1、重慶郵電學院軟件學院面向對象分析與設計實驗參考資料重慶郵電學院軟件學院 實驗中心目 錄一、課程編號3二、課程類型3三、本課程的地位、作用與任務3四、課程基本要求3五、實驗安排3實驗1：實驗準備31實驗器材32rational rose安裝步驟3實驗2：用例分析與設計41、實驗目的42、實驗內容43、實驗步驟44、實驗報告要求9實驗3：類圖的設計91實驗目的92實驗內容93實驗步驟9實驗4：狀態圖101實驗目的102實驗內容103實驗步驟10實驗5：時序圖161實驗目的162實驗內容163實驗步驟16實驗6：協作圖221實驗目的222實驗內容223實驗步驟22實驗7，8：綜合設計實驗251實驗目

2、的252實驗內容253實驗步驟25六、教材26七、成績考核辦法26八、附A：完整UML建模過程例子26面向對象分析與設計一、課程編號本科軟件工程二、課程類型課程類型：必修課。適用專業：軟件工程試驗學時：1024學時三、本課程的地位、作用與任務計算機軟件建模技術現在越來越廣泛的應用于軟件工程中。面向對象系統分析設計課程實驗的目的是為了使學生在課程理論學習的同時，通過在一個實踐的環境下，實際學習軟件統一建模語言，對軟件建模技術有一個初步的了解及認識。通過本指導書中的各個實驗，學習掌握對一般面向對象系統建模的方法與技術。總之，通過上述實驗環節，使學生加深了解和更好地掌握課程教學大綱要求的內容。四、課

3、程基本要求1、 學生應根據每個上機試驗的任務和教師所提的要求，上機前準備好上機內容。2、 上機時要針對一個實際的案例進行分析，畫出不同的階段UML圖。3、 上機結束后應按時提交試驗報告，對于上機未完成部分，應該下機后利用課余時間完成。五、實驗安排實驗1：實驗準備1實驗器材1計算機一臺。2建模工具軟件。2rational rose安裝步驟（1）運行安裝軟件；（2）單擊下一步，選擇rational rose enterprise edition；（3）單擊下一步，選擇desktop installation from cd image ，表示創建一個本地的應用程序而不是網絡的；（4）隨后根據提示進

4、一步操作，完成安裝，注冊；（5）運行rational rose，進入主界面，new表示新建模型，existing表示打開現有，recent表示最近打開模型；（6）熟悉模型的創建，保存，發布。實驗2：用例分析與設計1、實驗目的1熟悉用例圖的基本功能和使用方法。2掌握如何使用建模工具繪制活動圖方法。2、實驗內容1. 根據某圖書館的圖書管理系統開發進度，在完成對系統的需求建模，得到用例模型后，應針對每個用例進行業務分析，說明其具體的業務流程，現系統分析部指派您完成該項任務。要求：2. 對其中主要功能的用例書寫書面用例。3、實驗步驟書寫“刪除讀者信息”用例的書面用例。一般應包含以下信息：（1）管理員在

5、錄入界面，輸入待刪除的讀者名；（2）“業務邏輯”組件在數據庫中，查找待刪除的讀者名；（3）如果不存在，則顯示出錯信息，返回步驟（1），如果存在則繼續；（4）“業務邏輯”組件判斷“待刪除的讀者”是否可以刪除；（5）如果不可以，則顯示出錯信息，返回步驟（8），如果可以則繼續；（6）在數據庫中，刪除相關信息；（7）顯示刪除成功信息；（8）結束。分析:在圖書管理系統中,管理員首先登錄系統,系統驗證通過后,管理方可向系統查詢數據,在查詢后,系統會給出提示,有沒有找到相關的數據,管理員根據系統查詢的返回結果,進行下一步的操作,就是刪除讀者,在刪除的過程中,系統會對查詢得到的結果判斷該記錄是否可以刪除,若可

6、以刪除,則給刪除提示,若不能刪除,也給相關的提示信息。繪圖步驟:(1)在用例圖上雙擊main,出現如圖2.1所示,為繪制用例圖做好準備。圖2.1(2)在圖中的工具欄選取Actor圖標，在右邊的圖中添加一個Actor，并輸入名稱:administrator,如圖2.2所示。(3)在左邊的工具欄中，選取用例的圖標，在右邊的圖中畫出一個用例，并輸入用例的名稱：login 。 圖2.2（4）按照步驟（3），繪制出如圖2.4和圖2.5的兩個用例。 圖2.3 圖2.4圖2.5（5）在繪出了用例后，接下來的是繪制參與者與用例實現，如圖2.6所示。圖2.6（6）根據步驟（5），同時完成如圖2.7和圖2.8。此

7、時，刪除讀者用例圖就到此完成。其系統查詢讀者信息等其他的功能會在時序圖和活動圖中描繪。（7）根據分析情況，進一步添加或細化用例圖。圖2.7圖2.84、實驗報告要求1可以細化、完善或者修改給出的例子，分析和設計用例圖，寫出實驗步驟，整理實驗結果。實驗操作和步驟盡量詳盡，并且按照指導書給出的范例，適當進行需求和系統分析，做出的各種框圖需要在實驗報告中畫出來，可以打印。2 小結實驗心得體會，對于遇到的問題給予分析。實驗3：類圖的設計1實驗目的1. 掌握使用rose畫類圖的步驟。2. 掌握類圖的基本語法。2實驗內容1. 根據圖書管理系統的需要分析，用例圖，交互圖，對系統進行靜態建模，尋找和發現類，分析

8、類之間的關系；3實驗步驟1打開前面初步構建的UML模型文件;2打開Rose中的邏輯視圖（Logical View），選擇分析模型（analysis model）目錄。并在其下創建一個子目錄并命名為：“圖書館業務功能”。3用鼠標右擊“圖書館業務功能”在彈出來的菜單中選擇“NewClass diagram”項，創建類圖。4雙擊新建的類圖，并點右邊控件集中選中的類并用鼠標在圖中分別拖出上述類圖。5設定上述抽象出來各類的屬性和操作。6分析、設定以上各類之間的關系。7請根據教材中示例部分在Rational Rose中繪制類間的關系。注意：這里沒有具體的相關的例子；實驗4：狀態圖1實驗目的1熟悉狀態圖的基

9、本功能和使用方法。2掌握如何使用建模工具繪制狀態圖方法。2實驗內容1. 通過某圖書館的圖書館管理系統的需求的初步分析，得出系統的用例圖和相應的活動態。通過這兩類圖我們可以初步了解系統的業務處理過程，但對業務處理過程的處理狀態間轉換了解仍不夠，這不利于設計人員對系統業務的進一步理解，而狀態圖能從對象的動態行為的角度去描述系統的業務活動。因此，指派你運用本節所學的狀態圖，完成如下任務：2. 完成圖書業務模塊中還書用例的狀態圖。3實驗步驟1業務分析：對圖書館管理系統中的還書主要業務的描述和分析可知，還書業務的動態行為是由：空閑（idle）、圖書查找（finding）、還書（reversion）、失敗

10、（Failure）、歸還成功（Success）5種狀態及激活相互轉換的事件。2繪制狀態圖：請您根據分析運用UML繪制還書用例的狀態圖。分析：還書的狀態圖，還書的主要業務都是由管理員來完成，首先管理員必須先登錄系統，并通過驗證后，便可以進行下一步的操作，查找該書的相關信息，如存在，則進行還書操作，如不存在該信息，則給出提示信息；繪圖步驟：（1）在用例圖中的還書（revesion）用例，單擊右鍵，如圖3.15所示，新建一個狀態圖，命名為revesion狀態圖，圖3.16所示。圖3.15圖3.16（2）雙擊“receivesion”狀態圖，展開后，在左邊的工具欄上選取一個實心圓點，此結點為開始結點，

11、圖3.17所示；當還書的時候，操作者先要詢問系統的狀態，如果系統忙，操作者則必需等待，因此，得到系統的兩種狀態，如圖3.19所示。圖3.17圖3.18圖3.19（3）操作者在詢問系統和狀態后，得到的圖3.20所示兩種狀態，如果系統忙，操作者必需要等待、結束，如圖3.21和圖3.22所示，重返步驟（1）。圖3.20圖3.21圖3.22（4）如系統空閑，則進行對還書的信息進行查詢操作，圖3.23所示；查詢也有兩種結果，一是查詢得到該書的相關信息，二查詢不到該書的相關信息；則此時有兩種狀態，需要建立兩種狀態，如圖3.25所示。圖3.23圖3.24（5）最后，操作者進行了操作后，系統會給出操作的結果給

12、操作者；操作成功或失敗，都會有提示信息給出。整個的還書的過程便完成；實驗5：時序圖1實驗目的1理解時序（順序）圖的基本概念。2掌握在Rational Rose中繪制時序圖的操作方法。2實驗內容1. 對圖書的相關操作完成時序圖；3實驗步驟1分析：根據對圖書業務功能模塊中的時序圖操作進行動態建模的操作步驟和方法，請你對書籍管理模塊中的交互操作進行動態建模。該模塊中主要存在新增書籍、修改書籍信息和刪除書籍三種交互操作。2請根據教材中示例部分在Rational Rose中繪制上述的交互圖。繪圖步驟：（1）在Rose軟件的左邊欄目上的Logicl View單擊右鍵，新建一個時序圖，時序圖是交互圖一種表示

13、，可以用時序來表示，如圖4.1；在此，先單間介紹一下用法：圖中的直線箭頭是發送消息；虛線箭頭是返回消息；曲折線是對象自己給自己發送消息并調用。 （2）接下來的是添加類，系統中的類是其他的方法的邊界，在上面做好的類找到可以直接拖拉來圖中，見圖4.2 和圖4.3所示。圖4.1圖4.2圖4.3（3）添加類后，便可以添加方法了，開始是必需是外面的實體向系統發送消息，如圖4.4所示，是管理員登錄時向系統發送的消息；圖4.4（5）可以按上一步的方法來完成其他的方法，如viladate（驗證）,返回驗證結果，當用戶收到結果后，可以正常登錄后便能進行增加圖書見圖4.5到圖4.9。最后得到的時序圖如圖4.10所

14、示。圖4.5圖4.6圖4.7圖4.8圖4.9圖4.10實驗6：協作圖1實驗目的1理解協作圖的基本概念。2掌握在Rational Rose中繪制協作圖的操作方法。2實驗內容1. 通過對教學內容的學習，使我們完成了某圖書館的管理系統的需求分析，并從業務對象中抽象出了類?，F在需要對前面所給出的用例進行實現，主要是對書籍管理功能畫協作圖。3實驗步驟1分析：根據上面的時序圖，我們也可以圖出協作圖。2請根據上面時序圖部分在Rational Rose中繪制協作圖。繪圖步驟： (1)完成了時序圖后，可以按F5鍵便得到增加圖書的協作圖，也可以畫出圖4.11這樣的協作圖。圖4.11（7）剩下的更新圖書信息和刪除圖

15、書信息的交互圖在此不再一一詳細的介紹，其繪圖方法跟繪制增加圖書的方法一樣，最后得到見圖4.12 到圖4.15圖4.12圖4.13圖4.14圖4.15實驗7，8：綜合設計實驗1實驗目的1掌握用Rational Rose進行軟件建模。2實驗內容1. 對一個系統進行建模。3實驗步驟1. 對系統進行完整的建模。生成其用例圖，狀態圖，活動圖，時序圖以及協作圖。鼓勵創新。2. 可以選擇的系統有：本科生教務系統，圖書管理系統，編譯器，博客，即時通信軟件等等。六、教材實驗教材以本實驗指導書為參考；七、成績考核辦法采用綜合實驗與撰寫報告綜合評分八、附A：完整UML建模過程例子基于UML的面向對象分析與設計案例介

16、紹 本文以實例的方式，展示了如何使用UML進行面向對象的分析與設計。本文將假設讀者對UML、面向對象等領域的基本內容已了然于胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的實例，展現基于UML的OOA&D過程的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。 經常聽到有朋友抱怨，說學了UML不知該怎么用，或者畫了UML卻覺得沒什么作用。其實，就UML本身來說，它只是一種交流工具，它作為一種標準化交流符號，在OOA&D過程中開發人員間甚至開發人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現形式，可以說“OO是神，而UML是型”。所以，想

17、用好UML，扎實的OO思想基礎是必不可少的。然而，在UML應用到開發過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啟發式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統的分析設計實例，看看如何將UML應用到實際的開發中。1.從需求到業務用例圖 OOA&D的第一步，就是了解用戶需求，并將其轉換為業務用例圖。我們的CMS系統需求非常簡單，大致課做如下描述：這個系統主要用來發布新聞，管理員只需要一個，登錄后可以在后臺發布新聞。任何人可以瀏覽新聞，瀏覽者可以注冊成為系統會員，注冊后可對新聞進行評論。管理員在后臺可以對新聞、評論、注冊會員進行管理

18、，如修改、刪除等。 通過以上需求描述，我們畫出如下的業務用例圖： 這里要注意三點： 1.業務用例是僅從系統業務角度關注的用例，而不是具體系統的用例。它描述的是“該實現什么業務”，而不是“系統該提供什么操作”。例如，在實際系統中，“登錄”肯定要作為一個用例，但是這是軟件系統中的操作，而用戶所關注的業務是不包含“登錄”的。 2.業務用例僅包含客戶“感興趣”的內容。 3.業務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什么意思，它也許就不適合作為業務用例。2.從業務用例圖到活動圖 完成了業務用例圖后，我們要為每一個業務用例繪制一幅活動圖?；顒訄D描述了這個業務用例中，用戶可能會進行的

19、操作序列?；顒訄D有個很重要的使命：從業務用例分析出系統用例。例如，下面是“新聞管理”的活動圖： 可以看到，一個“新聞管理”這個業務用例，分解出N多系統操作。這里要特別注意這些操作，其中很多“活動”都很可能是一個系統用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統中至少要包含以下備選系統用例：登錄、注銷登錄、查看新聞列表、修改新聞、刪除新聞。 這樣，將每個業務用例都繪制出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統用例。3.從活動圖到系統用例圖 找出所有的備選系統用例后，我們要對他們進行合并和篩選。合并就是將相同的用例合并成一個，篩選就是將不符合系統用例條件的備選用例去掉

20、。 一個系統用例應該是實際使用系統的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統用例，因為他只是某系統用例的一個序列項。 最終我們得出的系統用例圖如下：4.從系統用例圖到用例規約 得出系統用例圖后，我們應該對每一個系統用例給出用例規約。關于用例規約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規約唯一的要求就是“清晰易懂”。 下面給出“登錄”這個系統用例的一個規約：5.繪制業務領域類圖 完成了上面幾步，下面應該是繪制業務領域類圖了。所謂業務領域類圖要描述一下三點： 1.系統中有哪些實體。 2.這些實體能做什么操作。 3.實體間的關系。 這里要特別強調：這里的實體不

21、是Actor，而是Actor使用系統時使用的所調用的實體，是處在系統邊界之內的實體。例如，管理員就沒有作為一個實體出現在這里，因為管理員處在系統邊界之外，它所有的工作都可以通過調用這三個類的方法完成。并且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統內的業務實體，供Actor們使用的。例如，其中的注冊功能是給注冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。 理解以上這段話非常重要，我經常看到由于混淆了實體和Actor的關系而導致畫出的領域類圖不準確或職責分配不準確。大家可能還注意到，我們這里沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性并不重要，重要的是找出實體的操作。 6.繪制實現類圖 以上這幾步，就是分析的過程。而下面的步驟就是設計了。 設計沒有分析那么好描述，因為分析是“客戶面”，它只關心系統本身的功能和業務，而不關心任何和計算機有關的東西。但是，設計和平臺、語言、開發模型等內容關系緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現類圖是要繪制的。 實現類圖和領域類圖不一樣，它描述的是真正系統的靜態結