Diagram sekwencji to niezastąpiona technika przy projektowaniu komunikacji pomiędzy klasami. Prezentacja kolejno następujących po sobie metod jest ważna nie tylko dla programistów. Dziś chciałbym podzielić się kilkoma wskazówkami.
Stosowanie na diagramach sekwencji tylko aktorów
Błędem, który czasem się zdarza, jest używanie na diagramach sekwencji tylko aktorów.
Sytuacja taka jest niepoprawna z tego względu, że aktorzy reprezentują otoczenie systemu, a diagram sekwencji służy do obrazowania zachowania systemu (w tym interakcji z jego otoczeniem).
Niestosowanie nowej notacji UML 2.0
Bardzo często analitycy są przyzwyczajeni do tradycyjnych rozwiązań (szablonów projektowych), które opanowali w trakcie nauki języka UML, i nie stosują nowoczesnych technik, które pozwalają na zwiększenie czytelności rozwiązania oraz ujednolicenie sposobu zapisu.
Przykładem może być poniższy diagram, na którym możliwość wyboru funkcji przez aktora została zapisana za pomocą kilku „starych” technik.
Stare przyzwyczajenia na diagramach sekwencji
W tym rozwiązaniu zastosowano notkę opisującą sytuację, której diagram sekwencji nie jest w stanie zaprezentować. Rozwiązanie to jest poprawne, ale mało wydajne. Kolejnym sposobem na ominięcie możliwości diagramów sekwencji jest zastosowanie opisu wraz z warunkiem.
Zastosowanie warunku w komunikacie
Powyższe rozwiązanie, choć poprawne, może wprowadzać w błąd, bo nic nie mówi o alternatywie sygnałów dotyczących edycji/ tworzenia pojazdu, a jedynie wskazuje na fakt, że wiadomość dodajNowyPojazd() może być wykonywana w sytuacji, gdy nie wybrano edytujPojazd(). Rozwiązanie to także jest obecnie nieefektywne.
Na poniższym diagramie wskazano poprawne rozwiązanie prezentowanej sytuacji, bazujące na elemencie „fragment”.
Zastosowanie fragmentu z alternatywą (alt)
Nagminne stosowanie wiadomości powrotu
Niepoprawne z punktu widzenia czytelności diagramu jest nagminne stosowanie linii powrotu komunikatu (return, wiadomość zwrotna, odpowiedź). Błąd polega na tym, że nie w każdej sytuacji można taką linię zastosować, gdyż w przypadku, w którym odpowiedź następuje natychmiast, możemy linię/komunikat pominąć. Taki zabieg zwiększa stopień czytelności diagramu.
W omawianym przykładzie, na poniższym rysunku można pominąć komunikaty powrotu z klas encyjnych, gdyż niejako z góry wiadomo, że po zapytaniu skierowanym do bazy danych nastąpi zwrot informacji. Po tym zabiegu diagram będzie bardziej czytelny.
Nagminne stosowanie wiadomości powrotu
Mam pytanie odnośnie diagramu sekwencji.
Chodzi o sytuację w której korzystam z fragmentu typu alt i mam 3 ścieżki alternatywne. Jedna oznacza koniec sekwencji, druga prowadzi do następnych komunikatów a trzecia nakazuje wrócić do początku sekwencji i rozpoczęcie nadawania komunikatów od nowa.
No i o ile dwie pierwsze ścieżki są łatwe do zobrazowania to zupełnie nie wiem jak się zabrać za trzecią. W UML-u diagram sekwencji nie zdefiniowano opcji „powrotu”, ponieważ jest to sekwencja komunikatów w czasie, więc teoretycznie nie można wracać do tego co już było (linia życia), jednak jestem pewien, że na pewno istnieje jakieś rozwiązanie dla takiej sytuacji jaką tu zaprezentowałem.
bardzo proszę o pomoc.
Tak z opisu, nie widząc diagramu, to widzę jedno rozwiązania. Komunikat, który „wzbudza” ponownie sekwencję należy podłączyć do endpoint i dodać notkę iż ten endpoint uruchamia ponownie sekwencję komunikatów.