4.2 The key Deliverables of Operational Architecture

4.2 The key Deliverables of Operational Architecture

For any system S, operational architecture has five core types of deliverables:

1. the need architecture diagram that hierarchically organizes all needs – with respect to S – according to an refinement hierarchy (see below),
2. the lifecycle diagram that describes how S passes – with indication of the associated events – from an operational context to another one, starting from its birth up to its death,
3. the use case diagrams that are describing – in a purely static way – the missions of S that are contributing to a given operational context,
4. the operational scenario diagrams that are describing – in a dynamic way – the interactions taking place between S and its stakeholders¹Or equivalently external systems. in a given operational context,
5. the operational flow diagrams that synthetizes all flows – with their logical relationships – exchanged between S and its reference environment during the lifecycle of S.

These different types of deliverables are presented more in details below.

4.2.1 Need Architecture Diagram

Let S be a system. The need architecture diagram of S is then a hierarchical exhaustive representation of all needs with respect to S, a need N1 being under another need N2 in this hierarchy if and only if one can logically deduce N1 from N2²Remember that needs are logical predicates (see subsection 2.4.3). In this last situation, one says then more precisely that N2 refines into N1, which explains why one speaks of a need refinement hierarchy. Figure 42 below now shows a (partial) need architecture diagram for an electronic toothbrush, a need being – classically – represented here by a 2-part box, whose first top part is a short name summarizing the need scope and second bottom part is the need statement, when the refinement relationships on which the need hierarchy relies are – also classically – represented by arrows.

The same issue that was already pointed out in the first part of subsection 3.2 when dealing with the stakeholder hierarchy diagram can also be expressed – more or less in the same terms – with the need architecture diagram: organizing a need refinement hierarchy is indeed always difficult since one shall avoid to have too much needs of first level, but also too many levels of refinements if one wants to be able to efficiently use such a view. The 7x7x7 rule (see first part of subsection 3.2) is again precious to handle this real difficulty. As a consequence, a typical “good” need architecture diagram associated with a given system shall have no more than 7 high level needs, each of them refined in around 7 medium level needs, finally also refining in the same way into 7 low level needs. Note again that the number 7 shall of course be just taken as an order of magnitude. Obtaining up to 10-12 high level needs in a need architecture diagram could of course work: however one must probably not go further without analyzing whether this number is justified. Finally one shall not hesitate to construct additional need architecture diagrams for refining such an analysis as soon as all relevant needs are not captured.

4.2.2 Lifecycle Diagram

Let S be again a system. The lifecycle diagram of S is then a representation of:

• the operational contexts of S, with their relative temporal relationships (consecutiveness, inclusion or simultaneity)³These three temporal relations are necessary and sufficient to model any temporal relationships between operational contexts among a system lifecycle. To be convinced of that claim, let us analyze the (only embarrassing) situation of two intervals of time P and Q that overlap, i.e. such that P = [s, t] and Q = [u, v] with u < v. One can model such a situation with our temporal relations by first decomposing P into P1 = [s, u] and P2 = [u, t] and Q into Q1 = [u, t] and Q2 = [t, v] and observing then that P2 is consecutive to P1, Q1 is simultaneous to P2 and Q2 is consecutive to Q1.,
• the events that cause the different transitions between each operational context of S and the immediately consecutive ones.

To draw such a diagram, we shall give the standard representations of the three temporal relations between operational contexts that we introduced above, which are provided by Table 10, where C and D stand for generic operational contexts. Remember here that operational contexts are modeled by ovals, as introduced in the first paragraph of subsection 2.4.2.

Figure 43 below provides an illustrative lifecycle diagram associated with an electronical toothbrush, taking here the standard representation of operational contexts and of their temporal relationships that we already introduced, when events – that induce operational context transitions – are modeled by arrows labelled with the name of the relevant event. Note also that the initial (resp. termination) events in each operational context do not respect this rule since they are conventionally modeled by small black circles (resp. by white circles containing a black circle).

Note finally that there is a perfect symmetry between the environment diagram, dedicated to model the space in which evolves a system, and the lifecycle diagram, dedicated to model the periods of time through which passes a system. Since space and time are always both required to specify any system behavior (that necessarily takes place somewhere at a certain time), one can easily see that these two diagrams are equally important to specify any system.

4.2.3 Use Case Diagrams

Let S be a system, let Env(S) be its reference environment and let q(S) be an operational context of S. A use case diagram associated with S and q(S) is then a static representation of the missions achieved through the collaboration of S and its external systems within Env(S), during the period of time which is modeled by q(S), which explicitly specifies:

1. the external systems of the environment of S that are contributing to each mission,
2. the missions that contribute to another mission.

Note that it is something necessary, when modelling a use case diagram, to also represent behaviors of Env(S) in which the system S is not contributing at all. This is done by just indicating that S is not contributing to such a function of Env(S).

Figure 44 that follows provides an example of use case diagram, associated with the “Brushing data transmission” operational context of an electrical toothbrush. The square represents the system of interest when we used again the “person” representation to model its stakeholders. A mission is (resp. not) placed in the square when the system of interest contributes (resp. does not contribute) to it. In the same way, one puts a line between a stakeholder and a mission when the stakeholder contributes to such a mission⁴Let UC(S) be a use case diagram associated with a given system S. A mission which is put in the square part of UC(S) and which is connected through lines to stakeholders S₁, … , S_n within UC(S) is then formally a function of the system resulting from the integration of S with S₁ up to S_n.. One also indicates by a rigid arrow when a mission contributes to another mission and by a dashed arrow when a given mission M₁ is mandatory to manage another one M2. Beware at that last level since the standard convention in this matter is highly counterintuitive: one indeed models such a situation by putting a dashed arrow from M₂ to M₁ and not the converse. Note finally that it is interesting to observe on that example that the motivation of the “brushing data transmission” cannot be found in a mission of the electronic toothbrush, but rather in the “Follow brushing recommendations” which is an environment function involving only end-users and dentists without the electronic toothbrush. One can then easily understand the value of a use case diagram on such a situation which would clearly not be possible to describe without a specific environment-oriented diagram such as a use case diagram.

It is interesting to point out that if one considers the special – limit – case of the operational context equal to the complete lifecycle of a given system S, the associated use case diagram would especially provide a hierarchical representation of all missions of S, jointly with the indication of the different stakeholders that are contributing to each mission of the system. For the sake of readability, one can of course decompose that last use case diagram into the two following use case diagrams:

1. the first one providing just a hierarchical representation of all missions of S, which shall be naturally called the Mission Breakdown Structure (MBS) of S⁵If one decides to model such a Mission Breakdown Structure (MBS), one must beware to the readability of such a view. All the recommendations based on the 7x7x7 rule that we previously gave for the stakeholder and the need architecture diagrams will then of course also apply – mutatis mutandis – in order to efficiently model the MBS.,
2. the second one providing the indication of the stakeholders that contribute to each mission of the system, whose semantics is equivalent to a mission / stakeholder allocation matrix.

Note finally that if no hierarchically related missions occur when modelling a given use case diagram, the semantics of such a diagram is completely contained within the associated operational scenario diagram (see next paragraph). One shall then decide the diagram to take since the use case diagram has no need with the associated operational scenario diagram (the converse being not true).

4.2.4 Operational Scenario Diagrams

Let again S be a system, Env(S) be its reference environment and q(S) be an operational context of S. An operational scenario diagram associated with S and q(S) is then a dynamic representation of the missions achieved through the collaboration of S and its external systems within Env(S), during the period of time which is modeled by q(S), which explicitly specifies all interactions occurring between S and the stakeholders – or equivalently the external systems – of its reference environment. The following Figure 45 shows an example of operational scenario diagram, associated with the “Reparation” operational context of an electrical toothbrush. We refer to the suitable paragraph of subsection 2.4.2 for all details on the semantics of the below representation.

An operational scenario diagram provides therefore an explicit algorithmic description which models the behavior of the environment of a given system during a given operational context. As already stated in the last paragraph, one must always choose whether using either a use case diagram, or an operational scenario diagram to specify an operational context, when no hierarchically related missions occur within the use case diagram, since this last diagram will not add any semantics to the corresponding operational scenario diagram.

4.2.5 Operational Flow Diagram

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

1. their logical relationships,
2. their abstraction relationships⁶We recall that a flow A is abstracted by a flow B if and only if A is a special instance of B. In relativist mechanics, Matter is for instance abstracted by Energy. .

It plays therefore the role of the operational “data model”⁷Beware that, even if we use the syntax of a data model for the operational flow diagram, this last diagram is not really a data model since it does not represent (only) data, but also physical objects, business objects or even informal information that may be exchanged by “humanware” stakeholders of a given system. of the system. Note that one also may split this diagram into two diagrams, each of them covering the two above points.
Figure 46 below shows an example of (partial) operational flow diagram, associated with an electrical toothbrush. The different logical relationships, which exist between the various operational flows (or objects) represented in that diagram, are modeled by rigid lines (without any arrow) labelled with the denomination of the corresponding relationship. Note that one usually uses a verb – in the third form of singular – to name such a logical relation: in an operational flow diagram, the line connecting a flow of type A with a flow of type B that represents a logical relation between A and B is typically labeled by a verb such as “is related to” in order to express that “A is related to B” or that “B is related to A”. To avoid ambiguity, one places the relationship denomination closer to the first term of such a logical relationship⁸Strictly speaking one should put two labels on each line between any flow A and any flow B in order to express both the logical relations between A & B and between B & A. However this would be too heavy which explains our convention. .

One may also put on the extremity of these lines an indication of the arity of these relationships: if n operational flows of type A can be associated with m operational flows of type B within a given logical relation, one just puts a label with “n” (resp. “m”) at the A-extremity (resp. B-extremity) of the line put between A and B that models the corresponding relation (we recall that (n,m) is called the arity of such a logical relationship). Note also that, by convention, one puts “*” instead of a natural number when there are not known limits to the number of involved elements. Finally, on another totally different hand, the abstraction relationships that are provided in the above diagram are modeled – according to a classical convention – by squared arrows.

As already stated the operational flow diagram defines the operational flow or object model of a given system. It is completely “dual” to the environment, use case or operational scenario diagrams since it focuses on flows, and not on the different functions, either of the system or of its reference environment, that are producing these flows. Unfortunately most of engineers, who usually do not have any computer science or software engineering background, do not understand the importance and the value of this new type of flow-oriented diagram … 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 a given system. Hence it gives the operational “dictionary” of the system, that is to say the list of all objects that are operationally manipulated by the system. This dictionary is of high value for ensuring a common vision between all project actors involved in the operational architecting process: these actors shall normally – in an ideal world – only use the terms of that dictionary when discussing of an operational object. One may easily understand that such a principle allows to avoid any ambiguity between the system designers and the project system stakeholders, but also within the different specialty engineers. It is thus key for ensuring a good collaboration between all these actors.

TABLE OF CONTENTS