Na razie widzę, że klarują się dwa podejścia:
– IDEF0 lub ICOM i pochodne (w tym EPC i eEPC)
– inne idą w kierunku UML
IDEF0 to kompletny model logiczny uwzględniający zasoby i cele biznesowe (które niestety często zatraca się w procesie modelowania!). UML to droga do zaprojektowania aplikacji. Myślę, że tą drogą w środku spotkają się analitycy i programiści. W miejscu gdzie mamy model procesowy i procedury (workflow) na najniższym poziomie dekompozycji programista obiektowy ma wszystkie informacje by z pomocą UML zaprojektować i napisać kod aplikacji. Każdy prosty ?bloczek? modelu oraz interfejsy (formatki dokumentów) mogą teraz zostać zaimplementowane w systemie. Być może od strony modelowania BPMN (Business Process Modeling Notation) a od strony kodowania BPEL wniosą ułatwienie polegające na umożliwieniu pewnej automatyzacji tworzenia programów jednak w moim przekonaniu ważniejsze jest by precyzyjnie wskazać granice kompetencji pomiędzy analitykiem a inżynierem i dokładnie na tej granicy umieścić styk narzędzi analitycznych i inżynierskich.
Modelowanie to dziedzina prawie tak stara jak systemy informatyczne dla biznesu. Podstawowym celem modelowania procesów jest opisanie firmy, określenie celu projektu reorganizacyjnego i jego zakresu, określenie wymagań na tworzone oprogramowania a wcześniej optymalizacji organizacji i przygotowanie jej do wdrożenia. Stworzenie opisu funkcjonalnego tego co będziemy oprogramowywać zawsze było wyzwaniem trudnym. Drugim, być może jeszcze trudniejszym jest (do dzisiaj) nawiązanie nici porozumienia i zrozumienia pomiędzy sferą biznesu a inżynierami i programistami.
Jedna z ról jaką ma do odegrania wykonany przez analityków model jest stworzenie szkieletu aplikacji lub przynajmniej opisu tego szkieletu. Naturalnym dążeniem jest także próba uniknięcia ręcznego “przepisywania” pracy analityków biznesowych modelu i wygenerowanie na jego podstawie kodu aplikacji lub przynajmniej jej modelu np. w postaci UML.
Notacje i metodyki modelowania można podzielić na dwie grupy:
- modelowanie do prowadzenia analiz i optymalizacji procesów i zdarzeń gospodarczych (procesów biznesowych)
- modelowanie do celów tworzenia oprogramowania
Na świecie nadal najpopularniejsze są: IDEF wśród analityków i UML wśród programistów.
Modele analityczne
Tu się niewiele zmieniło. Nadal w użyciu jest IDEF0 i jego odmiany a raczej warianty czyli ICOM i mniej znany IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czyli Wejście, Sterowanie, Wyjście, Mechanizm (tu chodzi o zasoby). Skrót IGOE ma rozwiniecie: Input, Guide (odpowiednik sterowania), Output, Enabler (tu chodzi o zasoby w kontekście inicjatora realizacji danej funkcji). W obu przypadkach ogólny schemat procesu w tych konwencjach przedstawiany jest za pomocą prostokąta symbolizującego funkcję realizowaną przez proces oraz strzałki obrazujące wymienione cztery jego atrybuty :
Na tym poziomie powstało wiele produktów, które niestety zawierają swoje unikalne rozszerzenia symboli i reguł. Doprowadziło to powstania wielu narzędzi do modelowania, których produkty są ze sobą niekompatybilne już na poziomie użytych symboli. Nie wymieniając ich tu napisze, tylko, że w dość powszechnym użyciu jest ich prawie dziesięć a Gartner zidentyfikował ich na rynku trzydzieści sześć. Z tego też powodu używam w pracy symboli ICOM prostych i zrozumiałych dla biznesu zaś w przypadkach bardziej “sformalizowanych” używam IDEF0. Z uwagi na stały rozwój także tych metod ostanio zainteresowąłem się notacją BPMN.
Modelowanie do celów tworzenia oprogramowania
Ten temat jest dużo trudniejszy, gdyż dążenie do realizacji “sprzęgu” pomiędzy analitykiem a informatykiem to temat istniejący od początku czasów tworzenia oprogramowania do celów biznesowych. Krótka historia narzędzi do modelowania na potrzeby tworzenia oprogramowania (rok powstania i nazwa metody):
- 1962: sieci Petriego (Carl Petri Network)
- 1970: ANSI Flow charts
- 1979: DFD (Data Flow Diagram)
- 1982: ISO TC87 (ISO Conceptual Schema Model)
- 1992: Merise (Methode d’Etude et de Realisation Informatique pour les Systemes d’Enterprice)
- 1992; EPC (Eventdriven Process Chains)
- 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method)
- 2001: ebXML v.1.1 (electronic business using eXtesible Markup Language)
- 2002: BPML v.1.1 (Busines Process Modeling Language)
- 2002: WSCi v.1.0
- 2003: BPEL4WS (Business Process Execution Language for Web Services)
- 2004: BPMN (Business Process Modeling Notation)
(na podstawie “Process modeling – A Maturing Discipline?”, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of technology Information).
Sieci Petriego są nadal uważane za jedno z najskuteczniejszych narzędzi do modelowania jednak ich głównym ograniczeniem jest dość skomplikowany model matematyczny oraz brak hierarchizacji funkcji jak to ma miejsce w realnych organizacjach. Nie zawiera też w sobie narzędzi do opisu architektury obiektowej oprogramowania. Metody tworzenia oprogramowania zorientowane obiektowo doprowadziły do powstania narzędzi typu UML jednak są one bardzo trudne do zastosowania w modelowaniu biznesowym gdyż natura organizacji jest hierarchiczna a nie obiektowa. Modele obiektowe są po pierwsze praktycznie niezrozumiałe dla biznesu po drugie nie sprawdzają się jako narzędzie do opisu organizacji, która żyje i ewoluuje. Stale rozwijające się metody zarządzania ewoluują w stronę procesów biznesowych ich natura zaś jest jest hierarchiczna. Kolejną próbą rozwiązania problemu jest powstanie BPMN.
BPMN – Business Process Modeling Notation
Ideą twórców BPMN jest stworzenie narzędzia dla analityków ale takiego, którego produkty da się “tłumaczyć” na BPEL4WS. Bazą dla BPMN są sieci Petriego i EPC. Dla tego z jednej strony kompletna lista symboli BPMN to 38 symboli obrazujących typowe zdarzenia biznesowe dające się odwzorować za pomocą BPEL4WS, modelować zaś można już za pomocą sześciu podstawowych, które pozwalają na zbudowanie pełnego modelu procesów biznesowych. Pozostałe symbole służą do dodatkowego definiowania zdarzeń koniecznych z punktu widzenia inżynierii oprogramowania. Dlatego np. model wykonany za pomocą podstawowego zestawu symboli przez analityka da się łatwo uzupełnić jako kontynuacja projektu o brakujące elementy w celu wygenerowania kodu dla BPEL. ten zaś być może będzie standardem służących do generowania kodu aplikacji jak dawne systemu typu CASE.
Notatka: W tym roku (2005) opublikowano wersję 1.0 notacji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odbyła się konferencja BPMN Foundation na której między innymi ogłoszono połączenie Notation Working Group z OMG i specyfikację BPMN v.1.0. W planie jest RFC.
