第10章面向對象分析

10.1面向對象分析的基本過程

10.2需求陳述

10.3建立對象模型

10.4建立動態模型

10.5建立功能模型

涓華大學出版社

10.6定義服務

10.7小結

習題

清監文學出據濁制赦力方士"IMMMH

不論采用哪種方法開發軟件，分析的過程都是提取

系統需求的過程。分析工作主要包括3項內容，這

就是理解、表達和驗證。首先，系統分析員通過與

用戶及領域專家的充分交流，力求完全理解用戶需

求和該應用領域中的關鍵性的背景知識，并用某種

無二義性的方式把這種理解表達成文檔資料。分析

過程得出的最重要的文檔資料是軟件需求規格說明

（在面向對象分析中，主要由對象模型、動態模型

和功能模型組成）。

清培無學出朧鈍篇於::肘掰置房MyuMHI

由于問題復雜，而且人與人之間的交流帶有隨意性

和非形式化的特點，上述理解過程通常不能一次就

達到理想的效果。因此，還必須進一步驗證軟件需

求規格說明的正確性、完整性和有效性，如果發現

了問題則進行修正。顯然，需求分析過程是系統分

析員與用戶及領域專家反復交流和多次修正的過程。

也就是說，理解和驗證的過程通常交替進行，反復

迭代，而且往往需要利用原型系統作為輔助工具。

清華7騫出掘鈍咖期施金駕imiH

面向對象分析(OOA)的關鍵是識別出問題域內的類

與對象，并分析它們相互間的關系，最終建立起問

題域的簡潔、精確、可理解的正確模型。在用面向

對象觀點建立起的3種模型中，對象模型是最基本、

最重要、最核心的。

J2Ji二尸/,刀廣?，jhXIJ*-^'n.**r^*

10.1面向對象分析的基本過程

10.1.1概述

面向對象分析，就是抽取和整理用戶需求并建立問

題域精確模型的過程。

通常，面向對象分析過程從分析陳述用戶需求的文

件開始。可能由用戶（包括出資開發該軟件的業主

代表及最終用戶）單方面寫出需求陳述，也可能由

系統分析員配合用戶，共同寫出需求陳述。當軟件

項目采用招標方式確定開發單位時，“標書”往往

可以作為初步的需求陳述。

需求陳述通常是不完整、不準確的，而且往往是非

正式的。通過分析，可以發現和改正原始陳述中的

二義性和不一致性，補充遺漏的內容，從而使需求

陳述更完整、更準確。因此，不應該認為需求陳述

是一成不變的，而應該把它作為細化和完善實際需

求的基礎。在分析需求陳述的過程中，系統分析員

需要反復多次地與用戶協商、討論、交流信息，還

應該通過調研了解現有的類似系統。正如以前多次

講過的，快速建立起一個可在計算機上運行的原型

系統，非常有助于分析員和用戶之間的交流和理解,

從而能更正確地提煉出用戶的需求。

福衫尤學出扳社々腳鴨.

接下來，系統分析員應該深入理解用戶需求，抽象

出目標系統的本質屬性，并用模型準確地表示出來。

用自然語言書寫的需求陳述通常是有二義性的，內

容往往不完整、不一致。分析模型應該成為對問題

的精確而又簡潔的表示。后繼的設計階段將以分析

模型為基礎。更重要的是，通過建立分析模型能夠

糾正在開發早期對問題域的誤解。

清華無學出版神國，斯赧61旖廿f卅

在面向對象建模的過程中，系統分析員必須認真向

領域專家學習。尤其是建模過程中的分類工作往往

有很大難度。繼承關系的建立實質上是知識抽取過

程，它必須反映出一定深度的領域知識，這不是系

統分析員單方面努力所能做到的，必須有領域專家

的密切配合才能完成。

在面向對象建模的過程中，還應該仔細研究以前針

對相同的或類似的問題域進行面向對象分析所得到

的結果。由于面向對象分析結果的穩定性和可重用

性，這些結果在當前項目中往往有許多是可以重用

的。

高華7'二學出版社

10.1.23個子模型與5個層次

正如9.3節所述，面向對象建模得到的模型包含系

統的3個要素，即靜態結構（對象模型）、交互次序

（動態模型）和數據變換（功能模型）。解決的問題不

同，這3個子模型的重要程度也不同：幾乎解決任

何一個問題，都需要從客觀世界實體及實體間相互

關系抽象出極有價值的對象模型；當問題涉及交互

作用和時序時（例如，用戶界面及過程控制等），動

態模型是重要的；解決運算量很大的問題（例如，

高級語言編譯、科學與工程計算等），則涉及重要

的功能模型。動態模型和功能模型中都包含了對象

模型中的操作（即服務或方法）o

復雜問題（大型系統）的對象模型通常由下述5個

層次組成：主題層、類與對象層、結構層、屬性

層和服務層，如圖10.1所示。

這5個層次很像疊在一起的5張透明塑料片，它們一

層比一層顯現出對象模型的更多細節。在概念上，

這5個層次是整個模型的5張水平切片。

猾華大學出版社

圖10.1復雜問題的對象模型的5個層次

清華文學出新社**腎訛惇制珊度均勃

J?-J"——J?'J，，'JI-''一，1.J,?^1*'?'J*~^~~'

在本書第9章中已經講述了類與對象（即UML的

“類”）、結構（即類或對象之間的關系）、屬性

和服務的概念，現在再簡要地介紹一下主題（或范

疇）的概念。主題是指導讀者（包括系統分析員、軟

件設計人員、領域專家、管理人員、用戶等，總之,

“讀者”泛指所有需要讀懂系統模型的人）理解大

型、復雜模型的一種機制。也就是說，通過劃分主

題把一個大型、復雜的對象模型分解成幾個不同的

概念范疇。心理研究表明，人類的短期記憶能力一

般限于一次記憶5?9個對象，這就是著名的7±2原

則。面向對象分析從下述兩個方面來體現這條原則:

控制可見性和指導讀者的注意力。

首先，面向對象分析通過控制讀者能見到的層次數

目來控制可見性。其次，面向對象分析增加了一個

主題層，它可以從一個相當高的層次描述總體模型,

并對讀者的注意力加以指導。

上述5個層次對應著在面向對象分析過程中建立對

象模型的5項主要活動：找出類與對象，識別結構，

識別主題，定義屬性，定義服務。必須強調指出的

是，我們說的是“5項活動”，而沒有說5個步驟，

事實上，這5項工作完全沒有必要順序完成，也無

須徹底完成一項工作以后再開始另外一項工作。

清華廣字出版社藻學A

雖然這5項活動的抽象層次不同，但是在進行面向

對象分析時并不需要嚴格遵守自頂向下的原則。人

們往往喜歡先在一個較高的抽象層次上工作，如果

在思考過程中突然想到一個具體事物，就會把注意

力轉移到深入分析發掘這個具體領域，然后又返回

到原先所在的較高的抽象層次。例如，分析員找出

一個類與對象，想到在這個類中應該包含的一個服

務，于是把這個服務的名字寫在服務層，然后又返

回到類與對象層，繼續尋找問題域中的另一個類與

對象。

通常在完整地定義每個類中的服務之前，需要先建

立起動態模型和功能模型，通過對這兩種模型的研

究，能夠更正確更合理地確定每個類應該提供哪些

服務。

綜上所述，在概念上可以認為，面向對象分析大體

上按照下列順序進行：尋找類與對象，識別結構，

識別主題，定義屬性，建立動態模型，建立功能模

型，定義服務。但是，正如前面已經多次強調指出

過的，分析不可能嚴格地按照預定順序進行，大型、

復雜系統的模型需要反復構造多遍才能建成。通常,

先構造出模型的子集，然后再逐漸擴充，直到完全、

充分地理解了整個問題，才能最終把模型建立起來。

清絡文學助泌鈍盟匍制巴端，號TMMMtMM"!

分析也不是一個機械的過程。大多數需求陳述都缺

乏必要的信息，所缺少的信息主要從用戶和領域專

家那里獲取，同時也需要從分析員對問題域的背景

知識中提取。在分析過程中，系統分析員必須與領

域專家及用戶反復交流，以便澄清二義性，改正錯

誤的概念，補足缺少的信息。面向對象建立的系統

模型，盡管在最終完成之前還是不準確、不完整的,

但對做到準確、無歧義的交流仍然是大有益處的。

信華文學出朧鈍巧iSSSi；；MHBSflBSSMMMHi

10.2需求陳述

10.2.1書寫要點

通常，需求陳述的內容包括：問題范圍，功能需求,

性能需求，應用環境及假設條件等。總之，需求陳

述應該闡明“做什么”而不是“怎樣做”。它應該

描述用戶的需求而不是提出解決問題的方法。應該

指出哪些是系統必要的性質，哪些是任選的性質。

清華交學圜版社V量荷：：：：日鋤設力方用彗IMMHI

應該避免對設計策略施加過多的約束，也不要描述

系統的內部結構，因為這樣做將限制實現的靈活性。

對系統性能及系統與外界環境交互協議的描述，是

合適的需求。止匕外，對采用的軟件工程標準、模塊

構造準則、將來可能做的擴充以及可維護性要求等

方面的描述，也都是適當的需求。

書寫需求陳述時，要盡力做到語法正確，而且應該

慎重選用名詞、動詞、形容詞和同義詞。

信華文學出朧鈍巧iSSSi；；MHBSflBSSMMMHi

不少用戶書寫的需求陳述，都把實際需求和設計決

策混為一談。系統分析員必須把需求與實現策略區

分開，后者是一類偽需求，分析員至少應該認識到

它們不是問題域的本質性質。

需求陳述可簡可繁。對人們熟悉的傳統問題的陳述,

可能相當詳細，相反，對陌生領域項目的需求，開

始時可能寫不出具體細節。

清華關淳圜版社壕:金

絕大多數需求陳述都是有二義性的、不完整的、甚

至不一致的。某些需求有明顯錯誤，還有一些需求

雖然表述得很準確，但它們對系統行為存在不良影

響或者實現起來造價太高。另外一些需求初看起來

很合理，但卻并沒有真正反映用戶的需要。應該看

至U,需求陳述僅僅是理解用戶需求的出發點，它并

不是一成不變的文檔。不能指望沒有經過全面、深

入分析的需求陳述是完整、準確、有效的。隨后進

行的面向對象分析的目的，就是全面深入地理解問

題域和用戶的真實需求，建立起問題域的精確模型。

信華文學出版社饗帥盤就gg員■MMH

系統分析員必須與用戶及領域專家密切配合協同工

作，共同提煉和整理用戶需求。在這個過程中，很

可能需要快速建立起原型系統，以便與用戶更有效

地交流。

信絡文學出瓶社■，勺

^^7「J,FTy、丁尸*?}《，>公？f/r**：p\fiq)>17r^17

10.2.2例子

圖10.2所示的自動取款機(ATM)系統，是本書講述

面向對象分析和面向對象設計時使用的一個實例。

某銀行擬開發一個自動取款機系統，它是一個由自

動取款機、中央計算機、分行計算機及柜員終端組

成的網絡系統。ATM和中央計算機由總行投資購

買。總行擁有多臺ATM,分別設在全市各主要街

道上。分行負責提供分行計算機和柜員終端。柜員

終端設在分行營業廳及分行下屬的各個儲蓄所內。

該系統的軟件開發成本由各個分行分攤。

高華十字出版社

圖10.2ATM系統

清華無字圜版卷黑金照制!盤

銀行柜員使用柜員終端處理儲戶提交的儲蓄事務。

儲戶可以用現金或支票向自己擁有的某個賬戶內存

款或開新賬戶。儲戶也可以從自己的賬戶中取款。

通常，一個儲戶可能擁有多個賬戶。柜員負責把儲

戶提交的存款或取款事務輸進柜員終端，接收儲戶

交來的現金或支票，或付給儲戶現金。柜員終端與

相應的分行計算機通信，分行計算機具體處理針對

某個賬戶的事務并且維護賬戶。

信華文學出朧鈍巧iSSSi；；MHBSflBSSMMMHi

擁有銀行賬戶的儲戶有權申請領取現金兌換卡。使

用現金兌換卡可以通過ATM訪問自己的賬戶。目

前僅限于用現金兌換卡在ATM上提取現金（即取款）,

或查詢有關自己賬戶的信息（例如，某個指定賬戶

上的余額）。將來可能還要求使用ATM辦理轉賬、

存款等事務。

所謂現金兌換卡就是一張特制的磁卡，上面有分行

代碼和卡號。分行代碼惟一標識總行下屬的一個分

行，卡號確定了這張卡可以訪問哪些賬戶。通常，

一張卡可以訪問儲戶的若干個賬戶，但是不一定能

訪問這個儲戶的全部賬戶。每張現金兌換卡僅屬于

一個儲戶所有，但是，同一張卡可能有多個副本，

因此，必須考慮同時在若干臺ATM上使用同樣的

現金兌換卡的可能性。也就是說，系統應該能夠處

理并發的訪問。

清華夫學即該神布/時朋史卻力匕卅mtn

當用戶把現金兌換卡插入ATM之后，ATM就與用

戶交互，以獲取有關這次事務的信息，并與中央計

算機交換關于事務的信息。首先，ATM要求用戶

輸入密碼，接下來ATM把從這張卡上讀到的信息

以及用戶輸入的密碼傳給中央計算機，請求中央計

算機核對這些信息并處理這次事務。中央計算機根

據卡上的分行代碼確定這次事務與分行的對應關系,

并且委托相應的分行計算機驗證用戶密碼。如果用

戶輸入的密碼是正確的，ATM就要求用戶選擇事

務類型（取款、查詢等）。當用戶選擇取款時，ATM

請求用戶輸入取款額。最后，ATM從現金出口吐

出現金，并且打印出賬單交給用戶。

，

信華笈學出版社111

?a?*Jr-/l270.■?■"'Uf'，.y/f.,0」^pt■*■..、?『J

10.3建立對象模型

面向對象分析首要的工作，是建立問題域的對象模

型。這個模型描述了現實世界中的“類與對象”以

及它們之間的關系，表示了目標系統的靜態數據結

構。靜態數據結構對應用細節依賴較少，比較容易

確定；當用戶的需求變化時，靜態數據結構相對來

說比較穩定。因此，用面向對象方法開發絕大多數

軟件時，都首先建立對象模型，然后再建立另外兩

個子模型。

需求陳述、應用領域的專業知識以及關于客觀世界

的常識，是建立對象模型時的主要信息來源。

如前所述，對象模型通常有5個層次。典型的工作

步驟是：首先確定對象類和關聯（因為它們影響系

統整體結構和解決問題的方法），對于大型復雜問

題還要進一步劃分出若干個主題；然后給類和關聯

增添屬性，以進一步描述它們；接下來利用適當的

繼承關系進一步合并和組織類。而對類中操作的最

后確定，則需等到建立了動態模型和功能模型之后,

因為這兩個子模型更準確地描述了對類中提供的服

務的需求。

清監充學出版社,78^的助廉附賓房廿"UtH

應該再一次強調指出的是，人認識客觀世界的過程

是一個漸進過程，是在繼承前人知識的基礎上，經

反復迭代而不斷深化的。因此，面向對象分析不可

能嚴格按照順序線性進行。初始的分析模型通常都

是不準確不完整甚至包含錯誤的，必須在隨后的反

復分析中加以擴充和更正。止匕外，在面向對象分析

的每一步，都應該仔細分析研究以前針對相同的或

類似的問題域進行面向對象分析所得到的結果，并

盡可能在本項目中重用這些結果。以后在講述面向

對象分析的具體過程時，對上述內容將不再贅述。

清華交學出版社期布盤就pmH

10.3.1確定類與對象

類與對象是在問題域中客觀存在的，系統分析員的

主要任務就是通過分析找出這些類與對象。首先找

出所有候選的類與對象，然后從候選的類與對象中

篩選掉不正確的或不必要的。

L找出候選的類與對象

對象是對問題域中有意義的事物的抽象，它們既可

能是物理實體，也可能是抽象概念。具體地說，大

多數客觀事物可分為下述5類：

(i)可感知的物理實體，例如，飛機、汽車、書、

房屋等等。

(2)人或組織的角色，例如，醫生、教師、雇主、

雇員、計算機系、財務處等等。

(3)應該記憶的事件，例如，飛行、演出、訪問、

交通事故等等。

(4)兩個或多個對象的相互作用，通常具有交易或

接觸的性質，例如，購買、納稅、結婚等等。

(5)需要說明的概念，例如，政策、保險政策、版

權法等等。

在分析所面臨的問題時，可以參照上列5類常見事

物，找出在當前問題域中的候選類與對象。

清華；＞騫密版社rj或繞前須

另?種更簡單的分析方法，是所謂的非正式分析。

這種分析方法以用自然語言書寫的需求陳述為依據,

把陳述中的名詞作為類與對象的候選者，用形容詞

作為確定屬性的線索，把動詞作為服務（操作）的候

選者。當然，用這種簡單方法確定的候選者是非常

不準確的，其中往往包含大量不正確的或不必要的

事物，還必須經過更進一步的嚴格篩選。通常，非

正式分析是更詳細、更精確的正式的面向對象分析

的一個很好的開端。

下面以ATM系統為例，說明非正式分析過程。認

真閱讀1022節給出的需求陳述，從陳述中找出下

列名詞，可以把它們作為類與對象的初步的候選者:

高華尤學出瓶社蜀巖三混嬲

銀行，自動取款機(ATM),系統，中央計算機，分

行計算機，柜員終端，網絡，總行，分行，軟件，

成本，市，街道，營業廳，儲蓄所，柜員，儲戶，

現金，支票，賬戶，事務，現金兌換卡，余額，磁

卡，分行代碼，卡號，用戶，副本，信息，密碼，

類型，取款額，賬單，訪問。

通常，在需求陳述中不會一個不漏地寫出問題域中

所有有關的類與對象，因此，分析員應該根據領域

知識或常識進一步把隱含的類與對象提取出來。例

如，在ATM系統的需求陳述中雖然沒寫“通信鏈

路”和“事務日志”，但是，根據領域知識和常識

可以知道，在ATM系統中應該包含這兩個實體。

清華7'二學出版社

2.篩選出正確的類與對象

顯然，僅通過一個簡單、機械的過程不可能正確地

完成分析工作。非正式分析僅僅幫助我們找到一些

候選的類與對象，接下來應該嚴格考察每個候選對

象，從中去掉不正確的或不必要的，僅保留確實應

該記錄其信息或需要其提供服務的那些對象。

篩選時主要依據下列標準，刪除不正確或不必要的

類與對象：

如果兩個類表達了同樣的信息，則應該保留在此問

題域中最富于描述力的名稱。

以ATM系統為例，上面用非正式分析法得出了34

個候選的類，其中儲戶與用戶，現金兌換卡與磁卡

及副本分別描述了相同的兩類信息，因此，應該去

掉“用戶”、“磁卡”、“副本”等冗余的類，僅

保留“儲戶”和“現金兌換卡”這兩個類。

(2)無關

現實世界中存在許多對象，不能把它們都納入到系

統中去，僅需要把與本問題密切相關的類與對象放

進目標系統中。有些類在其他問題中可能很重要，

但與當前要解決的問題無關，同樣也應該把它們刪

掉。

以ATM系統為例，這個系統并不處理分攤軟件開

發成本的問題，而且ATM和柜員終端放置的地點

與本軟件的關系也不大。因此，應該去掉候選類

“成本”、“市”、“街道”、“營業廳”和“儲

蓄所”。

(3)籠統

在需求陳述中常常使用一些籠統的、泛指的名詞，

雖然在初步分析時把它們作為候選的類與對象列出

來了，但是，要么系統無須記憶有關它們的信息，

要么在需求陳述中有更明確更具體的名詞對應它們

所暗示的事務，因此，通常把這些籠統的或模糊的

類去掉。

以ATM系統為例，“銀行”實際指總行或分行，

“訪問”在這里實際指事務，“信息”的具體內容

在需求陳述中隨后就指明了。此外還有一些籠統含

糊的名詞。總之，在本例中應該去掉“銀行”、

“網絡”、“系統”、“軟件”、“信息”、“訪

問”等候選類。

(4)屬性

在需求陳述中有些名詞實際上描述的是其他對象的

屬性，應該把這些名詞從候選類與對象中去掉。當

然，如果某個性質具有很強的獨立性，則應把它作

為類而不是作為屬性。

在ATM系統的例子中，“現金”、“支票”、

款

取

“額”、“賬單”、“余額”、“分行代碼”、

號

卡

“”、“密碼”、“類型”等，實際上都應該

屬

為

乍

清華尤學出加啦卻彩凝品鼐|捌疑懶?扇unm

在需求陳述中有時可能使用一些既可作為名詞，又

可作為動詞的詞，應該慎重考慮它們在本問題中的

含義，以便正確地決定把它們作為類還是作為類中

定義的操作。

例如，談到電話時通常把“撥號”當作動詞，當構

造電話模型時確實應該把它作為一個操作，而不是

一個類。但是，在開發電話的自動記賬系統時，

“撥號”需要有自己的屬性（例如日期、時間、受

話地點等），因此應該把它作為一個類。總之，本

身具有屬性需獨立存在的操作，應該作為類與對象。

高華尤學出頒社—IMMMHWMIWr

在分析階段不應該過早地考慮怎樣實現目標系統。

因此，應該去掉僅和實現有關的候選的類與對象。

在設計和實現階段，這些類與對象可能是重要的，

但在分析階段過早地考慮它們反而會分散我們的注

意力。

在ATM系統的例子中，“事務日志”無非是對一

系列事務的記錄，它的確切表示方式是面向對象設

計的議題；“通信鏈路”在邏輯上是一種聯系，在

系統實現時它是關聯類的物理實現。總之，應該暫

時去掉“事務日志”和“通信鏈路”這兩個類，

在設計或實現時再考慮它們。

綜上所述，在ATM系統的例子中，經過初步篩選，

剩下下列類與對象：ATM、中央計算機、分行計

算機、柜員終端、總行、分行、柜員、儲戶、賬戶、

事務、現金兌換卡。

高華7'二學出版社

10.3.2確定關聯

多數人習慣于在初步分析確定了問題域中的類與對

象之后，接下來就分析確定類與對象之間存在的關

聯關系。當然，這樣的工作順序并不是絕對必要的。

由于在整個開發過程中面向對象概念和表示符號的

一致性，分析員在選取自己習慣的工作方式時擁有

相當大的靈活性。

信華文學出版社饗帥盤就gg員■MMH

如前所述，兩個或多個對象之間的相互依賴、相互

作用的關系就是關聯。分析確定關聯，能促使分析

員考慮問題域的邊緣情況，有助于發現那些尚未被

發現的類與對象。

在分析確定關聯的過程中，不必花過多的精力去區

分關聯和聚集。事實上，聚集不過是一種特殊的關

聯，是關聯的一個特例。

信絡尢學出瓶社

L初步確定關聯

在需求陳述中使用的描述性動詞或動詞詞組，通常

表示關聯關系。因此，在初步確定關聯時，大多數

關聯可以通過直接提取需求陳述中的動詞詞組而得

出。通過分析需求陳述，還能發現一些在陳述中隱

含的關聯。最后，分析員還應該與用戶及領域專家

討論問題域實體間的相互依賴、相互作用關系，根

據領域知識再進一步補充一些關聯。

以ATM系統為例，經過分析初步確定出下列關聯：

清華大學崗朧鈍1■葺事黨:JMSBjBBSSMMMM

(1)直接提取動詞短語得出的關

ATM、中央計算機、分行計算機及柜員終端組成

網絡。

總行擁有多臺ATM。

ATM設在主要街道上。

分行提供分行計算機和柜員終端。

柜員終端設在分行營業廳及儲蓄所內。

分行分攤軟件開發成本。

儲戶擁有賬戶。

分行計算機處理針對賬戶的事務。

分行計算機維護賬戶。

柜員終端與分行計算機通信。

柜員輸入針對賬戶的事務。

ATM與中央計算機交換關于事務的信息o

中央計算機確定事務與分行的對應關系。

ATM讀現金兌換卡。

ATM與用戶交互。

ATM吐出現金。

ATM打印賬單。

系統處理并發的訪問。

清華步學出版社防?就

(2)需求陳述中隱含的關聯

總行由各個分行組成。

分行保管賬戶。

總行擁有中央計算機。

系統維護事務日志。

系統提供必要的安全性。

儲戶擁有現金兌換卡。

(3)根據問題域知識得出的關聯

現金兌換卡訪問賬戶。

分行雇用柜員。

2.篩選

經初步分析得出的關聯只能作為候選的關聯，還需

經過進一步篩選，以去掉不正確的或不必要的關聯。

篩選時主要根據下述標準刪除候選的關聯：

(1)已刪去的類之間的關聯

如果在分析確定類與對象的過程中已經刪掉了某個

候選類，則與這個類有關的關聯也應該刪去，或用

其他類重新表達這個關聯。

以ATM系統為例，由于已經刪去了“系統”、

“網絡”、“市”、“街道”、“成本”、“軟

件”、“事務日志”、“現金”、“營業廳”、

“儲蓄所”、“賬單”等候選類，因此，與這些類

有關的下列8個關聯也應該刪去：

①ATM、中央計算機、分行計算機及柜員終端組

成網絡。

②ATM設在主要街道上。

③分行分攤軟件開發成本。

④系統提供必要的安全性。

⑤系統維護事務日志。

⑥ATM吐出現金。

⑦ATM打印賬單。

⑧柜員終端設在分行營業廳及儲蓄所內。

(2)與問題無關的或應在實現階段考慮的關聯

應該把處在本問題域之外的關聯或與實現密切相關

的關聯刪去。

例如，在ATM系統的例子中，“系統處理并發的

訪問”并沒有標明對象之間的新關聯，它只不過提

醒我們在實現階段需要使用實現并發訪問的算法，

以處理并發事務。

(3)瞬時事件

關聯應該描述問題域的靜態結構，而不應該是一個

瞬時事件。

以ATM系統為例，“ATM讀現金兌換卡”描述了

ATM與用戶交互周期中的一個動作，它并不是

ATM與現金兌換卡之間的固有關系，因此應該刪

去。類似地，還應該刪去“ATM與用戶交互”這

個候選的關聯。

如果用動作表述的需求隱含了問題域的某種基本結

構，則應該用適當的動詞詞組重新表示這個關聯。

例如，在ATM系統的需求陳述中，“中央計算機

確定事務與分行的對應關系”隱含了結構上“中央

計算機與分行通信”的關系。

(4)三元關聯

三個或三個以上對象之間的關聯，大多可以分解為

二元關聯或用詞組描述成限定的關聯。

在ATM系統的例子中，“柜員輸入針對賬戶的事

務”可以分解成“柜員輸入事務”和“事務修改賬

戶”這樣兩個二元關聯。而“分行計算機處理針對

賬戶的事務”也可以做類似的分解。“ATM與中

央計算機交換關于事務的信息”這個候選的關聯，

實際上隱含了“ATM與中央計算機通信”利“在

ATM上輸入事務”這兩個二元關聯。

J,-J?J-I??j4'JI?-11J.?r?**~j?~

應該去掉那些可以用其他關聯定義的冗余關聯。

例如，在ATM系統的例子中，“總行擁有多臺

ATM”實質上是“總行擁有中央計算機”和“ATM

與中央計算機通信”這兩個關聯組合的結果。而

“分行計算機維護賬戶”的實際含義是“分行保管

賬戶”和“事務修改賬戶”。

3.進一步完善

應該進一步完善經篩選后余下的關聯，通常從下述

幾個方面進行改進：

(1)正名

好的名字是幫助讀者理解的關鍵因素之一。因此，

應該仔細選擇含義更明確的名字作為關聯名。

例如，”分行提供分行計算機和柜員終端”不如改

為“分行擁有分行計算機”和“分行擁有柜員終

端”。

⑵分解

為了能夠適用于不同的關聯，必要時應該分解以前

確定的類與對象。

例如，在ATM系統中，應該把“事務”分解成

“遠程事務”和“柜員事務”。

⑶補充

發現了遺漏的關聯就應該及時補上。

例如，在ATM系統中把“事務”分解成上述兩類

之后，需要補充“柜員輸入柜員事務”、“柜員事

務輸進柜員終端”、“在ATM上輸入遠程事務”

和“遠程事務由現金兌換卡授權”等關聯。

(4)標明重數

應該初步判定各個關聯的類型，并粗略地確定關聯

的重數。但是，無須為此花費過多精力，因為在分

析過程中隨著認識的逐漸深入，重數也會經常改動。

圖10.3是經上述分析過程之后得出的ATM系統原始

的類圖。

高學力學出版社

fSSi

分行＜組成保管A1+1+

擁

總行分行賬戶有儲戶

代碼

雇

用▲

▲1+

擁有擁有修

修

+改擁

改有

員

中央通信A1+分行巨

?訪問

計算機計算機

輸

擁有

信

通

通▼▼入

信▼+

!+1+1+

+柜員

柜員

務

事

輸

終端入

1+1+1+

1+1

輸入遠程現金

ATM事務+兌換卡

?授權

圖10.3ATM系統原始的類圖

清華文學出朧他巧第8冊;：盟誠藥力方

10.3.3劃分主題

在開發大型、復雜系統的過程中，為了降低復雜程

度，人們習慣于把系統再進一步劃分成幾個不同的

主題，也就是在概念上把系統包含的內容分解成若

干個范疇。

在開發很小的系統時，可能根本無須引入主題層；

對于含有較多對象的系統，則往往先識別出類與對

象和關聯，然后劃分主題，并用它作為指導開發者

和用戶觀察整個模型的一種機制；對于規模極大的

系統，則首先由高級分析員粗略地識別對象和關聯,

然后初步劃分主題，經進一步分析，對系統結構有

更深入的了解之后，再進一步修改和精煉主題。

）?-J?J./■_^/??/?*??J./-''j-J.?*r**'j*-^z*■

應該按問題領域而不是用功能分解方法來確定主題。

止匕外，應該按照使不同主題內的對象相互間依賴和

交互最少的原則來確定主題。

以ATM系統為例，可以把它劃分成總行（包含總

行和中央計算機這兩個類）、分行（包含分行、分

行計算機、柜員終端、柜員事務、柜員和賬戶等類）

和ATM（包含ATM、遠程事務、現金兌換卡和儲

戶等類）等3個主題。事實上，我們描述的是一個

簡化的ATM系統，為了簡單起見，在下面討論這

個例子時將忽略主題層。

清華交學出版社期布盤就pmH

10.3.4確定屬性

屬性是對象的性質，藉助于屬性我們能對類與對象

和結構有更深入更具體的認識。注意，在分析階段

不要用屬性來表示對象間的關系，使用關聯能夠表

示兩個對象間的任何關系，而且把關系表示得更清

晰、更醒目。

一般說來，確定屬性的過程包括分析和選擇兩個步

驟。

1.分析

通常，在需求陳述中用名詞詞組表示屬性，例如，

“汽車的顏色”或“光標的位置”。往往用形容詞

表示可枚舉的具體屬性，例如，“紅色的”、“打

開的”。但是，不可能在需求陳述中找到所有屬性,

分析員還必須藉助于領域知識和常識才能分析得出

需要的屬性。幸運的是，屬性對問題域的基本結構

影響很小。隨著時間的推移，問題域中的類始終保

持穩定，屬性卻可能改變了，相應地，類中方法的

復雜程度也將改變。

清監充學出版社,78^的助廉附賓房廿"UtH

屬性的確定既與問題域有關，也和目標系統的任務

有關。應該僅考慮與具體應用直接相關的屬性，不

要考慮那些超出所要解決的問題范圍的屬性。在分

析過程中應該首先找出最重要的屬性，以后再逐漸

把其余屬性增添進去。在分析階段不要考慮那些純

粹用于實現的屬性。

2.選擇

認真考察經初步分析而確定下來的那些屬性，從中

刪掉不正確的或不必要的屬性。通常有以下幾種常

見情況：

清華亍:學出瓶社'加忠思母醐制京猱的

J?-J"——J?'J，，'JI-''一，1.J,?^1*'?'J*~^~~'

(1)誤把對象當作屬性

如果某個實體的獨立存在比它的值更重要，則應把

它作為一個對象而不是對象的屬性。在具體應用領

域中具有自身性質的實體，必然是對象。同一個實

體在不同應用領域中，到底應該作為對象還是屬性,

需要具體分析才能確定。例如，在郵政目錄中，

“城市”是一個屬性，而在人口普查中卻應該把

“城市”當作對象。

(2)誤把關聯類的屬性當作一般對象的屬性

如果某個性質依賴于某個關聯鏈的存在，則該性質

是關聯類的屬性，在分析階段不應該把它作為一般

對象的屬性。特別是在多對多關聯中，關聯類屬性

很明顯，即使在以后的開發階段中，也不能把它歸

并成相互關聯的兩個對象中任一個的屬性。

(3)把限定誤當成屬性

正如942節所述，正確使用限定詞往往可以減少關

聯的重數。如果把某個屬性值固定下來以后能減少

關聯的重數，則應該考慮把這個屬性重新表述成一

個限定詞。在ATM系統的例子中，“分行代碼”、

“賬號”、“雇員號”、“站號”等都是限定詞。

j?二J?j-I',?j■‘_*/，:j'/-''一，j.J..*i**?y*?~

(4)誤把內部狀態當成了屬性

如果某個性質是對象的非公開的內部狀態，則應該

從對象模型中刪掉這個屬性。

(5)過于細化

在分析階段應該忽略那些對大多數操作都沒有影響

的屬性。

(6)存在不一致的屬性

類應該是簡單而且一致的。如果得出一些看起來與

其他屬性毫不相關的屬性，則應該考慮把該類分解

成兩個不同的類。

經過篩選之后，得到ATM系統中各個類的屬性，

如圖10.4(見書235頁)所示。

高華:字出版社

10.3.5識別繼承關系

確定了類中應該定義的屬性之后，就可以利用繼承

機制共享公共性質，并對系統中眾多的類加以組織。

正如以前曾經強調指出過的，繼承關系的建立實質

上是知識抽取過程，它應該反映出一定深度的領域

知識，因此必須有領域專家密切配合才能完成。通

常，許多歸納關系都是根據客觀世界現有的分類模

式建立起來的，只要可能，就應該使用現有的概念。

一般說來，可以使用兩種方式建立繼承（即泛化）關

系：

（1）自底向上：抽象出現有類的共同性質泛化出父

類，這個過程實質上模擬了人類歸納思維過程。例

如，在ATM系統中，“遠程事務”和“柜員事務”

是類似的，可以泛化出父類“事務”；類似地，可

以從“ATM”和“柜員終端”泛化出父類“輸入

站”。

清將大學出朧濁

)?二J??./■'J.，，'J-/-''-，1?J.?*/??.J。-竺~

(2)自頂向下：把現有類細化成更具體的子類，這

模擬了人類的演繹思維過程。從應用域中常常能明

顯看出應該做的自頂向下的具體化工作。例如，帶

有形容詞修飾的名詞詞組往往喑示了一些具體類。

但是，在分析階段應該避免過度細化。

利用多重繼承可以提高共享程度，但是同時也增加

了概念上以及實現時的復雜程度。使用多重繼承機

制時，通常應該指定一個主要父類，從它繼承大部

分屬性和行為；次要父類只補充一些屬性和行為。

圖10.5(見書237頁)是增加了繼承關系之后的

ATM對象模型。

高華宛學出版社

10.3.6反復修改

僅僅經過一次建模過程很難得到完全正確的對象模

型。事實上，軟件開發過程就是一個多次反復修改、

逐步完善的過程。在建模的任何一個步驟中，如果

發現了模型的缺陷，都必須返回到前期階段進行修

改。由于面向對象的概念和符號在整個開發過程中

都是一致的，因此遠比使用結構分析、設計技術更

容易實現反復修改、逐步完善的過程。

實際上，有些細化工作（例如，定義服務）是在建立

了動態模型和功能模型之后才進行的。

清華夫學即該神布/時朋史卻力匕卅mtn

在實際工作中，建模的步驟并不一定嚴格按照前面

講述的次序進行。分析員可以合并幾個步驟的工作

放在一起完成，也可以按照自己的習慣交換前述各

項工作的次序，還可以先初步完成幾項工作，再返

回來加以完善。但是，如果你是初次接觸面向對象

方法，則最好先按本書所述次序，嘗試用面向對象

方法，開發幾個較小的系統，取得一些實踐經驗后,

再總結出更適合自己的工作方式。

下面以ATM系統為例，討論可能做的修改：

信絡尢學出瓶社

1.分解“現金兌換卡”類

實際上，“現金兌換卡”有兩個相對獨立的功能，

它既是鑒別儲戶使用ATM的權限的卡，又是ATM

獲得分行代碼和卡號等數據的數據載體。因此，把

“現金兌換卡”類分解為“卡權限”和“現金兌換

卡”兩個類，將使每個類的功能更單一：前一個類

標志儲戶訪問賬戶的權限，后一個類是含有分行代

碼和卡號的數據載體。多張現金兌換卡可能對應著

相同的訪問權限。

廣，？'ff「J/FT：'y."/?<Uf.1.Vr/r?voJr>?ir/1?Jj?.i*G?

2.“事務”由“更新”組成

通常，一個事務包含對賬戶的若干次更新，這里所

說的更新，指的是對賬戶所做的一個動作（取款、

存款或查詢）。“更新”雖然代表一個動作，但是

它有自己的屬性（類型、金額等），應該獨立存在，

因此應該把它作為類。

3.把“分行”與“分行計算機”合并

區分“分行”與“分行計算機”，對于分析這個系

統來說，并沒有多大意義，為簡單起見，應該把它

們合并。類似地，應該合并“總行”和“中央計算

機”。

圖10.6（見書238頁）給出了修改后的ATM對象模

型，與修改前比較起來，它更簡單、更清晰。

清華十字出版社

10.4建立動態模型

本書9.5節和3?6節已經介紹了動態模型的概念和表

示方法，本節結合ATM系統的實例，進一步講述

建立動態模型的方法。

對于僅存儲靜態數據的系統（例如數據庫）來說，動

態模型并沒有什么意義。然而在開發交互式系統時,

動態模型卻起著很重要的作用。如果收集輸入信息

是目標系統的一項主要工作，則在開發這類應用系

統時建立正確的動態模型是至關重要的。

奇華文學出版社段金鬣嬲莖旖廿”—MMI

建立動態模型的第一步，是編寫典型交互行為的腳

本。雖然腳本中不可能包括每個偶然事件，但是，

至少必須保證不遺漏常見的交互行為。第二步，從

腳本中提取出事件，確定觸發每個事件的動作對象

以及接受事件的目標對象。第三步，排列事件發生

的次序，確定每個對象可能有的狀態及狀態間的轉

換關系，并用狀態圖描繪它們。最后，比較各個對

象的狀態圖，檢查它們之間的一致性，確保事件之

間的匹配。

清華十字出版社

10.4.1編寫腳本

所謂“腳本”，原意是指“表演戲曲、話劇，拍攝

電影、電視劇等所依據的本子，里面記載臺詞、故

事情節等”。在建立動態模型的過程中，腳本是指

系統在某一執行期間內出現的一系列事件。腳本描

述用戶（或其他外部設備）與B標系統之間的一個或

多個典型的交互過程，以便對目標系統的行為有更

具體的認識。編寫腳本的目的，是保證不遺漏重要

的交互步驟，它有助于確保整個交互過程的正確性

的和清晰性。

信衫大學出版社三fl

J?-J?J-I'?Ji'J!-''，J.'J.?J?'?'J??

腳本描寫的范圍并不是固定的，既可以包括系統中

發生的全部事件，也可以只包括由某些特定對象觸

發的事件。腳本描寫的范圍主要由編寫腳本的具體

目的決定。

即使在需求陳述中已經描寫了完整的交互過程，也

還需要花很大精力構思交互的形式。例如，ATM

系統的需求陳述，雖然表明了應從儲戶那里獲取有

關事務的信息，但并沒有準確說明獲取信息的具體

過程，對動作次序的要求也是模糊的。因此，編寫

腳本的過程，實質上就是分析用戶對系統交互行為

的要求的過程。在編寫腳本的過程中，需要與用戶

充分交換意見，編寫后還應該經過他們審查與修改。

編寫腳本時，首先編寫正常情況的腳本。然后，考

慮特殊情況，例如輸入或輸出的數據為最大值（或

最小值）。最后，考慮出錯情況，例如，輸入的值

為非法值或響應失敗。對大多數交互式系統來說，

出錯處理都是最難實現的部分。如果可能，應該允

許用戶“異常中止”一個操作或“取消”一個操作。

止匕外，還應該提供諸如“幫助”和狀態查詢之類的

在基本交互行為之上的“通用”交互行為。

高華尤學出版社—ISWMMWMIMr

腳本描述事件序列。每當系統中的對象與用戶（或

其他外部設備）交換信息時，就發生一個事件。所

交換的信息值就是該事件的參數（例如，“輸入密

碼”事件的參數是所輸入的密碼）。也有許多事件

是無參數的，這樣的事件僅傳遞一個信息—該事

件已經發生了。

對于每個事件，都應該指明觸發該事件的動作對象

（例如，系統、用戶或其他外部事物）、接受事件的

目標對象以及該事件的參數。

表10.1和表10.2（見書240頁）分別給出了ATM系

統的正常情況腳本和異常情況腳本。

清絡為學跚婿虢（二；時珈盤序

10.4.2設想用戶界面

大多數交互行為都可以分為應用邏輯和用戶界面兩

部分。通常，系統分析員首先集中精力考慮系統的

信息流和控制流，而不是首先考慮用戶界面。事實

上，采用不同界面（例如，命令行或圖形用戶界面）,

可以實現同樣的程序邏輯。應用邏輯是內在的、本

質的內容，用戶界面是外在的表現形式。動態模型

著重表示應用系統的控制邏輯。

清筠大學出版艇—量葡制

但是，用戶界面的美觀程度、方便程度、易學程度

以及效率等等，是用戶使用系統時最先感受到的，

用戶對系統的“第一印象”往往從界面得來，用戶

界面的好壞往往對用戶是否喜歡、是否接受一個系

統起很重要的作用。因此，在分析階段也不能完全

忽略用戶界面。在這個階段用戶界面的細節并不太

重要，重要的是在這種界面下的信息交換方式。我

們的目的是確保能夠完成全部必要的信息交換，而

不會丟失重要的信息。

不經過實際使用很難評價一個用戶界面的優劣，因

止匕，軟件開發人員往往快速地建立起用戶界面的原

型，供用戶試用與評價。圖10.7是初步設想出的

ATM界面格式。

猾華大學出版社

向儲戶顯示的信息

raESES

回回⑦國.

|ENTER||CLEAR|〔CANCEL

賬單出口現金出口

圖10.7ATM的界面格式

10.4.3畫事件跟蹤圖

完整、正確的腳本為建立動態模型奠定了必要的基

礎。但是，用自然語言書寫的腳本往往不夠簡明，

而且有時在閱讀時會有二義性。為了有助于建立動

態模型，通常在畫狀態圖之前先畫出事件跟蹤圖。

為此首先需要進一步明確事件及事件與對象的關系。

1.確定事件

應該仔細分析每個腳本，以便從中提取出所有外部

事件。事件包括系統與用戶（或外部設備）交互的所

有信號、輸入、輸出、中斷、動作等等。從腳本中

容易找出正常事件，但是，應該小心仔細，不要遺

漏了異常事件和出錯條件。

傳遞信息的對象的動作也是事件。例如，儲戶插入

現金兌換卡、儲戶輸入密碼、ATM吐出現金等都

是事件。大多數對象到對象的交互行為都對應著事

件。

J?-J?J-I'?'J，，'）./a*~JJ.'J.?**i??J*?"

應該把對控制流產生相同效果的那些事件組合在一

起作為一類事件，并給它們取一個惟一的名字。例

如，“吐出現金”是一個事件類，盡管這類事件中

的每個個別事件的參數值不同（吐出的現金數額不

同），然而這并不影響控制流。但是，應該把對控

制流有不同影響的那些事件區分開來，不要誤把它

們組合在一起。例如“賬戶有效”、“賬戶無效”、

“密碼錯”等都是不同的事件。一般說來，不同應

用系統對相同事件的響應并不相同，因此，在最終

分類所有事件之前，必須先畫出狀態圖。如果從狀

態圖中看出某些事件之間的差異對系統行為并沒有

影響，則可以忽略這些事件間的差異。

經過分析，應該區分出每類事件的發送對象和接受

對象。一類事件相對它的發送對象來說是輸出事件,

但是相對它的接受對象來說則是輸入事件。有時一

個對象把事件發送給自己，在這種情況下，該事件

既是輸出事件又是輸入事件。

2.畫出事件跟蹤圖

從腳本中提取出各類事件并確定了每類事件的發送

對象和接受對象之后，就可以用事件跟蹤圖把事件

序列以及事件與對象的關系，形象、清晰地表示出

來。事件跟蹤圖實質上是擴充的腳本，可以認為事

件跟蹤圖是簡化的UML順序圖。

清華文學出版社廉!刪嵐旖S鬟MMMHI

在事件跟蹤圖中，一條豎線代表一個對象，每個事

件用一條水平的箭頭線表示，箭頭方向從事件的發

送對象指向接受對象。時間從上向下遞增，也就是

說，畫在最上面的水平箭頭線代表最先發生的事件,

畫在最下面的水平箭頭線所代表的事件最晚發生。

箭頭線之間的間距并沒有具體含義，圖中僅用箭頭

線在垂直方向上的相對位置表示事件發生的先后，

并不表示兩個事件之間的精確時間差。

圖10.8（見書242頁）是ATM系統正常情況下的事

件跟蹤圖。

清華之學出瓶泡靦胡昌馬麗翳氮

10.4.4畫狀態圖

狀態圖描繪事件與對象狀態的關系。當對象接受了

一個事件以后，它的下個狀態取決于當前狀態及所

接受的事件。由事件引起的狀態改變稱為“轉換”。

如果一個事件并不引起當前狀態發生轉換，則可忽

略這個事件。

通常，用一張狀態圖描繪一類對象的行為，它確定

了由事件序列引出的狀態序列。但是，也不是任何

一個類都需要有一張狀態圖描繪它的行為。很多對

象僅響應與過去歷史無關的那些輸入事件，或者把

歷史作為不影響控制流的參數。對于這類對象來說,

狀態圖是不必要的。系統分析員應該集中精力僅考

慮具有重要交互行為的那些類。

高華十字

從一張事件跟蹤圖出發畫狀態圖時，應該集中精力

僅考慮影響一類對象的事件，也就是說，僅考慮事

件跟蹤圖中指向某條豎線的那些箭頭線。把這些事

件作為狀態圖中的有向邊（即箭頭線），邊上標以事

件名。兩個事件之間的間隔就是一個狀態。一般說

來，如果同一個對象對相同事件的響應不同，則這

個對象處在不同狀態。應該盡量給每個狀態取個有

意義的名字。通常，從事件跟蹤圖中當前考慮的豎

線射出的箭頭線，是這條豎線代表的對象達到某個

狀態時所做的行為（往往是引起另一類對象狀態轉

換的事件）。

根據一張事件跟蹤圖畫出狀態圖之后，再把其他腳

本的事件跟蹤圖合并到已畫出的狀態圖中。為此需

在事件跟蹤圖中找出以前考慮過的腳本的分支點

（例如“驗證賬戶”就是一個分支點，因為驗證的

結果可能是“賬戶有效”，也可能是“無效賬

戶”），然后把其他腳本中的事件序列并入已有的

狀態圖中，作為一條可選的路徑。

清華大學出血泡士

J*7-**??-I''Jt'Ji-''-，1_J.?*/?"<j*~^'

考慮完正常事件之后再考慮邊界情況和特殊情況，

其中包括在不適當時候發生的事件（例如，系統正

在處理某個事務時，用戶要求取消該事務）。有時

用戶（或外部設備）不能做出快速響應，然而某些資

源又必須及時收回，于是在一定間隔后就產生了

“超時”事件。對用戶出錯情況往往需要花費很多

精力處理，并且會使原來清晰、緊湊的程序結構變

得復雜、繁瑣，但是，出錯處理是不能省略的。

清華亍:學出頒社刪幻肅赫那已燃至殳UMH

).二J??-I','J?*4'Ji-''J■'J'?*I?'?J*

當狀態圖覆蓋了所有腳本，包含了影響某類對象狀

態的全部事件時，該類的狀態圖就構造出來了。利

用這張狀態圖可能會發現一些遺漏的情況。測試完

整性和出錯處理能力的最好方法，是設想各種可能

出現的情況，多問幾個“如果……，則……”的問

題。

以ATM系統為例。“ATM”、“柜員終端”、“總

行”和“分行”都是主動對象，它們相互發送事件;

而“現金兌換卡”、“事務”和“賬戶”是被動對

象，并不發送事件。“儲戶”和“柜員”雖然也是

動作對象，但是，它們都是系統外部的因素，無須

在系統內實現它們。因此，只需要考慮“ATM”、

“總行”、“柜員終端”和“分行”的狀態圖。

圖10.9（見書243頁），圖10.10和圖10.11分別是

“ATM”、“總行”和“分行”的狀態圖。由于

“柜員終端”的狀態圖和“ATM”的狀態圖類似，

為節省篇幅把它省略了。這些狀態圖都是簡化的，

尤其對異常情況和出錯情況的考慮是相當粗略的

（例如，圖10.9并沒有表示在網絡通信鏈路不通時的

系統行為，實際上，在這種情況下ATM停止處理

儲戶事務）。

清華十字出版社

處理事務驗證賬戶

Jdo/驗;分行\［無效代用］

/do/請求處理分行

I代碼J

分

分

［有效代碼］

行

行

事

事/------------、無效賬戶

務

務do/請求分行驗卡密碼錯:

失

成

敗

V功］賬戶7效

?)

圖10.10總行類的狀態圖

清華十學出版得

T摩裝1請求分行驗卡

U分仃事務u

<A，\［無效］

（do/更新賬戶｝（do/驗證卡號）

［有效］

［失敗］［成功］（------------\伊

（do/驗證密碼）-------

|||［正—

圖10.11分行類的狀態圖

猾華十字出版社

10.4.5審查動態模型

各個類的狀態圖通過共享事件合并起來，構成了系

統的動態模型。在完成了每個具有重要交互行為的

類的狀態圖之后，應該檢查系統級的完整性和一致

性。一般說來，每個事件都應該既有發送對象又有

接受對象，當然，有時發送者和接受者是同一個對

象。對于沒有前驅或沒有后繼的狀態應該著重審查,

如果這個狀態既不是交互序列的起點也不是終點，

則發現了一個錯誤。

鬲柜大學出版泡黑宗菊刪發房廣上?MMH

應該審查每個事件，跟蹤它對系統中各個對象所產

生的效果，以保證它們與每個腳本都匹配。

以ATM系統為例。在總行類的狀態圖中，事件

“分行代碼錯”是由總行發出的，但是在ATM類

的狀態圖中并沒有一個狀態接受這個事件。因此，

在ATM類的狀態圖中應該再補充一個狀態“do/顯

示分行代碼錯信息”，它接受由前驅狀態“do/驗

證賬戶”發出的事件“分行代碼錯”，它的后續狀

態是“退卡”。

清華文學出瓶社部1信舄

?A~tI「口/L*\；lr??'?）|，aa?'c:?■>?<：?'，.,r,—「？.i上j、、fj

10.5建立功能模型

功能模型表明了系統中數據之間的依賴關系，以及

有關的數據處理功能，它由一組數據流圖組成。其

中的處理功能可以用IPO圖（或表）、偽碼等多種方

式進一步描述。

通常在建立了對象模型和動態模型之后再建立功能

模型。

本書第2章已經詳細講述了畫數據流圖的方法，本

節結合ATM系統的例子，再復習一遍有關數據流

圖的概念和畫法。

高華9,二學出版社

10.5.1畫出基本系統模型圖

基本系統模型由若干個數據源點/終點，及一個處

理框組成，這個處理框代表了系統加工、變換數據

的整體功能。基本系統模型指明了目標系統的邊界。

由數據源點輸