Niedawno cytowałem tu pewnego profesora:

Drodzy Młodzi Przyjaciele. Czuję się w obowiązku zwierzyć się Wam z bardzo przykrej tajemnicy. Nie jesteście ? większość z Was ? dobrze wykształceni, a jedynie tak Wam się wydaje. Zostaliście oszukani najpierw przez nauczycieli, a potem przez wykładowców ? wyznaje Jan Stanek, profesor fizyki z Uniwersytetu Jagiellońskiego. (za  Wiedza po studiach? ).

i cóż, niestety chyba ma rację. Ten artykuł jest moim subiektywnym odczuciem, jednak starałem się wskazać na źródła mojego „sprzeciwu”.

Regularnie jestem proszony przez studentów o korepetycje z zakresu analizy i modelowania obiektowego, czasem także modelowania procesów biznesowych. Wspólną ich cechą jest to, że analiza obiektowa i UML to „ostatnie kilka ich zajęć na szybko”, a mowa o kierunkach informatyka, analiza i projektowanie itp. Ktoś taki na rynku pracy w dużych i trudnych projektach jest „szkodnikiem”, bo jak zauważył wyżej cytowany profesor, człowiek taki z pełnym przekonaniem, że coś dobrze robi, po protu szkodzi.

Do napisania tego artykułu „zmusiła” mnie kolejna przygoda z korepetycjami, w której tym razem dostałem od studenta pełną treść zadania wraz ze wskazówkami. Nie będę pisał o jaką uczelnię chodzi i kim jest tenże wykładowca bo nie jest moim celem krytyka osoby czy uczelni. To co pisze, wydaje mi się, jest zjawiskiem powszechnym (w miarę czasu jakim dysponuje, udzielam często korepetycji studentom różnych uczelni).

Zadanie i zalecenia

(kursywą wskazówki, wymagania wykładowcy)

Należy utworzyć model informacyjny systemu – diagram klas. Problem w tym, że w analizie obiektowej nie używa się pojęcia „model informacyjny”. Jest to pojęcie z obszaru relacyjnego modelowania danych i analizy systemowej. Diagram klas to albo model pojęciowy (słownikowy) albo model struktury kodu oprogramowania: byty mające atrybuty i operacje (umiejętności).

Każdy z atrybutów musi mieć ustalony typ danych. To jest zadanie na etapie implementacji a nie analizy obiektowej i projektowania logiki systemu. typy danych to praca dla programisty. Typy danych to pojęcia z obszaru programowania, są (nieco) różne w różnych językach programowania. Przymus ich deklarowania już na etapie analizy i projektowania, czyli przed wyborem technologii, jest dla mnie kuriozalny. Jeżeli „wykładowca” ma taki styl pracy jako „analityk” to jest źle, że przenosi to na zajęcia ze studentami, bo studentów należy uczy klasyki i standardów a nie prywatnej metody pracy. Owszem, należy powiedzieć, że np. nazwisko może składać się wyłącznie z liter, gdzie pierwsza jest duża a reszta małe ale to informacja dla programisty a nie „typ danych”.  Poza tym takie reguły zapisu nazwisk można implementować na więcej niż jeden sposób.

Klasy na tym etapie nie mają zdefiniowanych operacji. Klasa w UML to: nazwa, atrybuty i operacje(!). W literaturze przedmiotu wręcz twierdzi się, że na wstępnym etapie analizy i projektowania obiektowego operuje się interfejsami czyli właśnie „tylko” nazwą i listą operacji klasy. Operacja to bardzo ważny element modelu bo zawiera realizowaną w niej logikę (np. biznesową). Poziom abstrakcji modelu nie ma tu żadnego znaczenia, bo jeżeli obiekt faktura „liczy VAT” to gdzieś to, jak należy ten VAT wyliczać, należy w projekcie „umieścić”, np. w operacji „wyliczVAT”. Tak więc „diagram klas bez operacji” to klasyczny antywzorzec obiektowy o wdzięcznej nazwie „anemiczny model dziedziny”, powody są proste (wytłuszczenie):

Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób. (za Antywzorzec projektowy ? Wikipedia, wolna encyklopedia).

Dodam też, że EJB to technologia z lat 90-tych (od której się już odchodzi, jako środowisko została już tylko JEE z zachowaniem kompatybilności wstecz, więc istnienie JavaBeans’ów nie znaczy, że nadal są sexi)…

Wszystkie asocjacje muszą mieć liczności i nazwy ról. Po pierwsze związki logiczne to nie tylko asocjacje, bo mogą być także związki „użycia”. Nazwy ról to anachronizm rodem z modeli ERD (modele danych relacyjne), pomaga czasem na diagramach ale raczej wtedy gdy obiekty, ich nazwy oraz operacje „są niejasne”, ale to raczej mówi o tym, że model jest kiepski.  To, że notacja UML ma dziesiątki „fajnych rzeczy” nie znaczy, że należy użyć wszystkich,  umieszczamy na modelach „to o czym wiemy i chcemy powiedzieć” a nie „wszystko”.

Przypadki użycia: dla każdego z aktorów musi być odrębny diagram przypadków użycia. Nie mam pojęcia co jest powodem takiej nadmiarowości dokumentu. ponad to, takie podejście „ukrywa” fakt, że wiele przypadków użycia może być skojarzonych z tym samym aktorem.

Przypadki użycia:  należy stworzyć osobny diagram pokazujący hierarchię dziedziczenia aktorów. Plączą się „poradniki” opisujące stosowanie dziedziczenie pomiędzy aktorami, jednak to kuriozum raczej nie da się obronić. Aktorzy to byty rzeczywiste (konkretne role czy osoby lub zewnętrzne systemy). Budowanie abstrakcji czyli super aktora, po którym inny dziedziczy jest nieuzasadnione, opisywanie tą metodą „dziedziczenia uprawnień” jest dla mnie, i nie tylko kolejnym kuriozum, bo niestety prawa dostępu nie są dziedziczone (nie licząc może szablonów i grup, ale szablon to nie aktor) a są nadawane indywidualnie. Kiepskim pomysłem jest układ, który spotkałem na diagramie „pracy która zaliczyła”: Administrator dziedziczy po Użytkowniku. W bezpiecznym systemie Administrator nie powinien być „bogiem” tylko Administratorem, więc nie może mieć praw do wszystkich danych i operacji, do których ma dostęp Użytkownik Systemu, którym ten Administrator administruje. No i po co osobny diagram?

Przypadki użycia: dla każdego diagram aktywności z trzema partycjami: Aktor, warstwa prezentacji, warstwa logiki. Takie kuriozum plącze się w kilku poradnikach ale po pierwsze „warstwa logiki” i tak nie zastąpi nam tu diagramu sekwencji i modelu dziedziny (te diagramy raczej i tak muszą powstać), a jego wartość dodana jest moim zdaniem zerowa bo nie dość, że jest to nadmiarowy dokument (pamiętamy, że diagram sekwencji i tak powstanie) to nie da się na diagramie aktywności pokazać wewnętrznej logiki systemu inaczej niż abstrakcji pod tytułem „System” czyli tego co i tak jest na diagramie przypadków użycia.

Na zakończenie

Powyższe to tylko przykład „zadania dla studenta”, takich „zadań” i ich zaliczeń znam multum. Ktoś tak „wykształcony” pojawia się na rynku pracy i ma pretensje, że ma kłopoty ze znalezieniem pracy albo na podstawie dyplomu prestiżowej uczelni zostaje zatrudniony, i sieje spustoszenie w projektach nie raz ogromnej wartości.  Jest nie raz gorzej, bo buduje stereotyp „nieprzydatnej i kosztownej pracy analityka”. Powyższy przykład to praca wykładowcy na prestiżowej w naszym kraju uczelni na kierunku Analiza Biznesowa.