《树型软件工程方法》之系列博文13
树型软件开发步骤
TREESOFT
目 录
中国人为什么不可以有自己的软件工程方法与开发工具平台！
这是介绍《树型软件工程方法》的系列博文，请按文章标题所带的编号顺序阅读，否则你会看不懂本文。
13 树型软件开发步骤
博文《树型软件结构模型》可以说是对树软法理论的概述，本文将会以开发步骤的方式，给出树软法工程的概述。
13.1 分析与设计步骤
在博文《树型软件结构模型》中，我们用“树型软件模型图”形象而确切地刻划了树型软件的结构。实际上，这个模型图不仅刻划了树型软件的结构，它还给出了树型软件的开发方法。
树型软件的开发步骤是：沿模型图从外向内逐级分析与设计，自内向外逐级编码与调试。
从外向内的分析与设计：用户需求是包袱模型图的最外层，所以需要将其整理成《需求说明书》；事件树是架接于用户需求与计算机软件之间的桥梁，原子事件是构造事件树的基石，所以系统分析的主要目标就是确立原子事件；树型软件的结构是以事件树、任务树和作业树逐级嵌套表示的，所以系统设计的目标就是要构造设计出这三级结构树。
自内向外的编码与调试：作业由顺序执行的操作组成，编码自然是从位于模型图最内层的操作开始。将操作编码成程序语句，当然要将事物信息化，即要用位于模型图核心圈的字符来表示过程名、变量和算符。以操作、作业、任务、事件、系统或事件子树为单元，即是自内向外的逐级调试。最后是项目的整体测试，回到了模型图的最外层，将软件交付给用户。
按照上述断语，树型软件的开发步骤分为四段14步，前三个阶段属于分析与设计，最后一个阶段是编码与调试。
A. 需求整理
(1) 编写《需求说明书》。
B.系统分析：
(2) 按业务大类划分系统，构造系统树。
(3) 理出各系统的作用事物。
(4) 按“主-谓-宾”短语理出“主体作用对象”的底层case。
(5) 确立原子事件。
(6) 为终结数据建模。
C.系统设计：
(7) 按业务分类组成等效集，自底向上搭建事件树。
(8) 标志需要形成菜单的事件，形成隐形菜单树。
(9) 以求解终结数据为目标，将原子事件划分成任务，组建任务树。
(10) 按任务的求解算法，设计作业树。
D.编码调试：
(11) 在遍历编程各级结构树生成的程序框中，编码操作与作业。
(12) 程序调试，对各级结构树做必要的修改。
(13) 整体测试。
(14) 上线交付。
13.2 编写《需求说明书》
编写需求说明书实际就是写一份科技报告。报告的作用是要把一件事说清楚，将大概念逐级细化具体。这种分层描述的方式正好与树型软件的分析嵌套结构相符。可见编写需求说明书并不难，但却非常重要，它是后面分析、设计、编码、调试、测试等等的原始依据。既要客观全面，又要清晰明了。
实际上，用于树型软件工程开发的需求说明书是有格式要求的。既然树型软件的程序是分层嵌套的，用自然语言编写的《需求说明书》也应该分层编排。这并不是什么特殊要求，而是最普通、最常用的科技报告的编写方式。
(1)项目名就是需求说明书的“报告名”。
这点要求最简单，就是为需求说明书取一个恰当的报告名，其形式地对应于项目系统树的根事件。一般而言，报告的开始总会对报告的主要内容做一个概括性简介，这个简介可以说是系统树根事件的功能说明。以前述的文本编辑工具软件为例，其《需求说明书》的报告名当然是“文本编辑工具软件”。
(2) 按业务大类划分“章”。
科技报告当然是按编、章、节、条、款分层书写的。我们这里以“章”为最高级的款目，每一章叙述项目的一个业务大类，亦即对应于项目的一个系统，所以章的题目形式上对应于系统节点的“系统简称”。以博文《事件树》中的图10.13文本编辑工具软件的系统树为例，该项目的需求说明书应该含有如下章：
1 文件
2 编辑
3 视图
4 插入
5 格式
6 工具
(3) 按业务分类划分：节、条、款。
接下来就是对每一章所包含的业务的叙述，当然是分节、条、款叙述。书写时应该有等效处理的理念，每一节、条、款都有可能对应于一个事件。以博文《事件树》中的图10.11文本编辑工具软件的编辑系统事件树为例，该项目需求说明书第2章“2 编辑”的各节、条、款的内容安排如下：
2 编辑
2.1 选取
2.2 粘贴与删除
2.2.1复制粘贴
2.2.1.1 复制
2.2.1.1.1 拷贝
2.2.1.1.2 剪切
2.2.1.2 粘贴
2.2.2 删除
2.3 查找替换
2.3.1 查找
2.3.2 替换
2.4保存
既然认为编写《需求说明书》同写科技报告相同，也不必刻板地认定节、条、款对应于事件，分层细化逐级编写就可以了。后面的系统设计会区分出各级条款所描述的case：是事件还是任务，或者什么也不是。
(4) 详尽地描述最低级条款的case。
实际上，需求说明书的主要内容都在最低级的条款中，是需要全面仔细地叙述的。最低级条款的case可能是事件或任务，对它的描述就包含有：
详尽的业务规则，清晰的处理过程，明确的生产结果。
13.3 系统分析
如前所述，树软法系统分析的主要任务是要构造出事件树；原子事件是事件树的基石，构造事件树的主要任务就是要确立原子事件；原子事件以生成终结数据为目标，为终结数据建模等价于确立了原子事件。下面，我们就来按上述思路来进行树软法的系统分析。
13.3.1 按业务划分系统，构造系统树
有了《需求说明书》后，就可以进行系统分析的第一项工作，将“项目”按业务大类化分成系统，以此构造出系统树。实际上，一个项目由哪几个业务系统组成，需求单位的日常业务运作就已经形成了。项目组进驻需求单位接触用户需求后就能明确地分出业务系统，并据此分别委派主管设计师负责系统调查。接下来我们将以“图书管理系统”项目为例，逐项叙述树软法的开发步骤。
假定已经编写出了图书管理系统项目的需求说明书，该项目的名称为“图书管理系统”，其就是项目系统树的根事件。需求说明书分为如下几章：
(1) 借阅者自助系统；
(2) 借书业务系统；
(3) 管理维护系统；
图13.1 图书管理系统项目的系统树
上述各系统的具体内容当然也在需求说明书中有详尽的叙述，这将在后面的叙述中逐步了解。如此，就可以构造出该项目的系统树，如图13.1所示。
值得指出的是，系统的划分一定是依据项目的功能分类，而不是按参与者划分的。图书管理系统项目似乎是按“借阅者”、“图书管理员”和“系统管理员”的话动划分的，这实际上是巧合，本质上仍是按功能分类划分的。譬如早前所举的例子“文本编辑工具软件”项目，其只有编辑者这一类参与者，但该项目却被划分成至少六个系统(参见博文《事件树》的图10.13)，都是按功能集成的。
顺便指出，一个项目可能只有一个系统(甚至只有一个事件/一个任务/一个作业/一项操作)，则构造系统树的工作就是象征性的。
13.3.2 理出作用事物
将项目划分成系统后，接下来的工作目标就是要构造出系统的事件树。原子构件(原子事件及其终结数据的结合体)是事件树的基石，原子事件是由主体作用于对象而生成终结数据的。终结数据是由基本事物组成的，分析基本事物集中约束事物的活动情况以及活动产生的结果，就可以建立终结数据模型。由此前的叙述可知，基本事物集由如下基本事物组成：
时间: t (time)
地点: p (place)
主体: s (subject)
方法: m (method)
对象: o (object)
结果: R (Results)
此外，我们又称s和o为作用事物，事件就是由主体作用于对象而形成的。而这其中，主体又起到了主导作用，没有主体也就谈不上与对象的作用，也就没有事件的发生。所以，主体事物是原子事件存在的决定性事物，当然也就是系统存在的决定性事物。主体事物的确立并不需要等待基本事物集的确立，因为他们是系统活动的发起者，从《需求说明书》中很容易理出他们。显然，参与图书管理系统活动的作用事物有四类：
图书借阅者
图书管理员
系统管理员
图书
上述四类作用事物中，前三类充当主体事物时， 它们的作用对象都有图书。此外，这三类主体事物也都会充当对象事物：系统管理员添加借阅者，系统管理员添加图书管理员，超级用户添加系统管理员。“图书”则只充当对象事物，是前三类事物的作用对象。
13.3.3 列出主体事物产生的case
所谓“case”，即事物活动情况，需求说明书中任何一级的任何一个标题都概括了一个case。事件树的构造是从原子事件开始自底向上的，则原子事件应该在需求说明书的最底层，亦即各个业务方面分层叙述的最低一级的条款。从这些条款标题中可以明晰出以“主-谓-宾”短语描述的case，它们都是原子事件的候选对象，它们求解的目标数据则是终结数据的候选对象。
对于图书管理系统项目的三个系统，按照“主-谓-宾”的格式，分别可以罗列出如下最底层的case：
(1) 借阅者自助系统(主体都是借阅者)
·登录系统。
·查询图书。
·查询自身信息。
·预约借书。
(2) 借书业务系统(主体都是图书管理员)
·登录系统。
·处理借阅。
·处理归还。
·查询图书。
·查询借阅者信息。
·添加借阅者记录。
·删除借阅者记录。
·修改借阅者记录。
(3) 管理维护系统(主体都是系统管理员)
·登录系统。
·查询图书管理员信息。
·添加图书管理员记录。
·修改图书管理员记录。
·删除图书管理员记录。
·查询图书信息。
·添加图书记录。
·修改图书记录。
·删除图书记录。
13.3.4 确认原子事件
罗列出了主体作用于对象的case之后，还需要进一步确认存在于这些case中的原子事件。这些case可能并不包括系统的全部原子事件，但大部分原子事件都会在这些case中。这些case可能并不全部是原子事件，有的可能是高级事件或某原子事件的任务。正因为如此，才需要确认原子事件这一步。
在树型软件中，系统功能是用原子事件来描述的，拥有终结数据的case就有资格充任原子事件。确立原子事件的依据仍然是用户需求，要对罗列出的case逐个分析，看它们最终产生的目标数据是不是终结数据。当然，由于拥有终结数据的case也可以不被确立为原子事件，原子事件可以拥有多个终结数据，这一步对原子事件的确立可能并不十分准确。这没关系，在后面的设计中发现问题可以随时修正。现在，我们来逐个分析图书管理系统项目中被罗列出的case。
(1) 借阅者自助系统中的原子事件
·登录系统。
这个case的功能是：借阅者在自助终端上输入“借阅者代码”，若系统中有相应代码的借阅者，则允许其登录，否则拒绝登录。登录后，屏幕将显示供借阅者使用的界面，该界面就是终结数据，所以本case是原子事件。
·查询图书。
这是一个复用事件，功能将在“管理维护系统”中叙述。
·查询自身信息。
这个case的功能是：当借阅者在自助终端上输入其自身的“借阅者代码”后，若系统中有相应代码的借阅者，则应将该借阅者的属性记录显示于终端屏幕。所以，这个case是原子事件，屏幕显示数据即为其终结数据。
·预约借书。
借阅者登陆系统后，可以点击“预约借书”菜单，终端屏幕将弹出供预约借书用的窗口。输入预约的图书代号及预订日期等信息后，回车或确认，系统就会将这些信息写入“预约图书库”。所以这个case是原子事件，预约图书库即为终结数据。
(2) 借书业务系统中的原子事件
·登录系统。
这个case的功能是：图书管理员在工作终端上输入“图书管理员代码”，若系统中有相应代码的图书管理员，则允许其登录，否则拒绝登录。登录后，屏幕将显示供图书管理员使用的界面，该界面就是终结数据，所以本case是原子事件。
·处理借阅。
本case的功能是：图书管理员在工作终端上输入输入“借阅者代码”，检查借阅者是否超出借阅规定；如果借阅者未超规，则输入似借阅的“图书代码”，如果有此图书则检查图书是否有库存；如果图书有库存，则将库存数减1后写《图书参数库》。打开《借书登记库》，将记录“图书代码，借阅者代码，借阅日期”写入该数据库。最后将书给借阅者。本case是原子事件，它有两个终结数据：修改了记录的《图书参数库》的“库存数”和添加了《借书登记库》的记录，后者为其目标终结数据。
·处理归还。
本case的功能是：图书管理员收回图书。在工作终端上输入已借阅的“图书代码”，如果有此图书则将库存数加1后写《图书参数库》。然后输入“借阅者代码”，读入《借书登记库》记录，输入还书日期后写库。本case是原子事件，它有两个终结数据：修改了记录的《图书参数库》和修改了记录的《借书登记库》，后者为其目标终结数据。
·查询图书。
这是一个复用事件，功能将在“管理维护系统”中叙述。
·查询借阅者信息。
本case的功能是：图书管理员登录系统后，可以查询任何借阅者的信息，既可以单个借阅者查询，也可以列表浏览查询。本case是原子事件，终结数据是显示于屏幕上的借阅者参数库记录。
·添加借阅者记录。
本case的功能是：图书管理员登录系统后点击相应菜单，屏幕上便会显示一个表格，系统管理员应将欲添加的“借阅者代码”及其它参数填入。录入结束后，系统便会在借阅者参数库中添加新借阅者的记录。显然，本case是原子事件，终结数据是添加记录后的借阅者参数库。
·修改借阅者记录。
本case的功能是：图书管理员登录系统后点击相应菜单，系统将要求输入欲修改的“借阅者代码”，屏幕显示相应借阅者的参数库记录供修改。确认修改后，系统将该记录覆盖写入借阅者参数库。本case是原子事件，修改记录后的借阅者参数库即为终结数据。
·删除借阅者记录。
本case的功能是：图书管理员登录系统后点击相应菜单，系统将要求输入欲删去的“借阅者代码”，屏幕显示相应借阅者的参数库记录。确认删除后，系统将从参数库中删除该记录。本case是原子事件，删除记录后的借阅者参数库即为终结数据。
(3) 管理维护系统中的原子事件
·登录系统。
这个case的功能是：系统管理员在工作终端上输入“系统管理员代码”，若系统中有相应代码的系统管理员，则允许其登录，否则拒绝登录。登录后，屏幕将显示供系统管理员使用的界面，该界面就是终结数据，所以本case是原子事件。
·查询图书管理员信息。
本case的功能是：系统管理员登录系统后，可以查询任何图书管理员的信息，既可以单个图书管理员查询，也可以列表浏览查询。本case是原子事件，终结数据是显示于屏幕上的图书管理员参数库记录。
·添加图书管理员记录。
本case的功能是：系统管理员登录系统后点击相应菜单，屏幕上便会显示一个表格，系统管理员应将欲添加的“图书管理员代码”及其它参数填入。录入结束后，系统便会在图书管理员参数库中添加记录。显然，本case是原子事件，终结数据是添加记录后的图书管理员参数库。
·修改图书管理员记录。
本case的功能是：系统管理员登录系统后点击相应菜单，系统将要求输入欲修改的“图书管理员代码”，屏幕显示相应图书管理员的参数库记录供修改。确认修改后，系统将该记录覆盖写入图书管理员参数库。本case是原子事件，修改记录后的图书管理员参数库即为终结数据。
·删除图书管理员记录。
本case的功能是：系统管理员登录系统后点击相应菜单，系统将要求输入欲删去的“图书管理员代码”，屏幕显示相应图书管理员的参数库记录。确认删除后，系统将从图书管理员参数库中删除该记录。本case是原子事件，删除记录后的图书管理员参数库即为终结数据。
·查询图书信息。
本case的功能是：系统管理员登录系统后，可以查询任何图书的信息，既可以查询单本图书，也可以列表浏览查询。本case是原子事件，终结数据是显示于屏幕上的图书参数库记录。
·添加图书记录。
本case的功能是：系统管理员登录系统后点击相应菜单，屏幕上便会显示一个表格，系统管理员应将欲添加的“图书代码”及“库存数量”等参数填入。录入结束后，系统便会在图书参数库中添加新书的记录。显然，本case是原子事件，终结数据是添加了记录的图书参数库。
·修改图书记录。
本case的功能是：系统管理员登录系统后点击相应菜单，系统将要求输入欲修改的“图书代码”，屏幕显示相应图书的参数库记录供修改。确认修改后，系统将该记录覆盖写入参数库。本case是原子事件，修改记录后的图书参数库即为终结数据。
·删除图书记录。
本case的功能是：系统管理员登录系统后点击相应菜单，系统将要求输入欲删去的“图书代码”，屏幕显示相应图书的参数库记录。确认删除后，系统将从参数库中删除该记录。本case是原子事件，删除记录后的图书参数库即为终结数据。
13.3.5 终结数据建模
确立原子事件后，就可以为其终结数据建模。如前所述，终结数据的类型比较多，并非只有数据库一类。所以，这里的“建模”是广义的，既可以为数据库建模，也可以描述输出类终结数据的格式与外观。一般来讲，大概有如下几类终结数据：
1) 数据库
2) 文本
3) 表格
4) 画面
5) 语音
后面4类可以存储，也可以是输出形式的终结数据。在这里，我们只为数据库类终结数据建模。根据上一节的叙述，图书管理系统项目的各系统分别有如下数据库：
(1) 借阅者自助系统中的数据库
·预订图书库
(2) 借书业务系统中的数据库
·借书登记库
·借阅者参数库
(3) 管理维护系统中的数据库
·图书管理员参数库
·图书参数库
为了简单，我们只为“借书登记库”建模。图13.2是“借书登记库”的模型表，这是一个共性库，由主体和对象共同决定结果。顺便指出一个事实：在有的项目中，罗列底层case时不一定能包括全部可能的原子事件，被遗漏的原子事件一般都是共性库关键字中约束事物的参数事件。譬如这里的“借书登记库”，它的关键字中只有主体“借阅者”和对象“图书”两个约束事物。由于它们的参数要被查询和维护，所以列出了生成这两类约束事物参数库的case，没有被遗漏。但在有的共性库中，“时间”、“地点”甚至“方法”都可能会是虚事物，即需要为其设置参数库。当这三类约束事物是虚事物时，是最容易遗漏相应参数构件的，补上参数库时不要忘了补上对其维护的3个原子事件(添加、修改、删除)。
| 数据库名 | 借书登记库《loandb》 | |||
| 序号 | 事物简称 | 标识符 | 数据类型 | 备注 |
| 1 | 借阅者代号 | brwid | string | 主体 |
| 2 | 图书编号 | bookid | string | 对象 |
| 3 | 借书日期 | loandate | date | 结果 |
| 4 | 还书日期 | retdate | date | 结果 |
图13.2 借书登记库模型表
13.4 系统设计
通过对用户需求的分析，我们确立了原子事件及其终结数据，可以用高级事件来组装原子事件及下级事件，构造出事件树；之后就是将原子事件分划成任务，构造出任务树；最后当然是设计出任务的作业树。
13.4.1 以原子事件为基石，构造事件树
事件树的构造就是以原子事件为叶节点，依据需求自底向上安排高级事件，直至事件树的根节点。构造事件树的理念当然是等效处理法。
按事件的业务功能分类，逐级组成与高级事件等效的事件集，自底向上地搭建事件树。
所谓“按事件的业务功能分类”，实际是由用户需求提供的，需求说明书中必定会体现了这一点。这种分类并非一定是严格原则性的，在关注工序关系的前提下，总可以用一个高级事件与分类组成的事件集等效。
图书管理系统项目有3个系统，需要构造出3棵事件树。
(1) 借阅者自助系统的事件树
图13.3 借阅者自助系统的事件树
属于借阅者自助系统的原子事件有：登录系统，查找图书，查询自身信息，预约借书。显然，借阅者只有在登录系统后，才可以查找图书、查询借阅者信息、预约借书。据此就有如图13.3所示的事件树。高级事件“自助操作”下辖3个原子事件，以便添加工序关系实现先登录后查询的需求。高级事件“借阅者自助”是系统根事件，调度管理下属两个儿子：“登录系统”和“自助操作”。
(2) 借书业务系统的事件树
图13.4 借书业务系统的事件树
属于借书业务系统的原子事件有：登录系统，借书处理，还书处理，查询图书信息，添加图书记录，修改图书记录，删除图书记录。自底向上地安排高级事件，就构造出了该系统的事件树，如图13.4所示。高级事件“借书与维护”的增设，是为了保证先登录后操作的工序关系。这里，还可以将事件树增加一级，以高级事件“借书与还书”统管“借书处理”与“还书处理”；另以高级事件“图书维护”统管有关图书的四个原子事件。
(3) 管理维护系统的事件树
属于管理维护系统的原子事件有：登录系统，查询图书管理员信息，添加图书管理员记录，删除图书管理员记录，修改图书管理员记录，查询借阅者信息，添加借阅者记录，删除借阅者记录，修改借阅者记录。该系统的事件树如图13.5所示，高级事件的功能类似于前述系统。
图13.5 管理维护系统的事件树
13.4.2 以事件树为原型，标志菜单事件
在事件树的基础上通过标志菜单事件很简单。在每个事件的参数库结构中都设置数据项“menu(是否选为菜单)”，menu=“y”表示相应事件被选为菜单，否则表示未被选为菜单。选取的原则和方法在博文《菜单树》中都有详述，这里就不打算举例了。
13.4.3 分划独立出任务，组建任务树
这里所指任务树，主要是原子事件的任务树。高级事件一般都是单任务的，极其特殊的才会是多任务。在确立了原子事件并构造出事件树后，就可以着手为原子事件逐个组建任务树。严谨的做法是在“需求说明书”的基础上写出“系统设计报告”，该报告应该明确地给出求解终结数据的算法。依据系统设计报告划分任务时，当然要遵循任务划分的基本原理，即按“独立概念”来划分任务。这样做不一定能完全满足任务独立规则，这没有关系，之后可以由人工或辅助设计系统检测并修改之。
这里讲“组建”任务树，是因为任务树极其简单。它只有两层，主任务是根节点，其它协作任务都是主任务的儿子。如早前所述，组建任务树的重点不在树而在节点，将事件分划独立出任务才是关键。由于原子事件的功能是求解终结数据，则任务的分工与协作也是为了求解终结数据。有关任务划分与独立规则，在博文《任务独立规则》中有过详尽的论述。
图书管理系统项目有许多原子事件，必须逐个为之组建任务树。碰巧的是该项目的事件多数都是单任务的，所以几手就没有组建任务树的要求。我们还是以“借书处理”事件为例，并假定对借阅者是否违规的检查有一套规定，故将此检查独立为任务。于是，“借书处理”就由如下三个任务组成：
图13.6 原子事件“借书处理”的任务树
1) 主任务t0“登记借阅图书”，记减图书参数库的“库存数”和添加借书登记库的记录。
2) 协作任务t1“接收代码”，接收借阅者代码和图书编码，并检查输入数据的合法性。
3) 协作任务t2“借书违规检查”，违规则退出该事件。
如图13.6所示。这里，t0首先调用t1接收借阅者代码和图书代码，并检查录入数据的合法性。然后调用t2，检查是否超出借阅规定：违规则借书不成功而退出该事件；不违规则继续下一步。读入图书参数库记录，检查图书库存数是否为0：为0则借书不成功而退出该事件。有库存图书则记减库存数后写图书参数库记录，同时将借书信息添加进借书登记库，图书成功借出退出该事件。
13.4.4 按任务的算法逻辑，设计作业树
将事件分割成任务后，接下来的工作自然是设计作业树。我们知道，作业树是任务的结构树，作业树的设计也属于系统结构设计的一个层次。从另一个角度来讲，作业树的设计己经涉及到程序的控制逻辑，即涉及到程序设计，故又可以说作业树的设计也属于程序设计的一个层次。
任务树的设计依据是事件终结数据的求解算法，作业树的设计依据则是任务目标数据的求解算法，所以算法是这两类树的设计依据。算法设计是人们创造性的思维活动，没有什么捷径可走。对于求解算法相对复杂的任务，应该先用自然语言写出算法的逻辑步骤，以方便作业树的设计。
我们还是来看图书管理系统项目中的一个实例。前面构造了原子事件“借书处理”的任务树，现在来设计该事件主任务t0“登记借阅图书”的作业树，如图13.7所示。为了简单直观，该作业树中的操作都以自然语言表述。此外，图中也没有给出控制逻辑表达式，这可以借助于相应节点的注释来理解。其中，“未超出借阅规定”处调用了任务t2，并设定函数t2()=0表示未超出借阅规定；t2()=1表示已超出了借阅规定。
图13.7 任务“借书处理”的作业树
13.5 编码调试
至此，我们已经完成了树型软件的结构设计，接下来的工作就是编码、调试、测试、上线。这些工作都是规程性的，但还是需要十分细心、特别认真。这些工作都已经很具体了，所以下面的叙述既简单也不便举例。
13.5.1 遍历编程
图13.8 辅助设计系统MTC2008的一幅画面
实际上，在辅助设计系统的帮助下，每设计完成一棵结构树，辅助系统就会自动地将其遍历编码于显示屏的“编码窗口”，如图13.8所示。当各级结构树都设计完成后，编码窗口就会显示出具有控制语句的程序框架。这时，我们可以对照“设计窗口”的作业树，在“编码窗口”编写作业中的顺序语句代码。编译运行后，会在“信息窗口”显示出错信息。
13.5.2 程序调试
树型软件的程序调试和传统软件的调试方法一样，传统的调试方法与工具都适用于树型软件。只不过可以借助于结构树的特点，按操作、作业、任务、事件、系统逐级进行调试。当然，也可以更为详细地叙述树型软件的调试方法，这还是等到人们都愿意用树软法开发软件时再谈。
13.5.3 整体测试
整体测试更是老生常谈，就是对项目软件整体的功能测试、性能测试、压力测试等等。
13.5.4 上线交付
上线交付除软件正式服役外，还应包括交付文档给用户，为用户培训操作运行人员、系统管理人员等等工作。
13.6 树软法与UML
在当今软件工程界，UML是颇为流行的一种系统分析方法。树型软件工程方法(简称树软法)与UML之间有什么关系呢？树软法是具有分析、设计、编码、调试一整套的软件工程方法，UML只是系统分析工具，所以两者之间没有可比性，也谈不上有什么关系。但是，树软法的系统分析与UML是可以类比的，这两种分析方法有许多相同之处。
1) 树软法的“主体事物”与UML的“参与者”类同。
2) 主体事物产生的case与参与者的用例类同。
3) 树软法的数据库类终结数据建模与UML对类的静态和动态建模类同。
所以，在上述三点的基础上，采用UML的分析结果来确立原子事件也是可以的。只不过要注意不要遗漏为作开事物等约束虚事物的参数库建模，UML在这方面的概念不甚明确。
UML有许多图，从用例图至构件图、部署图，有十来种。这些图可以说是对用户需求的整理与分析，无疑对系统设计乃至调试都会有帮助。但是，这些图并没有构造出系统结构，也没有划分出各级模块及相应的程序结构。工程进入系统设计阶段时，树软法以事件树、任务树和作业树为通用的数学模型，显然比UML更具可操作性，其直接就是软件设计的具体步骤。
笔者认为，UML与树软法并不冲突。直接按本文所述的步骤开发树型软件显然是科学合理的，在UML分析结果的基础上再实施树软法也是可行的。
13.7 结束语
本文实际是对此前所有树软法博文内容的条理性的简述，综合全面地给出了树型软件的开发方法。然而，在此仍要强调：
在实施树软法的所有步骤中，构造事件树是关键，确立原子事件则是关键中的关键。
软件开发的难点就在如何从用户需求过渡到软件系统结构，采用任何软件工程方法都必须经历这一难关。以事件树表示系统结构，正是树软法的突出优点。
我看到oschina的许多网友都是从事手机软件开发工作的，我不懂手机软件，但我想从我所使用的手机(Changhong-2007款)菜单界面上，试着构造出手机管理系统的事件树，作为与网友们交流树软法的一个话题。
图13.9 手机管理系统的项目系统树
3.9是手机管理系统的项目系统树。如前所述，“系统树”只是为了方便叙述而取用的名称，其本质上还是事件树。我们看到，这棵系统树中除系统节点s1、s2和s3外，还有a1，a2，…，a6六个原子事件。高级事件h0是项目事件树的根节点，我猜想它的功能应该类似于Windows程序的“消息循环”。高级事件h1的主要功能是管理三个子系统：以s1代表的“快捷”系统，以s2代表的“功能表”系统，和以s3代表的“电话本”系统。将这相应子系统事件树的根节点替代这三个节点，即可形完整的项目事件树。
图13.10 不完整的“快捷”系统事件树
3.10 表示的是不完整的“快捷”系统事件树。并入图13.9时，应该以h10取代s1。这里只画出了h13和h18的下级节点，而且全部都是高级事件。要将该事件树构造完备至全部原子事件，我没有这个能力，不懂手机业务。好在这只是作为讨论话题的示意图，想必网友们是不会笑话的。如果从事手机软件设计的众网友都来参与设计构造手机管理系统的事件树，必定会得出一棵科学合理的事件树。
6324
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
