UML建模過程專家詳解
本節向大家介紹一下UML建模過程，主要包括UML建模過程高層視圖和UML實際建模過程兩大部分內容，希望通過本節的介紹大家對UML建模過程有深入的了解。
UML建模過程
UML是一種建模語言而不是方法,這是因為UML中沒有過程的概念,而過程正是方法的一個重要組成部分。UML本身獨立于過程,這意味著用戶在使用UML進行建模時,可以選用任何適合的過程。過程的選用與軟件開發過程的不同因素有關,諸如所開發軟件的種類(如實時系統、信息系統和桌面產品)、開發組織的規模(如單人開發、小組開發和團隊開發)等。用戶將根據不同的需要選用不同的過程。然而,使用UML建模仍然有著大致統一的過程框架,該框架包含了UML建模過程中的共同要素,同時又為用戶選用與其所開發的工程相適合的建模技術提供了很大的自由度。
1.UML建模過程高層視圖
圖2是UML建模過程的一個高層視圖。這是一個迭代遞增的開發過程。使用此方法,不是在項目結束時一次性提交軟件,而是分塊逐次開發和提交。構造階段由多次迭代組成,每一次迭代都包含編碼、測試和集成,所得產品應滿足項目需求的某一子集,或提交給用戶,或純粹是內部提交。每次迭代都包含了軟件生命周期的所有階段。同時,每次迭代都要增加一些新的功能,解決一些新的問題。
因此,首先要做的工作是:選擇一些功能點,然后完成這些功能;之后再選擇別的功能點,如此循環往復。前兩個階段是初始(Inception)和細化(Elaboration)階段。在初始階段,需要考慮項目的效益,并確定項目的范圍。這一階段需要與項目出資方進行討論。在細化階段,需要收集更為詳細的需求,進行高層分析和設計,并為構造階段制定計劃。運用這種迭代開發過程時,還有一些工作(如β測試、性能調試和用戶培訓等)要放到最后的移交階段(Transition)中進行。
事實上,涉及實際建模工作的微過程存在于上述的每次迭代中。迭代式開發是項目成功的重要保證。
2.實際UML建模過程
每次迭代都分為以下幾個階段:
分析階段 建模的目的是捕捉系統的功能需求,分析、提取所開發系統的"客觀世界"領域的類以及描述它們的合作概貌。
設計階段 建模的目的是通過考慮實現環境,將分析階段的模型擴展和轉化為可行的技術實現方案。
實現階段 具體工作就是進行編碼,同時對已構造的模型作相應的修正。
配置階段 通過模型描述所開發系統的軟硬件配置情況。
測試階段 使用前幾個階段所構造的模型來指導和協助測試工作。
在系統開發的不同階段,使用UML為系統建模,可以通過建立不同的模型,從不同的視角,以不同的詳略程度對系統進行描述。下面以一個商業管理信息系統的開發過程為例,具體介紹UML建模的實際過程:
(1)需求
最初版本商業MIS的正文需求規格說明應當由代表系統最終用戶的人員提供,內容包括系統基本功能需求和對計算機系統的要求。大致描述如下:
·它是一個商業支持系統;
·采購員采購所需的商品;
·保管員將采購的商品登記入庫;
·調撥員將庫存商品調撥到相應的銷售部門;
·銷售部門銷售商品;
·統計部門核算商場經營狀況;
·系統能運行于通用的技術環境(如Unix、Windows等)中,具有良好的圖形用戶界面
·系統容易維護,便于功能擴充。
由于基于UML的系統開發采取增量和迭代方式,商業MIS的初始版本僅需要完成系統的最基本功能(基本業務),而其他功能的實現(如商品移管、電子訂貨、電子支付、網絡銷售等)則在以后的版本中完成。#p#
(2)分析
分析的任務是找出系統的所有需求并加以描述,同時建立模型,以定義系統中的關鍵領域類,應由系統用戶和開發人員合作完成。這一階段不要拘泥于設計細節和技術方案。
需求分析
UML建模過程中需求分析的第一步是定義用例,以描述所開發系統的外部功能需求。用例分析包括閱讀和分析需求說明,此時需要與系統的潛在用戶進行討論。用例模型的主要構件是用例、角色和系統邊界。用例用于描述每個功能需求,系統邊界用于界定系統功能范圍,而角色用于描述與系統功能有關的外部實體,它可以是用戶,也可以是外部系統。
在本實例中,通過分析,先確認商業MIS中的角色有銷售人員、庫存人員、采購人員、輔助人員和分析人員。在此基礎上,確認用例。商業MIS的用例有訂貨采購、庫存管理、商品銷售、統計分析、系統維護(包括增加商品、取消商品、制作標簽、價格變更、取消或更新標簽)。如圖3所示。
除了用用例圖描述系統需求外,還可以用文字(或活動圖)對每個用例進行需求說明,更具體地描述該用例與角色的交互。例如我們可以描述訂貨采購用例的需求說明如下:
·如果是新商品:
a.新商品登記;
b.采購進貨;
c.登記入庫。
·如果商品庫存不足:
a.采購進貨;
b.登記入庫。
訂貨采購需求可以用活動圖來描述,如圖4所示。由于用例的需求說明直接影響到后續設計階段對類的操作的定位,因此,用例的需求說明應當盡量全面、準確。
值得說明的是,絕大多數用例可以在系統需求分析階段確定,但隨著系統的進展,可能會發現更多的用例,甚至會發現前面定義的用例存在不夠確切或錯誤的地方,需要重新修改。因此,在整個系統開發過程中,都應當時刻關注用例。
特定領域分析
分析階段的另一項工作是特定領域分析,以列出系統中的特定領域類。我們可以通過閱讀規格說明、用例以及尋找系統處理的"概念"來進行特定領域分析,也可以通過用戶和領域專家的討論,以識別出要處理的所有關鍵類及它們的相互關系。這里的特定領域是指具體的商業領域,而不是整個系統領域。
在本實例中,可以確定商業MIS中的特定領域類為商品、保質商品、非保質商品、物品、銷售、訂貨、庫存、廠商,并使用類圖來描述系統領域類及其關系。
需要強調的是,這一階段對特定領域類的描述具有一定的素描性質,也就是說特定領域類的操作和屬性不一定與最終實現時的定義一致。因為此時還沒有涉及到系統功能的具體實現,不可能準確、完整地定義它們。有一些操作需要在設計階段細化時才能確定。
此外,為了描述領域類的動態行為,可以使用UML中的任何一種動態圖(如順序圖、活動圖、合作圖、狀態圖)。本階段的各動態圖都具有素描性質,主要是為了協助對領域類及其相互關系的分析,為下一階段的具體設計打下基礎。
UML建模是很靈活的過程,使用者不必面面俱到地畫出各種圖。對于每一幅圖,只有在必要時(比如能幫助分析、設計、指導編碼、加深理解、促進交流等)才需要畫出,這樣的圖對建模才有意義,否則會浪費精力而事倍功半。本節UML建模過程就介紹到這里。
【編輯推薦】
