Wprowadzenie
Najczęściej w toku analiz posługujemy się pojęciem model, rzadziej mechanizm. Rzecz w tym, że pojęcie mechanizm pojawia się gdy chcemy coś wyjaśnić, np. “mechanizm generowania upustu na fakturze”.
Ale tu uwaga! Model (schematy blokowe, wzory itp.) to dokumentacja, opis chroniony prawem autorskim. Mechanizm to to, co zrozumieliśmy czytając te dokumentację (model), bo mechanizm to chronione know-how. Treść wniosku do Urzędu Patentowego to model (opis), ale to co patentujemy to wymyślony/opracowany mechanizm.
Mechanizm a model
Mechanizm i model w nauce to bliskie sobie pojęcia, np. tak opisywane:
Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm. […] Glennan argumentował, że mechanizmy są sekretnym połączeniem, którego Hume szukał między przyczyną a skutkiem: “Mechanizm zachowania jest złożonym systemem, który wytwarza to zachowanie poprzez interakcję wielu części, gdzie interakcję między częściami można scharakteryzować za pomocą bezpośrednich, niezmiennych uogólnień odnoszących się do zmian”
Popatrzmy jak te pojęcia definiuje oficjalny Słownik Języka Polskiego:
mechanizm «sposób, w jaki coś powstaje, przebiega lub działa»
Słownik Języka Polskiego (https://sjp.pwn.pl/)
model «konstrukcja, schemat lub opis ukazujący działanie, budowę, cechy, zależności jakiegoś zjawiska lub obiektu»
Jak widać bardzo podobnie. Pojęcie diagram jest definiowane w literaturze anglojęzycznej:
diagram: prosty plan przedstawiający maszynę, system lub pomysł itp., często rysowany w celu wyjaśnienia, jak to działa
(https://dictionary.cambridge.org/)
W literaturze naukowej (anglojęzyczna) pojęcie modelowania jest definiowane jako:
modelować coś, aby stworzyć kopię lub opis działania, sytuacji itp., aby móc je przeanalizować przed przystąpieniem do prawdziwego działania.
https://www.oxfordlearnersdictionaries.com/definition/english/model_2?q=modeling
Graficznie ten model pojęciowy mozna to zobrazować jako diagram:
Pozostaje kwestia pojęć: zjawisko (ktore chcemy opisać, wyjaśnić) oraz jego wyjaśnienie. Dane zjawisko to określone, zaobserwowane fakty. Najczęściej opisujemy jest literalnie lub tworzymy ich statystykę. Craver tak obrazuje związek miedzy zjawiskiem a mechanizmem jego powstawania:
Górna elipsa to nasze obserwacje: bodziec i skutek i elipsa to zapis faktów, ich statystyka. Statystyka jednak nie jest modelem, jest tylko statyką, zbirem danych o faktach, nie stanowi ona żadnego wyjaśnienia ich powstawania.
Dolna elipsa to mechanizm wyjaśniający powstawanie, inicjowanego bodźcami, zaobserwowanego efektu (faktów zebranych w statystyce). Jest to wyjaśnienie tego jak efekt (fakty, skutek) powstaje. To mechanizm powstania tego co obserwujemy. Ten mechanizm (wyjaśnienie) obrazujemy (można wyrazić jako) jako model, który można wyrazić np. schematem blokowym.
W nauce mówimy, że mechanizm to wyjaśnienie wrażone jako model “czegoś”:
Jak na razie było bardzo “abstrakcyjnie”, więc pokażmy jakieś przykłady.
Przykłady
Teoria Kopernika
Przykładem, który zapewne zna każdy jest Teoria Kopernika. Poniższy diagram pokazuje: po lewej u góry zapis obserwacji Nieba niesłusznie często nazywany modelem (statystycznym). To tak zwane epicykle: zobrazowanie obserwacji dróg planet i gwiazd na niebie, zaobserwowane z Ziemi. Po prawej na dole heliocentryczny układ słoneczny, ten diagram to model, który wyjaśnia mechanizm powstawania epicykli, czyli pętli jakie wykonują na niebie obserwowane gwiazdy i planety.
Regulator Watt’a
Inny przykład: regulator Watta. Poniżej model tego regulator:
Opis mechanizmu we wniosku patentowym był tekstem podobnym do tego:
Jeśli maszyna jest w spoczynku to ciężarki (kulki) są na samym dole, a przepustnica jest całkowicie otwarta. Jeśli maszyna parowa zacznie pracować. Obracające się koło maszyny parowej połączone jest z regulatorem obrotów – kulki zaczynają się obracać. Na kulki regulatora działają dwie siły. Siła grawitacji przyciągająca kulki pionowo w dół oraz siła odśrodkowa odciągająca kulki na zewnątrz, co przy takiej konstrukcji regulatora powoduje unoszenie się kulek ku górze. Unoszące się kulki powodowały zamykanie się przepustnicy, a to skutkowało mniejszą ilością pary dostarczanej do maszyny parowej. Maszyna zwalniała, malała więc siła odśrodkowa, kulki opadały w dół więc przepustnica się otwierała i tym samym dostarczała więcej pary do maszyny.
https://pl.wikipedia.org/wiki/Regulator_od%C5%9Brodkowy_obrot%C3%B3w
Schemat opisujący ten regulator:
Mechanizm wyjaśniający działanie tego regulatora to systemu z ujemnym sprzężeniem zwrotnym:
Regulator Watt’a to właśnie ujemne sprzężenie zwrotne. Na powyższym diagramie PROCES to maszyna parowa, wielkością na wejściu jest para wodna mająca określone ciśnienie, wielkością na wyjściu jest prędkość obrotowa wału napędowego maszyny parowej. Wzrost prędkości obrotowej wału powoduje zmniejszenie ciśnienia pary zasilającej maszynę parową, co z kolei powoduje zmniejszenie prędkości obrotowej wału i tym samym otwarcie zaworu pary na wejściu i ponowny wzrost prędkości obrotowej. Zjawisko doprowadzi do ustalonej (ustabilizowanej) prędkości wału z małymi jej wahaniami.
Zegar
Typowy analogowy zegar (jego tarcza) wiszący na niejednej ścianie w domu (lub zamontowany na niejednej wieży) wygląda jak poniżej:
Możliwa konstrukcja takiego zegara na wieży:
Mechanizm pomiaru czasu jaki stosujemy, wyjaśniający wskazanie na tarczy zegarowej, stanowiący podstawę konstruowania zegarów, wyrażony jako model w notacji UML:
Mechanizm działania maszyny
Powyżej po lewej diagram opisujący mechanizm działania sortownika, jest to model działania tego sortownika. Po prawej stronie sortownik, który jest skomplikowanym urządzeniem, realizującym mechanizm działania opisany na diagramie po lewej. Gdyby to urządzenie było patentowane, wniosek patentowy zawierał by schemat po lewej a nie rysunki konstrukcyjne maszyny po prawej.
Model pojęciowy
Wiedzę dziedzinową modelujemy jako Słownik pojęciowy, ten zaś można wyrazić graficznie w postaci taksonomii i związków syntaktycznych. Architektura kodu aplikacji wyrażona graficznie to jej model, dodanie do mniej diagramów opisujacych np. scenariusze przypadków użycia to także element tego modelu. Całość jednak opisuje mechanizm realizacji wymagań funkcjonalnych.
Poniżej po lewej model pojęciowy, on ne jest jednak mechanizmem realizacji wymagań funkcjonalnych. Po prawej model (fragment) architektury aplikacji, uzupełniony o diagram sekwencji był by modelem opisującym mechanizm realizacji określonej funkcjonalności.
Prawo autorskie
Jednym zdaniem: powyższe obrazki, jako grafikę, chroni prawo autorskie.
Podsumowanie
Jak widać czasami łatwo pomylić pojęcia model i mechanizm, można jednak powiedzieć, że model to schemat obrazujący coś, zaś mechanizm to wyjaśnienie zjawiska (tego jak coś powstaje jak działa). Mechanizm można zobrazować w postaci modelu. Jeżeli dążymy by model był idealizacją, to wtedy właśnie:
Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm.
Dla “zabawy”, w ramach ćwiczeń proponuję studiowanie tych opisówpatentów:
– jest schemat
– który jest modelem
– opatentowanego mechanizmu
https://www.wipo.int/patents/en/2023-patent-picks.html
Skąd pochodzi grafika porownujaca model pojęciowy i architekturę?
Autor i książka pod diagramem.
https://www.amazon.pl/Systems-Engineering-SysML-UML-Modeling/dp/0123742749/
https://www.amazon.pl/UML-Certification-Guide-Fundamental-Intermediate/dp/B00LXNDOJM
Któraś z tych??
Oj, faktycznie było graficznie a nie tekstowo, uzupełniłem. Generalnie nie brakuje tekstów opisujacych szkodliwość dziedziczenia i nie przypadkiem zostało ono usunięte z UML w 2015 roku.
Mógłby Pan podać inne przykłady publikacji, które o tym mówią?
Na blogu znajdzie Pan wiele. Pozycja literaturowa podana tu jest w pewnym sensie referencyjna, wszyscy piszą TO SAMO: dziedziczenie ze wszystkiego tworzy ciężki monolit który jest zaprzeczeniem podziału komponenty i łamie hermetyzację. To nie jest tak, ze ktoś tu musi coś udowadniać, to jest tak, że liczą sie wyłącznie koszty tworzenia, utrzymania i rozwoju aplikacji, np. sam wybór modelu takiego jak JavaEE powoduje dramat kosztowy powodowany ogromna komplikacją kodu powodowaną przez anemiczny model dziedziny a o tym to już M.Fowler.
Standardowa odpowiedź wielu autorów: jeżeli jakaś funkcjonalność może powstać jako efekt 500 linii kodu albo jako efekt 5 linii kodu, to co do zasady ta druga jest lepsza.