Projektowanie systemów informacyjnych

Projektowanie systemów informacyjnych Wykład 12: Przypadki użycia (use cases) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Po co są przypadki użycia? Podstawowym problemem w inżynierii oprogramowania jest określenie wymagańna projektowany system. Podejście przypadków użycia ma przede wszystkim na względzie ten problem. Celem metody opartej na przypadkach użycia jest: * głębsze zrozumienie użycia systemu bedącego przedmiotem procesu projektowania * zwiekszenie stopnia świadomości analityków i projektantów co do celów tego systemu * umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu * weryfikacja poprawności i kompletności projektu * odzyskanie wszystkich strukturalnych i funkcjonalnych własności systemu * ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu * dostarczenie podstawy do sporządzenia planu testów systemu Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy.

Przypadki użycia w analizie Eksperci Doświadczenie w dziedzinie przedmiotowej Potrzeby Model dziedziny Kompletny model analizy Koncepcja zastosowania Pomysły Przypadki użycia Model zastosowania Technologie Użytkownicy mocny wpływ słaby wpływ

Aktorzy Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z projektowanym systemem. Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem. I odwrotnie, jeden aktor może odpowiadać wielu osobom, np. strażnik budynku. Każdy aktor używa (będzie używać) systemu na kilka specyficznych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia. W tej metodzie aktor jest pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą informacji wyprodukowanych przez przypadki użycia.

Przykłady przypadków użycia wpłata pieniedzy wypłata pieniedzy klient banku Oczywiście, w operacjach wpłaty i wypłaty pieniędzy uczestniczą takze inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujacy nasz model. wpłata pieniedzy kasjer wypłata pieniedzy klient banku

Rozbudowa modelu przypadków użycia wpłata pieniedzy wpłata pieniedzy kasjer kasjer wypłata pieniedzy wypłata pieniedzy używa sprawdź bilans sprawdź bilans klient banku klient banku weź pożyczkę weź pożyczkę zarząd banku zarząd banku Model przypadków użycia można rozbudowywać poprzez dodanie nowych aktorów, nowych przypadków użycia oraz nowych powiązań pomiędzy przypadkami użycia.

Charakterystyka przypadków użycia Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza jakichkolwiek szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Podstawowym ich zastosowaniem jest dialog z użytkownikami zmierzajacy do sformułowania wymagań na system. W 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. edycja programu Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele. kompilacja programu używa używa wykonanie programu programista użytkownik drukowanie pliku

Projektowanie sterowane przypadkami użycia Model przypadków użycia: wyrażony w terminach zrealizowany poprzez przetestowany w zaimplementowany poprzez zestrukturalizowany poprzez OK klasa... OK wady Model obiektowy dziedziny Model analizy Model projektu Model implementacji Model testowania

Modele wg Jacobsona Model przypadków użycia: definiuje zewnętrze (aktorów) oraz wewnętrze (przypadki użycia), które określają zachowanie się systemu. Obiektowy model dziedziny, odwzorowujący obiekty świata rzeczywistego Obiektowy model analityczny opisujący dokładną strukturę istniejącego systemu Obiektowy model projektowy opisujący założenia przyszłej implementacji Model implementacyjny reprezentujący konkretną implementację systemu (klasy) Model testowania, okreslający plan testów, specyfikacji i raportów • Modele wymagają odpowiednich procesów ich tworzenia: • Analiza wymagań, składająca się z dwóch podprocesów • - proces modelowania przypadków użycia • - proces modelowania obiektów dzedziny • Proces analizy związany z obiektowym modelem analitycznym • Proces projektowania • Proces implementacji • Proces testowania

Model wymagań Składowe: • Model przypadków użycia • Opis interfejsów • Model dziedziny problemowej Model przypadków użycia wprowadza następujące pojęcia i notacje: Aktor Przypadek użycia Reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient) Reprezentuje sekwencję operacji lub transakcji wykonywanych w dialogu z systemem; (np. potwierdzenie pisma, zlożenie zamówienia) Przypadki użycia reprezentują przepływ zdarzeń w systemie. Są one uruchamiane (inicjowane) przez aktorów. Aktorem jest dowolny byt zewnetrzny, który uczestniczy w interakcji z przypadkiem użycia. Kilku fizycznych użytkowników może pełnić rolę jednego aktora i wice-versa. Można tworzyć aktorów abstrakcyjnych, na podobieństwo klas abstrakcyjnych.

Oznaczenia w metodzie przypadków użycia Klient wypłata pieniędzy Przypadek użycia. Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego głównego aktora. Aktor. Powinien mieć unikalną, logiczną nazwę Interakcja. Pokazuje interakcję pomiędzy przypadkiem użycia i aktorem (środowiskiem zewnętrznym). Blok ponownego użycia. Pokazuje pewien fragment działalności systemu, który jest używany w kilku przypadkach użycia. (Może być także oznaczony jako samodzielny przypadek użycia.) weryfikacja klienta Asocjacja z blokiem ponownego użycia. Pokazuje związek przypadku użycia z pewnym blokiem ponownego użycia. System obsługi klienta Nazwa systemu wraz z granicami systemu. Pokazuje granicę pomiędzy systemem i jego otoczeniem. ...system informacyjny...

Przykład modelu przypadków użycia Baza danych banku Klient Administrator systemu Automat do operacji bankowych Prowadzenie konta klienta Informowanie o stanie konta klienta Weryfikacja karty i kodu klienta Inicjalizacja karty klienta

Inny model przypadków uzycia Automat do papierosów uzupełnienie towaru operacje pieniężne zakup paczki papierosów sporządzenie raportów Operator Klient Kontroler

Opis przypadków użycia 1. Nieformalny tekst bez pokazania przepływu zdarzeń 2. Tekst, łatwy do czytania, z jasno zaznaczonym przepływem zdarzeń 3. Styl formalny z użyciem pseudo-kodu Co powinien zawierać opis przypadku użycia? 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 zapamietanych w systemie, lub jak i kiedy zapamiętuje dane w systemie? 4. Wyjatki przy przepływie zdarzeń. 5. Jak i kiedy używane są pojęcia dziedziny problemowej? Powiązania pomiędzy przypadkami użycia dodanie dodatkowego przepływu do istniejącego przypadku użycia użycie wspólnego zachowania w różnych przypadkach użycia rozszerza używa

Powiązania rozszerza i używa sprzedaż samochodu używa rejestracja klienta używa używa: wskazuje na wspólny fragment wielu przypadków użycia, wyłączony “przed nawias” (w tym sensie jest “abstrakcyjny”, podobieństwo do dziedziczenia) używa przegląd samochodu naprawa samochodu rozszerza rozszerza rozszerza rozszerza: strzałka prowadzi od przypadku użycia, który czasami (nie zawsze) rozszerza przypadki użycia. umycie samochodu przyholowanie samochodu

Przypadek użycia w postaci diagramu interakcji Przesyłanie zdarzeń pomiędzy blokami: Aktor Blok 1 Blok 2 Blok 3 Blok 4 s1 s2 czas s3 a3 a2 s4 a1 a4 s5 a5 Blok: obiekt + pewna akcja podejmowana przez system si - zdarzenia

Przykład diagramu interakcji Wypełnij formularz wpłaty Podaj formularz i gotówkę do kasy Zwiększ konto klienta Zwiększ bilans kasy Zwiększ bilans banku Wydaj pokwitowanie dla klienta wpłata pieniędzy kasa konto bank formularz Klient wypełnij podaj zwiększ zwiększ bilans zwiększ bilans wydaj pokwitowanie

Dokumentacja przypadków użycia 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 Prace niezbędne do skonstruowania przypadków użycia 1. Wyszczególnienie pojęć 2. Szkicowy opis przepływu zdarzeń 3. Zdefiniowanie sposobu interakcji aktora z przypadkiem użycia 4. Ustanowienie związków rozszerza 5. Ustanowienie zwiazków używa 6. Sporządzenie diagramu przypadków użycia, aktorów i związków 7. Przedyskutowanie i krytyka modelu 8. Sprawdzenie kompletności modelu

Metoda oparta na przypadkach użycia Metoda 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. To założenie implikuje zasadę: Nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika. Krok Udokumentowany w: Sporządzenie słownika pojęć Słownik pojęć Ustalenie aktorów Dokument opisu aktorów Ustalenie przypadków użycia 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 Diagram przypadków użycia

Sporzadzenie 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 obiekty dziedziny problemowej * na frazy opisujące funkcje, akcje, zachowanie się: mogą one być podstawą wyróżnienia przypadków użycia.

Ustalenie aktorów Przy wyszukiwaniu aktorów ze sformułowania wymagań istotne są odpowiedzi na następujące pytania: • Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu? • Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje? • Należy te funkcje rozbić na funkcje odnoszące się do • - dziedziny przedmiotowej (np. osoba rejestrująca korespondencję) i do • - wspomagania systemu (np. administrator systemu) • Z jakiego sprzętu zewnętrznego (komputerów, czujnikó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 będzie się zajmować. 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 (np. 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 (minimalizacja aktorów)

Analiza aktorów • Jakie jest główne zadanie dla każdego aktora? • Czy aktor będzie czytał/pisał/zmieniał jakąkolwiek informację w systemie? • Czy aktor ma informować system o zmianach na zewnątrz? • Czy aktor życzy sobie, aby być poinformowany o nieoczekiwanych zmianach? Wyjaśnienie różnic pomiedzy konkretnymi użytkownikami i aktorami Przypadek użycia Użytkownik Aktor Jest związany z: Może grać rolę Przeładowanie systemu Jan Kowalski Administrator systemu Wejście z kartą i kodem Adam Malina Pracownik Informacja ogólna Gość Osoba informowana Wypłata z konta Konkretny klient Klient

Ustalenie przypadków użycia Dla każdego aktora, znajdź zadania i funkcje, które powinien wykonywać w zwiazku 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 byc 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 przypadku użycia Wyodrę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 byc takż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.

Projektowanie systemów informacyjnych