4.2.3　以架构为中心的过程

Rational统一过程主要的一部分可以说是围绕建模进行的。模型是现实的简化，能够帮助我们理解并确定问题及其解决方法。对于那些整体把握不太容易的大型系统，模型应当尽量能够完整而一致地描述将要开发的系统，尽量和现实情况保持一致。当描述一个系统的一系列任务时，需要用一定的系统框架来进行描述。也就是和很多人认为的那样，所谓架构（即体系结构）就是当我们在去掉其中的任何部分时，就无法让人理解整个系统和解释它是如何工作的系统描述。

一个良好的架构能够清晰表达其目的，它应该具有关于架构的形成过程的具体描述，并且能够以一种被普遍接受的方式表达出来。对于一个以架构为中心的开发组织，需要对架构的以下3个方面进行关注。

• 架构的目的：开发组织应当理解架构的目的，明确它为什么如此重要，从中能够得到什么样的好处以及如何开发自己的架构。
• 架构的表示：开发组织应当确定一个统一的架构表示形式，这样能够使架构具体化，从而使开发组织可以系统地在同一架构下进行交流、评审和改进工作。
• 架构的过程：项目组织应当关注架构的具体形成过程，从而确定如何建立并验证一个能够满足项目需求的架构，并决定由谁来做这件事。

不同的参与者会关注架构的不同方面，因此在描述一个完整的架构时，应当是多维的，而不是平面的，这就是架构视图（Architecture View）。一个架构视图是从某一视角或某一点上看到的系统，并依此所做的概述（简要描述），描述中涵盖了系统的某一特定方面，省略了与此无关的实体。

在Rational统一过程中建议采用五种视图来描述架构，这5种视图分别是：

• 逻辑视图（Logical View）。在使用面向对象的方法时，逻辑视图是用来设计对象的模型。
• 过程视图（Process View）。过程视图是用来捕捉设计的并发和同步特性。
• 物理视图（Physical View）。物理视图是用来描述软件到硬件的映射，反映分布式的特性。
• 开发视图（Development View）。开发视图是用来描述在开发环境中软件的静态组织结构。
• 用例视图（Use Case View）。有时也被认为是场景（Scenarios），用来阐述其他视图是如何工作的。

我们可以轮流使用这5种视图观察系统的架构，并且展现出各个视图的目标，即视图所关注的问题、相应的架构设计的标记方式、描述和管理架构设计的工具。下面分别详细说明这5种视图。

1．逻辑视图（Logical View）

逻辑视图主要支持系统的功能性需求，即在为用户提供服务方面，系统应该提供的功能。逻辑视图是设计模型的抽象形式，将系统分解为一系列的关键抽象，这些关键抽象大多数来自于问题域，并采用抽象、封装和继承的方式，对外表现为对象或对象类的形式。我们可以使用Rational统一过程中的相关方法来表示逻辑架构，借助于类图和类模板的形式。类图用来显示一个类的集合和它们的逻辑关系：关联、使用、组合、继承等。相似的类可以划分成类集合的形式。类模板关注于单个类，它们强调主要的类操作，并且识别关键的对象特征。如果需要定义对象的内部行为，则需要使用状态图等形式来完成。公共的机制或服务可以在工具类（Class Utilities）中定义。

逻辑视图的风格是采用面向对象的风格，其主要的设计准则是试图在整个系统中保持单一的、一致的对象模型，避免对各个场合或过程产生多余的类和机制的技术说明。逻辑视图的结果是用来确定重要的设计包、子系统和类。

2．过程视图（Process View）

过程视图考虑的是一些非功能性的需求，主要表现为系统运行时的一些特性，它解决系统运行时的并发性、分布性、系统完整性、系统容错性，以及逻辑视图的主要抽象如何与系统进程架构结合在一起。

进程架构可以在几种层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序的逻辑网络，它们分布在一组硬件资源上，这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。例如，独立的逻辑网络可能用于支持离线系统与在线系统的分离，或者支持软件的模拟版本和测试版本的共存。

进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次（即：开始、恢复、重新配置及关闭）。另外，进程可以根据处理负载分布式的增强或可用性的提高而不断地被重复。

软件被划分为一系列单独的任务，而任务是独立的控制线程，可以在处理节点上单独调用。任务可以区分为主要任务和次要任务，主要任务是可以唯一处理的架构元素，次要任务则是由于具体实施主要任务而引入的局部附加任务（如周期性活动、缓冲、暂存等等）。主要任务采用良好的交互任务的通信机制：基于消息的同步或异步通信服务、远程过程调用、事件广播等；次要任务则以会话或共享内存来进行通信。在同一过程或处理节点上，不应对主要任务的分配做出任何假定，这是由线程的执行特点决定的。

在进程视图的设计中，应当关注那些在架构上具有重要意义的元素。使用Rational统一过程中提供的相关方法描述进程架构时，要详细描述可能的交互通信路径中的规格说明。

3．物理视图（Physical View）

物理视图主要关注的也是系统的非功能性需求，这些需求包括系统的可用性、可靠性、性能和可伸缩性。物理视图描述的是软件到硬件的映射，即展示不同的可执行程序和其他运行时构件是如何映射到底层平台或处理节点上的。软件在各种平台（包括计算机网络等）或处理节点上运行，各种元素（网络、过程、任务和对象）需要被映射至不同的节点。

在物理视图的设计中，需要考虑很多关于软件工程和系统工程的问题，因此在使用Rational统一过程提供的方法进行描述时，表达形式也多种多样，尽可能不要混用物理视图，以免产生混乱。

4．开发视图（Development View）

开发视图描绘的是系统的开发架构，它关注的是软件开发环境中实际模块的组织情况，即系统的子系统是如何被分解的。软件被打包分成为一个个小的程序模块（类库或子系统），一个程序模块可以由一位或几位开发人员来进行开发。在大型系统的开发中，有时需要将系统进行组织分层，每一层的子系统模块都为上层模块提供良好定义的接口。

系统的开发架构主要使用模块和子系统图来表达，显示了“输入”和“输出”的关系。完整的开发架构只有当所有软件元素被标识后才能加以描述。

在开发视图的设计中，在大多数情况下，需要考虑的问题与以下几项因素有关：开发难度、软件管理、重用性和通用性以及由工具集和编程语言所带来的限制。开发视图是各种活动的基础，这些活动包括：需求分配、团队工作的分配、成本评估和计划、项目进度的监控、软件重用性、可移植性和安全性等。这些活动都是建立产品线的基础。

5．用例视图（Use Case View）

用例视图有时也被认为是场景视图，扮演着一个很特殊的角色，它综合了所有上面的这四种视图。四种视图的元素通过数量比较少的一组重要场景或者用例进行无缝协同工作。

在某种意义上，这些场景或用例是最重要的需求抽象，它们的设计在Rational统一过程中可以使用用例图或交互图来表示。在系统的软件架构文档中，需要对这几个为数不多的场景进行详细的说明。用例视图通常被认为是其他4种视图的冗余视图，但是它却起着两个重要的作用：

• 作为一项设计的驱动元素来发现架构设计过程中的架构元素。
• 作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明，又作为架构原型测试的出发点。

使用这5种视图来描述架构可以解决架构的表述问题，那么Rational统一过程是如何以架构为中心实施设计过程呢？

Rational统一过程定义了两个关于架构的主要产物，它们分别是：

• 软件架构描述（SAD），用于描述与项目有关的架构视图。
• 架构原型，用于验证架构并充当开发系统其余部分的基础。

除此之外，还包括其他3种产物，上面两种产物是这3种产物的基础。这3种产物分别是：

• 设计指南，为架构设计提供指导，提供了一些模式和习惯用语的使用。
• 在开发环境中基于开发视图的产品结构。
• 基于开发视图结构的开发群组结构。

在Rational统一过程中还定义了一个参与者：架构师，负责架构的设计工作。但是，架构师不是唯一关系架构的人，大多数开发人员都参与了架构的定义和实现，尤其是在系统的细化阶段。

在Rational统一过程中，通过分析和设计工作流描述了大部分关于架构设计的活动，同时，这些活动贯穿了系统的需求、实现以及管理等方面。所以说，Rational统一过程是一个以架构为中心的过程。