Dziesięć lat temu pisałem o informacji i jej strukturalnym charakterze, wpis kończył się zdaniem:

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? (źr. : Potrzeby informacyjne firmy ? Zarządzanie wiedzą | Jarosław Żeliński IT-Consulting)

Kontynuacją cytowanego tekstu będzie dzisiaj kwestia informacji i powiązanych z nią wymagań na oprogramowanie. Każdy projekt wytworzenia, lub nawet tylko dostarczenia gotowego, oprogramowania powinien mieć co najmniej dwie warstwy opisu: (1) co chcemy stworzyć i (2) jak to chcemy stworzyć. Pierwsza to tak zwana warstwa abstrakcyjna opisująca mechanizm funkcjonowania systemu. Druga to logiczna architektura systemu czyli pomysł na realizację (model Platform Independent). Na podstawie modelu PIM developer projektuje oprogramowanie, które wykona (Platform Specific Model). Jednak często dostawca istniejącego oprogramowania chce porównać logikę oprogramowania, które oferuje, z logiką opisaną jako wymaganą. Tu potrzebny jest nie model architektury PIM a model informacyjny opisujący logikę biznesową ale nie narzucający architektury (bo ta już istnieje).

Bardzo często głównym celem biznesowym, i zarazem wymaganiem, jest zarządzanie informacją czyli skończoną liczbą typów dokumentów o ustalonej (lub wymagającej ustalenia) treści i strukturze. Niestety często jest tak, że struktura dokumentów ulega pewnym zmianom przy zachowaniu głównego celu dla jakiego powstały, co utrudnia zadanie ale nie jest prawdę, że jest to powód do permanentnego modyfikowania oprogramowania. Odporność (gotowość) aplikacji na zmienność treści jest tu wymaganiem i system powinien sobie z tym poradzić.

W takich przypadkach modelując system warto skupić się wyłącznie na informacji i na tym jak jest ona zarządzana, pozostawiając pewne detale architektury dostawcy, który z zasady – jako developer – dysponuje większą wiedzą o dostępnych na rynku technologiach i narzędziach. W takich przypadkach warto opracować tak zwany model informacyjny. Nie jest on jednak ani bazą danych ani modelem dziedziny (przypominam, że obiektowy model dziedziny to komponent architektoniczny wzorca MVC). Jest to model związków logicznych między dokumentami opisujący mechanizmy korzystania z nich.

O informacji

Kluczowymi pojęciami w tym obszarze analiz są: nośnik, dokument, informacja, treść, dane, wiadomość, które można zobrazować w postaci związków pojęciowych (diagram faktów SBVR):

Dokument elektroniczny (obecny jako pojęcie od kilku lat w polskim prawie) jest definiowany jako
stanowiący odrębną całość znaczeniową zbiór danych uporządkowanych w określonej strukturze wewnętrznej i zapisany na informatycznym nośniku danych (na podstawie ustawy KPA¹ i SJP PWN). Innymi słowy: dokument elektroniczny to (uporządkowane) informacje zapisane na elektronicznym nośniku, jednak nośnikiem może być nadal np. papier, więc generalnie pod pojęciem dokument można (należy) rozumieć  “utrwaloną odrębną całość znaczeniową, zbiór danych uporządkowanych w określonej strukturze wewnętrznej”. Skoro odrębną, to także mającą unikalną nazwę, bez czego niemożliwe było by odwołanie się do takiego dokumentu. Kolejna ważna rzecz: znaczenie i struktura. Strukturę dokumentu  określa jego szablon, treść zaś to to co zostanie zapisane z użyciem tego szablonu. Przykład: słowo faktura oznacza obowiązujący szablon dokumentu mogącego, po wypełnieniu, zawierać informacje o tym, kto, komu, co, kiedy i za jaką kwotę sprzedał.

Generalnie informacje są organizowane w nazwane struktury czyli dokumenty. Tu ważna uwaga: ludzie w procesie komunikacji zawsze operują informacją o określonej strukturze, bywa, że jest ona – struktura – prosta, strukturą jest także podział wymiany informacji na odrębne komunikaty, gdzie jeden komunikat to “jedno pole formularza”. Nie zmienia to faktu, że taki komunikat to struktura zawierająca autora i nadawcę komunikatu, odbiorcę komunikatu oraz jego treść, jest to formularz  – struktura – jaką widzimy pisząc np. kolejnego maila.

W efekcie można przyjąć, że wszelkie informacje w organizacjach są zorganizowane z użyciem określonej liczby formularzy, z których każdy ma określoną strukturę. Struktury te nazywamy szablonami dokumentów (formularzy). Nie jest niestety prawdą, że informacje są zorganizowane w bazach danych rozumianych jako system relacyjnych tablic.  Model relacyjny jest nienaturalny i stratny. Człowiek nie jest w stanie korzystać z niego wprost, jest to tylko jakaś technologiczna metoda zapisu danych.

Model informacyjny organizacji

W związku z tym, mamy prawo uznać, że wszystkie informacje w firmie są zorganizowane w użyciem skończonej liczby struktur i nie są to struktury znane z relacyjnych baz danych, są to odrębne i niepołączone (niewspółdzielące danych) formularze, czyli po prostu odrębne dokumenty. Formularze te mogą być jawnie logicznie skojarzone np. na fakturach są nanoszone numery zamówień. Mogą być skojarzone nie wprost, z użyciem określonych reguł np. podatek za dany miesiąc naliczamy na podstawie faktur wystawionych w tym miesiącu albo dany referent ma dostęp do dokumentu, jeżeli ten związany jest ze sprawą aktualnie przydzieloną temu referentowi. Ostatni przykład to typowe dynamiczne powiązanie gdyż przydział referenta do sprawy, a więc także dokumentów z nią powiązanych, może ulegać zmianie w czasie.

Formularze te, ich zawartość oraz logika powiązań pomiędzy nimi, to system informacyjny organizacji. Każda organizacja cechuje się własnym, indywidualnym system informacyjnym, gdyż tylko część dokumentów ma z góry narzuconą strukturę np. prawem lub standardem branżowym. Reszta, struktura wewnętrznych dokumentów,  to decyzje wewnętrzne organizacji.

Postrzegam jako poważny błąd uznanie, że model informacyjny to jednolita relacyjna struktura danych (pojęć) podobna do (budowana na wzór) ontologii². Po pierwsze relacyjny model  danych przechowuje nie dokumenty a pojęcia, uznając związki między pojęciami za stałe relacje (co nie zawsze jest prawdą). Po drugie usuwanie redundancji w procesie zapisu danych z formularzy wymaga ich odtworzenia przy każdej próbie odtworzenia konkretnego dokumentu. Tak więc taka relacyjna baza danych nie przechowuje żadnych dokumentów a jedynie zbiór trwale powiązanych pojęć. Bardzo często mówi się, że informacje i wiedza to ontologia. Niestety tak nie jest, ontologia to system pojęć powiązanych związkami semantycznymi, stanowi opis językowa ale nie jest to wiedza o świecie a wiedza o języku.

Generalnie uważam, że nie jest informacją pojęcie, jego definicja i semantyczne powiązanie z innym pojęciem. To tyko model syntaktyka i semantyka pojęć. Faktura zaś to zbiór pojęć mających określoną strukturę i treść, wartość ma to  – wiedza – kto, co kiedy i od kogo kupił, a nie to co znaczy słowo produkt czy nabywca i jak jest semantycznie on powiązany z pojęciem sprzedawca. To co najwyżej pozwoli nam zrozumieć jaką treść zawiera faktura.

Kolejną wadą podejścia relacyjnego jest to, że baza taka stanowi niepodzielny monolit, w efekcie to co jest możliwe w rzeczywistości (np. praca z fakturą w całkowitym oderwaniu od odpowiadających jej zamówień) jest niemożliwe w systemie relacyjnym. Usuwanie redundancji powoduje także powstawanie dużego narzutu na zarządzanie historią zmian pól baz danych, co nie ma miejsca w rzeczywistych dokumentach (kartoteka klienta zawiera wyłącznie aktualne dane adresowe, historyczne są dostępne w historycznych dokumentach, np. aktualne dane adresowe klienta są w jego kartotece, jego adres z ubiegłego roku znajdziemy na dokumentach wystawionych temu klientowi w ubiegłym roku).

Rok temu pisałem przy podobnej okazji:

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 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. (źr. : Biznesowy model danych ? nie chcemy | | Jarosław Żeliński IT-Consulting).

Problemy jakie wnosi do projektu oparcie się na jednym relacyjnym modelu danych dla całej aplikacji, są znane od lat:

a mimo to nadal jest on stosowany w sposób stanowiący zagrożenie dla całego projektu.

Czym więc jest model informacyjny organizacji? Jest to system szablonów dokumentów czyli ustalonych struktur informacyjnych wraz z logiką ich wzajemnych powiązań czyli asocjacji, świadomie unikam pojęcia relacji.  Relacja to trwały związek, zaś asocjacja to skojarzenie budowane na bazie określonej logiki czy zachodzącego faktu. Przykład: faktura skojarzona jest z osobą, która dokonała sprzedaży, jednak w momencie gdy upłynie termin ważności i faktura nie jest opłacona, jest ona automatycznie kojarzona z windykatorem i sprzedawca przestaje być za nią odpowiedzialny (być może nawet traci dostęp do jej treści, zgodnie z zasadą bezpieczeństwa mówiącą, że pracownicy mają dostęp wyłącznie do informacji potrzebnej do realizowania ich bieżących zadań i obowiązków).

Jak podejść do opracowania i udokumentowania systemu informacyjnego, czyli jak wykonać jego model? Pierwszy krok to zidentyfikowanie dokumentów. Podstawą będzie tu analiza procesów biznesowych i opracowanie ich modeli. Elementarny (atomowy) proces biznesowy to aktywność mająca wejście i wyjście, a konkretnie dane wejściowe i dane, który powstają jako produkt tej aktywności. Te dane to nic innego jak informacje o określonej strukturze. Oznacza to, że na modelu procesów (tu w notacji BPMN) każda aktywność musi mieć skojarzony dokument wejściowy i wyjściowy (element o nazwie DataObect w noracji BPMN), w przeciwnym razie taka aktywność nie powinna się pojawić na modelu.

Powyższy diagram zawiera modele dwóch odrębnych procesów: obsługa zapytań ofertowych oraz obsługa zamówień. Oba diagramy to najniższy poziom modelowania procesów, poziom elementarnych (atomowych) procesów biznesowych. Pozwala zidentyfikować wszystkie dokumenty i ich statusy.

Tu mała uwaga: nie ma żadnego sensu umieszczanie na takich modelach detalicznych prac takich jak “wprowadzenie danych zamawiającego” czy “sprawdzenie salda” bo to są elementy (kroki) procedur. Innymi słowy nie “rysujemy” na diagramach tego jak i w jakiej kolejności wypełnić pola formularza. Po pierwsze zaciemni to obraz, po drugie procedur, reguł biznesowych i słowników nie modelujemy z użyciem BPMN. Robi się to w postaci odrębnych dokumentów lub diagramów.

Powyższy model obrazuje sytuację, w której pewna firma odsyła oferty na zapytania, otrzymując zaś zamówienie, sprawdza je od strony formalnej i realizuje. Każdy taki model, dla pełnej zrozumiałości,  MUSI mieć załączone (diagramy, wzory wydruków, inne) struktury tych dokumentów. Dodatkiem będzie właśnie model informacyjny czyli logiczna struktura powiązań logicznych między dokumentami (korzystają z niej osoby pracujące z tymi dokumentami).

Prosta wersja takiego modelu informacyjnego może zostać wykonaną także w notacji BPMN:

Tu jednak możliwe jest pokazanie jedynie związków jakimi są tak zwane referencje, czyli wzajemne jawne odwołania (np. formularz oferty zawiera pole z numerem zapytania). Pełny model informacyjny można wykonać z użyciem notacji UML:

Powyższy diagram to klasy reprezentujące nazwane struktury dokumentów (ich typy) oraz związki logiczne między nimi (asocjacje w UML to nie są trwałe relacje znane z baz danych a jedynie związki semantyczne).   Związki te można zobrazować jeżeli są to trwałe (wbudowane w treść) binarne powiązania (związek pomiędzy dwoma klasami). Jednak związki dynamiczne, definiowane przez reguły biznesowe, nie dają się zobrazować dlatego poprzestajemy na wyspecyfikowaniu takiej reguły.

Powyższy diagram mówi nam, że:

• powiązanie pomiędzy oryginałem zapytania (np. jego skan na dysku) a wewnętrznym dokumentem Zapytanie od klienta, jest zawarte w dokumencie (formularz) Metadane zapytań (jest to klasa asocjacyjna UML), który (hipotetyczny szablon byłby w załączeniu) zawiera informacje o położeniu pliku na dysku i przydzielonym mu np. wewnętrznym numerze Zapytania,
• powiązanie pomiędzy Ofertą handlową a Zapytaniem jest wbudowane w Oferty w postaci numeru zapytania, jako jednego z atrybutów dokumentu Oferta (Oferta w swojej treści powołuje się na numer Zapytania, zobrazowano to asocjacją kwalifikowaną UML),
• związek pomiędzy dokumentem a osobą, która ma dostęp do jego treści opisuje reguła biznesowa mówiąca, że “Sprzedawca ma dostęp do dokumentów klientów, których jest opiekunem”, reguła ta została zaimplementowana w postaci dokumentu Opiekun (klasa asocjacyjna UML) , zakładamy że jest to formularz zawierający nazwę klienta i nazwę jego opiekuna (np. udokumentowana decyzja dyr. działu sprzedaży), te dokumenty mogą być w dowolnej chwili zmieniane, dodawane i usuwane.

Jak widać diagram nie zawiera asocjacji pomiędzy Sprzedawcą a dokumentami (dostęp Sprzedawcy do treści danego dokumentu), gdyż ich sensowne zobrazowanie na diagramie jest praktycznie niemożliwe.

Taki diagram zawiera precyzyjne informacje o tym jakie i jak powiązane z sobą informacje przetwarza organizacja. Nie jest to absolutnie coś co należy odwzorować jako model kodu, nie ma tu żadnych liczności klas, bo te także są (potencjalnie zmiennymi) regułami biznesowymi (np. reguła: jeden sprzedawca nie może się opiekować więcej niż dziesięcioma klientami). Nie jest to żaden model danych, struktury formularzy dokumentujemy osobno. Nie jest też powiedziane, że implementacja formularzy to tablice z kolumnami odpowiadającymi polom formularzy (to zresztą bardzo kiepski pomysł).

Pełna dokumentacja powinna zawierać w załączeniu detaliczne struktury tych formularzy (diagramy przedstawiające struktury XML, lub skomentowane mock-up’y dokumentów). Taka specyfikacja zawiera wszystkie informacje pozwalające developerowi stworzyć oprogramowanie służące do zbierania i zarządzania informacją. Jako model wymagań na systemy typu EOD³ jest wystarczająca.

Gdyby było prawdą, że wymagamy od oprogramowania także, by zawartość wybranych pól tych formularzy była wyliczana lub weryfikowana, musimy dodatkowo udokumentować  zależności między tymi polami. Model taki często warto uzupełnić wymaganą architekturą oprogramowania, bo od niej zależą cechy jakościowe aplikacji, tak zwane pozafunkcjonalne. Będzie to właśnie  model dziedziny systemu, opisywany na moim blogu wielokrotnie.

Poniżej cel i proces budowy modeli pojęciowych [zotpressInText item=”{5085975:BIBQ5WAW},{5085975:GUF2RNXW}”]:

Zapraszam także do lektury kontynuacji tego zagadnienia w artykule Bazy Dokumentowe.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Konieczność posiadania wiedzy i umiejętności programistycznych na etapie projektowania i wdrażania procesów została całkowicie wyeliminowana poprzez wprowadzenie narzędzi do graficznego projektowania procesów. […] Patrząc od strony korzyści dla przedsiębiorstw rozważających podjęcie decyzji o praktycznych wykorzystaniu systemu BPM 2.0, można wskazać pojawiające się dodatkowo możliwości łatwego projektowania, wdrażania i optymalizowania procesów.

Tego rodzaju opinie pojawiają się regularnie jak tylko na rynku pojawi się jakieś rozwiązanie z gatunku [[Rapid Development]]. Problem z takimi obietnicami polega na tym, że ukrywają pewien istotny fakt: każdy system to “narzędzie przetwarzania danych” i:

1. pierwsza trudność to zrozumieć i udokumentować co, kto i po co ma zrobić z jakimiś danymi,
2. druga, nie mniejsza, to  opisać te dane i przygotować dla nich miejsce.

w czym problem? Poniżej diagram prostego procesu (notacja BPMN):

Żółte prostokąty (zaokrąglone rogi) to czynności (procesy), “karteczki z zagiętymi rogami” to nasze dane (jakieś dokumenty itp.). Nasze dane są składowane  na różne sposoby. Jeżeli interesuje nas wyłącznie to ile stron dokumentów mamy, być może wystarczy traktowanie każdej karteczki na diagramie jak dokumentu. Jeżeli jednak chcemy wiedzieć kto, kiedy i co napisał, to pojawia się potrzeba “rozebranie” treści każdego dokumentu na te własnie “drobne” elementy. Ta rozbiórka nie jest prosta, nazywa się to [[modelowanie danych]] lub [[analiza i modelowanie dziedziny systemu]] a ogólnie jest to  model informacyjny. Ten niestety nie jest łatwy do wykonania. Po jego wykonaniu zaś należy zaprojektować i stworzyć system, który tymi danymi będzie zarządzał.

Tak więc powyższy diagram faktycznie jest w stanie opracować tak zwany “biznes” i zapewne wielu menedżerów się tego nauczyło. Problem w tym, że nic nie zadziała do czasu gdy nie stworzymy systemu zarządzania danymi, który obsłuży owe karteczki na diagramach procesów.

Po za tym dostarczenie mechanizmów pracy grupowej użytkowników systemu, utrzymanie zgodności ze standardami nie prowadzącej do uzależnienia od jednego dostawcy oprogramowania, możliwości wykorzystania różnych metod do relatywnie łatwej integracji z innymi wykorzystywanymi systemami – np. ERP czy CRM – i wreszcie ograniczenia kosztów w drodze wykorzystania jednej z istniejących, w pełni funkcjonalnych, implementacji rozwijanych w ramach projektów open-source. (za BPM 2.0 czyli nowa generacja zarządzania procesami w przedsiębiorstwach).

Powyższego niestety nie zrozumiałem (co to znaczy “możliwości wykorzystania różnych metod do relatywnie łatwej integracji z innymi wykorzystywanymi systemami”), nie licząc tego, że faktycznie dobrze wdrożony system wspomagający zarządzanie przepływem pracy i dokumentów, jest swego rodzaju systemem  pracy grupowej. Integracja, jej łatwość i koszt zaś nie zależy od systemu BPM a tych integrowanych systemów ERP czy CRM (pamiętajmy, że integracja w jednakowym stopniu dotyczy obu integrowanych systemów).

Tak więc nie sądzę by możliwe było projektowanie i wdrożenie systemu bez “służb informatycznych”. Jednak dobrze zaprojektowany i już wdrożony system BPM może pozwalać na komponowanie kolejnych nowych lub zmianę starych procesów, jednak tu możliwe jest jedynie  używanie jak klocków, wstępnie zaprojektowanych i zaimplementowanych “procesów i obiektów danych”.

Gdybym miał ocenić statystycznie diagram klas opisywany w książkach o UML [zotpressInText item=”{5085975:99XMB4H4},{5085975:3QMDVWZE}”], 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 [zotpressInText item=”{5085975:NVN9AR49}”] ^?*?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) [zotpressInText item=”{5085975:ZWDEIJJ9}”]. 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ę.

Przykład:

Cechą produktu jest kolor a barwa to wartość. Atrybut i cecha w języku potocznym to synonimy, ale:

• cechą samochodu jest jego kolor
• cechą samochodu jest także to, że ma koła

Dlatego analizując daną dziedzinę trzeba wiedzieć czym są tak zwane cechy definiujące produktu:

• kolor nie czyni przedmiotu samochodem
• ale posiadanie kół owszem

Jednak w przypadku flagi lub logo firmy, kolor jest cechą definiującą i to jest jeden z wielu powodów, dla których nie należy dawać koderom etapu analizy i projektowania, bo myślą tylko kodem (klasa i atrybut).

Dlatego używanie pojęcia klasy wymaga “zastanowienia” bo to ma więcej niż jeden kontakt:

• inny w kodzie
• inny w ontologii

a tu i tu używamy pojęcia klasy i klasyfikatora.

Model dziedziny to model mechanizmu działania

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) [zotpressInText item=”{5085975:TBT7B5D2}”] 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.

C++, Java i podobne języki

Paradygmat obiektowy to hermetyzacja i komunikacja, a nie “dziedziczenie i łączenie danych i funkcji w obiekty”. C++/C# czy Java nie są reprezentacją obiektowego paradygmatu i niosą ze sobą narastający dług technologiczny:

Popatrzmy także na to:

W tym filmie przedstawiamy niektóre z technik stosowanych przez autorów kompilatorów w celu osiągnięcia mechanizmów języków obiektowych. Ciekawie jest zobaczyć, jak blisko C++ jest do C i jak proste są te mechanizmy pod maską. Chociaż film koncentruje się na C++, podobne techniki są stosowane przez wirtualną maszynę Javy, wirtualną maszynę .Net w C# i wiele innych języków OO.

https://youtu.be/HClSfuT2bFA?si=b5W7dLOkjRTPLGbf

Od pewnego czasu [2024] słyszę od deweloperów: Teraz w Javie króluje Spring. Słyszał pan o nim? Jestem ciekaw opinii

Tak, słyszałem:

“The Spring Framework is an application framework and inversion of control container for the Java platform.[2] The framework’s core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE (Enterprise Edition) platform. The framework does not impose any specific programming model.[citation needed]. The framework has become popular in the Java community as an addition to the Enterprise JavaBeans (EJB) model.[3] The Spring Framework is free and open source software.[4]: 121–122 [5]”

[https://en.wikipedia.org/wiki/Spring_Framework]

Czym jest Enterprise JavaBeans (EJB) model?

“Java Beans, As part of the standardization, all beans must be serializable, have a zero-argument constructor, and allow access to properties using getter and setter methods.”

[https://en.wikipedia.org/wiki/JavaBeans]

To oceniane jako najgorsze metody w postaci “access to properties using getter and setter methods”.

“Every getter and setter in your code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters (also referred to as accessors, accessor methods, and properties) is a sign of a poorly-designed set of classes.”

[https://typicalprogrammer.com/doing-it-wrong-getters-and-setters]

(patrz także: https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html)

“Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób.”

https://pl.wikipedia.org/wiki/Antywzorzec_projektowy

znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu (patrz https://martinfowler.com/bliki/AnemicDomainModel.html, programistom polecam także te strony). Warto też pamiętać, że w 2015 roku zmieniła się specyfikacja UML, usunięto pojęcie dziedziczenia i agregacji, sugeruję uzupełnić wiedzę wpisami na blogu, które powstały po 2015 roku.

Źródła

[zotpressInTextBib style=”harvard1″ sort=”ASC”]

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: