需求分析——UML用例图STUD-PPT.ppt

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