5.2 The key Deliverables of Functional Architecture

5.2 The key Deliverables of Functional Architecture

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

1. the functional requirement architecture diagram that hierarchically organizes all functional requirements – with respect to S – according to an refinement hierarchy,
2. the functional mode diagram that describes how S passes – with indication of the associated events – from a functional mode to another one, starting from its birth up to its death,
3. the functional decomposition & interaction diagrams that are describing – in a purely static way – the functions of S with their interactions¹ Usually only at global level, but also possibly in only a given functional mode. ,
4. the functional scenario diagrams that are describing – in a dynamic way – the interactions taking place between the functions of S, in a given functional mode,
5. the functional flow diagrams that synthetizes all flows – with their logical relationships – absorbed or produced by the functions of S during the “functional mode cycle”²That is to say the period of time modeled by the functional mode diagram. of S.

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

5.2.1 Functional Requirement Architecture Diagram

Let S be a system. The functional requirement architecture diagram of S is then a hierarchical exhaustive representation of all functional requirements of S, a functional requirement R1 being under another functional requirement R2 in this hierarchy if and only if one can logically deduce R1 from R2³Remember that functional requirements are logical predicates (see subsection 2.4.3).. In this last situation, one says then more precisely that R2 refines into R1, which explains why one speaks of a functional requirement refinement hierarchy.

Figure 47 illustrates here a (partial) functional requirement architecture diagram for an electronic toothbrush, a functional requirement being – classically and exactly similarly to a need – represented here by a 2-part box, whose first top part is a short name summarizing the functional requirement scope and second bottom part is the functional requirement statement, the refinement relations, on which relies the functional requirement hierarchy, being – also classically – represented by arrows.

Note that exactly the same issue already pointed out for the need requirement architecture diagram takes also place with the functional requirement architecture diagram: organizing a functional requirement refinement hierarchy is indeed always difficult since one shall avoid to have too much functional requirements of first level, but of course 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 a precious tool to handle this real difficulty. As a consequence, a typical “good” functional requirement architecture diagram associated with a given system shall have no more than 7 high level functional requirements, each of them refined in around 7 medium level functional requirements, finally also refining in the same way into 7 low level functional requirements. Note again that the number 7 shall just be taken as an order of magnitude. Obtaining up to 10-12 high level functional requirements in a functional requirement 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 as many additional functional requirement architecture diagrams as necessary, for refining such an analysis as soon as all relevant functional requirements are not derived and/or captured.

5.2.2 Functional Mode Diagram

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

• the functional modes of S, with their relative temporal relationships (consecutiveness, inclusion or simultaneity)⁴We refer to the second paragraph of subsection 4.2 in this matter,
• the events that cause the different transitions between each functional mode of S and the immediately consecutive ones.

The standard representations of the temporal relations between functional modes introduced above are given – mutatis mutandis – by Table 10, if one now interprets C and D as functional modes.

The above Figure 48 provides in particular an illustrative functional mode diagram associated with an electronical toothbrush, taking here the standard representation of functional modes and of their temporal relationships that we introduced, when events – that induce functional mode transitions – are modeled by arrows labelled with the name of the relevant event. Note also that the initial (resp. termination) events in each functional mode do not respect this rule since they are conventionally modeled by small black circles (resp. by white circles containing a black circle).
It is finally important to understand that the functional mode diagram is key since it models – from a functional perspective – time. Following the intuition that we developed at the end of the second paragraph of section 4.2, one could say that the next diagrams – i.e. the functional decomposition & interaction diagrams – are modeling the “functional space” in which functions are evolving. Since space and time are always required to specify any functional behavior (that takes place “functionally somewhere” at a certain time), these two diagrams are completely complementary.

5.2.3 Functional Decomposition & Interaction Diagrams

Let S be a system. The functional decomposition diagram associated with S is then a hierarchical representation of the functions of S, a set F1, F2, …, FN of functions being under another function G in this hierarchy if G is the result of the integration – in the meaning of Definition 0.5⁵Considered here uniquely for its functional scope – of the functions F1, …, FN⁶ Due to our definition of the integration operator, this hierarchy is therefore an abstraction hierarchy (F1, …., FN are then classically called “sub-functions” of G). The functional interaction diagrams associated with S are then just the different representations – there is one functional interaction diagram per integration relationship involved in the functional decomposition diagram – of each such integration relationship that does exist between the different functions appearing in the hierarchy modeled by the functional decomposition diagram.

Figure 49 below now provides an illustrative partial example of functional decomposition diagram for an electronic toothbrush, where the integration relationships on which this hierarchy relies are – quite classically – represented by squared arrows.

We also give an example of a functional interaction diagram for an electronical toothbrush that can be found in Figure 50. In this example, we modeled the integration relationship existing between the global function of the toothbrush and its first “sub-functions” (using the formalism of a classical “activity diagram” in the UML or SysML meaning; see [20] or [34]). Note also that external interfaces are here – quite classically – represented by white squares at the border of the oval representing the integrated function (here the global function of an electronical toothbrush).

The functional decomposition of a system S modeled by the functional decomposition diagram is also classically called the Functional Breakdown Structure (FBS) of S. Similarly to the Mission Breakdown Structures that we introduced in the last chapter, it provides the exhaustive dictionary of functions of the system and thus has a key role in guaranteeing a common understanding on the functional scope of a system, which is mandatory for efficient transversal collaboration between the different actors and stakeholders of a system development project.

One must however beware to the readability of such a view. All the recommendations based on the 7x7x7 rule that we previously gave for the stakeholder and need architecture diagrams of course also apply – mutatis mutandis – to efficiently model the Functional Breakdown Structure of a system. Last, but not less important, we refer to Figure 9 in Chapter 0 for a concrete functional interaction diagram associated with an aircraft: it represents how all first-level sub-functions may be integrated to obtain the high-level global function of an aircraft.

5.2.4 Functional Scenario Diagrams

Let again S be a system and q(S) a functional mode of S. A functional scenario diagram associated with S and q(S) is then a dynamic representation of the interactions that are taking place between the functions of S during the period of time which is modeled by q(S).
The below Figure 51 shows an example of functional scenario diagram, associated with the “Active” functional mode of an electrical toothbrush. We refer to the suitable paragraph of subsection 2.4.2 for the fundamentals of the semantics of this representation. However we were obliged to introduce richer semantics with respect to the one that was introduced in subsection 2.4.2. The below diagram indeed expresses that as far as the electronic toothbrush is in active mode (which was modeled by the big box with “loop” on its top left and the “[active mode]” indication⁷This indication means “as soon as”. Hence we meant here “as soon as the system is in active mode”. in its top middle), it shall do in parallel (which was modeled by the big box with “par” on its top left), that is to say at the same time, three types of operations (that are separated by dashed lines in the “alt” big box): the first one being brushing force management, the second one being brushing data management and the third one being energy management. For the sake of completeness, one shall also know that there exists an “alt” (for alternatives) box which allows to express “if then else” situations⁸The “if then else” situation is expressed by a big box labelled “alt” on its top right, split in two parts – Part 1 (top) and Part 2 (bottom) – separated by a dashed line, with a “condition” denomination at its top middle. Its semantics is that when the “condition” is satisfied (resp. not satisfied), the system shall do the instructions of Part1 (resp. Part2). .

A functional scenario diagram provides the explicit “algorithm” which is underlying to the functional behavior of the system in a given functional mode. This is key to understand finely what – at least functionally – happens during a given functional mode. The enriched semantics that we introduced indeed allows to express any distributed algorithmic property of a system⁹This comes from the fact that usual algorithmic only requires the “while” (modeled by the “loop” box) and the “if then else” (modeled by the “alt” box) operators. When one passes to distributed – that is to say parallel – algorithmic, it is then sufficient to add the “parallel” operator (modeled by the “par” box)..

5.2.5 Functional Flow Diagram

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

1. their logical relationships,
2. their abstraction relationships (see the last paragraph of Chapter 4).

Hence it plays the role of the functional “data model”¹⁰Beware that, even if we use the syntax of a data model for the functional 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 with “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 52 below shows an example of (partial) functional flow diagram, associated with an electrical toothbrush. Its syntax follows exactly the same principles than for the operational flow diagram (see the last paragraph of the previous chapter).

As already stated the functional flow diagram defines the functional flow or object model of a given system. It is completely “dual” to the functional decomposition, interaction or scenario diagrams since it focuses on flows and not on the functions of the system that are producing these flows.
We must thus again 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 functions of a given system. Hence it gives the functional “dictionary” of the system, that is to say the list of all objects that are functionally manipulated by the system. This dictionary is of high value for ensuring a common 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 of a functional object. One may easily understand that such a principle allows to avoid any ambiguity between the different project actors. It is thus key for ensuring a good collaboration between these actors.

TABLE OF CONTENTS

REFERENCES

[20] Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language Reference Manual, Second Edition, Addison-Wesley, 2004 

[34] Friedenthal S., Moore A.C., Steiner R., A Practical Guide to SysML : the Systems Modeling Language, Morgan Kaufmann OMG Press, 2012