Projektowanie systemów informacyjnych Wykład 1 Zadania inżynierii oprogramowania Analiza wymagań Model use cases (przypadków użycia) Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Podstawowe pojęcia Dziedzina problemowa (dziedzina przedmiotowa) Cel Zakres odpowiedzialności systemu Kontekst (systemy zewnętrzne, interjfejsy, aktorzy) Wymagania wstępne (wymagania użytkownika) Wymagania na system Wymagania funkcjonalne Wymagania niefunkcjonalne Ewolucja systemu

Co to znaczy jakość oprogramowania Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania (tzn., czy spełnia wyspecyfikowane wymagania) i czy jest wolne od błędów. Łatwość użycia jest miarą stopnia łatwości korzystania z oprogramowania. Czytelność pozwala na określenie wysiłku niezbędnego do zrozumienia oprogramowania. Ponowne użycie (inne terminy to: wielokrotne użycie lub wielo-użycie) charakteryzuje przydatność oprogramowania, całego lub tylko pewnych fragmentów, do wykorzystania w innych produktach programistycznych. Stopień strukturalizacji (modularność) określa, jak łatwo oprogramowanie daje się podzielić na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji. Efektywność opisuje stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania. Przenaszalność mówi o łatwości przenoszenia oprogramowania na inne platformy sprzętowe czy programowe. Skalowalność opisuje zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników do systemu, itp. Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem.

Fazy cyklu życiowego w procesie konstrukcji produktu programistycznego Faza strategiczna Faza specyfikacji i analizy wymagań Faza projektowania Faza konstrukcji (implementacji) Faza testowania Faza konserwacji czas

Modele wg Jacobsona Model przypadków użycia: definiuje zewnętrze (aktorów, systemy zewnętrzne, kontekst) oraz wnętrze (przypadki użycia), określające zachowanie się systemu. Obiektowy model dziedziny odwzorowujący obiekty świata rzeczywistego, tzw. dziedziny problemowej 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 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 dziedziny problemowej Proces analizy związany z obiektowym modelem analitycznym Proces projektowania Proces implementacji Proces testowania

Model wymagań Model przypadków użycia Opis interfejsów Składowe: Model przypadków użycia Opis interfejsów Obiektowy model dziedziny problemowej Model przypadków użycia wprowadza następujące pojęcia: nazwa przypadku (tu) Przypadek użycia Aktor nazwa przypadku (lub tutaj) nazwa aktora Reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient) Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego (zainicjowanego) przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Przypadki użycia reprezentują przepływ operacji w systemie. Są one uruchamiane (inicjowane) przez aktorów. Aktorem jest dowolny byt zewnętrzny, 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 stosować struktury generalizacji-specjalizacji dla aktorów. Każdy potencjalny aktor używa (może używać) system na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia.

Notacja w modelu przypadków użycia wypłata pieniędzy Przypadek użycia. Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Lepiej jest stosować nazwę opisującą czynność (sekwencja operacji) niż polecenie. Aktor. Powinien mieć unikalną nazwę. klient Interakcja. Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem. Blok ponownego użycia. Pokazuje pewien fragment systemu, który jest używany w kilku przypadkach użycia. (Może być także oznaczony jako samodzielny przypadek użycia.) weryfikacja klienta <<używa>> Relacja typu <<używa>> lub <<rozszerza>>. Pokazuje związek zachodzący między dwoma przypadkami użycia (<<używa>> lub rozszerza>>) lub przypadkiem użycia a blokiem ponownego użycia (<<używa>>). System obsługi klienta ...system informacyjny... Nazwa systemu wraz z granicami systemu. Pokazuje granicę pomiędzy systemem i jego otoczeniem.

Aktor Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z wykorzystywaniem projektowanego systemem (“przyszli użytkownicy, ale nie tylko”). 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. Czy system może być aktorem sam dla siebie ? Aktor jest tu 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. Sprawca zdarzeń?

Przykład diagramu przypadków użycia wpłata pieniędzy wypłata pieniędzy klient banku Oczywiście, w operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć także inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujący nasz model. wpłata pieniędzy wypłata pieniędzy kasjer klient banku

Przykład diagramu przypadków użycia Automat do sprzedaży papierosów uzupełnienie towaru zakup paczki papierosów operacje pieniężne sporządzenie raportów klient operator kontroler

Relacje: << rozszerza>> i <<używa>> używa: wskazuje na wspólny fragment wielu przypadków użycia, wyłączony “przed nawias” - wykorzystywane w przebiegach podstawowych (funkcje zawsze wykonywane) sprzedaż samochodu rejestracja klienta używa używa używa przegląd samochodu naprawa samochodu rozszerza rozszerza: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (funkcje nie zawsze wykonywane) rozszerza rozszerza umycie samochodu przyholowanie samochodu

Przykład wykorzystania relacji <<używa>> Automat do operacji bankowych prowadzenie konta klienta podsystem zarządzania bazą danych banku <<używa>> klient informowanie o stanie konta klienta <<używa>> weryfikacja karty i kodu klienta <<używa>> inicjalizacja karty klienta administrator systemu

Rozbudowa modelu przypadków użycia wpłata pieniędzy wpłata pieniędzy kasjer wypłata pieniędzy kasjer <<używa>> wypłata pieniędzy <<używa>> uaktualnianie stanu konta <<używa>> sprawdź bilans sprawdź stan konta 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 dodawanie nowych aktorów, przypadków użycia czy relacji pomiędzy przypadkami użycia.

Charakterystyka modelu przypadków użycia Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system. Spojrzenia z pozycji aktorów, którzy go używają. Nie włącza zbyt wielu szczegółów, co pozwala wnioskować o fukcjonalności systemu (zbiorze funkcji, które obsługuje) na odpowiednio wysokim, abstrakcyjnym poziomie. Podstawowym zastosowaniem jest tu bowiem dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system. Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie pozwala na wykrycie bloków ponownego użycia. 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

Zależności czasowe między przypadkami użycia Wł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, podstawowy) jest czasami rozszerzane o p2, tutaj też p1 musi być pierwsze w kolejności działania.

Przypadek użycia w postaci diagramu interakcji Przesyłanie komunikatów pomiędzy blokami: Aktor Blok 1 Blok 2 Blok 3 Blok 4 k1 czas k2 k3 k4 k5 Blok: obiekt ki - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji

Przykład diagramu interakcji scenariusz 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 klient formularz kasa konto bank wypełnij podaj zwiększ zwiększ bilans zwiększ bilans wydaj pokwitowanie

Dokumentacja przypadków użycia Dokumentacja przypadków użycia powinna zawierać: 1. Diagramy przypadków użycia (aktorzy, przypadki użycia i relacje zachodzące między przypadkami) 2. Krótki, ogólny opis każdego przypadku użycia: - jak i kiedy przypadek użycia zaczyna się i kończy - opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. - kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie - wyjatki występujące przy obsłudze przypadku - specjalne wymagania, np. czas odpowiedzi, wydajność - jak i kiedy używane są pojęcia dziedziny problemowej 3. Opis szczegółowy każdego przypadku użycia - scenariusz - uczestniczące obiekty - diagram interakcji

Opis przypadków użycia (cd.) Opis przypadków użycia może być w postaci: 1. Nieformalnego tekstu bez pokazywania przepływu operacji 2. Tekst nieformalny, łatwy do czytania, z jasno zaznaczonym przepływem operacji 3. Styl formalny z użyciem pseudo-kodu Prace niezbędne do skonstruowania modelu przypadków użycia 1. Wyszczególnienie pojęć (związanych z aktorami i przypadkami użycia) 2. Zdefiniowanie interakcji aktorów z przypadkami użycia 3. Ustanowienie zwiazków <<używa>> 4. Ustanowienie związków <<rozszerza>> 5. Szkicowy opis przepływu operacji (utworzenie scenariuszy) 6. Skonstruowanie diagramów interakcji 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. Metoda jest oparta na ścisłej współpracy z przyszłym użytkownikiem. Jednocześnie jest budowany obiektowy model dziedziny. Ścisła współpraca z przyszłym użytkownikiem 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 plus: * podział na nazwane części * znalezienie wspólnych części w różnych przypadkach użycia Diagram przypadków użycia

Sporządzanie słownika pojęć Słownik dotyczy dziedziny problemowej. Tworzenie go polega na wyłowieniu wszystkich terminów z początkowych wymagań (wymagań wstępnych, wymagań użytkownika). Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itd. Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu. 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.

Ustalanie aktorów Przy ustalaniu aktorów 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ę, - wspomagania systemu, np. administrator systemu Z jakiego elementów zewnętrznych (innych systemów, komputerów, czujników, sieci, itp.) musi korzystać system aby realizować swoje funkcje. Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu, tj. odrzucaniem obszarów dziedziny problemowej, którymi system nie będzie się zajmować (zakres odpowiedzialności systemu). 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. czy użytkownik może łączyć funkcje kilku aktorów i jakich (minimalizacja aktorów)

Struktury generalizacji-specjalizacji dla aktorów (dziedziczenie) osoba pracownik gość pracownik administracji Pracownik administracji ma nie tylko uprawnienia na dostęp do funkcji (przypadków użycia) właściwych dla każdego pracownika, ale posiada też dostęp do funkcji związanych z jego własnym, specyficznym sposobem wykorzystywania systemu.

Administrator systemu 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życia Jest związany z: Może grać rolę Jan Kowalski Administrator systemu Przeładowanie systemu Wejście z kartą i kodem Adam Malina Pracownik Uzyskanie informacji ogólnych Gość Osoba informowana Konkretny klient Klient Wypłata z konta

Ustalenie przypadków użycia Dla każdego aktora, znajdź funkcje (zadania), które powinien wykonywać w zwiazku z jego działalnością w zakresie zarówno dziedziny przedmiotowej, jak i wspomagania działalności systemu informacyjnego. Staraj się powiązać w jeden przypadek użycia zespół funkcji wspólnie realizujących ten sam cel. Unikaj rozbicia jednego przypadku użycia na zbyt wiele pod-przypadków, 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, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne. Nazwij te “przypadki bazowe”. 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 bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.

Dlaczego wzrasta znaczenie modelu przypadków użycia? Główne zadanie modelu przypadków użycia to prawidłowe określenie wymagań na projektowany system. Prawidłowe określenie wymagań na system uznawane jest za jeden z podstawowych problemów w procesie konstrukcji. Model przypadków użycia pozwala na: lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), co oznacza zwiększenie stopnia świadomości analityków i projektantów co do celów, czyli innymi słowy - funkcjonalności - tego systemu, ustalenie praw dostępu do zasobów, umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu, weryfikacja poprawności i kompletności projektu, zrozumienie strukturalnych 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 odwzorowywują 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