《用例和用例图》PPT课件.ppt

上传人:小飞机 文档编号:5554148 上传时间:2023-07-20 格式:PPT 页数:51 大小:227.50KB
返回 下载 相关 举报
《用例和用例图》PPT课件.ppt_第1页
第1页 / 共51页
《用例和用例图》PPT课件.ppt_第2页
第2页 / 共51页
《用例和用例图》PPT课件.ppt_第3页
第3页 / 共51页
《用例和用例图》PPT课件.ppt_第4页
第4页 / 共51页
《用例和用例图》PPT课件.ppt_第5页
第5页 / 共51页
点击查看更多>>
资源描述

《《用例和用例图》PPT课件.ppt》由会员分享,可在线阅读,更多相关《《用例和用例图》PPT课件.ppt(51页珍藏版)》请在三一办公上搜索。

1、第4章用例和用例图,4.1 用例和用例图的概念,用例模型的基本组成部分有用例、角色(或参与者)和系统。用例用于描述系统的功能,也就是从用户的角度来说,系统具体应包含哪些功能,帮助分析人员理解系统的行为,它是对系统功能的宏观的、整体的描述,一个完整的系统通常包含许多用例,每个用例具体说明应完成的功能;参与者是指那些与系统进行交互的外部实体,通常它是系统的一个用户,但它也可以是其它系统或硬件设备,总之凡是需要与系统进行交互的任何实体都可以称作参与者,用例往往必须向参与者传递一些数值,这些数值是参与者在系统中获得的信息。,4.1 用例和用例图的概念,使用用例的主要目的是:(1)明确系统应具备什么功能

2、,这些功能是否满足客户的基本需求,并与系统开发人员达成一致。(2)为系统的功能提供清晰一致的描述,用例模型应用于系统开发的整个过程,为后阶段的系统设计和开发工作打下良好的基础。(3)为系统测试打下基础,可以用于验证最终实现的系统所完成的功能是否符合客户的最初需求。(4)通过从需求的功能用例出发跟踪进入到系统中具体实现的类和方法,可以检查其是否正确。例如,通过下面这种方法可以简化对系统的修改和扩展:首先修改用例模型,针对受到影响的用例,找到相应的系统设计和实现部分,对其进行相应的修改即可。,4.1 用例和用例图的概念,用例图(Use Case Diagram)是显示一组用例、参与者以及它们之间关

3、系的一种图。用例图在UML中是非常特别的图形元素,它描述了用户希望如何使用一个系统。通过用例图可以知道谁将是系统相关的用户,他们希望系统提供什么样的服务,以及他们需要为系统提供的服务。用例图从用户的角度而不是开发者的角度来描述对软件产品的需求,分析产品所需的功能和动态行为。用例图常用来对需求进行建模,用例图在系统的整个分析、设计和开发阶段是非常重要的,它的正确与否直接影响到客户对最终实现的产品的满意度。用例图被广泛使用在各种开发活动中,但它最常用于描述系统以及子系统。,4.1 用例和用例图的概念,图4.1 用例图,4.1.1 参与者,参与者(也可以称为角色,Actor)是系统外部的一个人或者物

4、,它以某种方式参与了系统的执行过程。参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。还有一点需要注意的是,参与者不是指人或事物本身,而是表示人或事物在系统中所扮演的角色。例如,张明是图书馆的管理员,他参与图书管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里张明扮演了两个角色,是两个不同的参与者,即管理员和借阅者。因此,在“图书管理系统”中“借阅者”和“系统管理员”都是参与者。,4.1.1 参与者,【例4-1】客户给销售员发来传真订货,销售员下班前将当日订货单汇总输入系

5、统。谁是系统的参与者?分析:根据参与者的定义可知,此系统的参与者是销售员。,4.1.1 参与者,【例4-2】在需求分析中常见的权限控制问题,一般的用户只可以使用一些常规的操作,如查询等,而管理员除了常规操作之外还需要进行一些系统管理工作,如一些关键数据的增加、删除、修改等,操作员既可以进行常规操作又可以进行一些配置操作。,4.1.1 参与者,例如,在“图书管理系统”中,可以认为“读者”是“学生读者”和“教师读者”的泛化,而“学生读者”还可以具体化为“本科生读者”和“研究生读者”;同样,“图书管理员”也是“采购员”、“编目员”及“借阅人员”的泛化。图4.3表示出了参与者之间的泛化关系。,4.1.

6、1 参与者,图4.3 图书管理系统参与者之间的泛化关系,4.1.2 用例,需求获取(Requirement Elicitation)是需求分析阶段的主体部分,其主要的工作就是要建立待开发系统的模型,而用例就是用于建立这种模型的最好方法。用例最初由Ivar Jackboson博士提出,后来被融合到UML的规范之中,成为描述需求的标准化体系。用例是代表系统中各个项目相关人员之间根据系统的行为所达成的契约。用例描述了在不同条件下,针对某一项目相关人员的请求,系统对其作出的响应。也就是说用例指的是对一组动作的描述,系统通过执行这些动作将对用例的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服

7、务或功能。,4.1.2 用例,例如,在图书管理系统中,用户可以进行“查询图书的基本信息”,“借书”以及“还书”,管理员可以对图书的基本信息进行管理,如“新增图书信息”、“修改图书信息”,“删除图书”等等操作。即这些操作都是系统提供的服务(功能),因此,这些都可以独立成为一个用例。执行这些操作的都是人(即参与者)。用例在UML中通常用一个椭圆图形符号来表示。如图4.4所示。,图4.4 用例符号,4.1.2 用例,例如,在文字处理程序中,“置正文的字体为宋体”是一个用例,在图书管理系统中“新增图书信息”、“借书”和“还书”也是用例,在超市管理系统中的“进货”也是一个用例,如图4.5所示。在这里可以

8、看出,用例可大可小,有的用例可能比较简单,而有的可能就很复杂,如“置正文的字体为宋体”这个用例就比较简单,很容易实现,但是对于“进货”和“借书”这样的用例相对就比较复杂,可能需要花一些时间才能够实现。,图4.5 用例,4.1.3 用例描述,从软件开发的角度,用例就是需求的文字性描述,主要是说明系统如何工作的功能性或行为性需求。用例图只是简单地用图形的方式描述了一下系统。实际上,用例是文本形式,不是图形。用例是作为人与人之间,尤其是没有受过专门培训的人员之间互相交流的一种手段。因此,编写用例的首选形式通常是简单的文本。因此对于每个用例,还需要有详细的说明,这样就可以让别人对这个系统有一个更加详细

9、的了解,这时我们就需要写用例描述。,4.2 用例之间的可视化表示,用例除了与参与者有关联关系外,用例之间也存在着一定的关系,如泛化关系、包含关系、扩展关系等。,4.2.1 包含关系,包含关系指的是两个用例之间的关系,其中一个用例(称为基本用例,base use case)的行为包含了另一个用例(称为包含用例,inclusion use case)的行为。也就是说基本用例会用到包含用例,表示基本用例中重用包含用例中的步骤。在UML图中,使用带虚线箭头表示,并在线上标有。如图4.7所示。,4.2.1 包含关系,图4.7 包含关系,4.2.2 扩展关系,扩展(extend)关系的基本含义与泛化关系类

10、似。extend关系是对基本用例的扩展,基本用例是一个完整的用例,即使没有子用例的参与,也可以完成一个完整的功能。extend的基本用例中将存在一个扩展点,只有当扩展点被激活时,子用例才会被执行。在扩展关系中,对于扩展用例(extension use case)有更多的规则限制,即基本用例必须声明若干“扩展点”(extension point),而扩展用例只能在这些扩展点上增加新的行为和含义。扩展关系是从扩展用例到基本用例的关系,它说明扩展用例定义的行为如何插入到基本用例定义的行为中。也就是说,扩展用例并不在基本用例中显示。,4.2.2 扩展关系,图4.8 扩展关系,4.2.3 泛化关系,泛化

11、关系指的是一般与特殊的关系。当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父用例,其它的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系,用例之间泛化关系如图4.9所示。,4.2.3 泛化关系,图4.9 泛化关系,4.2.4 分组关系,在一些用例图中,用例的数目可能很多,这时就需要把这些用例组织起来。这种情况在一个系统包含很多子系统时就会出现。另一种可能就是,当你按顺序和用户会谈,收集系统需求时,每个需求必须用一个单独的用例来表达,这时就需要某种方式来对这些需求进行分类。最直接的方法就是把相关的用例放

12、在一个包中组织起来。一组用例可以放在一个文件夹中。,4.3 用例图建模技术及应用,在传统的软件开发方法和早期的面向对象开发方法中,描述系统的功能需求都是使用自然语言。这样的做法使得系统没有一个统一的格式,随意性很大,容易产生理解上的歧义和不准确性。使用UML的用例图模型来做系统的需求,这些问题就得到了很好地解决。在前面已经详细地介绍了用例、用例图以及相关的一些概念,下面将利用上面的基础知识,结合具体的案例“图书管理系统”,根据系统的需求,创建用例图模型。,4.3 用例图建模技术及应用,1.识别出系统中的角色和用例(1)如何从系统中识别出角色获取系统用例首先要找出系统的角色。如何识别系统的角色?

13、可以从系统要完成的业务中识别系统的角色。,4.3 用例图建模技术及应用,通过与用户的交流,让用户回答一些问题来识别角色。可以参考以下问题:谁将使用系统的主要功能?谁需要系统的支持以完成其日常工作任务?谁负责维护、管理并保持系统正常运行?系统需要处理哪些硬设备?系统需要和哪些外部系统交互?系统运行产生的结果谁比较感兴趣?这几个问题的答案往往包括了所有与系统相关的用户。进一步分析这些用户,以及他们在系统中承担的作用就可以得到角色。,4.3 用例图建模技术及应用,图书管理系统涉及读者信息管理、借阅信息管理、图书信息管理等多方面的信息管理。系统的使用对象为图书管理员和读者。他们在使用系统时,各拥有不同

14、的权限,以完成各自需要的工作。在图书管理系统中,图书管理员要为每个读者建立借阅账号,用于记录读者的个人基本信息和图书的借阅信息;读者的账号信息建立成功后,给读者发借阅证,这时读者就可以凭借该借阅证进行图书的借阅,或是通过网络进行图书信息的查询和检索。,4.3 用例图建模技术及应用,读者在借阅图书时,需要出示借阅证,输入借阅证号,验证借阅证的有效性及是否可续借,无效则向读者提示原因,如,“卡号不对”,“已借满,不能续借”等,有效则显示读者的基本信息,例如读者的个人资料以及借阅图书的历史信息等,读者提出借阅申请后,管理员对借阅的图书进行登记。相应的,当读者归还图书信息时,也需要对借阅证进行有效性的

15、验证,如果不对,给读者提示相应的信息,验证通过后,显示读者的基本信息和借阅的图书信息等;读者向管理员归还图书,管理员验证无误后,删除读者对该书的借阅信息,如果超期,则读者需要缴纳一定的罚款才能归还。,4.3 用例图建模技术及应用,此外,当涉及到图书信息变更时,例如,新增图书信息或是图书毁坏程度很大需要报损不能再使用时,图书管理员就需要将图书进行入库或是注销处理。同理,当有新增的借阅者或是要注销借阅者信息时也要做相应的处理。,4.3 用例图建模技术及应用,(2)如何从系统中识别用例用例的获取是需求分析阶段的主要任务之一。但对于一个大系统,要直接列出用例清单常常是十分困难的。这时可先列出角色清单,

16、再对每个角色列出它的用例,问题就会变得容易得多。在识别出了角色之后,就可以通过回答下述问题来帮助识别用例.,4.3 用例图建模技术及应用,【例4-3】对图书管理系统进行需求分析以及第一部分得出的角色,可以得出每个角色相应的需求:其中图书管理员可实现如下操作:增加、删除和修改图书基本信息;增加、删除和修改读者信息;借书、归还图书记录的管理;查询读者基本信息、图书的基本信息。,4.3 用例图建模技术及应用,借阅图书用例描述借阅图书是图书管理系统中的一项基本功能,当读者能有效的登录到系统后就可以浏览图书的信息,进行借阅。借阅图书用例的描述如表4.4所示。还书用例描述还书是借书的逆过程,即要归还读者借

17、阅的图书,还书用例描述如表4.5所示。新增图书用例描述新增图书用例如表4.2所示。注销图书用例图书管理系统中对图书进行管理,图书有可能因为某些原因而损坏,不能再使用时,需要将其注销,注销图书用例描述如表4.6所示。,4.3 用例图建模技术及应用,2.区分用例优先次序某些用例必须在其他用例之前完成,因为它们之间要相互依赖。例如,在系统借阅图书之前,必须记录图书的基本信息。因此很明显新增图书是最重要的用例。3.构建用例图模型将已确定并细化的角色和用例放入用例图中。此时,再借助包含、扩展和泛化的关系给出用例之间的结构模型。,4.3 用例图建模技术及应用,【例4-4】图书管理系统用例图图书管理系统按其

18、业务功能分成读者管理、图书管理、借书、还书和用户管理等几部分,这些职能对应于系统不同组织部门。(1)系统参与者图书管理系统针对的对象是读者,图书管理员可以对图书信息进行管理。图4.10是图书管理系统参与者分析的用例图。其中,参与者“读者”是抽象角色。,4.3 用例图建模技术及应用,图4.10 系统角色,4.3 用例图建模技术及应用,(2)图书管理图书馆中的图书根据需求进行更新是一项日常业务,因此在设计该系统时,也要为此设计用例,管理员成功登陆图书管理系统的书籍信息管理子系统,可以进行图书的新书入库、删除、修改等。图书管理的用例图如图4.11所示。,4.3 用例图建模技术及应用,图4.11 图书

19、管理用例图,4.3 用例图建模技术及应用,图4.12 图书借阅和归还用例图,4.3 用例图建模技术及应用,图4.13 图书管理系统整体用例图,4.3 用例图建模技术及应用,【例4-5】超市进销存管理系统用例图(1)超市进销存系统的需求超市进销存系统的需求共包含销售管理、库存管理、订货管理和统计分析几部分:销售管理售货员接收顾客订购,输入顾客购买的商品,计算总价。顾客付款并接收清单。售货员保存顾客购买商品的记录清单。,4.3 用例图建模技术及应用,库存管理库存管理员每天进行盘点一次。库存管理员当发现库存商品有损坏时,及时到相关部门报损。在供应商的商品到货时,库存管理员首先检查商品是否合格,并将合

20、格的商品入库处理;当商品进入卖场时,进行商品出库处理。经理、订货员根据需要进行库存商品的模糊查询或详细查询。,4.3 用例图建模技术及应用,订货管理订货员用新商品供应商信息更新供应商数据库的信息。订货员统计库存商品是否低于库存下限,然后制作订货单。统计分析经理能够使用系统的统计功能,了解商品销售情况、库存情况、供应商情况,以便进行合理的营销策略。经理按市场情况适时变动商品价格。,4.3 用例图建模技术及应用,(2)建立超市进销存系统的用例图模型超市进销存管理系统按其业务功能分成订货管理、销售管理、库存管理和统计分析四部分,这些功能对应于系统的不同组织部门。系统角色,4.3 用例图建模技术及应用

21、,图4.14 超市进销存系统参与者之间的泛化关系,4.3 用例图建模技术及应用,超市进销存管理系统的顶层用例图,图4.15 超市进销存管理系统的顶层用例图,4.3 用例图建模技术及应用,销售管理子系统的用例图,图4.16 销售管理子系统的用例图,4.3 用例图建模技术及应用,订货管理子系统的用例图,图4.17 订货管理子系统的用例图,4.3 用例图建模技术及应用,库存管理子系统的用例图,图4.18 库存管理子系统的用例图,4.3 用例图建模技术及应用,统计分析子系统的用例图,图4.19 统计分析子系统的用例图,4.3 用例图建模技术及应用,身份验证子系统的用例图,图4.20 身份验证子系统的用

22、例图,4.4 小 结,用例建模是实现系统需求分析的一个很好的方法,使得系统分析员和用户之间能够更好的沟通系统的需求。用例图是显示一组用例、参与者以及它们之间关系的图。其中参与者在UML中通常以一个直立人的图形符号来表示;用例在UML中通常用一个椭圆图形符号来表示。用例与参与者之间具有关联关系,此外,用例之间也存在着泛化关系、包含关系、扩展关系等。面向对象和用例是UML中两个非常重要的基础概念,在本章中主要介绍的是通过举例并结合案例进行系统的用例建模,从第4章开始将逐步详细的介绍UML中其它的几种图。,习 题,1.什么是参与者?如何确定系统的参与者?2.什么是用例?如何确定系统的用例?3.用例之间有哪些关系?对每一种关系,请举出一个实际的例子,并画出用例图。4.试画出学生选课系统的用例图。5.学生管理系统中有一个模块是报到登记,具体流程是:在新生入校报到时,进行新生信息登记,记录学生的报到资料、个人基本情况的输入、查询、修改等。问题:写出在上述需求描述中出现的Actor并根据上述描述绘制其用例图,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号