use case modeling - basics
DESCRIPTION
Brief description of basic modeling techniques from workshop I conducted at WebMuses UnpluggedTRANSCRIPT
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!