《需求分析——uml用例图stud资料》由会员分享，可在线阅读，更多相关《需求分析——uml用例图stud资料（84页珍藏版）》请在金锄头文库上搜索。
1、用例建模 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（统一建模语言）
2、是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize） 、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）,-5-,UML诞生,1997.11.17 UML 1.1被OMG 接纳为标准,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的Superstru
3、cture的提案 正式文本尚未发布 ,-7-,UML 9种图,类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署 顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据,结 构,行为,用例图,静态图,实现图,交互图,行为图,-8-,UML建模工具,IBM Rational Rose 2003 Borland Together 7.0 Microsoft Visio 2003 Sybase PowerDesigner 10 NetBeans
4、UML “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具,-9-,内容安排,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,认识问题,分析问题,解决问题,最终用户(提出问题),开发团队(解决问题),以用户的身份站在用户的角度认识问题 获取需求用例建模技术,以开发者的身份站在用户的角度分析问题 分析需求用例分析技术,以开发者的身份站在开发团队的角度分析问题 解决需求面向对象设计,-11-,需求建造“正确”的系统,需求：系统必须满足的条件或具备的能力 软件质量准则“FURPS” 功能性（Functionality） 可用性（Usab
5、ility） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability）,非功能性需求,-12-,内容安排,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-13-,需求：饮料问题,我要一瓶饮料 差不多，但我要无糖饮料 很好，不过我要绿茶的 啊，没有大瓶的,大瓶的无糖绿茶饮料,难捕获，易变！,-14-,需求：如此脆弱,客户/用户的要求/想法/期望,软件设计,软件产品,分析和设计,编码和测试,验 收,没价值的 软件需求,补文档,-15-,需求：也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,
6、编码和测试,验收,有价值的 软件需求,分析和设计,-16-,获取好的需求,需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的,-17-,内容安排,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-18-,需求问题：对策,难捕获,易变,从用户视角看问题,合理的结构,用例,-19-,以用例为中心组织需求,-20-,内容安
7、排,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 对用例进行组织和
8、分包,-23-,获取需求的技巧,-24-,获取需求：考勤卡应用程序,初次访谈记录 开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-25-,基于用例的需求分析过程,1. 获取原始
9、需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图：确定参与者和用例之间的关系 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-26-,相关术语,场景：是用来描述用户和系统之间交互的顺序的步骤,用例：是为了达到某一用户目标而组合在一起的一组场景,用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系,主要使用场合：需求获取、定义、分析,用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。,-27-,用例图
10、元素,参与者,用例,系统边界,直接关联,扩展,包含,泛化,注释体,注释连接,关联,-28-,2.1 识别参与者,参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物,-29-,参与者要点,系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 任何事物 人、外系统、外部因素、时间,-30-,识别参与者：考勤卡系统,开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就
11、用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-31-,2.2 识别用例,关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例 简洁：参与者使用系统达到目标,-32-,识别用例：考勤卡系统,开发者：谁将使用这个应用程序？ 客 户：所有用它来记录
12、可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-33-,用例要点,可观测用例止于系统边界 结果值用例是有意义的目标 系统执行结果值由系统生成 由参与者观测业务语言、用户观点 一组用例实例用例的粒度,-34-,要点：用例
13、止于系统边界,描述交互，而不是内在的系统活动,-35-,要点：有意义的目标,-36-,要点：结果值由系统生成,系统需要处理的，由系统生成,-37-,要点：业务语言而非技术语言,用户词汇，而不是技术词汇 如：发票，商品，洗衣机 而不是：记录，字段，COM，C+等,-38-,要点：用户观点而非系统观点,用户观点,系统观点,-39-,用例 VS. 功能,呼叫某人 接听电话 发送短信 记住电话号码 ,传输/接收 电源/基站 输入输出（显示、键盘） 电话簿管理 ,用户观点,系统观点,-40-,用例的命名,执行者视角： 一个简单、描述性的名称，一般为带有动作性的词。,-41-,要点：用例粒度-1,用例要有
14、路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,-42-,用例粒度-2,把步骤当用例 把系统活动当用例,-43-,用例粒度-3,“四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的,-44-,用例粒度-4,如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理”即可 不管是C、R、
15、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.重构用例模型(高级用例建模方法)
16、4.1 识别用例间的关系 4.2 对用例进行组织和分包,-50-,进行用例阐述：写用例规约,用例规约(Use case Specification) ：更进一步的精度 用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值,用例图是骨架，而用例规约则是其内在的肉,-51-,谁来写用例文档,最完美：业务人员接受训练，写出优美的用例文档 最现实：业务人员提供素材，开发人员写用例文档 最糟糕：业务人员不管，完全由开发人员杜撰,-52-,用例规约组成,用例名称 用例标识 涉及的参与者 描述 用例的规格说明 前置条件 PreConditions 后置条件 PostConditions 正常事件流 Flow of events 备选事件流 Alternate flow 其它 非功能需求、设计约束、尚存在的问题,-53-,前置、后置条件-1,前置条件
