《大學選課系統(tǒng)的分析與設計—— UML應用案例》由會員分享，可在線閱讀，更多相關《大學選課系統(tǒng)的分析與設計—— UML應用案例（23頁珍藏版）》請在裝配圖網上搜索。

1、大學選課系統(tǒng)的分析與設計,UML,應用案例,本文主要以“學生注冊討論班為例，運用UML建模語言對大學的選課系統(tǒng)進行了分析。從問題分析到最后的系統(tǒng)設計，主要從以下幾個方面進行了陳述：,問題描述,需求分析,靜態(tài)建模,動態(tài)建模,組件建模,部署建模,一、問題描述,大學選課系統(tǒng)是與學生有著緊密的聯(lián)系，具有注冊、交費、選課、成績查詢等功能,為了簡化本次系統(tǒng)分析只考慮學生注冊討論班的功能，該問題描述如下：,學生想要注冊某門討論班，于是向注冊員提交其姓名和學生編號；,注冊員驗證該學生是否有資格注冊這門討論班；,注冊員驗證后，提供討論班列表，并驗證是否適合學生的課程安排；,注冊員統(tǒng)計費用并通知學生；,在學生確認

2、后，注冊員將該學生注冊到討論班，并將費用參加學生帳單；,注冊員向學生提供注冊成功確實認信息。,根據(jù)以上問題描述，該簡化系統(tǒng)應具有如下功能：,學生搜索、注冊討論班,驗證注冊資格,顯示討論班及相關信息,提供成績單,結算并顯示帳單,注冊成功,關閉注冊,返回,二、需求分析 采用用例驅動的方法分析需求的主要任務是識別參與者和用例，并建立用例模型，主要分為以下三個局部。,識別參與者,識別用例,確定事件流,返回,一識別參與者角色,參與者表示與系統(tǒng)進行交互的任何人或物。可以包括人不只是最終用戶、外部系統(tǒng)和其它機構。,通過分析選課系統(tǒng)的功能需求，確定有以下三個參與者：,1學生：在系統(tǒng)中申請注冊討論班的人,2注冊

3、員：完成驗證注冊信息的人或外部系統(tǒng),3教授：指導或協(xié)助討論班和管理學生成績,返回,二識別用例用況,用例是一系列活動，描述真實世界中參與者與系統(tǒng)相互交互的方式。,通過分析選課系統(tǒng)的功能需求，確定有如下用例：,1注冊討論班,2退出討論班,3參加討論班,4完成討論班,5通知學生方案改變,6分發(fā)成績單,7輸出收費方案表,8輸入成績,9指導討論班,10生成教學進度,系統(tǒng)的用例圖如下所示：,返回,三用例的事件流描述,用例還可以事件流來描述，用例的事件流是對完成用例行為所需的事件的描述。事件流描述了系統(tǒng)應該作什么，而不是描述系統(tǒng)應該怎樣做。,學,生,注冊員,1,學生想去注冊討論班。,3,注冊員確定該學生是否

4、有資格在這所學校注冊討論班。,2,學生向注冊員提交其姓名和編號,4,學生從可供選擇的討論班列表中，選出他希望注冊的討論班。,4,學生從可供選擇的討論班列表中，選出他希望注冊的討論班。,5.,注冊員驗證學生是否有資格注冊這門課。,6.,注冊員檢驗討論班是否適合學生已有的課程安排,7.,注冊員根據(jù)討論班目錄中公布的費用、適用的學生費用和適用的稅，計算出這門課的收費。,8.,注冊員通知學生相關費用。,9.,注冊員確認學生表示愿意注冊該討論班。,10.,學生表示愿意注冊該討論班。,14.,當學生得到確認信息時用況結束,11.,注冊員把學生注冊到該討論班。,12.,注冊員把相應的費用加到學生賬單中。,1

5、3.,注冊員向學生提供已經注冊成功的確認。,名稱：注冊討論班,描述：把現(xiàn)有的有資格的某一學生注冊到某個討論班。,前提條件：學生已在大學注冊。,后置條件：如果學生具有注冊資格，并且該討論班仍有空位，那么學生注冊到該討論班。,活動的根本過程：,事件流續(xù)表：,候選過程A：學生沒有資格注冊討論班。,A3.注冊員確定學生沒有資格注冊討論班。,A4.注冊員通知學生，她沒有資格注冊。,A5.用況結束。,候選過程B：學生不具備注冊這一討論班所需要的必備條件。,B5.注冊員確定學生沒有資格注冊該討論班。,B6.注冊員通知學生，她不具備注冊這一討論班所需要的必備條件,B7.注冊員通知學生，她需要具備的條件。,B8

6、.用況從活動根本過程中的步驟4繼續(xù)執(zhí)行。,候選過程C：學生決定不注冊討論班，雖然有討論班可供其選擇。,C4.學生查看討論班列表，但沒有找到他想要注冊的項。,C5.用況結束。,根據(jù)事件流描述，活動框圖如下所示：,返回,三、靜態(tài)建模,進一步分析系統(tǒng)需求，發(fā)現(xiàn)類以及類之間的關系，確定它們的靜態(tài)結構和動態(tài)行為，是面向對像分析的根本任務。,系統(tǒng)的靜態(tài)結構模型主要用類圖和對象圖描述。,靜態(tài)建模主要分為兩步：,1定義類,2確定類的名字、屬性和操作，建立類圖。,返回,一定義類,該系統(tǒng)主要有三種類型的類：,參與者類actor class)：代表出現(xiàn)在用況中的參與者,用戶界面類(user interface cl

7、ass)：組成系統(tǒng)用戶界面的屏幕顯示、菜單和報表，即UI元素,業(yè)務類(business class)：描述業(yè)務的地點、物品、概念和事件,在靜態(tài)建模中用類模型表示概念模型，而著手進行概念模型的最簡單的方法是把領域模型作為設計根底，于是要采用類-職責-協(xié)作CRC模型并把它直接轉換成類圖,CRC卡片的布局如以下圖所示：,該系統(tǒng),CRC,模型如下,該列為參與者類,該列為業(yè)務類,該列為用戶界面類,返回,二類圖,識別出系統(tǒng)中的類后，還要識別出類間的關系關聯(lián)、聚合、組合、類屬、依賴、實現(xiàn)關系，前面已講過，然后就可以建立類圖了。,在處理復雜問題時，通常使用分類的方法來有效地降低問題的復雜性。在面向對象建模技術

8、中，也可以采用同樣的方法將客觀世界的實體映射為對象，并歸納成類。類、對象及它們之間的關系是面向對象技術中最根本的元素。類圖是面向對象系統(tǒng)最常用的圖，類圖描述了類集、接口集、協(xié)作及它們之間的關系。,類間的關系如以下圖所示：,用戶界面包中有如下三個類：,1.成績單,2.注冊討論班,3.平安登錄,返回,四、動態(tài)建模,動態(tài)模型描繪了參與每個用例的對象之間的交互。開發(fā)動態(tài)模型的起點是用例以及在對象構建期間決定的對象。通常使用協(xié)作圖來描繪滿足用例需要的對象間消息通信，針對單個類實例的行為，用狀態(tài)圖描繪該類狀態(tài)的改變。,狀態(tài)圖,：為依賴狀態(tài)展示不同行為的類開發(fā)狀態(tài)圖,協(xié)作圖,：描繪對象間交互的鳥瞰視圖,返回

9、,狀 態(tài) 圖,返回,協(xié) 作 圖,返回,五、組件建模,組件建模的目標,把系統(tǒng)中在類分布到更大的內聚的組件當中。重構refactor傳統(tǒng)的對象設計，以便將其作為組件進行部署。為了能夠把對象設計組件化，需要執(zhí)行五個步驟，通常這五個步驟是迭代執(zhí)行的：,1處理非業(yè)務/領域類。,2定義類契約。,3簡化繼承與聚合的層次結構。,4確定領域組件。,5定義領域組件契約。,組 件 圖,返回,六、部署建模,以下圖給出了學生選課系統(tǒng)的UML部署圖。三維方框代表節(jié)點，比方計算機和交換機，結點之間的連接用簡單的直線表示，在該圖中構造型指出了瀏覽器和應用效勞器的連接使用 協(xié)議，而應用效勞器與數(shù)據(jù)效勞器之間的連接使用Java的遠程方法調用RMI協(xié)議。,