解析软件架构概念

组合派：软件系统的架构将系统描述为计算组件及组件之间的交互。
决策派：架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织--包括这些元素及其接口、它们的协作和它们的组合--架构风格。

如：伴随着对软件系统的依次分解，软件架构师应当不断做出决策，例如需要划分成哪些模块、每个模块的职责为何、每个模块的接口如何定义、模块间采用何种交互机制、如何满足约束和质量属性需求、如何适应可能发生的变化等等。

子系统、框架与架构

框架与架构的区别：框架是软件，架构不是。
框架是一种特殊的软件，它并不能提供完整的解决方案，而是为你构建解决方案提供良好的基础。框架中的服务可以被最终应用系统直接使用，而框架中的扩展点是供开发人员定制的'可变化点'。
软件架构不是软件，而是关于软件如何设计的重要决策。涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。
框架和架构的关系
1. 为了尽早验证架构设计，或者出于支持产品线开发的目的，可以将关键的通用机制甚至整个架构以框架的方式进行实现。
2. 业界可能存在大量可供重用的框架，这些框架或者已经实现了软件架构所需的重要架构机制，或者为未来系统的某个子系统提供了可扩展的半成品，所以最终的软件架构可以借助这些框架来扩展。

框架和架构技术的出现，都是为了解决系统的复杂性而采取"分而治之"思维的结果--先大局后局部，就出现了架构；先通用后专用，就出现了框架。架构是问题的抽象解决方案，它关注大局而忽略细节；而框架是通用的半成品，还必须根据具体需求进一步定制开发才能变成应用系统

软件架构的作用

错误守恒定律：在一个大型系统内仍然存在的错误数目和已经修改的错误数目成正比。也就是说，一个缺陷充斥的系统将始终是一个缺陷充斥的系统。

软件架构视图

多重软件架构视图之所以必不可少，是因为各类涉众（用户、客户、开发人员、测试人员、维护人员、其他人员）需要从各自的角度理解和使用架构。另一方面，每个软件架构视图关注软件架构不同的方面，使问题得以清晰化和简化，利于软件架构师完成架构设计工作，这也是"分而治之"的思想。
可简单分为逻辑架构和物理架构。逻辑元素一般指某种级别的功能模块。逻辑架构设计的三大核心任务：
识别功能模块
规划功能块的接口
明确功能块之间的使用关系和使用机制

多视图架构设计可以帮助架构师完成下述工作：
1、 要满足性能、持续可用性等方面的需求，架构师必须深入研究软件系统运行期间的情况、制定相应的设计决策，这些需求被称为软件的"运行期质量属性"。
2、 而要满足可扩展性、可重用性等方面的需求，则要求架构师深入研究软件系统开发期间的情况、制定相应的设计决策，这些需求被称为软件的"开发期质量属性"
3、 约束是一类特殊的需求，带有一定强制性，架构师制定的架构决策必须满足这些限制
4、 为了满足功能需求，架构师必须规划组成软件系统的所有模块，为他们分配不同职责，使这些模块可以通过协作完成功能需求

软件架构要设计到什么程度

我不会认为Coding和Designing是对立的。问题在于，那些设计人员的设计往往是高来高去的扯淡，脱离实际情况，二者的矛盾就必然存在。
分而治之有两种方式，一种是"按问题的深度分而治之"，如接口和实现分离（如分层结构）；一种是"按问题的广度分而治之"，如把系统分为不同的子系统。
高来高去架构设计的问题和对策：
问题：遗漏了对团队某些角色的指导。对策：针对遗漏的架构视图进行设计
问题：不够深入。对策：设计决策须细化到和技术相关的层面
问题：只用了分层架构的分层概念来进行职责划分，没有明确层次之间的交互接口和交互机制。对策：明确它们。

理解软件工程概念模型

模型就是抽象，就是有意识地忽略事物的某些特征，识别出关键元素。抽象带来的好处就是能够反映模型中元素之间的关系，清楚把握大局。

《软件工程--技术、方法与环境》一书中，有一个极为精简的软件工程概念模型： 

 

该模型可以用一句话概括：软件工程是（目标，方法，活动）三元组。它体现了目标-方法-活动的3维正交关系：

• 任何目标，都要依照特定方法，由特定活动实现；
• 任何方法，都是指导特定活动，来完成某种目标；
• 任何活动，都由特定方法指导，来完成某种目标。

一个简单的PM Tool案例
该案例贯穿了该书很多章节，这里截取了一小段，对于理解如果进行架构设计实践有一定帮助： http://book.csdn.net/bookfiles/383/10038314312.shtml
 
-------------------------------------------------------
书名：软件架构设计 作者：温昱著 来源：电子工业出版社 出版时间：2007年05月 ISBN:9787121039461 定价：45元
 
 
1.5  PM Tool案例：领会软件架构概念
为了有助于领会软件架构的概念，我们引入一个名为“PM Tool”的案例。PM Tool是一个项目管理系统，提供项目计划、任务管理和资源管理等功能。本节希望结合案例来讨论软件架构，为读者理解软件架构的概念带来实感。
1.5.1  案例故事
PM Tool有一项名为“查看甘特图”的需求，用户要求“能够以甘特图方式查看任务的起始时间、结束时间、任务承担者等信息”。经过分析我们不难发现，PM Tool至少应提供两种查看任务计划的方式：一种是以表格的方式将任务名称、开始时间等信息列出，另一种是采用甘特图。如图1-6所示。
图1-6  PM Tool至少要提供两种查看任务计划的方式
任务是如何计划的？又具体分配给哪些项目成员？这些信息和PM Tool采用何种方式来展现应当是没有关系的。根据此分析，我们立即想到采用MVC架构，将业务逻辑和展现逻辑分开，如图1-7所示。
图1-7  和具体技术无关的架构方案
上面的架构设计，还处于“和具体技术无关”的层面。我们必须考虑更多的实际开发中要涉及到的技术问题，从而不断细化架构方案，这样才能为开发人员提供更多的指导和限制，也才能真正降低后续开发中的重大技术风险。
对于PM Tool要显示甘特图而言，“甘特图绘制包”是自行开发的，还是采用的第三方SDK，就是一个很重要的技术问题。考虑如下：
一方面，用户根本不关心“甘特图绘制包”的问题，他们只在乎自己的需求是否得到了满足；而项目工期是很紧的，自行开发“甘特图绘制包”势必增加其他工作的压力，为什么不采用第三方SDK呢？
另一方面，短期内决定采用的第三方“甘特图绘制包”可能并不是最优的，所以并不希望PM Tool“绑死”在特定“甘特图绘制包”上。
基于以上分析，架构师会决定：采用第三方SDK，但会自主定义“甘特图绘制接口”将SDK隔离。如图1-8所示。
图1-8  和技术相关的架构方案
有的读者应该已经看出来了，上述设计中采用了Adapter设计模式。
适配器（Adapter）模式
关键字：已存在/不可预见  复用
支持变化：由于Adapter提供了一层“间接”，使得我们可以复用一个接口不符合我们需求的已存在的类，也可以使一个类（Adaptee）在发生不可预见的变化时，仅仅影响Adapter而不影响Adapter的客户类。
结构：
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  软件架构如何具有弹性
1.5.3  重要结论
通过上述分析，我们高兴地看到：组成派和决策派软件架构概念并不矛盾，它们只不过是所站的角度不同罢了；在具体的软件架构实践中，总是同时体现着这两“派”的架构概念。
 
1.6  总结与强调
不积跬步，无以至千里。本章仅是一小步，讨论软件架构的基本概念。虽然本书旨在系统地说明软件架构设计的方法与过程，但首先阐明软件架构的概念是大有裨益的，也是非常必要的。
软件架构概念是多样的。虽然软件架构的概念至今依然没有统一，但作为软件架构师，我们不能“揣着手儿”等待，将软件架构的概念总体上分为组成派和决策派，有利于我们理解软件架构概念的精髓。
本章还通过“用案例说话”的方式，说明了两个架构概念流派虽然角度不同，但却相辅相成。我们既应从“架构＝组件＋交互”的观点中获益，又应运用“架构＝重要决策集”的实践经验，这一点对于软件业界的实践者（而不仅仅是理论研究者）尤其重要。