SW_02 Diagram případu užití Use Case Diagram 1
problem statement Requirement elicitation nonfunctional requirements class diagram functional model Analysis analysis object model use case diagram dynamic model state machine diagram sequence diagram Přehled objektově orientovaného softwarového inženýrství a jejich produktů System design design goals system design object model subsystem decomposition Object design class diagram object design model Implementation source code Test deliverable system 2
Případy užití Případy užití se orientují na chování systému z vnějšího pohledu. Případ užití popisuje funkci poskytovanou systémem, která přináší viditelný výsledek pro aktéra. Aktér reprezentuje libovolnou entitu, která je se systémem v interakci (uživatel, jiný systém, fyzické okolí systému). 3
Případy užití Případ užití popisuje chování systému tak jak je viděno z pohledu aktéra. Aktéři inicializují případ užití, aby zpřístupnili funkcionalitu systému. Případ užití může iniciovat jiné případy užití a také získat více informací od aktérů. Když aktéři a případy užití si vyměňují informace, říkáme, že komunikují. 4
Řídící systém mimořádných událostí Aktéři terénní pracovník, dispečer. Terénní pracovník zaznamenává událost pomocí počítače (wifi) do databáze. Dispečer vizualizuje aktuální stav události, a aktuální stav policejních a požárních aut a přiděluje zdroje (techniku, lidi). 5
Navigační databáze Hlášení mimořádné události Terénní pracovník Otevření mimořádné události Dispečer Přidělení zdrojů Terénní pracovník vyvolává (spouští) případ užití Hlášení mimořádné události. Tím informuje dispečera o nové mimořádné události. Odpovědí dispečera je vyvolání případu užití Otevření mimořádné události, aby událost zaznamenal a inicioval zpracování události. Dispečer získá předběžné informace o události z Hlášení mimořádné události z databáze a přidělí další jednotky k řešení události tj. případ užití Přidělení zdrojů. 6
Textová reprezentace případu užití Atributy případu užití: Jméno - jedinečné Zúčastnění aktéři (jsou v interakci s případem užití) Vstupní podmínky pro inicializaci případu užití 7
Jméno případu užití Zúčastnění aktéři Hlášení mimořádné události Iniciace terénním pracovníkem, komunikace s dispečerem Tok událostí 1. TP aktivuje Hlášení mimořádné události. 2. IS odpoví formulářem k vyplnění. 3. TP vyplní formulář, stupeň důležitosti, typ, lokace, popis situace. Také popis nutných zdrojů. Odeslání formuláře. 4. IS obdrží formulář a informuje dispečera. 5. Dispečer vyhodnotí získané informace a vytvoří nový Incident v databázi pomocí případu užití Otevření mimořádné události. Dispečer vybere odpověď (akci). 6. IS potvrdí dispečerovi vybranou odpovědí. Vstupní podmínky Výstupní podmínky Požadavky kvality TP se přihlásí do IS. TP obdržel potvrzení své zprávy a vybranou odpověď od dispečera, nebo dostal vysvětlení proč nebyla transakce zpracovaná. Zpráva od TP je potvrzena do 30 sekund. Vybraná reakce přijde do 30 sekund od odeslání dispečerem. 8
Vztahy komunikace Aktéři a případy užití komunikují, když jsou mezi nimi vyměňovány informace. Komunikační vztahy jsou vyjádřeny plnými čarami mezi aktéry a případy užití. Komunikační vztahy mezi aktéry a případy užití se používají k naznačení (symbolizování) přístupu k funkcionalitě. 9
Vztah include Při popisu složitého systému model případu užití je také složitý a obsahuje nadbytečnosti (zbytečné opakování). Ke snížení složitosti modelu identifikujeme společné věci v různých případech užití. např. dispečeru se po stisknutí dané klávesy zobrazí mapa ulice to je možné modelovat případem užití Zobraz mapu, který je začleněn do Otevření mimořádné události. 10
Otevření mimořádné události «include» Zobraz mapu Přidělení zdrojů «include» Dva případy užití jsou propojeny vztahem (relací) include, znamená, že používají další případ užití. Vztah include se značí čárkovanou čarou, s popisem include a se šipkou označující která případ užití používá jiný případ užití. 11
Vztah extend Vztah extend představuje alternativní prostředky ke snížení složitosti modelu případu užití. Případ užití může rozšířit jiný případ užití přidáním událostí. Vztah extend naznačuje, že instance rozšířeného případu užití zahrnuje (za daných podmínek) chování specifikované rozšířeným (extended) případem užití. 12
Vztah extend Typickým příkladem pro vztah extend je specifikace výjimečného chování (exceptional behaviour). Např. síťové spojení dispečera a TP může být přerušeno kdykoli. (TP vjede do tunelu). Případ užití ConnectionDown popisuje množinu událostí, které provede systém, když je spojení přerušeno. 13
Otevření mimořádné události «extends» Connection Down Přidělení zdrojů «extends» Případ užití ConnectionDown rozšiřuje případy užití Otevření mimořádné události a Přidělení zdrojů. Oddělením zpracování výjimky nám dovolí psát efektivnější, přehlednější a kratší kód. Čárkovaná čára směřující od výjimečného případu užití ke standardním případům užití. 14
Jméno případu užití Zúčastnění aktéři ConnectionDown Terénní pracovník, dispečer Tok událostí - - - Vstupní podmínky Tento případ užití rozšiřuje (extends) případy užití Otevření mimořádné události a Přidělení zdrojů. Je iniciován systémem, když je ztraceno síťové spojení mezi dispečerem a terénním pracovníkem. Výstupní podmínky - - - 15
Rozdíl mezi vazbami include a extend Rozdílem je umístění závislosti. Předpoklad, máme další nové případy užití pro dispečera, např. AktualizaceIncitentu, RelokaceZdrojů. Pokud bychom modelovali případ užití ConnectionDown pomocí include, oba nové případy užití musí vědět o include případu užití ConnectionDown. 16
Rozdíl mezi vazbami include a extend Při použití vazby extend pro ConnectionDown, modifikovaný musí být pouze ConnectionDown, aby pokryl dodatečné případy užití. Vyjímečné případy jsou většinou modelovány pomocí vazby extend. Případy užití, které popisují všeobecné chování sdílené množinou případů užití, jsou modelovány s vazbou include. 17
Vztah dědičnosti Vztah dědičnosti je třetím mechanismem pro snížení složitosti modelu. Jeden případ užití může specializovat jiný všeobecnější případ užití. V našem případě, TP je žádán, aby se autentikoval před vstupem do IS. Autentizace se popsána jako všeobecný případ užití, který se může dále specializovat. 18
Autentizace s heslem Autentizace Autentizace s kartou Autentizace potvrzení pravosti Zjemnění činnosti zahrnuje autentizaci heslem nebo autentizaci kartou. 19
Jméno případu užití Autentizace s kartou Zúčastnění aktéři Zděděni z případu užití Autentizace Tok událostí 1. TP vloží svoji kartu do terminálu. 2. Terminál potvrdí kartu a žádá o číslo PINu. 3. TP vloží číslo svého PINu. 4. Terminál zkontroluje PIN s pinem na vložené kartě. Pokud se PINy shodují, je TP autentizován. Jinak terminál odmítne vstup. Vstupní podmínky Zděděné z Autentizace - případu užití Výstupní podmínky Zděděné z Autentizace - případu užití 20
Vazby mezi případy užití Všimněte si, že vazby extend a dědičnosti (inheritance) jsou odlišné. Ve vazbě extend, každý případ užití popisuje odlišný tok událostí k dokončení odlišného úkolu. Ve vazbě dědičnosti, případy užití popisují stejný tok událostí k dokončení společného úkolu. 21
Scénáře Případ užití je abstrakce, která popisuje všechny možné scénáře zahrnující popisovanou funkcionalitu. Scénář je instance případu užití, popisující konkrétní množinu akcí. Scénáře jsou používány jako příklady pro ilustraci společných případů; jejich záměrem je srozumitelnost. 22
Scénáře Scénář standardně popisujeme pouze tři pole: jméno zúčastnění aktéři tok událostí Vstupní a výstupní podmínky se používají v případech užití, které jsou abstrakcemi scénářů. 23
Jméno scénáře Zúčastněné instance aktérů Hoří velkosklad Josef, Alena: terenní pracovníci Jan: Dispečer Tok událostí 1. Josef během řízení zpozoroval kouř přicházející z velkoskladu. Alena aktivovala Hlášení momořádné události. 2. Alena vložila adresu budovy, krátký popis místa a úroveň mimořádné události. Žádala hasičské jednotky. Odeslala zprávu a čeká na potvrzení. 3. Dispečer Jan byl upozorněn na mimořádnou událost akusticky. Obdržel informace od Aleny a potvrdil jejich příjem. Alokoval dvě požární jednotky a zaslal odhadovaný čas jejich příjezdu Aleně. 4. Alena obdržela potvrzení o přijetí její zprávy a předpokládaný čas příjezdu hasičů. 24
Diagram tříd Diagram tříd popisuje strukturu systému v termínech tříd a objektů. Třídy jsou abstrakce, které specifikují atributy a chování množiny objektů. Diagram objektů se liší od diagramu tříd: název objektu je podtržený, datové atributy jsou konkrétní. 25
HavarijníZprava 1..* zpravy 1 Incident generovanezpravy * generovanyincident * TerenniPracovnik Dispecer 1 1 jmeno: String cisloodznaku: Integer autor jmeno: String cisloobznaku: Integer iniciator Diagram tříd- třídy, které se zúčastní v případu užití: Hlášení mimořádné události. Asociace mezi třídami, kardinality a role. 26
zprava_1291 incident_1551 josef: TerenniPracovnik jmeno = josef. D. cisloodznaku = 132 jan: Dispecer jmeno = jan M. cisloodznaku = 12 alena: TerenniPracovnik jmeno = alena L. cisloodznaku = 23 Diagram objektů, uvedeny pouze konkrétní vztahy. Linky mezi objekty. 27
Asociace a linky (spojení) Link (spojení) reprezentuje spojení dvou objektů. Asociace jsou relace (vztahy) mezi třídami a tedy reprezentují skupinu linků viz předchozí obrázky. 28
Navigace - směrování Jednosměrná asociace. Navigace směrem od Mnohoúhelníku k Bodu znamená, že pouze Mnohoúhelník zná bodu, ze kterých je složen. Bod neví do kterého Mnohoúhelníku patří. Mnohouhelnik * * Bod 29
Asociační třída Asociace jsou podobné třídám tím, že mohou mít také k sobě připojené atributy a operace. Přiděluje role: String casoznameni: Cas Incident TerenniPracovnik jmeno: String cisloodznaku: Integer zdroje 1..* 1 incident 30
Asociační třída Asociační třída se také může převést na klasickou třídu s jednoduchými asociacemi. Přidělení 1 1 role: String casoznameni: Cas TerenniPracovnik jmeno: String cisloodznaku: Integer 1..* zdroje incident 1 Incident 31
Role a kardinality (násobnosti) Role na každém konci asociace může být označení role. Kardinality: je uvedeno na koncích asociace one-to-one one-to-many (1..n, 0..n) many-to-many. 32
PolicejniiDustojnik 1 1 CisloOdznaku JednotkaHasicu 1 * vlastnik vlastnost HasicskeAuto TerenniPracovnik * * autor zprava ZpravaOIncidentu 33
* PrvekSouborovehoSystemu 1 Adresar Soubor Přidáním kardinality k asociacím, zvyšujeme množství informací, které získáme z aplikace nebo domény řešení. Specifikace kardinalit asociací se stává kritickou, když určujeme, který případ užití je nutný k manipulaci s aplikačními doménovými objekty. Např. souborový systém je tvořen adresáři a soubory. Adresář může obsahovat jakýkoli počet Prvků Souborového Systému. V případě striktně hierarchického systému, Prvek Souborového Systému je součástí přesně jednoho adresáře, což označíme jako one-to-many. 34
* PrvekSouborovehoSystemu * Adresar Soubor Avšak v případě, že Soubor nebo Adresář může být současně částí více než jednoho adresáře, musíme reprezentovat agregaci PrvkuSouborovehoSystemu do Adresářů jako asocoaci many-to-many. 35
Agregace Asociace se používají pro široký rozsah spojení mezi objekty. Speciálním případem asociace je agregace. Agregace představuje volnou vazbu mezi celkem a jeho částmi. 1 1 * * Stat Hejtmanstvi Město PolicejniStanice 1 * PolicejniDustojnik Adresar 1 * Soubor 36
Kvalifikace Kvalifikace je technika ke snížení kardinalit (násobnosti) pomocí klíčů. Asociace 0..1 nebo 1 je snazší než 0..n, 1..n. Často v případě asociace 1..n, mohou objekty na straně many rozlišeny od jiných přidáním jména. Každý soubor je jednotně identifikován podle jména souboru. 37
Kvalifikace Vztah mezi adresářem a souborem se nazývá kvalifikovaná asociace. bez kvalifikace Adresar 1 * Soubor jmenosouboru s kvalifikací Adresar jmenosouboru 1 0..1 Soubor 38
Dědičnost PolicejniDustojnik jmeno: String cisloodznaku: integer TerenniPracovnik autor 1 Dispecer 1 iniciator * generovanahlaseni * incident HlaseniOHavarii 1..* 1 Incident Vyjádření vztahů nadtříd a podtříd, datové atributy, metody. 39
Diagram aktivit Activity Diagram Diagram aktivit v UML reprezentuje určení pořadí (posloupnosti) a koordinaci nízkoúrovňového chování. Diagram aktivit ukazuje, jak je chování realizované v termínech jedné nebo více sekvencí aktivit a toků objektů, které jsou nutné pro koordinaci aktivit. 40
Zpracování incidentu Dokumentace incidentu Archivace incidentu Aktivita může být vykonávaná pouze, když jsou všechny předešlé aktivity vykonané. Řídící uzly koordinují toky řízení v diagramu aktivit, poskytují mechanismus pro rozhodování (selekci), uzly fork (přechod rozvětvení), uzly joint (přechod spojení). 41
Otevření incidentu [oheň ne & vysoká priorita] [nízká priorita] [oheň & vysoká priorita] Uvědomění šéfa hasičů Přidělení zdrojů Uvědomění šéfa policie Rozhodování jsou větve v toku řízení. Znamenají alternativy, založené na podmínkách stavu objektu, nebo množiny objektů. 42
Alokace zdrojů Otevření incidentu Koordinace zdrojů Archivace incidentu Dokumentace incidentu Uzly fork a join představují souběžnost (konkurentnost). Fork představují rozdělení toku řízení na více vláken, join pak jejich spojení. 43
Alokace zdrojů Dispečer Otevření incidentu Koordinace zdrojů Archivace incidentu Dokumentace incidentu Terenní pracovník Plavecké dráhy (swimlanes, activity partitions) označují uzavřenou skupinu činností vykonávanou daným aktérem. 44
Klient Vývojář Hlášení problému nebo změna požadavku Návrh změn a odhad dopadů Posouzení navržených změn [změna schválena] [změna odmítnuta] Archivace požadavků Aktualizace požadavků Test návrhu Aktualizace návrhu Aktualizace kódu Posouzení aktuálních změn Vykonání všech významných testů 45
Mapování asociací Asociace jsou koncepty UML, které označují (představují) kolekce dvousměrných spojení (linků) mezi dvěma nebo více objekty. OO-programovací jazyky nemají koncept asociace. Místo toho poskytují reference (odkazy) ve kterých jeden objekt uchovává odkaz na jiný objekt a kolekce, ve kterých jsou odkazy na několik objektů uchovány seřazeny (ordered). 46
Mapování asociací Reference jsou jednosměrné a odehrávají se mezi dvěma objekty. Během objektového návrhu realizujeme asociace v pojmech referencí a musíme vzít do úvahy velké množství asociací a jejich směry. Některé UML nástroje tuto transformaci dělají mechanicky, je však třeba rozumět důvodu (podstatě) této transformace. 47
Jednosměrné asociace one-to-one Např. Inzerent má asociaci one-to-one s Účtem, který nabývá různých hodnot. Inzerent může vyvolat operace Účtu, ale Účet nemůže vyvolat operace Inzerenta. Datový atribut ucet se odkazuje na reálný objekt Ucet. Pouze na počátku je datový atribut ucet nastaven na null. 48
Inzerent 1 1 Ucet Realizace jednosměrné asociace one-to-one (Diagram tříd UML a Java) public class Inzerent private Ucet ucet; public Inzerent() { ucet = new Ucet(); } public Ucet getucet() { return ucet; } } 49
Inzerent 1 1 Ucet Realizace dvousměrné asociace one-to-one (Diagram tříd UML a Java) public class Inzerent { public class Ucet { private Ucet ucet; private Inzerent vlastnik; public Inzerent() { public Ucet(Inzerent vlastnik) { ucet = new Ucet(); this.vlastnik = vlastbnik; } } public Ucet getucet() { public Inzerent getvlastnik() { return ucet; return vlastnik; } } } } 50
Asociace one-to-many Asociace one-to-many nemůže být realizována prostřednictvím reference nebo dvojice referencí. Místo toho realizujeme část many použitím kolekce referencí. Např. Inzerent má několik účtů. Protože účty nemají specifikovaní pořadí, vyskytují se nanejvýš jednou, použijeme množinu k jejich uložení. 51
Inzerent 1 * Ucet Realizace dvousměrné asociace one-to-many (Diagram tříd UML a Java) public class Inzerent { public class Ucet { private Set ucty; private Inzerent vlastnik; public Inzerent() { public void setvlastnik (Inzerent novyvlastnik) { ucty = new HashTable(); if(vlastnik!= novyvlastnik) { } public void adducet(ucet uct) { Inzerent stary = vlastnik; ucty.add(uct); vlastnik = novyvlastnik; uct.setvlastnik(this); if(novyvlastnik!= null) } novyvlastnik.adducet(this); public void removeucet if(stary!= null) (Ucet uct) { stary.removeucet(this); ucty.remove(uct); } uct.setvlastnik(null); } } } } 52
Asociace many-to-many V tomto případě obě koncové třídy mají datové atributy, které jsou kolekcemi referencí na operace, které udržují tyto kolekce konzistentní. Např. třída Turnaj má uspořádanou asociaci many-to-many se třídou Hrac. Tato asociace je realizovaná pomocí třídy List v každém datovém atributu tříd Turnaj a Hrac. 53
Turnaj * {ordered} * Hrac Realizace dvousměrné asociace many-to-many (Diagram tříd UML a Java) public class Turnaj { public class Hrac{ private List hraci; private List turnaje; public Turnaj() { public Hrac() { hraci = new ArrayList(); turnaje = new ArrayList(); } } public void addhrac(hrac h) { public void addturnaj(turnaj t) { if (!hraci.contains(h)){ if (!turnaje.contains(t) { hraci.add(h); turnaje.add(t); h.addturnaj(this); t.addhrac(this); } } } } } } 54
problem statement Requirement elicitation nonfunctional requirements functional model use case diagram Analysis state machine diagram class diagram analysis object model dynamic model sequence diagram System design design goals system design object model subsystem decomposition Object design class diagram object design model Implementation source code Test deliverable system 55