Blog: Modelowanie procesow i architektura systemow | Uml

Dobre praktyki tworzenia diagramów UML

Dobre praktyki tworzenia diagramów UML
  • 1 847 views

Modelowanie z wykorzystaniem UML powinno przyczynić się do lepszego zrozumienia problemu lub dziedziny rozwiązania, a także wspierać komunikację w zespole projektowym. Diagram jako wizualizacja modelu jest głównym środkiem komunikacji w UML. Oto kilka wskazówek jak tworzyć diagramy, aby dobrze pełniły swoją rolę, czyli były łatwe do czytania i rozumienia.

Udostępnij!

Modelowanie systemu – dla kogo i po co?

W 1956 r. amerykański psycholog George Miller stwierdził, że liczba obiektów, którą człowiek może przechowywać w swojej pamięci „operacyjnej” wynosi 7 ± 2. Oznacza to, że nasze możliwości percepcyjne są dość ograniczone. Dlatego zamiast bombardować interesariuszy ogromnymi diagramami z mnóstwem szczegółów, zastanówmy się najpierw dla kogo tworzony jest diagram i w jakim celu. Jaki aspekt modelowanego systemu ma prezentować? Spróbujmy umieścić na diagramie tylko elementy kluczowe dla określonego aspektu, celu, odbiorcy.

Korzystajmy z dekompozycji lub grupowania elementów za pomocą hierarchii pakietów, aby wydzielić diagramy bardziej ogólne (przeglądowe, streszczające) i bardziej szczegółowe.

W ostateczności możemy podzielić obszerny diagram na kilka mniejszych i umieścić na każdym z nich odwołania do pozostałych.

Powinniśmy zmieścić się formacie A4. Wydaje się, że to rozsądne ograniczenie wielkości diagramu.

Cel diagramu wyznacza również jego poziom szczegółowości. Zbyt wiele szczegółowo zdefiniowanych właściwości nie pozwoli czytelnikowi skoncentrować się na istocie zagadnienia, a i tak te definicje mogą się zmienić w ostatecznej implementacji. Zatem, o ile szczegółowe definicje nie są wymagane, to po prostu ich nie pokazujmy lub wręcz ich nie twórzmy. Powszechną praktyką jest:

  • Prezentacja diagramów bez szczegółowych specyfikacji elementów, ale z uwzględnieniem relacji pomiędzy nimi.
  • Nieumieszczanie na diagramach elementów oczywistych np. metod dostępowych w definicji klasy.
  • Nieumieszczanie na diagramach elementów, które mogą być wygenerowane automatycznie np. konstruktorów.
  • Nieumieszczanie elementów niezależnych od dziedziny problemu, a zależnych od implementacji.

Dobry diagram, to przemyślany diagram.

Ukośne linie i chaotycznie rozrzucone elementy powodują, że diagram wydaje się być niedopracowany. Natomiast uporządkowany diagram jest bardziej czytelny i sprawia wrażenie przemyślanego.

Najprostszym sposobem uporządkowania diagramu jest umieszczenie jego elementów poziomo lub pionowo oraz pionowe lub poziome poprowadzenie linii powiązań i załamywanie ich pod kątem prostym.

Ponadto w miarę możliwości postarajmy się aby:

  • elementy diagramu były rozmieszczone równomiernie przy zachowaniu pewnej symetrii,
  • były wyrównane w pionie i poziomie,
  • miały jednakowy rozmiar,
  • linie na diagramach nie przecinały się,
  • relacje generalizacji i realizacji były ułożone pionowo, a klasy potomne i implementujące znajdowały się poniżej nadklas i interfejsów,
  • wspólne relacje wielu elementów z tym samym elementem były pogrupowane w drzewa,
  • w przypadku, gdy istotna jest kolejność elementów (np. w aktywnościach)  diagramy były zorganizowane z góry na dół lub od lewej do prawej strony.

Nazwy i wygląd mają znaczenie

Co prawda kolory nie są elementem modelu, ale warto rozważyć ich stosowanie. Kolor może być przypisany do typu elementu, perspektywy, określonego statusu czy osoby odpowiedzialnej za implementacje. Przy pomocy kolorów możemy odróżniać elementy standardowe i ich stereotypy. Należy pamiętać, że jeśli zdecydujemy się na stosowanie kolorów niezbędna będzie też ich legenda.

Sposób nadawania nazw ma istotne znaczenie dla zrozumienia diagramu. Powinniśmy używać terminologii charakterystycznej dla dziedziny rozwiązania, ograniczając stosowanie programistycznych konwencji nazewniczych do diagramów implementacyjnych. Niezależnie od przyjętej konwencji ważne jest jej konsekwentne stosowanie.

Jeśli jesteśmy przy nazwach i innych tekstowych specyfikacjach, dobrze jest z góry ustalić rozmiar i rodzaj czcionki uwzględniając np. konieczność skalowania diagramu. Powszechnie uważa się, że czcionka o rozmiarze mniejszym niż 8 pkt jest nieczytelna.

Przedstawione powyżej wskazówki ułatwiają tworzenie diagramów UML „w dobrym stylu”. Oczywiście treść jest ważniejsza niż forma. Uporządkowane i przejrzyste diagramy nie uczynią naszych modeli lepszymi, ale sprawią, że ich odbiorcy nie będą musieli się zastanawiać nad tym, co autor miał na myśli i zamiast wyjaśniać sam diagram, będą mogli szybko przejść do dyskusji nad jego merytoryczną zawartością.