软件架构的概念

     我这样定义软件架构：软件系统包含的主要元素、重要约束与关键决策，以及它们之间的关系并如何进行协做交互，以知足软件系统的不一样涉众需求。

　　首先说说主要元素。这里说的元素不但包括接口、类、组件，还应有框架、子系统、独立程序（如数据库服务器）、管道、消息等。为何是主要元素而不是全部元素？1、从需求的角度用户首先并主要关注核心业务需求的知足，若是核心业务需求不能知足，其它的一切都没必要讲。这就比如去买手机，若是这部手机不能正常通话，就是再美观、有再多的辅助功能，也不能成其为手机，也就不会有人购买。软件架构做为与客户等涉众人员沟通的工具，不能重点关注如何知足这些核心业务需求的要求，也就失去它存在的意义。若是可以有效的把握这些主要的核心业务需求，也就离软件项目的成功不远了。2、从软件项目开发的现实来看，大多数软件项目都面临项目工期的压力，软件架构工程师必须在必定的时间内决定架构设计方案，不然没有软件架构所提供的对技术的足够指导以及对分工协做的足够限制，开发设计编码团队将面临项目失败的风险。因此软件架构工程师没有时间对全部元素进行深刻分析。3、人的精力、能力是有限的，若是不能把主要精力和时间花在决定软件项目成功的核心业务需求上，而是全部软件需求与元素上，最终致使全部需求与元素都分析了又都不够深刻，这样的软件架构只能是流于形式的软件架构，对提升软件的质量不但没有帮助反而会害软件项目失败。

最容易被忽略的多是重要约束。在说明重要约束的重要性前看看这样一个例子：C/S软件系统须要实现信息量不大的高并发实时网络通信，对于大多数有经验的软件架构工程师都会摒弃SELECT方式的不管是同步仍是异步、阻塞仍是非阻塞SOCKET通信模式，而会选择IOCP。但若是软件系统有一条运行约束：系统必须运行在LINUX下，整个软件系统的架构都面临巨大冲击：LINUX下根本不支持IOCP！必须使用EPOLL。因此，许多约束之中其实隐藏着一些隐含的需求，它经过如下三种路径影响软件系统：1、直接制约设计决策。如上面的例子，架构工程师必须直接遵循，并影响关键决策。2、引伸并转化为功能需求。这种状况下可能会增长软件系统的元素，若是在软件架构中不进行必要的说明，软件项目的涉众人员可能会对这些“平白无故忽然冒出来的”元素表示疑惑。3、引伸并转化为非功能需求。这种状况下也可能会影响关键决策。

　　能够这样讲：软件架构的每个过程当中的每一步工做都是一系列的重要设计决策。但是最难让人理解是软件架构如何包含决策？这里有两个误解：一是认为软件架构就是RUP的4+1视图与软件架构文档，因此没法说明这些决策。二是在软件架构中引入的每个设计模式、框架，其实就表现了一系列决策。因此虽然人们不理解软件架构如何包含决策，但其实每一位架构工程师都在不自觉的包含决策。我之因此提出是但愿在架构过程当中应主动有意识的包含这些关键决策。

　　主要元素、重要约束与关键决策从局部静态孤立的说明了软件系统的组成成份，而它们之间的关系则是说明它们是如何静态组成一个有机的软件系统总体的；如何进行协做交互则是从动态的角度说明软件系统是能进行怎样的行为、怎样知足软件系统的不一样涉众需求。