Clip Art Gallery created by Mark A. Hicks, illustrator.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.

 

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 10 komentarzy

  1. jacek2v

    “Nie jesteście ? większość z Was ? dobrze wykształceni”
    Chyba nie tak. Najpier trzeba sobie postawić pytanie co to znaczy dobrze wykształceni? Jaki jest prawdziwy cel szkolnictwa? 🙂
    “Zostaliście oszukani…”
    To na pewno, a może bardzie sami się oszukujemy 🙂

    A co do zadań i zaleceń wykładowcy to całkowicie się zgadzam, są kuriozalne 🙂

    1. Jarek Żeliński

      w kwestii “zostaliście oszukani” polegam na opinii Pana profesora :))). Program tych zajęć firmuje pewna “znana” firma doradcza…jej pracownik je prowadzi… to tylko dodaje pikanterii całej sprawie…

    2. jacek

      A może “dobrze wykształceni” ma znaczyć “dobrze opłaceni” w sensie, że celem uczelni jest pobieranie czesnego od studentów?

  2. Jacek

    Ej tam, czepiacie się.
    Jaka szkoła, taka wiedza. Jacy rodzice, takie dzieci.
    Jedyny sposób na takich “specjalistuff” to EDUKACJA.
    Wokół mamy pod dostatkiem antywzorców i musimy sobie z nimi radzić, czemu w analityce miałoby być inaczej?

    1. Jarek Żeliński

      i chyba masz rację…:(, szkoda tylko, że “Klienci” muszą się tego uczyć na własny koszt… choć niektórym chyba to potrzebne…. ja też wiem, która piekarnia ma zły chleb po tym jak go zjem…

    2. jacek2v

      Może się czepiam :), ale brak myślenia – u uczących się i tych co uczą – zwłaszcza w edukacji to chyba coś NIE TAK :D?
      A czemu w edukacji miałoby być inaczej niż np. przy kopaniu rowów? Jeśli ktoś ma zadanie wykopać rów pod instalację, a robi to źle to jest to tak samo złe wykonie jak nauczenie kogoś robienia złej analizy.
      Różnica taka, że przy kopaniu rowów łatwiej ocenić jakość, niż przy edukacji oraz rów ocenia zlecający, a jakość nauczania … nauczyciel? – co jest głupie z założenia 🙂

  3. Bartek

    Popieram wpis w 100%. Mam pewne doświadczenia ze studentami (i wykładowcami), gdyż od czasu do czasu prowadzę na jednej z uczelni państwowych zajęcia. Niestety jest tak jak piszesz. Czasami mam ochotę poprawić wiedzę studentów, ale niestety czasu brakuje, a mój przedmiot trzeba poprowadzić.

  4. Mateusz Kurleto

    To jeszcze powiedz mi skąd mam sobie wziąć pracownika, który przejmie ode mnie role inżynierii wymagań w projektach. Przecież to trzeba wziąć kogoś po studiach, żeby 2 lata studiował pod moim kierunkiem. Kogo stać na 2 lata pensji zanim pracownik będzie wartościowy?

    1. Jarek Żeliński

      Masz rację, albo go sobie na swój koszt wychowasz, albo na jego koszt (nieco mniej zarabia ale należy to z nim uzgodnić), albo podkupisz u konkurencji, albo stworzysz u siebie takie warunki, że sami do Ciebie przyjdą….. czyli jest ciężko…:)

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.