劉磊 周業林 楊小兵
摘要:模型驅動架構(Model Driven Architecture,MDA)是一種先進、系統、高效的軟件開發方法。然而掌握MDA模型轉換和實現完整代碼生成,具有一定的難度。在研究元建模技術的基礎上,對領域建模語言(Domain Specific Language,DSL)與元建模相結合的開發方法進行了探索,該方法基于MDA以模型為中心的思想,能快速通過模型轉換實現完整代碼的生成,易用性提高。結合Web應用系統這個領域,利用領域型元建模工具MetaEdit+,以學生健康信息收集系統的開發為例,驗證了領域元建模開發方式在解決領域問題上的可行性。
關鍵詞:模型驅動;模型轉化;代碼生成;領域語言;元建模;建模工具
中圖分類號:TP31文獻標志碼:A文章編號:1008-1739(2023)01-54-5

當今社會,人們的工作生活更加依賴各類信息系統提供的便利化管理和服務,各行業軟件開發需求大量增長。傳統的開發方式以編寫代碼為核心,存在文檔和代碼容易脫節、系統平臺轉換麻煩以及投入人力、物力高的問題。2001年,國際對象管理組織提出了模型驅動架構(Model Driven Architecture, MDA)的方法[1],以模型為中心,通過模型轉換,自動生成程序代碼,這樣的方式可以有效地解決傳統開發方式存在的文檔和代碼不能統一的問題。然而隨著時間的推移,MDA的開發方式并沒有大規模得到應用和推廣。而以建立建模語言的元建模技術卻正在逐漸興起,元建模技術是一種輕量化的MDA,在元建模工具的支持下,能高效地實現形式化建模和完整的代碼轉化。針對不同的問題領域,領域建模語言與元建模技術相結合可以更好地針對問題本身,解決問題,滿足用戶的需求,并實現代碼自動生成。
MDA沒有廣泛地推廣和應用,綜合分析主要有2方面原因:一是模型轉換復雜,不易于掌握和使用。模型轉換是MDA開發方法的核心。模型轉換是通過模型轉換工具,按照定義的轉換規則,將源模型轉換成為目標模型的過程。隨著模型轉換開發工具的推出和改進,模型轉換逐漸得到了應用。然而,模型轉換并不像人們想象的那樣容易。模型之間的轉換就分好幾種類型,包括PIMtoPIM,PIMtoPSM,PSMtoPSM,PSMtoPIM和PSMtoCode等,其中模型轉換的技術也有很多種,很抽象,采用的技術路線不容易理解,比如:QVT轉換方法、基于圖文法的轉換和基于結構的轉換等[2],一般的開發人員很難掌握。二是支持MDA的工具軟件還不完善。MDA中最常用的建模工具UML,體系龐大復雜,支持UML的MDA工具有Rational Rose,Enterprise Architect,IBM Rational Software Architec,Powerdesigner,Trufun等,只能生成部分代碼或是程序框架[3],常規的操作都被包含在實體模型中,但是對于業務邏輯的操作,只產生空的方法體[4],與生成完整應用系統還有相當的差距,這也制約了MDA真正投入到日常的軟件開發過程,國產支持MDA的工具軟件更是寥寥無幾。
要理解元建模首先要了解元模型。模型是對現實世界事物的一種抽象和概括,元模型是定義模型的模型,它是對模型的構成進行更高層次的抽象,元模型的構成還可以繼續抽象,抽象形成的模型稱為元元模型,從理論上說,抽象還可以繼續延伸深化,但抽象到了一定的層次已經可以解決建模的問題了,過度的深入沒有太大的現實意義。OMG專門為模型的實現和抽象制定了核心標準即元對象機制(Meta-Object Facility,MOF)[5],其結構如圖1所示。

MOF是一個4層模型,從下到上是逐漸抽象的過程是逐漸實現的過程,也是模型轉換的過程。M0層的對象是M1層對象的實例,M1層對象是M2層對象的實例,M2層對象是M3層對象的實例,這里的實例是相對于上一層模型而言,并不完全都是實現,只有M0層是具體的事物。MOF位于M3層,是最高層次的抽象,MOF可以自己構造自己,自己描述自己。常見的用UML建立的模型屬于M1層,UML的元模型屬于M2層。同樣,用DSL建立的模型屬于M1層,而DSL元模型屬于M2層。本文研究的元建模是指處于M2層的DSL元模型。
元建模指的是建立一種帶語義描述建模語言的元模型[5],需要有支持相關建模語言的工具。通過這個工具來設計、呈現這個元模型。
3.1建模語言
軟件開發是為了解決問題,問題是有領域的,因此,軟件開發也面臨問題領域。對于建模語言來說,相應可以按照適用范圍,分為通用語言(General Purpose Language,GPL)和領域語言(Domain Specific Language,DSL)。GPL常見的有UML,C和Python等語言,優點是適用面廣,缺點是太通用、不聚焦,不能很好地表達一些具體問題。UML作為一種通用建模語言,支持其建模的工具是最多的,然而UML過于通用和復雜,從UML模型生成完整的應用系統是很困難的,其包含大部分抽象概念,不是來自于問題域的抽象,導致UML中描述的模型與問題域存在一定的差異。DSL常見的有HTML,SQL和MERL等,優點在于貼近問題域,對于領域設計人員而言,領域建模語言學習起來更容易,從領域模型生成程序相對容易。根據資料顯示,基于元建模的領域建模要比基于UML的效率高出10倍[5]。元建模開發示意如圖2所示。

3.2建模工具
元建模除了建模的理論,還需要有強大的工具軟件來整合配置元元模型、模型,并實現模型到相關平臺代碼的自動生成。因此元建模工具是非常關鍵的。現在出現了不少元建模工具,常見的有GME,EMF,Visual Studio DSL,GMF和MetaEdit+等。EMF是Eclipse的一項全新的建模框架,該框架允許代碼自動生成,支持模型和元數據管理,可高效完成模型轉換,生成的模型可轉換為Java代碼,在現有工具中具有強大的生命力[6]。Visual Studio DSL是Windows平臺下的圖形化工具,包括元建模環境和代碼生成,除了提供模型與圖形之間的支持,還提供了對模型的驗證、規則和事務的支持[7]。GME是美國范德比特大學研發的一款元建模工具,其元模型是建立在UML基礎上,并利用關系數據庫來存儲[8]。GMF提供了圖形化的開發環境和基本的框架,設計人員可在圖形環境中定制自己的領域模型,并自動生成代碼框架[9]。MetaEdit+具有專屬的元建模語言和生成器定義語言,不需要依賴UML的模型,具有靈活的DSL定義功能,不需要手工編寫代碼,代碼生成器具備強有力的代碼生成功能[10]。MetaEdit+可以快速設計建模語言而且成本低廉,適用于信息系統的開發,工具的幫助文檔內容十分友好,方便進行學習和使用。
3.3建模框架
元建模框架是元建模的開發的模式和架構,發展到現在,元建模框架結構主要有2種類型[11]:
①基于通用建模工具的元建模
這是最常用的一種架構,以通用建模工具為核心。開發人員使用通用建模工具建立某個領域的元模型;用元模型來對通用建模工具做配置,使通用建模工具成為支持該元模型的建模工具,通過配置過的建模工具來生成應用的源代碼。其優點是支持多種元模型進行配置,從而支持多種建模語言。這類元建模工具有MetaEdit+,GME等。
②基于專用建模工具的元建模
定制生成一個專用的建模工具,通過這個建模工具來生成應用的源代碼。這種建模方式的優點是建模工具是定制、對建模的支持更好,缺點是使用難度較大,采用這種架構的元建模工具主要有EMF和GMF。
通過元建模工具及架構的比較,由于MetaEdit+具有功能全面、適用于信息系統開發,使用相對容易,且有良好的文檔支持、能快速建模的特點,因此,選擇MetaEdit+作為研究領域元建模開發的建模工具。
為了領域建模語言+元建模能實現基于MDA的元建模架構開發,并最終生成系統代碼,將通過一個簡單的學生健康收集系統“InfoCollecting”開發過程進行驗證。近2年來,加強新冠肺炎防控,保護人民群眾生命安全成了日常的一件重大事情。對于學校來說,校園疫情防控壓力很大,除了定期開展核酸檢測篩查以外,還必須加強學生日常健康申報管理,“InfoCollecting”系統就是以此為背景設計。系統有2類活動參與者,并且他們對系統具有以下幾種操作。
①學生(注冊系統、登錄系統、健康登記、查詢登記信息、修改密碼和退出系統)。
②管理員(登錄系統、更改密碼、查詢登記信息、管理登記信息和退出系統)。
4.1系統設計模式
InfoCollecting系統主要考慮采用B/S結構,系統設計模式使用Model-View-Controller,Model層代表業務邏輯層最終通過JavaBeans來實現,讀寫數據庫,View層代表交互界面層最終通過JSP來生成、提交和響應用戶請求,Controller層代表控制器層,負責View層和Model層之間的銜接。
4.2MetaEdit+元建模的主要步驟
MetaEdit+以GOPPRR作為元建模語言,主要包含6種元素,分別是Graph(圖)、Object(對象)、Property(屬性)、Por(端口)、Relationship(聯系)和Role(角色)[11]。Graph指一種由對象及其聯系組成的圖形;Object指一種事物,用一種圖形符號來表示;Property指其他5種元素所具有的特點描述;Port指角色連接對象的一個特定位置;Relationship指對象之間的連接關系;Role定義了對象如何參與到一個聯系中,如圖3所示。

MetaEdit+元建模的主要步驟如下:
步驟1利用GOPPRR元元模型,設計系統元模型
元模型的建立是將應用系統涉及的對象領域概念、數據庫概念的內容及它們之間關聯抽象成為Objects,Relationships,Roles,Property和Port等元元模型,在通過這些元元模型來描述應用系統,建立Graph圖形元模型。在MetaEdit+中使用Graph Tool工具來建立圖形元模型。圖4給出了“InfoCollecting”部分的系統元模型。Graph Tool可以根據抽象的模型元素創建圖所需的各種對象、聯系、角色以及其之間的綁定關系,圖形還可以包含子圖形和各種約束條件。
