9.5跨视图的文档

 

现在，我们看一下使视围文档完整所需要做的工作，即捕获应用于多个视图或作为一 个整体的文档软件包的信息。跨视图的文档仅由3个主要方面组成，我们将其总结为“如何-什么-为什么”：

 

(1)如何安排和组织构架的文档，以使构架的涉众能够有效可靠地找到所需要的信息。 本部分由于一个视图目录和一个视图模板组成。

 

(2)构架是什么。在这里，要捕获的信息是一个简短的系统概述，它能够使所有读者 了解系统的目的，视图彼此之间关联的方式，元素列表和元素出现的地方，以及适用于整个构架的词汇。

 

(3)为什么构架是这个样子：系统的上下文，用来以某种方式塑造构架而强加的外部限制条件以及粗粒度大规模决策的基本原理。

 

图9.3对这些耍点进行了总结。

 

9.5-1如何针对涉众组织文档

 

构架文档的每个套件都需要介绍性内容，以向经验不多的涉众解释其组织结构，并帮助该涉众获得他最感兴趣的信息。有两种关于“如何”组织构架文档的信息：

 

•视图目录

•视图模扳

 

视图目录。视图目录是对视图的介绍性信息，设计师将其放在了文档套件中。

 

当使用模板套件作为交流的基础时，对于新读者来说，就有必耍确定在哪儿可以找到 特定的信息。目录中包含该信息。当使用文档套件作为分析的基础时.有必要知道哪些视 图包含进行某个特定分析所需要的信息。例如，在性能分析中，资源消耗就是•块重要的 信息，目录能够使分析人员确定哪些视图包含与资源消耗相关的属性。

 

对于在文档套件中给出的每个视图来说，在视图目录中有一个条目。每个条目中应该 包含如下信息：

 

(1)视图的名称以及它所说明的样式

 

(2)视图的元素类型、关系类型和属性的描述

 

(3)视图目的的描述

 

(4)关于视图文档的管理信息，如最新版本，视图文档的位置和所有者。

 

视图目录的目的是描述文档套件，而不是编成文档的系统。系统的细节在单个视图中 进行了说明，不属于视图目录所描述的范围。例如，视图中包含的实际元素列在了视图的 元素目录中。

 

视图模板。视图模板是视图的标准组织结构。图9.1和周围的文字提供了视图模板的基础，它定义了视图文档的标准部分以及每一部分的内容和规则。视图模板的目的也就是 任何标准组织的目的：它可以帮助读者在感兴趣的部分快速査找倍息，并且它能够帮助编 写人员组织信息，并建立了了解还有多少工作没做的标准。

 

9.5.2构架是什么

 

本部分提供其构架被编成文档的系统的信息，视图彼此间的关系和构架元素索引。

 

系统概述。这部分简要描述了系统的功能.其用户是谁以及任何重要的背景或限制 条件。目的是使读者在头脑中对系统及其目的有一个.•致的模型。有时，整个项目有一个 系统概述。在这种情况下，构架文档的这一部分将指向该系统概述。

 

视图之间的映射。因为构架的所有视图描述的都是同•个系统，因此，我们可以合理 地推断出任意两个视图都有很多相同的内容。帮助文档的读者理解视图间的关系能够使他 洞察构架是如何作为一个统一的概念整体来发挥作用的。可以通过提供视阁间的映射来弄 淸视阁间的关系，这是加深理解和减少混淆的关键所在。

 

例如.毎个模块都可以映射到多个运行时元素上，如类映射到对象上。当映射不是一对一，或当系统的运行时元素根本不是作为代码元素存在时，如当它们在运行时被导入， 或在构建或载入时被集成.情况就复杂了。这些是相对简单的一（或无〉对多映射。但一 般说来，一个视图中元素的部分可以映射到另一个视图中元素的部分上。

 

没必耍在每对视阁之间提供映射。选择提供了重要且关键的信息的视图。

 

元素列表。元素列表就是出现在任何视图中的所有元素的索引，连同一个指向定义每 个元素的位置的指针。这有助于涉众快速找到自己感兴趣的项。

 

项目词汇。该词汇表列出并定义了对系统来说具有特殊含义的术语。涉众也会非常喜欢缩写词列表以及每个缩写词的含义。如果已经有了合适的词汇表.那么，-个指向该词汇表的指针就足够了。

 

9-5.3为什么构架是这样：基本原理

 

在目的上与视图的棊本原理或接口设计的基本原理类似，跨视图基本原理解释了整体构架实际上是其需求的一个解决方案。可以使用该基本原理解释：

 

•关于满足需求或满足限制条件的系统范围内设计决策的含义 

•，添加个有预见性的新滞求或改变现有需求时对构架的影响 

•在实现解决方案中对开发人员的限制 

•拒绝采用的决策方案

 

—般说来，基本原理解释了做出决策的原因以及在改变决策时的暗含的意义。

 

9.6统一建模语言

我们已经重点讨论了应该包含在构架文档中的信息种类。从某种意义上说，构架表达了软件系统的基本信息。该基本信息独立于捕获它的语言和表示法。然而，现在统一建模语言 (Unified Modeling Language, UML)已经成为对软件构架进行编档的事实上的标准表示法。然而必须说明的是，在视阁的主要表示中，我们主要采用了 UML。在元素或元素组的行为中，视图也发挥了辅助作用。向UML图中填充必耍的支持文档（元素目录、 基本原理等）是设汁师的工作，这是合理的工作所要求做的。UML并不对组件、连接器 、接口语义或系统厲于构架层次的其他方面直接提供支持 。尽符如此，在大多数情况下我们都可以使用UML提供的构件来获得满意的效果，至少制作构架视图的主要表示时是这样的。下面从模块视图展开讨论。

 

模块视图

模块就是代码或实现单元，模块视图就足模块及其接口和关系的列举。

接口，图9.4展示了可以如何用UML表示槐块接口。UML使用“棒棒糖"来表示接

口，它可以被附加到类和子系统上。

 

UML还允许将类符号（方框）构造为接口：虚线空心箭头表示元素实现了一个接口。 可以在类符号的底部标注上接口的签名信息：方法名、参数、参数类型.等等。棒棒糖表 示法通常用于表示从元素到该接口的依赖，而方框表示法允许更加详细地描述接口的语 法，如它所提供的操作。

模块。UML提供各种构件来表示不同种类的模块（模块的种类如：类、层、子系统），图9.5给出了一些例子。UML有 一个类构件，它是模块的面向对象的特化。可以在功能分组很重要的地方使用软件包，如 表示层和类时。如果要求接口和行为的规范，那么，可以使用子系统构件。

                                        围9.5 UML模块表示法示例

 

图9.6给出了如何用UML表示模块视图本地的关系。模块分解依赖于“是一部分” 关系。该模块使用视图依赖于依赖关系，模块类视图依赖于泛化或“是一个”关系（也被 称为“继承")。

 

                        图9.6 UML关系表示法的示例 

            模块B是模块A的一部分.模块D依賴于模块C.模块F是模块E的一个类型

 

聚合。在UML中.可以使用子系统构件表示包含其他模块的模块（子系统构件可以表示为一个模块）；类框通常用于分 解的叶（leaves)。子系统用作软件包和分类器。作为软件包，可以将其进行分解，因此就 适合于模块聚合。作为分类器，它们封装其内容，可以提供显示接口。采用UML用如下 3种方式之一描述聚合：

 

•模块可以嵌套（参见图9.7的左半部分）。

 

•可以展示两个连续的图（可能链接在一起).其中第二个图是对在第一个图中展 示的模块内容的描述。

 

• 在父和子之间画了一条表示组合的弧线（参见图9.7的右半部分)。

 

图9.7    带嵌套的UML分解聚合模块被表示为软件包 （左)：带有弧线的UML分解（右）

 

在UML中，组合就是某种形式的聚合（组合包含组成的意思），它具有隐含的强大的所有关系一也就是部分随着整体存在和消失。如果模块A由榄块B和模块C组成，那么，如果没冇A的话，

B或C就不能存在，如果A在运行时遭到了破坏，那么，B和C也会遒到破坏。因此， UML的组合关系的含义已经超出了实现单元的结构化问题：该关系还陚予了元素-个运 行时属性。作为设计师，在使用UML的组合关系之前.您应该确保已经适应了该属性。

 

泛化。表示泛化是UML的核心内容，其中模块被表示为类（尽管它们还可能被表示 为子系统)。            图9.8给出了 UML中的基本表示法。

                        图9.8采用UML用两线样式对泛化进行编档

 

阁9.8中的两个图在语义上是相同的。UML允许用省略号(...)代替子模块，这说明一个模块可能会有比图屮所显示的更多的子模块，很可能还有其他子模块„模块Shape 是模块 Polygon. Circle 和 Spline 的父模块，而 Polygon. Circle,和 Spline 又是 Shape 模块 的子类、子模块或子孙。Shape模块更加一般，其子模块是特化的版本。

 

依赖，图9.6给出了依赖的基本表示法。可以在层中找到依赖在构架层次上的最重要的表现。令人沮丧的是，UML没有与层对应的内建的原语。然而，它可以使用软件包表 示简单的层，如阁9.9所示。这些是对元素进行分组的通用机制,，UML具有针对系统和子系统预定义的软件包（使用包图表示系统和子系统）。我们可以通过将软件包定义为软件包构造型为层引入一个额外的软 件包。可以把层表示为具有限制条件的UML软件包，该软件包将模块集合在一起。软件 包之间的依赖关系是“允许使用”。我们可以使用在层名称的前面用构造型名称<<|ayer» 的软件包表示法指定层，或引入一个新的图形表示法，如带阴影的矩形。

 

9.6.2组件-连接器视图

在UML中，没有-个首选的策略来对组件-连接器（C&C)视阁进行编档，但有大屢 方案可供选择。毎个方案都有优缺点。表示组件-连接器类型的•个很自然的方案开始于 UML类概念。

 

图9.10说明了使用简单的管道-过滤器系统的一般性概念。这里，过滤器构架类型表 示为UML类Filter过滤器的实例（如Splitter)被表示为对象实例图屮相应的对象。为了 提供一个命名空间边界.我们把描述放在了软件包中。MergeAndSort （表示为details)的 表示在别的地方将被表示为另一个软件包。

                                

            

            

现在，我们仔细分析-下这个策略。

 

组件..构架描述中的类型/实例关系与UML模塑中的类/对象关系非常匹配。类似构架 描述中的组件类型，UML类是第一类实体，它们具有用于捕获软件抽象的丰富的结构。 由于可以使用UML描述性机制的全部集合描述类的结构、厲性和行为，使得对于描述细 节和使用基于UML的分析工具來说，这是一个很好的选择„可以将构架组件的特性表示 为类属性，或用关联表示构架组件的特性；可以使用UML行为模型描述行为：可以使用 泛化将组件类型集合联系在•起。还可以通过附加一个标准的构造型来详细描述实例或类 型的语义。例如.可以把<<process>>构造型附加到组件上，以指出它是作为一个独立的进 程运行的。请注意，MerBeAndSort和其子结构之间的关系是使用依赖关系衣示的。

                            Figure 9.11. Five ways to represent interfaces to components (ports)

 

 

接口。可以用5种方式展示组件的接口（有时称为端口），如图9.11所示，它们是用 表达力的升序来描述的。然而，随着表达力的提高，复染性也在提高。因此您应该挑选适 合您的目的第一个策略。

•    选择1:没有显式表示。省略接口可以画出最简单的图，但这样做所带来的非常 明显的问题是没有方法来刻画主要表示中接口的名称或属性。尽管如此，如果 组件只有一个接口，如果可以根据系统拓扑推断出接口，或者如采在別的地方对 该图进行了求精.那么，这个选择也可能是合理的。

 

•    选择2:接口表示为注解。将接口表示为注解给出了一个提供接口信息的场所. 尽管注解在UML中并没有语义值，因此不能作为分析的基础。此外，如果不关 心接口的详细厲性.那么，这种方法可能是合理的。

 

•    选择3:接口作为类/对象属性。将接口作为类/对象的属性使它们成为正式结构模型的一部分，但在类图中，它们可能只有一个简单的表示——基本上是一个名称 和一个类型。该约束限制了此选择的表达力。

 

•    选择4:接口作为UML接口。在描述组件类型的类图中.UML棒榨糖表示法提 供了接口的紧凑描述。在实例图中，与接口实例对应且由接口类型名称限定的

UML关联角色提供了 一个紧凑方法，它展示了组件实例通过一个特定的接口实 例进行交互。该方法提供了组件和接口在视觉上截然不同的描述，其中可以清楚 地看到作为丛属的接口。

 

然而，该策略并没有提供组件的环境所要求的描述服务的方法，而这通常是 接口的关键部分。此外，对于组件类型来说，具有相同接口类型的几个实例是有 息义的.怛是，说某个类实现了一个UML接口的几个版本是没有意义的。例如， 并没有一种很轻松的方法来定义Splitter过滤器类型，该过滤器类型具有使用该 技术的相同“类型”的两个输出端口。最后，与类不同的是，UML接口没有属 性或子结构。

 

•选择5:接口作为类。将接口描述为由组件类型包含的类克服了以前的方案可表 达性的不足：现在，我们可以表示接口子结构，并指出某个组件类型具有相同类 型的几个接口。组件实例被建模为-个包含接口对象集合的对象。然而’当把接 口表示为类时.我们不仅会使图变得混乱，而且会使接口和组件在视觉上的区别 变得不明显。我们可以使用表示法的变体，其中接口为被包含的类，如图9.11 中选择5的下部。然而，指出交互点是违反直觉的.因为“包含”通常指出一个 类拥有其实例可以或不可以通过父类实例访问的其他类。

 

连接器。有3种用于表示连接器的合理的选择。需要再次说明的是，选择用哪种方法 來衣示连接器一方面是可表达性和语义之间的匹配问题，另一方面是复杂性问题。

 

 

• 选择1:连接器类型作为关联，连接器实例作为连接。在系统的构架框线图中，组件之间的线就是连接器。在UML中表示连接器的一种有吸引力的方法是将类之间表示为关联或对象之间表示为连接。从视觉上看，该方法是简单的，它提供 了组件和连接器之间的明显区别，并使用了UML类图中很熟悉的关系：关联。 此外，还可以标记关联，并且可以用箭头指出与该连接器相关的方向。遗憾的是， 连接器和关联具有不同的含义。构架描述中的系统是通过选择行为通过接口暴露的组件，并用协调其行为的连接器把这些组件连接起来构建的。系统的行为被定 义为组件集合的共同行为，这些组件之间的交互由组件之间的连接来定义和限制。

 

相反，在UML中，尽管关联或连接表示它所关联的元素之间的潜在交互， 但关联机制主要是-种描述两个元素之间概念关系的方法。此外，关联是UML元素之间的关系.因此，在UML模型中，它不能申.独存在。因此，不能孤立地 衣示连接器类型。相反，您必须采用命名规则或构造型，其含义是通过UML 对象限制语言中的描述来捕获的。更进一步说，该方法不允许指定连接器的接口。 

 

•选择2:连接器类型作为关联类。缺乏可表达性的一个解决方案是为关联添加一个表示迕接器类型的类。采用这种方法时，可以把连接器类型或连接器属性捕获为类或对象的属性。遗憾的是，该方法仍然没有提供任何显式地表示连接器接口 的方法。

 

•选择3:连接器类型作为类，连接器实例作为对象。在UML中，为连接器提供 第一类状态的一种方法是将连接器类型表示为类，将连接器实例表示为对象。使用类和对象，对于表示其角色来说，我们有与接口相同的4个选择：没有显式表 示，作为注解，作为由类实现的接口，作为由连接器类包含的子类。给定一个表 示接口的方案，可以把组件的接口和连接器的接口之间的连接表示为关联或依赖。

 

系统。除了表示单个的组件和连接器及其类型外，我们还需要封装组件和连接器的图 形：系统。有如下3种方式可供选择。

 

•选择1:系统作为UML子系统。将相关元素分组的主耍UML机制是包-事实上，UML定义了 一个标准的称为<<subsystem>>的包构造型，来对表示系统的一个逻 辑部分的UML榄型进行分组。子系统的选择适用于组件和连接器的任何映射， 尤其是对于类分组，它能够很好地发挥作用。使用子系统存在的一个问题是（已 在UML 1.4中定义)，尽管它们既是分类器又是包，但含义并不是完全消楚的。 一些人认为在开发过程的某些阶段，我们应该能够把子系统看作原子的、像类一 样的实体，而后能够根据更详细的子结构对其进行求精-能够做到这一点将使得 子系统构件更适于建立构架组件模型。

 

•选择2:系统作为被包含的对象。可以使用对象包含来表示系统。组件被表示为 被包含类的实例，使用上面概述的一个选择为连接器建模。对象提供了一个强大 的封装边界，并且表达了这样一个概念：该类的每个实例都有相关的“子结构”。 然而，该方法也存在问题，最严重的问题就是在被包含的类之间，用于对连接器进行建模的关联并不由该类所界定。也就是说，一对类并不仅在特定系统的上 下文中通过一个建模为关联的特定连接器交互。由此，对于在模型中的任何其他 地方使用的类的实例来说，两个被包含的类通过关联交互是有效的。

 

•选择3:作为协作的系统。在UML中，我们使用协作来描述通过链接所连接的 通信对象集合。如果我们把组件表示为对象，就可以使用协作来表示系统。协作 定义了对于给定目的有意义的一组参与人员和关系，在这种情况下，目的就是描 述系统的运行时结构。参与人员定义了对象在交互时所扮演或遵从的分类器角 色。同样，关系定义了链接必须遵守的关联角色。

 

可以在规范级或实例级使用协作图来表示协作。规范级的协作图展示了在协 作中定义.以描述系统子结构的模式安排的角色。实例级的协作图展示了在规范 级遵从角色，并通过交互来实现目的的对象和链接。因此.在实例级表示的协作 最适用于表示系统的运行时结构。

 

图9.12对该方法进行了说明。Filter构架类型与以前的表示方法•样。过滤器和管道 的实例被表示为对应的分类器角色.例如，/Splitter指出Splitter角色——和关联角色。遵 从这些角色的对象和链接在实例级展示在协作图中。由带下划线的名字表示。

 

尽管这是一个描述运行时结构很自然的方法，但却没有办法明确地表示系统级的属 性。还有一个语义失配的问题：协作描述了对象之间有代表性的交互，并提供了部分描述， 而构架配置的含义是捕获一个完整的描述。

                                    Figure 9.12. Systems as collaborations

 

 

9.6.3分配视图

 

在UML中，部署图是由通信关联所连接结点的图形。图9.13提供了一个例子。结点 可以包含组件实例。这说明组件“居住”或“运行”在结点上。组件可以包含对象，这说 明对象是组件的一部分。组件通过用虚线表示的依赖关系与其他组件相连（可能是通过接 口）。这说明一个组件使用另一个组件的服务：如果需要的话，可以使用构造型来指出准 确的依赖关系。还可以通过使用带有构造型<<supports>>的虚线箭头，用部署类型图来展 示哪些组件可以运行在哪些点上。

 

结点是表示处理资源的运行时物理对象，一般至少有一个存储器，通常还具有处理能 力。结点包括计算设备以及人或机械的处埋资源。结点可以表示实例的类型。运行时计算 实例（对象和组件）可以驻留在结点实例上。

 

结点可以通过关联与其他结点相连。关联指出了结点之间的通信路径。关联可以有-个构造型来指出通信路径的本质（例如，通道或网络的种类）。

 

结点符号中的符号嵌套表示结点类和组成类之间的组合关联，或结点对象和组成对象 之间的组合链接。

                                        Figure 9.13. A deployment view in UML

 

 

9.7小 结

 

如果谁也不理解构架是什么或不知道如何使用它，那么，这个构架是没有价值的。在 创建构架的过程中，对构架进行编档是最重要的一步，因为对构架进行编档后，设计师就不用再回答许多关于构架的问题.而且，现在和以后的涉众可以通过构架文档来捕获构架， 必须了解构架的涉众以及他们将如何使用文档。把对构架进行编档看成是对相关视图 的集合进行编档.然后用跨视图信息进行补充。让涉众来帮助选择相关视图。

 

无论是采用形式化的表示法还是UML，框线图都仅提供了整个构架的一小部分信息. 需耍提供解释在主要表示中展示的元素和关系的支持文档.以对框线阁进行补充。接口和 行为是构架阁的重要组成部分。

本章提供了对软件构架进行编档的一个说明性组织。您可能会问为什么在本书的构架 案例分析中.我们没有严格进循这一组织。编写任何种类的技术文档（尤其是软件构架文 档）的一个基本原理是，要使文档的读者从文档中获得最大收获。在这里.读者需要的是 对系统、其动机以及系统如何满足其质量目标的概述——读者并不会分析它或构建它。因 此，与我们对系统构造或分析所提供的建议相比，我们所提供的描述不太正式也不太详细。 在这种思想的指导下，我们使用主要表示（cartoon)来传达一般的信总：然而，我们提供 的并不是一个耍填充细节的正式的目录元素，而是-个叙述性描述。

 

9.8可进一步参阅的文献

 

本章的大多数材料都改编[Clements 03]。如欲获知有关构架编档的更全面的信息， 读者可以参阅[Clements 03],读者还可以参考[IEEE 00],以了解构架文档在团体范围内的 标准，这一标准与本章讲述的内容一致，但使用的术语稍有不同。

 

最后，还有很多关于UML的很好的参考资料。然而，您仍然可以把第一本权威性的 UML书籍[Rumbaugh 99]作为非常有帮助的综合的介绍性书籍阅读。对象管理小组目前正 在编写一本关于UML的书，目的是为系统软件构架的表示提供更好的支持。可以访问 http:// www.omg.org/uml/来.获知本工作的进展情况。

 

9.9讨论题

 

(I)本章的哪些视阁与您iE在开发的系统有关？您把哪些视图编成了文档？为什么存 在差别？

 

(2)假定您刚加入某个项目的开发。列出熟悉这个工作职位所滞耍阅读的•系列文档。 

(3)您简要用什么文档进行性能分析？