需求分析与用例模型.pptx

第第3 3章章 需求分析与用例模型需求分析与用例模型 在软件工程中，需求分析指的是在建立系统时描写系统的目的、范围、定义和功能时要做的所有工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师要确定顾客的需求。第1页/共73页第第3 3章章 需求分析与用例模型需求分析与用例模型软件开发过程中常见的场景软件开发过程中常见的场景软件开发过程中常见的场景软件开发过程中常见的场景第2页/共73页第第3 3章章 需求分析与用例模型需求分析与用例模型什么是需求？什么是需求？什么是需求？什么是需求？需求层次内容业务需求 客户对系统、产品高层次的目标要求。通常问题定义就是业务需求用户需求 描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求系统需求 从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束。第3页/共73页第第3 3章章 需求分析与用例模型需求分析与用例模型在统一过程（UP）中，需求按照“FURPS”模型进行分类。功能性（Functional）：特性、功能、安全性；可用性（Usability）：人性化因素、帮助、文档；可靠性（Reliability）：故障频率、可恢复性、可预测性；性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率；可支持性（Supportability）：适应性、可维护性、国际化、可配置性。非非功功能能性性需需求求第4页/共73页系统的诞生系统的诞生系统架构如何开始？系统架构如何开始？从从从从 用用用用 例例例例 图图图图 开开开开 始！始！始！始！第5页/共73页一、一、什么叫用例图什么叫用例图 在系统开发的初期阶段，基于以下目的做成用例图：明确开发系统的主要功能明确开发系统的范围明确开发对象和外界的关系1 1 1 1、用例图的目的、用例图的目的、用例图的目的、用例图的目的第6页/共73页一、一、什么叫用例图什么叫用例图2 2 2 2、用例图的含义、用例图的含义、用例图的含义、用例图的含义由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图（Use Case Diagram）。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。话的被动接受者。第7页/共73页一、一、什么叫用例图什么叫用例图 在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。第8页/共73页一、一、什么叫用例图什么叫用例图3 3 3 3、用例图的作用、用例图的作用、用例图的作用、用例图的作用 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。第9页/共73页一、一、什么叫用例图什么叫用例图3 3 3 3、用例图的作用、用例图的作用、用例图的作用、用例图的作用 获取需求、指导测试、对开发过程中的其他工作起指导作用。第10页/共73页二、用例图的构成要素二、用例图的构成要素用例图包含3方面内容：用例图中可以包含注释、约束参与者参与者（ActorActor）用例用例（Use CaseUse Case）关系关系：关联（关联（AssociationAssociation）泛化（泛化（GeneralizationGeneralization）包含（包含（IncludeInclude）扩展（扩展（ExtendExtend）第11页/共73页二、用例图的构成要素二、用例图的构成要素参与者参与者参与者参与者o参与者是系统外部的一个实体，以某种方式参与用例的执行过程。是为了完成一个事件与系统进行交互的实体，是与系统交互作用的外部用户、进程或其他系统的理想化概念。o在UML中，参与者用名字写在下面的人形图标表示。第12页/共73页二、用例图的构成要素二、用例图的构成要素参与者由它们参与用例时所担当的角色来表示。第13页/共73页二、用例图的构成要素二、用例图的构成要素o任何事物人、外系统、特殊的硬件、时间(到某一时间触发某一事件）等第14页/共73页参与者的识别参与者的识别 在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻求系统参与者。（1）使用系统主要功能的人是谁？（2）需要借助于系统完成日常工作的人是谁？（3）谁来维护管理系统保证系统正常工作？（4）系统控制的硬件有哪些？（5）系统与哪些其他系统交互？（6）对本系统产生的结果感兴趣的人或事是哪些？第15页/共73页参与者之间的关系参与者之间的关系多个参与者之间可以具有与类之间相同的关系。在用例图中，可以使用泛化关系来描述多个参与者之间的公共公共行为行为。第16页/共73页参与者之间的关系参与者之间的关系例如，在图书馆管理系统中，借书者可以泛化成两类：学生和老师。再如，航空售票系统接受客户预定机票，客户可以进行电话预定和网上预定，如果不考虑客户是如何与系统接触的，可以使用一般角色的参与者，即父类；如果强调接触发生的形式，那么必须使用实际的参与者，即子类。第17页/共73页参与者之间的关系参与者之间的关系更具一般的，可以由下图表示参与者之间的关系。第18页/共73页用例用例用例是站在使用者的立场上看到的系统所提供的功能。用例是站在使用者的立场上看到的系统所提供的功能。用例是站在使用者的立场上看到的系统所提供的功能。用例是站在使用者的立场上看到的系统所提供的功能。用例是系统中的功能一个用例表示一个功能，集中所有的用例，可完整描述如何使用该系统可以通过关联线与参与者连接，一个用例至少与一个参与者相关联。给用例取名字要站在使用者的立场上考虑可以用系统边界把用例框起来以区分系统内外在UML中，用例用一个椭圆来表示，用例的名字可以写在椭圆的下方。第19页/共73页用例的识别用例的识别用例图对整个系统的建模过程非常重要，在绘制系统用例图前，有许多工作需要做。系统分析者必须分析系统的参与者和用例，它们分别描述了“谁来做”和“做什么”这两个问题。识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者。第20页/共73页用例的识别用例的识别在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。参与者要从系统中获得哪种功能？参与者需要做什么？参与者需要读取、产生、删除、修改或存储系统中的某种信息吗？系统中发生的事件要通知参与者吗？或者参与者需要通知系统某事件吗？这些事件（功能）能干什么？用系统的新功能处理参与者的日常工作是简化了，还是提高了工作效率？第21页/共73页用例的识别用例的识别还有一些与当前参与者的日常工作无关的问题，也能帮助发现用例 系统需要的输入、输出是什么信息？这些信息是从哪里来到哪里去？系统当前的这种实现方法要解决什么问题（也许用自动系统代替手工操作）？第22页/共73页用例之间的各种关系用例之间的各种关系 用例图中，除了参与者与用例之间的关联关系外，参与者和参与者之间可以有泛化关系，用例和用例之间有泛化关系、包含关系和扩展关系。1.1.关联关系关联关系参与者与用例之间通常用关联关系来描述。每个参与者可以参与一个或多个用例。参与者与用例之间的关联关系使用带箭头或者不带箭头的实现表示。第23页/共73页用例之间的各种关系用例之间的各种关系2.2.泛化关系泛化关系如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。第24页/共73页用例之间的各种关系用例之间的各种关系2.2.泛化关系泛化关系如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。第25页/共73页用例之间的各种关系用例之间的各种关系3.3.包含关系包含关系包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。在UML中，用例之间的包含关系含有关键字的带有箭头的虚线表示。第26页/共73页3.3.包含关系包含关系第27页/共73页3.3.包含关系包含关系第28页/共73页3.3.包含关系包含关系第29页/共73页3.3.包含关系包含关系使用场合使用场合如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统）意义意义 有助于将来实现系统时，确定哪些功能可以重用，在编写代码时就可以实现代码的重用，缩短开发周期。注意：执行基用例时，每次都必须调用被包含用例。第30页/共73页包含关系误用包含关系误用第31页/共73页用例之间的各种关系用例之间的各种关系4.4.扩展关系扩展关系扩展关系是一个用例被定义为基础用例的增量扩展，通过扩展关系把新的行为插入到已有用例中。扩展关系中，扩展用例是基础用例的一个相对独立并且可选的用例。在UML中，扩展关系用虚线箭头加表示，箭头指向基础用例，即被扩展的用例第32页/共73页4.4.扩展关系扩展关系第33页/共73页4.4.扩展关系扩展关系课表查询系统课表查询系统第34页/共73页4.4.扩展关系扩展关系使用场合使用场合 对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作可选的或只在特定条件下才执行的动作放在它的扩展用例中。第35页/共73页扩展关系误用扩展关系误用第36页/共73页实例分析：棋牌馆管理系统实例分析：棋牌馆管理系统第37页/共73页实例分析：网上书店实例分析：网上书店第38页/共73页用例粒度用例粒度用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。第39页/共73页用例粒度用例粒度比较下列两图用例的粒度比较下列两图用例的粒度第40页/共73页用例粒度用例粒度如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析第41页/共73页用例粒度用例粒度错误一：错误一：把步骤当用例把步骤当用例身份验证第42页/共73页用例粒度用例粒度错误二：把系统活动当用例错误二：把系统活动当用例第43页/共73页用例规约用例规约 用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识。但对于每一个用例还需要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这些信息包含在用例规约之中。用例模型指的也不仅仅是用例图，而是由用例图和用例的详细描述用例规约所组成的。用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉第44页/共73页用例规约用例规约用例规约包含以下内容：1 简要说明:对用例作用和目的的简要描述。2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。4 特殊需求:特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。5 前置条件:执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。第45页/共73页事件流事件流说明用例如何开始和结束。只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。避免不明确的术语，如“例如”、“等等”和“信息”第46页/共73页事件流事件流在事件流里要对事件流进行结构化说明基本事件流描述每个情节的行为者:目标语句对的顺序假设之前的每一步都是成功的备选事件流异常情况第47页/共73页特殊需求特殊需求非功能需求(URPS)可用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）设计约束用Oracle数据库平台，用PB开发软件必须符合ISO标准本质上不是需求，只是从商业、行政、技术上的约束第48页/共73页用例规约实例用例规约实例用例编号UC01用例名称用户注册用例概述未注册用户注册成为会员参与者未注册用户前置条件用户在主页单击“注册”,进入注册程序后置条件注册时填写的用户信息保存到系统中基本事件流1.系统显示注册页面；2.用户填写用户名、密码等相关信息后提交；3.系统处理该请求并显示注册成功；4.注册成功后跳转到登录页面；扩展事件流2a.如果填写的用户名已经存在，则提示错误信息：用户名已经存在 如果密码不符合要求，则提示错误信息：密码格式不正确；3a.注册失败 系统再跳转到注册页面，提示用户重新注册；规则与约束无第49页/共73页用例规约实例用例规约实例用例编号UC02用例名称登录用例概述验证用户名和密码参与者系统的注册用户前置条件无后置条件登录的用户已经注册基本事件流1.用户填写用户名、密码，点击“登录”；2.系统验证用户名和密码；3.验证成功，系统跳转到用户主页；扩展事件流3a.验证失败 3a1:如果用户名不存在，系统提示“用户名不存在”；如果密码错误，则系统提示“用户名或密码错误”；3a2:让用户重填用户名和密码规则与约束 无第50页/共73页用例规约实例用例规约实例用例编号UC03用例名称新增书籍信息用例概述录入新购书信息，并自动存储建档参与者图书管理员前置条件用户进入图书管理系统中的“新增书籍信息”程序后置条件完成新书信息的存储建档基本事件流1.系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；2.图书管理员做出选择后，显示相应的页面，让图书管理员输入信息，并自动根据书号规则生成书号；3.图书管理员输入书籍信息，包括书名、作者、出版社、ISBN、定价；4.系统确认输的入信息中书名没有重名；5.系统将所输入的信息存储建档扩展事件流5a.如果输入的书名有重名，则显示重名的书籍，并要求图书管理员选择修改书名或取消输入 5a1.图书管理员选择取消输入，则结束用例，不做存储建档工作；5a2.图书管理员选择修改书名后，转到第5步规则与约束无第51页/共73页实例实例1-1-企业进、销、存管理系统企业进、销、存管理系统1 1 1 1、需求分析、需求分析“企业进、存、销管理系统”功能性需求包括以下内容：（1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。第52页/共73页实例实例1-1-企业进、销、存管理系统企业进、销、存管理系统 （2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。第53页/共73页实例实例1-1-企业进、销、存管理系统企业进、销、存管理系统 （3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。第54页/共73页实例实例1-1-企业进、销、存管理系统企业进、销、存管理系统 （4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。第55页/共73页实例实例1-1-企业进、销、存管理系统企业进、销、存管理系统 （5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。第56页/共73页 （1）销售员：为客户客提供销售产品的服务。（2）仓库管理员：负责库存产品的管理活动。（3）采购员：负责企业生产原料的订购。（4）会计：负责企业经营状况的统计。（5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。2 2 2 2、识别参与者、识别参与者、识别参与者、识别参与者第57页/共73页3 3 3 3、构建用例模型、构建用例模型、构建用例模型、构建用例模型（1）销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。销销售售员员用用例例图图第58页/共73页3 3 3 3、构建用例模型、构建用例模型、构建用例模型、构建用例模型（2）仓库管理员能够通过该系统进行如下活动：处理盘点：每天需要对库存产品信息进行盘点。产品入库：当产品生产后，将产品进行入库。产品出库：当产品销售发货后，进行出库处理。管理设置：仓库管理员负责供应商信息、产品基本信息的管理设置。仓仓库库管管理理员员用用例例图图第59页/共73页3 3 3 3、构建用例模型、构建用例模型、构建用例模型、构建用例模型（3）采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。采采购购员员用用例例图图第60页/共73页3 3 3 3、构建用例模型、构建用例模型、构建用例模型、构建用例模型（4）会计负责产品的统计分析管理，它能够通过该系统进行如下活动：查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。查询供应商信息。会计能够查询供应商信息。查询缺货信息。会计能够查询缺货信息。查询报损信息。会计能够查询报损信息。会会计计用用例例图图第61页/共73页3 3 3 3、构建用例模型、构建用例模型、构建用例模型、构建用例模型（5）系统管理员能够通过该系统进行如下活动：维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。系统设置。系统管理员能够根据一些需要进行必要的系统设置。系系统统管管理理员员用用例例图图第62页/共73页实例实例2-2-学生信息管理系统学生信息管理系统在每个新学年开始的时候都会有新生入学。这时：管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、学生证号、身份证号等基本信息存入数据库。在日常的管理中：系统管理员还可以对所有学生的基本信息进行查询、修改、删除等操作。校领导可以查询、修改全校学生的基本信息教师查询、修改自己班里学生的基本信息。学校的领导可以通过本系统了解每个班的任课教师、辅导员、学生、专业等班级基本信息。第63页/共73页实例实例2-2-学生信息管理系统学生信息管理系统系统管理员可以进行查询班级基本信息、添加新班级、修改班级信息、删除班级等操作。考试结束后，教师可以录入学生成绩，还可以对成绩进行修改和查询。学生可以查询成绩。学生可以网上选课，可以通过系统看到课程的信息。每个学生每个学期的选课不得大于6门，如果已经选了6门课则不能选择新的课程。只有将已选的课程删除后才能再选。系统管理员负责修改、增加、删除选修课程。每个用户登陆系统，都需要一个账号，这就需要系统管理员对用户账户进行管理。第64页/共73页需求分析需求分析1.1.1.1.学生信息管理模块学生信息管理模块学生信息管理模块学生信息管理模块 学生信息管理模块主要用来实现系统管理员、教师、校领导等对学生基本信息的管理。系统管理员登录后可以对学生的基本信息进行增加、删除、修改和查询等操作；校领导登录后可以对全校学生信息进行查询和修改操作。教师登录后可以对本班学生信息进行查询和修改操作。第65页/共73页需求分析需求分析2.2.2.2.班级信息管理模块班级信息管理模块班级信息管理模块班级信息管理模块 班级信息管理模块主要用来实现系统管理员、校领导对班级基本信息的管理。系统管理员登录后可以对班级基本信息进行增加、删除、修改和查询等操作；校领导登录后可以对学生信息进行查询操作。3.3.3.3.成绩管理模块成绩管理模块成绩管理模块成绩管理模块 成绩管理模块主要用于实现教师对学生考试成绩的管理以及学生对考试成绩的查询。教师登录后可以对学生成绩进行录入、删除、修改和查询等操作；学生登录后可以对成绩进行查询操作。第66页/共73页需求分析需求分析4.4.4.4.网上选课模块网上选课模块网上选课模块网上选课模块 网上选课模块主要用于实现学生在网上了解并选择自己感兴趣的课程。5.5.5.5.账号管理模块账号管理模块账号管理模块账号管理模块 账号管理模块主要实现系统管理员对用户账号的管理。系统管理员可以对账号进行增加、删除、修改和查询等操作。第67页/共73页构建用例模型构建用例模型1.1.1.1.班级信息管理用例图班级信息管理用例图班级信息管理用例图班级信息管理用例图 第68页/共73页2.2.2.2.成绩管理用例图成绩管理用例图 第69页/共73页3.3.3.3.网上选课用例图网上选课用例图网上选课用例图网上选课用例图 第70页/共73页4.4.4.4.账号管理用例图账号管理用例图账号管理用例图账号管理用例图 第71页/共73页比较下列用例图比较下列用例图比较下列用例图比较下列用例图 第72页/共73页感谢您的观看！第73页/共73页