《軟件工程》備考知識點匯總

第一章緒論

1.軟件工程這一術語首次出現在1968年的NATO會議上.

2.軟件危機:隨著計算機的廣泛應用，軟件生產率、軟件質量遠遠滿足不了社

會發(fā)展的需求，成為社會、經濟發(fā)展的制約因素，人們通常把這--現象稱為“軟件

危機”.

3.軟件工程:軟件工程是應用計算機科學理論和技術以及工程管理原則和方

法,按預算和進度實現滿足用戶要求的軟件產品的工程,或以此為研究對象的學

科.

4.軟件工程概念的提出，其目的是倡導以工程的原理、原則和方法進行軟件

開發(fā)，以期解決出現的“軟件危機”.

5.20世紀60年代末到80年代初,提出了瀑布模型,試圖為開發(fā)人員提供有

關活動組織方面的指導;開發(fā)了諸多過程式語言C例如，Pascal語言、C語

言、Ada語言等）和開發(fā)方法（例如，Jackson方法、結構化方法等），

試圖為開發(fā)人員提供好的需求分析和設計手段,并開發(fā)了一些支持工具,如

調試工具、測試工具等.在這一時期，開始出現各種管理方法（例如，費用估算、文

檔復審〉，開發(fā)了一些相應支持工具（例如，計劃工具、配置管理工具）等.

6.20世紀80年代以來,這一時期的主要成果是提出了《軟件生存周期過

程》等一系列軟件工程標準;大力開展了計算機輔助軟件工程（CASE）的研究與實

踐（例如，我國在“七五”、“八五”、“九五”期間，均把這一研究作為國家

重點科技攻關項目〉，各類CASE產品相繼問世.與此同時,在工程技術方

面，出現了最引人注目的面向對象語言，例如Smalltalk、c++、Eiffel等;提出

了面向對象軟件開發(fā)方法;在工程管理方面,開展了一系列過程改進項目，

其目標是在軟件產業(yè)的實踐中,建立一種量化的評估程序,判定軟件組織和

過程的成熟度,提高組織的過程能力.

7.計算機軟件一般是指計算機系統(tǒng)中的程序及其文檔.

8.軟件開發(fā)的本質概括為:不同抽象層術語之間的“映射"，以及不同抽象層

處理邏輯之間的“映射”.

9.模型是在特定意圖下所確定的角度和抽象層次上對物理系統(tǒng)的描述,通常

包含對該系統(tǒng)邊界的描述、對系統(tǒng)內各模型元素以及它們之間關系的語義描述.

10.軟件系統(tǒng)模型大體上可分為兩類:概念模型和軟件模型

11.實施軟件開發(fā)的基本途徑:實施軟件開發(fā)的基本途徑是系統(tǒng)建模.所謂系

統(tǒng)建模,是指運用所掌握的知識,通過抽象,給出該系統(tǒng)的一個結構——系統(tǒng)模型.

12.軟件開發(fā)所涉及的兩大類技術:一是求解軟件的開發(fā)邏輯（過程方向），二

是求解軟件的開發(fā)手段（過程途徑）.

第二章軟件需求與需求規(guī)約

1.一個需求是有關一個“要予構造”的陳述,描述了待開發(fā)產品/系統(tǒng)（或

項）功能上的能力、性能參數或其他性質.

2.對于單一一個需求,必須具有如下5個基本性質：

?必要的（Necessary），該需求是用戶所要求的.

,元歧義的（Unambiguous），該需求只能用一種方式解釋.

?可測的(Testable)，該需求是可進行測試的.

?可跟蹤的(Traceable)，該需求可從一個開發(fā)階段跟蹤到另一個階

段.

,可測量的(Measurable)，該需求是可測量的.

3.需求分為兩大類：一類是功能需求,一類是非功能需求,而非功能需求又可

分為性能需求、外部接口需求、設計約束和質量屬性需求.

4.功能需求規(guī)約了系統(tǒng)或系統(tǒng)構件必須執(zhí)行的功能.

5.接口需求可分為以下主要7類：

1)用戶接口(UserInterfaces):描述軟件系統(tǒng)和用戶之間交互的邏

輯特性,即這類接口需求應規(guī)約對給定用戶所顯示的數據,要從用戶那里得到的數

據以及用戶如何控制該用戶接口.

2)硬件接口(HardwareInterfaces):描述軟件系統(tǒng)與硬件設備之間

的交互，以實現對硬件設備的響應和控制,其中應描述所要求的支持和協(xié)議類型.

3)軟件接口(SoftwareInterlaces):描述與其他軟件產品(例如，數

據管理系統(tǒng)、操作系統(tǒng)或數學軟件包)進行的交互.

4)通信接口(CommunicationInterfaces):描述待開發(fā)系統(tǒng)與通信設

施(例如,局域網)之間的交互.如果通信需求包含了系統(tǒng)必須使用的網絡類型

(TCP/IP、MicrosoftWindows

NT,Novell)，那么有關類型的信息就應包含在該需求描述中.

5)內存約束:描述易失性存儲和永久性存儲的特性和限制,特別應描述

它們是否被用于與一個系統(tǒng)中其他處理的通信.

6)運行(Operation):描述用戶如何使系統(tǒng)進入正常和異常的運行，以

及在系統(tǒng)正常和異常運行下如何與系統(tǒng)進行交互，其中應描述在用戶組織中的運

行模式,包括交互模式和非交互模式；

描述每一模式的數據處理支持功能；描述有關系統(tǒng)備份、恢復和升

級功能方面的需求.

7)地點需求(SiteAdaptationRequiremen創(chuàng)：描述系統(tǒng)安裝以及如

何調整一個地點，以適應新的物理環(huán)境.

6.設計約束是一種需求,它限制了軟件系統(tǒng)或軟件系統(tǒng)構件的設計方案的范

圍.

7.質量屬性(QualityAttribute)規(guī)約了軟件產品所具有的一個性質(包括

功能和其他需求)必須達到其質量方面一個所期望的水平.

8.初始發(fā)現需求的常用技術包括以下幾個.

(1)自悟(Introspection).需求人員把自己作為系統(tǒng)的最終用戶，審

視該系統(tǒng)并提出問題：“如果是我使用這一系統(tǒng)，則我需要……

適用情況:需求人員不能直接與用戶進行交流，自悟就可能是一種

切實可行的、比較有吸引力的方法.

成功條件:需求人員必須具有比最終用戶還要多的應用領域和過程

方面的知識,并具有豐富的想象力.

存在的風險:無法驗證發(fā)現的需求是否滿足用戶的要求,無法驗證

發(fā)現的需求是不是正確的.

(2)交談(IndividualInterview).為了確定系統(tǒng)應該提供的功能,

需求人員通過提出問題/用戶回答這一方式,直接詢問用戶需要的是一個什么樣

的系統(tǒng).

適用情況:客戶支持需求人員與最終用戶進行有關系統(tǒng)需求的交

流.

成功條件:依賴于

?需求人員是否具有“正確提出問題”的能力.

?回答人員是否具有“揭示需求本意”的能力.

存在的風險:在交談期間所獲得的需求可能不斷增長,或是以前沒

有認識到的合理需求的一種表現，或是“完美蠕行"(CreepingElegance)病癥

的體現，以至于很難控制,可能導致超出項目成本和進度的限制.

應對措施:項目管理人員和客戶管理人員應該定期地對交談過程的

結果進行復審.其中具有挑戰(zhàn)的問題是,判斷以下內容：

?什么時候界定這一增長.

?什么時候將這一增長通知客戶.

(3)觀察(Observation).通過觀察用戶執(zhí)行其現行的任務和過程，或

通過觀察他們如何操作與所期望的新系統(tǒng)有關的現有系統(tǒng)，了解系統(tǒng)運行的環(huán)境,

特別是了解要建立的新系統(tǒng)與現存系統(tǒng)、過程以及工作方法之間必須進行的交

互.

與“交談”的比較:盡管了解的這些信息可以通過交談獲取，但“第

一手材料”一般總能比較好地“符合現實”.

適用情況:用戶允許需求人員進入工作現場,并可進行觀察,可與有

關人員就有關問題進行交流.

成功條件:需求人員具有洞察事物本質的能力.

存在的風險：

?客戶可能抵觸這一觀察.其原因是他們認為開發(fā)者打擾了他

們的正常業(yè)務.

?客戶可能認為開發(fā)者在簽約之前,就已經熟悉了他們的業(yè)務.

(4)小組會(GroupSession).舉行客戶和開發(fā)人員的聯(lián)席會議，與客

戶組織的一些代表共同開發(fā)需求.其中：

1)通常是由開發(fā)組織的一個代表作為首席需求工程師或軟件

工程項目經理,主持這一會議.當然,還可以采用其他形式,這依賴于其應用領域和

主持人的能力.主持人的作用主要是掌握會議的進程.

2)必須仔細地選擇該小組的成員,不僅要考慮他們對目前和未

來運行環(huán)境的理解程度,還要考慮他們的人品.

適用情況:各方組織在管理層面上重視需求工作，并有能力提供人力

資源.

成功條件:會議組織得當,包括責權分明，參與會議的人員具有良好

的需求發(fā)現能力,并允許發(fā)表不同的觀點，以便很快地標識需求，揭示需求中存在

的問題，并與客戶達成共識.

存在的風險:如果會議組織不到位或受到某些客觀環(huán)境的限制，就有

可能過多地召開這樣的會議,并產生一些相互矛盾的需求.

(5)提煉(Extraction).復審技術文檔(例如，有關需要的陳述、功能

和性能目標的陳述、系統(tǒng)規(guī)約接口標準、硬件設計文檔等)，并提取相關的信息.

適用情況:提煉方法是針對已經有了部分需求文檔的情況.依據產品

的本來情況,可能有很多文檔需要復審，以確定其中是否包含相關聯(lián)的信息.有時，

也可能只有少數文檔需要復審.

成功條件：已存在項目背景文檔以及一些緊密相關的需求文檔,并且

需求人員具有很好的想象力和需求標識能力,包括熟悉相關的技術標準和法規(guī)政

策等.

存在的風險:與自悟方法一樣,無法驗證所發(fā)現的需求是否滿足用戶

的要求,無法驗證發(fā)現的需求是否正確.

9.需求規(guī)約是一個軟件項/產品/系統(tǒng)所有需求陳述的正式文檔,它表達了

一個軟件產品/系統(tǒng)的概念模型.

10.需求規(guī)約一般需要滿足以下4個基本性質.

1）重要性和穩(wěn)定性程度：按需求的重要性和穩(wěn)定性,對需求進行分級，例

如:基本需求、可選需求和期望需求.

2）可修改的:在不過多地影響其他需求的前提下,可以容易地修改一個

單一需求.

3）完整的:沒有被遺漏的需求.

4）一致的:不存在互斥的需求.

11.需求規(guī)約的表達主要存在3種不同的風格.

（1）非形式化的需求規(guī)約.

（2）半形式化的需求規(guī)約

（3）形式化的需求規(guī)約

12.需求規(guī)約的作用可概括為以下4點：

1）需求規(guī)約是軟件開發(fā)組織和用戶之間一份事實上的技術合同書,是產

品功能及其環(huán)境的體現.

2）對于項目的其余大多數工作,需求規(guī)約是一個管理控制點.

3）對于產品/系統(tǒng)的設計，需求規(guī)約是一個正式的、受控的起始點.

4）需求規(guī)約是創(chuàng)建產品驗收測試計劃和用戶指南的基礎,即基于需求規(guī)

約一般還會產生另外兩個文檔一一初始測試計劃和用戶系統(tǒng)操作描述.

13.簡述需求規(guī)約和項目需求的不同.

需求規(guī)約和項目需求是兩個不同的概念.需求規(guī)約是軟件開發(fā)組織和用

戶之間一份事實上的技術合同書，即關注產品需求,回答“交付給客戶的產品/系

統(tǒng)是什么”；

而項目需求是客戶和開發(fā)者之間有關技術合同一一產品/系統(tǒng)需求的理

解,應記錄在工作陳述中或其他某一項目文檔中，即關注項目工作與管理,回答

“開發(fā)組要做的是什么”.

14..什么是驗證和確認？簡述它們的區(qū)別.

第三章結構化方法

為了實現以上的分析目標，作為支持需求分析的結構化分析方法，一要給出

一些基本術語（參見第3.1.1節(jié)），支持表達分析中所需要使用的信息；二要給

出表達系統(tǒng)模型的工具（參見第3.1.2節(jié)），支持表達系統(tǒng)功能；三要給出過程

指導（參見第3.1.3節(jié)〉，

支持如何系統(tǒng)化地使用相關信息來建造系統(tǒng)模型.

----結構化需求分析----

1.在進行軟件系統(tǒng)/產品的需求工作中，通常面臨三大挑戰(zhàn).

（1）問題空間理解.

（2）人與人之間的通信.

（3）需求的變化性.

2.數據流是一類術語，用于表達在分析中所要使用的、用于表達“客體”的

信息.

3.加工也是一類術語，用于表達在分析中所使用的、用于表達“處理”的信

息.

4.數據存儲也是一類術語，用于表達在分析中所使用的、表達“結構化客

體”的信息.

5.建模過程

1.建立系統(tǒng)環(huán)境圈,確定系統(tǒng)語境.結構化方法是通過系統(tǒng)頂層數據流

圖來定義系統(tǒng)語境的.

2.自頂向下,逐步求精,建立系統(tǒng)的層次數據流圖.在頂層數據流圖的基

礎上,按功能分解的設計思想,進行“自頂向下,逐步求精”，即對加工進行分解，

自頂向下地畫出各層數據流圖，直到底層的加工足夠簡單,功能清晰易

懂,不必再繼續(xù)分解為止,并把這樣的加工稱為葉加工.

3.定義數據字典,該步的目標為依據系統(tǒng)的數據流圖,定義其中包含的

所有數據流和數據存儲的數據結構，直到給出構成以上數據的各數據項的基本數

據類型.

所有客體均可用以下3種基本結構表示，這3種結構分別為

順序結構(指數據A是由數據B和數據C順序構成的)：學生成績=

姓名+性別+學號+科目+成績

選擇結構(指由數據A或是由數據B.或是由數據C.定義的)：性別=

男I女

重復結構(是指數據A是由多個重復出現的數據B構成的)：學生成

績表=(學生成績)

4.描述加工,該步的目標為依據系統(tǒng)的數據流圖,給出其中每一加工的

小說明.由于需求分析的目的是定義問題，因此對DFD圖中的每一加工只需給出

加工的輸入數據和輸出數據之間的關系，即從外部來“視察”一個加工的邏輯.

3種表達工具：

(1)結構化自然語言.

(2)判定表.

(3)判定樹.

6.抽象和分解是結構化分析方法采用的兩個基本手段.

7.需求階段:需求發(fā)現、需求分析和需求驗證.

=======結構化需求設計=======

----總體設計----

8.結構化設計的主要任務是在需求分析的基礎上,定義滿足需求所需要的結

構，即針對給定的問題,給出該問題的軟件解決方案，確定“怎么做”的問題.

9.結構化方法在總體設計中引入了兩個基本概念:一是模塊,即指軟件中具有

特定標識的獨立成分;二是模塊調用，即指模塊之間的一種使用關系.

10.總體設計階段的基本任務是把系統(tǒng)的功能需求分配到一個特定的軟件體

系結構中.表達這一軟件體系結構的工具很多，主要有以下幾種.

(1)Yourdon提出的模塊結構圖.

模塊結構圖是系統(tǒng)的一個高層“藍圖”，允許設計人員在較高的層

次上進行抽象思維,避免過早地陷入特定的條件、算法和過程步等實現細節(jié).尾部

是空心圓的箭頭線標明傳遞的是數據信息，尾部是實心圓的箭頭線

標明傳遞的是控制信息.

(2)層次圖.層次圖很適合在自頂向下設計軟件的過程中使用.

(3)I1IP0圖.HIPO是由美國IBM公司提出的，其中HIPO是“層次圖+

輸入/處理/輸出”的英文縮寫，實際上，HIPO圖由H圖和IP0圖兩部分組成

的.H圖就是上面所講的層次圖.但是，為了使HIPO圖具有可跟蹤性，除H圖〈層

次圖)最頂層的方框之外,為每個方框都加了編號

11.如何將需求分析所得到的系統(tǒng)DFD圖映射為設計層面上的模塊和模塊調

用，這是結構化設計方法所要回答的問題.

12.該方法在分類DFD的基礎上，基于自頂向下、功能分解的設計原則，定

義了兩種不同的“映射”，即變換設計和事務設計.其基本步驟是,首先將系統(tǒng)的

DFD圖首先轉化為初始的模塊結構圖,再基于“高內聚低搞合”這一軟件設計原

理,通過模塊化,將初始的模塊結構圖轉化為最終的、可供詳細設計使用的模

塊結構圖(MSD).

13.通過大量軟件開發(fā)的實踐,人們發(fā)現,無論待建系統(tǒng)的數據流圖如何復雜，

一般總可以把它們分成兩種基本類型，即變換型數據流圖和事務型數據流圖.

14.系統(tǒng)/產品的模塊結構圖以及相關的全局數據結構和每一模塊的接口，是

軟件設計中的一個重要制品，是系統(tǒng)/產品的高層設計“藍圖”.

15.總體設計步驟

(1)變換型數據流圖.

(2)事務型數據流圖.

16.在實際應用中，任何軟件系統(tǒng)從本質上來說都是信息的變換裝置,因此,原

則上所有的數據流圖都可以歸為變換型.

17.總體設計分為3個階段.

第一階段為初始設計,在對給定的數據流圖進行復審和精化的基礎上,將

其轉換為初始的模塊結構圖.

(1)變換設計.

第1步:設計準備一復審并精化系統(tǒng)模型.

第2步:確定輸入、變換、輸出這三部分之間的邊界.

從物理輸入端到邏輯輸入,構成系統(tǒng)的輸入部分.

第3步:第一級分解一一系統(tǒng)模塊結構圖頂層和第一層的設計

根據變換型數據流圖的基本特征顯然它所對應的軟件系統(tǒng)

應由輸入模塊、變換模塊和輸出模塊組成.并且，為了協(xié)調這些模塊的“有序”工

作,還應設計一個所謂的主模塊，作為系統(tǒng)的頂層模塊.因此,變換型數據流圖所對

應的軟件結構有一個主模塊以及由它控制的3個部分組成.

第4步：“第二級分解”一一自頂向下，逐步求精.

(2)事務設計.

第1步:設計準備一一復審并精化系統(tǒng)模型.

第2步:確定事務處理中心.

第3步：“第一級分解"一一系統(tǒng)模塊結構圖頂層和第一層的

設計.

第4步：“第二級分解”一一自頂向下，逐步求精.

第二階段為精化設計，依據模塊“高內聚低藕合”的原則，精化初始的模

塊結構圖,并設計其中的全局數據結構和每一模塊的接口.

第三階段為復審階段對前兩個階段所得到的高層軟件結構進行復審，必

要時還可能需要對該軟件結構做一些精化工作,這對軟件的一些性質,特別是對軟

件質量的提高將產生非常大的影響.

18.實踐中，一個大型的軟件系統(tǒng)一般是變換型流圖和事務型流圖的混合結

構.在軟件總體設計中,通常以變換設計為主,事務設計為輔進行結構設計.即首先

利用變換設計,把軟件系統(tǒng)分為輸入、中心變換和輸出3個部分,設計上層模塊，

然后根據各部分數據流圖的結構特點，適當地利用變換設

計和事務設計進行細化,得到初始的模塊結構圖,再按照“高內聚低藕

合”的原則,對初始的模塊結構圖進行精化,得到最終的模塊結構圖.

19.模塊是執(zhí)行一個特殊任務的一個過程以及相關的數據結構.模塊通常由兩

部分組成.一部分是接口，給出可由其他模塊或例程訪問的常量、變量、函數等.

接口不但可用于刻畫各個模塊之間的連接，以體現其功能,而且還對其他模塊的設

計者和使用者提供了一定的可見性.模塊的另一部分是模塊體,是接口的實現.

20.耦合:耦合是指不同模塊之間相互依賴程度的度量.

①內容耦合：當一個模塊直接修改或操作另一個模塊的數據，或一個模塊

不通過正常入口而轉入到另一個模塊時,這樣的耦合被稱為內容耦合.內容精合是

最高程度的耦合,應該盡量避免使用.

②公共耦合:兩個或兩個以上的模塊共同引用一個全局數據項，這種耦合

被稱為公共耦合.在具有大量公共藕合的結構中，確定究竟是哪個模塊給全局變量

賦了一個特定的值是十分困難的.

③控制耦合:一個模塊通過接口向另一個模塊傳遞一個控制信號,接收信

號的模塊根據信號值進行適當的動作,這種精合被稱為控制搞合.在實際設計中，

通過保證每個模塊只完成一個特定的功能，這樣就可以大大減少模塊之間的這種

耦合.

④標記耦合:若一個模塊A通過接口向兩個模塊B和C傳遞一個公共

參數，那么稱模塊B和C之間存在一個標記耦合.

⑤數據耦合:模塊之間通過參數來傳遞數據,則稱為數據耦合.數據耦合

是最低的一種耦合形式,系統(tǒng)中一般都存在這種類型的藕合,因為為了完成一些有

意義的功能,往往需要將某些模塊的輸出數據作為另一些模塊的輸入數據.耦合影

響軟件復雜程度和設計質量的一個重要因素,在設計上我們應采取以下原則：

如果模塊間必須存在耦合,就盡量使用數據藕合,少用控制耦合，限制公

共搞合的范圍，盡量避免使用內容精合.

21.內聚：內聚是指一個模塊內部各成分之間相互關聯(lián)程度的度量.

①偶然內聚:如果一個模塊的各成分之間基本不存在任何關系，則稱為偶

然內聚.例如,有時在編寫一段程序時,發(fā)現有一組語句在兩處或多處出現,于是把

這組語句作為一個模塊，以減少書寫工作量,但這組語句彼此間沒有任何關系,這

時就出現了偶然內聚.

因為這樣的模塊一般沒有確定的語義或很難了解它的語義，那么當在一個應

用場合需要對之進行理解或修改時,就會產生相當大的困難.事實上,系統(tǒng)中如果

存在偶然內聚的模塊，那么對系統(tǒng)進行修改所發(fā)生的錯誤概率就比其他類型的模

塊高得多.

②邏輯內聚:幾個邏輯上相關的功能被放在同一模塊中，則稱為邏輯內

聚.例如，一個模塊讀取各種類型外設的輸入（包括卡片、磁帶、磁盤、鍵盤等），

而不管這些輸入從哪兒來、做什么用，因為這個模塊的各成分都執(zhí)行輸入,所以，

該模塊是邏輯內聚的.盡管邏輯內聚比偶然內聚度高一些，

但邏輯內聚的模塊各成分在功能上并無關系，即使局部功能的修改有時也會

影響全局，因此,這類模塊的修改也比較困難.

③時間內聚:如果一個模塊完成的功能必須在同一時間內執(zhí)行（例如,初

始化系統(tǒng)或一組變量），但這些功能只是因為時間因素關聯(lián)在一起則稱為時間內

聚.時間內聚在一定程度上反映了系統(tǒng)的某些實質，因此，比邏輯內聚高一些.

④過程內聚:如果一個模塊內部的處理成分是相關的,而且這些處理必須

以特定的次序執(zhí)行,則稱為過程內聚.使用程序流程圖作為工具設計軟件時,常常

通過研究流程圖確定模塊的劃分,這樣得到的往往是過程內聚的模塊.

⑤通信內聚:如果一個模塊的所有成分都操作同一數據集或生成同一數

據集,則稱為通信內聚,如圖3-43所示.在實際設計中這樣的處理有時是很自然

的，而且也顯得很方便，但是出現的通信內聚經常破壞設計的模塊化和功能獨立

性.

⑥順序內聚:如果一個模塊的各個成分和同一個功能密切相關,而且一個

成分的輸出作為另一個成分的輸入,則稱為順序內聚.

⑦功能內聚:最理想的內聚是功能內聚,模塊的所有成分對于完成單一的

功能都是基本的.功能內聚的模塊對完成其功能而言是充分必要的.

內聚和耦合是密切相關的，同其他模塊存在高耦合的模塊常意味著是低

內聚的,而高內聚的模塊常意味著該模塊同其他模塊之間是低搞合的.在進行軟件

設計時，應力爭做到高內聚、低耦合.

18.啟發(fā)式規(guī)則.不論是變換設計還是事務設計,都涉及一個共同的問題,即

“基于高內聚低藕合的原理,采用一些經驗性的啟發(fā)式規(guī)則,對初始的模塊結構圖

進行精化,形成最終的模塊結構圖”.

1）改進軟件結構，提高模塊獨立性.

2）力求模塊規(guī)模適中.

3）力求深度、寬度、扇出和扇入適中.

1.深度表示其控制的層數,寬度是指同一個層次上模塊總數的最大

值,模塊扇出是指一個模塊直接控制（調用）的下級模塊數目.

2.通過對大量軟件系統(tǒng)的研究,發(fā)現設計得很好的軟件結構,通常頂

層模塊扇出比較大，中間層模塊扇出較小，而底層模塊具有較大的扇人，即系統(tǒng)的

模塊結構呈現“葫蘆”形狀.

4）盡力使模塊的作用域在其控制域之內.

1.模塊的控制域是指這個模塊本身以及所有直接或間接從屬于它的

模塊的集合.

2.模塊的作用域是指受該模塊內一個判定所影響的所有模塊的集

&

口?

5）盡力降低模塊接口的復雜度.

6）力求模塊功能可以預測.也就是說,只要輸入的數據相同就產生同樣

的輸出，這個模塊的功能就是可以預測的.但對那種其內部狀態(tài)與時間有關的模

塊,采用同樣的方法就很難預測其功能,因為它的輸出可能要取決于所處的狀態(tài).

由于其內部狀態(tài)對于上級模塊而言是不可見的,所以,這樣的模塊既不易理解又難

以測試和維護.

----詳細設計----

19.詳細設計的目標是將總體設計階段所產生的系統(tǒng)高層結構映射為以這些

術語所表達的低層結構,也是系統(tǒng)的最終結構.

20.程序設計方法學的第一種含義是，以程序設計方法和技術為研究對象的學

科.第二種含義是,針對某一領域或某一領域的一類特定問題,所用的一整套特定

程序設計方法所構成的體系.作為一整套特定程序設計方法所構成的體系（第二種

含義），目前已出現多種程序設計

方法學，例如，結構化程序設計方法學、各種邏輯式程序設計方法學、函數式

程序設計方法學、面向對象程序設計方法學等.

21.詳細設計工具

（1）程序流程圖（從20世紀40年代未到70年代中期,）.程序流程圖

中的箭頭代表的是控制流而不是數據流,這一點同數據流圖中的箭頭是不同的.

它的主要優(yōu)點是對控制流程的描繪很直觀，便于初學者掌握.

程序流程圖的主要缺點如下：

1）不是一種逐步求精的工具,它誘使程序員過早地考慮程序的

控制流程,而不去考慮程序的全局結構.

2）所表達的控制流，往往不受任何約束可隨意轉移,從而會影

響甚至破壞好的系統(tǒng)結構設計.

3）不易表示數據結構.

（2）盒圖（N-S圖）早在20世紀70年代初，Nassi和Shneiderman

出于不允許違背結構化程序設計的考慮提出了盒圖，又稱為N-S圖.

（3）PAD圖（1973）是英文“ProblemanalysisDiagram"的縮寫.

（4）類程序設計語言.類程序設計語言（ProgramDesignLanguage,

PDL）也稱為偽碼,在20世紀70年代至80年代，人們設計了多種PDL,它是一種

用正文形式表示數據結構和處理過程的設計工具.

另外，IP0圖、判定樹和判定表等也可以作為詳細設計工具.

22.概要設計規(guī)約指明高層軟件體系結構,其主要內容如下：

1）系統(tǒng)環(huán)境，包括硬件、軟件接口、人機界面、外部定義的數據庫及其

與設計有關的限定條件等.

2）軟件模塊的結構,包括模塊之間的接口及設計的數據流和主要數據結

構等.

3）模塊描述，包括模塊接口定義、模塊處理邏輯及必要的注釋等.

4）文件結構和全局數據文件的邏輯結構，包括記錄描述、訪問方式以及

交叉引用信息等.

5）測試需求等.

概要設計規(guī)約是面向軟件開發(fā)者的文檔,主要作為項目管理人員、系統(tǒng)

分析人員與設計人員之間交流的媒體.

23.詳細設計規(guī)約是對軟件各成分內部屬性的描述.它是概要設計的細化,即

在概要設計規(guī)約的基礎上，增加以下內容：

①各處理過程的算法.

②算法所涉及的全部數據結構的描述,特別是,對主要數據結構往往包括

與算法實現有關的描述.

詳細設計規(guī)約主要作為軟件設計人員與程序員之間交流的媒體.

第四章面向對象方法-UML

1.在面向對象技術的發(fā)展中，一個重要的里程碑是UML（UnifiedModeling

Language）.

2.從語言學的角度，為了規(guī)約這八大范疇的事物,UML引入了8個術語，即類

與對象、接口、協(xié)作、用況、主動類、構件、節(jié)點和制品,并給出了它們的含義

和表示.UML把它們統(tǒng)稱為類目，作為元信息，以便對客觀世界的一切事物進行模

型化.

3.為了描述事物之間的相互依賴和相互作用，即為了表達各類事物之間的關

系,UML給出了4個術語，即關聯(lián)、泛化、實現和依賴.

4.除了這兩類術語之外，為了控制信息組織的復雜性，UML還引入了用于組

織特定對象結構的包，一個包相當一個可管理的“預制塊”.

5.最后，為了使建造的系統(tǒng)模型容易理解，UML引入了表達注釋的術語一一

注解,用于對模型增加一些輔助性說明.

6.類是一組具有相同屬性、操作、關系和語義的對象的描述.對象是類的一

個實例.

7.類的屬性是類的一個命名特性,該特性是由該類的所有對象所共享、用于

表達對象狀態(tài)的數據.

8.所謂信息隱蔽是指在每個模塊中所包含的信息（包括具有特定語義的數據

和處理過程）不允許其他不需要這些信息的模塊訪問.信息隱蔽是實現模塊低耦合

的一種有效途徑.但是,如果一個模塊中的所有信息都是不可見的，即該模塊是

“絕對”信息隱蔽的,那么這種模塊對系統(tǒng)而言也是毫無意義的.

9.所謂類范圍的屬性是指該屬性被該類所有對象所共享.

10.操作是對一個類中所有對象要做的事情的抽象.

leaf指明該操作是“葉子”操作.

abstract指明該操作是抽象操作.

query指明該操作的運行不會改變系統(tǒng)狀態(tài)，即是完全沒有副作用的純

函數.

sequential指明在該類對象中，一次僅有一個控制流.當出現多個控制

流時，就不能保證該對象的語義和完整性.

guarded指明執(zhí)行該操作的條件，實現操作調用的順序化,即一次只能調

用對象的一個操作，以保證在出現多控制流的情況下,對象具有的語義和完整性.

concurrent指明來自并發(fā)控制流的多個調用可以同時作用于一個對象

的任何一個并發(fā)操作,而所有操作均能以正確的語義并發(fā)進行.并發(fā)操作必須設計

成,在對一個對象同時進行順序的或監(jiān)護的操作情況下仍能正確地執(zhí)行.

static指明該操作沒有關于目標對象的隱式參數,其行為如同傳統(tǒng)的全

局過程.

1L關于類語義的進一步表達：

①詳細敘述類的職責.

②通過類的注解和/或操作的注解，以結構化文本的形式和/或編程語

言,詳述注釋整個類的語義和/或各個方法.

③通過類的注解或操作的注解，以結構化文本形式,詳述注釋各操作的前

置條件和后置條件,甚至注釋整個類的不變式.

④詳述類的狀態(tài)機.

⑤詳述類的內部結構.

⑥類與其他類的協(xié)作.

由此可見,類的語義表達,其詳細程度取決于所采用的描述手段.應用中

到底需要表達到何種程度,這取決于建模的意圖.

?如果是為了與最終用戶和領域專家溝通,那么就可以采用較低的

形式化手段.

?如果是為了支持正向和逆向工程,即需要在模型和代碼之間進行

轉換,那么就應該采用較高的形式化手段.

?如果是為了對模型進行推理,證明其正確性,那么就應該采用很高

的形式化手段.

12.，類的作用主要有3個.

①模型化問題域中的概念(詞匯).

②建立系統(tǒng)的職責分布模型.

③模型化建模中使用的基本類型.

13.接口是操作的一個集合，其中每個操作描述了類、構件或子系統(tǒng)的一個服

務.

14.在系統(tǒng)/產品建模中,接口的主要作用可概括為一句話,即對系統(tǒng)/產品

中的‘‘接縫"予以模型化.

15.協(xié)作是一個交互,涉及交互的三要素:交互各方、交互方式以及交互內容.

16.用況是對一組動作序列的描述,系統(tǒng)執(zhí)行這些動作應產生對特定參與者有

值的、可觀察的結果.

17.制品是系統(tǒng)中包含物理信息(比特)的、可替代的物理部件.

18.關聯(lián)是類目之間的一種結構關系，是對一組具有相同結構、相同鏈

(links)的描述.

19.類是一組具有相同屬性、操作、關系和語義的對象的描述;而關聯(lián)是一組

具有相同結構和語義的鏈的描述.

20.聚合(Aggregation).分類是增強客觀實際問題語義的一種手段.通過

“一個類(類目〉是另一類〈類目)的一部分”這一性質，對關聯(lián)集進行分類，凡

滿足這一性質的關聯(lián),都稱為一個聚合.顯然聚合是關聯(lián)的一種特殊形式,表達的

是一種“整體/部分”關系

聚合是對象之間的一種結構關系,不是類(類目)之間的部分一種結

構關系.

21.組合(Composition).組合又是聚合的一種特殊形式.如果在一個時間

段內，整體類的實例中至少包含一個部分類的實例,并且該整體類的實例負責創(chuàng)建

和消除部分類的實例,特別是如果整體類的實例和部分類的實例具有相同的生存

周期,那么這樣的聚合稱為組合.

22.泛化是一般性類目(稱為超類或父類)和它的較為特殊性類目(稱為子類)

之間的一種關系，有時稱為"is-a-kind-of'關系.

23.為了進一步表達泛化的語義，UML給出了4個約束.

①完整(Complete):表明已經在模型中給出了泛化中的所有子類，盡管

在表達的圖形中有所省略，但也不允許增加新的子類.

②不完整(Incomplete):表明在模型中沒有給出泛化中的所有子類，因

此可以增加新的子類.

③互斥(Disjoint):表明父類的對象最多允許該泛化中的一個子類作

為它的類型.例如，如果父類為Person，有兩個子類Woman和Man，顯然父類的

一個對象,其類型或是子類Man,或是子類Woman

④重疊(Overlapping):表明父類的對象可能具有該泛化中的多個子類

作為它的類型.例如，類“交通工具”的一個對象可能是兩棲工具，既是水上的又

是陸地的.

24.細化是類目之間的語義關系，其中一個類目規(guī)約了保證另一個類目執(zhí)行的

契約.

25.依賴是一種使用關系,用于描述一個類目使用另一類目的信息和服務.

26.按照UML的觀點,客觀世界一切事物之間的關系都可用依賴來規(guī)約，但為

了對各種關系賦予特定的語義，采用分類手段將它們分為4類，如圖4-49所示.

關聯(lián)、泛化和細化都是一類特定的依賴.如此處理，可以保證UML提出的4個術

語能夠表達客觀世界中各種各樣的關系，

即概念體系的完備性.因此,在系統(tǒng)建模中，為了模型化其中所遇到的關系,應

首先使用關聯(lián)、泛化和細化這3個術語,只有在不能使用它們時,再使用依賴.

27.UML的圖形化工具分為兩類，一類是結構圖，用于表達系統(tǒng)或系統(tǒng)成分的

靜態(tài)結構模型,給出系統(tǒng)或系統(tǒng)成分的一些說明性信息;一類是行為圖,用于表達

系統(tǒng)或系統(tǒng)成分的動態(tài)結構模型,給出系統(tǒng)或系統(tǒng)成分的一些行為信息,例如行為

的功能性信息,行為的交互信息以及行為的生存狀態(tài)信息.

28.類圖是構件圖和部署圖的基礎.

29.創(chuàng)建一個系統(tǒng)的類圖,依賴于所使用的方法學，但一般來說要涉及以下4

方面的工作.

（1）模型化待建系統(tǒng)中的概念（詞匯），形成類圖中的基本元素.

（2）模型化待建系統(tǒng)中的各種關系,形成該系統(tǒng)的初始類圖.

（3）模型化系統(tǒng)中的協(xié)作，給出該系統(tǒng)的最終類圖.

（4）模型化邏輯數據庫模式.

30.實踐經驗告訴人們,認識行為的一個有效途徑是要從多個視角對其進行抽

象.一般來說，一是從（行為）功能的視角，二是從（行為）交互的視角,三是從（行

為）生存周期的視角.為了支持從以上3個視角來認識系統(tǒng)（或系統(tǒng)成分）行為,對

行為進行抽象，

UML提供了7種圖形工具，其中USECASE圖支持系統(tǒng)功能的建模，交互圖支

持系統(tǒng)交互的建模,狀態(tài)圖支持系統(tǒng)生存周期的建模.

31.在一個用況圖中，用況之間可以具有3種關系，即泛化、擴展和包含.注

意箭頭方向.

32.一個用況圖通常包含6個模型元素，它們是主題（Subject）、用況

（Usecases）、參與者（Actor）、關聯(lián)、泛化、依賴.

33.使用用況圖可以為系統(tǒng)建模,描述軟件系統(tǒng)行為的功能結構;也可以對業(yè)

務建模,描述企業(yè)或組織的業(yè)務過程結構.業(yè)務模型和系統(tǒng)模型之間具有“整體/

部分”關系，即業(yè)務模型是“整體”，而系統(tǒng)模型是業(yè)務模型的一個組成部分.不

論是對系統(tǒng)建模還是對業(yè)務建模，都涉及兩方面的模型化工作，一是系統(tǒng)/業(yè)務

語境的模型化，二是系統(tǒng)/業(yè)務需求的模型化.

1）關于對系統(tǒng)/業(yè)務語境的模型化.在對系統(tǒng)語境的模型化中,應研究以

下4個問題.

①系統(tǒng)邊界的確定，即確定哪些行為是系統(tǒng)的一部分,哪些行為是由

外部實體執(zhí)行的，同時定義主題.

②參與者與用況的交互,即在用況圖中表明參與者與系統(tǒng)用況之間

的關聯(lián).

③參與者的語義表達,在需要加深理解的地方,為每個參與者提供一

個衍型.

④參與者的結構化處理,即將一些相似的參與者組織為一肋特殊結

構.

2)關于系統(tǒng)/業(yè)務需求的模型化.

①確定系統(tǒng)/業(yè)務的基本用況,即考慮每個參與者所期望或需要的系

統(tǒng)行為,并把這些行為規(guī)約為相應的用況,如圖4-63所示.

②用況的結構化處理,即分解行為,形成必要的泛化結構和擴展、包

含結構,并在用況圖中給出各種已確定的關系.

③用況的語義表達,即通過注解和約束來修飾用況,特別應給出用況

的一些非功能需求.

第四章面向對象方法-RUP

1.RUP是一種軟件開發(fā)過程框架,基于面向對象符號體系給出了有關軟件開

發(fā)過程組織及實施的指導.該框架體現了3個突出特征，即以用況驅動、體系結

構為中心以及迭代、增量式開發(fā).

2.RUP和UML是一對“姐妹”，它們構成了一種特定的軟件開發(fā)方法學.其

中，UML作為一種可視化建模語言，給出了表達事物和事物之間關系的基本術語

給出了多種模型的表達工具;而RUP利用這些術語定義了需求獲取層、系統(tǒng)分析

層、設計層、實現層，并給出了實現各層模型之間映射的基本活動以及相關的指

導.

3.RUP的突出特點是，它是一種以用況(UseCase)為驅動的、以體系結構

為中心的迭代、增量式開發(fā).

4.在RUP中，規(guī)定了4個開發(fā)階段:初初始階段(theInception

Phase)、精化階段(theElaborationPhase)、構造階段(由e

ConstructionPhase)和移交階段(theTransitionPhase),

5.系統(tǒng)體系結構是對系統(tǒng)語義的概括表述，對所有項目有關人員來說都是能

夠理解的，因此便于用戶和其他關注者對系統(tǒng)達成共識，以便建立和控制系統(tǒng)的開

發(fā)、復用和演化.

6.迭代、增量式開發(fā)是指通過開發(fā)活動的迭代,不斷地產生相應的增量.

7.兩次相鄰迭代所得到的發(fā)布版本之差,稱為一個增量,因此增量是系統(tǒng)中一

個較小的、可管理的部分(一個或幾個構造塊兒).

8.次里程碑是進行后續(xù)迭代的決策點.

9.初始階段的基本目標是:獲得與特定用況和平臺無關的系統(tǒng)體系結構輪廓,

以此建立產品功能范圍;編制初始的業(yè)務實例，從業(yè)務角度指出該項目的價值，減

少項目主要的錯誤風險.

精化階段的基本目標是：通過捕獲并描述系統(tǒng)的大部分需求(一些關鍵用

況)，建立系統(tǒng)體系結構基線的第一個版本，主要包括用況模型和分析模型,減少次

要的錯誤風險;到該階段末,就能夠估算成本、進度,并能詳細地規(guī)劃構造階段.

構造階段的基本目標是:通過演化,形成最終的系統(tǒng)體系結構基線(包括系

統(tǒng)的各種模型和各模型視角下的體系結構描述)，開發(fā)完整的系統(tǒng),確保產品可以

開始向客戶交付，即具有初始操作能力.

移交階段的基本目標是：確保有一個實在的產品發(fā)布給用戶群.期間,培訓

用戶如何使用該軟件.

10.在RUP的每次迭代中都要經歷一個核心工作流,即需求獲取、分析、設

計、實現和測試.

11.RUP采用UseCase技術來獲取需求.其目標是:使用UML中的用況、參

與者以及依賴等術語來抽象客觀實際問題，形成系統(tǒng)的需求獲取模型-----種特

定的系統(tǒng)/產品模型,并產生該模型視角下的體系結構描述.

1.列出候選需求

2.理解系統(tǒng)語境

為了理解系統(tǒng)語境,往往需要創(chuàng)建領域模型或業(yè)務模型.在RUP中，

領域模型一般是以類圖予以表達的，用于捕獲系統(tǒng)語境中的一些重要領域對象類,

其中領域對象表達系統(tǒng)工作環(huán)境中存在的事物或發(fā)生的事件.一般來說,領域類以

3種形態(tài)出現.

?業(yè)務對象:表示那些由業(yè)務操縱(Manipulate)的事物

('Thing)，如訂單、賬目和合同等.

?實在對象(Real-worldObjects)和概念;如教室、運動場

地等.

,事件(Events):如上課鈴響九討論開始等.

在RUP中,為了捕獲業(yè)務處理和其中的業(yè)務對象,通過以下兩個層

次來抽象一個業(yè)務：

(1)業(yè)務用況模型.業(yè)務用況模型是以用況圖予以表達的，如圖

5-7所示.其中包含一些“業(yè)務用況”和一些“業(yè)務參與者”，每一個業(yè)務用況對

應一個業(yè)務處理,每一個業(yè)務參與者對應客戶.

(2)業(yè)務對象模型.為了精化業(yè)務用況模型中的每一個業(yè)務用

況，RUP引入了3個術語，用于表達參與業(yè)務的業(yè)務對象〉：工作人員

(Workers)、業(yè)務實體(BusinessEntities)和工作單元(WorkUnits).

其中，工作人員用于表達參與業(yè)務處理的各類人員;業(yè)務實體用

于表達在一個業(yè)務用況中所使用的某一事物,如一張發(fā)票;工作單元是對最終用戶

而言可形成一個認知整體的實體的集合.業(yè)務實體和工作單元是領域類(如訂單、

貨物項、發(fā)票等)的對象.

RUP通過它們以及它們之間的關系來描述業(yè)務用況模型中的每

一個業(yè)務用況,其結果稱為業(yè)務對象模型.業(yè)務對象模型可通過交互圖和活動圖予

以表達

3.捕獲系統(tǒng)功能需求

用況模型是系統(tǒng)的一種概念模型,是對系統(tǒng)功能的抽象,包括系統(tǒng)參

與者、系統(tǒng)用況以及它們之間的關系.

為了創(chuàng)建系統(tǒng)的用況模型應進行以下活動.

(1)活動1：發(fā)現并描述參與者(Actor).

(2)活動2:發(fā)現并描述用況.用況模型(概述］

(3)活動3:確定用況的優(yōu)先級(Priority).

(4)活動4:精化用況.

(5)活動5:構造用戶界面原型.

(6)活動6:用況模型的結構化.

1)抽取用況描述中那些一般性的、共享的功能，并使用泛

化關系標識和描述那些共享功能.

2)抽取用況描述中附加的或可選的功能，可以使用擴展關

系對它們進行標識和描述.

3)標識用況之間的包含關系.

12.RUP的需求分析目標是:在系統(tǒng)用況模型的基礎上,創(chuàng)建系統(tǒng)分析模型以

及在該分析模型視角下的體系結構描述.

13.為了支持系統(tǒng)分析，RUP引入了以下術語:分析類、分析包和用況細化，

并通過這些術語以及描述它們之間特定關系的術語,定義了一個抽象層.

14.需求分析基本術語

(1)分析類.分析類(Analys總C~ass)是類的一種衍型，很少有操作和

特征標記,而用責任來定義其行為,并且其屬性和關系也是概念性的.分析類分為

邊界類、實體類和控制類3種.

1)邊界類｛BoundaryClasses).邊界類用于規(guī)約系統(tǒng)與其參與者

之間的交互,該交互一般涉及向用戶/外部系統(tǒng)發(fā)出請求和從他們那里接受信息.

2)實體類｛EntityClasses).實體類用于規(guī)約那些需要長期駐

留在系統(tǒng)中的模型化對象以及與行為相關的某些現象，如人的信息以及實際的一

個事件.

3)控制類(ControlClasses).控制類用于規(guī)約基本動作和控制

流的處理與協(xié)調,涉及向其他對象(如邊界類對象、實體類對象)委派工作.

(2)用況細化.用況細化是一個協(xié)作.針對一個用況，其行為可用多個分

析類之間的相互作用來細化，并記為用況細化［分析］.

(3)分析包｛AnalysisPackage).分析包是一種控制信息組織復雜性

的機制,提供了分析制品的一種組織手段,形成了一些可管理的部分.

15.分析的主要活動

(1)活動1:體系結構分析(ArchitecturalAnalysis).該活動的目

標是:通過標識分析包和分析類,建立分析模型和體系結構“骨架飛并標識有關分

析包和分析類的特定需求.

1)任務1：標識分析包.該任務的基本輸入是系統(tǒng)的用況模型.首

先,基于功能需求和問題域,即考慮需要的應用和業(yè)務，對分析工作進行劃分,從而

可形成一些分析包.

2)任務2:處理分析包之間的共性.在已標識了系統(tǒng)的一些分析包

的基礎上,就要處理分析包之間的共性.

3)任務3:標識服務包.在包的層次結構中，除了考慮以上對“共

性”的依賴之外時常還要考慮對“服務”的依賴,即應用層的包依賴下層提供的

服務包.

4)任務4:定義分析包的依賴.該任務的目標是:發(fā)現相對獨立的

包,實現包的高內聚和低藕合.為此,通常使用特定應用包和共用包把分析模型分

為兩個層面,從而可清晰地區(qū)分特殊性功能和一般性功能.

5)任務5