1用例.docVIP

用例是对系统主要、次要功能的描述，经过一个用例的特定路径，称为一个场景，其中包含一个操作序列，若干对象利用此操作序列相互作用协作，已到达这个用例目的。用例提供了系统及其环境的外部黑盒视图。在系统对象间双向发送消息及事件。 图5-1是一个典型的用例图。（可选的）矩形框系统的边界，人形图标代表参与者，椭圆形表示用例。参与者和用例之间的连线表示关联，借助关联可以交换信息。用例可能同其他用例间存在关系，图中所显示的从一个用例泛化为另一个用例既体现了这种关系。但是，用例不定义甚至不暗指任何特定的内部系统结构。用例通过对象间的协作来实现。这些协作由一组一起工作的对象组成，用来完成用例对应的功能。对象经常会参与到多个用例中，这使得问题变得更加复杂。 图5-1 用例图 5.22消息和事件 记录用例并给出相关的参与者，以及参与者和系统间传递的消息及相关属性与交互协议。 消息是发送者和接受者之间信息交换的抽象。消息交换的确切机制的实现细节在用例分析过程中是被忽略掉的。不过，消息往往必须具备一些必要的属性，以便刻画系统的功能及服务质量需求。 从逻辑的角度，消息包含如下几个方面，首先也是最显而易见的是消息的语义内容（semantic content）。语义内容就是消息的含义，例如“插入控制棒”或者“现在的温度为576度”。消息的结构称为特征标记（singnature），在对实时系统的需求分析中要建立一个参数列表，用于帮助理解黑盒层次的系统抽象。前置条件不变式和后置条件不变式是两种本体状态，分别在消息发送前和接受后假定为真。如果系统中消息必须按事先定义好的序列发生，或系统要根据当前的存在状态对消息的变化性作出响应，则系统中必须对这些不变式予以特别考虑。消息的服务质量（quality of services (Qos)）特性同样是很重要的。在大多数实时系统或嵌入式系统中，消息的到达模式和消息的同步模式必须被完整地定义，同时也可以定义其他的Qos属性，如可靠性等。 事件可以触发消息的发送。事情会在对系统有一定意义的某个时空中发生。外部环境中发生的事件可以表现为系统要对其作出响应的消息。UML定义了四种事件构造型：信号事件、调用事件、变更事件和时间事件。信号与异步的信号事件相关联。信号是请求的子类型；请求反过来与UML元模型中的MessageInstance相关联。CallEvents是操作调用或服务请求的结果所引发的事件。CallEvents与OperationCalls相关联；而OperationCall也是request的一个子类型。在值得注意的数值发生变化时会引发change事件。Time事件既可以在指定的时间段逝后发生，也可以在系统到达某绝对时间点的时候发生。所以这些事件类型都与用例分析相关，但最常见的是Signals. 5.2.3场景、协议和状态机 用例是对系统的一个内聚的功能块的定义。用例的实例是执行该行为的一条特定路径，这样的路径称作场景。场景由一个对象集合（这里，有些对象是“系统”对象。另外一些则来自参与者集合）和在对象间交换的一个有序的消息列表组成。场景中有一些分支点，在这些分支点上，对参与者或系统的响应或动作可能有多个。具有一组独立分支点集合的执行路径就构成了一个单独的场景，这样就需要多个场景才能完整地细化一个用例。 场景中既包含主要分支点，也包含里外分支点。通常，至少要为每一个分支点的一个场景进行建模。如果几个场景仅在例外分支点方面有所不同，通常可以被忽略掉，也不需要去考虑的。 例如，空中交通控制系统中的一个用例可能是“确定飞机的航线”，即系统要根据主雷达（表面反射）和/或辅助雷达（转发信号请求）确定一条航线，将该航线通知给先前给定的飞机，或者也可以开辟新航线。需要关注的场景包括： 主雷达和辅助雷达给出的航线相同，且与某架先前给定的飞机的预定位置相符。 只有主雷达给出了航线，并且与某架先前给定的飞机的预定位置相符。 只有辅助雷达给出了航线，并且与某架先前给定的飞机的预定位置相符。 只有主雷达给出了航线，并且，根据最近的位置和飞行性能推断，与两架已知飞机的可能飞行路线相符。 主雷达和辅助雷达给出的航线相同，但没有一架已知的飞机的预定位置与之相符（领空中进入新飞机）。 主雷达和辅助雷达给出的航线有很大不同（无法判定是一架飞机还是两架）。 场景的参考图5-2. 场景之间存在很大的不同，因为系统在这些场景中的行为都各不一样。并不是所有的场景差异都是我们所要关心的。比如这样一个场景，领空中所出现的其他飞机的航线与新航线偏差很大，就确定新航线而言，系统的行为无需改变。给所有场景建模是不可能的，这是因为场景的全集是无穷大的，或者接近于无穷大，场景间差异已经无关紧要。尽管如此，我们还是要对所有值得注意的场景，也就是能够使系统的行为产生本质改变的场景建