一场争论引发的思考

写这篇文章的起点出于一次系统设计讨论会,A和B因为意见不统一而争执不下.非要让我选择一种方案而推翻另一种方案,记录于此.权当对所谓架构的反思.

首先说一些软件工程方面的理论和指导性的原则,和从我个人职业生涯对软件工程和设计模式的一些实践性的理解.虽然有些是理论性的东西,但是具有指导意义.

 

一: 架构的定义

IEEE标准将架构定义为”系统的基本组织结构,包括它的组件,组件之间的相互关系,环境,以及设计和演进的指导原则”

 

红色字体是我个人认为的3个关键字,每一个关键字是一层意思,第一层就是系统是由逻辑上的组件和模块组成的,是结构化的,静态的描述.第二层意思就是架构要描述出这些组件和模块之间的关系,是动态的.第三层就是架构是增量式的,是不断演进和迭代的结果.

 

3者之间息息相关,缺一不可,缺少了组件,架构就是不完整的.而缺少了相互关系,架构就是混乱的,缺少了演进和指导原则,一上来就想到大而全,是没有意义的,不切实际的,这样的架构是纸上谈兵.

 

二: 软件工程的一般过程

从立项之后开始,一个完整的软件工程的生命周期包括:

1: 需求

2: 分析与设计

3: 实现 

4: 单元测试 集成测试

5: 部署

6: 项目管理 配置和変更管理

 

第一个生命周期就是需求,架构就是围绕需求来设计的,一切不以需求为目的的架构,都是空谈.下面以我们的可信平台为例,对系统架构的一部分做一个简要设计.下面这段话引自孙总邮件回复

 

要考虑整体稳定性、性能、扩展性、可控性、可维护性等，也要考虑可信架构的建立，可信架构就是软件基（动态度量是核心，动态度量包括了程序度量、访问控制、沙箱等，软件基还包括平台支撑机制），是安全体系的基础。

 

其实这段话应该把后面的部分放到前面来强调,

 

简单来讲,需求分为功能性需求和非功能性需求,从上面的话中可以概括出下面的图

 

 

2.1 功能性需求

从概念将系统分层,可以分为以下几个Package

拿程序度量Package来说,度量模型分为静态度量和动态度量,静态度量包括身份认证检测,代码特征检测,用户空间行为检测.而动态度量又包含内存完整性度量.等等.

 

注意:上面的图对模块的划分粒度已经是很细了.需求分析应该到第二层就已经结束.

第三层已经涉及到系统设计.而对于系统设计来说,第三层的模块划分粒度又相对很粗.要在第三层将模块更加细化,抽象出更加细小的组件,进而抽象出各个接口,对象,这就是关键字一:组件

然后就该进入了详细设计.就是进行接口和对象一级的抽象设计.剩下就是编码,测试等等.可以看出,系统就是在不断的进化和演变当中.这就是关键字三之一:演化

2.2 非功能性需求

 

 

上面是A的文档,定义框架既定目标,在这个目标中,我没有看到任何和当前平台刚性需求有关的字样,框架就是主要解决功能性需求同时兼顾非功能性需求.我只能认为这是一个非功能性需求.是框架的一部分,而不是一个完整的框架.从软件工程的生命周期的角度来说,没有从需求开始,出发点就已经错了.

 

接下来就是讲对象管理,组件管理等等,这样的一个组件管理模型,我个人认为应该叫做 类似于COM机制的对象组件管理器.而不是一个框架,这样的依据是什么呢?为什么要这样划分?有它存在的必要性吗?个人认为是可有可无的东西.没有这个组件管理器,对我的系统也没有影响,我完全可以用另一套很简单的组件管理器来替代它.因为它没有解决任何功能性的刚性需求.这是可以没有它的理由.没错吧?但是它又有他存在的合理性,这就是关键字三之二:设计的指导原则.从这个角度来推理,上面的功能性需求到最后详细设计会产生一堆庞大的对象啊接口啊dll的组件,这么多的组件对于后续的开发和扩展,都是一个挑战,这时候就需要一个组件管理器来进行统一的调度管理,这就是这个组件管理器可以存在的合理性的抽象指导原则

 

从上面分析,直接跳过需求分析而产生的这个对象管理器,是没有理论指导的.它不是一个框架,而是框架后期详细设计中的一个组件而已.因为这个组件可能很复杂,所以也可以称为一个框架,组件和框架,本身就是一个很虚的东西,看个人理解了.但是对于平台来讲,这就是一个组件.

 

后来才用一张图简单的带过了系统的功能性的刚性需求,这样子是本末倒置.

 

至于关键字二:相互关系,这就是B的设计所包含的东西了.将各个组件之间的相互作用封装起来,同时提供了组件管理和其它一些的功能,但是里面也有设计的缺陷.这在之前就已经讨论过了.不再细说.

 

2种架构思想:A是典型的面向对象型的设计思想,一切以接口为出发点,各个组件之间通过接口调用来实现.由组件管理器实现统一的调度.这种思想的好处是高度的可扩展性,单元测试的简易性.不过这是面向对象本身就具有的特征,而不是这个组件管理器所产生的特征.而这个组件管理器存在的问题就是对象管理的复杂性,以及对象生命周期的管理,一旦组件管理器返回对象产生错误,所有的调用都会出问题.这是对A架构的一个考验.

 

B是面向消息的设计思想,所有的组件通过消息调用来进行交互.这样设计的好处是交互的简易性.缺点是单元测试的繁琐和不方便,相对于面向对象来讲,缺少接口级调用的灵活性.

 

2种思想,对于一套系统来说,完全不冲突,没有必须推翻哪一种思想.面向对象和面向消息的优点和缺点正好对立和互补,完全可以取长补短,合理的存在于平台中.

 

下面给出我个人的中立而不是中庸的建议:这在以前的邮件中已经说明过了.再重复一下吧

1: 将A的组件管理器替换掉B现有的组件管理,这样可能有些难度,但是是可行的.或者B重新实现一套组件管理.

2: 去掉现有的XML文件传输载体.采用结构体+联合体,进行消息传输.

3: 将第二步中的XML载体单独提取出来一个模块或者一个工程,将代码膨胀从平台中转移到测试工具中,解除不必要的耦合,提高平台稳定性,供测试人员进行可视化测试.

4: 其它的想起来再说.....

 

后话 软件工程是一个庞大无比的东西,上面我们几个人所做的工作都只是冰山一角,如何在保证产品刚性需求的前提下,设计出可复用的可扩展的架构,是需要依赖软件工程的理论,结合软件工程师的智慧和实践,不断的迭代出来的.

 

以上是我这个伪”砖家”根据个人工程实践经验和软件工程理论得出的思想和建议,欢迎交流

 

推荐的关于软件工程的读物:

首先肯定是UML创始人Grady Booch的代表作之一 << Object-Oriented Analysis and Design with Applications >>

 

然后是4人帮的<< 设计模式：可复用面向对象软件的基础 >>

 

最后是国内的一本 << [大象Thinking.in.UML].ThinkingInUML>>