PowerDesigner UML 建模简介 - - JavaEye技术网站

PowerDesigner UML 建模简介

面向对象的分析

    在您准备为企业作出系统和软件投资前，必须首先了解企业的实际需求，明确所部署的技术将如何帮助您的企业获取更大的成功。您能够使用 UML，借助用例图、序列图和活动图来进行分析。这些图表将帮助您规划系统的范围、动态性能、连同表现方式等。不必考虑实施细节，您希望获得的只是按照您的需求而表现的系统性能。

    用例图(The Use Case Diagram)

    UML 用例图提供了一个系统环境的建模方式。他能够帮助您确定系统/应用程式的外部和内部元素连同系统范围。作为图像建模模式，他在您需要和所收集的系统需求进行对话时也将有所帮助，对于研制成品的研发团队来说，更是有着举足轻重的重要性。对于企业的任何者，或第一次接触该软件产品的用户也有很大的帮助作用。用例图能够以可视化的方式，表达系统如何满足所收集的业务规则，连同特定的用户需求等信息。

    在项目后期，也能够用到 UML 用例图。您能够通过用例图中定义的需求来协助测试项目的相关功能。您不但能够验证系统性能是否无错误（无崩溃或明显的非逻辑响应），还能够验证系统运行时是否按照需要，执行了指定命令。这样，您能够测试系统是否完全满足了需要，以确信成品能够投入生产——也就是说，他已完全满足了用户的需求。

    只有确保满足了合理、实用的各项需求，才能确保 IT 项目的更大成功。

 
   序列图(The Sequence Diagram)

    您能够使用 UML 序列图细化需求并对设计元素进行链接。序列图允许高层和低层对象间的交互文档。该交互在角色（和用例图中的角色相同）和类实例（运行于电脑内存中的技术对象和细节对象）之间显示。

    通过序列图，您能够按照系统特定方案中事件（消息）的精确顺序来描述随时间变化的系统行为。使用序列图进行用例分析并引导设计：您能够决定将对用例图所定义的管理任务负责的系统对象类型，并决定哪种对象将管理系统内外的“会话”或通信。由于消息已从序列图中抽出，您能够描述类和接口（我们最后要编译和部署的代码元素）所需的某些关键操作（方法）。

    活动图(The Activity Diagram)

    UML 活动图设计用于帮助您了解系统中对象的动态变化。用于描述某一特定类或一组类如何协同工作。和序列图有所不同，活动图不是一系列和时间相关的通信，而是从一个任务到另一任务的控制转移，同时指定谁（哪个对象）对发生的任务负责。

    UML 活动图也是业务流程的技术视图。可对业务工作流进行分析或在“业务流程建模”工作后可获得活动图。

    活动图还可帮助构造系统内元素的周详动态视图（EJB 如何互操作等）。

  通过分析推动设计

    通过分析模型可捕获单独于实施细节之外的系统意向和预期行为，和使用的语言、部署的应用程式服务器或使用的体系结构都没有关系。但是，设计阶段开始后，一切都发生了变化。您必须进入生产环境的细节并将软件构建至特定的体系结构。设计是对系统的实施。

    假如设计是由分析得到的，您能够更加确信所编写的系统行为的正确性，确认所研发的成果将是个按需求构建的系统。您将获得高度成功——让用户得到所需要的系统。您还能够直接利用分析得出的信息而无需在设计过程中重新生成，从而缩减研发时间，由于不必“重新复制”任何工作，因此减少了人为错误。

    通过分析，我们可获得什么呢？通过用例图能够发现对象并促进类和接口的创建。一个或更多类和接口能够实现一个角色，您能够在角色定义中直接创建类和接口。您还能够将角色链接到现有的类和接口，显示如何使用一条代码来满足所分析的多个元素。

    通过序列图能够发现方法并促进类操作的创建。假如您需要向类发送消息，您能够调用该类的方法。序列图中的消息能够用来自动创建操作或链接到现有操作。您能够通过链接跟踪方法的功能，包括将哪些作为输入内容和必须返回哪些内容等等。

    设计所包含的内容

    您已知道要构建的内容，现在您需要表述如何构建。您需要确定业务逻辑所在的位置：能够置于应用程式服务器的 EJB 等组件中，也能够置于使用 VB 或 PowerBuilder 等语言、作为客户端应用程式一部分的类或组件中，或做为触发器和过程内置于关系数据库中。您需要根据需求做出一些选择，包括扩展性、安全、性能和可访问性等方面。

    UML 类图和组件图将用于定义周详的技术系统静态结构。

    类图 (The Class Diagram)

    UML 类图、业务逻辑和任何支持结构一同被用于定义全部的代码结构。既然类图用来模拟研发中所维护的实际代码，显然他是 Java 或 PowerBuilder 等对象语言的概括性表述。您还能够使用 UML 类图来概括 XML 中的复杂结构，令其更易于研发和理解。

    能够从 UML 类图上生成代码。还能够在研发过程中编辑该代码以完善、测试和部署最终运行的应用程式。由于 PowerDesigner 在对象语言和 UML 类图之间具备 1:1 的映射功能，您还能够实施反向工程代码，读取源文档并创建新的类图。您能够更深入地理解现有系统并简化集成和维护工作。

    组件图(The Component Diagram)

    UML 组件图将被用于在更大的黑匣视图（Black Box View）中描述高级对象的定义和相关性。他仍然是个设计模型,并且是代码的直接概括。例如，一个 EJB 的组件标识直接链接到实施所必需的一系列类和接口，并将生成所需代码来推动最终 bean 的研发。
 

    组件图比组件体系结构的代码层视图更容易理解和管理。还能够通过编写组件接口的文档来实现代码的共享和反复使用，用户无需（或很少）了解组件的实施细节即可在其他项目和系统中使用这些代码。

    右击Customer EntityBean_CMP，选择Create/Update Class Diagram,生成如下class diagram:

    循环叠代工程

    世界不是一成不变的，您的 IT 项目也如此。在您了解需求，通过分析进行了设计，并构建了系统的某些元素后，必然还会碰到新的变化，如要更新定义，又或现有用例图中存在某些需要改正的错误，代码在 IDE 和文本编辑器中被编辑连同数据库被DBA 优化等。必须管理和掌控任何需要更改的细节，以确保所构建的系统能够和业务需求保持一致。
往返工程的一个方案是当代码在研发过程中被更改时，需要在类图中反映出来。具体细节如下：

    1. 创建类图并将业务逻辑元素添加到模型中
    2. 生成文档系统的应用程式代码
    3. 在 IDE 或文本编辑器中编辑代码
    4. 编辑设计，此时忽略在生成的代码中所发生的更改
    5. 对编辑内容实施反向工程，直到和现有类图一致
    6. 将设计过程中完成的工作和研发时编辑的内容同步（合并）
    7. 生成新代码，该代码是设计代码和研发人员更改代码的总和

    当对类图进行了修改以反映新的设计内容时，应该使用同步/合并技术防止丢失研发人员的工作成果，同时允许设计人员接受或拒绝研发过程中所做的更改。这样，PowerDesigner 令 IT 能够完全控制体系结构，这正是制胜的关键。

    PowerDesigner 的功能并不是仅限于此！现在设计模型已被更新，您能够将这些更改链接到分析中。有可能您在分析中发现了新的需求，能够将这一更改反映到设计中并编写代码。使用 PowerDesigner 中领先的 Compare/Merge 技术（在 September Blueprint 中讨论过），您能够在研发周期的任何模型和阶段中获得真正的往返同步。

    对象图(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 种图表和传统的数据建模方法和新的业务流程建模方法相结合，我们能够在从高级需求到技术和数据需求，连同物理实现的各个方面来全面了解推动软件研发的任何因素