Nadal obserwuję to, że model relacyjny i “tworzenie bazowych modeli danych na etapie analizy wymagań” (kanoniczny model danych) trzymają się twardo mimo tego, że nie wiele wnoszą do projektu a narzucają (sugerują) kiepską architekturę aplikacji z jedną relacyjna bazą danych.  Co ciekawe zaczynanie od bazy danych jest wręcz zaprzeczeniem zwinności (konieczność ukończenia projektu docelowej bazy danych przed rozpoczęciem kodowania czyli klasyka waterfall, w efekcie betonowanie stanu z dnia rozpoczęcia) mimo, że autorki artykułu piszą o sobie że są agile…)

Popatrzmy na to co proponują w tym 2017 roku.:

Jeśli w systemie istnieją określone reguły biznesowe, które określają maksymalne wartości relacji 0..n lub 1..n, można je uwzględnić w granicach kontekstu. Na przykład, PO dla SeiSounds może chcieć określić, że każde konto może być powiązane tylko z maksymalnie pięcioma użytkownikami lub słuchaczami, aby uniknąć sytuacji, w której znajomi kupują jedną płatną subskrypcję i dzielą się nią ze wszystkimi innymi. Proszę zobaczyć poniższy przykład:

[…]PODSUMOWANIE Diagramy danych biznesowych są jednym z tych modeli, które MUSZĄ BYĆ dla każdego produktu, który ma do czynienia z danymi. Samo ćwiczenie tworzenia modelu tworzy potężne, wspólne zrozumienie podstawowych konstrukcji danych, tak jak rozumieją je użytkownicy. BDD może również pomóc w zidentyfikowaniu dodatkowych, bardziej szczegółowych modeli, które mogą być potrzebne, a także w uzyskaniu pełnego zestawu historii użytkowników dotyczących interakcji użytkowników z danymi po wykonaniu czynności tworzenia, używania, edytowania, usuwania, przenoszenia i kopiowania. (Źródło: Deep Dive Models in Agile Series: Business Data Diagram) 

Powyższy model:

1. deklaruje konkretną znaną “na teraz”, wartość limitu liczby użytkowników Konta,
2. pomiędzy autorem, utworem i stacją  jest nic niemówiąca (każde z każdym bez żadnych ograniczeń) zależność,
3. pozostałe elementy nie wnoszą wartości dodanej (utwór jest cechą artysty czy może artysta jest cechą utworu…).

Zaryzykuję tezę, że powyższe w zasadzie nie pomaga developerowi w niczym. Czy wnosi coś do projektu? W moich oczach stanowi proste “zapisanie” tego co zeznali indagowani zamawiający (artykuł zawiera opis historyjek użytkownika i ich kojarzenia z tym modelem danych). Stwierdzenie zaś, że “…określone reguły biznesowe w systemie, które ustalają maksymalne wartości dla relacji 0..n lub 1..n…”, (np. maksimum pięcioro użytkowników może jednocześnie słuchać), to nie reguła biznesowa a kryterium decyzyjne (więcej o regułach biznesowych w literaturze). 

Trzeba sobie tu jasno powiedzieć, że indukcyjne podejście do analizy (zbieranie i zapisywanie obserwacji w celu identyfikacji trendu lub powtórzeń) przypomina próby zrozumienia gry w szachy metodą wielokrotnej obserwacji rozgrywek. Im wierniejszy opis gry ma powstać, tym więcej obserwacji należy udokumentować, co nie zmienia faktu, że taki dokument nie mówi absolutnie nic o przyszłych rozgrywkach. Alternatywą jest dedukcyjne podejście, polegające na zrozumieniu i opracowaniu, możliwie najmniejszym nakładem pracy, reguł gry w szachy, czego udokumentowanie wymaga najwyżej dwóch stron papieru A4, taki dokument opisuje także w 100% wszystkie przyszłe rozgrywki… 

Jak inaczej podejść do tego? 

Na początek należy zrozumieć dziedzinę problemu i opisać ją słownikiem:

Powyższy model pojęciowy (diagram notacji SBVR, diagram klas notacji UML) to słownik pojęć a nie model danych. To diagram obrazujący pojęcia i kontekstowe związki między nimi (tym kontekstem są fakty z dziedziny analizowanego problemu). Nie są to ani dane ani reguły biznesowe.

Są to graficznie wyrażone zdania, testem tego modelu jest sprawdzenie czy są to zdania prawdziwe w danej dziedzinie, np. “artysta jest autorem utworu”.

Są to pojęcia 9nazwy), a nie “byty systemowe”. Poza takim diagramem, należy także stworzyć słownik pojęć biznesowych w postaci tabeli zawierającej precyzyjne, dziedzinowe definicje tych pojęć. Dla wygody i prezentacji ich treści naniosłem dwie reguły na diagram, są skojarzone z Kontem gdyż jego dotyczą. Co do zasady reguły biznesowe są kojarzone z elementami na innych diagramach poprzez słowa zdefiniowane.

Cała analiza powinna się zaczynać od udokumentowania modeli procesów. Tu pominąłem te modele bo ich opisów jest na moim blogu wiele, a chcę się skupić na dziedzinie dla jakiej powstaje aplikacja. Analiza i zrozumienie problemu prowadzi do stworzenia modelu dziedziny aplikacji. Taki model powstaje na podstawie treści dokumentów wewnętrznych i zewnętrznych (tu np. Ustawa o prawach autorskich), pomagają co najwyżej bieżące wyjaśnienia.  Do jego powstania nie są potrzebne żadne warsztaty ani całodzienne spotkania.

Celem modelowania dziedziny systemu (tu aplikacji) jest udokumentowanie wewnętrznej logiki aplikacji, czyli mechanizmu jej działania. Absolutnie nie jest to model danych. Powyższy model nie jest modelem “ukończonym”, wymaga na pewno dopracowania, jednak moim celem jest jedynie pokazanie idei jego tworzenia. Nazwy klas, atrybutów, operacji zawierają pojęcia zawarte w słowniku pojęć. Zapewnia to jednoznaczność i zrozumienie. Dodam, że dopiero ten model pokazuje bardzo ważną rzecz, to że autor jest cechą utworu a nie odwrotnie. 

Tak więc:

1. uruchomienie i korzystanie z emisji kontrolowane jest przez Zarządzanie emisją, tu sprawdzane są i egzekwowane, reguły biznesowe, 
2. komponent Zarządzanie emisją korzysta także z informacji zawartych w Koncie użytkownika i Playlisty, detale utworów pobiera z Repozytorium utworów. 

Tu ważne jest podkreślenie, że reguła dotycząca ograniczenia liczby jednocześnie słuchających, jest oddzielona od Kont użytkowników i (nie pokazanych tu) Subskrypcji. Dzięki temu parametr ten jest łatwo modyfikowalny z poziomu aplikacji (parametryzowane kryterium decyzyjne) bez potrzeby jakichkolwiek ingerencji w “model danych”. Umieszczanie jakichkolwiek reguł w bazie danych (czyli na poziomie implementacji utrwalania) jest niestety ich “betonowaniem”.

Zmienność, nie tylko rynku ale i samych reguł w organizacjach, to stały element środowiska aplikacji. Dlatego dobrą praktyką jest, by utrwalanie danych (wszelkie bazy danych, pliki itp..) nie służyło do niczego poza utrwalaniem. Logika biznesowa powinna być w w 100% w aplikacji a nie podzielona pomiędzy aplikację i dane (żadna baza danych nie jest w stanie przechowywać innych reguł biznesowych niż bezpośrednie związki ilościowe). Na etapie implementacji, stosujemy zasadę hermetyzacji, czyli nie współdzielimy, na żadnym poziomie, danych pomiędzy repozytoriami i nie usuwamy redundancji. Dzięki temu nie odcinamy sobie drogi do zmian systemu takich jak np. zastąpienie klasy Dane osobowe interfejsem do zewnętrznego systemu, dysponującego takimi informacjami (klasa ta zostanie zmieniona, stanie się wtedy mostem do API zewnętrznego systemu co nie pociągnie za sobą jakichkolwiek zmian, bo interfejs tej klasy i jej nazwa pozostaną niezmienione, patrz zasada open-close principia oraz polimorfizm).

Poniżej kluczowe związki w UML i ilustracja związku pomiędzy modelem pojęciowym a modelem struktury (architektury, to model dziedziny):

Na zakończenie warto zauważyć, że zmienność środowiska biznesowego powoduje, że żadne decyzje o logice biznesowej nie są ostateczne, jednak są elementy niezmienne takie jak np. nasze dane osobowe. Tak więc to, co powszechnie nazywane jest “modelem danych” (business data diagram) w rozumieniu opisanym przez autorki artykułu, nie ma dzisiaj racji bytu. Ma sens zachowanie zamówienia i osobno faktury, ale to czy regułą jest jedno zamówienie do jednej faktury, podlega zmianom wynikającym i ze zmienności prawa i ze zmienności modeli biznesowych. Nie widzę żadnego powodu deklarowania już na początku projektu, tego by nie więcej niż 5 osób mogło korzystać z jednego konta i subskrypcji. W szczególności nie widzę powodu by taka zasada była zawarta w samym kodzie aplikacji.

Warto także mieć na uwadze to, że oprogramowanie może być tworzone z użyciem zewnętrznych komponentów dostępnych na rynku.  Założenie więc na samym początku projektu, że dane są w jednolity sposób przechowywane i współdzielone w jednej centralnej i współdzielonej bazie danych, wraz z logiką ich użycia, jest tu nie tylko nieuzasadnione ale wręcz szkodliwe. 

I na koniec gratka: dokładnie ta powstała, i nadal tak wygląda, znaczna większość obecnych na rynku systemów ERP, CRM itp…. 

oraz cytat z literatury

z 1994 roku:

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:

1. 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)
2. diagram klas notacji UML (ang. Unified Modeling Language)
3. 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ęć):

1. Conceptual data model
2. Logical data model
3. Physical data model

Diagram klas w notacji UML służy do tworzenia modeli:

1. pojęciowych (wszystkie diagramy klas w specyfikacjach OMG to modele pojęciowe opisujące semantyką i syntaktykę danej notacji),
2. 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),
3. 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:

Wprowadzenie

Ten artykuł to kontynuacja wątku rozpoczętego wpisem o modelu dziedziny i diagramie klas, jednak inna jest intencja. Wśród wielu listów i pytań od studentów i pracujących już analityków, na temat UML, regularnie pojawia się pytanie o diagram klas i modelowanie tak zwanej dziedziny systemu. Gdy odpowiadam często pojawia się zarzut, “a tam napisano, że…”.

Ten artykuł to między innymi chęć zwrócenia uwagi na to, że w sieci i wielu książkach niestety mamy nie mało tak zwanej pseudowiedzy… Z zasady nie oceniam treści innych stron, jednak trudno zignorować coś, co ktoś podaje jako przykład w rozmowie ze mną. Cytat, który przytoczyłem w dalszej części (jawnie podane źródło), pochodzi z cyklu  artykułów jakie ukazały się w piśmie Software Developer Journal, umieszczonego na publicznej stronie WWW ich autora, trenera prowadzącego szkolenia z UML.

Artykuł ten dedykuję między innymi każdemu kto podejmuje decyzję o szkoleniu, w jakiej firmie i u jakiego trenera.

Model dziedziny systemu

Na pytania o to, czym jest a czym nie jest tak zwany “model dziedziny systemu”  można odpowiedzieć pod warunkiem wcześniejszego zdefiniowania pojęcia “dziedzina systemu”. Bez tej definicji wszelkie dywagacje o modelowaniu “dziedziny systemu” są niestety bezprzedmiotowe (i bez sensu).

Pewien forumowicz, po lekturze kilku znalezionych stron WWW zapytał:

Czy możecie mi wytłumaczyć co oznaczają pojęcia “model dziedziny” oraz “model konceptualny”? Czy model dziedziny zawiera także diagram konceptualny klas?

Cóż, problem definicji pojęć. Uporządkujmy to co nieco. Wpisanie hasła “dziedzina systemu” do Google daje niestety tak różne informacje, nie raz sprzeczne, że wyłuskanie z tego “prawdy” dla początkującego jest niemalże niemożliwe (niestety tu uwidacznia się wada Internetu jako “źródła wiedzy”). Zróbmy to więc jak należy ;), celowo używam WIKI, bo to popularne darmowe źródło wiedzy, ale zaznaczam, że cytuje to co znam i wiem, że ma potwierdzenie w tradycyjnej literaturze naukowej.

Definicja pojęcia system:

System (stgr.  “systema” rzecz złożona) ? obiekt fizyczny lub abstrakcyjny, w którym można wyodrębnić zespół lub zespoły elementów wzajemnie powiązanych w układy, realizujących jako całość funkcję nadrzędną lub zbiór takich funkcji (funkcjonalność) (System ? Wikipedia, wolna encyklopedia).

Myślę, że tej definicji nie trzeba komentować. Kilka słów o pojęciu “dziedzina”. To bardzo niefortunne tłumaczenie słowa domain, bo model dziedziny to w oryginale domain model. Tu chodzi o domenę a nie dziedzinę (te słowa w j.polskim mają jednak nieco inne znaczenie).

Domena (dominium) ? kategoria systematyczna wyższa od królestwa, stosowana w klasyfikacji biologicznej (Domena (biologia) ? Wikipedia, wolna encyklopedia).

Domena to pojęcie mające rodowód w biologii, podobnie zresztą jak “teoria systemów” 🙂 i odnosi się do systematyzowania czegoś (klasyfikowania, stąd także pojęcie klasa).

Pojęcie dziedziny: dziedzina relacji, log. zbiór wszystkich przedmiotów pozostających w danej relacji do co najmniej jednego przedmiotu. (Encyklopedia PWN) ma swoje odzwierciedlenie w modelu relacyjnym baz danych i analizie strukturalnej. To, co w metodach strukturalnych bywa nazywane modelem dziedziny, to właśnie relacje  pomiędzy przedmiotami (bytami). Jest to tak zwany model pojęciowy (ang. conceptual model to model pojęciowy, tu bazy danych, a nie koncepcyjny w rozumieniu “pomysł na…”) wyrażany diagramem ERD (ang. Entity Relationship Model) i opisujący struktury danych.

W paradygmacie obiektowym:

Object-oriented programming (OOP) is a programming paradigm that represents concepts as “objects” that have data fields (attributes that describe the object) and associated procedures known as methods. […] An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. (Object-oriented programming – Wikipedia, the free encyclopedia).

W wolnym tłumaczeniu: obiektowy paradygmat programowania to reprezentowanie pojęć w postaci “obiektów”, mających atrybuty (dane opisujące obiekt) oraz powiązane procedury, nazywane metodami. Program obiektowy należy postrzegać jako kolekcję współdziałających obiektów, w przeciwieństwie do  konwencjonalnego modelu programowania, gdzie “wyłącznie” program to lista poleceń (zadań, podprogramów) [przyp. mój] operujących na określonym zestawie danych (baza danych).

Tak więc w paradygmacie obiektowym domain model, czyli “model dziedziny”, to kolekcja obiektów reprezentujących  modelowany problem. Innymi słowy:

obiektowy model dziedziny systemu to zestaw obiektów reprezentujących przedmioty z danego obszaru pojęciowego (np. handel i sprzedaż, produkcja kabli, itp.), zawierający dla każdego przedmiotu opis jego cech i procedur jakie może wykonać.

Taka kolekcja współpracujących obiektów, to przede wszystkim owe obiekty i ich metody (umiejętności). Ich cechy są ukryte wewnątrz nich, nie są przedmiotem współdziałania, bo współdziałanie polega komunikowaniu się obiektów między sobą a nie przetwarzaniu danych, które jako takie nie występują w tym paradygmacie.

Ale podobno program komputerowy służy do przetwarzania danych!

Hm… tylko wtedy, gdy patrzymy na biznes jak na zbieranie danych. Sprzedaż można postrzegać jako “przetwarzanie danych o transakcjach sprzedaży”, można jednak też postrzegać ją jako “operowanie na obiektach biznesowych takich jak: produkty, zamówienia i faktury”. Jest to diametralna różnica. Tu interesuje nas przede wszystkim to, że obiekty takie jak Produkt, zmieniły właściciela, obiekt Zamówienie jest materializacją tego czego oczekuje zamawiający, zaś Faktura materializacją faktu dokonania tej sprzedaży. Dane takie jak, cena, ilość, podatek, to tylko cechy tych obiektów, które są niezbędne by te transakcje zostały przeprowadzone w sposób prawidłowy i kontrolowany. Proszę zwrócić uwagę na to, że celem kupującego samochód jest tenże samochód służący do swobodnego podróżowania, a nie “przetworzenie jego ceny, podatku, ciężaru i numeru silnika”. Użytkownikowi samochodu potrzebne są dwa obiekty: Samochód i jego DowódRejestracyjny.

Tyle “teorii”. Jaki problem miał ów forumowicz? Ano taki, że np. na stronie jednej z dość znanych firm szkoleniowych, znalazł coś takiego w artykule o UML i modelowaniu obiektowym:

Zwróćmy uwagę, że na modelu dziedziny nie umieszczamy klas implementujących logikę aplikacji, jej interfejs użytkownika czy warstwę dostępu do danych. Nie warto też na modelu dziedziny umieszczać metod. Dzięki temu diagram jest prosty i powinien być zrozumiały także dla klienta nie mającego przygotowania technicznego i nie zainteresowanego szczegółami implementacji systemu. […] Model dziedziny jest elementem analizy systemowej, ukazującym biznesowe struktury danych i zależności pomiędzy nimi. W dużych projektach może on obejmować kilkaset klas. Decydując się na jego stworzenie, nie pozwalamy, aby istotne decyzje merytoryczne były podejmowane ad-hoc w trakcie implementacji. (Diagramy klas – model dziedziny i projekt aplikacji).

Cały ten akapit, jego ocenę, pozostawiam teraz czytelnikom (niestety ten cykl artykułów zawiera błędne przykłady modeli i błędne opisy struktury obiektowego kodu programu). To, co celowo wytłuściłem to niestety fundamentalny błąd w powyższym  tekście: obiektowy model dziedziny to absolutnie nie są struktury danych i zależności między nimi.

Forumowicz: Coraz większy mętlik w głowie. Wcześniej miałem do czynienia tylko z diagramem związków encji. Teraz nawet nie bardzo widzę różnicę pomiędzy nim a diagramem klas.

No niestety, mając za sobą teksty jak powyższy, nie dziwię się. Model w postaci diagramu ERD to właśnie  owe “struktury danych i zależności pomiędzy nimi”, ale nie ma to absolutnie nic wspólnego ani z diagramem klas ani z obiektowym paradygmatem. Różnica jest fundamentalna:

– ERD to diagram opisujący dane i tylko dane (tu nie wiemy nawet do czego one służą bo ta wiedza jest w funkcjach)

– obiektowy model dziedziny to diagram klas (UML) obrazujący wyłącznie role (obiekty mają cel istnienia, ich atrybuty są ich prywatną własnością, nie widać ich)

Forumowicz: Piszesz, że diagram klas w modelu dziedziny opisuję logikę aplikacji a jak to się ma do definicji diagramu klas która mówi, że jest to statyczny opis struktury systemu. Skoro jest to model statyczny to raczej nie pokazuje zachowania.

Logika systemu to nie dynamika działania a zestaw reguł działania, są one zawarte w metodach klas. Reguły są statyczne, dynamiczne są zachowania czyli odpowiedź na bodźce. Dynamika systemu to współdziałanie obiektów realizujących jakieś złożone zadanie (to modelujemy diagramem sekwencji). Model statyczny to kolekcja obiektów wraz z opisem ich cech i metod jakie realizują, czyli właśnie model dziedziny systemu wyrażony diagramem klas. Przywołując metaforę Fowlera, gra w snookera to kule i fizyka ich ruchu oraz zasady gry. Statyczny model snookera możliwy do pokazania jako diagram klas to między innymi klasa kula, która ma operacje uderzenie z parametrami siła uderzenia i kierunek oraz atrybuty średnica i masa.  Czym jest tu dynamika? Ona pojawia się jako opis uderzenia kijem w kulę… Czy model dziedziny to jest model statyczny struktury oprogramowania? Tak, bo fundamentem paradygmatu obiektowego tworzenia oprogramowania  jest to, że program obiektowy to implementacja (odwzorowanie w kodzie) obiektowego modelu dziedziny systemu. Odpowiedziałem forumowiczowi:

Model statyczny to coś jak Ty i Twoi koledzy dla otoczenia:

– masz konkretną rolę (np. murarz), po tym można identyfikować Twoje umiejętności i wiedzę, wiadomo co potrafisz i jak o to poprosić (wykonujesz konkretne polecenia opisane w Twojej umowie o pracę – to Twoje metody),

– nikt w pracy nie wie ile masz lat, jaki masz nastrój, itp. więc “dane” (twoje cechy) nie mają znaczenia (są chronione, dostępne są wyłącznie w dziale HR), znaczenie mają tylko Twoje umiejętności, i to, że jako konkretny murarz masz imię i nazwisko, po którym można Cię identyfikować na budowie.

Gdzie logika biznesowa? Ty wiesz jak murować, znasz zasady bezpieczeństwa, w razie potrzeby dostaniesz procedurę działania realizacji np. specyficznej ściany. Poprawny i kompletny Model dziedziny (dokumentowany diagramem klas) to klasy reprezentujące zarówno murarza zawierające – metody – procedury działania czyli logikę biznesową.

Wyobraź sobie Twoje CV, co jako Ty oferujesz? Swoja metrykę? Nie. To co potrafisz bo zgodnie z prawem nawet Twoja płeć nie ma znaczenia. Nie zmienia to faktu, że teczka CV pracowników firmy to jej model statyczny organizacji… Gdyby diagram klas służył do tego co ERD nie było by diagramu klas…;).

Skąd się bierze taka skuteczność metod obiektowych (o ile są prawidłowo stosowane)? Metody strukturalne to rozkładanie problemu biznesowego na oddzielone od siebie dane i procedury ich przetwarzania. Informacje o obiektach rzeczywistych są tracone w tych metodach. Model relacyjny danych to model, w którym utracono wiele informacji, np. nie da się z modelu relacyjnego odtworzyć np. faktury nie wiedząc jak ona wygląda. Do wydruku faktury potrzebne jest zapytanie, które wyciągnie z bazy danych właściwe dane i procedura która właściwie je sformatuje.

Podsumowanie

Metody obiektowe polegają na modelowania świata rzeczywistego (domeny systemu), w efekcie nie tracimy żadnej wiedzy modelując (zapisując) “świat” w postaci modelu dziedziny. Tu warto zwrócić uwagę, że wiedzę o tym jak wygląda faktura jako dokument, musi jakiś obiekt posiadać: to obiekt faktura.

W kwestii obiektowego paradygmatu polecam na początek, poza stroną www.omg.org, książki prekursorów OOAP: Booch Grady, Rumbaugh James, Jacobson Ivar, oraz Eda Yourdona Analiza Obiektowa.

oraz:

Wprowadzenie

Problematyka informacji w firmach, jej kolekcjonowania i przetwarzania jest częstym tematem artykułów w prasie specjalistycznej jak i opisem zakresów projektów IT. Termin ten jest jednak nie raz nadużywany. W prasie można pozwolić sobie na pewną dowolność jego interpretacji jednak w opisie zakresu projektu analitycznego pozycja o nazwie ?Zdefiniowanie potrzeb informacyjnych firmy? może rodzić poważne kłopoty z odbiorem tej części projektu gdyż tu na dowolność interpretacji nie powinno być miejsca.

Potrzeby informacyjne firmy

Czym są? Aby określić potrzeby informacyjne firmy musimy wskazać (opisać) to jaką wiedzę chcemy posiadać. To jest najtrudniejsze. Potem, budujemy listę faktów, których rejestracja jest wymagana do zgromadzenia potrzebnej wiedzy. Kolejnym krokiem jest określenie jakie dane są wymagane do opisu tych faktów. Następnie budujemy model pojęciowy i strukturę danych opisujących te fakty. Na koniec implementujemy ten model danych tworząc Bazę Danych.

Poniżej opisałem to w jaki sposób powstała akurat taka kolejność i to, że Wiedza nie istnieje, istnieją dane. Z modelem staje się to nieco prostsze.

Definicje

Informacja – 1. ?wiadomość o czymś lub zakomunikowanie czegoś?, 2. ?dział informacyjny urzędu, instytucji?, 3. ?dane przetwarzane przez komputer? (źr. Słownik PWN)

Informacja – Informacja (łac. informatio – wyobrażenie, pojęcie) to pojęcie o wielu definicjach w różnych dziedzinach. Zasadniczo mamy dwa podstawowe punkty widzenia na informację. Pierwszy, który można nazwać obiektywnym i wywodzi się z fizyki i matematyki, gdzie informacja oznacza pewną własność fizyczną lub strukturalną obiektów, i drugi, subiektywny (kognitywistyczny), gdzie informacją jest to, co umysł jest w stanie przetworzyć i wykorzystać do własnych celów. (źr. Wikipedia).

Dane – 1. ?fakty, liczby, na których można się oprzeć w wywodach?, 2. ?informacje przetwarzane przez komputer? (źr. Słownik PWN)

Dane (ang. data; z łac. datum – to, co jest dane) ? w informatyce zbiory liczb i tekstów o różnych formach. Są one używane przez komputery do obliczeń oraz są prezentowane, czy też przetwarzane cyfrowo. Takie tematyczne zbiory informacji są nazwane bazami danych. Bazy Danych są podstawową częścią systemów zarządzania informacją, systemów zarządzania projektami czy katalogów produktów. Układ danych przynoszący konkretną informację to komunikat. (źr. Wikipedia).

Wiedza – 1. ?ogół wiadomości zdobytych dzięki badaniom, uczeniu się itp.; też: zasób informacji z jakiejś dziedziny?, 2. ?znajomość czegoś? (źr. Słownik PWN)

Wiedza – termin używany powszechnie, dotychczas nie posiada jeszcze ogólnie uznanej definicji. Za klasyczną uznaje się definicję Platona z dialogu Teajtet, gdzie Sokrates w rozmowie z Teajtetem dochodzi do sformułowania definicji, że wiedza to prawdziwe, uzasadnione przekonanie. Nowa Encyklopedia Powszechna definiuje wiedzę jako ?ogół wiarygodnych informacji o rzeczywistości wraz z umiejętnością ich wykorzystywania?. (źr. Wikipedia)

Na bazie tych definicji można stworzyć następujący model pojęciowy:

? Fakty są komunikowane przez wiadomości, wiadomość komunikuje fakt

? Fakty niosą informacje, informacja to pojmowanie faktów

? Informacja stanowi widzę, wiedza to zbiór informacji

Informacja a wiedza

Jak widać relacje te nie są skomplikowane jednak ich obraz pokazuje, że samo stwierdzenie ?baza wiedzy? czy ?system informacyjny? nabiera nieco innej perspektywy. Proszę zwrócić uwagę na to, że nie ma tu bezpośredniego powiązania Wiadomości z Wiedzą. Można jednak powiedzieć, że wiadomości, jako opis faktów, niosą informacje, które budują naszą wiedzę.

Czym są dane?

Otóż powyższe cztery pojęcia są tak na prawdę niematerialne. Funkcjonują w naszych umysłach. Dopiero ich utrwalenia w postaci zapisu na trwałym nośniku (ot choćby piórem na papierze) czyni z faktów dane.

Mamy więc kolejny element tego modelu: Dane reprezentują Fakty, Fakty są dokumentowane przez Dane.

Jaki z tego wniosek? Pierwszy jaki się nasuwa to to, że pojęcie Bazy Wiedzy jest troszkę ?naciągane?. Dlaczego? Bo Wiedza to sposób interpretacji otrzymywanych Wiadomości przez człowieka a proces ten jest subiektywny i zależy od kontekstu przekazanych wiadomości. Kontekst zaś budują wiadomości poprzedzające. Podam przykład.

Wiadomość: ?w wyniku zderzenia samochodów zginęła jedna osoba?. Na jej podstawie zbudujemy sobie obraz kolizji na drodze i ludzkiej tragedii. Wiadomość ta jednak poprzedzona (np. audycją radiową podaną godzinę wcześniej) przekazem o treści ?Na drodze ekspresowej nr 48, w wyniku oblodzenia, miał miejsce wielki karambol, zderzyło się 37 samochodów? wywoła niemalże ulgę, że w takiej wielkiej katastrofie zginęła tylko jedna osoba.

Skoro więc nasza wiedza bazuje na wiadomościach a ich interpretacja (pojmowanie) bazuje na kontekście to czym jest ta Wiedza? Kluczem tu są dane, to jak są magazynowane. Inaczej mówią to jak są reprezentowane po ich utrwaleniu (rysunek powyżej).

Powoli nasuwa się już chyba świadomość tego, że dobra baza wiedzy (czym by nie była) musi przechowywać dane opisujące i fakty i ich kontekst. Po drugie sposób reprezentacji danych (ich zapisu, utrwalaniu) powinien być jak najmniej podatny na ich subiektywną interpretację. Jak to osiągnąć?

Model pojęciowy jako model rzeczywistości

Dobrnęliśmy do pojęcia reprezentacji danych. Najprostszą reprezentacją danych jest niestrukturalny tekst, popularnie zwany prozą . Proszę zwrócić uwagę na to, że nawet ten tekst to dane. Jaki z nim problem? Ano trudno jest w tej postaci wskazać wiadomość, fakt, informację czy w końcu odpowiedzieć na pytanie gdzie jest tu ta Wiedza. Wyobraźmy sobie dodatkowo, że ten tekst (ten artykuł) pozbawiono ilustracji. Stałby się praktycznie tak niejednoznaczny, że każdy jego czytelnik miał by prawo do jego własnej interpretacji (na szczęście są tu te diagramy, dostępne w wersji PDF, adres URL pełnej wersji artykułu na końcu tekstu).

Powstaje potrzeba takiego zapisu danych by były one zapisem faktów i niosły jednak ich kontekst, na tyle na ile to możliwe. Jaki to zapis?

Struktura informacji

Aby dane były możliwie jednoznaczne i niosły kontekst muszą być zapisane w sposób strukturalny i muszą mieć zdefiniowaną ich interpretację czyli tak zwane metadane. Co to oznacza?

Za słownikiem języka polskiego: struktura – 1. ?układ i wzajemne relacje elementów stanowiących całość?, 2. ?całość zbudowana w pewien sposób z poszczególnych elementów?

Dodatkowo za WIKI: Metadane ? czyli ?dane o danych?, [?]w przypadku bazy danych, metadanymi są definicje tabel, widoków, kluczy itp. natomiast danymi ? zawartość tych tabel, widoków (czyli rekordy). W systemach zarządzania dokumentami metadane określa się mianem metryki dokumentu.

Tak wiec mamy już wstępną odpowiedź. Ale może przykład:

?Po jutrze, godzinę po Wiadomościach odbędzie spotkanie członków klubu twórców niejednoznacznych tekstów w miejscu tym samym co ostatnio. Będziemy rozmawiali między innymi o tym jak jeszcze wydajniej zanudzać czytelnika, rozważać aspekty wpływu nudnych tekstów na stopień senności adresata przekazu oraz ocenimy wpływ naszych prac na tak zwane zamulanie sieci Internet.?.

Taki przekaz pozbawiony kontekstu jakim jest między innymi dokładny czas nadania tej wiadomości praktycznie nie nadaje się do jakiejkolwiek interpretacji (co nie zmienia faktu, że w takiej postaci często podawane są zapowiedzi spotkań w zaproszeniach przekazywanych pocztą elektroniczną)

Zapis strukturalny wyglądał by tak:

[Rodzaj zdarzenia]: Spotkanie

[Uczestnicy]: członkowie Klubu Twórców Niejednoznacznych Tekstów

[Termin]: 2008-10-06, godzina 20:00

[Miejsce]: klub Grafoman przy ulicy Nudnej 24

[Treść]: Będziemy rozmawiali między innymi o tym jak jeszcze wydajniej zanudzać czytelnika, rozważać aspekty wpływu nudnych tekstów na stopień senności adresata przekazu oraz ocenimy wpływ naszych prac na tak zwane zamulanie sieci Internet.

Powyżej mamy strukturalny tekst (składa się z oddzielnych powiązanych części), i metadane którymi są nazwy (opisy) po lewej stronie dwukropków w kwadratowych nawiasach. Gdyby był to dokument (treść) w wersji oryginalnej to pierwsze cztery elementy tej struktury mogły by stanowić tak zwaną metrykę całego dokumentu. Metryka dokumentu to nic innego na strukturalny opis zawartości (najczęściej skrócony) niestrukturalnego tekstu. Tak więc mamy opis tego co nazywamy reprezentacją danych.

Zaczynają się schody ? model dziedziny

Na początek model danych. Model danych (bazy danych) to zbiór zasad (specyfikacji), opisujących strukturę danych w bazie danych. [?] Definiuje się tę strukturę danych poprzez specyfikację reprezentacji dozwolonych w modelu obiektów (encji) oraz ich związków. (źr. WIKI)

Model danych to opis struktur, które posłużą do kolekcjonowania danych. Jest więc to nic innego jak struktura obrazująca pojęcia i powiązania między nimi. Opisem takich struktur są między innymi diagramy takie jak te w tym artykule (co nie zmienia faktu, że są ludzie opisujący struktury danych prozą).

[…] Jedyne co nam teraz pozostało to implementacja modelu danych czyli stworzenie bazy danych:

Obecnie coraz częściej można się spotkać z modelami obiektowymi.

Czy baza danych to wiedza?

[…]

Model jawnie pokazuje, że bezpośredni związek z Bazą Danych mają Dane. Dalej już są wyłącznie niematerialne pojęcia czym więc jest Zarządzanie Wiedzą (milcząco zakładam, że zarządzać można czymś materialnym)? Jest to ?przechowywanie danych jednoznacznie zrozumiałych, opisujących określone i ograniczone liczbą fakty interpretowane jako pojmowalna przez adresata informacja?.

Przemyślenia związane z tą ostatnią definicją pozostawiam Państwu. Ciąg dalszy może nastąpi?

Pobierz kompletne opracowanie: