7.2.1. Constructional requirement architecture diagram

Let S be a system. The constructional requirement architecture diagram of S is then a hierarchical exhaustive representation of all constructional requirements of S, a constructional requirement R1 being under another constructional requirement R2 in this hierarchy if and only if we can logically deduce R1 from R2⁶. In this last situation, we say then more precisely that R2 refines into R1, which explains why we speak of a constructional requirement refinement hierarchy⁷.

The above Figure 7.2 shows a (quite partial) constructional requirement architecture diagram for an electronic toothbrush, a constructional requirement being – classically and similarly both to a need and to a functional requirement – represented here by a 2-part box, whose first top part is a short name summarizing the constructional requirement scope and whose second bottom part is devoted to the constructional requirement statement, when the different refinement relationships on which relies the constructional requirement hierarchy are – also classically – represented by arrows.

The same issue that was already pointed out, both for need and functional requirement architecture diagrams, also happens in the same terms for the constructional requirement architecture diagram: organizing a constructional requirement refinement hierarchy is indeed always difficult since we shall avoid having too many first level constructional requirements, but of course also too many levels of refinements, as soon as we want to be able to efficiently use such a view. The 7x7x7 rule (see the first part of section 4.2) is again precious to handle this real difficulty. As a consequence, a typical “good” constructional requirement architecture diagram associated with a given system shall have no more than seven high-level constructional requirements, each of them being refined in around seven medium-level constructional requirements, finally also refined in the same way into seven low-level constructional requirements. Note again that the number 7 is just an order of magnitude. Obtaining up to 10–12 high-level constructional requirements in a constructional requirement architecture diagram could of course work: however, we must probably not go further without analyzing whether this number is justified. Finally, we shall not hesitate to construct as many additional constructional requirement architecture diagrams as necessary, for refining such an analysis as soon as all relevant constructional requirements are not derived and/or captured.

7.2.2. Configuration diagram

Again let S be a system. The configuration diagram of S is then a representation of:

• – the configurations of S, with their relative temporal relationships, that is, consecutiveness, inclusion or simultaneity⁸;
• – the events that cause the different transitions between each configuration of S and the immediately consecutive ones.

The standard representations of the temporal relations between configurations introduced above are given – mutatis mutandis – by Table 5.1, if we now interpret C and D as configurations.

The above Figure 7.3 provides an example of configuration diagram associated with an electronic toothbrush, which is here quite simple, taking the standard representation of configurations and of their temporal relationships that we introduced, when events – that induce configuration transitions – are modeled by arrows labeled with the name of the relevant event. Note also that the initial (respectively, termination) events in each configuration do not respect this rule since they are conventionally modeled by small black circles (respectively, by white circles containing a black circle).

The configuration diagram is key since it models – from a purely constructional perspective – time, even if it is not immediately obvious to see here. Following the intuition that we developed at the end of the second paragraphs of sections 5.2 and 6.2, we could consider that the next diagrams – that is, the constructional breakdown and interaction diagrams – are modeling the “constructional space” in which components are evolving. Since both space and time are always required to specify any constructional reality (that takes place somewhere at a certain time), we can easily see that these two diagrams are again completely complementary.

7.2.3. Constructional breakdown and interaction diagram

Let S be a system. The constructional breakdown diagram associated with S is then a hierarchical representation of the components of S, a set C1, C2, …, CN of components being under another component D in this hierarchy if D is the result of the integration – in the meaning of Definition 1.5 – of the components C1, …, CN⁹ (C1, …., CN are then classically called “sub-components” of D). The constructional interaction diagrams associated with S are then just the different representations – there is one constructional interaction diagram per integration relation involved in the constructional breakdown diagram – of each such integration relationship that exists between the different components appearing in the hierarchy modeled by the constructional breakdown diagram.

The previous Figure 7.4 now provides an illustrative partial example of constructional breakdown diagram for an electronic toothbrush, where the integration relationships on which such an hierarchy relies are – quite classically – represented by black-squared (respectively, white-squared) arrows when the low-level component is mandatory (respectively, optional, which allows us to model product options using this last syntax), with respect to the depicted integration relationship.

We also give an example of a constructional interaction diagram for an electronic toothbrush that can be found in Figure 7.5. It provides the integration relationship existing between the electronic toothbrush in its whole and its first “sub-components” as they are appearing above in the previous constructional breakdown diagram.

The constructional breakdown of a system S modeled by the constructional breakdown diagram is also classically called the product breakdown structure (PBS) of S. Similarly to the mission or the functional breakdown structures that we introduced in the two last chapters, it provides the exhaustive dictionary of components of the system and has a key role in guaranteeing a common understanding on the constructional scope of a system, which is mandatory for efficient transversal collaboration between the different actors and stakeholders of a system development project.

We must, however, be aware of the good readability of such a view. Just observe in this matter that all the recommendations based on the 7x7x7 rule that we previously gave for the stakeholder and the need architecture diagrams of course also apply – mutatis mutandis – for efficiently modeling the PBS of a given system.

Note also that Figure 1.9 in Chapter 1, even if formally functionally oriented, can also be easily re-interpreted as a constructional interaction diagram, here associated with an aircraft: each “box” of this diagram, even if, strictly speaking, representing a first-level sub-function of an aircraft, may indeed also naturally be interpreted as a first-level sub-system of an aircraft. The same remark does not, however, apply – mutatis mutandis – for the functional architectures discussed in Introduction since the functional and constructional architectures are not fully aligned for these examples.

7.2.4. Constructional scenario diagram

Let again S be a system and q(S) a configuration of S. A constructional scenario diagram associated with S and q(S) is then a dynamic representation of the interactions that are taking place between the components of S, and possibly the environment, during the period of time modeled by q(S).

The following Figure 7.6 shows an example of the constructional scenario diagram, associated with the “children” configuration of an electrical toothbrush. It shows how the electronic toothbrush sends an encouraging message to the end-user, when in a children configuration (see Table 3.5 for the corresponding illustration). We refer to the suitable paragraph of section 3.4.2 for all the details on the semantics of the below representation.

A constructional scenario diagram provides therefore the explicit “algorithm” which is underlying to the constructional interactions of the system that occur in a given configuration. This is key to finely understand what concretely happens during a given configuration.

Observe finally that this last diagram has also a functional nature since it models in a certain way a “constructional behavior”: we shall thus always be aware, on the first hand, not to overlap at this level with functional architecture in order to avoid making two times similar analyses and, on the second hand, to be fully consistent with the already constructed functional scenario diagrams.

7.2.5. Constructional flow diagram

Let S be a system. The constructional flow diagram associated with S is a consolidated description of all constructional flows associated with S and of:

• 1) their logical relationships;
• 2) their abstraction relationships (see the last section of Chapter 5).

Hence, it plays the role of the constructional “data model”¹⁰ of the system. Note that we may also split this diagram into two diagrams, each of them covering the two above points.

Figure 7.7 that follows shows an example of a (partial) constructional flow diagram, associated with an electrical toothbrush. It can be constructed by consolidating all the constructional flows that are appearing in the high-level constructional interaction diagram which is provided in Figure 7.5 for an electronic toothbrush. Its syntax exactly follows the same principles than for the operational and functional flow diagrams (see the last paragraph of the last two previous chapters).

As already stated, such a constructional flow diagram defines the constructional flow or object model of a given system. It is therefore completely “dual” to the constructional breakdown, interaction or scenario diagrams since it focuses only on flows and absolutely not on the different components of the system that are producing these flows.

We must therefore emphasize that such a diagram is of high importance since it rationally describes in a consolidated and organized way all inputs and all outputs of the components of a given system. Hence, it gives the constructional “dictionary” of the system, that is, the list of all objects that are constructionally – that is, concretely – manipulated by the system. Hence, this dictionary is of high value for ensuring a common constructional vision between all project actors involved in the architecting process: these actors shall normally – in an ideal world – only use the terms of that dictionary when discussing a constructional object. We may therefore easily understand that such a principle allows us to avoid any ambiguity between the different project actors. It is thus again completely key for ensuring a good collaboration between these actors.