协作图副本.ppt

交互图的两种形式 顺序图中的一些主要元素： – Object (包括actor实例) – Lifeline (生命线) – Focus of control(控制焦点)或activation(激活期) – Message 顺序图的特点 图书管理系统——借书顺序图 协作图的例子：由借书顺序图转换来的协作图 2、协助图的表示 2、协助图的表示 （1）对象： 协作图与顺序图中的对象的概念是一样，只不过在协作图中，无法表示对象的创建和撤销，所以对于对象在图中的位置没有限制。 （2）链： 表示对象之间的语义关系，链是关联的一个实例。协作图中链的符号和对象图中链所用的符号是一样的，即一条连接两个对象的实线。 （3）消息 协作图中的消息类型与顺序图中的相同，只不过为了说明交互过程中消息的时间顺序，需要给消息添加顺序号。顺序号是在消息的前面加一个整数。每个消息都必须有唯一的顺序号。 （4）消息编号： 消息的编号有两种，一种是无层次编号(按顺序编号)，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系. 角色的重数与迭代消息 类图中的重数特性表明，每个订单可以包含零个或多个订单行，若有多个订单行getValue消息在一个交互中将发送多次，然而这种重复并没有明确地表示出来 订单行的角色的重数，以及发送给这个角色的消息上的循环 循环包括一个写在消息编号后的星号，可能还跟着一个迭代子句 迭代子句指定了重复的详细信息，如果目的只是表示一个消息可能重复，可以省略迭代子句 UML没有规定用于指定循环的语法 循环在协作图和顺序图中都可以使用 两个银行帐户之间的转帐 为什么对象图这样的用法作为一种明确说明交互的一般方法不能令人满意？ a1和a2不是仅有的资金可以在其间转移的对象 对象图显示了固定数目的对象和它们之间的链接。然而，在调用操作的不同场合，涉及的对象的数目和它们之间的链接模式都可能改变，并且产生的交互也因此而不同 3.类元角色 协作一般描述的不是交互中的各个对象，而是对象在交互中扮演的角色 每个角色描述对象能够参与交互的一种特殊方式 对象在交互中可以扮演的角色称为类元角色 类元角色的表示法与对象和类使用的表示法有关。 可以为类元角色命名，以斜线开始；如果省略了名字，则必须包含冒号以区分角色和类 角色的名字和类不加下划线：这表示类元角色不是实例，而是更一般的概念，可以自己有对象作为实例 3.顺序图、协作图表达区别 （对象创建、销毁、条件消息、自返消息） 为了创建一个订单行，客户对象必须向订单发送一个消息说明要订购的零件和数量。然后将创建一个新的订单行对象，并加入到该订单 在顺序图中，代表新对象的类元角色画在新对象被创建时的相应位置，创建新对象的消息终止于该角色符号，而不是像通常消息那样终止于一条生命线 在这个交互过程中，创建了两个新链接，一个链接订单行和包含该订单行的订单，一个链接订单行和它的分类条目对象 顺序图中不描述关联角色 协作图不能显示地表明新对象创建的时间 为了区分在交互过程中创建的元素和交互一开始就存在的元素，对应于新对象和新链接的类元角色和关联角色用特性new予以标注 （2）对象销毁 假若在客户向订单发送一个remove消息时，就从订单中删除订单行 引起对象销毁的消息用destroy构造型标注 被销毁对象的生命线以一个大叉终止 协作图不能显示地表明对象被销毁的时间 被销毁的对象和链接都被用destroyed特性予以标注 (3)条件消息 协作图和顺序图都提供了表示有条件的消息传递的方式 这种条件消息和重复消息传递的表示法一起，原则上允许交互图详尽地展示算法的设计 在多数情况下，由于结果产生的图的复杂性，并不使用这种灵活性 假如零件的库存水平保存在目录条目对象中，并且当收到在订单中增加新订单行的消息时，订单对象在创建新订单行对象并将其加入订单之前，应该先检查库存有足够的所需类型的零件 为了表明创建订单行对象的消息只有在特定情况下才会发送，在消息上附有一个条件，由写在方括号中的布尔表达式组成 可以对协作图中的消息附加完全相同的表示法 一个特定消息的发送与否取决于发送时系统的状态 当进行交互时，两个可选消息中只有一个会被发送，这是通过让两个消息起源于同一个点来表示的 每当控制流到达交互中的这个点时，一个或另一个消息将被发送 在交互中稍后有一点两个分支会合；这点之后，交互以正常的顺序方式继续 分叉之后的会合由对应于分支消息的两个返回消息的交汇表示 除了控制的分岔，这个图还包含了一个有分支的生命线，因为目录条目对象的经历在事务过程中包含了另外的可能性 在任何一次交互中，只会沿着生命线的一个分支进行 这个表示法的一个令人不满意的特征是，引起出现分支的条件没有和生命线本身联系起来 (4)自返消