Inżynieria oprogramowania Przypadki użycia Piotr Miklosik piotr.miklosik@put.poznan.pl Mirosław Ochodek Miroslaw.Ochodek@cs.put.poznan.pl
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
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
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
Wymagania Funkcjonalne? Pozafunkcjonalne? 5
Analityk Udziałowcy Sponsor Kierownik Użytkownik Spójna, kompletna wizja Analityk SRS 6
Programista / projektant SRS System informatyczny 7
Cel wykładu Jak wygląda dobra specyfikacja wymagań funkcjonalnych? Jak ją przygotować? 8
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
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 10
Poziomy wymagań Poziom biznesowy Współpraca ludzi, jednostek organizacyjnych, systemów zewnętrznych w celu osiągnięcia celu biznesowego 11
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
Poziomy wymagań Poziom biznesowy Poziom użytkownika Poziom podfunkcji Funkcje pośrednio wspierające cele użytkowników 13
Perspektywy wymagań Perspektywa systemu System powinien umożliwiać wyszukanie faktury po numerze faktury. Perspektywa użytkownika
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)
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)
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
Podejścia do specyfikowania wymagań funkcjonalnych System powinien... Przypadki użycia System Autor Zgłoś artykuł Opowieści użytkowników 18
Opowieści użytkowników Jako użytkownik mogę zapłacić za zakupy kartą kredytową 19
Opowieści użytkowników Jako użytkownik mogę zapłacić za zakupy kartą kredytową 20
Opowieści użytkowników Testy akceptacyjne: zapłać kartą MasterCard płatność kartą płatniczą Visa płatność nieważną kartą 21
Proces użycia opowieści użytkownika Dostawca Klient Opowieści Klient Priorytety Pracochłonność Dostawca Testy akceptacyjne Klient Dostawca Konstrukcja Zakres wydania 22
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
Opowieści użytkownika a przypadki użycia Autor System Przypadki użycia Zgłoś artykuł Opowieści użytkowników
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ł
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 26
Dilbert: Zbieranie wymagań może być trudne (27)
Dilbert: Zbieranie wymagań może być trudne 28
Dilbert: Zbieranie wymagań może być trudne 29
Dilbert: Zbieranie wymagań może być trudne 30
Dilbert: Zbieranie wymagań może być trudne 31
Dilbert: Zbieranie wymagań może być trudne 32
Dilbert: Zbieranie wymagań może być trudne 33
Dilbert: Zbieranie wymagań może być trudne 34
Wykorzystanie wymagań 7% Zawsze używane 45% 19% 13% 16% Często używane Czasami używane Rzadko używane Nigdy nie używane http://www.betterprojects.net/2009/03/waste-in-requirements.html (35)
Stracone uzasadnienie Potrzebujemy daną funkcjonalność? 36
Impleme ntacja Etap wstępny Zbieranie wymagań a model budżetu Stały zakres Stały budżet 37
Problem i propozycja rozwiązania Opis problemu Wiedza dziedzinowa Wymagania 38
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
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
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
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.
Wstępna identyfikacja Proces biznesowy Dokumenty prawne Przykładowe dokumenty
Identyfikacja obiektów informacyjnych Obiekty występujące w dziedzinie problemu Relacje pomiędzy obiektami Potencjalnie przekształcą się w model danych podstawa Glosariusza
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
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
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
Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy 48
Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej 49
Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 50
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
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
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
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
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
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
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
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
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
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.
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
3. Identyfikacja aktorów Autor 62
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
Diagram kontekstu Dane Tworzony system Autor Aktor biznesowy 64
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
Diagram kontekstu 66
Aktorzy i klasy użytkowników Urzędnik Autor Klasa użytkownika?= Aktor 68
Aktorzy i klasy użytkowników Rola w procesie Urzędnik Autor Klasa użytkownika?= Aktor 69
Aktorzy w przypadkach użycia Człowiek System Urządzenie 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
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
4. Identyfikacja przypadków użycia Czego ci aktorzy mogą chcieć? 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
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
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
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
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ą 1 0..1 Zgłoś artykuł Autor 78
Diagramy przypadków użycia System zarządzania konferencją naukową 1 0..1 Zgłoś artykuł Autor Autor uczestniczy w przypadku użycia Zgłoś artykuł Aktor i przypadki użycia, w których uczestniczy 79
Diagramy przypadków użycia Przewodniczący KP Przydziel recenzje z preferencjami Recenzent Co to oznacza? 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
Diagramy przypadków użycia System zarządzania konferencją naukową 82
Diagramy przypadków użycia System zarządzania konferencją naukową Autor 83
Diagramy przypadków użycia System zarządzania konferencją naukową Przeczytaj recenzję Autor Zgłoś artykuł 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
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
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
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
6. Kompletność listy celów obiekt dziedzinowy Artykuł Recenzja... Macierz CRUD(L) K. E. Wiegers. Software Requirements. Microsoft Press, Redmond, WA, USA, 2nd edition, 2003. 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, 2003. 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, 2003. 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, 2003. 92
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
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
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?
Warunki pre i post oraz wyzwalacze UC: Przeczytaj recenzję Warunki wstępne? Warunki końcowe? Wyzwalacze?
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
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
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
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
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
Scenariusze alternatywne 8. Identyfikacja zdarzeń 9. Opisanie scenariuszy alternatywnych 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
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
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
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
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
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. 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 2. 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 2. 110
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 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
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
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
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
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
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
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. 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
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
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
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. 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
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. 124
Wzorce przypadków użycia Długość przypadku użycia Przypadek użycia powinien mieć od 3 do 9 kroków. 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
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 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
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
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
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
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 7. 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 7. 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
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
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
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
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
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
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 140
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 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
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
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
Relacja <<uses>> Wywołanie jednego przypadku użycia w ramach innego przypadku użycia Nie ma podanej przyczyny (zawierania czy rozszerzania) 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
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
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 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
CRUD 150
CRUD 151
Warianty Dodaj komentarz Dodaj artykuł Dodaj wiadomość Dodaj wiadomość Dodaj wiadomość Dodaj wiadomość 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
Pytania 154