软件架构是一系列有层次性的决策

软件架构属于设计范畴，但并不是所有设计都属于软件架构设计之列。

　　正如前面软件架构的“决策派”概念所揭示的，软件架构可以视为一系列重要决策的集合。不仅如此，架构决策还是分层次依次展开的。

　　首先，伴随着对软件系统的依次分解，软件架构师应当不断做出决策，例如需要划分成哪些模块、每个模块的职责为何、每个模块的接口如何定义、模块间采用何种交互机制、如何满足约束和质量属性需求、如何适应可能发生的变化等等。

　　以一个硬件设备调试系统为例。软件架构师通过理解需求，对该设备调试系统应完成的主要目标有了全局地把握：作为设备调试系统，其主要功能是实时显示设备状态、以及支持用户发送调试命令；另外，由于是为硬件产品配套的软件系统，所以它必须容易被测试，否则是硬件故障还是软件故障将很难区分；再就是必须具有很高的性能，具体性能指标为“每秒钟能够刷新5次设备状态的显示，并同时支持一个完整命令字的发送”。如图1-3所示。

 　　
　　　　　　　　　　　　　　　　
　　　　　　　　　　　图1-3    CRC卡：设备调试系统应完成的主要目标

　　之后，软件架构师必须规划整个系统的具体组成。通常，对于一个独立的软件系统而言，它常常被划分为不同的子系统或分系统，每个部分承担相对独立的功能，各部分之间通过特定的交互机制进行协作。而此例中的设备调试系统则不同，它有两个相对独立的应用组成：一个桌面应用、以及一个嵌入式应用。那么，它们如何通讯呢？最终决定，将它们通过串口连接，采用RS232协议进行通讯。再接下来，架构师必须决定这两个应用分别担负哪些职责，最终的设计决策是（如图1-4中的CRC卡所示）：桌面应用部分负责提供模拟控制台和状态显示；而嵌入式应用部分负责设备的控制和状态数据的读取。

 
　　　　　　　　图1-4    CRC卡：设备调试系统的组成部分

　　设备调试系统的桌面应用部分是一个复杂的应用程序，还应当有软件架构师来负责该应用的架构设计。如图1-5所示，通讯部分被分离出来作为通讯层，它负责在RS232协议之上实现一套专用的“应用协议”：当应用层发送来包含调试指令的协议包，它会按RS232协议将之传递给嵌入部分；当嵌入部分发送来原始数据，它将之解释成应用协议包发送给应用层。而应用层负责设备状态的显示，提供模拟控制台供用户发送调试命令，并使用通讯层和嵌入部分进行交互。

 
　　　　　　　　　图1-5    CRC卡：桌面应用进一步分解

　　通过上面的这个案例，我们强烈地感觉到：软件架构师需要做出的一系列重要设计决策，是伴随着对软件系统的层层分解依次展开的。例如，不将整个设备调试系统分为桌面部分和嵌入式部分，也就无从将桌面部分进一步分离成应用层和通讯层。

　　如前所述，其实设计决策不仅仅局限在职责划分上。例如，应用层应当如何设计才能保证很高的用户响应速度呢？通讯层应当如何设计以保证高性能地接受串口数据而不造成数据丢失呢？这些也都是架构师需要考虑的，在此不再赘述（可参考第4章和第5章的案例分析部分）。

　　其次，“架构决策是分层次依次展开的”还表现在：决策制定的顺序往往是先制定技术无关的决策、后制定技术相关的决策，后者在前者的指导下进行。对于这一点，本书将在软件架构设计过程的讲解中讨论（参见本书第2部分：软件架构设计方法与过程篇）。