Pojawiają się w sieci różne komentarze i artykuły na temat notacji wykorzystywanych w projektach analitycznych. Poniżej cytaty jednego z typowych tego typu tekstów i moje uwagi…

Miejsce BPMN w odniesieniu do UML

Pojawienie się BPMN, BPML i systemów BPMS nie powoduje, że projektowanie systemów za pomocą UML staje się przestarzałe. Projektowanie systemów nadal jest istotnym elementem tworzenia architektury przedsięwzięcia. UML jest językiem projektowania, specyfikacji, wizualizacji i dokumentowania systemów oprogramowania. Jest on narzędziem dla architektów systemów i projektantów oprogramowania. Został opracowany do ułatwienia i przyspieszenia produkcji oprogramowania, od projektu architektury systemu aż po implementację i jest skierowany do użytkowników o wysokich umiejętnościach technicznych. BPMN natomiast jest przeznaczony dla analityków biznesowych, architektów systemów i projektantów oprogramowania. Został opracowany do optymalizacji zarządzania cyklem życia projektu od etapu projektowania procesów i jest przeznaczony dla użytkowników biznesowych.

Sprostowanie: BPMN to system pojęciowy i notacja służące to tworzenia modeli procesów w postaci schematów blokowych (diagramów). BPML to [[Business Process Modeling Language (BPML)]] ? konkurencyjny do [[BPEL]] XMLowy język do opisu procesów. Zaś [[BPMS]] to ogólna nazwa na systemy wspomagające proces zarządzania zorientowanego na procesy, jest to cała klasa systemów. Co do tego dla kogo są adresowane notacje: każdy system pojęciowy jest adresowany do analityków i projektantów, dziedzina w jakiej zostanie zastosowana dana notacja zależy od jej użyteczności w danej dziedzinie a wybór należy do analityka. Natomiast trudno się zgodzić z twierdzeniem “BPMN […]. Został opracowany do optymalizacji zarządzania cyklem życia projektu od etapu projektowania procesów i jest przeznaczony dla użytkowników biznesowych” bo to nie prawda (choć może być także do tego wykorzystany), BPMN powstał jako spójny system pojęć, jako narzędzie-język modelowania procesów biznesowych.

UML jest obcy większości analityków biznesowych

UML definiuje rozmaite typy diagramów, które można z grubsza podzielić na trzy grupy:

  1. Statyczna struktura aplikacji
  2. Dynamika zachowania aplikacji
  3. Zarządzanie i organizacja rozwiązań programowych

Diagramy dynamiki zachowania, głównie diagramy use-case i aktywności są często używane do modelowania procesów biznesowych. BPMN jest zbliżony do UMLa w tym, że definiuje graficzną reprezentację procesów biznesowych zbliżoną do notacji w diagramach UMLowych. Jednakowoż UML i BPMN mają zupełnie odmienne podejście do modelowania procesów biznesowych.

To, że UML jest obcy większości analityków biznesowych to przykra prawda, dzisiaj raczej źle świadcząca o tej większości ([[patrz model kompetencji analityka biznesowego IIBA]]). Używanie UML do modelowania procesów biznesowych jest ograniczaniem możliwości tych modeli gdyż UML reprezentuje [[paradygmat]] obiektowy a BPMN procesowy a to dwa odrębne światy (to, że powstały i są wykorzystywane równolegle te dwie różniące się od siebie notacje notacje także o tym świadczy).

Trudno także mówić o “podejściu” do modelowania procesów w UML bo to tak, jak by mówić że łodzie reprezentują zupełnie odmienne podejście do poruszania się po drogach publicznych”. Niestety są żeglarze, którzy nie uznają innej prawdy niż ta, że łodzią można wszędzie trzeba się tylko postarać. Faktem jest, trzeba się dobrze postarać.

UML koncentruje się na obiektach, podczas gdy BPMN na procesach. Większość narzędzi UMLowych wymaga najpierw zdefiniowania statycznych obiektów w diagramach struktur, a dopiero później pozwala określić dynamikę interakcji między tymi obiektami za pomocą diagramów zachowań. Taka ścieżka rozumowania jest obca większości analityków biznesowych.

Co do wymagań samych narzędzi UML nie podejmuję się dyskusji bo narzędzia są rożne i każdy sam sobie je dobiera. Co do samej ścieżki analizy to raczej w pierwszej kolejności modelujemy biznes (modele BPMN) a potem dopiero zastanawiamy się i projektujemy narzędzie, oprogramowanie dla tego biznesu czyli pora na UML. Odwrotną kolejność sugerują dostawcy gotowego oprogramowania ale ten wątek był na tym blogu już nie raz poruszany.

BPMN oferuje podejście skoncentrowane na procesach, które jest bardziej naturalne i intuicyjne dla analityków biznesowych. W notacji BPMN najpierw modelowane są przepływy wiadomości i sterowania procesów.

Poprawka: proces opisuje przepływ pracy oraz to jakie dane (obiekt danych w BPMN) są wymagane i jakie powstają. Komunikaty to nośniki danych.

Model obiektowy procesu w trakcie normalnego modelowania nie jest definiowany wprost.

Prawdę mówią nie mam pojęcia co to jest “model obiektowy procesu”…

Niemniej jednak BPMN dostarcza również możliwoś zdefiniowania obiektowego modelu procesu explicite, na wypadek gdyby istniało zagrożenie, że zostanie on ujawniony przez usługi biznesowe w przebiegu procesu.

To także chciał bym zobaczyć, w specyfikacji BPMN niczego takiego nie znalazłem.

(źr.cytatów:  Zarządzanie Projektami – Artykuły)

Mam nadzieję, że powyższe uczuli Państwa na weryfikowanie tego co publikują autorzy tekstów w sieci (ze mną włącznie), niestety mam wrażenie rośnie ilość tak zwane pseudowiedzy.

[2015] Od wersji 2.5 UML formalnie UML nie służy do modelowanie procesów biznesowych, nie można zastąpić notacji BPMN notacją UML.

Jarosław Żeliński

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 wykładowca akademicki wizytujący (nieetatowy), 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). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.