系统架构_连载40：软件体系设计新方向：数学抽象设计模式系统架构与方案设计(简化版)(袁晓河著)

1. 完备和相容

完备性可以这样来简单理解：当一个对象具有完备性，即它不需要添加任何其他元素，这个对象也可称为完备的或完全的。完备性最为强烈的表现在数学之中，因为在整个体系中可以将之转化为一个一组公理系统，这组公理系统只有具有完备性，才能以此推广到这个领域，但是针对一个系统来说，在指定的范围内，虽然物理的系统是一个完备的系统，但是由于我们的有限的资源，有限的运行时间以及一些特殊的要求，我们描述系统常常又是非完备的。当然，我们需要通过有限的手段更为通用的设计方法来将完成一个绝大部分达到完备的系统。

完备系统有一个突出的优势就是：在完备系统中运行的系统是可靠的，是值得信任的。实际上，完备性和可靠性是互为可逆。这就表示两者具有等价的效果。

当然，我们此处不去讨论完备性和哥德尔的不完备性的各种理论或者哲学上的思辨，这里我们特别需要让大家知道如何在软件系统设计中做到完备性以及如何检测系统是否是完备的。

在具有状态变迁这样的系统中，我们发现其是否是完备的方法就是通过图例来表征系统的状态变迁情况，在这个变迁图中，一个是状态是否是完备的，一个是变迁方式是否是完备的。当进行有效的清理以后，如果不完备，这就可以直接从图中就会直观的表现出来。因此如何构造状态变迁图成为这类系统的一个基本的能力要求。

同样，在一个系统中，有些具有相互矛盾的业务或者处理方式也是我们判断是否具有完备性的一个检验方法。例如一个系统是否同时兼顾了“读和写”的能力，一个系统是否考虑了“输入和输出”的处理，一个系统是否具有“增加和删除”的功能等等。这些具有矛盾的处理方式在我们的设计过程中应该不断地检测和验证。

当然，很多系统在一些特征上都具有“对称”的特点，对称是完备系统中最为简单有效的处理方式。其实就算哪些具有“非对称”的系统中，在更大的领域其实也是具有“对称”的特点。例如在非对称加解密的应用中，在更大的范围内可以使用加解密和签名认证上就是对称的出现。

另外，完备性还表现在一些特殊的非正常情况下的异常处理机制中，针对异常情况下我们的应对策略，是否将这些异常情况的处理也同时统一到我们正常的处理机制中，这样我们就能够更好的满足系统的可靠性。

比如，在某些登录系统中，当用户传入的用户不存在或者密码不正确的情况下，我们是否可以提供给用户是否需要重新注册，或者忘记密码，通过将注册和密码这两个正常业务引入过来，这样能够显著提高用户的体验，同时也让登录系统完备化，这其实也是我们在处理异常情况下的一种通用的方法。

在应用层面上完备性是很难体现出来的，这就如同我们在一个完备系统中，我们没有参照物又何从指导我们是一个完备系统呢？所以，我们需要通过具有一些方式和方法来进行验证是否是在完备之中，比如如果我们预先知道我们是在一个对称系统中，此时可以通过对称来推测是否具有完备的设计。而在一个非完备系统中，常常会有一些无法定义的状态也是我们判断的依据。

相容：

数学中，在形式化的逻辑系统中，其相容性是指其中没有矛盾，或更精确的说，不存在一个命题P，P和非P都可以在这个系统中证明。

分布式领域CAP理论：

ü Consistency(一致性), 数据一致更新，所有数据变动都是同步的。

ü Availability(可用性), 好的响应性能。

ü Partition tolerance(分区容错性) 可靠性。

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

在系统设计中，常常存在无法相容的情况，需要我们进行适当的取舍。这些相容是由于在物理层面上，无法通过技术上的改造解决其相容性，这需要考虑实际的需求和运行环境，对此需要做的就是能够针对不同的场景能够通过配置进行切换，这样让系统能够根据需要进行不同模式的适应。

软件兼容：

软件的兼容性是衡量软件好坏的一个重要指标，兼容性指与软件可从某一环境转移到另一环境的能力有关的一组属性，它包括以下几个属性：

1、 与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性 ；

2、 使软件遵循与可移植性有关的标准或约定的软件属性 ；

3、与软件在该软件环境中用来替代制定的其他软件的机会和努力有关的软件属性 。

在具体测试中可以从以下几个方面来判断：

操作系统兼容性 　软件可以运行在哪些操作系统平台上，理想的软件应该具有与平台无关性。有些软件需要在不同的操作系统平台上重新编译即可运行，有些软件需要重新开发或是改动较大，才能在不同的操作系统平台上运行，对于两层体系和多层体系结构的软件，还要考虑前端和后端操作系统的可选择性。

异构数据库兼容性 　现在很多软件尤其是MIS，ERP，CRM等软件都需要数据库系统的支持，对这类软件要考虑其对不同数据库平台的支持能力，如从ORACLE平台替换到SYBASE平台，软件是否可直接挂接，或者提供相关的转换工具。

新旧数据转换 　软件是否提供新旧数据转换的功能。当软件升级后可能定义了新的数据格式或文件格式，涉及到对原来格式的支持及更新，原来用户的记录要能继承，在新的格式下依然可用，这里还要考虑转换过程中数据的完整性与正确性。

异种数据兼容性 　软件是否提供对其他常用数据格式的支持。例如办公软件是否支持常用的DOC、WPS等文件格式，支持的程度如何，即可否完全正确的读出这些格式的文件。

应用软件兼容性 　主要考察两项内容：一是软件运行需要哪些其他应用软件的支持，二是判断与其他常用软件如MS OFFICE，反病毒软件一起使用，是否造成其他软件运行错误或软件本身不能正确实现其功能。

硬件兼容性 　考察软件对运行的硬件环境有无特殊说明，如对计算机的型号，网卡的型号、声卡的型号、显卡的型号等有无特别的声明，有些软件可能在不同的硬件环境中，出现不同的运行结果或是根本就不能执行。

以上一些方面是中国软件评测中心在大量的软件测试实践中提炼出来的比较有共性的内容，对于不同类型的软件，在兼容性方面还有更多的评测指标，并且依据实际情况侧重点也有所不同。

例如在软件升级的过程中，往往由于没有考虑到原来的处理方式或者数据格式这样的前向兼容，导致升降级失败。

例如下面的命令字不兼容的有这样的一个系统，如图7-6所示。

图7-6

上层软件是由我们自己完成，而固件是购买的第三方，而所谓的固件，就是说这些软件是一些逻辑性的软件，是固化在硬件上。上层软件和固件的通信是通过命令字的方式进行，按照道理这种方式应该是耦合性最弱的方式。另外上层软件和固件由于是采用命令字方式，不是通过静态的函数接口，所以其两个部分都单独可以发布版本。其命令字通过如下枚举的方式表示：

enum

{

CMD_INIT = 0,

CMD_GET_DEV,

CMD_SET_INFO,

CMD_GET_INFO,
}enm_COMMAND_DEVICE;

由于之前没有充分考虑到枚举类型应该分段表示（注：实际开发中常常存在这样的情况，对于系统不可能完全考虑周全，对于这样的细小部分可能很容易忽略掉，但是一旦酿成事故，就变得十分严重），所以其命令字按照编译器的自动编号，将后面的枚举值进行编号。

这种方式在开始时候还没有引起大家的注意，原因是固件大多时候是不更新版本的，因此我们已经按照上面提供的命令字的版本发给了客户使用。后来固件也进行版本更新，由于第三方提供商同时存在给不同的厂家供货，所以他们也发布一个新的版本。不过他们对命令字是这样添加的。

enum

{

CMD_INIT = 0,

CMD_GET_DEV,

CMD_OTHER,//添加的新命令字

CMD_SET_INFO,

CMD_GET_INFO,
}enm_COMMAND_DEVICE;

结果导致命令字不兼容，我们就存在原来的上层软件就无法配套新的固版本，新的上层软件无法配套旧的固件版本。由于就是小小的接口命令字不兼容，导致我们不得不进行其他间接方式进行映射处理，同时向客户道歉，屈辱地更新客户当前运行的版本，真是劳力老财结果还不得一个好。

当然，对于一些并行处理的场景中，其实就算使用统一的处理机制也是容易导致冲突的，此时就需要通过一些方法来进行规避，例如在多版本并行开发中解决命令字冲突。

当前存在一个产品系列多个版本并行开发，而命令字的命名如果没有统一管理情况下容易导致冲突，冲突的结果是相同命令字可能定义为不同的编码值，或者不同的命令字定义为相同的编码值，两种情况都是非常危险的事情，而同时我们又不希望有这样的管理工作，此时就可以使用分区分段的策略来解决冲突，同时又需要当冲突的时候能够明确的通知给使用者，而我们在合理的做法就是形成编译错误，只有修改了此冲突才能够进行下一步的任务操作，这样能够有效的保证冲突发生而被忽略导致灾难。

namespace nameA

{

enum enum_nameA

{

ID_COM_Base = 0,

    ID_NameA_Ver1 = 100,

    ID_NameA_Ver2 = 200,

}

}

namespace nameB

{

enum enum_nameB

{

ID_COM_Base = 0,

    ID_NameB_Ver1 = 100,

    ID_NameB_Ver2 = 200,

}

}

操作实现如下：

switch (CMD cmd)

{

case ID_COM_Base://如果此处编译错误，表示你可能存在多个特性空间混杂的情况  

case ID_NameA_Ver1:

{

  … … …

}

case ID_NameA_Ver2:

{

  … … …

}

}

switch (CMD cmd)

{

case ID_COM_Base://如果此处编译错误，表示你可能存在多个特性空间混杂的情况  

case ID_NameB_Ver1:

{

  … … …

}

case ID_NameB_Ver2:

{

  … … …

}

}

这里为什么要定义一个相同的ID_COM_Base呢？这是因为希望将nameA和nameB两个空间进行隔离，如果一旦混杂，则编译器就会提醒ID_COM_Base命名冲突，一旦发生冲突，那么在编译时期就知道开发人员存在命令空间混乱的情况，所以此时可以提前就进行纠正，而不会向后运行和运营时期才发现问题。

当然如果存在混杂的应用，那么可以使用nameA::ID_COM_Base和nameB::ID_COM_Base来显示进行描述。

虽然这只是一个技巧处理，但是，能够帮助我们下面的好处：

ü 为了减少管理的成本，每一个接口类都有自己的ID编号。

ü 在这些ID中进行分段划分，此为适用于多个版本并行开发中避免冲突。

出现冲突则需要修复以后才能继续下一步工作，能够从技术上保证低级错误导致灾难。