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.
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.
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.
„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.”
LOL
A może po prostu domena nie jest „prosta” i model musi mieć postać taką jak mieć musi…
W tym miejscu na scenie powinna pojawić się „Barbie consultant” ze swą nieśmiertelną kwestią: „Analysis is hard, let’s go shopping”.
Ale na poważnie:
– zapis metod w notacji UML może być niezrozumiały, dlatego nie trzeba się go po prostu trzymać – chodzi o wyrażenie odpowiedzialności
– zagubionym adeptom można zasugerować następującą radę: należy zastanowić się jaki jest cel tworzenia danego artefaktu? W zdrowej organizacji powinno być to zrozumienie i przekazanie wiedzy. Czy diagram rzeczowników i powiązań pojęciowym pomiędzy nimi jest wystarczający do głębokiego zrozumienia dynamiki i przekazania tej wiedzy?
ja zawsze mówię: na początek stare dobre karty CRC :), w klasie wystarczy nazwać operację (nazwa polecenia), metody to algorytmu, można je opisać słownie, tablica decyzyjną, pseudokodem, ale metody to faktycznie technikalia…
Witam,
Przeczytałem artykuł i szczerze mówiąc dużo bicia piany o semantykę i nie wiem czy komuś coś rozjaśniłeś w głowie Jarku. Proponuję następnym razem zamodelować kilka diagramów zamiast tworzyć laborarty.
Cytowana przez Ciebie osoba pisze „Model dziedziny jest elementem analizy systemowej, ukazującym biznesowe struktury danych i zależności pomiędzy nimi.” Kluczem do zrozumienia jest «biznesowa struktura danych» – osobiście nie widzę nic rażącego w tym sformułowaniu.
Pracuje w organizacji gdzie istnieje model obiektów biznesowych zamodelowany na różnych poziomach abastrakcji m.in. też konceptualnym. Są to modele wspolne dla calego biznesu, do których IT ma dążyć. Przykładowo na poziomie konceptualnym mamy zdefioniwane relacje miedy obiektami Umowa – Klient – Produkty. Kazdy niższy poziom abstrakcji uszczegóławia te relacje i dokłada nowe obiekty biznesowe. W modelu nie ma atrybutów czy metod. Czyli formuła „biznesowe struktury danych i zależności pomiędzy nimi” jest dla mnie jak najbardziej prawdziwa.
Oczywiście Context is the King i możliwe, że ów autor podawał sprzeczne przykłady do przytoczonej definicji a ja się na siłe doszukuję prawdy.
aha, kolejna sprawa jest tez taka, że model domeny to nie to samo co logiczny model danych (reprezentowany czesto przez diagram klas) i fizyczny model danych (np. model tabeli na bazie) aplikacji.
odpowiadam:
A ja widzę i to bardzo, gdyż model dziedziny w ujęciu obiektowym, a o takim pisze autor „ucząc” ludzi UML’a, nie ma nic wspólnego z modelem danych. Gdyby to było szkolenie z analizy strukturalnej, mowa była by nie o UML/diagram klas a o diagramie ERD i tekst brzmiał by „Model pojęciowy jest elementem analizy strukturalnej, ukazującym biznesowe struktury danych i zależności pomiędzy nimi.” i zilustrowany byłby diagramem ERD, słowa bym nie powiedział. Tego typu teksty „piętnuję”, bo to pseudowiedza ludzi, którzy mając być może duże doświadczenie w analizie strukturalnej (modele ERD i DFD), ubierają to w zorientowaną obiektowo notacje UML nie zmieniając podejścia strukturalnego, w efekcie student cytuje mi taki tekst i pyta mnie czym się różni diagram klas od ERD.
Wszystko to co napisałeś dalej jest opisem relacyjnego modelu danych i z obiektowym niestety nie ma nic wspólnego. Absolutnie nie oceniam organizacji w której pracujesz (praktyka budowania relacyjnego modelu dla firmy jest dobra, rzecz w tym, że model relacyjny jest stratny stąd „moda na obiektowość”, która nie ma tej wady), ale w paradygmacie obiektowym nie ma pojęcia relacja, to cecha modelu relacyjnego danych. Model obiektowy i UML operuje pojęciem „związek” (asocjacja) a to zupełnie co innego. jest jednak istotna różnica pomiędzy «relacja” a „asocjacja” i tu bicie piany o semantykę ma głęboki sens). Zdanie ?biznesowe struktury danych i zależności pomiędzy nimi? o niczym jeszcze nie mówi, ale umieszczenie go w treści opisu notacji UML o obiektowej analizie czyni je z gruntu fałszywym, gdyż w paradygmacie obiektowym nie istnieje pojęcie „biznesowe struktury danych”. To pojęcie rodem z analizy strukturalnej i relacyjnego modelu danych. W metodach obiektowych nie ma mowy o danych (fizyczna baza danych, jakakolwiek, to implementacja utrwalania), a atrybuty to ostatni etap analizy o projektowania obiektowego.
Problem widzę w tym, że bardzo wielu analityków i programistów projektuje i pisze oprogramowanie metodami strukturalnymi, czyli analizuje dane, modeluje je, normalizuje, i na koniec pisze funkcje operujące na tych danych. To, że się ktoś np. przestawia z Pascala czy procedur wbudowanych bazy Oracle, na javę czy .Net, a diagramy ERD zamienia na źle tworzone diagramy UML (np. widuje klucze obce na diagramach klas, porażka!) nie czyni z tego programisty „obiektowca”… Projekty w rodzaju analiza i model danych, funkcje napisane w javie, kod pogrupowany na jakieś tam podprogramy-klasy i monstrualne mapowanie ORM (czasami jak widzę u klientów pliki konfiguracyjne dla Hibernate to mi ręce opadają) to porażka obiektowa…
A ostatnie Twoje zdanie to teza, czy też się z tym nie zgadzasz? Bo ogólnie to jest tak: w metodach obiektowych model dziedziny to kolekcja współpracujących obiektów (a nie powiązanych relacyjne danych). Skoro obiekty współpracują, to na wstępnym etapie analizy i projektowania mają operacje i nie mają atrybutów. To właśnie odróżnia metody strukturalne od obiektowych.
Zapewniam Cie, że karty CRC w ogóle nie maja „na sobie” żadnych atrybutów, a są powszechnie stosowane jako metoda nauki myślenia obiektowego i analizy obiektowej – to nie jest przypadek… Zacytuje jedną, z książek chyba nawet Jourdona: jeżeli ktoś nie potrafi zaprojektować systemu tylko jako zestawu komunikujących się obiektów bez zajmowania się zbędnymi na rym etapie ich atrybutami, ten nigdy nie bezie obiektowym programistą. Cóż, samo zastosowanie obiektowych narzędzi nie uczyni ani projektu ani programu „obiektowym”.
„Wszystko to co napisałeś dalej jest opisem relacyjnego modelu danych i z obiektowym niestety nie ma nic wspólnego.”
Zapewniam Cie, ze nikt nie probowal stworzyc relacyjnego modelu danych dla kilku tysiecy aplikacji (systemow). Przynajmniej nie w tej organizacji. Model domeny jest abstrakcją biznesową – aplikacja pracuje w tej domenie i ma swoje modele logiczny i fizyczny. Celem jest aby bylo traceability miedzy tymi modelami. Czyli skoro juz o semantyce dyskutujemy, stawiam teze, że mówienie „model domeny aplikacji xy” jest logicznie niepoprawny, ponieważ to nie aplikacja ma model dziedzy a w nim TYLKO pracuje.
Widze, że masz spory problem ze słowem «dane», jesli rozumiesz je jako ciagi danych z bazy to zaczynam rozumieć skąd nieporozumienie. Zauwazyłem już w jednym z Twoim poprzednich wpisów na temat Architektury Korporacyjnej i TOGAFa, że strasznie Ci nie leży koncept danych – piję tutaj to „Data architecture” z ADM. Nie chciałem tego juz tam komentować, daltego tutaj o tym wspomnę. Jak ktoś pisze „data” to nie zawsze mysli „database”.
Proponuje przeczytać książke Architektura Korporacyjna jako strategia (daje kontekst), a potem manuala do TOGAF 9 (daje wiedze) – wiele to rozjasnia w kwestii projektowania aplikacji w złożonych strukturach biznesu.
Odniosłem się tylko do tego co napisałeś, nie chodzi o liczbę aplikacji a o to, że „relacje” to nie „analiza obiektowa”. Specyfikacja „obiektów biznesowych” rozumianych jako obiekty UML to kolekcja, mogą być co najwyżej pokazane związki użycia lub logiczne asocjacje pokazujące np. to, że umowa i klient mogą zostać powiązane na bazie PESEL klienta. Jednak między obiektami nie ma relacji (zakładając, że słowo relacja ma swoje znacznie na diagramie ERD). Być może nadmierny skrót myślowy jaki zastosowałeś doprowadził do nieporozumienia.
Pojęcie modelu domeny opisałem, w metodach obiektowych aplikacja implementuje cały model danej domeny lub jego część, kilka aplikacji (komponentów) może implementować różne obszary (części modelu) domeny. Tak więc mamy obiektowy model dziedziny/domeny a aplikacja implementuje całość lub wybraną część tego modelu. Nie potrafię zinterpretować pojęcia „aplikacja pracuje w modelu dziedziny”.
Nie mam problemu z pojęciem dane, w tym kontekście używam rozłącznie słowa dane jako „elementy modelu danych” rodem z ERD, i atrybuty obiektów rodem z OOAD. To, że jakaś konkretne cyferki tu to DANE a tam to ATRYBUTY nie uprawnia do uogólniania pojęcia dane. Słowo dane (data) ma w j.poslkim wiele znaczeń zależnych od kontekstu, dlatego warto te znaczenia rozgraniczać lub w takich tekstach używać tylko w jednym znaczeniu by uniknąć nieporozumień. Oprogramowanie obiektowe nie przetwarza danych a zarządza współpracą obiektów. Owszem z perspektywy użytkownika dostaje on jakieś dane ale to inna perspektywa. Znam obie sugerowane książki, i nie ja jeden uważam, że TOGAF zawiera pewne nieścisłości terminologiczne. Dotyczy to zresztą całego podejścia The Open Group. Otarłem się o projekt tłumaczenia słownika na język polski pojęć TOGAF (ich glossariusz) i wiem od tych ludzi, że było z tym bardzo ciężko… problem z tym jest także w dość niespójnej notacji ArchiMate bo wykorzystuje ona pojęcia rodem z UML ale właśnie np. symbol data (obiekt danych) jest realizacją obiektu biznesowego na poziomie procesów … troszkę to do siebie nie gada tym bardziej, że autorzy sami piszą, że uszczegółowienie tej części należy robić diagramem klas UML.
Początkowo entuzjastycznie podszedłem do TOGAF ale w miarę zagłębiania się nabierałem wrażenia, że koncepcja jest mocno niedopracowana. Osobiście uważam, że Siatka Zachmanna jako struktura opisu organizacji w postaci kolekcji modeli sprawdza się znacznie lepiej, jej relatywnie mała popularność to chyba efekt dużych nakładów the Open Group na promocje opatentowanego TOGAF+ArchiMate (oba wymagają opłat licencyjnych)… poza tym Architektura Korporacyjna doskonale sobie radzi na narzędziach OMG gdzie śladowanie nie stanowi żadnego problemu za to cały zestaw narzędzi i technik OMG jest za darmo a pracują nad nimi po pojedyncze firmy a całe ich rzesze.
Uzupełniając: daleki jestem od ogólnej oceny Architektury Korporacyjnej, mam jakieś swoje przemyślenia i jak czytam różne książki nie ja jeden. Uważam, jednak mieszanie lub nawet dopuszczanie do niejednoznaczności pomiędzy metodami strukturalnymi a obiektowymi jest bardzo szkodliwe. „Kolekcja obiektów” vs. „dane uporządkowane w modelu relacyjnym przetwarzane przez zestaw procedur” to skrajnie różne systemu. Nie mają z sobą nic wspólnego, więc współdzielenie jakichkolwiek pojęć z tych dziedzin jest co najmniej ryzykowne. metody obiektowe to implementacja modelu domeny a metody strukturalne to przetwarzanie uporządkowanych danych opisujących daną domenę, a to nie jest to samo.
?Odniosłem się tylko do tego co napisałeś, nie chodzi o liczbę aplikacji a o to, że ?relacje? to nie ?analiza obiektowa?. Specyfikacja ?obiektów biznesowych? rozumianych jako obiekty UML to kolekcja, mogą być co najwyżej pokazane związki użycia lub logiczne asocjacje pokazujące np. to, że umowa i klient mogą zostać powiązane na bazie PESEL klienta. Jednak między obiektami nie ma relacji (zakładając, że słowo relacja ma swoje znacznie na diagramie ERD). Być może nadmierny skrót myślowy jaki zastosowałeś doprowadził do nieporozumienia. ?
Asocjacja z UML to tez jest relacja. Association is a relationship between classifiers which is used to show that instances of classifiers could be either linked to each other or combined logically or physically into some aggregation. – http://www.uml-diagrams.org/association.html Czyli fakt, że dwa obiekty pozostaja w relacji nie oznaczy odrazu, że nalezy użyci diagramu ERD aby tą relację przedstawić.
?Pojęcie modelu domeny opisałem, w metodach obiektowych aplikacja implementuje cały model danej domeny lub jego część, kilka aplikacji (komponentów) może implementować różne obszary (części modelu) domeny. Tak więc mamy obiektowy model dziedziny/domeny a aplikacja implementuje całość lub wybraną część tego modelu. Nie potrafię zinterpretować pojęcia ?aplikacja pracuje w modelu dziedziny?. ?
Tutaj sie akurat zgadzamy, chciałem podkreślić fakt, że aplikacja implementuj bądź realizuję część (lub całość) dziedziny/domeny. Czyli mamy np. Domenę Kredyty i w niej aplikacje realizującą kredyty samochodowe dla firm. Ta domena/dziedzina narzuca na aplikacje pewne ograniczenia (nie chce tutaj użyć słowa wymagania bo ono jest nacechowane innymi znaczeniami). Chodzi o to że cykl życia domeny biznesowej jest inny niż cykl życia aplikacji. Np. Wchodzi w życie pewna regulacja ? czyli to ?biznes/życie/rynek? zmienia domenę. Aplikacja musi zostać zmieniona lub staję się niespójna z domeną i traci wartość biznesową.
?Nie mam problemu z pojęciem dane, w tym kontekście używam rozłącznie słowa dane jako ?elementy modelu danych? rodem z ERD, i atrybuty obiektów rodem z OOAD. To, że jakaś konkretne cyferki tu to DANE a tam to ATRYBUTY nie uprawnia do uogólniania pojęcia dane. Słowo dane (data) ma w j.poslkim wiele znaczeń zależnych od kontekstu, dlatego warto te znaczenia rozgraniczać lub w takich tekstach używać tylko w jednym znaczeniu by uniknąć nieporozumień. Oprogramowanie obiektowe nie przetwarza danych a zarządza współpracą obiektów. Owszem z perspektywy użytkownika dostaje on jakieś dane ale to inna perspektywa.?
Będę nieugięty. Angielskie słowo data ma wiele znaczeń. Mamy na przykład Information Data Model i jego specalizację w postaci Canonical Data Model. Ani jedno ani drugie nie musi być ERD.
?Znam obie sugerowane książki, i nie ja jeden uważam, że TOGAF zawiera pewne nieścisłości terminologiczne. Dotyczy to zresztą całego podejścia The Open Group. Otarłem się o projekt tłumaczenia słownika na język polski pojęć TOGAF (ich glossariusz) i wiem od tych ludzi, że było z tym bardzo ciężko? problem z tym jest także w dość niespójnej notacji ArchiMate bo wykorzystuje ona pojęcia rodem z UML ale właśnie np. symbol data (obiekt danych) jest realizacją obiektu biznesowego na poziomie procesów ? troszkę to do siebie nie gada tym bardziej, że autorzy sami piszą, że uszczegółowienie tej części należy robić diagramem klas UML. ?
Akurat byłem w grupie osób pracujących nad tłumaczeniem tego glosariusza. Moim zdaniem większość problemów była natury leksykalnej (jak dobrze oddać sens angielskiej definicji). Faktycznie dwie lub trzy oryginalne definicje były nie najwyższej jakości, jednak na pewno nie mogę się zgodzić, że taksonomia którą oferuje TOGAF jest niespójna. W ArchiMate się tak mocno nie wgryzałem, więc się nie wypowiem.
?Początkowo entuzjastycznie podszedłem do TOGAF ale w miarę zagłębiania się nabierałem wrażenia, że koncepcja jest mocno niedopracowana. Osobiście uważam, że Siatka Zachmanna jako struktura opisu organizacji w postaci kolekcji modeli sprawdza się znacznie lepiej, jej relatywnie mała popularność to chyba efekt dużych nakładów the Open Group na promocje opatentowanego TOGAF+ArchiMate (oba wymagają opłat licencyjnych)? poza tym Architektura Korporacyjna doskonale sobie radzi na narzędziach OMG gdzie śladowanie nie stanowi żadnego problemu za to cały zestaw narzędzi i technik OMG jest za darmo a pracują nad nimi po pojedyncze firmy a całe ich rzesze.?
Oczywiści, AK jest pewną koncepcją i jako taka jest ona niezależna od narzedzi którymi się posłuzymy (z jednej bądź drugiej stajni). Osobiście uważam ze TOGAF dostarcza dużo więcej narzędzi i tak potrzebnej ? choć wnioskując z tej dyskuji ? taksonomii niż siatka Zachmanna.
Swoją drogą OMG też perfekcjonistą nie jest. Specyfikacja choćby BPMNa jest… hmmm bardzo elastyczna, co prowadzi do tego, że prawie każdy diagram w tym języku da się obronić jako poprawny. Z drugiej strony standard BMM, o którym sam pisałeś, został wydany bez notacji, czego zupełnie nie jestem w stanie zrozumić. Swoją drogą jeden i drugi znam, używam i polecam 🙂
Co do ostatniego zdania do nie do końca je rozumiem, więc napisze dla potomnych. TOG nie jest pojedyncza firmą a konsorcjum. Podobnie jak w przypadku OMG w rozwijaniu standardów uczestniczy wiele firm. To że ich produkty są płatne, mnie też wkurza.
PS. Dzieki za dobra dyskusje, podoba mi sie.
„Association is a relationship between classifiers which is used to show that instances of classifiers could be either linked to each other” pod warunkiem, że one są „linked”, a obiektów się raczej nie tak wiąże. Owszem, nie ma zakazu trwałego łączenia obiektów bo pozwala na to chyba każdy obiektowy język, takie połączenie jednak oznacza, że ID jednego obiektu jest wartością atrybutu drugiego, ale to właśnie „trwałe relacyjne powiązanie”. Nie neguje tego. Ja staram się pokazać, że obiektowy paradygmat to co innego niż możliwości (faktem jest, że duże) UML czy obiektowych języków programowania (można napisać duży program będący jedna wielka klasą). Można w javie napisać program nie mający z metodami obiektowymi nic wspólnego mimo, że to jego UMLowa dokumentacja może być poprawnym zestawem diagramów.
„Angielskie słowo data ma wiele znaczeń. Mamy na przykład Information Data Model i jego specalizację w postaci Canonical Data Model.” Owszem ale jest różnica pomiędzy „Canonical Data Model” a „Object oriented domain model”.
Takie dyskusje kształcą więc i mi nie pozostaje mi nic innego jak także podziękować. Nigdy nie ukrywałem, jest wręcz elementem mojej strategii 🙂 to, że jestem purystą formalnym. Jednak nie dlatego, by pacyfikować projekty ortodoksją. To efekt dwóch rzeczy: teoria poznania jako restrykcyjne podchodzenie do semantyki, pozwala uniknąć niejednoznaczności. Druga rzecz, to zdefiniowanie ideału pozwala ocenić (zmierzyć) odstępstwo konkretnego projektu od niego. To pozwala ocenić ryzyko takiego projektu. Fizyka ma np. nieistniejące w naturze ciało doskonale czarne, po co? By móc ocenić błąd rzeczywistych obliczeń. Zdaję sobie sprawę, że to filozofia, ale taki mam cel :), nie tylko analizować i modelować ale w 100% rozumieć :).
A przy okazji, nie tylko BPMN jest elastyczny, każda notacja taka jest, to dlatego, praktycznie każdy model, w BPMN także, podobnie jak w UML, dla swej jednoznaczności, wymaga określenia (opisania) pragmatyki.
Polecam prezentację, jej pierwsza część dobrze oddane sens wydzielania dziedziny, zawiera bardzo rzeczowy opis DDD:
http://www.slideshare.net/KonradRussa/dddprezentacja
Witam. Napisał Pan „… 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”
Troszkę się pogubiłem już powiem szczerze. Wydawało mi się czytając inne Pana wpisy, że atrybuty/wartości atrybutów to nie dane,a z tego zdania wynika że jednak dane. Proszę o rozjaśnienie.
Atrybut obiektu generalnie to jego cecha. Np. kolor karoserii samochodu jest (może być) jego atrybutem, ale bagażnik i jego zawartość też jest atrybutem samochodu. Mamy «dane przechowywane» i «dane opisujące obiekt» i to nie jest to samo. Załóżmy, że mam w kieszeni paragon z kawiarni, ale też jestem człowiekiem mającym pewne cechy, np. datę urodzenia. Data urodzenia to atrybut opisujący mnie. Treść paragonu, to także atrybut, jego wartość to dokument zawierający dane o tym, że kupiłem kawę, jaką i kiedy.
Ogromnym problemem dla wielu ludzi jest odejście od postrzegania danych rozumianych jako tabele baz danych. Niestety nadal na wielu uczelniach uczy się studentów, że dane przechowuje się w bazie danych, najlepiej relacyjnej, że obiekt to „połączone dane i funkcje je przetwarzające”. Taki model to prehistoria. Mamy czasy BigData, repozytoria w chmurze bez SQL, i wszechobecne niestrukturalne dane.
Obiekt ma atrybuty, mają one różne wartości, ale to czym są wartości tych atrybutów zależy od roli obiektu. Jeżeli jest to obiekt repozytorium, to jego atrybut (jeden!) będzie np. przechowywał skomplikowany zestaw danych w postaci ciągu znaków XML. Jeżeli będzie to obiekt reprezentujący kalkulator upustów, wartości atrybutów mogą przechowywać np. aktualny status (usługa dostępna/niedostępna), ale też obiekt taki może nie mieć atrybutów w ogóle, tylko operacje.
„… Mamy ?dane przechowywane? i ?dane opisujące obiekt?” rozumiem z tym, że ciężko mi sobie wyobrazić w świecie wirtualnym daną opisującą obiekt, która nie jest przechowywana w bazie czy to relacyjnej, dokumentowej czy każdej innej.
Więc dla mnie to tak: atrybut obiektu to jego cecha (a żeby być ścisłym nazwa tej cechy). A wartość tej cechy to dana/dane zapisane w dowolnej postaci np. Xml.
Fizyczne przechowywanie (utrwalanie) to tylko implementacja zachowywania treści na stałe, łączenie tego w jedno na modelu jest szkodliwe. To jak faktury: treść faktur przechowujemy, ale salda także, niby dane o fakturach a jednak nie to samo … Np. atrybutem faktury jest wartość brutto, status faktury (np. przeterminowana) jednak nie jest jej atrybutem, ale jest jej cechą… Tak więc treść faktury to np. XML (np. w pliku JPK) ale to czy jest opłacona, już nie jest w tym XML.