1)如果某个语言结构Ａ不依赖于任何语言结构,则记Ａ的层次是0;

　　2)如果某个语言结构依赖于ｉ个语言结构Ｘ1,Ｘ2,Ｘ3,…,Ｘｉ

　　则Ｃ(Ａ)=ＭＡＸ(Ｃ(Ｘ1),Ｃ(Ｘ2),Ｃ(Ｘ3),…,Ｃ(Ｘｉ))+1;

　　从形式上来看这两种方式的定义是相似的,但它们的实质是完全不同的。从其层次的标的来看,自顶向下的方式是Ｃ(Ａ)<Ｃ(Ｂ),当且仅当Ａ的层次高于Ｂ;自底向上的方法则是完全相反,Ｃ(Ａ)>Ｃ(Ｂ),当且仅当Ａ的层次高于Ｂ。构造出的层次图也局部不同。

　　定义4:一个程序结构的准备度定义为它所依赖程序结构中已经完成的比例。

　　按照上面的讨论,位于同一层次的类Ａ要先于类Ｂ完成,类1、类2、类3、类4的准备度增加了。但是类1、类2、类3位于较高的层次,它们的实现还必须依赖于类4、类6、类7所在层的某个或某些类的实现。完成类Ａ后,直接的效果是类4可以开始进行(是否能够立刻开始依赖于是否还有较低层次的依赖类没有完成)。相比之下类Ｂ的完成虽然不能像类Ａ那样对4个类的准备度有所贡献,但直接的效果是类6、类7都可能立即开始进行。对于整个工程来说类Ｂ的重要程度应当优于类Ａ。因此,一个程序结构在某层的重要程度首先应当由直接高层的依赖程度决定。

　　如果采用自顶向下的层次图的生成方式,即标号越小表示层次层越高,一个语言结构的优先函数定义为:

　　Ｆ(Ａ)=Σｎ=1ｉ=1(ｋｃｉ)/Ｎ(ｉ)×ｋｎ-1

　　其中:ｎ是语言结构Ａ所在的层次,Ｒ(ｉ)是第ｉ层依赖于语言结构Ａ的语言结构个数,Ｎ(ｉ)是第ｉ层语言结构的总数。优先函数越大则该语言结构在本层中的重要程度越高,越应当优先完成。而其中的常数Ｋ是任意指定的,它反映了相邻层次的依赖之间的重要程度,Ｋ越大,较低层次的依赖关系拥有越大的权。合理选择Ｋ是必要的,太大的Ｋ使得所求得的优先函数值过于集中,而太小的Ｋ不利于依赖关系层次的区多类的层次包含的类个数的50%为Ｋ。

　　如采用自底向上的层次构造方法,只是其层次的编号不同,其定义是类似的。

　　在ＬＥＤ航显系统移植项目中,同时有ｎ个程序员要求任务时,我们根据层次和优先函数挑选出ｎ个任务,根据他们的熟练程度,熟练的程序员被派发较大的任务。基本上没有出现程序员的相互等待。应当指出,无论怎样精巧的安排任务都不能完全杜绝等待的可能。

　　第5章 代码编写

　　为了保证接口定义的一致性、代码的可读性以及工程质量,在同一个移植工程中协作的程序员必须遵守相同的移植策略。这些策略应当是一种全局的约定,而且应当以文件的形式固定下来。移植蓝图就是包含了这些策略以及其他相关的内容的一系列文件,它应当包括以下几个部分。

　　（1）语法结构的移植标准。进行移植时,如何将源语言的结构以目标语言进行重写。以Ｃ++到Ｊａｖａ的移植为例,这些移植标准有的是易见的,例如相应类型以及流程语句的移植。有些则需要改变原来语言结构,甚至逻辑结构,例如对多继承的移植。有的移植方案是多种的,例如对Ｃ++中输入输出参数的移植。移植蓝图中必须指出源工程中涉及到的所有语言结构以及相应的移植方式,对有多种移植方案的应当根据源工程的特点进行选择。

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

　　第6章 代码测试

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

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

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

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

　　第7章 总结和展望

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

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

[1] [2]