第2讲需求分析与用例建模.ppt

计算机科学与通信工程学院 betts-li@ 面向对象技术 第2讲 需求分析与用例建模 内容提要 需求分析概述 用例建模技术 用例建模实例 需求分析概述 需求描述一个系统应该做什么，而不是系统应该怎么做； 需求分析则用来确定客户需要什么软件，帮助分析人员理解问题，评估可行性，协商合理的解决方案，无歧义地规约方案，确认规约以及将规约转换到可运行的系统时的管理要求； 在面向对象的分析中，需求典型地关注系统能够或将要执行的功能；需求还将标识系统中必须包含的对象，以及这些对象将随时间而呈现的各种状态。 整个系统分析的过程可分为三部分： 确定需求； 组织需求； 选择最佳的设计策略方案。 确定需求 在需求确定期间，分析员从尽可能多的来源收集关于这个系统应该如何运转的信息，这些信息可以呈现出很多形式：访谈记录，观察和文档的分析笔记，多种表单、报表、作业描述和其他文档，计算机生成的输出，例如原型系统等。 包括需求获取、分析和协商等过程 确定需求 软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，具体内容如下： 功能需求 性能需求 用户或人的因素 环境需求 界面需求 文档需求 数据需求 资源使用需求 安全保密需求 可靠性需求 软件成本消耗与开发进度需求 其他非功能性需求 确定需求 如何确定需求 传统的方法：与个人面谈，观察工作人员，收集 分析业务文档和程序等； 现代的方法：联合应用程序设计（JAD）,原型法，敏捷法 确定需求 原型法 确定需求 敏捷法 以使用为中心的设计 极限编程 组织需求 通过用例建模和类建模等方法进行需求的组织。主要包括： 用例图 概念类图 活动图 状态图等 什么是用例 用例建模主要用来分析一个系统的功能需求。因此用例建模的目的是捕获功能需求。 用例是对系统行为的描述，它由在特定环境下与特定目标相关的系统与用户之间的一组可能的交互序列组成，描述一个系统在响应来自主要参与者的请求时它在各种情况下的行为。 用例图 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。 用例图 用例图主要功能 用例图是使用统一建模语言设计新系统的起点，在初始阶段完成。 用例图提供了系统的一个概览，为系统提供给用户的功能进行说明。 从形式上讲，用例记录用户使用系统时从头到尾的一系列事件。 是用户和开发者一起深入剖析系统功能的起点。 在开发项目的初期，用例图可以描述现实世界中的活动和动机。同时可以在项目后期改进用例图以反映用户界面和设计细节。 用例图 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 用例图 范例 设计一个自动饮料售货机。功能分析如下： 1 卖给用户饮料 2 供应商向机器添加饮料 3 收银员从机器收钱 参与者 系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 在图形上，参与者用人形图符表示。 参与者 参与者的种类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程 参与者 如何确定参与者： 谁使用系统的主要功能 谁需要系统支持他们的主要工作 谁来维护、管理系统使其能正常工作 系统需要控制哪些硬件 系统需要与哪些系统交互 对系统产生的结果感兴趣的是哪些人或哪些事物 参与者 注意事项： 参与者对于系统而言总是外部的； 参与者直接通系统交互； 参与者表示人或事物与系统交互时所扮演的角色； 一个人或事物在与系统交互时可以同时或不同时扮演多个角色； 每个参与者需要有一个具有业务一样的名字； 每个参与者必须有简短的描述，从业务角度描述参与者是什么。 参与者 参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 参与者 参与者间的泛化关系示例： 用例 外部可见的系统功能单元。 在不揭示系统内部构造的前提下定义连贯的行为。 不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。 图形上用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。 用例 用例的名称： 简单名 路径名 用例 识别用例 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 如何识别用例。 参与者要求系统提供哪些功能 参与者需要读、产生、删除、修改或存储系统中的信息有哪些类型 必须提醒参与者的系统事件有哪些 参与者必须提醒系统事件有哪些 用例 范例1 用例与事件流 用例分析是处于系统的需求