《面向对象的分析设计之RUP基础及用例建模.pptx》由会员分享，可在线阅读，更多相关《面向对象的分析设计之RUP基础及用例建模.pptx（81页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、1目录RUP基础业务建模需求分析编写有效用例第1页/共81页什么是Rational Unified Process RationalUnifiedProcess（简称RUP）是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程。RUP为在开发组织中分配任务和职责提供了一种规范方法。其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。2第2页/共81页RUP是最佳软件开发经验的总结迭代式开发（developsoftwarei
2、teratively）管理需求（managerequirements）使用基于构件的体系结构（usecomponent-basedarchitectures）可视化软件建模（visuallymodelsoftware）验证软件质量（verifymodelquality）控制软件变更（controlchangestosoftware）3第3页/共81页RUP的核心思想尽早并且持续的化解重大风险，否则带来很多麻烦风险列表是不断变化的，要持续不断的化解风险。用例驱动，确保满足客户需求用例的主要优势是使团队成员在设计、实现、测试和最终编写用户手册的过程中紧紧的以用户需求为中心。把注意力放在可执行软件上
3、可执行软件使项目进度的最好体现。对项目进度评估时，尽可能以正在编写以及正在运行的代码和通过测试的用例为标准。4第4页/共81页RUP的核心思想(续)尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识，在细化阶段结束时候建立系统构架的基线（设计、实现、测试的构架），在构造阶段结束时候完成“特性冻结”。在早期确定一个可执行的构架（architectural）确立了系统的构架，就识别出了在创建系统时候会遇到的许多最复杂的困难。5第5页/共81页RUP的核心特点用例驱动以架构为中心迭代和增量开发6第6页/共81页“4+1”视图Process ViewDeployment ViewL
4、ogical ViewImplementation ViewProgrammers Software management PerformanceScalabilityThroughput System IntegratorsSystem topology Delivery,installationcommunicationSystem EngineeringUse-Case ViewStructure Analysts/DesignersEnd-user Functionality第7页/共81页RUP基本架构8第8页/共81页RUP主要的建模元素开发流程定义了“谁”“何时”“如何”做“某事
5、”四种主要的建模元素被用来表达RUP角色（Workers）：谁活动（Activities）：如何产物（Artifacts）：某事工作流（Workflows）：何时9第9页/共81页RUP的核心概念10第10页/共81页RUP的核心工作流6个核心工程工作流商业建模工作流需求工作流分析和设计工作流实现工作流测试工作流分发工作流3个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流11第11页/共81页RUP开发过程阶段-初始阶段主要目标:建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景，展示至少一个备选构架评估整个项目的
6、总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境第12页/共81页RUP开发过程阶段-细化阶段主要目标确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间、以合理的成本支持系统需求建立支持环境（创建开发案例、创建模板和指南、安装工具）第13页/共81页RUP开发过程阶段-构建阶段主要目标完成所有所需功能的分析、开发和测试迭代式、递增式地开发为部署应用程序作好准备第14页/共81页RUP开发过程阶段-移交阶段主要目
7、标确保最终用户可以使用软件培训用户和维护人员根据产品的完整前景和验收标准，对部署基线进行的评估第15页/共81页面向对象开发过程业务建模需求分析设计构建测试部署第16页/共81页17目录RUP基础业务建模需求分析编写有效用例第17页/共81页业务建模的目的目的：了解目标组织（将要在其中部署系统的组织）的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。为实现这些目标，业务建模工作流程说明了如何拟定新目标组织的前景，并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。作为对这些模型的
8、补充，还编写了以下文档：补充业务规约词汇表第18页/共81页业务建模-工作流程明细19第19页/共81页业务建模-活动概述20第20页/共81页业务建模-工件21第21页/共81页从业务模型到系统22第22页/共81页业务模型和系统Actor23第23页/共81页业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况。业务流程视图包括业务的关键业务流程并对其进行概述，这些流程是业务存在的原因。文化视图表述对组织文化前景的设想，并定义为促进该文化而应用的机制。人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制。领域视图（可选）对于处理结构复杂信息的组织，通常需要定义应用于这
9、些信息结构的关键机制和模式。在简单的情况下，组织结构视图中可能已经清楚地表示了领域视图。第24页/共81页25目录RUP基础业务建模需求分析编写有效用例第25页/共81页什么是需求需求是指系统必须符合的条件或具备的功能功能性：系统无需考虑物理约束而必须能够执行的动作非功能性可用性可靠性性能可支持性设计约束实施需求接口需求物理需求第26页/共81页需求工作流程的目的与客户和其他涉众在系统的工作内容方面达成并保持一致。定义系统的用户界面，重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求。定义系统边界（限定）为计划迭代的技术内容提供基础。为估算开发系统所需成本和时间提供基础。第27页/共
10、81页需求-工作流程28第28页/共81页需求-活动29第29页/共81页需求-工件30第30页/共81页31目录RUP基础业务建模需求分析编写有效用例第31页/共81页用例(Use Case)建模用例(UseCase)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。整个RUP流程都是用例驱动(Use-CaseDriven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。
11、32第32页/共81页用例模型（Use case model）用例模型描述外部执行者(Actor)所理解的系统功能。即待开发系统的功能需求。用例模型驱动了需求分析之后各阶段的开发工作,还被用于验证和检测所开发的系统,影响了UML的各个模型。用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。33第33页/共81页用例模型核心元素参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。用例(UseCase)用例用于表示系统所提供的服务，它定义了系统是如
12、何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。通讯关联(CommunicationAssociation)通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。34第34页/共81页用例分析流程识别系统边界和参与者列出事件识别用例编写用例规约（UseCaseSpecification）识别用例的关系对用例进行优先级排序第35页/共81页参与者Actor参与者实例是指在系统外部与系统进行交互的人或物。参与者类定义一个参与者实例集，其中的各个参与者实例在系统中都
13、担任同一角色。第36页/共81页查找参与者Actor与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意：有些时候时间触发器也可看作参与者第37页/共81页记录参与者Actor名称应明确表示参与者的角色，确保在以后不会对参与者的名称产生混淆。简要说明所代表的对象,为何需要,在系统中能获得哪些利益特征职责、数量、环境、使用系统的频率、领域知识水平、计算机水平、使用的其它应用程序第38页/共81页参与者的UML表示Actor第39页/共81页参与者之间的关系泛化关系学生学生读者读者教师教师第40页/共81页用户与参与者之间的关系一个用户可以抽象为多个参与者张三教师&学生一个参与者可以包
14、含多个用户教师张三&李四第41页/共81页参与者与系统边界的关系图书馆管理信息系统管理员管理员管理员第42页/共81页图书馆管理信息系统中的参与者学籍系统学籍系统学生学生读者读者教师教师第43页/共81页用例分析流程识别系统边界和参与者列出事件识别用例编写用例规约（UseCaseSpecification）识别用例的关系对用例进行优先级排序第44页/共81页列出事件系统必须响应的外部事件和内部事件外部事件：来自系统外部顾客下定单内部事件：来自系统内部和时间有关：每天晚上检查账户事件描述语法：“主语动词(宾语)”主语：Actor的候选，例如：乘客，顾客，店员。动词：表示行为。例如：买，发送，修改
15、宾语：动词所代表行为的目标45第45页/共81页列出事件-例子46零件销售系统事件表格第46页/共81页用例分析流程识别系统边界和参与者列出事件识别用例编写用例规约（UseCaseSpecification）识别用例的关系对用例进行优先级排序第47页/共81页用例Use Case用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值。一个用例定义一组用例实例。用例的UML表示：用例名称第48页/共81页识别用例从每个Actor出发，考虑：参与者希望系统执行的主要任务是什么？参与者是否将在系统中创建、存储、更改、删除或读取数据？参与者是否需要将突发变更或外部变更通知给系统？是否需
16、要将系统中发生的某些特定事件通知给此参与者？此参与者是否将执行系统启动或关闭操作？第49页/共81页识别用例用例要点用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言，用户观点而非系统观点用例的粒度50第50页/共81页识别用例-用例的粒度常见错误：把交互的某个步骤当作用例把系统活动当作用例粒度过细，陷入功能分解四轮马车的错误（增加、删除、修改、查询）51第51页/共81页用例分析流程识别系统边界和参与者列出事件识别用例编写用例规约（UseCaseSpecification）识别用例的关系对用例进行优先级排序第52页/共81页编写用例规约-用例的路径53第53页/共81页编写
17、用例规约-用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流）1.2 3.扩展点 2a.2a1.补充说明第54页/共81页编写用例规约-用例模板要素Mandatory（必须）（必须）Element（要素）（要素）Phase（阶段）（阶段）Author and date of the first versionGathering（需求收集阶段）Author and date of the latest revisionThroughout（全过程）ActorsGatheringUse case description用例说明GatheringPreconditions前置条件S
18、pecification（需求规格阶段）Postconditions后置条件SpecificationPriorityGatheringNormal course of events主流程SpecificationAlternate courses分支流程SpecificationExceptions and Issues异常SpecificationIncludesGatheringNotesThroughout第55页/共81页编写用例规约-前置、后置条件前置条件：开始用例前所必需的系统及其环境的状态后置条件：用例成功结束后系统应该具备的状态编写前置、后置条件的意义：某些用例依赖于其他用例
19、一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理订单”）有助于识别漏掉的用例如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”）第56页/共81页编写用例规约-事件流说明用例如何开始和结束。说明在参与者和用例之间交换的是什么数据。说明事件流，而不只是功能，每个动作都应从“当参与者.时”开始。只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。避免不明确的术语，如“例如”、“等等”和“信息”详细说明事件流，即回答所有包含“什么”的问题。说明系统要做什么，而不是系统怎样做。第57页/共81页编写用例规约-事件流使
20、用结构化的叙述格式每个use case只描述没有大的分支的行为的单个线索。在事件流里要对事件流进行结构化说明基本事件流v描述每个情节的行为者:目标语句对的顺序v假设之前的每一步都是成功的备选事件流v将失败情节作为延伸部分对于失败中的失败，用更长的前缀标记更深一层的失败情节第58页/共81页编写用例规约-识别扩展点的思路参与者的选择另一条成功路线“用支票结账”参与者错误的操作“没有提供Email地址”每次系统验证时，都暗示着扩展“系统验证账户名和密码”系统内部出现错误59第59页/共81页Actor与Use Case的交互每当找到一个用例，就应确定哪些参与者将与之进行交互定义一个通信关联关系，其
21、导航方向应该与参与者和用例之间的信号传输方向相同。第60页/共81页Actor与Use Case交互图用例名称Actor第61页/共81页用例分析流程识别系统边界和参与者列出事件识别用例编写用例规约（UseCaseSpecification）识别用例的关系对用例进行优先级排序第62页/共81页识别用例的关系包含(include)关系扩展(Extend)关系泛化(generalization)关系第63页/共81页识别用例的关系-用例的包含关系包含关系是指基础用例(Base)会用到被包含用例(Inclusion)，就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于：从基本用例中分解出来
22、这种的行为：它对于了解基本用例的主要目的不是必需的，只有它的结果才比较重要。分解出两个或者多个用例所共有的行为。第64页/共81页识别用例的关系-用例的包含关系65第65页/共81页识别用例的关系-用例的扩展关系扩展（extend）关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。基础用例(Base)中定义有一至多个已命名的扩展点，基本用例自身应该是完整的，即基本用例应该是可理解并且有意义的，而不必引用任何扩展用例。但是基本用例并不独立于扩展用例，因为如果无法遵循扩展用例，就不能执行基本用例。扩展是有条件的，它是否执行取决于在执行基本用
23、例时所发生的事件。基本用例并不控件执行扩展的条件，这些条件在扩展关系中进行说明。扩展用例可以访问和修改基本用例的属性。但是基本用例看到到扩展用例，也无法访问它们的属性。第66页/共81页识别用例的关系-用例的扩展关系扩展的目的在于：表明用例的某一部分是可选的（或者可能可选）的系统行为。这样，你就可以将模型中的可选行为和必选行为分开。表明只有在特定条件下（有时候是异常情况下）才执行的分支流，如触发警报表明可能有一组行为段，其中的一个或者多个段可以在基本用例中的扩展点处插入。所插入的行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互。67第67页/共81页识别用例的关系-用例的泛化关
24、系当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。父用例可以特化形成一个或者多个子用例，这些子用例代表了父用例比较特殊的形式。尽管在大多数情况下父用例是抽象的，但是无论是父用例还是子用例这两者都不要求一定抽象。子用例继承父用例的所有结构、行为和关系。同一父用例的子用例都是该父用例的特例。第68页/共81页识别用例的关系-用例的泛化关系现金支付信用卡支付支付第69页/共81页用例分析流程识别系统边界和参与者列出事件识别用例编写用例规约（U
25、seCaseSpecification）识别用例的关系对用例进行优先级排序第70页/共81页对用例进行优先级排序-排序原则以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险、时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程71第71页/共81页用例 vs.场景（Scenario）场景是用例的一个实例，表示用例的一个流程，可能是主流程，也可能是分支流程第72页/共81页大量用例时的组织按参与者分包按主题分包按开发团队分包按发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包73第73页/共81页用例包用例包是用例
26、、参与者、关系、图和其他包的集合；通过将其划分为若干个较小部分来建立用例模型第74页/共81页划分用例包标准用例包中的对象都要是直接包含在包中的对象。划分到一个包的情况：与同一个参与者交互的用例要划分在一个包内。相互之间有包含和扩展关系的包。都为可选，且由系统一起提供（或不提供）的包。顶级包包括所有的顶级用例包、所有顶级参与者，以及所有的顶级用例。第75页/共81页用例图用例图显示参与者、用例、用例包以及它们之间的关系。对每一个用例包都做一个用例图。对顶级包做一个用例图。第76页/共81页用例建模之需求分析过程第77页/共81页用例建模之需求的组成第78页/共81页参考文档编写有效用例（WritingEffectiveUseCases）UML和模式应用（ApplyingUMLandPattern）Rational官方文档（RationalRUP中文教程）79第79页/共81页80谢谢！第80页/共81页81感谢您的观看！第81页/共81页