UML和模式应用02-计划和细化阶段-70.pptVIP

第二部分 计划和细化阶段 第二部分 计划和细化阶段 学习案例：销售点终端 理解需求 用况：对过程的描述 用况的分类和时间调度 第4章 学习案例：销售点终端 目标 定义本书所使用的学习案例 第4章 学习案例：销售点终端 销售点终端系统 系统体系结构的层次和学习案例的重点 我们的策略：反复学习和反复开发 销售点终端系统 销售点终端系统(Point-Of-Sale Terminal, POST)：是一个计算机自动化系统，用来记录商品信息和处理客户的支付。使用这种系统的典型代表是超市。它包括计算机、打印机和条形码扫描仪等硬件设备和系统运行软件。 使用迭代式、增量开发策略，将经历需求分析、面向对象的分析、设计和实现阶段。 系统体系结构的层次和学习案例的重点 一个包括GUI和数据库存储功能的典型信息系统通常在体系结构的设计上具有若干层次。 1）表示层(Presentation)：图形用户界面、窗口。 2）应用逻辑-问题域对象(Application Logic-Problem Domain Object)层：代表那些能够满足应用需求的领域概念的对象。 3）应用逻辑-服务对象层(Application Logic-Service Objects)：提供支撑服务的非问题域对象，例如系统和数据库接口。 4）存储层(Storage)：持久存储化机构，如面向对象或关系型数据库。 系统体系结构的层次 学习案例的重点 问题域对象以及为了满足应用需求而对这些对象进行职责分配。 我们的策略：反复学习和反复开发 按照迭代开发策略，销售点终端系统需要经过两个开发周期，第一个周期只实现具有核心功能的简化系统，第二个周期扩展系统的功能。 采用这种开发策略的目的是一个“即时”学习模型。它强调首先表示出使用频率最高的概念。 第5章 理解需求 目标 1）创建需求阶段的制品，例如功能规格说明 2）系统功能的识别和分类 3）系统属性的识别和分类，以及建立属性和功能之间的联系 第5章 理解需求 导言 需求 总体问题陈述 顾客 目标 系统功能 系统属性 需求阶段的其他制品 导言 正确和充分的需求规格说明对一个成功的项目是必不可少的，要想获得需求说明的这方面的技巧，请请参见《Exploring Requirements: Quality Before Design》。需求说明一般是普通文档，不用UML说明。 导言 导言 需求 需求(requirement)是对一个产品的需要或要求的描述。需求阶段的主要目标是确定到底需要什么并将其记录在案，记录要使用一种能够将需求信息清晰地传达给客户和开发小组成员的文档格式，最大难题是如何使得需求的定义没有二义性。 需求阶段应该获得如下制品： 1）总体问题陈述 2）顾客 3）目标 4）系统功能 5）系统属性 总体问题陈述 创建一个用于商品零售的销售点终端系统。 顾客 ObjectStore公司，一个跨国的对象零销商。 目标 总体来讲，是提高结算的自动化水平，为业务过程提供更快捷的、更好的和更经济的服务，具体来讲，系统目标包括： 1）为顾客提供快速结帐。 2）进行快速准确的销售统计分析。 3）仓储控制自动化。 系统功能 系统功能(System function)是系统应该做的事，例如授权信用卡支付。应该识别出这些功能并将其列入逻辑上相关联的功能组中。 要验证X是否真是一个系统功能，则判断句：“系统应该做X”应该成立。 例如，系统应该做信用卡支付授权。 系统属性(System attribute)是系统的非功能性特性，例如易于使用。系统属性不应该是功能规格说明文档的一部分，而应该是一个单独的系统属性规格说明文档。 系统功能 功能的分类：应该对系统功能进行分类，以便区分各类功能的优先次序和识别出哪些是理所当然应该具备的系统功能。 系统功能 基本功能－下表列举销售点终端系统功能，但不全。 系统功能 处理支付功能 系统属性 系统属性是系统的特性或者系统的度量，如：易用、容错、响应时间、界面形式、零售价格、平台。系统属性可能跨越了系统的所有功能，如操作系统平台，或者只针对于一组或者一个特定的功能。 系统属性具有一组可能的属性细节(attribute detail)，这些属性细节往往是属性的分散的、表达模糊的符号值，如： 响应时间=（生理上能接受的时间段） 界面形式=（图形化的、彩色的、基于表的） 系统属性 属性边界约束(attribute boundary constraint)：是一些强制性的边界值约束条件，通常是属性值的一个数字范围： 响应时间=（最长5秒钟） 系统属性 有必要在功能规格说明表中列出与各个功能相关的所有系统属性。 需求阶段的其他制品 需求和相关工作小组：参与测试、协商沟通、复审以及