uml04(上).pptVIP

认识问题 分析问题 解决问题 最终用户(提出问题) 开发团队(解决问题) 以用户的身份站在用户的角度认识问题获取需求—用例建模技术 以开发者的身份站在用户的角度分析问题分析需求—用例分析技术 以开发者的身份站在开发团队的角度分析问题解决需求—面向对象设计 -*- 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 -*- 需求—建造“正确”的系统 需求：系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 非功能性需求 -*- 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 -*- 需求：石头问题 我要一块石头… 差不多，但我要小一点的… 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那个好了… 小一点的蓝色大理石 难捕获，易变！ -*- 需求：如此脆弱 客户/用户的要求/想法/期望 软件设计 软件产品 分析和设计 编码和测试 验 收 没价值的软件需求 补文档 -*- 需求：也需要开发 客户/用户的要求/想法/期望 软件设计 软件产品 开发 编码和测试 验收 有价值的软件需求 分析和设计 -*- 获取好的需求 需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 -*- 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 -*- 需求问题：对策 难捕获 易变 从用户视角看问题 合理的结构 用例 -*- 以用例为中心组织需求 用例 可用性 可靠性 网络协议 业务规则 …… 硬件接口 界面约束 性能 -*- 用例的昨天 Use Cases —Yesterday, Today and Tomorrow（Ivar Jacobson, The Rational Edge, 2003.3） 萌芽期（1967-1986） Ivar Jacobson在爱立信公司，他把各种不同类型的电话呼叫情况称为traffic case，而完成所有呼叫则需要交换机具备相应的功能function或特征feature 1986年，提出术语use case 1987年，OOPSLA’86采用Jacobson论文，用例诞生 成熟期（1987-1992） Objectory AB公司，以用例内容为核心的Objectory Process（对象工厂过程） 发展期（1992-） -*- 内容安排 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程 -*- 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 -*- 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 -*- 获取需求的技巧（MSF） 技巧 描述 实地观察 直接观察个人工作的情况，以发现现存的实践方式和问题 访谈 从个人处收集特定信息 特定群体调查 对一组人员进行调查，以便了解工作态度和共同看法 问卷调查 收集详细数据和统计意义上比较重要的数据 用户指导 让最终用户告诉你，他们是如何操作系统的 原型制作 模拟一个无法直接测试的系统 统计版本 使用具有统计功能的应用程序来记录用户完成任务的方式 -*- 获取需求：考勤卡应用程序 初次访谈记录开发者：谁将使用这个应用程序？客 户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。…… -*- 基于用例