23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 1 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 2 UML (1) úvod, requirements management © 2008 Radek Ošlejšek FI MU Brno oslejsek@fi.muni.cz http://www.fi.muni.cz/~oslejsek/PA103 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 3 Architektura Tijuana “shantytown” 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 4 a vize ... Fallingwater 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 5 Modelovací techniky a nástroje ● Formální modelovací techniky ● např. Z, VDM ● COOPN, Petri-Nets ● Umožňují různé druhy kontrol, ověřování ● Cílem je úplnost ● Použity především pro modelování ústředních částí systému ● Semiformální modelovací techniky ● např. Booch, UML, SysML ● Neformální modelovací techniky ● RDD - Requirement Definition Document, ● CRC analýza , ● Analýza textů, ● Scénáře, ● ... Všechny mají své místo na slunci !Všechny mají své místo na slunci ! 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 6 Historie UML BoochOMT Unified Method 0.8 UML 0.9 UML 1.0 UML 2.0 UML 2.1.2 Use Case říjen '94 Booch a Rumbough říjen '95 OOSE od Jacobsona červen '96 leden '97 z červenec '05 prosinec '07 standardOMG (ObjectModelingGroup) UML 1.1listopad '97 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 7 Co je to UML? (reklama) • UML = Unified Modeling Language • UML je standard OMG • UML může být použit ve všech fázích životního cyklu vývoje a pro různé technologie implementace. Kombinuje vše nejlepší z – Modelování výrobních procesů (toky práce) – viz Procesní řízení – Konceptů datového modelování (entitně-relační diagramy) – viz ANANAS – Modelování objektů – Modelování komponent • UML je převážně grafický jazyk – Grafické vyjádření napomáhá při pochopení, dokumentaci a vysvětlení problému • UML je sada nástrojů, nedefinuje postup jak je využít (to je věc zvolené metodiky) • Důležitým předpokladem pro úspěšný vývoj softwaru je: – Zvládnutí modelovacích technik (UML) – Zvládnutí jednoho nebo více procesů vývoje softwaru (metodiky) – Znalost nejdůležitějších návrhových vzorů 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 8 Proč potřebujeme jednotný standard? 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 9 Koncepty UML UML lze použít pro: ● zobrazení hranice systému a jeho hlavních funkcí pomocí případů užití (use cases) a účastníků (actors) ● ilustrovat realizaci případů užití pomocí diagramů interakcí ● reprezentovat statickou strukturu systému pomocí diagramů tříd ● modelovat chování objektů pomocí stavově-přechodových digramů ● odhalit fyzickou implementační architekturu pomocí diagramů zapojení komponent ● rozšířit funkcionalitu pomocí stereotypů 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 10 UML – univerzální modelovací nástroj Použití UML pro modelování podnikatelských procesů: ● při zahájení softwarového projektu pro vytvoření pevného základu ● pro zpětné inženýrství podnikatelského procesu Použití UML pro modelování ontologií: ● sémantický web, expertní systémy, ... ● UML je „podtřídou“ OWL – Web Ontology Language ⇒ Stejné diagramy pro různé účely, různé úrovně abstrakce, různé předmětné oblasti. UML není jediný modelovací jazyk – viz např. SysML 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 11 SysML - Systems Modeling Language • domain-specific modeling language for systems engineering applications • language to specify complex systems that include non-software components (e.g., hardware, information, processes, personnel, and facilities) • based on UML • OMG standard 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 12 Modely v UML Modely ukazující statickou strukturu systému: ● diagramy tříd, balíků a objektové diagramy ● implementační diagramy: diagramy komponent, diagramy rozmístění Modely ukazující dynamické chování systému: ● model případů užití ⇒ externí pohled na systém ● diagramy aktivit ⇒ externí/interní pohled na systém ● interakční diagramy: diagramy sekvencí, komunikace a časování diagramy spolupráce ⇒ interní pohled na systém Modely ukazující dynamické chování jediné třídy: ● stavové diagramy, diagramy aktivit 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 13 Vymezení problémové oblasti Use Case modelování 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 14 Problém zachycení požadavků 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 15 Diagram případů užití • Další názvy: Use Case Diagram, UCD • Co potřebujeme: – Chceme zachytit potřeby a požadavky uživatelů – Potřebujeme efektivní mechanismus komunikace mezi uživateli a vývojáři • Co UCD přináší: – Prostředek k vyjádření konkrétních cílů, které chce uživatel dosáhnout, prostřednictvím sekvence interakcí se systémem – Grafické znázornění je dostatečně jednoduché a čitelné i pro laiky – Dokumentace jednotlivých případů užití umožňuje detailně popsat konkrétní interakce 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 16 Pojišťovna: Vize (specifikace) Havarijní pojištění • Zákazník (pojištěnec) si prostřednictvím webových stránek prohlíží nabídku havarijního pojištění. Prostřednictvím webu má možnost zadat údaje o sobě, autě a parametry pojištění a pak odeslat žádost o vytvoření pojistné smlouvy. Žádost je posouzena pracovníkem odd. smluv a v případě souhlasu s vytvořením smlouvy dostane zákazník poštou dvě kopie smlouvy a složenku. Jednu podepsanou kopii pošle zákazník zpět pojišťovně. Platby za pojištění jsou v systému evidovány opět pracovníky odd. smluv. • Pojištěnec má dále možnost prostřednictvím webu zadávat pojistné události. Pojistná událost je vždy převzata likvidátorem škod (zaměstnance pojišťovny), který se spojí s pojištěncem, vyřizuje škodní událost a výsledky zadává do systému. • Pojišťovna spolupracuje s pojišťovacími agenty. Ti nejsou přímo zaměstnanci pojišťovny, ale spolupracují na základě smlouvy. Slouží pro podporu zákazníků, tj. pomáhají jim s vytvářením smluv, jejich změnami a s vyřizováním pojistných událostí. Agenti proto mohou zadávat žádosti namísto zákazníků. Jsou pak odměňováni na základě počtu uzavřených smluv a vyřízených pojistných událostí. Oproti zákazníkům mají navíc možnost zadávat žádosti o změnu smlouvy. Tyto žádosti o změnu jsou opět posouzeny pracovníkem oddělení smluv a vyřízeny podobně, jako žádosti o novou smlouvu. • Management pojišťovny bude mít možnost spravovat ceníky pojištění, získávat statistiky o uzavřených smlouvách a statistiky pojistných událostí. • Systém obsahuje heuristiky, které dokáží odhalit podezřelé události, např. Neobvykle vysoký počet škodných událostí zákazníka. V případě detekce takovýchto událostí je neprodleně informováno vedení prostřednictvím e-mailu. Demo 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 17 UCD: Aktéři • Další názvy: účastník, actor • Entity vně hranic systému, které interagují se systémem. • Dvě možnosti grafického znázornění („panáček“ je jednoznačně nejpoužívanější): • Modelují role, ne konkrétní osoby! – v jedné roli může vystupovat více osob • např.: Jan Novák a Karel Zeman jsou oba zákazníci. – jedna osoba může hrát v systému více rolí • např.: Jan Novák je zároveň vedoucí skladu a kontrolor. • Nejen uživatelé, ale i externí systémy, části hardwaru apod. • Od UML 2 i ostatní subjekty => propojení UC modelů • Aktérem může být i čas – např.: automatická záloha každý večer Student <> Student 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 18 UCD: Aktéři (II) • Aktéři jsou externí, často se ale objeví i jako objekt uvnitř systému – např.: aktér zákazník komunikuje se systémem, objekt zákazník si uvnitř systému pamatuje detaily (jméno, adresa, ...) • Modelujeme jen interakci mezi účastníky a systémem, nikoli interakce mezi účastníky Otázka: Kterého aktéra ponechat? Odpověď: Kdo je zodpovědný za správnost dat? Kdo fyzicky interaguje (komunikuje) se systémem? 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 19 UCD: Aktéři (III) • Více aktérů pro jeden případ užití? • Ano, ale: – Případ užití je „přístupný“ více uživatelským rolím, pak je vhodné zamyslet se nad • vhodnějším rozdělením rolí, • dědičností mezi aktéry – Na řešení případu užití se podílí více rolí (uživatelů) současně • ve skutečnosti se za tím často skrývá několik nezávislých navazujících interakcí (=> dekompozice při následném upřesňování hranic systému) • Jednosměrná komunikace mezi aktérem a případem užití – Nejčastěji ze systému směrem ven – Vhodné pro „pasivní“ zařízení/systémy a zajištěné spolehlivé komunikační protokoly – Používá se velmi zřídka, většinou se jedná o obousměrnou interakci 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 20 UCD: Případy užití • Další názvy: Use Case, typová úloha, uživatelská transakce, ... • Koherentní jednotky funkcionality poskytované systémem – Případ užití = konkrétní interakce, která vede ke splnění cíle • Jsou vždy zahájeny účastníkem, vždy napsány z pohledu účastníka! – případy užití spuštěné časovými událostmi => účastník čas • Jméno p.u. by mělo vyjadřovat cíl, kterého chce aktér dosáhnout špatně – fotograf tyto činnosti nedělá izolovaně, ale jsou mu poskytnuty systémem jako jedna funkcionalita “vytvoř fotku” správně – fotograf vyvolává tyto činnosti a systém na ně reaguje 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 21 Jak najít případy užití • Záleží na použité metodice, obecně můžeme použít tyto strategie: – Každému elementárnímu procesu z procesního modelování (viz přednáška PV165: Procesní řízení) odpovídá jeden případ užití. – Procházíme seznam účastníků a zvažujeme způsob, jakým bude každý z nich systém používat. • Jaké funkce jednotliví účastníci od systému očekávají? • Bude systém uchovávat a poskytovat informace? Pokud ano, jací účastníci budou tyto činnosti aktivovat? • Jací účastníci budou upozorněni na změnu stavu systému? • Existují nějaké vnější události, které ovlivňují systém? Co upozorní systém na tyto události? 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 22 UCD: Subjekt • Další názvy: System Boundary (používáno před UML 2.0) • Je možné vytvářet více UCD pro různé úrovně abstrakce a různé části systému a propojovat je • Často si ale vystačíme s jediným UCD (důležitá je přehlednost a čitelnost) název systému/subjektu modelovaný vnitřek systému Vně systému: nic nevytváříme, ale musíme to vzít v úvahu 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 23 UCD: Subject (II) 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 24 Pojišťovna: UCD Demo 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 25 Vymezení hranic systému • Definice hranic systému probíhá interaktivně. • Hranice systému mohou být definovány na několika úrovních abstrakce, účastníci interakcí se mění podle úrovně abstrakce! – vysoká úroveň bez žádných reprezentantů – střední úroveň, která bere v úvahu kdo/co skutečně vkládá za informaci – nižší úroveň, která bere v úvahu, jaká dat opravdu vstupují • Př. 1: platby za provedené služby – Na začátku víme pouze to, že náš systém musí řešit platby za provedené služby. – Později si vyjasníme, že platby jsou evidovány v externím systému, který zadavatel používá. Náš systém tedy bude platby řešit přes tento externí systém. – Nakonec dospějeme k tomu, že komunikace bude probíhat prostřednictvím XML zpráv. Náš systém bude mít modul, který se o komunikaci bude starat. • Př. 2: zálohování dat – Zákazník požaduje zálohování všech dat. – Později zjistíme, že data jsou uložena na externím databázovém serveru, který je automaticky zálohovaný a proto se o tuto činnost náš systém vůbec nemusí starat. 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 26 Př: Vymezení hranic systému (II) 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 27 Př: Vymezení hranic systému (III) Na PDA běží speciální klientská aplikace, kterou musíme také vyvinout GUI XML, SOAP, ... 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 28 Specifikace případů užití • Každý případ užití musí být dokumentovaný • Dokumentace je psána z pohledu aktéra • Obsahuje detaily, které musí systém poskytnout aktérovi při provádění případu užití • Neexistuje žádný standard UML pro psaní specifikace p.u. ... • ..., ale typicky obsahuje: – název případu užití – aktéři účastnící se případu užití – popis interakcepopis interakce pomocí toků událostí a/nebo scénářů – speciální (nefunkční) požadavky, např. časová omezení – priority a stav vývoje ... 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 29 Toky událostí Další názvy: Flow of Events. Dokumentace pomocí toků nejčastěji obsahuje: • vstupní podmínky (preconditions) – kritéria, která musí být splněna před spuštěním p.u. • výstupní podmínky (postconditions) – kritéria, která musí být splněna na konci p.u. • normální tok událostí nebo interakcí – jednotlivé kroky v případu užití • alternativní a výjimečné toky událostí 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 30 Toky událostí (II) Jak popsat tok událostí: • Volný text • Číslované krokyČíslované kroky • Pseudo kód (obvykle příliš detailní) • Diagramy aktivit • Diagramy interakcí s pseudo kódem nebo textem na levé straně Číslované kroky: • nejčastější forma • první krok popisuje okolnosti zahájení činnosti aktérem 1. p.u. začíná volbou “zobraz obsah košíku” 2. KDYŽ je košík prázdný 2.1 systém zobrazí uživateli, že košík neobsahuje žádné položky 2.2 p.u. končí 3. systém zobrazí seznam všech položek v košíku ... číslované kroky diagram interakcí s pseudokódem 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 31 Toky událostí (III) 1. jsou zadány údaje o rušených položkách objednávky Špatně:Špatně: • kdo údaje zadává?kdo údaje zadává? • kam je zadává?kam je zadává? • co to jsou “údaje o rušených položkách”co to jsou “údaje o rušených položkách” Jak podrobně popisovat: • Závisí na fázi projektu (např. nejprve číslované kroky, později diagram interakcí) • Záleží na významu a složitosti p.u. (kompromis: hlavní tok událostí podrobně, alternativní toky stručně nebo dokonce jen vyjmenovat) • Ne moc podrobné: zachycení požadavků neznamená popis konstrukce systému ve volném textu! 1. => p.u. začíná, když uživatel zadá do formuláře číslo objednávky 2. <= systém vypíše seznam položek objednávky 3. => uživatel vybere rušené položky... Doporučený vzor kroků:Doporučený vzor kroků: • <číslo>[i/o]<číslo>[i/o] 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 32 Alternativní toky událostí • Zjednodušují a doplňují hlavní tok. • Náhrada za větvení, zejména pokud není jasné, kam větvení umístit. • Musí začínat “booleovskou” podmínkou, která daný alternativní tok spouští! • Měl by být co nejjednodušší. • Každý alternativní tok musí mít svoje vlastní výstupní podmínky! Případ užití: zobrazení nákupního košíku Vstup. podmínky: zákazník je přihlášen do systému Tok událostí: 1. p.u. začíná volbou “zobraz obsah košíku” 2. KDYŽ je košík prázdný 2.1 systém zobrazí uživateli, že košík neobsahuje žádné položky 2.2 p.u. končí 3. systém zobrazí seznam všech položek v košíku Výstup. podmínky: Alternativní tok 1: 1. zákazník může kdykoli opustit obrazovku košíku Výstup. podmínky: Alternativní tok 2: 1. zákazník může kdykoli opustit systém Výstup. podmínky: 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 33 Pojišťovna: Dokumentace P.U. Use Case ID: VyrizeniNovychSmluv Primary Actor: PracovnikOddSmluv Preconditions 1. Pracovnik oddeleni smluv je prihlaseny do systemu 2. System pri zadavani zadosti overil, ze nechybi nezbytne udaje, zejmena rodne cislo zadatele Flow of Events 1. PU zacina, kdyz PracovnikOddSmluv vybere "vyrizovat nove smlouvy" 2. System zobrazi seznam nevyrizenych smluv s odkazy na podrobnosti setrideny podle data podani 3. IF PracovnikOddSmluv klikne na konkretni pozadavek v seznamu 3.1 System vypise podrobnosti zadane zadatelem 3.3 IF PracovnikOddSmluv klikne na "vytvorit novou smlouvu" 3.3.1 System zobrazi seznam existujicich smluv se stejnym rodnym cislem a odkazy na podrobnosti 3.3.2 PracovnikOddSmluv muze prohlizet podrobnosti o existujicich smlouvach 3.3.2 IF PracovnikOddSmluv kline na "vytvorit novou smlouvu" 3.3.2.1 System zobrazi formular pro zalozeni nove smlouvy s preddefinovanymi informacemy z zadosti 3.3.2.2 PracovnikOddSmluv vyplni pozadovane informace a potvrdi vytvoreni smlouvy 3.3.2.3 System smlouvu ulozi do databaze 3.3.2.4 System vytiskne dve kopie nove smlouvy 3.3.2.5 System vytiskne slozenku 3.3.2.6 PU pokracuje krokem 2 Post-conditions V systemu je zalozana nova smlouva Demo 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 34 Pojišťovna: Dokumentace P.U. (...pokr.) Alternative Flow 1 1. PU zacina, kdyz PracovnikOddSmluv pracuje s konkretni zadosti a PracovnikOddSmluv se rozhodne zadost zamitnout 2 System zobrazi formular zpravy o zamitnuti vcetne vyberu preddefinovanych oduvodneni 3 IF PracovnikOddSmluv vybere preddefinovane oduvodneni 3.1 System vyplni preddefinovany text do do zpravy 4 PracovnikOddSmluv muze editovat zpravu o zamitnuti 5 IF PracovnikOddSmluv potvrdi zamitnuti zadosti 5.1 IF zadost obsahuje e-mailovou adresu zadatele 5.1.1 System posle zpravu na e-mail zadatele 5.2 Zatnuti zadosti s oduvodnenim se ulozi do systemu Post-conditions V systemu je ulozeno zamitnuti zadosti vcetne oduvodneni Demo 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 35 Scénáře • Další názvy: Scenarios • Scénář: jedna konkrétní cesta případem užití • Jiný pohled na případ užití, vhodné pro složité případy užití • Neobsahuje větvení! • Primární scénář: normální průchod, kdy vše probíhá normálně, nebo nejpravděpodobnější cesta. Pro daný p.u. je jediný! • Sekundární scénáře: jiné cesty popsané méně podrobně nebo jen vyjmenované – alternativní scénáře: jiné povolené cesty (větvení) – výjimečné scénáře: pro zpracování chyb • Otázky pro nalezení sekundárních scénářů: – jaké jiné akce mohou být prováděny v tomto bodě? – je něco, co by se mohlo pokazit v tomto bodě? – nějaké chování, které může nastat kdykoli během primárního scénáře, např. zrušení nebo znovuspuštění? 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 36 P.u.: Diagramy aktivit (1) Diagramy aktivit patří do skupiny dynamických diagramů UML; mohou být také použity pro dokumentaci případů užití. Podrobněji budou probrány později. začátek případu užití konec případu užití krok případu užití (reprezentovaný jako stav obsahující akce), nebo několik kroků podrobněji popsaných na zvláštním diagramu přechod mezi kroky podmínka přechodu rozhodnutí s rozhodovacím bodem Ověření platnosti požadavku krok 1 [platný požadavek] krok 3 krok 2 [podmínka 1] [podmínka 2] 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 37 P.u.: Diagramy aktivit (2) Nedostatky: » prostor pro popis kroků na diagramu je omezený » nejsou znázorněny vztahy „užívá“ a „rozšiřuje“ (pokud si je sami nevytvoříte a nepřidáte do notace) » diagramy mohou být velmi složité ==> pro každý p.u. je nutné rozhodnout, zda je vhodné použít textový popis, diagram aktivit nebo obojí krok a krok b krok c krok d paralelní kroky (fork & join) Diagramy aktivit obsahují více modelovacích prvků, které zde neuvádíme, protože nejsou relevantní pro popis případů užití 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 38 Pokročilé modelování případů užití 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 39 Vztah <> • Další názvy: užívá • Vztah mezi dvěma případy užití • Společné chování dvou nebo více p.u. může být vyčleněno do zvláštního případu užití (vyhýbá se opakování a kopírování společných kroků) • A a B nejsou kompletní bez C • C je vyvoláno alespoň jednou v A a B • C může být (a často je) použito ve více případech užití • Pokud je C úplný p.u., může být vyvolán i přímo aktérem • C je popsáno stejně, jako jiné případy užití 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 40 Vztah <> (II) Případ užití: Změnit údaje o zaměstnanci Vstup. podmínky: K systému je přihlášený oprávněný Vedoucí. Tok událostí: 1. PU začíná požadavkem na změnu údajů zaměstnance. 2. INCLUDE(najít údaje o zaměstnanci). 3. Systém zobrazí aktuální údaje zaměstnance. 4. ... Výstup. podmínky: 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 41 Vztah <> • Další názvy: rozšiřuje • Vztah mezi dvěma případy užití • Pro vložení nového chování, volitelných částí a pro zpracování chyb • A je úplný p.u., který v ideálním případě neví nic o existenci svých rozšíření B a C => základnímu scénáři je jedno, kdo ho rozšiřuje • Umístění rozšiřujícího p.u. je označeno bodem rozšíření (extension point) => v diagramu a/nebo v popisu rozšiřovaného p.u. “ve vrstvě nad tokem událostí” => rozšiřující p.u. ví, jak se přidat do základního scénáře • Rozšiřující p.u. B a C jsou často neúplné p.u. a mohou mít více fragmentů • Podmínka pro rozšíření je uvedena v popisu jednotlivých rozšiřujících p.u. nebo v podmínce rozšiřujícího vztahu (od UML 2.0) • Rozšíření se často používají v následných verzích systému 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 42 Vztah <> (II) Případ užití: RezervujKnihu Preconditions: 1. Jsou zobrazeny detailní informace o knize Tok událostí: 1. Čtenář klikne na „rezervovat knihu“. 2. Systém uloží čtenáře do fronty rezervací a zobrazí výsledek. • Chceme přidat: – Odmítnout rezervaci čtenáři, který má nevrácenou knihu – Zaslání upomínky těm, kteří již měli rezervovanou knihu vrátit – Uložení pokuty těm, kteří navíc již upomínku dostali 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 43 Vztah <> (III) Případ užití: RezervujKnihu Preconditions: 1. Jsou zobrazeny detailní informace o knize Tok událostí: 1. Čtenář klikne na „rezervovat knihu“. 2. Systém uloží čtenáře do fronty rezervací a zobrazí výsledek. Body rozšířeníBody rozšíření • Chceme přidat: – Zaslání upomínky těm, kteří již měli rezervovanou knihu vrátit – Uložení pokuty těm, kteří navíc již upomínku dostali – Odmítnout rezervaci čtenáři, který sám má v nevrácenou knihu 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 44 Vztah <> (IV) Rozšiřující případ užití: UlozPokutu 1. PRO VŠECHNY čtenáře, kteří mají knihu půjčenou 2.1. IF čtenář měl knihu vrátit AND dostal již upomínku 2.1.1. Systém zaznamená u čtenáře výši pokuty 2.1.2. Systém pošle čtenáři info o udělené pokutě Případ užití: RezervujKnihu Preconditions: 1. Jsou zobrazeny detailní informace o knize Tok událostí: 1. Čtenář klikne na „rezervovat knihu“. 2. Systém uloží čtenáře do fronty rezervací a zobrazí výsledek. Rozšiřující případ užití: OdmitniRezervaci 1. Systém vyhledá výpůjčky čtenáře 2. IF existuje zpožděná výpůjčka 2.1. Systém zamítne rezervaci 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 45 Vztah <> (V) Případ užití: RezervujKnihu Preconditions: 1. Jsou zobrazeny detailní informace o knize Tok událostí: 1. Čtenář klikne na „rezervovat knihu“. 2. Systém uloží čtenáře do fronty rezervací a zobrazí výsledek. Použité bodyPoužité body rozšířenírozšíření ● Pokud vztah <> nespecifikuje body rozšíření, aplikuje se na všechny ● Rozšiřující p.u. musí mít přesně tolik segmentů, kolik bodů rozšíření používá ● Je dovoleno aby dva p.u. rozšiřovali základní p.u. ve stejném bodě, pořadí je pak ale náhodné 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 46 Vztah <> (VI) Případ užití: RezervujKnihu Preconditions: 1. Jsou zobrazeny detailní informace o knize Tok událostí: 1. Čtenář klikne na „rezervovat knihu“. 2. Systém uloží čtenáře do fronty rezervací a zobrazí výsledek. PodmínkyPodmínky rozšířenírozšíření Rozšiřující případ užití: UlozPokutu 1. PRO VŠECHNY čtenáře, kteří mají knihu půjčenou 2.1. IF čtenář měl knihu vrátit AND dostal již upomínku 2.1.1. Systém zaznamená u čtenáře výši pokuty 2.1.2. Systém pošle čtenáři info o udělené pokutě Rozšiřující případ užití: OdmitniRezervaci 1. Systém vyhledá výpůjčky čtenáře 2. IF existuje zpožděná výpůjčka 2.1. Systém zamítne rezervaci 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 47 Pojišťovna: Rozšíření p.u. (I) Demo 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 48 Pojišťovna: Rozšíření p.u. (II) Use Case: VyrizeniNovychSmluv Primary Actor: PracovnikOddSmluv Preconditions 1. Pracovnik oddeleni smluv je prihlaseny do systemu 2. System pri zadavani zadosti overil, ze nechybi nezbytne udaje, zejmena rodne cislo zadatele Flow of Events ... 3.3.2 IF PracovnikOddSmluv kline na "vytvorit novou smlouvu" 3.3.2.1 System zobrazi formular pro zalozeni nove smlouvy s preddefinovanymi informacemy z zadosti 3.3.2.2 PracovnikOddSmluv vyplni pozadovane informace a potvrdi vytvoreni smlouvy 3.3.2.3 System smlouvu ulozi do databaze ... Use Case: VernostniProgram Extension point: vernostniProgram Flow of Events 1 System zjisti prumernou vysi pojistneho z drivejsich smluv a platebni moralku pojistence a vypocita slevu na pojistnem 2 System upravi cenu pojisteni ve formulari podle vypocitane slevy Demo 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 49 Dědičnost aktérů • Aktér obchodní zástupce je podtypem aktéra kupující • Specializovaný aktér plní stejnou roli jako obecnější aktér, a pravděpodobně další roli navíc • Specializovaný aktér se účastní ve všech případech užití, ve který se účastní obecnější (dědí spouštění případů užití „nadaktéra“) 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 50 Dědičnost případů užití 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 51 Dědičnost případů užití (II) • Specializovaný p.u. může – dědit rysy z rodiče – přidávat nové rysy – přepisovat (měnit) zděděné rysy • V dokumentaci specializovaného p.u. se doporučuje následující notace, kdy v závorce je číslo, které odpovídá rysu z rodiče Rys Dědění Přidání Změna Vztah A A N Bodrozšíření A A N Vstupní podmínka A A A Výstupní podmínka A A A Krok v toku událostí A A A Rys je... Příklad Zděděný beze změny 3. (3.) Zákazník vloží požadovaná kriteria. Zděděný a přečíslovaný 6.2 (6.1) Systémsdělí zákazníkovi, že odpovídající produkt nebyl nalezen. Zděděný a změněný 1. (o1.) Zákazník vybere „vyhledej knihu“. Zděděný, změněný a přečíslovaný 5.2 (o5.1) Systémzobrazí stránku s detaily maximálně pěti knih. Přidaný 6.3 Systémznovu zobrazí vyhledávací stránku. 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 52 Podrobnější model rozhraní Může být užitečné podrobněji dokumentovat rozhraní systému (vymezené pomocí případů užití) např.: • Obrazový scénář (pro grafická uživatelská rozhraní) • pouze náčrtky ukazující různé obrazovky • diagram ukazující posloupnost obrazovek • prototyp uživatelského rozhraní (prověření motivace !!!) • Definice protokolu (pro systémová rozhraní) • např. při výměně XML zpráv definujte tyto zprávy • Interakční diagramy na různých úrovních abstrakce • mezi aktéry a systémem, asynchronní události • popis vlevo • strukturovaná angličtina nebo závorky pro různé cesty • různé úrovně abstrakce ! 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 53 Shrnutí případů užití • vymezení problému (iterativní proces) • odhalení hranic systému • diskuse požadavků s koncovými uživateli • specifikace vnějšího chování systému, funkčních požadavků pro vývojáře systému • výchozí bod pro návrh (diagramy tříd, interakční diagramy) • rozdělení podrobnější analýzy požadavků podle případů užití • rozdělení konstrukčních iterací podle případů užití • odvození testovacích případů, odvození uživatelské dokumentace • znovupoužití, architektura (viz literatura) • velikost projektu a odhad ceny (viz kniha G. Schneider) • …… 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 54 Rady pro modelování případů užití • Odvoďte případy užití z firemních procesů nebo procházením seznamu aktérů • Jako první identifikujte primární scénáře – zamyslete se nad vztahy <> – odsouhlaste s uživateli – systém by měl být optimalizován pro primární scénáře • Soupis alternativ provádějte až po akceptaci základních p.u. – zamyslete se nad vztahy <> – alternativy nepopisujte detailně • Diagramy se průběžně zpřesňují 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 55 Rady pro modelování p.u. (II) • Vytvářejte krátké a jednoduché p.u. – jen nezbytné detaily – z praxe: hlavní tok událostí by se měl vejít na jednu stránku • Zaměřte se na coco, ne na jakjak – modelujeme coco aktéři dělají, ne jakjak to dělají ... 4. Systém požádá Zákazníka o potvrzení objednávky. 5. Zákazník klikne na tlačítko OK. ... ... 4. Zákazník potvrdí objednávku. ... 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 56 Rady pro modelování p.u. (III) • Vyhněte se funkční dekompozici 23.2.2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 57 Knihy o případech užití • mnoho knih, zaměřených podle předmětných oblastí (obchod, telekomunikace, aj.) • dobré všeobecné knihy o případech užití: • Applying Use Cases, G. Schneider: krátká, dobrý úvod, průvodce tvorbou a dokumentací případů užití, jak definovat architekturu založenou na případech užití a cenový odhad na jejich základě; • Software Reuse, Jacobson, Griss, Jonsson: tvorba složitých a znovupoužitelných systémů a architektur, aplikace případů užití při řešení takových systémů; UseCases se používají (nejen) pro stanovení požadavků u velkýchUseCases se používají (nejen) pro stanovení požadavků u velkých projektů:projektů: http://www.w3.org/TR/mmi-use-cases/http://www.w3.org/TR/mmi-use-cases/