基于MDA的醫院管理系統的研究與設計

摘要：模型驅動架構(MDA)是對象管理組織OMG提出的軟件開發方法，它具有高效地實現系統集成和互操作、解決遺留系統問題、適應業務邏輯的快速變更以及縮短開發周期等優點。文章以一個醫院管理系統項目設計為實例，研究了基于模型驅動架構(MDA)的軟件開發方法，實現了領域模型的建立及領域模型到應用模型的變換。

關鍵詞：模型驅動架構；平臺無關；模型變換；醫院管理系統

0、引 言

傳統的軟件開發存在開發效率比較低、軟件可移植性差、文檔質量低、系統互操作性差等各種問題。對象管理組織OMG在2001年7月提出了全新的軟件開發框架——模型驅動架構(Model-Driven Architecture，MDA)。MDA將建模語言視為編程語言，而不僅僅是設計語言。用建模語言編程可以提高生產效率，改善質量，并使軟件產品生存期更長。

OMG的構想是將目前的開發行為提升到更高的抽象層級——分析模型，把針對特定計算平臺的編碼工作交由機器自動完成，從而達到分離業務邏輯和具體實現平臺的目的，二者相對獨立變化。在傳統的軟件開發方法中，隨著項目的進展，設計階段產生的UML模型和代碼之間的同步會變得愈來愈困難——代碼為了應付新增加的需求和新產生的想法而不斷變化，模型卻一直停留在原地不動，這使得模型在一段時間之后就失去了它的價值。OMG提出了一個根本的解決方案——在MDA中，模型不再是一種輔助工具，而是開發過程的產品。

MDA包括圍繞支持模型驅動開發過程的一系列標準框架，這些標準包括：統一建模語言UML(Unified Modeling Language)、元對象設施MOF(Meta Object Facility)、XML元數據交換XMI(XML Metadata Interchange)、公共倉庫元模型CWM(Common Warehouse Metamodel)等。

1、MDA的基本框架

MDA框架的主要元素包括模型、PIM、PSM、語言、元語言、變換、變換定義以及變換工具。

從開發者的角度看，PSM和PIM是最重要的元素。開發者把注意力集中在開發PIM上，在高抽象層次描述系統軟件，然后，選擇一種或者多種工具來執行對PIM的變換。這些變換工具是按照特定的變換定義開發的。變換的結果是PSM，這個PSM再被變換成代碼。

2、MDA的開發過程

MDA通過模型之間變換來實現軟件的開發。MDA的架構中包含了PIM和PSM兩個重要的部分。應用MDA方法進行軟件開發時，需要開發人員做兩件事情：一是為系統設計平臺無關模型PIM；二是選擇適當的變換規則進行模型變換，使PIM生成PSM。

MDA的軟件開發過程和傳統的軟件開發過程具有相同的開發階段，主要區別是各階段的設計工件不同。傳統軟件開發的設計工件是文檔圖，容易被開發者所理解；MDA的設計工件是精確的模型，能夠被機器所理解。

3、醫院管理系統開發平臺

Compuware公司的OptimalJ是Butler集團評出的最好的MDA工具之一。它實現了MDA規范，通過從可視化的模型中直接產生程序的代碼，從而提高了基于J2EE的應用程序的開發速度。

OpfimalJ有三種主要模型。

(1)Domain模型：Domain模型對應于MDA中的PIM，它是OptimalJ模式驅動開發框架的核心部分。Domain模型包含Class、Service和Use Case模型；同當今絕大多數MDA應用一樣，使用UML表示模型。

(2)Applicafion模型：Application模型對應MDA中的平臺相關模型PSM。

(3)Code模型：Code模型包含Java類和接口的定義。

3.1建立模型

醫院管理系統包含門診掛號系統、門診劃價收費系統、門診醫生工作站、住院病人管理系統、住院費用管理系統、住院醫生工作站、藥房管理系統、院長綜合查詢系統和外部數據接口等。

本文重點討論如下幾個核心模塊：人員管理模塊，住院管理模塊，病案病歷管理系統。各模塊功能描述如下：

(1)人員管理模塊。一個醫院的員工(Employee)只能隸屬于一個部門并且只能屬于一種員工類型。而一個具體醫院的部門(Department)之間的關系實際上是—個樹型結構，一個部門下面可以有多個子部門，每個子部門只能隸屬一個上級部門，而不能同時隸屬于多個上級部門。在醫院管理系統中，我們把員工類型分為：管理人員、醫護人員、后勤人員、服務人員等。不同的用戶在系統中采用不同的識別號進行區分。用戶子模塊的具體設計如圖1所示。

(2)住院管理模塊。在系統中，我們定義一個住院病人可以擁有一張病床：病床的狀態分為有病人使用和空著兩種。

(3)病案病歷管理模塊。不管病人是門診治病，還是住院治療，每個病人都應該有相應的病歷，作為醫院對患者進行診療全過程的完整記錄。

3.2建立PIM

下面給出住院系統的PIM，如圖2所示。在圖2所示的模型中，我們注意到沒有動態方法，這是因為有很多方法OptimalJ可以根據模型之間的關系自動生成。對于OptimalJ不能生成的方法，我們會在系統的PSM中手動添加。這樣做的好處是簡化了轉換的復雜性，易于系統的維護。

3.3PIM到PSM的變換

(1)PlM到關系PSM的變換

對于每一個應用，都必須經過從Domain模型到DBMS模型的轉換。將概念上的數據類持久化，生成數據庫Schema是基本步驟。在本系統經過轉換后生成的DBMS模型如圖3所示。

圖3是從Domain模型生成的原始的DBMS模型。如圖所示，我們可以根據需要進行必要的調整，比如調整數據類型或者字符串的長度等。而且這種調整會在下一次從Domain模型到DBMS模型的轉換中保留。

(2)PIM到FAB PSM的變換

EJB層是J2EE架構的關鍵層次。OptimalJ目前只能用來生成J2EE應用，換句話說，Optimatl只支持EJB PSM的變換。UML的PIM模型同EJB PSM模型有著很大不同。它可以簡單地用為每個class生成一個組件的方法來創建EJB組件模型。

EJB數據模式是一組類、屬性、關聯，在數據交互時，它們被EJB組件作為整體來對待。FAB數據類是一個類，它是EJB數據模型的一部分。對于在PIM中使用的關聯的組合聚合(composite aggregation)屬性，一個類如果是某個整體的一部分，那么分組時它就被歸入那個整體所生成的數據模式。

3.4 PSM到代碼的變換

(1)DBMS PSM到代碼的變換

將圖3所示的DBMS PSM變換成SQL Script，其部分代碼片斷如下所示：

CREATE TABLE zygLpatient(

patientlD INTEGER NOT NULL，

patientName VARCHAR(40) NULL，

sex VARCHAR(2) NuLL

aateotBirth DAIE NULL，

patientAddtess VARCHAR(40) NULL，

patientTel VARCHAR(40) NULL，

PARIMAY KEY(patientlD)

)：

(2)EJB PSM到代碼的變換

從PIM得到的EJB PSM是一個具有EJB數據模式的PSM，雖然這個PSM已經具有了EJB平臺的相關細節，但是離真正的EJB實現代碼還比較遠。EJB一般分為三種類型：Session Bean、Entity Bean和Message Driven Bean。

在本實例中選擇將FAB PSM變換成為Entity Bean。按照EJB規約，每個Entity Bean都要有一個主鍵類(key class)，如果Entity Bean提供遠程客戶視圖，那么就要提供遠程接口和遠程home接口；如果Entity Bean提供本地客戶視圖，就需要本地接口和本地home接口。

為了定義一些FAB組件的屬性，模型變換工具會自動生成用XML寫的描述信息。這些描述信息表述了業務方法和組件的持久化策略。

每個EJB組件都提供了實現EJB數據類的類，每個數據類都有set和get方法，以及在本地維護細粒度的私有屬性。

(3)Web PSM到代碼的變換

應用軟件的Web部分是按照J2EE對Web層的標準實現的。組件是用JSP實現的。每個來自客戶的請求都會實例化一個JSP，產生的結果HTML會被送回瀏覽器。每個Web組件都對應生成一個JSP文件。軟件運行時，JSP會生成HTML頁面，頁面中包含一個表，表中各行對應于同一類型的所有對象，表中各列對應于該類型的屬性，如此便將Web PSM變換成了代碼(可以運行的JSP頁面)。