【软件架构】运用RUP4+1视图软件架构设计（逻辑视图、实现视图、进程视图、物理视图和用例视图）

【软件架构】运⽤RUP4+1视图软件架构设计（逻辑视图、实现视图、进程视图、物理视图和⽤例视图）
RUP概述
RUP（Rational Unified Process），统⼀软件开发过程，统⼀软件过程是⼀个⾯向对象且基于⽹络的程序开发⽅法论。

在RUP中采⽤“4+1”视图模型来描述软件系统的体系结构。

“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和⽤例视图。

最终⽤户关⼼的是系统的功能，因此会侧重于逻辑视图；
程序员关⼼的是系统的配置、装配等问题，因此会侧重于实现(开发)视图；
系统集成⼈员关⼼的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程(处理)视图；
系统⼯程师关⼼的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署(物理)视图。

分析⼈员和测试⼈员关⼼的是系统的⾏为，因此会侧重于⽤例(场景)视图；
原⽂链接：https:///turbock/article/details/102930810
（2）4+1视图介绍：
（3）UML 4+1视图：
（）
运⽤RUP 4+1视图⽅法进⾏软件架构设计
下⽂摘⾃：
⽐如设计⼀座跨江⼤桥：
我们会考虑"连接南北的公路交通"这个"功能需求"，从⽽初步设计出理想化的桥墩⽀撑的公路桥⽅案；
然后还要考虑造桥要⾯临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计⽅案，规定桥墩的⾼度和桥墩之间的间距；
另外还要顾及"⼤桥的使⽤期质量属性"，⽐如为了"能在湍急的江流中保持稳固"，可以把⼤桥桥墩深深地建在岩⽯层之上，和⼤地浑然⼀体；其实，"建造期间的质量属性"也很值得考虑，⽐如在⼤桥的设计过程中考虑"施⼯⽅便性"的⼀些措施。

和⼯程领域的功能需求、约束条件、使⽤期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所⽰。

图1 软件需求分类的复杂性
超市系统案例：理解需求种类的复杂性
例⼦是最好的⽼师。

为了更好地理解软件需求种类的复杂性，我们来分析⼀个实际的例⼦。

在表1中，我们列举了⼀个典型的超市系统的需求⼦集，从这个例⼦中可以清晰地看到需求可以分为两⼤类：功能需求和⾮功能需求。

表1 超市系统案例：理解需求种类的复杂性
简单⽽⾔，功能需求就是"软件有什么⽤，软件需要做什么"。

同时，注意把握功能需求的层次性是软件需求的最佳实践。

以该超市系统为例：
超市⽼板希望通过软件来"提⾼收银效率"。

那么，你可能需要为收银员提供⼀系列功能来促成这个⽬的，⽐如供收银员使⽤的"任意商品项可单独取消"功能有利于提供收银效率（笔者曾在超市有过被迫整单取消然后⼀车商品重新扫描收费的痛苦经历）。

⽽具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从"逐项录⼊状态"进⼊"选择取消状态"，从⽽取消某项商品。

从上⾯的例⼦中我们还惊讶地发现，⾮功能需求--⼈们最经常忽视的⼀⼤类需求--包括的内容⾮常宽、并且极其重要。

⾮功能需求⼜可以分为如下三类：
约束。

要开发出⽤户满意的软件并不是件容易的事，⽽全⾯理解要设计的软件系统所⾯临的约束可以使你向成功迈进⼀步。

约束性需求既包括企业级的商业考虑（例如"项⽬预算有限"），也包括最终⽤户级的实际情况（例如"⽤户的平均电脑操作⽔平偏低"）；既可能包括具体技术的明确要求（例如"要求能在Linux上运⾏"），⼜可能需要考虑开发团队的真实状况（例如"开发⼈员分散在不同地点"）。

这些约束性需求当然对架构设计影响很⼤，⽐如受到"项⽬预算有限"的限制，架构师就不应选择昂贵的技术或中间件等，⽽考虑到开发⼈员分散在不同地点"，就更应注重软件模块职责划分的合理性、松耦合性等等。

运⾏期质量属性。

这类需求主要指软件系统在运⾏期间表现出的质量⽔平。

运⾏期质量属性⾮常关键，因为它们直接影响着客户对软件系统的满意度，⼤多数客户也不会接受运⾏期质量属性拙劣的软件系统。

常见的运⾏期质量属性包括软件系统的易⽤性、性能、可伸缩性、持续可⽤性、鲁棒性、安全性等。

在我们的超市系统的案例中，⽤户对⾼性能提出了具体要求（真正的性能需求应该量化，我们的表1没体现），他们不能容忍⾦额合计超过2秒的延时。

开发期质量属性。

这类⾮功能需求中的某些项⼈们倒是念念不忘，可惜很多⼈并没有意识到"开发期质量属性"和"运⾏期质量属性"对架构设计的影响到底有何不同。

开发期质量属性是开发⼈员最为关⼼的，要达到怎样的⽬标应根据项⽬的具体情况⽽定，⽽过度设计（overengineering）会花费额外的代价。

什么是软件架构视图
那么，什么是软件架构视图呢？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视图⽅法，针对不同需求进⾏架构设计，从⽽确保重要的需求⼀⼀被满⾜。

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

请读者注意。