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

树型软件开发步骤

 

 

 

 

 

TREESOFT

                            目  录

13 树型软件开发步骤. 1

13.1 分析与设计步骤…. 1

13.2 编写《需求说明书》…. 2

13.3 系统分析…. 3

13.3.1 按业务划分系统，构造系统树…. 3

13.3.2 理出作用事物…. 4

13.3.3 列出主体事物产生的case. 4

13.3.4 确认原子事件…. 5

13.3.5 终结数据建模…. 8

13.4 系统设计…. 9

13.4.1 以原子事件为基石，构造事件树…. 9

13.4.2 以事件树为原型，标志菜单事件…. 10

13.4.3 分划独立出任务，组建任务树…. 10

13.4.4 按任务的算法逻辑，设计作业树…. 11

13.5 编码调试…. 12

13.5.1 遍历编程…. 12

13.5.2 程序调试…. 13

13.5.3 整体测试…. 13

13.5.4 上线交付…. 13

13.6 树软法与UML. 13

13.7 结束语…. 13

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

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) 按业务大类划分“章”。

        1 文件

        3 视图

        4 插入

        5 格式

        6 工具

        (3) 按业务分类划分：节、条、款。

            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所示。

    顺便指出，一个项目可能只有一个系统(甚至只有一个事件/一个任务/一个作业/一项操作)，则构造系统树的工作就是象征性的。

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是原子事件，它有两个终结数据：修改了记录的《图书参数库》的“库存数”和添加了《借书登记库》的记录，后者为其目标终结数据。

    ·处理归还。