面向?qū)ο筌浖_發(fā)與UML建模課件

第11章面向?qū)ο?/p>

軟件開發(fā)與UML建模第11章面向?qū)ο?/p>

軟件開發(fā)與UML建模111.1面向?qū)ο筌浖_發(fā)概述 11.2UML簡介 11.3基于UML的面向?qū)ο蠓治雠c設(shè)計概要11.1面向?qū)ο筌浖_發(fā)概述 211.1面向?qū)ο筌浖_發(fā)概述11.1.1傳統(tǒng)軟件開發(fā)方法存在的不足 11.1.2面向?qū)ο蠓椒ǖ闹饕拍?11.1.3面向?qū)ο蠓椒ǖ膬?yōu)勢 11.1.4面向?qū)ο筌浖_發(fā)的過程 11.1.5典型面向?qū)ο筌浖_發(fā)方法 11.1面向?qū)ο筌浖_發(fā)概述11.1.1傳統(tǒng)軟件開發(fā)方311.1.1傳統(tǒng)軟件開發(fā)方法存在的不足互聯(lián)網(wǎng)時代，用戶為響應(yīng)外部競爭環(huán)境的變化對業(yè)務(wù)應(yīng)用系統(tǒng)要求：快速交付低成本維護系統(tǒng)柔性擴充同時，面向廣域業(yè)務(wù)應(yīng)用的大型分布式系統(tǒng)的規(guī)模和復(fù)雜性都顯著提高。以結(jié)構(gòu)化開發(fā)為代表傳統(tǒng)軟件開發(fā)方法確實存在難以逾越的鴻溝。11.1.1傳統(tǒng)軟件開發(fā)方法存在的不足互聯(lián)網(wǎng)時代4傳統(tǒng)開發(fā)方法主要的不足之處（1）軟件重用性差傳統(tǒng)的方法識別業(yè)務(wù)需求是在全局范圍內(nèi)以功能、數(shù)據(jù)或數(shù)據(jù)流為中心來進行分析。分析結(jié)果不能直接地映射問題域，而是經(jīng)過了不同程度的轉(zhuǎn)化和重新組合。極大地限制了軟件的可重用性，導(dǎo)致對不同用戶同樣業(yè)務(wù)對象大量的重復(fù)性工作。傳統(tǒng)開發(fā)方法主要的不足之處（1）軟件重用性差5傳統(tǒng)軟件開發(fā)方法主要不足之處（2）可維護性差傳統(tǒng)方法開發(fā)的系統(tǒng)通常是圍繞著如何實現(xiàn)一定的功能行為來進行的，當(dāng)系統(tǒng)功能易變，需要常作修改時，實施修改很困難。傳統(tǒng)軟件開發(fā)方法主要不足之處（2）可維護性差6傳統(tǒng)軟件開發(fā)方法主要不足之處（3）開發(fā)出的軟件難以滿足用戶需要功能與數(shù)據(jù)分離的軟件分析設(shè)計結(jié)構(gòu)，分析、設(shè)計階段表示體系不一致，和人的自然思維很不一致。對于開發(fā)大型軟件系統(tǒng)，從分析到設(shè)計容易隱蔽一些對問題域的理解偏差，在開發(fā)需求模糊或需求動態(tài)變化的系統(tǒng)時，往往容易造成最終交付的系統(tǒng)不能真正滿足用戶的需要。傳統(tǒng)軟件開發(fā)方法主要不足之處（3）開發(fā)出的軟件難以滿足用戶需711.1.2面向?qū)ο蠓椒ǖ闹饕拍蠲嫦驅(qū)ο筌浖_發(fā)方法不是從功能上，或是從處理問題的算法上來考慮，而是從系統(tǒng)的組成上來進行分解，對問題進行自然分割，以更接近人類思維的方式建立問題域模型，從而使設(shè)計出的軟件盡可能直接地描述現(xiàn)實世界，構(gòu)造出模塊化的、可重用的、可維護性好的軟件，并能控制軟件的復(fù)雜性和降低開發(fā)維護費用。11.1.2面向?qū)ο蠓椒ǖ闹饕拍蠲嫦驅(qū)ο筌浖_發(fā)8面向?qū)ο蠓椒ㄖ饕獞?yīng)用的概念：1.對象（Object）從認知角度，對象是人們要進行研究的任何事物，從具體的事物到抽象的規(guī)則、計劃或事件均可看作對象。

以系統(tǒng)開發(fā)角度，對象是系統(tǒng)中用來描述客觀事物的一個實體，是構(gòu)成系統(tǒng)的一個基本單位，它由一組屬性和對這組屬性進行操作的一組服務(wù)組成。屬性和服務(wù)是構(gòu)成對象的兩個基本要素：屬性是用來描述對象靜態(tài)特征的一個數(shù)據(jù)項。服務(wù)是用來描述對象動態(tài)特征（行為）的一個操作序列面向?qū)ο蠓椒ㄖ饕獞?yīng)用的概念：1.對象（Object）9人員對象姓名年齡性別職務(wù)住址……職務(wù)變遷改換住址……對象類型對象的屬性對象的服務(wù)人員對象姓名職務(wù)變遷對象類型對象的屬性對象的服務(wù)102.類(Class)類又稱對象類（ObjectClass），是一組具有相同屬性和服務(wù)的對象的集合。它為屬于該類的全部對象提供了統(tǒng)一的抽象描述。類好比是一個對象模板，用它可以產(chǎn)生多個對象。類所代表的是一個抽象的概念或事物，在客觀世界中實際存在的是類的實例，即對象。類具有屬性，它是對象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性；類具有服務(wù)，它是對象的行為的抽象，用服務(wù)名和實現(xiàn)該服務(wù)的方法來描述。2.類(Class)類又稱對象類（ObjectC11幾何對象顏色位置移動（delta：矢量）選擇（P:指針型）:布爾型旋轉(zhuǎn)(角度)圖示類的描述人姓名:字符串年齡:整型職務(wù)變遷改換地址文件文件名文件大小最近更新日期打印(人)李四28繪圖員人民路8號(人)張三24程序員無圖示對象的描述對象和類的描述：

對象和類一般采用“對象圖”和“類圖”來描述。類名屬性服務(wù)

對象圖

類圖幾何對象圖示類的描述人文件(人)(人)圖示對象的描述12繼承是以已有的定義為基礎(chǔ)，建立新定義的技術(shù)。是父類和子類之間共享數(shù)據(jù)結(jié)構(gòu)和服務(wù)的機制，這是類之間的一種關(guān)系。已有類定義父類(基類)新類定義子類(派生類)繼承3.繼承(Inheritance)繼承簡化了人們對現(xiàn)實世界的認識和描述，在定義子類時不必重復(fù)定義那些已在父類中定義過的屬性和服務(wù)，只要說明它是某個父類的子類，并定義自己特有的屬性和服務(wù)即可。繼承的形式單重繼承：一個子類只有一個父類。即子類只繼承一個父類的信息結(jié)構(gòu)和行為。多重繼承：一個子類可有多個父類。繼承多個父類的信息結(jié)構(gòu)和行為。輪船客輪貨輪繼承是以已有的定義為基礎(chǔ)，建立新定義的技術(shù)。是父類和子類134.消息（Message）消息就是向?qū)ο蟀l(fā)出的服務(wù)請求。對象之間的聯(lián)系可表示為對象間的消息傳遞，即對象間的通信機制。在對象的服務(wù)操作中當(dāng)一個消息發(fā)送給某個對象時，消息包含接收對象去執(zhí)行某種服務(wù)操作的信息。一個消息應(yīng)該包含以下信息：消息名、接收消息對象的標(biāo)識、服務(wù)標(biāo)識、輸入信息、應(yīng)答信息。面向?qū)ο蠹夹g(shù)的封裝機制使對象相互獨立，各司其職，消息通信則為它們提供了唯一合法的動態(tài)聯(lián)系途徑，使它們的行為能夠相互配合，構(gòu)成一個有機的運動的系統(tǒng)。4.消息（Message）消息就是向?qū)ο蟀l(fā)出的服務(wù)請求14屬性：姓名年齡單位職稱工資屬性：王五25電機系講師1500服務(wù)：調(diào)工資評職稱受聘操作：調(diào)工資（計算公式）評職稱（步驟、條件）服務(wù)：調(diào)工資評職稱受聘王五，調(diào)工資（??????）數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)值勞資處理例程向?qū)ο蟀l(fā)消息執(zhí)行的操作服務(wù)體類：教師對象：王五抽象實例抽象實例抽象方法名（參數(shù)）圖示：對象、類和消息傳遞屬性：姓名屬性：王五服務(wù)：調(diào)工資操作：調(diào)工資服務(wù)：調(diào)工資王五155.封裝（Encapsulation）封裝是把對象的屬性和服務(wù)結(jié)合成一個獨立的系統(tǒng)單位，并盡可能隱藏對象的內(nèi)部細節(jié)。封裝是面向?qū)ο蠓椒ǖ囊粋€重要原則，系統(tǒng)中把對象看成是屬性和對象的結(jié)合體，使對象能夠集中而完整地描述一個具體事物。封裝的信息隱蔽作用反映了事物的相對獨立性，當(dāng)我們從外部觀察對象時，只需要了解對象所呈現(xiàn)的外部行為（即做什么），而不必關(guān)心它的內(nèi)部細節(jié)（即怎么做）。5.封裝（Encapsulation）封裝是把對象166.對象結(jié)構(gòu)和類結(jié)構(gòu)為了使業(yè)務(wù)系統(tǒng)能夠有效地映射問題域，系統(tǒng)開發(fā)者需認識并描述對象之間的存在的關(guān)系。幾種常見重要的關(guān)系：（1）整體與部分之間的結(jié)構(gòu)對象間由分解或組成所構(gòu)成的關(guān)系，例如輪船由船體、船艙、船舵、發(fā)動機、螺旋槳等組成的關(guān)系。即一個對象能由其他對象構(gòu)成，通常稱為“包含”關(guān)系或“組裝”關(guān)系。（2）一般與特殊結(jié)構(gòu)它是由一組具有一般與特殊關(guān)系（即繼承關(guān)系）的類所組成的結(jié)構(gòu)。例如：6.對象結(jié)構(gòu)和類結(jié)構(gòu)為了使業(yè)務(wù)系統(tǒng)能夠有效地映射問17其中，形如左圖由一些單重繼承關(guān)系的類形成層次結(jié)構(gòu)；形如右圖由一些多重繼承關(guān)系的類形成網(wǎng)絡(luò)結(jié)構(gòu)。上層類有對下層類一般特性的“聚合”關(guān)系。人員教師學(xué)生研究生本科生交通工具輪船客運工具火車客輪客運列車其中，形如左圖由一些單重繼承關(guān)系的類形成層次結(jié)構(gòu)；形18（3）對象間的“相關(guān)”關(guān)系——實例連接

實例連接反映對象之間的靜態(tài)聯(lián)系，它是通過對象的屬性來表現(xiàn)對象之間的依賴關(guān)系。存在實例連接的對象類之間的聯(lián)系稱為“關(guān)聯(lián)”。

例如，“人員”與“輪船”是獨立的兩個類，它們之間存在“乘坐或駕駛”聯(lián)系，這種聯(lián)系是通過類中的“出行路線”、“時間”、“地點”等屬性建立起來的。（3）對象間的“相關(guān)”關(guān)系——實例連接

實例連接反映對象197.多態(tài)性（Polymorphism）多態(tài)性是指在父類中定義的屬性或服務(wù)被子類繼承后，可以具有不同的數(shù)據(jù)類型或表現(xiàn)出不同的行為。在體現(xiàn)一般與特殊關(guān)系的一個類層次結(jié)構(gòu)中，不同層次的類可以共享一個操作，但多態(tài)性卻使其有各自不同的實現(xiàn)。當(dāng)一個對象接收到一個請求時，它根據(jù)其所屬的類，動態(tài)地選用在該類中定義的操作。例如：面向?qū)ο罄L圖程序中，在父類“幾何圖形”中定義了一個服務(wù)“繪圖”，但并不確定執(zhí)行時繪制一個什么圖形。子類“圓形”和“多邊形”都繼承了幾何圖形類的繪圖服務(wù)，但其功能卻不相同：一個是畫圓形，一個是畫多邊形。圓形和多邊形接收到請求繪圖消息時各自執(zhí)行不同的繪圖算法。7.多態(tài)性（Polymorphism）多態(tài)性是指在2011.1.3面向?qū)ο蠓椒ǖ膬?yōu)勢（1）增強了可理解性面向?qū)ο蠓椒ㄒ詫ο鬄楹诵模瑥娬{(diào)對現(xiàn)實概念的模擬而不強調(diào)算法。它的基本原則是按照人們習(xí)慣的思維方式建立問題域的模型，開發(fā)出盡可能直觀、自然地表現(xiàn)求解方法的軟件系統(tǒng)。（2）增強了可重用性面向?qū)ο蠓椒ㄒ腩悺⒗^承、多態(tài)、封裝、消息連接等概念，這些概念為復(fù)用提供了可能性。（3）增強了系統(tǒng)的穩(wěn)定性面向?qū)ο蠓椒ㄒ詫ο竽M實體，因為實體相對穩(wěn)定，需求變化不會引起結(jié)構(gòu)的整體變化，故軟件系統(tǒng)也相應(yīng)穩(wěn)定。11.1.3面向?qū)ο蠓椒ǖ膬?yōu)勢（1）增強了可理解性（2）21（4）增強了系統(tǒng)的可維護性面向?qū)ο蠓椒◤囊韵聨追矫娓纳屏丝删S護性：①穩(wěn)定性好：軟件功能需求的變化不牽動全局，只需局部修改；②類的獨立性強：只要修改不涉及類的對外接口，則內(nèi)部修改完全不影響外部調(diào)用；③繼承和多態(tài)性，使其很容易被修改和擴充；④容易理解；⑤容易測試、調(diào)試（5）增加了軟件的總體效益可復(fù)用性、可維護和可擴展性帶來的不僅是技術(shù)上的效益。更重要的還有業(yè)務(wù)效益。從用戶的觀點來看，真正的利益在于構(gòu)建的系統(tǒng)更好、更快、更經(jīng)濟。（4）增強了系統(tǒng)的可維護性（5）增加了軟件的總體效益2211.1.4面向?qū)ο蟮能浖_發(fā)過程面向?qū)ο蟮能浖_發(fā)過程可以大體劃分為面向?qū)ο蠓治觯∣OA，ObjectOrientedAnalysis）、面向?qū)ο笤O(shè)計（OOD，ObjectOrientedDesign）、面向?qū)ο缶幊蹋∣OP，ObjectOrientedProgramming）和面向?qū)ο鬁y試（OOT，ObjectOrientedTesting）等主要環(huán)節(jié)。11.1.4面向?qū)ο蟮能浖_發(fā)過程面向?qū)ο蟮能浖?3面向?qū)ο蠓治?面向?qū)ο蠓治鰪膯栴}陳述入手，分析和構(gòu)造所關(guān)心的現(xiàn)實世界問題的模型，并用相應(yīng)的符號系統(tǒng)表示，面向?qū)ο蠓治龅牟襟E為：確定問題域。包括定義論域，選擇論域，根據(jù)需要細化和增加論域區(qū)分類和對象。包括定義對象，定義類，命名區(qū)分整體對象及組成部分，確定類的關(guān)系及結(jié)構(gòu)。包括一般—具體結(jié)構(gòu)、整體—部分結(jié)構(gòu)、多重結(jié)構(gòu)定義屬性。包括確定屬性，安排屬性。確定實例聯(lián)結(jié)定義服務(wù)。包括確定對象狀態(tài)，確定所需服務(wù)，確定消息聯(lián)結(jié)確定附加的系統(tǒng)約束。面向?qū)ο蠓治?面向?qū)ο蠓治鰪膯栴}陳述入手，分析和構(gòu)造所關(guān)心24面向?qū)ο笤O(shè)計

面向?qū)ο笤O(shè)計具體設(shè)計步驟如下：應(yīng)用面向?qū)ο蠓治鰧τ闷渌椒ǖ玫降南到y(tǒng)分析的結(jié)果進行改進和完善設(shè)計交互過程和用戶接口。包括描述用戶及任務(wù)并根據(jù)需要分成子系統(tǒng)、把交互作用設(shè)計成類、設(shè)計命令層次、設(shè)計交互作用過程及接口并用相應(yīng)符號系統(tǒng)表示設(shè)計任務(wù)管理。包括根據(jù)前一步驟確定是否需要多重任務(wù)、確定并發(fā)性、確定以何種方式驅(qū)動任務(wù)、設(shè)計子系統(tǒng)及任務(wù)之間的協(xié)調(diào)與通信方式、確定優(yōu)先級設(shè)計全局資源協(xié)調(diào)。包括確定邊界條件、確定任務(wù)或子系統(tǒng)的軟、硬件分配設(shè)計類等。包括各個類的存儲和數(shù)據(jù)格式、設(shè)計實現(xiàn)類所需的算法、將屬性和服務(wù)加入到各個類的存儲對象中、設(shè)計對象庫或數(shù)據(jù)庫面向?qū)ο笤O(shè)計 面向?qū)ο笤O(shè)計具體設(shè)計步驟如下：25OOP環(huán)節(jié)的工作就是用確定合適的面向?qū)ο蟮木幊陶Z言，把OOD模型中的每個成分書寫出來。并將編好的各個類代碼模塊根據(jù)類的相互關(guān)系集成為完整的軟件系統(tǒng)。使用OO語言來實現(xiàn)OO設(shè)計相對來說比較容易，因為語言的構(gòu)造與設(shè)計的構(gòu)造是相似的，OO語言支持對象、運行多態(tài)性和繼承。程序開發(fā)人員著重要做的工作是：用具體的數(shù)據(jù)結(jié)構(gòu)來定義對象的屬性，用具體的語句來實現(xiàn)服務(wù)流程圖所表示的算法。面向?qū)ο缶幊蘋OP環(huán)節(jié)的工作就是用確定合適的面向?qū)ο蟮木幊陶Z言，把OOD26對于運用OO技術(shù)開發(fā)的軟件，在測試過程中繼續(xù)運用OO技術(shù)進行以對象概念為中心的軟件測試。它以類作為基本測試單位，集中檢查在類定義之內(nèi)的屬性、服務(wù)和有限的對外接口，大大減少了錯誤的影響范圍。測試人員利用開發(fā)人員提供的測試樣例和用戶提供的測試樣例，分別檢驗編碼完成的各個模塊和整個軟件系統(tǒng)，并且測試可以與開發(fā)同步。

面向?qū)ο鬁y試對于運用OO技術(shù)開發(fā)的軟件，在測試過程中繼續(xù)運用OO技術(shù)進行27Booch的方法Coad/Yourdon的面向?qū)ο蠓治雠c設(shè)計（OOA/OOD）Rumbaugh的對象建模技術(shù)（OMT）Jacobson的面向?qū)ο筌浖こ蹋∣OSE）11.1.5典型面向?qū)ο筌浖_發(fā)方法介紹Booch的方法11.1.5典型面向?qū)ο筌浖_發(fā)方法介紹28Booch方法Booch是面向?qū)ο蠓椒ǖ淖钤绯珜?dǎo)者之一。Booch認為開發(fā)過程為螺旋上升模式，每一次重復(fù)的步驟如下：從應(yīng)用的問題域中發(fā)現(xiàn)類和對象；分析類和對象的功能、行為，確定其屬性和操作；找出類、對象之間的關(guān)系；說明每個類和對象的界面和實現(xiàn)。Booch方法Booch是面向?qū)ο蠓椒ǖ淖钤绯珜?dǎo)者之一。29Booch采用以下方法構(gòu)筑系統(tǒng)模型：類圖——在Booch方法中作為邏輯的、靜態(tài)模型的描述方法；描述系統(tǒng)的構(gòu)成。 類的圖形表示： 類之間相互關(guān)系的表示：名稱屬性操作關(guān)聯(lián)：繼承：包含：使用：Booch采用以下方法構(gòu)筑系統(tǒng)模型：名稱關(guān)聯(lián)：繼承：包含：使30環(huán)境控制器管理計劃作物實施（）可否收獲（）暖氣冷氣燈光溫度執(zhí)行機構(gòu)啟動（）關(guān)閉（）定義氣候11111n例：溫室管理系統(tǒng)類圖環(huán)境控制器管理計劃暖氣冷氣燈光溫度執(zhí)行機構(gòu)定義氣候1111131對象圖——在Booch方法中作為邏輯的、靜態(tài)模型的描述方法；表示系統(tǒng)行為的基本結(jié)構(gòu)。 例：計劃分析管理計劃谷物計劃度量1：收獲時間2：狀態(tài)3：成熟時間4：產(chǎn)量5：作物產(chǎn)量6：成本對象圖——在Booch方法中作為邏輯的、靜態(tài)模型的描述方法；32狀態(tài)遷移圖——作為邏輯的、動態(tài)模型的描述方法；表示一個類的動態(tài)行為。交互作用圖——作為邏輯的、動態(tài)模型的描述方法；表示幾個對象在共同完成一個系統(tǒng)功能時表現(xiàn)出的交互關(guān)系（亦即：一個類的動態(tài)行為）。 交互作用圖與OMT的事件追蹤圖十分相似，區(qū)別是：交互圖主要表示操作而不是事件；是對象圖的另一種表示形式。狀態(tài)遷移圖——作為邏輯的、動態(tài)模型的描述方法；表示一個類的動33計劃分析計劃度量管理計劃C：作物C:谷物收獲時間()狀態(tài)()成熟時間()產(chǎn)量()產(chǎn)量()成本()例：溫室管理系統(tǒng)的交互作用圖計劃分析計劃度量管理計劃C：作物C:谷物收獲時間()狀態(tài)34模塊圖——作為物理模型的描述方法；表示如何將類和對象分配到不同的軟件模塊中。 每個符號表示一個模塊，每個模塊是一個文件 連接文件的箭頭表示兩個文件的編譯依賴關(guān)系。氣候定義模塊圖——作為物理模型的描述方法；表示如何將類和對象分配到不35氣候計劃作物定義冷氣暖氣氣候定義例：溫室管理系統(tǒng)的模塊圖氣候計劃作物定義冷氣暖氣氣候定義例：36進程圖——作為物理模型的描述方法；表示如何將可同時執(zhí)行的進程分配到不同的處理機上。 對于單處理級系統(tǒng)，表示處于活動狀態(tài)的對象，及進程調(diào)度。溫室工作站溫室A溫室B溫室C溫室管理系統(tǒng)的進程圖進程圖——作為物理模型的描述方法；表示如何將可同時執(zhí)行的進程37Booch方法表示系統(tǒng)模型：系統(tǒng)模型靜態(tài)模型動態(tài)模型邏輯模型物理模型類圖對象圖狀態(tài)圖交互作用圖模塊圖進程圖Booch方法表示系統(tǒng)模型：系統(tǒng)模型靜態(tài)模型動態(tài)模型邏輯模型38Coad與Yourdon的方法是在信息模型化技術(shù)、面向?qū)ο蟪绦蛟O(shè)計語言及知識庫系統(tǒng)的基礎(chǔ)上發(fā)展起來的，這個方法分為OOA和OOD兩部分。

Coad/Yourdon的方法Coad與Yourdon的方法是在信息模型化技Coa39一、面向?qū)ο蟮姆治觯∣OA）Coad與Yourdon和其它描寫面向?qū)ο蠓椒ǖ淖髡咭粯樱J為OOA主要考慮與一個特定應(yīng)用有關(guān)的對象及對象與對象之間在結(jié)構(gòu)與相互作用上的關(guān)系。 1.OOA的任務(wù) 1）形式地說明所面對的應(yīng)用問題，最終成為軟件系統(tǒng)基本構(gòu)成的對象，還有系統(tǒng)所必須遵從的，由應(yīng)用環(huán)境所決定的規(guī)則和約束。 2）明確地規(guī)定構(gòu)成系統(tǒng)的對象如何協(xié)同合作，完成指定的功能。

一、面向?qū)ο蟮姆治觯∣OA）40在OOA中，要建立分析模型來描述系統(tǒng)的功能第一個層次主要是識別類和對象，這是整個分析模型的基礎(chǔ)。第二層和第三層是屬性層和服務(wù)層，用以說明前面已識別的類和對象。第四層是結(jié)構(gòu)層，OOA允許兩種類型的基本結(jié)構(gòu)：一是整體與部分結(jié)構(gòu)，也叫組裝結(jié)構(gòu)，組裝結(jié)構(gòu)表示聚合，即由屬于不同類的成員聚合而成新的類；二是泛化與特化結(jié)構(gòu)，也叫分類結(jié)構(gòu)。其中，特化類是泛化類的子類，泛化類是特化類的父類。分類結(jié)構(gòu)具有繼承性，泛化類和對象的屬性與服務(wù)一旦被識別，即可在特化類和對象中使用。第五層是主題層，是一些類和對象的特定組合表示，用來幫助和指導(dǎo)模型的讀者。

在OOA中，要建立分析模型來描述系統(tǒng)的功能41面向?qū)ο筌浖_發(fā)與UML建模課件422.OOA的步驟

1)找到類和對象首先確定問題空間中包含哪些對象，有哪些操作，這些對象之間有什么關(guān)系，它們與操作又有什么關(guān)系。對象應(yīng)該是實際問題域中有意義的個體或概念實體，具有目標(biāo)軟件系統(tǒng)所關(guān)心的屬性，還應(yīng)該以某種方式與系統(tǒng)發(fā)生關(guān)聯(lián)，即對象必須與系統(tǒng)中其他有意義的對象進行消息傳遞，并提供外部服務(wù)。有關(guān)對象命名的重要原則：

a.使用單個名詞或名詞短語； b.對象名稱必須簡潔、精確、易于理解； c.盡量使用用戶熟悉的標(biāo)準(zhǔn)詞匯。2.OOA的步驟432)確定結(jié)構(gòu)第一種結(jié)構(gòu)是分類結(jié)構(gòu)，代表了確定的類中的繼承等級。另一種結(jié)構(gòu)是組裝結(jié)構(gòu)，即由屬于不同類的成員聚合而成新的類。

3)定義主題確定主題通過將類和對象劃分成更大的單元來完成。主題是類和對象的組合。每個主題的規(guī)模按有助于讀者通過模型理解系統(tǒng)來選擇。

2)確定結(jié)構(gòu)444)定義屬性對每個對象，確定劃給該對象所需的屬性。關(guān)鍵是識別與當(dāng)前所處理的問題相關(guān)的屬性。被確定的屬性放到繼承等級的正確層次。注意應(yīng)避免冗余的或不正確的屬性

5)定義服務(wù)對象怎樣進行消息通信是用消息的聯(lián)系來確定的。這些都用來指定某一個操作。綜上所述，OOA大體上可以按照這個順序進行。但是，分析不可能嚴格地按照預(yù)定順序進行，大型、復(fù)雜系統(tǒng)的模型需要反復(fù)構(gòu)造多遍才能建成。4)定義屬性45二、面向?qū)ο蟮脑O(shè)計(OOD)OOA到OOD實際上是一個逐漸擴充模型的過程。面向?qū)ο蠓治鲋饕M問題空間和系統(tǒng)任務(wù)；而面向?qū)ο笤O(shè)計則是對其進行擴充，主要是增加各種組成部分。OOA識別和定義的類/對象，是一些直接反映問題空間和系統(tǒng)任務(wù)的；而OOD識別和定義的類/對象則是附加的，反映需求的一種實現(xiàn)。Coad與Yourdon在設(shè)計階段中繼續(xù)采用分析階段中提到的五個層次，他們認為這有助于從分析到設(shè)計的過渡。不同的是，在設(shè)計階段中，這五個層次是用于建立系統(tǒng)的四個組成成分上。這四個組成成分是：問題論域，用戶界面，任務(wù)管理和數(shù)據(jù)管理。

二、面向?qū)ο蟮脑O(shè)計(OOD)46問題論域部分包括與所面對的應(yīng)用問題直接有關(guān)的所有類和對象。

在其它的三個部分中，識別和定義新的類和對象。

問題論域部分包括與所面對的應(yīng)用問題直接有關(guān)的所有類和對象。471.問題域部分（PDC）的設(shè)計

OOA階段得到的有關(guān)應(yīng)用的概念模型描述了所要解決的問題。在OOD階段，主要是對OOA產(chǎn)生模型中的某些類與對象、結(jié)構(gòu)、屬性、操作進行組合與分解，或者增加必要的類、屬性和聯(lián)系。

1.問題域部分（PDC）的設(shè)計481）復(fù)用設(shè)計

根據(jù)問題解決的需要，把從現(xiàn)有的類庫或其它來源得到的現(xiàn)存類增加到問題解決方案中去。

1）復(fù)用設(shè)計49面向?qū)ο筌浖_發(fā)與UML建模課件502）把問題論域的專用類關(guān)聯(lián)起來3）為建立公共操作集合建立一般類4）調(diào)整繼承級別

2）把問題論域的專用類關(guān)聯(lián)起來512.用戶界面部分（HIC）的設(shè)計

通常在OOA階段給出了所需的屬性和操作，在設(shè)計階段必須根據(jù)需求把交互的細節(jié)加入到用戶界面的設(shè)計中，包括有效的人機交互所必需的實際顯示和輸入。2.用戶界面部分（HIC）的設(shè)計521）用戶分類通?？蓪⑵浞譃橥庑行汀⒊鯇W(xué)型、熟練型和專家型四類2）描述人及其任務(wù)的場景什么人、特點、期望軟件用途、主要要求與喜好以及任務(wù)場景等。3）設(shè)計命令層盡量遵循用戶界面的一般原則和規(guī)范，根據(jù)用戶分析結(jié)果確定初步的命令系統(tǒng)，然后再優(yōu)化。4）設(shè)計詳細的交互5）設(shè)計HIC（人機交互）類1）用戶分類533.任務(wù)管理部分(TMC)的設(shè)計

任務(wù)是進程的別稱，是執(zhí)行一系列活動的一段程序，或者說，任務(wù)是由目標(biāo)軟件系統(tǒng)中一段代碼決定的處理行為。任務(wù)管理主要包括任務(wù)的選擇和調(diào)整。

3.任務(wù)管理部分(TMC)的設(shè)計541）識別事件驅(qū)動任務(wù)一些負責(zé)與硬件設(shè)備通信的任務(wù)是事件驅(qū)動的，也就是說這些任務(wù)可由事件來激發(fā)，而事件常常是當(dāng)數(shù)據(jù)到來時發(fā)出的一個信號。2）識別時鐘驅(qū)動任務(wù)以固定的時間間隔激發(fā)這種事件，以執(zhí)行某些處理。3）識別優(yōu)先任務(wù)和關(guān)鍵任務(wù)

根據(jù)處理的優(yōu)先級別來安排各種任務(wù)。在系統(tǒng)中，有些操作具有高優(yōu)先級，因此必須在很強的時間限制內(nèi)完成；有些操作具有較低的優(yōu)先級，可進行時間要求較低的處理。關(guān)鍵任務(wù)是對系統(tǒng)的成敗起關(guān)鍵作用的處理，這些處理要求有較高的可靠性。

1）識別事件驅(qū)動任務(wù)554）識別協(xié)調(diào)者

當(dāng)有三個或更多的任務(wù)時，應(yīng)當(dāng)增加一個附加任務(wù)，專門負責(zé)任務(wù)之間的調(diào)度、協(xié)同和仲裁。5）評審各個任務(wù)6）定義各個任務(wù)定義任務(wù)的工作主要包括它是什么任務(wù)、如何協(xié)調(diào)工作及如何通信。任務(wù)的定義如下：name(任務(wù)名）description(描述)priority(優(yōu)先級)servicesincluded(包含的操作)communicationvia(經(jīng)由誰通信)

4）識別協(xié)調(diào)者564.數(shù)據(jù)管理部分(DMC)的設(shè)計

數(shù)據(jù)管理部分提供了在數(shù)據(jù)管理系統(tǒng)中存儲和檢索對象的基本結(jié)構(gòu)

設(shè)計數(shù)據(jù)管理部分的目的是，將目標(biāo)軟件系統(tǒng)中依賴開發(fā)平臺的數(shù)據(jù)存取部分與其他功能分離，數(shù)據(jù)存取通過一般的數(shù)據(jù)管理系統(tǒng)實現(xiàn)，但實現(xiàn)細節(jié)集中在DMC中。這樣既有利于軟件的擴充、移植和維護，又簡化了軟件設(shè)計、編碼和測試的過程。

4.數(shù)據(jù)管理部分(DMC)的設(shè)計571）數(shù)據(jù)管理方法數(shù)據(jù)管理方法主要有三種文件管理關(guān)系數(shù)據(jù)庫管理面向?qū)ο蟮臄?shù)據(jù)庫管理2）數(shù)據(jù)管理部分的設(shè)計數(shù)據(jù)存儲管理部分的設(shè)計包括數(shù)據(jù)存放方法的設(shè)計和相應(yīng)操作的設(shè)計

1）數(shù)據(jù)管理方法58OMT是美國通用電氣公司在總結(jié)其內(nèi)部多年來采用OO技術(shù)開發(fā)實踐的基礎(chǔ)上提出的一套系統(tǒng)開發(fā)方法學(xué)。OMT最早是由Loomis，Shan和Rumbaugh在1987年提出的，曾擴展應(yīng)用于關(guān)系DB設(shè)計。J.Rumbaugh在1991年正式把OMT應(yīng)用于OO的分析和設(shè)計。它以面向?qū)ο笏枷霝榛A(chǔ)，通過構(gòu)造一組相關(guān)模型（對象模型、動態(tài)模型和功能模型）來獲得關(guān)于問題的全面認識（即問題領(lǐng)域模型），是在實體關(guān)系模型上擴展了類、繼承和行為而得到的。

OMT(objectmodelingtechnique)方法OMT是美國通用電氣公司在總結(jié)其內(nèi)部多年來采用OO技術(shù)開發(fā)實59對象模型(objectmodel)代表了系統(tǒng)的靜態(tài)的、結(jié)構(gòu)方面的特性。動態(tài)模型(dynamicmodel)代表了系統(tǒng)對象之間的時間的、行為的、控制方面的特性。功能模型(functionalmodel)主要描述值與值之間的函數(shù)關(guān)系。這三個模型從不同角度對系統(tǒng)進行描述，分別抓住了系統(tǒng)的一個重要方面，組合起來構(gòu)成了對系統(tǒng)的完整描述。OMT認為一個典型的軟件過程是三個方面的合作：它的數(shù)據(jù)結(jié)構(gòu)(對象模型)、它按時間順序的操作(動態(tài)模型)和它所改變的值(功能模型)。

對象模型(objectmodel)代表了系統(tǒng)的靜態(tài)的、結(jié)構(gòu)60在分析階段，應(yīng)用領(lǐng)域的一個模型被建立，不考慮最后的實現(xiàn)。在設(shè)計階段，解決領(lǐng)域的結(jié)構(gòu)加入模型中，明確系統(tǒng)中各個類的定義和相互關(guān)系以及各個類中的操作，并考慮到重用效率，重新設(shè)計一些類和關(guān)系。在實現(xiàn)階段，應(yīng)用領(lǐng)域和解決領(lǐng)域的結(jié)構(gòu)都被編碼。

在分析階段，應(yīng)用領(lǐng)域的一個模型被建立，不考慮最后的實現(xiàn)。61模型有兩層含義：從系統(tǒng)的觀點看對象模型動態(tài)模型功能模型從開發(fā)階段看分析模型設(shè)計模型實現(xiàn)模型模型有兩層含義：62三種模型介紹

1.對象模型對象模型描述了系統(tǒng)中對象的結(jié)構(gòu)，即它們的標(biāo)識、它們與其它對象之間的關(guān)系、它們的屬性以及它們的操作。對象模型為動態(tài)模型和功能模型提供了重要的框架，因為只有當(dāng)事物變化時，動態(tài)模型和功能模型才有存在的意義。對象模型用包含對象及對象的關(guān)系圖表示。

三種模型介紹63面向?qū)ο筌浖_發(fā)與UML建模課件64類之間的聯(lián)系稱為關(guān)系。類之間的關(guān)系在OMT符號中用一條線表示。對象圖在關(guān)系線的端點用特定的符號表示多元性。

類之間的聯(lián)系稱為關(guān)系。類之間的關(guān)系在OMT符號中用一條線表示65對象模型中類之間的三種基本關(guān)系以O(shè)MT符號來表示

1）相關(guān)關(guān)系

對象模型中類之間的三種基本關(guān)系以O(shè)MT符號來表示662）包容關(guān)系

2）包容關(guān)系673）繼承關(guān)系

3）繼承關(guān)系68OMT建立一個對象模型的步驟大致如下：確定對象類定義一個DD，包括類、屬性和關(guān)系的描述增加類之間的關(guān)系增加對象和聯(lián)系的屬性用繼承組織和簡化對象類用場景測試訪問路徑如有需要重復(fù)以上各步基于相近的關(guān)系和相關(guān)的功能將成組的對象形成模塊

OMT建立一個對象模型的步驟大致如下：69 2.動態(tài)模型動態(tài)模型描述系統(tǒng)中與時間有關(guān)的方面以及操作執(zhí)行的順序，包括引起變化的事件、事件的序列、定義事件序列上下文的狀態(tài)、以及事件和狀態(tài)的主次。動態(tài)建模中的主要概念是事件和狀態(tài)。一個對象的狀態(tài)是指對象所擁有的屬性值和連接關(guān)系。從一個對象到另一個對象的單個消息叫作一個事件。 在系統(tǒng)的一個特定的執(zhí)行中發(fā)生的一系列事件叫一個場景。

2.動態(tài)模型70面向?qū)ο筌浖_發(fā)與UML建模課件71動態(tài)模型由多個狀態(tài)圖組成，每個用來描述一個類的重要動態(tài)行為，并表明整個系統(tǒng)的活動方式，不同類的狀態(tài)圖通過共享的事件組成一個動態(tài)模型。狀態(tài)圖的結(jié)點是狀態(tài)，標(biāo)有事件的線是轉(zhuǎn)移。轉(zhuǎn)移的箭頭指向接收事件后的目標(biāo)狀態(tài)。

動態(tài)模型由多個狀態(tài)圖組成，每個用來描述一個類的重要動態(tài)行為，72面向?qū)ο筌浖_發(fā)與UML建模課件73面向?qū)ο筌浖_發(fā)與UML建模課件74建立一個動態(tài)模型的步驟準(zhǔn)備典型的交互序列的場景確定對象之間的事件和為每個場景準(zhǔn)備一個事件跟蹤圖為每個系統(tǒng)準(zhǔn)備一個事件流圖為每個有重要的動態(tài)行為的類開發(fā)一個狀態(tài)圖檢驗狀態(tài)圖之間的共享的事件的一致性和完整性。

建立一個動態(tài)模型的步驟75 3.功能模型對象模型指出事件要發(fā)生在什么方面，動態(tài)模型指出什么時候發(fā)生，功能模型則指出要發(fā)生什么。功能模型表示怎樣從輸入值得到輸出值。包括函數(shù)、映射、約束和功能性依賴。功能模型由多個DFD組成，它們表示從外部輸入，通過操作和內(nèi)部數(shù)據(jù)存儲，到外部輸出這樣一個流。DFD不表示控制或?qū)ο蠼Y(jié)構(gòu)信息，這些分別屬于動態(tài)模型和對象模型。功能是由動態(tài)模型的動作引起，并在對象模型里表示對對象的操作。一個DFD包括轉(zhuǎn)換數(shù)據(jù)的過程，移動數(shù)據(jù)的DF，生產(chǎn)和消費數(shù)據(jù)的角色對象，以及被動地存儲數(shù)據(jù)的數(shù)據(jù)存儲對象。 3.功能模型76建立一個功能模型的步驟確定輸入和輸出值需要時用DFD表示功能的依賴性描述每個功能干什么確定限制，指定優(yōu)化準(zhǔn)則

建立一個功能模型的步驟77 4.三個模型之間的關(guān)系對象模型、動態(tài)模型和功能模型都包含了同樣的概念、數(shù)據(jù)、序列和操作，但它們描述了系統(tǒng)的不同方面，同時也互相引用。對象模型描述了動態(tài)模型、功能模型所操作的DS。對象模型中的操作對應(yīng)于動態(tài)模型中的事件和功能模型中的函數(shù)。動態(tài)模型描述了對象的控制結(jié)構(gòu)，告訴我們哪些決策是依賴于對象值，哪些引起對象的變化，并激活了功能。功能模型描述了由對象模型中操作和動態(tài)模型中動作所激活的功能，而功能作用在對象模型說明的數(shù)據(jù)上，功能模型還表示對對象值的約束。

4.三個模型之間的關(guān)系78OMT的開發(fā)過程

1、分析階段分析階段關(guān)心和理解要處理的應(yīng)用和領(lǐng)域并建模。分析階段首先輸入的是問題陳述，它主要描述了需要處理的問題，并提供了將要產(chǎn)生的系統(tǒng)概況。分析后的輸出是一個描述了系統(tǒng)三個重要方面的形式化模型：對象和對象之間的關(guān)系、動態(tài)的控制流，以及函數(shù)性轉(zhuǎn)換。系統(tǒng)分析文檔包括問題陳述和三類模型。

OMT的開發(fā)過程79面向?qū)ο筌浖_發(fā)與UML建模課件802、系統(tǒng)設(shè)計階段系統(tǒng)設(shè)計階段決定系統(tǒng)的整個體系結(jié)構(gòu)。系統(tǒng)設(shè)計是一個用于解決問題和形成解答的高層次的策略。它是最先的設(shè)計階段，在這里將選擇解決問題的基本方法。在系統(tǒng)設(shè)計階段，總體的結(jié)構(gòu)和風(fēng)格被決定，這將為以后的設(shè)計階段中更詳細的決定提供依據(jù)。通過作出用于整個系統(tǒng)的高層決定，系統(tǒng)設(shè)計者以對象模型為依據(jù)，將系統(tǒng)劃分成子系統(tǒng)，以便以后的工作可以由幾個設(shè)計者獨立地在不同的子系統(tǒng)上完成。系統(tǒng)設(shè)計文檔包括系統(tǒng)的基本的體系結(jié)構(gòu)以及高層的策略決定。2、系統(tǒng)設(shè)計階段813.對象設(shè)計階段在對象設(shè)計階段中，從著重于應(yīng)用概念逐步轉(zhuǎn)移到著重于計算機概念上。對象設(shè)計階段決定實現(xiàn)中所用的類和關(guān)系的全部定義，包括接口和用于實現(xiàn)操作的算法。在對象設(shè)計時，設(shè)計者執(zhí)行系統(tǒng)設(shè)計期間所選的策略和給出細節(jié)。對象設(shè)計文檔包括詳細的對象模型、詳細的動態(tài)模型和詳細的功能模型。

3.對象設(shè)計階段82 4、實現(xiàn)階段實現(xiàn)是在良好的面向?qū)ο缶幊田L(fēng)格的編碼原則指導(dǎo)下進行的。 4、實現(xiàn)階段83面向?qū)ο蟮能浖こ蹋∣OSE）OOSE將面向?qū)ο蟮乃枷霊?yīng)用于軟件工程中，建立五個模型：1、需求模型（RM）2、分析模型（AM）3、設(shè)計模型（DM）4、實現(xiàn)模型（IM）5、測試模型（TM）OOSE的開發(fā)活動主要分為三類：分析、構(gòu)造和測試。分析構(gòu)造測試面向?qū)ο蟮能浖こ蹋∣OSE）OOSE將面向?qū)ο蟮乃枷霊?yīng)84用例(Usecase)是OOSE中的重要概念，在開發(fā)各種模型時，用例貫穿了OOSE活動的核心，描述了系統(tǒng)的需求及功能。貿(mào)易經(jīng)理風(fēng)險分析設(shè)置邊界進行交易交易估價更新帳目《使用》《使用》《擴展》營銷人員超越邊界評價記帳系統(tǒng)銷售人員圖示用例圖分析模型usecase模型通過分析來構(gòu)造。

設(shè)計模型usecase模型通過設(shè)計來具體化。

實現(xiàn)模型該模型依據(jù)具體化的設(shè)計來實現(xiàn)usecase模型。

測試模型用來測試具體化的usecase模型。用例(Usecase)是OOSE中的重要概念，在8511.2UML簡介 UML概要UML由OMG與1997年11月批準(zhǔn)為標(biāo)準(zhǔn)建模語言。UML建立在當(dāng)今國際上最有代表性的三種面向?qū)ο蠓椒ǎ˙ooch方法，OMT方法，OOSE方法）的基礎(chǔ)之上。UML是一種建模語言而不是一種方法，UML本身是獨立于過程的。11.2UML簡介 UML概要86UML的設(shè)計目標(biāo)：運用面向?qū)ο蟾拍顏順?gòu)造系統(tǒng)模型建立起從概念模型直至可執(zhí)行體之間明顯的對應(yīng)關(guān)系著眼于那些有重大影響的問題創(chuàng)建一種對人和機器都適用的建模語言UML的設(shè)計目標(biāo)：87UML為人們提供了從不同的角度去觀察和展示系統(tǒng)的各種特征的一種標(biāo)準(zhǔn)表達方式。在UML中，從任何一個角度對系統(tǒng)所作的抽象都可能需要用幾種模型圖來描述，而這些來自不同角度的模型圖最終組成了系統(tǒng)的完整模型。UML為人們提供了從不同的角度去觀察和88一般而言，我們可以從以下幾種常用的視角來描述一個系統(tǒng)：系統(tǒng)的使用實例：從系統(tǒng)外部的操作者的角度描述系統(tǒng)的功能。系統(tǒng)的邏輯結(jié)構(gòu)：描述系統(tǒng)內(nèi)部的靜態(tài)結(jié)構(gòu)和動態(tài)行為，即從內(nèi)部描述如何設(shè)計實現(xiàn)系統(tǒng)功能。系統(tǒng)的構(gòu)成：描述系統(tǒng)由哪些程序構(gòu)件所組成。系統(tǒng)的并發(fā)性：描述系統(tǒng)的并發(fā)性，強調(diào)并發(fā)系統(tǒng)中存在的各種通信和同步問題。系統(tǒng)的配置：描述系統(tǒng)的軟件和各種硬件設(shè)備之間的配置關(guān)系。一般而言，我們可以從以下幾種常用的視89UML模型圖（5類，10種）：用例圖靜態(tài)圖（類圖，對象圖，包圖）行為圖（狀態(tài)圖，活動圖）交互圖（順序圖，協(xié)作圖）實現(xiàn)圖（部件圖，配置圖）UML模型圖（5類，10種）：90UML語義元-元模型：元模型的基礎(chǔ)體系結(jié)構(gòu)，定義一種說明元模型的語言元模型：元-元模型的一個實例，定義一種說明模型的語言模型：元模型的一個實例，定義一種語言來描述信息領(lǐng)域用戶對象：模型的一個實例，定義一個特定的領(lǐng)域UML語義91UML主要文件：UML概要（UMLSummary）UML語義（UMLSemantics）UML表示法指南（UMLNotationGuide）對象約束語言規(guī)約（ObjectContraintlanguageSpecification）：該文件定義并介紹了一種對象約束語言（OCL），其用途是用來說明在圖形化的系統(tǒng)模型中不能充分表達的建模信息。它是一種形式化語言。UML主要文件：92UML用例圖從本質(zhì)上將，一個用例是用戶與計算機之間為達到某個目的的一次典型交互作用：用例描述了用戶提出的一些可見的需求；用例可大可??；用例對應(yīng)一個具體的用戶目標(biāo)UML用例圖從本質(zhì)上將，一個用例是用戶93用例圖描述系統(tǒng)外部的執(zhí)行者與系統(tǒng)的用例之間的某種聯(lián)系。所謂用例是指對系統(tǒng)提供的功能（或稱系統(tǒng)的用途）的一種描述；執(zhí)行者是那些可能使用這些用例的人或外部系統(tǒng)；用例和執(zhí)行者之間的聯(lián)系描述了“誰使用哪個用例”。UML用例圖用例圖描述系統(tǒng)外部的執(zhí)行者與系統(tǒng)的用例94用例圖著重于從系統(tǒng)外部執(zhí)行者的角度來描述系統(tǒng)需要提供哪些功能，并且指明了這些功能的執(zhí)行者是誰；用例圖在UML方法中占有十分重要的地位，人們甚至稱UML是一種用例圖驅(qū)動的開發(fā)方法。UML用例圖用例圖著重于從系統(tǒng)外部執(zhí)行者的角度來描述系統(tǒng)需要提供哪些功能95用例圖中的圖符：

用例執(zhí)行者系統(tǒng)：用于界定系統(tǒng)功能范圍，描述該系統(tǒng)功能的用例都置于其中，而描述外部實體的執(zhí)行者都置于其外。關(guān)聯(lián)：連接執(zhí)行者和用例，表示執(zhí)行者所代表的系統(tǒng)外部實體與該用例所描述的系統(tǒng)需求有關(guān)。UML用例圖用例圖中的圖符：UML用例圖96用例圖中的圖符：使用：由用例A連向用例B，表示用例A中使用了用例B中的行為或功能。擴展：由用例A連向用例B，表示用例B描述了一項基本需求，而用例A則描述了該基本需求的特殊情況。注釋體：對UML實體進行文字描述注釋連接：將注釋體與要描述的實體連接，說明該注釋體是針對該實體所進行的描述。?使用??擴展?UML用例圖用例圖中的圖符：?使用??擴展?UML用例圖97設(shè)置邊界風(fēng)險分析交易估計進行交易超越邊界更新帳目評價貿(mào)易經(jīng)理營銷人員記帳系統(tǒng)銷售人員?使用??使用??擴展?UML用例圖設(shè)置邊界風(fēng)險分析交易估計進行交易超越邊界更新帳目評價貿(mào)易經(jīng)理98用例模型的獲?。韩@取執(zhí)行者獲取用例UML用例圖用例模型的獲取：UML用例圖99獲取執(zhí)行者：誰使用系統(tǒng)的主要功能（主要使用者）？誰需要系統(tǒng)支持他們的日常工作？誰來維護、管理系統(tǒng)使其能正常工作（輔助使用者）？系統(tǒng)需要控制哪些硬件？系統(tǒng)需要與其他哪些系統(tǒng)交互？對系統(tǒng)產(chǎn)生的結(jié)果感興趣的是哪些人？UML用例圖獲取執(zhí)行者：UML用例圖100獲取用例：執(zhí)行者要求系統(tǒng)提供哪些功能？執(zhí)行者需要讀、產(chǎn)生、刪除、修改或存儲系統(tǒng)中的信息有哪些類型？必須提醒執(zhí)行者的系統(tǒng)事件有哪些？執(zhí)行者必須提醒系統(tǒng)事件有哪些？怎樣把這些事件表示成用例中的功能？UML用例圖獲取用例：UML用例圖101UML類圖在面向?qū)ο蟮慕＜夹g(shù)中，類、對象和它們之間的關(guān)系是最基本的建模元素。對于一個想要描述的系統(tǒng)，其類模型、對象模型以及它們之間的關(guān)系揭示了系統(tǒng)的結(jié)構(gòu)。類圖描述了系統(tǒng)中的類及其相互之間的各種關(guān)系，其本質(zhì)反映了系統(tǒng)中包含的各種對象的類型以及對象間的各種靜態(tài)關(guān)系（關(guān)聯(lián)，子類型）。UML類圖在面向?qū)ο蟮慕＜夹g(shù)中，類、對象和它們之間的關(guān)系102類圖中的圖符：類：表示一個類，其中第一欄是類的名，第二欄是類的屬性，第三欄是類的操作。包：包是一種分組機制，表示一個類圖集合。關(guān)聯(lián)：用于表示類的對象之間的關(guān)系。其特殊形式有組成關(guān)聯(lián)和聚集關(guān)聯(lián)。OperationsAttributesClassPackageUML類圖類圖中的圖符：OperationsAttributesCla103類圖中的圖符：聚集關(guān)聯(lián)：用于表示類的對象之間的關(guān)系是整體與部分的關(guān)系。組成關(guān)聯(lián)：用于表示類的對象之間的關(guān)系：整體擁有各部分，部分與整體共存，如整體不存在了，部分也會隨之消失。泛化關(guān)聯(lián)：泛化關(guān)系（繼承關(guān)系）定義了類和包間的一般元素和特殊元素之間的分類關(guān)系。UML類圖類圖中的圖符：UML類圖104類圖中的圖符：依賴關(guān)系：有兩個類或包元素X、Y，修改元素X的定義可能會引起對另一個元素Y的定義的修改，則稱元素Y依賴于元素X。對象：類的一個實例。鏈接：用于表示對象間的關(guān)聯(lián)關(guān)系的一個實例。ValuesObjectUML類圖類圖中的圖符：ValuesObjectUML類圖105訂單DateReceivedisPrepaidnumber:Stringprce:MoneyDispatch()close()訂單項Quantity:Integerprice:MoneyisSatisfied:Boolean1*項客戶NameaddressCreditRating():String團體客戶ContactNamecreditRatingcreditLimitRemind()billforMonth(Intrger)雇員產(chǎn)品個人客戶CreditCard#{creditRating()=“poor”}銷售代表1*0..11**UML類圖訂單DateReceivedDispatch()訂單項Qua106UML對象圖對象圖對象圖是類圖的一種變形。除了在對象名下面要加下劃線以外，對象圖中所使用的符號與類圖基本相同。對象圖是類圖的一種實例化。一張對象圖表示的是與其對應(yīng)的類圖的一個具體實例，即系統(tǒng)在某一時期或者某一特定時刻可能存在的具體對象實例以及它們相互之間的具體關(guān)系。UML對象圖對象圖107作者計算機名字：String內(nèi)存：Ineger名字：String年齡：Integer0..1Uses1..*小王：作者小王的工作PC：計算機名字=“王小影”年齡=32小王的工作PC：計算機名字=“CompaqX”內(nèi)存=32名字=“Dell486”內(nèi)存=64類圖對象圖UML對象圖作者計算機名字：String名字：String0..1Use108對象圖并不象類圖那樣具有重要的地位，但是利用它可以幫助我們通過具體的實例分析，更具體直觀地了解復(fù)雜系統(tǒng)類圖的豐富內(nèi)涵。對象圖還常常被用作合作圖的一部分，用以展示一組對象實例之間的動態(tài)協(xié)作關(guān)系。UML對象圖對象圖并不象類圖那樣具有重要的地位，但是利用它可以幫助我們通109UML包圖包是類的集合。包圖所顯示的是類的包以及這些包之間的依賴關(guān)系。如果兩個包中的任意兩個類之間存在依賴關(guān)系，則這兩個包之間存在依賴關(guān)系。包的依賴是不傳遞的。UML包圖包是類的集合。110訂單獲取界面訂單獲取應(yīng)用AWT郵件發(fā)送清單界面郵件發(fā)送清單應(yīng)用訂單顧客UML包圖訂單獲取訂單獲取AWT郵件發(fā)送郵件發(fā)送訂單顧客UML包圖111何時使用包圖：在大項目中，包圖是一種重要工具（有專家建議，只要你不能將整個系統(tǒng)的類圖壓縮到一張A4紙上，你就應(yīng)該使用包圖）；依賴產(chǎn)生耦合，應(yīng)該盡量將依賴性減少到最低程度；包的概念對測試也是特別有用的。UML包圖何時使用包圖：UML包圖112UML狀態(tài)圖狀態(tài)圖狀態(tài)圖是對類的一種補充描述，它展示了此類對象所具有的可能的狀態(tài)以及某些事件發(fā)生時其狀態(tài)的轉(zhuǎn)移情況。在狀態(tài)圖中，狀態(tài)由圓角矩形表示。狀態(tài)的改變稱作轉(zhuǎn)移，狀態(tài)轉(zhuǎn)移由箭頭表示，箭頭旁可以標(biāo)出轉(zhuǎn)移發(fā)生的條件。狀態(tài)轉(zhuǎn)移可以伴隨有某個動作，它表明當(dāng)轉(zhuǎn)移發(fā)生時系統(tǒng)要做什么。UML狀態(tài)圖狀態(tài)圖113下降狀態(tài)在第一層上升狀態(tài)向第一層下降空閑狀態(tài)上升到達到達上升超時下降到達第一層UML狀態(tài)圖下降狀態(tài)在第一層上升狀態(tài)向第一層下降空閑狀態(tài)上升到達到達上升114UML順序圖順序圖順序圖描述了對象之間動態(tài)的交互關(guān)系，著重體現(xiàn)對象間消息傳遞的時間順序。順序圖由一組對象構(gòu)成，每個對象分別帶有一條豎線，稱作對象的生命線，它代表時間軸，時間沿豎線向下延伸。順序圖描述了這些對象隨著時間的推移相互之間交換消息的過程。消息用從一條垂直的對象生命線指向另一個對象的生命線的水平箭頭表示。圖中還可以根據(jù)需要增加有關(guān)時間的說明和其他注釋。UML順序圖順序圖115：計算機：打印服務(wù)程序：打印隊列：打印機打印文件打印文件[打印機空閑]保存文件[打印機忙]UML順序圖：計算機：打印服務(wù)程序：打印隊列：打印機打印文件打印文件[打116P1P2P3e1e2e3e4e5e6e7e8e9e10UML順序圖P1P2P3e1e2e3e4e5e6e7e8e9e10UML117順序圖中的事件順序：因果性（Causality）：對同一消息而言，發(fā)送事件先于接收事件?？煽匦裕–ontrolability)：對同一對象而言，事件p出現(xiàn)在發(fā)送事件q的上方，則p先于q。隊列性（FIFO)：對同一對象而言，接收事件p出現(xiàn)在接收事件q的上方，并且它們分別對應(yīng)的發(fā)送事件也位于同一個對象，則p先于q。UML順序圖順序圖中的事件順序：UML順序圖118e1e2e3e4e5e6e8e7e9e10e12e11P1P2P3P1P2P3e1e2e3e4e6e5e7e8e9e11e10e12UML順序圖e1e2e3e4e5e6e8e7e9e10e12e11P1P119UML協(xié)作圖協(xié)作圖與順序圖作用相同，協(xié)作圖也是用來描述系統(tǒng)中對象之間的動態(tài)協(xié)作關(guān)系。協(xié)作圖側(cè)重于描述各個對象之間存在的消息收發(fā)關(guān)系（交互關(guān)系），而不專門突出這些消息發(fā)送的時間順序。在協(xié)作圖中，對象同樣是用一個對象圖符來表示，箭頭表示消息發(fā)送的方向，而消息執(zhí)行的順序則由消息的編號來表明。UML協(xié)作圖協(xié)作圖120UML協(xié)作圖：計算機：打印隊列：打印服務(wù)程序：打印機1.打印文件3.保存文件[打印機忙]2.打印文件[打印機空閑]UML協(xié)作圖：計算機：打印隊列：打印服務(wù)程序：打印機1.打121協(xié)作圖的布局方法能更清楚地表示出對象之間靜態(tài)的連接關(guān)系。順序圖突出執(zhí)行的時序，能更方便地看出事情發(fā)生的次序。如果要描述在一個用例中的幾個對象協(xié)同工作的行為，交互圖是一種有力的工具。交互圖擅長顯示對象之間的協(xié)作關(guān)系，盡管它并不對這些對象的行為進行精確的定義。如果想要描述跨越多個用例的單個對象的行為，應(yīng)當(dāng)使用狀態(tài)圖；如果想要描述跨越多個用例或多個線程的多個對象的復(fù)雜行為，則需考慮使用活動圖。UML協(xié)作圖協(xié)作圖的布局方法能更清楚地表示出對象之間靜態(tài)的連接關(guān)系。UM122UML活動圖活動圖活動圖描述系統(tǒng)中各種活動的執(zhí)行順序，通常用于描述一個操作中所要進行的各項活動的執(zhí)行流程。同時，它也常被用來描述一個用例的處理流程，或者某種交互流程?；顒訄D由一些活動組成，圖中同時包括了對這些活動的說明。當(dāng)一個活動執(zhí)行完畢之后，控制將沿著控制轉(zhuǎn)移箭頭轉(zhuǎn)向下一個活動?；顒訄D中還可以方便地描述控制轉(zhuǎn)移的條件以及并行執(zhí)行等要求。UML活動圖活動圖123加水到容器中將咖啡放到過濾器中點燃咖啡爐取出咖啡杯把過濾器放到咖啡爐上沖調(diào)咖啡倒咖啡找飲料取一聽可口可樂喝飲料人[找到可口可樂][沒有可口可樂][沒有咖啡][找到咖啡]熄滅咖啡爐UML活動圖加水到容器中將咖啡放到點燃咖啡爐取出咖啡杯把過濾器放沖調(diào)咖啡124活動圖最適合支持描述并行行為，這使之成為支持工作流建模的最好工具?；顒訄D最大的缺點是很難清楚地描述動作與對象之間的關(guān)系。UML活動圖活動圖最適合支持描述并行行為，這使之成為支持工作流建模的最好125對于以下情況可以使用活動圖：（1）分析用例；（2）理解牽涉多個用例的工作流；（3）處理多線程應(yīng)用。在下列情況下，一般不要使用活動圖：（1）顯示對象間合作；（2）顯示對象在其生命周期內(nèi)的運轉(zhuǎn)情況。UML活動圖對于以下情況可以使用活動圖：UML活動圖126UML部件圖部件圖部件圖描述軟件構(gòu)件以及它們之間的依賴關(guān)系，從而便于人們分析和發(fā)現(xiàn)當(dāng)修改某個部件時可能對那些部件產(chǎn)生影響，以便對它們做相應(yīng)的修改或更新。部件可以是源代碼部件、二進制目標(biāo)碼部件、可執(zhí)行部件或文檔部件。UML部件圖部件圖127Whnd.cpp：窗口處理器Graphic.dll：圖形庫Comhnd.cpp：命令處理器Main.cpp：主類Whnd.obj：窗口處理器Comhnd.obj：命令處理器Main.obj：主類client.exe：客戶程序UML部件圖Whnd.cpp：Gr128UML配置圖配置圖配置圖描述系統(tǒng)中硬件和軟件的物理配置情況和系統(tǒng)體系結(jié)構(gòu)。在配置圖中，用結(jié)點表示實際的物理設(shè)備，如計算機和各種外部設(shè)備等，并根據(jù)它們之間的連接關(guān)系，將相應(yīng)的結(jié)點連接起來，并說明其連接方式。在結(jié)點里面，說明分配給該結(jié)點上運行的可執(zhí)行部件或?qū)ο?，從而說明哪些軟件單元被分配在哪些結(jié)點上運行。UML配置圖配置圖129客戶A：個人電腦PC客戶B：個人電腦PC數(shù)據(jù)庫服務(wù)器：VAX服務(wù)器：02?TCP/IP協(xié)議??TCP/IP?協(xié)議?DecNet協(xié)議?UML配置圖客戶A：客戶B：數(shù)據(jù)庫服務(wù)器：服務(wù)器：02?TCP/IP協(xié)議130UML應(yīng)用領(lǐng)域最常用的是為軟件系統(tǒng)建模，但不限于軟件系統(tǒng)建模。UML還可用來描述其他非軟件系統(tǒng)，如一個機構(gòu)的組成或機構(gòu)中的工作流程等。UML應(yīng)用領(lǐng)域最常用的是為軟件系統(tǒng)建模，但不限于軟件131UML的應(yīng)用領(lǐng)域UML被用來為系統(tǒng)建模，它可應(yīng)用的范圍非常廣泛在不同系統(tǒng)中的應(yīng)用信息系統(tǒng)技術(shù)系統(tǒng)嵌入式實時系統(tǒng)分布式系統(tǒng)商業(yè)系統(tǒng)UML的應(yīng)用領(lǐng)域UML被用來為系統(tǒng)建模，它可應(yīng)用的范圍非常廣132在軟件開發(fā)不同階段的應(yīng)用需求分析分析設(shè)計構(gòu)造測試在軟件開發(fā)不同階段的應(yīng)用需求分析133UML應(yīng)用---需求分析階段UML的用例視圖可以表示客戶的需求，通過用例建?？梢詫ν獠康慕巧约八鼈兯枰南到y(tǒng)功能建模。UML應(yīng)用---需求分析階段UML的用例視圖可以表134UML應(yīng)用---分析階段分析階段主要考慮所要解決的問題?？捎肬ML的邏輯視圖和動態(tài)視圖來描述，類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)；協(xié)作圖、狀態(tài)圖、順序圖和活動圖描述系統(tǒng)的動態(tài)特征。在分析階段，只為問題領(lǐng)域的類建模，不定義軟件系統(tǒng)的解決方案的細節(jié)（如用戶接口的類數(shù)據(jù)庫等）。UML應(yīng)用---分析階段分析階段主要考慮所要解決的問題。135UML應(yīng)用---設(shè)計階段在設(shè)計階段把分析階段的結(jié)果擴展成技術(shù)解決方案，加入新的類來提供技術(shù)基礎(chǔ)結(jié)構(gòu)---用戶接口，數(shù)據(jù)庫操作等。分析階段的領(lǐng)域問題類被嵌入在這個技術(shù)基礎(chǔ)結(jié)構(gòu)中，設(shè)計階段的結(jié)果是構(gòu)造階段的詳細的規(guī)格說明。UML應(yīng)用---設(shè)計階段在設(shè)計階段把分析階段的136UML應(yīng)用---構(gòu)造階段在構(gòu)造（或程序設(shè)計）階段把設(shè)計階段的類轉(zhuǎn)換成某種面向?qū)ο蟪绦蛟O(shè)計語言的代碼。UML應(yīng)用---構(gòu)造階段在構(gòu)造（或程序設(shè)計）階137UML應(yīng)用---測試階段對系統(tǒng)的測試通常分為單元測試、集成測試、系統(tǒng)測試和接受測試幾個不同級別。不同的測試小組使用不同的UML圖作為他們工作的基礎(chǔ)。單元測試使用類圖和類的規(guī)格說明；集成測試典型地使用組件圖和協(xié)作圖；而系統(tǒng)測試實現(xiàn)用例圖來確認系統(tǒng)的行為是否符合這些圖中的定義。UML應(yīng)用---測試階段對系統(tǒng)的測試通常分為單元測試13811.3基于UML的面向?qū)ο?/p>

分析與設(shè)計概要UML是一種建模語言，是系統(tǒng)開發(fā)的一個組成部分，本身并沒有關(guān)于開發(fā)過程概念的定義和表示符號。UML的創(chuàng)始者們在Rational公司的支持下綜合了多種系統(tǒng)開發(fā)過程的長處，提出新的面向?qū)ο蟮拈_發(fā)過程，稱為Rational統(tǒng)一過程（RationalUnifiedProcess，RUP）。RUP過程的核心工作流包括：業(yè)務(wù)建模、需求分析、系統(tǒng)分析與設(shè)計、實現(xiàn)、測試和系統(tǒng)配置。11.3基于UML的面向?qū)ο?/p>

分析與設(shè)計概要139運用UML進行面向?qū)ο?/p>

系統(tǒng)分析與設(shè)計的主要過程（1）識別系統(tǒng)的用例和角色首先對項目進行需求調(diào)研，依據(jù)項目的業(yè)務(wù)流程圖和數(shù)據(jù)流程圖以及項目中涉及的各級操作人員，通過分析，識別出系統(tǒng)中的所有用例和角色；接著分析系統(tǒng)中各角色和用例間的聯(lián)系，再使用UML建模工具畫出系統(tǒng)的用例圖，同時，勾畫系統(tǒng)的概念層模型，借助UML建模工具描述概念層類圖和活動圖。運用UML進行面向?qū)ο?/p>

系統(tǒng)分析與設(shè)計的主要過程（1）識別140（2）進行系統(tǒng)分析，并抽取類系統(tǒng)分析的任務(wù)是找出系統(tǒng)的所有需求并加以描述，同時建立特定領(lǐng)域模型。建立域模型有助于開發(fā)人員考察用例，從中抽取出類，并描述類之間的關(guān)系。運用UML進行面向?qū)ο?/p>

系統(tǒng)分析與設(shè)計的主要過程

（2）進行系統(tǒng)分析，并抽取類運用UML進行面向?qū)ο?/p>

系統(tǒng)分析141（3）系統(tǒng)設(shè)計，并設(shè)計類及其行為設(shè)計階段由架構(gòu)設(shè)計和詳細設(shè)計組成。①架構(gòu)設(shè)計是高層設(shè)計，其任務(wù)是定義包（子系統(tǒng)），包括包間的依賴關(guān)系和主要通信機制。包有利于描述系統(tǒng)的邏輯組成部分以及各部分之間的依賴關(guān)系。②詳細設(shè)計就是要細化包的內(nèi)容，清晰描述所有的類，同時使用UML的動態(tài)模型描述在特定環(huán)境下這些類的實例的行為。運用UML進行面向?qū)ο?/p>

系統(tǒng)分析與設(shè)計的主要過程

（3）系統(tǒng)設(shè)計，并設(shè)計類及其行為運用UML進行面向?qū)ο?/p>

系統(tǒng)142案例分析—圖書館管理系統(tǒng)目的通過一個具體的項目開發(fā)實例，簡要介紹面向?qū)ο筌浖_發(fā)的一些基本機制。加深對面向?qū)ο蠓椒ê徒y(tǒng)一軟件過程的理解。案例分析—圖書館管理系統(tǒng)目的143需求工程--需求收集需求獲取是軟件系統(tǒng)開發(fā)的起點。通常我們可以通過會談、集體討論等有效的方式獲取、理解用戶需求。并最終采用文檔—需求規(guī)范文檔的方式把所收集的需求文檔化。需求工程--需求收集需求獲取是軟件系統(tǒng)開發(fā)的起點。通常我們可144需求收集在圖書管理系統(tǒng)需求規(guī)范文檔中可能指出如下內(nèi)容：這是一個圖書館支持系統(tǒng)；圖書館將圖書和雜志借給借書者。借書者已經(jīng)預(yù)先注冊，圖書和雜志也預(yù)先登記；圖書館負責(zé)新書的采購。每一本圖書都購進多本書。當(dāng)舊書超期或破舊不堪時，從圖書館中處理掉。圖書管理員是圖書館的員工。他們的工作就是和讀者打交道并在軟件系統(tǒng)的支持下工作。借閱人可以預(yù)定當(dāng)前沒有的圖書和雜志。這樣，當(dāng)他所預(yù)定的圖書和雜志歸還回來或購進時，就通知預(yù)定人。當(dāng)預(yù)定了某書的借書者借閱了該書后，預(yù)定就取消。或者通過顯式的取消過程強行預(yù)定。需求收集在圖書管理系統(tǒng)需求規(guī)范文檔中可能指出如下內(nèi)容：145需求收集圖書館能夠容易地建立、修改和刪除標(biāo)題、借書者、借閱信息和預(yù)定信息。系統(tǒng)能夠運行在所有流行的技術(shù)環(huán)境中，包括Unix,Windows和OS/2，并應(yīng)有一個現(xiàn)代的圖形用戶界面。系統(tǒng)容易擴展新功能。這里我們暫時不必考慮預(yù)定的圖書到達后通知預(yù)定人的功能，也不必檢查借書過期的情況。需求收集圖書館能夠容易地建立、修改和刪除標(biāo)題、借書者、借閱信146用例建模為了理解系統(tǒng)所要解決的業(yè)務(wù)問題，以便掌握用戶需求，我們可以采用用例圖進行需求建模。用例圖描述了外部用戶所能觀察到的系統(tǒng)功能。它通過列出用例和角色，顯示用例和角色的關(guān)系，從而給出了目標(biāo)系統(tǒng)的功能。用例建模為了理解系統(tǒng)所要解決的業(yè)務(wù)問題，以便掌握用戶需求，我147用例建模圖書館管理系統(tǒng)的用例有：借書（LendItem）返書（ReturnItem）預(yù)訂圖書（MakeReservation）刪除預(yù)訂（RemoveReservation）管理（Maintenance）增加書目標(biāo)題（AddTitle）更新或刪除書目標(biāo)題（UpdateorRemoveTitle）添加書籍（AddItem）移除書籍（RemoveItem）增加借書者（AddBorrower）更新或刪除借書者（UpdateorRemoveBorrower）用例建模圖書館管理系統(tǒng)的用例有：借書（LendItem）148用例建模圖書管理系統(tǒng)用例圖如下：用例建模圖書管理系統(tǒng)用例圖如下：149用例文檔的編寫應(yīng)該為圖書管理系統(tǒng)用例圖中所有用例編寫用例文檔。用例文檔中應(yīng)包括如下內(nèi)容：名稱描述前置條件后置條件活動的基本過程；在用例文檔中還可添加一些可選內(nèi)容，如參與者、狀態(tài)、擴展點、被包含的用例、變更歷史。用例文檔的編寫應(yīng)該為圖書管理系統(tǒng)用例圖中所有用例編寫用例文檔150用例文檔名稱：LendItem描述：讀者借閱圖書館中的圖書前置條件： 借書者已經(jīng)預(yù)先注冊，圖書和雜志也預(yù)先登記；后置條件： 如果讀者已經(jīng)注冊，且圖書館內(nèi)讀者所借圖書處于可借閱狀態(tài)，則讀者借得圖書，產(chǎn)生一條借閱記錄。活動的基本過程：1、如果借書者沒有預(yù)訂：書名被識別；與書名對應(yīng)的一本可用書被識別；借書者被識別；系統(tǒng)借出這本書；新的借出記錄被登記。用例文檔名稱：LendItem151用例文檔2、如果借書者有預(yù)訂：借書者被識別書名被識別；與書名對應(yīng)的一本可用書被識別；系統(tǒng)借出對應(yīng)的書；新的借出記錄被登記；刪除預(yù)訂。需求工程階段得到的用例圖在許多教材中稱之為本質(zhì)用例即EssentialUseCase--我們這里沿用這種稱呼。用例文檔2、如果借書者有預(yù)訂：需求工程階段得到的用例圖在許多152確定構(gòu)建內(nèi)容--面向?qū)ο蠓治龇治鲞^程的主要成果以及它們之間的聯(lián)系如下:需求工程關(guān)注理解用戶和他們的使用，而分析關(guān)注于理解要構(gòu)建的內(nèi)容。分析是一個迭代的過程！用例圖順序圖類圖（分析）活動圖用戶界面原型確定構(gòu)建內(nèi)容--面向?qū)ο蠓治龇治鲞^程的主要成果以及它們之間的153確定構(gòu)建內(nèi)容--面向?qū)ο蠓治鲈诜治鲭A段需要本質(zhì)用例轉(zhuǎn)化成系統(tǒng)用例。系統(tǒng)用例圖除了包含本質(zhì)用例的基本內(nèi)容外，還添加了更多目標(biāo)系統(tǒng)高級實現(xiàn)決策。系統(tǒng)用例的編寫系統(tǒng)用例編寫非常簡單—從本質(zhì)用例開始，修改它們并反映使用順序圖、活動圖、用戶界面原型等模型捕獲的信息。依據(jù)RUP，軟件開發(fā)過程的迭代性質(zhì)，我們這里首先構(gòu)建系統(tǒng)用例，然后使用順序圖可視化系統(tǒng)用例中部分用例的實現(xiàn)細節(jié)，最后適當(dāng)調(diào)整系統(tǒng)用例。確定構(gòu)建內(nèi)容--面向?qū)ο蠓治鲈诜治鲭A段需要本質(zhì)用例轉(zhuǎn)化成系統(tǒng)154確定構(gòu)建內(nèi)容--面向?qū)ο蠓治龃_定構(gòu)建內(nèi)容--面向?qū)ο蠓治?55確定構(gòu)建內(nèi)容--面向?qū)ο蠓治鲇美齃endItem的實現(xiàn)細節(jié)—順序圖：LenditemLendareserveditem確定構(gòu)建內(nèi)容--面向?qū)ο蠓治鲇美齃endItem的實現(xiàn)細節(jié)156LenditemLenditem157LendareserveditemLendareserveditem158域分析（DomainAnalysis）系統(tǒng)分析也詳細地列出了域（系統(tǒng)中的關(guān)鍵類）。為了導(dǎo)出一個域分析，可以閱讀定義文檔（specifications）和用例，查找哪一些概念應(yīng)該被系統(tǒng)處理。或者組織一個集體討論，在用戶及領(lǐng)域?qū)＜夜餐膮⑴c下指出系統(tǒng)中必須處理的關(guān)鍵概念，以及它們之間的關(guān)系。對象模型是面向?qū)ο蠓治龊驮O(shè)計的支柱，它顯示了系統(tǒng)的類，這些類之間的關(guān)系。在分析階段，對象模型表示概念模型，它是問題域抽象的擴展。域分析（DomainAnalysis）系統(tǒng)分析也詳細地列出159域分析圖書館系統(tǒng)中的域類如下：BorrowerInfo（如此命名是為了與用例圖中的角色borrower區(qū)分開來），title，booktitle,magazinetitle,item,reservation和loan。這些類以及它們之間的關(guān)系記錄在類圖文檔中，如下圖所示：域分析圖書館系統(tǒng)中的域類如下：BorrowerInfo（如160類圖類圖161域分析其中有些類有狀態(tài)圖，用來顯示這些類的對象可能具有的不同狀態(tài)，以及觸發(fā)他們的狀態(tài)發(fā)生改變的事件。該例子中有狀態(tài)圖的類是item和title類。Item類的狀態(tài)圖：域分析其中有些類有狀態(tài)圖，用來顯示這些類的對象可能具有的不同162人機界面分析當(dāng)對順序圖建模時，必須提供窗體和對話框作為人機交互的界面。在本分析當(dāng)中，只要知道借書、預(yù)定和還書需要窗體就可以了。在此，詳細的界面不必考慮。為了把系統(tǒng)中的窗體類和域類分開，所有的窗體類組織在一起放在GUIPackage包中。域類組織在一起放在BusinessPackage包中。人機界面分析當(dāng)對順序圖建模時，必須提供窗體和對話框作為人機交163人機界面分