接口-数据流-系统运行

        软件设计要分层，就像TCP/IP七层协议一样，下层为上层提供服务，层间只有接口函数作为层间交互的唯一通道。不能跨层访问。这些是基本的软件设计中的原则，老生常谈而已。单单看这些，丝毫没有一点新意，也没有太多的实际指导作用。近来工作中分析用到的软件架构，发现一些比较有意义的东西，与大家分享一下。

 

         软件分层，比如分为LAP应用层，DAT数据表示层，LDB驱动层，暂时分为这三个层，不多也不少，便于把问题说清楚。层间有接口相连，接口本质上也就是函数，一般函数都是有参数的，这些参数是什么呢？就是我要讲的中心：数据流。从这个角度可以说，数据流可以认为是接口的本质，接口函数的调用也就是将数据流在各个层间传递。那么动态看来，可以将软件架构想象成这样：三个层相当于三层楼，接口相当于电梯，电梯里面当然会有人，会有货物，也可能是空的，电梯上上下下，实际各个层间的数据交互。接口不过是个载体，数据流才是核心，数据流体现了各个模块的共性。电梯是唯一的上下层间的通道，当然，你说我从外面爬窗户进去，那也是可以的，不过那是反设计的，是Hacker的行为。

         再深入一些，接口实现数据流的传递，那么什么时候数据流开始传递呢？什么时候传递结束呢？开始和结束有什么要求吗？有什么标记吗？接口函数如何设计的呢？这又关系到模块的设计原则。还是以LAT，DAT，LDB三层来说，比如LDB中的CAN驱动模块，它负责接收和发送CAN报文，如何设置LDB和DAT间的接口呢？一般有两个思路：

A：设置一个缓冲区，将接收到的消息存储到缓冲区中，提供一个函数，由上层来提取缓冲区中的消息，这是比较典型的设计方式，下层被动，完全是上层访问下层，而下层不能访问上层。

B：在CAN的中断接收函数中，调用一个回调函数，这个回调函数由上层来提供，实现将接收到的CAN报文拷贝到上层DAT，根据回调函数形式不同，实现不同控制功能。

         对比这两个实现方式，各有优劣，A设计在中断中做的事情比较少，负载较低，但是要提供缓冲区，且要管理缓冲区，报文过快的话，很容易导致缓冲区溢出，且上层从缓冲区提取数据时，这时可能又有新的报文写入缓冲区（典型地生产者消费者问题），维护起来比较麻烦。B设计在中断中调用回调函数，此函数由上层提供，你可以自由设计这个回调函数的形式，以实现充分控制，比如回调函数调用后，设置一个标志位或发送一个消息或激活一个任务让DAT层的其它模块对数据开始分析，极端一点也可以这样，一路回调函数直接LAP层，也就是说，中断引起了一系列的回调函数，包括DAT层和LAP层的，这个时候中断作为系统运行的唯一动力，连日常的周期性任务都省略了。当然也有缺点，中断中执行动作过多，会导致负载上升，甚至影响其它中断响应。比较良好的设计是，回调函数将数据拷贝到DAT的缓冲区，然后再激活一个任务来处理这些数据。

 

         从上面分析可看出，接口的设计可以是正向的，下层提供函数给上层使用，也可以是逆向的，由上层提供函数供下层来使用。一般来说，正向时表示有所需则有所取，上层用时才取，有一定的周期性，实时性不高，有点慢条斯理的味道。而逆向时则是事件型的，发生了就通过回调函数通知上层，实时性比较高。

 

        从另外一个角度来说，你可以认为是数据流通过接口从LDB传递给了DAT层，通过中断函数中的回调函数实现，传递到DAT层以后，通过回调函数接口的设计进行下一步动作。那么，我可以认为数据流是系统运行的一个动力（你说中断也可以，但是中断只是硬件概念在LDB中才会有，DAT和LAP中没有中断的概念），底层由中断驱动将数据流传递到DAT层，DAT层再通过其它手段比如启动一个新任务，或通过周期性任务，这就是系统运行动力切换，这些任务作为新的动力源，将数据流继续传递到LAP层。无论系统运行动力如何切换，数据流始终是系统运行动力处理的核心。

 

        先写到这里吧，语言水平不行，表达不清楚，且自己思想也不太成熟，不对的地方，欢迎指正。

 

 

有个体会：

1：软件架构设计是个复杂，难以理解，要悟性的活，不深入思考是无法得到其精华的。平时工作一点小悟，愿与同行交流。

2：架构设计是个全息的系统，任何一个架构相关的名词都可以映射出整个架构。