1.顺序图

定义：是一种用来显示对象之间的关系，并强调对象之间消息的顺序，同时显示对象之间的关系的动态模型图

包含的元素：对象、激活、生命线、消息

作用：

1，对于业务人员，顺序图可显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的顺序图能被当作一个需求文件使用，为实现一个未来系统传递需求。

2，对于需求分析人员，顺序图能通过提供一个深层次的表达，把用例带入下一层次。通常用例被细化为一个或者更多的顺序图。顺序图的主要用途之一，是把用例表达的需求，转化为进一步、更深层次的精细表达。

3，对于技术人员，顺序图在记录一个未来系统的行为应该如何表现时非常有用。在设计阶段，架构师和开发者能使用顺序图挖掘出系统对象间的交互，进一步完善整个系统的设计。

2.顺序图的原则

注意∶分类器命名规则的在别处描述。

其中，类和接口的命名规则在UML类图的风格指南中描述，用例的命名规则在UML用例图的风格指南中描述，而组件的命名规则在UML组件图的风格指南中描述。当你在消息上引用对象时要命名他们。

顺序图上的对象应使用标准的UML格式 name: ClassName 来标记，其中 name 可选的（拥有一个名称的对象称作已命名的对象，而那些没有名称的对象则被称作匿名对象）。在图1中，Student的实例以theStudent来命名，因为它是一条消息已引用返回值，然而SecurityLogon类的实例则不需要名称，因为图的其它地方并没有应用它，因此它可以使匿名的。

当存在部分相同的类型时需要命名对象。当一个顺序图包含几个同样类型的对象时，例如图3存在两个Account类的实例，你应该为该类型的所有对象命名，以避免图的意义含糊不清。

图⒊在账户间转帐。一致地应用文本版型。

表1总结了一些通用版型，你可以在顺序图的分类器上应用它们。 不要花过多的时间来争论应该使用哪个版型，例如<>和<>都是不错的版型，只要随便选择一个并保证一致性就好了。

表⒈通用的版型. 版型 用法<> 在设计期间表示微软的Active Server Page。<> 在设计期间用于注明一个组件。

<> 用来注明一个控制器类，实现了和使用情境有关的业务逻辑，或包括几个业务类的逻辑。<> 设计期间表示一个图形用户界面屏幕。

<> 设计期间表示一个超文本页。<> 设计期间表示一个Java接口<> 设计期间表示一个Java Server Page。

<> 设计期间表示一个打印的或电子的报告。<> 表示系统角色。

<> 一个一般的用户界面类。 一般使用在分析级的图上，此时你尚未决定使用何种的实现平台。

少量地应用可视化的版型。在你的顺序图上应用可视化的版型时完全正确的，就如同你在图2和图3所见的，但它并非一个十分通用的惯例，因此它可能会减少图的可理解性。

在图2中，顾客是一个角色（使用与用例图相同的符号），OrderCheckout是一个控制器类，CheckoutPage是一个用户界面类，而Order是一个业务实体类。注意，那些需要开发稳定性较高的图的团队会使用可视化的版型Rosenberg & Scott 1999; Ambler 2002），就像在图2描绘的可视化的版型一样，因此对项目中的所有人都必须熟悉这些符号。

集中在关键的交互。AM的实践--创建简单内容建议，当创建一个模型时，你应当集中于系统的关键性特征，而不要包含无关的细节。

因此，如果顺序图是探究业务逻辑的，你就不要包含对象和数据库的具体交互，诸如save （)和delete （)的操作就已经足够了，你可以简单地假定持久性已经能够处理，而不需要去理会细节。 例如，在图2中，你看不到从数据库或对象缓存中读取orders和order items的任何逻辑，只是他们会在适当点发生而已。

你也看不到CreditCardPayment类连接到payment处理器的逻辑，但这个逻辑是必定会发生的。 只把注意力集中在和你正在建模的东西相关的关键性交互上，你可以在尽可能的保持图的简单的同时达到目的，不但提高了建模者的生产力，也增加了图的可读性。

注意∶操作符号的命名规则，和消息、参数、返回值的命名有关的原则都在UML类图的风格指南中描述。把消息名放在箭头旁边。

大多数的建模者都会调整消息名，例如图2中的calculateTotal （)，因此消息名总是靠近箭头的。 一般我们认为消息的接受者将会实现相应的操作，因此把消息名放在离分类器接近的位置是有意义的。

注意，图3并没有遵循这些原则，所有的消息名都排列在接近发送者的地方。 这种方法的优点在于它很容易看出欲建模的情境的逻辑，而且，如果你使用了清楚的消息和参数名称，那你也许可以不用遵循包含逻辑的叙述性描述的原则。

而这种方法的缺点是很难判断哪个操作是被图右方的分类器所调用的。 象往常一样，选择一种方法并一致的应用它。

3.简述顺序图和和协作图的区别及各自的优缺点

原发布者：86140453

顺序图和协作图异同1.顺序图和协作图都属于交互图，都用于描述系统中对象之间的动态关系。两者可以相互转换，但两者强调的重点不同。顺序图强调的是消息的时间顺序，而协作图强调的是参与交互的对象的组织。2.两个图中所使用的建模元素，两者也各有特点。顺序图中有对象生命线和控制焦点，协作图中没有；协作图中有路径，并且协作图中的消息必须要有消息顺序号，但顺序图中没有路径，也可以没有消息顺序号。3.和协作图相比，顺序图在表示算法、对象的生命期、具有多线程特征的对象等方面相对来说更容易一些，但在表示并发控制流方面会困难一些。顺序图和协作图在语义上是等价的，两者之间可以相互转换，但两者并不能完全相互代替。顺序图可以表示某些协作图无法表示的信息，同样，协作图也可以表示某些顺序图无法表示的信息。4.例如，在顺序图中不能表示对象与对象之间的链，对于多对象和主动对象也不能直接显示出来，在协作图中则可以表示；协作图不能表示生命线的分叉，在顺序图中则可以表示。

4.活动图,状态图,顺序图的区别与联系是什么

活动图（activity diagram，动态图）是阐明了业务用例实现的工作流程。业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。活动图是状态图的一种特殊形式。其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。

状态图（Statechart Diagram）是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。

顺序图是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。顺序图是一种动态建模方法。 UML顺序图一般用于：确认和丰富一个使用情境的逻辑。

5.顺序图的简介

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

和合作图、活动图一样，UML顺序图（ Rumbaugh、Jacobson、和booch, 1999）是一种动态建模方法。 UML顺序图一般用于：确认和丰富一个使用情境的逻辑。一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。或是包含在几个用例中的流程，例如一个学生注册入学之后，立即就要在三个班级注册。研究你的设计，因为它们为你提供了一种方式，你可以使用这种方式来可视化的调用类定义的操作。检测面向对象的设计中的瓶颈。 通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，你很快就能了解那里的设计需要变化，以达到在系统内部平衡负荷的目的。 实际上某些CASE工具甚至能够让你模拟软件这些特征。

使你能够感觉到你的应用程序的那个类将会变得复杂的，这是个信号，意味着你需要为那些类画状态图了。