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.
Witam,
Z mojego doświadczenia (skromnego jednak) wynika, że każdy o UML mówi, jednak niewielu widziało. Mam przez to na myśli, że bardzo trudno jest znaleźć w internecie ,a na większości uczelni nie ma chyba co próbować, przykłady “UML done right” na niebanalnych dziedzinach biznesowych. Może Autor tego wpisu byłby w stanie wskazać tego typu materiały? Z pewnością wniosłoby to wiele wartości edukacyjnej do tego, już ciekawego, posta 😉
Pozdrawiam
W internecie i nie tylko, jest ich mało, głównie z tego powodu, że faktycznie mało który jest “dobrze zrobiony”. Czy to znaczy, że UML jest trudny i bez sensu? To potwierdza co innego: kodu napisanego naprawdę obiektowo jest równie mało… Trudne jest przestawienie się na myślenie obiektowe i obiektowe projektowanie gdy całe studia uczy się metod strukturalnych, baz relacyjnych i Pascala (algorytmika nie ma tu nic do rzeczy). ale ma to – metody obiektowe – sens, to te projekty o których wiem, że są “dobrze” zrobione pokazują, że zasady SOLID wnoszą dużą wartość dodaną, istnienie takich aplikacji jak choćby WordPress czy MOODLE pokazuje, że wzorce projektowe się sprawdzają, że można pisać oprogramowanie pozwalające na rozszerzenia funkcjonalności i nie wymagające zmian. Paradoksalnie duża pracochłonność kodowania działa na korzyść developera więc mamy sytuację, w której “rynek dostawców nie ma żadnego interesu w tym by to poprawiać. Ale niszowe, niekomercyjne projekty zyskują na tym, że projekt jest “lepszy” bo ma szanse na zlezienie inwestora. W naszym kraju dobre projekty to niestety śladowe zjawisko ale są. Z literatury z przykładami polecam spis zamieszczony pod artykułem o szachach (sam artykuł także zawiera przykład). Mało tam literatury krajowej niestety. Do tego warto dodać, że w UML raczej spotkamy się z projektami koncepcyjnymi i tylko logika biznesowa, reszta i tak pochodzi z frameworków a szczegóły kodu sa raczej dokumentowane w kodzie a nie poza nim…
Na uczelni coś wspomnieli o UML’u, wskazali soft do jego opracowania i poszło w zapomnienie. Wielka szkoda bo widzę, że to uprościło by prezentację bazy, programu itd.
UML wiele rzeczy upraszcza, ale z tą “bazą” to ostrożnie 😉
Witaj, tutaj kolega z Zachcianka:) (chyba że mi się pomyliło)
że ja wcześniej nie wiedziałem czym się zajmujesz:)))
Tezy w artykule mocne…
https://docs.google.com/forms/d/1xLFQvmWlseCbkknhR6BEmNh5kyQuG97IO5mBbpVTjZU/viewform
Nie, nie pomyliło Ci się 😉