Obsługiwanie stanu aplikacji za pomocą automatu skończonego

Robimy z kumplem w robocie aplikację opartą o automat skończony i wydaje się to nam dużo lepszym rozwiązaniem niż goły MVC z klejeniem handlerów i eventów na 100 mln różnych sposobów. Aplikacja jest w zasadzie desktopowa (kiosk mode), trudności sprawia nam zamodelowanie wywołań asynchronicznych w maszynie stanów, jak i np osobnych wątków liczących/ komunikujących się ze światem zewnętrzny żyjących trochę własnym życiem.

Czy ktoś robił aplikacje, szczególnie chodzi o aplikacje z GUI, oparte na automatach skończonych? Jeśli tak to proszę o jakąś sprawdzoną literaturę.

Wywołania synchroniczne i asynchroniczne możesz po prostu zaimplementować przez message passing : najpierw implemetujesz mechanizm przekazywania wiadomości a dopiero potem dopiero FSM. Tak to np. było zrobione w sofcie sterującym BTSami.
Nawiasem mówiąc jeżeli możesz uniknąć FSM to lepiej zastosuj co innego bo FSM są bardzo nieczytelne zwłaszcza jeżeli ktoś nie zna diagramu przejść. Są nawet obfuskatory kodu, których główną techniką obfuskacji jest stosowanie maszyny stanów...

Nawiasem mówiąc jeżeli możesz uniknąć FSM to lepiej zastosuj co innego bo FSM są bardzo nieczytelne zwłaszcza jeżeli ktoś nie zna diagramu przejść.

???
Dla przykładu mam stan OczekiwanieNaPłatność, który pod wpływem eventu WpłaconoPieniądze przechodzi do stanu DziękujemyZaPłatność. Co w tym nieczytelnego? U nasz zastosowanie FSM zwiększyło czytelność kodu.

Wywołania synchroniczne i asynchroniczne możesz po prostu zaimplementować przez message passing : najpierw implemetujesz mechanizm przekazywania wiadomości a dopiero potem dopiero FSM.

U nas te osobne wątki mają referencję do zarządcy maszyny stanów i wysyłają mu eventy. Nie chodzi mi o mechanizmy przesyłania eventów tylko sam sposób modelowania asynchronicznych żądań czy zdarzeń z osobnych wątków w maszynie stanów.

Dla przykładu mam stan OczekiwanieNaPłatność, który pod wpływem eventu WpłaconoPieniądze przechodzi do stanu DziękujemyZaPłatność. Co w tym nieczytelnego? U nasz zastosowanie FSM zwiększyło czytelność kodu.

Jak masz 2 stany i jedno przejście to faktycznie nie ma tu nic skomplikowanego. Z drugiej strony po co niby robić maszynę stanu do tak prostej sytuacji?

U nas te osobne wątki mają referencję do zarządcy maszyny stanów i wysyłają mu eventy. Nie chodzi mi o mechanizmy przesyłania eventów tylko sam sposób modelowania asynchronicznych żądań czy zdarzeń z osobnych wątków w maszynie stanów.

Asynchroniczny FSM pozwala na zajście wielu zdarzeń równolegle, przy czym, jeżeli obiekt A wysyła żądanie zmiany stanu do B to obiekt A nie musi czekać aż obiekt B skończy zmieniać swój stan - to jest właśnie asynchronizm. Do modelowania takich sytuacji wykorzystuje się message passing
A teraz podaj swoją definicję asynchronicznego FSM bo widzę, że masz jakąś zupełnie inną.

Jak masz 2 stany i jedno przejście to faktycznie nie ma tu nic skomplikowanego. Z drugiej strony po co niby robić maszynę stanu do tak prostej sytuacji?

W gołym MVC tak czy siak modeluje się pewne stany i przejścia między nimi. Przy zaprojektowaniu FSM te stany stają się explicite (można je ładnie i czytelnie nazwać) i ich zarządzanie może zostać scentralizowane i zupełnie odcięte od widoku. Mając FSM można do niej podpiąć tyle widoków naraz ile się chce.

edit:
No i stanów jest wiele u nas, ze ze dwadzieścia co najmniej.

Asynchroniczny FSM pozwala na zajście wielu zdarzeń równolegle, przy czym, jeżeli obiekt A wysyła żądanie zmiany stanu do B to obiekt A nie musi czekać aż obiekt B skończy zmieniać swój stan - to jest właśnie asynchronizm. Do modelowania takich sytuacji wykorzystuje się message passing
A teraz podaj swoją definicję asynchronicznego FSM bo widzę, że masz jakąś zupełnie inną.

Napisałeś wywołania asynchroniczne, czyli to jest mniej więcej coś jak event dla mnie na pierwszy rzut oka. Skoro masz gdzieś opis asynchronicznego FSM to podaj, z chęcią skorzystam.

Definicje asynchroniczności przy FSM masz chociażby tutaj: http://smi.web.cern.ch/smi/smi_3.html#chapter_3
Ale to tylko definicja, dalej nie wiem co chciałeś osiągnąć pisząc, że masz problem z asynchronicznością.

Dwa przypadki na razie:

1. Podpowiedzi przy wpisywaniu. Tu jest szereg problemów, np zarządzanie żądaniami do serwera tak aby było co najwyżej jedno żądanie, ogólnie trzeba zrobić dobrze działające podpowiadanie.
2. Osobny wątek sprawdzający status zewnętrznego urządzenia i wysyłający do maszyny stanów zdarzenia zmieniające stan (co pociąga za sobą zmianę widoku).

Generalnie mamy rozwiązane już te nasze problemy, ale chcę się dowiedzieć jak to zrobić lepiej, tzn poszukuję literatury/ opinii/ etc ludzi, którzy już mają doświadczenie z opieraniem aplikacji o maszyny stanów i mają już intuicję jak sobie radzić z problemami w sposób elastyczny i uogólniony.

Lektura pod linkiem wydaje się ciekawa na pierwszy rzut oka. Dzięki za ten link.

Stany gmatwają program. Zwielokrotniają każdy krok decyzyjny.
Chyba że zamykasz je we wzorcu projektowym - wtedy to zupełnie inna bajka:

http://www.codeproject.com/Articles/38962/State-Design-Pattern

Generalnie MVC oparte o zdarzenia jest fajne, kiedyś musiałem dla bardziej skomplikowanego przypadku trochę je rozbudować w Delphi (priorytety, lokalne kolejki, przeszukiwanie kolejki zdarzeń), ale w kiosku raczej nie powinieneś mieć takich potrzeb.

Stany gmatwają program. Zwielokrotniają każdy krok decyzyjny.

Tzn?

Do Ruby jest np http://rubygems.org/gems/state_machine (700k pobrań) i z tego co czytałem ludzie sobie to chwalą.