第3章 需求分析与用例模型

用例之间的各种关系
3.包含关系 包含关系描述的是一个用例需要某种功能，而该功能被另外一个 用例定义，那么在用例的执行过程中，就可以调用已经定义好的用 例。 在UML中，用例之间的包含关系含有关键字<<include>>的带有箭 头的虚线表示。
3.包含关系
3.包含关系
3.包含关系
3.包含关系
一、 什么叫用例图
3、用例图的作用 获取需求、指导测试、对开发过程中的其他工作起指 导作用。
二、用例图的构成要素
用例图包含3方面内容：
参与者（Actor）
用例（Use Case）
关系： 关联（Association）
泛化（Generalization）
包含（Include） 扩展（Extend）
带箭头的线段来描述，箭头表示在这一关系中 哪一方是对话的主动发起者，箭头所指方是对 话的被动接受者。
一、 什么叫用例图
在用例建模中，为了更加清楚的描述用例或者参与者，会 使用到注释。
一、 什么叫用例图
3、用例图的作用
用例图是需求分析中的产物，主要作用是描述参与者和用例之间 的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系 统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方 式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图可视化地表达了系统的需求，具有直观、规范等优点，克 服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的 分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于 我们来说就是一个黑箱子。
比较下列两图用例的粒度 用例粒度
用例粒度
如果用例的粒度很小，得到的用例数就会太多。反之， 如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困 难大大提高。如果用例数目过少会造成用例的粒度太 大，不便于进一步的充分分析
用例粒度
错误一：把步骤当用例
软件需求
用例编号 用例名称 用例概述 参与者 前置条件 后置条件
UC01 用例规约实例 用户注册 未注册用户注册成为会员 未注册用户 用户在主页单击“注册”,进入注册程序 注册时填写的用户信息保存到系统中
1.系统显示注册页面； 2.用户填写用户名、密码等相关信息后提交； 基本事件流 3.系统处理该请求并显示注册成功； 4.注册成功后跳转到登录页面；Байду номын сангаас
借书者
客户
学生
老师
电话客户
网上客户
参与者之间的关系
更具一般的，可以由下图表示参与者之间的关系。
超类参与者
特殊化参与者
特殊化参与者
用例
用例是站在使用者的立场上看到的系统所提供的功能。
用例是系统中的功能 一个用例表示一个功能，集中所有的用例，可完整描述如何使用该 系统 可以通过关联线与参与者连接，一个用例至少与一个参与者相关联。 给用例取名字要站在使用者的立场上考虑 可以用系统边界把用例框起来以区分系统内外 在UML中，用例用一个椭圆来表示，用例的名字可以写在椭圆的下方。
注意：执行基用例时，每次都必须调用被包含用例。
包含关系误用
用例之间的各种关系
4.扩展关系
扩展关系是一个用例被定义为基础用例的增量扩展，通过 扩展关系把新的行为插入到已有用例中。扩展关系中，扩 展用例是基础用例的一个相对独立并且可选的用例。 在UML中，扩展关系用虚线箭头加<<extend>>表示，箭头 指向基础用例，即被扩展的用例
参与者之间的关系
多个参与者之间可以具有与类之间相同的关系。 在用例图中，可以使用泛化关系来描述多个参与者之间的 。
参与者之间的关系
例如，在图书馆管理系统中，借书者可以泛化成两类：学生和 老师。 再如，航空售票系统接受客户预定机票，客户可以进行电话预 定和网上预定，如果不考虑客户是如何与系统接触的，可以使 用一般角色的参与者，即父类；如果强调接触发生的形式，那 么必须使用实际的参与者，即子类。
用例之间的各种关系
2.泛化关系 如果系统中一个或多个用例是某个一般用例的特殊化时，就需 要使用用例的泛化关系。 在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
用例之间的各种关系
2.泛化关系 如果系统中一个或多个用例是某个一般用例的特殊化时，就需 要使用用例的泛化关系。 在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
业务需求
用户需求
系统需求
第3章 需求分析与用例模型
在统一过程（UP）中，需求按照“FURPS”模型进行分类。 功能性（Functional）：特性、功能、安全性； 可用性（Usability）：人性化因素、帮助、文档； 非 可靠性（Reliability）：故障频率、可恢复性、可预测 功 能 性； 性 性能（Performance）：响应时间、吞吐量、准确性、有 需 求 效性、资源利用率； 可支持性（Supportability）：适应性、可维护性、国 际化、可配置性。
用例的识别
在识别用例的过程中，通过回答以下几个问题，系统分析者可 以获得帮助。 • ⑴ 参与者要从系统中获得哪种功能？参与者需要做什么？ • ⑵ 参与者需要读取、产生、删除、修改或存储系统中的某种信 息吗？ • ⑶ 系统中发生的事件要通知参与者吗？或者参与者需要通知系 统某事件吗？这些事件（功能）能干什么？ • ⑷ 用系统的新功能处理参与者的日常工作是简化了，还是提高 了工作效率？
特殊需求
非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 非功能需求 功能需求 设计约束 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上 的约束
二、用例图的构成要素
任何事物 人、外系统、特殊的硬件、时间(到某一时间触发某一事件）等
参与者的识别
在获取用例前要先确定系统的参与者，可以根据以下 的一些问题来寻求系统参与者。 （1）使用系统主要功能的人是谁？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护管理系统保证系统正常工作？ （4）系统控制的硬件有哪些？ （5）系统与哪些其他系统交互？ （6）对本系统产生的结果感兴趣的人或事是哪些？
第3章 需求分析与用例模型
第3章 需求分析与用例模型
在软件工程中，需求分析指的是在建立系统时描写系统 的目的、范围、定义和功能时要做的所有工作。 需求分析是软件工程中的一个关键过程。在这个过程中， 系统分析员和软件工程师要确定顾客的需求。
第3章 需求分析与用例模型
软件开发过程中常见的场景
第3章 需求分析与用例模型
事件流
说明用例如何开始和结束。只说明属于该用例的事件， 而不是发生在其他用例中或系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“信息”
事件流
在事件流里要对事件流进行结构化说明 基本事件流 • 描述每个情节的行为者:目标语句对的顺序 • 假设之前的每一步都是成功的 备选事件流 • 异常情况
使用场合 如果两个以上用例有大量一致的功能，则可以将这个功能分解到 另一个用例中，其他用例可以和这个用例建立包含关系（如之前介 绍的饮料自动售货机）。 一个用例的功能太多时，可以使用包含关系建立若干个更小的 用例。（如学生管理系统）
意义
有助于将来实现系统时，确定哪些功能可以重用，在编写代码 时就可以实现代码的重用，缩短开发周期。
用例名
用例的识别
用例图对整个系统的建模过程非常重要，在绘制系统用例图前， 有许多工作需要做。 系统分析者必须分析系统的参与者和用例，它们分别描述了 “谁来做”和“做什么”这两个问题。 识别用例最好的方法就是从分析系统的参与者开始，考虑每个 参与者是如何使用系统的。使用这种策略的过程中可能会发现 新的参与者。
什么是需求？
需求层次 内容 客户对系统、产品高层次的目标要求。通常问题定义 就是业务需求 描述用户使用产品必须要完成什么任务，怎么完成， 通常是在问题定义的基础上进用户访谈、调查，对用 户使用的场景进行整理，从而建立从用户角度的需求 从系统的角度来说明软件的需求，它就包括了用特性 说明的功能需求，质量属性以及其它非功能需求，还 有设计约束。
4.扩展关系
课表查询系统 4.扩展关系
4.扩展关系
使用场合 对扩展用例的限制规则：将一些常规的动作放在一个 基本用例中，将可选的或只在特定条件下才执行的动作放 在它的扩展用例中。
扩展关系误用
实例分析：棋牌馆管理系统
实例分析：网上书店
用例粒度
用例的粒度指的是用例所包含的系统服务或功能单元 的多少。 用例的粒度越大，用例包含的功能越多，反之则包含 的功能越少。
系统的诞生
系统架构如何开始？
从 用 例 图 开 始！
一、 什么叫用例图
1、用例图的目的
在系统开发的初期阶段，基于以下目的做成用例图： 明确开发系统的主要功能 明确开发系统的范围 明确开发对象和外界的关系
一、 什么叫用例图
2、用例图的含义
由参与者（Actor）、用例（Use Case）以及 它们之间的关系构成的用于描述系统功能的动 态视图称为用例图（Use Case Diagram）。 要在用例图上显示某个用例，可绘制一个椭 圆，然后将用例的名称放在椭圆的中心或椭圆 下面的中间位置。 要在用例图上绘制一个参与者（表示一个系 统用户），可绘制一个人形符号。 参与者和用例之间的关系使用带箭头或者不
会员
输入用户名
<<include>>
会员
登录
验证用户名和密码
身份验证
用例粒度
错误二：把系统活动当用例
<<include>> 建立数据库连接 <<include>> 查询订单 执行SQL语句
用例规约
用例图只是在总体上大致描述了系统所提供的各种服 务，让用户对系统有一个总体的认识。但对于每一个用例 还需要有详细的描述信息，以便让其他人对于整个系统有 一个更加详细地了解，这些信息包含在用例规约之中。 用例模型指的也不仅仅是用例图，而是由用例图和用 例的详细描述——用例规约所组成的。
用例的识别
还有一些与当前参与者的日常工作无关的问题，也能帮助发现 用例 • ⑴ 系统需要的输入、输出是什么信息？这些信息是从哪里来到 哪里去？ • ⑵ 系统当前的这种实现方法要解决什么问题（也许用自动系统 代替手工操作）？
用例之间的各种关系
用例图中，除了参与者与用例之间的关联关系外，参与者和参 与者之间可以有泛化关系，用例和用例之间有泛化关系、包含关系 和扩展关系。 1.关联关系 参与者与用例之间通常用关联关系来描述。每个参与者可以参 与一个或多个用例。 参与者与用例之间的关联关系使用带箭头或者不带箭头的实现 表示。
用例图是骨架，而用例规约则是其内在的肉
用例规约
用例规约包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本 流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生， 称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。 特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性 等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属 性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件 是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求 在某个用例执行完后，必须执行另一个用例。
用例图中可以包含注释、约束
二、用例图的构成要素
参与者 参与者是系统外部的一个实体，以某种方式参与用例的
执行过程。是为了完成一个事件与系统进行交互的实体
，是与系统交互作用的外部用户、进程或其他系统的理 想化概念。
在UML中，参与者用名字写在下面的人形图标表示。
二、用例图的构成要素
参与者由它们参与用例时所担当的角色来表示。