PETRI NETS

The purpose of this chapter is to give an overview of some currently active topics in automata and language theory. The overview is by no means intended to be exhaustive: Some topics have been entirely omitted, and the material within the topics presented has been chosen to give only a general idea of most representative notions and results. As the title of this chapter indicates, the attention is restricted to topics in automata and language theory.

The style of presentation in this chapter is somewhat different from that used in the previous chapters. Most of the proofs are either omitted or only outlined. Sometimes notions are introduced in a not entirely rigorous manner, and results are presented in a descriptive way rather than in the form of precise mathematical statements. We begin with a discussion of Petri nets.

In a customary model for computing, the notion of a state is quite essential. This is certainly true of most of the models discussed earlier. The notion of a state introduces, at least implicitly, a specific discrete linear time scale for all considerations involved: Time instants can be identified with the current states. Such a linear time scale is not desirable in all considerations. For instance, we might want to model systems where many processors operate independently and in parallel and where some partial computations depend (perhaps in a complicated way) on the outcome of some other computations.

The basic question in the theory of computing can be formulated in any of the following ways: What is computable? For which problems can we construct effective mechanical procedures that solve every instance of the problem? Which problems possess algorithms for their solutions?

Fundamental developments in mathematical logic during the 1930s showed the existence of unsolvable problems: No algorithm can possibly exist for the solution of the problem. Thus, the existence of such an algorithm is a logical impossibility—its nonexistence has nothing to do with our ignorance. This state of affairs led to the present formulation of the basic question in the theory of computing. Previously, people always tried to construct an algorithm for every precisely formulated problem until (if ever) the correct algorithm was found. The basic question is of definite practical significance: One should not try to construct algorithms for an unsolvable problem. (There are some notorious examples of such attempts in the past.)

A model of computation is necessary for establishing unsolvability. If one wants to show that no algorithm for a specific problem exists, one must have a precise definition of an algorithm. The situation is different in establishing solvability: It suffices to exhibit some particular procedure that is effective in the intuitive sense. (We use the terms algorithm and effective procedure synonymously.

The last twenty years have witnessed most vigorous growth in areas of mathematical study connected with computers and computer science. The enormous development of computers and the resulting profound changes in scientific methodology have opened new horizons for the science of mathematics at a speed without parallel during the long history of mathematics.

The following two observations should be kept in mind when reading the present monograph. First, various developments in mathematics have directly initiated the “beginning” of computers and computer science. Second, advances in computer science have induced very vigorous developments in certain branches of mathematics. More specifically, the second of these observations refers to the growing importance of discrete mathematics—and we are now witnessing only the very beginning of the influence of discrete mathematics.

Because of reasons outlined above, mathematics plays a central role in the foundations of computer science. A number of significant research areas can be listed in this connection. It is interesting to notice that these areas also reflect the historical development of computer science.

1. The classical computability theory initiated by the work of Gödel, Tarski, Church, Post, Turing, and Kleene occupies a central role. This area is rooted in mathematical logic.

2. In the classical formal language and automata theory the central notions are those of an automaton, a grammar, and a language.

BASIC IDEAS AND AXIOMATIC THEORY

The classification of mathematical problems into decidable and undecidable ones has been discussed quite extensively in previous chapters. Indeed, from the mathematical point of view, this classification is the most fundamental one. It is also of definite practical significance in discouraging attempts to design too-general systems, such as systems for deciding the equivalence of programs or the halting of a program. There are, in fact, instances of such attempts in the past!

However, this classification is too coarse in many respects. In Chapter 4 we considered a finer classification of undecidable problems in terms of reducibilities and degrees. We shall now discuss a finer classification of decidable problems in terms of their complexity. Two problems might both be decidable and yet one might be enormously more difficult to compute, which in practice might make this problem resemble an undecidable one. For example, if instances of reasonable size of one problem take only a few seconds to compute, whereas instances of comparable size of the other problem take millions of years (even if best computers are available), it is clear that the latter problem should be considered intractable compared with the former one. Hence, having established the decidability of a particular problem, we should definitely study its complexity—that is, how difficult it is to settle specific instances of the problem.

Introduction

Having established the framework for the phased development of a system we now go on to look at the techniques that are available to you during those phases.

The purpose of this chapter is not to present all known techniques in an encyclopaedic way. Rather, it is to present sufficient information on a representative selection to allow you to make a first selection of a subset for your own project. As you read each précis, you can decide which of the techniques presented are not of interest and those that might be.

In the subsequent phase-orientated chapters each technique is presented with further detail in the context of the phase or phases where it is of use. Thus techniques applicable to, say, the System Definition Phase can be read and compared. Should you still feel that a particular technique is or may be of use, you can refer for complete information to the source material listed in the bibliography.

Similarly, all of the descriptions of the techniques in later chapters are necessarily simplifications. Remember that they are given not so that you can learn how to use the technique – for that you must turn to the authoritative references and suppliers. The purpose is solely to give you sufficient flavour of each technique for you to judge whether further evaluation could be worthwhile.

For each candidate technique you should aim to adopt, adapt or reject it.

The aims of System Acceptance

The system resulting from the Production Phase must now be tested against the Functional Specification to your client's satisfaction. There are two principal reasons for giving the System Acceptance process a phase of its own:

• firstly, to emphasise the importance of careful preparation for it and proper orientation of the preceding phases towards it;

• secondly, because possibly for the first time since System Definition and the production of the Functional Specification, your client will once more play a major role.

Formal acceptance of the system by your client – in other words, a signature – is as important as his formal acceptance of the Functional Specification. It records his agreement that you have carried out your commitment to build his system.

It is likely that, if you have a commercial contract with your client, payment of some portion of the contract price will be dependent on the system's successfully passing an agreed Acceptance Test.

Throughout the preceding phases we have emphasised the need to prepare for Acceptance well ahead of the date of handover. The earlier the Acceptance Test is defined, for instance, the earlier the system can be checked out against it by its implementers. Above all, however, acceptance will not always be simply a matter of running some tests on the system and walking away. You may well be involved in a major handover operation requiring the conversion of the user's organisation and operational procedures, cutover from an existing system, conversion of existing databases to new formats, periods of parallel running, training of staff and so on.

The cost of software development is now the dominating cost in computer systems. As hardware costs decline, improved efficiency of software production becomes the key target if further reductions in computing costs are to be achieved. Accordingly the Alvey Committee identified software engineering as one of the four underlying technologies for the UK national programme of cooperative research in information technology.

Coming as it does at the start of the Alvey programme, I welcome this book by Martyn Ould and Nick Birrell, for it presents a picture of software engineering techniques that are already in existence and can therefore be exploited now. If the techniques set out in the book are widely applied we can look forward to a very significant improvement in the efficiency of software production.

The purpose of the Inception Phase

The Inception Phase is that part of the development lifecycle in which you will decide to embark on the development project. This is the time in which you will make a large number of crucial decisions regarding the need for and nature of the proposed system. The questions that must be asked in this phase will depend on particular circumstances, but may include the following:

• Why is the system needed?

• Are there better alternatives?

• Will the system be acceptable to its users?

• At what price will the system be marketed?

• Is there a market for the system?

• What are the legal implications of the system?

• What are the Trade Union implications of the system?

• What is the intended lifetime of the system?

• How reliable should the system be?

• Can management approval be obtained for system development?

• Will sufficient resources be available for system development?

• Will sufficient resources be available to run the system?

• Will the system be developed ‘in-house’ or will its development be put out to tender?

• How will tenderers' responses be assessed?

Although this phase is not directly involved with software development, it is vitally important that you ask the correct questions and obtain the correct answers to lead to a firm system requirement. These answers will affect all subsequent phases and ultimately the usefulness of the entire project.

The purpose of Project Debriefing

Now that the development project is over and your system is installed it is time to make sure that future projects will benefit from what you have achieved and learnt. This is the purpose of Project Debriefing; to record your experiences in carrying out the project in a way that will be of benefit to other projects and which will add to your organisation's collective database of project statistics.

The way in which the results of Project Debriefing can most help your organisation is in planning future projects. Such planning may be at the start of a new project or as part of a tendering activity. In either case the collected experiences of previous projects are of inestimable value in producing accurate project plans. For this reason, Project Debriefing should be strongly related to the topics of estimation and indicators discussed in chapter 2.

If you have been recording indicators throughout the project it will require little effort to organise, summarise and record these indicators as part of Project Debriefing. Of special importance will be indicators related to attributes used in arriving at the project plan (those of type (ii) on page 19). These indicator values can be used in updating the calibration of your cost estimation model or in pin-pointing weaknesses in the model. Weaknesses in the model or its use may show up in the form of input parameters to the model whose estimated values consistently bear no resemblance to their final values.

The aims of the System Definition Phase

Once the decision has been made to proceed, this is the most important phase of development. Decisions made here influence the rest of the project. Time spent here is rarely less than well-spent, if properly directed. On the other side of the coin, this is one of the most difficult stages as regards knowing where you start, knowing when you have finished and knowing how to go about it.

The purpose is clear however, namely to decide the following:

• What is to be produced,

• When it is to be produced by,

• What resources will be required to produce it.

These latter two may already have been determined for you. If so, you must regard them as constraints that limit what can be produced. In other words you will need to decide additionally that the system can actually be produced in the time with the resources.

Every project manager at this stage of his project needs to be reminded that there is a strong empirical correlation between failure to define a system adequately and failure to produce it. The temptation to short-circuit the Definition Phase is all the easier to succumb to, given the momentary feeling of an increased rate of progress.

The starting point of System Definition

It is most likely that you will start with some form of Requirement Specification.

The purpose of the System Design Phase

Introduction

Although your main concern in the System Definition Phase will have been to decide what functions the system is to perform, you will also have given some thought as to how it is to perform them. During the System Design Phase you continue this process by deciding upon and documenting the overall strategy by which the system will perform the required functions. This involves mapping the system functions onto elements of software (and hardware) which can in the next phase be designed in detail and implemented.

The means by which this mapping is carried out can vary enormously, as can the designs resulting from different design approaches. The principal aim of the System Design Phase should, however, be the same no matter what design method is used; namely, to produce a system design which

• is easily implemented,

and which, when implemented,

• will provide all required functions,

• will operate within any required constraints,

• will be easily maintained.

Let us consider the implications of each of these goals for any potential system design methodology.

Ease of implementation

The process by which the system design will be implemented involves the following basic ingredients:

• the system design (in the form of design documents),

• the implementers (i.e. programmers etc.),

• the virtual machine (i.e. the hardware and supporting systems software).

With the accelerating pace of work being done in the field of software engineering, it is becoming increasingly difficult to see the range of available techniques against a common background. Individual techniques are accessible throughout the literature but generally each is described in isolation. Comparison is difficult unless one has a strong idea of what one is looking for.

Our purpose in writing this book has therefore been to bring together, within a single framework, a variety of methods from all stages of software development and, in this way, to assist software engineers in particular in finding and evaluating the techniques appropriate to their own working environments. This should be regarded principally therefore as a book of signposts, leading the reader out into the field with a map, a compass and some reference points. By combining pointers to a selection of modern development practices with practical hints and checklists, all within one framework, we hope to fill the need for a vade-mecum to the software developer.

Managers with responsibility for software production will also, we hope, find much to stimulate their ideas about what modern practices have to offer and how their departments' efficiency and effectiveness could benefit. Students of computing science will be able to complement their more theoretical work by seeing the software development process as a day-to-day activity, a process that has managerial and sociological as much as purely technical aspects.