【正文】 可以快速生成 。 答 : 每一個(gè)線性序列產(chǎn)生的 “增量 ”交付的軟件，例如字處理軟件開發(fā)使用增量范式可能會(huì)提供基本的文件管理 ， 編輯和文件制作功能在第一增量，更復(fù)雜的編輯和文件制作能力在第二增量 ； 拼寫和語法檢查在第三增量 ， 先進(jìn)的頁面布局能力在第四增量 。 增量發(fā)展是特別有用當(dāng)人員無法 在 經(jīng)營期限為一個(gè)已成立 的 項(xiàng)目 做完美的 實(shí)施 。 可以合用幾種過程模型嗎？如果可以，舉例說明。 例如線性順序模型可以作為一個(gè)有用的過程模型，在被固定的情況下，要求工作以線性的方式繼續(xù)進(jìn)行，直至完成 。 在這之中，以及許多其他場合原型模型可以提供最好的辦法 。 協(xié)同過程模型定義了一套“狀態(tài)”，用你自己的話描述一下這些狀態(tài)表示什么，并指出他們在協(xié)同過程模型中的作用。 目前的挑戰(zhàn)是管理的并發(fā)，并能夠評估該項(xiàng)目的狀態(tài) 。 當(dāng)追求開發(fā) 速度超過了產(chǎn)品的質(zhì)量，這可能會(huì)導(dǎo)致許多缺陷 ， 該軟件可能需要更多的測試 ， 設(shè)計(jì)和實(shí)施工作 。 半 調(diào)子 和速度 過快開發(fā) 都可能導(dǎo)致無法檢測到重大 的 項(xiàng)目風(fēng)險(xiǎn) 。 詳細(xì)描述三個(gè)適于采用基于構(gòu)件模型的軟件項(xiàng)目。 我們可以證明一個(gè) 軟件構(gòu)件甚至整個(gè)程序的正確性，可是為什么并不是每個(gè)人都這樣做？ 答： 這是可能的用數(shù)學(xué)技術(shù)來證明軟件組件，甚至整個(gè)程序的正確性 。 用詳盡的測試是不可能證明任何不平凡的程序的正確性， 統(tǒng)一過程和 UML 是同一概念嗎？解釋你的答案。 但它并不提供流程框架 來 指導(dǎo)項(xiàng)目團(tuán)隊(duì)，在他們的技術(shù)應(yīng)用 中。 今天，統(tǒng)一的流程 和 UML 被廣泛應(yīng)用于各種 面向?qū)ο蟮捻?xiàng)目。在某些情況下，工程師們會(huì)化繁為簡。需求分析是設(shè)計(jì)和施工的橋梁 ,不能跳過。然后把這些數(shù)據(jù)翻譯成需求表 —— 稱為客戶意見表，并由客戶和利益相關(guān)者評審。 事實(shí)上 ,客戶和開發(fā)人員會(huì)有一個(gè)協(xié)商的過程，開發(fā)人員會(huì)要求客戶權(quán)衡產(chǎn)品的性能與產(chǎn)品成本、上市時(shí)間之間的關(guān)系。不幸的是 ,這樣的項(xiàng)目計(jì)劃很難達(dá)成 ,每個(gè)客戶都有自己的觀點(diǎn)。 需求模型的目的在于描述所需的信息、功能和計(jì)算機(jī)系統(tǒng)的工作領(lǐng) 域。因此，分析模型在任何時(shí)候都是用戶需求的簡介 最好的協(xié)商是爭取“雙贏” ,這會(huì)使你成為是一位談判大師。 第一組上下文無關(guān)問題集主要 關(guān)注的是 客戶、總體目標(biāo)和利益。 用例圖描述了參與者所能 觀察到 模型圖 。 在 許多情況下， 為了 提供更多的相互作用， 用例圖 需要做更詳細(xì)的闡述。這些分析模式在特定應(yīng)用領(lǐng)域內(nèi)提供了一些解決方案（如類、功能、行為），在為許多應(yīng)用項(xiàng)目建模時(shí)可以重復(fù)使用。 當(dāng)需求確認(rèn)解釋了一個(gè)錯(cuò)誤時(shí)，每個(gè)需求有一個(gè)問題清單。確認(rèn)需求的評審小組包括軟件工程師、客戶、用戶、和其他利益相關(guān)者，他們在檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯(cuò)誤，以及可能需要進(jìn)一步解釋澄清的地方、丟失的信息、不一致性（這是建造大型產(chǎn)品或系統(tǒng)時(shí)遇到的主要問題）、沖突的需求或是不可實(shí)現(xiàn)的（不能達(dá)到的）需求。 答：分析模 型作為領(lǐng)域 對象的 設(shè)計(jì) 和結(jié)構(gòu) 的 基礎(chǔ)服務(wù)。 一個(gè)單憑經(jīng)驗(yàn)的分析原則是：模型“應(yīng)該關(guān)注在問題域或業(yè)務(wù)域中可見的需求”。 答：正如我們 所知道的， 在 開始階段 很可能沒有完整 的需求規(guī)范 。 開發(fā)者 也 沒有把握使用 一個(gè)具體的方法 來 正常的完成系統(tǒng)的功能和性能。 分析師所將 認(rèn)識(shí)到的東西進(jìn)行建模， 并使用 此 模型作為 軟件增量 的設(shè)計(jì)的 基礎(chǔ)。在 這些領(lǐng)域中， 需求 的類型 是 不可見的 ， 可能因?yàn)?一些 功能必須在系統(tǒng) 中 實(shí)現(xiàn) ， 系統(tǒng) 展示 的行為是 什么， 屬性 定義的接口有哪些，應(yīng)用的約束有哪些？ 域分析的目的是什么？如何將域分析與需求模式概念相聯(lián)系？ 答：域分析是 持續(xù)的軟件工程活動(dòng)， 不與 任何的軟件項(xiàng)目 相 關(guān)聯(lián)。域分析是通過一系列 活動(dòng) 進(jìn)行 表征 的過程 。 有沒有可能不完成如圖 63 所示的 4 種元素就開發(fā)出一個(gè)有效的分析模型？解釋一下。分析模型作為域?qū)ο?的 設(shè)計(jì) 和 建造的 基礎(chǔ)。 b 一個(gè)計(jì)算機(jī)商店的基于 Web 的訂單處理系統(tǒng)。 d 內(nèi)置于電磁灶或微波爐的互聯(lián)網(wǎng)食譜。 答：需要強(qiáng)調(diào)的是 ， 所有 的 數(shù)據(jù) 對象和 關(guān)系 一定 客戶 可見的。 （無固定答案） 答案略。為了 說明 分析包 的作用 ，請 思考一下視頻游戲。 第六章 對于需求分析，結(jié)構(gòu)分析與面向?qū)ο蟛呗杂泻伪举|(zhì)區(qū)別？ 答：結(jié)構(gòu)分析，考慮把數(shù)據(jù)作為分離實(shí)體的變形的數(shù)據(jù)和過程。過程操作數(shù)據(jù)目標(biāo)是被使用它們在系統(tǒng)中的數(shù)據(jù)流向建模的。 在數(shù)據(jù)流圖中，一個(gè)箭 頭表示控制流還是其他？ 答： DFD 數(shù)據(jù)目標(biāo)是用有標(biāo)簽的箭頭所表示的。 在生成 DFD 圖時(shí)，如何使用圖形化解析？ 答：在第一次需求整合會(huì)議中，應(yīng)用工程描述中分離所有名詞和動(dòng)詞的第一步被導(dǎo)出。名詞是 DFD 中的外部實(shí)體（盒子），數(shù)據(jù)或控制目標(biāo)（箭頭），或數(shù)據(jù)存儲(chǔ)（雙實(shí)線）。它也包括程序行為表 —— 組合的行為規(guī)格。 答：不是。一個(gè)有用的情況描述一系列行為包括演員和系統(tǒng)（更著重于用戶可見行為而非算法）。主動(dòng)狀態(tài)指明了目標(biāo) 在轉(zhuǎn)化或執(zhí)行過程中的正確情況。 順序圖指明了事件如何引起目標(biāo)的遷移。 第七章 是的，但是設(shè)計(jì)是隱式進(jìn)行的 —— 通常以隨意的方式進(jìn)行的。 軟件設(shè)計(jì)的目的是運(yùn)用一系列的原則、概念和實(shí)踐導(dǎo)致高質(zhì)量體系或產(chǎn)品的發(fā)展。 通過開展一 系列的正式技術(shù)評審來評估質(zhì)量。通常，根據(jù)將要評審的設(shè)計(jì)信息的范圍，選擇 2 人、 3 人或 4 人參與。在技術(shù)評審會(huì)議結(jié)束后，軟件團(tuán)隊(duì)決定未來的行動(dòng)以來完成最終的產(chǎn)品。每次迭代提供額外的細(xì)節(jié)并且細(xì)化。團(tuán)隊(duì)必須適 應(yīng)一個(gè)通用的任務(wù)集去滿足產(chǎn)品，人和項(xiàng)目的需要。任務(wù)集在章節(jié)中給出。然而在更廣泛的意義上講，部件可以推廣到代表主要的系統(tǒng)元件以及它們之間的交互。高度耦合的問題表現(xiàn)出這一特征。 在某些時(shí)間關(guān)鍵應(yīng)用程序下 ,可能需要單塊集成軟件。“模塊”是內(nèi)聯(lián)編碼。在一般情況下，信息隔離謂詞有隔離功能，因此，各模塊凝聚力也可以改善 外部環(huán)境、編譯器和操作系統(tǒng)耦合將對軟件可移植性造成不利影響。如果沒有終端的軟件被搬到一個(gè)系統(tǒng) ,主要設(shè)計(jì)和代碼可能需要修改。例如，考慮到檢查寫入，我們可能這樣寫： Refinement 1: Write dollar amount in words Refinement 2: Procedure write amount。 Parse to determine each dollar unit。 end write_amount Refinement 3: procedure write_amount。 else set process flag true。 determine maximum significant digit。 divide to determine whole number value。 reduce significant digit count by one。 End do end write_amount 細(xì)化 1： 寫出大寫金額總數(shù)。 用 ? 來表示金額數(shù)，寫出來 。 結(jié)束判斷。 設(shè)置對應(yīng)阿爾法短語 。 略 不，重構(gòu)是一種不改變代碼的外部行為和其功能而改善軟件產(chǎn)品的內(nèi)部質(zhì)量的過程。 四個(gè)要素的設(shè)計(jì)模型： 設(shè)計(jì)模型的四個(gè)元素： 數(shù)據(jù) /類設(shè)計(jì) —— 建立由分析轉(zhuǎn)化的基于類內(nèi)元素的類模型和按數(shù)據(jù)結(jié)構(gòu)要求實(shí)現(xiàn)的軟件。 接口設(shè)計(jì) —— 描述軟件元素 ,硬件元素和用戶終端通信。 第八章 ，與軟件體系結(jié)構(gòu)作對照分析。例如所有的方子都有總體風(fēng)格（墻、頂、地基）。微觀上的模式（房子）可以在木材的類別、壁爐的設(shè)計(jì)以及窗戶上體現(xiàn)出來。不同點(diǎn)：一個(gè)比較實(shí)際，另外一個(gè)比較抽象；房屋或建筑物可變化的空間比較小，軟件體系結(jié) 構(gòu)變化跨度更大一點(diǎn) 舉出 2 到 3 個(gè)例子，說明 節(jié)中提到的每一種體系結(jié)構(gòu)風(fēng)格的應(yīng)用。 數(shù)據(jù)流結(jié)構(gòu)：任何工程或科學(xué)中主要功能是計(jì)算的應(yīng)用程序。 面對對象的體系結(jié)構(gòu)：基于 GUI 的應(yīng)用程序 。 分層體系結(jié)構(gòu)：應(yīng)用功能必須從底層操作系統(tǒng)或網(wǎng)絡(luò)詳細(xì)信息分離的應(yīng)用程序。 ，而另一些則沒有。沒有層次的體系風(fēng)格如何實(shí)現(xiàn)？ 答 : 層次：數(shù)據(jù)流，調(diào)用返回層。 非分層體系結(jié)構(gòu)可能是應(yīng)用面對對象和驅(qū)動(dòng)編程技術(shù)的最好實(shí)現(xiàn)。研究并描述這些術(shù)語之間的不同。 一個(gè)框架可能會(huì)被一些人定義為一組提供了一個(gè)通用的解決問題方案的類，被解決的問題可以被細(xì)化到創(chuàng)建一個(gè)應(yīng)用程序。 答：答案不固定。 答：答案不固定。使用本章描述的設(shè)計(jì)方法開發(fā) PHTRS 的軟件體系結(jié)構(gòu)。 使用數(shù)據(jù)流圖和過程說明，描述一個(gè)有清楚變換流特征的計(jì)算機(jī)系統(tǒng)。 第九章 構(gòu)件級設(shè)計(jì)定義了數(shù)據(jù)結(jié)構(gòu)、算法，界面特性以及分配給每個(gè)軟件構(gòu)件的通信機(jī)制。在傳統(tǒng)語言 (C 或 Fortran)中構(gòu)件式函數(shù)或操作過程。 像面向?qū)ο蟮臉?gòu)件一樣，傳統(tǒng)軟件構(gòu)件是由分析模型所導(dǎo)出的。數(shù)據(jù)流圖的最低層的每個(gè)變換都被映射為某一層上的模塊。為 了獲得有效的模塊化，在構(gòu)建細(xì)化的過程中采用了功能獨(dú)立性的設(shè)計(jì)概念。設(shè)計(jì)者應(yīng)該采用一種無需對結(jié)構(gòu)自身內(nèi)部（代碼或內(nèi)部邏輯）做修改就可以進(jìn)行的擴(kuò)展（在構(gòu)建所確定的功能域內(nèi)）的方式來說明構(gòu)件。 依賴性倒置原則 (DIP)， 依賴于抽象。 構(gòu)件依賴的其他具體構(gòu)件（不是依賴抽象類，如接口）越多，擴(kuò)展起來越困難。高內(nèi)聚的構(gòu)件會(huì)與其他構(gòu)件提供的服務(wù)“絕緣”，從而使其實(shí)施與維護(hù)更加容易。隨著類（構(gòu)件）相互依賴越來越多，類之間的耦合程度亦會(huì)增加。 外部耦合發(fā)生在組件通信或與基礎(chǔ)設(shè)施組件 (如。雖然這種類型的耦合是必要的 ,它應(yīng)該是局限于一小部分系統(tǒng)組件或類。因此 ,耦合是一 個(gè)不爭的事實(shí)。 略 重構(gòu)是系統(tǒng)決策集散控制的過程，目的是讓頂層模塊執(zhí)行控制功能，而底層模塊處理所有輸入，執(zhí)行和輸出工作。在傳統(tǒng)軟件開發(fā)中兩者是很相似的。 略 略 略 人可以短暫記憶一 小部分東西，分塊可以使評審者將相關(guān)概念組合成大的碎片或更大的分塊。 第十章 這道題應(yīng)該不難！許多早期交互 式 系統(tǒng)都有糟糕的界面。許多 web 應(yīng)用程序?yàn)榱?Flash 犧牲易用性。 允許用戶自定義屏幕布局以及命令。 例子如下： 如果用戶有需求，在屏幕上一直顯示快捷鍵命令序列。 例子如下： 使用一致的顏色，例如，紅色用作警示信息，藍(lán)色用作通知信息； 提供關(guān)鍵字驅(qū)動(dòng)的在線幫助。 如果你的學(xué)生在任務(wù)分析上出了問題，老的備用 IPO 將會(huì)有效。 當(dāng)響應(yīng)時(shí)間無法預(yù)測的時(shí)候，使用者會(huì)很不耐 煩并且重復(fù)嘗試請求的命令或者嘗試另一個(gè)命令。研究表明，用戶可以容忍他們熟悉的應(yīng)用程序的響應(yīng)率50%的變化。 答案略。兩者都要用測試用例的設(shè)計(jì)方法和測試策略嗎？ 答： “驗(yàn)證”是通過嘗試在功能或性能上發(fā)現(xiàn)錯(cuò)誤來保證程序的正確性，“確認(rèn)”是保證軟件與需求相一致 —— 這也是質(zhì)量的基本特征。