1、 嵌入式系统软件架构设计张志明目录1. 前言 .42. 决定架构的因素和架构的影响 .42.1. 常见的误解 .52.1.1. 小型的系统不需要架构 .52.1.2. 敏捷开发不需要架构 .73. 嵌入式环境下软件设计的特点 .73.1. 和硬件密切相关 .73.2. 稳定性要求高 .73.3. 内存不足 .83.3.1. 虚拟内存技术 .83.3.2. 两段式构造 .93.3.3. 内存分配器 .103.3.4. 内存泄漏 .113.4. 存储设备易损坏，速度较慢 .113.4.1. 损耗均衡 .113.4.2. 错误恢复 .123.5. 故障成本高昂 .124. 软件框架 .134.1.
2、嵌入式软件架构面临的问题 .134.2. 什么是框架 .134.2.1. 软件复用的层次 .134.2.2. 针对高度特定领域的抽象 .144.2.3. 框架可以实现和规定非功能性需求 .154.3. 一个框架设计的实例 .164.3.1. 基本架构 .164.3.2. 功能特点 .164.3.3. 分析 .164.3.4. 实际效果 .204.4. 框架设计中的常用模式 .204.4.1. 模板方法模式 .204.4.2. 创建型模式 .214.4.3. 消息订阅模式 .214.4.4. 策略模式 .224.5. 框架的缺点 .225. 自动代码生成 .235.1. 机器能做的事就不要让人来
3、做 .235.2. 举例 .235.2.1. 消息的编码和解码 .235.2.2. GUI 代码 .245.2.3. 小结 .255.2.4. Google Protocol Buffer.256. 面向语言编程(LOP) .276.1. 从自动化代码生成更进一步 .276.2. 优势和劣势 .296.3. 在嵌入式系统中的应用 .297. 测试 .307.1. 可测试性是软件质量的一个度量指标 .307.2. 测试驱动的软件架构 .317.3. 系统测试 .317.3.1. 界面自动化测试 .317.3.2. 基于消息的自动化测试 .337.3.3. 自动化测试框架 .337.3.4. 回归
4、测试 .357.4. 集成测试 .357.5. 单元测试 .357.5.1. 圈复杂度测量 .387.5.2. 扇入扇出测量 .387.5.3. 框架对单元测试的意义 .398. 维护架构的一致性 .399. 一个实际嵌入式系统架构的演化 .409.1. 数据处理 .419.2. 窗口管理 .419.3. MVC 模式 .429.4. 大量类似模块，低效的复用 .439.5. 远程控制 .439.6. 自动化的 TL1 解释器 .449.7. 测试的难题 .449.8. 小结 .4410. 总结 .451. 前言嵌入式是软件设计领域的一个分支，它自身的诸多特点决定了系统架构师的选择，同时它的一
5、些问题又具有相当的通用性，可以推广到其他的领域。本课程试图从嵌入式软件架构设计出发，启发大家对软件架构设计的理解。本课程的很多内容是对谢老师课程在嵌入式领域的具体阐述。提起嵌入式软件设计，传统的印象是单片机，汇编，高度依赖硬件。传统的嵌入式软件开发者往往只关注实现功能本身，而忽视诸如代码复用，数据和界面分离，可测试性等因素。从而导致嵌入式软件的质量高度依赖开发者的水平，成败系之一身。随着嵌入式软硬件的飞速发展，今天的嵌入式系统在功能，规模和复杂度各方面都有了极大的提升。比如，Marvell 公司的 PXA3xx 系列的最高主频已经达到 800Mhz，内建 USB,WIFI,2D 图形加速,32
6、 位 DDR 内存。在硬件上，今天的嵌入式系统已经达到甚至超过了数年前的 PC 平台。在软件方面，完善的操作系统已经成熟，比如 Symbian, Linux, WinCE。基于完善的操作系统，诸如字处理，图像，视频，音频，游戏，网页浏览等各种应用程序层出不穷，其功能性和复杂度比诸 PC 软件不遑多让。原来多选用专用硬件和专用系统的一些商业设备公司也开始转换思路，以出色而廉价的硬件和完善的操作系统为基础，用软件的方式代替以前使用专有硬件实现的功能，从而实现更低的成本和更高的可变更，可维护性。2. 决定架构的因素和架构的影响架构不是一个孤立的技术的产物，它受多方面因素的影响。同时，一个架构又对软件
7、开发的诸多方面造成影响。软件架构软件规模生命周期非功能性需求非功能性需求团队组成开发模式下面举一个具体的例子。摩托车的发动机在出厂前必须通过一系列的测试。在流水线上，发动机被送到每个工位上，由工人进行诸如转速，噪音，振动等方面的测试。要求实现一个嵌入式设备，具备以下基本功能:1. 安装在工位上，工人上班前开启并登录。2. 通过传感器自动采集测试数据，并显示在屏幕上。3. 记录所有的测试结果，并提供统计功能。比如次品率。如果你是这个设备的架构师，哪些问题是在设计架构的时候应该关注的呢？2.1.常见的误解2.1.1. 小型的系统不需要架构有相当多的嵌入式系统规模都较小，一般是为了某些特定的目的而设
8、计的。受工程师认识，客户规模和项目进度的影响，经常不做任何架构设计，直接以实现功能为目标进行编码。这种行为表面上看满足了进度，成本，功能各方面的需求，但是从长远来看，在扩展和维护上付出的成本，要远远高于最初节约的成本。如果系统的最初开发者继续留在组织内并负责这个项目，那么可能一切都会正常，一旦他离开，后续者因为对系统细节的理解不足，就可能引入更多的错误。要注意，嵌入式系统的变更成本要远远高于一般的软件系统。好的软件架构，可以从宏观和微观的不同层次上描述系统，并将各个部分隔离，从而使新特性的添加和后续维护变得相对简单。举一个城铁刷卡机的例子，这个例子在前面的课程中出现过。简单的城铁刷卡机只需要实
9、现如下功能：开始读取刷卡器信息余额充足 ?Y扣费 CMySimpleClass();.private:int SomeData;CMyCompoundClass:class CMyCompoundClass public:CMyCompoundClass();CMyCompoundClass();.private:CMySimpleClass* iSimpleClass; ;在 CMyCompoundClass 的构造函数里初始化 iSimpleClass 对象。CMyCompoundClass:CMyCompoundClass()iSimpleClass = new CMySimpleCla
10、ss; 当创建 CMyCompoundClass 的时候会发生什么呢？CMyCompoundClass* myCompoundClass = new CMyCompoundClass;1. 为 CMyCompoundClass 的对象分配内存2. 调用 CMyCompoundClass 对象的构造函数3. 在构造函数中创建一个 CMySimpleClass 的实例4. 构造函数结束返回一切看起来都很简单，但是如果第三步创建 CMySimpleClass 对象的时候发生内存不足的错误怎么办呢？构造函数无法返回任何错误信息以提示调用者构造没有成功。调用者于是获得了一个指向 CMyCompoundC
11、lass 的指针，但是这个对象并没有构造完整。如果在构造函数中抛出异常会怎么样呢？这是个著名的噩梦，因为析构函数不会被调用，在创建 CMySimpleClass 对象之前如果分配了资源就会泄露。关于在构造函数中抛出异常可以单讲一个小时，但是有一个建议是：尽量避免在构造函数中抛出异常。所以，使用两段式构造法是一个更好的选择。简单的说，就是在构造函数避免任何可能产生错误的动作，比如分配内存，而把这些动作放在构造完成之后，调用另一个函数。比如:AddressBook* book = new AddressBook()If(!book-Construct()delete book;book = NULL;这样可以保证当 Construct 不成功的时候释放已经分配的资源。在最重要的手机操作系统 Symbian 上，二段式构造法普遍使用。3.3.3. 内存分配器不同的系统有着不同的内存分配的特点。有些要求分配很多小内存，有的则需要经常增长已经分配的内存。一个好的内存分配器对嵌入式的软件的性能有时具有重大的意义。应该在系统设计时保证整个系统使用统一的内存分配器，并且可以随时更换。
