now browsing by author


Mechanism of Operation vs System Model vs Diagram

Mechanism of Operation vs System Model vs Diagram


Jaroslaw Zel­in­ski


2024-03-12 01:48:01


Busi­ness ana­lys­is and soft­ware design 


Dur­ing ana­lys­is, we often use the term «mod­el» and less fre­quently the term «mech­an­ism». The term “mech­an­ism” when we want to explain some­thing, such as “the mech­an­ism for gen­er­at­ing a dis­count on an invoice.” ” 

But here beware: the mod­el (block dia­grams, for­mu­lae, etc.) is doc­u­ment­a­tion and a copy­righted descrip­tion. The mech­an­ism is what we under­stand by read­ing this doc­u­ment­a­tion (mod­el), as the mech­an­ism is pro­tec­ted know-how. The con­tent of the applic­a­tion to the Pat­ent Office is the mod­el (descrip­tion), but what we pat­ent is the invented/developed mechanism. 

Keywords: mod­el, mech­an­ism, dia­gram, UML

Mechanism vs. model

Mech­an­ism and mod­el in sci­ence are close con­cepts. For example, they are described as:

Mod­el­ing involves abstract­ing from the details and cre­at­ing an ideal­iz­a­tion to focus on the essence of a thing. A good mod­el describes only the mech­an­ism. [Glen­nan argued that mech­an­isms are the secret con­nec­tion that Hume sought between cause and effect: “A mech­an­ism of beha­vi­or is a com­plex sys­tem that pro­duces that beha­vi­or through the inter­ac­tion of many parts, where the inter­ac­tion between the parts can be char­ac­ter­ized by dir­ect, invari­ant gen­er­al­iz­a­tions relat­ing to change” (Craver & Tabery, 2019)

Let’s exam­ine how these terms are defined by the offi­cial Dic­tion­ary of the Pol­ish Language:

Mech­an­ism: “the way some­thing is formed, runs, or oper­ates.“
Mod­el: “a con­struc­tion, scheme, or descrip­tion show­ing the oper­a­tion, struc­ture, fea­tures, rela­tion­ships of some phe­nomen­on or object.” ”

Dic­tion­ary of the Pol­ish Lan­guage (

As you can see, very sim­il­ar but not identic­al. The term “dia­gram” is defined in Eng­lish lit­er­at­ure as:

Dia­gram: a simple plan show­ing a machine, sys­tem, or idea, etc., often drawn to explain how it works.


In the sci­entif­ic (Eng­lish-lan­guage) lit­er­at­ure, the concept of mod­el­ing is defined as fol­lows: to 

mod­el some­thing is to cre­ate a copy or descrip­tion of an action, situ­ation, etc., so that it can be ana­lyzed before pro­ceed­ing with the real action.

Graph­ic­ally, this con­cep­tu­al mod­el can be illus­trated as a diagram:


Con­cepts: dia­gram, mod­el, and mech­an­ism, and the areas of law gov­ern­ing them. (Author’s own)

There remains the ques­tion of con­cepts: the phe­nomen­on (which we want to describe and explain) and its explan­a­tion. A giv­en phe­nomen­on is a cer­tain observed fact. Most often, we describe it lit­er­ally or cre­ate stat­ist­ics about it. Craver illus­trates the rela­tion­ship between the phe­nomen­on and the mech­an­ism of its form­a­tion in this way: 

Modelowanie to tworzenie opisu mechanizmu wyjaśniającego obserwowane fakty. Fakty to wiedza pozyskana od ekspertów dziedzinowych, to np. dane pomiarowe (źródłowe) i ich statystyka, dają one wyłącznie informacje o występowaniu określonych zjawisk, statystyki jako takie nie stanowią sobą żadnego modelu ani wyjaśnienia obserwowanego zjawiska. Statystyka może wskazać prawidłowości w obserwowalnych faktach związanych z badanym zjawiskiem (Phenomenon) ale statystyka nie wyjaśnia mechanizmu ich powstania (Mechanism). Zwraca na t uwagę Cravier na diagramie Wizualna reprezentacja mechanizmu (Craver & Tabery, 2019). Teoria wyjaśniająca to idealizacja, opis mechanizmu powstawiania obserwowanych faktów (Weisberg, 2007). Metanalizy nie podważają w żadnym stopniu wyników wykonanych badań, są one - ich wyniki - z zasady traktowane jako fakty. Metaanaliza ma za cel jedynie zbudować nadrzędny model wyjaśniający, którego celem jest wyłącznie opisanie (a czasami odkrycie) mechanizmu danego zjawiska. Podstawą tworzenia modelu dedukcyjnego jest idealizacja rozumiana jako model zbudowany z kluczowych dla badanego zjawiska faktów i elementów (Matthews, 2004).

The upper ellipse rep­res­ents our obser­va­tions of stim­uli and effects, and the ellipse is a record of the facts and their stat­ist­ics. Stat­ist­ics, how­ever, is not a mod­el, it is only a stat­ist­ic, a col­lec­tion of data about the facts, it does not provide any explan­a­tion for their formation. 

The lower ellipse rep­res­ents the mech­an­ism that explains the form­a­tion, ini­ti­ated by stim­uli, of the observed effect (facts col­lec­ted in stat­ist­ics). It is an explan­a­tion of how the effect (facts, effect) arises and is the mech­an­ism for the emer­gence of what we observe. We illus­trate (can be expressed as) this mech­an­ism (explan­a­tion) as a mod­el, which can be expressed, for example, by a flowchart.



An example that every­one is prob­ably famil­i­ar with is Coper­ni­cus» The­ory. The dia­gram shows: top left, a record of obser­va­tions of the heav­ens, wrongly called a (stat­ist­ic­al) mod­el. These are the so-called epi­cycles (below left): a depic­tion of obser­va­tions of the paths of plan­ets and stars in the sky, observed from Earth. On the right, the helio­centric sol­ar sys­tem dia­gram is a mod­el that explains the mech­an­ism of epi­cycles or loops that the observed stars and plan­ets make in the sky. 


Watt Regulator

Anoth­er example is the Watt reg­u­lat­or. Below is a mod­el of this regulator:

The ori­gin­al schem­at­ic is Wat­t’s reg­u­lat­or, describ­ing its design.

The descrip­tion of the mech­an­ism in the pat­ent applic­a­tion was text sim­il­ar to this:

If the machine is at rest, then the weights (balls) are at the very bot­tom, and the throttle is fully open. If the steam machine starts work­ing, the rotat­ing wheel of the steam machine is con­nec­ted to the speed reg­u­lat­or, the balls begin to rotate. Two forces act on the balls of the reg­u­lat­or: the grav­it­a­tion­al force attract­ing the balls ver­tic­ally down­ward and the cent­ri­fu­gal force pulling the balls out­ward, which, with this design of the reg­u­lat­or, causes the balls to float upward. The rising balls cause the throttle to close, and this res­ul­ted in less steam being sup­plied to the steam engine. The machine slows down, so the cent­ri­fu­gal force decreases, the balls fall down,soandthe throttle opens, thus sup­ply­ing more steam to the machine.

Dia­gram describ­ing this regulator:

Dia­gram describ­ing the mech­an­ism of the Watt Regulator.

The mech­an­ism that explains the oper­a­tion of this reg­u­lat­or is a neg­at­ive feed­back sys­tem (Ber­talan­ffy, 2003):

Neg­at­ive feed­back as a mech­an­ism to explain the oper­a­tion of the Watt regulator.

Wat­t’s reg­u­lat­or is pre­cisely the neg­at­ive feed­back. In the dia­gram above, PROCESS is a steam machine. The quant­ity at the input is steam with a cer­tain pres­sure, and the quant­ity at the out­put is the speed of the drive shaft of the steam machine. An increase in the speed of the shaft causes a decrease in the pres­sure of the steam sup­ply­ing the steam machine, which in turn causes a decrease in the speed of the shaft, thus open­ing the steam valve at the input and increas­ing the speed again. The phe­nomen­on will lead to a fixed (sta­bil­ized) shaft speed with small fluctuations. 


A typ­ic­al ana­log clock (its face) hanging on many walls in a house (or moun­ted on many towers) looks like the one below:

Clock face

Pos­sible con­struc­tion of such a clock on the tower: 

Example of a design repro­du­cing a clock mechanism

The time meas­ure­ment mech­an­ism we use to explain the indic­a­tion on the clock face, which is the basis for the con­struc­tion of clocks, is expressed as a mod­el in UML notation.

A mod­el express­ing the tim­ing mechanism

Conceptual model.

We mod­el domain know­ledge as a Concept Dic­tion­ary, and this can be expressed graph­ic­ally in the form of tax­onom­ies and syn­tact­ic rela­tion­ships. The applic­a­tion code archi­tec­ture expressed graph­ic­ally is its mod­el, adding to few­er dia­grams describ­ing♥ for example, use case scen­ari­os, is also part of this mod­el. The whole, how­ever, describes the mech­an­ism for imple­ment­ing func­tion­al requirements. 

Below left con­cep­tu­al mod­el, he né is, how­ever, the mech­an­ism for the imple­ment­a­tion of func­tion­al require­ments. On the right, the mod­el (frag­ment) of the applic­a­tion archi­tec­ture, sup­ple­men­ted with a sequence dia­gram, would be a mod­el describ­ing the mech­an­ism of imple­ment­a­tion of a spe­cif­ic functionality. 


As you can see, some­times it is easy to con­fuse the terms mod­el and mech­an­ism, but we can say that a mod­el is a dia­gram depict­ing some­thing, while a mech­an­ism is an explan­a­tion of a phe­nomen­on (how some­thing is cre­ated how it works). A mech­an­ism can be illus­trated in the form of a mod­el. If we aim for the mod­el to be an ideal­iz­a­tion, then that’s it:

Mod­el­ing involves abstract­ing from the details and cre­at­ing an ideal­iz­a­tion so as to focus on the essence of a thing. A good mod­el only describes the mech­an­ism.(Craver & Tabery, 2019).



Ber­talan­ffy, L. (2003). Gen­er­al sys­tem the­ory: found­a­tions, devel­op­ment, applic­a­tions (Rev. ed., 14th paper­back print). Braziller.

Craver, C. F. (2007). Explain­ing the brain: mech­an­isms and the mosa­ic unity of neur­os­cience. Clar­en­don Press.

Craver, C., & Tabery, J. (2019). Mech­an­isms in Sci­ence. In E. N. Zalta (Ed.), The Stan­ford Encyc­lo­pe­dia of Philo­sophy (Sum­mer 2019). Meta­phys­ics Research Lab, Stan­ford Uni­ver­sity.

Frigg, R., & Hart­mann, S. (2020). Mod­els in Sci­ence. In E. N. Zalta (Ed.), The Stan­ford Encyc­lo­pe­dia of Philo­sophy (Spring 2020). Meta­phys­ics Research Lab, Stan­ford Uni­ver­sity.

Weilki­ens, T. (2007). Sys­tems engin­eer­ing with SysML/UML: Mod­el­ing, ana­lys­is, design (1. Aufl). Mor­gan Kaufmann OMG Press/Elsevier.



System design and implementation


Soft­ware engin­eers eval­u­ate cli­ent or com­pany needs in con­junc­tion with those of the user and meth­od­ic­ally con­cep­tu­al­ize a sys­tem­at­ic solu­tion (also Sys­tem Engineer).

This per­son is a Solu­tion Designer…


Pro­gram­mers write code and debug errors in pro­grams and soft­ware based on instruc­tions from soft­ware engin­eers. They are involved in a single stage with­in the devel­op­ment life­cycle and con­cen­trate on one com­pon­ent at a time (also Sys­tem Developer).

Design and implementation process

How it works for those who succeed:

  1. an organ­isa­tion­al mod­el is cre­ated (busi­ness pro­cesses and doc­u­ment structures)
  2. define busi­ness require­ments (needs)
  3. a plat­form-inde­pend­ent logic is designed to imple­ment the require­ments (sys­tem model)

A developer is then selec­ted to:

  1. selects and sets up the environment
  2. imple­ments the designed logic in the selec­ted environment
  3. deliv­er the sys­tem to the users and imple­ment it.


  • If the pro­ject is mono­lith­ic, the imple­ment­a­tion will be a “big risky waterfall”.
  • If the pro­ject is a com­pon­ent archi­tec­ture (microservices), the imple­ment­a­tion will be a smooth, iter­at­ive and incre­ment­al pro­cess (points 5. and 6. in the loop).

I’m Sys­tem Engineer…

Above diagrams from the left (Bibliography):

Paul Har­mon. (2016). The State of Busi­ness Pro­cess Man­age­ment 2016. BT Trends.

Bajaj, M., Cole, B., & Zwe­mer, D. (2016, Septem­ber 13). Archi­tec­ture To Geometry—Integrating Sys­tem Mod­els With Mech­an­ic­al Design. AIAA SPACE 2016. AIAA SPACE 2016, Long Beach, Cali­for­nia.–5470

Cock­burn, A. (2005, Janu­ary 4). Hexagon­al archi­tec­ture. Alistair Cock­burn.

A good beginning and then it gets worse, i.e. MVP

Why prob­lems occur​” only later”, at the begin­ning it was good and the cus­tom­er was satisfied

Para­dox­ic­ally, the explan­a­tion is quite simple: developers are still dom­in­ated by meth­ods based on mono­lith­ic archi­tec­tures. Preach­ing applic­a­tion” Object-ori­ented pro­gram­ming meth­ods” only means that the so-called​” object-ori­ented pro­gram­ming lan­guage”, which abso­lutely does not mean that the archi­tec­ture of what will be cre­ated will be mod­ern. Audit prac­tice shows that it will rather be an archi­tec­tur­al museum based on a rela­tion­al data mod­el, multi-level inher­it­ance and the worst data mod­el­ing prac­tices, which are an anem­ic domain mod­el and shal­low flat classes with a huge num­ber of oper­a­tions (includ­ing set/get for each attrib­ute of classes rep­res­ent­ing data­base tables).

There­fore, this scen­ario often looks like this: at the begin­ning, soft­ware is cre­ated that per­forms one spe­cif­ic func­tion, often the embryo of a mono­lith. Everything works fine, the cus­tom­er is happy and con­cludes (extends) the con­tract. The next func­tion­al­it­ies are the begin­ning of the drama: expan­sion of the mono­lith­ic data mod­el, migra­tions from the old mod­el to the new one, grow­ing prob­lems of the mono­lith­ic archi­tec­ture: everything is fall­ing apart because everything depends on everything, and no one knows how, because there is no doc­u­ment­a­tion of the applic­a­tion’s oper­a­tion mech­an­ism, and the code has long been no longer suit­able for read­ing. Try­ing to fix this is start­ing to be a bit of a rab­bit chase too…. and there is a dispute.

Source: A good begin­ning and then it gets worse, i.e. MVP – IT-Con­sult­ing Jarosław Żeliński

Mechanism of operation vs. system model

Most often in the course of ana­lys­is we use the term mod­el, less often mech­an­ism. The thing is that the term mech­an­ism appears when we want to explain some­thing, e.g. “the mech­an­ism of gen­er­at­ing a dis­count on an invoice”. The thing is that the term mech­an­ism appears when we want to explain some­thing, e.g. “the mech­an­ism for gen­er­at­ing a dis­count on an invoice”. But here beware! A mod­el (block dia­grams, for­mu­lae, etc.) is doc­u­ment­a­tion, a copy­righted descrip­tion. The mech­an­ism is what we under­stood by read­ing these doc­u­ment­a­tion (mod­el), because the mech­an­ism is pro­tec­ted know-how. The con­tent of the applic­a­tion to the Pat­ent Office is the mod­el (descrip­tion), but what we pat­ent is the mech­an­ism invented/developed.

Source: Mech­an­ism of oper­a­tion vs. sys­tem mod­el – Jarosław Żeliński IT-Consulting