用例圖和順序圖構造操作剖面方法的有效軟體工程論文

　　摘要:探討了由面向物件用例模型構造操作剖面的可行性,結合一個例項,詳細介紹基於統一建模語言UML(Unified Modeling Language)的用例圖和順序圖構造操作剖面的具體方法,代寫碩士論文並對基於UML用例圖和順序圖構造操作剖面方法的有效性進行了分析.結果表明,將操作剖面構造與軟體系統建模相結合,可大大簡化構造過程,降低開發費用.

　　關鍵詞: 軟體;軟體工程;可靠性工程;操作剖面;用例模型;統一建模語言;用例圖;順序圖

　　操作剖面是描述使用者如何使用軟體的一種技術.因此透過構造軟體系統的操作剖面,可以有效的指導軟體可靠性測試工作,獲得理想的測試結果,大大提高軟體系統的可靠性.一方面,軟體執行條件和使用者的使用情況可以用剖面概念進行描述;另一方面,建立完整的系統表示模型,可以使人們從全域性上把握軟體系統的全貌.因此,如何準確高效的構造出切合實際的軟體系統操作剖面已成為軟體可靠性測試工作的一個關鍵環節.操作剖面的基於非面向物件技術的構造已經有了較為系統化的、成熟的理論和方法[1],而基於面向物件技術,尤其是基於統一建模語言UML(Unified Modeling Language)的系統操作剖面構造的系統化和成熟的理論、技術、方法以及相關工具目前尚未見到.

　　隨著面向物件技術應用的日益廣泛,如何將面向物件技術用於軟體系統操作剖面的構造已逐漸成為人們關注的焦點[2~4].本文探討在成熟的面向物件統一建模語言UML基礎上進行軟體系統操作剖面的構造,並對其有效性進行了分析.

　　1基本概念及操作剖面傳統構造方法

　　1.1 基本概念

　　統一建模語言UML是面向物件技術發展的重大里程碑.它不僅支援面向物件的分析與設計,還支援從需求分析開始的軟體開發的全過程.UML用例檢視,作為描述系統功能需求的手段和方法,用於輔助需求分析,描述專案的功能性需求.用例模型中,每個用例的執行獨立於其他用例,在功能上具有完整性.用例是一個類,它完整地描述系統功能,包括用例執行過程中可能產生的諸多變化情況,錯誤情況和異常情況等.用例例項化的結果通常稱為場景(Scenario),場景描述系統執行的一個特定情況.但用例檢視是靜態的,用例的動態執行過程不能表述,需要用UML的互動模型和活動模型進行描述.而順序圖模型可以用來進行一個場景說明———即一個事務的歷史過程[6],即完成用例動態執行的模擬.因此認為,對於任何一個複雜的軟體系統,上述2個檢視對系統功能性需求進行建模已經足夠.這為基於用例檢視和順序檢視構造操作剖面提供了重要依據.

　　1.2 操作剖面傳統構造方法

　　操作剖面的基於非面向物件技術的構造理論和方法在文獻[1],文獻[7]已經有詳細的闡述.Musa詳細描述了操作剖面的特徵,代寫碩士論文並給出了獲得操作剖面的方法.操作剖面是透過自頂向下不斷細化軟體輸入空間並確定機率的方法獲得的,如圖1所示.由於篇幅所限,在此不作詳細解釋.但需要指出的是,在Musa的操作剖面構造方法中,操作剖面是在軟體實現和軟體測試階段建立的,而其它剖面是在需求分析階段之前建立的.隨著面向物件技術等先進軟體工程方法的日益成熟,一方面,面向物件和快速原型法等新興開發技術的應用使得操作剖面的構造時機有了提前的可能;另一方面,在面向物件開發模式下,客戶要求根據用例模型安排人員現場模擬系統執行時,系統操作剖面的構造時機的提前便成了必要的需求.

　　2基於UML的操作剖面構造

　　本節中使用PBX(Private Branch eXchange)電話交換系統進行操作剖面構造方法的介紹.該系統是由AT&T公司開發的國際Definity專案.AT&T公司在此項工程的開發過程中使用了操作剖面和其他提高質量方法,大大提高了系統的可靠性和軟體質量.PBX系統是一個命令驅動系統.圖2是系統示意圖,其中,PBX交換機由UNIX工作站進行控制,同時與提供給使用者使用的數臺電話相連.該系統按執行模式分為單位使用、個人使用、服務人員使用、系統管理和系統維護5類.為簡化操作剖面的構建過程,本文僅以系統管理模式為例進行操作剖面的構造。構造操作剖面是一種逐步細化軟體執行條件和使用範圍的過程.本文將基於UML用例圖和順序圖操作剖面構造的整個過程分為3個主要階段,即建立用例剖面、確定場景剖面和構造操作剖面.

　　21 構造用例剖面

　　UML用例圖捕獲系統使用者需求及其描述的完整性給系統功能的細化提供了便利.下面首先給出用例剖面的定義,然後列出進行用例剖面構造的步驟.從軟體需求規格說明到用例剖面的構造需要完成的步驟:①細化系統功能,生成用例模型,即根據軟體需求規格說明建立UML用例檢視;②識別對用例產生影響的主要環境變數,並估測其出現機率;③分析用例和環境變數關係,並估計在環境變數影響下用例出現的機率.例如,在PBX交換系統中,系統管理工作方式主要包括行動電話或修改所提供服務、增加電話、代寫碩士論文摘除電話和更新電話簿4個功能,對這些功能產生主要影響的是電話型別,在此只考慮模擬電話和數字電話.根據上述步驟,在UML用例檢視的基礎上進行擴充得到如圖4所示的PBX系統中系統管理用例剖面檢視.在表示參與者與其參與執行的用例之間的通訊路徑的關聯上標註用例發生機率,如在管理使用者和增加用例之間的關聯上標註8%,表示此用例發生機率為8%;用註釋標註對每個用例產生主要影響的環境變數及其發生機率,如對行動電話或修改所提供服務、增加電話、摘除電話用例都產生影響的環境變數用註釋標註A(80%),B(20%),表示對上述3個用例有影響的主要環境為A,B,它們在各個用例下發生的機率均為80%與20%.

　　22 構造場景剖面

　　場景,作為系統執行特定情況的描述,是用例例項化的結果.根據UML用例圖定義可知,用例的定義包含用例所必需的所有行為,包括所有正常行為、異常情況及其預期反應[6].因此,場景有必要對用例的'所有情況進行描述.下面給出了場景剖面的定義及其

　　構造方法.定義場景剖面:場景剖面是指軟體系統由用例定義的場景及其發生的機率組成的集合.同樣可以給出集合的定義方式,在此省略.需要指出的是,此處場景發生的機率是在用例事件發生前提下的機率,是條件機率.場景剖面的構造在操作剖面的構造過程中起到了承上啟下的作用,它完成了操作剖面構造方法中的①用順序圖對用例場景進行描述;②估計場景出現機率2個步驟.PBX系統中新增使用者用例根據新增使用者型別不同可以劃分為3個場景:新增一般人員使用者、新增秘書使用者和新增經理使用者,按照PBX命令形式分別表示為: http://www.51lunwen.org/master_degree.html add-s staff,add-s secre-tary和add-s manager.根據上述步驟,可以得到如圖5所示的PBX系統中增加電話用例的場景剖面檢視.在檢視中,用註釋描述用例的每一場景發生的機率,如在增加電話用例中新增一般人員使用者場景發生的機率為70%,它表明在增加電話用例事件發生的前提下新增一般使用者電話的場景發生的機率是70%.

　　2.3 構造操作剖面

　　場景是用例例項化的描述,因此,場景剖面所描述的仍然是面向使用者的細化功能,而不是實際實現的操作,需要進一步細化.同時,操作剖面的構造有時還需要考慮系統的負載率[5](本文不作介紹).下面給出由場景剖面構造操作剖面的一般步驟:①識別場景剖面中的所有操作可能,建立操作和場景之間的聯絡;②識別操作輸入變數和輸入狀態的作用;③根據用例剖面、場景剖面、環境變數情況等因素估算操作出現機率.上例中,每一場景用PBX系統的一條命令表示,不能再分,認為每一場景均包含一個操作.在考慮操作輸入變數時,認為地址(location)對操作性質沒有影響,因此,在本文中不予考慮,當然如果認為某一地區發生此類操作較多的話,則另當別論.最後,可以根據條件機率公式,估算得到任一操作發生的機率,如管理人員執行add-s staff命令(針對模擬電話使用者)的操作機率為2%×8%×80%×70%=0.000896。

　　建立了操作剖面,就可以此為依據安排軟體可靠性測試工作的進行,大大提高軟體可靠性.由於篇幅所限,此例中提及的PBX系統操作剖面的Musa構造過程在此不作詳細介紹.讀者如有興趣,可參見文獻[5]和文獻[7].可以看出,基於UML用例圖和順序圖的操作剖面構造方法將操作剖面的構造過程融入了軟體系統建模過程中,大大減少了構造步驟,避免了傳統構造方法繁瑣的過程,降低了軟體開發的費用.

　　3有效性分析

　　首先,分析用例剖面的構造.透過用例剖面的定義可以看出,一方面,用例剖面透過UML用例檢視定義的用例描述了系統的功能性需求,傳統構造方法所強調的客戶、使用者和系統模型等資訊已經在建立用例模型時用UML用例檢視進行了描述;另一方面,它又透過定義這些用例發生的機率確定了系統的定量使用情況,滿足剖面的完備性.從此意義上講,用例剖面與傳統意義上的功能剖面是等價的.其次,從用例剖面到場景剖面的構造,以及從場景剖面到操作剖面的構造過程完成了操作剖面構造傳統方法中的①細化功能;②識別出所有可能的執行;③建立執行與功能之間的聯絡;④識別執行的輸入變數和輸入狀態;⑤)計算每個執行子類的出現機率等步驟,最終生成系統完整的操作剖面.可以看出,傳統構造方法中所考慮到的問題在基於UML用例圖和順序圖的操作剖面構造方法中均有所考慮,因此,認為本文提出的操作剖面構造方法是有效的.表2列出了2種方法中相關關鍵術語的對比.

　　4結束語

　　基於用例圖和順序圖的操作剖面的構造,可大大簡化操作剖面的傳統構造過程,避免由軟體系統需求規格說明到功能剖面的繁瑣構造過程.同時,由於用例圖和順序圖對系統功能性需求描述能力的完備性,也決定了這種操作剖面構造的方法與傳統方法的等價性.

　　參考文獻：

　　[1] Musa J D. Operational profiles in software-reliability engineering [J]. IEEE Software, 1993,10(2):14~32

　　[2] Lakey P, Neufelder A. System and software reliability assurance notebook[M]. NewYork: Rome Laboratory,1997. 9-16~9-20

　　[3] Regnell B, Runeson P, Wohlin C. Towards integration of use case modelling and usage-based testing[J]. Journal of Systems and Software, 2000, 50(2):117~130

　　[4] Butler G, Cretu A, Khendek F. Reconciling use cases and operational profiles[DB/OL]. http://www.51lunwen.org/master_degree.html http://citeseer.nj.nec.com/148512.html, 2000-04

　　[5] Lyu M R. Handbook of software reliability engineering [M]. McGraw-Hill publishing, 1995

　　[6]蘭博.UML參考手冊[M].姚淑珍,唐髮根譯.北京:機械工業出版社,2001Rumbaugh J. The unified modeling language reference manual[M]. Translated by Yao Shuzhen, Tang Fagen. Beijing:China Machine Press, 2001(in Chinese)

　　[7]黨齊民,楊新發.軟體可靠性工程中的操作剖面開發[J].軟體學報,1996,7(增刊):323~328DangQimin,YangXinfa. Operational profile development in software reiliability engineering[J]. Journal of Software,1996, 7 (supplement):323~328(in Chinese)