【正文】 試）：在單元測(cè)試的基礎(chǔ)上，將所有模塊按設(shè)計(jì)要求集成在一起進(jìn)行測(cè)試，以檢驗(yàn)總體設(shè)計(jì)中各模塊間的接口設(shè)計(jì)問(wèn)題、模塊之間的相互影響、上層模塊存在的各種差錯(cuò)及全局?jǐn)?shù)據(jù)結(jié)構(gòu)對(duì)系統(tǒng)的影響等方面。而漸增式測(cè)試把單元測(cè)試與集成測(cè)試合在一起，同時(shí)完成。 答：可靠性：系統(tǒng)在給定的時(shí)間間隔內(nèi)，根據(jù)需求說(shuō)明成功地運(yùn)行的概率。都反映了用戶對(duì)系統(tǒng)的信任程度。 二、選擇題 ，工作量所占比例最大的階段是（ D ）階段 （ A ），降低維護(hù)的代價(jià)。這種維護(hù)活動(dòng)占整個(gè)維護(hù)活動(dòng)的 25%。 軟件的可維護(hù)性是軟件開(kāi)發(fā)階段的關(guān)鍵目標(biāo)。質(zhì)量保證檢查是非常有效的 方法，不僅在軟件開(kāi)發(fā)的各階段中得到了廣泛應(yīng)用，而且在軟件維護(hù)中也是一個(gè)非常主要的工具。 《軟件工程概論》 27 (5)改進(jìn)程序的文檔 程序文檔是對(duì)程序功能、程序各組成部分之間的關(guān)系、程序設(shè)計(jì)策略、程序?qū)崿F(xiàn) 過(guò)程的歷史數(shù)據(jù)等的說(shuō)明和補(bǔ)充。 所有軟件維護(hù)申請(qǐng)報(bào)告應(yīng)按照規(guī)定的方式提出。 (3)對(duì)適應(yīng)性維護(hù)和完善性維護(hù)。 ？ 答： 軟件維護(hù)的困難性是由于軟件需求分析和開(kāi)發(fā)方法的缺陷。但修改軟件會(huì)造成軟件的錯(cuò)誤，這種因修改軟件而造成的錯(cuò)誤或其他不希望出現(xiàn)的情況稱為維護(hù)的副作用。 《軟件工程概論》 29 第 七 章 面向?qū)ο筌浖こ痰母拍? 本章要點(diǎn)： 1．傳統(tǒng)軟件開(kāi)發(fā)方法的局限性 2． OO 軟件的過(guò)程模型 3． OO 的有關(guān)概念及方法 4． UML 語(yǔ)言 本章目標(biāo)： 1．了解傳統(tǒng)軟件開(kāi)發(fā)方法的局限性 2．掌握面向?qū)ο筌浖倪^(guò)程模型 3．明確面向?qū)ο蟮南嚓P(guān)概念 4．了解幾種面向?qū)ο蠓椒? 5．掌握統(tǒng)一建模語(yǔ)言 — UML 本章重點(diǎn)： 1．面向?qū)ο筌浖倪^(guò)程模型 2．統(tǒng)一建模語(yǔ)言 — UML 本章難點(diǎn)： 1．面 向?qū)ο筌浖倪^(guò)程模型 2．統(tǒng)一建模語(yǔ)言 — UML 一、填空題 1．對(duì)象具有狀態(tài)，一個(gè)對(duì)象用（數(shù)據(jù)值）來(lái)描述它的狀態(tài)。需求分析階段重點(diǎn)是功能模型，難以徹底明確全部需求。傳統(tǒng)的方法一般從“零”開(kāi)始開(kāi)發(fā)軟件，數(shù)據(jù)與操作作為相互分離的實(shí)體來(lái)考慮，使軟件的可復(fù)用性差。 分類性是指將具有一致的數(shù)據(jù)結(jié)構(gòu) (屬性 )和行為 (操作 )的對(duì)象抽象成類。 在類層次中，子類繼承了 多個(gè)父類的數(shù)據(jù)結(jié)構(gòu)和方法，則稱為多重繼承。 。盡管 Coad 方法沒(méi)有引入類和類層次結(jié)構(gòu)的術(shù)語(yǔ)，但事實(shí)上已經(jīng)在分類結(jié)構(gòu)、屬性、操作、消息關(guān)聯(lián)等概念中體現(xiàn)了類和類層次結(jié)構(gòu)的特征。 UML 是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用的建模語(yǔ)言。該技術(shù)使用實(shí)際的或虛擬的索引卡片，為定義類提供較多的信息。非 OO 項(xiàng)包括：政策、規(guī)程、計(jì)劃、標(biāo)準(zhǔn)，非 OO 應(yīng)用文檔和構(gòu)件。 （ 5）為對(duì)象開(kāi)發(fā)分析模型。 （ 3）封裝原則 將對(duì)象的各種獨(dú)立的外部特性與內(nèi)部實(shí)現(xiàn)細(xì)節(jié)分開(kāi)。確定用例的準(zhǔn)則： 每個(gè)用例都應(yīng)該為其角色提供有價(jià)值的服務(wù) — 避免確定的用例太小；確保每個(gè)用例都向主要角色提供有價(jià)值的服務(wù) — 避免用例太大。一個(gè)特化用例代表了幾個(gè)相似用例，一個(gè)或多個(gè)特化提供了這些相似用例的細(xì)節(jié)。因此可開(kāi)始用戶界面原型化的迭代過(guò)程，和構(gòu)造系統(tǒng)的其他部分并行進(jìn)行。實(shí)體類大多數(shù)是直接從業(yè)務(wù)模型或領(lǐng)域模型中相應(yīng)實(shí)體類得到的。有些是隱含在問(wèn)題域或一般知識(shí)中的。從《軟件工程概論》 39 問(wèn)題陳述中抽取所有可能的關(guān)聯(lián)表述，把它們記下來(lái)，但不要過(guò)早去細(xì)化這些表述 。 (6)． 完善對(duì)象模型 對(duì)象建模不可能一次就能保證模型是完全正確的，軟 件開(kāi)發(fā)的整個(gè)過(guò)程就是一個(gè) 不斷完善的過(guò)程。 ，一個(gè)模式有四個(gè)基本要素：（ 模式名稱 ）、（ 問(wèn)題 ）、（ 解決方案 ）、（ 效果 ）。面向?qū)ο蠓椒ò?問(wèn)題域作為一系列相互作用的對(duì)象，在此基礎(chǔ)上構(gòu)造出基于對(duì)象的軟件系統(tǒng)結(jié)構(gòu)。 (2)類內(nèi)聚。低耦合是設(shè)計(jì)的一個(gè)重要標(biāo)準(zhǔn)，因?yàn)檫@有助于使得系統(tǒng)中某一部分的變化對(duì)其它部分的影響降到最低程度。 傳統(tǒng)的設(shè)計(jì)方法將問(wèn)題域分解成一系列任務(wù)來(lái)完成。 ：（ 過(guò)程驅(qū)動(dòng)控制 ）、（ 事件驅(qū)動(dòng)控制 ）、（ 線程 ）。 1. 自底向上通過(guò)把現(xiàn)有類的共同性質(zhì)一般化為父類，尋找具有相似的屬性， 關(guān)系或操作的類來(lái)發(fā)現(xiàn)繼承。一種依賴表示一種關(guān)聯(lián)，可用各種方式 來(lái)實(shí)現(xiàn)關(guān)聯(lián)，但在分析模型中應(yīng)刪除實(shí)現(xiàn)的考慮， 以便設(shè)計(jì)時(shí)更為靈活。 (1)． 確定類 構(gòu)造對(duì)象模型的第一步是標(biāo)出來(lái)自問(wèn)題域的相關(guān)的對(duì)象類，對(duì)象包括物理實(shí)體和 概念。主要用來(lái)體現(xiàn)應(yīng)用程序的執(zhí)行邏輯，可以使得變化不影響用戶界面和數(shù)據(jù)庫(kù)中的表。 （ 5）建立用戶界面原型 在面向?qū)ο蟮能浖_(kāi)發(fā)中，用例模型和用戶界面 設(shè)計(jì)息息相關(guān)。 用例有特化、擴(kuò)展和包含關(guān)系。表示了對(duì)象合法存在、對(duì)象合法操作應(yīng)滿足的條件，有助于深刻理解對(duì)象和系統(tǒng)。而具體化值在細(xì)化過(guò)程中，描述對(duì)象的某些特性，加強(qiáng)系統(tǒng)模型的穩(wěn)定性。 4．估算在領(lǐng)域中復(fù)用這些對(duì)象的應(yīng)用的百分率。 A．類與對(duì)象 B．成分對(duì)象與對(duì)象 C．過(guò)程與對(duì)象 D．類與界面 6．同一類中有相同的數(shù)據(jù)結(jié)構(gòu)，這是（ D ）級(jí)別的共享 A．不同應(yīng)用 B．同一應(yīng)用 C．不同類 D．同一類 三、問(wèn)答題 《軟件工程概論》 36 ？ 答：（ 1）定義將被調(diào)查的領(lǐng)域 分離感興趣的業(yè)務(wù)域、系統(tǒng)類型或產(chǎn)品范疇，抽取 OO 和非 OO 的“項(xiàng)”。它還可以用來(lái)（ 驅(qū)動(dòng)開(kāi)發(fā)過(guò)程 ）。 UML 將是面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標(biāo)準(zhǔn)建模語(yǔ)言。該方法的主要優(yōu)點(diǎn)是通過(guò)多年來(lái)大系統(tǒng)開(kāi)發(fā)的經(jīng)驗(yàn)與面向?qū)ο蟾拍畹挠袡C(jī)結(jié)合，在對(duì)象、結(jié)構(gòu)、屬性和操作的認(rèn)定方面，提出了一套系統(tǒng)的原則。 多態(tài)性允許每個(gè)對(duì)象以適合自身的方式去響應(yīng)共同的消息。 繼承性是面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言不同于其它語(yǔ)言的最重要的特點(diǎn)，是其他語(yǔ)言所沒(méi)有的。在對(duì)象的整 個(gè)生命期中，它的標(biāo)識(shí)都不改變，不同的對(duì)象不能有相同的標(biāo)識(shí)。解決問(wèn)題的類型一般用于“輸入－處理－輸出”為核心的數(shù)據(jù)處理系統(tǒng)，不適應(yīng)于復(fù)雜的實(shí)時(shí)、交互、事件驅(qū)動(dòng)、分布式等新型應(yīng)用的系統(tǒng)開(kāi)發(fā)。系統(tǒng)圍繞著由計(jì)算機(jī)來(lái)實(shí)現(xiàn)功能的復(fù)雜過(guò)程而建立，在分析和解決問(wèn)題時(shí)與人們對(duì)現(xiàn)實(shí)世界的認(rèn)識(shí)有一定差距。 （ 2）采用演化式的系 統(tǒng)開(kāi)發(fā)模型（如增量、螺旋），建立能結(jié)合新需求而演化和變更的系統(tǒng)。 ， 由于維護(hù)工作的困難性，維護(hù)工作經(jīng)常遭受挫折，而且很難出成果，不像軟件開(kāi)發(fā)工作那樣吸引人 。在發(fā)生重大問(wèn)題時(shí)，需要立即解決的問(wèn)題。 一個(gè)維護(hù)申請(qǐng)?zhí)岢鲋?，?jīng)評(píng)審需要維護(hù)則按下列過(guò)程實(shí)施維護(hù)： (1)首先確定要進(jìn)行維護(hù)的類型。 (3)進(jìn)行維護(hù)并做詳細(xì)記錄。低級(jí)語(yǔ)言很難掌握，很難理解，因而很難 維護(hù)。面向?qū)ο蟮能浖? 開(kāi)發(fā)方法就是一個(gè)非常實(shí)用而強(qiáng)有力的軟件開(kāi)發(fā)方法，用面向?qū)ο蠓椒ㄩ_(kāi)發(fā)出來(lái)的軟件系統(tǒng)，穩(wěn)定性好，比較容易修改，比較容易理解，易于測(cè)試和調(diào)試，因此，可維護(hù)性好。 ？與可維護(hù)性相關(guān)的質(zhì)量屬性是什么？如何提高軟件的可維護(hù)性？ 答： 軟件可維護(hù)性的定義：軟件能夠被理解、校正、適應(yīng)及增強(qiáng)功 能的容易程度。 （ 2） 適應(yīng)性維護(hù) 隨著計(jì)算機(jī)的飛速發(fā)展，計(jì)算機(jī)硬件和軟件環(huán)境也在不斷發(fā)生變化，數(shù)據(jù)環(huán)境也 在不斷發(fā)生變化。 4．軟件維護(hù)費(fèi)用增加的主要原因是維護(hù)的（ 生產(chǎn)率 ）非常低。同樣的概念也適用于軟件系統(tǒng)。 （ 7）非漸增式開(kāi)始可并行測(cè)試所有模塊，能充分利用人力，對(duì)測(cè)試大型軟件很有意義。每加入一個(gè)新模塊進(jìn)行一次集成的測(cè)試，重復(fù)此過(guò)程直至程序組 裝完畢。 答： 軟件測(cè)試一般分為四個(gè)步驟： （ 1）單元測(cè)試（也稱模塊測(cè)試）：針對(duì)軟件設(shè)計(jì)的基本單元 —程序模塊，進(jìn)行正確 性檢驗(yàn)的測(cè)試工作。只在軟件的接口處進(jìn)行測(cè)試，依據(jù)需求規(guī)格說(shuō)明書，檢查程序是否滿足功能需求。 （ 3）除了檢查程序是否做了它應(yīng)該做的事，還可檢查程序是否做了它不應(yīng)該做的事。 5．二分法檢索將檢索空間劃分成了三個(gè)部分，每個(gè)部分構(gòu)成了一個(gè)（ 等價(jià)類 ），選擇這些等價(jià)類集合的（ 邊界值 ）作為測(cè)試用例。 （ 4）評(píng)估模塊接口以降低復(fù)雜度和冗余并提高一致性。包括：無(wú)直接耦合、數(shù)據(jù)耦合、標(biāo)記耦合、控制耦合、公共耦合、內(nèi)容耦合。每個(gè)模型對(duì)象可能有許 多獨(dú)立的視圖對(duì)象與之關(guān)聯(lián)，例如表示數(shù)字?jǐn)?shù)據(jù)的模型可能有一個(gè)直方圖的或一個(gè)表格的視圖。 （ 6）用戶差異性：界面應(yīng)該為不同類型用戶提供合適的交互功能。 （ 3）動(dòng)態(tài)模型：補(bǔ)充模型，強(qiáng)調(diào)系統(tǒng)的行為性質(zhì)。 7． MVC 模型指的是（ 模型－視圖－控制器 ）模型。 頂層圖： 《軟件工程概論》 13 數(shù)據(jù)流條目： 報(bào)名單＝姓名＋性別＋年齡＋學(xué)歷＋身份證號(hào)碼＋地區(qū)＋職業(yè)＋待考專業(yè) 成績(jī)單＝姓名＋專業(yè)＋｛科目＋考試時(shí)間＋成績(jī)｝ 41 考生通知單＝姓名＋專業(yè)＋｛科目＋考試時(shí)間＋考試地點(diǎn)｝？？ 準(zhǔn)考證＝編號(hào)＋姓名＋性別＋年齡＋身份證號(hào) 總報(bào)名單＝｛報(bào)名單｝＋各專業(yè)人數(shù)＋總?cè)藬?shù) 數(shù)據(jù)項(xiàng)條目： 成績(jī)：別名：平均成績(jī) 類型：實(shí)型 長(zhǎng)度： 6 位，小數(shù)點(diǎn)后一位 準(zhǔn)考證編號(hào)：別名：無(wú) 類型：字符串 長(zhǎng)度： 10 取值范圍及含義：前四位表示專業(yè)，后六位表示本專業(yè)內(nèi)編號(hào) …… 加工條目： 加工名稱： EMS 編號(hào)：無(wú) 輸入 /出：略 加工邏輯：對(duì)全市的成人自學(xué)考試進(jìn)行管理，主要功能有：報(bào)名、 考試、成績(jī)管理等。 這樣，該系統(tǒng)的頂層 DFD 就確 定了。 （ 3）對(duì)于一些頻繁的人機(jī)交互的軟件系統(tǒng)，如飛機(jī)訂票、銀行管理、文獻(xiàn)檢查等系統(tǒng)，用戶最關(guān)心的是如何使用它，輸入命令、操作方式、系統(tǒng)響應(yīng)方式、輸入格式等等，都是用戶需求的重要方面， DFD 不適合描述人機(jī)界面系統(tǒng)的需求。 （ 3）具體需求：說(shuō)明每個(gè)功能的輸入、處理和輸出；外部接口需求，包括用戶接口、軟件接口、硬件接口和通信接口；性能需求；設(shè)計(jì)約束；其他需求，包括數(shù)據(jù)庫(kù)、操作等。 數(shù)據(jù)字典和數(shù)據(jù)流圖共同構(gòu)成了系統(tǒng)的邏輯模型，是需求規(guī)格說(shuō)明書的主要組成部分。 2．需求分析的原則是什么？ 答：需 求分析的原則如下： （ 1）必須能夠表達(dá)和理解問(wèn)題的數(shù)據(jù)域和功能域。 （ 手工建立 ）和（ 利用計(jì)算機(jī)輔助建立并維護(hù) ）。 （ 4）風(fēng)險(xiǎn)控制：定期進(jìn)行風(fēng)險(xiǎn)評(píng)估，及時(shí)修正緩解風(fēng)險(xiǎn)的計(jì)劃。 （ 6）綜合支持計(jì)劃：規(guī)定軟件開(kāi)發(fā)過(guò)程中所需要的支持，以及如何獲取和利用這些支持。 A． 技術(shù)可行性 B． 經(jīng)濟(jì)可行性 C． 社會(huì)可行性 D． 操作可行性 2． 技術(shù)可行性要解決（ D ）。 第 二 章 軟件項(xiàng)目管理 本章要點(diǎn)： 1． 軟件項(xiàng)目管理的概念 2． 可行性研究 3． 軟件項(xiàng)目計(jì)劃 4． 項(xiàng)目進(jìn)度安排與跟蹤 5． 軟件質(zhì)量管理 6． 軟件配置管理 本章目標(biāo)： 1． 掌握軟件項(xiàng)目管理的概念 2． 了解可行性研究的任務(wù)和目的 3． 掌握軟件項(xiàng)目計(jì)劃的相關(guān)內(nèi)容 4． 了解軟件質(zhì)量保證的相關(guān)內(nèi)容 本章重點(diǎn)： 1． 可行性研究的任務(wù)和目的 2． 軟件項(xiàng)目計(jì)劃的相關(guān)內(nèi)容 本章難點(diǎn)： 1． 可行性研究的任務(wù)和目的 《軟件工程概論》 5 2． 軟件項(xiàng)目計(jì)劃的相關(guān)內(nèi)容 一 、 填空題 1．（ 軟件可行性研究 ）的目的就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定該軟件項(xiàng)目是否能夠開(kāi)發(fā)，是否值得去開(kāi)發(fā)。 量模型的基本思想是什么？ 答： 為了克服瀑布模型的局限性，使開(kāi)發(fā)過(guò)程具有一定的靈活性和可修改性，于是產(chǎn)生了增量模型。 表現(xiàn)：開(kāi)發(fā)的軟件不能滿足用戶的要求；無(wú)完整、規(guī)范的文檔，難以維護(hù)；項(xiàng)目計(jì)劃不周，進(jìn)度拖延；軟件質(zhì)量差。 3．軟件生存周期包括（ 可行性研究 ）和（ 項(xiàng)目開(kāi)發(fā)計(jì)劃 ）、（ 需求分析 ）、（ 軟件設(shè)計(jì) ）、（ 編碼 ）、（ 測(cè)試 ）和（ 維護(hù) ）等活動(dòng)。 6．螺旋模型將（ 瀑布 ）模型和（ 增量 ）模型結(jié)合起來(lái)，加入了兩種模型均忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了這兩種模型的不足。在軟件管理方面，主要是研究軟件管理學(xué)，軟件經(jīng)濟(jì)學(xué)，軟件心理學(xué)等 ？ 軟件生存周期模型是描述 軟件開(kāi)發(fā)過(guò)程中，各種活動(dòng)如何執(zhí)行的模型，軟件生存周期模型確立了軟件開(kāi)發(fā)和演繹中各階段的次序限制以及各階段活動(dòng)的準(zhǔn)則，確立開(kāi)發(fā)過(guò)程 所遵守的規(guī)定和限制，便于各種活動(dòng)的協(xié)調(diào)，便于各種人員的