《面向对象的软件工程.pptx》由会员分享，可在线阅读，更多相关《面向对象的软件工程.pptx（72页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、会计学1面向对象的软件工程面向对象的软件工程认识问认识问认识问认识问题题题题分析问分析问分析问分析问题题题题解决问解决问解决问解决问题题题题最终用户最终用户最终用户最终用户(提出问题提出问题提出问题提出问题)开发团队开发团队开发团队开发团队(解决问题解决问题解决问题解决问题)以以以以用户用户用户用户的身份站在的身份站在的身份站在的身份站在用户用户用户用户的角度认识问题的角度认识问题的角度认识问题的角度认识问题获取需求获取需求获取需求获取需求用例建模技术用例建模技术用例建模技术用例建模技术以以以以开发者开发者开发者开发者的身份站在的身份站在的身份站在的身份站在用户用户用户用户的角度分析问题的角度
2、分析问题的角度分析问题的角度分析问题分析需求分析需求分析需求分析需求用例分析技术用例分析技术用例分析技术用例分析技术以以以以开发者开发者开发者开发者的身份站在的身份站在的身份站在的身份站在开发团队开发团队开发团队开发团队的角度分析问题的角度分析问题的角度分析问题的角度分析问题解决需求解决需求解决需求解决需求面向对象设计面向对象设计面向对象设计面向对象设计第1页/共72页-3-内容安排内容安排n n理解需求n n需求，难在何处？n n以用例为中心组织需求n n基于用例的需求分析过程第2页/共72页-4-需求需求建造建造“正确正确”的系统的系统n n需求：系统必须满足的条件或具备的能力n nRob
3、ert Grady软件质量准则“FURPS”n n功能性（功能性（FunctionalityFunctionality）n n使用性（使用性（UsabilityUsability）n n可靠性（可靠性（ReliabilityReliability）n n性能（性能（PerformancePerformance）n n可支持性（可支持性（SupportabilitySupportability）非功能性需求非功能性需求非功能性需求非功能性需求第3页/共72页-5-内容安排内容安排n n理解需求n n需求，难在何处？n n以用例为中心组织需求n n基于用例的需求分析过程第4页/共72页-6-需求，
4、难在何处？需求，难在何处？n自己到底想要什么？n这是个问题第5页/共72页-7-需求：也需要开发需求：也需要开发客户客户/用户的要用户的要求求/想法想法/期望期望软件设计软件设计软件产品软件产品开开发发编码和测试编码和测试验收验收有价值的有价值的软件需求软件需求分析和设计分析和设计第6页/共72页-8-获取好的需求获取好的需求n n需求收集包括五个关键步骤n n找到可以帮助你理解这个系统的人找到可以帮助你理解这个系统的人n n倾听这些相关人员的描述，并从他们的角度来倾听这些相关人员的描述，并从他们的角度来理解系统理解系统n n利用一个容易理解的模型来描述用户希望如何利用一个容易理解的模型来描述
5、用户希望如何使用这个系统以及为他们提供的什么价值使用这个系统以及为他们提供的什么价值n n详细地描述系统和客户以及系统和外部系统之详细地描述系统和客户以及系统和外部系统之间的交互间的交互n n重构（重构（refactorrefactor）这个详细描述以保证它是可读）这个详细描述以保证它是可读且易懂的且易懂的第7页/共72页-9-内容安排内容安排n n理解需求n n需求，难在何处？n n以用例为中心组织需求n n基于用例的需求分析过程第8页/共72页-10-需求问题：对策需求问题：对策难捕获难捕获难捕获难捕获易变易变易变易变从用户视角看问题从用户视角看问题从用户视角看问题从用户视角看问题合理的结
6、构合理的结构合理的结构合理的结构用例用例用例用例第9页/共72页-11-以用例为中心组织需求以用例为中心组织需求用例用例用例用例可用性可用性可用性可用性可靠性可靠性可靠性可靠性网络协议网络协议网络协议网络协议业务规则业务规则业务规则业务规则硬件接口硬件接口硬件接口硬件接口界面约束界面约束界面约束界面约束性能性能性能性能第10页/共72页用例的相关概念用例的相关概念参与者（Actor）用例（Use Case）事件流第11页/共72页参与者参与者(Actor)n n参与者是在系统之外于系统进行交互的任何事物。参与者触发系统某项功能的执行(通过向系统输入某些信息，或请求系统输出某些信息)。n n最常
7、见的参与者n n人（操作人员或系统的服务对象）人（操作人员或系统的服务对象）n n设备（监控系统的摄像头等信息采集器）设备（监控系统的摄像头等信息采集器）n n外系统外系统第12页/共72页用例用例(Use Case)n n用例(use case):是对系统某个功能的一组动作序列的描述，系统执行这些动作序列将产生一个对某个特定的参与者有特定价值的结果。用例表示系统外部可见的功能单元。n n简言之：用例就是系统某功能一次执行的例子。简言之：用例就是系统某功能一次执行的例子。第13页/共72页事件流事件流n n事件流是系统完成需求行为的事件描述应尽量写的详细。事件流通常包括4部分：简要说明简要说明
8、前置条件前置条件主事件流和异常事件流（错误流）主事件流和异常事件流（错误流）事后条件（并不是每个用例都有）事后条件（并不是每个用例都有）第14页/共72页-16-内容安排内容安排n n理解需求n n需求，难在何处？n n以用例为中心组织需求n n基于用例的需求分析过程第15页/共72页-17-基于用例的需求分基于用例的需求分析过程析过程n n1.1.获取原始需求获取原始需求n n2.2.开发一个可以理解的需求开发一个可以理解的需求n n2.1 2.1 识别参与者识别参与者n n2.2 2.2 识别用例识别用例n n2.3 2.3 构建用例图构建用例图n n3 3 详细、完整地描述需求详细、完整
9、地描述需求n n进行用例阐述进行用例阐述n n4 4 重构用例模型重构用例模型n n4.1 4.1 识别用例间的关系识别用例间的关系n n4.2 4.2 对用例进行组织和分包对用例进行组织和分包第16页/共72页-18-基于用例的需求分析过程基于用例的需求分析过程n n1.1.获取原始需求获取原始需求n n2.2.开发一个可以理解的需求开发一个可以理解的需求n n2.1 2.1 识别参与者识别参与者n n2.2 2.2 识别用例识别用例n n2.3 2.3 构建用例图构建用例图n n3.3.详细、完整地描述需求详细、完整地描述需求n n进行用例阐述进行用例阐述n n4.4.重构用例模型重构用例
10、模型n n4.1 4.1 识别用例间的关系识别用例间的关系n n4.2 4.2 对用例进行组织和分包对用例进行组织和分包第17页/共72页-19-获取需求的技巧（获取需求的技巧（MSF）技巧技巧技巧技巧描述描述描述描述实地观察实地观察实地观察实地观察直接观察个人工作的情况，以发现现存的实践方式和问直接观察个人工作的情况，以发现现存的实践方式和问题题访谈访谈访谈访谈从个人处收集特定信息从个人处收集特定信息特定群体特定群体特定群体特定群体调查调查调查调查对一组人员进行调查，以便了解工作态度和共同看法对一组人员进行调查，以便了解工作态度和共同看法问卷调查问卷调查问卷调查问卷调查收集详细数据和统计意义
11、上比较重要的数据收集详细数据和统计意义上比较重要的数据用户指导用户指导用户指导用户指导让最终用户告诉你，他们是如何操作系统的让最终用户告诉你，他们是如何操作系统的原型制作原型制作原型制作原型制作模拟一个无法直接测试的系统模拟一个无法直接测试的系统统计版本统计版本统计版本统计版本使用具有统计功能的应用程序来记录用户完成任务的方使用具有统计功能的应用程序来记录用户完成任务的方式式 (RequisitePro)第18页/共72页-20-获取需求：应用程序获取需求：应用程序初次访谈记录初次访谈记录初次访谈记录初次访谈记录开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的
12、工时的雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。第19页/共72页-21-基于用例的需求分析过程基于用例的需求分析过程n n1.1.获取原始需求获取原始需求n n2.2.开发一个可以理解的需求开发一个可以理解的需求n n2.1 2.1 识别
13、参与者识别参与者n n2.2 2.2 识别用例识别用例n n2.3 2.3 构建用例图：确定参与者和用例之间的关系构建用例图：确定参与者和用例之间的关系n n3.3.详细、完整地描述需求详细、完整地描述需求n n进行用例阐述进行用例阐述n n4.4.重构用例模型重构用例模型n n4.1 4.1 识别用例间的关系识别用例间的关系n n4.2 4.2 对用例进行组织和分包对用例进行组织和分包第20页/共72页-22-2.1 识别参与者识别参与者n n参与者，Actorn n关键词：关键词：边界边界n n参与者：在参与者：在系统之外系统之外，透过，透过系统边界系统边界与系统进与系统进行行有意义交互有
14、意义交互的的任何事物任何事物第21页/共72页-23-参与者要点参与者要点n n系统外n n参与者代表在系统边界之外的真实事物，并不参与者代表在系统边界之外的真实事物，并不是系统的成分是系统的成分n n系统边界n n参与者透过系统边界参与者透过系统边界直接直接与系统交互，参与者与系统交互，参与者的确定代表的确定代表系统边界系统边界的确定的确定n n有意义的交互n n任何事物n n人、外系统、外部因素、时间人、外系统、外部因素、时间第22页/共72页-24-题外话：人与猪题外话：人与猪(1)第23页/共72页-25-人与猪人与猪(2)n n众所周知，众所周知，use case use case
15、图里的图里的actor actor 用一个小人表示。但是这个小人极用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数多数UML UML 学习者都要花好长一段时间来搞明白小人其实不一定代学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示系统。那么为什么不干脆用其它的符号来表示Actor Actor 呢？呢？n n如果我开发一个猪圈自动供食供水系统，猪的前
16、蹄触发一个开关如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的系统就供食或供水。显然，这里的Actor Actor 是小猪。那么在是小猪。那么在use case use case 图图里用小猪代替原来的小人不是更易于交流吗？里用小猪代替原来的小人不是更易于交流吗？第24页/共72页-26-思考：参与者与系统边界？思考：参与者与系统边界？n n某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接n n某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分第25页/共72页-27-思考：思考：识别参与者
17、？识别参与者？n n寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；在这个叙述里，谁是寻呼台系统的在这个叙述里，谁是寻呼台系统的在这个叙述里，谁是寻呼台系统的在这个叙述里，谁是寻呼台系统的ActorActor？第26页/共72页-28-识别参与者思路识别参与者思路n n谁使用系统的主要功能谁使用系统的主要功能n n谁改变系统的数据谁改变系统的数据n n谁从系统获取信息谁从系统获取信息n n谁需要系统的支持以完成日常工作任务谁需要系统的支持以完成日常工作任务n n谁负责日常维护、管理并保证系统正常运行谁负责日常维护、管理并保证系统正常
18、运行n n系统需要应付（处理）那些硬设备系统需要应付（处理）那些硬设备n n系统需要和那些外部系统交互系统需要和那些外部系统交互n n谁（或什么）对系统运行产生的结果（值）感兴趣谁（或什么）对系统运行产生的结果（值）感兴趣n n时间、气温等内部外部条件时间、气温等内部外部条件n n第27页/共72页-29-识别参与者：考勤卡系统识别参与者：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时的雇员雇员雇员雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我
19、。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我（业务经理）（业务经理）（业务经理）（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。第28页/共72页-30-2.2 识别用例识别用例n n关键词：价值n n定义n n用例实例是用例实例是系统执行系统执行的的一系列动作一系列动作，这些动作，这些动作将生成特定将生成特定参与者可观测参与者可观测的的结果值结果值n n一个用例定义一个用例定义一组用例实例一组用例实例n n简洁：参与者使
20、用系统达到目标第29页/共72页-31-识别用例：考勤卡系统识别用例：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时的雇员雇员雇员雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码管理收费项目代码管理收
21、费项目代码管理收费项目代码？客客 户户：嗯，必要的时候由我（业务经理）（业务经理）（业务经理）（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。第30页/共72页-32-用例要点用例要点n n可观测用例止于系统边界n n结果值用例是有意义的目标n n系统执行结果值由系统生成n n由参与者观测业务语言、用户观点n n一组用例实例用例的粒度第31页/共72页-33-要点：用例止于系统边界要点：用例止于系统边界描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动第32页/共72页-34-要点：有意义的目标要点：有意
22、义的目标第33页/共72页-35-要点：结果值由系统生成要点：结果值由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成第34页/共72页-36-要点：业务语言而非技术语言要点：业务语言而非技术语言n n用户词汇，而不是技术词汇n n如：发票，商品，洗衣机如：发票，商品，洗衣机n n而不是：记录，字段，而不是：记录，字段，COMCOM，C+C+等等第35页/共72页-37-要点：用户观点而非系统观点要点：用户观点而非系统观点用户观点用户观点用户观点用户观点系统观点系统观点系统观点系统观点第36页/共72页-38-用例用例 VS.功能
23、功能呼叫某人呼叫某人接听电话接听电话发送短信发送短信记住电话号码记住电话号码传输传输/接收接收电源电源/基站基站输入输出（显示、键盘）输入输出（显示、键盘）电话簿管理电话簿管理用户观点用户观点用户观点用户观点系统观点系统观点系统观点系统观点第37页/共72页-39-用例的命名用例的命名n n执行者视角：执行者视角：n n（状语）动词（状语）动词+（定语（定语+）宾语）宾语第38页/共72页-40-要点：用例粒度要点：用例粒度-1n n用例要有路径，路径要有步骤；而这一切都是可观测的n n最常犯错误：粒度过细，陷入功能分解n n过细的粒度，一般都会导致技术语言的描述，过细的粒度，一般都会导致技术
24、语言的描述，而不再是业务语言而不再是业务语言第39页/共72页-41-用例粒度用例粒度-2n n把步骤当用例n n把系统活动当用例是不合适的第40页/共72页-42-思考：识别用例思考：识别用例-1n nEmailEmail客户端（如：客户端（如：outlook expressoutlook express），），A A在北在北京发邮件给上海的京发邮件给上海的B B，系统提醒，系统提醒B B你有你有“新邮新邮件件”，B B收邮件收邮件第41页/共72页-43-思考：识别用例思考：识别用例-2第42页/共72页-44-基于用例的需求分析过程基于用例的需求分析过程n n1.1.获取原始需求获取原始
25、需求n n2.2.开发一个可以理解的需求开发一个可以理解的需求n n2.1 2.1 识别参与者识别参与者n n2.2 2.2 识别用例识别用例n n2.3 2.3 构建用例图构建用例图n n3 3 详细、完整地描述需求详细、完整地描述需求n n进行用例阐述进行用例阐述n n4 4 重构用例模型重构用例模型n n4.1 4.1 识别用例间的关系识别用例间的关系n n4.2 4.2 对用例进行组织和分包对用例进行组织和分包第43页/共72页-45-进行用例阐述：写用例规约进行用例阐述：写用例规约n n用例规约：更进一步的精度n n用例文档的核心，作为用例文档的总图用例文档的核心，作为用例文档的总图
26、n n进一步的精度：有层次的文档进一步的精度：有层次的文档n n文档中每一句话都有其价值文档中每一句话都有其价值用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉第44页/共72页-46-谁来写用例文档谁来写用例文档n n最完美：业务人员接受训练，写出优美的用例文档n n最现实：业务人员提供素材，开发人员写用例文档n n最糟糕：业务人员不管，完全由开发人员杜撰第45页/共72页-47-用例规约组成用例规约组成n n用例名称用例名称n n用例标识用例标识n n涉及的参与者涉及的参与者n n描述描
27、述n n用例的规格说明用例的规格说明n n前置条件前置条件 PreConditionsPreConditionsn n后置条件后置条件 PostConditionsPostConditionsn n正常事件流正常事件流 Flow of eventsFlow of eventsn n异常事件流异常事件流 Alternate flowAlternate flown n其它其它n n非功能需求、设计约束、尚存在的问题非功能需求、设计约束、尚存在的问题第46页/共72页-48-前置、后置条件前置、后置条件-1n n前置条件约束在用例开始前置条件约束在用例开始前系统的状态前系统的状态n n把它们看做是看
28、门人，它把它们看做是看门人，它阻止参与者触发该用例直阻止参与者触发该用例直到满足所有条件到满足所有条件n n说明在用例触发之前什么说明在用例触发之前什么必须为真必须为真n n后置条件约束用例执行后后置条件约束用例执行后系统的状态系统的状态n n用例执行后什么必须为真用例执行后什么必须为真n n对于有多个事件流的用例，对于有多个事件流的用例，则应该有多个后置条件则应该有多个后置条件第47页/共72页-49-前置、后置条件前置、后置条件-2n n某些用例依赖于其他用例n n一个用例在离开系统时，可能是另一个用例的一个用例在离开系统时，可能是另一个用例的前置条件（例如：前置条件（例如：“登录登录”和
29、和“管理系统管理系统”）n n有助于识别漏掉的用例n n如果一个用例的前置条件不能由执行其他用例如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例（例如：满足，可能意味着丢失了用例（例如：“管理管理订单订单”却没有却没有“登录登录”用例）用例）第48页/共72页-50-用例交互四部曲用例交互四部曲-事件流事件流1.动动 作作4.回回 应应2.改变改变3.验证验证系系 统统写：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字第49页/共72页-51-事件流描述要点事件流描述要点n n1.只书写“可观测”的
30、（说人话）n n2.使用主动语句n n3.句子必须以参与者或系统作为主语n n4.不要涉及界面细节n n5.分支和循环第50页/共72页-52-要点要点1：只写：只写“可观测可观测”的的n n系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息n n系统按照查询条件搜索商品的详细信息第51页/共72页-53-要点要点2：主动语句：主动语句n n欧文丛贝克汉姆处得到传球，守门员n n贝克汉姆传球给欧文，欧文射门，守门员扑救n n出纳员n n系统第52页/共72页-54-要点要点3：以参与者或系统作主语：以参与者或系统作主语n n参与者n n系统n n出纳员接收顾客的付
31、款出纳员接收顾客的付款顾客的付款数可能高顾客的付款数可能高于商品总额于商品总额n n出纳员录入顾客所付的现金总额出纳员录入顾客所付的现金总额n n系统显示出应找还给顾客的余额，打印付款收系统显示出应找还给顾客的余额，打印付款收据据第53页/共72页-55-要点要点4：不涉及界面细节：不涉及界面细节n n会员从下拉框中选择类别n n会员在相应文本框中输入查询条件n n会员点击“确定”按钮第54页/共72页-56-要点要点5：分支和循环：分支和循环n n找清楚分支条件和循环条件第55页/共72页-57-基于用例的需求分析过程基于用例的需求分析过程n n1.1.获取原始需求获取原始需求n n2.2.
32、开发一个可以理解的需求开发一个可以理解的需求n n2.1 2.1 识别参与者识别参与者n n2.2 2.2 识别用例识别用例n n2.3 2.3 构建用例图构建用例图n n3 3 详细、完整地描述需求详细、完整地描述需求n n进行用例阐述进行用例阐述n n4 4 重构用例模型重构用例模型n n4.1 4.1 识别用例间的关系识别用例间的关系n n4.2 4.2 对用例进行组织和分包对用例进行组织和分包第56页/共72页-58-对用对用例进行分类例进行分类n n用例和开发周期用例和开发周期n n开发周期是围绕用例的需求来组织的开发周期是围绕用例的需求来组织的n n一个开发周期要被指派一个到多个用
33、例，如果完全版本的用例在一一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例个开发周期中处理起来太复杂的话，那就采用简化版本的用例开发周期开发周期开发周期开发周期开发周期开发周期用例用例A-简化版本简化版本用例用例A-完整版本完整版本用例用例B用例用例C第57页/共72页59用例分级用例分级n n每一个用例都要根据它的风险、对用户和架构的重要性、团队是否有能力开发进行分级。n n一旦用例已经按这些类别来分类，就可以确定哪一个用例的子集是最重要的，并适合在第一次系统的迭代中实现。n n这个过程包括一些权衡和妥协的综合考虑。n n例如，
34、一个用例的风险可能很高，例如，一个用例的风险可能很高，这使得我们想在第一次迭代中实现这使得我们想在第一次迭代中实现它。但是，如果开发团队对实现这它。但是，如果开发团队对实现这种用例完全没有把握，那么，作为种用例完全没有把握，那么，作为妥协，我们应该选择一个风险较低妥协，我们应该选择一个风险较低的、较容易实现的用例。的、较容易实现的用例。第58页/共72页60用例分级用例分级n n为了让这些工作简单一点，将用例的风险、重要性、合适性分成从1到5的五个级别。n n级别越高，那么这个用例就越适合在第一个或者下一个迭代中实现。n n考勤卡应用程序找到了6个用例，下图显示了这个高层用例图。第59页/共7
35、2页611风险(risk)n n你应该尽可能在开发周期的初期攻克系统有风险的部分。然后，即使出师不利，你仍然有足够的时间和机会来试着用其他的方法来做。n n在考虑用例的风险之前，需要先列出项目的风险清单。以下的风险，对多数的项目来说都是存在的，它们可以作为考虑项目风险的出发点，并按此顺序考察每一个用例。n n无法接受的系统性能。无法接受的系统性能。n n无法应付新的需求。无法应付新的需求。n n不确定的进度以及开发周期。不确定的进度以及开发周期。n n无法接受的用户界面。无法接受的用户界面。第60页/共72页62n n在按风险分级用例之前，我们将问开发人员这样一个问题：他们是否有把握在第一次尝
36、试中解决某个问题，然后让他们从以下的答案中选择一个：1)1)当然可以，我们的项目团队以前解当然可以，我们的项目团队以前解决过这种问题。决过这种问题。2)2)没问题，我们机构以前解决过这种没问题，我们机构以前解决过这种问题。问题。3)3)可以采用第三方提供的产品、培训、可以采用第三方提供的产品、培训、书或者其他的技术资源，但我们内书或者其他的技术资源，但我们内部没有任何经验。部没有任何经验。4)4)可能吧，我们听过类似的可以解决可能吧，我们听过类似的可以解决的问题。的问题。5)5)我希望可以，但我们得做一些开创我希望可以，但我们得做一些开创性的工作。性的工作。n n在评估用例的时候我们将会看到，
37、这个简单的风险“谱”将帮助我们识别出在下一次迭代中必须考虑的高风险用例。第61页/共72页632重要性(significance)n n如果一个用例差不多就是系统的愿景，那它对用户以及架构就是很重要的。一个重要的用例应该能够体现系统的特性和目标。其他的用例也可能会很重要，但它们只是扮演支持的角色。第62页/共72页64n n是否可以这样衡量用例的重要性：我们询问开发人员，如果这个用例在本次迭代中忽略掉，或者用其他的用例来取代，那么用户将会怎样反应?让他们从以下的答案中选择一个：1)1)他们几乎不会注意到这个用例不存他们几乎不会注意到这个用例不存在，在没有它的情况下使用这个系在，在没有它的情况下
38、使用这个系统不会有什么影响。统不会有什么影响。2)2)他们会注意到这个用例不存在，但他们会注意到这个用例不存在，但是，稍加想像，这个系统仍然可以是，稍加想像，这个系统仍然可以很好的使用。很好的使用。3)3)系统的大部分可以独立于这个用例。系统的大部分可以独立于这个用例。4)4)系统的一部分可以独立于这个用例。系统的一部分可以独立于这个用例。5)5)没有它，就不可能使用这个系统。没有它，就不可能使用这个系统。n n在评估用例的时候我们将会看到，这个简单的“谱”将有助于识别出在下一次迭代中必须考虑的重要用例。第63页/共72页653合适性(suitability)n n如果你的项目组可以只经过最少
39、的培训以及相对短的学习曲线就可以开始开发某个用例，那么这个用例就比较合适你的团队。当在机构中引入新的技术、语言和开发方法时，这两个标准就显得特别重要。n n由于在为第一次迭代选择用例的时候我们并没有考虑到技术选择，因此很难判断开发某个用例时需要学习多少东西。而实际上，一个项目组一般都知道他们是否需要采用一个新技术，比如面向对象开发。而且，他们一般也知道要采用的语言或者一族语言。第64页/共72页66n n考虑到这些，我们可以要求开发人员描述他们对方法和技术的把握有多高，让他们从以下的答案中做出选择：1)1)这个团队绝对需要一段培训时间来这个团队绝对需要一段培训时间来开发这个用例。开发这个用例。
40、2)2)对于这个用例来说，团队可能有了对于这个用例来说，团队可能有了足够的能力，但是在一次迭代之后，足够的能力，但是在一次迭代之后，团队的能力将会有本质的提高。团队的能力将会有本质的提高。3)3)团队可能有了足够的能力，但在一团队可能有了足够的能力，但在一次迭代之后这个能力不会怎么提高。次迭代之后这个能力不会怎么提高。4)4)不需要很多的培训。要么是团队的不需要很多的培训。要么是团队的能力已经绰绰有余，要么是这个用能力已经绰绰有余，要么是这个用例相当简单。例相当简单。5)5)不需要很多的培训。团队有足够的不需要很多的培训。团队有足够的经验，用例也很简单。手到擒来。经验，用例也很简单。手到擒来。
41、第65页/共72页672)2)重要性重要性n n这是一个非常重要的用例，整个考这是一个非常重要的用例，整个考勤系统的功能就是为各种不同的目勤系统的功能就是为各种不同的目标收集并获取考勤条目。标收集并获取考勤条目。n n它应该评为第它应该评为第5 5级级“没有它，系统没有它，系统就不可能使用就不可能使用”比较合适。比较合适。3)3)合适性合适性n n这个用例相对简单，团队可以应付这个用例相对简单，团队可以应付它。它。n n评为第评为第4 4级级“不需要很多的经验。不需要很多的经验。要么是团队的能力已经绰绰有余，要么是团队的能力已经绰绰有余，要么是这个用例相当简单要么是这个用例相当简单”比较合比较
42、合适。适。4)4)结论结论n n考虑到重要性，这个用例显然应该考虑到重要性，这个用例显然应该在第一次迭代中实现。这将有助于在第一次迭代中实现。这将有助于同用户建立信任，并提供重要的架同用户建立信任，并提供重要的架构功能。构功能。第66页/共72页68选择第一次迭代的用例选择第一次迭代的用例n n对于一个有相当开发经验的团队，我们可以在风险和重要性的基础上确定第一次迭代的用例。n n“Record Time”和“Extract Time Entries”肯定应该属于第一次迭代。“Create Employee”、“Create Charge Code”和“Change Password”可以推迟
43、实现，“Login”也可以推迟，但是我们将它包含进来，使第一次迭代看起来更现实点。n n将所有架构上重要的用例都放在第一次迭代中，在这次迭代完成后，相关人员就可以得到一个关于这个系统的清晰的印象，而且开发者可以通过这几个关键用例来确保解决方案的完整性。n n则第一次迭代的用例是：n n“Record Time”Record Time”、“Extract Time Extract Time Entries”Entries”和和“Login”Login”。第67页/共72页-69-用例分类原则用例分类原则n n用例分类的一个基本原则用例分类的一个基本原则n n高级别的用例是那些对系统核心体系结构影
44、响最大的用例高级别的用例是那些对系统核心体系结构影响最大的用例n n提高用例级别的特性：提高用例级别的特性：n na.a.对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例者需要持久化的用例n nb.b.不需要花费很多努力就可以从中获得重要信息和线索的那些用例不需要花费很多努力就可以从中获得重要信息和线索的那些用例n nc.c.含有开发风险、时间紧迫或功能复杂的用例含有开发风险、时间紧迫或功能复杂的用例n nd.d.涉及到重要技术研究或者新技术和高风险的用例涉及到重要技术研究或者新技术和高风险的用例n
45、ne.e.代表主要的在线业务流程的用例代表主要的在线业务流程的用例n nf.f.能产生直接经济效益或者降低成本的用例能产生直接经济效益或者降低成本的用例第68页/共72页-70-用例分类实施策略用例分类实施策略(1)n n可以使用一个简单的但是有些不精确的分类方法，如将用例划可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级分成高、中、低三个等级第69页/共72页-71-用例分类实施策略用例分类实施策略(2)n n依照上述的影响用例级别的特性给用例打分（用例也可能带有依照上述的影响用例级别的特性给用例打分（用例也可能带有权值权值第70页/共72页-72-用例的组织用例
46、的组织n n对用例进行分包对用例进行分包n n让用例图能够更为清晰地表现出系统的业务逻辑关系和层次让用例图能够更为清晰地表现出系统的业务逻辑关系和层次n n对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式n n常见的分包方式常见的分包方式n n按参与者分包按参与者分包n n按主题分包按主题分包n n按开发团队分包按开发团队分包n n按发布情况分包按发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包第71页/共72页