2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 1 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 2 UML (2) diagramy popisující statickou strukturu systému © 2008 Radek Ošlejšek FI MU Brno oslejsek@fi.muni.cz http://www.fi.muni.cz/~oslejsek/PA103 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 3 Diagram tříd (Class Diagram) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 4 Typ vs. instance • Diagram tříd (Class Diagram, CD) je grafický pohled na statickou strukturu – modeluje třídy (typy) a jejich vztahy • Diagram objektů je instancí diagramu tříd – ukazuje snímek systému v určitém časovém bodě • Typ – instance: – třída – objekt – asociace – spoj – parametr – hodnota – operace - volání 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 5 Třídy Window +default­size:Rectangle #maximum­size:Rectangle +create ()  +display ()  +size:Area = (100,100) #visibility:Boolean = invisible +hide ()  ­xptr: XWindow* ­attachXWindow(xwin:Xwindow*) {abstract, author=Joe, status=tested} +name:String {frozen} ­colors[3]: Color Window display ()   size: Area visibility: Boolean hide () potlačené detaily detaily analytické úrovně (typy a parametry mohou být také potlačeny) detaily implementační úrovně Window 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 6 Třídy (II) Viditelnost: + public - private # protected Abstraktní třída: {abstract} Násobnost: [0..1] optional [∗] array, list Nezměnitelné: {frozen} Struktura atributů: viditelnost název: typ [násobnost] = počátečníHodnota info oinfo o třídě,třídě, názevnázev oddíloddíl operacíoperací (metod)(metod) +create ()  Window +default­size:Rectangle #maximum­size:Rectangle +create ()  +display ()  +size:Area = (100,100) #visibility:Boolean = invisible +hide ()  ­xptr: XWindow* ­attachXWindow(xwin:Xwindow*) {abstract, author=Joe, status=tested} +name:String {frozen} ­colors: Color[3] oddíloddíl atributůatributů Struktura operací: viditelnost název(názevArg: typArg, ...): návratovýTyp signatura operacesignatura operace povinnépovinnénepovinnénepovinné nepovinnénepovinné 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 7 Generalizace / specializace • Generalizace je vztah mezi obecným a specifičtějším elementem (třídy, případy užití, rozhraní), který: – je plně konzistentní s obecným elementem – a přidává dodatečnou informaci Strom Smrk Dub Bříza druh diskrimininátordiskrimininátor - nepovinný - určuje, podle které charakteristiky nadtřídy je prováděna abstrakce - každá podtřída má jedinečnou hodnotu diskriminátoru generalizace specializace 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 8 Generalizace - ozdůbky • Ozdůbky: » {overlapping} nebo {disjoint} » {incomplete} nebo {complete} Osoba Zaměstnanec Prodejce Externista {disjoint} Firma Zákazník Dodavatel {overlapping} výlučná specializacevýlučná specializace nevýlučná specializacenevýlučná specializace Osoba je: - buď zaměstnanec, nebo prodejce, nebo externista. Firma je: - zákazníkem, nebo dodavatelem, nebo obojím. 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 9 Generalizace – styl zápisu Shape Polygon Ellipse Spline {overlapping} styl odděleného cílestyl odděleného cíle Shape Polygon Ellipse Spline {ovelapping} styl sdíleného cílestyl sdíleného cíle 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 10 Příklad „zneužití“ dědičnosti (I) Vehicle WindPoweredVehicle MotorPoweredVehicle LandVehicleWatherVehicle 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 11 Příklad „zneužití“ dědičnosti (II) Vehicle WindPoweredVehicle MotorPoweredVehicle LandVehicleWatherVehicle power power venue venue 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 12 Příklad „zneužití“ dědičnosti (III) {overlapping} Vehicle WindPoweredVehicle MotorPoweredVehicle LandVehicleWatherVehicle power power venue venue TruckSailboat 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 13 Asociace mezi třídami • Zobrazují se jako plná čára mezi dvěma třídami • Měly by být pojmenovány, šipka u jména implikuje směr čtení • Role určuje způsob, jakým se na asociaci podílí – pojmenování role není povinné – alternativa k pojmenování asociace • Násobnost definuje počet objektů ve vztahu (je definována na úrovni instancí) • Jsou obousměrné (výhodné pro analýzu) pokud neupřesníme směr (většinou při návrhu) • Modelujeme pouze statické asociace 11..* 11..* employee employer worksFor Person Person Company Company 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 14 Násobné asociace • Mezi instancemi mohou vnikat různé typy statických vazeb – Př: zaměstnanecký vztah vs. Akcionářský vztah mezi osobou a firmou stockHolder stockEmitter employee employer Person Company 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 15 Asociační třídy • Angl: Association class • Asociační třída vzniká jako produkt vztahu • Uchovává dodatečné informace o vzniklém propojení • Používá se často během analýzy, v návrhu se dekomponuje Osoba Firma *1..* zaměstnanec zaměstnavatel je zaměstnána v Smlouva asociační třídaasociační třída 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 16 Reflexivní asociace • Angl.: Reflexive association • Měly by mít vždy role, jinak vzniká chaos • Další “ozdoby” asociací: » uspořádání: {ordered} » měnitelnost: {addOnly} » viditelnost: +, #, » navigace: směrové šipky » omezení: {union}, {subset}, {unique} Vedoucí může řídit víceVedoucí může řídit více pracovníků, pracovník můžepracovníků, pracovník může být řízen jedním vedoucímbýt řízen jedním vedoucím Osoba atributy vedoucí 0..1 pracovník * řídí binární asociacebinární asociace 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 17 Vztah závislosti Vztah závislosti (angl. dependency) je nejobecnější vazba. Závislost mezi dvěma elementy (např. třídami) indikuje, že změna v cílovém elementu (např. rušení) může vyžadovat změnu ve zdrojovém elementu, ale ne naopak. Některé předdefinované stereotypy: x Zdrojový element (Factory) nepracuje bez cílového elementu (Transport): <> x Historicky odlišné elementy (nový = zdroj, starý = cíl) na různých úrovních abstrakce, ale reprezentující shodný koncept: <> x Zdrojový element vytváří instance cílového elementu: <> x Přátelský vztah ala C++: <> 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 18 Pojišťovna: Analytický model Demo 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 19 Diagram objektů (Object Diagram) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 20 Objekty jimsAccount:Account accountNumber : String = „12345“ owner : String = „Jim Arlow“ balance : double = 300.00 přihrádka pro jméno přihrádka pro atributy • Syntaxe názvu: jméno objektu : jméno třídy [jména stavů] – :Account – anonymní objekt dané třídy – jimsAccount – konkrétní objekt bez specifikované třídy, užitečné především v počátečních fázích analýzy – jimsAccount:Account – konkrétní instance třídy; nutné pokud je v diagramu více instancí jedné třídy • Název je vždy podtržený, doporučuje se tzv. „lowerCamelCase“ • Formát pro atributy: jméno : typ = hodnotajméno : typ = hodnota – typ se často vynechává, protože je uvedený u třídy • Zobrazení atributů není povinné, záleží na účelu diagramu jimsAccount:Account 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 21 Diagram objektů • Snímek v časovém bodě, který ukazuje podmnožinu objektů, jejich stavů, hodnot atributů a propojení. • Místo o asociaci mluvíme o spojení • Vhodné zejména pro komunikaci se zákazníky (konkrétní příklad hierarchie, ...) • Syntaxe: jméno objektu : jméno třídy [jména stavů] PCSestava:Zboží Monitor:Zboží Skříň:Zboží diagram objektůdiagram objektů Zboží * * diagram tříddiagram tříd předseda sekretářka člen lyžařskýKlub:Klub jim:Osoba fab:Osoba chris:Osoba rolerole Klub Osoba asociaceasociace lyžařskýKlub:Klub jim:Osoba předseda spojeníspojení 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 22 Pokročilé modelování v diagramu tříd 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 23 Agregace • Angl. Aggregation • Speciální případ asociace pro vztah celek-část • Symbol prázdného diamantu • Tranzitivní – pokud je píst součást motoru a motor součástí auta, pak je i píst součástí auta • Asymetrická – pokud je motor součástí auta, pak auto není součástí motoru – diagram objektů musí být acyklický Auto Motor Opravna 1 agregaceagregace • Sémantika: – totéž co asociace, pouze zdůrazňujeme vztah celek-část – součásti mohou existovat nezávisle na celku – součást může být sdílena více celky 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 24 Kompozice • Angl. Composition • Silnější forma agregace • Symbol plného diamantu • Tranzitivní a asymetrická • Sémantika: – na úrovní instancí (objektů) části neexistují vně celku – každá část patří pouze do jediného celku (části nelze sdílet) – je-li celek zničen, musí zničit i svoje součásti, nebo převést zodpovědnost za ně na jiný objekt Objednávka PoložkaObjednávky kompozicekompozice Objednávka položka:PoložkaObjednávky jiný způsob zápisujiný způsob zápisu **položka 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 25 Vlastnosti agregace a kompozice (I) Celek Část 1 Celek Část 0..1 Celek Část 1..* Celek Část 0..* • Které modely jsou správně a které naopak špatně z důvodu vlastností agregace a kompozice? ... odpověď na další obrazovce >> 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 26 Vlastnosti agregace a kompozice (II) Celek Část 1 Celek Část 0..1 Celek Část 1..* Celek Část 0..* správněsprávně totéž co bez kardinality špatněšpatně část neexistuje bez celku špatněšpatně část je součástí jediného celku správněsprávně ... odpovědi z předchozí stránky: 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 27 Vlastnosti agregace a kompozice (IV) • Které modely jsou správně a které naopak špatně z důvodu vlastností agregace a kompozice? ... odpověď na další obrazovce >> Auto Motor Letadlo 1 1 Auto Motor Letadlo 0..1 0..1 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 28 Vlastnosti agregace a kompozice (V) Auto Motor Letadlo 1 1 špatněšpatně - část nesmí být sdílená Auto Motor Letadlo 0..1 0..1 správněsprávně motor je součástí auta nebo letadla, nikdy ne současně vlastnost/problém:vlastnost/problém: motor se může přestěhovat z auta do letadla ... odpovědi z předchozí stránky: DopravniProstredek Motor 1 Auto Letadlo 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 29 Vlastnosti agregace a kompozice (VI) Produkt * * a:Produkt b:Produkt c:Produkt Produkt * * a:Produkt b:Produkt c:Produkt • Které modely jsou správně a které naopak špatně z důvodu asymetrie agregace? 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 30 Vlastnosti agregace a kompozice (VII) Produkt * * a:Produkt b:Produkt c:Produkt existence cyklů není povolenaexistence cyklů není povolena (na úrovni objektů!)(na úrovni objektů!) korektní diagramkorektní diagram Produkt * * a:Produkt b:Produkt c:Produkt správněsprávně pokud potřebujemepokud potřebujeme cykly na úrovni objektůcykly na úrovni objektů ... odpovědi z předchozí stránky: 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 31 Poznámky • Poznámka může připojit libovolnou textovou informaci k libovolnému prvku pole – v poznámkovém okénku – např. doplňující vysvětlení, otevřené otázky, stav prověrky, seznam nevyřešených úkolů, ... • Poznámky jsou k dispozici ve všech UML diagramech Třída nějaká poznámka o třídě provázání poznámky a prvku modeluprovázání poznámky a prvku modelu 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 32 Omezení v CD • Omezení specifikuje podmínky a tvrzení, které musí být udržovány jako pravdivé – umístěno bezprostředně za elementem, na který je aplikováno (např. atribut), připojeno čárkovanou čarou, nebo v poznámce – vždy v {} Účet Osoba Firma {or} Osoba Komise * je členem *1 je předsedou * {select} nějaká poznámka o třídě poznámkapoznámka Firma * 1..* zaměstnavatel zaměstnanec Osoba vedoucí 0..1 pracovník * řídí {Osoba.zaměstnavatel = Osoba.vedoucí.zaměstnavatel} omezeníomezení 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 33 Odvozené atributy a asociace • Odvozený element (angl. derived) je takový, který může být odvozen z jiného elementu – je ukázán pro názornost (analytická úroveň) – je zahrnut z implementačních důvodů (úroveň návrhu) – nepřidává žádnou sémantickou informaci Osoba datumNarozeni /vek {vek = aktualniDatum - datumNarozeni} Firma Oddělení *1 zaměstnanec zaměstnavatel Osoba 1 * oddělení zaměstnavatel 1 * pracuje pro oddělení /pracuje pro firmu {Osoba.zaměstnavatel = Osoba.oddělení.zaměstnavatel} odvozený elementodvozený element pravidlo výpočtupravidlo výpočtu 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 34 Rozhraní • Angl. Interface • Speciální třídy, které definují externě viditelné služby nějaké třídy nebo komponenty, bez specifikace interní struktury (atributy, stavy, implementace metod). • Často popisují pouze část, nikoliv celé chování příslušné třídy. • Používají stejné vztahy jako třídy, navíc ještě vztah realizace (angl. realization). • Dvě notace. HotelManager IHotelMngmt realizacerealizace <> IHotelMngmt reservation() HotelManager rozhranírozhraníRozhraní = nabídka služeb realizovaných třídami 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 35 Rozhraní: dvě notace (příklad) realizacerealizace <> Hashable hash(): Integer <> Comparable equals(Object): Boolean String hash(): Integer equals(Object): Boolean HashTable závislostzávislost <> <> String ..... isEqual(String):Boolean hash():Integer HashTable Hashable Comparable 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 36 Asociace s kvalifikátorem • Angl: Qualified association • Slouží k výběru jednoho člena cílové množiny pomocí jednoznačného identifikátoru (klíče) • Kvalifikátor se obvykle odkazuje na atribut cílové třídy • Kvalifikátor je součástí asociace, nikoliv třídy! kvalifikátorkvalifikátor Kombinace {Club, memberID}Kombinace {Club, memberID} specifikuje jedinečný cílspecifikuje jedinečný cíl Máme např. objekt typuMáme např. objekt typu ClubClub spojený sspojený s množinou objektů typumnožinou objektů typu MemberMember. Jak najít. Jak najít konkrétní instanci třídykonkrétní instanci třídy MemberMember?`?` 1 1 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 37 Parametrizované třídy, šablony Parametrizovaná třída definuje rodinu tříd. Nelze ji přímo použít, je nutné ji nejprve instanciovat přiřazením potřebných typů. Instanciace teprve vytvoří použitelnou třídu. Příklad: třída Set – reprezentuje kolekci objektů nějaké třídy. Tato třída se stává parametrem parametrizované třídy např. množina mincí, množina studentů, množina Set Insert(T) Remove(T) TT ParametrParametrizovaná třída StudentSet <> Student> Na rozdíl od specializace třída StudentSet nemůže přidávat ani atributy, ani služby. 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 38 Př: Analytický model tříd 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 39 Př: Návrhový model tříd (bez balíků) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 40 Pojišťovna: Část návrhového modelu Demo 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 41 Diagram balíků (Package Diagram) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 42 Balíky • Angl: Packages • Umožňují seskupit třídy a další modelové prvky (compile-time grouping) – do systémů (stereotyp <>) • obsahuje všechny třídy (celý modelovaný systém) – do subsystémů (stereotyp <>) – do soustavy (stereotyp <>) • Modelované samostatně v diagramu balíků nebo v rámci diagramu tříd – diagram balíků nemá třídy, soustředí se opravdu jen na balíky • Základní vazby: generalizace/realizace, „containment“ a závislostzávislost • Balík definuje jmenný prostor pro svoje elementy. Každý element lze jednoznačně identifikovat kvalifikovaným jménem (posloupnost jmen balíků a podbalíků od kořene až po daný element, např. ProdejceAut.Servis.Zakazka) • Balík definuje viditelnost svých elementů (private nebo public), viz. balíky v Javě. 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 43 Balíky - notace <> Finances + Credits + BankInterface - Accounts <> Finances <> Finances <> Credits Accounts <> BankInterface <> Finances <> Credits Accounts <> BankInterface 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 44 Balíky - závislosti Dodavatel Klient <> Dodavatel Klient <> Dodavatel Klient <> Dodavatel Klient <> Některý element klienta závisí na některém elementu z dodavatele. Totéž co bez stereotypu. Vhodné pro analýzu, v návrhu se upřesní <> nebo <> <> + jmenný prostor dodavatele se sloučí se jmenným prostorem klienta, nemusí se používat plně kvalifikovaná jména. <> + jmenné prostory zůstávají oddělené. Klient je dalším vývojovým stupněm dodavatele (v průběhu analýzy se balík Dodavatel změnil na Klient) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 45 Balíky – závislosti (II) • <> není tranzitivní: – elementy v balíčku A vidívidí elementy v balíčku B, – elementy v balíčku B vidívidí elementy v balíčku C, – elementy v balíčku A nevidínevidí elementy v balíčku C. => soudržnost modelu, jasnější zodpovědnost A B <> C <> • <> je tranzitivní: – elementy v balíčku A vidívidí elementy v balíčku C, – častější než <> 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 46 Balíky – závislosti (III) Příklad diagramu architektury ukazující subsystémy a jejich závislosti <> User Interface <> Business Rules Salary <> Database <> Business Rules Benefits 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 47 Subsytémy – kritéria návrhu • Každý subsystém by měl mít: – jedinou funkcionalitu – silnou kohezi • silné vztahy mezi třídami uvnitř subsystému – volné (externí) propojení • minimalizovat závislosti mezi subsystémy – znovupoužitelnost • komponenty • návrhové vzory – viz. další přednášky • Vyhněte se cyklické závislosti mezi balíky – cyklicky závislé třídy/podbalíky patří do jednoho balíku • spojení do jednoho balíku • přerozdělení na jiné balíky s acyklickými vztahy 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 48 Pojišťovna: Diagram balíků Demo Diagram tříd včetně balíků Přehlednější diagram balíků 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 49 Diagram komponent (Component Diagram) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 50 Modelování komponent • Model v etapě návrhu • Spojení konceptu balíků a rozhraní • Co je to komponenta? – Komponenta je jeden nebo více objektů sdružených do definovaného programového rozhraní – Komponenta poskytuje ucelený soubor služeb a je navržena pro vícenásobné použití – Komponenta je samostatně spustitelná a připojitelná za běhu Komponenty větší celky více rozhraní poskytují služby plně zapouzdřené obecně pochopitelné Objekty/třídy jemné subjekty jedno rozhraní poskytují operace využívají dědičnost, asociace pochopitelné pro vývojáře 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 51 Diagram komponent • Angl: Component Diagram • Ukazuje strukturu kódu – rozhraní – kolekce operací které jsou poskytovány nebo vyžadovány komponentou, viz. třídy – komponenta – vyměnitelná část systému; může obsahovat vnitřní strukturu (propojené komponenty nižší úrovně) – port – “okno” do uzavřené komponenty akceptující zprávy z/do komponenty odpovídající specifikovanému rozhraní komponentakomponenta vyžadované rozhranívyžadované rozhraní poskytované rozhraníposkytované rozhraní portport 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 52 Pojišťovna: Diagram komponent Demo 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 53 Diagram vnitřní struktury (Composite Structure Diagram) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 54 Diagram vnitřní struktury • Angl: Composite Structure Diagram, CSD • Novinka od UML 2.0 • Ukazuje strukturu složitých tříd – rozhraní – kolekce operací které jsou poskytovány nebo vyžadovány komponentou, viz. třídy – část – nejsou to instance tříd, jsou vnímány obecněji – port – “okno” do uzavřené komponenty akceptující zprávy z/do komponenty odpovídající specifikovanému rozhraní • Na rozdíl od balíků ukazuje rozdělení systému za běhu (runtime grouping) • Podobná notace jako u komponent. 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 55 CSD: Příklad Složitá třída s rozhranímiSložitá třída s rozhraními Interni pohled na tříduInterni pohled na třídu Použití portůPoužití portů 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 56 Diagram rozmístění (Deployment Diagram) 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 57 Diagram rozmístění • Angl: Deployment Diagram • Model v etapě návrhu a implementace • Ukazuje strukturu spustitelného programu • Fyzické rozmístění systému Planner Scheduler <> meetingsDB reservations AdminServer:HostMachine Joe'sMachine:PC 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 58 Pojišťovna: Diagram rozmístění Demo 2. 3. 2009 PA103: OO metody návrhu IS © R. Ošlejšek, FI MU 59 Tipy pro strukturální modelování ● Definujte „kostru“ (nebo „páteř“), kterou lze rozšiřovat a upravovat poté, co získáte více poznatků o předmětné oblasti. ● Soustřeďte se na správné použití základních konstrukcí; pokročilejší konstrukce a/nebo notaci přidávejte jen, pokud je to požadováno. ● Odložte implementační úvahy na pozdější etapu modelování. ● Strukturální diagramy mají ● zvýraznit určitý aspekt strukturálního modelu ● obsahovat klasifikátory na stejné úrovni abstrakce ● Při větších počtech klasifikátorů by měly být zavedeny balíky.