東北大學(xué)軟件工程期末復(fù)習(xí)資料

考點(diǎn):

1.什么是軟件，包括什么

2.程序，文檔，數(shù)據(jù)是什么

3.軟件類型（兩種）

4.*軟件特點(diǎn)

5.軟件危機(jī)（定義）

6.軟件工程（定義），關(guān)注質(zhì)量，成本

7.什么是軟件生命周期

8.什么是軟件過程模型

9.用例是什么的縮寫，是什么

10.描述一個(gè)案例，用什么模型

H.需求的重要性

12.軟件需求是什么

13.需求工程是什么

14.需求獲取的目的

6需求獲取的手段

16.需求分析

17.數(shù)據(jù)字典流圖不考

18.是什么

19.給一個(gè)例子，說明缺陷

20.需求驗(yàn)證和管理（了解）

21.面向?qū)ο蟮臍v史

22.對(duì)象，類，消息，繼承是什么

23.對(duì)象與類的關(guān)系

24.軟件建模

25.是什么的縮寫

26.關(guān)聯(lián)關(guān)系多重性

27.視角

28.面向?qū)ο蠓治鍪鞘裁?/p>

29.面向?qū)ο蠓治鼋?/p>

30.面向?qū)ο蠓治鲇美?/p>

31.用例是什么，關(guān)系，特點(diǎn)

32.用例描述

33.分析類是什么

34.畫類圖

35.包是什么

36.包中有什么

37.包之間的關(guān)系

38.動(dòng)態(tài)建模

39.狀態(tài)圖

40.類圖測(cè)試

41.迭代是軟件產(chǎn)品內(nèi)部特點(diǎn)

42.什么是面向?qū)ο笤O(shè)計(jì)

43.設(shè)計(jì)的原則

44.*模塊，耦合，內(nèi)聚

45.軟件復(fù)用

46.什么是軟件體系結(jié)構(gòu)

47.典型的體系結(jié)構(gòu)風(fēng)格

48.*順序圖，協(xié)作圖

49.問某個(gè)方法是哪個(gè)對(duì)象的方法

50.偽碼

51.數(shù)據(jù)庫(kù)設(shè)計(jì)（了解）

52.用戶界面設(shè)計(jì)

53.*實(shí)現(xiàn)與集成

54.編程與編碼的區(qū)別

55.編程語(yǔ)言

56.怎么選擇合適的編程語(yǔ)言

57編碼規(guī)范，包括哪些

58.*維護(hù)的類型

59.軟件測(cè)試

60.軟件質(zhì)量，軟件質(zhì)量保證

61.軟件測(cè)試類型

.?

1.軟件定義

■*軟件的定義（牢記）

?0在運(yùn)行中提供所希望的功能和性能的指令集（即程序）

程序

?編程語(yǔ)言描述的一系列語(yǔ)句序列

?提供需要的功能和性能

數(shù)據(jù)

?使程序能方便的操縱信息

文檔

?描述程序研制過程和方法，操作和使用方法的文檔

■軟件的類型（兩種）

?一般軟件

直接提供給市場(chǎng)，或供多個(gè)用戶使用

?定制軟件

受某個(gè)客戶委托，一個(gè)或多個(gè)軟件開發(fā)機(jī)構(gòu)為其開發(fā)的軟件

■*軟件的特點(diǎn)（牢記）

?,?邏輯產(chǎn)品，非物質(zhì)的

?.不會(huì)磨損

?,開發(fā)出來，而非制造

.大部分是定制的

?'質(zhì)量依賴于開發(fā)人員的素質(zhì)

?昂貴

?.難以維護(hù)

2.軟件危機(jī)（定義）

落后的軟件生產(chǎn)方式無法滿足迅速增長(zhǎng)的計(jì)算機(jī)軟件需求，從而導(dǎo)致

軟件開發(fā)與維護(hù)過程中出現(xiàn)一系列嚴(yán)重問題的現(xiàn)象。

主要是三個(gè)個(gè)方面的問題：

?軟件的質(zhì)量低，難以滿足需求

?對(duì)軟件開發(fā)時(shí)間和成本的估計(jì)不足

?如何維護(hù)軟件——數(shù)量不斷膨脹的已有軟件，不斷變化的用戶需求

1-定義

1.軟件工程（定義）

是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的工程學(xué)科。采用工程的概念、原理、

技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和

當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，這就是軟件工程。

2.軟件工程的關(guān)注（質(zhì)量，成本）

?軟件質(zhì)量

軟件需要一些屬性來反應(yīng)他的質(zhì)量

■可維護(hù)性：適應(yīng)用戶的需求變化

■可靠性：可依靠，安全的

■效率：不浪費(fèi)內(nèi)存和

■可接受性：方便適用

?軟件成本

用于開發(fā)和維護(hù)

2.主要元素

①過程：軟件工程的基礎(chǔ)

②方法：提供建造軟件的技術(shù)

③_E具：提供自動(dòng)化或半自動(dòng)化手段來支持過程和方法

3.目標(biāo)

滿足用戶的需求，同時(shí)提高性能，成本和質(zhì)量

二：

一、軟件生命周期

I.*生命周期：一個(gè)軟件從定義、開發(fā)、使用、和維護(hù)，直到最終被廢棄

要經(jīng)歷一個(gè)漫長(zhǎng)的時(shí)期，這個(gè)時(shí)期稱為生命周期。

2.生命周期涵蓋一系列的階段:

?需求分析

?概要設(shè)計(jì)

?細(xì)節(jié)設(shè)計(jì)

?實(shí)現(xiàn)

?集成

?維護(hù)

?退休

1.軟件過程

是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完

成各項(xiàng)任務(wù)的工作步驟

2.典型軟件過程模型

?瀑布模型

瀑布模型特點(diǎn):

＞階段間具有順序性和依賴性

＞每個(gè)階段必須完成規(guī)定的文檔;每個(gè)階段結(jié)束前完成文檔審查，與早

改正錯(cuò)誤，但：

。開發(fā)過程一般不能逆轉(zhuǎn)，否則代價(jià)太大。

實(shí)際的項(xiàng)目開發(fā)很難嚴(yán)格按該模型進(jìn)行。

?？蛻敉茈y清楚地給出所有的需求，而該模型卻要求如此。

應(yīng)用范圍：

＞軟件的實(shí)際情況必須到項(xiàng)目開發(fā)的后期客戶才能看到，這要求客戶

有足夠的耐心。

＞用戶的需求非常清楚全面，且在開發(fā)過程中沒有或很少變化

＞開發(fā)人員對(duì)軟件的應(yīng)用領(lǐng)域很熟悉。

＞用戶的使用環(huán)境非常穩(wěn)定。

＞開發(fā)工作對(duì)用戶參與的要求很低

?快速原型模型

基本是首先建立一個(gè)能夠反映用戶主要需求的原型系統(tǒng)讓用戶在計(jì)算

機(jī)上運(yùn)行、試用這個(gè)原型系統(tǒng)，通過與原型交互與早發(fā)現(xiàn)需求的缺陷;

設(shè)計(jì)人員也可檢查設(shè)計(jì)的可行性。

結(jié)束

原型可以利用第四代語(yǔ)言面向?qū)ο蟮膽?yīng)用程序框架，原型開發(fā)活動(dòng)、

用戶反饋、開發(fā)者修改原型的重復(fù)迭代過程可提高用戶滿意程度，也可縮

短軟件開發(fā)周期，從而降低了開發(fā)和維護(hù)成本。

在該模型中，如何快速進(jìn)行原型的開發(fā)是關(guān)鍵，快速開發(fā)原型的途徑

一般可以有三種：

利用計(jì)算機(jī)模擬一個(gè)軟件的人機(jī)界面與交互方式。

開發(fā)一個(gè)能實(shí)現(xiàn)部分功能（如輸入界面、輸出格式等）的軟件，這部分功

能往往是重要的，但也可能是容易引起誤解的。

尋找一個(gè)或幾個(gè)類似的正在運(yùn)行的軟件，利用這些軟件向客戶展示軟

件需求中的部分或全部功能。

為了快速地開發(fā)原型，要盡量采用軟件重用技術(shù)，以爭(zhēng)取時(shí)間，盡快

地向客戶提供原型。

()特點(diǎn)

?該模型是基于原型驅(qū)動(dòng)的。

?可以得到比較良好的需求定義，便于開發(fā)者與客戶進(jìn)行全面的溝通

與交流。而且原型系統(tǒng)也比較容易適應(yīng)用戶需求的變化。

?原型系統(tǒng)既是開發(fā)的原型，又可以作為培訓(xùn)的環(huán)境，這樣有利于開

發(fā)與培訓(xùn)的同步。

?原型系統(tǒng)的開發(fā)費(fèi)用低、開發(fā)周期短、維護(hù)容易且對(duì)用戶更友好。

盡管開發(fā)者和客戶都喜歡使用原型模型，但原型模型也有其固有的缺

點(diǎn)：

在對(duì)原型的理解上客戶與開發(fā)者有很大的差異，客戶以為原型就是軟

件的最終版本，而開發(fā)者只將原型當(dāng)作一個(gè)漂亮美麗的軟件外殼，在實(shí)際

開發(fā)過程中要對(duì)原型進(jìn)行不斷修改完善，這就需要開發(fā)人員與客戶相互溝

通、相互理解。

由于原型是開發(fā)者快速設(shè)計(jì)出來的，而開發(fā)者對(duì)所開發(fā)領(lǐng)域的陌生容

易將次要部分當(dāng)作主要的框架，做出不切題的原型。

軟件的整個(gè)開發(fā)都是圍繞著原型來展開的，在一定程度上不利于開發(fā)

人員的創(chuàng)新。

?增量模型

>把軟件產(chǎn)品分解成增量構(gòu)件。原則：當(dāng)把新構(gòu)件集成到原有構(gòu)件時(shí)，

所形成的產(chǎn)品必須是可測(cè)試的。它能在較短時(shí)間內(nèi)向用戶提交可完成

部分工作的產(chǎn)品，盡早的得到回報(bào)。

要求開始實(shí)現(xiàn)各個(gè)構(gòu)件前就全部完成的需求分析、規(guī)格說明、總體

設(shè)計(jì)。

?螺旋模型

螺旋模型：沿螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出一個(gè)更為完善的軟件版本

>螺旋模型的基本思想：使用原形與其他方法來盡量降低風(fēng)險(xiǎn)?？梢?/p>

看作每個(gè)階段前都加了風(fēng)險(xiǎn)分析的快速原型模型。螺旋模型是風(fēng)險(xiǎn)驅(qū)

動(dòng)型的。

總結(jié)

ModelChorocteristicsbrowbocks

尸格的■序方法可"能演足使用者的?

按照文檔短定求

*9明?要求■雄的內(nèi)部站構(gòu)設(shè)計(jì)：

浪費(fèi)工作時(shí)間

?大通度的■早產(chǎn)的成果?要軟件具備開放式的體

適應(yīng)使用者的變化素結(jié)構(gòu)

般難將所有的構(gòu)件集成

/以雄妒

支持系統(tǒng)發(fā)用；限制了適用性，只適用大

增加了乂險(xiǎn)分析型

開發(fā)者■要風(fēng)險(xiǎn)分析能力

?面向?qū)ο竽Ｐ?/p>

?噴泉模型

、噴泉模型的優(yōu)點(diǎn)各階段交叉、迭代，支持復(fù)用

噴泉模型不像瀑布模型那樣，需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng)，

設(shè)計(jì)活動(dòng)結(jié)束后才開始編碼活動(dòng)。該模型的各個(gè)階段沒有明顯的界限，開

發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開

發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。

、噴泉模型的缺點(diǎn)

由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量

的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，

使得審核的難度加大，尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的

情況。

?統(tǒng)一過程模型

/用例驅(qū)動(dòng)整個(gè)開發(fā)過程

/迭代增量式開發(fā)

/基于構(gòu)件的軟件體系結(jié)構(gòu)為中心展開開發(fā)

,使用統(tǒng)一建模語(yǔ)言0

（）（計(jì)算機(jī)輔助軟件工程）

用來輔助軟件開發(fā)、運(yùn)行、維護(hù)、管理、支持等過程中活動(dòng)的軟件稱為軟

件工具

?什么是需求工程

（軟件需求）

用戶對(duì)軟件功能，性能，設(shè)計(jì)等方面的需求

(需求工程)

/這個(gè)過程獲取用戶或最終使用者對(duì)軟件的需求

/包括一系列的任務(wù)來理解軟件的需求

/幫助軟件工程師更好的理解他們需要解決的問題

/()需求獲取

/需求分析

/需求說明

,需求認(rèn)證

,需求管理

二、需求獲取技術(shù)

■目的

確定和收集與待開發(fā)的軟件系統(tǒng)相關(guān)的信息

獲取需求，確定問題，定義問題范圍，解決沖突

■關(guān)鍵要與用戶溝通，收集和理解需求

■獲取方法

/采訪消費(fèi)者

/研討需求

,問卷調(diào)查

/建了原型

1.需求分析模型

重點(diǎn)是建立分析模型

是對(duì)現(xiàn)實(shí)的簡(jiǎn)化，分析模型定義了系統(tǒng)的詳細(xì)需求，但不限于一種技術(shù)

/傳統(tǒng)方法：（），，0,，…（數(shù)據(jù)流圖，數(shù)據(jù)字典，狀態(tài)轉(zhuǎn)換圖）

/面向?qū)ο蠓椒ǎ海?，，，（用例，順序圖，協(xié)作圖，類圖，狀態(tài)

圖）

需求分析過程

,定義系統(tǒng)范圍

,分析需求的可行性

,確定需求的優(yōu)先級(jí)

/形成需求分析模型

/建立數(shù)據(jù)字典

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

/建立一個(gè)系統(tǒng)的輸入輸出模型

/用來描述系統(tǒng)的功能和行為

優(yōu)點(diǎn)

/易于理解

/方便開發(fā)者和用戶間的交流

符號(hào)（外部實(shí)體，處理，數(shù)據(jù)流，數(shù)據(jù)儲(chǔ)存）

1）外部實(shí)體（原點(diǎn)和匯點(diǎn)）

外部項(xiàng)是指系統(tǒng)以外的事物或人，表達(dá)了該系統(tǒng)數(shù)據(jù)的外部來源或去

處，用方框表示之。

2）處理（加工）

處理表達(dá)了對(duì)數(shù)據(jù)的邏輯加工或變換功能：對(duì)數(shù)據(jù)的加工處理的結(jié)

果，或者是變換了數(shù)據(jù)的結(jié)構(gòu)，或者是在原有數(shù)據(jù)的基礎(chǔ)上產(chǎn)生新的

數(shù)據(jù)。處理用圓表示。

3）數(shù)據(jù)流

數(shù)據(jù)流指示數(shù)據(jù)的流動(dòng)方向，用單箭頭表示。

4）數(shù)據(jù)存儲(chǔ)

數(shù)據(jù)存儲(chǔ)指明了保存數(shù)據(jù)的地方。不代表具體的存儲(chǔ)介質(zhì)。數(shù)據(jù)存儲(chǔ)

使用右端開口的矩形框表示。

-Externalentity

?Aproducerorconsumerofdata

?Datamustalwaysoriginatesomewhereandmustalwaysbesent

tosomewhere.

-Process

?Adatatransformer

?Datamustalwaysbeprocessesinsomewaytoachievesystem

function

-Dataflow

?Dataflowsthroughasystem

-Datastorage

?Dataisoftenstoredforlateruse

分層數(shù)據(jù)流圖

為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，用一個(gè)數(shù)據(jù)流圖是不夠的。

稍為復(fù)雜的實(shí)際問題，在數(shù)據(jù)流圖上常常出現(xiàn)十幾個(gè)甚至幾十個(gè)加工。這

樣的數(shù)據(jù)流圖看起來很不清楚。層次結(jié)構(gòu)的數(shù)據(jù)流圖能很好地解決這一問

題。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)

構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)。

畫數(shù)據(jù)流圖的方法

畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細(xì)

化，完善求精。檢查和修改的原則為：

1）由外與里畫數(shù)據(jù)流圖

2）自頂向下分層畫數(shù)據(jù)流圖

分解應(yīng)遵循下列原則：

?分解要自然，注意概念上的合理性；

?以分層方式對(duì)處理編號(hào)；

?注意父圖與子圖的平衡，即子圖所有的輸入和輸出數(shù)據(jù)流應(yīng)當(dāng)是父

圖中相應(yīng)處理的所有輸入和輸出數(shù)據(jù)流；

?一個(gè)處理一般可分解成個(gè)子處理，不宜過多；

?當(dāng)進(jìn)一步分解可能涉與具體的物理實(shí)現(xiàn)手段時(shí)，分解應(yīng)終止。

3）檢查和修改的原則為：

①數(shù)據(jù)流圖上所有圖形符號(hào)只限于前述四種基本圖形元素。

②頂層數(shù)據(jù)流圖必須包括前述四種基本元素，缺一不可。

③頂層數(shù)據(jù)流圖上的數(shù)據(jù)流必須封閉在外部實(shí)體之間。

④每個(gè)加工至少有一個(gè)輸入數(shù)據(jù)流和一個(gè)輸出數(shù)據(jù)流。

⑤在數(shù)據(jù)流圖中，需按層給加工框編號(hào)。編號(hào)表明該加工處在哪

一層，以與上下層的父圖與子圖的對(duì)應(yīng)關(guān)系。

⑥規(guī)定任何一個(gè)數(shù)據(jù)流子圖必須與它上一層的一個(gè)加工對(duì)應(yīng)，兩

者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。此即父圖與子圖的平衡。

⑦可以在數(shù)據(jù)流圖中加入物質(zhì)流，幫助用戶理解數(shù)據(jù)流圖。

⑧圖上每個(gè)元素都必須有名字。數(shù)據(jù)流和數(shù)據(jù)文件的名字應(yīng)當(dāng)是

“名詞”或“名詞性短語(yǔ)”，表明流動(dòng)的數(shù)據(jù)是什么。加工的名字應(yīng)當(dāng)

是“動(dòng)詞+賓語(yǔ)。表明做什么事情。

⑨數(shù)據(jù)流圖中不可夾帶控制流。

⑩初畫時(shí)可以忽略瑣碎的細(xì)節(jié)，以集中精力于主要數(shù)據(jù)流。

數(shù)據(jù)流圖作用：開發(fā)人員與用戶，軟件人員與軟件人員之間的橋梁；

驗(yàn)收的依據(jù)

例子

?Example1

?Example2

|入篋寸拄入玲數(shù)格|n摩存伏態(tài)

I入國(guó)文件------------M庫(kù)存文件------------?

㈤錯(cuò)誤的形式

(b)正確的形式

?CopyrightbaiVu.NEU,吠

?Example3

數(shù)據(jù)字典

數(shù)據(jù)圖反映了數(shù)據(jù)在系統(tǒng)中的流向以與數(shù)據(jù)的轉(zhuǎn)換過程，但它無法描述有

關(guān)數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)、處理邏輯和外部項(xiàng)的進(jìn)一步詳細(xì)的內(nèi)容。數(shù)據(jù)字典

用于較詳細(xì)地定義或說明數(shù)據(jù)留圖的四個(gè)基本成分。數(shù)據(jù)兔和數(shù)據(jù)字典共

同構(gòu)造系統(tǒng)的邏輯模型。沒有數(shù)據(jù)字典，數(shù)據(jù)流圖就不嚴(yán)格。

2.（,軟件需求規(guī)格說明）

。定義：精確描述一個(gè)軟件系統(tǒng)的功能和性能

。軟件需求規(guī)格說明應(yīng)包含的內(nèi)容

/引言：軟件目標(biāo)與范圍

/數(shù)據(jù)描述：數(shù)據(jù)流圖（系統(tǒng)邏輯模型）、數(shù)據(jù)字典（一切數(shù)據(jù)的定

義）

,外部接口：怎樣與人，硬件，和其他系統(tǒng)交互

,功能描述：功能說明，應(yīng)該提供什么功能

性能描述：性能說明

/特征描述：軟件的安全性，可操作性等

,限制條件：應(yīng)遵循的標(biāo)準(zhǔn)（語(yǔ)言，環(huán)境，標(biāo)準(zhǔn)…）

不應(yīng)該包含的內(nèi)容

/開發(fā)計(jì)劃

/保險(xiǎn)計(jì)劃

/設(shè)計(jì)細(xì)節(jié)

的質(zhì)量

,正確性：能爭(zhēng)取表達(dá)用戶的需求

,無岐義：每個(gè)人都要有一致的理解

,完整：需要包括軟件的所有任務(wù)

/可驗(yàn)證性：每一個(gè)需求都能驗(yàn)證和確定

/一致性：需求的描述不能有沖突

/可修改性：容易修改，每個(gè)應(yīng)該有索引且需求不能交叉引用

/可追溯性：每個(gè)需求都和它的資源，設(shè)計(jì)，代碼，測(cè)試用例相聯(lián)系

1.需求確認(rèn)

證實(shí)用戶對(duì)需求是否滿意

,需求判斷

,原型評(píng)價(jià)

/生成測(cè)試用例

分析修改造成的影響，控制修改的過程

包括：修改控制，版本控制，需求追蹤

四:

一、面向?qū)ο蠓椒ń榻B

1.定義和歷史

出現(xiàn)后，代替的傳統(tǒng)的建模方法

2.面向?qū)ο筌浖こ?/p>

?()面向?qū)ο蠓治?/p>

?()面向?qū)ο笤O(shè)計(jì)

?()面向?qū)ο缶幊?/p>

?>>是一個(gè)平穩(wěn)的過度，可以提高開發(fā)的效率和質(zhì)量

?()面向?qū)ο鬁y(cè)試

?面向?qū)ο筌浖S護(hù)

二、面向?qū)ο蠡A(chǔ)

。(對(duì)象)：系統(tǒng)中用來描述現(xiàn)實(shí)中事物的實(shí)體

,包括一些屬性(描述靜態(tài)特征)和操作方法(描述動(dòng)態(tài)特征)

/軟件系統(tǒng)的基本單元

(類)：一組擁有相同屬性和方法的對(duì)象

。*類和對(duì)象的比較

/類是靜態(tài)的，在程序運(yùn)行前已經(jīng)定義

/對(duì)象是動(dòng)態(tài)的，在程序運(yùn)行是創(chuàng)建

對(duì)象是類的一個(gè)實(shí)例

在的過程中，我們強(qiáng)調(diào)類，而不是對(duì)象

（消息）：來自于對(duì)象的請(qǐng)求

（封裝）：隱藏對(duì)象的屬性和實(shí)現(xiàn)細(xì)節(jié)，僅對(duì)外公開接口，控制在程序

中屬性的讀和修改的訪問級(jí)別

（繼承）：意味著子類可以擁有父類的全部屬性和方法

。（多態(tài)）：多態(tài)指同一個(gè)實(shí)體同時(shí)具有多種形式。子類繼承的屬性和方

法，可以不同于父類，提供靈活的軟件設(shè)計(jì)方法，提高軟件復(fù)用

?基本概念：

1.軟件建模

描述現(xiàn)實(shí)世界重要的部分

三、統(tǒng)一建模語(yǔ)言（）

/一個(gè)可視的建模語(yǔ)言，但不是一個(gè)可視編程語(yǔ)言

/一個(gè)支持開發(fā)的工具，但不是萬(wàn)能的

/一個(gè)建模的描述

令（可視化的）

令（詳細(xì)描述的）

?（構(gòu)造的）

?（文檔化的）

矩形

線

其他圖形

特征字符串

（關(guān)于更詳細(xì)的方法，自己看書吧。。。）

五

面向?qū)ο蠓治龅闹饕蝿?wù)是用面向?qū)ο蟮母拍詈头椒檐浖枨蠼⒛?/p>

型。

①用例建模

.什么是用例？

在介始用例方法之前，我們首先來看一下傳統(tǒng)的需求表述方式”軟件需求規(guī)

約”（）o傳統(tǒng)的軟件需求規(guī)約基本上采用的是功能分解的方式來描述系統(tǒng)

功能，在這種表述方式中，系統(tǒng)功能被分解到各個(gè)系統(tǒng)功能模塊中，我們

通過描述細(xì)分的系統(tǒng)模塊的功能來達(dá)到描述整個(gè)系統(tǒng)功能的目的。一個(gè)典

型的軟件需求規(guī)約可能具有以下形式：

軟件需求規(guī)約（SRS）

子系統(tǒng)1功能

模塊1.1功能

模塊1.2功能

子系統(tǒng)2功能

模塊2.1功能

模塊2.2功能

子系統(tǒng)N功能

采用這種方法來描述系統(tǒng)需求，非常容易混淆需求和設(shè)計(jì)的界限，這樣的

表述實(shí)際上已經(jīng)包含了部分的設(shè)計(jì)在內(nèi)。由此常常導(dǎo)致這樣的迷惑：系統(tǒng)

需求應(yīng)該詳細(xì)到何種程度？一個(gè)極端就是需求可以詳細(xì)到概要設(shè)計(jì)，因?yàn)?/p>

這樣的需求表述既包含了外部需求也包含了內(nèi)部設(shè)計(jì)。在有些公司的開發(fā)

流程中，這種需求被稱為“內(nèi)部需求”，而對(duì)應(yīng)于用戶的原始要求則被稱之

為“外部需求”。

功能分解方法的另一個(gè)缺點(diǎn)是這種方法分割了各項(xiàng)系統(tǒng)功能的應(yīng)用環(huán)境，

從各項(xiàng)功能項(xiàng)入手，你很難了解到這些功能項(xiàng)是如何相互關(guān)聯(lián)來實(shí)現(xiàn)一個(gè)

完成的系統(tǒng)服務(wù)的。所以在傳統(tǒng)的文檔中，我們往往需要另外一些章節(jié)來

描述系統(tǒng)的整體結(jié)構(gòu)與各部分之間的相互關(guān)聯(lián)，這些內(nèi)容使得需求更象是

一個(gè)設(shè)計(jì)文檔。

參與者和用例

從用戶的角度來看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計(jì)，他們所關(guān)心

的是系統(tǒng)所能提供的服務(wù)，也就是被開發(fā)出來的系統(tǒng)將是如何被使用的，

這就用例方法的基本思想。用例模型主要由以下模型元素構(gòu)成：

.參與者0

參與者是指存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系

統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。

.用例（）

用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用

的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之

間發(fā)生的一段對(duì)話。

.通訊關(guān)聯(lián)（）

通訊關(guān)聯(lián)用于表示參與者和用例之間的對(duì)應(yīng)關(guān)系，它表示參與者使用了

系統(tǒng)中的哪些服務(wù)（用例），或者說系統(tǒng)所提供的服務(wù)（用例）是被哪

些參與者所使用的。

這大三種模型元素在中的表述如下圖所示。

以銀行自動(dòng)提款機(jī)（）為例，它的主要功能可以由下面的用例圖來表示。的

主要使用者是銀行客戶，客戶主要使用自動(dòng)提款機(jī)來進(jìn)行銀行帳戶的查

詢、提款和轉(zhuǎn)帳交易。

通訊關(guān)聯(lián)表示的是參與者和用例之間的關(guān)系，箭頭表示在這一關(guān)系中哪一

方是對(duì)話的主動(dòng)發(fā)起者，箭頭所指方是對(duì)話的被動(dòng)接受者；如果你不想強(qiáng)

調(diào)對(duì)話中的主動(dòng)與被動(dòng)關(guān)系，可以使用不帶箭頭的關(guān)聯(lián)實(shí)線。在參與者和

用例之間的信息流不是由通訊關(guān)聯(lián)來表示的，該信息流是缺省存在的（用

例本身描述的就是參與者和系統(tǒng)之間的對(duì)話），并且信息流向是雙向的,

它與通訊關(guān)聯(lián)箭頭所指的方向亳無關(guān)系。

用例的內(nèi)容

用例圖使我們對(duì)系統(tǒng)的功能有了一個(gè)整體的認(rèn)知，我們可以知道有哪些參

與者會(huì)與系統(tǒng)發(fā)生交互，每一個(gè)參與者需要系統(tǒng)為它提供什么樣的服務(wù)。

用例描述的是參與者與系統(tǒng)之間的對(duì)話，但是這個(gè)對(duì)話的細(xì)節(jié)并沒有在用

例圖中表述出來，針對(duì)每一個(gè)用例我們可以用事件流來描述這一對(duì)話的細(xì)

節(jié)內(nèi)容。如在系統(tǒng)中的“提款”用例可以用事件流表述如下：

提款基本事件流

.用戶插入信用卡

?輸入密碼

?輸入提款金額

.提取現(xiàn)金

.退出系統(tǒng)，取回信用卡

但是這只描述了提款用例中最順利的一種情況，作為一個(gè)實(shí)用的系統(tǒng)，我

們還必須考慮可能發(fā)生的各種其他情況，如信用卡無效、輸入密碼錯(cuò)、用

戶帳號(hào)中的現(xiàn)金余額不夠等，所有這些可能發(fā)生的各種情況（包括正常的

和異常的）被稱之為用例的場(chǎng)景0,場(chǎng)景也被稱作是用例的實(shí)例（）。在用例

的各種場(chǎng)景中，最常見的場(chǎng)景是用基本流（）來描述的，其他的場(chǎng)景則是用

備選流（）來描述。對(duì)于系統(tǒng)中的“提款”用例，我們可以得到如下一些備選

流：

提款備選事件流

備選流一：用戶可以在基本流中的任何一步選擇退出，轉(zhuǎn)至基本流步驟。

備選流二：在基本流步驟中，用戶插入無效信用卡，系統(tǒng)顯示錯(cuò)誤并退出

信用卡，用例結(jié)束。

備選流三：在基本流步驟2中，用戶輸入錯(cuò)誤密碼，系統(tǒng)顯示錯(cuò)誤并提示

用戶重新輸入密碼，重新回到基本流步驟；三次輸入密碼錯(cuò)誤后，信用卡

被系統(tǒng)沒收，用例結(jié)束。

通過基本流與備選流的組合，就可以將用例所有可能發(fā)生的各種場(chǎng)景全部

描述清楚。我們?cè)诿枋鲇美氖录鞯臅r(shí)候，就是要盡可能地將所有可能

的場(chǎng)景都描述出來，以保證需求的完備性。

用例方法的優(yōu)點(diǎn)

用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能的。

在用例方法中，我們把被定義系統(tǒng)看作是一個(gè)黑箱，我們并不關(guān)心系統(tǒng)內(nèi)

部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些

外部使用者（抽象成為），這些使用者與被定義系統(tǒng)發(fā)生交互；針對(duì)每一

參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)（抽象

成為）,或者說系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們

可以得到對(duì)于被定義系統(tǒng)的一個(gè)總體印象。

與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來定義系統(tǒng)的功能，

它把需求與設(shè)計(jì)完全分離開來。在面向?qū)ο蟮姆治鲈O(shè)計(jì)方法中，用例模型

主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設(shè)計(jì)主要由對(duì)象模型來記錄表

述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個(gè)用例描述的

是一個(gè)完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的更易于被用戶所理解，它可以

作為開發(fā)人員和用戶之間針對(duì)系統(tǒng)需求進(jìn)行溝通的一個(gè)有效手段。

在中，用例被作為整個(gè)軟件開發(fā)流程的基礎(chǔ)，很多類型的開發(fā)活動(dòng)都把用

例作為一個(gè)主要的輸入工件()，如項(xiàng)目管理、分析設(shè)計(jì)、測(cè)試等。根據(jù)用

例來對(duì)目標(biāo)系統(tǒng)進(jìn)行測(cè)試，可以根據(jù)用例中所描述的環(huán)境和上下文來完整

地測(cè)試一個(gè)系統(tǒng)服務(wù)，可以根據(jù)用例的各個(gè)場(chǎng)景()來設(shè)計(jì)測(cè)試用例，完全

地測(cè)試用例的各種場(chǎng)景可以保證測(cè)試的完備性。

?建立用例模型

使用用例的方法來描述系統(tǒng)的功能需求的過程就是用例建模，用例模型主

要包括以下兩部分內(nèi)容：

.用例圖()

確定系統(tǒng)中所包含的參與者、用例和兩者之間的對(duì)應(yīng)關(guān)系，用例圖描述

的是關(guān)于系統(tǒng)功能的一個(gè)概述。

.用例規(guī)約()

針對(duì)每一個(gè)用例都應(yīng)該有一個(gè)用例規(guī)約文檔與之相對(duì)應(yīng)，該文檔描述用

例的細(xì)節(jié)內(nèi)容。

在用例建模的過程中，我們建議的步聚是先找出參與者，再根據(jù)參與者確

定每個(gè)參與者相關(guān)的用例，最后再細(xì)化每一個(gè)用例的用例規(guī)約。

尋找參與者

所謂的參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進(jìn)行交互的人或其他系

統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者C尋找參與者可以

從以下問題入手：

.系統(tǒng)開發(fā)完成之后，有哪些人會(huì)使用這個(gè)系統(tǒng)？

.系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？

.系統(tǒng)會(huì)為哪些人或其他系統(tǒng)提供數(shù)據(jù)?

.系統(tǒng)會(huì)與哪些其他系統(tǒng)相關(guān)聯(lián)?

.系統(tǒng)是由誰(shuí)來維護(hù)和管理的？

這些問題有助于我們抽象出系統(tǒng)的參與者。對(duì)于機(jī)的例子，回答這些問題

可以使我們找到更多的參與者：操作員負(fù)責(zé)維護(hù)和管理機(jī)系統(tǒng)、機(jī)也需要

與后臺(tái)服務(wù)器進(jìn)行通訊以獲得有關(guān)用戶帳號(hào)的相關(guān)信息。

系統(tǒng)邊界決定了參與者

參與者是由系統(tǒng)的邊界所決定的，如果我們所要定義的系統(tǒng)邊界僅限于機(jī)

本身，那么后臺(tái)服務(wù)器就是一個(gè)外部的系統(tǒng)，可以抽象為一個(gè)參與者。

如果我們所要定義的系統(tǒng)邊界擴(kuò)大至整個(gè)銀行系統(tǒng)，機(jī)和后臺(tái)服務(wù)器都是

整個(gè)銀行系統(tǒng)的一部分，這時(shí)候后臺(tái)服務(wù)器就不再被抽象成為一個(gè)參與

者。

關(guān)

值得注意的是，用例建模時(shí)不要將一些系統(tǒng)的組成結(jié)構(gòu)作為參與者來進(jìn)行

抽象，如在機(jī)系統(tǒng)中，打印機(jī)只是系統(tǒng)的一個(gè)組成部分，不應(yīng)將它抽象成

一個(gè)獨(dú)立的參與者；在一個(gè)管理系統(tǒng)中，數(shù)據(jù)庫(kù)系統(tǒng)往往只作為系統(tǒng)的一

個(gè)組成部分，一般不將其單獨(dú)抽象成一個(gè)參與者。

特殊的參與者一一系統(tǒng)時(shí)鐘

有時(shí)候我們需要在系統(tǒng)內(nèi)部定時(shí)地執(zhí)行一些操作，如檢測(cè)系統(tǒng)資源使用情

況、定期地生成統(tǒng)計(jì)報(bào)表等等。從表面上看，這些操作并不是由外部的人

或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來表述這一類功能需求呢？對(duì)于這種

情況，我們可以抽象出一個(gè)系統(tǒng)時(shí)鐘或定時(shí)器參與者，利用該參與者來觸

發(fā)這一類定時(shí)操作。從邏輯上，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，

由它來觸發(fā)系統(tǒng)所提供的用例對(duì)話。

美一。

確定用例

找到參與者之后，我們就可以根據(jù)參與者來確定系統(tǒng)的用例，主要是看各

參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。尋

找用例可以從以下問題入手（針對(duì)每一個(gè)參與者）：

?參與者為什么要使用該系統(tǒng)？

?參與者是否會(huì)在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲(chǔ)數(shù)據(jù)？如果

是的話，參與者又是如何來完成這些操作的？

?參與者是否會(huì)將外部的某些事件通知給該系統(tǒng)？

?系統(tǒng)是否會(huì)將內(nèi)部的某些事件通知該參與者？

綜合以上所述，系統(tǒng)的用例圖可表示如下,

在用例的抽取過程中，必須注意：用例必須是由某一個(gè)主角觸發(fā)而產(chǎn)生的

活動(dòng)，即每個(gè)用例至少應(yīng)該涉與一個(gè)主角。如果存在與主角不進(jìn)行交互的

用例，就可以考慮將其并入其他用例；或者是檢查該用例相對(duì)應(yīng)的參與者

是否被遺漏，如果是，則補(bǔ)上該參與者。反之，每個(gè)參與者也必須至少涉

與到一個(gè)用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在，就應(yīng)該考

慮該參與者是如何與系統(tǒng)發(fā)生對(duì)話的，或者由參與者確定一個(gè)新的用例，

或者該參與者是一個(gè)多余的模型元素，應(yīng)該將其刪除。

可視化建模的主要目的之一就是要增強(qiáng)團(tuán)隊(duì)的溝通，用例模型必須是易于

理解的。用例建模往往是一個(gè)團(tuán)隊(duì)開發(fā)的過程，系統(tǒng)分析員在建模過程中

必須注意參與者和用例的名稱應(yīng)該符合一定的命名約定，這樣整個(gè)用例模

型才能夠符合一定的風(fēng)格。如參與者的名稱一般都是名詞，用例名稱一般

都是動(dòng)賓詞組等。

對(duì)于同一個(gè)系統(tǒng)，不同的人對(duì)于參與者和用例都可能有不同的抽象結(jié)果，

因而得到不同的用例模型。我們需要在多個(gè)用例模型方案中選擇一種”最佳

"（或'較佳”）的結(jié)果，一個(gè)好的用例模型應(yīng)該能夠容易被不同的涉眾所理

解，并且不同的涉眾對(duì)于同一用例模型的理解應(yīng)該是一致的。

描述用例規(guī)約

應(yīng)該避免這樣一種誤解一一認(rèn)為由參與者和用例構(gòu)成的用例圖就是用例

模型，用例圖只是在總體上大致描述了系統(tǒng)所能提供的各種服務(wù)，讓我們

對(duì)于系統(tǒng)的功能有一個(gè)總體的認(rèn)識(shí)。除此之外，我們還需要描述每一個(gè)有

例的詳細(xì)信息，這些信息包含在用例規(guī)約中，用例模型是由用例圖和每一

個(gè)用例的詳細(xì)描述一一用例規(guī)約所組成的。中提供了用例規(guī)約的模板，每

一個(gè)用例的用例規(guī)約都應(yīng)該包含以下內(nèi)容：

?簡(jiǎn)要說明0

簡(jiǎn)要介紹該用例的作用和目的。

.事件流（）

包括基本流和備選流，事件流應(yīng)該表示出所有的場(chǎng)景。

.用例場(chǎng)景0

包括成功場(chǎng)景和失敗場(chǎng)景，場(chǎng)景主要是由基本流和備選流組合而成的O

?特殊需求0

描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴(kuò)

展性等）和設(shè)計(jì)約束（所使用的操作系統(tǒng)、開發(fā)工具等）。

?前置條件（）

執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。

.后置條件（）

用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。

用例規(guī)約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也

可以選擇使用狀態(tài)圖、活動(dòng)圖或序列圖來輔助說明。只要有助于表達(dá)的簡(jiǎn)

潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或

是其他圖形。如活動(dòng)圖有助于描述復(fù)雜的決策流程，狀態(tài)轉(zhuǎn)移圖有助于描

述與狀態(tài)相關(guān)的系統(tǒng)行為，序列圖適合于描述基于時(shí)間順序的消息傳遞。

基本流

基本流描述的是該用例最正常的一種場(chǎng)景，在基本流中系統(tǒng)執(zhí)行一系列活

動(dòng)步驟來響應(yīng)參與者提出的服務(wù)請(qǐng)求。我們建議用以下格式來描述基本

流：

)每一個(gè)步驟都需要用數(shù)字編號(hào)以清楚地標(biāo)明步驟的先后順序。

)用一句簡(jiǎn)短的標(biāo)題來概括每一步驟的主要內(nèi)容，這樣閱讀者可以通過瀏

覽標(biāo)題來快速地了解用例的主要步驟。在用例建模的早期，我們也只需要

描述到事件流步驟標(biāo)題這一層，以免過早地陷入到用例描述的細(xì)節(jié)中去。

)當(dāng)整個(gè)用例模型基本穩(wěn)定之后，我們?cè)籴槍?duì)每一步驟詳細(xì)描述參與者和

系統(tǒng)之間所發(fā)生的交互。建議采用雙向()描述法來保證描述的完整性，即

每一步驟都需要從正反兩個(gè)方面來描述:()參與者向系統(tǒng)提交了什么信息；

()對(duì)此系統(tǒng)有什么樣的響應(yīng)。具體例子請(qǐng)參見附錄。

在描述參與者和系統(tǒng)之間的信息交換時(shí)，需指出來回傳遞的具體信息。例

如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說參與者輸入

了客戶姓名和地址。通?？梢岳迷~匯表讓用例的復(fù)雜性保持在可控范圍

內(nèi)，可以在詞匯表中定義客戶信息等內(nèi)容，使用例不至于陷入過多的細(xì)節(jié)。

備選流

備選流負(fù)責(zé)描述用例執(zhí)行過程中異常的或偶爾發(fā)生的一些情況，備選流和

基本流的組合應(yīng)該能夠覆蓋該用例所有可能發(fā)生的場(chǎng)景。在描述備選流

時(shí)，應(yīng)該包括以下幾個(gè)要素：

）起點(diǎn)：該備選流從事件流的哪一步開始；

）條件：在什么條件下會(huì)觸發(fā)該備選流；

）動(dòng)作：系統(tǒng)在該備選流下會(huì)采取哪些動(dòng)作；

）恢復(fù)：該備選流結(jié)束之后，該用例應(yīng)如何繼續(xù)執(zhí)行。

備選流的描述格式可以與基本流的格式一致，也需要編號(hào)并以標(biāo)題概述其

內(nèi)容，編號(hào)前可以加以字母前綴（）以示與基本流步驟相區(qū)別。

用例場(chǎng)景

用例在實(shí)際執(zhí)行的時(shí)候會(huì)有很多的不同情況發(fā)生，稱之為用例場(chǎng)景；也可

以說場(chǎng)景是用例的實(shí)例，我們?cè)诿枋鲇美臅r(shí)候要覆蓋所有的用例場(chǎng)景，

否則就有可能導(dǎo)致需求的遺漏。在用例規(guī)約中，場(chǎng)景的描述可以由基本流

和備選流的組合來表示。場(chǎng)景既可以幫助我們防止需求的遺漏，同時(shí)也可

以對(duì)后續(xù)的開發(fā)工作起到很大的幫助：開發(fā)人員必須實(shí)現(xiàn)所有的場(chǎng)景、測(cè)

試人員可以根據(jù)用例場(chǎng)景來設(shè)計(jì)測(cè)試用例。

特殊需求

特殊需求通常是非功能性需求，它為一個(gè)用例所專有，但不適合在用例的

事件流文本中進(jìn)行說明。特殊需求的例子包括法律或法規(guī)方面的需求、應(yīng)

用程序標(biāo)準(zhǔn)和所構(gòu)建系統(tǒng)的質(zhì)量屬性（包括可用性、可靠性、性能或支持

性需求等）。此外，其他一些設(shè)計(jì)約束，如操作系統(tǒng)與環(huán)境、兼容性需求

等，也可以在此節(jié)中記錄。

需要注意的是，這里記錄的是專屬于該用例的特殊需求；對(duì)于一些全局的

非功能性需求和設(shè)計(jì)約束，它們并不是該用例所專有的，應(yīng)把它們記錄在

《補(bǔ)充規(guī)約》中。

前置和后置條件

前置條件是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)，后置條件是用例一執(zhí)行完

畢后系統(tǒng)可能處于的一組狀態(tài)。

檢查用例模型

用例模型完成之后，可以對(duì)用例模型進(jìn)行檢查，看看是否有遺漏或錯(cuò)誤之

處。主要可以從以下幾個(gè)方面來進(jìn)行檢查：

-功能需求的完備性

現(xiàn)有的用例模型是否完整地描述了系統(tǒng)功能，這也是我們判斷用例建模

工作是否結(jié)束的標(biāo)志。如果發(fā)現(xiàn)還有系統(tǒng)功能沒有被記錄在現(xiàn)有的用例

模型中，那么我們就需要抽象一些新的用例來記錄這些需求，或是將他

們歸納在一些現(xiàn)有的用例之中。

.模型是否易于理解

用例模型最大的優(yōu)點(diǎn)就在于它應(yīng)該易于被不同的涉眾所理解，因而用例

建模最主要的指導(dǎo)原則就是它的可理解性。用例的粒度、個(gè)數(shù)以與模型

元素之間的關(guān)系復(fù)雜程度都應(yīng)該由該指導(dǎo)原則決定。

?是否存在不一致性

系統(tǒng)的用例模型是由多個(gè)系統(tǒng)分析員協(xié)同完成的，模型本身也是由多個(gè)

工件所組成的,所以我們要特別注意不同工件之前是否存在前后矛盾或

沖突的地方，避免在模型內(nèi)部產(chǎn)生不一致性。不一致性會(huì)直接影響到需

求定義的準(zhǔn)確性。

?避免二義性語(yǔ)義

好的需求定義應(yīng)該是無二義性的，即不同的人對(duì)于同一需求的理解應(yīng)該

是一致的。在用例規(guī)約的描述中，應(yīng)該避免定義含義模糊的需求，即無

二義性。

.系統(tǒng)需求

中根據(jù)模型將系統(tǒng)需求分為以下幾類：

?功能0

?可用性0

?可靠性()

?性能0

?可支持性0

.設(shè)計(jì)約束等

除了第一項(xiàng)功能性需求之外的其他需求都?xì)w之為非功能性需求。

需求工件集

用例模型主要用于描述系統(tǒng)的功能性需求，對(duì)于其他的非功能性需要用其

他文檔來記錄。中定義了如下的需求工件集合。

.用例模型：記錄功能性需求

O用例圖：描述參與者和用例之間的關(guān)系

O用例規(guī)約：描述每一個(gè)用例的細(xì)節(jié)信息

.補(bǔ)充規(guī)約：記錄一些全局性的功能需求、非功能性需求和設(shè)計(jì)約束

等

?詞匯表：記錄一些系統(tǒng)需求相關(guān)的術(shù)語(yǔ)

在實(shí)際應(yīng)用中，除了這些工件之外，我們還可以根據(jù)實(shí)際需求靈活選用其

他形式的文檔來補(bǔ)充說明需求。并不是所有的系統(tǒng)需求都適保合用用例模

型來描述的，如編譯器，我們很難用用例方法來表述它所處理的語(yǔ)言的方

法規(guī)則，在這種情況下，采用傳統(tǒng)的范式來表述更加合適一些。在電信軟

件行業(yè)中，很多電信標(biāo)準(zhǔn)都是采用語(yǔ)言來描述的，我們也不必用來改寫這

些標(biāo)準(zhǔn)(對(duì)存在著這樣的兼容性)，只需將形式的電信標(biāo)準(zhǔn)作為需求工件

之一，在其他工件中對(duì)其加以引用就可以了?？傊?，萬(wàn)萬(wàn)不可拘泥于用例

建模的形式，應(yīng)靈活運(yùn)用各種方式的長(zhǎng)處。

補(bǔ)充規(guī)約

補(bǔ)充規(guī)約記錄那些在用例模型中不易表述的系統(tǒng)需求，主要包括以下內(nèi)

容。

.功能性

功能性需求主要在用例模型中刻畫，但是也有部分需求不適合在用例中

表述。有些功能性需求是全局性的，適用于所有的用例，如出錯(cuò)處理、

支持等，我們不需要在所有的用例中描述這些功能性需求，只需要在補(bǔ)

充規(guī)約中統(tǒng)一描述就可以了。

.可用性

記錄所有可用性相關(guān)的需求，如系統(tǒng)的使用者所需要的培訓(xùn)時(shí)間、是否

應(yīng)附合一些常見的可用性標(biāo)準(zhǔn)如界面風(fēng)格等。

O可靠性

定義系統(tǒng)可靠性相關(guān)的各種指標(biāo)，包括：

可用性：指出可用時(shí)間百分比()，系統(tǒng)處于使用、維護(hù)、降級(jí)模

式等操作的小時(shí)數(shù)；

O平均故障間隔時(shí)間（）：通常表示為小時(shí)數(shù)，但也可表示為天數(shù)、

月數(shù)或年數(shù)；

O平均修復(fù)時(shí)間（）：系統(tǒng)在發(fā)生故障后可以暫停運(yùn)行的時(shí)間；

O精確度：指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確

度（按照某一已知的標(biāo)準(zhǔn)）；

0最高錯(cuò)誤或缺陷率：通常表示為（每千行代碼的錯(cuò)誤數(shù)目）

或（每個(gè)功能點(diǎn)的錯(cuò)誤數(shù)目）。

O性能

記錄系統(tǒng)性能相關(guān)的各種指標(biāo)，包括：

對(duì)事務(wù)的響應(yīng)時(shí)間（平均、最長(zhǎng)）；

O吞吐量（例如每秒處理的事務(wù)數(shù)）；

O容量（例如系統(tǒng)可以容納的客戶或事務(wù)數(shù)）；

O降級(jí)模式（當(dāng)系統(tǒng)以某種形式降級(jí)時(shí)可接受的運(yùn)行模式）；

0資源利用情況：內(nèi)存、磁盤、通信等。

?可支持性

定義所有與系統(tǒng)的可支持性或可維護(hù)性相關(guān)的需求，其中包括編碼標(biāo)

準(zhǔn)、命名約定、類庫(kù)、如何來對(duì)系統(tǒng)進(jìn)行維護(hù)操作和相應(yīng)的維護(hù)實(shí)用工

具等。

?設(shè)計(jì)約束

設(shè)計(jì)約束代表已經(jīng)批準(zhǔn)并必須遵循的設(shè)計(jì)決定，其中包括軟件開發(fā)流

程、開發(fā)工具、系統(tǒng)構(gòu)架、編程語(yǔ)言、第三方構(gòu)件類庫(kù)、運(yùn)行平臺(tái)和數(shù)

據(jù)庫(kù)系統(tǒng)等等。

詞匯表

詞匯表主要用于定義項(xiàng)目特定的術(shù)語(yǔ)，它有助于開發(fā)人員對(duì)項(xiàng)目中所用的

術(shù)語(yǔ)有統(tǒng)一的理解和使用，它也是后續(xù)階段中進(jìn)行對(duì)象抽象的基礎(chǔ)。

?調(diào)整用例模型

在一般的用例圖中，我們只表述參與者和用例之間的關(guān)系，即它們之間的

通訊關(guān)聯(lián)。除此之外，我們還可以描述參與者與參與者之間的泛化()、用

例和用例之間的包含()、擴(kuò)展()和泛化()關(guān)系。我們利用這些關(guān)系來調(diào)整已

有的用例模型，把一些公共的信息抽取出來重用，使得用例模型更易于維

護(hù)。但是在應(yīng)用中要小心選用這些關(guān)系，一般來說這些關(guān)系都會(huì)增加用例

和關(guān)系的個(gè)數(shù)，從而增加用例模型的復(fù)雜度。而且一般都是在用例模型完

成之后才對(duì)用例模型進(jìn)行調(diào)整，所以在用例建模的初期不必要急于抽象用

例之間的關(guān)系。

參與者之間的關(guān)系

參與者之間可以有泛化()關(guān)系(或稱為“繼承"關(guān)系)。例如在需求分析中常

見的權(quán)限控制問題(如下圖所示)，一般的用戶只可以使用一些常規(guī)的操

作，而管理員除了常規(guī)操作之外還需要進(jìn)行一些系統(tǒng)管理工作，操作員既

可以進(jìn)行常規(guī)操作又可以進(jìn)行一些配置操作。

在這個(gè)例子中我們會(huì)發(fā)現(xiàn)管理員和操作員都是一種特殊的用戶，他們擁有

普通用戶所擁有的全部權(quán)限，此外他們還有自己獨(dú)有的權(quán)限。這里我們可

進(jìn)一步把普通用戶和管理員、操作員之間的關(guān)系抽象成泛化（）關(guān)系，管理

員和操作員可以繼承普通用戶的全部特性（包括權(quán)限），他們又可以有自

己獨(dú)有的特性（如操作、權(quán)限等）。這樣可以顯著減速少用例圖中通訊關(guān)

聯(lián)的個(gè)數(shù)，簡(jiǎn)化用例模型，使之更易于理解。

用例之間的關(guān)系

用例描述的是系統(tǒng)外部可見的行為，是系統(tǒng)為某一個(gè)或幾個(gè)參與者提供的

一段完整的服務(wù)。從原則上來講，用例之間都是并列的，它們之間并不存

在著包含從屬關(guān)系。但是從保證用例模型的可維護(hù)性和一致性角度來看，

我們可以在用例之間抽象出包含()、擴(kuò)展()和泛化()這幾種關(guān)系。這幾種關(guān)

系都是從現(xiàn)有的用例中抽取出公共的那部分信息，然后通后過不同的方法

來重用這部公共信息，以減少模型維護(hù)的工作量。

包含0

包含關(guān)系是通過在關(guān)聯(lián)關(guān)系上應(yīng)用vv>>構(gòu)造型來表示的，如下圖所示。它

所表示的語(yǔ)義是指基礎(chǔ)用例()會(huì)用到被包含用例()，具體地講，就是將被包

含用例的事件流插入到基礎(chǔ)用例的事件流中。

包含關(guān)系是中的表述，在中，同等語(yǔ)義的關(guān)系被表述為使用0,如下圖。

在機(jī)中，如果查詢、取現(xiàn)、轉(zhuǎn)帳這三個(gè)用例都需要打印一個(gè)回執(zhí)給客戶，

我們就可以把打印回執(zhí)這一部分內(nèi)容提取出來，抽象成為一個(gè)單獨(dú)的用例

“打印回執(zhí)”，而原有的查詢、取現(xiàn)、轉(zhuǎn)帳三個(gè)例都會(huì)包含這個(gè)用例。每當(dāng)

以后要對(duì)打印回執(zhí)部分的需求進(jìn)行修改時(shí)，就只需要改動(dòng)一個(gè)用例，而不

用在每一個(gè)用例都作相應(yīng)修改，這樣就提高了用例模型的可維護(hù)性。

在基礎(chǔ)用例的事件流中，我們只需要引用被包含用例即可。

查詢基本事件流

.用戶插入信用卡

?輸入密碼

?選擇查詢

.查看帳號(hào)余額

.包含用例”打印回執(zhí)”

.退出系統(tǒng)，取回信用卡

在這個(gè)例子中，多個(gè)用例需要用到同一段行為，我們可以把這段共同的行

為單獨(dú)抽象成為一個(gè)用例，然后讓其他的用例來包含這一用例。從而避免

在多個(gè)用例中重復(fù)性地描述同一段行為，也可以防止該段行為在多個(gè)用例

中的描述出現(xiàn)不一致性。當(dāng)需要修改這段公共的需求時(shí)，我們也只需要修

改一個(gè)用例，避免同時(shí)修改多個(gè)用例而產(chǎn)生的不一致性和重復(fù)性工作。

有時(shí)當(dāng)某一個(gè)用例的事件流過于復(fù)雜時(shí)，為了簡(jiǎn)化用例的描述，我們也可

以把某一段事件流抽象成為一個(gè)被包含的用例。這種情況類似于在過程設(shè)

計(jì)語(yǔ)言中，將程序的某一段算法封裝成一個(gè)子過程，然后再?gòu)闹鞒绦蛑姓{(diào)

用這一子過程。

擴(kuò)展()

擴(kuò)展()關(guān)系如下圖所示，基礎(chǔ)用例()中定義有一至多個(gè)已命名的擴(kuò)展點(diǎn),

擴(kuò)展關(guān)系是指將擴(kuò)展用例0的事件流在一定的條件下按照相應(yīng)的擴(kuò)展點(diǎn)插

入到基礎(chǔ)用例()中。對(duì)于包含關(guān)系而言，子用例中的事件流是一定插入到

基礎(chǔ)用例中去的，并且插入點(diǎn)只有一個(gè)。而擴(kuò)展關(guān)系可以根據(jù)一定的條件

來決定是否將擴(kuò)展用例的事件流插入基礎(chǔ)用例事件流，并且插入點(diǎn)可以有

多個(gè)。

H一

例如對(duì)于電話業(yè)務(wù)，可以在基本通話()業(yè)務(wù)上擴(kuò)展出一些增值業(yè)務(wù)如：呼

叫等待()和呼叫轉(zhuǎn)移()o我們可以用擴(kuò)展關(guān)系將這些業(yè)務(wù)的用例模型描述

如下。

基本通話呻iq等待呻iq轉(zhuǎn)移

基本流：該用例在“增值業(yè)務(wù)”擴(kuò)展點(diǎn)上擴(kuò)該用例在“增值業(yè)務(wù)”擴(kuò)展點(diǎn)上擴(kuò)

展了基本通話用例展了基本通話用例

1拔.號(hào)

基本流：基本流

2.建立通話幡

i.如果應(yīng)答方正忙，用鈴聲提示應(yīng)1如果應(yīng)答方無應(yīng)答，按應(yīng)答方

3通.話答方并保持撥號(hào)呼叫。設(shè)置轉(zhuǎn)移呼叫。

4掛.機(jī)

擴(kuò)展點(diǎn)：

“增值業(yè)務(wù)”擴(kuò)展點(diǎn)定義在基本流

步聚1

在這個(gè)例子中，呼叫等待和呼叫轉(zhuǎn)移都是對(duì)基本通話用例的擴(kuò)展，但是這

兩個(gè)用例只有在一定的條件下(如應(yīng)答方正忙或應(yīng)答方無應(yīng)答)才會(huì)將被

擴(kuò)展用例的事件流嵌入基本通話用例的擴(kuò)展點(diǎn)，并重用基本通話用例中的

事件流。

值得注意的是擴(kuò)展用例的事件流往往可以也可抽象為基礎(chǔ)用例的備選流，

如上例中的呼叫等待和呼叫轉(zhuǎn)移都可以作為基本通話用例的備選流而存

在。但是基本通話用例已經(jīng)是一個(gè)很復(fù)雜的用例了，選用擴(kuò)展關(guān)系將增值

業(yè)務(wù)抽象成為單獨(dú)的用例可以避免基礎(chǔ)用例過于復(fù)雜，并且把一些可選的

操作獨(dú)立封裝在另外的用例中。

泛化0

當(dāng)多個(gè)用例共同擁有一種類似的結(jié)構(gòu)和行為的時(shí)候，我們可以將它們的共

性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。在用例的泛化

關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)

構(gòu)、行為和關(guān)系。在實(shí)際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為

都可以作為父用例中的備選流存在。

go

以下是一個(gè)用例泛化關(guān)系的例子，執(zhí)行交易是一種交易抽象，執(zhí)行房產(chǎn)交

易和執(zhí)行證券交易都是一種特殊的交易形式。

用例泛化關(guān)系中的事件流示例如下:

執(zhí)行交易執(zhí)行證券交易

基本流：該用例是執(zhí)行交易用例的一個(gè)子用例.

1.客戶登錄基本流：

驗(yàn)證用戶身份.??L客戶登錄

2.客戶選擇交易

客戶選擇交易類型...2.容尸選擇交易

3.客戶選擇帳號(hào)

系統(tǒng)顯示客戶可用帳號(hào)，客戶選擇...3.客戶選擇帳號(hào)

4執(zhí).行交易

4.執(zhí)行交易

5客.戶開始新的交易根需客戶矗擇的交易勇里.系銃分窺機(jī)行定價(jià)買

如果客戶需要執(zhí)行其他交易，轉(zhuǎn)至步驟3...人.啟靜拓》

6.顯示交易結(jié)果5客.戶開始新的交易

系統(tǒng)顯示交易結(jié)果..

6.顯示交易結(jié)

^了父用舊中衲接作步衰之先?系策也復(fù):該用尸

的修號(hào)平盤詁況

調(diào)整用例模型

用例模型建成之后，我們可以對(duì)用例模型進(jìn)行檢視，看是否可以進(jìn)一步簡(jiǎn)

化用例模型、提高重用程度、增加模型的可維護(hù)性。主要可以從以下檢查

點(diǎn)0入手：

?用例之間是否相互獨(dú)立？如果兩個(gè)用例總是以同樣的順序被激活，

可能需要將它們合并為一個(gè)用例。

?多個(gè)用例之間是否有非常相似的行為或事件流？如果有，可以考慮

將它們合并為一個(gè)用例。

.用例事件流的一部分是否已被構(gòu)建為另一個(gè)用例？如果是，可以讓

該用例包含()另一用例。

?是否應(yīng)該將一個(gè)用例的事件流插入另一個(gè)用例的事件流中？如果

是，利用與另一個(gè)用例的擴(kuò)展關(guān)系()來建立此模型。

.管理用例模型復(fù)雜度

一般小型的系統(tǒng)，其用例模型中包含的參與者和用例不會(huì)太多，一個(gè)用例

圖就可以容納所有的參與者，所有的參與者和用例也可以并存于同一個(gè)層

次結(jié)構(gòu)中。對(duì)于較復(fù)雜的大中型系統(tǒng)，用例模型中的參與者和用例會(huì)大大

增加，我們需要一些方法來有效地管理由于規(guī)模上升而造成的復(fù)雜度。

用例包

包0是中最常用的管理模型復(fù)雜度的機(jī)制，包也是中語(yǔ)義最簡(jiǎn)單的一種模

型元素，它就是一種容器，在包中可以容納其他任意的模型元素（包括其

他的包）。在用例模型中，我們可以用構(gòu)造型（）<<>>來擴(kuò)展標(biāo)準(zhǔn)包的語(yǔ)義,

這種新的包叫作用例包（），用于分類管理用例模型中的模型元素。

我們可以根據(jù)參與者和用例的特性來對(duì)它們進(jìn)行分類，分別置于不同的用

例包管理之下。例如對(duì)于一個(gè)大型的企業(yè)管理信息系統(tǒng)，我們可以根據(jù)參

與者和用例的內(nèi)容將它們分別歸于人力資源、財(cái)務(wù)、采購(gòu)、銷售、客務(wù)服

務(wù)這些用例包之下。這樣我們將整個(gè)用例模型劃分成為兩個(gè)層次，在第一

層次我們看到的是系統(tǒng)功能總共分為五部分，在第二層次我們可以分別看

到每一用例包內(nèi)部的參與者和用例。

|????€???II

<<UI4

一個(gè)用例模型需要有多少個(gè)用例包取決你想怎么樣來管理用例模型的復(fù)

雜度（包括參與者和用例的個(gè)數(shù)，以與它們之間的相互關(guān)系）。中的包其

實(shí)就類似于文件系統(tǒng)中的目錄，文件數(shù)量少的時(shí)候不需要額外的目錄，文

件數(shù)量一多就需要有多個(gè)目錄來分類管理，同樣一組文件不同的人會(huì)創(chuàng)建

不同的目錄結(jié)構(gòu)來進(jìn)行管理，關(guān)鍵是要保證在目錄結(jié)構(gòu)下每一個(gè)文件都要

易于訪問。同樣的道理存在于用例建模之中，如何創(chuàng)建用例包以與用例包

的個(gè)數(shù)取決于不同的系統(tǒng)和系統(tǒng)分析員，但要保證整個(gè)用例模型易于理

解。

用例的粒度

我的系統(tǒng)需要有多少個(gè)用例？這是很多人在用例建模時(shí)會(huì)產(chǎn)生的疑惑。描

述同一個(gè)系統(tǒng)，不同的人會(huì)產(chǎn)生不同的用例模型。例如對(duì)于各種系統(tǒng)中常

見的“維護(hù)用戶”用例，它里面包含了添加用戶、修改用戶信息、刪除用戶

等操作，這些操作在該用例的事件流可以表述成為基本流的子事件流0。

關(guān)--------O

維護(hù)用戶基本事件流

該基本流由三個(gè)子事件流構(gòu)成：

）添加用戶子事件流

）修改用戶子事件流

???

）刪除用戶子事件流

但是你也可以根據(jù)該用例中的具體操作把它抽象成為三個(gè)用例，它所表示

的系統(tǒng)需求和單個(gè)用例的模型是完全一樣的。

應(yīng)該如何確定用例的粒度呢？在一次技術(shù)研討會(huì)上，有人問起博士，一

個(gè)系統(tǒng)需要有多少個(gè)用例？大師的回答是個(gè)，當(dāng)然他的意思是最好將用例

模型的規(guī)?？刂圃趲资畟€(gè)用例左右，這樣比較容易來管理用例模型的復(fù)雜

度。在用例個(gè)數(shù)大致確定的條件下，我們就很容易來確定用例粒度的大小。

對(duì)于較復(fù)雜的系統(tǒng)，我們需要控制用例模型一級(jí)的復(fù)雜度，所以可以將復(fù)

雜度適當(dāng)?shù)匾仆恳粋€(gè)用例的內(nèi)部，也就是讓一個(gè)用例包含較多的需求信

息量。對(duì)于比較簡(jiǎn)單的系統(tǒng)，我們則可以將復(fù)雜度適度地曝露在模型一級(jí),

也就是我們可以將較復(fù)雜的用例分解成為多個(gè)用例。

用例的粒度不但決定了用例模型級(jí)的復(fù)雜度，而且也決定了每一個(gè)用例內(nèi)

部的復(fù)雜度。我們應(yīng)該根據(jù)每個(gè)系統(tǒng)的具體情況，因時(shí)因宜地來把握各個(gè)

層次的復(fù)雜度，在盡可能保證整個(gè)用例模型的易理解性前提下決定用例的

大小和數(shù)目。

用例圖

用例圖的主要作用是描述參與者和用例之間的關(guān)系，簡(jiǎn)單的系統(tǒng)中只需要

有一個(gè)用例圖就可以把所有的關(guān)系都描述清楚。復(fù)雜的系統(tǒng)中可以有多個(gè)

用例圖，例如每個(gè)用例包都可以有一個(gè)獨(dú)立的用例圖來描述該用例包中所

有的參與者和用例的關(guān)系。

在一個(gè)用例模型中，如果參與者和用例之間存在著多對(duì)多的關(guān)系，并且他

們之間的關(guān)系比較復(fù)雜，如果在同一個(gè)用例圖中表述所有的參與者和用例

就顯得不夠清晰，這時(shí)我們可創(chuàng)建多個(gè)用例圖來分別表示各種關(guān)系。

如果想要強(qiáng)調(diào)某一個(gè)參與者和多個(gè)用例的關(guān)系，你就可以以該參與者為中

心，用一個(gè)用例圖表述出該參與者和多個(gè)用例之間的關(guān)系。在這個(gè)用例圖

中，我們強(qiáng)調(diào)的是該參與者會(huì)使用系統(tǒng)所提供的哪些服務(wù)。

如果想要強(qiáng)調(diào)某一個(gè)用例和多個(gè)參與者之間的關(guān)系，你就可以以該用例為

中心，用一個(gè)用例圖表述出該用例和多個(gè)參與者之間的關(guān)系。在這個(gè)用例

圖中，我們強(qiáng)調(diào)的是該用例會(huì)涉與到哪些參與者，或者說該用例所表示的

系統(tǒng)服務(wù)有哪些使用者。

總之在用例建模過程中，你可以根據(jù)自己的需要?jiǎng)?chuàng)建任意多個(gè)用例圖，用

不同的用例來強(qiáng)調(diào)參與者和用例之間不同的關(guān)系。但是最重要的是要考慮

整個(gè)用例模型的可理解性，如果可以用一個(gè)用例圖把意思表述清楚，就不

要再用第二個(gè)，因?yàn)樵绞呛?jiǎn)潔的模型越易于理解。

（網(wǎng)上找的，具體自己看課件）

②類建模

分析類是什么

/從高的層次描述對(duì)象

,直接與業(yè)務(wù)邏輯相關(guān)聯(lián)，但不強(qiáng)調(diào)技術(shù)細(xì)節(jié)

分析類類型

/:實(shí)體類表示系統(tǒng)內(nèi)部使用的信息

<<entity?

Name

Name

/邊界類:一種用于對(duì)參與者與系統(tǒng)內(nèi)部運(yùn)作之間的交互進(jìn)行建模的類

?boundary>>

Name

Name

/控制類：用于對(duì)一個(gè)或幾個(gè)用例所特有的控制行為進(jìn)行建模

?control?

UName

Name

邊緣和控制類用在序列圖中

（畫類圖是重點(diǎn)，好好看）

包

/包是一種常規(guī)用途的組合機(jī)制。中的一個(gè)包直接對(duì)應(yīng)于中的一個(gè)包。

在中，一個(gè)包可能含有其他包、類或者同時(shí)含有這兩者。進(jìn)行建模時(shí),

通常使用邏輯性的包，用于對(duì)模型進(jìn)行組織；使用物理性的包，用于

轉(zhuǎn)換成系統(tǒng)中的包。每個(gè)包的名稱對(duì)這個(gè)包進(jìn)行了惟一性的標(biāo)識(shí)

,包中有什么：可以包含其他的包和類，或兩者

,包之間的關(guān)系：依賴（一個(gè)包引用了另一個(gè)包的元素，另一個(gè)包改

變會(huì)影響它）和獨(dú)立

③動(dòng)態(tài)建模

狀態(tài)圖

/狀態(tài)圖是用來為對(duì)象的狀態(tài)與造成狀態(tài)改變的事件建模。的狀態(tài)機(jī)圖

主要用于建立對(duì)象類或?qū)ο蟮膭?dòng)態(tài)行為模型，表現(xiàn)一個(gè)對(duì)象所經(jīng)歷的

狀態(tài)序列，引起狀態(tài)或活動(dòng)轉(zhuǎn)移的事件，以與因狀態(tài)或活動(dòng)轉(zhuǎn)移而伴

隨的動(dòng)作。狀態(tài)機(jī)圖也可用于描述，以與全系統(tǒng)的動(dòng)態(tài)行為。

/狀態(tài)圖表示一個(gè)模型元素在其生命期間的情況：從該模型元素的開始

狀態(tài)起，響應(yīng)事件，執(zhí)行某些動(dòng)作，引起轉(zhuǎn)移到新狀態(tài)，又在新狀態(tài)

下響應(yīng)事件，執(zhí)行動(dòng)作，引起轉(zhuǎn)移到另一個(gè)狀態(tài)，如此繼續(xù)，直到終

結(jié)狀態(tài)。

StateDiagram

-State（狀態(tài)）

?Aconditionorasituationintheobject'slifecycle

?Astatediagramonlyhasoneinitialstate,butseveralfinalstate.

-Transition（變遷）

?Representrelationshipbetweentwostates

-Event（^Hi）

?Anythingaffectingtheobject

State

StateName

Intarnalaction&

Findstate

類圖測(cè)試

/（,類責(zé)任協(xié)作）使用

/迭代是軟件產(chǎn)品的內(nèi)部特點(diǎn)

六：

安什么的面向?qū)ο笤O(shè)計(jì)：根據(jù)分析模型，設(shè)計(jì)軟件

。設(shè)計(jì)的原則：模塊化，低耦合，高內(nèi)聚，支持復(fù)用

。（耦合）：不同模塊間的互聯(lián)程度

（松耦合）：一個(gè)模塊的改變對(duì)另一個(gè)影響小

（緊耦合）：一個(gè)模塊的改變對(duì)另一個(gè)有很壞的影響

Low

DataCoupling＞數(shù)據(jù)期合

StampCoupling＞標(biāo)記耦合

ControlCoupling＞控制耦合

CommonCoupling＞公共耦合

ContentCoupling＞內(nèi)容耦合

High

＞數(shù)據(jù)耦合

一個(gè)模塊訪問另一個(gè)模塊時(shí)，彼此之間是通過簡(jiǎn)單數(shù)據(jù)參數(shù)（不是控

制參數(shù)、公共數(shù)據(jù)結(jié)構(gòu)或外部變量）來交換輸入、輸出信息的。

＞標(biāo)記耦合

一組模塊通過參數(shù)表傳遞記錄信息，就是標(biāo)記耦合C這個(gè)記錄是某一

數(shù)據(jù)結(jié)構(gòu)的子結(jié)構(gòu)，而不是簡(jiǎn)單變量。其實(shí)傳遞的是這個(gè)數(shù)據(jù)結(jié)構(gòu)的地址;

＞控制耦合

如果一個(gè)模塊通過傳送開關(guān)、標(biāo)志、名字等控制信息，明顯地控制選

擇另一模塊的功能，就是控制耦合。

＞公共耦合

若一組模塊都訪問同一個(gè)公共數(shù)據(jù)環(huán)境，則它們之間的耦合就稱為公

共耦合。公共的數(shù)據(jù)環(huán)境可以是全局?jǐn)?shù)據(jù)結(jié)構(gòu)、共享的通信區(qū)、內(nèi)存的公

共覆蓋區(qū)等。

＞內(nèi)容耦合

當(dāng)一個(gè)模塊直接修改或操作另一個(gè)模塊的數(shù)據(jù),或者直接轉(zhuǎn)入另一個(gè)

模塊時(shí)，就發(fā)生了內(nèi)容耦合。此時(shí)，被修改的模塊完全依賴于修改它的模

塊。如果發(fā)生下列情形，兩個(gè)模塊之間就發(fā)生了內(nèi)容耦合

（）一個(gè)模塊直接訪問另一個(gè)模塊的內(nèi)部數(shù)據(jù)；

0一個(gè)模塊不通過正常入口轉(zhuǎn)到另一模塊內(nèi)部；

0兩個(gè)模塊有一部分程序代碼重疊（只可能出現(xiàn)在匯編語(yǔ)言中）;

0一個(gè)模塊有多個(gè)入口。

。（內(nèi)聚）：同一模塊內(nèi)各元素緊密程度

H/igAh

FunctionalCohesion

C

CommunicationalCohesionho

se

ProceduralCohesioni

no

TemporalCohesioneD

rg

LogicalCohesione

l■e

CoincidentalCohesion

LODw

功