Chapter 1
Types of Diagrams for Representing Structures of Cooperative Systems
= Fundamental Modeling Concepts (FMC)



Home
1.1
Two
Problems
1.2
Concept
of the
Solution
1.3
Composition-
Diagrams
1.4
Process-
Diagrams
1.5
Data-
Structure-
Diagrams
1.6
Metadiagram
of the FMC-Diagrams
1.7
Layering of
Interpreters
1.8
Separation
of Phases

1.2 Concept of the Solution

Irrelevance of the program text:
Appropriate graphical representations of the results of planning a software system can only be found by neglecting the fact that implementing the system means writing program code. For programs are texts whose structure is completely irrelevant with regard to solving our actual presentation problem. The concentration on the program text will even lead the seeker into wrong directions. Instead of thinking about a static text, we must be aware that we consider systems in which dynamic processes occur, which arise through cooperation between individual agents. This special feature of the approach to solving the problem is already expressed in the chapter headline: Types of Diagrams for Representing Structures of Cooperative Systems.

Distinguishing between role and interpreter:
The notion of a cooperative system involves the idea that there are several agents who cooperate to reach a common goal. One usually has the idea that the agents are people. However, in addition to humans, animals and technical systems can also be seen as agents in a cooperative network. When people use computers, it is usually not the bare hardware with which they cooperate, but they cooperate with agents who are created by a computer or a computer network which appear in certain roles by the interpretation of software. It is therefore appropriate to say that an agent is determined by the role which an interpreter currently "plays". In a theater, the interpreters are the actors, and in the field of information technology, the interpreters are the computers. If you are only interested in the play that is being played, you will quickly forget who is the current interpreter of a certain role, and you will only be interested in the agent being incarnated by the interpreter. Software should therefore always be regarded as a description of interacting role players, and the cooperative system thus formed must be presented. This view also makes it clear that the linguistic formulation of the roles is irrelevant to the understanding of the cooperation system - a role can be formulated in any language, and still remains a definite role.

Generalization of the type of "workpieces":
Since we are considering software systems, it seems to be natural that what is to be processed by the cooperating agents must be information. But this restriction is not necessary. Rather, we can widen our view, at least in part, to what is common to all systems in which several agents work together by stepwise operating on "workpieces". These workpieces can be material, energetic or informational. Informational workpieces are data. The systems do not even have to be "puristic"; it is quite permissible that all three types of workpieces occur simultaneously in one and the same system.

Composition diagrams, process diagrams and data structure diagrams:
Each workpiece is located at a certain location in the system at any time, and the operations of the agents consist of step-by-step actions. An action serves to change a workpiece, or to join two or more workpieces to a single one, or to split one workpiece into two or more workpieces, or to move a workpiece from one location to another. Since the actions take place in certain places, I call the places action fields. Action fields on which the workpieces rest are storages, and action fields on which the workpieces move are channels. From the nature of the actions for which an agent is responsible follow the action fields which he must have access to, and this can be represented in a so-called composition diagram .

Since the cooperation of the agents serves a particular goal, their actions are partially causally interdependent, which means that the beginning of an action may require the end of certain other actions. This causal dependency can be represented in a so-called process diagram .

While the nature of the workpieces - material, energetic or informational - is irrelevant for the composition and process diagrams, the plans describing the structures of composite workpieces depend, of course, on the nature of the workpieces. In the present study, we are dealing with software and thus with informational workpieces, i.e. data, and their structure is represented in so-called data structure diagrams .

Relations between the diagrams:
The information required to understand a large system can only be covered with a large number of diagrams. With the exception of the "top" composition diagram, each of these diagrams has a "father diagram" to which it is assigned and to which it provides further information. That which a node symbolizes in a diagram does not have to be elementary. Therefore each diagram containing such non-elementary nodes will be the father of "child diagrams" of the same type, one for each non-elementary node. For example, an agent which appears in a composition diagram can itself be a system for which there is a composition diagram. And an action in a process diagram can be composed of a set of simpler actions whose causal dependencies can be represented again in a process diagramm. In addition to the child diagThat which a node symbolizes in a diagram does not have to be elementary. Therefore each diagram containing such non-elementary nodes will be the father of "child diagrams" of the same type, one for each non-elementary node.rams, which show structures that are abstracted in a node of their father diagram, there is also a second form of father-child relationship. In these cases, the parent is always a composition diagram, whereas the child is either a process or a data structure diagram. The father-child relationship is based on the fact that the child either shows actions performed by the agents on the father diagram, or that it describes a data structure that occurs on an action field in the father diagram. From the various possible father-child relationships between the diagrams it follows that the top diagram - that is, the only diagram that has no father - can only be a composition diagram. And this is the most important diagram for the understanding of the system, since all the diagrams below only provide further information that could not be classified without the composition diagram at the top.

to the top