軟件平臺設計技術方案

軟件平臺設計技術方案

目錄

1定義問題與歸結模型...................................3

1.1問題分析...........................................................3

1.2問題定義............................................................6

2需求分析與軟件設計...................................8

2.1需求分析的任務與過程..............................................8

2.2如何進行系統(tǒng)設計..................................................11

2.3軟件設計的任務與活動..............................................12

3結構化分析與設計...................................13

3.1結構化分析........................................................13

3.2結構化設計........................................................18

3.3模塊設計..........................................................20

4面向對象的分析與設計................................22

4.1面向對象的基本概念...............................................22

4.2面向對象分析......................................................25

4.3統(tǒng)一建模語言......................................................27

5用戶界面設計.......................................41

5.1用戶界面設計的原則................................................41

5.2用戶界面設計過程..................................................42

6工作流設計.........................................43

6.1工作流設計概述.....................................................43

6.2工作流管理系統(tǒng).....................................................45

7簡單分布式計算機應用系統(tǒng)的設計.....................46

8系統(tǒng)運行環(huán)境的集成與設計...........................48

9系統(tǒng)過渡計劃.......................................49

1定義問題與歸結模型

軟件系統(tǒng)的目的是為了解決問題，因此在建模之初最重要的步驟是對問題的分析與定義,

并在此基礎上歸結模型，這樣才能夠獲得切實有效的模型。定義問題的過程包括：理解真實

世界中的問題和用戶的需要，并提出滿足這些需要的解決方案的過程。

1.1問題分析

問題分析的目標就是在開發(fā)之前對要解決的問題有一個更透徹的理解。為了達到這一目

標，通常需要經過在問題定義上達成共識，理解問題的本質，確定項目干系人和用戶，定義

系統(tǒng)的邊界和確定系統(tǒng)實現(xiàn)的約束這五個步驟。

1.在問題定義上達成共識

要檢驗大家是否在問題的定義上達成了共識，最簡單的方法就是把問題寫出來，看看是

否能夠獲得大家的認可。而要使得這個過程更加有效，應該將問題用標準化的格式寫出來，

根據(jù)UP的建議，應該包括以下幾個方面的要素。

問題概述：用簡短的幾句話，將所理解的問題本質描述出來；

影響：說明該問題將會對哪些項目干系人(Stakeholder,風險承擔者)產生影響；

結果：確定問題對項目干系人和商業(yè)活動會產生什么樣的影響；

優(yōu)點：概要性地提出解決方案，并列舉出該解決方案的主要優(yōu)點。

在問題定義上達成共識，就能夠有效地將開發(fā)團隊的理解與用戶的需求達成一致，這樣

就能夠使得整個系統(tǒng)的開發(fā)沿著合理的方向發(fā)展。

2.理解問題的本質

每一句描述都會夾雜著敘述者的個人理解和判斷，因此透過表面深入本質，理解問題背

后的問題，是問題分析階段一個十分關鍵的任務。其中一種技術是“根本原因”分析，這是

一種提示問題或其表象的根本原因的系統(tǒng)化方法。在實際的應用中，常使用因果魚骨圖和帕

累托圖兩種方法。

(1)因果魚骨圖。因果魚骨圖是一種有效的探尋問題根源的技術，它通過直觀的圖形

找出問題或現(xiàn)象的所有潛在原因，從而追蹤出問題的根源。它能夠幫助人們將問題的原因而

放在首位，提供了一種運用集體智慧解決問題的方法。在使用時，通常按照以下步驟進行。

將問題簡明扼要地寫在右邊的方框里；

確定問題潛在原因的主要類別，將它們連到魚的脊骨上；

用頭腦風暴法尋找原因并歸類。圖8-1是魚骨圖的一個示例。

圖8-1魚骨圖示例

（2）帕累托圖。

帕累托圖是采用直方圖的形式，根據(jù)問題的相對頻率或大小從高往低降序排列，幫助設

計師將精力集中在重要的問題上。它為80%的問題找到關鍵的20%的原因，它可以一目了然

地顯示出各個問題的相對重要程度，有助于預防在解決了一些問題后，卻使另外一些問題變

得更糟的現(xiàn)象發(fā)生。在使用時，通常按照以下步驟進行。

明確問題：也就是前面達成共識的問題定義；

找出問題的各種可能原因：通常可以利用頭腦風暴來收集意見，并通過參考以往積累的資料

和運營的數(shù)據(jù)來綜合分析；

選擇評價標準和考察期限：最常用的評價標準包括頻率（占總原因的百分比）和費用（產生

的影響），而考察的期限則應具有相應問題的代表性，并不是越長越好；

收集各種原因發(fā)生的頻率及費用數(shù)據(jù)；

將原因按照發(fā)生的頻率或費用從大到小排列起來；

將原因排在橫軸上，頻率或費用排列在縱軸上，形成如圖8-2所示的結果。

這樣就能夠將造成問題的關鍵原因捕獲出來，以便指導設計出更符合需要、更能夠解

決問題的解決方案。

40

圖8-2帕累托圖示例

3.確定項目干系人和用戶

要想有效地解決問題，必須了解用戶和其他相關的項目干系人（任何將從新系統(tǒng)或應用

的實現(xiàn)中受到實質性影響的人）的需要。不同的項目干系人通常對問題有不同的看法和不同

的需要，這些在解決問題時必須加以考慮。事實上，許多項目干系人就是系統(tǒng)的用戶，這一

部分通常是易于識別的；但還有一部分項目干系人是系統(tǒng)的間接用戶，甚至只是受系統(tǒng)影響

的商業(yè)結果，這一部分不易識別，但十分重要。

在尋找項目干系人時，可以思考：系統(tǒng)的用戶是誰？系統(tǒng)的客戶（購買者）是誰？還有

哪些人會受到系統(tǒng)輸出的影響？系統(tǒng)完成并投入使用后，有誰會對它進行評估？還有沒有其

他系統(tǒng)內部或外部的客戶，他們的需要有沒有必要去考慮？系統(tǒng)將來由誰來維護？

4.定義系統(tǒng)的邊界

系統(tǒng)的邊界是指解決方案系統(tǒng)和現(xiàn)實世界之間的邊界。在系統(tǒng)邊界中，信息以輸入和輸

出的形式流入系統(tǒng)并由系統(tǒng)流向系統(tǒng)外的用戶，所有和系統(tǒng)的交互都是通過系統(tǒng)和外界的接

口進行的。在定義系統(tǒng)的邊界時，將世界分為兩個部分：系統(tǒng)及與系統(tǒng)進行交互的事物。要

描述系統(tǒng)的邊界有兩種方法：一種是結構化分析中的“上下文范圍圖”，另一種則是面向對

象分析中的“用例模型

（1）上下文范圍圖。也就是數(shù)據(jù)流圖中的頂層圖，它是一個反映領域信息的模型，能

夠清晰地顯示出系統(tǒng)的工作職責和相鄰系統(tǒng)的職責起止之處，從而讓讀者能夠從宏觀的層面

去了解系統(tǒng)。圖8-3就是一個描述“證券經紀人系統(tǒng)”的上下文范圍圖。

（2）用例模型。用例模型則通過引入?yún)⑴c者來描述”和系統(tǒng)進行交互的事物“，只要識

別了參與者，自然而然系統(tǒng)的界限就確定下來了。在尋找參與者時，可以思考以下問題：誰

會對系統(tǒng)提供信息？誰會在系統(tǒng)中使用信息？誰會從系統(tǒng)中刪除信息？誰將操作系統(tǒng)？系

統(tǒng)將會在哪里被使用？系統(tǒng)從哪里得到信息？哪些外部系統(tǒng)要和系統(tǒng)進行交互？

然后，再根據(jù)每個參與者的功能需求，識別出代表系統(tǒng)功能的用例，從而界定系統(tǒng)的邊

界。而關于用例模型的更多細節(jié)，請參考4.3節(jié)。

券商柜臺系統(tǒng)行情資訊數(shù)據(jù)庫

用戶露本資料股市行情信息

用戶持倉信息資訊信息

接收短消息個性化需求信息

□--------*經紀人

勖------------系統(tǒng)定

F發(fā)送短洎息I個性化資訊信息

手機----y

r經紀人

個性化個性化

資訊信息離求信息

用戶

圖8-3上下文范圍圖示例

5.確定系統(tǒng)實現(xiàn)的約束

由于各種因素的存在，會對解決方案的選擇造成一定的限制，稱這種限制為約束。每條

約束都將影響到最后的解決方案的形成，甚至會影響是否能夠提出解決方案。

在考慮約束時，首先應該考察到不同的約束源，其中包括進度、投資收益、人員、設備

預算、環(huán)境、操作系統(tǒng)、數(shù)據(jù)庫、主機和客戶機系統(tǒng)、技術問題、行政問題、已有軟件、公

司總體戰(zhàn)略和程序、工具和語言的選擇、人員及其他資源限制等。

1.2問題定義

通過對問題進行細致周密的分析，就可以對其進行綜合的定義。對于一個問題的完整定

義，通常應包括目標、功能需求和非功能需求三個方面。

1.目標

目標是指構建系統(tǒng)的原因，它是最高層次的用戶需求，是業(yè)務上的需要，而功能、性能

需求則必須是以某種形式對該目標做出貢獻。在描述目標時，應該注意以下幾個方面。

優(yōu)勢：目標應該不僅僅是解決問題，還要提供業(yè)務上的優(yōu)勢；

度量：不僅要說明業(yè)務的優(yōu)勢，而且還必須提供度量這種優(yōu)勢的標準；

合理性：要確保完成解決方案所需的工作量少于所獲得的業(yè)務優(yōu)勢，這才是合理的解決方案;

可行性：要探尋能夠滿足度量標準的解決方案；

可達成性：對于組織而言，是否具備獲取該系統(tǒng)的技能，構建完成后是否能夠操作它。

例如，表8-1就是一個很好的目標描述的例子。

表目標描述的例子

目標：在冬季道路養(yǎng)護支出h節(jié)省費用

優(yōu)勢：減少除冰和道路笄護的費用

度」標準：除冰費用將在目前道路處理費用的基礎?降低25%,冰對道路造成的損傷將降低50%

2.功能需求

功能需求是用來指明系統(tǒng)必須做的事情，只有這些行為的存在，才有系統(tǒng)存在的價值。

功能需求應該源于業(yè)務需求，它只與問題域相關，與解決方案域無關。也就是說，功能需求

是在與用戶或某個業(yè)務人員交談時，他們所描述的內容是為了完成他們某部分的工作而必須

做的事情。而在設計解決方案時，會遇到一些限制條件，這些東西也是“系統(tǒng)需求”的一

部分，不過應該是設計約束或非功能需求形式指定。

在規(guī)定功能需求時要注意其詳細程度。由于這些需求是業(yè)務需求，因此應該由業(yè)務人員

來驗證。也就是說，用戶應該能夠指明系統(tǒng)要達到有用的程度，功能是否已經足夠；考慮到

工作的成果，它的功能是否正確。另外，在描述功能需求時，應該注意需求的二義性。而二

義性主要體現(xiàn)在以下幾個方面。

(1)同名異義的詞：在自然語言中存在許多同名但異義的詞語，應該謹慎地排除它們

帶來的影響。

(2)代詞：在需求描述中，代詞經常會產生指代不明的現(xiàn)象，應該盡量避免使用，而

是換成主語及賓語。

希賽教育專家提示：在檢查功能需求的二義性時，一種有效的方法是大聲地朗讀出來，

大家一起邊聽邊進行討論，這樣可以不斷地優(yōu)化。

3.非功能需求

非功能需求是系統(tǒng)必須具備的屬性，這些屬性可以看作是一些使產品具有吸引力、易用、

快速或可靠的特征或屬性。非功能需求并不改變產品的功能，它是為工作賦予特征的。在識

別功能需求和非功能需求時，有一種十分有用的思維模式：功能需求是以動詞為特征的，而

非功能性需求則是以副詞為特征的。非功能需求主要包括以下幾種。

(1)觀感需求：即產品外觀的精神實質，也就是與用戶界面的觀感相關的一組屬性；

(2)易用性需求：也就是產品的易用性程度，以及特殊的可用性考慮，通常包括用戶

的接受率、因為引入該產品而提高的生產效率、錯誤率、特殊人群的可用性等指標;

(3)性能需求：也就是關于功能實現(xiàn)要求有多快、多可靠、多少處理量及多精確的約

束。例如：速度、精度、安全性、容量、值范圍、吞吐量、資源使用效率、可靠性(平均無

故障時間)、可用性(不停機時間)、可擴展性等；

(4)可操作性需求：衡量產品的操作環(huán)境，以及對該操作環(huán)境必須考慮的問題；

(5)可維護性和可移植性需求：期望的改變，以及完成改變允許的時間；

(6)安全性需求：產品的安全保密性，通常體現(xiàn)為保密性、完整性和可獲得性；

(7)文化和政策需求：由產品的開發(fā)者和使用者所帶來的特別需求；

(8)法律需求：哪些法律和標準適用于本產品。

2需求分析與軟件設計

需求分析是軟件生命周期中相當重要的一個階段。根據(jù)StandishGroup對23000個

項目進行的研究結果表明，28%的項目徹底失敗，46%的項目超出經費預算或者超出工期，只

有約26%的項目獲得成功。需求分析工作在整個軟件開發(fā)生命周期中有著十分重要的意義。

而在這些高達74%的不成功項目中，有約60%的失敗是源于需求問題，也就是差不多有一半

的項目都遇到了這個問題，這一可怕的現(xiàn)象引起人們對需求分析的高度重視。需求分析階段

的主要任務是通過開發(fā)人員與用戶之間的廣泛交流，不斷澄清一些模糊的概念，最終形成一

個完整的、清晰的、一致的需求說明。

而當明確了用戶的需求之后，下一步的任務就是對未來的軟件系統(tǒng)進行設計，它是確定

系統(tǒng)實現(xiàn)的關鍵工作。需求分析和設計的方法對軟件開發(fā)過程而言是十分重要的，因此必須

扎實地掌握它。

需求分析與軟件設計是軟件生存期中最重要的兩個步驟，需求分析解決的是“做什么”

的問題，系統(tǒng)設計則是解決“怎么做”的問題。

2.1需求分析的任務與過程

需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其

他系統(tǒng)元素的接口細節(jié)，定義軟件的其他有效性需求，細化軟件要處理的數(shù)據(jù)域。用一句話

概括就是：需求分析主要是確定待開發(fā)軟件的功能、性能、數(shù)據(jù)、界面等要求。需求分析的

實現(xiàn)步驟通常包括：獲取當前系統(tǒng)的物理模型，抽象出當前系統(tǒng)的邏輯模型，建立目標系統(tǒng)

的邏輯模型三個部分。具體來說，需求分析階段的工作可以分成4個方面：

(1)問題識別：用于發(fā)現(xiàn)需求、描述需求，主要包括功能需求、性能需求、環(huán)境需求、

可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟件成本消耗與開發(fā)進度需求，

以此來預先估計以后系統(tǒng)可能達到的目標。

(2)分析與綜合：也就是對問題進行分析，然后在此基礎上整合出解決方案。這個步

驟經常是反復進行的，常用的方法有面向數(shù)據(jù)流的結構化分析方法(StructuredAnalysis,

SA),面向數(shù)據(jù)結構的Jackson方法，面向對象的分析方法(ObjectOrientedAnalysis,

00A),以及用于建立動態(tài)模型的狀態(tài)遷移圖和Petri網。

(3)編制需求分析的文檔：也就是對已經確定的需求進行文檔化描述，該文檔通常稱

為“需求規(guī)格說明書

(4)需求分析與評審：它是需求分析工作的最后一步，主要是對功能的正確性、完整

性和清晰性，以及其他需求給予評價。

1.需求的分類

什么是軟件的需求呢？軟件需求就是系統(tǒng)必須完成的事及必須具備的品質。具體來說,

軟件需求包括功能需求、非功能需求和設計約束三方面內容。各種需求的概念示意圖如圖

8-4所示。

圖8*4需求概念示意圖

功能需求：是指系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的功能，產品必須

執(zhí)行的動作。

非功能需求：是指產品必須具備的屬性或品質，如性能、響應時間、可靠性、容錯性、

擴展性等。

設計約束：也稱為限制條件、補充規(guī)約，這通常是對解決方案的一些約束說明，例如必

須采用國有自主知識版權的數(shù)據(jù)庫系統(tǒng)，必須在UNIX操作系統(tǒng)之下運行等。

除了這三種需求之外，還有業(yè)務需求、用戶需求、系統(tǒng)需求這三個處于不同層面的概念，

充分地理解這樣的模型才能夠更加清晰地理清需求的脈絡。

業(yè)務需求(BusinessRequirement)：是指反映組織機構或客戶對系統(tǒng)、產品高層次的

目標要求，通常問題定義本身就是業(yè)務需求。

用戶需求(UserRequirement)：是指描述用戶使用產品必須要完成什么任務，怎么完

成的需求，通常是在問題定義的基礎上進行用戶訪談、調查，對用戶使用的場景進行整理,

從而建立從用戶角度出發(fā)的需求。

系統(tǒng)需求(SystemRequirement)：是從系統(tǒng)的角度來說明軟件的需求，它包括用特性

說明的功能需求、質量屬性、非功能需求及設計約束。

分析師經常圍繞著''功能需求”來展開工作，而功能需求大部分都是從“系統(tǒng)需求”的

角度來分析與理解的，也就是用“開發(fā)人員”的視角來理解需求。但要想真正地得到完整的

需求，僅戴上“開發(fā)人員”的眼鏡是不夠的，還需要“領域專家”的眼鏡，要從更高的角度

來理解需求，這就是“業(yè)務需求”；同時還應該更好地深入用戶，了解他們的使用場景，了

解他們的想法，這就是“用戶需求”。這是一個理解層次的問題，并不僅僅是簡單的概念。

2.需求工程

需求工程就是包括創(chuàng)建和維護系統(tǒng)需求文檔所必需的一切活動的過程，主要包括需求

開發(fā)和需求管理兩大工作。

(1)需求開發(fā)：包括需求捕獲、需求分析、編寫規(guī)格說明書和需求驗證4個階段。在

這個階段需要完成確定產品所期望的用戶類型、獲取每種用戶類型的需求、了解實際用戶任

務和目標及這些任務所支持的業(yè)務需求、分析源于用戶的信息、對需求進行優(yōu)先級分類、將

所收集的需求編寫成為軟件規(guī)格說明書和需求分析模型、對需求進行評審等工作。

(2)需求管理：通常包括定義需求基線、處理需求變更、需求跟蹤等方面的工作。

這兩個方面是相輔相成的，需求開發(fā)是主線，是目標；需求管理是支持，是保障。換句

話說，需求開發(fā)是努力更清晰、更明確地掌握客戶對系統(tǒng)的需求；而需求管理則是對需求的

變化進行管理的過程。

3.需求分析方法

需求分析的方法可謂種類繁多，不過如果按照分解方式的不同，可以很容易地劃分出幾

種類型。本節(jié)先從分析方法發(fā)展的歷史，對其建立一個概要性的認識，在本章的后面幾節(jié)中

將詳細說明最具有代表性的結構化分析與設計、面向對象分析與設計兩種方法。

(1)結構化分析方法：最初的分析方法都不成體系，而且通常都只包括一些籠統(tǒng)的告

誡，在20世紀70年代分析技術發(fā)展的分水嶺終于出現(xiàn)了。這時人們開始嘗試使用標準

化的方法，開發(fā)和推出各種名為“結構化分析”的方法論，而TomDeMacro則是這個領域

最有代表性和權威性的專家。

(2)軟系統(tǒng)方法：這是一個過渡性的方法論，并未真正流行過，它的出現(xiàn)只是證明了

結構化分析方法的一些不足。因為結構化分析方法采用的相對形式化的模型不僅與社會觀格

格不入，而且在解決“不確定性”時顯得十分無力。最有代表性的軟系統(tǒng)方法是Checkland

方法。

(3)面向對象分析方法：在20世紀90年代，結構化方法的不足在面對多變的商業(yè)

世界時，顯得更加蒼白無力，這就催使了00A的迅速發(fā)展。

(4)面向問題域的分析(ProblemDomainOrientedAnalysis,PDOA)：現(xiàn)在又發(fā)現(xiàn)面

向對象分析方法也存在著很多的不足，應運而生了一些新的方法論，PDOA就是其中一種。

不過現(xiàn)在還在研究階段，并未廣泛應用。

2.2如何進行系統(tǒng)設計

當設計者拿到一個需求，他如何開展系統(tǒng)設計呢？許多想進入系統(tǒng)分析與設計的年輕人

以為自己知道了面向對象、統(tǒng)一建模語言、設計模式等新鮮深奧的名詞就可以進行設計了，

可是掌握工具和技能絕不是成為優(yōu)秀設計者的充分條件，甚至也不是必要條件。遺憾的是這

里沒有捷徑，只有設計者在實踐中不斷學習和總結。而在實踐中，系統(tǒng)設計與其說是在設計，

不如說是在選擇和妥協(xié)。

妥協(xié)，就是在各個系統(tǒng)目標之間找到一個平衡點。系統(tǒng)目標包括但不限制于功能、性

能、健壯性、開發(fā)周期、交付日期等。不幸的是，這些目標往往是矛盾的，提高軟件性能直

接意味著開發(fā)周期的增加、交付日期的推遲，盲目地增加功能可能導致性能降低，維護成本

提高。軟件設計者的難題在于在如此眾多的目標之間找到這個平衡點，并且明確知道如何設

計能實現(xiàn)這個平衡，既可以讓投資者覺得在預算之內，又能讓用戶相對滿意?？尚行苑治鲭A

段應該已經論述了這樣一個平衡點，可是如果設計者發(fā)現(xiàn)沒有這樣一個平衡點，如同沒有一

個設計者能讓人騎著自行車到月球上去，那么設計者只能提出放棄某個方面的過度要求，否

則系統(tǒng)要遭受必然失敗的命運。更多的情況是沒有經驗的設計者不知道是否存在這些平衡

點，更不知道如何利用合理的設計及有效的工具來達到平衡。因此設計者需要了解可以解決

問題的各種方案，并清楚知道各個方案的效果、成本、缺點，以及這些方案的區(qū)別，并在各

種方案中進行選擇。而這些，不是一個人能在一兩天了解的。

沒有一個設計者會完全重新開始設計一個系統(tǒng)，他們總參考多個與目標系統(tǒng)相類似的系

統(tǒng)，再從中進行甄別、取舍和補充來作為新系統(tǒng)的設計。人們發(fā)現(xiàn)一個優(yōu)秀的設計者似乎能

在聽完需求后就立即構想出目標系統(tǒng)的框架，這并不是因為他聰明或者比不知所措的設計者

新手多一個腦袋，而是因為他在平時已經了解大量的系統(tǒng)，對各種設計的優(yōu)缺點、局限性也

了然于胸，能夠把以前的設計根據(jù)需要再次使用。所以要成為優(yōu)秀的設計者，了解、掌握、

消化、總結前人和自己以前的設計成果是最好的方法，這似乎也是唯一的方法。

設計者的苦惱有時候和編程人員一樣。計算機系統(tǒng)的發(fā)展如此迅速，解決方案也越來越

多，如同編程語言的發(fā)展，同時，隨著人類社會的進步，投資者和客戶也提出了越來越高的

要求，這又需要設計者不斷學習、創(chuàng)造新的方案。

但系統(tǒng)設計也并非沒有規(guī)律可以遵循，如同幸福的家庭都很相似，不幸的家庭各有各的

不幸，人們在實踐中發(fā)現(xiàn)優(yōu)秀的系統(tǒng)設計一般在以下幾個方面都很出色。

(1)組件的獨立性。審視自己設計的系統(tǒng)，是否做到了高內聚、低耦合？

(2)例外的識別和處理。誰能保證系統(tǒng)使用者都精確按照使用說明書使用？

(3)防錯和容錯。當網絡中斷、數(shù)據(jù)庫崩潰這樣的災難性事件發(fā)生時，系統(tǒng)也跟著崩

潰嗎？

而且，更幸運的是，也有一些技術能夠改進系統(tǒng)設計，這些方法包括：降低復雜性、通

過合約進行設計、原型化設計、錯誤樹分析等。

2.3軟件設計的任務與活動

軟件設計(又叫系統(tǒng)設計xxk)是一個把軟件需求變換成軟件表示的過程。最初這種表示

只是描繪出軟件的總體框架，然后再進一步細化，并在此框架中填入細節(jié)。

1.軟件設計的兩個階段從工程管理角度，軟件設計可以分為兩個步驟：

(1)概要設計：也稱為高層設計，將軟件需求轉化為數(shù)據(jù)結構和軟件的系統(tǒng)結構。例

如，如果采用結構化設計，則將從宏觀的角度將軟件劃分成各個組成模塊，并確定模塊的功

能及模塊之間的調用關系。

(2)詳細設計：也稱為低層設計，將對結構表示進行細化，得到詳細的數(shù)據(jù)結構與算

法。同樣的，如果采用結構化設計，則詳細設計的任務就是為每個模塊進行設計。

2.主要的設計方法比較

在結構化設計風行的時代，主流的設計方法還包括Jackson方法和Parnas方法。結

構化方法側重于''模塊相對獨立且功能單一，使模塊間聯(lián)系弱、模塊內聯(lián)系強”；而Jackson

方法則是從數(shù)據(jù)結構導出模塊結構；Parnas方法的主要思想則是將可能引起變化的因素隱

藏在有關模塊內部，使這些因素變化時的影響范圍受到限制，它只提供了重要的設計準則，

但沒有規(guī)定出具體的工作步驟。

而近年來，對象技術憑借其對數(shù)據(jù)的高效封裝及良好的消息機制，實現(xiàn)了高內聚、低耦

合的系統(tǒng)設計，成了現(xiàn)代軟件設計的主流方法學。

3結構化分析與設計

結構化分析與設計方法是一種面向數(shù)據(jù)流的需求分析和設計方法，它適用于分析和設計

大型數(shù)據(jù)處理系統(tǒng)，是一種簡單、實用的方法，曾獲得廣泛的應用。

3.1結構化分析

結構化分析方法的基本思想是自頂向下逐層分解。分解和抽象是人們控制問題復雜性的

兩種基本手段。對于一個復雜的問題，人們很難一下子考慮問題的所有方面和全部細節(jié)，通

?？梢园岩粋€大問題分解成若干個小問題，每個小問題再分解成若干個更小的問題，經過多

次逐層分解，每個最底層的問題都是足夠簡單、容易解決的，于是復雜的問題也就迎刃而解

了。這個過程就是分解過程。

結構化分析與面向對象分析方法之間的最大差別是：結構化分析方法把系統(tǒng)看作一個過

程的集合體，包括人完成的和電腦完成的；而面向對象方法則把系統(tǒng)看成一個相互影響的對

象集。結構化分析方法的特點是利用數(shù)據(jù)流圖來幫助人們理解問題，對問題進行分析。

結構化分析一般包括以下工具：數(shù)據(jù)流圖(DataFlowDiagram,DFD),數(shù)據(jù)字典(Data

Dictionary,DD),結構化語言、判定表、判定樹。在接下來的部分將對它們一一做簡單介

紹。

結構化系統(tǒng)分析方法從總體上來看是一種強烈依賴數(shù)據(jù)流圖的自頂向下的建模方法。它

不僅是需求分析技術，也是完成需求規(guī)格化的有效技術手段。

1.結構化分析的工作步驟

在介紹具體的結構化分析方法之前，先對如何進行結構化分析做一個總結性描述，以幫

助大家更好地應用該方法。

（1）研究“物質環(huán)境首先，應畫出當前系統(tǒng)（可能是非計算機系統(tǒng)，或是半計算機

系統(tǒng)）的數(shù)據(jù)流圖，說明系統(tǒng)的輸入、輸出數(shù)據(jù)流，說明系統(tǒng)的數(shù)據(jù)流情況，以及經歷了哪

些處理過程。在這個數(shù)據(jù)流圖中，可以包括一些非計算機系統(tǒng)中數(shù)據(jù)流及處理的命名，例如

部門名、崗位名、報表名等。這個過程可以幫助分析員有效地理解業(yè)務環(huán)境，在與用戶的充

分溝通與交流中完成。

（2）建立系統(tǒng)邏輯模型。當物理模型建立完成之后，接下來的工作就是畫出相對于真

實系統(tǒng)的等價邏輯數(shù)據(jù)流圖。在前一步驟建立的數(shù)據(jù)流圖的基礎上，將所有自然數(shù)據(jù)流都轉

成等價的邏輯流，例如，將現(xiàn)實世界的報表存儲在計算機系統(tǒng)中的文件里；又如將現(xiàn)實世界

中“送往總經理辦公室”改為“報送報表

（3）劃清人機界限。最后，確定在系統(tǒng)邏輯模型中，哪些將采用自動化完成，哪些仍

然保留手工操作。這樣，就可以清晰地劃清系統(tǒng)的范圍。

2.數(shù)據(jù)流圖

DFD是一種圖形化的系統(tǒng)模型，它在一張圖中展示信息系統(tǒng)的主要需求，即輸入、輸出、

處理（過程）、數(shù)據(jù)存儲。由于從DFD中可以很容易地看出系統(tǒng)緊密結合的各個部分，而且

整個圖形模式只有5個符號需要記憶，所以深受分析人員的喜愛，因而廣為流行。

如圖8-5所示，DFD中包括以下幾個基本元素。

?過程：也稱為加工（處理），一步步地執(zhí)行指令，完成輸入到輸出的轉換。

?外部實體：也稱為源/宿，系統(tǒng)之外的數(shù)據(jù)源或目的。

?數(shù)據(jù)存儲：也稱為文件，存放數(shù)據(jù)的地方，一般是以文件、數(shù)據(jù)庫等形式出現(xiàn)。

?數(shù)據(jù)流：從一處到另一處的數(shù)據(jù)流向，如從輸入或輸出到一個過程的數(shù)據(jù)流。

?實時連接：當過程執(zhí)行時，外部實體與過程之間的來回通信。

外部實體/源/宿"叫"

圖8-5數(shù)據(jù)流圖的符號集

希賽教育專家提示：不同的參考書籍中關于DFD的符號可能有些不一樣，其中加工、

外部實體、數(shù)據(jù)存儲和數(shù)據(jù)流是公共的部分。

(1)數(shù)據(jù)流圖的層次。正如前面提到的，結構化分析的思路是依賴于數(shù)據(jù)流圖進行自

頂而下的分析。這也是因為系統(tǒng)通常比較復雜，很難在一張圖上將所有的數(shù)據(jù)流和加工描述

清楚。因此，數(shù)據(jù)流圖提供一種表現(xiàn)系統(tǒng)高層和低層概念的機制。也就是先繪制一張較高層

次的數(shù)據(jù)流圖，然后在此基礎上，對其中的過程(處理)進行分解，分解成為若干獨立的、

低層次的、詳細的數(shù)據(jù)流圖，而且可以這樣逐一地分解下去，直至系統(tǒng)被清晰地描述出來。

數(shù)據(jù)流圖的層次如圖8-6所示。

圖8-6數(shù)據(jù)流圖的層次

(2)Context圖。Context圖，也就是系統(tǒng)上下文范圍關系圖。這是描述系統(tǒng)最高層

結構的DFD圖。它的特點是，將整個待開發(fā)的系統(tǒng)表示為一個過程，將所有的外部實體和

進出系統(tǒng)的數(shù)據(jù)流都畫在一張圖中。圖8-7就是一個Context圖的例子。

圖8-7Context圖實例

Context圖用來描述系統(tǒng)有什么輸入、輸出數(shù)據(jù)流，與哪些外部實體直接相關，可以把

整個系統(tǒng)的范圍勾畫出來。

(3)逐級分解。當完成了Context圖的建模之后，就可以在此基礎上進行進一步的分

解。以圖8-7為例，進行再分解，在對原有流程了解的基礎上，可以得到如圖8-8所示的

結果。

圖8-8DFD0層圖實例

圖8-8是在Context圖的基礎上做的第一次分解，而在Context圖中只有一個過

程，那就是系統(tǒng)，將其編號為0。而接下來對Context圖進行的分解，其實就是對這個編

號為0的過程進行更細化的描述，在這里引入了新的過程、數(shù)據(jù)存儲，為了能夠區(qū)分其位

置的級別，在這層次上的過程將以1、2、3為序列進行編號。

由于這是對過程0的分解，因此也稱之為DFD0層圖。而可以根據(jù)需要對DFD0層

圖上的過程(編號為1、2、3)進行類似的分解，那么就稱之為DFD1層圖，在DFD1層

圖中引入的新過程，其編號規(guī)則就是1.1,1.2-,以及2.1,2.2-,以此類推，直到完成

分析工作。

另外，這里存在一個很關鍵的要點，那就是DFDO層圖是Context圖的細化，因此所

有的輸入和輸出應該與Context圖完全一致，否則就說明存在著錯誤。

(4)如何畫DFD。DFD的繪制是一個自頂向下、由外到里的過程，通常按照以下幾個

步驟進行。

?畫系統(tǒng)的輸入和輸出：就是在圖的邊緣標出系統(tǒng)的輸入、輸出數(shù)據(jù)流。這一步其實是決

定研究的內容和系統(tǒng)的范圍。在畫的時候，可以先將盡可能多的輸入、輸出畫出來，然

后再刪除多余的，增加遺漏的。

?畫數(shù)據(jù)流圖的內部：將系統(tǒng)的輸入、輸出用一系列的處理連接起來，可以從輸入數(shù)據(jù)流

畫向輸出數(shù)據(jù)流，也可以從中間畫出去。

?為每一個數(shù)據(jù)流命名：命名的好壞與數(shù)據(jù)流圖的可理解性密切相關，應避免使用空洞的

名字。

?為加工命名：注意應該使用動賓短語。

?不考慮初始化和終點，暫不考慮出錯路徑等細節(jié)，不畫控制流和控制信息。

3.細化記錄DFD部件

為了更好地描述DFD的部件，結構化分析方法還引入了數(shù)據(jù)字典、結構化語言及決策樹、

決策表等方法。通過使用這些工具，能對數(shù)據(jù)流圖中描述不夠清晰的地方進行有效的補充。

其其中數(shù)據(jù)字典應用最為廣泛，下面將詳細說明數(shù)據(jù)字典的相關使用方法。

數(shù)據(jù)字典技術是一種很實用、有效的表達數(shù)據(jù)格式的手段。它是對所有與系統(tǒng)相關的數(shù)

據(jù)元素的一個有組織的列表和精確嚴格的定義，使得用戶和系統(tǒng)分析員對于輸入、輸出、存

儲成分和中間計算機有共同的理解。通常數(shù)據(jù)字典的每一個條目中包括以下信息。

①名稱：數(shù)據(jù)或控制項、數(shù)據(jù)存儲或外部實體的主要名稱，如果有別名的還應該將別

名列出來。

②何處使用/如何使用：使用數(shù)據(jù)或控制項的加工列表，以及如何使用。

③內容描述：說明該條目的內容組成，通常采用以下符號進行說明。

=：由…構成。

+:和，代表順序連接的關系。

[I]:或，代表從中選擇一個。

{}*：n次重復。

（）：代表可選的數(shù)據(jù)項。

*-*:表示特定限制的注釋。

④補充信息：關于數(shù)據(jù)類型、默認值、限制等信息。

下面就是一個數(shù)據(jù)字典的實例：

客戶基本信息=客戶編號+客戶名稱+身份證號碼+手機+家庭電話

客戶編號={0…9}8

客戶名稱={字}4

身份證號碼=[{0-9}151{0-9}18]

手機=[{0?“9}11|{0“?9}12]

家庭電話=（區(qū)號）+本地號區(qū)號={0…9}4

本地號=[{0…9}71{?！?}8]

3.2結構化設計

結構化設計包括架構設計、接口設計、數(shù)據(jù)設計和過程設計等任務。它是一種面向數(shù)據(jù)

流的設計方法，是以結構化分析階段所產生的成果為基礎，進一步自頂而下、逐步求精和模

塊化的過程。

1.概要設計與詳細設計的主要任務

概要設計階段的主要任務是設計軟件的結構、確定系統(tǒng)是由哪些模塊組成，以及每個模

塊之間的關系。它采用結構圖（包括模塊、調用、數(shù)據(jù)）來描述程序的結構，此外還可以使

用層次圖和IIIP0（層次圖加輸入/處理/輸出圖）。

整個過程主要包括：復查基本系統(tǒng)模型、復查并精化數(shù)據(jù)流圖、確定數(shù)據(jù)流圖的信息流

類型（包括交換流和事務流）、根據(jù)流類型分別實施變換分析或事務分析、根據(jù)軟件設計原

則對得到的軟件結構圖進一步優(yōu)化。

詳細設計階段的主要任務則是確定應該如何具體地實現(xiàn)所要求的系統(tǒng)，得出對目標系統(tǒng)

的精確描述。它采用自頂向下、逐步求精的設計方式和單入口單出口的控制結構。常使用的

工具包括程序流程圖PFD、盒圖NS、問題分析圖PAD、程序設計語言PDL。

2.結構圖

如圖8-9所示，結構圖的基本成分包括模塊、調用（模塊之間的調用關系）和數(shù)據(jù)（模

塊間傳遞及處理數(shù)據(jù)信息）。

圖8-9結構圖的基本成分

結構圖是在需求分析階段產生的數(shù)據(jù)流圖的基礎上進行進一步的設計。它將DFD圖中

的信息流分為兩種類型。

變換流：信息首先沿著輸入通路進入系統(tǒng)，并將其轉換為內部表示，然后通過變換中心

（加工）的處理，再沿著輸出轉換為外部形式離開系統(tǒng)。具有這種特性的加工流就是變換流。

事務流：信息首先沿著輸入通路進入系統(tǒng)，事務中心根據(jù)輸入信息的類型在若干個動作

序列（活動流）中選擇一個執(zhí)行，這種信息流稱為事務流。

3.程序流程圖和盒圖

程序流程圖和盒圖都是用來描述程序的細節(jié)邏輯的，其符號如圖8-10所示。

程序流程圖的特點是簡單、直觀、易學，但它的缺點也正是由于其隨意性而使得畫出來

的流程圖容易成為非結構化的流程圖。而盒圖正是為了解決這一問題設計的，它是一種符合

結構化程序設計原則的圖形描述工具。

盒圖的主要特點是功能域明確、無法任意轉移控制、容易確定全局數(shù)據(jù)和局部數(shù)據(jù)的作

用域、容易表示嵌套關系、可以表示模塊的層次結構。但它也帶來了一個副作用，那就是修

改相對比較困難。

CD口口。匚

起位點輸入/輸出處理準備既定處理

、線“-外接“0°內接

條件判斷

圖8-10程序流程圖和盒圖基本符號示意圖

4.PAD和PDL

PAD是問題分析圖的縮寫，它符合自頂向下、逐步求精的原則，也符合結構化程序設計

的思想，它最大的特點在于能夠很方便地轉換為程序語言的源程序代碼。

PDL則是語言描述工具的縮寫，它和高級程序語言很相似，也包括數(shù)據(jù)說明部分和過程

部分，還可以帶注解等成分，但它是不可執(zhí)行的。PDL是一種形式化語言，其控制結構的描

述是確定的，但內部的描述語法是不確定的。PDL通常也被稱為偽碼。

3.3模塊設計

在結構化方法中，模塊化是一個很重要的概念，它是將一個待開發(fā)的軟件分解成為若干

個小的簡單部分一一模塊，每個模塊可以獨立地開發(fā)、測試。這是一種復雜問題的“分而治

之”原則，其目的是使程序的結構清晰、易于測試與修改。

具體來說，模塊是指執(zhí)行某一特定任務的數(shù)據(jù)結構和程序代碼。通常將模塊的接口和功

能定義為其外部特性，將模塊的局部數(shù)據(jù)和實現(xiàn)該模塊的程序代碼稱為內部特性。而在模塊

設計時，最重要的原則就是實現(xiàn)信息隱蔽和模塊獨立。模塊經常具有連續(xù)性，也就意味著作

用于系統(tǒng)的小變動將導致行為上的小變化，同時規(guī)模說明的小變動也將影響到一小部分模

塊。

1.信息隱蔽原則

信息隱蔽是開發(fā)整體程序結構時使用的法則，即將每個程序的成分隱蔽或封裝在一個單

一的設計模塊中，并且盡可能少地暴露其內部的處理。通常將難的決策、可能修改的決策、

數(shù)據(jù)結構的內部連接以及對它所做的操作細節(jié)、內部特征碼、與計算機硬件有關的細

節(jié)等隱蔽起來。通過信息隱蔽可以提高軟件的可修改性、可測試性和可移植性，它也是現(xiàn)代

軟件設計的一個關鍵性原則。

2.模塊獨立性原則

模塊獨立是指每個模塊完成一個相對獨立的特定子功能，并且與其他模塊之間的聯(lián)系最

簡單。保持模塊的高度獨立性，也是設計過程中的一個很重要的原則。通常用耦合（模塊之

間聯(lián)系的緊密程度）和內聚（模塊內部各元素之間聯(lián)系的緊密程度）兩個標準來衡量，設計

的目標是高內聚、低耦合。

模塊的內聚類型通?？梢苑譃?種，根據(jù)內聚度從高到低排序，如表8-2所示。

表&2模塊的內聚類型

內聚類型描述

功能內聚

■序內聚處理元素相關,而且必須順序執(zhí)行

通信內聚所有處理元盍集中在一個數(shù)據(jù)結構的區(qū)域上

過程內聚處理元般相關,而H必須按特定的次序執(zhí)仃

瞬時內聚

邏輯內聚完成遺輯上相關的一組任務

偶然內聚三改絹沒有關系或護散4系的任務

與此相對應的，模塊的耦合性類型通常也分為7種，根據(jù)耦合度從低到高排序，如表8-3

所示。

表8-3模塊的耦合性類型

耦合類型描述

非直接播合沒有自接聯(lián)系,互相不依賴對方

數(shù)據(jù)戳臺借助參數(shù)表傳遞同單數(shù)據(jù)

標記耦介一個數(shù)據(jù)結構的一部分借助于模塊接口來傳遞

控制耦合模塊間傳遞的信息中包含用f控制模塊內部遺輯的信總

外部耦合與軟件以外的環(huán)境有關

.「；.一多個模塊引用同一個全局數(shù)據(jù)區(qū)

一個模塊訪問另一個模塊的內部數(shù)據(jù)

一個模塊不通過正常入口轉到另一個模塊的內部

內容耦合

兩個模塊有一部分程序代碼至登

一個模塊有多個入口

除了滿足以上兩大基本原則之外，通常在模塊分解時還需要注意：保持模塊的大小適中,

盡可能減少調用的深度，直接調用該模塊的個數(shù)應該盡量大，但調用其他模塊的個數(shù)則不宜

過大；保證模塊是單入口、單出口的；模塊的作用域應該在控制域之內；功能應該是可預測

的。

4面向對象的分析與設計

面向對象方法是一種非常實用的軟件開發(fā)方法，它一出現(xiàn)就受到軟件技術人員的青睞,

現(xiàn)已成為計算機科學研究的一個重要領域，并逐漸成為軟件開發(fā)的一種主要方法。面向對象

方法以客觀世界中的對象為中心，其分析和設計思想符合人們的思維方式，分析和設計的結

構與客觀世界的實際比較接近，容易被人們接受。在面向對象方法中，分析和設計的界面并

不明顯，它們采用相同的符號表示，能夠方便地從分析階段平滑地過渡到設計階段。此外,

在現(xiàn)實生活中，用戶的需求經常會發(fā)生變化，但客觀世界的對象及對象間的關系比較穩(wěn)定,

因此用面向對象方法分析和設計的結構也相對比較穩(wěn)定。

4.1面向對象的基本概念

1.對象和類

對象是系統(tǒng)中用來描述客觀事物的一個實體，它由對象標識（名稱）、屬性（狀態(tài)、數(shù)

據(jù)、成員變量）和服務（操作、行為、方法）三個要素組成，它們被封裝為一個整體，以接

口的形式對外提供服務。

在現(xiàn)實世界中，每個實體都是對象，如學生、書籍、收音機等；每個對象都有它的操作，

例如書籍的頁數(shù)，收音機的頻道、按鈕等屬性，以及收音機的切換頻道等操作。

而類則是對具有相同屬性和服務的一個或一組對象的抽象。類與對象是抽象描述和具體

實例的關系，一個具體的對象被稱為類的一個實例。在系統(tǒng)設計過程中，類可以分為三種類

型，分別是實體類、邊界類和控制類。

（1）實體類：類，它們都屬于實體類。實體類通常都是永久性的，它們所具有的屬性

和關系實體類映射需求中的每個實體，實體類保存需要存儲在永久存儲體中的信息，例如,

在線教育平臺系統(tǒng)可以提取出學員類和課程是長期需要的，有時甚至在系統(tǒng)的整個生存期都

需要。

實體類是對用戶來說最有意義的類，通常采用業(yè)務領域術語命名，一般來說是一個名詞，

在用例模型向領域模型的轉化中，一個參與者一般對應于實體類。通?？梢詮腟RS中的那

些與數(shù)據(jù)庫表（需要持久存儲）對應的名詞著手來找尋實體類。通常情況下，實體類一定有

屬性，但不一定有操作。

（2）控制類：控制類是用于控制用例工作的類，一般是由動賓結構的短語（”動詞+名

詞”或“名詞+動詞”）轉化來的名詞，例如，用例“身份驗證”可以對應于一個控制類“身

份驗證器”，它提供了與身份驗證相關的所有操作?？刂祁愑糜趯σ粋€或幾個用例所特有的

控制行為進行建模，控制對象（控制類的實例）通?？刂破渌麑ο?，因此，它們的行為具有

協(xié)調性。

控制類將用例的特有行為進行封裝，控制對象的行為與特定用例的實現(xiàn)密切相關，當系

統(tǒng)執(zhí)行用例的時候，就產生了一個控制對象，控制對象經常在其對應的用例執(zhí)行完畢后消亡。

通常情況下，控制類沒有屬性，但一定有方法。

（3）邊界類：邊界類用于封裝在用例內、外流動的信息或數(shù)據(jù)流。邊界類位于系統(tǒng)與

外界的交接處，包括所有窗體、報表、打印機和掃描儀等硬件的接口，以及與其他系統(tǒng)的接

口。要尋找和定義邊界類，可以檢查用例模型，每個參與者和用例交互至少要有一個邊界類，

邊界類使參與者能與系統(tǒng)交互。邊界類是一種用于對系統(tǒng)外部環(huán)境與其內部運作之間的交互

進行建模的類。常見的邊界類有窗口、通信協(xié)議、打印機接口、傳感器和終端等。實際上,

在系統(tǒng)設計時，產生的報表都可以作為邊界類來處理。

邊界類用于系統(tǒng)接口與系統(tǒng)外部進行交互，邊界對象將系統(tǒng)與其外部環(huán)境的變更（例如,

與其他系統(tǒng)的接口的變更、用戶需求的變更等）分隔開，使這些變更不會對系統(tǒng)的其他部分

造成影響。通常情況下，邊界類可以既有屬性也有方法。

2.繼承與泛化

繼承是面向對象方法中重要的概念，用來說明特殊類（子類）與一般類（父類）的關系，

而通常用泛化來說明一般類與特殊類的關系，也就是說它們是一對多關系。

如圖8-11所示，“交通工具”是“自行車”和“小轎車”的泛化；“自行車”和“小轎

車”從“交通工具”中繼承。

3.多態(tài)與重載

多態(tài)（即多種形式）性是指一般類中定義的屬性或服務被特殊類繼承后，可以具有不同

的數(shù)據(jù)類型或表現(xiàn)出不同的行為，通常是使用重載和改寫兩項技術來實現(xiàn)的。一般有4種不

同形式的多態(tài)，如表8-4所示。

圖-----------------------------------------------

表84多態(tài)類型一覽表

多態(tài)類型描述示例

classOverLaoder{

描述一個函數(shù)名稱有多紳不同實現(xiàn)方式,通常

里載publicvoidtest(intx);

可以在編譯時基于類型簽名來區(qū)分各個里轂曲

（專用多套）publicvoidteot(mtx.doubley);

數(shù)的名稱

publicvoidtest(stnng:x);)

classParent(

是更皎的一種特殊情況，只發(fā)生在有關父類和

改寫publicvoidtest(intx);}

產類之間關系中.注：通常簽名相同,內容不

（包含多名）classChildextendsParent{

publicvoidtest(int);}

多態(tài)變量尚明為一腫類型.但實際上卻可以包含另一種

Parentp=newChild()：

（賦值多態(tài)強制多態(tài)）類量數(shù)值的變量

templateclassT>Tmax(Ta,Tb)

它提供了一種創(chuàng)建通用工具的方法.可以在特

泛型（模板,參數(shù)多態(tài),{if(r：b)returnb;

定的場合將其特化

Returaa;}

注1:重載也稱為過載、重置；

注2：參數(shù)多態(tài)和包含多態(tài)稱為通用多態(tài)，重載多態(tài)和強制多態(tài)稱為特定多態(tài)。

希賽教育專家提示：雖然重載和改寫都是在多種潛在的函數(shù)體中，選擇和調用某一個函

數(shù)或方法并對其進行執(zhí)行，但它們的本質區(qū)別在于：重載是編譯時執(zhí)行的（靜態(tài)綁定），而

改寫則是運行時選擇的（動態(tài)綁定）。

4.模板類

也稱為類屬類，它用來實現(xiàn)參數(shù)多態(tài)機制。一個類屬類是關于一組類的一個特性抽象,

它強調的是這些類的成員特征中與具體類型無關的那些部分，而用變元來表示與具體類型有

關的那些部分。

5.消息和消息通信

消息就是向對象發(fā)出的服務請求，它通常包括提供服務的對象標識、消息名、輸入信息

和回答信息。消息通信則是面向對象方法學中的一個重要原則，它與對象的封裝原則密不可

分，為對象間提供了唯一合法的動態(tài)聯(lián)系的途徑。

4.2面向對象分析

面向對象分析的目標是開發(fā)一系列模型，這些模型描述計算機軟件，當它工作時以滿足

一組客戶定義的需求。對象技術的流行，演化出了數(shù)十種不同的00A方法，每個方法都引

入了一個產品或系統(tǒng)分析的過程、一組過程演化的模型及使軟件工程師能夠以一致的方式創(chuàng)

建每個模型的符號體系。其中比較流行的方法包括OMT.OOA.OOSE.Booch方法等，而OMT、

OOSE、Booch最后則統(tǒng)一成為UMLo

1.OOA/OOD方法

這是由PeterCoad和EdwardYourdon提出的，00A模型中包括主題、對象類、結

構、屬性和服務5個層次，需經過標識對象類、標識結構與關聯(lián)（包括繼承、聚合、組合、

實例化等）、劃分主題、定義屬性、定義服務5個步驟來完成整個分析工作。

00D中將繼續(xù)貫穿00A中的5個層次和5個活動，它由人機交互部件、問題域部件、任

務管理部件、數(shù)據(jù)管理部件4個部分組成，其主要的活動就是這4個部件的設計工作。

設計問題域部分：00A的結果恰好是00D的問題域部件，分析的結果在00D中可以被改

動或增補，但基于問題域的總體組織框架是長時間穩(wěn)定的；

設計人機交互部件：人機交互部件在上述結果中加入人機交互的設計和交互的細節(jié)，包括窗

口和輸出報告的設計。可以用原型來幫助實際交互機制進行開發(fā)和選擇；

設計任務管理部分：這部分主要是識別事件驅動任務，識別時鐘驅動任務，識別優(yōu)先任務和

關鍵任務，識別協(xié)調者，審查每個任務并定義每個任務。

設計數(shù)據(jù)管理部分：數(shù)據(jù)管理部分提供了在數(shù)據(jù)管理系統(tǒng)中存儲和檢索對象的基本結構，其

目的是隔離數(shù)據(jù)管理方法對其他部分的影響。

2.Booch方法

Booch認為軟件開發(fā)是一個螺旋上升的過程，每個周期中包括標識類和對象、確定類和

對象的含義、標識關系、說明每個類的接口和實現(xiàn)4個步驟。它的模型中主要包括如表8-

5所示的幾種圖形。

表&5Booch方法的模型概述

靜態(tài)模型動態(tài)模型

類圖狀態(tài)轉換圖

邏輯模型

對象圖時序圖

模塊圖

iMMta

進程圖

Booch方法的開發(fā)過程是一個迭代的、漸進式的系統(tǒng)開發(fā)過程，它可以分為宏過程和微

過程兩類。宏過程用于控制微過程，是覆蓋幾個月或幾周所進行的活動，它包括負責建立核

心需求的概念化，為所期望的行為建立模型的分析，建立架構的設計，形成實現(xiàn)的進化，以

及管理軟件交付使用的維護等5個主要活動。

而微過程則基本上代表了開發(fā)人員的日?；顒樱?個重要、沒有順序關系的步驟

組成：在給定的抽象層次上識別出類和對象，識別出這些類和對象的語義，識別出類間和對

象間的關系，實現(xiàn)類和對象。

3.0MT方法

0MT是對象建模技術的縮寫，它是由JamRambaugh及其同事合作開發(fā)的，它主要用

于分析、系統(tǒng)設計和對象設計。包括對象模型（靜態(tài)的、結構化的系統(tǒng)的''數(shù)據(jù)”性質，通

常采用類圖）、動態(tài)模型（瞬時的、行為化的系統(tǒng)“控制”性質，通常使用狀態(tài)圖）和功能

模型（表示變化的系統(tǒng)的“功能”性質，通常使用數(shù)據(jù)流圖）。0MT方法的三大模型如表8-

6所示。（2021年案例考）

表&6OMT方法的三大模型

模型說明主要技術

」.,：1_一對象之間的關系、屬性、操作.它表示靜態(tài)的、結枸卜

對象模型對象圖

的、系統(tǒng)的“數(shù)據(jù)”特征

描述與時間和操作順序有關的系統(tǒng)特征.如激發(fā)事件、事件序列、確定事件先后關系

動態(tài)模型狀態(tài)圖