注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
设备调试系统案例概述
本文的以下部分，将研究一个案例：某型号设备调试系统。
设备调试员通过使用该系统，可以察看设备状态（设备的状态信息由专用的数据采集器实时采集）、发送调试命令。
经过研制方和委托方的紧密配合，最终确定的需求可以总括地用表2来表示。
|
非功能需求 |
功能需求 |
|
约束 |
运行期质量属性 |
开发期质量属性 |
|
程序的嵌入式部分必须用C语言开发
一部分开发人员没有嵌入式开发经验 |
高性能 |
易测试性 |
察看设备状态
发送调试命令 |
表2 设备调试系统的需求
下面运用RUP推荐的4+1视图方法，从不同视图进行架构设计，来分门别类地将不同需求一一满足。
逻辑视图：设计满足功能需求的架构
首先根据功能需求进行初步设计，进行大粒度的职责划分。如图5所示。
应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。
应用层使用通讯层和嵌入层进行交互，但应用层不知道通讯的细节。
通讯层负责在RS232协议之上实现一套专用的“应用协议”。
当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给嵌入层。
当嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。
嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。
设备控制指令的物理规格被封装在嵌入层内部，读取数采器的具体细节也被封装在嵌入层内部。
开发视图：设计满足开发期质量属性的架构
软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果“漏”到了后边，最终到了大规模并行开发阶段才发现，可能造成“程序员碰头儿临时决定”的情况大量出现，软件质量必然将下降甚至导致项目失败。
其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下来。图6展示了设备调试系统的（一部分）软件架构开发视图：应用层将基于MFC设计实现，而通讯层采用了某串口通讯的第三方SDK。
在说说约束性需求。约束应该是每个架构视图都应该关注和遵守的一些设计限制。例如，考虑到“一部分开发人员没有嵌入式开发经验”这条约束情况，架构师有必要明确说明系统的目标程序是如何编译而来的：图7展示了整个系统的桌面部分的目标程序pc-moduel.exe、以及嵌入式模块rom-module.hex是如何编译而来的。这个全局性的描述无疑对没有经验的开发人员提供了实感，利于更全面地理解系统的软件架构。
处理视图：设计满足运行期质量属性的架构
性能是软件系统运行期间所表现出的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。为了达到高性能的要求，软件架构师应当针对软件的运行时情况进行分析与设计，这就是我们所谓的软件架构的处理视图的目标。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。图8展示了设备调试系统架构的处理视图。
可以看出，架构师为了满足高性能需求，采用了多线程的设计：
应用层中的线程代表主程序的运行，它直接利用了MFC的主窗口线程。无论是用户交互，还是串口的数据到达，均采取异步
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
