Návrh informačních systémů pomocí UML, OOP a vzorů

Rozměr: px
Začít zobrazení ze stránky:

Download "Návrh informačních systémů pomocí UML, OOP a vzorů"

Transkript

1 Návrh informačních systémů pomocí UML, OOP a vzorů RNDr. Ilja Kraval OBJECT CONSULTING s.r.o. Obsah (postupně se rozšiřuje): Návrh informačních systémů pomocí UML, OOP a vzorů Proč UML, OOP a vzory? Pád do pasti BYROKRATICKÉ METODY Čtyři základní pilíře návrhu IS Trojice základních vzorů návrhu IS Vzor Pattern for interaction Proč UML, OOP a vzory? Na tuto otázku existuje jednoduchá odpověď: Protože existuje způsob tvorby informačních systémů, který se příznačně nazývá TUNEL. Jedná se spíše o antimetodu, tj. o postup tvorby informačního systému, který není v žádném případě doporučován.

2 Jeho podstata je následující (viz následující obrázek): TUDY NE ÚSPĚCH TUDY NE obrázek 1 Metoda tvorby IS zvaná TUNEL Na počátku projektu se vstupuje do černého tunelu (viz zelená šipka), kterým se prochází poslepu od stěny ke stěně. Cestou se díky nárazům do stěn tunelu zjišťuje, kudy cesta nevede (viz červené šipky s nápisy TUDY NE ), tj. co se nemá dělat resp. nemělo udělat. Operativními zásahy se vedoucí projektu snaží projekt uřídit a najít světýlko na konci tunelu (žluté světélko s nápisem ÚSPĚCH). Mnohdy se projekt s odřenýma ušima dokončí a jakýs takýs informační systém se zákazníkovi nakonec odevzdá. Bohužel velmi často nastane případ, kdy se nadějné světélko na konci tunelu promění ve světla protijedoucího vlaku a celý projekt skončí katastrofickým scénářem. Použití metody TUNEL vede z hlediska softwarové firmy ke třem hlavním a podstatným negativním důsledkům: Zvýšené náklady strana 2

3 Pozdní dodávka systému Absolutní nesoulad mezi naprogramovanými funkcionalitami IS a původními požadavky zákazníka To jsou nejzávažnější důsledky použití metody TUNEL, většinou také uváděné v literatuře, avšak existují i další nepříjemné důsledky, které jsou neméně důležité. Při použití metody TUNEL nastávají zákonitě tyto nepříznivé jevy: Chybí jakákoliv koncepce vývoje a není možná opakovatelnost výsledků. V metodě TUNEL nejsou použity žádné opakovatelné postupy a projekt se řídí pouze momentální intuicí a zkušenostmi vedoucího projektu. Každý projekt a jeho výstupy vypadají jinak, a to dokonce i v případě, že projekty řídí jeden a tentýž vedoucí. Výsledky z různých projektů jsou různé, jsou nesourodé, navzájem si odporují, apod. Není možná jakákoliv predikce v projektu. Ani na začátku, ani v průběhu projektu, a to dokonce ani v jeho závěrečných fázích nelze odhadovat další pracnost, tj. jaké všechny práce bude třeba ještě udělat. Účastníci projektu nevědí, co je čeká na jejich cestě za příštím rohem. Každý projekt se tak stává sázkou do loterie a připomíná spíše dobrodružnou výpravu za pokladem pirátů než výrobu softwaru. Platí obecná neznalost kdy má co kdo dělat. Vše je pouze v kompetenci vedoucího projektu, který řídí projekt spíše ze zkušeností a pouze pomocí vlastní intuice. Vedoucí nemá žádnou příručku, ani žádné rady a pokyny, jak v dané chvíli postupovat, co vyžadovat. Proto volí své vlastní ať už lepší nebo horší řešení přímo v dané chvíli a na daném místě. Řízení se pro něj stává velmi náročnou prací plnou lokálních operativních zásahů bez možnosti jakékoliv kontroly správnosti rozhodnutí, přičemž z hlediska metod řízení chybí jakékoliv kvalitativní porovnání čehokoliv s čímkoliv. Každá porada v projektu začíná jobovými zvěstmi, co vše nechodí, co chybí, co je třeba ještě udělat. Vedoucí projektu, který používá metodu TUNEL, většinou mívá žaludeční vředy. Ve výstupech z projektů, které se průběžně tvoří metodou TUNEL, neexistuje požadavek na opětovnou použitelnost neboli re-use, anebo přesněji řečeno, při metodě TUNEL se tento požadavek nedá efektivně zavést. Některé části agend se vyvíjejí několikrát, což vede k dalším nečekaným problémům díky existenci několikanásobných řešení. Nejenže se bez zavedení opětovné použitelnosti jedná při opakování vývoje o zbytečnou práci, ale software začíná vykazovat velmi silnou nepřehlednost. Jednotlivé prvky softwaru v projektech se díky své násobnosti velmi těžko identifikují. Neví se, kde strana 3

4 všude se opakující chyba resp. požadavek na změnu vlastně vyskytuje. To se projevuje jako závažný nedostatek zejména při opravách a případných změnách. Opravdu velmi obtížně (někdy dokonce až za hranicí možného) se vyhledávají všechna místa, kde se všude chyba nebo požadavek na změnu nachází. V některých případech se při opravě chyby u hodně složitých a rozsáhlých systémů dokonce ani nenajdou všechna místa, kde se chyba vyskytuje, protože se o všech místech prostě neví. Systém vykazuje velmi nízkou transparenci, jeví se jako zbytečně složitý, vypadá jako slepenec plný těžko identifikovatelných a tedy těžko opravitelných chyb. Navíc informační systém nevykazuje žádné nosné analytické myšlenky a jeho architektura je zbytečně složitá a nepřehledná. Odhalení chyb (například v testování) ještě není zárukou, že se tato chyba skutečně odstraní ve všech místech svého výskytu. V některých případech se předchozí bod pojednávající o velmi nízké opětovné použitelnosti v TUNELU rozvine do nejhrůznější podoby: Nejenom, že se začnou opakovat funkcionality v jednotlivých agendách, ale díky opakovaným pracím začne docházet k redundanci samotných evidovaných informací. Například v metodě TUNEL se běžně stane, že některé osoby jsou v systému evidovány několikrát, v každé agendě znovu. Vzniká tak další nečekaný problém: Musí se zadat k řešení úplně nová agenda, jakýsi program pro program - zbytečná integrace, která má za úkol dávat dohromady opakující se evidované informace, které se vůbec opakovat nemusely. Při metodě TUNEL je každý i malý a jednoduchý analytický požadavek na změnu v konečném důsledku raději odmítán i za cenu obchodních ztrát. Systém vykazuje vysokou synergetickou nestabilitu : I malé změny v systému vedou k jeho nečekaným kolapsům paradoxně v odlehlých částech systému. Díky nízké transparenci, nestabilitě a chybovosti systém vykazuje vysokou pracnost i v případě jednoduché údržby, a to i po drobném zásahu. Po malé změně v systému se vyžaduje obrovský díl práce na opětovném bezchybném stabilním zprovoznění systému (nestabilita jako malá změna vyvolává obrovské nepříjemné důsledky). V softwaru se objevují příliš časté chyby i po odevzdávce odběrateli, systém jako produkt vykazuje velmi nízkou kvalitu. Díky chaotickému vývoji a neustálému řešení dalších nových a nečekaných problémů vznikají zákonitě softwarové slepence plné chyb. Důsledkem chybovosti je velmi nízká kvalita produktů. Enormně vzrůstá nutnost neustálých oprav i po implementaci systému. Co je však nejhorší, u zákazníka se začne projevovat nespokojenost s kvalitou dodávky, zejména pokud zjišťuje fatální chyby ve funkcionalitách systému ( ten systém dělá neuvěřitelné hlouposti, takhle jsme to tedy ale vůbec nechtěli ) Chaotický vývoj vede i k zvláštní atmosféře ve firmě, která je charakterizována vysokou hektičností prací, shonem a všeobecnou nervozitou. Vyrobený strana 4

5 software se neustále předělává a to stále dokola jako za trest. Provádí se zbytečná a tedy úmorně nepříjemná práce. Výsledkem jsou extrémně náročné vztahy na pracovišti. Firma si v konečném důsledku díky neustálým úpravám a opravám uzurpuje velmi vysoké nároky na volný čas pracovníků. Problém nespočívá ani tak v tom, že by se pracovníci bránili příliš vysokému vypjetí sil a přesčasům (pokud mají slušný výdělek), ale jako vysoce inteligentním pracovníkům a expertům jim velmi vadí zbytečnost vykonané práce. Nakonec to mohou pociťovat i jako určitou křivdu, že díky neuvěřitelnému chaosu ve vývoji musejí zůstat přesčas a dané chyby stále dokola opravovat s povzdechem: Po kolikáté už v této agendě, to už opravdu nikdo neřekne, jak to má být správně?! Ve firmě, která pracuje metodou TUNEL, je úplnou samozřejmostí pracovat hodně přesčas, dokonce až tak, že se to považuje za obvyklý standard chování. Někdy se tím vedoucí pracovníci u zákazníků chlubí: Sledujte, jak usilovně pracujeme, žádné dovolené, zůstáváme tu až do večera, někdy do rána, samé pracovní soboty a dokonce i neděle!. Ve skutečnosti však firma paradoxně staví na odiv svůj neefektivní způsob práce, který je pro metodu TUNEL příznačný. Správnější než tyto chlubné věty by byla formulace: Pracujeme sice hodně, ale neefektivně. Navíc metoda TUNEL v žádném případě neprospívá dobrým vztahům na pracovišti. Souhrnem všech negativních projevů jsou, jak bylo již zdůrazněno, zvýšené náklady a následně finanční ztráty. Proto se způsob tvorby informačních systémů TUNEL zásadně nedoporučuje, i když mohu z dlouholeté praxe konzultanta potvrdit, že bývá ve velmi mnoha firmách až příliš často používán. strana 5

6 2. Pád do pasti BYROKRATICKÉ METODY V předešlé kapitole byla popsána anti-metoda TUNEL. Existuje však ještě další dokonce ještě více nebezpečná anti-metoda - BYROKRATICKÁ METODA. Tato opět nedoporučovaná metoda následuje většinou jako další krok po metodě TUNEL. Pád softwarové firmy do pasti BYROKRATICKÉ METODY mívá většinou stejný scénář: Ve firmě neexistují žádné postupy prací, firma vyrábí software chaoticky, tj. tak., jak bylo popsáno v předešlé kapitole. Vedení SW firmy se tato situace přestane zamlouvat, tj. důsledky intenzivně působící metody TUNEL. Rozhodne se tedy s tímto postupem ve firmě rázně skoncovat. Vedení firmy vcelku správně pochopí, že základním nedostatkem metody TUNEL jsou chybějící postupy prací, tj. metodiky, a že je proto žádoucí nějaké metodiky ve firmě zavést. Zadá se proto jakýsi úkol, aby se vytvořily postupy pro tvorbu softwaru, neboli metodiky. Většinou spolu s tímto krokem se současně založí oddělení kvality. Na první pohled dobře míněná snaha však může skončit katastrofou. Pokud pracovníci, kteří zavádějí tyto postupy a metodiky, neznají základní principy tvorby softwaru, začnou vznikat velmi podivné dokumenty. Podle nich se sice vyžaduje pracovat, ale pro programátory se tyto dokumenty stávají spíše přítěží než pomůckou. Vznikají tak předpisy podle hesla: Hlavně ať jsou předpisy!, avšak jejich správnost, efektivita apod. není posuzována. Doslova začnou vznikat dokumenty pro dokumenty, avšak podle nich se nedá pracovat. Tento extrémně opačný byrokratický přístup je charakterizován následujícími body: Zavádějí se postupy a metodiky bez zkušeností s nimi, nedodržují se základní pravidla metodik platné pro tvorbu softwaru (o těchto principech bude dále v této knize pojednáno) Na počátku zavádění metodik se zahajují práce s přehnaným optimismem. Jsou patrná přílišná očekávání ze zavedených postupů, a to s očekáváním výsledků ihned a okamžitě. To samozřejmě vede k zavádění neověřených postupek za každou cenu s následnými krachy. Při tvorbě metodik se dopředu předjímají a vymýšlejí nesmyslné postupy neověřené praxí. Metodiky se vydávají jako jednou konečné pravdy, o kterých není již radno diskutovat. strana 6

7 Přílišné očekávání vede ke snaze o revoluční skoky ( čínská revoluce ) ve změnách způsobů práce ve firmě. Zanedbává se ten prostý fakt, že každý fungující mechanismus má svou setrvačnost. Navíc při zavádění metodik je třeba vytvořit rychlou zpětnou vazbu. Každý nový postup vyžaduje přejít postupně do krve. Každou postupku je třeba ověřit, odzkoušet, zrevidovat praxí. Při zanedbání těchto faktů následují při zavádění metodik v SW firmách krachy. Správně uvažujícímu člověku by měl přeběhnout mráz po zádech, když někdo přijde s myšlenkou: Máme tři čtvrtě roku na zavedení postupek a návodek, času máme dost. Zavedeme je a od 1.1. příštího roku je spustíme, to bude potom bomba! Bomba to bude, ale jinak, než původně autor zamýšlel. Necelý rok uplyne a vydají se takové postupky, které všichni zavrhnou jako nesmysly. S příchodem nového roku hora porodí myš. Při zavádění byrokratické mašinérie následuje zpomalení vývoje a poté se zvyšuje netrpělivost u zákazníka. Zde mohou nastat dva možné scénáře: Buď pracovníci začnou nesmyslné metodiky ignorovat a tím se dostanou zpět do metody TUNEL (metodiky se ignorují a každý bojuje jak umí), anebo nastane horší varianta: V některých případech dokonce pracovníci začnou švejkovat v tom smyslu, že pracují přesně podle nesmyslných postupek, což pochopitelně vede ke katastrofálním výsledkům. Přístup k tvorbě softwaru pomocí BYROKRATICKÉ metody se také nedoporučuje. Z vlastní zkušenosti mohu potvrdit, že pád firmy do pasti BYROKRATICKÉ METODY je mnohem nebezpečnější než použití klasické metody TUNEL. Pokud totiž nastane scénář striktního dodržování nesmyslných postupů, může to nakonec vést až k totálnímu kolapsu týmové práce. Zatímco v metodě TUNEL se mnohdy jakýs takýs informační systém odevzdá, BYROKRATICKÁ METODA může vést ke katastrofě, kdy se rozpadnou týmy a dokonce se zruší dosud zažité dobré zvyklosti vývoje vedoucí alespoň k nějakým výsledkům. Uvedený přechod firmy od TUNELU přes BYROKRATICKOU METODU zpátky do TUNELU ukazuje následující obrázek: strana 7

8 Zavedení metody TUNEL Ignorace předpisů (jedeme podle svého) Zavedení BYROKRATICKÉ METODY Dodržování nesmyslů BYROKRATICKÉ METODY KRACH obrázek 2 : Metoda TUNEL a návrat do ní po neúspěšném zavedení metodik Paradoxně jsem se setkal s firmami, ve kterých byla zavedena BYROKRATICKÁ METODA, naštěstí byla ignorována (viz šipka zpět na předešlém obrázku), firma tedy jela vesele TUNELEM a honosila se certifikáty ISO. Formálně totiž vše vypadalo tak, jako by firma předpisy pro postupy prací měla, ale stejně se v realitě pracovalo pouze ad hoc, jak je v metodě TUNEL zvykem. strana 8

9 3. Čtyři základní pilíře návrhu IS V předešlých kapitolách byly popsány dvě často používané anti-metody : TUNEL a druhá ještě více nebezpečná anti-metoda - BYROKRATICKÁ METODA. Samozřejmě naskýtá se otázka, jak má vypadat správná metodika. Ukazuje se, že efektivnost metodiky návrhu a tvorby IS je postavena základních čtyřech pilířích. Pokud je jeden z těchto pilířů narušen, metodu TUNEL nelze korektně opustit. Tyto čtyři pilíře zobrazuje následující obrázek: 4 PILÍŘE VÝVOJE IS ÚROVNĚ ABSTRAKCE Analýza Design Kód atd... OBJEKTOVÝ PŘÍSTUP Třídy Instance Zapouzdření atd... MODELOVÁNÍ V JAZYCE UML Modely, Diagramy Elementy, Interakce MDA atd... POUŽITÍ VZORŮ Design Patterns Analysis Patterns Enterprise Patterns Integration Patterns atd. obrázek 3: 4 pilíře vývoje IS strana 9

10 Následuje stručná charakteristika těchto bodů, v dalších kapitolách je probereme samozřejmě detailně a také prakticky: 1. Pilíř: Úrovně abstrakce ve zkratce znamená, že na informační systém je třeba nahlížet z různých úrovní abstrakce, přičemž každá úroveň je charakterizována mírou detailu implementace. Tomuto principu musí odpovídat rozvržení dokumentace projektu. Rozeznávají se (minimálně) tři úrovně abstrakce informačního systému a. analytické modelování (ve zkratce také analýza) b. design c. kód. Na nejnižší úrovni abstrakce (tj. kód) se dokumenty vyznačují nejvyšší mírou detailu implementace a to až na úrovni samotného kódu, na nejvyšší úrovni abstrakce, tj. na úrovni analytického modelování, je systém popsán pouze pomocí analytických entit (evidované pojmy a jejich struktura) a chování výskytů z nich (algoritmy, scénáře, dynamika). Tímto principem se povinně řídí tvorba dokumentů ve vývoji. Zohlednění tohoto bodu vede ke správnému fázování vývoje a k přehledné a úplné dokumentaci informačního systému. Nezohlednění tohoto bodu vede k cestě TUNELEM už díky neznalosti který dokument je třeba kdy udělat, což není nic jiného, než zanedbání fázování vývoje. Důsledkem této chyby je také následná velmi chabá dokumentace projektu. Většinou se projekt dokumentuje pouze na jedné úrovni abstrakce a to kódování, protože se u SW jedná o povinnou část dokumentace (ono totiž logicky bez napsání kódu nelze chodící systém odevzdat). Ostatní dokumenty, tj. analytické modely a modely designu, zůstávají v hlavách tvůrců a šíří se pouze ústním podáním. 2. Pilíř: Objektově orientovaný přístup (ve zkratce OOAP - Object Oriented Approach) zavádí při návrhu IS velmi důležitou filosofii náhledu na to, co jsou to vlastně prvky IS. Zavádí pojem obecný objekt (tj. general object ) ve smyslu prvku IS a definuje jeho vlastnosti. Tyto prvky jsou základními stavebními kameny vývoje systému na všech úrovních abstrakce (analýza, design, kód). Bez tohoto principu není vývojář schopen správně a logicky sestavit IS, protože mu chybí základní stavební kameny - obecné objekty. Problematika OOAP bude dále vysvětlena podrobně a rozvedena v dalších kapitolách, nyní uveďme pouze to, že jeden ze základních důsledků OOAP spočívá v rozdělení informačního systému na dvě prakticky oddělené části: IS je oddělen nikoliv pouze pomyslně, ale fyzicky (tj. až do kódu) na část uvnitř prvku (tj. to, co patří do prvku, implementace) a část vně prvku (okolí prvku, klient). Neznalost tohoto přístupu OOAP vede k fatálním chybám v návrhu, k nesprávnému použití prvků modelu, k nesmyslným návrhům jak v analýze, strana 10

11 tak v designu, tj. k hrubým chybám v modelování. Musíme zdůraznit, že porušením tohoto principu hrozí zejména zavlečení jedné z nejvážnějších chyb, kterých se může tvůrce IS dopustit, a tou je chyba uvedená v anti-vzoru SPLITTING OF OBJECT. Tato chyba spočívá v tom, že se evidované informace v IS umísťují do nesprávných pozic, tj. tam, kam nepatří. Tím dochází k tříštění objektů neboli evidovaných informací (o tomto anti-vzoru viz dále v knize). Musíme ještě upozornit na to, že pojem general object zavedený pomocí OOAP je obecnějším pojmem než objekt zavedený v OOP. Jedná se o jeho zobecnění pro všechny úrovně abstrakce, nejenom pro kód. 3. Pilíř: Modelování v jazyce UML (Unified Modeling Language) umožňuje vývojáři vyjádřit svoje myšlenky (a tedy celý návrh) ve velmi sofistikovaném jazyce. Tento jazyk navíc velmi dobře zohledňuje předešlý bod, tj. přístup pomocí OOAP. Jinak řečeno UML je jazykem určeným pro objektově orientovaná prostředí. Tvůrci UML poskytují vývojářům unifikovaný, standardní a velmi chytře promyšlený jazyk pro vyjádření návrhu na úrovních abstrakce analytického modelování a designu. 4. Pilíř: Použití vzorů při návrhu IS (návrhové vzory, analytické vzory, vzory integrace aj.) umožňuje vývojáři při návrhu IS použít princip vzorů jako opakovaných řešení. Pro firmu to znamená, že může takto zavádět velmi efektivně opakované postupy pro vývoj. Význam použití vzorů se dá vyjádřit trefně pomocí slovní hříčky: Zavádění opakovaných postupů a řešení (vzory) je nejlepším postupem, jak zavést opakované postupy ve firmě. Jinak řečeno, jedná se o nejefektivnější způsob zavádění metodik, navíc je tento postup na rozdíl od byrokratických metod pracovníky vítán a není jimi odmítán (vzory jsou odborné know-how, které si vývojáři rádi přečtou na rozdíl od byrokratických příkazů). Je třeba hned úvodem poznamenat, že tyto čtyři oblasti se navzájem prolínají a kombinují. Například pro vyjádření struktury a fungování vzoru se použijí diagramy v jazyce UML (kombinace bodu 3 a 4), nebo například různé modely IS spadají do různých úrovní abstrakce (kombinace bodu 1 a 3), nebo například přechod od dokumentů jedné úrovně abstrakce k druhé je popsán pomocí vzorů modelem v jazyce UML a také pomocí vzoru, což vede k moderní technologii MDA Model Driven Architecture atd. V dalších kapitolách tohoto seriálu se budeme podrobně zabývat těmito čtyřmi pilíři návrhu IS. strana 11

12 4. Trojice základních vzorů návrhu IS Při návrhu IS jsou patrné vzory, které jsou velmi důležité, protože se velmi často používají. Na druhou stranu vidíme jiné vzory, které jsou speciálnější a používají se méně často. Praxe ukazuje, že existuje trojice vzorů, které mají výsadní postavení. Tyto tři vzory se chovají podobně jako axiomy (tj. nejzákladnější tvrzení) v matematice. Jsou to vzory natolik zásadní, že na jejich konstrukci jsou postaveny všechny další vzory pro návrh IS. Proto je dobré si tuto trojici vzorů uvést hned na úvod a řádně vysvětlit. Zde je však jeden drobný háček - tato trojice vzorů je spolu provázána tak, že vysvětlení jednoho vzoru není možné bez druhého a jejich pochopení je možné až jako celé trojice, tedy celku. Vysvětlení však musí proběhnout postupně, což nyní uděláme, a na konec shrneme působnost těchto tří vzorů jako jeden celek. 4.1 Vzor Pattern for interaction Jedná se o první základní vzor z trojice axiomatických vzorů. Vzor ukazuje, jak vlastně funguje tzv. opětovná použitelnost (dále také re-use) a také ukazuje, jak funguje interakce mezi prvky. Mohl by se však také jmenovat Vzor pro objektový přístup, protože i tato vlastnost je v něm také skryta, jak si ukážeme dále. Jedná se o jednoduchý základní axiom, jehož důsledky se linou teorií tvorby SW a tedy i návrhem IS. Představme si, že existuje nějaký prvek A a existuje nějaký prvek B, přičemž zjistíme, že v prvku A se vyskytuje určitá část něčeho, co se opakuje také v prvku B, označme tuto opakující se část klikyhákem: strana 12

13 A B obrázek 4 Situace 1 ve vzoru pro re-use Příklady takovýchto situací: Opakující se kód ve funkci, opakující se struktury ve analytických třídách, opakující se sloupce v tabulkách aj. Vzor zavádí kromě této situace také situaci 2, která nastane tak, že se zavede interakce použití mezi prvky, daný opakující se klikyhák se vytkne do prvku C a vznikne tak situace 2: A B interakce 1 interakce 2 C obrázek 5 Situace 2 ve vzoru pro re-use (po vytknutí ) Situaci 1 budeme dále také nazývat situace před vytknutím a situaci 2 situací po vytknutí. Přechod ze situace 1 před vytknutím do situace 2 po vytknutí. tj. samo vytknutí prvku C, budeme chápat jako zavedení opětovné použitelnosti a budeme to nazývat také jako zavedení interakce mezi prvky. Existuje i opačný postup, kdy se ze situace 2 po vytknutí přejde úmyslně do situace 1 před vytknutím, tj., opačným směrem. Takovýto postup budeme nazývat optimalizace. Většinou se tak děje za účelem získání nějaké technologické výhody, strana 13

14 například rychlosti apod. Klasickým příkladem je postup tzv. de-normalizace (3. stupně) v relační databázi, kdy se rozpouštějí tabulky. Každá optimalizace vede v konečném důsledku k porušení opětovné použitelnosti, což je třeba mít vždy na paměti. Problému optimalizace se budeme ještě blíže věnovat v kapitolách přechodu od analýzy do designu ve vzorech optimalizace. Všimněme si blíže vlastností situací před vytknutím a situaci po vytknutí tj. obrázek 4 Situace 1 ve vzoru pro re-use a obrázek 5 Situace 2 ve vzoru pro re-use (po vytknutí ). Interakce použití v situaci po vytknutí je směrová, což je velmi důležitý poznatek. Toho, kdo používá (v našem případě prvky A a B), budeme nazývat klientem a toho, kdo je použit, budeme nazývat prvkem, nebo také obecným objektem. Je zřejmé, že pokud A používá C, tak to v žádném případě neznamená, že z toho plyne, že C používá A. Obecný objekt tj. prvek, který je použit, musí být v systému nějak přesně identifikován oproti jiným prvkům, jinak bychom nemohli docílit toho, aby si dvě interakce na předešlém obrázku ukázaly svými konci šipek na tentýž prvek C. Stejně tak jsou identifikovány prvky A, B, ale také C pro kohokoliv do budoucna, kdo se stane jejich klientem. Pro tuto situaci konkrétní identifikace, kdy klient používá konkrétní identifikovaný prvek, budeme také používat terminologii, že klient si drží ukazatel na používaný prvek, přičemž pod ukazatelem nemáme na mysli pouze paměťový ukazatel v OOP (kde tato věta platí samozřejmě také), ale máme tím na mysli obecně jakýkoliv ukazatel (třeba i datový, například cizí klíč apod.). Pokud tedy namaluje obrázek odpovídající situaci po vytknutí (tj. obrázek 5 Situace 2 ve vzoru pro re-use (po vytknutí )), současně tím máme na mysli to, že vnitřní struktura klienta A resp. B se obsahuje obecný ukazatel na prvek C (obsahují ve své struktuře kolečka jako začátek interakce na obrázku situace po vytknutí). Tento ukazatel je v dané technologii nějak realizován (například funkce nějak identifikuje druhou funkci při volání, cizí klíč v datech, anebo ukazatel na interface objektu, třída nějak identifikuje druhou třídu při dědičnosti, tj. má v sobě nějak jednoznačně zapsaného předka atd.) Další důležitou vlastnost tohoto vzoru si uvědomíme, pokud si představíme nový prvek (dosud neexistoval!), který se stane klientem prvku A, označme tento nový prvek jako X. Tomuto prvku X neboli klientovi prvku A je jedno, zda je použita situace 1 bez vytknutí anebo 2 po vytknutí, tj. zda došlo k aplikaci opětovné použitelnosti anebo nikoliv. V obou případech bude systém fungovat (nebýt této pravdy, nemohli bychom zavádět optimalizaci). Otázkou je, proč tomu tak je? Důvod je prostý, pokud si uvědomíme princip přechodu od situace před vytknutím k situaci po vytknutí : Prvek C byl vytknut a následně použit. Není tedy úplně přesné hovořit o interakci mezi prvky (to příliš zavání symetrií), ale raději o tom, že jeden prvek používá druhý prvek. Každý prvek nabízí v systému své použití, jinak řečeno nabízí nějakou službu použití. Pod službou strana 14

15 použití máme na mysli nabízenou možnost být použit v interakci ve směru od klienta k prvku, a takovou službu nabízí každý prvek. V našem příkladu tedy prvek A jako klient prvku C používá nabízenou službu použití prvku C (stejně tak prvek B používá službu C), navíc prvek X používá nabízenou službu prvku A atd., viz následující obrázek: služby použití X X služby použití A služby použití B A B služby použití C C obrázek 6 Princip použití prvků prvky Důležitý závěr: Každý klient prvku si tedy drží obecný ukazatel na používaný prvek a má přitom zpřístupněnu možnost použití služeb tohoto prvku. strana 15

16 Díky těmto dvěma okolnostem (identifikaci prvku a nabízené službě použití prvku) nakonec prvek použije. Všimněme si, že pohled klienta je omezen pouze na tuto službu použití a nikoliv na vnitřní strukturu prvku. Proto je možné zavést vnitřní restrukturalizaci prvku vytknutím ( refactoring ). Nyní je jasné, proč je prvku X jako klientovi prvku A na předešlém obrázku úplně, ale úplně jedno, zda je prvek C z A vytknut anebo nikoliv. X používá služby A a tím jeho pohled na prvek A končí. Tomuto jevu, kdy klient prvku používá služby tohoto prvku a vnitřek neboli implementace používaného prvku je pro klienta přitom skryt, budeme říkat obecně zapouzdření (encapsulation). Vidíme, že náš vzor o re-use má v sobě uschovány také základní principy objektového přístupu, čemuž bude věnována jedna z dalších důležitých kapitol. Tento princip objektovosti je mnohem obecnější než pouze pro OOP a co je hlavní, line se celým návrhem IS. K vysvětlení důležitosti tohoto faktu se vraťme k obrázku obrázek 6 Princip použití prvků prvky a představme si, že v prvku C je nějaká informace. Umí prvek A tuto informaci nebo ne? Odpověď ano, ale zprostředkovaně. Znamená to, že prvku X jako klientovi A je jedno, zda je ta informace v A nebo v C. Musíme upozornit (a dále si to ukážeme konkrétně na příkladech), že právě tady je schována nejčastější chyba při modelování a návrhu IS, která se nazývá tříštění objektů. Chyba se vytvoří tak, že určitý prvek se roztříští a jeho části se počnou objevovat rozprsknuté po systému. Jako příklad si představme., že máme v systému evidované jednak čtenáře knihovny, dále zaměstnance knihovny, studenty a jiné osoby. Umějí tyto evidované výskyty rodné číslo? Odpověď ano, protože to po nich budeme vyžadovat. To však neznamená, že rodná čísla budou přímo v nich jako jejich atributy. To, že z těchto evidovaných prvků tento údaj nějak dostaneme, tak to může (a v tomto případě to také znamená), že rodné číslo je v konkrétním prvku osoba a ten je použit těmito prvky nějak takto: strana 16

17 služby použití čtenáře čtenář služby použití zaměstnance zaměstnanec služby použití osoby osoba - rodné číslo obrázek 7 Má čtenář a zaměstnanec rodné číslo? Bylo by dobré pochopit, že veškeré modelování IS je v UML postaveno na takovýchto obrázcích, které jsou v podstatě úplně stejné, jako je tento předešlý a jediné, co se na nich mění, je jejich grafická podoba pro různé typy diagramů, pro různé typy prvků a pro různé typy interakcí. Různé typy diagramů zobrazují různé případy o co se v použití jedná a o jak typy prvků se jedná. Každý vztah použití v různých typech diagramů vyjadřuje pouze něco jiného, například dědičnost je použití třídy třídou, asociace je použití instance třídy instancí třídy, vztah <<include>> je použití instance případu užití druhou instancí případu užití atd. Je to však stále dokola o tomtéž vztahu použití prvku prvkem. Proto je tento vzor tak silný, dovoluje nám totiž pochopit, jak funguje modelování, jak funguje interakce, jak funguje objektový přístup obecně. Jeho nezohlednění vede k fatálním chybám v návrhu IS. V další kapitole se budeme zabývat druhým základním vzorem, který ukazuje, jak vlastně fungují vzory a jakou mají strukturu. strana 17

18 Konec dokumentu pokračování následuje Jakékoliv připomínky k článku pište prosím na adresu autora: Slovník Pattern for interaction and re-use strana 18

Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů

Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů Část 1 autor RNDr. Ilja Kraval, http://www.objects.cz březen 2007 firma Object Consulting s.r.o. Úvod V reakci

Více

NAUČTE SE MALOVAT SI INSTANCE!

NAUČTE SE MALOVAT SI INSTANCE! NAUČTE SE MALOVAT SI INSTANCE! část 2. RNDr. Ilja Kraval, září 2009 http://www.objects.cz ÚVOD V předešlém článku jsme otevřeli jeden ze základních problémů, který musí analytik řešit: Jak vypadá skladba

Více

S KONFIGURACÍ POVOLENÝCH KOMBINACÍ DĚDICŮ

S KONFIGURACÍ POVOLENÝCH KOMBINACÍ DĚDICŮ VZOR HETEROGENNÍ SEZNAM S KONFIGURACÍ POVOLENÝCH KOMBINACÍ DĚDICŮ RNDr. Ilja Kraval, září 2008 http://www.objects.cz ÚVOD Jak známo, v CLASS DIAGRAMU se dělí vztahy do dvou základních typů: Buď se jedná

Více

Objektové modelování pomocí UML v praxi, 2005

Objektové modelování pomocí UML v praxi, 2005 Objektové modelování pomocí UML v praxi, 2005 díl 1 PDF e-kniha RNDr. Ilja Kraval, autor, mailto:objects@objects.cz, leden 2005 OBJECT CONSULTING K uvedené problematice lze objednat školení in-house pro

Více

JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA)

JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA) JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA) 2. část autor: RNDr. Ilja Kraval, červenec 2010 http://www.objects.cz ÚVOD V minulém článku bylo pojednáno o složitosti

Více

Úvod do principů objektově orientovaného programování

Úvod do principů objektově orientovaného programování OBSAH DISTANČNÍHO E-LEARNINGOVÉHO KURZU PROFESNÍ RŮST ANALYTIKA OD ZÁKLADŮ (BASE) ÚVOD DO TECHNOLOGIÍ INFORMAČNÍCH SYSTÉMŮ Jak funguje počítač na základní úrovni Základy HTML Skripty ve webovských technologiích

Více

Šumperský efekt rozmnožení případů užití

Šumperský efekt rozmnožení případů užití Šumperský efekt rozmnožení případů užití Ilja Kraval, 2007 http://www.objects.cz Článek pojednává o jednom velmi nepříjemném efektu bobtnání projektu. 1. Odhad velikosti a rozsahu informačního systému

Více

Odpověď na dotaz ohledně asociační třídy v modelu měření

Odpověď na dotaz ohledně asociační třídy v modelu měření Odpověď na dotaz ohledně asociační třídy v modelu Část 4. Tento článek navazuje na předešlé články jako jejich pokračování autor RNDr. Ilja Kraval, http://www.objects.cz září 2007 firma Object Consulting

Více

Analytické modelování informačních systémů

Analytické modelování informačních systémů Ilja Kraval Analytické modelování informačních systémů pomocíumlvpraxi Object Consulting 2010 Anotace: V knize je popsán obecný přístup k analýze informačního systému, respektive vytvoření analytického

Více

Jedna z velmi častých a závažných chyb při návrhu IS aneb jak vznikají tzv. molochální systémy

Jedna z velmi častých a závažných chyb při návrhu IS aneb jak vznikají tzv. molochální systémy Jedna z velmi častých a závažných chyb při návrhu IS aneb jak vznikají tzv. molochální systémy Část druhá autor RNDr. Ilja Kraval, http://www.objects.cz červenec 2006 (pozn.: článek navazuje na první část

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Druhá část odpovědi na mail ohledně zpracování případů užití

Druhá část odpovědi na mail ohledně zpracování případů užití Druhá část odpovědi na mail ohledně zpracování případů užití Autor RNDr. Ilja Kraval leden 2008 www.objects.cz Úvod Tento článek navazuje jako pokračování na článek předešlý. Minule jsme si vysvětlili,

Více

Čtvrtá část odpovědi aneb jak je to vlastně s interakcí <>

Čtvrtá část odpovědi aneb jak je to vlastně s interakcí <<include>> Čtvrtá část odpovědi aneb jak je to vlastně s interakcí autor RNDr. Ilja Kraval leden 2008 www.objects.cz Úvod Tento článek navazuje jako pokračování na články předešlé. Minule jsme si zde

Více

Nutnost použití vzoru OBSERVER pro zamezení nepříjemných efektů zpětných funkcionálních vazeb mezi objekty

Nutnost použití vzoru OBSERVER pro zamezení nepříjemných efektů zpětných funkcionálních vazeb mezi objekty Nutnost použití vzoru OBSERVER pro zamezení nepříjemných efektů zpětných funkcionálních vazeb mezi objekty autor RNDr. Ilja Kraval, http://www.objects.cz únor 2007 firma Object Consulting s.r.o. Úvod V

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH

ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH 3. část RNDr. Ilja Kraval, srpen 2009 http://www.objects.cz ÚVOD Tento článek je pokračováním předešlých článků. Článek vysvětluje použití vztahu

Více

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Nástroje pro poskytování součinnosti 1.1 Help desk Poskytovatel vytvoří a zajistí službu pro hlášení vad/požadavků/připomínek (dále

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Obsah. ÚVOD 1 Poděkování 3

Obsah. ÚVOD 1 Poděkování 3 ÚVOD 1 Poděkování 3 Kapitola 1 CO JE TO PROCES? 5 Co všechno musíme vědět o procesním řízení, abychom ho mohli zavést 6 Různá důležitost procesů 13 Strategické plánování 16 Provedení strategické analýzy

Více

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) 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)... 1 1. Jak

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

DBS Konceptuální modelování

DBS Konceptuální modelování DBS Konceptuální modelování Michal Valenta Katedra softwarového inženýrství FIT České vysoké učení technické v Praze Michal.Valenta@fit.cvut.cz c Michal Valenta, 2010 BIVŠ DBS I, ZS 2010/11 https://users.fit.cvut.cz/

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Logická struktura systému Objektový diagram Pavel Děrgel, Daniela Szturcová Osnova Modelování objektů objektový diagram Struktura a vazby mezi objekty Dobré zvyky při

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Modelování řízené případy užití

Modelování řízené případy užití Modelování řízené případy užití kompletní proces od UC po implementaci, robustnost 2005 Radek Ošlejšek, Jiří Sochor FI MU Brno oslejsek@fi.muni.cz http://www.fi.muni.cz/~oslejsek/pa103 30. 3. 2005 PA103:

Více

Analýza a návrh webových aplikací I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Analýza a návrh webových aplikací I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Analýza a návrh webových aplikací I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova dnešní přednášky Proč tento předmět vlastně existuje? Proč nestačí standardní metodiky SI? Co standardním

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE?

JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE? JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE? RNDr. Ilja Kraval, říjen 2008 http://www.objects.cz ÚVOD Začnu jedním zajímavým postřehem: Na našich školeních OOP a UML existují určitá témata, která při jejich

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

Úvod do objektově orientovaného programování s použitím jazyka C# pro střední školy

Úvod do objektově orientovaného programování s použitím jazyka C# pro střední školy Úvod do objektově orientovaného programování s použitím jazyka C# pro střední školy Učebnice je určena pro střední školy k volnému šíření (FREE) autor RNDr. Ilja Kraval, 2006-2007, www.objects.cz Tato

Více

Kvalita v ošetřovatelské péči. Irena Pejznochová Česká asociace sester Česká společnost pro jakost 30.dubna 2010

Kvalita v ošetřovatelské péči. Irena Pejznochová Česká asociace sester Česká společnost pro jakost 30.dubna 2010 Kvalita v ošetřovatelské péči Irena Pejznochová Česká asociace sester Česká společnost pro jakost 30.dubna 2010 Kvalitní péče? Jak se společnost dokáže postarat o seniory a osoby se zdravotním postižením,

Více

Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC

Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC Úvod Před nedávnem jsem obdržel trochu delší mail tohoto znění: Dobrý den pane Kravale, před časem jsem absolvoval vaše

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

Hodnocení kvality logistických procesů

Hodnocení kvality logistických procesů Téma 5. Hodnocení kvality logistických procesů Kvalitu logistických procesů nelze vyjádřit absolutně (nelze ji měřit přímo), nýbrž relativně porovnáním Hodnoty těchto znaků někdo buď předem stanovil (norma,

Více

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan

Principy OOP při tvorbě aplikací v JEE. Michal Čejchan Principy OOP při tvorbě aplikací v JEE Michal Čejchan Témata přednášky Principy OOP - připomenutí Úvod - co nás vede k používání OOP Reálný svět - jak (ne)používáme OOP Nedostatky na úrovni programovacích

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

Vzor OBSERVER a jeho zajímavá varianta v kombinaci se vzorem ADAPTER Část 2

Vzor OBSERVER a jeho zajímavá varianta v kombinaci se vzorem ADAPTER Část 2 Vzor OBSERVER a jeho zajímavá varianta v kombinaci se vzorem ADAPTER Část 2 autor RNDr. Ilja Kraval, http://www.objects.cz únor 2007 firma Object Consulting s.r.o. Úvod V předešlé části článku jsme si

Více

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007 UML úvod Kapitola má seznámit se základy modelovacího jazyka UML. Klíčové pojmy: UML, CASE nástroje, procesní modelování, případy užití, role, diagram tříd, diagram objektů, sekvenční diagramy, digram

Více

I. JAK SI MYSLÍM, ŽE MOHU BÝT PRO TÝM PROSPĚŠNÝ:

I. JAK SI MYSLÍM, ŽE MOHU BÝT PRO TÝM PROSPĚŠNÝ: Test týmových rolí Pokyny: U každé otázky (I - VII), rozdělte 10 bodů mezi jednotlivé věty podle toho, do jaké míry vystihují vaše chování. V krajním případě můžete rozdělit těchto 10 bodů mezi všechny

Více

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1

DATABÁZOVÉ SYSTÉMY. Metodický list č. 1 Metodický list č. 1 Cíl: Cílem předmětu je získat přehled o možnostech a principech databázového zpracování, získat v tomto směru znalosti potřebné pro informačního manažera. Databázové systémy, databázové

Více

EFEKTIVNÍ KOMUNIKACE V ORGANIZACI

EFEKTIVNÍ KOMUNIKACE V ORGANIZACI EVROPSKÝ SOCIÁLNÍ FOND PRAHA & EU: INVESTUJEME DO VAŠÍ BUDOUCNOSTI V ORGANIZACI JAK SE EFEKTIVNĚ DOMLUVIT A ZÍSKAT INFORMACE 1. KOMUNIKAČNÍ PROCES 2 2. ORGANIZAČNÍ STRUKTURA KOMUNIKACE 4 3. FORMÁLNÍ A

Více

9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna -1- dále ZP).

9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna -1- dále ZP). 1 Popis ucelené problémové domény Následující komplexní příklad se týká domény soukromých zbraní v ČR (SSZ v ČR) Ukážeme nejdříve její obecný popis, ale nebudeme se přísně držet současně platného zákona

Více

( ) Jako základ mocnin nemusíme používat jen 10. Pokud není jasné, že číslo je uvedeno v desítkové soustavě, píšeme jej takto: ( 12054 ) 10

( ) Jako základ mocnin nemusíme používat jen 10. Pokud není jasné, že číslo je uvedeno v desítkové soustavě, píšeme jej takto: ( 12054 ) 10 .. Číselné soustavy I Předpoklady: základní početní operace Pedagogická poznámka: Tato a následující hodina není součástí klasické gymnaziální sady. Upřímně řečeno nevím proč. Jednak se všichni studenti

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Procesní řízení operačních sálů Mgr. Martin Gažar

Procesní řízení operačních sálů Mgr. Martin Gažar Procesní řízení operačních sálů Mgr. Martin Gažar Procesy Procesy Procesní analýza Procesní mapa Modely procesů Optimalizace procesů Přínosy procesní analýzy Procesy a modely Procesy Abychom mohli úspěšně

Více

Vstupní a výstupní test modul D

Vstupní a výstupní test modul D Vstupní a výstupní test modul D 1) Jaký je význam prvního řádku logického rámce? a) Na prvním řádku je uveden hlavní cíl projektu, jakožto formulace výsledného stavu v okamžiku ukončení projektu b) Význam

Více

Popisná statistika kvantitativní veličiny

Popisná statistika kvantitativní veličiny StatSoft Popisná statistika kvantitativní veličiny Protože nám surová data obvykle žádnou smysluplnou informaci neposkytnou, je žádoucí vyjádřit tyto ve zhuštěnější formě. V předchozím dílu jsme začali

Více

B2 Organizace jako systém

B2 Organizace jako systém Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B2 Organizace jako systém Toto téma obsahuje informace o způsobech a přístupech k řízení organizace jako

Více

Problém identity instancí asociačních tříd

Problém identity instancí asociačních tříd Problém identity instancí asociačních tříd Autor RNDr. Ilja Kraval Ve školeních a také následně po jejich ukončení se stále častěji objevují dotazy, které se týkají tzv. identity instancí asociační třídy.

Více

Návrh a management projektu. Řízení a koordinace projektu

Návrh a management projektu. Řízení a koordinace projektu Návrh a management projektu Řízení a koordinace projektu ČVUT FAKULTA BIOMEDICÍNSKÉHO INŽENÝRSTVÍ strana 1 Ing. Vladimír Jurka 2013 Program přednášky Komunikační nástroje Dokumenty řízení projektu Řízení

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010 FORTANNS manuál Vojtěch Havlíček havlicekv@fzp.czu.cz 22. února 2010 1 Úvod Program FORTANNS je software určený k modelování časových řad. Kód programu má 1800 řádek a je napsán v programovacím jazyku

Více

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová

MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH. Jindřich Kaluža Ludmila Kalužová MODELOVÁNÍ DAT V INFORMAČNÍCH SYSTÉMECH Jindřich Kaluža Ludmila Kalužová Recenzenti: prof. Ing. Milan Turčáni, CSc. prof. Ing. Ivan Vrana, DrSc. Tato kniha vznikla za finanční podpory Studentské grantové

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová, Pavel Děrgel Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

Diagram výskytů a vztahů

Diagram výskytů a vztahů Diagram výskytů a vztahů Nepoužívá se pro modelování. Pomůcka pro pochopení kardinalit a parcialit. KINO Blaník Vesna Mír Domovina Květen MÁ_NA_PROGRAMU FILM Černí baroni Top gun Kmotr Nováček Vzorec Vetřelec

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Podnikové informační systémy

Podnikové informační systémy Podnikové informační systémy 26. dubna 2013 Vladimír Kovář Vladimír Kovář Narozen 2.1.1962 v Praze 4 děti, 1 žena, 1 pes, 7 koní, 42 krav, 37 ovcí UNICORN a 1049 spolupracovníků Vzdělání (Ing.) ČVUT, Fakulta

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

S T R A T E G I C K Ý M A N A G E M E N T

S T R A T E G I C K Ý M A N A G E M E N T S T R A T E G I C K Ý M A N A G E M E N T 3 LS, akad.rok 2014/2015 Strategický management - VŽ 1 Proces strategického managementu LS, akad.rok 2014/2015 Strategický management - VŽ 2 Strategický management

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

To vše odděleně! Přitom mají stejný cíl: spokojeného zákazníka.

To vše odděleně! Přitom mají stejný cíl: spokojeného zákazníka. Firmy investují nemalé prostředky do posílení loajality zákazníků, zjišťování jejich spokojenosti a vnímání značky. Další prostředky směřují do výběru a motivace zaměstnanců, tréninků a školení, do průzkumů

Více

Kontrola zavedení postupů na principu HACCP v zařízeních školního stravování

Kontrola zavedení postupů na principu HACCP v zařízeních školního stravování Kontrola zavedení postupů na principu HACCP v zařízeních školního stravování MVDr. Milena Frühaufová Konzultační den HDM, SZÚ 17.3.2010 Rozdíl v pojetí národní a evropské legislativy Evropská legislativa

Více

O JEDNÉ ČASTÉ CHYBĚ PŘI ROZKLADU PROCESŮ PODNIKU ANEB KDY MÁME UKONČIT ROZKLAD PROCESŮ PODNIKU?

O JEDNÉ ČASTÉ CHYBĚ PŘI ROZKLADU PROCESŮ PODNIKU ANEB KDY MÁME UKONČIT ROZKLAD PROCESŮ PODNIKU? O JEDNÉ ČASTÉ CHYBĚ PŘI ROZKLADU PROCESŮ PODNIKU ANEB KDY MÁME UKONČIT ROZKLAD PROCESŮ PODNIKU? RNDr. Ilja Kraval, říjen 2008 http://www.objects.cz AKTÉROVÁ ŠKOLA Jak známo, informační systémy obsahují

Více

7.2 Model použití (jednání) (Use Case)

7.2 Model použití (jednání) (Use Case) 7.2 Model použití (jednání) (Use Case) - při analýze požadavků často popis typických interakcí uživatele, nedokumentované Jacobson model použití (1992) Scénář Posloupnost kroků popisujících interakci mezi

Více

Vztah typu Extend v UML a jeho zvláštnosti

Vztah typu Extend v UML a jeho zvláštnosti Vztah typu Extend v UML a jeho zvláštnosti RNDr. Ilja Kraval 2007 Object Consulting s.r.o. http://www.objects.cz objects@objects.cz Do diskusního fóra na Pandoře (http://pandora.idnes.cz/conference/objcon/)

Více

Školení v rámci zemědělské a lesnické činnosti 2014

Školení v rámci zemědělské a lesnické činnosti 2014 Vindex JIH, s.r.o. Platnéřská 191 110 00 Praha IČO: 25173278 Název projektu: Školení v rámci zemědělské a lesnické činnosti 2014 Číslo projektu: 13/0181310b/131/000199 Financováno z Programu Rozvoje Venkova

Více

Posouzení Plánu dopravní obslužnosti Libereckého kraje, Aktualizace pro období 2012-18

Posouzení Plánu dopravní obslužnosti Libereckého kraje, Aktualizace pro období 2012-18 Posouzení Plánu dopravní obslužnosti Libereckého kraje, Aktualizace pro období 2012-18 Zadavatel: KORID LK, spol. s r.o., U Jezu 642/2a, Liberec 2 Hodnotitel: doc. Ing. Miroslav Žižka, Ph.D., Technická

Více

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1 Dominik Vymětal 2009, Ostrava 1.-2.10.2009 1 Procesní model Výhody Orientace na konkrétní činnosti a možnost reengineeringu Nevýhody Malá orientace na průřezové nebo opakované činnosti Modely na základě

Více

PowerOPTI Řízení účinnosti tepelného cyklu

PowerOPTI Řízení účinnosti tepelného cyklu PowerOPTI Řízení účinnosti tepelného cyklu VIZE Zvýšit konkurenceschopnost provozovatelů elektráren a tepláren. Základní funkce: Spolehlivé hodnocení a řízení účinnosti tepelného cyklu, včasná diagnostika

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

Obecné pokyny pro používání identifikačních kódů právnických osob

Obecné pokyny pro používání identifikačních kódů právnických osob EIOPA(BoS(14(026 CS Obecné pokyny pro používání identifikačních kódů právnických osob EIOPA WesthafenTower Westhafenplatz 1 60327 Frankfurt Germany Phone: +49 69 951119(20 Fax: +49 69 951119(19 info@eiopa.europa.eu

Více

7.3 Diagramy tříd - základy

7.3 Diagramy tříd - základy 7.3 Diagramy tříd - základy - popisuje typy objektů a statické vztahy mezi nimi Objednávka -datumpřijetí -předplacena -číslo -cena +vyřiď() +uzavři() {if Objednávka.zákazník.charakteristika = 'nejistý'

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Objektově orientované programování v jazyce Python

Objektově orientované programování v jazyce Python Objektově orientované programování v jazyce Python Základní pojmy objektově orientovaného programování Objekt vychází z reálného světa. Má dva charakteristické rysy. Všechny objekty mají stav Všechny objekty

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include a extend) Shrnutí

Více

Modelování webových služeb v UML

Modelování webových služeb v UML Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě

Více

Jeden ze způsobů zadávání dat v programu MS Access je pomocí tabulek. Ovšem mnohem výhodnější způsob je pomocí tzv. formulářů.

Jeden ze způsobů zadávání dat v programu MS Access je pomocí tabulek. Ovšem mnohem výhodnější způsob je pomocí tzv. formulářů. 10.12 TVORBA FORMULÁŘE 10.12.1 VYTVOŘENÍ JEDNODUCHÉHO FORMULÁŘE Jeden ze způsobů zadávání dat v programu MS Access je pomocí tabulek. Ovšem mnohem výhodnější způsob je pomocí tzv. formulářů. Jak jste se

Více

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI

PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI PRVNÍ ELASTICKÝ INFORMAČNÍ SYSTÉM : QI Cyril Klimeš a) Jan Melzer b) a) Ostravská univerzita, katedra informatiky a počítačů, 30. dubna 22, 701 03 Ostrava, ČR E-mail: cyril.klimes@osu.cz b) DC Concept

Více

Vnitřní kontrolní systém a jeho audit

Vnitřní kontrolní systém a jeho audit Vnitřní kontrolní systém a jeho audit 7. SETKÁNÍ AUDITORŮ PRŮMYSLU 11. 5. 2012 Vlastimil Červený, CIA, CISA Agenda Požadavky na VŘKS dle metodik a standardů Definice VŘKS dle rámce COSO Role interního

Více

Bakalářky. Cyril Brom

Bakalářky. Cyril Brom Bakalářky Cyril Brom 1 Typy práce Implementační Implementačně experimentální Teoretický 2 Typický průběh Správně Měsíc předem se domluvím na zápočtech i vedoucí může mít dovolenou Odevzdávám vedoucímu

Více

17.3 - Motivace - inovace - zkušenost a vzdělávání

17.3 - Motivace - inovace - zkušenost a vzdělávání EVROPSKÝ SOCIÁLNÍ FOND 17.3 - Motivace - inovace - zkušenost a vzdělávání PRAHA & EU INVESTUJEME DO VAŠÍ BUDOUCNOSTI Klíčová aktivita č. 5 - Kurz a podpora a zkvalitnění výuky 3D počítačového modelování,

Více

Zrádné detaily penzijní reformy

Zrádné detaily penzijní reformy Zrádné detaily penzijní reformy O co jde v druhém pilíři Pavel Kohout Proč nestačí průběžný systém? Průběžné systémy byly zavedeny po II. světové válce ve všech vyspělých zemích Před válkou existovaly

Více

Databázové modelování. Analýza Návrh konceptuálního schématu

Databázové modelování. Analýza Návrh konceptuálního schématu Databázové modelování Analýza Návrh konceptuálního schématu 1 Vytváření IS Analýza Návrh Implementace Testování Předání SW Jednotlivé fáze mezi sebou iterují 2 Proč modelovat/analyzovat? Standardizované

Více

Přednáška. Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE. e-fractal, s.r.o.

Přednáška. Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE. e-fractal, s.r.o. Přednáška Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE e-fractal, s.r.o. Úvod Agenda Motivace proč modelovat procesy Stručný úvod do metody C.C Příklad Motivace proč modelovat procesy

Více

TŘÍDY KVALITY. Důležitý bod pozice podniku na trhu v závislosti na kvalitě 3 třídy kvality

TŘÍDY KVALITY. Důležitý bod pozice podniku na trhu v závislosti na kvalitě 3 třídy kvality ŘÍZENÍ KVALITY 1 TŘÍDY KVALITY Důležitý bod pozice podniku na trhu v závislosti na kvalitě 3 třídy kvality C top třída B střední třída A začínající třída Nutnost zvolit třídu všechny jsou na trhu žádoucí

Více

JAK NA JEDNOTKU VÝSLEDKŮ UČENÍ

JAK NA JEDNOTKU VÝSLEDKŮ UČENÍ JAK NA JEDNOTKU VÝSLEDKŮ UČENÍ žádostí o grant Jednotka výsledků učení (JVU) Co je jednotka výsledků učení? - část kvalifikace - ucelený soubor znalostí, dovedností a kompetencí - jednotlivé JVU lze kombinovat,

Více

Řízení rizik. Ing. Petra Plevová. plevova.petra@klikni.cz http://plevovapetra.wbs.cz

Řízení rizik. Ing. Petra Plevová. plevova.petra@klikni.cz http://plevovapetra.wbs.cz Řízení rizik Ing. Petra Plevová plevova.petra@klikni.cz http://plevovapetra.wbs.cz Procesní řízení a řízení rizik V kontextu současných změn je třeba vnímat řízení jakékoli organizace jako jednoduchý,

Více