Wprowadzenie

Od czasu do czasu dostaję emaile rozpoczynające się od słów: „A tu programista i pisze inaczej”. Tym razem dostałem od czytelnika link do tekstu Diagramy klas UML (https://www.p-programowanie.pl/uml/diagramy-klas-uml).

Artykuł ten w zasadzie w całości jest lawina nieprawdy o UML. Odniosę się do części dotyczącej notacji UML i powiązanych z nią fałszywych treści. Wszystkie cytaty pochodzą z ww. artykułu (inne oznaczono, źródłami).

Recenzja

Artykuł jest datowany na 30 września 2022. Aktualna wersja notacji UML 2.5.1 pochodzi z Grudnia 2017 roku, kluczowe zmiany: rezygnacja z podziału na Superstructure i Infrastructure, usunięcie pojęć dziedziczenia i agregacji to wer. 2.5.0 wydana w 2015 roku.

Język UML jest językiem służącym do graficznego modelowania aplikacji oraz systemów. Najczęściej wykorzystywany jest do modelowania diagramów klas.

Niestety nie. UML to notacja, kluczowe diagramy: diagram przypadków użycia, diagram komponentów, diagram klas, diagram sekwencji, diagram maszyny stanowej (patrz artykuł o ICONIX…).

Na diagramie UML nie da się zawrzeć wszystkich informacji o danej klasie. Gdyby tak było, wtedy diagramy klas byłyby graficzną reprezentacją kodu – a tak nie jest. Jeżeli w diagramie klas nie ma jakiegoś składnika, to nie można zakładać, że takowy nie istnieje w modelowanej aplikacji.

Jest to nieprawda. Istniejący kod można automatycznie odwzorować jako diagramu UML bo diagramy klas reprezentujące kod SĄ jego projektem lub odwzorowaniem. To, że na diagramie UML nie ma jakiegoś składnika kodu jest możliwe: implementacja często zawiera detale języka programowania, istotne dla tej implementacji ale nie istotne dla logiki jej działania (np. specyficzne dla danego języka typy danych).

Każdy obiekt reprezentowany jest przez jeden prostokąt, w którym zawarte są jego składniki. W prostokącie może znajdować się nazwa elementu, nazwa elementu wraz z polami bądź wszystkie składniki, czyli: nazwa, pola i metody.

W UML klasa to nazwa. Klasyfikator to „prostokąt” zawierający: nazwę, atrybuty, operacje. Metody to algorytmy i procedury, operacje to nazwa pozwalająca te procedury wywoływać. Atrybuty są opcjonalne.

Implementację interfejsu do danej klasy oznacza się pustym białym grotem strzałki, który znajduje się na końcu przerywanej linii.

Nie ma czegoś takiego w UML. Mamy związek generalizacji stosowany w modelach pojęciowych. Interfejs to po po prostu publiczne operacje klasy.

Powyższy rysunek: po lewej jest związek realizacji, po prawej dziedziczenie usunięte z UML w 2015 roku. Dziedziczenie nadal jest dostępne w tak zwanych obiektowo-zorientowanych językach programowania, jest to sposób na re-użycie kodu, bardzo szkodliwy z perspektywy architektury (np.: Inheritance Is Evil. Stop Using It).

Zależność oznacza „uzależnienie” bez podawania jego przyczyny. Nie ma „chwilowego używania”, jest „użycie” (wywoływanie operacji) i wtedy zależność ma postać:

Standardowa asocjacja to linia bez strzałek i oznacza ona wyłącznie „logiczny związek” na modelach pojęciowych. W postaci pokazanej u autora jest obecnie praktycznie niewykorzystywana.

Nie ma czegoś takiego jak „agregacja częściowa” była w UML „agregacja” (pusty rombik na końcu linii) i została usunięta z UML w 2015 roku. Nie ma czegoś takiego jak „agregacja całkowita”, jest kompozycja (związek całość-część). W UML od 2015 roku nie ma związku dziedziczenia.

Asocjacja pokazana tak:

oznacza tak zwaną widoczność: klasa Karol może wywoływać klasę Firma. Poprawna forma:

I jest to związek pojęciowy (słownikowy).

Dziedziczenie (ang. inheritance) jest głównym filarem paradygmatu programowania obiektowego.

Dziedziczenie jest antywzorcem i nie jest „filarem” paradygmatu obiektowego:

Na diagramie klas UML możemy umieścić także klasę zagnieżdżoną. Jej symbolem jest puste kółko z czarnym krzyżykiem.

Diagram należy czytać w następujący sposób: klasa Silnik jest zagnieżdżona w klasie Samochód.

Nie ma w UML pojęcia „zagnieżdżenie”, jest „zawieranie się” i jest to kompozycja. Poprawna konstrukcja:

Związek zawierania:

służy to łączenia elementy grupującego z elementami grupowanymi.

Podsumowanie

Niestety w sieci jest wiele podobnych tekstów pisanych przez koderów. Ich autorzy piszą nieprawdę wprowadzając swoich czytelników w błąd. Takie artykuły jak tu komentowany budują ogromną, niezasłużoną, niechęć do notacji UML.

Zapewne są konsekwencją cech języka programowania w jakim wyspecjalizował sie autor i dlatego często można spotkać określenie „myślnie kodem” wyjaśniające powstawanie takich artykułów. Jeżeli ktoś pisze i próbuje innych uczyć, to powinien sie skupić na tym co potrafi. Gdyby autor napisał artykuł o kodowaniu, zapewne byłoby ok. Niestety napisał artykuł o UML i modelowaniu, który to artykuł bardzo daleki jest od specyfikacji notacji UML i modelowania.

Autor nie podaje swoich danych ani źródeł tego co napisał: https://www.p-programowanie.pl/prawa-autorskie. To niestety częste na tego typu stronach z taką „wiedzą”.