软件调试设计随想

1、调试
个人认为调试分为： 基于过程的调试，基于类的调试，基于构件的调试，基于领域的调试.
过程的调试： 即现在大家普遍使用的调试方法。 利用硬件可对单次存储内容发送中断信号的功能，可以设置指令断点和数据断点。目前大家断点设置的位置在具体的函数位置，跟踪的过程也只是局限于函数和函数之间的调用。这样trace出来的都是函数之间的调用过程，却无法追踪类与类之间的调用关系。
优势：现在的软件调试器基本支持调用函数栈的树形展示，而且部分支持软件函数翻译注释的支持，软件调试时间花费在对函数的二次整理和翻译。  劣势： 无法从对象的角度进行解析对象间的依存关系，更无法直观的了解整个软件的架构层次，对软件的解析带来一定的时间浪费

基于类的调试： 可以非常直接的观察到类与类之间的关系，目前未发现有这样的调试器。因为这类调试是基于面向对象而产生的调试方法，大概比较新，未发现有支持的调试器。调试器所要做的工作是将调试符号中的符号解析成对应的类，但是目前调试符号支持C++方式，所以这个工作量还算是不大，直接在基于过程的调试基础上进行基于类的调试就可以了。进行二次构建任务。
劣势：对于采用面向对象的语言来说，这个问题不大，但是如果是面向过程的语言，而无法进行解析出来。因为面向对象里面包含了人的对象识别和业务逻辑，计算机怎么知道人类怎么区分对象的。

基于构件的调试：这个思想还算是比较新，可能采用这种思维构建软件的公司在中国这里要比较规范、技术实力比较强的公司会这样做。但优势还是蛮多的。 优势：对于大规模软件来说，基于构件调试容易轻松的进行调试的第一层过滤，直接定位问题出现的模块，然后使用 基于类的调试， 可以进一步定义构件中出问题的逻辑层， 再使用基于过程的调试，可以进一步定位出具体的函数过程，最后才是观察寄存器、内存、堆栈等，直接定位出问题的原因。
这里插播下： 当然我这里说讲的是至上而下的调试思路，如果有大侠采用数学统计调试方法的话，当然也是很不错的。 前提是你得先建立一套的统计调试理论（真希望国外的牛逼哄哄的人士先建立下，我们只要学习就好，嘻嘻），统计方法非常适合用于调试没有源代码的软件。  当然linux底下调试可以采用调试驱动开发，windows底下则采用调试符号配合调试器进行，如果想要对软件调试掌握的比较好的话，还是应该这四种综合使用比较好。
至上而下调试+统计调试+调试驱动开发+调试理论（系统原理的深入理解）

基于领域的调试：领域建模目前应用的还不算多，uml正向工程也未有大批量应用。当然对于一个需要多领域配合的巨型大系统来说，基于领域的调试才算有意义。 目前第三代信息革命已经来临，我想基于领域的调试只是时间上的问题而已。三网合一的时代，软件架构问题将是家常便饭。而随之带来的软件调试问题也是异常突出。需要综合这几种调试手段，一起解决

当然还有一种是基于现象总结判断的调试方式：  其一： 认真阅读代码中的逻辑关系，理清层次关系，根据代码的类逻辑关系图挖掘出潜在的bug，然后推断出这些bug会产生的现象，推导出问题的原因。其二，认真分析现象，汇总所有相关的现象，对所有的现象进行分类和统计，然后抽象出根本的原因， 从而定位代码中错误的模块和位置。  当然一般情况下是这两种方式统一一起使用，而且这个方法是作为初略定位bug来用的，如果遇到比较不明显的bug，还是得实际调试才可以

2、设计
设计要分层次来说： 
从语言角度来说：分为汇编层、高级语言层
从系统架构来说：分为内核层和应用层。
应用层分为 基础设施层和领域层。  基础设施层分为： 引擎层、中间构件层。  领域层分为框架和业务层。 业务层分为 界面层和逻辑层
从系统组成角度来讲： 分为硬件驱动层和软件业务层。
语言角度来讲：  汇编层的设计思路决定高级语言的设计思路。  汇编层的角度来看：其实软件就是数据加逻辑，而汇编层强调的是数据和算法的分离。所以决定了高级语言层也要时时是算法和数据结构的分离。高级语言层有：界面和界面逻辑分离，于是产生了界面助手和界面。底层存储数据和上层业务分离，于是产生了数据库和中间件。