需求分析――UML用例图STUD

用例建模Use-CaseModeling蔡莉[e-mail]-2-课程内容UML概述理解需求需求，难在何处？以用例为中心组织需求基于用例的需求分析过程-3-课程内容UML概述理解需求需求，难在何处？以用例为中心组织需求基于用例的需求分析过程-4-WhatIstheUML?TheUMLisalanguageforVisualizingSpecifyingConstructingDocumentingtheartifactsofasoftware-intensivesystemUnifiedModelingLanguage（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize）、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）-5-UML诞生工业化标准化统一化分散的各部分公众反馈1997.11.17UML1.1被OMG接纳为标准OOPSLA95UnifiedMethod0.8Booch93OMT-21996.6和1996.10UML0.9&0.911997.9公布UML1.11997.1公布UML1.0合作伙伴意见Booch91OMT-1其他方法OOSEGradyBoochJimRumbaughIvarJacobson-6-UML发展现状目前通用的是UML1.x版主要UML1.3、UML1.42003年3月正式发布UML1.5UML2.02003年6月OMG采纳了UML2.0的Superstructure的提案正式文本尚未发布…-7-UML9种图类图：类以及类之间的相互关系对象图：对象以及对象之间相互关系构件图：构件及其相互依赖关系部署图：构件在各节点上的部署顺序图：强调时间顺序的交互图协作图：强调对象协作的交互图状态图：类所经历的各种状态活动图：对工作流建模用例图：需求捕获，测试依据结构行为用例图静态图实现图交互图行为图-8-UML建模工具IBMRationalRose2003BorlandTogether7.0MicrosoftVisio2003SybasePowerDesigner10NetBeansUML……“非程序员杂志”第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-用例图元素includeextend参与者用例系统边界直接关联扩展包含泛化注释体注释连接关联-28-2.1识别参与者参与者，Actor关键词：边界参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物-29-参与者要点系统外参与者代表在系统边界之外的真实事物，并不是系统的成分系统边界参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定有意义的交互任何事物人、外系统、外部因素、时间-30-识别参与者：考勤卡系统开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……EmployeeAdministrativeUser-31-2.2识别用例关键词：价值定义用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例简洁：参与者使用系统达到目标-32-识别用例：考勤卡系统开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……RecordTimeCreateChargeCode-33-用例要点可观测→用例止于系统边界结果值→用例是有意义的目标系统执行→结果值由系统生成由参与者观测→业务语言、用户观点一组用例实例→用例的粒度-34-要点：用例止于系统边界描述交互，而不是内在的系统活动-35-要点：有意义的目标设定查询条件会员选择零件会员检索零件-36-要点：结果值由系统生成出纳员吃饭系统需要处理的，由系统生成-37-要点：业务语言而非技术语言用户词汇，而不是技术词汇如：发票，商品，洗衣机而不是：记录，字段，COM，C++等-38-要点：用户观点而非系统观点订票旅客查看今日航班处理订票旅客显示今日航班用户观点系统观点-39-用例VS.功能•呼叫某人•接听电话•发送短信•记住电话号码•……•传输/接收•电源/基站•输入输出（显示、键盘）•电话簿管理•……用户观点系统观点-40-用例的命名执行者视角：一个简单、描述性的名称，一般为带有动作性的词。顾客购买商品信用卡支付extend-41-要点：用例粒度-1用例要有路径，路径要有步骤；而这一切都是可观测的最常犯错误：粒度过细，陷入功能分解过细的粒度，一般都会导致技术语言的描述，而不再是业务语言-42-用例粒度-2把步骤当用例把系统活动当用例会员输入用户名验证用户名和密码会员登录include查询订单建立数据库连接执行SQL语句includeinclude-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管理员管理用户增加用户extend可以把包含复杂交互的路径独立出去形成用例-46-思考：识别用例-1Email客户端（如：outlookexpress），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件收件人发件人发邮件收邮件邮件系统提醒新邮件错误-47-思考：识别用例-2提醒新邮件发邮件用户收邮件时间-48-2.3构建用例图AdministrativeUserCreateChargeCodeBillingSystemExportTimeEntriesEmployeeRecordTimeCreateEmployee-49-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3.详细、完整地描述