上傳人：x***

認(rèn)證信息

認(rèn)證類型：個人認(rèn)證

認(rèn)證主體：楊**（實(shí)名認(rèn)證）

IP屬地：浙江

IP屬地：浙江 上傳時間：2022-04-13 格式：DOCX 頁數(shù)：43 大?。?58.48KB 積分：30 舉報 版權(quán)申訴

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

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

3、應(yīng)是對象， 計算是通 過新的對象的建立和對象之間的消息通信來執(zhí)行的。1.對象object一般意義來講，對象是現(xiàn)實(shí)世界中存在的一個事物。 可以是物理的，如一個家具或桌子, 如圖5-1-1所示，可以是概念上的，如一個開發(fā)工程。對象是構(gòu)成現(xiàn)實(shí)世界的一個獨(dú)立的單 位，具有自己的靜態(tài)特征用數(shù)據(jù)描述和動態(tài)特征行為或具有的功能。例如：人的特征：、 性別、年齡等，行為：衣、食、住、行等。子柱格寸量萱色 毎買售重計 MX怖尺重位顫 五購梢稱鴨 .y圖5-1-1對象的定義1對象、屬性、操作、消息定義對象可以定義為系統(tǒng)中用來描述客觀事物的一個實(shí)體，它是構(gòu)成系統(tǒng)的一個根本單位，由一組屬性和一組對屬性進(jìn)行操作的效勞組成

4、。屬性一般只能通過執(zhí)行對象的操作來改變操作又稱為方法或效勞，在 C + 中稱為成員函數(shù)，它描述了對象執(zhí)行的功能，假設(shè)通過 消息傳遞，還可以為其他對象使用。而所謂的消息是一個對象與另一個對象的通信單元， 是要求某個對象執(zhí)行類中定義的某個 操作的規(guī)格說明。發(fā)送給一個對象的消息定義了一個操作名和一個參數(shù)表可能是空的，并 指定某一個對象。 由一個對象接收的消息那么調(diào)用消息中指定的操作， 并將傳遞過來的實(shí)際參數(shù) 與參數(shù)表中相應(yīng)的形式參數(shù)結(jié)合起來。 接收對象對消息的處理可能會改變對象中的狀態(tài)， 即改 變接收對象的屬性， 并發(fā)送一個消息給自己或另一個對象。 可以認(rèn)為， 這種消息的傳遞大致等 價于過程性范型中

5、的函數(shù)調(diào)用。2對象的分類外部實(shí)體：與軟件系統(tǒng)交換信息的外部設(shè)備、相關(guān)子系統(tǒng)、操作員或用戶等。信息結(jié)構(gòu)：問題信息域中的概念實(shí)體 ，如信號、報表、顯示信息等。需要記憶的事件：在系統(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)識對象時必需注意遵循“信息隱蔽的原那么：必需將對象的屬性隱藏在對象的內(nèi)部， 使得從對象的外部看不到對象的信息是如何定義的，

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

7、 對象的狀態(tài)那么包含 在它的實(shí)例變量，即實(shí)例的屬性中。如圖 5-1-2 所示。從“李杰、“王輝和“楊芳等 對象可得到類“學(xué)生，而這些對象就稱為該類的實(shí)例運(yùn)動運(yùn)動場芳楊芳北京 系統(tǒng)皓構(gòu)1979.125418 室月名別気業(yè)年址翳書豔姓性轟專生住亦<實(shí)出圖5-1-2 對象、類與實(shí)例類定義了各個實(shí)例所共有的結(jié)構(gòu)，類的每一個實(shí)例都可以使用類中定義的操作。實(shí)例的當(dāng)前狀態(tài)是由實(shí)例所執(zhí)行的操作定義的。面向?qū)ο蟪绦蛟O(shè)計語言，如C+和Smalltalk都定義了一個new操作，可建立一個類的 新實(shí)例。C+還引入了構(gòu)造函數(shù)，用它在聲明一個對象時建立實(shí)例。此外，程序設(shè)計語言給 出了不同的方法，來撤消稱為析構(gòu)實(shí)例，

8、即當(dāng)某些對象不再使用時把它們刪去，把存儲釋 放以備其他對象使用。C+給出了一個操作delete，可以釋放一個對象所用的空間。C+還 允許每個類定義自己的析構(gòu)方法，在撤消一個對象時調(diào)用它。Smalltalk沒有提供一個機(jī)制來撤消對象，但可以進(jìn)行無用單元收集。類常?？煽醋鍪且粋€抽象數(shù)據(jù)類型ADT的實(shí)現(xiàn)。但更重要的是把類看做是表示某種 概念的一個模型。事實(shí)上，類是單個的語義單元，它可以很自然地管理系統(tǒng)中的對象，匹配數(shù) 據(jù)定義與操作。類加進(jìn)了操作，給通常的記錄賦予了語義，可提供各種級別的可訪問性。3.繼承inheritanee 如果某幾個類之間具有共性的東西信息結(jié)構(gòu)和行為，抽取出來放在一個一般類中，而

9、將各個類的特有的東西放在特殊類中分別描述，那么可建立起特殊類對一般類的繼承，如圖5-1-3所示。各個特殊類可以從一般類中繼承共性，這樣防止了重復(fù)。圖5-1-3特殊類對一般類的繼承關(guān)系建立繼承結(jié)構(gòu)的好處:易編程、易理解代碼短，結(jié)構(gòu)清晰;易修改：共同局部只要在一處修改即可;-易增加新類：只須描述不同局部4.多繼承如果一個類需要用到多個既存類的特征， 可以從多個類中繼承，稱為多繼承。例如退休教 師是繼承退休者和教師這兩個類的某些特征或行為而得到的一個新類。圖5-1-4 多繼承對象互相通信，即一個對象發(fā)消息給另一個對象，執(zhí)行某些行為或又發(fā)消息給另外的對象， 從而執(zhí)行系統(tǒng)的功能。發(fā)送消息的對象可能不知道

10、另一個對象的類型是什么。如在C程序中使用命令Clearlnt時要嚴(yán)格區(qū)分該命令適合一個整數(shù)，還是一個整數(shù)數(shù)組。但在C+情形，Clearlnt 對兩者都適用，它自己判斷對象是哪一個。這就是多態(tài)性。它意味 著一個操作 在不同類中可以有不同的實(shí)現(xiàn)方式。如清零操作 Clearlnt 針對消息對象是int array還是int，其實(shí)現(xiàn)是不同的。在一個面向?qū)ο蟮亩?態(tài)性語言中，可能代替一個特定類型的類型的集合就是它的子類集合。例如，圖5-1-5給出了 4個類的繼承層次。使用這個繼承結(jié)構(gòu)，發(fā)送給多邊形類的所有 消息，它的所有子類都能夠響應(yīng)。又例如，想要在屏幕上畫一系列多邊形，多態(tài)性允許一個表 的元素可以屬于

11、一組指定的類型而不僅僅是一個類型，可以認(rèn)為這是一個類族。通過遍歷這個 表，發(fā)送給各個表元素以draw消息，畫出所有的多邊形圖5-1-54個類的繼承層次動態(tài)綁定把函數(shù)調(diào)用與目標(biāo)代碼塊的連接延遲到運(yùn)行時進(jìn)行。這樣，只有發(fā)送消息時才與接收消息實(shí)例的一個操作綁定。它與多態(tài)性可以使我們建立的系統(tǒng)更靈活，易于擴(kuò)充。做為動 態(tài)綁定的例子，考慮在多邊形類中的方法 con tai ns ? aPoi nt。這個操作可以在類層次的各層重新實(shí)現(xiàn)，以有效利用各個子類的特殊的特征。 例如，假定一個矩形有某些邊與屏幕的邊 平行，這時，檢查一個點(diǎn)是否包含在矩形內(nèi)， 比檢查一個點(diǎn)是否在一個一般的四邊形內(nèi)的效率 要高一些。二、

12、面向?qū)ο筌浖_發(fā)的分析模型面向?qū)ο蠓治鲞^程分為論域分析和應(yīng)用分析。論域分析建立大致的系統(tǒng)實(shí)現(xiàn)環(huán)境，應(yīng)用分析那么根據(jù)特定應(yīng)用的需求進(jìn)行論域分析。1.00A分析的根本原那么和任務(wù)為建立分析模型，要運(yùn)用如下的5個根本原那么：建立信息域模型；描述功能；表達(dá)行為；劃分功能、數(shù)據(jù)、行為模型，揭示更多的細(xì)節(jié)；用早期的模型描述問題的實(shí)質(zhì)， 用后期的模型給出實(shí)現(xiàn)的細(xì)節(jié)。這些原那么形成 00A的根底OOA 的目的是定義所有與待解決問題相關(guān)的類包括類的操作和屬性、類與類之間的關(guān) 系以及它們表現(xiàn)出的行為。為此， OOA 需完成的任務(wù)是：1軟件工程師和用戶必須充分溝通，以了解根本的用戶需求；2必須標(biāo)識類即定義其屬性和操

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

14、 以及進(jìn)行一系列求精從而實(shí)現(xiàn)分析模型。2 Rumbaugh 方法： Rumbaugh 和他的同事提出的對象模型化技術(shù) OMT 用于 分析、系統(tǒng)設(shè)計和對象級設(shè)計 。分析活動建立三個模型：對象模型描述對象、類、層次和 關(guān)系，動態(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)識主題

15、系統(tǒng)構(gòu)件的表示；定義屬性及對象之間的實(shí)例連接；定義效勞及對象之間的消息連接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)視圖、表示對象行為、別離出每個對象的子系 統(tǒng)和模型，建立分析模型。5Wirfs Brock方法：Wirfs -Brock方法不明確區(qū)分分析和設(shè)計任務(wù) 。從評估客戶

16、 規(guī)格說明到設(shè)計完成，是一個連續(xù)的過程。與Wirfs -Brock分析有關(guān)的任務(wù)概述如下：評估客戶規(guī)格說明；使用語法分析從規(guī)格說明中提取候選類；將類分組以表示超類；定義每一個類的職責(zé)；將職責(zé)賦予每個類；標(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)秀的特色組 合成一個統(tǒng)一的方法。 UML 允許軟件工程師使用由一組語法的語義的實(shí)用的規(guī)那么支配的符號 來表示分析模型。在 UML

17、中用 5 種不同的視圖來表示一個系統(tǒng)，這些視圖從不同的側(cè)面描述系統(tǒng)。每一個 視圖由一組圖形來定義。這些視圖概述如下：用戶模型視圖：這個視圖從用戶 在 UML 中叫做參與者角度來表示系統(tǒng)。它用使用實(shí)例 use case 來建立模型，并用它來描述來自終端用戶方面的可用的場景結(jié)構(gòu)模型視圖：從系統(tǒng)內(nèi)部來看 數(shù)據(jù)和功能性。即對 靜態(tài)結(jié)構(gòu)類、對象和關(guān)系 模型化。行為模型視圖：這種視圖表示了系統(tǒ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 分析

18、建模的注意力放在系統(tǒng)的用戶模型和結(jié)構(gòu)模型視圖，而 UML 設(shè)計建模那么定位在行為模型、實(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 方法為根底，同時也吸收了其他面向?qū)?象建模方法的優(yōu)點(diǎn)， 形成一種概念清晰、 表達(dá)能力豐富、 適用范圍廣泛的面向?qū)ο蟮臉?biāo)準(zhǔn)建模它共定義了UML 通過圖形化的表示機(jī)制從多個側(cè)面對系統(tǒng)的分析和設(shè)計模型進(jìn)行刻畫 10

19、種視圖，并將其分為如下 4 類：1用例圖 use case diagram 。從外部用戶的角度描述系統(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)、依賴、聚合等。對象圖是類圖一個實(shí)例，它描述在某 種狀態(tài)下或在某一時間段， 系統(tǒng)中活潑的對象及其關(guān)系。 在對象圖， 一個類可以擁有多個活潑 的對象實(shí)例。包圖描述系統(tǒng)的分解結(jié)構(gòu)，它表示包 (package) 以及包之間的關(guān)系。包由子包及 類

20、組成。包之間的關(guān)系包括繼承、構(gòu)成與依賴關(guān)系。3行為圖。包括交互圖 interactive diagram 、狀態(tài)圖 statechar diagram 與 活動圖 activity diagram ，它們從不同的側(cè)面刻畫系統(tǒng)的動態(tài)行為。交互圖描述描述對象 之間的消息傳遞，它又可分為順序圖 sequence diagram 與 合作圖 collaboration diagram 兩種形式。順序圖強(qiáng)調(diào)對象之間消息發(fā)送的時間序。合作圖更強(qiáng)調(diào)對象間的動態(tài)協(xié) 作關(guān)系。合作圖也可通過消息序號之間消息發(fā)送的時間序。 只不過這種表示不如順序圖那樣直 觀 。狀態(tài)圖描述類的對象的動態(tài)行為 ，它包含對象所有可能的狀

21、態(tài)、 在每個狀態(tài)下能夠響應(yīng) 的事件以及事件發(fā)生時的狀態(tài)遷移與響應(yīng)動作。 活動圖描述系統(tǒng)為完成某項功能而執(zhí)行的操作 序例，這些操作序列可以并發(fā)和同步。 活動圖中包含控制和信息流。 控制流表示一個操作完成后對其后操作的觸發(fā)，信息流那么刻畫操作之間的信息交換4 實(shí)現(xiàn)圖 implementatin diagram 。包括構(gòu)件圖 component diagram 與 部 署圖 deploymetn diagram ，它們描述軟件實(shí)現(xiàn)系統(tǒng)的組成和分布狀況。構(gòu)件圖描述軟件 實(shí)現(xiàn)系統(tǒng)中各組成部件以及它們之間的信賴關(guān)系。 一個部件可能是一個資源描述文件、 一個二 進(jìn)制文件或一個可執(zhí)行文件。 構(gòu)件圖主要用于理解

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

23、根據(jù)每個學(xué)生的選課情況計算其應(yīng)繳費(fèi)用； 老師使用 “選 課學(xué)生花名冊查詢用例獲取選定其所開課程的學(xué)生花名冊。It掙骨理人酗諜&權(quán)椚2O父吳<o芝袖進(jìn)i!T聲生兌密*1骨耐圖5-2-1 課程注冊管理系統(tǒng)的用例圖圖5-2-2表示前述的課程注冊管理系統(tǒng)包含“教務(wù)管理人員、“學(xué)生、“老師、“課程、“課程設(shè)置、“課程注冊表、“課程注冊管理器和“課程管理器8個類。前3個類為一般化的“用戶類的子類。一門“課程可由一到多個“課程設(shè)置構(gòu)成，例如， 對于全校性的公共根底課，由于選修的學(xué)生太多，必須安排不同的老師、不同的教室和不同的 時間段?！皩W(xué)生、“老師與“課程設(shè)置之間 ，“課程注冊表與“課程注冊管

24、理器 之間以及“課程注冊管理器與“課程之間存在著關(guān)聯(lián)關(guān)系。0 >11«Ft lift-Tfvfr研盤if(rriMw set'ascQltoffi Um Cm View)li triMii IZ ac View h1 一 匚iF1£ 附戶圖5-2-2課程注冊管理系統(tǒng)的類圖圖5-2-3通過UML順序圖刻畫了“個人課程規(guī)劃用例中學(xué)生選課功能的實(shí)現(xiàn)過程予雹阡&1|舸屬弓找賈2 I *i |.*XiSiULSrrii2 M.l ifCMMCNhri;*0圖5-2-3 用UML順序圖表示“個人課程規(guī)劃用例中的學(xué)生選課過程圖5-2-4用UML協(xié)作圖刻畫學(xué)生選課過程

25、，該圖與圖5-2-3等價。I r-nk圖5-2-4 用UML協(xié)作圖表示“個人課程規(guī)劃用例中的學(xué)生選課過程圖5-2-5 “課程設(shè)置對象的狀態(tài)圖。它表示每個“課程設(shè)置最多只能容納50個選課學(xué)生。itrainw j簾 m*C auBF*i/raMun<- Jcn|n 氏 fl 就CTA眩吃前1誠“iil rCuet-kd®l Ml 出 prgiMcird W吋eh1曲rumnJjii “JI也1|圖5-2-5 UML狀態(tài)圖例如本章的后繼章節(jié)結(jié)合需求分析過程更具體地介紹 UML的用例圖、包圖、類圖和活動圖，第八章將結(jié)合軟件設(shè)計過程詳細(xì)介紹順序圖、協(xié)作圖、狀態(tài)圖和活動圖。對其他UML圖形

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

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

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

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

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

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

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

33、頂層結(jié)構(gòu)構(gòu)件圖部署圖或接近實(shí)際的模4.移交在移交階段， 開發(fā)人員將構(gòu)造階段獲得的軟件系統(tǒng)在用戶實(shí)際工作環(huán)境擬環(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)驗設(shè)計目標(biāo)軟件系統(tǒng)的頂層架構(gòu)；從業(yè)務(wù)需求描述中提取“關(guān)鍵概念，形成領(lǐng)域概念模型；從概念模型和用

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

35、步需求描述： “家庭保安系統(tǒng)的軟件允許用戶在安裝時進(jìn)行系統(tǒng)配置，實(shí)施對傳感器的監(jiān)控并通過控制面板與用戶進(jìn)行信息交互。配置操作包括：1指定每一傳感器的種類和編號；2設(shè)置開、關(guān)機(jī)密碼；3指定報警 電碼；4指定報警延遲和重?fù)苎舆t時間以秒為單位；當(dāng)軟件系統(tǒng)收到傳感器發(fā)出的數(shù)據(jù)后， 判別是否出現(xiàn)異常事件。 如果是， 那么在指定的延遲時間內(nèi)撥報警 號碼，撥號操作將按照重?fù)苎舆t反復(fù)進(jìn)行， 直至 接通。然后軟件系統(tǒng)負(fù)責(zé) 報告時間、地點(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)

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

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

38、場景將促成開發(fā) 人員和用戶對業(yè)務(wù)處理流程和目標(biāo)軟件系統(tǒng)的功能范圍的共同理解。 在場景確定之后， 通過對 場景的匯總、分類歸并和抽象即可形成用例。二、生成用例從外部用戶的視角看 ，一個用例是執(zhí)行者 actor 與目標(biāo)軟件系統(tǒng)之間的一次典型的交 互作用。 從軟件系統(tǒng)內(nèi)部的視角出發(fā)， 一個用例代表系統(tǒng)執(zhí)行的一系列動作， 動作執(zhí)行的結(jié)果 能夠被外部的執(zhí)行者所覺察。 執(zhí)行者是指外部用戶或外部實(shí)體在系統(tǒng)中扮演的角色。 如果多個 用戶在使用目標(biāo)軟件系統(tǒng)時扮演同一角色， 這些用戶將由單一執(zhí)行者表示。 反之，如果一個用 戶扮演多種角色，那么需要用多個執(zhí)行者來表示同一用戶。對用例的完整描述包括用例名稱、參與執(zhí)行者

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

40、用例。其實(shí)，對于熟悉業(yè)務(wù)領(lǐng)域的分析師而言，也可以略過場景，直接從業(yè)務(wù)需求描述 中獲取用例。在“家庭保安系統(tǒng)中，執(zhí)行者有“用戶、“傳感器、“報警和“顯示器用例有“系統(tǒng)配置、“命令響應(yīng)和“傳感器監(jiān)測。下面以“傳感器監(jiān)測為例說明用 例的一般描述格式：用例名稱：傳感器監(jiān)測。參與執(zhí)行者：各類傳感器、警報器、報警和顯示器。前置條件：系統(tǒng)已開機(jī)。主事件流：1傳感器向目標(biāo)軟件系統(tǒng)上報其監(jiān)測數(shù)據(jù) ，系統(tǒng)判別監(jiān)測數(shù)據(jù)是否正常。2如果不正常，系統(tǒng)啟動警報器，撥報警 號碼。3報警接通后 ，軟件系統(tǒng)播出語音，報告異常事件發(fā)生的時間、地點(diǎn)和事件的性質(zhì)。4系統(tǒng)在控制面板的顯示器上顯示報警時間及當(dāng)前狀態(tài)報警輔事件流：1如果報

41、警 無人接聽 ，那么按照重?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)處于“報警“狀態(tài)；否那么，系統(tǒng)處于正常的 監(jiān)測狀態(tài)。三、用活動圖表示用例用例的描述既可采用自然語言， 也可采用活動圖。 后一種表示法更為精確和直觀。 下面首 先介紹活動圖的語法機(jī)制，然后結(jié)合實(shí)例說明如何用活動圖表示用例。1.UML 活動圖用例的事件流或操作均表示為一系列的活動， 每個活動在活動圖中被表示為一個節(jié)點(diǎn)。 節(jié) 點(diǎn)之間的有向邊表示活動的執(zhí)行順序。 在節(jié)點(diǎn)間的連接邊上可以

42、附加條件表達(dá)式，以表示在有向邊的源節(jié)點(diǎn)執(zhí)行完成后，如果條件成立，那么開始執(zhí)行有向邊的目標(biāo)節(jié)點(diǎn)所表示的活動；如果條件不成立，那么目標(biāo)節(jié)點(diǎn)的活動不被執(zhí)行。條件表達(dá)式一般出現(xiàn)在以菱形為源節(jié)點(diǎn)的有向邊 上。菱形在活動圖中屬特殊節(jié)點(diǎn)，用來表示條件判斷。例如，在圖5-3-2中，“密碼驗證活動的有向邊上。如果“密碼正確，貝U開始“開始選擇功能活動；否那么，回到“輸入 密碼“活動。骨押MBJ*片呦點(diǎn)事卄対斟V扎童.I宙切、廠枷ht mi卡闿A b律國圖5-3-2 典型的活動圖活動圖還可以表示處理過程的并發(fā)。 活動圖的同步條 水平或垂直粗線 可以將一條有向 邊分叉為多個并發(fā)執(zhí)行的分支進(jìn)程， 或?qū)⒍鄠€有向邊上的進(jìn)

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

44、感器監(jiān)測用例，其活動圖表示如圖圖5-3-3“傳感器監(jiān)測用例的活動圖表示四、生成用例圖執(zhí)行者與用例之間的關(guān)系有兩例種：觸發(fā)執(zhí)行與信息交換。執(zhí)行者與用例之間可能兼具這 兩種關(guān)系，例如，“在家庭保安系統(tǒng)中，執(zhí)行者“用戶在觸發(fā)用例“命令響應(yīng)的同時， 還要向用例傳送命令信息。在UML用例圖中，從執(zhí)行者指向用例的邊表示觸發(fā)執(zhí)行和/或信息交換，從用例指向執(zhí)行者的邊那么表示用例將其生成的信息傳遞給執(zhí)行者。UML的用例與用例之間存在如下兩種關(guān)系:1使用use丨關(guān)系。如果有一個公共的動作序列存在于多個用例中，為防止重復(fù), 并使需求模型更簡潔，可以將公共動作序列抽出來構(gòu)成新的獨(dú)立用例。 這樣，原來的多個用例與新的用

45、例之間便通過使用關(guān)系來連接。例如，在“家庭保安系統(tǒng)中“系統(tǒng)配置和“命令響應(yīng)兩個用例使用公共的“密碼驗證子用例。2擴(kuò)展extend丨關(guān)系。如果一個用例的動作序列完全包含另一個用例的動作序列，且前者含有后者所不具備的一些特殊情況下的處理動作，那么稱前者擴(kuò)展后者。例如，圖5-3-4的“傳感器監(jiān)測用例僅包含正常的處理流程，而“報警未接通用例除正常流程處還增 加了“重復(fù)撥號以及“重?fù)艽螖?shù)到達(dá)最大次數(shù)仍無人接聽這兩種異常處理動作圖5-3-4“家庭保安系統(tǒng)的用例圖五、建立頂層架構(gòu)頂層架構(gòu)的 主要目的是為后續(xù)的分析 和設(shè)計活動建立一種結(jié)構(gòu)和分劃 ，以便開發(fā)人員 在不同的開發(fā)階段 ，以及同一開發(fā)階段的不同開發(fā)人

46、員，能夠聚焦于系統(tǒng)的不同局部。頂層 架構(gòu)是分析和設(shè)計的階段成果的承載體。 隨著開發(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)的一些類劃 分為一個包， 分屬于不同包的兩個類之間的關(guān)聯(lián)那么比擬松散。 由此可見，對于大型軟件系統(tǒng)而 言，包的劃分是實(shí)現(xiàn)“分而治之的重要技術(shù)手段。包之間存在兩種關(guān)系：依賴和構(gòu)成。如果對類 A 的修改將導(dǎo)致類 B 的改變，那么稱 B 依賴

47、于 A 。如果兩個包中存在具有依賴關(guān)系的兩個類， 那么認(rèn)為這兩個類分屬的包之間存在依賴關(guān)系。 例如，圖 5-3-5 中的“訂單包依賴于“ 客戶 包。包的構(gòu)成關(guān)系是指包是可以嵌套的， 即包中不僅可包含類，還可以包含子包。在圖 5-3-5 中，“領(lǐng)域包由“訂單和“客戶 兩個子包構(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)，還需要在包之間引進(jìn)一種稱為“連接器的邊。連接器用來表示包之 間的信息傳遞、事件發(fā)送和軟件調(diào)用等關(guān)系

48、，且有單向和雙向即無向之分。2.軟件頂層架構(gòu)的設(shè)計建立軟件系統(tǒng)頂層架構(gòu)的根本方法是，結(jié)合實(shí)際需求，從既往的架構(gòu)設(shè)計經(jīng)驗?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)效勞例 如數(shù)據(jù)庫訪問效勞，處理命令來自用戶界面，處理的進(jìn)度和結(jié)果也通過用戶界面呈現(xiàn)圖5-3-6流程處理模式流程處理模式僅適合于采用批處理方式的軟件系統(tǒng)，不適合于交互式系統(tǒng)2丨客戶/效勞器模式。如圖5-3-7所示

49、，客戶端負(fù)責(zé)用戶輸入和處理結(jié)果的呈現(xiàn)，服 務(wù)器端那么負(fù)責(zé)后臺的業(yè)務(wù)邏輯處理T.圖5-3-7客戶/效勞器模式3模型一視圖一控制器MVC丨模式。如圖5-3-8所示，該模式將整個軟件系統(tǒng)劃分為模型，視圖和控制器 3個局部。模型負(fù)責(zé)維護(hù)并保存具有持久性的業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)業(yè)務(wù)處理功能，并將業(yè)務(wù)數(shù)據(jù)的變化情況及時通知視圖；視圖負(fù)責(zé)呈現(xiàn)模型的業(yè)務(wù)數(shù)據(jù)，響應(yīng)模型 變化通知，更新呈現(xiàn)形式，并向控制器傳遞用戶的界面動作；控制器負(fù)責(zé)將用戶的界面動作映射為模型中業(yè)務(wù)處理功能并實(shí)際調(diào)用之，然后根據(jù)模型返回的業(yè)務(wù)處理結(jié)果選擇新的視圖MVC模式特別適合于分布應(yīng)用軟件，尤其是 Web應(yīng)用系統(tǒng)權(quán)羽tt(t通M11R圖 5-3-8

50、模型-視圖-控制器模式4分層模式。如圖5-3-9所示，分層模式將整個軟件系統(tǒng)分為假設(shè)干層次，最頂層直 接面向用戶提供軟件系統(tǒng)的操作界面， 其余各層為緊鄰其上的層次提供效勞。 層次劃時分的主 要原那么是：較易變化的軟件局部例如用戶界面、與業(yè)務(wù)邏輯緊密相關(guān)的部件置于較高層次, 較穩(wěn)定的軟件局部例如公共的技術(shù)效勞部件那么位于較低層次；每一層次盡量只訪問其緊鄰 下層提供的效勞，防止越級訪問，尤其要防止逆向訪問上層模塊為下層模塊提供效勞；在 許多情況下，可以將目標(biāo)軟件系統(tǒng)的外部接口置入較低層次， 目標(biāo)軟件系統(tǒng)其余局部對外部系 統(tǒng)的訪問或操作均通過這些外部接口所提供的公共效勞來完成。 分層模式可以有效地降

51、低軟件 系統(tǒng)的耦合度，因此其應(yīng)用十分普遍圖5-3-9 分層模式在全面了解軟件架構(gòu)樣式的前提下， 對于具體的應(yīng)用需求而言，影響頂層架構(gòu)選取的主要因素在于分析人員的經(jīng)驗以及他們對每種架構(gòu)樣式與當(dāng)前軟件工程之間匹配程度的判斷。事實(shí)上,大型軟件的頂層架構(gòu)往往需要復(fù)合使用多種架構(gòu)樣式。例如，整個目標(biāo)軟件系統(tǒng)采用分層結(jié)構(gòu)，在系統(tǒng)的不同層次內(nèi)再分別使用適宜的其他種類的架構(gòu)模式。在確立頂層架構(gòu)的過程中，需綜合考慮以下因素：1架構(gòu)中包的數(shù)量。 原那么上，如果每個包中包含的軟件元素例如類的數(shù)量過多， 應(yīng)考慮將其進(jìn)一步細(xì)分；如果過少，那么說明架構(gòu)過早地陷入了細(xì)節(jié)，架構(gòu)劃分返工的可能性較 大，同時也不合理地限制了后續(xù)

52、分析和設(shè)計活動的自由空間。2架構(gòu)中包之間的耦合度。包之間的依賴關(guān)系和連接關(guān)系應(yīng)盡量簡單、稀疏，例如，在分層結(jié)構(gòu)中，通常要求某一層中的軟件元素只與同層及相鄰下一層的元素之間存在依賴關(guān) 系。3軟件元素的穩(wěn)定性。 要盡量抽取不穩(wěn)定的軟件元素之中相對穩(wěn)定的局部將不穩(wěn)定的 軟件元素分類聚集于少數(shù)幾個包中，以提高軟件系統(tǒng)的可維護(hù)性。4軟件元素的必然性。 可以將可選功能和必須實(shí)現(xiàn)的功能分置于架構(gòu)中不同的包或子 包之中。5作為軟件系統(tǒng)運(yùn)行環(huán)境的物理網(wǎng)絡(luò)拓樸。 根據(jù)軟件元素在分布環(huán)境的部署情況區(qū)分 頂層架構(gòu)中的包， 可以使包之間的消息傳遞與物理節(jié)點(diǎn)之間的通信相吻合， 使后續(xù)的分析和設(shè) 計活動受益于頂層架構(gòu)中明確定義的通信關(guān)系。6軟件元素的平安、保密級別。 根據(jù)平安訪問的權(quán)限劃分頂層架構(gòu)中的包或者子包。7開發(fā)團(tuán)隊的技術(shù)專長。 根據(jù)開發(fā)人員在問題領(lǐng)域和軟件技術(shù)領(lǐng)域不同的專長劃分頂 層架構(gòu)中的包， 使每個包都能分配給最適合的開