O notacji tej mówi się od kilku już lat. Początkowo spotkać można było opinie, że będzie częścią BPMN, a także że będzie jej konkurencją itp..  Pojawiały się nawet tezy (wróżby lub groźby 😉 ), że będzie to dobre narzędzie do “rozrysowywania” złożonych przepływów w procesach (nadzieja dla zwolenników algorytmizacji firm…). Jednak nie. Walka z “kilerem” projektów, jakim jest “utrata panowania nad złożonością diagramów”, z tworzeniem monstrualnych diagramów ocierających się o próby algorytmizowania organizacji trwa.

Niedawno napisałem:

Modele analityczne, jak sama nazwa wskazuje, to modele których celem jest stworzenie abstrakcji, modelu pozwalającego na prowadzenie analiz a nie uruchamianie czy nawet symulacja modelowanych konstrukcji. Każda analiza to praca z uproszczeniami. Te uproszczenia mają na celu pozbycie się zbędnych szczegółów, tych nieistotnych dla danego badanego zagadnienia. (Źródło: Analityczne i wykonywalne modele).

Dlatego model analityczny procesu, poziom jego szczegółowości raczej wygląda tak:

Przypomnę, że podstawowym “blokiem konstrukcyjnym” w takich analitycznych modelach jest proces biznesowy czyli “chronologiczny łańcuch zadań, przetwarzająca określony stan wejścia procesu w stan jego wyjścia”, te stany to określone zestawy informacji (danych, w BPMN DataObject na diagramie zobrazowane jako karteczka z zagiętym rogiem). Elementarnym (atomowym) procesem biznesowym jest jedna aktywność i jej wejście i wyjście. Na diagramie powyżej mamy proces biznesowy obsłużenia pisma (na wejściu Pismo a na wyjściu Odpowiedź) składający się z czterech “atomowych” procesów biznesowych (pojedynczych aktywności mających wejście i wyjście). Każda z aktywności na diagramie może mieć potencjalnie nawet bardzo złożoną i wielowariantową procedurę realizacji. Zobrazowanie jej w postaci “algorytmicznego” diagramu (np. także z użyciem BPMN, albo co gorsza, wrysowanie tej złożoności bezpośrednio w diagram powyżej!!!) doprowadzi do próby stworzenia mega-diagramu, kosztownego zarówno na etapie jego tworzenia jak i aktualizacji!

Ratunkiem przed utratą panowania nad złożonością takich detalicznych schematów blokowych nadal jest stosowanie pisemnej formy reguł biznesowych i powoływanie się na udokumentowane w projekcie umiejętności i kompetencje wykonawcy (ról). Jednak taka forma (pozostawienie procedur poza modelem) nie poddaje się łatwo analizie tak, jak można to zrobić z modelami wyrażonymi w określonej notacji (analizy wpływu, weryfikacje kompletności i spójność itp.). Zgrabnym wyjściem z tej sytuacji w BPMN, jest stosowanie diagramów z aktywnościami ad-hoc.

I tu z pomocą przychodzi CMMN. Notacja ta pozwala na tworzenie modeli opisujących to, jakie powinności i możliwości ma wykonawca (performer w BPMN), jakie zależności powodują to, że w danej konkretnej sytuacji wydarzy się taki nie inny scenariusz. Jednak nie polega to na tworzenia tych paskudnych zawiłych algorytmicznych monstrualnych diagramów. Polega to na opisaniu tego jakie aktywności muszą być wykonane (aktywności planowane do realizacji) , jakie mogą być wykonane (aktywności przewidziane ale nieobligatoryjne) oraz tego, jakie reguły (warunki) tym wszystkim sterują (Tablica planowania). Nie powstaje więc model “algorytmu” a model “tego co musi i czym dysponuje” wykonawca. To “jak” ma to robić opisują detaliczne dokumenty, reprezentowane na modelu jako Case files i Tablice planowania (może ich być wiele i mogą być skojarzone z konkretnymi elementami).

Notacja CMMN to tak na prawdę rozwinięta i uporządkowana metoda modelowania przypadków (wnętrze aktywności), których realizacja to złożony zestaw aktywności ad-hoc mogący wygenerować bardzie wiele konkretnych indywidualnych scenariuszy. W BPMN był by to albo zestaw niepowiązanych logiką aktywności ad-hoc albo monstrualny bardzo trudny w percepcji diagram, z niezliczoną liczbą rombów decyzyjnych (nie wiedzieć czemu tę wersję upodobała sobie znaczna większość analityków).

Na powyższym modelu w notacji BPMN jest zobrazowana, między innymi, aktywność Opracowanie odpowiedzi. Próba stworzenia modelu opisującego wszelkie możliwe, planowane i dopuszczalne zachowania wykonawcy, skończy się mega-diagramem. Użycie notacji CMMN (i logiki tworzenia w niej modeli) zaowocuje mniej więcej takim  o to diagramem:

Nie planuję tu opisywania z detalami notacji CMMN, polecam dostępną specyfikację, a w lżejszej formie ).  Mam nadzieję, że komentarze co nieco wyjaśniają. Celem moim było teraz jedynie pokazanie tego, że taka notacja jest, jak można jej użyć w analizach i jaką korzyść daje przejście z mozolnego pisania procedur w edytorach tekstów na modele, które stają się częścią całego modelu (w jakimś narzędziu CASE), poddającemu się analizie oraz kontroli spójności.  Notacja jest kompatybilna pojęciowo z BPMN, powstała jako narzędzie do modelowania tego co objawia się złożonością na najniższym poziomie. Po prawej stronie, często tu przytaczany, model poziomów abstrakcji w modelowaniu organizacji. CMMN plasuje się narzędzie modelowania pracy ludzi na najniższym trzecim poziomie. Nie zastępuje żadnej z obecnych notacji.

Case Management Model and Notation. Formal Version of CMMN. (OMG CMMN). Polecam do modelowania z użyciem CMMN CASE ArchiMetric 🙂 

 

 

Polecam też ciekawą prezentację firmy CAMUNDA:

http://www.slideshare.net/camunda/2015-0109-cmmn-en

Wprowadzenie

Od czasu do czasu jestem pytany czy UML, BPMN, itp.. to notacje czy języki, a padają nawet pytania czy to metody. Otóż metody na pewno nie… (np. mamy dwie metody modelowania procesów biznesowych: z użyciem notacji BPMN i notacji eEPC). A pozostałe dwa?

Nie jest to proste. Dzisiaj pójdę może nieco na skróty dlatego wnikliwym polecam lekturę przede wszystkim na temat semiotyki, logiki i rachunku zdań. Problem w tym, że na co dzień, w biznesie też, nie używamy logiki boolowskiej tylko logiki predykatów pierwszego rzędu zwanej rachunkiem zdań, w systemach informatycznych dla biznesowy też [zotpressInText item=”{5085975:PIXDJHUG},{5085975:GX5YUV53}”].

Język i znaczenie

Na początek kilka definicji ogólnych (wszystkie sł. j. polskiego PWN):

język
5. ?utrwalony społecznie zespół znaków dotyczących jakichś działań człowieka lub wyrażających jego emocje oraz każdy układ elementów rzeczywistości, któremu człowiek nadał jakąś treść?

Język jest więc określonym zespołem norm,  są nimi jednak nie tylko znaki ale także to, co znaczą i jaką treść niosą. Wyrażanie emocji czy myśli w ogóle, rzadko jest możliwe z użyciem tylko jednego znaku. Dlatego w toku ich wyrażania operujemy raczej zdaniami:

zdanie
1. ?myśl wyrażona słowami?
4. log. ?sensowne wyrażenie oznajmiające podlegające falsyfikacji?

Tu zaczynamy powoli iść w porządkowanie tego o czym piszę. Każde zdanie (w logice) może być prawdziwe lub nie (tautologia jest zdaniem zawsze prawdziwym, czyli jest znany fakt je falsyfikujący ale wiemy, że nigdy taki nie wystąpi). Jeżeli więc, że treść najczęściej wyrażamy słowami (a raczej rzadko nie jednym słowem) to znaczy, że należy umieć odczytać znaczenie złożenia wielu słów w jednym zdaniu. Jak wiemy o zrozumiałości (zrozumiałość oznacza, że zdanie ma dla czytającego określone znaczenie) decyduje układ słów w zdaniu, znaki interpunkcyjne itp.

Nawet przecinek ma znaczenie (jest on elementem języka) w zdaniu złożonym.

Jednoznaczność (zrozumiałość, znaczenie) zdań jest także efektem kontekstu:

kontekst
1. ?fragment tekstu potrzebny do dokładnego rozumienia danych wyrazów lub wyrażeń?
3. ?zespół jednostek językowych, które stanowią otoczenie danej jednostki?
4. ?zespół odniesień niezbędnych do zrozumienia utworu literackiego, dzieła naukowego itp.?

Jeżeli napiszę “Te dwie krowy są paskudne” to nadal nie ma pewności o czym mowa. Bez wiedzy o tym, czy to rozmowa dwóch rolników o inwentarzu, czy też dwóch koleżanek o dwóch innych, nie wiemy. Słowo “palant” także ma więcej niż jedno znaczenie i bez kontekstu jego użycia nie wiemy o jakie znaczenie chodzi (kolega czy mało już popularna gra) :).  Bardzo często to właśnie kontekst nadaje znaczenie.

Jak widać zrozumienie przekazu nie musi być proste, a komunikacja prosta i łatwa (każdy kto się choć raz pokłócił z powodu nieporozumień o tym wie). Kontekstem zajmuje się:

pragmatyka
1. ?dział językoznawstwa, którego przedmiotem są społeczne i sytuacyjne warunki funkcjonowania języka oraz cele, jakie mówiący chce osiągnąć przez użycie określonych wyrazów i wyrażeń?

Należy pamiętać, że znaczenie mają nie tylko pojedyncze słowa (znaki) ale także ich złożenia (“proces biznesowy” to jedno pojęcie ale dwa słowa). Innymi słowy konkretne pojęcie może być zapisane z użyciem jednego lub więcej znaków.

słowo
1. ?znak językowy mający jakieś znaczenie?

Dlatego złożenie kilku znaków (słów) także jest znakiem (definicja słowa i słowo/pojęcie przez nią definiowane, niosą tożsame znaczenie). Słowo (rozumiane jako zapis: złożenie liter) można zastąpić symbolem graficznym (ikona). O tym traktuje

semiotyka
1. ?ogólna teoria znaku w procesie porozumiewania się ludzi?

w tym:

semantyka
1. ?dział językoznawstwa, którego przedmiotem jest analiza znaczeń wyrazów?
2. ?dział semiotyki zajmujący się badaniem związków, jakie zachodzą między wyrażeniami języka a przedmiotami, do których się one odnoszą?

syntaktyka
2. ?dział semiotyki badający wzajemne stosunki i właściwości budowy wyrażeń języka w procesie porozumiewania się ludzi?

Zapisując coś: treść, w celu przekazania jej drugiej osobie komunikujemy się:

komunikacja
2. ?przepływ informacji między urządzeniami, np. telefonami lub komputerami?
3. ?przekazywanie i odbieranie informacji w bezpośrednim kontakcie z drugą osobą?

treść
1. ?to, co jest zawarte w czyjejś wypowiedzi; też: to, co przekazuje odbiorcy dzieło sztuki, w przeciwstawieniu do formy?
2. ?to, co stanowi istotę, sens czegoś?

Do komunikacji używamy znaków:

znak
1. ?kształt, któremu przypisuje się określone znaczenie?
2. ?dźwięk, spojrzenie, gest itp. służący do przekazania informacji?

Znak znaczy, czyli ma określone znacznie (pamiętamy o kontekście). Znakiem może być wiele rzeczy (także gest). Znak ma (niesie) znaczenie, znak lub ich złożenie także, przekazuje określoną treść:

znaczenie
1. ?myśl zawarta w czyjejś wypowiedzi, w czyimś zachowaniu itp.?
3. ?treść, której znakiem jest wyraz lub wyrażenie?

znaczyć
1. ?być znakiem czegoś?
3. ?umieszczać na czymś lub na kimś znak?
4. ?zostawiać na czymś znak, ślad?

Na koniec zostawiłem, sporne słowo:

notacja ?oznaczenie czegoś umownymi znakami; też: zbiór takich znaków?

Notacja to zbiór znaków. Przypomnę też, że język to miedzy innymi określony zbiór znaków wraz z opisem ich znaczeń (semantyka) oraz tym, jakie mają znaczenia ich określone złożenia (syntaktyka). Wiemy już, że znaczenie (treść) mają nie tylko pojedyncze słowa (to rzadko) ale ich konkretne złożenia (zdania). Przekazanie konkretnych, jednoznacznych treści, poza rzadkimi wyjątkami, wymaga więc zbudowania  konkretnych zdań czyli “złożeń słów (znaków)”. Innymi słowy, nikt chyba nie powie, że “książka jaką jest słownik języka polskiego, wraz z zasadami gramatyki, to jest język polski”. Język to jednak “coś więcej”. Słowo język jest dość nieprecyzyjne i oznacza wręcz pewien zespół norm i sposobów porozumiewania się (w tym idiomy, zespoły słów mająca inne znaczenie niż każde z nich z osobna). Poprawne (skuteczne) posługiwanie się danym językiem oznacza, że adresat “zrozumiał” treść nadawcy (mówiącego) [zotpressInText item=”{5085975:WBY4QT8K},{5085975:2B7VQZA7},{5085975:42JVE67U}”].

Porządkujemy to wszystko

Zrobiło się ciężko :).  Poniżej model pojęciowy: diagram w notacji SBVR pokazujący pojęcia i związki między nimi. Jednym z kluczowych narzędzi w analizie jest własnie analiza pojęciowa i budowanie słownika pojęć dla określonej dziedziny (tu więcej o tym czy jest diagram faktów opisany w notacji SBVR).

Powyższy model obrazuje związki pomiędzy opisanymi wyżej pojęciami, precyzuje także ich znaczenia. Model pojęciowy dla danej dziedziny (tu mowa o językach i notacjach) powinien się cechować między innymi tym, że znaczenia poszczególnych pojęć powinny być rozłączne, czyli spełniać arystotelesowską “zasadę wyłączonego środka” w logice, brzmiącą: “jeżeli coś jest czymś, to nie jest niczym innym”. Dla zachowania jednoznaczności zdań, definicje pojęć muszą się więc wzajemnie wykluczać, tak zbudowany słownik nazywamy “przestrzenią nazw” (ang. namespace).

UML i BPMN to język czy notacja?

Skrót UML zawiera w sobie słowo “language” (ang. język). Historycznie tłumaczyć to można tym, że obecne 14 typów diagramów to konkretne konteksty oraz narzucone konstrukcje, które można nazwać “zdaniami” (widać to szczególnie w przypadku diagramów Przypadków użycia czy Rozlokowania). Jednak obecna specyfikacja UML 2.5 porządkuje i to, słowo “language” w zasadzie nie jest w niej stosowane wobec tego co nazwano tam mianem UML (W zasadzie dzisiaj mogła by nosić nazwę Object-oriented Modeling and Notation 🙂 ).

Tak więc język czy notacja? To zależy od tego czy dana “specyfikacja” opisuje wyłącznie symbole czy też ich określone, i zalecane w określonych sytuacjach, konstrukcje oraz ich znaczenie. OMG (chyba) stara się to ostatnio jasno sygnalizować: UML to jeszcze “language” ale BPMN to już “notation”.  Specyfikacja UML zawiera określone, semantyczne (nazwane) konstrukcje, mające określone znaczenia, związane z konkretnymi diagramami (nazwa diagramu nadaje kontekst użytym na nich symbolom, jest to potrzebne bo pamiętajmy, że w UML wszystko jest “klasą”). W BPMN nie ma czegoś takiego (nawet pojęcie “proces biznesowy” nie jest częścią BPMN, jest ono zdefiniowane dopiero w Dodatku A jako objaśnienie i dodatkowy kontekst, w notacji zaś BPMN nie ma symbolu “proces biznesowy” 🙂 ). To czy dana specyfikacja to tyko opis notacji czy także języka, zależy więc od konkretnego przypadku.

Niewątpliwie UML, BPMN, CMMN, SBVR, BMM itp., to wszystko są notacje (choć niestety mają pewne wady, wytykane w przez niektórych autorów, głownie nadmiarowość), bo są to specyfikacje symboli, ich znaczeń oraz określona syntaktyka. Natomiast o tym co i jak wyrażają (i czy w ogóle ;)) tworzone z ich pomocą diagramy, to już inna kwestia… To leży w gestii twórcy diagramów. A testem jest miedzy innymi skuteczność komunikacji: porównanie tego jaką konkretną treść chciał przekazać twórca danego diagramu i jaką treść odebrał czytający… Analityk zaczyna od analizy pojęciowej by uniknąć niejednoznaczności w samym przekazie. Potem dopiero dokumentuje, z użyciem modeli tworzonych z pomocą notacji, to co zastał oraz projektuje to, co chciałby by, by powstało sposób rozwiązanie problemu (tu polecam lekturę artykułu gdzie pisałem o tym, że wymagania to projekt).

Niewątpliwie więc wszystkie “języki programowania” są językami: mają składnię i każde zdanie coś wyraża (rozumie to i kolega programista i kompilator). Wiele notacji jednak językiem nie jest. O języku można mówić tylko wtedy, gdy jest samowystarczalny do wyrażania określonych myśli i treści, do komunikowania ich. Nie możemy tego raczej powiedzieć o wielu notacjach. Diagramy i modele wykonane z pomocą ww. notacji wymagają stosowania np. “języka” polskiego, do nadawania nazw symbolom i diagramom, bez czego diagramy te były by niezrozumiałe.

Uważam więc, że używanie wobec notacji obligatoryjnie nazwy język, jest poważnym nadużyciem… Niektóre notacje mają swoją wersję wykonywalną (tu nawiązuje do tego że języki programowania są” językami”) o czym niedawno pisałem (Analityczne i wykonywalne modele) jednak pamiętać, należy notacja jako taka nie jest językiem “programowania”, jest tu raczej formą budowania mechanizmu (modelowanie), który dopiero po dodaniu wielu parametrów (czyli wprowadzeniu wielu “słów” z poza notacji) pozwala taki model “uruchomić”.

Czy specyfikacja notacji to “tekst normatywny”

Od czasu do czasu spotykam sie z tezą, że specyfikację notacji należy traktować jak “tekst normatywny”. Czym jest tekst normatywny?

Akt normatywny to tekst, który zawiera normy prawne – sformułowane w języku prawnym i zapisane w postaci przepisów. Zazwyczaj normy prawne mają charakter generalny (tzn. adresaci tych norm nie są indywidualnie określeni – normy mogą być kierowane do np. osób podlegających jurysdykcji państwa lub do grupy osób wyróżnionej ze względu na wspólne cechy – podatnicy, przedsiębiorcy itp.) i abstrakcyjny (co oznacza, że normy zawierają ogólne sposoby postępowania).

(https://www.infor.pl/prawo/encyklopedia-prawa/a/271975,akt-normatywny.html)

Specyfikacja notacji ty wyłącznie semantyka i syntaktyka notacji czyli “sposób zapisywania czegoś umownymi znakami lub symbolami” (SJP), i to bardzo często nadmiarowa (zawiera znaki i symbole, które można stosować zamiennie). Specyfikacje notacji nie zawierają opisu żadnych metod ani sposobów postępowania, dlatego co do zasady nie są to “teksty normatywne”.

Zamiast podsumowania

Źródła

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

Obserwuję wiele nieporozumień z tworzeniem modeli i samym modelowaniem. Generalnie modele mogą być modelami abstrakcyjnymi lub wykonywalnymi. Te pierwsze są także nazywane analitycznymi. Większość notacji ma dodatki (rozszerzenia) zatytułowane Execution Semantics (lub podobnie). Generalnie są to opisy warunków jakie musi spełnić model by był wykonywalny (pozwala na realizacje – uruchomienie – tego co modeluje). Zapewnienie wykonywalności wymaga podania dodatkowych elementów do modelu. Zbliża go to do modeli PSM (MDA, Platform Specific Model). Np. dla notacji BPMN jest to rozszerzenie [[BPEL]].

W poprzednim artykule napisałem, że…

Modele wykonywalne, w tym te tworzone automatycznie na bazie modeli abstrakcyjnych, to narzędzia do tworzenia wykonywalnego kodu. Nie tylko w moim mniemaniu, jest to albo daleka przyszłość (mam na myśli komercyjne zastosowania) albo wyłącznie akademickie badania. Wiem, że są udane próby generowania działającego kodu z modeli, jednak wymagania na ilość detali, jakie trzeba zadeklarować w tych modelach, zbliża ich złożoność do złożoności kodu  jaki powstaje. Nie będziemy się tu zajmowali modelami wykonywalnymi. (Źródło: MDA ? Cztery produkty czyli dwa etapy: wymagania i produkt | | Jarosław Żeliński IT-Consulting)

Modele analityczne, jak sama nazwa wskazuje, to modele których celem jest stworzenie abstrakcji, modelu pozwalającego na prowadzenie analiz a nie uruchamianie czy nawet symulacja modelowanych konstrukcji. Każda analiza to praca z uproszczeniami. Te uproszczenia mają na celu pozbycie się zbędnych szczegółów, tych nieistotnych dla danego badanego zagadnienia. W nauce krąży powiedzenie “[[all models are wrong but some are useful]]” (każdy model jest zły ale niektóre są przydatne), rzecz w tym, że model z zasady jest uproszczeniem czyli w jakimś sensie jest to “zepsuta rzeczywistość”.  Jednak modele służą do analiz tylko w określonych kontekstach, np. do badania współczynnika oporu powietrza model samochodu nie musi mieć silnika, nawet nie musi nadawać się do jeżdżenia, zaś rysunek techniczny stropu wystarczy do analizy jego wytrzymałości.

Popatrzmy na modele procesów biznesowych. Abstrakcją procesu biznesowego jest aktywność mająca wejście i wyjście, to trzy elementy. Reszta szczegółów jest “zbędna”, jeżeli celem analizy jest zrozumienie mechanizmu funkcjonowania organizacji. Detale realizacji procesu pomijamy, pozostawiamy w sferze umiejętności wykonawcy i ewentualnych spisanych procedur. Liczy się fakt wykonywania nazwanej pracy (aktywność) i jej cel oraz to co ją zainicjowało. Na diagramie BPMN wejście i wyjście procesu biznesowego reprezentuje abstrakcja jaką jest symbol kartki z zagiętym rogiem, abstrakcją pracy: aktywności w procesie, jest prostokąt z zaokrąglonymi rogami. Analogicznie upraszczamy rzeczywistość z użyciem innych notacji. Każda notacja ma swoje przeznaczenie, każda notacja to określony, dedykowany system pojęciowy.

Poniżej diagram pokazujący, które notacje mają rozszerzenia do budowania wykonywalności oraz do czego i kiedy są stosowane (i przeznaczone).

Na diagramie po prawej stronie umieściłem dość popularny obraz trzech poziomów modelowania organizacji, ten pochodzi ze strony ). Wszystkie trzy poziomy to abstrakcyjne modele budowane z użyciem notacji wskazanych strzałkami.

Notacje zobrazowane na diagramie pozwalają na budowę modeli analitycznych, koniecznych i wystarczających zarazem, do analiz o jakich tu piszemy. Modele pojęciowe i reguły biznesowe (SBVR) to szkielet każdego modelu analitycznego, ta notacja nie ma rozszerzeń do budowy modeli wykonywalnych. Podobnie notacja BMM, która stanowi model pojęciowy do opisu strategii firm. BPMN na poziomie analizy biznesowej, to model przepływu pracy a nie detaliczny opis każdej czynności. Celem modelowania procesów biznesowych w analizie organizacji, jest zidentyfikowanie przepływów pracy, ich produktów  i miejsc podejmowania decyzji. CMMN (będzie o tej notacji za niedługo artykuł) to narzędzie dokumentowania wariantowych detali wybranych aktywności w procesach biznesowych. UML to uniwersalna notacja (przypominam, że to to 13 typów diagramów), na etapie analiz i projektowania stosowana jest do tworzenia strukturalnych modeli systemów i modelowania ich dynamiki.

 

Ten artykuł miał za zadanie jedynie zwrócenie uwagi na to, że wykonywanie zbyt szczegółowych modeli w analizach i projektowaniu nie jest konieczne, a najczęściej bywa wręcz szkodliwe. Stosowanie w modelach analitycznych, konstrukcji i elementów przeznaczonych do tworzenia modeli wykonywalnych, w zasadzie należy uznać za błąd w użyciu notacji. Znanym z literatury przedmiotu powodem wielu porażek projektów analitycznych jest między innymi utrata panowania nad szczegółowością projektu.  Warto o tym pamiętać…

Na koniec polecam wpis na blogu Martina Fowlera UML Mode…

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :).

Niedawno napisałem:

Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te wraz z liniami je łączącymi stanowią, jako całość, model podległości zasobów w organizacji. (Źródło: Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej perspektywy powiemy sobie teraz o etapach analizy i projektowania w inżynierii, nie tylko oprogramowania, w oparciu o MDA ([[Model Driven Architecture]], www.omg.org/mda, polecam także pojęcie [[model driven engineering]]). Dobra informacja dla czytelników: na końcu się wszystko wyjaśni, można pominąć część o MDA 🙂

MDA

Pięć lat temu, jeden z artykułów o modelowaniu i projektowaniu, kończyłem tymi słowami:

Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

1. Analiza biznesowa, której produktem są: model organizacji (model biznesowy) oraz opis tego co ma powstać (opis, wymagania na oprogramowanie). Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
2. Wytworzenie oprogramowania polegające na: opracowaniu szczegółów architektury, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne), kodowaniu oraz dostarczeniu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tekście właśnie na MDA. Czymże to jest? Na stronach OMG znajdziemy: Document — ormsc/14-06-01 (MDA Guide revision 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revised MDA Guide edited in Boston on 18 June 2014 reflects all AB edits requested at the Reston and Boston AB meetings. (Źródło: OMG Document — ormsc/14-06-01 (MDA Guide revision 2.0)) 

Skorzystam z kilku cytatów i napisze co nieco o MDA. Poniżej kluczowe tezy, nie miałem tu ambicji literalnego tłumaczenia tego dokumentu, chodziło mi o pryncypia.

This guide describes the Model Driven Architecture (MDA) approach as defined by the Object Management Group (OMG). MDA provides an approach for deriving value from models and architecture in support of the full life cycle of physical, organizational and I.T. systems (A ?System?, in this context, is any arrangement of parts and their interrelationships, working together as a whole.). The MDA approach represents and supports everything from requirements to business modeling to technology implementations. By using MDA models, we are able to better deal with the complexity of large systems and the interaction and collaboration between organizations, people, hardware, software.

Stosowanie modeli pozwala znacznie lepiej radzić sobie ze złożonością wielkich systemów jakimi są organizacje oraz funkcjonujące w nich związki między ludźmi, oprogramowaniem i infrastrukturą. Fakt, że badane organizacje współpracują z innymi, dodatkowo komplikuje tę całość.

Models as communications vehicles

A fundamental value proposition for models and modeling is to facilitate a team or community coming to a common understanding and/or consensus.

Jedną z głównych ról modeli, poza ich analizą, jest komunikacja: komunikujemy innym członkom zespołu (także klientom) to co zrozumieliśmy i to czego oczekujemy. Tak więc modele są zarówno opisem rzeczywistości powstałym w toku jej zrozumienia, są także opisem tego co ma powstać, jeżeli chcemy tę rzeczywistość stworzyć.

[?]Abstraction deals with the concepts of understanding a system in a more general way; said in more operational terms, with abstraction one eliminates certain elements from the defined scope; this may result in introducing a higher level viewpoint at the expense of removing detail. A model is considered more abstract if it encompasses a broader set of systems and less abstract if it is more specific to a single system or restricted set of systems. [?]

Podstawową rzeczą w analizie jest redukowanie szczegółów i uogólnianie. Człowiek nie jest w stanie analizować czegoś co składa się z setek detali.

Model Analytics

Once models are captured as semantic data various analytics can be executed across those models including model validation, statistics and metrics. Analytics assists in decision making, monitoring and quality assessment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele pojęciowe i analityczne służą do zrozumienia badanej rzeczywistości. Modele tworzone (projektowanie) służą do testowania pomysłów i podejmowania decyzji, dalej zaś stanowią opis cech wymaganego rozwiązania. Modele wykonywalne to inne modele ale bazują na modelach analitycznych. Poniżej, na bazie MOF ([[Meta Object Facility]]), pokazano trzy poziomy abstrakcji (poziom zerowy to rzeczywistość).

Abstrakcja to “uproszczony” (pozbawiony zbędnych szczegółów) model określonej rzeczywistości. Metamodel to mechanizm tworzenia tej rzeczywistości w tym także model pojęciowy (więcej w dalszej części).

Model (M1) więc jest albo wynikiem (produktem) analizy badanej rzeczywistości, albo wynikiem (produktem) procesu jej projektowania (projektowania rozwiązania). 

Model Simulation and Execution

Models as data can drive simulation engines that can assist in both analytics and execution of the designs captured in models. Simulation assists in the human understanding of how a modeled system will function as well as a way to validate that models are correct. Models can, in some cases be directly executed ? serving as the ?source code? for highlevel applications that implement processes, data repositories and service endpoints. Model execution provides a direct and immediate path to realizing a design with a minimum of technical details being exposed. DBMS Schema and process models are well-known categories of (partially) executable models.[?]

Modele symulacyjne służą do testowania hipotez i podejmowani decyzji. Modele wykonywalne, w tym tworzone automatycznie na bazie modeli abstrakcyjnych, to narzędzia do tworzenia wykonywalnego kodu. Nie tylko w moim mniemaniu, jest to albo daleka przyszłość (mam na myśli komercyjne zastosowania) albo wyłącznie akademickie badania. Wiem, że są udane próby generowania działającego kodu z modeli, jednak wymagania na ilość detali, jakie trzeba zadeklarować w tych modelach, zbliża ich złożoność do złożoności kodu  jaki powstaje. Nie będziemy się tu zajmowali modelami wykonywalnymi.

Cztery produkty

Te dwa opisane na początku etapy do analiza systemowa organizacji (potocznie “analiza biznesowa”) oraz implementacja rozwiązania. Produkty to …

MDA to architektura mająca trzy poziomy modelowania, nazywane  “od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is useful to identify particular ?layers? of an architecture with respect to its level of abstraction. While there can be any number of architectural layers, a broad categorization of this concept is:

• Business or domain models ? models of the actual people, places, things, and laws of a domain. The ?instances? of these models are ?real things?, not representations of those things in an information system. In MDA domain models have historically been called a ?CIM? for ?Computation Independent Model?.
• Logical system models ? models of the way the components of a system interact with each other, with people and with organizations to assist an organization or community in achieving its goals. [model PIM]
• Implementation models ? the way in which a particular system or subsystem is implemented such that it carries out its functions. Implementation models are typically tied to a particular implementation technology or platform. [model PSM].

Model CIM opisuje ludzi i ich związki, miejsca, prawa rządzące tym wszystkim. Ten model opisuje realną, badaną rzeczywistość całkowicie abstrahując od wykorzystywanych ewentualnie posiadanych narzędzi informatycznych (w przypadku start-up’u lub rozwoju organizacji jest to przyszła jej postać). Nie jest to model jakiegokolwiek oprogramowania ani tego jak ono działa. Produktem tego etapu są: modele procesów biznesowych, specyfikacja reguł biznesowych, biznesowy słownik pojęć i modele pojęciowe.

Model PIM opisuje komponenty aplikacji, ich wzajemne interakcje, logikę działania tych komponentów (ta część logiki opisanej w modelu CIM, która ma być realizowana w aplikacji). Produktem tego etapu są modele: przypadków użycia (w tym postać nośników danych, mockup’y ekranów), komponentów, wewnętrzne struktury komponentów (modele dziedziny z perspektywy wzorca MVC),  interakcji, inne jeśli konieczne.

Model PSM to model będący projektem wykonawczym. Jest to rozszerzenie modelu PIM, uszczegółowienie go wraz z dodatkowymi elementami technicznymi (realizującymi środowisko, bezpieczeństwo, wymaganą  wydajność itp.). Kod aplikacji to materializacja (implementacja) modelu PSM.

Powyższe, to cztery produkty powstające w tym procesie. Dlaczego pisze o dwóch etapach? Poniżej wyjaśnienie.

Diagram obrazuje produkty/fazy definiowane jako MDA. Każdy produkt analizy to określony zestaw modeli. Na diagramie wskazano jakich notacji używa się w każdym z nich (tu bazując na notacjach rodem z OMG). Tu przypominam to co już nie raz pisałem: celem jest zrozumienie (i tworzenia potrzebnych w danym przypadku modeli) oraz przekazane tej wiedzy, a nie tworzenie “jakichś modeli i dokumentów”. Każdy model, jego powstanie, ma określony cel.

Jeszcze stosunkowo niedawno w moich projektach związanych z  oprogramowaniem, wyróżniałem trzy etapy: analiza organizacji, specyfikacja wymagań oraz opracowanie logiki dla dedykowanych komponentów oprogramowania. W końcu, po kilku projektach, przekonałem się, że ten podział “nie działa”. Dlaczego?

Skoro na etapie CIM opracowaliśmy między innymi model logiki biznesowej dla danej organizacji (w tym reguły biznesowe, słownik pojęć) to już ją, te logikę, mamy. Okazało się, że ten “trzeci etap” w zasadzie jest sztuczny, gdyż rzetelne opracowanie CIM to także “ta” logika. Tu warto przytoczyć diagram:

Swego czasu pisałem także o testowaniu modeli:

W toku dalszej pracy podejmowana jest decyzja o zakresie projektu. Wskazując to, jakie “działania” ma wspierać lub przejąć na siebie aplikacja (to są właśnie przypadki użycia), wskazujemy jaka logika ma być przez tę aplikację realizowana i kiedy. Wskazanie zakresu projektu jest więc pierwszym etapem definiowania logiki aplikacji. Jeżeli do tego dodać wiedzę dziedzinową, np. to które elementy mogą być współdzielone a które nie, które powinni być całkowicie niezależne itp., powstanie tak zwany model dziedziny systemu (logika biznesowa i jej struktura czyli architektura aplikacji, a konkretnie części realizującej logikę biznesową).

Na zakończenie

Jak podejść do planów zakupu także gotowego oprogramowania? Czy warto je projektować? Oczywiście, że warto z prostego powodu: nie ma znaczenia to, czy przyszłe oprogramowanie będzie gotowe czy trzeba je będzie dopiero stworzyć. Ono ma realizować taką logikę jakiej oczekujemy. Owszem, jest możliwa decyzja: skoro na rynku nie ma poszukiwanego produktu a stworzenie dedykowanego jest zbyt kosztowne, to albo rezygnujemy  z zakupu albo z określonej logiki wewnątrz organizacji. Jednak do podjęcia takiej decyzji musimy tę logikę znać i mieć udokumentowaną (no bo jakoś musimy ją pokazać oferentom). “Ale dostawcy oprogramowania zawsze oferują analizę wymagań”… To prawda … A ilu z nich powie, że nie mają Wam nic do zaoferowania? “Ale dedykowane oprogramowanie może zaprojektować tylko jego wykonawca”. To dlaczego firmy budowlane nie są dopuszczane do prac projektowych i architektonicznych?

Dlatego na diagramie powyżej, jako moment wyboru dostawcy oprogramowania, wskazano ten w którym mamy udokumentowany model logiki czyli PIM. To czy logika taka jest dostępna w jakimś produkcie na rynku czy nie, nie zmienia faktu, że i tak musi zostać ona opisana, bez czego taki wybór jest niemożliwy. Czym więc są (czym powinny być) wymagania na oprogramowanie? Niestety powinny być zwięzłym projektem a nie długą listą cech.

Jeden analityk projektant mający dobre wsparcie narzędziowe, jest w stanie wykonać analizę i projekt dla dowolnie dużej firmy, wystarczy, że potrafi tworzyć abstrakcje i zarządzać złożonością dokumentacji. Czy kilku analityków zrobi to nie gorzej i szybciej? Nie znam takiego przypadku…. bo im więcej osób prowadzi taką analizę tym więcej pracy wymaga koordynacja i praca nad spójnością całości.

Na zakończenie cytat z pewnej dyskusji:

I started a company called Nascent Blue that specializes in MDD for application development. We have actually had the opportunity to compare MDD to traditional development side-by-side on large projects. Our client set up ?the experiment? to collect the PM data for analysis. It was a large project with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team produced more than twice the code of the other teams.
3. Our team achieved a 75% reduction in cost.
4. Our team achieved a 66% reduction in defect rate.
5. Our team was twice as fast (with half the size).
We have since gotten more efficient and more advanced, so I don?t know what the numbers are now.
(źr. Model driven productivity | LinkedIn).

Własnie czytam o nowelizacji KPC:

Nowe przepisy uznają za dokumenty i dopuszczają jako dowody w sądzie e-maile, esemesy, nagrania audio czy wideo, wręcz ?każdy nośnik informacji umożliwiający zapoznanie się z jej treścią“. Te nośniki będą zrównane z pismem papierowym. W elektronicznej formie (tzw. dokumentowej), będzie też można zawierać umowy, składać wiążące oświadczenia.

Z tymi oczywistymi ułatwieniami, wynikającymi z postępu techniki i zmian zwyczajów w biznesie, wiąże się niestety też ryzyko.

? W e-korespondencji strony powinny zachować szczególną ostrożność. Adresat e-maila czy nagrany rozmówca może bowiem opacznie odczytywać oświadczenia składane w formie elektronicznej i wykorzystać je potem w sądzie ? wskazuje Monika Leszko, radca prawny w kancelarii DLA Piper. ? Pierwsza rada, jaka się nasuwa, jest taka, by w takiej korespondencji wyraźnie zastrzegać, że nie jest to np. oferta czy zgoda. (źr. RP.pl)

Chciałbym się tym razem skupić na wytłuszczonej w cytacie treści. Problemem z jakim muszą się zmierzyć między ustawodawca, urzędy, ale także autorzy “dokumentów”, jest zapewnienie porządku pojęciowego dla zachowania poprawnej i jednoznacznej komunikacji. W szczególności dotyczy to podkreślonych powyżej pojęć: nośnik, informacja, treść, opacznie zrozumieć.

Cztery lata temu zwracałem uwagę na to samo (głownie treść, oryginał, kopia, nośnik) ale w kontekście praw autorskich i ustawy ich dotyczącej:

Dzieło może mieć postać materialną i niematerialną. Dzieło materialne (rzeźba, obraz malarski) ma swój oryginał, mogą powstać reprodukcje. To drugie dzieło, niematerialne, dotyczy w szczególności utworów muzycznych, zdjęć czy treści (każda wypowiedź to proza lub poezja ;)). Dzieło niematerialne może być utrwalone na wybranym nośniku (muzyka na płycie CD, proza na papierze, ?), wtedy powstają jego egzemplarze.

(cały wpis: Prawo autorskie i wartości niematerialne – analiza systemowa).

Artykuł ten zwraca uwagę na problemy jakie stwarza między innymi “rozłączność treści i nośnika oraz na stwierdzeniu czym jest oryginał, kopia i egzemplarz. Kluczowe są tu pojęcia: nośnik, dzieło (dane), oryginał i kopia.

Na czym polega problem? Zbudujmy model pojęciowy dla problemu dokumentu i jego roli:

Diagram czytamy tak: dokument to informacje utrwalone na nośniku. Informacją są dane lub wiadomości niosące określoną treść. Dla porządku przytaczam przyjęte definicje tych pojęć (na podstawie sł. j.polskiego PWN):

Skupmy się na tym, że dowodem może być “każdy nośnik informacji umożliwiający zapoznanie się z jej treścią” i na tym, że ktoś “może bowiem opacznie odczytywać oświadczenia składane w formie elektronicznej i wykorzystać je potem w sądzie”. 

Z perspektywy teorii komunikacji za treść (to co zrozumiano) odpowiada nadawca (autor) treści i dobra rada, żeby w treści “wyraźnie zastrzegać” o co chodzi, jest jak najbardziej właściwa. Jednak teoria komunikacji nie jest tu głównym wątkiem ani problemem :).

Pozostaje kwestia nośnika i danych (wiadomości) niosących ową treść. Oczywiście można użyć podpisu elektronicznego, jednak jego powszechność w Polsce jest znikoma (nieco ponad milion, z tego aktywnych ok. 1/3, podobnie jak i profilu zaufanego na ePUAP).  Pojawia się nowe pojęcie: forma dokumentowa (zamiast “forma pisemna”):

Ustawodawca postanowił, że forma dokumentowa będzie zachowana wówczas, gdy oświadczenie woli zostanie złożone w postaci dokumentu, w sposób umożliwiający ustalenie osoby składającej to oświadczenie. Warto podkreślić, że podpis w takim przypadku nie jest elementem koniecznym dla zachowania tej formy czynności prawnej. Wymagane jest natomiast istnienie dokumentu, czyli, zgodnie z wprowadzanym przez nowelizację przepisem, nośnika informacji umożliwiającego zapoznanie się z jej treścią. Drugorzędna jest natomiast fizyczna postać tego nośnika ? może to być papier, jak i np. plik komputerowy ? ważne jest, by sposób zapisania na nim informacji umożliwiał jej utrwalenie i odtworzenie. (Źródło: Nowe formy czynności prawnych w Kodeksie cywilnym – Aktualności, Zmiany w prawie, NL Zmiany w prawie – Czytaj – kancelaria.lex.pl)

Ustawodawca moim zdaniem słusznie godzi się na dopuszczenie dokumentów niepodpisanych elektronicznie (mail, SMS, dokument na pendrive itp.) do “obiegu” w urzędach i sądach. Głównym, w moich oczach, dotychczasowym problemem było praktyczne wykluczenie znacznej większości obywateli z komunikacji drogą elektroniczną, a powodem jest brak powszechnego używania wspomnianego podpisu i profilu.

Ustawodawca doprecyzowuje definicję: “dokumentem jest nośnik informacji umożliwiający zapoznanie się z jej treścią”. Zakładam, że intencją jest, by nie uznać za dokument tego co z powodów np. technicznych, nie jest możliwe do odczytania przez adresata (sąd, urząd, …). Rodzi to ryzyko uznaniowości (a ja nie mam jak tego odczytać). Tu sugeruję dokumentować (ustalać) zasady komunikacji lub żądać co najmniej oświadczenia o tym jakie “dokumenty” adresat jest w stanie odczytać by “zapoznać się z ich treścią”.

Pewną ciekawostka jest natomiast dla mnie zapis:

w art. 73 § 1 otrzymuje brzmienie:
?§ 1. Jeżeli ustawa zastrzega dla czynności prawnej formę pisemną, dokumentową albo elektroniczną, czynność dokonana bez zachowania zastrzeżonej formy jest nieważna tylko wtedy, gdy ustawa przewiduje rygor nieważności.?;

Skoro użyto trzech odrębnych pojęć “pisemną, dokumentową albo elektroniczną” to znaczy że ich znaczenia się (powinny) wzajemnie wykluczają.  Jak więc to rozumieć w świetle definicji pojęć powyżej? Firma pisemna to każda forma “utrwalona”. Dokument jest niczym innym jak właśnie formą utrwaloną (na nośniku). Forma elektroniczna to treść na nośniku, w formie elektronicznej. Ciekaw jestem interpretacji prawników… 

Jednak dalej czytamy:

Art. 781
. § 1. Do zachowania elektronicznej formy czynności prawnej wystarcza złożenie oświadczenia woli
w postaci elektronicznej i opatrzenie go bezpiecznym podpisem elektronicznym weryfikowanym przy pomocy ważnego kwalifikowanego certyfikatu.

Co nieco burzy moje zrozumienie całości…

 

Jakie ryzyka powoduje rezygnacja z podpisu dokumentu w wersji elektronicznej?  Generalnie rzecz biorąc dotyczy to uwiarygodnienia: informacji, daty jej powstania, daty doręczenia. Pamiętajmy, że w powszechnym obrocie są dokumenty papierowe. Co jest ich kluczową cechą? Nierozłączność informacji i nośnika oraz relatywnie duża trudność w sfałszowaniu (i treści i odręcznego podpisu). W kwestii doręczenia radzimy sobie wysyłając dokument za poświadczeniem odbioru.

W wersji elektronicznej oddzielono pojęcie treści od nośnika z powodów jak wyżej, z tego także powodu straciło sens pojęcie kopii i oryginału: istotne są informacje a nie forma zapisu i liczba egzemplarzy (ustawodawca zrobił tu już formalnie w przypadku faktur). W konsekwencji stwierdzenie czy informacja była zmieniana staje się bardzo trudne.

Stan obecny, mimo że jest bardzo wygodny,  rodzi jednak ryzyka związane z trudnością zagwarantowania autentyczności dokumentu. Zapis na nośnikach wielokrotnego użytku (np. pendrive, karty pamięci…) jest potencjalnie podważalny. Ja osobiście stosuje nagrania na płytach CD-R/DVD. Raczej trudno podważyć niemodyfikowalość zapisu na nich. Co do daty doręczenia/powstania to w przypadku rzeczy ważnych (czyli rodzących duże ryzyko) warto takie nośniki tworzyć u kogokolwiek, kto dysponuje ważnym podpisem elektronicznym, gdyż cudzy podpis zawiera także znacznik czasu, co uwiarygodni datę powstania treści. Nie zmienia to faktu, że podpisanie się na takiej płycie niezmywalnym pisakiem czyni ją “nie gorszą” od podpisanego papieru ;).

Formą łatwą i tanią oceny wiarygodności treści jest uznanie kontroli krzyżowej jako weryfikatora. Tak są weryfikowane od lat niepodpisywane faktury (porównanie treści u wystawcy i odbiorcy).

 

Artykuł ten ma na celu zwrócenie uwagi na problemy i ryzyka związane z nowymi przepisami a nie rozwiązywanie ich. Mam nadzieję, że większe ich zrozumienie przyczyni się do większej dbałości o swój interes i stosowanie tak prywatnie jak i w prowadzonej działalności, mechanizmów minimalizujących ryzyka korzystania z dokumentów elektronicznych. Osobiście nie korzystam z podpisu elektronicznego, do urzędów, w tym Urzędu Skarbowego, od lat wysyłam zwykłe email’e. Owszem korzystam także z papieru i Poczty Polskiej, gdyż wychodzę z założenia, że należy dostosowywać środki do celu, a nie “być za wszelką cenę” nowoczesnym.

(Tekst ustawy: Ustawa z dnia 10 lipca 2015 r. o zmianie ustawy – Kodeks cywilny, ustawy – Kodeks postępowania cywilnego oraz niektórych innych ustaw)