INTRODUCTION

In this chapter, we shall give a further illustration of the theoretical usefulness of our framework by applying it in the identification of unstructuredness. Since DeMarco data flow diagrams are mainly used as communication tools with users during the analysis stage of systems development, they are problem-oriented and probably unstructured. Some mechanism must be available enabling us to detect the unstructured elements so that we can construct structured tasks and define refinement morphisms accordingly. We shall extend our concepts in tasks and show that only one single criterion is necessary and sufficient for identifying unstructuredness. Looking at it in another way, a single criterion is necessary and sufficient for proving a task to be structured.

Quite a number of papers have already addressed a similar problem of detecting unstructuredness in program schemes and transforming the schemes into structured equivalents. These papers can roughly be classified as follows:

1. (a) Many of the papers are based on heuristic arguments (Colter 1985, McCabe 1976, Mills 1972, Oulsman 1982, Williams 1977, Williams and Ossher 1978, Williams and Chen 1985). Each paper gives a new proposal supposedly better than earlier ones (Prather and Giulieri 1981). According to the arguments in McCabe (1976), Oulsman (1982), Williams (1977) and Williams and Ossher (1978), unstructuredness may be due to any of four elements — branching out of a loop, branching into a loop, branching out of a selection and branching into a selection. The identification of these elements, however, has remained a difficult task. Since unstructured elements cannot exist in isolation, the authors recommend that we should identify unstructured compounds, or combinations of unstructured elements. Unfortunately, the number of combinations is endless, so that we can never exhaust all the possible cases (Williams 1983).

2. […]

Structured analysis and design methodologies have been recognized as a popular and powerful tool in information systems development. A complex system can be specified in a top-down and graphical fashion, enabling practitioners to visualize the target systems and communicate with users much more easily than by means of conventional methods. As a matter of fact, the structured methodologies have been designed by quite a number of distinct authors, each employing a number of models which vary in their graphical outlook. Different models are found to be suitable for different stages of a typical systems life cycle. A specification must be converted from one form to another during the development process. Unfortunately, however, the models are only derived from the experience of the authors. Little attempt has been made in proposing a formal framework behind them or establishing a theoretical link between one model and another.

A unifying framework is proposed in this book. We define an initial algebra of structured systems, which can be mapped by unique homomorphisms to a DeMarco algebra of data flow diagrams, a Yourdon algebra of structure charts and a Jackson algebra of structure texts. We also find that the proposed initial algebra as well as the structured models fit nicely into a functorial framework. DeMarco data flow diagrams can be mapped by a free functor to terms in the initial algebra, which can then be mapped to other notations such as Yourdon structure charts by means of forgetful functors.

INTRODUCTION

In this chapter, we shall give an illustration of the practical usefulness of our framework. We shall discuss a prototype system which has been developed to implement the structured tasks. It has been implemented on a Macintosh using Turbo Pascal. It enables the user to draw a hierarchy of DeMarco-like task diagrams and stores them as structured tasks, which are stored physically in the form of pointers and linked lists. It helps the user to review the task diagrams to an appropriate level of detail, and zoom in/zoom out to lower/higher levels through refinements and abstractions as required. Given an incomplete task specification, the system prompts the user to define further details of his design considerations. For example, if the user wants to build a hierarchical structure into a flat task diagram, he will be prompted to supply the necessary details such as the names of intermediate levels. Given a hierarchy of task diagrams, the system then transforms them automatically into a term algebra, a Yourdon structure chart and also Jackson structure text. An example of an application of the system will be given in Section 7.2. An overview of the system with examples of its algorithms will be given in Section 7.3.

INTRODUCTION

In this chapter we shall compare our approach with five related systems development environments. These environments include PSL/PSA, ADS/SODA, SADT/EDDA, SAMM/SIGS and RSL/SREM. They have been chosen for comparison because of the following reasons:

1. (a) They were pioneer systems development environments meant to cover the entire systems life cycle, and have stood the test of time.

2. (b) They are better known and documented, so that interested readers can obtain further information easily.

3. (c) They are still under active development and recent enhancements have been reported.

4. (d) The languages examined cover a wide spectrum of characteristics. Some were originally developed as manual tools, but others were meant for mechanical support from the very beginning. For some languages, a system can be specified in a multi-level fashion, but not for others. Some languages use graphics as the specification medium while others are purely textual. Some of the development environments generate graphical feedback to users whereas others generate textual documentation.

5. (e) The final reason is a pragmatic one. We have included projects which are familiar to the present author. Part of this chapter is derived from the research results of a joint project with Mr Daniel Pong (Tse and Pong 1982, Tse and Pong (to appear)).

PSL/PSA AND META/GA

PSL was the first major language for defining a system formally and analysing it automatically (Teichroew 1971, Teichroew et al. 1980, 1982, PSL/PSA Introduction 1987).

Structured systems development methodologies have been recognized as the most popular tools in information systems development. They are widely accepted by practising systems developers because of the top down nature of the methodologies and the graphical nature of the tools. Unfortunately, however, the models are only derived from the experience of the authors. In spite of the popularity of these models, relative little work has been done in providing a theoretical framework to them. In this project, we have tried to solve the problem by defining a unifying theoretical framework behind the popular structured models.

We have defined an initial algebra of structured systems, which can be mapped by unique homomorphisms to a DeMarco algebra of data flow diagrams, a Yourdon algebra of structure charts and a Jackson algebra of structure texts (with equations). As a result, specifications can be transformed from one form to another. Algebraic interpreters may be adapted to validate the specifications.

We have also found that the proposed term algebra as well as the DeMarco, Yourdon and Jackson notations fit nicely into a functorial framework. The framework provides a theoretical basis for manipulating incomplete or unstructured specifications through the concepts of structured tasks and refinement morphisms. Moreover, DeMarco data flow diagrams can be mapped to term algebras through free functors. Conversely, specifications in term algebras can be mapped to other notations such as Yourdon structure charts by means of functors.

Perspective differences at the Postal Giro

When we enter a large organization like the Postal Giro, we will be exposed to a large inhomogeneous mass of written and spoken language: we listen to the speech of workers engaged in work, interview them and talk to them, read manuals and look at the screen images they work with, and talk to management in offices removed from the shop floor. Although many of these verbal exchanges clearly refer to the same physical phenomena, the linguistic forms can be quite different. It soon appears that each linguistic form is adapted to the particular function the speaker fulfills in the total structure of work processes and power relations in the organization. Each sub-language expresses a particular perspective (on perspective, see Section 1.2.2.2) and reveals a partial truth about the organization.

In the development of the PGP system there was one major issue that in a nut-shell illustrates the intricate interplay between language, perspectives and position in the division of labor. In semiotic terms, the issue was simply the relation between signifier and signified, in this specific case taking the form of a disagreement between union and management about electronic scanning of paper forms.

Management wanted to get rid of all paper by optical scanning of the paying-in-forms and wanted all subsequent work involving the cards to be done by means of electronic card images on a video screen. The union demanded that the basis of data recording should still be the paper forms, so that a direct feeling of the amount of work remained intact. The union succeeded in preventing electronic scanning of paper forms.

In the previous part, I described the basic properties of computer-based signs. They have three main kinds of features (permanent, transient and handling features) and are organized in two main chains (concurrent and sequential). In this part, I shall treat composite computer-based signs. How are smaller computer-based signs combined to form larger signs?

It is very clear that complex signs corresponding to linguistic concepts like phrases, sentences, and periods exist. The player of video games will experience long nerve-racking combat episodes involving the hero and one or more enemies, and the user of a word processor will engage in major tasks like proof-reading a manuscript or reorganizing the composition of a text, involving extensive handling of tools and text. Since these larger activities are manifested in system processes, they must be considered signs also, and since they contain smaller recurrent elements with meaning (the hero and enemy, the tools and texts), they are composite signs.

Although the three main features of computer-based signs have been treated in detail, I have not yet said much of the analytical consequences of the fact that computer-based signs participate in two different chains.

I shall continue using the textbook on folk-dance from Section II. 1.2, since a dance instructor or a writer of textbooks on dance faces problems similar to those facing a designer of computer systems. Like the designer prescribing the sequence of computer-based actions and the stage of the screen, the dance instructor must teach the dancers how to move in time on the floor, how to coordinate their movements with their partner, how to hold each other, and how to establish collective patterns.

A psychological definition of language games

In the preceding section, I showed how to use semantic fields of lexical material for various purposes: when the system developer enters the organization she can use them to get an impression of conceptual differences of the organization, when she starts doing particular applications she can use them to design the general data structure, and when she has made a prototype, semantic fields are useful for evaluating its reception and for redesigning it. Finally, researchers studying the general effects of computerization on organizations can use semantic fields to record language changes in the organization, and use these data as a basis for setting up hypotheses about changes of culture and cognition.

However, language is more than a vehicle for interpretation and description. Besides the ideational functions, language also has an action aspect that is subsumed under Halliday's interpersonal functions.

Although it is not a bad idea to start with the ideational aspect, since professional languages are registers and tend to differ in vocabulary, the action aspect is equally important in systems development. Language in work situations is not only used to interpret and describe, but also to act verbally, and in a similar way, computer systems are used as media for distributing work, giving orders, and reporting. Designers not only need to know which kind of information is needed and how it should be structured semantically, they also need to know when it is needed and for which purposes.

In the preceding section, I showed how to use work and conversation patterns as a basis for design. In this last section I discuss principles for building these patterns into the system. What does it mean to “put work patterns into the system”? To what degree should it be done? How should it be done?

As my example I shall use the data entry parts of the data entry (registrering) process classified as control style in Section II.2.2.2. Here I noted that the PGP-system is in control in this part of the work process and guides the worker through a fixed standardized sequence of operations:

In addition, it automatically provides the next card of the same batch, and the first card of the next batch when the last of the previous batch is finished and the batch tallies. If it does not tally, it enters the completing subview. The system supervises the user's work, and directs the worker's attention to and from the screen by means of error messages like

a type of control which was consciously introduced by the developers: they wanted to “stop a phase where you work with the card, and initiate a phase where you work with the screen”.

I have already classified this standardization of work as a “frozen” variant structure.

I start with a reassessment of selected linguistic traditions. Since they were developed to meet needs other than those I want them to serve, a careful reexamination is not out of place.

Empirical characteristics of two work languages

The first issue I shall take up is simply whether they are able to handle the language variety in which most computer systems must function, namely the languages of people at work, and in order to do so we need to know what a “work language” is.

The car repair shop

The typical Danish car repair shop is a small scale enterprise, consisting of the owner and a couple of skilled workers, possibly an apprentice and a bookkeeper, as well.

Most of the work can be performed by one worker alone, so cooperation is seldom a physical necessity. Planning and execution of the work procedure is integrated. The mechanic performs both tasks. Personal relationships between employer and employee survive, such as the master-journeyman relationship. Normally, a small stock of tools is used: hammers, screwdrivers, nippers, etc.

In the early eighties, I investigated communication in a small repair shop, and the following pages are based on this project. The research was done in collaboration with one of the mechanics employed in the garage. A taperecorder placed on a bench recorded the conversation that took place during work. (Everybody in the garage knew about the recording.) The mechanic also produced written descriptions of whole working days.

The analysis of the data took 1 1/2 years. The mechanic was employed as an assistant teacher in an advanced course at the university.