什么是软件架构

 １　   从软件的开发项目谈起
 １.１　软件项目的阶段划分
软件项目的阶段包括：
a.可行性研究阶段
--------------------------------------------> 结束标志：需求书
b.设计阶段（设计目标软件、确定编码人员工期、确定测试指标）
--------------------------------------------> 结束标志：开发／部署的任务清单
c.开发阶段（软件编码和测试）
--------------------------------------------> 结束标志：软件的安装程序
d.部署阶段
--------------------------------------------> 结束标志：验收付款
e.或者还有维护阶段

如果项目是全部完成设计阶段再进入开发阶段，全部完成开发后才开始部署工作，这属于瀑布式开发
开发和部署的划分并不重要。如果开发部署一部分，然后再开发部署另一部分的话，这属于增量瀑布式开发
如果进行大部分的开发工作，或任何部署工作后又确认了新的需求，开发将回溯到设计阶段，这属于迭代式开发（软件重构属于迭代的一种）

／／ １.２　为什么要原型系统
随着软件规模的增加，我们遇见了这样的情况：
跟客户谈需求的时候，你觉得每一条的需求都很容易可以实现，但是最后提交整个软件时却总是延期，而且是缺陷多多，越是大型的项目这种问题就越突
例如，我为了增加通用性将所有的变量都定义为字符串类型，但是字符串到的数字／日期的频繁转化却浪费了大量时间，降低了软件性能
项目组面对的主要问题不再是如何实现需求，而是处理大量需求间的相互制约关系

我们必需在一个软件整体内同时提供所有的需求
如何均衡利弊地满足需求？是有一定规模的软件项目中不得不提的问题
如何平衡了各个需求，得到同时满足所有的需求的软件的原型系统？这就是软件工程的课题

为了均衡利弊，我们经常把所有的需求划分为几个需求主题（而后会发现实现需求主题的解决方案的确是很容易的）
然后我们要以需求主题为单位考虑一些取舍问题，最终得到一个糅合了所有需求的程序实现模型
这个“糅合了所有需求主题的程序实现模型”就是原型系统，原型系统的产生过程就是我们均衡各方需求的过程

> 系统平台的移植性也是一个需求
>  因为客户肯定不只是购买你一套软件
>  也别指望客户总是先买你的软件再配操作系统和数据库
>  那么客户必然会要求能够利用他已有的其它软件，所以平台因素是一个合理需求

／／／／／／／／／／／／／／／／／／
／／ ２　  “满足需求”是软件项目的目标
／／ ２.１　什么是原型系统
原型系统大体上对应于目标软件的“运行时的结构”
我们研究原型系统是为了研究，目标软件运行后进程内有那些数据对象的实例，以及这些数据对象间的交互作用
“实例及它们的交互”的目标是实现需求，我们可以绘制“用例图”来说明需求是如何被满足的

前面说的“糅合了所有需求主题的软件实现”就是软件的原型系统（就是“架构”啦！）
这个原型系统最终会表述为一组相互交互的实例对象，实例对象通过交互触发状态变化，通过状态变化满足需求

原型系统包括三个层次
a.实例对象清单，目标软件运行后进程内所有数据实例
b.解决方案的实现定义，是以“数据实例”为线索的实例间的交互图
c.解决方案的应用分析，是以“需求”为线索的实例间的交互图
d.解决方案的实施计划，是指模块化分析

实例对象清单，是数据实例清单，包括数据实例有那些状态、消息怎么影响状态，比如，状态图

解决方案的实现定义，将描述实例可以接受那些消息、会触发那些消息，比如，接口定义

解决方案的应用分析，是选择确定实例对象、设计实现解决方案的基本依据
设计原型系统的主要矛盾是，满足每个需求主题（设计子系统）和平衡不同的需求（糅合子系统）
其中子系统当然要制约糅合过程，而糅合时也可能对子系统做一些修改

“模块化分析”也是原型系统中的一个部分，因为它和和“应用分析”一样的作用／反作用
但它的反作用力远不如“应用分析”强烈，相对而言，前三者是一个强烈关联的整体，而“模块化”则游离于这个整体之外
“模块化分析”似乎只是在考虑这个“三位一体”对整个项目工程的影响

／／ ２.２　“实例对象清单”与“实例对象的模块化”
原型系统的最终描述却只有“实例对象清单”
在设计阶段中
从需求书中获得“实例对象清单”的过程是“抽象化”
从“实例对象清单”中制定里程碑过程则依赖一个“模块化”的过程

其中“模块化”的过程也直接影响开发阶段和部署阶段工作

“模块化”的目标将是：方便开发部署阶段工作
在开发阶段模块可以作为布置工作任务的单位，我们只能根据工作任务来指定项目的里程碑
在部署阶段，我们长把若干个模块组合成一个产品组件，然后由客户选择要安装的产品组件
另外模块化甚至包括运行实例的合并，比如，ＴＣＰ通讯模块的客户端和服务端的压缩和解压模块，大多会被合并为同一个实例

工作任务作用是观察项目确实在发展，制定里程碑的必然依赖于工作任务的安排

有人你称“模块”为软件架构，但是“模块”基本上只在开发部署阶段有意义
“模块”也可以认为是“实例对象清单”的一个划分（也就是“实例对象清单”的组织分布），可以认为是“实例对象清单”的一个视图

／／ ２.3　其它
记住，贯穿整个软件项目的线索是“满足需求”，项目组存在的原因也是为了满足客户需求
所有的东西都值得以“和这个线索的关系”来重新定义一遍

原型系统不是用来被迭代的源代码，所以我们无须把这组实例对象完整地用源代码表示出来
我们可以在自己的脑海里均衡需求，设计出“原型系统”；也可以在纸面上和其它人交流“原型系统”；或者就把它理解成一个演示系统用计算机工具来表达和处理（这时其中就会包含一些的源代码）

> 严格地说，“应用分析”是设计实现的手段
>  原型系统只包括“实例对象清单”和“实现定义”
>  从原型系统本身我们只需看到需求是如何被满足
>  这是整个项目中都在谈的主题
> 把“应用分析”拿来考虑的原因是：
>  需求的复杂性导致了软件工程的产生
>  原型系统的设计过程的主要矛盾是平衡不同的需求要求

／／／／／／／／／／／／／／／／／／
／／ ３　  “原型系统”与“ＵＭＬ的4+1视图”
／／ ３.１ ＵＭＬ的4+1视图
ＵＭＬ四加一视图是Use Case, Logical, Process, Deployment, Implementation 

前两个视图和原型系统是一致的
Logical View 是“实例对象清单”＋“解决方案的实现定义”
Use Case View 是“解决方案的业务性应用分析”
Process View 是“解决方案的专业性应用分析”(性能和移植要求是需求的一部分)

从系统论的角度看：
Logical View 是解决方案的实现模型(what is the prototype)
Use Case View ＋ Process View 是解决方案的应用模型(how can the prototype settle the problem)

／／ ３.２　Implementation View 在考虑如何设计构架
我觉得Implementation View 只是在考虑程序员的态度
比如交给牛人的技术难题攻关久未成效，我们被迫改变某个设计
就像设计一个机械结构，影响结构的设计因素有很多，但这些因素不是结构本身

／／ ３.３　相对于Implementation 来说Deployment View 更实际意义
比如Oracle 的安装程序，我们可以在一台机器上安装多个DBMS 的实例
这说明安装程序的目标是建立运行时结构的实例

别把安装工作理解成“将软件的编译结果复制到机器上”
那么Deployment View 证明研究运行时结构是中肯的

如果我们把Deployment View 放到楼顶的“软件项目的阶段”中考虑的话，就是部署阶段的使用视图

按照Deployment View 的思路。也许我们也可以为“维护阶段”也设计一个使用模型视图，就叫“Operation Flow View”吧
用户汇报“软件缺陷”时，总是说“在某个状态下，进行某个操作后出错了”
如果我们为每个操作也列出涉及到那些对象和那些消息，一定可以方便维护工作

４　   自动机－－原型系统概念的推广
／／ ４.１　概述
自动机系统是研究信息处理工程的概念，它被归类到“形式语言理论”、“形式语义学”、“计算语言学”等学科中研究
自动机是一台“能回答某个问题的机器”，一个自动机只能回答一个问题，而且对你提问的格式有很多的要求
通俗打个比方说明：
int AutomataAdd (int nA, int nB)
{
  int     nAnswer;
  nAnswer = nA + nB;
  return  nAnswer;
};
这里的AutomataAdd 就是一个加法自动机（只能回答加法问题），你只能按“被加数”和“加数”的格式提问，然后AutomataAdd 将告诉你答案

自动机可以包括以下基本型：
“图灵机型”是面向过程的软件实现模式，前面的AutomataAdd 就是一个例子
“协作机型”是基于对象的软件实现模式，进行研究时可以直接类比于机械系统
“智能机型”是面向对象的软件实现模式，是自动机的乌托邦，它将运用信息论中的所有知识

原型系统就是属于一个协作机型的自动机

／／ ４.２　面向过程的图灵机
图灵机研究中的主题词是：算法（它以句子为研究对象）
一般我们把它归类到计算理论中研究如，算法设计与分析、复杂性理论、可计算性理论等，并行算法；或如，加密算法、数值分析、图象匹配

设计图灵机是“应用推理逻辑”为途径的
关键的问题是要找出从输入（问题）到输出（答案）的推理过程
推理过程其实是我们自己的研究的过程，是以研究工作为中心的“回答问题”的策略

这个推理过程在必须是无歧义地在有限次操作内完成，通过顺序点的概念我们将可以把“这个推理过程”和“程序运行时上下文”一一对应起来

／／ ４.３　基于对象的协作机
协作机研究中的主题词是：购架（它以名词为研究对象）
好象并没有什么学术性的学科研究该机器

设计图灵机是以“研究主语”为途径的
关键的问题是要找出所有的主语，并研究主语间的相互作用关系
主语就是我们的研究对象，我们将跨越研究的手段，认为我们直接接触到术语，这是以研究对象本身的属性为依据的“回答问题”的策略

这个推理过程在必须先构造“低版本的术语系统”，然后在不断地进化演变获得“高版本的术语系统”，迭代是协作机发展的主旋律

／／ ４.４　面向对象的智能机
智能机研究中的主题词是：知识（它以动词为研究对象）
一般我们把它归类到人工智能中研究，如，知识工程、机器学习；或如，实例化抽象

设计图灵机是以“观察现象”为途径的
其实“先明确研究对象再展开研究”的做法（这是协作机的设计途径）在哲学上是错误的
正确的做法是：先观察现象，归纳属性，在有了一定的现象／属性积累以后，再决定是否要就某几个属性组合出一个术语概念