Objektový návrh IS Přístup k návrhu vychází ze strukturovaného přístupu Přebírá P3A, není tak výrazné odlišení analýzy a designu Odlišnost vyjádření objektů reálného světa 1
druhá polovina 80.let historie objektový přístup a objektové modelování vycházelo ze strukturovaných metod jen datový a funkční model byl nahrazen modelem objektovým Postupně více než 50 objektových metod a metodik Metody a metodiky lze rozdělit do tří generací první generace do začátku devadesátých let druhá generace zahrnuje více metod a metodik, které se vzájemně ovlivňovaly v dalších verzích modely používané v jiných metodách vypuštěny modely dříve používané modely upraveny dochází k postupnému zmenšování jejich odlišností, snaha po standardizaci třetí generace standardizace, OMG, ODMG 2
OMG (Object Management Group) uskupení firem které se zabývají objektovými technologiemi cílem vytvořit doporučený standard, usiluje o unifikovaný rozvoj teorie v dané oblasti. 3
Meto dika BO OCH BO N B ORM CRC Hl avní n ávrháři Grady Booch Je an Marc-N erson, Ki m W ald en Roger Knott, V ojtěc h M erunka, Jiří P olák W a rd C unningham, Rebecca Wi rfs-brock Ge ne race 1. 2. 3. 2. V hod nost pr o tvo rb u softwaru *** ** ** ** Vhod nost p ro výuk u * *** ** *** Vh odn ost pro bu siness mod elován í * ** *** ** Z aměře ní An alýza/desig n/ I mp lem entace */***/*** */**/** ***/**/** **/**/** Char akter istické rysy k omplexnost, ori entace na C+ +, zaměření na desi gn a implemen tac i j ednoduchost, integrovaná podpora principů kont raktu, nepříl iš vhodná podpora dynami cké ho m odelová ní ori enta ce směre m k business a proces nímu mod elování extrém ní je dnoduchost, s rostoucím rozsa hem mode lovaného syst ému klesá efe ktivnost pou žití CRC Prostředky pr o statické mod elován í cl ass di agram s, objec t diagrams, module di agram s, proc ess diagrams class diagrams obje ct relat ionship dia gra m (+ větši na dia gramů U ML) N /A Pr ostře dky p ro d ynam ic ké mod elován í st ate transi tion diagra ms, int eraction dia grams object di agrams obje ct relat ionship dia gra m (+ větši na dia gramů U ML) N /A Podp ora ze stra ny C AS E *** * * *** Pří klad nab ízenýc h C ASE Rational Rose,... EiffelC ase Met a Edit+ QuickC RC, C RCP at terns, CR C Pro,... * - čí m více hvězd iček, tím lépe COAD/YOURDON OMT OBJECTORY/OOSE OPEN SHLAER/MELLOR UML Peter Coad, Edward Yourdon James Ru mbaugh Ivar Jacobson Donald Firesmith, Ian Graham, Meilir Page- Jones, Brian Henderson Sellers Stephen J. Mellor, Sally Shlaer Grady Booch, Ivar Jacobson, James Rumbaugh 2. 2. 2. 3. 1. 3. ** *** ** *** *** *** ** * ** * * * ** ** *** ** * ** **/**/** **/**/** ***/**/** ***/***/*** **/**/** ***/***/*** jednoduchost, slabá podpora dynamického modelování, koncepce vrstvového pohledu object diagrams (jako součást object model) scenario view, object state diagrams značně ovlivněna strukturovanými metodikami, vhodná i pro datové modelování class diagrams use case diagrams, state transition diagrams, event flow diagrams, data flow diagrams vývoj systému řízen důsledně Use Case modelováním, vhodná i pro business modelování problem domain object model, interface descriptions use case diagrams, interaction diagrams, state transition graphs komplexní metodika se širokým záběrem, otevřenost k dalším nástrojům, staví na sjednoceném metamodelu COMMA context diagrams, layer diagrams, configuration diagrams,cluster diagrams,inheritance diagrams, deployment diagrams,... collaboration diagrams, sequence diagrams, state transition diagrams, use case diagrams,... translační přístup (vs.evoluční přístup), orientace na dyn. modelování, vhodná pro realtime systémy Class diagrams, dependency diagrams, class structure diagrams, inheritance diagrams,... state transition diagrams, action data flow diagrams, object communication diagrams,... komplexnost, orientace na C++ a Javu, doporučený standard OMG, pouze notace Class diagrams, deployment diagrams, component diagrams sequence diagrams, collaboration diagrams, activity diagrams, state transition diagrams, use case diagrams ** *** ** ** ** **** Playground Rational Rose,... Select, N/A ObjectMaker, SimplyObjects BridgePoint, OpenTool COOL: Jex, Rational Rose ObjectIF, Together, With- Class,... 4
České prostředí metodika OOMT (Objektově orientované metodiky a technologie) grant VŠE (Drbal a kol.) zčásti vyvíjena metodika BORM ( Business Object Relation Modeling Knot, Merunka, Polák Prvním a jediným standardem v oblasti objektového modelování IS je UML Objektové paradigma 5
Objektové paradigma Zapouzdření Dědičnost Polymorfismus OID Objektové paradigma Týká se tříd a jejich definice atributy vlastnosti metody (operace) funkce Abstrakce: třída Instance: objekt 6
Objektové paradigma zapouzdření Public + veřejný přístup prvek s přístupem ke třídě může používat vlastnosti a funkce deklarované jako veřejné Private - soukromý přístup přístup k vlastnostem a funkcím - pouze operace uvnitř dané třídy) Protected # chráněný přístup přístup k vlastnostem a funkcím- pouze operace uvnitř dané třídy a uvnitř jejich potomků Objektové paradigma - dědičnost a polymorfismus dědičnost je uplatnění generalizace (víceúrovňová hierarchická abstrakce) Třídy mohou vytvářet hierarchie (jednu i více) třída nižší úrovně (potomek) dědí všechny vlastnosti třídy vyšší úrovně (rodiče) funkce dědí nahrazuje zděděné vlastnosti (data i metody) lze doplnit speciálními (u metod i dat) či je nahradit (metody) 7
OID - object identifier každému objektu je přiřazeno OID, když je objekt vytvořen je generován systémem uživatel nemůže měnit, max může číst, ideálně není vůbec viditelný je jedinečný, neměnný po dobu existence objektu unikátnost platí v rámci celého systému nebude znovu použito pro jiné objekty ani po skončení existence objektu nezávisí na hodnotách jeho atributů Standardy UML prvním a jediným standardem v oblasti objektového modelování počty diagramů se mění, mění se i použití diagramů 8
Diagramy není ostrá hranice mezi analýzou a designem dělí se spíše z hlediska statického popisu popisu dynamiky chování Přehled modelů UML UML verze 2.0 Diagram aktivit Diagram tříd Diagram komunikace (dříve diagram spolupráce) Diagram komponent Diagram vnitřní struktury Diagram nasazení Diagram přehledu interakcí (varianta diagramu aktivit- zachycuje tok řízení v rámci procesu či systému) Objektový diagram Diagram balíčků Sekvenční diagram Stavový diagram (diagram stavů a přechodů) Diagram časování Diagram případů užití 9
Diagramy UML UML nedefinuje pořadí, v němž mají být diagramy tvořeny obvykle na počátku případ užití 10
Statické modely diagram tříd (Class Diagram) Objektový model Dynamické modely Use Case Diagram (Diagram užití, Model jednání) Diagram stavů a přechodů (Stavový diagram, State Transition Diagram, STD) Diagram činností (Activity Diagram) Diagram sekvencí (Sequence Diagram) Diagram komunikace (dříve Diagram spolupráce - Collaboration Diagram) Funkční model 11
Diagram tříd Objektový diagram Struktura tříd je založena na zodpovědnosti na zapouzdření Př. objekt Zákazník má inf. o zákazníkovi zachycuje chování zákazníka v S.; vznik, modifikaci, zánik (tj. život. cyklus) jiný objekt odpovědnost nepřebírá, pouze může požádat (pomocí zpráv) o poskytnutí služby (dát informaci, vytvořit záznam ) 12
Oddíl název Notace třídy název třídy povinný začíná velkým písmenem (pro každé slovo názvu velbloudí písmo ) Oddíl atributů Oddíl operací = vlastnost název atributu datový typ viditelnost Atribut atributy jsou nositeli informací o stavu objektu definují statickou strukturu objektu 13
Operace definují chování objektu dány název operace seznam parametrů, návratový typ (signatura operace) viditelnost operace abstraktní specifikace pro funkce objektu při analýze metody konkrétní specifikace v etapě návrhu operace aktualizace, typ interface poskytují rozhraní ostatním objektům Notace objektu Oddíl název názevobjektu: NázevTřídy slova názvu objektu podtržena název třídy začíná velkým písmenem (pro každé slovo názvu velbloudí písmo ) název objektu začíná malým písmenem, každé slovo názvu velkým písmenem (pro každé slovo názvu velbloudí písmo ) Oddíl atributů názvy atributů a jejich hodnoty názvy začínají malým písmenem 14
stereotypy Mechanismus na rozšíření << >> Př. <<entity >> <<instantiate>> << include >> << extend >> 3 mechanismy UML <<stereotyp>> instantiate, entity, boundary omezení násobnost (multiplicity) 15
Vztahy mezi třídami a objekty asociace Vztahy mezi třídami a objekty je vztah mezi třídami (binární, n-ární vztah) je skupina linků se společnou strukturou a společnou semantikou link je spojení mezi objekty, po kterém může být předána zpráva vysílající objekt prostřednictvím zprávy požaduje zaslání dat, či provedení operace linky téže asociace spojují objekty těchže tříd link je instancí asociace, asociace je abstrakcí linku 16
název Vztahy mezi třídami a objekty asociace sloveso (zaměstnává, je zaměstnán) role názvy rolí z podstatných jmen popisujících sémantiku (zaměstnanec, zaměstnavatel) buď role nebo název průchodnost násobnost není-li určena explicitně, pak se považuje za neurčitou vztahy mezi třídami asociace reflexivní asociační třídy př. osoba firma vztah M :N; plat je vlastností asociace atributy asociací kvalifikátor redukují asociaci typu M:N na N:1 asociace s kvalifikátorem používají kvalifikátor k výběru jedinečného objektu z cílové množiny průchodnost 17
vztahy mezi třídami Průchodnost jednosměrná asociace spojení od A do B je průchodné, naopak není obousměrná asociace průchodnost spojení v obou směrech A A B B vztahy mezi třídami asociace může být obecná jednostranná pouze jedna třída zná rozhraní druhé třídy oboustranná obě třídy znají rozhraní druhé třídy agregace je speciálním případem asociace objekt agregující třídy obsahuje jiné objekty ( skládá se z), t.j.objekt může být kontejnerem, který obsahuje objekty jiné třídy kompozice spec. případ asociace generalizace specializace dědičnost, polymorfismus 18
agregace agregované objekty většinou přístupné prostřednictvím agregujícího objektu - kontejneru pokud objekty budou obsaženy ve více kontejnerech, pak je jeden kontejner vlastní (a tím rozhoduje o jeho existenci), ostatní užívají Př. počítač tiskárna kompozice silnější vztah než agregace jednotlivé objekty nemohou existovat samostatně Př. objednávka:hlavička objednávky-řádek objednávky (stejný životní cyklus) 19
Benešovský, Richta: UML, alea iacta est! Datakon 2008, Závislost = relace v níž se změna v nezávislém (dodavatel) projeví v závislém (klient) znázorněny šipkou od klienta k dodavateli (tečkovaně) 20
Diagram tříd Multiplicita (násobnost) 21
Benešovský, Richta: UML, alea iacta est! Datakon 2008 Benešovský, Richta: UML, alea iacta est! Datakon 2008 22
Benešovský, Richta: UML, alea iacta est! Datakon 2008 Diagram tříd 23
Objektový diagram Objektový diagram Objektový diagram ukazuje objekty a jejich vazby v určitém okamžiku = snímky objektu 24
Use Case Diagram Use Case Diagram (Diagram užití, Model jednání) dynamický model určení funkčních požadavků na systém, upřesnění zadání, může být východiskem dynamického modelu i objektového modelu na počátku analýzy (může být použit i v jejím průběhu) 25
Základní Use Case Diagram slouží k oddělení systému od okolí a ke strukturalizaci okolí systému. Systém je chápán jako celek konstrukty aktor typ jednání scénář impuls - reakce Aktor (aktér) prvek podstatného okolí systému komunikuje s navrhovaným systémem Typ jednání logicky uzavřený popis komunikace mezi aktorem a vytvářeným systémem Jeden typ jednání může být použitelný více aktory jeden aktor může mít více typů jednání 26
i zpětně pomocí typu jednání se určují funkční požadavky na systém scénář popsán každý typ jednání obsahuje impulsy aktorů a reakce systému rozšířený model jednání v průběhu analýzy určuje komunikace mezi aktorem a třídou ne mezi aktorem a systémem jako v základním modelu vztah mezi typem jednání a třídou, vyjadřuje odpovědnost třídy 27
Diagram užití Specifikace případu užití Není standard obvykle šablona, kde v jednotlivých částech: 1. Název případu užití 2. Jedinečný identifikátor 3. Stručný popis 4. Aktéři primární, vedlejší 5. Stav systému před spuštěním případu užití 6. Kroky případu užití 7. Stav systému po skončení případu užití 8. Alternativní scénáře 28
Hlavní aktér zpravidla spouští případ užití Vedlejší aktéři v interakci po spuštění Vstupní podmínky omezení stavu systému před spuštěním (než je to možné) případu užití spustit (pravidla) Výstupní podmínky omezení stavu systému po skončení případu užití Kroky případu užití = tok událostí (scénář) hlavní zachycuje ideální případ vedlejší scénář větvení» zachycuje jednoduché odchylky alternativní scénář pro výrazné odchylky 29
příklad PlatitDaňZDPH ID:1 Stručný popis: na konci fiskálního čtvrtletí se zaplatí daň fin. úřadu Primární aktéři čas Vedlejší fin. úřad Vstupní podmínky konec fiskálního čtvrtletí příklad Hlavní scénář 1. případ užití začíná na konci fiskálního čtvrtletí 2. S. zjistíčástku k platbě fin. úřadu 3. S. odešle částku fin. úřadu Výstupní podmínky fin. úřad přijímá platbu ve správné výši Alternativní scénáře žádné 30
Rozvětvení hlavního scénáře KDYŽ (IF) PŘ. nákupní košík 2. KDYŽ zákazník zadá odstranit položku z košíku» 2.1. S. odstraní položku z košíku 3.KDYŽ zákazník zadá nové množství» 3.1. S.aktualizuje množství FOR PŘ. vyhledání produktů 2. pokud S najde produkty, pak pro 2.1. každý nalezený produkt 2.1.1. S. zobrazí produkt 2.1.2. S. zobrazí informace o produktu 2.1.3. S. zobrazí cenu produktu 3. nebo 3.1. sdělí zákazníkovi že není hledaný produkt WHILE Př. podrobnosti o firmě 3. Dokud zákazník prochází podrobnosti o firmě: 3.1. S. přehrává hudbu na pozadí 3.2. S. zobrazí speciáolní nabídku Alternativní scénář obvykle se nevracejí zpět k hlavnímu scénáři pro výjimky a chyby v hlavním scénáři lze je dokumentovat samostatně (lepší), nebo napojit na případ užití 31
Alternativní scénář Alternativní scénáře lze spustit: Místo hlavního scénáře Pak jej spustil hlavní aktér a alternativní scénář se stává scénářem hlavním až po kroku X hlavního scénáře Pak scénář začíná : 1.alternativní scénář začíná až po kroku X hlavního scénáře Lze ho spustit kdykoliv během realizace hlavního scénáře (př. storno) 1. alternativní scénář může začít kdykoli (uvedeno hned na počátku) Alternativní scénář Př. ID5 hlavní scénář vytvořit NovýÚčetZákazníka 2. Dokud jsou údaje Zákazníka neplatné 2.1. S. žádá zákazníka aby zadal všechny údaje 2.2.S. ověří údaje zákazníka 3. S. vytvoří nový účet Z. Alternativní scénář ID5.1. NovýÚčetZákazníka:NeplatnáAdresa 1. alternativní scénář začíná krokem 2.2. hlavního scénáře 2. S. informuje Zákazníka že zadal neplatnou adresu 32
Zobecnění případu užití Generalizace, specializace u aktoru Př. Zákazník VypsatSeznamProduktů, ObjednatProdukty ObchodníZástupce VypsatSeznamProduktů, ObjednatProdukty, VypočítatOdměnuZaZprostředkování pak generalizace Kupující Zobecnění případu užití Generalizace, specializace Př. Najít produkt (předek) najit knihu, najít CD (potomek) pokud předek nemá hlavní scénář pak se jedná o abstraktní scénář abstraktní scénář k zachycení chování na obecné úrovni- shrnutí chování, nelze spustit 33
Zobecnění případu užití << include >> vyčleňuje kroky společné několika případům užití do samostatného případu užití případ užití je do příslušných případů užití (z nichž je vyčleněn) zahrnut vyčleněný a následně zahrnovaný případ užití dodavatelský zahrnující případ užití klientský V klientském je třeba určit místo na kterém má být dodavatelský případ užití zahrnut Zobecnění případu užití << extend >> do existujícího případu užití vkládá nové chování v případu užití do něhož bude vloženo nové chování je určeno místo rozšíření je umístěno mezi kroky scénáře Př. vrácení knihy a u pozdě vrácené knihy výpočet pokuty 34
Zobecnění případu užití Použití: Aktoři pokud to zjednoduší model Případy užití málo, jen pokud jsou abstraktní předci << include >> jen pokud to zjednoduší model << exclude >> zřídka, sémantice použití musí rozumět a souhlasit s ní všichni uživatelé Diagram komunikace (spolupráce) Diagram sekvencí (Sequence diagrams) 35
Diagram komunikace (Diagram spolupráce) Diagram komunikace (Diagram spolupráce) 36
Sequence Diagrams Diagram aktivit 37
Diagramy aktivit Aktivita ovál název aktivity tvoří sloveso vyjadřující chování objektu, často následované podstatným jménem nebo spojením slov. Počáteční bod Koncový bod Přechod mezi aktivitami šipka ve směru ukončená aktivita - nová aktivita (směr toku řízení) Diagram činností/aktivit 38
39
Diagramy aktivit Pro popis dynamiky objektu spolu s diagramem stavů Stavový diagram Pro popis dynamiky objektu definuje možné stavy možné přechody mezi stavy události, které přechody iniciují podmínky přechodů akce,které s přechody souvisí 40
Stavový diagram Souběžné stavy (složený stav, composite state ) 41