当前位置:文档之家› 探索模型驱动开发(MDD)和相关思路方法(1)

探索模型驱动开发(MDD)和相关思路方法(1)

探索模型驱动开发(MDD)和相关思路方法(1)
探索模型驱动开发(MDD)和相关思路方法(1)

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

模型驱动的开发方法——基于面向对象的开发 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白皮书-模型驱动开发和UML+2.0

白皮书 模型驱动开发和UML 2.0 传统编程方式的终结? 本文档包含Telelogic AB专有信息。未经Telelogic AB书面许可,不得使用本文档内的任何信息,不得复印、影印本文档的任何部分。

前言 “模型驱动开发”——体会一下这几个词。它们说出了这个不断变化的工业中一个新的改变。这里不是说一种革命,而是一种缓慢的变化,但是肯定会渗透到我们开发系统的方式中。这种推动将降低代码的重要性,并且专注于一些开发中的真正事情:最终的应用程序被期望怎样工作,并确保你能够根据客户的需求可靠地建立起它来。 模型驱动开发是更伟大视景MDA中的一部分。MDA是模型驱动体系架构(Model-Dri ven Architecture)的简称,由对象管理组织OMG(Object Management Group)所驱动。M DA表示了一种模型驱动开发方法的概念框架。然而,尽管完整的MDA还没有成为现实,模型驱动开发现在已成为可能。实际上,它已以较低级的形式存在了较长一段时间,所以我们并不是在做某种新的东西(当然,除非你在听某些市场人员的宣传)。 没有魔法 如果模型驱动开发这么好的话,为什么不是每个人立刻加入到这个潮流中来呢?首先,模型驱动开发不是一个银子弹,能神奇地解决你所有的问题。总有某人需要去实现系统的功能,并且还找不到任何工具来完成这一点。所有你能发现的工具只是使这项工作更容易和直接一些。 第二,采用模型驱动开发,并不只是在开发项目的过程中更换一种工具。它还必须和已根深蒂固的开发过程结合起来(如果没有的话,你就可以开始使用模型驱动开发了;否则你就只能改善当前的情况),但实际上更重要的是,你还会担心它对现有应用程序的影响。决定改用基于模型的方法前确实需要有一些仔细的考虑,并且,一般说来,为了不影响当前的工作,你只会在新项目中改变开发方法。 第三,你还需要获得那些使用工具的人们的支持(你需要一些工具来应用模型驱动开发)。开发人员常会认为“模型驱动开发不是编程”而回避它,并且当心他们的工作难于被接受。他们还可能担心模型驱动开发将会使他们以前辛苦学来的一些技巧过时。他们的担心也不是完全没有理由。采用模型驱动开发后,市场确实很有可能会减少对那些精通好几种编程语言的开发人员的需求。但是另一方面,所有好的开发人员,首先和最主要的是,他们是问题的解决者。他们感兴趣的是尽可能地为手边的主要问题找到新的更好的解决方案。模型 第 2 页/共 2 页

MDA模型驱动开发方法学

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

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

相关主题
文本预览
相关文档 最新文档