【正文】 的狀態(tài)轉(zhuǎn)換空間 導(dǎo)致狀態(tài)轉(zhuǎn)換的事件 導(dǎo)致狀態(tài)改變的動(dòng)作 為類的重要?jiǎng)討B(tài)行為建立狀態(tài)轉(zhuǎn)換圖 超時(shí) 到達(dá) 上樓 上樓 到達(dá) 上樓 到達(dá) 在底樓 向上移動(dòng) 向底樓移動(dòng) 向下移動(dòng) 空閑 狀態(tài)圖 State Diagram 待 機(jī)開 機(jī)播 放UML狀態(tài)圖示例 電視機(jī) 世界上的萬事萬物在任何特定時(shí)刻總處于某一特定狀態(tài)。一個(gè)電梯可以處于上升、下降、停止?fàn)顟B(tài)。一輛汽車可以處于前行、后退、停止?fàn)顟B(tài)。 一臺電視機(jī)可以處于開機(jī)、播放、待機(jī)或關(guān)機(jī)狀態(tài) 。 活動(dòng)圖 ? 捕獲動(dòng)態(tài)行為（面向活動(dòng)的） 活動(dòng)圖 ? 捕獲動(dòng)態(tài)行為（面向活動(dòng)的 ? 目的 ?給商業(yè)工作流建模 ?給操作建模 活動(dòng)圖 Activity Diagram Disk free Disk full 顯示磁盤滿 顯示在打印 刪去顯示信息 建立打印文件 () ^() 活動(dòng)圖的符號集與狀態(tài)圖中使用的符號集類似。像狀態(tài)圖一樣，活動(dòng)圖也從一個(gè)連接到初始活動(dòng)的實(shí)心圓開始?；顒?dòng)是通過一個(gè)圓角矩形（活動(dòng)的名稱包含在其內(nèi)）來表示的?；顒?dòng)可以通過轉(zhuǎn)換線段連接到其他活動(dòng)，或者連接到判斷點(diǎn)，這些判斷點(diǎn)連接到由判斷點(diǎn)的條件所保護(hù)的不同活動(dòng)。結(jié)束過程的活動(dòng)連接到一個(gè)終止點(diǎn)（就像在狀態(tài)圖中一樣）。作為一種選擇， 活動(dòng)可以分組為泳道（ swimlane），泳道用于表示實(shí)際執(zhí)行活動(dòng)的對象 UML活動(dòng)圖示例（ ATM系統(tǒng)中“客戶插入卡”的活動(dòng)圖） 體系結(jié)構(gòu)和 UML 組織： 包 , 子系統(tǒng) 動(dòng)態(tài) 交互 狀態(tài)機(jī) 設(shè)計(jì)視圖 實(shí)現(xiàn)視圖 過程視圖 組件 類 , 接口 , 協(xié)作 活動(dòng)類 分布視圖 節(jié)點(diǎn) 用例圖 用例 UML靜態(tài)圖 ? 用例圖（ Use Case Diagram） ? 類圖 (Class Diagram) ? 對象圖 (Object Diagram) ? 構(gòu)件圖 (Component Diagram) ? 部署圖 (Deployment Diagram) UML動(dòng)態(tài)圖 ? 狀態(tài)圖（ State Diagram） ? 時(shí)序圖（ Sequence Diagram） ? 協(xié)作圖（ Collaboration Diagram） ? 活動(dòng)圖 （ Activity Diagram） UML建模方法與視圖 ? 用例建模 ? 用例圖 ? 類和對象（結(jié)構(gòu)）建模： ? 類圖 ? 對象圖 ? 行為（動(dòng)態(tài)）建模 ? 用例圖 ? 交互圖（順序圖、協(xié)作圖） ? 活動(dòng)圖 ? 狀態(tài)圖 ? 物理體系結(jié)構(gòu)建模 ? 構(gòu)件圖 ? 實(shí)施圖 UML過程 ? UML過程主要包括： ?用例驅(qū)動(dòng)（ usecasedriven） ?以體系結(jié)構(gòu)為中心（ architecturecentric） ?反復(fù)（ iterative） ?漸增式開發(fā)（ incremental） UML過程 ? 用例驅(qū)動(dòng)： ? 用用例方法獲取系統(tǒng)的功能需求，并以此驅(qū)動(dòng)需求分析之后的所以階段的開發(fā) ? 在需求階段，用例所包括的系統(tǒng)功能，需要用戶的確認(rèn) ? 在設(shè)計(jì)和實(shí)現(xiàn)階段，用例被實(shí)現(xiàn) ? 在測試階段，用例用于驗(yàn)證系統(tǒng)功能 需求 用例 分析 設(shè)計(jì) 實(shí)現(xiàn) 測試 用例視圖 并發(fā)視圖 部署視圖 構(gòu)件視圖 邏輯視圖 用例影響開發(fā)的所有階段 用例視圖影響其他視圖 UML過程 ? 以體系結(jié)構(gòu)為中心 ? 項(xiàng)目開發(fā)的早期，除了需求以外，另一個(gè)最主要的工作就是確定系統(tǒng)的體系結(jié)構(gòu) ? 體系結(jié)構(gòu)定義了系統(tǒng)的各部分、各部分的關(guān)系和交互、通信機(jī)制、如何增加和修改體系結(jié)構(gòu)的規(guī)則 ? 體系結(jié)構(gòu)決定了系統(tǒng)的功能和非功能部分 ? 非功能部分包括：性能、易理解性、易修改性、復(fù)用度 ? 在 UML中，通過定義可以層次化的“包”，來實(shí)現(xiàn)把一個(gè)大系統(tǒng)劃分成不同的小系統(tǒng) ? 確定體系結(jié)構(gòu)的基本方法是：分析、選擇、原型化、評估和精細(xì) UML過程 ? 反復(fù)迭代 ? 用 UML方法建模，可以反復(fù)多次，不需要一次完成 ? 通過反復(fù)，增加新信息、細(xì)化新的細(xì)節(jié) ? 每次反復(fù)，應(yīng)進(jìn)行評估，評估的內(nèi)容還應(yīng)包括：代價(jià)、風(fēng)險(xiǎn) ? 漸增式 ? 多次迭代，每次迭代增加新的用例和功能 ? 每次迭代，都是分析、設(shè)計(jì)、實(shí)現(xiàn)和測試的過程 ? 迭代的最大好處是分解了風(fēng)險(xiǎn)，不至于把失敗的風(fēng)險(xiǎn)留到開發(fā)的最后才發(fā)現(xiàn) 需求獲取與用例分析 需求開發(fā)過程的階段任務(wù) 需求開發(fā)過程的重要里程碑 需求獲取 需求分析 需求處理 需求驗(yàn)證 問題定義階段 需求分析階段 面向用戶確認(rèn)的需求描述 面向?qū)崿F(xiàn)的需求規(guī)格說明 用戶確認(rèn) 需求評審 面向?qū)崿F(xiàn)的細(xì)化 面向管理的規(guī)范 面向成果的驗(yàn)證 基于 UML的需求獲取 需求獲取與業(yè)務(wù)建模 ? 對于一個(gè)復(fù)雜的業(yè)務(wù)系統(tǒng)，我們可能涉及：公司組織、業(yè)務(wù)單位、部門和人員崗位、職責(zé)和功能、內(nèi)部和外邊網(wǎng)絡(luò)、客戶、業(yè)務(wù)信息流、行政和財(cái)務(wù)流等等 ? 為這個(gè)組織建立計(jì)算機(jī)系統(tǒng)，我們要回答： ? 為什么要建立這個(gè)系統(tǒng) ? 這個(gè)系統(tǒng)的定位在何處 ? 我們?nèi)绾未_定哪些功能是最適宜放在系統(tǒng)的特定節(jié)點(diǎn)上 ? 我們何時(shí)采用計(jì)算機(jī)處理而何時(shí)采用人工處理 ? 為適應(yīng)計(jì)算機(jī)處理，我們需要改變現(xiàn)有工作流程嗎 ? 回答這些問題的技術(shù)，就是業(yè)務(wù)建模 ? 業(yè)務(wù)建模的目的： 建模過程是開發(fā)者和用戶之間為導(dǎo)出需求規(guī)約而進(jìn)行的交互過程 因此： ? 理解現(xiàn)有業(yè)務(wù)組織的靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)運(yùn)作方式 ? 確?？蛻?、最終用戶以及開發(fā)人員對業(yè)務(wù)組織有共同的理解 ? 系統(tǒng)的邊界在那里？功能是什么？ ? 理解如何部署新的系統(tǒng)以提高生產(chǎn)力，以及現(xiàn)有的哪一個(gè)系統(tǒng)會(huì)受到新系統(tǒng)的影響 ? 系統(tǒng)的功能由用例來表示： 用例用來： ? 確定和描述系統(tǒng)的功能要求 ? 給出清晰和一致的系統(tǒng)做什么的描述 ? 為驗(yàn)證系統(tǒng)所需的系統(tǒng)測試提供基準(zhǔn) ? 提供從功能需求到系統(tǒng)實(shí)際類和操作的跟蹤能力 圖例 說明 業(yè)務(wù)處理 單位 業(yè)務(wù)處理 描述 表格制作 傳遞 存儲(chǔ) 收集資料 儲(chǔ)戶 存折 存取款單 存折 現(xiàn)金 存折 業(yè)務(wù)分類 存款單折 取款單折 存款處理 取款處理 利息文件 帳目文件 存取款業(yè)務(wù) B 2 系統(tǒng)分析 B 2 . 2表 格 名 稱 業(yè) 務(wù) 流 程 第 圖 / 共 張圖業(yè)務(wù)名稱： 制圖： 審核：單位名稱： 核對： 年 月 日傳統(tǒng)方法：業(yè)務(wù)流程圖 ——存取款業(yè)務(wù)處理過程 在 UML中的建模結(jié)構(gòu)就是 業(yè)務(wù)用例模型 和 業(yè)務(wù)對象模型 ? 領(lǐng)域模型 將系統(tǒng)語境中的重要概念描述為領(lǐng)域?qū)ο?，并建立這些領(lǐng)域?qū)ο笾g的關(guān)系 ? 業(yè)務(wù)模型 是領(lǐng)域模型的超集，包括： ：說明系統(tǒng)所支持的業(yè)務(wù)過程 ：領(lǐng)域模型和業(yè)務(wù)用例實(shí)現(xiàn) ? 業(yè)務(wù)用例模型 是業(yè)務(wù)系統(tǒng)預(yù)期功能的描述模型，是系統(tǒng)開發(fā)任務(wù)和作為產(chǎn)品提交時(shí)的最根本的系統(tǒng)工作描述 ? 業(yè)務(wù)對象模型 描述了實(shí)體和相互交互完成業(yè)務(wù)用例所需要的功能，是業(yè)務(wù)用例的實(shí)現(xiàn) ? 下面，我們用示例介紹 利用 UML概念進(jìn)行業(yè)務(wù)建模 業(yè)務(wù)過程與業(yè)務(wù)用例 ? 一個(gè) 業(yè)務(wù)過程 是根據(jù)組織目標(biāo)而采用組織資源來獲得預(yù)定義結(jié)果的一組邏輯相關(guān)的活動(dòng) ? 用一個(gè) 業(yè)務(wù)用例 代表一個(gè)業(yè)務(wù)過程 ? 業(yè)務(wù)用例包括： ? 角色（與業(yè)務(wù)活動(dòng)交互的人或系統(tǒng)） ? 用例（角色與業(yè)務(wù)元素交互完成工作的事件序列） ? 建立業(yè)務(wù)用例的過程： ? 確定行為者 ? 確定用例 確定行為者 ? 行為者： ? 與系統(tǒng)交互的人或其他系統(tǒng) ? 交互：發(fā)送、接收、交換信息 ? 行為者執(zhí)行用例 ? 行為者是一個(gè)角色，而不是具體個(gè)人 ? 尋找行為者 ? 誰使用系統(tǒng)的功能 ? 誰需要系統(tǒng)提供信息 ? 誰維護(hù)、管理、控制系統(tǒng) ? 系統(tǒng)完成功能還需要得到其他系統(tǒng)的支持 ? 還有哪些人對系統(tǒng)的結(jié)果感興趣 業(yè)務(wù)用例 – 銀行 確定用例 ?一個(gè)用例是被行為者感受到的一個(gè)完整的功能 UML的定義：用例是給一個(gè)特定行為者的一個(gè)可觀察的結(jié)果值的系統(tǒng)所完成的一系列動(dòng)作 這個(gè)動(dòng)作除計(jì)算機(jī)內(nèi)部完成的計(jì)算外，還包括與行為者的信息交互 用例通過關(guān)聯(lián)與行為者進(jìn)行交互 用例總是被行為者所啟動(dòng)，并回答一個(gè)可識別的結(jié)果 類似于對象是類的實(shí)例，用例的實(shí)例是場景（ scenario）。 例如：“用戶在 ATM機(jī)上執(zhí)行取款操作”用例的場景是：“張三在ATM機(jī)上取出 300元人民幣” 尋找用例 行為者需求系統(tǒng)提供哪些功能？ 行為者是否需要?jiǎng)?chuàng)建、讀、寫、修改、刪除系統(tǒng)中的信息？ 行為者是否需要被系統(tǒng)提醒、啟動(dòng)系統(tǒng)的某個(gè)功能？ 系統(tǒng)能否幫助行為者做一些事情，來提高行為者的效率、便利 尋找用例 考慮人和飲料販賣機(jī)的交互，包括購買飲料，首先，放置貨物（飲料）等，下面考慮購買飲料。 ? 用例 描述了系統(tǒng)的行為 ， 包括行為者和系統(tǒng)之間的交互以及系統(tǒng)與系統(tǒng)之間的交互 。 ? 用例 是系統(tǒng)提供的功能塊。演示了人們?nèi)绾问褂孟到y(tǒng)。它來自于 客戶需求的分析 。這個(gè)過程稱為 Use Case分析 , 是整個(gè)系統(tǒng)開發(fā)中非常關(guān)鍵的過程。 我們設(shè)計(jì)一個(gè)飲料販賣機(jī)，從用戶的角度來考察它的功能： 問 :“ 自動(dòng)飲料販賣機(jī)將為您做什么 ?” 答 :“ 我 通過自動(dòng)飲料販賣機(jī)購買一聽飲料 .” 飲料販賣機(jī)的主要功能是使得用戶可以購買飲料， 我們?yōu)檫@種機(jī)器標(biāo)記一個(gè)叫 “買飲料”的 use case. UML中的 Use Case 表示 Buy Soda Use Case Actor Communication Customer ? use case記錄用戶使用系統(tǒng)是從頭到尾的一系列事件 。 用戶普遍稱為 “ 活動(dòng)者 ” ，它可以是 人 或 另一個(gè)系統(tǒng) 。 ? 每一個(gè) use case 包括 “ 活動(dòng)者 ” 和一個(gè)表示 use case 的橢圓。 Use Case 活動(dòng)者 活動(dòng)者 可以是 人 或 另一個(gè)系統(tǒng) ， 它與當(dāng)前的系統(tǒng)交互 ，向系統(tǒng)提供 輸入 或從系統(tǒng)中獲得 輸出 。 Actor Name Telephone System (電話系統(tǒng)） 使用電話卡 對方付款 Phone User (電話用戶） 活動(dòng)者 的標(biāo)志 ? 誰 對某一需求感興趣？ ? 組織中 哪一部分 使用系統(tǒng) ? ? 誰 從系統(tǒng)的使用中受益 ? ? 誰 向系統(tǒng)提供信息？ ? 誰 將維護(hù)系統(tǒng)？ ? 系統(tǒng)使用 外部資源 嗎 ? ? 系統(tǒng)和 已經(jīng)存在的系統(tǒng) 交互嗎 ? 活動(dòng)者 的 類型 ? 實(shí)際的人，即用戶，是最常用的角色，幾乎每個(gè)系統(tǒng)都有。命名這些角色的時(shí)候，要按作用來命名，而不是按照位置命名。 ? 另外一個(gè)系統(tǒng)。例如航空訂票系統(tǒng)可能需要與外部應(yīng)用程序接口，驗(yàn)證信用卡以便購買。 ? 可能隱蔽的角色：時(shí)間。例如商業(yè)促銷項(xiàng)目推出免費(fèi)獎(jiǎng)，每天下午三點(diǎn)，系統(tǒng)自動(dòng)選擇向隨機(jī)客戶提供免費(fèi)獎(jiǎng)品。 在飲料自動(dòng)販賣機(jī)中，除了買飲料的 顧客 ， 還有以下的 活動(dòng)者 。 Buy Soda Restock Soda Collect Money Customer Supplier Collector 每一 種活 動(dòng)者 具有 自己 的 use case 飲料販賣機(jī)中的 活動(dòng)者 供應(yīng)商 向 自動(dòng)販賣機(jī)添加飲料。 收銀員 從 自動(dòng)販賣機(jī)收錢。 理解用例 ? 用例 獨(dú)立于實(shí)現(xiàn)。 用例 關(guān)注的是作用而不是如何實(shí)現(xiàn)這個(gè)作用。 ? 用例 是系統(tǒng)的高級視圖。用例的集合應(yīng)讓客戶易于了解高層的整個(gè)系統(tǒng)。 ? 最后， 用例 關(guān)注系統(tǒng)外的用戶。每個(gè) 用例 應(yīng)表示用戶與系統(tǒng)間的完整事務(wù)，為用戶提供一定價(jià)值。 用例 應(yīng)按業(yè)務(wù)術(shù)語命名，而不是按技術(shù)術(shù)語命名，應(yīng)讓客戶一目了然。 ? 例如： 用例 不要命名為 “ 客戶與銀行 ATM的交互界面 ” ，如果客戶要買票 , 用例可以稱為 “ 客戶購票 ” 。 ? 用例 分析有助于 : ?捕捉需求 ?計(jì)劃開發(fā)過程的循環(huán)往復(fù)。 ?驗(yàn)證系統(tǒng)。 ? 需求分析 從 用例 分析開始，它驅(qū)動(dòng)整個(gè)開發(fā)過程。 ? 在 用例 中描述了所有的功能需求。 標(biāo)記 用例 ? 活動(dòng)者希望這個(gè)系統(tǒng) 執(zhí)行 什么任務(wù)。 ? 活動(dòng)者在系統(tǒng)中 訪問 哪些信息 (創(chuàng)建 , 存儲(chǔ) , 修修改 , 刪除等 )? ? 外部的哪個(gè)變化將要 被告知 系統(tǒng)？ ? 系統(tǒng)的那個(gè)事件將要 被告知 活動(dòng)者？ ? 系統(tǒng)