第3章序列图.doc

3.1　概述 通过前面学到的知识，我们进一步比较3种UML图，如表3-1所示。用例图和序列图（sequence diagram）都表示动态行为，只是前者表示系统外部对象（参与者）与系统这两大对象之间的互动，而后者则重在表示系统内部一群小对象之间的互动。 表3-1　3种UML图的比较 ? 也就是说，序列图关联了类图与用例图两方面，表示了系统在与参与者互动执行某一个用例期间，系统内部的一群小对象的协作情况。因此，分析师可以使用双叉法，同步进行类图与用例图的分析，然后尽快通过序列图来整合、调整三方面的图，如图3-1所示。 ? 同类图的情况一样，序列图包含了一大堆元素，不过我们还是主张要聪明地选用合适的元素。所以，接下来的小节中，分析师可以先学习必学的元素，接着再来看如何应用BCE模式（Boundary-Control-Entity Patterns），迅速绘制出整合领域概念（domain concept）和业务流程（business process）两方面的序列图。3.2.1　一群对象 序列图是一张栅栏状的图形，展现出一群对象（object）的一小段存活期间，如图3-2所示。而对象之间的互动消息，横跨在生命线（lifeline）上，稍后我们会详细说明“消息”。 ? 既然序列图用来表示执行期间系统内部一群对象之间的互动情况，因此在实际操作中，我们经常使用序列图来表示某一个用例的执行期间系统内部的运作情况。至于系统内部有哪些对象可用，理所当然地规范在类图中。请看图3-3，分析师可以使用序列图来整合用例与类。 ? 3.2.2　消息 一旦分析师让序列图对应到用例之后，序列图中的对象该做什么事情便可以参考用例描述中的流程步骤了。而到了序列图中，原先的用例中的流程步骤将拆解成对象之间的“消息”。换言之，对象之间通过互传消息来进行合作，就好像真实世界中一群人之间的互动。 序列图中的生命线在概念上并无太多重要价值，仅用来表示这一群对象是存在的。不过，在序列图上，有一条条的垂直虚线刚好方便消息横跨其上，从这一点来看，生命线确实有其存在的价值，如图3-4所示。 ? 再者，位于线条上的长条矩形称为“执行说明（execution specification）”，用来代表对象收到消息之后，会负责做一小段事情。对象接收到消息之后，本来就会开始动作，所以如同生命线的情况一样，执行说明在概念上并无特殊价值。 但是，在序列图方面，执行说明可以显示在某一小段执行期间，对象可能发送消息给其他对象，或者发送消息给自己。同样，从这一点来看，执行说明也有其存在价值。 3.3　BCE模式 如果只是这样，要分析师画出某一个用例背后的序列图，就如同一开始要分析师画出类图一样困难重重。既然我们可以应用事务模式来降低绘制类图的难度，当然也可以应用BCE模式来降低绘制序列图的难度。 BCE模式（Boundary-Control-Entity Patterns）是用例技术的创始人Ivar Jacobson大师提出来的，和用例技术同时诞生，只是命运大不相同。后来，用例技术被选择成为UML的一部分，BCE模式却流浪在外。经过多年的演进，BCE模式在图标、名称上都有一些小变动。不过，概念上没大变动，图标和名称也都还是能够让人一眼辨识出来的。 其实，BCE模式在概念上很浅显易懂，跟著名的MVC模式（Model-View-Control Pattern）概念相似。简单来说，在BCE模式中，将对象分为三类：边界类（boundary class）、控制类（control class）和实体类（entity class），如图3-5所示。 ? 边界类。边界类用来隔离系统内外，通常负责接收并响应系统内外的信息。所以，参与者对象只能跟边界对象互动，不能直接发送消息给控制对象或实体对象。 控制类。控制类对应着用例，用来控制用例执行期间的复杂运算或者业务逻辑（business logic）。所以，通常针对一个用例，就会对应生成一个控制类。 实体类。从类图来看，前面我们找出的对应领域概念的类，正属于实体类，主要用来保存问题领域中的重要信息，封装了跟数据结构和数据存储有关的变化。 因此，应用BCE模式之后的序列图如图3-6所示。总之，应用BCE模式时，要注意下列4项规则： ? 1. 针对每一个用例，可以对应生成一个控制类。 2. 参与者对象只能跟边界对象互动。 3. 实体对象不能发送消息给边界对象和控制对象。 4. 比较特别的是，如果只是单纯对数据表进行增加、删除、修改、查询的话，可以不设置控制对象，让边界对象直接发送消息给实体对象，以提高整个序列图的执行速度。 好了，我们马上就应用BCE模式，来练习绘制订房系统的序列图。 3.4　酒店联合订房系统 通常，一个用例至少会有一张