一个词（比如“电脑”），可能并不代表一件单独的东西，而是代表了一类事物。这个一般性的表述就是我们通常所说的“概念”。

　　也许读者期待一个干净利落的软件架构概念，但这不是现实。对此，Martin Fowler给出的评价是，“软件业的人乐于做这样的事——找一些词汇，并把它们引申到大量微妙而又相互矛盾的含义。一个最大的受害者就是‘架构’这个词。……很多人都试图给‘架构’下定义，而这些定义本身却很难统一。”

　　软件架构概念：组成派

　　关于软件架构的概念，有太多版本，这对我们的实践也造成了很多麻烦。笔者认为，可以将这些概念大致分为两大流派：组成派和决策派。

　　Mary Shaw在《软件体系结构：一门初露端倪学科的展望》中，为“软件架构”给出了精致利索的定义：

　　软件系统的架构将系统描述为计算组件及组件之间的交互（The architecture of a software system defines that system in terms of computational components and interactions among those components.）。

　　必须说明，上述定义中的“组件”是广泛意义上的元素之意，并不是指和CORBA、DCOM、EJB等相关的专有的组件概念；“计算组件”也是泛指，其实计算组件可以进一步细分为处理组件、数据组件、连接组件等。总之，“组件”可以指子系统、框架、模块、类等不同粒度的软件单元，它们可以担负不同的计算职责。

　　上述定义是“组成派”软件架构概念的典型代表，有如下两个显著特点：

　　• 关注架构实践中的客体——软件，以软件本身为描述对象；　　• 分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算目的。

　　软件架构概念：决策派

　　下面来看看RUP（Rational Unified Process，Rational统一过程）为软件架构下的定义：

　　软件架构包含了关于以下问题的重要决策：

　　• 软件系统的组织；　　• 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；　　• 如何组合这些元素，使它们逐渐合成为更大的子系统；　　• 用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合。　　软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡、以及美学等。

　　上述定义看似冗长，其实核心思想非常明确：软件架构是在一些重要方面所做出的决策的集合。

　　该定义是“决策派”软件架构概念的典型代表，有如下两个显著特点：

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

　　深入解析：找准软件架构的位置

　　既然窗帘是用来遮光的，为什么非要用一整块布呢？于是百叶窗发明了。

　　既然建模有助于认清复杂问题，为什么非守着软件架构的“文字定义”方式不放呢？于是我们开始了下面“模型驱动”的思辨过程。

　　从Shaw的架构概念开始

　　“软件系统的架构将系统描述为计算组件及组件之间的交互”，Shaw的这个定义从“软件组成”角度解析了软件架构的要素：组件、以及组件之间的交互。通过UML类图，我们可以将这个关系表达得更加清晰，参见图1。如图所示，组件和组件之间可以有交互关系，图中的“交互”采用了关联类的语法。

 　　 　　　

　　　　　　　　图1    软件架构的要素：组件、以及组件之间的交互

　　Shaw的架构定义高度抽象地将软件架构概括为“组件＋交互”，我们有必要举例说明之——就以大家熟悉的MVC为例吧（如图2所示）：

　　采用MVC架构的软件会包含了这样三种组件：Model、View、Controller。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12639375/viewspace-150453/，如需转载，请注明出处，否则将追究法律责任。