主题

引用 到页首

引用部分提出的外部文档提供对于理解系统体系结构很重要的背景信息。如果有大量的引用,请将该部分组织为几小部分:

  1. 外部文档
  2. 内部文档
  3. 政府文档
  4. 非政府文档
  5. 其它

体系结构目标和约束 到页首

形成体系结构时将考虑以下各项:

  • 功能需求(包括在用例模型中)和
  • 非功能需求(包括在补充规范中)

但是,改变体系结构形式的影响因素不仅仅是这些:将会有软件操作环境所施加的约束;重用现有资产的需要所施加的约束;强制实施各种标准所施加的约束;与现有系统兼容的需要所施加的约束等等。也可能有一组预先存在的体系结构准则和策略,它们将指导开发,并需要针对该项目精化和落实。软件体系结构文档的这一部分用于描述这些目标和约束,以及由此生成的任何体系结构决策(它们与需求不同,在其它地方都无法生成)。

创建本文档时,一项重要的输入就是指定实施环境。应指定的事项的示例有目标平台(硬件、操作系统)、视窗系统、开发工具(语言、GUI 构建器)、数据库管理系统和组件库。指定允许和不允许使用哪些用户接口技术也是很有价值的。许多系统选择不使用某些表现技术(JavaScript、Applets、Frames、XML 等),以使更多客户机系统能够使用该应用程序,或使该应用程序更易于开发。此处的这些决策是包括在软件体系结构文档

实施这些决策是通过形成一组体系结构评估标准来实现的,这些标准将用作迭代评估的一部分。

评估标准也从变更用例得出,后者记录将来可能对以下各项作出的变更:

  • 系统的功能和属性
  • 使用系统的方式
  • 系统的操作环境和支持环境

变更用例阐明了使用如下主观短语描述的系统属性:“易于扩展”、“易于移植”、“易于维护”、“适应变更”和“快捷开发”。 变更用例专注于重要的事项,而可能不只是可能的事项。

变更用例尝试预测变更:此类预测最后很少会真正实现。

系统的属性是由用户、负责人、供应商、开发人员和其他涉众确定的。变更可能有许多来源,例如:

  • 业务驱动因素:新的和修改过的业务流程和目标
  • 技术驱动因素:改编系统以适应新的平台,与新的组件集成
  • 普通用户概要信息的变更
  • 与其它系统集成的需要的变更
  • 由于从外部系统迁移功能而产生的范围变更

用例视图 到页首

用例视图表现了工件:用例模型的其中一部分,简介具有重要体系结构意义的系统用例。它描述了代表某一重要的中心功能的一组场景和/或用例。它还描述了一组具有实际体系结构覆盖(用到许多体系结构元素)或者强调或说明特定、微妙的体系结构点的场景和/或用例。

如果模型较大,它通常将组织为几个包;为了易于理解,用例视图应类似地组织为几个包(如果它们被打包封装)。对于每个重要的用例,都在一个子节中包括以下信息:

  1. 用例的名称。
  2. 用例的简短描述。
  3. 用例事件流的有效描述。这可以是整个事件流描述,也可以是该描述中几个描述用例重要流程或场景的子节。
  4. 涉及用例的关系的有效描述,例如包含关系、扩展关系或通信关联。
  5. 枚举与用例相关的重要用例图。
  6. 对用例的特殊需求的有效描述。这可以是整个特殊需求描述,也可以是该描述中几个描述重要需求的子节。
  7. 重要的用户界面图片,阐明用例。
  8. 这些用例的实现应在逻辑视图中可以找到。

逻辑视图 到页首

逻辑视图是工件:设计模型的一部分,表现具有重要体系结构意义的设计元素。它描述最重要的类、它们的包和子系统组织以及将这些包和子系统组织为层。 它还描述最重要的用例实现,例如,体系结构的动态方面。

复杂的系统可能需要许多章节来描述逻辑视图:

  1. 概述

    这一子节根据设计模型的包层次结构和层来描述设计模型的整体分解结构。如果系统的包有好几级,您应先描述顶级的重要包。包括显示重要顶级包以及它们互相依赖性和分层的任何图。然后表现其中任何重要的包,依此类推,直到层次结构底部的重要包。

  2. 具有重要体系结构意义的设计包

    对于每个重要的包,都在一个子节中包括以下信息

    1. 其名称。
    2. 简短描述。
    3. 一个图,具有该包内包含的所有重要类和包。为了更好地理解,此图可以在必要时显示其它包的一些类。
    4. 对于包中每个重要的类,请包括其名称、简短描述,以及(可选地)对其一些主要职责、操作和属性的描述。必要时还描述其重要关系,以理解所包括的图。
  3. 用例实现

    此节通过给出一些选定的用例(或场景)实现来阐述软件如何工作,并说明各个设计模型元素对其功能的作用。选择此处给出的这些实现,是因为它们代表了最终系统的一些重要的、中心功能;或是因为它们的体系结构覆盖(它们实践了许多体系结构元素),或强调或说明特定的、微妙的体系结构点。这些实现的相应用例和场景应在用例视图中可以找到。

    对于每个重要的用例实现,都在一个子节中包括以下信息

    1. 所实现用例的名称。
    2. 所实现用例的简短描述。
    3. 用例实现的事件流 - 设计的有效描述。这可以是整个事件流 - 设计描述,也可以是该描述中几个描述实现该用例重要流程或场景的子节。
    4. 枚举与用例实现相关的重要交互或类图。
    5. 对用例实现的推导需求的有效描述。这可以是整个推导需求描述,也可以是该描述中几个描述重要需求的子节。

具有重要体系结构意义的设计元素

为了协助确定什么是具有重要体系结构意义的,这里提出了一些检验元素是否合格及其特征的示例:

  • 包括了问题领域主要抽象内容的模型元素,例如:
    • 空中交通控制系统中的飞行计划。
    • 薪资系统中的雇员。
    • 电话系统中的订户。

    不一定包括它们的子类型,例如,区分 ICAO 标准飞行计划美国国内飞行计划是不重要的;它们都是飞行计划,并共享大量的属性和操作。

    区分具有数据线路或具有语音线路的订户无关紧要,只要呼叫处理工作方式大致相同即可。

  • 由许多其它模型元素使用的模型元素。
  • 包括了系统主要机制(服务)的模型元素
  • 设计机制
    • 持续机制(资料库、数据库、内存管理)。
    • 通信机制(RPC、广播、代理服务)。
    • 错误处理或恢复机制。
    • 显示机制和其它公共界面(窗口显示、数据捕获、信号调节等)。
    • 参数化机制。

总的来说,任何机制都可能要在许多不同的包中使用(相对于完全在包内使用),以及最好在整个系统中单一实施,或至少有一个接口隐藏几个替代的实施。

  • 参与系统与诸如以下各项的主要对接的模型元素:
    • 操作系统。
    • 成品产品(窗口显示系统、RDBMS、地理信息系统)。
    • 实施或支持体系结构模式(例如分解模型元素的模式,包括模型视图控制器模式或代理模式)的类。
  • 本地可见、但可能对系统整体性能有某种重大影响的模型元素,例如:
    • 用以高速扫描传感器的轮询机制。
    • 用于故障诊断的跟踪机制。
    • 高可用性系统的检查点设置机制(检查点和重新启动)。
    • 启动顺序。
    • 在线更新代码。
    • 一种类,它包括了一种新颖而具有技术风险的算法或在安全性方面很关键的某种算法,例如计算辐射程度、在拥挤的领空中避免飞机相撞的条件、密码加密。

关于什么具有重要体系结构意义的标准将在项目的早期迭代中发展,此时您发现了技术难点并开始更好地理解系统。但是,通常您应至多将模型元素的 10% 标记为“具有重要体系结构意义”。否则您会有削弱体系结构概念以及“体系结构就是一切”的风险。

当您定义具有重要体系结构意义的模型元素并将其包括在逻辑视图中时,还应考虑以下方面

  • 确定公用和重用的可能性。哪些类可以是某个公共类的子类或同一参数化类的实例?
  • 确定参数化的可能性。通过使用静态参数和运行时参数(例如表格驱动的行为或启动时装入的资源数据),可使设计的哪一部分重用性更好或更灵活?
  • 确定使用成品产品的可能性。

进程视图 到页首

进程视图描述系统的进程结构。由于进程结构有重大的体系结构影响,故应表现所有进程。在进程内,只需表现具有重要体系结构意义的轻量级线程。进程视图描述系统执行中涉及的任务(进程和线程),它们的交互和配置,以及将对象和类分配给任务。

对于每个进程网络,都在一个子节中包括以下信息:

  1. 其名称。
  2. 涉及的进程。
  3. 进程之间的交互(形式为通信图),其中的对象是包括其自身控制线程的实际进程。对于每个进程,简短描述其行为、生命期和通信特征。

部署视图 到页首

此节描述部署和运行软件所采用的一个或多个实际网络(硬件)配置。它还描述将任务(从进程视图)分配给实际节点。对于每个实际网络配置,都在一个子节中包括以下信息:

  1. 其名称。
  2. 部署图,举例说明配置以及将进程映射到每个处理器。
  3. 如果有许多可能的实际配置,则只描述一个典型的实际配置,然后说明在定义其它配置时要遵循的一般映射规则。在多数情况下,您还应包括对执行软件测试和仿真的网络配置的描述。

此视图是从工件:部署模型生成的。

实施视图 到页首

此节描述在实施模型中将软件分解为多个层和实施子系统。它还概述了将设计元素(从逻辑视图)分配到实施。它包含两个子节:

  1. 概述

    此子节命名和定义各个层及其内容、控制给定层所包含内容的规则以及层的边界。包括一个显示层之间关系的组件图。

  2. 对于每一层,都在一个子节中包括以下信息:

    1. 其名称。
    2. 显示实施子系统及其重要依赖性的组件图。
    3. 该层与逻辑视图或进程视图中元素关系的适当概括。
    4. 枚举该层内的实施子系统。对每个实施子系统:
      • 给出其名称、缩写或昵称、简短描述及其存在的理由;
      • 适当地指出实施子系统与逻辑视图或进程视图中元素之间的关系。在许多情况下,实施子系统将实施逻辑视图中的一个或多个设计子系统。
      • 如果实施子系统包含具有重要体系结构意义的实施子系统和/或
        目录,则考虑在子节层次结构中反映这种情况。
      • 如果实施子系统不与实施目录一对一映射,则包括一项说明,即如何根据实施目录和/或文件定义实施子系统。

数据视图 到页首

此视图描述数据模型中具有重要体系结构意义的永久元素。它根据用于向系统提供持久性的表、视图、索引、触发器和存储过程来描述数据模型的概述及其组织。它还描述永久类(从逻辑视图)映射到数据库的数据结构

它通常包括:

  • 从关键永久设计类的映射,尤其是在映射不可忽视时。
  • 已在数据库中实施的、具有重要体系结构意义的系统部件,采用存储过程和触发器的形式。
  • 其它视图中影响数据的重要决策,例如选择事务策略、分发、并行、容错。 例如,选择使用基于数据库的事务管理(依靠数据库提交或放弃事务),则要求体系结构中使用的错误处理机制包括一个策略,用于通过在应用程序中刷新内存中高速缓存的持久对象的状态而从失败事务中恢复。

您应该表现具有重要体系结构意义的数据模型元素,描述它们的职责,以及一些非常重要的关系和行为(触发器、存储过程等)。

规模和性能 到页首

此节描述在体系结构方面具有确定性的系统容量和响应性特征。提供的信息包括:

  • 系统将必须处理的主要元素的数量,例如空中交通控制系统中并发班机的数量、电信交换机中并发电话呼救的数目、航班预订系统中并发在线用户的数量等。
  • 系统的主要性能指标,如主要事件的平均响应时间;平均吞吐率、最大吞吐率和最小吞吐率等。
  • 可执行文件的占用量(根据磁盘和内存),如果系统是必须在极为限制的约束下存活的嵌入式系统,该占用量则是必需的。

这些质量中有多数都是作为需求包括在内的;此处表现它们是因为它们以多种方式形成体系结构并保证了特殊焦点。针对每个需求,讨论体系结构如何支持该需求。

质量 到页首

在此节中,列出系统中形成体系结构的主要质量维度。提供的信息可能包括:

  • 操作性能需求,例如故障平均间隔时间(MTBF)。
  • 质量目标,例如“无计划内停工作间”。
  • 可扩展性目标,例如“系统运行时,软件将可以升级”。
  • 可移植性目标,例如硬件平台、操作系统、语言。

针对每一维,讨论组件如何支持该需求。您可以按照不同视图或按质量组织该节。当系统中的特定特征(例如安全、安全性或隐私性)很重要时,应在此节中仔细描绘对它们的体系结构支持。



Rational Unified Process   2003.06.15