Niemalże każde spotkanie projektowe, na którym omawiane są modele UML, na każdym szkoleniu na temat UML, pojawia się problem o którym pisze Ron Ross (wytłuszczenia moje):
Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That?s wrong. A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It?s about communication. A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication.Most businesses don?t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. (Źródło: Concept Model vs. Data Model ? Ron Ross on Business Rules)
Generalnie model pojęciowy, model danych to skrajnie różne modele. Jeżeli do tego dodamy dyskusje na temat obiektowego modelu dziedziny, to na spotkaniu mamy niemalże gwarancje ostrego sporu.
Widzę dwa główne źródła tych problemów. Pierwsze to fakt, że w szkołach wyższych nadal króluje analiza strukturalna, a po macoszemu traktowana analiza systemowa i obiektowa (obie bazują na koncepcji współpracujących obiektów i operują pojęciem obiekt zaś „termin” to pojęcie słownikowe). Teoria systemów i oparty na niej paradygmat obiektowy są niestety trudne, bazują w 100% na hermetyzacji i abstrahowaniu od szczegółów, a oderwanie się od szczegółów większości ludziom przychodzi z ogromnym trudem albo nie udaje się w ogóle. Drugie to powszechne mylenie kontekstów słów „termin” (pojęcie) i „koncepcja” (pomysł, idea) w literaturze anglojęzycznej:
concept {rzecz.} (też: notion, idea, conception, term) pojęcie {n.} Same concept, but looking at communication dynamics in a very different sphere. To samo pojęcie, ale patrząc na dynamikę komunikacji w zupełnie odmiennej sferze.
concept {rzecz.} (też: conception, idea) koncepcja {f.} However, we ought to be aware that the concept of victimisation requires strong proof. Musimy jednak być świadomi, że koncepcja represjonowania wymaga mocnych dowodów.
term {rzecz.} (też: notion, idea, conception, concept) pojęcie {n.} Really cool term: neoteny — the retention of play and juvenile traits in adults. Świetne pojęcie – neotenia, zachowanie u dorosłych młodzieńczych cech i chęci do zabawy.
(źr. http://pl.bab.la/slownik/angielski-polski/concept)
Do tego dochodzą notacje i czasami wręcz nie zrozumienie ich semantyki i zastosowania. W omawianym obszarze od lat są stosowane dwie, od niedawna trzy notacje:
- diagram związków encji (najpopularniejsze notacje to „Crow?s Feet” czyli kurze stopki 🙂 i jej wersja zwana, notacją barkera (Barker’s notation, ERD, ang. Entity Relationship Diagram)
- diagram klas notacji UML (ang. Unified Modeling Language)
- diagram faktów (ang. SBVR, Semantics Of Business Vocabulary And Rules)
Pierwszy służy do tworzenia modeli w paradygmacie relacyjnym na trzech poziomach ogólności, wszystkie trzy są modelami danych (a nie pojęć):
- Conceptual data model
- Logical data model
- Physical data model
Diagram klas w notacji UML służy do tworzenia modeli:
- pojęciowych (wszystkie diagramy klas w specyfikacjach OMG to modele pojęciowe opisujące semantyką i syntaktykę danej notacji),
- modeli obiektowych (diagram obiektów) i ich metamodeli (diagram klas), są to tak zwane modele dziedziny systemu (logika, mechanizm działania aplikacji, przedsiębiorstwa, każdego systemu w rozumieniu teorii systemów),
- modeli struktury kodu aplikacji (diagram klas).
Od niedawna mamy notacje SBVR a w niej diagram „Fact diagram”. Jest to diagram (nie jest to diagram klas UML, ale diagramu klas UML można użyć by go zastąpić) reprezentujący w formie graficznej słownik pojęć i jest to specyficzny model pojęciowy, oparty na tak zwanych związkach opartych na faktach (asocjacje reprezentują tu fakty, które kontekstowo kojarzą dane dwa pojęcia np. dokument opisuje zdarzenie, podkreślenia wskazują na pojęcia ze słownika (są w nim zdefiniowane) o słowo pisane kursywą to fakt, który je kontekstowo kojarzy (modele faktów to nie są ontologie).
Modele danych (np. diagramy ERD) to struktury pokazujące organizację danych (informacji). Mogą być na dużym poziomie abstrakcji w postaci wstępnego „pomysłu”, mogą być wypracowanym modelem i mogą być mniej lub bardziej kompromisowym planem implementacji.
Obiektowy paradygmat oraz ogólna teoria systemów zakładają, że wszystko to co obserwujemy to pewna większa lub mniejsza złożoność opisana jako skończona liczba współpracujących elementów (lub ich klas). Każdy element ma określone cechy, każdy w określony sposób reaguje na bodźce z otoczenia. Całkowitą złożoność wyznacza liczba tych elementów i prostota lub jej brak, reakcji na bodźce. Doskonale tłumaczy to metafora K.Poppera o zegarach i chmurach:
Generalnie problem złożoności ładnie opisał Karl Popper, w swoim dziele Wiedza Obiektywna metaforą ?o chmurach i zegarach?. To co obserwujemy, system, może być tak złożone, że ilość obiektów i ich wzajemnych oddziaływań będzie zbyt duża, by możliwe było stworzenie modelu (teoria wyjaśniająca zachowanie) takiego systemu, pozwalającego na przewidywanie zachowania takiej złożoności. Są jednak systemy, których natura na to pozwala, ich model jest możliwy do stworzenia, takie systemy są przewidywalne w 100%. Metaforą systemu nieprzewidywalnego jest chmura, a przewidywalnego zegar. Oczywiście jest nieskończenie wiele systemów o naturze gdzieś pomiędzy chmurami i zegarami. (Źródło: Wszystkie drogi prowadzą do Rzymu | | Jarosław Żeliński IT-Consulting)
Elementy systemu mają swoje cechy (ukryte: hermetyzacja) a uzewnętrzniają wyłącznie reakcje na bodźce (żądania). W efekcie system „żyje” ale nie jest „bazą danych”. UML i diagram klas, w tym wypadku, modeluje współpracujące obiekty a nie „bazę danych”. To, że taka baza (każda forma utrwalania danych) fizycznie istnieje (jest tworzona) to wyłącznie skutek potrzeby jaką jest zapamiętanie stanu systemu (aplikacji).
Niewątpliwie jednak diagram klas UML nie jest relacyjnym modelem danych
Model komponentu systemu, opisujący mechanizm jego działania (logikę) to tak zwany „model dziedziny” czyli obiektowy model systemu opisujący (modelujący) mechanizm jego działania. Owszem, aplikacja może służyć do zarządzania dużymi i zorganizowanymi zbiorami danych ale to to samo co zespół ludzi – system współpracujących obiektów mających – każdy – wiele cech – zarządzający biblioteką: Ci ludzie i ich cechy to nie „baza danych” a ukryte do ich wiadomości cechy i umiejętności, dostępne dla innych wyłącznie pod warunkiem zadania pytania i woli odpowiedzi na nie, ci ludzie mogą „zarządzać” jakimś zbiorem danych.
Dlatego ubolewam, gdy osoby będące nauczycielami akademickimi, trenerami prowadzącymi szkolenia czy autorami wielu „uczonych” blogów, publikują pomysły o modelowaniu danych z użyciem UML… co nie ma nic wspólnego z UML.
O SBVR, modelach pojęciowych i diagramie faktów pisałem w artykule SBVR czyli reguły biznesowe i słownik. Kwestie diagramów klas opisałem między innymi w artykule Cholerny diagram klas i w Czym jest a czym nie jest model dziedziny. Jeśli zaś chodzi o to czym nie jest diagram ERD pisałem przy okazji Wiedza po studiach? Zostaliście oszukani?
Na zakończenie ciekawy referat na temat nazw: „Proper Names” by John Searle:
Nareszcie jakieś dobre-proste wyjaśnienie. Dzięki.
Czy zatem należałoby wyłączyć bazodanowców z procesu tworzenia wymagań?
Doświadczenie uczy, że często są to osoby postrzegane jako jedne z najważniejszych w projekcie IT.
Jakkolwiek uważam, że każdy członek zespołu jest ważny w procesie tworzenia aplikacji (tak również marketingowiec), to bazodanowcy często podchodzą do samych siebie tak jak jak przykładowo prawnicy… nie ujmując wszystkim prawnikom spora ich część pracuje na opinię o branży jako kaście nadętych dupków z nosami w chmurach.
Ja ich już dawno wyłączyłem :). Najważniejsze? Kiedyś gdy baza danych stanowiła 99% projektu implementacji tak…. teraz nie (o ile nie mówimy o metodach strukturalnych). Owszem, każdy członek zespołu jest ważny, jednak klucz to określenie ról w projekcie i rezygnacja ze zbiorowej odpowiedzialności. Zwróć uwagę, że o jakości działania biblioteki nie decyduje szafa z kartoteką….
Co do opinii … z grzeczności nie zaprzeczę 😉
Dzień dobry 🙂 W Enterprise Architect jeśli chodzi o modelowanie danych jest tylko jedna możliwość: notacja Barkera (winogronka), nie ma notacji Martina (kurze stopy). Jeśli chciałbym przedstawić model danych jako encje + relacje (liczności) to jedyny sposób w jaki mogę to zrobić to skorzystać z diagramu klas UML. Czy takie podejście jest zgodne ze sztuką?
Kilka słów ogólnie tutaj: architektura kodu
To troszkę pytanie z gatunku „czy mogę używać, łopaty do zabijania much bo nie mam standardowej packi na muchy”… ;). Odpowiedź zawsze będzie brzmiała: owszem, ale pamiętaj o konsekwencjach.
Z tak zwaną „sztuką” nie ma to absolutnie nic wspólnego, bo generalnie zadeklarowanie stosowania notacji UML każe użyć do interpretacji takich diagramów specyfikacji UML, a notacja ta powstała do czego innego (o modelowaniu danych w UML nie ma ani słowa, nie przypadkiem świat ma diagramy ERD i stosowne notacje do modelowania danych w relacyjnym ich modelu). Paradygmat obiektowy jest daleki od relacyjnego modelu danych i towarzyszącemu mu strukturalnego paradygmatu projektowania oprogramowania.
Aby nie brnąć w akademickie metody (dość często nadmiarowe 😉 ) oraz zaspokoić i wilka i owcę można tak: deklarujemy, że projektujemy w UML warstwę odwzorowania tabel baz danych z pomocą wzorców obiektowych active record (mapowanie obiekt-rekord) lub active table (mapowanie klasa-tablica), deklarujemy też w tym celu prosty profil zawierający jeden stereotyp 'ORM’: oznaczona tym stereotypem klasa (i jej atrybuty) będzie wtedy intepretowana jako klasa implementująca interfejs do tablicy bazy danych. Najprościej: budujemy diagram klas oznaczając wszystkie klasy stereotypem 'ORM’, klasy, ich atrybuty i asocjacje między klasami intepretujemy jako krotki, atrybuty i relacje modelu relacyjnego w notacji Martina (często stosowany stereotyp w narzędziach wspierających ORM, np. Hibernate, to 'ORM Pesistable’). Kilka słów o tym także tu: JPA ORM.
Przykład akademicki takiego profilu opisano w: Torres, A., Galante, R., & Pimenta, M. (2009). Towards a UML Profile for Model-Driven Object-Relational Mapping. https://doi.org/10.1109/SBES.2009.22.
BTW: z tego powodu coraz więcej ludzi na świecie powoli rezygnuje z EA SPARX ;), to stare narzędzie z wielkim długiem technologicznym.. Po drugie relacyjny model danych i SQL powoli odchodzą do lamusa ;), polecam teksty o BigData i NoSQL.
W EA można „zamienić” diagram klas na diagram ERD typu „Crow’s foot”.
Aby przedstawić model danych przy użyciu konwencji Crow’s foot należy otworzyć okno właściwości diagramu (prawy przycisk myszy na pustym miejscu diagramu, a następnie wybieramy z menu kontekstowego Properties). Na zakładce Connectors z listy rozwijalnej Connector Notation należy zamiast UML 2.1 wybrać Information Engineering.
https://eablogpl.blogspot.com/2014/07/entity-relationship-model-w-enterprise.html
Karkołomne ale ..ę da sié 😉
Na szczęście sa narzędzia, że modele ERD po prostu są, do tego pozwalają tworzyć mapowania ORM i generować skrypty DDE bez tak karkołomnych operacji: Programming Guides (ORM) for Visual Paradigm Users
Problem z EA SPARX niestety pozostaje taki, że eksport XMI i wymiana z innymi narzędziami nie jest możliwa. Nie mnie jednak duże podziękowania za pomoc użytkownikom EA.
Dziękuję za wyjaśnienia 🙂 Myślałem, że skoro wizualnie diagram ERD w notacji Martina wygląda tak samo jak diagram klas (bez metod) to nic w tym złego 😉 A mam jeszcze jedno pytanie. Jaką notacją/notacjami powinno się posłużyć żeby zamodelować transformację i przepływy danych (w tym plików z danymi) między systemami. Załóżmy: w pierwszym kroku system X generuje pli CSV, następnie system Y wykorzystuje ten plik, przetwarza te dane, następnie system Z integruje się z systemem Y. A za wszystko to dzieje się w ramach procesu biznesowego „XYZ”. Jak to wszystko zamodelować i jeszcze powiązać z procesem…
Wizualne podobieństwo notacji to w PowerPoint działa 😉 … Notacje formalne to raczej matematyka 🙂 (nie przypadkiem są także przedmiotem norm).
Co do drugiego pytania: UML (tu jest kilka typów diagramów), w sumie narysuję to ale poproszę jakiś bogatszy opis tego procesu z tymi XYZ, bo generalnie to IT wspiera proces biznesowy a nie odwrotnie ;): które z tych systemów są wykorzystywane przez ludzi w procesie biznesowym.
jak intepretować zdanie: „następnie system Z integruje się z systemem Y”, który system co tu robi?
O super 🙂 załóżmy, że realizujemy proces biznesowy: zarządzanie kursami walut. W ramach procesu pracownik musi przygotować plik csv zawierający wyłącznie listę słownikową par walut (np. usdpln, eurpln, eurusd). Nazwa pliku to np bieżącą data.
Następnie systemX łączy się z API zewnętrznej platformy i pobiera tabele kursów tych par walut (aktualne i historyczne miesiąc wstecz) i wystawia plik xls zawierający dane: nazwa pary walut, data kursu, wartość kursy)
Plik ten system X wysyła do szyby ESB. Szyna przesyła ten plik do systemuY.
SystemY wykorzystuje te dane do wyznaczenia wewnętrznych kursów walut wg. ustalonego modelu matematycznego. Wynik obliczeń odkładany jest w bazie danych tego systemu.
Na końcu procesu jest pracownik, który wykorzystuje te informacje za pośrednictwem SystemuZ. Wybiera parę walut, określa datę i system zwraca mu wewnętrzny kurs wyznaczony przez SystemY. Technicznie odbywa się poprzez odpytanie systemu Y poprzez jego API.
Czyli mamy SystemX, SystemY, SystemZ, pracownika, szynę, plik csv, plix xls, 2XAPI no i przepływ danych (najpierw plików, potem poszczególnych atrybutów) . I jak to wszystkim pokazać żeby było czytelne?
Proszę się zapisać na newsletter, odpowiedź będzie opisowa (wpis na blogu). Być może o cos zapytam jeszcze tu.
Odpowiedź:
https://it-consulting.pl/autoinstalator/wordpress/2021/10/05/i-jak-to-wszystkim-pokazac-zeby-bylo-czytelne/
ukazał się artykuł z odpowiedzią, będę wdzięczny za opinie 😉
To jeszcze inny wątek. Napisał Pan: „.. : Ci ludzie i ich cechy to nie ?baza danych? a ukryte do ich wiadomości cechy i umiejętności, dostępne dla innych wyłącznie pod warunkiem zadania pytania i woli odpowiedzi na nie, ci ludzie mogą ?zarządzać? jakimś zbiorem danych..” – czyli jeśli mam np. komponent np. GeneratorFaktur to zgodnie z obiektywom paradygmatem kogo odpytuję żeby uzyskać dane sprzedawcy do wystawienia faktury: odpytuję np. komponent BazaKlientów z argumentem np. NIP? Dobrze rozumiem?
GeneratorFaktur jako logika tworzenia Faktury tworzy Fakturę. BazaKlientów służy tu (temy Generatorowi) jako źródło danych klientów, ale to może być APi do usługi GUS, która na NIP odpowiada danymi podmiotu gospodarczego. Dane sprzedawcy (jest pracownikiem sprzedającego) wystawiającego tę fakturę pobrał bym z rejestru pracowników, na podstawie jego identyfikatora bo zakładam, że jest „zalogowany” więc znam jego identyfikator (to parametr sesji).
Czy pojęcia na modelu pojęciowym (SBVR) to obiekty? Odnoszę takie wrażenie, że niektórzy twierdzą, że tak.
Nie, pojęcia na modelu pojęciowym to pojęcia 😉
Jednak są i tacy, to twierdzą że na modelu pojęciowym są obiekty –> Katedra Informatyki, Politechnika Poznańska, strona 4, p. 2:
https://icis.pcz.pl/~olga/dydaktyka/BAZYw06.p.pdf
Odnoszę wrażenie, że autorzy zatrzymali się na czasach sprzed notacji SBVR i model pojęciowy traktują jak model oprogramowania ściśle powiązany z relacyjnymi bazami danych.
To nawet nie chodzi o notację SBVR. Niestety wielu ludzi mentalnie siedzi po uszy w SQL/model relacyjny i nie odróżnia pojęcia w słowniku od przedmiotu nim nazwanego. Trójkąt semiotyczny to ogólnie wiedza mająca setki lat:
„The triangle of reference (also known as the triangle of meaning[1] and the semiotic triangle) is a model of how linguistic symbols relate to the objects they represent. The triangle was published in The Meaning of Meaning (1923) by Charles Kay Ogden and I. A. Richards.[2] While often referred to as the „Ogden/Richards triangle”, the idea was also expressed in 1810 by Bernard Bolzano, in his Beiträge zu einer begründeteren Darstellung der Mathematik. The triangle can be traced back to 4th century BC, in Aristotle’s Peri Hermeneias. The Triangle relates to the problem of universals, a philosophical debate which split ancient and medieval philosophers, especially realists and nominalists.”
przykre jest to, że na wielu uczelniach jest taki stan wiedzy wśród kadry wykładowców….
Daoutis, M., & Mavridis, N. (2014). Towards a model for grounding semantic composition. AISB-Artificial Intelligence and the Simulation of Behaviour 2014. https://www.researchgate.net/publication/286283084_Towards_a_model_for_grounding_semantic_composition
Ullmann, S. L. (1973). Oogenesis in Tenebrio molitor: Histological and autoradiographical observations on pupal and adult ovaries. Development, 30(1), 179–217.
„przykre jest to, że na wielu uczelniach jest taki stan wiedzy wśród kadry wykładowców.…”
Najwidoczniej nie aktualizują wiedzy.
I jeżeli to wykładowca akademicki to jest to przykre.