Projektowanie systemów informacyjnych

K.Subieta. Projektowanie systemów informacyjnych, Wykład 12, Folia 1

Projektowanie systemów informacyjnych

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 12: Przypadki użycia (use cases)


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.

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

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 w analizie

Potrzeby

Pomysły

Technologie

Koncepcjazastosowania

Eksperci

Użytkownicy

Doświadczeniew dziedzinie

przedmiotowej

Przypadkiużycia

Modeldziedziny

Modelzastosowania

Kompletnymodelanalizy

mocny wpływsł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

klient banku

wpłata pieniedzy

wypłata pieniedzy

klient banku

wpłata pieniedzy

wypłata pieniedzy

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.

kasjer


Rozbudowa modelu przypadków użycia

klientbanku

wpłata pieniedzy

wypłata pieniedzy

kasjer

sprawdźbilans

weźpożyczkę zarząd

banku

klientbanku

wpłata pieniedzy

wypłata pieniedzy

kasjer

sprawdźbilans

weźpożyczkę zarząd

banku

używa

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życiaModel 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.

edycjaprogramu

kompilacjaprogramu

wykonanieprogramu

drukowaniepliku

programista użytkownik

używa

używa

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


Projektowanie sterowane przypadkami użyciaModel przypadków użycia:

Model obiektowydziedziny

Modelanalizy

Modelprojektu

Modelimplementacji

Modeltestowania

klasa... OK

OK

wady

wyrażonyw terminach

zestrukturalizowanypoprzez

zrealizowanypoprzez

zaimplementowanypoprzez

przetestowany w


Modele wg JacobsonaModel 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ń• Model przypadków użycia• Opis interfejsów• Model dziedziny problemowej

Składowe:

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 transakcjiwykonywanych 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życiaPrzypadek użycia. Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego głównego aktora.

KlientAktor. Powinien mieć unikalną, logiczną nazwę

Interakcja. Pokazuje interakcję pomiędzy przypadkiem użycia i aktorem (środowiskiem zewnętrznym).

weryfikacjaklienta

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.)

wypłata pieniędzy

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

Bazadanychbanku

Klient

Administratorsystemu

Prowadzeniekonta klienta

Informowanie o stanie konta klienta

Inicjalizacjakarty klienta

Weryfikacja kartyi kodu klienta

Automat do operacji bankowych


Inny model przypadków uzycia

Klient Operator

Automatdo papierosów

zakup paczkipapierosów

uzupełnienietowaru

operacjepieniężne

sporządzenieraportów

Kontroler


Opis przypadków użycia1. 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

naprawasamochodu

przeglądsamochodu

sprzedażsamochodu

rejestracjaklienta

używa

używa używa

umyciesamochodu

rozszerza

przyholowaniesamochodu

rozszerza

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)

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

rozszerza


Przypadek użycia w postaci diagramu interakcji

Przesyłanie zdarzeń pomiędzy blokami:

s1

s2s3

s4

s5

a1

a2 a3

a4

a5

Blok 1 Blok 2 Blok 3 Blok 4

Blok: obiekt + pewna akcja podejmowana przez systemsi - zdarzenia

czas

Aktor


Przykład diagramu interakcji

wpłata pieniędzy

Wypełnij formularz wpłatyPodaj formularz i gotówkę do kasyZwiększ konto klientaZwiększ bilans kasyZwiększ bilans bankuWydaj pokwitowanie dla klienta

formularz kasa konto bank

wypełnij

podaj

zwiększ

zwiększbilans

zwiększbilans

wydajpokwitowanie

Klient


Dokumentacja przypadków użycia1. Krótki opis przypadku użycia2. Przepływ zdarzeń opisany nieformalnie3. Asocjacje pomiędzy przypadkami użycia4. Uczestniczące obiekty5. Specjalne wymagania (np. czas odpowiedzi, wydajność)6. Obrazy interfejsu użytkownika7. 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życia4. Ustanowienie związków rozszerza5. Ustanowienie zwiazków używa6. Sporządzenie diagramu przypadków użycia, aktorów i związków7. Przedyskutowanie i krytyka modelu8. Sprawdzenie kompletności modelu


Metoda oparta na przypadkach użyciaMetoda 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.

To założenie implikuje zasadę:

Krok Udokumentowany w:

Sporządzenie słownika pojęćSłownik pojęć

Ustalenie 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

Dokument opisu aktorów

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ówPrzy 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

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

Jan Kowalski

Adam Malina

Gość

Konkretny klient

Administrator systemu

Pracownik

Osoba informowana

Klient

Przeładowanie systemu

Wejście z kartą i kodem

Informacja ogólna

Wypłata z konta


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życiaWyodrę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.

Documents

Projektowanie systemów informacyjnych