{"id":25565,"date":"2021-04-03T16:10:52","date_gmt":"2021-04-03T14:10:52","guid":{"rendered":"https:\/\/cesam.community\/?p=25565"},"modified":"2023-01-20T11:46:23","modified_gmt":"2023-01-20T10:46:23","slug":"6-2-the-key-deliverables-of-constructional-architecture","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/04\/03\/6-2-the-key-deliverables-of-constructional-architecture\/","title":{"rendered":"6.2 The key Deliverables of Constructional Architecture"},"content":{"rendered":"

6.2 The key Deliverables of Constructional Architecture<\/h2>

For any system S, constructional architecture has five core types of deliverables:<\/p>\n

    \n
  1. the constructional requirement architecture<\/em> diagram that hierarchically organizes all constructional requirements \u2013 with respect to S \u2013 according to an refinement hierarchy,<\/li>\n
  2. the constructional mode diagram<\/em> that describes how S passes \u2013 with indication of the associated events \u2013 from a configuration to another one, starting from its birth up to its death,<\/li>\n
  3. the constructional decomposition & interaction diagrams<\/em> that are describing \u2013 in a purely static way \u2013 the components of S with their interactions1<\/a><\/sup> Usually only at global level, but also possibly in only a given configuration<\/span>,<\/li>\n
  4. the constructional scenario diagrams<\/em> that are describing \u2013 in a dynamic way \u2013 the interactions taking place between the components of S, in a given functional mode,<\/li>\n
  5. the constructional flow diagrams<\/em> that synthetizes all flows \u2013 with their logical relationships \u2013 absorbed or produced by the components of S during the \u201cconfiguration cycle\u201d2<\/a><\/sup>That is to say the period of time modeled by the configuration diagram.<\/span> of S.<\/li>\n<\/ol>\n

    These different types of deliverables are presented more in details below.<\/p>\n<\/div>

    6.2.1 Constructional Requirement Architecture Diagram<\/h3>

    Let S be a system. The constructional requirement architecture diagram<\/em> 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 one can logically deduce R1 from R23<\/a><\/sup>Remember that constructional requirements are logical predicates (see subsection 2.4.3)<\/span>. In this last situation, one says then more precisely that R2 refines into R1, which explains why one speaks of a constructional requirement refinement hierarchy.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25566″ img_size=\u00a0\u00bb500×278″ alignment=\u00a0\u00bbcenter\u00a0\u00bb]

    Figure 54 \u2013 Example of a constructional requirement architecture diagram for an electronical toothbrush\u00a0<\/span><\/strong><\/p>\n<\/div>

    The above Figure 54 shows a (quite partial) constructional requirement architecture diagram for an electronic toothbrush, a constructional requirement being \u2013 classically and similarly both to a need and to a functional requirement \u2013 represented here by a 2-part box, whose first top part is a short name summarizing the constructional requirement scope and second bottom part is dedicated to the constructional requirement statement, when the different refinement relationships on which relies the constructional requirement hierarchy are \u2013 also classically \u2013 represented by arrows.
    \nThe 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 one shall avoid to have too much constructional requirements of first level, but of course also too many levels of refinements, as soon as 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 \u201cgood\u201d constructional requirement architecture diagram associated with a given system shall have no more than 7 high level constructional requirements, each of them being refined in around 7 medium level constructional requirements, finally also refining in the same way into 7 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 one must probably not go further without analyzing whether this number is justified. Finally one 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.<\/p>\n<\/div>

    6.2.2 Configuration Diagram<\/h3>

    Let S be again a system. The configuration diagram<\/em> of S is then a representation of:<\/p>\n