(完整版)面向?qū)ο蟮男枨蠓治龇椒?doc

1、面向?qū)ο蟮男枨蠓治龇椒嫦驅(qū)ο蟮男枨蠓治龇椒ǖ暮诵氖抢妹嫦驅(qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷Ｐ汀Ｋ嫦驅(qū)ο箫L(fēng)格的圖形語言機(jī)制和用于指導(dǎo)需求分析的面向?qū)ο蠓椒▽W(xué)。面向?qū)ο蟮乃枷胱畛跗鹪从?0 世紀(jì) 60 年代中期的仿真程序設(shè)計(jì)語言 Simula67 。20 世紀(jì) 80 年代初出現(xiàn)的 Smalltalk 語言及其程序設(shè)計(jì)環(huán)境對面向?qū)ο蠹夹g(shù)的推廣應(yīng)用起到了顯著的促進(jìn)作用。 20 世紀(jì) 90 年代中后期誕生并迅速成熟的 UML（Unified Modeling Language ，統(tǒng)一建模語言）是面向?qū)ο蠹夹g(shù)發(fā)展的一個(gè)重要里程碑。 UML 統(tǒng)一了面向?qū)ο蠼５幕靖拍睢⑿g(shù)語和表示方法，不僅為面向?qū)?/p>

2、象的軟件開發(fā)過程提供了豐富的表達(dá)手段，而且也為軟件開發(fā)人員提供了互相交流、分享經(jīng)驗(yàn)的共用語言。本章首先介紹面向?qū)ο蟮闹饕拍詈退枷搿?在概述了 UML的全貌之后，以“家庭保安系統(tǒng)”為實(shí)例，介紹與需求分析相關(guān)的部分 UML語言機(jī)制以及基于 UML的面向?qū)ο蟮男枨蠓治龇椒ê瓦^程。第一節(jié)面向?qū)ο蟮母拍钆c思想一、面向?qū)ο蟮母拍铌P(guān)于“面向?qū)ο蟆?，有許多不同的看法。 Coad和 Yourdon 給出了一個(gè)定義：“面向?qū)ο?= 對象 + 類 + 繼承 + 消息通信”。如果一個(gè)軟件系統(tǒng)是使用這樣 4 個(gè)概念設(shè)計(jì)和實(shí)現(xiàn)的，則認(rèn)為這個(gè)軟件系統(tǒng)是面向?qū)ο蟮?。一個(gè)面向?qū)ο蟮某绦虻拿恳怀煞謶?yīng)是對象，計(jì)算是通過新的對象的

3、建立和對象之間的消息通信來執(zhí)行的。1. 對象（ object ）一般意義來講，對象是現(xiàn)實(shí)世界中存在的一個(gè)事物?？梢允俏锢淼?，如一個(gè)家具或桌子 ，如圖 5-1-1 所示，可以是概念上的 ，如一個(gè)開發(fā)項(xiàng)目。對象是構(gòu)成現(xiàn)實(shí)世界的一個(gè)獨(dú)立的單位，具有自己的靜態(tài)特征（用數(shù)據(jù)描述）和動(dòng)態(tài)特征（行為或具有的功能）。例如：人的特征：姓名、性別、年齡等，行為：衣、食、住、行等。圖 5-1-1對象的定義（ 1）對象、屬性、操作、消息定義對象可以定義為系統(tǒng)中用來描述客觀事物的一個(gè)實(shí)體，它是構(gòu)成系統(tǒng)的一個(gè)基本單位，由一組屬性和一組對屬性進(jìn)行操作的服務(wù)組成。屬性一般只能通過執(zhí)行對象的操作來改變。操作又稱為方法或服務(wù)，在

4、 C +中稱為成員函數(shù)，它描述了對象執(zhí)行的功能，若通過消息傳遞，還可以為其他對象使用。而所謂的消息是一個(gè)對象與另一個(gè)對象的通信單元，是要求某個(gè)對象執(zhí)行類中定義的某個(gè)操作的規(guī)格說明。發(fā)送給一個(gè)對象的消息定義了一個(gè)操作名和一個(gè)參數(shù)表（可能是空的），并指定某一個(gè)對象。由一個(gè)對象接收的消息則調(diào)用消息中指定的操作，并將傳遞過來的實(shí)際參數(shù)與參數(shù)表中相應(yīng)的形式參數(shù)結(jié)合起來。接收對象對消息的處理可能會(huì)改變對象中的狀態(tài)，即改變接收對象的屬性，并發(fā)送一個(gè)消息給自己或另一個(gè)對象。可以認(rèn)為，這種消息的傳遞大致等價(jià)于過程性范型中的函數(shù)調(diào)用。（ 2）對象的分類外部實(shí)體：與軟件系統(tǒng)交換信息的外部設(shè)備、相關(guān)子系統(tǒng)、操作員或用

5、戶等。信息結(jié)構(gòu)：問題信息域中的概念實(shí)體，如信號、報(bào)表、顯示信息等。需要記憶的事件：在系統(tǒng)運(yùn)行過程中可能產(chǎn)生并需要系統(tǒng)記憶的事件，如單擊鼠標(biāo)左鍵、擊打鍵盤“ ?”鍵等。角色：與軟件系統(tǒng)交互的人員所扮演的角色，如經(jīng)理、部長、技術(shù)支持等。組織機(jī)構(gòu)：有關(guān)機(jī)構(gòu)，如單位、小組等。位臵：作為系統(tǒng)環(huán)境或問題上下文的場所、位臵，如客戶地址、收件人（機(jī)構(gòu)）地址等。操作規(guī)程：如操作菜單、某種數(shù)據(jù)輸入過程等。在標(biāo)識對象時(shí)必需注意遵循“信息隱蔽”的原則：必需將對象的屬性隱藏在對象的內(nèi)部，使得從對象的外部看不到對象的信息是如何定義的，只能通過該對象界面上的操作來使用這些信息。對象的狀態(tài)通過給對象賦予具體的屬性值而得到。它

6、只能通過該對象的操作來改變。對象有兩個(gè)視圖，分別表現(xiàn)在分析設(shè)計(jì)和實(shí)現(xiàn)方面。從分析及設(shè)計(jì)方面來看 ，對象表示了一種概念 ，它們把有關(guān)的現(xiàn)實(shí)世界的實(shí)體模型化。從實(shí)現(xiàn)方面來看，一個(gè)對象表示了在應(yīng)用程序中出現(xiàn)的實(shí)體的實(shí)際數(shù)據(jù)結(jié)構(gòu)。之所以有兩個(gè)視圖，是為了把說明與實(shí)現(xiàn)分離，對數(shù)據(jù)結(jié)構(gòu)和相關(guān)操作的實(shí)現(xiàn)進(jìn)行封裝。2. 類（ class ）和實(shí)例（ instance ）把具有相同特征和行為的對象歸在一起就形成了類。類成為某些對象的模板，抽象地描述了屬于該類的全部對象的屬性和操作。屬于某個(gè)類的對象叫做該類的實(shí)例。對象的狀態(tài)則包含在它的實(shí)例變量，即實(shí)例的屬性中。如圖 5-1-2 所示。從“李杰”、“王輝”和“楊芳

7、”等對象可得到類“學(xué)生”，而這些對象就稱為該類的實(shí)例。圖 5-1-2對象、類與實(shí)例類定義了各個(gè)實(shí)例所共有的結(jié)構(gòu)，類的每一個(gè)實(shí)例都可以使用類中定義的操作。實(shí)例的當(dāng)前狀態(tài)是由實(shí)例所執(zhí)行的操作定義的。面向?qū)ο蟪绦蛟O(shè)計(jì)語言， 如 C+和 smalltalk都定義了一個(gè) new操作，可建立一個(gè)類的新實(shí)例。 C+ 還引入了構(gòu)造函數(shù)，用它在聲明一個(gè)對象時(shí)建立實(shí)例。此外，程序設(shè)計(jì)語言給出了不同的方法，來撤消（稱為析構(gòu)）實(shí)例，即當(dāng)某些對象不再使用時(shí)把它們刪去，把存儲釋放以備其他對象使用。C+給出了一個(gè)操作delete ，可以釋放一個(gè)對象所用的空間。C+還允許每個(gè)類定義自己的析構(gòu)方法，在撤消一個(gè)對象時(shí)調(diào)用它。 s

8、malltalk 沒有提供一個(gè)機(jī)制來撤消對象，但可以進(jìn)行無用單元收集。類常?？煽醋鍪且粋€(gè)抽象數(shù)據(jù)類型（ ADT）的實(shí)現(xiàn) 。但更重要的是把類看做是表示某種概念的一個(gè)模型。事實(shí)上，類是單個(gè)的語義單元，它可以很自然地管理系統(tǒng)中的對象，匹配數(shù)據(jù)定義與操作。類加進(jìn)了操作，給通常的記錄賦予了語義，可提供各種級別的可訪問性。3. 繼承 （inheritance）如果某幾個(gè)類之間具有共性的東西（信息結(jié)構(gòu)和行為），抽取出來放在一個(gè)一般類中，而將各個(gè)類的特有的東西放在特殊類中分別描述，則可建立起特殊類對一般類的繼承，如圖 5-1-3所示。各個(gè)特殊類可以從一般類中繼承共性，這樣避免了重復(fù)。圖 5-1-3特殊類對一般

9、類的繼承關(guān)系建立繼承結(jié)構(gòu)的好處：易編程、易理解代碼短 ,結(jié)構(gòu)清晰；易修改：共同部分只要在一處修改即可；易增加新類：只須描述不同部分。4. 多繼承如果一個(gè)類需要用到多個(gè)既存類的特征，可以從多個(gè)類中繼承，稱為多繼承。例如退休教師是繼承退休者和教師這兩個(gè)類的某些特征或行為而得到的一個(gè)新類。圖 5-1-4多繼承5. 多態(tài)性和動(dòng)態(tài)綁定對象互相通信，即一個(gè)對象發(fā)消息給另一個(gè)對象，執(zhí)行某些行為或又發(fā)消息給另外的對象，從而執(zhí)行系統(tǒng)的功能。發(fā)送消息的對象可能不知道另一個(gè)對象的類型是什么。 如在 C 程序中使用命令 ClearInt （） 時(shí)要嚴(yán)格區(qū)分該命令適合一個(gè)整數(shù)，還是一個(gè)整數(shù)數(shù)組。但在 C+情形， Cle

10、arInt （）對兩者都適用，它自己判斷對象是哪一個(gè)。這就是多態(tài)性。它意味著一個(gè)操作在不同類中可以有不同的實(shí)現(xiàn)方式。如清零操作ClearInt（ ） 針對消息對象是int array還是 int ，其實(shí)現(xiàn)是不同的。在一個(gè)面向?qū)ο蟮亩鄳B(tài)性語言中，可能代替一個(gè)特定類型的類型的集合就是它的子類集合。例如，圖 5-1-5 給出了 4 個(gè)類的繼承層次。使用這個(gè)繼承結(jié)構(gòu)，發(fā)送給多邊形類的所有消息，它的所有子類都能夠響應(yīng)。又例如，想要在屏幕上畫一系列多邊形，多態(tài)性允許一個(gè)表的元素可以屬于一組指定的類型而不僅僅是一個(gè)類型，可以認(rèn)為這是一個(gè)類族。通過遍歷這個(gè)表，發(fā)送給各個(gè)表元素以 draw 消息，畫出所有的多邊

11、形。圖 5-1-54 個(gè)類的繼承層次動(dòng)態(tài)綁定把函數(shù)調(diào)用與目標(biāo)代碼塊的連接延遲到運(yùn)行時(shí)進(jìn)行。這樣，只有發(fā)送消息時(shí)才與接收消息實(shí)例的一個(gè)操作綁定。它與多態(tài)性可以使我們建立的系統(tǒng)更靈活，易于擴(kuò)充。做為動(dòng)態(tài)綁定的例子，考慮在多邊形類中的方法 contains ? （ aPoint ） 。這個(gè)操作可以在類層次的各層重新實(shí)現(xiàn)，以有效利用各個(gè)子類的特殊的特征。例如，假定一個(gè)矩形有某些邊與屏幕的邊平行，這時(shí)，檢查一個(gè)點(diǎn)是否包含在矩形內(nèi)，比檢查一個(gè)點(diǎn)是否在一個(gè)一般的四邊形內(nèi)的效率要高一些。二、面向?qū)ο筌浖_發(fā)的分析模型面向?qū)ο蠓治鲞^程分為論域分析和應(yīng)用分析。論域分析建立大致的系統(tǒng)實(shí)現(xiàn)環(huán)境，應(yīng)用分析則根據(jù)特定應(yīng)用

12、的需求進(jìn)行論域分析。1.OOA分析的基本原則和任務(wù)為建立分析模型，要運(yùn)用如下的 5 個(gè)基本原則 ：建立信息域模型；描述功能；表達(dá)行為；劃分功能 、數(shù)據(jù) 、行為模型，揭示更多的細(xì)節(jié)；用早期的模型描述問題的實(shí)質(zhì)，用后期的模型給出實(shí)現(xiàn)的細(xì)節(jié)。這些原則形成 OOA的基礎(chǔ)。OOA的目的是定義所有與待解決問題相關(guān)的類（包括類的操作和屬性、類與類之間的關(guān)系以及它們表現(xiàn)出的行為）。為此，OOA需完成的任務(wù)是：（ 1）軟件工程師和用戶必須充分溝通，以了解基本的用戶需求；（ 2）必須標(biāo)識類（即定義其屬性和操作）；（ 3）必須定義類的層次；（ 4）應(yīng)當(dāng)表達(dá)對象與對象之間的關(guān)系（即對象的連接）；（ 5）必須模型化對象

13、的行為；（ 6）反復(fù)地做任務(wù)，直到模型建成。2.OOA概述目前已經(jīng)衍生許多種 OOA方法。每種方法都有各自的進(jìn)行產(chǎn)品或系統(tǒng)分析的過程，有一組可描述過程演進(jìn)的圖形標(biāo)識，以及能使得軟件工程師以一致的方式建立模型的符號體系。 現(xiàn)在廣泛使用的OOA方法有以下幾種：（ 1） Booch 方法： Booch 方法包含“ 微開發(fā)過程 ”和“宏開發(fā)過程”。微開發(fā)過程定義了一組任務(wù)，并在宏開發(fā)過程的每一步驟中反復(fù)使用它們，以維持演進(jìn)途徑。 Booch OOA 宏開發(fā)過程的任務(wù)包括標(biāo)識類和對象、標(biāo)識類和對象的語義、定義類與對象間的關(guān)系，以及進(jìn)行一系列求精從而實(shí)現(xiàn)分析模型。（ 2） Rumbaugh 方法： Rum

14、baugh和他的同事提出的對象模型化技術(shù)（ OMT）用于分析、系統(tǒng)設(shè)計(jì)和對象級設(shè)計(jì) 。分析活動(dòng)建立三個(gè)模型：對象模型（描述對象、類、層次和關(guān)系），動(dòng)態(tài)模型（描述對象和系統(tǒng)的行為），功能模型（類似于高層的 DFD，描述穿越系統(tǒng)的信息流）。（3） Coad 和 Yourdon 方法： Coad和 Yourdong 方法常常被認(rèn)為是最容易學(xué)習(xí)的 OOA方法。建模符號相當(dāng)簡單， 而且開發(fā)分析模型的導(dǎo)引直接明了。其 OOA過程概述如下：使用“要找什么”準(zhǔn)則標(biāo)識對象；定義對象之間的一般化特殊化結(jié)構(gòu)；定義對象之間的整體 部分結(jié)構(gòu)；標(biāo)識主題（系統(tǒng)構(gòu)件的表示）；定義屬性及對象之間的實(shí)例連接；定義服務(wù)及對象之間的

15、消息連接。（4） Jacobson 方法：也稱為 OOSE（面向?qū)ο筌浖こ蹋?Jacobson方法與其他方法的不同之處在于他特別強(qiáng)調(diào)使用實(shí)例（use case ）用以描述用戶與系統(tǒng)之間如何交互的場景。Jacobson 方法概述如下：標(biāo)識系統(tǒng)的用戶和它們的整體責(zé)任；通過定義參與者及其職責(zé)、使用實(shí)例、對象和關(guān)系的初步視圖，建立需求模型；通過標(biāo)識界面對象、建立界面對象的結(jié)構(gòu)視圖、表示對象行為、分離出每個(gè)對象的子系統(tǒng)和模型，建立分析模型。（ 5） Wirfs Brock 方法： Wirfs Brock 方法不明確區(qū)分分析和設(shè)計(jì)任務(wù) 。從評估客戶規(guī)格說明到設(shè)計(jì)完成 ，是一個(gè)連續(xù)的過程 。與Wirfs

16、 Brock 分析有關(guān)的任務(wù)概述如下：評估客戶規(guī)格說明；使用語法分析從規(guī)格說明中提取候選類；將類分組以表示超類；定義每一個(gè)類的職責(zé)；將職責(zé)賦予每個(gè)類；標(biāo)識類之間的關(guān)系；基于職責(zé)定義類之間的協(xié)作；建立類的層次表示；構(gòu)造系統(tǒng)的協(xié)作圖。（ 6） 統(tǒng)一的 OOA方法（ UML） 。統(tǒng)一的建模語言（ UML）已經(jīng)在企業(yè)中廣泛使用，它把 Booch、Rumbaugh和 Jacobson 等各自獨(dú)立的 OOA和OOD方法中最優(yōu)秀的特色組合成一個(gè)統(tǒng)一的方法。UML 允許軟件工程師使用由一組語法的語義的實(shí)用的規(guī)則支配的符號來表示分析模型。在 UML中用 5 種不同的視圖來表示一個(gè)系統(tǒng)，這些視圖從不同的側(cè)面描述系

17、統(tǒng)。每一個(gè)視圖由一組圖形來定義。這些視圖概述如下：用戶模型視圖：這個(gè)視圖從用戶（ 在 UML中叫做參與者）角度來表示系統(tǒng)。它用使用實(shí)例（ use case ）來建立模型，并用它來描述來自終端用戶方面的可用的場景。結(jié)構(gòu)模型視圖 ：從系統(tǒng)內(nèi)部來看 數(shù)據(jù)和功能性 。即對 靜態(tài)結(jié)構(gòu)（類、對象和關(guān)系）模型化。行為模型視圖：這種視圖表示了系統(tǒng)動(dòng)態(tài)和行為。它還描述了在用戶模型視圖和結(jié)構(gòu)模型視圖中所描述的各種結(jié)構(gòu)元素之間的交互和協(xié)作。實(shí)現(xiàn)模型視圖：將系統(tǒng)的結(jié)構(gòu)和行為表達(dá)成為易于轉(zhuǎn)換為實(shí)現(xiàn)的方式。環(huán)境模型視圖：表示系統(tǒng)實(shí)現(xiàn)環(huán)境的結(jié)構(gòu)和行為。通常， UML 分析建模的注意力放在系統(tǒng)的用戶模型和結(jié)構(gòu)模型視圖，而 U

18、ML設(shè)計(jì)建模則定位在行為模型、實(shí)現(xiàn)模型和環(huán)境模型。第二節(jié) UML概述一、 UML的語言機(jī)制在 UML 誕生之前，面向?qū)ο箢I(lǐng)域已經(jīng)涌現(xiàn)出了許多開發(fā)方法及相應(yīng)的表示機(jī)制，它們各有千秋 ，卻又有很多類似之處 ，往往讓使用者無所適從。UML在這樣的背景下應(yīng)運(yùn)而生。它主要以 BOOCH方法、 OMT方法（ 71）和 OOSE方法為基礎(chǔ)，同時(shí)也吸收了其他面向?qū)ο蠼７椒ǖ膬?yōu)點(diǎn)，形成一種概念清晰、表達(dá)能力豐富、 適用范圍廣泛的面向?qū)ο蟮臉?biāo)準(zhǔn)建模語言。UML 通過圖形化的表示機(jī)制從多個(gè)側(cè)面對系統(tǒng)的分析和設(shè)計(jì)模型進(jìn)行刻畫。它共定義了 10 種視圖，并將其分為如下 4 類：（ 1）用例圖（ use case di

19、agram ） 。從外部用戶的角度描述系統(tǒng)的功能，并指出功能的執(zhí)行者。（2）靜態(tài)圖。包括類圖（ class diagram ）、對象圖（object diagram ）和包圖（ pack diagram ）。類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，類圖的節(jié)點(diǎn)表示系統(tǒng)中的類及其屬性和操作， 類圖的邊表示類之間的聯(lián)系， 包括繼承、關(guān)聯(lián)、依賴、聚合等。對象圖是類圖一個(gè)實(shí)例，它描述在某種狀態(tài)下或在某一時(shí)間段，系統(tǒng)中活躍的對象及其關(guān)系。在對象圖，一個(gè)類可以擁有多個(gè)活躍的對象實(shí)例。包圖描述系統(tǒng)的分解結(jié)構(gòu)，它表示包 (package) 以及包之間的關(guān)系。包由子包及類組成。包之間的關(guān)系包括繼承、構(gòu)成與依賴關(guān)系。（3）行為圖。

20、包括交互圖（interactivediagram ）、狀態(tài)圖（ statechardiagram ） 與活動(dòng)圖（activity diagram），它們從不同的側(cè)面刻畫系統(tǒng)的動(dòng)態(tài)行為。交互圖描述描述對象之間的消息傳遞，它又可分為順序圖（ sequence diagram ）與 合作圖（ collaboration diagram ）兩種形式。順序圖強(qiáng)調(diào)對象之間消息發(fā)送的時(shí)間序。合作圖更強(qiáng)調(diào)對象間的動(dòng)態(tài)協(xié)作關(guān)系。合作圖也可通過消息序號之間消息發(fā)送的時(shí)間序。只不過這種表示不如順序圖那樣直觀 。狀態(tài)圖描述類的對象的動(dòng)態(tài)行為 ，它包含對象所有可能的狀態(tài)、在每個(gè)狀態(tài)下能夠響應(yīng)的事件以及事件發(fā)生時(shí)的狀態(tài)遷

21、移與響應(yīng)動(dòng)作?；顒?dòng)圖描述系統(tǒng)為完成某項(xiàng)功能而執(zhí)行的操作序例，這些操作序列可以并發(fā)和同步?；顒?dòng)圖中包含控制和信息流?？刂屏鞅硎疽粋€(gè)操作完成后對其后操作的觸發(fā)，信息流則刻畫操作之間的信息交換。（ 4）實(shí)現(xiàn)圖（ implementatin diagram）。包括構(gòu)件圖（ componentdiagram ）與 部署圖（ deploymetn diagram ），它們描述軟件實(shí)現(xiàn)系統(tǒng)的組成和分布狀況。構(gòu)件圖描述軟件實(shí)現(xiàn)系統(tǒng)中各組成部件以及它們之間的信賴關(guān)系。一個(gè)部件可能是一個(gè)資源描述文件、一個(gè)二進(jìn)制文件或一個(gè)可執(zhí)行文件。構(gòu)件圖主要用于理解和分析軟件各部分之間的相互影響程度。部署圖描述作為軟件系統(tǒng)運(yùn)行環(huán)

22、境的硬件及網(wǎng)絡(luò)的物理體系結(jié)構(gòu)，其節(jié)點(diǎn)表示實(shí)際的計(jì)算機(jī)和設(shè)備，邊表示節(jié)點(diǎn)之間物理連接關(guān)系，也可顯示連接的類型及節(jié)點(diǎn)之間的依賴性。在節(jié)點(diǎn)內(nèi)部，可以放臵可執(zhí)行部件和對象以顯示節(jié)點(diǎn)與可執(zhí)行軟件單元之間的對應(yīng)關(guān)系。部署圖對于軟件安裝工程師有著重要的參考價(jià)值。例如，圖 5-2-1 表示某大學(xué)的課程注冊管理系統(tǒng)包含3 個(gè)用例：“課表維護(hù)”、“個(gè)人課程規(guī)劃”和“選課學(xué)生花名冊查詢”。教務(wù)管理人員使用“課表維護(hù)”用例設(shè)臵或修改課程屬性（課程的時(shí)間、地點(diǎn)、上課老師等）和增刪課程；學(xué)生使用“個(gè)人課程規(guī)劃”用例選課和修改自己的個(gè)人課表，收費(fèi)管理系統(tǒng)根據(jù)每個(gè)學(xué)生的選課情況計(jì)算其應(yīng)繳費(fèi)用；老師使用“選課學(xué)生花名冊查詢”用

23、例獲取選定其所開課程的學(xué)生花名冊。圖 5-2-1課程注冊管理系統(tǒng)的用例圖圖 5-2-2 表示前述的課程注冊管理系統(tǒng)包含“教務(wù)管理人員”、 “學(xué)生”、“老師”、“課程”、“課程設(shè)臵”、“課程注冊表”、“課程注冊管理器”和“課程管理器” 8 個(gè)類。前 3 個(gè)類為一般化的“用戶”類的子類。一門“課程”可由一到多個(gè)“課程設(shè)臵”構(gòu)成，例如，對于全校性的公共基礎(chǔ)課，由于選修的學(xué)生太多，必須安排不同的老師、不同的教室和不同的時(shí)間段?！皩W(xué)生” 、“老師”與“課程設(shè)臵”之間 ，“課程注冊表”與“課程注冊管理器”之間以及“課程注冊管理器”與“課程”之間存在著關(guān)聯(lián)關(guān)系。圖 5-2-2課程注冊管理系統(tǒng)的類圖圖 5-2

24、-3 通過 UML順序圖刻畫了“個(gè)人課程規(guī)劃”用例中學(xué)生選課功能的實(shí)現(xiàn)過程。圖 5-2-3 用 UML順序圖表示“個(gè)人課程規(guī)劃”用例中的學(xué)生選課過程圖 5-2-4用 UML協(xié)作圖刻畫學(xué)生選課過程，該圖與圖5-2-3等價(jià)。圖 5-2-4 用 UML協(xié)作圖表示“個(gè)人課程規(guī)劃”用例中的學(xué)生選課過程圖 5-2-5 “課程設(shè)臵”對象的狀態(tài)圖。它表示每個(gè)“課程設(shè)臵”最多只能容納 50 個(gè)選課學(xué)生。圖 5-2-5UML狀態(tài)圖示例本章的后繼章節(jié)結(jié)合需求分析過程更具體地介紹 UML的用例圖、包圖、類圖和活動(dòng)圖，第八章將結(jié)合軟件設(shè)計(jì)過程詳細(xì)介紹順序圖、協(xié)作圖、狀態(tài)圖和活動(dòng)圖。 對其他 UML 圖形機(jī)制感興趣的讀者

25、，以及希望進(jìn)一步深入了解 UML 及其軟件開發(fā)方法的讀者。二、基于 UML的軟件開發(fā)過程雖然 UML是獨(dú)立于軟件開發(fā)過程的，即 UML能夠在幾乎任何一種軟件開發(fā)過程中使用，但是熟悉一種有代表性的面向?qū)ο蟮能浖_發(fā)過程，并知悉 UML各語言要素在過程中不同階段的應(yīng)用，對于理解 UML將大有裨益。圖 5-2-6表示一種迭代的漸進(jìn)式軟件開發(fā)過程，它包含4 個(gè)階段：初啟、細(xì)化、構(gòu)造和移交。圖 5-2-6面向?qū)ο蟮牡?、漸進(jìn)式軟件開發(fā)過程1. 初啟在初啟階段，軟件項(xiàng)目的發(fā)起人確定項(xiàng)目的主要目標(biāo)和范圍，并進(jìn)行初步的可行性分析和經(jīng)濟(jì)效益分析。2. 細(xì)化細(xì)化階段的開始標(biāo)志著項(xiàng)目的正式確立。軟件項(xiàng)目組在此階段需

26、要完成以下工作：（ 1）初步的需求分析。采用 UML的用例描述目標(biāo)軟件系統(tǒng)所有比較重要、比較有風(fēng)險(xiǎn)的用例，利用用例圖表示參與者與用例以及用例與用例之間的關(guān)系。采用 UML 的類圖表示目標(biāo)軟件系統(tǒng)所基于的應(yīng)用領(lǐng)域中的概念之間的關(guān)系。這些相互關(guān)聯(lián)的概念構(gòu)成領(lǐng)域模型。領(lǐng)域模型一方面可以幫助軟件項(xiàng)目組理解業(yè)務(wù)背景，與業(yè)務(wù)專家進(jìn)行有效溝通；另一方面，隨著軟件開發(fā)階段的不斷推進(jìn)，領(lǐng)域模型將成為軟件結(jié)構(gòu)的主要基礎(chǔ)。如果領(lǐng)域中含有明顯的流程處理成分，可以考慮利用UML的活動(dòng)圖來刻畫領(lǐng)域中的工作流，并標(biāo)識業(yè)務(wù)流程中的并發(fā)、同步等特征。（ 2）初步的高層設(shè)計(jì) 。如果目標(biāo)軟件系統(tǒng)的規(guī)模比較龐大，那么經(jīng)初步需求分析獲

27、得的用例和類將會(huì)非常多。此時(shí)，可以考慮根據(jù)用例、類在業(yè)務(wù)領(lǐng)域中的關(guān)系，或者根據(jù)業(yè)務(wù)領(lǐng)域中某種有意義的分類方法將整個(gè)軟件系統(tǒng)劃分為若干包， 利用 UML的包圖刻畫這些包及其間的關(guān)系。 這樣，用例、用例圖、類、類圖將依據(jù)包的劃分方法分屬于不同的包，從而得到整個(gè)目標(biāo)軟件系統(tǒng)的高層結(jié)構(gòu)。（ 3）部分的詳細(xì)設(shè)計(jì)。對于系統(tǒng)中某些重要的或者比較高的用例，可以采用交互圖進(jìn)一步探討其內(nèi)部實(shí)現(xiàn)過程 。同樣 ，對于系統(tǒng)中的關(guān)鍵類，也可以詳細(xì)研究其屬性和操作，并在 UML 類圖中加以表現(xiàn)。因此，這里倡導(dǎo)的軟件開發(fā)過程并不在時(shí)間軸上嚴(yán)格劃分分析與設(shè)計(jì)、總體設(shè)計(jì)與詳細(xì)設(shè)計(jì)，而是根據(jù)軟件元素（用例、類等）的重要性和風(fēng)險(xiǎn)程度

28、確立優(yōu)先細(xì)化原則，建議軟件項(xiàng)目組優(yōu)先考慮重要的、比較有風(fēng)險(xiǎn)的用例和類，不能將風(fēng)險(xiǎn)的識別和解決延遲到細(xì)化階段之后。（ 4）部分的原型構(gòu)造。在許多情形下 ，針對某些復(fù)雜的用例構(gòu)造可實(shí)際運(yùn)行的耐用消費(fèi)品型是降低技術(shù)風(fēng)險(xiǎn)、讓用戶幫助軟件項(xiàng)目組確認(rèn)用戶需求的最有效的方法 。為了構(gòu)造原型 ，需要針對用例生成詳盡的交互圖，對所有相關(guān)類給出明確的屬性和操作定義。綜上所述， 在細(xì)化階段可能需要使用的 UML語言機(jī)制包括： 描述用戶需求的用例用用例圖、表示領(lǐng)域概念模型的類圖、表示業(yè)務(wù)流程處理的活動(dòng)圖、表示系統(tǒng)高層結(jié)構(gòu)的包圖和表示用例內(nèi)部實(shí)現(xiàn)過程的交互圖等。細(xì)化階段的結(jié)束條件是，所有主要的用戶需求已通過用例和用例圖

29、得以描述；所有重要的風(fēng)險(xiǎn)已被標(biāo)識，并對風(fēng)險(xiǎn)應(yīng)對措施了如指掌；能夠比較精確地估算實(shí)現(xiàn)每一用例的時(shí)間。3. 構(gòu)造在構(gòu)造階段，開發(fā)人員通過一系列的迭代完成對所有用例的軟件實(shí)現(xiàn)工作，在每次迭代中實(shí)現(xiàn)一部分用例。以迭代方式實(shí)現(xiàn)所有用例的好處在于，用戶可以及早參與對已實(shí)現(xiàn)用例的實(shí)際評價(jià)，并提出改進(jìn)意見。這樣可有效降低大型軟件系統(tǒng)的開發(fā)風(fēng)險(xiǎn)。在實(shí)際開始構(gòu)造軟件系統(tǒng)之前，有必要預(yù)先制定迭代計(jì)劃。計(jì)劃的制定需遵循如下兩項(xiàng)原則：（ 1）用戶變?yōu)闃I(yè)務(wù)價(jià)值較大的用例應(yīng)優(yōu)先安排；（ 2）開發(fā)人員評估后認(rèn)為開發(fā)風(fēng)險(xiǎn)較高的用例應(yīng)優(yōu)先安排。在迭代計(jì)劃中，要確定迭代次數(shù)、每次迭代所需時(shí)間以及每次迭代中應(yīng)完成（或部分完成）的用例

30、。每次迭代過程由針對用例的分析、設(shè)計(jì)、編碼、測試和集成 5 個(gè)子階段構(gòu)成。在集成之后，用戶可以對用例的實(shí)現(xiàn)效果進(jìn)行評價(jià)，并提出修改意見。這些修改意見可以在本次迭代過程中立即實(shí)現(xiàn)，也可以在下次迭代中再予以考慮。構(gòu)造過程中，需要使用 UML的交互圖來設(shè)計(jì)用例的實(shí)現(xiàn)方法。 為了與設(shè)計(jì)得出的交互圖協(xié)調(diào)一致，需要修改或精化在細(xì)化階段繪制的作為領(lǐng)域模型的類圖，增加一些為軟件實(shí)現(xiàn)所必需的類、類的屬性或方法。如果一個(gè)類有復(fù)雜的生命周期行為，或者類的對象在生命周期內(nèi)需要對各種外部事件的刺激作出反應(yīng)， 應(yīng)考慮用 UNL 狀態(tài)圖來表述類的對象的行為。UML的活動(dòng)圖可以在構(gòu)造階段用來表示復(fù)雜的算法過程和有多個(gè)對象參與

31、的業(yè)務(wù)處理過程?；顒?dòng)圖尤其適用于表示過程中的并發(fā)和同步。在構(gòu)造階段的每次迭代過程中，可以對細(xì)化階段繪出的懈圖進(jìn)行修改或精化，以便包圖切實(shí)反映目標(biāo)軟件系統(tǒng)最頂層的結(jié)構(gòu)劃分狀況。綜上所核對，在構(gòu)造階段可能需要使用的UML語言機(jī)制包括：用例及用例圖。它們是開發(fā)人員在構(gòu)造階段進(jìn)行分析和設(shè)計(jì)的基礎(chǔ)。類圖。在領(lǐng)域概念模型的基礎(chǔ)上引進(jìn)為軟件實(shí)現(xiàn)所必需的類、屬性和方法。交互圖。表示針對用例設(shè)計(jì)的軟件實(shí)現(xiàn)方法。狀態(tài)圖。表示類的對象的狀態(tài)事件響應(yīng)行為。活動(dòng)圖。表示復(fù)雜的算法過程，尤其是過程中的并發(fā)和同步。包圖。表示目標(biāo)軟件系統(tǒng)的頂層結(jié)構(gòu)。構(gòu)件圖。部署圖。4. 移交在移交階段，開發(fā)人員將構(gòu)造階段獲得的軟件系統(tǒng)在用戶

32、實(shí)際工作環(huán)境（或接近實(shí)際的模擬環(huán)境）中試運(yùn)行，根據(jù)用戶的修改意見進(jìn)行少量調(diào)整。第三節(jié)基于 UML的需求分析在初步的業(yè)務(wù)需求描述已經(jīng)形成的前提下 ，基于 UML的需求分析大致可分為以下步驟：（ 1）利用用例及用例圖表示需求 。從業(yè)務(wù)需求描述出發(fā)獲取執(zhí)行者和場景；對場景進(jìn)行匯總、分類、抽象；形成用例；確定執(zhí)行者與用例、用例與用例圖之間的關(guān)系，生成用例圖。（ 2）利用包圖及類圖表示目標(biāo)軟件系統(tǒng)的總體框架結(jié)構(gòu) 。根據(jù)領(lǐng)域知識、業(yè)務(wù)需求描述和既往經(jīng)驗(yàn)設(shè)計(jì)目標(biāo)軟件系統(tǒng)的頂層架構(gòu)；從業(yè)務(wù)需求描述中提取“關(guān)鍵概念” ，形成領(lǐng)域概念模型 ；從概念模型和用例出發(fā)，研究系統(tǒng)中主要的類之間的關(guān)系，生成類圖。上述兩個(gè)步

33、驟并沒有時(shí)序關(guān)系，它們可以并行展開， 如圖 5-3-1 所示。圖 5-3-1需求分析過程本節(jié)將依次介紹上述步驟中涉及的 UML語言機(jī)制，并結(jié)合“家庭保安系統(tǒng)”實(shí)例說明每步驟中基于 UML的需求分析方法。一、開發(fā)場景場景是指從單個(gè)執(zhí)行者的角度觀察目標(biāo)軟件系統(tǒng)的功能和外部行為。這種功能通過系統(tǒng)與用戶之間的交互來表征。因此也可以說，場景是用戶與系統(tǒng)之間進(jìn)行交互的一組具體的動(dòng)作。相對于用例（見第五章第二節(jié)）而言，場景是用例的實(shí)例，而用例是某類場景的共同抽象。對場景的完整描述應(yīng)包含場景名稱、執(zhí)行者實(shí)例，前臵條件、事件流和后臵條件。例如，“家庭保安系統(tǒng)”的初步需求描述：“家庭保安系統(tǒng)”的軟件允許用戶在安裝

34、時(shí)進(jìn)行系統(tǒng)配臵，實(shí)施對傳感器的監(jiān)控并通過控制面板與用戶進(jìn)行信息交互。配臵操作包括：（ 1）指定每一傳感器的種類和編號；（ 2）設(shè)臵開、關(guān)機(jī)密碼；（ 3）指定報(bào)警電話電碼；（ 4）指定報(bào)警延遲和電話重?fù)苎舆t時(shí)間（以秒為單位）；當(dāng)軟件系統(tǒng)收到傳感器發(fā)出的數(shù)據(jù)后，判別是否出現(xiàn)異常事件。如果是，則在指定的延遲時(shí)間內(nèi)撥報(bào)警電話號碼，撥號操作將按照重?fù)苎舆t反復(fù)進(jìn)行，直至電話接通。然后軟件系統(tǒng)負(fù)責(zé)報(bào)告時(shí)間、地點(diǎn)和異常事件的性質(zhì)。開機(jī)后，軟件系統(tǒng)負(fù)責(zé)顯示當(dāng)前工作狀態(tài)，接收并處理用戶指令。根據(jù)以上描述，該系統(tǒng)具有“系統(tǒng)配臵” 、“開機(jī)” 、“關(guān)機(jī)”、“門窗監(jiān)測”、“煙霧監(jiān)測”和“復(fù)位”等場景。其中，門窗監(jiān)測場景

35、的具體描述如下：場景名稱：門窗監(jiān)測。參與執(zhí)行者實(shí)例：警報(bào)器、報(bào)警電話、顯示器和門窗監(jiān)視器。前臵條件：系統(tǒng)已開機(jī)。事件流：（1） 門窗監(jiān)視器發(fā)現(xiàn)門或窗戶發(fā)生異動(dòng)，向軟件系統(tǒng)報(bào)告異常事件。（ 2） 軟件系統(tǒng)啟動(dòng)警報(bào)器并撥報(bào)警電話號碼。（ 3） 報(bào)警電話接通后，軟件系統(tǒng)播出語音，報(bào)告異常事件發(fā)生的時(shí)間、地點(diǎn)和事件的性質(zhì)（門窗異動(dòng)）。（ 4） 系統(tǒng)在控制面板的顯示器上顯示報(bào)警時(shí)間及當(dāng)前狀態(tài)（報(bào)警：門窗異動(dòng)）。后臵條件：系統(tǒng)處于“報(bào)警”狀態(tài)。根據(jù)場景作用的不同，可以將其劃分為以下類型：（ 1）實(shí)際場景。 對實(shí)際的業(yè)務(wù)處理流程或其優(yōu)化流程的描述。實(shí)際場景是用戶需求的重要組成部分。（ 2）設(shè)想場景。 分析人

36、員對目標(biāo)軟件系統(tǒng)投入應(yīng)用后經(jīng)改進(jìn)或優(yōu)化的業(yè)務(wù)流程的描述。這種場景可視為一種紙面原型，主要用于幫助分析人員挖掘潛在的用戶需求。（ 3）評價(jià)場景。 以確認(rèn)需求或提出改進(jìn)建議為主要目的的業(yè)務(wù)流程描述。評價(jià)場景可以在用例生成后用例進(jìn)行實(shí)例化而形成，以便用戶對用例進(jìn)行評價(jià)或改進(jìn)。（ 4）培訓(xùn)場景。 面向開發(fā)人員及用戶解釋系統(tǒng)的功能和外部行為的業(yè)務(wù)流程描述。對以下問題的回答有助于分析人員獲取場景：（ 1） 目標(biāo)軟件系統(tǒng)有哪些執(zhí)行者？（ 2） 執(zhí)行者希望系統(tǒng)執(zhí)行哪些任務(wù)？（ 3） 執(zhí)行者希望獲得哪些信息？這些信息由誰生成？由誰修改？（ 4） 執(zhí)行者需要通知系統(tǒng)哪些事件？系統(tǒng)響應(yīng)這些事件時(shí)會(huì)表現(xiàn)出哪些外部行為

37、？（ 5） 系統(tǒng)將通告執(zhí)行者哪些事件？總之，確定執(zhí)行者和場景的關(guān)鍵在于理解業(yè)務(wù)領(lǐng)域和初步需求描述文檔。場景將促成開發(fā)人員和用戶對業(yè)務(wù)處理流程和目標(biāo)軟件系統(tǒng)的功能范圍的共同理解。在場景確定之后，通過對場景的匯總、分類歸并和抽象即可形成用例。二、生成用例從外部用戶的視角看 ，一個(gè)用例是執(zhí)行者（ actor ）與目標(biāo)軟件系統(tǒng)之間的一次典型的交互作用。從軟件系統(tǒng)內(nèi)部的視角出發(fā)，一個(gè)用例代表系統(tǒng)執(zhí)行的一系列動(dòng)作，動(dòng)作執(zhí)行的結(jié)果能夠被外部的執(zhí)行者所察覺。執(zhí)行者是指外部用戶或外部實(shí)體在系統(tǒng)中扮演的角色。如果多個(gè)用戶在使用目標(biāo)軟件系統(tǒng)時(shí)扮演同一角色，這些用戶將由單一執(zhí)行者表示。反之，如果一個(gè)用戶扮演多種角色，

38、則需要用多個(gè)執(zhí)行者來表示同一用戶。對用例的完整描述包括用例名稱、參與執(zhí)行者、前臵條件、一個(gè)主事件流、零到多個(gè)輔事件流和后臵條件。主事件流表示正常情況下執(zhí)行者與系統(tǒng)之間的信息交互及動(dòng)作序列，輔事件流則表示特殊情況或異常情況下的信息交互及動(dòng)作序列。顯式地分隔主、輔事件流是為了使分析人員首先聚集于正常的業(yè)務(wù)處理流程，同時(shí)也便于用例的讀者理解業(yè)務(wù)需求。用例主要來源于分析人員對場景的分類和抽象，即將相似的場景進(jìn)行歸并 ，使一個(gè)用例可以通過實(shí)例化和參數(shù)調(diào)節(jié)而涵蓋多個(gè)場景 。例如，“家庭保安系統(tǒng)“中的“開機(jī)”、“關(guān)機(jī)”、“復(fù)位” 3 個(gè)場景可以歸并為“命令處理”， 3 個(gè)場景之間的差異通過用戶命令種類的不同

39、而體現(xiàn)。類似地，“門窗監(jiān)測”、“煙霧監(jiān)測”兩個(gè)場景也可歸并為統(tǒng)一的“傳感器監(jiān)測”用例 。其實(shí) ，對于熟悉業(yè)務(wù)領(lǐng)域的分析師而言，也可以略過場景，直接從業(yè)務(wù)需求描述中獲取用例。在“家庭保安系統(tǒng)”中，執(zhí)行者有“用戶”、“傳感器”、“報(bào)警電話”和“顯示器” ，用例有“系統(tǒng)配臵” 、“命令響應(yīng)”和“傳感器監(jiān)測”。下面以“傳感器監(jiān)測”為例說明用例的一般描述格式：用例名稱：傳感器監(jiān)測。參與執(zhí)行者：各類傳感器、警報(bào)器、報(bào)警電話和顯示器。前臵條件：系統(tǒng)已開機(jī)。主事件流：（ 1）傳感器向目標(biāo)軟件系統(tǒng)上報(bào)其監(jiān)測數(shù)據(jù) ，系統(tǒng)判別監(jiān)測數(shù)據(jù)是否正常。（ 2）如果不正常，系統(tǒng)啟動(dòng)警報(bào)器，撥報(bào)警電話號碼。（ 3）報(bào)警電話接通

40、后 ，軟件系統(tǒng)播出語音，報(bào)告異常事件發(fā)生的時(shí)間、地點(diǎn)和事件的性質(zhì)。（ 4）系統(tǒng)在控制面板的顯示器上顯示報(bào)警時(shí)間及當(dāng)前狀態(tài)（報(bào)警）。輔事件流：（ 1）如果報(bào)警電話無人接聽 ，則按照重?fù)苎舆t反復(fù)撥號，直至電話接通，再轉(zhuǎn)入主事件流的步驟（ 3）。（ 2）如果重?fù)艽螖?shù)達(dá)到系統(tǒng)預(yù)設(shè)的最大次數(shù) ，電話仍無人接聽，則跳過主事件流的步驟（ 3），轉(zhuǎn)入步驟（ 4）。后臵條件 ：如果已發(fā)現(xiàn)異常監(jiān)測數(shù)據(jù) ，系統(tǒng)處于“報(bào)警“狀態(tài)；否則，系統(tǒng)處于正常的監(jiān)測狀態(tài)。三、用活動(dòng)圖表示用例用例的描述既可采用自然語言，也可采用活動(dòng)圖。后一種表示法更為精確和直觀。下面首先介紹活動(dòng)圖的語法機(jī)制，然后結(jié)合實(shí)例說明如何用活動(dòng)圖表示用例。

41、1.UML活動(dòng)圖用例的事件流或操作均表示為一系列的活動(dòng)，每個(gè)活動(dòng)在活動(dòng)圖中被表示為一個(gè)節(jié)點(diǎn)。節(jié)點(diǎn)之間的有向邊表示活動(dòng)的執(zhí)行順序。在節(jié)點(diǎn)間的連接邊上可以附加條件表達(dá)式，以表示在有向邊的源節(jié)點(diǎn)執(zhí)行完成后，如果條件成立，則開始執(zhí)行有向邊的目標(biāo)節(jié)點(diǎn)所表示的活動(dòng)；如果條件不成立，則目標(biāo)節(jié)點(diǎn)的活動(dòng)不被執(zhí)行。條件表達(dá)式一般出現(xiàn)在以菱形為源節(jié)點(diǎn)的有向邊上。菱形在活動(dòng)圖中屬特殊節(jié)點(diǎn)，用來表示條件判斷。例如，在圖 5-3-2 中，“密碼驗(yàn)證”活動(dòng)的有向邊上。如果“（密碼正確）”，則開始“開始選擇功能”活動(dòng)；否則，回到“輸入密碼“活動(dòng)。圖 5-3-2典型的活動(dòng)圖活動(dòng)圖還可以表示處理過程的并發(fā)?；顒?dòng)圖的同步條（水平或

42、垂直粗線）可以將一條有向邊分叉為多個(gè)并發(fā)執(zhí)行的分支進(jìn)程，或?qū)⒍鄠€(gè)有向邊上的進(jìn)程同步合并為一個(gè)進(jìn)程。例如，在圖5-3-2中，當(dāng)用戶選擇取款操作，輸入取款金額，且系統(tǒng)驗(yàn)證其要求的金額小于等于余額之后，系統(tǒng)分叉為兩個(gè)并發(fā)進(jìn)程：點(diǎn)鈔、出鈔和扣減余額、打印交易信息。此后，再合并為一個(gè)進(jìn)程，進(jìn)行“選擇功能”活動(dòng)。為了描述活動(dòng)的責(zé)任對象，活動(dòng)圖引進(jìn)了“泳道”的概念。泳道是由垂直長線分割出來的矩形區(qū)域，在泳道上方的對象負(fù)責(zé)該矩形區(qū)域內(nèi)的所有活動(dòng)。例如，在圖5-3-2中，類“ Customer”的對象負(fù)責(zé)“插入銀行卡”、“輸入密碼”、“選擇功能”和“輸入金額”4項(xiàng)活動(dòng)，其余活動(dòng)由類“ ATMsystem”的對象

43、負(fù)責(zé)。2. 用例的活動(dòng)圖表示針對前面所述的 “傳感器監(jiān)測” 用例，其活動(dòng)圖表示如圖5-3-3 所示。圖 5-3-3“傳感器監(jiān)測”用例的活動(dòng)圖表示四、生成用例圖執(zhí)行者與用例之間的關(guān)系有兩例種：觸發(fā)執(zhí)行與信息交換。執(zhí)行者與用例之間可能兼具這兩種關(guān)系，例如，“ 在家庭保安系統(tǒng) ”中，執(zhí)行者“用戶”在觸發(fā)用例“命令響應(yīng)”的同時(shí)，還要向用例傳送命令信息。在 UML用例圖中，從執(zhí)行者指向用例的邊表示觸發(fā)執(zhí)行和或信息交換，從用例指向執(zhí)行者的邊則表示用例將其生成的信息傳遞給執(zhí)行者。UML的用例與用例之間存在如下兩種關(guān)系：（ 1） 使用（ use）關(guān)系 。如果有一個(gè)公共的動(dòng)作序列存在于多個(gè)用例中，為避免重復(fù)，并

44、使需求模型更簡潔，可以將公共動(dòng)作序列抽出來構(gòu)成新的獨(dú)立用例。這樣，原來的多個(gè)用例與新的用例之間便通過使用關(guān)系來連接。例如，在“家庭保安系統(tǒng)”中“系統(tǒng)配臵”和“命令響應(yīng)”兩個(gè)用例使用公共的“密碼驗(yàn)證”子用例。（ 2） 擴(kuò)展（ extend ）關(guān)系。如果一個(gè)用例的動(dòng)作序列完全包含另一個(gè)用例的動(dòng)作序列，且前者含有后者所不具備的一些特殊情況下的處理動(dòng)作，則稱前者擴(kuò)展后者。例如，圖 5-3-4 的“傳感器監(jiān)測”用例僅包含正常的處理流程，而“報(bào)警電話未接通”用例除正常流程處還增加了“重復(fù)撥號”以及“重?fù)艽螖?shù)達(dá)到最大次數(shù)仍無人接聽”這兩種異常處理動(dòng)作。圖 5-3-4“家庭保安系統(tǒng)”的用例圖五、建立頂層架構(gòu)頂

45、層架構(gòu)的 主要目的是為后續(xù)的分析 和設(shè)計(jì)活動(dòng)建立一種結(jié)構(gòu)和分劃 ，以便開發(fā)人員在不同的開發(fā)階段 ，以及同一開發(fā)階段的不同開發(fā)人員，能夠聚焦于系統(tǒng)的不同部分。頂層架構(gòu)是分析和設(shè)計(jì)的階段成果的承載體。隨著開發(fā)過程的推進(jìn)，框架中的內(nèi)容不斷豐富、翔實(shí)，最終演進(jìn)為完整的面向?qū)ο筌浖Y(jié)構(gòu)。UML 包圖是表示頂層架構(gòu)的適當(dāng)機(jī)制，因此，下面首先介紹包圖的語法機(jī)制，然后探討建立頂層架構(gòu)的方法與原則。1.UML包圖包是 UML 對類進(jìn)行分組的一種機(jī)制。 可以從某種視角將具有比較密切的關(guān)聯(lián)的一些類劃分為一個(gè)包，分屬于不同包的兩個(gè)類之間的關(guān)聯(lián)則比較松散。由此可見，對于大型軟件系統(tǒng)而言，包的劃分是實(shí)現(xiàn)“分而治之”的重要

46、技術(shù)手段。包之間存在兩種關(guān)系：依賴和構(gòu)成。如果對類A 的修改將導(dǎo)致類B 的改變，則稱 B 依賴于 A。如果兩個(gè)包中存在具有依賴關(guān)系的兩個(gè)類，則認(rèn)為這兩個(gè)類分屬的包之間存在依賴關(guān)系。例如，圖5-3-5中的“訂單”包依賴于“客戶 ”包。包的構(gòu)成關(guān)系是指包是可以嵌套的，即包中不僅可包含類，還可以包含子包。在圖5-3-5中，“領(lǐng)域”包由“訂單”和“客戶”兩個(gè)子包構(gòu)成。圖5-3-5中，“數(shù)據(jù)庫接口”類僅定義抽象的數(shù)據(jù)訪問、數(shù)據(jù)操作的接口函數(shù)，而“Oracle 接口”包和“ DB2接口”包則基于具體的數(shù)據(jù)庫管理系統(tǒng)逐一實(shí)現(xiàn)了通用接口中定義的抽象接口函數(shù)。圖 5-3-5包圖示例為了表示軟件架構(gòu)，還需要在包之

47、間引進(jìn)一種稱為“連接器”的邊。連接器用來表示包之間的信息傳遞、事件發(fā)送和軟件調(diào)用等關(guān)系，且有單向和雙向（即無向）之分。2. 軟件頂層架構(gòu)的設(shè)計(jì)建立軟件系統(tǒng)頂層架構(gòu)的基本方法是，結(jié)合實(shí)際需求，從既往的架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)?zāi)Ｐ椭羞x取適當(dāng)者，再進(jìn)行微調(diào)或局部改造。目前有如下幾種主要的架構(gòu)模式：（ 1）流程處理模式 。流程處理系統(tǒng)以算法和數(shù)據(jù)引進(jìn)中心，其系統(tǒng)功能由一系列的處理步驟構(gòu)成，相鄰的處理步驟之間以數(shù)據(jù)流通管道相互連接。圖 5-3-6 表示具有 3 處理步驟的流程處理模式。這些處理步驟都使用公共的系統(tǒng)服務(wù)（例如數(shù)據(jù)庫訪問服務(wù)），處理命令來自用戶界面，處理的進(jìn)度和結(jié)果也通過用戶界面呈現(xiàn)。圖 5-3-6流程

48、處理模式流程處理模式僅適合于采用批處理方式的軟件系統(tǒng)，不適合于交互式系統(tǒng)。（ 2）客戶服務(wù)器模式。如圖 5-3-7 所示，客戶端負(fù)責(zé)用戶輸入和處理結(jié)果的呈現(xiàn)，服務(wù)器端則負(fù)責(zé)后臺的業(yè)務(wù)邏輯處理。圖 5-3-7 客戶服務(wù)器模式（ 3）模型視圖控制器（ MVC）模式。如圖 5-3-8 所示，該模式將整個(gè)軟件系統(tǒng)劃分為模型， 視圖和控制器 3 個(gè)部分。模型負(fù)責(zé)維護(hù)并保存具有持久性的業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)業(yè)務(wù)處理功能，并將業(yè)務(wù)數(shù)據(jù)的變化情況及時(shí)通知視圖；視圖負(fù)責(zé)呈現(xiàn)模型的業(yè)務(wù)數(shù)據(jù)，響應(yīng)模型變化通知，更新呈現(xiàn)形式，并向控制器傳遞用戶的界面動(dòng)作；控制器負(fù)責(zé)將用戶的界面動(dòng)作映射為模型中業(yè)務(wù)處理功能并實(shí)際調(diào)用之，然后根

49、據(jù)模型返回的業(yè)務(wù)處理結(jié)果選擇新的視圖。 MVC模式特別適合于分布應(yīng)用軟件，尤其是 Web應(yīng)用系統(tǒng)。圖 5-3-8模型視圖控制器模式（ 4）分層模式。如圖 5-3-9 所示，分層模式將整個(gè)軟件系統(tǒng)分為若干層次，最頂層直接面向用戶提供軟件系統(tǒng)的操作界面，其余各層為緊鄰其上的層次提供服務(wù)。 層次劃時(shí)分的主要原則是： 較易變化的軟件部分 （例如用戶界面、與業(yè)務(wù)邏輯緊密相關(guān)的部件）臵于較高層次，較穩(wěn)定的軟件部分（例如公共的技術(shù)服務(wù)部件）則位于較低層次；每一層次盡量只訪問其緊鄰下層提供的服務(wù)，避免越級訪問，尤其要避免逆向訪問（上層模塊為下層模塊提供服務(wù)）；在許多情況下，可以將目標(biāo)軟件系統(tǒng)的外部接口臵入較低層次，目標(biāo)軟件系統(tǒng)其余部分對外部系統(tǒng)的訪問或操作均通過這些