4.3视图和模板
正如我们在第 2 章中已经看到的，在软件架构描述的上下文中，“架构视图”这一术语经常被使用。架构视图是从特定视角对系统的表示。它强调被观察对象的重要特征，并创建高层抽象，掩盖对该特定观点不重要的细节。在这个阶段，我们想为您提供关于如何有意义地描述架构视图的概述和初步指南。
本章中提到的视图（上下文视图、构建块视图等）在第 2 章中已经涵盖。我们通常将它们简单地称为“视图”。此外，我们假设您已经熟悉诸如 UML 和 ER 之类的缩写。
4.3.1 iSAQB定义的成熟视图
软件架构文献提供了一系列描述软件架构的不同方法，其中许多都使用了视图的概念。
图4-3 iSAQB定义的验证视图
在 iSAQB 课程框架内，涉及到四个关键视图。这些被认为是经过验证的，并且具有特别的实际相关性。它们基于 [ARC42] 模板中的实用软件架构描述，而该模板又源自软件架构的“4 + 1”模型 [Kru95]。这四个视图及其之间的相互作用如图 4 - 3 所示。这些视图是:
上下文视图(或者背景图) 一个（最好是）带有 UML 组件的图表，将设计中的系统作为黑盒，所有外部系统和用户作为参与者或 UML 组件。相应地，使用 UML 节点符号表示分布或部署上下文。
构建块视图 软件系统的功能和（可能的）技术“软件构建块”的 UML 组件图或顶级类图以及它们之间的相互关系
运行时视图 用于说明主要（或关键）序列的序列图、活动图或类似图表，特别是构成（或位于）软件系统内的构建块之间的那些
部署视图(或基础设施) 系统软件工件到计算机节点、网络等的部署 - 换句话说，将软件映射到物理技术基础设施。
这四个视图通常为描述软件架构提供了足够的基础。然而，其他专门的视图可以有用地补充这些 - 例如，如果它们能让您更好地向利益相关者解释事情。专门视图的一些示例有:
• 数据视图
对软件系统的数据库结构的详细描述 - 例如通过实体关系（ER）模型
• “大局”视图
用于与管理层沟通（即预算批准）的高级系统架构视图
• 掩码（或序列）视图
屏幕掩码、网站屏幕序列图等
对于每个额外的视图，您需要考虑创建和维护所涉及的工作。总的文档工作相应地会更大。可能还需要对任何额外的图表符号进行详细解释。 所有类型的视图都可以多次存在，以详细阐述软件系统的部分或子区域。它们的使用必须根据利益相关者、系统的关键性以及系统特定部分的复杂性来确定。
4.3.2视图描述中的 UML 图表作为标记工具
统一建模语言（UML，参见 [UML-1a]、[UML-1b]、[UML-1c]、[RQ+12]、[Oes09]）标记可用于在视图描述中呈现图表。这很有用，因为自 1997 年对象管理组（OMG）对其进行标准化以来，UML 标记在实践中得到了广泛应用。因此，您可以期望您的目标群体对基本的 UML 元素有较高的熟悉程度（但在过度使用 UML 之前，您仍应始终对此进行检查）。作为简要回顾，本节涵盖了软件架构的一些重要 UML 图表（如果您已经熟悉 UML，则可以跳过此部分）。
UML 2中的图表类型
2010 年发布了 2.3 版（[UML-1b]、[UML-1c]），总共包含 14 种图表类型（7 种结构图和 7 种行为图）。它们列在下表中。我们认为对软件架构的视图描述特别重要的 UML 图表以粗体显示。
表4-1UML 2图类型
下面的部分详细介绍了两个UML结构图和两个UML行为图。
UML类图
UML 类图展示了类的静态结构以及类之间的关系。典型的关系有关联、聚合、特化和泛化（见图 4 - 4）。关系可以有不同的基数 - 例如，您会发现 1:1、1:n 和 m:n 的关系。
图4-4UML类图与不同类型的关系
UML组件图
UML 组件图提供了构成软件系统的构建块的概述，并使用 UML 组件对其进行描述。UML 组件具有定义明确的接口，通过这些接口它们与其他系统组件相连。图 4 - 5 显示了通过输入和输出接口相连的两个 UML 组件。
图4-5UML组件图
UML活动图
UML 活动图展示了系统元素（例如：类、组件或用例）内的可能序列。这些图可用于提供算法、数据流和控制流的详细描述。图 4 - 6 显示了一个具有起点、终点、子步骤和分支的序列。
图4-6UML活动图
UML序列图
UML 序列图展示了软件系统中构建块实例之间的交互（消息交换）。为防止单个序列图变得过大，可以将它们嵌套。在图 4 - 7 中，两个构建块实例交换消息，并通过嵌套图处理了另一个构建块实例。
图4-7UML序列图
结论:UML用于视图描述中的图
UML 是一种广泛使用的、广泛的工具，具有许多不同类型的图表用于描述软件系统。然而，您不应将 UML 视为始终有效的通用解决方案。当有助于您的目标群体更好地理解事物时，不要犹豫补充图表。其他类型的图表，例如非正式的“框和箭头”，通常用于描述软件架构。在这种非标准图表中使用的符号的解释尤为重要。
UML 对于某些利益相关者群体也可能不合适。例如，其他图表对于在管理级别传达架构（“大局”）可能有用。例如，PowerPoint 幻灯片可能会与高级网络符号的 Visio 图表和非正式的“框和箭头”图表结合使用。（高级）流程工作流的事件驱动流程链（EPC）图表等在这个级别也可能有用。
相应地，实体关系图通常更适合描述数据库，而带有网络符号的图表在描述管理和操作方面时更好。
4.3.3 视图描述:高级结构和示例
本节提供了视图描述结构的高级概述。在 [ARC42] 中提供了软件架构描述（包括视图描述）的模板。然而，在其他一系列方法中也可以找到这样的模板 - 例如，在 RM-ODP [RM-ODP] 中。在 4.3.3.2 节中提供了一个简短的示例。
4.3.3.1 高级结构:模板型视图描述
在描述软件架构，特别是架构视图时，使用标准结构或布局是有意义的。这为读者提供了很高的识别价值。将描述与相应的目标群体相匹配也很重要。询问您的利益相关者，对于他们自己的特定任务，需要描述哪些方面。
在描述架构视图时，经验法则是尽可能少地使用形式主义，但要使用必要的量。一个项目不应该仅仅因为只有在处理了每个小细节时架构图才被接受而大幅偏离计划。作为架构师，您应该抵制教条主义行事的诱惑。
对于文档范围的一个有用的初始框架是风险级别或要描述的构建块的复杂性。风险越高，构建块文档就必须越全面。如果风险级别可控，可以省略一些细节。 用于描述架构视图的示例部分可能如下:
简要描述 视图的简要描述提供了一个基于短文本的“在这个特定情况下涉及的内容”的概述。
图表 图表提供了视图的图形表示。
元素目录
元素及其属性
关系及其属性
元素的接口以及元素之间的接口
元素行为
如果涵盖所有图表的元素目录过于庞大，可以为视图的图表使用多个本地元素目录。
可变性
此部分使用基于文本的描述来解决视图内可变元素或关系的问题。此处包括需求、架构、设计、涉及的外部系统或基础设施方面的所有可变性。 根据视图的类型，还可以在此处解释配置、安装和操作参数。还可以在此提供所有要遵守的技术标准的列表。 在可变性中，区分可更改性和灵活性可能很有用。可更改性解决了对当前系统进行修改的可预见能力（例如，更改 JDBC 数据库驱动程序），而灵活性解决了扩展系统的能力（例如，通过提供允许对同一底层应用程序进行不同类型 GUI 访问的扩展阶段）。
背景信息
基于文本的背景信息在理解视图的特定结构方面很重要，可用于证明特定的设计决策是合理的。典型的背景信息包括:
选择的结构或所选替代方案的理由
特定内容相关系统方面的分析或初步评估的结果
关于系统、使用的构建块或系统环境所做的假设
对相关或连接的视图的引用
各种源信息或示例代码
4.3.3.2 示例:一个构建块视图描述的摘录
为了说明，下面提供了CoCoME示例的构建块视图的摘录。
简要描述
此构建块视图的这一部分为超市收银操作的 CoCoME 提供了概述。图 4 - 8 使用 UML 组合结构图展示了 CoCoME 的最高构建块级别，其中软件构建块库存（Inventory）和收银台线（CashDeskLine）均由 UML 组件表示。 图
图4-8 CoCoME的构建块视图，最顶层 CoCoME构建块视图(TradingSystem)的元素目录
表4-2 CoCoME构建块视图的元素目录
可变性
收银系统应能够针对不同的安装进行配置。届时将适用特定的合理性。
背景信息
• 分析
o 原型表明，CoCoME 中的条码扫描仪可能是一个错误源。因此，在开发过程中应进行适当的测试，并在最终系统中实施措施，以确保在这方面提高容错能力。
o 关于 CoCoME 软件是否真的应可配置到本地级别，仍需要与负责的利益相关者进行澄清。在适当的情况下，CoCoME 测试用户应实施评估原型的措施。
• 假设
o 预计其他 CoCoME 构建块不会出现特定的错误源、安全风险或性能瓶颈。
• 对相关视图的引用
o 细化的 CoCoME 构建块视图
o 运行时视图和部署/基础设施视图 基于此高级结构和视图描述的示例摘录，我们现在将呈现
4.3.1 节中列出的四个视图，从上下文视图开始。
4.3.4 上下文视图(或者上下文图)
上下文视图的内容
上下文视图（也称为上下文图）是基于文本/图形的需求描述与后续架构之间的重要链接。它描述了系统的环境以及与该环境的关系和连接，从而为所有相关方提供了系统的入口点和地图。
在上下文视图描述中，重点因此放在与相邻系统的接口上。对于这些接口的实现的功能、技术和组织方面的更详细描述，应参考相应的接口概念。
在上下文视图中，以下元素很重要:
• 外部参与者(相邻系统和用户)
• 待开发的系统
• 与外部参与者(所有相邻系统和用户)的所有接口包括:
o 接口的类型(例如，在线、批处理、USB或文件)、通过此接口传递的数据或资源，以及使用的任何服务或功能
o 使用的通信协议
o 使用的通信模式(例如，同步、异步)
在此基础上，上下文视图划定了所讨论的软件系统的范围。
上下文视图利益相关者
与相邻系统的接口是项目中最关键的方面之一，因此上下文视图相应地很重要。上下文视图的利益相关者通常包括:
• 项目管理
• 需求分析师(作为“输入提供者”)
• 系统分析师(作为“输入提供者”)
• 技术或领域专家(作为“输入提供者”)
• 设计和开发
• 测试人员
• (可能)下游管理和运营
• 控制(将开发成本分配到成本中心)
• 对于“产品”而言，可能还有销售和市场营销
• <你给它命名> -(即，任何其他名称，取决于组织和项目)
上下文视图中的典型描述元素
上下文视图的描述主要使用
• 上下文图
• 具有其接口的相邻系统列表
上下文视图通常既是功能性的又是技术性的。因此，软件系统描述可以在功能上与其他软件系统划定界限，同时在技术上集成到现有或未来的基础设施中。
上下文视图的功能元素可以是静态的或动态的。动态视图往往更适合测试和操作，而静态视图更适合架构、设计和开发。在以下部分中，我们将集中于静态视图。
在上下文视图中指定接口的所有相关方面是至关重要的。例如，通过接口传递的内容、传递的格式、使用的介质等等 - 尽管一些流行的图表类型（如 UML 用例图）仅说明了接口的特定方面。
上下文视图图是使用许多不同的符号创建的。如果使用 UML 图表，那么 UML 组件图和 UML 组合结构图对于此视图的功能导向图特别有用。在这种情况下，将待描述的系统定位为具有定义明确的接口的“中心黑盒”是合适的。
对于技术导向的上下文视图，您还可以使用 UML 节点补充 UML 组件。UML 包符号有时也用于此目的。非 UML 网络符号（例如，Visio 使用的那些）经常被使用。PowerPoint“框和箭头”风格的其他不太正式的符号形式也经常用于上下文视图。需要注意的重要一点是，所使用的表示形式适合与您的主要利益相关者进行沟通。
上下文视图提供了构建块、运行时和部署视图的抽象图示，因此它们各自的符号和图表也可以用于补充上下文视图本身。
上下文视图通常包含以下元素:
表4-3Elements上下文视图
上下文视图中的图表示例
以下部分展示了来自 CoCoME 的示例上下文视图图表，其中一些使用了非 UML 描述方法。
首先，图 4 - 9 在一个仅由“符号和线条”组成的简单图表中展示了单个收银台的上下文。这里的核心元素是收银台 PC，它代表了与银行以及构成收银台的各种硬件构建块的连接。这些包括用于识别待计费产品的条码扫描仪、用于信用卡/借记卡的读卡器、现金盒、打印机和显示器。所有这些硬件构建块都具有由收银台 PC 处理的接口。因此，此 PC 通过这些接口与其周围环境进行交互。
图4-9收银台的环境 图 4 - 10 展示了在商店环境中的收银台。在相应的 UML 图的左侧，我们看到一个名为 CashDeskLine 的 UML 组件，它包含商店中的所有收银台。这些收银台连接到一个 StoreServer，而 StoreServer 又被一个 StoreClient 访问。
图4-10The现金书桌在商店里
在图 4 - 11 中，商店在公司（企业）的环境中被展示。相应的 UML 图显示了几个作为 UML 组件的商店连接到公司服务器（UML 组件 EnterpriseServer），而公司服务器又被一个客户端（UML 组件 EnterpriseClient）访问。
图4-11The上下文的几个企业内的商店
4.3.5 构建块视图
构件视图的内容
构建块视图展示了软件系统的静态结构。在开发过程中，此视图详细说明了期望的结构，而一旦系统投入生产，它就必须反映其实际结构。此视图的目标是明确展示软件架构的静态结构及其构建块之间的关系。
正如在第 2 章中已经解释和说明的那样，“构建块”一词涵盖了最终代表源代码抽象的所有软件和实现工件。在最顶层，这些包括软件子系统或软件包。还应该注意的是，构建块本身可以由其他构建块组成。
如果每个构建块至少具有以下属性，那将是有帮助的:
• 名称
• 职责或目的
• 接口
• 对其实现的引用
还可以添加其他可选属性 - 例如，需求或未解决的问题。
构建块视图可以使用自上而下的方法来开发。在这种情况下，起点是上下文视图。如果必须集成现有系统，则自上而下的方法可能必须与对这些系统的自下而上的抽象相结合。面向服务架构中基本服务的抽象就是一个这样的例子。
构建块视图利益相关者
构建块视图主要涉及软件系统的设计和实现。其利益相关者是:
• 参与软件架构、设计、开发和测试的所有项目人员
• 质量保证（如果尚未直接分配到项目中）
• 构建块视图有助于项目管理制定工作和活动计划。
• 在软件开发项目完成后，构建块视图还能使生成的软件得到更高效的维护。
构建块视图符号的描述元素
构建块视图中的典型UML元素是组件和包符号。
UML 组件符号在构建块视图中是最便捷的描述元素，特别是在外部接口起重要作用的系统中。UML 组件的广泛使用的替代方案（或补充）是最顶层构建块级别的类，由 UML 类符号表示。在构建块视图的细化过程中（关于细化的更多信息，请参见 4.3.9 节），类的使用更为普遍。
构建块视图中使用 UML 组件的示例有 TradingSystem（交易系统）、Inventory（库存）和 CashDeskLine（收银台线）（见图 4 - 8）。
在图表中使用不同的符号类型时，往往少即是多。以 UML 为例，在许多情况下，以下元素足以表示整个软件系统及其环境：
表4-4Elements必须代表一个软件系统和它的环境
构建块视图图表示例
作为构建块视图图表的进一步示例，图 4 - 12 和 4 - 13 展示了图 4 - 8 中库存构建块的细化。
在图 4 - 12 中，以 UML 组件的形式展示了库存的 GUI 构建块 Inventory::GUI。它包含一个通过报告接口（ReportingIf）进行报告的 UML 组件，用于生成各种报告和统计数据。此外，还有 UML 组件 Store，通过 StoreIf 接口可以访问 StoreManager（例如，下达产品订单）。
图4-12构建块视图细化-库存的GUI
图 4 - 13 以细化的形式展示了库存的内部结构。除了已经提到的 GUI 构建块之外，它还包含 UML 组件 Application（应用程序）、Data（数据）和 Database（数据库）。UML 组件的各种接口（例如，ReportingIf 和 StoreQueryIf）还补充了重要的方法，如 OrderEntry（订单输入）和 ProductOrder（产品订单）。
图4-13构建块视图的细化——清单显示为白框
4.3.6 运行时视图
运行时视图的内容
运行时视图描述了软件系统元素在运行时的交互。在这里，影响系统启动、运行时配置和系统管理的系统操作的重要方面开始发挥作用。运行时视图通常不会描述整个软件系统，而是侧重于系统的重要元素和提供概述的示例。
注意：模型驱动的软件开发的全面使用是此规则的一个例外。如果您希望从包含运行时视图中的动态元素的 UML 图表生成代码，那么这些图表必须广泛且精确地描述您的软件系统架构。
运行时视图利益相关者
运行时视图有多个目标群体:
• 软件系统的操作员
• 系统架构师
• 参与软件设计、开发和测试的所有项目人员
质量保证也是此视图的利益相关者（如果尚未直接分配到项目中）。
运行时视图符号的典型描述元素
运行时视图主要描述构建块的动态交互。为此使用了各种形式的描述，它们都具有特定的优点。一些典型的例子有:
• UML活动、通信图和序列图
• 如果您的目标群体能很好地理解传统流程图，那么它对于运行时视图来说也可以是一种有用的符号。
• 在合理的情况下，小段的（伪）代码可能会有用。
• 以编号列表形式的非正式口头序列描述也可能有用。然而，这些必须易于理解且足够简短。您还需要确保相应序列的中心语义足够清晰，并且每个活动到相应执行构建块的分配是明确的。
• 业务流程模型和符号（BPMN）是在运行时视图中表示业务流程的另一种选择。
在某些情况下，静态模型是运行时视图的有用部分。例如，如果要描述对象的各个实例的运行时视图，可以使用 UML 对象图（或其他类型）来促进这一点。然而，在架构级别，这些通常不是必需的，因此以下部分的重点仅在于动态模型的元素。
运行时视图的图表示例
图 4 - 15 和 4 - 16 展示了来自 CoCoME 运行时视图的两个示例图表。第一个是一个序列图，描述了生成当前库存水平报告（库存报告）的过程。为了进行比较，第二个图表是一个通信图，描述了相同的过程。
序列图
图 4 - 14 提供了 UML 序列图中一些重要元素的概述。
序列图的图4-14Runtime观点:典型的元素 UML 序列图的重要元素在下面以表格形式列出。自 UML 2 发布以来，这些图表中可能的元素数量显著增加，包括循环、条件、对其他图表的引用和其他元素。为了简单和清晰起见，这里也适用尽可能少使用元素的规则。
表4-5 UML序列图的元素
图 4 - 15 展示了另一个序列图。它包含了此类图的典型元素 - 例如，方法调用和一个循环。
图4-15Runtime视图:样本序列图“库存水平报告”
此序列图的内容描述了库存水平报告的创建。这是一个典型的 CoCoME 用例，并描述了以下序列：
一个 StoreManager 可以使用 UML 组件 GUI::Reporting 来检查库存水平。输入是一个 storeId，然后必须选择“创建报告”操作。反应是对 UML 组件 Application::Reporting 的 getStockReport() 方法的调用。这进而访问数据组件 Data::Store 以在一个循环中创建适当的报告（循环被包含在一个事务 tr.begin...tr.commit 中）。作为结果，生成一个 ReportTO 对象并返回给 UML 组件 GUI::Reporting。最后，结果在 Store Manager GUI 中作为报告显示。
通信图
与 UML 序列图紧凑的从左到右的表格布局不同，UML 通信图中涉及的伙伴在很大程度上可以自由排列。这使得布局的构建更容易 - 例如，基于构建块视图中的构建块。然而，包含许多通信关系的大型图表很容易变得笨拙和令人困惑。
图 4 - 16 展示了与图 4 - 15 相同的序列，但这次是以 UML 通信图的形式。图表元素排列的更大自由度清晰可见。
图4-16Runtime观点:示例通信图“库存水平报告”
4.3.7 部署 /基础设施视图
部署视图的内容 部署视图 - 也称为基础设施视图 - 描述了软件系统运行的（技术）环境。它们有助于软件系统的操作和部署。
在此视图中，构建块视图中的特定 UML 组件被放置在部署视图的节点内。因此，这些描述包含系统软件或硬件构建块，如应用服务器、数据库管理系统、网络连接、服务器等等。 在此视图中，工件（即工作成果，如文档、文件、软件、可执行文件、.war、.ear、脚本、源代码、库）通常被分配给“它们的”执行节点（例如，计算机、服务器、设备、数据库/数据库系统/数据库管理系统、EJB 容器、容器、操作系统、工作流管理系统）。这种分配可以是 1:1 或 m:n 的方式 - 换句话说，多个工件可以被分配给多个节点。
部署视图的一个额外有用的功能是软件系统到“现实”的特定映射。例如，这可以以引用构建和部署脚本（或其描述）的形式进行。单独的文档部分可能非常合适（另见 4.5 节）。
部署视图利益相关者
部署视图关注“真实的软件运行环境”。其主要利益相关者是:
• 软件系统的操作员（一个特别重要的目标群体）
• 系统架构师和软件架构师
• 开发人员（以确保他们了解其软件将运行的环境和网络，以及软件将如何分布式运行）
部署视图符号的典型描述元素
此视图中的核心 UML 实体是 UML 部署图，其中节点可用于表示任何技术元素。通道（以关联的形式）用于互连节点。此外，UML 组件和包符号用于运行时元素（软件系统）。在这里，同样是少即是多。
在特殊情况下，用网络符号（如 Visio 中可用的那些）细化 UML 部署图可能会有用，以为特定目标群体（例如，网络管理员）提供更多信息。还有磁带驱动器、数据库系统、大型机、PC、服务器等的符号。然而，只有在确定利益相关者将从中受益时，这些符号才应作为 UML 图的补充使用。在纯 UML 环境中，如果特定目标群体熟悉这种符号形式，可以使用 UML 节点和组件的相应构造型来代替。
部署视图中的典型符号列在下表中:
表4-6Typical符号在部署视图
部署/基础设施视图的图表示例
我们将使用两个示例图来更详细地解释部署/基础设施视图。
图 4 - 17 首先展示了一个微型网络商店的“丰富的”、半正式的 UML 部署图。它由两个 UML 节点组成，代表可以作为客户端访问网络商店的 PC 和网络商店服务器。PC 是具有≥ 3GB 内存的标准 Windows PC。在其上安装了两个 Java 部署工件，ShopView.jar 和 ShopAPI.jar。运行时环境是 Java 运行时环境（JRE）1.8.x。
PC 通过未指定带宽的 TCP/IP 链路访问网络商店服务器 ShopServer。服务器运行 Sun/Oracle Solaris。它具有 8GB 内存和 1TB 硬盘容量。使用 IBM DB/2 数据库来管理商店数据。
图4-17Deployment /基础设施视图- Web商店部署图
第二个图表（图 4 - 18）是一个 UML 部署图，展示了 CoCoME 系统中的主要物理构建块的概述。
从左到右，我们看到 UML 节点 CashDeskPC。这个 UML 节点包含 UML 组件 CashDesk（收银台核心软件）和 CashDeskChannel。该通道提供与外围设备（如打印机、读卡器、条形码扫描仪和显示器）的通信。从技术上讲，这些设备通过 RS - 232 接口连接。与银行的接口/链接通过 Java 远程方法调用（RMI）实现。
在图的中心，我们看到 StoreServer 节点。它包含四个 UML 组件 Coordinator、extCommChannel、Application 和 Data，以及它们的 UML 子组件。一个 StoreServer 节点可以连接到任意数量的收银台 PC（CashDeskPC 节点）。这些连接的技术基础也是 Java RMI。
一个 StoreServer 节点可以有任意数量的 StoreClient 节点。它们也使用 Java RMI 连接。每个 StoreClient 节点上都运行着一个库存 GUI 构建块（显示为 UML 组件）。 在图的最右边，我们看到公司及其 EnterpriseServer 节点，任意数量的 StoreServer 节点可以通过 Java 数据库连接（JDBC）连接到该节点。EnterpriseServer 节点包含 UML 组件 Database、componentData 和 componentReporting。任意数量的 EnterpriseClient 节点通过 Java RMI 访问 EnterpriseServer 节点。EnterpriseClient 节点有一个用于库存报告的 GUI UML 组件。
图4-18Deployment /基础设施——完整的视图CoCoME部署图
4.3.8 架构视图的相互依赖关系
特定架构视图的设计通常会对其他视图产生影响。对一个视图的更改需要在其他视图中进行调整。因此，希望使用迭代开发过程，在每次更改后更新所有相关视图。出于以下原因，应记录特殊的相互依赖关系:
• 设计决策变得更易于理解。
• 更改的影响更容易识别。
• 系统组件之间的依赖关系更容易理解。
以下是架构视图之间存在的相互依赖关系:
• 将软件系统作为黑盒与其相邻系统进行交互的上下文视图。
• 构建块视图和运行时视图源自上下文视图，并且彼此之间存在关系（即，构建块在运行时进行交互）。
• 部署/基础设施视图也存在于（技术）上下文中。构建块视图的元素放置在部署/基础设施视图的技术节点和元素内。
4.3.9架构视图的分层细化
一般来说，架构级别代表了软件系统的“顶层”描述。它主要有两个目的：首先，这样的描述应该提供系统的整体印象，作为后续更详细的洞察和进一步细化的基础，其次，它应该提供系统的抽象（技术）总结，可在更高的组织或技术级别作为入门参考。
在第 2 章中已经对“黑盒”和“白盒”这两个术语进行了一般解释。我们将使用这些术语来解释架构视图的分层细化。
层次结构基本上从上下文视图开始，它将整个系统表示为黑盒（即最高级别）。如第 2 章所述，黑盒显示外部接口，并使用信息隐藏原则描述功能。因此，层次结构的最高级别可以明确分配给架构。
第一级细化将整个系统表示为白盒。如第 2 章所述，白盒显示构建块的内部结构、其依赖关系和操作方法。内部构建块反过来又是黑盒，随后会被进一步细化。
在这个阶段，向软件系统设计的过渡开始了，实际上是相当流畅的。架构可以（但不一定）进一步细化白盒描述。您应该足够详细地指定重要的子区域。图 4 - 19 显示了构建块视图中细化的示例层次结构。它从上下文视图开始，最初将构建块 System 细化为构建块 A 和 B（为简单起见，在这个第一次细化步骤的图中省略了与 AdjacentSystem1 和 AdjacentSystem2 的接口）。然后，构建块 A 和 B 被进一步细化为 C & D 和 E & F。
软件系统设计最迟在对模块或组件细化到特定的 OO 类时开始。当达到这个阶段时，架构和软件系统的设计与开发必须特别紧密地合作，以避免后续的“失败”。
图4-19构建块视图中构建块的层次结构和细化
需要注意的是，连续细化并不仅限于构建块视图。特别是运行时视图也可以相应地进行细化。在图 4 - 19 所示的示例中，构建块 A 已细化为构建块 C 和 D。例如，这可能需要一个新的运行时视图图，其中包括构建块 C 和 D 之间的通信。
黑盒描述
对于黑盒构建块的描述，遵循类似的模式在逻辑上总是有意义的。为此目的使用的典型信息总结在下表中：
表4-7lack框描述数据
图 4 - 20 提供了一个黑盒构建块图的示例摘录。这展示了一个 UML 组件 EmailManagement，例如，它可以用作 CoCoME 的扩展。该图显示了 UML 组件及其几个接口，如接收邮件、获取邮件、监控操作和发送邮件。EmailManagement 构建块在内部是如何实现的并未明确显示。
图4-20 UML组件“EmailManagement”的黑盒视图
白盒描述
当黑盒构建块被细化时，就会创建白盒视图。对于白盒，也建议使用定义好的模板，下面的表格详细说明了一个示例方法:
表4-8White框描述数据
例如，图 4 - 20 的白盒细化可以将其分解为 POP3、SMTP 和 SNMP 构建块，可能还有其他自行开发的构建块。
Last updated