Informačné systémy 2

Dátové vzory

Firma :

- ľudia

- objekty

- činnosti

- vzťahy s okolím – obchodovanie na základe zmlúv, vykonávanie platieb

Ľudia

Pyramída ( vzťah nadriadený a podriadený )

- problém so zmenami

- pevné pracovné kategórie

Oddelenie kategórie od osoby

- neeviduje sa história nadriadenosti a podriadenosti

- môže byť viacero nadriadených

- môžu byť aj iné vzťahy než nadriadenosť a podriadenosť a môžu byť rôznych typov

Vzťah ako samostatná entita (trieda)

- relácia nadriadený-podriadený sa transformuje na entitu (a bude možné zaznamenať aj iné typy vzťahov)

Relácie medzi pracovnými kategóriami ako entity

- keďže pracovné vzťahy medzi osobami vznikajú na základe smerníc, treba to zachytiť

Doplnený diagram – relácie medzi pracovnými kategóriami a typmi pracovných vzťahov

Firma

Priamočiara reprezentácia organizačnej štruktúry

Flexibilná reprezentácia

Vzor zodpovednosť zachytí aj vzťahy medzi osobami a organizáciami

Zovšeobecnenie vzoru zodpovednosť

Objekty

Výrobok a jeho typ

Generalizácia objektov

Kategória objektov

Agregovanie objektov

Súvislosť objektov

Kusový a nekusový objekt

Dávka

UML metamodel

– podľa špecifikácie UML 1.4, ktorá je umiestnená na http://skmi.science.upjs.sk/~lencses/01-09-67.pdf

– prednášky (dve) boli založené na kapitole UML Semantics - text od str. 57 po str. 260

GRASP – navrhovanie objektov so zodpovednosťami

- ako vytvárať diagramy tried vo fáze návrhu (class diagrams v design modeli vo fáze Elaboration v RUP), ako im definovať metódy a zasielanie správ medzi triedami

- general reponsibily assigning software patterns (GRASP)

- je to overená metodika pre návrh software

- vzory pre návrh objektov a prideľovania zodpovednosti

- zodpovednosť sa delí na :

o vedieť (o súkromných zapuzdrených dátach, o asociovaných objektoch, o veciach, ktoré sa môžu odvodiť alebo vypočítať)

o robiť (vytvárať objekt, robiť výpočet, iniciovať nejakú akciu pomocou iných objektov, riadiť a koordinovať aktivity v iných objektoch)

- vzory sú určené svojím menom, problémom a riešením problému

Information Expert

- riešenie: trieda, ktorá má informácie, ktoré potrebuje na splnenie svojej zodpovednosti

- problém: všeobecný princíp prideľovania zodpovednosti objektom

Príklad: Kto by mal vedieť celkovú sumu za predaj ?

Postup:

1. Prezrieť design model (softwérové triedy)

2. Prezrieť domain model (konceptuálne doménové triedy)

Predaj v Design Model ( inšpirované podľa Domain Model ) bude mať metódu getTotal()

Položka bude mať getSubTotal()

Tovar bude mať getPrice()

Predaj: vie celkovú sumu

Položka predaja: vie cenu za položku

Tovar: vie cenu za tovar

- každá z týchto tried je informačným expertom

Výhody

- každý objekt si zapuzdrí svoju vlastnú informáciu, ktorú potom využíva na splnenie svojej úlohy (tým znižuje väzbu – low coupling, čo vedie ku robustnejším a ľahšie spravovateľným systémom)

- správanie je rozdistribuované medzi viac tried, ktoré majú požadovanú informáciu (tým sa zvyšuje súdržnosť – cohesion, čo opäť vedie ku ľahšej pochopiteľnosti a údržbe)

Creator

- riešenie: trieda B vytvára inštancie triedy A ak:

o B agreguje objekty A

o B obsahuje objekty A

o B zaznamenáva objekty A

o B má inicializačné dáta, ktoré sú dodané ku A počas vytvárania ( B je inf. expert vzhľadom ku vytváraniu A )

- problém: kto je zodpovedný za vytváranie nových inštancií

Príklad: Pokladňa vyžaduje od Predaja vytvoriť Položku – vytvorPoložku( množstvo )

Predaj vytvorí položku: vytvor(množstvo)

Low coupling ( slabá väzba, spojenie, spriahnutie )

- riešenie: Prideliť zodpovednosť tak, že spojenie ostane slabé

- problém: Ako zabezpečiť nízku závislosť od zmien, znížiť dopad zmien, zabezpečiť vysokú použiteľnosť

Coupling (väzba) je miera toho, ako silne je jeden element spojený (má informácie, je závislý) s inými elementami. Element so slabou väzbou nie je závislý na príliš mnoho iných elementoch (triedy, subsystémy, systémy atď.). Element so silnou väzbou na ostatných má problémy s

- zmeny v zviazaných elementoch sa prejavia vo vynútených zmenách v nich všetkých

- ťažšie sa izolovane pochopí

- ťažšie sa znova využije, keďže je nutná prítomnosť alebo zásahy v elementoch, na ktorých závisí

Príklad: Pokladňa vytvorí Platbu a tú pridelí Predaju

alebo Pokladňa signalizuje vytvorenie Platby Predaju a ten ju vytvorí

Druhý diagram podporuje nižšiu väzbu. Platba totiž aj tak závisí od Predaja a je teda lepšie, keď závisí iba od neho.

V praxi treba úroveň väzby uvažovať vždy spolu so vzorom Expert a High Cohesion. Extrémny prípad nulovej väzby (žiadna väzba) nie je žiadúci, keďže v OO technológii ide o spoluprácu prepojených objektov komunikujúcich pomocou správ. Vysoká väzba môže vzniknúť v prípade stabilných elementov. Taktiž nie je nutné odstraňovať vysokú väzbu všade, stačí len tam, je potenciálna vysoká nestabilita alebo predpokladaný vývoj.

Typy väzieb medzi typom T1 a T2 v OO jazykoch:

- T1 má atribút, ktorý je typu T2

- objekt T1 volá metódu objektu T2

- T1 má metódu, ktorá odkazuje na typ T2, napr ako parameter, lokálnu premennú alebo návratovú hodnotu

- T1 je priama alebo nepriama podtrieda (potomok) T2

- T2 je interface a T1 ho implementuje

Výhody pre element s nízkou väzbou:

- znižuje množstvo zmien v ostatných elementoch

- ľahšie sa samostatne pochopí

- ľahšie sa používa

High cohesion ( vysoká kompaktnosť, súdržnosť )

- riešenie: prideliť zodpovednosť tak, že súdržnosť ostane vysoká

- problém: Ako udržať komplexnosť spravovateľnú ?

- trieda ( alebo podsystém ), ktorá má súvisiace zodpovednosti a nemá príliš veľa práce, má vysokú súdržnosť ( ľahšie sa znovupoužíva, udržuje )

Príklad: Pokladňa vytvorí Platbu a tú pridelí Predaju

alebo Pokladňa signalizuje vytvorenie Platby Predaju a ten ju vytvorí

Druhý diagram podporuje vyššiu súdržnosť. Pokladňa nebude robiť dve (málo súvisiace) veci, ale len jednu – pri dvoch to nevadí, ale pri väčšom množstve nesúvisiacich operácií sa zníži súdržnosť.

Stupne súdržnosti:

- veľmi nízka súdržnosť : trieda je zodpovedná za veľa vecí týkajúcich sa rôznych oblastí (napr. DB-RPC interface)

- nízka súdržnosť: trieda je zodpovedná za komplexné úlohy v jednej oblasti (DB interface)

- vysoká súdržnosť: trieda má priemerné zodpovednosti v jednej oblasti a spolupracuje s ostatnými na splnení úloh (DBConnection, DBTable, DBQuery)

- priemerná súdržnosť: trieda má malé až priemerné zodpovednosti v rôznych oblastiach, ktoré logicky súvisia s danou triedou, ale nie medzi sebou navzájom (Company – zamestnanci a ich financie)

Analógia s reálnym svetom – ak má osoba veľa nesúvisiacich zodpovedností, prestáva efektívne pracovať

Porovnanie s modulárnym návrhom – modularita je vlastnosť systému, ktorý je dekomponovaný do množiny súdržných a slabo spojených modulov.

Súdržnosť a väzba : Yin a Yang, zvyčajne zlá súdržnosť implikuje zlú väzbu a opačne.

Výhody:

- jasný návrh

- zjednodušená údržba a vylepšovanie

- často je podporená slabá väzba

- zvýšená znovupoužiteľnosť

Controller ( dozorca, ovládač, riadiaci prvok )

- riešenie: Prideliť zodpovednosť za príjem a obsluhu systémových udalostí triede, ktorá:

o reprezentuje zariadenie, subsystém, alebo celý systém

o reprezentuje use case scenár, kde sa systémové udalosti vyskytujú: <UseCaseName>Handler, Coordinator, Session

o window, applet, view nie sú controller, je to UI, ktoré posielajú udalosti ku controlleru, UI by nemalo byť priamo späté s výkonnými triedami

- problém: Kto je zodpovedný za obsluhu vstupných (systémových) udalostí ?

Ak pokladník stlačí tlačidlo „vlož Položku“, vygeneruje systémovú udalosť – na túto udalosť reaguje systémová operácia. Controller je objekt ( nie user interface ) zodpovedný za príjem a obslúženie systémových udalostí

Počas analýzy sa často používa trieda Systém, ktorej sú priradené systémové operácie. Počas návrhu treba túto triedu nahradiť príslušným Controllerom

Controller zvyčajne tiež len deleguje obsluhu ďalej, vykonáva riadenie a koordináciu, sám nepracuje veľa. Ak deleguje príliš veľa nesúvisiacich udalostí a obslúh, je preťažený. Vtedy mal malo byť viac controllerov, väčšie delegovanie práce

Príklad: Po stlačení vložPoložku to zachytí nejaké okno a to by malo delegovať obsluhu tejto udalosti Pokladni alebo ObsluhePredaja. Neurobí to priamo, ale postúpi udalosť Ovládaču a ten ho postúpi Pokladni alebo Obsluhe

Výhody:

- zvýšená možnosť znovupoužitia tried s aplikačnou logikou, ktoré sa v tomto prípade zaručene nevyvolávajú vo vrstve interface

- možnosť zmeny interface

- sledovanie a zmena udalostí v use-case : niekedy je nutné zaistiť správne poradie systémových udalostí a controller je prirodzené miesto na ich zachytávanie a zmenu (napr. vytvorPlatbu sa nesmie vyskytnúť pred ukonciPredaj)

Problémy s preťaženými ovládačmi – treba ich rozdeliť

- jediný controller, ktorý zachytáva všetky systémové udalosti (porušené high cohesion)

- controller, ktorý vykonáva mnoho úloh bez delegovanie časti svojej práce

Design Class Diagrams

- triedy, asociácie, atribúty

- interface s operáciami a konštantami

- metódy

- typy atribútov

- navigovateľnosť ( možnosť prechádzať z jedného konca role na druhý - pokladňa zaznamenáva Predaj )

- závislosti ( jeden element má informácie o inom elemente – Predaj má info o Špecifikácii tovaru )

- telá metód : pseudokód alebo ľubovoľný jazyk

Ďalšie GRASP vzory

Polymorfizmus

- riešenie: Ak správanie závisí na type, prideliť zodpovednosť za za správanie pomocou operácií polymorfizmu (dedičnosť a preťaženie)

o nerobiť to pomocou podmieňovacích príkazov a testu na typ

- problém: Ako obslúžiť alternatívne správanie závislé na type, komponenty, ktoré možno ľahko zapojiť do systému

Príklad: Komponent umožňujúci využiť platenie platobnou kartou. Každá banka si môže definovať vlastné spôsoby pripojenia.

Po definovaní interface sa definuje trieda, ktorá ho implementuje:

Polymorfizmus je základný princíp na návrh systému tak, aby vedel obsluhovať podobné variácie udalostí, správ, volaní … V prípade takého návrhu systému je ľahké doplniť nové triedy (interface, ..), ktoré zabezpečia novú funkčnosť s minimálnym dopadom na ostatné elementy.

Nemá význam používať polymorfizmus v sitáciách, o ktorých sa nevie alebo nie je tam pravdepodobné, že by dochádzalo ku variáciam. Zbytočne sa tým komplikuje návrh.

Výhody:

– ľahké rozširovanie systému pre nové variácie správania

– nové implementácie elementov systému môžu byť vytvorené bez zmeny na ostatných komponentoch

Pure Fabrication (umelý výtvor)

- riešenie: Priradiť vysoko súdržnú množinu zodpovedností umelej triede, ktorá nereprezentuje žiaden doménový koncept tak, aby bola zachovaná nízka väzba

- problém: Čo v prípade, ak žiadna z tried v doménovom alebo design model nemôže mať zodpovednosť za nejaké správanie bez porušenia súdržnosti a väzby

Príklad: Trieda Predaj by mala byť perzistentná. Ako by sa mala ukladať do databázy ? Buď bude mať sama metódy na spoluprácu s databázou (a každá iná trieda to bude mať tiež), čím sa poruší súdržnosť i väzba, albo bude existovať samostatná trieda DB, ktorá to zabezpečí

Týmto spôsobom sme získali výhody:

– Predaj zostal dobre navrhnutým, s vysokou súdržnosťou a nízkou väzbou

– DB je tiež sama relatívne súdržná (dala by sa vylepšiť)

– DB je znovupoužiteľná a ľahko udržiavateľná

Dva typy návrhu tried a objektov:

– dekompozícia podľa reprezentácie (Predaj)

– dekompozícia podľa správania (GenerátorObsahu): často je to umelý výtvor

Výhody:

– podporená vysoká súdržnosť

– podporená znovupoužiteľnosť

Indirection (presmerovanie)

- riešenie: Priradiť zodpovednosť medzičlánku, ktorý bude prepojený medzi dotyčnými elementami tak, aby neboli priamo prepojené

- problém: Ako priradiť zodpovednosť tak, aby sme sa vyhli priamej väzbe medzi dvoma a viac elementami?

Príklad: Rozhranie pre komunikáciu s bankou je prostredníkom medzi Predajom a nízkoúrovňovým API pre prácu s TCP/IP

Výhody:

– nižšia väzba medzi elementami (a teda ľahšie zapájanie iných elementov s podobným správaním)

Protected variations (ochrana pred zmenami)

- riešenie: Identifikovať body predpokladaných variácií a nestabilít a vybudovať okolo nich stabilné rozhranie

- problém: Ako navrhovať objekty, systémy a iné elementy tak, aby variácie alebo nestability v týchto elementoch len minimálne ovplyvnili ostatné elementy

Príklad: Rozhranie pre komunikáciu s bankou je vytvorené tak, aby bod nestability (pridanie novej banky s iným komunikačným protokolom) bol ošetrený – pomocou polymorfizmu

Iné príklady:

– základné mechanizmy: zapuzdrenie, interface, polymorfizmus, presmerovanie

– brokers, virtual machine (to je presmerovanie)

GoF : Design patterns (1995)

- popis často opakovaných vzorov pri návrhu software

- sú v súlade s GRASP

Adapter (adaptér)

- vychádza z polymorfizmu, presmerovania a ochrany pred zmenami

- rieši problém nekompatibilných rozhraní, prípaden poskytuje stabilné interface pre podobné komponenty s rôznymi rozhraniami

- konvertuje originálny interface na iný cez prostredníka – adaptér

- príklad : adaptér pre pripojenie sa ku databáze v JDBC

public class Adapter implements Target {

public Adapter(Home home){

super();

this.home = home;

}

private Home home;

}

Factory (továreň)

- trieda zodpovedná za vytváranie objektov

- založená na tvorcovi

- rieši problém vytvárania objektov so zložitým vytváraním, pričom teda oddelí zodpovednosť za vytváranie kvôli lepšej súdržnosti

- príklad : factory na vytváranie adaptérov pre pripojenie sa ku databáze

- abstract factory je rozšírenie vzoru factory, v ktorom sa vytvárajú skupiny objektov so spoločným rozhraním

public class factory implements abstractFactory {

public abstractProduct createabstractProduct(){

return new ConcreteProduct1();

}

Singleton (jediný)

- rieši problém, keď je potrebná práve jedna inštancia nejakej triedy (napr. factory)

- definuje statickú metódu, ktorá vracia dotyčný singleton

- príklad: Toolkit

o tu je nevhodné súčasné použitie factory (nedá sa použiť polymorfizmus, nemožno zmeniť singleton na „multiton“)

- vhodné použiť lazy inicialization

public class singletonFactory {

public static synchronized singleton getInstance(){

if (instance == null) {

instance = new singleton();

}

return instance;

}

private static singleton instance = null;

}

Strategy (stratégia)

- založené na polymorfizme, poskytujú ochranu pred zmenami, často je vytváraná pomocou factory

- pre každý algoritmus je definovaná samostatná trieda so všeobecným rozhraním

- rieši problém často sa meniacich podobných algoritmov

- príklad: výpočet zľavy

Composite

- rieši problém často sa meniacich konkurentných algoritmov

- vytvorí sa trieda (composite) obsahujúca triedy riešiace konkurentné algoritmy, pričom ona i obsiahnuté triedy implementujú rovnaký inteface (navonok sa javia rovnako)

- samotná trieda potom rozhodne, aký algorimus použije

Facade (front, priečelie, fasáda)

- rieši problém jednotného a jediného rozhrania pre nejaký subsystém (aby sa nevytvorila veľká väzba medzi elementami subsystému a triedou, čo ich používa)

- vytvorí sa trieda (vstupný bod), ktorá bude prostredníkom medzi subsystémom a okolím

- je to v podstate „front-end“ pre daný subsystém

- poskytujú ochranu pred zmenami v subsystéme, pomocou presmerovania znižujú väzbu, často sa k nim pristupuje pomocou singletonu

Observer (pozorovateľ)

- rieši sa problém, keď rôzni prihlasovatelia chcú vedieť a reagovať na stav alebo udalosť v publikujúcom objekte (a publikujúci objekt chce udržať nízku väzbu s prihlásenými objektami)

- publish/subscribe model

- príklad: AWT 1.1

Chain of responsibility (reťaz zodpovednosti)

- rieši sa problém, keď treba vybaviť požiadavku nejakého klienta a nevie sa presne, ktorí z obluhovateľov ju vybavia

- definuje sa všeobecná obsluha, ku ktorej pristupuje klient a tá postupne podáva požiadavku na vybavenie žiadosti konkrétnym obsluhovateľom a jeden z nich ju vybaví

- príklad: obsluha v reštaurácii, objednanie auta

Layers (vrstvy)

- rieši sa problém, keď treba znížiť väzbu medzi jednotlivými subsystémami organizovanými hierarchicky

- definujú sa vrstvy, ktoré majú definované rozhranie (facade) a vždy môže jedna vrstva volať len najbližšiu podriadenú vrstvu

- príklad : OSI model, operačný systém

- klasická 2 a 3 vrstvová architektúra (interface, aplikačná logika a úložište)

Proxy

- rieši sa problém, keď sa nedá (alebo je to nevhodné) priamo pristupovať ku nejakému reálnemu objektu

- pridá sa presmerovanie: proxy, ktoré má zhodný interface s reálnym subjektom a klient potom pristupuje ku proxy, ktoré sprostredkuje jeho žiadosti von a vráti mu odpovede

- príklad : http proxy, firewal

Master – slave pattern

- riadiaci vzor

- inteligentný kontrolér vysiela príkazy a dostáva odpovede od podriadených elementov (ktoré typicky neinicializujú komunikáciu)

- symetrický multiprocesing (SMP): podriadené uzly sú viac menej identické a nadriadený komponent distribuuje medzi ne úlohy dynamicky (napr. podľa záťaže)

- asymetrický multiprocesing : úlohy podriadených elementov sú stanovené už v čase kompilácie (menšie nároky na plánovanie úloh, avšak menšia flexibilita)

Mikrokernel pattern

- vrstvový vzor

- aplikácia je rozdelená do vrstiev usporiadaných hierarchicky, pričom vrstva môže vždy používať služby len najbližšej podriadenej vrstvy

Broker patter

- prepracovaný proxy patter

- broker je objekt, ktorý pozná umiestnenie ostatných objektov, ktoré ponúkajú služby (pozná ich buď priamo – v čase kompilovania, alebo sa objekty u neho registrujú)

Model – view – controller (MVC) pattern

- špecializovaná forma Observer vzoru

- oddelenie dát, výzoru a správania sa objektu

- typický príklad je JTable v balíčku swing

- má TableModel obsahujúci dáta, pri zmene dát sám volá Renderer na vykreslenie

- má listenery slúžiace na spracovanie udalostí

Transaction pattern

- spoľahlivé zasielanie správ

- využíva sa, ak treba udržať spoľahlivé spojenie pomocou nespoľahlivého média

- tri stupne spoľahlivosti:

o at most once (najviac raz)

o at least once (aspoň raz)

o exactly once (práve raz)

- úspešný scenár pre exactly once:

Randezvous pattern (stretnutie)

- synchronizácia paralelných úloh (napríklad riadený prístup ku zdieľaným zdrojom, alebo čakanie na dokončenie behu úlohy-vlákna)

Information retrieval

- reprezentácia, uchovanie, organizovanie, získavanie informácií (informácie relevantné ku otázke)

- odlišnosť oproti data retrieval (chceme získať informáciu týkajúcu sa otázky a nie dáta/objekty, ktoré presne spĺňajú jasne definované podmienky v reg. výraze alebo výraze relačnej algebry)

- užívateľ:

o transformácia jeho požiadaviek do jazyka špecifického pre daný systém

o po získaní odpovede jej prechádzanie (browsing)

o filtering (push action)

- logická reprezentácia dokumentov:

o keywords (generované automaticky alebo pomocou experta)

o full text

o eliminácia stop words, stemming

Modely

- booleovský (+ fuzzy, + rozšírený booleovský)

- vektorový (+ rozšírený vektorový, + LSI, + neurónové siete)

- pravdepodobnostný ( + Byesove siete, + inferenčné siete, belief siete )

Formálne, model je štvorica ( D, Q, F, R(q_i, d_i) ), kde

- D je logický pohľad(y) alebo reprezentácia dokumentov kolekcie

- Q je logický pohľad alebo reprezentácia užívateľských požiadaviek (query)

- F je framework pre modelovanie reprezentácií dokumentu, otázok a ich vzťahov

- R je ohodnocovacia funkcia

Dokument je charakterizovaný množinou indexovacích termov (gramatické korene významných slov), ktoré sú zvyčajne ohodnotené podľa sémantickej dôležitosti.

Booleovský model

- založený na teórii množín a booleovskej algebre

- váha indexovacieho termu je binárna (0 alebo 1, podľa toho, či sa term vyskytuje alebo nevyskytuje v danom dokumente)

- otázka je zložená z termov pospájaný spojkami and, or a but (zvyčajne sa transformuje na DNF); miesto not je but (okrem), aby sme nemali príliš veľkú množinu vrátených dokumentov

- ohodnocovacia funkcia:

o sim(d_i,q) = 1, ak je splnená otázka

o = 0 ináč

- výhody:

o jednoduchý, ľahko pochopiteľný (podobá sa data retrieval)

o bol často implementovaný

- nevýhody:

o dokument je relevantný alebo nie je, nie je nič medzi tým (partial matching), čiže sa často získa buď priveľa alebo primálo dokumentov; nevieme tiež usporiadať nájdené dokumenty

o transformovanie otázky do booleovského výrazu nie je jednoduché

Vektorový model

- váha indexovacieho termu je stanovená podľa jeho dôležitosti:

o čím častejšie sa daný term vyskytuje v dokumente, tým by mala byť jeho váha vyššia

o čím častejšie sa daný term vyskytuje v celej kolekcii dokumentov, tým by mala byť jeho váha nižšia (pretože klesá jeho schopnosť odlíšiť jeden dokument do druhého)

o nájdenie relevantného dokumentu sa podobá na úlohu zhlukovania dokumentov do dvoch zhlukov – podobných otázke a nepodobných otázke – chceme maximalizovať podobnosť v rámci zhluku a minimalizovať podobnosť medzi zhlukmi

o tf-idf formula: w_{i, j} = tf_{i, j} * log(N / N_j), kde tf_i,
j je počet výskytov j-teho termu v i-tom dokumente i, N je počet všetkých dokumentov a N_i je počet dokumentov, v ktorých sa vyskytuje j-ty term, w_{i, j} je váha j-teho termu v i-tom dokumente

o podobnosť dokumentu a otázky (ktorá je tiež transformovaná na dokument) je potom: sim(d_i,q) = (d_{i *}q) / | d_i| * | q |, kde v čitateli je skalárny súčin vektorov a v menovateli je súčin ich veľkostí

o je to v podstate kosínus uhla dvoch vektorov (dokumenty sú vektory váh v M-dimenzionálnom vektorovom priestore, kde M je počet indexovacích termov celej kolekcie; vektory majú teda zvyčajne väčšinu zložiek nulovú)

- výhody:

o jednoduchý, rýchle spočítanie relevantnosti dokumentu, usporiadanie odpovedí (partial matching), v súčasnosti najpoužívanejší

- nevýhody:

o vzájomná nezávislosť termov (dokument je reprezentovaný vektorom váh, kde sa stráca informácia o korelácii termov ), v praxi sa použitie korelácie však ukazuje ako nevýznamné

Vyhodnotenie relevantnosti

- presnosť = RR / A

- úplnosť = RR / R

- RR: relevantné získané dokumenty (prienik R a A)

- R: relevantné dokumenty (pravý ovál)

- A: získané dokumenty (ľavý ovál)

- vzťah presnosti a úplnosti:

o diagram je vytvorený na základe priemeru výsledkov vyhľadávaní

o zo získanej postupnosti vrátených dokumentov sa postupne berie napr. prvých desať, potom prvých dvadsať, potom prvých tridsať .. až prvých n dokumentov a stále sa spočíta presnosť a úplnosť a nanesú sa do grafu

o interpoláciou vznikne klesajúca krivka (čím viac dokumentov vezmeme, tým viac stúpa úplnosť, ale naopak klesá presnosť)

Query

- typy otázok:

- zoznam keywords (v booleovskom modeli pospájaných logickými spojkami)

- kontextové otázky – použitie funkcií (musí to byť podporované indexom)

o fráza (keywordy tvoria frázu, sú vedľa seba)

o proximity (keywordy sú blízko seba)

- prirodzený jazyk (treba extrahovať významné termy a transformovať na otázkový jazyk vlastný systému)

- štrukturálne otázky

o formulár (reštriktívne, avšak ľahko implementovateľné), rozšírenie SQL o fulltextové vyhľadávanie

o hypertext (maximálna voľnosť voči štruktúrovaniu, avšak problémy s definovaním opytovacieho jazyka)

o hierarchická štruktúra (niečo medzi predošlými dvoma spôsobmi; napr. kniha sa člení na kapitoly, tie na paragrafy, sekcie, odstavce, sú tam nadpisy, obrázky) – v súčasnosti je to XML, nad ktorým je definovaný XQL (XML Query Language)

- pattern matching:

o word

o prefix

o suffix

o substring

o ranges

o errors (s prahom)

o regular expressions

Query operations

- relevance feedback (spätná väzba) : najčastejšie používaná metóda na preformulovanie otázky – užívateľ po zadaní otázky vyberie z postupnosti vrátených dokumentov pre neho relevantné a systém nejakým spôsobom pozmení otázku

- problém so znížením presnosti za cenu vyššej úplnosti

- základná rovnica na zmenu váh pridaných termov (mali by mať menšiu váhu)

o Rocchio: ,kde R a S je postupnosť dokumentov označených ako relevantných a nerelevantných, n₁ a n₂ je ich počet, a, b, g, sú Rocchiove váhy. Ich hodnota sa určuje experimentálne (y je zvyčajne 0). Relevantnosť dokumentov sa určí manuálne, alebo sa použije prvých n dokumentov usporiadaných podľa relevantnosti

- v novej otázke sa nemusia použiť všetky termy z relevantných dokumentov, stačí vybrať najdôležitejšie:

o Harman: , kde tf_{i k} je počet výskytov termu k v dokumente i, f_k je počet výskytov termu k v celej množine dokumentov a N je počet termov v celej množine dokumentov

- automatická lokálna analýza

Expandovanie otázky

Väčšina užívateľov má problémy stanoviť vhodnú otázku, zvlášť v prípade kolekcií dokumentov, o ktorých je im neznámy spôsob jej vytvárania, indexovania, a jazyk používaný pre otázky. Často sa teda obmedzia len na najjednoduchšie otázky obsahujúce minimum informácií. Tento problém zapríčiňuje to, že prvé formulovanie otázky by malo byť považované za prvotné, s tým, že užívateľ ho bude meniť na základe získaných relevantných dokumentov (to sa deje aj v systémoch bez zapracovanej užívateľovej reakcie – user relevance feedback). Na preformulovanie alebo rozšírenie otázky sa dnes využívajú algoritmy založené na:

- relevance feedback

- prehľadaní dokumentov získaných ako odpovede (lokálny prístup)

- globálnych štruktúrach obsahujúcich dodatočné informácie o kolekcii

Užívateľove označenie pre neho relevantných odpovedí (user relevance feedback) je najznámejší algoritmus na expandovanie otázky. Užívateľ si prezerá zoznam získaných dokumentov (odpoveď na otázku) a označí tie, ktoré považuje za relevantné. Systém potom obohatí otázku o termy extrahované z pozitívne označených relevantných dokumentov. Nové termy v otázke by samozrejme mali mať menšiu váhu, než originálne. Ich váha sa može vypočítať napríklad pomocou klasickej Rocchiovej rovnice:

kde R je množina dokumentov označených užívateľom ako relevantné, S je množina označená ako irelevantné dokumenty, q je pôvodná otázka, di sú dokumenty, α, β, γ sú experimentálne konštanty. Zvyčajne sú informácie v relevantných dokumentoch dôležitejšie, než v irelevantných, čiže β je väčšia než γ (γ je často dokonca nulová). Celý proces sa cyklicky opakuje.

Tento algoritmus je možné plne automatizovať – systém označí prvých n získaných dokumentov za relevantné a ďalej sám pokračuje.

Ďalší prístup spočíva vo využití zhlukov. Pre množinu dokumentov vybudujú zhluky obsahujúce vzájomnú koreláciu termov. Potom možno term z otázky expandovať termami patriacimi do toho istého zhluku. Výhodné je tiež vytvárať zhluky obsahujúce nie termy ale ich gramatické korene (stem). Množina dokumentov môže byť celá kolekcia dokumentov (vtedy ide o tzv. globálny prístup) alebo len dokumenty získané ako odpovede na otázku (lokálny prístup). V prípade lokálneho prístupu získame výhodu v expandovaní zameranom na kontext otázky. Korelácia termov v zhlukoch môže byť založená

- na ich vzájomnom výskyte

- na ich vzdialenosti v dokumente

- na ich kontextoch (podobnosti okolitých termov)

Vo všetkých prípadoch sú zhluky uložené v štvorcovej matici S, ktorej rozmer je rovný počtu termov kolekcie dokumentov, nad ktorou sa zhluk vytvára. Prvok matice (sij ) vyjadruje stupeň korelácie termov ti a tj.

V prípade korelácie termov založenej na ich vzájomnom výskyte sa matica S vypočíta nasledovne:

kde fik je počet výskytov termu ti v dokumente dk, D je množina dokumentov, nad ktorou sa vytvára matica S.

V prípade korelácie založenej na vzájomnej vzdialenosti termov sa prvky matice S určia:

kde r(ti, tj) je vzdialenosť termov ti a tj meraná v (minimálnom) počte slov medzi nimi v rámci jedného dokumentu. Ak sa v tom istom dokumente nevyskytujú, tak r(ti,tj) = ∞.

Pri korelácii termov založenej na podobnosti kontextov sa porovnávajú kontexty termov (okolie uzavreté do okna stanovenej dĺžky, prípadne odstavec alebo dokumente). Často sa tiež nepoužívajú všetky termy z okolia, ale len prienik okolia a tzv. indexovacej množiny významných termov. Táto indexovacia množina je určená ručne, na základe frekvencie výskytov v kolekcii, prípadne s využitím gramatických pravidiel. Porovnanie týcho vektorov môže byť vypočítané pomocou štandardnej kosínovej miery.

Ak množina dokumentov D, nad ktorou sa vytvárajú zhluky termov, je celá kolekcia, hovoríme o globálnom prístupe v expandovaní otázky. Ďalší prístup je použiť tezaurus, štruktúru obsahujúcu koncepty, ktoré sú popísané pomocou termov (slov). Koncepty v tezaure sú navzájom viazané reláciami. Najbežnejšie sú hierarchie kategórií (hypernymá a hyponymá), asociácie a ekvivalencie.

XML www.zvon.org

- metajazyk stojaci medzi HTML (príliš jednoduché, pevná množina značiek) a SGML (príliš zložité, orientované na texty)

- vhodný nástroj na výmenu dát medzi informačnými systémami, pre publikovanie dokumentov, uľahčuje správu metadát

- obsahuje elementy (tie majú počiatočný a koncový tag a obsah medzi nimi), elementy môžu obsahovať atribúty

- XML dokument musí byť správne štrukturovaný (well formed) a môže byť založený nejakej schéme (DTD, XML schéma)

<text>This is an

<doctype>XML document</doctype>

</text>

<list>

</list>

<list>

<ITEM>Plane</ITEM>

<Item>Train</Item>

</list>

<text>

</text>

<AAA/>

<CCC/>

<DDD/>

</listOfTags>

<name/>

<xsl:copy-of>

<A_long_element_name/>

<A.name.separated.with.full.stops/>

<a123323123-231-231/>

<_12/>

</permitedNames>

<elements-with-attributes>

<apos_quote case1="John's" case2='He said: "Hello, world!" '/>

</elements-with-attributes>

23 < 46

</isLower>

Willey & sons

</ampersand>

</example>

<right-bracket> both > and > permitted</right-bracket>

<double-quote> both " and " permitted</double-quote>

<apostrophe> both ' and ' permitted</apostrophe>

Useful in: <el value=" ' " ' "/>

</example>

</example>

<?perl lower-to-upper-case ?>

<?web-server add-header = "university" ?>

<text>vscht</text>

</example>

<![CDATA[ <aaa>bb&cc<<< ]]>

</example>

<?xml version="1.0" encoding="ISO-8859-2"?>

<text>If encoding is not given UTF-8 is assumed</text>

DTD

<!ELEMENT XXX (AAA , BBB)>

<!ELEMENT AAA (#PCDATA)>

<!ELEMENT BBB (#PCDATA)>

<!DOCTYPE XXX SYSTEM "2.dtd">

<XXX>

<AAA>Start</AAA>

</XXX>

<!ELEMENT XXX (AAA+ , BBB)>

<!ELEMENT AAA (CCC* , DDD?)>

<!ELEMENT BBB (CCC | DDD)>

<!ELEMENT CCC (#PCDATA)>

<!ELEMENT DDD (#PCDATA)>

<!ELEMENT XXX (AAA+ , BBB+)>

<!ELEMENT AAA (BBB | CCC )>

<!ELEMENT BBB (#PCDATA | CCC )*>

<!ELEMENT CCC (#PCDATA)>

<!ELEMENT attributes (#PCDATA)>

<!ATTLIST attributes

aaa CDATA #REQUIRED

bbb CDATA #IMPLIED>

<!DOCTYPE attributes SYSTEM "8.dtd">

Text

</attributes>

<!ELEMENT XXX (AAA+, BBB+)>

<!ELEMENT AAA (#PCDATA)>

<!ELEMENT BBB (#PCDATA)>

<!ATTLIST AAA

true ( yes | no ) #REQUIRED>

<!ATTLIST BBB

month (1|2|3|4|5|6|7|8|9|10|11|12) #IMPLIED>

<!DOCTYPE XXX SYSTEM "12.dtd">

<XXX>

</XXX>

XSD

<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="product" type="ProductType"/>

<xsd:complexType name="ProductType">

<xsd:sequence>

<xsd:element name="number" type="xsd:integer"/>

<xsd:element name="size" type="SizeType" maxOccurs="1"/>

</xsd:sequence>

<xsd:attribute name="effDate" type="xsd:date"/>

</xsd:complexType>

<xsd:simpleType name="SizeType">

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="2"/>

<xsd:maxInclusive value="18"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

<?xml version="1.0"?>

</product>

DTD

<?xml encoding="UTF-8"?>

<!ELEMENT Data (Code, MENO, PRIEZVISKO, ROK, EMAIL)>

<!ELEMENT Code (#PCDATA)>

<!ELEMENT MENO (#PCDATA)>

<!ELEMENT PRIEZVISKO (#PCDATA)>

<!ELEMENT ROK (#PCDATA)>

<!ELEMENT EMAIL (#PCDATA)>

XSD

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'>

<xs:element name="Data">

<xs:complexType>

<xs:sequence>

<xs:element ref="Code" />

<xs:element ref="MENO" />

<xs:element ref="PRIEZVISKO" />

<xs:element ref="ROK" />

<xs:element ref="EMAIL" />

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Code">

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:minInclusive value="1"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="MENO" type='xs:string'/>

<xs:element name="PRIEZVISKO" type='xs:string'/>

<xs:element name="ROK">

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:maxExclusive value="2050"/>

<xs:minExclusive value="1900"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="EMAIL">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:pattern value="[^@]+@[^.]+\..+"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

</xs:schema>

XSL

<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:output method="xml"/>

<xsl:template match="Data">

<Data>

<CodeX>

<xsl:value-of select="Code"/>

</CodeX>

<menoX>

<xsl:value-of select="MENO"/>

</menoX>

<xsl:value-of select="PRIEZVISKO"/>

</priezviskoX>

<rokX>

<xsl:value-of select="ROK"/>

</rokX>

<xsl:value-of select="EMAIL"/>

</emailX>

</Data>

</xsl:template>

</xsl:stylesheet>

DOM

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

factory.setValidating(validating);

// Create the builder and parse the file

Document doc = factory.newDocumentBuilder().parse(new File(filename));

// This method visits all the nodes in a DOM tree

    public static void visit(Node node, int level) {

        // Process node

        // If there are any children, visit each one

        NodeList list = node.getChildNodes();

        for (int i=0; i<list.getLength(); i++) {

            // Get child node

            Node childNode = list.item(i);

            // Visit child node

            visit(childNode, level+1);

// Get a list of all elements in the document

    NodeList list = doc.getElementsByTagName("*");

    for (int i=0; i<list.getLength(); i++) {

        // Get element

        Element element = (Element)list.item(i);

// Get the root element (without specifying its name)

    String xpath = "/*";                       // 1

    // Get the root element (using its name)

    xpath = "/root";                           // 1

    // Get all elements directly under the root

    xpath = "/root/*";                         // 2 8 12

    // Get all e elements directly under the root

    xpath = "/root/e";                         // 12

    // Get all e elements in the document

    xpath = "//e";                             // 4 6 10 11 12

    // Get all non-e elements in the document

    xpath = "//*[name() != 'e']";              // 1 2 3 5 7 8 9

    // Get all e elements directly under an elem1 element

    xpath = "//elem1/e";                       // 10 11

    // Get all e elements anywhere under an elem1 element

    xpath = "//elem1//e";                      // 4 6 10 11

    // Get all elements with at least one child element

    xpath = "//*[*]";                          // 1 2 3 5 8

    // Get all elements without a child element

    xpath = "//*[not(*)]";                     // 4 6 7 9 10 11 12

    // Get all elements with at least one child e element

    xpath = "//*[e]";                          // 1 3 5 8

    // Get all elements with more than one child e elements

    xpath = "//*[count(e)>1]";                 // 8

    // Get all non-e elements without an e child element

    xpath = "//*[not(e) and name() != 'e']";   // 2 7 9

    // Get all level-4 e elements (the root being at level 1)

    xpath = "/*/*/*/e";                        // 4

    // Get all elements with more than one child e elements

    xpath = "//*[count(e)>1]";                 // 8

SAX

public class BasicSax {

        public static void main(String[] args) {

            // Create a handler to handle the SAX events generated during parsing

            DefaultHandler handler = new MyHandler();

            // Parse the file using the handler

            parseXmlFile("infilename.xml", handler, false);

        // DefaultHandler contain no-op implementations for all SAX events.

        // This class should override methods to capture the events of interest.

        static class MyHandler extends DefaultHandler {

        // Parses an XML file using a SAX parser.

        // If validating is true, the contents is validated against the DTD

        // specified in the file.

        public static void parseXmlFile(String filename, DefaultHandler handler, boolean validating) {

            try {

                // Create a builder factory

                SAXParserFactory factory = SAXParserFactory.newInstance();

                factory.setValidating(validating);

                // Create the builder and parse the file

                factory.newSAXParser().parse(new File(filename), handler);

            } catch (SAXException e) {

                // A parsing error occurred; the xml input is not valid

            } catch (ParserConfigurationException e) {

            } catch (IOException e) {

// This class listens for startElement SAX events

    static class MyHandler extends DefaultHandler {

        // This method is called when an element is encountered

        public void startElement(String namespaceURI, String localName,

                                 String qName, Attributes atts)  {

            // Get the number of attribute

            int length = atts.getLength();

            // Process each attribute

            for (int i=0; i<length; i++) {

                // Get names and values for each attribute

                String name = atts.getQName(i);

                String value = atts.getValue(i);

                // The following methods are valid only if the parser is namespace-aware

                // The uri of the attribute's namespace

                String nsUri = atts.getURI(i);

                // This is the name without the prefix

                String lName = atts.getLocalName(i);

Data warehouses

– OLTP (on-line transaction processing)

– tradičný spôsob využívania databáz

– krátke transakcie (read/update málo záznamov)

– DSS (decision support systems)

– pomáhajú manažérom a analytikom lepšie a rýchlejšie rozhodovať

o aká bola veľkosť predaja podľa regiónov a produktu posledný rok ?

o spôsobí 10% zľava dostatočné zýšenie predaja ?

– OLAP (on-line analytical processing) je časťou DSS

OTTP vs OLAP

	OLTP	OLAP
Užívateľ	Úradník	Manažér
Funkcia	Každodenné operácie	Podpora rozhodovania
Prístup	Read/write	Zväčša read
Dáta	Detailné, relačné	Zhrnutia, historické, multidimensionálne
Veľkosť	100MB – 1GB	100GB – 1 TB

Data warehouse

– Databáza na podporu rozhodovania, ktorá je udržovaná oddelene od bežnej operačnej databázy organizácie

– Prečo budovať data warehouse ?

o obsahuje dáta z celej organizácie v jednej zjednodušenej schéme (dáta sú zvyčajne rozložené vo viacerých aplikáciách, databázach)

o zvýšenie výkonnosti OLAP, zníženie záťaže OLTP databázy

o dostupnosť je zvýšená

o často je to jediný spôsob, ako požadovať dáta z rôznych zdrojov

o čistenie dát ( DW často musí filtrovať dáta)

– architektúra:

o warehouse database server (klasická relačná databáza) - OLAP server (ROLAP, MOLAP)

o data marts

o klienti – nástroje na dotazovanie a reporting, analytické nástroje, data mining

– vybudovanie:

o zhora nadol (pomalé, riziko nedokončenia, avšak získa sa konzistentná schéma)

o zdola nahor, po jednotlivých „data marts“ (rýchle, avšak risk nekonzistentnej globálnej schémy)

– pozadie (back end):

o obnovenie: extrakcia, transformovanie a nakopírovanie dát (ETL)

§ zasielanie zmien zo zdrojových data marts do warehouse

§ kedy a ako obnovovať

§ extrahovanie

· všetkých dát

· inkrementálne

§ transformovanie

· konflikty v schéme

· konflikty pri hodnotách (napr. rovnaké hodnoty pre kľúčové atribúty rôznych objektov)

· čistenie dát (odstraňovanie duplicít, neúplností, spresňovanie)

§ nakopírovanie (loading)

· cez pumpu prechádza veľké množstvo dát počas malého časového intervalu

· využíva sa nie SQL (kvôli pomalému náhodnému prístupu) ale dávkové (batch) spracovanie, ktoré využíva sekvenčné I/O operácie

– popredie (front end)

o OLAP

§ hodnota (miera)

§ rozmer (dimenzia)

o OLAP analýza

§ agregácie

§ porovnania

§ triedenie

§ komplexné kritéria

§ vizualizácia

o atribúty (mesiac, produkt, región)

o hierarchie atribútov (druh priemyslu – kategória – produkt, krajina – región – mesto – obchod)

o z atribútov vznikne viacdimenzionálna kocka, ktorá, s ktorou sa konajú operácie:

§ roll up (sumarizovanie)

§ drill down (ísť z vyššej úrovne na nižšiu)

§ slice and dice (select and project)

§ pivot (preorientovanie kocky)

– databázové servery

o ROLAP (relational OLAP)

o MOLAP (multidimensional OLAP)

o ROLAP schémy

§ star (hviezda) – jedna centrálna tabuľka faktov a niekoľko denormalizovaných tabuliek dimenzií

§ snowflake (vločka) – normalizovaná verzia star schémy, ľahšie sa udržuje, pomalšie sa dotazuje

§ agregované tabuľky (obsahujú dopredu vypočítané agregácie, ktoré sú uložené buď v oddelenej tabuľke, alebo priamo v dátovej tabuľke ako ďalší stĺpec)

o dimensionálne modelovanie

§ jedna tabuľka faktov, na ňu sú napojené tabuľky dimenzií pomocou cudzích kľúčov

§ tabuľka faktov nemusí obsahovať reálne hodnoty, iba cudzie kľúče

o MOLAP

§ úložným modelom je n-rozmerné pole

§ veľmi rýchle vo výpočtoch a OLAP operáciách

§ vyžaduje vopred vypočítať kocku, často je nutné komprimovanie

§ v súčasnosti tento model používa 98% OLAP serverov

o indexovacie techniky

§ nutné kvôli častému využívaniu join operácií, veľkým tabuľkám a komplexným otázkam

§ bitmapové indexy

· výhodné pre domény s nízkou kardinalitou

· riadok v tabuľke sa reprezentuje bitovým vektorom

· pre každú hodnotu h v doméne existuje rozlišovací bitový vektor B_h veľkosti rovnej kardinalite domény

· j-ty bit v rozlišovacom vektori B_h je nastavený práve vtedy, ak riadok tabuľky obsahuje j-tu hodnotu domény (h je j-tou hodnotou v doméne)

Zákazník	Región	Zákazník	Sever	Juh	Východ	Západ
Z1	Sever	Z1	1	0	0	0
Z2	Juh	Z2	0	1	0	0
Z3	Sever	Z3	1	0	0	0
Z4	Východ	Z4	0	0	1	0
Z5	Západ	Z5	0	0	0	1
Z6	Juh	Z6	0	1	0	0

· v príklade miesto 5B na stĺpec región potrebujeme len 4b pri použití bitmapových vektorov

· veľmi sa zrýchli aj porovnávanie, join operácie a agregácie, keďže to všetko bude redukované na bitové operácie

· v prípade domén s vysokou kardinalitou sa zníži výkonnosť

§ pripojené (join) indexy

· sú to tradičné indexy, ktoré mapujú hodnotu v stĺpci na zoznam riadkov s touto hodnotou

· toto zobrazenie sa potom využíva pri porovnávaniach, join operáciách a agregáciách

Organizačné informácie:

- Za cvičenie sa dá získať 30 bodov

- Za dve písomky (prvá je 18.10.2002, druhá je 13.12.2002) je dohromady 20 bodov

- Tí, ktorí za prvú písomku získali menej než 7 bodov, budú na skúške skúšaní z toho, čo mali zle a až keď to budú vedieť, potom budú môcť robiť zvyšok skúšky (keďže v 1. písomke bolo vlastne jadro 1. semestra)

- Zvyšok (50 bodov) je možné získať na ústnej skúške

- Známka za skúšku sa vypočíta nasledovne:

o A : 95 bodov a viac

o B : 90 bodov a viac

o C : 85 bodov a viac

o D : 80 bodov a viac

o E : 75 bodov a viac

- Známka za cvičenie sa vypočíta nasledovne:

o A : 27 bodov a viac

o B : 24 bodov a viac

o C : 21 bodov a viac

o D : 18 bodov a viac

o E : 15 bodov a viac

- Body za cvičenie je možné získať len do 14. týždňa, t.j. do 10.1.2002 vrátane

- Tento zimný semester je možné pokračovať len so získaným zápočtom za letný semester

- Predbežné termíny pre skúšku: 10.1, 24.1, 7.2 (všetko piatky, minimálny počet 5, maximálny 20, miestnosť sa ešte určí)

Ukážka 1.písomky (90 min) :

Žiaci navštevujú gymnázium (trvá 4, prípadne 8 rokov, vďaka legislatívnym zmenám sa to však môže meniť). Sú organizovaní do tried. Na gymnáziu sú učitelia, ktorí dávajú žiakom za predmety známky. To, aké má žiak predmety, je dané ročníkom, ktorý navštevuje. Známky za predmet sú priebežné a navyše dve špeciálne – polročná a koncoročná. Každá trieda má svojho triedneho učiteľa.

Nakreslite diagram tried, entitno-relačný diagram s cudzími kľúčmi a na ukážku aj databázové tabuľky s cudzími kľúčmi a ostatnými atribútmi obsahujúce niekoľko riadkov s konkrétnymi hodnotami

2. Digitálne hodinky ukazujú na displeji hodiny a minúty. Majú ešte dve tlačidlá na zmenu času – A a B. Hodinky môžu byť v dvoch režimoch – zobrazovať čas a nastavovať čas. Počas zobrazovania času sa ukazujú hodiny a minúty, ktoré sa menia štandardným spôsobom ( po jednej minúte sa zvýši číslo označujúce minúty na hodinkách, ak bude rovné 60, tak sa vynuluje a zvýši sa číslo označujúce hodiny ). Nastavovanie času má dva podrežimy – nastavovanie hodín a nastavovanie minút. Tlačidlo A slúži na zmenu režimu, po jeho stlačení sa postupne dostávame do režimu zobrazuj čas, nastav hodiny, nastav minúty, zobrazuj čas ... Tlačidlo B slúži na zvýšenie hodín alebo minút v režimoch na nastavenie času štandardným spôsobom ( ak je číslo označujúce minúty rovné 60, tak sa vynuluje, analogicky pre hodiny ). V prípade, že počas nastavovacích režimov stlačíme tlačidlo B a podržíme ho viac než 5 sekúnd, začnú sa zvyšovať hodiny alebo minúty raz za štvrť sekundy ( kým držíme tlačidlo ).

Načrtnite stavový diagram

3. Use case: Predaj lístka a miestenky pre prepravu vlakom

Hlavný scenár:

1. Cestujúci pristúpi ku pokladni na železničnej stanici

2. Požiada o lístok a miestenku na cestu z mesta A do B, udá dátum a hodinu štartu

3. Pracovník skontroluje spojenie, zistí, či sú voľné miestenky. Bod 2. a 3. sa opakuje pre všetky lístky a miestenky, ktoré chce cetujúci zakúpiť

4. Pracovník pri prepážke mu predá lístky a miestenky, zaznamená predaj i rezervácie do systému

5. Cestujúci odíde

Alternatívne scenáre:

3a) Spojenie ( v daný deň, či hodinu ) nepremáva

1. Ponuka alternatívneho spojenia

3b) Nie sú voľné miestenky

1. Predaj iba lístka bez miestenky

4a) Zlacnená platba ( na základe napr. študentského alebo dôchodcovského preukazu )

1. Kontrola preukazu

Načrtnite systémový sekvenčný diagram ( SSD ) a diagram činností s rolami aktorov ( activity diagram )

4. Máme nasledovnú sieť počítačov, zariadení a bežiacich procesov:

a) jeden počítač-server, na ktorom beží databázový server a zálohovací proces ( ten zálohuje dáta cez sieť na iný záložný počítač )

b) dva počítače, na ktorých bežia dva aplikačné servery ( tie pristupujú na databázový server pomocou siete)

c) dva počítače, na ktorých sú klientske aplikácie, ktoré pristupujú cez sieť na prvý aplikačný server

d) jeden počítač, na ktorom je klientska aplikácia, ktorá pristupuje na druhý aplikačný server ( pomocou modemu - zariadenie )

e) na druhom aplikačnom serveri je ešte modemová centrála ( zariadenie )

Načrtnite diagram nasadenia

class A {

public static void main(String[] s){

B b = new B();

C c = new C();

int p,q,i=0;

int x = Integer.parseInt(args[0]);

if (x>0) b.op1( p );

else b.op3( q );

while( i<10) {

c.op1(); i++;

}

public static void op2() {

}

class B {

public void op1(int x) {

A.op2();

}

public void op3(int x) {

A.op2();

}

class C {

public void op1(int x) {

A.op2();

}

Metódu main v triede A spúšťa aktor JVM ( Java virtual machine ). Načrtnite sekvenčný diagram a diagram spolupráce.

Ukážka 2.písomky (90 min) :

Spolok chovateľov zvierat eviduje svoje zvieratá a ľudí, ktorí patria do spolku. Zvieratá majú číslo, dátum narodenia, sú nejakého druhu, majú nejakú váhu. Eviduje sa, ktoré choroby ich môžu napadnúť (napr. kravy môže napadnúť BSE) a ktoré choroby kedy napadli konkrétneho jedinca (napr. krava číslo 6 bola napadnutá slintačkou roku 1999 a krívačkou roku 2000). Zvieratá môžu(nemusia) byť zhlukované do skupín. Ľudia majú povinnosti starať sa o jednotlivé kusy alebo skupiny zvierat a eviduje sa, ako si túto povinnosť plnia (napr. dňa 1.1.2000 dal ošetrovateľ skupine rybiek krmivo, o deň nato im vymenil vodu, orangutanovi č. 5 dal injekciu).

Diagram tried/entitno relačný diagram + DDL script

Evidencia kúpy. Spolok nakupuje zvieratá i krmivo. Objednávky môžu byť trvalé (s dátumom platnosti do a intervalom opakovania) a jednorázové. Objednávka sa skladá z položiek, ktoré obsahujú info o type tovaru a jeho množstvo, ďalej obsahuje meno dodávateľa. Tovar obsahuje názov a cenu. Objednávky spláca spolok jedným hromadným platobným príkazom mesačne z jedného účtu. Hromadný platobný príkaz sa skladá z jednotlivých príkazov. V každom príkaze je uvedené, na aký účet idú peniaze, koľko ich ide a identifikátor objednávky, ktorá sa ním spláca.
Majme tri dokumenty:

Líška naháňa bieleho zajaca. Chytila ho v poli.
Líška hrdzavá žije v lese a na lúkach.
Zajac sa živí trávou.

Otázka: Zajac obyčajný.

Vypočítajte relevancie dokumentov ku otázke podľa vektorového modelu. Používajte základné gramatické tvary slov.

Vytvorte triedu Triedenie v Jave, ktorá bude mať metódu triedenie. V nej bude vedieť triedit pole akýchkoľvek inštancií iných tried, ktoré budú mať definovanú metódu na porovnanie. Metódu triedenie popíšte len schematicky, ukážte v nej najmä, ako sa tam bude volať metóda na porovnanie. Vytvorte diagram tried, kde bude táto trieda Triedenie, nejaké iné ukážkové triedy, ktoré bude vedieť Triedenie triediť a element, ktorý bude potrebný na to, aby to celé fungovalo.
Napíšte DTD a XML schému ku nasledovnému XML dokumentu

(mesto v sídlisku je pre DTD nepovinné, ine atribúty sú povinné)

<?xml version="1.0" encoding="ISO-8859-2"?>

<najomnik> Jan Novak </najomnik>

<najomnik> Peter Novak </najomnik>

</dom>

<najomnik> Jan Novak </najomnik>

</dom>

</sidlisko>