UML交互建模与用例分析全解析

### UML交互建模与用例分析全解析 #### 1. 特殊消息建模 在消息建模中，除了常见形式，像回避（balking）和超时（time out）这类特殊消息形式，可通过定义适当的消息原型来进行建模。 #### 2. 对象的创建、修改与销毁 在多数交互中，参与交互的对象会贯穿交互始终。但也存在一些情况，对象会在交互过程中被创建或销毁，链接也是如此，对象间的关系可能随时产生或消失。为了明确对象或链接在交互中的进入和离开情况，可以为元素附加以下约束： |约束类型|说明| | ---- | ---- | |new|表示实例或链接在包含它的交互执行期间被创建| |destroyed|表示实例或链接在包含它的交互执行完成之前被销毁| |transient|表示实例或链接在包含它的交互执行期间被创建，但在执行完成之前被销毁| 在交互过程中，对象通常会改变其属性值、状态或角色。可以通过在交互中复制对象（可能具有不同的属性值、状态或角色）来表示对象的修改。在序列图中，将对象的每个变体放在同一条生命线；在交互图中，用“become”消息连接每个变体。 #### 3. 交互的表示方式 在对交互进行建模时，通常会涉及对象（每个对象扮演特定角色）和消息（每个消息代表对象间的通信并产生相应动作）。可以通过两种方式可视化交互中的对象和消息： - 强调消息的时间顺序，这种表示方式在UML中称为序列图。 - 强调发送和接收消息的对象的结构组织，这种表示方式在UML中称为协作图。 序列图和协作图在很大程度上是同构的，即可以在不损失信息的情况下将一种图转换为另一种图，但它们也存在一些视觉上的差异： - 序列图可对对象的生命线进行建模，对象的生命线表示对象在特定时间的存在情况，可能涵盖对象的创建和销毁。 - 协作图可对交互中对象间可能存在的结构链接进行建模。 #### 4. 常见建模技术 - 控制流建模 使用交互的最常见目的是对系统整体行为的控制流进行建模，包括用例、模式、机制和框架，或者类或单个操作的行为。类、接口、组件、节点及其关系用于建模系统的静态方面，而交互则用于建模系统的动态方面。 建模交互时，本质上是构建一组对象间发生的动作的故事板。像CRC卡这类技术对于发现和思考此类交互特别有用。以下是建模控制流的步骤： 1. 设置交互的上下文，无论是整个系统、类还是单个操作。 2. 通过确定哪些对象参与交互来为交互搭建舞台，并设置它们的初始属性，包括属性值、状态和角色。 3. 如果模型强调这些对象的结构组织，确定连接它们的链接，这些链接与交互中发生的通信路径相关。必要时，使用UML的标准原型和约束来指定链接的性质。 4. 按时间顺序指定对象间传递的消息。必要时，区分不同类型的消息，并包含参数和返回值以传达交互的必要细节。 5. 为了传达交互的必要细节，在每个时间点为每个对象标注其状态和角色。 例如，在发布 - 订阅机制（观察者设计模式的一个实例）的上下文中，有三个对象：p（StockQuotePublisher）、s1和s2（均为StockQuoteSubscriber的实例）。可以用序列图强调消息的时间顺序，也可以用协作图强调对象的结构组织。 #### 5. 建模提示与技巧 在UML中对交互进行建模时，需记住每个交互都代表一组对象的动态方面。一个结构良好的交互应具备以下特点： - 简单，仅包含共同协作以执行比所有元素总和更大行为的对象。 - 有明确的上下文，可表示操作、类或整个系统上下文中对象的交互。 - 高效，以时间和资源的最佳平衡执行其行为。 - 可适应，可能发生变化的交互元素应被隔离，以便于修改。 - 易于理解，应直接明了，不涉及黑客手段、隐藏的副作用或模糊的语义。 在绘制UML交互图时： - 为交互选择一个侧重点，可强调消息随时间的顺序，或在对象的某种结构组织上下文中强调消息的顺序，但不能同时兼顾。 - 仅展示每个对象对理解交互上下文重要的属性（如属性值、角色和状态）。 - 仅展示每个消息对理解交互上下文重要的属性（如参数、并发语义和返回值）。 #### 6. 用例概述 没有系统是孤立存在的，每个有意义的系统都会与人类或自动化参与者进行交互，参与者期望系统以可预测的方式运行。用例指定系统或系统一部分的行为，是系统为产生对参与者有价值的可观察结果而执行的一组动作序列（包括变体）的描述。 使用用例可以在不指定行为实现方式的情况下，捕获正在开发的系统的预期行为。用例为开发者与系统的最终用户和领域专家达成共识提供了途径，还可帮助验证架构并在开发过程中验证系统。在实现系统时，这些用例由协作实现，协作中的元素共同执行每个用例。结构良好的用例仅表示系统或子系统的基本行为，既不过于笼统也不过于具体。 #### 7. 用例的关键要素 - **用例描述的序列**：用例描述了一组序列，每个序列代表系统外部的参与者与系统本身（及