【正文】 制類，控制使用案例中事件順序。 Control Entity Actor Boundary 參與者 邊界對(duì)象 控制對(duì)象 實(shí)體對(duì)象 圖示 UML對(duì)類進(jìn)行了分類，既所謂： BCE模型 UML有三種基本的構(gòu)造型：邊界、實(shí)體和控制。 ? 在需求獲取階段得到的用例模型就是功能模型。 （ 3） 有負(fù)責(zé)分析和分配系統(tǒng)需求的小組對(duì)確認(rèn)可能有問(wèn)題的給定需求進(jìn)行評(píng)審并進(jìn)行必要的修改 。 需求分析 ——細(xì)化用例 細(xì)化用例的主要步驟： ?審查主角 ?細(xì)化描述 ?定義和細(xì)化事件流程 ?確定前置條件和后置條件 ?確定特殊需求 ?擴(kuò)展用例 需求分析 ——細(xì)化用例關(guān)系 為需求處理做準(zhǔn)備 ?在定義系統(tǒng)的用例規(guī)約之前，確定一份基本的術(shù)語(yǔ)詞匯表，以統(tǒng)一項(xiàng)目開(kāi)發(fā)中的用詞。 期望的結(jié)果 1. 工號(hào) 1000無(wú)論如何進(jìn)入不了系統(tǒng) ， 系統(tǒng)提示無(wú)此員工 2. 工號(hào) nj001也不能進(jìn)入系統(tǒng) ， 系統(tǒng)提示該操作員無(wú)權(quán)執(zhí)行卡號(hào)資源管理系統(tǒng) 3． 工號(hào) yd002可以進(jìn)入系統(tǒng) ， 并能打開(kāi)所有的功能菜單 測(cè)試結(jié)果描述 相符 測(cè)試人員 測(cè)試日期 20220308 復(fù)測(cè)人員 復(fù)測(cè)日期 備注 需求分析與類和對(duì)象建模 從現(xiàn)在開(kāi)始，我們完成了“需求獲取”階段的任務(wù)，進(jìn)入“需求分析”階段 ?需求獲取階段完成的標(biāo)志，是獲得用戶簽字確認(rèn)的需求描述 ?需求分析階段任務(wù)完成的標(biāo)志，是在經(jīng)過(guò)需求分析、需求處理后，通過(guò)“需求評(píng)審” 從現(xiàn)在開(kāi)始，我們要用面向“實(shí)現(xiàn)”的眼光，來(lái)看待需求 ?什么是面向?qū)崿F(xiàn)？ ?需求分析階段的“面向?qū)崿F(xiàn)”，是面向可交付成果 ?什么是面向成果？我們先看一下需求評(píng)審的要求 需求開(kāi)發(fā)過(guò)程的階段任務(wù) 需求開(kāi)發(fā)過(guò)程的重要里程碑 需求獲取 需求分析 需求處理 需求驗(yàn)證 問(wèn)題定義階段 需求分析階段 面向用戶確認(rèn)的需求描述 面向?qū)崿F(xiàn)的需求規(guī)格說(shuō)明 用戶確認(rèn) 需求評(píng)審 面向?qū)崿F(xiàn)的細(xì)化 面向管理的規(guī)范 面向成果的驗(yàn)證 基于 UML的需求分析 傳統(tǒng)的需求分析階段 需求分析階段的任務(wù)和步驟 ? 復(fù)查系統(tǒng)規(guī)模和目標(biāo) ? 研究現(xiàn)有系統(tǒng)功能 ? 導(dǎo)出新系統(tǒng)模型 ? 重新定義問(wèn)題 ? 導(dǎo)出和分析各種可選解決方案 ? 推薦行動(dòng)方針 ? 草擬開(kāi)發(fā)計(jì)劃 ? 書(shū)寫文檔提交審查 階段成果交付物： 需求定義文檔（需求規(guī)格說(shuō)明） 循環(huán) 需求分析 —— 需求獲取與需求分析的區(qū)別 需求獲取是面向用戶、在較高的抽象級(jí)別上對(duì)系統(tǒng)特性的定義 ?可以更多地關(guān)注系統(tǒng)的特性以及如何體現(xiàn)用戶的需求，以便更好地理解系統(tǒng)的形狀和形式 ?可以對(duì)系統(tǒng)的完整性、一致性以及對(duì)環(huán)境的適應(yīng)性進(jìn)行評(píng)估 ?在繼續(xù)大量投入之前，可以利用這些信息決定可行性和管理系統(tǒng)的范圍 ?可以脫離對(duì)具體需求進(jìn)行取舍和決策所帶來(lái)的風(fēng)險(xiǎn) ?需求獲取的目標(biāo)是用戶的認(rèn)可，因此，階段的驗(yàn)收標(biāo)志是用戶簽字確認(rèn)的需求描述 需求分析 —— 需求獲取與需求分析的區(qū)別 需求分析是面向系統(tǒng)實(shí)現(xiàn)、嚴(yán)格對(duì)系統(tǒng)需求的定義 ?定義系統(tǒng)的輸入、輸出、功能、屬性以及系統(tǒng)環(huán)境的屬性，決定系統(tǒng)的完整集合 ?面向系統(tǒng)技術(shù)實(shí)現(xiàn)，討論系統(tǒng)應(yīng)該做什么，因此，應(yīng)避免受項(xiàng)目進(jìn)度、計(jì)劃、預(yù)算、設(shè)計(jì)、測(cè)試等的影響 ?需求和設(shè)計(jì)是迭代進(jìn)行的，但需求將引導(dǎo)設(shè)計(jì)，也受設(shè)計(jì)方法的制約 ?需求分析的驗(yàn)收標(biāo)志是組織的需求評(píng)審 需求分析 —— 細(xì)化系統(tǒng)定義 在需求獲取階段，我們已經(jīng)通過(guò)建立業(yè)務(wù)模型、系統(tǒng)模型，與用戶共同確定了系統(tǒng)的特性： ?業(yè)務(wù)用例模型 ，可以映射出軟件產(chǎn)品核心的需求，包括與業(yè)務(wù)功能對(duì)應(yīng)的組織的特性，與業(yè)務(wù)流程對(duì)應(yīng)的內(nèi)外部關(guān)系特性等； ?系統(tǒng)用例模型 ，是在已經(jīng)建立的業(yè)務(wù)模型的基礎(chǔ)上，建立系統(tǒng)的模型。 （ 1） 從業(yè)務(wù)用例到實(shí)現(xiàn)用例 （ 2） 從業(yè)務(wù)用例到測(cè)試用例 用 例 實(shí) 現(xiàn)涉 眾 需 求補(bǔ) 充 需 求測(cè) 試 用 例測(cè) 試 用 例產(chǎn) 品 特 性系 統(tǒng) 定 義用 例實(shí) 現(xiàn)系 統(tǒng) 測(cè) 試用例 編號(hào) 描述 燈的狀態(tài) 預(yù)期結(jié)果 開(kāi)關(guān) 1 基本流：住戶按下按扭的時(shí)間小于 1秒 開(kāi) 關(guān)并記憶亮度 2 基本流：住戶按下按扭的時(shí)間小于 1秒 關(guān) 按記憶亮度開(kāi) 3 其他流：住戶按下按扭的時(shí)間大于 1秒 開(kāi) 亮度按 10%/秒速度上升達(dá)到最大后下降并循環(huán) 4 其他流：住戶按下按扭的時(shí)間大于 1秒 關(guān) 先開(kāi)，然后再同上循環(huán) 5 其他流：住戶按下按扭的時(shí)間大于 1秒后松開(kāi)了開(kāi)關(guān) 開(kāi) 停在當(dāng)時(shí)的亮度位置 6 其他流：住戶按下按扭的時(shí)間大于 1秒后松開(kāi)了開(kāi)關(guān) 關(guān) 停在當(dāng)時(shí)的亮度位置 根據(jù)用例的事件流分析，針對(duì)用例情景，產(chǎn)生驗(yàn)收測(cè)試用例。 V模型的價(jià)值在于它非常明確地標(biāo)明了測(cè)試過(guò)程中存在的不同級(jí)別 ， 并且清楚地描述了這些測(cè)試階段和開(kāi)發(fā)過(guò)程期間各階段的對(duì)應(yīng)關(guān)系 。 ? 是否考慮了 維護(hù)問(wèn)題 ，要有人啟動(dòng)和關(guān)閉系統(tǒng)。 ?驗(yàn)證系統(tǒng)。 用例 關(guān)注的是作用而不是如何實(shí)現(xiàn)這個(gè)作用。 ? 另外一個(gè)系統(tǒng)。它來(lái)自于 客戶需求的分析 。活動(dòng)是通過(guò)一個(gè)圓角矩形（活動(dòng)的名稱包含在其內(nèi)）來(lái)表示的。 ? 順序圖和協(xié)作圖同構(gòu)的 ：兩種圖之間可以相互轉(zhuǎn)換，而沒(méi)有任何信息損失。第四部分 軟件工程的需求過(guò)程 《 軟件工程 》 傳統(tǒng)的需求分析方法 1 面向?qū)ο蟮男枨蠓治龇椒?2 基于 UML的需求分析方法 3 需求工程與需求管理實(shí)現(xiàn) 4 第四部分 軟件工程的需求過(guò)程 第三章 基于 UML的需求分析方法 UML概述 需求獲取與用例建模 類與對(duì)象建模 動(dòng)態(tài)建模 物理體系結(jié)構(gòu)建模 第四部分 軟件工程的需求過(guò)程 UML概述 UML——統(tǒng)一 OO方法大戰(zhàn)的努力 ? 1960年 70年代 ? COBOL, FORTRAN, C ? 結(jié)構(gòu)化分析和設(shè)計(jì)技術(shù) ? 1980年 1990年前 ? Smalltalk, Ada, C++, Visual Basic ? 早期面向?qū)ο笊桑ùa）方法 ? 1990年中晚期 ? Java ? Unified Process UML概要 ? UML是一種語(yǔ)言： ? 可視化 ? 詳細(xì)描述的 ? 構(gòu)造性的 ? 文檔化的 ? UML的價(jià)值 ? 是一個(gè)開(kāi)發(fā)的標(biāo)準(zhǔn) ? 支持完整的軟件開(kāi)發(fā)生命周期模型 ? 支持不同的應(yīng)用領(lǐng)域 ? 是基于經(jīng)驗(yàn)的和用戶群體需要的 ? 被許多工具支持 什么是 UML? ? Unified Modeling Language（統(tǒng)一建模語(yǔ)言）是國(guó)際對(duì)象管理組織 OMG制定的一個(gè)通用的、可視化建模語(yǔ)言標(biāo)準(zhǔn) ? 用于描述（ specify）、可視化（ visualize）、構(gòu)造（ construct）和記載（ document）軟件密集型系統(tǒng)的各種工件 ? UML提供了一系列建模元素、概念、關(guān)系以及規(guī)則，應(yīng)用于軟件開(kāi)發(fā)活動(dòng) ? 詳細(xì)內(nèi)容，請(qǐng)學(xué)習(xí) 《 統(tǒng)一軟件開(kāi)發(fā)過(guò)程 》 （ The Unified Software Development Process）（美） Ivar Jacobson、Grady Booch、 James Rumbaugh著，周伯生、馮學(xué)民、樊東平譯（機(jī)械工業(yè)出版社） UML概念 ? UML—— Unified Modeling Language. ? 組合了當(dāng)前最好的面向?qū)ο筌浖７椒? ? UML三位主要貢獻(xiàn)者 ? 1. OMT方法（對(duì)象、動(dòng)態(tài)、功能模型， James Rumbaugh） ? 2. The Booch method （ 5個(gè)步驟， Grady Booch） ? 3. OOSE （ User Case圖， Ivar Jacobson） James Rumbaugh Grady Booch Ivar Jacobson UML概念 ? 1994年， Booch和 Rumbaugh在 Rational開(kāi)始了UML的工作，但是的目標(biāo)是創(chuàng)建一個(gè)“統(tǒng)一方法” ? 他們把 Booch93和 OMT2統(tǒng)一起來(lái)，與 95年發(fā)布了 （ Unified Method） ? 1995年 OOSE的創(chuàng)始人 Jacobson加入到這個(gè)聯(lián)盟中，開(kāi)始把工作重點(diǎn)放到創(chuàng)建一種標(biāo)準(zhǔn)建模語(yǔ)言，UML—— Unified Modeling Language。由一組對(duì)象、對(duì)象間的關(guān)系、對(duì)象間發(fā)送的消息組成一種動(dòng)態(tài)視圖，可以單獨(dú)使用、也可以對(duì)用例中的特定控制流程建模。像狀態(tài)圖一樣，活動(dòng)圖也從一個(gè)連接到初始活動(dòng)的實(shí)心圓開(kāi)始。演示了人們?nèi)绾问褂孟到y(tǒng)。命名這些角色的時(shí)候，要按作用來(lái)命名，而不是按照位置命名。 理解用例 ? 用例 獨(dú)立于實(shí)現(xiàn)。 ? 用例 分析有助于 : ?捕捉需求 ?計(jì)劃開(kāi)發(fā)過(guò)程的循環(huán)往復(fù)。 ? 每個(gè)操作員從系統(tǒng) 接收了什么信息。 ?這樣 ， 我們就建立了一張描述 “ 活動(dòng) ” 的 Use Case圖 ， 通過(guò)這張圖 ，我們就能夠比較具體地描述 “ 活動(dòng) ” ， 即讓用戶看到： ?誰(shuí)與系統(tǒng)交互 ， 有助于發(fā)現(xiàn)缺少的參與者 ?知道系統(tǒng)的范圍 ， 有助于發(fā)現(xiàn)缺少的功能 業(yè)務(wù)用例描述：柜臺(tái)取款 業(yè)務(wù)用例活動(dòng)圖 ： 柜臺(tái)取款 注意： 這里只有角色（客戶）和用例（系統(tǒng)） 對(duì)于系統(tǒng)內(nèi)部的實(shí)現(xiàn)，我們還沒(méi)有更多的涉及 從業(yè)務(wù)模型到系統(tǒng)模型 ATM 系統(tǒng)用例 – ATM 系統(tǒng)用例 ATM取款 用例時(shí)序圖 ATM取款 系統(tǒng)開(kāi)始區(qū)分 ATM系統(tǒng)和銀行主機(jī)系統(tǒng) 用例的層次 ? 概要目標(biāo)用例： 需要多個(gè)用戶目標(biāo)會(huì)話來(lái)完成（日、周、月、年） ? 用戶目標(biāo)用例 ： 滿足特定、迫切、有價(jià)值的用例目標(biāo)（分鐘、小時(shí)） ? 子功能用例： 為了完成用戶的真實(shí)目標(biāo)而提供的功能 用戶目標(biāo)層 ? ―Can the actor go away happy after having done this?‖ ? 通常 1個(gè)人， 1次性完成， 220分鐘 概要目標(biāo)層 ? 使用 ATM用例：銀行自動(dòng)柜員機(jī) ? 含有多個(gè)用戶目標(biāo)，可包含：存取款、查詢、修改密碼、打印憑單、提供跨地域、跨銀行服務(wù) ? 作用 ?說(shuō)明用戶目標(biāo)執(zhí)行的背景 ?說(shuō)明相關(guān)目標(biāo)的范圍 ?提供了下層用例的目錄 用戶目標(biāo)層次 用例分析流程 1. 定義系統(tǒng)范圍和邊界 2. 列出角色及其作用 3. 提取概要用例并調(diào)整得當(dāng) 4. 著重對(duì)系統(tǒng)的用戶目標(biāo)層用例進(jìn)行細(xì)化 5. 填寫干系人責(zé)權(quán)利、前置后置條件 6. 編寫基本流 7. 列出所有擴(kuò)展條件，編寫擴(kuò)展處理步驟 8. 用活動(dòng)圖、狀態(tài)圖、交互圖等描述重點(diǎn)用例 9. 分解、合并用例，調(diào)整用例關(guān)系模型（用例圖） 需求獲取 ——關(guān)鍵是獲得用戶的確認(rèn) 建立業(yè)務(wù)模型的工作主要包括： ?分析領(lǐng)域中的業(yè)務(wù)角色 ?分析角色間的業(yè)務(wù)功能等關(guān)系 ?分析業(yè)務(wù)組織架構(gòu) ?分析業(yè)務(wù)規(guī)則 ?分析業(yè)務(wù)實(shí)體 ?分析業(yè)務(wù)事件 ?分析以業(yè)務(wù)角色為主角的業(yè)務(wù)用例等； 以業(yè)務(wù)用例為實(shí)例，與用戶進(jìn)行溝通： ?需求是否被清楚地陳述？ ?存在錯(cuò)誤的理解嗎？ ?需求的來(lái)源（人員、規(guī)章制度、文件）是否正確？ ?需求的最終陳述是否得到用戶最終責(zé)任人確認(rèn)？ 問(wèn)題 用戶不知道他們需求什么或不知道如何表達(dá) 直到開(kāi)發(fā)人員把用戶所描述的東西給他們，用戶才認(rèn)為知道自己要什么 分析人員認(rèn)為自己比用戶更了解用戶的需求 解決方案 將用戶當(dāng)作領(lǐng)域?qū)＜襾?lái)認(rèn)識(shí)和感激， 嘗試一下其他溝通和啟發(fā)技術(shù) 盡早提供相互選擇的啟發(fā)技術(shù)：情節(jié) 串聯(lián)板、原型、角色換位等 把分析人員放在用戶的位置，試著換位一小時(shí)或一天 解決用戶和開(kāi)發(fā)人員綜合癥 用戶講故事 介紹游戲規(guī)則 輸出結(jié)果 幻燈片放映 動(dòng)畫(huà)制作 仿真演示 交互演示 現(xiàn)場(chǎng)演示 被動(dòng)式介紹 主動(dòng)式介紹 交互式介紹 需求誘導(dǎo)的方法（情節(jié)串聯(lián)板） 原型開(kāi)發(fā) 復(fù)雜程度與成本 需求獲取過(guò)程需求管理的關(guān)注點(diǎn) 步驟： 發(fā)現(xiàn)和分析問(wèn)題 理解用戶的需求 定義系統(tǒng) （ 用例模型 ） 管理范圍 （ 項(xiàng)目管理 ） 方法： 采用業(yè)務(wù)建模和系統(tǒng)建模的方法進(jìn)行問(wèn)題分析