原文地址：http://www.aygfsteel.com/RongHao/archive/2007/10/30/157009.html

對于當前的工作流應(yīng)用來說，人工節(jié)點無疑扮演著一個非常重要的角色。因為無論是傳統(tǒng)的協(xié)同辦公系統(tǒng)還是越來越多的企業(yè)應(yīng)用，都需要有人參與到具體的流程中來。這篇文章著重分析工作流應(yīng)用中人工節(jié)點所涉及到的參與者模式以及與此關(guān)聯(lián)的工作項模式，最后會提供部分的解決方案作為參考。

先簡單說說什么是人工節(jié)點。

人工節(jié)點的概念是與自動節(jié)點相對的。顧名思義，人工節(jié)點就是需要有人參與的節(jié)點，在實際流程中，它體現(xiàn)在產(chǎn)生由人完成的工作項以及由人決定一些決策變量，這些決策變量會對流程的運行產(chǎn)生影響（例如分支的選擇等等）。自動節(jié)點則是由工作流引擎自己調(diào)用完成，不需要人的參與，通常是執(zhí)行定制的業(yè)務(wù)操作。相比較而言，人工節(jié)點更多的應(yīng)用在管理流程里，而自動節(jié)點更多的則是應(yīng)用在企業(yè)業(yè)務(wù)流程里。

人工節(jié)點的職責有三個：第一是決定該節(jié)點的參與者；第二是根據(jù)參與者生成需要人來處理的工作項；最后是當工作項被參與者處理完畢時，它將繼續(xù)觸發(fā)流程的流轉(zhuǎn)。參與者處理工作項時可以處理相應(yīng)的業(yè)務(wù)和設(shè)置流程決策變量。

下面我們就按照這三個職責分別對人工節(jié)點所涉及到的參與者模式和工作項模式進行分析。

1、  決定參與者模式

換句話說就是決定該節(jié)點的參與者，這里有兩種模式：引擎自動獲取和最終用戶指定。
 

1．1引擎自動獲取

所謂引擎自動獲取就是由引擎在運行期計算實際的節(jié)點參與者，不需要最終用戶的參與。這個計算基于流程定義時對該節(jié)點參與者的定義。

（1）    直接指定人員、部門或角色

這種情況最簡單，也最直接，用戶定義節(jié)點時直接在組織用戶樹里選定人員、部門或角色，然后在運行期根據(jù)定義執(zhí)行與或者是或的運算。大多數(shù)的工作流引擎都支持這種模式。但很明顯它也存在著很大的局限性，它是靜態(tài)的，一旦流程定義完畢參與者也就跟著固定下來，運行期的任何變化都不會對參與者造成影響，一個很簡單的需求，請假流程，節(jié)點的參與者需要是當前申請者的部門領(lǐng)導(dǎo)，因為申請者在定義期是不確定的，所以根本無法指定節(jié)點的參與者，所以這種模式遠遠滿足不了用戶稍微復(fù)雜一點的需求。

（2）    調(diào)用用戶定制的計算參與者代碼

這種情況通常是由引擎提供一個接口或是父類，用戶需要實現(xiàn)或是繼承這個接口或父類，然后實現(xiàn)相應(yīng)的方法。這個方法通常會傳遞進一個執(zhí)行上下文的參數(shù)，用戶代碼通過這個上下文可以訪問到當前流程實例的信息，例如當前節(jié)點狀態(tài)，工作流變量等等，然后用戶可以根據(jù)實際業(yè)務(wù)和當前流程實例信息進行邏輯計算，最后返回一個參與者的ID集合。對于上一個模式里提到的計算當前申請者部門領(lǐng)導(dǎo)的例子，這個模式實現(xiàn)起來非常簡單，首先獲得當前申請者ID，然后在根據(jù)這個ID找出該申請者部門再找出該部門領(lǐng)導(dǎo)即可。

實際流程運行到該節(jié)點就會調(diào)用用戶自己定制的計算參與者的代碼，方法返回的參與者ID即作為該節(jié)點的實際參與者。

這種模式對于工作流引擎的實現(xiàn)而言最為簡單，因為它把最大的復(fù)雜性都拋給了用戶，由用戶代碼來計算實際的參與者。實際上很多開源的工作流引擎采用的都是這種方式，例如JBPM。但是這種方式給用戶帶來最大靈活性的同時也帶來了復(fù)雜和煩瑣。特別是當面對一個數(shù)量巨大的流程需求時，為每一個流程的每一個人工節(jié)點都定義一個參與者計算類是讓人頭疼的。再加上現(xiàn)在強調(diào)業(yè)務(wù)的敏捷，業(yè)務(wù)里的改變要迅速反饋到流程的定義里，讓最終用戶來編寫或修改這個參與者計算類不現(xiàn)實也不可能。補充一下，這也是用戶在考慮采用開源的工作流引擎還是商業(yè)工作流引擎時需要著重考慮的一個方面。

（3）    指定前續(xù)節(jié)點的參與者

實際上是用戶在節(jié)點定義時指定參與者為前續(xù)某個節(jié)點的參與者，當流程運行到該節(jié)點，引擎會自動獲取所指定的前續(xù)節(jié)點的參與者作為該節(jié)點的實際參與者。

這個模式實現(xiàn)起來并不困難，大多數(shù)商業(yè)工作流引擎都對該模式進行了支持。它能夠滿足用戶的部分特定需求。

（4）    更為復(fù)雜的情況

用戶的需求永遠是復(fù)雜的，引擎所要做得就是盡量降低這種復(fù)雜性，流程的變化要能夠迅速跟上業(yè)務(wù)的變化?？紤]下面兩種稍微復(fù)雜一點但是又很常見的需求。需求一：參與者為當前申請者的部門領(lǐng)導(dǎo)且職位為副總；需求二：參與者需要是測試部的所有女同事。這兩種需求模式1、3都不能滿足，2可以，但是正如提到的那樣，模式2可能會非常的煩瑣，不能適應(yīng)業(yè)務(wù)的敏捷。其實這里的復(fù)雜性主要體現(xiàn)在：1、這里的參與者可能是運行期決定的；2、參與者的限制條件可能非常多，而這些條件不是簡單的部門、角色或職位所能描述的。

對于一般的工作流引擎而言，它們都會選擇模式2的實現(xiàn)，讓用戶自己實現(xiàn)邏輯。實際在后面的部分解決方案里，我們會看到更為好一點的實現(xiàn)方式。

 

1.2最終用戶指定

   運行期由最終用戶來決定節(jié)點的參與者。這也是中國國情所獨有的特色。這種模式最為常見的就是用戶提交工作項時的提交頁面，用戶在該頁面上選定下一節(jié)點（多數(shù)分支用戶選定時）和下一節(jié)點的參與者。這種模式本身并不困難，問題在于在提交頁面需要給用戶提供一個參與者的選擇范圍，讓用戶進行選擇。而關(guān)于這個選擇范圍，則又回到前面所提到的引擎自動獲取的模式，這個范圍同樣是需要引擎計算的。于是又回到了剛剛討論過的四種模式。

 

2、參與者執(zhí)行模式

   現(xiàn)在，已經(jīng)獲得了節(jié)點的參與者。引擎下一步將會根據(jù)這個參與者生成工作項，注意，這里的參與者可能是一個人，也可能會是一個人員范圍（即多個人）。于是就產(chǎn)生了參與者的執(zhí)行模式，也可以理解為工作項的生成模式。

2.1競爭參與

當有多個參與者參與這個節(jié)點時就會產(chǎn)生競爭參與這個模式。同樣一個工作，A可以完成，B也可以完成，于是就產(chǎn)生競爭，誰先開始這項工作，就由誰負責完成該工作。

2.2順序參與

   多個參與者按照指定的順序完成該工作項。A完成之后由B完成，B完成之后再交給C完成。

2.3同時參與

   多個參與者同時對工作進行處理，所有參與者均完成后，流程繼續(xù)向后流轉(zhuǎn)。這個模式其實比較復(fù)雜，因為這里同時涉及到一個完成規(guī)則：是所有參與者均完成工作項后流程流轉(zhuǎn)，還是有其他規(guī)則？例如完成2個工作項即可流轉(zhuǎn)，完成80%的工作項即可流轉(zhuǎn)。稍候會討論到。

2.4負載均衡

   這也是一個常見的需求。這項工作A和B都可以完成，但是A目前有10個待辦工作項，B只有2個待辦工作項。于是用戶期望該工作交由B來完成。這里需要實現(xiàn)一個簡單的負載均衡。其實這種情況只是智能決策的一種最簡單的情況，所謂智能決策是指系統(tǒng)能夠根據(jù)一定的指標（由數(shù)據(jù)分析，例如人員的處理效率，工作負載等等）和規(guī)則來決定該節(jié)點的參與者。

3、工作項完成模式

這個模式在參與者執(zhí)行模式為同時參與時有效。在說到這個模式之前，先簡單說說工作項可能存在的幾種特殊狀態(tài)，這些狀態(tài)包括掛起、人工終止和委派。掛起就是工作項暫時停止執(zhí)行，掛起會影響到流程的流轉(zhuǎn)，會導(dǎo)致流程的掛起。人工終止則是人工手動改變該工作項的狀態(tài)，使該工作項終止執(zhí)行，這個人通常會是管理員。人工終止也會對流程流轉(zhuǎn)產(chǎn)生影響，當除去該工作項之外的所有工作項都完成時，人工終止該工作項會觸發(fā)流程的流轉(zhuǎn)。委派就是將該工作項委派給他人完成，同時該工作項也就結(jié)束了。人工終止和委派是工作項結(jié)束的特殊狀態(tài)。
 

3.1全部完成

當所有工作項都結(jié)束時觸發(fā)節(jié)點的結(jié)束和流程的流轉(zhuǎn)。

3.2完成規(guī)定的個數(shù)

節(jié)點定義時指定工作項必須完成的個數(shù)，當完成的工作項達到這個指定的個數(shù)時觸發(fā)節(jié)點的結(jié)束和流程的流轉(zhuǎn)。 

3.3完成規(guī)定的百分比

節(jié)點定義時指定工作項必須完成的百分比，當完成的工作項占所有工作項的比例達到這個指定的百分比時觸發(fā)節(jié)點的結(jié)束和流程的流轉(zhuǎn)。
 

其實這里很明顯的可以看出不管是所謂的參與者執(zhí)行模式還是工作項完成模式不過都是一定的規(guī)則，既然是一定的規(guī)則那必然就限定了應(yīng)用的靈活性，用戶能否自定義規(guī)則？根據(jù)業(yè)務(wù)靈活地修改規(guī)則？規(guī)則引擎+DSL應(yīng)該是一個不錯的選擇。

周末參加了清華大學信息系統(tǒng)與工程研究所組織的一次工作流研討會。
會上清華大學的研究人員介紹了他們對工作流研究的一些成果。其中主要關(guān)注了數(shù)據(jù)挖掘和分析。
關(guān)于數(shù)據(jù)挖掘，有兩個方面。第一個方面是當企業(yè)沒有應(yīng)用工作流時，對企業(yè)日常數(shù)據(jù)進行挖掘，分析數(shù)據(jù)
之間的關(guān)聯(lián)和邏輯，得出一套基本的企業(yè)應(yīng)用業(yè)務(wù)流程，為將來應(yīng)用工作流做出準備；第二個方面是當企業(yè)
已有工作流應(yīng)用時，對相關(guān)流程數(shù)據(jù)進行挖掘，根據(jù)數(shù)據(jù)描繪出正在運行的流程，很顯然，這個方面與流程
仿真有關(guān)。
關(guān)于數(shù)據(jù)分析，則主要是對流程數(shù)據(jù)進行分析，這個涉及的內(nèi)容就比較多，包括流程的運行效率，人員效率
分析，統(tǒng)計等等。其中有一個非常有趣的例子：貪官A試圖逃跑，逃跑前是有一定前兆的，比如向國外轉(zhuǎn)移
賬款，給小蜜頻繁打電話，工作效率降低等等。于是數(shù)據(jù)分析就可以起作用，對A最近的所有數(shù)據(jù)進行分析，
得出他將要逃跑的結(jié)論。而來自有生博大的趙斌，談?wù)摰剿麄円呀?jīng)實施的項目中，涉及到對一些電子公文
流程中的辦文統(tǒng)計，并依據(jù)“指標”進行工作量和效率的分析。
這其實也反映出我們工作流軟件中缺失的部分：數(shù)據(jù)分析-數(shù)據(jù)統(tǒng)計-優(yōu)化流程。而這也正是BPM的重要功能之一。也是未來發(fā)展的趨勢。功能缺失最重要的原因在于實際上我們的軟件沒有研發(fā)只有開發(fā)。具體他們略微談到了他們一些實現(xiàn)的方式，非常的理論，涉及到算法，數(shù)據(jù)結(jié)構(gòu)等等。我們軟件開發(fā)最主要的是滿足用戶的各種業(yè)務(wù)需求，比如說回退、收回、會簽等等，這也是現(xiàn)實情況所決定的，開發(fā)團隊的人員通常都不是很多，并且這種分析挖掘需要的人員無疑需要很高的理論水準，這個本科往往是達不到的(不得不承認研究生和博士就是比本科要優(yōu)秀)，博士碩士的研發(fā)團隊的開發(fā)成本會非常的高，并且實際產(chǎn)生的利潤很難評價，對于不大的公司來講這個是很難接受的。于是就造成了這種狀況：軟件研發(fā)缺失掉了。
依托高校是個不錯的想法，但是依托高校不等于說你把辦公地點搬到清華大學門口就是依托高校了，也有這種依托，那是買煎餅的。
問題背景：我們是一家工作流公司，客戶采購我們的產(chǎn)品后，將其嵌入其項目中。我們的工作流采用的是   spring+hibernate的方式，客戶項目則是jdbc直接進行數(shù)據(jù)庫操作。
問題：客戶在其數(shù)據(jù)庫操作過程中需要調(diào)用我們的工作流接口，這樣就需要將我們的工作流操作與他們的業(yè)  務(wù)操作置于同一個事務(wù)中。我們的服務(wù)采用的都是spring的聲明式事務(wù)，而客戶采用的是對         connection進行事務(wù)處理。如何保證事務(wù)的一致性？
想到的解決方案一：使用jta事務(wù)，用tomcat+jotm提供事務(wù)管理器。為什么一開始就想到要使用jta事務(wù)？？實際上我們和客戶都是使用的同一個數(shù)據(jù)庫，為了方便，各自使用了不同的數(shù)據(jù)庫連接方式，使用jta的話確實有bt的意思在里面。但是事實上是我們的第一反應(yīng)都是jta。最后沒有采用該方法的原因也很簡單：我沒有將jotm配置成功！汗一個。
想到的解決方案二：將客戶的這些特定代碼用spring管理起來。因為要修改客戶部分代碼，這個方案遭到了客戶的強烈反對。于是放棄。
想到的解決方案三：客戶數(shù)據(jù)庫操作與我們的服務(wù)使用同一個數(shù)據(jù)庫連接。然后編程處理事務(wù)。存在兩種方式：一種是把客戶的連接傳給我們，另一種則是把我們的連接傳給客戶。第一種方式對我們的影響太大，所以最后決定采用后一種方式：從hibernate session中獲取connection然后傳遞給客戶。接下來查看一下HibernateTemplate的execute()方法，思路就很簡單了：獲取定義的sessionFactory-->創(chuàng)建一個新的session并打開-->將session與當前線程綁定-->給客戶代碼返回connection-->打開事務(wù)-->客戶使用我們傳遞的connection進行數(shù)據(jù)庫操作-->我們不帶聲明事務(wù)的服務(wù)操作-->提交事務(wù)-->解除綁定。
實際要注意的地方是：1、將session與當前線程綁定使用的TransactionSynchronizationManager.bindResource()方法，這樣在HibernateTemplate里才能找到session；
                    2、我們的服務(wù)一定要把聲明式事務(wù)徹底干掉，否則會有commit;
                    3、我們服務(wù)調(diào)用完畢后一定要flush session，否則客戶代碼不會感知數(shù)據(jù)庫里的數(shù)據(jù)變化。
最終解決：使用了spring里常用的模板和回調(diào)。代碼如下：

調(diào)用偽代碼：


基于職責設(shè)計對象
最關(guān)鍵的軟件開發(fā)工具是受過良好設(shè)計原則訓(xùn)練的思維，而不是UML或其他任何技術(shù)。

RDD是思考OO軟件設(shè)計的一般性隱喻。把軟件對象想象成具有某種職責的人，他要與其他人協(xié)作以完成工作。RDD使我們把OO設(shè)計看作是有職責對象進行協(xié)作的共同體。

分配職責的基本模式是GRASP。

創(chuàng)建者模式
  問題：誰創(chuàng)建類A的實例？
  建議：如果以下條件為真時（越多越好），將創(chuàng)建類A實例的職責分配給類B：
        1、B“包含”或組成聚集了A。
        2、B記錄A。
        3、B緊密的使用A。
        4、B具有A的初始化數(shù)據(jù)。
        首選聚集或包含A的類B。
  注意：A和B指的都是軟件對象而不是領(lǐng)域模型對象。
  禁忌：對象的創(chuàng)建常常具有相當?shù)膹?fù)雜性。在一些情況下，更適合使用工廠。

信息專家模式
  問題：給對象分配職責的基本原則是什么？
  建議：把職責分配給具有完成該職責所需信息的那個類。把職責和數(shù)據(jù)置于一處，把服務(wù)與其屬性置于一處。
  禁忌：相比較而言系統(tǒng)關(guān)注更為重要，設(shè)計要分離主要的系統(tǒng)關(guān)注。例如：領(lǐng)域?qū)ο蠹尤氤志没壿嫵蔀槌溲Ｐ停@就把應(yīng)用邏輯與數(shù)據(jù)庫邏輯混合起來了（不良設(shè)計）。

低耦合模式
  問題：如何減少因變化產(chǎn)生的影響？（高耦合并不是問題所在，問題是與某些方面不穩(wěn)定的元素之間的高耦合）
  建議：分配職責以使（不必要的）耦合保持在較低的水平。（信息專家模式支持低耦合）

控制器模式
  問題：在UI層之上首先接受和協(xié)調(diào)系統(tǒng)操作的對象是什么？
  建議：把職責分配給能代表下列選擇之一的對象：
        1、代表全部“系統(tǒng)”、“根對象”、運行軟件的設(shè)備或主要的子系統(tǒng)（外觀控制器的變體）。
        2、代表發(fā)送系統(tǒng)操作的用例場景（用例或會話控制器）。

高內(nèi)聚模式
  問題：怎樣使對象保持有內(nèi)聚、可理解和可管理，同時具有支持低耦合的附加作用？
  建議：職責分配應(yīng)保持高內(nèi)聚。委派職責。內(nèi)聚性低的類通常表示大粒度的抽象，或承擔了本該委托給其他對象的職責。

多態(tài)模式
  問題：如何處理基于類型的選擇？如何創(chuàng)建可插拔的軟件構(gòu)件？
  建議：當相關(guān)選擇或行為隨類型（類）有所不同時，使用多態(tài)為變化的行為類型分配職責。不要測試對象的類型，也不要使用條件邏輯來執(zhí)行基于類型的不同選擇。
  經(jīng)驗：如果有一個具有抽象超類C1的類層次結(jié)構(gòu)，可以考慮對應(yīng)于C1中的公共方法特征標記來定義接口I1，然后聲明C1來實現(xiàn)接口I1。

純虛構(gòu)模式
  問題：當并不想違背高內(nèi)聚和低耦合或其他目標，但基于專家模式的方案又不合適時，哪些對象應(yīng)承擔這一職責？
  建議：人為制造類，由該類來承擔一組高內(nèi)聚的職責。該類并不代表問題領(lǐng)域的概念-是虛構(gòu)的事物。例如DAO
  純虛構(gòu)通?；谙嚓P(guān)的功能性進行劃分，因此這是一種以功能為中心的對象。

間接性模式
  問題：為了避免兩個或多個事物之間的直接耦合，應(yīng)該如何分配職責？
  建議：將職責分配給中介對象。例如，Adapter
  間接性的動機通常是為了低耦合，并且大多數(shù)間接性中介都是純虛構(gòu)的。

防止變異模式
  問題：如何設(shè)計對象、子系統(tǒng)和系統(tǒng)，使其內(nèi)部的變化或不穩(wěn)定性不會對其他元素產(chǎn)生不良影響？
  建議：創(chuàng)建穩(wěn)定的接口。
  不要和陌生人講話：約束了應(yīng)該在方法里給哪些對象發(fā)送消息。它要求在方法里，只應(yīng)給以下對象發(fā)送消息：
  1、this對象（自身）
  2、方法的參數(shù)
  3、this的屬性
  4、作為this屬性的集合中的元素
  5、在方法中創(chuàng)建的對象
  典型違反該原則的例子： F f=foo.getA().getB().getC().getD().getE().getF();

命令-查詢分離原則：
  執(zhí)行動作（更新、調(diào)整，等等）的命令方法，這種方法通常具有改變對象狀態(tài)等副作用，并且是void的（沒有返回值）。
  向調(diào)用者返回數(shù)據(jù)的查詢，這種方法沒有副作用，不會永久性地改變?nèi)魏螌ο蟮臓顟B(tài)。
關(guān)鍵在于：一個方法不應(yīng)該同時屬于以上兩種類型。
 
在繪制交互圖時考慮和決定職責分配。然后在類圖的方法分欄里概括職責分配結(jié)果，方法是職責的具體實現(xiàn)。
在迭代開發(fā)中，我們并非一次就實現(xiàn)所有需求。

在多個迭代里對同一用例進行增量式開發(fā)。

細化階段：構(gòu)建核心架構(gòu)，解決高風險元素，定義大部分需求，以及預(yù)計總體進度和資源。（包括了三到四次的細化迭代）
關(guān)鍵思想和最佳實踐：
 實行短時間定量、風險驅(qū)動的迭代
 及早開始編程
 對架構(gòu)的核心和風險部分進行適應(yīng)性設(shè)計、實現(xiàn)和測試
 盡早、頻繁、實際的測試
 基于來自測試、用戶、開發(fā)者的反饋進行調(diào)整
 通過一系列討論會，詳細編寫大部分用例和其他需求，每個細化迭代進行一次
制品：領(lǐng)域模型、設(shè)計模型、軟件架構(gòu)文檔、數(shù)據(jù)模型、用例、用戶界面原型。

領(lǐng)域模型
領(lǐng)域模型是對領(lǐng)域內(nèi)的概念類或現(xiàn)實世界中對象的可視化表示。
應(yīng)用UML表示法，領(lǐng)域模型被描述為一組沒有定義操作的類圖，反映屬性和關(guān)聯(lián)。（一定注意，它不是軟件對象！是概念對象?。?br /> 準則：
  使用領(lǐng)域術(shù)語
  認真汲取領(lǐng)域?qū)＜宜褂玫暮诵脑~匯和概念
  如果某概念類不是現(xiàn)實世界中的數(shù)字或文本，那么她可能是概念類而不是屬性
  需要描述類：1、需要有關(guān)商品或服務(wù)的描述，獨立于任何商品或服務(wù)的現(xiàn)有實例；2、減少冗余或重復(fù)信                 息
  避免加入大量關(guān)聯(lián)，添加關(guān)聯(lián)是為了突出對重要關(guān)系的大致理解，而非記錄對象或數(shù)據(jù)的結(jié)構(gòu)
  通過關(guān)聯(lián)而不是屬性來表示概念類之間的關(guān)系，領(lǐng)域模型中屬性的類型應(yīng)該是數(shù)據(jù)類型（基本類型）
  對數(shù)量和單位建模
每次迭代的領(lǐng)域建模不超過幾個小時。

系統(tǒng)順序圖
系統(tǒng)順序圖（SSD）是為闡述與所討論系統(tǒng)相關(guān)的輸入和輸出事件而快速、簡單地創(chuàng)建的制品。是操作契約和對象設(shè)計的輸入。
SSD展示了直接與系統(tǒng)交互的外部參與者、系統(tǒng)（作為黑盒）以及由參與者發(fā)起的系統(tǒng)事件。這些事件是通過用例文本總結(jié)出來的。
應(yīng)為每一個用例的主成功場景，以及頻繁發(fā)生的或者復(fù)雜的替代場景繪制SSD。
基本上軟件系統(tǒng)要對三種事件進行響應(yīng)：來自于參與者的外部事件，時間事件，錯誤和異常（通常源于外部）。
系統(tǒng)事件應(yīng)該在意圖的抽象級別而非物理的輸入設(shè)備級別來表達。

操作契約
操作契約使用前置和后置條件的形式，描述領(lǐng)域模型里對象的詳細變化。其中的關(guān)鍵元素是后置條件。
為系統(tǒng)操作定義操作契約。系統(tǒng)操作在繪制SSD草圖時確定。
后置條件描述了領(lǐng)域模型內(nèi)對象狀態(tài)的變化?？煞譃槿N類型：創(chuàng)建或刪除實例，屬性值的變化，形成和消除關(guān)聯(lián)。注意，它描述的是所需的變化，而不是這些變化是如何完成的。以說明性的、被動式的過去時態(tài)編寫后置條件。（例如，創(chuàng)建了xx，而不是創(chuàng)建xx）

邏輯架構(gòu)和UML包圖
邏輯架構(gòu)是軟件類的宏觀組織結(jié)構(gòu)，它將軟件類組織為包（或命名空間）、子系統(tǒng)和層等。
UML包圖常用于描述系統(tǒng)的邏輯架構(gòu)--層、子系統(tǒng)、包等。
將系統(tǒng)的大型邏輯結(jié)構(gòu)組織為獨立的、職責相關(guān)的離散層，具有清晰、內(nèi)聚的關(guān)注分離。
協(xié)作和耦合是從較高層到較低層進行的，要避免從較低層到較高層的耦合。較低層包含可復(fù)用功能。
可以將應(yīng)用邏輯層更準確地稱為架構(gòu)的領(lǐng)域?qū)樱窗I(lǐng)域?qū)ο螅ㄗ⒁忸I(lǐng)域模型與領(lǐng)域?qū)ο笫遣煌膬蓚€概念），處理應(yīng)用邏輯的層。
領(lǐng)域?qū)邮擒浖囊徊糠郑I(lǐng)域模型是概念角度分析的一部分。
從UI層發(fā)送到領(lǐng)域?qū)拥南⑹荢SD中所描述的消息。

輕量級繪圖然后編碼。