PowerDesigner UML 建模简介（第二部分）

PowerDesigner UML 简介（第二部分）
作者：Sybase, Inc. PowerDesigner 产品经理 David Dichmann

在 BluePrint #4（访问 http://www.sybase.com/blueprint 以获取以往问题的电子版）中，我们探讨了 5 种 UML 图表：用例图、序列图、活动图、类图和组件图，它们可以帮助您掌握系统的需求，设计其物理结构和预期功能，并转换为代码。我们还可以使用另外 4 个 UML图来进一步精简前 5 个图中包含的定义，或者从完全不同的可取角度来定义系统。

这些图表（对象图、协作图、状态图和部署图）与前面的图一起组成了PowerDesigner 中的全部图表，并可在PowerDesigner9.5中使用。
对象图(Object Diagram)：
与类图一样，对象图也是一个 UML 静态结构图；它定义了系统在给定时刻具有的物理元素，而没有具体考虑系统的动态活动。它与代码一一对应，但与类图不同，我们现在讨论的是具体的分类器，而不是分类器定义。将对象图描述为类实例图可能最为合适。

对象图的主要用途是进行分析。类图中无法表示的类之间存在不确定的约束。我们将使用对象图来记录这些约束。而且，在我们查看所管理的具体类实例示例以阐明这些元素之间的交互作用关系时，对象图还允许我们定义具体的“What if”场景。

以下内容适用于 OO 建模的初学者：分类器是抽象的对象结构定义。分类器可以告诉我们所管理的是什么类型的数据（属性/成员表示数据元素）以及该分类器具有什么能力（操作/方法表示对象的行为）。实例是具体的分类器示例。假定定义一个名为 Customer 的类，该类具有 Name 属性。类 Customer 的实例“Jane Doe”是姓名恰为“Jane Doe”的客户。实例通常具有比分类器更丰富的含义，这是因为分类器表示某种级别的概述。收集某个分类器的若干个实例或示例可能有助于您理解其用途并更好地使用它。

因此，对象图是类图的具体形式，表示类实例样本，并且显示了键值和关系。例如，CustomerBean 类具有以下客户实例：该客户的 ID 为 52271，姓名为“John Doe”。该客户实例与三个订单实例（三份订单）相关，订单编号分别为122047、122103 和 122399。

 



 
协作图(Collaboration Diagram)：
协作图和序列图非常相似。实际上，序列图和协作图可以有效地交替使用，并可以简便的相互转换。其区别在于用户阅读和理解的方式不同。序列图具有很好的层次性，并且围绕时间构造。协作图则主要是围绕对象结构构造。通过在图中对消息进行编号可以表示消息的顺序。采用这种方式时，即使图的结构不是基于时间的，也将保持定时关系。

协作图借助于系统中元素或对象之间的交互作用，表示系统的动态方面，即在一段时间内的表现方式。它通过表示系统的静态结构来对类图和对象图进行补充，但不是借助于基于结构的关系，而是在系统对象之间传递交互作用“消息”。

构造协作图时还可以在概念级测试静态模型。在类图中定义了类实例，这些类实例之间的交互作用定义了一个具体的使用方案以及将在这些元素之间发生的内部通讯。我们还可以使用其他角色来表示系统的外部作用者和内部使用者，如用例图。

例如，我们可以建立一个订单输入系统，以供客户和销售代表使用。客户通过创建新订单与该系统交互作用。订单对象与销售对象之间进行对话，该对话由链接消息表示，在此情况下，只有两个消息：一个是来自 Orders 类的订单请求，一个是来自 Sales 类的订单确认。对一个链接上的消息数量没有限制。我们在此讨论的对话以一个订单请求开始，然后是对该订单的确认。 

 


适用性
协作图对于设计人员尤其重要，因为它阐明了对象的作用。您可以在序列图之前构造协作图（如果您计划构造这两个图），但通常是在完成类图之后构造协作图以说明从类中导出的对象之间的交互作用。可以使用一个或多个协作图来实现一个用例，或者将复杂行为分割成多个逻辑子行为。
状态图(Statechart Diagram)：
状态图（也称为状态机）描述了特定类或组件在其整个生命周期中不断变化时的行为。该图显示是什么触发了从一种状态向另一种状态的转换，以及在该类上调用哪些操作以提供该状态的行为或触发这种转换。例如，订单在被创建时处于初始状态。在客户确认订单正确后，订单将进入确认状态。在发货以后，订单需要从确认状态进入发货状态。 

 



 

因此，每当一个类在其生命周期的不同阶段具有不同的可用选项（不同的有效行为）时，您都可以使用状态图来将这些规则和条件建模。生命周期中的每个阶段都是该对象的一种状态，而每个改变状态的触发器都代表从一种状态到另一种状态的转换。可以根据需要从某个状态转换到任意多个其它状态，也可以从其它多个状态进入某个状态。
子状态图
若要保持状态图简单和易读，您可能发现所定义的一个或多个状态实际上涉及到更为复杂的行为，以至于它本身就可以定义为一个状态图。此时，与向主图中添加大量复杂细节的做法相比，更好的做法是将这个单独的状态分解为多个子状态，进而组成一个辅助图，以定义父状态的更为复杂的内部行为。



部署图(Deployment Diagram)：
部署图可以帮助我们确定所有代码元素在服务器、工作站和数据库中的存放位置。有的节点需要依赖硬件或软件框来运行部分业务逻辑。这些节点交互作用以演示我们开发的多个计算机和系统是如何交互作用和集成的。节点中包含将部署到数据库、应用程序或 Web 服务器中的组件实例。

部署图用于将组件实际部署到服务器中。通过定义希望组件运行的位置，我们可以快捷的映射、部署和管理分布在客户端应用程序和应用程序服务器端组件之间的业务逻辑或数据库端服务器逻辑。以下是要管理的物理体系结构的 1:1 模型。

例如，假定我们已决定实现两个 Enterprise Java Beans，并且在应用程序服务器上运行它们。下图显示了单个节点以及该节点内的两个组件（每个 EJB 一个组件）。我们可以看出 EmployeeBean 依赖于同一应用程序服务器内的 CustomerBean。 


结论
在我们借助用例图、序列图、活动图、类图和组件图完成基本 UML 建模时，我们将需要其它一些工具来定义有关系统中某些特定元素的详细信息。我们可能希望在对象图中使用精确的示例来表示对象的结构，或者借助于状态图来更多地了解在其内部具有多个复杂状态的类的行为。我们需要使用协作图从结构角度而不是从时间角度来考察系统组件之间的交互作用。最后，还需要使用部署图来显示所有系统组件在运行环境中的物理硬件或服务器中所处的位置，从而更详尽的了解分布式体系结构的使用方式。

UML 为我们提供了更加实用的图表，以便完成对业务逻辑的技术分析、设计、开发、或部署。将这 9 种图表与传统的数据建模方法和新的业务流程建模方法相结合，我们可以在从高级需求到技术和数据需求，以及物理实现的各个方面来全面了解推动软件开发的所有因素。

原文转自：http://www.ltesting.net