2.5 CESAM Systems Architecture Matrix
We are now in position to introduce CESAM Systems Architecture Matrix, which is presented in Table 7 below. This matrix is just a synthesis of the different architectural dimensions that we introduced within this chapter. It indeed presents all the types of views that allow to exhaustively describe any system, classified according to:
- a first axis of classification corresponding to the three architectural visions, that is to say the operational, functional and constructional visions,
- a second axis of classification corresponding to behaviors, that is to say the conjunction of:
o expected properties,
o all descriptions, i.e. states, static elements, dynamics and flows.
Crossing these two axis, one thus immediately gets the matrix of Table 7 where we listed the names of all different views that were introduced along the current section. As already stated above, the completeness of all these views in matter of system specification is an immediate consequence of all the material that we introduced along the previous pages.
| Visions | Expected properties | Descriptions | |||
| States | Static elements | Dynamics | Flows | ||
| Operational vision | Needs | Operational contexts | Missions1Including descriptions of all integration mechanisms involving missions. | Operational scenarios | Operational flows or objects |
| Functional vision | Functional requirements | Functional modes | Functions2Including descriptions of all integration mechanisms involving functions. | Functional scenarios | Functional flows or objects |
| Constructional vision | Constructional requirements | Configurations | Components3 Including descriptions of all integration mechanisms involving components. | Constructional scenarios | Constructional flows or objects |
Table 7 – CESAM System Architecture Matrix
As explained in subsection 2.4.3, one will of course always have to find the good balance between expected properties and descriptions when specifying a system. CESAM System Architecture Matrix is thus only a help to be sure that all dimensions of a system where taken into account during its modelling, but it does in no way provide – neither CESAM System Architecting Method does – an automatic specification mechanism for systems. Systems architecture indeed remains an art where expertise, experience and competency of systems architects are clearly fundamental!
To concretely illustrate this last notion, let us now provide an example of a partially completed CESAM System Architecture Matrix for the electronical toothbrush.
| Visions | Expected properties | Descriptions | |||
| States | Static elements | Dynamics | Flows | ||
| Operational vision | End-users want to have less than one cavity in average per 5 years due to teeth brushing | Teeth brushing | Brush teeth | Teeth brushing scenario | Toothpaste |
| Functional vision | The electronic Toothbrush shall produce a brushing force of 0.5 N in automatic mode | Automatic mode | Produce a brushing force | Brushing force production scenario (functional) | Brushing force |
| Constructional vision | The electronic toothbrush shall have a removable head in children & adult configurations | Children configuration | Head | Brushing force transmission scenario (concrete) | Electricity |
Table 8 – Example of a CESAM System Architecture Matrix for the electronical toothbrush
One can now understand why system modeling is so unintuitive. If one completes CESAM System Architecture Matrix by adding system abstraction / integration levels, one may indeed understand that a system model looks much more to a cube than to a matrix as depicted on Figure 37 below that represents CESAM System Architecture Cube, the 3D-version of the 2D CESAM System Architecture Matrix. One can thus understand that it is easy to be lost in such a multi-dimensional world!
Figure 37 – CESAM System Architecture Cube
Note also that the three first descriptions types – that is to say states, static elements and dynamics – are the most important since the last one – flows – is just a dedicated synthesis, focused on exchanges, which consolidates information that can already found in the views corresponding to dynamics. Restricting the CESAM System Architecture Matrix to these three first descriptions types leads us thus to a simpler matrix – the so-called CESAM 9-views matrix4 This terminology was invented by Vincent Vion, chief systems architect of PSA Peugeot Citroën. – which provides the minimal number of descriptions to construct when “modeling” a system5Beware that modelling is considered in this pocket guide in a broader way with respect to the usual meaning of this concept which, for most authors, only refer to description – in the meaning of subsection 2.4.2 – construction.. An example of such CESAM 9-views matrix is provided below on the electronical toothbrush case study.
Figure 38- Example of a CESAM 9-views matrix for an electronical toothbrush6Our example of functional scenario is represented here using an activity diagram (see [20]) which an alternative to the representation mode introduced and discussed previously
At this point, note finally that CESAM Systems Architecting Method is nothing else than a certain way of moving in the CESAM System Architecture Matrix, starting from the knowledge of all use cases provided by the system lifecycle up to arriving to a quite precise vision on all constructional scenarios of the system. We will not develop this point here since the forthcoming chapters are dedicated to the presentation of the main deliverables of that process.
Next pageTABLE OF CONTENTS
REFERENCES
[20]Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language Reference Manual,Second Edition, Addison-Wesley, 2004