1、可視化建模與UML I課程項目指導書軟件工程系一：完成自擬項目的需求分析（一）基本信息本次實踐是自擬項目（三級項目）。對自擬項目進行需求分析，構建用例模型解決該問題。1、類型： 綜合類 設計類 創新類 驗證類2、學時安排：課上2學時。3、教學目標：（1）理解用例模型對需求建模的重要性；（2）識記構建用例圖的方法，并能夠熟練運用用例圖完成對系統的需求分析。（3）識記書寫用例描述的關鍵點，完成對每個用例的分析和描述。（二）組織形式課上完成本次實踐的內容，采取分小組的方式，每組35人，包括1名組長。由組長負責分配工作。（三）任務描述每個小組自擬題目，完成該項目的需求分析，要求使用工具StarUML完

2、成系統的總體用例圖，并且對于關鍵用例要給出對應的用例描述。（三）指導內容1、相關知識：（1）用例圖 識別參與者：參與者（也可以稱為角色，Actor）是系統外部的一個人或者物，它以某種方式參與了系統的執行過程。參與者不是特指人，是指系統以外的，在使用系統或與系統交互中所扮演的角色。因此參與者可以是人，可以是事物，也可以是時間或其他系統等等。參與者之間也可以象類一樣存在泛化關系。用例：用例是代表系統中各個項目相關人員之間根據系統的行為所達成的契約。用例描述了在不同條件下，針對某一項目相關人員的請求，系統對其作出的響應。用來描述參與者可以感受到的系統服務或功能。用例和用例之間的關系：用例除了與參與者

3、有關聯關系外，用例之間也存在著一定的關系，如泛化關系、包含關系、擴展關系等。例1：例2：（2）用例描述用例描述的組成部分：用例標識用例名稱涉及的參與者用例概述前置條件（Preconditions）后置條件（Postconditions）事件流（Flow of events）基本流程，不考慮異常；分支流程（Subflows）例1：用例標識UC1用例名稱上傳課件參與者教師前置條件確認教師身份后置條件系統增加了新的課件信息用例概述教師將該課程的課件上傳到服務器上。基本事件流參與者動作系統動作1.教師確認要上傳的課件信息。2.系統檢查該課件信息的有效性。3.系統從本地提取課件到服務器。4.系統將課件信

4、息保存到相應位置，并提示保存成功。備選事件流2.a 如果課件格式不符合要求，系統提示此信息，并返回到步驟1.3.a 如果提取信息失敗，提示此信息，返回到步驟1.4.a 如果保存信息失敗，提示此信息，返回到步驟1.備注服務器將記錄每次上傳的時間。（3）其他知識資源詳細內容請參見第4章 用例與用例圖的PPT或者 教材P51-P68 。2、過程與步驟：第一步：分析項目需求，識別出參與者。第二步：分析系統功能，識別出用例。第三步：分析參與者之間的關系。第四步：分析用例之間的關系。第五步：繪制整體用例圖的草圖。第六步：優化并調整用例圖。第七步：采用工具StarUML畫出系統的用例圖，具體過程 Use C

5、ase Modeladd Usecase Diagram，創建參與者actor和用例usecase。完成之后將用例圖粘貼到需求報告中。第八步：對用例進行優先級排序。第九步：對優先級高的用例完成用例的詳細描述。（四）成果提交組長將該小組的項目內容匯總到一個word文檔中，形成一份完成的需求報告。小組成員每人提交一份該完整的需求報告，注明提交人的姓名、學號和任務分工。需求報告中必須包含系統總體用例圖和核心用例的用例描述，其余部分可以適當增加，比如項目概述等。（五）考核方式與標準1、考核方法（1）評閱項目報告；（2）課堂檢查小組項目的完成情況。2、考核標準本次實踐占形成性考核成績中的10分。標準：能

6、根據系統的概述完成系統的整體用例圖，并對核心用例能夠進行詳細描述。成績構成：小組得分+個人得分。小組得分共5分。（1）任務分工合理，小組合作默契，系統選題新穎、分析透徹，給4-5分。（2）部分同學參與度低，小組合作欠佳，選題普遍，分析不夠透徹，給2-3分。（3）主要工作全由組長一人完成，小組合作極差，選題陳舊，分析停留在表面，給0-1分。個人得分共5分。根據需求報告中小組成員的任務完成情況，給與適當的分數。（1）用例圖中參與者和用例的識別全面、正確，命名規范，關系正確；用例描述詳細、流程正確，給4-5分。（2）用例圖中參與者或用例識別不夠全面、正確，或者命名不符合規范，或者部分關系不正確；用例

7、描述，不夠詳細，缺少關鍵流程，給2-3分。（3）用例圖中缺少關鍵參與者或者關鍵用例，參與者和用例命名隨意，不符合規范，用例間關系不正確；用例描述流于頁面，沒有深入系統內部，或者沒有給出分支流程的描述，給0-1分。說明：如附加其他部分，可以酌情加分。二：完成自擬項目的設計報告（一）（一）基本信息本次實踐是自擬項目（三級項目）。對自擬項目進行系統設計，構建系統的順序圖和分析類圖。1、類型： 綜合類 設計類 創新類 驗證類2、學時安排：課上2學時。3、教學目標：（1）理解順序圖和分析類圖對設計建模的重要性；（2）識記構建順序圖的方法，并能夠熟練運用順序圖來完成系統的對象設計。（3）識記構建分析類圖的

8、方法，并能夠熟練的構建系統的類圖。（二）組織形式課上完成本次實踐的內容，采取分小組的方式，每組35人，包括1名組長。由組長負責分配工作。（三）任務描述每個小組根據上次實踐課自擬項目的需求分析報告，完成該項目的系統設計（一）報告，要求使用工具StarUML完成該系統的順序圖和分析類圖建模。（三）指導內容1、相關知識：（1）順序圖 順序圖（Sequence Diagram） 順序圖：強調消息的時間順序的交互圖。圖形上是一張表，對象沿X軸排列，消息沿Y軸按時間順序排列。順序圖描述了對象之間傳送消息的時間順序，它用來表示用例中的行為順序。三類對象：邊界對象、實體對象、控制對象。 狀態圖中的基本概念：O

9、bject (包括actor實例)、Lifeline (生命線)、Focus of control(控制焦點)、activation(激活期)、Message(消息)。 例1、查詢書籍用例對象的順序圖。 （2）分析類圖 分析類圖（Class Diagram） 類圖：構建分析類圖，完成系統內部類的初步設計。類是對一組具有相同屬性、操作、關系和語義的對象的抽象。類圖是用來顯示系統中的類、接口以及它們之間的靜態結構和關系的一種靜態模型，它用于描述系統的結構。類圖的建模貫穿系統的分析和設計階段的始終。類圖中的基本概念：名稱部分（Name）、屬性部分（Attribute）和操作部分（Operation）

10、。類之間的關系：是指事物之間的聯系。在面向對象的建模中，類之間最常見的關系有：依賴關系、泛化關系、關聯關系和實現關系。 例1、查詢圖書用例對象順序圖對應的分析類圖。 （3）其他知識資源詳細內容請參見第5章 類圖和對象圖的PPT或者 教材P69-P92，第6章 順序圖和通信圖的PPT或者 教材P93-P115 。2、過程與步驟：第一步：根據需求分析報告中，高優先級用例的用例描述，識別出每個用例中的三類對象。第二步：識別出三類對象間傳遞的關鍵消息。第三步：繪制每個用例描述的順序圖草圖。第四步：修改順序圖草圖。第五步：采用工具StarUML畫出每個用例的順序圖，具體過程“雙擊” Analysis M

11、odelmain，創建三類對象：Entity、Boundary、Controller，并完成每類對象的命名。第六步：創建順序圖 Analysis Modeladd SequenceDiagram，將上一步已經創建好的三類對象拖拽到順序圖中。將三類對象的顯示方式改為圖像方式：Ctrl+A，Ctrl+Shift+I。完成對象間消息的傳遞，注意返回消息修改右下角“General屬性框中的ActionKind屬性，改為return消息即可”。完成之后將順序圖粘貼到設計報告一中。第六步：分析并識別該順序圖中關鍵類。第七步：識別每個類中的屬性和方法，并設置屬性和方法的可見性。第八步：繪制每個分析類圖的草圖

12、。第九步：修改分析類圖。第十步：采用工具StarUML該順序圖的分析類圖，具體過程 Design Modeladd Class Diagram，創建類class。完成之后將分析類圖粘貼到設計報告一中。（四）成果提交組長將該小組的項目內容匯總到一個word文檔中，形成一份完成的設計報告一。小組成員每人提交一份該完整的設計報告一，注明提交人的姓名、學號和任務分工。設計報告一中必須包含系統中高優先級用例的順序圖和該用例對應的分析類圖，其余部分可以適當增加，比如界面設計等。（五）考核方式與標準1、考核方法（1）評閱項目報告；（2）課堂檢查小組項目的完成情況。2、考核標準本次實踐占形成性考核成績中的10

13、分。標準：能分析出高優先級用例的用例描述中的三類對象和消息，完成該用例的順序圖，給出該用例對應的分析類圖。成績構成：小組得分+個人得分。小組得分共5分。（1）任務分工合理，小組合作默契，全組順序圖的風格一致且全部正確，給4-5分。（2）部分同學參與度低，小組合作欠佳，小組內順序圖的風格不一致，部分順序圖不正確，給2-3分。（3）主要工作全由組長一人完成，小組合作極差，小組內順序圖的風格迥異，基本全部錯誤，給0-1分。個人得分共5分。根據設計報告二中小組成員的任務完成情況，給與適當的分數。（1）順序圖中三類對象和關鍵消息識別正確，消息傳遞符合規范，圖形符號正確；分析類圖中類抽取正確，屬性和方法設

14、置合理，類間關系設置正確，圖形符號正確，給4-5分。（2）順序圖中三類對象和關鍵消息識別部分錯誤，消息傳遞基本符合規范，圖形符號基本正確；分析類圖中類抽取基本正確，屬性和方法設置部分不合理，類間關系設置基本正確，圖形符號基本正確，給2-3分。（3）順序圖中三類對象和關鍵消息識別存在錯誤，消息傳遞不合理，圖形符號錯誤；分析類圖中類抽取存在錯誤，屬性和方法設置不合理，類間關系設置不正確，圖形符號不正確，給0-1分。說明：如附加其他部分，可以酌情加分。三：完成自擬項目的設計報告（二）（一）基本信息本次實踐是自擬項目（三級項目）。對自擬項目進行系統設計，構建系統的狀態圖和活動圖。1、類型： 綜合類 設

15、計類 創新類 驗證類2、學時安排：課上2學時。3、教學目標：（1）理解狀態圖和活動圖設計建模的重要性；（2）識記構建狀態圖的方法，并能夠熟練運用狀態圖完成對某個對象的狀態分析與設計。（3）識記構建活動圖的方法，并能夠熟練運用活動圖完成對某個工作流程的分析與設計。（二）組織形式課上完成本次實踐的內容，采取分小組的方式，每組35人，包括1名組長。由組長負責分配工作。（三）任務描述每個小組根據上次實踐課自擬項目的系統設計（一）報告，完成該項目的系統設計（二）報告，要求使用工具StarUML完成該系統的狀態圖和活動圖建模。（三）指導內容1、相關知識：（1）狀態圖 狀態圖（Statechart Diag

16、ram） 主要用于描述一個對象在其生存期間的動態行為，表現為一個對象所經歷的狀態序列，引起狀態轉移的事件（Event），以及因狀態轉移而伴隨的動作（Action）。狀態圖只為單個對象模型。當所建模的類呈現出值得關注的和復雜的動態行為時，狀態圖才是有價值的。 狀態圖中的基本概念：State (狀態)、Action (動作)、Transition (轉移)、Event (事件)。 例1、電腦狀態圖。 例2、借書證狀態圖。 （2）活動圖 活動圖（Activity Diagram） 活動圖被設計用于簡化描述一個過程或者操作的工作步驟。活動圖對表示并發行為很有用。活動圖的應用非常廣泛，包括：1. 對系統

17、的工作流(workflow)建模，即對系統的業務過程建模。2. 對具體的操作建模，描述計算過程的細節。活動圖中的基本概念：activity (活動)、transition (轉移)、swimlane (泳道)、branch (分支)、fork and join (分叉和匯合)、object flow (對象流)。 例1、一個咨詢公司會見一個客戶時的業務過程。 （3）其他知識資源詳細內容請參見第7章 狀態機圖和活動圖的PPT或者 教材P117-P136 。2、過程與步驟：第一步：分析并識別系統中具有復雜狀態的對象。第二步：分析并確認每個對象的狀態。第三步：繪制每個對象的狀態圖草圖。第四步：修改狀

18、態圖草圖。第五步：采用工具StarUML畫出每個對象的狀態圖，具體過程 Design Modeladd Statechart Diagram，創建狀態state。完成之后將狀態圖粘貼到設計報告二中。第六步：分析并識別系統中的工作流程。第七步：分析并確認每個工作流程中涉及到的活動和活動之間的關系。第八步：繪制每個活動圖的草圖。第九步：修改活動圖。第十步：采用工具StarUML畫出每個工作流程的活動圖，具體過程Design Modeladd Activity Diagram，創建活動activity。完成之后將活動圖粘貼到設計報告二中。（四）成果提交組長將該小組的項目內容匯總到一個word文檔中，形成一份完成的設計報告二。小組成員每人提交一份該完整的設計報告二，注明提交人的姓名、學號和任務分工。設計報告二中