UML系列文章（32）体系结构建模---系统和模型

UML是一种用于可视化、详述、构造和文档化软件密集型系统制品的图形语言。可以用UML来对系统建模。模型是对现实世界的简化---即对系统的抽象，建模的目的是为了更好地理解系统。一个系统可能被分解成一组子系统，它是为实现某一目标而组织起来的元素的集合，并且它是由一组可能来自不同视角的模型来描述的。类、接口、构件和结点等事物是系统模型的重要组成部分。在UML中，可以用模型来组织这些元素以及系统中的所有其他抽象。当进入较复杂的领域时，就会发现，在某一抽象层次上的系统看起来像另一个更高抽象层次上的子系统。在UML中，可以将系统和子系统作为一个整体来建模，从而能无缝地控制问题的规模。

结构良好的模型可以帮助从不同的但有联系的方面来可视化、详述、构造和文档化一个复杂的系统。结构良好的系统在功能、逻辑及物理方面是内聚的，是由松散耦合的子系统构成。

1. 入门

对于复杂的建筑物，必须进行平面图设计、立体图设计、暖气、冷气设计、电气设计和管道设计，或许甚至是网络设计。没有任何一个模型能够充分捕捉一个复杂建筑的所有令人关注的方面。

在UML中，可以将软件密集型系统中的所有抽象组织成一个模型，每个模型代表正在开发的系统中的相对独立而又重要的方面。然后用图来可视化这些抽象的有趣集合。审视系统体系结构的5种视图，是沟通与软件系统相关的不同人员对系统理解的特别有用的方法。总之，这些模型一起提供了对系统结构方面和行为方面的完整描述。

对于较大的系统，会发现这样的系统中的元素可以被有意义地划分到各个独立的子系统中，从较低的抽象层次观察子系统中，每个子系统都像是一个较小的系统。

    如下图所示，UML为系统和子系统提供了一个图形表示。这种表示法允许可视化地将系统分解为较小的子系统。在图形上，系统和子系统都被画成一个衍型化的构件的图标。模型和视图有专门的图形表示，但很少使用它们，因为它们主要是由用于组织系统的不同方面的工具所操纵的事物。

 2. 术语和概念

    系统（system）是一组为了完成一定的目标而组织起来的元素，这些元素是用一组模型分别从不同的角度描述的。一个系统可以被分解为一组子系统。子系统（subsystem）是元素的组合。其中一些元素构成了对由另一些被包含元素所提供的行为的规约。在图形上，系统和子系统都画成一个衍型化的构件的图标。

   模型（model）是对现实世界的简化。是对系统的抽象，建立模型的目的是为了更好地理解系统。视图（view）是模型的投影，它是某个角度看模型或突出模型中的某一侧面，而忽略与这一侧面无关的实体。

2.1 系统与子系统

    系统是正在开发的并为之建模的事物。系统包括构成这个事物的所有制品，其中包含它的所有模型及建模元素，如类、接口、构件、结点以及它们之间的关系。在可视化、详述、构造和文档化一个系统时所需要的所有事物都是系统的组成部分，而在可视化、详述、构造和文档化一个系统时所不需要的所有事物都位于系统以外。

    在上图UML中，系统被表示为衍型化的构件。作为衍型化的构件，系统拥有自己的元素。如果展开一个系统，将会看到系统的所有模型及各种建模元素（包括图），也许它还被进一步分解成子系统。作为一种类目，系统可以有实例（一个系统可能被部署在现实世界中的多个实例中）、属性和操作（系统外部的参与者可以把系统作为一个整体进行操作）、用况、状态机和协作，所有这些可一起描述系统的行为。系统甚至可以实现接口，这对于建立系统的系统很重要。

    子系统只是系统的一部分，它用来将一个复杂的系统分解为几乎相互独立的部分。处于某一抽象级别的系统可以是更高抽象级别的系统的子系统。

    系统和子系统的主要关系是组合。一个系统（整体）可以包含多个子系统（部分）。子系统之间也可以建立泛化关系。利用泛化关系，可以对子系统建模：其中的一些代表一般种类的系统，而另一些代表对这些系统的特定剪裁。这些子系统之间有各种各样的连接。

注解：系统代表在给定语境中的最高级别的事物，构成系统的子系统提供了对整个系统的完整的、无交叉的划分。系统是最高层次的子系统。

2.2 模型与视图

    模型是对现实世界的简化，当然是定义在被建模的系统的语境内的现实世界。简而言之，模型是对系统的抽象。子系统将较大的系统中的元素分割形成一些独立的部分的划分；模型是对可视化、详述、构造和文档化一个系统的抽象的划分。二者之间的区别虽小但非常重要。

    将一个系统分解为子系统的目的是为了在一定程度上独立开发和部署这些部分；将系统或子系统的抽象划分到一些模型中的目的是为了更好地理解正在开发和部署的事物的不同方面。就像飞机这样的复杂的系统可以有许多组成部分一样（如机身、推进器、航空电子设备和旅客子系统），这些子系统或系统作为一个整体可以被从多个不同的视角（如结构、动力、电子、加热、制冷模型等视角）来建模。

    一个模型可以包括许多制品（如主动类、关系和交互），以至于在系统级上，简直难以立刻领会所有这些制品。可以把制品看作模型的投影。对于每个模型，将有多个能让你窥视由模型所拥有的事物的图。一个视图包括由模型所拥有的事物的一个子集，视图通常不可以跨越模型边界。尽管包含在不同的元素之间可能存在跟踪关系。但模型之间没有直接关系。

2.3 跟踪

    对类、接口、构件和结点等元素之间的关系的说明是任何模型中的一个重要结构部分。同样，对存在于不同模型中的文档、图、和包等元素之间的关系说明是关联一个复杂系统的开发制品的一个重要组成部分，其中的许多制品可能有多个版本。

    在UML中，可以用跟踪关系对存在于不同模型中的元素之间的概念关系建模，跟踪关系不能用来表达同一模型中元素之间的关系。跟踪关系可被表示为衍型化的依赖关系。

 

3. 常用建模技术

3.1 对系统的体系结构建模

    使用系统和模型的最常见的用途是把那些用来可视化、详述、构造和文档化系统的体系结构的元素组织起来。最终，这实际上涉及到了软件开发项目中的所有制品。当对系统的体系结构建模时，要捕捉关于系统的需求、逻辑元素和物理元素的决策。还要为系统的结构方面和行为方面以及形成这些视图的模式建模。最后，要把注意力集中在子系统之间的接缝以及需求到部署的跟踪上。

对系统的体系结构建模，要遵循如下策略：

• 识别用来表示体系结构的视图。在多数情况下，这包括用况视图、设计视图、交互视图、实现视图和部署视图，如图所示，

 

• 详细描述系统的语境，其中包括系统周围的参与者。

必要时，将系统分解为它的基本子系统。

对系统以及它的子系统进行下列活动：

•  定义系统的用况视图，其中包括由最终用户、分析人员和测试人员使用的描述系统行为的用况。利用用况图对系统的静态方面建模、利用交互图、状态图和活动图对系统动态方面建模。
• 定义系统的设计视图，其中包括构成问题空间和解空间的词汇的类、接口和协作。利用类图和对象图对系统的静态方面建模，利用交互图、状态图和活动图对系统的动态方面建模
• 定义系统的交互视图，其中包括构成系统并发与同步机制的线程、进程和消息。可以利用与设计视图相同的图来描述交互视图的静态和动态方面，但侧重点是表示线程和进程的主动类和主动对象以及消息和控制流。
• 定义系统的实现视图，其中包括用于装配和发布物理系统的制品。利用制品图对系统的静态方面建模，用交互图、状态图和活动图对系统的动态方面建模。
• 定义系统的部署视图，其中包括构成系统的硬件拓扑结构且系统在其上执行的结点。利用部署图对系统的静态方面建模，利用交互图、状态图和活动图对其执行环境中的系统的动态方面建模。
• 用协作来为形成这些模型的体系结构模式和设计模式建模。

3.2 对系统的系统建模

   某一抽象级别上的系统看起来像更高抽象级别上的一个子系统。同样，一个抽象级别上的子系统对于负责开发这个子系统的小组而言也可以看做是一个完整的系统。

4.提示和技巧

    选择合适的一组模型来可视化、详述、构造和文档化一个系统是很重要的。一个结构良好的模型，应满足如下要求：

• 从不同的且相对独立的视角提供了对现实世界的简化。
• 自包含的，读者可以不需要其他背景知识就可以理解其语义
• 通过跟踪关系，与其他模型之间形成松耦合。
• 在整体上（与相邻的模型一起）提供系统制品的完整表达。

类似的，将一个复杂的系统分解为结构良好的子系统也是重要的。一个结构良好的系统，应满足如下要求：

• 在功能、逻辑和物理上是内聚的。
• 能够分解成几乎独立的子系统，这些子系统较低的抽象层次可以被看作是系统。
• 可以通过一组相关但没有交叉的模型进行可视化、详述、构造和文档化。

    UML提供了模型的图形符号，不过最好不要用它；对系统建模，而不是对模型本身。编辑工具会提供浏览、组织和管理模型集合的工具。

当用UML绘制一个系统或子系统时，应遵循如下策略：

• 使用每个系统或子系统作为与它们相关联的所有制品的起始点。
• 只显示系统和它的子系统之间的基本聚合关系，通常，将它们的连接的细节放在较低层的图中。