基于操作系统设计的开发环境的设计概要(上)
基于操作系统设计的开发环境的设计概要(上)
前言
由于本设计难度较大，先以此概要铺垫，希望能和各位有兴趣的人士交流
加上时间紧迫，我是在网吧里边敲边想了一下午，还是写了一半多点，感觉应该先让各位看看
因为晚上要上课，课后的网吧里总是满满的，所以只能明天把剩余的补上
感谢远方的SOAR，祝她生日快乐，天天快乐,以此代替大蛋糕了(送上迟到的祝福)
这是昨天下午写的,贴了后,发现很多给删了,只好今天又贴了,大家别介意呀
内容
一、选择题原因
1）国内关于开发工具设计的公开资料很少
2）现在能操作系统设计工具非常有限，有关工具分析的理论和方法不多
3）操作系统是一个具有足够复杂度的系统，能提供充足的设计需求，因此这样的环境足以满足多数系统开发的需要
4）它有其他系统所不具备的难点，如由体系结构产生的调式难度
5）开放源码的方式提供了一个最好的分析基础
二、整体设计思路
1、基本思路
一般大型软件设计可分为如下几步：
先期调研、模型设计、编码阶段（语言和编译的选择）、测试阶段（调式）和产品化阶段
这种划分是粗略的，很多过程是相互循环的过程，但基本可以此来确定开发环境的整体结构
如图所示：
模型设计模块 编辑/编译/调试模块 产品化模块
文 档 管 理 模 块
为方便起见把先期调研归入了文档管理模块中
2、为操作系统的考虑
从操作系统设计的角度出发会有以下基本需求
1）必须考虑现有的大量的源码的存在，由此可推出，源码代码分析功能
2）操作系统是一个完全独立运行的软件，只受限制于硬件环境，需设计全新的调试方式
3) 操作系统的基本理论比较成熟,由此很多模块的基本框架很成熟了,在类库设计中需充分考虑
4) 总体讲操作系统的整体理论又是不完善的,有待更新的结构模型出现,开发环境的设计不应受其本身开发环境的限制,体现灵活性
5）操作系统的独特性，对其产品化时，有一个难点，如何为其提供应用软件开发的环境，设想是在本开发环境上，生成一个适当简化的与新系统相应的编译环境
3、从灵活性角度的考虑
1）不同的系统开发者喜欢的开发语言不同,还有各种新的语言不停的产生,需设计新的编译结构,突破语言的限制
2）文档管理一直是系统开发的一个难点，应将其管理结构灵活化，在提供新方式的同时便于用户自己安排
3）整个开发环境是一个对大量数据流的处理过程，考虑将数据库方式有机的结合入开发环境，而无须要求用户具有相关知识（出发点是，数据库具有完善的数学理论基础，希望将它引入，促进操作系统的理论基础发展）
4、从源码分析得出的 -- 透视图
上面的一个需求：源码分析功能，在此块中将其细分，以提出新的整体设计需求
对规模巨大的源码分析是一件艰巨的任务，好的工具能让分析者摆脱枯燥，享受分析的乐趣
关键是分析工具能从多大程度上分析出整个代码的结构，并以好的方式展示在分析人员的面前
逻辑视图方式是一个很好的表达方式
通过词法分析器将源码进行简单的处理形成一张基本数据图，通过语法分析（无须揪错）可以形成最基本的系统视图
通过图形方式将视图展现给使用者，免去代码分析最费力的基本分析步骤
而在调试中也可按视图描述的设置断点，提高调试速度
5、缺憾
由于对模型设计的软件接触很少，在此将不具体谈及模型设计部分，仅在视图部分稍做讨论，准备做进一步调查后，再加入正式设计一文中
由上需求可构成如下整体结构：
逻 辑 视 图 管 理
编译/调试模块
模型设计模块 编 辑 设 计 产品化模块
类 库 设 计
文 档 管 理 模 块
重点分析两个基本元素（视图和文档）、调试模型和类库设计
编译结构、编辑设计和模型设计因为已有比较成熟的理论，在此为简述
以下将按模块逐步分析
三、逻辑透图
逻辑视图是实现大规模代码管理的有效方式
将用户的代码经过初步分析生成最基本的代码流图
1）提出每个源码文件中的所有函数名称和它们的入口、出口，形成一文件一张的基础函数关系视图
2）相应的把每个文件中的全局变量和局部变量等提出按出现位置归类，生成基础变量视图
经过这两步后，便可以进行全局整合了
3）形成整个系统的函数关系视图和全局的变量关系视图
4）按3）形成的视图分析各函数变量所处的文件，形成一张工程文件的关系视图，以用于规范代码编制者对变量与函数定义
这些均可自动完成，接下来便可由系统设计的本身特点，按用户描述生成如下视图
5）模块关系图（定义模块的概念）
6）状态变迁图（定义状态的概念）
7）操作流程图（定义操作的概念）
8）数据流走向图（以逻辑形式描述的数据集合走向，如某些重要的全局变量的修改过程）
相应视图可由用户对基本视图进行简单操作获得，由此就产生这么个问题，如何描述视图
最简单的方式是使用数据库方式，因为整个处理过程中的基本数据是同一源码，描述的是同一数据集合内数据间的关系，以数据库方式存储源码结构，再配上简单的脚本语言用于描述数据关系，和生成用户自定义的视图
上面描述的是对现存源码的处理中的视图应用，把其过程相反，则得到的就是模型设计的过程中的视图制作过程了，可以说模型设计就是相应的视图设计，所有复杂关系均能体现在视图中
根据视图的描述，可以进行基本的逻辑查错和调式
最终也是产品说明演示中直接样品
因此将逻辑视图作为整个开发系统的一个基本元素
四、调试模块
1、现有模式下的调试方式：
在众多开发工具中，VC、VB、DELPHI等它们的调试方式基本能体现了当前的调试模式
因为它们本身是当作操作系统的附属软件而存在的，它们的调试过程直接受到操作系统所提供的功能所限制，只提供简单的单进程状态下的调试功能，很少提及多进程调试和分布式系统的调试，而在多数情况下，大型系统都是多进程的，使用这些调试工具总有累的感觉
2、在此简单分析一下，可能存在的需分类的调试情况
1）单进程内部的调试
2）单机单CPU多进程调试
3）单机多CPU多进程调试
4）分布式系统结构的调试
5）有操作系统支持的调试（即一般应用软件的调试）
6）无支持的调试（即操作系统设计的调试，存在自己为自己诊断的情况）
3、单进程调式
它所使用的方法是具有普遍意义的，是其它各调试情况的基础
一般的断点可分为静态设置（如VC）和动态设置（如VB和DELPHI）
在此主张动态断点的使用，因为更方便
在此提出一种条件断点的概念
即断点并不是源代码中的指定的一行，而是以一个基本数据逻辑描述形式存在，基本数据是变量名和函数名，当运行中逻辑描述成立时，则被激活，系统停止在当前的运行位置
它的实现可分为静态方式和动态方式
1）静态方式
在调试运行前，先确定要考察的基本数据是哪几个，和用户期望的逻辑描，述在调式编译中加以处理
在运行时，可以在确定的数据上，可以适当修改逻辑描述
容易实现
2）动态方式
在调式运行前不确定调试数据
而在运行中才选择基本数据来生成逻辑描述，这样的条件断点实现会降低整个运行效率
但好处明显，实现难度大，尚未找到有效快速的实现方案，只能供参考的方案
4、针对操作系统的特征的调试
前面分析的几种可能的调试情况，归根到底是同步调式问题
而操作系统的调试包含了所有这些情况
从实现方法看有这三种方式：
全程仿真调式方式
子母系统型调式方式
内嵌式调试方式
讨论如下：
1）全程仿真调式方式
即以全软件方式来模拟出一个操作系统所处的硬件环境，所有硬件细节由软件模拟
这是非常有效的方式，调试成本很低，可以方便的模拟出各种出错状态来调试
缺点是生成一个模拟环境的代价很高，且硬件描述的深度有限，存在难以模拟的特殊状态（硬件中有自身的缺陷难以模拟）
优点是，复杂度相对较低，可复用性很高，调式的控制能力最强
2）子母系统型调式方式
即专门设计一个为调试操作系统之类系统的调试操作系统，它是一个单进程系统，无须应用软件，是个极为简化的系统，它是母系统，负责控制子系统的运行
而被调式的操作系统是子系统，但被调试时，它不能控制几个重要的中断（针对中断机制为核心的硬件系统）如硬时钟中断，当然这个步骤需一定量的人工描述，即描述各中断的代码位置，这是编译前的工作，在编译中，母系统将调整相关的中断入口，加入控制代码，以便在断点激活时，从子系统中夺取系统控制权，显然中间存在一个内存分布的冲突，也需要子系统配合母系统来实现
这种方式适合任一情况下的调试需求，因为单机多进程的实质是系统单进程，多CPU的情况和分布式情况相同，母系统要为每个CPU提供一个控制器，即本身是个大的分布式母系统
优点：内真时的反应所有情况，在子系统崩溃的情况下，母系统能直接控制硬件，而恢复调试
缺点：实现难度较大
3）内嵌式调试方式
把调试器融入被调试的操作系统中，通过一定的人工设置，使编译后生成一个以调式为目的的操作系统版本，直接使用该操作系统提供的调用功能来实现运行期跟踪调式
显然，此时的调式代码是开放式的
优点：调式成本适中，实现容易
缺点：调试前，必须严格进行逻辑上的调试（可通过视图完成），须保证调式器调用的系统功能无错误，在被调式系统出现崩溃时调式器也同时崩溃
未完待续
一个愿望：
您能坚持看到此处，感谢你的支持，顺便希望您能有空向如下地址帮我发送您祝福给我的朋友SOAR
希望您能和我一起给她一个惊喜
祝福的地址:
如果此文能激发您的灵感，望能和我分享
我的地址：
我在此期待您的意见