活动:
|
用途
|
|
角色:设计员 | |
频率:每个迭代一次,针对一组用例和/或用例场景(在当前迭代中开发的)。 | |
步骤
在当前迭代中,为每个用例执行以下步骤: 以下步骤每个迭代执行一次: 注意:上述步骤是以逻辑顺序列出的,但您可能必须在各个步骤之间交替,或者并行执行某些步骤。 |
|
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
用途 | 创建用来表达用例行为的建模元素。 |
用例形成了大多数早期分析和设计工作的中心焦点。为了实现以需求为中心的活动和以分析/设计为中心的活动之间的移交,工件:用例实现充当了桥梁,提供一种将分析与设计模型中的行为回溯到用例模型的方式,并围绕着“用例”概念组织协作。
如果还不存在分析用例实现,则在分析模型中针对用例创建一个分析用例实现。分析用例实现的名称应该与相关联的用例相同,并且应建立从分析用例实现到其相关联用例的“实现”关系。
有关用例实现的更多信息,请参阅指南:用例实现。
用途 | 记录为了解所要求的系统内部行为而需要的其它信息,为系统客户编写的用例描述中可能缺少这些信息。 |
每个用例的描述并非总是足以用来查找分析类和它们的对象。客户一般对关于系统内部所发生情况的信息不感兴趣,所以用例描述可以不考虑这样的信息。在这些情况下,用例描述读起来就像是“黑盒”描述,其中关于系统执行什么操作来响应参与者操作的内部细节不是没有就是描述得很简略。要找到执行用例的对象,就必须具有关于从内部角度看系统执行了什么操作的“白盒”描述。
示例
在自动柜员机(ATM)的情况下,系统客户可能更愿意说
“ATM 验证银行客户卡。”
来描述系统的用户认证行为。对客户来说,这可能就足够了,但我们并不真正知道 ATM 内部实际是怎样来验证卡的。
为了对系统的工作方式进行内部描绘,能足够详细地确定对象,我们可能需要其它信息。以 ATM 卡验证活动为例,扩展后的描述可能是这样的:
“ATM 将客户的帐号和 PIN 发送到 ATM 网络进行验证。如果客户号码和 PIN 匹配,客户获得授权进行交易,ATM 网络就返回成功消息,否则 ATM 网络返回失败消息。”
这样的详细程度使读者能清楚地了解需要什么信息(帐号和 PIN)以及谁负责认证(ATM 网络,用例模型中的参与者)。根据这些信息,我们可以确定两个可能的对象(“客户”对象,属性为帐号和 PIN;和 ATM 网络接口)以及它们的职责。
检验用例描述,查看系统的内部行为是否得到了明确的定义。系统的内部行为应该是明确的,这样系统必须做什么就很清楚了。没有必要定义系统内负责执行该行为的元素(对象)- 只要清楚地定义需要做什么就可以了。
这些详细信息的来源包括帮助定义系统需要做什么的领域专家。在考虑系统的特定行为时,一个很值得问的问题是“系统这样做有什么意义?”。如果对系统为执行该行为所做的操作的定义不足以回答该问题,就可能需要寻找更多的信息。
以下备选方法可补充事件流的描述:
用途 | 确定将能执行用例中所述行为的一组候选模型元素(分析类)。 |
在系统从纯粹陈述所要求的行为转换到描述系统如何工作的过程中,第一步就是查找一组候选分析类。在该工作中,分析类用来表示模型元素的角色,这些模型元素提供满足用例指定的功能需求和补充需求指定的非功能需求所必要的行为。因为项目的关注对象转到了设计,所以这些角色转变了一组实现这些用例的设计元素。
用例分析中确定的角色主要表示系统应用程序特定行为和领域特定行为的最高层次行为。边界类和控制类通常转变为应用层设计元素,而实体类则转变成特定于领域的设计元素。较低层的设计元素通常是从这里确定的分析类所使用的分析机制转变而来的。
这里所述的技能通过系统的三个不同透视图来促进候选类的确定。这三个透视图是系统与其参与者之间边界的透视图、系统使用的信息以及系统的控制逻辑。相应的类构造型、边界、实体和控制是在“分析”期间为方便而使用的,它们在“设计”期间消失。
类的确定只意味着:它们应得以确定、命名并用几个句子简短地描述。
有关确定分析类的更多信息,请参阅指南:分析类。有关分析用例实现的更多信息,请参阅指南:用例实现。
如果特定分析机制和/或分析模式已经记录在项目特定指南中,它们就应该用作分析类的另一个“灵感”来源。
用途 | 根据协作的分析类来表示用例行为。确定分析类的职责。 |
对每个独立的子流(场景):
用例接收堆积物项的通信图。
如果特定分析机制和/或分析模式已经记录在项目特定指南中,它们就应该反映在职责分配和所生成的交互图中。
用途 | 描述从用例行为中确定的对象类的职责。 |
职责是关于可要求对象提供的内容的陈述。职责演变为设计中的类上的一个(但通常为多个)操作;它们的属性可以描述为:
每个分析类都应有几个职责;只具有一个职责的类可能太简单了,而有十几个甚至更多职责的类就可能超出职责的极限,这样的类可能应分成几个类。
所有对象都可以创建,也可以删除,这是不言而喻的;除非对象在创建或删除时执行某一特殊行为,否则不要重申明显的事实。(如果存在某些关系,就不能删除某些对象。)
职责是从交互图的消息派生而来的。对于每条消息,检验发送消息的目标对象的类。如果职责尚未存在,则创建一个新的职责,该职责提供所请求的行为。
其它职责将从非功能需求派生而来。创建新的职责时,请检查非功能需求,看看是否有适用的相关需求。要么补充职责的描述,要么创建新的职责来反映这一情况。
职责是用职责的简称(最多几个字)和简短描述(最多几个句子)进行记录的。该描述陈述对象为履行职责所做的事,以及在调用职责后返回的结果。
用途 | 定义分析类所依赖的其它类。 定义该类必须了解的其它分析类中的事件。 定义该分析类负责保留的信息。 |
为了履行职责,类通常依赖于其它类来提供所需要的行为。众多关联记录类之间的关系,并帮助我们了解类的结合;更好地了解类结合并尽可能减少结合情况,这可帮助我们构建更好、更有弹性的系统。
以下步骤定义类的属性以及类之间的关联:
属性由类用于存储信息。特别地,属性在信息符合以下条件的情况下使用:
另一方面,如果信息有复杂的行为、由两个或多个对象共享或者“通过引用”在两个或多个对象间传递,该信息就应该建模为单独的类。
属性名称应该是一个名词,清楚地说明属性具有哪些信息。
属性的描述应该描述属性中要存储什么信息;当存储的信息从属性名称来看很明显时,这是可选的。
属性类型是属性的简单数据类型。示例包括字符串、整数、数字。
首先研究将行为分发给分析类中生成的交互图中的链接。类之间的链接表示两个类的对象需要彼此交流以执行用例。一旦我们开始设计系统,这些链接就可以用几种方式实现:
但是,在类的“生命”的这一早期时刻就开始作出这些决定,这太早了:我们还没有足够的信息来作出经过深思熟虑的决定。结果,我们在分析中创建关联和聚集来表示(并“携带”)必须在两个类的对象之间发送的任何消息。(聚集是关联的一种特殊形式,表示对象参与“整个/部分”关系(请参阅指南:关联和指南:聚集))。
我们将在活动:类设计中改进这些关联和聚集。
为每个类绘制一张类图,显示每个类与其它类的关联:
部分订单输入系统的分析类图示例
只关注实现用例所需的关联;不要添加您认为“可能”存在的关联,除非它们是必需的(基于交互图)。
给出关联角色的名称和多重性。
请撰写一份关联的简述,表明如何使用关联,或者该关联代表什么关系。
对象有时需要知道,事件在某个“目标”对象中何时发生,而“目标”不必在事件发生时知道要求得到通知的所有对象。预订关联是显示这一事件通知依赖关系的简单表示法,它允许我们简洁明了地表示这种依赖关系。
两个对象之间的预订关联表明,当预订的对象发生特定事件时,将会通知预订方对象。预订关联有一个条件,定义使订户得到通知的事件。有关更多信息,请参阅指南:预订关联
预订关联的条件应该根据抽象属性来表示,而不应根据其特定的属性或操作。这样,关联方对象得以保持对所关联实体对象的内容(将会更改)的独立性。
以下情况下需要预订关联:
“预订的”对象通常是实体对象。实体对象通常被动地存储信息,其任何行为一般都与它们的信息存储职责相关。许多其它对象常常需要知道对象实体何时更改。预订关联使实体对象不必了解所有这些另外的对象 - 它们只“表示”对实体对象感兴趣,并会在实体对象更改时收到通知。
现在这一切还只是“分析手法”:在设计中我们必须定义这种通知到底是如何起作用的。我们可能会购买通知框架,或者我们可能必须自行设计并构建一个框架。但此时只要记住,有通知存在就足够了。
关联的方向显示,只有预订方对象知道两个对象之间的关系。预订的描述完全在预订方对象之内。反过来,相关联的实体对象是以常规方式来定义的,没有考虑其它对象也可能对该对象的活动感兴趣。这也意味着,可以对模型添加或删除预订方对象,而不更改所预订的对象。
用途 | 协调单个分析用例实现,并确定一组有一致关系的分析类。 |
分析用例实现是因为分析特定用例而制定的。现在需要协调单个分析用例实现。检验为每个分析用例实现定义的分析类和支持的关联。确定并解决不一致情况,并去除任何重复情况。例如,两个不同的分析用例实现可能包含概念上相同的一个分析类,但因为分析类是由不同的设计人员确定的,故使用了不同的名称。
注意:如果软件设计人员很好地定义了初始体系结构,分析用例实现之间的重复情况就会大大减少(请参阅活动:体系结构分析)。
协调模型元素时,考虑它们的关系是很重要的。如果两个类被合并起来,或者一个类替换了另一个类,则务必将原始类的关系传递给新的类。
软件设计人员应该参与协调分析用例实现,因为它要求了解业务环境以及对软件体系结构和设计有某种预见性,这样就可以选择最好地代表问题和解决方案领域的分析类。
有关类的更多信息,请参阅指南:分析类。
用途 | 确定分析类使用的分析机制(如果有)。提供关于分析类如何应用分析机制的其它信息。 |
在本步骤中,将检验适用于每个确定的分析类的分析机制。
如果分析类使用一个或多个分析机制,现在记录的其它信息将帮助软件设计人员和设计人员确定对体系结构设计机制要求的功能。分析类的实例个数、它们的大小、它们的访问频率以及它们的预测生命期是重要的属性,可帮助设计人员选择适当的机制。
对于分析类使用的每个分析机制,请限定在选择适当的设计和实施机制时所需考虑的相关属性。这些属性将因机制类型而异;给出适当的范围,或者在仍有许多不确定因素时给出范围。不同的体系结构机制将有不同的属性,所以这些信息是纯描述性的,只需在必要时进行结构化,以记录并传达信息。在分析期间,该信息通常是相当不确定的,但是值得记录,因为随着发现更多的信息,就可修改推测的估计值。
类使用的分析机制以及它们的关联属性不必正式记录;在图上附加注释或者扩展类的描述就足以传达信息了。在类的演进过程中,这时的属性信息是相当不确定的,所以重点在于记录预期的值,而不是将机制的定义规范化。
示例
Flight 类使用的永久性机制的属性可限定为:
粒度:每个 flight 为 2 到 24 千字节
容量:最多达 100,000
访问频率:
- 创建/删除:每小时 100 次
- 更新:每小时更新 3,000 次
- 读取:每小时访问 9,000 次
示例
Mission 类使用的永久性机制的属性可限定为:
粒度:每个 mission 为 2 到 3 兆字节
容量:4
访问频率:
- 创建/删除:每天 1 次
- 更新:每天 10 次
- 读取:每小时 100 次
用途 | 保持分析模型与其它模型之间的可跟踪性关系。 |
项目的项目特定指南指定了分析模型元素所要求的可跟踪性。
例如,如果存在用户界面的单独模型,那么将该模型中的屏幕或其它用户界面元素跟踪到分析模型中的边界类可能会很有用。
用途 | 验证分析对象符合在系统中提出的功能需求。 验证分析对象和交互是一致的。 |
在研讨会结束后开展一次非正式复审,作为活动:用例分析的同步点和结束。
对本活动输出的工件使用检查点。
Rational Unified Process
|