Różnica między stanem a statusem obiektu

Wstęp

Od czasu do czasu wpadają mi maile z pytaniami jak to:

Chcę zamodelować dynamiczne zachowanie / stany smartfona (np. wyłączenie smartfona, inicjalizacja, tryb czuwania, użycie) w diagramie maszyny stanów SysML. Dla stanu użytkowania istnieją również podstany takie jak dzwonienie, latarka lub robienie zdjęć. Nie jestem pewien czy powinienem modelować te podstany, a jeśli tak, to jak mogę je modelować (szczególnie biorąc pod uwagę fakt, że każdy z tych podstanów może zmieniać się w inny, jak również mogą one działać równolegle).
Moim zdaniem są różne opcje:
1.) Po prostu uwzględnić je jako aktywność w użyciu stanu
2.) Wymodelować je w oddzielnym diagramie maszyny stanów
3.) Modelować je w oddzielnym diagramie aktywności (czy mozna użyć diagramu aktywności zamiast diagramu maszyny stanowej?)

Takie i podobne pytania pojawiają się w mailach do mnie często, ale zanim na nie odpowiem tu, opiszę czym jest model (diagram) maszyny stanowej. Pokażę także dlaczego, np. próby wdrażania obiegów dokumentów na bazie wzorca “maszyny stanowej” sprawiają ogromne kłopoty, lub po prostu się nie udają.

Na początek to, co znajdziemy np. w Longman English Dictionary:

status: a situation at a particular time, especially in an argument, discussion etc. (sytuacja w określonym czasie, zwłaszcza w kłótni, dyskusji itp.)
state: the physical or mental condition that someone or something is in (stan fizyczny lub psychiczny, w jakim znajduje się ktoś lub coś)

źr.: Longman English Dictionary https://www.ldoceonline.com/

Tak więc generalnie status to ogląd obiektu z zewnątrz, stan to cecha obiektu. Innymi słowy moja choroba to mój stan, ale moja niezdolność do pracy to aktualny mój status (wynika on nie z choroby, a z ustalenia, że chorzy nie pracują, to nie to samo). Zapraszam do lektury.

Metody

W badaniu wykorzystano standardowe definicje i elementy notacji UML i SBVR, takie jak pojęcia obiektu, klasy obiektów oraz diagramy klas jako modele struktury i modele pojęciowe.

Maszyna stanowa

W specyfikacji notacji UML czytamy:

Pakiet State Machines definiuje zestaw pojęć, które mogą być użyte do modelowania dyskretnych zachowań sterowanych zdarzeniami przy użyciu formalizmu skończonych maszyn stanów. Oprócz wyrażania zachowania systemu (np. zachowania instancji klasyfikatora), maszyny stanów mogą również wyrażać zachowanie części systemu, maszyny stanów mogą być również użyte do wyrażenia prawidłowych sekwencji interakcji, zwanych protokołami. Te dwa rodzaje maszyn stanów nazywane są odpowiednio maszynami stanów zachowań oraz maszynami stanów protokołów. Specyficzna forma automatów stanów skończonych używana w UML-u jest oparta na wariancie formalizmu tablic stanów Davida Harela.

Ograniczenia użycia graficznego schematu maszyny stanowej opisał sam Harel, wskazano także na ograniczenia tej metody, między innymi złożoność tak wyrażanych schematów .

Poniżej przykład ww. autora konstrukcji stosowanych w C++:

Poniżej podobna w metodzie tworzenia konstrukcja ze specyfikacji UML:

Są to konstrukcje maszyny stanowej bazujące na skomplikowanych modelach matematycznych (nie będę ich tu przytaczał), ich ideą jest generalnie wyrażanie modelu działania obiektu wyłącznie tą jedną metodą: założeniu, że 100% zachowań obiektu to zmiana jego stanu jako reakcja na bodźce z otoczenia. Założenie to jednak ma wadę: nie każdy (system) da się opisać w całości jako taka maszyna stanowa. Po drugie podejście to często prowadzi do bardzo złożonych modeli, co powoduje, że ich użyteczność jako graficzna metoda zobrazowania i komunikowania jest znikoma zaś pracochłonność napisania odpowiadającego temu modelowi kodu jest także bardzo duża.

W specyfikacji UML znajdziemy jednak i takie przykłady maszyny stanowej:

Model pojęciowy

Kiedy i z czym mamy do czynienia? Kluczowe pojęcia:

automat: maszyna wykonująca czynność lub ciąg czynności bez udziału człowieka,

ale też:

automatyczny: działający samoczynnie, za pomocą odpowiedniego urządzenia, wykonywany lub powstający bez udziału świadomości i woli, będący nieuchronnym następstwem lub naturalną konsekwencją czegoś

maszyna: urządzenie zawierające mechanizm lub zespół współdziałających mechanizmów, służące do przetwarzania energii albo do wykonywania określonej pracy

mechanizm: zespół współpracujących ze sobą części maszyny lub przyrządu, wykonujących jakąś pracę, sposób, w jaki coś powstaje, przebiega lub działa, (patrz także )

stan: sytuacja, w której ktoś lub coś się znajduje

Podstawową różnicą między automatem a maszyną, jest więc “samoczynność” automatu (automatyzm jako samoistność reakcji na coś). Generalnie więc automatyzm to zachowanie się, maszyna to określony, nie raz złożony (działający) mechanizm.

Powiemy, że człowiek automatycznie reaguje krzykiem na ból, ale nie powiemy, że reaguje “maszynowo” lub “jak maszyna”. Z tego powodu, przyjmujemy, że automat to opis zachowania się, a maszyna to opis (model) konstrukcji (struktury) mechanizmu. Maszyna może zachowywać się jak automat .

Testowanie ontologii polega na sprawdzeniu syntaktycznej poprawności i prawdziwości zdań tworzonych z nazw (pojęć w modelu pojęciowym) z użyciem predykatów (związków zdaniotwórczych, w notacji SBVR nazywanych faktami):

• mechanizm realizuje automat (zachowania opisane automatem)
• automat opisuje zachowanie się maszyny (jej stany)
• maszyna przyjmuje określony stan
• automat przyjmuje określony stan
• maszyna implementuje mechanizm (projektowanie)
• mechanizm wyjaśnia działanie maszyny (analiza)

Automat to abstrakcja (model) opisująca “automatyczną” zmianę stanów czegoś (to tak zwana czarna skrzynka wg. BABoK). Mechanizm wyjaśnia jak do tych zmian stanu dochodzi (biała skrzynka wg. BABoK). Maszyna to realna konstrukcja lub jej projekt (model), realizująca opisany mechanizm działania. Stan to cecha zarówno maszyny jak i abstrakcji ją opisującej (automatu). Ciekawą, wartą lektury, historię stosowania pojęcia automatu w historii oraz automatycznego mechanizmu (jako czegoś działającego automatycznie) podaje Bedini .

Z powyższego wynika, że stan to cecha zarówno maszyny jak i automatu, jednak to maszyna jest bytem materialnym realizującym określony mechanizm działania . Skoro zaś stan to cecha i automatu i maszyny, to automat jest abstrakcyjnym (obserwacyjnym) opisem/modelem maszyny, opisującym jej zachowanie (reakcje). Często mówimy “automat stanowy” by podkreślić to, że jest to model zmian stanu maszyny, a nie model opisujący jej działanie (bo to opisuje mechanizm) , .

Powyższy diagram to model opisujący (wyjaśniający) mechanizm działania zegara, tu wyrażony w notacji UML. Jest to model mechanizmu działania Zegara, ale nie koniecznie detaliczny projekt konkretnego egzemplarza (typu). Poniżej, jedna z wielu możliwych implementacji: mechaniczna maszyna.

Zegar, zależnie od tego czy jest zasilany czy nie, może być w stanie: “pracuje” lub “nie pracuje”, co można wyrazić poniższym modelem: diagram UML Maszyny Stanowej (automatu stanowego):

Jednak powyższy model nie wyjaśnia tego jak działa zegar (i tego, że ma np. baterię i silniczek lub sprężynę). Pomysłem kuriozalnym (ale nie takim rzadkim) było by pokazanie stanów zegara jako kolejnych położeń wskazówek (lub treści tarczy zegara elektronicznego). Mam nadzieję, że czytelnik ma na tyle wyobraźni bym nie musiał tu tego rysować. Wtedy np. program komputerowy “Zegar” mógłby być automatem, wyświetlającym co minutę (lub co sekundę) kolejny statyczny obraz tarczy zegara:

Generalnie uznanie, że stan obiektu to aktualna wartość wszystkich jego cech, oraz próby zobrazowania tego metodami jak wyżej nie wnosi żadnej wartości w poznanie tego obiektu, gdyż:

Ciekawe jest to, że bardzo rzadko, powstaje potrzeba modelowania “stanu systemu” rozumianego jako aktualna, łączna wartości jego cech, gdyż wiele cech jednego systemu to cechy od siebie niezależne i ich aktualny łączny “stan” w zasadzie nie ma znaczenia. Zachowanie się systemu bardzo rzadko, o ile w ogóle, jest efektem aktualnej wartości wszystkich jego atrybutów. Tu niestety okazuje się, że znana z niektórych podręczników programowania definicja: stan obiektu to aktualna wartość jego atrybutów, nie oddaje prawdy. Popatrzmy np. na siebie: jednym z naszych atrybutów jest stan zdrowia a innym waga, obie te cechy mogą zmieniać wartość. Jakie ma znaczenie łączna wiedza ‘chory, 45 kg vs. ‘zdrowy, 45 kg’ czy ‘zdrowy, 48 kg’, itd?

Tak więc na pytanie czytelnika zadane we wstępie:

Chcę zamodelować dynamiczne zachowanie / stany smartfona (np. wyłączenie smartfona, inicjalizacja, tryb czuwania, użycie) w diagramie maszyny stanów SysML. Dla stanu użytkowania istnieją również podstany takie jak dzwonienie, latarka lub robienie zdjęć

Odpowiedź brzmi: takie modelowanie telefonu, z pomocą zagnieżdżonej “maszyny stanowej”, nie ma sensu, bo np. świecenie latarki nijak sie ma do stanu czuwania itp. I nawet gdyby powstał taki diagram, to na pewno niczego nie wyjaśni…

Czy można zastąpić diagram maszyny stanowej diagramem aktywności? Nie. Bo to zupełnie inny model (czytaj o diagram aktywności).

Rezultaty: kiedy modelujemy stan a kiedy status?

Powyższe opisy dotyczą systemów (system). Jednak oprogramowanie to nie tylko obserwacja i realizacja maszyny (parz: komputer jako uniwersalny mechanizm).

Oprogramowanie, szczególnie zwane biznesowym, to przetwarzane dane (a z perspektywy człowieka: informacje), co przekłada się także na dokumenty jako ich nośniki. Dane (informacje) zaś nie są maszyną! Maszyną może być (jest) system, które te dane przetwarza.

Kolejne pojęcia:

status: stan prawny jakiejś osoby, instytucji lub organizacji

cecha: (filoz.) niesamodzielny składnik rzeczy, dający się w niej wyróżnić tylko w drodze analizy myślowej

Kluczowe jest pytanie: co chcemy wiedzieć i kiedy, co chcemy zapisać i gdzie? Status dokumentu, sprawy, itp. rozumianego jako jego zachowanie? Dokument nie ma “zachowania”. Takie podejście (zachowanie się dokumentu) to mylenie stanu obiektu z klasyfikowaniem informacji (jego treści). Np. dokument może mieć status ‘w edycji’ lub ‘ukończony’, informacja w nim zawarta to nie stan dokumentu a treść i ewentualnie klasyfikacja jego treści. Np. faktura ma status w toku edycji, zapisana lub zaksięgowana, stan płatności nie jest cechą (treścią) faktury, to cecha salda. Faktura jako dokument nie zmieni swojej treści po jej opłaceniu. Gdzie to zapisujemy? W innym miejscu (obiekcie), najczęściej to repozytorium przechowuje informacje o stanie dokumentu, a nie sam dokument… 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 usta­wio­ny.

(parz: Problem z wzorcem State Machine czyli ile Cię kosztuje workflow – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

To dlatego, próby wdrażania obiegów dokumentów na bazie wzorca “maszyny stanowej” sprawiają ogromne kłopoty, lub po prostu się nie udają (klasyczny antyprzykład w artykule: Status ? informacja dla klienta czy dostawcy?).

Porównaj pojęcia wewnętrzny i zewnętrzny stan obiektu u Kirchhoff’a , które zgodnie z powyższym uważam za błędne. Wiele obiektów to obiekty “jednostanowe” czyli takie, które od momenty powstania nie zmieniają się , istnieją jednak ich zewnętrzne opisy. Typowy przykład to faktura:

Powyższy przykład to typowa sytuacja, w której stan faktury i jej status to dwa odrębne “byty informacyjne”: Faktura to jedynie jej treść (to dokument, którego od momentu wystawienia nie wolno już modyfikować). Biznesowy status faktury 9do zapłaty itd.) nie może być przechowywany jako treść tej faktury to ta od momentu wystawienia z zasady jest dokumentem “read only”. Dlatego biznesowe cechy faktury musi przechowywać poza nią, z reguły jest to zapis w księgach rachunkowych, gdyż “faktura nie wie, że jest opłacona”, wie to “księgowość”.

W konsekwencji widać, że nie da się opisać systemu ani jego logiki wyłącznie maszyną stanową. Zmiany statusów faktury (Biznesowy status faktury) to nie skutek zdarzeń (eventy) a określonych procedur (np. cykliczne sprawdzanie stanu rachunku bankowego) i reguł biznesowych (np. spełnienie warunku). Tu mogło by to być:

1. jeżeli nie jest Umorzona sprawdź wyciąg bankowy
   • jeżeli dokonano wpłaty ustaw status Zapłacona
   • jeżeli brak wpłaty i dzień płatności jest data przeszłą, ustaw Do windykacji
2. jeżeli status jest Do windykacji i zdecydowano o umorzeniu ustaw Umorzona

Mam tu dwie procedury wykonywane alternatywnie. W procedurze 1. nie musimy obsługiwać faktu “jeżeli brak wpłaty i dzień płatności jest data przyszłą pozostaw Do zapłaty”, bo ta procedura oznacza “nic nierobienie”.

Rozwiązanie problemu (architektura implementacji):

Komponent (obiekt) Repozytorium odpowiada za utrwalanie i dostęp do dokumentów, Obiekty klasy Formularz Faktury, przechowują dokumenty (a są nimi ciągi znaków). Status faktury nie jest treścią faktury (być moze jest to nawet podpisany elektronicznie nieedytowalny dokument), aktualny status tu jest przechowywany na “kopercie” (atrybut “status” obiektu klasy Faktura). Wartość tego statusu ustawia wyżej opisana procedura realizowana przez obiekt Logika biznesowa (metoda jej uruchamiania nie ma tu znaczenia, może to być realizowane cyklicznie raz na dobę).

Powyższe to jeden z wielu powodów, dla których metody takie jak “event storming” są bardzo nieskuteczne jako analiza i projektowanie logiki działania oprogramowania, szczególnie tak zwanego “biznesowego”.

Będzie c.d.

Źródła