欢迎访问电子工程网!   登录 | 免费注册 ]   

bmr_bmr的个人空间 http://www.eechina.com/space-uid-8416.html [收藏] [复制] [分享] [RSS]

博客

嵌入式软件开发的变革

已有 857 次阅读2010-3-25 15:23 | 关键词:

嵌入式软件开发的变革

作者:Atollic 销售和市场副总裁   Magnus UNEMYR

译者:北京麦克泰软件技术有限公司   刘毅

软件开发不只是写代码

随着处理器日益强大,对于额外软件功能的需求也越来越大。嵌入式系统软件的尺寸大小每年都在增长,结果带来了一些新的问题。

从事软件行业的人员承认,开发软件最大的问题不再是如何写代码;在很多软件产品中,问题更多地涉及到管理渐增代码的复杂性、渐增的开发成本和时间延迟、分离的项目团队和太多的低质量代码。

尽管如此,令人惊讶的是,20年前所创立的软件开发工具,几乎所有的集成开发环境仅仅关注于传统的编辑、编译以及调试方面。

好的开发工具能够解决开发人员在每天工作中遇到的很多问题。使用它,开发时间能够减少,软件质量能够提升。

 

传统工具

诚然,在过去的20年中工具改进了许多,但它仍然主要是传统的编辑、编译以及调试步骤。当然今天的编辑器好用多了。开发人员期待的一些特性,如代码块展开/折叠、C/C++代码注释的原文的拼写检查、可视化功能、代码结构的导航等等依然没有。

今天,嵌入式编译器处理C/C++,虽然改善了代码尺寸,但这在强大的32位处理器中显得并不重要。不同厂商编译器的尺寸在大多数情况下区别很小,免费的GNU编译器甚至在很多情况下比商业的编译器好。调试器虽然会好一些,但它的功能还主要是在执行代码和变量检查。

通过更广的角度来寻求工具支持,开发团队可以开始处理项目费用的问题,项目延迟的问题以及导致公司交付低质量软件产品的问题。

现代化的C/C++工具应该扩大传统特性(编辑,编译和调试功能),新的特性包含了设计和文档的支持、团队合作、代码变化跟踪以及提高软件质量的更好工具。

写代码前思考一下

改善工作的方法之一是在开始编码前更好地描述什么应该被开发。这个可以是UML,一个标准的软件可视化的图像语言 ,它使用一些不同类型的图表。图表类型是类图表、活动图表、程序图表、状态图表等等。

Atollic TrueSTUDIO是一个C/C++工具,集成了图形化的UML编辑器,给开发人员更好的机会捕捉需求,同时模拟了静态结构和应用程序的动态行为。

   嵌入式系统的UML工具一直以来都非常昂贵,并且在整个开发部门经常需要改变工作方法。一个非常便宜和渐进的方式是选择一个一开始就带有UML编辑器的C/C++环境。

管理代码

很多经验丰富的开发工程师经历着项目需求的变化,代码需要扩展和修改。然而经验丰富的开发人员一旦离开了这个项目,过了一段时间,就没有人知道这代码是如何工作的,而且没有人记得什么时候修改过代码或者代码以前是什么样子的。

所有公司应该使用的一个好的解决方法就是版本控制系统,实质上它是一个包含所有项目文件的数据库,包含了从项目开始的所有旧的版本。一个好的版本控制系统不应该仅仅存储早期版本的文件,同时也存储了整个路径架构。

一个版本控制系统提供了完整的追溯功能,非常容易地计算出哪个程序代码行在什么时候、被谁、为什么添加或修改了。同时也容易恢复到早期版本,创建类似的代码库将来再次被合并。发布的版本可以被贴上标签,这样就容易地为一个特定早期发布版存储源代码。

版本控制系统对于在项目中几个工程师同时工作是必须的,特别是当他们在不同的地方工作。

有了版本控制系统,几个工程师可以同时工作在同样的源代码文件中,并且相互检查。其他的开发人员可以从服务器上的最新变化同步他们的本地拷贝工作。这样所有的开发人员能够访问最新的变化,而不依赖于是谁做了这个变化。

版本控制系统通常作为团队合作工具被划分,在几个开发者的项目中它是非常有用的。但是版本控制系统同样在单个开发人员的小项目中是有用的,它提供了完整的追溯功能,并且能够容易地找到代码的早期版本,一直跟踪变化。

市场上有很多流行的版本控制系统,有商业的,也有开源的。最流行的一个是CVS,但它现在已经大量地被SVN取代。Subversion是开源的,免费的,成功被全球很多公司使用,Subversion配置在团队的服务器上或者一个单一开发人员的计算机上。

一个现代化的C/C++集成开发环境应该集成进来流行的版本控制系统。图2显示了Atollic TrueSTUDIO中对于Subversion的完整支持。

 

管理特性请求和缺陷报告

同样保持对代码变化的跟踪是重要的,开发团队应该保持对特性需求和bug报告的跟踪。这些问题典型地存储在服务器上的一个中央问题管理系统中。有几个bug数据库系统是免费的,如Bugzilla  Trac.

一个现代化的C/C++开发工具应该可以连接到一个bug数据库服务器,并且提供完整的特性,如bug报告的列表,搜索,编辑。

一些工具甚至集成了代码编辑和调试特性到bug数据库系统中去了,如 Atollic TrueSTUDIO会记得哪个文件被打开了,上次的工作被记录到一个特定的bug报告中。如果这个bug报告以后被激活了,编辑器将会自动打开上次工作打开的那个C/C+文件。

其他集成到Atollic TrueSTUDIO产品的特性,使用附到bug报告中的屏幕截图记录调试器的状态。调试器的屏幕截图可以用箭头,文本来注释说明。下一次有人打开这个bug报告,屏幕截图作为额外的信息

 

用代码审查来消除错误

使用调试器寻找错误往往是必要的。但是修补错误,首先需要把错误检测出来。 在测试诊断启动之前比在产品交付给客户之前找到错误要便宜的多。

开发安全系统软件的公司(如航空航天行业)擅长于发现软件错误,甚至在产品测试阶段之前找到错误。通过使用严格的规格定义和代码审查,开发者相互研究代码,确定潜在的问题。

代码审查是被看做最便宜和最好地提高软件质量方式之一。但令人惊讶的是,事实上直到现在的嵌入式行业才有工具支持它。

现代化的C/C++开发环境应该集成了代码审查功能,Atollic TrueSTUDIO已经做好了这个功能,使用这个工具,项目经理或者是团队成员可以容易地通过定义项目中应该加入的文件和审查者来创建一个代码审查窗口,

使用自己的电脑,审查者可以在编辑器中研究源代码文件,在编辑器里双击代码,加入审查注释到不同的源代码行中 。审查注释被分为逻辑错误,可移植性问题,可维护性等,又以优先级分为关键的,主要的,次要的。

在审查的第二阶段,所有的审查者一起坐下讨论所有不同的审查注释,有选择地分派他们到不同的团队成员去修正。

使用这个简单的方法,可以提高软件质量。审查者可以在他们自己的时间里研究代码,所有参加了代码审查会议的成员通过同事间相互学习,提高了他们的编码技巧 。现在代码审查功能已经集成到了专业的C/C++环境,不再有任何理由不使用这个方法,至少对于大多数应用程序的关键部分。

 

什么代码已经被测试过了?

代码覆盖率分析通常用来研究哪部分的代码已经被测试过了。有许多不同类型的代码覆盖率分析,从非常简单的分析到非常严格的分析类型。

代码覆盖率分析通常被正式的分类。更先进的代码覆盖率分析类型(如下面描述地MC/DC)经常用来开发安全关键软件。

例如,RTCA DO-178B(飞行安全关键软件开发的一个标准)需要对航空航天软件最关键部分进行MC/DC测试。在那个部分,一个软件错误可以导致灾难性的损失,飞机,火箭或者人类生命。

很多航空航天工业外的项目会受益于对于测试的良好控制,特别是对于生产量大的公司或者对于很难在该领域进行产品升级的公司。同样对于那些产品,供应商保持其良好信誉 ,坏的声誉对于公司来说需要付出很大的代价。

因为这些,代码覆盖率分析应该被用来证实软件在交付给客户之前是否被测试的足够好。不同类型的代码覆盖率分析举例如下:

1. 函数覆盖,在执行代码期间,所有的C/C++函数是否被调用?

2. 函数调用覆盖,执行一个特定的C/C++函数的调用。

3. 语句覆盖。执行了哪些代码行?这个测试并不是说所有关于为什么或者在什么情况下执行一个代码行。

4. 分支覆盖包含了正确和错误的部分,如果语句(或者更通常的,所有可以选择的分支中的执行路径)执行了。

5. 修订的条件/判定覆盖。这是代码覆盖中非常高级的类型。完成代码的MC/DC覆盖率,以下条件在测试中,必须至少执行一次

1:每个判定尝试输出每一个可能的结果

2:判定中的每个条件呈现每一个可能的结果

3:每个入口和出口点被调用

4:每个判定中的条件用来独立地显示影响判定的结果

没有工具的支持,MC/DC-级别的代码覆盖率分析当然是非常复杂的。然而有这样的自动化工具,如Atollic TrueSTUDIO,这个工具运行在目标系统上,在PCC/C++环境中呈现出MC/DC分析结果。

代码覆盖率分析运行在目标系统上这个事实是重要的,如果运行在一个PC的模拟环境中,就不能和目标系统适当的交互。很多代码执行路径会不同,这降低了分析的价值。

 

总结

软件行业发展迅速,windows软件的开发人员拥有很强大的工具给他支配。同时,嵌入式软件的开发工具几年以前仍然或多或少处在同样的水平,仅仅提供编辑,编译,调试等特性。

是给嵌入式系统开发人员提供一些合适的工具的时候了,这些工具以完整的产品形式,覆盖了大范围的问题。这种工具已经上市,将会给开发项目更好地交付高质量的设计软件。



路过

鸡蛋

鲜花

握手

雷人

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 立即注册

回顶部