什么是软件架构？

    什么是软件架构呢?

    去年毕业前期，大小的企业轮流来到学校进行宣讲，对所谓的软件开发的职业规划做出了五花八门的说明，每个公司都有自己的特色，但总体来讲，还是分为技术和管理两条线，我不太喜欢做管理，所以只关注技术的发展路线，大部分都是这样的：初级程序员——>中级程序员——>高级程序员——>架构师——>技术总监，我还算发展的比较顺利的，现在混到高级程序员的边缘了，本着“不想当将军的士兵不是好士兵”的原则，我应该对架构师这个目前还是有些神秘的东东做一个比较深入的了解，这不，正愁没有具体的实践来和抽象的理论交相辉映的时候，公司如及时雨般把一个100+人月的项目分给我了，让我担当技术经理的角色，。

    当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。

    软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。

    在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。

    软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：

    ’组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互。它有两个非常明显的特点：

• 关注架构实践的客体——软件，以软件本身作为描述对象。
• 分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。

    ‘决策派’认为软件架构包含了一系列的决策，主要包括：

• 软件系统的组织
• 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为
• 如何组合这些元素，使它们逐渐合成为更大的子系统
• 用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合

    软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。

    ‘决策派’有以下两个显著的特点：

• 关注软件架构中的实体——人，以人的决策为描述对象。
• 归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。

    按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。

    按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。

    至于‘组成派’和‘决策派’之间是否是互斥的，我不认为这样，实际上，很多牛人都不认为是这样（呵呵，我也沾些牛人的牛气），这两种观点应该是站在不同的角度来看待软件架构，架构师在分割模块时，也会不得不去作出各种决策。


参考文献：
《软件架构设计》   温昱