Strona główna

Prowadź biznes efektywnie
dzięki zastosowaniu informatycznych rozwiązań

Aktualności

Prace nad szkoleniami

Obecnie trwają prace nad opracowaniem szkoleń E-learningowych i M-learningowych zawierających informacje przeznaczone dla osób prowadzących działalność gospodarczą w sektorze MŚP. Planowany termin zakończenia tych prac to 31 grudzień 2011.

Uruchomienie platrofmy e-learningowej

30 czerwca 2011, zgodnie z harmonogramem projektu uruchomiona została platforma E-learningowa.

Publikacja strony www projektu

31 marca 2011 r. uruchomiona została platforma oparta na technologii www, zintegrowana z platformą E-Learningu, E-firma i E-Turist

Wydarzenia

«Październik 2019»
Pn Wt Śr Cz Pt So Nd
  01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
 
Brak nadchodzących wydarzeń wpisanych do kalendarza

Ankieta

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:

 

Zdarzenia:

  • Zdarzenie rozpoczęcie (utworzenie tokenu)
  • Zakończenie (zniszczenie wszystkich tokenów)
  • Zdarzenie pośrednie (utworzenie / zniszczenie tokenu)

Akcja / zdarzenie

przepływ (przesunięcie tokenu)

decyzja (warunek) - wybór jednej z możliwych ścieżek przepływu sterowania

współbieżne ścieżki sterowania: złączenie lub rozdzielenie

 

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:

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:

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ć:

 

Zakres projektowy

systemowy - opis zewnętrzny

Poziom

użytkownika

Aktor główny

klient

Szkic

klient wysyła SMS'a przy pomocy telefonu komórkowego do systemu rozliczeń; informacja o dokonaniu zapłaty jest przekazywana do systemu sprzedaży

 

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:

 

 

Warunki rozszerzeń

Obsługa rozszerzeń

1

Klient nie otrzymał SMS'u z potwierdzeniem.

Możliwość sprawdzenia, czy w systemie sprzedaży zarejestrowano płatność i ewentualne zgłoszenie reklamacji.

 

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.

Projekt współfinansowany ze środków Unii Europejskiej z Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Podkarpackiego na lata 2007 – 2013