2.2.2.3 Constructional Vision
The constructional vision provides white box models of the system where one describes all concrete hardware, software and “humanware”1Remember that men can be part of systems with either strong organizational dimensions such for instance as information
systems, or when a human stakeholder plays such a key role (e.g. pilot, driver, operator, etc.) that it may be important to include him/her in the design, considering then an operated system rather that the underlying technical system alone. components of a system with their interactions. Its core motivation is to elicit in that way the concrete structure – that is to say the “How” – of the system. It is thus probably the most intuitive part of a systems architecture.
Figure 23 – Constructional vision – Product Breakdown Structure (PBS) of an electronic toothbrush
The core notion of the constructional vision is of course the notion of “component of a system”, that refers to a concrete part of the considered system. In other terms, a component associated with a given system models a physical, software or even “humanware” resource that belongs to the system. In other word, each atom of a system shall belong to one and only one of its components. A common pattern to denote a component is thus just to use its usual technical or business name.
Exactly as in the functional vision, all constructional concepts – such as configuration, constructional scenarios or constructional objects (see Section 2.4 for more details) – are again uniquely referring to the system of interest, without involving any external system. All these concepts can be managed at different levels of abstraction / grain. Figure 22 shows for instance the Product Breakdown Structure (PBS) of an electronic toothbrush, where its components are put in a hierarchy according to the fact that a high level component results from the integration of the lower level components.
Note finally that the term “architecture” usually only refers to the constructional architecture of a system. One shall thus be aware of the fact that we will use this term in a much broader acceptation through our entire pocket guide, especially when speaking of systems architecture which does refer to the union of all architectural visions for a given system as introduced above.
2.2.3 Relationships between the three Architectural Visions
Last but not least, it is also important to point out the network of relationships existing between the three architectural visions, since they are at the heart of the systems architecting process. It is in particular especially important to maintain these relationships during the different design phases, which is difficult due to the “highly iterative & recursive nature” of systems architecting [66].
Figure 24 – Relationships between the three architectural visions
Figure 24 shows the generic relationships between the architectural visions as explained below.
• The operational vision connects first with the two other visions due to the fact that missions are naturally implemented by functions, but also components. Another way to make this connection is to observe that all external flows between the different external systems and the system of interest, as provided by the operational vision, must be internally captured or produced (depending the external flows are input or output flows from the internal point of view of the considered system) by functions of the system of interest2 In other terms, it is sufficient to continue each external flow, as identified in the operational vision, within the system to get the first functions of the system of interest. Functional analysis will then continue internally the same kind of analysis up to identifying exhaustively all functions, which can be checked by a functional synthesis proving that all identified functions are forming a coherent functional network.
• The functional vision connects back in the same way with the operational vision and forth with the constructional vision due to the fact that each abstract function must be concretely allocated to / implemented by some set of constructional components.
• The constructional vision connects then back to the two other visions according to the implementation and allocation relationships that we just pointed out.
Note in particular that one should not think3Which is unfortunately a common mistake … that operational artefacts do only allocate to functional artefacts, which on their side do only allocate to constructional artefacts. Such a vision would indeed be dramatically false. Operational, functional and constructional visions shall indeed be analyzed as a circle of three interdependent visions. Figure 25 illustrates this situation.
Figure 25 – Relationships existing between the three architectural visions
One must first understand that the operational vision is nothing else than a mixed functional and constructional description of the part of the environment of the system of interest which involves this last system. As an immediate consequence, the functional (resp. constructional) dimension of the environment Env(S) of a given system S naturally maps with the functional (resp. constructional) dimension of S. Such a property implies therefore that operational architecture is connected both to functional and constructional architectures of a given system. As a matter of fact, the geometry of a given system’s environment – which is one of its typical constructional properties – maps for instance directly with the geometry of the considered system, without any connection with functions4The shape of my body typically implies the shape of a chair, without requiring any functional analysis…. The same situation also holds for most of the physical properties of the environment.
On the other hand, one must also notice that there may be feedbacks from the constructional vision onto the functional vision and/or the operational vision and/or from the functional vision onto the operational vision. The choice of a specific technology at constructional level may indeed typically induce functions that were not directly requested. Deciding to implement a given service through an automated device creates for instance immediately the “To distribute electricity” function. In the same way, the choice of a specific function at functional level may allow new services that were initially not designed. As another example, just remember that nobody could imagine the creation of an entire new world of new services thanks to the apparently simple Internet functionality5Which functionally speaking is nothing else that allowing the exchange between different computers!
2.2.4 Organization of a System Model
We are now in position to derive the first consequences of the CESAM framework on the structure of a system model. We are indeed now aware of two dimensions of any system, the first one being provided by the three architectural visions used to model a system, the second one being simply given by the abstraction / grain level on which a given system may be analyzed. On this last point, we shall just recall that any integrated system can be analyzed on the different levels of its integration hierarchy that is to say at system, sub-system, sub-sub-system, etc. levels.
Figure 26 – Organization of a system model
Hence any system model can be naturally organized in a matrix way where the different system views are classified according to their architectural vision and the level of analysis within the system integration hierarchy, as depicted in Figure 26. Note that the horizontal relation between these views is allocation or implementation as explained in the previous sub-section, when the vertical relation is refinement when going from a high level view to a lower level view and abstraction when doing the converse. Refinement means here providing more details with respect to a given architectural view, when abstraction stands for a not (too much) destructive idealization6An abstraction/refinement mechanism is formally provided [25] by a pair (α , ρ ) of applications between sets of so-called concrete objects and sets of so-called abstract objects, where abstraction application α maps each set of concrete objects into a set of abstract objects and refinement application ρ maps each set of abstract objects into a set of concrete objects. These applications are then called an abstraction/refinement pair if and only if α(ρ(A)) ⊆ A for each abstract set A (refining an abstract set and then re-abstracting the result cannot enlarge the initial abstraction) and C ⊆ ρ(α(C)) for each concrete set C (abstracting a concrete set and then refining the result cannot reduce the initial concrete scope). of a series of views, where one will reason in terms of clusters from a lower level perspective, thus losing the details for getting the big picture on a given architectural topic7Abstraction & refinement are core mechanisms for systems architects, especially when creating architectural hierarchies. A quite frequent problem in architecture is indeed the excessive number of objects generated by a step of an architectural analysis. In order to handle them effectively and to achieve their real global understanding, we typically have to cluster and to synthesize them into abstract objects. This abstraction activity can be achieved by partitioning the objects in clusters of “similar” weakly inter-dependent objects, then clarifying systematically the key characteristics (goal, function, feature, etc.) of each group and naming each group consequently. Such a process will naturally lead to architectural hierarchies such as Mission, Functional or Product Breakdown Structures as introduced in the previous subsections.. On one hand, refinement is clearly the right tool when one wants to precisely analyze a problem. On the other hand, abstraction86 As a matter of fact, one observes in practice that abstraction is not at all an easy activity. Most of people are in particular not able to manipulate efficiently this mechanism. The key difficulty is indeed to find the “good” abstractions of a given problem, that is to say a good balance between too abstract and too detailed views. The key point is here to be able to manipulate coarse grain views, with which one can reason more easily and thus take the good strategic decisions, but that can also be refined in fine grain views. This requires the abstract views to be holistic in order to capture all dimensions of a given problem. What happens unfortunately often in real life is that one creates too simple abstractions to be useful! is crucial for being able to define an architectural strategy without being lost in an ocean of details.
NEXT PAGETABLE OF CONTENTS
REFERENCES
[66] NASA, Systems Engineering Handbook, 2007-edition, NASA/SP-2007-6105, 2007