Jak pisa przypadki uycia Jolanta Sala Halina Taska

Jak pisać przypadki użycia Jolanta Sala Halina Tańska Olsztyn 2019

Narzędzie – Enterprise Architect (EA) Nazwa PU: Rodzaj: Główny lub alternatywne Opis : Kroki scenariusza

Czym jest przypadek użycia • Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania. W przypadku użycia opisuje się zachowanie systemu w różnych warunkach, gdy system reaguje na żądanie jednego z uczestników, zwanego aktorem głównym. • Aktor główny rozpoczyna interakcję z systemem, której wynikiem ma być osiągnięcie pewnego celu. System reaguje, zabezpieczając interesy wszystkich uczestników. Mogą z tego wyniknąć różne ciągi zachowań (lub scenariuszy), zależnie od konkretnych wysłanych żądań i warunków w ich środowisku. W przypadku użycia scenariusze te łączą się. • Przypadki użycia mają postać tekstu, chociaż niekiedy można je zapisać za pomocą diagramów blokowych, diagramów przebiegu, sieci Petriego lub języków programowania. Służą one jako sposób komunikowania się osób.

Pisanie PU • • Przypadek użycia jako sposób pisania może w ramach zespołu zachęcać do dyskusji o powstającym systemie. Zespół może (ale nie musi) dokumentować rzeczywiste wymagania za pomocą przypadków użycia. Inny zespół może zapisać ostateczny projekt za pomocą przypadków użycia. Gdy przypadki użycia służą do udokumentowania procesów gospodarczych przedsiębiorstw, systemem analizowanym (S. A. ) jest po prostu to przedsiębiorstwo. Uczestnikami są właściciele akcji firmy, klienci, sprzedawcy i nadzorujące agencje rządowe. Aktorzy główni to m. in. klienci firmy, dostawcy. Gdy przypadek użycia jest zapisem wymagań czynnościowych stawianych części oprogramowania, S. A. jest programem komputerowym. Uczestnikami są osoby korzystające z programu, firma będąca jego właścicielem, nadzorujące agencje rządowe i inne programy komputerowe. Aktorem głównym jest użytkownik siedzący przed ekranem komputera lub inny system komputerowy. Dobrze napisany przypadek użycia składa się ze zdań napisanych tylko w jednej formie gramatycznej. Ma postać prostego kroku czynności, w którym aktor otrzymuje wynik lub przekazuje informacje innemu aktorowi.

Scenariusz - przykład Zakup towaru Rodzaj: Główny lub alternatywne Opis : Kroki scenariusza

Scenariusz - przykład „zakup towaru” 1/2 • Scenariusz to ciąg kroków opisujących interakcję między użytkownikiem a systemem. • W wypadku sklepu internetowego scenariusz „zakup towaru” może wyglądać następująco: Klient przegląda katalog i wkłada towary do koszyka. Gdy chce zapłacić, podaje informacje o adresie dostawy, karcie kredytowej i potwierdza chęć zakupu. System sprawdza autoryzację karty kredytowej i potwierdza sprzedaż natychmiastowo wysyłając pocztę elektroniczną. • Ten scenariusz przedstawia jedną z sytuacji, jakie mogą się przydarzyć. Autoryzacja karty kredytowej mogłaby się jednak zakończyć niepowodzeniem i byłby to oddzielny scenariusz.

Scenariusz - przykład „zakup towaru” 2/2 • Scenariusz składa się z kroków działania. • W scenariuszu sukcesu wszystkie (uzgodnione) interesy uczestników są spełnione względem usługi, która ma być zrealizowana. • W scenariuszu niepowodzenia wszystkie te interesy są chronione zgodnie z gwarancjami systemu. Scenariusz kończy się, gdy wszystkie interesy uczestników są spełnione lub ochronione. • Trzy wyzwalacze, które oznaczają żądanie realizacji celu, to rozpoczęcie przez aktora głównego interakcji z systemem, rozpoczęcie przez aktora głównego tej interakcji przez pośrednika i rozpoczęcie w wyniku zmiany stanu lub upływu czasu.

Scenariusz to droga od celu do rezultatu Cel Scenariusz alternatywny SA 2 Scenariusz alternatywny SA 1 Scenariusz alternatywny SA 3 Rezultat

Zakres 1/3 • Zakres to słowo, którego używamy na oznaczenie obszaru, tego, co projektujemy, w odróżnieniu od tego, co jest zadaniem projektowym kogoś innego, lub tego, co ma już projekt. • Panowanie nad zakresem przedsięwzięcia lub choćby tylko zakresem dyskusji może być trudne. Warto skorzystać z narzędzia do śledzenia i panowania nad dyskusjami o zakresie – listę w-poza. • Narzędzie lista w-poza to tabela z trzema kolumnami. Lewa kolumna zawiera dowolny temat. Pozostałe dwie kolumny mają etykiety „W” i „Poza”. Gdy może dojść do nieporozumienia, czy dany temat leży w zakresie dyskusji, dodaj go do tabeli i spytaj ludzi, czy jest on w czy poza • Skutecznie wykorzystaj listę w-poza na początku czynności gromadzenia wymagań lub pisania przypadków użycia w celu oddzielania rzeczy leżących w zakresie prac od tych, poza zakresem • Wracaj do niej, ilekroć wydaje ci się, że dyskusja schodzi na manowce albo gdy dyskutowane jest wymaganie, wymaganie dla którego nie ma miejsca.

Tabela. Przykładowa lista w-poza 2/3 Temat W Fakturowanie w dowolnej postaci Poza Generowanie raportów o zleceniach (np. przez dostawcę, kontrahenta lub osobę) W Łączenie zleceń w jedno PO W Częściowe dostawy, spóźnione dostawy i błędne dostawy W Wszystkie nowe usługi systemu, oprogramowanie W Dowolne części systemu nie będące oprogramowaniem Poza Wynajdowanie istniejącego oprogramowania, które można by użyć W Zapotrzebowanie W Używaj listy w-poza do zapisywania tematów związanych zarówno z zakresem funkcjonalnym, jak i zakresem projektowym systemu analizowanego.

Zakres funkcjonalny 3/3 • Zakres funkcjonalny dotyczy usług oferowanych przez system, które na końcu zapisze się w postaci przypadków użycia. • Gdy rozpoczynasz przedsięwzięcie, prawdopodobnie będziesz miał o nim precyzyjnej wiedzy. • Zakres funkcjonalny ustalasz w tym czasie, w którym rozpoznajesz przypadki użycia – oba te zadania przeplatają się. • Pomaga w tym lista w-poza, w-poza ponieważ umożliwia nakreślenie granicy między tym, co jest w, i tym co jest poza zakresem. • Innymi dwoma narzędziami są – lista aktor-cel – szkice przypadków użycia

Lista aktor-cel 1/2 • Na liście aktor-cel wylicza się wszystkie cele użytkownika, których realizację system ma wspomagać, i pokazuje się funkcjonalną zawartość systemu. • W odróżnieniu od listy w-poza, która obejmuje zarówno elementy w zakresie, jak i spoza niego, lista aktor-cel zawiera jedynie te usługi, które system rzeczywiście będzie wykonywał • Przed przystąpieniem do opracowania takiej listy, nakreśl tabelkę z trzema kolumnami. • W lewej umieść aktorów głównych, tzn. takich, którzy mają cele. W środkowej kolumnie wpisz cele tych aktorów w odniesieniu do systemu. • W trzeciej kolumnie wynotuj priorytety albo twoje oszacowanie, w której wersji system będzie wspomagał realizację tego celu. W trakcie przedsięwzięcia ustawicznie aktualizuj tę listę, aby zawsze odzwierciedlała stan granicy funkcjonalnej systemu. • Niektórzy dodają jeszcze kilka kolumn: wyzwalacz, w której określa się przypadek użycia uruchamiany w miarę upływu czasu, a nie przez osobę, priorytet gospodarczy, złożoność wytwarzania i priorytet wytwarzania. • Dzięki nim można oddzielić potrzeby gospodarcze od kosztów wytworzenia przy ustalaniu priorytetu wytwarzania.

Tabela. Przykładowa lista Aktor-cel system śledzenia zleceń Aktor Cel 2/2 priorytet Każdy Sprawdź zlecenie 1 Kontroler Zmień zlecenie 2 Kupujący Sprawdź kontakt z dostawcami 3 Zamawiający Przygotuj zlecenie 1 Zmień zlecenie 1 Anuluj zlecenie 4 Odznacz zlecenie jako zrealizowane 4 Odrzuć dostarczone towary 4 Akceptujący Wypełnij żądanie dostawy 2 Kupujący Wypełnij żądanie zamówienia 1 Rozpocznij PO z dostawcą 1 Zgłoś brak dostawy 4 Kontroler Zweryfikuj podpis Akceptującego 3 Odbiorca Zarejestruj dostawę 1 W tabeli podano listę aktor-cel z przedsięwzięcia budowy systemu śledzenia zleceń dotyczących zaopatrzenia. Jest to wstępna propozycja do negocjacji.

Szkice przypadków użycia • Szkic przypadku użycia to opis zachowania przypadku użycia w od dwóch do sześciu zdaniach, w których uwzględnia się jedynie najbardziej znaczące czynności i awarie. • Informuje ludzi o tym, o co chodzi w przypadku użycia. Jest przydatny do oszacowania złożoności prac. • Zespoły budujące SI z komercyjnych komponentów z półki korzystają z tego opisu przy wyborze komponentów. • Niektóre zespoły wytwórcze, np. mające szczególnie dobrą wewnętrzną komunikację i ciągle rozmawiające z użytkownikami nigdy nie piszą więcej wymagań niż szkice przypadków użycia. • Reszta wymagań jest utrzymywana przez ustawiczne dyskusje, prototypy i często dostarczane przyrosty. • Szkice przypadków użycia można przygotować w postaci tabeli, w postaci rozszerzenia listy aktor-cel albo od razu jako część treści przypadków użycia w ich pierwszej wersji.

Tabela. Przykładowe szkice przypadków użycia Aktor Cel Szkic Personel produkcyjny Zmień kartę Personel produkcyjny dodaje metadane obszaru administracyjnego (hierarchia administracyjna, administracyjnego waluta, kod języka, typ ulic itp. ) do referencyjnej bazy danych. Kataloguje się informacje kontaktowe dla danych źródłowych. Jest to szczególny przypadek aktualizacji danych referencyjnych. Personel produkcyjny Przygotuj cyfrowe źródłowe dane kartograficzne Personel produkcyjny przekształca dane cyfrowe otrzymane z zewnątrz w standardowy format, sprawdza je i poprawia, przygotowując do połączenia z operacyjną bazą danych. Dane kataloguje się i przechowuje w cyfrowej bibliotece źródłowej. Personel produkcyjny i terenowy Zatwierdź transakcje aktualizacyjne przy jednoczesnym pobraniu z operacyjnej bazy danych Personel stosuje zgromadzone transakcje aktualizacyjne z operacyjnej bazy danych. Transakcje nie powodujące konfliktów są zatwierdzane w operacyjnej bazie danych. Kontekst aplikacji jest synchronizowany z operacyjną bazą danych. Zatwierdzone transakcje są usuwane z kontekstu aplikacji, co pozostawia operacyjną bazę danych w stanie spójnym. Transakcje powodujące konflikty są potem rozstrzygane manualnie i interakcyjnie.

Błędy w pisaniu PU 1/5 • Największymi błędami popełnianymi przy pisaniu przypadków użycia są – pomijanie podmiotów zdań, – czynienie założeń o projekcie interfejsu użytkownika, – uwzględnianie celów na zbyt niskim poziomie.

Brak systemu w PU • Przypadek użycia: Pobierz gotówkę • Zakres: Bankomat • Aktor główny: Klient 2/5 klient 1. Klient wsuwa kartę i wprowadza hasło 2. Klient wybiera „Wypłata” i podaje kwotę 3. Klient odbiera gotówkę, kartę i potwierdzenie 4. Klient odchodzi • W tym przypadku użycia pokazano wszystko co robi aktor główny, ale nie uwzględniono zachowania systemu. • Korekta będzie polegała na nazwaniu wszystkich aktorów i ich akcji.

PU – brak aktora głównego • • • Przypadek użycia: Pobierz gotówkę Zakres: Bankomat Aktor główny: klient 1. 2. 3. 4. 5. 6. 3/5 klient Pobiera kartę bankomatową i hasło Dowiaduje się, że typ transakcji to „Wypłata” Dowiaduje się o wielkości żądanej kwoty Stwierdza, że na koncie są wystarczające środki Wydaje pieniądze, potwierdzenie i kartę Zeruje swój stan Praktyczne uwagi: Ten przypadek użycia napisano wyłącznie z punktu widzenia systemu. Na jego podstawie można dowiedzieć się wszystkiego, co robi bankomat, ale nie ma ani słowa o zachowaniu aktora głównego. Zapiski tego rodzaju są trudne do zrozumienia, sprawdzenia i poprawienia. Korekta jest tu konieczna. Należy nazwać każdego aktora i akcję.

4/5 PU – korekta zbyt wiele szczegółów interfejsu • • • Przypadek użycia: Kup towar Zakres: Aplikacja obsługująca sprzedaż Aktor główny: Klient 1. 2. 3. 4. 5. 6. • • klient Klient przekazuje systemowi identyfikator i hasło System stwierdza poprawność identyfikacji użytkownika Użytkownik udostępnia nazwisko, adres, numer telefonu System stwierdza, że użytkownik jest mu znany Użytkownik wybiera towary i ilości Kontaktując się z systemem magazynowym hurtowni, system stwierdza, że w magazynie jest wystarczająca ilość żądanego towaru Korekta polega na znalezieniu sposobu opisu intencji użytkownika bez faktycznego wskazywania konkretnego rozwiązania. Czasem wymaga to kreatywnego sformułowania.

5/5 PU – zbyt wiele szczegółów interfejsu użytkownika • • • Przypadek użycia: Kup towar Zakres: Aplikacja obsługująca sprzedaż Aktor główny: Klient klient 1. System wyświetla ekran z pytaniem o identyfikator i hasło 2. Użytkownik wpisuje do systemu identyfikator i hasło; naciska OK 3. System stwierdza poprawność identyfikatora użytkownika i hasło; wyświetla ekran z danymi osobowymi 4. Klient wpisuje imię i nazwisko, ulicę, miasto, województwo, kod pocztowy i numer telefonu; naciska OK. 5. System stwierdza, że użytkownik jest mu znany 6. System wyświetla listę dostępnych towarów 7. Użytkownik przyciska obrazki towarów, które chce kupić, wpisuje ilość obok każdego i naciska „Gotowe”, gdy skończy 8. Kontaktując się z systemem magazynowym hurtowni, system stwierdza, że w magazynie jest wystarczająca ilość żądanego towaru • Praktyczne uwagi: – – Ten błąd prawdopodobnie zdarza się najczęściej. Autor napisał zbyt wiele o interfejsie, co sprawiło, że przypadek użycia przestał być dokumentacją wymagań a stał się podręcznikiem użytkownika. Nadmiarowe szczegóły interfejsu użytkownika nic nie wnoszą do opowiadania, ale zaśmiecają treść i sprawiają, że wymagania są słabe. Korekta polega na znalezieniu sposobu opisu intencji użytkownika bez faktycznego wskazywania konkretnego rozwiązania. Czasem wymaga to kreatywnego sformułowania.

Stosowanie przypadków użycia w procesie analizy • • Proces rozpoczyna się od wywiadów z klientem. Ich rezultatem jest stworzenie diagramu klas, który następnie może służyć za podstawę wiedzy o domenie systemu (zakresie, w którym system będzie rozwiązywał problemy). Po zapoznaniu ogólnej terminologii używanej przez klienta należy rozpocząć rozmowy z użytkownikami. Wywiad z użytkownikami rozpoczynamy od terminologii domeny, którą powinniśmy wzbogacić o terminologię użytkowników. Pierwsze wywiady powinny odkryć aktorów i przypadki użycia wysokiego poziomu, opisujące ogólne warunki funkcjonalne. Te informacje prowadzą do poznania ograniczeń i zakresu systemu. Kolejne wywiady z użytkownikiem są szczegółowym zagłębianiem się w te warunki i prowadzą do tworzenia modelu ukazującego scenariusze ze szczegółowymi ciągami zdarzeń. Może to prowadzić do tworzenia dodatkowych przypadków użycia ze związkami zawierania i rozszerzania. Jest ważne, aby w tej fazie polegać na własnym rozumieniu domeny (na podstawie diagramu klas stworzonego w wyniku rozmów z klientem). Uwaga: Jeżeli nie rozumiemy domeny, możemy stworzyć zbyt wiele przypadków użycia ze zbyt wieloma szczegółami, a to może w znaczący sposób wpłynąć na projektowanie i budowanie systemu.

Stosowanie modeli przypadków 1/9 użycia - przykład • Zakładamy, że należy zaprojektować lokalną sieć komputerową (LAN) dla firmy konsultingowej. • Trzeba wyobrazić sobie funkcjonowanie tej sieci. • LAN jest siecią komunikacyjną, używaną na ograniczonym obszarze. Pozwala na współużytkowanie zasobów i informacji.

Poznanie domeny 2/9 • Zaczynamy od wywiadów z klientem, co pozwoli na stworzenie diagramu będącego odbiciem pracy w firmie konsultingowej. Diagram ten może zawierać następujące klasy: Konsultant, Klient, Projekt, Propozycja, Dane i Raport.

Zrozumienie użytkowników 3/9 • Po poznaniu domeny skupić trzeba skupić uwagę na użytkownikach pamiętając, że naszym zadaniem jest wyobrażenie sobie pełnej funkcjonalności systemu. • W świecie rzeczywistym z użytkownikami trzeba przeprowadzać wywiady (nic nie zastąpi wywiadów z ludźmi). • W tym przypadku należy się opierać na ogólnej znajomości konstrukcji sieci lokalnych i znajomości domeny. • Jedną grupę będą stanowić konsultanci, drugą urzędnicy biura. Inni potencjalni użytkownicy to: księgowi, handlowcy, administratorzy sieci, kierownicy działów, kierownicy projektów.

Hierarchia użytkowników sieci LAN 4/9 Metoda z góry do dołu Pracodawca Członek Menedżer Konsultant Kierownik Menedżer Administrator biura projektu sieci zarządu Urzędnik Metoda z dołu do góry

Zrozumienie przypadków Lista przypadków: 5/9 „Zapewnij bezpieczeństwo”, „Przygotuj propozycję”, „Użyj poczty elektronicznej”, „Udostępnij informacje”, „Wykonaj księgowanie”, „Połącz się z siecią lokalną z innej sieci lokalnej”, „Połącz się z Internetem”, „Współużytkuj bazę danych”, „Zrób katalog propozycji”, „Używaj gotowych propozycji”, „Współużytkuj drukarki”.

Diagram przypadków użycia wysokiego poziomu sieci LAN firmy konsultingowej 6/9 Członek zarządu Połącz się z zewnątrz Zapewnij poziom bezpieczeństwa Administrator Przygotuj propozycję Kierownik biura Menedżer projektu Konsultant Użyj poczty elektronicznej sieci Zapisz propozycję Współużytkuj bazę danych Korzystaj z Poprzednich propozycji Połącz się z internetem Zrób katalog propozycji Urzędnik Współużytkuj drukarkę

• • Drążenie w głąb Zajmijmy się dokładnie jednym z przypadków wysokiego poziomu i zbudujemy jego dokładny model. Jedną z najważniejszych powinności firmy konsultingowej jest przygotowywanie propozycji. Z rozmów przeprowadzonych z konsultantami dowiesz się, ile kroków będzie liczył ciąg czynności w tym przypadku użycia, którego aktorem inicjującym jest właśnie konsultant. – – – – • • 7/9 Konsultant musi się zalogować w sieci LAN i zostać rozpoznany jako uprawniony użytkownik. Potem, korzystając z oprogramowania pakietu biurowego (procesora tekstu, arkusza kalkulacyjnego i programu graficznego), przystąpi do przygotowania propozycji. Na tym etapie pracy konsultant może korzystać z propozycji wcześniej przygotowanych. W części firm konsultingowych przygotowane propozycje przed przekazaniem klientowi są sprawdzane przez jednego z członków zarządu i dwóch innych konsultantów. Aby tego rodzaju praktyka była możliwa, konsultant zapisuje gotową propozycję w centralnym repozytorium i pocztą elektroniczną zawiadamia zainteresowane osoby o miejscu jej zapisania. Po otrzymaniu uwag i dokonaniu modyfikacji (znów za pomocą pakietu oprogramowania biurowego) konsultant drukuje propozycję i wysyła ją do klienta. Gdy wszystko jest skończone, wylogowuje się z sieci. Konsultant, który przygotował skończoną propozycję, jest aktorem czerpiącym korzyści z danego przypadku użycia. Z wyliczonego poprzednio ciągu czynności wynika, że niektóre kroki będą powtarzane w kilku przypadkach użycia, zatem należy pomyśleć o zastosowaniu zawierania, co na początku mogło nie wydawać się tak oczywiste. Z tego powodu można stworzyć przypadek użycia „Sprawdź użytkownika”, który zostanie zawarty w przypadku „przygotuj propozycję”. Razem z nim zawarte zostaną dwa inne przypadki użycia: „Użyj pakietu programów biurowych” i „Wyloguj się z sieci”. Dalsze rozważania prowadzą do stwierdzenia, że propozycje pisane dla nowych klientów różnią się od propozycji pisanych dla klientów dotychczasowych. W pierwszych umieszcza się materiały promocyjne i informacyjne o firmie. W drugim przypadku nie jest to potrzebne. A zatem przypadek użycia „Przygotuj propozycję” może zostać rozszerzony przez nowy przypadek – „Przygotuj propozycję dla nowego klienta”.

Przypadek użycia „Przygotuj propozycję” w modelu LAN firmy konsultingowej 8/9 Sprawdź użytkownika e d clu in Przygotuj propozycję extend Przygotuj propozycję dla nowego klienta include inc Użyj pakietu programów biurowych lud e Wyloguj się z sieci Ten przykład obrazuje bardzo istotną kwestię. Analiza przypadków użycia opisuje zachowanie systemu i nie ma nic wspólnego z implementacją.

Diagram klas dla działalności firmy konsultingowej 9/9 Konsultant 1 Pracuje nad 1. . * Projekt 1 1 1. . * Pisze Służy Prowadzi do 1. . * Klient Czyta 1 1. . * 1 1 Propozycja 1 Jest prezentowane Ukazuje się w 1. . * Raport 1. . * 1 Ukazuje się w 1. . * Dane