《軟件建模與實(shí)踐》課件-4-軟件建模和設(shè)計(jì)方法

課程內(nèi)容協(xié)作的對(duì)象建模和體系結(jié)構(gòu)設(shè)計(jì)方法(COMET)需求、分析和設(shè)計(jì)建模中的活動(dòng)用例建模靜態(tài)建模動(dòng)態(tài)建模課程目的

了解COMET

了解需求、分析和設(shè)計(jì)建模中的活動(dòng)

掌握用例建模、靜態(tài)建模和動(dòng)態(tài)建模重點(diǎn)COMET、用例建模、靜態(tài)建模、動(dòng)態(tài)建模難點(diǎn)動(dòng)態(tài)建模協(xié)作的對(duì)象建模和體系結(jié)構(gòu)設(shè)計(jì)方法(CollaborativeObjectModelingandArchitecturalDesignMethod，COMET)是一種常用的迭代用例驅(qū)動(dòng)和面向?qū)ο蟮姆椒?，與統(tǒng)一軟件開(kāi)發(fā)過(guò)程(UnifiedSoftwareDevelopmentProcess，USDP)和螺旋模型兼容。軟件建模的全過(guò)程包括需求建模、分析建模和設(shè)計(jì)建模三個(gè)階段。4.1協(xié)作的對(duì)象建模和體系結(jié)構(gòu)設(shè)計(jì)方法圖4-1

COMET基于用例的軟件生存周期模型(1)在需求建模階段進(jìn)行用例模型開(kāi)發(fā)。(2)在分析建模階段進(jìn)行靜態(tài)和動(dòng)態(tài)系統(tǒng)模型的構(gòu)建。(3)在設(shè)計(jì)建模階段進(jìn)行系統(tǒng)軟件體系結(jié)構(gòu)的設(shè)計(jì)，并將分析模型映射到設(shè)計(jì)模型中。(4)增量軟件構(gòu)建方法是指采用一系列的增量構(gòu)件來(lái)設(shè)計(jì)、實(shí)現(xiàn)、集成和測(cè)試軟件，每一個(gè)構(gòu)件由多種相互作用的模塊所形成的提供特定功能的代碼片段構(gòu)成。(5)在增量軟件集成期間，以增量所選用例為依據(jù)對(duì)各軟件增量進(jìn)行集成測(cè)試。(6)系統(tǒng)測(cè)試主要包括系統(tǒng)的功能測(cè)試，是基于黑盒用例完成系統(tǒng)測(cè)試。COMET基于用例的軟件生存周期模型4.2COMET生存周期與其他軟件過(guò)程的比較1.COMET生存周期與統(tǒng)一軟件開(kāi)發(fā)過(guò)程USDP強(qiáng)調(diào)了過(guò)程和方法COMET方法與USDP的前三個(gè)工作流程相同。2.COMET生存周期與螺旋模型對(duì)比螺旋模型通常由四個(gè)階段組成：制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程和客戶評(píng)估COMET方法也能夠與螺旋模型同時(shí)使用。4.3需求、分析和設(shè)計(jì)建模4.3.1

需求建模中的活動(dòng)(1)用例建模。(2)陳述非功能性需求。4.3.2分析建模中的活動(dòng)(1)靜態(tài)建模(2)對(duì)象的組織(3)動(dòng)態(tài)交互建模(4)動(dòng)態(tài)狀態(tài)機(jī)建模4.3.3

設(shè)計(jì)建模中的活動(dòng)(1)確定系統(tǒng)的軟件體系結(jié)構(gòu)(2)確定子系統(tǒng)結(jié)構(gòu)和接口(3)確定類(lèi)接口采取的決策(4)確定對(duì)象特性的決策(5)確定消息特性的決策4.4用例建模4.4.1需求建模1.

需求分析需求分析是軟件設(shè)計(jì)過(guò)程的重要一環(huán)，軟件需求描述了系統(tǒng)必須為用戶提供的功能。功能性需求非功能需求2.需求規(guī)格說(shuō)明書(shū)需求規(guī)格說(shuō)明書(shū)是后續(xù)設(shè)計(jì)和開(kāi)發(fā)的起點(diǎn)，開(kāi)發(fā)者必須理解需求規(guī)格說(shuō)明書(shū)。3.軟件需求規(guī)格說(shuō)明書(shū)的質(zhì)量屬性(1)正確(2)完整(3)無(wú)歧義(4)可行性(5)可驗(yàn)證(6)非計(jì)算機(jī)專家能夠理解(7)可修改(8)可追蹤4.4.2

用例分析在需求建模中，用例是捕獲系統(tǒng)功能性需求的技能，它描述了系統(tǒng)用戶和系統(tǒng)本身的典型交互，定義了一個(gè)或多個(gè)參與者和系統(tǒng)之間的交互序列。圖4-3

ATM系統(tǒng)“取款”用例圖4.4.3參與者參與者描繪了與系統(tǒng)交互的外部用戶。1.參與者、角色和用戶參與者代表了在應(yīng)用領(lǐng)域中扮演的一種角色例如，“銀行系統(tǒng)”中有多位客戶，都由參與者“ATM客戶”來(lái)代表，因此，參與者“ATM客戶”是對(duì)一種用戶類(lèi)型的建模；單個(gè)的客戶是該參與者的實(shí)例。參與者可能是一個(gè)和本系統(tǒng)通過(guò)接口連接的外部系統(tǒng)例如ATM系統(tǒng)中，參與者可以是后臺(tái)服務(wù)器；在實(shí)時(shí)嵌入式系統(tǒng)中，參與者還可以是外部輸入輸出(I/O)設(shè)備、計(jì)時(shí)器外部I/O設(shè)備或計(jì)時(shí)器。2.主要和次要參與者主要參與者啟動(dòng)用例，系統(tǒng)必須響應(yīng)主要參與者。其他參與者稱為次要參與者。一個(gè)用例中的主要參與者可以是另一個(gè)用例中的次要參與者；每個(gè)用例至少有一個(gè)參與者，即主要參與者。3.邊界邊界(Boundary)也叫系統(tǒng)邊界，用于界定系統(tǒng)功能范圍在UML中用一個(gè)帶名稱的矩形框表示，把描述系統(tǒng)功能的用例都置于其中，而描述與系統(tǒng)交互的角色都置于其外。準(zhǔn)確地定義系統(tǒng)的邊界(功能)并非易事，需要先識(shí)別出系統(tǒng)的基本功能集4.

識(shí)別參與者可以通過(guò)回答以下問(wèn)題來(lái)識(shí)別系統(tǒng)的角色：?使用系統(tǒng)主要功能的人是誰(shuí)(即主要角色)？?需要借助于系統(tǒng)完成日常工作的人是誰(shuí)？?誰(shuí)來(lái)維護(hù)和管理系統(tǒng)(次要角色)，保證系統(tǒng)正常工作？?系統(tǒng)控制的硬件設(shè)備有哪些？?系統(tǒng)需要與哪些其它系統(tǒng)交互？?對(duì)系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事是哪些？5.參與者之間的泛化關(guān)系圖4-5

參與者的泛化關(guān)系4.4.4標(biāo)識(shí)用例標(biāo)識(shí)用例可以從參與者及其與系統(tǒng)間的交互開(kāi)始以汽車(chē)租賃系統(tǒng)為例，客戶能啟動(dòng)三個(gè)用例：預(yù)訂、租車(chē)和還車(chē)。用例的主序列描述了參與者和系統(tǒng)之間最常見(jiàn)的交互在“預(yù)訂”用例中，主流是成功預(yù)訂的步驟的序列可替換流用來(lái)說(shuō)明各種錯(cuò)誤情況4.4.5

用例規(guī)格化描述用例描述要素:概述：用例的簡(jiǎn)短描述依賴：該部分可選，描述該用例是否依賴其他用例參與者：該部分給用例中的參與者命名前置條件：從該用例的角度來(lái)看在用例開(kāi)始時(shí)必須為真的一個(gè)或多個(gè)條件。例如，ATM是空閑狀態(tài)，屏幕顯示“歡迎”消息。主流描述：用例的主體是對(duì)該用例主流的敘述性描述。該描述的形式是首先參與者輸入，接著是系統(tǒng)的響應(yīng)。4.4.5

用例規(guī)格化描述可替換流描述：主流的可替換分支的敘述性描述。主流可能有多個(gè)可替換分支。例如，如果客戶的賬戶沒(méi)有足夠的資金，則顯示“余額不足”并退出卡片。非功能性需求：非功能性需求的敘述性描述，例如性能和安全性需求。后置條件：該用例終點(diǎn)處(從該用例的角度來(lái)看)總是為真的條件，前提是遵循了主序列的步驟。例如，客戶的資金已經(jīng)被取出。未解決的問(wèn)題：在開(kāi)發(fā)期間，有關(guān)用例的問(wèn)題被記錄下來(lái)，用于和用戶進(jìn)行討論。4.4.5

用例規(guī)格化描述圖4-7

其購(gòu)物網(wǎng)站的訂單管理員與用例表4-1“處理訂單”用例描述用例名稱處理訂單參與者訂單處理員描述訂單處理員從系統(tǒng)中選擇一個(gè)銷(xiāo)售單，檢查每一訂單項(xiàng)是否有庫(kù)存并處理訂單，系統(tǒng)記錄處理記錄以及訂單管理員信息前提條件銷(xiāo)售單保存在系統(tǒng)中后置條件銷(xiāo)售單狀態(tài)變?yōu)椤耙烟幚怼?，該銷(xiāo)售單持有相應(yīng)的庫(kù)存項(xiàng)，不得再銷(xiāo)售給其他用戶主流(1)訂單處理員選擇銷(xiāo)售單，系統(tǒng)顯示訂單項(xiàng)及數(shù)量(2)訂單處理員檢查每項(xiàng)是否有庫(kù)存(3)訂單處理員為銷(xiāo)售單提取庫(kù)存項(xiàng)，系統(tǒng)將銷(xiāo)售單狀態(tài)修改為“已處理”可替換流第二步：訂單處理員檢查訂單中的每一項(xiàng)，如果沒(méi)貨，則第三步系統(tǒng)將銷(xiāo)售單狀態(tài)修改為“待處理”4.4.6用例關(guān)系用例之間的依賴可以用包含(include)和擴(kuò)展(extend)關(guān)系來(lái)定義，其目的是使可擴(kuò)展性最大化和復(fù)用用例。(1)包含關(guān)系(2)擴(kuò)展關(guān)系(3)泛化關(guān)系和包含關(guān)系用例泛化關(guān)系和包含關(guān)系都可以用來(lái)復(fù)用該模型用例間的行為在用例泛化關(guān)系中，子用例的執(zhí)行不受父用例的結(jié)構(gòu)和行為(復(fù)用部分)的影響；在包含關(guān)系內(nèi)，執(zhí)行基本用例只依賴包含用例(復(fù)用部分)執(zhí)行有關(guān)功能的結(jié)果。圖4-12

泛化關(guān)系4.4.7用例圖在需求分析過(guò)程中的作用會(huì)談的初步成果是能夠發(fā)現(xiàn)一些參與者以及高層用例，這些高層用例概括地描述了系統(tǒng)的功能需求。這些信息提供了系統(tǒng)邊界和范圍。后期與用戶的交談將涉及深層次的需求，產(chǎn)生的成果是詳細(xì)描述了場(chǎng)景和序列的用例模型。

4.5靜態(tài)建模物理類(lèi)是具有物理特性的類(lèi)——即它們能被看到和摸到，這樣的類(lèi)包括物理設(shè)備(在嵌入式應(yīng)用中這往往是問(wèn)題域的一部分)、用戶、外部系統(tǒng)和計(jì)時(shí)器。實(shí)體類(lèi)是概念上的數(shù)據(jù)密集型類(lèi)，通常是持久的——即長(zhǎng)久存在的類(lèi)。4.5.1類(lèi)之間的關(guān)聯(lián)關(guān)聯(lián)定義了兩個(gè)或多個(gè)類(lèi)之間的關(guān)系，指明了類(lèi)之間的一種靜態(tài)的、結(jié)構(gòu)化的關(guān)系。鏈接是代表類(lèi)的對(duì)象(實(shí)例)之間的一組連接，表示類(lèi)之間關(guān)聯(lián)關(guān)系的實(shí)例。關(guān)聯(lián)本身是雙向的。(1)類(lèi)圖中關(guān)聯(lián)的描述在類(lèi)圖中，關(guān)聯(lián)顯示為一條連接兩個(gè)類(lèi)框的實(shí)線，實(shí)線旁邊有關(guān)聯(lián)的名稱。(2)關(guān)聯(lián)的多重性一對(duì)一關(guān)聯(lián)一對(duì)多關(guān)聯(lián)規(guī)定數(shù)值關(guān)聯(lián)

圖4-17

可選(零或一)關(guān)聯(lián)圖4-18

可選(零或一或多)關(guān)聯(lián)可選關(guān)聯(lián)多對(duì)多關(guān)聯(lián)(3)三元關(guān)聯(lián)三元關(guān)聯(lián)是在類(lèi)之間的三個(gè)方向的關(guān)聯(lián)。三元關(guān)聯(lián)通過(guò)連接三個(gè)類(lèi)的菱形展示。(4)一元關(guān)聯(lián)一元關(guān)聯(lián)(也稱為自身關(guān)聯(lián))是一個(gè)類(lèi)的一個(gè)對(duì)象與同一個(gè)類(lèi)的另一個(gè)對(duì)象之間的關(guān)聯(lián)。(5)關(guān)聯(lián)類(lèi)關(guān)聯(lián)類(lèi)是對(duì)兩個(gè)或多個(gè)類(lèi)之間的關(guān)聯(lián)進(jìn)行建模的類(lèi)，關(guān)聯(lián)類(lèi)的屬性就是該關(guān)聯(lián)的屬性。4.5.2組合和聚合層次組合(composition)和聚合(aggregation)層次都是討論一個(gè)類(lèi)由其他類(lèi)構(gòu)成的情況。組合中部分和全體是唇亡齒寒的關(guān)系，每個(gè)實(shí)例都是全體的固有特性。聚合中部分的每個(gè)實(shí)例都不是全體的固有特性，可以有千千萬(wàn)萬(wàn)個(gè)部分實(shí)例，只要有一個(gè)部分實(shí)例存在，聚合關(guān)系形成的全體仍然是其本身。4.5.2組合和聚合層次組合關(guān)系用一條帶實(shí)心菱形箭頭的直線表示，如圖4-23所示。ATM組合類(lèi)和它的四個(gè)部分類(lèi)中的每一個(gè)都是一對(duì)一關(guān)聯(lián)。圖4-23組合層次示例4.5.2組合和聚合層次聚合層次是整體/部分關(guān)系的一種較弱的形式，部分實(shí)例能添加到聚合整體中，也能從聚合整體中移除聚合更適合對(duì)概念類(lèi)建模一個(gè)部分可以屬于多個(gè)聚合4.5.3

泛化/特化層次在泛化/特化層次中，共同屬性被抽象到一個(gè)泛化類(lèi)，稱作超類(lèi)。不同的屬性是特化類(lèi)的性質(zhì)，特化類(lèi)被稱作子類(lèi)。超類(lèi)也被稱為父類(lèi)或祖先類(lèi)，子類(lèi)也被稱為孩子類(lèi)或者孫子類(lèi)。4.5.4

約束在類(lèi)中，約束規(guī)定了必須為真的條件或限制，可以用任何文本語(yǔ)言表示對(duì)屬性的可能值的限制在關(guān)聯(lián)鏈接上的限制4.5.5

靜態(tài)建模與UML(1)系統(tǒng)上下文建模上下文建模在整個(gè)系統(tǒng)(硬件和軟件)的級(jí)別上完成顯式地標(biāo)識(shí)了什么是在系統(tǒng)內(nèi)的，什么是在系統(tǒng)外的。圖4-28

銀行系統(tǒng)的上下文類(lèi)圖(2)使用UML構(gòu)造型對(duì)類(lèi)分類(lèi)COMET方法主張對(duì)類(lèi)進(jìn)行分類(lèi)，從而將具有相似特性的類(lèi)分組到一起。構(gòu)造型:由一對(duì)雙尖括號(hào)(類(lèi)似于漢語(yǔ)書(shū)名號(hào))括起來(lái)按照扮演的角色對(duì)類(lèi)進(jìn)行分類(lèi)，例如<<實(shí)體>>(Entity)類(lèi)或者<<邊界>>(Boundary)類(lèi)。根據(jù)它們?cè)谕獠凯h(huán)境中的特點(diǎn)進(jìn)一步分類(lèi)，例如<<外部系統(tǒng)>>(ExternalSystem)或者<<外部用戶>>(ExternalUser)。 (3)外部類(lèi)建模通過(guò)構(gòu)造性對(duì)外部類(lèi)分類(lèi)(3)外部類(lèi)建模一個(gè)通用的指南是：一方面，人類(lèi)用戶只有在用戶通過(guò)標(biāo)準(zhǔn)輸入/輸出設(shè)備和系統(tǒng)交互時(shí)，才被視為外部用戶類(lèi)；另一方面，如果用戶通過(guò)特定的輸入/輸出設(shè)備和軟件系統(tǒng)進(jìn)行交互，那么這些輸入/輸出設(shè)備就要表示為外部輸入/輸出設(shè)備類(lèi)。(4)實(shí)體類(lèi)的靜態(tài)建模實(shí)體類(lèi)屬于數(shù)據(jù)密集型類(lèi)，它們負(fù)責(zé)存儲(chǔ)數(shù)據(jù)并提供對(duì)這些數(shù)據(jù)的訪問(wèn)服務(wù)。COMET方法強(qiáng)調(diào)對(duì)實(shí)體類(lèi)的靜態(tài)建模，靜態(tài)建?？梢猿浞终故酒湓诒磉_(dá)類(lèi)、屬性和類(lèi)之間的關(guān)系方面的優(yōu)勢(shì)。實(shí)體類(lèi)建模類(lèi)似于對(duì)數(shù)據(jù)庫(kù)的邏輯建模，在設(shè)計(jì)階段實(shí)體類(lèi)會(huì)被映射到一個(gè)數(shù)據(jù)庫(kù)里去。在問(wèn)題域的靜態(tài)建模期間，COMET的重點(diǎn)是確定在問(wèn)題中定義的實(shí)體類(lèi)、它們的屬性和它們的關(guān)系。設(shè)計(jì)建模階段才去設(shè)計(jì)規(guī)定操作。在線購(gòu)物系統(tǒng)實(shí)體類(lèi)模型在對(duì)實(shí)體類(lèi)的建模中，還需定義每個(gè)實(shí)體類(lèi)的屬性。圖4-32

在線購(gòu)物系統(tǒng)的實(shí)體屬性4.6

動(dòng)態(tài)建模在COMET中，系統(tǒng)的靜態(tài)模型僅描述了數(shù)據(jù)是如何封裝到對(duì)象中在動(dòng)態(tài)建模機(jī)制中，以消息完成對(duì)象之間的交互。系統(tǒng)的行為和動(dòng)作通過(guò)對(duì)象間的通信和傳遞信息方式呈現(xiàn)UML狀態(tài)機(jī)圖、順序圖、通信圖來(lái)描述系統(tǒng)的行為靜態(tài)建模和動(dòng)態(tài)建模相互補(bǔ)充，相互利用，對(duì)保證系統(tǒng)的完整性有著重要意義。4.6.1

狀態(tài)機(jī)圖狀態(tài)機(jī)圖描述了對(duì)象隨時(shí)間變化的動(dòng)態(tài)行為。系統(tǒng)的狀態(tài)模型由多個(gè)狀態(tài)機(jī)圖組成，每個(gè)類(lèi)對(duì)應(yīng)一個(gè)狀態(tài)機(jī)圖，描述對(duì)系統(tǒng)來(lái)說(shuō)較重要的那些時(shí)序行為。狀態(tài)機(jī)圖不僅可以表現(xiàn)一個(gè)對(duì)象擁有的狀態(tài)，還可以說(shuō)明事件(例如消息的接收、錯(cuò)誤、條件變更等)如何隨著時(shí)間的推移來(lái)影響這些狀態(tài)。(1)狀態(tài)與事件狀態(tài)(State)表示一個(gè)對(duì)象在其生存周期內(nèi)的狀況一個(gè)狀態(tài)只能在一個(gè)有限的時(shí)間段生存。根據(jù)對(duì)象的總體行為，將其取值和對(duì)應(yīng)鏈接的集合組成一個(gè)狀態(tài)。事件(Event)是指在某個(gè)時(shí)刻發(fā)生的事情并發(fā)事件是兩個(gè)因果無(wú)關(guān)的事件就是并發(fā)的(concurrent)事件包括錯(cuò)誤狀態(tài)以及普通事件事件表示外部激勵(lì)，狀態(tài)表示對(duì)象在對(duì)應(yīng)激勵(lì)下的取值。(2)狀態(tài)機(jī)圖示例狀態(tài)機(jī)圖由表示狀態(tài)的節(jié)點(diǎn)和表示狀態(tài)之間轉(zhuǎn)換的帶箭頭的直線組成。狀態(tài)機(jī)圖通常作為對(duì)類(lèi)圖的補(bǔ)充，完善類(lèi)中依賴于狀態(tài)的各種行為僅需要針對(duì)那些有多個(gè)狀態(tài)，及行為會(huì)受狀態(tài)取值影響而發(fā)生改變的類(lèi)畫(huà)狀態(tài)機(jī)圖。(3)狀態(tài)圖的建模過(guò)程(1)識(shí)別出某個(gè)特定對(duì)象所有可能的狀態(tài)；(2)識(shí)別引起該對(duì)象轉(zhuǎn)移的所有觸發(fā)因素(事件或條件)；(3)表示狀態(tài)轉(zhuǎn)移的實(shí)現(xiàn)過(guò)程(方法或行為)；(4)完善類(lèi)模型。在完成了上述步驟以后，還需要把狀態(tài)圖映射到類(lèi)，從而完善類(lèi)中相關(guān)的屬性和操作。(3)狀態(tài)圖的建模過(guò)程建模狀態(tài)圖的過(guò)程中可以進(jìn)行必要的分組，即將具有共性的簡(jiǎn)單狀態(tài)置于合成狀態(tài)中，讓它們成為子狀態(tài)，從而對(duì)狀態(tài)模型進(jìn)行簡(jiǎn)化圖4-34

圖書(shū)管理系統(tǒng)中“Book”的狀態(tài)機(jī)圖4.6.2

順序圖的建模順序圖用來(lái)表示用例中的行為順序順序圖可供不同的用戶使用幫助分析人員進(jìn)一步明確事件處理流程；幫助開(kāi)發(fā)人員進(jìn)一步了解需要開(kāi)發(fā)的對(duì)象施加在這些對(duì)象上的操作；幫助測(cè)試人員了解過(guò)程的細(xì)節(jié)以開(kāi)發(fā)更加完備的測(cè)試案例順序圖是一個(gè)二維圖，水平方向是對(duì)象維，沿水平方向排列的是參與交互的對(duì)象。參與者的對(duì)象放在圖的兩側(cè)，主要參與者(表示人的參與者)放在最左邊，次要參與者(系統(tǒng)的參與者)放在最右邊順序圖中的垂直方向?yàn)闀r(shí)間維，自上而下按時(shí)間遞增順序列出各對(duì)象所發(fā)出和接收的消息(1)順序圖上的消息標(biāo)簽順序圖上的消息標(biāo)簽遵循以下的語(yǔ)法：[序列表達(dá)式]:消息名稱(參數(shù)列表)順序圖上的消息都會(huì)被賦予消息序列編號(hào)。典型的形式序列如1,2,3……；M1,M2,M3……Dewey分類(lèi)系統(tǒng)來(lái)描述，一個(gè)典型的消息編號(hào)序列是M1,

M1.1,

M1.1.1,

M1.2在消息標(biāo)簽中還可以加入[條件語(yǔ)句]例如[x<n]，意味著只有當(dāng)這個(gè)條件判斷為真的時(shí)候，消息才會(huì)被發(fā)送出去移動(dòng)用戶成功登錄移動(dòng)公司的網(wǎng)站后查詢相關(guān)信息的順序圖(2)對(duì)象的創(chuàng)建和銷(xiāo)毀將create消息發(fā)送給對(duì)象實(shí)例，創(chuàng)建對(duì)象，對(duì)象創(chuàng)建之后才具有生命線；destroy消息用于銷(xiāo)毀對(duì)象，給需要銷(xiāo)毀的對(duì)象發(fā)送這個(gè)消息，同時(shí)在該對(duì)象的生命線上放一個(gè)“×”符號(hào)，表示對(duì)象的生命終止。(3)順序圖建模策略設(shè)置交互語(yǔ)境識(shí)別參與交互過(guò)程的對(duì)象確定消息序列確定可替換流(4)順序圖建模實(shí)例①

用例模型以基于Web服務(wù)的在線購(gòu)物系統(tǒng)中的客戶“結(jié)算訂單”為例，一個(gè)客戶提交結(jié)算訂單信息，系統(tǒng)會(huì)得到客戶信息并且驗(yàn)證支付方式。如果支付方式選擇信用卡支付，當(dāng)信用卡授權(quán)通過(guò)后，系統(tǒng)會(huì)創(chuàng)建一個(gè)新的發(fā)貨單并且顯示訂單。用例的描述如下所示：用例名：提交訂單。概述：客戶在在線購(gòu)物商城中選取商品后，提交結(jié)算請(qǐng)求。客戶選用的是信用卡支付，系統(tǒng)驗(yàn)證信用卡的合法性以及是否有足夠的額度來(lái)支付所選商品的總價(jià)。參與者：客戶。前置條件：客戶選擇了一個(gè)或多個(gè)商品并放在購(gòu)物車(chē)?！敖Y(jié)算訂單”用例模型主流：第一步：客戶提交了訂單詳情和信用卡號(hào)來(lái)結(jié)算訂單。第二步：系統(tǒng)獲得客戶的賬戶信息、訂單信息和信用卡詳細(xì)信息。第三步：系統(tǒng)檢查客戶的信用卡內(nèi)的額度是否足以購(gòu)買(mǎi)所選商品，如果檢查通過(guò)，將會(huì)創(chuàng)建一個(gè)支付流水單號(hào)。第四步：系統(tǒng)創(chuàng)建一個(gè)發(fā)貨單，包括了訂單的詳細(xì)信息、客戶號(hào)以及支付流水單號(hào)。第五步：系統(tǒng)確認(rèn)支付成功并且向客戶顯示訂單的信息。第六步：系統(tǒng)向客戶發(fā)送站內(nèi)確認(rèn)信息“結(jié)算訂單”用例模型可替換流：第三步：如果對(duì)客戶信用卡的授權(quán)失敗(例如信用卡狀態(tài)異?；蛘呤强蛻粜庞每ㄙ~戶的額度不足)，系統(tǒng)會(huì)提示客戶選擇其他支付方式或者輸入新的卡號(hào)?？蛻艨梢暂斎胍粋€(gè)不同的信用卡號(hào)或者是取消這個(gè)訂單。后置條件：系統(tǒng)為客戶創(chuàng)建一個(gè)發(fā)貨單。②確定實(shí)現(xiàn)用例所需的對(duì)象接口對(duì)象“客戶交互”We