了解RUP的基础知识

RationalOOAD目标了解RUP的基础知识能够使用RationalRose能够进行面向对象的分析和设计（OOAD）目录1.RUP2.OO基础3.Requirementsoverview4.Analysisanddesignoverview5.Architecturalanalysis6.Use-caseanalysisRUPRUP—RationalUnifiedProcessRUP是一个软件工程过程（Softwareengineeringprocess)RUP提供了一种在开发组织内分配任务和责任的纪律性方法。目标是确保按照预计的进度和预算，生产出满足最终用户需求的高质量的软件。BestPractices迭代式开发每个迭代是一个完整的过程，要产生可运行的结果根据风险决定迭代的次序管理需求使用组件体系结构可视化建模（UML）不断地验证质量（ContinuouslyVerifyQuality）测试各个方面：功能、可靠性、性能测试每一个迭代管理变更（ManageChange）RUP的四个阶段（Phase）Inception定义项目的Scope20%UseCases建立项目的商业计划Elaboration制定项目计划掌握需求（80%）建立体系结构基准Construction通过若干迭代，生成Beta版Transition提交给最终用户阶段、迭代和工作流的关系2.OO基础模型（Model）模型是对现实的简化建模就是获取系统的关键部分可视化建模就是用标准的图形表示法来建模可视化建模的好处统一的模式：用户、分析员、设计师和实施员都用一个语言(UML)模型更能反映现实世界更精确的描述实体基于自然划分的分解容易理解和维护把类组织成更有意义的元素，形成软件构架为不同的人提供不同级别的抽象促进复用(reuse)可以有一个类复用、多个类（或一个组件）的复用、应用模式等复用方式不止是复用代码，而是复用建立原始工件时需要的所有分析、设计、实现、测试、文档化可视化建模让你从复用的角度看，如果想复用工件，什么是可用的UMLUML(UnifiedModelingLanguage)是可视化、说明、构建和文档化软件系统工件的标准语言UML可以做下面的建模数据建模业务建模对象建模组件建模UML可以用于可视化建模系统与外界的交互系统的行为系统的结构系统的构架系统的组件Views模型由不同的view和diagram构建而成，描述了不同的视点和系统的构建块View是一个对特定涉众有意义的模型的视点View是模型的“碎片”Rose中的“4+1view”LogicalView分析师设计师structureProcessView系统集成员PerformanceScalabilityThroughputImplementationView编程人员SoftwaremanagementUse-caseView最终用户FunctionalityDeploymentView系统工程SystemtopologyDeliveryinstallationCommunicationViewsUse-caseView是其他view的“心脏”，因为它说明了系统做什么包括用例图、用例事件流和补充规约，也可以包括活动图它说明了塑造系统构架需要的精力LogicalView支持系统的功能性需求包括用例实现、类图和交互图，也包括状态图和活动图ProcessView阐述系统的性能、伸缩性和吞吐量包括形成系统并发和同步机制的线程和进程对于单处理环境是不必要的ComponentView（implementationView）说明开发的容易，软件的管理、复用、子合同和off-the-shelf组件以分包、分层和配置管理的形式描述了静态软件模型的组织（源码、数据文件、组件、可执行体等）DeploymentView说明部署、安装和性能的主题只用于分布式系统表示如何把各种执行体和其他运行时组件映射要下层平台或计算节点显示一个部署对象（Object）对象代表了一个实体，可以是物理的（如一个卡车）、概念的（如一个化学过程）或软件的（如一个链表）对象是一个有定义良好的边界和标识，并封装了状态（State）和行为（Behavior）的实体状态用属性（attribute）和关系（relation）表示是对象可以处于的状况对象的状态随时间变化行为用操作（Operation）、方法（Method）和状态机（Statemachine）表示行为决定对象如何动作和做反应对象的可见行为用一系列它相应的消息来模型化标识（Identity）每个对象有唯一的标识例如，一个名叫JClark的教授的信息如下（她的状态是tenured）：Name:JClark EmployeeID：567138(标识)Status:TenuredDiscipline:Finance行为SubmitFinalGrades

AcceptCourseOfferingTakesabbatical面向对象的基本规则抽象（abstraction）对象区别于其他对象的本质特征定义与使用者视点相关的边界不是具体的表现，而是理想化的本质封装（Encapsulation）对用户隐藏了实现，用户只能通过接口与对象通信封装通常叫“信息隐藏”封装使对象的状态不受用户的影响，使用户不受对象实现变化的影响模块化（Modularity）把复杂的东西分成可管理的小块帮助人们理解复杂的系统层次（Hierarchy）抽象级别的树状结构可以分成：聚合（aggregation）层次、类（class）层次、包含（containment）层次、继承（inheritance）层次、分割（partition）层次、特殊化（specialization）层次、类型（type）层次同一层的元素具有相同的抽象级别类类是对一系列具有相同属性、操作、关系和语义的对象的描述对象是类的实例类定义了它的所有对象的结构和行为的模板RequirementsOverviewIntroduction相关的活动查找主角（Actor）和用例（UseCase）建立用例模型结构详细说明用例获取常用词汇相关的工件用例模型（UseCaseModel）在Use-caseView中创建包括用例图（UseCaseDiagram）和用例规约（UseCaseSpecifications），也可以包括活动图用用例和主角描述系统的功能性需求的模型用例模型最主要的功能是和客户/最终用户交流系统的行为（behavior）是顾客和开发者之间的契约对于分析、设计和测试活动都是至关重要的补充规约（SupplementarySpecification）非功能性需求词汇表（Glossary）角色：系统分析员Actor&UsecaseActor定义：与系统进行交互的人或事物种类人外部系统外部设备或TimerUsecase定义：是actor与系统的一系列交互特点：完成actor的某个目的（不是功能）起始于actor的输入

其中，系统是一个黑盒用于描述系统行为，但不描述如何实现Usecasediagram表示usecase与actor之间以及usecase之间的关系Usecasemodeling步骤初始化用例模型在“UseCaseView”中建立一个“UseCaseModel”包在“UsecaseModel”下建立“Actors”和“UseCases”包识别Actor根据Actor的定义识别Actor把识别的actor放到“Actors”包中识别Usecase根据Usecase的定义和特点，识别Usecase为每个usecase建立一个包，名字与那个usecase的名字相同，并在每个usecase的包下面加入相应的usecase画用例图在“UseCaseModel”下面新建一个用例图，其中表示出actor和usecase以及usecase之间的关系为每个usecase写用例规约（Usecasespecification）更新词汇表编写补充规约用例规约用例名字（Name）简要说明（Briefdescription）事件流（FlowsofEvents）系统对于某个用例做了什么的文本描述要被客户理解描述了用例何时以及如何开始和结束，用例何时与主角交互以及主角与用例之间的信息交换不描述用户界面的细节包括：基本流（Basicflow）：成功的流，又叫happyflow备选流（Alternationflow）特殊需求（Specialrequirements）前置条件（Pre-conditions）后置条件（Post-conditions）扩展点（Extensionpoints）其他场景（Scenarios）场景是用例的一个实例活动图可以用活动图描述用例的事件流可以用包（Package）把用例组织起来Usecase之间的关系有ExtendIncludeGeneralizationUsecasesRelationships--Extend作用表示基本用例（Baseusecase）的有条件的部分，只在某些环境下执行模型化复杂的或可选的路径。

扩展用例（Extensionusecase）&基本用例扩展用例只有在基本用例中的某种条件满足时才能执行，如果没有基本用例，扩展用例不能运行扩展用例可以扩展多个基本用例基本用例的basicflow执行时,扩展用例不一定执行

扩展点表示UsecasesRelationships--Include反映了多个用例的共同点抽象用例和具体用例抽象用例不能单独执行，必须与包括（也就是执行）它的具体用例一起执行抽象用例没有特定的actor，它的actor实际上包括它的具体用例的actor抽象用例可以被几个其他的用例复用

具体用例的基本流执行时，抽象用例一定执行表示Concreteabstract<<include>>检查点（1）需求：用例模型用例模型可以理解吗？通过研究用例模型，能形成对系统功能和它们之间的联系的清晰理解吗？满足了所有的功能需求吗？用例模型中有多余的行为吗？模型到包的分解合适吗？需求：Actor识别了所有的actor吗？每个actor至少参与了一个用例吗？每个actor确实是一个角色(role)吗？是否应该合并或分解？是否有两个actor在一个用例中扮演相同的角色？Actor是否有直观的、描述性的名字？用户和客户是否能理解这些名字？需求：词汇表每个术语都有清晰、简练的定义吗？每个术语都包含在用例描述中吗？属于在actor和用例的简单描述中是一致的吗？检查点（2）需求：用例每个用例中至少有一个actor吗？每个用例都独立于其他用例吗？如果两个用例总是以同样的顺序执行，也许应该合并成一个有具有非常类似的行为或事件流程的用例吗？为了以后不会混淆，用例具有唯一的、直观的、说明性的名字吗？客户和用户能理解用例的名字和描述吗？需求：用例规约谁要执行用例明确吗？用例的目的明确吗？简单的描述刻画了用例的真实情况吗？用例的时间流程何时/如何开始/结束明确吗？Actor和用例的通信顺序符合用户的期望吗？Actor的交互和信息交换清晰吗？是否有过于复杂的用例？ArchitectureAnalysisArchitectureAnalysisOverview（1）基本构架分析时定义系统pieces/parts及其之间关系的最初的尝试，这时需要把pieces/parts组织成有明显依赖的定义良好的layers，关注的是系统的上层layers。构架分析是构架设计师决定如何进行分析的时候，大部分精力用于对分析模式和习惯达成共识，以便分析工作不用在“firstprinciple”上花费太多时间。目的根据从相似系统或相似问题领域中获取的经验，定义备选构架。定义系统的体系结构模式、关键机制和建模方式定义重用策略为策划提供输入在下列情况下，这个工作可以不做：系统体系结构的风险低没有具有相关领域的有经验的构架设计师ArchitectureAnalysisOverview（2）输入用例模型补充规约词汇表业务模型软件构架文档设计模型设计指南输出更新的软件构架文档更新的设计模型更新的设计指南用例实现(只是识别出来，但没有开发)步骤开发构架概述调查可用资产

定义子系统的高层组织确定分析机制确定核心的抽象概念创建用例实现开发高层部署模型评审结果角色：构架设计师Step1:开发构架概述目的：通过研究和评估高层构架选项来简化有关系统的预先设想

将有关既定系统高层结构的初步理念传递给资助人、开发团队和其他涉众在项目的初期、甚至是在项目的提议阶段编写内容：反映有关实现项目前景的初期决策和可行的假设，以及与系统的物理和逻辑结构、非功能性需求有关的决策构架设计师将收集有关当前环境的信息，并将它们记录在部署模型中，如电子商务系统中可能会了解：现有网络的逻辑设计和物理设计现有数据库和数据库的设计现有的Web环境（服务器、防火墙等等）现有的服务器环境（配置、软件版本和预计的升级）现有标准（网络、命名和协议等等）构架概述的作用：沟通工具Step2：调查可用资产

目的确定与项目有关的资产。分析资产和项目需求之间的一致程度与偏差程度。决定是否采用资产作为某些系统领域的基础。确定并列出项目中可以复用的潜在资产。进行初步评估，确保可以获取必要的支持Step3:定义子系统的高层组织(1)模式（Pattern）&框架（Framework）模式通用问题在特定情况下的通用解决方法分析/设计模式小范围技术问题的解决方法解决方法的片断框架定义解决问题的通用方法骨架的解决方法，它的细节是分析/设计pattern设计模式描述了通用设计问题描述了问题的解决方案讨论应用模式的结果和策略构架模式（Architecturepattern）构架模式代表了软件系统的基本机构的组织模式，提供了一系列预定义的子系统，阐述了子系统的责任，还包括组织子系统之间关系的规则和指南。Step3:定义子系统的高层组织(2)几种典型的构架模式Layers：应用被分成不同层次的抽象，从上面的应用层到下面的实现/技术层Model-view-controller(MVC)：应用被分成3部分：作为业务规则和底层数据的Model、把信息显示给用户的View和处理用户输入的Controller。Pipesandfilters：数据在流中处理，流通过pipe从filter流向filter，filter是处理步骤Blackboard：独立的特定应用通过处理相同的数据结构，相互协作以解决问题ArchitecturalLayers的模型化用stereotypedpackage，如<<layer>>stereotype课程注册系统决定采用Layers型的构架（Demo）包之间的关系(dependency)对supplier包的修改会影响client包Client包不能独立地被重用因为它要依赖于supplier包避免依赖关系形成回路合并包拆分包Step4:识别分析机制—构架机制构架机制关于通用标准、方针、管理的策略，是项目中应该标准化的问题的实现，每个人都应该以相同的方式使用这些概念，复用同样的机制来执行操作代表了经常遇到的问题的通用解决方案，可以是结构模式、行为模型或两者都是。构架机制是系统的需求和如何实现的‘glue’的重要部分，提供了对实现环境的限制。由构架设计师来管理构架机制选择构架机制、通过集成它们来验证有效性、证实它们确实能工作、把它们用于其他的系统设计种类Analysismechanism(conceptual)：例如：distributionDesignmechanism(concrete)：例如：RMIImplementmechanism(actual)：例如：Java1.1Step4:识别分析机制—分析机制基本：分析机制关注的是系统的非功能性需求，建立对非功能性需求的支持通过向设计师提供复杂行为的简单描述来减少分析的复杂性，增强一致性分析机制被用作复杂行为在构架的中间或更低层的‘placeholder’，通常与具体的问题域无关，而是计算机科学的概念例子PersistencyCommunication(IPCandRPC)MessageroutingDistributionProcesscontrolandsynchronizationInformationexchange,formatconversionSecurityErrordetection/handling/reportingRedundancyLegacyinterfaceStep4:识别分析机制—分析机制特征Consistency例子粒度（Granularity)：需要保存的对象大小的范围。容量(Volume)：需要保存的对象的数量。持续时间(Duration)：通常对象保留时间。访问机制：如何唯一地标识并访问给定对象？访问频率：对象是否大致保持恒定不变？它们是否经常更新？可靠性（reliability)：对象是否应当在进程、处理器或者整个系统崩溃后继续存在？进程间通信机制延时（latency）：进程间通信有多快同步（synchronicity)：消息大小协议、流控制、缓冲等遗留接口机制延时（latency）：有多快持续时间(Duration)：通常对象保留时间访问机制：如何唯一地标识并访问给定对象？访问频率：对象是否大致保持恒定不变？它们是否经常更新？安全机制数据粒度：package-level,class-level,attribute-level

用户粒度：singleuses,roles/groups

安全规则：基于数据值、基于数据的算法、基于用户和数据的算法权限类型：读、写、创建、删除或其他操作Step4:识别分析机制识别分析机制的过程列出所有的分析机制绘制客户类到分析机制的映射图识别分析机制的特征Modelusingcollaborations课程注册系统的分析机制Persistence分布安全遗留接口Step5:识别关键抽象(Keyabstraction)基础关键抽象是通常在需求中揭示，系统必须处理的概念关键抽象的来源领域的知识需求GlossaryDomainmodel或businessmodel定义关键抽象定义分析类关系用类图模型化分析类及其关系把分析类向分析机制映射关键抽象的例子（课程注册系统）ProfessorStudentScheduleCourseCatalogCourseOfferingCourse检查点GeneralIsthepackagepartitioningandlayeringdoneinalogicallyconsistentway?识别了必要的分析机制吗？包Haveweprovidedacomprehensivepictureoftheservicesofthepackagesinupper-levellayers?类对关键的实体类及其之间的关系进行识别和准确的建模了吗？每个类的名字清晰地反映了它承担的角色吗？关键抽象/类及其之间的关系和商业模型、领域模型、需求、词汇表一致吗？UseCaseAnalysis概要目的找出完成usecase需要的类把usecase的行为分配到类中识别类的责任、属性和关联标记构架机制的使用输入词汇表补充规约用例建模指南用例模型用例实现（只是识别，没有开发）软件构架文档输出分析类分析模型和/或设计模型开发后的用例实现概要用例实现对用例模型中的每个用例，在设计模型中都有相应的实现提供从分析和设计到需求的可跟踪性用例实现结构用例实现包是组织用例的类和交互图的方式每个用例都对应一个用例实现包可跟踪性图交互图时序图（SequenceDiagrams）（动态）协作图（CollaborationDiagrams）（动态）类图（ClassDiagrams）（静态）用例分析的步骤补充用例描述对每个用例实现从用例行为中找出类把用例行为分配到类对每个分析类描述属性和关联描述责任限定分析机制（analysismechanism）确定属性建立分析类之间的关联关系说明分析类之间的事件依赖关系整合分析类Step1:补充用例描述用例的描述往往不够查找分析类用户通常不关心系统内部的信息，所以开始时的用例描述是黑盒的为了发现分析类，需要从系统内部的视点对用例进行白盒描述例如：课程注册系统中，学生可能喜欢说“系统显示课程列表”，但是这不能说明系统内部是如何实现的。为了给出系统内部是如何工作的，我们要加入:系统从课程目录遗留数据库中取得课程列表Step2:从用例行为中找出类--分析类边界类(boundaryclass)是接口与系统外部某些事物的媒介分类用户接口类系统接口类设备接口类对象的生命周期与usecase的实例相同控制类(controlclass)用例行为的协调者有的用例没有控制类，复杂的用例可以有多个控制类控制类会提供以下行为：与周围环境无关定义控制逻辑（event的顺序）和usecase事务如果实体类的内部结构或行为变化，控制类很少会变化使用或设定几个实体类的内容，因此需要协调这几个实体类的行为每次被激活，行为方式不同（flowofevent与多个状态有关）Step2:从用例行为中找出类--分析类实体类(entityclass)系统的关键抽象主要责任是用于保存和管理系统的信息，如一个event，一个人或一些实际存在的对象的信息。通常是持久化的(persistent)通常不特定于某个usecaserealization，有时甚至不特定于系统。分析类的角色Step2:从用例行为中找出类--方法边界类最初识别时，每对actor/usecase对应一个边界类控制类建议在初始识别时每个用例对应一个控制类实体类(entityclass)来源词汇表（需求阶段）Business-domainModel（业务建模阶段）Usecaseflowofevents（需求阶段）Keyabstractions（构架分析中识别）Actor的信息可以作为一个实体类用过滤名词方法寻找实体类在Usecaseflowofevents中画出名词去掉重复的候选去掉含糊的候选去掉actor去掉实现结构去掉属性去掉操作Step3:把用例行为分配到类指南：把责任分配到类边界类和actor交互的行为实体类与数据抽象封装有关的行为控制类特定到一个usecase或一部分非常重要的事件流程的行为动态建模：用时序图和协作图来描述用例行为注意：对所有基本流和备选流都要进行分析时序图时序图表示如何一步步的完成系统的一个功能时序图是用于决定类责任和接口的主要信息来源时序图描述了对象间的交互模式通过对象的“生命线”和他们相互发送的消息来显示对象时序图与协作图在语义上是相同的，只是时序图中的消息是按时间顺序分布的时序图表示的是一个场景(scenario)组成主角对象消息生命线Focusofcontrol表示对象直接或通过子过程执行动作的一段时间协作图协作图显示对象之间的交互协作图强调参与交互的对象的组织适合分析活动，适合表示少数对象的简单交互组成主角对象LinksLink是对象通信的途径消息类之间的关系Associationconnection类的关联表示的是对象之间的关系Aggregation&CompositionIsapart-ofComposition与aggregation