[理学]2002级毕业生毕业设计课题任务.doc

2002级毕业设计课题任务一、综述 1. 软件分类特征：软件开发工具 2. 指导教师：刘伏贵 3. 编程语言： C （Windows 的C 语言编程环境） 4. 宅 电：2310091 5. 手 机：13087228854课题任务 程序流程图编辑器 二、 主要任务内容，要点、难点所在1. 程序功能 支持软件开发人员使用流程图作为描述工具自顶向下地完成模块内部过程的结构化设计、提供对于程序流程图的图形编辑操作、可对开发人员的过程设计结果进行正确性分析、提供流程图输出支持、为将设计结果转化为等价的PDL 描述提供系统支持。2. 任务要点 设计系列关联的系统数据结构保存一张程序流程图。引导用户严格按照“自顶向下、逐步求精”的原则进行模块的过程设计。控制模块的过程设计，使设计不违背结构化原则。3. 任务难点：（1）缺乏现存的系统参考资料；（2）流程图本身并不支持自顶向下的结构化设计；（3）在支持用户对流程图进行编辑的同时要防止用户的修改导致流出的结果违背结构化设计原则；（4）设计实用的数据库保存程序流程图。 三、 关于“程序流程图编辑器”任务 （一）系统总体考虑 1. 程序流程图 用以描述一个软件产品中指定程序模块的过程设计结论的图形工具，在我国得到广为流行。它包含以下基本图符： （1）起始/终止框 椭圆框，用以表示一个程序模块执行的起点和终点； （2）执行框 矩形框，用以表示执行某个确定的动作（包括输入/输出）； （3）判断框 菱形框，用以表示进行一个确定的判断（检测指定条件的状态，不考虑多分支情况，假定判断仅有两个分支）； （4）子程序调用框 在其内左右两侧各加一条竖线的矩形框，用以表示对于一个相对独立子程序的引用； （5）流程线 带有指示执行方向的单箭头的线段。 2. 控制流结构 为了简化用户的操作，系统允许用户使用几种规范的控制流结构： （1）顺序结构 由1 到多个顺序关联的“执行框”组成的局部过程； （2）单分支条件结构 由一个判断框和一个执行框为主体组成的局部过程，指出：当相应的条件成立时执行“执行框”所规定的动作；条件不成立时忽略指定的动作； （3）双分支条件结构 由一个判断框和两个执行框为主体组成的局部过程，指出：当相应的条件成立时执行一个确定“执行框”所规定的动作；条件不成立时执行另一个“执行框”所规定的动作； （4）多分支结构 由一个判断框和多于两个的执行框为主体组成的局部过程，判断关联的状态变量可取多个值，据之，在多个可选的执行框中选择一个执行； （5）For 循环结构； （6）While 循环结构； （7）Do while 循环结构。 3系统数据库 系统提供一个用C 语言程序实现的系统数据库保存用户输入的流程图信息。相应地，系统信息主要包括： （1）程序模块的过程设计相关信息 本系统假定，系统所面向的问题是一个软件产品中的一个确定程序模块的过程设计问题。由关联实践可知，在一个软件产品的开发过程中，程序模块是在“软件设计”阶段确定的。在这一开发阶段， （2）流程图构成单元及其相互关联的基本信息 “流程图构成单元”可以是一个确定的“执行框”，也可以是一个确定的控制流结构。流程图构成单元间的关联仅有两种模式：顺序关联和嵌套关联。这样，两个“执行框”可以顺序连结、一个“执行框”与一个确定的控制流结构可以顺序关联、两个确定的控制流结构可以顺序关联、两个确定的控制流结构可以嵌套关联。 （3）填入流程图相应图符内部的信息 本系统假定，它们是一个确定的短语，描述计算机系统应执行的“动作”或“判断”。（二）系统数据库设计的基本考虑 1. 在本系统中，保存程序流程图相关设计信息的系统数据库由一组逻辑关联的系统数据文件（文件簇）定义。这些文件包括： （1）“名字表”文件 （2）模块所涉“名字”一览表文件（文件簇） （3）程序模块一览表文件（每个程序模块一张流程图、每个程序模块的有关信息在本文件中占一个有效记录，记录内容反映各程序模块的有关整体特征） （4）程序流程图文件（文件簇） （5）流程图内容文件（文件簇） 2. “名字表”文件的系统设计 在本系统中，设计有一个“名字表”文件。该文件保存所有用户提供给系统的“名字”。包括：程序模块名、参数名、局部变量名、全局变量名、子程序名、填入流程图框内的相对独立语言成分等。每个“名字”在该文件中占一个有效记录。每个“名字”在该文件中的记录号被称为该“名字”的“名字表系统索引”。该文件为顺序文件。文件的有效记录号为1 32767。文件的0# 记录被特殊使用，用来保存文件的控制信息。 3. 模块所涉“名字”一览表文件（文件簇） 面向每一个用户提供给系统的程序模块，系统中对应地设置一个“模块所涉名字一览表文件”以保存其系统设计和流程图设计关联“名字”的有关信息。每个模块所涉“名字”在该文件中占一个有效记录。 4. 程序模块一览表文件 用户使用本系统可记录多个程序模块的程序流程图相关信息（系统最多可保存 32767 个模块的程序流程图信息）。每个程序模块的有关信息在该文件中占一个有效记录。一个程序模块的“程序模块一览表文件”记录号称为该模块的“程序模块系统索引”。 5. 程序流程图文件 每个程序模块的程序流程图结构信息被保存在一个独立的系统数据文件中。文件的每一个有效记录对应于一张确定的程序流程图中的一个“执行框”或控制流结构。记录的顺序性基本上反映了程序流程图中相应构成的顺序性。 6. 流程图内容文件 “内容”是指登记在一张程序流程图图符内部的“文字”。（三）程序流程图构成成分的基本属性分析 1. 流程图的基本构成成分有两类：执行框和控制流结构。在这两类成分中，“执行框”的系统描述较为简单；控制流结构的系统描述较为复杂。 2. 在控制流结构中，最为简单的是“顺序结构”，它由两个以上的执行框、一个以上的执行框和一个以上的控制流结构、两个以上的控制流结构依序组成。 3. 最简单的“单分支条件结构”仅含一个判断框和一个执行框；这种结构中的“执行框”也可以是一个确定的控制流结构，由此形成嵌套的“单分支条件结构”。 4. 最简单的“双分支条件结构”含三框：一个判断框、一个条件为“真”时的执行框、一个条件为“假”时的执行框。条件为“真”时的执行框也可被一个确定的控制流结构取代，由此形成嵌套的“双分支条件结构”。类似的，条件为“假”时的执行框也可被一个确定的控制流结构取代，由此形成嵌套的“双分支条件结构”。最复杂的“双分支条件结构”是两个分支都是嵌套的控制流结构的情况。 5. 最简单的“多分支条件结构”含n+1框（n 为分支数，其中的一个可能是“default”分支）：一个判断框、n个“执行框”。在“多分支条件结构”中，任一个分支都可被一个控制流结构所取代，由此形成嵌套的“多分支条件结构”。为了简单起见，本系统假定“多分支条件结构”中的分支数n不大于12（这一假设与实际是较为吻合的）。这样，一个“多分支条件结构”的分支数如果小于3、大于12，在本系统中被视为“非法”的“多分支条件结构”。 6. 最简单的“for 循环结构”含4框：一个 “控制变量赋初值”框、一个判断框、一个表示循环体的“执行框”、一个“控制变量增值（含减值）”框。为了简单、实用起见，系统对“for 循环结构”的组成特性作出如下限制： （1）在结构上不支持“break”和“continue”，如果确有必要，在循环体中用“执行框”表示（参见随后关于嵌套的“for 循环结构”的有关讨论）； （2）“for 循环结构”的4个组成成分不能缺省（流程图反映的是设计而不是程序代码）； （3）“for 循环结构”中的循环控制变量只能是整型数值量； （4）“for 循环结构”中的判断循环终止的条件只能是（）、（）、（）、（）； （5）“for 循环结构”中的修改控制变量值的方式只能是增加一个整数值或者减去一个整数值，不能使用变量，也不能使用其它方式（如“乘”、“除”等）； （6）判断循环终止在循环体执行之前被执行。“for 循环结构”的循环体可以是一个确定的控制流结构，由此形成嵌套的“for 循环结构”。当设计者必须在循环体中使用“break”和“continue”时，相应的“for 循环结构”必须是嵌套的“for 循环结构”。 7. 最简单的“while循环结构”含两框：一个判断循环是否终止的判断框、一个表示循环体的“执行框”。为了简单起见，本系统规定，对于“while循环结构”，仅当判断检测到相应条件为“真”时，循环体才被执行；否则，终止循环。“while循环结构” 的循环体可以是一个确定的控制流结构，由此形成嵌套的“while循环结构”。 8. 最简单的“Do while 循环结构” 含两框：一个表示循环体的“执行框”、一个判断循环是否终止的判断框。为了简单起见，本系统规定，对于“Do while 循环结构”，仅当判断检测到相应条件为“真”时，循环体才被重复执行；否则，终止循环。“Do while 循环结构” 的循环体可以是一个确定的控制流结构，由此形成嵌套的“Do while 循环结构”。（四）程序流程图的系统保存与系统数据库设计 由程序设计相关知识可知，当考虑用一个系统数据库来保存一张程序流程图的内容时，需要系统地处理程序流程图的控制流结构框架以及填写在流程图各框内的文字（实际上还有条件的标示）两个方面信息的系统保存与处理问题。在本系统中，称“程序流程图的控制流结构框架”为“程序流程图结构”；而称“填写在流程图各框内的文字”为“程序流程图标注”。在本系统中，这两部分信息被分别地保存在一些相对独立的系统数据文件中。这些系统数据文件既相对独立，又密切关联，组成了本系统中用来保存程序流程图信息的系统数据库。下面分别对之作简要讨论。1. 动作描述与系统数据库设计 在程序流程图中，“执行框”（包括“子程序调用框”在内）被用来描述确定的“动作”。包括：“输入”、“输出”、“显示”、“打印”、“变量赋初值”、“求表达式的值并赋给变量”等等。在本系统中，“动作”被划分为： （1）系统预定义的一些简单操作 （2）子程序调用 （3）“命名动作” 在本系统中，一个“动作”在形式上通常由两部分组成：一是“动作”关联的“操作”（如“输入”，用动词描述）；二是“动作”所指向的“操作对象”（确定类型的数据对象“变量”）。为了简化“执行框”中的一些简单内容（简单动作）的描述，系统中通过编码给出了一些“预定义”的基本操作（详见“顺序结构列表文件”部分的相关讨论）。对之，我们将其关联“动作”的描述通过数据抽象放置在描述“执行框”的文件（“顺序结构列表文件”）的记录中。一个“执行框”的内容也可以是一个“子程序调用”（为了使之有别于一般“执行框”，在本系统输出流程图时，对之给出单独的图符，但在流程图信息的系统管理上，系统把它看作一般“执行框”）。在系统数据库设计中，对之的处理与“预定义”的基本操作相同（详见“顺序结构列表文件”部分的相关讨论）。应当注意，这里所谓的“子程序”，是指在用户向系统提供程序模块系统设计信息时列表给出的“模块可调用的代码资源”。由于本系统支持用户按照“自顶向下、逐步求精”的结构化设计方法进行一个程序模块的流程图设计，因此，一个“执行框”中的“动作” 关联的“操作”可以是用一个系统“名字”表示的，这就是“命名动作”。对之的处理参见“顺序结构列表文件”部分的相关讨论。 2. 表达式描述与系统数据库设计 由程序设计相关知识可知，一个“执行框”的内容可以是对一个确定的表达式求值并将其值赋给“操作对象”。鉴于一般意义上的“表达式”组成复杂，本系统中另外用关联的系统数据文件来保存它们。为了简化当前系统的设计，这部分内容目前尚未进行系统处理，留待今后系统功能扩展时再去处理（系统已留出相应接口，参见“顺序结构列表文件”部分的相关讨论）。 3. 简单判断描述与系统数据库设计 在流程图中，“判断”是广为使用的（在本系统中，它总是与“控制流结构”关联在一起的）。这使得，在系统数据库的设计中必须系统考虑流程图中判断描述的有效保存问题。在本系统中，“判断描述”被划分为：（1）“简单判断描述” 在程序设计语言中通常称作“关系表达式”；（2）以子程序调用的返回值为逻辑值（0 “假”、“非0” “真”）的判断描述（3）“复杂判断描述” 带有两个以上逻辑运算符和/或关系运算符的判断相关逻辑表达式。本系统中对于“判断描述”的相关处理参见后续内容中关于“单分支条件结构列表文件”部分的讨论。 4. 逻辑表达式与系统数据库设计 由程序设计相关知识可知，与“判断”相关联，程序设计语言通常识别“逻辑表达式”（其值为逻辑“真”/“假”的表达式）。相应地，在程序流程图中出现的“判断框”的内容在原则上讲可以是一个逻辑表达式，对之，本系统在设计上留出了相应接口，但目前未提供具体的处置机制，留待以后系统功能扩展时处理。5. 执行框与系统数据库设计 由程序设计相关知识可知，执行框是流程图中的基本构成成分。同时，多个顺序执行的动作（顺序控制流结构）在流程图中可逻辑地表述为一个执行框的内容。为了系统地保存程序流程图中的“执行框”（顺序控制流结构）相关信息，本系统中设置了一个“顺序结构列表”数据文件。文件的有效记录中存储了一个“执行框”（顺序控制流结构）的有关流程图信息，详见后续内容中关于“顺序结构列表文件”的讨论）。在该文件中，一个“执行框”（包含于程序模块整体顺序结构中的“执行框”、包含于各种控制留结构中的独立“执行框”或作为顺序结构组成部分的“执行框”）的流程图信息对应地占文件的一个有效记录。 6. “单分支条件结构”与系统数据库设计 由前面的相关讨论和程序设计相关知识可知，“单分支条件结构”包含一个“判断”环节和一个在判断结果为“真”时的执行部分。为了系统保存程序流程图中的“单分支条件结构”的有关信息，本系统中设置了一个名为“单分支条件结构列表”的数据文件。文件的有效记录中存储了一个“单分支条件结构”的有关程序流程图信息，包括“判断”环节相关描述信息、判断结果为“真”时的执行部分相关流程图信息、其后续程序流程图元素信息等内容（详见后续“单分支条件结构列表文件”部分的相关讨论）。该文件的有效记录号自1始，0#记录用来存放文件的控制性数据。文件有效记录的记录号称为“单分支结构系统索引”。 7. “双分支条件结构”与系统数据库设计 一个“双分支条件结构”的流程图信息主要包括：（1）判断环节（2）判断结果为“真”时的执行部分（3）判断结果为“假”时的执行部分。为了系统保存程序流程图中的“双分支条件结构”的有关信息，本系统中设置了一个名为“双分支条件结构列表”的数据文件。文件的有效记录中存储了一个“双分支条件结构”的有关流程图信息（详见后续“双分支条件结构列表文件”部分的讨论）。该文件的有效记录号自1始，0#记录用来存放文件的控制性数据。文件有效记录的记录号称为“双分支结构系统索引”。 8. “多分支条件结构”与系统数据库设计 与“单分支条件结构”和“双分支条件结构”不同，“多分支条件结构”的分支数因具体流程图内容的不同而不同。为了系统保存程序流程图中的“多分支条件结构”的有关信息，本系统中采用了如下策略： （1）设置一个名为“多分支条件结构列表”的数据文件，以保存流程图中各“多分支条件结构”的整体性描述信息（包括“判断”、分支数、有无default 分支等）。文件的一个有效记录登记一个“多分支条件结构”的相关信息。该文件的有效记录号自1始，0#记录用来存放文件的控制性数据。文件有效记录的记录号称为“多分支结构系统索引”。 （2）针对流程图中的每个“多分支条件结构”，系统中设置一个“分支列表”数据文件，记录相应“多分支条件结构”每个分支的有关情况，每个分支的有关信息在该文件中对应地占一个记录。由此在系统中形成一个同构（记录格式完全相同）的“文件簇”。这些文件按统一的规则命名。有关进一步的细节参见后续相关部分的讨论。 9. “for 循环结构” 与系统数据库设计 一个“for 循环结构”依序包含“循环变量赋初值”、“判断循环是否终止”、“循环体”、“修改循环变量值”等4个环节。通过应用“数据抽象”技术，本系统中用一个文件记录来规范地登记一个“for 循环结构”的程序流程图信息。相应的系统数据文件被称为“for 循环结构列表文件”。该文件的有效记录号被称为各相应“for 循环结构”的“for 循环系统索引”。文件的有效记录号自1始，0#记录用来存放文件的控制性数据。有关进一步的细节参见后续“for 循环结构列表文件”部分的相关讨论。 10. “while循环结构” 与系统数据库设计 相关的系统处理策略与“for 循环结构”相同，有关细节参见后续相应部分的讨论。 11. “Do while 循环结构” 与系统数据库设计 相关的系统处理策略与“for 循环结构”相同，有关细节参见后续相应部分的讨论。 12. 综合而论，鉴于一个程序模块的程序流程图在结构化设计方法下总是由几种规范的控制流结构规则组形成的，为了系统保存程序模块的程序流程图信息，在本系统中，是以控制流结构的分类来组织系统数据库的。一种控制流结构对应着系统中的一个数据文件或一组相关的数据文件，通过文件记录格式的设计来确立它们间的逻辑关联。面向每一种不同的系统数据文件，系统中设计有一组程序模块与之直接关联，使得外部对于这些文件的所有访问要求都通过相应的模块来实现。 13. 程序模块设计信息与系统数据库设计 由于本系统所面向的问题是程序模块的流程图设计，因此，自然而然地，系统需要关注并系统保存程序模块的设计信息。本系统所关注的程序模块设计信息是以“软件设计”阶段流出的“程序模块规格说明”为基础的，详见后面相关部分的讨论。为了系统地保存程序模块的设计信息，本系统中引入了下列数据文件： （1）“程序模块一览表文件” 用以保存需要（或已经）进行流程图设计程序模块的一些整体性特征的系统描述信息，每个模块的相关信息在文件中占一个有效记录； （2）“模块 全局性数据列表文件” 用以记录各流程图关联的程序模块可见的系统“全局性数据单元”和直接关联的全局性变量，如果模块具有相应属性的话； （3）“模块 模块调用关联列表文件” 用以记录各流程图关联的程序模块所引用的程序模块（子程序）的相关信息，若模块存在直接递归调用，其自身的相应信息也被登记，模块所引用的来自开发平台的程序模块不计在内； （4）“模块参数列表文件” 用以记录各流程图关联的程序模块的参数的有关信息，如果模块的参数个数不为“0”；若模块具有长度可变的参数表，则记录模块参数表中的“固定参数” （系统假定，这样的模块至少包含一个固定的参数）的有关信息； （5）“模块功能定义列表文件” 用以记录各流程图关联的程序模块的功能说明文本。14. 模块流程图的整体描述与系统数据库设计 基于结构化程序设计技术，一个程序模块的流程图在整体上是一个“顺序结构”，它由顺序关联的若干个“执行框”、除“顺序结构”（在流程图的这一层次上，本系统不识别局部的“顺序结构”，视之为顺序关联的多个执行框）外的其它控制流结构组成。在上述相关系统数据库设计的基础上，本系统面向每一个系统存有其流程图信息的程序模块，设置有一个文件来系统地记录其整体顺序结构的有关描述信息（相应文件的记录格式设计等见后续相关部分的讨论），由此形成一个同构的“文件簇”。 四、系统可操作性与系统过程特性 本系统向用户提供的可视化操作包括： （1）创建程序流程图操作 （2）输入初始流程图操作 （3）添加流程图操作 （4）插入流程图操作 （5）删除流程图操作 （6）修改流程图操作 （7）复制流程图操作 （8）搬移流程图操作 （9）局部变量操作 （10）输出流程图操作 下面，分别对之作一简要讨论。 （一）、创建程序流程图操作（简称“创建”操作） 1. “创建”操作开始一个程序模块的程序流程图的交互式设计过程。 2. 由于本系统假定所面向的问题是一个程序模块的过程设计，而程序模块的确定是“软件设计”阶段的结果（参见软件工程相关内容），因此，在着手进行一个模块的程序流程图的设计活动前，用户首先要向系统提供关于待处理程序模块的相关系统设计信息。程序模块的系统设计信息（在软件工程术语中称为“程序模块的规格说明”）包括：（1）程序模块名（2）程序模块的功能说明（3）程序模块的分类特征（“总控模块”/“原子模块”/“普通模块”）（4）程序模块的返回值类型（5）程序模块的参数特征 指出程序模块的参数个数是固定的还是可活动的（6）程序模块的参数个数 当程序模块的参数个数可变时，这项指标指向程序模块的参数表中固定参数的个数（系统假定，如果一个程序模块具有可变长度的参数表，则它至少有一个参数是固定参数）（7）程序模块的参数列表 列表给出程序模块的参数（当程序模块的“程序模块的参数个数”不为0时），对于每个参数，应给出“参数的数据类型”、“参数名”、“参数的作用类型”（“输入”/“输入/输出”）（8）程序模块所引用的模块数（不包含程序模块所引用的来自开发平台的系统函数，若模块存在直接的递归调用，应记在其中）（9）程序模块所引用的模块列表 列表给出模块所引用的软件中的所有程序模块的“模块名”（10）程序模块直接关联的“全局变量”个数（11）程序模块关联的“全局变量”列表 列表给出程序模块关联的全局变量（包括“数据类型”、“变量名”、“关联方式”“读”/“写”/“读写”）（12）程序模块可见的全局性数据结构（例如系统数据文件等）数（13）程序可见的全局性数据结构列表 列表给出模块可见的全局性数据的数据类型名、成员个数、成员列表（成员的数据类型、成员名）以上内容为程序模块的“规格说明”所包含的系统设计信息。除此之外，用户还应提供：（14）程序模块的局部变量数 这里所指的“局部变量”是除模块参数外的、用户在进行模块的流程图设计前为模块确定的“工作变量”，对一个具体的模块，该值可为“0”（15）程序模块的局部变量列表 列表给出已确定的局部变量的“数据类型”、“变量名”关于程序模块的局部变量，为方便用户的设计，本系统提供相应手段，使得用户可在交互设计过程中添加。 3. 当用户选择了“创建”操作后，系统将展示一个交互屏幕以接收用户提供的上述系列输入。对于“创建”操作，对应的系统输入数据结构的定义为： 程序模块的“参数列表”关联系统输入数据结构及其相关系统处理 相应输入数据结构的数据类型定义： typedef struct /* 模块“参数列表”对应的输入数据类型定义 */int idparmtype； /* 参数数据类型编码 */int idusagparm； /* 参数的作用类型编码 */char * parmname； /* 参数名 */MODPARL；对之，作简要说明如下：（）“参数的数据类型编码” 为简单的顺序编码，实际上是在输入过程中由相应程序模块将系统中预先存放的参数类型名列表显示出来（“弹出窗口”），供用户选择。在用户选定后，相应的参数类型名被放置在屏幕的“参数类型名”文本窗口中（“弹出窗口”关闭）。相应输入处理模块将其转换为系统内部的数据类型代码（）“参数作用类型编码” 输入过程中的处理同“参数数据类型”，相应代码为 “1” “输入” “2”“输入/输出”（）若模块的“参数个数”不为“0”，则面向每个参数，要求用户提供上述三个输入，由此形成一个MODPARL 类型数组与“参数表”输入数据结构相关联，系统的处理策略可概述为：（）与数据类型MODPARL（MODPARL *）相关联，设置几个程序模块来处理模块的“参数表”输入问题，它们实现对输入数据的合法性、变换相应数据的用户可见描述为系统内部表示等（）系统中设置有一个“系统数据类型名一览表文件”（参见后续相关部分的说明），文件的有效记录保存了系统目前可识别的各种数据类型的有关信息。在模块“参数表”输入过程中系统显示出的“数据类型名列表”（据之，用户可以指定参数等的数据类型）即是来自于该文件（）系统中设置有一个“参数列表文件”（参见后续相关部分的说明），保存了所有模块的参数信息。“参数输入处理”要完成将用户输入的参数信息转换为该文件记录的工作（）与数据类型MODPARL（MODPARL *）相关联的系统模块（称为“函数”，下同）为： （a）参数名合法性检查函数 （b）转换参数输入信息为“参数列表文件”记录函数 模块的“局部变量列表”关联输入数据结构及其系统处理 typedef struct /* 模块“局部变量列表”对应的输入数据类型定义 */ int idlocaltype； /* 局部变量数据类型编码 */ char * localvnam； /* 局部变量名 */MODLOCAL；其中“局部变量数据类型编码”同上述“参数类型” 模块的“全局性变量关联”信息对应的系统输入数据结构及其系统处理 typedef struct /* 模块直接关联的全局性变量列表对应的输入数据类型 */ int glbvaltype； /* 全局性变量的数据类型编码 */ char * glbvalnam； /* 全局变量的变量名 */ int idrelatglbmd； /* 模块与相应全局性变量的关联方式编码 */GLOBVAL；其中，“全局性变量的数据类型编码”同上述“参数类型”；“模块与相应全局性变量的关联方式编码”取“1 读”、“2 写”、“3 读/写”，交互屏幕上的处置同“参数类型” 模块可见的“全局性数据结构”信息对应的系统输入数据结构及其系统处理 # define MAXMEMB 20 /* 全局性数据结构的最大成员数 */ typedef struct /*“全局性数据结构”的成员对应的输入数据类型 */ int membtype； /* 成员数据的数据类型编码 */ char * namofmemb； /* 成员数据的名 */GLDMEMB； typedef struct /* “模块可见全局性数据结构列表”对应的输入数据类型 */ int codtypgld； /* “全局性数据结构”的分类特征编码 */ char * gldtypnam； /* “全局性数据结构”的数据类型名 */ int quanmemb； /* “全局性数据结构”的成员个数 */ GLDMEMB memblistMAXMEMB； /* 成员数据列表MODRALGLD；对之，作简要说明如下： （）“成员数据的数据类型编码”与“参数类型”同； （）“全局性数据结构的分类特征编码” “1 数据文件”、“2 数据缓冲”、“3 输入数据结构”、“4 输出数据结构”；目前系统中仅考虑“全局性数据结构”为“数据文件”的情况； （）本系统假定，“全局性数据结构”的数据类型都已被用typedef 定义为一个确定的“名字” 程序模块系统信息对应的系统输入数据结构及其系统处理 # define QUANMPMAX 9 /* 一个模块的最大参数个数 */ # define QUANCMMAX 8 /* 一个模块引用模块的最大数 */ # define QUANGBMAX 5 /* 一个模块关联的最大全局变量数 */ # define QUANGDMAX 3 /* 一个模块可将的全局数据结构的最大值 */ # define QUANLVMAX 30 /* 一个模块的局部变量的最大个数 */ typedef struct /* “创建”操作的输入数据结构定义 */char * modelnam； /* 程序模块名 */char * modelfun； /* 模块功能说明 */int idtypmod； /* 模块的分类特征编码 */int rtdtypmod； /* 模块的返回值类型编码 */int prmfeatcod； /* 模块的参数特征编码 */int quanprmmd； /* 模块的参数个数 */MODPARL parmlistQUANMPMAX； /* 模块的参数表 */int quanclsub； /* 模块所引用的程序模块数 */char * calsublistQUANCMMAX； /* 所引用的模块名列表 */int quanglvb； /* 模块直接关联的“全局变量”数 */GLOBVAL glbvallistQUANGBMAX； /* 模块引用的“全局变量”列表 */int quangldatut； /* 模块可见的“全局性数据结构”数 */MODRALGLD gldlistQUANGDMAX； /*模块“全局性数据结构”列表*/int quatlocal； /* 模块的局部变量数 */GLDMEMB locallistQUANLVMAX； /* 模块局部变量列表 */CREATINDT；对之，作简单说明如下： （）“模块的返回值类型编码”与“参数类型”的编码同； （）“模块的分类特征编码”的系统处置与“参数类型”的系统处理机制相同，相应编码为“1 原子模块”、“2 普通模块”、“3 总控模块” （）关于模块的“局部变量”的系统描述信息对应的数据类型与“模块可见的全局性数据结构”的“成员”列表具有相同的数据类型（参见前相关讨论）4. 在用户向系统提供上述系列输入时，系统将对用户的输入进行系统检查，在检查确认用户的输入合法有效后，系统将相关信息存入系统数据库，并以之约束用户随后的流程图信息处理。程序模块系统信息相关的输入处理主要包括：（1）“程序模块名”、“参数名”的处理 由程序设计相关知识可知，“程序模块名”（包括“子程序”名）和“参数名”都遵循“普通标识符”规范。因此，对之，系统的输入处理部分首先要进行“合法性”检查，确认它们的合法有效性。若发现其不符合相应的形式规范，则显示相应的错误消息，并要求用户重输。在它们的合法性得到确认后，输入处理部分要将其存入系统名字表（利用“名字表”部分的相应模块），并相应保存其“系统名字表索引”（2）“全局变量名”、“局部变量名”的处理 在程序设计的角度来看，“全局变量名”、“局部变量名”、“程序模块名”和“参数名”都是程序设计语言中的“普通标识符”；然而，从系统管理程序流程图信息的需要出发，“全局变量名”、“局部变量名”与前两种情况仍然略有区别。这是因为，“全局变量名”和“局部变量名”可能是与模块可见的“全局性数据结构”关联定义（声明）的（此时，相应“名字”的形式构成略有区别）。对之，有以下几点值得引起注意：（）“全局变量”的数据类型可以是“构造类型”（从软件工程的观念来看，这是应当尽量避免的，由此将引起人们不期望出现的“公共耦合”）也可以是非构造类型（“简单类型”）。当“全局变量”的数据类型为“简单类型”时，“全局变量名”遵循“普通标识符”规则；当一个“全局变量”的数据类型为“构造类型”时，有两个问题是通常人们在进行程序设计是很少关注的（注意，这里所论及的“构造类型”/“简单类型”是本系统的划分，下同，不另说明）： （a）此时，对于该模块，相应“构造类型”是其可见的“全局性数据结构”； （b）相应模块的程序流程图中（程序中）可能出现如下形式的“全局变量”：全局变量名.成员变量名（）在模块的参数中，可以存在“构造类型”（包括以“构造类型”为基类型的指针）的参数，这表明，模块对该“构造类型”是可见的。对于这样的“构造类型”，在模块内部还可以根据需要声明（或称“定义