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…
