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

  引言  在同系列文章“实现模型驱动开发增加您 IT 系统业务价值”中您了解了模型驱动开发(model-driven developmentMDD)如何交付价值在本文中您将发现 MDD 如何支持架构驱动思路方法来进行开发

  MDD 概述

  在 MDD 中模型不仅用作框架或蓝图而且作为通过变换应用来生成有效实现所依据主要工件在 MDD 中当开发新软件Software组件时面向应用领域模型是主要焦点代码和其他领域工件是利用将来自建模专家和目标领域专家意见作为输入转换来生成

  定义架构和架构风格  IEEE 将架构定义为:

  软件Software系统架构(在个特定时间点)是通过接口那些由连续较小组件和接口组成组件交互重要组件进行组织或结构化  在软件Software架构开发方面我们投入了大量工作和专家经验架构反映了有关功能在系统中如何分布要使用哪些技术及要采用哪些设计模式决定

  架构包含了组架构原则和决定有时候这些架构原则被记录下来但常常推论原因却无从得知些情况下甚至没有对架构原则进行过充分考虑这导致了糟糕或不架构当然编写架构原则是个好主意但是如果您可以更进并以变更或引入架构原则会实际地改变系统架构方式获取它们会怎样呢?而且如果您能将那些同样原则应用于多个组件、服务和解决方案会怎样呢?这些优势是 MDD 所涉及

  在名为 Convergent Architecture: Building Model-driven J2EE s with UML 书中Richard Hubert 引入了术语 architectural style(架构风格) 来描述组可以重复地应用架构原则他将架构风格定义为架构家族:

  和公共原则和属性相关

  传达原则和思路方法从而最有效地实现设计构想

  MDD 还将架构风格自动化在 MDD 中不仅仅简单地将所实现解决方案架构原则、模式和转换编写为文档MDD 思路方法还要求明确地做出架构决策当获得了新理解时MDD 能够更容易地矫正不好决策当原则手工地应用于整个系统中时修改是很困难但如果在转换中获取并被自动地应用修改转换和再生成是较容易在做出最终决策的前尝试许多其他选择也是花费较少成本当通过重复地应用模式和转换以确定最佳匹配来验证解决方案满足非功能需求时该思路方法是有价值

  MDD 项目所采用架构风格是受很多原因影响它们包括:

  被开发软件Software类别(例如企业整合、实时嵌入、最终用户界面)

  要使用软件Software平台类别(例如消息传递中间件或基于规则系统)

  公认软件Software开发范例(例如面向服务或面向方面)

  软件Software领域(例如电信、金融或零售)

  系统或被开发系统架构原则

  架构风格范围(从整个行业到具体项目)

  软件Software开发组织机构风格(例如建模惯例)

  解决方案非功能需求(从服务质量到表现风格和现有基础架构)

  获取专家经验  许多 IT 项目都缺乏能够做出架构决策有技能专家这常常导致对关键角色过渡依赖缺少了他们将会使项目面临巨大困难

  MDD 个关键方面是专家经验获取和其每次需要专家在现场做出最佳实战决策到不如在自动模式和转换中获取他们专家经验这样您可以再次运用这些经验该思路方法让不具有专家知识开发人员能够构建成熟系统

  为了构建 MDD 框架您需要获取两个主要类型专家经验:逻辑(功能)架构经验和技术架构经验逻辑和技术架构经验都是整个架构风格部分

  逻辑架构经验

  解决方案逻辑架构涉及必须表现出来功能而不是利用特定技术实现功能方式当使用 MDD 思路方法时目标是在逻辑层建模并且生成实现工件

  在 MDD 中您定义出逻辑架构风格并且开发了支持该风格建模语言(Unied Modeling LanguageUML)概要文件、模式和建模惯例和定义逻辑架构相关许多专家经验是在 MDD 框架中获取并且在每次开发新应用时应用它们新应用设计师能够更多地关注问题领域并且在应用间通用软件Software架构些方面上少投入精力

  技术架构经验

  现代中间件平台为了支持那些构建在其上各种应用提供了丰富特性然而单个项目经常使用那些功能子集并且它们以专门方式来使用这些子集

  个特定项目(或计划)利用其所选择中间件平台方式确定了技术架构在最佳实战文档中可以获得技术架构或者可以将技术架构从开发人员传递给其他开发人员实际上当处于手工过程中时很难确保技术架构被致地应用

  MDD 向您提供了直接实现技术架构机会和其在文档中记录例如“对所有公共思路方法入口和出口都将利用 log4j 来记录”到不如您实现个转换来根据该规则生成日志代码 MDD 思路方法点好处是让您集中在项目较早时期并且更彻底地考虑技术架构如果您开始就了解到这点并且分配了充足时间来定义技术架构那么这将会带来实在收益并且在项目后期节省您很多时间

  了解模式  在 MDD 中您利用具体领域概念来建模例如在企业整合领域中您可能会用到消息、代理和适配器应用领域词汇中还常常包含模式在企业整合领域中您可以保证交付和发布订阅模式这些模式不是单个元素而是引入元素和对其行为约束的间关系

  (建筑)架构师 Christopher Alexander 在其著名 Timeless Way of Building 中引入了模式语言概念想法模式作为般设计问题最佳实战思路方法已经得到软件Software团体广泛采纳他引入了模式语言概念他将其定义为可以起为特定环境或问题领域中设计提供词汇组相关模式

  在后继卷A Pattern Language 中Alexander 介绍了拥有面向城镇设计(目标为计划者)和建筑物(目标为架构师)子语言以及面向构建(目标为建筑者)子语言具体模式语言

  Alexander 模式例子是:

  城镇模式 环形路、夜生活和连排房 建筑物模式 屋顶花园、室内日照和避暑别墅 构建模式 好材料、支柱连接及半英寸装饰   每个模式都包含它所适用环境信息以及它和其他模式关系Alexander 解释说当使用模式语言时“我们总是将其用作顺序经历模式总是从较大模式转移到较小模式总是从创建结构到修饰那些结构再到修饰那些装饰模式

  模式语言想法就像适用于适用于建筑物架构也适用于软件Software开发而本文始终在使用该术语软件Software开发特点意味着额外地将用模式语言进行设计过程自动化是可行

  就像用 Alexander 思路方法您可以通过从较大模式转移到较小模式来设计软件Software系统如图 1 所示需要人专家经验来选择设计环境中适当软件Software模式

  图 1. 模式级别

探索模型驱动开发 (MDD) 和相关思路方法(2)   当把模式应用于软件Software时有了个额外好处:可以将模式应用自动化以便当选择模式时可以用所有和该模式相关结果展开设计个简单软件Software模式例子是 Getter/Setter 模式在该模式中总是通过致命名操作来访问属性该模式可以自动化以便将模式应用于类 Customer 属性名向 Customer 类添加名为 getName 和 Name(以及恰当参数)操作

  通常将建筑物物理构建自动化是不可能然而软件Software系统是用根据实现模式自动生成信息工件构建建筑者必须手工地应用构建模式而软件Software架构师可以充分详细地描述软件Software实现模式使在已知具体应用环境时候生成这些模式

  如您在图 2 中所看到依据所选择模式和技术架构原则详细系统模型可以转换为组运行时工件(源代码、部署描述符等等)例如如果您使用了 Getter/Setter 模式模型那么您可以针对具体平台例如 Java™根据该平台实现模式为那些思路方法生成实现代码在某些情况下您可能会使用直接实现了应用模式实现模式在其他情况下您可能要应用多个较低层次实现模式来实现应用模式

  图 2. 转换

探索模型驱动开发 (MDD) 和相关思路方法(2) 结合模式和 MDD  模式 和 MDD 互补性是架构驱动开发关键模式和 MDD 以下面两种重要方式相关联:

  MDD 可以将模式应用自动化   传统上模式是以文档形式记录下来UML 常常帮助介绍说明模式然后手工地应用模式

  模式为 MDD 提供内容   MDD 让您从设计良好模型转移到设计良好实现上模式在建模和实现层获取最佳实战在不了解应用领域模式和实现领域模式情况下MDD 是不可能

  软件Software模式可以在抽象层(例如设计模式和实现模式)中应用并可以跨抽象层(将设计元素和代码相关联模式)应用您可以将模式组合起来为解决较大问题生成复合模式并为覆盖领域最佳实战生成模式语言

  当使用本文中介绍架构驱动思路方法来开发时系统设计就如图 3 所显示那样进行

  图 3. 架构驱动思路方法

探索模型驱动开发 (MDD) 和相关思路方法(2)   活动顺序不意味着在下步开始的前必须完成这个步骤我们可以使用迭代思路方法通过多次经过这些步骤每次添加些功能来构建解决方案

  利用 IBM 电子商务模式复用资产  利用模式和 MDD 互补性利用架构驱动开发思路方法项目成功依赖于模式和 MDD 框架质量您必须确保将覆盖了商业、应用和运行时层模式语言自动化同时当应用每个模式时提供服务和行为预期质量定义IBM 电子商务模式提供了每个层次上模式可以让您从中选择特定模式(根据我们解决方案需求)来构成您模式语言

  IBM Patterns for e-business 可以帮助简化资产复用通过使未来合约更简单且更快方式来获取 IT 架构师经验对这些资产复用节省了时间、金钱和工作量并且帮助确保坚固、构架恰当解决方案交付IBM 电子商务模式是获取并发布被使用、测试、并证明是成功电子商务工件假定所获取信息符合大多数或 80/20 情况通过最佳实战方针及相关链接IBM 电子商务模式在进发展

  分层资产模型

  电子商务模式思路方法让架构师通过复用来自已证实成功经验组件和解决方案元素来实现成功电子商务解决方案模式思路方法是基于组任何现有开发思路方法都可以使用分层资产构建分层资产以便每个详细层次构建于前层次的上这些资产包括:

  商业模式 确定用户、企业和数据的间交互 整合模式 当不能提供根据单个商业模式而来解决方案时将多个商业模式连在 组合模式 表现为通常出现商业模式和整合模式组合 应用模式 提供描述了商业模式或整合模式的中应用组件和数据如何交互概念上布局 运行时模式 定义了支持应用模式逻辑中间件结构   运行时模式描述了主要中间件节点、它们角色和这些节点的间接口

  产品映射 为每个运行时模式确定已证实并测试过软件Software实现 最佳实战指导方针 用于电子商务应用设计、开发、部署及管理   参见图 4观察可视化表示

  图 4.

探索模型驱动开发 (MDD) 和相关思路方法(2)   模式和 MDD 是填补商业和 IT 的间鸿沟并确保商业价值交付关键模式及 MDD 采用:

  减少了响应时间

  使随需设计和开发成为可能

  减少复杂性

  模式和 MDD 已经成熟并且正交付着切实结果   META Group(现在是 Gartner Group 部分) Thomas Murphy 所说“使用模型驱动、基于模式开发框架和工具组织可以获得开发团队(Team)中引人注目生产力和质量提高”得到广泛引用

  MDD 促进了商业灵活性提高这是在不断地随需应变世界里取得成功关键模式驱动开发、IBM 电子商务模式和 MDD 成功是这些技术互补性结果

  IBM 电子商务模式是分层、可复用、整合且已证实模式它向 MDD 思路方法提供了质量输入MDD 通过将电子商务模式自动化来增大它们可复用性所以它们可以很容易地被再应用电子商务模式在创建企业级 MDD 框架时提供关键内容这些框架对于跨企业中 IT 系统获取并实现公共架构风格是特别重要

  系列文章 随需构架解决方案 第 11 部分很好地介绍说明了此概念它使用了个例子在该例子中IBM 电子商务模式向 MDD 框架提供输入用于生成基于消息传递模式企业服务总线(Enterprise Service BusESB)组件

  整理总结  在本文中您了解了如何用模式和 MDD 组合来进行架构驱动开发这样可以明确地获取架构决策并且在系统中对架构决策自动化编码您还探究了实现架构驱动思路方法好处

Tags:  驱动精灵 深入探索c对象模型 深度探索c对象模型 模型驱动

延伸阅读

最新评论

发表评论