软件架构设计（一）：软件架构概念
不积跬步，无以至千里。
程序员在向架构师转型时，都希望尽早清除“什么是架构”。但是架构的额定义又多又乱。已造成“什么是架构”成了程序员向架构师转型的最大门槛。
1.1 软件架构的分类
一个词（比如电脑），可能并不代表一件单独的东西，而是代表了一类事物。这个一般性的表述就是我们通常所说的概念。
也许大家期待一个干净利落的软件架构概念，但这有点儿难。对此，马丁·福勒给出的评价是：
软件业的恶人乐于做这样的事——找一些词汇，并将它们引申到大量微妙而又相互矛盾的含义中。一个最大的受害者就是架构这个词。很多人都试图给架构下定义，而这些定义本身却很难统一。
本专栏将软件架构概念分为两大流派——组成派和决策派，帮助各级开发人员快速理清“什么是架构的”的基础问题。下面就采用这种方式介绍结构概念。
2.1.1 组成派
Mary Shaw在《软件体系结构：一门初露端倪学科的展望》中，为软件架构给出了非常简明的定义：
软件系统的架构将系统描述为计算机组件与组件之间的交互。
必须说明，上述定义的组件是广泛意义上的元素之意，并不是指和CORBA、DCOM、EJB等相关的专有的组件概念。计算组件页式泛指，其实计算组件可以进一步细分为处理组件、数据组件、连接组件等。总之，组件可以指子系统、框架、模块、类等不同粒度的软件单元，他们可以担负不同的计算职责。
上述定义是组成派软件架构的典型代表，有如下两个显著特点：
关注架构实践中的客体——软件，以软件本身为描述对象。
分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算。
2.1.2 决策派
RUP（Rational Unified Process，统一软件开发过程）给出的架构的定义非常冗长，但其核心思想非常明确：软件架构是在一些重要方面所作出的决策集合。下面看看它的定义：
软件架构包含了关于以下问题的重要决策：
软件系统的组织；
选择组成系统的结构元素和他们之间的接口，以及当这些元素相互协作时所体现的行为；
如何组成这些元素，使他们逐渐合成为更大的子系统；
用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合。
软件架构并部基金注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。
该定义是“决策派”软件架构概念的典型代表，有如下两个显著的特点：
关注架构实践中的主体——人，以人的决策为描述对象。
归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括众多非功能需求的决策。
2.1.2 软件架构概念大观
下面再列举几个著名的软件架构定义，请大家：
结合实践，体会自己所认为的“架构”是什么，也可以问问周围同事对架构的理解；
体会到专家们对“架构”下的定义虽然多，但万变不离其宗——都是围绕“组成”和“决策”两个角度定义架构的；
注意区分，下面的定义1和定义2属于架构概念的“决策派”，而定义3、4、5、6、7属于架构概念的“组成派”；
关注定义7，它将架构的多视图“本性”体现到了定义当中，是相对比较新的定义，业界都深表认同。
1.Booch、Rumbaugh 和 Jacobson的定义
架构师一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在像话协作照片那个明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的系统，以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。
2.2 概念思想的解析
2.2.1 软件架构关注分割和交互
架构设计师分与合的艺术。
“软件系统的架构将系统描述为计算机组件及组件之间的交互”，shaw的这个定义从“软件组成”角度解析了软件架构的要素：组件及组件之间的交互。架构=组件 交互，组件和111组件之间有交互关系（图中的交互“关系”建模成UML关联类）。
下面以大家熟悉的MVC架构为例进行说明。如图2-1所示。
采用MVC架构的软件包含了这样的3种组件：Model、View、Controller.
这三种组件通过交互来协作：View创建Controller后，Controller根据用户交互调用Model的对应服务，而Model会将自身的改变通知View，View则会读取Model的信息以更新自身。