信息系统分析与设计案例最新版本ppt课件

,课程案例一,第二部分,用例用例图用例场景和用例描述参与者和参与者描述用例关系技术讨论,内容,简介-1,用例对用户眼中的系统功能进行建模，即到目前为止用户所关注的系统做什么，它所做的对用户有价值的事情。用例模型提供了一种对需求调查阶段所获得的大量信息进行组织、分类和记录的一种方式；因此，它是开发过程中需求定义的一个组成部分。用例通常用图形表示，即用例图，并且被文本描述（用例描述、参与者描述和场景）所支持。用例图和支持文本都是简单的和直观的，它们是理想的工具用于同用户讨论和清楚表明开发者对用户需求理解。,简介-2,一旦用例模型完成并同用户一起检查，它就形成一个结构化信息的基础源，系统其它的模型都能在其基础上作出。用例模型对系统的测试也是有帮助的。用例建模时在面向对象软件开发过程的不同阶段进行的。在各个阶段的信息类型和详细程度取决于模型的用途。在开发的早期阶段，用例模型的主要目的是用于同用户沟通，不包括系统详细设计和实施的信息。随后，诸如用户界面的设计这样相关的技术细节被增加，以便为编程人员提供信息。,用例图,用例模型由用例图、一组用例描述、一组参与者描述和一组场景组成。用例图使用四个概念对问题领域进行图形化建模：用例（usecase）、参与者（actor）、关系连接（relationshiplink）和边界（boundary）图2.1表示了Wheels案例研究的一个用例图。新系统的功能被分解成5个用例：维护自行车登记表（Maintainbikelist）、维护顾客登记表（Maintaincustomerlist）、处理询问（Handleenquiries）、出租自行车（Issuebike）、以及处理自行车返还（Handlebikereturn）。概念上，用例图类似于顶层菜单，其列出了系统做的5个主要的事情。,确定用例-1,根据参与者确定用例我们看到了Annie和Simon开始谈论的是如何出租自行车，这是Annie每天主要的工作任务之一。因此，出租自行车是一个用例。出租自行车包括找出合适的自行车，计算租金，收钱，给收据，以及记录顾客和租赁交易的细节。然后，会谈涉及到关于自行车返还处理的讨论。Annie将这当做与出租自行车分开的任务，因为其在时间上上是不同的，并且涉及一组不同的过程：检查日期、检查自行车的车况、以及返还押金。,确定用例-2,根据参与者确定用例（续1）在会谈中Annie告诉我们，一个自行车的登记表已经存放在计算机中，但是不能用来帮助他们进行工作。这个自行车登记表需要如此存储，以便其能用来回答诸如此类问题的询问：Wheels有什么样的自行车、是否这些车可以租借、它们的押金是多少、租金是多少，如此等等。维护这个自行车登记表是另一个用例。处理询问被Annie视作是与出租自行车不同的另外任务。她经常遇到有人到商店或打电话来仅仅为了了解有哪些自行车可以租借，以及费用如何。有时这种询问会导致租借，但更多的时候不会导致自行车的租借。因此，我们能确定“处理询问（Handleenquiries）”是一个单独的用例。,确定用例-3,根据参与者确定用例（续2）在会谈中，发现顾客的信息，以及他们以前租借自行车的记录没有被保存。而这类信息从市场营销的角度是非常有用的，其能简化对相同自行车租借的处理（参见问题定义图2.2、问题和需求列表图2.3、以及会谈总结图2.4。因此，维护顾客登记表(Maintaincustomerlist)能被确定为一个用例。,用例场景-1,根据用例场景确定用例一个场景描述了用户和系统之间一系列的交互以便达到特定的目的。一个场景描述了一个特定的事件序列，例如，当Annie成功地将自行车出租给用户时将会发生什么事情（参见图2.5）。取决于所在的阶段，系统开发人员能够使用场景来描述在一个情况下实际发生什么（或者，可能已经发生什么），或者他们要求在新系统中将要发生的事情。,用例场景-2,根据用例场景确定用例（续）一个精心研究的场景既描述了系统的典型应用，又描述了系统的例外的应用，它是一个非常好的工具，用来理解系统做什么，以及它是如何使用的。她是一个从下到上理解系统的方法。你从了解系统如何被使用的细节着手，以此发现整个的目标和目的是什么，进而理解用例是什么。每个用例代表了一组场景。属于同一用例的场景有共同的目的，而在这个组中的每个场景描述了涉及达到（或不能达到）这个用例目的的一个不同的事件序列。图2.5和图2.6描述了属于出租自行车(Issuebike)用例的场景；在两种情况下，Annie都试图将一辆自行车出租给一位顾客。,用例场景-3,场景应该用文档记录一个典型的事件序列导致达到用例的目的，即一个顾客租到了一辆自行车。明显地，有些特殊情况，例如：一位顾客租借一辆以上的自行车，租借时间是一样的；一位顾客租借一辆以上的自行车，但每辆车的租借时间长短不一；一位顾客租借一辆特殊的自行车；等等。也有一些事件序列表示用例的目的不能达到，例如：顾客不能发现他所喜欢的自行车；顾客认为费用太高；等等。开发人员需要确信其理解并用文档记录了系统应该如何响应每一个可能发生的事件。小的、简单的用例利用用例描述就能充分地描述了。,用例描述-1,什么是用例描述用例描述是一种描述性文档，其以普通的术语描述了用例的功能需求。典型地，它描述了用例的目的，给出了通常会发生什么的一般性描述，事件的正常过程，以及任何小的变化的简要描述。换言之，这种描述是概况的，其书写的方式是应该包括涉及用例的每一个事件序列和每一个场景。这种描述表明系统应该做什么，而不是它应该如何做。在这些情节后面的程序编写、数据存储结构、以及其它的实施细节不应出现在用力描述中，仅仅是用户能见到的发生事情。,用例描述-2,高层次的用例描述有两种不同类型的用例描述是有用的。在软件开发的早期，此时关于系统设计，特别是系统用户界面的设计的详细决策没有被制定，一个简短的、非结构化的描述是足够的，这种描述被称为高层描述（参见图2.7）这些描述仅需要记录用例的目的，涉及的参与者、以及发生什么的总体概述。,用例描述-3,扩展的用例描述随后，一个更详细的、结构化得描述是有用的，其被称为扩展用例描述（参见图2.8）。扩展用例描述比高层用例描述更详细，结构化更强。它应该记录：什么发生来触发用例哪些参与者被涉及哪些数据应该被输入用例的输出是什么用例需要哪些存储的数据什么发生来表示用例的完成事件序列的微小变化（图2.9）。,参与者与参与者描述-1,参与者参与者在系统外部，他们代表了同系统交互，并从中获得某种收益的某些人或事物。通常，一个参与者是一位用户，但有时它是诸如银行或财务系统这样的其它系统；一个参与者也可以代表诸如打印机这样的硬件。一般而言，一个参与者是某个输入信息到系统或接收来自系统的信息（或二者具备）的实体。更严谨地，一个参与者代表了利用系统的一种特殊的方法；一种同系统交互以取得用例目的的方法。它经常被描述成某个实体在用例中所扮演的角色。Theactorsintheusecasediagramin在用例图图2.1中的参与者是管理者（Administrator）和接待员（Receptionist）。接待员租出自行车，管理者维护自行车登记表和顾客登记表。在Wheels中即没有管理者的任务头衔，也没有接待员的任务头衔。这是因为我们不是表示任何个人，相反我们表示任何被授权使用系统来完成特定任务的人。,参与者与参与者描述-2,参与者（续）每个参与者能代表着若干不同的人和若干不同的任务头衔。例如，管理者可能是首席机械师Naresh，商店经理Annie，或者甚至是商店老板Mike，每个人或任务头衔能扮演若干个不同的角色。接待员的角色通常是由Annie扮演。然而，当她不在的时候，任何一个机械师或者Mike能作为接待员使用计算机系统，即他们能扮演接待员的角色。另一个思维的方式是用户在使用系统时能戴不同的帽子；Naresh能戴管理者或接待员的帽子来使用本系统。参与者在需求获取时通过询问下列问题来确认：谁涉及诸如出租自行车这样的主要系统过程？谁将使用新系统？谁给系统提供信息？谁获得系统的输出？,参与者与参与者描述-3,参与者描述参与者描述借助角色和任务头衔来简要描述参与者接待员使用系统来回答关于自行车的可得性和费用的询问，租出自行车，以及记录自行车的返还。接待员可以是商店经理Annie，任何一位机械师，或者商店老板Mike。管理者使用系统来维护顾客和自行车登记表。管理者可以是首席机械师Naresh，商店经理Annie，或者商店老板Mike。,用例关系-1,通讯关联在用例图中，连接参与者和用例的连接线被称作为通讯关联（参见图2.1）。通讯关联告诉我们哪个参与者同哪个用例是相互关联的。每个参与者可能被关联到许多用例，每个用例能被关联到许多参与者。包括Includeinclude关系是用例之间的关系。当你发现你有一部分行为对若干用例是共同的时候，它是有用的。不需要在若干个用例描述中重复地描述这部分行为，这部分共同的行为能分割成一个单独的用例，然后用include关系连接到所有相关的用例。确定对若干用例是共同的功能是重要的，它允许开发人员避免无谓的努力；一部分功能能被一次确定，研究和建模，然后在需要时重用。,用例关系:通讯关联,include和extend-2,包括Include（续）图2.10表示了一个初始Wheels的用例图（参见图2.1）的精炼版本。用例Maintainbikelist、Handleenquiries、Issuebike和Handlebikereturn都需要在自行车记录表中发现一辆特定的自行车。因此，我们产生一个新用例Findbike，然后将它用include关系连接到前面四个需要它的用例。这告诉我们这些用例将总使用Findbike用例。同样，Issuebike的用例描述的第一部分重复了用例Handleenquiries的行为，Annie在出租自行车之前总是要告诉顾客一辆自行车每天的租金和押金。取代在两个用例中重复描述同一行为，我们能将其从Issuebike用例中去掉，然后在Issuebike和Handleenquiries之间使用一个include关系。注意虚线箭头从主要用例指向它所包括的用例，即从Issuebike指向Handleenquiries。,用例关系:通讯关联,include和extend-3,扩展Extendextend关系被用作为在一个用例中定义一个特定的有意义的替代行为的方法。它通常记录用户能选择在正常情况以外的功能。在这个方面使用extend关系仅仅是为了记录不同于正常事件过程的重要变化。小的变化能在扩展用例描述中所覆盖。如果我们要描述下列情况，则需要使用一个extend关系：另外的功能在需要时是能够得到的，例如，打印一个列表，而不是仅仅在屏幕上显示它。仅在特定条件下的行为，例如，如何没有返还全部押金，则打印另外的收据。,用例关系:通讯关联,include和extend-4,扩展Extend（续1）在图2.10中，我们已经产生了一个新用例Printreceipt和一个这个新用例同Handlebikereturn用例之间的extend。其意义是表示有时在返还一辆自行车时可能涉及到打印一张收据，虽然正常情况下不会发生。如果顾客租借自行车的天数超出他们预付的租金的天数，或者还回的自行车有损坏，则必须打印新的收据。相反，打印收据总是Issuebike用例的组成部分，所以我们在Issuebike和Printreceipt之间定义了一个include关系。注意现在虚线箭头是从新扩展的用例指向主用例，即从Printreceipt指向Handlebikereturn。这种方向的改变似乎没有特别的理由，仅仅是规则所规定。,用例关系:通讯关联,include和extend-5,扩展Extend（续2）如果我们决定用例Issuebike的部分将相当频繁地涉及增加新顾客，或者更新我们已有顾客的细节，那么在Issuebike和Maintaincustomerlist之间定义一个extend关系将是明智的（参见图2.11）。在这里，一个extend关系比一个include关系更为适当，因为我们在出租一辆自行车时不是经常增加新顾客或编辑顾客的细节。注意小用例总是建模成一个主要用例的扩展，即，核心功能在基本用例中定义，而附件的或例外的行为在扩展用例中定义。,用例关系:通讯关联,include和extend-6,扩展Extend（续3）有时在用例的一个特定点处，用户不得不从若干选项中选择一个选项；在此情况下，将每个选项建模成单独的扩展用例可能是有用的。扩展用例描述中的可选过程（alternativecourses）部分也可以用来定义用例的不同行为（参见图2.9）。你选择使用哪种方法是一个判断的问题。在用例描述中记录include和extend如果我们已经增加了include或extend关系到一个用例图中，我们必须在用例描述中记录它们。这是利用关键词initiate来完成。例如，如果用例Issuebike被建模如图2.10和图2.11中所定义，我们应该调整它的用例描述，以记录include和extend关系，如图2.12所示。,技术要点-1,在用例图中记录扩展点当一个基本用例用一个extend连接到另一个用例时，在用例图中表示一个跳转到扩展用例的跳转点有时是有用的。例如（参见图2.11），在Issuebike用例中，我们将要在接待员需要增加新顾客信息或改变一个已有顾客的细节时，利用在Maintaincustomerlist用例中定义的额外的功能。扩展点能记录在用例图中如图2.13所示。在用例椭圆的下半部，我们定义扩展点的名称-在本例中，名称是addcustomer和Editcustomer。通过在关系上增添标注，我们也定义扩展用例执行的情景-在本例中是：Newcustomer或changecustomerdetails.,技术要点-2,泛化（Generalization）用例和参与者都可以特别规定，即我们能在参与者之间和用例之间使用一个继承（或者称为泛化generalization/特化specialization）关系。在用例的情况下，泛化的使用时定义事件的可选过程的另一种方法。例如，我们能对图3.12中表示的情形利用泛化关系改变成图2.14中所示这使我们能更加精确地对发生的事情建模。如果接待员正在出租自行车给一位新顾客，则她使用一个特化用例Issuebiketonewcustomer。这个用例总是执行用例Maintaincustomerlist。然而，如果她出租一辆车给一个老客户，它使用泛化用例Issuebike。如果在执行这个用例的过程中，她发现该顾客已经改变了他们的地址，则她能选择执行Maintaincustomerlist用例。参与者也能被特化，如果我们希望表示特化的参与者除扮演同泛化的参与者相同的角色，但还有一些另外的角色。,技术要点-3,主要参与者（Initiatingactor）和次要参与者（participatingactor）理解参与者类型的差别而不过于陷于细节的泥潭是值得的。在任何用例中，主要参与者是这样的参与者，其启动事件序列，即激活用例。用例涉及的其他参与者是次要参与者。最重要的参与者是被称作受益者的参与者，即参与者从用例获得益处：如同用例中所定义，一个人使用计算机来做一些对他有用的事情。关于谁应该被建模成与用例关联的参与者存在一些争论。有些实践者喜欢在用例图中表示每一个同用例关联的人。而另外一些则仅表示主要参与者，一些人仅表示受益者。,技术要点-4,主要参与者和次要参与者（续）在Wheels案例研究中，我们不将顾客（Customer）建模成一个参与者，虽然通常是顾客激活一个用例。我们应该建模系统如图2.15所示。参与者的选择是一个很大的内容描述，在其中我们选择绘制系统边界。如果我们正在建立一个整个商业系统的高层模型，目的是使得商业或公司更有效率，则参与者是公司以外环境中的人。在Wheels系统中，这将是客户，也可能是供货商。根据这个观点，公司的雇员被看作系统边界内的资源，而不被建模成参与者。在另一方面，如果我们正在考虑作为整个商业系统组成部分的计算机系统的自动边界，参与者将是使用计算机的人，公司雇员。在Wheels系统这将是接待员和管理者。,技术要点-5,基本的和实际的用例一个基本的用例是一个同实施或详细设计决策完全没有联系的用例。在这些决策制定之前的软件开发早期，用例应该是基本用例。在早期保持用例独立于实施细节是重要的，以便约束了后来的设计决策。另一方面，实际用例表示设计和实施决策在其影响用户范围内的细节。例如，一个实际用例将表示用户界面的细节。不直接影响用户对系统认识的实施决策，如编程语言、数据结构或程序算法等的选择不在用例中定义。在图2.16中的用例描述有一些附加的实施决策（例如，自行车的细节要以报告表格的形式显示），因此是一个实际用例描述。,技术要点-6,实例（Stereotype）stereotype是一个有专门用途的建模元素。Stereotype通常是利用在括弧内的标记来标识，例如include和extend，其意义是它们是用于特定方式的关系。严格地说，参与者图标是一个实例化的类。取代使用棍状人形对诸如接待员建模成参与者，我们同样可以用UML的类图标，并将其标识为参与者的实例（参见图2.17）。子系统和包图如果我们正在为一个大系统建模，在绘制用例图时，我们不能再将我们所有的用例放在一个屏幕显示上。UML有一个称作包的编组表示符号来处理这一问题（图2.18）。包仅仅是一个约定的表示符号，用来管理我们的模型，它们在系统中不代表任何事情，而是被用来对表示系统中事情的元素进行分组。我们能用包来对任何建模元素的集合：类、用例或模型的实体集合，即用例模型、对象模型、以及相对一个子系统的交互模型。,技术要点-7,用例实现用例开发，从需求获取阶段的最初确定到它的实施被称为用例实现。换言之，对单一用例的用例实现要求贯穿所有开发活动中的一个完整迭代。RUP基本是用例驱动，这