搜索
信息系统分析与设计InformationSystemAnalysisandDesign1/55第二部分信息系统分析与设计InformationSystemAnalysisandDesign2/55用例用例图用例场景和用例描述参与者和参与者描述用例关系技术讨论内容信息系统分析与设计InformationSystemAnalysisandDesign3/55简介-1用例对用户眼中的系统功能进行建模，即到目前为止用户所关注的系统做什么，它所做的对用户有价值的事情。用例模型提供了一种对需求调查阶段所获得的大量信息进行组织、分类和记录的一种方式；因此，它是开发过程中需求定义的一个组成部分。用例通常用图形表示，即用例图，并且被文本描述（用例描述、参与者描述和场景）所支持。用例图和支持文本都是简单的和直观的，它们是理想的工具用于同用户讨论和清楚表明开发者对用户需求理解。信息系统分析与设计InformationSystemAnalysisandDesign4/55简介-2一旦用例模型完成并同用户一起检查，它就形成一个结构化信息的基础源，系统其它的模型都能在其基础上作出。用例模型对系统的测试也是有帮助的。用例建模时在面向对象软件开发过程的不同阶段进行的。在各个阶段的信息类型和详细程度取决于模型的用途。在开发的早期阶段，用例模型的主要目的是用于同用户沟通，不包括系统详细设计和实施的信息。随后，诸如用户界面的设计这样相关的技术细节被增加，以便为编程人员提供信息。信息系统分析与设计InformationSystemAnalysisandDesign5/55用例图用例模型由用例图、一组用例描述、一组参与者描述和一组场景组成。用例图使用四个概念对问题领域进行图形化建模：用例（usecase）、参与者（actor）、关系连接（relationshiplink）和边界（boundary）图2.1表示了Wheels案例研究的一个用例图。新系统的功能被分解成5个用例：维护自行车登记表（Maintainbikelist）、维护顾客登记表（Maintaincustomerlist）、处理询问（Handleenquiries）、出租自行车（Issuebike）、以及处理自行车返还（Handlebikereturn）。概念上，用例图类似于顶层菜单，其列出了系统做的5个主要的事情。信息系统分析与设计InformationSystemAnalysisandDesign6/55确定用例-1根据参与者确定用例我们看到了Annie和Simon开始谈论的是如何出租自行车，这是Annie每天主要的工作任务之一。因此，出租自行车是一个用例。出租自行车包括找出合适的自行车，计算租金，收钱，给收据，以及记录顾客和租赁交易的细节。然后，会谈涉及到关于自行车返还处理的讨论。Annie将这当做与出租自行车分开的任务，因为其在时间上上是不同的，并且涉及一组不同的过程：检查日期、检查自行车的车况、以及返还押金。信息系统分析与设计InformationSystemAnalysisandDesign7/55确定用例-2根据参与者确定用例（续1）在会谈中Annie告诉我们，一个自行车的登记表已经存放在计算机中，但是不能用来帮助他们进行工作。这个自行车登记表需要如此存储，以便其能用来回答诸如此类问题的询问：Wheels有什么样的自行车、是否这些车可以租借、它们的押金是多少、租金是多少，如此等等。维护这个自行车登记表是另一个用例。处理询问被Annie视作是与出租自行车不同的另外任务。她经常遇到有人到商店或打电话来仅仅为了了解有哪些自行车可以租借，以及费用如何。有时这种询问会导致租借，但更多的时候不会导致自行车的租借。因此，我们能确定“处理询问（Handleenquiries）”是一个单独的用例。信息系统分析与设计InformationSystemAnalysisandDesign8/55确定用例-3根据参与者确定用例（续2）在会谈中，发现顾客的信息，以及他们以前租借自行车的记录没有被保存。而这类信息从市场营销的角度是非常有用的，其能简化对相同自行车租借的处理（参见问题定义图2.2、问题和需求列表图2.3、以及会谈总结图2.4。因此，维护顾客登记表(Maintaincustomerlist)能被确定为一个用例。信息系统分析与设计InformationSystemAnalysisandDesign9/55用例场景-1根据用例场景确定用例一个场景描述了用户和系统之间一系列的交互以便达到特定的目的。一个场景描述了一个特定的事件序列，例如，当Annie成功地将自行车出租给用户时将会发生什么事情（参见图2.5）。取决于所在的阶段，系统开发人员能够使用场景来描述在一个情况下实际发生什么（或者，可能已经发生什么），或者他们要求在新系统中将要发生的事情。信息系统分析与设计InformationSystemAnalysisandDesign10/55用例场景-2根据用例场景确定用例（续）一个精心研究的场景既描述了系统的典型应用，又描述了系统的例外的应用，它是一个非常好的工具，用来理解系统做什么，以及它是如何使用的。她是一个从下到上理解系统的方法。你从了解系统如何被使用的细节着手，以此发现整个的目标和目的是什么，进而理解用例是什么。每个用例代表了一组场景。属于同一用例的场景有共同的目的，而在这个组中的每个场景描述了涉及达到（或不能达到）这个用例目的的一个不同的事件序列。图2.5和图2.6描述了属于出租自行车(Issuebike)用例的场景；在两种情况下，Annie都试图将一辆自行车出租给一位顾客。信息系统分析与设计InformationSystemAnalysisandDesign11/55用例场景-3场景应该用文档记录一个典型的事件序列导致达到用例的目的，即一个顾客租到了一辆自行车。明显地，有些特殊情况，例如：一位顾客租借一辆以上的自行车，租借时间是一样的；一位顾客租借一辆以上的自行车，但每辆车的租借时间长短不一；一位顾客租借一辆特殊的自行车；等等。也有一些事件序列表示用例的目的不能达到，例如：顾客不能发现他所喜欢的自行车；顾客认为费用太高；等等。开发人员需要确信其理解并用文档记录了系统应该如何响应每一个可能发生的事件。小的、简单的用例利用用例描述就能充分地描述了。信息系统分析与设计InformationSystemAnalysisandDesign12/55用例描述-1什么是用例描述用例描述是一种描述性文档，其以普通的术语描述了用例的功能需求。典型地，它描述了用例的目的，给出了通常会发生什么的一般性描述，事件的正常过程，以及任何小的变化的简要描述。换言之，这种描述是概况的，其书写的方式是应该包括涉及用例的每一个事件序列和每一个场景。这种描述表明系统应该做什么，而不是它应该如何做。在这些情节后面的程序编写、数据存储结构、以及其它的实施细节不应出现在用力描述中，仅仅是用户能见到的发生事情。信息系统分析与设计InformationSystemAnalysisandDesign13/55用例描述-2高层次的用例描述有两种不同类型的用例描述是有用的。在软件开发的早期，此时关于系统设计，特别是系统用户界面的设计的详细决策没有被制定，一个简短的、非结构化的描述是足够的，这种描述被称为高层描述（参见图2.7）这些描述仅需要记录用例的目的，涉及的参与者、以及发生什么的总体概述。信息系统分析与设计InformationSystemAnalysisandDesign14/55用例描述-3扩展的用例描述随后，一个更详细的、结构化得描述是有用的，其被称为扩展用例描述（参见图2.8）。扩展用例描述比高层用例描述更详细，结构化更强。它应该记录：什么发生来触发用例哪些参与者被涉及哪些数据应该被输入用例的输出是什么用例需要哪些存储的数据什么发生来表示用例的完成事件序列的微小变化（图2.9）。信息系统分析与设计InformationSystemAnalysisandDesign15/55参与者与参与者描述-1参与者参与者在系统外部，他们代表了同系统交互，并从中获得某种收益的某些人或事物。通常，一个参与者是一位用户，但有时它是诸如银行或财务系统这样的其它系统；一个参与者也可以代表诸如打印机这样的硬件。一般而言，一个参与者是某个输入信息到系统或接收来自系统的信息（或二者具备）的实体。更严谨地，一个参与者代表了利用系统的一种特殊的方法；一种同系统交互以取得用例目的的方法。它经常被描述成某个实体在用例中所扮演的角色。Theactorsintheusecasediagramin在用例图图2.1中的参与者是管理者（Administrator）和接待员（Receptionist）。接待员租出自行车，管理者维护自行车登记表和顾客登记表。在Wheels中即没有管理者的任务头衔，也没有接待员的任务头衔。这是因为我们不是表示任何个人，相反我们表示任何被授权使用系统来完成特定任务的人。信息系统分析与设计InformationSystemAnalysisandDesign16/55参与者与参与者描述-2参与者（续）每个参与者能代表着若干不同的人和若干不同的任务头衔。例如，管理者可能是首席机械师Naresh，商店经理Annie，或者甚至是商店老板Mike，每个人或任务头衔能扮演若干个不同的角色。接待员的角色通常是由Annie扮演。然而，当她不在的时候，任何一个机械师或者Mike能作为接待员使用计算机系统，即他们能扮演接待员的角色。另一个思维的方式是用户在使用系统时能戴不同的帽子；Naresh能戴管理者或接待员的帽子来使用本系统。参与者在需求获取时通过询问下列问题来确认：谁涉及诸如出租自行车这样的主要系统过程？谁将使用新系统？谁给系统提供信息？谁获得系统的输出？信息系统分析与设计InformationSystemAnalysisandDesign17/55参与者与参与者描述-3参与者描述参与者描述借助角色和任务头衔来简要描述参与者接待员使用系统来回答关于自行车的可得性和费用的询问，租出自行车，以及记录自行车的返还。接待员可以是商店经理Annie，任何一位机械师，或者商店老板Mike。管理者使用系统来维护顾客和自行车登记表。管理者可以是首席机械师Naresh，商店经理Annie，或者商店老板Mike。信息系统分析与设计InformationSystemAnalysisandDesign18/55用例关系-1通讯关联在用例图中，连接参与者和用例的连接线被称作为通讯关联（参见图2.1）。通讯关联告诉我们哪个参与者同哪个用例是相互关联的。每个参与者可能被关联到许多用例，每个用例能被关联到许多参与者。包括《Include》《include》关系是用例之间的关系。当你发现你有一部分行为对若干用例是共同的时候，它是有用的。不需要在若干个用例描述中重复地描述这部分行为，这部分共同的行为能分割成一个单独的用例，然后用《include》关系连接到所有相关的用例。确定对若干用例是共同的功能是重要的，它允许开发人员避免无谓的努力；一部分功能能被一次确定，研究和建模，然后在需要时重用。信息系统分析与设计InformationSystemAnalysisandDesign19/55用例关系:通讯关联,include和extend-2包括《Include》（续）图2.10表示了一个初始Wheels的用例图（参见图2.1）的精炼版本。用例‘Maintainbikelist’、‘Handleenquiries’、‘Issuebike’和‘Handlebikereturn’都需要在自行车记录表中发现一辆特定的自行车。因此，我们产生一个新用例‘Findbike’，然后将它用《include》关系连接到前面四个需要它的用例。这告诉我们这些用例将总使用