| click here for POSD home page |
POSD and similar notations represent the structure of a system as a composition of interacting component systems. A composition structure is normally too complicated to be represented in a single diagram. It needs to be represented by a hierarchical structure with the top level of the hierarchy representing the composition of the system from major component systems and lower levels showing how these major component systems are composed from minor component systems. There may be many views of the purpose of the system each of which can result in a different hierarchical structure for the system. Click on the heading above to see an example that illustrates these concepts. The example represents the structure of a very simple system and so can use a notation close to existing notations. More complex examples would require a POSD like notation, for reasons discussed below.
Systems engineers have for many years needed to represent the structure of software and hardware IT systems and needed to represent how the hardware structures supported the software structures. This problem has been extended recently as engineers have found themselves wanting to represent the structure of business (and engineering) processes and wanting to represent how the process structures were supported by software and hardware structures. This has been further complicated by the need to represent the structure and support of value-chains (the network of interactions between businesses) and organisations (the network of interactions between functional units within businesses). Click on the heading above to see simple examples of structures at the value-chain, organisation, process, software and hardware levels. These examples use the simple informal notation referred to above.
As the scope of the systems (whose structures needs to be represented) has expanded, existing notations have proved inadequate to the task. Existing notations represent systems as powerful compositions of component systems. However they treat the interactions between the systems as relatively primitive mechanisms. At the hardware level the interactions are seen as signals between hardware components, at the software level as function or procedure calls, at the process level as message passing or document transfers, at the organisational level as dependencies, goals, etc, and at the value-chain level as orders, deliveries, etc. This works reasonably well if the need is to represent the structure of a small system at one of these levels. However it breaks down when a system includes components at many of these levels and there is a need to represent how systems and interactions at one level relate to or are supported by systems and interactions at another level.
Take the IDEF0 notation as an example of existing notations. IDEF0 represents the structure of a system with an hierarchical structure, with the top level diagram in this structure representing the system as a composition of major component systems, and the lower level diagrams representing these major components as compositions of minor component systems. The diagrams use rectangles to represent component systems and lines to represent interactions between components. Whilst the rectangles in the higher level diagrams represent powerful compositions of the component systems in the lower level diagrams, the lines in the higher level diagrams are identical to lines in lower level diagrams (or at best sets of these lines). There is thus an abstraction mismatch between the rectangles and lines in the higher level IDEF0 diagrams. The rectangles are powerful abstractions of rectangles and lines in lower level diagrams whilst the lines are weak abstractions of lines in lower level diagrams. The lines in IDEF0 diagrams are incapable of representing the many different types of interaction found in a large heterogeneous system. POSD eliminates this notational weakness by recognising that the rectangles and lines represent the same type of entity and should therefore be given equal compositional power.
last revision: 21st June 1997