| click here for POSD home page |
Another part of this POSD presentation identifies problems that are encountered when a typical graphical notation is used to represent the structure of a system. The problems can be summarised as:
The example presented below illustrates these problems. It is expressed in the IDEF0 notation. The use of IDEF0 to illustrate these problems should not be taken as an attack on IDEF0 in particular. On the contrary IDEF0 is one of the best notations available and has been used here because it allows the problems to be illustrated succinctly. Good introductions to IDEF0 can be seen by searching on the internet for IDEF.
IDEF0 allows the structure of a system to be represented in a hierarchically structured set of diagrams. The top level diagram in the hierarchy represents the system as a set of interacting activities. Second level diagrams represents each of these (top level) activities as a set of interacting (lower level) activities, and so on down through as many levels as are necessary. Activities are represented in diagrams by rectangles. Interactions with activities are represented by lines. Four types of interaction are catered for:
For instance the following diagram gives a top-level IDEF0 view of the example problem:
Here the input is funding, the output is supplies, the control is requirements, the mechanism is people, and the activity is supplying a construction project. The example problem is close to that discussed in another part of this POSD presentation, where the phrase "representing the structure of systems" is analysed and defined.
Click here to see an IDEF0 model for the example problem - supplying a construction project. Most names used in the model should be self explanatory. In order to simplify the model the mechanism interactions have been omitted.
Click here to see the IDEF0 model with the mechanism interactions included. The inclusion of these interactions makes it clear which people are responsible for each activity.
The example introduced above is a very simple use of IDEF0. In a real application of IDEF0 one would expect to see the model refined through about five levels of diagrams with about five rectangles in each diagram. There would then be about 5 rectangles in the top level diagram, 25 in the second level diagrams, 125 in the third, 625 in the fourth and 3125 in the fifth. One would expect each diagram to be presented on a separate A4 sheet so that the complete model would require hundreds or even thousands of A4 sheets.
Thus a rectangle in a high level diagram can expand into a network of hundreds or even thousands of rectangles and lines in the lower level diagrams. A rectangle in a high level diagram is thus a very powerful abstraction.
Now consider the abstractions provided by lines. Lines in a high level diagram are frequently identical to lines in lower level diagrams. For example, look at the line, orders, in the IDEF0 model introduced above. Some lines in a high level diagram expand into sets of lines in lower level diagrams. For instance, the line, requirements, expands into the lines, supplier constraints and supply requirements.
In both cases, the lines provide much weaker abstractions than rectangles. Rectangles in high level diagrams can expand into networks of hundreds of rectangles and lines in lower level diagrams, whilst lines can at best expand into sets of lines. This means that there must be an abstraction mismatch in high level diagrams with rectangles representing powerful abstractions and lines representing weak ones. This constrains the designers ability to think about the design at a high (abstract) level.
Now consider the line, orders, in the IDEF0 model. This appears in the top level diagram and also appears unexpanded in the lower level diagrams. Suppose that this line represents a complex interaction, such as that shown below:
This complex interaction can be thought of as comprising two meetings between the staff of the suppliers and the staff of the construction company, one to agree the nature of the supplies and one to agree contracts.
The complex interaction could be catered for if the IDEF0 notation allowed lines (like rectangles) to expand into networks of rectangles and lines. Click here to see what the model might look like with this enhancement of the IDEF0 notation.
However this raises the question - why not replace the line, orders, with a rectangle, formalise orders, thus staying within the kosher IDEF0 notation. Click here to see what the model would look like then.
This change is fruitless. The problem which was originally noted for the line, orders, has now migrated to the line, formal orders. Either this line represents a complex interaction, in which case it (like the line, orders) needs an expansion as a network of rectangles and lines, or it is a simple interaction in which case the abstraction mismatch problem has manifested itself in the top level diagram.
The above has shown that IDEF0 exhibits the second of the two problems referred to in section 1.4.1 - the symbols, rectangles and lines, have different expressive power. It has shown that the only solution to the problem is to treat rectangles and lines in the same way and give them the same compositional capability.
This change to IDEF0 would open up many possibilities. Click here to see how it might affect the example problem. The possibilities are explored more fully in the POSD definition and the POSD examples.
The above has only used the functional structuring notation, IDEF0. IDEF also supports an information and data structuring notation, IDEF1, a process structuring notation, IDEF3, and other notations. Hence IDEF exhibits the third problem referred to in section 1.4.1. It imposes a restricted and stylised set of hierarchical structures.
Another part of this POSD presentation (where the phrase "representing the structure of systems" is analysed and defined) introduces an example problem and establishes the need for different structural views of the problem. Each of those views could be represented in an hierarchical IDEF0 structure (and possibly IDEF1, IDEF3, etc). However this would go beyond normal IDEF0 practice.
Another part of this POSD presentation established the need for multi level views of a business problem ranging from the value-chain view, via organisational, process and software views, to the hardware view. In principle this can be done in IDEF0. One can produce an IDEF0 model for each of the levels. The mechanism interactions in each model provide the links from that model to lower level models.
Thus many different hierarchical IDEF0 structures would be needed to fully represent the structure of a complex system (more than are normally suggested by the IDEF method). It would be difficult to correlate the entities in these different hierarchies unless IDEF0 had the extensions introduced in section 1.4.8 (and thus effectively became POSD).
last revision: 21st June 1997