基于MDA的医院管理系统的研究与设计 锐拓医院管理系统

基于MDA的医院管理系统的研究与设计 锐拓医院管理系统 摘要：模型驱动架构(MDA)是对象管理组织OMG提出的软件开发方法，它具有高效地实现系统集成和互操作、解决遗留系统问题、适应业务逻辑的快速变更以及缩短开发周期等优点。文章以一个医院管理系统项目设计为实例，研究了基于模型驱动架构(MDA)的软件开发方法，实现了领域模型的建立及领域模型到应用模型的变换。 关键词：模型驱动架构；平台无关；模型变换；医院管理系统 0、引 言 传统的软件开发存在开发效率比较低、软件可移植性差、文档质量低、系统互操作性差等各种问题。对象管理组织OMG在xx年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中使用的关联的组合聚合(posite 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部分是按照J