软件系统分析与设计-6--面向对象分析设计.ppt

* * * * * * 6.3.2 用例建模 §6.3 用例模型设计 用例视图应该是客户、最终用户、领域专家、测试人员和任何其他设计系统的人员。不需要详细了解系统结构和实现就容易理解的。用例视图不描述软件系统的组织或结构，它的作用是给设计者施加约束，设计者必须设计出一个能够提供用例视图中指定的功能的结构。 一组用例是一个系统的用户能够使用系统完成的不同任务。用例一般是由分析人员与系统未来用户进行磋商而确定的。 * * 6.3.2 用例建模 §6.3 用例模型设计 例子：开发一个餐馆预约系统，为顾客预定和分配餐桌的过程，当前是手工预约，用保存在一个文件夹中的手写预约单。 预约单中的每一行对应参观中一张特定的餐桌。预约是对特定的一个餐桌登记的，每个预约中记录有“餐具”的数目，或者预约进餐者的数目，这样就能够分配一个大小适当的餐桌。该餐馆在晚间供应三次餐点，成为“简餐”、“正餐”和“晚点”时段。但如同期预约单所表明的，这些时段无须严格遵守，可以预约跨多个时段的时间。每个预约中要记录联系人的姓名和电话。 * * 6.3.2 用例建模 §6.3 用例模型设计 为了记录这种情况，要在预约单加上一个注释。当一行用餐者到来并在他们的餐桌就座时，就划掉相应的预约登记。如果他们就座的不是他们预约的餐桌，就画一个箭头从最初预约的餐桌指向新的餐桌。如果顾客打电话取消预约，并不能从表中真正地删除，而是做一个预约已经取消的注释。其他的信息，比如到什么时候餐桌必须空出来，也可以写在预约单上。 如果有空闲的餐桌，用餐者当然也可以不提前预约就餐，这被称为“未预约的顾客”，并在预约单中作为预约登记以表示餐桌的占用，但是不登记顾客的姓名和电话。 * * 6.3.2 用例建模 §6.3 用例模型设计 对计算机系统的需要 系统必须易于记录餐馆营业时发生的有意义的事情，例如顾客的到来。系统的操作应当尽可能是直接操作屏幕上显示的数据。例如，可以简单地将预约拖动的屏幕上的一个适当的位置以改变一个预约的时间或者分配的餐桌。 2. 迭代 迭代和增量的方法建议，一个系统第一次迭代应该只交付足够使系统提供某些确定的商业价值的核心功能。本例中餐馆在营业时间记录预约和更改新预约单信息是核心功能。 * * 6.3.2 用例建模 §6.3 用例模型设计 3. 用例 餐馆预约系统第一次迭代的意图是允许用户使用一个自动化的预约单。可以通过考虑在系统实现后餐馆员工能够用它来做什么，简单地草拟出这次迭代的一组初步的用例。下面列出了这次用例所支持的主要任务： （1）记录一个新的预约信息（“记录预约”）。 （2）取消一个预约（“取消预约”）。 （3）记录一个顾客的到来（“记录到达”）。 （4）将一个顾客从一张餐桌移到另一张（“调换餐桌”）。 * * 6.3.2 用例建模 §6.3 用例模型设计 4.参与者 一个用例描述了系统及其用户之间的一类交互。人与系统在进行交互是能够担任的不同角色称为参与者(actor)。参与者一般对应于对系统一个特定的访问级别，它由参与者能够执行的系统功能类别定义。 本例中所提出的用例可以分成两组：一组由维护提前预约信息有关的用例组成——提前预约和取消预约。一组记录顾客到来和可能的餐桌调换。 * * 6.3.2 用例建模 §6.3 用例模型设计 5.用例图 用例图(use case diagram)以图解的形式概括了系统中的不同参与者和用例，并显示哪些参与者能够参与哪些用例。 时间中不值得花更多的时间细化用例图，重要的是描述每一个用例指定的行为细节。 图6-16 初始用例图 * * 6.3.3 描述用例 §6.3 用例模型设计 店员被认为是接待员参与者的一个实例，发生在接待员与系统之间的交互是用例的一个实例。 在用例的不同实例中将发生什么样的细节，会在很多方面有所不同。例如接待员必须要为每个新的预约输入特定的数据，如不同顾客的姓名和电话号码，这些数据在各个实例中都不尽相同。 更值得注意的是，一个用例实例中可能会出现差错，如在用户要求的时间没有适合的餐桌，用例实例可能实际上将不会导致进行一个新的预约。一个用例的完整描述必须指明，在用例所有可能的实例中可能发生什么。 * * 6.3.3 描述用例 §6.3 用例模型设计 1）事件路径 用例描述必须定义在执行用例时用户和系统之间可能的交互。这些交互可以作为一种对话描绘。交互可以区分为“正常”交互和其他各情况的交互，出错导致不能完成正常的交互（异常），特殊情况中一些可选功能被调用等。