【正文】 ? 分析建?；顒影ㄒ韵虏襟E。 ② 將職責分配到類 ：記錄在相應的卡片上。 ? 通過邊界對象來初始化用例，并創(chuàng)建控制對象 。 ? 順序圖對用例中各參與對象之間的交互序列進行建模。根據(jù)館藏圖書的館藏號和借閱者信息，執(zhí)行借閱動作，創(chuàng)建和保存借閱記錄。有添加借閱者、修改借閱者、刪除借閱者等操作。 ③ Book：流通圖書。一般來說，一個用例對應一個控制類。 ? 當用例中有多個參與者時，根據(jù)構想的用戶界面來標識參與者的行為 。 ? 檢查每一個用例，標識候選對象 ? 用例中的連續(xù)名詞 （如借閱事件） ； ? 系統(tǒng)需要跟蹤的現(xiàn)實世界中的實體 （如借閱記錄、館藏圖書信息） ； ? 系統(tǒng)需要跟蹤的現(xiàn)實世界中的活動 （如緊急情況操作預案） ； ? 數(shù)據(jù)源或數(shù)據(jù)潭 （如借閱者、管理員） 。 增加類的類型 除了上述版型外，還可以向模型中增加自己的構造型。 例如，假設要迅速尋找模型中所有窗體，可以創(chuàng)建 Form類型，將所有窗口指定為這個類型。 ? 在分析對象模型中有實體對象、邊界對象和控制對象等三種類型。但是，這個眼光不是 程序設計員 的眼光，是 系統(tǒng)分析師 的眼光 ?經(jīng)過下一步 需求處理 后，達到需求規(guī)范要求 ?分析的方法是一套“ 建模 ”技術 需求分析的成果： 用例驅動 的分析 為了進一步描述系統(tǒng)，我們現(xiàn)在需要建立類和對象模型 ?類和對象模型，描述了系統(tǒng)的靜態(tài)結構 ?有了系統(tǒng)的靜態(tài)結構，我們才可以在靜態(tài)結構的基礎上，建立系統(tǒng)的行為（動態(tài)）模型 ?在面向對象方法中，我們已經(jīng)介紹了如何建立類和對象的模型 ?UML的特點是一套統(tǒng)一描述方法和符號 用例驅動的分析實現(xiàn) Booch method 的 5個步驟 （ 1）使用“尋找什么”標準來標識類和對象 ——分析類 （ 2）定義一般 /特殊結構、定義整體 /部分結構 ——分析包 （ 3）標識主題（子系統(tǒng)構件的表示） ——建立子系統(tǒng) （ 4）定義屬性和實例聯(lián)系 （ 5）定義操作和消息聯(lián)系 靜態(tài)建模 動態(tài)建模 UML的三個來源和三個組成部分： OMT、 5步驟、圖形符號 從業(yè)務 /系統(tǒng)模型到分析模型 ? 分析類（邏輯結構） ?用例實現(xiàn) ：將用例的實現(xiàn)（執(zhí)行）表示為分析類（對象）之間的交互 ? 分析包（物理結構） ?以包（分塊）的方式組織分析模型的組件 ?強內聚、弱耦合 ?完整性、正確性、一致性和易讀性 類是信息和行為的包裝 對象是類的特定實例 類圖由系統(tǒng)中的類和它們之間的關系組成 例如：在 C/S結構的系統(tǒng)中，我們把系統(tǒng)的信息放在數(shù)據(jù)庫一方，行為放在應用程序一方。 ?有二種 Interaction圖 ， 按時間順序排列的是 Sequence圖 ， 按對象關系排列的是 Collaboration圖 。 取款的客戶是角色 ， 取款是用例 。 輸入數(shù)據(jù)描述 工號 1000根本不是系統(tǒng)合法的工號 。 ? 用戶在完成按測試用例的測試后 ， 在測試記錄上逐條確認 、 簽字 ， 最后 ， 在測試報告上簽字 ， 完成驗收測試 。 ?用例模型開始定義角色之間的關系 （ 關聯(lián)關系 、 包括關系 、 擴展關系 、 一般化關系等 ） 。 ? 是否考慮了每個操作者 如何使用系統(tǒng)。 用例 應按業(yè)務術語命名，而不是按技術術語命名，應讓客戶一目了然。 Buy Soda Restock Soda Collect Money Customer Supplier Collector 每一 種活 動者 具有 自己 的 use case 飲料販賣機中的 活動者 供應商 向 自動販賣機添加飲料。 Use Case 活動者 活動者 可以是 人 或 另一個系統(tǒng) ， 它與當前的系統(tǒng)交互 ，向系統(tǒng)提供 輸入 或從系統(tǒng)中獲得 輸出 。 ? 用例 描述了系統(tǒng)的行為 ， 包括行為者和系統(tǒng)之間的交互以及系統(tǒng)與系統(tǒng)之間的交互 。 一臺電視機可以處于開機、播放、待機或關機狀態(tài) 。 ?提供了系統(tǒng)的局部詳細描述； ?和別的視圖保持語義一致； ? 在 UML中 ,有九種標準圖表 ?靜態(tài)視圖 : 用例圖 , 類圖 ,對象圖 ,組件圖 , 分布圖 ?動態(tài)視圖 : 時序圖 ,協(xié)作圖 ,狀態(tài)圖 ,活動圖 用例圖 ? 捕獲用戶能夠看到的系統(tǒng) ?通過對”場景”的描述，定義系統(tǒng)的功能和性能，并獲得用戶和開發(fā)團隊的共同認可 ?提供清楚和無二義的用戶與系統(tǒng)的交互描述 用例圖 ? 在開發(fā)過程的早期創(chuàng)建 ? 目的： ?詳細說明系統(tǒng)的表達含義； ?捕獲系統(tǒng)的需求； ?驗證系統(tǒng)的體系結構； ?驅動實現(xiàn)和生成測試用例。95 OOSE 其他方法 UML Web June 180。 時序圖 ? 捕獲系統(tǒng)的動態(tài)行為 (面向時間的 ) 時序圖 ? 捕獲系統(tǒng)的動態(tài)行為 (面向時間的 ) ? 目的 ?模型流程的控制 ?舉例說明典型的腳本 [打印機就緒 ] 打印文件 時序圖 （ Sequence Diagram） [打印機忙 ] 保存文件 打印文件 打印文件 計算機 打印服務器 打印隊列 計算機 UML順序圖示例（某客戶 Joe取 20美元的順序圖） 協(xié)作圖 ? 捕獲系統(tǒng)的動態(tài)行為 (面向消息的 ) 協(xié)作圖 ? 捕獲系統(tǒng)的動態(tài)行為 (面向消息的 ) ? 目的 ?模型流程控制 ?舉例說明對象結構和控制的協(xié)調 協(xié)作圖（ Collaboration Diagram） [打印機忙 ] 保存文件 [打印機就緒 ] 打印文件 打印文件 計算機 打印隊列 打印服務器 打印機 UML協(xié)作圖示例（ ATM系統(tǒng)中“客戶插入卡”的協(xié)作圖） 狀態(tài)圖 ? 捕獲系統(tǒng)動態(tài)行為 (面向事件的 ) 狀態(tài)圖 ? 捕獲系統(tǒng)動態(tài)行為 (面向事件的 ) ? 目的 ?對象生命周期模型 ?為起反作用的對象 (用戶接口、設備等）建模 狀態(tài)圖 State Diagram 狀態(tài)圖描述了： 給定類的狀態(tài)轉換空間 導致狀態(tài)轉換的事件 導致狀態(tài)改變的動作 為類的重要動態(tài)行為建立狀態(tài)轉換圖 超時 到達 上樓 上樓 到達 上樓 到達 在底樓 向上移動 向底樓移動 向下移動 空閑 狀態(tài)圖 State Diagram 待 機開 機播 放UML狀態(tài)圖示例 電視機 世界上的萬事萬物在任何特定時刻總處于某一特定狀態(tài)。結束過程的活動連接到一個終止點（就像在狀態(tài)圖中一樣）。 我們設計一個飲料販賣機，從用戶的角度來考察它的功能： 問 :“ 自動飲料販賣機將為您做什么 ?” 答 :“ 我 通過自動飲料販賣機購買一聽飲料 .” 飲料販賣機的主要功能是使得用戶可以購買飲料， 我們?yōu)檫@種機器標記一個叫 “買飲料”的 use case. UML中的 Use Case 表示 Buy Soda Use Case Actor Communication Customer ? use case記錄用戶使用系統(tǒng)是從頭到尾的一系列事件 。 ? 可能隱蔽的角色：時間。用例的集合應讓客戶易于了解高層的整個系統(tǒng)。 ? 在 用例 中描述了所有的功能需求。 ? 每個外部系統(tǒng)從系統(tǒng) 接收什么信息 和系統(tǒng) 發(fā)送什么信息 ? 用例視圖 一個 use case 視圖包括 一個 use case 集合，定義整個系統(tǒng)的功能 。 ? 驗收測試與確認測試非常相似 ， 所不同的是 ， 確認測試是項目組或組織內部的測試 ， 驗收測試是用戶主導 、 現(xiàn)場參與 、 現(xiàn)場環(huán)境下的測試 。 2. 輸入系統(tǒng)中不存在的工號 1000， 再輸入密碼 12345， 檢查能否進入系統(tǒng) 。 ?另一方面，設計約束和限制，也是系統(tǒng)需求必須要考慮的內容 通常這三部分需求構成軟件需求的總集。如果做了業(yè)務建模，則可以先從業(yè)務對象模型中的業(yè)務工人（ Business Worker）著手。 在這里 ， 我們最主要先關注 （ 1） （ 2） 二條 ?第一條：需求分析階段的 《 需求規(guī)格說明 》 必須與需求獲取階段經(jīng)用戶簽字確認的 《 用戶需求描述 》 一致 ?第二條： 《 需求規(guī)格說明 》 還應具有一些特定的屬性 良好的需求規(guī)格說明屬性 具有良好的需求規(guī)格說明屬性的需求文檔 ， 具有如下的屬性： （ 1） 不含糊性 ：如果每一個需求只有唯一的一種解釋 ， 那它是不含糊的； （ 2） 完整性： 如果需求包括了功能 、 性能 、 時間響應要求 、 限制、 接口等屬性 ， 不存在沒有界定的 、 以為是隱含或默認而實際存在認知差異的需求 ， 是完整的； （ 3） 可檢驗性： 存在有限的 、 經(jīng)濟與技術都是可行的檢驗方法和程序 ， 對需求的實現(xiàn)與否 ， 進行檢驗 ， 使得用戶和組織通過該檢驗 ，確認需求被按照需求規(guī)格說明實現(xiàn)； （ 4） 一致性： 需求作為一種要求是一致的 ， 不存在系統(tǒng)內相互沖突的需求要求； （ 5） 可跟蹤性： 需求可追蹤； （ 6） 可使用性： 可為產(chǎn)品的各階段 ， 特別是維護階段 ， 提供充分有用的信息 。 ? 需要注意，這些模型代表的是來自客戶的概念，而非實際軟件類或實際構件。 要尋找和定義邊界類，可以檢查 Use Case框圖。還有處理共用功能的管理者，如資源競爭、分布式處理和錯誤處理等。 1) 標識實體對象 ? 自然語言分析法 利用 Abbott啟發(fā)式準則，將語言成分映射為模型成分。 ? 標識邊界對象的啟發(fā)式準則如下： ? 標識用戶所需初始用例的用戶界面控制 。 ? 控制對象沒有在現(xiàn)實世界中具體的對應物，它通常從邊界對象處收集信息，并把這些信息分配給實體對象。因為名字可能重復，可用借閱證號碼識別。 圖書管理系統(tǒng)中的邊界對象 ① mainWindow：主窗口。 ⑤ FindTDialog：彈出對話框。 ⑩ LoginDialog：輸入用戶名和密碼的窗口。 ? 畫順序圖的啟發(fā)式準則如下： ? 順序圖第一欄對應激活該用例的參與者 。 標識實體對象 標識邊界對象 標識控制對象 使用順序圖將用例映射為對象 使用 CRC卡片對對象之間的交互建模 標識關系（結構） 標識屬性 對每一對象的與狀態(tài)有關的行為建模 分析模型評審 5) 使用 CRC卡片對對象之間的交互建模 ? CRC是類、職責和協(xié)作的縮寫。 ? 在這個過程中可以驗證已有的定義，不斷發(fā)現(xiàn)新的類、職責以及伙伴。標識關聯(lián)的啟發(fā)式準則如下： ? 檢查指示狀態(tài)的動詞或動詞短語； ? 準確地命名關聯(lián)和角色； ? 盡量使用常用的修飾詞標識出名字空間和關鍵屬性； ? 消除可導出其他關聯(lián)的關聯(lián)； ? 在關聯(lián)集合穩(wěn)定之前不必關心重復性； ? 過多的關聯(lián)使得一個模型不可讀； 定義結構層次：對象 關系模型 在已經(jīng)定義的類之間，進一步標明每個責任者和協(xié)作者之間的“連接”關系，即描述類 amp。 ? 在模擬一個場景的過程中，每當一個類開始“執(zhí)行”時，它的卡片就被拿出來討論，當“控制”傳送到另一個類時，注意力就從前一張卡片轉移到另一張上去了。 ? 試題對象不能訪問邊界對象和控制對象 。 ? 通過順序圖，將責任以操作集合的形式分配給每一個對象。根據(jù)館藏圖書的館藏號和借閱者信息，執(zhí)行預約、取消預約動作。 ④ TitleDialog：館藏圖書對話框。同一個人關于不同圖書的借閱記錄是不同的。 ? ? 在 圖書館 系統(tǒng)的例子中，我們發(fā)現(xiàn)以下控制類： ? BorrowBook：借閱流通圖書 ? ReturnBook：返還流通圖書 ? RecerveTitle：預約某種館藏圖書 ? CancelReservation：取消預約 ? MaintainBorrowerInfo：維護借閱者信息，包括創(chuàng)建、修改、取消借閱者賬戶 ? MaintainTitleInfo：維護館藏圖書信息，包括添加、修改、刪除館藏圖書信息 ? MaintainBookInfo：維護流通圖書信息，包括添加、修改、刪除流通圖書信息 圖書管理系統(tǒng)中的實體對象 ① Borrower：借閱者。 ? 分析建?；顒影ㄒ韵虏襟E。邊界對象收集來自參與者的信息，將它們轉換為可用于實體對象和控制對象的表示形式。 entity Day entity Month entity Year control ChangeDateControl boundary ButtonBoundary boundary LCDDisplayBoundary ? 分析建?；顒影ㄒ韵虏襟E。每個使用案例通常都有一個控