【正文】 將職責(zé)分配到類 ：記錄在相應(yīng)的卡片上。 ③ 找尋協(xié)作者 ：依次檢查每一類承擔(dān)的責(zé)任，看是否需要其他類的幫助，找尋與每個(gè)類協(xié)作的伙伴，并記錄在相應(yīng)卡片上。 軟件工程 137 職責(zé) 顯示歡迎詞 密碼驗(yàn)證器 接收磁卡 菜單選擇器 讓密碼驗(yàn)證器檢驗(yàn) 啟動(dòng)菜單選擇器 退出磁卡 類名 讀卡機(jī) 協(xié)作 職責(zé) 從賬戶中取出密碼 賬戶 如無此賬戶返回假值 提示客戶輸入密碼 讀入密碼 比較核實(shí) , 返回結(jié)果 類名 密碼驗(yàn)證器 協(xié)作 職責(zé) 檢查賬戶有效性 返回密碼 檢查取款 /存款信息 類名 賬戶 職責(zé) 顯示菜單 存款管理器 等待客戶選擇 取款管理器 調(diào)用相應(yīng)的 存款 /取款管理器 類名 菜單選擇器 協(xié)作 職責(zé) 詢問取款額 賬戶 要求驗(yàn)證賬戶 出銀機(jī) 啟動(dòng)出銀機(jī)發(fā)款 類名 取款管理器 協(xié)作 軟件工程 138 ④ 細(xì)化 ：模擬在執(zhí)行每個(gè)基本功能時(shí)系統(tǒng)內(nèi)部出現(xiàn)的場(chǎng)景，以此推動(dòng)細(xì)化工作的進(jìn)行。 ? 在模擬一個(gè)場(chǎng)景的過程中，每當(dāng)一個(gè)類開始“執(zhí)行”時(shí)，它的卡片就被拿出來討論，當(dāng)“控制”傳送到另一個(gè)類時(shí)，注意力就從前一張卡片轉(zhuǎn)移到另一張上去了。不同的場(chǎng)景，包括例外和出錯(cuò)狀況，都應(yīng)逐一加以模擬。 ? 在這個(gè)過程中可以驗(yàn)證已有的定義，不斷發(fā)現(xiàn)新的類、職責(zé)以及伙伴。 ? 在模擬不同的場(chǎng)景中會(huì)發(fā)現(xiàn)某些職責(zé)需要重新加以分配。這些都導(dǎo)致進(jìn)一步的開發(fā)工作。 軟件工程 139 6) 識(shí)別關(guān)系（結(jié)構(gòu)） ? 使用類圖，能夠表示對(duì)象之間的關(guān)系。 ? 關(guān)聯(lián)表示了兩個(gè)或多個(gè)類之間的關(guān)系。標(biāo)識(shí)關(guān)聯(lián)的啟發(fā)式準(zhǔn)則如下： ? 檢查指示狀態(tài)的動(dòng)詞或動(dòng)詞短語；識(shí)別動(dòng)作的主體和客體。 ? 準(zhǔn)確地命名關(guān)聯(lián)和角色； ? 應(yīng)消除可導(dǎo)出其他關(guān)聯(lián)的關(guān)聯(lián)； ? 在一組關(guān)聯(lián)穩(wěn)定之前不必關(guān)心重復(fù)性； ? 過多的關(guān)聯(lián)使得一個(gè)模型不可讀； 軟件工程 140 a) 建立系統(tǒng)的包圖（主題） ? 建立包圖是為了降低復(fù)雜性 ? 提供整體框架。每一個(gè)包就是一個(gè)主題。 ? 通過對(duì)主題的識(shí)別，可以讓人們能夠比較清晰地了解大而復(fù)雜的模型 。 Library GUI DataBase 軟件工程 141 b) 建立邊界類的類圖 ? 標(biāo)明類之間的關(guān)系，包括關(guān)聯(lián)、泛化等。 messageWindow loginDialog returnDialog borrowerDialog reserveDialog mainWindow findTDialog borrowDialog findBwrDialog TitleDialog 軟件工程 142 c) 建立實(shí)體類的類圖 ? 這些類與數(shù)據(jù)庫相關(guān)，為了操作方便，以它們?yōu)樽宇?，建立一個(gè)持久類（ Persistent）作為它們的父類，共享與數(shù)據(jù)庫相關(guān)的操作。 Book Borrower Reservation Title Loan Persistent (from DataBase) 1 1 0..1 * 0.. * 0.. * 0.. * 0.. * 1 1 軟件工程 143 d) 建立邊界類與實(shí)體類之間關(guān)系的類圖 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) 軟件工程 144 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.. * 軟件工程 145 7) 標(biāo)識(shí)屬性 ? 對(duì)象所保存的信息稱為它的屬性。類的屬性所描述的是狀態(tài)信息，每個(gè)實(shí)例的屬性值表達(dá)了該實(shí)例的狀態(tài)值。 ? 標(biāo)識(shí)屬性的啟發(fā)性準(zhǔn)則如下： ? 每個(gè)對(duì)象至少需包含一個(gè)屬性；例如： id ? 屬性取值必需適合對(duì)象類的所有實(shí)例； ? 系統(tǒng)的所有存儲(chǔ)數(shù)據(jù)必須定義為屬性； ? 對(duì)象的導(dǎo)出屬性應(yīng)當(dāng)略去。例如，“年齡”是由屬性“出生年月”導(dǎo)出，它不能作為基本屬性存在。 軟件工程 146 8) 表示類的服務(wù) ? 對(duì)每個(gè)類的增加、修改、刪除、選擇等服務(wù) 有時(shí)是隱含的 ，在圖中不標(biāo)出，但實(shí)現(xiàn)類和對(duì)象時(shí)有定義。 ? 其它服務(wù)則必須顯式地在圖中畫出。 ① 首先標(biāo)識(shí)在每個(gè)類中封裝的服務(wù) 。 ② 畫出對(duì)象之間的消息通信路徑。方法： ① 找出每一對(duì)象在其生存周期中的所有狀態(tài)。每一狀態(tài)的改變都關(guān)聯(lián)到對(duì)象之間消息的傳遞。 ② 使用順序圖，標(biāo)識(shí)和描述對(duì)象之間的相互通信 軟件工程 147 Scenario 敘述 劉備 孔明 關(guān) 羽 求戰(zhàn) 請(qǐng)擬 策略 張飛 請(qǐng)防守 荊州 請(qǐng) 防守 荊州 前線 孫權(quán) 曹操 請(qǐng)聯(lián)絡(luò)孫權(quán) 請(qǐng)孫權(quán)領(lǐng)兵相助 借 東風(fēng) 火攻 火攻 曹軍 軟件工程 148 ? 這是一種有效駕馭風(fēng)險(xiǎn)的技術(shù)。通過原型 ? 可以增進(jìn)軟件開發(fā)者和用戶對(duì)系統(tǒng)服務(wù)需求的理解，使比較含糊的具有不確定性的軟件需求（主要是功能）明確化 。 ? 可以容易地確定 系統(tǒng)的性能 ，確認(rèn) 各項(xiàng)主要系統(tǒng)服務(wù)的可應(yīng)用性 ，確認(rèn)系統(tǒng)設(shè)計(jì)的可行性，確認(rèn)系統(tǒng)作為產(chǎn)品的結(jié)果。 ? 有的原型可以直接成為產(chǎn)品，有的略加修改就可成為最終系統(tǒng)的一個(gè)組成部分。 快速原型化方法 軟件工程 149 1) 探索型 ： 目的是要弄清對(duì)目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。適用于對(duì)項(xiàng)目缺乏經(jīng)驗(yàn)的情況。 2) 實(shí)驗(yàn)型 ： 這種原型用于大規(guī)模開發(fā)和實(shí)現(xiàn)之前，考核方案是否合適，規(guī)格說明是否可靠。 3) 進(jìn)化型 ： 這種原型的目的不在于改進(jìn)規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進(jìn)原型的過程中，逐步將原型進(jìn)化成最終系統(tǒng)。 原型分類 軟件工程 150 原型使用策略 ? 軟件原型支持需求工程的兩項(xiàng)活動(dòng)： ? 需求獲取 ? 需求有效性驗(yàn)證 ? 其他用途： ? 用戶培訓(xùn) ? 系統(tǒng)測(cè)試 ? 原型開發(fā)主要分類： ? 進(jìn)化式原型開發(fā) ? 拋棄式原型開發(fā) 軟件工程 151 1）進(jìn)化式原型開發(fā) ? 基本思路是：先給出一個(gè)系統(tǒng)的最初實(shí)現(xiàn)，讓用戶去使用和評(píng)價(jià)，不斷進(jìn)行細(xì)化和改善，經(jīng)過多次這樣的反復(fù)過程后形成最終的完善的系統(tǒng)。 開發(fā)抽象描述 建立原型系統(tǒng) 使用原型系統(tǒng) 系統(tǒng)充分嗎 ? 交付系統(tǒng) 否 是 軟件工程 152 2）拋棄式原型開發(fā) ? 基本思路是：原型的根本作用是弄清楚需求和為風(fēng)險(xiǎn)評(píng)估提供補(bǔ)充信息。通過評(píng)估后，原型被拋棄，重新規(guī)劃和實(shí)施系統(tǒng)的開發(fā)。 框架需求 開發(fā)原型 確定系統(tǒng) 評(píng)估原型 開發(fā)軟件 問題 可 驗(yàn)證系統(tǒng) 問題 可 交付的軟件系統(tǒng) 可復(fù)用構(gòu)件 軟件工程 153 (1) 功能與實(shí)現(xiàn)分離，描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。 (2) 如果目標(biāo)軟 件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也要描述。 (3) 規(guī)格說明必須包括系統(tǒng)運(yùn)行的環(huán)境。 (4) 系統(tǒng)規(guī)格說明必須是一個(gè)認(rèn)識(shí)的模型（讓用戶理解），而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。 (5) 規(guī)格說明必須是可操作的。 (6) 規(guī)格說明必須容許不完備性并允許擴(kuò)充。 (7) 規(guī)格說明必須局部化和松耦合。 需求規(guī)格說明的原則 軟件工程 154 1. 完整性： 不能遺漏任何必要的需求信息。如果知道缺少某項(xiàng)信息，用“待定”作為標(biāo)準(zhǔn)標(biāo)識(shí)來標(biāo)明這項(xiàng)缺漏。在開始設(shè)計(jì)和實(shí)現(xiàn)之前，必須解決需求中所有的“待定”項(xiàng)。 2. 無歧義性 需求規(guī)格說明的質(zhì)量要求 軟件工程 155 必須保證該需求規(guī)格說明對(duì)其每一個(gè)需求只有一種解釋。為此，要求最終產(chǎn)品的每一個(gè)特性都需使用某一確定的術(shù)語描述。 3. 一致性 必須保證在需求規(guī)格說明書中描述的每一個(gè)軟件需求的定義不能與其他軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求相矛盾。在設(shè)計(jì)和實(shí)現(xiàn)之前必須解決所有需求間的不一致部分。 4. 可驗(yàn)證性 對(duì)于每一個(gè)需求，需指定所使用的驗(yàn)證方法，以確保需求得到滿足。 軟件工程 156 5. 可修改性 ? 在內(nèi)容組織上，需求規(guī)格說明應(yīng)有目錄表、索引和相互參照表，各個(gè)章節(jié)盡可能獨(dú)立，以減少修改的波及面，使得修改局部化。 ? 盡可能減少冗余，每項(xiàng)需求只應(yīng)在軟件需求規(guī)格說明中出現(xiàn)一次。 6. 可追蹤性 1) 向后追蹤 ：即向產(chǎn)生軟件需求規(guī)格說明的前一階段追蹤 2) 向前追蹤 ：即向由軟件需求規(guī)格說明所派生的所有后續(xù)文檔追蹤 軟件工程 157 需求管理 ? 需求管理的目的是在客戶與開發(fā)方之間建立對(duì)需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更。需求管理強(qiáng)調(diào)： ? 控制對(duì)需求基線的變動(dòng)。 ? 保持項(xiàng)目計(jì)劃與需求一致。 ? 控制單個(gè)需求和需求文檔的版本情況。 ? 管理需求和跟蹤鏈之間的聯(lián)系或管理單個(gè)需求和其他項(xiàng)目可交付物之間的依賴關(guān)系。 ? 跟蹤基線中需求的狀態(tài)。 軟件工程 158 需求管理的主要活動(dòng) 需求管理 需求跟蹤 ? 定義對(duì)其 他需求的 跟蹤鏈 ? 定義對(duì)其 他系統(tǒng)需 求的跟蹤 鏈 版本控制 ? 確定需求 文檔版本 ? 確定單個(gè) 需求文檔 版本 需求狀態(tài)跟蹤 ? 定義需求狀 態(tài) ? 跟蹤需求的 每一狀態(tài) 變更控制 ? 建議變更 ? 分析影響 ? 做出決策 ? 交流 ? 合并 ? 測(cè)量需求 的穩(wěn)定性 軟件工程 159 需求的變更控制 ? 對(duì)于很多軟件項(xiàng)目來說，需求變更是合理的，而且是不可避免的。 ? 如果對(duì)需求的變更不加控制，持續(xù)不斷地返工，持續(xù)不斷地調(diào)整資源、進(jìn)度或質(zhì)量目標(biāo)，會(huì)導(dǎo)致開發(fā)過程混亂，開發(fā)成本上升和開發(fā)進(jìn)度延誤，同時(shí)導(dǎo)致產(chǎn)品質(zhì)量的下降。所以，必須嚴(yán)格控制需求的變更。 1. 變更控制的策略 軟件工程 160 (1) 所有需求的變更必須遵循一個(gè)變更控制的過程，如果一個(gè)變更請(qǐng)求未被批準(zhǔn)，則其后續(xù)過程不再予以考慮。 (2) 對(duì)于未獲批準(zhǔn)的變更，除可行性論證之外，不應(yīng)再做其他設(shè)計(jì)和實(shí)現(xiàn)工作。 (3) 提交一個(gè)變更請(qǐng)求不能保證該變更一定能實(shí)現(xiàn)，要由項(xiàng)目變更控制委員會(huì)決定實(shí)現(xiàn)哪些變更。 (4) 項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者應(yīng)該能夠了解變更數(shù)據(jù)庫的內(nèi)容。 軟件工程 161 (5) 絕不能從數(shù)據(jù)庫中刪除或修改變更請(qǐng)求的原始文檔。 (6) 每一個(gè)集成的需求變更必須必須能跟蹤到一個(gè)經(jīng)核準(zhǔn)的變更請(qǐng)求。 2. 變更控制委員會(huì)（ CCB） ? 變更控制委員會(huì)的主要工作是： (1) 制定決策 。對(duì)每個(gè)變更權(quán)衡利弊后做出決定。 (2) 交流情況 。一旦變更控制委員會(huì)做出決策，應(yīng)及時(shí)更新變更數(shù)據(jù)庫中請(qǐng)求的狀態(tài)，通知所有相關(guān)人員，保證他們能充分處理變更。 軟件工程 162 (3) 重新協(xié)商約定 。當(dāng)軟件開發(fā)組接受了重要的需求變更時(shí)，要與管理部門和客戶重新協(xié)商約定。協(xié)商內(nèi)容包括推遲“交貨”時(shí)間、要求增加人手、推遲實(shí)現(xiàn)尚未實(shí)現(xiàn)的較低優(yōu)先級(jí)的需求，或者質(zhì)量上進(jìn)行折衷。 軟件工程 163 ? 版本控制是為了管理軟件需求規(guī)格說明文檔。它主要的活動(dòng)是統(tǒng)一標(biāo)識(shí)需求規(guī)格說明文檔的每一個(gè)版本，并讓每一個(gè)