（專升本）自考《軟件工程》備考知識點(diǎn)

《軟件工程》備考知識點(diǎn)匯總

第一章緒論

1.軟件工程這一術(shù)語首次出現(xiàn)在1968年的NATO會議上.

2.軟件危機(jī):隨著計(jì)算機(jī)的廣泛應(yīng)用，軟件生產(chǎn)率、軟件質(zhì)量遠(yuǎn)遠(yuǎn)滿足不了社

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

危機(jī)”.

3.軟件工程:軟件工程是應(yīng)用計(jì)算機(jī)科學(xué)理論和技術(shù)以及工程管理原則和方

法,按預(yù)算和進(jìn)度實(shí)現(xiàn)滿足用戶要求的軟件產(chǎn)品的工程,或以此為研究對象的學(xué)

科.

4.軟件工程概念的提出，其目的是倡導(dǎo)以工程的原理、原則和方法進(jìn)行軟件

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

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

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

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

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

調(diào)試工具、測試工具等.在這一時(shí)期，開始出現(xiàn)各種管理方法（例如，費(fèi)用估算、文

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

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

程》等一系列軟件工程標(biāo)準(zhǔn);大力開展了計(jì)算機(jī)輔助軟件工程（CASE）的研究與實(shí)

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

重點(diǎn)科技攻關(guān)項(xiàng)目〉，各類CASE產(chǎn)品相繼問世.與此同時(shí),在工程技術(shù)方

面，出現(xiàn)了最引人注目的面向?qū)ο笳Z言，例如Smalltalk、c++、Eiffel等;提出

了面向?qū)ο筌浖_發(fā)方法;在工程管理方面,開展了一系列過程改進(jìn)項(xiàng)目，

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

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

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

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

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

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

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

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

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

統(tǒng)建模,是指運(yùn)用所掌握的知識,通過抽象,給出該系統(tǒng)的一個(gè)結(jié)構(gòu)——系統(tǒng)模型.

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

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

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

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

項(xiàng)）功能上的能力、性能參數(shù)或其他性質(zhì).

2.對于單一一個(gè)需求,必須具有如下5個(gè)基本性質(zhì)：

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

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

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

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

段.

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

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

分為性能需求、外部接口需求、設(shè)計(jì)約束和質(zhì)量屬性需求.

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

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

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

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

據(jù)以及用戶如何控制該用戶接口.

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

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

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

據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學(xué)軟件包)進(jìn)行的交互.

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

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

(TCP/IP、MicrosoftWindows

NT,Novell)，那么有關(guān)類型的信息就應(yīng)包含在該需求描述中.

5)內(nèi)存約束:描述易失性存儲和永久性存儲的特性和限制,特別應(yīng)描述

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

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

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

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

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

級功能方面的需求.

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

何調(diào)整一個(gè)地點(diǎn)，以適應(yīng)新的物理環(huán)境.

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

圍.

7.質(zhì)量屬性(QualityAttribute)規(guī)約了軟件產(chǎn)品所具有的一個(gè)性質(zhì)(包括

功能和其他需求)必須達(dá)到其質(zhì)量方面一個(gè)所期望的水平.

8.初始發(fā)現(xiàn)需求的常用技術(shù)包括以下幾個(gè).

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

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

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

切實(shí)可行的、比較有吸引力的方法.

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

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

存在的風(fēng)險(xiǎn):無法驗(yàn)證發(fā)現(xiàn)的需求是否滿足用戶的要求,無法驗(yàn)證

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

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

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

的系統(tǒng).

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

流.

成功條件:依賴于

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

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

存在的風(fēng)險(xiǎn):在交談期間所獲得的需求可能不斷增長,或是以前沒

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

的體現(xiàn)，以至于很難控制,可能導(dǎo)致超出項(xiàng)目成本和進(jìn)度的限制.

應(yīng)對措施:項(xiàng)目管理人員和客戶管理人員應(yīng)該定期地對交談過程的

結(jié)果進(jìn)行復(fù)審.其中具有挑戰(zhàn)的問題是,判斷以下內(nèi)容：

?什么時(shí)候界定這一增長.

?什么時(shí)候?qū)⑦@一增長通知客戶.

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

通過觀察他們?nèi)绾尾僮髋c所期望的新系統(tǒng)有關(guān)的現(xiàn)有系統(tǒng)，了解系統(tǒng)運(yùn)行的環(huán)境,

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

互.

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

一手材料”一般總能比較好地“符合現(xiàn)實(shí)”.

適用情況:用戶允許需求人員進(jìn)入工作現(xiàn)場,并可進(jìn)行觀察,可與有

關(guān)人員就有關(guān)問題進(jìn)行交流.

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

存在的風(fēng)險(xiǎn)：

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

們的正常業(yè)務(wù).

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

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

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

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

工程項(xiàng)目經(jīng)理,主持這一會議.當(dāng)然,還可以采用其他形式,這依賴于其應(yīng)用領(lǐng)域和

主持人的能力.主持人的作用主要是掌握會議的進(jìn)程.

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

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

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

資源.

成功條件:會議組織得當(dāng),包括責(zé)權(quán)分明，參與會議的人員具有良好

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

的問題，并與客戶達(dá)成共識.

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

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

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

和性能目標(biāo)的陳述、系統(tǒng)規(guī)約接口標(biāo)準(zhǔn)、硬件設(shè)計(jì)文檔等)，并提取相關(guān)的信息.

適用情況:提煉方法是針對已經(jīng)有了部分需求文檔的情況.依據(jù)產(chǎn)品

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

也可能只有少數(shù)文檔需要復(fù)審.

成功條件：已存在項(xiàng)目背景文檔以及一些緊密相關(guān)的需求文檔,并且

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

策等.

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

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

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

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

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

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

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

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

單一需求.

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

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

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

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

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

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

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

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

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

2）對于項(xiàng)目的其余大多數(shù)工作,需求規(guī)約是一個(gè)管理控制點(diǎn).

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

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

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

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

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

戶之間一份事實(shí)上的技術(shù)合同書，即關(guān)注產(chǎn)品需求,回答“交付給客戶的產(chǎn)品/系

統(tǒng)是什么”；

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

解,應(yīng)記錄在工作陳述中或其他某一項(xiàng)目文檔中，即關(guān)注項(xiàng)目工作與管理,回答

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

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

第三章結(jié)構(gòu)化方法

為了實(shí)現(xiàn)以上的分析目標(biāo)，作為支持需求分析的結(jié)構(gòu)化分析方法，一要給出

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

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

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

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

----結(jié)構(gòu)化需求分析----

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

（1）問題空間理解.

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

（3）需求的變化性.

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

信息.

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

息.

4.數(shù)據(jù)存儲也是一類術(shù)語，用于表達(dá)在分析中所使用的、表達(dá)“結(jié)構(gòu)化客

體”的信息.

5.建模過程

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

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

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

礎(chǔ)上,按功能分解的設(shè)計(jì)思想,進(jìn)行“自頂向下,逐步求精”，即對加工進(jìn)行分解，

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

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

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

所有數(shù)據(jù)流和數(shù)據(jù)存儲的數(shù)據(jù)結(jié)構(gòu)，直到給出構(gòu)成以上數(shù)據(jù)的各數(shù)據(jù)項(xiàng)的基本數(shù)

據(jù)類型.

所有客體均可用以下3種基本結(jié)構(gòu)表示，這3種結(jié)構(gòu)分別為

順序結(jié)構(gòu)(指數(shù)據(jù)A是由數(shù)據(jù)B和數(shù)據(jù)C順序構(gòu)成的)：學(xué)生成績=

姓名+性別+學(xué)號+科目+成績

選擇結(jié)構(gòu)(指由數(shù)據(jù)A或是由數(shù)據(jù)B.或是由數(shù)據(jù)C.定義的)：性別=

男I女

重復(fù)結(jié)構(gòu)(是指數(shù)據(jù)A是由多個(gè)重復(fù)出現(xiàn)的數(shù)據(jù)B構(gòu)成的)：學(xué)生成

績表=(學(xué)生成績)

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

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

加工的輸入數(shù)據(jù)和輸出數(shù)據(jù)之間的關(guān)系，即從外部來“視察”一個(gè)加工的邏輯.

3種表達(dá)工具：

(1)結(jié)構(gòu)化自然語言.

(2)判定表.

(3)判定樹.

6.抽象和分解是結(jié)構(gòu)化分析方法采用的兩個(gè)基本手段.

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

=======結(jié)構(gòu)化需求設(shè)計(jì)=======

----總體設(shè)計(jì)----

8.結(jié)構(gòu)化設(shè)計(jì)的主要任務(wù)是在需求分析的基礎(chǔ)上,定義滿足需求所需要的結(jié)

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

9.結(jié)構(gòu)化方法在總體設(shè)計(jì)中引入了兩個(gè)基本概念:一是模塊,即指軟件中具有

特定標(biāo)識的獨(dú)立成分;二是模塊調(diào)用，即指模塊之間的一種使用關(guān)系.

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

系結(jié)構(gòu)中.表達(dá)這一軟件體系結(jié)構(gòu)的工具很多，主要有以下幾種.

(1)Yourdon提出的模塊結(jié)構(gòu)圖.

模塊結(jié)構(gòu)圖是系統(tǒng)的一個(gè)高層“藍(lán)圖”，允許設(shè)計(jì)人員在較高的層

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

是空心圓的箭頭線標(biāo)明傳遞的是數(shù)據(jù)信息，尾部是實(shí)心圓的箭頭線

標(biāo)明傳遞的是控制信息.

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

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

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

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

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

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

用，這是結(jié)構(gòu)化設(shè)計(jì)方法所要回答的問題.

12.該方法在分類DFD的基礎(chǔ)上，基于自頂向下、功能分解的設(shè)計(jì)原則，定

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

DFD圖首先轉(zhuǎn)化為初始的模塊結(jié)構(gòu)圖,再基于“高內(nèi)聚低搞合”這一軟件設(shè)計(jì)原

理,通過模塊化,將初始的模塊結(jié)構(gòu)圖轉(zhuǎn)化為最終的、可供詳細(xì)設(shè)計(jì)使用的模

塊結(jié)構(gòu)圖(MSD).

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

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

14.系統(tǒng)/產(chǎn)品的模塊結(jié)構(gòu)圖以及相關(guān)的全局?jǐn)?shù)據(jù)結(jié)構(gòu)和每一模塊的接口，是

軟件設(shè)計(jì)中的一個(gè)重要制品，是系統(tǒng)/產(chǎn)品的高層設(shè)計(jì)“藍(lán)圖”.

15.總體設(shè)計(jì)步驟

(1)變換型數(shù)據(jù)流圖.

(2)事務(wù)型數(shù)據(jù)流圖.

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

則上所有的數(shù)據(jù)流圖都可以歸為變換型.

17.總體設(shè)計(jì)分為3個(gè)階段.

第一階段為初始設(shè)計(jì),在對給定的數(shù)據(jù)流圖進(jìn)行復(fù)審和精化的基礎(chǔ)上,將

其轉(zhuǎn)換為初始的模塊結(jié)構(gòu)圖.

(1)變換設(shè)計(jì).

第1步:設(shè)計(jì)準(zhǔn)備一復(fù)審并精化系統(tǒng)模型.

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

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

第3步:第一級分解一一系統(tǒng)模塊結(jié)構(gòu)圖頂層和第一層的設(shè)計(jì)

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

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

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

應(yīng)的軟件結(jié)構(gòu)有一個(gè)主模塊以及由它控制的3個(gè)部分組成.

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

(2)事務(wù)設(shè)計(jì).

第1步:設(shè)計(jì)準(zhǔn)備一一復(fù)審并精化系統(tǒng)模型.

第2步:確定事務(wù)處理中心.

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

設(shè)計(jì).

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

第二階段為精化設(shè)計(jì)，依據(jù)模塊“高內(nèi)聚低藕合”的原則，精化初始的模

塊結(jié)構(gòu)圖,并設(shè)計(jì)其中的全局?jǐn)?shù)據(jù)結(jié)構(gòu)和每一模塊的接口.

第三階段為復(fù)審階段對前兩個(gè)階段所得到的高層軟件結(jié)構(gòu)進(jìn)行復(fù)審，必

要時(shí)還可能需要對該軟件結(jié)構(gòu)做一些精化工作,這對軟件的一些性質(zhì),特別是對軟

件質(zhì)量的提高將產(chǎn)生非常大的影響.

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

構(gòu).在軟件總體設(shè)計(jì)中,通常以變換設(shè)計(jì)為主,事務(wù)設(shè)計(jì)為輔進(jìn)行結(jié)構(gòu)設(shè)計(jì).即首先

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

然后根據(jù)各部分?jǐn)?shù)據(jù)流圖的結(jié)構(gòu)特點(diǎn)，適當(dāng)?shù)乩米儞Q設(shè)

計(jì)和事務(wù)設(shè)計(jì)進(jìn)行細(xì)化,得到初始的模塊結(jié)構(gòu)圖,再按照“高內(nèi)聚低藕

合”的原則,對初始的模塊結(jié)構(gòu)圖進(jìn)行精化,得到最終的模塊結(jié)構(gòu)圖.

19.模塊是執(zhí)行一個(gè)特殊任務(wù)的一個(gè)過程以及相關(guān)的數(shù)據(jù)結(jié)構(gòu).模塊通常由兩

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

接口不但可用于刻畫各個(gè)模塊之間的連接，以體現(xiàn)其功能,而且還對其他模塊的設(shè)

計(jì)者和使用者提供了一定的可見性.模塊的另一部分是模塊體,是接口的實(shí)現(xiàn).

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

①內(nèi)容耦合：當(dāng)一個(gè)模塊直接修改或操作另一個(gè)模塊的數(shù)據(jù)，或一個(gè)模塊

不通過正常入口而轉(zhuǎn)入到另一個(gè)模塊時(shí),這樣的耦合被稱為內(nèi)容耦合.內(nèi)容精合是

最高程度的耦合,應(yīng)該盡量避免使用.

②公共耦合:兩個(gè)或兩個(gè)以上的模塊共同引用一個(gè)全局?jǐn)?shù)據(jù)項(xiàng)，這種耦合

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

賦了一個(gè)特定的值是十分困難的.

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

號的模塊根據(jù)信號值進(jìn)行適當(dāng)?shù)膭幼?這種精合被稱為控制搞合.在實(shí)際設(shè)計(jì)中，

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

耦合.

④標(biāo)記耦合:若一個(gè)模塊A通過接口向兩個(gè)模塊B和C傳遞一個(gè)公共

參數(shù)，那么稱模塊B和C之間存在一個(gè)標(biāo)記耦合.

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

是最低的一種耦合形式,系統(tǒng)中一般都存在這種類型的藕合,因?yàn)闉榱送瓿梢恍┯?/p>

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

響軟件復(fù)雜程度和設(shè)計(jì)質(zhì)量的一個(gè)重要因素,在設(shè)計(jì)上我們應(yīng)采取以下原則：

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

共搞合的范圍，盡量避免使用內(nèi)容精合.

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

①偶然內(nèi)聚:如果一個(gè)模塊的各成分之間基本不存在任何關(guān)系，則稱為偶

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

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

時(shí)就出現(xiàn)了偶然內(nèi)聚.

因?yàn)檫@樣的模塊一般沒有確定的語義或很難了解它的語義，那么當(dāng)在一個(gè)應(yīng)

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

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

塊高得多.

②邏輯內(nèi)聚:幾個(gè)邏輯上相關(guān)的功能被放在同一模塊中，則稱為邏輯內(nèi)

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

而不管這些輸入從哪兒來、做什么用，因?yàn)檫@個(gè)模塊的各成分都執(zhí)行輸入,所以，

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

但邏輯內(nèi)聚的模塊各成分在功能上并無關(guān)系，即使局部功能的修改有時(shí)也會

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

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

始化系統(tǒng)或一組變量），但這些功能只是因?yàn)闀r(shí)間因素關(guān)聯(lián)在一起則稱為時(shí)間內(nèi)

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

④過程內(nèi)聚:如果一個(gè)模塊內(nèi)部的處理成分是相關(guān)的,而且這些處理必須

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

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

⑤通信內(nèi)聚:如果一個(gè)模塊的所有成分都操作同一數(shù)據(jù)集或生成同一數(shù)

據(jù)集,則稱為通信內(nèi)聚,如圖3-43所示.在實(shí)際設(shè)計(jì)中這樣的處理有時(shí)是很自然

的，而且也顯得很方便，但是出現(xiàn)的通信內(nèi)聚經(jīng)常破壞設(shè)計(jì)的模塊化和功能獨(dú)立

性.

⑥順序內(nèi)聚:如果一個(gè)模塊的各個(gè)成分和同一個(gè)功能密切相關(guān),而且一個(gè)

成分的輸出作為另一個(gè)成分的輸入,則稱為順序內(nèi)聚.

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

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

內(nèi)聚和耦合是密切相關(guān)的，同其他模塊存在高耦合的模塊常意味著是低

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

設(shè)計(jì)時(shí)，應(yīng)力爭做到高內(nèi)聚、低耦合.

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

“基于高內(nèi)聚低藕合的原理,采用一些經(jīng)驗(yàn)性的啟發(fā)式規(guī)則,對初始的模塊結(jié)構(gòu)圖

進(jìn)行精化,形成最終的模塊結(jié)構(gòu)圖”.

1）改進(jìn)軟件結(jié)構(gòu)，提高模塊獨(dú)立性.

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

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

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

值,模塊扇出是指一個(gè)模塊直接控制（調(diào)用）的下級模塊數(shù)目.

2.通過對大量軟件系統(tǒng)的研究,發(fā)現(xiàn)設(shè)計(jì)得很好的軟件結(jié)構(gòu),通常頂

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

模塊結(jié)構(gòu)呈現(xiàn)“葫蘆”形狀.

4）盡力使模塊的作用域在其控制域之內(nèi).

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

模塊的集合.

2.模塊的作用域是指受該模塊內(nèi)一個(gè)判定所影響的所有模塊的集

&

口?

5）盡力降低模塊接口的復(fù)雜度.

6）力求模塊功能可以預(yù)測.也就是說,只要輸入的數(shù)據(jù)相同就產(chǎn)生同樣

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

塊,采用同樣的方法就很難預(yù)測其功能,因?yàn)樗妮敵隹赡芤Q于所處的狀態(tài).

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

以測試和維護(hù).

----詳細(xì)設(shè)計(jì)----

19.詳細(xì)設(shè)計(jì)的目標(biāo)是將總體設(shè)計(jì)階段所產(chǎn)生的系統(tǒng)高層結(jié)構(gòu)映射為以這些

術(shù)語所表達(dá)的低層結(jié)構(gòu),也是系統(tǒng)的最終結(jié)構(gòu).

20.程序設(shè)計(jì)方法學(xué)的第一種含義是，以程序設(shè)計(jì)方法和技術(shù)為研究對象的學(xué)

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

程序設(shè)計(jì)方法所構(gòu)成的體系.作為一整套特定程序設(shè)計(jì)方法所構(gòu)成的體系（第二種

含義），目前已出現(xiàn)多種程序設(shè)計(jì)

方法學(xué)，例如，結(jié)構(gòu)化程序設(shè)計(jì)方法學(xué)、各種邏輯式程序設(shè)計(jì)方法學(xué)、函數(shù)式

程序設(shè)計(jì)方法學(xué)、面向?qū)ο蟪绦蛟O(shè)計(jì)方法學(xué)等.

21.詳細(xì)設(shè)計(jì)工具

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

中的箭頭代表的是控制流而不是數(shù)據(jù)流,這一點(diǎn)同數(shù)據(jù)流圖中的箭頭是不同的.

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

程序流程圖的主要缺點(diǎn)如下：

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

控制流程,而不去考慮程序的全局結(jié)構(gòu).

2）所表達(dá)的控制流，往往不受任何約束可隨意轉(zhuǎn)移,從而會影

響甚至破壞好的系統(tǒng)結(jié)構(gòu)設(shè)計(jì).

3）不易表示數(shù)據(jù)結(jié)構(gòu).

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

出于不允許違背結(jié)構(gòu)化程序設(shè)計(jì)的考慮提出了盒圖，又稱為N-S圖.

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

（4）類程序設(shè)計(jì)語言.類程序設(shè)計(jì)語言（ProgramDesignLanguage,

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

用正文形式表示數(shù)據(jù)結(jié)構(gòu)和處理過程的設(shè)計(jì)工具.

另外，IP0圖、判定樹和判定表等也可以作為詳細(xì)設(shè)計(jì)工具.

22.概要設(shè)計(jì)規(guī)約指明高層軟件體系結(jié)構(gòu),其主要內(nèi)容如下：

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

與設(shè)計(jì)有關(guān)的限定條件等.

2）軟件模塊的結(jié)構(gòu),包括模塊之間的接口及設(shè)計(jì)的數(shù)據(jù)流和主要數(shù)據(jù)結(jié)

構(gòu)等.

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

4）文件結(jié)構(gòu)和全局?jǐn)?shù)據(jù)文件的邏輯結(jié)構(gòu)，包括記錄描述、訪問方式以及

交叉引用信息等.

5）測試需求等.

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

分析人員與設(shè)計(jì)人員之間交流的媒體.

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

在概要設(shè)計(jì)規(guī)約的基礎(chǔ)上，增加以下內(nèi)容：

①各處理過程的算法.

②算法所涉及的全部數(shù)據(jù)結(jié)構(gòu)的描述,特別是,對主要數(shù)據(jù)結(jié)構(gòu)往往包括

與算法實(shí)現(xiàn)有關(guān)的描述.

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

第四章面向?qū)ο蠓椒?UML

1.在面向?qū)ο蠹夹g(shù)的發(fā)展中，一個(gè)重要的里程碑是UML（UnifiedModeling

Language）.

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

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

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

型化.

3.為了描述事物之間的相互依賴和相互作用，即為了表達(dá)各類事物之間的關(guān)

系,UML給出了4個(gè)術(shù)語，即關(guān)聯(lián)、泛化、實(shí)現(xiàn)和依賴.

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

織特定對象結(jié)構(gòu)的包，一個(gè)包相當(dāng)一個(gè)可管理的“預(yù)制塊”.

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

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

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

個(gè)實(shí)例.

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

表達(dá)對象狀態(tài)的數(shù)據(jù).

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

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

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

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

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

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

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

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

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

函數(shù).

sequential指明在該類對象中，一次僅有一個(gè)控制流.當(dāng)出現(xiàn)多個(gè)控制

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

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

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

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

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

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

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

局過程.

1L關(guān)于類語義的進(jìn)一步表達(dá)：

①詳細(xì)敘述類的職責(zé).

②通過類的注解和/或操作的注解，以結(jié)構(gòu)化文本的形式和/或編程語

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

③通過類的注解或操作的注解，以結(jié)構(gòu)化文本形式,詳述注釋各操作的前

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

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

⑤詳述類的內(nèi)部結(jié)構(gòu).

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

由此可見,類的語義表達(dá),其詳細(xì)程度取決于所采用的描述手段.應(yīng)用中

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

?如果是為了與最終用戶和領(lǐng)域?qū)＜覝贤?那么就可以采用較低的

形式化手段.

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

轉(zhuǎn)換,那么就應(yīng)該采用較高的形式化手段.

?如果是為了對模型進(jìn)行推理,證明其正確性,那么就應(yīng)該采用很高

的形式化手段.

12.，類的作用主要有3個(gè).

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

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

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

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

務(wù).

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

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

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

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

值的、可觀察的結(jié)果.

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

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

(links)的描述.

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

具有相同結(jié)構(gòu)和語義的鏈的描述.

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

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

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

是一種“整體/部分”關(guān)系

聚合是對象之間的一種結(jié)構(gòu)關(guān)系,不是類(類目)之間的部分一種結(jié)

構(gòu)關(guān)系.

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

段內(nèi)，整體類的實(shí)例中至少包含一個(gè)部分類的實(shí)例,并且該整體類的實(shí)例負(fù)責(zé)創(chuàng)建

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

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

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

之間的一種關(guān)系，有時(shí)稱為"is-a-kind-of'關(guān)系.

23.為了進(jìn)一步表達(dá)泛化的語義，UML給出了4個(gè)約束.

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

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

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

此可以增加新的子類.

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

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

一個(gè)對象,其類型或是子類Man,或是子類Woman

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

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

是陸地的.

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

契約.

25.依賴是一種使用關(guān)系,用于描述一個(gè)類目使用另一類目的信息和服務(wù).

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

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

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

語能夠表達(dá)客觀世界中各種各樣的關(guān)系，

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

首先使用關(guān)聯(lián)、泛化和細(xì)化這3個(gè)術(shù)語,只有在不能使用它們時(shí),再使用依賴.

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

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

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

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

28.類圖是構(gòu)件圖和部署圖的基礎(chǔ).

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

方面的工作.

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

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

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

（4）模型化邏輯數(shù)據(jù)庫模式.

30.實(shí)踐經(jīng)驗(yàn)告訴人們,認(rèn)識行為的一個(gè)有效途徑是要從多個(gè)視角對其進(jìn)行抽

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

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

行為進(jìn)行抽象，

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

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

31.在一個(gè)用況圖中，用況之間可以具有3種關(guān)系，即泛化、擴(kuò)展和包含.注

意箭頭方向.

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

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

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

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

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

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

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

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

下4個(gè)問題.

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

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

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

的關(guān)聯(lián).

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

個(gè)衍型.

④參與者的結(jié)構(gòu)化處理,即將一些相似的參與者組織為一肋特殊結(jié)

構(gòu).

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

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

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

②用況的結(jié)構(gòu)化處理,即分解行為,形成必要的泛化結(jié)構(gòu)和擴(kuò)展、包

含結(jié)構(gòu),并在用況圖中給出各種已確定的關(guān)系.

③用況的語義表達(dá),即通過注解和約束來修飾用況,特別應(yīng)給出用況

的一些非功能需求.

第四章面向?qū)ο蠓椒?RUP

1.RUP是一種軟件開發(fā)過程框架,基于面向?qū)ο蠓栿w系給出了有關(guān)軟件開

發(fā)過程組織及實(shí)施的指導(dǎo).該框架體現(xiàn)了3個(gè)突出特征，即以用況驅(qū)動、體系結(jié)

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

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

中，UML作為一種可視化建模語言，給出了表達(dá)事物和事物之間關(guān)系的基本術(shù)語

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

層、設(shè)計(jì)層、實(shí)現(xiàn)層，并給出了實(shí)現(xiàn)各層模型之間映射的基本活動以及相關(guān)的指

導(dǎo).

3.RUP的突出特點(diǎn)是，它是一種以用況(UseCase)為驅(qū)動的、以體系結(jié)構(gòu)

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

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

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

ConstructionPhase)和移交階段(theTransitionPhase),

5.系統(tǒng)體系結(jié)構(gòu)是對系統(tǒng)語義的概括表述，對所有項(xiàng)目有關(guān)人員來說都是能

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

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

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

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

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

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

9.初始階段的基本目標(biāo)是:獲得與特定用況和平臺無關(guān)的系統(tǒng)體系結(jié)構(gòu)輪廓,

以此建立產(chǎn)品功能范圍;編制初始的業(yè)務(wù)實(shí)例，從業(yè)務(wù)角度指出該項(xiàng)目的價(jià)值，減

少項(xiàng)目主要的錯(cuò)誤風(fēng)險(xiǎn).

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

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

要的錯(cuò)誤風(fēng)險(xiǎn);到該階段末,就能夠估算成本、進(jìn)度,并能詳細(xì)地規(guī)劃構(gòu)造階段.

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

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

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

移交階段的基本目標(biāo)是：確保有一個(gè)實(shí)在的產(chǎn)品發(fā)布給用戶群.期間,培訓(xùn)

用戶如何使用該軟件.

10.在RUP的每次迭代中都要經(jīng)歷一個(gè)核心工作流,即需求獲取、分析、設(shè)

計(jì)、實(shí)現(xiàn)和測試.

11.RUP采用UseCase技術(shù)來獲取需求.其目標(biāo)是:使用UML中的用況、參

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

定的系統(tǒng)/產(chǎn)品模型,并產(chǎn)生該模型視角下的體系結(jié)構(gòu)描述.

1.列出候選需求

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

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

領(lǐng)域模型一般是以類圖予以表達(dá)的，用于捕獲系統(tǒng)語境中的一些重要領(lǐng)域?qū)ο箢?

其中領(lǐng)域?qū)ο蟊磉_(dá)系統(tǒng)工作環(huán)境中存在的事物或發(fā)生的事件.一般來說,領(lǐng)域類以

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

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

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

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

地等.

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

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

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

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

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

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

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

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

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

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

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

而言可形成一個(gè)認(rèn)知整體的實(shí)體的集合.業(yè)務(wù)實(shí)體和工作單元是領(lǐng)域類(如訂單、

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

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

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

以表達(dá)

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

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

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

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

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

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

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

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

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

(6)活動6:用況模型的結(jié)構(gòu)化.

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

化關(guān)系標(biāo)識和描述那些共享功能.

2)抽取用況描述中附加的或可選的功能，可以使用擴(kuò)展關(guān)

系對它們進(jìn)行標(biāo)識和描述.

3)標(biāo)識用況之間的包含關(guān)系.

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

及在該分析模型視角下的體系結(jié)構(gòu)描述.

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

并通過這些術(shù)語以及描述它們之間特定關(guān)系的術(shù)語,定義了一個(gè)抽象層.

14.需求分析基本術(shù)語

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

特征標(biāo)記,而用責(zé)任來定義其行為,并且其屬性和關(guān)系也是概念性的.分析類分為

邊界類、實(shí)體類和控制類3種.

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

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

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

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

個(gè)事件.

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

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

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

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

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

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

15.分析的主要活動

(1)活動1:體系結(jié)構(gòu)分析(ArchitecturalAnalysis).該活動的目

標(biāo)是:通過標(biāo)識分析包和分析類,建立分析模型和體系結(jié)構(gòu)“骨架飛并標(biāo)識有關(guān)分

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

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

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

可形成一些分析包.

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

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

3)任務(wù)3:標(biāo)識服務(wù)包.在包的層次結(jié)構(gòu)中，除了考慮以上對“共

性”的依賴之外時(shí)常還要考慮對“服務(wù)”的依賴,即應(yīng)用層的包依賴下層提供的

服務(wù)包.

4)任務(wù)4:定義分析包的依賴.該任務(wù)的目標(biāo)是:發(fā)現(xiàn)相對獨(dú)立的

包,實(shí)現(xiàn)包的高內(nèi)聚和低藕合.為此,通常使用特定應(yīng)用包和共用包把分析模型分

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

5)任務(wù)5