OOAD 第5章 建立辅助模型 CUMT.ppt

面向对象分析与设计Object-Oriented Analysis and Design 张 磊 博士 副教授 zhanglei@cumt.edu.cn 5.1顺序图 5.2协作图 4.3类之间的关系 4.4实例 5.1 顺序图 系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。 它们是操作契约和（最重要的）对象设计的输入。 UML包含以顺序图为形式的表示法，用以阐述外部参与者到系统的事件。 对于用例中一系列特定事件，系统顺序图展示了： 直接与系统交互的外部参与者。 系统（作为黑盒）。 参与者发起的系统事件 1 时间顺序是自上而下的。 2 事件的顺序应该遵循其在场景中的顺序。 处理销售场景的SSD 用例描述外部参与者是如何与所希望创建的系统进行交互的。 在交互中，参与者对系统发前系统事件，通常需要某些系统操作对这些事件加以处理。（例如收银员输入商品ID时，收银员要请求POS系统记录对该商品的销售）。 UML包含了顺序图作为表示法，以便能够阐述参与者的交互及参与者引发的操作。 定义 系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。 所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。 准则 应为每个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD。 为什么要绘制SSD 我们的系统会发生什么事件？ 因为我们必须为处理和响应这些事件来设计软件。 软件系统要对以下三种事件进行响应： 1 来自参与者（人或计算机）的外部事件。 2 事件事件 3 错误或异常（通常源于外部） 因此，需要准确地知道，什么是外部输入的事件，即系统事件。这些事件是系统行为分析的重要部分。 系统行为 系统行为描述的是系统做什么，而无需解释如何做。 这种描述的一部分就是系统顺序图。 其他部分包括用例和系统操作契约。 SSD指导方针 SSD(系统顺序图)是从对用例的考察中产生的，它展示了用例中一个场景的系统事件。 通常不在SSD中显示用例文本。为SSD适当地命名，可以指明对应的用例。例如，处理销售场景。 系统事件应该在意图的抽象级别而非物理的输入设备级别来表达。因此，“enterItem”要优于“scan”。因为前者既捕获了操作的意图，又保留了抽象性，而不需要涉及使用什么样的接口来捕获系统事件。 SSD可以用来阐述系统之间的协作。 SSD中所示的元素（操作名称、参数、返回的数据）是简洁的。 迭代和进化式SSD 不用为所有场景创建SSD，除非你在使用需要识别所有系统操作的预算技术。 只需为下次迭代所用的场景绘制SSD。 当需要了解现有系统的接口和协作时，或者将其架构记录在文档当中时，SSD也是十分有效的。 顺序图以一种栅栏格式描述交互，其中在右侧添加新创建的对象 顺序图示例：makePayment 消息表示式的基本语法 交互图展示了对象之间的消息；UML对于这些消息表达式具有标准语法： return = message(parameter : parameterType): returnType 没有参数时可以省略圆括号，这是合法的。 如果明显或不重要，可以不包括类型信息。 例如： initialize(code) initialize d = getProductDescription(id) d = getProductDescription(id : ItemID) d = getProductDescription(id : ItemID) : ProductDescription 顺序图的基本表示法 顺序图中的生命线框图包括框图之下的垂直延伸线，这是实际的生命线，尽管实际中的所有UML示例都用虚线表示生命线（源于UML1的影响），但事实上UML2规范中定义生命线可以是实线也可以是虚线。 消息在垂直生命线之间，用带实心箭头的实线并附以消息表达式的方式表示对象间的每个消息（典型的同步消息），生命线自上而下表示时间顺序。 创始消息以实心圆作为起点来表示此类消息。创始消息表示没有特定发送者、发送者不明确或消息源众多的消息。然而，在实际中，可以使用常规的消息连线表示。 应答或返回 可以用以下两种方式表示消息的返回结果： 1）使用消息语法return Var = message(parameter). 2） 在活动条末端使用应答（或返回）消息线 Fig.15.8 顺序图表示法 发送给“自身”的消息 可以使用嵌套的活动条表示对象发送给自身的消息（如图15-9所示） 实例的创建 UML要求使用虚线 实心箭头表示常规的同步消息 开发箭头表示异步调用 消息名称中的create不是必需