《UML面向对象建模基础》需求建模基础与实例PPT课件.ppt

UMLUML面向对象建模基础面向对象建模基础面向对象建模基础面向对象建模基础需求建模基础与实例需求建模基础与实例知识图谱知识图谱2.AgendaAgenda什么是需求什么是需求如何使用如何使用UML对需求建模对需求建模需求建模实例需求建模实例本章小结本章小结3.AgendaAgenda什么是需求什么是需求如何使用如何使用UML对需求建模对需求建模需求建模实例需求建模实例本章小结本章小结4.需求需求导致项目失败的罪魁祸首导致项目失败的罪魁祸首根据根据Standish Group对对23000个项目进行的研究结果表明，个项目进行的研究结果表明，28%的项目彻的项目彻底失败，底失败，46%的项目超出经费预算或者超出工期，只有约的项目超出经费预算或者超出工期，只有约26%的项目获得的项目获得成功。成功。而在于这些高达而在于这些高达74%的不成功项目中，有约的不成功项目中，有约60%的失败是源于需求问题。的失败是源于需求问题。也就是说，有近也就是说，有近45%的项目最终因为需求的问题最终导致失败。的项目最终因为需求的问题最终导致失败。5.我们在哪重重摔了一跤我们在哪重重摔了一跤在在Standish Group的报告中总结了导致项目失败的最重要的的报告中总结了导致项目失败的最重要的8大原因中，大原因中，有有5个与需求相关：个与需求相关：不完整的需求；不完整的需求；没有用户的介入；没有用户的介入；不实际的客户期望；不实际的客户期望；需求和规范的变理；需求和规范的变理；提供了不再需要的提供了不再需要的6.软件需求曾经让我们如此狼狈软件需求曾经让我们如此狼狈7.需求的定义需求的定义需求层次内容业务需求反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求用户需求 描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求系统需求 从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束需求工程需求工程需求开发活动需求开发活动需求开发与需求管理的分界线需求开发与需求管理的分界线需求捕获需求捕获明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是“项目项目的目标的目标”；通常来说，业务需求是构建在；通常来说，业务需求是构建在“项目发起人项目发起人”的脑子里的的脑子里的；“业务需求业务需求”可以分为可以分为“产品产品/项目目标项目目标”和和“子目标描述子目标描述”两个方面的内两个方面的内容容 理解业务流程：理解业务流程：-若项目较大或者业务较陌生：应进行业务建模；若项目较大或者业务较陌生：应进行业务建模；-如果业务较陌生：聘请领域专家，领域培训；如果业务较陌生：聘请领域专家，领域培训；-如果术语较多，易于混淆：业务术语表如果术语较多，易于混淆：业务术语表-无论如何，都应该建立跨部门职能流程图无论如何，都应该建立跨部门职能流程图 12.需求捕获需求捕获明确用户需求：明确用户需求：-What（收集什么信息）（收集什么信息）-Where（从哪收集）（从哪收集）-How（如何收集）（如何收集）捕获技术优点缺点用户访谈直接有效、灵活、深入，主要技术占用时间长，信息面窄、较片面用户调查面广、可以获得更多反馈不够深入，容易形式主义、失真现场观摩容易建立直接的认识消耗时间长，易失真文档考古能够详细、直观对数据流细节进行分析易陷入文山书海，甚至产生误导联合开发直接的头脑风暴，可以击破需求盲点成本高，需要较高的控制技巧AgendaAgenda什么是需求什么是需求如何使用如何使用UML对需求建模对需求建模需求建模实例需求建模实例本章小结本章小结14.用例模型用例模型组织需求组织需求用例特性用例特性-用例描绘的场景（或事件流）展示了参与者如何使用系统。这都应基于用例描绘的场景（或事件流）展示了参与者如何使用系统。这都应基于系统要完成的任务及其重要性来决定如何确定主要场景、次要场景，以及系统要完成的任务及其重要性来决定如何确定主要场景、次要场景，以及需要多少场景需要多少场景|-用例的粒度问题很关键，既不能太大也不能够太小用例的粒度问题很关键，既不能太大也不能够太小 测试项含义说明WWhat to do用例是否描述了应用做什么？而非如何做？AActors point of view用例的描述是否体现了参与者的视角？VValue for the actor?用例是否对参与者有价值？EEntire scenario用例描述时间流是否为一个完整的场景？用例模型用例模型组织需求组织需求用例建模工作流用例建模工作流-识别参与者识别参与者-寻找用例寻找用例-描述参与者和用例的交互方式描述参与者和用例的交互方式-用包来组织用例和参与者（可选）用包来组织用例和参与者（可选）-通过用例图表示用例模型通过用例图表示用例模型-细化用例模型细化用例模型-评估用例模型评估用例模型类模型类模型概念模型概念模型概念模型也称为领域模型，通常把业务建模生成的称为领域模型，而无专概念模型也称为领域模型，通常把业务建模生成的称为领域模型，而无专门的业务建模生成的称为概念模型门的业务建模生成的称为概念模型 建立概念模型的目的是帮助开发团队理解问题领域的各种概念、各种名词、建立概念模型的目的是帮助开发团队理解问题领域的各种概念、各种名词、以及它们之间的各种关系，它的主要表现方式就是类图以及它们之间的各种关系，它的主要表现方式就是类图 在构建这个模型时，最主要的工作是找出相关的类，然后明明类之间的关在构建这个模型时，最主要的工作是找出相关的类，然后明明类之间的关联关系，必要时加入一些多重性描述和业务规则约束联关系，必要时加入一些多重性描述和业务规则约束 交互模型交互模型描述事件流描述事件流在需求阶段的交互模型是一个起点，随着分析和设计工作的开展，该模型在需求阶段的交互模型是一个起点，随着分析和设计工作的开展，该模型将不断的精化和修正将不断的精化和修正可借助可借助Robustness分析来推导出交互模型分析来推导出交互模型交互模型中一般只包含概念模型中的实体对象和分析模型中的边界对象，交互模型中一般只包含概念模型中的实体对象和分析模型中的边界对象，其目标只是帮助分析人员理清整个事件流，而控制对象、设计类的引入都其目标只是帮助分析人员理清整个事件流，而控制对象、设计类的引入都将在后续阶段进行将在后续阶段进行并非一定要为用例模型中的所有用例构建交互模型，关键在于并非一定要为用例模型中的所有用例构建交互模型，关键在于“是否需要是否需要”可借助状态图表示一些对象状态的变迁及用户界面设计，还可以借助活动可借助状态图表示一些对象状态的变迁及用户界面设计，还可以借助活动图来理解活动与活动之间的控制流图来理解活动与活动之间的控制流AgendaAgenda什么是需求什么是需求如何使用如何使用UML对需求建模对需求建模需求建模实例需求建模实例本章小结本章小结19.确定业务需求确定业务需求20.确定业务需求确定业务需求21.确定业务需求确定业务需求 为开发人员提供一个为开发人员提供一个PSP工具，简化时间记录工作；同时提供数工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。据使用的工具，帮助开发人提高估算能力。22.需求捕获需求捕获23.需求捕获需求捕获24.获取需求特性表获取需求特性表编号特性FEAT01研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目FEAT02项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务FEAT03项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包FEAT04项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询FEAT05开发人员接到任务时，通过系统填写计划时间（计划开始时间和计划结束时间），项目经理确认后，更新日程安排表FEAT06开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）FEAT07开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表FEAT08当任务完成之后，项目经理负责Close任务，并填入实际的完成情况（KLOC、实际结束时间）FEAT09开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长-中断时长）FEAT10开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计FEAT11时间记录程序会自动连接服务器，完成时间日志上传的工作，未能连接服务器，则在本机暂存时间日志FEAT12项目经理可以按项目、任务、关键字统计实际工作时长、产能FEAT13研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能建立概念模型建立概念模型发现类发现类研发经理研发经理 项目项目 项目经理项目经理 工作任务工作任务 工作包工作包开发人员开发人员 日程安排表日程安排表 计划时间计划时间 历史数据历史数据 估算数据估算数据实际数据实际数据 任务编号任务编号 工作关键字工作关键字 开始时间开始时间 暂停时间暂停时间停止时间停止时间 总时长总时长 有效时长有效时长 服务器服务器 产能产能管理层管理层 时间日志时间日志项目项目 工作任务工作任务 工作包工作包 开发人员开发人员日程安排表日程安排表 时间日志时间日志建立概念模型建立概念模型关联分析关联分析建立概念模型建立概念模型职责分析职责分析建立用例模型建立用例模型识别参与者识别参与者建立用例模型建立用例模型合并特性获得用例合并特性获得用例参与者特性用例开发人员FEAT05.开发人员接到任务时，应通过系统填写计划时间（计划开始时间和计划结束时间），项目经理确认后，更新日程安排表 UC01.填写任务计划FEAT06.开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）FEAT10.开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计UC02.查询历史任务数据(UC01的扩展)FEAT09.开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长-中断时长）FEAT11.时间记录程序会自动连接服务器，完成时间日志上传的工作，未能连接服务器，则在本机暂存时间日志UC03.记录时间日志建立用例模型建立用例模型合并特性获得用例合并特性获得用例项目经理FEAT02.项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务UC04.设置工作包FEAT03.项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包FEAT04.项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询UC05.分配工作任务UC5A.查看日程安排(扩展用例)FEAT07.开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表UC06.更新日程表FEAT08.当任务完成之后，项目经理负责Close任务，并填入实际的完成情况（KLOC、实际结束时间）UC07.关闭工作任务FEAT12.项目经理可以按项目、任务、关键字统计实际工作时长、产能UC08.统计项目产能研发经理FEAT01.研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目UC09.管理项目信息管理层FEAT13.研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能UC10.统计团队产能建立用例模型建立用例模型绘制用例图绘制用例图建立用例模型建立用例模型简要描述用例简要描述用例用例编号用例编号UC01用例名称用例名称填写任务计划用例概述用例概述开发人员对项目经理安排给自己的工作任务进行计划，填入计划开始时间和计划完成时间。主参与者主参与者开发人员补充说明补充说明在填入计划开始时间和计划完成时间时，开发人员可以查询与该任务的关键字相关的历史任务的数据。建立用例模型建立用例模型划分用例优先级划分用例优先级优先级用例说明1UC11.登录系统 系统使用的基础，并且可复用原有资源UC09.管理项目信息 UC04.设置工作包 UC05.分配工作任务 UC01.填写任务计划 任务管理的完整流程，是记录时间日志的基础UC03.记录时间日志系统核心功能2UC07.关闭工作任务只是对任务信息进行更新，重要性次之UC06.更新日程表 UC5A.查看日程安排对日程安排进行优化，使任务安排合理化3UC02.查询历史任务数据UC08.统计项目产能 UC10.统计团队产能对系统记录的时间记录进行有效的利用，必须有前面的信息才能够开发UC12.管理用户前期可以通过直接往数据库中写值的方式进行使用，最后提供界面操作即可建立用例模型建立用例模型详细描述用例详细描述用例用例编号用例编号UC03用例名称用例名称记录时间日志用例概述用例概述开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”等功能，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长-中断时长）。主参与者主参与者开发人员前置条件前置条件用户进入“记录时间日志”程序后置条件后置条件将本次时间日志存入数据库基本事件流基本事件流步骤活动1系统显示“开始”、“暂停”和“停止”按钮，但仅“开始”可用2用户点击“开始”，系统记录开始时间，并将“开始”置为不可用，使“暂停”和“停止”按钮可用3用户点击“停止”按钮，系统记录停止时间，并统计暂时时间、暂停次数、总时长、有效时长，并要求用户选择任务编号、输入工作关键字和相关信息。填写完成后，点击确定，用例完成。扩展事件流扩展事件流3a在此期间，若用户点击“暂停”按钮，系统则记录暂停开始时间，并使暂停次数增加1次，并使“暂停”按钮变为“恢复”，使“停用”按钮不可用3a1当用户点击“恢复”按钮，用当前时间减去暂停开始时间得到本次暂停时间，并累加到“暂停时间”时间中，并使“恢复”按钮变为“暂停”，使“停用”按钮恢复可用规则与约束规则与约束时间记录程序应以离线式工作，该程序会自动连接服务器，完成时间日志上传的工作，如果未能连接服务器，则在本机暂存时间日志建立交互建立交互/状态模型状态模型用户界面设计用户界面设计AgendaAgenda什么是需求什么是需求如何使用如何使用UML对需求建模对需求建模需求建模实例需求建模实例本章小结本章小结38.本章小结本章小结首先阐述了需求的三个层次，解释了需求工程的任务，并展开说明了需求首先阐述了需求的三个层次，解释了需求工程的任务，并展开说明了需求捕获的工作流程捕获的工作流程 阐述了如何通过阐述了如何通过UML来对需求进行建模，包括组织需求的用例模型、建立来对需求进行建模，包括组织需求的用例模型、建立概念模型的类模型以及描述事件流的交互模型概念模型的类模型以及描述事件流的交互模型引入了一个引入了一个“开发时间管理开发时间管理”系统的实例，从明确业务需求开始，通过需系统的实例，从明确业务需求开始，通过需求的捕获收集信息，然后构建概念模型、用例模型，并通过文字描述、交求的捕获收集信息，然后构建概念模型、用例模型，并通过文字描述、交互图、状互图、状态机图来对用例进行规格描述，并且最后态机图来对用例进行规格描述，并且最后来说明了如何根据这些信息进行最初的用来说明了如何根据这些信息进行最初的用户界面设计户界面设计 39.Thank you!40.