软件建模技术课件

第一章軟體建模技術和軟體工程

1.1軟體建模技術概述1.1.1建模

模型的概念 模型是對現實的簡化。它可以是一個對象的微縮表示、是一種用於生產某事物的模式，也可以是一種設計或一個類型，還可以是一個待模仿或仿真的樣例。1.1.1建模建模目的①模型幫助我們按照實際情況對系統進行可視化。②模型允許我們詳細說明系統。③模型給出了一個指導我們構造系統的範本。④模型對我們做出的決策進行範本化。

1.1.1建模建模原則①要仔細的選擇模型②每一種模型可以在不同的精度級別上表示所要開發的系統③模型要與現實相聯系④對一個重要的系統用一組幾乎獨立的模型去處理

1.1.1建模使用UML建模

UML的中文意思是統一建模語言(UnifiedModelingLanguage)，它是一種通用的可視化建模語言，可用於工程領域特別是軟體工程領域的建模。有了UML，就方便我們對各種工程進行描述和交流。1.1.2UML簡介

UML發展歷史

OMT(Rumbaughetal.)BoochOOSE(Jacobsonetal.)UML0.91996UML1.1Nov.1997UML1.4Mar.19991.1.2UML簡介統一建模語言UML(UnifiedModelingLanguage)是一種通用的可視化建模語言，用於對軟體進行描述、可視化處理、構造和建立軟體系統的工作文檔。

UML體系包括三個部分：

①UML基本構造塊

②UML規則

③UML公共機制。

1.1.2UML簡介UML的應用領域

軟體工程領域

UML同樣也可以用來描述非軟體領域的系統，如機械系統、企業機構或業務過程，以及處理複雜數據的資訊系統、具有即時要求的工業系統或工業過程等。

UML適用於系統開發過程中從需求規格描述到系統完成測試後的不同階段。

1.1.3建模工具rationalrose

啟動Rose

創建模型

發佈模型

設置全局屬性

1.2.1軟體

軟體的概念

軟體是電腦系統中與硬體相互依存的另一部分，它是包括程式、數據及其相關文檔的完整集合。 程式是按照事先設計的功能和性能要求執行的指令序列； 數據是使得程式能夠適當地操作資訊的數據結構； 文檔是描述程式的開發、操作和維護的文字或圖形資料。

1.2.1軟體軟體的特徵：

1．軟體是被開發或設計的，而不是被製造的。

2．軟體不會“磨損”，但會“退化”。

3．軟體的開發至今尚未擺脫手工藝的開發方式。

4．軟體是複雜的。1.2.1軟體軟體的分類：

1.系統軟體

2.支撐軟體

3.應用軟體

1.2.2軟體危機

軟體開發中出現的問題歸結如下：①軟體開發無計畫性，進度的執行和實際情況有很大差距。②軟體需求分析階段工作做得不充分，前期問題不及時解決，造成後期矛盾的集中暴露。③軟體開發過程中沒有統一的規範指導，參與軟體開發的人員各行其事。④軟體產品無評測手段。

1.2.3軟體工程

軟體工程的概念

將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、運行和維護，即將工程化應用於軟體開發。

與軟體工程相關的工作一般可分為三個階段：

①定義階段

②開發階段

③支持階段

1.2.3軟體工程軟體生存期的六個步驟：

①計畫

②需求分析和定義

③軟體設計（詳細設計）

④編碼

⑤軟體測試

⑥運行和維護

1.2.3軟體工程軟體生存期模型：

軟體生存期模型是從軟體專案需求定義直至軟體廢棄為止，跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框圖。常見軟體生存期模型：

①瀑布模型

②原型實現模型

瀑布模型原型實現模型1.2.4面向對象軟體工程方法

面向對象的概念“面向對象=對象+類+繼承+通信”。如果一個軟體系統是使用這樣的概念設計和實現的，就可以認為這個軟體系統是面向對象的。對象 對象是一種看問題的觀點，是對現實世界各種真實事物的一種抽象。一個對象是一組屬性和一組操作的集合。類

類是具有相同屬性、相同操作的一組對象的集合的抽象描述。每個對象都是類的實例。繼承

繼承是使用已存在的定義作為基礎建立新定義的技術。通信 一個對象和另一個對象之間，通過消息來進行通信。消息的傳遞大致等價於面向過程方法中的函數調用。

1.2.4面向對象軟體工程方法面向對象的應用開發過程：

①分析階段

②高層設計

③類的開發

④實例化

⑤組裝測試

⑥應用的維護

1.2.5Rational統一過程

Rational統一過程(RationalUnifiedProcessRUP)是一種軟體工程過程。RUP吸收了許多開發模型的優點，具有很好的可操作性和實用性。RUP的構架水準軸代表時間，顯示了過程的生命週期，包括初始、細化、構造、移交四個階段。豎直軸代表核心過程工作流，包括業務模型、需求、分析和設計、實現、測試、實施、配置和變更管理、專案管理、環境。1.2.5Rational統一過程RUP體現的現代軟體開發方法（實踐）：

①迭代的開發軟體

②需求管理

③應用基於構件的構架

④建立可視化模型

⑤不斷的驗證軟體品質

⑥配置管理和變更管理1.2.5Rational統一過程RUP的模型元素

①工作人員

②活動

③製品

④工作流

1.3.1UML事物

事物是對模型中最有代表性的成分的抽象。UML中有四種事物:1．結構事物(structuralthing)2．行為事物(behavioralthing)3．分組事物(groupingthing)4．注釋事物(annotationalthing)結構事物(structuralthing)

①類(class)

類是具有相同屬性、相同操作的一組對象的集合的抽象描述。在圖形上，類用一個矩形來表示，通常矩形中寫有類的名稱、類的屬性和類的操作。結構事物(structuralthing)②組件(component)

組件是系統中物理的、可替代的部件，是一個描述了一些邏輯元素(如類、介面)的物理包。在圖形上，組件由一個帶有小方框的矩形表示。通常在矩形中只寫該組件的名字。結構事物(structuralthing)③介面(interface)

介面是描述了一個類或組件的一個服務的操作集，或者說，介面描述了類或組件對外的、可見的動作。一個類可以實現一個或多個介面。在圖形上，介面用一個帶有名稱的圓表示。介面很少單獨存在，而是依附於實現介面的類或組件

結構事物(structuralthing)④協作(collaboration)

協作是一組類、介面和其他元素的群體，它們共同工作，提供比各組成部分的功能總和更強的合作行為。與組件不同，協作不能擁有自己的結構事物，而只能引用其他地方定義的類、介面、組件、節點等結構事物，即協作是系統體系結構中的概念組塊而不是物理組塊。在圖形上，協作用一個包含名稱的虛線橢圓表示。

結構事物(structuralthing)⑤用例(usecase)

用例是對一組序列動作的描述，系統執行這些動作將對用例的參與者(actor，有些書翻譯成“角色”)產生可以觀察的結果。在圖形上，用例用實線的橢圓表示，參與者用一個人形的圖案表示。

結構事物(structuralthing)⑥節點(node)

節點是一個物理元素，它在運行時存在，代表一個可計算的資源，比如說一台數據庫伺服器。在圖形上，節點用一個立方體來表示。結構事物(structuralthing)⑦主動類(activeclass)

主動類能夠啟動控制活動，因為它的對象至少擁有一個進程或線程。在圖形上，主動類的表示方法和普通類相似，也是使用一個矩形，只是最外面的邊框使用粗線。

行為事物(behavioralthing)

結構事物描述的是模型的靜態部分，而行為事物描述的是模型的動態部分。一共有兩類主要的行為事物。①交互(interaction)

對象都不是孤立存在的，它們之間通過傳遞消息進行交互。在圖形上，交互的消息通常用帶箭頭的直線表示。

行為事物(behavioralthing)

②狀態機(statemachine)

一個狀態機是一個行為，它說明對象在它的生命週期中回應時間所經歷的狀態序列以及它們對那些事件的回應。狀態是指在對象的生命週期中滿足某些條件、執行某些活動或等待某些事件時的一個條件或狀況。一個事件的到來，能夠觸發一個狀態的轉換。

分組事物(groupingthing)分組事物是UML模型中負責分組的部分，可以把它看作一個一個的盒子，每個盒子裏面的對象關係相對複雜，而盒子與盒子之間的關係相對簡單。最主要的分組事物是包。

包(package)是把元素組織成組的機制。結構事物、行為事物甚至其他的分組事物都可以放進包內。在圖形上，包用一個在左上角帶有一個小矩形的大矩形表示。

注釋事物(annotationalthing)

注釋事物是UML模型的解釋部分。這些注釋事物用來描述、說明和標注模型的任何元素。有一種主要的注釋事物，稱為注解(note)。在圖形上，注解用一個右上角是折角的矩形表示。1.3.2UML關係

UML中關係(relationship)包括四種： 依賴(dependency)

關聯(association)

泛化(generalization)

實現(realization)。

依賴關係

依賴是兩個事物間的語義關係，其中一個事物(獨立事物)發生變化，會影響到另一個事物(依賴事物)的語義。在圖形上，把一個依賴關係畫成一條可能有方向的虛線，偶爾在其上還有一個標記。

關聯關係

關聯指明了一個事物的對象與另一個事物的對象間的關係。在圖形上，關聯用一條實線表示，它可能有方向，偶爾在其上還有一個標記。

泛化關係

泛化是一種特殊\一般關係，是一般事物(父類)和該事物較為特殊的種類(子類)之間的關係，子類繼承父類的屬性和操作，除此之外，子類通常還添加新的屬性和操作。實現關係

實現關係將一種模型元素(如類)與另一種模型元素(如介面)連接起來，其中介面只是行為的定義而不是結構或實現，也就是說，關係中的一個模型元素只具有行為的定義，而行為的具體實現，則是由另一個模型元素來給出。在兩個地方要遇到實現關係：一種是在介面和實現它們的類或組件之間，另一種是在用例和實現它們的協作之間。1.3.3UML圖

圖是一組元素的圖形表示。為了對系統進行可視化，可以從不同的角度畫圖。在理論上，圖可以包含任何事物及其關係的組合。在UML中包含9類圖：

1．類圖(classdiagram)2．對象圖(objectdiagram)3．用例圖(usecasediagram)4．順序圖(sequencediagram)5．協作圖(collaborationdiagram)6．狀態圖(statechartdiagram)7．活動圖(activitydiagram)8．組件圖(componentdiagram)9．部署圖(deploymentdiagram)1.3.3UML圖1．類圖(classdiagram)

類圖展現了一組對象、介面、協作和它們之間的關係。類圖給出了系統的靜態設計視圖。在面向對象系統的建模中，建立的最常見的圖就是類圖。

1.3.3UML圖2．對象圖(objectdiagram)

對象圖展現了一組對象以及它們之間的關係。和類圖類似，對象圖也給出了系統的靜態設計視圖。

1.3.3UML圖3．用例圖(usecasediagram)

用例圖展示了一組用例、參與者以及它們之間的關係。用例圖給出了系統的靜態用例視圖。

1.3.3UML圖4．順序圖(sequencediagram)

順序圖是一種強調消息的時間順序的交互圖。交互圖(interactiondiagram)是指：它展現了一種交互，由一組對象和它們之間的關係組成，包括它們之間可能發送的消息。交互圖是描述系統的動態視圖。

1.3.3UML圖5．協作圖(collaborationdiagram)

協作圖也是一種交互圖，它強調收發消息的對象的組織結構。因為協作圖和順序圖在結構上是相同的，所以它們是可以互相轉換的。

1.3.3UML圖6．狀態圖(statechartdiagram)

狀態圖展現了一個狀態機，它由狀態、轉換、事件和活動組成。狀態圖是描述系統的動態視圖。狀態圖對於介面、類或協作的行為建模非常重要。

1.3.3UML圖7．活動圖(activitydiagram)

活動圖是一種特殊的狀態圖，它展現了在系統內從一個活動到另一個活動的流程。活動圖是描述系統的動態視圖。它強調了對象間的控制流程，因此對系統的功能建模非常重要。

1.3.3UML圖8．組件圖(componentdiagram)

組件圖展現了一組組件之間的組織和依賴。組件圖專注於系統的靜態實現圖。它與類圖是息息相關的，通常情況下，組件被映射成一個或多個類、介面或協作。

1.3.3UML圖9．部署圖(deploymentdiagram)

部署圖展現了在系統運行時，進行處理的節點和在節點上活動的組件的配置。部署圖給出了體系結構的靜態部署視圖。

本節目標理解需求分析與用例圖之間的關係。掌握參與者、用例、關係的概念。學會通過分析需求畫出用例圖。任務分析本章的專案引入中的系統的需求，確定系統中的參與者和主要用例，並畫出用例視圖。案例描述

HNS是一所以培養軟體開發人才為目標的高等院校，為適應IT產業發展對技術人才的需求，近年來擴大了招生規模，隨著在校學生的增加，學院計畫改善包括圖書館在內的各項教學設施，擬開發《圖書管理系統》使其可以滿足學生的要求。

現實案例

建築效果圖建築規劃圖建築平面圖需求需求是指系統必須符合的條件或具備的功能。需求問題是引起軟體專案的高風險率的最主要原因缺乏需求對需求的不正確理解需求的不完整需求的變化需求建模如何描述需求？《圖書管理系統》的需求描述如下：1．新書入庫：當圖書館新進一批新書時，圖書管理員需要登記入庫資訊，並為每一本新書製作一個圖書卡(書目條)。2．借閱者資訊維護：包括兩個方面的工作：一是新讀者的辦證操作，二是讀者基本資訊的維護工作。3．預約借書：當讀者想借閱書不在時，可以通過預約的方式預定不在庫的書籍。4．借書：根據借閱者提供的書目編號，辦理借書手續。5．還書：根據借閱者歸還書籍的書目編號，辦理歸還手續。6．圖書查詢：讀者在借書前，通過書目目錄去查詢所需書籍的書目編號。需求建模如何使用UML對需求建模呢？如圖：需求建模使用UML對需求建模的優勢？1、幫助專案人員按照實際情況對系統可視化。2、對系統的描述一目了然，方便與用戶的交流和溝通。3、不易產生二義性，利於系統的分析和設計。用例圖用例圖是顯示一組用例、參與者以及它們之間關係的圖。

用例圖從用戶的角度而不是開發者的角度來描述對軟體產品的需求，分析產品所需的功能和動態行為用例圖常用來對需求建模，用例圖是至關重要的，它的正確與否直接影響到客戶對最終產品的滿意度用例圖的內容：參與者用例泛化、擴展和包含關係參與者（Actor)參與者(Actor)是系統外部的一個人或物，它以某種方式參與了系統的執行過程。參與者對系統而言總是外部的參與者在系統的不同組成部分可能扮演不同的角色參與者用一個人形的圖案表示識別參與者

客戶給銷售員發來傳真訂貨，銷售員下班前將當日訂貨單匯總輸入系統。誰是系統的Actor？答案：銷售員識別參與者

尋呼臺系統。用戶如果預定了天氣預報，系統每天定時給他發天氣消息；如果當天氣溫高於35度，還要提醒用戶注意防暑。這個敘述裏，誰是尋呼臺系統的Actor?

用戶？氣溫？時間？答案：用戶，氣溫，時間都是Actor識別參與者

商品銷售系統。顧客通過網路下單之後，系統計算出總計金額，稅金，運費，並將數目傳遞給一個外掛的會計系統，該系統是另外購買的。有幾個Actor？答案：顧客(商品銷售系統)，商品銷售系統(會計系統)參與者使用以下問題有助於發現系統的參與者①誰使用系統？②誰安裝系統、維護系統？③誰啟動系統、關閉系統？④誰從系統中獲取資訊，誰提供資訊給系統？⑤在系統交互中，誰扮演了什麼角色？⑥系統會與哪些其他系統相關聯？用例(UseCase)用例是對一組序列動作的描述，系統執行這些動作將對用例的參與者產生可以觀察的結果。參與者和用例分別描述了“誰來做？”和“做什麼？”這兩個問題。用例用實線的橢圓表示用例識別用例的最好辦法就是從分析系統的參與者開始，考慮每個參與者是怎樣使用系統。根據下麵的一些問題來識別用例：①參與者希望系統提供什麼功能；②系統是否存儲和檢索資訊；③當系統改變狀態時，是否通知參與者；④是否存在影響系統的外部事件，是哪個參與者通知系統這些外部事件。識別用例Email客戶端（如：outlookexpress），A在北京發郵件給深圳的B，系統提醒B”你有新郵件”，B收郵件。識別用例

一個論壇類的應用，用戶可以提問，別人來回答，如果有自己問題被解答的話，就給發問者發一份郵件通知。注意：發郵件這個用例可以是單獨的用例，也可以是由回答用例擴展出來的用例用例如何判斷一個用例是否是一個優秀的用例呢？①用例是否描述了應該做什麼，而不是如何做？②用例的描述是否採取了參與者的視點？③用例是否對參與者有價值？④用例描述的時間流是否是一個完整場景？⑤是否所有的參與者、用例都有相應的關聯用例或關聯參與者？用例與事件流用例描述的是參與者與系統之間的對話，但是這個對話的細節並沒有在用例圖中表述出來，針對每一個用例我們可以用事件流來描述這一對話的細節內容。事件流可分為：基本事件流、備選事件流用例與事件流銀行自動取款機(ATM)系統中的“提款”用例可以用事件流表述如下提款─基本事件流 基本流步驟1：用戶插入信用卡 基本流步驟2：輸入密碼 基本流步驟3：輸入提款金額 基本流步驟4：提取現金 基本流步驟5：退出系統，取回信用卡用例與事件流提款─備選事件流備選流一：用戶可以在基本流中的任何一步選擇退出，轉至基本流步驟5。備選流二：在基本流步驟1中，用戶插入無效信用卡，系統顯示錯誤並退出信用卡，用例結束。備選流三：在基本流步驟２中，用戶輸入錯誤密碼，系統顯示錯誤並提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯誤後，信用卡被系統沒收，用例結束。用例之間的關係

泛化關係包含關係擴展關係用例之間的關係泛化：同一業務目的的不同技術實現包含：提取公共交互，提高複用擴展：“凍結”基用例以保持穩定

*通過關係提高用例複用泛化(generalization)

當多個用例共同擁有一種類似的結構和行為的時候我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關係中的子用例。泛化(generalization)泛化舉例（一）：

泛化(generalization)泛化舉例（二）：包含(include)包含是指基本用例(baseusecase)會用到包含用例(inclusion)，具體地講，就是將包含用例的事件流插入到基礎用例的事件流中。包含用例是可重用的用例──多個用例的公共用例。

包含(include)包含(include)包含舉例（一）：包含(include)包含舉例（二）：擴展(extend)將擴展用例的事件流在一定的條件下按照相應的擴展點插入到基礎用例中。基礎用例不必知道擴展用例的任何細節，它僅為其提供擴展點。擴展用例的行為是否被執行要取決於主事件流中的判定點。擴展(extend)擴展(extend)擴展舉例（一）：擴展(extend)擴展舉例（二）：用例之間的關係包含用例與擴展用例的區別①相對於基礎用例，擴展用例是可選的，而包含用例則不是。②如果缺少擴展用例，基礎用例還是完整的，而缺少包含用例，則基礎用例就不完整了。③擴展用例的執行需要滿足某種條件，而包含用例不需要。④擴展用例的執行會改變基礎用例的行為，而包含用例不會。任務解決系統中的主要活動，如下：①讀者需要借書籍，需要還書籍。②讀者可以預約書籍，也可以撤銷預約。③管理員根據讀者要求提供服務。④管理員可以添加、修改、刪除讀者。⑤管理員可以添加、修改、刪除書籍。任務解決1．確定系統參與者 管理員和讀者2．確定系統用例。3．使用RationalRose繪製用例圖。①讀者資訊管理用例圖的繪製任務解決任務解決②書籍資訊管理用例圖的繪製任務解決③圖書館業務用例圖的繪製任務解決④資訊查詢用例圖的繪製任務

根據HNS的圖書管理系統開發進度，在完成對系統的需求建模，得到用例模型後，應針對每個用例進行業務分析，說明其具體的業務流程，現系統分析部指派您完成該項任務，要求：用活動圖描述系統中已知用例的業務過程：1．描述新增讀者用例2．描述刪除讀者用例活動圖的基本概念為什麼需要活動圖？用於描述活動流程的圖形稱為活動圖活動指一個狀態機中進行的非原子的執行單元，它由一系列的可執行的原子計算組成，這些原子計算會導致系統狀態的改變或返回一個值。活動圖可以算作是狀態圖一種特殊形式，活動圖除了描述對象狀態之外，更加突出它的活動

活動圖的基本概念活動圖可以用作以下目的：描述一個操作執行過程中所完成的工作（動作），這是活動圖最常見的用途。描述對象內部的工作。顯示如何執行一組相關的動作，以及這些動作如何影響它們周圍的對象。顯示用例的實例如何執行動作以及如何改變對象狀態。說明一次業務流程中的人（參與者）和對象是如何工作的。

活動圖的基本概念活動圖中的基本要素包括狀態、轉移、分支、分叉和匯合、泳道、對象流等狀態（State）狀態是指在對象的生命週期中滿足某些條件、執行某些活動或等待某些事件時的一個條件或狀況。活動圖中的狀態包括動作狀態和活動狀態。活動圖的基本概念動作狀態對象的動作狀態是活動圖中最小單位的構造塊，表示原子動作。動作狀態有三個特性：原子性；不可中斷性：暫態性：動作狀態使用帶圓端的方框表示活動圖的基本概念活動狀態表示的是可以分割的動作特點是：它可以被分解成其他子活動或動作狀態，它能夠被中斷，佔有有限的時間。活動狀態可以理解為一個組合，它的控制流由其他活動狀態或動作狀態組成。圖形表示同動作狀態活動圖的基本概念活動圖中還有一類特殊的狀態，用於表示活動的開始和結束，分別稱為起始狀態(startstate)和終止狀態(endstate)。起始狀態表示一個工作流程的開始，用實心圓點來表示終止狀態表示了一個活動圖的最後和終結狀態，用實心圓點外加一個小圓圈來表示活動圖的基本概念轉移（transition）

轉移是兩個狀態間的一種關係，表示對象將在當前狀態中執行動作，並在某個特定事件發生或某個特定的條件滿足時進入後繼狀態。在UML中用一條簡單的直線表示一個轉移活動圖的基本概念示例：打電話活動圖的基本概念分支(Branch)分支用於描述基於某個條件的可選擇路徑。一個分支可以有一個進入轉移和兩個或多個輸出轉移。在每條輸出轉移上都有監護條件運算式保護，當且僅當監護條件運算式為真時，該輸出路徑才有效。在所有輸出轉移中，其監護條件不能重疊，而且它們應該覆蓋所有的可能性。分支在圖形表示上用菱形表示活動圖的基本概念示例2.2.1HNS圖書館管理系統中需要提供對用戶資訊的修改功能，請使用活動圖描述該用例。活動圖的基本概念分叉（fork）和匯合（join）

在UML中使用分叉和匯合表示並行發生的事件流分叉表示把一個單獨的控制流分成兩個或多個併發的控制流。一個分叉可以有一個進入轉移和兩個或多個輸出轉移，每一個轉移表示一個獨立的控制流。匯合表示兩個或多個併發控制流的同步發生，一個匯合可以有兩個或多個進入轉移和一個輸出轉移。分叉和匯合應該是平衡的分叉和匯合在圖形上都使用同步條來表示，同步條通常用一條粗的水平線表示活動圖的基本概念示例：描述打電話活動中的併發事件活動圖的基本概念泳道（swimlane）“泳道”技術，是將一個活動圖中的活動狀態進行分組，每一組表示一個特定的類、人或部門，他們負責完成組內的活動。“泳道”技術來描述每個活動是由哪個對象負責完成UML中，每個組被稱為一個泳道，用一條垂直的實線與鄰居分開每個活動都明確屬於一個泳道，不可以跨越泳道，而轉移則可以跨越泳道活動圖的基本概念示例2.2.2用活動圖描述客戶在商店中購買物品的過程。活動圖的基本概念對象流（objectstream）包括依賴關係和對象的應用被稱為對象流。對象流是動作和對象間的關聯。對象流可用於對下列關係建模：動作狀態對對象的使用動作狀態對對象的影響。在UML中，使用矩形表示對象,對象和動作之間使用帶箭頭的虛線連接，帶箭頭的虛線表示對象流。活動圖的基本概念示例2.2.2用活動圖描述客戶在商店中購買物品的過程。(使用對象流技術描述購物這個動態過程中系統內對象的狀態變化）活動圖的基本概念活動圖的建模技術活動圖用於對系統的動態行為建模，在對一個系統建模時，通常有兩種使用活動圖的方式：為工作流建模為對象的操作建模活動圖的基本概念使用活動圖對系統建模的步驟①確定活動圖所關注的業務流程。②確定該業務流程中的業務對象。③確定該工作流的起始狀態和終止狀態。④從該工作流的起始狀態開始，說明隨著時間發生的動作和活動，並在活動圖中把它們表示成活動狀態或動作狀態。⑤將複雜的動作，或多次出現的動作集合歸併到一個活動狀態，並對每個這樣的活動狀態提供一個可展開的單獨的活動圖。⑥找出連接這些活動和動作狀態的轉移。⑦如果工作流中涉及重要的對象，則也把它們加入到活動圖中。任務解決"新增讀者"用例屬於讀者資訊管理中的一個功能，主要用於在系統中增加新的讀者資訊，其具體的辦理流程是：

（1）"讀者"填寫申請表，並交給"圖書管理員"； （2）"圖書管理員"將申請表中的資訊通過錄入介面，輸入到圖書管理系統； （3）系統中的"業務邏輯"組件將判斷輸入的資訊是否合法； （4）如果不合法則轉入步驟（5），否則轉入步驟（6）； （5）顯示"添加錯誤資訊"，轉到（8）； （6）在資料庫添加相信的用戶資訊； （7）顯示"添加成功資訊"； （8）結束。任務解決精練請您根據本節所學的知識解決“任務”中的要求2，繪製“刪除讀者資訊”用例的活動圖。刪除讀者資訊一般按照以下步驟進行：（1）管理員在錄入介面，輸入待刪除的讀者名；（2）“業務邏輯”組件在資料庫中，查找待刪除的讀者名；（3）如果不存在，則顯示出錯資訊，返回步驟（1），如果存在則繼續；（4）“業務邏輯”組件判斷“待刪除的讀者”是否可以刪除；（5）如果不可以，則顯示出錯資訊，返回步驟（8），如果可以則繼續；（6）在資料庫中，刪除相關資訊；（7）顯示刪除成功資訊；（8）結束。小結活動圖是UML中用於對系統的動態方面建模的五種圖中的一種，一張活動圖從本質上說是一個流程圖，顯示從活動到活動的控制流多數情況下，活動圖用於對業務過程中順序和併發的工作流程進行建模。活動圖中的基本要素包括狀態、轉移、分支、分叉和匯合、泳道、對象流。狀態是指在對象的生命週期中滿足某些條件、執行某些活動或等待某些事件時的一個條件或狀況。活動圖中的狀態包括動作狀態和活動狀態。對象的動作狀態是活動圖中最小單位的構造塊，表示原子動作。具有原子性、不可中斷性和暫態性。小結(續)活動狀態表示的是可以分割的動作。活動圖中還有一類特殊的狀態，用於表示活動的開始和結束，分別稱為起始狀態(startstate)和終止狀態(endstate)。轉移表示對象將在當前狀態中執行動作，並在某個特定事件發生或某個特定的條件滿足時進入後繼狀態。分支用於描述基於某個條件的可選擇路徑。分叉表示把一個單獨的控制流分成兩個或多個併發的控制流。專案引入HNS軟體學院開發部在對圖書館管理系統需求建模後，進入到系統分析和概要設計階段。在該階段中，將在需求模型的基礎上，對系統進行靜態建模以及動態建模，最後構建出圖書館管理系統的軟體架構。這主要體現在對系統中對象進行抽象成類，進而對類間的相互關係進行建模，而系統內部行為建模則是由交互圖進行描述。因此，指派您在學習完本章內容的前提下對系統進行概要設計建模。3.1.1事件(Event)事件：它表示對一個在時間和空間上佔據一定位置的有意義的事情的規格說明。事件：也就是指發生的且引起某些動作執行的事情。例如，當你按下電視機上的Power按鈕時，電視開始播放。其中“按下Power按鈕”就是事件，而事件引起的動作就是“開始播放”。3.1.1事件(Event)事件可以是內部的事件或外部的事件外部事件是在系統和參與者之間傳送的事件。內部事件是在系統內部的對象之間傳送的事件。

事件可以分成多種類型：信號調用事件變化事件時間事件……信號信號（Signal）：是作為兩個對象之間通信媒介的命名的實體，信號的接收是信號接收對象的一個事件。

信號和簡單的類有許多共同之處，同樣信號也可以有實例。 信號還可以包含在泛化關係中。同樣信號可以像類一樣，有屬性和操作。 例如電腦設備的中斷信號就是一般的信號，而鍵盤中斷信號就是特殊的信號。

信號信號可以在類圖中被聲明為類，並用關鍵字《signal》表示，信號的參數被聲明為屬性。在UML中，可以將信號建模為構造型化的類。用構造型為Send的依賴關係來表示一個操作發送了一個特定的信號。信號信號間可以有泛化，信號可以是其他信號的子信號，它們繼承父信號的屬性，並可以觸發包含信號類型的轉換。示例：調用事件調用事件（CallEvent）是指一個對象對操作調用的接收。接收的類可以選擇將操作實現為一個方法或實現為狀態機裏的一個調用事件觸發器。信號是一個非同步事件，而調用事件一般來說是同步的。也就是說，當對象調用另一對象的操作時，控制就從發送者傳送到接收者，該事件觸發轉換，完成操後，接收者轉換到一個新的狀態，控制返還給發送者。調用事件示例3.1.1

如圖變化事件變化事件（changeevent）是指依賴於指定屬性值的布爾運算式得到滿足。這是一種一直等待直到特定條件被滿足的聲明方式。在UML中，用關鍵字When，後面跟隨布爾運算式來對一個變化事件建模。你可以用運算式來標記一個絕對時間（如：Whentime＝10:00），或對運算式作不間斷地測試（如whenaltitude<1000）。變化事件示例3.1.2

如圖時間事件時間事件（Timeevent）是表示一段時間推移的事件。在UML中，用關鍵字after，後面跟著計算一段時間的運算式來對時間事件建模。運算式計時的基準，默認為進入當前狀態的時間為基準。時間事件示例3.1.3

如圖3.1.2狀態狀態（State）是指在對象的生命週期中滿足某些條件、執行某些活動或等待某些事件時的一個條件或狀況。 例如，印表機printer在工作時可能有6種狀態：“就緒”（Ready），“列印”（Print），“缺紙”(Lackpaper)，“忙”（Busy），“暫停”（Pause）和“停止”（Stop）。這裏具體的印表機在UML中就表示為對象，而它工作時可能出現的狀態則是狀態圖中的狀態。狀態的組成部分1．名稱（name）是可以把該狀態和其他狀態區分開的字串;狀態也可能是匿名的，即沒有名稱。2．進入/退出動作(entry/exitaction)分別指進入和退出這個狀態時所執行的動作。3．內部轉換（internaltransition）不會導致狀態改變的轉換。4．子狀態

(substate)主要是在狀態的嵌套結構中，包括不相交（順序活動）或併發（併發活動）子狀態。5．延遲事件

(deferredevent)是指在該狀態下暫不處理，但將推遲到該對象的另一個狀態下排隊處理的事件列表。狀態示例示例3.1.4

如圖3.1.3轉換轉換是兩個狀態間的一種關係，表示對象將在當前狀態中執行動作，並在某個特定事件發生或某個特定的條件滿足時進入後繼狀態。在轉換啟動之前，稱對象處於源狀態;啟動後，就稱對象處於目標狀態。 例如，當像“獲取時間片”這樣的事件發生時，程式可能從“就緒”狀態轉換到“運行”狀態。轉換的組成部分1.源狀態（sourcestate）即受轉換影響的狀態;如果對象處於源狀態，當該對象接收到轉換的觸發事件或滿足監護條件（如果有）時，就會啟動一個轉換。2.事件觸發（Eventtrigger）是一個事件，源狀態中的對象接收這個事件使轉換合法地啟動，並使監護條件滿足。 例如，將Mouse（滑鼠）作為觸發器，那麼接收到RightMouseButton也可以觸發這個轉換（如圖3.1.2）。轉換的組成部分3.監護條件（guardcondition）是一個布爾運算式，當觸發器事件被觸發時才對這個布爾運算式求值;如果運算式取值為真，則啟動轉換;為假，則不能啟動轉換，而且如果沒有其他的轉換被此事件所觸發，則該事件丟失。事件能夠觸發多個轉換離開當前狀態。每個轉換必須具有不同的監護條件。4.動作（Action）動作是可執行的一個原子計算，它可以直接的作用於擁有狀態機的對象，也可以間接作用於那些可見的其他對象。當轉換被引發時，它對應的動作被執行。它一般是一個簡短的計算處理過程，通常是賦值操作或算術計算。轉換的組成部分5.目標狀態（targetstate）轉換完成後的活動狀態。示例3.1.5

3.1.4狀態圖狀態圖（StatechartDiagram）是UML中對系統的動態方面進行建模的五種圖之一。狀態圖顯示了狀態機。活動圖是狀態圖的一個特例，狀態圖中的多數狀態是活動狀態，而且所有或多數轉換是由源狀態中的活動完成所觸發的。活動圖顯示的是從活動到活動的控制流，狀態圖則顯示的是從狀態到狀態的控制流。狀態圖的用途狀態圖用於對系統的動態方面建模。動態方面是指出系統體系結構中任一對象按事件排序的行為，這些對象可以是類、介面、構件和節點。狀態圖的建模技術的策略2-1(1)選擇狀態機的語境（即建模對象），不管它是類、用例或是整個系統；(2)選擇這個對象的初態和終態。為了指導模型的剩餘部分，可能要分別地說明初態和終態的前置條件和後置條件；(3)考慮對象可能在其中存在一段時間的條件，以決定該對象所在的穩定狀態。從這個對象的高層狀態開始，然後考慮它的可能的子狀態；(4)在對象的整個生命週期中，決定穩定狀態的有意義的順序；狀態圖的建模技術的策略2-2(5)決定可能觸發從狀態到狀態的轉換的事件。將這些事件建模為觸發者，它觸發從一個合法狀態序列到另一個合法狀態序列的轉換；(6)把動作附加到這些轉換上，並且附加到這些狀態上；(7)考慮通過使用子狀態、分支、匯合和歷史狀態，來簡化狀態圖；(8)核實所有的狀態都是在事件的某種組合下可達的；(9)核實不存在死角狀態，即不存在那種不能轉換出來的狀態；(10)通過手工或通過使用工具跟蹤狀態機，核對所期望的事件序列以及它們的回應。狀態圖示例示例3.1.6對電話工作的行為建模。任務解決-分析借書業務在系統的業務建模中是一個用例，而這種用例是一個應對型對象。為便於理解該業務的控制流程和確保業務處理的正確性。從前面章節對該業務描述可知，借書業務是由借書空閒(idle)書目查詢（finding）借書（Lending）預約（reservation）取消預約（removereservation）借書成功（Success）失敗（Failure）7種狀態組成。任務解決-主要事件從空閒狀態到書目查詢狀態是由書目編號錄入引發的；同樣查詢失敗也會引發查詢狀態轉換到借書業務的空閒狀態；查詢成功的事件會激發從查詢狀態到借書狀態；當所查到的書在庫時則借閱成功轉發成功顯示狀態；當所查到的書已預約時則激發取消預約事件；當所查到的書已借出則激發預約事件轉入預約狀態；在取消預約時如預約取消成功則轉入借書狀態；如預約成功則轉入資訊顯示狀態任務解決-繪製狀態圖步驟1.打開前面初步構建的UML模型檔。步驟2．打開Rose中的用例視圖（UseCaseView），選擇用例（usecase）目錄下的圖書館業務功能包，並選擇借書用例。如圖3.1.8所示。任務解決-繪製狀態圖步驟3．用滑鼠右擊借書用例在彈出來的菜單中選擇“New→statechartdiagram”項，創建狀態圖。如圖所示。任務解決-繪製狀態圖步驟4．雙擊新建的狀態圖，並點右邊控件集中選中開始狀態並用滑鼠在圖中拖出。任務解決-繪製狀態圖步驟5．如上圖所示操作方法分別將狀態圖中的所有狀態創建出來。如圖所示。任務解決-繪製狀態圖步驟6．將狀態圖中的事件加上就完成借書的狀態圖。如圖所示。精練請您根據本節所學的知識解決專案中的任務2。分析：由前面章節對圖書館管理系統中的還書業務的描述和分析可知，還書業務的動態行為是由：空閒（idle）、圖書查找（finding）、還書（reversion）、失敗（Failure）、歸還成功（Success）5種狀態及啟動相互轉換的事件。繪製狀態圖：請您根據分析運用UML繪製還書用例的狀態圖。小結事件(Event)，是指對一個在時間和空間上佔據一定位置的有意義的事情的規格說明。事件包括信號、調用、時間推移或狀態改變。狀態（State）是指在對象的生命週期中滿足某些條件、執行某些活動或等待某些事件時的一個條件或狀況。轉換是兩個狀態間的一種關係，表示對象將在當前狀態中執行動作，並在某個特定事件發生而某個特定的條件滿足時進入後繼狀態。3.2.1類類（class）是對一組具有相同屬性、操作、關係和語義的對象的描述。類是對事物的抽象，它不是個體對象，而描述一些對象完整集合。例如，你可以把CPU看作是對象類，它具有CPU的共同屬性，如：主頻、指令集、Cache容量、運算位數、功率等。也可以考慮CPU的某個具體實例，如“Intel的P4處理器”。3.2.1類在UML中為類提供了圖形表示。這種可視化的抽象表示，使得我們對類的描述脫離了具體編程語言，而只需要強調抽象的主要部分。類主要是由：名稱、屬性和操作。類名稱類必須各自有不同的類名稱。類名稱是一個字串。單獨的名稱為簡單名;還有一種用類所在包的名稱作為首碼的類名稱作路徑名。例如書類屬於數據表包中的類則其類的路徑名為“數據表：：書”。類名可以是由數字、字母和下劃線等符號組成，類名的長度沒有限制。例如顧客類可以用Customer作為類名。屬性屬性（attribute）是已被命名的類的特性，它描述了該特性的實例可以取值的範圍。屬性描述了正被建模的事件的一些特性，這些特性是類的所有對象所共有。 例如，所有的CPU都有主頻率、指令集類型、運算的位算和外觀尺寸。屬性描述的一般語法格式為：可見性屬性名：類型名＝初值｛特性串｝屬性在UML中定義了3種可以用於屬性的特性：(1)可變（changeable）：對修改屬性的值沒有約束。(2)只增（addOnly）：對於多重性大於1的屬性，可以增加附加值，但一旦被創建，就不可對值進行消除或改變。(3)凍結（frozen）：在初始化對象後，就不允許改變屬性值。操作操作（Operation）是服務的實現，該服務可以由類的任何對象請求以影響其行為。 在UML中把操作序列放在類屬性下麵的欄中，如圖所示：操作操作的標準語法格式為：可見性操作名（參數表）：返回值｛特性串｝可用於操作的特性：查詢（isQuery）順序（sequential）監護（guarded）併發（concurrent）3.2.2類成員的可見性1．公有（Public）用“＋”表示。2．受保護（protected）用“#”表示。3．私有（private）用“—”表示。類的類型1．實體類（entity）

實體類是對系統中需要存儲的資訊和其資訊的行為建立模型。實體類具有永久的特性，這類似於資料庫中的表一樣用於保存系統的業務資訊。在UML中，實體類的構造類型（stereotype）被設定為Entity。類的類型示例3.2.1從圖書館管理系統中的讀者管理模組中找出所有的實體類。

練習3.2.1請找出學籍管理系統中的學生管理模組中的實體類。（主要對學生進行抽象）類的類型2．邊界類（boundary）邊界類（boundary）位於系統與外界的交接處，它在一個或多個角色和系統之間建立相互作用的模型。邊界類可以是窗口、印表機介面、感測器和終端。要尋找和定義邊界類，可以檢查用例圖。每個參與者（Actor）和用例交互至少要有一個邊界類。在UML中，實體類的構造類型（stereotype）被設定為Boundary。類的類型示例3.2.2從圖書館管理系統中的讀者管理模組中找出所有的邊界類。類的類型3．控制類（control）控制類是負責協調其他類的工作，它建立了一個或幾個用例的行為模型。例如登錄用例就須要有用戶驗證類就是控制類，他通過協調登錄邊界類與用戶資訊實體類來完成登錄的工作。

它整理系統的行為並描述一個系統的動態特性，處理主要的任務和控制流。每個用例通常都有一個控制類、控制用例中的事件順序。也存在多個用例共用同一個控制類。在UML中，控制類的構造類型（stereotype）被設定為control。類的類型示例3.2.3從圖書館管理系統中的讀者管理模組中找出所用到的控制類。類的尋找類的尋找策略：(1)從事件流中尋找名詞或名詞片語（或交互圖中的對象），將性質相同的歸為一類，或性質內容值正負相反的歸為一類。(2)去除不恰當的與含糊的類別，去除應是歸類為屬性的專案。(3)給這些類取個合適的名字，在現實系統實現時，可以參照真實系統相關的命名規約。任務解決-分析圖書館業務功能主要由借書、還書、預約和取消預約四個主要功能，這四種功能是由三層組成，即：介面、控制和相應的書籍資訊表。因此，本功能模組可以抽象出如下類：書實體類讀者實體類借書操作介面類還書操作介面類預約圖書操作介面類書籍管理類。任務解決-繪製狀態圖步驟1．打開前面初步構建的UML模型檔;步驟2．打開Rose中的邏輯視圖（LogicalView），選擇分析模型（analysismodel）目錄。並在其下創建一個子目錄並命名為：“圖書館業務功能”，如圖所示。任務解決-繪製狀態圖步驟3．用滑鼠右擊“圖書館業務功能”在彈出來的菜單中選擇“New→Classdiagram”項，創建類圖。任務解決-繪製狀態圖步驟4．雙擊新建的類圖，並點右邊控件集中選中的類並用滑鼠在圖中分別拖出上述類圖。任務解決-繪製狀態圖步驟5．設定上述各類的屬性和操作（以讀者資訊類為例）。5.1先用滑鼠右擊Reader類在彈出的下拉菜單中選擇“OpenSpecification”項彈出類屬性窗體如圖3.2.14所示。任務解決-繪製狀態圖5.2再點擊“Attributes”選項，在彈出的窗體中分別插入屬性。任務解決-繪製狀態圖5.3同理在打開的類屬性窗口中選擇“Operations”項，並按上面步驟插入類的操作。步驟6．設各類的構造類型（以讀者資訊類為例）。精練請您根據本節所學的知識解決專案中的任務2。分析：由前面章節對圖書館管理系統中的書籍管理功能可知，該模組是由書籍資訊類、書目類、新增書籍介面類、修改書籍介面類、刪除書籍介面類和書籍管理類6個類組成。請您根據分析使用Rose圖繪製類資訊。3.3類的關係關係（Relationship）是指事物之間的聯繫。在面向對象的建模中，有3種最重要的關係是依賴泛化關聯在圖形上，把關系畫成一條線，並用不同的線區別關係的種類。依賴（dependency）依賴（dependency）是一種使用關係，它說明了一個事物聲明說明的變化可能影響到使用它的另一個事物，但反之未必。

例如在windows系統中的窗體事件（類Event）的變化將會影響到使用它的窗體（類Window）。

在圖形上，把依賴畫成一條有向的虛線，指向被依賴的事物。當要指明一個事物使用另一個事物時，就使用依賴。依賴（dependency）在UML中定義了4類基本依賴類型：1．使用依賴使用依賴是一種非直接的，它通常表示使用者使用服務提供者所提供的服務實現它的行為。在UML中定義了4種使用依賴：(1)使用（《use》）(2)調用依賴（《call》）(3)發送（《Send》）(4)實例化（《instantiate》）依賴（dependency）2．抽象依賴抽象依賴建模表示使用者和提供者之間的關係，它依賴於在不同抽象層次上的事物。下麵給出了3種類型的抽象依賴。(1)跟蹤依賴（《trace》）(2)精化依賴（《refine》）(3)派生依賴（《derive》）3．授權依賴授權依賴表達了一個事物訪問另一個事物的能力。提供者可以規定使用者的許可權，這是提供者控制和限制對其內容訪問的方法。下麵給出了3種類型的授權依賴。(1)訪問依賴（《access》）(2)導入依賴（《import》）(3)友元依賴（《friend》）依賴（dependency）4．綁定依賴它表明對目標範本使用給定的實際參數進行實例化。當對範本類的細節建模時，要使用綁定（《bind》）。例如，範本容器類和這個類的實例之間的關係被模型化為綁定依賴。綁定包括一個映射到範本的形式參數的實際參數列表。3.3.2泛化（generalization）泛化（generalization）是一般事物（稱為父類或超類）和較特殊事物（稱為子類或孩子類）之間的關係。例如，你可能遇到一般類Client（用戶類）和它的較特殊類Librarian(管理員類)。泛化的用途

一種用途是用來定義下列情況：當一個變數（如參數或過程變數）被聲明承載某個給定類的值時，可使用類的實例，這被稱作可替換性原則。該原則表明後代的一個實例可以用於任何祖先被聲明的地方。例如，如果一個變數被聲明為圖書管理員，那麼他就可代替用戶實例。另一個用途是在共用父類所定義的成員的前提下允許它增加自身定義的描述，這被稱作繼承。繼承允許描述的共用部分只被聲明一次而可以被許多子類所共用，而不是在每個類中重複聲明並使用它，這種共用機制減小了模型的規模。更重要的是，它減少了為了模型的更新而必須做的改變和意外的前後定義不一致。泛化示例例如水陸兩用汽車他即是汽車又是船，那麼在對交通工具進行抽象時，就可認為水陸汽車類即繼承了汽車類又繼承了船類，這就是多重繼承。3.3.3實現（realization）實現（realization）是類元（類）之間的語義關係，關係中的一個類元（類）描述了另一個類元（介面）實現的契約。也就是說，實現關係中的一個類只具有行為的定義，而具體的結構和行為，則是由另一個類來給出。例如3.3.4關聯（association）關聯是一種結構關係，它詳述了一個事物的對象與另一個事物的對象相互聯繫。例如，類Library（圖書館類）與類Book（書類）就是一種一對多的關聯，這表明每一個Book實例僅被一個Library實例所擁有。此外，給定一個Book，能夠找到它所屬的Library，給定Library，能夠找到它的全部Book。在UML中，把關聯畫為連接相同或不同的類的一條實線。當要表示結構關係時，就使用關聯。3.3.4關聯（association）示例3.3.1

請對書與書目之間的關係建模3.3.4關聯（association）在UML中，有4種可應用到關聯的基本修飾：關聯名關聯端的角色關聯端的多重性聚合(1)關聯名即名稱關聯可以通過命名的方式來描述關係的性質。此關聯名稱應該取為動詞短語，因為它表明源對象正在目標對象上執行的動作。為了消除名稱含義的歧義，UML中提供了一個指引讀者名稱方向的三角形，並給名稱一個方向。3.3.4關聯（association）示例3.3.2

在圖書館管理系統中的書與書目記錄之間是存在著一種關聯關係。這種關聯關係可以稱為“擁有”而名稱的方向是指向書目類。如圖3.3.7所示。3.3.4關聯（association）(2)角色當一個類處於關聯的某一端時，該類就在這個關係中扮演了一個特定的角色。它呈現的是對另一端的職責。可以顯式地命名類在關聯中所扮演的角色。(3)多重性關聯表示了對象間的結構關係。有時在建模時需要說明一個關聯的實例中有多少個相互連接的對象。3.3.4關聯（association）(4)聚合在實際建模中，往往需要對“整體/部分”的關係進行描述。在這種關係中，其中一個類所描述的是一個較大的事物（即“整體”），它由較小的事物（“部分”）組成。這種關係在面向對象中就稱為聚合，它描述了“has-a”的關係，意思是整體對象擁有部分對象。在UML中被表示為在整體的一端用一個空心菱形修飾的簡單關聯。例如，在對學校的組織結構進行建模時，學校和系部之間就存在著這種“整體/部分”的關係，因為一所學校裏肯定會設置多個系部。如關聯如圖3.3.9所示。3.3.4關聯（association）(4)聚合3.3.4關聯（association）(5)組合：組合是聚合的一種形式，它具有強的擁有關係，而且整體與部分的生命週期是一致的。帶有非確定多重性的部分可以在組合物自身之後創建，但創建後，就同生共死，即整體釋放部分也跟著被釋放。例如，視窗系統中，一個Frame只屬於一個Window。如圖3.3.10所示。在UML中，組合是一種特殊的關聯，用整體端有實心菱形箭頭的簡單關聯修飾它。3.3.4關聯（association）(6)導航：給定兩個類（如Book類和Library類）之間的一個簡單的、未加修飾的關聯，從一個類的對象能夠導航到另一個類的對象。除非另有指定，否則關聯的導航是雙向的。例如圖書館管理系統中，對象Librarian（管理員）和Password之間有一個關聯。給定一個管理員，就需要找到對應的對象Password，反之不需要成立.任務解決-分析該模組中的類存在如下關係：1．關聯關係所有的操作介面類與管理類之間就是一種普通的關聯關係。

2．泛化關係我們可將管理員類和讀者類相同的特性和操作抽象出來形成一個父類（Client），那麼管理員類、讀者類與用戶類之間就是一種泛化關係任務解決-繪製類圖在類圖中繪製類的關係圖。精練請您根據本節所學的知識解決專案中的任務2分析：圖書館的主要靜態模型類圖是由書籍管理類、書類、書目類、管理員類、用戶類和各種介面操作類組成。其中用戶類與管理員類是泛化的關係，而其他類之間均是關聯關係。請根據演示部分繪製類圖的方法為書籍管理業務繪製類圖。3.4交互圖在業務系統靜態模型的基礎上，分析和設計系統的動態結構，並且建立相應的動態模型。動態模型描述了系統隨時間變化的行為，這些行為是從靜態視圖中抽取系統瞬間狀態的變化來描述的。在UML中，動態模型主要是通過交互圖和行為圖來描述。交互圖（InteractionDiagram）是由一組對象和它們之間的關係構成，其中包括在對象間的傳遞的資訊，它包括順序圖和協作圖。3.4.1順序圖（SequenceDiagram）順序圖（SequenceDiagram）是強調消息時間順序的交互圖。順序圖描述了類相互協作的完成預期行為的動態過程。順序圖向用戶提供了隨時間推移、清晰和可視的事件流軌跡。

3.4.1順序圖（SequenceDiagram）示例3.4.1

繪製出圖書館管理系統中的用戶登錄活動的順序圖。分析：活動的執行的順序是：(1)啟動登錄介面；(2)錄入用戶的帳號和口令；(3)校驗用戶帳號和口令；(4)取出用戶帳號和口令。3.4.1順序圖（SequenceDiagram）3.4.1順序圖（SequenceDiagram）順序圖的組成：(1)類角色（ClassRole）(2)生命線（Lifeline）(3)啟動期（Activation）(4)消息（Message）3.4.1順序圖（SequenceDiagram）順序圖的特徵：(1)順序圖有生命線(2)順序圖有啟動期3.4.2協作圖（CollaborationDiagram）協作圖作為另一種交互圖而言，強調的是參加交互的對象的組織。協作圖只對相互間有交互作用的對象和這些對象間的關係建模，而忽略了其他沒有交互的對象和關聯。協作圖不僅可以表示對象間的關聯，而且可以表現對象間的資訊傳遞。3.4.2協作圖（CollaborationDiagram）示例3.4.2繪製出圖書館管理系統中的用戶登錄活動的協作圖。3.4.2協作圖（CollaborationDiagram）協作圖的組成：(1)類角色（ClassRole）(2)關聯角色（AssociationRole）(3)消息流（MessageFlow）3.4.2協作圖（CollaborationDiagram）協作圖的特徵：(1)協作圖有路徑(2)協作圖有順序號任務解決-分析1．借書交互操作的動態建模由業務模型對借書交互操作的描述可知，借書是圖書管理的最基本的功能。它是由管理員角色、借書窗體類（LendFrame）、書籍管理類（BookManager）、書籍類（Book）、書目類（Item）、借書記錄類（Loan）、讀者管理類（ReaderManager）和讀者類（Reader）組成。

2．還書的交互操作動態建模從對還書業務的描述可知該交互操作的動態建模，是由：管理員角色、還書窗體類（ReturnFrame）、書籍管理類（BookManager）、書籍類（Book）、書目類（Item）和借書記錄類（Loan）組成。任務解決任務解決任務解決任務解決精練請您根據本節所學的知識解決專案中的任務2分析：根據演示部分對圖書業務功能模組中的交互操作進行動態建模的操作步驟和方法，請你對書籍管理模組中的交互操作進行動態建模。該模組中主要存在新增書籍、修改書籍資訊和刪除書籍三種交互操作。4.1.1對象圖(ObjectDiagram)對象圖（ObjectDiagram）是描述在某一時刻，一組對象以及它們之間關係的圖形。

對象圖可以看作是類圖在系統某一時刻的實例。對象圖表示的是被凍結的系統在運行時的某一瞬間的情況，類似於使用DVD播放機播放DVD光碟時，按下暫停（pause）鍵時，出現的靜止畫面。4.1.1對象圖(ObjectDiagram)對象圖中一般包括“對象”和“鏈”兩類基本的模型元素。1．對象(Object)一般來說，把類的具體表示稱為對象，對象是類的實例。4.1.1對象圖(ObjectDiagram)2．鏈（link）鏈是兩個或多個對象之間的獨立連接，是關聯的實例。通過鏈可以將多個對象連接起來，形成一個有序列表，稱為元組。4.1.1對象圖(ObjectDiagram)3．對象圖的建模技術要對對象結構建模，應遵循以下步驟:確定參與交互的各對象的類，可以參照相應的類圖和交互圖確定類間的關係，如依賴、泛化、關聯和實現確定在某特定時刻各對象的狀態值，使用對象圖為這些對象建模根據建模目標，繪製對象的關鍵狀態和關鍵對象之間的連接關係4.1.1對象圖(ObjectDiagram)4．提示和技巧在UML中創建對象圖時，要記住，每一個對象圖只是系統的靜態設計視圖或系統的靜態進程視圖的圖形表示。這意味著，並不需要用單個的對象圖來捕獲系統的設計視圖或進程視圖中的每一個事物。一個結構良好的對象圖，應滿足如下的要求：只包含關注表達系統靜態設計視圖或靜態進程視圖的一個方面只包含對理解系統運行關鍵時刻必不可少的對象只顯示對象中必不可少的屬性值不要過分地簡化，以免產生誤解4.1.2包(package)包是用於把元素組織成組的通用機制。包有助於組織模型中的元素，使你更容易理解系統模型，也可以控制對包的內容的訪問。UML提供了對包的圖形表示法。4.1.2包(package)1．包的名字和其他建模元素一樣，每個包都必須有一個區別於其他包的名字。4.1.2包(package)2．包擁有的元素包是對模型元素進行分組的機制，它把模型元素劃分成若干個子集。包可以擁有UML中其他元素，包括類、介面、組件、節點、協作、用例、甚至還可以包含其他子包。對包內所包含的建模元素可以使用文本或圖形的方式，加以顯示。4.1.2包(package)3．包的可見性包內的元素加以控制，使得某些元素能被外界訪問，可見某些元素不能被外界訪問。這就是所謂的包內元素可見性控制。可見性可以分成3種：公有訪問（public）保護訪問（protected）私有訪問（private）4.1.2包(package)圖4.1.6分別描述了三種類型的訪問可見性。4.1.2包(package)4．引入（import）與導出（export）引入（import）使得一個包中的元素可以單向訪問另一個包中的元素。導出（export）指的是包中具有公有訪問許可權的內含元素，一個包中“導出”部分僅僅只對顯示地引入這個包的其他包中的內含元素可見。4.1.2包(package)5．泛化關係在包之間可以有兩種關係：一種關係是引入和訪問依賴；另一種關係就是泛化。包間的泛化關係與類之間的泛化關係類似。 4.1.2包(package)6．標準元素UML的擴充機制同樣適用於包元素，可以使用標記值來增加包的新特性，用構造型來描述包的新種類。UML定義了5種構造型來為其標準擴充，分別是：虛包（facade）框架(framework)樁（stub）子系統（subsystem）系統(system)。4.1.2包(package)7．包建模技術①分析系統的模型元素（通常是對象類），把概念上或語義上相近的模型元素歸入同一個包。②對於每一個包，標出其模型元素的可視性，確定包內每個元素的訪問屬性，是公共、保護或私有。③確定包與包之間的依賴聯繫，特別是“引入”關係。④確定包與包之間的泛化關係。⑤繪製包圖。⑥對結果進行精化和細化。任務解決通過本節對對象圖的描述，可以知