{"id":25866,"date":"2021-07-15T12:07:37","date_gmt":"2021-07-15T10:07:37","guid":{"rendered":"https:\/\/cesam.community\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/"},"modified":"2022-11-15T11:59:33","modified_gmt":"2022-11-15T10:59:33","slug":"2-4-more-systems-architecture-dimensions-1-2","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/","title":{"rendered":"2.4 More Systems Architecture Dimensions (1\/2)"},"content":{"rendered":"<div class=\"wpb-content-wrapper\"><section class=\"vc_row wpb_row vc_row-fluid  vc_custom_1627389518372\"><div class=\"wpb_column vc_column_container vc_col-sm-10 vc_col-md-offset-1 col-xs-mobile-fullwidth\"><div class=\"vc_column-inner \"><div class=\"wpb_wrapper\"><div class=\"vc_row wpb_row vc_inner vc_row-fluid\"><div class=\"wpb_column vc_column_container vc_col-sm-9  col-xs-mobile-fullwidth\"><div class=\"vc_column-inner \"><div class=\"wpb_wrapper\"><h2 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-1\"  style=\"font-weight: 600; color: #000000;\">2.4 More Systems Architecture Dimensions<\/h2><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Architectural visions are however not the only architectural dimensions of a system. We shall now introduce a number of new dimensions that can be used to refine each architectural vision.<\/p>\n<\/div><h3 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-2\"  style=\"font-weight: 500; color: #01af50;\">2.4.1 Descriptions versus Expected Properties<\/h3><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">As already discussed in section 0.1, one must now recall that there exists two complementary ways of specifying a system. The first one refers to <em>descriptions<\/em>: in this specification mode, one explicitly<sup class=\"modern-footnotes-footnote \" data-mfn=\"1\" data-mfn-post-scope=\"00000000000019b60000000000000000_25866\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25866-1\">1<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25866-1\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"1\">This is why descriptions are considered as specifications in extension.<\/span> describes the behavior and structure, either of the system of interest (if one is reasoning functionally or constructionally) or of its environment (if one reasons operationally).<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25393&Prime; img_size=\u00a0\u00bb450&#215;270&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 29 \u2013 Descriptions versus expected properties <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">The second way deals with <em>expected properties<\/em>: one is now not explicitly describing a system, but rather stating the (operational, functional and constructional) properties, expected\/intended<sup class=\"modern-footnotes-footnote \" data-mfn=\"2\" data-mfn-post-scope=\"00000000000019b60000000000000000_25866\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25866-2\">2<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25866-2\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"2\">This is why expected properties are considered as specifications in intention.<\/span> to be satisfied by the system. Note these expected properties are usually called <em>requirements<\/em> in systems engineering (see section 0.1 for more details). This gives rise to the six different \u2013 but altogether exhaustive<sup class=\"modern-footnotes-footnote \" data-mfn=\"3\" data-mfn-post-scope=\"00000000000019b60000000000000000_25866\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25866-3\">3<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25866-3\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"3\">This key property is ensured by the mathematical foundations of the CESAM framework (see Chapter 0)<\/span> \u2013 specification modes that are presented in the below Figure 29, that is to say:<\/p>\n<ul>\n<li>For descriptions: operational descriptions, functional descriptions, constructional description,<\/li>\n<li>For expected properties: needs<sup class=\"modern-footnotes-footnote \" data-mfn=\"4\" data-mfn-post-scope=\"00000000000019b60000000000000000_25866\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25866-4\">4<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25866-4\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"4\">We will use here the term \u201cneed\u201d instead of \u201coperational requirement\u201d, even if they are equivalent. We indeed prefer to reserve the term \u201crequirement\u201d for functional &amp; constructional uses in order to separate strictly the domain of the question (expressed with needs) and the domain of the solution (stated with requirements). <\/span>, functional requirements, constructional requirements.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">As explained in section 0.1, one can equivalently (from a purely theoretical point of view) completely specify any system by using either descriptions, or expected properties. However these two modes of specification are absolutely not equivalent from an engineering effort perspective (see again section 0.1). On one hand, descriptions are indeed well adapted to define and tosynthetize the behavioral &amp; structural dimensions of a system. On the other hand, performances of a system are typical expected properties. But the converse is totally false. As a good practice, an efficient and optimal \u2013 in terms of engineering time spent \u2013 system specification shall mix descriptions (reserved for defining behavioral &amp; structural elements and their dynamics) and expected properties (reserved for performance). This trick allows drastically reducing the requirements volume in a specification file, thus improving its readability, since descriptions are usually encoded by a huge amount of requirements.<\/p>\n<\/div><h3 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-3\"  style=\"font-weight: 500; color: #01af50;\">2.4.2 Descriptions<\/h3><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Descriptions can be separated in four different views, each of them modeling a different dimension of a system. States are first modeling time. Static elements are then depicting the core objects of each architectural vision when dynamics are describing their temporal behavior. Flows are finally consolidating the exchanges involved in these dynamics. On should also note that all these system views are both exhaustive \u2013 they allow modeling completely a system \u2013 and non-redundant \u2013 each view provides a specific perspective which is not covered by the other views \u2013 due to the foundations of our system architecting framework (see section 0.1).<\/p>\n<\/div><h3 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-4\"  style=\"font-weight: 500;\">2.4.2.1 States<\/h3><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">A <em>state<\/em> T associated with a given system S is modeling a period of time, that is to say a set consisting of one or more intervals of time, where the system S can be analyzed in a homogeneous way from the perspective of a given architectural vision. A state can be usually specified by its initiation and termination events<sup class=\"modern-footnotes-footnote \" data-mfn=\"5\" data-mfn-post-scope=\"00000000000019b60000000000000000_25866\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25866-5\">5<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25866-5\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"5\"> T = \u222a [t1, t2] for all moments of time t1 and t2 such that an initiation (resp. termination) event occurs at t1 (resp. t2).<\/span>, which are both modeling phenomenon occurring instantaneously, i.e. at a specific moment \u2013 not interval \u2013 of time. As one may imagine, the initiation (resp. termination) events do correspond to moments of time \u2013 the same type of event can indeed occur at different moments of time \u2013 where the period of time modeled by T begins (resp. ends).<br \/>\nStates are used to model time. In each architectural vision, a key temporal analysis consists indeed in decomposing in different states the time line of a system from birth to death. In such analyses, one can then model the usual temporal behavior of a system as a succession of states in which lies the system, one after the other. Think for instance to a normal day of a human person which begins in the \u201cSleeping\u201d state, passing then to the \u201cMorning dress\u201d and \u201cBreakfast\u201d states, before arriving to the \u201cTransportation\u201d and \u201cWorking\u201d states, passing a new time in the \u201cTransportation\u201d state, then in the \u201cRelaxing\u201d, \u201cDining\u201d and \u201cTV listening\u201d states, before going back again to the \u201cSleeping\u201d state. We will discuss more precisely in Chapter 4 that kind of analysis for systems, based on states.<\/p>\n<p style=\"text-align: justify;\">There are therefore logically three different types of states for any given system S, depending on the considered architectural vision, which are defined as follows:<\/p>\n<ul>\n<li style=\"text-align: justify;\">Operational states are called operational contexts: an <em>operational context<\/em> for S is a period of time OC(S) characterized by the fact that external interactions of S during OC(S) do only involve a certain fixed set of stakeholders or external systems of its environment.<\/li>\n<li style=\"text-align: justify;\">Functional states are called <em>functional modes<\/em>: a functional mode for S is a period of time FM(S) which is characterized by the fact that the behavior of S during FM(S) can be modeled by only using a certain fixed set of system functions.<\/li>\n<li style=\"text-align: justify;\">Constructional states are called (technical)<em> configurations<\/em>: a configuration for S is a period of time TC(S) \u2013 usually identified with the involved components \u2013 characterized by the fact that the structure of S during TC(S) does only consist of a certain fixed set of system components.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">In other terms, one changes of operational context, functional mode or configuration if and only if a new stakeholder, function or component appears within the life of a given system. Passing from the \u201cRainy\u201d to the \u201cSunny\u201d operational context typically means that the Rain stakeholder disappeared and was replace by the Sun stakeholder. Replacing stakeholder by function or component would then lead to similar examples for the two other types of states that we introduced.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25396&Prime; img_size=\u00a0\u00bb400&#215;270&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Table 2 \u2013 Examples of states for an electronic toothbrush<\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Table 2 illustrates the notion of states with some examples for an electronic toothbrush, where we explicated the set of architectural (static) elements characterizing each state. One can see on these examples that there is no one-to-one correspondence between these different states. The toothbrush can indeed typically be in the \u201cBathroom\u201d operational context and in either an \u201cActive\u201d or a \u201cPassive\u201d functional mode (in that last case, it would mean that the toothbrush is broken, but that the user did not noticed it) and in either a \u201cChildren\u201d or an \u201cAdult\u201d configuration. In the same way, the toothbrush can be in the \u201cActive\u201d functional mode, but in either a \u201cBathroom\u201d or a \u201cReparation\u201d operational context (this last case corresponds to the situation where the toothbrush was repaired in the reparation workshop) and in lots of different configurations. The toothbrush may finally also be in a given configuration, but in various operational contexts or functional modes as one can easily check on the previous Table 2. These examples do thus show that each type of state may be allocated with many other types of states without any simple relationship in this matter.<br \/>\nLet us end by providing the standard representation of states \u2013 in most modeling languages \u2013 which are usually modeled by means of oval shapes, as one can see in the below Figure 30.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25398&Prime; img_size=\u00a0\u00bb400&#215;150&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 30 \u2013 Standard representations of states <\/span><\/strong><\/p>\n<\/div><h3 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-5\"  style=\"font-weight: 500;\">2.4.2.2 Static Elements<\/h3><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">A <em>static element<\/em> with respect to a given system S refers to an input\/output mechanism associated with S from the perspective of a certain architectural vision. We are using the term \u201cstatic element\u201d to emphasize that this new system description does not focus on the temporal dynamic (see next sub-section for that other point) of the involved input\/output mechanism, but provides just a nontemporized definition of such a mechanism without explicating its \u201calgorithm\u201d.<br \/>\nThere are therefore logically three different types of static elements for a given system S, depending on the considered architectural vision, which are defined as follows:<\/p>\n<ul style=\"text-align: justify;\">\n<li>Operational static elements are called <em>missions<\/em>: a mission of S is an input\/output behavior of the environment Env(S) of S, involving both S and other external systems.<\/li>\n<li>Functional static elements are called <em>functions<\/em>: a function of S is an abstract implementationindependent intrinsic input\/output behavior of S, that is to say that only involves S.<\/li>\n<li>Constructional static elements are called <em>components<\/em>: a component of S formally refers to a concrete implementation-dependent intrinsic input\/output behavior of S. A component of S is therefore naturally identified to a concrete part of S.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Missions shall never be mixed with functions or components, since they do not refer to the system of interest, but to its environment. Functions and components refer both to the system of interest, but in two different ways. Functions are indeed independent of any concrete implementation of the system of interest when components do always refer to its specific concrete implementation. There are thus two types of functions: on one hand, transverse functions that can only be implemented by using several components; on the other hand, unitary functions that can be implemented by using a single component (such functions are thus \u201csimply\u201d modeling the components behavior). Transverse functions are very important since they do model transverse system behaviors that, by definition, cannot be easily analyzed at constructional level. One may finally observe that the existence of such transversal (or equivalently emergent) behaviors is intrinsic to any system since it is directly the consequence of the emergence postulate (see Section 0.2).<br \/>\nNote also that the standard way for stating a mission or a function of a given system is to use the \u201cTo do something\u201d pattern in both cases. The only difference lies in the subject associated with the verb that describes the mission or function. This subject shall consist in external systems or stakeholders in the case of a mission (\u201cexternal systems cooperating with the system shall do something\u201d) when it shall only be the system alone for a function (\u201cthe system shall do something\u201d). On the other hand, components are usually stated using only names referring to concrete objects forming the system. Table 3 illustrates the notion of static elements with some examples for an electronic toothbrush. We provided some inputs and outputs for each proposed static elements.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25400&Prime; img_size=\u00a0\u00bb440&#215;273&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Table 3 \u2013 Examples of static elements for an electronic toothbrush <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">As already mentioned, static elements are related by <em>allocation relations<\/em>. Each function contributes for instance to one or more missions, which corresponds to the fact that a mission can be obtained by composing a function with some other input \/ output behavior (see the example given in note 84): such a situation is then expressed by saying that this mission is allocated to the considered function. In the same way, a component can contribute to a mission and\/or a function, which will be expressed by saying that such a mission or function is allocated to the considered component.<\/p>\n<p style=\"text-align: justify;\">We may also provide the standard representations of the three different types of static elements \u2013 in most modeling languages \u2013 which are usually modeled by circles for missions, ovals for functions and boxes for components, as one can see in the below Figure 31. We also expressed on this last figure the different allocation relationships that may exist between these different static elements.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25403&Prime; img_size=\u00a0\u00bb400&#215;142&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 31 \u2013 Standard representations of static elements <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Note finally that static elements can occur at different abstraction levels that do also correspond to different integration levels, resulting both in an abstraction and an integration hierarchy. Hence it is always crucial to be able to specify how different types of static elements are connected altogether by such relationships. The standard representations of these abstraction \/ integration relationships is provided by the below Figure 32, where we also put the associated allocation relations (beware that arrow ends, which express relationships, are squared when dealing with components).<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25405&Prime; img_size=\u00a0\u00bb400&#215;324&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 32 \u2013 Standard representations of integration relations between static elements<\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">For the sake of completeness, one also needs to explicitly represent the full<em> integration mechanism<\/em> that relates the different static elements of lower level that are abstracted by a static element of higher level (see Definition 0.5). Figure 33 below shows an example \u2013 in the line of Definition 0.5 \u2013 of standard representation of such an integration mechanism \u2013 where oriented arrows labelled with an exchanged flow represent interfaces<sup class=\"modern-footnotes-footnote \" data-mfn=\"6\" data-mfn-post-scope=\"00000000000019b60000000000000000_25866\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25866-6\">6<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25866-6\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"6\">We recall that an interface between two static elements E and F is formally nothing else that the couple (E, F). With such an interface, one may associate both flows exchanged between E and F and flows exchanged between F and E (we refer to the Flows subsection that follows for more detailed information on flows).<\/span> \u2013 between different constructional components of the same level of abstraction (here the head, body and embedded system that are forming the \u201cbrush\u201d part of an electronical toothbrush). Similar representations do also exist with functions or missions.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25407&Prime; img_size=\u00a0\u00bb420&#215;248&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 33 \u2013 Interfaces standard representation <\/span><\/strong><\/p>\n<\/div><a  href=\"https:\/\/cesam.community\/2021\/08\/02\/2-4-more-systems-architecture-dimensions-2-2\/\" target=\"_self\" class=\"btn pofo-button-1 bg-position-center-center  wow none button-style9  btn-link text-extra-dark-gray text-deep-pink-hover  btn-medium   vc_custom_1627908543882\" >Next page<i class=\"ti-arrow-right   margin-5px-left no-margin-right\" aria-hidden=\"true\"><\/i><\/a><\/div><\/div><\/div><div class=\"wpb_column vc_column_container vc_col-sm-3  col-xs-mobile-fullwidth\"><div class=\"vc_column-inner \"><div class=\"wpb_wrapper\"><h2 class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-6\"  style=\"font-size: 10px; font-weight: 600; color: #000000;\" data-fontsize=\"10px\">TABLE OF CONTENTS<\/h2>[vc_wp_custommenu nav_menu=\u00a0\u00bb132&Prime;]<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>\n<\/div>","protected":false},"excerpt":{"rendered":"2.4 More Systems Architecture DimensionsArchitectural visions are however not the only architectural dimensions of a system. We shall now introduce a number of new dimensions that can be used to refine each architectural vision. 2.4.1 Descriptions versus Expected PropertiesAs already discussed in section 0.1, one must now recall that there exists two complementary ways of specifying a system. The first one refers to descriptions: in this specification mode, one explicitly describes the behavior and structure, either of the system of interest (if one is reasoning functionally or constructionally) or of its environment (if one reasons operationally). [vc_single_image image=\"25393\" img_size=\"450x270\" alignment=\"center\"]Figure 29 \u2013 Descriptions versus expected properties The second way deals with expected properties: one is now not explicitly describing a system, but rather stating the (operational, functional and constructional) properties, expected\/intended to be satisfied by the system. Note these expected properties are usually called requirements in systems engineering (see section 0.1 for more details). This gives rise to the six different \u2013 but altogether exhaustive \u2013...","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[158],"tags":[157],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v24.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>2.4 More Systems Architecture Dimensions (1\/2) - Cesam Community<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"2.4 More Systems Architecture Dimensions (1\/2) - Cesam Community\" \/>\n<meta property=\"og:url\" content=\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\" \/>\n<meta property=\"og:site_name\" content=\"Cesam Community\" \/>\n<meta property=\"article:published_time\" content=\"2021-07-15T10:07:37+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-15T10:59:33+00:00\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@cesamcommunity\" \/>\n<meta name=\"twitter:site\" content=\"@cesamcommunity\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"admin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\"},\"author\":{\"name\":\"admin\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505\"},\"headline\":\"2.4 More Systems Architecture Dimensions (1\/2)\",\"datePublished\":\"2021-07-15T10:07:37+00:00\",\"dateModified\":\"2022-11-15T10:59:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\"},\"wordCount\":2619,\"publisher\":{\"@id\":\"https:\/\/cesam.community\/fr\/#organization\"},\"keywords\":[\"Article\"],\"articleSection\":[\"CESAM Systems Architecting Method\"],\"inLanguage\":\"fr-FR\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\",\"url\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\",\"name\":\"2.4 More Systems Architecture Dimensions (1\/2) - Cesam Community\",\"isPartOf\":{\"@id\":\"https:\/\/cesam.community\/fr\/#website\"},\"datePublished\":\"2021-07-15T10:07:37+00:00\",\"dateModified\":\"2022-11-15T10:59:33+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/cesam.community\/fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CESAM Systems Architecting Method\",\"item\":\"https:\/\/cesam.community\/fr\/category\/cesam-systems-architecting-method-en\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"2.4 More Systems Architecture Dimensions (1\/2)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/cesam.community\/fr\/#website\",\"url\":\"https:\/\/cesam.community\/fr\/\",\"name\":\"Cesam Community\",\"description\":\"La communaut\u00e9 CESAM\",\"publisher\":{\"@id\":\"https:\/\/cesam.community\/fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/cesam.community\/fr\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/cesam.community\/fr\/#organization\",\"name\":\"CESAM Community\",\"url\":\"https:\/\/cesam.community\/fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png\",\"contentUrl\":\"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png\",\"width\":7310,\"height\":1018,\"caption\":\"CESAM Community\"},\"image\":{\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/x.com\/cesamcommunity\",\"https:\/\/www.linkedin.com\/company\/community-cesam\/about\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505\",\"name\":\"admin\",\"sameAs\":[\"https:\/\/cesam.community\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"2.4 More Systems Architecture Dimensions (1\/2) - Cesam Community","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/","og_locale":"fr_FR","og_type":"article","og_title":"2.4 More Systems Architecture Dimensions (1\/2) - Cesam Community","og_url":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/","og_site_name":"Cesam Community","article_published_time":"2021-07-15T10:07:37+00:00","article_modified_time":"2022-11-15T10:59:33+00:00","author":"admin","twitter_card":"summary_large_image","twitter_creator":"@cesamcommunity","twitter_site":"@cesamcommunity","twitter_misc":{"\u00c9crit par":"admin","Dur\u00e9e de lecture estim\u00e9e":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/#article","isPartOf":{"@id":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/"},"author":{"name":"admin","@id":"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505"},"headline":"2.4 More Systems Architecture Dimensions (1\/2)","datePublished":"2021-07-15T10:07:37+00:00","dateModified":"2022-11-15T10:59:33+00:00","mainEntityOfPage":{"@id":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/"},"wordCount":2619,"publisher":{"@id":"https:\/\/cesam.community\/fr\/#organization"},"keywords":["Article"],"articleSection":["CESAM Systems Architecting Method"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/","url":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/","name":"2.4 More Systems Architecture Dimensions (1\/2) - Cesam Community","isPartOf":{"@id":"https:\/\/cesam.community\/fr\/#website"},"datePublished":"2021-07-15T10:07:37+00:00","dateModified":"2022-11-15T10:59:33+00:00","breadcrumb":{"@id":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/cesam.community\/fr\/2021\/07\/15\/2-4-more-systems-architecture-dimensions-1-2\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/cesam.community\/fr\/"},{"@type":"ListItem","position":2,"name":"CESAM Systems Architecting Method","item":"https:\/\/cesam.community\/fr\/category\/cesam-systems-architecting-method-en\/"},{"@type":"ListItem","position":3,"name":"2.4 More Systems Architecture Dimensions (1\/2)"}]},{"@type":"WebSite","@id":"https:\/\/cesam.community\/fr\/#website","url":"https:\/\/cesam.community\/fr\/","name":"Cesam Community","description":"La communaut\u00e9 CESAM","publisher":{"@id":"https:\/\/cesam.community\/fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/cesam.community\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/cesam.community\/fr\/#organization","name":"CESAM Community","url":"https:\/\/cesam.community\/fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/","url":"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png","contentUrl":"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png","width":7310,"height":1018,"caption":"CESAM Community"},"image":{"@id":"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/x.com\/cesamcommunity","https:\/\/www.linkedin.com\/company\/community-cesam\/about\/"]},{"@type":"Person","@id":"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505","name":"admin","sameAs":["https:\/\/cesam.community"]}]}},"_links":{"self":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25866"}],"collection":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/comments?post=25866"}],"version-history":[{"count":7,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25866\/revisions"}],"predecessor-version":[{"id":32448,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25866\/revisions\/32448"}],"wp:attachment":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/media?parent=25866"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/categories?post=25866"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/tags?post=25866"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}