案例教学1：4+1视图方法进行软件体系结构设计要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
本文从理解需求种类的复杂性谈起，通过具体案例的分析，展示了如何通过RUP的4+1视图方法，针对不同需求进行体系结构设计，从而确保重要的需求一一被满足。
1、呼唤体系结构设计的多重视图方法灵感一闪，就想出了把大象放进冰箱的办法，这自然好。
但希望每个体系结构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。
需要体系结构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。
以工程领域的例子开道吧。
比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。
和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。
图1 软件需求分类的复杂性2、超市系统案例：理解需求种类的复杂性例子是最好的老师。
为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。
在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。
表1 超市系统案例：理解需求种类的复杂性简单而言，功能需求就是"软件有什么用，软件需要做什么"。
同时，注意把握功能需求的层次性是软件需求的最佳实践。
以该超市系统为例：* 超市老板希望通过软件来"提高收银效率"。
* 那么，你可能需要为收银员提供一系列功能来促成这个目的，比如供收银员使用的"任意商品项可单独取消"功能有利于提供收银效率。
* 而具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从"逐项录入状态"进入"选择取消状态"，从而取消某项商品。
从上面的例子中我们还惊讶地发现，非功能需求--人们最经常忽视的一大类需求--包括的内容非常宽、并且极其重要。
非功能需求又可以分为如下三类：* 约束。
要开发出用户满意的软件并不是件容易的事，而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步。
约束性需求既包括企业级的商业考虑（例如"项目预算有限"），也包括最终用户级的实际情况（例如"用户的平均电脑操作水平偏低"）；既可能包括具体技术的明确要求（例如"要求能在Linux上运行"），又可能需要考虑开发团队的真实状况（例如"开发人员分散在不同地点"）。
这些约束性需求当然对体系结构设计影响很大，比如受到"项目预算有限"的限制，体系结构师就不应选择昂贵的技术或中间件等，而考虑到开发人员分散在不同地点"，就更应注重软件模块职责划分的合理性、松耦合性等等。
* 运行期质量属性。
这类需求主要指软件系统在运行期间表现出的质量水平。
运行期质量属性非常关键，因为它们直接影响着客户对软件系统的满意度，大多数客户也不会接受运行期质量属性拙劣的软件系统。
常见的运行期质量属性包括软件系统的易用性、性能、可伸缩性、持续可用性、鲁棒性、安全性等。
在我们的超市系统的案例中，用户对高性能提出了具体要求（真正的性能需求应该量化，我们的表1没体现），他们不能容忍金额合计超过 2秒的延时。
* 开发期质量属性。
这类非功能需求中的某些项人们倒是念念不忘，可惜很多人并没有意识到"开发期质量属性"和" 运行期质量属性"对体系结构设计的影响到底有何不同。
开发期质量属性是开发人员最为关心的，要达到怎样的目标应根据项目的具体情况而定，而过度设计（overengineering）会花费额外的代价。
3、什么是软件体系结构视图那么，什么是软件体系结构视图呢？Philippe Kruchten在其著作《Rational统一过程引论》中写道：一个体系结构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。
也就是说，体系结构要涵盖的内容和决策太多了，超过了人脑"一蹴而就"的能力范围，因此采用"分而治之"的办法从不同视角分别设计；同时，也为软件体系结构的理解、交流和归档提供了方便。
值得特别说明的，大多数书籍中都强调多视图方法是软件体系结构归档的方法，其实不然。
多视图方法不仅仅是体系结构归档技术，更是指导我们进行体系结构设计的思维方法。
4、Philippe Kruchten提出的4+1视图方法1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。
如图2所示。
图2 Philippe Kruchten提出的4+1视图方法该方法的不同体系结构视图承载不同的体系结构设计决策，支持不同的目标和用途：* 逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。
* 开发视图：描述软件在开发环境下的静态组织。
* 处理视图/进程视图，processing/：描述系统的并发和同步方面的设计。
* 物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计。
运用4+1视图方法：针对不同需求进行体系结构设计如前文所述，要开发出用户满意的软件并不是件容易的事，软件体系结构师必须全面把握各种各样的需求、权衡需求之间有可能的矛盾之处，分门别类地将不同需求一一满足。
Philippe Kruchten提出的4+1视图方法为软件体系结构师"一一征服需求"提供了良好基础，如图3所示。
图3 运用4+1视图方法针对不同需求进行体系结构设计逻辑视图。
逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。
开发视图。
开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。
开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
处理视图。
处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。
处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图。
物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。
物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的体系结构视图。
5、设备调试系统案例概述本文的以下部分，将研究一个案例：某型号设备调试系统。
设备调试员通过使用该系统，可以察看设备状态（设备的状态信息由专用的数据采集器实时采集）、发送调试命令。
该系统的用例图如图4所示。
图4 设备调试系统的用例图经过研制方和委托方的紧密配合，最终确定的需求可以总括地用表2来表示。
表2 设备调试系统的需求下面运用RUP推荐的4+1视图方法，从不同视图进行体系结构设计，来分门别类地将不同需求一一满足。
A.逻辑视图：设计满足功能需求的体系结构首先根据功能需求进行初步设计，进行大粒度的职责划分。
如图5所示。
* 应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。
* 应用层使用通讯层和嵌入层进行交互，但应用层不知道通讯的细节。
* 通讯层负责在RS232协议之上实现一套专用的"应用协议"。
* 当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给嵌入层。
* 当嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。
* 嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。
* 设备控制指令的物理规格被封装在嵌入层内部，读取数采器的具体细节也被封装在嵌入层内部。
图5 设备调试系统体系结构的逻辑视图B. 开发视图：设计满足开发期质量属性的体系结构软件体系结构的开发视图应当为开发人员提供切实的指导。
任何影响全局的设计决策都应由体系结构设计来完成，这些决策如果"漏"到了后边，最终到了大规模并行开发阶段才发现，可能造成"程序员碰头儿临时决定"的情况大量出现，软件质量必然将下降甚至导致项目失败。
其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件体系结构的开发视图确定下来。
图6展示了设备调试系统的（一部分）软件体系结构开发视图：应用层将基于MFC设计实现，而通讯层采用了某串口通讯的第三方SDK。
图6 设备调试系统体系结构的开发视图约束性需求:约束应该是每个体系结构视图都应该关注和遵守的一些设计限制。
例如，考虑到"一部分开发人员没有嵌入式开发经验"这条约束情况，体系结构师有必要明确说明系统的目标程序是如何编译而来的：图7展示了整个系统的桌面部分的目标程序pc-moduel.exe、以及嵌入式模块rom- module.hex是如何编译而来的。
这个全局性的描述无疑对没有经验的开发人员提供了实感，利于更全面地理解系统的软件体系结构。
图7 设备调试系统体系结构的开发视图C. 处理视图：设计满足运行期质量属性的体系结构性能是软件系统运行期间所表现出的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。
为了达到高性能的要求，软件体系结构师应当针对软件的运行时情况进行分析与设计，这就是我们所谓的软件体系结构的处理视图的目标。
