需求分析——UML用例图STUD

1、-2-课程内容课程内容nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程-3-课程内容课程内容nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程-4-What Is the UML?nThe UML is a language fornVisualizingnSpecifyingnConstructingnDocumenting the artifacts of a software-

2、intensive system的的-5-UML诞生诞生工业工业化化标准标准化化统一统一化化分散分散的的各部各部分分公公众众反反馈馈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-6-UML发展现状发展现状n目前通用的是目前通用的是UML 1.x版版n主要主要UML 1

3、.3、UML 1.4n2003年年3月正式发布月正式发布UML 1.5nUML 2.0n2003年年6月月OMG采纳了采纳了UML 2.0的的Superstructure的提案的提案n正式文本尚未发布正式文本尚未发布n-7-UML 9种图种图n类类 图：类以及类之间的相互关系图：类以及类之间的相互关系n对象图：对象以及对象之间相互关系对象图：对象以及对象之间相互关系n构件图：构件及其相互依赖关系构件图：构件及其相互依赖关系n部署图：构件在各节点上的部署部署图：构件在各节点上的部署n顺序图：强调时间顺序的交互图顺序图：强调时间顺序的交互图n协作图：强调对象协作的交互图协作图：强调对象协作的交互图

4、n状态图：类所经历的各种状态状态图：类所经历的各种状态n活动图：对工作流建模活动图：对工作流建模n用例图：需求捕获，测试依据用例图：需求捕获，测试依据-8-UML建模工具建模工具nIBM Rational Rose 2003nBorland Together 7.0nMicrosoft Visio 2003nSybase PowerDesigner 10nNetBeans UMLnn“非程序员杂志非程序员杂志”第第26到到30期期UML工具一工具一览，列出了约览，列出了约129个个UML开发工具开发工具-9-内容安排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n

5、以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程-11-需求需求建造建造“正确正确”的系统的系统n需求：系统必须满足的条件或具备的能需求：系统必须满足的条件或具备的能力力n软件质量准则软件质量准则“FURPS”n功能性（功能性（Functionality）n可用性（可用性（Usability）n可靠性（可靠性（Reliability）n性能（性能（Performance）n可支持性（可支持性（Supportability）-12-内容安排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n

6、基于用例的需求分析过程基于用例的需求分析过程-13-需求：饮料问题需求：饮料问题n我要一瓶饮料我要一瓶饮料n差不多，但我要无糖饮料差不多，但我要无糖饮料n很好，不过我要绿茶的很好，不过我要绿茶的n啊，没有大瓶的啊，没有大瓶的-14-需求：如此脆弱需求：如此脆弱客户客户/用户的要用户的要求求/想法想法/期望期望软件设计软件设计软件产品软件产品分析和设计分析和设计编码和测试编码和测试验验 收收没价值的没价值的软件需求软件需求补文档补文档-15-需求：也需要开发需求：也需要开发客户客户/用户的要用户的要求求/想法想法/期望期望软件设计软件设计软件产品软件产品开发开发编码和测试编码和测试验收验收有价值

7、的有价值的软件需求软件需求分析和设计分析和设计-16-获取好的需求获取好的需求n需求收集包括五个关键步骤需求收集包括五个关键步骤n找到可以帮助你理解这个系统的人找到可以帮助你理解这个系统的人n倾听这些相关人员的描述，并从他们的角度倾听这些相关人员的描述，并从他们的角度来理解系统来理解系统n利用一个容易理解的模型来描述用户希望如利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值何使用这个系统以及为他们提供的什么价值n详细地描述系统和客户以及系统和外部系统详细地描述系统和客户以及系统和外部系统之间的交互之间的交互n重构（重构（refactor）这个详细描述以保证它是）这个

8、详细描述以保证它是可读且易懂的可读且易懂的-17-内容安排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程-18-需求问题：对策需求问题：对策-19-以用例为中心组织需求以用例为中心组织需求-20-内容安排内容安排nUML概述概述n理解需求理解需求n需求，难在何处？需求，难在何处？n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程基于用例的需求分析过程-21-基于用例的需求分析过程基于用例的需求分析过程n1. 获取原始需求获取原始需求n2. 开发一个可以理解的需求

9、开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n3 详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4 重构用例模型重构用例模型n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包-22-基于用例的需求分析过程基于用例的需求分析过程n2. 开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n3. 详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4. 重构用例模型重构用例模型n

10、4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包-23-获取需求的技巧获取需求的技巧直接观察个人工作的情况，以发现现存的实践方式和问题直接观察个人工作的情况，以发现现存的实践方式和问题从个人处收集特定信息从个人处收集特定信息对一组人员进行调查，以便了解工作态度和共同看法对一组人员进行调查，以便了解工作态度和共同看法收集详细数据和统计意义上比较重要的数据收集详细数据和统计意义上比较重要的数据让最终用户告诉你，他们是如何操作系统的让最终用户告诉你，他们是如何操作系统的模拟一个无法直接测试的系统模拟一个无法直接测试的系统使用具有统计功能的应用程序来记录用户完

11、成任务的方式使用具有统计功能的应用程序来记录用户完成任务的方式收集和整理行业中的法律、法规，用户所使用的规章制度、操收集和整理行业中的法律、法规，用户所使用的规章制度、操作规程等内容作规程等内容-24-获取需求：考勤卡应用程序获取需求：考勤卡应用程序开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可

12、以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。-25-基于用例的需求分析过程基于用例的需求分析过程n1. 获取原始需求获取原始需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图：确定参与者和用例之间的关系构建用例图：确定参与者和用例之间的关系n3. 详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4. 重构用例模型重构用例模型n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包-26-相关术语相关术语：是用来描述

13、用户和系统之间交互的顺序的步骤：是用来描述用户和系统之间交互的顺序的步骤：是为了达到某一用户目标而组合在一起的一组场景：是为了达到某一用户目标而组合在一起的一组场景：用来显示在系统（或其它实体）内的用例与系统参：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系与者之间的关系：是系统既定功能及系统环境的模型，并作为客户：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。动的基本输入。-27-用例图元素用例图元素参与者参与者用例用例系统边界系统边界直接直接关联关联扩展扩展包含包含

14、泛化泛化注释体注释体注释连接注释连接关联关联-28-2.1 识别参与者识别参与者n参与者，参与者，Actorn关键词：关键词：边界边界n参与者：在参与者：在系统之外系统之外，透过，透过系统边界系统边界与系统与系统进行进行有意义交互有意义交互的的任何事物任何事物-29-参与者要点参与者要点n系统外系统外n参与者代表在系统边界之外的真实事物，并参与者代表在系统边界之外的真实事物，并不是系统的成分不是系统的成分n系统边界系统边界n参与者透过系统边界参与者透过系统边界直接直接与系统交互，参与与系统交互，参与者的确定代表者的确定代表系统边界系统边界的确定的确定n有意义的交互有意义的交互n任何事物任何事物

15、n人、外系统、外部因素、时间人、外系统、外部因素、时间-30-识别参与者：考勤卡系统识别参与者：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时的开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。Empl

16、oyeeAdministrative User-31-2.2 识别用例识别用例n关键词：价值关键词：价值n定义定义n用例实例是用例实例是系统执行系统执行的的一系列动作一系列动作，这些动，这些动作将生成特定作将生成特定参与者可观测参与者可观测的的结果值结果值n一个用例定义一个用例定义一组用例实例一组用例实例n简洁：参与者简洁：参与者使用系统使用系统达到目标达到目标-32-识别用例：考勤卡系统识别用例：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来的开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后

17、用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来？客客 户户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。Record TimeCreate Charge Code-33-用例要点用例要点n可观测可观测用例止于系统边界用例止于系统边界n结果值结果值用例是有意义的目标用例是有意义的目标n系统执行系统执行结果值由系统生成结果值由系统生成n由参与者观测由参与者观测业务语言、用户观点业务语言、用户观点n一组用例实例一组用例实例用例的粒度用例的粒度-34-要

18、点：用例止于系统边界要点：用例止于系统边界-35-要点：有要点：有意义意义的目标的目标?设定查询条件?会员?选择零件?会员?检索零件-36-要点：结果值由系统生成要点：结果值由系统生成出纳员吃饭-37-要点：业务语言而非技术语言要点：业务语言而非技术语言n用户词汇，而不是技术词汇用户词汇，而不是技术词汇n如：发票，商品，洗衣机如：发票，商品，洗衣机n而不是：记录，字段，而不是：记录，字段，COM，C+等等-38-要点：用户观点而非系统观点要点：用户观点而非系统观点?订票?旅客?查看今日航班?处理订票?旅客?显示今日航班-39-用例用例 VS. 功能功能呼叫某人呼叫某人接听电话接听电话发送短信发

19、送短信记住电话号码记住电话号码传输传输/接收接收电源电源/基站基站输入输出（显示、键盘）输入输出（显示、键盘）电话簿管理电话簿管理-40-用例的命名用例的命名n执行者视角：执行者视角：n一个简单、描述性的名称，一般为带有动作性的词。一个简单、描述性的名称，一般为带有动作性的词。 顾客购买商品信用卡支付-41-要点：用例粒度要点：用例粒度-1n用例要有路径，路径要有步骤；而这一用例要有路径，路径要有步骤；而这一切都是可观测的切都是可观测的n最常犯错误：粒度过细，陷入功能分解最常犯错误：粒度过细，陷入功能分解n过细的粒度，一般都会导致技术语言的描述，过细的粒度，一般都会导致技术语言的描述，而不再是

20、业务语言而不再是业务语言-42-用例粒度用例粒度-2n把步骤当用例把步骤当用例n把系统活动当用例把系统活动当用例?会员?输入用户名?验证用户名和密码?会员?登录?查询订单建立数据库连接执行SQL语句-43-用例粒度用例粒度-3n“四轮马车四轮马车”nC(Create)R(Read)U(Update)D(Delete)n所有业务最终对会成为所有业务最终对会成为CRUD？nCRUD能为能为Actor提供价提供价值？值？nCRUD掩盖业务，掩盖业务，锐变成锐变成关系数据库的建模：关系数据库的建模：n“系统就是数据的增删系统就是数据的增删改查改查”n关心数据的存储和维护，关心数据的存储和维护，反而忽略

21、了用户的目的反而忽略了用户的目的?删除用户?修改用户?增加用户?管理员?查询用户-44-用例粒度用例粒度-4n如果确实是如果确实是CRUD？n如果如果CRUD不涉及复杂的交互，一个用例不涉及复杂的交互，一个用例“管理管理”即可即可n不管是不管是C、R、U、D，都是为了完成，都是为了完成“管理管理”目目标标n甚至很多种的基本数据管理都可以用一个用例表甚至很多种的基本数据管理都可以用一个用例表示示?管理员?管理用户-45-用例粒度用例粒度-5n灵活处理灵活处理CRUD?管理员?管理用户?增加用户?-46-思考：识别用例思考：识别用例-1nEmail客户端（如：客户端（如：outlook expre

22、ss），），A在北京发邮件给上海的在北京发邮件给上海的B，系统提醒，系统提醒B你有你有“新邮件新邮件”，B收邮件收邮件收件人发件人发邮件收邮件邮件系统提醒新邮件错误错误-47-思考：识别用例思考：识别用例-2提醒新邮件发邮件用户收邮件时间-48-2.3 构建用例图构建用例图Administrative UserCreate Charge CodeBilling SystemExport Time EntriesEmployeeRecord TimeCreate Employee-49-基于用例的需求分析过程基于用例的需求分析过程n1. 获取原始需求获取原始需求n2. 开发一个可以理解的需求开发

23、一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n进行用例阐述进行用例阐述n4.重构用例模型重构用例模型()n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包-50-进行用例阐述：写用例规约进行用例阐述：写用例规约n用例规约用例规约(Use case Specification) ：更进一步的精度更进一步的精度n用例文档的核心，作为用例文档的总图用例文档的核心，作为用例文档的总图n进一步的精度：有层次的文档进一步的精度：有层次的文档n文档中每一句话都有其价值文档中每一句话都有其价值-51-谁来写用

24、例文档谁来写用例文档n最完美：业务人员接受训练，写出优美最完美：业务人员接受训练，写出优美的用例文档的用例文档n最糟糕：业务人员不管，完全由开发人最糟糕：业务人员不管，完全由开发人员杜撰员杜撰-52-用例规约组成用例规约组成n用例名称用例名称n用例标识用例标识n涉及的参与者涉及的参与者n描述描述n用例的规格说明用例的规格说明n前置条件前置条件 PreConditionsn后置条件后置条件 PostConditionsn正常事件流正常事件流 Flow of eventsn备选事件流备选事件流 Alternate flown其它其它n非功能需求、设计约束、尚存在的问题非功能需求、设计约束、尚存在的

25、问题-53-前置、后置条件前置、后置条件-1n前置条件约束在用例开始前前置条件约束在用例开始前系统的状态系统的状态n把它们看做是看门人，它阻把它们看做是看门人，它阻止参与者触发该用例直到满止参与者触发该用例直到满足所有条件足所有条件n说明在用例触发之前什么必说明在用例触发之前什么必须为真须为真n后置条件约束用例执行后系后置条件约束用例执行后系统的状态统的状态n用例执行后什么必须为真用例执行后什么必须为真n对于有多个事件流的用例，对于有多个事件流的用例，则应该有多个后置条件则应该有多个后置条件-54-前置、后置条件前置、后置条件-2n某些用例依赖于其他用例某些用例依赖于其他用例n一个用例在离开系

26、统时，可能是另一个用例一个用例在离开系统时，可能是另一个用例的前置条件（例如：的前置条件（例如：“登录登录”和和“管理系管理系统统”）n有助于识别漏掉的用例有助于识别漏掉的用例n如果一个用例的前置条件不能有执行其他用如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：例满足，可能意味着丢失了用例（例如：“管理订单管理订单”却没有却没有“登录登录”用例）用例）-55-用例交互四部曲用例交互四部曲-事件流事件流1. 动动 作作4. 回回 应应2.改变改变3.验证验证系系 统统-56-事件流描述要点事件流描述要点n1.只书写只书写“可观测可观测”的的n2.使用主动语句使用主动语

27、句n3.句子必须以参与者或系统作为主语句子必须以参与者或系统作为主语n4.不要涉及界面细节不要涉及界面细节n5.分支和循环分支和循环-57-要点要点1：只写：只写“可观测可观测”的的n系统通过系统通过ADO建立数据库连接，传送建立数据库连接，传送SQL查询语句，从查询语句，从“商品表商品表”查询商品查询商品的详细信息的详细信息n系统按照查询条件搜索商品的详细信息系统按照查询条件搜索商品的详细信息-58-要点要点2：主动语句：主动语句n用户输入搜索条件，页面显示系统搜索用户输入搜索条件，页面显示系统搜索的结果的结果n出纳员出纳员n系统系统-59-要点要点3：以参与者或系统作主语：以参与者或系统作

28、主语n参与者参与者n系统系统n出纳员接收顾客的付款出纳员接收顾客的付款顾客的付款数可能顾客的付款数可能高于商品总额高于商品总额n出纳员录入顾客所付的现金总额出纳员录入顾客所付的现金总额n系统显示出应找还给顾客的余额，打印付款系统显示出应找还给顾客的余额，打印付款收据收据-60-要点要点4：不涉及界面细节：不涉及界面细节n会员从下拉框中选择类别会员从下拉框中选择类别n会员在相应文本框中输入查询条件会员在相应文本框中输入查询条件n会员点击会员点击“确定确定”按钮按钮-61-要点要点5：分支和循环：分支和循环n分支：放到扩展路径分支：放到扩展路径n参与者的选择参与者的选择n另一条成功线路另一条成功线

29、路n系统进行验证系统进行验证nn循环：直接描述循环：直接描述-62-用例规约：记录时间用例规约：记录时间UC01：“Record Time”用例文档用例文档n用例名称：用例名称：Record Time（记录时间）（记录时间）n用例标识用例标识：UC01n涉及的参与者：涉及的参与者：雇员、系统管理员n描述：描述：雇员利用“Record Time”用例来登记他们的工时 系统管理员用这个用例为任何雇员登记时间n前置条件：前置条件：用户必须已经登录到这个系统n后置条件：后置条件：系统将雇员的工时正确的记录到数据库中-63-用例规约：记录时间用例规约：记录时间(续续)n正常事件流（正常事件流（Basic

30、 Flow）：）：1.雇员查看当前时间之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。n备选事件流（备选事件流（Alternative Flow）1：雇员更改他的时间雇员更改他的时间1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目；3.雇员改变工时；4.在视图中更新这个信息，并在以后的视图中都可以看到。-64-用例规约：记录时间用例规约：记录时间(续续)n非功能需求：非功能需求：无n设计约束：设计约束：无n部署约束：

31、部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙n未解决的问题未解决的问题雇员是否可以在以前的考勤卡上输入和更改时间雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？-65-活动图活动图-简述用例流程简述用例流程显示雇员列显示雇员列表表显示当前条显示当前条目目提示输入工提示输入工时时询问是否输询问是否输入完毕入完毕保存修改保存修改显示错误显示错误记录错误记录错误管理员用户管理员用户雇员雇员选定收费项目代码和日期选定收费项目代码和日期选定输入工时选定输入工时完毕完毕未完未完数据保存出错数据保存出错OKOK选择雇员

32、选择雇员-66-活动图活动图Activity Diagramn通过动作来组织，主要用于描述某一方法、机通过动作来组织，主要用于描述某一方法、机制或制或的的-67-活动图活动图-推荐的使用场合推荐的使用场合能直观清晰地分析用例，了解应当能直观清晰地分析用例，了解应当采取哪些动作以及这些动作之间的依赖关系。采取哪些动作以及这些动作之间的依赖关系。一张完整的活动图是所有用例的集成图一张完整的活动图是所有用例的集成图n理解牵涉理解牵涉在难于区分不同在难于区分不同用例而对整个系统的工作过程又十分清楚时，用例而对整个系统的工作过程又十分清楚时，可以先构造活动图，然后用切片技术派生用例可以先构造活动图，然后

33、用切片技术派生用例图图应用：采用应用：采用“分层抽象，逐步细化分层抽象，逐步细化”的原则描述多线程的原则描述多线程-68-基于用例的需求分析过程基于用例的需求分析过程n1. 获取原始需求获取原始需求n2. 开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者识别参与者n2.2 识别用例识别用例n2.3 构建用例图构建用例图n3 详细、完整地描述需求详细、完整地描述需求n进行用例阐述进行用例阐述n4.1 识别用例间的关系识别用例间的关系n4.2 对用例进行组织和分包对用例进行组织和分包-69-4.1 用例关系用例关系ExtendIncludeGeneralization-70-通过关

34、系整理文档通过关系整理文档nExtendn分离扩展路径分离扩展路径nIncluden提取公共步骤，便于复用提取公共步骤，便于复用nGeneralizationn同一业务目的的不同技术实现同一业务目的的不同技术实现-71-扩展关系扩展关系，可能是一条扩展路，可能是一条扩展路径径n扩展路径步骤多扩展路径步骤多n扩展路径内部还有扩展点扩展之扩展扩展路径内部还有扩展点扩展之扩展?管理订单?会员?从订单中删除某个订单项?-72-扩展关系误用扩展关系误用?购物?修改会员资料?会员?登录?-73-识别扩展点思路识别扩展点思路n执行者的选择执行者的选择n系统验证系统验证n步骤失败步骤失败n-74-包含关系包含

35、关系n某些步骤在多个用例重复出现，且单独某些步骤在多个用例重复出现，且单独形成价值形成价值n用例步骤较多时，可用用例步骤较多时，可用Include简化简化（慎用）（慎用）?下订单?提供客户信息?-75-包含关系误用包含关系误用?填写注册信息?验证注册信息充分?生成用户名和密码?保存注册信息?潜在会员?注册?-76-泛化关系泛化关系n同一业务目的不同技术实现：同一业务目的不同技术实现：n一个用例可以特化另一个更普通用例（更普通用例一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）泛化特殊用例）nUML 1.5: 用例间的泛化关系表明子用例包含父用用例间的泛化关系表明子用例包含父用例中定义

36、的所有属性、行为序列和扩展点，并且参例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系与父用例中所有的关系识别用户识别用户验证口令验证口令扫描指纹扫描指纹-77-用例关系：扩展用例关系：扩展 VS. 泛化泛化?识别用户?验证口令?扫描指纹?识别用户?验证口令?扫描指纹?-78-重构后的用例图：考勤卡系统重构后的用例图：考勤卡系统Change?PasswordRecord?TimeCreate?Charge?CodeBilling?SystemExport?Time?EntriesLoginEmployeeAdministrative?UserCreate?Employee-79-

37、4.2 为什么要对用例进行分级为什么要对用例进行分级n用例和开发周期用例和开发周期n开发周期是围绕用例的需求来组织的开发周期是围绕用例的需求来组织的n一个开发周期要被指派一个到多个用例，如果完全一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例那就采用简化版本的用例开发周期开发周期开发周期开发周期开发周期开发周期用例用例A-简化版本简化版本用例用例A-完整版本完整版本用例用例B用例用例C-80-用例分级原则用例分级原则n用例分级的一个基本原则用例分级的一个基本原则n高级别的用例是那些对系统核心体系结构影响最大高级别的用例是那些对系统核心体系结构影响最大的用例的用例n提高用例级别的特性：提高用例级别的特性：na. 对体系结构设计有重要影响的用例，如在领域层对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例中增加多个类的用例或者需要持久化的用例nb. 不需要花费很多努力就可以从中获得重要信息和不需要花费很多努力就可以从中获得重要信息和线索的那些用例线索的那些用例nc. 含有开发风险、时间紧迫或功能复