第6章 面向对象的分析与设计.ppt

第6章面向对象的分析与设计6.1面向对象分析6.1.1优化用例模型
用例模型，也就是用例图，它采用业务需求用例建模系统功能需求。在此期间，记录的用例仅仅包含了有关业务事件的一般性信息，其目标是快速地记录所有的业务事件（用例），以便定义和验证需求。通常在依据业务需求建模时，会生成用例图，但是为了文件管理及用户阅读，还会生成参与者词汇表、用例词汇表和用例描述表。参与者词汇表用例词汇表对用例图中的所有参与者、用例进行文字描述，分别见表6.1和表6.2。用例描述表对每个用例进行详细描述。当准备用例描述时，首先在高层记录，以便尽快理解系统的事件和量级，然后再回到每个用例，扩展它以完全记录业务需求描述。对于高层的用例描述，通常包括如下内容：作者、日期、版本、用例名称、用例类型、用例ID、优先权（表示用例的重要性）、来源（表示哪个实体触发用例的创建，该实体可能是一个需求、一个特殊的文档或者某个关联人员）、主要业务参与者、其他业务参与者、其他有利益的关联人员及描述。
用例描述的高层版本见表6.3。用例名称对于每个确定的事件，需要进一步扩展用例的典型事件过程和替代过程。用例的典型事件过程是从参与者发起用例直到业务事件结束的步骤描述，通常记录主要时间发生的主要步骤（典型过程）；替代过程即记录了用例的异常或例外分支。对于用例描述表的扩展版本，通常多了如下内容：前置条件、触发器（发起用例执行的事件）、典型事件过程、替代事件过程、结论（描述用例什么时候成功结束）、后置条件、业务规则（说明新系统必须服从的业务政策或规程）、实现约束和说明（表示可能影响用例实现和有助于构架规划的非功能需求）、假设（记录用例时作者做出的假设）及开放问题（在用例最终确定之前需要解决或研究的问题）。
用例描述的扩展版本见表6.4。用例名称而在进行面向对象分析时，对于每个以前定义的用例，将基于开发过程中了解到的事实对这些用例进行细化，让其包含更多的细节，如用户界面需求。为了准备进行对象建模，需要将业务需求用例模型转换成分析用例模型。1、确定、定义并记录新的参与者
在创建了业务需求用例模型和其最终被系统所有者批准之间，系统分析员和开发团队的其他成员通过与关联人员交换和研究项目发布物，继续了解系统成功还需要什么。通过这些努力，有可能会发现需求被定义和记录的额外参与者。2、确定、定义并记录新的用例
作为一般规则，用于处理业务事件的每种类型的用户接口都需要自己的用例。以银行业为例，在ATM中存款的用例将不用于在柜台存款的用例。处理的目的相同，许多步骤也相同，但实际的系统用户可能不同，用户采用特定的技术（ATM及为出纳设计的GUI界面）如何与系统交互可能不同。新确定的用例需要被定义到前面准备好的用例参与者词汇表中。3、确定任何复用的可能性
正如上一步所述，当两个用例有同样的业务目标但接口技术和实现的系统用户不同时，两个用例可能共享公共的步骤。为了消除冗余步骤，可以将这些公共步骤提取成独立的用例，称为抽象用例；当分析用例，发现用例包含多个步骤构成的复杂功能并且难以理解时，可以将更复杂的用例提取成专门的用例，称为扩展用例。新的用例也需要被定义到前面准备好的用例参与者词汇表中。4、细化用例模型图
由于发现了新的参与者和/或用例，需要修改前面构造的用例模型图以包括这些新的内容，并完成新的用例描述表。5、记录系统分析用例描述
一旦修订了所有的业务需求并被用户批准，将细化每个用例包含更多的信息以便详细地说明系统功能。把得到的用例称为系统分析用例，该用例没有太多的实现细节，除了描述系统用户用来与系统交互的手段（WindowsGUI、Internet浏览器、电话等）的高层信息。系统分析用例包含从系统用户角度的描述。从与系统交互的角度看，系统分析用例比业务需求用例（需求阶段的用例）交互得更自然。
系统分析用例在生命周期的设计阶段将被进一步细化，以说明如何实现。在进入设计阶段之前，所有开放的问题和要确定的问题都被解决了，这一点很重要，因为每个决策都会影响设计的特性。6、记录抽象用例描述和扩展用例描述
记录扩展用例和抽象用例的描述与记录常规用例的描述十分类似，但是有几个主要的区别。抽象和扩展用例不是由参与者发起的，而是由其他用例调用的。而且，抽象和扩展用例一般比较短，不需要那么多描述条件。此外，在“用例类型”中的选项为“抽象”和“扩展”。
抽象/扩展用例描述表的版本见表6.5。用例名称当被两个以上的用例调用时，可以采用抽象用例；当扩展单个用例的功能时，可以采用扩展用例。此外，抽象用例可以调用其他抽象和/或扩展用例，扩展用例也可以调用其他抽象和/或扩展用例，因此，这提供了许多用例的复用。
当完成系统分析用例的定义后，就可以开始确定用例中包含的对象了。这些对象表示了业务领域的事物或实体。在这里，先用一两句话集中描述这