用例和用例图.

用例和用例图用例建模是UML建模的一部分，它也是UML里最基础的部分；用例建模的最主要功能就是用来表达系统的功能性需求或行为；用例建模可分为用例图和用例描述；用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统，是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模，用画图的方法来完成；用例描述用来详细描述用例图中每个用例，用文本文档来完成。用例图的作用用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术用例图的组成用例图由如下元素组成：参与者(Actor)：也称为参与者，它代表系统的用户。系统边界(SystemScope)：它确定系统的范围。用例(UseCase)：它代表系统提供的服务。关系(Association)：关联关系（Association）、包含关系（Include）、扩展关系（Extend）以及泛化关系（Generalization）。参与者参与者(actor)是指系统以外的、需要使用系统或与系统交互的事物,包括:人、设备、外部系统等.其它译名有:活动者、执行者、行动者、角色等；参与者是系统外部的一个实体，参与者只可能存在于边界之外，边界之内的所有人和事物都不是参与者。从图中可以看出，所有的用例都放置在系统边界内，表明它属于一个系统。参与者则放在系统边界的外面，表明角色并不属于系统。但是角色负责直接（或间接）驱动与之关联的用例的执行。UML的用例图示意参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。第一类参与者是真实的人，即用户，命名这类参与者时，应当按照业务命名；第二类参与者是其它的系统，这类位于程序边界之外的系统也是参与者。第三类参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。怎样识别参与者谁向系统提供信息？谁从系统获取（使用）信息？谁管理这个系统？谁维护这个系统？系统要使用哪些外部资源？（系统启动打印机、扫描仪）系统是否和已经存在的系统交互？（跨行转账的外部银行系统、时间到了定时启动系统某功能）查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。下面对机票预订系统进行分情况讨论：情况一：机票购买者通过登录网站购买机票，那么谁是参与者？情况二：假如机票购买者通过呼叫中心，由人工座席操作订票系统购买机票，那么谁是参与者？情况三：如果机票购买者通过呼叫中心的自动语音预定机票而不是通过人工座席，那么谁是参与者？情况四：如果扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，并且假设机票购买者将可以自主选择是通过人工座席还是自动语音登录网站预订机票，那么谁是参与者？在对参与者建模的过程中，注意以下几点：（1）参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物；（2）每个参与者需要一个具有业务一样的名字；（3）一个人或事物在与系统交互时，可以同时或不同时扮演多个角色。UML中的Actor实际上是一个版型化的类,可以有三种表示形式Icon形式Label形式Decoration形式由于Actor实际上是一个类,因此它们之间可以存在一定的关系,参与者之间的关系一般表现为特殊/一般化关系，即，泛化关系。思考：1、这样一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？2、自动售货机的参与者是谁？用例用例(usecase)是IvarJacobson发明的.其它的中文译名有:用况、用案等.定义1:用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列.定义2:用例是系统、子系统或类和外部参与者交互的动作序列的说明,包括可选的动作序列和会出现异常的动作序列.用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约,软件开发过程是用例驱动的.什么是用例？用例是一种需求方法学把用例解释为某个参与者(actor)要做的一件事，这样的一件事有以下几个特征：1、这件事是相对独立的；2、这件事的执行结果对参与者来说是可观测的和有意义的；3、这件事必须由一个参与者发起；不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征二；4、这件事必然是以动宾短语形式出现的。怎样识别用例参与者希望系统执行什么任务？参与者在系统中访问哪些信息？（创建、存储、修改、删除等）需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉参与者？如何维护系统？如何判断一个用例是否是一个优秀的用例呢？①用例是否描述了应该做什么，而不是如何做？②用例的描述是否采取了参与者的视点？③用例是否对参与者有价值？④用例描述的时间流是否是一个完整场景？⑤是否所有的参与者、用例都有相应的关联用例或关联参与者？怎样确定用例的粒度？（用例规模的大小）用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定用例是系统级的、抽象的描述，不是细化的（考虑的是“做什么what”，而不是“怎样做how”）对复杂的系统可以划分为若干子系统处理实际上，用例粒度的划分依据最标准的方法是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。UML中用例用椭圆表示,使用动宾结构或主谓结构命名.例:字处理程序中,“置正文为黑体”和”创建索引”都可以是用例.使用用例进行需求分析的特点:1.用例从使用系统的角度描述系统中的信息.2.用例描述用户提出的一些可见需求,对应一个具体的用户目标.3.用例是对系统行为的描述,属于UML的动态建模部分.使用用例时注意的问题:1.不要将所有的需求都以用例的形式表示出来.2.用例只描述系统功能性方面的需求,它只是全部需求的一部分.3.本质上用例分析是功能分解技术,但目前是OO开发的第一步.4.用例是与实现无关的关于系统功能的描述.思考：网上选课系统脚本其它译名:情景、场景、情节、剧本.脚本就是用例的一次完整的、具体的执行过程。用例与脚本的关系，如同类与对象的关系。每个用例有一系列脚本,包括一个主要脚本,以及几个次要脚本.相对于主要脚本,次要脚本描述了执行路径中的异常或可选择的情况.例：在“订货”用例中包括几个相关脚本：•订货顺利进行的脚本;•相关货源不足时的脚本;•购货者的信用卡被拒绝时的脚本;•……关联（accociation）包含（include）扩展（extend）泛化（generalization）用例图中的关系关联（accociation）每个用例都有参与者启动（每个用例必须和一个参与者关联，有一个参与者来参与），除包含和扩展用例用例和参与者之间是关联关系，有三种形式。泛化关系泛化关系代表一般与特殊的关系,与继承类似.在泛化关系中,子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义.包含关系包含（include）（是一种依赖关系，加了版型include）两个以上用例有共同功能，可分解到单独用例，形成包含依赖；箭头方向由基本用例指向被包含用例；执行基本用例时，每次都必须调用被包含的用例（吃饭前洗手）；被包含用例也可以单独执行；包含（include）一个用例功能过多，可分解成小用例，构成包含依赖本例中，被包含用例不能单独执行，没有Actor直接指向它们扩展关系扩展（extend）（是一种依赖关系，加了版型extend）一个用例（在某些扩展点extensionpoint上）扩展另一个用例的功能，构成新用例；箭头方向由扩展用例指向被扩展用例（即基本用例）；扩展用例依赖于被扩展用例（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行；扩展用例不一定每次都被执行和调用。（吃饭前也可以不洗手），而被包含用例每次必须执行。肯定没有参与者指向扩展用例，因为扩展用例依赖基本用例。几种关系的比较泛化和扩展表示用例之间的“isa”,包含关系表示用例之间的“hasa”.扩展关系的基本用例是wellformed的.一个基本用例执行时,可以执行或不执行扩展用例.包含关系的基本用例可以不是或是wellformed的.执行基本用例时,一定会执行被包含用例.需要重复处理两个或多个用例时,可以考虑包含关系.处理正常行为的变型且只是偶而描述时,可以考虑只使用泛化关系.处理正常行为的变型且希望采用更多控制方式时,可以在基本用例中设置扩展点,使用扩展关系.几种关系的比较关系类型说明表示符号关联actor与usecase之间泛化actor之间或usecase之间包含usecase之间扩展usecase之间思考：需求建模—用例图用例图需求分析的第一步是确定系统能够做什么，谁来使用这个系统。用例图(usecasediagram)是显示一组用例、参与者以及它们之间的关系的图。用户、项目管理员、分析人员、开发人员、质保人员都可以通过用例图了解系统功能。实例1：图书馆管理系统中的用例图1.确定系统涉及的总体信息图书馆管理系统是对书籍的借阅及读者信息进行统一管理的系统，具体包括读者的借书、还书，书籍预订；图书馆管理员的书籍借出处理、书籍归还处理、预订信息处理；还有系统管理员的系统维护，包括增加书目、删除或更新书目、增加书籍、减少书籍、增加读者账户信息、删除或更新读者账户信息、书籍信息查询、读者信息查询等。2.确定系统的参与者根据图书馆管理系统的需求分析，可以确定如下几点：（1）作为一个图书馆管理系统，首先需要借阅者的参与，借阅者可以登录系统查询所需要的书籍，查到所需书籍后可以考虑预订，当然最重要的是借书、还书操作。（2）对于系统来说，借阅者发起的借书、还书等操作最终还需要图书馆管理员来处理，他们还可以负责图书的预订取消。（3）对于图书馆管理系统来说，系统的维护操作也是相当重要的，维护操作主要包括增加书目、删除或更新书目、增加书籍、减少书籍等操作。系统的参与者主要有：借阅者、图书馆管理员、图书馆管理系统维护者。3.确定系统用例识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。（1）借阅者请求服务的用例①登录系统；②查询自己的借阅信息；③查询书籍信息；④预订书籍；⑤借阅书籍；⑥归还书籍。（2）图书馆管理员处理借书、还书等的用例①处理书籍借阅；②处理书籍归还；③删除预订信息。（3）系统管理员进行系统维护的用例①查询借阅者信息；②查询书籍信息；③增加书目；④删除或更新书目；⑤增加书籍；⑥删除书籍；⑦添加借阅者账户；⑧删除或更新借阅者账户。4.使用Rose绘制用例图使用Rose绘制用例图的步骤：1.创建用例图2.添加参与者与用例3.添加参与者与用例之间的关系4.添加用例之间的关系RationalRose介绍选择实现语言J2EEJ2SEJDKVB6VC6OracleRUPRationalRoseIDE环境浏览器四个视图用例视图逻辑视图组件视图部署视图1.用例视图包含内容PackageUsecaseActorClassUsecasediagramClassdiagramCollaborationdiagramSequencediagramStatechartdiagramActivitydiagram2.逻辑视图包含内容ClassClassUtilityUsecaseInterfacePackageClassdiagramUsecasediagram尽量不用Collaborationdia