【正文】 。 由于 客戶的需要總是不斷（連續(xù)）增長的， 但一般的軟件開發(fā)又總是落后于客戶需求的增長，如何管理需求的進(jìn)化 (變化 )就成為軟件 管理 的 首要問題。對于傳統(tǒng)的變化管理過程來說，其基本成分包括軟件配置、軟件基線和變化審查小組。當(dāng)前的發(fā)展是軟件家族法，即產(chǎn)品線方法。多視點方法也是管理需求變化的一種新方法，它可以用于管理不一致性，并進(jìn)行關(guān)于變化的推理 。 進(jìn)化需求是十分必要的。 2．簡述 抽取需求 的主要方法，并比較它們的特點。 ⑴ 面談法。 這 是一種重要而直接簡單 ， 隨時 可 使用的發(fā)現(xiàn)和獲取需求的方法 。 面談的對象主要有用戶和領(lǐng)域?qū)＜遥号c用戶面談主要了解和提取需求， 與領(lǐng)域?qū)＜颐嬲?，是一個對領(lǐng)域知識的學(xué)習(xí)和轉(zhuǎn)換過程。使用該方法時應(yīng)注意面談前要充分準(zhǔn)備 ,面談后認(rèn)真分析 總結(jié)，同時注意掌握面談的人際交流 技巧 ，才能取得好的效果。 ⑵ 問卷法 調(diào)查法 。 通過采用向用戶發(fā)問卷調(diào)查表的方式，達(dá)到徹底弄清項目需求的一種需求獲取方法。 這是一種 從多個用戶處 收集需求信息的有效方式，是對面談法的補充。 ⑶ 會議討論法 。 所謂會議討論法，是指開發(fā)方和用戶方召開若干次需求討論會議，達(dá)到徹底弄清項目需求的一種需求獲取方法。 這種方法適合于開發(fā)方不清楚項目需求 的情況。 ⑷ 原型法。對于某些試驗性、探索性的項目，更是難于得到一個準(zhǔn)確、無二義性的需求。而原型化方法 （ Prototyping Method） 是獲取這一類項 目需求的有效方法。 ⑸面向用例的方法。 分析建立“用例”的過程，也就是提取需求的過程。 在實際應(yīng)用中，常常將以上方法進(jìn)行綜合應(yīng)用。 3. 客戶的需要總是不斷地增長，但是一般的軟件開發(fā)又總是落后于客戶需求的增長，如何管理需求的進(jìn)化就成為軟件進(jìn)化的首要問題。 請說明需求變更的管理過程。 答： 需求 變更的管理是 需求管理 的核心內(nèi)容。 其 主要任務(wù)是對系統(tǒng)需求變更進(jìn)行跟蹤和控制。對傳統(tǒng)的變化管理過程來說，其基本內(nèi)容包括軟件配置、軟件基線和變 更審查等。目前推出的新的管理方法有軟件家族法，即軟件產(chǎn)品線方法 及多視點方法等 。 下圖描述了 需求變更的管理過程。 4. M 公司的軟件產(chǎn)品以 實驗型的新軟件為主。用瀑布模型進(jìn)行軟件開發(fā)已經(jīng)有近十年了，并取得了一些成功。若你作為一名管理 人 員剛加入 M 公司，你認(rèn)為快速原型法對公司的軟件開發(fā)更加優(yōu)越，請向公司副總裁寫一份報告闡明你的理由 。 切記：副總裁不喜歡報告長度超過一頁。 參考答案提示： 應(yīng)先簡述瀑布模型的缺點，它已不適宜開發(fā)實驗型的軟件。根據(jù)快速原型法的特點，說明它特別適合于開發(fā)探索型、實驗型的軟件。 5. 如何畫分層數(shù)據(jù)流圖？ 有哪些基本原則？ 答 ：總的原則是：至頂而下，逐層分解 (畫分層數(shù)據(jù)流圖 )。逐層分解的畫法可以控制每一層的復(fù)雜度。 頂層：將整個系統(tǒng)作為一個加工，描述系統(tǒng)邊界 (輸入與輸出 )。 中間層： 將 某個加工分解為一組子加工，其中的子加工還需進(jìn)一步分解。 底層：由不再進(jìn)行分解的基本加工組成。 識別出 的問題 問題分析和 變更描述 變更分析和 成本計算 變更實現(xiàn) 修正后 的需求 《軟件工程 —— 理論與實踐》 (第 2 版 )習(xí)題答案 6 畫 分層數(shù)據(jù)流 圖的基本原則有：① 數(shù)據(jù)守恒與數(shù)據(jù)封閉原則。 ② 加工分解的原則。 ③ 子圖與父圖 “平衡 ”的原則。 ④ 合理使用文件的原則。 6. 加工小說明有哪些描述方法？ 它們各有何優(yōu)缺點？為什么不采用自然語言進(jìn)行描述？ 答 ：主要的 描述方法 有三種； 結(jié)構(gòu)化語言 、 判定 表 和 判定樹 。 ● 結(jié)構(gòu)化語言：介于自然語言和形式語言 (如謂詞邏輯 )之間 的 的一種半形式語言， 它是自然語言的一個受限制的子集 。是在自然語言的基礎(chǔ)上加上一些約束，一般分為兩層結(jié)構(gòu)：外層語法較具體，為控制結(jié)構(gòu)（順序、選擇、循環(huán)）；內(nèi)層較靈活，表達(dá)“做什么”。 常用 結(jié)構(gòu)化英語 或 結(jié)構(gòu)化 漢語 表示 ， 精確、簡明扼要、文體 靈活。 結(jié)構(gòu)化語言特點：簡單，易學(xué)，少二義性，但不好處理組合條件。 ● 判定表：適用于表述比較復(fù)雜的加工邏輯，如具有多項選擇條件的操作。 判定表是一種二維的表格，常用于較復(fù)雜的組合條件。通常由四部分組成，如 教材 表 22 所示。對用結(jié)構(gòu)化語言不易處理的較復(fù)雜的組合條件問題，可使用判定表。 ● 判定樹：本質(zhì)上與判定表相同，圖形表示更易于理解。 描述一般組合條件較清晰，但不易輸入計算機。 7. 考察下圖中子圖、父圖的平衡 關(guān)系 。 圖 1 圖 2 參考答案： ⑴ 顯然，圖 1 中子圖與父圖不平衡。 ⑵ 圖 2 中， 如果有如下數(shù)據(jù)條目： 訂貨單 =客戶 +賬號 +數(shù)量 則子、父圖平衡 。 8. 畫出銀行取款過程的 用例 圖。問題描述為：儲戶用存折取款，首先填寫取款單，根據(jù) “ 銀行 卡 ” 中的信息檢驗取款單與存折，如有問題，將問題反饋給儲戶，否則，登 錄 “儲戶存款數(shù)據(jù)庫 ”，修改相應(yīng)數(shù)據(jù)，并更新 “銀行 卡 ” ，同時發(fā)出付款通知，出納向儲戶付款。 參考答案： 分析所給出的 需求，確定角色為： 儲戶 、 存款數(shù)據(jù)庫 、 存折 、 出納 。用例為：填寫 取款單 、 驗證 取款單與存折 、 銀行 卡 管理、 數(shù)據(jù)庫 管理、 付款 。 《軟件工程 —— 理論與實踐》 (第 2 版 )習(xí)題答案 7 習(xí)題三答案 一、 選擇題 1. 模塊的基本特征是 (A C)。 A) 外部特征 (輸入 /輸出、功能 ) B) 內(nèi)部特征 (輸入 /輸出、功能 ) C) 內(nèi)部特征 (局部數(shù)據(jù)、代碼 ) D) 外部 特征 (局部數(shù)據(jù)、代碼 ) 2. SD 方法的設(shè)計總則是 (C D)。 A) 程序簡潔、操作方便 B) 結(jié)構(gòu)清晰、合理 C) 模塊內(nèi)聚性強 D) 模塊之間耦合度低 3. 軟件設(shè)計的主要任務(wù)是 (A B D)。 A) 將分析階段獲得的需求說明轉(zhuǎn)換為計算機中可實現(xiàn)的系統(tǒng) ； B) 完成系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)和程序結(jié)構(gòu)設(shè)計 C) 完成模塊的編碼和測試 D) 對模塊內(nèi)部的過程進(jìn)行設(shè)計 4. 設(shè)計階段應(yīng)達(dá)到的目標(biāo)有 (A D)。 A) 提高可靠性和可維 護(hù)性 B) 提高應(yīng)用范圍 C) 結(jié)構(gòu)清晰 D) 提高可理解性和效率 5. 從工程管理的角度來看，軟件設(shè)計分 (D)兩步完成。 A) 系統(tǒng)分析 、 模塊設(shè)計 B) 詳細(xì)設(shè)計 、 總體設(shè)計 C) 模塊設(shè)計 、 詳細(xì)設(shè)計 D) 總體設(shè)計 、 詳細(xì)設(shè)計 6. 模塊獨立性準(zhǔn)則定性指標(biāo) (B D)來衡量。 A) 分解度 B) 耦合度 C) 屏蔽性 D) 內(nèi)聚性 7. 用戶界面設(shè)計的任務(wù)包括 (A B C)。 A) 確定用戶界面類型 B) 建立任務(wù)模型 C) 建立用戶模型 D) 建立功能模型 銀行取款系統(tǒng)的高層用例圖 儲戶 存折 出納 存款數(shù)據(jù)庫 付款 數(shù)據(jù)庫 管理 填寫 取款單 銀行 卡 管理 管理 驗 證 取款單與存折 extend include include include 《軟件工程 —— 理論與實踐》 (第 2 版 )習(xí)題答案 8 二、判斷題 1. 劃分模塊可以降低軟件的復(fù)雜度和工作量，所以應(yīng)該將模塊分得越小越好。 () 2. 在網(wǎng)狀結(jié)構(gòu)中任何兩個模塊都是平等的，沒有從屬關(guān)系，所以在軟件開發(fā)過程中常常被使用。 () 3. 信息隱蔽原則有利于提高模塊的內(nèi)聚性。 (√) 4. 中心變換型的 DFD 圖可看成是對輸入數(shù) 據(jù)進(jìn)行轉(zhuǎn)換而得到輸出數(shù)據(jù)的處理，因此可以使用事務(wù)分析技術(shù)得到初始的模塊結(jié)構(gòu)圖。 () 5. SD 法是一種面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計方法，強調(diào)程序結(jié)構(gòu)與問題結(jié)構(gòu)相對應(yīng)。 () 6. 當(dāng)模塊的控制范圍是其作用范圍的子集時，模塊之間的耦合度較低。 () 三、簡答題 1. 請解釋為什么需要體系結(jié)構(gòu)設(shè)計。 答： 軟件體系結(jié)構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)成系統(tǒng)的元素的描述、元素 間 的相互作用、指導(dǎo)元素集成的模式以及這些模式的約束組成。軟件體系結(jié)構(gòu)不僅指定了系統(tǒng)的組織結(jié)構(gòu)和拓?fù)浣Y(jié)構(gòu)，并且顯示了系統(tǒng)需求和構(gòu)成 系統(tǒng)的元素之間的對應(yīng)關(guān)系，提供了一些設(shè)計決策的基本原理 。良好的體系結(jié)構(gòu)是普遍適用的，它可以高效地處理各種各樣的個體需求。 2. 集中式模型和分布式模型相比各有什么優(yōu)缺點？ 答： 以集中式的 倉庫模型 為例。其 主要優(yōu)點： (1) 數(shù)據(jù)由某個子系統(tǒng)產(chǎn)生，并且被存儲到倉庫中，以便為另外一些子系統(tǒng)共享； (2) 由于中央集中控制的緣故，共享數(shù)據(jù)能得到有效的管理，各子系統(tǒng)之間不需要通過復(fù)雜的機制來傳遞共享數(shù)據(jù)； (3) 一個子系統(tǒng)不必關(guān)心 其他 的子系統(tǒng)是怎么使用它產(chǎn)生的數(shù)據(jù)； (4) 所有的子系統(tǒng)都擁有一致的基于中央數(shù)據(jù)倉庫的數(shù)據(jù)視圖。如果新子系統(tǒng)也采用相 同的規(guī)范，則將它集成于系統(tǒng)中是容易的。 但這種系統(tǒng)也有明顯的缺陷： (1) 雖然共享數(shù)據(jù)得到了有效的管理，但隨之而來的問題是各子系統(tǒng)必須有一致的數(shù)據(jù)視圖以便能共享數(shù)據(jù)，換句話說，就是各子 系統(tǒng)之間為了能共享數(shù)據(jù)必須走一條折中的路線，這不可避免地會影響 整個系統(tǒng)的性能。 (2) 一個子系統(tǒng)發(fā)生了改變，它產(chǎn)生的數(shù)據(jù)也可能發(fā)生結(jié)構(gòu)上的改變。問題隨之而來， 其他 的子系統(tǒng)如何能正確解析這些數(shù)據(jù)呢？所以為了達(dá)到共享的目的，數(shù)據(jù)翻譯系統(tǒng)會被引入到整個系統(tǒng)當(dāng)中。但這種翻譯的代價是很高的，并且有時是不可能完成的。 (3) 中央數(shù)據(jù)倉庫和各子系統(tǒng)的私有數(shù) 據(jù)庫必須有相同的關(guān)于備份、安全、訪問控制和恢復(fù)的策略，這可能會影響子系統(tǒng)的效率。 (4) 集中式的控制使數(shù)據(jù)和子系統(tǒng)的分布變得非常困難甚至成為不可能。這里分布指的是將數(shù)據(jù)或子系統(tǒng)分散到不同的機器上。 分布式結(jié)構(gòu)有這樣的一些優(yōu)勢： (1) 資源共享：系統(tǒng)中每個服務(wù)節(jié)點上的資源都可以被系統(tǒng)中的 其他 節(jié)點訪問； (2) 開放性高：系統(tǒng)可以方便地增刪不同軟硬結(jié)構(gòu)的節(jié)點； (3) 可伸縮性好：系統(tǒng)可以方便地增刪新的服務(wù)資源以滿足需要； (4) 容錯能力強：分布式系統(tǒng)中的信息冗余可以容忍一定程度的軟硬故障； (5) 透明性高：系統(tǒng)中的節(jié)點一般只需知道服務(wù)的位置而不必 清楚系統(tǒng)的結(jié)構(gòu)。 但分布式結(jié)構(gòu)也存在著一些不足： (1) 復(fù)雜性：分布式系統(tǒng)比集中式系統(tǒng)要復(fù)雜 得 多。集中式系統(tǒng)的性能主要依賴于主機的處理《軟件工程 —— 理論與實踐》 (第 2 版 )習(xí)題答案 9 器能力，而分布式系統(tǒng)的性能則還會依賴于網(wǎng)絡(luò)的帶寬，這讓情形變得更加復(fù)雜。 (2) 安全性：網(wǎng)絡(luò)環(huán)境隨時面臨著各種威脅：病毒、惡意代碼、非法訪問 等。如何保證安全性是一個讓人頭疼的問題。 (3) 可管理性：分布式系統(tǒng)的開放性造成了系統(tǒng)的異構(gòu)性。顯而易見，管理異構(gòu)的系統(tǒng)比管理主機系統(tǒng)要困難得多。 (5) 不可預(yù)知性：這主要指系統(tǒng) 的響應(yīng)時間。 網(wǎng)絡(luò)環(huán)境本身的特點決定了網(wǎng)絡(luò)負(fù)載會明顯地影響整個系統(tǒng)的響應(yīng)時間。 3. 請舉出一種集中式模型的實例，并圖示它的結(jié)構(gòu)。 答：請參考 “倉庫模型” 4. 胖客戶模型和瘦客戶模型的區(qū)別是什么？它們分別被應(yīng)用在什么樣的場合？ 答：在胖客戶模型中，客戶端應(yīng)用負(fù)責(zé)用戶界面和應(yīng)用邏輯部分，因此它的工作比較繁重。一般的數(shù)據(jù)庫應(yīng)用都是屬于這種結(jié)構(gòu)。而與此相反，在瘦客戶模型中，服務(wù)器負(fù)責(zé)了更多的工作，而客戶端的工作就變得非常單純。瀏覽器 /Web 服務(wù)器結(jié)構(gòu)就屬于瘦客戶結(jié)構(gòu)，而且常被稱為B/S（ Browser/Server） 結(jié)構(gòu)。 ，并圖示它的結(jié)構(gòu)。 答：請參考 “兩層 C/S 模型” 。 答：略。 － 服務(wù)器模型有什么異同？ 答：在 C/S 模型中，客戶和服務(wù)器的“地位”是不“平等”的：客戶只能向服務(wù)器提出服務(wù)請求，而服務(wù)器不能向客戶提出服務(wù)請求，同時服務(wù)器之間可以互相提供服務(wù)。另外，客戶一般要知道服務(wù)器在網(wǎng)絡(luò)上的具體位置（服務(wù)器的域名或者 IP 地址），相反，服務(wù)器則不需要。這種差別在一定程度上限制了系統(tǒng)的靈活性和可擴展性。而在分布式對象結(jié)構(gòu)中，服務(wù)的提供者是被稱為“對象 ” (Object)的系統(tǒng)組件 (System Component)。每個對象的地位在邏輯上是平等的，它們可以互相為對方提供所需的服務(wù)。在這種情況下，提供服務(wù)的對象就是服務(wù)器，而提出服務(wù)請求的對象就是客戶。為了能夠提供服務(wù)，每個對象都有一個服務(wù)接口。 ，寫一篇對比 CORBA和 DCOM 的報告。 答：略。 ？ 答：模塊分解的目的是將系統(tǒng)“分而治之”，以降低問題的復(fù)雜性，使軟件結(jié)構(gòu)清晰，易閱讀、易理解，易于測試和調(diào)試，因而也有助于提高軟件的可靠性。 10. 模塊分解應(yīng)該遵循什么樣的標(biāo)準(zhǔn) ? 答： 按照