面向对象分析和设计讲座4.初始化阶段

null第四讲. 初始化阶段 Chapter 4-7第四讲. 初始化阶段 Chapter 4-7曹健 上海交通大学 内容内容案例简介 初始化阶段 需求概念 基于用例的功能性需求获取 非功能性需求1. 案例1. 案例NEXTGEN POS 系统NEXTGEN POS 系统NextGen 销售终端(point-of-sale, POS) 系统 POS系统是用来记录销售信息和处理支付的计算机系统，它一般用于零售店体系结构体系结构minor focusexplore how to connect toother layersprimary focus ofcase studyexplore how todesign objectssecondaryfocusexplore howto designobjects讲授方法讲授方法Iteration 1Iteration 2Iteration 3介绍与第一次迭代相关的分析和设计技术介绍其他的分析和设计技术Likewise.2. 初始化阶段2. 初始化阶段2.1 在我们开始一个项目前…2.1 在我们开始一个项目前…在项目启动前，我们需要回答下列问题: 该项目的vision（设想，前景） 和business case（业务案例） ? 可行吗? 购买and/or 构造? 成本的大致估计; 是$10K-100K 或者几百万? 我们需要继续还是停止?2.2 目的2.2 目的该阶段的目的不是定义所有的需求，而是做适当的调研（to do just enough investigation） 何谓“适当的”： 对新系统的整体目的和可行性形成一个合理的意见 确定是否值得深入研究null初始化阶段的主要目标为: 建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 针对主要的场景，确定或者演示至少一个备选的系统结构 对整个项目估计总成本和 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 (更详细的估计将安排在细化阶段中) 估计可能的风险 (不可预计性的来源） 为项目准备支持环境2.3 制品2.3 制品前景和业务用例（Vision and Business Case） 用例模型（Use-Case Model） 补充规格说明（Supplementary Specification） 词汇表（Glossary） 风险列表和风险管理计划（Risk List&Risk Management Plan） 原型和概念验证（Prototypes and Proof-of-concepts） 迭代计划（Iteration Plan） 阶段计划和软件开发计划（Phase Plan & Software Development Plan） 开发案例（Development Case）3. 理解需求 （Chapter 5）3. 理解需求 （Chapter 5）3.1 概述3.1 概述需求 每一个人都有需求 在不同的时间我们有不同的需求 需求驱动了软件过程 正式的定义 “需求就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件". 3.2涉及到谁?3.2涉及到谁?客户（Client） – 为开发付钱的人，将来是产品的拥有者 顾客（Customer） – 买商品化软件的人，或者将来有发言权确定是否产品可以接受（开发产品）。可能与客户是同样的人 涉众 – 任何对系统的需求有直接或者间接影响的人 参考: Mastering the Requirements Process, Robertson and Robertson3.3 需求管理3.3 需求管理需求管理是一种系统化的方法： 获取，记载、组织和跟踪系统的需求 为客户和项目团队之间针对不断变化的需求建立和维护 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 3.4 功能需求3.4 功能需求功能需求 系统必须提供的服务的描述，系统应该如何响应特定的输入，系统在特定的情景下的行为null例子 用户能够搜索所有的数据集合或者从中选择一部分进行搜索 系统需要为用户提供合适的浏览器从文档库中读取文档 每一个订单需要分配一个唯一标识符，用户可以永久保存起来.3.5非功能需求3.5非功能需求对系统提供服务或者功能的约束，如时间约束，开发过程的约束，标准等等； 许多需求是非功能性的，只能够描述系统的属性或者系统环境的属性null例子 产品需求 “It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set.” 组织需求 “The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95” 外部需求 “The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system”3.6需求类型3.6需求类型另一种分类的方法是采用FURPS+ 模型 [GRA92], 缩写FURPS 描述了需求的主要类别： Functionality Usability Reliability Performance Supportability null功能性 特性集（feature sets) 功能（capabilities ） 安全性（security ） 可用性 人性化因素 (Related Concepts: User-Centered Design) 美学特性(aesthetics ) 用户接口的一致性（consistency in the user interface ） 在线和上下文相关的帮助（online and context-sensitive help ） 智能助手（wizards and agents ） 用户文档（user documentation ） 训练材料（training materials ） null可靠性 失效频率和严重性（frequency and severity of failure ） 可恢复性（recoverability ） 可预测性（predictability ） 精度（accuracy ） 平均失效时间（mean time between failure (MTBF) ） 性能 速度（speed ） 效率（efficiency ） 可用性（availability ） 精度（accuracy ） 吞吐量（throughput ） 响应时间（response time ） 恢复时间（recovery time ） 资源利用率（resource usage ）null可支持性 可测试性（testability ） 可扩展性（extensibility ） 适应性（adaptability ） 可维护性（maintainability ） 匹配性（compatibility ） 可配置性（configurability ） 可服务性（serviceability ） 可安装性（installability ） 本地化，国际化localizability (internationalization) nullFURPS+中的“+” 号意味着还有一些其他的约束，如: 设计约束（design constraints ） 实现需求implementation requirements 接口需求interface requirements 物理需求physical requirements 包装Packaging 授权等等Legal-licensing and so forth4. 基于用例的需求获取 Chapter 64. 基于用例的需求获取 Chapter 64.1 目标4.1 目标如何识别和编写用例 使用摘要、非正式和详述等用例形式的基本式样 将测试应用于确定适当的用例上 将用例分析与迭代开发联系起来 4.2目标和故事4.2目标和故事人类的行动主要是由目标驱动的. 对于一个图书馆信息系统，某些目标为: 每一本书的请求都必须最终实现 新系统必须高度可靠 通过做某些事情或者避免（不做）某些事情来实现 系统构造时，我们必须记住我们的目标 null获取目标并不容易 真正的需要是什么 不同的细节层次 无法控制的复杂性 存在许多方法 越简单的往往应用越广 通过讲述如何利用系统满足不同涉众的目标的故事来记录功能需求-cases of use4.3 什么是用例 ?4.3 什么是用例 ?“一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值”（RUP） 描述了从参与者（Actor）角度看系统（黑盒子）做了什么 WHAT 用例模型本身不是面向对象建模技术null用例的好处 从用户的角度获取操作性需求 对系统的功能进行清晰而一致的描述 系统测试的基础 提供了从功能需求跟踪到系统中真正的类和操作的能力null理解Use Cases 参与者Actor: 是某些具有行为的事物，可以是人（由角色标识），计算机系统或组织，例如收银员 场景Scenario: 参与者和系统之间的一系列特定的活动和交互，也称为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。 用例Use Case: 一组相关的成功和失败场景集合，用来描述参与者如何使用系统实现其目标null处理退货-非正式格式 主成功场景 A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item… 其它场景: If they paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code If the system detects failure to communicate with external accounting system…use case的例子 (from Fowler and Scott, UML Distilled) use case的例子 (from Fowler and Scott, UML Distilled) Use Case: 购买产品 Customer browsers through catalog and selects items to buy Customer goes to check out Customer fills in shipping information (address; next-day or 3-day delivery) System presents full pricing information, including shipping Customer fills in credit card information System authorizes purchase System confirms sale immediately System sends confirming email to customer Alternative: 授权失败 6a. At step 6, system fails to authorize credit purchase Allow customer to re-enter credit card information and re-try Alternative: 会员 3a. System displays current shipping information, pricing information, and last four digits of credit card information 3b. Customer may accept or override these defaults Return to primary scenario at step 6null思考… 用例是相关的成功或者失败的场景的集合 “在ATM机中输入用户ID" 不能建模为单独的Use Case，因为无人使用系统仅仅为了输入ID null用例是什么，不是什么 用例是需求，而且主要是功能需求，反映了系统将做什么 用例是需求，而不是功能或者特征列表 用例是文档，而不是图，用例建模主要是写文字，而不是画图4.4 编写用例4.4 编写用例不同形式化程度 摘要 非正式 详述 详述格式的例子，见pp50-54（中译本），pp68-72（英文版）null章节内容 绪言 范围：系统用例，业务用例 级别：用户目标级别，子功能级别（可被许多用例重复使用的） 主要角色 涉众 前置条件和后置条件 主成功场景和步骤（或基本流程） 扩展（或替代流程） 特殊需求：非功能性需求，质量属性或约束 技术和数据变元表：比如用户对如何实现系统的要求 null指南 以无界面约束的本质风格编写用例 发现目标的目标，可以拓宽我们的视野 What versus How What: 标识我自己并获得授权 How 通过对话框输入用户ID和口令 生物识别i Smart Card 指南：“以本质风格编写用例，摒弃用户界面并关注参与者的意图” “具体风格”需要在早期需求工作中避免 另外一个例子另外一个例子Recycle Items: The user uses this machine to automatically have all the return items (bottles, cans, and crates) counted, and receives a receipt. The receipt is to be cashed at a cash register (machine). Add New Bottle Type: New kinds of bottles can be added to the machine by starting it in ‘learning mode’ and inserting 5 samples just like when returning items. In this way, the machine can measure the bottles and learn to identify them. The manager specifies the refund value for the new bottle type. null编写简洁的用例 编写黑盒用例 软件元素具有 责任 安全质量包保责任状安全管理目标责任状8安全事故责任追究制幼儿园安全责任状占有损害赔偿请求权 （responsibility) 采用参与者和参与者目标的观点 “对特定参与者而言具有价值的可观察的结果” 4.5 如何发现用例4.5 如何发现用例4.5.1 主要过程4.5.1 主要过程选择系统边界 寻找主要参与者 为每个参与者确定他们的目标 定义用例null系统边界描述了系统被包含在内的“信封” 在许多情形下，系统边界是显而易见的。例如对一个单个用户的运行在Microsoft Windows上的个人联系信息管理本，它的边界是很容易定的，因为只有一个用户，一个平台。. 4.5.2 参与者与目标4.5.2 参与者与目标选择系统边界 寻找主要参与者 为每个参与者确定他们的目标 定义用例null参与者是与系统交换数据的实体。参与者可以使用户，外部的硬件或者另外一个系统 某些技巧某些技巧我们可以问一些代表性的问题来找到参与者和目标 参与者的类型 主要的参与者Primary Actors 支持参与者Supporting Actors 幕后参与者Offstage actors 参与者-活动列表 这似乎一个交互和叠代的过程 The focus of this stagenull主要的参与者和用户目标依赖于系统的边界4.5.3 定义用例4.5.3 定义用例选择系统边界 寻找主要参与者 为每个参与者确定他们的目标 定义用例null一般而言，为每一个用户目标定义用例 用例名称以动词开头 将CRUD (create, retrieve, update, delete)这些分散的目标合并成一个CRUD用例: Manage 定义用例需要交流和参与 领域专家的参与非常重要 迭代开发 null发现有效用例 用例的粒度问题 大用例 我们的企业需要拓宽销售渠道 整个系统就只有一个用例!!! 小的用例 输入口令 系统中可能有成百上千个用例!!! 我们必须权衡 null经验方法 老板测试 EBP测试 规模测试 null老板测试 老板是付钱的人 老板必须看到可量化的价值nullEBP测试 EBP用例 对计算机应用的需求分析，关注于基本业务过程（ elementary business processes，EBPs）层面上的用例 依据持续时间，步骤，涉及到的人来定 增加可见的或者可度量的业务价值 没有人仅仅想输入一个口令 客户愿意为此付费吗?null规模测试 用例通常应该包括多个步骤 在详细描述的情形下，应该需要3-10页文本null分析 供应者 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 进行协商 处理退货 登陆 在游戏板上移动棋子null任何东西都有例外 EBP 原则也不是圣经 有些时候我们会把多个用例中的公共部分单独成为用例 目标与用例的关系 目标可以分解成不同层次 用户目标 EBP层次的用例=用户目标 EBP层次的用例 用户目标 Use Case reflects current solutions Understanding Goal opens up the vision for new and improved solutions 企业层次 增加利润 子功能目标 4.6 用例图4.6 用例图用例的组织和用例图 用例的组织和用例图 在UML里, 用例图是表达用例和活动者及其之间关系的载体 用例图是模型图，用例图可包含用例，活动者以及它们之间的关系，这些关系可以是： 关联关系 依赖关系 实现关系 用例图的用途是为软件系统、软件子系统、类的动态行为建模。它从两个方面对其建模对象的内容进行描述，即： 描述它们的边界 对它们进行需求分析null下图是一个描绘系统边界的用例图的例子，它通过区分系统用例和活动者，明确区分了系统内部的事物和系统外部的事物，通过描绘它们之间的关联关系，系统的边界得到了清晰的表达 null用例图和用例关系在编写用例工作中是次要的。用例是文本文档。编写用例意味着编写文本。 绘制简单的用例图，并与参与者-目标列表关联。 用例不是面向对象的画图建议画图建议4.7 在迭代方法中如何使用用例4.7 在迭代方法中如何使用用例用例驱动开发用例驱动开发功能需求首先记录在用例（用例模型）中； 用例是迭代计划的重要部分，是预算的关键输入 用例实现驱动设计 用例影响了用户手册和测试null需求规格说明的工作任务跨越了各个迭代，见书表6-1， 中文，pp72，英文，pp96 初始阶段编写用例初始阶段编写用例确定目标和涉众，推测项目范围 参与者-目标-用例 表 绝大部分需要关注的，复杂的，具有风险的用例采用简单的形式编写 其中的10%-20% 的用例代表了复杂的核心功能，需要构建核心架构或者在某些方面具有风险，采用详细的格式进行描述 确定是否要继续到细化阶段细化阶段编写用例细化阶段编写用例多次时间定量的迭代 绝大部分的需求被识别和描述清楚 在每一次迭代中，会有一次需求会议 早期的会议关注于最重要用例的子集 用户目标和用例列表被精化 在细化阶段结束时，80-90%的用例被详细描述构造阶段编写用例构造阶段编写用例由时间定量的迭代 关注于完成系统 在这个阶段可能涉及编写一些次要的用例，也可能举办需求讨论会nullWhereAt a requirements workshop.WhoMany, including, end users and developers, will playthe role of requirements specifier, helping to write usecases.Led by system analyst, who is responsible forrequirements definition.How: ToolsSoftware:For use case text, use a web-enabled requirements toolthat integrates with a popular word processor.For use case diagrams, a UML CASE tool.Hyperlink the use cases; present them on the projectwebsite.Hardware: Use two projectors attached to dual video cardsand set the display width double, to improve thespaciousness of the drawing area or display 2 adjacenctword processor windows .DeveloperCustomerSystemAnalystEnd UserTwo adjacent projections.SoftwareArchitect5.识别其他需求5.识别其他需求UP中的制品UP中的制品需求制品集合需求制品集合初始化阶段的制品初始化阶段的制品用例模型 词汇表 补充性规格说明 前景 业务规则词汇表词汇表领域术语 设计/实现中的术语对所有人并不相同 从用例中观察：是不是有任何术语需要重用或者容易误解补充说明文档补充说明文档包含那些用例中没有的需求: 非功能需求 (URPS+) 领域 (或者业务) 规则 法律问题 – 责任，知识产权，等等 约束 封装, 等等.远景远景业务机会 竞争 目标 关键的涉众 产品概览 远景中表达的需求初始化中的其他制品初始化中的其他制品风险列表: What issues could be a problem for project achieving goals? 原型: Proof of technical feasibility UI prototypes to clarify functionality in vision 高层的系统备选架构null编写前景的第一个草稿 确定用户目标和支持性用例 编写某些用例并开始编写补充性规格说明 依据上述信息，修改前景 构造构造依据反馈修改前景 其他需求将更清楚，并可以记录在补充规格说明中 主要的术语将被发现和精化 主要的需求——功能或者其他方面的需求稳定下来nullDeveloperCustomerSystemAnalystEnd UserTwo adjacent projections.SoftwareArchitect