《需求分析用例图精品文稿.ppt》由会员分享，可在线阅读，更多相关《需求分析用例图精品文稿.ppt（84页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、需求分析用例图需求分析用例图第1页，本讲稿共84页-2-课程内容课程内容nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程第2页，本讲稿共84页-3-课程内容课程内容nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程第3页，本讲稿共84页-4-What Is the UML?nThe UML is a language fornVisualizingnSpecifyingnConstr
2、uctingnDocumenting the artifacts of a software-intensive systemUnified Modeling LanguageUnified Modeling Language（统一建模语言）是对象管理组（统一建模语言）是对象管理组（统一建模语言）是对象管理组（统一建模语言）是对象管理组织（织（织（织（OMGOMG）制定的一个）制定的一个）制定的一个）制定的一个通用通用通用通用的、的、的、的、可视化可视化可视化可视化的的建模语言建模语言建模语言建模语言标准，可以用标准，可以用标准，可以用标准，可以用来来来来可视化可视化可视化可视化（visual
3、izevisualize）、描述描述描述描述（specifyspecify）、）、）、）、构造构造构造构造（constructconstruct）和和和和文档化文档化文档化文档化（documentdocument）软件密集型系统的各种工件（）软件密集型系统的各种工件（）软件密集型系统的各种工件（）软件密集型系统的各种工件（artifactsartifacts，又译制品）又译制品）又译制品）又译制品）第4页，本讲稿共84页-5-UML诞生诞生工 业化标 准化统 一化分 散的各 部分公众反馈1997.11.171997.11.17 UML 1.1UML 1.1被被被被OMG OMG 接纳为标准接纳
4、为标准接纳为标准接纳为标准OOPSLA95 Unified Method 0.8 Booch93 OMT-21996.6和1996.10 UML 0.9&0.911997.9公布 UML 1.1 1997.1公布 UML 1.0合作伙伴意见 Booch91 OMT-1 其他方法 OOSEGrady Booch Jim Rumbaugh Ivar Jacobson第5页，本讲稿共84页-6-UML发展现状发展现状n目前通用的是目前通用的是UML 1.x版版n主要主要UML 1.3、UML 1.4n2003年年3月正式发布月正式发布UML 1.5nUML 2.0n2003年年6月月OMG采纳了采纳
5、了UML 2.0的的Superstructure的提案的提案n正式文本尚未发布正式文本尚未发布n第6页，本讲稿共84页-7-UML 9种图种图n类类 图：类以及类之间的相互关系图：类以及类之间的相互关系n对象图：对象以及对象之间相互关系对象图：对象以及对象之间相互关系n构件图：构件及其相互依赖关系构件图：构件及其相互依赖关系n部署图：构件在各节点上的部署部署图：构件在各节点上的部署n顺序图：强调时间顺序的交互图顺序图：强调时间顺序的交互图n协作图：强调对象协作的交互图协作图：强调对象协作的交互图n状态图：类所经历的各种状态状态图：类所经历的各种状态n活动图：对工作流建模活动图：对工作流建模n用
6、例图：需求捕获，测试依据用例图：需求捕获，测试依据结结构构行行为为用例图用例图用例图用例图静态图静态图静态图静态图实现图实现图实现图实现图交互图交互图交互图交互图行为图行为图行为图行为图第7页，本讲稿共84页-8-UML建模工具建模工具nIBM Rational Rose 2003nBorland Together 7.0nMicrosoft Visio 2003nSybase PowerDesigner 10nNetBeans UMLnn“非程序员杂志非程序员杂志”第第26到到30期期UML工具一览，工具一览，列出了约列出了约129个个UML开发工具开发工具第8页，本讲稿共84页-9-内容安
7、排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程第9页，本讲稿共84页认识问题认识问题认识问题认识问题分析问题分析问题分析问题分析问题解决问题解决问题解决问题解决问题最终用户最终用户最终用户最终用户(提出问题提出问题提出问题提出问题)开发团队开发团队开发团队开发团队(解决问题解决问题解决问题解决问题)以以以以用户用户用户用户的身份站在的身份站在的身份站在的身份站在用户用户用户用户的角的角的角的角度认识问题度认识问题度认识问题度认识问题获取需求获取需求获取需求获取需求用例建模技术
8、用例建模技术用例建模技术用例建模技术以以以以开发者开发者开发者开发者的身份站在的身份站在的身份站在的身份站在用户用户用户用户的角的角的角的角度分析问题度分析问题度分析问题度分析问题分析需求分析需求分析需求分析需求用例分析技术用例分析技术用例分析技术用例分析技术以以以以开发者开发者开发者开发者的身份站在的身份站在的身份站在的身份站在开发团开发团开发团开发团队队队队的角度分析问题的角度分析问题的角度分析问题的角度分析问题解决需求解决需求解决需求解决需求面向对象设计面向对象设计面向对象设计面向对象设计第10页，本讲稿共84页-11-需求需求建造建造“正确正确”的系统的系统n需求：系统必须满足的条件或
9、具备的能需求：系统必须满足的条件或具备的能力力n软件质量准则软件质量准则“FURPS”n功能性（功能性（Functionality）n可用性（可用性（Usability）n可靠性（可靠性（Reliability）n性能（性能（Performance）n可支持性（可支持性（Supportability）非功能性需求非功能性需求非功能性需求非功能性需求第11页，本讲稿共84页-12-内容安排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程第12页，本讲稿共84页-13-需求：饮料问题
10、需求：饮料问题n我要一瓶饮料我要一瓶饮料n差不多，但我要无糖饮料差不多，但我要无糖饮料n很好，不过我要绿茶的很好，不过我要绿茶的n啊，没有大瓶的啊，没有大瓶的大瓶的无糖绿茶饮料大瓶的无糖绿茶饮料难难捕捕获获，易易变变！第13页，本讲稿共84页-14-需求：如此脆弱需求：如此脆弱客户/用户的要求/想法/期望软件设计软件产品分析和设计编码和测试验 收没价值的软件需求补文档第14页，本讲稿共84页-15-需求：也需要开发需求：也需要开发客户/用户的要求/想法/期望软件设计软件产品开发编码和测试验收有价值的软件需求分析和设计第15页，本讲稿共84页-16-获取好的需求获取好的需求n需求收集包括五个关键
11、步骤需求收集包括五个关键步骤n找到可以帮助你理解这个系统的人找到可以帮助你理解这个系统的人n倾听这些相关人员的描述，并从他们的角度倾听这些相关人员的描述，并从他们的角度来理解系统来理解系统n利用一个容易理解的模型来描述用户希望如利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值何使用这个系统以及为他们提供的什么价值n详细地描述系统和客户以及系统和外部系统详细地描述系统和客户以及系统和外部系统之间的交互之间的交互n重构（重构（refactor）这个详细描述以保证它是）这个详细描述以保证它是可读且易懂的可读且易懂的第16页，本讲稿共84页-17-内容安排内容安排nUML概
12、述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程第17页，本讲稿共84页-18-需求问题：对策需求问题：对策难捕获难捕获难捕获难捕获易变易变易变易变从用户视角看问题从用户视角看问题从用户视角看问题从用户视角看问题合理的结构合理的结构合理的结构合理的结构用例用例用例用例第18页，本讲稿共84页-19-以用例为中心组织需求以用例为中心组织需求用例用例用例用例可用性可用性可用性可用性可靠性可靠性可靠性可靠性网络协议网络协议网络协议网络协议业务规则业务规则业务规则业务规则硬件接口硬件接口硬件接口硬件接口界
13、面约束界面约束界面约束界面约束性能性能性能性能第19页，本讲稿共84页-20-内容安排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程第20页，本讲稿共84页-21-基于用例的需求分析过程基于用例的需求分析过程n1.获取原始需求获取原始需求n2.开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n3 详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4 重构用例模型重构用例模型n4.
14、1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包第21页，本讲稿共84页-22-基于用例的需求分析过程基于用例的需求分析过程n n1.1.获取原始需求获取原始需求获取原始需求获取原始需求n2.开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n3.详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4.重构用例模型重构用例模型n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包第22页，本讲稿共84页-23-获取需求的技巧
15、获取需求的技巧技巧技巧描述描述实地观察实地观察直接观察个人工作的情况，以发现现存的实践方式和问题访谈访谈从个人处收集特定信息特定群体特定群体调查调查对一组人员进行调查，以便了解工作态度和共同看法问卷调查问卷调查收集详细数据和统计意义上比较重要的数据用户指导用户指导让最终用户告诉你，他们是如何操作系统的原型制作原型制作模拟一个无法直接测试的系统统计版本统计版本使用具有统计功能的应用程序来记录用户完成任务的方式行业知识行业知识收集和整理行业中的法律、法规，用户所使用的规章制度、操作规程等内容第23页，本讲稿共84页-24-获取需求：考勤卡应用程序获取需求：考勤卡应用程序初次访谈记录初次访谈记录初次
16、访谈记录初次访谈记录开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。第24页，本讲稿共84页-25-基于用例的需求分析过程基于用例的需求分析过程n1.获取原始
17、需求获取原始需求n n2.2.开发一个可以理解的需求开发一个可以理解的需求开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图：确定参与者和用例之间的关系构建用例图：确定参与者和用例之间的关系n3.详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4.重构用例模型重构用例模型n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包第25页，本讲稿共84页-26-相关术语相关术语场景场景场景场景：是用来描述用户和系统之间交互的顺序的步骤：是用来描述用户和系统之间交互的顺序的步
18、骤用例用例用例用例：是为了达到某一用户目标而组合在一起的一组场景：是为了达到某一用户目标而组合在一起的一组场景用例图用例图用例图用例图：用来显示在系统（或其它实体）内的用例与系统参与：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系者之间的关系主要使用场合：需求获取、定义、分析主要使用场合：需求获取、定义、分析主要使用场合：需求获取、定义、分析主要使用场合：需求获取、定义、分析用例模型用例模型用例模型用例模型：是系统既定功能及系统环境的模型，并作为客户和开发：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。人员之间的契约。用
19、例模型用作分析、设计和测试活动的基本输入。第26页，本讲稿共84页-27-用例图元素用例图元素参与者用例系统边界直接关联扩展包含泛化注释体注释连接关联第27页，本讲稿共84页-28-2.1 识别参与者识别参与者n参与者，参与者，Actorn关键词：关键词：边界边界n参与者：在参与者：在系统之外系统之外，透过，透过系统边界系统边界与系统与系统进行进行有意义交互有意义交互的的任何事物任何事物第28页，本讲稿共84页-29-参与者要点参与者要点n系统外系统外n参与者代表在系统边界之外的真实事物，并参与者代表在系统边界之外的真实事物，并不是系统的成分不是系统的成分n系统边界系统边界n参与者透过系统边界
20、直接与系统交互，参与参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定者的确定代表系统边界的确定n有意义的交互有意义的交互n任何事物任何事物n人、外系统、外部因素、时间人、外系统、外部因素、时间第29页，本讲稿共84页-30-识别参与者：考勤卡系统识别参与者：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时的雇员雇员雇员雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条
21、目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我（业务经理）（业务经理）（业务经理）（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。第30页，本讲稿共84页-31-2.2 识别用例识别用例n关键词：价值关键词：价值n定义定义n用例实例是用例实例是系统执行系统执行的的一系列动作一系列动作，这些动，这些动作将生成特定作将生成特定参与者可观测参与者可观测的的结果值结果值n一个用例定义一个用例定义一组用例实例一组用例实例n简洁：参与者简洁：参与者使用系统使用系统达到目标达到目标第31页，本讲稿共84页
22、-32-识别用例：考勤卡系统识别用例：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时的雇员雇员雇员雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码管理收费项目代码管理收费项目代码管理收费项目代码？客客
23、 户户：嗯，必要的时候由我（业务经理）（业务经理）（业务经理）（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。第32页，本讲稿共84页-33-用例要点用例要点n可观测可观测用例止于系统边界用例止于系统边界n结果值结果值用例是有意义的目标用例是有意义的目标n系统执行系统执行结果值由系统生成结果值由系统生成n由参与者观测由参与者观测业务语言、用户观点业务语言、用户观点n一组用例实例一组用例实例用例的粒度用例的粒度第33页，本讲稿共84页-34-要点：用例止于系统边界要点：用例止于系统边界描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动描
24、述交互，而不是内在的系统活动第34页，本讲稿共84页-35-要点：有要点：有意义意义的目标的目标第35页，本讲稿共84页-36-要点：结果值由系统生成要点：结果值由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成第36页，本讲稿共84页-37-要点：业务语言而非技术语言要点：业务语言而非技术语言n用户词汇，而不是技术词汇用户词汇，而不是技术词汇n如：发票，商品，洗衣机如：发票，商品，洗衣机n而不是：记录，字段，而不是：记录，字段，COM，C+等等第37页，本讲稿共84页-38-要点：用户观点而非系统观点要点：用户观点而非系统观点用
25、户观点用户观点用户观点用户观点系统观点系统观点系统观点系统观点第38页，本讲稿共84页-39-用例用例 VS.功能功能n呼叫某人呼叫某人n接听电话接听电话n发送短信发送短信n记住电话号码记住电话号码nn传输传输/接收接收n电源电源/基站基站n输入输出（显示、键盘）输入输出（显示、键盘）n电话簿管理电话簿管理n用户观点用户观点用户观点用户观点系统观点系统观点系统观点系统观点第39页，本讲稿共84页-40-用例的命名用例的命名n执行者视角：执行者视角：n一个简单、描述性的名称，一般为带有动作性的词。一个简单、描述性的名称，一般为带有动作性的词。第40页，本讲稿共84页-41-要点：用例粒度要点：用
26、例粒度-1n用例要有路径，路径要有步骤；而这一用例要有路径，路径要有步骤；而这一切都是可观测的切都是可观测的n最常犯错误：粒度过细，陷入功能分解最常犯错误：粒度过细，陷入功能分解n过细的粒度，一般都会导致技术语言的描述，过细的粒度，一般都会导致技术语言的描述，而不再是业务语言而不再是业务语言第41页，本讲稿共84页-42-用例粒度用例粒度-2n把步骤当用例把步骤当用例n把系统活动当用例把系统活动当用例第42页，本讲稿共84页-43-用例粒度用例粒度-3n“四轮马车四轮马车”nC(Create)R(Read)U(Update)D(Delete)n所有业务最终对会成为所有业务最终对会成为CRUD？
27、nCRUD能为能为Actor提供价值？提供价值？nCRUD掩盖业务，掩盖业务，锐变成关系锐变成关系数据库的建模：数据库的建模：n“系统就是数据的增删改查系统就是数据的增删改查”n关心数据的存储和维护，反关心数据的存储和维护，反而忽略了用户的目的而忽略了用户的目的第43页，本讲稿共84页-44-用例粒度用例粒度-4n如果确实是如果确实是CRUD？n如果如果CRUD不涉及复杂的交互，一个用例不涉及复杂的交互，一个用例“管理管理”即即可可n不管是不管是C、R、U、D，都是为了完成，都是为了完成“管理管理”目标目标n甚至很多种的基本数据管理都可以用一个用例表示甚至很多种的基本数据管理都可以用一个用例表
28、示第44页，本讲稿共84页-45-用例粒度用例粒度-5n灵活处理灵活处理CRUD可以把包含复杂交互的路径独立出去形成用例可以把包含复杂交互的路径独立出去形成用例可以把包含复杂交互的路径独立出去形成用例可以把包含复杂交互的路径独立出去形成用例第45页，本讲稿共84页-46-思考：识别用例思考：识别用例-1nEmail客户端（如：客户端（如：outlook express），），A在北京发邮件给上海的在北京发邮件给上海的B，系统提醒，系统提醒B你有你有“新新邮件邮件”，B收邮件收邮件错误第46页，本讲稿共84页-47-思考：识别用例思考：识别用例-2第47页，本讲稿共84页-48-2.3 构建用例
29、图构建用例图第48页，本讲稿共84页-49-基于用例的需求分析过程基于用例的需求分析过程n1.获取原始需求获取原始需求n2.开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n n3.3.详细、完整地描述需求详细、完整地描述需求详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4.重构用例模型重构用例模型(高级用例建模方法高级用例建模方法高级用例建模方法高级用例建模方法)n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包第49页，本讲稿共84页-50-进行
30、用例阐述：写用例规约进行用例阐述：写用例规约n用例规约用例规约(Use case Specification)：更进一步的精度更进一步的精度n用例文档的核心，作为用例文档的总图用例文档的核心，作为用例文档的总图n进一步的精度：有层次的文档进一步的精度：有层次的文档n文档中每一句话都有其价值文档中每一句话都有其价值用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉第50页，本讲稿共84页-51-谁来写用例文档谁来写用例文档n最完美：业务人员接受训练，写出优美最完美：业务人员接受训练，写出优美的用
31、例文档的用例文档n n最现实：业务人员提供素材，开发人员最现实：业务人员提供素材，开发人员写用例文档写用例文档n最糟糕：业务人员不管，完全由开发人最糟糕：业务人员不管，完全由开发人员杜撰员杜撰第51页，本讲稿共84页-52-用例规约组成用例规约组成n用例名称用例名称n用例标识用例标识n涉及的参与者涉及的参与者n描述描述n用例的规格说明用例的规格说明n前置条件前置条件 PreConditionsn后置条件后置条件 PostConditionsn正常事件流正常事件流 Flow of eventsn备选事件流备选事件流 Alternate flown其它其它n非功能需求、设计约束、尚存在的问题非功能
32、需求、设计约束、尚存在的问题第52页，本讲稿共84页-53-前置、后置条件前置、后置条件-1n前置条件约束在用例开始前系前置条件约束在用例开始前系统的状态统的状态n把它们看做是看门人，它阻止参与把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件者触发该用例直到满足所有条件n说明在用例触发之前什么必须为说明在用例触发之前什么必须为真真n后置条件约束用例执行后系统后置条件约束用例执行后系统的状态的状态n用例执行后什么必须为真用例执行后什么必须为真n对于有多个事件流的用例，则对于有多个事件流的用例，则应该有多个后置条件应该有多个后置条件第53页，本讲稿共84页-54-前置、后置条件前置、后置
33、条件-2n某些用例依赖于其他用例某些用例依赖于其他用例n一个用例在离开系统时，可能是另一个用例一个用例在离开系统时，可能是另一个用例的前置条件（例如：的前置条件（例如：“登录登录”和和“管理系统管理系统”）n有助于识别漏掉的用例有助于识别漏掉的用例n如果一个用例的前置条件不能有执行其他用如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：例满足，可能意味着丢失了用例（例如：“管理订单管理订单”却没有却没有“登录登录”用例）用例）第54页，本讲稿共84页-55-用例交互四部曲用例交互四部曲-事件流事件流1.动 作4.回 应2.改变3.验证系 统写：可观测的、体现客户利益的文
34、字写：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字第55页，本讲稿共84页-56-事件流描述要点事件流描述要点n1.只书写只书写“可观测可观测”的的n2.使用主动语句使用主动语句n3.句子必须以参与者或系统作为主语句子必须以参与者或系统作为主语n4.不要涉及界面细节不要涉及界面细节n5.分支和循环分支和循环第56页，本讲稿共84页-57-要点要点1：只写：只写“可观测可观测”的的n系统通过系统通过ADO建立数据库连接，传送建立数据库连接，传送SQL查询语句，从查询语句，从“商品表商品表”查询商品查询商品的详细信息的详细信息n系统按照查询条件搜索商
35、品的详细信息系统按照查询条件搜索商品的详细信息第57页，本讲稿共84页-58-要点要点2：主动语句：主动语句n用户输入搜索条件，页面显示系统搜索用户输入搜索条件，页面显示系统搜索的结果的结果n出纳员出纳员n系统系统第58页，本讲稿共84页-59-要点要点3：以参与者或系统作主语：以参与者或系统作主语n参与者参与者n系统系统n出纳员接收顾客的付款出纳员接收顾客的付款顾客的付款数可能顾客的付款数可能高于商品总额高于商品总额n出纳员录入顾客所付的现金总额出纳员录入顾客所付的现金总额n系统显示出应找还给顾客的余额，打印付款系统显示出应找还给顾客的余额，打印付款收据收据第59页，本讲稿共84页-60-要
36、点要点4：不涉及界面细节：不涉及界面细节n会员从下拉框中选择类别会员从下拉框中选择类别n会员在相应文本框中输入查询条件会员在相应文本框中输入查询条件n会员点击会员点击“确定确定”按钮按钮第60页，本讲稿共84页-61-要点要点5：分支和循环：分支和循环n分支：放到扩展路径分支：放到扩展路径n参与者的选择参与者的选择n另一条成功线路另一条成功线路n系统进行验证系统进行验证nn循环：直接描述循环：直接描述第61页，本讲稿共84页-62-用例规约：记录时间用例规约：记录时间UC01：“Record Time”用例文档用例文档n用例名称：用例名称：Record Time（记录时间）（记录时间）n用例标
37、识用例标识：UC01n涉及的参与者：涉及的参与者：雇员、系统管理员n描述：描述：雇员利用“Record Time”用例来登记他们的工时 系统管理员用这个用例为任何雇员登记时间n前置条件：前置条件：用户必须已经登录到这个系统n后置条件：后置条件：系统将雇员的工时正确的记录到数据库中第62页，本讲稿共84页-63-用例规约：记录时间用例规约：记录时间(续续)n正常事件流（Basic Flow）：1.雇员查看当前时间之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并
38、在以后的视图中看到这个数据。n备选事件流（Alternative Flow）1：雇员更改他的时间1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目；3.雇员改变工时；4.在视图中更新这个信息，并在以后的视图中都可以看到。第63页，本讲稿共84页-64-用例规约：记录时间用例规约：记录时间(续续)n非功能需求：非功能需求：无n设计约束：设计约束：无n部署约束：部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙n未解决的问题未解决的问题n雇员是否可以在以前的考勤卡上输入和更改时间n雇员是否可以在以后的考勤卡上输入和更
39、改时间，例如，在休假之前？第64页，本讲稿共84页-65-活动图活动图-简述用例流程简述用例流程第65页，本讲稿共84页-66-活动图活动图Activity Diagramn通过动作来组织，主要用于描述某一方法、机制通过动作来组织，主要用于描述某一方法、机制或或用例用例用例用例的的内部行为内部行为内部行为内部行为n n活动活动活动活动（ActivitiesActivities）,which are steps in the workflow.,which are steps in the workflow.n n动作动作动作动作（ActionsActions）,which are steps
40、within an,which are steps within an activity.Actions may occur when entering the activity.Actions may occur when entering the activity,exiting the activity,while inside the activity,exiting the activity,while inside the activity,or upon a specific event.activity,or upon a specific event.n n转移（转移（转移（
41、转移（TransitionsTransitions）、决策（）、决策（）、决策（）、决策（DecisionDecision）、同步条）、同步条）、同步条）、同步条（SynchronizationsSynchronizations）n n业务对象（业务对象（业务对象（业务对象（Business objectsBusiness objects）n n起始状态（起始状态（起始状态（起始状态（The start stateThe start state）、终止状态（）、终止状态（）、终止状态（）、终止状态（The end The end statestate）第66页，本讲稿共84页-67-活动图活动
42、图-推荐的使用场合推荐的使用场合n n分析用例：分析用例：分析用例：分析用例：能直观清晰地分析用例，了解应当采取哪能直观清晰地分析用例，了解应当采取哪些动作以及这些动作之间的依赖关系。一张完整的活些动作以及这些动作之间的依赖关系。一张完整的活动图是所有用例的集成图动图是所有用例的集成图n理解牵涉理解牵涉多个用例的工作流：多个用例的工作流：多个用例的工作流：多个用例的工作流：在难于区分不同用例而在难于区分不同用例而对整个系统的工作过程又十分清楚时，可以先构造活对整个系统的工作过程又十分清楚时，可以先构造活动图，然后用切片技术派生用例图动图，然后用切片技术派生用例图n n处理多线程处理多线程处理多
43、线程处理多线程应用：采用应用：采用“分层抽象，逐步细化分层抽象，逐步细化”的的原则描述多线程原则描述多线程第67页，本讲稿共84页-68-基于用例的需求分析过程基于用例的需求分析过程n1.获取原始需求获取原始需求n2.开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n3 详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n n4 4 重构用例模型重构用例模型重构用例模型重构用例模型(高级用例建模方法高级用例建模方法高级用例建模方法高级用例建模方法)n4.1 识别用例间的关系识别用例间的关系n4.2
44、 对用例进行组织和分包对用例进行组织和分包第68页，本讲稿共84页-69-4.1 用例关系用例关系ExtendIncludeGeneralization第69页，本讲稿共84页-70-通过关系整理文档通过关系整理文档nExtendn分离扩展路径分离扩展路径nIncluden提取公共步骤，便于复用提取公共步骤，便于复用nGeneralizationn同一业务目的的不同技术实现同一业务目的的不同技术实现第70页，本讲稿共84页-71-扩展关系扩展关系n n基用例路径本身是完整的基用例路径本身是完整的基用例路径本身是完整的基用例路径本身是完整的，可能是一条扩展路，可能是一条扩展路径径n扩展路径步骤多
45、扩展路径步骤多n扩展路径内部还有扩展点扩展之扩展扩展路径内部还有扩展点扩展之扩展第71页，本讲稿共84页-72-扩展关系误用扩展关系误用第72页，本讲稿共84页-73-识别扩展点思路识别扩展点思路n执行者的选择执行者的选择n系统验证系统验证n步骤失败步骤失败n必须是系统能感知的必须是系统能感知的必须是系统能感知的必须是系统能感知的第73页，本讲稿共84页-74-包含关系包含关系n某些步骤在多个用例重复出现，且单独某些步骤在多个用例重复出现，且单独形成价值形成价值n用例步骤较多时，可用用例步骤较多时，可用Include简化（慎简化（慎用）用）第74页，本讲稿共84页-75-包含关系误用包含关系误
46、用第75页，本讲稿共84页-76-泛化关系泛化关系n同一业务目的不同技术实现：同一业务目的不同技术实现：n一个用例可以特化另一个更普通用例（更普通用例泛化特殊一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）用例）nUML 1.5:用例间的泛化关系表明子用例包含父用例中用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系例中所有的关系第76页，本讲稿共84页-77-用例关系：扩展用例关系：扩展 VS.泛化泛化采用不同关系，文档结构不同采用不同关系，文档结构不同采用不同关系，文档结构不同采用不同关
47、系，文档结构不同第77页，本讲稿共84页-78-重构后的用例图：考勤卡系统重构后的用例图：考勤卡系统第78页，本讲稿共84页-79-4.2 为什么要对用例进行分级为什么要对用例进行分级n用例和开发周期用例和开发周期n开发周期是围绕用例的需求来组织的开发周期是围绕用例的需求来组织的n一个开发周期要被指派一个到多个用例，如果完全一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例那就采用简化版本的用例用例A-简化版本用例A-完整版本用例B用例C第79页，本讲稿共84页-80-用例分级原则用例分
48、级原则n用例分级的一个基本原则用例分级的一个基本原则n高级别的用例是那些对系统核心体系结构影响最大的高级别的用例是那些对系统核心体系结构影响最大的用例用例n提高用例级别的特性：提高用例级别的特性：na.对体系结构设计有重要影响的用例，如在领域层中增加多对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例个类的用例或者需要持久化的用例nb.不需要花费很多努力就可以从中获得重要信息和线不需要花费很多努力就可以从中获得重要信息和线索的那些用例索的那些用例nc.含有开发风险、时间紧迫或功能复杂的用例含有开发风险、时间紧迫或功能复杂的用例nd.涉及到重要技术研究或者新技术和高
49、风险的用例涉及到重要技术研究或者新技术和高风险的用例ne.代表主要的在线业务流程的用例代表主要的在线业务流程的用例nf.能产生直接经济效益或者降低成本的用例能产生直接经济效益或者降低成本的用例第80页，本讲稿共84页-81-用例分级实施策略用例分级实施策略n可以使用一个简单的但是有些不精确的分级方可以使用一个简单的但是有些不精确的分级方法，如将用例划分成高、中、低三个等级法，如将用例划分成高、中、低三个等级第81页，本讲稿共84页-82-用例的组织用例的组织n对用例进行分包对用例进行分包n让用例图能够更为清晰地表现出系统的业务逻辑关系和层次让用例图能够更为清晰地表现出系统的业务逻辑关系和层次n
50、对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式n常见的分包方式常见的分包方式n按参与者分包按参与者分包n按主题分包按主题分包n按开发团队分包按开发团队分包n按发布情况分包按发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包第82页，本讲稿共84页-83-补充需求规约补充需求规约Supplementary Specificationn补充需求规约补充需求规约S