褚長勇 任栩生 孫安程
(杭州電子科技大學機械工程學院 浙江 杭州 310018)
在信息技術高速發展的今天,人們需要開發的系統日益復雜,而且牽涉到的領域也越來越廣。系統建模語言SysML針對系統工程領域中設計與建模的特點,提供了可視化、圖形化的系統建模支持,廣泛應用于復雜系統建模[1]。SysML包含九種模型視圖,側重于不同角度反映整個系統的結構特征。模型圖之間相互關聯,互為補充。但是現階段系統建模主要依賴于工程師的個人能力水平,不僅建模效率較低,而且也無法避免人為錯誤導致的模型錯誤、不一致等問題。
由于不同模型圖反映的模型信息存在重疊、冗余的情況,因此可以對模型信息進行擴展,加強模型之間的聯系,通過建立模型之間的映射關系實現模型轉換達到快速開發建模的目的。模型驅動架構MDA(Model Driven Architecture)是對象管理組織OMG(Object Management Group)于2001年提出的軟件系統開發方法。對MDA而言,模型不再是一種輔助工具,而是開發過程的產品,其核心即為模型轉換。平臺無關模型PIM(Platform Independent Model)和平臺相關模型PSM(Platform Specific Model)是MDA中用于開發工作的計算模型。MDA中PIM到PIM的轉換實際上是模型之間的增強、過濾和精化。目前MDA更多地關注在PIM到PSM的轉換上,忽視了PIM的精確性對系統需求的影響。因此,為了實現快速、精確建立系統的SysML模型,提出一種基于UML Profile通用擴展機制的模型轉換方法:根據模型之間的關聯關系,分別定義SysML需求圖及用例圖的模型擴展版型(Stereotype),通過元模型間的映射方法實現SysML需求圖到用例圖、用例圖到序列圖的轉換。
文獻[2]提出一種模型映射的九元組,并給出序列圖到狀態圖轉換的形式化定義,但該方法沒有實現模型的自動生成,需要分段分析并進行整合。文獻[3]采用規范化的描述語言,設計了一種用例圖到序列圖的半自動轉換方法,但這種方法不但在描述語言中抽取信息時存在混淆錯誤的情況,還需額外設計模型圖中元素的格局布置,準確度和自由度較低。文獻[4]給出一種遞歸對象模型(ROM)到SysML模型的轉換方法,通過分析系統需求設計其ROM模型,ROM模型實際上也是規范化描述語言的圖形化表示,通過分析ROM模型元素間得關系實現ROM到SysML的模型轉換。文獻[2-4]對于建立SysML模型圖之間的映射、實現模型轉換給出了參考思路:通過分析模型圖的用途、元素組成,可以構建模型元素間的映射關聯,以實現模型轉換的目的。
文獻[5]提出以擴展需求圖為基礎,實現其到用例圖及狀態圖的轉換。但其擴展沒有依據SysML模型圖之間的關聯關系,只是將所有擴展信息加入需求圖中,導致需求圖過于臃腫,并且適用范圍很窄。文獻[6]采用業務流程建模標記(BPMN)方法,通過在計算無關模型(CIM)層次創建包含更多信息的業務模型,研究實現CIM到PIM的轉換,與文獻[5]類似,同樣使用擴展源模型的方式來實現。因此,在建立模型間映射關聯的基礎上,通過擴展源模型所包含的信息、約束、關聯關系是實現模型轉換、達到快速開發建模目的的有效方法。
SysML需求圖是由UML類圖擴充而來,是SysML中用于溝通以文字形式記錄的系統需求的一種主要媒介。建模者通常會創建需求圖來表示需求之間的可跟蹤性,以及從需求到系統結構和行為的可跟蹤性,包括包含、跟蹤、繼承、改善、驗證等關系[7]。SysML用例圖可以顯示各種類型的元素和關系,說明系統提供的服務信息,以及需要服務的利益相關者的信息。在用例圖中通過創建用例描述系統的功能性需求,包括基礎用例、內含用例(include)和擴展用例(extend)。因此,根據需求圖與用例圖內容之間的關聯關系,將需求圖中的功能性需求部分通過模型轉換得到用例圖是可行的。
根據這種思想,首先需要使用UML Profile設計需求圖的擴展版型(Stereotype),使其能夠包含用例圖中的Actor、Include以及Extend等元素,這是實現需求圖到用例圖轉換的基礎。如圖1所示,在功能性需求擴展版型中:TargetUseCase用于判斷該需求是否為所需的功能性需求;TargetUser表示需求所服務的使用者,同時通過枚舉的方式列出使用者;IncludedBy表示用例的內含關系;ExtendedFrom和ExtensionPoint則表示用例之間的擴展關系。最后,將其導入到所建立的需求圖中。

圖1 需求圖的擴展Profile
SysML中序列圖可以表達系統動態行為信息,說明隨著時間推移而發生的行為和事件的序列。通過生命線元素,為系統行為中的參與者建模,然后使用生命線之間的消息,為參與者之間的交互建模[7]。序列圖主要包含的模型元素有:消息發送者、消息接收者以及消息序列。用例圖是用來描述系統功能的,從面向對象的角度來看,系統的功能是由一組對象通過互相發送消息來完成,而序列圖則是通過這樣的對象和信息來描述系統的動態行為。因此,序列圖是描述用例的事件流場景[8]。
基于用例圖與序列圖的關聯關系,同樣使用UML Profile設計用例圖的擴展版型(Stereotype),使用例圖中每一個用例都可以完整表達其內部的事件流,如圖2所示。首先,為了確定要進行模型轉換的目標用例,設置TargetUseCase來進行判斷,對布爾值為true的用例進行轉換操作;其次,由于序列圖中可能存在用例外部的“觸發者”通過消息激活序列圖事件流,所以設置多重性為[0,1]的Trigger作為觸發者,TMessage作為觸發消息,TReceiver作為接收消息的生命線元素表達這種情況;最后,通過發送者序列(SenderSequence)、接收者序列(ReceiverSequence)以及消息序列(MessageSequence)來表達生命線元素之間的消息交互。從縱向來看,消息的發送者、接收者和消息本身組成了一個消息傳遞的三元組,該三元組在橫向上按照從左到右的方式對消息傳遞按照時間先后進行排序,從而可以得到消息傳遞的順序。

圖2 用例圖的擴展Profile
ATL(Atlas Transf ormation Language)[9-10]是ATLAS、INRIA&LINA和Nantes大學共同開發的一種符合OMG的QVT解決方案,它基于EMF(Eclipse模型框架),通過EMF來描述其元模型和模型。從本質上來說,ATL是一種描述式和命令式混合的編程語言。一方面ATL的描述式可以簡化源模型和目標模型元素之間的映射,另一方面命令式可以彌補描述式在映射關系上的不足[11]。
本文在Eclipse平臺上通過插件Papyrus分別對需求圖、需求圖擴展Profile以及用例圖擴展Profile進行建模。在此基礎上,通過在ATL插件中使用ATL模型轉換語言編寫轉換代碼來實現模型轉換。
首先,需定義模型(Model)層面的轉換規則,由需求模型經ATL轉換生成用例模型,作為容器為后續元素層面的模型轉換奠定基礎。規則可用如下偽代碼來描述:
if exist RequirementModel && contain Profile then
create UseCaseModel
在元素層面,將經Profile擴展的需求圖中包含的元素分別對應轉換為用例圖中的執行者、用例、執行者與用例之間的關系以及用例之間的關系。在遍歷需求圖實例的基礎上,轉換規則如下:
(1) 若關鍵詞TargetUser存在,則將其包含的元素轉換為用例圖中的Actor,即執行者;
(2) 判斷TargetUseCase設置的屬性值,若為true,將該實例轉換為用例圖中的UseCase,即用例;
(3) 若實例中TargetUser存在并且TargetUseCase為true,則在用例圖中創建執行者與用例之間的關系(Association);
(4) 若需求圖中IncludedBy存在,則將其包含的實例作為源端用例,該需求本身作為目標用例,建立用例之間的內含關系(include);
(5) 同理,若需求圖中ExtendedFrom存在,則將其包含的實例作為目標用例,該需求本身作為源端用例,在目標用例中創建對源端用例的接口ExtensionPoint,實現用例之間的擴展關系(extend)。
下列偽代碼描述了元素之間的對應轉換關系,將其放入模型層中實現需求圖到用例圖的轉換過程:
traversal instances in RequirementModel
//創建執行者
if exist TargetUser then
create Actor
Actor.name=TargetUser.name
//創建用例
if TargetUseCase is true then
create UseCase
UseCase.name=TargetUseCase.name
//創建Association
if exist TargetUser && TargetUseCase is true then
create Association
Association.from=Actor
Association.to=UseCase
//創建內含關系
if exist IncludedBy then
create include
include.from=UseCase[target]
include.to=UseCase[self]
//擴展關系與內含關系類似,不再贅述
……
在模型層面,與需求圖到用例圖的轉換類似,由用例模型轉換生成序列模型作為容器。與用例圖不同的是,序列圖還需在模型中創建一個交互(Interaction)面板,用于放置后續的模型元素。偽代碼如下:
if exist UseCaseModel && contain Profile then
create SequenceModel
create Interaction
元素層面上,需由用例包含的事件流信息轉換得到序列圖中生命線、消息序列等元素。其轉換規則設計如下:
(1) 設置布爾值屬性關鍵詞TargetUseCase,若值為true,則將該用例作為轉換時序圖的目標用例,獲取該用例所包含的事件流信息;
(2) 若用例中外部觸發者Trigger存在,將該元素轉換為序列圖中的LifeLine,即生命線元素;
(3) 用例的觸發消息中,以Trigger、TMessage以及TReceiver作為觸發消息的三元組,判斷三者的值屬性轉換得到序列圖的觸發消息;
(4) 若用例的內部事件InternalEvent存在,將其包含的所有元素均轉換為生命線元素;
(5) 用例內部事件之間的消息交互,同樣采用消息三元組SenderSequence、MessageSequence以及ReceiverSequence通過模型轉換得到序列圖中生命線元素之間的消息序列;
(6) 規定TMessage和MessageSequence消息交互的屬性值首位以數字序號開頭,用以判別消息交互的序列,以便模型轉換后序列圖的消息布局。
實現該模型轉換的偽代碼如下:
//判斷是否為目標用例
if TargetUseCase is true then
//創建觸發者生命線
if exist Trigger then
create LifeLine
LifeLine.name=Trigger.name
//若存在觸發者,則必定有觸發消息
//創建觸發消息
create LifeLine
LifeLine.name=TReceiver.name
create Message
//觸發消息必定在消息序列的首位
Message.name=“0 ”+TMessage.name
Message.from=LifeLine[Trigger]
Message.to=LifeLine[TReceiver]
//創建內部事件生命線
if exist InternalEvent then
for i 0 to InternalEvent.length by 1 do
create LifeLine
LifeLine.name=InternalEvent[i].name
//創建內部消息
for j 0 to MessageSequence.length by 1 do
create Message
//內部消息序列從1開始排序
Message.name=“(j+1) ”+
MessageSequence[j].name
Message.from=SenderSequence[j].name
Message.to=ReceiverSequence[j].name
本章選取電動汽車充電樁軟件控制系統作為案例,用以驗證上文研究的模型轉換方法可行性。首先,通過分析充電樁軟件控制系統的需求[12],在Eclipse平臺下采用papyrus插件建立系統的需求圖,并將其擴展Profile導入,得到擴展的系統需求圖,如圖3、圖4所示。

圖3 需求圖導入擴展Profile

圖4 電動汽車充電樁軟件控制系統需求圖
同樣在Eclipse平臺下,通過ATL模型轉換插件根據轉換算法編寫轉換代碼實現需求圖到用例圖的模型轉換,如圖5所示。

圖5 系統ATL模型轉換程序界面
在執行ATL轉換程序時配置其輸入、擴展Profile以及輸出得到電動汽車充電樁軟件控制系統的用例圖,如圖6、圖7所示。

圖6 系統ATL模型轉換程序配置信息

圖7 電動汽車充電樁軟件控制系統用例圖
同理,在得到的用例圖中導入其擴展Profile,根據ATL轉換規則,得到電動汽車充電樁軟件控制系統各個用例的序列圖。以“用戶驗證”為例,其轉換后的序列圖如圖8所示。

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