用 Rational Software Architect 进行模型驱动和基于模式的开发.docx
《用 Rational Software Architect 进行模型驱动和基于模式的开发.docx》由会员分享，可在线阅读，更多相关《用 Rational Software Architect 进行模型驱动和基于模式的开发.docx（30页珍藏版）》请在冰豆网上搜索。
用RationalSoftwareArchitect进行模型驱动和基于模式的开发
用RationalSoftwareArchitect进行
模型驱动和基于模式的开发
第1部分:
使用模式的模型驱动开发范例的概述
简介：
模型驱动开发（Model-drivendevelopment，MDD）是软件开发的一种样式，其中主要的软件工件都是由代码和其他工件所生成的模型。
其目标是提高企业应用程序开发的生产力和质量。
模式在MDD的模型转换和代码生成中扮演重要角色。
本系列文章详细地讨论了利用IBM®Rational®SoftwareArchitect（支持MDD的集成开发环境）进行模型驱动及基于模式的开发范例。
内容
∙引言
∙使用RationalSoftwareArchitect来应用MDD
∙UML模型
∙转换
∙模式
∙从业务问题到软件解决方案
∙使用带有模式的MDD的好处
∙经验教训
∙总结
∙参考资料
∙关于作者
∙建议
引言
模型驱动开发（Model-drivendevelopment，MDD）是由模型驱动体系架构（Model-drivenArchitecture，MDA）技术支持并驱动的新软件开发范例，是对象管理组织（ObjectManagementGroup，OMG）发布的软件设计方法。
MDA提供一组指南，用于构建表示为模型的规范，从独立于平台的模型（platform-independentmodel，PIM）开始，通过适当的具体到领域的语言，然后转换为用于实际的实现平台的一个或多个具体到平台的模型（platform-specificmodels，PSMs）。
它可以是很多种平台，例如Java™2Platform、EnterpriseEdition（J2EE™）、CORBA或.Net，以通常的程序设计语言实现，例如Java™、C#和Python。
MDA通常用自动化的工具来执行，如IBM®Rational®SoftwareArchitect。
MDD由MDA驱动，并更着重于模型转换和代码生成。
然而，MDD所使用的基于代码生成的方法有它不利的方面，这是由于例如所生成代码中的约束、技术不强的开发人员和与模型的紧耦合等因素造成的。
当企业100％地投入到代码生成中时，就没有余地进行调整了，尤其是在开发人员仔细检查其模型的时候。
基于模式的开发方法能够帮助解决该问题。
模式是在已知环境中重现问题的解决方案。
模式将设计人员的时间、技能和知识进行萃取，从而解决软件问题。
此外，当模式在许多不同的项目中重复地使用时，它就成为了最佳实践。
通过设计特殊的设计模式，开发人员可以更灵活地控制所生成的代码，这就不简单地拘泥于抽象模型了。
而且，MDD可以通过转换自动化地实现模式，这将排除重复的低层次开发工作，并且可以将技术性的专家经验加入到代码中，以提高一致性和可维护性。
为了生成能够将变更反映到实现架构的解决方案工件，就要迅速地重新应用被修改的转换。
UML是开发标准，事实上是软件建模的标准。
UML是说明、可视化，并编制软件系统的语言。
UML为软件模型提供可视化的标记以及基础语义。
UML还拥有标准的计算机可处理的序列格式，因此可以使用自动化。
本文关注于如何用基于资产的开发来优化作为集成开发方法的MDD。
使用该方法，开发人员首先用统一建模语言（UnifiedModelingLanguage，UML）构建对象模型，然后通过利用了模式存储库的代码生成工具来生成代码。
使用RationalSoftwareArchitect来应用MDD
阅读了此信息，您可能发现，应用该开发方法需要可以支持以下内容的集成开发环境（IntegratedDevelopmentEnvironment，IDE）：
∙使用UML建模
∙模式基础架构
∙模型转换和代码生成
∙具体到平台的设计和开发工具及单元测试环境
RationalSoftwareArchitect是提供以上所有功能的工具。
RationalSoftwareArchitect是能够利用UML进行模型驱动开发的集成设计和开发工具，用以创建良好架构的应用程序和服务。
有了RationalSoftwareArchitect，您可以：
∙利用开放且可扩展的建模平台
∙加速软件建模和设计
∙将开发过程自动化并且将资产复用最大化
∙更有成果地开发应用程序和Web服务
本系列的这些文章按照如下顺序进行组织：
第1部分：
本文，着重于MDD和基于模式的开发方法的概述
第2部分（即将发布）：
利用RationalSoftwareArchitect进行MDD和基于模式的开发的方法
第3部分（即将发布）：
案例研究
UML模型
MDD的主要特点之一是将模型作为重要工件。
模型是以特定的观点对系统的描述，忽略了不相关的细节，同时更清晰地看到关注的特性。
在MDD中，模型必须是计算机能够处理的，这样您可以用自动化的方式访问模型的内容。
为了让您能够生成工件，模型必须是计算机可以处理的。
白板上的图可能会满足作为模型的其他标准，但直到您以计算机能够处理的方式获取它时，您才能在MDD工具链中使用它。
软件模型一般用UML表示。
UML模型隐藏了技术实现细节，这样可以利用来自应用领域的概念来设计系统。
一般应用程序设计用UML建模工具，例如RationalSoftwareArchitect，以及与应用领域相关的概念来实现。
甚至在MDD之前，使用UML模型来设计软件就是很好的实践。
在大部分情况下，以两种方式来使用模型：
∙作为非正式地传达系统某个方面的框架结构
∙作为描绘您人工实现的详细设计的蓝图。
在MDD中，模型不仅用作框架结构或蓝图，而且作为主要工件，通过应用转换，由这些工件生成有效的实现。
在MDD中，在开发新软件组件时，准确的描述面向领域的应用程序模型是主要关注点。
代码和其他目标领域工件利用根据建模专家和目标领域专家而设计的转换来生成。
模式
MDD的另一个主要特征是获取专家经验。
模式获取最佳实践解决方案来重现问题。
在MDD中，模式可以出现在建模的所有抽象层次上。
例如：
∙架构模式
∙设计模式
∙实现模式
模式是可以进行组合的，用以为解决更大的问题而生成模式菜单，并且涵盖领域的最佳实践。
模式指定模型元素的特征，以及那些元素之间的关系。
当您将模式应用到模型中时，您可以将模式自动化，在转换中新的元素被创建，已有的元素被修改，以符合模式的定义。
模式提高解决方案的一致性和质量。
这可以通过在MDD中使用转换来自动化模式的实现来完成这一点，这样可以排除重复的低层次开发工作。
与其在构建解决方案工件时重复且人工地应用技术专家经验，倒不如将专家经验直接编入转换之中。
这样做就拥有了一致性和可维护性的双重优势。
迅速地再次应用修改了的转换，从而生成将变更反应到实现架构上的解决方案工件。
从业务问题到软件解决方案
图1展示了如何利用MDD将业务问题转换为软件解决方案。
评审业务问题，并且应用一些通用的业务模式。
这样做部分地填充了设计模型，并且在构建的具体业务功能中加入细节。
然后，应用平台独立的设计模式，以将设计模型转换为运行时独立的组件。
在那之后，选择运行时平台，并且使用具体到运行时的实现模式来生成工件。
图1.利用MDD将业务问题转化为软件解决方案
使用带有模式的MDD的好处
软件开发行业已经发现了采用带有模式的MDD的很多好处。
一些重要的包括：
提高生产率：
MDD通过从模型生成代码和工件来减少软件开发的成本，这样做提高了开发人员的生产率。
增加复用：
MDD在应用于大型项目或组织层时优势尤其明显。
这是因为在每次复用它们时，开发转换的投资回报率都有所提高。
使用可靠且经过测试的转换还可以提高开发新功能的可预计性，并且减少项目风险（因为架构和技术问题已经解决了）。
提高可维护性：
技术的演进导致解决方案组件逐渐成为先前平台技术的遗产。
MDD帮助解决这一问题，它引出可维护的架构，在该架构中可以快速且一致地进行变更，使您更有效地将组件迁移到新技术上。
灵活性更强：
高层次的模型与实现细节无关。
保持模型与实现细节无关可以使得处理底层平台技术及其技术架构中的变更成为更容易的事情。
通过更新转换来完成对实现的技术架构的变更。
再次对原来的模型应用转换，从而生成依照新方法的实现工件。
一致性：
人工地应用编码实践和架构上的决策是容易出错的活动。
MDD确保一致地生成那些工件。
提高沟通性：
模型省略了与了解系统逻辑行为不相关的实现细节。
因此，模型更接近问题领域，减少了涉众所了解的概念和解决方案所用的表示语言之间的语义鸿沟。
模型还简化了设计层系统的理解及退出。
这形成了对系统的沟通性的增加。
保留专家经验：
项目或组织经常依赖于重复做出最佳实践决策的重要专家。
有了模式和转换中获取的专家经验，他们不需要出现在项目的其他成员面前来应用（得益于）这些经验。
降低风险：
当使用MDD方法时，早期的应用程序开发着重于建模活动。
这意味着，直到晚些时候才选择具体的技术平台或产品版本是可能的（当进一步的信息可用时，从而减少风险）。
经验教训
MDD是可靠的开发方法。
然而，行业反馈指出，不是所有使用MDD的项目都是成功的。
这一般源于一些因素：
∙糟糕的项目选择
∙计划不充分
∙缺少必要的经验和技能
要帮助您从MDD中获得最大利益，以下是一些从过去项目中获得的经验。
选择恰当的候选项目：
MDD在应用于大型项目或组织层之上时特别强大，因为来自转换的开发或购买中的投资回报（returnoninvestment，ROI）在每次复用时都增加了。
好的候选项目也应该有良好的架构和可重复的行为的模式，以便可以对那些模式进行抽象，从而获取专家经验，并且在转换中使用。
考虑附加的成本：
您可能需要考虑开发或购买转换的成本，但是谨慎的成本计划可以确保长期内的成本降低。
取得小的成功：
在许多组织中，一些怀疑论对新的方法进行质疑，直到新方法得到证实。
如果这是您使用MDD方法的第一个项目，那么明智的做法是将MDD工具的开发分割为许多迭代。
后继的迭代建立于您所获得的经验之上，允许您支持越来越广的业务应用程序的情景集。
发展适当的技能：
MDD要求架构师和开发人员要熟悉UML和MDD的IDE。
在团队中培养成这些技能最初要花些时间，这导致了项目延迟。
然而，对于同样的项目团队，后继的项目将更容易。
如果这是您第一个使用MDD的项目，那么引入专家来发动团队是很好的选择。
时刻考虑复用：
在应用程序开发人员为业务应用程序生成工件时，它们会多次使用为项目而构建的MDD工具。
该工具在后继的项目中得到复用也是可能的。
时刻考虑在更大的环境中复用将在长期内为您的组织带来重大的好处。
选择适当的开发工具。
拥有适当的工具将确保您从MDD中获得最大价值。
项目团队（包括项目经理、业务分析人员、解决方案架构师、开发人员，和测试人员）应该评估并验证正在使用的开发工具。
总结
本系列第1部分描绘出模型驱动和基于模式的开发范例的全景。
概括地说，MDD开启了模式的潜能，以创建设计优良的解决方案，而模式为MDD提供内容。
参考资料
学习
∙您可以参阅本文在developerWorks全球网站上的英文原文。
∙学习developerWorks文章中有关可复用资产、诀窍和模式的内容。
∙从developerWorks的SOA和Webservices新手入门页面上了解有关SOA的内容。
∙密切关注developerWorks技术活动和网络广播。
∙IBMRationalSoftwareArchitect产品页面：
找到关于RationalSoftwareArchitect的技术文档、指导文章、教程、下载及产品信息。
∙访问IBM的PatternSolutions并找出IBM在模式和可复用资产方面正在做什么。
∙在developerWorks的Architecture专区中获取在架构领域提高您的技能所需的资源。
∙浏览技术书店，找寻有关这些和其他技术主题的书籍。
获得产品和技术
∙下载RationalSoftwareArchitectv6的免费试用版本。
讨论
∙RationalSoftwareArchitect、DataArchitect、SoftwareModeler、ApplicationDeveloper和WebDeveloper论坛：
询问有关RationalSoftwareArchitect的问题。
∙参与developerWorksblogs并加入developerWorks社区。
第2部分:
IBMRationalSoftwareArchitect
中的模型驱动开发工具支持
内容
∙利用UML建模
∙RationalSoftwareArchitectModeling透视图
∙模型模板
∙模式框架
∙转换
∙基于资产的开发框架
∙将所有内容放在一起：
简单的场景
∙将您投资的价值最大化
∙下载
∙参考资料
∙关于作者
∙建议
如本系列第1部分中所提到的，要使用模型驱动及基于模式的开发方法，您需要支持以下内容的集成开发环境（integrateddevelopmentenvironment，IDE）：
∙利用统一建模语言（UnifiedModelingLangugage，UML）建模
∙模式基础架构
∙模型转换及代码生成
∙具体到平台的设计和开发工具
∙单元测试环境
IBM®Rational®SoftwareArchitect不但提供支持端到端的模型驱动开发（model-drivendevelopment，MDD）的这些功能，而且还提供支持基于资产开发的增值功能，通过支持模型、模式和转换的复用为MDD进行补充（参见图1）。
利用UML建模
模型已经成为软件设计的主要工件，因此从相应的程序代码上转移走了相当多的注意力。
因而，模型不仅令您获取并传达应用程序架构的所有方面，而且还作为各种自动和半自动过程导出程序和相关模型的源头。
所以，您可以将模型用作以下目的：
∙可视化地表示您想要构建的系统
∙促进对系统的一般了解
∙开发、验证，并传达系统的架构
∙生成代码
RationalSoftwareArchitect集成了强大的UML软件建模框架，并且完全支持UML2.0（UML标准的第一个重要的修订版）建模。
这意味着它能够更好地支持MDD工具及方法，可以帮助您获取并传达设计的意图。
在UML建模中，模型包含许多元素，例如角色、用例、类和包，以及一个或多个表示系统具体角度的图，例如活动图或类图。
图1.集成开发环境
本文，也就是系列的第2部分，强调了与模型驱动开发、模式和基于资产的开发相关的IBMRationalSoftwareArchitect的重要工具支持。
一个简单的场景将指导您了解那些特性，并且为第3部分中的案例研究做准备。
RationalSoftwareArchitectModeling透视图
RationalSoftwareArchitect提供了一个组合以下相关视图的建模透视图。
ModelExplorer
ModelExplorer（图2）展示了可能包含许多模型的建模项目。
模型（本身就是模型元素）包含相应的模型元素，例如包、类、参数、方法和约束。
在ModelExplorer中，您可以添加、删除、分类，并组织元素，您还可以在图编辑器中打开UML图。
图2.ModelExplorer视图
DiagramNavigator
DiagramNavigator是工作区中不同的项目视图。
它在目录（树型）视图中显示建模项目、UML模型，及其UML图，如图3所示。
图3.DiagramNavigator视图
UML图帮助您可视化并控制模型中的元素。
不同的图表示您正在开发的系统、应用程序，或数据库的不同视图。
因为图可以说明模型的多个方面，所以同样的模型元素可以出现在一个或多个图中。
UML利用许多涉众公认的标准标记，提供让用户获取并传达应用程序架构所有方面的各种图。
这些是13个正式的UML2.0图，每一个都表示系统的不同方面：
∙活动图：
活动图提供对系统行为的视图，它描述了过程中的活动序列。
除了展示活动中动作之间的流，类似流程图，活动图还可以展示并行或并发的流，及交替的流。
∙类图：
您可以使用类图来对组成系统的对象建模，展示对象之间的关系，以及描述那些对象要做什么，及它们要提供什么服务。
类图对对象建模过程是很重要的，并且在分析和设计阶段是有用的。
∙通信图：
原来在UML1中称为协作图，通信图展示了对象之间的消息流，并且展示了若干对象如何一起合作实现共同目标。
类似于序列图，通信图也对用例的动态行为建模。
然而，通信图更看重对象的协作，而不是时间序列。
∙组件图：
组件图展示了系统组件之间的结构关系。
在UML2中，组件是系统或子系统中自治，封装的单元，它提供一个或多个接口。
因此，组件图能够让架构师来验证，组件在实现系统的所需功能。
∙复合结构图：
复合结构图探索了在通信链路上协作的连通实例的运行时实例。
∙部署图：
部署图描述了处理节点的运行时配置，以及运行于那些节点（系统的硬件、安装在硬件之上的软件，以及连接不同机器的中间件）之上的组件的静态视图。
∙交互总览图：
交互总览图是活动图的变体，它当中的节点表示交互图。
交互图包含序列、通信、交互总览，及时序图。
∙对象图：
使用对象图来探究对象的真实世界的实例，以及它们之间的关系。
对象图类似于类图，因为关系的标记是一样的。
要解释对象之间复杂的关系，对象图是很好的选择。
∙包图：
包图可以让您将模型元素组织为用文件夹表示的组，这使UML图更容易理解。
∙序列图：
序列图说明了交互中对象之间消息的时间序列。
它包含参与者小组，例如角色、系统或子系统、类，和用生命线表示的组件，以及交互过程中交换的消息。
∙状态机图：
状态机图描述了对象所处的各种状态，以及那些状态之间的变迁。
∙时间图：
时间图探究了具体的时期中一个或多个对象的行为。
∙用例图：
使用用例图来可视化（或例举）用例和角色之间的关系，以及用例和其他用例之间的关系。
DiagramEditor
您可以由DiagramNavigator或ModelExplorer视图在DiagramEditor中打开UML图（图4）。
您可以同时选择打开多个图，然后使用选项卡在打开的图之间切换。
UML图包含许多图元素。
图元素，也称为图形，是表示UML元素（例如类、接口，和关系），或者没有UML语义的几何形状（例如椭圆形、菱形和矩形）的图形或文本元素。
在DiagramEditor中，您可以从ModelExplorer中将现有的模型元素拖拽到图中，或者您可以使用选项板来创建新的图元素。
（如果图元素表示UML元素，那么其相应的UML元素将被添加到模型中。
）
图4.DiagramEditor视图
属性（Properties）
如果您选择UML图中的图元素，您可以在Properties视图中看到并设置该图元素的属性（图5）。
属性是控制UML图中图形和连接件的特征的值。
例如，每个图形和连接件都有一个线条颜色属性，您可以通过它指定图形的边或者连接件的线的颜色。
您还可以指定属性值，从而改变连接件的线条样式，以及显示或隐藏间隔或间隔标题。
如果您在ModelExplorer中选择模型元素，那么您可以看到并设置模型元素的属性，例如名称和可视性、模型的概要文件，和类的属性及方法。
图5.Properties视图
模型模板
RationalSoftwareArchitect包含用例、分析和设计模型的模板。
每一个都针对不同的开发阶段：
需求、分析和设计。
RationalSoftwareArchitect不为表示实现的物理组成的实现模型提供模板，包括实现子系统和实现元素（源代码、数据和可执行文件）。
不包含实现模板的原因是RationalSoftwareArchitect的操作理论是：
通过设计使用平台无关的模型，然后通过各种不同的转换，让RationalSoftwareArchitect把这些设计转换为代码或实现级工件。
用例模型
用例模型提供有关您正在开发的系统或应用程序的行为的详细信息。
它根据为实现目标或解决用户所确定的问题而必须存在的功能，确定出系统的需求（用例），并且指定周围环境（角色）和用例与角色之间的关系（用例图）。
用例模型还包括描述用户与系统如何交互的用例图和活动图。
分析模型
分析模型描述了您正在建模的系统或应用程序的结构。
它包括了描述用例模型中所确定的功能需求的逻辑实现的类和序列图。
分析模型确定出系统中的主要类，并且包含一组描述系统如何构建的用例实现。
类图通过利用原型对系统的功能部分建模对系统的静态结构进行描述。
序列图通过描述用例中事件执行时的流对用例进行实现。
这些用例实现对系统的一些部分如何在具体用例环境中交互进行建模。
分析模型描述了系统的逻辑结构，因而它是设计模型的基础。
设计模型
设计模型是基于分析模型的，它向系统的实际实现中添加了详细信息。
设计模型通过使用各种图（包括序列图、状态机图、组件图和部署图），详细地描述了应用程序是如何构成，以及如何实现的。
它还描述了程序设计构想及技术，例如那些用于持久性、分布、安全，及记录的内容。
设计模式通常对设计模型进行提炼，从而获取经常使用的，或复杂的结构和过程。
模式框架
如前面设计模型部分中所提到的，您可以利用设计模式对设计模型进行提炼（修改或添加UML元素），从而将解决方案应用到已知问题上。
您可以利用RationalSoftwareArchitect的模式框架来完成许多重要的任务：
∙撰写模式
∙以插件的形式将模式作为可复用资产进行打包
∙在模式库中找到并导航到模式
∙将模式应用于UML元素
撰写模式
您可以通过扩展两个插件来撰写设计模式：
抽象出模式服务用途的模式服务和模式框架。
模式服务和模式框架提供构建、设计、编码、搜索、组织，及应用模式的基本功能。
“Contentauthoringdemystified”这篇文章（参见参考资源）详细地介绍了如何撰写新的模式。
打包并发布模式用于重用
您可以导出一个符合可复用资产规范（ReusableAssetSpecification，RAS）的作为可部署，可复用资产的模式插件，以便将来可以再次使用。
可复用资产可以作为文件进行交换，或者发布到资产存储库中，让其他人来搜索，然后方便地将模式导入到他们的RationalSoftwareArchitect工作台中。
“Contentautho
升级会员 