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