【正文】 例（場景）行為在其參與對象之間是如何實施的。 ? 順序圖 對用例中各參與對象之間的交互序列進行建模 。每一個消息從一個對象（或參與者）發(fā)送給另一個對象（或參與者）。消息的接受就觸發(fā)了一個操作。 ? 通過順序圖，將責任以操作集合的形式分配給每一個對象。如果一個對象參與到多個用例，則其操作應為這些用例共享。 117 軟件工程 ? 畫順序圖的啟發(fā)式準則如下： ? 順序圖第一欄對應激活該用例的參與者 。 ? 順序圖第二欄是邊界對象 。 ? 順序圖第三欄是管理用例中其他參與對象的控制對象 。 ? 通過邊界對象來初始化用例，并創(chuàng)建控制對象 。 ? 通過控制對象可創(chuàng)建其他邊界對象 。 ? 實體對象允許邊界對象和控制對象訪問 。 ? 實體對象不能訪問邊界對象和控制對象 。 118 軟件工程 借書用例的順序圖 :mainWindow :BorrowDialog :Title :Book :Borrower :Loan :Librarian 1:borrow() 2:createDialog() 3:borrow() 4:findTitle(string) 5:getTitle() 6:getAvaliableBook() 7:findBorrower(string) 8:newLoan(OID, OID, Date) 9:store() 10:getBorrower(OID) 11:update() 12:addLoan(OID) 13:getObject(OID) 14:setLoan(OID) 15:update() 119 軟件工程 還書用例的順序圖 :mainWindow :ReturnDialog :Book :Borrower :Loan :Librarian 1:return() 2:createDialog() 3:return() 4:findBook(Integer) 5:getObject(OID) 6:getLoan() 7:getBorrower() 8:setLoan(null) 9:update() 10:delLoan(OID) 11:update() 12:delete() 120 軟件工程 5) 使用 CRC卡片對對象之間的交互建模 ? CRC是類、職責和協作的縮寫。每一個類可用一張 CRC卡片表示。 ? 建立 CRC卡片有以下幾個 步驟： ① 識別類和職責 ： 首先識別類或對象，然后從客戶需求說明中尋找有關行為的描述，以發(fā)現職責。 ② 將職責分配到類 ：記錄在相應的卡片上。 ③ 找尋協作者 ：依次檢查每一類承擔的責任，看是否需要其他類的幫助，找尋與每個類協作的伙伴，并記錄在相應卡片上。 121 軟件工程 職責 顯示歡迎詞 密碼驗證器 接收磁卡 菜單選擇器 讓密碼驗證器檢驗 啟動菜單選擇器 退出磁卡 類名 讀卡機 協作 職責 從賬戶中取出密碼 賬戶 如無此賬戶返回假值 提示客戶輸入密碼 讀入密碼 比較核實 , 返回結果 類名 密碼驗證器 協作 職責 檢查賬戶有效性 返回密碼 檢查取款 /存款信息 類名 賬戶 職責 顯示菜單 存款管理器 等待客戶選擇 取款管理器 調用相應的 存款 /取款管理器 類名 菜單選擇器 協作 職責 詢問取款額 賬戶 要求驗證賬戶 出銀機 啟動出銀機發(fā)款 類名 取款管理器 協作 122 軟件工程 ④ 細化 ：模擬在執(zhí)行每個基本功能時系統(tǒng)內部出現的場景，以此推動細化工作的進行。 ? 在模擬一個場景的過程中，每當一個類開始“執(zhí)行”時，它的卡片就被拿出來討論，當“控制”傳送到另一個類時，注意力就從前一張卡片轉移到另一張上去了。不同的場景，包括例外和出錯狀況，都應逐一加以模擬。 ? 在這個過程中可以驗證已有的定義，不斷發(fā)現新的類、職責以及伙伴。 ? 在模擬不同的場景中會發(fā)現某些職責需要重新加以分配。這些都導致進一步的開發(fā)工作。 123 軟件工程 6) 標識關系（結構） ? 使用類圖，能夠表示對象之間的關系。 ? 關聯表示了兩個或多個類之間的關系。標識關聯的啟發(fā)式準則如下： ? 檢查指示狀態(tài)的動詞或動詞短語； ? 準確地命名關聯和角色； ? 盡量使用常用的修飾詞標識出名字空間和關鍵屬性； ? 消除可導出其他關聯的關聯； ? 在關聯集合穩(wěn)定之前不必關心重復性； ? 過多的關聯使得一個模型不可讀； 124 軟件工程 a) 建立系統(tǒng)的包圖（主題） ? 建立包圖是為了降低復雜性，目的是 控制可見度 及 指引讀者的思路 。 ? 對于面向對象分析模型，主題表示此模型的整體框架?？梢允且粋€層次結構。 ? 通過對主題的識別，可以讓人們能夠比較清晰地了解大而復雜的模型 。 Library GUI DataBase 125 軟件工程 b) 建立邊界類的類圖 ? 標明類之間的關系，包括關聯、泛化等。 messageWindow loginDialog returnDialog borrowerDialog reserveDialog mainWindow findTDialog borrowDialog findBwrDialog TitleDialog 126 軟件工程 c) 建立實體類的類圖 ? 這些類與數據庫相關，為了操作方便，以它們?yōu)樽宇?，建立一個持久類（ Persistent）作為它們的父類，共享與數據庫相關的操作。 Book Borrower Reservation Title Loan Persistent (from DataBase) 1 1 0..1 * 0.. * 0.. * 0.. * 0.. * 1 1 127 軟件工程 d) 建立邊界類與實體類之間關系的類圖 Book (from Library) 1 1 0..1 * 0.. * 1 Title (from Library) Loan (from Library) Borrower (from Library) Reservation (from Library) BorrowDialog (from GUI) ReturnDialog (from GUI) 128 軟件工程 Book (from Library) 1 1 0..1 * 0.. * 1 Title (from Library) Loan (from Library) Borrower (from Library) Reservation (from Library) TitleDialog (from GUI) findTDialog (from GUI) 0.. * 0.. * 1 0.. * 129 軟件工程 7) 標識屬性 ? 對象所保存的信息稱為它的屬性。類的屬性所描述的是狀態(tài)信息，每個實例的屬性值表達了該實例的狀態(tài)值。 ? 標識屬性的啟發(fā)性準則如下： ? 每個對象至少需包含一個屬性； ? 屬性取值必需適合對象類的所有實例； ? 出現在泛化關系中的對象所繼承的屬性必須與泛化關系一致； ? 系統(tǒng)的所有存儲數據必須定義為屬性； 130 軟件工程 ? 對象的導出屬性應當略去。例如，“年齡”是由屬性“出生年月”導出，它不能作為基本屬性存在。 8) 對每一對象的與狀態(tài)有關的行為建模 ? 對象收到消息后所能執(zhí)行的操作稱為它可提供的服務。 ? 對每個類的增加、修改、刪除、選擇等服務 有時是隱含的 ，在圖中不標出，但實現類和對象時有定義。 ? 其它服務則必須顯式地在圖中畫出。 ① 首先標識在每個類中封裝的服務 。 131 軟件工程 ② 再比較服務與類的屬性，驗證其一致性。所標識的類屬性，它必然關聯到某個服務，否則該屬性就形同虛設，永遠不可能被訪問 。 ③ 畫出對象之間的消息通信路徑，協調系統(tǒng)的行為。 ? 自底向上方法 ：找出每一對象在其生存周期中的所有狀態(tài)。每一狀態(tài)的改變都關聯到對象之間消息的傳遞。從對象著手，逐漸向上分析。 ? 自頂向下方法 ：一個對象必須識別系統(tǒng)中發(fā)生或出現的事件，產生發(fā)送給其他對象 132 軟件工程 的消息，由那些對象作出響應。所以對象應具有能夠接收、處理、產生每個消息的服務。它是從系統(tǒng)行為著手，然后逐漸分析到對象。 ④ 使用順序圖或協作圖，標識和描述對象之間的相互通信，并進行運行走查。 10) 分析模型評審 有關模型正確性的問題： ? 對實體對象的分類，用戶是否能夠理解 ? ? 抽象類是否對應到用戶層的定義 ? ? 是否所有的描述均符合用戶的定義 ? 133 軟件工程 ? 是否所有的實體對象和邊界對象都使用了有實際含義的名詞短語進行了命名 ? ? 是否所有的用例和控制對象都使用了有意義的動詞短語進行了命名 ? ? 是否所有的錯誤用例都已經描述和處理 ? 有關模型完備性的問題： ? 每一個對象是否有用例用到它？創(chuàng)建、修改或刪除該對象的用例是哪些？ ? 每一個屬性的類型是什么？它應進行修飾嗎？ ? 每一個關聯何時被用到？其重復性的選擇原則是什么？該關聯使用那一種連接？ 134 軟件工程 ? 每一個控制對象是否具有必要的關聯，以連接到用例中相關的其他對象？ 有關模型一致性的問題： ? 是否有多個類或多個用例同名？ ? 名字相近的實體（如類、對象、屬性）能夠相互區(qū)別嗎？ ? 在同一泛化層次是否存在相似屬性和關聯的對象？ 有關模型可實現性的問題： ? 在該系統(tǒng)中性能需求和可靠性需求是否滿足？ ? 在選定硬件上運行原型是否可以確定需求？ 135 軟件工程 ? 這是一種有效駕馭風險的技術。通過原型 ? 可以增進軟件者和用戶對系統(tǒng)服務需求的理解，使比較含糊的具有不確定性的 軟件需求（主要是功能）明確化 。 ? 可以容易地確定 系統(tǒng)的性能 ，確認 各項主要系統(tǒng)服務的可應用性 ，確認系統(tǒng)設計的可行性，確認系統(tǒng)作為產品的結果。 ? 有的原型可以直接成為產品，有的略加修改就可成為最終系統(tǒng)的一個組成部分。 快速原型化方法 136 軟件工程 1) 探索型 ： 目的是要弄清對目標系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。 2) 實驗型 ： 這種原型用于大規(guī)模開發(fā)和實現之前，考核方案是否合適，規(guī)格說明是否可靠。 3) 進化型 ： 這種原型的目的不在于改進規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進原型的過程中，逐步將原型進化成最終系統(tǒng)。 原型分類 137 軟件工程 原型使用策略 ? 軟件原型支持需求工程的兩項活動： ? 需求獲取 ? 需求有效性驗證 ? 其他用途： ? 用戶培訓 ? 系統(tǒng)測試 ? 原型開發(fā)主要分類： ? 進化式原型開發(fā) ? 拋棄式原型開發(fā) 138 軟件工程 1）進化式原型開發(fā) ? 基本思路是：先給出一個系統(tǒng)的最初實現，讓用戶去使用和評價，不斷進行細化和改善，經過多次這樣的反復過程后形成最終的完善的系統(tǒng)。 開發(fā)抽象描述 建立原型系統(tǒng) 使用原型系統(tǒng) 系統(tǒng)充分嗎 ? 交付系統(tǒng) 否 是 139 軟件工程 2）拋棄式原型開發(fā) ? 基本思路是：原型的根本作用是弄清楚需求和為風險評估提供補充信息。通過評估后，原型被拋棄，重新規(guī)劃和實施系統(tǒng)的開發(fā)。 框架需求 開發(fā)原型 確定系統(tǒng) 評估原型 開發(fā)軟件 問題 可 驗證系統(tǒng) 問題 可 交付的軟件系統(tǒng) 可復用構件 140 軟件工程 原型開發(fā)技術 ? 可執(zhí)行規(guī)格說明 ? 基于場景 (scenario) 的設計 ? 自動程序設計 ? 專用語言 ? 可復用 (reusable)的軟件 ? 簡化假設 1. 可執(zhí)行規(guī)格說明 ? 用于需求規(guī)格說明走查的一種動態(tài)技術。使用它，人們可以直接觀察他們用語言規(guī)定的任何系統(tǒng)性行為。 141 軟件工程 ? 可執(zhí)行規(guī)格說明包括 a) 代數規(guī)格說明 ? 使用集合、定義于這些集合上的函數和定義于這些函數上的方程來描述對象。規(guī)