UML

UML语言纵览

视图

UML中的视图大致分为如下5种：
 1、用例视图。用例视图强调从系统的外部参与者（主要是用户）的角度看到的或需要的系统功能。
 2、逻辑视图。逻辑视图从系统的静态结构和动态行为角度显示如何实现系统的功能。
 3、组件视图。组件视图显示代码组件的组织结构。
 4、并发视图。并发视图显示系统的并发性，解决在并发系统中存在的通信和同步问题。
 5、配置视图。配置视图显示系统的具体部署。部署是指将系统配置到由计算机和设备组成的物理结构上。
 
 上述5种视图分别描述系统的一个方面，5种视图组合成UML完整的模型。下图显示了构成UML完整模型的5种视图间的关系

一、用例视图
    用例视图描述系统应具备的功能，也就是被成为参与者的外部用户所能观察到的功能。用例是系统的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。参与者可以是一个用户或者另外一个系统。客户对系统要求的功能被当作多个用例在用例视图中进行描述，一个用例就是对系统的一个用法的通用描述。用例模型的用途就是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。用例视图是其他视图的核心，它的内容直接驱动其他视图的开发。
二、逻辑视图
    逻辑视图描述用例视图中提出的系统功能的实现。与用例视图相比，逻辑视图主要关注系统内部，它既描述系统的静态结构（类、对象以及他们之间的关系），也描述系统内部的动态协作关系。系统的静态结构在类图和对象图中进行描述，而动态模型则在状态图、时序图、协作图以及活动图中进行描述。逻辑视图的使用者主要是设计人员和开发人员。
三、并发视图
    并发视图主要考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理。除了将系统划分为并发执行的控制以外，并发视图还需要处理线程之间的通信和同步。并发视图的使用者是开发人员和系统集成人员。并发视图由状态图、协作图、以及活动图组成。
四、组件视图
    组件是不同类型的代码模块，它是构造应用的软件单元。组件视图描述系统的实现模块以及它们之间的依赖关系。组件视图中也可以添加组件的其他附加信息，例如资源分配或者其他管理信息。组件视图主要由组件图构成，它的使用者主要是开发人员。
五、配置视图
    配置视图显示系统的物理部署，它描述位于节点上的运行实例的部署情况。配置视图主要由配置图表示，它的使用者是开发人员、系统集成人员和测试人员。配置视图还允许评估分配结果和资源分配。

图

UML的各种图是UML模型的重要组成部分
1、 用例图（Use Case Diagram）
    用例是系统中的一个可以描述参与者与系统直接交互作用的功能单元，用例图的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。
2、 类图（Class Diagram）
    类是对应用领域或应用解决方案中概念的描述。类图以类为中心组织，类图中国的其他元素或属于某个类，或与类相关联。
3、 对象图（Object Diagram）
    对象图是类图的变体，它使用与类图相似的符号描述，不同之处在于对象图显示的是类的多个对象实例而非实际的类。可以说对象图是类图的一个例子，对象图与类图表示的不同之处在于它用带下划线的对象名称类表示对象，显示一个关系中的所有实例。
4、 状态图（State Diagram）
    状态图是对类描述的补充，它用于显示类的对象可能具备的所有状态，以及引起状态改变的事件。实际建模时，并不需要为所有的类都绘制状态图，仅对那些具有多个明确状态并且这些状态会影响和改变其行为的类才有绘制状态图的必要。此外，还可以为系统绘制整体状态图。
5、 时序图（Sequence Diagram）
    时序图显示多个对象间的动作协作，重点是显示对象之间发送的消息的时间顺序。
6、 协作图（Collaboration Diagram）
    协作图对在一次交互中有意义的对象和对象间的链建模。除了显示消息的交互以外，协作图也显示对象以及它们之间的关系。时序图和协作图都可以表示各对象间的交互关系，但它们的侧重点不同。时序图用消息的几何排列关系来表达消息的时间顺序，各角色之间的关系是隐含的。协作图用各个角色排列来表示角色之间的关系，并用消息类说明这些关系。在实际应用中可以根据需要选用这两种图：如果需要重点强调时间或顺序，那么选择时序图；如果需要重点强调上下文，那么选择协作图。
7、 活动图（Activity Diagram）
    活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动。活动状态代表了一个活动，即一个工作流步骤或一个操作的执行。活动图由多个动作状态组成，当一个动作完成后，动作状态将会改变，转换为一个新的状态。
8、 组件图（Component Diagram）
    组件图是用代码组件来显示代码物理结构。一个组件包含它所实现的一个或多个逻辑类的相关信息。通常组件图用于实际的编程工作中。
9、 配置图（Deployment Diagram）
    配置图用于显示系统中的硬件和物理结构。


   

模型元素

UML中的模型元素包括事物和事物之间的联系。事物是UML中重要的组成部分，它代表任何可以定义的东西。事物之间的关系能够把事物联系在一起，组成有意义的结构模型。每一个模型元素都有一个与之相对应的图形元素。
一、 事物
   UML中事物可以分为结构事物、动作事物、分组事物和注释事物。
   1、 结构事物
      结构事物分为：类、接口、协作、用例、活动类、组件和节点
     （1） 类。类是对具有相同属性、方法、关系和语义的对象的抽象，一个类可以实现一 个或多个接口。类用包括类名、属性和方法的矩形表示。

     （2） 接口。接口是为类或组件提供特定服务的一组操作的集合。

     （3） 协作。协作定义了交互操作。一些角色和其他元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。UML中协作用虚线构成的椭圆表示。

     （4） 用例。用例描述系统对一个特定角色执行的一系列动作。在模型中用例通常用来组织动作事物，它是通过协作来实现的。UML中，用例用标注了用例名称的实线椭圆表示。

     （5） 活动类。活动类是类对象有一个或多个进程或线程的类。在UML中活动类的表示法和类相同，只是边框用粗线条。

     （6） 组件。组件是实现了一个接口集合的物理上可替换的系统部分。

     （7） 节点。节点是在运行时存在的一个物理元素，它代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个节点，但也可以从一个节点转到另一个节点。

   2、 动作事物
      动作事物是UML模型中的动态部分，它们是模型的动词，代表时间和空间上的动作。交互和状态机是UML模型中最基本的两个动态事物元素。
     （1） 交互。交互是一组对象在特定上下文中，为达到某种特定的目的而进行的一系列消息交换组成的动作。在交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次数（消息产生的动作）、连接（对象之间的连接）。

     （2） 状态机。状态机由一系列对象的状态组成。

   3、 分组事物
      分组事物是UML模型中组织的部分，分组事物只有一种，称为包。

   4、 注释事物
      注释事物是UML模型的解释部分。

二、 UML中的关系
   1、 关联关系
      关联关系连接元素和链接实例，它用连接两个模型元素的实线表示，在关联的两端可以标注关联双方的角色和多重性标记。

   2、 依赖关系
      依赖关系描述一个元素对另一个元素的依附。依赖关系用源模型指向目标模型的带箭头的虚线表示。

   3、 泛化关系
      泛化关系也称为继承关系，泛化用一条带空心三角箭头的实线表示，从子类指向父类。

   4、 实现关系
      实现关系描述一个元素实现另一个元素。

   5、 聚合关系
      聚合关系描述元素之间部分和整体的关系，即一个表示整体的模型元素可能由几个表示部分的模型元素聚合而成。

通用机制

一、 修饰。
    在使用UML建模时，可以将图形修饰附加到UML图中的模型元素上。比如，当一个元素代表某种类型的时候，它的名称可以用粗体字形类显示；当同一元素表示该类型的实例时，该元素的名称用一条下划线修饰。

二、 注释。
    UML中用一条虚线将注释连接到它为之解释的或细化的元素上。

三、 通用划分。
    UML对其模型元素规定了两种类型的通用划分：型-实例（值）和接口-实现。
    1、型-实例（Type-Instance）：描述一个通用描述符与单个元素项之间的对应关系。实例元素使用与通用描述符相同的表示图形，但是名字的表示与通用描述符不同：实例元素名字带有下划线，而且后面还要加上冒号和通用描述符的名字。

    2、接口-实现：接口声明了一个规定了服务的约定，接口的实现负责执行接口的全部语义定义并实现该项服务。

用例图

一、概念
    用例视图将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称为用例。用例使用系统与一个或多个参与者之间的一系列消息来描述系统中的交互。
用例视图包含6个元素，分别是：参与者（Actor）、用例（Use Case）、关联关系（Association）、包含关系（Include）、扩展关系（Extend）以及泛化关系（Generalization）

二、参与者
    参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互，而参与者的内部实现与用例是不相关的。参与者有三大类：系统用户、与所建造的系统交互的其他系统和一些可以运行的进程。

三、用例
  1、关联关系（Association）：关联关系表示参与者同用例间的通信，使用箭头来表示。
   

  2、包含关系：一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称为包含关系。UML中，包含关系表示为虚线箭头加《include》字样，箭头指向被包含的用例。包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称为客户用例。

  3、扩展关系：一个用例也可以被定义为基础用例的增量扩展，这被称作增量扩展。UML中扩展关系表示为虚线箭头加《extend》字样。箭头指向被扩展的用例（即基础用例）。

  4、泛化关系：一个用例可以被特别列举为一个或多个子用例，这被称作用例泛化。当父用例能够被使用时，任何子用例也可以被使用。UML中泛化关系用一个三角箭头从子用例指向父用例。

类图的概念

一、概述

    类图（Class Diagram）是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。类图是定义其他图的基础，在类图基础上，可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。
    类图包括7个元素：类（Class）、接口（Interface）、协作（collaboration）、依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）以及实现关系（Realization）。

二、类

    类定义了一组有着状态和行为的对象。其中，属性和关联用来描述状态。属性通常用没有身份的数据值表示，如数字和字符串。关联则用有身份的对象之间的关系表示。行为由操作来描述，方法是操作的实现。对象的生命期则由附加给类的状态机来描述。
    1、 名称：类的名称是每个类中所必有的构成元素。
    2、 属性（Attribute）
       （1） 可见性：类中属性的可见性主要包括公有（public）、私有（Private）和受保护（Protected）。在UML中，公有类型的用“+”表达，私有类型用“-”表达，而受保护类型则用“#”表达。UML的类中不存在默认的可见性，如果没有显示任何一种符号，就表示没有定义该属性的可见性。
       （2） 属性名：按照UML的约定，单字属性名小写。如果属性名包含多个单词，这些单词要合并，且除了第一个单词外其余单词的首字母要大写。
       （3） 属性字符串。属性字符串用来指定关于属性的其他信息，例如某个属性应该是永久的。任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则，都可以放在属性字符串里。
       （4） 类属性。属性也可以作为一个类属属性来定义，这就意味着此属性被该类的所有对象共享。在类图中，类属性带有一条下划线。
   3、 操作。类的操作是对类的对象所能做的事务的抽象，相当于一个服务的实现。
   4、 职责：在操作部分下面的区域，可以用来说明类的职责。职责是类或其他元素的契约或义务。类的职责是是自由形式的文本，写一个短语，一个句子等。在UML中，把职责列在类图底部的分隔栏中。
   5、 约束。说明类的职责是消除二义性的一种非形式化的方法，形式化的方法是使用约束。约束指定了该类所要满足的一个或多个规则。在UML中，约束是用一个花括号括起来的自由文本。

三、接口

    接口包含操作但不包含属性，且它没有对外界可见的关联。

四、类之间的关系

    类之间的关系最常见的有四种：依赖关系、泛化关系、管理关系、实现关系。
   1、 依赖关系（Dependency）
      依赖表示两个或多个模型元素之间语义上的关系。它表示了这样一种情形，对于一个元素（提供者）的某些改变可能会影响或提供消息给其他元素（客户），即客户以某种形式依赖于其他类元。根据这个定义，关联、实现和泛化都是依赖关系，但是它们有更特别的语义。在UML中，依赖用一个从客户指向提供者的虚箭头表示，用一个构造型的关键字来区分它的种类。
      UML定义了4种基本依赖类型，分别是使用（Usage）依赖、抽象（Abstraction）依赖、授权（Permission）依赖和绑定（Binding）依赖。

     （1）、使用依赖。使用依赖都是非常直接的，通常表示客户使用提供者提供的服务以实现它的行为。以下列出了5种使用依赖关系.

     （2）、抽象依赖。抽象依赖用来表示客户与提供者之间的关系，依赖于在不同抽象层次上的事物。

     （3）、授权依赖。授权依赖表示一个事物访问另一个事物的能力。提供者通过规定客户的权限，可以控制和限制对其内容访问的方法。

     （4）、绑定依赖。绑定依赖是较高级的依赖类型，用于绑定模板以创建新的模型元素。

   2、泛化关系（Generalization）
      泛化关系是一种存在于一般元素和特殊元素之间的分类关系，它只使用在类型上，而不是实例上。在类中，一般元素被称为超类或父类，而特殊元素被称为子类。在UML中，泛化关系用一条从子类指向父类的空心三角箭头表示

   3、关联关系（Association）
      关联关系是一种结构关系，它指明一个事物的对象与另一个事物的对象之间的联系。也就是说，关联描述了系统中对象或实例之间的离散连接。在UML中，关联关系用一条连接两个类的实线表示

      关联关系有6种对应的修饰，它们分别是：名称、角色、多重性、聚合、组合和导航性。
        （1）、名称（Name）。名称用来描述关联的性质，通常使用一个动词或动词短语来命名关联。名称以前缀或后缀一个指引阅读的方向指示符以消除名称含义上可能存在的歧义，方向指示符用一个实心的三角形箭头表示。
       

        （2）、角色（Role）。角色是关联关系中一个类对另一个类所表现出来的职责。角色名称是名词或名词短语，以解释对象是如何参与关联的。

        （3）、多重性（Multiplicity）。约束是UML三大扩展机制之一，多重性是其中使用最广泛的一种约束。关联的多重性是指有多少对象可以参与该关联，多重性可以用来表达一个取值范围、特定值、无限定的范围或一组离散值。

        （4）、聚合（Aggregation）。聚合关系表示整体和部分关系的关联。聚合关系描述了“has a”的关系。在UML中聚合关系用带空心的实线来表示，其中头部指向整体。

        （5）、组合关系(Composition)。组合关系是聚合关系中的一种特殊情况，是更强形式的聚合，又被称为强聚合。在组合中，成员对象的生命周期取决于聚合的生命周期，聚合不仅控制着成员对象的行为，而且控制着成员对象的创建和析构。在UML中，组合关系用带实心菱头的实线来表示，其中头部指向整体。

        （6）、导航性(Nevigation)。导航性描述的是一个对象通过链（关联的实例）进行导航访问另一个对象，即对一个关联端点设置导航属性意味着本端的对象可以被另一端的对象访问。可以在关联关系上加箭头表示导航方向。只在一个方向上可以导航的关联称为单向关联(Unidirection Association),用一条带箭头的实线来表示。在两个方向上都可以导航的关联称为双向关联(Bidirection Association),用一条没有箭头的实线来表示。另外使用导航性可以降低类之间的耦合度，在也是好的面向对象分析与设计的目标之一。

 

   4、实现关系（Realization）
      实现是规格说明和其实现之间的关系，它将一种模型元素与另一种模型元素连接起来，比如类和接口。
      泛化和实现关系都可以将一般描述与具体描述联系起来。泛化将同一语义层上的元素连接起来，并且通常在同一模型内。实现关系则将不同语义层内的元素连接起来，通常建立在不同的模型内。
      实现关系通常在两种情况下被使用：在接口与实现该接口的类之间；在用例以及实现该用例的协作之间。
      在UML中，实现关系的符号与泛化关系的符号类似，用一条带指向接口的空心三角箭头的虚线表示。下图所示的是实现关系的一个示例，描述的是Keyboard保证自己的部分行为可以实现Typewriter的行为

      实现关系还有一种省略的表示方法，即接口表示为一个小圆圈，并和实现接口的类用一条线段连接，如图

类图建模技术

一、对简单协作建模
    类不是单独存在的，而是要与其他类协同工作。协作是动态交互在静态视图上的映射，协作的静态结构通过类图来描述。
    对协作建模要遵循如下策略
    1、识别要建模的机制。一个机制描述了正在建模的部分系统的一些功能和行为，这些功能和行为是由类、接口和一些其他元素的相互作用产生的。
    2、对每种机制，识别参与协作的类、接口和其他协作，并识别这些事物之间的关系。
    3、用协作的脚本检测事物，通过这种方法可以发现模型中被遗漏的部分和有明显语义错误的部分。
    4、把元素和它们的内容聚合在一起。对于类，首先平衡好职责，随着时间的推移，将它们转换成具有的属性和操作。
二、对逻辑数据库模式建模
    通用的逻辑数据库建模工具是“实体-关系（E-R）”图，传统的E-R图只针对数据，而UML的类图还允许对行为建模。在物理数据库中，类图一般要把逻辑操作转化成触发器或存储过程。
    对模式建模要遵循如下策略：
    1、在模型中识别的类，其状态必须超过其应用系统的生命周期。
    2、创建包含这些类的类图，并把它们标记为永久（persistent）。对于特定的数据库细节，可以定义自己的标记值集合。
    3、展开这些类的结构性细节，即详细描述属性的细节，并注重于关联和构造类的基数。
    4、观察系统中的公共模式（如循环关联、一对一关联和n元关联），它们常常造成物理数据库设计的复杂化。
    5、考虑这些类的行为，扩展对数据库存储和数据完整性来说重要的操作。一般情况下，与对象集的操作相关的业务规则应该被封装在永久类的上一层。
三、正向工程和逆向工程
    1、正向工程（Forward Engineering）
      正向工程是通过实现语言的映射把模型转换为代码的过程。由于UML中描述的模型在语义上比当前的任何面向对象语言要丰富，所以正向工程会导致一定信息的损失，这也是需要模型的原因。
      对类图进行正向工程，要遵循如下的策略 
      (1)、识别映射到所选择的实现语言的规则
      (2)、根据所选择的语言的语义，可能会限定一些对UML特性的使用
      (3)、用标记值详细描述目标语言，若需要精确的控制，该操作可以在单个类的层次上进行，也可以在较高的层次(如协作或包)上进行
      (4)、使用工具对模型进行正向工程
    2、逆向工程（Reverse Engineering）
      逆向工程是通过从特定实现语言的映射，把代码转换为模型的过程。逆向工程会导致大量的冗余信息同时逆向工程又是不完整的。
      对类图进行逆向工程，要遵循如下的策略
      (1)、识别从实现语言或所选的语言进行映射的规则
      (2)、使用工具，指向要进行逆向工程的代码，用工具生成新的模型或修改以前进行正向工程时已有的模型。
      (3)、使用工具，通过查询模型创建类图。

对象图

一、概述
   对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。
    在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例。下图显示了对象图的模型。其中节点可以是对象也可以是类，连线表示对象之间的关系：

二、类图和对象图的区别
 

类图	对象图
类具有3个分栏：名称、属性和操作	对象只有两个分栏：名称和属性
在类的名称分栏中只有类名	对象的名称形式为“对象名：类名”，匿名对象的名称形式为“：类名”
类的属性分栏定义了所有属性的特征	对象则只定义了属性的当前值，以便用于测试用例或例子中
类中列出了操作	对象图中不包括操作，因为对于同属于同一个类的对象而言，其操作是相同的
类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义。类代表的是对对象的分类所以必须说明可以参与关联的对象的数目	对象使用链连接、链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重性。

对象图建模技术

一、对对象结构建模
    对系统的设计视图建模时，可以使用一组类图完整地描述抽象的语义以及它们之间的关系。但是使用对象图不能完整地描述系统的对象结构。对于一个个体类，可能存在多个实例，对于相互之间存在关系的一组类，对象间可有的配置可能是相当多的。所以，在使用对象图时，只能在一定意义上显示感兴趣的具体或原型对象集。这就是对对象结构建模，即一个对象图显示了某一时刻相互联系的一组对象。
    对对象结构建模，要遵循以下策略：
    (1)、识别将要使用的建模机制。该机制描述了一些正在建模的部分系统的功能和行为，它们由类、接口和其他元素的交互而产生。
    (2)、对于各种机制，识别参与协作的类、接口和其他元素，同时也要识别这些事物之间的关系。
    (3)、考虑贯穿这个机制的脚本。冻结某一时刻的脚本，并且汇报每个参与这个机制的对象。
    (4)、按照需要显示出每个对象的状态和属性值，以便理解脚本。
    (5)、显示出对象之间的链，以描述对象之间关联的实例。
二、正向工程和逆向工程
    1、正向工程
      对对象图工程进行正向工程在理论上是可行的，但是在实际上却是受限制的。
    2、逆向工程
      对对象图进行逆向工程是非常困难的。当对系统进行调试时，总要依靠开发人员或工具来进行。

包图

包图(Package Diagram)由包和包之间的关系组成，模型如下：

一、包(Package)
1、名称
   包的名称有两种形式：简单名(simple name)和路径名(path name).其中简单名仅包含一个简单的名称，路径名是以包处于的外围包的名字作为前缀

2、拥有的元素
   包可以拥有其他元素，比如类、接口、组件、节点、协作、用例和图，甚至可以是其他包。
3、可见性
   包的可见性用来控制包外部的元素对包内部元素的访问权限

4、引入与输出
   引入(import)允许一个包中的元素单向访问另一包中的元素。被引入的包中的公共部分称为输出(export).如下图，包Package3输出一个类----C1，而C2是受保护的，所以没有被输出。一个包输出的部分仅对显式地引入这个包的其他包中的元素是可见的。下图中package1显式地引入了pacakge2，而package2显式地引入了package3.因此package3::C1对包package2是可见的，但是由于package3::C2受保护，因此它是不可见的。同样Package::B2对包package1的内容也是不可见的，因为它是私有的。要注意一点：引入和访问依赖是不可传递的。package1引入了package2，package2引入了package3，但这并不意味着package1引入了package3！！！

二、包之间的关系
    在包之间可以有如下两种关系
    1、引入和访问依赖，用于在一个包中引入另一个包输出的元素。
    2、泛化。用于说明包的家族
      包之间的泛化关系和类之间的泛化关系类似，即特殊包可以应用到一般包被使用的地方。就像类一样，包可以替换一般的元素，并可以增加新的元素。

三、包图建模技术
    1、对组成的元素建模
      (1)、浏览特定的体系结构视图中的建模元素，找出在概念和语义上相互接近的元素所定义的组块。
      (2)、把每一个这样的组块放到一个包中。
      (3)、对每一个包找出可以在包外访问的元素，将这些元素标记为公有的，把其他的元素标记为私有或受保护的。如果不确定，就隐藏该元素。
      (4)、确定包与包之间的依赖关系，特别是引入依赖。
      (5)、确定包与包之间的泛化关系，以及包的多重性和重载。
    2、对体系结构视图建模
      (1)、找出问题语境中一组有意义的体系结构视图。通常包括设计视图、进程视图、实现视图、用例视图。
      (2)、找出对于可视化、详述、构造和文档化来说充分必要的元素(和图)，并将他们放入适当的包中。
      (3)、如有必要将这些元素进一步组合到他们自己的包中。
      (4)、不同视图中的元素之间通常存在依赖关系，所以一般要让系统顶层的所有视图对同层的其他视图开放。

状态图

    状态图是系统分析的一种常用工具，它通过建立类对象的生存周期模型来描述对象随时间变化的动态行为。

状态机

    状态机是展示状态与状态转换的图。通常一个状态机依附于一个类，并且描述一个类的实例。状态机包含了一个类的对象在其生命周期间所有状态的序列以及对象对接收到的事件所产生的反应。
    状态机由状态、转换、事件、活动和动作5部分组成。

状态图

    一个状态图表示一个状态机。主要用于表现从一个状态到另一个状态的控制流。
    状态图由表示状态的节点和表示状态之间转换的带箭头的直接组成。若干个状态由一条或多条转换箭头连接，状态的转换由事件触发。模型元素的行为可以由状态图中的一条通路表示，沿着此通路状态机随之执行了一系列动作。一个简单的状态图如下：

    1、状态
      状态由一个带圆角的矩形表示，状态图的图标可以分为3部分：名称、内部转换和嵌套状态。

      (1)、名称。名称表示状态的名字，通常用字符串表示。一个状态的名称在状态图所在的上下文中应该是唯一的
      (2)、内部转换。在内部转换中可以包含进入或者走出此状态应该执行的活动或动作，它们将响应对象所接收到的事件，但是不改变对象的状态。
      (3)、嵌套状态图。状态图中的状态有两种：简单状态和组合状态。简单状态不包含其他状态，组合状态是包含子状态的状态。在组合状态的嵌套状态图部分包含的就是此状态的子状态。

    2、转换
      转换用带箭头的直线表示，分别连接源状态和目标状态。当源状态接收到一个事件，并且监护条件得到满足，则执行相应的动作，同时从源状态转换到目标状态。如果转换上没有标注触发转换的事件，则表示此转换为自动进行。

    3、初始状态
      初始状态代表状态图的起始位置，起始状态在一个状态图中只允许有一个，用一个实心圆表示。

    4、终止状态
      终止状态是一个状态图的终止点。它用一个含有实心圆的空心圆表示。

    5、判定
      判定用空心小菱形表示。工作流在此处按监护条件的取值而发生分支。

状态

    状态包括状态名、内部转换、入口动作和出口动作、简单状态、组成状态（顺序子状态、并发子状态）、历史状态。

事件

    事件表示在某一特定的时间或空间出现的能够引发状态改变的运动变化。事件分为入口事件、出口事件、动作事件、信号事件、调用事件、修改事件、时间事件、延迟事件。

转换

    转换表示当一个特定事件发生或某些条件得到满足时，一个源状态下的对象在完成一定的动作后将发生状态转变，转向另一个称之为目标状态的状态。
    转换通常分为外部转换、内部转换、完成转换和复合转换4种。一个转换一般包括5部分的信息：源状态、目标状态、触发事件、监护条件和动作。
    1、外部转换
      外部转换是一种改变对象状态的转换，它是最常见的一种转换。外部转换用从源状态到目标状态的箭头表示。下图表示了一个火车上的卫生间的简单状态转换。图中箭头上标注的都是引发状态转换的外部事件。

    2、内部转换
      内部转换有一个源状态但没有目标状态，它转换后的状态仍是它本身。内部转换用于对不改变状态的插入动作建立模型，例如建立帮助信息。
      内部转换和自转换（即后面提到的完成转换）不同：自转换是离开本状态后重新进入该状态，它会激发状态的入口动作和出口动作的执行；而内部转换自始至终都不离开本状态，所以没有出口或入口事件。

    3、完成转换
      完成转换又成自转换，之所以称为完成转换是因为没有标明触发器事件的转换是由状态中活动的完成引起的，是自然而然的完成的转换。
    4、复合转换
      复合转换由简单转换组成，这些简单转换通过分支判定、分叉或接合组合在一起。多条件的分支判定又分为链式和非链式的分支，两种分支分别如下图所示：

    5、触发事件
      触发事件就是能引起状态转换的事件。触发事件可以是信号、调用和时间段等。

    6、监护条件
      监护条件是触发转换必须满足的条件，它是一个布尔表达式。当事件被触发时，监护条件被赋值。如果布尔表达式为真，那么转换被触发；否则不会引起转换。监护条件只能在触发事件发生时被赋值一次。从一个状态引出的多个转换可以有同样的触发器事件，但是每个转换必须具有不同的监护条件。
    7、动作
      动作是一组可执行语句或计算处理过程。动作可以包括发送消息给另一个对象、操作调用、设置返回值、创建和销毁对象等。动作是原子的，不可中断的。
      整个系统可以在同一时间执行多个动作。动作在它的控制线程中是原子性的，一旦开始执行就必须执行到底并且不能与同时处于活动状态的动作发生交互作用。

活动图

    活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。

概述

    虽然活动图与状态图都是状态机的表现形式，但是两者还是有本质区别：活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程；而状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与。
    1、活动图的图形表示
      在UML中，活动图表示成圆角矩形。

 

    2、活动图与流程图的区别
      (1)、流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系。而活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。
      (2)、活动图能够表示并发活动的情形，而流程图不行。
      (3)、活动图是面向对象的，而流程图是面向过程的。

活动图的组成元素

    UML的活动图中包含的图形元素有动作状态、活动状态、动作流、分支与合并、分叉与汇合、泳道和对象流等。
    1、动作状态
      动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。动作状态有如下特点：
      (1)、动作状态是原子的，它是构造活动图的最小单位。

      (2)、动作状态是不可中断的。
      (3)、动作状态是瞬时的行为。
      (4)、动作状态可以有入转换，入转换既可以是动作流，也可以是对象流。动作状态至少有一条出转换，这条转换以内部的完成为起点，与外部事件无关。
      (5)、动作状态与状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。
      (6)、在一张活动图中，动作状态允许多处出现。
    UML中动作状态用平滑的圆角矩形表示。

    2、活动状态
      活动状态用于表达状态机中的非原子的运行，其特点如下：
      (1)、活动状态可以分解成其他子活动或者动作状态。
      (2)、活动状态的内部活动可以用另一个活动图来表示。
      (3)、和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。
      (4)、动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。
    UML中活动状态和动作状态的图标相同，但是活动状态可以在图标中给出入口动作和出口动作等信息。

    3、动作流
      与状态图不同，活动图的转换一般都不需要特定事件的触发。与状态图的转换相同，活动图的转换也用带箭头的直线表示，箭头的方向指向转入的方向。
    4、分支与合并
      UML中分支与合并用空心的小菱形表示。

    4、分叉与汇合
      对象在运行时可能会存在两个或多个并发运行的控制流，为了对并发的控制流建模，UML中引入了分叉与汇合的概念。分叉用于将动作流分为两个或多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。

    5、泳道
      泳道将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织，即对象。在活动图中，泳道区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。在包含泳道的活动图中，每个活动只能明确地属于一个泳道。
      泳道是用垂直实线绘出，垂直线分隔的区域就是泳道。在泳道的上方可以给出泳道的名字或对象的名字，该对象负责泳道内的全部活动。泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。

    6、对象流
      对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。用活动图描述某个对象时，可以把涉及到的对象放置在活动图中并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用方法就构成了对象流。
      对象流中的对象有以下特点：
      (1)、一个对象可以由多个动作操作。
      (2)、一个动作输出的对象可以作为另一个动作输入的对象。
      (3)、在活动图中，同一个对象可以多次出现，它的每一次出现表面该对象正处于对象生存期的不同时间点。
      对象流用带有箭头的虚线表示。如果箭头是从动作状态出发指向对象，则表示动作对对象施加了一定的影响。施加的影响包括创建、修改和撤销等。如果箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。
      状态图中的对象用矩形表示，矩形内是该对象的名称，名称下的方括号表明对象此时的状态。

活动的分解

    一个活动可以分为若干个动作或子活动，这些动作和子活动本身又可以组成一个活动图。不含内嵌活动或动作的活动称之为简单活动，嵌套了若干活动或动作的活动称为组合活动。组合活动有自己的名字和相应的子活动图。

时序图

概述

    时序图(Sequence Diagram)描述了对象之间传送消息的时间顺序，它用来表示用例中的行为顺序。
    时序图包含4个元素，分别是对象(Objce)、生命线(Lifeline)、消息(Message)和激活(Activation)。
    UML中时序图表示为二维图。其中纵轴是时间轴，时间沿竖线向下延伸。横轴代表了在协作中各个独立的对象。当对象存在时，生命线用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。消息从一个对象的生命线到另一个对象生命线的箭头表示。

时序图的组成

    1、对象   
      时序图中的对象符号和对象图中对象所用的符号一样，都是使用矩形将对象名称包含起来，并且对象名称下有下划线。将对象置于时序图的顶部意味着在交互开始的时候对象就已经存在，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。

    2、生命线    
      生命线表示时序图中的对象在一段时间内的存在。是一条垂直的虚线。

    3、消息    
      消息定义的是对象之间某种形式的通信，它是对象之间的单路通信。消息可以用于在对象之间传递参数，消息可以是信号，也可以是调用。
      UML中常见的消息符号如下：

      消息箭头所指的一方是接收方。

    4、激活    
      时序图可以描述对象的激活(Activation)和去激活(Deactivation)状态。激活表示对象被占用以完成某个任务，去激活指的是对象处于空闲状态，在等待消息。UML中激活状态表示为矩形。

对象的创建和撤销

    对象可以在交互开始前就存在，或者在交互的过程中被创建。下图表示了创建对象的两种方法：

    如果要撤销一个对象，只要在其生命线终止点放置一个"X"符号即可，该点通常是对删除或取消消息的回应。

组件图

概述

    组件图(Component Diagram)描述了软件的各种组件和它们之间的依赖关系。组件图中通常包含3种元素：组件(Component)、接口(Interface)和依赖(Dependency)。每个组件实现一些接口，并使用另一些接口。

组件

    组件是定义了良好接口的物理实现单元，是系统中可替换的物理部件。一般情况下，组件表示将类、接口等逻辑元素打包而形成的物理模块。一个组件包含它所实现的一个或多个逻辑类的相关信息，创建了一个从逻辑视图到组件视图的映射。
    在UML中，组件用一个左侧带有两个突出小矩形的矩形来表示，如下图：

    1、名称
      组件的名称是一个字符串，位于组件图的内部。组件的名称有两种：简单名和路径名。通常，UML图中的组件只显示其名称，但是也可以用标记值或表示组件细节的附加栏加以修饰。

    2、组件的种类
      有3种类型的组件：配置组件(Deployment Component)、工作产品组件(Work product component)和执行组件(Execution Component)
      (1)、配置组件是运行系统需要配置的组件，是形成可执行文件的基础。操作系统、Java虚拟机和数据库管理系统都属于配置组件。
      (2)、工作产品组件包括模型、源代码和用于创建配置组件的数据文件，它们是配置组件的来源。工作产品组件包括UML图、Java类和JAR文件、动态链接库(dll)和数据库表等。
      (3)、执行组件是在运行时创建的组件，是最终可运行的系统产生的允许结果。EJB、Servlets、HTML和XML文档、COM+和.Net组件以及CORBA组件都是执行组件的例子。

    3、Rose中不同类型组件的图标表示
      (1)、组件
          Rose中的组件即一般意义上的组件。也可以用构造型来指定组件类型(如ActiveX、Applet、Application、DLL和Executable等)。如图所示

      (2)、子程序规范
          子程序规范(Subprogram Specification)通常是一组子程序集合名，子程序中不包括类定义。下图给出了两种表示子程序规范的图标：

      (3)、子程序体
          下图给出了两种表示子程序体的图标：
 

      (4)、主程序
          主程序是包含程序根的文件。

      (5)、包规范
          包是类的实现方法。包规范(Package Specification)是类的头文件，包含类中函数的原型信息。在C++中，包规范就是.h文件。

      (6)、包体
          包体(Package Body)包含类操作代码。在C++中，包体就是.cpp文件。

      (7)、任务规范
          任务表示具有独立控制线程的包。可执行文件通常表示为扩展名为.exe的任务规范。

      (8)、任务体
          下图是两种表示任务体的图标。

      (9)、数据库
          数据库可能含有一个或几个结构。

      (10)、虚包
          下图是两种表示虚包的图标。

      (11)、虚子程序
          下图是两种表示虚子程序的图标。

接口

    接口和组件之间的关系分为两种：实现关系(Realization)和依赖关系(Dependency)。接口和组件之间用实线连接表示实现关系，用虚线连接表示依赖关系。

    组件的接口分为两种：导入接口和导出接口。其中导入接口供访问操作的组件使用，导出接口由提供操作的组件提供。上图中，接口对于组件Component是导出接口，对于组件Component2来说是导入接口。

依赖关系

    组件图用依赖关系表示各组件之间存在的关系类型。组件图中的依赖关系是由客户指向提供者的虚线箭头。客户组件依赖于提供者组件，提供者组件只在开发时存在，运行时则不存在。

协作图

概述

    协作图(Collaboration Diagram)描述了和对象结构相关的信息。协作图的一个用途是表示类操作的实现。协作图可以说明类操作中用到的参数、局部变量以及操作中的永久链。
    协作图包含三个元素：对象(Object)、链(Link)和消息(Message)。下图是协作示例图。

对象、链和消息

    1、对象
      协作图中的对象和时序图中一样，是用矩形表示。

    2、链
      链是一条连接两个类角色的实线。下面是几种常见的链符号：

    为了说明一个对象如何与另一个对象连接，可以在链的末路上附上一个路径构造型。例如构造型<<local>>，表示指定对象对发送方而言是局部的。

    3、消息
      消息中的顺序是根据消息前的数字来区别，同时，消息还可以通过点表示法代表控制的嵌套关系，也就是说在消息1中，消息1.1是嵌套在消息1中的第一个消息。嵌套可以具有任意深度。

时序图与协作图的比较

    1、相同点
      (1)、规定责任。
      (2)、支持消息。
      (3)、衡量工具。两种图还是衡量耦合性的工具
    2、不同点
      (1)、协作图的重点是将对象的交互映射到它们之间的链上，但是时序图却不把链表示出来。
      (2)、时序图可以描述对象的创建和撤销的情况，而在协作图中，对象要么存在要么不存在。

配置图

概述

    配置图(Deployment Diagram)描述了运行软件的系统中硬件和软件的物理结构。配置图中通常包含两种元素：节点(Node)和关联关系(Association)

    配置图中每个配置必须存在于某些节点上。配置图也可以包含包或子系统。

节点

    节点是在运行时代表计算机资源的物理元素。在UML中，节点用一个立方体来表示。节点在很多方面与配置相同，二者都有名称和关系，都可以有实例，都可以被嵌套，都可以参与交互。但是节点与配置之间也存在着差别：配置是参与系统执行的事物，而节点是执行配置的事物。配置表示逻辑元素的物理包装，而节点表示配置的物理配置。
    1、名称
      节点名称有两种：简单名和路径名。路径名是在简单名的前面加上节点所在包的名称。节点也可以用标记值或表示节点细节的附加栏加以修饰：

    2、节点的种类
      节点可以分为两种：处理器(Processor)和设备(Device)
      (1)、处理器
          处理器是能够执行软件、具有计算能力的节点、服务器、工作站和其他具有处理能力的机器。
      (2)、设备
          设备是没有技术能力的节点，通常都是通过其接口为外部提供某种服务。比如哑终端、打印机、扫描仪等。
      下图表示了UML中的处理器和设备

    3、节点中的配置
      当配置驻留在某个节点时，可以将它建模在图上该节点的内部。为显示配置之间的逻辑通信，需要添加一条表示依赖关系的虚线箭头。下图显示了提供查询数据库功能的服务器。

    同样也可以在节点和配置之间添加一条表示依赖关系的虚线箭头并使用构造型来表示。

关联关系

    配置用关联关系(Association)表示各节点之间通信路径。关联关系一般不使用名称，而是使用构造型，如<<Ethenet>>、<<parallel>>、<<TCP>>等。下图显示的是PC机的配置图。

UML与统一开发过程     Rational Unified Process(RUP，统一开发过程)是一套面向对象的软件工程过程。RUP是一套软件工程方法的框架，软件开发者可以根据自身的实际情况以及项目规模对RUP进行裁剪和修改，以制定合乎需要的软件工程过程。 软件开发过程     当前使用比较广泛的软件过程主要包括以下几种:     1、Rational United Process(RUP)     2、Open Process     3、Object-Oriented Software Process(OOSP)     4、Extreme Programming(XP)     5、Catalysis     6、Dynamic System Development Method(DSDM) RUP简介     1、传统的软件开发模型       (1)、瀑布模型(Waterfall Model)           瀑布模型将软件生存周期划分为6个阶段，是一种线性模型。各个阶段活动为：需求分析、设计、实现、测试、运行和维护。每个开发阶段具有以下特征：将上一阶段的结果作为本阶段工作的输入；对上述输入实施本阶段的活动；给出本阶段的工作成果作为输出传入下一阶段；对本阶段进行工作评审，若本阶段工作得到确认，则继续下阶段工作，否则返回前一阶段。瀑布模型的缺点是缺乏灵活性。                (2)、螺旋模型           螺旋模型使用原型作为降低风险的机制，重要的是，它使开发者在产品演化的任意阶段均可使用原型方法。它保持了传统生命周期模型中系统的、阶段的方法，但将其并入了迭代框架，更加真实地反映了现实世界。螺旋模型要求在项目的所有阶段直接考虑技术风险。螺旋模型体现了RUP中的迭代思想，即一步一步接近目标系统，每完成一圈，得到一个更接近目标的原型，同时开发的风险也随之降低。           一个螺旋的周期一般包括4个阶段：确定目标，选择方案，选定完成目标的策略；风险分析；启动开发阶段；评审前一阶段的工作，计划下一阶段工作。    RUP的二维开发模型     传统的瀑布开发模型是一个一维的模型，开发过程被划分为多个连续的阶段。在一段时间内，只能做某一个阶段的工作。而在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间：横轴表示项目的时间维，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Period)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织，为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如下图：     1、RUP的核心工作流       RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflow)和3个核心支持工作流(Core Supporting Workflow)。这些工作流在整个生命周期中一次又一次被访问，在每一次迭代中以不同的重点和强度重复。如下图：       (1)、商业建模(Business Modeling)            该工作流的主要目的是对系统的商业环境和范围进行建模，确保所有参与人员对开发系统有共同的认识。       (2)、需求分析(Requirements)            定义系统功能及用户界面，明确可以需要的系统的功能。该工作流的主要结果是软件需求说明书(SRS)。       (3)、分析与设计(Analysis and Design)            把需求分析的结果转化为实现规格。分析设计工作流的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的包(Package)和子系统(SubSystem)，而描述则体现了类的对象如何协同工作实现用例的功能。       (4)、实现(Implementation)            定义代码的组织结构、实现代码、单元测试、系统集成。实现工作流的目的包括以层次化的子系统形式定义代码的组织结构，以组件的形式(源文件、二进制文件、可执行文件)实现类和对象。将开发出的组件作为单元进行测试，以及集成由单个开发者所开发的组件，使其成为可执行的系统。       (5)、测试(Test)            验证各子系统的交互和集成。测试分别从可靠性、功能性和系统性能来进行。       (6)、部署(Deployment)            部署工作流的目的是成功的生成版本并将软件分发给最终用户。       (7)、配置和变更管理(Configuration and Change Management)            该工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录       (8)、项目管理(Project Management)            为计划、执行和监控软件开发项目提供可行性的指导。       (9)、环境(Environment)            为组织提供过程管理和工具的支持。                2、RUP的4个阶段       通过使用RUP，软件产品的生命周期被分成单独的开发周期。这些周期再被细分为多个阶段。RUP包括以下几个阶段：初始阶段、细化阶段、构造阶段、交付阶段       每个阶段都由一个或多个连续的迭代组成。每个迭代都是一个完整的开发过程，每个阶段结束于一个主要的里程碑，每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足，如果评估结果令人满意的话，可以允许项目进入下一个阶段。       (1)、初始阶段            在这个阶段，需要建立商业案例，必须建立基本的用例模型、项目计划、初始风险评估和项目描述。该阶段的焦点是需求和分析工作流。              (2)、细化阶段            这个阶段的目标是分析问题领域，编制项目计划；细化风险评估；定义质量属性；捕获大部分的系统功能需求用例。为了达到该目的，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板、准备工具。            细化阶段结束是第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。该里程碑为系统的结构建立了管理基准，并使项目小组能够在构建阶段进行衡量。该阶段有以下标准：            a、标明用例模型中的用户和参与者，建立用例的描述文档。用例模型需完成80%            b、创建软件系统开发过程中的软件结构的描述文档。            c、创建可执行的系统原型            d、细化商业案例和风险列表            e、创建整个项目的开发计划          该阶段的焦点是需求、分析和设计工作流。       (3)、构造阶段            构造阶段的主要目标是完成所有的需求、分析和设计。在构造阶段，所有剩余的构件和应用程序功能被并发并集成为产品，所有的功能被详细测试。构造阶段主要目标包括以下几点：            a、优化资源，避免不必要的报废和返工。            b、尽快达到质量要求。            c、快速完成有用的版本，如Alpha版、Beta版和其他测试发布版。            d、完成所有功能的分析、开发和测试。            e、迭代式、递增地开发随时可以发布的产品，也就是要继续描述剩余的用例和其他需求、充实设计、完成实施并测试软件。            f、确定准备好软件系统的外部环境。            构造阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。该里程碑决定了产品是否可以在测试环境中进行部署。此刻要确定软件、环境、用户是否可以开始系统地运作。       (4)、交付阶段            交付阶段的重点是确保软件对最终用户是可用的。在交付阶段的终点是第4个里程碑：产品发布(Product Release)里程碑。此时要确定目标是否实现，是否应该开始另一个开发周期。 RUP的迭代开发模型     RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它是增量式的发展，从一个迭代过程到另一个迭代过程到成为最终的系统。 RUP的核心工作流     下面将从制品、工作人员、工作流3个方面，针对几个关键流程中所应用到的UML过程进行说明。     1、需求捕获工作流       需求的焦点主要在初始阶段和细化阶段，在细化阶段后期，需求捕获的工作量大幅下降：       (1)、制品            需求捕获工作流中，主要的UML制品包括用例模型、参与者、用例、架构描述、术语表和用户界面原型。            a、用例模型(Use Case Model)主要包括系统参与者、用例以及它们之间的关系。用例模型可以帮助开发人员和客户在需求方面达到共识。            b、参与者(Actor)作为相关工作单元部分直接与系统进行交互，它们可以是人类用户或其他系统。            c、用例(Use Case)定义了系统所提供的功能和行为单元。可以认为，参与者使用系统的每一种方式都可以表示为一个用例。在UML术语中，一个用例往往可以认为是一个类元，也就是说，它具有操作和属性，因此用例可以由顺序图和协作图来详细描述。            d、架构描述。架构描述了关键性功能的用例，它包括用例模型的构架视图。            e、术语表(Glossary)提供了主要业务术语和定义字典。            f、用户界面原型可以在需求捕获期间由用户理解和确定参与者和系统之间的交互。       (2)、工作人员            需求捕获阶段的工作人员有系统分析人员、用例描述人员、用户界面设计人员和构架设计师。            a、系统分析人员(System Analyst)在需求捕获阶段确定参与者和用例，并确保用例模型是完整的和一致的，主要负责用例模型、参与者和术语表3个制品，但他不对每个单独的用例负责。            b、用例描述人员(Use Case Specifier)对一个或多个用例进行详细描述。            c、用户界面设计人员(Use Interface Designer)负责对用户界面进行可视化定型。            d、构架设计师(Architect)也参与需求工作流，这有助于他描述用例模型的架构视图。       (3)、工作流            需求捕获阶段的工作流主要有5个活动：确定参与者和用例、区分用例的优先级、详细描述一个用例、构造用户界面原型以及构造用例模型。            a、确定参与者和用例。从环境中界定系统，概述哪些参与者将与系统进行交互，以及他们将从系统中得到哪些功能(用例)            b、区分用例的优先级。为了决定用例的开发阶段            c、详细描述一个用例。            d、构造用户界面原型。            e、构造用例模型。     2、分析工作流       分析的主要工作开始于初始阶段的结尾，和需求一样是细化阶段的主要焦点。       (1)、制品            在分析工作流期间，主要的UML制品包括分析模型、分析类、用例实现、分析包和构架描述。            a、分析模型由代表该模型顶层包的分析系统来表示。            b、分析类代表问题域中的简单抽象，它映射到现实世界业务的概念。            c、用例实现由一组类所组成，这些类实现了用例中所说明的行为。            d、分析包。提供了一种对模型中的制品进行组织的方法。            e、构架模型。构架描述了对构架重要的制品。       (2)、工作人员            在分析工作流期间，参与的工作人员有构架设计师、用例工程师、构件工程师。       (3)、工作流            分析工作流主要包括4个活动：构架分析、分析用例、分析类、分析包。     3、设计工作流       设计工作流主要位于细化阶段的最后部分和构造阶段的开始部分。和需求一样是细化阶段的主要焦点。       (1)、制品            在设计工作流期间，主要的UML制品包括设计模型、设计类、用例实现、设计子系统、接口、构架描述、实施模型。       (2)、工作人员            在设计工作流期间，参与的工作人员有构架设计师、用例工程师、构件工程师。       (3)、工作流            分析工作流主要包括4个活动：构架分析、设计一个用例、设计一个类和设计子系统。     4、实现工作流       实现工作流是把设计模型转换成可执行代码的过程。       (1)、制品            在实现工作流期间，主要有6种制品：实现模型、构件、实现子系统、接口、构架描述、集成构造计划。       (2)、工作人员            在设计工作流期间，参与的工作人员有构架设计师、构件工程师、系统集成人员。       (3)、工作流            分析工作流主要包括5个活动：构架实现、系统集成、实现一个子系统、实现一个类和执行单元测试。     5、测试工作流       测试工作流贯穿于软件开发的整个过程。       (1)、制品            在测试工作流期间，主要有7种制品：测试模型、测试用例、测试规程、测试构件、测试计划、缺陷和评估测试。       (2)、工作人员            在测试工作流期间，参与的工作人员有测试设计人员、构件工程师、集成测试人员、系统测试人员。       (3)、工作流            测试工作流主要包括6个活动：制定测试计划、设计测试、实现测试、执行集成测试、执行系统测试和评估测试。