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

Jak správně psát scénáře k případům užití?

Jak správně psát scénáře k případům užití? Jak správně psát scénáře k případům užití? Autor RNDr. Ilja Kraval 2007 http://www.objects.cz K napsání tohoto článku mne inspiroval tento mail: Dobrý den pane Kravale, chci Vás poprosit o radu, která

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

Třetí část odpovědi na mail ohledně zpracování případů užití, aneb jak je to s číslováním pořadí případů užití

Třetí část odpovědi na mail ohledně zpracování případů užití, aneb jak je to s číslováním pořadí případů užití Třetí část odpovědi na mail ohledně zpracování případů užití, aneb jak je to s číslováním pořadí případů užití autor RNDr. Ilja Kraval leden 2008 www.objects.cz Úvod Tento článek navazuje jako pokračování

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

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

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

6 Objektově-orientovaný vývoj programového vybavení

6 Objektově-orientovaný vývoj programového vybavení 6 Objektově-orientovaný vývoj programového vybavení 6.1 Co značí objektově-orientovaný - organizace SW jako kolekce diskrétních objektů, které zahrnují jak data tak chování objekt: OMG: Objekt je věc (thing).

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

VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ

VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ Část 3 Tento článek je pokračováním předešlých článků RNDr. Ilja Kraval, duben 2009 http://www.objects.cz ÚVOD V předešlých článcích jsme se seznámili s použitím

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

Jak funguje element deep history v UML

Jak funguje element deep history v UML Jak funguje element deep history v UML autor RNDr. Ilja Kraval, http://www.objects.cz březen 2007 firma Object Consulting s.r.o. Úvod Již několikrát jsem v internetových diskusích a při školeních narazil

Více

Usage of modular scissors in the implementation of FEM

Usage of modular scissors in the implementation of FEM Usage of modular scissors in the implementation of FEM Dalibor Frydrych PANM 2010 6.-11. června 2010 Dolní Maxov 8. června 2010 1 Úvod Zúžený pohled na OOP 2 Základy objektově orientovaného přístupu Objektové

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

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

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

Č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

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

Vývoj IS - strukturované paradigma II

Vývoj IS - strukturované paradigma II Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 05 1/18 Vývoj IS - strukturované paradigma II Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií) 8 Přehled OO metodik (metod, metodologií) 8.1 OO metodiky konce 80. a začátku 90.let - všechny populární OO metodiky předpokládají, že: a) zadavatel jasný názor na svoje požadavky, b) zadavatel a vývojáři

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

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

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 22. Otázka : Úvodní fáze rozpracování softwarového projektu. Postupy při specifikaci byznys modelů. Specifikace požadavků a jejich rozpracování pomocí

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

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

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

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

Algoritmizace. 1. Úvod. Algoritmus

Algoritmizace. 1. Úvod. Algoritmus 1. Úvod Algoritmizace V dnešní době již počítače pronikly snad do všech oblastí lidské činnosti, využívají se k řešení nejrůznějších úkolů. Postup, který je v počítači prováděn nějakým programem se nazývá

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

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

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

Úvod a teoretický vstup do procesního řízení. Procesy Jičín, Bloky B2 B4 / B5 B7

Úvod a teoretický vstup do procesního řízení. Procesy Jičín, Bloky B2 B4 / B5 B7 Úvod a teoretický vstup do procesního řízení Procesy Jičín, 20. - 21. 1. 2011 Bloky B2 B4 / B5 B7 Program 1. Základní zarámování projektu 2. Teoretický vstup do procesního řízení U1 Některé hlavní problémy,

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

Vyřešené teoretické otázky do OOP ( )

Vyřešené teoretické otázky do OOP ( ) Vyřešené teoretické otázky do OOP (16. 1. 2013) 1) Vyjmenujte v historickém pořadí hlavní programovací paradigmata a stručně charakterizujte každé paradigma. a) Naivní chaotičnost, špatná syntaxe a sémantika

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

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

2 Životní cyklus programového díla

2 Životní cyklus programového díla 2 Životní cyklus programového díla Typické etapy: 1. Specifikace požadavků - specifikace problému - analýza požadavků 2. Vývoj programu - návrh - kódování (programování) 3. Verifikace a validace 4. Provoz

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

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

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

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS Roman Danel VŠB TU Ostrava HGF Institut ekonomiky a systémů řízení Literatura Staníček, Z, - Hajkr, J.: Řízení projektů zavádění IS do organizací.

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

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I

Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel I Návrh řešení IS Vývoj informačních systémů Ruční návrh Připravíme si odpovědi na základní otázky Co chceme řešit (projektovat) a proč Komu to bude sloužit Jaký užitek z toho bude mít uživatel IS a jaký

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

Algoritmus. Cílem kapitoly je seznámit žáky se základy algoritmu, s jeho tvorbou a způsoby zápisu.

Algoritmus. Cílem kapitoly je seznámit žáky se základy algoritmu, s jeho tvorbou a způsoby zápisu. Algoritmus Cílem kapitoly je seznámit žáky se základy algoritmu, s jeho tvorbou a způsoby zápisu. Klíčové pojmy: Algoritmus, vlastnosti algoritmu, tvorba algoritmu, vývojový diagram, strukturogram Algoritmus

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

Ú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

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

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

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů Číslo otázky : 16. Otázka : Funkční a dynamická analýza informačního systému. Obsah : 1. Úvod 2. Funkční

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

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

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

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

Databázové systémy. Ing. Radek Holý

Databázové systémy. Ing. Radek Holý Databázové systémy Ing. Radek Holý holy@cvut.cz Literatura: Skripta: Jeřábek, Kaliková, Krčál, Krčálová, Kalika: Databázové systémy pro dopravní aplikace Vydavatelství ČVUT, 09/2010 Co je relační databáze?

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

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

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

Geografické informační systémy p. 1

Geografické informační systémy p. 1 Geografické informační systémy Slajdy pro předmět GIS Martin Hrubý hrubym @ fit.vutbr.cz Vysoké učení technické v Brně Fakulta informačních technologií, Božetěchova 2, 61266 Brno akademický rok 2004/05

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

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

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

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

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

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

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

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

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme Smysl metodiky IS/IT Koncentrovaná zkušenost Checklist na nic nezapomeneme Přínosy metodik Větší produktivita a kooperace týmů Komunikační standard Specializace projektových týmů Nezávislost na konkrétních

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

Architektury počítačů a procesorů

Architektury počítačů a procesorů Kapitola 3 Architektury počítačů a procesorů 3.1 Von Neumannova (a harvardská) architektura Von Neumann 1. počítač se skládá z funkčních jednotek - paměť, řadič, aritmetická jednotka, vstupní a výstupní

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

METODICKÝ APARÁT LOGISTIKY

METODICKÝ APARÁT LOGISTIKY METODICKÝ APARÁT LOGISTIKY Metodický aparát logistiky jedná se o metody sloužící k rozhodování při logistických problémech Metodu = použijeme, v případě vzniku problému. Problém = vzniká v okamžiku, když

Více

PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE

PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE Vývoj prvních programů byl prováděn nadšenci, programy byly šité na míru. Žádná metodika vývoje SW v té době neexistuje. Vývoj SW byl vnímán jako výzkum. Cíl, co bude

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

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů

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

Význam měřm. Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D. VŠE Praha

Význam měřm. Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D. VŠE Praha Význam měřm ěření v testování softwaru Mgr. Anna Borovcová doc. Ing. Alena Buchalcevová, Ph.D VŠE Praha Motivace The Standish Group reporty za roky 1994 2009 1994 1996 1998 2000 2002 2004 2006 2009 Úspěšných

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

Příloha č. 3 zadávací dokumentace

Příloha č. 3 zadávací dokumentace Příloha č. 3 zadávací dokumentace 1. Stávající stav 1.1. Východiska pro systém základních registrů Současný systém veřejné správy vychází a bude i nadále založen na principech hierarchického modelu v podobě,

Více

BI-TIS Případová studie

BI-TIS Případová studie Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti BI-TIS Případová Cvičení č. 2 Ing. Pavel Náplava naplava@fel.cvut.cz Katedra softwarového inženýrství, ČVUT FIT, 18102 Centrum znalostního

Více

informační technologie: vaše výhoda, váš úspěch

informační technologie: vaše výhoda, váš úspěch informační technologie: vaše výhoda, váš úspěch informace po ruce Dovolte, abychom vám stručně představili naše komplexní služby v oblasti informačních technologií a zpracování informací >>> informační

Více

Vývoj a ověřování metodiky výuky programování

Vývoj a ověřování metodiky výuky programování Copyright Rudolf Pecinovský, Soubor: 2016_INF_Architecture First.doc, verze 1.00.2413, uloženo út 19.1.2016 10:03 1 z 11 Vývoj a ověřování metodiky výuky programování Rudolf Pecinovský Informatika XXIX

Více

Delphi - objektově orientované

Delphi - objektově orientované Kapitola 6 Delphi - objektově orientované programování Objektově orientované programování (zkracováno na OOP, z anglického Object oriented programming) je metodika vývoje softwaru, založená na těchto myšlenkách,

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

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

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

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14

ZÁKLADY PROGRAMOVÁNÍ. Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14 ZÁKLADY PROGRAMOVÁNÍ Mgr. Vladislav BEDNÁŘ 2014 5.3-5.8 9/14 Co je vhodné vědět, než si vybereme programovací jazyk a začneme programovat roboty. 1 / 12 0:40 UML unifikovaný modelovací jazyk Zkratka tohoto

Více

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6 Metodika Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009 Sb., o základních registrech Verze 1.6 AIS RPP Působnostní určeno pro oznamovatele Oznámení o vykonávání působností č. 111/2009

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

Úvod do databázových systémů

Úvod do databázových systémů Úvod do databázových systémů Databáze je dnes velmi často skloňovaným slovem. Co se pod tímto termínem skrývá si vysvětlíme na několika následujících stranách a cvičeních. Databáze se využívají k ukládání

Více