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