从需求分析到架构设计

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

软件最终要驻留、安装或部署到硬件才能运行， 而软件架构的物理视图关注“目标程序及其依赖 的运行库和系统软件”最终如何安装或部署到物 理机器，以及如何部署机器和网络来配合软件系 统的可靠性、可伸缩性等要求。
图9所示的物理架构视图表达了设备调试系统软件和硬 件的映射关系。可以看出，嵌入部分驻留在调试机中 （调试机是专用单板机），而PC机上是常见的桌面可 执行程序的形式。
和工程领域的功能需求、约束条件、使用期质量 属性、建造期间的质量属性等类似，软件系统的 需求种类也相当复杂，具体分类如下图所示。
超市系统案例
功能需求
简单而言，功能需求就是“软件有什么用，软件需要做 什么”。同时，注意把握功能需求的层次性是软件需求的 最佳实践。以该超市系统为例： 超市老板希望通过软件来“提高收银效率”。 那么，你可能需要为收银员提供一系列功能来促成这 个目的，比如供收银员使用的“任意商品项可单独取消” 功能有利于提供收银效率（笔者曾在超市有过被迫整单取 消然后一车商品重新扫描收费的痛苦经历）。 而具体到这个超市系统，系统分析员可能会决定要提 供的具体功能为：通过收银终端的按键组合，可以使收银 过程从“逐项录入状态”进入“选择取消状态”，从而取 消某项商品。
运行期质量属性。这类需求主要指软件系 统在运行期间表现出的质量水平。
运行期质量属性非常关键，因为它们直接影响着 客户对软件系统的满意度，大多数客户也不会接 受运行期质量属性拙劣的软件系统。常见的运行 期质量属性包括软件系统的易用性、性能、可伸 缩性、持续可用性、鲁棒性、安全性等。在我们 的超市系统的案例中，用户对高性能提出了具体 要求（真正的性能需求应该量化，表1没体现）， 他们不能容忍金额合计超过2秒的延时。
进程视图：设计满足运行期质量属性的架构
性能是软件系统运行期间所表现出的一种质量水 平，一般用系统响应时间和系统吞吐量来衡量。 为了达到高性能的要求，软件架构师应当针对软 件的运行时情况进行分析与设计，这就是我们所 谓的软件架构的进程视图的目标。进程视图关注 进程、线程、对象等运行时概念，以及相关的并 发、同步、通信等问题。
嵌入层。负责对调试设备的具体控制，以及高频度 地从数据采集器读取设备状态数据。
设备控制指令的物理规格被封装在嵌入层内部，读取数采 器的具体细节也被封装在嵌入层内部。
开发视图：设计满足开发期质量属性的架构
软件架构的开发视图应当为开发人员提供切实的指导。任 何影响全局的设计决策都应由架构设计来完成，这些决策 如果“漏”到了后边，最终到了大规模并行开发阶段才发 现，可能造成“程序员碰头儿临时决定”的情况大量出现， 软件质量必然将下降甚至导致项目失败。 其中，采用哪些现成框架、哪些第三方SDK、乃至哪 些中间件平台，都应该考虑是否由软件架构的开发视图确 定下来。图6展示了设备调试系统的（一部分）软件架构 开发视图：应用层将基于MFC设计实现，而通讯层采用了 某串口通讯的第三方SDK。
本案例中架构师为了满足高性能需求，采用了多线程设计： 应用层中的线程代表主程序的运行，它直接利用了MFC 的主窗口线程。无论是用户交互，还是串口的数据到达，均 采取异步事件的方式处理，杜绝了任何“忙等待”无谓的耗 时，也缩短了系统响应时间。 通讯层有独立的线程控制着“上上下下”的数据，并设 置了数据缓冲区，使数据的接收和数据的处理相对独立，从 而数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐 量。 嵌入层的设计中，分别通过时钟中断和RS232口中断来 激发相应的处理逻辑，达到轮询和收发数据的目的。
开发期质量属性。
这类非功能需求中的某些项人们倒是念念不忘， 可惜很多人并没有意识到“开发期质量属性”和 “运行期质量属性”对架构设计的影响到底有何 不同。开发期质量属性是开发人员最为关心的， 要达到怎样的目标应根据项目的具体情况而定， 而过度设计会花费额外的代价。
什么是软件架构视图 ?
Philippe Kruchten在其著作《Rational统一过程引论》中 写道： 一个架构视图是对于从某一视角或某一点上看到的系 统所做的简化描述，描述中涵盖了系统的某一特定方面， 而省略了于此方面无关的实体。 架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就” 的能力范围，因此采用“分而治之”的办法从不同视角分 别设计；同时，也为软件架构的理解、交流和归档提供了 方便。 1995年，Philippe Kruchten在《IEEE Software》上发表 了题为《The 4+1 View Model of Architecture》的论文， 引起了业界的极大关注，并最终被RU架构视图 都应该关注和遵守的一些设计限制。例如，考虑 到“一部分开发人员没有嵌入式开发经验”这条 约束情况，架构师有必要明确说明系统的目标程 序是如何编译而来的。
图7展示了整个系统的桌面部分的目标程序pcmoduel.exe、以及嵌入式模块rom-module.hex是如何编 译而来的。这个全局性的描述无疑对没有经验的开发人员 提供了实感，利于更全面地理解系统的软件架构。
设备调试系统案例
逻辑视图：设计满足功能需求的架构 应用层。负责设备状态的显示，并提供模拟控制台 供用户发送调试命令。
使用通讯层和嵌入层进行交互，但应用层不知道通讯的细 节。
通讯层。负责在RS232协议之上实现一套专用的 “应用协议”。
当应用层发送来包含调试指令的协议包，由通讯层负责按 RS232协议将之传递给嵌入层。当嵌入层发送来原始数据， 由通讯层将之解释成应用协议包发送给应用层。
从需求分类到多视图架构设计方法
需要架构设计的多重视图方法，从根本上 来说是因为需求种类的复杂性所致。
Eg:设计一座跨江大桥： 我们会考虑“连接南北的公路交通”这个“功能需求”， 从而初步设计出理想化的桥墩支撑的公路桥方案；然后还 要考虑造桥要面临的“约束条件”，这个约束条件可能是 “不能影响万吨轮从桥下通过”，于是细化设计方案，规 定桥墩的高度和桥墩之间的间距；另外还要顾及“大桥的 使用期质量属性”，比如为了“能在湍急的江流中保持稳 固”，可以把大桥桥墩深深地建在岩石层之上，和大地浑 然一体；其实，“建造期间的质量属性”也很值得考虑， 比如在大桥的设计过程中考虑“施工方便性”的一些措施。
非功能需求
约束。要开发出用户满意的软件并不是件容易的 事，而全面理解要设计的软件系统所面临的约束 可以使你向成功迈进一步。
约束性需求既包括企业级的商业考虑（例如“项目预算有 限”），也包括最终用户级的实际情况（例如“用户的平 均电脑操作水平偏低”）；既可能包括具体技术的明确要 求（例如“要求能在Linux上运行”），又可能需要考虑 开发团队的真实状况（例如“开发人员分散在不同地 点”）。这些约束性需求当然对架构设计影响很大，比如 受到“项目预算有限”的限制，架构师就不应选择昂贵的 技术或中间件等，而考虑到开发人员分散在不同地点”， 就更应注重软件模块职责划分的合理性、松耦合性等等。