1.5.2  软件架构概念的体现

有关PM Tool的案例故事先讲到这儿，虽然其中仅涉及到架构设计方案的一小部分，但仍然可以体现软件架构的概念——对组成派和决策派的架构概念都有体现。

先说组成派的架构概念，它强调软件架构包含了“计算组件及组件之间的交互”。组件体现在哪里呢？
在图1-7所展示的设计中，“业务层”和“展现层”就是两个组件；当然，这两个组件粒度很粗，并且完全是黑盒。

到了图1-8所展示的设计中，黑盒虽然没有完全变成白盒，但支持MVC协作机制的一部分关键类已经明确——PrgMgtModel、GanttChart和GanttChartImpl都是粒度较细的组件，可以说，“业务层”和“展现层”两个组件在某种程度上已从黑盒变成了灰盒，从而能提供更具体的开发指导。

那么，软件架构概念中所说的“交互”体现在哪里呢？

对于图1-7所展示的设计，“业务层”和“展现层”两个粗粒度组件之间的交互为：展现层从业务层“读取数据”。

“读取数据”这一交互到了图1-8的设计依然存在，但此职责已经“具体落实”成了“GanttChartImpl从PrgMgtModel读取数据”。另外，图1-8的设计中，两个“调用”关系也是软件架构的概念中“交互”的具体例子。

由此看来，组成派软件架构概念完全是对架构设计方案的忠实概括，只不过有一点儿抽象罢了。

再看看决策派的架构概念，它归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统、架构风格等的几类决策，还包括关于众多非功能需求的决策。图1-7所展示的设计那么简单，也包含了设计决策吗？是的，业务层和展现层分离，体现了架构概念中的“软件系统的组织”决策，这一设计决策早已得到了业界的普遍认同。

下面再举个例子，来说明软件架构中的设计决策是如何支持“使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等”非功能需求的。仅以“弹性”为例吧。为了防止PM Tool“绑死”在特定甘特图绘制包上，架构设计之时作了如下决策（参见图1-8）：引入自主定义的GanttChart接口，让实现该接口的GanttChartImpl转而调用第三方SDK（其实就是Adapter设计模式）。这样一来，架构就有了弹性——当发现功能更强大的甘特图程序包时（或决定直接调用Java 2D自行开发甘特图绘制部分时），可以方便地仅更改GanttChartImpl，而其他组件不用更改（如图1-9所示）。

图1-9  软件架构如何具有弹性