- Stahuj zápisky z přednášek a ostatní studijní materiály
- Zapisuj si jen kvalitní vyučující (obsáhlá databáze referencí)
- Nastav si své předměty a buď stále v obraze
- Zapoj se svojí aktivitou do soutěže o ceny
- Založ si svůj profil, aby tě tví spolužáci mohli najít
- Najdi své přátele podle místa kde bydlíš nebo školy kterou studuješ
- Diskutuj ve skupinách o tématech, které tě zajímají
Studijní materiály
Hromadně přidat materiály
Otázky statnice_mgr_nav_apl_vseobecna_12_otazek
SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika)
Hodnocení materiálu:
Zjednodušená ukázka:
Stáhnout celý tento materiáli, které procesor musí kontrolovat.
Dále se v 80. letech objevily tzv. Very Long Instruction Words, které předstatovaly způsob zajištění paralelního provedení různých aritmetických operací již na úrovní překladače. Procesor tak pro paralelní spuštění instrukcí nemusel kontrolovat vzájemnou závislost mezi instrukcemi a mohl být jednodušeji navržen.
Pojem superpipeline je rozsáhlejší dekompozice pipeline, např. Pentium 4 má až 31 stupňovou pipeline.
S tím také souvisí pojem architektura ANDES, která se vyznačuje tím, že:
Nevykonává instrukce přesně tak, jak jsou zapsané v programu, ale dynamicky jejich posloupnost optimalizuje přičemž cílem je komplexní využití procesoru.
Více výpočetních jednotek, které mohou pracovat současně např. ALU a FLOAT. Každá má vlastní pipeline.
Pořadí vykonávání instrukcí si řídí sám procesor (opět některé instrukce na sobě mohou být závislé) nikoliv překladač i když samozřejmě optimalizovaný překlad může pomoci ke zvýšení výkonu.
Mezi další vlastnosti patří spekulativní skoky (nečeká se na výsledek operace if, ale rovnou se začne provádět předpovězená větev výpočtu), neblokující load/store.
Příkladem takové architektury je procesor MIPS 10000
Paralelní počítače
Jsou počítače s více procesory nebo s více jádry, lze mezi ně zahrnout například nedávno se objevivší procesor Intel Core Duo.
Architektury s více procesory lze dělit podle různých hledisek, například podle počtu procesorů:
Small scale multiprocessing:
2-16 procesorů
Výpočetní model je sdílená paměť
Large scale multiprocessing:
> 100 procesorů
Výpočetní model je distribuovaná paměť
Nebo podle taxonomie pana Flynna z roku 1972:
SIMD (Single Instruction Multiple Data)
Procesory pracují jako vektorové počítače, které jednou instrukcí zpracují prvky jednoho vektoru (pole data).
Jde o jednoduchý programovací model a i samotné procesory mohou být jednoduché.
MIMD (Multiple Instruction Multiple Data)
Procesory zde pracují samostatně nad vlastními daty.
Složitější programovací model.
Konečně podle přístupu do paměti se paralelní výpočetní prostředí může dělit na:
Sdílenou paměť (Symetrický přístup)
Každý procesor vidí celou paměť a každý ma do ní “stejně daleko”
Programování lze realizovat relativně jednoduše, ovšem může nastat problém s paměťovou propustností a s čekáním procesorů mezi sebou.
Výkon vzhledem k omezené paměťové propustnosti s přídáním procesoru nevzrůstá lineárně
Předáváním zpráv (Distribuovaná paměť)
Zde má každý procesor svou paměť a s ostatními procesory komunikuje zasíláním zpráv.
Výkon roste prakticky lineárně, ovšem za cenu vysoké ceny komunikace mezi procesory a tedy i složitějšího programování.
Hybridní systémy (NUMA)
Každý procesor má svou lokální paměť a v systému je ještě sdílená paměť. Lokální paměť si lze představit jako cache pro hlavní paměť.
Procesor však stále může adresovat celou paměť.
Distribuovaná sdílená paměť v clusterech
Může být implementovaná v operačním systému, v tom případě je před programátorem skrytá nebo jako knihovna, která pak umožňuje explicitní programování.
Vystuptuje zde lokální paměť daného uzlu a vzdálená paměť ostatních uzlů.
Systémy se sdílenou pamětí musí nějakým vhodným způsobem řešit problém paměťové koherence. Možné metody jsou založeny např. na broadcastech nebo snoopy cache, kdy procesor sleduje změny v hlavní paměti.
Propojovací sítě
Základní komponenty propojovacích sítí jsou:
Topologie
Přepínání (Jak data proudí mezi uzly)
Směrování (Jak data hledají cestu mezi uzly)
S topologií souvisí pojem bisection width, který určuje počet linek, které je třeba přepnout, aby se systém rozpadl na dvě stejné části.
Dalším pojmem je poloměr sítě, což je rozdíl mezi nejkratší a nejdelší délkou v síti.
Podle topologie se sítě klasifikují na:
Jednorozměrné
Dvourozměrné
Třírozměrné – až hyperkryhle
Plně propojené sítě.
Podle přepínání se sítě rozdělují na:
Přepínání paketů - paket se uloží a přepošle, jednoduché.
Přepínání obvodů – ustaví se spojení, přenáší se, zruší se spojení
Virtuální propojení (cut – through) – rozdělení do menších bloků a posílá se kontinuálně
Směrování červí dírou - speciální případ cut-through, latence nezávisí na vzdálenosti
Podle směrování se sítě dělí na:
Statické (Zdrojové nebo distribuované)
Adaptivní
Koherenci paměti u takovýchto schémat nelze založit z důvodu rozšiřitelnosti, proto se používají tzv. adresářové přístupy.
Např. plně mapované adresáře fungují tak, že každý blok paměti ma u sebe seznam ukazatelů na lokální vyrovnávací paměti. Zpravila to není potřebné a používají se omezené adresáře, které se alokují dynamicky. Mezi další přístupy patří provázané seznamy nebo hiearchické adresáře.
Příklady přístupů
Multiprocessing
Např. běžné PC s dvěma procesory nebo procesorem se dvěma jádry a se sdílenou pamětí.
Cluster
Cluster je více než jeden propojených počítačů, které spolu spolupracují tak, že v některých aspektech vystupují navenek jako jeden počítač.
Clusterů je mnoho druhů např.
High availability cluster – dva nebo více počítačů, i když zpravidla dva pro zajištění redundance v případě výpadku.
Load balancing cluster – pracují tak, že počítač vystupující jako frontend rozděluje práce jednotlivým počítačům v clusteru. Cílem je zvýšení výkonu, většinou poskytujé i funkce z první skupiny tj. zajištění redundance. Příkladem je projekt Linux Virtual Server.
Výpočetní clustery – používají se primárně pro zvýšení výpočetního výkonu. Zpravidla jde o běžné počítače propojené na jednom místě lokální počítačovou sítí případně lokální počítačovou sítí uzpůsobenou pro nízkou latenci – předpokládá se, že paralelní procesy spolu budou intenzívně komunikovat. Pro programování takových výpočtů existují speciální knihovny. např. MPI. Příkladem clusteru je BeoWulf.
Gridy – jsou podobné clusterům v tom smyslu, že jde opět o skupinu propojených počítačů. Počítače jsou zpravidla propojeny na větší vzdálenost buď Internetem nebo nějakým dedikovaným či ad-hoc vytvářeným kanálem. Gridy na rozdíl od clusterů jsou více heterogenní, nemusí jít o stejné počítače. Také jejich výpočetní prostředí je uzpůsobeno spíše pro samostatnou práci jednotlivých uzlů
Masivně paralelní superpočítače – masivně paralelní počítače fungují na základě těsně propojených procesorových uzlů s nějakým řídícím subsystémem. Subsytém má již zmíněný charakter sítě. Dle Flynnovy klasifikace maji architekturu MIMD.
Masivně paralelní systémy, paralelní algoritmy, „jemný paralelismus.
Paralelní programování je o designu a implementaci a ladění počítačových programů, které jsou schopny využít paralelních systémů.
Dekompozice úloh
Paralelní programování rozděluje celkový problém do úkolů pro jednotlivé procesory a synchronizuje běh jednotlivých úkolů tak, aby na konci vznikl smysluplný výsledek.
Paralelní programování lze nahlížet také ze dvou úhlů:
Implicitní paralelismus – o paralelizaci se stará kompilátor nebo nějaký jiný systém a automaticky alokuje práci procesorům.
Explicitní paralelismu – programátor sám určí rozdělení práce.
MPI (Message Passing Interface)
Je komunikační rozhraní pro meziprocesorovou komunikaci v paralelních programech.
Vlastnosti:
Přenositelnost, vazba na různé programovací jazyky, nezávislé implementace
Nezávislá optimalizace na různé architektury
Funkcionalita – snaha pokrýt všechny aspekty meziprocesorové komunikace.
Určena pro clustery i gridy.
PVM (Parallel Virtual Machine)
Byl vyvinut na přelomu 80. a 90. let s cílem vytvářet virtuální superpočítač. Znamenal první krok pro vývoj distribuovaného počítaní. Síť byla tvořena démony pvmd běžícími na různých počítačích s různými OS a knihovny přilinkované k programům. Výpočetní model byly samostatné úlohy řešené na jednotlivých procesorech s komunikací pomocí zpráv.
Koordinační jazyk Linda
pracuje se sdílenou tabulí přístupnou všem procesům zpracovávajícím úlohu
číst, zapsat a mazat může každý proces
má charakter asociativní paměti
pomocí zápisu speciální n-tice do tabulce lze procesy i vytvářet
jde o jednoduchý přístup
Hrubý paralelismus
Granularita paralelismu na úrovni samostatných úloh pro jednotlivé OS, kdy si jednotlivé úlohy pouze zasílají zprávy.
Jemný paralelismus
2. Objektově-orientovaná analýza požadavků, vlastnosti objektů, principy
abstrakce a dekompozice. Vývoj OO metod, historie a kritika. Základy
jazyka UML, tvorba modelů, použití UML. Vývoj řízený případy užití.
Analytické a návrhové vzory.
Objektově-orientovaná analýza požadavků
Objekty a třídy
Analýza je založena principech objektového programování. Jak už název napovídá vystupují v něm objekty, což jsou instance tříd objektů. Např. já jsem instancí třídy osoba. Třídy jsou obecnou kategorií objektů, které mají stejné vlastnosti a mohou provádět stejné operace. Objekty mají strukturu, která se skládá z:
Vlastností (atributů) – (váha osoby, výška osoby)
Chování – operací, metod, které objekt může provádět (osoba může jíst, číst, psát, ...)
Z objektového programování se přenáší následující principy:
Abstrakce
Znamená filtrování reálných objektů tak, že zbydou jen ty vlastnosti, které jsou pro budování informačního systému potřeba.
Dědičnost
Objekty dědí atributy a operace po své třídě nebo třída dědí po jiné třídě.
Polymorfismus
Operace může mít v různých třídách objektů stejné jméno, ale každá třída objektů bude operaci provádět jinak.
Zapouzdření
Objekty skrývají provádění svých operací před ostatními objekty a před okolním světem. Objekt má pro komunikaci s okolním světem rozhraní, pomocí kterého je okolní svět může přimět k vyvolání nějaké činnosti a zbytek operací ukrývá.
Komunikace mezi objekty
Objekty mezi sebou komunikují – zasílají si zprávy. Zasílání zpráv je v podstatě vždy žádost o provedení operací.
Asociace
Asociace označuje stav, kdy nějaká třída má vztah s jinou třídou. Později v popisu UML.
Asociace - Agregace
Speciální případ pro vztah celek-část.
Součástí agregace mohou fungovat nezávisle na sobě.
Asocicea - Kompozice
Silnější forma agregace.
Opět je tranzitivní a asymetrická.
Části nemají mimo celek smysl.
Základy jazyka UML
UML je specifikační jazyk pro objektově orientované softwarové modelování. Používá standardizovaný grafický zápis pro vytvoření abstraktního modelu systému. UML se používá pro popis IS ze všech pohledů ze kterých je třeba, tj:
programátora (diagram tříd, komponent)
uživatele (případy užití)
project managera (diagram balíčků)
správce systému (diagram rozmístění)
analytika (diagram tříd)
K diagramům v UML patří další specifické vyjadřovacích prostředky, které diagramy doplňují. Např. popis ve vhodně strukturovaném jazyce.
Jazyk lze i doplnit tzv. stereotypy, pro které jinak jazyk nemá syntax. Příklad stereotypů jsou návrhové vzory.
Statická struktura systému
Diagram tříd – což jsou kategorie objektů majících podobné chování a vlastnosti a jsou spojené asociacemi.
Diagram objektů – což už jsou konkrétní instance tříd vhodné pro zachycení aktuálního stavu systému v určitém čase.
Diagram komponent – rozdělení vývoje systému na jednotlivé komponenty, např. práce programátorům. Je to fáze po návrhu, kdy je už hotový diagram tříd. Komponenta je v podstatě samostatně spustitelný modul složený z objektů z sdružených za definovatelné rozhraní. Jsou samozřejmě plně zapouzdřené. Představuje kusy aplikace, které se dají naprogramovat zvlášť.
Diagram rozmístění – fyzické rozdělení systému na jednotlivé počítače atd.
Dynamická struktura systému
Diagram případů užití – zachycuje chování systému z hlediska uživatele. V případě pračky je pravděpodobný jen jeden případ užití a to praní prádla.
Diagram činností (aktivit) – což jsou činnosti, ke kterým dochází během případu užití. Např. buben se točí, voda odtéká
Diagramy interakcí:
Diagram sekvencí – ukazuje interakce uspořádané v časové posloupnosti. Vhodné pro RT systémy.
Diagramy spolupráce – ukazuje interakce podle interagujících objektů
Dynamické chování jediné třídy
Stavový diagram – zachybuje přechod mezi stavy objektu v jedné třídě. V podstatě je to konečný automat, který popisuje reakce na nějaký vstup.
Vývoj řízený případy užití
Snaží se zachytit to co uživatelé a další zainteresované osoby od systému očekávají.
Používá use-case diagramy.
Modely jsou jednoduché a umožňují konzultaci s uživatelem. Umožňuje popsat uživateli konkrétní cíle, jakých může dosáhnout pomocí interakce se systémem.
Model případu užití vypadá tak, že je v něm nějaký uživatel, který spustí akci vyvolající “případ užití” a obdží nějaký výstup. Jiný uživatel může vyvolat jinou akci s jiným výstupem. Grafická reprezentace vypadá velmi jednoduše:
Use case se skládá z vymezení:
Hranice systému
Aktéři (Účastníci) – modelují role a nejen uživatele, ale i externí systémy
Jednotlivé případy užití – mohou být spojené s dalšími případy užití
Příklad případu užití
1. Každý strávník má kartu, s tou přijde do menzy, kde si může buď uložit peníze, nebo vybrat jídlo.
2. Dokumentace případů užití:
Vkládání peněz: Případ užití začíná volbou vkládání peněz. Systém načte kartu, ověří ji v databází. Pokud není platná, kartu vrátí s upozorněním na neplatnost karty, případ užití končí. Pokud je platná, vezme peníze od uživatele a přidá je na kartu. Vydá potvrzení.
Výběr jídla: Případ užití začíná volnou vkládání peněz. Systém načte kartu, ověří ji v databází. Pokud není platná, kartu vrátí s upozorněním na neplatnost karty, případ užití končí. Obsluha zvolí jídla a pokud má strávník dost peněz na účtě vydá jídlo. Případ užití končí.
3. Případ užití se dále upraví tak, že se sdruží proces načtení karty a ověření uživatele. Společná funkcionalita se vytáhne do use case “identifikuj strávníka” a zbývající use case ho
vezmou pomocí include
4. Odpovídajícím způsobem se změní dokumentace případu užití.
V diagramu tříd se aktéři stávají třídami se stereotypem .
Kromě lze použít i , který vystupuje jako rozšířující element ve významu nebo.
Use case se většinou vytvářejí z procesní analýzy nebo zkoumáním činnosti a dialogem s účastníky. Use case musí být dále pečlivě popsány, hlavně na rozhraní, aby uživateli
bylo jasné co bude moci od systému očekávat.
Popis procesů a dodržování procesů má zásadní význam např. v procesu certifikace ISO 9000.
Význam případu užití spočívá ve:
Vymezení problému
Odhalení hranic systému
Diskuse požadavků s uživateli
Specifikace úkolů pro vývojáře
Výchozí bod pro návrh
Uložení pro znovupoužití
Diagram tříd
Diagram tříd je grafický pohled na statickou strukturu systému.
Mezi třídami lze používat následující vazby:
Asociace
Asociace označuje stav, kdy nějaká třída má vztah s jinou třídou. Asociace se realizuje přes nějaký vhodný atribut. Např. klub má členy, kterým přiděluje nějaká ID.
Příklad asociace:
Obecně stejně jako u ERD se vyhýbáme vazbám M:N a použijeme raději asociační třídy. Např. pracovní smlouva tzv. asociační třída vznikne, až kdyz nějaký objekt z třídy osoba vstoupí v asociaci s třídou firma.
Asociace mohou být reflexivní. Např. objekt vedoucí je z třídy osoba a může vést více pracovníků. Naopak pracovník může být řízen jen jedním vedoucím.
Agregace
Speciální případ pro vztah celek-část. Je tranzitivní, např. píst je součástí motoru a motor je součástí auta. Je asymetrická, tj. auto není součástí motoru.
Součástí agregace mohou fungovat nezávisle na sobě.
Součást může být sdílena více celky, např. opravna má pro auta více motorů ve skladu.
Kompozice
Silnější forma agregace.
Opět je tranzitivní a asymetrická.
Části nemají mimo celek smysl. Např. položka objednávky jinde než v objednávce nemá smysl. Každá položka objednávky patří právě do jedné objednávky.
Generalizace / Specializace
Je vztah mezi obecným a specifickým elementem třídy. Specializace přidává nějaké dodatečné informace, generalizace je zas víc abstraktní.
Příklad: Dub, Bříza jsou specializace třídy Strom.
Vztahy závislostí
Když je třeba vyjádřit, že změna v cílovém elementu může výžadovat změnu ve zdrojovém elementu.
Interface
Speciální třídy, které nic neimplementuje, ale definuje externě viditelné služby, které pak dále implementují jiné třídy.
Balíky tříd
Skupiny tříd se silnou kohezí – množstvím asociací mezi sebou a naopak malým množstvím asociací ven. Balíky řeší nějakou ucelenou problematiku. Mají význam pro znovupoužitelnost.
Např. třídy voltmetr, šroubovák, kleště jsou balík elektronářadí.
Diagram činnosti
Příklad:
Diagramy interakcí (Sekvenční a spolupráce)
Dynamické diagramy zaměřené na komunikaci mezi objekty (ne s uživatelem).
Sekvenční diagram
Ukazuje interakce uspořádané v časové posloupnosti.
Např. pro specifikace RT systémů
Na ose X jsou objekty, na ose Y jde dolů čas. Mohou se vyvolávat procedury, vrací se nějaké návratové hodnoty, zasílat synchronní nebo asynchronní zprávy.
Diagram spolupráce
Ukazuje interakci mezi objekty organizovanou podle interagujících objektů. Ukazuje zejména vztahy mezi rolemi objektů.
Např. objekt customer vyvolává metodu vytvoř objednávku u manažera objednávek. Manažer objednávek zkontroluje platbu za objednávku a vytvoří požadavek na expedici do manažera skladu.
Stavový diagram
Stavový diagram se většinou píše pro jednu třídu. Stavový diagram reprezentuje stavový automat , který je grafem stavů a přechodů a popisuje odezvu na příchod vnějšího stimulu.
Dědí se pro všechny objekty třídy.
Zapisuje se v podstatě jako konečný automat.
Příklad: model telefon.
Vývoj OO metod, historie a kritika
UML patří mezi modelovací techniky, který se snaží kombinovat různé přístupy z různých oblastí např. ERD ze strukturované analýzy, toky práce z procesního řízení atd. UML poskytuje sadau nástrojů pro vytváření modelů, ale nedefinuje jak tyto modely použít (metodika např. RUP – Rational Unified Process).
UML se vyvíjí od druhé poloviny 90. let (Booch, Jacobson, Rumbaugh, Gamma) hlavně z use-case, ale nejrůznějších dalších technik.
UML je pro začátečníka příliš komplexní a rozsáhlý, pokud se snaží vytvářet všechny diagramy.
UML také neřeší mapování objektového modelu na relační.
UML také nemá syntax na návrhové vzory.
Analytické a návrhové vzory
Návrhový vzor popisuje opakovaně se objevující návrhovou strukturu – nějaký návrhový problém a také definuje řešení.
Předpis pro to, jak se objekt definovaný vzorem v širším slova smyslu chová.
Rozlišujeme např. tyto druhy vzorů:
Vzory tvořící:
Factory – třída, která podle zadaných parametrů vytváří objekty různých tříd s nějakým daným interface.
Singleton – objekt, který může být v systému jenom jednou (jediná instance třídy), a poskytuje do ní globální přístup např. objekt zabezpečující logování.
Vzory strukturální:
Adaptér – objekt, který se přilepí na jiný objekt a přizpůsobí jeho interface na jiný interface.
Vzory chování:
Iterátor – objekt, který prochází elementy agregovaného objektu sekvenčně bez potřeby znalosti vnitřní reprezentace.
Identifikace uživ.
Výdej jídla
MENZA
Vkládání peněz
MENZA
Vkládání peněz
Výdej jídla
KLUB
Člen klubu
member #ID: String
member #ID: String
SMLOUVA
je zaměstnána v
FIRMA
OSOBA
zaměstnavatel
zaměstnanec
OSOBA
vedoucí
*
0..1
DUB
MOTOR
KAROSÉREIE
AUTO
STROM
BŘÍZA
JAVOR
Factory
Transport
3. Číselné soustavy, vztahy mezi číselnými soustavami, zobrazení čísel v počítači.
Číselné soustavy
Jsou způsoby reprezentace čísel.
Dnes se obvykle používají polyadicke soustavy, kde se cisla vyjadruji jako soucet mocnin
o jistem zakladu násobených jednoduchými činiteli.
Nejznámější soustavou je soustava desítková, kde se číslo vyjadřuje jako součet mocnin deseti vynásobených jednoduchými sočiniteli. Součinitelé mohou nabývat hodnot 0,1,...,9 a nazývají se číslice.
Pro zobrazení v počítači jsou vhodnější soustavy o jiných základech např. dvojková, šestnáctková (zde se číslice 10...16 nazývají písmeny A..F) nebo o
Vloženo: 26.04.2009
Velikost: 244,76 kB
Komentáře
Tento materiál neobsahuje žádné komentáře.
Mohlo by tě zajímat:
Reference vyučujících předmětu SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika)Podobné materiály
- IA008 - Computational Logic - Otazky_jaro2008
- PA103 - Objektové metody návrhu informačních systémů - Vypracované otázky zkouska
- PA105 - Technologie informačních systémů II - Otazky-zpracovane
- PA151 - Soudobé počítačové sítě - Vypracovane_otazky
- PA159 - Počítačové sítě a jejich aplikace I - Otazky_vypracovane
- PB001 - Úvod do informačních technologií - Vypracovane_otazky
- PB001 - Úvod do informačních technologií - Úvod_do_IT_vypracovane_otazky
- PB009 - Základy počítačové grafiky - Otazky_jaro_2006
- PB009 - Základy počítačové grafiky - Vypracovane_otazky
- PB029 - Elektronická příprava dokumentů - Zkusebni otazky
- PB114 - Datové modelování I - Teoretické otázky
- PB152 - Operační systémy - Otazky_komplet
- PB156 - Počítačové sítě - Otazky_site
- PB156 - Počítačové sítě - Vypracovane_otazky
- PV017 - Bezpečnost informačních technologií - Vypracované otázky
- PV019 - Geografické informační systémy I - Vypracovane_otazky
- PV062 - Organizace souborů - Otazky
- PV062 - Organizace souborů - Otazky_and_Odpovedi
- PV112 - Programování grafických aplikací - Otázky
- PV112 - Programování grafických aplikací - Vypracované otázky
- PV157 - Autentizace a řízení přístupu - Vypracovane-otazky.
- PV182 - Komunikace člověka s počítačem - Vypracovane-otazky_podzim2008
- PV183 - Technologie počítačových sítí - Otazky-vypracovane
- PV203 - IT Services Management - Otazky_2008
- SZBAP - Státní zkouška (bakalářský studijní program Aplikovaná informatika) - Statnice- otazky-jaro-2006
- SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika) - Otazky_jaro2006
- SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika) - Vypracovane_otazky_statnice_IS
- PB007 - Analýza a návrh systémů - Otazky_ke_zkousce_2002
- PV123 - Základy vizuální komunikace - Otazky
- PV123 - Základy vizuální komunikace - Otazky_2
- IA062 - Randomized Algorithms and Computations - Zkouškoové otazky_04_06_2008
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 13_06_2007
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 2007
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 24.5.2006
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 31.5.2006
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky a 31.5.2006
- IA157 - Logická analýza přirozeného jazyka II - Testové otazky_2007
- IV054 - Kódování, kryptografie a kryptografické protokoly - Zkouska 10_1_2003_zk_4_otazky
- PB114 - Datové modelování I - Teoreticke_otazky_doplneni_12_6_2007
- PB154 - Základy databázových systémů - Zkouška otazky_z_pisomiek
- PB151 - Výpočetní systémy - Otazky
- PB151 - Výpočetní systémy - Otazky_a_odpovedi
- PV005 - Služby počítačových sítí - Vypracované otazky
- PA103 - Objektové metody návrhu informačních systémů - Vypracované otázky ze všech zkoušek
Copyright 2025 unium.cz


