软件构架文档
通过采用许多不同的构架视图描述系统的各个方面,软件构架文档从构架的角度对整个系统进行综合概述。
角色: 构架设计师
模板:
示例:
详细信息:

 
活动的输入: 活动的输出:

目的 返回页首

软件构架文档提供软件系统构架的综合概述。它用作构架设计师和项目团队的其他成员之间的交流媒介,讨论已针对项目构架做出的重要决定。

提要 返回页首

(链接到新窗口中的 HTML 模板

1.       简介         
    1.1     目的     
    1.2     范围     
    1.3     定义、首字母缩写词和缩略语     
    1.4     参考资料     
    1.5     概述     
2.       构架表示方式
3.       构架目标和约束   
4.       用例视图
    4.1     用例实现     
5.       逻辑视图
    5.1     概述     
    5.2     在构架方面具有重要意义的设计包     
6.       进程视图
7.       部署视图
8.       实施视图
    8.1     概述     
    8.2          
9.       数据视图(可选)       
10.            大小和性能               
11.            质量

时机 返回页首

软件构架的表示方式和目标通常在首次迭代之前必须定义,然后在整个项目过程中保留下来。这些构架表示方式指南记录在软件构架文档的初始版本中。

软件构架文档主要在精化阶段开发,原因是此阶段的目的之一是建立一个坚实的构架基础。

在此文档的所有视图中,可能要优先考虑用例视图。原因是用例促使开发,并且是迭代计划的一个核心输入。对于并行和分布程度较高的系统,也可能较早考虑进程视图和部署视图,原因是这两个视图可能会对整个系统产生重大影响。

职责 返回页首

构架设计师负责编写软件构架文档,此文档记录多个构架视图中最为重要的设计决策。

构架设计师要为各构架视图确立整体结构:视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此,与其他角色相比,构架设计师的视图属于宽度视图,而不是深度视图。

构架工程师还负责在整个开发流程中维持系统的构架完整性,具体方式如下:

  • 认可对在构架方面很重要的元素(如主要接口)所做的更改,软件构架文档对这些元素进行了说明。
  • 参与“变更控制委员会”决策,以解决那些影响软件构架的问题。

定制 返回页首

您应该调整软件构架文档的概要,以适合软件的特性:

  • 某些构架视图可能是无关的:
    • 单 CPU 系统不需要“部署视图”
    • 如果系统仅采用单控制线程,则不需要“进程视图”
    • 除非对象永久性是系统的重要方面,并且永久性机制要求永久性对象和非永久性对象之间存在映射,否则不需要“数据视图”。
  • 软件的某些特定方面可能要求有自己的章节,例如与数据管理或可用性问题相关的方面。
  • 您可能需要其他附录来解释某些方面(如某些重要选择的基本原理以及已被排除的解决方案),或定义首字母缩写词或缩略语,或介绍一般设计原理。
  • 章节的顺序可能会变化,这取决于系统涉众以及他们的关注点与兴趣。

各构架视图的优缺点如下:

用例视图

此视图是必需的。

逻辑视图

此视图是必需的。

进程视图

此视图为可选视图。仅当系统具有多个控制线程并且各个独立线程相互作用或相互依赖时,才使用此视图。

部署视图

此视图为可选视图。仅当系统分布在多个节点上时,才使用此视图。即使是这样,也仅当分布会影响构架时才使用部署视图。例如,如果有单个服务器和许多客户机,那么只有在将服务器和客户机的职责描绘成节点类时才需要使用部署视图;如果客户机节点具有相同的功能,则无须一一显示各客户机节点。

实施视图

此视图为可选视图。仅当实施并非严格受设计驱动时(即设计模型与实施模型中各相应包之间存在不同的职责分布时),才使用此视图。如果设计模型与实施模型的打包操作完全相同,则可以省略此视图。

数据视图

此视图为可选视图。仅当永久性是系统的一个重要方面,而且永久性机制不会自动将设计模型转换为数据模型时,才使用此视图。

 

© 1987 - 2001 Rational Software Corporation。版权所有。

分栏显示 Rational Unified Process

Rational Unified Process