Inżynieria oprogramowania. Przypadki użycia. Piotr Miklosik Mirosław Ochodek

Transkrypt

1 Inżynieria oprogramowania Przypadki użycia Piotr Miklosik Mirosław Ochodek

2 Znaczenie wymagań Standish Group, CHAOS Report 1994 Problem % porażek Niekompletne wymagania 13,1 Niskie zaangażowanie klienta 12,4 Brak / niewystarczające zasoby 10,6 Nierealistyczne oczekiwania 9,9 Brak / niewystarczające wsparcie zarządzania projektem 9,3 Zmiany w wymaganiach 8,7 Brak / niewystarczające planowanie 8,1 Niepotrzebne wymagania 7,5 2

3 Znaczenie wymagań Standish Group, CHAOS Report 1994 Problem % porażek Niekompletne wymagania 13,1 Niskie zaangażowanie klienta 12,4 Brak / niewystarczające zasoby 10,6 Nierealistyczne oczekiwania 9,9 Brak / niewystarczające wsparcie zarządzania projektem 9,3 Zmiany w wymaganiach 8,7 Brak / niewystarczające planowanie 8,1 Niepotrzebne wymagania 7,5 3

4 Inżynieria wymagań Proces ustalenia usług, których klient wymaga od systemu oraz ograniczenia przy których system musi działać po wytworzeniu. Wymaganie jest opisem usługi systemu oraz ograniczeń, które zostały zdefiniowanie w ramach procesu inżynierii wymagań. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 6 4

5 Wymagania Funkcjonalne? Pozafunkcjonalne? 5

6 Analityk Udziałowcy Sponsor Kierownik Użytkownik Spójna, kompletna wizja Analityk SRS 6

7 Programista / projektant SRS System informatyczny 7

8 Cel wykładu Jak wygląda dobra specyfikacja wymagań funkcjonalnych? Jak ją przygotować? 8

9 Plan wykładu Przypadki użycia Metoda 9 kroków Jakość przypadków użycia Diagram przypadków użycia Zagadnienia dodatkowe dotyczące przypadków użycia 9

11 Poziomy wymagań Poziom biznesowy Współpraca ludzi, jednostek organizacyjnych, systemów zewnętrznych w celu osiągnięcia celu biznesowego 11

12 Poziomy wymagań Poziom biznesowy Poziom użytkownika Współpraca pomiędzy użytkownikiem a opisywanym systemem w celu osiągnięcia celu użytkownika 12

13 Poziomy wymagań Poziom biznesowy Poziom użytkownika Poziom podfunkcji Funkcje pośrednio wspierające cele użytkowników 13

14 Perspektywy wymagań Perspektywa systemu System powinien umożliwiać wyszukanie faktury po numerze faktury. Perspektywa użytkownika

15 System powinien Zalety:? Wady:? System powinien umożliwiać wystawienie faktury System powinien generować raport zestawienia faktur w roku System powinien uniemożliwiać dodanie faktury jeśli nie ma ona żadnej pozycji (i tak przez następne 200 stron)

16 System powinien Zalety: Łatwe w zapisie Wady: Trudno się czyta Trudno sprawdzić kompletność i spójność System powinien umożliwiać wystawienie faktury System powinien generować raport zestawienia faktur w roku System powinien uniemożliwiać dodanie faktury jeśli nie ma ona żadnej pozycji (i tak przez następne 200 stron)

17 Perspektywy wymagań Użytkownik Perspektywa chciałbysystemu wyszukać fakturę. W tym celu użytkownik wybiera opcję wyszukiwania i podaje numer faktury. System prezentuje... Perspektywa użytkownika

18 Podejścia do specyfikowania wymagań funkcjonalnych System powinien... Przypadki użycia System Autor Zgłoś artykuł Opowieści użytkowników 18

19 Opowieści użytkowników Jako użytkownik mogę zapłacić za zakupy kartą kredytową 19

20 Opowieści użytkowników Jako użytkownik mogę zapłacić za zakupy kartą kredytową 20

21 Opowieści użytkowników Testy akceptacyjne: zapłać kartą MasterCard płatność kartą płatniczą Visa płatność nieważną kartą 21

22 Proces użycia opowieści użytkownika Dostawca Klient Opowieści Klient Priorytety Pracochłonność Dostawca Testy akceptacyjne Klient Dostawca Konstrukcja Zakres wydania 22

23 Przypadek użycia System Autor Zgłoś artykuł Rodzaj historii, która przedstawia jak aktor (użytkownik lub urządzenie) współpracuje z systemem aby osiągnać dany cel 23

24 Opowieści użytkownika a przypadki użycia Autor System Przypadki użycia Zgłoś artykuł Opowieści użytkowników

25 Opowieści użytkownika a przypadki użycia Opowieści użytkowników Opowieści użytkowników Autor Autor System System Przypadki użycia Zgłoś artykuł Przypadki użycia Zgłoś artykuł

27 Dilbert: Zbieranie wymagań może być trudne (27)

28 Dilbert: Zbieranie wymagań może być trudne 28

35 Wykorzystanie wymagań 7% Zawsze używane 45% 19% 13% 16% Często używane Czasami używane Rzadko używane Nigdy nie używane (35)

36 Stracone uzasadnienie Potrzebujemy daną funkcjonalność? 36

37 Impleme ntacja Etap wstępny Zbieranie wymagań a model budżetu Stały zakres Stały budżet 37

38 Problem i propozycja rozwiązania Opis problemu Wiedza dziedzinowa Wymagania 38

39 Metoda 9 kroków 1. Określenie problemu 2. Zebranie wiedzy dziedzinowej identyfikacja obiektów informacyjnych Procesy biznesowe 3. Identyfikowanie aktorów (diagram kontekstu) 4. Identyfikowanie przypadków użycia (diagram przypadków użycia) 5. Definiowanie obiektów informacyjnych 6. Kompletność przypadków użycia 7. Opisanie scenariuszy przypadków użycia 8. Identyfikacja zdarzeń 9. Opisanie scenariuszy alternatywnych

40 1. Opis problemu Problem: Przyjmowanie artykułów konferencyjnych i komunikacja z recenzentami oraz autorami tylko za pomocą poczty elektronicznej ma wady: Rozproszenie ocen recenzentów między różne maile; Konieczność ręcznego rozsyłania informacji do członków KP i autorów. Rozwiązanie: Stworzyć aplikację internetową wspierającą komunikacje oraz proces recenzji i akceptacji artykułów konferencyjnych. 40

42 2. Zebranie wiedzy dziedzinowej BC1: Zgłoszenie artykułów na konferencję naukową Poziom: Biznesowy Aktorzy główni: Autor, Przewodniczący Komitetu Programowego (KP) Prolog Aktorzy pomocniczy: Komitet Programowy (KP) {Przewodniczący KP, Członek KP}, Recenzent 1. KP ustala zakres tematyczny konferencji, miejsce i termin. Scenariusz główny: 1. KP ogłasza nabór artykułów na konferencje. 2. *Autor zgłasza artykuł. 3. Przewodniczący KP przydziela artykuły do członków KP (Członek KP staje się Recenzentem). 4. *Recenzent przegląda artykuł. 5. *Przewodniczący KP akceptuje artykuł na podstawie recenzji. 6. Przewodniczący tworzy program konferencji. Epilog 1. Autor poprawia artykuł według wskazań recenzentów. Scenariusze alternatywne i rozszerzenia: 5.A. Artykuł nie spełnia kryteriów akceptacji na konferencję. 5.A.1. Przewodniczący KP odrzuca artykuł. Sytuacje wyjątkowe: 5.B. Przewodniczący KP stwierdza, że recenzje są niekompletne lub niespójne 5.B.1. Przewodniczący KP prosi recenzentów o wyjaśnienia. 5.B.2. Recenzent przekazuje wyjaśnienia Przewodniczącemu KP. Przejdź do kroku 5.

43 Wstępna identyfikacja Proces biznesowy Dokumenty prawne Przykładowe dokumenty

44 Identyfikacja obiektów informacyjnych Obiekty występujące w dziedzinie problemu Relacje pomiędzy obiektami Potencjalnie przekształcą się w model danych podstawa Glosariusza

45 2. Wiedza dziedzinowa Proces zgłaszania artykułów: 1.Komitet Programowy (KP) ogłasza nabór artykułów na konferencję 2.Autorzy zgłaszają artykuły 3.Przewodniczący KP przydziela artykuły do recenzentów z grona osób należących do KP 4.Recenzenci czytają i oceniają artykuły 5.Przewodniczący KP dokonuje decyzji o przyjęciu artykułów na podstawie ocen recenzentów 6.Przewodniczący KP tworzy program konferencji 45

46 Przypadek użycia Autor System Zgłoś artykuł Rodzaj historii, która przedstawia jak aktor (użytkownik osoba lub urządzenie) współpracuje z systemem z innymi aktorami aby osiągnać dany cel 46

47 Przypadek użycia Autor System Zgłoś artykuł Rodzaj historii, która przedstawia jak aktor (użytkownik osoba lub urządzenie) współpracuje z systemem z innymi aktorami aby osiągnać dany cel 47

48 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy 48

49 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej 49

50 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 50

51 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 51

52 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 52

53 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 53

54 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 54

55 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 5. Ubezpieczyciel wypłaca pieniądze Ubezpieczonemu. 55

56 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 5. Ubezpieczyciel wypłaca pieniądze Ubezpieczonemu. Rozszerzenia: 56

57 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 5. Ubezpieczyciel wypłaca pieniądze Ubezpieczonemu. Rozszerzenia: 1a. Przedstawione dane są niekompletne: 57

58 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 5. Ubezpieczyciel wypłaca pieniądze Ubezpieczonemu. Rozszerzenia: 1a. Przedstawione dane są niekompletne: 1a1. Ubezpieczyciel żąda podania brakujących danych. 1a2. Ubezpieczony dostarcza brakujące dane. 58

59 Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 5. Ubezpieczyciel wypłaca pieniądze Ubezpieczonemu. Rozszerzenia: 1a. Przedstawione dane są niekompletne: 1a1. Ubezpieczyciel żąda podania brakujących danych. 1a2. Ubezpieczony dostarcza brakujące dane. 2a. Ubezpieczony nie posiada ważnej polisy:... 59

60 Proces biznesowy Konferencja naukowa BC1: Zgłoszenie artykułów na konferencję naukową Poziom: Biznesowy Aktorzy główni: Autor, Przewodniczący Komitetu Programowego (KP) Aktorzy pomocniczy: Komitet Programowy (KP) {Przewodniczący KP, Członek KP}, Recenzent Prolog 1. KP ustala zakres tematyczny konferencji, miejsce i termin. Scenariusz główny: 1. KP ogłasza nabór artykułów na konferencje. 2. *Autor zgłasza artykuł. 3. Przewodniczący KP przydziela artykuły do członków KP (Członek KP staje się Recenzentem). 4. *Recenzent przegląda artykuł. 5. *Przewodniczący KP akceptuje artykuł na podstawie recenzji. 6. Przewodniczący tworzy program konferencji. Epilog 1. Autor poprawia artykuł według wskazań recenzentów. Scenariusze alternatywne i rozszerzenia: 5.A. Artykuł nie spełnia kryteriów akceptacji na konferencję. 5.A.1. Przewodniczący KP odrzuca artykuł. Sytuacje wyjątkowe: 5.B. Przewodniczący KP stwierdza, że recenzje są niekompletne lub niespójne 5.B.1. Przewodniczący KP prosi recenzentów o wyjaśnienia. 5.B.2. Recenzent przekazuje wyjaśnienia Przewodniczącemu KP. Przejdź do kroku 5.

62 3. Identyfikacja aktorów Autor 62

63 3. Identyfikacja aktorów Proces zgłaszania artykułów: 1. Komitet Programowy (KP) ogłasza nabór artykułów na konferencję 2. Autorzy zgłaszają artykuły 3. Przewodniczący KP przydziela artykuły do recenzentów z grona osób należących do KP 4. Recenzenci czytają i oceniają artykuły 5. Przewodniczący KP dokonuje decyzji o przyjęciu artykułów na podstawie ocen recenzentów 6. Przewodniczący KP tworzy program konferencji 63

64 Diagram kontekstu Dane Tworzony system Autor Aktor biznesowy 64

65 Diagram kontekstu Autor artykuł, recenzja Członek KP Administrator dane użytkowników Recenzent artykuł, recenzja System zarządzania konferencją naukową rezerwacja hotelu Uczestnik artykuł, recenzj, przydział recenzji, program konferencji rezerwacja hotelu Przewodniczący KP Rezerwator hoteli 65

66 Diagram kontekstu 66

67 Aktorzy i klasy użytkowników Urzędnik Autor Klasa użytkownika?= Aktor 68

68 Aktorzy i klasy użytkowników Rola w procesie Urzędnik Autor Klasa użytkownika?= Aktor 69

69 Aktorzy w przypadkach użycia Człowiek System Urządzenie 70

70 Aktorzy główni i pomocniczy Przypadek Aktor główny użycia: aktor, Przydziel którego cel recenzje zostanie osiągnięty (zwykle rozpoczyna interakcje) Przewodniczący KP System konferencyjny 71

71 Aktorzy główni i pomocniczy Aktor Przypadek pomocniczy użycia: wspiera Przydziel aktora recenzje głównego w osiągnięciu celu Przewodniczący KP Recenzent System konferencyjny 72

72 4. Identyfikacja przypadków użycia Czego ci aktorzy mogą chcieć? 73

73 4. Identyfikacja przypadków użycia Proces zgłaszania artykułów: 1. Komitet Programowy (KP) ogłasza nabór artykułów na konferencję 2. Autorzy zgłaszają artykuły 3. Przewodniczący KP przydziela artykuły do recenzentów z grona osób należących do KP 4. Recenzenci czytają i oceniają artykuły 5. Przewodniczący KP dokonuje decyzji o przyjęciu artykułów na podstawie ocen recenzentów 6. Przewodniczący KP tworzy program konferencji 74

74 4. Identyfikacja przypadków użycia Proces zgłaszania artykułów: 1. Komitet Programowy (KP) ogłasza nabór artykułów na konferencję 2. Autorzy zgłaszają artykuły 3. Przewodniczący KP przydziela artykuły do recenzentów z grona osób należących do KP 4. Recenzenci czytają i oceniają artykuły 5. Przewodniczący Autorzy mogą KP dokonuje chcieć zgłaszać decyzji o artykuły przyjęciu artykułów na podstawie ocen recenzentów Autor-> zgłoś artykuł 6. Przewodniczący KP tworzy program konferencji 75

75 Lista aktor-cel Autor Aktor Przewodniczący KP Recenzent Zgłosić artykuł Przeczytać recenzje Cel Ogłosić nabór artykułów Przydzielić recenzentów Poinformować autorów o decyzji Stworzyć program konferencji Zrecenzować artykuł 76

76 Lista aktor-cel Autor Aktor Przewodniczący KP Recenzent Zgłosić artykuł Przeczytać recenzje Cel Ogłosić nabór artykułów Przydzielić recenzentów Poinformować autorów o decyzji Stworzyć program konferencji Cele stają się tytułami przypadków użycia (Fraza czasownikowa strona czynna, cel) Zrecenzować artykuł 77

77 Diagramy przypadków użycia Prezentują aktorów i ich cele Prezentują powiązania pomiędzy przypadkami użycia Nie prezentują kolejności wykonywania System zarządzania konferencją naukową Zgłoś artykuł Autor 78

78 Diagramy przypadków użycia System zarządzania konferencją naukową Zgłoś artykuł Autor Autor uczestniczy w przypadku użycia Zgłoś artykuł Aktor i przypadki użycia, w których uczestniczy 79

79 Diagramy przypadków użycia Przewodniczący KP Przydziel recenzje z preferencjami Recenzent Co to oznacza? 80

80 Diagramy przypadków użycia Przewodniczący KP Przydziel recenzje z preferencjami Recenzent Przewodniczący KP i recenzent razem uczestniczą w przypadku użycia 81

81 Diagramy przypadków użycia System zarządzania konferencją naukową 82

82 Diagramy przypadków użycia System zarządzania konferencją naukową Autor 83

83 Diagramy przypadków użycia System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł 84

84 Diagramy przypadków użycia System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł Zrecenzuj artykuł Zarządzaj użytkownikami Administrator Recenzent Przydziel recenzje z preferencjami Przewodniczący KP Przydziel recenzje Zgłoś udział w konferencji Uczestnik Członek KP Akceptuj artykuł Rezerwuj hotel Rezerwator hoteli 85

85 5. Definicja obiektów informacyjnych Proces zgłaszania artykułów: 1.Komitet Programowy (KP) ogłasza nabór artykułów na konferencję 2.Autorzy zgłaszają artykuły 3.Przewodniczący KP przydziela artykuły do recenzentów z grona osób należących do KP 4.Recenzenci czytają i oceniają artykuły 5.Przewodniczący KP dokonuje decyzji o przyjęciu artykułów na podstawie ocen recenzentów 6.Przewodniczący KP tworzy program konferencji 86

86 5. Definicja obiektów informacyjnych Proces zgłaszania artykułów: 1.Komitet Programowy (KP) ogłasza nabór artykułów na konferencję Tytuł 2.Autorzy zgłaszają artykuły Autorzy 1..* (Imię i 3.Przewodniczący KP przydziela artykuły nazwisko ) do recenzentów z Abstrakt grona osób należących do KP Treść 4.Recenzenci czytają i oceniają artykuły Literatura 0..* (Artykuł, ) 5.Przewodniczący KP dokonuje decyzji o przyjęciu artykułów na podstawie ocen recenzentów 6.Przewodniczący KP tworzy program konferencji 87

88 6. Kompletność listy celów obiekt dziedzinowy Artykuł Recenzja... Macierz CRUD(L) K. E. Wiegers. Software Requirements. Microsoft Press, Redmond, WA, USA, 2nd edition,

89 6. Kompletność listy celów Przypadek użycia / obiekt dziedzinowy Artykuł Recenzja... Zgłoś artykuł Czytaj artykuł Przeczytaj recenzję... Macierz CRUD(L) K. E. Wiegers. Software Requirements. Microsoft Press, Redmond, WA, USA, 2nd edition,

90 6. Kompletność listy celów Przypadek użycia / obiekt dziedzinowy Artykuł Recenzja... Zgłoś artykuł C, U... Czytaj artykuł R Przeczytaj recenzję R Macierz CRUD(L) K. E. Wiegers. Software Requirements. Microsoft Press, Redmond, WA, USA, 2nd edition,

91 6. Kompletność listy celów Przypadek użycia / obiekt dziedzinowy Artykuł Recenzja... Zgłoś artykuł C, U... Czy lista typów operacji jest Czytaj artykuł R kompletna? Przeczytaj recenzję R Macierz CRUD(L) K. E. Wiegers. Software Requirements. Microsoft Press, Redmond, WA, USA, 2nd edition,

93 7. Scenariusz główny UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. 94

94 Warunki pre i post oraz wyzwalacze Warunkie wstępne (pre) Stan stystemu przed rozpoczęciem przypadku Warunki końcowe (post) Stan systemu po zakończeniu przypadku Wyzwalacze Kiedy / w jakich warunkach przypadek użycia jest wykonywany Konieczne?

95 Warunki pre i post oraz wyzwalacze UC: Przeczytaj recenzję Warunki wstępne? Warunki końcowe? Wyzwalacze?

96 Warunki pre i post oraz wyzwalacze UC: Przeczytaj recenzję Warunki wstępne Autor jest zalogowany do systemu Autor zgłosił przynajmniej jeden artykuł Warunki końcowe Recenzje artykułu zostały zaprezentowane autorowi (lub informacja o braku recenzji) Wyzwalacze Autor wybrał opcję przeglądania recenzji dla artykułu Recenzent wybrał opcję pobrania artykułu do recenzji

97 Scenariusz główny Najbardziej typowy scenariusz osiągnięcia celu Prezentuje interakcję pomiędzy aktorami i opisywanym systemem Strona czynna: Podmiot / Orzeczenie / Dopełnienie Przewodniczący KP wybiera opcję dodania recenzji Zwykle prezentowane jako lista numerowana albo diagram czynności UML 98

98 Scenariusz główny UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. 99

99 Scenariusz główny Autor 1. Autor wybiera opcję zgłoszenia artykułu 3. Autor podaje wymagane dane na temat artykułu. System 2. System prosi o podanie danych artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu 100

100 Scenariusz główny Autor wybiera opcję zgłoszenia artykułu. System prosi o podanie danych artykułu. Autor podaje wymagane dane na temat artykułu. System informuje o pomyślnym zgłoszeniu artykułu. UC1: Zgłoś artykuł 101

101 Scenariusze alternatywne 8. Identyfikacja zdarzeń 9. Opisanie scenariuszy alternatywnych 102

102 Scenariusze alternatywne UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. Czy można coś zrobić w inny sposób? Czy coś może pójść nie tak? 4. System informuje o pomyślnym zgłoszeniu artykułu. Czy można zrobić coś dodatkowego? 103

103 Scenariusze alternatywne Scenariusze alternatywne Inne sposoby osiągnięcia celu Rozszerzenia Dodatkowe czynności, które można wykonać w trakcie wykonywania scenariusza głównego Sytuacje wyjątkowe Zdarzenie wyjątkowe (np. błędy) 104

104 Scenariusze alternatywne Scenariusze alternatywne Inne sposoby osiągnięcia celu Rozszerzenia Dodatkowe czynności, które można wykonać w trakcie wykonywania scenariusza głównego Scenariusze alternatywne i rozszerzenia są często trudne do rozróżnienia Zdarzenie wyjątkowe (np. błędy) Sytuacje wyjątkowe 105

105 Scenariusze alternatywne UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. Scenariusze alternatywne i rozszerzenia: 1.A. Author chciałby zgłosić zmienioną wersję artykułu. Zdarzenie lub warunek 106

106 Scenariusze alternatywne UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. Scenariusze alternatywne i rozszerzenia: 1.A. Author chciałby zgłosić zmienioną wersję artykułu. 107

107 Scenariusze alternatywne UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. Scenariusze alternatywne i rozszerzenia: 1.A. Author chciałby zgłosić zmienioną wersję artykułu. 1.A.1. Autor wybiera opcję ponownego zgłoszenia swoich artykułów. 1.A.2. System prezentuje artykuły zgłoszone dotychczas przez Autora. 1.A.3. Autor wybiera jeden z artykułów oraz opcję jego ponownego zgłoszenia. 1.A.4. Przejdź do kroku

108 Scenariusze alternatywne UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. Scenariusze alternatywne i rozszerzenia: 1.A. Author chciałby zgłosić zmienioną wersję artykułu. 1.A.1. Autor wybiera opcję ponownego zgłoszenia swoich artykułów. 1.A.2. System prezentuje artykuły zgłoszone dotychczas przez Autora. 1.A.3. Autor wybiera jeden z artykułów oraz opcję jego ponownego zgłoszenia. 1.A.4. Przejdź do kroku

109 Scenariusze alternatywne UC1: Zgłoś artykuł Poziom: Użytkownika Aktor główny: Autor Scenariusz główny: 1. Autor wybiera opcję zgłoszenia artykułu. 2. System prosi o podanie danych artykułu. 3. Autor podaje wymagane dane na temat artykułu. 4. System informuje o pomyślnym zgłoszeniu artykułu. Scenariusze alternatywne i rozszerzenia: 1.A. Author chciałby zgłosić zmienioną wersję artykułu. 1.A.1. Autor wybiera opcję ponownego zgłoszenia swoich artykułów. 1.A.2. System prezentuje artykuły zgłoszone dotychczas przez Autora. 1.A.3. Autor wybiera jeden z artykułów oraz opcję jego ponownego zgłoszenia. 1.A.4. Przejdź do kroku 2. Sytuacje wyjątkowe: 3.A. Nie podano wszystkich wymaganych danych. 3.A.1. System informuje o błędzie. 3.A.2. Przejdź do kroku

111 Czy to jest dobry przypadek? UC1kz. Rozpoczęcie procesu tworzenia zgłoszenia. Aktorzy: Zgłaszający Scenariusz główny: 1. Zgłaszający wybiera opcję utworzenia Zgłoszenia 2. System prezentuje Formularz Zgłoszenia 3. Użytkownik uzupełnia pola formularza 4. Zgłaszający wybiera przycisk zapisu. Scenariusz alternatywny: 3.A.. W systemie istnieje co najmniej jedno Zgłoszenia aktywne lub edytowalne dla podanego w formularzu urządzenia drukującego. E.3.1. Wykonanie przypadku UC4kz. E.3.2. System prezentuje zapytanie Czy mimo wszystko kontynuować tworzenie Zgłoszenia? E.3.3. Zgłaszający wybiera opcję Tak/Anuluj lub opcję Nie. E.3.4. Jeżeli wybrano opcję Tak/Anuluj System zamyka okno i następuje kontynuacja w punkcie 3. scenariusza głównego. W przeciwnym wypadku formularz zgłoszenia jest wyłączany i przerwane jest wykonywanie przypadku użycia. 112

112 Wzorce przypadków użycia Nazwy przypadków użycia Pracownik Przypadek #1 Wprowadzenie kodu Zatrudnianie pracownika Zwalnianie pracownika Transakcje wartościowe dla użytkownika Zidentyfikuj wartościowe usługi, jakie system dostarcza aktorom, aby osiągnęli swoje cele biznesowe. 113

113 Czy to jest dobry przypadek? UC1kz. Rozpoczęcie procesu tworzenia zgłoszenia. Stworzenie zgłoszenia Aktorzy: Zgłaszający Scenariusz główny: 1. Zgłaszający wybiera opcję utworzenia Zgłoszenia 2. System prezentuje Formularz Zgłoszenia 3. Użytkownik uzupełnia pola formularza 4. Zgłaszający wybiera przycisk zapisu. Scenariusz alternatywny: 3.A.. W systemie istnieje co najmniej jedno Zgłoszenia aktywne lub edytowalne dla podanego w formularzu urządzenia drukującego. E.3.1. Wykonanie przypadku UC4kz. E.3.2. System prezentuje zapytanie Czy mimo wszystko kontynuować tworzenie Zgłoszenia? E.3.3. Zgłaszający wybiera opcję Tak/Anuluj lub opcję Nie. E.3.4. Jeżeli wybrano opcję Tak/Anuluj System zamyka okno i następuje kontynuacja w punkcie 3. scenariusza głównego. W przeciwnym wypadku formularz zgłoszenia jest wyłączany i przerwane jest wykonywanie przypadku użycia. 114

114 Wzorce przypadków użycia Osiągnięty zamiar aktora Opisuj każdy krok tak, by jasno pokazać, jaki aktor wykonuje akcję i co przez to osiąga. 115

115 Czy to jest dobry przypadek? UC1kz. Rozpoczęcie procesu tworzenia zgłoszenia. Stworzenie zgłoszenia Aktorzy: Zgłaszający Scenariusz główny: 1. Zgłaszający wybiera opcję utworzenia Zgłoszenia 2. System prezentuje Formularz Zgłoszenia 3. Użytkownik Zgłaszający uzupełnia pola formularza 4. Zgłaszający wybiera przycisk zapisu. Scenariusz alternatywny: 3.A.. W systemie istnieje co najmniej jedno Zgłoszenia aktywne lub edytowalne dla podanego w formularzu urządzenia drukującego. E.3.1. Wykonanie przypadku UC4kz. E.3.2. System prezentuje zapytanie Czy mimo wszystko kontynuować tworzenie Zgłoszenia? E.3.3. Zgłaszający wybiera opcję Tak/Anuluj lub opcję Nie. E.3.4. Jeżeli wybrano opcję Tak/Anuluj System zamyka okno i następuje kontynuacja w punkcie 3. scenariusza głównego. W przeciwnym wypadku formularz zgłoszenia jest wyłączany i przerwane jest wykonywanie przypadku użycia. 116

116 Wzorce przypadków użycia Unikaj opisu obiektu w kroku Nie prezentuj szczegółowego opisu obiektu informacyjnego (lub jego podzbioru) jeśli informacja ta nie jest kluczowa. 117

118 Wzorce przypadków użycia Neutralność technologiczna Zapisuj każdy przypadek użycia w sposób neutralny technologicznie. System zadaje zapytanie SQL do bazy MySQL i wyświetla pobraną listę artykułów. 119

119 Wzorce przypadków użycia Osobno opisane reguły biznesowe przypadku skomplikowanych reguł decyzyjnych unikaj ich opisywania w krokach przypadku użycia. Opisz je osobno jako reguły biznesowe. 120

120 Wzorce przypadków użycia Czytelność opisów Przypadek użycia powinien być zrozumiały dla programistów ORAZ klienta. Opisy powinny być zwięzłe, czytelne i jednoznaczne. 121

122 Wzorce przypadków użycia Opis zachowania Przypadki użycia służą do opisu zachowania. Interfejs użytkownika powinien być opisany gdzie indziej. 123

124 Wzorce przypadków użycia Długość przypadku użycia Przypadek użycia powinien mieć od 3 do 9 kroków. 125

125 Wzorce przypadków użycia Wykrywalne warunki Warunki opisane w przypadku użycia powinny być możliwe do wykrycia przez system Użytkownik podaje cudze imię 126

127 Relacje pomiędzy przypadkami System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł Zrecenzuj artykuł Zarządzaj użytkownikami Administrator Recenzent Przydziel recenzje z preferencjami Przewodniczący KP Przydziel recenzje Zgłoś udział w konferencji Uczestnik Członek KP Akceptuj artykuł Rezerwuj hotel Rezerwator hoteli 128

128 Relacje pomiędzy przypadkami System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł Zrecenzuj artykuł Zarządzaj użytkownikami Administrator Recenzent Przydziel recenzje z preferencjami Przeczytaj artykuł Przewodniczący KP Przydziel recenzje Zgłoś udział w konferencji Uczestnik Członek KP Akceptuj artykuł Rezerwuj hotel Rezerwator hoteli 129

129 Relacje pomiędzy przypadkami System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł Zrecenzuj artykuł «includes» Zarządzaj użytkownikami Administrator Recenzent Przydziel recenzje z preferencjami Przeczytaj artykuł Przewodniczący KP Przydziel recenzje Zgłoś udział w konferencji Uczestnik Członek KP Akceptuj artykuł Rezerwuj hotel Rezerwator hoteli 130

130 Relacje pomiędzy przypadkami Relacja zawierania jest wykorzystywana kiedy kilka przypadków użycia współdzieli wspólny podcel. W celu uniknięcia duplikowania tego samego zapisu tworzy się osobny przypadek użycia, który opisuje wspólną funkcjonalność, natomiast pozostałe przypadki użycia zawierają w swoich scenariuszach odwołanie do wyodrębnionego przypadku użycia. 131

131 Relacje pomiędzy przypadkami Zrecenzuj artykuł «includes» Przeczytaj artykuł Recenzent UC2: Zrecenzuj artykuł Poziom: Użytkownika Aktor główny: Recenzent Scenariusz główny: 1. Recenzent wybiera opcję przeglądania przypisanych do niego artykułów. 2. System prezentuje artykuły przypisane do recenzenta. 3. Recenzent wybiera artykuł oraz opcję rozpoczęcia recenzji. 4. System prezentuje zbiorcze informacje o artykule. 5. Recenzent czyta artykuł [UC4:Przeczytaj artykuł]. 6. Recenzent wybiera opcję dodania recenzji. 7. System prosi o podanie recenzji. 8. Recenzent podaje treść recenzji. 9. System informuje o pomyślnym zapisaniu recenzji. Scenariusze alternatywne i rozszerzenia Sytuacje wyjątkowe: 8.A. Nie podano wszystkich wymaganych danych. 8.A.1. System informuje o błędzie. 8.A.2. Przejdź do kroku

132 Relacje pomiędzy przypadkami Zrecenzuj artykuł «includes» Przeczytaj artykuł Recenzent UC2: Zrecenzuj artykuł Poziom: Użytkownika Aktor główny: Recenzent Scenariusz główny: 1. Recenzent wybiera opcję przeglądania przypisanych do niego artykułów. 2. System prezentuje artykuły przypisane do recenzenta. 3. Recenzent wybiera artykuł oraz opcję rozpoczęcia recenzji. 4. System prezentuje zbiorcze informacje o artykule. 5. Recenzent czyta artykuł [UC4:Przeczytaj artykuł]. 6. Recenzent wybiera opcję dodania recenzji. 7. System prosi o podanie recenzji. 8. Recenzent podaje treść recenzji. 9. System informuje o pomyślnym zapisaniu recenzji. Scenariusze alternatywne i rozszerzenia Sytuacje wyjątkowe: 8.A. Nie podano wszystkich wymaganych danych. 8.A.1. System informuje o błędzie. 8.A.2. Przejdź do kroku

133 Relacje pomiędzy przypadkami System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł Zrecenzuj artykuł «includes» Zarządzaj użytkownikami Administrator Recenzent Przydziel recenzje z preferencjami Przeczytaj artykuł Przewodniczący KP Przydziel recenzje Zgłoś udział w konferencji Uczestnik Członek KP Akceptuj artykuł Rezerwuj hotel Rezerwator hoteli 134

134 Relacje pomiędzy przypadkami System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł Zrecenzuj artykuł «includes» Zarządzaj użytkownikami Administrator Recenzent Przydziel recenzje z preferencjami «extends» Przeczytaj artykuł Przewodniczący KP Przydziel recenzje Zgłoś udział w konferencji «extends» Uczestnik Członek KP Akceptuj artykuł Rezerwuj hotel Rezerwator hoteli 135

135 Relacje pomiędzy przypadkami Relacja rozszerzania oznacza, że scenariusz przypadku użycia może zostać wzbogacony o scenariusz innego przypadku użycia w określonym kroku jego wykonania. 136

136 Relacje pomiędzy przypadkami UC4: Przydziel recenzje Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: 1. Przewodniczący KP wybiera opcję przeglądania zgłoszonych artykułów. 2. System prezentuje zgłoszone artykuły. 3. Przewodniczący KP wybiera artykuł. 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę potencjalnych recenzentów. 5. Przewodniczący PK wybiera recenzentów i zatwierdza. 6. System potwierdza przypisanie recenzentów do artykułu. Scenariusze alternatywne i rozszerzenia: 4.A. Przewodniczący KP chciałby przeczytać artykuł zanim przydzieli recenzentów do jego recenzji. 4.A.1. Przewodniczący KP czyta artykuł [UC3:Przeczytaj artykuł]. 4.A.2. Przejdź do kroku 5. Sytuacje wyjątkowe: Przewodniczący KP Przydziel recenzje Przeczytaj artykuł «extends» 137

137 Relacje pomiędzy przypadkami UC4: Przydziel recenzje Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: 1. Przewodniczący KP wybiera opcję przeglądania zgłoszonych artykułów. 2. System prezentuje zgłoszone artykuły. 3. Przewodniczący KP wybiera artykuł. 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę potencjalnych recenzentów. 5. Przewodniczący PK wybiera recenzentów i zatwierdza. 6. System potwierdza przypisanie recenzentów do artykułu. Scenariusze alternatywne i rozszerzenia: 4.A. Przewodniczący KP chciałby przeczytać artykuł zanim przydzieli recenzentów do jego recenzji. 4.A.1. Przewodniczący KP czyta artykuł [UC3:Przeczytaj artykuł]. 4.A.2. Przejdź do kroku 5. Sytuacje wyjątkowe: Przewodniczący KP Przydziel recenzje Przeczytaj artykuł «extends» 138

138 Relacje pomiędzy przypadkami UC4: Przydziel recenzje Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: 1. Przewodniczący KP wybiera opcję przeglądania zgłoszonych artykułów. 2. System prezentuje zgłoszone artykuły. 3. Przewodniczący KP wybiera artykuł. 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę potencjalnych recenzentów. <extension point: przed-przydzialem> 5. Przewodniczący PK wybiera recenzentów i zatwierdza. 6. System potwierdza przypisanie recenzentów do artykułu. Scenariusze alternatywne i rozszerzenia: Sytuacje wyjątkowe: Przewodniczący KP «extends» przed-przydzialem Przydziel recenzje Extension Point przed-przydzialem Przeczytaj artykuł 139

141 Relacje pomiędzy przypadkami Relacja generalizacji / specjalizacji pozwala zdefiniować szczególny przypadek danego przypadku użycia poprzez zdefiniowanie różnic w stosunku do przypadku bazowego. 142

142 Relacje pomiędzy przypadkami Przewodniczący KP Przydziel recenzje Przydziel recenzje z preferencjami UC4: Przydziel recenzje Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: 1. Przewodniczący KP wybiera opcję przeglądania zgłoszonych artykułów. 2. System prezentuje zgłoszone artykuły. 3. Przewodniczący KP wybiera artykuł. 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę potencjalnych recenzentów. 5. Przewodniczący PK wybiera recenzentów i zatwierdza. 6. System potwierdza przypisanie recenzentów do artykułu. Scenariusze alternatywne i rozszerzenia: 4.A. Przewodniczący KP chciałby przeczytać artykuł zanim przydzieli recenzentów do jego recenzji. 4.A.1. Przewodniczący KP czyta artykuł [UC3:Przeczytaj artykuł]. 4.A.2. Przejdź do kroku 5. Sytuacje wyjątkowe: UC5: Przydziel recenzje z preferencjami <specjalizacja UC4> Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: Przed rozpoczęciem wykonywania scenariusza głównego każdy z recenzentów zgłasza swoje preferencje co do recenzowania poszczególnych artykułów [UC6:Określ preferencje recenzji artykułu]. W kroku czwartym bazowego przypadku użycia UC4: 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę recenzentów, którzy zgłosili chęć recenzji artykułu oraz listę pozostałych recenzentów. Scenariusze alternatywne i rozszerzenia: Sytuacje wyjątkowe: 143

143 Relacje pomiędzy przypadkami Przewodniczący KP Przydziel recenzje Przydziel recenzje z preferencjami UC4: Przydziel recenzje Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: 1. Przewodniczący KP wybiera opcję przeglądania zgłoszonych artykułów. 2. System prezentuje zgłoszone artykuły. 3. Przewodniczący KP wybiera artykuł. 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę potencjalnych recenzentów. 5. Przewodniczący PK wybiera recenzentów i zatwierdza. 6. System potwierdza przypisanie recenzentów do artykułu. Scenariusze alternatywne i rozszerzenia: 4.A. Przewodniczący KP chciałby przeczytać artykuł zanim przydzieli recenzentów do jego recenzji. 4.A.1. Przewodniczący KP czyta artykuł [UC3:Przeczytaj artykuł]. 4.A.2. Przejdź do kroku 5. Sytuacje wyjątkowe: UC5: Przydziel recenzje z preferencjami <specjalizacja UC4> Poziom: Użytkownika Aktor główny: Przewodniczący KP Scenariusz główny: Przed rozpoczęciem wykonywania scenariusza głównego każdy z recenzentów zgłasza swoje preferencje co do recenzowania poszczególnych artykułów [UC6:Określ preferencje recenzji artykułu]. W kroku czwartym bazowego przypadku użycia UC4: 4. System prezentuje zbiorcze informacje o artykule oraz prezentuje listę recenzentów, którzy zgłosili chęć recenzji artykułu oraz listę pozostałych recenzentów. Scenariusze alternatywne i rozszerzenia: Sytuacje wyjątkowe: 144

144 Relacja <<uses>> Wywołanie jednego przypadku użycia w ramach innego przypadku użycia Nie ma podanej przyczyny (zawierania czy rozszerzania) 145

145 Dobre praktyki Jeden obraz mówi tyle co 1000 słów Jeden diagram z 1000 przypadków użycia nic nie mówi DPU jest po to aby pomagać, a nie przeszkadzać Ogranicz liczbę przypadków użycia na jednym diagramie do kilku Nie staraj się przedstawić na diagramie wymagań dla całego systemu warto ograniczyć się do pojedynczego modułu / aspektu systemu 146

146 Dobre praktyki Jeśli pracujesz głównie z DPU Miej na uwadze treść przypadków użycia kiedy tworzysz diagram DPU nie przedstawia kolejności przypadków użycia Wielu aktorów powiązanych z przypadkiem użycia nie oznacza, że wszyscy oni mają dostęp do przypadku użycia, ale to że biorą w nim udział 147

148 CRUD Załóżmy, że z artykułem można wykonać: Zgłosić artykuł Anulować zgłoszenie Zmodyfikować zgłoszony artykuł Przeczytać artykuł C-reate, R-etrieve, U-pdate, D-elete 149

149 CRUD 150

150 CRUD 151

151 Warianty Dodaj komentarz Dodaj artykuł Dodaj wiadomość Dodaj wiadomość Dodaj wiadomość Dodaj wiadomość 152

152 UC1: Dodaj <Obiekt CMS> Poziom: Użytkownika Aktor główny: Użytkownik Scenariusz główny: 1. Użytkownik wybiera opcję dodania <Obiekt CMS>. 2. System prosi o podanie danych <Obiekt CMS>. 3. Użytkownik podaje dane <Obiekt CMS>. 4. System potwierdza, że <Obiekt CMS> został poprawnie zapisany. Scenariusze alternatywne i rozszerzenia: Sytuacje wyjątkowe: 3.A. Nie podano wszystkich wymaganych dla <Obiekt CMS>. 3.A.1. System informuje o błędzie. 3.A.2. Przejdź do kroku 2. Warianty <Obiekt CMS> to komentarz, artykuł, wiadomość, itd. 153

153 Pytania 154