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
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.
Scenariusze należy traktować jako konkretne wystąpienia przypadku użycia.
Aktor
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ę.
Rysunek 4. Połączenie aktora z przypadkiem użycia
Bardzo często jest to asocjacja skierowana, która wskazuje, kto inicjuje usługę.
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. Istotny jest fakt, że związek zawierania zawsze skierowany jest grotem w stronę zawieranego przypadku użycia (rys. 6).
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.
Rysunek 7. Związek rozszerzenia
W związku rozszerzenia grot zależności musi być skierowany w kierunku bazowego przypadku użycia (rys. 7).
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:
Cześć 🙂
A propos przypadków użycia:
„przepływ zdarzeń (scenariusze)”<- to chyba są kroki a nie scenariusze.
Z tego co się uczyłam to Scenariusz jest zbiorem przypadków testowych.
Mógłbyś to potwierdzić lub zanegować? Bo już sama nie jestem pewna.
Pozdrawiam
Hej
Scenariusze składają się z kroków. Scenariusz nie jest zbiorem przypadków testowych. Scenariusz z przypadku użycia może być jednym ze scenariuszy testowych.
Przypadek użycia ma jeden lub kilka alternatywnych scenariuszy, które zbudowane są z kroków… testem jest zgodność implementacji z projektem.
dostałem takie pytanie od klienta, więc wyjaśniam
nie jest prawdą, ż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.”
bo:
– „includowanych” przypadków użycia nie wolno łączyć z aktorem
– aktor na modelu może być ważnym bytem na diagramie a nie mającym interakcji z systemem modelowanym np. diagram przypadków użycia jako kontekst interesariuszy
Trochę się zgadzam a trochę nie.
– „includowanych” przypadków użycia nie wolno łączyć z aktoremTu jest podłączony via inny przypadek użycia
– aktor na modelu może być ważnym bytem na diagramie a nie mającym interakcji z systemem modelowanym np. diagram przypadków użycia jako kontekst interesariuszyJeśli coś nie jest związane z systemem, nie korzysta z jego funkcji to umieszczeni go na diagramie, moim zdaniem, jest nadmiarowe.