logo资料库

嵌入式系统软件架构设计.pdf

第1页 / 共48页
第2页 / 共48页
第3页 / 共48页
第4页 / 共48页
第5页 / 共48页
第6页 / 共48页
第7页 / 共48页
第8页 / 共48页
资料共48页,剩余部分请下载后查看
1. 前言
2. 决定架构的因素和架构的影响
2.1. 常见的误解
2.1.1. 小型的系统不需要架构
2.1.2. 敏捷开发不需要架构
3. 嵌入式环境下软件设计的特点
3.1. 和硬件密切相关
3.2. 稳定性要求高
3.3. 内存不足
3.3.1. 虚拟内存技术
3.3.2. 两段式构造
3.3.3. 内存分配器
3.3.4. 内存泄漏
3.4. 处理器能力有限,性能要求高
3.4.1. 抵御新技术的诱惑
3.4.2. 不要有太多的层次
3.5. 存储设备易损坏,速度较慢
3.5.1. 损耗均衡
3.5.2. 错误恢复
3.6. 故障成本高昂
4. 软件框架
4.1. 嵌入式软件架构面临的问题
4.2. 什么是框架
4.2.1. 软件复用的层次
4.2.2. 针对高度特定领域的抽象
4.2.3. 解除耦合和应对变化
4.2.4. 框架可以实现和规定非功能性需求
4.3. 一个框架设计的实例
4.3.1. 基本架构
4.3.2. 功能特点
4.3.3. 分析
软件
固件
4.3.4. 实际效果
4.4. 框架设计中的常用模式
4.4.1. 模板方法模式
4.4.2. 创建型模式
4.4.3. 消息订阅模式
4.4.4. 装饰器模式
4.5. 框架的缺点
5. 自动代码生成
5.1. 机器能做的事就不要让人来做
5.2. 举例
5.2.1. 消息的编码和解码
5.2.2. GUI代码
5.2.3. 小结
5.2.4. Google Protocol Buffer
6. 面向语言编程(LOP)
6.1. 从自动化代码生成更进一步
6.2. 优势和劣势
6.3. 在嵌入式系统中的应用
7. 测试
7.1. 可测试性是软件质量的一个度量指标
7.2. 测试驱动的软件架构
7.3. 系统测试
7.3.1. 界面自动化测试
7.3.2. 基于消息的自动化测试
7.3.3. 自动化测试框架
7.3.4. 回归测试
7.4. 集成测试
7.5. 单元测试
7.5.1. 圈复杂度测量
7.5.2. 扇入扇出测量
7.5.3. 框架对单元测试的意义
8. 维护架构的一致性
9. 一个实际嵌入式系统架构的演化
9.1. 数据处理
9.2. 窗口管理
9.3. MVC模式
9.4. 大量类似模块,低效的复用
9.5. 远程控制
9.6. 自动化的TL1解释器
9.7. 测试的难题
9.8. 小结
10. 总结
嵌入式系统软件架构设计
目录 1. 前言 ................................................................................................................................... 4 2. 决定架构的因素和架构的影响 ....................................................................................... 4 2.1. 常见的误解 ........................................................................................................... 5 2.1.1. 小型的系统不需要架构 .............................................................................. 5 2.1.2. 敏捷开发不需要架构 .................................................................................. 7 3. 嵌入式环境下软件设计的特点 ....................................................................................... 7 3.1. 和硬件密切相关 ................................................................................................... 7 3.2. 稳定性要求高 ....................................................................................................... 8 3.3. 内存不足 ............................................................................................................... 8 3.3.1. 虚拟内存技术 .............................................................................................. 8 3.3.2. 两段式构造 .................................................................................................. 9 3.3.3. 内存分配器 ................................................................................................ 10 3.3.4. 内存泄漏 .................................................................................................... 11 3.4. 处理器能力有限,性能要求高 ......................................................................... 11 3.4.1. 抵御新技术的诱惑 .................................................................................... 11 3.4.2. 不要有太多的层次 .................................................................................... 11 3.5. 存储设备易损坏,速度较慢 ............................................................................. 12 3.5.1. 损耗均衡 .................................................................................................... 12 3.5.2. 错误恢复 .................................................................................................... 12 3.6. 故障成本高昂 ..................................................................................................... 13 4. 软件框架 ......................................................................................................................... 14 4.1. 嵌入式软件架构面临的问题 ............................................................................. 14 4.2. 什么是框架 ......................................................................................................... 14 4.2.1. 软件复用的层次 ........................................................................................ 14 4.2.2. 针对高度特定领域的抽象 ........................................................................ 15 4.2.3. 解除耦合和应对变化 ................................................................................ 16 4.2.4. 框架可以实现和规定非功能性需求 ........................................................ 16 4.3. 一个框架设计的实例 ......................................................................................... 17 4.3.1. 基本架构 .................................................................................................... 17 4.3.2. 功能特点 .................................................................................................... 17 4.3.3. 分析 ............................................................................................................ 18 4.3.4. 实际效果 .................................................................................................... 23 4.4. 框架设计中的常用模式 ..................................................................................... 23 4.4.1. 模板方法模式 ............................................................................................ 23 4.4.2. 创建型模式 ................................................................................................ 23 4.4.3. 消息订阅模式 ............................................................................................ 24 4.4.4. 装饰器模式 ................................................................................................ 24 4.5. 框架的缺点 ......................................................................................................... 25 5. 自动代码生成 ................................................................................................................. 26 5.1. 机器能做的事就不要让人来做 ......................................................................... 26 5.2. 举例 ..................................................................................................................... 26 5.2.1. 消息的编码和解码 .................................................................................... 26
5.2.2. GUI 代码 .................................................................................................... 27 5.2.3. 小结 ............................................................................................................ 28 5.2.4. Google Protocol Buffer .............................................................................. 28 6. 面向语言编程(LOP) ...................................................................................................... 30 6.1. 从自动化代码生成更进一步 ............................................................................. 30 6.2. 优势和劣势 ......................................................................................................... 32 6.3. 在嵌入式系统中的应用 ..................................................................................... 32 7. 测试 ................................................................................................................................. 33 7.1. 可测试性是软件质量的一个度量指标 ............................................................. 33 7.2. 测试驱动的软件架构 ......................................................................................... 34 7.3. 系统测试 ............................................................................................................. 34 7.3.1. 界面自动化测试 ........................................................................................ 34 7.3.2. 基于消息的自动化测试 ............................................................................ 36 7.3.3. 自动化测试框架 ........................................................................................ 36 7.3.4. 回归测试 .................................................................................................... 38 7.4. 集成测试 ............................................................................................................. 38 7.5. 单元测试 ............................................................................................................. 38 7.5.1. 圈复杂度测量 ............................................................................................ 41 7.5.2. 扇入扇出测量 ............................................................................................ 42 7.5.3. 框架对单元测试的意义 ............................................................................ 42 8. 维护架构的一致性 ......................................................................................................... 42 9. 一个实际嵌入式系统架构的演化 ................................................................................. 43 9.1. 数据处理 ............................................................................................................. 44 9.2. 窗口管理 ............................................................................................................. 44 9.3. MVC 模式 ........................................................................................................... 45 9.4. 大量类似模块,低效的复用 ............................................................................. 46 9.5. 远程控制 ............................................................................................................. 46 9.6. 自动化的 TL1 解释器 ........................................................................................ 47 9.7. 测试的难题 ......................................................................................................... 47 9.8. 小结 ..................................................................................................................... 47 10. 总结 ............................................................................................................................. 48
1. 前言 嵌入式是软件设计领域的一个分支,它自身的诸多特点决定了系统架构师的选择,同时 它的一些问题又具有相当的通用性,可以推广到其他的领域。本课程试图从嵌入式软件架构 设计出发,启发大家对软件架构设计的理解。本课程的很多内容是对谢老师课程在嵌入式领 域的具体阐述。 提起嵌入式软件设计,传统的印象是单片机,汇编,高度依赖硬件。传统的嵌入式软件 开发者往往只关注实现功能本身,而忽视诸如代码复用,数据和界面分离,可测试性等因素。 从而导致嵌入式软件的质量高度依赖开发者的水平,成败系之一身。随着嵌入式软硬件的飞 速发展,今天的嵌入式系统在功能,规模和复杂度各方面都有了极大的提升。比如,Marvell 公司的 PXA3xx 系列的最高主频已经达到 800Mhz,内建 USB,WIFI,2D 图形加速,32 位 DDR 内存。在硬件上,今天的嵌入式系统已经达到甚至超过了数年前的 PC 平台。在软件方面, 完善的操作系统已经成熟,比如 Symbian, Linux, WinCE。基于完善的操作系统,诸如字处 理,图像,视频,音频,游戏,网页浏览等各种应用程序层出不穷,其功能性和复杂度比诸 PC 软件不遑多让。原来多选用专用硬件和专用系统的一些商业设备公司也开始转换思路, 以出色而廉价的硬件和完善的操作系统为基础,用软件的方式代替以前使用专有硬件实现的 功能,从而实现更低的成本和更高的可变更,可维护性。 2. 决定架构的因素和架构的影响 架构不是一个孤立的技术的产物,它受多方面因素的影响。同时,一个架构又对软件开 发的诸多方面造成影响。 软件规模 生命周期 非功能性需求 软件架构 非功能性需求 团队组成 开发模式 下面举一个具体的例子。
摩托车的发动机在出厂前必须通过一系列的测试。在流水线上,发动机被送到每个工位 上,由工人进行诸如转速,噪音,振动等方面的测试。要求实现一个嵌入式设备,具备以下 基本功能: 1. 安装在工位上,工人上班前开启并登录。 2. 通过传感器自动采集测试数据,并显示在屏幕上。 3. 记录所有的测试结果,并提供统计功能。比如次品率。 如果你是这个设备的架构师,哪些问题是在设计架构的时候应该关注的呢? 2.1. 常见的误解 2.1.1. 小型的系统不需要架构 有相当多的嵌入式系统规模都较小,一般是为了某些特定的目的而设计的。受工程师认 识,客户规模和项目进度的影响,经常不做任何架构设计,直接以实现功能为目标进行编码。 这种行为表面上看满足了进度,成本,功能各方面的需求,但是从长远来看,在扩展和维护 上付出的成本,要远远高于最初节约的成本。如果系统的最初开发者继续留在组织内并负责 这个项目,那么可能一切都会正常,一旦他离开,后续者因为对系统细节的理解不足,就可 能引入更多的错误。要注意,嵌入式系统的变更成本要远远高于一般的软件系统。好的软件 架构,可以从宏观和微观的不同层次上描述系统,并将各个部分隔离,从而使新特性的添加 和后续维护变得相对简单。 举一个城铁刷卡机的例子,这个例子在前面的课程中出现过。 简单的城铁刷卡机只需要实现如下功能:
一个 While 循环足以实现这个系统,直接就可以开始编码调试。但是从一个架构师的角 度,这里有没有值得抽象和剥离的部分呢? 1. 计费系统。计费系统是必须抽象的,比如从单次计费到按里程计费。 2. 传感器系统。传感器包括磁卡感应器,投币器等。设备可能更换。 3. 故障处理和恢复。考虑到较高的可靠性和较短的故障恢复时间,这部分有必要单独 设计。 未来很可能出现的需求变更: 1. 操作界面。是否需要抽象出专门的 Model 来?以备将来实现 View。 开始读取刷卡器信息余额充足?Y扣费&开门重置关门定时器超时?关门Y有刷卡动作?YN读取定时器NN
2. 数据统计。是否需要引入关系型数据库? 如果直接以上面的流程图编码,当出现变更后,有多少代码可以复用? 不过,也不要因此产生过度的设计。架构应当立足满足当前需求,并适当的考虑重用和 变更。 2.1.2. 敏捷开发不需要架构 极限编程,敏捷开发的出现使一些人误以为软件开发无需再做架构了。这是一个很大的 误解。敏捷开发是在传统瀑布式开发流程出现明显弊端后提出的解决方案,所以它必然有一 个更高的起点和对开发更严格的要求。而不是倒退到石器时代。事实上,架构是敏捷开发的 一部分,只不过在形式上,敏捷开发推荐使用更高效,简单的方式来做设计。比如画在白板 上然后用数码相机拍下的 UML 图;用用户故事代替用户用例等。测试驱动的敏捷开发更是 强迫工程师在写实际代码前设计好组件的功能和接口,而不是直接开始写代码。 敏捷开发的一些特征: 1. 针对比传统开发流程更大的系统 2. 承认变化,迭代架构 3. 简洁而不混乱 4. 强调测试和重构 3. 嵌入式环境下软件设计的特点 要谈嵌入式的软件架构,首先必须了解嵌入式软件设计的特点。 3.1. 和硬件密切相关 嵌入式软件普遍对硬件有着相当的依赖性。这体现在几个方面: 1. 一些功能只能通过硬件实现,软件操作硬件,驱动硬件。 2. 硬件的差异/变更会对软件产生重大影响。 3. 没有硬件或者硬件不完善时,软件无法运行或无法完整运行。 这些特点导致几方面的后果: 1. 软件工程师对硬件的理解和熟练程度会很大程度的决定软件的性能/稳定性等非功 能性指标,而这部分一向是相对复杂的,需要资深的工程师才能保证质量。 2. 软件对硬件设计高度依赖,不能保持相对稳定,可维护性和可重用性差 3. 软件不能离开硬件单独测试和验证,往往需要和硬件验证同步进行,造成进度前松 后紧,错误定位范围扩大。 针对这些问题,有几方面的解决思路: 1. 用软件实现硬件功能。选用更强大的处理器,用软件来实现部分硬件功能,不仅可 以降低对硬件的依赖,在响应变化,避免对特定型号和厂商的依赖方面都很有好处。 这在一些行业里已经成为了趋势。在 PC 平台也经历了这样的过程,比如早期的汉
卡。 2. 将对硬件的依赖独立成硬件抽象层,尽可能使软件的其他部分硬件无关,并可以脱 离硬件运行。一方面将硬件变更甚至换件的风险控制在有限的范围内,另一方面提 高软件部分的可测试性。 3.2. 稳定性要求高 大部分嵌入式软件都对程序的长期稳定运行有较高的要求。比如手机经常几个月开机, 通讯设备则要求 24*7 正常运行,即使是通讯上的测试设备也要求至少正常运行 8 小时。为 了稳定性的目标,有一些比较常用的设计手段: 1. 将不同的任务分布在独立的进程中。良好的模块化设计是关键 2. Watch Dog, Heart beat,重新启动失效的进程。 3. 完善而统一的日志系统以快速定位问题。嵌入式设备一般缺乏有力的调试器,日志 系统尤其重要。 4. 将错误孤立在最小的范围内,避免错误的扩散和连锁反应。核心代码要经过充分的 验证,对非核心代码,可以在监控或者沙盒中运行,避免其破坏整个系统。 举例,Symbian 上的 GPRS 访问受不同硬件和操作系统版本影响,功能不是非常稳 定。其中有一个版本上当关闭 GPRS 连接时一定会崩溃,而且属于 known issue。 将 GPRS 连接,HTTP 协议处理,文件下载等操作独立到一个进程中,虽然每次操 作完毕该进程都会崩溃,对用户却没有影响。 5. 双备份这样的手段较少采用 3.3. 内存不足 虽然当今的嵌入式系统的内存比之以 K 计数的时代已经有了很大的提高,但是随着软 件规模的增长,内存不足的问题依然时时困扰着系统架构师。有一些原则,架构师在进行设 计决策的时候可以参考: 3.3.1. 虚拟内存技术 有一些嵌入式设备需要处理巨大的数据量,而这些数据不可能全部装入内存中。一些嵌 入式操作系统不提供虚拟内存技术,比如 WinCE4.2 每个程序最多只能使用 32M 内存。对 这样的应用,架构师应该特别设计自己的虚拟内存技术。所谓的虚拟内存技术的核心是,将 暂时不太可能使用的数据移出内存。这涉及到一些技术点: 1. 引用计数,正在使用的数据不能移出。 2. 使用预测,预测下一个阶段某个数据的使用可能性。基于预测移出数据或者提前装 入数据。 3. 占位数据/对象。 4. 高速缓存。在复杂数据结果下缓存高频率使用的数据,直接访问。 5. 快速的持久化和装载。 下图是一个全国电信机房管理系统的界面示意图:
分享到:
收藏