软件架构设计学习笔记(1) 基本概念

软件架构设计学习笔记（1）—基本概念

按照系统工程的思想，人们面对复杂系统时，总是应先考虑宏观再考虑微观。系统越复杂，宏观考虑就越重要，因为越是宏观上的失误，纠正的代价越大。软件系统的研发亦是如此。随着软件复杂程度的日益增大，当代软件设计领域的重点开始由算法、数据结构转向系统的总体结构，软件架构这门学科就应运而生了。
在科学研究领域，软件架构常被称为软件体系结构。英文中倒是没有其他词汇，就是Software Architecture一个词。从目前流行的程度来看，软件架构应是一个主流词汇，所以我还是遵守大多数人的使用习惯来。至少，最直接的好处是，我做笔记时，少打好多字哦

。
学习软件架构设计，个人最想弄明白是这么几个问题：

软件架构是什么？它在软件开发过程中处在什么样的地位？到底哪些工作是架构师负责的？
如何来开展软件架构的设计工作？
如何来表达软件架构的设计结果？

我希望通过几篇连续的短文，逐一总结我对这几个问题的看法，希望高手们批评指正。
1.1 软件架构的定义
软件架构的定义非常之多，一定程度上也反映了这是一门百花齐放的新学科。SEI的网站上收集了大量的定义，并进行了分类，感兴趣的话可以看看网址：http://www.sei.cmu.edu/architecture/start/glossary/index.cfm。温昱在他的《软件架构设计》一书中还把定义分为了决策派和组成派。
组成派代表Mary Shaw的定义
软件系统的架构将系统描述为计算组件以及它们之间的交互。
这个定义中，较难理解的是组件（Component）这个词，因为组件这个词实际含义很泛。通常开发人员看到的诸如EJB组件、COM/DCOM组件等都是指的一种可运行体。但是，这里的组件应该不仅仅是指可以运行的东西，而是指的某种结构元素。例如在软件架构的部署视图中，“组件和交互”是指节点及其通信机制；在软件架构的模块视图中，“组件和交互”是指模块及其依赖关系。



决策派代表RUP（Rational Unified Process）的定义
软件架构包含以下问题的重要决策：

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




在第一次软件架构国际研讨会，Mary Shaw曾将软件架构的定义分为四大类型：

结构模型：软件架构由组件以及连接组成，通常还包括其他诸如风格、原则、约束、语义等相关方面。
框架模型：重点关注整个系统的内在结构，而不是组成。这中结构通常只有一个。
动态模型：强调系统的行为质量。
过程模型：聚焦于软件架构的构造过程。

最现代的定义应是书《Documenting
Software Architectures: Views and Beyond 》（第二版）中的定义：

The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.

中文意思应是：软件架构是系统推导所需要的一个结构集，这些结构由软件元素、它们之间的关系及其属性组成。这里的系统推导主要是指架构分析，也就是说，系统质量属性应可以从软件架构推导出来。

目前的现实情况是，软件架构的定义繁多，各种定义之间既不能相互包含，也不存在矛盾。事实上，各种定义反映了各软件架构研究社区的兴趣点和重点。如果将各类定义综合，则可以形成对软件架构的一个整体观念。

[b]1.2 软件架构是什么？[/b]

综合来看，我对软件架构的整体观念是：软件架构是关于软件设计的一组宏观决策，其显式表达形式通常是结构及其相关说明的集合。

具体来说，软件架构是：

软件架构属于传统软件工程的设计领域，是分析与设计的一座桥梁。
软件架构是一种顶层设计。
软件架构是一个结构的集合。