Różnica mię­dzy sta­nem a sta­tu­sem obiektu

Wstęp

Od cza­su do cza­su wpa­da­ją mi maile z pyta­nia­mi jak to:

Chcę zamo­de­lo­wać dyna­micz­ne zacho­wa­nie / sta­ny smart­fo­na (np. wyłą­cze­nie smart­fo­na, ini­cja­li­za­cja, tryb czu­wa­nia, uży­cie) w dia­gra­mie maszy­ny sta­nów SysML. Dla sta­nu użyt­ko­wa­nia ist­nie­ją rów­nież pod­sta­ny takie jak dzwo­nie­nie, latar­ka lub robie­nie zdjęć. Nie jestem pewien czy powi­nie­nem mode­lo­wać te pod­sta­ny, a jeśli tak, to jak mogę je mode­lo­wać (szcze­gól­nie bio­rąc pod uwa­gę fakt, że każ­dy z tych pod­sta­nów może zmie­niać się w inny, jak rów­nież mogą one dzia­łać rów­no­le­gle).
Moim zda­niem są róż­ne opcje:
1.) Po pro­stu uwzględ­nić je jako aktyw­ność w uży­ciu sta­nu
2.) Wymodelować je w oddziel­nym dia­gra­mie maszy­ny sta­nów
3.) Modelować je w oddziel­nym dia­gra­mie aktyw­no­ści (czy mozna użyć dia­gra­mu aktyw­no­ści zamiast dia­gra­mu maszy­ny stanowej?)

Takie i podob­ne pyta­nia poja­wia­ją się w mailach do mnie czę­sto, ale zanim na nie odpo­wiem tu, opi­szę czym jest model (dia­gram) maszy­ny sta­no­wej. Pokażę tak­że dla­cze­go, np. pró­by wdra­ża­nia obie­gów doku­men­tów na bazie wzor­ca maszy­ny sta­no­wej” spra­wia­ją ogrom­ne kło­po­ty, lub po pro­stu się nie udają.

Na począ­tek to, co znaj­dzie­my np. w Longman English Dictionary:

sta­tus: a situ­ation at a par­ti­cu­lar time, espe­cial­ly in an argu­ment, discus­sion etc. (sytu­acja w okre­ślo­nym cza­sie, zwłasz­cza w kłót­ni, dys­ku­sji itp.)
sta­te: the phy­si­cal or men­tal con­di­tion that some­one or some­thing is in (stan fizycz­ny lub psy­chicz­ny, w jakim znaj­du­je się ktoś lub coś)

źr.: Longman English Dictionary https://​www​.ldo​ce​on​li​ne​.com/

Tak więc gene­ral­nie sta­tus to ogląd obiek­tu z zewnątrz, stan to cecha obiek­tu. Innymi sło­wy moja cho­ro­ba to mój stan, ale moja nie­zdol­ność do pra­cy to aktu­al­ny mój sta­tus (wyni­ka on nie z cho­ro­by, a z usta­le­nia, że cho­rzy nie pra­cu­ją, to nie to samo). Zapraszam do lektury. 

Metody

W bada­niu wyko­rzy­sta­no stan­dar­do­we defi­ni­cje i ele­men­ty nota­cji UML i SBVR, takie jak poję­cia obiek­tu, kla­sy obiek­tów oraz dia­gra­my klas jako mode­le struk­tu­ry i mode­le pojęciowe. 

Maszyna stanowa

W spe­cy­fi­ka­cji nota­cji UML czytamy: 

Pakiet State Machines defi­niu­je zestaw pojęć, któ­re mogą być uży­te do mode­lo­wa­nia dys­kret­nych zacho­wań ste­ro­wa­nych zda­rze­nia­mi przy uży­ciu for­ma­li­zmu skoń­czo­nych maszyn sta­nów. Oprócz wyra­ża­nia zacho­wa­nia sys­te­mu (np. zacho­wa­nia instan­cji kla­sy­fi­ka­to­ra), maszy­ny sta­nów mogą rów­nież wyra­żać zacho­wa­nie czę­ści sys­te­mu, maszy­ny sta­nów mogą być rów­nież uży­te do wyra­że­nia pra­wi­dło­wych sekwen­cji inte­rak­cji, zwa­nych pro­to­ko­ła­mi. Te dwa rodza­je maszyn sta­nów nazy­wa­ne są odpo­wied­nio maszy­na­mi sta­nów zacho­wań oraz maszy­na­mi sta­nów pro­to­ko­łów. Specyficzna for­ma auto­ma­tów sta­nów skoń­czo­nych uży­wa­na w UML‑u jest opar­ta na warian­cie for­ma­li­zmu tablic sta­nów Davida Harela.

Ograniczenia uży­cia gra­ficz­ne­go sche­ma­tu maszy­ny sta­no­wej opi­sał sam Harel, wska­za­no tak­że na ogra­ni­cze­nia tej meto­dy, mię­dzy inny­mi zło­żo­ność tak wyra­ża­nych sche­ma­tów .

Poniżej przy­kład ww. auto­ra kon­struk­cji sto­so­wa­nych w C++: 

Poniżej podob­na w meto­dzie two­rze­nia kon­struk­cja ze spe­cy­fi­ka­cji UML:

Są to kon­struk­cje maszy­ny sta­no­wej bazu­ją­ce na skom­pli­ko­wa­nych mode­lach mate­ma­tycz­nych (nie będę ich tu przy­ta­czał), ich ideą jest gene­ral­nie wyra­ża­nie mode­lu dzia­ła­nia obiek­tu wyłącz­nie tą jed­ną meto­dą: zało­że­niu, że 100% zacho­wań obiek­tu to zmia­na jego sta­nu jako reak­cja na bodź­ce z oto­cze­nia. Założenie to jed­nak ma wadę: nie każ­dy (sys­tem) da się opi­sać w cało­ści jako taka maszy­na sta­no­wa. Po dru­gie podej­ście to czę­sto pro­wa­dzi do bar­dzo zło­żo­nych mode­li, co powo­du­je, że ich uży­tecz­ność jako gra­ficz­na meto­da zobra­zo­wa­nia i komu­ni­ko­wa­nia jest zni­ko­ma zaś pra­co­chłon­ność napi­sa­nia odpo­wia­da­ją­ce­go temu mode­lo­wi kodu jest tak­że bar­dzo duża. 

W spe­cy­fi­ka­cji UML znaj­dzie­my jed­nak i takie przy­kła­dy maszy­ny stanowej:

Model pojęciowy

Kiedy i z czym mamy do czy­nie­nia? Kluczowe pojęcia:

auto­mat: maszy­na wyko­nu­ją­ca czyn­ność lub ciąg czyn­no­ści bez udzia­łu człowieka, 

ale też:

auto­ma­tycz­ny: dzia­ła­ją­cy samo­czyn­nie, za pomo­cą odpo­wied­nie­go urzą­dze­nia, wyko­ny­wa­ny lub powsta­ją­cy bez udzia­łu świa­do­mo­ści i woli, będą­cy nie­uchron­nym następ­stwem lub natu­ral­ną kon­se­kwen­cją czegoś

maszy­na: urzą­dze­nie zawie­ra­ją­ce mecha­nizm lub zespół współ­dzia­ła­ją­cych mecha­ni­zmów, słu­żą­ce do prze­twa­rza­nia ener­gii albo do wyko­ny­wa­nia okre­ślo­nej pracy

mecha­nizm: zespół współ­pra­cu­ją­cych ze sobą czę­ści maszy­ny lub przy­rzą­du, wyko­nu­ją­cych jakąś pra­cę, spo­sób, w jaki coś powsta­je, prze­bie­ga lub dzia­ła, (patrz tak­że )

stan: sytu­acja, w któ­rej ktoś lub coś się znajduje

Podstawową róż­ni­cą mię­dzy auto­ma­tem a maszy­ną, jest więc samo­czyn­ność” auto­ma­tu (auto­ma­tyzm jako samo­ist­ność reak­cji na coś). Generalnie więc auto­ma­tyzm to zacho­wa­nie się, maszy­na to okre­ślo­ny, nie raz zło­żo­ny (dzia­ła­ją­cy) mechanizm. 

Powiemy, że czło­wiek auto­ma­tycz­nie reagu­je krzy­kiem na ból, ale nie powie­my, że reagu­je maszy­no­wo” lub jak maszy­na”. Z tego powo­du, przyj­mu­je­my, że auto­mat to opis zacho­wa­nia się, a maszy­na to opis (model) kon­struk­cji (struk­tu­ry) mecha­ni­zmu. Maszyna może zacho­wy­wać się jak auto­mat .

Ontologia pojęć maszy­na i auto­mat (opra­co­wa­nie własne) 

Testowanie onto­lo­gii pole­ga na spraw­dze­niu syn­tak­tycz­nej popraw­no­ści i praw­dzi­wo­ści zdań two­rzo­nych z nazw (pojęć w mode­lu poję­cio­wym) z uży­ciem pre­dy­ka­tów (związ­ków zda­nio­twór­czych, w nota­cji SBVR nazy­wa­nych faktami):

  • mecha­nizm reali­zu­je auto­mat (zacho­wa­nia opi­sa­ne automatem)
  • auto­mat opi­su­je zacho­wa­nie się maszy­ny (jej stany)
  • maszy­na przyj­mu­je okre­ślo­ny stan
  • auto­mat przyj­mu­je okre­ślo­ny stan
  • maszy­na imple­men­tu­je mecha­nizm (pro­jek­to­wa­nie)
  • mecha­nizm wyja­śnia dzia­ła­nie maszy­ny (ana­li­za)

Automat to abs­trak­cja (model) opi­su­ją­ca auto­ma­tycz­ną” zmia­nę sta­nów cze­goś (to tak zwa­na czar­na skrzyn­ka wg. BABoK). Mechanizm wyja­śnia jak do tych zmian sta­nu docho­dzi (bia­ła skrzyn­ka wg. BABoK). Maszyna to real­na kon­struk­cja lub jej pro­jekt (model), reali­zu­ją­ca opi­sa­ny mecha­nizm dzia­ła­nia. Stan to cecha zarów­no maszy­ny jak i abs­trak­cji ją opi­su­ją­cej (auto­ma­tu). Ciekawą, war­tą lek­tu­ry, histo­rię sto­so­wa­nia poję­cia auto­ma­tu w histo­rii oraz auto­ma­tycz­ne­go mecha­ni­zmu (jako cze­goś dzia­ła­ją­ce­go auto­ma­tycz­nie) poda­je Bedini .

Z powyż­sze­go wyni­ka, że stan to cecha zarów­no maszy­ny jak i auto­ma­tu, jed­nak to maszy­na jest bytem mate­rial­nym reali­zu­ją­cym okre­ślo­ny mecha­nizm dzia­ła­nia . Skoro zaś stan to cecha i auto­ma­tu i maszy­ny, to auto­mat jest abs­trak­cyj­nym (obser­wa­cyj­nym) opisem/modelem maszy­ny, opi­su­ją­cym jej zacho­wa­nie (reak­cje). Często mówi­my auto­mat sta­no­wy” by pod­kre­ślić to, że jest to model zmian sta­nu maszy­ny, a nie model opi­su­ją­cy jej dzia­ła­nie (bo to opi­su­je mecha­nizm) , .

Mechanizm dzia­ła­nia Zegara (źr.: Model dzie­dzi­ny jako mecha­nizm)

Powyższy dia­gram to model opi­su­ją­cy (wyja­śnia­ją­cy) mecha­nizm dzia­ła­nia zega­ra, tu wyra­żo­ny w nota­cji UML. Jest to model mecha­ni­zmu dzia­ła­nia Zegara, ale nie koniecz­nie deta­licz­ny pro­jekt kon­kret­ne­go egzem­pla­rza (typu). Poniżej, jed­na z wie­lu moż­li­wych imple­men­ta­cji: mecha­nicz­na maszyna.

Zegar jako maszy­na (imple­men­ta­cja)

Zegar, zależ­nie od tego czy jest zasi­la­ny czy nie, może być w sta­nie: pra­cu­je” lub nie pra­cu­je”, co moż­na wyra­zić poniż­szym mode­lem: dia­gram UML Maszyny Stanowej (auto­ma­tu stanowego): 

Automat sta­no­wy Zegara (w kon­tek­ście zasi­la­nia: Zegar dzia­ła lub nie działa). 

Jednak powyż­szy model nie wyja­śnia tego jak dzia­ła zegar (i tego, że ma np. bate­rię i sil­ni­czek lub sprę­ży­nę). Pomysłem kurio­zal­nym (ale nie takim rzad­kim) było by poka­za­nie sta­nów zega­ra jako kolej­nych poło­żeń wska­zó­wek (lub tre­ści tar­czy zega­ra elek­tro­nicz­ne­go). Mam nadzie­ję, że czy­tel­nik ma na tyle wyobraź­ni bym nie musiał tu tego ryso­wać. Wtedy np. pro­gram kom­pu­te­ro­wy Zegar” mógł­by być auto­ma­tem, wyświe­tla­ją­cym co minu­tę (lub co sekun­dę) kolej­ny sta­tycz­ny obraz tar­czy zegara:

Generalnie uzna­nie, że stan obiek­tu to aktu­al­na war­tość wszyst­kich jego cech, oraz pró­by zobra­zo­wa­nia tego meto­da­mi jak wyżej nie wno­si żad­nej war­to­ści w pozna­nie tego obiek­tu, gdyż: 

Obserwowalna zmia­na sta­nów maszy­ny” nie jest mode­lem (opi­sem) mecha­ni­zmu jej dzia­ła­nia .

Ciekawe jest to, że bar­dzo rzad­ko, powsta­je potrze­ba mode­lo­wa­nia sta­nu sys­te­mu” rozu­mia­ne­go jako aktu­al­na, łącz­na war­to­ści jego cech, gdyż wie­le cech jed­ne­go sys­te­mu to cechy od sie­bie nie­za­leż­ne i ich aktu­al­ny łącz­ny stan” w zasa­dzie nie ma zna­cze­nia. Zachowanie się sys­te­mu bar­dzo rzad­ko, o ile w ogó­le, jest efek­tem aktu­al­nej war­to­ści wszyst­kich jego atry­bu­tów. Tu nie­ste­ty oka­zu­je się, że zna­na z nie­któ­rych pod­ręcz­ni­ków pro­gra­mo­wa­nia defi­ni­cja: stan obiek­tu to aktu­al­na war­tość jego atry­bu­tów, nie odda­je praw­dy. Popatrzmy np. na sie­bie: jed­nym z naszych atry­bu­tów jest stan zdro­wia a innym waga, obie te cechy mogą zmie­niać war­tość. Jakie ma zna­cze­nie łącz­na wie­dza «cho­ry, 45 kg vs. «zdro­wy, 45 kg» czy «zdro­wy, 48 kg», itd? 

Tak więc na pyta­nie czy­tel­ni­ka zada­ne we wstępie: 

Chcę zamo­de­lo­wać dyna­micz­ne zacho­wa­nie / sta­ny smart­fo­na (np. wyłą­cze­nie smart­fo­na, ini­cja­li­za­cja, tryb czu­wa­nia, uży­cie) w dia­gra­mie maszy­ny sta­nów SysML. Dla sta­nu użyt­ko­wa­nia ist­nie­ją rów­nież pod­sta­ny takie jak dzwo­nie­nie, latar­ka lub robie­nie zdjęć

Odpowiedź brzmi: takie mode­lo­wa­nie tele­fo­nu, z pomo­cą zagnież­dżo­nej maszy­ny sta­no­wej”, nie ma sen­su, bo np. świe­ce­nie latar­ki nijak sie ma do sta­nu czu­wa­nia itp. I nawet gdy­by powstał taki dia­gram, to na pew­no nicze­go nie wyjaśni…

Czy moż­na zastą­pić dia­gram maszy­ny sta­no­wej dia­gra­mem aktyw­no­ści? Nie. Bo to zupeł­nie inny model (czy­taj o dia­gram aktyw­no­ści).

Rezultaty: kiedy modelujemy stan a kiedy status?

Powyższe opi­sy doty­czą sys­te­mów (sys­tem). Jednak opro­gra­mo­wa­nie to nie tyl­ko obser­wa­cja i reali­za­cja maszy­ny (parz: kom­pu­ter jako uni­wer­sal­ny mecha­nizm).

Oprogramowanie, szcze­gól­nie zwa­ne biz­ne­so­wym, to prze­twa­rza­ne dane (a z per­spek­ty­wy czło­wie­ka: infor­ma­cje), co prze­kła­da się tak­że na doku­men­ty jako ich nośni­ki. Dane (infor­ma­cje) zaś nie są maszy­ną! Maszyną może być (jest) sys­tem, któ­re te dane przetwarza.

Kolejne poję­cia:

sta­tus: stan praw­ny jakiejś oso­by, insty­tu­cji lub organizacji

cecha: (filoz.) nie­sa­mo­dziel­ny skład­nik rze­czy, dają­cy się w niej wyróż­nić tyl­ko w dro­dze ana­li­zy myślowej

Przedmiot i jego bli­ska onto­lo­gia (opra­co­wa­nie własne)

Kluczowe jest pyta­nie: co chce­my wie­dzieć i kie­dy, co chce­my zapi­sać i gdzie? Status doku­men­tu, spra­wy, itp. rozu­mia­ne­go jako jego zacho­wa­nie? Dokument nie ma zacho­wa­nia”. Takie podej­ście (zacho­wa­nie się doku­men­tu) to myle­nie sta­nu obiek­tu z kla­sy­fi­ko­wa­niem infor­ma­cji (jego tre­ści). Np. doku­ment może mieć sta­tus «w edy­cji» lub «ukoń­czo­ny», infor­ma­cja w nim zawar­ta to nie stan doku­men­tu a treść i ewen­tu­al­nie kla­sy­fi­ka­cja jego tre­ści. Np. fak­tu­ra ma sta­tus w toku edy­cji, zapi­sa­na lub zaksię­go­wa­na, stan płat­no­ści nie jest cechą (tre­ścią) fak­tu­ry, to cecha sal­da. Faktura jako doku­ment nie zmie­ni swo­jej tre­ści po jej opła­ce­niu. Gdzie to zapi­su­je­my? W innym miej­scu (obiek­cie), naj­czę­ściej to repo­zy­to­rium prze­cho­wu­je infor­ma­cje o sta­nie doku­men­tu, a nie sam doku­ment… Pisałem o tym już 10 lat temu:

Model ten więc bazu­je na zało­że­niu, że wie­dza o sta­tu­sie (kie­dy jaki przy­jąć) tkwi w obiek­cie sta­tu­so­wym (przyj­mu­ją­cym te sta­ny). Przykładem może być np. woda i jej sta­ny sku­pie­nia, któ­re są cechą fizycz­ną wody ? są więc zwią­za­ne z wodą. Woda może przy­jąć stan sku­pie­nia sta­ły (lód), cie­kły lub gazo­wy (para wod­na). Aktualny stan sku­pie­nia zale­ży wyłącz­nie od tem­pe­ra­tu­ry i ciśnie­nia. Żaden inny czyn­nik nie jest w sta­nie zmie­nić sta­nu kupie­nia wody (np. na pole­ce­nie czło­wie­ka ;)). Przykładów takich moż­na przy­to­czyć wiele.Problem zaczy­na się gdy obiekt ma sta­tu­sy zależ­ne od pew­nej logi­ki zewnętrz­nej, jakiś inny obiekt ma wie­dzę o tym jaki sta­tus zosta­nie ustawiony. 

(parz: Problem z wzor­cem State Machine czy­li ile Cię kosz­tu­je work­flow – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

To dla­te­go, pró­by wdra­ża­nia obie­gów doku­men­tów na bazie wzor­ca maszy­ny sta­no­wej” spra­wia­ją ogrom­ne kło­po­ty, lub po pro­stu się nie uda­ją (kla­sycz­ny anty­przy­kład w arty­ku­le: Status ? infor­ma­cja dla klien­ta czy dostaw­cy?).

Tak więc: stan obiek­tu to jego cecha, sta­tus obiek­tu to opis nie­bę­dą­cy cechą tego obiektu.

Porównaj poję­cia wewnętrz­ny i zewnętrz­ny stan obiek­tu u Kirchhoff’a , któ­re zgod­nie z powyż­szym uwa­żam za błęd­ne. Wiele obiek­tów to obiek­ty jed­no­sta­no­we” czy­li takie, któ­re od momen­ty powsta­nia nie zmie­nia­ją się , ist­nie­ją jed­nak ich zewnętrz­ne opi­sy. Typowy przy­kład to faktura:

Faktura to odręb­ny samo­dziel­ny doku­ment, jego sta­tus jest prze­cho­wy­wa­ny w innym obiekcie.

Powyższy przy­kład to typo­wa sytu­acja, w któ­rej stan fak­tu­ry i jej sta­tus to dwa odręb­ne byty infor­ma­cyj­ne”: Faktura to jedy­nie jej treść (to doku­ment, któ­re­go od momen­tu wysta­wie­nia nie wol­no już mody­fi­ko­wać). Biznesowy sta­tus fak­tu­ry 9do zapła­ty itd.) nie może być prze­cho­wy­wa­ny jako treść tej fak­tu­ry to ta od momen­tu wysta­wie­nia z zasa­dy jest doku­men­tem read only”. Dlatego biz­ne­so­we cechy fak­tu­ry musi prze­cho­wy­wać poza nią, z regu­ły jest to zapis w księ­gach rachun­ko­wych, gdyż fak­tu­ra nie wie, że jest opła­co­na”, wie to księ­go­wość”.

W kon­se­kwen­cji widać, że nie da się opi­sać sys­te­mu ani jego logi­ki wyłącz­nie maszy­ną sta­no­wą. Zmiany sta­tu­sów fak­tu­ry (Biznesowy sta­tus fak­tu­ry) to nie sku­tek zda­rzeń (even­ty) a okre­ślo­nych pro­ce­dur (np. cyklicz­ne spraw­dza­nie sta­nu rachun­ku ban­ko­we­go) i reguł biz­ne­so­wych (np. speł­nie­nie warun­ku). Tu mogło by to być:

  1. jeże­li nie jest Umorzona sprawdź wyciąg bankowy 
    • jeże­li doko­na­no wpła­ty ustaw sta­tus Zapłacona
    • jeże­li brak wpła­ty i dzień płat­no­ści jest data prze­szłą, ustaw Do windykacji
  2. jeże­li sta­tus jest Do win­dy­ka­cji i zde­cy­do­wa­no o umo­rze­niu ustaw Umorzona

Mam tu dwie pro­ce­du­ry wyko­ny­wa­ne alter­na­tyw­nie. W pro­ce­du­rze 1. nie musi­my obsłu­gi­wać fak­tu jeże­li brak wpła­ty i dzień płat­no­ści jest data przy­szłą pozo­staw Do zapła­ty”, bo ta pro­ce­du­ra ozna­cza nic nierobienie”.

Rozwiązanie pro­ble­mu (archi­tek­tu­ra implementacji):

Zarządzanie Fakturami

Komponent (obiekt) Repozytorium odpo­wia­da za utrwa­la­nie i dostęp do doku­men­tów, Obiekty kla­sy Formularz Faktury, prze­cho­wu­ją doku­men­ty (a są nimi cią­gi zna­ków). Status fak­tu­ry nie jest tre­ścią fak­tu­ry (być moze jest to nawet pod­pi­sa­ny elek­tro­nicz­nie nie­edy­to­wal­ny doku­ment), aktu­al­ny sta­tus tu jest prze­cho­wy­wa­ny na koper­cie” (atry­but sta­tus” obiek­tu kla­sy Faktura). Wartość tego sta­tu­su usta­wia wyżej opi­sa­na pro­ce­du­ra reali­zo­wa­na przez obiekt Logika biz­ne­so­wa (meto­da jej uru­cha­mia­nia nie ma tu zna­cze­nia, może to być reali­zo­wa­ne cyklicz­nie raz na dobę). 

Powyższe to jeden z wie­lu powo­dów, dla któ­rych meto­dy takie jak event stor­ming” są bar­dzo nie­sku­tecz­ne jako ana­li­za i pro­jek­to­wa­nie logi­ki dzia­ła­nia opro­gra­mo­wa­nia, szcze­gól­nie tak zwa­ne­go biz­ne­so­we­go”.

Będzie c.d.

Źródła

Bedini, S. A. (1964). The Role of Automata in the History of Technology. Technology and Culture, 5(1), 24. https://​doi​.org/​1​0​.​2​3​0​7​/​3​1​0​1​120
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Drusinsky, D., & Harel, D. (1989). Using sta­te­charts for har­dwa­re descrip­tion and syn­the­sis. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 8(7), 798 – 807. https://​doi​.org/​1​0​.​1​1​0​9​/​4​3​.​3​1​537
Harel, D. (2000). From play-in sce­na­rios to code: An achie­va­ble dre­am. International Conference on Fundamental Approaches to Software Engineering, 22 – 34.
Harel, D. (1992). Biting the silver bul­let: Toward a bri­gh­ter futu­re for sys­tem deve­lop­ment. Computer, 25(1), 8 – 20.
Harel, D., & Gery, E. (1996). Executable object mode­ling with sta­te­charts. Proceedings of IEEE 18th International Conference on Software Engineering, 246 – 257.
Kiverstein, J., Kirchhoff, M., & Thacker, M. (2021). An Embodied Predictive Processing Theory of Pain.
MacKay, D. M. (1956). The Epistemological Problem for Automata. In C. E. Shannon & J. McCarthy (Eds.), Automata Studies. (AM-34) (pp. 235 – 252). Princeton University Press. https://​doi​.org/​1​0​.​1​5​1​5​/​9​7​8​1​4​0​0​8​8​2​618 – 012
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Yang, N., Cuijpers, P., Schiffelers, R., Lukkien, J., & Serebrenik, A. (2021). Single-sta­te sta­te machi­nes in model-dri­ven softwa­re engi­ne­ering: an explo­ra­to­ry stu­dy. Empirical Software Engineering, 26(6), 124. https://​doi​.org/​1​0​.​1​0​0​7​/​s​1​0​6​6​4​-​021 – 10015‑3

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

Ten post ma 2 komentarzy

  1. Paweł Sańczyk

    Bardzo cie­ka­wy artykuł.

    Teraz tak mnie wzię­ła reflek­sja, żeby zasta­no­wić się w sumie nad tak czę­sto spo­ty­ka­ną rze­czą jak użyt­kow­nik i kon­to w sys­te­mie. Bardzo czę­sto wszyst­ko jest zawsze upy­cha­ne do jed­nej encji.

    1. Jarosław Żeliński

      użyt­kow­nik i kon­to w sys­te­mie. Bardzo czę­sto wszyst­ko jest zawsze upy­cha­ne do jed­nej encji.”

      Tak, to czę­sty błąd. Znacznie lep­szą prak­ty­ką jest sepa­ro­wa­nie danych użyt­kow­ni­ka (jego pro­fil, kar­to­te­ka, jak zwał tak zwał) od jego aktu­al­ne­go sta­tu­su i sesji: auten­ty­ka­cja to funk­cja śro­do­wi­ska (patrz archi­tek­tu­ra hek­sa­go­nal­na, albo MVC) zaś dane kon­tak­to­we to sta­tycz­ny opis. Należy sepa­ro­wać (osob­ne encje”) fak­ty i sta­tus oraz opis: fak­ty to zalo­go­wa­nie się i wylo­go­wa­nie, sta­tus to jest” lub nie jest” zalo­go­wa­ny, a opis to moje imię nazwi­sko itp.. 

      Opisałem ten pro­blem w tej recen­zo­wa­nej publikacji:
      https://​www​.igi​-glo​bal​.com/​c​h​a​p​t​e​r​/​d​i​g​i​t​a​l​-​d​o​c​u​m​e​n​t​s​-​a​s​-​d​a​t​a​-​c​a​r​r​i​e​r​s​-​a​n​d​-​a​-​m​e​t​h​o​d​-​o​f​-​d​a​t​a​-​m​a​n​a​g​e​m​e​n​t​-​g​u​a​r​a​n​t​e​e​i​n​g​-​t​h​e​-​u​n​a​m​b​i​g​u​i​t​y​-​o​f​-​t​h​e​-​r​e​c​o​r​d​e​d​-​i​n​f​o​r​m​a​t​i​o​n​/​2​7​5​700

Dodaj komentarz

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