软件工程4-4.基于UML的需求分析方法.ppt

第四部分 软件工程的需求过程 软件工程 传统的需求分析方法-1 面向对象的需求分析方法-2 基于UML的需求分析方法-3 需求工程与需求管理实现-4 第四部分 软件工程的需求过程 第三章 基于UML的需求分析方法 UML概述-3.1 需求获取与用例建模-3.2 类与对象建模-3.3 动态建模-3.4 物理体系结构建模-3.5 第四部分 软件工程的需求过程 3.1 UML概述 UML统一OO方法大战的努力 n1960年 - 70年代 COBOL, FORTRAN, C 结构化分析和设计技术 n1980年 - 1990年前 Smalltalk, Ada, C+, Visual Basic 早期面向对象生成（代码）方法 n1990年中晚期 Java Unified Process UML概要 nUML是一种语言： 可视化 详细描述的 构造性的 文档化的 nUML的价值 是一个开发的标准 支持完整的软件开发生命周期模型 支持不同的应用领域 是基于经验的和用户群体需要的 被许多工具支持 什么是UML? nUnified Modeling Language（统一建模语言） 是国际对象管理组织OMG制定的一个通用的、 可视化建模语言标准 n用于描述（specify）、可视化（visualize）、 构造（construct）和记载（document）软件密 集型系统的各种工件 nUML提供了一系列建模元素、概念、关系以及规 则，应用于软件开发活动 n详细内容，请学习统一软件开发过程（The Unified Software Development Process）（美）Ivar Jacobson、Grady Booch、James Rumbaugh著，周伯生 、冯学民、樊东平译（机械工业出版社） UML概念 nUML Unified Modeling Language. 组合了当前最好的面向对象软件建模方法 UML三位主要贡献者 n1. OMT方法（对象、动态、功能模型，James Rumbaugh） n2. The Booch method （5个步骤，Grady Booch ） n3. OOSE （User Case图，Ivar Jacobson） James Rumbaugh Grady BoochIvar Jacobson UML概念 n1994年，Booch和Rumbaugh在Rational开始了 UML的工作，但是的目标是创建一个“统一方法” n他们把Booch93和OMT2统一起来，与95年发布 了UM0.8（Unified Method） n1995年OOSE的创始人Jacobson加入到这个联 盟中，开始把工作重点放到创建一种标准建模 语言，UML Unified Modeling Language。 n他们以Booch方法、OMT方法、OOSE方法为 基础，吸收了其他流派的长处，于96年6月、10 月、97年1月、11月分别推出了UML0.9、0.91 、1.0和1.1 创建UML Booch 方法OMT Unified Method 0.8OOPSLA 95 OOSE其他方法 UML 0.9 Web - June 96 公共 反馈 最后提交给 OMG, Sep 97 第一次提交给OMG, Jan 97 UML 1.1 OMG 认可, Nov 1997 UML 1.3 UML 1.0UML 团体 UML 2.0 UML概念 nMethod 方法告诉使用者做什么、怎么做、什么时候做、为什 么做（特定活动的目的），方法包括模型 nModeling 模型用来描述使用某种方法的结果，例如，通过不同 角度的简化视图，描述对象系统的设计与实现结果， 模型用建模语言来表达 nLanguage 建模语言由记号（模型使用的符号）和一组规则（语 法、语义等）组成 UML概念 nUML是一种语言 遵循特定的规则 允许创建各种模型 并不告诉设计者需要创建哪些模型 并不提供开发过程 nUML是可视化语言 UML是图形化语言 图形便于交流（一幅图抵上千文字） nUML是用于构造系统或理解系统的语言 UML既支持正向工程，又支持反向工程 nUML是文档化语言 将所建造的系统记录下来 便于新程序员跟进 开发产品新版本时很有用处 UML的概念 n模型元素 n关系 n扩展的机制 n图表 UML构成： 模型元素 关系 扩展的机制 图表 模型元素 关系 图表 模型元素 n结构元素 类，接口，协作 用例，主动类，构 件 节点 n行为元素 交互, 状态机 n组元素 包, 子系统 n其它元素 注解 类、对象与接口 n一个系统往往可以从不同的角度进行观察，一 个角度构成了一个视图 nUML有九种图表，构成5种视图： 1、用例图（use case diagram） 2、类图（class diagram） 3、对象图（object diagram） 4、状态图（state diagram） 5、时序图（sequence diagram） 6、协作图（collaboration diagram) 7、活动图（activity diagram） 8、构件图（component diagram） 9、部署图（deployment diagram） UML的图表与视图 静态逻辑视图 动态逻辑视图 3-并发视图 1-用例视图 5-部署视图 2-逻辑视图 4-构件视图 模型,视图,和图表 Use Case Diagrams Use Case Diagrams 用例图 Scenario Diagrams Scenario Diagrams 协作图 State Diagrams State Diagrams 组件图 Component Diagrams Component Diagrams 分布图 State Diagrams State Diagrams 对象图 Scenario Diagrams Scenario Diagrams 状态图 Use Case Diagrams Use Case Diagrams 时序图 State Diagrams State Diagrams 类图 活动图 模型是对一个系统 从详细观察的角度 的描述 模型 图表 n图表是模型的视图 表现给投资者看得详细的描述; 提供了系统的局部详细描述； 和别的视图保持语义一致； n在UML中,有九种标准图表 静态视图: 用例图, 类图,对象图,组件图 , 分布 图 动态视图: 时序图,协作图,状态图,活动图 用例图 n捕获用户能够看到的系统 通过对”场景”的描述，定义系统的功能和性能 ，并获得用户和开发团队的共同认可 提供清楚和无二义的用户与系统的交互描述 用例图 n在开发过程的早期创建 n目的： 详细说明系统的表达含义； 捕获系统的需求； 验证系统的体系结构； 驱动实现和生成测试用例。 n由分析人员和领域专家开发 Use Case图 nUse Case图形描述了一个系统应该执行的什么或应该有 什么外部系统 它描述了存在的actors（外部系统）、use case（该 系统应该执行什么）以及它们的关系 n在Use Case视图中可以包含以下的图形 Use Case图：包括：包、actors、use case和关系 相互作用图（序列图或协同图）：包括：对象和消息 n符号表示： 系统名称 系统 用例名 用例角色关联 Use Case图例 保险商务系统 签定保险 单 销售统计 客户统计 客户 保险销售员 Use Case图例 UML用例图示例 类图 n捕获系统的词汇表 n在开发过程中被创建和精确化 n目的 系统中的名字和模型概念 详细描述协作关系 详细描述逻辑数据库表 n由分析人员、设计人员和代码实现人员开发 类图Class Diagram 类图描绘系统的静态视图 它描述了系统逻辑设计中存在的包、类以及它们之间的关系 类图可以代表该系统中部分或全部的类结构 学生 姓名:string 学号:string 书 书名:string 价格:real 1购买 0* 属于 对象图 n捕获实例 和连接 对象图 n捕获实例和连接 n在分析和设计阶段创建 n目的 举例说明数据/对象结构 详细描述瞬态图 n由分析人员、设计人员和代码实现人员开 发 对象图Object Diagram 王平：学生 姓名:王平 学号:020106 英语：书 书名:英语 价格:26.5 数学：书 书名:数学 价格:21.8 对象间关系 n关联关系 (Association) n聚集关系(Aggregation) n泛化关系(Generalization) n依赖关系(Dependency) n细化关系 (Refinement) 构件图 n捕获实现的物理结构 构件图 n捕获实现的物理结构 n作为体系结构规范的一部分实现 n目的 组织源代码 构造一个可执行的发布版本 指定物理数据库 n由集成人员和程序人员创建 分布图 n捕获系统硬件的拓扑结构 分布图 n捕获系统硬件的拓扑结构 n作为系统结构规范的一部分被创建 n目的 描述组件的分布 标识系统性能瓶颈 n由集成人员、网络工程师和系统工程师开 发 交互图 n交互图描述了系统在逻辑设计中存在的对象及 其间的关系 它可以代表系统中对象的结构 nUML中包含两种交互图，它们对同一交互操作 提供了不同的浏览视角 时序图（顺序图） n按时间顺序排列对象交互操作 协作图 n围绕对象及其间的链接关系组织对象的交互操作 交互图 n顺序图和协作图均被称为交互图（interaction diagram ）。由一组对象、对象间的关系、对象间发送的消息组 成一种动态视图，可以单独使用、也可以对用例中的特 定控制流程建模。 n顺序图和协作图同构的：两种图之间可以相互转换，而 没有任何信息损失。 n二者区别点在于：顺序图（sequence diagram）关注消 息的时间顺序，有对象生命线、有控制焦点；协作图（ collaboration diagram，在UML2.0中协作图被称为 communication diagram，二者指的是同一类型的图） 关注收发消息的对象的组织结构，有路径、有顺序号。 时序图 n捕获系统的动态行为(面向时间的) 时序图 n捕获系统的动态行为(面向时间的) n目的 模型流程的控制 举例说明典型的脚本 打印机就绪 打印文件 时序图（Sequence Diagram） 打印机忙 保存文件 打印文件 打印文件计算机打印服务器打印队列计算机 UML顺序图示例（某客户Joe取20美元的顺序图） 协作图 n捕获系统的动态行为 (面向消息的) 协作图 n捕获系统的动态行为 (面向消息的) n目的 模型流程控制 举例说明对象结构和控制的协调 协作图（Collaboration Diagram） 打印机忙 保存文件 打印机就绪 打印文件 打印文件 计算机打印队列 打印服务器打印机 UML协作图示例（ATM系统中“客户插入卡”的协作图） 状态图 n捕获系统动态行为(面向事件的) 状态图 n捕获系统动态行为(面向事件的) n目的 对象生命周期模型对象生命周期模型 为起反作用的对象为起反作用的对象( (用户接口、设备等）建模用户接口、设备等）建模 状态图State Diagram 状态图描述了： 给定类的状态转换空间 导致状态转换的事件 导致状态改变的动作 为类的重要动态行为建立状态转换图 超时 到达 上楼 上楼到达 上楼 到达 在底楼向上移动 向底楼移动 向下移动空闲 状态图State Diagram UML状态图示例 电视机 世界上的万事万物在任何特 定时刻总处于某一特定状态 。一个电梯可以处于上升、 下降、停止状态。一辆汽车 可以处于前行、后退、停止 状态。一台电视机可以处于 开机、播放、待机或关机状 态。 活动图 n捕获动态行为（面向活动的） 活动图 n捕获动态行为（面向活动的 n目的 给商业工作流建模 给操作建模 活动图Activity Diagram Disk free Disk full 显示磁盘满 显示在打印 删去显示信息 建立打印文件 Win.printAll() printer.print() 活动图的符号集与状 态图中使用的符号集 类似。像状态图一样 ，活动图也从一个连 接到初始活动的实心 圆开始。活动是通过 一个圆角矩形（活动 的名称包含在其内） 来表示的。活动可以 通过转换线段连接到 其他活动，或者连接 到判断点，这些判断 点连接到由判断点的 条件所保护的不同活 动。结束过程的活动 连接到一个终止点（ 就像在状态图中一样 ）。作为一种选择， 活动可以分组为泳道 （swimlane），泳道 用于表示实际执行活 动的对象 UML活动图示例（ATM系统中“客户插入卡”的活动图） 体系结构和UML 组织： 包, 子系统 动态 交互 状态机 设计视图实现视图 过程视图 组件 类, 接口, 协作 活动类 分布视图 节点 用例图 用例 UML静态图 n用例图（Use Case Diagram） n类图(Class Diagram) n对象图(Object Diagram) n构件图(Component Diagram) n部署图(Deployment Diagram) UML动态图 n状态图（State Diagram） n时序图（Sequence Diagram） n协作图（Collaboration Diagram） n活动图（Activity Diagram） UML建模方法与视图 n用例建模 用例图 n类和对象（结构）建模： 类图 对象图 n行为（动态）建模 用例图 交互图（顺序图、协作图） 活动图 状态图 n物理体系结构建模 构件图 实施图 UML过程 nUML过程主要包括： 用例驱动（use-case-driven） 以体系结构为中心（architecture-centric） 反复（iterative） 渐增式开发（incremental） UML过程 n1、用例驱动： 用用例方法获取系统的功能需求，并以此驱动需求分析之后的 所以阶段的开发 在需求阶段，用例所包括的系统功能，需要用户的确认 在设计和实现阶段，用例被实现 在测试阶段，用例用于验证系统功能 需求 用例 分析设计实现测试 用例视图 并发视图 部署视图 构件视图逻辑视图 用例影响开发的所有阶段 用例视图影响其他视图 UML过程 n2、以体系结构为中心 项目开发的早期，除了需求以外，另一个最主要的工 作就是确定系统的体系结构 体系结构定义了系统的各部分、各部分的关系和交互 、通信机制、如何增加和修改体系结构的规则 体系结构决定了系统的功能和非功能部分 n非功能部分包括：性能、易理解性、易修改性、复用度 在UML中，通过定义可以层次化的“包”，来实现把一 个大系统划分成不同的小系统 确定体系结构的基本方法是：分析、选择、原型化、 评估和精细 UML过程 n3、反复迭代 用UML方法建模，可以反复多次，不需要一次完成 通过反复，增加新信息、细化新的细节 每次反复，应进行评估，评估的内容还应包括：代价 、风险 n4、渐增式 多次迭代，每次迭代增加新的用例和功能 每次迭代，都是分析、设计、实现和测试的过程 迭代的最大好处是分解了风险，不至于把失败的风险 留到开发的最后才发现 3.2 需求获取与用例分析 需求开发过程的阶段任务 需求开发过发过 程的重要里程碑 需求获取需求分析 需求处理 需求验证 问题 定义 阶段 需求分析阶段 面向用户确认的 需求描述 面向实现的需求 规格说明 用户确认需求评审 面向实现的细化 面向管理的规范 面向成果的验证 基于UML的需求获取 1、需求获取与业务建模 n对于一个复杂的业务系统，我们可能涉及：公司 组织、业务单位、部门和人员岗位、职责和功能 、内部和外边网络、客户、业务信息流、行政和 财务流等等 n为这个组织建立计算机系统，我们要回答： 为什么要建立这个系统 这个系统的定位在何处 我们如何确定哪些功能是最适宜放在系统的特定节点 上 我们何时采用计算机处理而何时采用人工处理 为适应计算机处理，我们需要改变现有工作流程吗 n回答这些问题的技术，就是业务建模 n业务建模的目的： 建模过程是开发者和用户之间为导出需求规约而进行的 交互过程 因此： 理解现有业务组织的静态结构和动态运作方式 确保客户、最终用户以及开发人员对业务组织有共同的理解 系统的边界在那里？功能是什么？ 理解如何部署新的系统以提高生产力，以及现有的哪一个系统会 受到新系统的影响 n系统的功能由用例来表示： 用例用来： 确定和描述系统的功能要求 给出清晰和一致的系统做什么的描述 为验证系统所需的系统测试提供基准 提供从功能需求到系统实际类和操作的跟踪能力 图例 说明 业务处理 单位 业务处理 描述 表格制作 传递 存储 收集资料 储户 存折 存取款单 存折 现金 存折 业务分类 存款单折 取款单折 存款处理 取款处理 利息文件帐目文件 存取款业务存取款业务 传统方法：业务流程图存取款业务处理过 程 在UML中的建模结构就是业务用例模型和业务对象 模型 n领域模型将系统语境中的重要概念描述为领域对 象，并建立这些领域对象之间的关系 n业务模型是领域模型的超集，包括： a.业务用例模型：说明系统所支持的业务过程 b.业务对象模型：领域模型和业务用例实现 n业务用例模型是业务系统预期功能的描述模型， 是系统开发任务和作为产品提交时的最根本的系 统工作描述 n业务对象模型描述了实体和相互交互完成业务用 例所需要的功能，是业务用例的实现 n下面，我们用示例介绍 利用UML概念进行业务建模 业务过程与业务用例 n一个业务过程是根据组织目标而采用组织资源 来获得预定义结果的一组逻辑相关的活动 n用一个业务用例代表一个业务过程 n业务用例包括： 角色（与业务活动交互的人或系统） 用例（角色与业务元素交互完成工作的事件序列） n建立业务用例的过程： 确定行为者 确定用例 确定行为者 n行为者： 与系统交互的人或其他系统 交互：发送、接收、交换信息 行为者执行用例 行为者是一个角色，而不是具体个人 n寻找行为者 谁使用系统的功能 谁需要系统提供信息 谁维护、管理、控制系统 系统完成功能还需要得到其他系统的支持 还有哪些人对系统的结果感兴趣 业务用例 银行 确定用例 l一个用例是被行为者感受到的一个完整的功能 UML的定义：用例是给一个特定行为者的一个可观察的结果值的系统 所完成的一系列动作 这个动作除计算机内部完成的计算外，还包括与行为者的信息交互 用例通过关联与行为者进行交互 用例总是被行为者所启动，并回答一个可识别的结果 类似于对象是类的实例，用例的实例是场景（scenario）。 例如：“用户在ATM机上执行取款操作”用例的场景是：“张三在ATM机 上取出300元人民币” 寻找用例 行为者需求系统提供哪些功能？ 行为者是否需要创建、读、写、修改、删除系统中的信息？ 行为者是否需要被系统提醒、启动系统的某个功能？ 系统能否帮助行为者做一些事情，来提高行为者的效率、便利 寻找用例 考虑人和饮料贩卖机的交互，包括购买饮料，首 先，放置货物（饮料）等，下面考虑购买饮料。 l 用例描述了系统的行为，包括行为者 和系统之间的交互以及系统与系统之间 的交互。 n 用例是系统提供的功能块。演示了 人们如何使用系统。它来自于客户需求 的分析。这个过程称为Use Case分析, 是整个系统开发中非常关键的过程。 我们设计一个饮料贩卖机，从用户的角度来考察它的功能： 问:“自动饮料贩卖机将为您做什么?” 答:“我通过自动饮料贩卖机购买一听饮料.” 饮料贩卖机的主要功能是使得用户可以购买饮料， 我们为这种机器标记一个叫 “买饮料”的use case. UML中的 Use Case 表示 Buy Soda Use CaseActor Communication Customer nuse case记录用户使用系统是从头到 尾的一系列事件。用户普遍称为“活动 者”，它可以是人或另一个系统。 n每一个 use case 包括 “活动者”和 一个表示 use case 的椭圆。 Use Case 活动者 活动者可以是人或另一个系统，它与 当前的系统交互，向系统提供输入或 从系统中获得输出。 Actor NameTelephone System (电话系统） 使用电话卡 对方付款 Phone User (电话用户） 活动者的标志 n谁对某一需求感兴趣？ n组织中哪一部分使用系统? n谁从系统的使用中受益? n谁向系统提供信息？ n谁将维护系统？ n系统使用外部资源吗? n系统和已经存在的系统交互吗? 活动者的类型 n实际的人，即用户，是最常用的角色， 几乎每个系统都有。命名这些角色的时 候，要按作用来命名，而不是按照位置 命名。 n另外一个系统。例如航空订票系统可能 需要与外部应用程序接口，验证信用卡 以便购买。 n可能隐蔽的角色：时间。例如商业促销 项目推出免费奖，每天下午三点，系统 自动选择向随机客户提供免费奖品。 在饮料自动贩卖机中，除了买饮料的顾客， 还有以下的活动者。 Buy Soda Restock Soda Collect Money Customer Supplier Collector 每一 种活 动者 具有 自己 的 use case 饮料贩卖机中的活动者 供应商向自动贩卖机添加饮料。 收银员从自动贩卖机收钱。 理解用例 n用例独立于实现。用例关注的是作用而不是 如何实现这个作用。 n用例是系统的高级视图。用例的集合应让客 户易于了解高层的整个系统。 n最后，用例关注系统外的用户。每个用例应 表示用户与系统间的完整事务，为用户提供 一定价值。用例应按业务术语命名，而不是 按技术术语命名，应让客户一目了然。 n例如：用例不要命名为“客户与银行ATM的交互界面 ”，如果客户要买票, 用例可以称为“客户购票”。 n用例分析有助于: 捕捉需求 计划开发过程的循环往复。 验证系统。 n需求分析从用例分析开始，它驱动整个开 发过程。 n在用例中描述了所有的功能需求。 标记用例 n活动者希望这个系统执行什么任务。 n活动者在系统中访问哪些信息 (创建, 存储, 修 修改, 删除等)? n外部的哪个变化将要被告知系统？ n系统的那个事件将要被告知活动者？ n系统将要怎样维护? 标记用例 用例的完整性 n每个功能需求是否至少在一个用例中?如果需 求不在用例中,则不会实现。 n是否考虑了每个操作者如何使用系统。 n每个操作员向系统提供了什么信息。 n每个操作员从系统接收了什么信息。 n是否考虑了维护问题，要有人启动和关闭系 统。是否标示了系统要交互的所有外部系统 。 n每个外部系统从系统接收什么信息和系统发 送什么信息? 用例视图 一个 use case 视图包括 一个use case 集合，定义整个 系统的功能 。 Buy Soda Restock Soda Collect Money Customer Supplier Collector Soda Machine Use Case 视图 系统 边界 用例的范围 2、从业务模型到系统模型 例：建立用例的系统模型 pATM取款机作为一个业务系统 p来取款的客户是一个角色 p用例是业务模型中业务的活动 p系统模型描述了业务中系统的工作（内部活动） p角色是外部，用例是内部。取款的客户是角色，取款是用例。 p用例模型开始定义角色之间的关系（关联关系、包括关系、扩 展关系、一般化关系等）。 p用例模型描述事件流，包括主事件流、其他事件流、前提条件 、事后条件等等。 p这样，我们就建立了一张描述“活动”的Use Case图，通过这张图 ，我们就能够比较具体地描述“活动”，即让用户看到： p谁与系统交互，有助于发现缺少的参与者 p知道系统的范围，有助于发现缺少的功能 业务用例描述：柜台取款 业务用例活动图 ： 柜台取款 注意： 这里只有角色（ 客户）和用例（ 系统） 对于系统内部的 实现，我们还没 有更多的涉及 从业务模型到系统模型 - ATM 系统用例 ATM 系统用例 - ATM取款 用例时序图 - ATM取款 系统开始区分ATM系 统和银行主机系统 用例的层次 n概要目标用例： 需要多个用户目标会话来完成（日、周、月、 年） n用户目标用例： 满足特定、迫切、有价值的用例目标（分钟、 小时） n子功能用例： 为了完成用户的真实目标而提供的功能 用户目标层 n“Can the actor go away happy after having done this?” n通常1个人，1次性完成，2-20分钟 概要目标层 n使用ATM用例：银行自动柜员机 n含有多个用户目标，可包含：存取款、查 询、修改密码、打印凭单、提供跨地域、 跨银行服务 n作用 说明用户目标执行的背景 说明相关目标的范围 提供了下层用例的目录 用户目标层次 用例分析流程 定义系统范围和边界 列出角色及其作用 提取概要用例并调整得当 着重对系统的用户目标层用例进行细化 填写干系人责权利、前置后置条件 编写基本流 列出所有扩展条件，编写扩展处理步骤 用活动图、状态图、交互图等描述重点用例 9. 分解、合并用例，调整用例关系模型（用例图 ） 需求获取关键是获得用户的确认 建立业务模型的工作主要包括： 分析领域中的业务角色 分析角色间的业务功能等关系 分析业务组织架构 分析业务规则 分析业务实体 分析业务事件 分析以业务角色为主角的业务用例等； 以业务用例为实例，与用户进行沟通： 需求是否被清楚地陈述？ 存在错误的理解吗？ 需求的来源（人员、规章制度、文件）是否正确？ 需求的最终陈述是否得到用户最终责任人确认？ 问题 用户不知道他们需求什么或不 知道如何表达 直到开发人员把用户所描述的 东西给他们，用户才认为知道 自己要什么 分析人员认为自己比用户更了 解用户的需求 解决方案 将用户当作领域专家来认识和感激， 尝试一下其他沟通和启发技术 尽早提供相互选择的启发技术：情节 串联板、原型、角色换位等 把分析人员放在用户的位置，试着换 位一小时或一天 解决用户和开发人员综合症 用户讲故事 介绍游戏规则 输出结果 幻灯片放映 动画制作 仿真演示 交互演示 现场演示 被动式介绍主动式介绍交互式介绍 需求诱导的方法（情节串联板） 原型开发 复杂程度与 成本 需求获取过程需求管理的关注点 步骤： 1、发现和分析问题 2、理解用户的需求 3、定义系统（用例模型） 4、管理范围（项目管理） 方法： 采用业务建模和系统建模的方法进行问题分析 对与系统架构和系统行为有关的用例进行描述和定义 目标： p在问题定义上与用户达成共识 p理解问题背后的根本原因 p确定用户和项目干系人 p定义问题解空间的边界 p确定问题解决方案的约束和假设 最终阶段完成标志：用户对系统目标的认可签字 需求获取过程产品基线管理的关注点 产品前景文件 技术创新和突破产品特点 客户：涉众和用例 分析人员和专家 的意见 与公司其他产品 的配套和一致性 与对手的竞争性 产品差异和优势 开发团队的状况与 产品的可持续性 系统平台与兼容性公司目标与市场 需求 一个真 正伟大 的产品 需求获取过程产品路线管理的关注点 V1.0V2.0V2.1V3.0V3.1 新系统 版本特性 基本 功能 安保 接口 客户 定义 远程 维护 多平台 支持 中央控 制单元 户主 客户 控制 开关 05/0105/0705/0906/0106/03 图例：正在发行发布代码行代码行修改 需求提取的最佳实践 明确构想和范围 确立需求开发过 程 用户群分类 选定产品代表 建立用户核心队 伍 建立用例模型 举办用例演示会 分析业务流程 明确质量属性 检查问题报告 重用需求 用例常见错误 无系统目标或边界 无角色定位 用户界面细节过多 目标层次太低 目的与内容不一致 含有设计内容 过多的数据细节 “ 用例分析是当今消除需求不明确、不一致、不完整 的重要手段和关键技术 ” 用例在需求获取阶段的好处： 与传统的需求分析方法相比，用例书写简单、易于理解 用例迫使开发人员从系统设计时，就从用户的角度考虑问 题 用例使用户参与需求过程，帮助他们理解所建设的系统， 并提供了一种交流和记录的工具 用例给出了需求的情景，从而使人们理解需求的原因以及 系统是如何实现它的目标 大多数情况下，用例是开发人员写的，因此，他是理解这 个需求，也知道最终要对实现这个需求负责的 用例在系统开发的其他阶段的好处： 用例在分析阶段，也是一个关键的工具，它帮助我们理解 系统需求做什么以及系统可能如何去做 用例在设计和实现过程中，也是一个关键的工具，它降低 了因需求表达不确切和不一致，导致系统开发错误的风险 用例可以直接延伸到测试过程，这有利于确保系统真正做 了它应该做的事情 用例也是用户文档的输入，可以从用例开始，很方便地组 织用户文档的编写 用例在组织软件开发中的核心作用 用例驱动模型 到目前为止，我们完成了需求获取阶段的任务 通过采用用例的方法，建立了业务模型，使用户理解并确认系 统要做什么和不做什么 3、从业务用例到测试用例 V模型中的过程从 左到右，描述了基本 的开发过程和测试行 为。V模型的价值在 于它非常明确地标明 了测试过程中存在的 不同级别，并且清楚 地描述了这些测试阶 段和开发过程期间各 阶段的对应关系。 测试与开发阶段的对应V模式 验收测试 n在行业应用软件环境中，验收测试是项目过程非常重 要的一环，也是项目经理非常关注的一项工作。 n验收测试与确认测试非常相似，所不同的是，确认测 试是项目组或组织内部的测试，验收测试是用户主导 、现场参与、现场环境下的测试。 n验收测试通常由项目组先提出测试大纲，定义测试目 的、范围、方法、测试用例、预期结果、验收标准等 。经用户同意批准，可能包括用户的修改、增加后， 确定测试时间，开始进入验收测试。 n用户在完成按测试用例的测试后，在测试记录上逐条 确认、签字，最后，在测试报告上签字，完成验收测 试。 n一般地、验收测试报告是项目初验、终验的依据和主 要验收形式。 系统验收与用例的关系 验收测试的用例，在需求获取完成后产生 测试用例的依据是需求获取的业务用例。 （1）从业务用例到实现用例 （2）从业务用例到测试用例 用例编编 号 描述灯的 状态态 预预期结结果 开关1 基本流：住户户按下按扭的 时间时间 小于1秒 开关并记忆记忆 亮度 2 基本流：住户户按下按扭的 时间时间 小于1秒 关按记忆记忆 亮度开 3 其他流：住户户按下按扭的 时间时间 大于1秒 开亮度按10%/秒速度上升达 到最大后下降并循环环 4 其他流：住户户按下按扭的 时间时间 大于1秒 关先开，然后再同上循环环 5 其他流：住户户按下按扭的 时间时间 大于1秒后松开了开关 开停在当时时的亮度位置 6 其他流：住户户按下按扭的 时间时间 大于1秒后松开了开关 关停在当时时的亮度位置 根据用例的事件流分析，针对用例情景，产生验收测试用例。 从用例到测试用例 测试用例名 称 工号权限被测子系统名卡/号资源管理 测试用例来源 公司测试组 内部测试抽查参考文档 序号测试用例描述 XWYY001 测试目的能否正确识别合法的操作员进入应用系统 测试步骤1.启动“卡/号资源管理”应用程序。2. 输入系统中不存在的 工号1000，再输入密码12345，检查能否进入系统。3.输入系 统中存在的工号nj001和正确的密码，检查能否进入系统。4. 输入系统中存在的工号yd002和正确的密码，检查能否进入系 统。 输入数据描 述 1、工号1000根本不是系统合法的工号。2、工号nj001是前台 营业受理的工号，不能进行卡号资源管理系统。3、工号yd002 是卡号资源管理系统的工号。 期望的结果1. 工号1000无论如何进入不了系统，系统提示无此员工 2. 工号nj001也不能进入系统，系统提示该操作员无权执行卡 号资源管理系统 3工号yd002可以进入系统，并能打开所有的功能菜单 测试结果描 述 相符 测试人员 测试日期2003-03-08 复测人员 复测日期 备注 3.3 需求分析与类和对象建模 从现在开始，我们完成了“需求获取”阶段的任务，进入 “需求分析”阶段 p需求获取阶段完成的标志，是获得用户签字确认的 需求描述 p需求分析阶段任务完成的标志，是在经过需求分析 、需求处理后，通过“需求评审” 从现在开始，我们要用面向“实现”的眼光，来看待需求 p什么是面向实现？ p需求分析阶段的“面向实现”，是面向可交付成果 p什么是面向成果？我们先看一下需求评审的要求 需求开发过程的阶段任务 需求开发过发过 程的重要里程碑 需求获取需求分析 需求处理 需求验证 问题 定义 阶段 需求分析阶段 面向用户确认的 需求描述 面向实现的需求 规格说明 用户确认需求评审 面向实现的细化 面向管理的规范 面向成果的验证 基于UML的需求分析 传统的需求分析阶段 需求分析阶段的任务和步骤 n复查系统规模和目标 n研究现有系统功能 n导出新系统模型 n重新定义问题 n导出和分析各种可选解决方案 n推荐行动方针 n草拟开发计划 n书写文档提交审查 阶段成果交付物： 需求定义文档（需求规格说明） 循环 需求分析需求获取与需求分析的区别 需求获取是面向用户、在较高的抽象级别上对系 统特性的定义 l可以更多地关注系统的特性以及如何体现用户的需求， 以便更好地理解系统的形状和形式 l可以对系统的完整性、一致性以及对环境的适应性进行 评估 l在继续大量投入之前，可以利用这些信息决定可行性和 管理系统的范围 l可以脱离对具体需求进行取舍和决策所带来的风险 l需求获取的目标是用户的认可，因此，阶段的验收标志 是用户签字确认的需求描述 需求分析需求获取与需求分析的区别 需求分析是面向系统实现、严格对系统需求的定义 l定义系统的输入、输出、功能、属性以及系统 环境的属性，决定系统的完整集合 l面向系统技术实现，讨论系统应该做什么，因 此，应避免受项目进度、计划、预算、设计、 测试等的影响 l需求和设计是迭代进行的，但需求将引导设计 ，也受设计方法的制约 l需求分析的验收标志是组织的需求评审 需求分析细化系统定义 在需求获取阶段，我们已经通过建立业务模型、系统模型 ，与用户共同确定了系统的特性： 业务用例模型，可以映射出软件产品核心的需求，包括与业务功 能对应的组织的特性，与业务流程对应的内外部关系特性等； 系统用例模型，是在已经建立的业务模型的基础上，建立系统的 模型。 用例业务模型和系统模型的最典型表示形式 p软件产品本身可能还存在与业务无直接关系的另类需求（一般与硬件 、软件环境相关），比如支持多种操作系统、对软件运行的远端监控要 求、异常处理（如通讯连接中断等非业务异常）等等。 p另一方面，设计约束和限制，也是系统需求必须要考虑的内容 通常这三部分需求构成软件需求的总集。 需求分析细化系统定义 在需求分析阶段，我们不可避免地要 涉及到进行设计决策 设计决策： p硬件环境（运行在PC服务器上 ？还是小型机？） p平台的选择（只支持Windows 平台，是否也支持UNIX平台？） p工具的限制（采用VB实现？） p方法的约束（用XYZ类库实现 数据库访问？） 当前需求使我们 考虑采用某种设 计选项 被选择的设计选 项可能影响需求 需求分析是在需求获取、需求分析和设计决策之间反复 迭代循环的过程 需求分析细化系统定义 软件需求是具体的： 面向系统设计、编码 面向测试 因此，在需求获取的基础上，进一步细化系统需求、明确 和细化系统定义，这就是需求分析阶段的任务 在传统软件过程方法中，这二个阶段不是非常清晰和明确 系统需求 功能性需求非功能性需求设计约束 需求分析细化用例 在需求获取过程中，我们建立了业务模型和系统模型，引入 了角色和用例的概念 角色与用例的区别： 系统的角色是业务之外与业务交互的人或事 例如：ATM取款机作为一个业务系统，来取款的客户就是一个角色 用例是业务模型中，业务的活动 在系统模型中，描述了业务中系统的工作（内部活动）。角色是外 部，用例是内部。取款的客户是角色，取款是用例。 用例模型开始定义角色之间的关系（关联关系：包括关系、扩展关系、 一般化关系等）。用例模型描述事件流，包括主事件流、其他事件流、 前提条件、事后条件等等。 需求分析细化用例 细化用例的主要步骤： l审查主角 l细化描述 l定义和细化事件流程 l确定前置条件和后置条件 l确定特殊需求 l扩展用例 需求分析细化用例关系 为需求处理做准备 在定义系统的用例规约之前，确定一份基本的术语词汇表，以 统一项目开发中的用词。 确定系统的用例，通常从寻找系统的主角开始。如果做了业务 建模，则可以先从业务对象模型中的业务工人（Business Worker）着手。 系统主要的主角确定后，可以根据为系统主角提供有价值的结 果（Result of Value）这一准则（用例是为主角的活动最终提 供一个有价值的结果的活动过程）来确定系统的用例。 理清系统用例之间存在的密切关系，具有的内在结构，如泛化 关系、包含关系、扩展关系等。 有二种Interaction图，按时间顺序排列的是Sequence图，按对 象关系排列的是Collaboration图。二种图从不同的角度，反映 了案例中特定情形的流程。 需求分析的成果需求评审内容 CMM2对评审内容规定为： （1）确定不完整和遗漏的给定需求； （2）评审给定需求以确定他们是否：可行、适用于软件实 现、说明清楚、适当、彼此一致、可测试。 （3）有负责分析和分配系统需求的小组对确认可能有问题 的给定需求进行评审并进行必要的修改。 （4）相关小组协商由给定需求所得出的约定。 在这里，我们最主要先关注（1）（2）二条 p第一条：需求分析阶段的需求规格说明必须与需求 获取阶段经用户签字确认的用户需求描述一致 p第二条：需求规格说明还应具有一些特定的属性 良好的需求规格说明属性 具有良好的需求规格说明属性的需求文档，具有如下的属性： （1）不含糊性：如果每一个需求只有唯一的一种解释，那它是不含 糊的； （2）完整性：如果需求包括了功能、性能、时间响应要求、限制、 接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差 异的需求，是完整的； （3）可检验性：存在有限的、经济与技术都是可行的检验方法和程 序，对需求的实现与否，进行检验，使得用户和组织通过该检验，确认 需求被按照需求规格说明实现； （4）一致性：需求作为一种要求是一致的，不存在系统内相互冲突 的需求要求； （5）可跟踪性：需求可追踪； （6）可使用性：可为产品的各阶段，特别是维护阶段，提供充分有 用的信息。 所以，我们现在可以理解： 需求分析，就是为了实现系统需求，并使最后交付成果与 需求所要求的目标，不产生：含糊性、不完整性、不可检 验性、不一致性、不可追踪性和不可用性，而进一步对需 求进行描述和定义。 p需求分析继承需求获取阶段的成果 p需求分析面向下阶段系统概要设计 p需求分析采用自己的特定方法，达到相应的阶段要求 p需求获取阶段的目标是让用户签字 p采用的方法是尽量地让用户和开发团队都能理解并认同系统目 标和范围界定的方法业务/系统模型、用例和USE CASE图 p需求分析阶段的目标是用计算机的（而不再是用户）眼光和语 言，分解需求、定义需求。但是，这个眼光不是程序设计员的眼 光，是系统分析师的眼光 p经过下一步需求处理后，达到需求规范要求 p分析的方法是一套“建模”技术 需求分析的成果： 用例驱动的分析 为了进一步描述系统，我们现在需 要建立类和对象模型 p类和对象模型，描述了系统的静 态结构 p有了系统的静态结构，我们才可 以在静态结构的基础上，建立系统 的行为（动态）模型 p在面向对象方法中，我们已经介 绍了如何建立类和对象的模型 pUML的特点是一套统一描述方法 和符号 用例驱动的分析实现 Booch method 的5个步骤 （1）使用“寻找什么”标准来标识类和对象分析类 （2）定义一般/特殊结构、定义整体/部分结构分析包 （3）标识主题（子系统构件的表示）建立子系统 （4）定义属性和实例联系 （5）定义操作和消息联系 静态建模 动态建模 UML的三个来源和三 个组成部分： OMT、5步骤、图形 符号 从业务/系统模型到分析模型 n分析类（逻辑结构） 用例实现：将用例的实现（执行）表示为分 析类（对象）之间的交互 n分析包（物理结构） 以包（分块）的方式组织分析模型的组件 强内聚、弱耦合 完整性、正确性、一致性和易读性 类是信息和行为的包装 对象是类的特定实例 类图由系统中的类和它们之间的关系组成 例如：在C/S结构的系统中，我们把系统的信息放在数据 库一方，行为放在应用程序一方。 面向对象的特点之一就是将信息和影响信息的行为连接在 一起，包装成类。 类图和对象图： （1）类/对象图静态分析 类名 属性名：类型 操作 类 对象名：类名 属性名 = 值 操作 对象 对象图使用与类 图相同的形式 只是在对象名下 加一个下划线 对象名后可接以 冒号和类名 n分析模型由三个独立的模型构成：由用例和场景 表示的功能模型；用类和对象表示的分析对象模 型；由状态图和顺序图表示的动态模型。 n在需求获取阶段得到的用例模型就是功能模型。 据此可导出分析对象模型和动态模型。 n需要注意，这些模型代表的是来自客户的概念， 而非实际软件类或实际构件。如数据库、子系统 、会话管理器、网络等，不应出现在分析模型中 ，因为这些概念仅与实现相关。 n分析中的类可以看作是高层抽象，在后续阶段将 使用更多的细节实现。 n在分析对象模型中有实体对象、边界对象和控制 对象等三种类型。 n实体对象表示系统将跟踪的持久信息；边界对象 表示参与者与系统之间的交互（接口）；控制对 象负责用例的实现 。 n可用UML提供的衍型机制，区分不同类型对象。 ControlControlEntityEntity ActorActorBoundary 参与者 边界对象 控制对象 实体对象 图示 UML对类进行了分类，既所谓：B-C-E模型 UML有三种基本的构造型：边界、实体和控制。 边界类（Boundary Calsses） 边界类位于系统与外界的交接处，包括所有窗体、报 表、打印机和扫描仪等硬件的接口以及与其他系统的接 口。 要寻找和定义边界类，可以检查Use Case框图。每个 角色/使用案