软件架构---工程理论篇

近期调整了下工作内容划分，也相对有更多的时间思考我们系统架构的设计。（节选自架构设计分析文档）

一、模型

提到模型，大家就直观的说到数据模型，也对。我们再提高一个层次对模型的认识。模型是所研究的系统、过程、事物或概念的一种表达形式。 见百度百科定义

可以理解为我们对所研究事物的一种抽象。 关于抽象，请见 。

说几个系统设计常见的，比如对IO处理抽象，有同步模型、异步模型。还有对线程抽象，Master-Worker模型，Leader-Follower模型。还比如计算机系统中更高一个层次的抽象，从CPU到多进程的抽象，物理内存到地址空间(虚拟内存)的抽象，磁盘到文件的抽象等等。

模型贯穿在软件需求调研，分析，设计，实现，实施的各个环节中。当然，不同阶段也会有不同的模型出现。比如调研阶段的角色模型、分析阶段的对象及对象关系模型；

设计阶段的数据模型、类模型等等，实现阶段的编程模型。

模型要求：

1、概念完整性

2、模型一致性

3、模型稳定性

二、管理复杂度

抽象是管理复杂性的关键。 关于抽象，请见 。

1、必要复杂度则是从软件本身要解决的问题衍生而来，并无法被移除。

如果软件需要提供三十个不同的功能，那么这三十个功能都是必要的，这些功能都必须被实作出来。

2、所谓次要复杂度是指由人们本身所产生的问题，而这类型的问题是可以被解决的。

比如：使用不当的抽象模型等。

3、软件工程面临的问题在于我们已经清除了大部分的次要复杂度，而剩余的（主要复杂度）都无法改变。

主要是我们在软件开发的各个阶段都掌握了相关的模型、工具等。

（程序复杂性：程序复杂度（时间复杂度+空间复杂度），而复杂性是指什么呢？
Pascal语言之父NiklausWirth在70年代提出，
Program= Data Structure + Algorithm
随后逻辑学家和计算机科学家RKowalski进一步提出：
Algorithm= Logic + Control
数据结构和算法都属于控制策略。
程序的本质是：Program= Logic + Control。换句话说，程序包含了逻辑和控制两个维度。
逻辑就是问题的定义，比如，对于排序问题来讲，逻辑就是“什么叫做有序，什么叫大于，什么叫小于，什么叫相等”
程序的本质复杂性就是逻辑，非本质复杂性就是控制。
绝大多数程序不够简洁优雅的根本原因：逻辑与控制耦合。）

抽象的实现形式                      抽象的维度与层次
语言的发展 C,C++
设计模式的产生
IO、线程、事务
架构设计模式
框架 不同层次
中间件 不同用途
软件工程 阶段划分

三、功能与规则

对应上述的定义，可将功能理解为逻辑了，比如说业务功能或是业务逻辑。而规则则是控制了，就是不同的规则下，应用不同的功能。

系统上讲对功能与规则的识别就是程序上要对逻辑与控制的识别。

1、识别标准的建立

2、 功能可定制

3、规则可控制

进而保证最大程度解耦。

四、应用与服务

说到应用与服务，就需要牵涉到架构系统分解了。那架构的定义是什么呢？

其中 IEEE1471-2000 的定义是这样的：系统的架构是系统组件的基本组织形式，

它们之间的关系以及和环境之间的关系，以及指导其设计和演化的原则。

该定义中的系统组件可以理解为架构元素，根据涉及到的系统范围和层次，架构元素可以是子系统、模块、类等等。

从架构设计的动态角度出发，我们可以这样来定义软件架构：通过一系列架构决策，将系统分解为一些架构元素，

并定义这些元素之间的接口和交互关系、集成机制。

架构决策就是在架构设计过程中做出的一系列全局的决定和权衡取舍，

例如将系统拆分成几个子系统、子系统的职责是什么、子系统之间的接口是什么、

采用什么通讯方式和集成机制、采用的开发语言和技术框架等。

（插播下篇 软件架构分解）