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

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

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

Transkript

1 Vzor OBSERVER a jeho zajímavá varianta v kombinaci se vzorem ADAPTER Část 2 autor RNDr. Ilja Kraval, únor 2007 firma Object Consulting s.r.o.

2 Úvod V předešlé části článku jsme si uvedli nejjednodušší variantu použití vzoru OBSERVER. Nyní se vrátíme k problému s našimi auty a barvami a uvedeme si, jak by se dal tento vzor pro řešení našeho příkladu nasadit. Hned v úvodu si však musíme uvést jednu důležitou okolnost. Vzor OBSERVER předpokládá, že pokud při jeho použití hovoříme o objektech, tak máme na mysli rovnou a přímo objekty dané technologie objektového prostředí, tj. hovoříme zde o objektech v prostředí.net nebo JAVA atd. Při použití tohoto vzoru tedy nehovoříme o tzv. logických instancích v analytickém modelu, tj. o analytických evidovaných instancích, ale hovoříme o opravdu žijících objektech v OOP. Jinak řečeno vzor OBSERVER je nasazen přímo v objektovém prostředí na opravdové žijící objekty vytvořené voláním konstruktoru v tomto prostředí. A právě zde musíme zvážit jeden drobný problém. Pokud bychom v přechodu od analytického modelování do designu mapovali logické instance (tj. evidované instance) do OOP přímo jedna k jedné a platilo by proto kolik evidovaných instancí, tolik objektů v paměti v OOP, potom by nasazení tohoto vzoru bylo opravdu jednoduché až primitivní. Každý objekt auta (ve smyslu OOP), který se provazuje přes ukazatel na svou barvu, by se spolu s tvorbou této objektové vazby současně také zaregistroval k danému objektu barvy, například nějak takto (o principu registrace viz předešlá část článku): class CAuto : IObserver; //...JAVA implements IObserver private CBarva mbarva; public SetmBarva (Cbarva abarva); //nastavení barvy do auta mbarva = abarva; mbarva.getonchangebarva.add(this); //registrace k události v barvě... strana 2

3 Takto nejenom že objekt auta vidí svůj objekt barvy, ale současně je dané auto také zaregistrováno k požadované události v barvě a proto bude přes interface IObserver auto zavoláno (až nastane událost v barvě) odpovídající metodou Update(). Asi tušíme, v čem je problém tohoto příkladu. Pro tzv. enterprise systémy, tj. systémy evidenční (neboli podnikové) je příznačné, že obsahují na analytické úrovni opravdu hodně multiinstanční třídy s vysokým počtem logických instancí. Jinak řečeno pro podnikové systémy je charakteristické, že počet evidovaných výskytů multiinstančních entit může být velmi velký. Pro náš příklad to konkrétně znamená, že analyticky řečeno v systému se může vyskytovat řádově tisíce až desetitisíce evidovaných aut. Pokud bychom tedy tyto logické instance aut mapovali do objektového prostředí jedna ku jedné, nastane evidentní technologický problém se správou takového množství žijících OOP objektů. Závěr je jasný: Nemůžeme z tohoto důvodu použít jednoduchou variantu nasazení vzoru OBSERVER, která byla uvedena v předešlém odstavci, tj. tu variantu nasazení vzoru OBSERVER, kdy se auto současně s vazbou na barvu také zaregistrovalo a poté je zavoláno. Nemůžeme prostě všechny objekty aut a všechny objekty barev držet v paměti a čekat na události v objektech - barvách, které potom volají zpět své zaregistrované objekty - auta. Musíme tedy provést jiné mapování a vzor OBSERVER nasadit na jiné instance objektů. Otázkou je, jak to udělat? Mapování analýzy podnikových systémů do designu, vzor FLYWEIGHT a jeho různé podoby v dalších vzorech V podstatě řešíme klasický problém, kdy máme část analytického modelu u podnikového systému již hotovu (zde auta a barvy) a snažíme se ji mapovat do technologie hybridního systému, tj. do technologie silné prostředí OOP plus silná databáze (např. C# plus MS SQL nebo JAVA plus ORACLE apod.) a to jinak, než pro velký počet instancí technologicky nesmyslným stylem počet instancí v analýze a designu bude jedna ku jedné. Připomeňme, že situaci, kdy máme hodně logických instancí na straně jedné a relativně k tomu málo instancí v prostředí OOP, řeší obecně vzor FLYWEIGHT v jeho různých modifikacích. Pro podnikové systémy (neboli tzv. enterprise systémy) řešené pomocí hybridního systému se tato sada takovýchto řešení nazývá speciálně Patterns of Enterprise Architecture Systems, zkráceně Enterprise Architecture Patterns (blíže o této literatuře viz článek Známé vzory při návrhu informačních systémů na našem serveru). strana 3

4 Tyto vzory udávají známé postupy při řešení těchto situací: Známe logické řešení (analytický model tříd), máme hybridní systém, tj. silný jazyk OOP a silnou databázi, a otázkou je, jaké tedy potom zvolíme technologické řešení našeho logického problému? Uveďme například, že ve zmíněné knize existuje celkem 51 vzorů, které se týkají této problematiky mapování do hybridních systémů. Pro náš příklad zvolíme lehce upravený vzor DOMAIN MODEL v kombinaci se vzorem MAPPER. Stručně řečeno by naše řešení bylo zavedeno takto: Nalezenou multiinstanční analytickou třídu mapujeme na jednu tabulku a jednu třídu s odpovídajícími názvy podle analytické třídy (například z analytické třídy auto vznikne jedna tabulka TAuto v databázi a jedna třída CAuto v OOP), dále zavedeme nějaký pomocný datový objekt, který zprostředkovává přístup k databázi, nazvěme jej třebas DBO, za kterým je schován objekt připojení do databáze. Metody tohoto datového objektu odpovídají funkcionalitám, které potřebují objekty z OOP při spolupráci s databází (například vlož data nového auta apod.). Tento datový objekt se svým interfacem se chová velmi podobně jako okénko úschovny zavazadel, objekty z business vrstvy si přes něj odkládají svá data a zase podle stvrzenek (tj. idéček) opět vybírají. Za okénkem úschovny zavazadel jsou nějak uspořádány regály pro data (neboli tabulky ). Funkcionality itemů se podle tohoto vzoru (např. co umí jedno auto ) mapují jako dynamické členy tříd a funkcionality seznamu (např. najdi v seznamu aut právě ta auta, která... ) se mapují na statické metody této třídy. Je zřejmé, že v určitém okamžiku delegují tyto funkcionality svůj běh na datový objekt DBO. I když máme vše pěkně pohromadě v jedné třídě, tak toto mapování není až tak výhodné a v praxi jsme v projektech se statickými metodami narazili. Nevýhody zavedení statických metod pro funkcionality seznamu jsou hned dvě: Za prvé, statické metody nemůžeme přepisovat (a opravdu i chování seznamu se může chovat polymorfně) a za druhé, je možné (a dokonce to nastane v našem případě při zavádění vzoru OBSERVER!), že budeme chtít se seznamem handlovat jako s objektem, což nám třída se statickými metodami neumožňuje. Zvolíme proto lehkou modifikaci tohoto vzoru a totiž, že analytickou třídu budeme do OOP mapovat vždy nikoliv na jednu třídu, ale NA DVĚ TŘÍDY. První třída bude třídou pro item (to zůstává stejné jako před modifikací) a druhá třída bude správcem seznamu a v ní budou metody odpovídající funkcionalitám seznamu těchto itemů. Jinak řečeno, statické metody v nemodifikované variantě se převedou do jiné třídy, do správce seznamu, a stanou se tak dynamickými metodami. Dále učiňme názvovou dohodu, že třídy spravující seznamy vybavíme předponou col (jako collection ). Navíc, pokud nejsou prvky seznamu v kompozici vůči svému majiteli (jako jsou například řádky faktury ve faktuře apod.), tak v tom případě prvky těchto tříd vlastní sám systém a nikoliv nějaký prvek. Zavedeme proto tyto třídy správců seznamu jako jedno-instanční podle vzoru SINGLETON. strana 4

5 Vyplývá z toho, že pro náš příklad máme tedy hned 4 třídy v OOP (pomineme pro nás nezajímavý služební datový objekt DBO obalující konekt do DB a poskytující okénko do úschovny dat) vzniklých ze dvou entit, zde auto a barva: CAuto, CcolAuto, CBarva a CcolBarva a vzniknou také dva objekty podle vzoru SINGLETON a to gcolauto a gcolbarva jako dva globální správci seznamů ze tříd CcolAuto a CcolBarva. Jedna velmi důležitá poznámka (!): Objekty gcolauto a gcolbarva mají sice metody pro funkcionality seznamů (speciálně pro auta a pro barvy), ale to vůbec neznamená, že za nimi opravdu stojí v paměti (v OOP) skutečně žijící objekty. Jak jsou tyto metody uvnitř napsány, to záleží na technologovi, on rozhodne, co se udělá v paměti v objektech a co v databázi. Například metoda dej počet prvků seznamu aut getcount se může pouze ztransformovat na dotaz do DB, například v pseudokódu nějak takto: class CcolAuto public long GetCount(); return DBO.GetCountforAuto();... a uvnitř metody objektu DBO.GetCountforAuto() se volá přes konekt jednoduchý SQL příkaz, například SELECT COUNT(*) FROM TAuto. Nyní je otázkou, jak při tomto mapování zavedeme odpovídající vzor OBSERVER. Je zřejmé, že nemůžeme použít již zmíněnou primitivní variantu, kdy objekt barva obtelefonuje své zaregistrované objekty aut posazených jako objekty OOP v paměti, protože jak vidět, uvnitř objektu gcolauto se nemusí vyskytovat žádný žijící objekt auta ve smyslu OOP (viz metoda GetCount v příkladu ) a není proto koho obtelefonovat. Kdo koho tedy bude ve vzoru OBSERVER zpětně volat a jak? strana 5

6 Zavedení vzoru OBSERVER v našem příkladu Je zřejmé, že musíme problém registrace převést na úroveň správců seznamů. Tam se totiž nabízí jednoduché řešení. Nechť máme v objektu barva zavedenu nějakou změnu, na kterou čekají ta auta, která mají tuto barvu. Při změně jednoho objektu barva (máme jej dočasně například pro editaci vytvořen) nebude tento objekt obtelefonovávat svá auta (to teď nelze, kdoví zda jsou v té chvíli auta vůbec v paměti!), ale zavolá svůj objekt správce seznamu barev. Tento správce barev zavolá všechny své zaregistrované objekty - jiné správce seznamů - přes interface IObserver a mezi nimi bude také zaregistrován seznam aut. Seznam aut se už postará o to, aby auta s danou barvou zareagovala, buď v databázi, anebo objektově v paměti. V této konstrukci však musí dojít k jedné drobné změně: Vstupním parametrem těchto volání musí být vždy daný objekt barvy anebo stačí pouze jeho idbarva, aby seznamům bylo jasné, kdo tuto událost vyvolal a podle toho se provede reakce u těch aut, která toto idbarva mají jako cizí klíč. Pseudokód barvy může vypadat nějak takto: class CBarva private long idbarva;......//něco se děje v nějaké metodě a ostatní mají reagovat gcolbarva.onchangebarva.updateall(idbarva) //volám mého správce barev!...//pokračujeme dále... Všimněte si, že objekt barvy vůbec nevolá své zaregistrované objekty, ale zavolá svému správci, aby on zavolal své zaregistrované objekty! V metodě UpdateAll(idBarva) u správce barev se zavolají všechny registrované objekty ke správci barev, mezi nimi bude podle našeho příkladu i objekt správce aut strana 6

7 gcolauta. U něj se spustí metoda Update(idBarva) a v této implementované metodě seznamu se s pomocí tohoto vstupního parametru určí, která auta ze seznamu mají reagovat. Například je možné, že objekt gcolauta provede jako reakci opět pouze jako transformaci do DB a pouze zavolá DBO objekt nějakou metodou a v ní bude spuštěna nějaká stored procedura vstupním parametrem bude samozřejmě převzaté id, zde idbarva. Je zřejmé, že objekt barvy nemusí předávat jako vstupní parametr idbarva, ale může namísto toho předat sám sebe (kdo potřebuje id, tak si jej vyžádá přes property). Pak by se kód v řádku volání správce barev změnil takto:...//něco se děje v nějaké metodě a ostatní mají reagovat gcolbarva.onchangebarva.updateall(this) //volám mého správce barev!...//pokračujeme dále Výhodou předání celého objektu barvy v předešlé konstrukci je možnost získat z barvy i jiné údaje, než pouze idbarva. (poznámka: samozřejmě tyto údaje včetně idbarva musí být vyvedeny ven z objektu barva nějakými public metodami, například přes property). Posloupnost volání kódu je tedy následující: 1. pracujeme s nějakým jedním objektem ze třídy CBarva. 2. dojde k nutnosti vyvolat událost, na kterou čekají auta s danou barvou 3. zavolá se správce seznamu barev, aby danou událost vyvolal na své úrovni. Současně se mu předává buď idbarva anebo celý objekt barvy, u něhož došlo ke změně 4. správce barev zavolá všechny své observery, mezi nimi je registrován i správce aut, zavolá jim všem metodu Update a dá jim vstupní parametr buď idbarva anebo objekt Barva. 5. uvnitř registrovaného správce seznamu aut dojde ke zpracování události se vstupním parametrem barva nebo idbarva. Uvnitř seznamu aut se buď zavolá datový objekt a vyvolá se nějaká odpovídající stored procedura anebo se vyvolají a zkonstruují objekty aut pouze s danou vstupní barvou a jim se zavolají odpovídající metody. strana 7

8 Závěr části 2 U podnikových neboli tzv. enterprise systémů nemůžeme většinou použít vzor OBSERVER přímo na objekty z multiinstačních tříd pocházejících z logického modelu, protože logických instancí je většinou příliš mnoho a vzor OBSERVER předpokládá, že čekající objekty budou umístěny v paměti, aby jim bylo možné zavolat jejich metody. Jedním z řešení je provázat observery na úrovni správců seznamu. Znamená to, že čekajícími objekty (observery) se stávají správci seznamů, kteří jsou zaregistrováni k jiným správcům seznamů, jejichž itemy vyvolávají události. Vyvolání observerů probíhá tak, že daný prvek, který vyvolává událost, zavolá svého správce seznamu a ten zavolá všechny k němu zaregistrované správce seznamů. Přitom se samozřejmě musí předat vstupní parametr, který identifikuje ten prvek (z mnoha), který tuto událost vyvolal, například vstupním parametrem je buď id prvku nebo celý prvek jako objekt. U reagujících zaregistrovaných správců seznamů se tímto vyvolá metoda seznamu, která tuto reakci přenese na všechny ty prvky v seznamu, které používají daný vstupní parametr a další reakce u prvků se provede buď v databázi anebo objektově v paměti V příštím článku se dostaneme ke slíbené modifikaci vzoru OBSERVER v kombinaci se vzorem ADAPTER a jaké to přinese výhody. Konec 2. části strana 8

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

3 Současný pohled na jednotlivé směry SWI

3 Současný pohled na jednotlivé směry SWI 3 Současný pohled na jednotlivé směry SWI 3.1 Úvod Chaotický a překotný vývoj programů vedl ke stavu, označovaném jako KRIZE PROGRAMOVÁNÍ. Poučení z krize bylo v několika směrech. Jedním z nich byl směr,

Více

Vlákna v C# Překlad Threading in C# od Josepha Albahari. Jakub Kottnauer. Z původního seriálu vydaného na Programujte.com

Vlákna v C# Překlad Threading in C# od Josepha Albahari. Jakub Kottnauer. Z původního seriálu vydaného na Programujte.com Vlákna v C# Překlad Threading in C# od Josepha Albahari Jakub Kottnauer Z původního seriálu vydaného na Programujte.com Vlákna v C# Joseph Albahari Copyright Jakub Kottnauer, 2008 1. vydání Překlad: Jakub

Více

PŘÍRUČKA TVŮRCE v LMS Moodle

PŘÍRUČKA TVŮRCE v LMS Moodle Projekt PODPORA MULTIMEDÁLNÍ VÝUKY PŘÍRUČKA TVŮRCE v LMS Moodle Kapitola 1: ELearning nové formy a metody vzdělávání Danuše Bauerová Ostrava 2010 2 ÚVODEM Předkládaný text je součástí Příručky pro tvůrce

Více

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. Školní agenda.

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. Školní agenda. 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 Libor Jelínek Hradec Králové 2014 Úvod Tento studijní text je určen pro studenty pedagogických

Více

Tvorba mapové aplikace pro sledování polohy v Cloud serverová část Windows Azure

Tvorba mapové aplikace pro sledování polohy v Cloud serverová část Windows Azure Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie Tvorba mapové aplikace

Více

Fakulta informačních technologií Vysoké učení technické v Brně. Jak na projekt

Fakulta informačních technologií Vysoké učení technické v Brně. Jak na projekt Fakulta informačních technologií Vysoké učení technické v Brně Příručka pro studenty předmětu Formální jazyky a překladače Jak na projekt (IFJ07) Zbyněk Křivka Projekt FRVŠ 673/2007/G1 Roman Lukáš Lukáš

Více

Řízení projektů zavádění IS do organizací TUTORIAL

Řízení projektů zavádění IS do organizací TUTORIAL Řízení projektů zavádění IS do organizací TUTORIAL Zdenko STANÍČEK 1, Josef HAJKR 2 1 etrium Corporation, a.s. U Vodárny 2,616 00 Brno zdenko.stanicek@etriumgroup.com a Katedra programových a komunikačních

Více

- mikrokontrolér pro začátečníky a snadné použití

- mikrokontrolér pro začátečníky a snadné použití - mikrokontrolér pro začátečníky a snadné použití Následující text byl poprvé zveřejněn v modelářském časopisu Praktická Elektronika Amatérské Radio (www.aradio.cz) v roce 2012 jako seriál článků. Seriál,

Více

Využití aplikace NetSupport School pro školní prostředí

Využití aplikace NetSupport School pro školní prostředí Využití aplikace NetSupport School pro školní prostředí Vytvořeno v rámci projektu Dotkněte se inspirace Registrační číslo: CZ.1.0.7./1.3.00/51.0046 Autoři: Ludmila Klatovská Petr Kofroň Lenka Mandryszová

Více

PROGRAMOVÁNÍ V SQL Podpora výuky databázových systémů na SOŠ, založené na technologiích společnosti ORACLE.

PROGRAMOVÁNÍ V SQL Podpora výuky databázových systémů na SOŠ, založené na technologiích společnosti ORACLE. PROGRAMOVÁNÍ V SQL Podpora výuky databázových systémů na SOŠ, založené na technologiích společnosti ORACLE. Publikace vznikla v rámci projektu CZ.1.07/1.1.07/02.007, Podpora výuky databázových systémů

Více

České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie DIPLOMOVÁ PRÁCE. Filip Antoš

České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie DIPLOMOVÁ PRÁCE. Filip Antoš České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie DIPLOMOVÁ PRÁCE Filip Antoš Problematika skenování historických map a jejich následné prezentace na internetu Problematics

Více

Gymnázium a Střední odborná škola, Nový Jičín, příspěvková organizace. Google dokumenty. Tutoriál projektu MOSS studentská verze

Gymnázium a Střední odborná škola, Nový Jičín, příspěvková organizace. Google dokumenty. Tutoriál projektu MOSS studentská verze Gymnázium a Střední odborná škola, Nový Jičín, příspěvková organizace Google dokumenty Tutoriál projektu MOSS studentská verze Nový Jičín 2010 Mgr. Gustav Žídek Osnova 1 Úvodní informace... 3 2 Cloud Computing...

Více

Výukový materiál pro projekt Podpora multimediální výuky reg. č. CZ.1.07/1.1.07/02.0077

Výukový materiál pro projekt Podpora multimediální výuky reg. č. CZ.1.07/1.1.07/02.0077 Výukový materiál pro projekt Podpora multimediální výuky reg. č. CZ.1.07/1.1.07/02.0077 Obsah Úprava a správa fotografií...5 1 Úvod...5 1.1 Obrazové formáty...5 1.2 Rozlišení...7 1.3 Tisk...8 2 Popis prostředí

Více

Jak na základní registry?

Jak na základní registry? Příručka pro kraje a obce 20mm Jak na základní registry? 15mm 9mm 7mm 5mm Ministerstvo vnitra 2012 20mm Jak na základní registry? Příručka pro kraje a obce Zpracovalo Ministerstvo vnitra 20mm Obsah 1.

Více

D A T A B Á Z O V É S Y S T É M Y

D A T A B Á Z O V É S Y S T É M Y 1(22) Konceptuální úroveň - vytvářím první model reality - ER-model jednoduchý grafický aparát, dá se jednoduše identifikovat - entita skládá se z vlastností, které chci zpracovávat - Chenovo pojetí -

Více

Přiřazení zdrojů. V té to ka pi to le:

Přiřazení zdrojů. V té to ka pi to le: 5 Přiřazení zdrojů V té to ka pi to le: Přiřazení pracovních zdrojů Přiřazení materiálových zdrojů Přiřazení nákladových zdrojů Přiřazení rozpočtových zdrojů Kapitola 5 Přiřazení zdrojů V minulých kapitolách

Více

Manuál pracovních postupů v GIS pro oblast sociálního výzkumu a sociální práci

Manuál pracovních postupů v GIS pro oblast sociálního výzkumu a sociální práci Manuál pracovních postupů v GIS pro oblast sociálního výzkumu a sociální práci pracovní postupy v GIS zpracování statistických dat atributové a prostorové výběry dat interpolační metody geostatistické

Více

(Case Study Essay) Branislav LACKO

(Case Study Essay) Branislav LACKO Informace a jejich využití (Case Study Essay) Branislav LACKO Motto: Informace, které máme - nepotřebujeme. Informace, které jsme potřebovali -už nechceme. Informace, které chceme - nemáme, a nemůžeme

Více

FIT, Brno University of Technology, Czech Rep., email: janousek@fit.vutbr.cz

FIT, Brno University of Technology, Czech Rep., email: janousek@fit.vutbr.cz Simulace a návrh vyvíjejících se systémů Vladimír Janoušek Fakulta informačních technologií, Vysoké učení technické v Brně Brno, 2008 Simulace a návrh vyvíjejících se systémů Vladimír Janoušek 1 FIT,

Více

Servisně orientovaný návrh (část 3: Návrh služeb)

Servisně orientovaný návrh (část 3: Návrh služeb) KAPITOLA 15 Servisně orientovaný návrh (část 3: Návrh služeb) Ještě před tím, než se můžeme pustit do vývoje služby, musíme definovat její rozhraní. Jedná se o klasické zaříkávadlo všeobecně přijímaného

Více

CCC PPPP / M M 222 222 C C P P / M M 2 2 2 2 C P P / MM MM 2 2 C PPPP / M M M 2 2 C C P / M M 2.. 2 CCC P / M M 22222.. 22222

CCC PPPP / M M 222 222 C C P P / M M 2 2 2 2 C P P / MM MM 2 2 C PPPP / M M M 2 2 C C P / M M 2.. 2 CCC P / M M 22222.. 22222 O P E R A Č N Í S Y S T É M CCC PPPP / M M 222 222 C C P P / M M 2 2 2 2 C P P / MM MM 2 2 C PPPP / M M M 2 2 C C P / M M 2.. 2 CCC P / M M 22222.. 22222 Implementace na Sharp MZ-800 VERZE: 1.2 Jiří Lamač

Více

VYUŽITÍ POČÍTAČŮ V ÚČETNICTVÍ

VYUŽITÍ POČÍTAČŮ V ÚČETNICTVÍ SOUKROMÁ VYSOKÁ ŠKOLA EKONOMICKÁ ZNOJMO VYUŽITÍ POČÍTAČŮ V ÚČETNICTVÍ distanční studijní opora Břetislav Andrlík, Jiří Mikulica Soukromá vysoká škola ekonomická Znojmo říjen 2014 Využití počítačů v účetnictví

Více

Univerzita Pardubice. Fakulta ekonomicko-správní Ústav podnikové ekonomiky a managementu

Univerzita Pardubice. Fakulta ekonomicko-správní Ústav podnikové ekonomiky a managementu Univerzita Pardubice Fakulta ekonomicko-správní Ústav podnikové ekonomiky a managementu Řízení změn v podniku Veronika Gajdošíková Bakalářská práce 2013 PROHLÁŠENÍ Prohlašuji, že jsem tuto práci vypracovala

Více

Jak správně citovat aneb Komentář k ČSN ISO 690 PhDr. Naďa Urbánková

Jak správně citovat aneb Komentář k ČSN ISO 690 PhDr. Naďa Urbánková http://www.cz-museums.cz Jak správně citovat aneb Komentář k ČSN ISO 690 PhDr. Naďa Urbánková I. Úvod Vážené kolegyně a kolegové, byla jsem požádána, abych se s Vámi podělila o své zkušenosti z normy ČSN

Více

1 Nástroje používané v mikroekonomii

1 Nástroje používané v mikroekonomii 1 Nástroje používané v mikroekonomii 1.1 Předmět zkoumání Ekonomie se podle tradiční definice zabývá zkoumáním alokace vzácných zdrojů mezi různá alternativní užití tak, aby byly uspokojeny lidské potřeby.

Více

Linux From Scratch. Michal Pecha

Linux From Scratch. Michal Pecha Linux From Scratch alternativní výukový operační systém Michal Pecha Bakalářská práce 2011 ABSTRAKT Cílem této bakalářské práce je vytvoření vlastního linuxového operačního systému s alternativním výukovým

Více

Analýza vybraného procesu ve středně velké potravinářské firmě

Analýza vybraného procesu ve středně velké potravinářské firmě Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Adéla Weinsteinová Analýza vybraného procesu ve středně velké potravinářské firmě Bakalářská

Více