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

《第3章需求分析与用例模型资料》由会员分享，可在线阅读，更多相关《第3章需求分析与用例模型资料（73页珍藏版）》请在金锄头文库上搜索。

1、第3章 需求分析与用例模型,第3章 需求分析与用例模型,在软件工程中，需求分析指的是在建立系统时描写系统的目的、范围、定义和功能时要做的所有工作。 需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师要确定顾客的需求。,第3章 需求分析与用例模型,软件开发过程中常见的场景,第3章 需求分析与用例模型,什么是需求？,第3章 需求分析与用例模型,在统一过程（UP）中，需求按照“FURPS”模型进行分类。 功能性（Functional）：特性、功能、安全性； 可用性（Usability）：人性化因素、帮助、文档； 可靠性（Reliability）：故障频率、可恢复性、可预测性；

2、性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。,非功能性需求,系统的诞生,系统架构如何开始？,从 用 例 图 开 始！,一、 什么叫用例图,在系统开发的初期阶段，基于以下目的做成用例图： 明确开发系统的主要功能 明确开发系统的范围 明确开发对象和外界的关系,1、用例图的目的,一、 什么叫用例图,2、用例图的含义,由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图（Use Case Diagram）。 要在用例图上显示某个用例，

3、可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。 要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。 参与者和用例之间的关系使用带箭头或者不 带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。,一、 什么叫用例图,在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。,一、 什么叫用例图,3、用例图的作用,用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了

4、大量交流上的障碍，便于对问题达成共识。 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。,一、 什么叫用例图,3、用例图的作用,获取需求、指导测试、对开发过程中的其他工作起指导作用。,二、用例图的构成要素,用例图包含3方面内容： 用例图中可以包含注释、约束,参与者（Actor） 用例（Use Case） 关系： 关联（Association） 泛化（Generalization） 包含（Include） 扩展（Extend

5、）,二、用例图的构成要素,参与者,参与者是系统外部的一个实体，以某种方式参与用例的执行过程。是为了完成一个事件与系统进行交互的实体，是与系统交互作用的外部用户、进程或其他系统的理想化概念。 在UML中，参与者用名字写在下面的人形图标表示。,二、用例图的构成要素,参与者由它们参与用例时所担当的角色来表示。,二、用例图的构成要素,任何事物 人、外系统、特殊的硬件、时间(到某一时间触发某一事件）等,参与者的识别,在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻求系统参与者。 （1）使用系统主要功能的人是谁？ （2）需要借助于系统完成日常工作的人是谁？ （3）谁来维护管理系统保证系统正常工

6、作？ （4）系统控制的硬件有哪些？ （5）系统与哪些其他系统交互？ （6）对本系统产生的结果感兴趣的人或事是哪些？,参与者之间的关系,多个参与者之间可以具有与类之间相同的关系。 在用例图中，可以使用泛化关系来描述多个参与者之间的公共行为。,参与者之间的关系,例如，在图书馆管理系统中，借书者可以泛化成两类：学生和老师。 再如，航空售票系统接受客户预定机票，客户可以进行电话预定和网上预定，如果不考虑客户是如何与系统接触的，可以使用一般角色的参与者，即父类；如果强调接触发生的形式，那么必须使用实际的参与者，即子类。,参与者之间的关系,更具一般的，可以由下图表示参与者之间的关系。,用例,用例是站在使用

7、者的立场上看到的系统所提供的功能。 用例是系统中的功能 一个用例表示一个功能，集中所有的用例，可完整描述如何使用该系统 可以通过关联线与参与者连接，一个用例至少与一个参与者相关联。 给用例取名字要站在使用者的立场上考虑 可以用系统边界把用例框起来以区分系统内外 在UML中，用例用一个椭圆来表示，用例的名字可以写在椭圆的下方。,用例的识别,用例图对整个系统的建模过程非常重要，在绘制系统用例图前，有许多工作需要做。 系统分析者必须分析系统的参与者和用例，它们分别描述了“谁来做”和“做什么”这两个问题。 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。使用这种策略的过程

8、中可能会发现新的参与者。,用例的识别,在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。 参与者要从系统中获得哪种功能？参与者需要做什么？ 参与者需要读取、产生、删除、修改或存储系统中的某种信息吗？ 系统中发生的事件要通知参与者吗？或者参与者需要通知系统某事件吗？这些事件（功能）能干什么？ 用系统的新功能处理参与者的日常工作是简化了，还是提高了工作效率？,用例的识别,还有一些与当前参与者的日常工作无关的问题，也能帮助发现用例 系统需要的输入、输出是什么信息？这些信息是从哪里来到哪里去？ 系统当前的这种实现方法要解决什么问题（也许用自动系统代替手工操作）？,用例之间的各种关系,用

9、例图中，除了参与者与用例之间的关联关系外，参与者和参与者之间可以有泛化关系，用例和用例之间有泛化关系、包含关系和扩展关系。 1.关联关系 参与者与用例之间通常用关联关系来描述。每个参与者可以参与一个或多个用例。 参与者与用例之间的关联关系使用带箭头或者不带箭头的实现表示。,用例之间的各种关系,2.泛化关系 如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。 在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。,用例之间的各种关系,2.泛化关系 如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。 在UML中，用例泛

10、化与其他泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。,用例之间的各种关系,3.包含关系 包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。 在UML中，用例之间的包含关系含有关键字的带有箭头的虚线表示。,3.包含关系,3.包含关系,3.包含关系,3.包含关系,使用场合 如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。 一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统）,意义 有助于将来实现系统时，确定

11、哪些功能可以重用，在编写代码时就可以实现代码的重用，缩短开发周期。 注意：执行基用例时，每次都必须调用被包含用例。,包含关系误用,用例之间的各种关系,4.扩展关系,扩展关系是一个用例被定义为基础用例的增量扩展，通过扩展关系把新的行为插入到已有用例中。扩展关系中，扩展用例是基础用例的一个相对独立并且可选的用例。 在UML中，扩展关系用虚线箭头加表示，箭头指向基础用例，即被扩展的用例,4.扩展关系,4.扩展关系,课表查询系统,4.扩展关系,使用场合 对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。,扩展关系误用,实例分析：棋牌馆管理

12、系统,实例分析：网上书店,用例粒度,用例的粒度指的是用例所包含的系统服务或功能单元的多少。 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。,用例粒度,比较下列两图用例的粒度,用例粒度,如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析,用例粒度,错误一：把步骤当用例,身份验证,用例粒度,错误二：把系统活动当用例,用例规约,用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识。但对于每一个用例还需

13、要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这些信息包含在用例规约之中。 用例模型指的也不仅仅是用例图，而是由用例图和用例的详细描述用例规约所组成的。,用例图是骨架，而用例规约则是其内在的肉,用例规约,用例规约包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包

14、括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。,事件流,说明用例如何开始和结束。只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“信息”,事件流,在事件流里要对事件流进行结构化说明 基本事件流 描述每个情节的行为者:目标语句对的顺序 假设之前的每一步都是成功的 备选

15、事件流 异常情况,特殊需求,非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发 软件必须符合ISO标准 本质上不是需求，只是从商业、行政、技术上的约束,用例规约实例,用例规约实例,用例规约实例,实例1-企业进、销、存管理系统,1、需求分析,“企业进、存、销管理系统” 功能性需求包括以下内容： （1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。,实例1-企业进、销、存管理

16、系统,（2）仓库管理员负责产品的库存管理。 包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。 仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。,实例1-企业进、销、存管理系统,（3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。,实例1-企业进、销、存管理系统,（4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。,实例1-企业进、销、存管理系统,（5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护