Regularnie widuje pytania takie jak to:

I have an assignment for developing a hotel reservation system! One of tasks is to develop UML class diagram! However, in the task description it is written “Class diagram should represent your database”. I am a bit confused about the rules, notations and etc… because I can’t find any official UML class diagrams specifically for databases! Could you help me please? (UML class diagram for database).

i regularnie piszę: używanie diagramu klas jako reprezentacji [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca UML) mówiących o modelowaniu relacyjnych modeli danych diagramami klas notacji UML. Do modelowania relacyjnego modelu danych używamy notacji ERD (ang. Entity Relationship Diagram, diagram związków encji). Niestety takie wzmianki – jak stosować diagram klas UML do modelowania RDBMS –  można znaleźć w książkach uznawanych za wartościowe (okładka jednej z nich po prawej), można usłyszeć na wielu szkoleniach dotyczących notacji UML, a nawet usłyszeć o tym można – modelowanie danych w UML – z ust niejednego wykładowcy na uczelniach wyższych technicznych (co jest smutne, mam na półce podręcznik akademicki z opisem stosowania kluczy głównych i obcych na diagramach klas w modelowaniu danych).

Przy okazji. Książkę tę , mam na półce, przeczytałem, i mam obawy przez jej polecaniem, mimo, że przez wielu jest uważana niemalże za biblię analityka biznesowego (ale jako ogólny opis modelu kompetencyjnego analityka można ją uznać).

Krótkie przypomnienie pojęć (sł. j. polskiego):

dane
1. ?fakty, liczby, na których można się oprzeć w wywodach?
2. ?informacje przetwarzane przez komputer?

obiekt
1. ?przedmiot, który można zobaczyć lub dotknąć?
2. ?rzecz abstrakcyjna, np. cecha lub pojęcie?
3. ?coś, czego dotyczą czyjeś działania, zainteresowania lub uczucia?
4. ?budynek lub zespół budynków; też: urządzenia terenowe?

Generalnie dane to zapis faktów (informacje, wiedza), obiekt to abstrakcyjny bądź rzeczywisty byt, mający określone cechy i reagujący na bodźce. To dwa różne światy. Tak zwany paradygmat obiektowy to modelowanie (traktowanie) systemu jako zbioru współpracujących w określonym celu obiektów.  Model danych zaś, to opis organizacji danych w ich repozytorium. Model obiektowy to struktura współpracujących obiektów mających określone zachowania. Nie tylko na uczelniach nadal pokutuje “stare”: Algorytmy plus struktury danych równa się programy, ale to  definicja jeszcze z czasów przetwarzania wsadowego. Dzisiaj mamy wokół siebie współdziałające komputery, smartfony, linie produkcyjne, a nawet sprzęt AGD, gdzie tu są te oddzielne “struktury danych i algorytmy”? Nie ma, są współdziałające obiekty. Owszem, każdy obiekt operuje określonymi danymi, ale są one “w środku” i nie są “jedną wielką bazą danych” .

Notacja UML bazuje na obiektowym paradygmacie, diagram klas tej notacji służy do modelowania obiektowej struktury dowolnego systemu (obiekt to nazwa, atrybuty i operacje jakie wykonuje on na żądanie). Nie ma tu mowy o żadnych danych, co najwyżej obiekty cechują się określonymi atrybutami, te jednak nie są współdzielone a zamknięte w tych obiektach, bo to ich “prywatne” cechy. Gdyby te atrybuty były współdzielone, system taki byłby niemodyfikowalny, niepodzielny i niepodatny na zmiany, na wymianę w nim jednego obiektu na inny (co obserwujemy nadal w systemach zintegrowanych metodą współdzielenia danych, tak jest skonstruowane wiele systemów ERP!).

Owszem, na poziomie technologicznym nadal korzystamy z plików na dyskach i baz danych (nie zawsze relacyjnych) ale to co innego, korzystamy z nich do zapisu (utrwalania) danych/treści, utrwalania informacji  (danych). Na styku tych dwóch światów korzystamy (jeżeli jest taka konieczność) z mapowania modelu obiektowego na utrwalane dane i wtedy korzystamy z notacji UML do modelowania obiektowej architektury aplikacji i np. z notacji ERD do modelowania np. relacyjnej struktury danych, łącznie nazywa się mapowanie obiektowo-relacyjne (ORM). Tak więc modelowanie danych notacją UML to pogwałcenie zasad stosowania tej notacji i niezrozumienie samej notacji, pojęcia obiekt i klasa. Skąd się biorą takie pomysły? Bardzo wielu ludzi używa notacji tylko w charakterze bibliotek obrazków/symboli, zaś notacja to system pojęciowy, a to nie jest to samo.

A przy okazji: tworzenie takich modeli w notacji UML, jako projekty modelu dziedziny systemu (obiektowego), to klasyczny antywzorzec projektowy o nazwie anemiczny model dziedziny:

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. (https://pl.wikipedia.org/wiki/Antywzorzec_projektowy)

Bibliografia