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的右半部分)。