plik


10/7/2012 MODEL USE CASE Model Use Case Przedstawia system z punktu widzenia u|ytkownika (r|nych klas u|ytkownikw systemu). Bibliografia: Modeluje zachowanie systemu w odpowiedzi na polecenia u|ytkownika. A. Cockburn -" Jak pisa efektywne Na tym etapie tworzone s diagramy  Use Case przypadki u|ycia", WNT 2004 PosBu| one do nastpnych etapw projektowania http://www.usecases.org oraz do koDcowego testowania systemu pod ktem speBniania wymogw u|ytkownikw. Okre[la CO system robi Model implementacyjny i Model logiczny wdro|eniowy Przedstawia system w postaci klas, powizaD i Model implementacyjny interakcji midzy nimi, zachowaD obiektw Przedstawia system jako moduBy, nale|cych do tych klas oraz sekwencji dziaBaD podsystemy, zadania. Na tym etapie powstaje systemu. diagram komponentw. Na tym etapie tworzy si nastpujce diagramy: Model wdro|eniowy (Deployment ) klas, obiektw sekwencji (interakcji) Modeluje fizyczne rozmieszczenie moduBw wspBpracy systemu na komputerach. Uwzgldnia przej[ stanw wymagania sprztowe, obszary krytyczne. Okre[la CO jest w systemie, JAK system Na tym etapie tworzymy diagramy dziaBa rozmieszczenia (deployment). Use Case  przykBad u|ycia Elementy diagramw use case Opisuje pewne zachowanie systemu, interakcje aktor systemu ze [rodowiskiem zewntrznym przypadek u|ycia (czBowiek, inny system  aktor) relacje (asocjacje, zale|no[ci) Cig wykonywanych przez system akcji, ktre na |danie aktora realizuj jego cele Aktor (osoba, system zewntrzny): i dostarczaj mierzalne wyniki. korzysta z systemu Reprezentuje wymagania funkcjonalne dostarcza/odbiera dane do/z systemu administruje systemem use case  CO system robi a NIE jak to robi 1 10/7/2012 Aktor PrzykBad diagramu use case Aktor: przyczyna napdzajca przypadki u|ycia, sprawca zdarzeD powodujcych zamawia uruchomienie przypadku u|ycia, odbiorca danych wyprodukowanych przez przypadki u|ycia. wypo|ycza Czytelnik Aktor  osoba, organizacja, inny system komputerowy. Grupa osb peBnicych pewn rol, a nie zwraca konkretna osoba bibliotekarz 7 DziaBania wstpne Strukturalizacja use case w rozpoznanie dziedziny problemu przykBad u|ycia mo|e by specjalizacj innego (generalizacja) wywiady z udziaBowcami przykBad u|ycia mo|e by wBczany jako okre[lenie u|ytkownikw i ich punktw cze[ innego (<<include>>) widzenia przykBad u|ycia mo|e rozszerza zachowanie modelowanie procesw biznesowych innego ( <<extend>> ) zrdBa danych wizja systemu Relacje Scenariusz przypadku u|ycia Zale|no[ (dependency) midzy Opisuje si sekwencj zdarzeD: elementami, zmiana w jednym mo|e wpBywa jak si rozpoczyna, na drugi, skierowanie pokazuje kierunek przepByw zdarzeD, zale|no[ci . jak si koDczy, Generalizacja (dziedziczenie) jakie s interakcje z aktorem. Asocjacja (association) powizanie. Dwukierunkowa : Tekst nieformalny, tekst strukturalny (z Jednokierunkowa: warunkami pocztkowymi i koDcowymi), pseudokod 2 10/7/2012 Format opisu przypadku u|ycia (1) Format opisu przypadku u|ycia (2) Warunki koDcowe: Nazwa: <W postaci wyra|enia czasownikowego> - Gwarancje powodzenia: <Warunki speBnione po Kontekst u|ycia: <Cel, normalne warunki wystpienia> pomy[lnym wykonaniu gBwnego scenariusza przypadku Zakres i poziom: <Czy przypadek u|ycia dotyczy caBego u|ycia> przedsibiorstwa, wybranego systemu czy fragmentu - Minimalne gwarancje: <Minimalne wymagania oprogramowania? Na jakim poziomie szczegBowo[ci prawdziwe na koDcu ka|dego przebiegu przypadku u|ycia jest opisany?> (rwnie| niepoprawnego)> Aktor gBwny: <Nazwa gBwnego aktora, opis jego roli> GBwny scenariusz powodzenia / PrzepByw podstawowy: Pozostali aktorzy i udziaBowcy: <Nazwy aktorw, ich <Numer kroku> <Opis akcji> interesy> <Numer kroku> <Opis akcji> Wyzwalacze / Inicjacja: <Zdarzenie powodujce PrzepBywy alternatywne: rozpoczcie przypadku u|ycia> <Numer zmienionego kroku> <Opis akcji> Warunki pocztkowe: <Co system zapewnia przed Punkty rozszerzenia: <Miejsca i warunki rozszerzeD> zezwoleniem na rozpoczcie przypadku u|ycia?> Specjalne wymagania (np. niefunkcjonalne): 13 14 Scenariusz gBwny  przykBad Scenariusze alternatywne zamawia ksi|k Scenariusz alternatywny 1 (odmowa autoryzacji) 1. System prezentuje ekran wyszukiwania. 1  8 Jak w scenariuszu gBwnym. 2. Czytelnik wprowadza dane bibliograficzne. 9 System odmawia autoryzacji: powrt do kroku 7. 3. System przeszukuje katalog i wy[wietla list tytuBw. Scenariusz alternatywny 2 (brak wolnej ksi|ki) 4. Czytelnik przeglda list i wybiera tytuB. 1  5 Jak w scenariuszu gBwnym. 5. System wy[wietla list ksi|ek. 6. Brak wolnej ksi|ki: czytelnik zapisuje si do 6. Czytelnik zamawia woln ksi|k. kolejki. 7. System wy[wietla okno logowania. 7. System wy[wietla okno logowania. 8. Czytelnik wprowadza nazw i hasBo. 8. Czytelnik wprowadza nazw i hasBo. 9. System autoryzuje czytelnika. 9. System autoryzuje czytelnika. 10. System potwierdza zapisanie do kolejki. 10. System potwierdza przyjcie zamwienia. Generalizacja use case Oglny schemat i specyficzne realizacje zamawia Ten sam cel Mog by r|ni aktorzy przez telefon przez osobi[cie internet Klient Klient Klient 18 telefoniczny internetowy 3 10/7/2012 Rozszerzenie <<extend>> Typowy schemat i dodatkowe czynno[ci Okre[lone punkty rozszerzenia Brak odrbnych aktorw PrzykBad u|ycia podstawowy mo|e wystpi sam, ale w pewnych warunkach jego zachowanie mo|e by rozszerzone  w pewnych punktach ( extension point), przez inny przypadek), pokazane opcjonalne zachowanie systemu Wariant, opcja 19 PrzykBad <<extend>> <<extend>>>> PoB. Konferencyjne. PoBcz sie <<extend>> Odbierz Odbierz dodatkowe klient 22 Zawieranie <<include>> PrzykBad u|ycia wBcza zachowanie innego, przykBad  included nie mo|e by samodzielny Wyodrbnienie fragmentu przypadku u|ycia Mo|liwe fragmenty wsplne Brak odrbnych aktorw 23 4 10/7/2012 PrzykBad <<include>> zamawia <<include>> autoryzuje Czytelnik wypo|ycza <<include>> 26 Generalizacja aktorw U|ycie generalizacji aktorw wypo|ycza obsBuga podsystem konta klienta zarzdzania baz danych banku include Czytelnik weryfikacja include informowanie o zwraca karty stanie konta klienta i kodu klienta klient include inicjalizacja karty klienta Wprowadza czytelnika administrator systemu bibliotekarz 28 Diagram przypadkw u|ycia z Heurystyka tworzenia przypadkw <<include>> u|ycia 4 kroki wg Cockburna Rezerwuje <<include>> 1. Zidentyfikuj aktorw i ich cele. >> 2. Napisz gBwny scenariusz powodzenia Zwraca Modyfikacja bazy klient 3. Zidentyfikuj i wylistuj mo|liwe rozszerzenia <<include>>>> (zwBaszcza mo|liwe bBdy) <<include>> Wypo|ycza 4. Opisz jak system obsBuguje ka|de >> rozszerzenie (w tym ka|dy bBd) 30 5 10/7/2012 Diagram przypadkw u|ycia  Zalety i wady przypadkw u|ycia podsumowanie Przedstawia wymagane zachowanie systemu + Modeluje kontekst systemu przedstawiaj wymagania funkcjonalne w prostym do czytania formacie tekstowym Czynno[ci: - 1. Identyfikacja aktorw 2. Okre[lenie przypadkw u|ycia pokazuj tylko wymagania funkcjonalne  bez zadania aktora (np. wprowadzanie danych, niefunkcjonalnych prezentacja danych, utrzymanie systemu) projekt nie jest tylko tworzony w kategoriach 3. Uporzdkowanie modelu (generalizacja, przypadkw u|ycia rozszerzenie, zawieranie 4. Dokumentacja modelu 31 Diagram przypadkw u|ycia  PrzykBady przypadkw u|ycia podsumowanie -2 Przypadki u|ycia nie dotykaj problemw projektowych: Order Food Customer Service Person struktury danych wspBbie|no[ci operacji Hire Employee Applicant struktury programu Diagram przypadkw u|ycia nie pokazuje Reorder <<include>> Manager kolejno[ci, w jakiej przypadki mog by supplies Supplier wykonywane. WBa[ciw kolejno[ okre[laj <<include>> diagramy realizowane w modelu logicznym. Track sales and inv. data Produce 34 mgt. reports PrzykBady Use Case model  typowe bBdy ZBe nazwy (rzeczowniki zamiast czasownikw): assign a visit add a patient patient for a patient NiewBa[ciwe u|ycie relacji Kierunki relacji something something "main "main included extending functionality" functionality" include extend 35 36 6 10/7/2012 Use cases vs. internal features consider software to run a cell phone: Use Cases Internal Functions call someone " transmit / receive data receive a call " energy (battery) send a message " user I/O (display, keys, ...) memorize a number " phone-book mgmt. Point of view: user Point of view: developer / designer 37 7

Wyszukiwarka

Podobne podstrony:
Laboratorium Use Case Diagram
Sieci komputerowe wyklady dr Furtak
Wykład 05 Opadanie i fluidyzacja
Viral Blog Post Case Study
WYKŁAD 1 Wprowadzenie do biotechnologii farmaceutycznej
mo3 wykladyJJ
ZARZĄDZANIE WARTOŚCIĄ PRZEDSIĘBIORSTWA Z DNIA 26 MARZEC 2011 WYKŁAD NR 3
Wyklad 2 PNOP 08 9 zaoczne
Wyklad studport 8
Kryptografia wyklad
Budownictwo Ogolne II zaoczne wyklad 13 ppoz
wyklad09

więcej podobnych podstron