Notations
Rooted in military art, the decomposition principle, also known as the divide and con- quer strategy, has been recognised for a long time and in many domains as an effective means to overcome complexity and enable the solving of complex problems. The idea is basically to break a complex problem (such as understanding and/or designing a complex system) into smaller, manageable pieces, solve each of them separately and combine the partial solutions to obtain a complete solution. Obviously this principle in not enough for managing the complexity in those systems where the system behaviour emerge from the local interactions at run-time (see Section 11.3). These systems need different tools that are out of the scope of this work.
System development methodologies have adopted the decomposition principle, either intentionally or not. Most methodologies apply this strategy by breaking the system into a number of models, each dealing with a different aspect of the system, such as structure, behaviour and function. Each model applies a different set of symbols and concepts, and together they are expected to convey a complete system specification. This aspect decomposition is at the heart of standard, state-of-the-art object-oriented development languages like UML. A system is then expressed as a multiplicity of different models, each representing a specific system aspect: actually, UML defines thirteen types of diagrams, four of which represent the static application structure, five are devoted to capture the system’s dynamic behaviour, and three are related to the organisation and management of application modules [123]. Altogether, all these models are expected to convey a complete system specification.
However, although the availability of so many models constitutes a richness from the expressiveness viewpoint, each model introduces its own set of symbols and concepts, thus leading to an unnatural complexity in terms of vocabulary, model multiplicity and model integration [54]. This is a problem both for maintaining consistency among the different system models and views, and for the mental integration of such views, since integrating several models within one’s mind is a very difficult process. That is why the need to concurrently refer to different models in order to understand a system and the way it
Figure 12.1: Example of folding in a object process diagram [54]
operates and changes over time is a critical issue, known as the multiplicity problem [171]. A different notation, OPM, adopts a different approach. A basic principle in OPM is that structure and behaviour within a system are so intertwined that effectively sep- arating them is extremely harmful, if not impossible. OPM has adopted the detailed decomposition: rather then decomposing a system according to its various aspects, the decomposition is based on the system’s levels of abstraction. OPM controls complexity through granularity levels, refinement, and abstraction similar to zooming in and zoom- ing out in a digital map. Three built-in refinement/abstraction mechanisms are built into OPM. They enable presenting the system elements at various detail levels without losing the comprehension of the system as a whole.
12.2.1
Detail Decomposition in OPM
OPM controls the complexity through granularity levels, refinement, and abstraction similar to zooming in and zooming out in a digital map. There are three scaling modes with respect to the three entities of OPM—object, process and state. Visibility scal- ing zooms in or zooms out of a process, hierarchy scaling unfolds or folds an object, and manifestation scaling expresses or suppresses a state. These are done via three re- finement/abstraction mechanisms: unfolding/folding, in-zooming/out-zooming, and state expressing/suppressing.
Figure 12.2: Example of in-zooming in a object process diagram [54]
components (parts, specialisations, features, or instances). Unfolding reveals a set of lower-level entities that are hierarchically below a relatively higher-level thing. The hier- archy is with respect to one or more structural links. The result of unfolding is a graph, the root of which is the thing being unfolded. Linked to the graph are the things that are exposed as a result of the unfolding. Conversely, folding is applied to a tree from which a set of unfolded entities is removed, leaving just the root. Figure 12.1 shows an example in which the Order object is unfolded, showing its operations and event triggers. Unfolding/folding can be applied fully or partially to any subset of descendants (parts, specialisations, features, or instances) of a thing (object or process).
A state is a situation in which an object can be for some period of time. At any point in time an object is in exactly one of its states. State expressing is a refinement mechanism applied to objects which reveals a set of states inside an object. State suppressing is the abstraction mechanism which conceals a set of states inside an object. Figure 12.1 shows an example in which Order Status is expressed.
In-/out-zooming is applied by default to processes for detailing/hiding their sub- process components and details of the process execution. In-zooming of (i.e., zooming into) an entity decreases the distance of viewing it, such that lower-level elements en- closed within the entity become visible. Conversely, out-zooming (i.e., zooming out) of a refined entity increases the distance of viewing it, such that all the lower-level ele- ments that are enclosed within it become invisible. Figure 12.2 shows an example of the in-zooming of the Ordering process.
Despite the different names, all the OPM scaling mechanisms allow engineers to work middle-out: MAS engineers can choose to start at any arbitrary abstraction level, and then achieve both the most detailed level and the most abstract level, along with the entire spectrum of intermediate levels between these two extremes.