叢昕　楊德仁　楊志誠

摘要摘要：MDA是以模型及其轉化為中心的軟件建模范型。軟件要處理數(shù)據(jù)庫表中存儲的數(shù)據(jù)，其數(shù)據(jù)存儲模式的設計至關重要。數(shù)據(jù)存儲模式是PSM的重要組成部分，在數(shù)據(jù)庫表模式設計方法中，傳統(tǒng)方法沒有將庫表模式設計有機地融入軟件設計過程中，或存在設計鴻溝，或實體來源具有隨意性且缺乏可追溯性?；跀U展的MDA軟件范型，探索MDA軟件范型中的數(shù)據(jù)庫表模式及其演變機制，從BM到CIM以及PIM，最后到PSM建模，詳細探索了庫表模式在這些模型中的形態(tài)及其轉化機制，該機制生成的數(shù)據(jù)庫表模式具有可追溯性。

關鍵詞關鍵詞：MDA；數(shù)據(jù)庫表模式；演變機制；數(shù)據(jù)庫設計

DOIDOI：10.11907/rjdk.161766

中圖分類號：TP302

文獻標識碼：A文章編號文章編號：16727800（2017）005001704

0引言

隨著計算機軟件技術的快速發(fā)展，對象管理組織（the Object Management Group ，OMG）提出了一種基于模型驅動開發(fā)技術的新型軟件范型，即模型驅動的軟件構架（MDA）。MDA是以模型及其轉化為中心的軟件建模范型。軟件要處理在數(shù)據(jù)庫表中存儲的數(shù)據(jù)，其數(shù)據(jù)存儲模式的設計至關重要，其表現(xiàn)形式是數(shù)據(jù)庫表模式，而目前針對數(shù)據(jù)庫表模式演變的研究非常少。本文從業(yè)務層面（Business Model，BM）建模入手，逐步完成數(shù)據(jù)庫表的模式演變。建模的最終核心內(nèi)容是生成可操作性強、利于編碼的數(shù)據(jù)庫表模式，這也一直是相關領域研究的焦點[14]。

1相關研究綜述

在MDA思想提出后，國內(nèi)外有許多研究人員致力于MDA相關理論及其技術的研究，提出了很多基于MDA的模型表示方法和模型間轉換機制。然而，這些表示方法中的數(shù)據(jù)庫表模式演變存在一些不完善之處，并且仍未形成統(tǒng)一標準。

基于視角，對象管理組織規(guī)定了MDA軟件范型的3種模型：①聚焦于系統(tǒng)環(huán)境及需求，但不涉及系統(tǒng)內(nèi)部結構與運作細節(jié)的計算獨立模型（Computation Independent Model，CIM）；②聚焦于系統(tǒng)內(nèi)部細節(jié)，但不涉及實現(xiàn)系統(tǒng)

具體平臺的平臺無關模型（Platform Independent Model，

PIM）；③聚焦于系統(tǒng)落實的特定具體平臺，但沒有規(guī)定建模技術細節(jié)的平臺相關模型（Platform SpecificModel，PSM） [5]。Kirikova 等[6]認為計算獨立模型分為人類智能信息處理過程模型和人工智能信息處理過程模型；Yamin等[7]用類圖描述平臺無關模型，但并未對類圖到平臺的相關模型進行研究；Sharifi等[8]用活動圖作為描述業(yè)務模型的表示圖形之一，未涉及數(shù)據(jù)庫表的模式演變研究。

與國外相比，國內(nèi)關于MDA的研究起步較晚，對于MDA相關理論及其建模技術的研究不夠成熟，只有少部分研究涉及到MDA建模設計，并未見對其數(shù)據(jù)庫表演變模式的研究。臺灣學者邱郁惠[5]在其著作中使用的建模流程是：定義業(yè)務流程、分析業(yè)務流程、定義系統(tǒng)范圍、分析系統(tǒng)流程、分析業(yè)務規(guī)則、定義靜態(tài)結構、定義操作及方法。其優(yōu)點是把UML與MDA的模型關聯(lián)了起來，缺點是繁雜而不合理，CIM和PIM之間的過渡有鴻溝，PSM也并非代碼；劉敏[9]進行了基于業(yè)務模型的擴展研究，李波[10]的重點是PIM到PSM的轉換機制研究，二者均沒有具體類到數(shù)據(jù)庫表模式的研究；孟志偉[11]提出，數(shù)據(jù)庫的概念結構設計是將分析得到的用戶需求抽象為概念模型的過程。即在需求分析的基礎上，設計出能夠滿足用戶需求的各種實體以及體現(xiàn)它們之間相互關系的概念結構設計模型[11]；文斌[12]對面向對象的數(shù)據(jù)庫設計方法進行了研究與探討，使用實體—關系模型方法（E-R方法）進行設計，分別通過實例進行說明，但著重點在實例的步驟和過程上；張念[13]針對傳統(tǒng)E-R模型在大型數(shù)據(jù)庫設計中的不足， 提出了一種基于UML的、以用例驅動整個研發(fā)過程的方法，此方法可以在進行系統(tǒng)分析的同時規(guī)劃數(shù)據(jù)庫， 產(chǎn)生對應的數(shù)據(jù)庫表，但并沒有抽象到數(shù)據(jù)庫模式的高度，因此需要進一步研究。

2MDA中的數(shù)據(jù)庫表模式及其演變機制

MDA 軟件范型是一種新型的軟件開發(fā)范型，也是一套標準和技術。其基于面向對象的思想，一切遵循人類對事物的認知過程，從理解問題到認知問題，從分析問題到解決問題，建立相互對應的模型，從而達到實現(xiàn)系統(tǒng)的目的。各模型之間的邏輯關系需遵循進化性（繼承性）、可追溯性和可轉化性的關系。

2.1MDA主要模型

MDA的主要模型包括3種，計算無關模型（Computation Independent Model，CIM）、平臺無關模型（Platform Independent Model，PIM）與平臺相關模型（Platform Specific Model，PSM）。經(jīng)過前期研究[15]，為了更完整地進行信息建模，在CIM建模之前增加業(yè)務模型（Business Model ， BM）過程。BM是對業(yè)務的描述，以及對業(yè)務實施的初步分析。BM用業(yè)務用例圖、活動圖及業(yè)務對象圖進行建模。

MDA軟件范型中4個模型層次是自然演變的，其結構層次清晰，設計沒有鴻溝，是系統(tǒng)設計的良好選擇[3]。其PSM中的類和對象可作為E-R圖（Entity Relationship Diagram）中“E”的來源，其演變機制值得深入研究。下面將對4層模型結構作詳細分析。

（1）業(yè)務模型（BM）。業(yè)務模型（BM）是第一層抽象模型，旨在捕獲系統(tǒng)語境中最重要的對象類型。業(yè)務模型的建立是為了業(yè)務運行而并非為了系統(tǒng)信息化，主要指通過需求者對業(yè)務在系統(tǒng)環(huán)境下的直觀和簡要描述，業(yè)務人員對其描述進行高度的凝練和提取。業(yè)務模型具有復雜性、多維性和廣泛性。業(yè)務建模的目的是為了定義和表示業(yè)務的目的、行為和結構。

業(yè)務過程模型是系統(tǒng)需求模型（CIM）的基礎，CIM建模階段需從BM建模中找出可信息化的部分。

（2）計算無關模型（Computation Independent Model，CIM）。計算無關模型（CIM）是一種需求分析模型，主要用來對某具體行業(yè)內(nèi)一個項目的業(yè)務需求及其系統(tǒng)功能需求進行分析，而對于系統(tǒng)的內(nèi)部細節(jié)不作過多考慮。計算無關模型由業(yè)務需求和系統(tǒng)功能需求兩部分組成。其中，業(yè)務需求是從業(yè)務員的角度出發(fā)，對一個項目在非計算機環(huán)境下的情況進行簡單描述；系統(tǒng)功能需求是從系統(tǒng)用戶的角度出發(fā)，對一個軟件的功能需求進行簡單描述。

（3）平臺無關模型（Platform Independent Model，PIM）。平臺無關模型（PIM）是一種系統(tǒng)分析模型，主要用來對系統(tǒng)內(nèi)部的結構和執(zhí)行細節(jié)進行詳細分析，并對業(yè)務的邏輯性和完整性進行分析和規(guī)范，而對于系統(tǒng)的實現(xiàn)技術及具體平臺不作任何考慮。PIM來源于計算無關模型，它是連接需求分析與系統(tǒng)詳細設計的關鍵模型。

（4）平臺相關模型（Platform Specific Model，PSM）。平臺相關模型（PSM）是一種系統(tǒng)詳細設計模型，它依據(jù)相關的實現(xiàn)技術和具體平臺完成系統(tǒng)的詳細設計。PSM來源于平臺無關模型，基于不同實現(xiàn)平臺的選擇，一個PIM模型可以產(chǎn)生多個PSM模型。數(shù)據(jù)庫表就是在這一層得到的最終形式。

2.2數(shù)據(jù)庫表模式演變機制

2.2.1數(shù)據(jù)庫表模式演變原理

MDA軟件范型的目標之一是通過提高軟件開發(fā)的抽象層次實現(xiàn)系統(tǒng)之間的互操作性[9]。而軟件要處理在數(shù)據(jù)庫表中存儲的數(shù)據(jù)，其數(shù)據(jù)存儲模式的設計則顯得至關重要。數(shù)據(jù)庫表模式演變的原理如下：在業(yè)務域，業(yè)務單據(jù)表是數(shù)據(jù)庫表的初期形式，它在分析域依據(jù)第三范式進行分解，成為魯棒圖的重要組成部分，在設計域中分配職責并確定類的方法時，不斷對類、關系和方法名等進行優(yōu)化，完善系統(tǒng)邏輯，從而形成完整清晰的數(shù)據(jù)庫表模式。

它主要包含以下幾個性質：①抽象性，指在MDA建模過程中，通過關注分離實現(xiàn)層次之間的交互，將設計從架構中分離出來；②層次性，在基于MDA軟件范型探索數(shù)據(jù)庫表的模式演變過程中，數(shù)據(jù)庫表在不同層次具有不同的表現(xiàn)形式；③可追溯性，數(shù)據(jù)庫表在每個層次的變換形態(tài)均有出處，有現(xiàn)實依據(jù)，不依賴于頭腦風暴，實現(xiàn)了從模型到代碼的有機轉化；④精化性，從業(yè)務域到設計域，數(shù)據(jù)庫表在每一層的表現(xiàn)都比其在上一層的表現(xiàn)更為細化和準確，各表之間的關系更明了。

2.2.2數(shù)據(jù)庫表模式演變機制

通過上文對各個域模型的分析，基于統(tǒng)一建模語言，數(shù)據(jù)庫表的演變機制如下：①在業(yè)務域，數(shù)據(jù)庫表還是基礎的表現(xiàn)形式，它基于現(xiàn)實中的業(yè)務單據(jù)表、業(yè)務對象和業(yè)務Actor/Worker等信息，對它們進行整理、提??；②基于業(yè)務域，需求域主要是提取活動圖中可信息化的部分，生成系統(tǒng)用例圖。數(shù)據(jù)庫表在這一層沒有明顯升華；③基于需求域，在分析域中依據(jù)第三范式對業(yè)務域中的對象進行分解，數(shù)據(jù)庫表體現(xiàn)在魯棒圖的實體對象中；④基于分析域，在設計域中通過分配職責并確定類的方法形成序列圖，通過優(yōu)化和整理形成完整的類圖。類圖包含實體類、邊界類和軟件類3部分。其中的實體類進一步生成E-R圖，最后形成適用于編碼的數(shù)據(jù)庫表模式；⑤基于前期生成的數(shù)據(jù)庫表，在代碼域即可使用具體的編程語言，如JAVA、C#等進行編碼。

2.2.3數(shù)據(jù)庫表模式演變過程圖示化表示

現(xiàn)將數(shù)據(jù)庫表模式演變用形象的圖示進行表示，方便下一步詳細講解，如圖1所示。

2.2.4數(shù)據(jù)庫表演變過程詳細說明

如圖1所示，數(shù)據(jù)庫模式的演變歷程從業(yè)務模型（BM）、計算無關模型（CIM）、平臺無關模型（PIM）到平臺相關模型（PSM），旨在消除設計模型之間的鴻溝。

首先，在業(yè)務域，根據(jù)現(xiàn)實需求畫出業(yè)務用例圖，然后進一步細化用例圖中的每一條用例，生成活動圖，活動圖的形成涉及到現(xiàn)實中的業(yè)務規(guī)則、業(yè)務Actor/Worker、業(yè)務單據(jù)表和業(yè)務對象?；顒訄D中的每個對象節(jié)點都持有對象和數(shù)據(jù)，這是業(yè)務單據(jù)的來源，在活動圖中它們會等待一個合適的機會來流通[9]。而業(yè)務單據(jù)、業(yè)務對象、業(yè)務Actor/Worker三者又是分析域中魯棒圖的一部分。

其次，在需求域，依據(jù)活動圖，提取其中可以信息化的部分，生成系統(tǒng)用例圖，對其實現(xiàn)用例邏輯，寫出系統(tǒng)用例規(guī)約。

然后，在分析域，根據(jù)系統(tǒng)用例規(guī)約，獲取對象屬性，完善在需求域中得到的魯棒圖中的實體對象，以及找出魯棒圖的邊界對象和控制對象。依據(jù)第三范式分解業(yè)務單據(jù)圖，提取出形成分析域中魯棒圖的實體對象。將魯棒圖中與實體對象有直接關系的控制對象轉換為序列圖中相關實體類的方法，也即給類分配職責[10]。類圖包含實體類、邊界類和軟件類三部分。

最后，在設計域，根據(jù)魯棒圖確定類的序列，將魯棒圖進一步轉化為序列圖。根據(jù)分析域中的實體類得到E-R圖，從而生成數(shù)據(jù)庫表模式，由此進入到最后的代碼域中。

3相關研究比較

管理系統(tǒng)中數(shù)據(jù)庫設計的傳統(tǒng)方法主要分為結構化分析法、信息建模法、CRC法和ICONIX法，以下將分別總結其優(yōu)缺點。

3.1數(shù)據(jù)流法（Data Flow Approach）

數(shù)據(jù)流法（Data Flow Approach）又稱為結構化分析法。其基本策略是跟蹤數(shù)據(jù)流，即研究問題域中數(shù)據(jù)如何流動，以及在各個環(huán)節(jié)上進行何種處理，從而發(fā)現(xiàn)數(shù)據(jù)流和加工。問題域被映射為數(shù)據(jù)流圖（DFD），并用處理說明和數(shù)據(jù)字典進行詳細說明。用來描述概念數(shù)據(jù)模型的主要工具是E-R（實體—聯(lián)系）模型，又稱為E-R 圖。優(yōu)點是有嚴格的法則，較強調研究問題域。缺點是它仍然是間接映射問題域，與結構化設計概念不一致，從分析到設計的過渡比較困難，且數(shù)據(jù)流與加工的數(shù)量太多，引起分析文檔的膨脹。

3.2信息建模法（Information Modeling）

信息建模法（Information Modeling）由實體—關系法（E-R方法）發(fā)展而來，與數(shù)據(jù)庫設計有很深的淵源，其核心概念是實體和關系。實體描述問題域的事物，含有屬性；關系描述事物之間在數(shù)據(jù)方面的聯(lián)系，也可以帶有屬性。發(fā)展之后的方法也把實體稱作對象，并使用類型和子類型的概念，作為實體（對象）的抽象描述[14]。其優(yōu)點是它注重信息存儲模式建模，但忽視了軟件功能建模機制。

3.3CRC法（Candidates、Responsibilities、Collaborators）

CRC法（Candidates、Responsibilities、Collaborators）主要是利用頭腦風暴的方法來挖掘建模初期的設計思想，優(yōu)點明顯，即工具非常便利、簡單，可以被隨時移動、修改或丟棄。但缺點也不可忽視，即缺乏可靠的現(xiàn)實依據(jù)，容易在后期編碼過程中出現(xiàn)問題。

3.4ICONIX過程

ICONIX過程是盡早進入編碼階段，縮短分析設計周期的軟件開發(fā)方法，其基于極限編程（XP）和敏捷軟件開發(fā)的思想，合理地簡化統(tǒng)一過程（RUP）。只使用4個UML圖（用例圖、健壯性圖、時序圖、類圖）完成所有工作。ICONIX也是用例驅動的架構，與極限編程一樣，相對較小，比較緊湊，但又不像極限編程摒棄了分析與設計過程[9]。因此，ICONIX是一種高效的建模方法[9]，但類的來源沒有現(xiàn)實依據(jù)。

3.5方法比較

綜上所述，數(shù)據(jù)流法過早設計數(shù)據(jù)細節(jié)而致使設計文檔膨脹；信息建模法注重信息存儲模式建模，而忽視了軟件功能建模機制；CRC方法則主要利用頭腦風暴法收集對象及其協(xié)作機制，缺乏可追溯性；ICONIX是一種高效的建模方法，但類的來源沒有現(xiàn)實依據(jù)。相比之下，MDA軟件范型從現(xiàn)實世界的業(yè)務層面入手，逐步進行分析設計，減少步驟間的設計鴻溝，使其平滑過渡，生成可操作性強、完整直觀的數(shù)據(jù)庫表模式。

通過前面幾種方法的比較，可以發(fā)現(xiàn)每種建模方法各有優(yōu)缺點。但通過與實際案例相結合，可以看到上述方法自然、清晰地提供了一個數(shù)據(jù)庫表生成的過程，在建模過程中步步為營，有理有據(jù)，建模過程中對數(shù)據(jù)列表及模型的表示更加清晰，模型間的轉換更加平滑，彌補了模型層次間數(shù)據(jù)庫表轉化的鴻溝，成功指導模型間的平滑過度，并使PIM成功轉化到PSM，最終設計出實用性強、符合客戶需求的系統(tǒng)。

4結語

本文主要研究了MDA軟件范型中的數(shù)據(jù)庫表模式演變機制。首先比較了幾種傳統(tǒng)的數(shù)據(jù)庫設計路線，然后深入研究和闡述了MDA軟件范型中各個建模階段之間的關系，進而提出一種更為直觀和完整的建模步驟；接著基于筆者前期的研究，抽象出了業(yè)務建模過程，并整合了各個建模階段之間的關系；然后基于對相關理論的深入研究，提出了一種MDA軟件范型中數(shù)據(jù)庫表模式演變的機制，最終設計出實用性強、符合客戶需求的系統(tǒng)，并對該數(shù)據(jù)庫表模式演變機制進行了驗證。

參考文獻參考文獻：

[1]YANG D R， XUE M. Software process paradigm and its constraint mechanisms [C].International Conference on Software Engineering and Service Science， 2011：842845.

[2]DEREN YANG， MIN LIU， SHENGGUO WANG.Objectoriented methodology meets MDA software paradigm[C].Proceedings of the 3rd International Conference on Software Engineering and Service Science（ICSESS 2012），IEEE Press，2012：208211.

[3]R M NOORULLAH.Grasp and GOF patterns in solving design problems[J]. Journal of Current Engineering Research，2011.

[4]DEREN YANG，F(xiàn)ULIN SU，TAO ZHOU.Applying robustness analysis to MDA software process paradigm[C].2012 International Symposium on Instrumentation & Measurement， Sensor Network and Automation （IMSNA），2012：419422.

[5]邱郁慧.系統(tǒng)分析師UML實務手冊[M].北京：機械工業(yè)出版社，2008：1718.

[6]HE MAN， LIU XIANGWEI，HAO CHENGMIN. Research on transformation method from PIM to relation PSM [J].Computer Engineering， 2010， 36（3）：5860.

[7]YAMIN M， ZUNA V. Requirements analysis and traceability at CIM level[J]. SoftwareEngineering & Applications， 2010， 3（9）：845851.

[8]SHARIFI H R， MOHSENZADEH M. A new method for generating CIM using businessand requirement models [J]. World of Computer Science and Information Technology Journal， 2012， 2（1）：812.

[9]劉敏.基于業(yè)務模型的MDA軟件范型擴展研究[D].銀川：北方民族大學，2014.

[10]李波.面向對象技術在MDA軟件范型中的應用研究[D].銀川：北方民族大學，2014.

[11]孟志偉.管理信息系統(tǒng)的數(shù)據(jù)庫設計[J].信息與電腦，2009（7）：9092.

[12]文斌，李榮國.面向對象的數(shù)據(jù)庫設計方法[J].荊門職業(yè)技術學院學報，2002，17（3）：2325.

[13]張念，陳薇.基于UML的面向對象數(shù)據(jù)庫設計思想及在HR系統(tǒng)中的應用[J].計算機應用與軟件，2009（8）： 138140.

[14]面向對象的分析[EB/OL].http：//sei.pku.edu.cn/～swz/OO/analysis1.pdf.

[15]DEREN YANG，MIN LIU，BO LI.Modeling business for MDA software paradigm[J].International Journal of Database Theory and Application，2014，7（4）：155168.

責任編輯（責任編輯：黃?。?