Eksperymenty z diagramami stanu

Witam Wszystkich

Ostatnimi czasu wziąłem się za diagramy stanu jako jeden z elementów projektowania nieco większego systemu. Naturalnie mimo wielu publikacji na
ten temat zastanawiam się na ile wdrożenie danego systemu w fazie kodowania ukaże mi błędy i niedociągnięcia wynikające z fazy projektowej ?
Jeśli chciałby choćby na bazie gotowego systemu wprowadzić kilka własnych zmian nadal eksperymentując.
Chyba, że bardziej można stwierdzić, że te problemy wyjdą podczas samego użytkowania. Dla przykładu podać można system obiegu dokumentacji urzędowej
lub system biblioteczny.

Pozdrawiam

delform_17 napisał(a):

Ostatnimi czasu wziąłem się za diagramy stanu jako jeden z elementów projektowania nieco większego systemu. Naturalnie mimo wielu publikacji na
ten temat zastanawiam się na ile wdrożenie danego systemu w fazie kodowania ukaże mi błędy i niedociągnięcia wynikające z fazy projektowej ?

Im dłużej będzie trwała faza projektowa (im później kod zacznie powstawać), tym więcej błędów powstanie. Moim zdaniem najlepiej ją w ogóle pominąć.

Jeśli w fazie projektowej zostanie popełniony błąd/błędy, to one mają szanse na wykrycie dopiero kiedy powstaje kod. Im później się to stanie, tym mniejsza szansa że zostanie naprawiony. Jeśli błąd powstanie we wczesnej fazie projektowania, np. zostanie zbudowany na błędnym założeniu, to możliwe że większość projektu będzie się opierać na tym błędzie.

delform_17 napisał(a):

zastanawiam się na ile wdrożenie danego systemu w fazie kodowania ukaże mi błędy i niedociągnięcia wynikające z fazy projektowej ?

Zależy jak dobra będzie analiza i złożona domena biznesowa. My zawsze zaczynamy od analizy bo tego od nas wymagają przepisy i zazwyczaj logika kodu wychodzi jak w analizie ale czasem trafiają się niedociągnięcia. Wtedy poprawiamy i robimy dalej. Nie ma się co tym zbytnio przejmować

na ile wdrożenie danego systemu w fazie kodowania ukaże mi błędy i niedociągnięcia

Zależy, co rozumiesz przez "wdrożenie". Jeśli masz na myśli np. zastąpienie istniejącego krajowego systemu bibliotecznego (idąc twoim przykładem) nowym systemem w ciągu jednej chwili, no to raczej skończy się katastrofą. Ale możesz "wdrożyć" swój nowy system np. dla jednej szkolnej biblioteki w Polsce, i po miesiącu zobaczyć, jak sobie radzą.

markone_dev napisał(a):

Zależy jak dobra będzie analiza i złożona domena biznesowa. My zawsze zaczynamy od analizy bo tego od nas wymagają przepisy i zazwyczaj logika kodu wychodzi jak w analizie ale czasem trafiają się niedociągnięcia. Wtedy poprawiamy i robimy dalej. Nie ma się co tym zbytnio przejmować

Jeśli przepisy wymagają czegoś takiego, to i tak najlepszym sposobem zrobienia tej analizy jest napisanie aplikacji/prototypu.

1. Analiza (wymagana przepisowo) - zrób prototyp aplikacji, w której projektujesz wszystkie elementy, tak jak w fazie projektowej, tylko że z kodem. To ma sens działać. Jest to lepsze bo masz proof of concept, i jak popełnisz błąd, to widzisz to od razu.
2. Implementacja - teraz napisz aplikację jak chcesz, możesz od nowa, możesz się posiłkować fragmentami które już napisałeś.

ten temat zastanawiam się na ile wdrożenie danego systemu w fazie kodowania ukaże mi błędy i niedociągnięcia wynikające z fazy projektowej ?

Pamiętam projekt, który był oparty o maszynę stanu i w dokumentacji były wydumane rysunki, jak mają te stany przebiegać. I co? I gucio. Bo na poziomie implementacji były bugi, które powodowały pewnego rodzaju race conditions, tak że te stany nie zawsze były prawidłowe. Odpalały się po kilka razy, czy coś takiego.

Diagram stanu może zakładać pewną spójność i logikę w tych stanach, a w rzeczywistości mogą wystąpić bugi. I powodzenia w debugowaniu czegoś, co nie ma logiki w jednym miejscu.

Plus istnieje ryzyko, że diagramy stanu będą rysowane jak na studiach i proste interakcje będą celowo komplikowane, żeby wyszedł bardziej skomplikowany rysunek. Więc i implementacja będzie bardziej skomplikowana, jeśli będzie chciał człowiek zaimplementować 1:1 to, co widocznie na diagramie.

Nie znaczy to, że diagramy stanu są złe, tylko że są pewną idealizacją, która może się rozwalić podczas implementacji.

Ciężko taki "nieco większy system" umieścić na jednym diagramie stanów. W systemie bibliotecznym możesz modelować w ten sposób pojedyncze obiekty domenowe, jak książka, wypożyczający. Np. książka ma stany "na półce", "wypożyczona", "przeterminowana", "utracona", masz akcje typu "wypożyczenie", "zwrot" itp. i modelujesz sobie w którym stanie jakie akcje są możliwe i jak się kończą.
Podstawowy problem, to to, że po narysowaniu takiego diagramu stanów i zaimplementowaniu go posiadasz 2 miejsca, które mogą się różnić. Jeżeli pojawi się żądanie zmiany, albo błąd, to musisz za każdym, razem sprawdzić, czy błąd jest już na etapie analizy, czy już implementacji. Żądanie zmiany też powinno zmienić najpierw dokumentację, dopiero później kod. Moim zdaniem, ideałem byłoby gdyby dało się automatycznie generować kod na podstawie rysunku (np. jakiegoś diagramu zapisywanego w xml.
Granica pomiędzy przypadkiem kiedy nie należy tworzyć dokumentacji a takim, w którym dokumentacja jest konieczna jest bardzo płynna.

Riddle napisał(a):

markone_dev napisał(a):

Zależy jak dobra będzie analiza i złożona domena biznesowa. My zawsze zaczynamy od analizy bo tego od nas wymagają przepisy i zazwyczaj logika kodu wychodzi jak w analizie ale czasem trafiają się niedociągnięcia. Wtedy poprawiamy i robimy dalej. Nie ma się co tym zbytnio przejmować

Jeśli przepisy wymagają czegoś takiego, to i tak najlepszym sposobem zrobienia tej analizy jest napisanie aplikacji/prototypu.

1. Analiza (wymagana przepisowo) - zrób prototyp aplikacji, w której projektujesz wszystkie elementy, tak jak w fazie projektowej, tylko że z kodem. To ma sens działać. Jest to lepsze bo masz proof of concept, i jak popełnisz błąd, to widzisz to od razu.
2. Implementacja - teraz napisz aplikację jak chcesz, możesz od nowa, możesz się posiłkować fragmentami które już napisałeś.

Są pewne branże gdzie tak to nie działa z różnych względów na które przeciętny architekt/lead nie ma wpływu, więc daruję sobie dalszą dyskusję na ten temat.

Ostatnimi czasu wziąłem się za diagramy stanu jako jeden z elementów projektowania nieco większego systemu

Ten nieco większy system, to coś co jest przedmiotem umowy z klientem, czy to jest Twoja prywatna inicjatywa do portfolio/szuflady/kosza? Jeśli prywatnie coś tworzysz, to projekt dla jednoosobowego zespołu generuje raczej narzut niż wartość dodaną.

Jeśli z klientem, to umowa reguluje co ma być dostarczone i kiedy, np. "Projekt systemu". W takiej sytuacji diagramy stanu mogą być elementem dokumentacji projektowej, która będzie wykorzystywana przez innych interesariuszy, np. przez ekspertów domenowych do weryfikacji, czy cykl życia zamówienia faktycznie tak wygląda jak to zostało zilustrowania na diagramie. Daje to możliwość korekcji projektu, jeszcze zanim powstanie jakikolwiek kod.

Co modelujesz z wykorzystaniem diagramów stanu? Może są inne/lepsze sposoby prezentacji danego aspektu?

zastanawiam się na ile wdrożenie danego systemu w fazie kodowania ukaże mi błędy i niedociągnięcia wynikające z fazy projektowej ?

Co to znaczy 'wdrożenie systemu w fazie kodowanie'? Chodzi Ci, że masz jakaś instalację roboczą i tam dorzucasz inkrementalnie funkcjonalności w ramach dostarczania rozwiązania docelowego? Jeśli tak, to jest szansa, że takie niedociągnięcia wyjdą, ale raczej wynikające z implementacji, a nie projektu. Natomiast czy wyjdą, to będzie zależało np. od klienta i umowy, czy będziesz od tego klienta mógł wyegzekwować wcześniejsze sprawdzenie takiej "roboczej" funkcjonalności. Klient może powiedzieć, "zgodnie z umową ma być dostarczone tak i tak, nie planujemy wcześniejszych testów, ludzi są zajęci innymi sprawami". Umowa wymusi jakiś model pracy, tak, że możesz sobie wewnętrznie dłubać iteracyjnie, a klient i tak ma przewidziane np. testy integracyjne z +N miesięcy.

Moim zdaniem tworzenie projektu jest niezbędne w złożonych systemach. Jest to punkt odniesienia do różnych późniejszych dyskusji, n/t integracji, funkcjonalności, zarządzania zmianą. Piszę tu o złożonych systemach, gdzie np. masz nie tylko "swoje pudełko" do developmentu, ale i interakcje z dziesiątkami zewnętrznych systemów. Zespołom od tych zewnętrznych systemów przecież nie pokażesz swojego kodu, bo to ich nie interesuje.

Przez wdrożenie rozumiem ,,przekucie" takiego diagramu stanu we fragment aplikacji ,,ubranego" w GUI. Miałem w sumie na myśli mniejszą placówkę ew utworzenie
pewnej wtyczki usprawniającej. Naturalnie poszukiwanie nowych przykładów takich diagramów i traktowanie ich jako ćwiczeń dobra rzecz, ale
na dłuższą metę tego nie widzę więc zobaczmy jak maszyna to zrozumie.

Dlaczego to robię, wiec ani do szuflady ani do kosza, po prostu dla wprawy i praktyki oraz zamieszczania na portfolio.