(4) UML軟件質量控制
軟件系統的質量往往是大型、復雜系統成敗的關鍵。軟件系統質量難以保證的主要原因首先是軟件系統固有的復雜性。但人們往往對這一點尚未有足夠的認識,而把軟件系統的復雜程度看得過低。另外一個原因是由于軟件系統及其管理工作固有的不可見性。采用定量軟件工程有利于改善可見性,但是還不可能做到完全透明。因此,在當代軟件技術水平的前提下,建造軟件質量控制環境勢在必行。學術界與工業界對軟件質量工程的看法主要劃分為兩個流派,一個叫"產品足夠優質"(Good-Enough),另一個叫"無差錯軟件"( Error-Free)。
在建造軟件質量控制環境時,除了應建造通用軟件過程管理環境(包括軟件項目管理、軟件配置管理和軟件質量管理)、軟件過程支持環境(以支持軟件開發單位成熟度模型CMM、個體軟件過程PSP和支持群組軟件過程TSP的實現)外,還應包含相互聯系但可分別獨立使用的三個子環境:
集成化軟件測試環境 這個環境應包括軟件需求覆蓋測試工具、源程序覆蓋測試工具、軟件回歸測試工具、軟件測試管理工具和內存負載檢測工具等。
集成化軟件質量度量環境 度量有關軟件質量的原始數據,并據此來計算ISO軟件度量標準中所需要的管理度量元。
軟件產品質量綜合評測系統 從上述諸方面因素對軟件產品的質量進行綜合考慮,把所得到的數據進行加權綜合。只有滿足整體要求的軟件才被認為是一個合格的軟件產品。
(5) UML逆向變換系統
當用戶對生成的代碼進行修改后,逆向轉換機制將用戶的修改轉換到模型上。否則,將造成模型和代碼間的不一致性,使系統的擴充、增刪和維護難以進行。
我們認為,如果一個支持環境既有正向變換機制,又有逆向變換機制,就能保持模型和代碼的一致性。動態模型的逆向轉換機制是研究難點,一般可由建模、析取和抽象三個步驟組成。我們將在正向轉換的基礎上,建立起模型到代碼的映射關系,嘗試建立一套約束機制,實現自動的或人工導引的逆向轉換機制。目前,國際上對這方面的研究尚不成熟。
五、標準建模語言UML的應用實例
UML是一種建模語言而不是方法,這是因為UML中沒有過程的概念,而過程正是方法的一個重要組成部分。UML本身獨立于過程,這意味著用戶在使用UML進行建模時,可以選用任何適合的過程。過程的選用與軟件開發過程的不同因素有關,諸如所開發軟件的種類(如實時系統、信息系統和桌面產品)、開發組織的規模(如單人開發、小組開發和團隊開發)等。用戶將根據不同的需要選用不同的過程。然而,使用UML建模仍然有著大致統一的過程框架,該框架包含了UML建模過程中的共同要素,同時又為用戶選用與其所開發的工程相適合的建模技術提供了很大的自由度。
1. UML建模過程高層視圖
文章來源于領測軟件測試網 http://www.kjueaiud.com/
