《用例和用例图ppt课件.ppt》由会员分享，可在线阅读，更多相关《用例和用例图ppt课件.ppt（93页珍藏版）》请在三一办公上搜索。
1、用例和用例图,用例建模是UML建模的一部分，它也是UML里最基础的部分；用例建模的最主要功能就是用来表达系统的功能性需求或行为；用例建模可分为用例图和用例描述；用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统，是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模，用画图的方法来完成；用例描述用来详细描述用例图中每个用例，用文本文档来完成。,用例图的作用用例图展示了用例之间以及用例与参与者之间是怎样相互联系的。用例图对系统、子系统或类的行为进行了可视化，使用户能够理解如何使用这些元素，并使开
2、发者能够实现这些元素。用例图主要用来描述用户的功能需求。UML侧重从最终用户的角度来理解软件系统的需求，强调谁在使用系统、系统可以完成哪些功能。用例分析技术已经是一种公认有效的用户需求获取、分析和描述技术,用例图的组成,用例图由如下元素组成：参与者(Actor)：也称为参与者，它代表系统的用户。系统边界(System Scope)：它确定系统的范围。用例(Use Case)：它代表系统提供的服务。关系(Association)：关联关系（Association）、包含关系（Include）、扩展关系（Extend）以及泛化关系（Generalization）。,参与者,参与者(actor)是指
3、系统以外的、需要使用系统或与系统交互的事物,包括:人、设备、外部系统等.其它译名有:活动者、执行者、行动者、角色等；参与者是系统外部的一个实体，参与者只可能存在于边界之外，边界之内的所有人和事物都不是参与者。,从图中可以看出，所有的用例都放置在系统边界内，表明它属于一个系统。参与者则放在系统边界的外面，表明角色并不属于系统。但是角色负责直接（或间接）驱动与之关联的用例的执行。,UML的用例图示意,参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。第一类参与者是真实的人，即用户，命名这类参与者时，应当按照业务命名；第二类参与者是其它的系统，这类位于程序边界之外的系统也是
4、参与者。第三类参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。,怎样识别参与者谁向系统提供信息？谁从系统获取（使用）信息？谁管理这个系统？谁维护这个系统？系统要使用哪些外部资源？（系统启动打印机、扫描仪）系统是否和已经存在的系统交互？（跨行转账的外部银行系统、时间到了定时启动系统某功能）,查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。下面对机票预订系统进行分情况讨论：情况一：机票购买者通过登录网站购买机票，那么谁是参与者？,情况二：假如机票购买者通过呼叫中心，由人工座席操作订票系统购买机票，那么谁是参与
5、者？,情况三：如果机票购买者通过呼叫中心的自动语音预定机票而不是通过人工座席，那么谁是参与者？,情况四：如果扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，并且假设机票购买者将可以自主选择是通过人工座席还是自动语音登录网站预订机票，那么谁是参与者？,在对参与者建模的过程中，注意以下几点：（1）参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物；（2）每个参与者需要一个具有业务一样的名字；（3）一个人或事物在与系统交互时，可以同时或不同时扮演多个角色。,UML中的Actor实际上是一个版型化的类,可以有三种表示形式,Icon形式,Label形式,Decoration
6、形式,由于Actor实际上是一个类,因此它们之间可以存在一定的关系,参与者之间的关系一般表现为特殊/一般化关系，即，泛化关系。,思考：1、这样一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？2、自动售货机的参与者是谁？,用例,用例(use case)是Ivar Jacobson发明的.其它的中文译名有:用况、用案等.,定义1:用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列.,定义2:用例是系统、子系统或类和外部参与者交互的动作序列的说明,包括可选的动作序列和会出现异常的动作序列.,用例是代表系统中各个项目相关人员
7、之间就系统的行为所达成的契约,软件开发过程是用例驱动的.,什么是用例？,用例是一种需求方法学把用例解释为某个参与者(actor)要做的一件事，这样的一件事有以下几个特征：1、这件事是相对独立的；2、这件事的执行结果对参与者来说是可观测的和有意义的；3、这件事必须由一个参与者发起；不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征二；4、这件事必然是以动宾短语形式出现的。,怎样识别用例参与者希望系统执行什么任务？参与者在系统中访问哪些信息？（创建、存储、修改、删除等）需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉参与者？如何维
8、护系统？,如何判断一个用例是否是一个优秀的用例呢？用例是否描述了应该做什么，而不是如何做？用例的描述是否采取了参与者的视点？用例是否对参与者有价值？用例描述的时间流是否是一个完整场景？是否所有的参与者、用例都有相应的关联用例或关联参与者？,怎样确定用例的粒度？（用例规模的大小）用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定用例是系统级的、抽象的描述，不是细化的（考虑的是“做什么what”，而不是“怎样做how”）对复杂的系统可以划分为若干子系统处理,实际上，用例粒度的划分依据最标准的方法是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。,UML中用例用椭
9、圆表示,使用动宾结构或主谓结构命名.,例:字处理程序中,“置正文为黑体”和”创建索引”都可以是用例.,使用用例进行需求分析的特点:,用例从使用系统的角度描述系统中的信息.用例描述用户提出的一些可见需求,对应一个具体的用户目标.用例是对系统行为的描述,属于UML的动态建模部分.,使用用例时注意的问题:,不要将所有的需求都以用例的形式表示出来.用例只描述系统功能性方面的需求,它只是全部需求的一部分.本质上用例分析是功能分解技术,但目前是OO开发的第一步.用例是与实现无关的关于系统功能的描述.,思考：,网上选课系统,脚本,其它译名:情景、场景、情节、剧本.脚本就是用例的一次完整的、具体的执行过程。用
10、例与脚本的关系，如同类与对象的关系。,每个用例有一系列脚本,包括一个主要脚本,以及几个次要脚本.相对于主要脚本,次要脚本描述了执行路径中的异常或可选择的情况.,例：在“订货”用例中包括几个相关脚本：订货顺利进行的脚本;相关货源不足时的脚本;购货者的信用卡被拒绝时的脚本;,关联（accociation）包含（include）扩展（extend）泛化（generalization）,用例图中的关系,关联（accociation）每个用例都有参与者启动（每个用例必须和一个参与者关联，有一个参与者来参与），除包含和扩展用例用例和参与者之间是关联关系，有三种形式。,泛化关系,泛化关系代表一般与特殊的关系
11、,与继承类似.在泛化关系中,子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义.,包含关系,包含（include）（是一种依赖关系，加了版型）两个以上用例有共同功能，可分解到单独用例，形成包含依赖；箭头方向由基本用例指向被包含用例；执行基本用例时，每次都必须调用被包含的用例（吃饭前洗手）；被包含用例也可以单独执行；,包含（include）一个用例功能过多，可分解成小用例，构成包含依赖本例中，被包含用例不能单独执行，没有Actor直接指向它们,扩展关系,扩展（extend）（是一种依赖关系，加了版型）一个用例（在某些扩展点extension point上）扩
12、展另一个用例的功能，构成新用例；箭头方向由扩展用例指向被扩展用例（即基本用例）；扩展用例依赖于被扩展用例（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行；扩展用例不一定每次都被执行和调用。（吃饭前也可以不洗手），而被包含用例每次必须执行。肯定没有参与者指向扩展用例，因为扩展用例依赖基本用例。,几种关系的比较,泛化和扩展表示用例之间的“is a”,包含关系表示用例之间的“has a”.扩展关系的基本用例是 well formed 的.一个基本用例执行时,可以执行或不执行扩展用例.包含关系的基本用例可以不是或是 well formed 的.执行基本用例时,一定会执行被包含用例.需要
13、重复处理两个或多个用例时,可以考虑包含关系.处理正常行为的变型且只是偶而描述时,可以考虑只使用泛化关系.处理正常行为的变型且希望采用更多控制方式时,可以在基本用例中设置扩展点,使用扩展关系.,几种关系的比较,思考：,需求建模用例图,用例图,需求分析的第一步是确定系统能够做什么，谁来使用这个系统。用例图(use case diagram)是显示一组用例、参与者以及它们之间的关系的图。用户、项目管理员、分析人员、开发人员、质保人员都可以通过用例图了解系统功能。,实例1：图书馆管理系统中的用例图,1.确定系统涉及的总体信息 图书馆管理系统是对书籍的借阅及读者信息进行统一管理的系统，具体包括读者的借书
14、、还书，书籍预订；图书馆管理员的书籍借出处理、书籍归还处理、预订信息处理；还有系统管理员的系统维护，包括增加书目、删除或更新书目、增加书籍、减少书籍、增加读者账户信息、删除或更新读者账户信息、书籍信息查询、读者信息查询等。,2.确定系统的参与者根据图书馆管理系统的需求分析，可以确定如下几点：（1）作为一个图书馆管理系统，首先需要借阅者的参与，借阅者可以登录系统查询所需要的书籍，查到所需书籍后可以考虑预订，当然最重要的是借书、还书操作。（2）对于系统来说，借阅者发起的借书、还书等操作最终还需要图书馆管理员来处理，他们还可以负责图书的预订取消。（3）对于图书馆管理系统来说，系统的维护操作也是相当重
15、要的，维护操作主要包括增加书目、删除或更新书目、增加书籍、减少书籍等操作。系统的参与者主要有：借阅者、图书馆管理员、图书馆管理系统维护者。,3.确定系统用例识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。,（1）借阅者请求服务的用例登录系统；查询自己的借阅信息；查询书籍信息；预订书籍；借阅书籍；归还书籍。,（2）图书馆管理员处理借书、还书等的用例处理书籍借阅；处理书籍归还；删除预订信息。,（3）系统管理员进行系统维护的用例查询借阅者信息；查询书籍信息；增加书目；删除或更新书目；增加书籍；删除书籍；添加借阅者账户；删除或更新借阅者账户。,4.使用Rose绘制用例图,
16、使用Rose绘制用例图的步骤：1.创建用例图2.添加参与者与用例3.添加参与者与用例之间的关系4.添加用例之间的关系,Rational Rose 介绍,选择实现语言,J2EEJ2SEJDKVB6VC6OracleRUP,Rational Rose IDE 环境,浏览器,四个视图用例视图逻辑视图组件视图部署视图,1.用例视图,包含内容PackageUse caseActorClassUse case diagramClass diagramCollaboration diagramSequence diagramStatechart diagramActivity diagram,2.逻辑视图,
17、包含内容ClassClass UtilityUse caseInterfacePackageClass diagramUse case diagram 尽量不用Collaboration diagramSequence diagramStatechart diagramActivity diagram,3.组件视图,包含内容PackageComponentComponent diagram,4.部署视图,包含内容ProcessorDeviceDeployment diagram,文档窗口,可以为任何当前UML元素添加注释、说明或简单定义等。导出发布模型时，这里的文字也会自动输出。,标准工具栏,
18、基本的新建、打开、保存工具浏览类图、浏览交互图、浏览组件图、浏览状态图、浏览部署图以及放大、缩小等方便查看的功能可以Ctrl+D删除任意元素。,视图工具栏,根据不同的视图环境，显示不同的工具用例视图逻辑视图组件视图部署视图,视图工具栏,用户可以自己定制工具栏内容,修改模型属性,Tools菜单中选择“Options”,创建元素,命名文档区加注释缺省的主用例图main缺省的主类图main缺省的主组件图main缺省的主部署图main,实例2:,分析：,1.参与者,管理员,2.用例,管理图书：新增书籍、查询书籍、修改书籍管理外借：登记外借、查询外借统计信息,推荐方案 PK 可选方案,优化方案1 优化方
19、案2,用例的描述,用例描述是指对一个用例的功能进行的文字描述,是参与者与系统交互动作序列的说明.,用例采用自然语言描述参与者与系统的交互行为,要易于理解。其读者是开发人员、用户、项目经理、测试人员等。,用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事。用例描述模板为了说明一个用例的行为，描述一个用例的关键要素包括：用例何时开始（前置条件）、何时结束（后置条件）、参与者何时与用例交互、交互了什么信息，以及用例执行的基本事件流和扩展事件流。,1.事件流事件流就是一个用例在执行时参与者与系统之间的交互过程。事件流的目的是为用例的逻辑流程建立文档，这个文档详
20、细描述系统用户的工作和系统本身的工作。事件流分为基本事件流和扩展事件流两种。2.用例描述模板 用例描述有两种格式：一种是纯文本格式，另一种是表格形式。,用例的描述格式,用例的描述格式(续表),用例的描述,描述用例时易出现的错误：,只描述系统的行为,没有描述参与者的行为只描述参与者的行为,没有描述系统的行为在用例描述中就设定了对用户界面的设计的要求描述过于冗长,Use case:Withdraw cashActor:customer主事件流：储户插入ATM卡,并输入密码储户按“取款”按钮,并输入取款数目储户取走现金/ATM卡/收据储户离开,Use case:Withdraw cashActor:
21、customer主事件流：ATM系统获得ATM卡和密码设置交易类型为“取款”ATM系统获得取款金额输出现金、收据和ATM卡系统复位,用例的描述,ATM系统“取款”用例的两个错误描述：,只描述了actor的行为,只描述了System的行为,用例的描述,Use case:Withdraw cashActor:customer主事件流：储户通过读卡机插入ATM卡ATM系统从卡上读取银行ID、账号、加密密码,并通过主银行系统验证银行ID和账号储户输入密码,ATM系统根据加密密码对输入密码进行验证储户按“取款”按钮,并输入取款数目,该数目应该为100的倍数ATM系统通知主银行系统,传递账号和金额,并接收
22、返回的确认信息和账户余额ATM系统输出现金、ATM卡和收据ATM系统记录交易到日志文件,ATM系统“取款”用例的正确描述：,找出系统外部的参与者和外部系统,确定系统边界和范围确定每一个参与者所期望的系统行为把这些系统行为命名为用例使用泛化、包含、扩展等关系处理系统行为的公共或变更部分编制每一个用例的脚本绘制用例图区分主要事件流和异常事件流,如果需要,可以把异常事件流处理为单独的用例细化用例图,解决用例间重复与冲突的问题.,用例分析的基本步骤：,实例分析：语音邮箱系统,目标：构建一个语音邮箱系统问题描述：语音邮箱系统中,可以为每个系统用户(邮箱主人)分配一个语音邮箱号码。进行留言时，拨打语音邮箱
23、系统的主号码，在听到提示音“请输入邮箱号”后，输入语音邮箱号，听到主人设定的问候语后，进行留言然后挂断电话。邮箱主人拨打语音邮箱系统的主号码，在听到提示音“请输入邮箱号”后，输入语音邮箱号，听到主人设定的问候语后，输入密码+#进行邮箱管理。此时系统提供三种服务：1.接收信息；2.更改问候语；3.更改密码。其中接收留言包括收听新留言、存储留言、删除留言等。,实例分析：语音邮箱系统,1.找出actor和外部系统，确定系统边界。,参与者：留言人、邮箱主人,2.主要功能分析(参与者期望的系统行为等),(1)留言人保留信息(留言)。(2)邮箱主人管理信息：收听/存储/删除。(3)邮箱主人更改问候语。(4
24、)邮箱主人更改密码。,实例分析：语音邮箱系统,3.初步找到的用例,留言人：保留信息邮箱主人：接收信息、更改问候语、更改密码,4.进一步寻找用例,邮箱主人：登录邮箱留言人、邮箱主人：拨打邮箱号码,5.分析用例之间的关系,本例较为简单，只使用“包含关系”即可。,实例分析：语音邮箱系统,6.绘制初步用例图,实例分析：语音邮箱系统,7.编写每一个用例的脚本,8.区分脚本中的主事流或异常情况事件流,9.细化用例图，完成用例模型(略),实例分析：语音邮箱系统-用例脚本,用例1：拨打邮箱号1.呼叫者拨打语音邮件系统的主号码。2.语音邮件系统发出提示音：输入邮箱号码并加#号。3.呼叫者输入接收者的邮箱号。4.
25、语音邮件系统发出问候语：已进入XX的邮箱，请留言。,用例2:保留信息1.呼叫者完成邮箱号输入操作.2.呼叫者说出信息.3.呼叫者挂断电话.4.语音邮件系统将记录的信息存放在接收者的邮箱中.,实例分析：语音邮箱系统-用例脚本,用例3:登录系统1.邮箱用户完成邮箱号输入操作.2.邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同)3.语音邮件系统播放邮箱菜单:按1键接收信息.按2键更改密码.按3键更改问候语.,实例分析：语音邮箱系统-用例脚本,用例4:接收信息1.邮箱用户完成登录操作.2.邮箱用户选择“接收信息”菜单选项.3.语音邮件系统播放信息菜单:按1收听当前信息;按2存储当前信息;按3删除当
26、前信息;按4返回邮箱菜单.4.邮箱用户选择“收听当前信息”菜单选项.5.语音邮件系统播放当前新信息,若无新信息,播放当前已有信息.(注意:只播放,不删除)6.语音邮件系统播放信息菜单.7.用户选择”删除当前信息”,则信息被永久删除.8.继续执行第3步.,实例分析：语音邮箱系统-用例脚本,用例4变体#1:存储一条信息1.1 以第6步作为开始.1.2 用户选择“存储当前信息”.1.3 当前信息从新信息队列中删除并添加到旧信息队列中.1.4 继承执行第3步.,实例分析：语音邮箱系统-用例脚本,用例5:更改问候语1.邮箱用户完成登录操作.2.邮箱用户选择“更改问候语”菜单选项.3.邮箱用户说出新的问候
27、语.4.邮箱用户按下#键.5.邮件系统设置新的问候语.,用例5变体#1:在确认前挂断电话1.1 以第3步作为开始.1.2 邮件用户挂断电话.1.3 邮件系统保留旧的问候语.,实例分析：语音邮箱系统-用例脚本,用例6:更改密码1.邮箱用户完成登录操作.2.邮箱用户选择“更改密码”菜单选项.3.邮箱用户输入新的密码.4.邮箱用户按下#键.5.邮件系统设置新的密码.,用例6变体#1:在确认前挂断电话1.1 以第3步作为开始.1.2 邮件用户挂断电话.1.3 邮件系统保留旧的密码.,实例分析：语音邮箱系统-用例脚本,练习,画出该系统的用例图，并对学生选课用例进行用例描述,选课事件流,主事件流：,错误流,作业：1、什么是参与者？如何确定系统的参与者？2、什么是用例？如何确定系统的用例？3、简述用例图中存在的4种关系，并举例。4、简述用例分析的基本步骤。,
