Kilka dobrych praktyk dotyczących diagramów sekwencji

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.

najczesciej_stosowana_notacja_UML_2011_html_m44714f3

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.

najczesciej_stosowana_notacja_UML_2011_html_m54dd100c

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.

najczesciej_stosowana_notacja_UML_2011_html_m1f660c7b

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”.

najczesciej_stosowana_notacja_UML_2011_html_m30e9349

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.

image

Nagminne stosowanie wiadomości powrotu

Podobne wpisy
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

UML – zastosowanie w biznesie

Po raz kolejny Centrum Promocji Informatyki zorganizowało seminarium związane z wykorzystaniem języka UML w biznesie. W tym przedsięwzięciu miałem swój więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Reklama
MODESTO - licencje Enterprise Architect

2 komentarze dla “Kilka dobrych praktyk dotyczących diagramów sekwencji”

  1. 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.

    1. 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.

Dodawanie komentarzy zostało zablokowane.

Scroll to Top