Projektowanie systemw informacyjnych Wykad 1 Pojcia wstpne Model

Projektowanie systemów informacyjnych Wykład 1 Pojęcia wstępne Model przypadków użycia Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1

Zalecana literatura ü E. Stemposz, K. SUBIETA: Slajdy do wykładu “Projektowanie systemów informacyjnych” ü J. Płodzień, E. Stemposz: Analiza i projektowanie systemów informatycznych, wydawnictwo PJWSTK, 2003 i wydanie II-gie rozszerzone 2005 ü M. Śmiałek: Zrozumieć UML 2. 0 Metody modelowania obiektowego, Helion, 2005 ü S. Wrycza, B. Marcinkowski, K. Wyrzykowski: Język UML 2. 0 w modelowaniu systemów informatycznych, Helion 2005 ü OMG Unified Modeling Language. Specification, Version 1. 5, Version 2. 0, The Object Management Group, 2003, http: //www. omg. org üM. Fowler, K. Scott: UML Distilled, Addison-Wesley 1997 ü J. Rumbaugh, I. Jacobson, G. Booch: The Unified Modeling Language Reference Manual, Addison-Wesley, 1999 ü T. Quatrani: Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000 ü K. SUBIETA: Obiektowość w projektowaniu i bazach danych, Akademicka Oficyna Wydawnicza PLJ, 1998 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 2

Zagadnienia Prezentowanie diagramów Stereotypy; komentarze Klasyfikatory; wystąpienia klasyfikatorów Związki pomiędzy elementami modelowania Model przypadków użycia: § § § § § Notacja Analiza aktorów Analiza przypadków użycia Relacje między przypadkami użycia Związek uogólnienia między aktorami Określanie aktorów Określanie przypadków użycia Dokumentowanie przypadków użycia Diagram interakcji dla przypadku użycia Podsumowanie Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 3

Prezentowanie diagramów Diagramy mogą być prezentowane w formie: - nieobramowanej - obramowanej, gdzie diagram jest otoczony prostokątną ramą zawierającą nagłówek-diagramu=(rodzaj) nazwa-diagramu (parametry) nagłówek rodzaj – wyróżnik diagramu nazwa – odzwierciedlająca merytoryczną zawartość diagramu parametry – parametry kluczowe dla danego diagramu Nazwa jest obligatoryjnym elementem składowym nagłówka; rodzaj i parametry są elementami nieobligatoryjnymi. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 4

Stereotypy; komentarze Stereotypy: mechanizm rozszerzalności UML. Stereotypy są wykorzystywane do metaklasyfikacji elementów modelu. Notacja: «nazwa stereotypu» lub ikona Przykłady stereotypów: P 1 «include» P 2 P 3 «extend» P 4 Komentarze: mechanizm rozszerzalności UML. Komentarze są wykorzystywane do wprowadzania do diagramu adnotacji przypisanych do fragmentu modelu. tekst adnotacji Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 5

Klasyfikatory; wystąpienia klasyfikatorów Klasyfikator: kategoria modelowania UML, stanowiąca uogólnienie grupy bytów o podobnych własnościach; pojęcie klasyfikatora odnosi się do każdego rodzaju diagramów UML. Notacja: zależna od rodzaju diagramów Wystąpienie klasyfikatora (instacja klasyfikatora): odpowiada konkretnemu bytowi z grupy bytów charakteryzowanych przez dany klasyfikator Notacja: zazwyczaj zgodna z notacją klasyfikatora; różnice występują głównie w nazwach wystąpień: nazwa_własna_danego_bytu : nazwa_klasyfikatora Osoba O-Nowak : Osoba nazwisko : string wiek : integer nazwisko = ” Nowak” wiek = 35 klasyfikator wystąpienie klasyfikatora Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 6

Związki pomiędzy elementami modelowania (1) Na diagramach UML występują cztery rodzaje związków pomiędzy elementami modelowania: uogólnienie, asocjacja, zależność, realizacja. Uogólnienie (generalizacja): występuje pomiędzy klasyfikatorem ogólnym a klasyfikatorem specjalizowanym Notacja: klasyfikator specjalizowany klasyfikator ogólny Asocjacja: opisuje powiązania pomiędzy wystąpieniami klasyfikatorów (również pomiędzy różnymi wystąpieniami tego samego klasyfikatora) Notacja: klasyfikator Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 7 klasyfikator

Związki pomiędzy elementami modelowania (2) Zależność: jest związkiem pomiędzy takimi dwoma elementami modelowania, dla których zmiana jednego elementu (u dostawcy usług) może skutkować koniecznością wprowadzenia zmian do elementu drugiego (u klienta usług) Notacja: klient usług dostawca usług Realizacja: to związek pomiędzy klasyfikatorami, gdzie jeden z klasyfikatorów opisuje kontrakt, a drugi określa sposób realizacji tego kontraktu Notacja: klasyfikator określający sposób realizacji kontraktu klasyfikator opisujący kontrakt Jak? Co? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 8

Modele wg Jacobsona a. Model przypadków użycia: definiuje zarówno zewnętrze systemu (aktorzy ≡ systemy zewnętrzne ≡ kontekst systemu), jak i jego wnętrze (przypadki użycia); służy określeniu zachowań systemu w odpowiedzi na akcje pochodzące z otoczenia systemu. a. Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (dziedziny problemowej ≡ dziedziny przedmiotowej) w obiekty istniejące w systemie. a. Obiektowy model analityczny: podzbiór modelu dziedziny (dotyczy konkretnego zastosowania). a. Model projektowy (logiczny): opisuje założenia przyszłej implementacji. a. Model implementacyjny (fizyczny): reprezentuje implementację systemu. a. Model testowania: określa plan testów, specyfikuje procedury, dane testowe, raporty. Modele wymagają odpowiednich procesów do ich tworzenia § Proces analizy wymagań, składa się z dwóch podprocesów: - proces modelowania przypadków użycia - proces analizy związany z budową obiektowego modelu analitycznego § Proces projektowania § Proces implementacji § Proces testowania Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 9

Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu. Przyczyny: a Ujęcie w modelu pewnych elementów dziedziny problemu nie będących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi system ma współpracować. a Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie. Dostępne środki mogą nie pozwolić na realizację systemu w całości. Celem budowy modelu analitycznego może być wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą innego oprogramowania będzie szczególnie przydatne. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 10 Dziedzina problemu Model analityczny Zakres odpowiedzialności systemu

Model wymagań Składowe: § Model przypadków użycia § Obiektowy model analityczny Model przypadków użycia został oparty o dwa podstawowe pojęcia: Aktor Przypadek użycia Reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik, np. kierownik, urzędnik, klient. Reprezentuje sekwencję operacji (realizowanych przez system), niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Aktorem jest dowolny byt z otoczenia systemu, który uczestniczy w interakcji z systemem. Każdy potencjalny aktor może wchodzić w interakcję z systemem na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje przepływ operacji w systemie związany z obsługą zadania zleconego przez aktora w procesie interakcji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 11

Notacja Wypłata pieniędzy Przypadek użycia: Powinien mieć unikatową nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Czy lepiej jest stosować nazwę opisującą czynność (“wypłata pieniędzy”/„wypłacanie pieniędzy”) czy polecenie (“wypłać pieniądze”) − zdania są podzielone. Aktor: Powinien mieć unikatową nazwę. Klient Weryfikacja klienta «include» ud Obsługa klienta Interakcja: Ilustruje związek asocjacji zachodzący pomiędzy przypadkiem użycia (systemem) a aktorem. Blok ponownego użycia: Wewnętrzny fragment systemu, używany przez kilka przypadków użycia; blok ponownego użycia nie jest elementem UML. Relacja typu «include» lub «extend» : Pokazuje związek zależności zachodzący pomiędzy dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia. Nazwa diagramu wraz z nagłówkiem i ramą: ud (ang. use case diagram) – wyróżnik diagramu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 12

Aktor − kto (co) może wystąpić w roli aktora? Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z planowanym wykorzystywaniem projektowanego systemu, innymi słowy wymaga ustalenia zbioru “przyszłych użytkowników systemu”. Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne), inny system komputerowy lub urządzenie. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor “strażnik budynku”. (1) Czy system może być aktorem sam dla siebie? Aktor to przecież, zgodnie z definicją, byt z otoczenia systemu. (2) Aktor jest pierwotną przyczyną napędzającą przypadki użycia. Jest sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jest też odbiorcą danych wyprodukowanych przez przypadek użycia. Sprawca zdarzeń? Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji systemu jest aktorem? (3) Aktor pasywny a interakcja z systemem ? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 13

Analiza aktorów Wyjaśnienie różnicy pomiędzy pojęciem „konkretny użytkownik” a pojęciem „aktor”: Konkretny użytkownik Aktor Przypadek użycia zleca Może grać rolę Jan Kowalski Administrator systemu Przeładowanie systemu Adam Malina Pracownik Wejście z kartą i kodem Konkretny gość Osoba informowana Konkretny klient Klient Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 14 Uzyskanie informacji ogólnych Wypłata z konta

Wykorzystanie stereotypów dla aktorów Aktor: człowiek, grupa ludzi, organizacja «actor» Klient Aktor: system zewnętrzny System ubezpieczeń Aktor: czas 1 -szy dzień roku Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 15 Klient

Przykład diagramu przypadków użycia (1) ? Wpłata pieniędzy Klient Wypłata pieniędzy Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy – to zależy od konkretnego systemu. 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 Klient Kasjer Wypłata pieniędzy Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 16 alternatywna notacja dla przypadków użycia

Przykład diagramu przypadków użycia (2) ud Automat do sprzedaży papierosów Uzupełnienie towaru Zakup paczki papierosów Wykonanie operacji pieniężnej Operator Klient Sporządzenie raportu Kontroler Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 17

Liczność związków asocjacji ud Automat do sprzedaży papierosów Uzupełnienie towaru * 1 1 * Zakup paczki papierosów * Wykonanie operacji pieniężnej 1 Operator 1 Klient Sporządzenie raportu * * 1 Kontroler Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 18

Oznaczanie kierunków interakcji ud Automat do sprzedaży papierosów Uzupełnienie towaru Zakup paczki papierosów Wykonanie operacji pieniężnej Operator Klient Sporządzenie raportu System archiwizujący Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 19

Relacje między przypadkami użycia (1) Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi związki zależności typu «include» czy «extend» . W obu poniższych diagramach P 1, nazywane tu przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania. Przebieg podstawowy (sekwencyjny): P 1 zawsze włącza (używa) P 2, zwane tu przypadkiem włączanym. P 1 «include» P 2 Przebieg opcjonalny (alternatywny): P 1 jest czasami rozszerzane o P 2, zwane tu przypadkiem rozszerzającym (inaczej: P 2 czasami rozszerza P 1). Sformułowanie “czasami” oznacza, że warunek na wywołanie P 2 musi być spełniony, aby P 2 zostało wywołane z P 1. O ile warunek nie został wyspecyfikowany − co jest dopuszczalne − P 2 będzie wywołane zawsze. P 1 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 20 «extend» P 2

Relacje między przypadkami użycia (2) Rejestracja klienta «include» Przegląd samochodu Sprzedaż samochodu «include» «extend» Naprawa samochodu «extend» Umycie samochodu Przyholowanie samochodu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 21 «include» wskazuje na wspólny fragment wielu przypadków użycia (wyłączony “przed nawias”); jest wykorzystywane w przebiegach podstawowych (przypadek włączany jest zawsze wykonywany) − strzałka jest skierowana w stronę przypadku włączanego «extend» jest wykorzystywane w przebiegach opcjonalnych (przypadek rozszerzający nie zawsze będzie wykonywany) − strzałka jest skierowana w stronę przypadku bazowego

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

Relacje między przypadkami użycia (3) 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. Złożenie zamówienia Klient «extend» Dostawca Realizacja zamówienia Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 23

Związek uogólnienia między aktorami (1) Osoba Pracownik Księgowa Gość Pracownik administracji Np. Pracownik administracji dziedziczy dostęp do przypadków użycia wyspecyfikowanych dla każdego pracownika, oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 24

Związek uogólnienia między aktorami (2) ud Automat do operacji bankowych Podsystem zarządzania bazą danych banku Obsługa konta klienta «include» Informowanie o stanie konta klienta «include» Klient Inicjalizacja karty klienta Administrator systemu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 25 «include» Weryfikacja karty i kodu klienta

Związek uogólnienia między aktorami (3) ud Automat do operacji bankowych Podsystem zarządzania bazą danych banku Obsługa konta klienta «include» Informowanie o stanie konta klienta «include» Klient Inicjalizacja karty klienta Administrator systemu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 26 «include» Weryfikacja karty i kodu klienta

Rozbudowa modelu przypadków użycia Wpłać pieniądze Kasjer Wypłać pieniądze «include» Wypłać pieniądze «extend» «include» Klient banku Sprawdź stan konta Weź pożyczkę Zarząd banku Sprawdź stan konta Weź pożyczkę Uaktualnianie stanu konta Zarząd banku Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy przypadkami. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 27

Stopień szczegółowości diagramów Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system − spojrzenia z pozycji aktorów, którzy go używają. Z założenia nie włącza zbyt wielu szczegółów, co pozwala wnioskować o funkcjonalności systemu na odpowiednio wysokim poziomie abstrakcji. Podstawowym (choć nie jedynym) zastosowaniem jest tu 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 «include» Kompilacja programu Tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół, różni analitycy tworzą różne modele. «include» Wykonanie programu Programista Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 28 Drukowanie pliku Użytkownik końcowy

Diagram kontekstowy Podsystem zarządzania bazą danych banku «system» Automat do operacji bankowych Klient Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 29 Administrator systemu

Przepływ zdarzeń (1) ü Jednym z najważniejszych elementów w opisie każdego przypadku użycia – na etapie formułowania wymagań – jest specyfikacja przepływu zdarzeń między aktorem a systemem. Specyfikację przepływu zdarzeń należy formułować w języku naturalnym: prostą, spójną prozą i w oparciu o terminy zawarte w słowniku pojęć z dziedziny problemowej. Na przykład, przepływ zdarzeń między aktorem a systemem dla bankomatu, dla przypadku użycia “Wypłać pieniądze”, mógłby być opisany, jak poniżej: 1. Przypadek użycia rozpoczyna się, gdy klient wkłada kartę do bankomatu. System czyta informacje na karcie i bada ich poprawność. 2. System pyta o PIN. Klient wprowadza PIN. System sprawdza poprawność. 3. System pyta o rodzaj operacji do wykonania. Klient wybiera: “Wypłać pieniądze”. 4. System pyta o wielkość kwoty. Klient wprowadza kwotę. 5. System komunikuje się z bankiem, żeby sprawdzić poprawność ID konta, PIN i dostępność kwoty. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 30

Przepływ zdarzeń (2) 6. System pyta klienta czy potrzebuje potwierdzenie. 7. System komunikuje klientowi prośbę o zabranie karty. Klient zabiera kartę. Komunikat stanowi tu pewien mechanizm bezpieczeństwa chroniący klienta przed nie zabraniem karty. 8. System wydaje pieniądze. 9. System drukuje potwierdzenie (o ile klient sobie życzył) i to kończy przypadek użycia. ü Możliwe są różne, alternatywne przepływy dla tego przypadku użycia: § Dane od aktora: np. aktor może unieważnić transakcję w dowolnym momencie lub może nie chcieć potwierdzenia. § Stan systemu: np. bankomat może nie zawierać pieniędzy, może brakować papieru, może nastąpić blokada urządzenia wydającego pieniądze czy też blokada urządzenia drukującego potwierdzenie. § Time-out lub błędy: np. jeśli klient nie odpowie w określonym czasie, system może unieważnić transakcję. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 31

Scenariusze ü Każdy alternatywny przepływ nie oznacza oddzielnego przypadku użycia raczej grupujemy wszystkie powiązane przepływy w jeden przypadek użycia. ü Taką grupę przepływów czasami nazywa się klasą przypadków użycia. ü Wystąpieniem klasy przypadków użycia jest wtedy jeden z pojedynczych, alternatywnych przepływów. ü Wystąpienie klasy przypadków użycia jest także nazywane scenariuszem. ü Scenariusze są używane do “ekstrahowania” z przypadku użycia unikatowej sekwencji akcji, inaczej: “wątków” w przypadku użycia. ü Na wczesnych etapach rozwoju systemu łatwiej jest rozpocząć prace od pewnego konkretnego scenariusza, a następnie dokładać przepływy alternatywne − w ten sposób tworzy się klasę przypadków użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 32

Kolejne kroki w konstrukcji modelu Konstrukcja modelu przypadków użycia opiera się na kilku krokach i wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje zasadę: “nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika”. Jednocześnie powinien być budowany obiektowy model analityczny (schemat pojęciowy). Krok: 1 Sporządzenie słownika pojęć 2 Określenie aktorów 3 Określenie przypadków użycia 4 Tworzenie opisu każdego przypadku użycia plus: § podział na nazwane części § znalezienie wspólnych części w różnych przypadkach użycia Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 33 Udokumentowany w: Słownik pojęć Dokument opisu aktorów Diagram przypadków użycia + dokument z opisem przypadków użycia

Krok 1: sporządzenie słownika pojęć § Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć. § Słownik dotyczy dziedziny problemowej. § Tworzenie go polega na wyłowieniu wszystkich pojęć z wymagań użytkownika. § Pojęcia mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp. § Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. § Posługiwanie się pojęciami ze słownika powinno być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu. Przykład: Konto – służy do rejestrowania zasobów i wyników transakcji przeprowadzanych przez klienta, będącego właścicielem konta. Konta mogą być różnych typów, a w szczególności: konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto. Na co należy zwracać uwagę przy kwalifikowaniu pojęć do słownika: § na rzeczowniki − mogą oznaczać aktorów lub byty z dziedziny problemowej, § na frazy opisujące funkcje, akcje, zachowanie się − mogą stanowić podstawę do wyróżniania przypadków użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 34

Krok 2: określanie aktorów Przy określaniu aktorów istotne są odpowiedzi na następujące pytania: § Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu (np. osoba wysyłająca korespondencję)? § Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje (np. administrator systemu)? § Z jakich elementów zewnętrznych (innych systemów, urządzeń) musi korzystać system, aby realizować swoje funkcje. Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu, tj. odrzucaniem tych obszarów dziedziny problemowej, którymi system nie będzie się zajmował (ustalenie zakresu odpowiedzialności systemu). Po wyszukaniu aktorów, należy ustalić: § 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 dostępu do funkcji systemu dla aktorów. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 35

Krok 3: określanie przypadków użycia (1) Nazwy dla przypadków użycia powinny być krótkie, ale jednoznacznie określające charakter zadania zlecanego systemowi przez aktora. Ponadto, nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, czyli np. “wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”. funkcja systemu ≡ zachowanie systemu ≡ zadanie zlecane systemowi ≡ przypadek użycia a Dla każdego aktora, znajdź zadania: (1) w których system może go wesprzeć w działalności związanej z dziedziną przedmiotową, (2) niezbędne dla wspomagania działania systemu jako takiego (np. zakładanie kont użytkowników). a Staraj się powiązać w jeden przypadek użycia zespół zadań realizujących podobne cele. Unikaj rozbicia jednego przypadku na zbyt wiele pod-przypadków. a Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika. a Uporządkuj aktorów i przypadki użycia w postaci diagramu. a Przeanalizuj zarówno wyspecyfikowane przypadki użycia (niektóre z nich mogą być „mutacjami” innych przypadków użycia), jak i powiązania aktorów z przypadkami użycia. Ustal, co jest zbędne, a co może być uogólnione. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 36

Określanie przypadków użycia (2) a W pierwszym podejściu skup się na tzw. „przypadkach krytycznych”, czyli takich, które stanowią istotę systemu (są normalnym, standardowym użyciem) lub są ważne z powodu istniejących w projekcie ryzyk (np. ryzyk technologicznych). Pomiń czynności wyjątkowe, uzupełniające lub opcjonalne; pomiń przypadki użycia typu Create Read Update Delete. a Określ wzajemne powiązania przypadków, wyspecyfikuj rodzaj zależności: sekwencja ( «include» ) czy alternatywa ( «extend» ). a Dodaj zachowania wyjątkowe, uzupełniające, opcjonalne i CRUD. Ustal związki “przypadków krytycznych” z tego rodzaju zachowaniami. a Tworząc podział każdego przypadku użycia na nazwane części (bloki), staraj się, aby nie były one ani zbyt ogólne ani zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę, a zbyt ogólne zmniejszają możliwość wykrycia fragmentów oprogramowania posiadających potencjał ponownego użycia. Całość diagramu nie może być ani zbyt duża ani zbyt złożona. a Przeanalizuj przypadki użycia pod kątem wyizolowania bloków ponownego 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 ponownego użycia może być powiązane z określeniem bardziej ogólnych zadań lub dodaniu nowych elementów do już istniejącego zadania. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 37

Krok 4: dokumentowanie 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 oraz jak i kiedy zapamiętuje dane w systemie, § wyjątki 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(e) § specyfikację uczestniczących obiektów, § diagram(y) interakcji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 38

Diagram interakcji dla przypadku użycia (1) Przesyłanie komunikatów pomiędzy obiektami: Obiekt 1 Aktor Obiekt 2 Obiekt 3 Obiekt 4 k 1 k 2 czas k 3 k 4 k 5 ki − komunikat, czyli polecenie wykonania operacji na obiekcie, do którego komunikat jest wysyłany; komunikat nosi nazwę tej operacji Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 39

Diagram interakcji dla przypadku użycia (2) Uproszczony scenariusz Wypełnij formularz wpłaty Podaj formularz i gotówkę do kasy Aktualizuj stan konta klienta Zwiększ bilans kasy Zwiększ bilans banku Wydaj pokwitowanie dla klienta wpłata pieniędzy : Formularz : Klient : Kasa : Konto wypełnij podaj formularz aktualizuj stan zwiększ bilans wydaj pokwitowanie Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 40 zwiększ bilans : Bank

Szablon dokumentacji przypadku użycia Nazwa przypadku Nr id Numer identyfikacyjny przypadku Autor Informacje o autorze Priorytet Np. wysoki, średni, itd. Typ Np. ogólny, szczegółowy Aktorzy Lista aktorów związanych z przypadkiem Opis Krótka charakterystyka przypadku Warunek początkowy Świat „przed”, czyli informacja o tym, co powinno być wykonane wcześniej, tak aby system mógł zrealizować dany przypadek Warunek końcowy Świat „po” Główny przepływ zdarzeń Scenariusz główny Alternatywne przepływy zdarzeń Scenariusze alternatywne Wymagania niefunkcjonalne Np. czas odpowiedzi, szybkość transakcji, itd. Uwagi dodatkowe Wszystko, co warte jest uwagi, a nie zostało omówione powyżej Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 41

Dokumentacja przypadku Wypożycz kasetę (1) Nazwa Wypożycz kasetę Nr id 7 Autor Jan Kowalski - analityk Priorytet Wysoki Typ Ogólny Aktorzy Pracownik wypożyczalni Opis Przypadek 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ątkowy Osoba wypożyczająca powinna być zarejestrowana jako klient wypożyczalni Warunek końcowy O 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ł Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 42

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ń 2 a O ile osoba wypożyczająca nie jest zarejestrowana w systemie, system informuje o tym aktora i kończy przypadek użycia 2 b. 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. 3 a O ile aktualnie 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. 3 b 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. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 43

Dokumentacja przypadku Wypożycz kasetę (3) Alternatywne przepływy zdarzeń, cd. 3 c 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. 3 d Jeśli osoba wypożyczająca znajduje się aktualnie w okresie karencyjnym, system informuje o tym aktora i kończy przypadek. Wymagania niefunkcjonalne Brak Uwagi dodatkowe Brak Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 44

Podsumowanie Główne zadanie modelu przypadków użycia to określenie poprawnych wymagań funkcjonalnych na projektowany system, co jest uznawane za jeden z podstawowych problemów w procesie budowy systemu. Ponadto, model przypadków użycia pozwala na: § lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), lepsze zrozumienie jego funkcjonalności − co w efekcie oznacza zwiększenie stopnia świadomości uczestników projektu co do celów systemu, § umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu, § ustalenie praw dostępu do zasobów, § zrozumienie strukturalnych własności systemu, a przez to ustalenie składowych systemu i związanego z nimi planu budowy systemu, § dostarczenie podstawy do sporządzenia harmonogramu prac, § dostarczenie bazy do budowy planu testów systemu, § dostarczenie środków umożliwiających weryfikację poprawności i kompletności projektu. Przypadki użycia powinny odwzorowywać strukturę systemu tak, jak tę strukturę widzą przyszli użytkownicy systemu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 45

Przypadki użycia w analizie Eksperci Doświadczenie w dziedzinie przedmiotowej Model dziedziny Model analityczny Przypadki użycia Użytkownicy Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 46 Model zastosowania mocny wpływ słaby wpływ