Diagramy UML i BPMN - wspólny język analityków, menadżerów i informatyków.

Schematy graficzne od dawna były w zarządzaniu używane do opisu struktur i procesów. Kiedy w latach 80-tych ubiegłego wieku upowszechniły się metody obiektowe, stało się oczywiste, że elementy schematów graficznych powinno się traktować jako obiekty. Pojawiło się kilka tego typu notacji. Aby uporządkować te prace, wprowadzono jednolity standard UML (Zunifikowany Język Modelowania, ang. Unified Modeling Language). Dlaczego język? Gdyż elementy schematów graficznych mają struktury analogiczne jak wypowiedzi języka (zdania, słowa, pojęcia).

Często można spotkać opinię, że UML jest narzędziem programistów lub projektantów systemów. Może ona wiązać się z tym, że implementację UML można znaleźć w narzędziach softwerowych dla programistów (CASE). Jednak UML może on mieć także inne zastosowania:

• w analizie i projektowaniu systemów (na przykład w pracach nad informatyzacją)
• w optymalizacji procesów biznesowych.

Sposób w jaki powstał UML, wiąże się z pewną jego wadą. Jest to standard bardzo rozbudowany i obejmuje aż 12 różnych diagramów. Z punktu widzenia analizy i projektowania systemów najbardziej użyteczne są trzy, które zostaną pokrótce omówione poniżej: aktywności, klas i przypadków użycia. Celem tego tekstu nie jest kompletny opis diagramów, ale pokazanie ich zastosowań. Dlatego podano konkretne przykłady i poszerzono prezentację o opis innych metod stosowanych w praktyce.

Diagram aktywności

Diagram aktywności pokazuje procesy i zachowania na najbardziej abstrakcyjnym poziomie. Należy na niego patrzeć jak na przepływ znacznika sterowania (tokenu) wskazującego aktualnie wykonywaną czynność (akcję). Najważniejszym elementem diagramu są właśnie opisy czynności, zawarte w prostokącie z zaokrąglonymi rogami.

Tworzenie diagramu rozpoczynamy od identyfikacji poszczególnych akcji. Podział procesu na akcje powinien być wykonany w taki sposób, by było możliwe na dalszym etapie analizy przypisanie poszczególnym akcjom klas (obiektów - zob. opis diagramu klas). Szczegóły konstrukcji diagramu pokazuje poniższy przykład, opisujący wykonanie płatności SMS'em:

Najważniejsze elementy diagramu:

Strona z bardziej szczegółowym opisem i wieloma przykładami:

http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

BPMN

Jak wspomniano, diagram aktywności UML można wykorzystać w analizie procesów biznesowych. Pewną trudność stanowią jednak wspomniane związki UML z inżynierią oprogramowania i wynikające stąd podejście obiektowe. Menadżerowie mają raczej skłonność do myślenia procesowego niż obiektowego. Różna interpretacja tych samych zapisów graficznych może zaś prowadzić do nieporozumień. Dlatego powstał inny standard obejmujący wyłącznie modelowanie procesów: Business Process Modeling Notation (BPMN). Poniższy przykład pokazuje zasadnicze podobieństwa i różnice w stosunku do diagramu aktywności:

Diagram ten jest nieco bardziej skomplikowany (i nie wynika to jedynie z ładniejszej grafiki). Początków UML należy szukać w diagramach rysowanych kredą na tablicy. BPMN raczej trudno tworzyć bez komputera. Na szczęście istnieją dwa dobre i darmowe programy służące do tych celów:

• http://www.bizagi.com/
• http://www.ariscommunity.com/aris-express

Pierwszy z nich jest wygodniejszy w użyciu, ale dostarcza jedynie podstawowych elementów.

Metodzie BPMN jest poświęcona strona firmy MGX Infoservice:

http://www.mgx.com.pl/readarticle.php?article_id=10

Można też polecić książkę Marka Piotrowskiego "Notacja modelowania procesów biznesowych – podstawy".

Podstawowe elementy diagramów przedstawia poniższy schemat (nazewnictwo zaczerpnięto z pływania):

Baseny i tory reprezentują odpowiedzialności w procesie. Mogą to być organizacje, role lub systemy. Między zadaniami następuje przepływ komunikatu (tokenu) - podobnie jak w diagramach aktywności.

Diagramy te mogą być bardziej rozbudowane. Pełen standard opisuje kilkadziesiąt elementów. Bardziej szczegółowy opis można znaleźć na stronach:

• http://sdcenter.pl/system/lectures/attachment1s/1508/original/06_-_BPMN_-_rola_standardu_modelowania_proces_w_w_Administracji_Publicznej_01.pdf?1274347120
• http://www.omg.org/cgi-bin/doc?dtc/10-06-02

lub we wspomnianej książce Marka Piotrowskiego.

Przypadki użycia

Jeśli celem analizy nie jest jedynie audyt i/lub optymalizacja procesów, ale implementacja lub rozbudowa systemu, musimy dokonać analizy poszczególnych działań. Służą do tego przypadki użycia. Diagram przypadku użycia składa się z opisu przypadku (w elipsie) i połączonych z nim aktorów (schematycznie narysowany ludzik).

Diagram można interpretować jako opis działania, jakie może być wykonywane na rzecz aktorów. Aktorem może być nie tylko osoba, ale na przykład podsystem lub urządzenie. Wyjaśnia to poniższy przykład:

Przypadki użycia są kluczowe dla prawidłowego sformułowania wymogów wobec systemów. Dlatego takie proste schematy nie są wystarczające i stosuje się opis tekstowy. Stanowi on specyfikację funkcjonalną, opisującą cele systemu (wymagania). Warto przy tym skorzystać z podręcznika Alistaira Cockburna "Jak pisać efektrywne przypadki użycia" („Writing Effective Use Cases”). Cockburn zaproponował klasyfikację przypadków użycia względem zakresu projektowego i poziomów.

Zakresy projektowe:

• gospodarczy - opis zewnętrzny (enterprise)
• gospodarczy - szczegóły (system)
• systemowy - opis zewnętrzny (subsystem)
• systemowy - szczegóły (subsystem)
• komponentowy (component)

Poziomy:

• opis ogólny (very high summary)
• poziom streszczenia (summary)
• poziom użytkownika (user-goal)
• podfunkcje (subfunction)
• poziom najniższy (too low)

Cele wyższego poziomu skupiają się na pytaniu: dlaczego; poziom niższy: jak.

Opis przypadku użycia rozpoczyna się od ustalenia aktora głównego i ogólnego opisu (szkicu).

Dla pokazanego na powyższym diagramie przypadku, możemy ustalić:

Pozostałe elementy opisu przypadku użycia, to:

1. Cel w kontekście: jaki jest cel opisywanego działania.
2. Minimalna gwarancja: co powinno się zdarzyć w wyniku poprawnego wykonania działania
3. Główny scenariusz powodzenia: jaki jest przebieg operacji
4. Rozszerzenia: sytuacje nadzwyczajne (wyjątki, warunki rozszerzenia) i reakcje na nie.

Dla powyższego przykładu mamy:

1. Cel w kontekście: Dokonanie zapłaty w ramach transakcji przeprowadzonej elektronicznie.
2. Minimalna gwarancja: W systemie sprzedaży pojawi się informacja o zapłacie.
3. Główny scenariusz powodzenia: Klient wysyła SMS'a na numer podany przez system sprzedaży. Do numeru tego jest jednoznacznie przypisana kwota. System rozliczeń po otrzymaniu SMS'a rejestruje informację o dokonaniu zapłaty i przekazuje ją do systemu sprzedaży. System sprzedaży odnotowuje w opisie transakcji, że zapłata została wykonana. Na numer klienta jest wysyłany SMS z potwierdzeniem.

Rozszerzenia:

Aczkolwiek przypadki użycia w procesie projektowania systemów są kluczowe, to opis procesów biznesowych (BPMN) ułatwia ich zrozumienie. Dlatego warto analizę wymagań wobec systemów poprzedzić analizą procesów (zob.

http://www.michalwolski.com/2008/04/przypadki-uzycia-sa-latwiejsze-do-zrozumienia-niz-diagramy-bpmn/).

Diagram klas

Ostatnim rodzajem diagramów, jaki powinien pojawić się w procesie analizy są diagramy klas. Jest opis struktury (a więc od środka) systemu w terminologii obiektowej. Każdemu obiektowi przypisuje się atrybuty i operacje jakie mogą być w ramach tego obiektu wykonywane (funkcja, metody). Na podstawie takiego modelu można bardzo łatwo przejść do projektu bazy danych dla systemu. Najczęściej klasie odpowiada relacja (tabela bazy danych), a atrybuty klas stają się atrybutami relacji (kolumnami tabel).

Każdą klasę (obiekt) opisuje się prostokątem podzielonym na trzy pola:

• identyfikator
• atrybuty
• metody 

Klasy mnogą być powiązane ze sobą na dziedziczenia (atrybutów i metod), asocjacji (zbiory), agregacji lub kompozycji (część - całość). Szczegółowe objaśnienie znajdziesz tutaj.

Znów posłużmy się przykładem:

Zakończenie

Pomimo, że powyższy opis zawiera jedynie wybrane elementy używanych w analizie i projektowaniu systemów metod, jest to opis kompletny. Oznacza to, że posługując się opisanymi metodami można dokonać analizy systemu. Uproszczenie takiej analizy ułatwia komunikację i przyspiesza proces projektowania. Takie podejście jest szczególnie godne polecenia w nowoczesnych metodologiach zwinnych (agile). Stanowi bowiem bardzo rozsądny kompromis gmiędzy dokładnością opisu a prostotą. Zwłaszcza gdy głównym celem takiego opisu jest porozumienie między wykonawcą systemu i przyszłymi jego użytkownikami.