11菜单树

 

《树型软件工程方法》之系列博文11

菜单树

 

 

 

 

 

TREESOFT

                             目  录

11 菜单树. 1

11.1 菜单的意义.... 1

11.2 菜单的选取.... 1

11.3 菜单的种类.... 3

11.3.1 主菜单.... 3

11.3.2 右键莱单.... 5

11.3.3 图标莱单.... 5

11.3.4 隐含莱单.... 5

11.3.5 莱单的分类管理.... 5

11.4 结束语.... 6

中国人为什么不可以有自己的软件工程方法与开发工具平台！

这是介绍《树型软件工程方法》的系列博文，请按文章标题所带的编号顺序阅读，否则你会看不懂本文。

11 菜单树

   本文将要讨论菜单树。我们将会看到，系统的菜单树是与事件树密切相关的，

有时甚至会因为菜单设置的需要而修改事件树。

11.1 菜单的意义

   我们知道，大多数系统都会有菜单。当要启动一个系统运行时，我们会双击以.exe

作为 扩展名的相应的系统文件名，这也相当于双击了菜单“系统名.exe”。从这个意

义上 说，任何系统都有菜单。

   系统中凡需要人工启动运行的功能都必须形成菜单。

   上述断语指出了设立菜单的意义。人工启动就是人工干预系统的运行，菜单设置得

不合 理会影响运行效率，系统的运行人工干预愈少愈好。所以，上述断语之后还应加

上 一句 话：凡不需要人工启动运行的功能都不应该形成菜单。这样，当你要确定某项

功能 为菜 单时就会谨慎地考虑，尽量不要去干预系统的流畅运行。断语中笼统地说某

项“功 能”，如何来确定它呢？既然是可以独立运行的功能，必定是 能完成某项功能

的完备的 程序模块。由此前系列博文的叙述可知，在树型软件中可以独 立完成某项功

能的模块 有；

   1) 作业子树

   2) 任务子树

   3) 事件子树

   我们知道，启动菜单运行程序直至正常结束，必定会产生数据，而且必定是终结数

据而不会是中间数据。因为，既然程序都已经运行结束，其生成的数据必定处于静态。

所以 “作业子树”和“任务子树”都不具备作为功能菜单的条件。原子事件(名)是可

以作为 菜单的，因为它的功能就是封闭地加工生成终结数据。高级事件(名)也可以作

为菜，虽然它不直接生成终结数据，但以它为根的事件子树是会生成终结数据的。于是

就有结论：

   菜单能且只能是事件，事件树中的任何节点都有资格充任菜单。

11.2 菜单的选取

   我们知道，事件树是系统的结构树，所有需要输出的终结数据都是由原子事件生成

的。所以，系统所需要设置的菜单尽在事件树中，事件树中任何节点都有资格充任菜

单。

   系统的菜单尽在事件树中。将事件树中不需要形成菜单的子树剪掉后就得到了

菜单树，菜单树的节点都是事件树的节点，根节点就是事件树的根。

   上述断语总的意思是，菜单树同事件树的结构类同，菜单树中有的节点事件树中必

定 有，但事件树中有的节点菜单树中就不一定有。也不好将莱单树说成是事件树的子

树，其并不是以任意节点为根的子树，其根仍然是事件树的根，只是有的枝叶可能被剪

除 了。这个结论指出了生成菜单的必要条件，有了事件才能生成菜单，没有事件是无

法生 成菜单的。并且把菜单树的结构形状固定了，每个菜单节点的位置也固定了。菜单

同事件相对应的道理很简单。如前所述，每一棵事件子树都承担着系统的一项功 能，而

每条菜单的作用也是要启动运行一项功能，两者正好相互吻合。事件的等效处理 正好对

应着菜单的分层调度运行，菜单树与事件树的天然对应关系是由现实世界的用户 需求确

立的。

   现在，我们要将事件树中不需要形成菜单的子树都剪掉，只留下需要人工启动运行

的节 点。将事件树剪切成菜单树有如下规律。

   (1) 在事件树中确立菜单时，凡被指定为菜单的事件节点的祖辈节点都必须被

指定为菜单。

图11.1 菜单树示意图

   如图11.1所示。图中凡被标注为“m”的节点，表示该节点被选取为菜单。节点a1

和 a2 没有被选取作为菜单，它们的父亲h1是菜单，说明启动h1后就会运行以h1为根的

子 树，a1和a2将在没有人工干预的情况下连续运行。另一棵以h2为根的子树却不同，

不仅父节 点h2被选为菜单，h2的两个儿子a4和a5也被选为菜单。这意味着启动h2并不能

立即运行 以其为根的子树，点击h2只会下拉出由a4和a5组成的下级菜单表。这就是上述

断语所指出的，需要人工启动的是a4和a5，却连带它们的父亲h2也被指定为菜单。

   上述断语成立的理由很简单，因为下级事件总是由上级事件管理的，不经由上级事

件是 到达不了下级事件的，当然也就启动不了下级事件。这也与现实社会的管理架构

一 致，凡事总是自上而下逐级下达处理指令的。所以，系统介面上会有第2级甚至第3

级菜 单，任何系统的“.exe”文件就是该系统菜单树(事件树)的根节点。

   (2) 在同一个等效事件集中，只要有一个元素被选为菜单，其全部元素必定都

是 菜单。

   上述断语也可以换一种说法：对于事件树中的某等效集，或者其元素都是菜单，或

者都 不是。在图11.1中，假定a4被指定为菜单而a5不被指定为菜单，那么a5的运行只

能由启 动h2来实现。然而，h2还要承担下拉出菜单a4的功能，h2不可能同时承担这两项

相悖的 功能。所以，唯一办法就是将h2的儿子都指定为菜单。或许的确存在这种现

象，同一个等效集中有的元素必须被指定为菜单，有的却不必人工启动。这种情况下应

该检查 事件树的结构是否合理，采取适当措施调整事件树。将不需要人工启动的事件组

成一个等效集，需要人工启动的事件组成另一个等效集。如此就一定能适应上述断语所

指出的规 律。人们或许会担心，这种做法会过多地增加菜单树(事件树)的深度，影响运

行 效率。不会的，除去项目根事件外，工程实践中一般最多只会下拉出两级菜单。

   (3) 需要连续不间断运行的工序链上的事件都不需要形成菜单，它们应该单独

组成 一个等效集。

   这里首先要澄清一个概念：并非所有的工序链上的事件都必定是要连续运行的。由

工序关系的定义可知，a→b表示事件b必须等待事件a的处理结果，并没有“a运行结束后b必须立即接着运行”的意思。a运行结束后为b的运行创造了条件，b可以立即自动运行，也可以由人工点菜单运行。最典型的例子是编辑系统中的“选取”(涂黑字符串)是“删除”的前导，但选取后并不允许自动删除，必须由人工启动“删除”菜单。所以，“选取”执行之前“删除”是灰暗不可用的，“选取”执行后“删除”才变成明亮可用。既体现了它们之间的工序关系，又实现了“删除”的选择执行。

   如果工序链上的事件都是依序连续自动运行的，当然就不需要形成菜单。将它们独

立组 成一个等效集后，点击它们的父亲就可连续自动运行这些事件。图11.1中的a1和

a2就是 两个连续自动运行的事件，点击它们的父亲h1就可以连续自动运行它们。在许多

大型的 系统中，经常会有这类连续自动运行的工序链。

11.3 菜单的种类

   软件系统的运行画面上会有多种类型的菜单：主菜单，右键莱单，图标莱单，隐含

莱 单。它们的共同特上是：都对应着一个需要人工启动的事件，都能完成一项能生成

终结数据的功能。

11.3.1 主菜单

   什么叫主菜单？我们将系统启动后显示的首栏莱单及由它们下拉出的菜单，都称为

主菜 单。主菜单的取名似乎不甚贴切，好在后面的“右键莱单”、“图标莱单”和

“隐含莱 单”的取名意义都很明确，不会与“主菜单”的取名混淆。

图11.2 文本编辑工具软件的第一级主菜单

   我们还是来看具体的例子。图11.2是文本编辑工具软件主菜单树的第一级莱单，该

图就是从博文《事件树》的图10.13拷贝过来的。图10.13是文本编辑工具软件的项目结

构 树，根节点是项目根事件，叶节点是各系统的根事件。在这个项目中，项目根事件

和系 统根事件都必须人工启动，都必须列为菜单，所以图11.2的菜单树与图10.13的事

件树 完全相同。点击图11.2中各系统的根事件，就可以下拉出相应系统的第二级菜单。

   我们曾在博文 《事件树》中构造出“编辑”系统的事件树，现将其拷贝于图11.3，

我们将从这棵事件树剪出编辑系统的菜单树。可以看出，除事件a1不能作为主菜单外

(原因待后叙述)，该事件树中的其它节点都必须指定为菜单。如此，则相应菜单树

就有5级，显然是太深 了，不合适。造成菜单树太深的原因当然是事件树太高，解决的

办法 只有修改事件树。

图11.3 文本编辑工具软件编辑系统的事件树

   图11.4是调整过的“编辑”系统的事件树，它只有3层，比图11.3中的事件树少了2

层。两树相比作了如下修改：

   1) 去掉了高级事件h3。

   2) 去掉了高级事件h2。

   3) 原子事件a2、a3、a4和a5组成了等效集，作为高级事件h1的儿子。

   4) 高级事件h1负责管理a2、a3、a4、和a5，所以除原来调度a5的功能外，它还将

承 担原h3调度a2和a3，原h2调度a4的功能。

图11.4 结构调整后的编辑系统事件树

   为了标注工序关系，图11.4中h1的儿子们都在节点注释部的园括号中标有相应事件

的前 导。例如事件a4标有(a2/a3)，说明a2和a3都是它的前导，仅当这两个事件中有一

个运 行过(剪贴板中有内容)，a4才允许运行。采用这种办法标注工序关系，是因为箭

头式标 注没有办法标记多前导。此前我们也说过，同一个等效集内不会出现多前导或

多后继，这里为什么允许呢？原理上的确是不允许的，所以图11.4中的事件树是非规范

的。由于 它并没有影响到系统的树型结构，工程上的这样处理还是允许的。这种减少

高级事件的 处理办法叫“管理扁平化”。现实社会的机构改革也经常采用这种方法，适

当的管理扁 平化可以提高系统运行效率。但无论如何，系统结构树的改动都必须遵循

“等效处理 法”，管理扁平化是在原理性事件树(如图11.3)的基础上进行的。实际上，

图11.3和图 11.4中两棵事件树的运行效率相差并不大，只是后者比前者的菜单下拉深度

更浅，提高 了管理效率。

   图11.4中的节点a1去掉后，就是“编辑系统”的主菜单树。

11.3.2 右键莱单

   所谓“右键莱单”，即在窗口画面上点击鼠标右键，系统就会弹出列有菜单的窗

口，这 些菜单都是针对光标当前所指对象可以进行的操作。右键莱单是一类菜单，所

以其每一条菜单都必定对应于事件树中的相应事件。譬如对于 图11.4的事件树，若已经

选取了字符串(执行了a1而涂黑了字符串)，点击鼠标右键后所 弹出的窗口中就会列出菜

单“拷贝”、“剪切”、“删除”。右键莱单窗口的弹出及其 菜单的管理功能，也是由

事件树中的高级事件实现的。譬如上面所举的那个右键莱单及 其窗口的管理，就是由高

级事件h1实现的。

   右键莱单都可以是主菜单。

11.3.3 图标莱单

   图标莱单也是我们所熟悉的，人们以形象的小图形表示菜单。既然是菜单，图标莱

单也 必定对应于事件树中的一个事件，点击某图标就相当于启动了相应功能的事件子

树。 与主菜单和右键莱单类似，图标莱单也是由高级事件管理的。譬如图11.4的事件

树中， “拷贝”、“剪切”、“粘贴”、“保存”都可以是图标莱单，对它们的管理就

由h0和 h1实现的。。

   图标莱单也可以是主菜单，有的图标莱单还可以是右键莱单。

11.3.4 隐含莱单

   所谓“隐含莱单”，实际就是没有菜单，或者说相应事件的启动无法用显式菜单标

出。譬如图11.4事件树中的a1事件，就不能被标记成主菜单、右键莱单或图标莱单，只

能是 隐含莱单。该事件的执行是隐含在用户操作过程中的，当操作者将光标对准某字

符，然 后按住鼠标左键水平移动光标时，事件a1就会将光标水平移动所涉及的字符串

变黑，以 表示选取了该字符串。隐含莱单的例子也不少。窗口的拖动，窗口边框线的

推拉，文本游标的上下拉动等等， 都属隐含莱单。

   隐含莱单既不可以是主菜单，也不可以是右键莱单或图标莱单。

11.3.5 莱单的分类管理

   实际上，菜单如此分类并非人们凭空想出来的，也是从现实生活中归纳模拟过来

的。当 你在饭馆坐下来准备点菜吃饭时，服务员会给你菜单簿让你点菜，菜单簿上所

列 出的就 是“主菜单”。在讲究点饭馆，菜单薄上的主菜单下还会有相应菜色的相

片，这就是 “图标莱单”。你所坐等的桌子上往往还会有一张过胶的小菜单插在塑料架

上，上 面会 列出本饭馆的特色菜或打折菜，有的是将这类菜单贴在墙壁上，这差不多

就是“右键莱单”。“套餐菜单”更为接近“右键莱单”，它是因人而异的组合菜单。

吃自助餐大概算是“隐含莱单”吧，你随心所欲地拿取菜食的过程就完成了点菜。

   这么多种类的菜单，系统是如何管理的呢？在饭馆，点完菜后要在点好的菜单上写

上餐 桌编号，以便按单送菜。计算机系统也是这样，只不过信息的传递人们看不见。

无论你 在桌面上操作哪类菜单，菜单所在的位置总是有坐标的，所做的操作总会产生硬

件中断，操作系统会从硬件接口获取中断信息及其中断类型，然后将这些信息返馈给应

 用系 统。在以事件树为结构树的系统中，是由项目根事件接收操作系统送来的这些信

息，然 后根据信息中的内容沿事件树的管理架构自上而下逐级分发传递，直至应该执行

相应中 断处理的事件。

   譬如文本编辑工具软件。假如桌面上有“按住鼠标左键水平移动”的操作，显示器

的硬件接口就会产生中断信号，操作系统捕捉到该信号后就会将相关信息一并返馈给文

本编 辑工具软件的项目根事件。然后，由项目根事件再分发给“编辑系统”的根事件

(图 11.4中的)h0，再由h0启动a1运行，涂黑字符串。

   硬件中断信息的发生、捕捉、收集、分发等是相当复杂的过程，不是三言两语能说

得清 楚的。这里主要是为了说明事件树对菜单的管理，同样是自顶向下逐级进行的。

Windows的消息处理机制就是典型的中断处理机制，差不多也是按树型结构逐级传递处

理的。只不过Windows编程的有些规定绑住了程序设计者的手脚，很难按等效处理法分

离出各级事件。

11.4 结束语

   本文内容很简单，颠来倒去地就只说了一句话：菜单必定对应于一个事件，菜单树是剪除事件树中不必人工启动的子树后的剩余树。

转载于:https://my.oschina.net/treesoft/blog/85838