活动： 用例分析
目的
|
|
| 步骤 | |
| 输入工件： | 生成工件： |
| 频率：每次迭代进行一次，适用于一组工件：用例实现 | |
| 角色：设计员 | |
| 详细信息： | |
| 工具向导： | |
| 工作流程明细： |
补充用例说明 
目的
|
在查找分析类以及它们的对象时，仅对每个用例进行说明往往还不足够。一般情况下，客户对有关系统内部情况的信息不感兴趣，因此在用例说明中就可能遗漏了这些信息。在这种情况下，用例说明读起来就象是一份“黑盒”说明，因为说明省略了有关系统响应主角动作的内部详细信息，或者有关说明解释非常粗略。要查找执行用例的对象，您需要有一份从内部角度观察系统响应的“白盒”说明。
示例
在有关自动柜员机 (ATM) 的情况中，该系统的客户很可能会说：
“ATM 机用来验证银行客户卡。”
以此说明系统的用户身份验证行为。 虽然以上说明对客户而言可能是足够的，但是它并没有给我们任何具体的说明：ATM 机内部实际发生了什么操作来对卡进行验证。
为了从内部角度说明系统实际工作的方式，并且使说明达到确定各个对象的详细程度，我们可能需要更多的信息。以 ATM 卡确认活动为例，详细的说明如下所示：
“ATM 机向 ATM 网络发送要求验证的客户帐号和 PIN。如果客户帐号和 PIN 匹配，ATM 网络返回验证成功，批准客户进行交易；否则 ATM 网络返回验证失败。”
此程度的详细信息为我们提供了一个清晰的概念，即需要什么样的信息（帐号和 PIN）以及由谁负责身份验证（ATM 网络，它是用例模型中的一个主角）。从这一信息中，我们可以确定两个可能存在的对象（即一个具有客户帐号和 PIN 属性的 Customer 对象和一个 ATM 网络接口）以及它们的职责。
检查用例说明以确定系统的内部行为是否已明确定义。系统的内部行为应清晰明白，这样才能明确系统必须做什么。没有必要定义系统内负责执行行为的元素（对象），只要清楚地定义需要做什么即可。
提供此详细程度的信息的人员包括能够帮助确定系统需要执行什么操作的领域专家。在考虑系统的某个特定行为时，可以提出一个针对性很强的问题：“执行此行为对系统意味着什么？”如果没有明确规定系统需要进行什么操作来执行此行为，就无法回答上述问题，因此可能需要发现更多的信息。
以下是补充说明事件流的备选方案：
- 完全不说明。认为协作图本身清晰易懂或者相关用例的事件流提供了足够的说明时，就可能出现此情况。
- 补充已有的事件流说明。如果现有的文本在某些方面没有明确规定系统应执行的操作，则对其中的事件流进行补充说明。
- 作为一个完整的文本流来说明，独立于“外部”的用例事件流说明。这种方案适合系统的内部行为与外部行为几乎没有相同之处的情形。在这种情况下，必须保证说明是完全独立的。
从用例行为中查找分析类
目的
|
查找一组备选的分析类是系统从纯粹说明所需行为到具体描述系统工作方式的转换过程中的第一步。在此过程中，分析类用来表示模型元素的“角色”，这些元素提供了满足用例指定的功能性需求以及补充需求指定的非功能性需求的必需行为。当项目的工作中心转移到设计时，这些“角色”就演进为实现用例的一组设计元素。
用例分析中确定的角色主要说明系统最上层的行为 - 应用程序专用行为和领域专用行为。边界类和控制类通常演进为应用程序层的设计元素，而实体类则发展为领域专用的设计元素。较低层设计元素通常从分析机制演进而来，分析机制的使用对象是在这里确定的分析类。
这里说明的技术从三种不同的系统角度来识别备选类。这三种角度分别是系统与其主角之间的边界角度、系统所用信息角度以及系统控制逻辑角度。边界、实体和控制等相应的类构造型都在分析期间使用，而不在设计期间使用。
确定类仅仅表示应对这些类进行标识、命名以及使用几个句子作简短说明。
有关确定分析类的详细信息，请参见指南： 分析类。有关用例实现的详细信息，请参见指南： 用例实现。
将行为分配给分析类
对每一个独立的分支流（场景）：
- 创建一个或多个协作图。用例的主事件流通常至少需要一个图来说明，再加上每一个备选/异常事件流也至少需要一个图来说明。具有多个复杂时间点或者判定点的分支流通常需要用不同的图来说明，而复杂流因为太长而无法用一个图来把握时也需要用不同的图来说明。
- 确定分析类，通过单步执行场景的事件流负责所需行为，确保在用例实现中提供了用例需要的所有行为。
- 阐明协作图中分析类的交互。协作图还应当显示系统和它的主角之间的交互（由于主角始终调用用例，因此协作就应当从主角开始）。
- 包含代表所用用例的控制类的类。（对每一个扩展用例都使用一个独立的协作图，其中只显示该扩展用例的不同行为。）
用例接收储存项的协作图。
说明职责
目的
|
| 工具向导：使用 Rational Rose 记录类的职责 |
职责是要求某个对象执行的事务规定。职责在设计中演进为类的一个操作（但通常是几个）；它们按特性可以归纳为：
- 对象可以执行的操作。
- 对象保留并提供给其他对象的知识。
每一个分析类应当具有几个职责；仅有一个职责的类可能过于简单，但是一个类具有十几个或更多职责则将逼近职责的极限数量，应该将其划分成几个类。
不言而喻，所有的对象都可以创建和删除；无需重申这个显而易见的事实，除非对象在创建或删除时执行某个特殊行为。（存在某些关系时，有些对象就不能被删除。）
查找职责
职责是从协作图提供的消息中得到的。对每一条消息，检查向其发送消息的对象所属的类。如果职责尚不存在，则创建一个新的职责以便提供需要的行为。
其他职责将从非功能性需求中得到。创建新的职责时，请检查非功能性需求以确定其中是否有适用的相关需求。要么对职责的说明进行补充，要么创建新的职责来反映非功能性需求。
记录职责
用简短的（最多几个单词）职责名称和简短的（最多几个句子）说明记录职责。该说明表述对象实现职责需要执行什么操作，以及调用职责时将返回什么结果。
说明属性和关联关系
目的
|
为履行职责，类经常依靠其他类来提供必需的行为。关联关系记录了类之间的依赖关系，并帮助理解类的耦合；较好地理解类的耦合，并在可能的情况下减少耦合度，可以帮助我们构建更好的、更有弹性的系统。
以下步骤定义了类的属性以及类之间的关联关系：
确定属性
类使用属性来存储信息。具体而言，信息属于以下情况时，需要使用属性：
- “通过值”引用；即在信息中只有值是重要的，而与地址或对象标识符无关。
- 由其所属的对象唯一“拥有”；其他对象都不引用这条信息。
- 通过获取、设置或者执行对信息的简单转换的操作进行访问；信息除了提供它本身的值以外没有任何“实际”的行为。
另一方面，如果信息具有复杂的行为，被两个或更多对象共享，或者在两个或更多对象间“通过引用”传递，此时信息应当作为一个单独的类来构建模型。
属性名称应当是一个名词，它清楚地表述了属性保留的信息。
属性说明应当说明属性中将要存储的信息；如果从属性名称可以很明显地看出所存储的信息，则可以选择该方法。
属性类型就是属性的简单数据类型。示例类型包括字符串、整型、数值型等。
建立分析类之间的关联关系
从研究在将行为分配给分析类中产生的协作图内的链接开始。类之间的链接指明两个类的对象需要互相交流，以便执行用例。 开始设计系统后，这些链接可以通过几种途径实现：
- 对象具有“全局”范围，在这种情况下，系统中的任何对象都可以向它发送消息。
- 一个对象可以作为一个参数传递给第二个对象，此后它可以向被传递对象发送消息。
- 对象可以和消息发送的目标对象之间建立永久关联关系。
- 对象可以在操作范围内创建和破坏（即“临时”对象），因为这些对象都被认为是操作“特有的”。
然而，在类的“生命”早期时刻就开始做出决定，未免为时太早了：我们还没有作出明智决策所需要的足够信息。因此，在分析中我们创建关联关系和聚合关系以表示（和“传递”）所有必须在两个类的对象之间发送的消息。（聚合关系是关联关系的一种特殊形式，它指明对象参与了一种“整体/部分”的关系（请参见指南：关联关系和指南：聚合关系））。
我们将在活动：类的设计中改进这些关联关系和聚合关系。
为每一个类绘制一个显示它和其他类关联关系的类图：
定单输入系统组成部分的分析类图示例
只需集中考虑实现用例必需的关联关系；不要添加您认为“或许”存在的关联关系，除非根据协作图要求添加这些关联关系。
赋予这些关联关系角色名称和多重性。
- 角色名称应当是一个名词，它表示被关联关系的对象在与关联关系对象的关系中承担的角色。
- 除非能给出明确的证据说明存在其他情况，否则多重性为 0..* （零对多）。零的多重性意味着关联关系是可选的；确保您的意图也是如此；如果某个对象不在其中，使用此关联关系的操作将需要做相应调整。
- 可以指定范围更狭窄的多重性（比如 3..8 之间）。
- 在多重性范围内，可以指定概率。因此，如果多重性为 0..*，而且期望它在 85% 的情况下介于 10 和 20 之间，则请将此信息记录下来；该信息在设计期间非常重要。例如，如果使用关系数据库来实施永久性存储，则范围更小的限制将会有助于更好地组织数据库表。
编写一份关联关系的简短说明，指明如何使用关联关系，或者关联关系表示了什么关系。
说明分析类之间的事件依赖关系
对象有时需要知道事件什么时候在某个“目标”对象中发生，而“目标”对象则不必知道所有这些在事件发生时需要通知的对象。作为表示这种事件通知依赖关系的简写方式，订阅关联关系允许以紧凑简练的方式表示这种依赖关系。
两个对象之间的订阅关联关系指明在被订阅对象中发生某个特定的事件时，将通知订阅对象。订阅关联关系具有一项条件，它定义了使订阅者得到通知的事件。有关详细信息，请参见指南：订阅关联关系。
订阅关联关系的条件应利用抽象特征来表述，而不利用具体的属性或者操作来表述。这样，关联关系对象就可独立于可能经常变更的被关联关系实体对象的内容。
在以下情况下需要订阅关联关系：
- 如果一个对象受在另一个对象中发生的事件的影响。
- 如果必须创建一个新的对象以处理某些事件，比如当出现错误时必须创建一个新的窗口来通知用户。
- 如果一个对象需要知道另一个对象什么时候被实例化、变更或者破坏。
“被订阅”对象通常是实体对象。通常，实体对象是信息的被动存储，而且任何行为一般都和它们的信息存储职责有关。很多其他的对象经常需要知道实体对象变更的时间。订阅关联关系则避免了实体对象必须知道所有其他对象的情况发生 - 它们只是“登记”了实体对象中有关信息，并且在实体对象变更时获得通知。
但现在这些实际上都只是一种“分析戏法”：在设计中我们必须确定这种通知的实际执行方式。我们可以购买一个通知框架，或者我们可能需要自己设计和构建一个框架。但对眼前来说，只要指出这种通知存在就足够了。
该关联关系指导说明只有订阅对象知道这两个对象之间的关系。订阅说明全部包含在订阅对象中。而被关联关系的实体对象仍以通常的方式定义，它不必考虑其他对象是否对其活动感兴趣。这也意味着订阅对象可以加入到模型中，或者从模型中删除，而不用改变它所订阅的对象。
限定分析机制
目的
|
如果分析类使用了一种或几种分析机制，现已得到的有关附加信息将帮助构架设计师和设计人员确定构架设计机制应该具备的性能。分析类的实例数目、它们的大小、访问频率、以及预期的寿命等重要特征可以帮助设计员选择合适的机制。
在分析类使用的每一种分析机制中，限定在选择合适的设计机制与实施机制时必须考虑的相关特征。这些特性因机制类型不同而有差异；根据情况，或者如果存在很大程度的不确定性，则给出一个范围。不同的构架机制具有不同的特征，因此这种信息纯粹是说明性的，只需按照获取和传送信息的需要进行组织即可。在分析过程中，这种信息通常有很大的推测性，但是获得该信息很有价值，因为当更多的信息被揭示后，可以对推测得到的估计进行修正。
无须正式记录类所使用的分析机制以及它们的关联关系特征；在图中加上附注，或者对类的说明进行补充就足以表达这样的信息。此时，在类的演进过程中，特性信息不稳定，具有一定的推测性，因此重点是记录期望值，而不是规范机制的定义。
示例
航班类使用的永久性机制的特征可以限定为：
粒度：每个航班占用 2 到 24 千字节
容量：上限为 100,000
访问频率：
- 创建/删除：每小时 100 次
- 更新：每小时 3,000 次
- 读取：每小时 9,000 次存取
示例
任务类使用的永久性机制的特征可以限定为：
粒度：每个任务占用 2 到 3 兆字节
容量：4
访问频率：
- 创建/删除：每天 1 次
- 更新：每天 10 次
- 读取：每小时 100 次
评估用例分析结果
目的
|
在研讨班结束和活动： 用例分析完成时同时进行一项非正式的复审。
