| UML软件工程组织 | |||
| |
|||
|
|||
系统模型的四个维度
作者：Fredrik Ferm, ECAT战略团队领导者 来源：IBM
| 本文内容包括:
本文来自于 Rational Edge：像 Rational 统一过程（RUP）和 Zachman 这样的架构框架能够帮助我们了解大型系统，以及如何查阅系统的依赖关系。但是当一个分析团队在检验一个真正的系统模型时，模型里的不同视图究竟表达了什么信息，分析团队成员在这方面彼此仍然会有误解。本文提出了一个改进方法来描述一个复杂系统模型所涉及的这些方面。 在我从事的许多项目里，与我的同事们进行的关于系统模型和如何将它们划分成几部分的讨论通常令人困惑而且不是很有效果。我认为问题之一是我们缺少组织和操作模型以及考虑其结构的通用方法。因此，在这篇文章里，我将就此问题提出我的观点并提供在操作系统模型和软件时对我来说十分有用的四个维度。 最具代表性的是，一个系统模型包含系统的许多方面。为了传达所有这些方面的信息，我们需要以某种方式组织模型，这意味着模型必须根据一些层次的规则被分成几部分。有许多关于这些规则的层次设置，最具代表性的是“架构框架”。一个架构框架提供关于一个系统模型应该由哪些部分组成以及模型因此应该描述系统哪些有趣的方面的信息。一个架构框架可能也会提供其他一些东西，但这篇文章的目的是将重点放在模型划分方面。 实际上有一个软件系统架构描述的层次：IEEE1471-2000。这个层次定义了一些术语，如系统、架构、架构描述、模型、视图、观点等等。同时也在“架构描述的概念模型”上详细说明了这些术语之间的关系，如图1所示。 1
图1:IEEE1471概念模型 现在，让我们考虑图1用到的一些术语。我将在下面一一讨论。 模型 正如我早期所提到的，模型是将要建立的系统的抽象。它们可以通过使用一些技术，包括统一建模语言（UML）被创建出来。 一个系统和它的架构描述可以创建在一个或多个模型中。有许多方法将这一描述划分到独立的模型中，但是至少从概念上来说，我们通常可以将所有的模型信息视为一个单独的模型。 视图 视图代表了您将在模型中查找到的描述或者某个维度的独立片断。模型中一个特定的信息片断可能被视为是零个、一个或者更多的视图。如果您为我们的模型使用统一建模语言，大多数视图将以一些类型的统一建模语言图的形式呈现。 观点 如果模型是信息的来源而且视图包含了信息的表述，那么观点就是定义应该如何生成这些视图表述。观点可以被认为是关于在每个视图里要表述什么类型的信息以及如何进行表述的规则集合。我们可以认为模型和视图是我们所看到的东西，而观点就是我们看到这些东西的眼镜。 如图1所示，IEEE1471层次规定每个观点应该表达对一个或多个涉众的关注。这意味着应该了解观点和涉众之间的映射关系。 正如上面所提到的，可以得到许多种架构框架。在这里我将描述一些框架的各个维度，在下部分将谈论我是如何看待将模型划分几个部分的。 RUP IBM Rational 统一过程?或者 RUP?，包含一个被称为“软件架构4+1视图”的架构框架。 2 这个框架为软件架构描述了五个必要的视图（或者更准确的说法是IEEE1471意义上的观点）。这些视图（观点）如图2中所示。
图2：软件架构的4+1视图 在4+1视图架构框架里，视图包括： 3
RUP SE IBM Rational Unified Process for Systems Engineering（RUP SE）是RUP的扩展，它覆盖软件工程以处理更加复杂的系统工程问题。RUP 中的许多概念仍然适用，但是有些地方有所改变。例如，在 RUP SE 里，来自RUP的架构框架（4+1视图）被另一个叫作“RUP SE 模型框架”的架构框架所取代， 4 如表1所示。
如在表1的单元格中所示，RUP SE 模型框架详细说明了一组视图。例如，我们看到的“角色定义”和“UML区域视图”。这些视图中每一个表示的是系统一个特定的方面。 视图从两个维度划分。表1中的水平方向，我们视为模型观点；垂直方向，我们认为是模型层次（例如，每个视图属于一个特定的模型层次和一个特定的模型观点）。 第一个维度——模型观点——相当于上面描述的 IEEE1471 种的观点的概念。在 RUP SE 模型框架中，模型观点代表系统模型关系的不同区域，最具代表性的是不同涉众群的关系。 RUP SE模型框架的模型观点更多的扮演了RUP的4+1视图架构框架里的视图所担任的角色。它们和模型观点设置不完全一样，其中每一个处理系统关系的一个特定区域。在RUP SE模型框架里为什么有不同的观点设置呢？因为在系统工程里，您必须处理在RUP中没有包含的软件开发中的一些东西，例如系统里的人。因此，RUP SE模型框架包含一个角色观点，这在4+1视图中是没有的。 RUP SE模型框架的第二个维度是模型层次，用于处理规格说明的层次。这意味着在更高的模型层次里，系统没有被详细说明，信息包含了抽象的系统问题。模型层次越低，被添加的细节就越多；因此，您能获得高层次的规格说明。而且，随着模型层次的降低，您能通过较低的层次中新的模型元素实现高层次的模型。这意味着系统设计中的常用工作流程代表您的工作方式从最高的模型层次向下降至一个较高的细节层次。 其他的架构框架 除了上面描述的两个之外，还有许多其他架构框架的例子。国防部架构框架(DoDAF)规定了许多美国军用系统的系统模型中应该有的视图。 5 在DoDAF里，视图被分成四个组：AV（整体视图）、OV（运行视图）、SV（系统视图）和 TV（技术层次视图）。在这些组里，我们发现到了一些视图的例子，例如 AV-1（总体介绍和概要信息）、OV-5（运行活动模型）、SV-1（系统接口描述）和TV-2（技术层次预测）。 6 另一个例子是 Zachman 框架。 7 Zachman 框架采取两个维度的方法，将一个模型分成涉众（行）和架构方面（列），如表2所示。
需要注意的是 zachman 框架并不意味着是一种系统模型的架构框架，相反它掌控企业架构，是一个比系统建模更大的问题。但是我们可以看到这种框架与其他几个提到的模型有很多的共同点。Zachman 框架将模型分成不止一个维度，在这些维度的交集处（表格中的各单元）能够看到我们所建模型系统的描述。 到目前为止我已经讨论了在系统建模部分中提到的著名的架构框架，但正如介绍中提到的，我发现尽管我们可以依赖这些架构框架，但是人们操控这种系统模型还是会很困难。这将导致混乱并不利于交流，这两点反过来也会导致系统质量的降低和项目开发的延迟。 如果4+1视图模型被用于系统建模，它是单维度的，它根据一个规则将系统模型分成几个部分。RUP SE 模型框架引入了另一个维度，为我们提供了更为精确的系统建模导航，但是我想这仍是不够的。我得出的结论是我们应该添加另外两个维度使得我们在操控系统模型上真正具有四个有趣的维度。 第一个维度——观点 第一个维度是观点，它相当于RUP SE模型框架如何看事情。我认为观点维度是十分重要的，因为它很好的分离了模型中的关系。而且，我们可以将工作分成许多独立的观点，使得每一个观点以较低的模型层次由一个特定的工程学所操控。例如，逻辑观点可能由软件工程所操控，而物理观点可能由硬件工程学所操控。 RUP SE模型框架为我们理解系统工程中要使用哪一个观点提供了一个很好的开端。如下面表3所示，这些是早在表1显示的观点。
当然，我们不需要为全部的系统模型使用所有这些观点；相反我们只应使用那些有意义的。我们也可以为特定的系统模型添加新的观点。例如，一个安全性观点对于带有特定安全需求的系统模型是有用的。 第二个维度——模型层次 我使用的第二个维度是来自RUP SE的模型层次，这是必要的，因为我们需要能够以变化的精度层次和变化的规范层次来表达我们自己。在开发的早期，我们没有全部的细节，但是我们需要能够表达我们了解什么。随着开发的深入，添加了更多的细节，我们也因此降低模型的层次。 在构建略微复杂的系统的过程中，保持模型信息创造于一个较高的层次或许是一个好主意，即使我们已经使用了一个较低的层次并且加入更多的细节。这是因为简化的系统描述对于需要一个整体观点或者正在学习系统的人来说是有帮助的。如果我们一次提供了所有的细节（较低层次），他们可能在理解系统全局时会很困难。此外，一个单独的抽象设计（高层次）可能以许多不同的方法以及变化的性能和价格点来实现。 在要使用哪一个模型层次这一问题上，我建议使用来自RUP SE的模型层次，除非有特殊的理由来增加或去除任何模型层次。来自RUP SE模型框架的模型层次如表4中所示。
第三个维度——系统层次 第三个维度处理的是系统层次以及层次里当前的视图位置。首先我将通过描述系统层次解释这一点，然后说明为什么我们必须将这些层次视为一个维度。这一概念可与 “抽象层次”的概念相比较，这是一个经常用到的词，但是我想会迷惑很多人；后面我将更多地解释这一点。 如果我使用一点系统理论推理，我们可以认为每个系统都有分离内部和外部的边界。系统的内部包含许多可以协同实现系统目的的“部分”——例如，产生系统交付其环境的服务。在一个由子系统组成的方法中，我们要将核心系统内部的“部分”也视为系统自身，这意味着较大的核心系统由许多子系统组成。同样的道理，这些子系统是由下级子系统组成，我们可以将这种分层结构按照我们的需要深入到系统内部。或者，通过讨论再返回到更大的系统，我们可以移到这个层次的更高一级，需要注意的是核心系统所起的作用与子系统在其自身周围的系统中所起的作用是一样的。 这意味着典型的系统模型将包含一个略微复杂的系统层次。这些系统中的每一个可能以同样的方式被模拟出来（他们都是系统），但是清楚的知道我们正在建模的是哪一个系统是十分重要的。出于这个原因，我们已经介绍了第三个维度：系统层次，它在整体的系统层次里定位系统。 让我们看一个系统层次使得事物更加清晰的例子。假设我们正在建模的系统是一艘军舰，让我们使用“核心系统”这一术语来表示这艘军舰。这个系统由许多的子系统组成——例如，命令和控制系统、通信系统、推进系统、传感系统和一些武器系统。在这一层次里，这些系统处于低于军舰系统的系统层次。如果我们转向其他方向，我们可以说我们的军舰正在一个较大的系统里工作，那就是舰队。舰队包含军舰作为子系统，而且也可以有其它的子系统，例如航运供给。这个例子如图3所示。
图3：一个表示系统层次的 UML 类图 在图3里，我们可以清晰的看到三个系统层次：核心系统的层次、周围系统的层次和子系统的层次。当然，在实例中可能有更多的层次，但是掌握要点就足够了。也要注意在实例中，子系统可以支持更多更高层次的系统。 很显然，对于系统模型的任何视图来说了解核心系统层次是十分重要的。例如，当我们考虑军舰及显示命令和控制、传感器和武器如何协同合作抗击目标的视图时，我们在军舰这一层次上完成这一点。在这一层次上的推论将给下一层次的系统——如，命令和控制系统、传感系统和武器系统－－提供必备条件。例如，我们降低一个层次并将中心改为传感系统，现在我们可以看到传感系统如何与这一层次上的其他系统——命令控制系统和武器系统－－协同合作。 在上面解释的例子里，传感系统既出现在军舰层次也出现在传感器层次。尽管如此，在如何介绍它和它为什么是层次的一部分之间仍有不同之处。在军舰层次，传感器在军舰内部而且其出现是因为它们需要使得军舰完成其任务。而在传感器层次，传感系统自身就是核心系统；因此我们考虑的是传感器的外部系统。有时这一区分类似于黑盒（外部）与白盒（内部）的比较。在许多例子里，黑盒用于了解核心系统（在这个例子中是传感系统）的需求，而白盒用于了解核心系统（在那个例子中是军舰）的实现情况。因此，区分看待传感器的两种方式十分重要，同样了解我们正在查阅的每一个视图的特定系统层次也十分重要。 我听说过很多次人们使用“抽象层次”这一术语来表示上面描述的系统层次。尽管如此，我认为既然“抽象层次” 对不同的人来说意味着很多事情，那么这是一个不太合适的术语；例如，一些人使用“抽象层次”并不意味着系统层次，而是模型层次，这在我看来是完全不同的维度。我已经参加过很多的讨论，发现术语的两个不同的意思源于误解。因为这一点，我选择完全不使用“抽象层次”这一术语，而是通过使用“系统层次”和“模型层次”来解释。 第四个维度——描述类型 除了上面提到的三个维度外，第四个维度处理每个视图包含的描述类型。这包括含在视图里的模型元素的选择以及视图的目的。 让我们通过一个例子来说明。让我们将城市公交系统作为我们的核心系统，查看公交系统系统的一个方法（这是一个描述类型）是查看整个公交系统系统并考虑它是由哪些部分组成。 10 这会提供给我们一个如图4的视图，显示公交系统是由六个相互依赖的子系统组成。
图4：城市公交系统构成 查看公交系统（这是另一个描述类型）的另一个方法是考虑公交系统执行的特定任务。例如，当我们查看一个特定的任务——人的交通工具时，可能涉及较少的部分。这会给我们提供一个如图5所示的图。
图5：涉及市民交通工具的公交系统部分 在图5里，我们发现公交系统执行这一特定的任务时，使用的是整套子系统的子系统。 图4和图5中提供的例子显示了不同描述类型之间的不同之处。这两个例子显示的是从相同设置的模型实体里选出的模型实体（在这个例子中是类）。但是选择是不同的，因为我们想用例子视图传递不同的信息（在图4中，我们想要查阅公交系统某些部分子系统的完整列表；在图5中，我们想查阅参与一个特定任务的子系统）。 这些不同的选择层次不符合到目前为止我提到的其他三个维度中的任何一个。它们与观点无关，因为两个例子（图4和图5）都显示的是来自于逻辑观点的模型实体。它们与模型层次也没有关系，因为两个例子都处于相同的详述层次。最后，这些选择层次也与系统层次无关，因为两个例子都处理公交系统如何被分成几部分。 与其他三个维度的这些不同之处促成了系统模型的第四个维度，它处理视图的特定目的。这一目的可以是表示系统特定部分的所有实体，或者表示系统如何运行以完成特定的任务。 11 我选择将这一维度称为“描述类型”。 上面解释的目的为我们提供了三个描述类型，注意这里黑体字显示的。在系统特定的部分表示所有的实体被我称作的内容 图所涵盖。解释系统如何实现特定的任务由实现来处理，它被分为静态实现和动态实现。所有三个描述类型在下面进行说明。 图4是一个内容图的例子。它显示了在展示公交系统所有部分（在这个例子中的子系统部分）的意义上公交系统的内容。 这一描述类型的重要方面是概括了系统的一个区域而且显示那一区域的所有部分和它们的关系。被讨论的区域可能是整个系统、系统的一层或者一些相似的区域。这一描述类型考虑所选区域的内部结构，但是我不想将这一描述类型称为“结构”，因为结构图是 UML 2 中的其他一些事物。 如果我们查看系统的所有内容视图，我们将发现组成系统的所有部分以及它们是如何相互关联的。因此它们将详细说明系统的全部内容。 除了内容视图外，我们也需要显示系统如何运行来实现其目的。在我们模型的某些地方，我们有关于系统应该做的任务的描述，这可以通过用例或服务来表示。对每一个任务来说，我们将创建一个实现来描述系统如何执行那个任务。我们也可以创建实现来描述系统如何解决特定的问题。 不论实现是关于什么，最具代表性的是由两部分组成：静态实现和动态实现。 一个静态实现如图5所示。静态实现显示的实现中包含的架构的组成部分。在大多数例子中，静态实现中出现的组成部分可能属于内容的不同区域，这意味着它们不出现在相同的内容视图中。因此静态实现是把内容区域归类汇总的一种方式。 动态实现描述在静态实现里显示的组成部分如何协同合作使事情发生。这可以根据UML序列图来表示，但是它也可以用其他方式来表示。最重要的是它描述了谁做什么、以何种顺序来做以及正在交流的信息是什么。图6显示的是一个来自公交系统样例的动态实现。
图6；动态实现 那么，为什么我们真的需要考虑所有这四个维度？因为两点原因我发现它们十分有用：理解特定的视图以及为要开发的模型提供导航图。 理解特定的视图 当我们根据这四个维度考虑特定的视图（在大多数例子中是一个或多个UML图表）时，我们理解视图想要展示的更多内容。例如，如果我们假定视图是来自关于公交系统和模型层次分析的物理观点的静态实现，我们可以理解视图想要表达的许多东西。用这种方法描述视图帮助我们理解视图提供的信息，同时也帮助我们理解视图如何适合更大的范围。 同样地，如果人们关于视图在什么地方适合四个维度有不同意见时，将不可避免地导致误解。我发现在所讨论的系统模型的四个维度不被认知时，这一点相当普遍。因此，理解四个维度本身和一个特定视图在什么地方适合这四个维度将帮助澄清误解。 理解四个维度的第二点理由是它们能够为模型提供导航图。在开发之前以及开发过程中，导航图可以帮助我们理解我们需要开发模型的哪些部分。开发之后，导航图将帮助我们理解模型由哪些部分组成，以便我们能够更加容易进行操作。 这样一个模型导航图可以通过组成模型的四个维度的联合价值是什么来表示。例如，我们可以认为我们将开发逻辑、物理和角色观点；我们将开发结构视图和基于这些观点的实现视图；而且我们将在最高的系统层次和子系统上来实现这些，等等。 我不想建议您必须为每一个系统层次使用所有观点、所有模型层次和所有的描述类型。通常来说，您应该使用与项目相关的那些部分。这可能意味着特定的观点、模型层次、系统层次或者描述类型被略过，或者意味着特定的结合（例如，信息观点里的动态实现）被略过，可能也意味着并非所有的方维度是您感兴趣的。例如，我曾参加过一个项目，这个项目对模型层次并不干兴趣，因为这个项目是关于创建有关系统的整体概况而且不用挑出所有的细节。 致谢 首先，我要感谢那些帮助我完成这篇文章所描述的观点的人，这些观点是在我与 H?kan Beckman 和 Lars Schylberg 一起与其他人的交流中得出的。而且我想感谢 Dave Brown 和 Jim Densmore 帮助我对文章进行点评，我还要感谢 Michael Perrow，因为他提出了大量的修改建议。 注释 1我已经略微简化了架构描述的概念模型，因此已经去掉了那些对这篇文章来说没有趣味的概念。 2最初记录于 Philippe Kruchten 的一篇文章中，“架构的4+1视图模型”，IEEE Software. 12(6)，1995年11月。 3 这些描述都或多或少有所简化。这篇文章的目的不是详细地解释4+1视图，而是将其作为一个架构框架的例子来展示。 4请注意这并不是对 RUP SE 模型框架的完整描述，而只是架构框架的一个例子。在 RUP SE 上有许多信息资源，包括 Murray Cantor 写的由三篇文章组成的系列。关于 RUP SE 模型框架的描述在第二篇文章里：Murray Cantor, "Rational Unified Process for Systems Engineering, Part II: System architecture," Rational Edge，2003年9月。 5DoDAF 框架使用“视图”一词，但是它们实际上是IEEE1471里的观点。我将使用视图一词来与框架相一致。 6IBM 针对 DoDAF 方法的完整描述，查看 Chris Widney 撰写的 "美国国防部体系架构框架（DoDAF）使用的 IBM Rational 方法的 第 1 部分：运作视图"，Rational Edge，2006年4月；还有"第 2 部分：系统视图"， Rational Edge，2006年5月。 7关于 Zachman 框架的最新描述以及它与 RUP 和 UML 的关系可以在 Rational Edge 这一期的其他文章中找到。查阅 Vitalie Temnenco 撰写的 "UML、RUP 和 Zachman 框架：完美结合。 8请注意角色和参与者的区别。角色是在核心系统里面工作的人。参与者是核心系统之外的当事人（例如，个体）。4+1视图框架并不涉及角色的原因是：根据 RUP 使用的系统定义，人们可能不是系统的一部分。而在系统工程里，他们的确可以是系统的一部分。 9我已经通过一个 UML 模型来说明层次结构，用铅板印刷的类代表的是系统。一个系统与其子系统之间的关系以及 UML 所特有的元素关系一起显示出来。这并不意味着这是模拟系统层次的唯一方法，您可以以许多不同的方式来模拟。我只是选择了这种建模方法来显示系统的子系统和周围系统的例子。 10这可能并不是将公交系统分成几部分的最好方法，我只是想显示整体说明这部分的例子。 11可能也有其他的用途，但是这些对大多数系统模型来说似乎足矣。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
