UML之二

今天是UML的第二天讲授，越来越发现这个功能的强大了，今天复习了昨天的东西用例图、类图后来又讲了序列图
序列图显示具体用例（或者是用例的一部分）的详细流程。它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。序列图的绘制非常简单。横跨图的顶部，每个框（参见图4）表示每个类的实例（对象）。在框中，类实例名称和类名称之间用空格/冒号/空格来分隔，例如，myReportGenerator: ReportGenerator。如果某个类实例向另一个类实例发送一条消息，则绘制一条具有指向接收类实例的开箭头的连线，并把消息/方法的名称放在连线上面。对于某些特别重要的消息，您可以绘制一条具有指向发起类实例的开箭头的虚线，将返回值标注在虚线上。就我而言，我总喜欢绘制出包括返回值的虚线，这些额外的信息可以使得序列图更易于阅读。阅读序列图也非常简单。从左上角启动序列的"驱动"类实例开始，然后顺着每条消息往下阅读。记住：虽然图4所示的例子序列图显示了每条被发送消息的返回消息，但这只是可选的。

图4：一个示例序列图（最下边的图）

通过阅读图4中的示例序列图，您可以明白如何创建一个CD销售报告（CD Sales Report）。其中的aServlet对象表示驱动类实例。aServlet向名为gen的ReportGenerator类实例发送一条消息。该消息被标为generateCDSalesReport，表示ReportGenerator对象实现了这个消息处理程序。进一步理解可发现，generateCDSalesReport消息标签在括号中包括了一个cdId，表明aServlet随该消息传递一个名为cdId的参数。当gen实例接收到一条generateCDSalesReport消息时，它会接着调用CDSalesReport类，并返回一个aCDReport的实例。然后gen实例对返回的aCDReport实例进行调用，在每次消息调用时向它传递参数。在该序列的结尾，gen实例向它的调用者aServlet返回一个aCDReport。

请注意：图4中的序列图相对于典型的序列图来说太详细了。然而，我认为它才是足够易于理解的，并且它显示了如何表示嵌套的调用。对于初级开发人员来说，有时把一个序列分解到这种详细程度是很有必要的，这有助于他们理解相关的内容

 

状态图的建立步骤：

1〉确定状态机的上下文，它可以是一个类、子系统或整个系统。

    2〉选择初始状态和终结状态。

    3〉发现对象的各种状态。注意应当仔细找出对问题有意义的对象状态属性，这些属性具有少量的值，且该属性的值的转换受限制。状态属性值的组合，结合行为有关的事件和动作，就可以确定具有特定的行为特征的状态。

    4〉确定状态可能发生的装移。注意份已从一个状态可能转移到那些状态，对象的哪些行为可引起状态的转移并找出触发状态转移的事件。

    5〉把必要的动作加到状态或转移上。

    6〉超状态、子状态、分支、历史状态等概念组织和简化一个复杂的状态机。

    7〉分析状态的并发和同步情况。

    8〉绘制状态图。

    9〉确认每一个状态在某个时间组合之下都是可到达的。确认没有一个死端状态，对象不能从该状态转移出来。

活动图的建立步骤：

    1〉找出负责实现工作流的业务对象。这些对象可以是现实业务领域中的实体，也可以是一种抽象的概念或事物。为每一个重要的业务对象建立一条泳道。

    2〉确定工作流的初始状态和终结状态，明确工作流的边界。

    3〉从工作流的初始状态开始，找出随时间而发生的活动和动作，把他们表示成活动状态或动作状态。

    4〉对于复杂的动作或多次重复出现的一组动作，可以把他们组成一个活动状态，并且用另外一个活动图来展开表示。

    5〉给出连接活动和动作的转移（动作流）。首先处理顺序动作流，然后处理条件分支。最后处理分劈和接合。

    6〉在活动图中给出与工作流有关的重要对象，并用虚箭线把他们与活动状态或动作状态相连接。

包图的建立步骤：

    1〉分析系统模型元素（通常是对象类），把概念上或语义上相近的模型元素纳入一个包。注意可以从类的功能的相关性来确定纳入包中的对象类。以下几点可作为分析对象类的功能相关性的参考

    （1）如果一个类的行为和/或结构的变更要求另一个相应的变更，则这两个类是功能相关的。

    （2）如果删除一个类后，另一个类便变成是多余的，则这连个类是功能相关的，这说明该剩余的类只为那个被删除的类所使用，他们之间有依赖关系。

    （3）如果两个类之间大量的频繁交互或通信，则这两个类是功能相关的。

    （4）如果两个类之间有一般/特殊关系，则这两个类是功能相关的。

    （5）如果一个类激发创建另一个类的对象，则这两个类是功能相关的。

    （6）如果两个类不涉及统一个外部活动着，则这两个类不应放在同一个包中。

    （7）一个包应当具有高内聚性，包中的对象类应该是功能相关的。

    2〉对于每一个包，标出其模型元素的可视性：公共、保护或私有。

    3〉确定包与包之间的依赖关系，特别是输入依赖。

    4〉确定包与包之间的泛化关系，确定包元素的多态性和重载。

    5〉绘制包图。

    6〉包图精化。

组件图的建立步骤：

    1〉确定组件。首先要分解系统，考虑有关系统的组成管理、软件的重用核物理节点的配置等因素，把关系密切的可执行程序和对象库分别归入组件，找出相应的对象类、接口等模型元素。

    2〉对组件加上必要的构造型。可以使用UML的标准构造型“executable”、“library”、“table”、“file”、“document”，或自定义新的构造型，说明组件的性质。

    3〉确定组件之间的联系。最常见的组件之间的联系是通过接口依赖。一个组件使用某个接口，另一个组件实现该接口。

    4〉必要时把组件组织成包。组件和对象类、协同等模型元素一样可以组织成包。

    5〉绘制组件图。

配置图的建立步骤：

    1〉确定节点。

注意：标示系统中的硬件设备，包括大型主机、服务器、前端机、网络设备、输入/输出设备等。一个处理机是一个节点，它具有处理功能，能够执行一个组件；一个设备也是一个节点，它没有处理功能，但它是系统和现实世界的接口。

    2〉对节点加上必要的构造型。可以使用UML的标准构造型或自定义新的构造型，说明节点的性质。

3〉确定联系。这是关键步骤。配置图中的联系包括节点与节点之间的联系，节电与组件之间的联系，组件与组件之间的联系，可以使用标准构造型或自定义新的构造型说明联系的性质。把系统的组件如可执行程序，动态连接库等分配到节点上，并确定节点与节点之间，节点与组件之间，组件与组件之间的联系，以及他们的性质。

今天还讲了RUP模式，不过不懂这个