集成化軟件測試環境 這個環境應包括軟件需求覆蓋測試工具、源程序覆蓋測試工具、軟件回歸測試工具、軟件測試管理工具和內存負載檢測工具等。
集成化軟件質量度量環境 度量有關軟件質量的原始數據,并據此來計算ISO軟件度量標準中所需要的管理度量元。
軟件產品質量綜合評測系統 從上述諸方面因素對軟件產品的質量進行綜合考慮,把所得到的數據進行加權綜合。只有滿足整體要求的軟件才被認為是一個合格的軟件產品。
(5) UML逆向變換系統
當用戶對生成的代碼進行修改后,逆向轉換機制將用戶的修改轉換到模型上。否則,將造成模型和代碼間的不一致性,使系統的擴充、增刪和維護難以進行。
我們認為,如果一個支持環境既有正向變換機制,又有逆向變換機制,就能保持模型和代碼的一致性。動態模型的逆向轉換機制是研究難點,一般可由建模、析取和抽象三個步驟組成。我們將在正向轉換的基礎上,建立起模型到代碼的映射關系,嘗試建立一套約束機制,實現自動的或人工導引的逆向轉換機制。目前,國際上對這方面的研究尚不成熟。
五、標準建模語言UML的應用實例
UML是一種建模語言而不是方法,這是因為UML中沒有過程的概念,而過程正是方法的一個重要組成部分。UML本身獨立于過程,這意味著用戶在使用UML進行建模時,可以選用任何適合的過程。過程的選用與軟件開發過程的不同因素有關,諸如所開發軟件的種類(如實時系統、信息系統和桌面產品)、開發組織的規模(如單人開發、小組開發和團隊開發)等。用戶將根據不同的需要選用不同的過程。然而,使用UML建模仍然有著大致統一的過程框架,該框架包含了UML建模過程中的共同要素,同時又為用戶選用與其所開發的工程相適合的建模技術提供了很大的自由度。
1. UML建模過程高層視圖
圖2是UML建模過程的一個高層視圖。這是一個迭代遞增的開發過程。使用此方法,不是在項目結束時一次性提交軟件,而是分塊逐次開發和提交。構造階段由多次迭代組成,每一次迭代都包含編碼、測試和集成,所得產品應滿足項目需求的某一子集,或提交給用戶,或純粹是內部提交。每次迭代都包含了軟件生命周期的所有階段。同時,每次迭代都要增加一些新的功能,解決一些新的問題。
因此,首先要做的工作是:選擇一些功能點,然后完成這些功能;之后再選擇別的功能點,如此循環往復。前兩個階段是初始( Inception)和細化 ( Elaboration) 階段。在初始階段,需要考慮項目的效益,并確定項目的范圍。這一階段需要與項目出資方進行討論。在細化階段,需要收集更為詳細的需求,進行高層分析和設計,并為構造階段制定計劃。運用這種迭代開發過程時,還有一些工作(如β測試、性能調試和用戶培訓等)要放到最后的移交階段(Transition)中進行。
事實上,涉及實際建模工作的微過程存在于上述的每次迭代中。迭代式開發是項目成功的重要保證。
2. UML實際建模過程
文章來源于領測軟件測試網 http://www.kjueaiud.com/
