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

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

přednáší RNDr. Ilja Kraval pořádá firma OBJECT CONSULTING http://www.objects.cz

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

Kurz Postupy návrhu IS pomocí UML a OOP © RNDr. Ilja Kraval http://www.objects.cz

4.3 Doporučení pro vedoucího při návrhu IS pomocí UML .................................................. 11 5. Stavba a syntaxe jazyka UML ................................................................................................ 11 5.1 Extenzivní mechanismy UML........................................................................................ 11 5.2 Společné mechanismy UML ......................................................................................... 12 5.3 PACKAGE, DEPENDENCY, vrstvení aplikace a správa modelů ................................... 12 6. Použití, syntaxe a doporučený postup tvorby USE CASE DIAGRAMU ................................... 13 6.1 BUSINESS PROCESS MODELING jako nejlepší metoda nalézání případů užití .......... 13 6.2 Syntaxe a tvorba USE CASE DIAGRAMU .................................................................... 13 6.3 Nejčastější omyly při tvorbě USE CASE DIAGRAMU a jak se jich vyvarovat ................. 14 6.4 Praktické použití USE CASE DIAGRAMU v projektech ................................................. 14 7. Použití a syntaxe dalších diagramů UML................................................................................ 15 7.1 Použití a syntaxe SEQUENCE A COMMUNICATION DIAGRAMU................................ 15 7.2 Použití a syntaxe STATE DIAGRAMU .......................................................................... 15 7.3 Použití a syntaxe COMPONENT DIAGRAMU ............................................................... 16 7.4 Použití a syntaxe DEPLOYMENT DIAGRAMU ............................................................. 16

strana 2


1. Jak se software nemá dělat - nedoporučované postupy 1.1 Metoda řízení vývoje IS zvaná TUNEL Popis kapitoly 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.

Obsah kapitoly 

Ří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 Popis kapitoly 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


Obsah kapitoly 

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 Popis kapitoly 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.

Obsah kapitoly 

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


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 Popis kapitoly 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.

Obsah kapitoly 

Ú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 Popis kapitoly 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ů.

Obsah kapitoly 

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


2.3 Jak se hledá kompozice, její syntaxe a význam, co je atribut Popis kapitoly 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.

Obsah kapitoly 

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 Popis kapitoly 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á.

Obsah kapitoly 

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“ Popis kapitoly 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


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 Popis kapitoly 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.

Obsah kapitoly 

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 Popis kapitoly 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í. Obsah kapitoly 

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




Příklady na asociační třídu s vícero konci

2.8 Jak hledat a používat vztah Generalizace Popis kapitoly 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.

Obsah kapitoly 

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í Popis kapitoly 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í.

Obsah kapitoly 

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


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 Popis kapitoly 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. Obsah kapitoly 

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 Popis kapitoly 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.

Obsah kapitoly 

Vzor COMMAND



Vzor OBSERVER



Vzor DECORATOR



Vzor SINGLETON



Vzor STRATEGY



Vzor INTERPRETER

strana 9


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í Popis kapitoly 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.

Obsah kapitoly 

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


4.2 Rozdělení diagramů podle nezbytnosti dokumentace Popis kapitoly 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í.

Obsah kapitoly 

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 Popis kapitoly 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.

Obsah kapitoly 

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 Popis kapitoly

strana 11


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.

Obsah kapitoly 

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 Popis kapitoly 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á.

Obsah kapitoly 

NOTE neboli COMMENT



CONSTRAINT a jazyk OCL



DEPENDENCY



PACKAGE

5.3 PACKAGE, DEPENDENCY, vrstvení aplikace a správa modelů Popis kapitoly 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 Obsah kapitoly 

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


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 užití

BUSINESS PROCESS MODELING jako nejlepší metoda nalézání případů

Popis kapitoly 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: Obsah kapitoly 

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 Popis kapitoly 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í.. Obsah kapitoly 

Známé metody popisu případů



USE CASE SCENARIO a jeho syntaktická pravidla



SCENARIO PATTERNS, nejčastější vzory scénářů

strana 13




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 Popis kapitoly 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. Obsah kapitoly 

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 Popis kapitoly 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


Obsah kapitoly 

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 Popis kapitoly Účastníci školení jsou seznámeni se syntaxí a použitím SEQUENCE A COMMUNICATION DIAGRAMU v návaznosti na návrh IS.

Obsah kapitoly 

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 Popis kapitoly

strana 15


Účastníci školení jsou seznámeni se syntaxí a použitím stavového diagramu v návaznosti na návrh IS. Obsah kapitoly 

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 Popis kapitoly Účastníci školení jsou seznámeni se syntaxí a použitím komponentního diagramu v návaznosti na návrh IS. Obsah kapitoly 

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 Popis kapitoly Účastníci školení jsou seznámeni se syntaxí a použití DEPLOYMENT DIAGRAMU v návaznosti na návrh IS. Obsah kapitoly 

Prvek NODE



Využití mechanismu STEREOTYPE

strana 16




NODE a NESTING



Technika výměny prezentačního prvku u STEREOTYPE



Vztah mezi prvky COMPONENT a NODE



Stereotypy pro <>, <> a <>



Příklady na diagramy nasazení

strana 17

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

Recommend Documents