系統(tǒng)約定：用UML描述工作流管理

2019-11-17 04:38:32

字體：大中小

供稿：網(wǎng)友

統(tǒng)一建模語(yǔ)言（UML）為描述面向?qū)ο笙到y(tǒng)定義了一系列的標(biāo)準(zhǔn)符號(hào)。使用UML增強(qiáng)了領(lǐng)域?qū)＜摇⒐ぷ髁鲗＜摇④浖O(shè)計(jì)者和其他不同背景的專家之間的交流聯(lián)系。UML可以在普遍的場(chǎng)合使用，對(duì)工作流系統(tǒng)的用戶而言很直觀。

除了這些，UML符號(hào)具有準(zhǔn)確的語(yǔ)義，也就是說可視化的工作流描述可以作為軟件規(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í)的通常情形：

　　顧問與用戶一起描述一個(gè)軟件解決方案所支持的企業(yè)業(yè)務(wù)流程。開發(fā)隊(duì)伍獲得顧問的描述，但是他們很難理解業(yè)務(wù)術(shù)語(yǔ)，發(fā)現(xiàn)其中描述了太多的信息以至于難以用來(lái)實(shí)現(xiàn)此系統(tǒng)。開發(fā)者從技術(shù)觀點(diǎn)來(lái)撰寫系統(tǒng)規(guī)約，當(dāng)把這個(gè)系統(tǒng)規(guī)約呈現(xiàn)在用戶面前時(shí)，由于過于專業(yè)，以至于用戶難以理解。然而為了進(jìn)行下一步的工作，雙方被迫接受了這個(gè)系統(tǒng)規(guī)約。

　　這種方式很輕易導(dǎo)致系統(tǒng)無(wú)法達(dá)到用戶的需求。用戶、顧問和開發(fā)者通常都不是用同樣的語(yǔ)言，這樣的交流問題導(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)說很直觀，并有確定的語(yǔ)義，因此開發(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ì)的目的給同樣的圖增加具體的實(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)確、具體地描述業(yè)務(wù)流程，如組織圖之類的靜態(tài)結(jié)構(gòu)，沒有實(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ì)節(jié)很輕易從UML的語(yǔ)義和符號(hào)指南[7]得到。工作流治理系統(tǒng)的每個(gè)結(jié)構(gòu)都能用合適構(gòu)造型的UML符號(hào)來(lái)描述。

系統(tǒng)約定：用UML描述工作流治理

圖1 用UML表示業(yè)務(wù)對(duì)象、業(yè)務(wù)流程、團(tuán)隊(duì)角色

　　圖1顯示了用UML描述業(yè)務(wù)流程、業(yè)務(wù)對(duì)象、團(tuán)隊(duì)角色。業(yè)務(wù)對(duì)象在UML中用類和對(duì)象表示。類描述沒有特性（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)造型 <<workflow>> 的用例或用例實(shí)例描述。在UML中用類和對(duì)象描述團(tuán)隊(duì)角色（team roles），用類來(lái)描述團(tuán)隊(duì)角色的類型，對(duì)象描述擔(dān)任該角色的具體工人（worker）。所有的符號(hào)可以用相應(yīng)的構(gòu)造型來(lái)修飾，如 <<business object>>、<<business PRocess>>和<<team role>> 。每一個(gè)構(gòu)造型都可以用文字或一個(gè)特定的圖標(biāo)表示。

　　假設(shè)業(yè)務(wù)流程是在業(yè)務(wù)系統(tǒng)中的業(yè)務(wù)對(duì)象、角色和其他的實(shí)例之間協(xié)作完成的。請(qǐng)參看具體介紹“跟蹤業(yè)務(wù)流程到軟件設(shè)計(jì)”。

系統(tǒng)約定：用UML描述工作流治理

圖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è)開發(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ì)。

系統(tǒng)約定：用UML描述工作流治理

圖3 UML序列圖描述業(yè)務(wù)流程的實(shí)例

　　圖3描述了業(yè)務(wù)流程的實(shí)例。角色客戶(customer) 下了一份定單，然后銷售(sales)部門中的某個(gè)工人確認(rèn)此定單。假如定單有效，此工人調(diào)用另一業(yè)務(wù)流程“公司運(yùn)輸物品（company ships an item）”的實(shí)例。這個(gè)類型的圖在UML表示法指南中沒有明確的提到，然而，它符合UML的元模型。在對(duì)象生命線頂部的符號(hào)代表分類器角色，如圖3中的角色、對(duì)象角色和用例角色。

系統(tǒng)約定：用UML描述工作流治理

圖4 UML用例圖描述業(yè)務(wù)流程之間的靜態(tài)關(guān)系

　　圖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è)用例也開始啟動(dòng)。在這種情況下，角色通過與另一個(gè)用例的聯(lián)系初始化此用例而不需發(fā)出任何特定的開始信號(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)系 <<precedes>> 。類似的關(guān)系同樣存在于OML（OPEN modeling language），參看[3]，Robert C. Martin建議使用要害字follows替代precedes，參看[6]。這樣替代的原因是依靠關(guān)系 <<follows>>與依靠關(guān)系<<preceds>>的指向相反，依靠關(guān)系<<follows>> 指向通常的依靠方向——從依靠元素指向獨(dú)立元素，至于哪一個(gè)更直觀仍是個(gè)未解決的問題。然而，帶約束或依靠的圖仍然是靜態(tài)結(jié)構(gòu)圖，并不描述特定場(chǎng)景。

系統(tǒng)約定：用UML描述工作流治理

圖5 UML序列圖描述業(yè)務(wù)流程和執(zhí)行者（Actor）之間的交互

　　角色可以通過非凡順序啟動(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è)用例的最開始操作，如調(diào)用請(qǐng)求（invoke request）, 調(diào)用運(yùn)輸（invoke shipment）和調(diào)用付款（invoke payment），可以命名這些消息，除了這些消息之外，用例交互圖能表示角色與系統(tǒng)間其他消息的交互，并描述了用例與角色的全部交談。

系統(tǒng)約定：用UML描述工作流治理

圖6 UML交互圖描述業(yè)務(wù)流程和角色之間的交互和關(guān)系

　　用例協(xié)作圖也描述業(yè)務(wù)流程實(shí)例組成的一個(gè)場(chǎng)景。不象用例序列圖，用例協(xié)作圖描述用例實(shí)例和角色實(shí)例之間的用例關(guān)系和消息交互。用例協(xié)作圖如圖6所示。

系統(tǒng)約定：用UML描述工作流治理

圖7 UML活動(dòng)圖描述業(yè)務(wù)流程的答應(yīng)的順序

　　用例交互圖描述的僅僅是由用例實(shí)例組成的一種典型場(chǎng)景。因此它不能表達(dá)用例實(shí)例所有答應(yīng)的順序，屬于用例包的用例實(shí)例所答應(yīng)的順序可以在用例包生命周期內(nèi)具體說明。用例包的生命周期可用靜態(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元模型沒有定義任何從狀態(tài)或行為狀態(tài)到用例實(shí)例的映射，這種映射可以在開發(fā)過程進(jìn)行，與Martin和Odell方法相似，其中子系統(tǒng)的每個(gè)狀態(tài)都指明子系統(tǒng)中的一個(gè)候選類。參考[5]。然后，其他開發(fā)過程可能以其它方式定義用例包生命周期。例如，用例包生命周期的目的在用例包的范圍內(nèi)可被指定為子系統(tǒng)接口操作答應(yīng)的順序。

　　用例交互模型和用例生命周期還有一個(gè)顯著的區(qū)別——它們?cè)陧?xiàng)目知識(shí)庫(kù)中的位置不同，并且與其它設(shè)計(jì)工件的關(guān)系不同。工件用例交互模型與工件用例模型相關(guān)，工件用例包生命周期與工件用例包相關(guān)，后者的抽象級(jí)別比相對(duì)應(yīng)的用例模型和用例交互模型高。

系統(tǒng)約定：用UML描述工作流治理

圖8 在項(xiàng)目知識(shí)庫(kù)里的用例視圖中工件之間的關(guān)系。

　　符號(hào)用UML表示，為了更加清楚，依靠關(guān)系用role ends3表示。項(xiàng)目知識(shí)庫(kù)的結(jié)構(gòu)化

　　在開發(fā)流程中，軟件構(gòu)架師、設(shè)計(jì)者和開發(fā)者確認(rèn)軟件產(chǎn)品的某些信息，如用例、軟件構(gòu)架、對(duì)象協(xié)作和類描述。這些信息可能十分抽象，如產(chǎn)品前景，也可能非常具體，如源代碼。在本文中，我們把這些信息叫作軟件產(chǎn)品設(shè)計(jì)工件（design artifacts）。

　　我們必須熟悉到設(shè)計(jì)工件與它的表達(dá)之間的區(qū)別：設(shè)計(jì)工件決定業(yè)務(wù)系統(tǒng)的信息，而表達(dá)決定如何把這些信息表示出來(lái)。有些設(shè)計(jì)工件用UML表示，有些用文字或表格表示，例如，類的生命周期可以用UML狀態(tài)圖、活動(dòng)圖、狀態(tài)轉(zhuǎn)移表或Backus-Naur范式表示。類庫(kù)用文字來(lái)表示。

　　工作流治理系統(tǒng)的規(guī)格說明是定義在精確定義的設(shè)計(jì)工件基礎(chǔ)上的，而不是在圖上。這一節(jié)和下一節(jié)將討論設(shè)計(jì)工件的結(jié)構(gòu)，此結(jié)構(gòu)可以明確業(yè)務(wù)流程、業(yè)務(wù)規(guī)則、軟件構(gòu)架和業(yè)務(wù)系統(tǒng)設(shè)計(jì)之間的關(guān)系，并且很輕易擴(kuò)展到覆蓋業(yè)務(wù)系統(tǒng)的其他方面，如團(tuán)隊(duì)結(jié)構(gòu)和項(xiàng)目計(jì)劃。

　　業(yè)務(wù)系統(tǒng)可被描述為多級(jí)的抽象和多種視圖。多級(jí)的抽象如組織級(jí)、系統(tǒng)級(jí)、構(gòu)架級(jí)、類級(jí)；多種視圖如邏輯視圖、用例視圖、分析視圖、測(cè)試視圖或文檔視圖。在抽象的每一級(jí)和在每一視圖里，軟件產(chǎn)品可以用四個(gè)設(shè)計(jì)工件來(lái)描述：分類器之間的靜態(tài)關(guān)系、分類器之間的動(dòng)態(tài)交互、分類器職責(zé)和分類器生命周期。每個(gè)工件可用UML圖或文字來(lái)表示。如圖9和圖10。

系統(tǒng)約定：用UML描述工作流治理

圖9 結(jié)構(gòu)化項(xiàng)目知識(shí)庫(kù)的設(shè)計(jì)工件模式

系統(tǒng)約定：用UML描述工作流治理

圖10 在每一抽象級(jí)的每一視圖中，都可以用四種設(shè)計(jì)工件描述軟件產(chǎn)品。

　　UML分類器是：類、接口、用例、節(jié)點(diǎn)、子系統(tǒng)和組件。

　　分類器模型(classifier model)指定了分類器之間的靜態(tài)關(guān)系。分類器模型可以是一組靜態(tài)結(jié)構(gòu)圖（假如分類器是子系統(tǒng)，類或接口），可以是一組用例圖（假如分類器是用例和執(zhí)行者），可以是一組部署圖（假如分類器是節(jié)點(diǎn)），還可以是一組組件圖（假如分類器是組件）。

　　分類器交互模型（classifier interaction model）指定了分類器之間的交互。分類器交互模型可以用交互圖表示：序列圖或協(xié)作圖。UML表示指南（UML Notation Guide）僅僅描述了那些分類器是對(duì)象的交互圖，并不描述那些分類器是用例、子系統(tǒng)、節(jié)點(diǎn)或組件的交互圖。

　　設(shè)計(jì)工件叫做分類器（classifier），指定了分類器的職責(zé)、角色和分類器接口的靜態(tài)屬性（例如，分類器的操作表，有前置條件和后置條件）。分類器還可以用結(jié)構(gòu)化的文字表示，如CRC卡。

　　分類器生命周期（classifier lifecycle）指定了分類器狀態(tài)機(jī)和分類器接口的動(dòng)態(tài)屬性（例如所答應(yīng)的有順序的操作和事件）。分類器生命周期可以用狀態(tài)圖、活動(dòng)圖和狀態(tài)轉(zhuǎn)移表來(lái)表示。

　　可以把分類器模型的一個(gè)實(shí)例鏈接到分類器交互模型的幾個(gè)實(shí)例上，所有這些實(shí)例都鏈接到分類器的實(shí)例上，分類器的實(shí)例鏈接到分類器生命周期的實(shí)例上。跟蹤業(yè)務(wù)流程到軟件設(shè)計(jì)

　　在結(jié)構(gòu)良好的設(shè)計(jì)文檔中，有關(guān)業(yè)務(wù)流程和軟件產(chǎn)品的信息可以很輕易定位，并且相關(guān)信息鏈接在一起，同時(shí)結(jié)構(gòu)還體現(xiàn)了不同設(shè)計(jì)工件的完整性和一致性，它是業(yè)務(wù)專家、顧問和軟件開發(fā)者溝通的基礎(chǔ)。

此結(jié)構(gòu)還提供了明顯的關(guān)注點(diǎn)，由業(yè)務(wù)人員而不是開發(fā)者定義所有的業(yè)務(wù)規(guī)則。這一節(jié)討論業(yè)務(wù)流程和軟件設(shè)計(jì)工件之間的關(guān)系，用它把項(xiàng)目知識(shí)庫(kù)結(jié)構(gòu)化，給出了把業(yè)務(wù)流程的以及它們與軟件設(shè)計(jì)工件的關(guān)系的構(gòu)造信息。參看[4]獲得知識(shí)庫(kù)結(jié)構(gòu)化的具體實(shí)例。

　　結(jié)構(gòu)是基于業(yè)務(wù)系統(tǒng)中業(yè)務(wù)對(duì)象、角色、工人協(xié)作的業(yè)務(wù)流程（在UML中用用例表示）。業(yè)務(wù)流程（用例）定義為協(xié)作類型，指明了協(xié)作職責(zé)、目標(biāo)、前置條件、后置條件和協(xié)作中調(diào)用的系統(tǒng)操作。業(yè)務(wù)流程實(shí)例（用例實(shí)例）為協(xié)作實(shí)例，指明了在協(xié)作中的行為和事件、系統(tǒng)狀態(tài)和狀態(tài)轉(zhuǎn)移的具體順序。

系統(tǒng)約定：用UML描述工作流治理

圖11 設(shè)計(jì)工件在邏輯和業(yè)務(wù)流程視圖中描述了軟件系統(tǒng)

　　圖11指明了業(yè)務(wù)流程的設(shè)計(jì)工件和軟件系統(tǒng)的邏輯設(shè)計(jì)之間的關(guān)系，工件是按照不同的抽象級(jí)別組織起來(lái)的：組織級(jí)、系統(tǒng)級(jí)、構(gòu)架級(jí)和對(duì)象級(jí)

　　組織級(jí)（organization level）指定了一個(gè)組織（如公司、學(xué)校和政府機(jī)關(guān)）的職責(zé)，以及該組織的業(yè)務(wù)環(huán)境。工件組織（organization）指定了組織的職責(zé)和相關(guān)的靜態(tài)屬性。工件組織模型（organization model）指定了組織與其他組織之間的關(guān)系。工件組織用例（organization use case）用流程目標(biāo)、前置條件、后置條件和業(yè)務(wù)流程必須符合與其相關(guān)的靜態(tài)屬性的業(yè)務(wù)規(guī)則來(lái)指定組織范圍的業(yè)務(wù)流程。這個(gè)業(yè)務(wù)流程是組織與其他組織之間的協(xié)作，這種協(xié)作是在工件組織用例模型（organization use model）中指定的，見圖11中的依靠關(guān)系協(xié)作。組織業(yè)務(wù)流程的實(shí)例是由組織交互模型（organization interaction model）用組織與其他組織間的交互來(lái)指定的。組織業(yè)務(wù)流程可以精化到更具體的系統(tǒng)業(yè)務(wù)流程，見圖11中的依靠關(guān)系精化。工件組織用例生命周期（organization use case life cycle）指定了所答應(yīng)的系統(tǒng)業(yè)務(wù)流程。組織用例交互模型（organization use case interaction model）指定了典型的業(yè)務(wù)流程實(shí)例序列，見圖11中的實(shí)例依靠關(guān)系。組織業(yè)務(wù)流程的實(shí)現(xiàn)用軟件系統(tǒng)和它的用戶（團(tuán)隊(duì)角色）之間的交互來(lái)指定，見圖11和12中實(shí)現(xiàn)依靠關(guān)系。

　　系統(tǒng)級(jí)（system level）指定了軟件系統(tǒng)的環(huán)境以及與它的角色之間的關(guān)系。工件系統(tǒng)（system）用職責(zé)、前置條件、后置條件、參數(shù)和返回值來(lái)指明系統(tǒng)的接口和操作。若角色職責(zé)和接口是相關(guān)的，并由工件角色（actor）指定。系統(tǒng)生命周期（system lifecycle）指定了所答應(yīng)的系統(tǒng)操作和事件。系統(tǒng)模型（system model）指定了軟件系統(tǒng)和角色（其他系統(tǒng)和用戶）之間的關(guān)系，系統(tǒng)交互模型（system interaction model）指定了軟件系統(tǒng)和角色之間的交互。這些交互是系統(tǒng)業(yè)務(wù)流程的實(shí)例，見圖11中依靠關(guān)系實(shí)例。工件系統(tǒng)用例（system use case）用流程的目標(biāo)、前置條件、后置條件、非功能性需求、業(yè)務(wù)規(guī)則和其他相關(guān)靜態(tài)屬性指定了在系統(tǒng)范圍內(nèi)的業(yè)務(wù)流程。這個(gè)業(yè)務(wù)流程是系統(tǒng)與其它系統(tǒng)或用戶的協(xié)作。

　　這些系統(tǒng)與它的角色之間的協(xié)作是在工件系統(tǒng)用例模型（system use case model）中描述的，見圖11中的依靠關(guān)系協(xié)作。業(yè)務(wù)流程接口的動(dòng)態(tài)屬性，如在業(yè)務(wù)流程范圍內(nèi)所答應(yīng)的系統(tǒng)操作順序，是在系統(tǒng)用例生命周期（system use case life cycle）中指定的。系統(tǒng)用例交互模型（system use case interaction model）指定了典型的業(yè)務(wù)流程實(shí)例的序列。系統(tǒng)業(yè)務(wù)流程可以精化到子系統(tǒng)業(yè)務(wù)流程中，見圖11中的依靠關(guān)系精化。系統(tǒng)業(yè)務(wù)流程的實(shí)現(xiàn)用構(gòu)架級(jí)的子系統(tǒng)間的交互來(lái)指定，見圖11中的依靠關(guān)系實(shí)現(xiàn)。

　　構(gòu)架級(jí)（architectual level）定義了子系統(tǒng)（組件）、子系統(tǒng)的職責(zé)、接口、關(guān)系和交互。工件子系統(tǒng)（subsystem）職責(zé)、前置條件、后置條件、參數(shù)和返回值指定了子系統(tǒng)接口和子系統(tǒng)操作。子系統(tǒng)生命周期（subsystem lifecycle）指定了所答應(yīng)的子系統(tǒng)的操作和事件的順序。子系統(tǒng)模型（subsystem model）指定了子系統(tǒng)和其他子系統(tǒng)之間的關(guān)系，子系統(tǒng)交互模型（subsystem interaction model）指定了子系統(tǒng)之間的交互，這些交互是子系統(tǒng)業(yè)務(wù)流程的實(shí)例，見圖11中依靠關(guān)系<<實(shí)例>>。工件子系統(tǒng)用例（subsystem use case）指定了在子系統(tǒng)范圍內(nèi)的業(yè)務(wù)流程，這個(gè)業(yè)務(wù)流程是子系統(tǒng)與其它子系統(tǒng)、系統(tǒng)和用戶之間的協(xié)作。子系統(tǒng)和它的角色之間的所有協(xié)作是在系統(tǒng)用例模型（system use case）中描述的，見圖11中的依靠關(guān)系<<協(xié)作>>。子系統(tǒng)業(yè)務(wù)流程接口的動(dòng)態(tài)特性，如在業(yè)務(wù)流程范圍里所答應(yīng)的子系統(tǒng)操作順序是在子系統(tǒng)用例生命周期（subsystem use case life cycle）中指定的。子系統(tǒng)用例交互模型（subsystem use case interaction model）指定了業(yè)務(wù)流程實(shí)例的典型序列。子系統(tǒng)業(yè)務(wù)流程的實(shí)現(xiàn)用類級(jí)別上對(duì)象之間的交互來(lái)描述，見圖11中的依靠關(guān)系<<實(shí)現(xiàn)>>。

　　對(duì)象級(jí)（object level）用業(yè)務(wù)對(duì)象、業(yè)務(wù)對(duì)象的職責(zé)、關(guān)系和交互來(lái)描述子系統(tǒng)的設(shè)計(jì)。業(yè)務(wù)對(duì)象模型（business object model）指定業(yè)務(wù)對(duì)象之間的靜態(tài)關(guān)系。業(yè)務(wù)對(duì)象交互模型（business object interaction model）用業(yè)務(wù)對(duì)象之間的交互指定子系統(tǒng)操作的設(shè)計(jì)。工件業(yè)務(wù)對(duì)象（business object）指定業(yè)務(wù)對(duì)象的職責(zé)和業(yè)務(wù)對(duì)象接口的靜態(tài)屬性，如用前置條件和后置條件描述的接口操作。業(yè)務(wù)對(duì)象生命周期（business object lifecycle）指定了所答應(yīng)的接口操作順序。

　　圖12中，設(shè)計(jì)工件描述了組織團(tuán)隊(duì)結(jié)構(gòu)。事實(shí)上，它與描述軟件子系統(tǒng)結(jié)構(gòu)的工件沒有什么太大的區(qū)別。團(tuán)隊(duì)的角色可以表示成UML構(gòu)造型的類，工件角色（role）指定工人角色的職責(zé)及其它相關(guān)的靜態(tài)屬性。工件角色生命周期（role lifecycle）指定了角色的動(dòng)態(tài)屬性、它們的狀態(tài)以及它們所響應(yīng)的事件。工件角色模型（role model）指定角色之間的靜態(tài)關(guān)系。成員級(jí)業(yè)務(wù)流程（member level business process）指定團(tuán)隊(duì)成員角色與其它團(tuán)隊(duì)成員角色之間的協(xié)作，見圖12中的依靠關(guān)系<<協(xié)作>>。這些業(yè)務(wù)流程的實(shí)例是在工件角色交互模型（role interaction model）用角色實(shí)例之間的交互指定的，見圖12中的依靠關(guān)系<<實(shí)例>>。

系統(tǒng)約定：用UML描述工作流治理

圖12 在團(tuán)隊(duì)和業(yè)務(wù)流程視圖中，設(shè)計(jì)工件描述了軟件系統(tǒng)

　　稱為團(tuán)隊(duì)（team）的設(shè)計(jì)工件是一個(gè)角色包，指明了團(tuán)隊(duì)的職責(zé)以及相關(guān)的靜態(tài)屬性。團(tuán)隊(duì)的動(dòng)態(tài)屬性是在工件團(tuán)隊(duì)生命周期（team life cycle）中指定的。工件團(tuán)隊(duì)模型（team model）指定了團(tuán)隊(duì)之間的靜態(tài)關(guān)系。團(tuán)隊(duì)級(jí)業(yè)務(wù)流程（team level business process）指定了團(tuán)隊(duì)和其它團(tuán)隊(duì)之間的協(xié)作，見圖12中的依靠關(guān)系<<協(xié)作>>。團(tuán)隊(duì)級(jí)業(yè)務(wù)流程的實(shí)例是在團(tuán)隊(duì)交互模型（team interaction level）中指定的，見圖12中的依靠關(guān)系<<實(shí)例>>。團(tuán)隊(duì)級(jí)業(yè)務(wù)流程的實(shí)現(xiàn)用團(tuán)隊(duì)成員之間的交互以及團(tuán)隊(duì)成員與軟件系統(tǒng)之間的交互來(lái)指定，如圖12中的依靠關(guān)系<<實(shí)現(xiàn)>>。設(shè)計(jì)工件的模式可以用相似的方法應(yīng)用在更高的抽象級(jí)4上。

　　這一節(jié)描述的設(shè)計(jì)工件的結(jié)構(gòu)可以通過兩種方式簡(jiǎn)化：

　　· 只使用設(shè)計(jì)工件的子集；
　　· 把緊密相關(guān)的一些設(shè)計(jì)工件結(jié)合起來(lái)，構(gòu)成更大的設(shè)計(jì)工件單元。

　　使用設(shè)計(jì)工件的子集不會(huì)導(dǎo)致信息的丟失，因?yàn)閁ML圖系統(tǒng)不是正交的。意思是同樣的信息可以用兩個(gè)或更多不同的UML圖來(lái)描述。例如，兩個(gè)靜態(tài)結(jié)構(gòu)圖和對(duì)象協(xié)作圖描述對(duì)象之間的關(guān)系。兩個(gè)狀態(tài)圖和交互圖描述對(duì)象之間的消息。因?yàn)橥瑯拥男畔⒖梢詮膸讉€(gè)方位來(lái)描述，開發(fā)者所提供的僅僅是設(shè)計(jì)工件的特定子集，否則此工件必須接受關(guān)于一致性的檢查。

　　由于實(shí)際的原因，設(shè)計(jì)者可以創(chuàng)建一個(gè)更大的可交互工件來(lái)包含幾個(gè)緊密相關(guān)的工件。例如，分類器職責(zé)和生命周期總是與某一文檔相關(guān)和結(jié)合。也可以把組織、系統(tǒng)、子系統(tǒng)和類用例圖結(jié)合成一個(gè)大用例圖，以清楚地區(qū)別用例級(jí)。同樣的，系統(tǒng)、子系統(tǒng)和業(yè)務(wù)對(duì)象靜態(tài)結(jié)構(gòu)和相對(duì)應(yīng)的所有級(jí)別里的交互圖可以結(jié)合成一個(gè)文檔，也可用UML語(yǔ)義把靜態(tài)結(jié)構(gòu)圖、組件、節(jié)點(diǎn)和每一級(jí)的用例圖結(jié)合起來(lái)表示。用這種方法，設(shè)計(jì)者可以在一個(gè)大的靜態(tài)結(jié)構(gòu)圖中表達(dá)用例、角色、子系統(tǒng)、業(yè)務(wù)對(duì)象、團(tuán)隊(duì)成員和業(yè)務(wù)流程之間的關(guān)系，然而“UML表示法指南”沒有清楚地提到這樣結(jié)合的靜態(tài)結(jié)構(gòu)圖。

　　小結(jié)

　　本文討論了用UML表示面向?qū)ο蠊ぷ髁髦卫硐到y(tǒng)，給出了如何把典型工作流概念映射到UML概念的方法，并建議結(jié)構(gòu)化設(shè)計(jì)工件，從而跟蹤業(yè)務(wù)流程的定義和面向?qū)ο筌浖O(shè)計(jì)之間的信息。此結(jié)構(gòu)展示了業(yè)務(wù)流程可表示為業(yè)務(wù)對(duì)象、團(tuán)隊(duì)角色和業(yè)務(wù)系統(tǒng)中其它實(shí)例的協(xié)作，此結(jié)構(gòu)基于四種相關(guān)的設(shè)計(jì)工件的模式，這四種設(shè)計(jì)工件為分類器關(guān)系、交互、職責(zé)和生命周期。此模式可以應(yīng)用于一個(gè)業(yè)務(wù)系統(tǒng)的不同抽象級(jí)和不同的視圖，也可應(yīng)用于業(yè)務(wù)和軟件系統(tǒng)設(shè)計(jì)的其它方面。

上一篇：java模式之單例模式

下一篇：深入編程:控制面板知多少(下)