UML dla każdego
Notacja UML umożliwia opisanie założeń, jak i dokumentowanie istniejącego systemu w sposób graficzny w postaci dedykowanych diagramów. Diagramy te pozwalają na formalne opisywanie i modelowanie struktur czy procesów w sposób zrozumiały zarówno dla zespołu technicznego, jak i interesariuszy.
Diagramy UML dzielimy na te, które opisują strukturę, jak np. diagram klas czy komponentów, oraz diagramy, za pomocą których modelujemy zachowanie systemu – jak np. diagram przypadków użycia, aktywności czy diagram sekwencji.
Spróbuję w sposób praktyczny przybliżyć świat UML na podstawie bliskiego Inetum przykładu, a mianowicie outsourcingu pracowników oraz całego procesu od momentu zapytania o danego specjalistę do momentu rozpoczęcia współpracy. Aby przybliżyć podstawy UML (a tym samym zachęcić do stosowania i czytania diagramów UML), zastosuję uproszczoną formę zapisu tego procesu.
Przeczytaj także: UML i BPMN – narzędzia pracy analityczki i analityka
Outsourcing specjalisty IT – UML w praktyce
Wyobraźmy sobie, że dana firma rozwija system finansowy i jest zainteresowana wynajmem pracownika specjalizującego się w danej dziedzinie (programista, tester, analityk), posiadającego określone kompetencje. Do wyspecyfikowania cech, które będą istotne, może posłużyć diagram klas, który opisze pracownika oraz jego kompetencje.
Diagram klas
Diagram klas obrazuje zbiór klas, interfejsów oraz zależności pomiędzy nimi. Pozwala na szczegółowy opis klas ze zwróceniem uwagi na dostępne atrybuty i operacje.
Pomiędzy klasami mogą występować relacje jednokierunkowe lub dwukierunkowe, jak dziedziczenie, zależności pomiędzy klasami czy przypisanie elementów jednej klasy do drugiej.
W naszym przykładzie każdy pracownik ma przypisane stanowisko należące do danego działu. Dodatkowo pracownik posiada wiele kompetencji określonych przez klasę Kompetencje.
Mówiąc o procesie, chcemy zidentyfikować osoby biorące w nim udział. W notacji UML takie osoby są nazywane aktorami. Aktor jest rolą, którą użytkownik pełni w stosunku do systemu oraz przypadków użycia – może nim być człowiek, urządzenie lub inny system. Mając określonych aktorów, zaczynamy modelowanie z wykorzystaniem diagramu przypadków użycia.
Diagram przypadków użycia
Diagram ten odgrywa najważniejszą rolę w procesie projektowania systemu. Opisuje on wymagania systemu oraz identyfikuje funkcjonalności, jakie zawiera.
Wymagania funkcjonalne systemu definiujemy za pomocą przypadków użycia, które w sposób graficzny reprezentują te wymagania. Przypadki użycia (PU) nazywają daną funkcjonalność systemu, opisują zależności, w których dany przypadek wystąpi, oraz opisują scenariusze kolejno wykonywanych czynności służących do zrealizowania danego PU. Przykładowo scenariusze opisujące PU są podstawą dla tworzenia przypadków testowych danego zakresu aplikacji.
Jak wyglądałoby zastosowanie modelu przypadków użycia w kontekście outsourcingu? Model w jasny sposób prezentuje, który aktor (klient, pracownik działu sprzedaży, programista, manager) jest związany z daną częścią procesu. Klient zgłasza zapotrzebowanie na danego specjalistę, osoba z działu sprzedaży weryfikuje, czy istnieje pracownik o wymaganych kompetencjach, i potwierdza jego dostępność z przełożonym. Po znalezieniu konkretnej osoby może (ale nie musi) odbyć się rozmowa techniczna weryfikująca umiejętności kandydata.
–> include (związek zawierania) rozszerza funkcjonalność bazowego PU. W naszym przypadku oznacza, że funkcjonalność zamówienia specjalisty zawsze wiąże się z weryfikacją dostępnych pracowników.
<– extend (związek rozszerzania) wskazuje, że dany PU opcjonalnie rozszerza funkcjonalność PU bazowego. W omawianym przykładzie weryfikacja techniczna nie jest częścią konieczną procesu rekrutacji.
Diagram sekwencji
Ten sam proces można zamodelować, biorąc pod uwagę przepływy pomiędzy aktorami/systemami z uwzględnieniem czasu oraz komunikatów (interakcji).
Służy do prezentowania interakcji pomiędzy obiektami wraz z uwzględnieniem w czasie komunikatów, jakie są przesyłane pomiędzy nimi. Obiektami wchodzącymi w interakcje mogą być aktorzy oraz obiekty wewnętrzne lub zewnętrzne (systemy) komunikujące się pomiędzy sobą.
Poniżej przedstawiony został uproszczony przebieg procesu zamówienia oraz pozytywnej weryfikacji pracownika zakończony podjęciem decyzji o współpracy z kandydatem.
Po zapytaniu klienta o specjalistę o danych kompetencjach pracownik działu sprzedaży weryfikuje, czy istnieje taki pracownik, używając do tego systemu ewidencji pracowników (JMatrix). W przypadku negatywnej weryfikacji klient natychmiast otrzymuje odpowiedź i na tym kończy się proces. Dla pozytywnej weryfikacji należy dodatkowo sprawdzić dostępność pracownika – w tym celu pracownik działu sprzedaży kontaktuje się z przełożonym pracownika.
W przypadku dostępności pracownika może nastąpić rozmowa kwalifikująca go do projektu przeprowadzona przez klienta. Cały proces kończy się uzgodnieniem warunków współpracy oraz przekazaniem informacji o rozpoczęciu pracy w projekcie.
Zastosowanie diagramów UML – podsumowanie
Jak pokazał powyższy przykład, UML może służyć nie tylko do opisywania skomplikowanych procesów systemu, ale i do graficznego przedstawienia wielu czynności zarówno biznesowych, jak i z życia codziennego. To tylko namiastka ogromu możliwości, różnorodnych diagramów oraz powiązań, które wykorzystuje się w modelowaniu za pomocą UML. Niewątpliwie jest to doskonałe narzędzie do precyzyjnego opisania każdego systemu informatycznego oraz dokumentowania wszelkich jego zawiłości.
Przeczytaj także: 7 grzechów głównych w analizie biznesowej
