use cases - przypadki u¿ycia

Przypadki użycia (use cases)


Po co są przypadki użycia ?Próby definicjiPodstawowe pojęciaNotacjeRelacjeDokumentacjaKroki metodyPrzykłady


Po co są przypadki użycia ?

Gdy projektujemy jakikolwiek system, najważniejszym etapem jest

!!! określenie wymagań !!!Podejście przypadków użycia ma przede wszystkim na względzie ten problem.


Definicje

Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy.

Przypadek użycia specyfikuje zachowanie systemu lub jego części. Jest to opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w

celu dostarczenia określonemu aktorowi godnego uwagi wyniku

Ich głównym celem jest odwzorowanie funkcji projektowanego systemu wtaki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach

opartych na UML przypadkom użycia przypisuje się szczególne znaczenie jako środka napędzającego cały proces rozwoju systemu.


Przypadki użycia w analizieEksperci

Potrzeby

Pomysły

Technologie

Koncepcjazastosowania

Doświadczeniew dziedzinie

przedmiotowej

Przypadkiużycia

Modelzastosowania

Kompletnymodelanalizy

Modeldziedziny

Użytkownicy

mocny wpływsłaby wpływ


Przypadki użycia w analizie c.d.

Cele :

• głębsze zrozumienie użycia systemu (z punktu widzenia użytkownika)• zwiekszenie stopnia świadomości analityków i projektantów• umożliwienie interakcji zespołu projektowego z przyszłymiużytkownikami systemu• weryfikacja poprawności i kompletności projektu• ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu• dostarczenie podstawy do sporządzenia planu testów systemu


Projektowanie mieszkania

• poruszanie się po mieszkaniu• miejsce na urządzenia, np. w kuchni• szybka droga z garażu do kuchni• odpowiednia wielkość pokoi• ....

Co bierzemy pod uwagę ?

analiza oparta na przypadkach użycia

W ten sposób kształtuje się architekturę

mieszkania

Konsultacja z

architektem (ekspertem)


Zalety zastosowania

Nie narzucają sposobu implementacji pozwalajązapomnieć o strukturze i architekturze systemu i jego detalach technicznych na etapie analizyUżytkownicy i eksperci mogą rozmawiać z projektantami i programistami bez konieczności analizowania nieistotnych szczegółówIntuicyjna reprezentacja funkcjonalna systemu, nie wprowadza komputerowego żargonuPosiadają notację graficznąJęzyk zunifikowany, znany na całym świecie


Aktor

Używa systemu na wiele sposobów (przypadków użycia)Jest sprawcą zdarzeń powodujących uruchomienie przypadków użyciaOdbiera informacje wyprodukowane przez systemJest modelem (obiektem), nie konkretną osobą –reprezentuje rolę, jaką może grać konkretny użytkownikMożna tworzyć aktorów abstrakcyjnych (nadklasy)


Notacje

1. Graficzna

2. Tekstowa


Notacja graficzna - pojęciaTo unikalna nazwa, która opisuje przypadek z punktu widzenia głównego aktora

Przypadek użycia

Reprezentuje zbiór ról odgrywanych przez użytkowików przypadku użycia.

Zwykle jest to człowiek, maszyna, inny system

Powinien mieć unikalną, jednoznaczną nazwę

Aktor


Notacja graficzna - pojęcia c.d.Pokazuje związek między przypadkiem użycia i aktorem (środowiskiem zewnętrznym)

Interakcje

Blok ponownego

użyciaPokazuje pewien fragmentdziałalności systemu, który jestużywany w kilku przypadkach użycia. (Może być także oznaczony jako samodzielny przypadek użycia).

weryfikacjaklienta


Notacja graficzna - pojęcia c.d.

Asocjacje z blokiem ponownego użycia Pokazuje związek przypadku użycia

z pewnym blokiem ponownego użycia

Nazwa systemu wraz z granicami

systemu Pokazuje granicę pomiędzy systemem i jego otoczeniem

System obsługi klienta

...system informacyjny...


Przykład diagramu PU (Siergiej)

klient banku

wpłata pieniedzy

wypłata pieniedzy

W operacjach wpłaty i wypłaty pieniędzy uczestniczą takze inni aktorzy,np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujacy

klient banku

wpłata pieniedzy

wypłata pieniedzy kasjer


Przykład diagramu PU 2

klient operator

Automatdo sprzedażypapierosów

zakup paczkipapierosów

uzupełnienietowaru

operacjepieniężne

sporządzenieraportów

kontroler


<<rozszerza>> i <<używa>>Relacje pomiędzy przypadkami użycia używa: wskazuje na wspólny

fragment wielu przypadków użycia, wyłączony “przed nawias” (w tym sensie jest “abstrakcyjny”, podobieństwo dodziedziczenia)

sprzedażsamochodu

używa

używaużywa

rozszerza

rejestracjaklienta

przeglądsamochodu

naprawasamochodu

umyciesamochodu

rozszerza

rozszerza: strzałka prowadzi odprzypadku użycia, który czasami(nie zawsze) rozszerza przypadki użycia.

rozszerza

przyholowaniesamochodu


Powiązania w modelu PU

«uses» Modeluje sytuację kiedy przypadek (przypadki) użycia wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok ponownego użycia) na zasadzie podobnej do wywołania procedury.

«extends» Modeluje sytuację kiedy rozszerzający przypadek użycia definiuje wspólne lub dobrze wyodrębnione akcje. Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w nim akcje plus niekiedy dodatkowo akcje określane przez przypadek rozszerząjący. Jest on zwykle niekompletny.

Zmiany: «uses» «import», «extends» «extend»


Zależności czasowe między PUWłaściwie nie występuje w tym modelu nacisk na uwzględnianie zależności czasowych między przypadkami użycia, tzn. nie interesuje nas wzajemna kolejność przypadków użycia (co oznacza, że mogą być konstruowane w dowolnej kolejności), ale jeśli ...

p1 p2<<używa>>

Przebieg podstawowy - p1 (przypadek bazowy, podstawowy) zawsze używa p2,a więc p1 musi być pierwsze w kolejności działania.

p1 p2<<rozszerza>>

Przebieg opcjonalny - p1 (przypadek bazowy) jest czasami rozszerzane o p2,tutaj też p1 musi być pierwsze w kolejności działania.


Przykład diagramu 3 (Bartek)

Bazadanychbanku

Klient

Administratorsystemu

Prowadzeniekonta klienta

Informowanie ostanie konta klienta

Inicjalizacjakarty klienta

Weryfikacja kartyi kodu klienta

Automat do operacji bankowych

<<używa>>

<<używa>

>

<<używa>>


Notacja tekstowa

•Przypadek użycia może być wyspecyfikowany przez opisanie ciągu zdarzeń w formie tekstu zrozumiałego nawet dla laika.

•Wymagane informacje :

•Jak i kiedy zaczyna się i kończy

•Kiedy dochodzi do interakcji z aktorami

•Jakie obiekty są przekazywane

•Główny ciąg zdarzeń


Notacja tekstowa - przykład

Przypadek użycia zaczyna się, gdy system pyta klienta o PIN. Klient może teraz wprowadzić hasło z klawiatury. Klient potwierdza wprowadzone dane za pomocą klawisza „Wykonaj”. System sprawdza poprawność PIN`u. Jeśli jest on poprawny, system informuje o tym. Na tym kończy się przypadek użycia.

Weryfikacja użytkownika

Główny ciąg zdarzeń :

Nadzwyczajny ciąg zdarzeń :

Klient może w każdej chwili anulować transakcję, naciskając klawisz „Stop”. Przypadek użycia wraca teraz do punktu początkowego. Na koncie klienta nie zachodzą żadne zmiany


Przykład c.d.

Przed potwierdzeniem PIN`u Klient może w każdej chwili wprowadzić go jeszcze raz.

Weryfikacja użytkownika



Gdy klient wprowadzi błędny PIN, przypadek użycia wraca do punktu początkowego. Gdy zdarzy się to trzy razy z rzędu, system anuluje całą transakcję i przez 60 sekund nie reaguje na żadne działania klienta.


Rozbudowa modelu PU (Siergiej)

klientbanku

wpłata pieniedzy

wypłata pieniedzy

kasjer

sprawdźbilans

weźpożyczkę zarząd

banku

klientbanku

wpłata pieniedzy

kasjerwypłata pieniedzy

używa

sprawdźbilans

weźpożyczkę zarząd

banku


Charakterystyka PUW późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich w postaci scenariuszy.

wykonanieprogramu

drukowaniepliku

programista użytkownik

używa

używa

edycjaprogramu

Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele.

kompilacjaprogramu


Opis przypadków użycia

Co powinien zawierać opis przypadku użycia?

Opis przypadku użycia może być dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty:

1) Jak i kiedy przypadek użycia zaczyna się i kończy?2) Opis interakcji przypadku użycia z aktorami,

włączając w to kiedy interakcja ma miejsce i co jest przesyłane.3) Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych

w systemie, lub jak i kiedy zapamiętuje dane w systemie?4) Wyjątki przy przepływie zdarzeń.5) Jak i kiedy używane są pojęcia dziedziny problemowej?


Dokumentacja PU

1. Krótki opis przypadku użycia

2. Przepływ zdarzeń opisany nieformalnie

3. Asocjacje pomiędzy przypadkami użycia

4. Uczestniczące obiekty

5. Specjalne wymagania

(np. czas odpowiedzi, wydajność)

6. Obrazy interfejsu użytkownika

7. Ogólny pogląd na przypadki użycia

(powiązania w postaci diagramów)

8. Diagramy interakcji dla każdego aktora


Metoda oparta na PUMetoda dotyczy analizy wymagań i opiera się na kilku krokach.Jednocześnie jest budowany obiektowy model dziedziny.Metoda jest oparta na ścisłej współpracy z przyszłym użytkownikiem.

Nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika.

Udokumentowany w:KrokSporządzenie słownika pojęć

Opis każdego przypadku użycia:* podział na nazwane części* wyspecyfikowanie w szczegółach* znalezienie wspólnych części

w różnych przypadkach użycia

Słownik pojęć

Ustalenie aktorów

Dokument opisu aktorówUstalenie przypadków użycia

Diagram przypadków użycia


Sporządzenie słownika pojęćPolega na wyłowieniu wszystkich terminów z początkowych wymagań.

Słownik dotyczy dziedziny problemowej.

Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu.

Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny.

Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, aktywności, zdarzeń, itd.

Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika:

* na rzeczowniki: mogą one oznaczać aktorów lub obiektydziedziny problemowej

* na frazy opisujące funkcje, akcje, zachowanie się: mogąone być podstawą wyróżnienia przypadków użycia.


Ustalenie aktorów

• Jaka grupa potrzebuje wspomagania ze strony systemu?• Jacy użytkownicy są konieczni do tego, aby system?•Funkcje należy rozbić na odnoszące się do

- dziedziny przedmiotowej (np. osoba rejestrująca) i - wspomagania systemu (np. administrator systemu)

• Z jakiego sprzętu zewnętrznego (komputerów, sieci, itp.)musi korzystać system aby realizować swoje funkcje.

Wyszukanie potencjalnych aktorów musi być powiązane z ustaleniem granic systemu, tj. odrzucenia obszarów dziedziny problemowej, którymi system nie zajmuje się.


Ustalenie aktorów c.d.Po wyszukaniu aktorów, należy ustalić:- czy jest to aktor konkretny (Jan Kowalski),

czy też określenie roli (magazynier)

- nazwę dla każdego aktora/roli

- zakresy znaczeniowe dla poszczególnych nazw aktorów

oraz relacje pomiędzy zakresami (sekretarka → pracownik administracji → pracownik → dowolna osoba).

Niekiedy warto ustalić hierarchię dziedziczenia dla aktorów.

- opisać relacje pomiędzy konkretnymi użytkownikami i aktorami

- czy użytkownik może łączyć funkcje kilku aktorów i jakich


Analiza aktorów

• Jakie jest główne zadanie dla każdego aktora?• Czy aktor będzie czytał/pisał/zmieniał informację w systemie?• Czy aktor ma informować system o zmianach na zewnątrz?

Użytkownik Aktor Przypadek użyciaJest związany z:Może grać rolę

Jan Kowalski

Adam Malina

Administrator systemu

Pracownik

Przeładowanie systemu

Wejście z kartą i kodem

Informacja ogólnaOsoba informowana Gość

Wypłata z kontaKonkretny klient Klient


Ustalenie przypadków użyciaDla każdego aktora, znajdź zadania i funkcje, które powinien wykonywać w

związku z jego działalnością w zakresie dziedziny przedmiotowej jak i systemu informacyjnego.

Staraj się powiązać w jeden przypadek użycia zespół funkcji i zadań wspólnie realizujących ten sam cel. Unikaj rozbicia jednego przypadku użycia na wiele pod-przypadków, o ile każdy z nich realizuje cel cząstkowy, który musi być uzupełniony przez inne funkcje lub zadania.

Nazwy dla przypadków użycia: powinny być krótkie ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. “wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.

Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika.

Uporządkuj aktorów i przypadki użycia w postaci diagramu. Niektóre z powstałych w ten sposób przypadków użycia mogą być

mutacjami lub szczególnymi przypadkami innych przypadków użycia. Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z nich są zbędne lub mogą być uogólnione.


Specyfikacja każdego PUWyodrębnij “przypadki bazowe”, tj. takie, które stanowią istotę zadania lub

funkcji, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne.

Nazwij te “przypadki bazowe”; nazwy powinny być proste i zrozumiałe. Ustal wzajemne powiązanie “przypadków bazowych”, poprzez ustalenie ich sekwencji, alternatywy, zależności, związku przyczyna-skutek, itd.

Dodaj zachowanie skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie “przypadków bazowych” z tego rodzaju zachowaniem. Może ono byctakże powiązane w pewną strukturę.

Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku użycia nie były zbyt ogólne lub zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków wielokrotnego użycia.

Struktura nie może być zbyt duża i złożona. Staraj się wyizolować bloki wielokrotnego użycia. Przeanalizuj podobieństwo

nazw przypadków użycia, podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. Wydzielenie bloku wielokrotnego użycia może być powiązane z określeniem nieco bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.

use cases - przypadki u¿ycia

Documents