Wprowadzenie

Wśród wie­lu stron WWW jest tak­że ta: Modeling Languages (źró­dło poni­żej). Tym razem autor­ka w tek­ście On com­pa­ring model­ling lan­gu­ages”, porów­nu­je kil­ka wybra­nych, jak je nazwa­ła, języ­ków mode­lo­wa­nia”. Autorka nazy­wa mode­lem urzą­dze­nia dia­gra­my map myśli i mode­le poję­cio­we, co jest moim zda­niem złym podej­ściem. Teza, że onto­lo­gia to pro­jekt opro­gra­mo­wa­nia też nie wytrzy­mu­je pro­stych testów. 

Modelowanie

Najpierw sprawdź­my co ozna­cza­ją w lite­ra­tu­rze poję­cia model i modelowanie:

mode­lo­wać coś, aby stwo­rzyć kopię lub opis dzia­ła­nia, sytu­acji itp., aby móc je prze­ana­li­zo­wać przed przy­stą­pie­niem do praw­dzi­we­go działania.

https://​www​.oxfor​dle​ar​ners​dic​tio​na​ries​.com/​d​e​f​i​n​i​t​i​o​n​/​e​n​g​l​i​s​h​/​m​o​d​e​l​_​2​?​q​=​m​o​d​e​l​ing

W poprzed­nim arty­ku­le na powią­za­ny temat pisałem:

Graficznie ten model poję­cio­wy mozna zobra­zo­wać jako dia­gram: Pojęcia: dia­gram, model i mecha­nizm oraz regu­lu­ją­ce je obsza­ry pra­wa (opr. wła­sne autora)

żr.: Mechanizm dzia­ła­nia vs model sys­te­mu vs dia­gram – Jarosław Żeliński IT-Consulting

W komen­to­wa­nym tek­ście sku­pię się na poniż­szej grafice:

Figure 1. Two exam­ple dia­grams abo­ut espres­so machi­nes: a mind map and a con­cep­tu­al data model. If you have no idea abo­ut what or how to com­pa­re yet: befo­re reading abo­ut the com­pa­ri­sons, can you descri­be dif­fe­ren­ces betwe­en the­se two examples?

Source: On com­pa­ring models

Jak zawsze, war­to upo­rząd­ko­wać zna­cze­nie pojęć uży­wa­nych w opracowaniu:

kon­cep­tu­ali­za­cja: stwo­rzyć w umy­śle wyobra­że­nie o czymś
kon­cep­cja: idea lub zasa­da zwią­za­na z czymś abs­trak­cyj­nym
poję­cie: sło­wo lub wyra­że­nie uży­wa­ne jako nazwa cze­goś, zwłasz­cza zwią­za­ne z okre­ślo­nym typem języ­ka
model poję­cio­wy (the con­cep­tu­al model): jest repre­zen­ta­cją sys­te­mu, zja­wi­ska lub pro­ble­mu, któ­ry poka­zu­je klu­czo­we poję­cia, zmien­ne, rela­cje i zało­że­nia. Może być wyra­żo­ny za pomo­cą słów, dia­gra­mów lub innych form i poma­ga kie­ro­wać pyta­nia­mi badaw­czy­mi, hipo­te­za­mi, meto­da­mi i ana­li­zą
onto­lo­gia: lista pojęć i kate­go­rii w obsza­rze tema­tycz­nym, któ­ra poka­zu­je rela­cje mię­dzy nimi

na pod­sta­wie https://​www​.oxfor​dle​ar​ners​dic​tio​na​ries​.com/

Jak widać, model poję­cio­wy to spo­sób wyra­że­nia onto­lo­gii. To bar­dzo waż­ne w tym, i nie tyl­ko tym tekście. 

Poniżej tak zwa­na mapa myśli, czę­sto sto­so­wa­ne narzę­dzie do noto­wa­nia wyni­ków burz mózgów

Powyższy dia­gram nic nie mówi o tym jak dzia­ła to urzą­dze­nie i jak je skonstruować. 

Automatyczny ekspres do kawy

Realnie taki express wyglą­da tak:

Zdjęcie real­ne­go urzą­dze­nia bez obu­do­wy (https://coffeecave.pl/blog/blog‑1/z‑czego-sklada-sie-i-jak-zbudowany-jest-ekspres-do-kawy)

Schemat blo­ko­wy opi­su­ją­cy dzia­ła­nie eks­pre­su do kawy:

Mechanizm dzia­ła­nia (https://​www​.elek​tro​da​.pl/​r​t​v​f​o​r​u​m​/​t​o​p​i​c​3​7​8​6​1​0​8​.​h​tml)

Elementy z jakich zbu­do­wa­ny jest zapa­rzacz kawy:

Lista kom­po­nen­tów (https://​north​.pl/​b​a​z​a​-​p​o​r​a​d​/​b​u​d​o​w​a​-​e​k​s​p​r​e​s​u​-​d​o​-​k​a​wy/)

Powyższe to jed­no zdję­cie i dwa dia­gra­my. Zdjęcie obra­zu­je real­ne urzą­dze­nie. Schematy poka­zu­ją odpo­wied­nio: mecha­nizm dzia­ła­nia oraz czę­ści skła­do­we real­ne­go urządzenia. 

Prosze zwró­cić uwa­gę, że każ­dy z tych obra­zów ma inny cel. Każda z tych gra­fik, jako okre­ślo­na for­ma wyra­że­nia pew­nej tre­ści, to przed­miot pra­wa autor­skie­go. Mechanizm dzia­ła­nia, wyra­żo­ny jako model, z pomo­cą dia­gra­mu jak wyżej, może być np. przed­mio­tem paten­tu, jed­nak hipo­te­tycz­ny wnio­sek paten­to­wy nie mógł­by zawie­rać ani zdję­cia ani listy ele­men­tów okre­ślo­nej kon­struk­cji (wcie­le­nie wyna­laz­ku w życie). Musiał by zawie­rać opis mecha­ni­zmu dzia­ła­nia wyra­żo­ny np. w posta­ci jak powy­żej .

To co nazwano software design”

Conceptual data model” (żr.: On com­pa­ring models)

Czym jest powyż­szy model? Jeżeli, jak uwa­ża autor­ka jet to kon­cep­cyj­ny model danych”, to spo­dzie­wam się atry­bu­tów każ­de­go z tych pojęć. Powyższy dia­gram nie opi­su­je tego co moż­na zapi­sać w jakiej­kol­wiek bazie danych (zwią­zek zawie­ra­nia sie gene­ra­li­za­cja). Odtworzenie tej kon­struk­cji w kodzie z pomo­cą języ­ka takie­go jak C++/C# czy Java jest moż­li­we, o ile ele­men­ty na tym dia­gra­mie będą zawie­ra­ły ope­ra­cje pozwa­la­ją­ce sko­rzy­stać z tej kon­struk­cji, pozo­sta­je pyta­nie jak. Owszem jest to moż­li­we ale bar­dzo trud­ne i skom­pli­ko­wa­ne (pro­stym testem będzie pró­ba nary­so­wa­nia dia­gra­mu sekwen­cji dla tej archi­tek­tu­ry), dla­te­go powyż­szy sche­mat, odtwo­rzo­ny w kodzie, nie będzie symu­la­to­rem takie­go eks­pre­su, będzie bar­dzo kosz­tow­ną atrapą.

Model ekspresu

Przypomnijmy sche­mat:

Pytanie: któ­ry z powyż­szych dia­gra­mów opi­su­je (wyja­śnia) mecha­nizm dzia­ła­nia eks­pre­su do kawy? Wygląda na to, że żaden. Więc jaki model powi­nien powstać? 

Przyjętym w inży­nie­rii sys­te­mów (MBSE) spo­so­bem postę­po­wa­nia jest dwu­eta­po­wy proces: 

  1. defi­nio­wa­nie typów blo­ków funk­cjo­nal­nych: powsta­je Block Definition Diagram, 
  2. oraz pro­jek­to­wa­nie wewnętrz­nej kon­struk­cji sys­te­mu (tu urzą­dza­nia), powsta­je Internal Block Diagram

Poniżej oba te diagramy:

Block Definition Diagram

Diagram defi­ni­cji blo­ków bywa nazy­wa­ny meta­mo­de­lem sys­te­mu na wzór dia­gra­mów klas w UML. Jednak w ter­mi­no­lo­gii nota­cji SysML to poję­cie nie jest uży­wa­ne. Poniżej model urządzenia:

Internal Block Diagram

Po uzu­peł­nie­niu go dia­gra­mem aktyw­no­ści był­by peł­nym opi­sem mecha­ni­zmu jego dzia­ła­nia. Jedynym miej­scem, gdzie mógł by się tu poja­wić kom­pu­ter (i pro­gra­mo­wa­nie) jest moduł reali­zu­ją­cy wybór recep­tu­ry i jej wyko­na­nie (ste­ro­wa­nie zaparzaczem). 

Kończąc, przy­znam, że nie wiem co autor­ka mia­ła na myśli pisząc, że jej dia­gram to model danych…

Bibliografia

Object Management Group. (2017, December 8). Systems Modeling Language (SysML). http://​www​.omg​sy​sml​.org/
Pyrża, A. (Ed.). (2006). Poradnik wyna­laz­cy: meto­dy­ka bada­nia zdol­no­ści paten­to­wej wyna­laz­ków i wzo­rów użyt­ko­wych. Urząd Patentowy Rzeczypospolitej Polskiej. https://uprp.gov.pl/sites/default/files/inline-files/Poradnik%20wynalazcy.%20Metodyka%20badania%20zdolno%C5%9Bci%20patentowej%20wynalazk%C3%B3w%20i%20wzor%C3%B3w%20u%C5%BCytkowych.%20Wydanie%20I.pdf

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.