應(yīng)用實例電梯調(diào)模擬器_第1頁
應(yīng)用實例電梯調(diào)模擬器_第2頁
應(yīng)用實例電梯調(diào)模擬器_第3頁
應(yīng)用實例電梯調(diào)模擬器_第4頁
應(yīng)用實例電梯調(diào)模擬器_第5頁
已閱讀5頁,還剩3頁未讀 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

1、UML程序設(shè)計實例電梯調(diào)度模擬器本章通過電梯調(diào)度模擬器的例子詳細介紹了如何利用UML進行一個實際系統(tǒng)的開發(fā)。這個系統(tǒng)的實現(xiàn)過程,遵循Rational統(tǒng)一軟件開發(fā)過程,最后用Vc+編碼實現(xiàn)。問題描述在開發(fā)任何一個系統(tǒng)之前,開發(fā)人員對所要開發(fā)的系統(tǒng)的初步理解首先是從用戶的問題描述開始的。問題描述的內(nèi)容包括系統(tǒng)的基本功能需求,用戶對系統(tǒng)的性能,外觀等特性的要求。這種描述根據(jù)開發(fā)項目的規(guī)模不同,呈現(xiàn)不同的形式。對于大的項目,問題描述可能是長達幾頁(幾十頁)的需求規(guī)格說明;對于小的項目,可能只是口頭上的幾句陳述。通過問題描述,開發(fā)人員對要開發(fā)的系統(tǒng)產(chǎn)生一個大概的印象。此實例的問題描述如下:有一座8層樓房

2、,每層提供一組按鈕(“上”或“下”),用于請求電梯的到達;每部電梯內(nèi)部提供一個控制面板,提供用戶對目標(biāo)樓層的選擇,并顯示電梯當(dāng)前所處樓層、運行方向。兩部電梯由一個調(diào)度器統(tǒng)一調(diào)度。如果沒有請求,并超過一定時限,電梯回到一樓。希望開發(fā)人員能實現(xiàn)一個電梯調(diào)度模擬器來模擬如上所述的一切,對電梯的調(diào)度準則沒有做特別要求。此外,用戶還可能會對系統(tǒng)的性能,外觀等特性提出要求,這些都需要在開發(fā)過程中加以考慮。需求分析 擬訂侯選需求在系統(tǒng)開發(fā)啟動之前,首先要對項目做一些可行性分析。在Rational統(tǒng)一軟件開發(fā)過程中,稱這個階段為初始階段。在初始階段主要是跟各方進行交流,廣泛收集信息,聽取客戶和專家的建議。并對

3、這些信息和建議進行記錄,整理得到一個后選需求列表。后選需求列表中應(yīng)包括如下各項1 名稱2 簡要說明3 狀態(tài)(建議的、批準的、并入的或證實的)4 實現(xiàn)成本估算(人小時,人月)5 優(yōu)先級(關(guān)鍵的、重要的或輔助的)6 實現(xiàn)風(fēng)險的級別(關(guān)鍵的、重要的或一般的)表1 后選需求列表名稱說明狀態(tài)成本估算優(yōu)先級風(fēng)險級別模擬控制器界面用戶通過此界面控制電梯的模擬運行證實的重要的請求電梯到達通過外部控制面板證實的重要的選擇目標(biāo)樓層通過內(nèi)部控制面板證實的重要的顯示電梯所處樓層界面證實的一般的顯示電梯運行方向界面證實的一般的合理的調(diào)度算法對電梯進行調(diào)度證實的關(guān)鍵的這時對系統(tǒng)所要實現(xiàn)的功能在整體上有了一個大致的了解。然

4、后明確哪一部分功能是系統(tǒng)中應(yīng)該實現(xiàn)的,哪一部分功能是由其它外部系統(tǒng)實現(xiàn)的。即確定出系統(tǒng)的功能范圍,并粗略估計一下項目的花費和可能得到的收益。這個階段最重要的是弄清楚啟動這個項目是不是有意義,有價值。初始階段根據(jù)項目的大小,表現(xiàn)為不同的形式。對于小的項目,可能只需要與相關(guān)人員進行一些交流和討論。而對于大的項目可能要花費幾個月的時間進行可行性分析。經(jīng)過分析,作出啟動項目的決定之后,就進入開發(fā)過程的細化階段。理解系統(tǒng)上下文建立領(lǐng)域模型如果對要實現(xiàn)系統(tǒng)所要解決的問題領(lǐng)域沒有一個清楚的了解,就不可能開發(fā)出一個滿足用戶需求的軟件。因此,進行系統(tǒng)建模時,應(yīng)首先建立領(lǐng)域模型,描述問題領(lǐng)域中的基本概念。建立領(lǐng)域

5、模型時,先不要考慮軟件是怎樣實現(xiàn)的,而只關(guān)心如何將用戶和領(lǐng)域?qū)<翌^腦中與業(yè)務(wù)過程相關(guān)的概念組織起來,并將業(yè)務(wù)過程描繪出來。所以在電梯調(diào)度模擬器這個實例中,暫不考慮用戶界面,而首先考慮把電梯的運做過程描述清楚。用戶界面的加入推遲到分析階段的后期進行。首先從問題描述和所了解的領(lǐng)域知識中抽取出可能與解決問題有關(guān)的重要概念(領(lǐng)域?qū)ο螅?。本例中通過分析問題描述提取出了這樣一些名詞(概念)。同時,為了便于理解,各名詞的修飾語也被一同標(biāo)注出來。1 樓房2 (兩部)電梯3 (每層)一組按鈕(“上”或“下”)4 (電梯內(nèi)部)控制面板5 用戶6 調(diào)度器接下來,再抽取問題描述中重要動詞短語,它們可能會成為某個類的屬

6、性或方法。1. 請求電梯的到達;2. 提供用戶對目標(biāo)樓層的選擇;3. 顯示電梯當(dāng)前所處樓層、運行方向通過對這些概念做進一步分析,不難發(fā)現(xiàn)2.電梯、3.按鈕(“上”或“下”)、4.控制面板、5.用戶、9.調(diào)度器等這些概念在電梯運做過程中都擔(dān)當(dāng)一定的職責(zé),可以把它們抽象為系統(tǒng)中的一個類?!罢埱箅娞莸牡竭_”可以作為外部控制面板的職責(zé);“提供用戶對目標(biāo)樓層的選擇”作為內(nèi)部控制面板的職責(zé);“顯示電梯當(dāng)前所處樓層、運行方向”作為電梯的職責(zé)。此外,還有1.樓房,它在電梯運做過程中不與任何其它對象交互,也不承擔(dān)任何職責(zé),也不能成為任何其它對象的屬性或方法,則把它刪除。根據(jù)以上分析,初步地找出了系統(tǒng)中的一些類實

7、體,再根據(jù)用戶或領(lǐng)域?qū)<覍﹄娞葸\做過程的描述,以及開發(fā)者本人對問題的理解,建立起這些對象之間的關(guān)聯(lián)關(guān)系。此外,根據(jù)問題描述中限定這些概念的量詞(例如:8層、兩部、一個等),還可以進一步描述它們之間的多重性關(guān)系。然后,為每個類分配職責(zé),并添加一些必要的注釋信息。這樣就建立起了這個系統(tǒng)的原始領(lǐng)域模型,如圖1所示。圖1 電梯運行系統(tǒng)領(lǐng)域模型建立業(yè)務(wù)模型至此,通過領(lǐng)域模型描述了問題領(lǐng)域中存在的重要概念,并從靜態(tài)視角描述了它們之間的關(guān)系??疾煜到y(tǒng)的動態(tài)行為是正確理解一個系統(tǒng)運做情況的關(guān)鍵。所以還需要刻畫出系統(tǒng)的動態(tài)特性。這一點通過建立系統(tǒng)的業(yè)務(wù)模型來實現(xiàn)。在這個實例中,主要通過活動圖和交互圖來描述電梯使

8、用的內(nèi)部運做過程。根據(jù)對問題的理解,建立下面的活動圖來描述乘客使用電梯過程中發(fā)生的各個活動。圖2 電梯運作之活動圖為了進一步描述領(lǐng)域?qū)ο笾g的交互關(guān)系,建立下面的順序圖描述電梯運作系統(tǒng)中各對象間的信息傳遞。圖3 電梯運作之順序圖建立詞匯表在建立領(lǐng)域模型和業(yè)務(wù)模型的同時,收集問題領(lǐng)域中的一些重要概念,建立起一個可供用戶,項目經(jīng)理、系統(tǒng)分析員、開發(fā)人員、測試人員和其他相關(guān)人員共同使用的詞匯表。這樣各種人員就可以使用共同的術(shù)語來進行討論和交流,不僅為系統(tǒng)的實現(xiàn)帶來很多便利,還可以防止因誤解而使開發(fā)的系統(tǒng)偏離用戶的真正需求。提取用例建立用例模型對系統(tǒng)運作過程有了一定了解之后,下一步開始考慮系統(tǒng)的功能。

9、通過分析業(yè)務(wù)模型找出執(zhí)行者并提取用例,建立用例模型來描述系統(tǒng)應(yīng)實現(xiàn)的功能。首先,通過分析業(yè)務(wù)模型找出系統(tǒng)的潛在用戶,即執(zhí)行者。在本實例中只有一類執(zhí)行者電梯乘客。然后,通過跟蹤執(zhí)行者與系統(tǒng)的交互行為,找出用例。在本實例中,用戶與系統(tǒng)有兩次交互,一次是按上/下按鈕,請求電梯到達,另一次是進入電梯后,通過內(nèi)部控制面板選擇目標(biāo)樓層。進一步分析,會發(fā)現(xiàn)用戶與電梯的這兩次交互都需要對電梯進行調(diào)度。因此提取出公共用例“調(diào)度電梯”。用例圖如圖4。圖4 用例圖簡單描述用例提取出用例以后,應(yīng)對每一個用例做一個簡單描述。以表明它的功能和大致的執(zhí)行流程。這個描述,在Uml_Designer中,可以通過添加注釋體來實現(xiàn)

10、,也可以寫入用例的規(guī)格說明中。例如,對調(diào)度電梯這個用例所做的簡單描述:調(diào)度電梯過程:有兩個觸發(fā)條件:Ø 用戶有請求(包括請求電梯到達和選擇目標(biāo)樓層);Ø 某個時鐘信號到達第一種情況:1 獲取用戶請求;2 獲取電梯的當(dāng)前狀態(tài);3 調(diào)度器調(diào)度,調(diào)度結(jié)果通知電梯;4 電梯運動。第二種情況:1 分析時鐘信號;2 獲取電梯當(dāng)前狀態(tài);3 調(diào)度器調(diào)度,調(diào)度結(jié)果通知電梯;4 電梯執(zhí)行調(diào)度結(jié)果。確定用例優(yōu)先級別對于大的系統(tǒng),會找到好多用例。但這些用例對所開發(fā)的系統(tǒng)來說,并不同等重要。所以確定用例的優(yōu)先級別是很必要的,對于高優(yōu)先級的用例,首先對它進行分析,設(shè)計,甚至實現(xiàn);而對于低優(yōu)先級的用例可

11、以留到后面迭帶過程中再予以考慮。那些優(yōu)先級別較高的用例就刻畫出了系統(tǒng)的體系結(jié)構(gòu)。本實例由于規(guī)模較小,所以沒有實施這一過程。但這一過程在系統(tǒng)實現(xiàn)過程中,是有著重要意義的。細化用例在這一階段,用例分析員應(yīng)與用戶密切合作,商討完成。首先描述用例執(zhí)行過程的基本路徑,然后再描述發(fā)生異常時可能會出現(xiàn)的分支路徑。對有的用例來說,文本描述就足夠了。但對于對象間交互比較復(fù)雜的用例,借助順序圖、合作圖和活動圖來描述,則更能說明問題,更易于交流。當(dāng)然,若能采用圖文并貌的方法,則更好不過了。下面的活動圖描述了調(diào)度電梯用例的一種場景。圖5 調(diào)度電梯之活動圖設(shè)計用例界面現(xiàn)在對業(yè)務(wù)執(zhí)行過程有了清楚的認識,下一步加入系統(tǒng)界面

12、。首先分析用例在與用戶進行交互時,需要用戶提供什么信息,系統(tǒng)應(yīng)向用戶返回什么信息。設(shè)計的界面應(yīng)能幫助用戶和系統(tǒng)完成這種交互。加入系統(tǒng)界面后,作為電梯模擬器系統(tǒng),它的用例才被完整的進行了考慮。在電梯運行模擬過程中,需要用戶輸入電梯到達請求和對目標(biāo)樓層的選擇,系統(tǒng)要向用戶顯示電梯運行的模擬情況,比如電梯的當(dāng)前狀態(tài)信息等。所以界面中應(yīng)能提供控件來顯示這些行為和狀態(tài)。在用例模型中增加一個新的用例:系統(tǒng)界面,執(zhí)行者相應(yīng)改為模擬器用戶。結(jié)構(gòu)化用例模型結(jié)構(gòu)化用例模型是指通過進一步分析,提取那些公用的模塊和那些可選的分支模塊,使它們單獨各自成為一個用例。然后,標(biāo)出用例間的使用和擴展關(guān)系。用例圖調(diào)整后如下圖。圖

13、6 用例圖分析在需求分析階段所做的各項工作,都是面向問題領(lǐng)域的。是為了充分的理解所要解決的問題空間,以及與各方進行交流和討論。采用的術(shù)語也都是客戶容易理解的。進入分析階段之后,所做的工作開始轉(zhuǎn)向面向?qū)崿F(xiàn)領(lǐng)域,主要是為了幫助開發(fā)者更深入的理解系統(tǒng)的實現(xiàn)。所采用的術(shù)語也逐漸轉(zhuǎn)向面向便于程序代碼的實現(xiàn)。在分析階段,所建立的模型仍然是概念層次上的。雖然是深入系統(tǒng)內(nèi)部進行分析,但分析階段并不考慮系統(tǒng)最終實現(xiàn)時的一些特性,比如:實現(xiàn)語言、操作平臺,可用構(gòu)件,用戶界面技術(shù)、數(shù)據(jù)庫技術(shù)等等。這些是設(shè)計和實現(xiàn)階段所要解決的問題。識別分析類通過分析用例圖和用例描述,找出分析類。這些分析類在用例的實現(xiàn)過程中,承擔(dān)一

14、種或幾種職責(zé)。它們相互合作共同實現(xiàn)用例描述的功能。這些分析類有一部分可以從問題域中的相關(guān)實體直接對應(yīng)得到,而其它大多數(shù)則需要通過分析抽象得到。分析類一般可以分為三種:邊界類、實體類和控制類。邊界類用于系統(tǒng)與角色之間的交互,系統(tǒng)通過邊界類向執(zhí)行者請求信息,返回和顯示信息(如用戶界面)。在此實例中,可以抽象出一個SystemInterface類,作為用戶與系統(tǒng)交互的界面。通過這個界面,用戶可以初始化模擬器、啟動模擬和終止模擬器運行。此外,通過此界面用戶還可以實現(xiàn)與內(nèi)部控制面板和外部控制面板的交互。實體類用于為系統(tǒng)長期存在的信息建模。通常情況下,實體類可由問題域中的實體直接對應(yīng)得到。此實例中如電梯,

15、內(nèi)、外部控制面板??刂祁愂窃谝粋€用例實現(xiàn)過程中協(xié)調(diào)其它對象的交互,并控制實現(xiàn)流程的一類對象。它們在用例的實現(xiàn)過程中,承擔(dān)了管理和控制的職責(zé)。本例中,Dispatcher擔(dān)當(dāng)了這樣一個角色。此外,為了防止Dispatcher負擔(dān)過大,引入一個CentralManager類來負責(zé)Dispather與其它對象的交互,比如信息的獲取,調(diào)度命令的下達等;而Dispather則專門負責(zé)電梯調(diào)度算法的實現(xiàn)。分析類如圖7所示。圖7 分析類圖接著,建立如下圖所示的順序圖,進一步描述這些類的實例間的交互協(xié)作關(guān)系和信息傳遞。圖8 電梯使用過程識別各個類的職責(zé)一個類可能在多個用例中擔(dān)當(dāng)(同種和不同種)角色:比如,Sy

16、temInterface類參與了系統(tǒng)界面、請求電梯到達和選擇目標(biāo)樓層三個用例。一個類的職責(zé)是它在不同用例實現(xiàn)中所起作用的總和。在對類的職責(zé)進行描述時,可采用非正式的文字描述形式。以電梯為例來說明。例:類的職責(zé)電梯有下面一些職責(zé):n 根據(jù)CentralManager的指示移動(包括向用戶所在樓層移動和向目標(biāo)樓層移動);n 獲取用戶對目標(biāo)樓層的選擇,并報告給CentralManager;n 通知SystemInterface進行必要的信息顯示;識別出類的職責(zé)后,重新返回到“主類圖”,給類增加相應(yīng)的方法。例如,給電梯添加方法:Move(direction);GetUserDestFloor();No

17、tifyCM();NotifySI().這時類的方法只是對其職責(zé)的描述,與最終代碼沒有直接的對應(yīng)關(guān)系,其返回類型、參數(shù)類型等不是考慮的重點,所以不必具體到實際實現(xiàn)語言中的某種類型。識別各個類的屬性在識別類的屬性時應(yīng)遵循以下原則:n 屬性名應(yīng)用一個名詞表示;n 屬性類型是概念領(lǐng)域的名稱,不必具體到實際實現(xiàn)的語言中的某種類型;n 同一個屬性不能由多個分析類共享,否則應(yīng)把這個屬性單獨成類;n 如果某個分析類過于龐大和復(fù)雜,可以把它的某些屬性分離出來,單獨成類;例:電梯的屬性theInnerControlPanel;CurrentFloor1.8;CurrentStatusWaiting,Idle,M

18、ovingUp,MovingDownCurrentOrientationUp,Down;NextStopFloor1.8等。識別類之間的關(guān)聯(lián)關(guān)系根據(jù)對問題的了解可知,樓房中有兩部電梯,由同一個調(diào)度器統(tǒng)一調(diào)度。由此在CentralManager與Elevator之間建立一個關(guān)聯(lián),并標(biāo)明多重性關(guān)系:1對2;每部電梯有一個內(nèi)部控制面板,在Elevator和InnerControlPanel之間建立一個組成關(guān)聯(lián)關(guān)系(由InnerControlPanel指向Elevator),多重性關(guān)系:1對1;此外,在CentralManager與OuterControlPanel之間建立1對8的關(guān)聯(lián)關(guān)系;Centr

19、alManager與Dispatcher之間建立1對1的關(guān)聯(lián)關(guān)系等等。分析結(jié)果見下圖。圖9 分析類圖設(shè)計設(shè)計工作主要在細化階段后期和構(gòu)造階段前期完成。設(shè)計時要充分考慮目標(biāo)語言、操作系統(tǒng)、可重用構(gòu)件、數(shù)據(jù)庫技術(shù)以及用戶界面技術(shù)等因素。設(shè)計階段采用目標(biāo)語言對類的屬性、操作、參數(shù)類型等進行描述。并標(biāo)明屬性和操作的可見性類型的信息。類之間的各種關(guān)聯(lián)關(guān)系用類中的成員變量描述出來。例如,可用定義在類中的指針變量來描述類之間的關(guān)聯(lián)和聚集關(guān)系。類中的方法在實現(xiàn)中有直接的對應(yīng)代碼。體系結(jié)構(gòu)設(shè)計系統(tǒng)的物理體系結(jié)構(gòu)對系統(tǒng)軟件體系結(jié)構(gòu)有著重要的影響。因此,設(shè)計階段的首要任務(wù)是識別出系統(tǒng)中的物理節(jié)點和它們的設(shè)置情況。包

20、括:系統(tǒng)中包含哪些節(jié)點?它們之間如何連接,采用什么通信協(xié)議?對于此實例來說,所有可執(zhí)行部件都在一個PC機上,因此,沒有實施配置圖。識別設(shè)計類首先,由分析類勾畫出設(shè)計類的大致輪廓。比如對于邊界類可以設(shè)計它為對話框、菜單或其它控件;對于實體類可以把它設(shè)計為某種數(shù)據(jù)庫技術(shù)。處理控制類相對比較復(fù)雜,一般要考慮它的分布式問題,性能問題等。然后,識別出設(shè)計類的操作和屬性。從相應(yīng)分析類的職責(zé)中可以識別設(shè)計類的操作。有時,可能需要將分析類的一種職責(zé)分解為多個操作來實現(xiàn)。設(shè)計類的操作用目標(biāo)語言來描述。以電梯為例:Elevator需要向CentralManager匯報當(dāng)前狀態(tài)、運行方向、當(dāng)前所處樓層等信息。給電梯

21、類增加GetCurrentStatus(), GetCurrentDirection(), GetCurrentFloor(), GetNextStopFloor()等操作來完成這些功能此外,通過分析類的狀態(tài)轉(zhuǎn)變,也可以識別出類的操作。電梯狀態(tài)圖如圖10。圖10 電梯狀態(tài)圖電梯有Waiting, Idle, MovingUp, MovingDown ,等狀態(tài),為電梯加入Initialize方法在模擬器運行之前對其狀態(tài)進行初始化;加入Start(), Stop(), BeginWait(), EndWait(), BeginIdle(),EndIdle()等方法來實現(xiàn)電梯狀態(tài)的轉(zhuǎn)換。對于設(shè)計類屬性的識別,一般從相應(yīng)分析類屬性可以直接對應(yīng)得到設(shè)計類的屬性。電梯類的操作和屬性如圖11。圖11 電梯的操作和屬性根據(jù)類似的方法,可以逐個識別出其它幾個類的操作和屬

溫馨提示

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

評論

0/150

提交評論