【正文】 ? 關(guān)聯(lián)表示了兩個(gè)或多個(gè)類(lèi)之間的關(guān)系。 ? 在模擬不同的場(chǎng)景中會(huì)發(fā)現(xiàn)某些職責(zé)需要重新加以分配。 職責(zé) 顯示歡迎詞 密碼驗(yàn)證器 接收磁卡 菜單選擇器 讓密碼驗(yàn)證器檢驗(yàn) 啟動(dòng)菜單選擇器 退出磁卡 類(lèi)名 讀卡機(jī) 協(xié)作 職責(zé) 從賬戶(hù)中取出密碼 賬戶(hù) 如無(wú)此賬戶(hù)返回假值 提示客戶(hù)輸入密碼 讀入密碼 比較核實(shí) , 返回結(jié)果 類(lèi)名 密碼驗(yàn)證器 協(xié)作 職責(zé) 檢查賬戶(hù)有效性 返回密碼 檢查取款 /存款信息 類(lèi)名 賬戶(hù) 職責(zé) 顯示菜單 存款管理器 等待客戶(hù)選擇 取款管理器 調(diào)用相應(yīng)的 存款 /取款管理器 類(lèi)名 菜單選擇器 協(xié)作 職責(zé) 詢(xún)問(wèn)取款額 賬戶(hù) 要求驗(yàn)證賬戶(hù) 出銀機(jī) 啟動(dòng)出銀機(jī)發(fā)款 類(lèi)名 取款管理器 協(xié)作 ④ 細(xì)化：模擬在執(zhí)行每個(gè)基本功能時(shí)系統(tǒng)內(nèi)部出現(xiàn)的場(chǎng)景，以此推動(dòng)細(xì)化工作的進(jìn)行。每一個(gè)類(lèi)可用一張 CRC卡片表示。 ? 實(shí)體對(duì)象允許邊界對(duì)象和控制對(duì)象訪問(wèn) 。 ? 順序圖第二欄是邊界對(duì)象 。消息的接受就觸發(fā)了一個(gè)操作。 ? 分析建模活動(dòng)包括以下步驟。 ⑧ ReserveDialog：預(yù)約對(duì)話框。根據(jù)圖書(shū)的館藏號(hào)查找館藏圖書(shū)。有根據(jù)借閱者 ID號(hào)碼查找借閱者的操作。有借書(shū)、還書(shū)、預(yù)約、取消預(yù)約、添加書(shū)種、修改書(shū)種、刪除書(shū)種、添加借閱者、修改借閱者、刪除借閱者、添加圖書(shū)復(fù)本、刪除圖書(shū)復(fù)本等操作。 ④ Loan：借閱記錄。 ② Title：館藏圖書(shū)。在有些情況下，用例的行為十分簡(jiǎn)單，這時(shí)可以沒(méi)有控制類(lèi)，圖書(shū)館系統(tǒng)中的用 登錄 就是這種情況。 ? 控制類(lèi)負(fù)責(zé)協(xié)調(diào)邊界類(lèi)和實(shí)體類(lèi)，通常在現(xiàn)實(shí)世界中沒(méi)有對(duì)應(yīng)的事物，它負(fù)責(zé)接收邊界類(lèi)的信息，并將其分發(fā)給實(shí)體類(lèi)。 ? 使用用戶(hù)的術(shù)語(yǔ)來(lái)描述接口，不要使用來(lái)自設(shè)計(jì)和實(shí)現(xiàn)的術(shù)語(yǔ)。 ? 標(biāo)識(shí)用戶(hù)需要鍵入系統(tǒng)的數(shù)據(jù)表格 。 標(biāo)識(shí)實(shí)體對(duì)象 標(biāo)識(shí)邊界對(duì)象 標(biāo)識(shí)控制對(duì)象 使用順序圖將用例映射為對(duì)象 使用 CRC卡片對(duì)對(duì)象之間的交互建模 標(biāo)識(shí)關(guān)系（結(jié)構(gòu)） 標(biāo)識(shí)屬性 對(duì)每一對(duì)象的與狀態(tài)有關(guān)的行為建模 分析模型評(píng)審 2) 標(biāo)識(shí)邊界對(duì)象 ? 在用例圖中，每一個(gè)參與者至少要與一個(gè)邊界對(duì)象交互。 語(yǔ)言成分 模型成分 示例 專(zhuān)有名詞 實(shí)例 人員乙 普通名詞 類(lèi) 現(xiàn)場(chǎng)工作人員 Doing動(dòng)詞 操作 創(chuàng)建、提交、選擇 Being動(dòng)詞 繼承 是 … 的一種，是 … 中的一個(gè) Having動(dòng)詞 聚合 有 … ，由 … 組成，包括 … 情態(tài)動(dòng)詞 約束 必須是 形容詞 屬性 事件描述 ? 自然語(yǔ)言分析法主要關(guān)注用戶(hù)術(shù)語(yǔ)。在實(shí)現(xiàn)中，真正需要自行創(chuàng)建的“類(lèi)”并不多，甚至不需要自己創(chuàng)建 類(lèi)庫(kù)就是按 BCE模型設(shè)計(jì)的 邊界類(lèi) 控制類(lèi) 實(shí)體類(lèi) 邊界類(lèi) 采用 BCE模式進(jìn)行類(lèi)設(shè)計(jì)的好處 優(yōu)點(diǎn)： 與系統(tǒng)的三層結(jié)構(gòu)直接對(duì)應(yīng) 可以把過(guò)去散布在 Client端、數(shù)據(jù)庫(kù)端等各處的程序邏輯，按 BCE模式，自然地劃分好，界面非常清楚 將商務(wù)邏輯封裝在控制中，可以隱蔽其復(fù)雜性 將實(shí)體獨(dú)立出來(lái)，以后可以直接將實(shí)體類(lèi)轉(zhuǎn)換為數(shù)據(jù)庫(kù)的表單，包括處理（面向?qū)ο蟮膬?yōu)點(diǎn)：存儲(chǔ)的數(shù)據(jù)與處理數(shù)據(jù)的功能封裝，同時(shí)隱蔽了數(shù)據(jù)庫(kù)系統(tǒng)的復(fù)雜性） 缺點(diǎn)： 增加了系統(tǒng)的復(fù)雜性（代價(jià)：在系統(tǒng)概要設(shè)計(jì)中分析） J2ME的用戶(hù)界面 Display類(lèi) Display類(lèi)管理MID的屏幕輸出 Displayable一個(gè)具體的顯示部件 Screen 標(biāo)準(zhǔn)的用戶(hù)界面 TextBox 文本框 Alert 報(bào)警 List 列表框 Form 窗體 Canvas 顯示的 運(yùn)行感知 StringItem Item ImageItem textField DateField Guage ChoiceGroup 可以看成是一個(gè)應(yīng)用系統(tǒng)的顯示子系統(tǒng) 需求分析要分析到哪層？ 根據(jù)系統(tǒng)規(guī)模而定 規(guī)模越大抽象層次越高 程序員要知道這里：如何使用 Display類(lèi) 具有兩個(gè)按鈕的手表的分析類(lèi) ? 使用實(shí)體對(duì)象、邊界對(duì)象和控制對(duì)象等概念對(duì)系統(tǒng)建模時(shí)，常常需要提供一些簡(jiǎn)單的啟發(fā)式規(guī)則來(lái)指導(dǎo)開(kāi)發(fā)人員使用這些概念，可以使用相應(yīng)的類(lèi)來(lái)跟蹤。 實(shí)體類(lèi)（ Entity Classes） 實(shí)體類(lèi)保存要放進(jìn)永久存儲(chǔ)體的信息，在 BCE模型中，通過(guò)實(shí)體類(lèi)將數(shù)據(jù)庫(kù)封裝起來(lái)。 UML類(lèi)的三種基本構(gòu)造型 控制類(lèi)（ Control Classes） 控制類(lèi)負(fù)責(zé)協(xié)調(diào)其他類(lèi)的工作。每個(gè)角色 /使用案例交互至少要有一個(gè)邊界類(lèi)。 ? 可用 UML提供的衍型機(jī)制，區(qū)分不同類(lèi)型對(duì)象。如數(shù)據(jù)庫(kù)、子系統(tǒng)、會(huì)話管理器、網(wǎng)絡(luò)等，不應(yīng)出現(xiàn)在分析模型中，因?yàn)檫@些概念僅與實(shí)現(xiàn)相關(guān)。 類(lèi)圖和對(duì)象圖： （ 1）類(lèi) /對(duì)象圖 ——靜態(tài)分析 類(lèi)名 屬性名：類(lèi)型 操作 類(lèi) 對(duì)象名：類(lèi)名 屬性名 = 值 操作 對(duì)象 對(duì)象圖使用與類(lèi)圖相同的形式 只是在對(duì)象名下加一個(gè)下劃線 對(duì)象名后可接以冒號(hào)和類(lèi)名 ? 分析模型由三個(gè)獨(dú)立的模型構(gòu)成：由 用例 和 場(chǎng)景 表示的功能模型；用 類(lèi) 和 對(duì)象 表示的分析對(duì)象模型；由 狀態(tài)圖 和 順序圖 表示的動(dòng)態(tài)模型。 所以，我們現(xiàn)在可以理解： 需求分析，就是為了實(shí)現(xiàn)系統(tǒng)需求，并使最后交付成果與需求所要求的目標(biāo)，不產(chǎn)生：含糊性、不完整性、不可檢驗(yàn)性、不一致性、不可追蹤性和不可用性，而進(jìn)一步對(duì)需求進(jìn)行描述和定義。 需求分析的成果 ——需求評(píng)審內(nèi)容 CMM2對(duì)評(píng)審內(nèi)容規(guī)定為： （ 1） 確定不完整和遺漏的給定需求； （ 2） 評(píng)審給定需求以確定他們是否：可行 、 適用于軟件實(shí)現(xiàn) 、 說(shuō)明清楚 、 適當(dāng) 、 彼此一致 、 可測(cè)試 。 ?系統(tǒng)主要的主角確定后，可以根據(jù)為系統(tǒng)主角提供有價(jià)值的結(jié)果（ Result of Value）這一準(zhǔn)則（用例是為主角的活動(dòng)最終提供一個(gè)有價(jià)值的結(jié)果的活動(dòng)過(guò)程）來(lái)確定系統(tǒng)的用例。 用例模型描述事件流 ， 包括主事件流 、 其他事件流 、前提條件 、 事后條件等等 。 需求分析 —— 細(xì)化系統(tǒng)定義 在需求分析階段，我們不可避免地要涉及到進(jìn)行設(shè)計(jì)決策 設(shè)計(jì)決策： ?硬件環(huán)境（運(yùn)行在 PC服務(wù)器上？還是小型機(jī)？） ?平臺(tái)的選擇（只支持 Windows平臺(tái)，是否也支持 UNIX平臺(tái)？） ?工具的限制（采用 VB實(shí)現(xiàn)？） ?方法的約束（用 XYZ類(lèi)庫(kù)實(shí)現(xiàn)數(shù)據(jù)庫(kù)訪問(wèn)？） 當(dāng)前需求使我們考慮采用某種設(shè)計(jì)選項(xiàng) 被選擇的設(shè)計(jì)選項(xiàng)可能影響需求 需求分析是在需求獲取、需求分析和設(shè)計(jì)決策之間反復(fù)迭代循環(huán)的過(guò)程 需求分析 —— 細(xì)化系統(tǒng)定義 軟件需求是具體的： ?面向系統(tǒng)設(shè)計(jì)、編碼 ?面向測(cè)試 因此，在需求獲取的基礎(chǔ)上，進(jìn)一步細(xì)化系統(tǒng)需求、明確和細(xì)化系統(tǒng)定義，這就是需求分析階段的任務(wù) 在傳統(tǒng)軟件過(guò)程方法中，這二個(gè)階段不是非常清晰和明確 系統(tǒng)需求 功能性需求 非功能性需求 設(shè)計(jì)約束 需求分析 ——細(xì)化用例 在需求獲取過(guò)程中 ， 我們建立了業(yè)務(wù)模型和系統(tǒng)模型 ， 引入了角色和用例的概念 角色與用例的區(qū)別： ?系統(tǒng)的角色是業(yè)務(wù)之外與業(yè)務(wù)交互的人或事 ?例如： ATM取款機(jī)作為一個(gè)業(yè)務(wù)系統(tǒng) ， 來(lái)取款的客戶(hù)就是一個(gè)角色 ?用例是業(yè)務(wù)模型中 ， 業(yè)務(wù)的活動(dòng) ?在系統(tǒng)模型中 ， 描述了業(yè)務(wù)中系統(tǒng)的工作 （ 內(nèi)部活動(dòng) ） 。 工號(hào)yd002是卡號(hào)資源管理系統(tǒng)的工號(hào) 。 系統(tǒng)中存在的工號(hào) nj001和正確的密碼 ， 檢查能否進(jìn)入系統(tǒng) 。 系統(tǒng)驗(yàn)收與用例的關(guān)系 驗(yàn)收測(cè)試的用例 ， 在需求獲取完成后產(chǎn)生 測(cè)試用例的依據(jù)是需求獲取的業(yè)務(wù)用例 。 ? 驗(yàn)收測(cè)試通常由項(xiàng)目組先提出測(cè)試大綱 ， 定義測(cè)試目的 、范圍 、 方法 、 測(cè)試用例 、 預(yù)期結(jié)果 、 驗(yàn)收標(biāo)準(zhǔn)等 。 ?這樣 ， 我們就建立了一張描述 “ 活動(dòng) ” 的 Use Case圖 ， 通過(guò)這張圖 ，我們就能夠比較具體地描述 “ 活動(dòng) ” ， 即讓用戶(hù)看到： ?誰(shuí)與系統(tǒng)交互 ， 有助于發(fā)現(xiàn)缺少的參與者 ?知道系統(tǒng)的范圍 ， 有助于發(fā)現(xiàn)缺少的功能 業(yè)務(wù)用例描述：柜臺(tái)取款 業(yè)務(wù)用例活動(dòng)圖 ： 柜臺(tái)取款 注意： 這里只有角色（客戶(hù)）和用例（系統(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è)用戶(hù)目標(biāo)會(huì)話來(lái)完成（日、周、月、年） ? 用戶(hù)目標(biāo)用例 ： 滿(mǎn)足特定、迫切、有價(jià)值的用例目標(biāo)（分鐘、小時(shí)） ? 子功能用例： 為了完成用戶(hù)的真實(shí)目標(biāo)而提供的功能 用戶(hù)目標(biāo)層 ? ―Can the actor go away happy after having done this?‖ ? 通常 1個(gè)人， 1次性完成， 220分鐘 概要目標(biāo)層 ? 使用 ATM用例：銀行自動(dòng)柜員機(jī) ? 含有多個(gè)用戶(hù)目標(biāo)，可包含：存取款、查詢(xún)、修改密碼、打印憑單、提供跨地域、跨銀行服務(wù) ? 作用 ?說(shuō)明用戶(hù)目標(biāo)執(zhí)行的背景 ?說(shuō)明相關(guān)目標(biāo)的范圍 ?提供了下層用例的目錄 用戶(hù)目標(biāo)層次 用例分析流程 1. 定義系統(tǒng)范圍和邊界 2. 列出角色及其作用 3. 提取概要用例并調(diào)整得當(dāng) 4. 著重對(duì)系統(tǒng)的用戶(hù)目標(biāo)層用例進(jìn)行細(xì)化 5. 填寫(xiě)干系人責(zé)權(quán)利、前置后置條件 6. 編寫(xiě)基本流 7. 列出所有擴(kuò)展條件，編寫(xiě)擴(kuò)展處理步驟 8. 用活動(dòng)圖、狀態(tài)圖、交互圖等描述重點(diǎn)用例 9. 分解、合并用例，調(diào)整用例關(guān)系模型（用例圖） 需求獲取 ——關(guān)鍵是獲得用戶(hù)的確認(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í)例，與用戶(hù)進(jìn)行溝通： ?需求是否被清楚地陳述？ ?存在錯(cuò)誤的理解嗎？ ?需求的來(lái)源（人員、規(guī)章制度、文件）是否正確？ ?需求的最終陳述是否得到用戶(hù)最終責(zé)任人確認(rèn)？ 問(wèn)題 用戶(hù)不知道他們需求什么或不知道如何表達(dá) 直到開(kāi)發(fā)人員把用戶(hù)所描述的東西給他們，用戶(hù)才認(rèn)為知道自己要什么 分析人員認(rèn)為自己比用戶(hù)更了解用戶(hù)的需求 解決方案 將用戶(hù)當(dāng)作領(lǐng)域?qū)＜襾?lái)認(rèn)識(shí)和感激， 嘗試一下其他溝通和啟發(fā)技術(shù) 盡早提供相互選擇的啟發(fā)技術(shù)：情節(jié) 串聯(lián)板、原型、角色換位等 把分析人員放在用戶(hù)的位置，試著換位一小時(shí)或一天 解決用戶(hù)和開(kāi)發(fā)人員綜合癥 用戶(hù)講故事 介紹游戲規(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)題 理解用戶(hù)的需求 定義系統(tǒng) （ 用例模型 ） 管理范圍 （ 項(xiàng)目管理 ） 方法： 采用業(yè)務(wù)建模和系統(tǒng)建模的方法進(jìn)行問(wèn)題分析 對(duì)與系統(tǒng)架構(gòu)和系統(tǒng)行為有關(guān)的用例進(jìn)行描述和定義 目標(biāo)： ?在問(wèn)題定義上與用戶(hù)達(dá)成共識(shí) ?理解問(wèn)題背后的根本原因 ?確定用戶(hù)和項(xiàng)目干系人 ?定義問(wèn)題解空間的邊界 ?確定問(wèn)題解決方案的約束和假設(shè) 最終階段完成標(biāo)志：用戶(hù)對(duì)系統(tǒng)目標(biāo)的認(rèn)可 —— 簽字 需求獲取過(guò)程產(chǎn)品基線管理的關(guān)注點(diǎn)