標準建模語言UML的應用實例_第1頁
標準建模語言UML的應用實例_第2頁
標準建模語言UML的應用實例_第3頁
標準建模語言UML的應用實例_第4頁
標準建模語言UML的應用實例_第5頁
已閱讀5頁,還剩1頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、標準建模語言UML的應用實例UML是一種建模語言而不是方法,這是因為UML中沒有過程的概念,而過程正是方法的一個重要組成部分。UML本身獨立于過程,這意味著用戶在使用 UML進行建模時,可以選用任何適合的過程。過程的選用與軟件開發(fā)過程的不同因素有關(guān),諸如所開發(fā)軟件的種類(如實時系統(tǒng)、信息系統(tǒng)和桌面產(chǎn)品)、開發(fā)組 織的規(guī)模(如單人開發(fā)、小組開發(fā)和團隊開發(fā))等。用戶將根據(jù)不同的需要選用不同的過程。然而,使用UML建模仍然有著大致統(tǒng)一的過程框架,該框架包含了 UML建模過程中的共同要素,同時又為用戶選用與其所開發(fā)的工程相適合的建模技術(shù)提供了很大的自由度。 1. UML建模過程 UML建模過程是一個迭

2、代遞增的開發(fā)過程。前兩個階段是初始( Inception)和細化( Elaboration) 階段。在初始階段,需要考慮項目的效益,并確定項目的范圍。這一階段需要與項目出資方進行討論。在細化階段,需要收集更為詳細的需求,進行高層分析和設計,并為構(gòu)造階段制定計劃。構(gòu)造階段由多次迭代組成,每一次迭代都包含編碼、測試和集成,所得產(chǎn)品應滿足項目需求的某一子集,或提交給用戶,或純粹是內(nèi)部提交。每次迭代都包含了軟件生命周 期的所有階段。同時,每次迭代都要增加一些新的功能,解決一些新的問題。運用這種迭代開發(fā)過程時,還有一些工作(如測試、性能調(diào)試和用戶培訓等)要放到最后的移交階段(Transition)中進

3、行。2. UML實際建模過程 每次迭代都分為以下幾個階段:分析階段:建模的目的是捕捉系統(tǒng)的功能需求,分析、提取所開發(fā)系統(tǒng)的"客觀世界"領域的類以及描述它們的合作概貌。設計階段:建模的目的是通過考慮實現(xiàn)環(huán)境,將分析階段的模型擴展和轉(zhuǎn)化為可行的技術(shù)實現(xiàn)方案。實現(xiàn)階段:具體工作就是進行編碼,同時對已構(gòu)造的模型作相應的修正。配置階段:通過模型描述所開發(fā)系統(tǒng)的軟硬件配置情況。測試階段:使用前幾個階段所構(gòu)造的模型來指導和協(xié)助測試工作。 在系統(tǒng)開發(fā)的不同階段,使用UML為系統(tǒng)建模,可以通過建立不同的模型,從不同的視角,以不同的詳略程度對系統(tǒng)進行描述。下面以一個商業(yè)管理信息系統(tǒng)的開發(fā)過程為

4、例,具體介紹UML建模的實際過程:(1) 需求最初版本商業(yè)MIS的正文需求規(guī)格說明應當由代表系統(tǒng)最終用戶的人員提供,內(nèi)容包括系統(tǒng)基本功能需求和對計算機系統(tǒng)的要求。大致描述如下:· 它是一個商業(yè)支持系統(tǒng);· 采購員采購所需的商品;· 保管員將采購的商品登記入庫;· 調(diào)撥員將庫存商品調(diào)撥到相應的銷售部門;· 銷售部門銷售商品;· 統(tǒng)計部門核算商場經(jīng)營狀況;· 系統(tǒng)能運行于通用的技術(shù)環(huán)境(如Unix、Windows等)中,具有良好的圖形用戶界面· 系統(tǒng)容易維護,便于功能擴充 。由于基于UML的系統(tǒng)開發(fā)采取增量和迭代方式,

5、商業(yè)MIS的初始版本僅需要完成系統(tǒng)的最基本功能(基本業(yè)務),而其他功能的實現(xiàn)(如商品移管、電子訂貨、電子支付、網(wǎng)絡銷售等)則在以后的版本中完成。 (2) 分析分析的任務是找出系統(tǒng)的所有需求并加以描述,同時建立模型,以定義系統(tǒng)中的關(guān)鍵領域類,應由系統(tǒng)用戶和開發(fā)人員合作完成。這一階段不要拘泥于設計細節(jié)和技術(shù)方案。 需求分析分析的第一步是定義用例,以描述所開發(fā)系統(tǒng)的外部功能需求。用例分析包括閱讀和分析需求說明,此時需要與系統(tǒng)的潛在用戶進行討論。用例 模型的主要構(gòu)件是用例、角色和系統(tǒng)邊界。用例用于描述每個功能需求,系統(tǒng)邊界用于界定系統(tǒng)功能范圍,而角色用于描述與系統(tǒng)功能有關(guān)的外部實體,它可以是用 戶,也

6、可以是外部系統(tǒng)。在本實例中,通過分析,先確認商業(yè)MIS中的角色有銷售人員、庫存人員、采購人員、輔助人員和分析人員。在此基礎上,確認用例。商業(yè)MIS的用例有訂貨采 購、庫存管理、商品銷售、統(tǒng)計分析、系統(tǒng)維護(包括增加商品、取消商品、制作標簽、價格變更、取消或更新標簽)。除了用用例圖描述系統(tǒng)需求外,還可用文字(或活動圖)對每個用例進行需求說明,更具體地描述該用例與角色的交互。例如我們可以描述訂貨采購用例的需求說明如下:· 如果是新商品:a. 新商品登記;b. 采購進貨;c. 登記入庫 。· 如果商品庫存不足:a. 采購進貨;b. 登記入庫。訂貨采購需求可以用活動圖來描述,如圖4

7、所示。由于用例的需求說明直接影響到后續(xù)設計階段對類的操作的定位,因此,用例的需求說明應當盡量全面、準確。值得說明的是,絕大多數(shù)用例可以在系統(tǒng)需求分析階段確定,但隨著系統(tǒng)的進展,可能會發(fā)現(xiàn)更多的用例,甚至會發(fā)現(xiàn)前面定義的用例存在不夠確切或錯誤的地方,需要重新修改。因此,在整個系統(tǒng)開發(fā)過程中,都應當時刻關(guān)注用例。 特定領域分析分析階段的另一項工作是特定領域分析,以列出系統(tǒng)中的特定領域類。我們可以通過閱讀規(guī)格說明、用例以及尋找系統(tǒng)處理的"概念"來進行特 定領域分析,也可以通過用戶和領域?qū)<业挠懻?以識別出要處理的所有關(guān)鍵類及它們的相互關(guān)系。這里的特定領域是指具體的商業(yè)領域,而不是

8、整個系統(tǒng)領域。在本實例中,可以確定商業(yè)MIS中的特定領域類為商品、保質(zhì)商品、非保質(zhì)商品、物品、銷售、訂貨、庫存、廠商,并使用類圖來描述系統(tǒng)領域類及其關(guān)系。需要強調(diào)的是,這一階段對特定領域類的描述具有一定的素描性質(zhì),也就是說特定領域類的操作和屬性不一定與最終實現(xiàn)時的定義一致。因為此時還沒有涉及到系統(tǒng)功能的具體實現(xiàn),不可能準確、完整地定義它們。有一些操作需要在設計階段細化時才能確定。此外,為了描述領域類的動態(tài)行為,可以使用UML中的任何一種動態(tài)圖(如順序圖、活動圖、合作圖、狀態(tài)圖)。本階段的各動態(tài)圖都具有素描性質(zhì),主要是為了協(xié)助對領域類及其相互關(guān)系的分析,為下一階段的具體設計打下基礎。UML建模是

9、很靈活的過程,使用者不必面面俱到地畫出各種圖。對于每一幅圖,只有在必要時(比如能幫助分析、設計、指導編碼、加深理解、促進交流等)才需要畫出,這樣的圖對建模才有意義,否則會浪費精力而事倍功半。(3) 設計設計階段的任務是通過綜合考慮所有的技術(shù)限制,以擴展和細化分析階段的模型。設計的目的是指明一種易轉(zhuǎn)化成代碼的工作方案,是對分析工作的細化,即進一步細化分析階段所提取的類(包括其操作和屬性),并且增加新類以處理諸如數(shù)據(jù)庫、用戶接口、通信、設備等技術(shù)領域的問題。設計階段可以分為兩個部分:結(jié)構(gòu)設計是高層設計,其任務是定義包(子系統(tǒng)),包括包間的依賴性和主要通信機制。我們希望得到盡可能簡單和清晰的結(jié)構(gòu),各

10、部分之間的依賴盡可能的少,并盡可能的減少雙向的依賴關(guān)系。第二部分是詳細設計,細化包的內(nèi)容,使編程人員得到所有類的一個足夠清晰的描述。同時使用UML中的動態(tài)模型,描述特定情況下這些類的實例之間的行為。· 結(jié)構(gòu)設計一個設計良好的系統(tǒng)結(jié)構(gòu)是系統(tǒng)可擴充和可變更的基礎。包實際上是一些類的集合。類圖中包括有助于用戶從技術(shù)邏輯中分離出應用邏輯(領域類),從而減少它們之間的依賴性。這就是軟件結(jié)構(gòu)設計強調(diào)的模塊間的高聚合、低偶合的原則。在商業(yè)MIS中,存在以下包(或子系統(tǒng)):用戶接口包:用戶接口類允許用戶訪問系統(tǒng)數(shù)據(jù)和加入新數(shù)據(jù)。在商業(yè)對象中,用戶接口包跟商業(yè)對象包合作,調(diào)用商業(yè)對象的操作,實施數(shù)據(jù)的

11、檢索和插入。 商業(yè)對象包:包括來自分析階段的特定領域類。在設計階段,詳細設計這些類,以完整定義他們的操作,支持對數(shù)據(jù)庫的存取。所以,所有商業(yè)對象類必須繼承數(shù)據(jù)庫包中的類。數(shù)據(jù)庫包:為商業(yè)對象包中的類提供服務,便于永久存儲。實用包:包含系統(tǒng)其他包要使用的服務。· 詳細設計詳細設計的目的是通過創(chuàng)建新的類圖、狀態(tài)圖和動態(tài)圖,描述新的技術(shù)類,并擴展和細化分析階段"素描"的商業(yè)對象類。這些圖在分析階段也 曾用過,不過在詳細設計階段,它們是從技術(shù)層次上對系統(tǒng)進行更詳盡的描述。如分析階段的用例描述用來驗證它們是否在設計階段都得到處理,而順序圖用來展示 系統(tǒng)中每個用例在技術(shù)上如何

12、實現(xiàn),等等。數(shù)據(jù)庫包:MIS的實現(xiàn)必須有永久存儲對象即數(shù)據(jù)庫的支持,因此系統(tǒng)中必須增加數(shù)據(jù)庫層,提供這種服務。目前,市面上有許多商用數(shù)據(jù)庫,有的是真正的面向 對象數(shù)據(jù)庫如工程數(shù)據(jù)庫,有的是傳統(tǒng)的關(guān)系數(shù)據(jù)庫。由于我們只討論設計方法,不涉及具體的環(huán)境,因此,可以抽象一個永久存儲類來實現(xiàn)對數(shù)據(jù)庫的通用操作, 如存儲、更新、刪除、查詢等。永久類類似于MFC中的基類。商業(yè)對象包:設計階段的商業(yè)對象包即是分析階段的領域類,需要從實現(xiàn)角度對這些類進行細化,包括如何實現(xiàn)他們之間的關(guān)聯(lián)和行為。所有這些對象類必須從數(shù)據(jù) 庫包的永久類中繼承而來。分析階段描述的類的操作,在設計模型中可能被分解成幾個操作或者改變名稱。

13、因為分析是構(gòu)造每個類的框架,而設計是對系統(tǒng)的詳細說 明,因此設計模型中所有類的操作必須定義符號和返回值。圖2是經(jīng)過細化后的商業(yè)類圖(局部)在設計階段,也可細化分析階段的狀態(tài)圖,更詳細的顯示狀態(tài)的變換細節(jié)(如圖3)。使用狀態(tài)圖可以揭示單個對象在整個系統(tǒng)中的變化細節(jié),對了解和實現(xiàn)關(guān)鍵類有較大的幫助。此外,還可以使用其他圖在實現(xiàn)層上從不同側(cè)面對分析階段建立的模型進行細化。用戶接口包:用戶接口包在其他包的"頂層"。在系統(tǒng)中,它為用戶提供信息和支持。由于所有與用戶的交互都是通過用戶接口實現(xiàn)的,因此UML的動態(tài)模型非常適合對GUI包的描述。圖4用順序圖描述系統(tǒng)增加新商品用例的動態(tài)模型。

14、另一種表示順序的圖是合作圖(如圖5)。 建立用戶接口是設計階段的一項特殊活動。在商業(yè)MIS中,用戶接口可以分為功能(系統(tǒng)中的主功能窗口,如采購、庫存、銷售、統(tǒng)計分析等)、信息(顯示系統(tǒng)信息的窗口以及(維護系統(tǒng)的窗口)等三部分。目前,由于可視化技術(shù)的迅速發(fā)展,用戶界面的設計相對比較簡單。一般情況下,應用系統(tǒng)的用戶界面由帶有菜單條和相應圖形的主窗口組成。(4) 實現(xiàn)構(gòu)造或?qū)崿F(xiàn)階段是對類進行編程的過程??梢赃x擇某種面向?qū)ο髮ο缶幊陶Z言(如Java)作為實現(xiàn)系統(tǒng)的軟件環(huán)境。Java很容易實現(xiàn)從邏輯視圖到代碼部件 的映射,因為類到Java代碼文件之間是一一映射關(guān)系。圖6是設計模型的部件圖,顯示邏輯視圖到

15、部件視圖的一個簡單映射。邏輯視圖中的包也映射到相應的部 件視圖中。 在實現(xiàn)階段中,可以選取下列圖的說明來輔助編程:· 類的規(guī)格說明:每個類的規(guī)格說明詳細顯示了必要的屬性和操作。· 類圖:顯示類的靜態(tài)結(jié)構(gòu)和類之間的關(guān)系。· 狀態(tài)圖:顯示類的對象可能的狀態(tài)、所需處理的轉(zhuǎn)移以及觸發(fā)這些轉(zhuǎn)移的操作。· 包含某個類的對象的動態(tài)圖(順序圖、合作圖、活動圖):顯示該類的某個方法的實現(xiàn)或別的對象是如何使用該類的對象的。· 用例圖和規(guī)格說明:顯示系統(tǒng)需求和結(jié)果。編碼期間也可能會發(fā)現(xiàn)設計模型的缺陷。這時需要開發(fā)者修改設計模型。修改設計模型時一定要保持設計模型與編碼

16、的一致性,以便將來易于維護。(5) 測試和配置完成系統(tǒng)編碼后,需要對系統(tǒng)進行測試,它通常包括:單元測試、集成測試、系統(tǒng)測試和驗收測試。在單元測試中使用類圖和類的規(guī)格說明,對單獨的類或一組類進 行測試;在集成測試中,使用組件圖和合作圖,對各組件的合作情況進行測試;在系統(tǒng)測試中,使用用例圖,以檢驗所開發(fā)的系統(tǒng)是否滿足例圖所描述的需求。系統(tǒng)的配置是實際的交付系統(tǒng),包括文檔和組成模型等。對商業(yè)MIS而言,它是一個典型的客戶/服務器系統(tǒng)。可以用配置圖顯示系統(tǒng)的物理結(jié)構(gòu),如圖7所示。 從表面上看,配置圖能顯示系統(tǒng)設備之間的關(guān)系以及顯示節(jié)點跟可執(zhí)行軟件單元的對應關(guān)系。然而一旦某個節(jié)點內(nèi)部的對象或可執(zhí)行部件過多(超過5個),就很難 完全用配置圖清楚描述這種關(guān)系。 (6) 小結(jié) 本文所舉的商業(yè)MIS系統(tǒng)的UML建模過程可以用圖8來描述。其中首先要把握的是如何使用用例技術(shù)正確描述系統(tǒng)需求。UML中的類圖描述的是系統(tǒng)中類的靜 態(tài)關(guān)系,對象圖有助于對復雜類的理解。在系統(tǒng)開發(fā)過程中,類圖可應用于分析、設計和實現(xiàn)階段。類的包化有助于進行系統(tǒng)結(jié)構(gòu)設計。商業(yè)MIS的包分為用戶接 口包、商業(yè)對象包、數(shù)據(jù)庫包,他們之間的關(guān)系是前者依

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論