用例和用例图

用例和用例图教学目的熟悉用例的概念，掌握用例图的作用；掌握用例之间的关系；学会使用用例对软件系统需求建模；掌握用例描述；掌握Rose下用例建模。用例建模概述

用例图从用户的角度来描述系统功能，并指出各功能的操作者，其基本组成成份是系统、参与者和用例。用例从外部用户的角度来描述系统应该实现什么样的功能。参与者是与系统进行交互的外部实体，系统是实现各种用例的“黑盒”。用例进行需求分析的特点用例从使用系统的角度描述系统中的信息，即站在系统外部察看系统的功能，而不考虑系统内对该功能的具体实现方式。用例描述了用户提出的一些可见需求，对应一个具体的用户目标。是用来划分系统与外部实体的界限，是OO系统设计的起点，是类、对象、操作的来源。用例是对系统行为的动态描述，属于UML动态建模部分。用例图用例图用来定义系统的功能需求，描述若干参与者与系统提供的用例之间的连接关系。用例图的作用主要有三个：获取需求；指导测试；对整个过程中的其他工作流起指导作用。用例图示例用例图用例图包含三个元素，它们是：参与者、用例、关系。参与者：参与系统成功操作的某些人、系统、设备甚是是企业所扮演的角色。用例：标志系统的某个关键行为。每个用例都表达了系统必须达到的目标或必须产生的结果。关系：标志参与者和用例之间的交互称为关联。每个关联成为在用例描述中加以解释的对话，而每个用例描述又提供了一组脚本，它们有助于开发测试用例。用例之间有包含、扩展和泛化关系。用例图要素系统：表示一台机器或一次商务活动等。系统的边界说明用例图的应用范围。参与者：是为了完成一个事件而与系统进行交互的实体，是与系统交互的外部用户、或其他系统的概念。用例：用例是外部可见的一种系统功能，其作用是在不揭示系统内部构造的情况下定义系统中连贯的行为，在系统层，表示整个系统对外部用户可见的行为。用例图用例图是基于用例的方法的一部分，基于用例的方法还包括对用例的文本描述和用例脚本。文本描述用来强调用例的需求细节，脚本则用来说明用例执行中的选项、测试需求以及为后续的开发提供较高层次的测试计划。参与者（1）参与者是某种类型的用户，用户指使用系统的人，或者是其他的的系统、设备。参与者的图形表示见教材P24页图3.4所示。参与者（2）建模人员可以这样看待参与者：是一个外部实体；和系统之间存在交互；充当某个特定的角色；如何识别参与者系统的主要客户是谁？谁从该系统获得信息？谁向系统提供信息？谁来安装该系统？谁来操作该系统？谁来关闭该系统？在预定的时刻是否有事件自动发生？谁使用或删除系统中的信息？系统从何处获得信息？参与者的泛化关系参与者之间的泛化关系表示一个一般性的参与者（称作父参与者）与另一个更为特殊的参与者（称作子参与者）之间的联系。子参与者继承了父参与者的行为和含义，还可以增加自己的行为和含义，子参与者可以出现在父参与者能出现的任何位置上。泛化关系用带三角形箭头的实线表示。见教材P24图3.5。关联

关联是参与者和用例之间的关系，表示方法是在参与者和用例之间连接一条直线，关联描述了这样一个事实，即参与者和用例之间的通信。用例间的关系包含关系：标志一个可重用的用例，它可以被无条件地集成到其他的用例中，什么时候或者为什么调用该用例取决于调用它的用例。扩展关系：指的是一个可重用的用例被另外一个用例有条件地打断，以增加其功能。什么时候使用扩展用例取决于扩展用例。泛化：指的是参与者之间或者用例之间的继承关系。用例的扩展关系使用扩展用例可以使我们不改变基用例的同时，根据需要自由的往系统中添加行为。扩展关系中，箭头的方向是从扩展用例到基本用例，也就是说，扩展用例是依赖于基本用例的。扩展用例决定它什么时候执行，基用例对此毫不知情。扩展关系的要素基用例：需要被扩展用例加强的用例；扩展用例：提供所添加的行为的用例；《extend》关系：使用虚线箭头表示，箭头的尾部在扩展用例上，箭头指向基用例。扩展点：基用例中的一个或多个位置，该位置会衡量某个条件以决定扩展是否打断基用例的执行。扩展点可以列在用例图标中，也可以在用例描述中说明。扩展关系扩展点是一个条件，决定扩展是否会被使用，扩展点定义了一个扩展用例一直在监视的条件，一旦条件满足，扩展用例就将自己加入到执行用例中。比如基用例向系统报告一个错误，该错误这是某个扩展用例监视的条件，在收到这个条件后，扩展用例就插入执行，对错误进行处理，执行完毕后，基用例被允许从中断的地方继续执行。用例的包含关系包含关系和对象的调用关系比较相象，它描述的是一个用例需要某种类型的行为，而另一个用例定义了该行为，那么在用例执行中，就可以调用已经定义好的用例。包含关系中箭头的方向是从基本用例到包含用例，箭头线上包含关键词《include》，即就是说，基本用例是依赖于包含用例的。为了使用包含关系，必须遵循以下两个约束：调用用例只能依赖被调用用例的返回结果，它对被调用用例的内部结构没有了解；调用用例总会要求被调用用例执行，对被调用用例的使用是无条件的。包含关系的表示包含、扩展关系比较（1）Include增强基用例的行为；被包含用例总是被用来增强执行用例；执行用例决定什么时候调用被执行用例，被包含用例对基用例一无所知；关系箭头由执行用例指向被包含用例，箭头的尾部表示基用例指导被包含用例的执行。包含、扩展关系比较（2）Extend增强基用例的行为；扩展用例可能被用来增强执行用例扩展用例决定什么时候将自己加入基用例的执行中，基用例对扩展用例一无所知关系箭头由扩展用例指向执行用例，箭头的尾部表示扩展用例决定是否打断执行用例定义用例方法一个项目最开始的任务之一就是确定应用程序的上下文和范围，需要回答以下问题：需要包含哪些功能？在整体体系结构中，该系统如何和其他系统关联？谁将使用该系统？系统取决于谁或什么因素？系统提供什么产品或结果？其他系统或用户为什么需要本系统提供的特征？用例描述用例图通常会和用例描述一起使用，用例描述会对用例给出解释。用例脚本描述的使用例执行时选择的路径，这是形成测试计划的基础。用例图、用例描述和用例脚本构成了基于用例的方法的基础。用例描述用例的目标；用例是怎么启动的；参与者和用例之间的消息是如何传送的；用例中除了主路径外，其他路径是什么；用例结束后的系统状态；其他需要描述的内容；用例描述模板（1）用例描述格式见教材P30表3.2例子见教材P31表3.3用例描述模板（1）假定：描述的是系统在使用用例之前必须满足的状态，这些条件并没有经过用例的检测，用例只是假设它们为真。前置条件：前置条件描述了执行用例之前系统必须满足的条件，但是和假定不一样，前置条件在使用之前，是使用用例测试过的。如果条件得不到满足的话，用例将不会被执行。用例起始/触发器：用例必须有一个起始点，用例起始说明了一个用例触发的原因。用例描述模板（2）会话：指的是对用户（参与者或另外的用例）和执行用例（实现用例的系统）之间的交互所做的一步步的描述，通常使用活动图或交互综述图描述该事件序列。用例终止：尽管只有一个触发事件启动一个用例，但终止一个用例却经常有很多方法，用例可以正常终止，即所有交互都正常进行，最后得到希望的结果，担当出错或取消某个操作时，用例会给出出错信息然后终止。后置条件：规定（1）如果前置条件满足的话，系统必须做什么；（2）在用例结束时，系统必须处于什么状态。用例脚本发现脚本为了发现脚本，首先从用例描述开始，一般来说，最好是先决定成功脚本的路径，跟随用例中的每一步，在到达决策点时，就需要进行选择，在所有的选项中选择可以到达用例成功结束点的路径，然后继续往下跟踪，一直到达成功结束点，这样就完成了第一个脚本。然后回到第一个分支点，从另一条未被选择的路径开始跟踪第二个脚本，如此重复直到找完所有脚本。脚本可以在活动图中表现。寻找用例的方法找出系统外部的参与者和外部系统，确定系统的边界和范围；确定每一个参与者所期望的系统行为；把这些系统行为命名为用例；使用泛化、包含、扩展等关系处理系统行为的公共或变更部分；编制每一个用例的脚本；绘制用例图；区分主要事件流和异常事件流，如果需要，可以把表示异常情况的事件流作为单独的用例处理。细化用例图，解决用例间的重复与冲突问题。帮助发现用例的原则参与者得主要任务是什么？参与者需要了解系统的什么信息？需要修改系统什么信息？参与者是否需要把系统外部的变化通知系统？参与者是否希望系统把异常情况的变化通知自己？构造用例图的步骤1.定义系统的上下文

1.1确定参与者和它们的责任；

1.2确定用例，即确定带有特定目的或产生特定结构的系统行为。2.对参与者和用例进行权衡，以便精华模型3.衡量用例以找出包含关系；4.衡量用例以找出扩展关系；5.对参与者和用例进行研究，查找是否存在泛化关系。小结用户模型视图从用户角度描述系统所应具有的功能，其基本组成成分是系统、参与者和用例。参与者是为了完成一个事件而与系统进行