没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
多年以来,采用模型驱动开发(MDD)的水平似乎仍没预期的那么好。阻碍、
限制 MDD 使用的因素有很多,例如对实际的 MDD 成功案例缺乏认知、不确定
如何在平常使用 MDD、缺少预先投资的拨款模式、或是没有战略举措的重点。
如果你过去尝试过 MDD,那你很可能遇到了一些挫折,导致你现在不再用
它。也或许你正在尝试采用 MDD,而又面临着一些挑战和阻碍。无论你遇到上
述哪种情况,本文都对你有所帮助。我们会在本文中看一看与采用 MDD 相关
的挑战和误解[1]。
建模早已证明了它在改善沟通、促进业务编排、提升质量、提高生产率上
的价值。它的使用范围很广,分析、设计和开发都会有所涉及。考虑到这一点,
我们就来看看有关 MDD 的诸多误解和挑战,我们又该怎样利用现代方法和相
关工具集解决这些问题。
1 - 挑战:方法不当且不可用
过去,MDD 的一个关键抑制因素是人们实施活动的时候没有现成的 MDD
最佳实践。比如说,人们在阅读有关如何执行特定任务(诸如设计高可用的解
决方案)的过程文档时,文档里并没有任何 MDD 的内容。为了得到 MDD 实践,
人们不得不到论文或书本里去找,然后再应用到现有的非 MDD 文档上。
如今,MDD 从业者在进行日常工作时,可用的 MDD 指南已经越来越多,
而且那些信息嵌在他们每天使用的工具中。我们先看看开发过程,它包括利用
MDD 原则的“工具向导”最佳实践,这些“工具向导”隶属于整个方法和过程。
特定任务的指南(例如需求评审、设计用户接口或设计高可用的解决方
案)现在都包含指向 MDD 内容的链接。比如推荐设计模式、提供设计中应用
模式的指南、利用现成工具中的模式实现。
以前还有另一个阻碍因素,就是 MDD 与特定开发方法过度掺杂,人们无
法提取 MDD 最佳实践,并将其应用到不同的场景中。一个典型的例子就是面
向 对象分析和设计(OOAD)中存在大量工具,你要么采用全部的 OOAD 内
容,将其作为从 MDD 受益的一部分内容,要么就完全抛弃 OOAD。MDD 的
最佳实 践曾是 OOAD 框架的一部分,但人们并不知道如何在框架之外利用这
些最佳实践。抽取出 MDD 的内容并将其应用到不同的场景中是不可能的。
这些因素再加上其他一些原因导致企业很难在它们的环境里采用最佳实践
(包括 MDD 最佳实践)。公司已经有了合适的过程和方法,而给这些方法添
加 MDD 方面的内容却很困难。
为了在组织和特定类型的项目中采用 MDD,业界在裁剪特定开发过程方面
已经做得越来越好。比如有的研讨会旨在指导团队完成定制的开发过程,这通
常被称作“方法采用研讨会”。研讨会的目的是针对特定项目裁剪现有的方法内
容,它通常会涉及以下人员:过程工程师(管理组织开发过程的人)、首席架
构师、 开发人员组长和项目经理。
支持定制后,方法工具浮出水面,比如 Rational Method Composer 和
Eclipse Process Framework Composer,它们包含定制的最佳实践库。这
些工具的思想是整理、打包最佳实践,用工具为组织裁剪并采用这些最佳实践。
在工具中,你选择想要采用的某 些方法元素,对它们进行修改、编辑,并将其
组织成希望关注的过程。然后将该过程以可读格式(例如 HTML)在组织内发
布,供从业者在日常工作中遵循。
尽管使用上述工具和方法的可用指南有很多,但仍然要求用户找到、理解
并遵照指南。跨越这一障碍的措施是,除了在工具里提供指南之外,还要将方
案 的全面自动化。举例来说,你能在使用基于 Eclipse 的产品时利用备忘单
(Cheat Sheets)。备忘单提供完成任务的步骤指南,并能自动化工作流里
的步骤。
下一节我们会讨论关于模式实现的机制。不管选用什么方法,要点都是获
取越来越多的指南,并将其落实到工具中,从而更好地指导用户充分利用模型。
正如软件解决方案可能会过度工程化一样,创建指南也会发生同样的问题。
克服这个挑战的最后一点是要务实、主动。计算出构建方案所需步骤的全部细
节,无论从价值来说还是从时间来说都没有什么意义。那关键的步骤是什么呢?
他们如何与团队的技术相结合?在文档化步骤上投入时间的意义何在?相对于
自动 化,在创建静态文档上又该投入多少呢?
过程,尤其是 MDD,都不是放之四海而皆准的,这将在“4-误解”中讨论。
2 - 挑战:基础设施和工具不能从 MDD 获益
近几年,我们看到建模工具已不局限于对特定图形符号(比如 UML)的支
持了,经过发展,它已然能帮助从业者完成工作。这些工具不仅支持图形建模
符号,也内置了 MDD 特性,这些特性有利于:
业务编排:业务编排是 SOA 等成功方法的关键方面。通过使用 MDD 模
型、自动化、以及与之关联的“追踪”,你能记录决策的原因,跟踪满足
业务需求 的所有方式。另外,我们可以研究利用 MDD 的特定版本,比
如业务驱动开发(BDD)。顾名思义,BDD 关注的是业务建模。你可
以在这种情况下进行建模,也 可以在某些情况下模拟组成业务的流程。
高质量:由于实践内建在工具中,并进行了自动化处理,因此出错的几
率非常小,甚至不会出错。
增强的一致性和治理:由于工具支持指南和最佳实践的自动化,所以提
高了解决方案中元素的一致性。另外,工具也能确保构建的元素是固定
的,并与需求和最佳实践保持一致。
提高的生产率:重复、耗时的工作现在都自动化了。从业者可以“复用”,
把时间花在最紧要的事情上(比如业务逻辑)。依赖自动构建,用户群
的复杂度和自动化要么可以在当前项目中实现,要么可以分散在多个项
目中实现。
改善的沟通:使用模型、工具和自动化,从业者(例如架构师)能针对
不同的受众创建不同的视图。
影响分析:MDD 的可追踪性能让你分析出需求变更对解决方案造成的影
响,反之亦然。
让我们以设计模式为例,来说明工具如何给 MDD 带来了活力。假设某本
书中描述了设计模式,我们将其称为模式规范。该规范非常有用。它描述了模
式 的使用时机、模式的特征,以及使用模式的好处和意义。模式规范能帮助人
们理解模式并做出恰当的选择。但模式规范并不能确保设计的高质量和生产率
的提高。为 了从中受益,你必须将这些模式“自动化”。我们将其称为模式实现,
也就是模式规范在工具中的可复用编辑。使用模式实现,设计者可以将模式快
速应用到他们的 设计中,也能确保这些应用准确无误。
领域独立的工具不太可能内置领域所需的所有 MDD 工件。工具除了提供
开箱即用的 MDD 工件外(比如一组设计模式实现),也允许你扩展现有的工
件、创建自己的工件。现在的工具包含“扩展框架”,以及最佳实践、模板和
API。Rational Software Architect 之类的工具还允许你构建适用于领域的
MDD 工件(例如模式实现、规则、约束等)。
既然你能构建这些 MDD 工件,那么基于资产的开发(ABD)就能让你与
他人共享工件、提升复用的实践和基础设施。换句话说,ABD 最佳实践和基
础设施的改进支撑了 MDD 的采用进程。诸如 Rational Asset Manager 的可
复用资产库能让你管理可复用的软件工件,让开发社区共享和复用工件。试想
一个为领域创建的模式实现,你现在可以把它提交到资产库中,该 模式经过评
审和认可,社区中的其他从业者就可以复用它了。作为这个生态系统的一部分,
你可以监控资产被复用的时机和方式,收集反馈信息并确保整个团队在使 用合
适资产的正确版本。
我们重新回到务实和实用上来。在对用户和用户所在组织有意义的情况下,
ABD 及复用倡议才需要被采用。你需要识别出你的成熟度级别,并采用支持该
级别的工具和过程。通过事先思考和计划,你可以随需确定、推广 ABD 计划,
避免不必要的开销和成本。
3 - 误解:MDD==UML?
有一个误解是 MDD 意味着你必须使用统一建模语言(UML)——现状如
此,完全是因为来自对象管理组织(OMG)的 UML 规范进行了这样的描述。
消除这一误解的方法有很多。
剩余10页未读,继续阅读
资源评论
lee8400
- 粉丝: 0
- 资源: 61
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 基于python开发使用深度学习去预测股票后续的价格+源码+文档(毕业设计&课程设计&项目开发)
- flowable-designer-5.22.0.zip
- threadmanager.cpp
- 腾讯云小程序 - 一站式开发与部署平台
- 基于JSP+Java+Servlet采用MVC模式开发的购物网站+源码(毕业设计&课程设计&项目开发)
- fastgestures安装包,模拟mac的触控板收拾,两指代表右击, 三指拖拽
- 基于组态王的升降式横移立体车库控制系统+源码(毕业设计&课程设计&项目开发)
- 基于python+Django和协同过滤算法的电影推荐系统+源码(毕业设计&课程设计&项目开发)
- 环境配置 vscode+jupyter
- 项目全部代码,还包含使用到的图片
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功