第八章 UML统一建模语言

8.1 概述

• UML（Unified Modeling Language）是软件界第一个统一的建模语言，该方法结合了Booch, OMT, 和OOSE方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术。
• UML是一种标准表示，是一种基于面向对象的可视化的通用(General)建模语言。提供统一的交流标准——UML图。

面向对象建模的基本概念

1.什么是模型？

• 模型是对系统的完整的抽象表示，建模是在不同层次上对系统的描述。
• 开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。

2.为什么要建模？

• 鉴于软件系统的复杂性和规模的不断增大，需要建立不同的模型对系统的各个层次进行描述。
  软件模型包括：数学模型、描述模型和图形模型。
• 便于开发人员与用户的交流。
• 模型为以后的系统维护和升级提供了文档。
  
• UML作为一种可视化的建模语言，提供了丰富的基于面向对象概念的模型元素及其图形表示元素。

8.1.1 UML的形成

8.1.2 UML的主要内容

• UML的定义包括UML语义和UML表示法两个部分。

• (1)UML语义

  • 描述基于UML的精确元模型(meta-model)定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
  • UML支持各种类型的语义。如布尔、表达式、列表、阶、名字、坐标、字符串和时间等，还允许用户自定义类型。

• (2)UML表示法

  • 定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。
  • 这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。

UML的主要构成：

• UML是一种标准化的图形建模语言，它是面向对象分析与设计的一种标准表示。

1.视图

• 一个系统应从不同的角度进行描述，从某一个角度观察到的系统就叫做视图。
• 视图由多个图构成，不是一个图表，而是在某一个抽象层上，对系统的抽象表示。
• 为系统建立一个完整的模型图，需定义一定数量的视图，每个视图表示系统的一个特殊的方面。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。
• 

2.图

• UML语言定义五种类型，9种不同的图，把他们有机结合起来就可以描述系统所有视图。
• 用例图：用户角度描述系统功能，指出各功能操作者。
• 静态图：表示系统的静态结构。包括类图、对象图、包图。
• 行为图：描述系统的动态模型和组成对象间的交互关系。包括状态图、活动图。
• 交互图：描述对象间的交互关系。包括顺序图、合作图。
• 实现图：用于描述系统的物理实现。包括构件图、、部件图。

3.模型元素

• 代表面向对象中的类、对象、关系和消息等概念，是构成图的最基本的常用的元素。一个模型元素可以用于多个不同的图中。

4.通用机制

• 用于表示其他信息，比如注释、模型元素的语义等。另外，为了适应用户的需求，它还提供了扩展机制(Extensibility mechanisms) ，包括构造型(Stereotype)、标记值(Tagged value)和约束(Constraint)。使用UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户。

8.1.3 UML的特点

• (1)统一标准
  • UML统一了Booch、OMT和OOSE等方法中的基本概念，已成为OMG的正式标准，提供标准的面向对象的模型元素的定义和表示。
• (2)面向对象
  • 吸取大量面向对象技术领域种其他流派的精华。删除大量易引起混乱的、多余的和极少使用的符号，也添加了一些新符号。
• (3)可视化、表示能力强
  • 可用于复杂软件的建模、系统的逻辑模型或实现模型。
• (4)易掌握、易用

8.2 通用模型元素

• 模型元素是UML构造系统的各种元素，是UML构建模型的基本单位。分为
  • 1.基元素
    • 由UML定义的模型元素。
  • 2.构造型元素
    • 在基元素的基础上增加了新的定义而构造的新的模型元素。
    • 构造型元素用括在双尖括号<< >>的字符串表示。

8.2.1 常用模型元素

• 可以在图中使用的概念统称为模型元素。
• 模型元素在图中用其相应的视图元素（符号）表示，图中给出了常用的元素符号：类、对象、结点、包和组件等。
• 
• 模型元素和模型元素之间的连接关系也是模型元素，常见的关系有关联、泛化、依赖和聚合。（聚合是关联的一种特殊形式）
  
  • 关联：连接（connect）模型元素及链接(link)实例。
  • 依赖：表示一个元素以某种方式依赖于另一种元素。
  • 泛化：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。
  • 聚合：表示整体与部分的关系。

8.2.2 关联和链

• 关联是两个或多个类之间的一个关系。链是关联的具体体现。
• 关联分为二元关联、三元关联、多元关联。
  
• 关联的重数：
  • 重数表示多个对象与对方对象相连接，常用的重数符号有：
    • "0…1"表示零或1
    • "0…*“或”*"表示零或多个
    • "1…*"表示1或多个
    • "1,3,7"表示1或3或7(枚举型)
    • 默认值为1
      
• 有序关联与导航(导引)
  • 在关联的**多端标注{ordered}**指明这些对象是有序的。
  • 关联可以用箭头，表示该关联使用的方向(单向或双向)，称为导引或导航(navigation)。
    
• 受限关联
  • 使用限定词对该关联的另一端的对象进行明确的标识和鉴别，如图。如果对关联的含义作出某种限制，称为受限关联。
    

8.2.4 约束

• UML中提供了一种简便、统一和一致的约束，是各种模型元素的一种语义条件或限制。一种约束只能应用于同一类元素。
• 约束的表示
  • 如果约束应用于一种具有相应视图元素的模型元素，它可以出现在它所约束元素视图元素的旁边。
  • 通常一个约束由一对花括号括起来({constraint})，花括号中为约束内容。
  • 如果一条约束涉及同一种类的多个元素，则要用虚线把所有受约束的元素框起来，并把该约束显示在旁边。
• 约束可分为：对泛化的约束、关联的约束
  • 对泛化的约束
    • 应用于泛化的约束，显示在大括号里，若有多个约束，用逗号隔开。如果没有共享，则有一条虚线通过所有继承线，并在虚线的旁边显示约束。
      
    • 对泛化常用的约束
      • 1.complete：说明泛化中所有子元素都已在模型中说明，不允许再增加其它子元素。
      • 2.disjoint：父类对象不能多于一个型的子对象。
      • 3.incomplete：允许增加其它子元素。
      • 4.overlapping：表示重载，给定父类对象可有多于一个型的子对象。
  • 关联的约束
    • 对关联常用的约束：
      • 1.implicit：该关联只是概念性的，在对模型进行精化时不再用。
      • 2.ordered：具有多重性的关联一端的对象是有序的。
      • 3.changeable：关联对象之间的链(Link)是可变的（添加、修改、删除）。
      • 4.addonly：可在任意时刻增加新的链接。
      • 5.frozen：冻结已创建的对象，不能再添加、删除和修改它的链接。
      • 6.xor：“或约束”，某时刻只有一个当前的关联实例。
        

8.2.6 依赖

• 依赖关系描述的是两个模型元素（类，组合，用例等）之间的语义上的连接关系，其中一个模型元素是独立的，另一个模型元素是非独立的（或依赖的）。
  如图表示类A依赖于类B的一个友元依赖关系。
  
• 依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系有不同的变体(varieties)：
  • <1>抽象(abstraction)：从一个对象中提取一些特性，并用类方法表示。
  • <2>绑定(binding)：为模板参数指定值，以定义一个新的模板元素。
  • <3>组合(combination)：对不同类或包进行性质相似融合。
  • <4>许可(permission)：允许另一个对象对本对象的访问。
  • <5>使用(usage)：声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能(包括调用、实例化、参数、发送)。
  • <6>跟踪(trace)：声明不同模型中元素的之间的存在一些连接。
  • <7>访问或连接(access)：允许一个包访问另一个包的内容。
  • <8>调用(call)：声明一个类调用其他类的操作的方法。
  • <9>导出(derive)：声明一个实例可从另一个实例导出。
  • <10>友元(friend)：允许一个元素访问另一个元素，不管被访问的元素是否具有可见性。
  • <11>引入(import)：允许一个包访问另一个包的内容并被访问组成部分增加别名。
  • <12>实例(instantiation)：关于一个类的方法创建了另一个类的实例声明。
  • <13>参数(parameter)：一个操作和它参数之间的关系。
  • <14>实现(realize)：说明和其实之间的关系。
  • <15>精化(refine)：声明具有两个不同语义层次上的元素之间的映射。
  • <16>发送(send)：信号发送者和信号接收者之间的关系。

8.2.7 细化

• 有两个元素A和B，若B元素是A元素的详细描述，则称为B元素细化A元素。
• 细化与类的抽象层次有密切的关系，在构造模型时要经过逐步细化，逐步求精的过程。
  

8.2.8 注释

• 注释用于对UML语言的元素或实体进行说明、解释和描述。通常用自然语言进行注释。
  

8.3 用例建模

• UML的用例模型被推荐为识别和捕获需求的首要工具。
• 用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计方法的主流。

8.3.1 用例建模概述

• 用例建模技术，用于描述系统的功能需求，宏观上给出模型的总体轮廓。
• 用例模型的作用：沟通、识别、确认。

8.3.2 用例模型

• 用例模型描述外部执行者所理解的系统功能，即待开发系统的功能需求。
• 用例模型驱动了需求分析之后各阶段的开发，还被用于验证和检测所开发的系统，影响了UML的各个模型。
• 用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中，构成用例图的主要元素是用例和执行者及其它们之间的联系。
• 创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。
• 如何建立用例模型
  • 建立系统用例模型的过程就是对系统进行功能需求分析的过程。
    
  • 一、确认执行者
    • 执行者是指用户在系统中所扮演的角色，执行者用类似人的图形来表示，但执行者可以是人，也可以是一个外界系统。
    • 如何确定执行者：
      
  • 二、用例
    • 从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。在UML中，用例被定义成系统执行的一系列动作（功能）。
    • 用例有以下特点：
      • 用例实现一个具体的用户目标。
      • 用例由执行者激活，并将结果值反馈给执行者。
      • 用例必须具有功能上的完整描述。
    • 如何确定用例：
      
  • 三、用例之间的关系
    • 执行者与用例之间通常是一种关联。
    • 用例之间的联系：
      
      

8.3.3 用例图实例

8.3.4 用例分析—场景分析法

8.4 静态建模

• 静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。
• 熟练掌握基本概念、区分不同抽象层次以及在实践中灵活运用，是三条最值得注意的建模基本原则。
• UML的静态建模机制包括：
  • 用例图、类图、对象图、包图、构件图、配置图

8.4.1 对象类与对象

• UML的对象类图与对象图表达了对象模型的静态结构，能够有效建立专业领域的计算机系统对象模型。
  
• 类图由系统中使用的类以及它们之间的关系组成，分为长式和短式。
• 类及类型名均用英文大写字母开头，属性及操作名为小写字母开头。(类图是构建其他图的基础)
• 对象是对象类的实例，用对象图来描述，对象图亦分为长式和短式。
• (1)属性：用来描述类的特征，表示需要处理的数据。
  • 属性定义：visibility attribute-name : type = initial-value {property-string}
  • 可见性表示该属性对类外的元素是否可访问。分为：
    • public(+) 公有的(任何类都可以访问该属性)
    • private(-) 私有的(表示不能被别的类访问)
    • protected(#) 受保护的，表示该属性只能被该类及其子类访问。
    • 如果可见性未申明，表示其可见性不确定。
• (2)操作：对数据的具体处理方法的描述则放在操作部分，操作说明该类能做些什么工作。操作通常称为函数，是类的一个组成部分，只能作用于该类的对象上。
  • 操作定义：visibility operating-name(parameter-list): return-type {property- string} 可见性 操作名（参数表）；返回类型{约束特性}
  • 参数表：参数名：类型，…
    Parameter-name :type =default-value
• 二、类的识别
  • 面向对象方法的一个难点，又是建模的关键。常用方法：
  • 1.名词识别法
    • 识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。
  • 2.系统实体识别法
    • 不关心系统的运作流程及实体之间的通信状态，而只考虑系统中的人员、组织、地点、表格、报告等实体，经过分析将他们识别为类（或对象）。
    • 被识别的实体有：
      • 系统需要存储、分析、处理的信息实体；
      • 系统内部需要处理的设备；
      • 与系统交互的外部系统；
      • 系统相关人员；
      • 系统的组织实体。
  • 3.从用例中识别类
  • 4.利用分解与抽象技术
    • 分解技术：将整体类和组合类分解。可控制单个类的规模。
    • 抽象技术：根据一些类的相似性建立抽象类，并建立抽象类与这些类之间的继承关系。
    • 抽象类实现系统内部的重用，很好控制复杂性，为所有子类定义一个公共界面，使设计局部化，提高系统的可修改性和可维护性。

8.4.2 UML中类之间的关系

• 类之间的关系有关联、聚集、泛化、依赖、细化。
• 一、关联
  • 关联是类之间的连结，分为：1.常规关联，2.多元关联，3.有序关联，4.受限关联，5.或关联，6.关联类， 7.其他关联(递归关联——一个类到自身的关联)

• 二、聚集
  • 聚集是一种特殊的关联，指出类间“整体-部分”关系。
  • 1.共享聚集
    • 其“部分”对象可以是任意“整体”对象的一部分。当“整体”端的重数不是1时，称聚集是共享的。
      
  • 2.组合聚集
    • 其“整体”(重数为0、1)拥有它的“部分” 。部分仅属于同一对象，整体与部分同时存在。
      
• 三、泛化
  • 泛化指出类之间的“一般与特殊关系”，即继承关系。父类与子类之间构成类的分层结构。
    
  • 抽象类：指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征。并附以{abstract}。
  • 交叠泛化：在继承树中，若存在某种具有公共父类的多重继承，称为是交叠(overlapping)的。否则是不交的(disjoint)。
  • 完全泛化：一般类特化出它所有的子类，称为完全泛化，记为{complete}。
  • 不完全泛化：即未特化出它所有的子类，称为是不完全泛化的，表示为{incomplete}。
• 四、类图的抽象层次和细化关系
  • 在需求分析阶段，类图是研究领域的概念；
  • 在设计阶段，类图描述类与类之间的接口；
  • 而在实现阶段，类图描述软件系统中类的实现。
  • 类图分为三个层次：
    • 1.概念层：类图描述应用领域的概念。
    • 2.说明层：类图描述软件的接口部分，而不是软件的实现部分。
    • 3.实现层：只有在实现层才真正有类的概念，并且揭示软件的实现部分。

8.4.3 包图

• 1.为什么要引入包？
  • 引入包(Package)是为了降低系统的复杂性。
• 2.什么是UML包？
  • 是将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。
  • 是一种分组机制，把各种各样的模型元素通过内在的语义连接为一个整体。
  • 构成包的模型元素称为包的内容，包通常用于对模型的组织管理，因此有时又将包称为子系统（subsystem）。
  • 包与包之间不能共用一个相同的模型元素，包的实例没有任何语义（含义）。仅在模型执行期间包才有意义。
• 包的表示：
  
• 包的内容：可以是类的列表，也可以是另一个包图，还可以是一个类图。
• 包之间的关系：
  • 依赖关系：两个包中的任意两个类存在依赖关系，则包之间存在依赖关系。
  • 泛化关系：使用继承中一般和特殊的概念来说明通用包和专用包之间的关系。
• 和类一样包也有可见性，利用可见性控制外部包对包的内容的存取方式，UML中也定义了可见性：私有(private)，公有(public)，保护(protected) 。缺省值为公有。
• 包也可以有接口，接口与包之间用实线相连，接口通常由包的一个或多个类实现。

8.5 动态建模

• 动态模型主要描述系统的动态行为和控制结构。
  • 动态行为包括系统中对象生存期内可能的状态及事件发生时状态的转移，对象间动态合作关系，对象之间的交互过程以及交互顺序，描述了为满足用例要求所进行的活动及活动间的约束关系。
• 在动态模型中，对象间的交互是通过对象间消息的传递来完成的。
  • 在其生命周期中根据通信的结果不断改变自身的状态。
• 动态模型包括4类图：
  • 状态图：描述某个对象，子系统，系统的生命周期。
  • 活动图：描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。
  • 顺序图：是一种交互图，描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。
  • 合作图：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。
• UML中的消息：
  • 一、简单消息
    
    • 表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。
  • 二、同步消息
    
    • 是一种嵌套的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。
  • 三、异步消息
    
    • 是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。

8.5.1 状态图

• 状态图(State Diagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。
• 状态：所有对象都具有状态，状态是对象执行一系列活动的结果。状态图中定义的状态有：
  • 初态—状态图的起始点，一个状态图只能有一个初态。
  • 终态—是状态图的终点。而终态则可以有多个。
  • 中间状态—包括三个区域：名字域、状态变量与活动域。
    • 状态变量：是状态图所显示的类的属性。
    • 活动：列出了在该状态时要执行的事件和动作。定义为：事件名 (参数表[条件])/动作表达式
      
  • 复合状态—可以进一步细化的状态称作复合状态。
    
• 状态迁移：一个对象的状态的变迁称为状态迁移。通常是由事件触发的，此时应标出触发转移的事件表达式。
• 嵌套状态图：状态图可能有嵌套的子状态图，且子状态图可以是另一个状态图。子状态又可分为两种：“与”子状态和“或”子状态。
• 事件：事件是激发状态迁移的迁移的条件或操作。在UML中，有4类事件：
  • 1.某条件变为真；表示状态迁移的上的警戒条件。
  • 2.收到来自外部对象的信号 (signal) 表示为状态迁移上的事件特征，也称为消息。
  • 3.收到来自外部对象的某个操作中的一个调用，表示为状态迁移上的事件特征，也称为消息。
  • 4.状态迁移上的时间表达式。
• 状态图之间的消息发送：状态图之间可以发送消息，用虚箭头表示。

8.5.2 顺序图

一、概述

• 顺序图是用来描述对象之间动态的交互行为，着重体现对象间消息传递的事件顺序。
• 顺序图构成：
  • 一组对象（对象名和类名）
    对象生命线（时间轴）
    对象被激发
    对象间的通信（消息）

二、消息

• 消息延迟：用倾斜箭头表示
• 消息串：包括消息和控制信号，控制信号位于信号串的前部。
  
• 当收到消息时，接收对象立即开始执行活动，即对象被激活了，通过在对象生命线上显示一个细长矩形框来表示激活。

三、顺序图的形式

• 有两种使用顺序图的方式：一般格式和实例格式。
  • 实例格式详细描述一次可能的交互。没有任何条件和分支或循环，它仅仅显示选定情节（场景）的交互。
  • 而一般格式则描述所有的情节。因此，包括了分支，条件和循环。
• 创建对象与对象的消亡
  • 在顺序图中，还可以描述一个对象通过发送一条消息来创建另一个对象。
  • 当对象消亡(destroying)时，用符号$\times$表示。

8.5.3 活动图

一、概述

• 活动图，它既可用来描述操作(类的方法)的行为，也可以描述用例和对象内部的工作过程，并可用于表示并行过程。
• 活动图是由状态图变化而来的，用于不同的目的。活动图描述了系统中各种活动的执行的顺序。刻化一个方法中所要进行的各项活动的执行流程。
• 活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。

二、活动图的模型元素

• 构成活动图的模型元素有：活动、转移、对象、信号、泳道等。

1.活动

• 构成活动图的核心元素。是具有内部动作的状态，由隐含的事件触发活动的转移。
• 在概念层描述中，活动表示要完成的一些任务；在说明层和实现层中，活动表示类中的方法。
  
• 活动还有其他的图符：初态、终态、判断、同步。
  

2.转移

• 转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动。
• 转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。

3.泳道

• 泳道进一步描述完成活动的对象，并聚合一组活动。泳道也是一种分组机制。
• 泳道可以直接显示动作在哪一个对象中执行，或显示的是一项组织工作的哪部分。

4.对象流

• 活动图中可以出现对象，对象作为活动的输入／输出，用虚箭头表示。

5.控制图符

• 活动图中可发送和接收信号，发送符号对应于与转移联系在一起的发送短句。接收符号也同转移联系在一起。
  

三、活动图举例

• 活动图中只有一个起点一个终点，表示方式和状态图一样，泳道被用来组合活动，通常根据活动的功能来组合。

8.5.4 合作图

• 合作图也称协作图，用于描述相互合作的对象间的交互关系和链接关系。
• 顺序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态链接关系。

一、合作图中的模型元素

1.对象

• 合作图中对象的外观与顺序图中的一样。如果一个对象在消息的交互中被创建，则可在对象名称之后标以{new}。类似地，如果一个对象在交互期间被删除，则可在对象名称之后标以{destroy}。

2.链接

• 链接用于表示对象间的各种关系，包括组成关系的链接(Composition Link)、聚集关系的链接(Aggregation Link)、限定关系的链接(Qualified Link)以及导航链接(Navigation Link)。各种链接关系与类图中的定义相同，在链接的端点位置可以显示对象的角色名和模板信息。
  
• 对于链接还可以加上“角色”与“约束”，在链角色上附加的约束有global(全局)，local(局部)，parameter(参数)，self(自身) 。

3.消息

• 在对象之间的静态链接关系上可标注消息，消息类型有简单消息，同步消息和异步消息三种。用标号表示消息执行的顺序。消息定义的格式如下：
  消息类型　标号 控制信息：返回值：=消息名 参数表
  

8.6 实现模型

• 实现模型描述了系统实现时的一些特性，又称为物理体系结构建模。
• 实现模型包括：
  • 构件图：显示代码本身的逻辑结构，它描述系统中存在的软件构件以及它们之间的依赖关系。
  • 配置图：描述了系统中硬件和软件的物理配置情况和系统体系结构。显示系统运行时刻的结构。

8.6.1 构件图

• 构件又称组件，可以看作逻辑上与包与类对应的物理代码模块，实际上是对应一个文件。
• 一、构件的类型
  • 1.源代码构件(Source Component)；
    源代码文件
    WEB页
    文档
  • 2.二进制构件(Binary Component) ；
  • 3.可执行构件(Executable Component) ;
• 二、构件图的元素
  • 1.构件：常常表示软件模块
  • 2.界面：构件对外提供的可见操作和属性称为构件的界面。
    图符：
    
  • 3.依赖关系：构件之间的依赖关系是指结构之间在编译、连接或执行时的依赖关系。用虚线箭头表示。
    • 组件的依赖关系又分为：开发期的依赖和调用依赖。
      • 开发期的依赖(Development –time Dependency)是指在编译阶段和连接阶段，组件之间的依赖关系。
      • 调用依赖(Call Dependency)是指一个组件调用或使用另外一个组件服务。

8.6.2 配置图

• 配置图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。
• 配置图的元素：
  • 结点：代表某种计算机构件(通常是硬件)，结点还包括在其上运行的软构件(物理代码模块、可执行程序)
  • 连接：结点之间的连接关系及通信类型。连接的连线上要标注通信类型。

8.7 RUP统一过程及其应用

• RUP统一过程具有很好的可操作性和实用性。

8.7.1 UML与RUP统一过程

• 使用UML过程的基本特征是：
  • 1.用例驱动的系统
    • 用例包含了功能描述，将影响后面各阶段及视图。
  • 2.以体系结构为中心
    • 在开发初期就建立基础的体系结构，并不断进行精化，对建立一个易于修改、易理解和允许复用的系统是十分重要的。主要工作是在逻辑上将系统划分为若干个子系统（UML包）。
  • 3.反复
    • UML的建模型过程要经过若干次的反复。
  • 4.渐增式
    • 渐增式开发是在多次反复迭代的过程中，每次增加一些功能（或用例）的开发，每次迭代都包含了分析、设计、实现和测试。
• 能够和UML最佳结合的是RUP，不仅因为该过程的开发者也是UML的创立者，更因为RUP过程能够有效地测度工作进度，控制和改善工作效率。

8.7.2 RUP的特点

• RUP是最佳软件开发经验的总结，具有迭代式增量开发、使用实例驱动、以软件体系结构为核心的三个鲜明特点。这些特点是对UML的发展和无缝集成。
• 具有六大特点：
  • ⑴ 迭代式开发（Develop Iteratively Develop Iteratively）
  • ⑵ 管理需求（Manage Requirements）
  • ⑶ 应用基于组件的体系结构(Use Component Architectures)
  • ⑷ 可视化建模（Use Component Architectures）
  • ⑸ 不断验证软件质量（Continuously Verify Quality）
  • ⑹ 控制软件变更（Manage Change）

8.7.3 RUP的二维开发模型

• RUP中软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。
• 1.横轴是时间维
  • 起始阶段(Inception)：定义最终产品视图、商业模型并确定系统范围。
  • 演化阶段(evaluation)：设计及确定系统的体系结构，制定工作计划及资源要求。
  • 构造阶段(construction)：构造产品并继续演进需求、体系结构、计划直至产品提交。
  • 提交阶段(Transition)：把产品提交给用户使用。
• 2.纵轴表示核心工作流
  • 核心工作流从技术角度描述RUP的静态组成部分。RUP中的9个核心工作流(Core Workflows)
    • ⑴ 商业建模(Business Modeling)
      ⑵ 需求(Requirements)
      ⑶ 分析和设计(Analysis & Design)
      ⑷ 实现(Implementation)
      ⑸ 测试(Test)
      ⑹ 部署(Deployment)
      ⑺ 配置和变更管理(Configuration & Change Management)
      ⑻ 项目管理(Project Management)
      ⑼ 环境(Environment)
    • ⑴到⑹为核心过程工作流(Core Process Workflows)方式
      ⑺到⑼为核心支持工作流(Core Supporting Workflows)
• RUP中的每个阶段都由一个或多个连续的迭代组成。
• 在每个阶段结束前都应有一个里程碑（MileStone）评估该阶段的工作，只有当阶段目标达到时才允许项目进入下一阶段，产生一个阶段里程碑。

第八章完