MDA模型驱动开发方法学

MDA模型驱动开发方法学

主讲：张文（Jevons）一、传统软件工程方法学

传统的软件开发方式有许多模型，瀑布模型是其中最典型也最受诟病的一种，为了描述一个软件的生命周期，我们暂时以这种模型来阐述一下软件开发的过程。

软件开发要经历可行性分析研究，需求分析，总体设计（概要设计），详细设计，集成和测试等过程。一个成熟的软件模型在这些环节都需要生成大量的文档，目前的很多CMMI工具能很好的管理好这些文档，比如将需求文档关联到后期的详细设计的过程或编码的过程等。由于这个过程的生命周期太长，导致了开发过程中发现的问题不能及时反映到模型中来（虽然某些工具能跟踪到需求的变化），这个传统的工作过程虽然在目前遇到了极大的挑战，所以目前非常流行所谓的敏捷开发，本人也非常崇尚这种开发方式，但从我的经验来看，敏捷开发应该更多的体现在小项目或大项目的子模块的开发。对于一个较大的项目而言，一定的设计和研讨还是必不可少的。但如何解决之前所提到的开发周期过长，错误反馈不到位的诟病呢？

我认为，在详细设计阶段，如果能有一个好的开发模型将能极大的解决这种问题，而MDA就是这么一个开发模型。

二、MDA的过程

MDA，全称叫模型驱动开发，顾名思义，开发是由模型来推动的，即开发之前需要建立良好的模型。

也许大家现在有了一定的概念了，因为大家在大大小小的开发时都会画一些uml图，建立一定的模型，然后一个软件的雏形就应运而生了。如果大家能做到这一步，恭喜你，说明你已经具备一定的设计能力了。但我也要反问你，在工作过程中，请问有哪次的模型是你自己觉得非常满意的，或者说是你的得意之作吧。面对这个简单问题，我想任何肯定回答都是牵强的，因为小的软件过程基本上不需要良好的设计，而大的软件过程，则很难做到良好的设计，如果没有一个良好的开发机制的话。

而MDA的开发方式则不一样，因为设计和编码可以融为一体，而且任何编码之前都是设计，任何设计都能生成编码，代码中也能访问到设计中的元数据定义，这就是MDA的神奇之处。

三、MDA的具体实施

金蝶的MDA方式建立在金蝶BOS的基础之上，BOS意思是Busingess Operation System，意思是业务定义系统，但远没那么牛，但在这个工具上实施MDA则是恰到好处。

一个典型的开发过程如下：首先定义实体，该实体具有一定的属性，而且从一定的父实体集成过来（如表单，基础数据等），这个实体也有一定的业务方法，在业务方法的定义中可以确定参数、返回值和异常，同时，可以在方法上定义EJB事务属性等。这些方法都可

以在生成代码时自动生成本地接口，远程接口，工厂方法接口，及工厂方法，而实体则可导出为VO（值对象），VO Collection对象等。

实体是一类重要的模型设计，此模型设计好了后可以导出另外一种模型——表元数据，一种描述数据如何存储的元数据，简单的说就是表的设计。其中可以按规范定义表名，字段名，主键名，外键名（虽然不建议建外键引用）。根据这种模型的设计就可以导出在各种数据库中可以运行的数据库脚本。注意，在金蝶，这种脚本被称作KSql，金蝶sql，因为金蝶有一个sql的中间层，可以屏蔽各种sql的差异。

目前的设计过程更多的是后台的设计，如果我们设计的东东是前后台都有的三层结构，那么还有客户端的设计，即UI设计。

金蝶BOS有一种元数据就称作UI设计，最典型的两种UI就是叙事簿（ListUI）和编辑（EditUI）界面了，前者是个数据的列表，后则则是一条数据的编辑界面，当设计这两种UI时，采用所见即所得的方式，可以精确定位UI中的组建，可以轻松绑定一个查询（Query）到ListUI或绑定一个VO到EditUI，并且可以从ListUI点击Edit按钮弹出EditUI，至于这之间数据是如何传递的，则由模型生成的框架代码来搞定。

经过简单的设计，一个软件的真实模型就出来了，运行模型生成的代码，客户端可以用ejb的方式远程访问服务器，可以在客户端浏览数据库中的数据，可以编辑或新增一条数据，可以准确的处理财务数字，可以定义更多的数据约束，甚至已经集成了权限，事务处理，日志服务，工作流，而我们目前所做的仅仅是设计而已。

完成了这一步，可以说我们建立了模型了，这就意味这可以驱动开发了。

工具生成的代码分抽象层和实现层，实现层是我们需要进一步完善的商业逻辑，而抽象层就是我们的框架代码。商业逻辑我不想多说了，这是大家最熟悉的编码阶段。

经过一定时间的开发，现在问题来了，经过大家的日夜奋战，需求或产品人员一看，总体满意，但还有些地方不符合用户需求，这个时候怎么办？？

如果是传统的开发方式，可能要重新审视需求或重新修改需求，整个开发过程来重来，包括设计。如果这样做的话，是一种负责人的开发方式，而我所见到的多数情况是，开发人员跟产品经理谈了后立即在代码中做若干次重大修改，最后达到了产品需求，而后也交互使用了，但你回过头来发现，之前做的设计也许跟现在的实现已经关系不大了，这种代码对日后维护来说是一场灾难。

现在说一下MDA的做法，当发现软件产品与需求不一致时，首先修改的是模型，注意是模型，而不是代码，任何改动都会首先体现在模型上，由于有工具支持，这种过程是迅速而安全可靠的。模型对应的是框架代码，有着丰富的功能，很多时候，修改了一下模型，不用改写一行商业代码就能通过产品部门的审核了，而且这种软件产品具备了极高的可维护性，因为模型可以做反向工程成为可读性很强的uml图，其实只要看模型就能很直观的窥见整个软件的全貌了。

模型驱动的开发方法——基于面向对象的开发

模型驱动的开发方法——基于面向对象的开发 2012210874 魏翔案例 案例名称：《基于UML的GRAPPLE在数字化医院信息系统设计中的应用》 案例简述： GRAPPLE (Guidelines for Rapid application Engineering: 快速应用工程指导原则)主要适用于面向对象系统。因此，每个段中的动作主要是生成面向对象的工作产品。GRAPPLE 所包括的5个段分别为： 1需求收集 1.1发现业务过程 首先要分析员要用客户业务常用的词汇与客户进一步面谈，从而建立一个或者一组能够捕获业务过程中的步骤和判定点的活动图，即从客户的业务流程出发理解系统。 1.2领域分析 领域分析可以与前一个动作同时进行，它们的共同目标是达到对某特定领域的理解。在此过程中，分析员需要分析与客户的会谈从而开发初步类图、建立和标记类之间的关联并且找出关联的多重性。 1.3发现系统需求 在此阶段，GRAPPLE 要求开发组举行一次联合应用开发会议，参加者包括客户的决策者、用户以及开发组成员。会议的参加者一同收集系统需求，需求收集的结果是一个包图，这个包图中的每个包代表系统的一个主要功能模块，每个包中包括一组用例，它们详细说明这个包代表的功能。本系统最重要的是事务对象包，它包括了系统涉及的大部分功能模块，例如挂号收费模块、看病诊断模块、取药模块、住院出院模块等；用户接口包定义了数据导入导出接口、打印接口；数据库包则定义了系统使用的数据库表、视图、存储过程。 2分析 2.1开发用例 “发现系统需求”阶段得到的每个功能包中的用例说明系统必须要做的事。在“开发用例”阶段开发组还必须分析和理解每个用例，描述用例执行步骤以便绘制详细用例图。HIS 系统案例的用例图如图 1所示。

MDA模型驱动开发方法学

MDA模型驱动开发方法学 主讲：张文（Jevons）一、传统软件工程方法学 传统的软件开发方式有许多模型，瀑布模型是其中最典型也最受诟病的一种，为了描述一个软件的生命周期，我们暂时以这种模型来阐述一下软件开发的过程。 软件开发要经历可行性分析研究，需求分析，总体设计（概要设计），详细设计，集成和测试等过程。一个成熟的软件模型在这些环节都需要生成大量的文档，目前的很多CMMI工具能很好的管理好这些文档，比如将需求文档关联到后期的详细设计的过程或编码的过程等。由于这个过程的生命周期太长，导致了开发过程中发现的问题不能及时反映到模型中来（虽然某些工具能跟踪到需求的变化），这个传统的工作过程虽然在目前遇到了极大的挑战，所以目前非常流行所谓的敏捷开发，本人也非常崇尚这种开发方式，但从我的经验来看，敏捷开发应该更多的体现在小项目或大项目的子模块的开发。对于一个较大的项目而言，一定的设计和研讨还是必不可少的。但如何解决之前所提到的开发周期过长，错误反馈不到位的诟病呢？ 我认为，在详细设计阶段，如果能有一个好的开发模型将能极大的解决这种问题，而MDA就是这么一个开发模型。 二、MDA的过程

MDA，全称叫模型驱动开发，顾名思义，开发是由模型来推动的，即开发之前需要建立良好的模型。 也许大家现在有了一定的概念了，因为大家在大大小小的开发时都会画一些uml图，建立一定的模型，然后一个软件的雏形就应运而生了。如果大家能做到这一步，恭喜你，说明你已经具备一定的设计能力了。但我也要反问你，在工作过程中，请问有哪次的模型是你自己觉得非常满意的，或者说是你的得意之作吧。面对这个简单问题，我想任何肯定回答都是牵强的，因为小的软件过程基本上不需要良好的设计，而大的软件过程，则很难做到良好的设计，如果没有一个良好的开发机制的话。 而MDA的开发方式则不一样，因为设计和编码可以融为一体，而且任何编码之前都是设计，任何设计都能生成编码，代码中也能访问到设计中的元数据定义，这就是MDA的神奇之处。 三、MDA的具体实施 金蝶的MDA方式建立在金蝶BOS的基础之上，BOS意思是Busingess Operation System，意思是业务定义系统，但远没那么牛，但在这个工具上实施MDA则是恰到好处。 一个典型的开发过程如下：首先定义实体，该实体具有一定的属性，而且从一定的父实体集成过来（如表单，基础数据等），这个实体也有一定的业务方法，在业务方法的定义中可以确定参数、返回值和异常，同时，可以在方法上定义EJB事务属性等。这些方法都可

基于TMS320DM642驱动模型的驱动程序开发

基于TMS320DM642驱动模型的驱动程序开发 武汉大学金朝辉 随着新技术不断涌现和DSP实时系统日趋复杂，不同类型的外部设备越来越多，为这些外部设备编写设备驱动程序已成为依赖操作系统管理硬件的内在要求。但是，由于内存引脚、响应时间和电源管理等条件的限制，为一个给定的DSP系统编写设备驱动程序有时会很困难。针对设备驱动程序开发者遇到的上述难题，TI公司为C64X系列DSP的开发者提供了一种"类/微型驱动模型（Class/Mini－driver Model）"，该模型在功能上将设备驱动程序分为依赖硬件层和不依赖硬件层，两层之间使用通用接口。实践结果表明，采用类/微型驱动模型进行设计后，应用软件可以复用绝大部分相似设备的驱动程序，从而提高驱动程序的开发效率。 1 类/微型驱动模型简介 在类/微型驱动模型中，类驱动通常用于实现多线程I/O请求的序列化和同步功能；同时对设备实例进行管理。在包括视频系统I/O和异步I/O的典型实时系统中，只有少数的类驱动需要表示出外部设备的类型。 类驱动通过每个外部设备独有的微型驱动对该设备进行操作，微型驱动则通过控制外设的寄存器、内存和中断资源来实现对外部设备的控制，微型驱动程序必须将特定的外部设备有效地表示给类驱动。例如：视频显示设备存在一些不同的帧存，应用软件会根据不同的I/O操作进行帧存的分配，此时微型驱动必须映射视频显存，使得类驱动可对不连续的内存（分别存放RGB或YUV分量）设计特定的I/O请求，类/微型驱动模型允许发送由开发者定义数据结构的I/O请求包给微型驱动来控制外部设备，此分层结构使设备驱动的复用能力得到加强，并且丰富了发送给微型驱动I/O 请求包的结构。 类/微型驱动模型的结构如图1所示，上层应用程序并非直接控制微型驱动，而是使用一个或一个以上的类驱动对其进行控制。每个类驱动在应用程序代码中表现为一个API函数，并且通过微型驱动的接口IOM与微型驱动进行通信，类驱动使用DSP/BIOS的中的API函数来实现诸如同步等系统服务（DSP/BIOS是TI公司推出的一种实时操作系统，实际上它是一组可重复调用系统模块的ABI函数集合）。到目前为止DSP/BIOS共定义了3种类驱动：流输入输出管理模块（SIO/DIO）、管道管理模块（PIP/PIO）和通用输入输出模块（GIO）。在PIP/PIO和SIO/PIO类驱动中，调用的API函数已存在于DSP/BIOS的PIP和SIO模块中，这些API函数将参数传给相应的适配模块（Adapter），适配模块再与微型驱动交换数据。在GIO类驱动中，调用的API函数直接与微型驱动通信（需在CCS2.2以上）。

AADL在模型驱动开发中的应用

AADL在模型驱动开发中的应用 刘巨富51141500022 摘要 AADL(Architecture Analysis & Design language)[1]是一种字符化和图形化的语言，用于对嵌入式系统进行建模。MDA(Model Driven Architecture)[2]是OMG(Object Management Group)大力提倡的一种模型开发过程。其主要思想是用户建立平台无关模型PIM(Platform Independent Model)，结合具体平台信息生成平台相关模PSM(Platform Specific Model)，然后再生成代码Code。本文研究的主要内容是如何在MDA开发过程中使用AADL，对嵌入式系统进行建模。本文先介绍了相关背景知识，然后分成两个部分进行重点研究。 首先本文提出了UML与AADL模型转换的方法，在EMF(Eclipse Modeling Framework )基础上借助ATL(Atlas Transformation Language)模型转换工具实现UML与AADL模型的互相转换。 然后，研究了AADL代码自动生成及集成技术，设计AADL 模型转换为C 语言框架代码的自动代码生成器Generator并实例证明了AADL模型自动转换为可执行C 代码的有效性。 1.背景知识介绍 嵌入式软件的规模及复杂性的不断增长导致开发时间和开发费用急速增长，如何快速有效地开发嵌入式软件成为目前急待解决的问题。模型驱动体系结构(Model Driven Architecture, MDA)是一种具有生命力和应用前景的开发方法。使用MDA 方法的软件开发过程如图1 所示，其中，模型是研究的中心。在嵌入式软件产业中已有许多面向功能的建模工具，如Simulink, SCADE等。 图1 使用MDA 方法的软件开发过程 在传统的嵌入式软件开发过程中，缺乏对整个系统体系结构的精确预算，虽然单个功能模块的非功能属性相对容易实现，但在系统集成后如何满足整个系统的非功能属性对于开发人员是一个巨大挑战。要解决这些问题，可以采用MDA 方法在系统实现前建立模型，在模型级对整个系统的体系结构进行非功能属性规