軟件需求包括三個(gè)不同的層次：業(yè)務(wù)需求，用戶(hù)需求和功能需求（也包括非功能需求）。售前人員用PowerPoint和Word編寫(xiě)客戶(hù)的業(yè)務(wù)需求，為客戶(hù)編寫(xiě)藍圖；項目經(jīng)理則用Word編寫(xiě)用戶(hù)需求規格說(shuō)明書(shū)；而系統架構師又會(huì )采用UML 等另外一套建模技術(shù)對用戶(hù)需求進(jìn)行系統分析和設計。
除此之外，出于種種原因，客戶(hù)的需求幾乎肯定是要頻繁發(fā)生變化的，哪怕是簽了板上釘釘的合同，實(shí)施一個(gè)軟件項目不可能總是陷入到PPT或者是Word文檔的修改當中。如果有一個(gè)建模工具，能夠由這幾類(lèi)人員統一使用，而且隨著(zhù)客戶(hù)需求變化，多個(gè)模型之間也可以相互轉化，再加上結合MDA/MDD 思想，這個(gè)工具能夠自動(dòng)生成一些能夠減少程序員重復勞動(dòng)的代碼，那將能夠極大提高軟件開(kāi)發(fā)企業(yè)的開(kāi)發(fā)效率，使得應用軟件做到真正“隨需應變”。這恐怕也是軟件公司夢(mèng)寐以求的“銀彈”。
但是，即使是UML創(chuàng )始人之一的James Rumbaugh 也說(shuō)UML在對業(yè)務(wù)的描述上確實(shí)是有缺陷的，這些缺陷源于它并非為描述業(yè)務(wù)而設計。但是，通過(guò)引UML的擴展機制和UML2變化最大的Activity Modeling，還是為業(yè)務(wù)建模和多種模型之間的相互轉化帶來(lái)了一絲曙光。
本文重點(diǎn)在于講述如何用UML2和GEF/EMF實(shí)現這個(gè)捕獲企業(yè)需求的建模工具上，而不是講述如何用UML2進(jìn)行企業(yè)建模，所以本文的重點(diǎn)將放在UML2元模型和GEF/EMF具體技術(shù)上，用UML2作為理論依據把企業(yè)業(yè)務(wù)需求和他們整合在一起，以實(shí)現模型驅動(dòng)思想的開(kāi)發(fā)。我們用UML2的Activity Model作為我們例子的元模型，EMF作為具體實(shí)現模型，GEF作為我們的表示層，這就是UML2、EMF和GEF三者之間的關(guān)系。
這是一個(gè)很簡(jiǎn)單的采購審批流程，采購員提出采購申請，錄入采購申請單（輸出采購申請單），采購部門(mén)處長(cháng)、部長(cháng)或者具有采購審批權限的審批人，對采購申請單進(jìn)行審批（輸出是采購訂單）。審批通過(guò)，則采購申請單自動(dòng)生成采購訂單，審批不通過(guò)，則退回采購員，采購員修改原采購申請單，重新提交。
下面采用UML2和GEF/EMF實(shí)現這個(gè)業(yè)務(wù)建模工具（而不是一個(gè)用來(lái)畫(huà)工作流的工具）。
企業(yè)建模有很多建模方法，如：ARIS 、IDEF 和 UML。為了使業(yè)務(wù)模型能夠更好的轉化為信息系統分析模型，所以我們采用面向對象UML技術(shù)來(lái)描述一個(gè)業(yè)務(wù)。
下面將結合UML2的Activity Model來(lái)解釋上述業(yè)務(wù)建模流程?；顒?dòng)圖是UML所有圖中變化最大的一種。UML 1.5 版本從早期版本中繼承了狀態(tài)機的概念，并將其改進(jìn)為流程圖，稱(chēng)之為活動(dòng)圖。令人遺憾的是 ，狀態(tài)機的潛在含義限制了其明確意圖，這使得用戶(hù)感到很困惑。特別是那些沒(méi)有面向對象概念的用戶(hù)更對UML 1.x 的活動(dòng)模型無(wú)所適從。類(lèi)似的情形還涉及到UML 1.5 中包含的那些控制流和數據流模型?；谝陨线@些經(jīng)驗，UML2重新定義了Activity Model，并且和UML1.5的Action Model整合在一起?；顒?dòng)圖的目的也發(fā)生了相當大的變化，它本來(lái)用于描述工作流程，現在它也包含一些必須的新特性使得它可以支持工作流程的自動(dòng)化(automation)。原來(lái)的活動(dòng)概念(Activities），改稱(chēng)動(dòng)作（Action）?；顒?dòng)成了一個(gè)更高層次的概念，它包含一個(gè)動(dòng)作序列。因此一個(gè)活動(dòng)圖展現了一系列的動(dòng)作，這些動(dòng)作一起組成了活動(dòng)。
從圖3中我們可以看到，Basic Activities的繼承分支有兩個(gè)方向，主要的一個(gè)是Structured Activities，用于軟件建模(對應的類(lèi)名是Action)，另外的一個(gè)分支（Intermediate and Complete Activities）則用于一般過(guò)程建模。
UML2 活動(dòng)(Activity)中包含有由邊連接起來(lái)的組成完整流程圖的節點(diǎn)(Node)。一個(gè)Activity可以包含多個(gè)Action。Activity的結點(diǎn)（Node）分為三大類(lèi)：動(dòng)作結點(diǎn)(Action Node)、控制結點(diǎn)(Control Node) 和 對象結點(diǎn)(Object Node)。動(dòng)作結點(diǎn)主要是處理它接收到的控制流和數據值，或者提供這些動(dòng)作和數據給其他動(dòng)作；控制結點(diǎn)主要是路由控制流和數據值（比如判斷框）；對象結點(diǎn)主要用于存儲臨時(shí)數據，在編程方面，就是一個(gè)方法的參數對象。
我們再來(lái)看看采購訂單流程業(yè)務(wù)模型中所涉及到的幾個(gè)概念：
1、業(yè)務(wù)員/采購審批人員：在業(yè)務(wù)建模中我們稱(chēng)為業(yè)務(wù)角色（business worker）。業(yè)務(wù)角色是在業(yè)務(wù)中發(fā)揮作用的人的抽象，完成特定的工作，操縱業(yè)務(wù)實(shí)體，和其他業(yè)務(wù)角色交互。
2、采購申請單/采購訂單：在業(yè)務(wù)建模中我們稱(chēng)之為業(yè)務(wù)實(shí)體（Business Entity）。在業(yè)務(wù)模型中，業(yè)務(wù)實(shí)體代表業(yè)務(wù)角色處理或使用的“事物”（A business entity represents a "thing" handled or used by business workers.）。航空公司今天打折，明天又不打，還有明折、暗折?？墒菣C票從來(lái)沒(méi)見(jiàn)有什么大的變化，從來(lái)也只有那幾樣屬性：價(jià)格、航班、出發(fā)地、目的地。所以業(yè)務(wù)實(shí)體是比較穩定的。一般而言，一個(gè)好的業(yè)務(wù)實(shí)體不包含關(guān)于其使用主體和使用方法的信息(RUP)。在UML2中，它與Activity Model的Object Node相對應。在實(shí)際軟件建模的時(shí)候，Business Entity對應著(zhù)域模型(Domain Model)。
3、輸入采購申請單/審批采購申請單：對應UML2 Activity Model中的Action；
4、判斷框：對應UML2 Activity Model中Control Node之一的Decision；
5、控制流和信息流：對應UML2的Control Flow和Information Flow。
整個(gè)一個(gè)采購流程則對應UML2一個(gè)Activity。
我們利用Eclipse插件eclipseuml (http://www.omondo.com/download/index.html)對上述業(yè)務(wù)模型所涉及到的business worker 、Action、Business Entity、Decision、Control Flow和Information Flow等元素進(jìn)行EMF建模。
我們用Element作為Business Worker 、Action、Business Entity、Decision的基類(lèi)。抽出這些元素在圖形中所共有的height、name、caption、width、x坐標、y坐標等基本信息。其中，Condition類(lèi)表示Decision，Activity類(lèi) 表示Action, Business Worker 類(lèi)表示業(yè)務(wù)模型中的Business Worker，Business Entity類(lèi)表示表示業(yè)務(wù)模型中的Business Entity,。對于Connection、Node、Diagram、Point、Dimension等類(lèi)，它們是由于創(chuàng )建GEF應用程序所需要的輔助類(lèi)。由于我們是在探討如何對業(yè)務(wù)模型、軟件模型統一建模，采用UML2作為我們的建模理論基礎，如果要完善這個(gè)系統，這將是一個(gè)非常浩大的工作，所以我們并未嚴格按照UML2的Action的定義來(lái)對Action建模，比如在UML2中，Action有輸入、輸出，叫Pin,輸入叫InputPin, 輸出叫OutputPin。Pin 是一種 object node,在流中用于存儲臨時(shí)數據.
當我們用eclipseuml，創(chuàng )建EMF Class Diagram的時(shí)候，eclipseuml會(huì )為我們自動(dòng)生成.ecd 、model.ecore和 .genmodel 三個(gè)文件。我們建好自己的EMF模型以后，就可以用.genmodel自動(dòng)生成Model對應的Java代碼了。
有了EMF模型，我們既可以利用EMF的代碼生成工具得到一個(gè)可用編輯器（有興趣的可以參照Merlin開(kāi)源項目 http://sourceforge.net/projects/merlingenerator/ ）,也可以自己編寫(xiě)一個(gè)GEF編輯器，讓GEF利用EMF構造的模型。GEF的設計沒(méi)有對模型部分做任何限制，也就是說(shuō)，我們可以任意構造自己的模型，唯一須要保證的就是模型具有某種消息機制，以便在發(fā)生變化時(shí)能夠通知GEF（通過(guò)EditPart）。這里我們用后一種方法作為自己的例子。
步驟一：生成我們自己的業(yè)務(wù)建模視圖：
我們在plugin.xml文件里面加入：
<extension point="org.eclipse.ui.perspectives">
<perspective name="業(yè)務(wù)建模" class="org.bizsolution.jetblue.ui.perspective.ui.BusinessModelingPerspective"
id="org.bizsolution.jetblue.ui.perspective.BusinessModelPerspective"
icon="icons/bus_lvl_model_pers.gif">
</perspective>
<perspective
name="設計建模"
class="org.bizsolution.jetblue.perspective.ui.DesignModelingPerspective"
id="org.bizsolution.jetblue.perspective.ui.DesignModelPerspective"
icon="icons/bus_lvl_model_pers.gif">
</perspective>
</extension>
步驟二：生成自己的TreeView：
<extension point="org.eclipse.ui.views">
<view name="業(yè)務(wù)建模" icon="icons/buslvlmodelnav.gif" class="org.bizsolution.jetblue.ui.views.businessmodeling.view.NavigationTreeEditorView"
id="org.bizsolution.jetblue.ui.views.businessmodeling.view.NavigationTreeEditorView" />
</extension>
步驟三：生成自己的GEF編輯器：
<extension point="org.eclipse.ui.editors">
<editor class="org.bizsolution.jetblue.ui.BlueBirtEditor"
contributorClass="org.bizsolution.jetblue.ui.JetBlueEditorActionBarContributor"
default="true"
extensions="jbm"
icon="icons/shapes.gif"
id="org.bizsolution.jetblue.ui.BlueBirtEditor"
name="Business Model"/>
</extension>
步驟四：當模型用EMF實(shí)現，EditPart應實(shí)現org.eclipse.emf.common.notify.Adapter接口，因為EMF的每個(gè)模型對象都是Notifier，它維護了一個(gè)Adapter列表，可以把Adapter作為監聽(tīng)器加入到模型的這個(gè)列表中。
public void notifyChanged(Notification notification) {
int type = notification.getEventType();
int featureId = notification.getFeatureID(ModelPackage.class);
if (type == Notification.SET) {
switch (featureId) {
case ModelPackage.JET_BLUE_ELEMENT__X:
case ModelPackage.JET_BLUE_ELEMENT__Y:
case ModelPackage.JET_BLUE_ELEMENT__WIDTH:
case ModelPackage.JET_BLUE_ELEMENT__HEIGHT:
case ModelPackage.JET_BLUE_ACTIVITY__NAME:
case ModelPackage.JET_BLUE_ELEMENT__CAPTION:
refreshVisuals();
break;
}
} else if (type == Notification.ADD || type == Notification.REMOVE) {
switch (featureId) {
case ModelPackage.JET_BLUE_ELEMENT__SOURCE_CONNECTIONS:
refreshSourceConnections();
break;
case ModelPackage.JET_BLUE_ELEMENT__TARGET_CONNECTIONS:
refreshTargetConnections();
break;
}
}
}
步驟五：初始化我們的Palette , 加入Business Worker 、Action、Business Entity、Decision等元素。
PaletteDrawer businessProcessDrawer = new PaletteDrawer("Business Process");
CombinedTemplateCreationEntry component = new CombinedTemplateCreationEntry ("Business Worker", "Create an Business Worker", BusinessWorker.class, new CreationFactory() {
public Object getNewObject() {
return ModelFactory.eINSTANCE.createJetBusinessWorker();
}
public Object getObjectType() {
return null;
}
},BlueBirtPlugin.getImageDescriptor("icons/swimminglanec16.gif"), BlueBirtPlugin.getImageDescriptor("icons/businessworker.gif"));
businessProcessDrawer.add(component);
….
….
這樣，我們就用GEF/EMF建立了一個(gè)企業(yè)業(yè)務(wù)需求捕獲模型的工具。
讓我們走的更遠
我們用GEF/EMF建立了一個(gè)業(yè)務(wù)需求捕獲模型工具，但是有了這個(gè)工具，距離我們的理想目標“軟件建模和業(yè)務(wù)建?；ハ噢D化”差距還是很遠的。我們可以繼續完善這個(gè)工具，繼續基于UML2的理論，創(chuàng )建類(lèi)圖，序列圖和用例圖等等。事實(shí)上，Eclipse組織也有一個(gè)開(kāi)源實(shí)現UML2的項目。有興趣的可以關(guān)注它。
客戶(hù)的需求總是在不斷的發(fā)生變化，使我們不得不考慮新一代的基于模型驅動(dòng)開(kāi)發(fā)的一些方法和技術(shù)，使得軟件的生命周期更長(cháng)一些，更客戶(hù)化一些，更可以定制一些。本文摸索性的從技術(shù)上提出業(yè)務(wù)建模和軟件建模相互轉化的一些話(huà)題，希望能夠得到大家的批評和指正。
參考資料
1、 UML 2.0 Superstructure Specification05-07-04
2、 China UML--軟件和需求的實(shí)踐（4-1）業(yè)務(wù)建模時(shí)期
聲明：該文章已發(fā)表于《程序員》2006年第五期，如要引用請注明出處。
聯(lián)系客服
