Diagram sytemu produkcyjnego

Witam Panowie

Ostatnio projektuje mały system wspierający procesy produkcyjne a przede wszystkim konserwacje maszyn i wydajność tworzenia i ułożyłem do tego pewne diagramy.
Dodatkowe możliwości systemu mają opierać się na IoT i czujnikach aczkolwiek głównie chodzi o przewidywanie i utrzymanie ruchu. Zdaje sobie sprawę, że o pewnych rzeczach mogłem tutaj zapomnieć, a inne tez pewnie źle wstawić.

Dodatkowo od każdej funkcji w klasie tworze osobny przypadek użycia. Z tego co pamiętam jest to niezbędne. Wyprzedzając ew pytania system w formie dodatkowego oprogramowania tworzę jako rozszerzone możliwości tego co dają firmom polskim inni producenci softu.

Mam nadzieje, że diagramy wyglądają przejrzyście. Liczyłbym na subiektywną ocenę błędów i sugestie.

Ja to bym odpuścił sobie robienie diagramów klas i przypadków użycia. Szybko się dezaktualizują, są skomplikowane i chaotyczne. Twój diagram to w sumie taka hybryda obu. Nie mówiąc o polach i metodach prywatnych (jak mnie pamięć nie myli, oznaczane minusem), takie szczegóły implementacyjne mogą się zmienić z dnia na dzień, komu będzie się chciało je poprawiać? Nie mówiąc o tym, że jeśli już są koniecznie potrzebne żeby dopełnić papierologii, możesz wygenerować je z kodu i nawet zautomatyzować odświeżanie dokumentacji po zbudowaniu aplikacji.

Ostatni raz diagram klas widziałem gdzieś w 2019 i już wtedy wszyscy robili wielkie oczy, po co on jest właściwie potrzebny, skoro nie wnosi niczego względem spojrzenia w kod źródłowy.

Diagram przypadków użycia ostatnio widziałem chyba na studiach kilka lat wcześniej.

Jeśli chcesz opisać system, który projektujesz, to patrzyłbym raczej w stronę

• diagramu komponentów, żeby opisać strukturę
• diagramów sekwencji, żeby opisać jak realizowane są różne procesy
• może aktywności / stanów, by opisać przejścia między stanami systemu lub jego możliwości
• ewentualnie diagramy sieciowe, jeśli jest tu istotna topologia sieci, rozłożenia firewalli, etc.

Wszystko to co mówi @superdurszlak . Diagram komponentów najbardziej użyteczny. Zwłaszcza jak twoje oprogramowanie będzie łączyć się z zewnętrznymi systemami urządzeniami. To jest najważniejsze . Co do reszty to sekwencji też był dla mnie użyteczny jaki jest przepływ sterowania w najważniejszych procesach. Pamiętam że mój poprzedni architekt próbował diagramy sekwencji też generować z kodu z różnym skutkiem.

Co do tego diagramy klas:

• kod pa polsku XD
• czasem pola są camelCase a czasem snake_case, to zamierzone?
• czasem metody są camelCase a czasem PascalCase jak w C#, to zamierzone?
• operation()? czy to ważna funkcja biznesowa że umieszczasz ją w diagramie?

Jeśli w tej chwili system to 6 klas to prawdę mówiąc nie ma za dużo co dokumentować

Najpierw daj kontekst po co w ogóle robisz takie diagramy i kto jest odbiorcą.

Dodatkowo od każdej funkcji w klasie tworze osobny przypadek użycia. Z tego co pamiętam jest to niezbędne.

Dlaczego?

@superdurszlak Zdaje sobie sprawę, że ISI zmienia się tak samo dynamicznie jak przybywa nowych biblioteka dla Native'a np, ale żeby diagramy klas, które jak dla mnie modelują teoretycznie jak ma wygląda software, jakie mają być interakcje, jakie funkcje są istotne, a które nie. Potem tworząc przypadki użycia podczas procesu tworzenia zdajemy sobie sprawę najwyżej ,,fakt ten element nic tu nie wnosi". Mnie tez uczono na studiach projektowania w ten sposób, bo nie wyobrażam sobie od razu siadania do kodu mając tylko rozpisany algorytm.

Same firmy deklarują nawet 10% czasu przeznaczone na przygotowanie dokumentacji. To co robię to jest tylko rozszerzenie działa systemu, aby go bardziej zoptymalizować zaprzęgając do pracy również czujniki. Po to np aby serwisant nie musiał dostawać telefonów coś nie działa lub łożysko zaczyna hałasować.

Choć dopiero modeluąc to w takie formie zdałem sobie sprawę iż jest to nieco trudniejsze niżeli myślałem.
Notabene w początkowej fazie skupilibyście się na funkcjonowaniu tego systemu w praktyce później po testach wdrażając szatę graficzną mając na myśli tryb tekstowy czy lepiej te oba aspekty połączyć? ;)

Na koniec wypowiedzi dodam, że dzięki za podpowiedź, bo akurat jestem w trakcie laboratorium z maszyny stanu ;)

delform_17 napisał(a):

@superdurszlak Zdaje sobie sprawę, że ISI zmienia się tak samo dynamicznie jak przybywa nowych biblioteka dla Native'a np, ale żeby diagramy klas, które jak dla mnie modelują teoretycznie jak ma wygląda software, jakie mają być interakcje, jakie funkcje są istotne, a które nie. Potem tworząc przypadki użycia podczas procesu tworzenia zdajemy sobie sprawę najwyżej ,,fakt ten element nic tu nie wnosi". Mnie tez uczono na studiach projektowania w ten sposób, bo nie wyobrażam sobie od razu siadania do kodu mając tylko rozpisany algorytm.

Wczesne lata 2000. i odwzorowywanie kodu, który będzie napisany, w ścisłych szczegółach na diagramie, najlepiej w jakimś UMLowym diagramie klas. To podejście nie przetrwało próby czasu, bo IMO jest marnotrawstwem ograniczonych zasobów.

Ten sam czas mógłbyś poświęcić na faktyczne projektowanie interakcji w systemie, implementację protypu / MVP, analizy wydajności czy threat modelling, a zamiast tego nanosisz na diagram wywołania metod i interakcje pomiędzy klasami. Na diagramie klas to będzie wyglądać pięknie, a potem zaczniesz to implementować i dojdziesz do wniosku, że kod jest nieintuicyjny i chciałbyś go zrefaktorować - wrócisz do przerysowywania diagramów? Mi by sę nie chciało.

Jeśli koniecznie chcesz mieć diagramy klas do dokumentacji, dlaczego nie zrobisz podejścia code-first i automatyzacji? Pluginy do IDE (np. Jetbrains) to potrafią, jakieś narzędzia standalone z pewnością też.

Z ciekawych sposobów opisu architektury systemu, może Cię jeszcze zainteresować model C4 lub pokrewne, gdzie dosyć wyraźnie rozdziela się opis systemu na poszczególne warstwy abstrakcji. W dyskusji nad wdrożeniem systemu na faktyczne serwery lub do chmury, lub przy analizowaniu topologii sieci gwarantuję, że nikogo (Ciebie też) nie będzie interesowało, jakie są klasy w projekcie i jakie mają metody, ani co kogo wywołuje.

Robiąc diagram sekwencyjny również opisujesz albo np. działanie jakiegoś algorytmu, albo jakieś złożone interakcje między dwoma i więcej serwerami, ale raczej unikasz robienia obu naraz, bo to zaciemnia obraz i utrudnia analizę. Robisz na diagramie odniesienie "a tu jest procedura X na serwerze Y" i potem robisz diagram dla procedury X na serwerze Y.

A, i jeszcze jedna rzecz. Wartość diagramu wynika z możliwości opisania systemu w sposób zrozumiały bez znajomości wszystkich szczegółów i pełnego kontekstu, oraz z tego na ile jest aktualny. Diagram który w najdrobniejszym szczególe opisuje, jak system jest zbudowany będzie miał dyskusyjną wartość, bo zaciemnia obraz rzeczywistości, a z biegiem czasu szybko się zdezaktualizuje i będzie miał wartość ujemną - bo albo ktoś będzie tracił czas na ciągłe nanoszenie zmian, albo diagram który "opisuje" system będzie po prostu wprowadzał w błąd i podawał nieprawdę. Po co?