信息系统分析与设计案例2010-2.pptVIP

第二部分 内容 简介 -1 用例对用户眼中的系统功能进行建模，即到目前为止用户所关注的系统做什么，它所做的对用户有价值的事情。 用例模型提供了一种对需求调查阶段所获得的大量信息进行组织、分类和记录的一种方式； 因此，它是开发过程中需求定义的一个组成部分。 用例通常用图形表示，即用例图，并且被文本描述（用例描述、参与者描述和场景）所支持。 用例图和支持文本都是简单的和直观的，它们是理想的工具用于同用户讨论和清楚表明开发者对用户需求理解。 简介 -2 一旦用例模型完成并同用户一起检查，它就形成一个结构化信息的基础源，系统其它的模型都能在其基础上作出。用例模型对系统的测试也是有帮助的。 用例建模时在面向对象软件开发过程的不同阶段进行的。在各个阶段的信息类型和详细程度取决于模型的用途。 在开发的早期阶段，用例模型的主要目的是用于同用户沟通，不包括系统详细设计和实施的信息。随后，诸如用户界面的设计这样相关的技术细节被增加，以便为编程人员提供信息。 用例图 用例模型由用例图、一组用例描述、一组参与者描述和一组场景组成。 用例图使用四个概念对问题领域进行图形化建模：用例（use case）、参与者（actor）、关系连接（relationship link）和边界（ boundary） 图 2.1 表示了Wheels案例研究的一个用例图。新系统的功能被分解成5个用例：维护自行车登记表（Maintain bike list）、维护顾客登记表（Maintain customer list）、处理询问（Handle enquiries）、出租自行车（Issue bike）、以及处理自行车返还（Handle bike return）。 概念上，用例图类似于顶层菜单，其列出了系统做的5个主要的事情。 确定用例 -1 根据参与者确定用例 我们看到了Annie和Simon开始谈论的是如何出租自行车，这是Annie每天主要的工作任务之一 。因此，出租自行车是一个用例。出租自行车包括找出合适的自行车，计算租金，收钱，给收据，以及记录顾客和租赁交易的细节。 然后，会谈涉及到关于自行车返还处理的讨论。Annie将这当做与出租自行车分开的任务，因为其在时间上上是不同的，并且涉及一组不同的过程：检查日期、检查自行车的车况、以及返还押金。 确定用例 -2 根据参与者确定用例（续1） 在会谈中Annie告诉我们，一个自行车的登记表已经存放在计算机中，但是不能用来帮助他们进行工作。这个自行车登记表需要 如此存储，以便其能用来回答诸如此类问题的询问：Wheels有什么样的自行车、是否这些车可以租借、它们的押金是多少、租金是多少，如此等等。维护这个自行车登记表是另一个用例。 处理询问被Annie视作是与出租自行车不同的另外任务。她经常遇到有人到商店或打电话来仅仅为了了解有哪些自行车可以租借，以及费用如何。有时这种询问会导致租借，但更多的时候不会导致自行车的租借。因此，我们能确定“处理询问（Handle enquiries）”是一个单独的用例。 确定用例 -3 根据参与者确定用例（续2） 在会谈中，发现顾客的信息，以及他们以前租借自行车的记录没有被保存。而这类信息从市场营销的角度是非常有用的，其能简化对相同自行车租借的处理（参见问题定义图2.2、问题和需求列表图2.3、以及会谈总结图2.4。因此，维护顾客登记表(Maintain customer list)能被确定为一个用例。 用例场景 -1 根据用例场景确定用例 一个场景描述了用户和系统之间一系列的交互以便达到特定的目的。 一个场景描述了一个特定的事件序列，例如，当Annie成功地将自行车出租给用户时将会发生什么事情 （参见 图 2.5）。 取决于所在的阶段，系统开发人员能够使用场景来描述在一个情况下实际发生什么（或者，可能已经发生什么），或者他们要求在新系统中将要发生的事情。 用例场景 -2 根据用例场景确定用例（续） 一个精心研究的场景既描述了系统的典型应用，又描述了系统的例外的应用，它是一个非常好的工具，用来理解系统做什么，以及它是如何使用的。 她是一个从下到上理解系统的方法。你从了解系统如何被使用的细节着手，以此发现整个的目标和目的是什么，进而理解用例是什么。 每个用例代表了一组场景。属于同一用例的场景有共同的目的，而在这个组中的每个场景描述了涉及达到（或不能达到）这个用例目的的一个不同的事件序列。 图2.5 和图2.6 描述了属于出租自行车(Issue bike)用例的场景；在两种情况下，Annie都试图将一辆自行车出租给一位顾客。 用例场景 -3 场景应该用文档记录 一个典型的事件序列导致达到用例的目的，即一个顾客租到了一辆自行车。 明显地，有些特殊情况，例如：一