软件工程之Java实现策略(2)

第5章 代码编写

为了保证接口定义的一致性、代码的可读性以及工程质量,在同一个移植工程中协作的程序员必须遵守相同的移植策略。这些策略应当是一种全局的约定,而且应当以文件的形式固定下来。移植蓝图就是包含了这些策略以及其他相关的内容的一系列文件,它应当包括以下几个部分。
（1）语法结构的移植标准。进行移植时,如何将源语言的结构以目标语言进行重写。以Ｃ++到Ｊａｖａ的移植为例,这些移植标准有的是易见的,例如相应类型以及流程语句的移植。有些则需要改变原来语言结构,甚至逻辑结构,例如对多继承的移植。有的移植方案是多种的,例如对Ｃ++中输入输出参数的移植。移植蓝图中必须指出源工程中涉及到的所有语言结构以及相应的移植方式,对有多种移植方案的应当根据源工程的特点进行选择。

(2)类的管理策略。对源工程的移植的理想情况是类的"一对一"移植,即一个源程序的类对应于一个目标工程中的实现类。但这种情况往往是不可能的,对多重继承以及采用设计包装类的方式解决输出参数的移植都需要新撰写额外的类(将Ｊａｖａ中的接口结构也视为一种特殊的类),另外,对于Ｃ++中库函数和系统函数的移植可能也需要编写新类加以实现。对于前两种的新增类,往往是从其它类中衍生出来而且数量比较大,在编码开始前就可以预见,可以使用统一的接口和命名规则进行管理。对于第3种情况的新增类,情况就要稍稍复杂一点,不是所有库函数和系统函数的移植都需要新增加类。一种做法是在编码阶段开始时,首先进行的是对工程中涉及到的库函数和系统函数进行移植,然后在此后的移植工作中使用这些结果,是否增加以及如何使用这些新类和今后的工作完全无关;另一种做法是将这一工作推迟到移植使用该库函数或系统函数的代码时,根据上下文由程序员自己决定如何进行移植,是否增加新的类也由程序员自行决定。后一种方式适合规模不大,涉及库函数和系统函数不多的工程,且有明显的缺点:对于同一个函数的移植不同程序员之间可能拥有不同版本,可能造成难以修正的错误,代码的复用度也不高。推荐使用第1种方式。

第6章 代码测试

与传统测试方式不同,在选择测试数据方面,如果源工程中保留了足够的测试数据,这些数据可以直接用于测试。由于移植活动的目标,测试方法可以进行源工程和目标工程的相同执行,观察其动作一致性作为有效的测试手段。测试的重点应当放在源工程的改动之处,必须确保所有的改动没有副作用。

我们采用以类为单位的编码加单元测试的方法,即在每个类的编码完成后,测试人员立刻采用结构走通和基于状态的方法进行单元测试,尽量保证提交的代码,是完整正确的。该测试是尽力而为的,测试人员仅仅保证被测试的代码流程和状态转换方面合乎要求,换言之,有和原来的代码结构相对应的期待动作。所以进一步的测试是必要的。

在对某个类进行编码之前必须从接口调用的角度对需要调用的所有类进行功能和副作用的测试。对于被测试类来说,如果是进行单元测试的同一人员进行测试(即单元测试也是该测试人员进行的)则称为该测试人员的二次测试,若不是进行单元测试的测试人员进行测试,则称为交换测试。无论是二次测试还是交换测试都不是单元测试的简单重复。二次测试或交换测试是一个黑盒测试,测试人员仅仅从即将撰写的类的角度来进行调用测试,不保证没有被调用部分的正确性。对同一个类的每次二次交换测试或二次测试都可能是针对不同侧重点。只要必要,所有被测试类结构在整个二次或交换测试中都会被覆盖到。可以看到,从整个工程的角度来看,一个类如果被调用了ｎ次,它就会被进行ｎ+1次测试,其中1次单元测试,ｎ次二次或者交换测试。

二次测试和交换测试的区别是进行测试的人员和进行单元测试的人员是否相同。根据测试主体的交换性原则,交换测试的效果应当优于二次测试。恰当地安排测试任务,即使不能完全消除二次测试,也能提高交换测试所占的比重。

第7章 总结和展望

如果源工程具有完全不需要了解功能便可机械移植的特性,则完全可以实现机器移植。遗憾的是,Ｃ++比较Ｊａｖａ来说有更大的灵活性,对于同一结构有更多的实现。完全的自动移植也是不可能的。如何进行机器辅助的半自动化移植,是我们下一步的工作方向。

当前的ＬＥＤ航显系统移植项目仅仅是先移植源工程的一部分功能,形成一个可用版本,然后再进行新功能的添加。后一个过程等同于维护和修改,软件代价无疑是相当大的。如何在进行移植的过程中就一次性进行新功能的增加,也是将来的课题。