位试图增加 IT 系统业务价值
领头架构师或项目经理(project manager)吗？如果您是
本文可以为您提供帮助
本文解释了影响现代 IT 开发业务推动力并且向您介绍了模型驱动开发(model-driven developmentMDD)MDD 是主流软件Software开发实战提高并且让您 IT 系统能够对业务推动力更加敏感了解 MDD 思路方法以及您如何可以将其应用于实现业务价值最大化并且减少解决方案开发成本利用 MDD通过利用转换和重复性消除将实现模式自动化并将低层次开发工作自动化您可以提高解决方案致性和质量了解您目前
业务环境 IT 开发不会孤立出现IT 目是简化业务运作这意味着业务环境需求推动着我们开发 IT 思路方法表 1展示了些当前业务推动力表 1. 当前
业务推动力推动力 描述
随需应变
业务 由于商家应该更具适应性和灵活性所以 IT 系统要做得太多了 业务关联 大家强烈关注 IT 部门交付业务价值
软件Software必须是和业务相关业务及 IT 人员的间
传达会导致从 IT 交付观点看成功项目被视为业务上失败 成本控制 根据承诺
力度对 IT 投资时代早已过去现在IT 部门在强大预算约束下运作并且应该证明其金钱方面价值 不断增加
复杂性 软件Software系统在规模和复杂度上不断增加从而满足业务需要对小规模开发有效技术不定适用于按企业级计划 技能可用性 当今 IT 平台
成熟意味着交付软件Software需要专家经验许多组织努力寻找着有充足技能专业人员支持它们开发项目常常依赖于些关键人物如果这些人离开了损失会很严重 变化
中间件环境 现今应用
都部署到极为多样中间件平台上平台技术变更率没有表现出减慢迹象商家希望利用中间件中先进技术但不愿意重复地编写它们应用 了解软件Software开发
模型驱动思路方法 模型驱动开发(Model-driven developmentMDD)是软件Software开发种样式其中主要软件Software工件是模型根据最佳实战可以从这些模型生成代码和其他工件模型是从特定角度对系统进行描述它省略了相关细节因此可以更清楚地看到感兴趣特性例如结构工程师会创建适合于确定建筑物承载特性模型在 MDD 中
我们引入了附加标准即模型必须是计算机可读例如我们必须能够以自动化方式估计模型内容模型计算机可读性是它能够生成工件必要条件白板上图也许满足作为模型其他标准然而直到我们以计算机可读方式获取它时才能够在 MDD 工具系列中使用它软件Software模型
般用统建模语言(Un
ied Modeling LanguageUML)表示UML 是用于介绍说明、可视化并文档化软件Software系统语言它为软件Software模型提供了可视化表示和基础语义UML 还拥有用来确保自动化标准化计算机可读序列化格式软件Software模型隐藏了技术实现
细节因此我们可以利用来自应用领域中概念来设计系统应用般是利用 UML 建模工具例如 IBM Rational® Software Architect并使用和应用领域相关概念进行设计例如当我们工作于企业集成领域中时我们会利用消息、代理和适配器这样概念为应用设计建模随后我们可以精练该软件Software模型并且为其组件设计详细内容作为示意图和蓝图
模型利用模型来设计软件Software是
个公认实战(尽管确不普遍)目前模型大多用于通俗地传达系统某个方面示意图或用于描述您手动实现详细设计蓝图将模型作为文档和规范标准是有价值
但是这需要严格规程来确保模型和实现进度保持致通常时间约束意思是在没有首先变更模型情况下对实现进行了更新不准确模型比没有模型更有害在本文中
我们用术语 MDD 来表示由模型自动生成工件思路方法利用准确
模型进行自动生成在 MDD 中
模型不仅用作示意图或蓝图它们还作为通过转换应用生成有效实现主要工件在 MDD 中当开发新软件Software组件时首要焦点是面向应用领域模型代码和其他目标领域工件是利用由建模专家和目标领域专家参和所设计出转换来生成MDD 能够极大地减少解决方案开发
成本并且提高解决方案致性和质量这些好处是通过自动化带有转换实现模式来形成它消除了重复低层次开发工作在构建解决方案工件时和其重复地手动应用技术经验不如将这些经验窍门技巧直接编入转换中并且还带来致性和可维护性优势修改了转换可以快速地重复应用用于生成反应出对实现架构做出变更解决方案工件MDD 将应用
开发重点从平台上移开让具有应用开发经验开发人员在不用关注具有平台经验开发人员领域中平台级概念情况下设计应用平台经验直接在转换中获取而不是编制为项目指导或者更糟是在项目进行过程中重新去多次发现同样有关实现架构决策也直接编入转换中而不是编制为架构决策文档根据情况
区别合适成品转换会用于直接使用或者作为扩展基础另外您可以为项目构建定制转换不仅是代码
虽然代码和其他平台工件
生成是 MDD 重要部分但是 MDD 样式自动化有更深意义软件Software开发项目需要生成许多非代码工件其中些完全或部分地来源于模型以下列表提供了些由模型生成通用工件例子但您可以考虑其他文档 在遵照正式
开发思路方法组织中生成文档用去了大量开发精力将文档和实现保持致出了名困难当使用 MDD 时文档由模型生成它们确保了致性并且使开发人员日常处理模型中信息可用比在很难将信息定位文档中要好工具例如 Rational SoDA 和 Rational Software Architect Report Generator (参见 参考资料)可以生成文档或者文档由转换来生成 测试工件 由软件Software模型中所包含信息生成基本测试例如利用 JUnit是有可能如果执行了额外具体到测试建模(例如利用 UML Profile for Testing)那么就可以生成完整测试实现基于模型测试是有关由模型生成测试规程 构建及部署脚本 基础结构架构师利用他们经验可以创建生成构建及部署脚本转换 其他模型 个系统中会涉及到许多区别抽象层次上(分析、设计、实现)相互依赖模型它们代表系统区别部分(UI、数据库、业务逻辑、系统管理)、区别关注点(安全性、性能及可靠性)或者区别任务(测试、部署建模)在许多情况下由个模型部分地生成另个模型是有可能例如从分析模型到设计模型或者从应用模型到测试模型 模式应用 模式获取最佳实战解决方案来重现问题模式指定模型元素特性以及那些元素的间关系您可以将模式自动化以便创建新元素以及修改现有元素来遵照该模式然后将模式应用于模型中 在本文中我们介绍了所有这些技术除此的外还有利用 MDD 进行代码生成为 MDD 项目估计任务 MDD 对我们构建业务应用软件Software
方式有着深远影响它获得了顶级技术人员经验及决策通过为项目需求所定制工具使余下团队(Team)可以获得这些经验和决策由于大量低层次编码工作已经自动化了所以开发成本以及测试业务软件Software成本极大地减少了数量减少了并且在工作完成方式上增加了致性然而
MDD 确实创建了项目区别面需要管理个项目中另个项目内部工程包含了 MDD 工具开发这些工具可以供开发团队(Team)在外部项目中构建业务应用时使用般来说开始要将个业务应用确定为利用 MDD 工具构建着重于需求并且可以对该思路方法进行些调整第个项目旦开始开发了就可以将 MDD 工具用于构建许多业务应用了对于两个项目
谨慎地组织和计划是非常重要特别是在开始时候在和开发项目相关平常问题的上存在着管理额外内部依赖集需求MDD 工具需求必须在应用开发人员需要它们的前进行确认和开发两个项目任务流要互相联结这样可以确保由 MDD 工具项目而来交付产品是及时图 1 展示了 MDD 项目中
任务流阴影任务可能在传统项目中执行白色任务是为具体项目构建 MDD 工件附加任务图 1. 开发 MDD 工件
步骤
您可以在业务应用
开发的前开发所有工具或者利用更加迭代“准时制(just-in-time)”思路方法不论采用哪种思路方法重要是在业务应用项目开放过程中允许有额外时间来开发被确定为第次使用工具增强任务
开发 MDD 工具
最初任务出现在所有传统开发思路方法中您解决方案架构师执行了这些任务并且定义了业务应用高层结构 创建解决方案架构 定义业务应用
概念结构这可以表示为在构建业务应用时开发人员将要采用许多架构风格 定义运行时环境 定义业务应用运行所处运行时环境这包含所有测试环境其中包括单元测试和最终产品环境 旦开始两个任务完成了解决方案架构师就会很好地了解了为业务应用开发什么需求了到此具体到 MDD 任务可以开始了: 确定通用
模式和标准 解决方案架构师确定出在业务应用中重复模式这些模式经常出现是由于架构风格致使用或者由于运行时平台需求通用模式可以利用对组织开发过程来说标准方式进行描述 确定用于复用现有 MDD 资产 解决方案架构师比较他们用现有 MDD 资产确定出通用模式对他们架构做出任何必要小调整从而使用已经可用内容现有 MDD 资产可以来自先前 MDD 项目或者来自标准工具和包 定义设计模型 解决方案架构师定义开发人员在开发业务应用时必须依据建模规则般开始会选择 UML且解决方案架构师会更精确地定义如何利用 UML 来获取设计解决方案架构师需要了解区别类型 UML 图(例如类图、协作图、活动图)以及什么时候适合使用哪种 确定独立于运行时组件模型 该任务创建了个 UML 模型定义该模型以独立于运行时方式为业务应用指定了组件该任务可以由解决方案架构师执行或者由了解所有运行时环境有经验应用开发人员执行 生成举例工件 应用设计人员为典型场景手动编制结果业务应用工件这些举例工件是作为 MDD 模板和转换蓝图该任务应该由您最佳应用设计人员执行 确定工具系列 该任务确定了开发项目所需 MDD 工具该任务是由掌握 MDD 工具开发人来完成旦完成了该任务您就可以创建构建 MDD 工具所需工作详细计划了 接下来 5个任务构建了 MDD 工具: 从举例工件中抽取模板 MDD 工具开发人员审阅举例工件
并且将它们用作为每个待生成工件开发模板基础模板包含了对于已生成工件每个例子都相同代码MDD 工具开发人员需要掌握已生成工件语言和格式方面技能它还包含转换所使用根据模型内容插入工件具体部分时所需标志 设计、代码、测试转换及模式 该任务需要 Java 设计能力对于每个转换或模式MDD 工具开发人员需要书写阅读 UML2 模型 Java 代码然后更新模型或者对模板进行适当填充生成新工件 包装 MDD 工具 MDD 工具必须打包成可以安装到每个人或您应用开发人员工作台中形式这里有些选择: 根据打包指导将所有文件放入 zip 文件中 使用标准
Eclipse 插件管理 使用可复用
资产(reusable as
RAS)存储库 提供完整
下载 Web 站点 该选择依赖于可能安装 MDD 工具
人数种合理思路方法是着重于支持您最初应用开发人员然后当更多人开始使用它时按照需要升级打包机制 为应用开发人员生成文档及培训资料 解决方案架构师或技术作者介绍了应用开发人员如何构建模型并且选择恰当转换来生成正确工件 利用关键场景来验证工具系列 这个最后 MDD 工具开发任务是个测试角色MDD 工具建模并生成每个运行时平台所需所有工件来支持些关键场景 现在已经准备好 MDD 工具让应用开发人员开始使用了: 培训应用
开发人员使用 MDD 工具 在使用 MDD 工具的前告诉应用开发人员新开发过程是如何工作他们需要了解什么时候以及如何使用 MDD 工具并且还要知道这些工具如何配合他们传统工具例如配置管理 开发业务应用 到此应用开发人员使用 MDD 工具来构建业务应用 MDD 工具系列图 2 中
流展示了开发人员如何能够利用 MDD 工具开发部分业务应用在此例子中开发人员审阅了业务问题并且选择了设计模式该模式部分地填充了设计模型而开发人员填写他们正在构建具体业务功能细节此后开发过程就完全自动化了开发人员选择项来生成工件这些工件被打包并放入构建区然后开发人员可以选择更多选项为个别运行时平台生成附加工件图 2. MDD 工具链
好处 MDD 拥有极大地提高当前主流软件Software开发实战
潜能表 2 展示了 MDD 思路方法优点表 2. MDD 好处
好处 介绍说明
增加了
生产力 通过由模型生成代码和工件
方式减少了软件Software开发成本同时增加了开发人员生产力您必须考虑转换开发(或购买)成本但谨慎计划可以帮助确保成本整体减少 可维护性 许多解决方案组件是使用遗留平台技术实现
但组织不再掌握这方面技术了MDD 形成了可维护架构在其中可以快速致地做出变更可以将组件更有效地移植到新技术上 高层次模型和不相关实现细节无关这使得处理底层平台技术及其技术架构中变更更加容易您可以通过更新转换来变更实现技术架构转换被重复地应用于原有模型用于生成依据新思路方法实现工件您可以在做出最终决策的前尝试区别
想法不好决策很容易变更人们经常按照决策继续进行软件Software项目而成本过高难于修复 遗留系统
复用 贯地在 UML 中为现有遗留平台建模如果有许多组件是在同个遗留平台上实现那么您可以开发从组件到 UML 逆向转换您可以将组件移植到新平台上或者生成包装器(wrapper)通过集成技术例如 Web 服务来访问遗留组件 适应性 由于已经在自动化方面进行了投资
因此添加或修改业务功能就是很简单了当添加新业务功能时您只需要开发针对该功能行为生成实现工件所需剩余信息可以在转换中获取 致性 手动地应用编码实战以及架构决策是容易出错MDD 确保致地生成工件 可重复性 当在
或组织层应用时MDD 尤其强大来自开发转换投资回报在每次复用时都有所增加使用经过试验和测试转换还增加了开发新功能可预测性并且减少了风险
架构和技术问题已经解决了 改进了涉众
交流 模型省略了和了解系统逻辑行为无关实现细节它们更接近于问题领域减少了涉众所了解概念和表示解决方案所用语言的间语义差异简化了和业务目标更好地结合解决方案交付 改进了设计
交流 模型帮助您在设计层上了解系统引出了对系统改进讨论和交流模型是系统定义部分比起文档它们从不会过时而且是可靠 经验获取 项目或组织经常依靠重复地做出最佳实战决策
重要专家他们经验可以在模式和转换中获得因此他们不需要直接面对项目其他成员而且有了伴随转换充足文档即使当专家离开时组织经验仍旧保留在模式和转换中 模型可以作为
长期
资产 模型是获取组织 IT 系统功能重要资产高层模型对最新平台级上变更具有弹性它们只在业务需求变更时才发生变更 推迟
技术决策
能力 早期应用开发针对建模活动您可以推迟具体技术平台或产品版本选择直到有更多信息可用时再选择在出现极其长开发循环(例如航空交通管制系统)领域中这是至关重要在开发开始时目标平台可能还不存在 整理总结 本文阐述了
您能够如何利用 MDD交付改进来自 IT 业务价值像所有工具或技术样MDD 可以很好地应用或不好地应用MDD 拥有生成本文中概括好处能力但该思路方法必须有效地应用本文中
信息是基于作者 MDD 行业应用中经验集还是同样作者在 IBM 红皮书 Patterns: Applying Model-Driven Development with Rational Software Architect中更详细地介绍了该主题它包含详细案例研究并且介绍了如何利用 IBM Rational Software Architect 来执行 MDD 项目任务利用红皮书中实战将极大地提高 MDD 项目成功机率
最新评论