| 软件工程复习笔记 用例图 | 您所在的位置：网站首页 › 画用例图软件有哪些 › 软件工程复习笔记 用例图 |
软件工程复习笔记 用例图
|
用例图
前言用例图场景关于用例用例图参与者怎样识别参与者
用例怎样获取用例？确定系统用例应注意：1. 可观测，用例止于系统边界2. 用例是有意义的目标（结果值）3. 结果值由系统生成（系统执行）4. 业务语言、用户观点（由参与者观测）5. 用例的粒度
关系四种基本关系：关联（association）包含（include）扩展（extend）泛化（generalization）
网上求职招聘系统用例建模案例分析
用例规约（即用例说明）例：“修改密码”用例规约
建立用例模型步骤例 某校网上选课系统的用例分析例1. 由此可得出系统的参与者及用例。2. 区分用例的优先次序3、细化每个用例4.建立用例模型结构
建模要点用例模型事件流
前言
copy自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了。 如有问题请多指教 用例图用户模型视图也称为用例图，它从用户的角度来描述系统功能，并指出各功能的操作者。用例图是捕获用户需求的强有力工具，它描述了系统应该实现什么样的功能 用例图是外部参与者所能观察到的系统功能的模型图，它将系统、子系统和类的行为可视化 用例图是获取需求的直接方法用例图还是软件测试人员进行测试的指导 棋牌馆管理系统用例图
场景
用例是对场景的抽象，是对一组场景共同行为的抽象 关于场景 在系统中，按照某个顺序执行了一系列相关的动作后，即可实现某种功能，把完成这一功能操作的集合称为场景。场景就是用户使用系统的一个实际的、特定的场面一个场景就是描述软件使用者与系统之间的一系列交互活动，系统具体执行的行为路径，即一次完成的事件流。e.g.小刘ATM机取款3000元的场景 小刘将银行卡插入柜员机柜员机要求客户输入卡密码小刘输入卡密码，并确认密码柜员机屏幕提示，请客户选择服务类型小刘选择取款服务柜员机提示：请客户输入取款数目小刘输入3000，并确认柜员机出钱口输出30张100元面值的人民币小刘取回30张100元面值的人民币柜员机提示服务类型：确认、继续或退卡小刘选择服务类型退卡，结束服务 关于用例用例是对场景的抽象，体现在两方面： 1）用例是对一组场景的抽象 2）用例的取名是对场景（事件）的概括 用例图用例图是描述用例、参与者及其关系的图。与UML的其他图一样，用例图可以包括注释、约束。 用例图由三部分构成： 参与者、一组（个）用例、关系
定义 是直接与系统（系统、子系统或类）相互作用的外部实体的抽象。它是用户所扮演的角色，是系统的用户每个参与者定义了一个角色集合。通常，一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。典型的参与者如销售部经理、销售员和结帐系统。图形表示 用小人图符表示 在定义用例之前要先确定系统的参与者，下面的问题有助于我们找出系统的参与者： 谁向系统提供信息？谁从系统获取信息？谁操作系统？谁维护系统？系统使用哪些外部资源？系统是否和已经存在的系统交互？由于系统对时间进行相应，“时间”是否也是一个参与者？ 用例定义 对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果描述参与者使用系统，以达到某个目标时所涉及到的一系列场景的集合。用例特征 说明了一个参与者与系统执行的一个相关的事务序列提供了一种获取系统需求的方法提供了一种与最终的用户和领域专家进行沟通的方法提供了一种测试系统的方法图形表示–用椭圆形表示，用例的名字显示在图标的下面 在确定了参与者之后，就要确定参与者要做什么，下面的问题可以帮助我们识别用例： 特定参与者希望系统提供什么功能？系统是否要存储和检索信息（涉及创建、存储、修改、删除等）？需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉参与者？如何维护系统？ 确定系统用例应注意： 1. 可观测，用例止于系统边界要点：可观测，指用例是软件系统完成的功能，并且是参与者激活的，并可以反馈处理结果给参与者看。 要点：用例止于系统边界
要点：用户观点而非系统观点即从使用者角度考虑用例的名字。 怎样确定用例的粒度？ 用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个用例左右。用例是系统级的、抽象的描述，不是细化的（是做什么，非怎样做）对复杂的系统可以划分为若干个子系统处理。
关系
关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。 在一个用例图中，可能会出现关联关系、依赖关系、泛化关系以及这三种关系的扩展形式：扩展关系、包含关系和精化关系。 四种基本关系： 关联（association） 描述参与者与用例之间的关系；用单向箭头，表示谁启动用例；每个用例都有角色启动，除包含和扩展用例；
包含（include）
是指两个用例之间的关系。其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。一个用况的执行需要依赖于另一个用况的实现   如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系。  执行基用例时，必须执行被包含用例，被包含用例也可单独执行。  如果一个用例的功能太多时，可用包含关系建模成两个或多个小用例。 
扩展（extend）
一个用例可以被定义为基础用例的增量扩展，称作扩展关系。扩展关系是把新的行为插入到已有用例中的方法。基础用例即使没有扩展用例也是完整的。一般情况下基础用例的执行不会涉及扩展用例，只有特定条件发生，扩展用例才被执行。 
泛化（generalization）
一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。任何父用例出现的地方子用例也可出现。 
网上求职招聘系统用例建模案例分析
1.对系统的求职者模块进行用况建模
所谓规约，就是业务规则的规格说明。针对每一个用况，都应该有一个用况规约文档与之相对应，以描述该用况的细节内容。每一个用况的用况规约，都应该包含以下内容 (1) 用例名称(Use Case Name).用例的名称一般由“动词+名词”构成，简单说明“做什么”。 (2) 简要说明(Brief Description).简要介绍该用例的作用和目的。 (3) 前置条件(Previous Condition).系统在执行该用例前必须处在的状态。 (4) 事件流(Flow of Event) 描述该用例所有可能的场景，它包括基本流和备选流。 基本流：描述该用例在正常情况下的场景。备选流：描述用例执行过程中一场情况或突发情况。(5) 用例场景(Use Case Scenario).包括成功场景和失败场景，场景主要由基本流和备选流组合而成。 (6) 特殊需求(Special Requirement).描述与该用例相关的非功能性需求(性能、可靠性、可用性和可扩展性等)以及涉及约束(所使用的操作系统、开发工具等)。 (7) 后置条件(Post Condition).系统在执行完该用例之后应该处在的状态 。 例：“修改密码”用例规约 用例名称：修改密码参与者：多个求职者简要说明：求职者为了密码安全且方便使用，修改了密码前置条件： 求职者已经登录网上求职招聘系统求职者输入旧密码求职者输入新密码基本事件流： 求职者鼠标单击“修改密码”按钮系统出现一个对话框，显示“密码修改成功”求职者单击“确定”按钮用例结束其他事件流A1：在单击“修改密码”按钮之间，求职者随时可以按“清空”按钮，文本框清空，可以重新填写内容。 异常事件流E1: 系统出现一个对话框，显示“旧密码输入错误”求职者单击“确定”按钮返回到修改密码页面，旧密码文本框被清空异常事件流E2: 系统出现一个对话框，显示“密码要设在6~10位之间”求职者单击“确定”按钮返回到修改密码页面，新密码文本框被清空异常事件流E3： 系统出现一个对话框，显示“旧密码输入错误3次”系统自动将该用户注销系统返回到首页后置条件：求职者的密码被重置，再次登录时必须使用新密码。
管理员通过系统管理界面登录后进入系统，建立本学期要开设的各种课程，将课程信息保存到系统中，并可以对课程能进行改动和删除。 学生可通过客户机浏览器登录后进入系统，选择课程。选课流程为：查询可选课程，选择课程并支付课程费用（可用支付宝和网银、微信三种支付方式）。 例：有一业务需求列表如下，要求我们为其构建一个用例图。 系统可以供教师使用来为学生记录成绩 系统根据需要创建报告卡 系统允许用户浏览记录的成绩 我们需要询问业务需求的提出者以获取更多的信息。教师可以对已经输入的信息进行更新吗？ 可以！ 谁来创建报告卡，是教师吗？ 不！有一位管理人员来做这项工作。 报告卡创建后，我们还可以对它做些什么工作？ 在报告卡创建后，我们的管理人员要检查其准确性。当报告卡核准后，教师应该通过计算机分发报告卡。 谁需要浏览成绩？ 教师和学生。 通过访谈，我们就会得出一个修改过的新的系统需求列表。 我们需要的系统可以供教师使用，来为学生记录并更新成绩。系统根据需求由管理人员创建报告卡，管理人员要检查报告卡的准确性。教师需要通过计算机分发报告卡。系统允许教师和学生浏览记录的成绩。 1. 由此可得出系统的参与者及用例。参与者 教师、学生、管理员用例 记录成绩更新成绩生成报告卡检查报告卡的准确性分发报告卡浏览成绩 2. 区分用例的优先次序 记录成绩浏览成绩更新成绩生成报告卡检查报告卡的准确性分发报告卡 3、细化每个用例对“记录成绩”用例进行细化，下面是该用例的主事件流。 教师确定出要记录哪些学生的成绩。系统要确保学生在数据库中。教师说明要记录哪项作业的成绩。系统开始数据库的一项事务处理。系统为学生把作业加入数据库。教师输入学生作业的成绩。系统核对输入的成绩以确保其属于正确的范围。系统记录作业的成绩。系统结束事务的处理。系统提示教师成绩已经记录。细化过程中可添加新发现的用例，并根据优先级重新排列。 登录保存成绩记录成绩加载成绩浏览成绩更新成绩生成报告卡分发报告卡 4.建立用例模型结构
（1）构建结构良好的用例 为系统和部分系统中单个的、可标识和合理的原子行为命名；将公共的行为抽取出来，放到一个被包含用例中，再将它《include》进来；对于变化部分，将其抽取出来，放到一个扩展用例（用《extent》连接）中；清晰地描述事件流 （2）构建结构良好的用例图 （3）根据系统实际情况控制粒度 用例模型一个用例模型由一个或者多个用例图和所有的支持文件（诸如用例规范和参与者定义等）所构成。用例规范是大多数用例模型的产物，而用例图充当将需求模型综合在一起的粘胶剂。 用例模型应当从项目投资者的角度进行开发，而不是从开发者的（通常是技术）观点去开发。 事件流执行用例时，其动作的有序集合称为事件流 事件流描述的目的是建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作，既包括正常状态下系统完成需求行为的事件，也包括在其他状态下不能完成需求行为的事件。事件流描述通常包括： 简要说明前置条件事件流后置条件 |
把系统内部活动当用例 
2.对系统的招聘者模块进行用况建模
3.对系统的管理员模块进行用况建模 
4.对系统总体功能进行建模 
【本文地址】