Kurz Postupy návrhu IS pomocí UML a OOP (5 dnů, in-house)

Transkript

1 Kurz Postupy návrhu IS pomocí UML a OOP (5 dnů, in-house) přednáší RNDr. Ilja Kraval pořádá firma OBJECT CONSULTING Obsah: Kurz Efektivní postupy návrhu IS pomocí UML a OOP (5 dnů, in-house) Jak se software nemá dělat - nedoporučované postupy Metoda řízení vývoje IS zvaná TUNEL Základní filosofie objektového přístupu a jak jej správně chápat a prakticky používat Jak jsou definovány fáze analýzy, designu a kódu Jak použít syntaxi CLASS DIAGRAMU pro správný a efektivní návrh IS V čem spočívá pohled analytika a designéra na CLASS DIAGRAM a jaký je mezi nimi rozdíl Jak se prakticky nalézají třídy a jejich vztahy v analytickém modelu tříd Jak se hledá kompozice, její syntaxe a význam, co je atribut Jak se hledá běžná asociace - vztah do seznamu Důležitá vlastnost konce asociace IsNavigable K čemu slouží sdílená (neboli slabá) agregace Jak se hledá asociační třída, použití asociační třídy s vícero konci Jak hledat a používat vztah Generalizace Příklady na diagramy tříd, analytické cvičení Základní pojmy z OOP a Design Patterns Principy a pojmy OOP Návrhové vzory v OOP Přehled diagramů modelovacího jazyka UML a jejich praktické použití Přehled diagramů UML a jejich praktické zařazení Rozdělení diagramů podle nezbytnosti dokumentace... 11

2 4.3 Doporučení pro vedoucího při návrhu IS pomocí UML Stavba a syntaxe jazyka UML Extenzivní mechanismy UML Společné mechanismy UML PACKAGE, DEPENDENCY, vrstvení aplikace a správa modelů Použití, syntaxe a doporučený postup tvorby USE CASE DIAGRAMU BUSINESS PROCESS MODELING jako nejlepší metoda nalézání případů užití Syntaxe a tvorba USE CASE DIAGRAMU Nejčastější omyly při tvorbě USE CASE DIAGRAMU a jak se jich vyvarovat Praktické použití USE CASE DIAGRAMU v projektech Použití a syntaxe dalších diagramů UML Použití a syntaxe SEQUENCE A COMMUNICATION DIAGRAMU Použití a syntaxe STATE DIAGRAMU Použití a syntaxe COMPONENT DIAGRAMU Použití a syntaxe DEPLOYMENT DIAGRAMU strana 2

3 1. Jak se software nemá dělat - nedoporučované postupy 1.1 Metoda řízení vývoje IS zvaná TUNEL Tato úvodní kapitola vysvětluje nedoporučovaný avšak nejčastější postup při návrhu IS nazývaný metoda TUNEL. Na počátku projektu se vstupuje do černého tunelu, kterým se prochází poslepu tunelem od stěny ke stěně. Cestou se díky nárazům do stěn tunelu zjišťuje, kudy cesta nevede. Ve tmě TUNELU je vidět pouze pár kroků dopředu a všechna rozhodnutí vedoucího projektu jsou tedy přijímána ad hoc v dané situaci a většinou pouze hasí požáry. Kapitola dále také popisuje hlavní důsledky tohoto špatného postupu, zejména důsledky na vlastnosti a kvalitu SW. Kapitola také popisuje druhou velmi špatnou metodu a tou je Byrokratická metoda a popisuje její důsledky. Na konci kapitoly je učiněn velmi důležitý závěr související s metodou TUNEL, s vlastnostmi transparence SW a s objektovým přístupem. Řízení projektů metodou TUNEL a její nepříznivé důsledky o Důsledky pro firmu o Důsledky pro tým a jeho řízení o Důsledky pro samotný vyvíjený SW a jeho vlastnosti Objektové paradigma a proč TUNEL nemůže ze zásady tento princip dodržovat Řízení projektů Byrokratickou metodou její nepříznivé důsledky Objektové paradigma jako základ opuštění metody TUNEL 1.2 Základní filosofie objektového přístupu a jak jej správně chápat a prakticky používat Tato kapitola patří k základním kapitolám ve školení. Vysvětluje velmi podrobně a detailně, jak funguje objektové paradigma a jak jej chápat a to i na příkladech z praxe. Tato kapitola je stěžejní pro další výklad. Pokud není vývojář seznám s tímto principem, může se dopouštět hrubých chyb nejenom při použití OOP, ale dokonce už při analytickém návrhu IS. Objektový přístup umožňuje vývojáři, aby navrhoval své modely správně, korektně, efektivně a rychle. Současně umožňuje,aby pracovník odhaloval hned na počátku chyby v modelu a následně v kódu a to co nejdříve. Současně se v této kapitole účastník školení seznámí s nejčastějšími chybami při porušování objektového přístupu na konkrétních příkladech z praxe. strana 3

4 Rozdíl objektového a neobjektového přístupu Důsledky chybného ne-objektového přístupu Nejčastější chyby modelování IS Chyba tříštění objektů s příklady Chyba nečistých pojmů s příklady Chyba špatných kompetencí objektů a jak se jí vyvarovat 1.3 Jak jsou definovány fáze analýzy, designu a kódu Praktické zohlednění úrovně abstrakce (analýza, design, kód) patří mezi základní pilíře tvorby SW. Je třeba zdůraznit, že s problémy s úrovní abstrakce se potýká většina SW firem. Kapitola jasně a zřetelně vysvětluje, jak se toto zohlednění úrovní abstrakce promítne konkrétně do modelování v UML, jaké musí být povinně dodržovány role v projektu a jaké jsou tvořené dokumenty na každé úrovni abstrakce. Současně se na příkladech vysvětluje také chybné chápání úrovní abstrakce. V kapitole je také podán návod, jak tento způsob práce zavádět ve firmě a jakým postupům se určitě vyvarovat. Nejnižší úroveň abstrakce - kódování Nejvyšší úroveň abstrakce - analytické modelování Střední úroveň abstrakce modelování technického návrhu Čím se liší úrovně abstrakce? Pojem mapování z úrovně AM do D Analytické modelování jako abstraktní programování Problém podrobnosti a úplnosti analytického modelování Jak dosáhnout maximální efektivity přechodu z analytického modelování do designu a do kódu Podcenění analytického modelování a časované bomby v projektech Role v projektu: analytik, designér a programátor Příklady a ukázky chybných postupů strana 4

5 2. Jak použít syntaxi CLASS DIAGRAMU pro správný a efektivní návrh IS 2.1 V čem spočívá pohled analytika a designéra na CLASS DIAGRAM a jaký je mezi nimi rozdíl Pro modelování IS se jak na úrovni analytického modelování tak designu používá jazyk UML a popisuje se tentýž IS. Kapitola ukazuje, jak při tvorbě CLASS DIAGRAMU postupuje analytik a jak postupuje designér v technickém designu. Úroveň informace jako typ a výskyt, pojem meta úroveň, pojem třída v analytickém modelování Úroveň informace jako typ a výskyt, úroveň meta, pojem třída v technickém designu Dynamické a statické modely v analytickém modelování a designu Mapování z analytického modelování do designu, Jak má vypadat zadání od analytika pro design Jak postupuje analytik při vyhledávání analytických tříd 2.2 Jak se prakticky nalézají třídy a jejich vztahy v analytickém modelu tříd Model tříd patří k nosným modelům UML. V této kapitola je vysvětleno, jak se hledají třídy v IS a jak se hledají a popisují vztahy. Kapitola je doplněna spoustou příkladů. Vztah diagramu tříd a diagramu instancí Praktické a rychlé nalézání evidovaných instancí Praktické a rychlé nalézání konkrétních tříd Častá chyba meta-úrovně a její podstata, jak se jí vyvarovat strana 5

6 2.3 Jak se hledá kompozice, její syntaxe a význam, co je atribut Kompozice patří k prvním vztahům, které analytik při své práci s diagramem tříd vyhledává. Jedná se o poměrně dobře viditelný vztah a proto je dobré jej vyhledávat jako jeden z prvních. V kapitole jsou popsány vlastnosti kompozice jako zvláštního případu asociace, jsou vysvětleny základní vlastnosti asociace. Ve výkladu je prakticky zdůrazněno, co je povinností analytika popsat a co již nikoliv. Význam vztahu asociace a speciálně kompozice Použití vztahu s příklady Pojem multiplicita Jak fungují jednosměrné a obousměrné vztahy Co je to role Co je to atribut Mapování kompozice do objektového programování Mapování kompozice do relační databáze 2.4 Jak se hledá běžná asociace - vztah do seznamu Dalším velmi často se vyskytujícím vztahem v analytickém diagramu tříd je vzor zvaný běžná asociace - vztah do seznamu. V kapitole je vysvětleno, jak se tento vztah vyhledává, jak a kde se používá. Reprezentace a význam vztahu Použití vztahu s příklady Mapování vztahu do seznamu do OOP Mapování vztahu do seznamu do RDB 2.5 Důležitá vlastnost konce asociace IsNavigable Vlastnost konce asociace nazvaná IsNavigable bývá při modelování v CLASS DIAGRAMU bohužel z neznalosti velmi často zanedbávána, což k velmi chybným modelům, zejména špatně navrženým strana 6

7 vrstvám IS. Vlastnost IsNavigable se používá ve významu směrovosti vazeb a její správné použití vede v konečném důsledku ke správnému rozvrstvení systému. Naopak zanedbání v použití vlastnosti IsNavigable je prvním krokem k tvorbě velmi nepříjemných tzv. molochálních systémů, které nelze rozdělit na menší části. Této chyby se většinou dopouštějí bývalí dataři, protože datové modely RDB na rozdíl od objektového přístupu nepoužívají směrovost vazeb, vazby mezi daty v RDB jsou totiž v SQL příkazech vždy symetrické. Popis a vysvětlení významu vlastnosti IsNavigable Příklady použití vlastnosti IsNavigable Důsledky nepoužití vlastnosti IsNavigable Vztah k parentovi v kompozici ku N a jeho výjimečné vypnutí 2.6 K čemu slouží sdílená (neboli slabá) agregace Sdílená agregace je dalším vztahem, se kterým se může analytik a následně designér při návrhu IS v CLASS DIAGRAMU setkat. Kapitola podrobně vysvětluje podstatu tohoto vztahu, ukazuje, co má tento vztah společného s kompozicí a čím se od kompozice liší a pratkiocké použití tohoto vztahu. Vysvětlení vztahu sdílená agregace Příklady na sdílenou agregaci 2.7 Jak se hledá asociační třída, použití asociační třídy s vícero konci Ukazuje se, že asociační třída bývá bohužel velmi chybně chápána. Je to důsledek některých chybných vysvětlení vyskytujících v odborné anglické literatuře přeložené do češtiny. Ve školení je detailně a podrobně vysvětleno poslání a funkcionalita asociační třídy, k čemu slouží, jak se nalézá, a jak se mapuje do technologie OOP a RDB. Kapitola je doplněna o spoustu příkladů a základní vzory použití. Na základě pochopení z těchto příkladů účastníci školení následně nalézají asociační třídy velmi snadno a správně je používají. Vysvětlení asociační třídy Mapování do OOP Mapování do RDB Nejznámější vzory použití asociační třídy Příklady na asociační třídu strana 7

8 Příklady na asociační třídu s vícero konci 2.8 Jak hledat a používat vztah Generalizace Vztah Generalizace (slangově zvaný dědičnost) patří k velmi chybně používaným vztahům. Mnozí návrháři IS si neuvědomují základní rozdíl mezi vztahem zvaným asociace a vztahem zvaným Generalizace, což vede k velmi chybným řešením, doslova hrubkám v modelech. V kapitole je uvedeno podrobné vysvětlení vztahu Generalizace včetně vysvětlení, v čem spočívá jeho chybné použití a jak se hrubým chybám při použití Generalizace vyvarovat. Současně je vysvětleno i polymorfní chování a jak polymorfismus chápat již v analytické rovině návrhu IS. Vysvětlení vztahu Generalizace Zástupnost rolí a kompatibilita zespodu nahoru Základní vzory použití vztahu Generalizace (vzory Heterogenní seznam, Ukazatel na vrchol stromu atd.) Polymorfní chování a jeho podstata Mapování Generalizace do RDB (známé vzory) Mapování Generalizace do OOP Generalizace a technologie Hibernate Vzor Diskriminátor Anti-vzor Explose subtříd Příklady na Generalizaci a příklady na chyby použití Generalizace 2.9 Příklady na diagramy tříd, analytické cvičení V této části školení jsou jednak předloženy ukázkové příklady řešení IS a poté se řeší příklady účastníků školení, které si donesou ve formě zadání. Příklad Kusovník (evidence skládaného zboží) Vzor Party neboli Agenda Subjekty (podrobně rozebrán evidence osob i se vztahy) Agenda Číselníky Agenda Přístupová práva strana 8

9 3. Základní pojmy z OOP a Design Patterns Cílem kapitoly je seznámit účastníky s principy OOP a současně vysvětlit použití Design Patterns. V kapitole jsou také podrobně a detailně vysvětleny nejčastěji používané a nejdůležitější návrhové vzory GOF. 3.1 Principy a pojmy OOP V kapitole je jasně a srozumitelně vysvětleno, jaký je rozdíl mezi strukturálním programováním a objektovým programováním. Jsou ukázány jednak principy OOP a také jsou vysvětleny nejčastější chyb v chápání OOP, se kterými se autor ve firmách při zavádění OOP setkal. Objekt, třída, dědičnost, polymorfismus Asociace a dědičnost v OOP Abstraktní třída, abstraktní metoda, interface Příklady na OOP, vzor COMPOSITE 3.2 Návrhové vzory v OOP V kapitole jsou vysvětleny a rozebrány nejčastější a nejpoužívanější vzory z OOP. Důraz je kladen na praktické použití těchto vzorů včetně spousty příkladů z praxe. Vzor COMMAND Vzor OBSERVER Vzor DECORATOR Vzor SINGLETON Vzor STRATEGY Vzor INTERPRETER strana 9

10 4. Přehled diagramů modelovacího jazyka UML a jejich praktické použití Cílem kapitoly je seznámit účastníka školení jednak s principy stavby jazyka UML, s přehledem jeho diagramů. V kapitole je podrobně ukázáno, k čemu jsou které diagramy vhodné a jak lze UML používat prakticky v projektech včetně doporučených postupů. 4.1 Přehled diagramů UML a jejich praktické zařazení Jednotlivé diagramy UML lze chápat jako nástroje specializované na určité účely pro určité fáze modelování podobně, jako když otevřeme nějakou krabici s nástroji, toolkit (tj. kladivo, šroubovák atd.). V kapitole je podán celkový přehled všech diagramů UML, které má návrhář IS k dispozici ve smyslu nástrojů, které může použít. Současně je podána charakteristika každého diagramu s doporučením k čemu je používat a také v jaké fázi projektu nejlépe který diagram použít. Konkrétní syntaxe jednotlivých diagramů je vysvětlena v dalších kapitolách podrobněji. USE CASE DIAGRAM, jeho charakteristika, fáze projektu a použití CLASS DIAGRAM, jeho charakteristika, fáze projektu a použití SEQUENCE DIAGRAM, jeho charakteristika, fáze projektu a použití COMMUNICATION DIAGRAM, jeho charakteristika, fáze projektu a použití STATE DIAGRAM, jeho charakteristika, fáze projektu a použití ACTIVITY DIAGRAM, jeho charakteristika, fáze projektu a použití COMPONENT DIAGRAM, jeho charakteristika, fáze projektu a použití DEPLOYMENT DIAGRAM, jeho charakteristika, fáze projektu a použití PACKAGE DIAGRAM, jeho charakteristika, fáze projektu a použití OBJECT DIAGRAM, jeho charakteristika, fáze projektu a použití COMPOSITE STRUCTURE DIAGRAM, jeho charakteristika, fáze projektu a použití INTERACTION OVERVIEW DIAGRAM, jeho charakteristika, fáze projektu a použití TIMING DIAGRAM, jeho charakteristika, fáze projektu a použití strana 10

11 4.2 Rozdělení diagramů podle nezbytnosti dokumentace V předešlé kapitole jsou vysvětleny charakteristiky jednotlivých diagramů při návrhu IS a jejich použití. Některé z těchto diagramů jsou úzce specializované. Naopak některé diagramy jsou pro dobře zdokumentovaný projekt nezbytné a nesmí být nikdy zanedbány. Kapitola podává ucelený přehled o diagramech nezbytných pro projektech a logicky vysvětluje, které diagramy by měly být velmi podrobné, na které se má vedoucí projektu zaměřit, a které toto nevyžadují. Princip minimální, jednoznačné a přitom úplné dokumentace Modely nezbytné pro projekt Modely podpůrné pro projekt a jejich úloha 4.3 Doporučení pro vedoucího při návrhu IS pomocí UML Pokud se v projektu používá UML, měly by se dodržovat určité zásady, které hlídá vedoucí projekt. V dokumentu specifikace UML verze 1.5 jsou uvedena doporučení, jakými zásadami by se měl vedoucí projektu řídit (pozn. v další verzi UML tato doporučení však již nejsou uvedena). Pokud tato doporučení nebudou dodržena, vedoucí projektu bude mít problémy s řízením projektu. Doporučení pro vedoucího projekt, aby byl projekt tzv. Use Case driven Doporučení, aby byla navrhována a dodržována správná architektura v návrhu IS (vrstvy) Doporučení, aby byla použita metoda vývoje SW tzv. iterativní a inkrementální metoda vývoje 5. Stavba a syntaxe jazyka UML Ve školení jsou postupně detailně vysvětleny další diagramy UML včetně mechanismu jejich použití a doporučení pro návrh IS a pro správu modelů. 5.1 Extenzivní mechanismy UML strana 11

12 Skladba a flexibilní konstrukce jazyka UML umožňuje využít tento jazyk plnou měrou k modelování všeho, co podléhá objektovému paradigmatu, včetně například BPM a jiných oblastí. K tomu je však třeba však znát době flexibilní mechanismy zabudované do UML. TAGGED VALUE a jeho použití STEREOTYPE a jeho použití PROFILE, jeho použití pro zavádění metodik ve firmách 5.2 Společné mechanismy UML V kapitole jsou popsány společné mechanismy jazyka UML, které se prolínají celým UML. Znalost použití těchto mechanismů je pro použití návrhu v UML nezbytná. NOTE neboli COMMENT CONSTRAINT a jazyk OCL DEPENDENCY PACKAGE 5.3 PACKAGE, DEPENDENCY, vrstvení aplikace a správa modelů Jedno z doporučení tvůrců UML je dbejte na správnou architekturu IS. Toto doporučení se při návrhu IS v jazyce UML promítá prakticky do dvou kroků: 1. správný návrh prvků Package v CLASS DIAGRAMU a následně správný návrh COMPONENT DIAGRAMU v technickém designu PACKAGE a jeho význam v jazyce UML PACKAGE a NESTING PACKAGE a DEPENDENCY PACKAGE a MODEL MANAGMENT PACKAGE a CLASS MODEL, vrstvy aplikace, COMPONENT MODE strana 12

13 6. Použití, syntaxe a doporučený postup tvorby USE CASE DIAGRAMU V kapitole je popsán doporučený postup tvorby jednoho z nejdůležitějších diagramů včetně popisu nedoporučovaných postupů. Současně s tímto diagramem je probrán i ACTIVITY DIAGRAM, jehož znalost je nutná pro tvorbu BPM diagramů. 6.1 BUSINESS PROCESS MODELING jako nejlepší metoda nalézání případů užití Existuje několik škol vyhledávání případů užití, z nichž jako nejlepší se jeví v praxi BPM. V kapitole je popsán postup, jak se modeluje BPM v jazyce UML a jak se využívá pro nalézání funkcionalit IS: Metody nalézání případů užití o metoda ACTOR o metoda BUC o metoda BPM Prvek ACTIVITY a prvek BUSINESS PROCESS - STEREOTYPE Syntaxe ACTIVITY DIAGRAMU Diagram rozkladu BP (strom) Diagram podpory BP - UC (vztah okolí a IS) Diagram chodu BP (Business Flow Diagram diagram chodu procesů) 6.2 Syntaxe a tvorba USE CASE DIAGRAMU Po nalezení případů užití je třeba tyto případy užití také zpracovat. Kapitola popisuje nutné postupy pro zpracování případů užití v USE CASE DIAGRAMU. Zaměřuje se na velmi účinnou techniku popisu UC pomocí scénářů a zavádí srozumitelně a jednoduše syntaxi pro interakci mezi případy užití.. Známé metody popisu případů USE CASE SCENARIO a jeho syntaktická pravidla SCENARIO PATTERNS, nejčastější vzory scénářů strana 13

14 Pojmy BASIC PATH, ALTERNATE PATH, EXCEPTION FLOW Interakce INCLUDE v USE CASE DIAGRAMU a její správné použití Interakce EXTEND v USE CASE DIAGRAMU a její správné použití Interakce GENERALIZATION v USE CASE DIAGRAMU a její správné použití Praktické použití prvků PRECONDITION a POSTCONDITION v případu užití Prvek ACTOR v USE CASE DIAGRAMU, jeho praktický význam Postupy pro nalézání a návrh interfaců systému Jak řešit časté opakování prvku USE CASE v INCLUDE Jak řešit příliš často opakující se prvek PRECONDITON Jaké má být správné rozložení dokumentace USE CASE DIAGRAMU v projektu Jak provádět změnové řízení při požadavku na změnu funkcionality Jak provádět reversní analýzu u již hotových avšak nezdokumentovaných částí systémů 6.3 Nejčastější omyly při tvorbě USE CASE DIAGRAMU a jak se jich vyvarovat S tvorbou diagramu případů užití je spojeno několik předsudků a chybných představ. Tato kapitola poukazuje na tyto chyby a ukazuje, jak se jim vyvarovat. Omyl manažerů při odhadu rozsahu IS Konzistence USE CASE DIAGRAMU a fokus na obchodně zlaté případy užití Bobtnání projektu a jeho exploze díky chybným (nebo chybějícím) případům užití a jak se tomuto efektu vyvarovat Metody kontroly konzistence a úplnosti návrhu IS v USE CASE DIAGRAMU Omyl ohledně nejednoznačnosti rozkladu hiearchie BP Omyl ztotožnění hierarchie BPM s rozkladem na komponenty 6.4 Praktické použití USE CASE DIAGRAMU v projektech Tato kapitola vysvětluje velmi podrobně a přesně význam tvorby USE CASE DIAGRAMU pro dobrý návrh IS v projektu. Výstupy z tohoto diagramu mají velmi rozsáhlé opětovné použití, z čehož plyne, že zanedbání tvorby USE CASE DIAGRAMU má opravdu velmi nepříjemné důsledky nejenom pro návrh IS,ale i pro řízení projektu. strana 14

15 Použití USE CASE DIAGRAMU jako vývojářský dokument Použití USE CASE DIAGRAMU pro vedení projektu o Bobtnání projektu jako největší mor a jak mu lze zamezit z pozice vedoucího o Bobtnání projektu díky chybné analýze systému o Bobtnání projektu díky rostoucím požadavků uživatelů a jak mu zamezit o Bobtnání projektu díky touze po dokonalosti Použití USE CASE DIAGRAMU v testování, návrh TEST CASE DIAGRAMU Použití USE CASE DIAGRAMU v obchodním oddělení (marketing) Použití USE CASE DIAGRAMU pro tvorbu dodatku ke smlouvám se zákazníkem a pro korektní dodavatelsko odběratelské vztahy 7. Použití a syntaxe dalších diagramů UML 7.1 Použití a syntaxe SEQUENCE A COMMUNICATION DIAGRAMU Účastníci školení jsou seznámeni se syntaxí a použitím SEQUENCE A COMMUNICATION DIAGRAMU v návaznosti na návrh IS. Použití SEQUENCE A COMMUNICATION DIAGRAMU v projektech Prvek instance object Prvek Life-line Prvek Message (synchronní a asynchronní) Posloupnost zpráv jako scénář zpráv Prvek Fragment (alt, loop, par atd.) Prvek Diagram Gate Návaznost SQ diagramu na diagram tříd a na generaci kódu Příklady na SQ diagram 7.2 Použití a syntaxe STATE DIAGRAMU strana 15

16 Účastníci školení jsou seznámeni se syntaxí a použitím stavového diagramu v návaznosti na návrh IS. Použití STATE DIAGRAMU v projektech Prvek STATE Prvek INITIAL a FINAL Prvek TRANSITION, FLOW Skládání stavů, super state Prvek JOIN a FORK Prvek HISTORY (deep shallow) Prvek DECISION a GUARD 7.3 Použití a syntaxe COMPONENT DIAGRAMU Účastníci školení jsou seznámeni se syntaxí a použitím komponentního diagramu v návaznosti na návrh IS. Principy návrhu správných komponent, vrstvy systému, komponenty Vztahy mezi prvky CLASS, PACKAGE a COMPONENT DEPENDENCY a linkování komponent, JAVA a C# DEPENDENCY vedoucí do prvku INTERFACE Příklady na komponentní diagramy 7.4 Použití a syntaxe DEPLOYMENT DIAGRAMU Účastníci školení jsou seznámeni se syntaxí a použití DEPLOYMENT DIAGRAMU v návaznosti na návrh IS. Prvek NODE Využití mechanismu STEREOTYPE strana 16

17 NODE a NESTING Technika výměny prezentačního prvku u STEREOTYPE Vztah mezi prvky COMPONENT a NODE Stereotypy pro <<Device>>, <<Running Enviroment>> a <<Artifakt>> Příklady na diagramy nasazení strana 17