Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: analizy systemowe przedsiębiorstw, projektowanie rozwiązań i przygotowanie do wdrożeń systemów standardowych i dedykowanych.
(aktualizowany 2020) Gdybym miał ocenić statystycznie diagram klas opisywany w książkach o UML , projektach jakie widuję nie tylko w pracach studentów, to powiedział bym, że jest jakiś problem z nimi. Dlaczego? Pokaże to, co moim zdaniem jest chyba nie tak. Szczególnie jak ktoś uważa, że diagram klas do model danych co wprost prowadzi do antywzorca obiektowego o nazwie anemiczny model dziedziny ?*?Ten artykuł to kontynuacja poprzedniego artykułu o modelach dziedziny systemu.
Co można i należy pokazać w wynikach analizy – taksonomia
Przede wszystkim analiza to nie projekt, powinna pokazać obiektywny stan faktyczny. Druga rzecz, o tym już niektórzy zapominają: wynikiem analizy jest dokumentacja zrozumienia, tak więc model analityczny nie może być modelem pokazującym stan po uproszczeniach. To powinien być model rzeczywistości z naniesionymi, zastosowanymi lokalnie, ograniczeniami i uproszczeniami. Innymi słowy: dla fabryki spodni budujemy kompletny model człowieka (manekin) z komentarzem, że tu w użyciu jest część od pasa w dół a nie wmawiamy nikomu, że w tej fabryce człowiek składa sie wyłącznie z bioder i nóg. W przeciwnym wypadku, przyszła rozbudowa systemu będzie co najmniej problematyczna.
Produkt analizy przekazuje informację o tym co zastano, opisuje pojęcia i reguły jakie nimi rządzą. Tak na prawdę, opisać firmę (organizację) to znaczy stworzyć listę pojęć jakimi się w niej operuje (jakimi można ją opisać) i reguły jakie ograniczają swobodę użycia (funkcjonowania) tych pojęć. Model pojęciowy (ich specyfikacja) to semantyka systemu, ograniczenia swobody ich wzajemnego kojarzenia to syntaktyka, i na koniec dziedzinowe ograniczenie swobody ich użycia to pragmatyka. Wkrada się tu także przydatne pojęcie jakim jest entropia czyli miara nieuporządkowania. Tak więc mamy system pojęć, jego entropia (stopień nieuporządkowania) jest ograniczona syntaktyką i pragmatyką specyficzną dla dziedziny i miejsca (organizacji). Co to oznacza dla analizy przedwdrożniowej?
Jednym z celów tej analizy jest odkrycie i zapisanie wiedzy o podmiocie „informatyzowanym”. Jak ją zapisać? Ano właśnie tak: zbudować listę pojęć i wskazać opisane ograniczenia. Doskonałym narzędziem do tego jest diagram klas (odradzam diagram ERD, można go później zbudować w oparciu o model pojęciowy, jeżeli zajdzie taka potrzeba, ale nie należy tych dwóch modeli stosować zamiennie). Diagram klas opisujący taki system pojęciowy to tak zwana przestrzeń pojęciowa (namespace) . Jak to wygląda:
Od razu uwaga: powyższy diagram jest nadmiarowy, w realnym projekcie bym tego tak nie narysował, ale po kolei.???
Podstawowe pojęcia (semantyka) analizowanego systemu to klasy oznaczone niebieskim kolorem. Bardzo często zdarza się, że pewne pojęcia można lub należy poklasyfikować, by przekazać informację o istnieniu tej klasyfikacji. Diagram ten można wiec uzupełnić na dwa sposoby: stosując tak zwane superklasy (uogólnienie, zebranie kilku wspólnych cech) oraz tak zwane stereotypy, czyli znacząc dodatkowo klasy. Klasa uogólniana nazywana jest specjalizacją. Na powyższym diagramie Zamówienie (specjalizacja) jest specyficznym rodzajem Dokumentu (uogólnienie) a każdy dokument to coś będącego jakąś treścią np. na papierze. Zamówienie jednak jest także «obiektem biznesowym», utrwalonym i zrozumiałym pojęciem (bytem) w firmie, do czegoś konkretnego służy.
Jest pewna semantyczna różnica pomiędzy super-klasą a stereotypem, gdyż uważam, że tych pojęć nie można stosować zamiennie. Super-klasa pokazuje, że pewne byty są uogólniane (mają one jakieś wspólne cechy zebrane w tym uogólnieniu) i uogólnienie to – jako pojęcie – jest stosowane „w rozmowie”. Stereotyp wskazuje na pewne istniejące i istotne (chcemy to zakomunikować w dokumentacji) rozróżnienie pomiędzy pojęciami jednak nie jest ono stosowane „w rozmowie”. Można więc uznać, że pojęcie Dokument funkcjonuje „w rozmowie” na równi z pojęciem Zamówienie choć jest to pojęcie (Dokument) abstrakcyjne. Nie istnieje coś takiego jak „ogólny dokument” ale pojęcie to jest powszechnie stosowane w firmach, abstrakcje takie oznaczamy pisząc nazwę takiej klasy kursywą. Można także powiedzieć, że Zamówienie jest «obiektem biznesowym» (coś istotnego, używanego) jednak raczej nikt nie używa tego pojęcia na co dzień. Ten stereotyp informuje czytelnika analizy, że to coś istotnego (jakimś kontekście).
Wpłata jest zdarzeniem, jednak zdarzenie to coś, co na co dzień nie jest traktowane jako równoprawne „słowo” w biznesie. Dlatego w tym przypadku w modelu użyłbym tylko stereotypu «zdarzenie», by wskazać, że jest to coś innego niż «obiekt biznesowy» ale już nie użył bym, abstrakcyjnej superklasy Zdarzenie. Jeżeli jednak w toku projektowania (etap po analizie) uznamy, że chcemy przetwarzać dane o tych zdarzeniach zaprojektujemy dla systemu klasę Zdarzenie.
Obiektem biznesowym jest jednak Dowód Wpłaty (tak na prawdę reprezentuje on to zdarzenie ale nie jest to tożsame pojęcie: stwierdzenie wpłaty nie jest dowodem wpłaty). Te niuanse są bardziej oczywiste (mam nadzieję :)) na przykładzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu także ewidentnie, że Klient jest wyłącznie Osobą.
Diagram ten zawiera także pewne reguły biznesowe (ograniczenia entropii, czyli swobody). Są to liczebności naniesione na skojarzenia (asocjacje), linie łączące klasy. Zaznaczono np. że Sprzedawca może mieć pod opieką klientów, także żadnego, jednak klient musi mieć i tylko jednego opiekuna. Brak linii łączącej dwie klasy świadczy zaś o tym, że nie ograniczają się one nawzajem w żaden sposób np. Wpłaty w żaden sposób nie wpływają na Sprzedawcę i odwrotnie. Istnieje jedynie pośredni związek mówiący, że można skojarzyć Wpłatę ze Sprzedawcą, elementem kojarzącym jest Faktura i jest ona także kontekstem tego skojarzenia: Faktura jest produktem procesu Sprzedaży, za który odpowiada Sprzedawca. To jest powód, dla którego model procesów powinien także powstać jako jeden z produktów takiej analizy bo to on zawiera tę właśnie informację.
Model dziedziny to projekt
A teraz model dziedziny, przytoczę diagram użyty w poprzednim artykule:
Jak widać jest pomiędzy nimi istotna różnica. Jej źródłem jest to, że taksonomia to model pojęciowy zaś model dziedziny (w rozumieniu Model z wzorca MVC) to opis przetwarzania. Przede wszystkim model dziedziny nie zawiera pojęć abstrakcyjnych. Dlaczego? No bo ich nie zapisujemy i nie przetwarzamy :)! Po drugie pewne pojęcia zniknęły z modelu (Klient, jest aktorem) bo Klient nie jest przetwarzany, ale dane klienta będą atrybutami (nie zaznaczono) Zamówienia: jest on tu, Klient, zamawiającym. Czytaj więcej o tworzeniu i testowaniu modelu dziedziny.
Tak więc warto zwrócić uwagę na to, że diagram klas diagramowi nie równy, to samo narzędzie może posłużyć do dwóch różnych celów w tej samej dokumentacji. Widać także (mam nadzieję), że próba pokazania na jednym diagramie zarówno systemu pojęć jak i sposobu ich przetwarzania, jako informacji w systemach informatycznych, jest raczej błędnym podejściem. Wydaje mi się, że podejmowanie takich prób świadczy o niezrozumieniu różnicy pomiędzy systemem pojęciowym a modelem przetwarzania informacji. W szczególności gdy dotyczy to systemów obiektowych.
w 2015 roku zmieniła się specyfikacja UML, usunięto pojęcie dziedziczenia i agregacji, sugeruję uzupełnić wiedzę wpisami, które powstały po 2015 roku.
Fowler, M. (1997) Analysis patterns: reusable object models. Menlo Park, Calif: Addison Wesley (The Addison-Wesley series in object-oriented software engineering).
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Czyli taksonomię (niebieskie) przygotowujemy na wczesnym etapie i zatwierdzamy z zamawiającym, a model dziedziny (żółte) przygotowujemy dla siebie (nie pokazujemy klientowi, ale przekazujemy zespołowi wykonawców)?
mniej więcej, chociaż coraz częściej zastępuję taksonomię w postaci diagramu klas, sformalizowanym słownikiem pojęciowym i specyfikacją reguł biznesowych, sprawdza się znacznie lepiej (to klient powinien ze zrozumieniem zatwierdzić, diagram klas tu niestety nie jest łatwy dla biznesu), z tego klient potrafi korzystać (np. uporządkowanie zarządzeń wewnętrznych otp..) http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules …
Z jakich relacji należy korzystać przy budowaniu modelu pojęciowym (taksonomii)? Na przedstawionym schemacie są tylko asocjacje i uogólnienia. Czy zaznaczanie na tym etapie kompozycji czy agregacji jest zasadne? I druga sprawa – na ile głęboko schodzić na etapie modelu pojęciowego. Przykład: zarówno Zamówienie jak i Faktura składa się z pozycji. Na podanym przykładzie zostało to pominięte. Pytanie czy celowo czy dla uproszczenia?
Model pojęciowy to nic innego jak słownikowe podejście „do tematu” podobne do podręcznikowej klasyfikacji roślin czy psów. Stosując diagram klas do tego, należy się wystrzegać „choroby relacyjnej” czyli traktowania pojęć (klas) jak encji (tabel) na diagramach baz danych (ERD) bo mają tu one zupełnie inny sens. Przedstawiony przykład pokazuje wyłącznie logikę pojęciową więc Faktura „jest jakoś” powiązana logicznie z Zamówieniem. Ale! Tu (model pojęciowy) Faktura i Zamówienie to nie „dokumenty” z ich treścią, a pojęcia np. Faktura do „dokument, który…”.
Głębokość uszczegółowienia. Więc wyjaśniło się jedno: na modelu pojęciowym Faktura to zdefiniowane pojęcie – termin, więc nie ma żadnych pozycji faktury itp. Można zdefiniować pojęcie „produkt” itp. ale wtedy diagram klas jako model pojęciowy (chcąc pokazać każdy związek logiczny) stanie się nieczytelnym „talerzem spagetti” albo będzie niekompletny (w zasadzie w biznesie wszystkie pojęcia jakoś się ze sobą wiążą). Dlatego od jakiegoś czasu diagramu klas nie używam do modelowania systemu pojęć, poprzestając na słowniku pojęć i specyfikacji dokumentów (obiektów biznesowych). Diagramów klas używam wyłącznie do modelowania dziedziny stylem opisanym jako DDD, czasami do zobrazowania metamodeli.
Mam pytanie ponieważ w książce B. Bruegge i A.H. Duttoit „Inżynieria oprogramowania w ujęciu obiektowym” autorzy wspominają o modelach dziedziny aplikacyjnej i realizacyjnej. Na stronie 40 piszą, że: „Istotą podejścia zorientowanego obiektowo jest połączenie modeli obu dziedzin(…)”. Czy zatem wspomniany w tym artykule (i innych artykułach na tym blogu) model dziedziny mamy utożsamiać z obydwoma modelami ze wspomnianego opracowania?
Hm… dobre pytanie… Generalnie mamy model logiki „systemu” czyli jego „mechanizm działania”. Myślę, że intencją autora było oddzielnie logiki „systemu” od logiki „interakcji z nim”. Jeżeli tak, to odpowiada temu wzorzec MVC-MV-VM. Model dziedziny to taki e„prawa fizyki w tym systemie”. To podstawa jego działania. Ale już „model” interakcji z aplikacją na komputerze a model interakcji na smartfonie mają swoją specyfikę.
MikeR 7 lutego 2017
Dzięki za info. Teraz jest to dla mnie bardziej jasne.
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
Czyli taksonomię (niebieskie) przygotowujemy na wczesnym etapie i zatwierdzamy z zamawiającym, a model dziedziny (żółte) przygotowujemy dla siebie (nie pokazujemy klientowi, ale przekazujemy zespołowi wykonawców)?
mniej więcej, chociaż coraz częściej zastępuję taksonomię w postaci diagramu klas, sformalizowanym słownikiem pojęciowym i specyfikacją reguł biznesowych, sprawdza się znacznie lepiej (to klient powinien ze zrozumieniem zatwierdzić, diagram klas tu niestety nie jest łatwy dla biznesu), z tego klient potrafi korzystać (np. uporządkowanie zarządzeń wewnętrznych otp..) http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules
…
Z jakich relacji należy korzystać przy budowaniu modelu pojęciowym (taksonomii)? Na przedstawionym schemacie są tylko asocjacje i uogólnienia. Czy zaznaczanie na tym etapie kompozycji czy agregacji jest zasadne?
I druga sprawa – na ile głęboko schodzić na etapie modelu pojęciowego. Przykład: zarówno Zamówienie jak i Faktura składa się z pozycji. Na podanym przykładzie zostało to pominięte. Pytanie czy celowo czy dla uproszczenia?
Model pojęciowy to nic innego jak słownikowe podejście „do tematu” podobne do podręcznikowej klasyfikacji roślin czy psów. Stosując diagram klas do tego, należy się wystrzegać „choroby relacyjnej” czyli traktowania pojęć (klas) jak encji (tabel) na diagramach baz danych (ERD) bo mają tu one zupełnie inny sens. Przedstawiony przykład pokazuje wyłącznie logikę pojęciową więc Faktura „jest jakoś” powiązana logicznie z Zamówieniem. Ale! Tu (model pojęciowy) Faktura i Zamówienie to nie „dokumenty” z ich treścią, a pojęcia np. Faktura do „dokument, który…”.
Głębokość uszczegółowienia. Więc wyjaśniło się jedno: na modelu pojęciowym Faktura to zdefiniowane pojęcie – termin, więc nie ma żadnych pozycji faktury itp. Można zdefiniować pojęcie „produkt” itp. ale wtedy diagram klas jako model pojęciowy (chcąc pokazać każdy związek logiczny) stanie się nieczytelnym „talerzem spagetti” albo będzie niekompletny (w zasadzie w biznesie wszystkie pojęcia jakoś się ze sobą wiążą). Dlatego od jakiegoś czasu diagramu klas nie używam do modelowania systemu pojęć, poprzestając na słowniku pojęć i specyfikacji dokumentów (obiektów biznesowych). Diagramów klas używam wyłącznie do modelowania dziedziny stylem opisanym jako DDD, czasami do zobrazowania metamodeli.
Mam pytanie ponieważ w książce B. Bruegge i A.H. Duttoit „Inżynieria oprogramowania w ujęciu obiektowym” autorzy wspominają o modelach dziedziny aplikacyjnej i realizacyjnej. Na stronie 40 piszą, że: „Istotą podejścia zorientowanego obiektowo jest połączenie modeli obu dziedzin(…)”. Czy zatem wspomniany w tym artykule (i innych artykułach na tym blogu) model dziedziny mamy utożsamiać z obydwoma modelami ze wspomnianego opracowania?
Hm… dobre pytanie… Generalnie mamy model logiki „systemu” czyli jego „mechanizm działania”. Myślę, że intencją autora było oddzielnie logiki „systemu” od logiki „interakcji z nim”. Jeżeli tak, to odpowiada temu wzorzec MVC-MV-VM. Model dziedziny to taki e„prawa fizyki w tym systemie”. To podstawa jego działania. Ale już „model” interakcji z aplikacją na komputerze a model interakcji na smartfonie mają swoją specyfikę.
Dzięki za info. Teraz jest to dla mnie bardziej jasne.
Pingback: Semiotyka - czyli dlaczego sama notacja to za mało - Jarosław Żeliński IT-Consulting