褚長勇 任栩生 孫安程

(杭州電子科技大學機械工程學院 浙江 杭州 310018)

0 引 言

在信息技術高速發(fā)展的今天，人們需要開發(fā)的系統(tǒng)日益復雜，而且牽涉到的領域也越來越廣。系統(tǒng)建模語言SysML針對系統(tǒng)工程領域中設計與建模的特點，提供了可視化、圖形化的系統(tǒng)建模支持，廣泛應用于復雜系統(tǒng)建模[1]。SysML包含九種模型視圖，側重于不同角度反映整個系統(tǒng)的結構特征。模型圖之間相互關聯(lián)，互為補充。但是現(xiàn)階段系統(tǒng)建模主要依賴于工程師的個人能力水平，不僅建模效率較低，而且也無法避免人為錯誤導致的模型錯誤、不一致等問題。

由于不同模型圖反映的模型信息存在重疊、冗余的情況，因此可以對模型信息進行擴展，加強模型之間的聯(lián)系，通過建立模型之間的映射關系實現(xiàn)模型轉(zhuǎn)換達到快速開發(fā)建模的目的。模型驅(qū)動架構MDA(Model Driven Architecture)是對象管理組織OMG(Object Management Group)于2001年提出的軟件系統(tǒng)開發(fā)方法。對MDA而言，模型不再是一種輔助工具，而是開發(fā)過程的產(chǎn)品，其核心即為模型轉(zhuǎn)換。平臺無關模型PIM(Platform Independent Model)和平臺相關模型PSM(Platform Specific Model)是MDA中用于開發(fā)工作的計算模型。MDA中PIM到PIM的轉(zhuǎn)換實際上是模型之間的增強、過濾和精化。目前MDA更多地關注在PIM到PSM的轉(zhuǎn)換上，忽視了PIM的精確性對系統(tǒng)需求的影響。因此，為了實現(xiàn)快速、精確建立系統(tǒng)的SysML模型，提出一種基于UML Profile通用擴展機制的模型轉(zhuǎn)換方法：根據(jù)模型之間的關聯(lián)關系，分別定義SysML需求圖及用例圖的模型擴展版型(Stereotype)，通過元模型間的映射方法實現(xiàn)SysML需求圖到用例圖、用例圖到序列圖的轉(zhuǎn)換。

1 國內(nèi)外研究現(xiàn)狀

文獻[2]提出一種模型映射的九元組，并給出序列圖到狀態(tài)圖轉(zhuǎn)換的形式化定義，但該方法沒有實現(xiàn)模型的自動生成，需要分段分析并進行整合。文獻[3]采用規(guī)范化的描述語言，設計了一種用例圖到序列圖的半自動轉(zhuǎn)換方法，但這種方法不但在描述語言中抽取信息時存在混淆錯誤的情況，還需額外設計模型圖中元素的格局布置，準確度和自由度較低。文獻[4]給出一種遞歸對象模型(ROM)到SysML模型的轉(zhuǎn)換方法，通過分析系統(tǒng)需求設計其ROM模型，ROM模型實際上也是規(guī)范化描述語言的圖形化表示，通過分析ROM模型元素間得關系實現(xiàn)ROM到SysML的模型轉(zhuǎn)換。文獻[2-4]對于建立SysML模型圖之間的映射、實現(xiàn)模型轉(zhuǎn)換給出了參考思路：通過分析模型圖的用途、元素組成，可以構建模型元素間的映射關聯(lián)，以實現(xiàn)模型轉(zhuǎn)換的目的。

文獻[5]提出以擴展需求圖為基礎，實現(xiàn)其到用例圖及狀態(tài)圖的轉(zhuǎn)換。但其擴展沒有依據(jù)SysML模型圖之間的關聯(lián)關系，只是將所有擴展信息加入需求圖中，導致需求圖過于臃腫，并且適用范圍很窄。文獻[6]采用業(yè)務流程建模標記(BPMN)方法，通過在計算無關模型(CIM)層次創(chuàng)建包含更多信息的業(yè)務模型，研究實現(xiàn)CIM到PIM的轉(zhuǎn)換，與文獻[5]類似，同樣使用擴展源模型的方式來實現(xiàn)。因此，在建立模型間映射關聯(lián)的基礎上，通過擴展源模型所包含的信息、約束、關聯(lián)關系是實現(xiàn)模型轉(zhuǎn)換、達到快速開發(fā)建模目的的有效方法。

2 模型轉(zhuǎn)換的擴展Profile設計

2.1 需求圖到用例圖的轉(zhuǎn)換

SysML需求圖是由UML類圖擴充而來，是SysML中用于溝通以文字形式記錄的系統(tǒng)需求的一種主要媒介。建模者通常會創(chuàng)建需求圖來表示需求之間的可跟蹤性，以及從需求到系統(tǒng)結構和行為的可跟蹤性,包括包含、跟蹤、繼承、改善、驗證等關系[7]。SysML用例圖可以顯示各種類型的元素和關系，說明系統(tǒng)提供的服務信息，以及需要服務的利益相關者的信息。在用例圖中通過創(chuàng)建用例描述系統(tǒng)的功能性需求，包括基礎用例、內(nèi)含用例(include)和擴展用例(extend)。因此，根據(jù)需求圖與用例圖內(nèi)容之間的關聯(lián)關系，將需求圖中的功能性需求部分通過模型轉(zhuǎn)換得到用例圖是可行的。

根據(jù)這種思想，首先需要使用UML Profile設計需求圖的擴展版型(Stereotype)，使其能夠包含用例圖中的Actor、Include以及Extend等元素，這是實現(xiàn)需求圖到用例圖轉(zhuǎn)換的基礎。如圖1所示，在功能性需求擴展版型中：TargetUseCase用于判斷該需求是否為所需的功能性需求；TargetUser表示需求所服務的使用者，同時通過枚舉的方式列出使用者；IncludedBy表示用例的內(nèi)含關系；ExtendedFrom和ExtensionPoint則表示用例之間的擴展關系。最后，將其導入到所建立的需求圖中。

圖1 需求圖的擴展Profile

2.2 用例圖到序列圖的轉(zhuǎn)換

SysML中序列圖可以表達系統(tǒng)動態(tài)行為信息，說明隨著時間推移而發(fā)生的行為和事件的序列。通過生命線元素，為系統(tǒng)行為中的參與者建模，然后使用生命線之間的消息，為參與者之間的交互建模[7]。序列圖主要包含的模型元素有：消息發(fā)送者、消息接收者以及消息序列。用例圖是用來描述系統(tǒng)功能的，從面向?qū)ο蟮慕嵌葋砜?，系統(tǒng)的功能是由一組對象通過互相發(fā)送消息來完成，而序列圖則是通過這樣的對象和信息來描述系統(tǒng)的動態(tài)行為。因此，序列圖是描述用例的事件流場景[8]。

基于用例圖與序列圖的關聯(lián)關系，同樣使用UML Profile設計用例圖的擴展版型(Stereotype)，使用例圖中每一個用例都可以完整表達其內(nèi)部的事件流，如圖2所示。首先，為了確定要進行模型轉(zhuǎn)換的目標用例，設置TargetUseCase來進行判斷，對布爾值為true的用例進行轉(zhuǎn)換操作；其次，由于序列圖中可能存在用例外部的“觸發(fā)者”通過消息激活序列圖事件流，所以設置多重性為[0,1]的Trigger作為觸發(fā)者，TMessage作為觸發(fā)消息，TReceiver作為接收消息的生命線元素表達這種情況；最后，通過發(fā)送者序列(SenderSequence)、接收者序列(ReceiverSequence)以及消息序列(MessageSequence)來表達生命線元素之間的消息交互。從縱向來看，消息的發(fā)送者、接收者和消息本身組成了一個消息傳遞的三元組，該三元組在橫向上按照從左到右的方式對消息傳遞按照時間先后進行排序，從而可以得到消息傳遞的順序。

圖2 用例圖的擴展Profile

3 基于擴展Profile模型轉(zhuǎn)換實現(xiàn)過程

3.1 ATL模型轉(zhuǎn)換語言

ATL(Atlas Transf ormation Language)[9-10]是ATLAS、INRIA&LINA和Nantes大學共同開發(fā)的一種符合OMG的QVT解決方案，它基于EMF(Eclipse模型框架)，通過EMF來描述其元模型和模型。從本質(zhì)上來說，ATL是一種描述式和命令式混合的編程語言。一方面ATL的描述式可以簡化源模型和目標模型元素之間的映射，另一方面命令式可以彌補描述式在映射關系上的不足[11]。

本文在Eclipse平臺上通過插件Papyrus分別對需求圖、需求圖擴展Profile以及用例圖擴展Profile進行建模。在此基礎上，通過在ATL插件中使用ATL模型轉(zhuǎn)換語言編寫轉(zhuǎn)換代碼來實現(xiàn)模型轉(zhuǎn)換。

3.2 需求圖到用例圖轉(zhuǎn)換的ATL規(guī)則實現(xiàn)

首先，需定義模型(Model)層面的轉(zhuǎn)換規(guī)則，由需求模型經(jīng)ATL轉(zhuǎn)換生成用例模型，作為容器為后續(xù)元素層面的模型轉(zhuǎn)換奠定基礎。規(guī)則可用如下偽代碼來描述：

if exist RequirementModel && contain Profile then

create UseCaseModel

在元素層面，將經(jīng)Profile擴展的需求圖中包含的元素分別對應轉(zhuǎn)換為用例圖中的執(zhí)行者、用例、執(zhí)行者與用例之間的關系以及用例之間的關系。在遍歷需求圖實例的基礎上，轉(zhuǎn)換規(guī)則如下：

(1) 若關鍵詞TargetUser存在，則將其包含的元素轉(zhuǎn)換為用例圖中的Actor，即執(zhí)行者；

(2) 判斷TargetUseCase設置的屬性值，若為true，將該實例轉(zhuǎn)換為用例圖中的UseCase，即用例；

(3) 若實例中TargetUser存在并且TargetUseCase為true，則在用例圖中創(chuàng)建執(zhí)行者與用例之間的關系(Association)；

(4) 若需求圖中IncludedBy存在，則將其包含的實例作為源端用例，該需求本身作為目標用例，建立用例之間的內(nèi)含關系(include)；

(5) 同理，若需求圖中ExtendedFrom存在，則將其包含的實例作為目標用例，該需求本身作為源端用例，在目標用例中創(chuàng)建對源端用例的接口ExtensionPoint，實現(xiàn)用例之間的擴展關系(extend)。

下列偽代碼描述了元素之間的對應轉(zhuǎn)換關系，將其放入模型層中實現(xiàn)需求圖到用例圖的轉(zhuǎn)換過程：

traversal instances in RequirementModel

//創(chuàng)建執(zhí)行者

if exist TargetUser then

create Actor

Actor.name=TargetUser.name

//創(chuàng)建用例

if TargetUseCase is true then

create UseCase

UseCase.name=TargetUseCase.name

//創(chuàng)建Association

if exist TargetUser && TargetUseCase is true then

create Association

Association.from=Actor

Association.to=UseCase

//創(chuàng)建內(nèi)含關系

if exist IncludedBy then

create include

include.from=UseCase[target]

include.to=UseCase[self]

//擴展關系與內(nèi)含關系類似，不再贅述

……

3.3 用例圖到序列圖轉(zhuǎn)換的ATL規(guī)則實現(xiàn)

在模型層面，與需求圖到用例圖的轉(zhuǎn)換類似，由用例模型轉(zhuǎn)換生成序列模型作為容器。與用例圖不同的是，序列圖還需在模型中創(chuàng)建一個交互(Interaction)面板，用于放置后續(xù)的模型元素。偽代碼如下：

if exist UseCaseModel && contain Profile then

create SequenceModel

create Interaction

元素層面上，需由用例包含的事件流信息轉(zhuǎn)換得到序列圖中生命線、消息序列等元素。其轉(zhuǎn)換規(guī)則設計如下：

(1) 設置布爾值屬性關鍵詞TargetUseCase，若值為true，則將該用例作為轉(zhuǎn)換時序圖的目標用例，獲取該用例所包含的事件流信息；

(2) 若用例中外部觸發(fā)者Trigger存在，將該元素轉(zhuǎn)換為序列圖中的LifeLine，即生命線元素；

(3) 用例的觸發(fā)消息中，以Trigger、TMessage以及TReceiver作為觸發(fā)消息的三元組，判斷三者的值屬性轉(zhuǎn)換得到序列圖的觸發(fā)消息；

(4) 若用例的內(nèi)部事件InternalEvent存在，將其包含的所有元素均轉(zhuǎn)換為生命線元素；

(5) 用例內(nèi)部事件之間的消息交互，同樣采用消息三元組SenderSequence、MessageSequence以及ReceiverSequence通過模型轉(zhuǎn)換得到序列圖中生命線元素之間的消息序列；

(6) 規(guī)定TMessage和MessageSequence消息交互的屬性值首位以數(shù)字序號開頭，用以判別消息交互的序列，以便模型轉(zhuǎn)換后序列圖的消息布局。

實現(xiàn)該模型轉(zhuǎn)換的偽代碼如下：

//判斷是否為目標用例

if TargetUseCase is true then

//創(chuàng)建觸發(fā)者生命線

if exist Trigger then

create LifeLine

LifeLine.name=Trigger.name

//若存在觸發(fā)者，則必定有觸發(fā)消息

//創(chuàng)建觸發(fā)消息

create LifeLine

LifeLine.name=TReceiver.name

create Message

//觸發(fā)消息必定在消息序列的首位

Message.name=“0 ”+TMessage.name

Message.from=LifeLine[Trigger]

Message.to=LifeLine[TReceiver]

//創(chuàng)建內(nèi)部事件生命線

if exist InternalEvent then

for i 0 to InternalEvent.length by 1 do

create LifeLine

LifeLine.name=InternalEvent[i].name

//創(chuàng)建內(nèi)部消息

for j 0 to MessageSequence.length by 1 do

create Message

//內(nèi)部消息序列從1開始排序

Message.name=“(j+1) ”+

MessageSequence[j].name

Message.from=SenderSequence[j].name

Message.to=ReceiverSequence[j].name

4 基于擴展Profile的模型轉(zhuǎn)換實例

本章選取電動汽車充電樁軟件控制系統(tǒng)作為案例，用以驗證上文研究的模型轉(zhuǎn)換方法可行性。首先，通過分析充電樁軟件控制系統(tǒng)的需求[12]，在Eclipse平臺下采用papyrus插件建立系統(tǒng)的需求圖，并將其擴展Profile導入，得到擴展的系統(tǒng)需求圖，如圖3、圖4所示。

圖3 需求圖導入擴展Profile

圖4 電動汽車充電樁軟件控制系統(tǒng)需求圖

同樣在Eclipse平臺下，通過ATL模型轉(zhuǎn)換插件根據(jù)轉(zhuǎn)換算法編寫轉(zhuǎn)換代碼實現(xiàn)需求圖到用例圖的模型轉(zhuǎn)換，如圖5所示。

圖5 系統(tǒng)ATL模型轉(zhuǎn)換程序界面

在執(zhí)行ATL轉(zhuǎn)換程序時配置其輸入、擴展Profile以及輸出得到電動汽車充電樁軟件控制系統(tǒng)的用例圖，如圖6、圖7所示。

圖6 系統(tǒng)ATL模型轉(zhuǎn)換程序配置信息

圖7 電動汽車充電樁軟件控制系統(tǒng)用例圖

同理，在得到的用例圖中導入其擴展Profile，根據(jù)ATL轉(zhuǎn)換規(guī)則，得到電動汽車充電樁軟件控制系統(tǒng)各個用例的序列圖。以“用戶驗證”為例，其轉(zhuǎn)換后的序列圖如圖8所示。

圖8 電動汽車充電樁軟件控制系統(tǒng)序列圖

5 結 語

針對目前系統(tǒng)開發(fā)需求復雜、領域交叉導致建模效率低、人為錯誤多等問題，本文提出一種基于擴展UML Profile的模型轉(zhuǎn)換機制。在根據(jù)系統(tǒng)需求建立SysML需求圖的基礎上，建立需求圖到用例圖以及用例圖到序列圖的擴展Profile。然后根據(jù)擴展Profile包含的系統(tǒng)信息使用ATL模型轉(zhuǎn)換語言實現(xiàn)需求圖到用例圖、用例圖到序列圖的轉(zhuǎn)換。最后，通過以電動汽車充電樁軟件控制系統(tǒng)為例，驗證了該方法的可行性。下一步，我們將研究關于序列圖消息序列排序更好的表達方式，并實現(xiàn)用例圖到序列圖中組合片段的轉(zhuǎn)換，建立更加完善的Profile擴展信息。