Diagram przypadków użycia UML

Zarejestruj się za darmo. Będziesz otrzymywać bieżące informacje na temat szkoleń, języka UML i narzędzia Enterprise Architect

Interesuje Cię szkolenie - wypełnij ankietę, my przygotujemy ofertę dla Twojej firmy.

Diagram przypadków użycia

Diagramy przypadków użycia

Cel: Opisanie funkcjonalności widzianej z zewnątrz sytemu (ew. klasy, komponentu, podsystemu; formalnie wszystkiego co ma zachowanie)

Dziedziny dominujące: wymagania i modelowanie biznesowe

Dla: wszystkich osób

Stopień trudności: zapis bardzo prosty, w praktyce modelowanie PU jest jednym z najtrudniejszych etapów przedsięwzięcia informatycznego

Klasyfikacja: diagramy zachowania

Użycie: praktycznie w każdym projekcie

Formalnie:

aktor jest klasą
PU jest klasyfikatorem
Rysując diagram sekwencji specyfikuje się nie tyle PU co jego występnie (instancję)

Mają zasadnicze znaczenie w inżynierii wymagań ale ich „odbiorcami” są wszystkie kategorie osób uczestniczące w przedsięwzięciu informatycznym.

PU ukazują wymagania funkcjonalne – co system robi.

Wymagania niefunkcjonalne (jak realizowana jest owa funkcjonalność) modelowane są przy pomocy ograniczeń ew. notatek.

Definicja PU:

PU jest specyfikacją zbioru akcji wykonywanych przez system które produkują obserwowalny rezultat i wartość dla jednego lub więcej aktorów lub osób związanych z systemem. Musi mieć sens dla aktora – zwracać jakąś użyteczną dla niego wartość. Nie idę do banku się zarejestrować w ich systemie ale wziąć kredyt, zrobić przelew. Nie idę do bankomatu aby włożyć kartę ale aby wypłacić pieniądze, sprawdzić saldo. Nie loguję się do systemu rezerwacji online dla samego zalogowania ale np. aby zrobić rezerwację.

Cechy PU:

PU jest inicjowany przez aktora.
PU ma dobrze zdefiniowaną i skończoną funkcjonalność.
PU musi dostarczać obserwowalny rezultat.
Wewnętrzna struktura systemu jest pomijana.
Aktor może być rolą w kolaboracji (: przed nazwą)

Typowe elementy diagramów PU

Aktorzy – użytkownicy systemu (osoby lub inne systemy, które inicjują interakcję z systemem. Zawsze na zewnątrz systemu.)
PU np. Zakup towaru, otwarcie rachunku, złożenie zamówienia Ale nie: ~~wprowadzenie nazwiska do formatki, przeciśnięcie przycisku anuluj~~
Relacje generalizacji pomiędzy aktorami np. klient – klient instytucjonalny, pracownik – kierownik,
Relacje generalizacji pomiędzy dwoma PU (w praktyce się nie używa)
Relacje asocjacji pomiędzy aktorami a PU np. klient – złożenie zamównia
Relacje <<extend>> i <<include>> PU

Wymagania formalne

Aktor poza systemem
Aktor musi mieć nazwę.
Aktor może być w asocjacji wyłącznie z PU, klasami i komponentami. Relacje te muszą być binarne.
Punkt rozszerzania musi mieć nazwę.
PU musi mieć nazwę
Asocjacje PU muszą być binarne
Nie może być asocjacji pomiędzy PU opisującymi ten sam podmiot (system)
Relacje <<include>> nie mogą tworzyć cykli.

Zmiany z poprzednich wersji UML

Koncepcja aktora bez zmian (ograniczenie: aktor musi mieć nazwę). Pomiędzy opisem w wersji 1.4 i 2.0 są różnice redakcyjne – nie istotne z praktycznego punktu widzenia
Relacja <<extend>> Różnica formalna na poziomie MM (extend obecnie dziedziczy z DirectedRelationship (źródło: rozszerzający, cel: rozszerzany PU a w 1.4 z Relationship). Warunek rozszerazania i punkt rozszerzania mogą być określone jako notatka „przyczepiona” do relacji.
Zmiany formalne dotyczące punktu rozszerzania, który w poprzednich wersjach był elementem modelu a teraz jest cechą PU – bez znaczenia praktycznego w modelowaniu.
Relacja <<include>> b.z.
PU mogą być „posiadane” przez klasyfikator (np. podsystem, klasę itp.)

Typowe błędy:

Traktowanie PU jak kroku algorytmu, czynności (np. wprowadzenie PIN-u, wprowadzenie nazwiska)
Niewłaściwa identyfikacja aktorów zwłaszcza gdy, czynność np. wyliczanie czegoś, pomiar jest inicjowana przez system.
Niewłaściwe zastosowanie relacji <<extends>> i <<include>>
Określanie modelowanego systemu mianem aktora
Skupianie się na technicznym aspekcie rozwiązania
Zbyt silna identyfikacja aktora z konkretną osobą (osoba może występować jako wiele aktorów)
Niedoszacowanie ilości PU może spowodować zbyt niską wycenę projektu co może skutkować, iż całe przedsięwzięcie się nie opłaci, przekroczy czas, budżet i zasoby.

Opisywanie PU
- Słowne (scenariusze)
- Warunki pre i post
- Diagramy aktywności
- Diagramy stanów
- Diagramy sekwencji
- Kolaboracje (komunkacje)
Podział PU: