Uogólnienie Diagram przypadków u ycia



Podobne dokumenty
SUPLEMENT SM-BOSS WERSJA 6.15

Planowanie adresacji IP dla przedsibiorstwa.

TECHNOLOGIE OBIEKTOWE. Wykład 3

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Projektowanie systemów informatycznych. Diagramy przypadków użycia

Listy i operacje pytania

Instalacja programu Sprzeda

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Instalacja programu Sprzeda z motorem. bazy danych Pervasive V8

Podstawy modelowania w j zyku UML

SUPLEMENT SM-BOSS WERSJA 6.15

Język UML w modelowaniu systemów informatycznych

Instrukcja obsługi programu Pilot PS 5rc

Inżynieria oprogramowania

Diagram maszyny stanowej - POJĘCIA

Modelowanie obiektowe - Ćw. 3.

Program Sprzeda wersja 2011 Korekty rabatowe

Bazy danych. Plan wykładu. Podzapytania - wskazówki. Podzapytania po FROM. Wykład 5: Zalenoci wielowartociowe. Sprowadzanie do postaci normalnych.

Sposoby przekazywania parametrów w metodach.

Wprowadzanie i zmiany faktur z zakupu, wydruk rejestru zakupu

AUTOMATYCZNE I ZDALNE STEROWANIE STACJ UZDATNIANIA WODY

Znaleziony - jeżeli nadawca nie jest znany w obrębie danego fragmentu Utracony - jeżeli odbiorca komunikatu nie jest znany w obrębie danego fragmentu

Klonowanie MAC adresu oraz TTL

Diagramy przypadków użycia

REGULAMIN SKLEPU INTERNETOWEGO KASTOR z

Temat: Programowanie zdarzeniowe. Zdarzenia: delegacje, wykorzystywanie zdarze. Elementy Windows Application (WPF Windows Presentation Foundation).

Poradnik korzystania z serwisu UNET: Konfiguracja programu pocztowego

MiASI. Modelowanie analityczne. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

Na podstawie art. 14a 1 i 4 ustawy z dnia 29 sierpnia 1997r. - Ordynacja podatkowa (tekst jednolity Dz. U. Nr 8, poz. 60 z 2005r. ze zm.

Zadania do wykonaj przed przyst!pieniem do pracy:

Jzyk UML opis notacji

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Język UML w modelowaniu systemów informatycznych

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Diagram przypadków użycia

Instrukcja instalacji oprogramowania TSG wer. 5.0 z dost pem do danych poprzez sie Internet.

Podstawy programowania III WYKŁAD 4

WYKŁAD 10. Wzorce projektowe czynnociowe Command Strategy

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Gramatyki regularne i automaty skoczone

Bash i algorytmy. Elwira Wachowicz. 20 lutego

obsług dowolnego typu formularzy (np. formularzy ankietowych), pobieranie wzorców formularzy z serwera centralnego,

Instalacja Altium Designer Powizane wideo Altium Designer - Installation and Management

FUNKCJE UYTKOWNIKA. Rozbrajanie systemu pod przymusem [Kod przymusu] Blokowanie linii

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

UML cz. I. UML cz. I 1/1

Bazy danych. Plan wykładu. Proces modelowania i implementacji bazy danych. Elementy ERD. Wykład 2: Diagramy zwizków encji (ERD)

Diagramy czynności Na podstawie UML 2.0 Tutorial

Rys1 Rys 2 1. metoda analityczna. Rys 3 Oznaczamy prdy i spadki napi jak na powyszym rysunku. Moemy zapisa: (dla wzłów A i B)

Bazy danych. Plan wykładu. Proces modelowania i implementacji bazy danych. Elementy ERD. Wykład 2: Diagramy zwizków encji (ERD)

Diagramy czynności. Widok logiczny. Widok fizyczny

PROWIZJE Menad er Schematy rozliczeniowe

Listy Inne przykªady Rozwi zywanie problemów. Listy w Mathematice. Marcin Karcz. Wydziaª Matematyki, Fizyki i Informatyki.

FAKTURA PRZEDPŁATA PODRCZNIK UYTKOWNIKA

Instrukcja obsługi dodatku InsERT GT Smart Documents

Modelowanie i analiza systemów informatycznych Spis treści

Standardy danych w tagu EPC

Instrukcja obsługi systemu przywoławczego pomidzy kabin LF a laboratorium analiz chemicznych

Poradnik korzystania z serwisu UNET: Dostp do poczty elektronicznej ze strony WWW

Programowanie i struktury danych 1 / 44

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Systemy operacyjne lab. 6 Paweł Gmys strona 1

Podstawy modelowania w j zyku UML

JANEX INTERNATIONAL Sp z O.O Warszawa, ul. Płomyka 2 Tel. (022) INSTRUKCJA OBSŁUGI

Kompilacja image z CVS

Wprowadzenie do kompilatorów

1. Podstawy budowania wyra e regularnych (Regex)

MiASI. Modelowanie systemów informatycznych. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

Program Sprzeda 2012

Modelowanie aktywności. Jarosław Kuchta Programowanie Współbieżne

Inżynierski Projekt Zespołowy

Opera Wykorzystanie certyfikatów niekwalifikowanych w oprogramowaniu Opera wersja 1.1 UNIZETO TECHNOLOGIES SA

Elementy Modelowania Matematycznego Wykªad 9 Systemy kolejkowe

Diagramy przypadków uŝycia. związków między nimi

Przypomnienie najważniejszych pojęć z baz danych. Co to jest baza danych?

Podstawy inżynierii oprogramowania

Bazy danych. Plan wykładu. Pierwsza posta normalna. Druga posta normalna. Wykład 7: Sprowadzanie do postaci normalnych. DDL, DML

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

Wzorce projektowe kreacyjne

zdefiniowanie kilku grup dyskusyjnych, z których chcemy odbiera informacje, dodawanie, usuwanie lub edycj wczeniej zdefiniowanych grup dyskusyjnych,

Kreator automatycznego uaktualniania firmware'u

Diagramy stanów i aktywności. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

System Connector Opis wdrożenia systemu

Dostp do zasobów dyskowych uytkowników lcme10 przez protokół SMB (Microsoft Networking)

Lekcja 8 - ANIMACJA. 1 Polecenia. 2 Typy animacji. 3 Pierwsza animacja - Mrugaj ca twarz

Język UML w modelowaniu systemów informatycznych

ZAJ CIA 4. Podstawowe informacje o algorytmie. Operatory relacyjne i logiczne, instrukcja warunkowa if

System Wspierania Pracy Przedstawicieli Handlowych Pocket Seller. Instrukcja uytkownika

s FAQ: NET 08/PL Data: 01/08/2011

Przed instalacj naley sprawdzi wersj posiadanych sterowników urzdzenia. Powinna by nie starsza ni:

Przygotowanie rodowiska dla egzaminu e-obywatel

Programowanie Obiektowe

Studium przypadku Case Study CCNA2-ROUTING

REGULAMIN SKLEPU INTERNETOWEGO KASTOR z

CYKL ZAJ POZNAJEMY POWER POINT

INSTRUKCJA OBSŁUGI PROGRAMU C-STATION

Przyk adowa konfiguracja zwielokrotnianienia po czenia za pomoc Link Aggregation Control Protocol

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Transkrypt:

1 Przypadki uycia Przypadki uycia opisuj funkcjonalno systemu widzian z zewntrz przez uytkownika; Definicja Przypadek uycia to opis zbioru cigów akcji i ich wariantów wykonywanych przez system w celu dostarczenia okrelonemu aktorowi godnego uwagi wyniku. Opisane cigi akcji s działaniami, które obrazuj spodziewane zachowania projektowanego systemu. Przypadki uycia opisuj, w jaki sposób klient zamierza korzysta z projektowanego systemu. Aktor Aktorem jest uytkownik Uytkownikiem moe by zarówno człowiek jak i inny system. Aktor inicjuje interakcj z systemem. Aktor nie musi wcale korzysta bezporednio z systemu (siedzc przed terminalem) - moe robi to, np. za porednictwem pracownika. Tak wic, aktorem w systemie do obsługi przychodni lekarskiej bdzie na pewno pacjent, chocia najprawdopodobniej nigdy nie "dotknie" on adnego komputera. Warianty przypadku uycia Zbiór scenariuszy tworzcych przypadek uycia moe składa si z kilku alternatywnych cigów zdarze. Przykład: Automat do wody sodowej w puszkach. Najwaniejszy dla klienta przypadek uycia to kup napój. I tu mamy główny cig zdarze: wrzuca monet wybiera napój klient otrzymuje napój. A co si zdarzy, gdy w automacie nie ma puszek. Wtedy scenariusz, nadzwyczajny cig zdarze brak towaru jest szczególn wersj, uszczegóławiajc przypadek uycia kup napój. Zawieranie Przypadki uycia mog by czci innych przypadków uycia (zawieranie) Rozpatrzmy przypadki uycia: Dostarcz towar: odbezpiecz automat, otwórz automat, uzupełnij puszki, uzupełnij pienidze do wydawania, zamknij automat, zabezpiecz automat. Zainkasuj pienidze: odbezpiecz automat, otwórz automat, wyjmij pienidze, zamknij automat, zabezpiecz automat. Tworzymy dwa nowe przypadki: Udostpnij wntrze, zablokuj dostp. Teraz przypadki dostarcz towar i zainkasuj pienidze składaj si Dostarcz towar Główny cig zdarze: include (Udostpnij wntrze), uzupełnij puszki, uzupełnij pienidze, include (zablokuj dostp). Ta technika wielokrotnego uycia nazywa si zawieraniem przypadków uycia. Rozszerzanie Przypadki uycia mog rozszerza znaczenie istniejcego przypadków uycia. Wtedy mamy odczynienia z rozszerzaniem. Zwizek ten słuy do modelowania fragmentów przypadków uycia postrzeganych jako opcjonalne zachowanie systemu. 1

2 Czasami tworzymy nowy przypadek uycia przez dodanie kilku kroków do ju istniejcego. Mamy przypadek uycia dostarcz towar i chcemy stworzy nowy przypadek podobny do tego tylko troch rozszerzony np. Dostarcz towar według wyników sprzeday. Dodajemy nowe kroki do starego przypadku uycia i otrzymujemy: include (Udostpnij wntrze), spisz który towar najlepiej si sprzedaje, uzupełnij puszki, include (zablokuj dostp). Uogólnienie Uogólnienie midzy przypadkami uycia jest jak uogólnienie midzy klasami. Oznacza, e przypadek uycia-potomek dziedziczy całe zachowanie i znaczenie po przypadku uycia- przodku. Potomek moe doda do odziedziczonego zachowania nowe elementy, a moe te to zachowanie zupełnie zmieni. Potomek moe zawsze zastpi swego przodka (zarówno przodek, jak i potomek mog mie egzemplarze konkretne). Przy tworzeniu przypadków uycia bardzo wan rzecz jest ustalenie warunków pocztkowych inicjowania przypadków i warunków kocowych okrelajcych rezultat działania. Np. warunki pocztkowe przypadku uycia kup napój jest pojawienie si pragnienia. Warunek kocowy to dana osoba ma puszk napoju. Projektujc system naley zdawa sobie spraw, e czsto uznanie, czy "co" jest przypadkiem uycia, czy te nie, zaley od ziarnistoci modelu. Jeeli projektujemy system operacyjny, a właciwie jego API to wywietlanie pojedynczego znaku moe by przypadkiem uycia tego systemu - operacja taka nie bdzie na pewno PU w systemie obsługi przychodni lekarskiej. Diagram przypadków uycia Diagramy przypadków uycia słu do obrazowania statycznych aspektów perspektywy przypadków uycia systemu. W perspektywie tej bee si pod uwag zachowanie systemu, to znaczy rozpoznawane z zewntrz usługi, jakie system udostpnia bytom ze swego otoczenia. Aktor inicjuje przypadek uycia i aktor (by moe ten sam, ale niekoniecznie) otrzymuje jak warto przez ten przypadek utworzon. Łatwo to przedstawi w postaci graficznej. Aktora inicjujcego umieszczamy na lewo od przypadku uycia, a aktora czerpicego korzy na prawo. Nazw przypadku uycia umieszczamy wewntrz elipsy lub tu pod ni. Linia powizania łczy aktora z przypadkiem uycia i reprezentuje komunikacj midzy nimi. Jest to linia cigła, taka sama, jak stosujemy, przedstawiajc powizania klas. Jedn z korzyci płyncych ze stosowania analizy przypadków uycia jest wyznaczanie granicy midzy systemem i wiatem zewntrznym. Aktorów zwykle umieszczamy poza systemem, przypadki uycia wewntrz. Granice systemu przedstawiamy w postaci prostokta z nazw systemu umieszczon gdzie w rodku. Wewntrz tego prostokta umieszczamy przypadki uycia. 2

3 Diagramy przypadków uycia s zwykle czci dokumentacji projektu przeznaczonej dla klientów i twórców oprogramowania. Kademu diagramowi jest powicana oddzielna strona. Oddzieln stron tworzy si take dla scenariusza kadego przypadku uycia. Oto elementy wyliczane na takiej licie: aktor, który inicjuje przypadek uycia, warunki wstpne przypadku uycia, kroki scenariusza, warunki kocowe scenariusza, aktor, który czerpie korzy z przypadku uycia. Mona take doda list załoe dla danego scenariusza (na przykład, e w danej chwili z automatu do napojów moe korzysta tylko jeden uytkownik) oraz jego krótki, jednozdaniowy opis. Przykład przypadku uycia: Zakup towaru Główny cig zdarze 1. Klient przeglda katalog i wybiera towar do kupienia. 2. Klient przechodzi do kasy. 3. Klient podaje informacje o warunkach dostawy (adres, termin). 4. System podaje pełn informacj cenow, w tym koszty dostawy. 5. Klient podaje informacj o karcie kredytowej. 6. System autoryzuje sprzeda. 7. System natychmiastowo potwierdza sprzeda. 8. System wysyła potwierdzenie do klienta poczt elektroniczn. Alternatywny cig zdarze: Niepowodzenie autoryzacji. W kroku 6 system nie uzyskuje autoryzacji karty kredytowej. Naley umoliwi klientowi powtórne wprowadzenie informacji o karcie kredytowej i powtórzy prób autoryzacji. Alternatywny cig zdarze: Stały klient 3a. System wywietla biece warunki dostawy, informacj o cenie i 4 ostatnie cyfry numeru karty kredytowej. 3b. Klient moe potwierdzi lub zmieni dane domylne. Powrót do scenariusza głównego w punkcie 6. Warunki pocztkowe: Klient postanowił zrobi zakupy w naszym sklepie Warunki kocowe: System wysyła poczt potwierdzenie dokonania sprzeday Aktor: klient. Innym sposobem pokazania scenariusza jest wykorzystanie diagramu czynnoci. 3

4 Zawieranie Zawieranie przypadków uycia oznaczamy tym samym symbolem co zaleno klas. Jest to linia przerywana zakoczona grotem strzały wskazujcym na niezaleny przypadek uycia (czyli ten, od którego zaley inny przypadek). Nad lini zwizku zawierania umieszczamy w nawiasach francuskich stereotyp «include». Rozszerzanie Nowy przypadek uycia powstały z innych przypadków nazywamy rozszerzeniem oryginalnego, poniewa poprzedni cig zdarze zostaje uzupełniony o nowe kroki. Przypadek oryginalny nazywamy podstawowym. Tak samo jak zawieranie, rozszerzenie przedstawiamy za pomoc oznaczenia zalenoci (linii przerywanej z grotem strzały) z ujt w nawiasy francuskie nazw stereotypu «extend». Punkt rozszerzenia wpisujemy wewntrz elipsy przypadku uycia pod jego nazw. Uogólnienie Uogólnienie podobne jest do dziedziczenia. Jedne przypadki uycia dziedzicz zachowania po innych. Diagramy stanów Diagram stanów słuy do modelowania dynamicznych aspektów systemu. Nie musi modelowa jedynie zachowanie obiektów, ale równie przypadki uycia lub system jako cało. Diagram stanów przedstawia maszyn stanow z uwypukleniem przepływu sterowania midzy stanami. Maszyna stanowa okrela cig stanów przyjmowanych przez obiekt w odpowiedzi na zdarzenia zachodzce w czasie jego ycia; okrela te reakcje obiektu na te zdarzenia. Maszyny stanowe słu do modelowania dynamicznych aspektów systemu. Nie musz modelowa jedynie zachowanie obiektów, ale równie przypadki uycia lub system jako cało. Stan to okolicznoci lub sytuacja, w jakiej si obiekt znajduje w czasie swego ycia, kiedy spełnia jaki warunek, wykonuje jak czynno lub czeka na jakie zdarzenie. 4

5 Zdarzenie to specyfikacja zjawiska, które zachodzi w czasie i w przestrzeni. Jeli chodzi o maszyn stanow, zdarzenie jest wystpieniem bodca, który moe uruchomi przejcie midzy stanami. Przejcie to zwizek midzy dwoma stanami, wskazujcy, e obiekt znajdujcy si w pierwszym stanie wykona pewne akcje i przejdzie do drugiego stanu o ile zajdzie okrelone zdarzenie i bd spełnione okrelone warunki.np. nacinito klawisz, zakoczono. Przyjejcie ma pi składników: Stan pocztkowy Stan kocowy Zdarzenie uruchamiajce Warunek dozoru [w nawiasach kwadratowych] wyraenie logiczne, którego warto jest wyznaczana w chwili otrzymania zdarzenia uruchamiajcego. Akcja- wykonywalna podzielna procedura obliczeniowa np. wykonanie operacji obiektu (bdcego włacicielem maszyny stanowej), utworzenie lub zniszczenie innego obiektu, wysłanie sygnału do obiektu. Np. nacinito klawisz [klawisz to spacja] /t.zapiszklawisz(k) Obiekty systemu zmieniaj stany w odpowiedzi na zdarzenia interakcje. Stany Nazwa stanu Nazw stanu piszemy podobnie jak nazw klas z duych liter. Nazwy (jeli to moliwe) podajemy w formie rzeczowników odczasownikowych np. Faksowanie, Wykrcanie, Wyłczanie, Działanie. Od tej reguły mona odstpi np. Bezczynno. Wygld stanu: Prostokt z zaokrglonymi rogami. Po bokach linie cigłe z grotami strzał oznaczaj przejcie. Grot strzały wskazuje stan, w który dany stan przechodzi, czyli stan po przejciu. Na rysunku widzimy take wypełniony okrg, oznaczajcy stan pocztkowy, i bycze oko" oznaczajce stan kocowy. Ikon stanu mona dzieli, w górnym polu nazwa, w nastpnym zmienne, na kocu czynnoci. Zmienne stanu, np. liczniki i zegary, czasami bywaj przydatne. Czynnoci to zdarzenia i akcje. Najczciej uywane s trzy: entry \ (wejd okrela akcj która jest wykonywana przy wejciu do stanu), exit (wyjd okrela, co si dzieje przy wychodzeniu ze stanu) i czynnoci do (wykonaj okrela, co si dzieje z obiektem, gdy system pozostaje w danym stanie). W razie potrzeby mona dodawa inne. 5

6 M o na wskaza zdarzenie, które jest przyczyn przej cia (zdarzenie uruchamiaj ce) oraz obliczenie (akcj ), które zostaje wykonane i powoduje przej cie z jednego stanu w drugi. Zdarzenia i akcje zapisujemy w pobli u linii transmisji, oddzielaj c uko nikiem zdarzenie uruchamiaj ce od akcji. Czasami zdarzenie powoduj ce przej cie nie jest skojarzone z adn akcj, a czasem przej cie nast puje w wyniku uko czenia wszystkich akcji, a nie z powodu jakiego zdarzenia. M ówimy wówczas o przej ciu bez zdarzenia uruchamiaj cego. Podstany Podstan to stan zagnie d ony w innym stanie. Stan maj cy podstany to stan zło ony. Poziom zagnie d enia stanów mo e by dowolnie du y. Podstany sekwencyjne Podstany sekwencyjne wyst puj koleino, jeden po drugim. Obiekt b d cy w stanie zło onym z kilku podstanów sekwencyjnych jest jednocze nie tylko w jednym z tych podstanów. Takie podstany dziel przestrze stanu zło onego na stany rozł czne. Podstany współbie ne Podstany współbie ne umo liwiaj tworzenie dwóch lub wi cej maszyn stanowych działaj cych równolegle w ramach otaczaj cego je obiektu. Czynno ci podstanów współbie nych przebiegaj równolegle. 6