UML用户指南第二版-读书笔记-第2章-UML介绍

UML概述

• UML是一种绘制软件蓝图的标准语言。可以用UML对软件密集型系统的制品进行可视化，规格化，构建和文档化。

• UML仅仅只是一种语言，是软件开发方法的一部分

• UML是独立于过程的，但是最好把它用于以用例为驱动，以体系结构为中心，迭代和增量的过程

• UML可以告诉你如何创建模型，但是它没有说明应该在什么时候创建什么样的模型，因为这是软件开发过程的工作。

• 一个定义明确的过程将指导你决定生产什么制品，由什么样的活动和人员来创建与管理这些制品，怎样利用这些制品从整体上去度量和控制项目

UML的概念模型

UML语言有3个要素，UML的基本构造块(词汇)，支配这些构造块如何放在一起的规则(语法)，运用于整个UML的公共机制。

UML的构造块(building blocks)

UML的词汇表包含下面3种构造块：

1. 事物(things)

2. 关系(relationships)

3. 图(diagrams)

事物是对模型中重要元素的抽象，关系把事物连接在一起，图聚集了相关的事物

UML事物

在UML中有4种事物：

1. 结构事物(structural things)

2. 行为事物(behavioral things)

3. 分组事物(grouping things)

4. 注释事物(annotational things)

结构事物

结构事物是UML模型中的名词，通常是模型中的静态部分，表示概念元素或者物理元素。结构事物总称为类目(classifier)。

1. 类(class)
   类是对一组具有相同属性，相同操作，相同关系，相同语义的对象的描述。类实现一个或者多个接口。

   

2. 接口(interface)
   接口是一组操作的集合，每个操作描述了类或者组件的一个服务。

   

3. 协作(collaboration)
   协作定义了一个交互，由角色和其他元素构成一个群体，他们之间通过相互合作提供了一些协作行为，这些协作行为大于所有元素各自行为的总和。协作具有结构性和行为性两个维度。一个给定的类或者对象可以参与几个协作。这些协作描述了组成系统的模式(patterns)的实现。

   

4. 用例(use case)
   用例是一组动作(action)序列的描述，系统执行这些动作将产生对特定参与者有价值而且可观察的结果。用例用于构建UML模型中的结构事物。用例是通过协作实现的。

   

5. 主动类(active class)
   主动类是这样的类，其对象拥有一个或多个进程或线程，因此它能够启动控制活动。主动类的对象所表示的元素与其他元素的行为是并发的，除了这一点之外，它和类是一样的。

   

6. 组件(component)
   组件是系统设计的模块化部件，将实现隐藏在一组外部接口之后。在一个系统中，共享相同接口的组件可以相互替换，只要保证系统的逻辑行为相同即可。

   

7. 制品(artifact)
   制品是系统中物理的而且可替换的部件，包含物理信息（”bits”）。在一个系统中，会遇到不同类型的部署制品，如源代码文件，可执行程序，脚本文件。制品通常代表对源码信息或运行时信息的物理打包。

   

8. 结点(node)
   结点是运行时存在的物理元素，它表示一个计算机资源，通常有内存和处理器。一组组件可以驻留在一个结点内，也可以从一个结点迁移到另一个结点。

   

   这些元素：类，接口，协作，用例，主动类，组件，制品，结点，是UML模型中可以包含的基本结构事物。它们也有变体，如参与者，信号，实用程序（一种类），进程/线程(两种主动类)，应用程序，文档，文件，库，页，表(一种制品)等。

行为事物

行为事物是UML模型中动态的部分，它们是模型中的动词，代表了跨越时间和空间的行为。共有3类主要的行为事物。

1. 交互(interaction)
   交互是这样一种行为，它由特定语境中共同完成一定任务的一组对象或角色之间交互的信息组成。一个对象群体的行为或者单个操作的行为可以用一个交互来描述。交互涉及一些其他的元素，包括消息(message)，动作(action)，连接件(connector,对象间的连接)。

2. 状态机(state machine)
   状态机是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列以及对这些事件的响应。单个类或一组类之间协作的行为可以用一个状态机来描述。状态机涉及到一些其他的元素，包括状态(states)，转移(transitions,从一个状态转移到另一个状态)，事件(events，触发转移的事件)，活动(activities，对转移的响应)。

   

3. 活动(activities)
   活动是这样一种行为，它描述了计算过程执行的步骤序列。交互关注的是相互作用的对象集合，状态机关注的是一定时间内一个对象的生命周期，活动关注的是步骤之间的流而不关心哪个对象执行哪个步骤。活动的一个步骤就是一个动作。

   

分组事物

分组是UML模型的组织部分。主要的分组事物是包。包(package)是用于对设计本身进行组织的通用机制。结构事物，行为事物，甚至其他的分组事物都可以放进包内。包是用来组织UML模型的基本分组事物，它也有变体，如框架，模型，子系统(一种包)等。

注释事物

注释事物是UML模型的解释部分，用来描述，说明和标注模型的任何元素。有一种主要的注释事物是注解(note)。注解是依附于一个元素或者一组元素之上对其进行约束或者注释的简单符号。通常可以用注解中所含的约束或者解释来修饰图，当然最好是把注释表示成形式化或非形式化的文本。这种元素也有变体，如需求(从模型的外部来描述一些想得到的行为)。

UML中的关系

在UML中有4种关系：

1. 依赖(dependency)
   依赖是两个模型元素间的语义关系，其中一个元素(独立元素)发生变化会影响到另一个元素(依赖元素)的语义。

   

2. 关联(association)
   关联是类之间的结构关系，它描述了链(links)的集合，链是对象之间的连接。聚合(aggregation)是一种特殊类型的关联，它描述了整体和部分间的结构关系。

   

3. 泛化(generalization)
   泛化是一种特殊/一般关系，其中特殊元素(子元素)基于一般元素(父元素)而建立。子元素共享了父元素的结构和行为。这种关系在一些面向对象语言中也叫做继承。

   

4. 实现(realization)
   实现是类目之间的语义关系，其中一个类目指定了一个合约，由另一个类目保证执行这个合约。你会在两种地方会遇到实现关系：一种是在接口和实现接口的类和组件之间；另一种是在用例和实现用例的协作之间。

除了这4中基本的关系事物外，它们也有变体，如精化(refinement)，跟踪(trace)，包含(include)和扩展(extend)。

UML中的图

图(diagram)是一组元素的图形表示。UML包括13种图：

1. 类图(class diagram)
   类图展现了一组类，接口，协作和它们之间的关系。类图给出的是系统的静态设计视图。包含主动类的类图给出系统的静态进程视图。组件图是类图的变体。

2. 对象图(object diagram)
   对象图展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。对象图给出的是系统的静态设计视图或静态进程视图。

3. 组件图(component diagram)
   组件图展现了一个封装的类和它的接口，端口以及由内嵌的组件和连接件构成的内部结构。组件图给出的是系统的静态设计实现视图。

4. 组合结构图(composite structure diagram)
   组合结构图和组件图的差别非常小，区别是组合结构图适用于任何类。

5. 用例图(use case diagram)
   用例图展现了一组用例，参与者及它们之间的关系。用例图给出了系统的静态用例视图。

6. 顺序图(sequence diagram)

7. 通信图(communication diagram)
   顺序图和通信图都是交互图。交互图(interaction diagram)展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。通信图也是一种交互图，它强调收发消息的对象或角色的结构组织。顺序同和通信图都表达了类似的基本概念，但是两种图强调了概念的不同视图，顺序图强调次序，通信图强调消息流中的数据结构。定时图强调的是消息交互时的实际时间。

8. 状态图(state diagram)
   状态图显示一个由状态，转移，事件，活动组成的状态机。状态图给出的是一个对象的动态视图。状态图在对接口，类，协作的行为进行建模时特别重要，它强调的是对象基于事件顺序的行为，这对于建模响应式系统特别有用。

9. 活动图(activity diagram)
   活动图将函数的结构展示为一步步的控制流和数据流。活动图给出的是系统的动态视图。活动图在建模系统功能的时候特别重要，它强调的是对象间的控制流。交互概览图(interaction overview diagram)是活动图和顺序图的混合物。

10. 部署图(deployment diagram)
    部署图显示的是运行时结点以及运行在这些结点上的组件的配置信息。它给出的是系统体系结构的静态部署图。典型的，一个结点上包含一个或多个制品。

11. 制品图(artifact diagram)
    制品图显示的是计算机上一个系统的物理组成，制品包括文件，数据库等。制品常与部署图一起使用。UML把制品图当作部署图的一个变体。

12. 包图(package diagram)
    包图展现了由模型本身分解而成的组织单元以及它们的依赖关系。

13. 定时图(timing diagram)
    定时图是一种交互图，它展现的是消息跨越不同对象或角色的实际时间，而不仅仅关心消息的相对顺序。

为了方便后续查阅，画了一个图。

UML的通用机制

UML有贯穿整个语言的4个通用机制并保证一致的应用，这使得UML变的更加简单。这4个通用的机制是：

1. 规格(Specifications)
   UML的规格提供了一个语义母板，此母板包含一个系统的所有模型的所有部分，各个部分以一致的方式相互联系。简单点说就是，UML的规格定义了UML的各个构造块的语法和语义上的文字描述。例如，类的规格就提供了对类所拥有的属性，操作，属性可见性，是否是抽象类等全面地描述。

2. 修饰(Adornments)
   UML中每一个元素基本都有对应的符号表示，可在符号上添加相关的修饰，使得符号能够表示更多规格中定义的细节。

   

3. 通用划分(Common divisions)
   在面向对象系统建模中，通常有三种划分方法：

   • 对类和对象的划分

   • 接口和实现的分离

   • 类型和角色的分离

4. 扩展机制(Extensibility mechanisms)
   UML是一种开放的语言，允许人们以受控的方式来扩展该语言。UML的扩展机制包括：

   • 衍型
     衍型(stereotype)扩展了UML的词汇，可以用来创造新的构造块。

   • 标记值
     标记值(tagged value)扩展了UML衍型的特性，可以用来创建衍型的规格的新信息。

   • 约束
     约束(constraint)扩展了UML构造块的语义，可以用来增加新的规则或者修改现有的规则。

   

体系结构

可视化，规格化，构建，文档化一个软件密集型系统要求能够从不同的视角来看这个系统。系统的体系结构(architecture)是在系统开发的整个生命周期中可以用来管理这些不同的视图，控制迭代和增量开发的最重要的制品。

体系结构是一些重要决策的集合，这些决策关于：

• 软件系统的组织

• 组成系统的结构元素和他们的接口的选择

• 这些结构元素的行为

• 逐渐组合这些结构和行为元素成为更大的子系统

• 体系结构的风格指导软件组织：静态的和动态的元素，以及这些元素的接口，协作，组成

软件体系结构不仅仅关心系统的结构，行为，同时也关心系统的用法，功能，效率，弹性，可复用性，可理解性，成本和技术的约束和折中，以及审美问题。

如下图所示，软件密集型系统最好能够5个相互连接的视图来表示。每个视图聚焦在系统的特定方面，是系统组织和结构的一个投影。

• 系统的用例视图包含用例， 这些用例从最终用户，分析师，测试人员等不同的视角描述了系统行为。在UML中，这个视图的静态部分描述在用例图，动态部分描述在交互图，如状态图，活动图

• 系统的设计视图包含了表达问题和解决方法的类，接口，协助。这个视图描述了系统的功能性需求，即应该提供给用户的服务。在UML中，这个视图的静态部分描述在类图和对象图，动态部分描述在交互图，如状态图，活动图

• 系统的交互视图包含系统各个部分间的交互，包括可能存在并发和同步机制。这个视图指出了系统的性能，弹性，吞吐量。在UML中，这个视图的静态部分描述在类图和对象图，动态部分描述在交互图，如状态图，活动图

• 系统的实现视图包含发布在物理系统的制品。这个视图指出了系统发布的配置管理，它由某些独立的文件经装配后可得到一个运行的系统。它同样也指出了从逻辑类或者组件到物理制品的映射。在UML中，这个视图的静态部分描述在制品图，动态部分描述在交互图，如状态图，活动图。

• 系统的部署视图包含运行系统的结点，结点形成系统的硬件拓扑结构。这个视图指出了组成物理系统的分发，交付，安装。在UML中，这个视图的静态部分描述在部署图，动态部分描述在交互图，如状态图，活动图。

软件开发生命周期

尽管UML是独立于开发过程的，但是为了从UML获得最大的效果，开发过程最好是这样的：

• 以用例驱动的

• 以体系结构为中心的

• 软件是个不断迭代/增量开发的过程

这里我理解的迭代是小功能的迭代发布，增量指的是几个小功能的发布版本集成为一个大版本的发布。具体有关开发过程不是本书的重点，可参考《The Unified Software Development Process》和《 The Rational Unified Process》两书。

到此本章结束，花了２天时间整理UML的基础概念模型还是值得的。