{"id":25768,"date":"2021-08-05T10:12:46","date_gmt":"2021-08-05T08:12:46","guid":{"rendered":"https:\/\/cesam.community\/2021\/08\/05\/0-1-cesam-a-mathematically-sound-system-modeling-framework\/"},"modified":"2022-11-14T14:40:20","modified_gmt":"2022-11-14T13:40:20","slug":"0-1-cesam-a-mathematically-sound-system-modeling-framework","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/08\/05\/0-1-cesam-a-mathematically-sound-system-modeling-framework\/","title":{"rendered":"0.1 CESAM: a Mathematically Sound System Modeling Framework"},"content":{"rendered":"

0.1 CESAM: a Mathematically Sound System Modeling Framework<\/h2>

CESAMES Systems Architecting Method (CESAM) is the result of 12 years of research & development (cf. [1], [3], [4], [16], [17], [18], [22], [27], [48], [49], [51], [52], [53]) including permanent interactions and operational experimentations with industry. The CESAM framework was indeed used in practice within several leading international industries in many independent areas with a success that has never wavered (see [14], [23], [26], [31], [32], [33], [35] or [36]) for some application examples). This huge theoretical and experimental effort resulted in a both mathematically sound & practical system modeling framework, easy to use by working systems engineers and architects<\/em>.
\nWe shall only present in this general introduction the more important fundamentals1<\/a><\/sup>CESAM framework is based on formal semantics, the mathematical theory \u2013 based on mathematical logics (cf. [12]) \u2013 which provides the fundamentals of computer science (see [89]) CESAM framework may be understood as an extension of usual formal semantics \u2013 which only addresses software systems \u2013 to more general types of systems.<\/span> of the CESAM framework that may help to better understand its philosophy. At this level, the key point is the logical consistency of the CESAM framework, naturally provided by its mathematical basis. Due to this strong consistency, anybody who agrees with logical reasoning2<\/a><\/sup>Logical reasoning is usually mixed with common sense. However one shall not forget that logics is a body of mathematical knowledge (see [12]), sadly largely unknown to engineers, that can be traced back to Aristoteles (see [84]). <\/span> (which shall normally be the case with all engineers) will indeed be able to use and work with CESAM framework.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25176″ img_size=\u00a0\u00bb600×282″ alignment=\u00a0\u00bbcenter\u00a0\u00bb css=\u00a0\u00bb.vc_custom_1627457477977{padding-top: 5px !important;}\u00a0\u00bb]

Figure 1 \u2013 The two abstracting\/ experimenting sides of a system modeling process <\/span><\/strong><\/p>\n<\/div>

Note now first that systems are considered in a modelling perspective within CESAM framework. This point of view immediately leads to distinguish the two core concepts of \u201cformal system\u201d and \u201creal system\u201d. It is indeed quite important to avoid making any confusion3<\/a><\/sup>Unfortunately this confusion is quite common in systems engineering where such a distinction is usually not made both in practice and in most textbooks, handbooks and standards (such as [15], [42], [44], [47], [57], [61], [62], [71], [74] or [78]). Aslaksen appears in particular to be one of the rare systems engineering authors who proposed a formal definition for a system (see [9] or [10]). Sound systems modelling formalisms thus seem to be only found in the mathematical simulation literature (cf. [23], [73] or [100]) or in the few theoretical computer science system literature (cf. [21], [55] or [59]). <\/span> between the result of a system modelling process (the formal system) and the concrete object under modelling (the real system). Many design mistakes \u2013 with often high costs of non-quality \u2013 are indeed made by engineers when they forget that their system specification documentation is just an abstraction of reality, but not the \u201creal\u201d reality, and that their job is to ensure permanent alignment \u2013 through feedback loops with reality \u2013 between their system models and the real system, as it is and not as they think it is.<\/p>\n

A system modeling process can thus be seen as a permanent back-and-forth between, on a first side, an abstraction activity that constructs a formal model of a real world object \u2013 using the tools of systemic analysis \u2013 and on a second side, an experimentation activity where the structure or behavior of the real object, as given or predicted by the model, are checked against those really observed in reality. The real object under modelling will thus be considered as a (real) system due to the fact that a system modeling process analyzes it as a (formal) system within a systemic modelling framework. By abuse of language, we often identify these two concepts of \u00ab\u00a0system\u00a0\u00bb, but it is important never to forget that \u00ab\u00a0the map is not the territory\u00a0\u00bb ([46]) in order to know at any time on what we reason! Note also that this approach points out that being a system is absolutely not an intrinsic property of an object4<\/a><\/sup>This last consideration shows that it is merely impossible to give a sound definition of a real system since any object in the real world can be considered as a system as soon as a system designer decides it. <\/span> , but results from a modelling decision of a system designer. This being recalled, we can now provide the definition of a formal system5<\/a><\/sup>The CESAM definition of a system provided by Definition 0.1 unifies two classical system modelling traditions: it indeed mixes the usual functional definition coming from the mathematical system simulation literature (cf. [23], [73] or [100]) and the state-machine system definition that emerged in theoretical computer science (cf. [21], [55] or [59]). <\/span> on which relies the CESAM modelling framework.<\/p>\n

Definition 0.1 \u2013 Formal system<\/span>\u2013 A formal system<\/em> S is characterized on one hand by a input set X, an output set Y and an internal variables set Q and on the other hand by the following two kinds of behaviors that link these systemic variables among a given time scale T6<\/a><\/sup>A time scale T is a totally ordered set with a unique minimal element \u2013 usually denoted t0<\/sub> \u2013 and where each element t \u2208 T has a (unique) greatest upper bound within the time scale, called its successor and denoted t+ within T. Up to rescaling, two types of time scales are key in practice: discrete time scales where t+ = t + 1 and continuous time scales where t+ = t + dt where dt stands for an infinitesimal quantity. Discrete time scales model event-oriented systems (such as software systems which are regulated by a discrete clock) when continuous time scales are used to model physical continuous phenomena. <\/span> :<\/p>\n