设计--软件架构视图 4+1视图

什么是软件架构视图

那么，什么是软件架构视图呢？Philippe Kruchten在其著作《Rational统一过程引论》中写道：

一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。
也就是说，架构要涵盖的内容和决策太多了，超过了人脑"一蹴而就"的能力范围，因此采用"分而治之"的办法从不同视角分别设计；同时，也为软件架构的理解、交流和归档提供了方便。

值得特别说明的，大多数书籍中都强调多视图方法是软件架构归档的方法，其实不然。多视图方法不仅仅是架构归档技术，更是指导我们进行架构设计的思维方法。

Philippe Kruchten提出的4+1视图方法

1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。如图2所示。

图2 Philippe Kruchten提出的4+1视图方法

该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途：

逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。

开发视图：描述软件在开发环境下的静态组织。

处理视图：描述系统的并发和同步方面的设计。

物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计。

运用4+1视图方法：针对不同需求进行架构设计

如前文所述，要开发出用户满意的软件并不是件容易的事，软件架构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。

Philippe Kruchten提出的4+1视图方法为软件架构师"一一征服需求"提供了良好基础，如图3所示。

图3 运用4+1视图方法针对不同需求进行架构设计

逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。

开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。

处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图。物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

设备调试系统案例概述

本文的以下部分，将研究一个案例：某型号设备调试系统。

设备调试员通过使用该系统，可以察看设备状态（设备的状态信息由专用的数据采集器实时采集）、发送调试命令。该系统的用例图如图4所示。

图4 设备调试系统的用例图

经过研制方和委托方的紧密配合，最终确定的需求可以总括地用表2来表示。

表2 设备调试系统的需求

下面运用RUP推荐的4+1视图方法，从不同视图进行架构设计，来分门别类地将不同需求一一满足。

逻辑视图：设计满足功能需求的架构

首先根据功能需求进行初步设计，进行大粒度的职责划分。如图5所示。

应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。

应用层使用通讯层和嵌入层进行交互，但应用层不知道通讯的细节。

通讯层负责在RS232协议之上实现一套专用的"应用协议"。

当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给嵌入层。

当嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。

嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。

设备控制指令的物理规格被封装在嵌入层内部，读取数采器的具体细节也被封装在嵌入层内部。

图5 设备调试系统架构的逻辑视图

开发视图：设计满足开发期质量属性的架构

软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果"漏"到了后边，最终到了大规模并行开发阶段才发现，可能造成"程序员碰头儿临时决定"的情况大量出现，软件质量必然将下降甚至导致项目失败。

其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下来。图6展示了设备调试系统的（一部分）软件架构开发视图：应用层将基于MFC设计实现，而通讯层采用了某串口通讯的第三方SDK。

图6 设备调试系统架构的开发视图

在说说约束性需求。约束应该是每个架构视图都应该关注和遵守的一些设计限制。例如，考虑到"一部分开发人员没有嵌入式开发经验"这条约束情况，架构师有必要明确说明系统的目标程序是如何编译而来的：图7展示了整个系统的桌面部分的目标程序pc-moduel.exe、以及嵌入式模块rom-module.hex是如何编译而来的。这个全局性的描述无疑对没有经验的开发人员提供了实感，利于更全面地理解系统的软件架构。

图7 设备调试系统架构的开发视图

处理视图：设计满足运行期质量属性的架构

性能是软件系统运行期间所表现出的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。为了达到高性能的要求，软件架构师应当针对软件的运行时情况进行分析与设计，这就是我们所谓的软件架构的处理视图的目标。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。图8展示了设备调试系统架构的处理视图。

可以看出，架构师为了满足高性能需求，采用了多线程的设计：

应用层中的线程代表主程序的运行，它直接利用了MFC的主窗口线程。无论是用户交互，还是串口的数据到达，均采取异步事件的方式处理，杜绝了任何"忙等待"无谓的耗时，也缩短了系统响应时间。

通讯层有独立的线程控制着"上上下下"的数据，并设置了数据缓冲区，使数据的接收和数据的处理相对独立，从而数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐量。

嵌入层的设计中，分别通过时钟中断和RS232口中断来激发相应的处理逻辑，达到轮询和收发数据的目的。

图8 设备调试系统架构的处理视图

物理视图：和部署相关的架构决策

软件最终要驻留、安装或部署到硬件才能运行，而软件架构的物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。图9所示的物理架构视图表达了设备调试系统软件和硬件的映射关系。可以看出，嵌入部分驻留在调试机中（调试机是专用单板机），而PC机上是常见的桌面可执行程序的形式。

图9 设备调试系统架构的物理视图

我们还可能根据具体情况的需要，通过物理架构视图更明确地表达具体目标模块及其通讯结构，如图10所示。

图10 设备调试系统架构的物理视图

小结与说明

所谓本立道生。深入理解软件需求分类的复杂性，明确区分功能需求、约束、运行期质量属性、开发期质量属性等不同种类的需求就是"本"，因为各类需求对架构设计的影响截然不同。本文通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行架构设计，从而确保重要的需求一一被满足。

本文重点在于方法的解说，因此省略了对架构设计中不少具体问题的说明，同时本文提供的说明架构设计方案的模型也经过了简化。请读者注意。

 

转载自：http://www.uml.org.cn/zjjs/201412262.asp