Wstęp do systemów informatycznych Model przypadków użycia

Agenda  Po co projektujemy oprogramowanie?  UML – wprowadzenie  Definicje  Diagramy przypadków użycia  Budowa modelu przypadków użycia  Dokumentacja przypadków użycia

Po co projektujemy oprogramowanie?  Oprogramowanie to efekt procesu inżynierii  Inżynierowie projektują rzeczy  Złożone systemy trudne do zrozumienia  Komunikacja w zespole  Znalezienie sposobu na uproszczenie systemu

UML  Język modelowania (notacja)  Międzynarodowy standard (ISO/IEC 19501:2005)  Wykorzystywany przez różne metodyki wytwarzania oprogramowania

UML  Przedstawia różne aspekty tworzonego systemu w formie graficznej  wymagania funkcjonalne  zachowanie  strukturę

UML  Często krytykowany  zbyt rozbudowany  trudny do nauczenia  próbuje osiągnąć zbyt wiele rzeczy  programiści nie lubią dokumentowania  Ale  jest standardem w dużych firmach  które oczekują jego znajomości

Modele systemu wg. Jacobsona  Model przypadków użycia  Obiektowy model dziedziny  Obiektowy model analityczny  Model projektowy (logiczny)  Model implementacyjny (fizyczny)  Model testowania

Model dziedzinowy i analityczny  Musimy zrozumieć otoczenie systemu  Nie zawsze mamy dość czasu i środków na wszystko Zakres odpowiedzialności systemu Model analityczny Dziedzina problemu

Model przypadków użycia  Definiuje  kontekst systemu (aktorów i systemy zewnętrzne)  system  Określa zachowanie systemu w odpowiedzi na wejście pochodzące spoza niego  Dwa podstawowe elementy  Aktor  Przypadek użycia

Przypadek użycia  Funkcja systemu  Używana przez aktora  Może być powiązana z innymi funkcjami

Aktor  Modeluje grupę osób grających określoną rolę  Osoba może wchodzić w interakcje z systemem w wielu rolach – być więcej niż jednym aktorem  Aktor może reprezentować więcej niż jedną osobę

Aktor vs Użytkownik Konkretny użytkownik AktorPrzypadek użycia Może grać rolę zleca Jan Kowalski Adam Malina Konkretny gość Konkretny klient Administrator systemu Pracownik Osoba informowana Klient Przeładowanie systemu Wejście z kartą i kodem Uzyskanie informacji ogólnych Wypłata z konta

Kto (co) może być Aktorem?  Czy system może być aktorem?  w kontekście innego systemu  w swoim kontekście  Czy osoba nie używająca systemu bezpośrednio może być aktorem?  Czy osoba otrzymująca tylko wyjście z systemu może być aktorem?

Diagramy przypadków użycia - notacja Aktor: Powinien mieć unikatową nazwę. Interakcja: Ilustruje związek zachodzący pomiędzy przypadkiem użycia (systemem) a aktorem. Klient Przypadek użycia. Unikatowa nazwa Wypłata pieniędzy

Diagramy przypadków użycia - notacja Nazwa diagramu wraz z nagłówkiem i ramą: ud (ang. use case diagram) – wyróżnik diagramu. ud Obsługa klienta «include» Relacja typu « include » lub « extend »

Stereotypy aktorów Aktor: system zewnętrzny System ubezpieczeń Aktor: czas 1-szy dzień roku Klient «actor» Klient Aktor: człowiek, grupa ludzi, organizacja Klient

Przykład diagramu przypadków użycia (1) Wpłata pieniędzy Wypłata pieniędzy Klient

Przykład diagramu przypadków użycia (2) Klient Kasjer Wpłata pieniędzy Wypłata pieniędzy alternatywna notacja dla przypadków użycia

Przykład diagramu przypadków użycia (3) ud Automat do sprzedaży papierosów Zakup paczki papierosów Uzupełnienie towaru Wykonanie operacji pieniężnej Sporządzenie raportu Klient Operator Kontroler

Relacje między przypadkami użycia (1)  Include – P1 zawsze używa P2  Extend – P1 jest czasami rozszerzane o P2 P1 P2 « include » P1 P2 « extend »

Relacje między przypadkami użycia (2) Naprawa samochodu Przegląd samochodu Sprzedaż samochodu Rejestracja klienta « include » Umycie samochodu « extend » Przyholowanie samochodu « extend »

Relacje między przypadkami użycia (3) Punkty rozszerzające (extension points) Umożliwiają podanie warunków wymaganych do użycia przypadków rozszerzających („opcjonalnych”). Umycie samochodu « extend » Przyholowanie samochodu « extend » Naprawa samochodu extension points: Samochód poza warsztatem Samochód wymaga przeglądu Przegląd samochodu extension points: Samochód jest brudny extension point: Samochód wymaga przeglądu extension point: Samochód jest brudny extension point: Samochód poza warsztatem

Relacje między przypadkami użycia (3) Klient Dostawca Złożenie zamówienia Realizacja zamówienia « extend » Uwaga: Zabronione jest łączenie relacją «include» (czy «extend») przypadków użycia występujących w różnych przebiegach systemu, jak np. na poniższym diagramie. Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu.

Związek uogólnienia między aktorami (1) Osoba Gość Pracownik Księgowa Pracownik administracji

Związek uogólnienia między aktorami (2) Obsługa konta klienta Informowanie o stanie konta klienta Inicjalizacja karty klienta Weryfikacja karty i kodu klienta ud Automat do operacji bankowych « include » Podsystem zarządzania bazą danych banku Klient Administrator systemu

Związek uogólnienia między aktorami (2) Obsługa konta klienta Informowanie o stanie konta klienta Inicjalizacja karty klienta Weryfikacja karty i kodu klienta ud Automat do operacji bankowych « include » Podsystem zarządzania bazą danych banku Klient Administrator systemu

Stopień szczegółowości diagramów  Zbyt szczegółowy diagram  trudna analiza  niewielka czytelność  Zbyt ogólny diagram  mało informacji

Diagram kontekstowy Podsystem zarządzania bazą danych banku Klient Administrator systemu «system» Automat do operacji bankowych

Kolejne kroki w konstrukcji modelu Krok: Udokumentowany w: Sporządzenie słownika pojęć Słownik pojęć Określenie aktorów Określenie przypadków użycia Tworzenie opisu każdego przypadku użycia plus:  podział na nazwane części  znalezienie wspólnych części w różnych przypadkach użycia Dokument opisu aktorów Diagram przypadków użycia + dokument z opisem przypadków użycia

Dokumentacja przypadku Wypożycz kasetę (1) NazwaWypożycz kasetę Nr id7 AutorJan Kowalski - analityk PriorytetWysoki TypOgólny AktorzyPracownik wypożyczalni OpisPrzypadek dotyczy rejestracji wypożyczenia kaset; kasety przeznaczone dla dorosłych można wypożyczać od 18-tego roku życia; jednocześnie można mieć wypożyczonych co najwyżej 5 kaset; nie wolno wypożyczać osobie, która aktualnie znajduje się w okresie karencji Warunek początkowyOsoba wypożyczająca powinna być zarejestrowana jako klient wypożyczalni Warunek końcowyO ile warunki wypożyczenia zostały zrealizowane, to powinny zostać zarejestrowane następujące informacje o wypożyczeniu kasety : kto wypożyczył, co wypożyczył i kiedy wypożyczył

Dokumentacja przypadku Wypożycz kasetę (2) Główny przepływ zdarzeń1.Pracownik wypożyczalni uruchamia przypadek Wypożycz kasetę. 2.System odpytuje o nazwisko i imię osoby wypożycząjącej. Pracownik wprowadza odpowiednie informacje. 3.System odpytuje o tytuł filmu. Pracownik wprowadza tytuł. 4.System rejestruje wypożyczenie kasety z filmem (kto, co, data wypożyczenia). Alternatywne przepływy zdarzeń 2a O ile osoba wypożyczająca nie jest zarejestrowana w systemie, system informuje o tym aktora i kończy przypadek użycia 2b. O ile jest zarejestrowana więcej niż jedna osoba o tym samym nazwisku i imieniu, system wyświetla okno z listą osób. Pracownik wybiera odpowiednią osobę z listy. 3a O ile aktualnie nie ma filmu o tym tytule w zasobach wypożyczalni, lub wszystkie kasety z filmem są wypożyczone, system informuje o tym aktora i kończy przypadek. 3b O ile film jest przeznaczony dla osób dorosłych a osoba wypożyczająca nie ukończyła 18-tu lat, system informuje o tym aktora i kończy przypadek.

Dokumentacja przypadku Wypożycz kasetę (3) Alternatywne przepływy zdarzeń, cd. 3c Jeśli osoba wypożyczająca ma już aktualnie co najmniej pięć wypożyczonych kaset na koncie, system informuje o tym aktora i kończy przypadek. 3d Jeśli osoba wypożyczająca znajduje się aktualnie w okresie karencyjnym, system informuje o tym aktora i kończy przypadek. Wymagania niefunkcjonalneBrak Uwagi dodatkoweBrak