Budowanie rozwiązań informatycznych poprzedza określenie potrzeb. Potrzeby te, zwane wymaganiami, pozwalają określić jaki ma być system, jakie funkcje ma realizować. Wymagania, w pierwszej fazie ich zbierania są zazwyczaj zapisane słowami. Przy zastosowaniu w projekcie języka UML, mogą zostać również zapisane
w formie graficznej. Możliwość odwzorowania graficznego wymagań funkcjonalnych stawianych systemowi, jest niewątpliwie jedną z największych zalet języka UML. W rozdziale tym zostanie przedstawiona technika umożliwiająca modelowanie otoczenia systemu i wymagań, jakie są mu stawiane.

Diagram przypadków użycia – definicja i zastosowanie

Diagram przypadków użycia (ang. use case diagram) jest diagramem, który przedstawia funkcjonalność systemu wraz z jego otoczeniem.

Diagramy przypadków użycia pozwalają na graficzne zaprezentowanie własności systemu tak, jak są one widziane po stronie użytkownika.

Diagramy przypadków użycia służą do zobrazowania usług, które są widoczne z zewnątrz systemu.

Diagram przypadków użycia – notacja i semantyka

Diagram przypadków użycia, mimo iż jest zbudowany z kilku elementów, odgrywa najważniejszą rolę w procesie projektowania systemu; opisuje bowiem wymagania funkcjonalne, jakim system musi sprostać, i otoczenie, w którym  się znajduje. Diagram ten jest agregatem funkcji usług, które wykonuje system. Poza specyfikacją, diagram ten pozwala na identyfikację funkcjonalności, weryfikację postępów w modelowaniu i implementacji, a także wspomaga komunikację pomiędzy uczestnikami projektu.

Przypadek użycia

image

Rysunek 2. Przypadek użycia – notacja

Przypadek użycia (ang. use case) to zbiór scenariuszy powiązanych ze sobą wspólnym celem użytkownika. Przypadek użycia jest graficzną reprezentacją wymagań funkcjonalnych. Definiuje zachowanie systemu bez informowania  o wewnętrznej strukturze i narzucania sposobu implementacji. Przypadek użycia pozwala na zdefiniowanie przyszłego, spodziewanego zachowania systemu. Dostarcza także kwant funkcjonalności dostępnej dla użytkownika. Przypadki użycia są stosowane w całej analizie systemu i mają za zadanie dostarczyć wyniki, z których użytkownik będzie mógł skorzystać, i które go zainteresują. Istotny jest fakt, że przypadek użycia musi być w interakcji chociaż z jednym aktorem. Wyjątek stanowi sytuacja, gdy przypadek użycia jest połączony związkiem rozszerzenia lub zawierania z innym przypadkiem użycia. Każdy przypadek użycia możemy opisać za pomocą następujących cech:

  • nazwa;
  • opis;
  • przepływ zdarzeń (scenariusze);
  • zależności i relacje;
  • diagramy aktywności;
  • wymagania specjalne;
  • warunki wstępne;
  • warunki końcowe.

Jedną z najważniejszych cech, jaką opisuje przypadek użycia, jest przepływ zdarzeń – scenariusze, które wskazują zestaw, sekwencję kolejno wykonywanych czynności służących do zrealizowania funkcjonalności zobrazowanej przez dany przypadek użycia. Za pomocą scenariusza możemy zaprezentować:

  • podstawowy zestaw czynności, który reprezentuje podstawową oczekiwaną sekwencję zdarzeń (ang. basic flows);
  • inne sekwencje zdarzeń (ang. alternative flows), które możemy podzielić na:
    inne warianty zakończenia scenariusza,
    dodatkowe przypadki,
    sekwencje zdarzeń obejmujące obsługę wyjątków i błędów.

Scenariusze należy traktować jako konkretne wystąpienia przypadku użycia.

Aktor

najczesciej_stosowana_notacja_UML_2011_html_m673eeeb0

Rysunek 3. Aktor – notacja

Aktor (ang. actor) jest rolą, którą pełni użytkownik w stosunku do systemu oraz przypadków użycia. Aktor reprezentuje spójny zbiór ról, które są odgrywane przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem. Aktorem może być człowiek, urządzenie lub inny system. Aktor nie musi  być fizycznym obiektem. Istotne jest, by pełnił określoną funkcję wobec systemu i przypadku użycia, którego używa. Aktor reprezentuję rolę, w którą człowiek, urządzenie bądź inny system może się wcielić w trakcie współpracy z modelowanym systemem.

Szczególną uwagę należy zwrócić na fakt, iż aktor zawsze reprezentuje otoczenie systemu (nie jest częścią systemu) i musi być w interakcji chociaż
z jednym przypadkiem użycia.

  • Podsumowując, możemy powiedzieć, że aktor:
    nie jest częścią systemu;
    reprezentuje rolę, w którą może wcielić się użytkownik;
    może reprezentować człowieka, urządzenie bądź inny system;
    może aktywnie wymieniać informacje z systemem;
    może dostarczać informacje;

Do łączenia diagramów przypadków z aktorami najczęściej stosuje
się powiązanie poprzez asocjację.

najczesciej_stosowana_notacja_UML_2011_html_m40799eff

Rysunek 4. Połączenie aktora z przypadkiem użycia

Bardzo często jest to asocjacja skierowana, która wskazuje, kto inicjuje usługę.

najczesciej_stosowana_notacja_UML_2011_html_m658a8ccd

Rysunek 5. Asocjacja skierowana

Na powyższym diagramie, za pomocą asocjacji skierowanej, pokazano Klienta jako inicjatora usługi. Asocjacja skierowana wskazuje także na fakt,
że element inicjujący zawsze zna element inicjowany, natomiast element inicjowany nie zna elementu inicjującego. Innymi słowy, patrząc powyższy rysunek, możemy powiedzieć, że Klient wie o istnieniu możliwości Zarezerwowania samochodu, natomiast Zarezerwowanie samochodu (w rzeczywistości interfejs tego przypadku użycia) nie wie o istnieniu Klienta.

Strukturalne związki zawierania i rozszerzenia

Strukturalne związki, przedstawiane na diagramach przypadków użycia, opisują zależności między elementami modelu usług, określając: całość (bazowy przypadek użycia) i część (zawierany lub rozszerzający przypadek użycia) oraz hierarchię (poprzez związek generalizacji). Związek zawierania (ang. include) polega na rozszerzaniu funkcjonalności bazowego przypadku użycia o zachowanie innego przypadku użycia. Zawierany przypadek użycia nie jest autonomiczny. Stanowi wydzieloną część bazowego przypadku użycia, która jest obowiązkowo wywoływana w procesie realizacji bazowego przypadku użycia. Związek zawierania umożliwia uniknięcie sytuacji, w której ta sama funkcjonalność będzie opisana wielokrotnie. Zawierany przypadek użycia stanowi więc tzw. blok wielokrotnego użycia, który wskazuje tą część rozwiązania, do której można będzie się odwołać wielokrotnie (ang. reuse), co w przyszłości skutkuje redukcją złożoności modelu. Istotny jest fakt, że związek rozszerzenia zawsze skierowany jest grotem w stronę zawieranego przypadku użycia (rys. 6).

najczesciej_stosowana_notacja_UML_2011_html_m577466f

Rysunek 6. Związek zawierania

Inną sytuację przedstawia związek rozszerzenia (ang. extend), który wskazuje, że dany przypadek użycia opcjonalnie rozszerza funkcjonalność bazowego przypadku użycia. Funkcjonalność bazowego przypadku użycia
jest rozszerzana o inny przypadek użycia po spełnieniu określonego warunku. Warunek taki może być zapisany w notce dołączonej do zależności.

najczesciej_stosowana_notacja_UML_2011_html_m39d042b3

Rysunek 7. Związek rozszerzenia

Podczas stosowania związku rozszerzenia należy pamiętać, że grot zależności musi być skierowany w kierunku bazowego przypadku użycia (rys. 7).

1.2.4. Generalizacja

najczesciej_stosowana_notacja_UML_2011_html_6d09185

Rysunek 8. Generalizacja – notacja (diagram przypadków użycia)

Generalizacja (ang. generalization), zwana także uogólnieniem,
jest związkiem pomiędzy aktorami lub przypadkami użycia, w którym jeden
z nich jest bytem ogólnym, a drugi bytem szczegółowym. Byt szczegółowy może zastąpić byt uszczegóławiany. Na zamieszczonym przykładzie (rys. 9) bytem ogólnym (przodkiem) jest Pracownik, a bytem szczegółowym (potomkiem)
jest Administrator systemu. Zgodnie z omawianym rysunkiem (grot strzałki skierowany jest na byt ogólny) można stwierdzić, że każdy Administrator systemu może być Pracownikiem, ale Pracownik nie może zastąpić Administratora systemu.

najczesciej_stosowana_notacja_UML_2011_html_6ddcf03a

Rysunek 9. Przykładowe użycie generalizacji pomiędzy aktorami

W tym miejscu należy wspomnieć o cienkiej linii, która dzieli generalizację od związku zawierania.

najczesciej_stosowana_notacja_UML_2011_html_m1b9da1d3

Rysunek 10. Zastosowanie zależności na diagramie przypadków użycia

Weryfikuj Kartę Kredytową (weryfikacja karty kredytowej może polegać
na obciążeniu konta minimalną kwotą, np. 1 groszem) jest potomkiem Obciąż konto. Na pierwszy rzut oka wydawać by się mogło, że pomiędzy tymi dwoma usługami powinna być także zależność „include”. Jednak w tym przypadku tak nie jest, gdyż przypadek użycia Weryfikuj Kartę Kredytową zawiera niejako w sobie funkcjonalność związaną z obciążeniem konta.

Diagram przypadków użycia – przykładowe zastosowanie

Na zamieszczonym przykładzie (rys. 11) zaprezentowano diagram przypadków użycia. Z diagramu tego wynika, że w interakcję z systemem wchodzi dwóch aktorów: Sprzedawca i Pracownik. Związek generalizacji wskazuje, że Sprzedawca może wystąpić w roli, którą pełni Pracownik.

Na diagramie, graficznymi symbolami przypadków użycia zdefiniowano cztery wymagania funkcjonalne: Określ opcje ubezpieczenia, Dodaj nowy samochód, Określ dodatkowe wyposażenie oraz Wyświetl listę zadań do wykonania. Należy zauważyć, że diagram usług nie definiuje sposobu realizacji postawionych wymagań funkcjonalnych.

image

Rysunek 11. Przykładowy diagram przypadków użycia

Z zaprezentowanego diagramu wynika, że wymaganie Dodaj nowy samochód wiąże się zawsze z Określeniem opcji ubezpieczenia. Oznacza to, że każdemu nowemu samochodowi, który ma być wprowadzony do systemu muszą być obowiązkowo zdefiniowane różne opcje ubezpieczenia. Dodatkowo, dzięki związkowi rozszerzenia przypadek użycia Dodaj nowy samochód może być rozszerzony o przypadek użycia Określ dodatkowe wyposażenie. Należy zauważyć, że Dodawanie nowego samochodu zostanie rozszerzone o określenie dodatkowego wyposażenia w przypadku, gdy samochód może być wyposażony w takie dodatki, co zostało zapisane w notce.

Należy także pamiętać, że każdy przypadek użycia musi być przyporządkowany minimum jednemu aktorowi, a każdy aktor przyporządkowany jest minimum jednemu przypadkowi użycia. Jeżeli przypadki użycia są połączone związkami zawierania lub rozszerzenia, to bazowy przypadek użycia staje się punktem łączącym aktora z danym przypadkiem użycia.

Pozostałe diagramy UML:

Chcę otrzymywać powiadomienia o nowych wpisach na tym blogu

Wyrażam zgodę na przetwarzanie powyższych danych. Potwierdzam zapisanie się na newsletter w celu otrzymywania powiadomień o nowych wpisach. (Mogę wypisać się w dowolnym momencie)

FreshMail.pl
 
Close