統(tǒng)一建模語(yǔ)言（UML）為描述面向?qū)ο笙到y(tǒng)定義了一系列的標(biāo)準(zhǔn)符號(hào)。使用UML增強(qiáng)了領(lǐng)域?qū)＜?、工作流專家、軟件設(shè)計(jì)者和其他不同背景的專家之間的交流聯(lián)系。UML可以在普遍的場(chǎng)合使用，對(duì)工作流系統(tǒng)的用戶而言很直觀。 除了這些，UML符號(hào)具有準(zhǔn)確的語(yǔ)義，也就是說(shuō)可視化的工作流描述可以作為軟件規(guī)約。本文側(cè)重討論了如何使用UML來(lái)描述工作流管理系統(tǒng)，如何跟蹤從業(yè)務(wù)流程到面向?qū)ο筌浖O(shè)計(jì)的描述信息，如何用UML可交互工件來(lái)結(jié)構(gòu)化項(xiàng)目知識(shí)庫(kù)。
在本文中，我們先來(lái)討論工作流產(chǎn)品的軟件設(shè)計(jì)者和用戶對(duì)一種通用語(yǔ)言的需要，然后再來(lái)介紹如何使用統(tǒng)一建模語(yǔ)言（UML）描述一般的工作流概念，最后希望和搭建一起探討如何把面向?qū)ο筌浖?guī)約與工作流系統(tǒng)的描述聯(lián)系起來(lái)。
下面我們先來(lái)描述一個(gè)企業(yè)在實(shí)現(xiàn)新工作流管理系統(tǒng)時(shí)的通常情形：
顧問(wèn)與用戶一起描述一個(gè)軟件解決方案所支持的企業(yè)業(yè)務(wù)流程。開(kāi)發(fā)隊(duì)伍獲得顧問(wèn)的描述，但是他們很難理解業(yè)務(wù)術(shù)語(yǔ)，發(fā)現(xiàn)其中描述了太多的信息以至于難以用來(lái)實(shí)現(xiàn)此系統(tǒng)。開(kāi)發(fā)者從技術(shù)觀點(diǎn)來(lái)撰寫(xiě)系統(tǒng)規(guī)約，當(dāng)把這個(gè)系統(tǒng)規(guī)約呈現(xiàn)在用戶面前時(shí)，由于過(guò)于專業(yè)，以至于用戶難以理解。然而為了進(jìn)行下一步的工作，雙方被迫接受了這個(gè)系統(tǒng)規(guī)約。
這種方式很容易導(dǎo)致系統(tǒng)無(wú)法達(dá)到用戶的需求。用戶、顧問(wèn)和開(kāi)發(fā)者通常都不是用同樣的語(yǔ)言，這樣的交流問(wèn)題導(dǎo)致難以保證業(yè)務(wù)流程所有部分很好溝通，并轉(zhuǎn)換為技術(shù)性的軟件規(guī)約。另外，因?yàn)槭褂么讼到y(tǒng)的實(shí)際用戶很難全部理解技術(shù)性的系統(tǒng)規(guī)約，使軟件系統(tǒng)變得難以使用。
其挑戰(zhàn)性在于能用一種既準(zhǔn)確又友好的方法來(lái)為業(yè)務(wù)流程和業(yè)務(wù)系統(tǒng)建模。用來(lái)描述業(yè)務(wù)流程的每一個(gè)符號(hào)對(duì)用戶來(lái)說(shuō)很直觀，并有確定的語(yǔ)義，因此開(kāi)發(fā)者可以用它作為一般的描述，甚至用來(lái)精確的描述軟件系統(tǒng)規(guī)約。
UML有著豐富和復(fù)雜的符號(hào)來(lái)描述軟件系統(tǒng)。這些符號(hào)也許太豐富以至于不直觀、不友好。然而，恰當(dāng)?shù)赜肬ML來(lái)描述工作流管理系統(tǒng)有兩大好處。首先，UML是軟件界公認(rèn)的符號(hào)標(biāo)準(zhǔn)；第二，UML也可用在不需要實(shí)現(xiàn)細(xì)節(jié)的一般場(chǎng)合。在顯示的UML圖與那些領(lǐng)域?qū)＜乙呀?jīng)在使用的圖在直觀上很相近，另外，它們的語(yǔ)義有精確的定義。如有必要，可出于軟件設(shè)計(jì)的目的給同樣的圖增加詳細(xì)的實(shí)現(xiàn)細(xì)節(jié)。
業(yè)務(wù)系統(tǒng)的描述由流程和靜態(tài)結(jié)構(gòu)的描述組成。流程最直觀的模型就是一個(gè)活動(dòng)或任務(wù)的序列，按照順序完成以到達(dá)某個(gè)目標(biāo)。因此，UML的序列圖和活動(dòng)圖很適用于友好、準(zhǔn)確、詳細(xì)地描述業(yè)務(wù)流程，如組織圖之類的靜態(tài)結(jié)構(gòu)，沒(méi)有實(shí)現(xiàn)細(xì)節(jié)，可以用UML的靜態(tài)結(jié)構(gòu)圖描述。圖形化的實(shí)現(xiàn)細(xì)節(jié)往往會(huì)誤導(dǎo)那些不精通UML的人。例如，導(dǎo)航箭頭經(jīng)常錯(cuò)誤地表示方向，最好是僅用UML表示選項(xiàng)的某一特定子集。例如，把元素互相嵌套來(lái)表示組裝比用實(shí)心菱形表示關(guān)聯(lián)要好。用文字來(lái)描述各種屬性，而不用UML符號(hào)，例如《refine》就比帶三角形的虛線好理解得多。
工作流概念映射到UML概念
這里介紹了用UML來(lái)描述工作流概念的例子。這僅僅提供了一個(gè)一般的指導(dǎo)，如何把工作流概念映像成UML，詳細(xì)的細(xì)節(jié)很容易從UML的語(yǔ)義和符號(hào)指南[7]得到。工作流管理系統(tǒng)的每個(gè)結(jié)構(gòu)都能用合適構(gòu)造型的UML符號(hào)來(lái)描述。
圖1顯示了用UML描述業(yè)務(wù)流程、業(yè)務(wù)對(duì)象、團(tuán)隊(duì)角色。業(yè)務(wù)對(duì)象在UML中用類和對(duì)象表示。類描述沒(méi)有特性（identity）的業(yè)務(wù)對(duì)象，如發(fā)票(invoice)；對(duì)象描述有特性的業(yè)務(wù)對(duì)象，比如編號(hào)為VM4/55的發(fā)票(VM 4/55: invoice)。業(yè)務(wù)流程1用用例和用例實(shí)例來(lái)描述，用例根據(jù)目標(biāo)、職責(zé)、前置條件和后置條件來(lái)描述；用例對(duì)象是具體的事件序列。工作流是自動(dòng)化的業(yè)務(wù)流程，用帶有構(gòu)造型 <
假設(shè)業(yè)務(wù)流程是在業(yè)務(wù)系統(tǒng)中的業(yè)務(wù)對(duì)象、角色和其他的實(shí)例之間協(xié)作完成的。請(qǐng)參看詳細(xì)介紹“跟蹤業(yè)務(wù)流程到軟件設(shè)計(jì)”。
圖2 UML的靜態(tài)結(jié)構(gòu)圖描述團(tuán)隊(duì)結(jié)構(gòu)
圖2顯示了一個(gè)團(tuán)隊(duì)結(jié)構(gòu)的例子。團(tuán)隊(duì)的角色用對(duì)象實(shí)例表示，為每個(gè)角色指定了雇員數(shù)量。一個(gè)客戶滿意團(tuán)隊(duì)（Customer Satisfaction Team）有三個(gè)開(kāi)發(fā)員、兩個(gè)測(cè)試員、一個(gè)產(chǎn)品經(jīng)理和一個(gè)人擔(dān)任用戶角色。角色組叫做客戶滿意團(tuán)隊(duì)（Customer Satisfaction Team），用包符號(hào)表示。角色組也可能被表示成對(duì)象——作為角色的組裝（composition）。如果團(tuán)隊(duì)表示為對(duì)象，團(tuán)隊(duì)和角色之間的關(guān)系為組裝關(guān)系，那么根據(jù)UML元模型概念，一個(gè)特定的角色實(shí)例不能同時(shí)屬于多于一個(gè)團(tuán)隊(duì)。如果團(tuán)隊(duì)表示為包，特定的角色實(shí)例可以同時(shí)屬于幾個(gè)團(tuán)隊(duì)。
圖3描述了業(yè)務(wù)流程的實(shí)例。角色客戶(customer) 下了一份定單，然后銷售(sales)部門(mén)中的某個(gè)工人確認(rèn)此定單。如果定單有效，此工人調(diào)用另一業(yè)務(wù)流程“公司運(yùn)輸物品（company ships an item）”的實(shí)例。這個(gè)類型的圖在UML表示法指南中沒(méi)有明確的提到，然而，它符合UML的元模型。在對(duì)象生命線頂部的符號(hào)代表分類器角色，如圖3中的角色、對(duì)象角色和用例角色。
圖4是UML用例圖，描述了業(yè)務(wù)流程之間的靜態(tài)關(guān)系。業(yè)務(wù)流程描述組織(organization)與角色客戶（customer）的協(xié)作。注意在UML的1.1版本中，用例不能相互聯(lián)系而總是由角色發(fā)送信號(hào)觸發(fā)。這給建模環(huán)境帶來(lái)困難，一個(gè)用例在運(yùn)行期間，當(dāng)特殊條件出現(xiàn)時(shí)，另一個(gè)用例也開(kāi)始啟動(dòng)。在這種情況下，角色通過(guò)與另一個(gè)用例的聯(lián)系初始化此用例而不需發(fā)出任何特定的開(kāi)始信號(hào)。例如，如果客戶的請(qǐng)求被評(píng)估為有效，用例公司運(yùn)輸物品（company ships an item）被組織中的對(duì)象觸發(fā)。這個(gè)用例實(shí)例不直接由客戶觸發(fā)，希望下一版本的UML將減少用例間有關(guān)聯(lián)系的限制。
UML用例圖不容易表達(dá)出用例實(shí)例的順序，例如，首先客戶請(qǐng)求一項(xiàng)物品，然后公司將傳送此物品，最后客戶付款。一個(gè)解決的方法就是在用例間使用約束{precedes}或依賴關(guān)系 <
圖5 UML序列圖描述業(yè)務(wù)流程和執(zhí)行者（Actor）之間的交互
角色可以通過(guò)特殊順序啟動(dòng)用例的方法來(lái)使用系統(tǒng)。像這樣的場(chǎng)景——用例實(shí)例序列——可以用順序圖或協(xié)作圖描述，參看圖5和圖6。對(duì)照對(duì)象交互圖，場(chǎng)景被描述為消息序列，用例交互圖把場(chǎng)景描述為用例序列。這個(gè)圖僅僅是由其他場(chǎng)景的實(shí)例組成的一個(gè)場(chǎng)景的UML圖。在圖5中消息調(diào)用（invoke）表示用例構(gòu)造器和映射為從角色到用例的信號(hào)。根據(jù)每個(gè)用例的最開(kāi)始操作，如調(diào)用請(qǐng)求（invoke request）, 調(diào)用運(yùn)輸（invoke shipment）和調(diào)用付款（invoke payment），可以命名這些消息，除了這些消息之外，用例交互圖能表示角色與系統(tǒng)間其他消息的交互，并描述了用例與角色的全部交談。
用例協(xié)作圖也描述業(yè)務(wù)流程實(shí)例組成的一個(gè)場(chǎng)景。不象用例序列圖，用例協(xié)作圖描述用例實(shí)例和角色實(shí)例之間的用例關(guān)系和消息交互。用例協(xié)作圖如圖6所示。
用例交互圖描述的僅僅是由用例實(shí)例組成的一種典型場(chǎng)景。因此它不能表達(dá)用例實(shí)例所有允許的順序，屬于用例包的用例實(shí)例所允許的順序可以在用例包生命周期內(nèi)詳細(xì)說(shuō)明。用例包的生命周期可用靜態(tài)圖、Backus-Naur范式（BNF）(請(qǐng)參看[4]如何使用BNF指定生命周期。)的活動(dòng)圖表示，在這些狀態(tài)中，活動(dòng)狀態(tài)或BNF聲明映射為用例包中的用例。用例包生命周期是用例包行為的準(zhǔn)確描述，然而它難以正確表達(dá)，尤其在復(fù)雜的用例中。用例交互圖很容易表達(dá)，但它描述的僅僅是由包中用例組成的某一典型場(chǎng)景。
圖7是UML活動(dòng)圖，描述了用例包訂單管理（order management）的生命周期。在活動(dòng)圖中的活動(dòng)與圖4、5、6中的用例相對(duì)應(yīng)。
注意UML元模型沒(méi)有定義任何從狀態(tài)或行為狀態(tài)到用例實(shí)例的映射，這種映射可以在開(kāi)發(fā)過(guò)程進(jìn)行，與Martin和Odell方法相似，其中子系統(tǒng)的每個(gè)狀態(tài)都指明子系統(tǒng)中的一個(gè)候選類。參考[5]。然后，其他開(kāi)發(fā)過(guò)程可能以其它方式定義用例包生命周期。例如，用例包生命周期的目的在用例包的范圍內(nèi)可被指定為子系統(tǒng)接口操作允許的順序。
統(tǒng)一建模語(yǔ)言（UML）為描述面向?qū)ο笙到y(tǒng)定義了一系列的標(biāo)準(zhǔn)符號(hào)。使用UML增強(qiáng)了領(lǐng)域?qū)＜?、工作流專家、軟件設(shè)計(jì)者和其他不同背景的專家之間的交流聯(lián)系。UML可以在普遍的場(chǎng)合使用，對(duì)工作流系統(tǒng)的用戶而言很直觀。 除了這些，UML符號(hào)具有準(zhǔn)確的語(yǔ)義，也就是說(shuō)可視化的工作流描述可以作為軟件規(guī)約。本文側(cè)重討論了如何使用UML來(lái)描述工作流管理系統(tǒng)，如何跟蹤從業(yè)務(wù)流程到面向?qū)ο筌浖O(shè)計(jì)的描述信息，如何用UML可交互工件來(lái)結(jié)構(gòu)化項(xiàng)目知識(shí)庫(kù)。
在本文中，我們先來(lái)討論工作流產(chǎn)品的軟件設(shè)計(jì)者和用戶對(duì)一種通用語(yǔ)言的需要，然后再來(lái)介紹如何使用統(tǒng)一建模語(yǔ)言（UML）描述一般的工作流概念，最后希望和搭建一起探討如何把面向?qū)ο筌浖?guī)約與工作流系統(tǒng)的描述聯(lián)系起來(lái)。
下面我們先來(lái)描述一個(gè)企業(yè)在實(shí)現(xiàn)新工作流管理系統(tǒng)時(shí)的通常情形：
顧問(wèn)與用戶一起描述一個(gè)軟件解決方案所支持的企業(yè)業(yè)務(wù)流程。開(kāi)發(fā)隊(duì)伍獲得顧問(wèn)的描述，但是他們很難理解業(yè)務(wù)術(shù)語(yǔ)，發(fā)現(xiàn)其中描述了太多的信息以至于難以用來(lái)實(shí)現(xiàn)此系統(tǒng)。開(kāi)發(fā)者從技術(shù)觀點(diǎn)來(lái)撰寫(xiě)系統(tǒng)規(guī)約，當(dāng)把這個(gè)系統(tǒng)規(guī)約呈現(xiàn)在用戶面前時(shí)，由于過(guò)于專業(yè)，以至于用戶難以理解。然而為了進(jìn)行下一步的工作，雙方被迫接受了這個(gè)系統(tǒng)規(guī)約。
這種方式很容易導(dǎo)致系統(tǒng)無(wú)法達(dá)到用戶的需求。用戶、顧問(wèn)和開(kāi)發(fā)者通常都不是用同樣的語(yǔ)言，這樣的交流問(wèn)題導(dǎo)致難以保證業(yè)務(wù)流程所有部分很好溝通，并轉(zhuǎn)換為技術(shù)性的軟件規(guī)約。另外，因?yàn)槭褂么讼到y(tǒng)的實(shí)際用戶很難全部理解技術(shù)性的系統(tǒng)規(guī)約，使軟件系統(tǒng)變得難以使用。
其挑戰(zhàn)性在于能用一種既準(zhǔn)確又友好的方法來(lái)為業(yè)務(wù)流程和業(yè)務(wù)系統(tǒng)建模。用來(lái)描述業(yè)務(wù)流程的每一個(gè)符號(hào)對(duì)用戶來(lái)說(shuō)很直觀，并有確定的語(yǔ)義，因此開(kāi)發(fā)者可以用它作為一般的描述，甚至用來(lái)精確的描述軟件系統(tǒng)規(guī)約。
UML有著豐富和復(fù)雜的符號(hào)來(lái)描述軟件系統(tǒng)。這些符號(hào)也許太豐富以至于不直觀、不友好。然而，恰當(dāng)?shù)赜肬ML來(lái)描述工作流管理系統(tǒng)有兩大好處。首先，UML是軟件界公認(rèn)的符號(hào)標(biāo)準(zhǔn)；第二，UML也可用在不需要實(shí)現(xiàn)細(xì)節(jié)的一般場(chǎng)合。在顯示的UML圖與那些領(lǐng)域?qū)＜乙呀?jīng)在使用的圖在直觀上很相近，另外，它們的語(yǔ)義有精確的定義。如有必要，可出于軟件設(shè)計(jì)的目的給同樣的圖增加詳細(xì)的實(shí)現(xiàn)細(xì)節(jié)。
業(yè)務(wù)系統(tǒng)的描述由流程和靜態(tài)結(jié)構(gòu)的描述組成。流程最直觀的模型就是一個(gè)活動(dòng)或任務(wù)的序列，按照順序完成以到達(dá)某個(gè)目標(biāo)。因此，UML的序列圖和活動(dòng)圖很適用于友好、準(zhǔn)確、詳細(xì)地描述業(yè)務(wù)流程，如組織圖之類的靜態(tài)結(jié)構(gòu)，沒(méi)有實(shí)現(xiàn)細(xì)節(jié)，可以用UML的靜態(tài)結(jié)構(gòu)圖描述。圖形化的實(shí)現(xiàn)細(xì)節(jié)往往會(huì)誤導(dǎo)那些不精通UML的人。例如，導(dǎo)航箭頭經(jīng)常錯(cuò)誤地表示方向，最好是僅用UML表示選項(xiàng)的某一特定子集。例如，把元素互相嵌套來(lái)表示組裝比用實(shí)心菱形表示關(guān)聯(lián)要好。用文字來(lái)描述各種屬性，而不用UML符號(hào)，例如《refine》就比帶三角形的虛線好理解得多。
工作流概念映射到UML概念
這里介紹了用UML來(lái)描述工作流概念的例子。這僅僅提供了一個(gè)一般的指導(dǎo)，如何把工作流概念映像成UML，詳細(xì)的細(xì)節(jié)很容易從UML的語(yǔ)義和符號(hào)指南[7]得到。工作流管理系統(tǒng)的每個(gè)結(jié)構(gòu)都能用合適構(gòu)造型的UML符號(hào)來(lái)描述。
圖1顯示了用UML描述業(yè)務(wù)流程、業(yè)務(wù)對(duì)象、團(tuán)隊(duì)角色。業(yè)務(wù)對(duì)象在UML中用類和對(duì)象表示。類描述沒(méi)有特性（identity）的業(yè)務(wù)對(duì)象，如發(fā)票(invoice)；對(duì)象描述有特性的業(yè)務(wù)對(duì)象，比如編號(hào)為VM4/55的發(fā)票(VM 4/55: invoice)。業(yè)務(wù)流程1用用例和用例實(shí)例來(lái)描述，用例根據(jù)目標(biāo)、職責(zé)、前置條件和后置條件來(lái)描述；用例對(duì)象是具體的事件序列。工作流是自動(dòng)化的業(yè)務(wù)流程，用帶有構(gòu)造型 <
假設(shè)業(yè)務(wù)流程是在業(yè)務(wù)系統(tǒng)中的業(yè)務(wù)對(duì)象、角色和其他的實(shí)例之間協(xié)作完成的。請(qǐng)參看詳細(xì)介紹“跟蹤業(yè)務(wù)流程到軟件設(shè)計(jì)”。
圖2 UML的靜態(tài)結(jié)構(gòu)圖描述團(tuán)隊(duì)結(jié)構(gòu)
圖2顯示了一個(gè)團(tuán)隊(duì)結(jié)構(gòu)的例子。團(tuán)隊(duì)的角色用對(duì)象實(shí)例表示，為每個(gè)角色指定了雇員數(shù)量。一個(gè)客戶滿意團(tuán)隊(duì)（Customer Satisfaction Team）有三個(gè)開(kāi)發(fā)員、兩個(gè)測(cè)試員、一個(gè)產(chǎn)品經(jīng)理和一個(gè)人擔(dān)任用戶角色。角色組叫做客戶滿意團(tuán)隊(duì)（Customer Satisfaction Team），用包符號(hào)表示。角色組也可能被表示成對(duì)象——作為角色的組裝（composition）。如果團(tuán)隊(duì)表示為對(duì)象，團(tuán)隊(duì)和角色之間的關(guān)系為組裝關(guān)系，那么根據(jù)UML元模型概念，一個(gè)特定的角色實(shí)例不能同時(shí)屬于多于一個(gè)團(tuán)隊(duì)。如果團(tuán)隊(duì)表示為包，特定的角色實(shí)例可以同時(shí)屬于幾個(gè)團(tuán)隊(duì)。
圖3描述了業(yè)務(wù)流程的實(shí)例。角色客戶(customer) 下了一份定單，然后銷售(sales)部門(mén)中的某個(gè)工人確認(rèn)此定單。如果定單有效，此工人調(diào)用另一業(yè)務(wù)流程“公司運(yùn)輸物品（company ships an item）”的實(shí)例。這個(gè)類型的圖在UML表示法指南中沒(méi)有明確的提到，然而，它符合UML的元模型。在對(duì)象生命線頂部的符號(hào)代表分類器角色，如圖3中的角色、對(duì)象角色和用例角色。
圖4是UML用例圖，描述了業(yè)務(wù)流程之間的靜態(tài)關(guān)系。業(yè)務(wù)流程描述組織(organization)與角色客戶（customer）的協(xié)作。注意在UML的1.1版本中，用例不能相互聯(lián)系而總是由角色發(fā)送信號(hào)觸發(fā)。這給建模環(huán)境帶來(lái)困難，一個(gè)用例在運(yùn)行期間，當(dāng)特殊條件出現(xiàn)時(shí)，另一個(gè)用例也開(kāi)始啟動(dòng)。在這種情況下，角色通過(guò)與另一個(gè)用例的聯(lián)系初始化此用例而不需發(fā)出任何特定的開(kāi)始信號(hào)。例如，如果客戶的請(qǐng)求被評(píng)估為有效，用例公司運(yùn)輸物品（company ships an item）被組織中的對(duì)象觸發(fā)。這個(gè)用例實(shí)例不直接由客戶觸發(fā)，希望下一版本的UML將減少用例間有關(guān)聯(lián)系的限制。
UML用例圖不容易表達(dá)出用例實(shí)例的順序，例如，首先客戶請(qǐng)求一項(xiàng)物品，然后公司將傳送此物品，最后客戶付款。一個(gè)解決的方法就是在用例間使用約束{precedes}或依賴關(guān)系 <
圖5 UML序列圖描述業(yè)務(wù)鞒毯橢蔥姓擼ˋctor）之間的交互
角色可以通過(guò)特殊順序啟動(dòng)用例的方法來(lái)使用系統(tǒng)。像這樣的場(chǎng)景——用例實(shí)例序列——可以用順序圖或協(xié)作圖描述，參看圖5和圖6。對(duì)照對(duì)象交互圖，場(chǎng)景被描述為消息序列，用例交互圖把場(chǎng)景描述為用例序列。這個(gè)圖僅僅是由其他場(chǎng)景的實(shí)例組成的一個(gè)場(chǎng)景的UML圖。在圖5中消息調(diào)用（invoke）表示用例構(gòu)造器和映射為從角色到用例的信號(hào)。根據(jù)每個(gè)用例的最開(kāi)始操作，如調(diào)用請(qǐng)求（invoke request）, 調(diào)用運(yùn)輸（invoke shipment）和調(diào)用付款（invoke payment），可以命名這些消息，除了這些消息之外，用例交互圖能表示角色與系統(tǒng)間其他消息的交互，并描述了用例與角色的全部交談。
用例協(xié)作圖也描述業(yè)務(wù)流程實(shí)例組成的一個(gè)場(chǎng)景。不象用例序列圖，用例協(xié)作圖描述用例實(shí)例和角色實(shí)例之間的用例關(guān)系和消息交互。用例協(xié)作圖如圖6所示。
用例交互圖描述的僅僅是由用例實(shí)例組成的一種典型場(chǎng)景。因此它不能表達(dá)用例實(shí)例所有允許的順序，屬于用例包的用例實(shí)例所允許的順序可以在用例包生命周期內(nèi)詳細(xì)說(shuō)明。用例包的生命周期可用靜態(tài)圖、Backus-Naur范式（BNF）(請(qǐng)參看[4]如何使用BNF指定生命周期。)的活動(dòng)圖表示，在這些狀態(tài)中，活動(dòng)狀態(tài)或BNF聲明映射為用例包中的用例。用例包生命周期是用例包行為的準(zhǔn)確描述，然而它難以正確表達(dá)，尤其在復(fù)雜的用例中。用例交互圖很容易表達(dá)，但它描述的僅僅是由包中用例組成的某一典型場(chǎng)景。
圖7是UML活動(dòng)圖，描述了用例包訂單管理（order management）的生命周期。在活動(dòng)圖中的活動(dòng)與圖4、5、6中的用例相對(duì)應(yīng)。
注意UML元模型沒(méi)有定義任何從狀態(tài)或行為狀態(tài)到用例實(shí)例的映射，這種映射可以在開(kāi)發(fā)過(guò)程進(jìn)行，與Martin和Odell方法相似，其中子系統(tǒng)的每個(gè)狀態(tài)都指明子系統(tǒng)中的一個(gè)候選類。參考[5]。然后，其他開(kāi)發(fā)過(guò)程可能以其它方式定義用例包生命周期。例如，用例包生命周期的目的在用例包的范圍內(nèi)可被指定為子系統(tǒng)接口操作允許的順序。
聯(lián)系客服
