mda-模型驱动体系结构-PPT

软件体系结构(SoftwareArchitecture)四、模型驱动的体系结构MDA(ModelDrivenArchitecture)•从西西弗斯说起——•现代版西西弗斯——项目进展内容•MDA简介•MDA开发过程•简单的MDA框架•MDA应用案例•完整的MDA框架•OMG相关标准MDA简介•ModelDrivenArchitecture–Model?客观事物的抽象表示–Model-Driven?使用模型完成软件的分析、设计、构建、部署、维护等各开发活动–Architecture?构成系统的部件、连接件及其约束的规约–MDA起源于分离系统规约和平台实现的思想–MDA的主要目标：portability,interoperability,reusabilityMDA简介•MAD产生背景–OMG标准化OMACORBA–OMG标准化对象建模技术UML,1995–OMG采纳MDA作为第二个软件框架,2001•MDA不是实现分布式系统的框架，而是在软件开发中使用模型的指导方法•MDA是从软件工艺迈向软件工程化的一步MDA简介•以机器为中心的计算•以应用为中心的计算不断提高的抽象层次MDA简介•以企业为中心的计算–基于构件的开发（CBD）–体系结构风格、设计模式–分布式计算–中间件：提升平台抽象层次、提升变成抽象层次–说明性规约（数据库、WYSIWYG）–企业体系结构和关注点分离（大型机、C/S、3-tier、n-tier）–企业应用集成（EAI）：集成遗产系统–契约式设计：建立可靠软件系统的方法–4GL（数据库访问、GUI生成）MDA简介•以企业为中心的计算面临的压力–应用的复杂性（B2Bi）–生产成本的压力（需求的变动）–质量的压力（文档、形式化）–软件生命期的压力（平台的易变性）MDA简介•将以模型为中心的思想引入EAI、B2Bi–模型作为开发制品，而非设计制品–模型富含语法抽象和语义抽象–结合WebService的应用–定义抽象的业务服务=〉将业务服务模型映射到WSDLMDA简介•OMG提出解决上述问题的有效途径—MDA–模型的角色–软件开发中的难点——分离关注点–模型是问题域的抽象，模型中的元素对应问题域中的概念–模型中使用客户熟悉的概念/术语描述问题，避免与计算机实现相关的细节问题–沟通业务和技术的有效途径–模型有不同的抽象级别，可以从高层抽象向底层模型进行映射MDA简介•MDA的体系结构图MDA简介•核心部分：OMG的建模技术——UML、CWM、MOF等，可通过UMLprofiles进行扩充，独立于具体平台•平台层：将独立于平台的模型映射到各平台，使用映射标准和工具自动或半自动的执行–平台相关的模型一般也采用UML表达，通过UML方言表达特定平台的元素–平台无关模型中的语法和语义信息被映射到平台相关的模型中•实现层：平台相关的模型被映射产生代码，使用工具自动或半自动的生成–平台相关模型中包含的语义信息越丰富，代码的生成质量越高–从平台无关模型到平台相关模型再到代码，体现一致性MDA简介MDA简介•互操作性–核心模型是平台无关的，便于向MDA中添加不同平台，只要增加模型到特定平台概念和元素的映射–相应的，平台元素之间的交互逐渐标准化，bridge、gateway、mapping等能够自动或半自动的产生–集成遗产系统，通过包装与核心模型一致的代码层，并且建立包装器的模型，与其他平台的交互可以通过映射机制生成，内部实现可以调用遗产系统完成，昀终集成到MDA框架中MDA简介•普适服务–业务系统一般依赖一组关键服务：目录服务、事件处理、数据持久化、事务、安全等–业务系统可能需要平台的非功能性属性：可扩展性、实时、容错性、环境限制等–在平台独立的模型中提供普适服务的支持，映射到平台相关的模型后再利用特定平台提供的服务–在平台独立的模型中，以高层抽象的形式看待服务；在平台相关的模型以及实现中，以本地代码的形式调用平台提供的服务MDA简介•标准化领域模型–OMG认识到领域模型的重要性，成立了DomainTaskForce，对特定领域市场所提供的服务和设施进行标准化–包括面向领域的平台独立模型、至少一个平台相关模型、接口描述文件MDA简介•MDA对企业计算的主要影响–再次提升编程环境的抽象级别–使用形式化模型驱动代码生成器–基于不同规约语言的元数据集成–在生成器中封装了设计模式的知识–形成按需生产构件的方式–使用DBC来驱动断言检测、异常处理和测试框架的生成–形成了“TheGlobalInformationAppliance”内容•MDA简介•MDA开发过程•简单的MDA框架•MDA应用案例•完整的MDA框架•OMG相关标准MDA开发过程MDA开发过程•传统开发过程带来的问题–生产效率问题：重视代码、维护软件时有问题–可移植性：技术更新换代快–互操作性问题：前端系统和后端系统–维护与文档问题：后期补文档MDA开发过程MDA开发过程•变换自动完成•相比传统软件开发过程–生产效率（模型是焦点、PIM开发者轻松）–可移植性（PIM到多个PSM的变换）–互操作性–维护与文档MDA开发过程•模型对开发过程的影响：允许定义机器可读的应用及数据模型，用以支持灵活的–实现：结合基础设施，由设计模型映射生成–集成：自动化生成平台之间的桥接器和连接件–维护：可以直接回到系统规约——模型阶段进行维护，然后向下生成系统–测试和模拟：模型根据需求进行验证，在基础设施之上进行测试，模拟系统的行为•此前，模型对开发人员来说只短暂存在而MDA中模型之间进行演化，相当于高层次的编译过程基本概念•Architecture:描述了软件开发中可能使用到的若干模型，这些模型如何建立，以及它们之间的关系•Viewpoint:为关注系统的特定部分而使用一套概念和规则进行抽象的技术–计算无关的视点：关注系统需求，忽略系统的结构和实现技术–平台无关的视点：关注系统如何操作，忽略特定平台的细节–平台相关的视点：关注系统如何利用平台进行实现•Platform:通过接口或模式提供一组功能的系统或技术的集合，使得使用平台的应用程序不用关心这些功能如何实现基本概念•ComputationIndependentModel:使用计算无关视点建立的系统模型–被称为领域模型或业务人员的词汇表–其用户是业务人员，不了解用以实现需求的建模技术–在业务专家和技术专家，业务需求和设计、构建方法之间建立桥梁•PlatformIndependentModel:使用平台无关视点建立的系统模型–表达了某种程度的平台无关性，适用于不同的平台上–通用技术是将模型建立在一个技术中立的虚拟机上，该“平台”提供的功能和服务可以在不同平台上实现•PlatformSpecificModel:使用平台相关视点建立的系统模型，将PIM中的规约联系到平台上如何实现模型变换•模型变换：将同一系统的一个模型转换为另一个模型的过程模型变换•基于元模型的变换•基于类型的模型变换模型变换•基于标记的模型变换•使用模式的模型变换模型变换•模型合并•使用附加信息的模型变换模型变换•对平台的理解内容•MDA简介•MDA开发过程•简单的MDA框架•MDA应用案例•完整的MDA框架•OMG相关标准MDA框架•模型：以精确定义的语言对系统作出的描述•精确定义的语言：具有精确定义的形式(语法)和含义(语义)的语言，以适合计算机自动解释•模型的表达能力–静态模型和动态模型–平台独立模型和平台相关模型MDA框架•变换(Transformation)：模型之间转换的过程–变换定义：一组变换规则，描述用源语言表述的模型–如何变换为用目标语言表述的模型–变换规则：描述源语言中的一个元素如何进行变换为目标语言中的一个元素•变换中的输入和输出–可在同一种语言中进行（重构、ER模型的规范化）–可在不同语言中进行（PIM到PSM）MDA框架•基本的MDA框架–模型：PIMPSM–语言：精确定义的–变换定义：变换规则的集合–变换工具：执行源模型到目标模型的变换MDA框架•小例子MDA框架MDA框架•MDA不要求特定的软件开发过程•和敏捷软件开发结合：模型被提升为交付软件的一部分•和极限编程结合：增量、测试、极限建模•和Rational统一过程结合：利用UML、既保持控制又提高•效率敏捷MDA•基于可执行的模型与代码在执行方面一致，敏捷人士提出了敏捷的MDA方法，即可执行模型以增量或迭代的形式被快速创建、运行、测试和修改•敏捷与建模的根本差距之一就是“确认的间隔”——不能执行的模型需要时间和人力转化为代码，模型的准确度、转化的正确性、客户需求的变化等因素使得昀终系统存在问题；敏捷方法强调短时间内交付小片的可执行代码，开发结果随时对客户可见，从而缩短了“确认的间隔”•敏捷与建模的差别并没有昀初看上去那么大，敏捷方法中的很多思想在模型的上下文中同样有效，只要将“代码”替换为“可执行的模型”•模型的语言更接近于客户，使其更容易与开发者交互和增量、迭代开发敏捷MDA•2001年，敏捷联盟成立，提出敏捷宣言–个体和交互胜过过程和工具–工作软件胜过可理解的文档–与客户协作胜过合同谈判–响应变化胜过追随计划•模型的三个层次–Sketch:表达系统设计的思想，不必精确和完整，便于理解和交流，应用广泛–Blueprint:描述构造实际系统的文档，将模型作为软件开发过程中的一阶制品，通过手动或自动化手段可以转化为实际系统，要求模型中包含足够精确的信息–ProgramLanguage:可以执行，经过编译和执行能满足用户各项需求，就像程序设计语言一样，“可执行的模型”敏捷MDA•设计时互操作总线：模型具有相同的元模型时，模型之间的连接非常简单，新增模型可以直接插在总线上敏捷MDA•敏捷：创建测试用例，编写代码，使用语言编译器编译代码，运行测试用例，不断向用户交付系统的片段•敏捷MDA：创建测试用例，编写可执行的模型，使用模型编译器编译模型，运行测试用例，不断向用户交付系统的片段，直接收到客户的反馈•可执行的模型vs.代码重量级相当•统一过程软件开发vs.极限编程重量级不同内容•MDA简介•MDA开发过程•简单的MDA框架•MDA应用案例•完整的MDA框架•OMG相关标准MDA应用案例•Rosa早餐服务系统：–提供早餐订购服务，有若干种套餐：如法式早餐、英式早餐等–客户可以在套餐基础上调整食物–记录客户信息以便得到配送信息和打折•设计决策：采用基于Web的三层应用MDA应用案例•Rosa系统PIMMDA应用案例•PIM到关系PSM的变换–每个类变换成一个表–当属性的类型不是基本数据类型而是类时，对应字段应该包含外键–设计到多重性问题，需要在多一端设置到另一端的关联；当多对多的情况，需要设置关联类MDA应用案例•PIM到EJBPSM的变换–粗粒度的构件模型：构件较大，交互频率较低，每次交互传递大量数据–EJB数据schema：一组类、属性、关联，在数据交互时它们被EJB构件作为整体来对待–EJB数据类：保存EJB数据，是数据模式的一部分–EJB数据对象：EJB数据类的实例–EJB主键类：保存用来区分EJB数据对象的数据MDA应用案例•部分EJBPSM–类=〉主键类–非组合成份=〉EJB构件和数据模式–类=〉数据类和归入数据模式–关联=〉EJB关联和归入数据模式–关联类=〉数据类和2个EJB关联–属性=〉数据类属性–操作=〉EJB构件操作MDA应用案例•PIM到WebPSM的变换•与EJBPSM的不同–Web模型的数据类型定义了用户表示和交互细节–Web模型中没有主键类，引用EJB中的主键类–增加了Web动作，定义昀终用户可以引发的动作•变换规则与EJB变换类似MDA应用案例•部分EJBPSM–非组合成份=〉构件和数据模式–类=〉数据类和归入数据模式，由昀外组合类生成–关联=〉关联和归入数据模式–关联类=〉数据类和2个关联类–属性=〉数据类属性–操作=〉web构件操作MDA应用案例•通信桥接器：关系PSM、EJBPSM、WebPSMMDA应用案例•关系PSM到代码–表CREATETABLE{…}–列CO