Radek Bartosiak kedar@mimuw.edu.pl Ćwiczenia z IO dotyczące przypadków użycia. Zagadnienia do omówienia na ćwiczeniach 1. Wprowadzenie do przypadków użycia jako sposobu przedstawienia interakcji użytkownika (a raczej aktora, np także innego systemu informatycznego) z systemem traktowanym jako czarna skrzynka. 2. Przypadek użycia jako dialog między aktorem a systemem 3. Przypadki użycia jako sposób opisu wymagań funkcjonalnych sytemu 4. Schematyczne przedstawianie przypadków użycia na diagramach UML owych, cele i ograniczenia takiej reprezentacji przypadków użycia (podkreślić, że diagramy pełnią jedynie funkcję pomocniczego spisu treści, trzeba pisać scenariusz przypadków użycia. 5. Które scenariusze przypadków użycia pisać najpierw, jak dokładnie pisać scenariusze przypadków użycia, czy trzeba pisać wszystkie scenariusze przypadków użycia. 6. Dokumentowanie stakeholderów i ich interesów (nawet jeżeli nie są aktorami, np urząd skarbowy w przypadku użycia Sprzedaż towarów za pomocą terminalu kasowego ) 7. Dokumentowanie warunków wstępnych i końcowych 8. Scenariusze główne i alternatywne. 9. Użycie innego przypadku użycia (jeżeli zawsze: include, jeżeli czasem: extend) 10. Dokumentowanie wymagań niefunkcjonalnych (np dotyczących kolorystyki, użycia ekranów dotykowych, wydajności systemu). 11. Napisane scenariusze przypadków użycia NIE są ostateczne (nie można liczyć, że udało nam się napisać scenariusze bezbłędne czy kompletne. Wymaganie podlegają identyfikacji i zmianom oraz ukonkretnieniu> Przykładowo na wczesnym etapie analizy wymagań nie należy pisać scenariuszy, które narzucają konkretne rozwiązania techniczne lub zbyt dokładnie określają GUI) 12. Wskazówki jak zidentyfikować PU Określ zakres (system=software, system=hardware+software,system=hardware+software+ludzie, system=organizacja). To zasadniczo decyduje czy tworzymy tzw biznesowy przypadek użycia, czy tzw systemowy przypadek użycia Zidentyfikuj aktorów Zidentyfikuj cele każdego aktora, zastanów się nad interesami stakeholderów Zdefiniuj przypadki użycia realizujące cele każdego z aktorów 13. Przydatne pytania (w identyfikacji przypadków i aktorów o których można łatwo zapomnieć)
Czy czas (albo zaufany serwer czasu :) jest aktorem Kto administruje systemem (uruchamia, wyłącza, dodaje/usuwa użytkowników, nadaje uprawnienia, monitoruje...) Kto bada, nadzoruje działanie systemu, kto jest powiadamiany w przypadku nieprawidłowości w przypadku jego działania, kto czyta logi. Czy istnieje proces, który restartuje system po jego awarii W jaki sposób oprogramowanie systemu jest aktualizowane Czy system kontaktuje się (korzysta z, udostępniania funkcje) z zewnętrznymi systemami informatycznymi. 14. Podkreślić, że to co jest przypadkiem użycia zależy od zakresu systemu! Test szefa: Szef pyta Co robi Pan dziś od rana (eliminuje przypadek użycia logowanie, który swoją drogą w pewnym momencie może się znów pojawić, gdy będziemy chcieli podjąć konkretne decyzje projektowe dotyczące autentykacji :) Test elementarnego procesu biznesowego: Zadanie wykonywane przez jedną osobę, w jednym miejscu i w konkretnym stosunkowo krótkim czasie (sekundy,minuty) w odpowiedzi na zaistnienie zdarzenia biznesowego, które przynosi wymierną wartość biznesową oraz pozostawia system w spójnym stanie. Eliminuje przypadki użycia typu: edycja wiersza dokumentu tekstowego (brak spójności oraz wymiernej korzyści biznesowej) oraz np projektowanie nowego samochodu(zbyt długi czas, ale może nadawać się na biznesowy przypadek użycia) 15. Przypadki użycia mają pomagać i jak zwykle należy dostosowywać metodologię do potrzeb i możliwości. Przykład 1 Omówić przykładowy przypadek użycia z rozdziału 6 (o przypadkach użycia), książki Craiga Larmana Applying UML and Patterns (strony 50 58, te strony można skserować studentom). Ćwiczenie 2 Producent sprzętu komputerowego wchodzi na nowy rynek urządzeń bankomatowych, każdy bankomat ma mieć własne oprogramowanie, które będzie się łączyło z oprogramowaniem operatora zarządzającego bankomatem. Twoim zadaniem jest opracowanie przypadku użycia Wypłata gotówki z bankomatu Uwagi: 1. Można podkreślić pewną sztuczność tej sytuacji (scenariusz jest dość dobrze określony), przeważnie tak nie jest i pisanie scenariusza jest większym wyzwaniem. 2. Identyfikacja aktorów, stakeholderów i ich interesów, zakresu systemu oraz (to ważne) innych przypadków użycia
3. Dyskusja na temat tego jak dokładnie modelować autoryzację w tym przypadku jestem za dokładnym modelowaniem tzn piszemy Aktor wprowadza PIN, a nie Aktor autoryzuje się, gdyż ta technologia (PIN) jest standardem i jest narzucona ). 4. Skupić się na scenariuszach alternatywnych (błędne hasło, brak gotówki w bankomacie, brak niektórych rodzajów banknotów (np nie można wypłacić 20PLN), zbyt duża kwota wypłaty, przekroczenie stanu konta, zbyt powolne wprowadzanie PINu, nie wyjęcie karty bankomatowej, niepodjęcie pieniędzy, karta bankomatowa nieczytelna, utrata połączenia z systemem zewnętrznym...) Podkreślić, że tu właśnie leży siła PU, sprawdzić czy studenci nie są teraz w stanie zidentyfikować nowych przypadków użycia naszego systemu (np pobranie zatrzymanych kart, powiadomienie o awarii, braku banknotów etc. Przedyskutować padające propozycje w kontekście zakresu i aktorów) 5. Warunki początkowe (np istnienie połączenia z systemem) i końcowe (przebieg operacji jest zapamiętany, informacje przekazane systemowi zewnętrznemu), niefunkcyjne (zagadnienia związane z czasem) 6. Przykład dobrze nadaje się do pokazania różnic gdy myślimy (ustalamy zakres), że system to samo oprogramowanie, oraz gdy myślimy o systemie jako o oprogramowaniu i sprzęcie Uwagi do ćwiczenia 3 1. To ćwiczenie jest mniej skoncentrowane na scenariuszach, po prostu pisanie scenariuszy jest czasochłonne i na ćwiczeniach musimy (mym zdaniem) przećwiczyć także inne rzeczy. Oczywiście zawsze podkreślamy studentom, że najważniejsze są scenariusze. 2. Ćwiczenie nadaje się do pokazania różnicy między systemowym, a biznesowym przypadkiem użycia. Ja biznesowy przypadek użycia Dodanie nowej funkcji każę modelować za pomocą diagramu czynności (z torami). Oczywiście możecie uważać, że na te diagramy jest jeszcze zbyt wcześnie, możecie zresztą całkowicie pominąć rozróżnienie między biznesowymi i systemowymi PU (choć moi studenci wydają się pojmować tę różnicę). 3. Jeżeli mamy diagram czynności to można wskazać w jaki sposób SPU wspierają dane czynności i pokazać w ten sposób śledzenie. 4. Na diagramach PU można tu pokazać generalizację (np generuj raport i dwie podklasy odpowiadające typom raportów), zawieranie i rozszerzanie (np powiadom o odrzuceniu). 5. Ćwiczenie pozwala na zbadanie czy studenci radzą sobie określeniem zakresu, wadą jest to że tak na prawdę nie udaje się zidentyfikować wszystkich przypadków użycia (można na to zwrócić uwagę: np zarządzanie użytkownikami zostanie za pewne pominięte przez studentów). No i krótki opis (oparty na moich notatkach z ćwiczeń z Arkiem Wojną) także nie może oddawać wszystkich problemów, wymagań.
Ćwiczenie 3 System jest przeznaczony dla działu informatyki firmy prowadzącej działalność ubezpieczeniową (sprzedaż polis posagowych, polis na życie itp). Dział informatyki zajmuje się utrzymaniem i rozwojem systemów informatycznych tej firmy. Wraz z ekspansją firmy, wprowadzaniem przez jej władze nowych usług i ofert oraz wraz ze zmianami przepisów prawnych pojawiają się potrzeby udostępniania nowych funkcji oraz zmiany istniejących funkcjonalności. System ma za zadanie zapewnić efektywną komunikację pomiędzy pracownikami związaną ze zgłaszaniem i realizacją tych potrzeb. Przy pojawieniu się nowego zapotrzebowaniapracownik zgłasza je do systemu podając: nazwę systemu który trzeba zmodyfikować, informację czy potrzebna jest nowa funkcja czy zmiana już istniejącej, opis funkcji (modyfikacji), priorytet oraz maksymalny czas realizacji. Po zgłoszeniu zadania osoba z działu informatyki zwana administratorem zadań dokonuje wstępnej analizy zapotrzebowania i przypisuje je do odpowiedniego zespołu projektowego. Kierownik zespołu projektowego wykonuję dokładną analizę zadania i albo je odrzuca, podając uzasadnienie, albo przyjmuje zadanie do wykonania. Jeżeli zadanie zostało odrzucone to zgłaszający zostaje o tym poinformowany. W przypadku akceptacji zadania kierownik zespołu musi wybrać z podzespołu programistów osobę która będzie miała za zadanie zaimplementować zadaną funkcję, a z podzespołu testerów osobę która przetestuje implementację i jej zgodność z wymaganiami zgłaszającego. Obsługa realizacji zadania przebiega w następujący sposób. Po przydziale osób wybrany programista jest informowany o nowym zadaniu i po jego wykonaniu zgłasza ten fakt do systemu podając również nazwy fizycznych komponentów systemu które uległy zmianie (dane, pliki wykonywalne, konfiguracyjne, dokumentacja techniczna, pomoc użytkownika, przypadki testowe oraz opisy testów wykonywanych w trakcie implementacji) System informuje wtedy testera o potrzebie przetestowania wprowadzonych zmian. Po wykonaniu testów tester wprowadza do systemu jego wyniki (oraz utworzone przypadki testowe). Jeżeli wynik jest pozytywny, to Dział Migracji jest informowany o potrzebie uaktualnienia wersji produkcyjnej systemu. Po wykonaniu migracji system informuje: kierownika zespołu, administratora zadań, oraz zgłaszającego o dostępności nowej lub zmienionej funkcjonalności Jeżeli wynik testu był negatywny informowany jest kierownik zespołu, który musi ponownie wykonać analizę zadania pod względem jego wykonalności i jeżeli nie zmienił decyzji to ponownie wybiera osoby do jego wykonania i przetestowania (mogą być to inne niż poprzednio osoby). Z każdym zadaniem system zapamiętuje również daty oraz autorów kolejnych operacji wykonywanych dla danego zadania, takich jak: zgłoszenie, przypisanie, wykonanie testów, odrzucenie zadania oraz aktualny status zadania. Pracownicy firmy mają dostęp do opisu, historii i aktualnego stanu realizacji zadań, przy czym zwykli pracownicy mogą przeglądać tylko informacje dotyczące zgłoszonych przez siebie zadań, pracownicy działu informatyki do wszystkich zadań przypisanych do ich zespołów, a administratorzy zadań i pracownicy Działu Migracji do wszystkich zgłoszonych zadań. Istnieje także grupa kierowników mających możliwość generowania i drukowania sumarycznych raportów dotyczących realizacji potrzeb. Istnieją dwa rodzaje raportów: pierwszy zawiera informacje ile potrzeb zostało zgłoszonych, ile zrealizowanych, ile odrzuconych w zadanym okresie czasu. Parametrami tego raportu są: okres czasu, dział(y) z których pochodziły zapotrzebowania, zespół
projektowy (zespoły projektowe) do których te zapotrzebowania zostały przypisane. Drugi rodzaj raportów zawiera informacje bieżące, czyli dla każdego statusu jest podana informacja, ile w danej chwili jest zadań o danym statusie (ten raport także można przygotować dla zadań z wybranych działów i zespołów projektowych). 1. Narysuj diagram czynności dla procesu biznesowego (biznesowego przypadku użycia): Dodanie nowej funkcji 2. Zidentyfikuj aktorów i systemowe przypadki użycia i przedstaw je na diagramie przypadków użycia.