《软件工程4-4基于UML的需求分析方法.ppt》由会员分享，可在线阅读，更多相关《软件工程4-4基于UML的需求分析方法.ppt（205页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第四部分软件工程的需求过程软件工程软件工程传统的需求分析方法-1面向对象的需求分析方法-2基于UML的需求分析方法-3需求工程与需求管理实现-4第四部分第四部分 软件工程的需求过程软件工程的需求过程第三章基于UML的需求分析方法UML概述-3.1需求获取与用例建模-3.2类与对象建模-3.3动态建模-3.4物理体系结构建模-3.5第四部分第四部分 软件工程的需求过程软件工程的需求过程3.1UML概述UML统一OO方法大战的努力n1960年-70年代COBOL,FORTRAN,C结构化分析和设计技术n1980年-1990年前Smalltalk,Ada,C+,VisualBasic早期面向对象生成
2、（代码）方法n1990年中晚期JavaUnifiedProcessUML概要概要nUML是一种语言：可视化详细描述的构造性的文档化的nUML的价值是一个开发的标准支持完整的软件开发生命周期模型支持不同的应用领域是基于经验的和用户群体需要的被许多工具支持什么是UML?nUnifiedModelingLanguage（统一建模语言）是统一建模语言）是国际对象管理组织国际对象管理组织OMG制定的一个通用的、可视制定的一个通用的、可视化建模语言标准化建模语言标准n用于描述（用于描述（specify）、）、可视化（可视化（visualize）、）、构构造（造（construct）和记载（和记载（docu
3、ment）软件密集型软件密集型系统的各种工件系统的各种工件nUMLUML提供了一系列建模元素、概念、关系以及规则，提供了一系列建模元素、概念、关系以及规则，应用于软件开发活动应用于软件开发活动n详细内容，请学习详细内容，请学习统一软件开发过程统一软件开发过程（The Unified The Unified Software Development ProcessSoftware Development Process）（美）（美）IvarIvar Jacobson Jacobson、Grady Grady BoochBooch、James James RumbaughRumbaugh著，周伯生
4、、冯学民、樊著，周伯生、冯学民、樊东平译（机械工业出版社）东平译（机械工业出版社）UML概念nUMLUnifiedModelingLanguage.组合了当前最好的面向对象软件建模方法UML三位主要贡献者n1.OMT方法（对象、动态、功能模型，JamesRumbaugh）n2.TheBoochmethod（5个步骤，GradyBooch）n3.OOSE（UserCase图，IvarJacobson）JamesRumbaughGradyBoochIvarJacobsonUML概念n1994年，Booch和Rumbaugh在Rational开始了UML的工作，但是的目标是创建一个“统一方法”n他们
5、把Booch93和OMT2统一起来，与95年发布了UM0.8（UnifiedMethod）n1995年OOSE的创始人Jacobson加入到这个联盟中，开始把工作重点放到创建一种标准建模语言，UMLUnifiedModelingLanguage。n他们以Booch方法、OMT方法、OOSE方法为基础，吸收了其他流派的长处，于96年6月、10月、97年1月、11月分别推出了UML0.9、0.91、1.0和1.1创建创建UMLBooch 方法OMTUnified Method 0.8OOPSLA 95OOSE其他方法UML 0.9Web-June 96 公共公共反馈反馈最后提交给最后提交给 OMG
6、,Sep 97第一次提交给第一次提交给OMG,Jan 97UML 1.1OMG 认可认可,Nov 1997UML 1.3UML 1.0UML 团体团体UML 2.0UML概念nMethod方法告诉使用者做什么、怎么做、什么时候做、为什么做（特定活动的目的），方法包括模型nModeling模型用来描述使用某种方法的结果，例如，通过不同角度的简化视图，描述对象系统的设计与实现结果，模型用建模语言来表达nLanguage建模语言由记号（模型使用的符号）和一组规则（语法、语义等）组成UML概念nUML是一种语言遵循特定的规则允许创建各种模型并不告诉设计者需要创建哪些模型并不提供开发过程nUML是可视化
7、语言UML是图形化语言图形便于交流（一幅图抵上千文字）nUML是用于构造系统或理解系统的语言UML既支持正向工程，又支持反向工程nUML是文档化语言将所建造的系统记录下来便于新程序员跟进开发产品新版本时很有用处UML的概念的概念n模型元素n关系n扩展的机制n图表UML构成：模型元素关系扩展的机制图表模型元素模型元素关系关系图表图表模型元素模型元素n结构元素类，接口，协作用例，主动类，构件节点n行为元素交互,状态机n组元素包,子系统n其它元素注解类、对象与接口n一个系统往往可以从不同的角度进行观察，一个角度构成了一个视图nUML有九种图表，构成5种视图：1、用例图（usecasediagram）
8、2、类图（classdiagram）3、对象图（objectdiagram）4、状态图（statediagram）5、时序图（sequencediagram）6、协作图（collaborationdiagram)7、活动图（activitydiagram）8、构件图（componentdiagram）9、部署图（deploymentdiagram）UML的图表与视图静态逻辑视图动态逻辑视图3-并发视图并发视图1-用例视图用例视图5-部署视图部署视图2-逻辑视图逻辑视图4-构件视图构件视图模型模型,视图视图,和图表和图表Use CaseDiagramsUse CaseDiagrams用例图用例图
9、ScenarioDiagramsScenarioDiagrams协作图协作图StateDiagramsStateDiagrams组件图组件图ComponentDiagramsComponentDiagrams分布图分布图StateDiagramsStateDiagrams对象图对象图ScenarioDiagramsScenarioDiagrams状态图状态图Use CaseDiagramsUse CaseDiagrams时序图时序图StateDiagramsStateDiagrams类图类图活动图活动图模型模型是对一个系统从详细观察的角度的描述模型模型图表图表n图表是模型的视图表现给投资者看得
10、详细的描述;提供了系统的局部详细描述；和别的视图保持语义一致；n在UML中,有九种标准图表静态视图:用例图,类图,对象图,组件图,分布图动态视图:时序图,协作图,状态图,活动图用例图用例图n捕获用户能够看到的系统通过对”场景”的描述，定义系统的功能和性能，并获得用户和开发团队的共同认可提供清楚和无二义的用户与系统的交互描述用例图n在开发过程的早期创建n目的：详细说明系统的表达含义；捕获系统的需求；验证系统的体系结构；驱动实现和生成测试用例。n由分析人员和领域专家开发UseCase图nUseCase图形描述了一个系统应该执行的什么或应该有什么外部系统它描述了存在的actors（外部系统）、use
11、case（该系统应该执行什么）以及它们的关系n在UseCase视图中可以包含以下的图形UseCase图：包括：包、actors、usecase和关系相互作用图（序列图或协同图）：包括：对象和消息n符号表示：系统名称系统用例名用例角色关联UseCase图例保险商务系统签定保险单销售统计客户统计客户保险销售员UseCase图例UML用例图示例类图类图n捕获系统的词汇表n在开发过程中被创建和精确化n目的系统中的名字和模型概念详细描述协作关系详细描述逻辑数据库表n由分析人员、设计人员和代码实现人员开发类图ClassDiagram类图描绘系统的静态视图它描述了系统逻辑设计中存在的包、类以及它们之间的关系
12、类图可以代表该系统中部分或全部的类结构学生姓名:string学号:string书书名:string价格:real1购买0.*属于对象图对象图n捕获实例和连接对象图对象图n捕获实例和连接n在分析和设计阶段创建n目的举例说明数据/对象结构详细描述瞬态图n由分析人员、设计人员和代码实现人员开发对象图ObjectDiagram王平：学生姓名:王平学号:020106英语：书书名:英语价格:26.5数学：书书名:数学价格:21.8对象间关系n关联关系(Association)n聚集关系(Aggregation)n泛化关系(Generalization)n依赖关系(Dependency)n细化关系(Refi
13、nement)构件图构件图n捕获实现的物理结构构件图构件图n捕获实现的物理结构n作为体系结构规范的一部分实现n目的组织源代码构造一个可执行的发布版本指定物理数据库n由集成人员和程序人员创建分布图分布图n捕获系统硬件的拓扑结构分布图分布图n捕获系统硬件的拓扑结构n作为系统结构规范的一部分被创建n目的描述组件的分布标识系统性能瓶颈n由集成人员、网络工程师和系统工程师开发交互图n交互图描述了系统在逻辑设计中存在的对象及其间的关系它可以代表系统中对象的结构nUML中包含两种交互图，它们对同一交互操作提供了不同的浏览视角时序图（顺序图）n按时间顺序排列对象交互操作协作图n围绕对象及其间的链接关系组织对象
14、的交互操作交互图n顺序图和协作图均被称为交互图（interactiondiagram）。由一组对象、对象间的关系、对象间发送的消息组成一种动态视图，可以单独使用、也可以对用例中的特定控制流程建模。n顺序图和协作图同构的顺序图和协作图同构的：两种图之间可以相互转换，而没有任何信息损失。n二者区别点在于：顺序图（sequencediagram）关注消息的时间顺序，有对象生命线、有控制焦点；协作图（collaborationdiagram，在UML2.0中协作图被称为communicationdiagram，二者指的是同一类型的图）关注收发消息的对象的组织结构，有路径、有顺序号。时序图时序图n捕获系
15、统的动态行为(面向时间的)时序图时序图n捕获系统的动态行为(面向时间的)n目的模型流程的控制举例说明典型的脚本打印机就绪打印文件时序图（SequenceDiagram）打印机忙保存文件打印文件打印文件计算机打印服务器打印队列计算机UML顺序图示例（某客户Joe取20美元的顺序图）协作图协作图n捕获系统的动态行为(面向消息的)协作图协作图n捕获系统的动态行为(面向消息的)n目的模型流程控制举例说明对象结构和控制的协调协作图（CollaborationDiagram）打印机忙保存文件打印机就绪打印文件打印文件计算机打印队列打印服务器打印机UML协作图示例（ATM系统中“客户插入卡”的协作图）状态图
16、n捕获系统动态行为(面向事件的)状态图状态图n捕获系统动态行为(面向事件的)n目的对象生命周期模型对象生命周期模型为起反作用的对象为起反作用的对象(用户接口、设备等）建模用户接口、设备等）建模状态图StateDiagram状态图描述了：给定类的状态转换空间导致状态转换的事件导致状态改变的动作为类的重要动态行为建立状态转换图超时到达上楼上楼到达上楼到达在底楼向上移动向底楼移动向下移动空闲状态图StateDiagramUML状态图示例电视机世界上的万事万物在任何特定时刻总处于某一特定状态。一个电梯可以处于上升、下降、停止状态。一辆汽车可以处于前行、后退、停止状态。一台电视机可以处于开机、播放、待机
17、或关机状态。活动图活动图n捕获动态行为（面向活动的）活动图活动图n捕获动态行为（面向活动的n目的给商业工作流建模给操作建模活动图ActivityDiagramDiskfreeDiskfull显示磁盘满显示在打印删去显示信息建立打印文件Win.printAll()printer.print()活动图的符号集与状态图中使用的符号集类似。像状态图一样，活动图也从一个连接到初始活动的实心圆开始。活动是通过一个圆角矩形（活动的名称包含在其内）来表示的。活动可以通过转换线段连接到其他活动，或者连接到判断点，这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个终止点（就像在状态图中一样）
18、。作为一种选择，活动可以分组为泳道（swimlane），泳道用于表示实际执行活动的对象UML活动图示例（ATM系统中“客户插入卡”的活动图）体系结构和UML组织：包,子系统动态交互状态机设计视图实现视图过程视图组件 类,接口,协作活动类分布视图节点用例图用例UML静态图n用例图（UseCaseDiagram）n类图(ClassDiagram)n对象图(ObjectDiagram)n构件图(ComponentDiagram)n部署图(DeploymentDiagram)UML动态图n状态图（StateDiagram）n时序图（SequenceDiagram）n协作图（CollaborationD
19、iagram）n活动图（ActivityDiagram）UML建模方法与视图n用例建模用例图n类和对象（结构）建模：类图对象图n行为（动态）建模用例图交互图（顺序图、协作图）活动图状态图n物理体系结构建模构件图实施图UML过程nUML过程主要包括：用例驱动（use-case-driven）以体系结构为中心（architecture-centric）反复（iterative）渐增式开发（incremental）UML过程n1、用例驱动：用用例方法获取系统的功能需求，并以此驱动需求分析之后的所以阶段的开发在需求阶段，用例所包括的系统功能，需要用户的确认在设计和实现阶段，用例被实现在测试阶段，用例用
20、于验证系统功能需求用例分析设计实现测试用例视图用例视图并发视图并发视图部署视图部署视图构件视图构件视图逻辑视图逻辑视图用例影响开发的所有阶段用例视图影响其他视图UML过程n2、以体系结构为中心项目开发的早期，除了需求以外，另一个最主要的工作就是确定系统的体系结构体系结构定义了系统的各部分、各部分的关系和交互、通信机制、如何增加和修改体系结构的规则体系结构决定了系统的功能和非功能部分n非功能部分包括：性能、易理解性、易修改性、复用度在UML中，通过定义可以层次化的“包”，来实现把一个大系统划分成不同的小系统确定体系结构的基本方法是：分析、选择、原型化、评估和精细UML过程n3、反复迭代用UML方
21、法建模，可以反复多次，不需要一次完成通过反复，增加新信息、细化新的细节每次反复，应进行评估，评估的内容还应包括：代价、风险n4、渐增式多次迭代，每次迭代增加新的用例和功能每次迭代，都是分析、设计、实现和测试的过程迭代的最大好处是分解了风险，不至于把失败的风险留到开发的最后才发现3.2需求获取与用例分析需求开发过程的阶段任务需求开发过程的阶段任务需求开需求开发过发过程的重要里程碑程的重要里程碑需求获取需求获取需求分析需求分析需求处理需求处理需求验证需求验证问题定义阶段需求分析阶段面向用户确认的需求描述面向实现的需求规格说明用户确认需求评审面向实现的细化面向管理的规范面向成果的验证基于UML的需求
22、获取1、需求获取与业务建模、需求获取与业务建模n对于一个复杂的业务系统，我们可能涉及：公司组对于一个复杂的业务系统，我们可能涉及：公司组织、业务单位、部门和人员岗位、职责和功能、内织、业务单位、部门和人员岗位、职责和功能、内部和外边网络、客户、业务信息流、行政和财务流部和外边网络、客户、业务信息流、行政和财务流等等等等n为这个组织建立计算机系统，我们要回答：为这个组织建立计算机系统，我们要回答：为什么要建立这个系统为什么要建立这个系统这个系统的定位在何处这个系统的定位在何处我们如何确定哪些功能是最适宜放在系统的特定节点上我们如何确定哪些功能是最适宜放在系统的特定节点上我们何时采用计算机处理而何
23、时采用人工处理我们何时采用计算机处理而何时采用人工处理为适应计算机处理，我们需要改变现有工作流程吗为适应计算机处理，我们需要改变现有工作流程吗n回答这些问题的技术，就是业务建模回答这些问题的技术，就是业务建模n业务建模的目的：业务建模的目的：建模过程是开发者和用户之间为导出需求规约而进行的交建模过程是开发者和用户之间为导出需求规约而进行的交互过程互过程因此：因此：理解现有业务组织的静态结构和动态运作方式理解现有业务组织的静态结构和动态运作方式确保客户、最终用户以及开发人员对业务组织有共同的理解确保客户、最终用户以及开发人员对业务组织有共同的理解系统的边界在那里？功能是什么？系统的边界在那里？功
24、能是什么？理解如何部署新的系统以提高生产力，以及现有的哪一个系统会受理解如何部署新的系统以提高生产力，以及现有的哪一个系统会受到新系统的影响到新系统的影响n系统的功能由用例来表示：系统的功能由用例来表示：用例用来：用例用来：确定和描述系统的功能要求确定和描述系统的功能要求给出清晰和一致的系统做什么的描述给出清晰和一致的系统做什么的描述为验证系统所需的系统测试提供基准为验证系统所需的系统测试提供基准提供从功能需求到系统实际类和操作的跟踪能力提供从功能需求到系统实际类和操作的跟踪能力图例图例 说明说明业务处理业务处理单位单位业务处理业务处理描述描述表格制作表格制作传递传递存储存储收集资料收集资料储
25、户存折存取款单存折现金存折业务分类存款单折取款单折存款处理取款处理利息文件帐目文件存取款业务存取款业务传统方法：业务流程图传统方法：业务流程图存取款业务处理过程存取款业务处理过程在在UML中的建模结构就是中的建模结构就是业务用例模型业务用例模型和和业务对象模业务对象模型型n领域模型领域模型将系统语境中的重要概念描述为领域对象，将系统语境中的重要概念描述为领域对象，并建立这些领域对象之间的关系并建立这些领域对象之间的关系n业务模型业务模型是领域模型的超集，包括：是领域模型的超集，包括：a.业务用例模型：说明系统所支持的业务过程业务用例模型：说明系统所支持的业务过程b.业务对象模型：领域模型和业务
26、用例实现业务对象模型：领域模型和业务用例实现n业务用例模型业务用例模型是业务系统预期功能的描述模型，是是业务系统预期功能的描述模型，是系统开发任务和作为产品提交时的最根本的系统工系统开发任务和作为产品提交时的最根本的系统工作描述作描述n业务对象模型业务对象模型描述了实体和相互交互完成业务用例描述了实体和相互交互完成业务用例所需要的功能，是业务用例的实现所需要的功能，是业务用例的实现n下面，我们用示例介绍下面，我们用示例介绍利用UML概念进行业务建模业务过程与业务用例n一个一个业务过程业务过程是根据组织目标而采用组织资源来是根据组织目标而采用组织资源来获得预定义结果的一组逻辑相关的活动获得预定义
27、结果的一组逻辑相关的活动n用一个用一个业务用例业务用例代表一个业务过程代表一个业务过程n业务用例包括：业务用例包括：角色（与业务活动交互的人或系统）角色（与业务活动交互的人或系统）用例（角色与业务元素交互完成工作的事件序列）用例（角色与业务元素交互完成工作的事件序列）n建立业务用例的过程：建立业务用例的过程：确定行为者确定行为者确定用例确定用例确定行为者n行为者：行为者：与系统交互的人或其他系统与系统交互的人或其他系统交互：发送、接收、交换信息交互：发送、接收、交换信息行为者执行用例行为者执行用例行为者是一个角色，而不是具体个人行为者是一个角色，而不是具体个人n寻找行为者寻找行为者谁使用系统的
28、功能谁使用系统的功能谁需要系统提供信息谁需要系统提供信息谁维护、管理、控制系统谁维护、管理、控制系统系统完成功能还需要得到其他系统的支持系统完成功能还需要得到其他系统的支持还有哪些人对系统的结果感兴趣还有哪些人对系统的结果感兴趣业务用例银行确定用例确定用例l一个用例是被行为者感受到的一个完整的功能一个用例是被行为者感受到的一个完整的功能UML的定义：用例是给一个特定行为者的一个可观察的结果值的系统的定义：用例是给一个特定行为者的一个可观察的结果值的系统所完成的一系列动作所完成的一系列动作这个动作除计算机内部完成的计算外，还包括与行为者的信息交互这个动作除计算机内部完成的计算外，还包括与行为者的
29、信息交互用例通过关联与行为者进行交互用例通过关联与行为者进行交互用例总是被行为者所启动，并回答一个可识别的结果用例总是被行为者所启动，并回答一个可识别的结果类似于对象是类的实例，用例的实例是场景（类似于对象是类的实例，用例的实例是场景（scenario）。）。例如：例如：“用户在用户在ATM机上执行取款操作机上执行取款操作”用例的场景是：用例的场景是：“张三在张三在ATM机上取出机上取出300元人民币元人民币”寻找用例寻找用例行为者需求系统提供哪些功能？行为者需求系统提供哪些功能？行为者是否需要创建、读、写、修改、删除系统中的信息？行为者是否需要创建、读、写、修改、删除系统中的信息？行为者是否
30、需要被系统提醒、启动系统的某个功能？行为者是否需要被系统提醒、启动系统的某个功能？系统能否帮助行为者做一些事情，来提高行为者的效率、便利系统能否帮助行为者做一些事情，来提高行为者的效率、便利寻找用例寻找用例 考虑人和饮料贩卖机的交互，包括购买饮料，首考虑人和饮料贩卖机的交互，包括购买饮料，首先，放置货物（饮料）等，下面考虑购买饮料。先，放置货物（饮料）等，下面考虑购买饮料。l用用例例描描述述了了系系统统的的行行为为，包包括括行行为为者者和和系系统统之之间间的的交交互互以以及及系系统统与与系系统统之之间间的交互。的交互。n 用例用例是系统提供的功能块。演示了是系统提供的功能块。演示了人们如何使用
31、系统。它来自于人们如何使用系统。它来自于客户需求客户需求的分析的分析。这个过程称为。这个过程称为Use Case分析分析,是整个系统开发中非常关键的过程。是整个系统开发中非常关键的过程。我们设计一个饮料贩卖机，从用户的角度来考察它的功能：我们设计一个饮料贩卖机，从用户的角度来考察它的功能：问问:“自动饮料贩卖机将为您做什么自动饮料贩卖机将为您做什么?”答答:“我我通过自动饮料贩卖机购买一听饮料通过自动饮料贩卖机购买一听饮料.”饮料贩卖机的主要功能是使得用户可以购买饮料，饮料贩卖机的主要功能是使得用户可以购买饮料，我们为这种机器标记一个叫我们为这种机器标记一个叫 “买饮料买饮料”的的use ca
32、seuse case.UML中的中的 Use Case 表示表示Buy SodaUse CaseActorCommunicationCustomernusecase记录用户使用系统是从头到尾的一系列事件。用户普遍称为“活动者”，它可以是人或另一个系统。n每一个 usecase 包括“活动者”和一个表示 usecase 的椭圆。Use Case活动者活动者活动者可以是人或另一个系统，它与当前的系统交互，向系统提供输入或从系统中获得输出。Actor NameTelephoneSystem(电话系统）使用电话卡对方付款PhoneUser(电话用户）活动者活动者的标志的标志n谁对某一需求感兴趣？n组织
33、中哪一部分使用系统?n谁从系统的使用中受益?n谁向系统提供信息？n谁将维护系统？n系统使用外部资源吗?n系统和已经存在的系统交互吗?活动者活动者的的类型类型n实际的人，即用户，是最常用的角色，几实际的人，即用户，是最常用的角色，几乎每个系统都有。命名这些角色的时候，乎每个系统都有。命名这些角色的时候，要按作用来命名，而不是按照位置命名。要按作用来命名，而不是按照位置命名。n另外一个系统。例如航空订票系统可能需另外一个系统。例如航空订票系统可能需要与外部应用程序接口，验证信用卡以便要与外部应用程序接口，验证信用卡以便购买。购买。n可能隐蔽的角色：时间。例如商业促销项可能隐蔽的角色：时间。例如商业
34、促销项目推出免费奖，每天下午三点，系统自动目推出免费奖，每天下午三点，系统自动选择向随机客户提供免费奖品。选择向随机客户提供免费奖品。在饮料自动贩卖机中，除了买饮料的在饮料自动贩卖机中，除了买饮料的顾客顾客，还有以下的还有以下的活动者活动者。Buy SodaRestock SodaCollect MoneyCustomerSupplierCollector每一每一种活种活动者动者具有具有自己自己的的 use case饮料贩卖机中的饮料贩卖机中的活动者活动者供应商供应商向向自动贩卖机添加饮料。自动贩卖机添加饮料。收银员收银员从从自动贩卖机收钱。自动贩卖机收钱。理解用例理解用例n用例用例独立于实现
35、。独立于实现。用例用例关注的是作用而不是如关注的是作用而不是如何实现这个作用。何实现这个作用。n用例用例是系统的高级视图。用例的集合应让客户是系统的高级视图。用例的集合应让客户易于了解高层的整个系统。易于了解高层的整个系统。n最后，最后，用例用例关注系统外的用户。每个关注系统外的用户。每个用例用例应表应表示用户与系统间的完整事务，为用户提供一定示用户与系统间的完整事务，为用户提供一定价值。价值。用例用例应按业务术语命名，而不是按技术应按业务术语命名，而不是按技术术语命名，应让客户一目了然。术语命名，应让客户一目了然。n例如：例如：用例用例不要命名为不要命名为“客户与银行客户与银行ATM的交互界
36、面的交互界面”，如果客户要买票，如果客户要买票,用例可以称为用例可以称为“客户购票客户购票”。n用例分析有助于:捕捉需求计划开发过程的循环往复。验证系统。n需求分析从用例分析开始，它驱动整个开发过程。n在用例中描述了所有的功能需求。标记标记用例用例n活动者希望这个系统执行什么任务。n活动者在系统中访问哪些信息(创建,存储,修修改,删除等)?n外部的哪个变化将要被告知系统？n系统的那个事件将要被告知活动者？n系统将要怎样维护?标记标记用例用例用例的完整性n每个功能需求是否至少在一个用例中?如果需求不在用例中,则不会实现。n是否考虑了每个操作者如何使用系统。n每个操作员向系统提供了什么信息。n每个
37、操作员从系统接收了什么信息。n是否考虑了维护问题，要有人启动和关闭系统。是否标示了系统要交互的所有外部系统。n每个外部系统从系统接收什么信息和系统发送什么信息?用例视图用例视图一个usecase视图包括一个usecase集合，定义整个系统的功能。Buy SodaRestock SodaCollect MoneyCustomerSupplierCollectorSoda MachineUse Case 视图视图系统系统 边界边界用例的范围2、从业务模型到系统模型例：建立用例的系统模型例：建立用例的系统模型pATMATM取款机作为一个业务系统取款机作为一个业务系统p来取款的客户是一个角色来取款的客
38、户是一个角色p用例是业务模型中业务的活动用例是业务模型中业务的活动p系统模型描述了业务中系统的工作（内部活动）系统模型描述了业务中系统的工作（内部活动）p角色是外部，用例是内部。取款的客户是角色，取款是用例。角色是外部，用例是内部。取款的客户是角色，取款是用例。p用用例例模模型型开开始始定定义义角角色色之之间间的的关关系系（关关联联关关系系、包包括括关关系系、扩扩展关系、一般化关系等）。展关系、一般化关系等）。p用用例例模模型型描描述述事事件件流流，包包括括主主事事件件流流、其其他他事事件件流流、前前提提条条件件、事后条件等等。事后条件等等。p这这样样，我我们们就就建建立立了了一一张张描描述述
39、“活活动动”的的Use Use CaseCase图图，通通过过这这张张图图，我们就能够比较具体地描述我们就能够比较具体地描述“活动活动”，即让用户看到：，即让用户看到：p谁与系统交互，有助于发现缺少的参与者谁与系统交互，有助于发现缺少的参与者p知道系统的范围，有助于发现缺少的功能知道系统的范围，有助于发现缺少的功能业务用例描述：柜台取款业务用例活动图业务用例活动图：柜台取款柜台取款注意：注意：这里只有角色这里只有角色（客户）和用例（客户）和用例（系统）（系统）对于系统内部的对于系统内部的实现，我们还没实现，我们还没有更多的涉及有更多的涉及从业务模型到系统模型-ATM系统用例ATM系统用例-AT
40、M取款用例时序图-ATM取款系统开始区分系统开始区分ATM系系统和银行主机系统统和银行主机系统用例的层次n概要目标用例：概要目标用例：需要多个用户目标会话来完成（日、周、月、需要多个用户目标会话来完成（日、周、月、年）年）n用户目标用例用户目标用例：满足特定、迫切、有价值的用例目标（分钟、满足特定、迫切、有价值的用例目标（分钟、小时）小时）n子功能用例：子功能用例：为了完成用户的真实目标而提供的功能为了完成用户的真实目标而提供的功能用户目标层n“Cantheactorgoawayhappyafterhavingdonethis?”n通常通常1个人，个人，1次性完成，次性完成，2-20分钟分钟概
41、要目标层n使用使用ATM用例：银行自动柜员机用例：银行自动柜员机n含有多个用户目标，可包含：存取款、查含有多个用户目标，可包含：存取款、查询、修改密码、打印凭单、提供跨地域、询、修改密码、打印凭单、提供跨地域、跨银行服务跨银行服务n作用作用说明用户目标执行的背景说明用户目标执行的背景说明相关目标的范围说明相关目标的范围提供了下层用例的目录提供了下层用例的目录用户目标层次用例分析流程1.1.定义系统范围和边界定义系统范围和边界2.2.列出角色及其作用列出角色及其作用3.3.提取概要用例并调整得当提取概要用例并调整得当4.4.着重对系统的用户目标层用例进行细化着重对系统的用户目标层用例进行细化5.
42、5.填写干系人责权利、前置后置条件填写干系人责权利、前置后置条件6.6.编写基本流编写基本流7.7.列出所有扩展条件，编写扩展处理步骤列出所有扩展条件，编写扩展处理步骤8.8.用活动图、状态图、交互图等描述重点用例用活动图、状态图、交互图等描述重点用例9.9.分解、合并用例，调整用例关系模型（用例图）分解、合并用例，调整用例关系模型（用例图）需求获取需求获取关键是获得用户的确认关键是获得用户的确认建立业务模型的工作主要包括：建立业务模型的工作主要包括：分析领域中的业务角色分析领域中的业务角色分析角色间的业务功能等关系分析角色间的业务功能等关系分析业务组织架构分析业务组织架构分析业务规则分析业务
43、规则分析业务实体分析业务实体分析业务事件分析业务事件分析以业务角色为主角的业务用例等；分析以业务角色为主角的业务用例等；以业务用例为实例，与用户进行沟通：以业务用例为实例，与用户进行沟通：需求是否被清楚地陈述？需求是否被清楚地陈述？存在错误的理解吗？存在错误的理解吗？需求的来源（人员、规章制度、文件）是否正确？需求的来源（人员、规章制度、文件）是否正确？需求的最终陈述是否得到用户最终责任人确认？需求的最终陈述是否得到用户最终责任人确认？问题问题 用户不知道他们需求什么或不知道如何表达直到开发人员把用户所描述的东西给他们，用户才认为知道自己要什么分析人员认为自己比用户更了解用户的需求解决方案解决
44、方案将用户当作领域专家来认识和感激，尝试一下其他沟通和启发技术尽早提供相互选择的启发技术：情节串联板、原型、角色换位等把分析人员放在用户的位置，试着换位一小时或一天解决用户和开发人员综合症解决用户和开发人员综合症用户讲故事介绍游戏规则输出结果幻灯片放映动画制作仿真演示交互演示现场演示被动式介绍被动式介绍主动式介绍主动式介绍交互式介绍交互式介绍需求诱导的方法（情节串联板）需求诱导的方法（情节串联板）原型开发复杂程度与成本需求获取过程需求管理的关注点需求获取过程需求管理的关注点步骤：步骤：1、发现和分析问题2、理解用户的需求3、定义系统（用例模型）4、管理范围（项目管理）方法：方法：采用业务建模和
45、系统建模的方法进行问题分析对与系统架构和系统行为有关的用例进行描述和定义目标：目标：p在问题定义上与用户达成共识p理解问题背后的根本原因p确定用户和项目干系人p定义问题解空间的边界p确定问题解决方案的约束和假设最终阶段完成标志：用户对系统目标的认可最终阶段完成标志：用户对系统目标的认可签字签字需求获取过程产品基线管理的关注点需求获取过程产品基线管理的关注点产品前景文件技术创新和突破产品特点客户：涉众和用例分析人员和专家的意见与公司其他产品的配套和一致性与对手的竞争性产品差异和优势开发团队的状况与产品的可持续性系统平台与兼容性公司目标与市场需求一个真一个真正伟大正伟大的产品的产品需求获取过程产品
46、路线管理的关注点需求获取过程产品路线管理的关注点V1.0V2.0V2.1V3.0V3.1新系统新系统 版本特性版本特性基本功能安保接口客户定义远程维护多平台支持中央控制单元户主客户控制开关05/0105/0705/0906/0106/03图例：图例：正在发行正在发行发布代码行发布代码行代码行修改代码行修改需求提取的最佳实践1.明确构想和范围明确构想和范围2.确立需求开发过程确立需求开发过程3.用户群分类用户群分类4.选定产品代表选定产品代表5.建立用户核心队伍建立用户核心队伍6.建立用例模型建立用例模型7.举办用例演示会举办用例演示会1.分析业务流程分析业务流程2.明确质量属性明确质量属性3.
47、检查问题报告检查问题报告4.重用需求重用需求用例常见错误1.1.无系统目标或边界无系统目标或边界2.2.无角色定位无角色定位3.3.用户界面细节过多用户界面细节过多4.4.目标层次太低目标层次太低5.5.目的与内容不一致目的与内容不一致6.6.含有设计内容含有设计内容7.7.过多的数据细节过多的数据细节“用例分析用例分析是当今消除需求不明确、不一致、不完整是当今消除需求不明确、不一致、不完整 的重要手段和关键技术的重要手段和关键技术”用例在用例在需求获取需求获取阶段的好处：阶段的好处：与传统的需求分析方法相比，用例书写简单、易于理解与传统的需求分析方法相比，用例书写简单、易于理解用例迫使开发人
48、员从系统设计时，就从用户的角度考虑问用例迫使开发人员从系统设计时，就从用户的角度考虑问题题用例使用户参与需求过程，帮助他们理解所建设的系统，用例使用户参与需求过程，帮助他们理解所建设的系统，并提供了一种交流和记录的工具并提供了一种交流和记录的工具用例给出了需求的情景，从而使人们理解需求的原因以及用例给出了需求的情景，从而使人们理解需求的原因以及系统是如何实现它的目标系统是如何实现它的目标大多数情况下，用例是开发人员写的，因此，他是理解这大多数情况下，用例是开发人员写的，因此，他是理解这个需求，也知道最终要对实现这个需求负责的个需求，也知道最终要对实现这个需求负责的用例在系统开发的其他阶段的好处
49、：用例在系统开发的其他阶段的好处：用例在分析阶段，也是一个关键的工具，它帮助我们理用例在分析阶段，也是一个关键的工具，它帮助我们理解系统需求做什么以及系统可能如何去做解系统需求做什么以及系统可能如何去做用例在设计和实现过程中，也是一个关键的工具，它降用例在设计和实现过程中，也是一个关键的工具，它降低了因需求表达不确切和不一致，导致系统开发错误的风低了因需求表达不确切和不一致，导致系统开发错误的风险险用例可以直接延伸到测试过程，这有利于确保系统真正用例可以直接延伸到测试过程，这有利于确保系统真正做了它应该做的事情做了它应该做的事情用例也是用户文档的输入，可以从用例开始，很方便地用例也是用户文档的
50、输入，可以从用例开始，很方便地组织用户文档的编写组织用户文档的编写用例在组织软件开发中的核心作用用例驱动模型到目前为止，我们完成了需求获取阶段的任务到目前为止，我们完成了需求获取阶段的任务通过采用用例的方法，建立了业务模型，使用户理解并确认系通过采用用例的方法，建立了业务模型，使用户理解并确认系统要做什么和不做什么统要做什么和不做什么3、从业务用例到测试用例 V V模模型型中中的的过过程程从从左左到到右右，描描述述了了基基本本的的开开发发过过程程和和测测试试行行为为。V V模模型型的的价价值值在在于于它它非非常常明明确确地地标标明明了了测测试试过过程程中中存存在在的的不不同同级级别别，并并且且