The Tabular Method for Relational Documentation

Electronic Notes in Theoretical Computer Science 44 No. 3 (2003) URL: http://www.elsevier.nl/locate/entcs/volume44.html 26 pages

The Tabular Method for Relational Documentation David L. Parnas 1 Department of Computing and Software, McMaster University, Hamilton, Ontario, Canada

Abstract The basic mathematical laws of relations can be presented and verified using compact abstract notation. However, descriptions of specific relations, such as those that arise in describing software, must be done in terms of a a state representation. When conventional notation is used, the expressions can be complex and hard to use. This tutorial presented and explained tabular notation that has been found useful in practical software development. It also described a set of prototype tools that make it easier to apply relational methods in software development.

(For giving readers some idea of what was presented in this tutorial, the following pages reproduce the tutorial slides.)

1 Current affiliation: SQRL Limerick, Department of Computer Science and Information Systems, University of Limerick, Ireland. E-mail: [email protected]

c 2003 Published by Elsevier Science B. V.


1

Parnas

A Rational Design Process 1. A. Establish and document system requirements (black-box view) 2. Select Hardware Components and Document the System Design 3. Document the Desired Software Behaviour 4. Design and document the module structure 5. Design and document the module interfaces 6. Design and document the uses hierarchy 7. Establish process structure guidelines 8. For each module that is too big to throw away, repeat 4...8, then • Document the module’s internal design • Code to the internal design

Documentation is the key to a better process.

So why don’t developers do it? The simple answer, “They do not know how”. Imagine trying to develop an automobile if you do not know how to specify the thread on nuts and bolts. Imagine trying to develop electronic devices and systems if we do not know how to specify impedance, voltage, current, inductance, frequency response. Imagine trying to produce for the petroleum industry if you do not know how to specify viscosity, octane level, etc. You do not have to imagine trying to produce software systems without knowing how to specify component properties. We do it every day.

2

Parnas

Never Build on Sand Software is among the most complex of products. We cannot hope to keep such products under intellectual control, unless we build on a solid, sound, well understood foundation. If •we don’t know the meaning of our notation, or •we don’t know the associated rules of inference, or if •those rules are complex and conditional,

using that notation will not help us to understand what we are doing. To build complex products our design notations must have a sound and simple mathematical basis. Today, many people promote Undefined Modelling Languages (UMLs) as a solution. Without a precise definition of the notation, UMLs become part of the problem, not the solution.

Using Mathematics to Document and Analyse Software. Those who talk about “Software Engineering” should take a better look at traditional Engineering. Engineers do use mathematics in designing and documenting their work. Engineers do not think anthropomorphically about their products. Engineering mathematics • serves as documentation, • provides precise, accurate summaries of product characteristics, • allows us to abstract from construction details, • provides us with methods of analysis. In contrast, software developers use anthropomorphic descriptions of execution details, pictures whose meaning is unclear, and documentation or descriptions that are at least as bulky and complex as the product.

3

Parnas

What do we want to do with mathematical descriptions of software? 1. Describing software products that we already have - so that people can use them without reading the code. 2. Writing specifications for software products we do not yet have - so that the programmers and clients can agree on the requirements. 3. Be able to verify that a product meets its requirements (testing or proving).

What are the Criteria? 1. Descriptions must be easier to read than the code. 2. We must state the requirements in a way that does not restrict the solutions unnecessarily. 3. Testing and proof can eventually be automated. 4. Use closed form mathematics where possible. Methods such as Z fail all four tests. The meaning of Z has not been precisely defined and it is used to give models, not specifications.Specifications are axiomatic in style, not closed form expressions.

Are Programs Different From Other Engineering Products? Before we had computers, engineers used classical mathematics to describe and analyse their products. In Computer Science, most researchers have turned to newly invented “languages”. We are using software to replace conventional products. Why can’t we simply go on using the mathematics we used to use? Wrong Answer: “Conventional products are inanimate objects.” - So is software! Wrong Answer: “We need to describe the procedure followed by the program.” In most cases the reader will not care what procedure is followed. The will want to know the function the software performs. Right Answer: “The functions have many more points of discontinuity”. We will return to this point later.

4

Parnas

Describing Engineering Products Engineers use mathematics, not just words, to describe their products. • They use a variety of descriptions rather than attempt one “complete” description. • There is never a single complete description of a product. • Each product description is intended for a different purpose and each is an accurate description of some aspect of the product. • Even taken together, these descriptions never constitute a complete description. There are always some facts that are not stated in the descriptions.

Even for simple physical objects, Engineers produce several drawings (“views”) and require additional numerical specification sheets Current specification “languages” make no provision for this. They use the same approach for all “views”!

Engineer’s Mathematics Engineers use mathematics but •they prefer closed form expressions to equations •they prefer equations to generalised predicates •they prefer predicates to axioms,

In addition, they expect the mathematic descriptions to summarise properties precisely, not describe the construction of the mechanisms in detail. “Formal Methods” are based on the axiomatic view of mathematics used by logicians, not the mathematics developed by applied mathematicians and used by Engineers.

5

Parnas

Describing Different Types of Products 1. Systems interacting with the real-world, 2. Conventional terminating programs, 3. Programs that shouldn’t terminate, 4. Modules (hiding data structures, etc.) 5. Objects (created by modules)

Each requires a different approach. 1. For systems, can we follow control theory and deal with relations between observable time functions. 2. For terminating programs, we can describe the program’s effect on the exposed data structure. 3. For modules, we must not mention the data structure. Consequently, we must describe classes of traces (sequences of visible events). 4. For objects, we extend the module method to allow multi-object operations. Sometimes we must describe inter-object constraints (resource based). 5. For non-terminating programs, we can replace time-functions, with event sequences.

Descriptions vs. Specifications Engineers distinguish specifications from other descriptions. Definition: An actual description is a statement of some actual attributes of a product, or set of products.

Definition: A specification is a statement of all properties required of a product, or a set of products.

In the sequel, “description”, without modifier, means “actual description”. • A description may include attributes that are not required. • A specification may include attributes that a (faulty) product does not possess. • The statement that a product satisfies a given specification constitutes a description. Specifications are indistinguishable from descriptions.

The third fact results in much confusion. A useful distinction has been lost.

6

Parnas

Descriptions vs. Specifications Any list of attributes may be interpreted as either a description or a specification. Example (a box): “A volume of more than 1 cubic meter” This could be either an observation about a specific box or, a requirement for a box that is about to be purchased. A specification may offer a choice of attributes; a description describes the actual attributes, but need not describe them completely. Sometimes one may use one’s knowledge of the world to guess whether a statement is a description or a specification. Example: “Milk, badly spoiled” Guessing is not reliable. We need to label specifications and descriptions to distinguish them.

What Mathematics Do We Need Simple Answer: •The concept of “function” and “relation”. •The well-known algebra of functions and relations. •The ability to describe sets (functions and relations) using characteristic predicates.

These are the primary concepts used in all branches of Engineering. We describe the behaviour of physical objects by describing mathematical functions and describing the meaning of the range and domain elements. We use relations when there is uncertainty or choice.

7

Parnas

How to document system requirements The first step is to: • Identify monitored variables (m1, m2, •••, mn). • Identify controlled variables (c1, c2, •••, cp).

The primary monitored variables are things outside the system whose values should influence the output of the system. Examples: • customer meter reading • steam temperature • time of day

The primary controlled variables are things outside the system whose values should be determined or influenced by the system. Examples: • what the operator sees • what appears on a bill • control positions

This is only the beginning, but for many projects you cannot even find a complete list of these variables and there is no agreement on what they are.

How to document system requirements Monitored and controlled variables will be added during the design process. It is inevitable that the need for additional variables will be discovered as we get into detailed work. Further, new monitored and control variables are created during the design process. •

The primary monitored and controlled variables are outside the system.

•

Sometimes we want to monitor the system itself, i.e. measure things that did not exist before the system was built.

•

Sometimes we may even want to control (adjust) parts of the system.

•

As the design is developed, we may add these monitored and controlled variables to the requirements document.

It is essential that the document be updated. Otherwise reviewers and maintainers are misled.

8

Parnas

Bringing Time into the Picture All of these variables can vary with time. For each scalar variable, x, denote the time-function describing its value by “xt”. The value of x at time t is denoted “xt (t)”. The vector of time-functions (vt1, vt2, ..., vtn) will be denoted by “vt”. Contrary to the statements of some computer scientists, there is no problem dealing with “real” time.

The contents of requirements documents The implementors need to know the following relations: Relation NAT: • domain contains values of mt, range contains values of ct, • (mt, ct) is in NAT if and only if nature permits that behaviour.

This tell us what we need to know about the environment. Relation REQ: • domain contains values of mt, range contains values of ct, • (mt, ct) is in REQ if and only if system should permit that behaviour.

This tells us how the new system is intended to further restrict what NAT(ure) allows to happen. If we can describe these relations, we have our system requirements precisely documented. This is the way to understand the SCR/A-7 work.

9

Parnas

Practical Applications of Requirements Model A-7 requirements document and other military Bell Labs systems Nuclear Plant shut down systems. Tools •SCR toolset •Ontario Hydro/AECL tools •Dennis Peter’s Monitor Generator •Various Model Checking approaches to check the tables.

Documenting Objects We want “black box” descriptions of objects, For such descriptions, references to the data structure used in the module are inappropriate. For black box descriptions of finite state machines, the only information that can be mentioned are the externally visible events, i.e. sequences of inputs and outputs. We call such sequences traces. Definition: A trace of an object is a finite sequence of pairs, each containing a member of the input alphabet and a member of the output alphabet. A trace, T, is considered possible for object O, if O could react to the sequence of inputs in T by emitting the sequence of outputs in T.

Descriptions and specifications of objects can both be written as predicates on classes of traces. Programs implementing objects are assumed to terminate.

10

Parnas

Relational Descriptions of Objects Identify a set of canonical traces: • Each canonical trace to represent a set of equivalent traces • No distinct canonical traces are equivalent • Every possible trace equivalent to a canonical trace

Describe an extension relation: • Domain: set of traces extended by a single element • Range: canonical traces • A function • Maps each extended trace to equivalent canonical trace

Describe an output relation: • Domain: set of traces extended by a single element • Range: set of vectors of output values • Maps each extended trace to set of possible outputs.

Key issues: • Readable representations of traces • Readable representations of the relations

We can do it, but people rarely take the time.

Before/After Descriptions of Programs Before/after descriptions are a class of behavioural descriptions that are used when the intermediate states of an execution are not important. For each state, s, they must describe: • (a) whether or not a program is guaranteed too terminate if started in state s, and • (b) the set of possible final states for the executions of program P that start in s.

11

Parnas

LD-Relations Definition: A binary relation R on a given set U is a set of ordered pairs with both elements from U, i.e. R ⊆ U × U. The set U is called the Universe of R. The set of pairs R can be described by its characteristic predicate, R(p,q), i.e. R = {(p,q): U × U | R(p,q) = true}. The domain of R is denoted Dom(R) and is {p | ∃q [R(p,q)]}. The range of R is denoted Range(R) and is {q | ∃p [R(p,q)]}. Below, “relation” means “binary relation”.

Definition: A limited-domain relation (LD-relation) on a set, U, is a pair, L = (RL, CL), where: RL, the relational component of L, is a relation on U, i.e. RL ⊆ U × U, and CL, the competence set of L, is a subset of the domain of RL, i.e. CL ⊆ Dom(RL).

Using LD-Relations as Before/After Descriptions (1) Definition: Let P be a program, let S be a set of states, and let LP = (RP, CP) be an LD-relation on S such that (x,y) ∈ RP if and only if is a possible execution of P, and CP is the set of safe states for P. 1 Lp is called the LD-relation of P

By convention, if CP is not given, it is, by default, Dom(RP).

This convention makes LD-relations upward compatible with Mills’ program functions.

1. Please note that CP is not the same as the precondition used in VDM [4]. SP is the safe set of P.

12

Parnas

Using LD-Relations as Before/After Descriptions (2) The following follow from the definitions: • If P starts in x and x ∈ CP, P will always terminate; if (x, y) ∈ RP, P may terminate in y. • If P starts in x, and x ∈ (Dom(RP) − CP), the termination of P is nondeterministic; in this case, if (x, y) ∈ RP, when P is started in x, the execution may terminate in y or may not terminate. • If P is started in x, and x ∉ Dom(RP), then the execution will not terminate. • If P is a deterministic program, the relational component, RP, is Mills’ program function and CP (which will be exactly Dom(RP)) need not be written. Hence, our approach is “upward compatible” with Mills’ approach. By these conventions we are able to provide complete before/after descriptions of any program and still have an efficient representation for those cases that arise most often.

Using LD-Relations as Before/After Descriptions (3) We know that LD-relations are theoretically equivalent to other relational models, but... LD-relations have advantages over other, more popular, before/after descriptions. • They provide complete before/after descriptions of non-deterministic programs. • They can be described by giving the characteristic predicates of the Relation and Competence Set; those predicates can be expressed in terms of values of the actual, program variables. The last property is of great practical value. It allows us to use completely conventional (classical) mathematics yet still provide descriptions in terms of things that programmers know about.

13

Parnas

Specifying Programs Specifications may allow behaviour not actually exhibited by a satisfactory program. We can also use LD-relations as before/after specifications: To do this we must describe how the description of a program should be related to a specification that has been provided. Definition: Let Lp = (RP, CP) be the description of program P. Let S, called a specification, be a set of LD-relations on the same universe and LS = (RS, CS) be an element of S. We say that: (1) P satisfies the LD-relation LS, iff CS ⊆ CP and RP ⊆ RS, and (2) P satisfies the specification S, iff Lp satisfies at least one element of S. Often, S has only one element. If S = {LS} is a specification, then we can also call LS a specification.

There is Nothing New With LD-relations. Any LD-relation can be translated into a relation that has a special symbol representing non-termination. The rules for composition change slightly but we can express the same things. Why introduce LD-relations? • Everything can be expressed in terms of variable values • Upward compatible with function view, competence set can be left out in majority of cases. These are not theoretical advantages; they are practical advantages.

14

Parnas

What New Notation do we Need? Although the mathematics is old, and the abstract notation for defining things is old, the applications are new. We have to describe relations and functions that have non-heterogeneous ranges and domains and can have a discontinuity at arbitrary points. We have found a variety of tabular notations to be useful. Ryszard Janicki, has found new ways to unite these tabular notations. Jeff Zucker, Martin von Mohrenschildt, Ridha Khedri and I and our students are implementing tools for transformations. We are trying to: • Make the documentation easier to produce • Make the documentation more useful

A Simple Conventional Expression (((∃ i, B[i] =x) ∧ (B[j’] = x) ∧ (present’ = true)) ∨ ((∀ i, ((1 ≤ i ≤ N) ⇒ B[i] ≠ x))∧(present’ = false))) ∧ (‘x = x’ ∧ ‘B =B’)

An equivalent tabular expression: Specification for a search program (∃ i, B[i] =x)

(∀ i, ((1 ≤ i ≤ N) ⇒ B[i] ≠ x))

j’ |

B[j’] = x

true

present’=

true

false

The above is one of many kinds of tables! Simple tables like this understate the advantage. These have “practitioner appeal”. • They can be used with any mathematical method. • They can also be used without quantifiers • Tables are useful even without mathematics.

15

∧ NC(x, B)

Parnas

Program Descriptions and Specifications Specification for a search program

j’ | present’=

(∃ i, B[i] =x)

(∀ i, ((1 ≤ i ≤ N) ⇒ B[i] ≠ x))

B[j’] = x

true

true

false

∧ NC(x, B)

Description of a search program

j’ |

present’ =

(∃ i, B[i] =x)

(∀ i, ((1 ≤ i ≤ N) ⇒ B[i] ≠ x))

(B[j’] = x) ∧ (∀ i, ((j’ < i ≤ N) ⇒ B[i] ≠ x)) true

true

∧ NC(x, B)

false

Interface Documentation: 12 Element Queue (1) Syntax ACCESS PROGRAMS

Program Name

Value

Arg#1

ADD



REMOVE FRONT



(2) Canonical representation (rep = < [ a i ] i = 1 >) ∧ ( 0 ≤ n ≤ 12 ) n

(3) Trace Extension Functions1

ADD([rep],a) ≡ conditions

new rep

extension class

n = 12

rep

%full%

n < 12

rep.a

REMOVE([rep]) ≡ conditions

new rep

extension class

rep = _

rep

%empty%

rep ≠ _

< [ ai ]i = 2 >

conditions

new rep

extension class

rep = _

rep

%empty%

rep ≠ _

rep

FRONT([rep]) ≡

n

Value returned a1

1.We use “.” to denote sequence concatenation. [brackets] enclose implicit arguments to functions.

16

Parnas

Queue: Internal Design (part I) (1) DATA STRUCTURE CONSTANTS Constant Name

Definition

QSIZE

12

TYPES Type Name

Definition



array[0..QSIZE-1] of integer

VARIABLES Type Definition/Name

Variables



DATA

Initial Values “Don’t Care”

0..QSIZE-1

F, R

“Don’t Care”



FULL

“Don’t Care”



old

false

Abbreviation: edge df (R = F + 1) ∨ (F = QSIZE-1) ∧ (R = 0) ‘edge df (‘R = ‘F + 1) ∨ (‘F = QSIZE-1) ∧ (‘R = 0) edge’ df (R’ = F’ + 1) ∨ (F’ = QSIZE-1) ∧ (R’ = 0) df qds × 0..QSIZE-1 × 0..QSIZE-1 × boolean (2) ABSTRACTION FUNCTION af: → af(DATA,F,R,FULL,old)

df

(¬ edge ∨ FULL) ∧ (F ≥ R) ∧ old

Q12INIT.ADD(DATA[F]).ADD(DATA[F−1]). … .ADD(DATA[R])

(¬ edge ∨ FULL) ∧ (F < R) ∧ old Q12INIT . ADD(DATA[F]). … .ADD(DATA[0]).ADD(DATA[QSIZE-1]). … .ADD(DATA[R]) edge ∧ ¬ FULL ∧ old

Q12INIT

¬ old

Queue: Internal Design (part II) (3) PROGRAM FUNCTIONS pf_Name

Arg#1

Value

pf_Q12INIT



pf_ADD pf_REMOVE



pf_FRONT



df

F’ =

0

R’ =

1

FULL’ =

false

DATA’ |

true

old =

true

NC(F) ∧ ∀j (j ≠ R’) [NC(DATA[j])] ∧ NC(a) ∧ (‘R = 0) ∧ old ∧ ‘edge ∧ ‘FULL

pf_REMOVE

df

(‘R ≠ 0) ∧ old ∧ ‘edge ∧

¬ ‘edge

¬ ‘FULL

‘FULL

¬ ‘edge

¬ old

‘DATA[‘R]

a

a

‘DATA[‘R]

a

a

R’ =

‘R

QSIZE-1

QSIZE-1

‘R

‘R − 1

‘R − 1

‘R

FULL’ =

‘FULL

false

‘F = QSIZE-2

‘FULL

false

edge’

‘FULL

‘DATA[‘R]

NC(DATA,R) ∧

F’ = FULL’ = df

¬ ‘FULL

DATA’[R’] =

(¬ ‘edge ∨ ‘FULL) ∧ old ∧

pf_FRONT

→ → → → ×

df

pf_Q12INIT

pf_ADD(a)

×



(‘edge ∧ ¬‘FULL) ∨¬ old

(‘F = 0)

(‘F > 0)

QSIZE-1

‘F − 1

‘F

false

false

‘FULL

NC(R,FULL, DATA, F) ∧ (¬‘edge ∨ ‘FULL) ∧ old return value =

(‘edge ∧ ¬‘FULL) ∨ ¬ old

‘DATA[‘F]

We have systematically made many design decisions. Coding can be left to a language technician.

17

Parnas

Tables Don’t Make a Difference: Theoretically We cannot express anything with table that we could not express without it. The proof rules don’t change because the underlying abstraction is the same. Why did we do it? •They are easier to write, people make fewer mistakes •They are easier to read •They can be used as reference documentation •They help in a “divide and conquer” approach to design and inspection.

When we ask students to write descriptions in conventional notation, they get them wrong. With tables they usually get them right. The same thing has been noted in industry. Tables really make a difference.

TOOLS and Use The fact that the meaning of these tables has been precisely defined using classical mathematics means that we can make tools that support their use. The methods are now used in safety-critical situations even though the tools are primitive. With good tools and good education, we could turn software developers into Engineers.

18

Parnas

Tool Work of McMaster’s SERG: A framework to allow components to communicate by means of table objects (syntax only) plus semantic information. The kernel stores tabular expressions in a format independent way allowing the utilities and tools to process them based on their mathematical semantics. Utilities make it easier to build tools. The kernel and utilities allow tools to be composed into more useful tools. The output of one tool is the input to another. Users can “plug and work” e.g “invert” a table and then simplify the results by combining inversion and simplification tools. The kernel is “professional” The tools are for proof of concept and demonstration. They are not production tools.

Input tools Style of input a matter of taste. Some want very conventional input. Some want highly interactive syntax guided input. We have three input tools and are working on a fourth.

Formatting tools (postscript, latex) These tools do not allow a user to change the mathematical structure of an expression. They allow appearance changes, but not content changes. Based on industrial experience.

19

Parnas

Table checking tools • Completeness checking • Checking for ambiguity • Type checking These tools can detect the errors most commonly made in practice. They save time for reviewers and documenters. They do not show that the table is correct. That requires subject matter knowledge.

Expression evaluation (generalised tables) Tables are mathematical expressions. Assign values to the variables and they can be evaluated. This can be useful in simulation, test oracles, and checking specifications. Based on the work of Ryszard Janicki, Ruth Abraham and Dennis Peters, we can handle many types of tables with one tool. Thesis co-supervised by Prof. Ryszard Janicki and myself.

20

Parnas

Table Form Conversion Many forms of tables have been discovered. Each is useful in a different situation. •Normal tables good for gathering information •Inverted tables better for presentation (sometimes) •Ontario Hydro Tables fit their tools •NRL Tables useful for requirements •ORA tables have powerful checkers.

SERG has conversion tools to link with other work and to improve presentation. Co-supervised by Prof. Mark Lawford and myself.

Expression Simplification (first pass) Inversion and conversion tools produce complex tables. Tools like Maple can be used to simplify expressions. SERG tools simplify tabular expressions. Co-supervised by Prof. Martin von Mohrenschildt and myself.

21

Parnas

Use of alias definitions to simplify tables Even tabular expressions get complex when the variable identifiers are long. Variable identifiers are always long when you have complex data structures. Variable identifiers complex when you use pointers. Tables can be made simpler to read if you assign an alias that depends on the values of the variables. This requires double evaluation. SERG has a prototype tool.

Functional Composition Given tabular descriptions of programs A and B, what is the tabular description of A;B. Answer: Functional composition of the two expressions. SERG has a prototype tool to compute this. Potentially of great value for inspections. Can be plugged together with simplifier, converter, etc. Co-supervised by Prof. Martin von Mohrenschildt and myself.

22

Parnas

Equivalence Checking And Refinement. The Program Inspection Problem: •given a table specifying the requirements, and •a table derived from the program itself,

How do you know if the program is acceptable? Answer: The program’s table must describe a function that is a refinement of the specification. Prof. Martin von Mohrenschildt and his student have built a prototype tool that checks this property.

Scenario Checking Scenarios are an excellent way to explore requirements with potential users. You never know when you have enough. Relational Models tell you when scenarios are missing - Profs. Khedri and Desjarnais (Laval). Tables, which have a relational semantics, make the missing cases obvious. (Prof. Khedri)

23

Parnas

Test Oracle Generator Given documentation, how do you know it is accurate? Given a test-result, how do you know if the result is acceptable? Answer: Generate an “oracle” from the documentation. The oracle tells you if the program and the document are consistent on the text. An oracle does not calculate an answer, it checks an answer. This provides a truly independent check. This is the work of Dennis Peters, now teaching at Memorial University.

Real-Time Monitor Generator Why not apply the test oracle idea to real-time systems? Monitor runs along-side the real system and reports errors. May be used for testing or safety. May be generated from the design document. The prototype is the work of Dennis Peters now at Memorial University.

24

Parnas

Reliability Estimation for Modules and Programs Reliability of software is a function of the input data. Input data generated based on a statistical model. Reliability estimated based on binomial or inverse binomial models. Two tools built as prototypes. Tools generate test-data and compute reliability estimates. One tool for “open” programs, one for “closed” modules.

Test Case Generation and Coverage Evaluation How do you know when you have tested enough? How do you know if some cases are undertested? Given a tabular specification, how many tests fall in each cell of the table? Can you display the test coverage? (Wang N.) Can you generate tests for each cell (S. Liu under the supervision of Martin von Mohrenschildt)

25

Parnas

Table driven program family generator Lucent Technology has successfully applied the idea of “program families” to reduce delays and cost in generating families of programs. Book on the FAST Method (Weiss and Lee) available. In FAST the domain engineer designs a special purpose language and the application engineer writes applications in that language. D. Han and I have developed a variant. •domain engineer produces an incomplete table and tool for completing it. •application engineer completes a table and code is generated automatically. •Application engineer does not write programs.

Demonstration program shows several interesting types of families and their tabular representation.

Lots of Work Left All tools are pre-prototype. Simplifiers, inverters, converters, require lots of work. There will always be more to do. Notation is better but could be still better. Kernel could be done better with XML. More table forms deserve exploration. Inspection tools are needed. Mathematics is the key Mathematics makes the documentation unambiguous. Mathematics makes it possible to build simple but powerful tools The mathematics is Engineer’s mathematics. It is primarily expressions that you evaluate. It is not a set of axioms. It can be checked for many properties.

26