王雁濤 王 毅 楊 鈿

（1.海軍裝備部駐重慶地區(qū)軍事代表局 重慶 400042）（2.總裝備部重慶軍事代表局 重慶 400060）

1 引言

近年來，隨著計(jì)算機(jī)軟件在軍用與民用領(lǐng)域的廣泛應(yīng)用，軟件可靠性的重要性也日益突出。作為主要的軟件可靠性分析方法之一，軟件失效模式與影響分析（SFMEA）得到了越來越多的實(shí)際應(yīng)用，對提高軟件的可靠性和安全性起到了重要作用。當(dāng)前，面向?qū)ο蠓椒ㄒ殉蔀閲鴥?nèi)外軟件設(shè)計(jì)的主流，UML亦已成為軟件界統(tǒng)一的建模語言。建模語言是構(gòu)建軟件的藍(lán)圖，從軟件開發(fā)的建模語言入手進(jìn)行SFMEA 分析，無疑抓住了面向?qū)ο筌浖煽啃苑治龅暮诵?。因此，基于UML的SFMEA 方法對面向?qū)ο筌浖目煽啃苑治鼍哂兄匾饬x。

當(dāng)前，國內(nèi)外針對該領(lǐng)域的研究成果非常少。從檢索到的僅有的幾篇文獻(xiàn)來看，Nathaniel Ozarin 教授在2004年發(fā)表的文獻(xiàn)［1］中總結(jié)了軟件開發(fā)階段、UML 圖和軟件單元（方法、類、模塊和包）三者之間的關(guān)系，著重描述了SFMEA 四個(gè)級別（方法級、類級、模塊級和包級）的分析特點(diǎn)和過程。作者雖然將UML圖與SFMEA 關(guān)聯(lián)起來，卻未闡述如何將UML圖以及關(guān)系元素具體應(yīng)用在SFMEA 各級別分析中。同一年，Herbert Hecht教授發(fā)表的一篇基于UML的計(jì)算機(jī)輔助軟件FMEA 文獻(xiàn)［2］中，分別從軟件開發(fā)過程中的概念階段（即需求階段）和執(zhí)行階段（即編碼階段）以實(shí)例闡述了UML 圖在SFMEA 中的應(yīng)用方法。不過，作者僅僅對用例圖和類圖的特點(diǎn)做了研究，缺乏對UML元素全面的闡述。針對當(dāng)前研究現(xiàn)狀，本人致力于研究基于UML的、應(yīng)用于軟件開發(fā)各階段的、全面深入的SFMEA 分析方法，提高面向?qū)ο筌浖目煽啃院桶踩浴?/p>

2 需求分析階段的UML建模特點(diǎn)

需求分析階段是軟件開發(fā)過程中第一個(gè)重要階段，用來描述用戶需求和系統(tǒng)結(jié)構(gòu)。因此在這個(gè)階段需要采用好的需求分析方法和技術(shù)，以保證得到高質(zhì)量的用戶需求［3］。需求分析階段建模常用的UML 圖形有：用例圖、類圖和活動(dòng)圖。

用例圖：用例圖通常是軟件需求分析階段基于UML開發(fā)的首要工具，用來描述用戶需求。用例圖包括用例、參與者和它們之間的關(guān)系，如圖1所示。用例與參與者之間存在關(guān)聯(lián)關(guān)系，用例與用例之間主要存在兩種關(guān)系：包含（用《uses》表示）和擴(kuò)展（用《extends》表示）。包含是指一個(gè)用例作為另一個(gè)用例必需的部分被使用；擴(kuò)展則是指一個(gè)用例擴(kuò)充了另一個(gè)用例的功能，但這個(gè)擴(kuò)充功能不是必需的［3］。

圖1 用例圖

圖2 類圖

·類圖：如圖2所示，類圖由類和類間關(guān)系組成，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。在程序設(shè)計(jì)的不同階段，類圖的作用也不相同。在需求分析階段，類圖是針對研究領(lǐng)域的概念描述。繪制類圖時(shí)，一般只給出主要的類名、屬性和方法及主要的類間關(guān)系（關(guān)聯(lián)、依賴和泛化）［3］。

圖3 活動(dòng)圖

·活動(dòng)圖：活動(dòng)圖用來描述一個(gè)過程或操作的執(zhí)行步驟。一個(gè)活動(dòng)順序地跟在另一個(gè)活動(dòng)后執(zhí)行，表示系統(tǒng)按照先后次序依次進(jìn)行，如圖3所示。在需求分析階段，活動(dòng)圖常用來描述系統(tǒng)的宏觀活動(dòng)［4］。

3 基于UML的SFMEA 方法研究

按分析的層次，SFMEA 分為系統(tǒng)級SFMEA 和詳細(xì)級SFMEA［5］。系統(tǒng)級SFMEA 用以分析評價(jià)軟件的需求描述和體系結(jié)構(gòu)，確保軟件結(jié)構(gòu)能夠抵御軟硬件失效所帶來的影響，降低軟件風(fēng)險(xiǎn)。因此需要在開發(fā)過程的早期開始實(shí)施系統(tǒng)級SFMEA，如需求分析階段和概要設(shè)計(jì)階段。系統(tǒng)級SFMEA的一般分析步驟［6］為：系統(tǒng)定義—功能分解—對所選層次的定義—對所選層次的基本單元進(jìn)行失效模式分析—填寫SFMEA 分析表格—提出改進(jìn)、糾正措施。我們認(rèn)為，在軟件需求分析階段，基于UML的SFMEA 也遵循同樣的分析步驟。

3.1 系統(tǒng)定義并功能分解

作為一種自底向上的分析方法，SFMEA 首先需要將被分析系統(tǒng)按層次分解成各個(gè)功能模塊。這種分解遵循的方式是能夠識別底層模塊的失效模式。底層模塊的失效影響構(gòu)成了上一層次模塊的失效模式。影響選擇合適的系統(tǒng)層次的基本因素在于分析的目的和可參考文檔的詳盡程度［7］。

從用例圖的特點(diǎn)可知，用例表示系統(tǒng)執(zhí)行的功能模塊。在實(shí)際開發(fā)過程中，隨著對需求進(jìn)一步的分析和明確，用例可以進(jìn)一步分解，得到子用例。這些用例和子用例在SFMEA 中作為失效模式的分析對象，即分析項(xiàng)（如圖4所示）。

需要說明的是，用例之間的包含（用《uses》表示）和擴(kuò)展（用《extends》表示）關(guān)系在用例分解中得以如下體現(xiàn)：被包含用例是包含用例（或基礎(chǔ)用例）執(zhí)行的一部分，因此是其子用例之一；擴(kuò)展用例是對基礎(chǔ)用例的功能擴(kuò)充，通常也作為基礎(chǔ)用例的子用例之一。用例之間的這些相互關(guān)系有助于我們對系統(tǒng)功能層次的了解和劃分。

3.2 確定分析的約定層次

系統(tǒng)功能層次劃分完成以后，確定分析的約定層次是一步很重要的工作，它決定了我們在哪個(gè)層次上進(jìn)行分析。確定約定層次是一個(gè)主觀行為，一般來說，分析人員可以約定在任意層次上開始分析。約定層次越低，功能模塊就越多，分析結(jié)果更全面，但花費(fèi)的人力、時(shí)間成本也就越高。實(shí)施SFMEA的目的之一是在軟件開發(fā)過程的早期盡可能多地發(fā)現(xiàn)軟件存在的缺陷并加以改進(jìn)，因此，在需求分析階段應(yīng)該從較低層次開始SFMEA 分析（如圖4所示）。

圖4 用例圖、分析項(xiàng)和約定層次

3.3 確定失效影響的傳遞路徑

失效影響是指軟件（或軟件單元）失效對系統(tǒng)造成的后果。失效影響具有傳遞性，一般分為本層次影響、上一層次影響、最終影響。為了得到失效影響的傳遞路徑，我們需要確定軟件模塊（或軟件單元）之間的順序依賴關(guān)系。

UML中的活動(dòng)圖適合于描述跨一個(gè)或多個(gè)用例的行為，而且它的特點(diǎn)很適合描述用例行為的順序關(guān)系。因此在需求分析階段的SFMEA 過程中，我們利用已有的活動(dòng)圖，在用例級（或子用例級）分析層次上確定用例（或子用例）的執(zhí)行順序，建立失效影響的傳遞路徑。這種用活動(dòng)圖元素表示用例與用例、子用例與子用例之間的順序依賴關(guān)系的圖形稱作“用例依賴關(guān)系圖”［8］，如圖5所示。該圖反映了圖4中在約定層次上三個(gè)用例的依賴關(guān)系。該三個(gè)用例順序執(zhí)行，用例1.1失效的本層次影響是對用例1.2實(shí)施，用例1.2失效的本層次影響是對用例2.1 實(shí)施，等等，以此類推。另外，分析用例的上一層次失效影響以及最終影響則根據(jù)用例圖的層次關(guān)系來確定。如參考圖4用例圖，用例1.1的上一層次影響是對用例1實(shí)施，最終影響是對整個(gè)系統(tǒng)實(shí)施。

圖5 用例依賴關(guān)系圖

3.4 確定失效模式并進(jìn)行影響分析，完成分析表

SFMEA的最終成果是生成分析表，表格內(nèi)容主要包括分析項(xiàng)、失效模式、失效原因、失效影響、嚴(yán)酷度以及改進(jìn)措施和建議。由前面的分析得知，將約定層次上的用例（或子用例）作為分析項(xiàng)。失效模式是指軟件（或軟件單元）失效的表現(xiàn)形式，是SFMEA 最重要的分析元素。分析人員需要根據(jù)分析項(xiàng)的功能特點(diǎn)并結(jié)合需求規(guī)格文檔，例舉出該分析項(xiàng)所有潛在的失效模式。然后，從約定層次向上追溯失效影響的傳遞路徑，確定該失效模式的本層次影響、上一層次影響和最終影響。再協(xié)同開發(fā)人員、領(lǐng)域?qū)＜乙约敖Y(jié)合相關(guān)文檔找出失效原因并評估失效嚴(yán)酷度。最后，提出改進(jìn)措施和建議，完成SFMEA 分析表。

綜上論述，在軟件需求分析階段基于UML的SFMEA方法總結(jié)如下：

1）分析對象：用例圖、活動(dòng)圖。

2）分析方法：利用用例圖確定分析層次和分析項(xiàng)，結(jié)合用例圖和活動(dòng)圖建立“用例依賴關(guān)系圖”，用于分析失效影響。

需要說明的是，類圖在軟件需求分析階段主要用于概念類的描述，不需要也無法獲知類的完整屬性和方法。因此，類圖不作為在此階段SFMEA的分析對象。但是，在后續(xù)的軟件設(shè)計(jì)和實(shí)現(xiàn)階段的SFMEA 過程中，類圖將扮演著重要角色。

4 實(shí)例驗(yàn)證

以常見的ATM 軟件系統(tǒng)為例，根據(jù)其需求規(guī)格說明文檔繪制的系統(tǒng)用例圖如圖6所示，包括“存款”、“取款”、“查詢余額”三個(gè)主要用例，其中“登錄”為該三個(gè)用例的被包含用例，“打印收據(jù)”為“存款”、“取款”用例的擴(kuò)展用例。對ATM 軟件系統(tǒng)的SFMEA 分析過程如下

圖6 用例圖

1）系統(tǒng)定義和功能分解。由圖6可知，系統(tǒng)包括“取款”、“存款”和“查詢余額”三大功能模塊，它們作為系統(tǒng)第一層次。“登錄”用例是被包含用例，因此屬于第二層次；“打印數(shù)據(jù)”用例是擴(kuò)展用例，根據(jù)其功能特點(diǎn)，屬于上層用例的子用例，也劃為第二層次。并且，“打印數(shù)據(jù)”與“登錄”兩個(gè)子用例相互獨(dú)立。分析人員參考子用例圖進(jìn)一步了解系統(tǒng)層次。以“取款”用例為例，圖7反映了“取款”的子用例層次圖。分析人員可結(jié)合用例圖與子用例圖來約定分析層次。

圖7 “取款”子用例圖

2）約定整個(gè)軟件系統(tǒng)為分析的初始層次，子用例圖的最底層為最低層次。如圖7 所示，子用例“驗(yàn)證銀行卡”、“驗(yàn)證密碼”、“驗(yàn)證賬戶余額”、“結(jié)算”所在層次為最低層次；“打印數(shù)據(jù)”沒有子用例，也將其作為最低層次。上述5個(gè)子用例均作為分析項(xiàng)，展開自底向上的分析。

3）確定失效影響的傳遞路徑。根據(jù)“取款”用例的活動(dòng)圖（見圖8）我們看到，一個(gè)或一組活動(dòng)構(gòu)成了個(gè)子用例。由這些活動(dòng)的順序關(guān)系，我們繪制出如圖9所示的子用例依賴關(guān)系圖，建立了子用例失效影響的傳遞路徑。

圖8 “取款”活動(dòng)圖

圖9 “取款”子用例依賴關(guān)系圖

4）研究分析失效模式。以“驗(yàn)證銀行卡”子用例為例，根據(jù)其功能特點(diǎn)，有“無效銀行卡驗(yàn)證成功”、“有效的銀行卡驗(yàn)證失敗”以及“驗(yàn)證銀行卡超時(shí)”等三種失效模式。分析失效原因需要結(jié)合需求說明文檔以及項(xiàng)目經(jīng)驗(yàn)來闡述。分析失效的本層次影響、上一層影響以及最終影響時(shí)，分別根據(jù)圖9、圖7和圖6進(jìn)行跟蹤，即分析對“驗(yàn)證密碼”子用例、“登錄”子用例和整個(gè)系統(tǒng)的影響。最后，評估失效影響的嚴(yán)重等級。對其他子用例的分析過程如法炮制。

通過以上分析，最后完成SFMEA分析表，如表1所示。

表1 SFMEA 表

續(xù)表1

5 結(jié)語

通過以上分析，我們更加明確利用UML 元素在軟件需求分析階段進(jìn)行SFMEA 分析的特點(diǎn)：

1）使用用例圖定義分析項(xiàng)，分析者不需要將系統(tǒng)進(jìn)行功能分解［1］；結(jié)合活動(dòng)圖來建立用例依賴關(guān)系圖，確定失效影響的傳遞路徑；

2）用例圖覆蓋了系統(tǒng)功能，將用例作為分析項(xiàng)，確保分析完整；

3）找出需求描述在準(zhǔn)確性、一致性和完備性方面的缺陷；識別軟件潛在的危險(xiǎn)狀態(tài)，在后續(xù)設(shè)計(jì)和實(shí)現(xiàn)中避免危險(xiǎn)狀態(tài)的發(fā)生。

與其他開發(fā)階段相比，在需求分析階段進(jìn)行SFMEA分析只需要相對較少的努力，雖然分析結(jié)果不如在后續(xù)階段的分析準(zhǔn)確和完善，但具有重要意義。

［1］Nathaniel Ozarin.Failure Modes and Effects Analysis during Design of Computer Software［J］.IEEE，2004：201－206.

［2］Herbert Hecht，Xuegao An，Myron Hecht.Computer Aided Software FMEA for Unified Modeling Language Based Software［J］.IEEE，2004：243－248.

［3］王養(yǎng)廷，李磊，等.UML 基礎(chǔ)與應(yīng)用［M］.北京：清華大學(xué)出版社，2006，6.

［4］吳建，鄭潮，等.UML基礎(chǔ)與Rose建模案例［M］.北京：人民郵電出版社，2004，（10）：91.

［5］Bowles，J.B..The new SAE FMECA standard［C］／／Proceedings Annual Reliability and Maintainability Symposium，1998：48－53.

［6］栗芳，黃錫滋.軟件失效模式效應(yīng)分析方法［D］.電子科技大學(xué)，1998.

［7］Haapanen Pentti，Helminen Atte.Failure modes and effects analysis of software based automation systems［J］.STUKYTO－TR 190，2002，（8）.

［8］徐宏喆，陳建明，等.UML 自動(dòng)化測試技術(shù)［M］.西安：西安交通大學(xué)出版社，2006：143－173.