Use Case modeling - basics

332 views

Published on

Brief description of basic modeling techniques from workshop I conducted at WebMuses Unplugged

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
332
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Use Case modeling - basics

  1. 1. 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
  2. 2. 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!

×