Jak pisać przypadki użycia
Jolanta Sala Halina Tańska
2018/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.
Zakup towaru
Rodzaj:
Główny lub alternatywne Opis :
Kroki scenariusza
Scenariusz - przykład
Scenariusz - przykład „zakup towaru”
• 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.
1/2
Scenariusz - przykład „zakup towaru”
• 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.
2/2
Scenariusz to droga od celu do rezultatu
Cel
Rezultat
Scenariusz alternatywny
SA1
Scenariusz alternatywny
SA2
Scenariusz alternatywny
SA3
Zakres
• 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ędzianarzędzia do śledzenia i panowania nad dyskusjami o zakresie – listę w-poza.
• Narzędzie lista w-poza to tabela z trzema kolumnami. Lewa Narzędzie lista w-poza 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 ww czy pozapoza.
• 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 w zakresie prac od tych, poza poza
zakresem zakresem.
• Wracaj do niej, ilekroć wydaje ci się, że dyskusja schodzi na
manowce albo gdy dyskutowane jest wymaganiewymaganie, dla którego nie ma miejsca.
1/3
Tabela. Przykładowa lista w-poza
Temat W Poza
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.
2/3
Zakres funkcjonalny
• 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 nie 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-pozalista 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 lista aktor-cel
– szkice przypadków użycia.szkice przypadków użycia
3/3
Lista aktor-cel
• 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.
1/2
Tabela. Przykładowa lista Aktor-cel system śledzenia zleceń
Aktor Cel 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.
2/2
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ę obszaru
administracyjnego
Personel produkcyjny dodaje metadane obszaru administracyjnego (hierarchia administracyjna, 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
• 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.
1/5
Brak systemu w PU
• Przypadek użycia: Pobierz gotówkę
• Zakres: Bankomat
• Aktor główny: 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.
klient
2/5
PU – brak aktora głównego
• Przypadek użycia: Pobierz gotówkę
• Zakres: Bankomat
• Aktor główny: klient
1. Pobiera kartę bankomatową i hasło
2. Dowiaduje się, że typ transakcji to „Wypłata”
3. Dowiaduje się o wielkości żądanej kwoty
4. Stwierdza, że na koncie są wystarczające środki 5. Wydaje pieniądze, potwierdzenie i kartę
6. 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ę.
klient
3/5
klient
PU – korekta zbyt wiele szczegółów interfejsu
• Przypadek użycia: Kup towar
• Zakres: Aplikacja obsługująca sprzedaż
• Aktor główny: Klient
1. Klient przekazuje systemowi identyfikator i hasło
2. System stwierdza poprawność identyfikacji użytkownika 3. Użytkownik udostępnia nazwisko, adres, numer telefonu 4. System stwierdza, że użytkownik jest mu znany
5. Użytkownik wybiera towary i ilości
6. 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.
4/5
PU – zbyt wiele szczegółów interfejsu użytkownika
klient
• Przypadek użycia: Kup towar
• Zakres: Aplikacja obsługująca sprzedaż
• Aktor główny: 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.
5/5
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 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.
1/9
Poznanie domeny
• 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.
2/9
Zrozumienie użytkowników
• 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.
3/9
Hierarchia użytkowników sieci LAN
Pracodawca
Członek zarządu
Menedżer Konsultant Urzędnik
Kierownik biura
Menedżer projektu
Administrator sieci
4/9 Metoda
z góry do dołu
Metoda z dołu do góry
Zrozumienie przypadków
Lista przypadków:
„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”.
5/9
Diagram przypadków użycia wysokiego poziomu sieci LAN firmy konsultingowej
Członek zarządu
Konsultant Kierownik biura
Menedżer projektu
Administrator sieci
Urzędnik
Połącz się z zewnątrz
Przygotuj propozycję
Zapewnij poziom bezpieczeństwa
Zapisz propozycję
Współużytkuj bazę danych
Korzystaj z Poprzednich
propozycji Połącz się z internetem
Użyj poczty elektronicznej
Zrób katalog propozycji
Współużytkuj drukarkę
6/9
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.
– 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”.
7/9
Przygotuj propozycję
Sprawdź użytkownika
Użyj pakietu
programów biurowych
Wyloguj się z sieci Przygotuj propozycję
dla nowego klienta
include
include
include extend
Przypadek użycia „Przygotuj propozycję” w modelu LAN firmy konsultingowej
Ten przykład obrazuje bardzo istotną kwestię. Analiza przypadków użycia opisuje zachowanie systemu i nie ma nic wspólnego z implementacją.
8/9
Konsultant Projekt
Klient
Raport
Propozycja
Dane
Pracuje nad
Czyta
Prowadzi do
Ukazuje się w Służy
Jest prezentowane
Ukazuje się w 1
1..*
1
1 1 1
1
1
1 1..*
1..*
1..*
1..*
1..*
1..*
1..*
Pisze
Diagram klas dla działalności firmy konsultingowej
9/9
