图1 软件需求分类的复杂性

表1 超市系统案例：理解需求种类的复杂性

* 超市老板希望通过软件来"提高收银效率"。
* 那么，你可能需要为收银员提供一系列功能来促成这个目的，比如供收银员使用的"任意商品项可单独取消"功能有利于提供收银效率（笔者曾在超市有过被迫整单取消然后一车商品重新扫描收费的痛苦经历）。
* 而具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从"逐项录入状态"进入"选择取消状态"，从而取消某项商品。

* 约束。要开发出用户满意的软件并不是件容易的事，而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步。约束性需求既包括企业级的商业考虑（例如"项目预算有限"），也包括最终用户级的实际情况（例如"用户的平均电脑操作水平偏低"）；既可能包括具体技术的明确要求（例如"要求能在Linux上运行"），又可能需要考虑开发团队的真实状况（例如"开发人员分散在不同地点"）。这些约束性需求当然对架构设计影响很大，比如受到"项目预算有限"的限制，架构师就不应选择昂贵的技术或中间件等，而考虑到开发人员分散在不同地点"，就更应注重软件模块职责划分的合理性、松耦合性等等。
* 运行期质量属性。这类需求主要指软件系统在运行期间表现出的质量水平。运行期质量属性非常关键，因为它们直接影响着客户对软件系统的满意度，大多数客户也不会接受运行期质量属性拙劣的软件系统。常见的运行期质量属性包括软件系统的易用性、性能、可伸缩性、持续可用性、鲁棒性、安全性等。在我们的超市系统的案例中，用户对高性能提出了具体要求（真正的性能需求应该量化，我们的表1没体现），他们不能容忍金额合计超过 2秒的延时。
* 开发期质量属性。这类非功能需求中的某些项人们倒是念念不忘，可惜很多人并没有意识到"开发期质量属性"和" 运行期质量属性"对架构设计的影响到底有何不同。开发期质量属性是开发人员最为关心的，要达到怎样的目标应根据项目的具体情况而定，而过度设计（overengineering）会花费额外的代价。

图2 Philippe Kruchten提出的4+1视图方法

* 逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。
* 开发视图：描述软件在开发环境下的静态组织。
* 处理视图：描述系统的并发和同步方面的设计。
* 物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计。

图3 运用4+1视图方法针对不同需求进行架构设计

图4 设备调试系统的用例图

表2 设备调试系统的需求

* 应用层负责设备状态的显示，并提供模拟控制台供用户发送调试命令。
* 应用层使用通讯层和嵌入层进行交互，但应用层不知道通讯的细节。
* 通讯层负责在RS232协议之上实现一套专用的"应用协议"。
* 当应用层发送来包含调试指令的协议包，由通讯层负责按RS232协议将之传递给嵌入层。
* 当嵌入层发送来原始数据，由通讯层将之解释成应用协议包发送给应用层。
* 嵌入层负责对调试设备的具体控制，以及高频度地从数据采集器读取设备状态数据。
* 设备控制指令的物理规格被封装在嵌入层内部，读取数采器的具体细节也被封装在嵌入层内部。

图5 设备调试系统架构的逻辑视图

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

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

* 应用层中的线程代表主程序的运行，它直接利用了MFC的主窗口线程。无论是用户交互，还是串口的数据到达，均采取异步事件的方式处理，杜绝了任何"忙等待"无谓的耗时，也缩短了系统响应时间。
* 通讯层有独立的线程控制着"上上下下"的数据，并设置了数据缓冲区，使数据的接收和数据的处理相对独立，从而数据接收不会因暂时的处理忙碌而停滞，增加了系统吞吐量。
* 嵌入层的设计中，分别通过时钟中断和RS232口中断来激发相应的处理逻辑，达到轮询和收发数据的目的。

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

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

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

本文出自 51CTO.COM技术博客