Przypadki użycia (ang. Use case) – to po prostu lista funkcjonalności systemu,

zwykle wraz z interakcjami między rolą (tzn. aktor -> ang. actor) a systemem.

Aczkolwiek czasem aktora można pominąć :)

Składowe:

Aktor – może to być człowiek, księgowy, dyrektor, ufoludek a może to być sys-

tem zewnętrzny (czyli taki którego akurat teraz nie projektujemy – ale wchodzi z

tym naszym w interakcje).

System – to jest co modelujemy :) Ale nie musi to być aplikacja! Może to być

np. urządzenie lub inna rzecz obrazująca pewną całość której funkcjonalności

chcemy opisać.

Przypadki użycia – czyli funkcjonalności. Uwaga! Tu nas nie interesuje jak owe

funkcjonalności są zrealizowane technicznie.

Relacje – czyli relacje zachodzące między poszczególnymi składowymi nasze-

go modelu.

Symbol Z czym to się je?

Aktor jest obrazowany jako

ludzik, ale nie zawsze będzie

to człowiek!

Pojedynczy przypadek użycia

- jest obrazowany jako elipsa i

oznacza pojedynczą funkcjo-

nalność.

Prosta linia obrazuje podsta-

wową relacje między przy-

padkiem użycia a aktorem.

Include czyli „dołączanie”.

Dołączony przypadek użycia

zazwyczaj nie może działać

samodzielnie i jest częścią

większego przypadku użycia.

Łopatologicznie: Use Case jest większą całością a Use Case 2 jego częścią. Use

Case nie może działać BEZ Use Case2 (czyli Use Case2 nie jest opcjonalne). Taki

zabieg stosuje się aby umożliwić korzystanie z pewnych przypadków użycia przez in-

ne. Uwaga! Use Case2 nie może działać samodzielnie.

Extend czyli „rozszerzanie”.

Jest do dodatkowa funkcjo-

nalność.

Łopatologicznie: Use Case3 może działać BEZ Use Case4 (jest to opcja dodatko-

wa rozszerzająca możliwości systemu).

Skrócony przewodnik po UML – USE CASE

UML USE CASE —Dobre praktyki:

Legenda – nie każdy zna UMLa. Nawet jeśli podchodzisz ortodoksyjnie i rysujesz

wszystkie strzałki zgodnie ze sztuką, to istnieje szansa że Twój odbiorca nie do końca

zrozumie przekaz. Minimalizuj ryzyko i umieść legendę w rogu schematu.

Upraszczaj – nawet skomplikowane problemy da się „ prosto” przedstawić, ale trze-

ba pogłówkować. Jeśli pierwszy schemat wyjdzie skomplikowany – nie zrażaj się tym!

Potraktuj go jako punkt wyjścia do podziału na prostsze elementy. Widzisz, nawet w

analizie wymagań można zastosować agile’owe podejście iteracyjne.

Staraj się unikać plątaniny i dużej ilości przecięć linii oznaczających relacje – dzięki

temu model będzie czytelniejszy. Parę przecinających się linii jeszcze nie jest zła,

gorzej jak nasz model zaczyna przypominać spaghetti.

UML USE CASE—FAQ:

Jak przedstawić sekwencje? Aby przedstawić ciąg zdarzeń najlepiej zastosować

Diagram Sekwencji (lub w prostszy sposób za pomocą schematu blokowego <ang.

flowchart> który nie jest częścią UML!). Przypadki użycia nadają się do obrazowania

przepływów średnio – jest to raczej lista czynności a nie schemat ich wykonania.

Jaki poziom szczegółowości zastosować? Odpowiedni. To znaczy że jednak należy

trzymać się ogółu. Use Case powinien być prosty, jeśli stopień skomplikowania wzra-

sta to warto zastanowić się nad podzieleniem Use Case’u na części.

Jak czytać Use Case? Od lewej do prawej :) Dobra praktyka mówi że po lewej powinni

znajdować się aktorzy inicjujący przypadki użycia a po prawej – odbierający. W zależ-

ności od stopnia skomplikowania modelu może okazać się, że taki sposób nie spraw-

dzi się.

Strzałka z linią przerywaną czy ciągłą? Jaki grot? UML to notacja mająca ułatwić

komunikację. Jeśli gubisz się w strzałkach i co więcej inni też nie wiedzą o co w nich

chodzi – stwórz własną „terminologię”. Jak? Obok diagramu umieść legendę ze strzał-

kami oraz opisem co która oznacza.

Czy zawsze muszę używać ludzika jako aktora? Nie, można używać także innych

symboli (ikon). Często narzędzia pozwalające na rysowanie UML na komputerze w

sekcji „Use Case” nie udostępniają niczego poza ludzikiem do obrazowania aktorów,

niemniej jednak zawsze można skorzystać z zestawu ikon z innego przybornika. A jak

się rysuje na kartce to granicą jest tylko wyobraźnia. Pamiętaj jednak: ważne aby Twój

model był zrozumiały! Jeśli używasz wielu kształtów inaczej niż jest to opisane w nota-

cji – pamiętaj o legendzie!

Przykład „Flowchart” z przymrużeniem oka

———————————————

Uwagi do materiałów: opracowanie własne na podstawie praktyki i literatury. Mieszanie języka polskiego i angiel-

skiego na rysunkach występuje z uwagi na oszczędność miejsca (raz w jednym raz w drugim języku można coś

napisać krócej). Możesz śmiało kopiować i rozpowszechniać!

Materiały do ćwiczeń w wersji elektronicznej znajdziesz na moim blogu: http://mrowca-kasia.blogspot.com/

Źródło: http://xkcd.com

Groch z kapustą—trochę o UML, a trochę o schemacie blokowym!