面向对象的分析设计之RUP基础及用例建模.ppt

《面向对象的分析设计之RUP基础及用例建模.ppt》由会员分享，可在线阅读，更多相关《面向对象的分析设计之RUP基础及用例建模.ppt（82页珍藏版）》请在三一办公上搜索。

1、面向对象的分析设计之RUP基础及用例建模出家如初,成佛有余,2008年12月,面向对象的分析设计培训大纲,2,3,目录,RUP基础业务建模需求分析编写有效用例,什么是Rational Unified Process,Rational Unified Process（简称RUP）是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程。RUP 为在开发组织中分配任务和职责提供了一种规范方法。其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的

2、软件工程过程。,4,RUP是最佳软件开发经验的总结,迭代式开发（develop software iteratively）管理需求（manage requirements）使用基于构件的体系结构（use component-based architectures）可视化软件建模（visually model software）验证软件质量（verify model quality）控制软件变更（control changes to software）,5,RUP的核心思想,尽早并且持续的化解重大风险，否则带来很多麻烦风险列表是不断变化的，要持续不断的化解风险。用例驱动，确保满足客户需求用例的主

3、要优势是使团队成员在设计、实现、测试和最终编写用户手册的过程中紧紧的以用户需求为中心。把注意力放在可执行软件上可执行软件使项目进度的最好体现。对项目进度评估时，尽可能以正在编写以及正在运行的代码和通过测试的用例为标准。,6,RUP的核心思想(续),尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识，在细化阶段结束时候建立系统构架的基线（设计、实现、测试的构架），在构造阶段结束时候完成“特性冻结”。在早期确定一个可执行的构架（architectural）确立了系统的构架，就识别出了在创建系统时候会遇到的许多最复杂的困难。,7,RUP的核心特点,用例驱动以架构为中心迭代和增量开

4、发,8,“4+1”视图,RUP基本架构,10,RUP主要的建模元素,开发流程定义了“谁”“何时”“如何”做“某事”四种主要的建模元素被用来表达RUP角色（Workers）：谁活动（Activities）：如何产物（Artifacts）：某事工作流（Workflows）：何时,11,RUP的核心概念,12,RUP的核心工作流,6个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流3个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流,13,RUP开发过程阶段-初始阶段,主要目标:建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望产品

5、中包括和不包括的内容识别系统的关键用例对比一些主要场景，展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境,RUP开发过程阶段-细化阶段,主要目标确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间、以合理的成本支持系统需求建立支持环境（创建开发案例、创建模板和指南、安装工具）,RUP开发过程阶段-构建阶段,主要目标完成所有所需功能的分析、开发和测试迭代式、递增式地开发为部署应

6、用程序作好准备,RUP开发过程阶段-移交阶段,主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准，对部署基线进行的评估,面向对象开发过程,业务建模需求分析设计构建测试部署,19,目录,RUP基础业务建模需求分析编写有效用例,业务建模的目的,目的：了解目标组织（将要在其中部署系统的组织）的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。作

7、为对这些模型的补充，还编写了以下文档：补充业务规约词汇表,业务建模-工作流程明细,21,业务建模-活动概述,22,业务建模-工件,23,从业务模型到系统,24,业务模型和系统Actor,25,业务建模成果,组织结构视图概述业务中的关键角色和职责以及他们的分组情况。业务流程视图包括业务的关键业务流程并对其进行概述，这些流程是业务存在的原因。文化视图表述对组织文化前景的设想，并定义为促进该文化而应用的机制。人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制。领域视图（可选）对于处理结构复杂信息的组织，通常需要定义应用于这些信息结构的关键机制和模式。在简单的情况下，组织结构视图中可能已经清楚

8、地表示了领域视图。,27,目录,RUP基础业务建模需求分析编写有效用例,什么是需求,需求是指系统必须符合的条件或具备的功能功能性：系统无需考虑物理约束而必须能够执行的动作非功能性可用性可靠性性能可支持性设计约束实施需求接口需求物理需求,需求工作流程的目的,与客户和其他涉众在系统的工作内容方面达成并保持一致。定义系统的用户界面，重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求。定义系统边界（限定）为计划迭代的技术内容提供基础。为估算开发系统所需成本和时间提供基础。,需求-工作流程,30,需求-活动,31,需求-工件,32,33,目录,RUP基础业务建模需求分析编写有效用例,用例(Us

9、e Case)建模,用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。整个RUP流程都是用例驱动(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。,34,用例模型（Use case model）,用例模型描述外部执行者(Actor)所理解的系统功能。即待开发系统的功能需求。用例模型驱动了需求分析之后各阶段的开发工作,还

10、被用于验证和检测所开发的系统,影响了 UML 的各个模型。用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。,35,用例模型核心元素,参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。通讯关联(Communication Association)通讯关联用于表示参与者和用例之间的

11、对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。,36,用例分析流程,识别系统边界和参与者列出事件识别用例编写用例规约（Use Case Specification）识别用例的关系对用例进行优先级排序,参与者Actor,参与者实例是指在系统外部与系统进行交互的人或物。参与者类定义一个参与者实例集，其中的各个参与者实例在系统中都担任同一角色。,查找参与者Actor,与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意：有些时候时间触发器也可看作参与者,记录参与者Actor,名称应明确表示参与者的角色，确保在以后不会对参与者的

12、名称产生混淆。简要说明所代表的对象,为何需要,在系统中能获得哪些利益 特征职责、数量、环境、使用系统的频率、领域知识水平、计算机水平、使用的其它应用程序,参与者的UML表示,参与者之间的关系,泛化关系,用户与参与者之间的关系,一个用户可以抽象为多个参与者张三 教师&学生一个参与者可以包含多个用户教师 张三&李四,参与者与系统边界的关系,图书馆管理信息系统,管理员,图书馆管理信息系统中的参与者,用例分析流程,识别系统边界和参与者列出事件识别用例编写用例规约（Use Case Specification）识别用例的关系对用例进行优先级排序,列出事件,系统必须响应的外部事件和内部事件外部事件：来自系

13、统外部顾客下定单内部事件：来自系统内部和时间有关：每天晚上检查账户事件描述语法：“主语动词(宾语)”主语：Actor的候选，例如：乘客，顾客，店员。动词：表示行为。例如：买，发送，修改宾语：动词所代表行为的目标,47,列出事件-例子,48,零件销售系统事件表格,用例分析流程,识别系统边界和参与者列出事件识别用例编写用例规约（Use Case Specification）识别用例的关系对用例进行优先级排序,用例Use Case,用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值。一个用例定义一组用例实例。用例的UML表示：,识别用例,从每个Actor出发，考虑：参与者希望系统

14、执行的主要任务是什么？参与者是否将在系统中创建、存储、更改、删除或读取数据？参与者是否需要将突发变更或外部变更通知给系统？是否需要将系统中发生的某些特定事件通知给此参与者？此参与者是否将执行系统启动或关闭操作？,识别用例用例要点,用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言，用户观点而非系统观点用例的粒度,52,识别用例-用例的粒度,常见错误：把交互的某个步骤当作用例把系统活动当作用例粒度过细，陷入功能分解四轮马车的错误（增加、删除、修改、查询）,53,用例分析流程,识别系统边界和参与者列出事件识别用例编写用例规约（Use Case Specification）识别用例

15、的关系对用例进行优先级排序,编写用例规约-用例的路径,55,编写用例规约-用例模板,用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流）1.23.扩展点2a.2a1.补充说明,编写用例规约-用例模板要素,编写用例规约-前置、后置条件,前置条件：开始用例前所必需的系统及其环境的状态后置条件：用例成功结束后系统应该具备的状态编写前置、后置条件的意义：某些用例依赖于其他用例一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理订单”）有助于识别漏掉的用例如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”）,编写用例规约-事

16、件流,说明用例如何开始和结束。说明在参与者和用例之间交换的是什么数据。说明事件流，而不只是功能，每个动作都应从“当参与者.时”开始。只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。避免不明确的术语，如“例如”、“等等”和“信息”详细说明事件流，即回答所有包含“什么”的问题。说明系统要做什么，而不是系统怎样做。,编写用例规约-事件流,使用结构化的叙述格式每个use case只描述没有大的分支的行为的单个线索。在事件流里要对事件流进行结构化说明基本事件流描述每个情节的行为者:目标语句对的顺序假设之前的每一步都是成功的备选事件流将失败情节作为延伸部分对于失败中的失败，用更长的前缀标记

17、更深一层的失败情节,编写用例规约-识别扩展点的思路,参与者的选择另一条成功路线“用支票结账”参与者错误的操作“没有提供Email地址”每次系统验证时，都暗示着扩展“系统验证账户名和密码”系统内部出现错误,61,Actor与Use Case的交互,每当找到一个用例，就应确定哪些参与者将与之进行交互定义一个通信关联关系，其导航方向应该与参与者和用例之间的信号传输方向相同。,Actor与Use Case交互图,用例分析流程,识别系统边界和参与者列出事件识别用例编写用例规约（Use Case Specification）识别用例的关系对用例进行优先级排序,识别用例的关系,包含(include)关系扩展

18、(Extend)关系泛化(generalization)关系,识别用例的关系-用例的包含关系,包含关系是指基础用例(Base)会用到被包含用例(Inclusion)，就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于：从基本用例中分解出来这种的行为：它对于了解基本用例的主要目的不是必需的，只有它的结果才比较重要。分解出两个或者多个用例所共有的行为。,识别用例的关系-用例的包含关系,67,识别用例的关系-用例的扩展关系,扩展（extend）关系是指将扩展用例(Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例(Base)中。基础用例(Base)中定义有一至多个已

19、命名的扩展点，基本用例自身应该是完整的，即基本用例应该是可理解并且有意义的，而不必引用任何扩展用例。但是基本用例并不独立于扩展用例，因为如果无法遵循扩展用例，就不能执行基本用例。扩展是有条件的，它是否执行取决于在执行基本用例时所发生的事件。基本用例并不控件执行扩展的条件，这些条件在扩展关系中进行说明。扩展用例可以访问和修改基本用例的属性。但是基本用例看到到扩展用例，也无法访问它们的属性。,识别用例的关系-用例的扩展关系,扩展的目的在于：表明用例的某一部分是可选的（或者可能可选）的系统行为。这样，你就可以将模型中的可选行为和必选行为分开。表明只有在特定 条件下（有时候是异常情况下）才执行的分支流

20、，如触发警报表明可能有一组行为段，其中的一个或者多个段可以在基本用例中的扩展点处插入。所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互。,69,识别用例的关系-用例的泛化关系,当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。父用例可以特化形成一个或者多个子用例，这些子用例代表了父用例比较特殊的形式。尽管在大多数情况下父用例是抽象的，但是无论是父用例还是子用例这两者都 不要求一定抽象。子用例继承父用例的所有结构、

21、行为和关系。同一父用例的子用例都是该父用例的特例。,识别用例的关系-用例的泛化关系,现金支付,信用卡支付,支付,用例分析流程,识别系统边界和参与者列出事件识别用例编写用例规约（Use Case Specification）识别用例的关系对用例进行优先级排序,对用例进行优先级排序-排序原则,以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险、时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程,73,用例 vs.场景（Scenario）,场景是用例的一个实例，表示用例的一个流程，可能是主流程，也可能是分支流程,大量用例时的组织

22、,按参与者分包按主题分包按开发团队分包按发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包,75,用例包,用例包是用例、参与者、关系、图和其他包的集合；通过将其划分为若干个较小部分来建立用例模型,划分用例包标准,用例包中的对象都要是直接包含在包中的对象。划分到一个包的情况：与同一个参与者交互的用例要划分在一个包内。相互之间有包含和扩展关系的包。都为可选，且由系统一起提供（或不提供）的包。顶级包包括所有的顶级用例包、所有顶级参与者，以及所有的顶级用例。,用例图,用例图显示参与者、用例、用例包以及它们之间的关系。对每一个用例包都做一个用例图。对顶级包做一个用例图。,用例建模之需求分析过程,用例建模之需求的组成,参考文档,编写有效用例（Writing Effective Use Cases）UML和模式应用（Applying UML and Pattern）Rational官方文档（Rational RUP中文教程）,81,82,谢 谢！,