Mechanism of Operation vs System Model vs Diagram

Mechanism of Operation vs System Model vs Diagram

Author

Jaroslaw Zel­in­ski

Date

2024-03-12 01:48:01

Cat­egor­ies

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

Introduction

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 (https://sjp.pwn.pl/)

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.

(https://dictionary.cambridge.org/)

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.

https://www.oxfordlearnersdictionaries.com/definition/english/model_2?q=modeling

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.

Examples

 

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. 

https://pl.wikipedia.org/wiki/Regulator_od%C5%9Brodkowy_obrot%C3%B3w

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. 

Clock

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. 

Summary

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).

 

Sources43790

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. https://plato.stanford.edu/entries/science-mechanisms/

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. https://plato.stanford.edu/archives/spr2020/entries/models-science/

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

WHAT DOES A SOFTWARE ENGINEER DO?

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…

WHAT DOES A PROGRAMMER DO?

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.

NOTE!

  • 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. https://www.club-bpm.com/Contenido/Estudios/BPT-Survey-Report.pdf

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. https://doi.org/10.2514/6.2016–5470

Cock­burn, A. (2005, Janu­ary 4). Hexagon­al archi­tec­ture. Alistair Cock­burn. https://alistair.cockburn.us/hexagonal-architecture/

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

Architecture & Systems Engineering

I highly recom­mend the MIT Archi­tec­ture & Sys­tems Engin­eer­ing course. it is pre­cious know­ledge and an increas­ingly pop­u­lar skill: the ana­lys­is and design of com­plex, inter­dis­cip­lin­ary systems.

Enroll in MIT’s Archi­tec­ture & Sys­tems Engin­eer­ing Online Pro­gram and learn from MIT fac­ulty and industry experts. Explore the new­est prac­tices in sys­tems engin­eer­ing, includ­ing how mod­els can enhance sys­tem engin­eer­ing func­tions and how sys­tems engin­eer­ing tasks can be aug­men­ted with quant­it­at­ive analysis.

Source: Enroll in MIT’s Archi­tec­ture & Sys­tems Engin­eer­ing Online Program

If you are look­ing for loc­al per­son­al ment­or­ing, I am an exper­i­enced MBSE expert, please ask for details.

Enterprise Architecture – goals and scope of analysis and modeling

Enter­prise Archi­tec­ture – goals and scope of ana­lyzes and mod­el­ing­Pur­pose and bene­fit­sThe primary goal of ana­lyz­ing and mod­el­ing the entire com­pany, at a pre­de­ter­mined level of detail (or rather the level of gen­er­al­ity), is to determ­ine the con­text for spe­cif­ic loc­al, domain-spe­cif­ic pro­jects. The whole mod­el con­tains inform­a­tion about the doc­u­ment flow and the IT sys­tems sup­port­ing it. The key bene­fit of hav­ing a doc­u­mented Enter­prise Archi­tec­ture is an even sev­er­al-fold reduc­tion in the costs of ongo­ing man­age­ment and devel­op­ment of the IT sys­tem, The key bene­fit of hav­ing a doc­u­mented Enter­prise Archi­tec­ture is even a sev­er­al-fold reduc­tion in the costs of cur­rent com­pany man­age­ment and the costs of IT sys­tem devel­op­ment. Giv­en mod­els we have:possibility to make organ­iz­a­tion­al decisions imme­di­ately and without risk: doc­u­mented inform­a­tion about mech­an­ism of the oper­a­tion of each busi­ness ser­vice (busi­ness pro­cesses), means the abil­ity to per­form imme­di­ate ana­lys­is the impact of each such decision on the rest of the com­panythe abil­ity to imme­di­ately make decisions about intro­du­cing neces­sary changes to the IT sys­tem, doc­u­mented inform­a­tion about the oper­a­tion mech­an­ism and archi­tec­ture of the IT sys­tem, allows for imme­di­ate imple­ment­a­tion of the specification​“to-be” of this sys­tem, and send it to sup­pli­ers as a require­ment (no need to do any pre-imple­ment­a­tion analyses),possibility of imple­ment­ing busi­ness con­tinu­ity management,possibility of imple­ment­ing a con­trolling and activ­ity-based cost man­age­ment sys­tem (ABC meth­od of cost man­age­ment). See also Tar­get oper­at­ing mod­el (TOM).

Source: Enter­prise Archi­tec­ture – goals and scope of ana­lyzes and mod­el­ing – Jarosław Żeliński IT-Consulting

What is the difference between the requirements of the solution and the needs of the user?

Sev­en years ago (2015), I ended an art­icle about require­ments and trace­ab­il­ity with the words: So the busi­ness require­ments may be dozens. The required sys­tem ser­vices (use cases) in a large pro­ject may also be dozens. But hun­dreds or thou­sands of ?require­ments? is an expres­sion of los­ing con­trol of the pro­ject scope? Here I would like to point out that a require­ment (a sys­tem ser­vice) could be, for example, a VAT invoice pro­duced in com­pli­ance with the reg­u­la­tions. The fea­tures of this invoice (list of fields) are not sep­ar­ate require­ments, they are fea­tures (para­met­ers, attrib­utes) of a single require­ment. No fea­ture of the VAT invoice has any value on its own so it can­not be a sep­ar­ate use case, just as our require­ment can be a car but its col­our or auto­mat­ic trans­mis­sion are fea­tures of the car, it makes no sense to require ?red col­our? without expect­ing a car (and how to jus­ti­fy that this col­our sup­ports the busi­ness object­ive). The use case for a car is the jour­ney and not the inser­tion of the key into the igni­tion, because this is just one ele­ment of the scen­ario of start­ing a car journey.Source: Why is require­ments tra­cing import­ant in a pro­ject? – Jarosław Żeliński IT-Con­sult­ingThere are pub­lic­a­tions about require­ments, their man­age­ment and imple­ment­a­tion. There are applic­a­tions avail­able on the mar­ket to col­lect them and man­age such a col­lec­tion. And we are con­stantly con­fron­ted with their – require­ments – ambi­gu­ity (Šen­kýř & Kroha, 2019). It turns out that their import­ance becomes cru­cial for pro­jects, also from a leg­al per­spect­ive (PZP and the concept of need defined in the recom­mend­a­tions of the Pub­lic Pro­cure­ment Office). This time I will focus on the con­cepts of «require­ment» and «need» in rela­tion to the solu­tion design.

Source: What is the dif­fer­ence between solu­tion require­ments and user needs? – Jarosław Żeliński IT-Con­sult­ing.

Work vs. design vs. intellectual property in engineering

Anoth­er dis­cus­sion I had on Linked­In recently showed that intel­lec­tu­al prop­erty law is very dif­fi­cult to assim­il­ate, mainly because – due to its «imma­ter­i­al­ity» – it escapes the intu­it­ive and mater­i­al man­ners of human per­cep­tion of the world. This is over­laid by the coder­’s con­vic­tion that, in prin­ciple, they are autonom­ous cre­at­ors, and unfor­tu­nately, many law­yers also think so. The thing is that the coder is always the cre­at­or, but not always the design­er. When the coder is not a design­er, their works (source code) are depend­ent works on primary works, which are tech­nic­al designs expressed, for example with the help of UML, math­em­at­ic­al for­mu­lae, algorithms. Then we expect coders, as developers, to do their craft brilliantly.Given that I often use pur­pose­ful and sys­tem­ic inter­pret­a­tion of con­tracts and law in the expert reports I write, I have decided to describe here an onto­lo­gic­al ana­lys­is of this area of engin­eer­ing. The aim is to determ­ine the mean­ing and range of defin­i­tions of terms com­monly used in the field of intel­lec­tu­al prop­erty. I also hope to help you with this to make bet­ter soft­ware sup­ply contracts.

Source: Cre­ation vs. design vs. intel­lec­tu­al prop­erty in engin­eer­ing – Jarosław Żeliński IT-Con­sult­ing.

ICONIX as an object-oriented, agile software design process using UML notation

The fact that ICONIX, as a pro­cess, is rel­at­ively rarely used (this has been chan­ging over the last few years, how­ever), is rooted in the fact that, first and fore­most, it requires an under­stand­ing of the com­pon­ent-ori­ented archi­tec­ture pro­cess, it also requires know­ledge and under­stand­ing of the concept of hexagon­al archi­tec­ture and the asso­ci­ated MVC pat­tern. Requires know­ledge and under­stand­ing of many oth­er object-ori­ented design pat­terns, requires, above all, abstract think­ing and mod­el­ling (UML) skills. It requires an under­stand­ing that z cod­ing must be pre­ceded by design, because «design­ing» in code is the least effect­ive form of design (Bör­ger, 2018).The pro­cess is also sup­por­ted by the divi­sion into ana­lys­is and design and imple­ment­a­tion stages (see above dia­gram: Struc­ture of pro­ject roles and products in the ICONIX pro­cess). ICONIX is some­times wrongly asso­ci­ated with a “heavy” soft­ware devel­op­ment pro­cess such as the Ration­al Uni­fied Pro­cess (which I have hardly writ­ten about on my blog). The reas­on ICONIX is rarely used, is also that, unfor­tu­nately, the world was, already in the 1990s, heav­ily “spoiled” by C++ and Java (archi­tec­tures built on cas­cades of inher­it­ance). These are often heavy, mono­lith­ic frame­works based on a rela­tion­al data mod­el, where there is no strict sep­ar­a­tion between domain logic and envir­on­ment (MVC). Java is still one of the most costly and least effect­ive applic­a­tion devel­op­ment meth­ods. The EJB frame­work is to this day described as the source of an object-ori­ented design anti-pat­tern called the «anem­ic domain mod­el». How­ever, the grow­ing developer interest in the C4 mod­el over the last few years shows that ana­lys­is and mod­el­ling are needed and quietly enter­ing through the back door….The fact that ICONIX, as a pro­cess, is rel­at­ively rarely used (this has been chan­ging over the last few years, how­ever), is rooted in the fact that, first and fore­most, it requires an under­stand­ing of the com­pon­ent-ori­ented archi­tec­ture pro­cess, it also requires know­ledge and under­stand­ing of the concept of hexagon­al archi­tec­ture and the asso­ci­ated MVC pat­tern. Requires know­ledge and under­stand­ing of many oth­er object-ori­ented design pat­terns, requires, above all, abstract think­ing and mod­el­ling (UML) skills. It requires an under­stand­ing that z cod­ing must be pre­ceded by design, because «design­ing» in code is the least effect­ive form of design (Bör­ger, 2018).The pro­cess is also sup­por­ted by the divi­sion into ana­lys­is and design and imple­ment­a­tion stages (see above dia­gram: Struc­ture of pro­ject roles and products in the ICONIX pro­cess). ICONIX is some­times wrongly asso­ci­ated with a “heavy” soft­ware devel­op­ment pro­cess such as the Ration­al Uni­fied Pro­cess (which I have hardly writ­ten about on my blog). The reas­on ICONIX is rarely used, is also that, unfor­tu­nately, the world was, already in the 1990s, heav­ily “spoiled” by C++ and Java (archi­tec­tures built on cas­cades of inher­it­ance). These are often heavy, mono­lith­ic frame­works based on a rela­tion­al data mod­el, where there is no strict sep­ar­a­tion between domain logic and envir­on­ment (MVC). Java is still one of the most costly and least effect­ive applic­a­tion devel­op­ment meth­ods. The EJB frame­work is to this day described as the source of an object-ori­ented design anti-pat­tern called the «anem­ic domain mod­el». How­ever, the grow­ing developer interest in the C4 mod­el over the last few years shows that ana­lys­is and mod­el­ling are needed and quietly enter­ing through the back door.…

Source: ICONIX jako obiek­to­wo zori­entow­any, zwinny pro­ces pro­jek­tow­ania opro­gramow­ania z uży­ciem not­acji UML – Jarosław Żeliński IT-Consulting

True Engineering

A few days ago I was talk­ing about the bor­der between require­ments ana­lys­is and engin­eer­ing with Tom Gilb. The con­clu­sion is: that we have to sep­ar­ate the require­ments stage and the engin­eer­ing stage. A huge thank you to Karo­lina Zmitrow­icz for organ­iz­ing this meeting.

True Engin­eer­ing: with Tom Gilb and Jarek Żeliński