本文来自于 Rational Edge：为了确保了解所有的系统相关性，并且为了确保根据对其他组件的影响来了解对一个或多个组件产生的变更，推荐在对现有系统进行变更之前进行影响分析。本文介绍了利用 IBM Rational 工具集执行影响分析的具体技术。 如果您有在对应用程序变更之前进行影响分析的想法或需求的话，您的项目将比您不这么做可能更加成功。影响分析将确定应用程序的什么部分需要变更，并且它将告诉您该变更可能对应用程序的影响有多少。它还将帮助您确定需要什么级别的回归测试。此外，影响分析将帮助您估计进行所提议的增强所需的时间。 设想一个情景，一个架构师或开发人员已经致力于一个应用程序相当长的时间了，因此他或她的脑子里有许多这类的信息。在这种情况下，该工作人员可能不需要做正式的影响分析。但在许多情况下，应用程序非常大，并且涉及许多开发人员。同样，如果应用程序暂时遍布很多地方，那么其架构将是笨拙的。在这种情况下，影响分析是更好地了解所提议的增强将如何影响应用程序其他部分的有价值的方法。 虽然所有 Rational Architecture Management 工具中都没有“影响分析”特性，但是 Rational 工具集中有一些非常好的能力可以帮助您确定对您的应用程序所进行的建议的变更的影响。各种 Rational 工具中都有您可以使用的具体分析特性，而这些工具之间的集成增强了影响分析能力。然而，即使您没有所有这些工具，您也可以独立地用它们来评估变更的影响。 进行影响分析的 Rational 工具：概要如果您使用可视化建模，并且您的 UML 模型与应用程序代码同步，那么您可以开始观察模型，查明在哪里可以进行变更，以应用程序的其他哪些部分会受影响。UML 2 结构图，例如类图（Class diagram），展示了类或组件之间的关系。您可以看到其他什么组件可能受到变更的影响。如果有许多使用了将要变更的组件的其他组件，那么您可以看到变更对更大应用程序的潜在影响的程度。 让我们来看看什么 IBM® Rational™ 工具可以用于影响分析，在下一个部分中，我将更详细地讨论每种工具的使用。 RequisitePro 是与其他架构管理工具集成的需求管理工具。您可以通过使用您的 UML 模型，并将 RequisitePro 和 IBM Rational Software Architect（或 IBM Rational Software Modeler）集成使用，来大大增强您评估对应用程序的变更的能力。这一集成使您很容易地将 RequisitePro 中的需求与 Rational Software Architect 或 Rational Software Modeler 中的模型元素链接起来。Rational Software Architect 还拥有我一会儿将谈到的架构发现工具。 RequisitePro 还与 WebSphere® Business Modeler 和 IBM Rational Application Developer（版本 7）集成在一起。将 RequisitePro 与其他四个工具中的任何一个相集成，都可以让分析人员、架构师和开发人员维持从需求直接到模型和代码的可追溯性。例如，使用 Rational Application Developer 中的 RequisitePro 界面，开发人员可以看到追溯到应用程序的各个部分的是哪些需求。从这些工具，他们可以确定变更导致对应用程序其他部分的什么影响，以及什么风险与它相关联。RequisitePro 记录了模型或代码工件与需求之间的连接。因此，当您找到应用程序中需要进行变更的位置时，您可以依据追踪能力来查看什么组件（就像 RequisitePro 中的需求）可以追溯到您想变更的组件上。 IBM Rational Application Developer 开发人员利用 Rational Application Developer 来观察可视化为 UML 后的应用程序代码，从而更好地了解类和/或接口之间现有的关系。它帮助开发人员了解可能需要在哪里进行潜在的变更，以及这些变更可能对其他类和接口产生什么影响。他们可以在类图中查看代码，来观察这些关系。他们还可以通过序列图（Sequence Diagrams）观察复杂的方法，以便快速地查看到该复杂方法调用了什么类的其他什么方法。如果开发人员需要进一步查看应用程序在运行时是如何交互的，那么他们可以使用运行时分析特性来描绘他们的应用程序。明确地说明如何完成以上事情超出本文的范围，但我在下面的参考资源部分中加入了参考，通过它可以了解更多信息。 Rational Application Developer 中还有一个静态代码分析特性，通过它可以查看您现有的代码是否违背最佳实践。虽然这似乎不适用于影响分析，但是该特性让您能够创建帮助您更好地了解应用程序的您自己的规则。举例来说，您可以创建对大型的应用程序运行的您自己的静态分析规则，从而发现在哪里用到了特定的接口或类。您可以将您所有的代码都可视化，并且寻找引用，或者您可以做一个查询，寻找代码中的文本。然而，规则的创建是可重复的，并且可以与其他开发人员共享。 Rational Software Architect 拥有所有刚提到的 Rational Application Developer 中的相同的特性，并且还通过添加观察应用程序代码结构的规则来扩展代码分析特性。这使架构师可以发现是否存在任何模式或反模式。它还包含一类规则，用来查看 UML 模型的可追溯性。 Rational Data Architect 令您能够发现并可视化现有数据源的结构，以便帮助您估计所提出的变更将产生什么影响。参见本文末尾的参考资源部分中所引用的演示，了解更多关于 Rational Data Architect 的信息。 利用 Rational RequisitePro 来使用追溯能力当调查一个增强请求时，首先要看哪里？如果您有需求管理数据库，那么您应该看这里。Rational RequisitePro 允许您在许多等级上记录项目和应用程序的需求。它还允许您追踪不同类型的需求，并且在矩阵中观察那些关系。这样，当商业目标追溯到应用程序特性时，您就可以依据这一追溯性。 本文末尾处参考资源中所列出的，出自 Rational Edge 2004 年 2 月刊的文章中包含了针对 RequisitePro 的使用和影响分析的信息。在此我要关注的是使用 RequisitePro 和与 Rational Software Architect (RSA) 或 Rational Application Developer (RAD) 的集成来创建 RequisitePro 所管理的可追溯性链接。 为了启用 RequisitePro 与 Rational Application Developer、Rational Software Architect、Rational Software Modeler (RSM)，或 WebSphere Business Modeler (WBM) 的集成，您只需在这些工具中打开 Requirements 透视图。为了确保启用了该能力，您可以通过选择 Windows 下拉菜单，并选择“Preferences”，来打开 Preferences 窗口。在该窗口中，展开“General”并单击“Capabilities”。您可以启用 Requirements Management 集成了，如图 1 所示。 
图 1：启用了 Rational Application Developer、Rational Software Architect、Rational Software Modeler，或 WebSphere Business Modeler 中的需求管理集成 您还想确保启用 RequisitePro 标签装饰。在 Preferences 窗口打开的情况下，展开“Appearance”并单击“Label Decorations”。确保选择了“RequisitePro Requirement Decorator”。在图 2 中，您将注意到工作区中的一些元素被为了该元素的类型图标对标签进行装饰的小箭头链接到 RequisitePro 中的需求上。如果存在未知状态的链接，那么类型图标上就将出现红色的问号。如果您在工作区中看到了元素上有红色问号，那么查看 Requirement Link Problems 视图。它将告诉您关于该链接出了什么错的更多信息。 当您在 RAD、RSM、RSA 或 WBM 中打开 Requirements 透视图时，您将能把项目、模型、模型元素，或代码与存储在 RequisitePro 数据库中的需求链接起来。这意味着，您将拥有从需求到实现了该需求的模型或代码（更好的是，两者）的追溯能力。您可以在 RequisitePro 中构建可追溯性矩阵，您可以在 RAD、RSM、RSA，或 WBM 中进行影响分析的过程中，查看这些矩阵。在 RSA/RSM/RAD/WBM Requirements 透视图中可以运行这些查询，并且结果将显示在 Requirement Query Results 视图中。这里是您寻找 RequisitePro 中的需求和实现该需求的元素之间关联的地方。图 2 举出了一个示例：假设您需要做出一个变更，添加对新信用卡的支持。您可以依据 Business Rule 7 和实现了该商业规则的文件和模型之间的追溯能力链接。 当您打开 Requirements 透视图时，您会看到一个新的视图，Requirements Explorer 视图。它允许您打开 Requirements 透视图中所使用的 RequisitePro 数据库。通过右键单击打开的 RequisitePro 工程，并选择“Properties”，您可以配置链接策略，和其他属性。Requirements 透视图中使用到的其他视图有 Requirement Trace（它展示了对于 Requirements Explorer 视图中选中的需求的追溯关系）和 Link Clipboard 视图（它用来观察您为链接所保存的元素）。 
图 2：依照 Business Rule 7 和实现该商业规则的文件和模型之间的追溯能力 要添加一个 RequisitePro 中的需求与 RSA、RSM、RAD，或 WBM 工作区中的工件之间的链接，您唯一要干的事情就是将需求拖放到工件上。这样将在 RequisitePro 中，而不是在 RSA/RSM/RAD/WBM 中创建链接。在 RequisitePro 中将生成一个新的“proxy（代理）”需求，表示在您工作区中的工件，并且将生成代理需求和需求之间的链接。参见图 2 中的代理元素“FILE3”、“FILE4”，和“DIAGRAM1”的实例。对此的一个例外情况是创建 UML 模型中的用例和 RequisitePro 中需求之间的链接。在这种情况下，不会生成代理需求。 对于 PequisitePro 和影响分析我还有很多可以介绍的，但本文的目标主要是介绍一些您进行影响分析时可用的具体工具中的一般技术，不是深入了解 RequisitePro。 使用 Rational Application Developer 中的图那么，您需要观察您的应用程序，以看出您认为需要变更的特定类与那些类和接口是相关联的。存在许多将 Java 或 C++ 代码可视化为 UML 的方法。请注意，只有 RSA 中支持对 C++ 代码的可视化，而 RAD 和 RSA 中都支持对 Java 的可视化。 要这样做的一种简单方法是使用 Browse Diagram。该图是不可保存的，但它允许您以类似浏览器的方式浏览代码。要想在 Browse 图中查看您的代码，右键单击您的类，并选择 Visualize > Explore in a Browse Diagram。当图打开时，您可以选择想要查看的关系（Extends、Uses, Implements、References，和 Declares）及关系的深度。然后单击 Apply。该图是可点击的，双击一个类，您就可以看到它与另一个类的关系。然后您可以使用 Forward、Backward，和 Home 按钮在您已查看过的这些图之间进行切换，如图 3 所示。 
图 3：利用 Browse 图将代码可视化为 UML 符号 Topic 图提供了另一种方法。Topic 图类似于 Browse 图，除了 Topic 图是可保存在您的工程中的 —— 保存为 .tpx 文件。Topic 图实际上是对您应用程序的代码的查询，所以，如果您的代码变更了，那么 Topic 图也将反映出该变更。在 Java 类型的环境菜单中，您可以按照创建 Browse 图的同样方法来生成 Topic 图。 您还能够创建可以保存在您的工程中的 Class 图。与 Topic 图的差别是 Class 图只显示您添加的类，而且是可视化编辑 Java 代码的途径。您可以变更 Class 图中的类，这样会导致自动地对您的代码进行变更。记住在 Rational Application Developer 中，所有这些图 —— Browse、Topic 和 Class —— 都不是模型。您的 Java 代码位于图之后，而不是 UML 模型之后。 如果您想更深入到方法中，但不想浏览源代码该怎么办？您可以创建该方法中 Java 代码的时序图。这是研究与其他许多类都进行交互的长方法的好工具，并且是对方法进行文档编制的好工具。 为了以时序图的形式查看方法，您可以在 package explorer 中展开类，右键单击该方法，并选择 Visualize > Add to New Diagram File > Static Method Sequence Diagram。它对静态的和平常的方法都可用，但时序图是静态的。图 4 展示了对于 Swing 类中的方法的静态方法时序图，您可以看到该方法所调用的同一个类和其他类中的其他方法。注意，概要图展示了一个较小的图，一个灰色的框表示您在图中的位置。 
图 4：Swing 类中的方法的静态方法时序图 可视化代码的另一种方法是生成带有 JavaDoc 的 UML 图。就像浏览 图一样，所有类、接口，和包都是可点击的，您可以浏览您所点击的类、接口，或包的 JavaDoc 文档。为了将 UML 嵌入您的 JavaDoc 中，按照以下方法进行操作：在 Java 透视图中，务必选择您的工程，然后选择 Project 下拉菜单。选择 "Generate JavaDoc with Diagrams" > Automatically。您将看到类似图 5 中的窗口。 
图 5：生成带有 JavaDoc 的 UML 图 您需要告诉 RAD，您想要使用什么 javadoc.exe。图 2 中显示的实例使用了用 WebSphere Application Server 版本 6.0 测试环境加载的 javadoc.exe。选择您想生成的图，及 image 类型。如果您点击“Contribute diagrams and diagram tags to source”，它将在源代码中放置图的 image，并包含新的图 image 标签。这意味着将来您可以运行“Project > Generate JavaDoc with Diagrams > From Existing Tags”，来替代“Project > Generate Javadoc with Diagrams > Automatically”。 单击 Finish，您的工程中将生成一个名为“doc”的新文件夹。展开 doc 文件夹，然后在 Web 浏览器中打开 index.html，您可以看到所生成的 JavaDoc。JavaDoc 页面上列出了对于每个类和接口的 UML 图，这些图显示了类或接口与其他类和接口之间的关系。您可以双击 UML 图，浏览 JavaDoc。图 6 展示了带有 UML 图的 JavaDoc 实例。 
图 6：带有 UML 图的 JavaDoc 实例 Rational Application Developer 也拥有询问源代码的分析特性，寻找您还没有应用最佳实践的地方，或者您已经提出性能问题的地方。这个静态代码分析拥有分为以下几类的 212 条规则：设计原则（Design Principles）、全球化（Globalization）、J2EE 最佳实践、J2EE 安全、J2SE 最佳实践、J2SE 安全、命名、性能和私有 API 的检查。您还可以添加自己的分类和规则。如果您选择 Windows > Preferences，并展开 Analysis，您将看到 Custom Rules and Categories。在那里，您可以选择 Add a Category，然后向该分类添加规则。Custom Rule 向导将带您经过新规则的创建过程。 这对代码质量的审查非常有帮助的。Rational Software Architect 通过添加“Architectural Discovery”规则集来扩展代码分析能力。我将在下个部分中分析这个 Analysis 特性。 Rational Application Developer 中还拥有执行 Java 代码的运行时分析的 Java Runtime Profiling。这超出了本文的范围，但我强烈推荐您能自己研究一下该特性。 用 Rational Software Architect 进行架构影响分析Rational Software Architect 允许您在应用程序上执行帮助您了解架构强度的代码审查。“Architectural Discovery”规则集包含了二十四条规则。标题为“Design Patterns”的子类包含了在您的代码中搜索七个“Gang of Four”设计模式的实现的规则。子类“Object-Oriented Patterns”将搜索您的代码，查看 OO 结构，并向您显示抽象和继承树。“Structural Patterns”子类中提供的反模式提供了帮助您寻找可能导致脆弱结构的 Breakable、Butterfly，和 Hub 的实现的规则。“System Patterns”分类包含了一条向您展示应用程序中包结构的规则。 要使用该分析特性，就选择您希望审查的工程，然后单击右键，选择“Analyze”。一些透视图允许您选择 Run 下来菜单，然后选择“Analysis”。采用哪种方法都能让您看到类似图 7 中的窗口。 
图 7：在 Rational Software Architect 中运行代码审查的第一步 在该窗口中，单击 New 按钮，然后您就可以选择分析名称并设置分析的范围。如果您在 RSA 中点击 Rules 选项卡，您将会看到 Architectural Discovery for Java 的选项。如果您选择该类，那么该类中的二十四个规则都将被选上。单击 Apply，然后选择 Analyze，进行分析。分析配置将被保存，并且可以通过环境菜单的 Analyze 选项很容易地再次运行。当 Analysis 运行完成时，将出现 Analysis Results 视图，如图 8 所示。 
图 8：当 Analysis 运行完成时，将出现 Analysis Results 视图 Analysis Results 视图显示了为 Analysis 所选择的分类，括起来的信息表示找到了多少结果，以及分析运行了多久。当您展开该分类时，您将会看到带有关于该子类信息的子类。如果您进一步展开子类，您将看到列出的每个结果。双击结果，您就可以打开它，并且您将看到如图 9 中所示的直观视图。 
图 9：展开 Rational Software Architect 中 Analysis Results 中的子类 如先前提到的，结构模式是我们所称的“反模式”。在某些情况下，您构建或使用了您的整个应用程序所使用的框架，并且该框架可能出现在这些分类中的其中一种中。在这种情况下，您可以单击右键，并选择 Ignore the result。否则，您就应该注意是否找到了三种普遍的反模式的实现：Breakable、Butterfly 和 Hub。“Breakable”是一个依靠太多其他组件的组件或包。相反，“Butterfly”是拥有太多依赖性的组件或包。结合二者，“Hub”是即有太多依赖性，又有太多从属的组件或包。这些是由全球级别上的项目中的组件百分比和本地级别上的直接依赖性确定的。默认值分别是 15% 和 10%，在我前面介绍的，图 7 中所显示的分析配置中，二者都是可配置的。 用 Rational Data Architect 进行数据库影响分析这是 IBM Web 站点上对 Rational Data Architect 的阐述：“影响分析将列出对具体元素的依赖性。结果以可视化的形式表示出来，而且为了更容易地观察，结果还以报告格式显示出来。”我在参考资源部分中列出的演示，“Managing Database Design Changes with Rational Data Architect”，提供了关于进行数据库影响分析的有用信息。 总结Rational RequisitePro 不仅是需求管理的伟大工具，还擅长影响分析。Rational Application Developer 和 Rational Software Architect 中的分析工具是基于代码的，这意味着它们参照您的代码来分析，或构建直观视图。此外，使用 Rational Software Architect 可以参照 Models 来研究所提出的变更的影响。虽然 Rational Software Modeler 不包含 本文中提到的基于代码的分析工具的 IDE，，但是，如果您的模型可以表示应用程序代码的话，您仍旧可以进行影响分析。 现在对本文进行讨论！尊敬的读者：现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 此处 开始。 参考资料
|
版权所有：UML软件工程组织