【正文】 布線 4 合作圖 下圖為一銷售結(jié)果統(tǒng)計的合作圖 。 ， ， ， … 并行執(zhí)行： 標(biāo)號中帶小寫字母。 消息定義的格式如下： 消息類型 標(biāo)號 控制信息：返回值： =消息名 參數(shù)表 4 合作圖 控制信息 { 條件控制信息 如： ［ ｘ＞ｙ］ 重復(fù)控制信息 如：＊ ［ Ｉ＝ 1..n］ 標(biāo)號有３種： 順序執(zhí)行：按整數(shù)大小執(zhí)行。 ３ 、 消息 在對象之間的靜態(tài)鏈接關(guān)系上可標(biāo)注消息 ， 消息類型有簡單消息 ， 同步消息和異步消息三種 。 各種鏈接關(guān)系與類圖中的定義相同 ,在鏈接的端點位置可以顯示對象的角色名和模板信息 。 類似地 ,如果一個對象在交互期間被刪除 ,則可在對象名稱之后標(biāo)以 {destroy}。 4 合作圖 一、 合作圖中的模型元素 合作圖中對象的外觀與順序圖中的一樣 。 雖然順序圖和合作圖都用來描述對象間的交互關(guān)系 ,但側(cè)重點不一樣 。 發(fā)送和接收信號可以和消息的的發(fā)送對象和接收對象聯(lián)系在一起 ， 如下圖所示 。 接收符號也同轉(zhuǎn)移聯(lián)系在一起 。 發(fā)送信號 接收信號 ４、 對象流 活動圖中可以出現(xiàn)對象，對象作為活動 的輸入／輸出，用虛箭頭表示。 3 活動圖 三、活動圖舉例 帶泳道的會議申請活動圖 ５ 、控制圖符 活動圖中可發(fā)送和接收信號，發(fā)送符號對應(yīng)于與轉(zhuǎn)移聯(lián)系在一起的發(fā)送短句。 具體說泳道有如下目的：直接顯示動作在哪一個對象中執(zhí)行 ， 或顯示的是一項組織工作的哪部分 。 泳道也是一種分組機(jī)制。 ● 請求服務(wù) 支付 取貨 提貨 開訂單 供貨 3 活動圖 活動圖的模型元素： 泳道 圖 泳道 泳道進(jìn)一步描述完成活動的對象，并聚合一組活動?；顒訄D是另一種描述交互的方式，描述采取何種動作，做什么（對象狀態(tài)改變），何時發(fā)生（動作序列），以及在何處發(fā)生（泳道）。 轉(zhuǎn)移用帶箭頭的直線表示，可標(biāo)注執(zhí)行該轉(zhuǎn)移的條件，無標(biāo)注表示順序執(zhí)行。 活動名 [條件 1] [條件 2] 活動圖 二、活動圖的模型元素 活動還有其它的圖符：初態(tài)、終態(tài)、判斷、同步。 活動的解釋依賴于作圖的目的和抽象層次，在概念層描述中，活動表示要完成的一些任務(wù)；在說明層和實現(xiàn)層中，活動表示類中的方法。 3 活動圖 一、概述 二、活動圖的模型元素 3 活動圖 構(gòu)成活動圖的模型元素有：活動、轉(zhuǎn)移、對象、信號、泳道等。 刻化一個方法中所要進(jìn)行的各項活動的執(zhí)行流程 。 活動圖是由狀態(tài)圖變化而來的 ,它們各自用于不同的目的 。 當(dāng)對象消亡 (destroying)時，用符號 ? 表示。 因此 ， 包括了分支 ， 條件和循環(huán) 。 沒有任何條件和分支或循環(huán) ， 它僅僅顯示選定情節(jié) （ 場景 ） 的交互 （ 如下圖所示 ） 。 有兩種使用順序圖的方式：一般格式和實例格式 。 消息 延遲： 用傾斜箭頭表示 。 同步消息 (synchronous)： 表示發(fā)送對象必須等待接收對象完成消息處理后 ， 才能繼續(xù)執(zhí)行 。 二、 消息 控制信息 { 條件控制信息 如： ［ ｘ＞０］ 重復(fù)控制信息 如：＊ ［ Ｉ＝ 1..n］ 簡單消息 (simple)： 表示消息類型不確定或與類型無關(guān) 。 2 順序圖 順序圖 (Sequence Diagram)用來描述對象之間動態(tài)的交互行為 ,著重體現(xiàn)對象間 消息傳遞的時間順序 。 順序圖中每個對象圖符下面的垂直虛線表示對象的生命線 ， 每條對象生命線上的細(xì)長矩形表示該對象正處于活動時期 ， 細(xì)長矩形底部的 “ ‖表示該對象被刪除 。 狀態(tài)圖之間的消息發(fā)送 狀態(tài)圖之間可以發(fā)送消息，用虛箭頭表示。 收到來自外部對象的某個操作中的一個調(diào)用， 表示為狀態(tài)遷移上的事件特征，也稱為 消息。 在 UML中 ， 有 4類事件： 某條件變?yōu)檎妫槐硎緺顟B(tài)遷移的上的警戒條件。 狀態(tài)名 （狀態(tài)變量） 活動 細(xì)化電梯狀態(tài)圖 在第一層 上行 上升 到指定樓層 上行 空閑 時間 =0 開始計時 到達(dá) 下降 到指定樓層 下行 超時 移到 第一層 到達(dá) 到達(dá) 1 狀態(tài)圖 1 狀態(tài)圖 或關(guān)系的子狀態(tài)圖 嵌套 狀態(tài) 圖 狀態(tài)圖可能有嵌套的子狀態(tài)圖 ， 且子狀態(tài)圖可以是另一個狀態(tài)圖 。 如果轉(zhuǎn)移上未標(biāo)明事件 ,則表示在源狀態(tài)的內(nèi)部活動執(zhí)行完畢后自動觸發(fā)轉(zhuǎn)移 。 例 : 無參數(shù) 1 狀態(tài)圖 遷移 login 狀態(tài)圖 login login time=curent time entry/type ―login‖ do/get use name do/get password help/display help exit/login() 1 狀態(tài)圖 狀態(tài) 遷移 （ 轉(zhuǎn)換 ） 一個對象的狀態(tài)的變遷稱為狀態(tài)遷移 。 exit事件用于指明退出該狀態(tài)時的特定動作。 活動 列出了在該狀態(tài)時要執(zhí)行的事件和動作。 復(fù)合狀態(tài) —可以進(jìn)一步細(xì)化的狀態(tài)稱作復(fù)合狀態(tài) 。 而終態(tài)則可以有多個 。 狀態(tài)圖中定義的狀態(tài)有 : 初態(tài) —狀態(tài)圖的起始點 ,一個狀態(tài)圖只能有一個初態(tài) 。 狀態(tài) 所有對象都具有狀態(tài) ,狀態(tài)是對象執(zhí)行了一系列活動的結(jié)果 。 1 狀態(tài)圖 狀態(tài)圖 (State Diagram)用來描述一個特定對象的所有可能的狀態(tài)及其引起狀態(tài)轉(zhuǎn)移的事件 。操作的執(zhí)行者要到消息相應(yīng)操作執(zhí)行完并回送一個簡單消息后，再繼續(xù)執(zhí)行。 UML中的消息 一、簡單消息 (simple) 表示控制流，描述控制如何從一個對象傳遞到另一個對象，但不描述通信的細(xì)節(jié)。 動態(tài)模型主要描述系統(tǒng)的動態(tài)行為和控制結(jié)構(gòu)。 順序圖 (sequence diagram) ：是一種交互圖 ， 主要描述對象之間的動態(tài)合作關(guān)系以及合作過程中的行為次序 ，常用來描述一個用例的行為 。如下圖所示： 動態(tài)模型 狀態(tài)圖 (state diagram)： 狀態(tài)圖用來描述對象，子系統(tǒng)，系統(tǒng)的生命周期。 對象通過相互間的通信 (消息傳遞 )進(jìn)行合作 ,并在其生命周期中根據(jù)通信的結(jié)果不斷改變自身的狀態(tài) 。 動態(tài)行為包括系統(tǒng)中對象生存期內(nèi)可能的狀態(tài)以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移，對象之間動態(tài)合作關(guān)系，顯示對象之間的交互過程以及交互順序，同時描述了為滿足用例要求所進(jìn)行的活動以及活動間的約束關(guān)系。 包也可以有接口，接口與包之間用實線相連，接口通常由包的一個或多個類實現(xiàn)。表示為： 3 包圖 包內(nèi)容 包名 包名 包 A 包 B Oracle界面 Sybase界面 （ a）包的表示 (b)包的依賴關(guān)系 (c) 包的泛化關(guān)系 包圖 包 數(shù)據(jù)庫界面 和類一樣包也有可見性，利用可見性控制外部包對包的內(nèi)容的存取方式， UML中定義了四種可見性：私有 (private)，公有 (public)，保護(hù) (protected)和實現(xiàn) (implementation)。 表示為： 泛化關(guān)系： 使用繼承中通用和特例的概念來說明通用包和專用包之間的關(guān)系。 包之間的關(guān)系有依賴和泛化（繼承）。 僅在模型執(zhí)行期間包才有意義 。 包是一種組合機(jī)制 ， 把各種各樣的模型元素通過內(nèi)在的語義連在一起成為一個整體就叫包 ， 構(gòu)成包的模型元素稱為包的內(nèi)容 ， 包通常用于對模型的組 織 管 理 ， 因 此 有 時 又 將 包 稱 為 子 系 統(tǒng)（ subsystem） 。 UML中這種分組機(jī)制叫 包(Package)。 見下圖： 醫(yī)生 用戶名 密碼 查看病情報告 （ ） 要求打印病情報告 （ ） 查看病歷 （ ） 要求打印病歷 （ ） 病人 姓名 性別 年齡 病癥 提供病癥信號 （ ） 用戶名 密碼 查看病情報告 （ ） 打印病情報告 （ ） 值班護(hù)士 病癥監(jiān)視 采集頻率 病癥信號 格式化信號數(shù)據(jù) （ ） 采集信號 （ ） 信號組合 （ ） 靜態(tài)建模 ——例：建立 “ 醫(yī)院病房監(jiān)護(hù)系統(tǒng) ”的類與對象模型 值班護(hù)士 醫(yī)生 病人 病癥監(jiān)視 中央監(jiān)護(hù)系統(tǒng) 報警信號 標(biāo)準(zhǔn)病癥信號庫 病歷庫 病人病癥信號 病情報告 病歷 標(biāo)準(zhǔn)病癥信號 病人病癥信號 脈搏 血壓 體溫 生成病癥信號 （ ） 病歷 格式 病人基本情況 打印時間 生成病歷 （ ） 查看病歷 （ ） 打印病歷 （ ） 標(biāo)準(zhǔn)病癥信號 脈搏 血壓 體溫 生成標(biāo)準(zhǔn)信號 （ ） 標(biāo)題 格式 生成病情報告 （ ） 查看病情報告 （ ） 打印病情報告 （ ） 病情報告 報警信號 聲音 燈光 文字 報警 （ ） 數(shù)模轉(zhuǎn)化 （ ） 病歷庫 類型 大小 容量 生成病歷 （ ） 更新病歷 （ ） 查看病歷 （ ） 打印病歷 （ ） 類型 大小 容量 提供標(biāo)準(zhǔn)信號 （ ） 標(biāo)準(zhǔn)病癥信號庫 輸入 輸出 分解信號 （ ） 比較信號 （ ） 報警 （ ） 數(shù)據(jù)格式化 （ ） 中央監(jiān)護(hù)系統(tǒng) 類的識別 建立類的關(guān)系 ——在類圖中標(biāo)明類之間的關(guān)系： * * * * * * * 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 值班護(hù)士 醫(yī)生 病人 病癥監(jiān)視 病人病癥信號 病歷 病歷庫 病情報告 報警信號 中央監(jiān)護(hù)系統(tǒng) 標(biāo)準(zhǔn)病癥信號 標(biāo)準(zhǔn)病癥信號庫 1 1 1 報警 監(jiān)視 系統(tǒng)類圖 3 包圖 一個最古老的軟件方法問題是 :怎樣將大系統(tǒng)拆分成小系統(tǒng) 。 盡管迄今為止人們似乎更強(qiáng)調(diào)實現(xiàn)層類圖 ,但這三個層次都可應(yīng)用于 UML,而且實際上另外兩個層次的類圖更有用 。 要正確地理解類圖 ,首先應(yīng)正確地理解上述三種層次 。 畫圖時 ,要從一個清晰的層次觀念出發(fā) 。 理解以上層次對于畫類圖和讀懂類圖都是至關(guān)重要的 。 實現(xiàn)層 只有在實現(xiàn)層 (Implementation)才真正有類的概念 ,并且揭示軟件的實現(xiàn)部分 。 現(xiàn)在這種情況正在發(fā)生變化 。 這主要是因為 OO語言中類的概念將接口與實現(xiàn)合在了一起 。 說明層 說明層 (Specification)類圖描述軟件的接口部分 ,而不是軟件的實現(xiàn)部分 。實現(xiàn)它們的類可以從這些概念中得出 ,但兩者并沒有直接的映射關(guān)系 。 描述了類圖的抽象層次和細(xì)化 (Refinement)關(guān)系 。 按照 Steve Cook和 John Dianiels的觀點 ,類圖分為三個層次： 概念層 、 說明層 、 實現(xiàn)層 。在設(shè)計階段 ,類圖描述類與類之間的接口 。 不完全泛 化 即未特化出它所有的子類，稱為是 不完全泛化 的，表示為 {inplete}. 有關(guān)泛化的約束 2 UML中類之間的關(guān)系 三、泛化 {plete} 人 女人 男人 性別 圖 b 完全泛化 交通工具 drive() 汽車 drive() 輪船 drive() drive()啟動 輪子轉(zhuǎn)動 drive()啟動 螺旋漿 Person 駕駛 drive()是 抽象操作 圖 c 泛化中的多態(tài)性 及帶識別名稱的泛化 交通工具 圖 a 重疊泛化 汽車 船 水陸兩棲車 繼承性的實例 泛化關(guān)系圖 圖 形 {abstract} 顏 色 中心位置 筆的粗細(xì) 移 動（） 旋 轉(zhuǎn)（） 顯 示（） {abstract} 2 維 {abstract} 定位 填充類型 縮放 填充 多邊形 邊數(shù) 頂點數(shù) 顯示 園 直徑 顯示 旋轉(zhuǎn) 線 端點 顯示 0 維 {abstract} 點 顯示 樣條 控制點 顯示 弧 半徑 起始角 弧度角 顯示 1 維 {abstract} 定位 縮放 維數(shù) 2 UML中類之間的關(guān)系 抽象類加說明 {abstract} 2 UML中類之間的關(guān)系 OrderLine Quantity:Integer isSatisfied