面向对象需求分析

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