基于UC/OS-II的嵌入式构件系统设计
扫描二维码
随时随地手机看文章
近些年来，随着嵌入式产品需求的不断增加，嵌入式软件正变得越来越复杂，而产品的开发周期也越来越短。嵌入式软件开发迫切需要更高效的软件重用手段。
随着软件复用研究成为热点，其核心技术——构件化软件开发方法(CBD)引起了软件工程领域的高度关注，并且在工程应用领域获得了极大的成功。这种开发方法已在办公应用、电子商务、因特网及分布式网络应用中广泛使用；但在嵌入式领域，构件技术仍处于起步阶段，目前没有一个统一通用的构件规范。尽管如此，由于基于构件的软件设计方法能够极好地满足嵌入式软件几乎所有的特性(如定制、裁剪、动态演变等)，有效缩短产品开发周期，这种设计方法无疑将给嵌入式系统的开发带来巨大的好处。
本文尝试将构件化软件设计思想引入嵌入式软件设计中，提出了一种适用于嵌入式软件的基于构件的软件体系结构，并且在常用输入设备键盘的应用实践中，验证了此体系结构的可行性。
1 嵌入式构件技术
1．1 构 件
构件可以视为一个通过接口对外界提供服务或向外界请求服务的黑盒，多个构件可以组成一个更高层次的构件，构件比对象提供了更高的设计抽象。构件是二进制可替换的，这个特点使它们与“类”有着显著的不同。当创建了一个构件的修订版本时，它可以替代同一构件的原先版本，而不必重新编译其他构件。通常，只要一个构件满足相同的接口，就可替换另一个构件，而不必对其他构件做任何修改。因此，构件能够很好地解决更新、维护、分布和复用等诸多问题。
构件具备以下几个基本特征：可复用性、可封装性、组装性、可定制性、自治性、粗粒度、集成特征、接口连接机制。目前，构建模型大致可分为2类：在面向对象的程序设计中，构件即对象，例如JavaBean；在软件体系结构中，构件即结构单元，例如结构描述语言ADL。这些构件模型适合更高层的应用软件，但不适合在嵌入式软件开发中占主导地位的底层系统软件的开发。
1.2 嵌入式构件
1．2．1 嵌入式构件模型
嵌入式构件为实现一定嵌入式系统功能的一组封装的、规范的、可重用的、具有嵌入特性的软件单元，是组成嵌入式系统的功能单位。它是被标准化的、具有重用性、支持QoS的、能够提供实时应用的软件资源。
这里，从嵌入式构件的定义出发，将参考文献中通用软件构件模型作适当的扩展，使其成为适用于嵌入式系统的基本构件模型。
每个嵌入式构件由4部分构成：构件体、属性、接口、依赖关系。图1为基本构件的示意图。构件体实现构件的基本功能，即对外提供的服务；属性描述了构件的基本信息；接口将构件与外界连接，在得到自己需要的服务后，为外界提供服务，每一种接口对应一个不同的服务；依赖关系标识构件间的所有关系，用于实现构件间的拼接。
属性是描述构件某个方面特征的元数据。属性定义了构件查找的方法，可以根据任意一条属性记录快速找到符合条件的构件。由于嵌入式构件的特殊性，可以将嵌入式软件构件的属性分为3 种：描述属性、约束属性和服务质量(QoS)属性。
(1)描述属性
描述属性指的是一般构件都具有的公共属性。常见的描述属性有以下几种。
名称：构件以名称作为标识。
标识：每个构件都对应唯一的ID号，区别于其他构件。
类型：将构件归类，便于检索与管理。
版本号：用于构件的更新。
编程语言：表示构件的实现语言。
构件描述信息：简述构件功能。
表示形式：一个构件可以是源代码、动态链接库、静态链接库，以及文档、图表等形式。
(2)约束属性
约束属性描述构件所依赖的环境。约束属性可分为2类：描述绝大多数构件都具有的公有约束属性和描述单独构件特殊需求的专有约束属性。公有约束属性包括 CPU类型、操作系统、依赖的类库等。专有约束属性包括特殊硬件需求、时间约束和内存需求等。
(3)QoS属性
QoS属性是嵌入式软件构件最重要的要素。为了选取合适的构件来开发嵌入式系统，必须考虑构件的QoS属性，以评估它所提供的性能指标。常见的QoS属性包括平均执行时间、最差执行时间、最优执行时间、内存消耗、功耗、健壮性、可靠性和安全性等。
2 嵌入式软件构件设计
2．1 μC／OS—II嵌入式实时操作系统
μC／0S—II是一个可移植、占先式、实时的多任务内核，以任务为基本处理单位，能同时管理高达63个任务。它实时性强，可靠性高，对处理器以及 ROM、RAM资源的要求不高；另外，它的代码大部分用ANSI C语言编写，只有少部分微处理器专用的代码用汇编语言编写，有利于程序的移植。
2．2 基于构件的嵌入式软件体系结构
一个构件系统的体系结构由一系列定义的构件框架和针对该框架设计的构件间的相互作用关系组成。体系结构是所要实现系统的整体规划，它为构件的组装提供基础框架和接口规范。
目前，嵌入式构件技术研究的核心之一是构件模型和软件体系结构(软件构架)这两个相互关联的问题。不同的构件只能在相应的软件构架中使用，因此基于构件的应用软件设计也可认为是基于体系结构(构架)的软件设计，也称之为基于“构件一构架”的应用软件设计。
根据上述的嵌入式基本构件模型，本文提出了一适用于嵌入式系统的软件体系结构。其中，定义“构件系统”为一特定应用，实现某一具体功能。例如，键盘为一构件系统，显示器也为一构件系统。另外，定义“构件子系统”。它类似于UML中的包概念，代表元素的逻辑分组，将具体的应用从实际问题中抽象出来，同时对各个关注区域进行相对分离，这样做可以独立地分析各个关注点，从而可以更好地分析系统的结构。一个构件子系统可以包含一个构件或者是多个构件的集合。
我们把构件系统构造成抽象层次中的不同部分，最抽象(最接近应用领域)的位于“顶部”，最具体(最接近硬件)的位于“底部”。这样，可以将构件系统从结构上构造为6个独立的层次：应用层、用户接口层、通信层、OS层、硬件抽象层和配置描述层。
每个层次为一个构件子系统，每个构件子系统内包含有一个或多个构件。通过构件间的依赖关系来定位和拼接构件，组装构件子系统，最终生成所需要的构件系统。其中，配置描述层记录构件系统属性、结构说明、相关参数设置与系统类型定义，以及构件系统中各构件的依赖关系。配置描述层作用于其他各个层次，记录了构件系统所需的一切信息，使得构件系统的移植更为方便，同时也易于构件的查询、检索、维护及出入库管理。[!--empirenews.page--]
硬件抽象层实现硬件的驱动、I／O控制，可以用于同一种硬件平台的很多应用中。OS层主要用于与操作系统相关的操作，包括系统任务的创建、消息的创建等。通信层实现数据的传递、数据格式的转换。
用户接口层提供与底层应用相关的基本操作函数、对外接口函数，实现上下层之间的互操作。应用层位于顶层，用于实现用户的应用程序。用户无需关心底层的硬件结构，直接使用用户接口层提供的基本操作函数，即可编程实现自己需要的功能。
层(即构件子系统)的接口是所包含的构件接口的组合。分层接口从上层看是透明的，对下层则是不透明的。在层接口处定义的构件仅对整个层次结构中该层或者该层之上的构件可见。只要符合一定的条件，每一层都可实现相当程度的复用，只需要替换相关的构件即可。
这里，特别要提到“原型”的概念。在各个层中，每个垂直切片仅实现与切片的目的相关的部分。这种实现方案称为“迭代式原型(iterative prototyping)”，每个切片称为一个“原型(prototype)”。实现原型时，每个原型都在其前驱所实现的特性的基础上进行构造。原型的序列根据逻辑上特性的优先顺序来确定。本体系结构引入原型的概念，每个原型包含来自各层的一个或者多个构件，后面的原型构造于先前原型所提供的服务的基础上。每个原型将实现一种特定的功能，逐渐增加功能，最终实现用户应用程序。
分层的结构设计保持了顶层与低层很好的一致性，实现了横向分离；同时，原型的引用使得各层间的连接更为紧密，纵向相连，从而得到集成度更高、更可靠的系统。
3 嵌入式构件系统的实现
3．1 键盘构件系统的实现
嵌入式构件从本质上来说，大部分的工作就是对输入／输出部分进行处理。其构件主要有键盘、前向通道的处理(如A／D处理)、后向通道的处理(如D／A处理)、USB控制、网络控制、液晶显示等。输入／输出软件的代码占据了整个操作系统的相当部分，对嵌入式操作系统来说，这部分的重要性是不言而喻的。其中，键盘更是嵌入式应用程序最常用的器件，因此本文以键盘为例，依据上述体系结构构建了键盘应用模型，配置实现了键盘功能。
图2为键盘构件系统分层体系结构。每层左边显示的“棒棒糖”形状表示层的接口，接口是一组可以从外部访问的类和对象。虚线箭头表示的是依赖关系，每层都依赖于其下一层的包，且构件与构件之间也存在着依赖关系。上层调用位于下层具体一些的层次中的服务，这种单向依赖使得可以在不同的上下文中使用相同的服务，而无需考虑服务的实现方式。同时，由于低一些的层中提供了定义良好的接口集合，可以用不同的底层实现来替换它们，这样，整个构件系统就能更方便地移植到其他的物理环境中。
- 3．2 构件生成集成环境的实现
基于构件系统体系结构，本文拟开发了一构件生成集成环境，如图3所示。该环境可以实现构件系统的自配置、自拼接、源代码自生成，结构清晰，使用简便。随后在该集成环境上，配置键盘构件系统，自动生成源代码，并在博创ARM300实验平台上实现了键盘响应，很好地验证了此体系结构的可行性及优越性。
本文扩展了通用软件构件的概念，提出了适用于嵌入式系统的构件模型；并在此基础上设计了嵌入式软件6层体系结构，采用了分层的结构设计，实现了横向分离，而“原型”的引用使得各层纵向相连。此体系结构不仅实现了软硬件分离，同时也实现了功能的分离，有利于实现稳定性好的嵌入式系统。最后，本文在键盘应用实例中验证了其可行性。随着嵌入式系统的硬件发展，以及基于构件的软件设计方法自身的不断完善，基于构件的软件设计方法必将是未来的发展方向。
下载文档
