Fundamental Modeling Concepts
Fundamental Modeling Concepts ( FMC ) are a semi-formal methodology for communication via complex software systems .
history
Siegfried Wendt and his colleagues and students at the University of Kaiserslautern developed the foundations since the late 1970s . At the 1999 founded under the direction of Siegfried Wendt Hasso Plattner Institute at the University of Potsdam , these concepts were initially under the name SPIKES ( S tructured P lans for I mproving K nowledge transfer e ngineering of S taught ystems) before the year 2001 the name of FMC ( F undamental M odeling C oncepts) received.
relevance
A large number of software systems are analyzed, designed and documented with FMC. Known user is u. a. the Walldorf software house SAP , which documents the SAP R / 3 architecture with it. Hasso Plattner's enthusiasm for this methodology resulted in the establishment of the HPI ( Hasso Plattner Institute ), which in the past taught FMC's teaching in basic university training.
introduction
According to FMC, there are three interrelated ways of looking at software systems:
- Structure of the system
- Processes in the system
- Ranges of values
For each of these perspectives there is a type of diagram that can be used to graphically depict the respective aspect. The resulting diagrams , mostly easy to create, but also easy to understand , made FMC popular among its followers.
Basically, FMC diagrams serve one of two purposes: They are either intended to be used by a group to communicate about a software system, or they are used to introduce others (developers, customers, managers, etc.) to a software system. In the first case, the diagrams are usually somewhat more extensive in order to facilitate communication about more complex relationships; in the second case, small diagrams with few components are mostly used for didactic reasons. Aesthetics and clarity should always be in the foreground, however, since the main driving force behind the use of FMC is to promote communication. That is why the diagrams are the most important part of FMC, but do not need any comment.
Diagrams
All diagrams have in common that they are so-called bipartite graphs . A bipartite graph is a graph whose nodes come from two different classes , with the condition that no node may be directly connected to nodes from its class. The nodes of one class are always drawn as a rectangle (angular node), the nodes of the other as a circle , ellipse , oval or stadium (rectangle with two attached semicircles on two opposite sides) (round node).
In addition, the relationships shown in all diagrams can be refined or abstracted almost at will in other diagrams of the same type . This means that all abstraction levels of a system relevant to the software can be represented using the same method.
Structure diagrams
A construction diagram describes how a number of system components are related to one another. For this purpose, each component is identified as an actor , channel or store . Channels and storage facilities are also referred to as passive components, and actors as active components. Passive components cannot be directly related to other passive components, just as active and active components cannot. This results in a bipartite understanding of the system, which is reflected in bipartite structural images.
structure
In layouts, active components are represented by angular nodes and passive components by round nodes, with channels mostly being represented by a smaller circle and storage by a larger oval or stadium. The edges (connecting lines) between stores and actors must be directional , between channels and actors they can also be non-directional . The direction has the following meaning:
- Memory / Channel → Actor: Actor reads from memory or receives from the channel
- Actor → Memory / Channel: Actor writes to memory or sends via channel
There are no two-way edges. Instead, to express that an actor both reads from and writes to a memory, two oppositely directed edges are used (also known as modifying access ). In contrast to this, an undirected edge is used for channels.
Nodes can be grouped to illustrate similarities. To do this, another node is simply introduced that contains these other nodes. For example, some actors and memories can be part of a larger actor whose internal structure is to be represented, or there are a number of memories that are to be accessed by the same actor.
A special form of the channel is a request / response channel in which a using component calls up a service from another component and receives a corresponding response. These channels are marked with an "R" and an arrow that points from the calling to the called component.
Structural variance
The structure of many software systems can change during runtime. This structural variance is interpreted in FMC as follows: The affected subsystem is regarded as a memory, regardless of its actual structure, which can be modified by an actor not contained in this subsystem. Correspondingly, a memory (to distinguish it with a dashed outline) that contains this subsystem and the modifying access of the structure variance actor to this memory are drawn in in the structure diagram.
Sequence diagrams
Processes are represented with a class of Petri nets , the condition-event nets, since these are also bipartite. In FMC Petri nets, each position can normally only contain one mark, so the switching rule is:
A transition switches exactly when all input labels are occupied and all output labels that are not input labels at the same time are free.
There are also places that can accommodate any number of places and are represented by a double circle. Special 'infinite' positions are stack positions and return positions.
In addition, in FMC Petri nets there is the means of resolving conflicts by evaluating conditions. If several edges depart from a point, conditions can be written to these edges, which can be used to determine which transition switches in which case.
Range of values images
These are slightly modified and expanded entity relationship diagrams . Entities (objects) are round nodes in FMC diagrams, while relations are angular. Entities can have attributes that are noted as a list in the entity's node. Abstraction enables entities to contain relations so that relations can be related to other entities or relations. Partitions of entities are represented either by drawing the sub-entities into the entity to be partitioned, or by the triangular partition symbol (which represents the "partition relation", so to speak).
Layer diagrams
For the exemplary representation of quadratic relations, i. H. Relationships on a set of elements, so-called layering diagrams can be used. This is the abbreviated representation of a matrix representation with which any two-digit relations can be represented. For example, this type of diagram can be used to display the call stratification of procedures or the dependencies of the packages within a computer program (the recursion case can also be displayed).
Although this form of representation is used in a number of FMC-based modeling documents, it is not considered a conceptual part of FMC. Rather, it is a case-by-case useful addition to the description, just as UML class diagrams or screenshots are useful means of description for certain other aspects.
See also
- Unified Modeling Language , a graphic modeling language for the specification, construction and documentation of software parts and other systems
literature
- Siegfried Wendt: Non-physical basics of information technology. Interpreted formalisms. 2nd Edition. Springer-Verlag, Berlin Heidelberg 1991, ISBN 3-540-54452-6 ( PDF; 7.31MB ).
- A PDF version that was approved by the author after the original edition was discontinued. Even if this work does not aim specifically at the description of FMC, but is much more fundamental in content and structure, the interested reader will nevertheless recognize the knowledge base on which FMC is based.
- Andreas Knöpfel, Bernhard Gröne, Peter Tabeling: Fundamental Modeling Concepts: Effective Communication of IT Systems , Wiley 2006, ISBN 0-470-02710-X
- Peter Tabeling: Software systems and their modeling , Springer-Verlag Berlin Heidelberg 2005, ISBN 3-540-25828-0