您好,欢迎访问三七文档
用例建模Use-CaseModeling吴晓霞wxxqa@163.com-2-课程内容UML概述理解需求需求,难在何处?以用例为中心组织需求基于用例的需求分析过程-3-课程内容UML概述理解需求需求,难在何处?以用例为中心组织需求基于用例的需求分析过程同样的东西(对象)在不同人的眼里……如果在你的世界里出现了这样的事情……抽象画?还是表达某种神秘信息的作品?想做什么事情?UML简介UML(UnifiedModelingLanguage)为面向对象软件设计提供统一的、标准的、可视化的建模语言。适用于描述以用例为驱动,以体系结构为中心的软件设计的全过程。UML的定义包括UML语义和UML表示法两个部分。UML语义:UML对语义的描述使开发者能在语义上取得一致认识,消除了因人而异的表达方法所造成的影响。UML表示法:UML表示法定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。-8--9-UML发展现状目前通用的是UML1.x版主要UML1.3、UML1.42003年3月正式发布UML1.5UML2.02003年6月OMG采纳了UML2.0的Superstructure的提案正式文本尚未发布…-10-UML9种图类图:类以及类之间的相互关系对象图:对象以及对象之间相互关系构件图:构件及其相互依赖关系部署图:构件在各节点上的部署顺序图:强调时间顺序的交互图协作图:强调对象协作的交互图状态图:类所经历的各种状态活动图:对工作流建模用例图:需求捕获,测试依据结构行为用例图静态图实现图交互图行为图-11-UML建模工具IBMRationalRose2003BorlandTogether7.0MicrosoftVisio2003SybasePowerDesigner10NetBeansUML……“非程序员杂志”第26到30期UML工具一览,列出了约129个UML开发工具-12-内容安排UML概述理解需求需求,难在何处?以用例为中心组织需求基于用例的需求分析过程认识问题分析问题解决问题最终用户(提出问题)开发团队(解决问题)以用户的身份站在用户的角度认识问题获取需求—用例建模技术以开发者的身份站在用户的角度分析问题分析需求—用例分析技术以开发者的身份站在开发团队的角度分析问题解决需求—面向对象设计-14-需求—建造“正确”的系统需求:系统必须满足的条件或具备的能力软件质量准则“FURPS”功能性(Functionality)可用性(Usability)可靠性(Reliability)性能(Performance)可支持性(Supportability)非功能性需求-15-内容安排UML概述理解需求需求,难在何处?以用例为中心组织需求基于用例的需求分析过程-16-需求:饮料问题我要一瓶饮料…差不多,但我要无糖饮料…很好,不过我要绿茶的…啊,没有大瓶的…大瓶的无糖绿茶饮料难捕获,易变!-17-需求:如此脆弱客户/用户的要求/想法/期望软件设计软件产品分析和设计编码和测试验收没价值的软件需求补文档-18-需求:也需要开发客户/用户的要求/想法/期望软件设计软件产品开发编码和测试验收有价值的软件需求分析和设计-19-获取好的需求需求收集包括五个关键步骤找到可以帮助你理解这个系统的人倾听这些相关人员的描述,并从他们的角度来理解系统利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值详细地描述系统和客户以及系统和外部系统之间的交互重构(refactor)这个详细描述以保证它是可读且易懂的-20-内容安排UML概述理解需求需求,难在何处?以用例为中心组织需求基于用例的需求分析过程-21-需求问题:对策难捕获易变从用户视角看问题合理的结构用例-22-以用例为中心组织需求用例可用性可靠性网络协议业务规则……硬件接口界面约束性能-23-内容安排UML概述理解需求需求,难在何处?以用例为中心组织需求基于用例的需求分析过程-24-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别角色2.2识别用例2.3构建用例图3详细、完整地描述需求进行用例阐述4重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-25-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别角色2.2识别用例2.3构建用例图3.详细、完整地描述需求进行用例阐述4.重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-26-获取需求的技巧技巧描述实地观察直接观察个人工作的情况,以发现现存的实践方式和问题访谈从个人处收集特定信息特定群体调查对一组人员进行调查,以便了解工作态度和共同看法问卷调查收集详细数据和统计意义上比较重要的数据用户指导让最终用户告诉你,他们是如何操作系统的原型制作模拟一个无法直接测试的系统统计版本使用具有统计功能的应用程序来记录用户完成任务的方式行业知识收集和整理行业中的法律、法规,用户所使用的规章制度、操作规程等内容………-27-获取需求:考勤卡应用程序初次访谈记录开发者:谁将使用这个应用程序?客户:所有用它来记录可记帐以及不可记帐的工时的雇员……开发者:现在考勤卡应用程序是什么样的?客户:每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好,然后用电子邮件发给我。这个表格相当标准:纵向是收费项目代码,横向是日期。雇员可以在每个条目上填写说明。开发者:这个收费项目代码可以从什么地方得到?……开发者:谁来管理收费项目代码?客户:嗯,必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……-28-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别角色2.2识别用例2.3构建用例图:确定角色和用例之间的关系3.详细、完整地描述需求进行用例阐述4.重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-29-相关术语场景:是用来描述用户和系统之间交互的顺序的步骤用例:是为了达到某一用户目标而组合在一起的一组场景用例图:用来显示在系统(或其它实体)内的用例与系统角色之间的关系主要使用场合:需求获取、定义、分析用例模型:是系统既定功能及系统环境的模型,并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。-30-用例图元素includeextend角色用例系统边界直接关联扩展包含泛化注释体注释连接关联312.1识别角色角色(actor)是指在系统外部与系统交互的人或其他系统,它以某种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图符来表示。角色类型:角色不仅可以由人承担,还可以是其它系统、硬件设备、甚至是时钟:1)其它系统:当系统需要与其它系统交互时,如ATM柜员机系统中,银行后台系统就是一个角色;2)硬件设备:如果系统需要与硬件设备交互时,如在开发IC卡门禁系统时,IC卡读写器就是一个角色;3)时钟:当系统需要定时触发时,时钟就是角色322.1识别角色通过向用户提问来识别角色:谁使用系统提供的主要功能?(主要角色)谁来维护、管理系统?(次要角色)谁需要借助于系统完成日常工作任务?系统需要控制的硬件设备有哪些?系统需要与其他哪些系统交互?系统从哪儿得到信息?对系统产生的结果感兴趣的人或事是哪些?!不能把目光只专著于人身上。33ATM系统的角色1、谁使用ATM系统的主要功能(提款)?答:储户2、谁使用ATM系统的支持以完成日常工作任务?答:出纳员?还不肯定,先放在这里3、谁来维护、管理并保持系统正常运行?答:ATM系统工程师,银行人员34ATM系统的角色5、ATM系统需要处理哪些设备?答:信用卡6、谁对ATM系统运行的结果感兴趣?答:银行会计、储户4、该系统需要和哪些系统交互?答:目前还不清楚35ATM系统的角色储户信用卡银行人员银行会计-36-识别角色:考勤卡系统开发者:谁将使用这个应用程序?客户:所有用它来记录可记帐以及不可记帐的工时的雇员……开发者:现在考勤卡应用程序是什么样的?客户:每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好,然后用电子邮件发给我。这个表格相当标准:纵向是收费项目代码,横向是日期。雇员可以在每个条目上填写说明。开发者:这个收费项目代码可以从什么地方得到?……开发者:谁来管理收费项目代码?客户:嗯,必要的时候由我(业务经理)来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……EmployeeAdministrativeUser372.2识别用例用例,就是一件事情,要完成这件事情,需要做一系列的活动;而做一件事情可以有很多不同的方法和步骤,也可能会遇到各种各样的意外情况,因此这件事情是由很多不同情况的集合构成的,在UML中我们称之为场景。一个场景就是一个用例的实例。从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作(功能)。381.用例的特征响应性。一个用例不自动执行,总是有执行者启动。这件事必须由一个执行者发起,执行者的愿望是用例存在的原因。不存在没有执行者的用例,也不应该主动启动另一个用例。39回执性。用例执行完毕,向执行者提供可识别的返回值。用例的执行结果对角色来说是可观测的和有意义的。如,系统会监控角色在系统里的操作,并在角色删除数据之前备份。虽然它是系统的一个必需组成部分,但它在需求阶段却不应该作为用例出现。因为这是一个后台进程,对角色来说是不可观测的,它应该在系统用例分析阶段定义。又比如,登录系统是一个有效的用例,但输入密码却不是。这是因为登录系统对角色是有意义的,这样他可以获得身份认证和授权,但输入密码却是没有意义的,输入完了呢?有什么结果吗?1.用例的特征完整性。用例表示一个完整的功能,必须是一完整的描述。必须以向执行者提供返回值作为该用例完整性的标志。4041用例的特征-动宾短语用例必然是以动宾短语形式出现的。即,这件事必须有一个动作和动作的受体。例如,喝水是一个有效的用例,而“喝”和“水”却不是。虽然生活常识告诉我们,在没有水的情况下人是不会做出喝这个动作的,水也必然是喝进去的,而不是滑进去的。但是我们所见的很多用例中类似“计算”,“统计”,“报表”,“输出”,“录入”之类的并不在少数。-42-用例的命名执行者视角:一个简单、描述性的名称,一般为带有动作性的词。顾客购买商品信用卡支付extend432.寻找和确定用例业务用例:开始阶段,在确定用户需求过程中,系统分析员通过与客户交流建立业务模型来发现和确定的用例。系统用例:系统构造阶段,系统分析和设计人员在进行系统分析和设计时,根据系统的需求建立的用例。在系统开发的开端阶段,应把注意力集中在业务用例上,在精化阶段和构建阶段再考虑系统用例。-44-识别用例:考勤卡系统开发者:谁将使用这个应用程序?客户:所有用它来记录可记帐以及不可记帐的工时的雇员……开发者:现在考勤卡应用程序是什么样的?客户:每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好,然后用电子邮件发给我。这个表格相当标准:纵向是收费项目代码,横向是日期。雇员可以在每个条目上填写说明。开发者:这个收费项目代码可以从什么地方得到?……开发者:谁来管理收费项目代码?客户:嗯,必要的时候由我(业务经理)来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……RecordTimeCreateChargeCode-45-用例要点可观测→用例止于系统边界结果值→用例是有意义的目标系统执行→结果值由系统生成由角色观测→业务语言、用户观点一组用例实例→用例的粒度-46-要点:用例止于系统边界描述交互,而不是内在的系统活动-47-要点:有意义的目标设定查
本文标题:需求分析与用例建模
链接地址:https://www.777doc.com/doc-5124285 .html