运用RUP 4+1视图方法进行软件架构设计[转]（一）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小结与说明

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

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

参考资料 

Philippe Kruchten著，周伯生等译. Rational统一过程引论（原书第2版）. 机械工业出版社，2002  Karl E. Wiegers著，刘伟琴等译. 软件需求（第2版）. 清华大学出版社，2004 

关于作者

温昱。架构设计师，技术咨询顾问，松耦合空间网站创办人。擅长面向对象、架构和框架设计，对设计模式、UML、RUP和软件工程有深入研究。曾在金融、航空、多媒体、网络管理、中间件平台等领域负责和参与多个大型系统的设计和开发。发表《拥抱变化：敏捷设计从理论到实践》、《随需而变的RUP》等文章数十篇，目前译著有《应用框架的设计与实现--.NET平台》一书。可以通过[email protected]与温昱联系。