multimediálna podpora predmetu architektúra...

Slovenská technická univerzita v Bratislave

Fakulta elektrotechniky a informatiky

Študijný odbor Informatika

Tímový projekt

Multimediálnapodpora predmetuArchitektúra počítačovDokumentácia k inžinierskemu dieluAnalýza, špecifikácia požiadaviek, hrubý návrh, prototypovanie,podrobný návrh, implementácia, testovanie a záver

Tím č. 9Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel MésárošVedúci tímového projektu: Ing. Ján Hudecletný semester šk. r. 2003/200410. 5. 2004

KINEDRYLS T A Y C O O L

Obsah0 Úvod 5

0.1 Zadanie projektu 50.2 Skratky 60.3 Slovník pojmov z problémovej oblasti 6

1 Opis problematiky 71.1 Výučba predmetov 7

1.1.1 Predmet Architektúra počítačov 71.1.2 Výučba predmetu Architektúra počítačov 71.1.3 Ciele projektu 8

1.2 Elektronické štúdium alebo „e-learning“ 91.2.1 E-learning a školstvo 101.2.2 Spôsoby využitia e-learningu 101.2.3 Rozdelenie pod�a spôsobu komunikácie 111.2.4 Hybridný spôsob výučby 121.2.5 Použitie multimediálnych technológií v e-learningu 12

1.3 Prostredia pre tvorbu prezentácií na Internete 131.3.1 PowerPoint 2000 141.3.2 Multimedia Builder 4.9 151.3.3 Illuminatus 15

1.4 Analýza podobných prezentácií 161.4.1 Cisco Network Academy Program 161.4.2 Kurz signalizácie v ISDN 18

2 Špecifikácia a analýza požiadaviek 192.1 Katalóg požiadaviek 192.2 Scenáre použitia 31

2.2.1 Vloženie textovej komponenty na obrazovku prezentácie 31

2.2.2 Vloženie novej obrazovky prezentácie 312.2.3 Export prezentácie do HTML 31

2.3 Analýza formátovania prezentácie 322.3.1 Obsah prezentácie 322.3.2 Používate�ské rozhranie 342.3.3 Záver 34

2.4 Interview s Ing. J. Hudecom 353 Hrubý návrh 37

3.1 Základné vlastnosti editora prezentácii 373.1.1 Vzh�ad aplikácie 373.1.2 Štruktúra prezentácie 373.1.3 Komponenty a práca s nimi 373.1.4 Výstup prezentácie 39

3.2 Roly používate�ov 393.2.1 Tvorca prezentácie 393.2.2 Študent prezentácie 39

3.3 Návrh aplikácie pre tvorbu prezentácie 403.3.1 Koncepcia návrhu softvérového systému 40

Tímový projekt | Dokumentácia k inžinierskemu dielu i

3.3.2 Komunikácia používate�ov so systémom 413.3.3 Koncepcia návrhu z implementačného h�adiska 43

3.4 Návrh prezentácie 443.5 Model funkcií 45

3.5.1 Externé entity 453.5.2 Úložiská údajov 453.5.3 Procesy 46

3.6 Logický model údajov 493.6.1 Diagram modelu údajov 493.6.2 Údajové entity 50

3.7 Návrh šablón 513.7.1 Aktuálny zoznam elementov 52

4 Prototypovanie 544.1 Ciele prototypovania 544.2 Vyhodnotenie prototypovania (systém) 55

4.2.1 Prostredie pre tvorbu prezentácii 554.2.2 Tvorba výstupnej prezentácie 55

4.3 Vyhodnotenie prototypovania (prezentácia) 565 Podrobný návrh 57

5.1 Editor prezentácie 575.2 Konverzná utilita 58

5.2.1 Vnútorná štruktúra konverznej utility 595.2.2 Rozhranie konverznej utility 60

5.3 Návrh konverznej utility do formátu HTML 615.3.1 Nastavenie konverznej utility 615.3.2 Konvertovanie projektu prezentácie 625.3.3 Zobrazenie prezentácie 64

5.4 Formátovanie prezentácie 645.4.1 Titulný pruh 645.4.2 Navigačný pruh 645.4.3 Pruh s pobsahom 65

6 Implementácia 666.1 Editor prezentácie 66

6.1.1 Zre�azená vo�ná pamä� 666.1.2 Dedené dátové štruktúry 666.1.3 Štruktúra prezentácie 666.1.4 Pamä� komponentov 66

6.2 Rozhranie konverznej utility 666.3 Konvertovanie projektu prezentácie do formátu HTML 67

6.3.1 Tvorenie CSS šablón 686.3.2 Tvorenie používate�ského prostredia prezentácie 686.3.3 Tvorenie používate�ských obrazoviek 696.3.4 Kopírovanie zdrojov 696.3.5 Stav konvertovania prezentácie 69

6.4 Formátovanie prezentácie 706.4.1 Organizácia súborov 706.4.2 Používate�ské rozhranie 706.4.3 Látka prezentácie 72

Tímový projekt | Dokumentácia k inžinierskemu dielu ii

7 Testovanie 737.1 Alfa testovanie 737.2 Beta testovanie 79

8 Záver 81

Použité názvy spoločností a produktov môžu by� registrovanými obchodnýmiznámkami alebo obchodnými značkami príslušných vlastníkov.

Tímový projekt | Dokumentácia k inžinierskemu dielu iii

0 ÚvodTento dokument vznikol na základe zadania projektu pre predmetTímový projekt, ktorý sa vyučuje v prvom ročníku inžinierskeho štúdia naFakulte informatiky a informačných technológií Slovenskej technickej univerzityv Bratislave.

0.1 Zadanie projektu

Zadanie projektu je nasledovné:

Multimediálna podpora predmetu Architektúra počítačov

Predmet Architektúra počítačov je jedným zo základných predmetov v prvomroku bakalárskeho štúdia konaného prezenčnou vzdelávacou metódou.V bakalárskom štúdiu konanom dištančnou vzdelávacou metódou sa tentopredmet vyučuje pod názvom Informatika 1. Štandardné učebné pomôckyvytvárané pre tento predmet (učebnice, skriptá, a pod.) sa vyznačujú tým,že ich obsahová náplň podlieha rýchlemu zastarávaniu, k čomu prispieva aj časpotrebný na ich výrobu. Na jednej strane je nevyhnutné neustále aktualizova�obsah predmetu o najnovšie poznatky, na druhej strane, aj ke� ve�ká čas�poznatkov z oblasti architektúry počítačov sa nemení, najmä preto, že časovýpriestor pre predmet je vymedzený, je potrebné postupne prehodnocova� ichdôležitos� a najmä ich rozsah, a intenzívne ich aj zovšeobecňova�.

Využitie multimediálnych technológií pri tvorbe učebných pomôcokmôže významným spôsobom zlepši� ich obsahovú aktuálnos� a cenovúdostupnos�, a čo je najpodstatnejšie, zredukujú sa časové nároky na ichinováciu a výrobu. Vzh�adom na stanovenú rámcovú obsahovú náplň predmetuje možné kedyko�vek vymeni� náplň (texty, obrázky, fotografie, animácie,videosekvencie, akustické efekty a pod.) jednotlivých častí, upravi� ich rozsah a takvytvára� učebnú pomôcku, ktorá bude zodpoveda� aktuálnemu stavu poznania voblasti architektúry počítačov.

Cie�om projektu je podpora uvedených činností. V rámci riešenia bude potrebné: – navrhnú� a realizova� produkt, ktorý multimediálnymi prostriedkami

umožní vytvori� rámce zodpovedajúce požadovaným kapitolám predmetuArchitektúra počítačov

– navrhnú� a realizova� náplň jednotlivých častí – produkt implementova� ako hypermediálnu prezentáciu s kapacitnými

nárokmi na jedno CD-ROM médium a vo�ne dostupný prehliadač.

Odporúčaná vzorová literatúra: 1. Krajčovič, T.: Počítače. Vydavate�stvo STU, Bratislava 2000. 2. Jelšina, M.: Architektúry počítačových systémov.

Vydavate�stvo ELFA, s.r.o., Košice 2002.

Vedúci tímu: Ing. J. Hudec

Tímový projekt | Dokumentácia k inžinierskemu dielu 5

0.2 Skratky

CSS2Cascading Style Sheets version 2

HTMLHypertext Markup Language

HWhardvér

LMSLearning Management Systems

SWsoftvér

WWWWorld Wide Web

zad.zadávate� Tímového projektu

0.3 Slovník pojmov z problémovej oblasti

Obrazovka – jeden súvislý HTML dokument.

Komponenta – elementárny prvok (text, obrázok, hypertextová linka, …)

s pomocou ktorej je možné posklada� obsah obrazovky.Návrhový systém

– prostredie pre vytváranie multimediálnych prezentácií.Tvorca prezentácie

– učite� alebo iná osoba, ktorá bude tvori� prezentáciu.Študent prezentácie

– študent (resp. osoba), ktorá používa vytvorenú prezentáciu.Zadávate�

– zadávate� Tímového projektu.


1 Opis problematikyCie�om tejto kapitoly je oboznámi� čitate�a s problematikou dištančnéhovzdelávania elektronickou formou, ozrejmenie pojmov z tejto oblasti, ako ajrozčlenenie rôznych druhov a typov elektronických prezentácií. Budeme sazaobera� technológiami používanými v týchto prezentáciách a naznačíme, akýmsmerom sa vydá náš projekt. Nako�ko celý projekt má by� realizovaný akomultimediálna podpora predmetu Architektúra počítačov, bude úlohou tejtokapitoly predstavi� aj tento predmet.

1.1 Výučba predmetov

Ak sa chceme pozrie� na komplexný problém výučby predmetov, je potrebnéurobi� isté predpoklady. V našom prípade sa budeme zaobera� predovšetkýmvýučbou predmetov na Fakulte informatiky a informačných technológiíštandardnou formou denným štúdiom, nako�ko táto fakulta (ako aj jej materskáFakulta elektrotechniky a informatiky) externú formu štúdia nepodporuje. Našouúlohou však je hlbšie sa pozrie� aj na iné formy štúdia a navzájom ich porovna�.Takýto náh�ad nám poslúži pri h�adaní výhod a perspektív, ktoré poskytujeelektronická forma vzdelávania. Prv však než sa doňho pustíme, priblížme sisamotný predmet Architektúra počítačov.

1.1.1 Predmet Architektúra počítačov

V tomto článku by sme radi dali čitate�ovi stručnú informáciu o obsahupredmetu Architektúra počítačov. Cie�om predmetu Architektúra počítačov, ktorýsa vyučuje v druhom semestri bakalárskeho štúdia, je poskytnú� študentomvšetkých študijných odborov základné informácie o technických prostriedkochčíslicových počítačov a počítačových systémov. V anotácii predmetu sa hovorí :

Predmet poskytuje preh�ad o koncepcii číslicového počítača, zobrazeníinformácie v počítači, základoch číslicových obvodov a koncepcii procesora,inštrukčnom súbore, hierarchickom usporiadaní pamäti, vstupno-výstupnýchprenosoch a zariadeniach, osobných počítačoch a počítačových sie�ach.

Predmet prednášajú Doc. Ing. Tibor Krajčovič, PhD., Ing. KatarínaJelemenská, PhD. a Ing. Ján Hudec

1.1.2 Výučba predmetu Architektúra počítačov

Fakulta informatiky a informačných technológií Slovenskej technickej univerzityv Bratislave garantuje výučbu predmetu Architektúra počítačov iba v dennejforme štúdia. Takáto forma je bežná pre výučbu predmetov na tejto fakultea má na Slovensku dlhodobé tradície. Predmetu je vyhradený pevný početprednášok a cvičení za semester, pričom každá prednáška a cvičenie má pevnestanovenú dobu výučby v rámci jedného študijného týždňa. Pre predmetArchitektúra počítačov je to štandardne dvanás� trojhodinových prednášoka dvanás� cvičení trvajúci jednu hodinu za semester. Vo všeobecnosti platí, žeúčas� na prednáškach nie je povinná, ale naopak účas� na cvičeniach je jednou


z podmienok udelenia zápočtu. Ako vidí takúto formu vzdelávania študent?Túto otázku môžeme jednoducho a kvalifikovane zodpoveda�, nako�ko každýz členov tímu tento predmet absolvoval (aj ke� pod iným názvom) a s toutoformou štúdia má skúsenosti.

Prednášky, nako�ko účas� na nich nie je povinná, sú navštevované asi lenpolovicou študentov, ktorí si predmet zapísali. Prečo? Nie je to spôsobené ibanezáujmom o predmet, aj ke� treba prizna�, že sú študenti, ktorých tento predmetpramálo zaujíma a majú ho zapísaný len preto, že je povinný. Spomenutá účas�(možno by bolo lepšie slovo neúčas�) je spôsobená vo ve�kej miere aj inýmipovinnos�ami študentov, či už sú to povinnosti študijné alebo pracovné.Zo strany cvičení, je situácia iná. Účas�, nako�ko je to podmienka zápočtu, jetakmer stopercentná a teda študenti sú nútení prís� na cvičenie v presnestanovenú dobu. Toto je bežná forma vzdelávania a ako taká zrejme najviacvyhovuje študentom, ktorí si vyhradili nieko�ko rokov na štúdium vysokej školy.Existuje však aj skupina študentov, ktorým by viac vyhovovala externá formaštúdia, pri ktorej by boli nútení navštevova� fakultu v minimálnej mierea vzdeláva� sa predovšetkým samoštúdiom vo svojom vo�nom čase. Samotnávysoká škola by potom iba vykonávala preskúšanie zvládnutia danej problematiky.Je treba pripomenú�, že Fakulta informatiky a informačných technológiív súčasnej dobe externé štúdium nepodporuje, a preto nie sú skúsenosti s toutoformou štúdia predmetu Architektúra počítačov. Bez oh�adu nato, projekt,ktorý riešime, si kladie za cie� vytvori� takýto systém multimediálnej podpory,ktorý by mohol by� plne použite�ný aj pre túto formu štúdia.

V problematike podpory štúdia predmetu Architektúra počítačov sú ajiné aspekty, ktoré by náš projekt vedel efektívne rieši�. Náplňou predmetu súpredovšetkým informačné technológie a všetko s nimi spojené. Nepoviem žiadnunovinku ak tvrdím, že táto oblas� vedy sa vyvíja závratným tempom. Preto jenutné, v záujme udržania aktuality informácií poskytovaných v predmete, neustáleobnovova� obsah skrípt a iných študijných materiálov. Rýchlej a jednoduchejaktualizácii týchto materiálov však bránia vysoké finančné náklady a časovánáročnos�. A práve tu sa črtá možnos� využita informačných technológií.Na to, akým spôsobom, by mal odpoveda� tento projekt.

1.1.3 Ciele projektu

Aké sú ciele, ktoré si kladieme a aké máme plány s projektom? Predovšetkýmmusíme nájs� miesto, kde sa v rámci výučby predmetu Architektúra počítačovnáš projekt uplatní. Externá forma štúdia je práve to pole pôsobnosti, na ktoromby sa mohol realizova� práve náš projekt. Informačné technológie sa v súčasnejdobe rozvíjajú závratným tempom a bolo by škoda nevyuži� ich v maximálnejmožnej miere. Jedným možným využitím by bola predstava, že študent bykomunikoval so svojim učite�om cez internet a tak isto by získaval študijnémateriály. Takto by sa dosiahla požiadavka externého študenta na minimálnunávštevnos� školy a štúdium vo svojom vo�nom čase. To je jeden smer, ktorýmby sme sa mohli vybra�. Iná možnos� je, aby samotné študijné materiály boliv elektronickej forme s maximálnou multimediálnou podporou. To by do značnejmiery vyriešilo problém s aktualizáciou informácií, ktoré sa v rámci predmetupreberajú.


Aby sme správne určili smer, ktorým sa pri realizácii vybra�, je potrebné,aby sme si dobre rozobrali požiadavky zo zadania. Autori zadania argumentujúrýchlym zastarávaním informácií podávaných v predmete ako aj vysokýminákladmi na výrobu študijných materiálov. Aký produkt je teda potrebné vytvori�?V prvom rade musí ís� o systém, ktorý bude umožňova� uchováva� a prezentova�informácie v elektronickej forme. Týmto sa odstráni nutnos� tlačenia skrípt,čo stojí čas a peniaze. Bude potrebné vytvori� systém, ktorý umožní jednoduché,ale efektívne narábanie so samotnými informáciami, aby mal pedagóg možnos�rýchlo vytvori� svoju prezentáciu, inovova� údaje, niektoré zastaranejšie údajevymaza� a opätovne ich distribuova� ku študentovi. V dnešnej dobe sa vyvíjajúrôzne možnosti ako podpori� názornos� prednášanej tematiky a toto je oblas�,ktorú môže náš systém plne využi�. A v neposlednom rade je potrebné,aby systém čo najmenej obmedzoval používate�a z poh�adu požadovanejtechnickej výbavy.

Ke� zhrnieme tento náh�ad na budúci systém, vybavuje sa nám riešenie,ktoré by všetky tieto požiadavky riešilo z dvoch poh�adov. Jedným by bol poh�adpedagóga resp. tvorcu prezentácie a druhým poh�adom by bol poh�ad študentaprezentácie, teda toho, čo daný predmet študuje. Pre pedagóga by systémposkytoval výkonný nástroj na tvorbu prezentácie podporovanú najmodernejšímimultimediálnymi prostriedkami a pre študenta samotnú prezentáciu, pomocouktorej by si mohol doma na počítači študova� látku daného predmetu.V neposlednej rade by sme radi spomenuli, že nie je zanedbate�nou myšlienkourealizova� systém nezávisle na type prezentácie. To znamená, že by ho bolo možnépouži� aj na iné predmety ako predmet Architektúra počítačov. V každom prípadebude našou prioritou vytvori� systém, ktorý bude v maximálnej miere spĺňa�požiadavky naň kladené, ktorý bude (aspoň sčasti) naplnený údajmi z obsahupredmetu Architektúra počítačov a ktorý bude na konci letného semestra plnepoužite�ný pre nasadenie.

1.2 Elektronické štúdium alebo „e−learning“

E-learning predstavuje širokú oblas� získavania vedomostí vo vyučovacom proceseprostredníctvom moderných informačných a telekomunikačných technológií. Jejedným z prúdov tzv. e-odvetví, ktoré sa čoraz častejšie skloňujú s transformáciouspoločnosti na tzv. „informačnú spoločnos�“. Oblas� elektronického vzdelávaniaje pomerne rozsiahla, pričom pokrýva tvorbu a distribúciu interaktívnychelektronických kurzov (e-learningové kurzy), riadenie vyučovania a s ňou súvisiacuspätnú väzbu – to všetko za využitia moderných technológií. E-learningové kurzymôžu pozostáva� z multimediálnych prezentácií, simulácií, kombinácie animácií,videa, zvuku a textového výkladu a v neposlednom rade z testov pre overovanieznalostí študujúceho. Aby však bola zabezpečená spätná väzba medzi študujúcima lektorom, aby bolo vzdelávanie riadené a usmerňované a bolo ho možné presnevyhodnocova�, existujú systémy pre riadenie vyučovania, tzv. LearningManagement Systems (LMS). Okrem týchto základných vlastností zabezpečujúLMS systémy aj mnohé funkcie on-line štúdia (chat, videokonferencie, zdie�anieaplikácií, virtuálne učebne a pod.).


V�aka e-learningu je možné rieši� niektoré špecifické problémy, ktoréúzko súvisia so vzdelávaním dospelých. V dnešnej uponáh�anej dobe plnejneustálych zmien v živote každého z nás hrá obrovskú úlohu čas. Čas je fenomén,ktorého má bohužia� takmer každý z nás čoraz menej, o čase na naše vzdelávanieani nehovoriac. A práve množstvo problémov vo vzdelávaní dospelých s nímsúvisí. E-learning sa tu môže uplatni� ako ve�mi užitočný a výkonný nástroj nazvyšovanie znalostí, schopností a kvalifikácie ako jednotlivcov, tak aj personálumoderných spoločností. V dnešnej dobe je prínos elektronického vzdelávanianesporný.

1.2.1 E−learning a školstvo

Klasické vzdelávanie, pod vedením učite�a, existuje už od počiatku histórie.Vzdelávanie pod vedením lektora je najčastejšou a najrozšírenejšou formouvzdelávania vo svete aj u nás. Učite� dokáže študentovi poradi�, správne honasmerova� a v neposlednom rade ohodnoti� jeho úspechy. V každom z nás sacelý život ukrývajú spomienky na učite�a, ktorý v nás niečo zanechal. Sú toučitelia, ktorí formujú naše životy a práve školstvo výraznou mierou určujespoločnos�. Klasické a osvedčené postupy vzdelávania sa využívajú aj dnes. Žijemevšak v dobe zmien, dobe nových myšlienok, nápadov, ale aj úloh. Jednouz nových a moderných foriem vzdelávania, ktoré sa už dlhšie presadzuje vovyspelých krajinách, ale aj u nás, je e-learning. E-learning prináša do škôl novýimpulz a nové možnosti.

Kombináciou klasického vzdelávania a e-learningu je možné dosiahnu�formu, v ktorej sa spájajú skúsenosti učite�a – lektora a výhody výpočtovejtechniky a multimédií. Vzdelávanie sa tak stáva pútavejším, adresnejším aefektívnejším. E-learning dokáže učite�a oslobodi� od každodenného opakovaniavýkladu, navyše dokáže často prostredníctvom obrázku, či animácie vysvetli�problém jednoduchšie a dostatočne názorne na to, aby si ho študent lepšiezapamätal. Môže to vzbudi� dojem, že úloha učite�a tým zaniká. Opak je všakpravdou. E-learning umožňuje učite�ovi sta� sa lektorom, ktorý svoju pozornos�venuje len problematickým oblastiam, zdokona�ovaniu svojich kurzov, vytváraniunových komunikácii so študentom a iným činnostiam, na ktoré mu doteraznezostával dostatok času. Práve komunikácia so študentom je ve�mi dôležitousúčas�ou vzdelávania prostredníctvom elektronických médií.

Už dnes je jasné, že e-learning nahradí tradičnú formu externého štúdia,ako ju poznáme dnes. E-learning posúva školstvo na vyššie priečky, otvára novémožnosti učite�om aj študentom a stáva sa novou, modernou a plnohodnotnousúčas�ou vzdelávania.

1.2.2 Spôsoby využitia e−learningu

Aby sme sa bližšie oboznámili s prostriedkami a možnos�ami použitia e-learningu,popíšeme si základnú terminológiu a pojmy z tejto oblasti. Využitie e-learningu vovýučbe sa dá rozdeli� pod�a toho, či sa vo výučbe používa ako učebná pomôcka(väčšia čas� výučby je vykonávaná klasickým spôsobom), alebo je priamoprostriedkom, prostredníctvom ktorého výučba prebieha.


Pod�a spôsobu, akým je prístupný e-learning študentovi, môžeme rozdeli�spôsob výučby na tieto kategórie:

Technológiou podporovaná výučba – Pri tomto spôsobe výučby majúštudenti možnos� často sa stretáva� s vyučujúcim. Dopĺňa pritom štandardnýspôsob štúdia, a môže nahradi� materiály pre študentov, predtým dodávanév klasickej forme učebníc, papierových kópií a pod. Typicky to znamenáuverejňovanie osnov, odkazov na materiály a �alších materiálov pre výučbuon-line.

Technológiou podávaná výučba – Nikdy (alebo ve�mi málo) nie jevyžadovaný fyzický kontakt študenta s vyučujúcim. Je tiež známa ako „dištančnévzdelávanie“, „distribuované vzdelávanie“ alebo „dištančná výučba“. Vyučujúcimvedené tradičné triedy sú minimalizované, nahradené inými formami pôsobenianie v reálnom čase fungujúcimi „virtuálnymi triedami“. Pri on-line vzdelávaní savyužíva doručenie kurzu lebo programu vzdelávania, ktorý nie je typickým pretradičné, „kamenné univerzity“, až k používate�ovi (študentovi)

V súčasnosti sa väčšia čas� výučby na školách a univerzitách realizujevo forme technológiou podporovanej výučby, a ve�mi málo informatickýchpredmetov u nás je realizovaných za pomoci technológiou podávanej výučby.Práve z dôvodu ve�kého záujmu o informatické predmety a z dôvodu zvýšeniakapacít sa uvažuje a prechádza z technológie podporovanej výučby technológioupodávaný spôsob výučby.

1.2.3 Rozdelenie podľa spôsobu komunikácie

Pod�a spôsobu, akým sa študujúci stretáva a dostáva do kontaktu s obsahomučebných materiálov a vyučujúcim sa dá rozdeli� spôsob výučby na tieto kategórie:

Samoštúdium – Samoštúdium sa spolieha na určitý presne formulovanýplán, ktorý študenta vedie štúdiom, bez interakcie (odohrávajúcej sa v reálnomčase) s vyučujúcim. Príkladom materiálov pre túto formu štúdia súmultimediálne, na CD-ROM uložené materiály, písomná korešpondencia a tzv.„Click-To-Learn“, na web technológiách postavené systémy. Môže by� pritomdoplnené asynchrónnym vzájomným pôsobením študenta s vyučujúcim,prostredníctvom elektronickej pošty, hlasovej pošty či komentárov v tematickejdiskusii. Výučba postavená čisto na samoštúdiu vyžaduje, aby mal študentvytvorenú vlastnú motiváciu k štúdiu. Počet študentov korešpondenčných kurzov,ktorí nedokončia štúdium je ove�a vyšší, ako v prípade študentov tradičných„kamenných univerzít“. Samoštúdium môže by� použité pre tvorbu a potvrdenieschopnosti pre zvládnutie základov výučby, o zjednodušenie učiaceho procesu(prístup k osnovám predmetu, pridelenie úloh, chod kurzu, študentovisprístupnené hodnotenie), o odhad úspešnosti študenta prostredníctvom danýchcie�ov a merate�ných metód, testov, analýzy a dosiahnutých bodov)

Vyučujúcim vedené štúdium – Tento spôsob štúdia je dôležitý z dôvoduspoločného zdie�ania skúseností či udalostí. Obvykle sa koná v reálnom čase, jeinteraktívne a má dynamický priebeh. Vyučujúcim vedené štúdium má možnos�dynamicky reagova� na prostredie a meni� plán štúdia alebo jeho priebeh pod�apotrieb vyučujúceho v konkrétnom čase. Toto napomáha udrža� pozornos�študenta a pomáha znižova� počet študentov, ktorý nedokončia kurz. Môžeme pritom rozlíši� dva prístupy:


– „vysielací model“ – štýl semináru, prednášky. Vyučujúci prednášas malou alebo žiadnou odozvou a interakciou od publika. Tentomodel je možné �ahko rozšíri� na väčšie množstvá študujúcich a jeasi najčastejšie používaný (ako príklad môžu slúži� klasicképrednášky na univerzitách),

– „dialógový model“ – malá skupina vedená vyučujúcim (expertomv danej problematike) – často ve�mi interaktívne, dynamickysledovaná a prispôsobovaná aktuálnym potrebám dialógu a výučby.Tento model je typický pre „kamenné univerzity“ a vyžaduje menšípočet študentov na skupinu (napríklad cvičenia v učebniachvýpočtovej techniky).

1.2.4 Hybridný spôsob výučby

Zmiešaný spôsob výučby je taký spôsob, ktorý využíva možnosti výučby za pomociprostriedkov informačno-komunikačných technológií (multimediálne CD-ROM,lokálne počítačové siete, Internet) a je ho možné kombinova� ho s klasickýmspôsobom výučby „tvárou v tvár“ (prednášky a cvičenia). Dá sa poveda� žev súčasnosti ešte nenastali podmienky pre výučbu prostredníctvom lenpočítačových sietí. Samozrejme, tento spôsob je pri súčasnom stave techniky plnevyužite�ný aj u nás, avšak ešte stále nenastali vhodné podmienky, ktoré byumožňovali využíva� možnosti dištančného vzdelávania bez živého kontaktus vyučujúcim všetkým potencionálnym záujemcom. Preto je dnes pre tie školya univerzity, ktoré chcú využíva� najmodernejšie trendy vo výučbe,najprijate�nejším spôsobom pre vedenie výučby hybridný spôsob výučby.

1.2.5 Použitie multimediálnych technológií v e−learningu

E-learning je proces, ktorý zahŕňa tvorbu a distribúciu e-learningových kurzov,riadenie výuky a následnú spätnú väzbu. E-learningové kurzy sú aplikácie, ktoréväčšinou obsahujú simulácie a multimediálne lekcie, t.j. kombinácie textovéhovýkladu a multimédií. Študijné materiály pre kurzy dištančného vzdelávania saväčšinou skladajú z nasledovných častí:

Tlačené texty – ktoré vytvára špecialista na obsah, obvykle učite�(prostriedky pre tvorbu tohto typu materiálov sú obvyklé textové editory, nakoniecv tomto prípade nie je dôležitý prostriedok, ktorý sa pre vytváranie danéhomateriálu používa, ale jeho obsah). Texty by mali by� vytvorené pod�a zásadpedagogiky dištančného vzdelávania. Dištančný text musí by� usporiadanýv krátkych moduloch. Musia by� jasne vymedzené ciele výučby. Každý študijnýtext by mal obsahova� obsah, úvod, text a záver. Nemal by chýba� slovníkpojmov, k�úč k úlohám a testom a zoznam literatúry. Súčas�ou každého modulusú jednoduché úlohy a testy, ktoré má študujúci vypracova� a posla� v zadanýchtermínoch, čím sa kontroluje jeho aktivita a zais�uje sa spätná väzba.

Multimediálne materiály – animácie, grafika, schémy, zvuk, videoa elektronické testy. Vytvorenie kvalitných multimediálnych materiálov je vysokoprofesionálna úloha pre špecialistov, pretože vyžaduje znalosti príslušných HWa SW technológií. Počítačový expert musí samozrejme ma� od učite�a k dispozícii


pedagogicky a odborne pripravený obsah príslušného výučbového materiálua scenár usporiadania jednotlivých prvkov.

Grafika a schémy – predstavujú základný doplnok k učebným textom,bez ktorého sa nezaobíde žiadna kvalitná učebnica. Slúžia na �ahšie aintuitívnejšie pochopenie látky, ktorá je opísaná v príslušnom texte. Sú statickéhocharakteru, čiže neobsahujú pohybujúce sa prvky. Grafika sa dá vytvára vovektorových (napr. CorelDraw) alebo bitmapových (napr. Adobe Photoshop)grafických editoroch.

Animácie – slúžia na dodatočné vysvetlenie danej problematiky, prípadnena preh�adné zopakovanie prebranej kapitoly. Slúžia najmä ako doplnok grafiky,avšak v dnešnej dobe sa čoraz viac dostáva do popredia flash animácia. Takétoanimácie umožňujú ma� úplnú kontrolu nad jej priebehom pomocouinteraktívnej komunikácie s používate�om, čo je v priebehu výučby ve�ká výhoda.

Zvuk a video – väčšinou slúžia ako sprievodný materiál k danej téme.V prípadoch jednoduchej látky však môžu by� postačujúce na celkové pochopenieučiva a preto sa môžu distribuova� i samostatne. Ďalšie použitie zvuku a videavychádza z potreby spätnej väzby medzi študentom a učite�om, ktorá môže by�realizovaná práve týmto spôsobom (napr. videokonferenciou), čo si však vyžadujeve�ké nároky na kvalitu spojovacej siete.

Elektronické testy – s ich pomocou sa študent môže sám otestova�, akozvládol danú problematiku. S patričným zabezpečením sa môžu využi� i naohodnotenie študenta učite�om. Väčšinou sú realizované v prostredí HTMLs použitím JavaScript-u, môže sa tu využi� aj flash animácia.

Distribúcia multimediálnych študijných materiálov od vzdelávacejinštitúcie k študujúcemu sa realizuje na dátových nosičoch, ktorými môžu by�napríklad audio a video kazety, počítačové diskety alebo CD disky. Pre rôznepedagogické ciele sú vhodné rôzne technológie či kombinácie viacerých cenovodostupných technológií. Pre distribúciu multimediálnych študijných materiálov sačoraz častejšie používa Internet. Všetky vyššie spomenuté materiály vyžadujúpreh�adnos�, orientáciu, prezentáciu, štruktúru a prístup k informáciám, čo spolutvorí kvalitný učebný materiál pre potreby dištančného vzdelávania.

1.3 Prostredia pre tvorbu prezentácií

Tvorba prezentácii sa v poslednej dobe stala pomerne aktuálnou. Sú súčas�ouvyučovacieho procesu používaného na vysokých školách, pri prednášaní,umožňujú oživova� konferencie a začali sa používa� pre dištančné štúdium.Hlavným dôvodom ob�úbenosti je ich jednoduchos� na ovládanie, názornos�,doplnenie obrázkami a animáciami, ktoré oživujú text.

Túto skutočnos� si všimli mnohé firmy, ktoré sa zaoberajú tvorbousoftvéru. Po jednoduchých aplikáciách, ktoré umožňovali len jednoduchévkladanie obrázkov a textu sa začali objavova� prvé profesionálne aplikácie. Vývoja konkurencia v tejto oblasti však pracuje správne, takže v súčasnosti mámemnožstvo nástrojov na tvorbu prezentácii s obrovskými možnos�ami. Vývojspôsobil ich rozdelenie na dve základné skupiny:


Jednoduché aplikácie pre začiatočníkov – aplikácie, ktorých základom jeskĺbenie podporovaných funkcií a jednoduchos� práce pri tvorbe prezentácie, takaby aj začínajúci používate� mal možnos� tvorby prezentácie. Často ide leno jednoduché zadávanie postupností obrazoviek, ktoré sú tvorené obrázkamia jednoduchým sprievodným textom. Je to dané tým, že prezentácie vytvorenév týchto aplikáciách sa používajú hlavne na prednes, pri ktorom slúžia akografické pozadie k hovorenému slovu. Nie je možné tvori� zložito štruktúrovanéprezentácie, ktoré sú určené napríklad pre dištančné štúdium.

Profesionálne aplikácie – aplikácie, ktoré sa snažia poskytnú� ve�kémnožstvo funkcií. Jednoduchos� práce s aplikáciou je až na druhom mieste.Samozrejmos�ou je poskytnutie ovládania, ktoré nebude pre používate�aprekážkou, ale pomôckou. Aplikácie poskytujú možnosti grafického editovania,a tiež podporu skriptovacieho jazyku. Je možné tvori� aj jednoduché prezentácie,ale hlavné �ažisko je v tvorbe štruktúrovanej prezentácie s možnos�ou použitiavšetkých moderných technológií, predovšetkým internetových.

Aj napriek rozdeleniu aplikácii na dve základné skupiny je možnépoukáza� na spoločnú vlastnos� – tvorba prezentácie je plne grafická. Toznamená, že na plochu sú pridávané grafické komponenty, ktoré podporujeaplikácia. Je možné meni� ich umiestnenie na stránke a vlastnosti. V závislostiod aplikácie potom závisia aj �alšie možnosti úpravy komponent.

U aplikácií na tvorbu prezentácií je však možné vidie� �alší dôležitýfaktor, ktorý určuje ich použitie: výstupný formát prezentácie. Pod�a toho ichmožno rozdeli� do nieko�kých skupín:

a) prezentácie, ktoré potrebujú aplikáciu, v ktorej boli vytvorené na ichprezeranie. Typickým predstavite�om je aplikácia PowerPoint 2000.

b) prezentácie, ktoré sú tvorené spustite�ným súborom. V tomto prípadeje to napríklad aplikácia Multimedia Builder 4.9.

c) prezentácie vo forme www stránky. Typickým príkladom je aplikáciaIlluminatus.Aplikácie umožňujú grafickú editáciu. Multimedia Builder navyše

obsahuje skriptovací jazyk, pomocou ktorého je možné vytvára� vlastné udalosti,ktoré môžu nasta� v programe, napríklad po stlačení tlačidla. Je dobré predstavi�si základné vlastnosti niektorých aplikácií.

1.3.1 Power Point 2000

Program PowerPoint je asi najčastejšie používaným nástrojom pre tvorbuprezentácii. Jeho základom je jednoduché rozhranie, ktoré je intuitívne a najmäefektívne. Je možne importova� do prezentácie výstupy z iných programovkancelárskeho balíka Microsoft Office. Ďalším významným plusom aplikácie jeexistencia šablón obrazoviek prezentácii. Aplikácia obsahuje množstvosprievodcov pre �alšie zjednodušenie práce.

Jednoduchos� aplikácie je aj mínusom. Je to v dôsledku orientácieaplikácie na začínajúcich používate�ov. Neobsahuje teda možnos� tvorbyzložitejších štruktúr, tvorbu tlačidiel s možnos�ou nastavova� akcie po vykonanía podobne. Vytvorené prezentácie je možné prehliada� len v aplikácii, teda ideo �alšie obmedzenie prenosite�nosti prezentácie. Je však možné exportova�výstupnú prezentáciu do HTML. Stráca sa tak však podpora medziobrazovkových


efektov a zvukových súborov, ktoré HTML značky nepodporujú. Nie je možnépouži� animácie, ktoré sa používajú na internete ako Flash a animovaný GIF.Pretože ide iba o jednoduchú aplikáciu jej použitie pre dištančné štúdium jenedostatočné.

1.3.2 Multimedia Builder 4.9

Multimedia Builder predstavuje profesionálny nástroj. Aplikácia je jednoducháa nie je problém sa v nej vyzna� po prvom spustení. Ovládanie je intuitívne,podporuje priame grafické editovanie metódou Drag & Drop. Obsahujemnožstvo komponent, ktoré je možné vklada� do prezentácie.

Základná obrazovka je rozdelená na tri časti. V hornej časti je lištas tlačidlami pre ovládanie, �avú čas� tvorí lišta s komponentmi, ktoré aplikáciapodporuje. V dolnej časti je zoznam obrazoviek, ktoré tvoria prezentáciu a vpravoje zoznam komponent, ktoré sú v prezentácii. Používate� tak má okamžitý prístup,ku všetkým dôležitým prvkom prezentácie.

Jednotlivým komponentom, ktoré sa nachádzajú v okne prezentácie jemožné nastavova� udalosti. Ich podpora je rozšírená o existenciu skriptovaciehojazyka. Je tak zabezpečená podpora pre tvorbu vlastných udalostí napríklad pristlačení tlačidla. Do prezentácie je možné vklada� zvukové súbory vo formáteMP3, WAV, MID. Ďalším možným prvkom sú videá vo formáte AVI, MPEGa animovaný GIF. Obrázky, ktoré sa pridávajú do prezentácie je možné oživi�jedným z obrázkových efektov. Aplikácia obsahuje navyše možnos� vytvára�vlastné typy efektových klipov. Pre kompatibilitu s WWW stránkami je možnévklada� do prezentácie vytvorené WWW stránky, poprípade Flash animácie.

Aplikácia podporuje tvorbu zložitej štruktúry prezentácie. Chýba všakmožnos� zobrazenia štruktúry v strome. Nie je možné prezera� ako sú pospájanéobrazovky prezentácie. Aplikácia nepodporuje pokročilú prácu s textom, čo súvisís jej orientáciou na tvorbu grafických prezentácii. Je možné meni� len vlastnosticelého textu v textovej komponente. Farbu, font a štýl písma. Chýba tak možnos�formátovania časti textu v textovej komponente. Nie je možné vytvára�štruktúrované nadpisy.

Výstupom aplikácie je vykonate�ný súbor. Z toho vyplýva aj základnýmínus aplikácie. Do výstupného súboru sa integrujú všetky súbory, teda ajanimácie a obrázky, čím je zhoršená spustite�nos�, pretože je nutné nahra� celúaplikáciu do pamäti, a tiež je tým spomalená práca pri tvorbe. Ďalší mínusvychádza z orientácie aplikácie na grafiku a nepodporuje tak lepšiu prácus textom. Nie je možné exportova� prezentáciu do formátu HTML.

Aplikácia predstavuje profesionálny produkt. Jej možnosti použitia predištančné štúdium sú však značne obmedzené.

1.3.3 Illuminatus

Aplikácia Illuminatus podporuje komponenty podobne ako Multimedia Builder,aj ke� možnosti udalostí pri jednotlivých komponentoch sú slabšie anepodporuje skriptovací jazyk. Nie je možné používa� grafické efekty na zlepšeniekvality obrázkov. Je to v dôsledku orientácie aplikácie na Internet, pretožezákladným výstupom aplikácie je WWW stránka. Posledná verzia obsahuje


chybu, ktorá neumožňuje export do čistého jazyku HTML, ale len jazyku Java. Jejpoužitie je obmedzené na prehliadače s podporou Java.

Aplikácia neposkytuje jednoduché ovládanie ako Multimedia Builder a ajpráca s ňou je o trochu náročnejšia. Preto sa jej opisom nebudem zaobera�podrobne.

1.4 Analýza podobných prezentácií

1.4.1 Cisco Network Academy Program

Popredný výrobca sie�ových smerovačov, firma Cisco Systems Incorporated,využíva multimediálne prezentácie v rámci vzdelávacích kurzov pre budúcichsie�ových špecialistov – Cisco Network Academy Program (CNAP).

Vzdelávací program je rozdelený do nieko�kých stupňov a každý stupeňdo nieko�kých modulov. Stupne možno prirovna� rozsahom k predmetom navysokej škole a moduly k častiam predmetov. Každý modul obsahuje nieko�kokapitol alebo okruhov, ktoré sú �alej rozčlenené na podkapitoly a články.Prezentácie sú nezávislé na úrovni modulov.

Orientácia v prostredí prezentácie

Používate� si po otvorení modulu môže vybra� okruh, o ktorý má záujem. Zobrazísa látka prvého článku okruhu. V záhlaví prezentácie je uvedený názov stupňaa verzia spolu s logom spoločnosti. Používate� sa môže pohybova� o článok vpreda vzad pomocou tlačidiel so šípkami, ktoré sú umiestnené vpravo dole. Okremnich sa tam nachádzajú aj tlačidlá pre zobrazenie obsahu, spustenie testovzvládnutia látky okruhu a pre zobrazenie slovníka pojmov. Pomocou roletovejponuky na spodnom okraji obrazovky je možné zvoli� si iný okruh.


Organizácia obsahu

Látka je prezentovaná v dvoch oddelených častiach obrazovky. avá, väčšia čas�,zaberá asi 60 % šírky a pravá zvyšný priestor. V �avej časti sa zobrazujú obrázky,animácie, tabu�ky a diagramy. Pomocou očíslovaných záložiek pri �avom okraji simožno zvoli�, ktorý objekt sa má zobrazi�. Nad touto čas�ou sa pri niektorýchdruhoch obsahu zobrazujú �alšie ovládacie prvky, ktoré umožňujú napríkladspustenie animácie, prehrávanie zvuku, zobrazenie prepisu nahrávky, tlačeniea zväčšenie alebo zmenšenie.

V pravej časti sa nachádza text prezentácie. Na jeho začiatku sanachádzajú nadpis podkapitoly a článku uvedené ich číslovaním(v rámci modulu). Za odstavcom, ktorý súvisí s obrázkom alebo iným objektomzobrazovaným v �avej časti, sa nachádza číslo tohto objektu (číslovanie je v rámcičlánku). Číslo nie je hyperlinka. Na konci väčšiny článkov sa nachádzajú odkazyna zdroje súvisiacich informácií na Internete, prípadne informácie o súvisiacichmateriáloch a aktivitách CNAP.

Formátovanie

Celá prezentácia je formátovaná pod�a presných pravidiel. Farby boli zvolené zrôznych tónov neutrálnych farieb. Odstavce textu sú oddelené polriadkom bezodsadenia prvého riadku. V celej prezentácii je použitý jeden bezpätkový font(Arial) vo viacerých rezoch. Základný text je v obyčajnom reze, nadpisy, nápisy vobrázkoch a záhlaví sú v polotučnom reze. Odkazy sú vyznačené inou farboupísma a podčiarknutím.


Záver

CNAP je prepracovaný vzdelávací program na vysokej úrovni tak po obsahovejako aj po formálnej stránke. Prezentácia je vo svojej forme jednoduchá a pritomelegantná. Ako kompromis pôsobí umiestnenie textu na pravý okraj obrazovky amultimediálnych objektov v�avo. Prispieva to síce k preh�adnosti a zrejme aj kimplementačnej jednoduchosti, avšak degraduje čitate�nos� textu, ktorý tvorívýznamnú čas� prezentácie, nehovoriac o plytvaní plochou obrazovky.

1.4.2 Kurz signalizácie v ISDN

V rámci predmetu Integrované služby digitálnych sietí sme mohli na vlastnej koživyskúša�, čo to znamená vzdeláva� sa elektronicky. Vo forme multimediálnejprezentácie bola spracovaná čas� látky tohto predmetu.

Pohyb v prezentácii na úrovni častí umožňujú odkazy na začiatku a koncikaždej časti. Zoznam všetkých častí je zobrazený len pri úvodnej časti. Prezentáciamá ve�mi vo�né členenie (8 častí a v rámci nich nadpismi uvedené podčasti), kvôličomu je predložená látka menej preh�adná. Text s vloženými objektmi(obrázkami, animáciami, tabu�kami, at�.) je prezentovaný na celej plocheobrazovky s okrajom v�avo a malým okrajom vpravo. Praktické je umiestnenieväčšej časti obsahu do jedného súvislého prúdu. Používate�ovi to umožňuje ma�väčšiu kontrolu nad priebehom prezentácie a lepšie sa orientova� v látke, ke�ženie je odkázaný na listovanie po jednej strane.

Pri tvorbe tejto prezentácie sa zrejme kládol ove�a väčší dôraz naobsahovú ako na formálnu stránku. Text prezentácie nie je �ahko čitate�ný, čomuzo strany formátovania prispievajú tučné bezpätkové písmo, dlhé riadky, malýpreklad a slabá podpora členenia textu. Avšak kurz signalizácie v ISDN je, ike�nie ideálna, predsa jedna z mála naozaj fungujúcich a používanýchmultimediálnych prezentácií na našej škole.


2 Analýza2.1 Katalóg požiadaviek

Táto kapitola obsahuje požiadavky na informačný systém pre tvorbumultimediálnych prezentácií. Požiadavky sú zoskupené hierarchicky. Identifikovalisme tieto skupiny požiadaviek:

– funkcionálne požiadavky (t. j. požiadavky na funkcie systému) –Súborová správa prezentácie, Správa základných parametrov prezentácie,Vytváranie štruktúry prezentácie, Tvorenie obsahu obrazoviek, Tvorenieautomatických obrazoviek, Ovládacie panely, Pomocník, Vyh�adávanie,Doplnkové funkcie

– systémové požiadavky – Garantované zdroje, Parametre návrhovéhosystému

– bezpečnostné – Ochrana údajov Požiadavky sú detailne opísané v tabu�kách uvedených nižšie. Stĺpce

v tabu�kách majú takýto význam:

IdIdentifikátor požiadavky

ČísloHierarchické číslo pod�a umiestnenia v strome požiadaviek

Názov Výstižný názov požiadavky

OpisStručný opis požiadavky

ÚroveňÚroveň požiadavky:

U – nelistová (rozvíja)L – listová (nerozvíja sa)

TypTyp požiadavky:

F – funkcionálna požiadavkaS – systémová požiadavkaB – bezpečnostná požiadavka

ZdrojReferencia na zdroj požiadavky:

Zad. (zadávate�)Tím (členovia tímu)

PrioritaPriorita môže nadobúda� nasledovné hodnoty:

1 – vysoká2 – stredná3 – nízka


2.2 Scenáre použitia

2.2.1 Vloženie textovej komponenty na obrazovku prezentácie

Opis situácie: Pridanie novej textovej komponenty na obrazovku prezentácie.Typické kroky:

1. Požívate� stlačí tlačidlo textovej typovej komponenty.2. Systém pridá komponentu na koniec zoznamu komponent na

obrazovke.3. Požívate� stlačí komponentu na obrazovke.4. Systém otvorí používate�ovi editačné okno.5. Požívate� zadá text a pomocou menu ho naformátuje do požadovanej

podoby.6. Požívate� ukončí editáciu zatvorením okna.7. Systém uloží text do výstupného súboru a čaká na �alší krok.

2.2.2 Vloženie novej obrazovky prezentácie

Opis situácie: Pridanie novej obrazovky do prezentácie.Typické kroky:

1. Používate� stlačí tlačidlo pridanie novej obrazovky.2. Systém zobrazí okno s možnos�ou nastavenia mena a parametrov.3. Používate� zadá základné parametre.4. Systém uloží parametre obrazovky a pridá ju na koniec zoznamu

obrazoviek.

2.2.3 Export prezentácie do HTML

Opis situácie: Vytvorenie výslednej HTML prezentácie.Typické kroky:

1. Používate� stlačí tlačidlo export.2. Systém odovzdá parametre prezentácie a jej štruktúru používate�skej

knižnici.


3. Používate�ská knižnica vytvorí z prezentácie v návrhovej forme HTMLstránku výslednej prezentácie.

2.3 Analýza formátovania prezentácie

Formátovanie prezentácie by malo napomáha� používate�ovi vníma� obsahprezentácie, orientova� sa v ňom a pohodlne riadi� jej priebeh. Ke�že naformátovanie používate�ského rozhrania a obsahu (látky) prezenácie sú kladenéodlišné nároky tak z používate�ského ako aj implementačného h�adiska, je vhodnézaobera� sa nimi oddelene. Na�alej ich však bude spája� požiadavka na jednotnýdizajn celej prezentácie.

2.3.1 Obsah prezentácie

Obsah prezentácie sa delí na časti kvôli preh�adnosti a taktiež za účelomodkazovania. Môže by� prezentovaný v zásade dvoma spôsobmi:

– ako súvislý tok textu a vložených objektov alebo – ako postupnos� stránok s vopred definovaným rozmiestnením textu

a objektov. Súvislý tok textu a vložených objektov (nadpisov, obrázkov, tabuliek,

animácií, a pod.) môže používate� posúva� vo vertikálnom smere, a tak si plynuloprezera� predložený materiál. V postupnosti stránok sa používate� pohybujeprostredníctvom navigačných tlačidiel (o stránku vpred, o stránku vzad, príp.iných) a tak sa môže sústredi� len na vopred určenú čas� obsahu.

Jednotlivé časti textu látky je potrebné odlíši� pod�a významu. Preto jevhodné zaradi� ich do týchto kategórií s oh�adom na možnosti jazyka HTMLv spolupráci s CSS2: nadpisy, holý text, zoznamy, tabu�ky, poznámky, definície,texty popisujúce vložený objekt.

Nadpisy

Nadpis slúži na získanie rýchlej informácie o obsahu jemu príslušnej časti textu.Nadpisy zoskupujú malé časti textu do väčších celkov alebo naopak, rozde�ujúdlhšie texty na menšie časti, a tým vytvárajú hierarchiu dokumentu.

Nadpisy jednotlivých úrovní je potrebné od seba odlíši�. Zo skúsenosti jeznáme, že príliš pestré členenie textu narušuje väzby medzi jednotlivými jehočas�ami, dezorientuje čitate�a a nie je ani estetické. Preto je potrebné urči�kategórie nadpisov pod�a možnosti korešpondujúce s úrovňami hierarchie a zvoli�vlastnosti ich písma a umiestnenia – formátovanie.

Špecifikácia jazyka HTML a CSS2 umožňuje prispôsobi� a používa� ažšes� úrovní nadpisov. V praxi sa však osvedčuje používanie nadpisov najviacštyroch úrovní. Väčší počet úrovní je problém rozumným spôsobom od sebaodlíši�.

Nadpisy vyššej úrovne odde�ujú väčšie časti textu, preto bývajú zvyčajnevýraznejšie. Naopak, nadpisy nižších úrovní by nemali zbytočne rozbíja� text,preto by mali by� nenápadnejšie. V odborných textoch sa často využíva číslovanie


nadpisov, ktoré pomáha pri odkazovaní na určité časti textu. Číslovanie nadpisovje hierarchické.

Holý text

Najväčšiu čas� prezentácie bude tvori� holý text učiva. V ňom sa nachádza �ažiskoprezentovaných informácií. Najdôležitejším kritériom pri jeho formátovaní ječitate�nos� (pod�a možnosti na rôznom hardvéri) najmä pri dlhšom čítaní.

Niekedy je potrebné v texte zvýrazni� určité slová, slovné spojenia,prípadne vety, na ktoré sa kladie väčší dôraz. Môžu to by� napr. pojmyterminológie, tvrdenia, závery ale aj odkazy na iné časti prezentácie. Klasickátypografia odporúča zvýrazňova� text zmenou jeho rezu pod�a nasledovných zásad:

– kurzíva: najmenej ruší šedos� textu; najbežnejší a najšetrnejší spôsobzvýrazňovania,

– polotučné písmo: výrazne ruší šedos� textu; používa� len v osobitneodôvodnených prípadoch,

– polotučná kurzíva: klasická typografia ju nepozná, vznikla až spolus elektronickou sadzbou; neodporúča sa používa�.Ďalšie možnosti zvýrazňovania sú:

– zmena farby písma,– zmena prestrkania,– zmena ve�kosti písma,– verzálky,– kapitálky,– podčiarknutie,– horný index,– dolný index a �alšie.

Zoznamy

Vymenovanie položiek zoznamu sa v texte často vyznačuje špeciálnym spôsobom.Každá položka zoznamu začína na novom riadku a je uvedená značkou. Pod�adruhu značky možno rozdeli� zoznamy na číslované (každá položka má priradenéoznačenie z všeobecne známeho radu) a nečíslované (uvedené špeciálnymznakom, symbolom).

Najbežnejšie spôsoby číslovania sú:– arabské číslice,– abeceda z malých písmen,– rímske číslice a – abeceda z ve�kých písmen

Číslovania môžu by� viacúrovňové, pričom úrovne sa odde�ujúnajčastejšie bodkou. Viacúrovňové číslovanie zoznamov nebude v našomprodukte podporované, pretože by mohlo pôsobi� rušivo v súvislosti s číslovanímnadpisov.

Nezriedka je potrebné v rámci zoznamu uvies� �alší zoznam.Pri číslovaných zoznamoch sa zvyčajne uplatní iný spôsob číslovania, prinečíslovaných sa môže ale nemusí použi� iný symbol ako v nadradenom zozname.

Pre zvýrazňovanie častí zoznamov platia tie isté pravidlá ako pre holý text.


Tabu�ky

Tabu�ky sme sa rozhodli rieši� ich včlenením ako obrázky. Rozsah predmetuneumožňuje vytvori� editor tabuliek. Iným možným riešením môže by� vloženieHTML kódu z externého súboru vygenerovaného bežným editorom HTML.

Poznámky

Na spresnenie a doplnenie textu možno použi� poznámky. V tlačených kniháchsú uvedené zvyčajne menším písmom, často na spodnej časti strany pod čiarou sodkazom v texte. Iný často používaný spôsob formátovania poznámok je ichvloženie za odstavec, obsahu ktorého sa týkajú. Pritom sú poznámky taktiežpísané malým písmom, oproti predchádzajúcemu spôsobu však naviac odsadenéa často oddelené aj iným spôsobom (linkami pred a za poznámkou, ikonou,uvedené textom "Poznámka", at�.)

Definície

V náučnom texte majú zvláštne postavenie definície. Skladajú sa z objektudefinície (slovo alebo slovné spojenie) a textu samotnej definície.

Vložené objekty

Prepojenie obrázkov, tabuliek, animácií, schém, diagramov s textom sa realizujeodkazom v texte na číslo daného objektu. Každý objekt takéhoto charakteru byvšak kvôli preh�adnosti mal ma� okrem čísla aj stručný opis, jednou vetouvystihujúci jeho obsah.

Vložené objekty môžu by� v texte umiestnené v zásade dvomaspôsobmi – vložením s obtekaním textu pozdĺž jednej strany objektu alebovloženie medzi dva odstavce bez obtekania.

2.3.2 Používateľské rozhranie prezentácie

Látku prezentácie používate�ovi sprístupňuje používate�ské rozhranie prezentácie.K jeho hlavným úlohám patria:

– informovanie o názve prezentácie, autoroch, podmienkach použitia,kontakte na správcu,

– jednoduchá navigácia v malom rozsahu článkov,– primerane zložitá navigácia v rámci celej prezentácie,– prístup k obsahu, indexu, slovníku pojmov, testom,– prístup k súvisiacim zdrojom informácií na Internete,– informovanie o aktuálnej pozícii v prezentácii (v hrubom meradle).

2.3.3 Záver

Zoznam tried textu prezentácie, pre ktoré je potrebné navrhnú� formátovanie:– holý text– nadpisy


– nadpis kapitoly– nadpis podkapitoly– nadpis článku– nadpis štvrtej úrovne

– zoznamy– nečíslovaný zoznam

– obyčajný nečíslovaný zoznam– vnorený nečíslovaný zoznam– vnorený číslovaný zoznam

– číslovaný zoznam– obyčajný číslovaný zoznam– vnorený nečíslovaný zoznam– vnorený číslovaný zoznam

– definícia– objekt definície– text definície

– poznámka– popis k vloženému objektu

V každej triede je potrebné okrem základného textu navrhnú�formátovanie pre:

– zvýraznenie– odborný termín– odkaz

Zoznam prvkov používate�ského rozhrania prezentácie, pre ktoré jepotrebné navrhnú� formátovanie:

– názov prezentácie– autor prezentácie– administratívne informácie– štruktúra prezentácie– ovládacie prvky– úvodná obrazovka

2.4 Interview s Ing. J. Hudecom

V tejto podkapitole uvádzame interview s vedúcim tímového projektuJ. Hudecom na tému multimediálna podpora predmetu Architektúra počítačov.Otázky boli kladené na zistenie základných, ale aj podrobných požiadaviek a slúžihlavne pre ozrejmenie si predstáv v tejto oblasti.

Aké formáty výstupných súborov majú by� podporované?Okrem štandardného HTML výstupu by mal by� podporovaný hlavne

PDF formát z h�adiska jeho univerzálnosti a rozšírenosti. Ďalšie formáty nie jenutné podporova�.


Aké by mali by� typy šablón?Šablóny by mali by� rozdelené do dvoch skupín. Prvá skupina by bola na

vytváranie bežných multimediálnych prezentácií a druhá skupina určená špeciálnena dištančné štúdium. Z každej skupiny by ich malo by� nieko�ko, aby boloz čoho vybera�.

Aké typy fontov by mali by� podporované?Rozhodne by nemla chýba� podpora všetkých štandardných fontov, ktoré

sú poskytované prostredím, prioritne ktoré sú podporované v operačnom systémeWindows s dôrazom na správnu diakritiku. Podpora špeciálnych fontov nie jenutná.

Je nutné implementova� funkciu "vráti� spä�"? Ak áno, do akej hĺbky?Samozrejme takáto funkcia by u�ahčila vytváranie prezentácií. Hĺbka by

mala by� aspoň tri kroky, samozrejme závisí to aj od implementačných možností.Je potrebné zavádza� kontrolu pravopisu?O tejto funkcii by sa dalo uvažova�, ale predpokladám, že vstupné texty

už budú skontrolované. O kontrole pravopisu by sa dalo uvažova� akoo prídavnej funkcii.

Je požadovaná ochrana údajov?Systém by mal podporova� zálohovacie funkcie, ktoré by mohli by� do

určitej miery aj automatizované. Autorizácia prístupu nie je nutná. Systém totižbude fungova� na počítačoch, ku ktorým majú prístup iba autorizované osoby.

Do akej miery by mal by� vypracovaný pomocník?Pomocník by mal by� v rozsiahlejšej forme vrátane príkladov tvorby

základných typov prezentácií. Vítaná by bola aj možnos� použitia onlinepomocníka, s ktorým by bolo možné rieši� aj zložitejšie problémy.

Akým spôsobom podporova� vyh�adávanie v dokumentoch?Bude postačova� vyh�adávanie základných odborných termínov a

definícií. Mohli by ste uvažova� aj o rozšírenom vyh�adávaní nadpisov a obrázkov.Mal by systém poskytova� aj nejaké štatistické informácie, ako počet slov, viet

a podobne?Myslím že pri niektorých typoch prezentácií je takáto funkcia určite

užitočná, a preto by malo zmysel o nej uvažova�.Aký počítačový systém bude používaný na vytváranie prezentácií na fakulte?Predpokladáme požitie produktu na modernejších počítačoch, ktoré

budú v blízkej dobe k dispozícii. Prostredie by malo by� optimalizované nabezproblémový chod na počítačoch Pentium 4 s operačným systémom Windows2000. Samozrejme, musí to by� funkčné aj na pomalších počítačoch.


3 Návrh3.1 Základné vlastnosti editora prezentácii

Z analýzy prostredí pre tvorbu prezentácií je možné vidie�, že existujúce komerčnéaplikácie neposkytujú možnosti vytvorenia plnohodnotnej prezentácie vhodnejpre dištančné štúdium, ktoré by vyhovovali podmienkam zadania tímovéhoprojektu. Základnou podmienkou zadania je export do formátu, ktorý podporujúvo�ne dostupné prehliadače. Ide o formát HTML. Ďalšia dôležitá podmienka jemožnos� jednoduchej úpravy existujúcej prezentácie.

Jediná aplikácia, ktorá poskytuje tieto kritéria je Illuminatus. Jehoovládanie však nie je na dostatočnej úrovni. Tiež preh�ad štruktúry prezentácie jenedostatočný.

Je dôležité zhrnú� základné požiadavky pre aplikáciu, ktorá by vyhovovalapodmienkam zadania a prebrala by tie najlepšie vlastnosti z už existujúcichprezentácii:

Vlastnosti možno spoji� do nieko�kých základných tried, ktoré sa týkajúvzh�adu aplikácie, úpravy štruktúry prezentácie, komponent a ich vlastností.Poslednou dôležitou čas�ou je výstup programu.

3.1.1 Vzhľad aplikácie

Základom aplikácie je nieko�ko líšt. Lišta s komponentami, ktoré je možnévklada� do prezentácie a možnos� nastavovania ich parametrov pre každúkomponentu, spolu s možnos�ou práce spôsobom Drag & Drop. Zoznamobrazoviek tvoriacich prezentáciu a možnos� prezerania štruktúry prezentácie ajv stromovom zobrazení. Tretia lišta zobrazuje komponenty, ktoré sa nachádzajúv prezentácii. Tým je k nim zabezpečený jednoduchý prístup a je možné meni� ichvlastnosti. Hlavnou čas�ou je obrazovka s oknom prezentácie, do ktorého savkladajú jednotlivé komponenty.

3.1.2 Štruktúra prezentácie

Prezentácia je tvorená obrazovkami. Vzájomné prepojenie obrazoviek vytváraštruktúru prezentácie. Zoznam obrazoviek nie je postačujúci na celkovú predstavuo štruktúre prezentácie. Preto aplikácia musí podporova� možnos� zobrazenia celejštruktúry aj s následnos�ou obrazoviek. Používate� tak získa preh�ad aj nadzložitou prezentáciou. Pretože aplikácia obsahuje nadpisy, je žiadúce vytvára� ajštruktúru na základe nadpisov, aby používate� mal možnos� vidie� aj textovúštruktúru.

3.1.3 Komponenty a práca s nimi

Podstatou celej prezentácie sú komponenty, ktoré možno vklada� na obrazovkuprezentácie. Zjednodušene možno poveda�, že komponenty určujú možnostiaplikácie a tým aj výslednej prezentácie.


Zoznam podporovaných komponent

Pri tvorbe prezentácie pre potreby dištančného štúdia je dôležitá názornos� učiva.Preto musí by� správne skĺbený text s podpornou grafikou v jednotlivýchobrazovkách prezentácie. Aplikácia tak musí podporova� vkladanie grafickýcha textových komponent.

Textové komponenty tvoria základ prezentácie určenej pre dištančnéštúdium. Základná komponenta je text. Pre lepšiu preh�adnos� textu je nutnámožnos� úpravy textu: farba, font, ve�kos�, štýl, zarovnanie. V prípade potreby jemožné použi� nastavenie konkrétnych slov v texte ako odkazov na iný textv prezentácii. Je tak možné vysvet�ova� pojmy v texte. Pre názornos� je niekedypotrebné umiestni� text učiva do tabu�ky. Samozrejmos�ou je tvorba nadpisov, priktorých je možnos� ich použitia ako odkazy na iné miesta prezentácie a určova�ich úroveň. Nadpisy by mali tvori� štruktúru, ktorú je možné použi� na tvorbuobsahu v prezentácii. Táto štruktúra tak umožňuje zobrazova� tematickú štruktúruučiva, ktorá môže by� odlišná od štruktúry obrazoviek prezentácie. Ďalšímikomponentmi, ktoré umožňujú zlepši� preh�adnos� sú obsah, ktorý je možnévklada� do prezentácie. S podporou obsahu súvisí číslovanie nadpisov. Programby tak mal podporova� aj automatické číslovanie nadpisov. Pre možnostitestovania zvládnutého učiva je potrebná komponenta test, ktorá bude obsahova�testové otázky. Na zoznam najdôležitejších pojmov je dobré vytvori� v prezentáciiindex. Zaujímavou by bola tvorba automatického indexu z už existujúcich pojmovv texte.

Pre grafické znázornenie učiva musia by� použité technológie, ktoré súpodporované prehliadačmi internetových stránok. Preto bude možne vklada� doprezentácie dva typy komponent. Jedna na vkladanie obrázkov, druhá navkladanie animácii. Pretože najpoužívanejšie obrázky sú typu jpg, gif a bmp, budemožný ich import, do prezentácie. Pri animáciách ide o súbory typu AVI, MPEGa Flash animácie, ktoré umožňujú vytvára� interaktívne animácie.

Pre možnos� zlepšenia komfortu bude možné vklada� do prezentáciezvukové súbory. Bude ich možné použi� na predčítavanie existujúceho textu,prípadne ako zvukovú kulisu.

Samozrejmos�ou je nastavovanie vlastností komponent. Na obrazovke prezentácie bude možné použi� dvojitý náh�ad na

komponenty. Prvý, kde komponenty budú predstavova� ikony, pri druhom sakomponenty nahradia svojím obsahom. Napríklad ikona s nápisom text, textom,ktorý obsahuje.

Tvorba šablón

Pri dištančnom štúdiu je snaha o vytvorenie jednotného zobrazenia. Je to danépsychologickým efektom na používate�a, ktorý číta text. Preto je potrebné abyprogram podporoval tvorbu šablón, ktoré bude možné uklada� do výstupnéhosúboru.


3.1.4 Výstup prezentácie

Ukladanie prezentácie

Prezentáciu je možné uloži� do výstupného súboru. Je tak možnos� neskoršiehonávratu k nej a jej modifikácia.

Export prezentácie

Prezentáciu bude možné exportova� do formátu HTML a PDF. Tento formátumožňuje prehliadanie vo vo�ne dostupných prehliadačoch. Je tiež možnos�umiestnenia celej prezentácie na internet. Bude tak všeobecne prístupná.Samozrejmos�ou je tlač výstupnej prezentácie. Vidie�, že existuje viacero možnostíexportu prezentácie. V súčasnosti sa na tento účel používajú samostatné moduly,ktoré sa dajú pridáva� k programu. Tento prístup umožňuje nezávislos� prostrediapre tvorbu prezentácie od výstupu aplikácie. Výstup aplikácie je možné meni�pod�a požiadaviek.

3.2 Roly používateľov

V tejto podkapitole identifikujeme jednotlivých používate�ov systému a podrobnerozoberieme ich roly z poh�adu vytváraného prostredia. V zásade je vhodnéhovori� o dvoch používate�och, a to takých, ktorí používajú systém z rôznehouvažovaného prístupu k systému. Je to „tvorca prezentácie“, ktorý pristupujek systému z poh�adu tvorby prezentácie a „študent prezentácie“, ktorý prezentáciuprezerá (a zrejme študuje). Nasledovne si rozoberieme každého z nich.

3.2.1 Tvorca prezentácie

Je taký používate�, ktorý prezentáciu vytvára, modifikuje, prípadne ju inakautorsky pozmeňuje. Predpokladáme, že tvorca prezentácie má k dispozíciipočítač, na ktorom má nainštalovaný vytvorený systém pre multimediálnupodporu predmetu Architektúra počítačov a je oprávnený so systémom narába�.Tomuto používate�ovi sú prístupné všetky funkčné požiadavky popísané vkatalógu požiadaviek (vi�. 2.1). Predovšetkým sú to vytvorenie novej prezentácie,vkladanie komponent ako text, obrázok a pod., správa šablón prezentácie,narábanie s ovládacími panelmi a mnohé iné. Výslednú prezentáciu si tvorcaprezentácie samozrejme má možnos� prezrie�.

3.2.2 Študent prezentácie

Je taký používate�, ktorý prezentáciu iba prezerá. To znamená, že to nie jepoužívate� priamo vytvoreného systému, ale iba výstupu, ktorý tento systémprodukuje. Predpokladáme, že študent prezentácie je teda �ubovo�ná osoba, ktorávlastní produkt (prezentáciu), vytvorený systémom pre multimediálnu podporupredmetu Architektúra počítačov.


3.3 Návrh aplikácie pre tvorbu prezentácie

Navrhovaný systém pre podporu dištančného štúdia je možné vidie� z dvochzákladných poh�adov. Prvý poh�ad sa zakladá na používate�och aplikáciea funkciách, ktoré im poskytuje. Druhý poh�ad pozerá na systém z h�adiskaimplementácie.

3.3.1 Koncepcia návrhu softvérového systému

z pohľadu používateľa

Základné rozdelenie navrhovaného systému vychádza z toho, že k systémupristupujú dvaja používatelia. Prvým je pedagóg alebo tvorca prezentácie. Ten máprístup k aplikácii na návrh prezentácie. Tu pomocou prostredia, ktoré muposkytuje prezentácia vytvára prezentáciu. Je možné identifikova� �alší modul,ktorý je pod vplyvom používate�a. Ide o konverziu prezentácie do výstupnéhosúboru. Druhým používate�om je študent, poprípade iný používate�, ktorýpristupuje k prezentácii.

Obr. 5. Základné rozdelene aplikácie z poh�adu používate�a

Prostredie pre tvorbu prezentácie

Prostredie pre tvorbu prezentácie je základným modulom, ktorý umožňujetvorcovi prezentácie určova� výstupnú prezentáciu. Základom je intuitívneovládanie. Návrh aplikácie vychádza z analýzy existujúcich aplikácii.

Základom je intuitívne prostredie. V prostredí je možné rozozna� trizákladné lišty:

– zoznam typových komponent, ktoré je možné vklada� do prezentácie,– zoznam obrazoviek tvoriacich prezentáciu a– zoznam komponent, ktoré sa nachádzajú v prezentácii

Hlavnú čas� okna vypĺňa obrazovka prezentácie. Prostredie poskytujepoužívate�ovi základnú prácu s prezentáciou a jej štruktúrou. Zabezpečuje tvorbunových prezentácii, načítanie existujúcich prezentácii a ich úpravu. Pomocoukomponent, ktoré je možné vklada� do obrazovky prezentácie je možné upravova�vzh�ad samotnej prezentácie. Výsledkom práce v prostredí je prezentáciav pracovnej podobe, ktorú �alej spracováva konverzia prezentácie do výstupu.


Prostredie pre tvorbuprezentácie – editor

Konverzný modul

Prezentácia

Konverzia prezentácie na výstupný formát

Podstatou modulu je konvertova� existujúcu pracovnú prezentáciu do výslednejpodoby. Ide o samostatný modul, ktorý je možno nahradi� a zmeni� tak výstupprostredia pre tvorbu prezentácii. Zabezpečí sa tak modulárnos� prezentácie.Pretože zadanie si vyžaduje výstup do formátu podporovaného dostupnýmiprehliadačmi, tento modul zabezpečuje jeho konverziu do formátu HTML.Tvorca prezentácie môže meni� iba zobrazované lišty vo výstupnej prezentácii.Prezentácia bude tvorená dvomi základnými čas�ami. Pretože ide o formát HTML,ide o rámce (frames). Pevnou súčas�ou bude samotné okno prezentácie, ktorébolo vytvárané v prostredí na tvorbu prezentácie. Ďalšie okno je volite�né.V tomto okne je zobrazená celková štruktúra prezentácie. používate� ma takmožnos� pristupova� k �ubovo�nej časti prezentácie. Posledným rozšírením jemožnos� zakomponova� do okna prezentácie ovládanie, ktoré umožňujeprechádza� po prezentácií vo vopred určenom slede obrazoviek, tak ako ich určiltvorca prezentácie.

Prezentácia

Samotný model prezentácie je HTML stránka. Tento modul je prístupnýprimárne študentovi, ktorý bude získava� informácie z prezentácie.

3.3.2 Komunikácia používateľov so systémom

Prostredie pre tvorbu prezentácie

Základom systému na tvorbu prezentácie je prostredie, v ktorom je možnévytvára� prezentáciu. Prostredie preto musí poskytova� používate�ovi dostatokfunkcií, ktoré zjednodušia jeho prácu. Prostredie obsahuje lišty, ktoré poskytujúzákladné funkcie pre používate�a.

Základom celej prezentácie sú obrazovky. Obrazovka predstavuje jednookno prezentácie, ktoré sa vo výslednej prezentácii zobrazí ako celok naobrazovke. V našom prípade ide o jednu stránku HTML, pretože výstupom jeprezentácia vo forme HTML. Na obrazovku je možné vklada� základnékomponenty typu text, obrázok, animácia a zvuk. Komponentom sa nedá určova�presné umiestnenie na obrazovke. Komponenty sa ukladajú pod seba v poradí,ako ich používate� vkladá na obrazovku. Samozrejmos�ou je možnos� presúvaniakomponent.

Komponenta text má nieko�ko odvodených typov. Základným typomtextovej komponenty je holý text. Ide o �ubovolný text, ktorý tvorí v prípadedištančného štúdia vysvet�ované učivo.

Ďalšia textová komponenta je linka. Ide o slovo, ktoré predstavuje odkazna inú čas� textu. Samozrejmos�ou je odkaz na text, ktorý sa nenachádza naobrazovke. Táto komponenta umožňuje vytvára� odkaz na pojmy, ktoré je dobréozrejmi� počas štúdia a používate� tak má prístup k ich vysvetleniu.

Všetky tieto pojmy je možné združova� do indexu, v ktorom sanachádzajú najdôležitejšie pojmy. Používate�, ktorý si prehliada prezentáciu mátak stály prístup k pojmom, aj v prípade, že sa v texte nenachádza odkaz na danýpojem.


Text je možné štruktúrova� pod�a nadpisov a je teda možné vytvára�kapitoly a podkapitoly. Pre každý nadpis je možné urči� úroveň. Túto štruktúrunadpisov je možné očíslova�. Číslovanie je automatické s jeho možnou ručnouúpravou.

Z nadpisov je možné generova� automatický obsah. Ten je možné vklada�do prezentácie ako automatickú komponentu.

Ďalšími komponentmi sú grafické komponenty obrázok, ktorý môžeslúži� aj ako odkaz a animácia. Obsah týchto komponent tvorí súbor animáciealebo obrázku, ktorý sa priradí danej komponente.

Jednotlivé typové komponenty sa nachádzajú na lište programu. Po ichpresunutí do obrazovky prezentácie je možné určova� ich vlastnosti.

Komponenty sa v na obrazovke dajú zobrazi� dvomi spôsobmi. Prvým spôsobom je zobrazenie malých obdĺžnikov. Po "dvojkliku" na

danú komponentu je možné meni� jej vlastnosti. V prípade obrázku a animácieide len o zadávanie súboru, ktorý bude tvori� obrázok, prípadne animáciu.Špeciálny prípad predstavuje text. V tomto prípade sa zobrazí editor textupodobný programom na úpravu textu ako Wordpad, kde používate� môže zadáva�text a meni� jeho vlastnosti: font, štýl písma, zarovnanie a podobne.

Druhý spôsob je zobrazenie komponent na obrazovke tak ako budúvyzera� v skutočnosti. Ide teda o nahradenie "malých obdĺžničkov" textom aobrázkami. Iba animácie zostanú zobrazené ako "biele obdĺžniky" bez obsahu.

Na bočnej lište vo vývojom prostredí je zoznam komponent, ktoré sanachádzajú v prezentácii. Je možné zvoli� dva základné poh�ady na tento zoznam.Prvým poh�adom je zobrazenie všetkých komponent, ktoré sa nachádzajú vprezentácii. Pri druhom zobrazení sa zobrazí len zoznam komponent, ktoré sanachádzajú na práve upravovanej obrazovke prezentácie. Komponenty budúzatriedené do skupín pod�a typových komponent, aby mal používate� preh�ad nadkomponentmi. Iba v prípade zobrazenia komponent v rámci jednej obrazovky jemožné zobrazenie komponent, tak ako idú po sebe v rámci obrazovky.

Jednotlivé obrazovky tvoria štruktúru zre�azenia. Pretože obrazovkynemôžu existova� ako samostatné jednotky je nutné vytvori� ich zre�azenie.Zre�azenie vytvára tvorca prezentácie a určuje v akom slede sa budú obrazovkyzobrazova� v prípade, že používate� použije ovládanie na presun v rámciprezentácie, ktoré je možné prida� k prezentácii. Táto štruktúra sa tiež zobrazí nabočnej strane výslednej prezentácie. Do tohto zre�azenia môže tvorca zasahova�.Prostredie mu umožní presúva� jednotlivé obrazovky v štruktúre prezentácie.

Okrem tohto zre�azenia je možné vytvori� ešte jedno zre�azenie. Ide ozre�azenie pomocou nadpisov. Toto zre�azenie nahradí zre�azenie na bočnej lištevo výslednej prezentácii. Zre�azenie, ktoré je možné prida� do prezentácie naprechod medzi obrazovkami však bude na�alej prechádza� prezentáciou nazáklade poradia obrazoviek, ako je definované v štruktúre obrazoviek.

Konverzný modul do HTML

Tento modul bude zabezpečova� konverziu prezentácií vytvorených v editore doformátu HTML pre možnos� prezerania prezentácie pomocou vo�ne dostupnýchinternetových prehliadačov. Nako�ko sa nepredpokladá ich neustála aktualizácia,


ke�že sa ráta s ich distribúciou aj na CD nosičoch, výsledná prezentácia budereprezentovaná ako statická HTML stránka, s prípadnou podporou JavaScript-u.

Konverzný modul bude samostatne stojaca jednotka, ktorá bude ma� seditorom spoločný iba dátový model pre vnútornú reprezentáciu prezentácie.Nebude poskytova� žiadne používate�ské prostredie, nako�ko všetky informáciepotrebné pre vykonanie konverzie mu budú poskytnuté pri jeho volaní editorom.

Z funkčného h�adiska sa dá rozdeli� na dve časti – Tvorenie štruktúryprezentácie a Tvorenie obrazoviek, tak ako to vidie� na nasledujúcom obrázku.

Obr. 6. Základná koncepcia konverzného modulu

Tvorenie štruktúry HTML prezentácie bude zabezpečova� načítanievstupných parametrov pre vykonanie konverzie, �alej vytvorenie HTMLdokumentov, ktoré budú tvori� základné rozhranie prezentácie pre zobrazeniejednotlivých obrazoviek a budú tiež umožňova� riadenie prezerania prezentácie.Taktiež bude zabezpečova� vytvorenie súborovej organizácie prezentácie tak, abyobsahovala všetky potrebné zdroje, pre správne zobrazenie jednotlivých častíprezentácie. To sa týka hlavne obrázkov, animácií a audiovizuálnych ukážok, ktorévo všeobecnosti môžu by� počas tvorby prezentácie v editore umiestnené na�ubovolnom mieste. Takto vznikne ucelená forma, ktorá je pripravená naprípadnú distribúciu pomocou elektronických nosičov, ako Internet a CDmédium.

Tvorenie obrazoviek bude zabezpečova� preklad obrazoviek z vnútornejreprezentácie editora na HTML dokumenty. V základe sa budú rozoznáva� dvatypy obrazoviek a to obrazovky vytvorené používate�om, vyskladané z editoromponúkaných komponent a obrazovky, ktoré sa budú tvori� automaticky až prisamotnom preklade ako napríklad zoznam obrázkov, index dôležitých pojmova iné.

3.3.3 Koncepcia návrhu z implementačného hľadiska

Z implementačného h�adiska bude aplikácia realizovaná modulovo a budepozostáva� z dvoch modulov. Tieto dva moduly vytvárajú aplikáciu, ktorápredstavuje konkrétne riešenie navrhovaného softvérového systému.


Vstup z návrhovéhosystému

Tvorenie štruktúryHTML prezentácie

Tvorenie obrazoviek

Základným modulom je prostredie pre tvorbu prezentácie, ktorépredstavuje hlavný program. Zabezpečuje používate�ovi vizuálnu tvorbuprezentácie.

Druhú čas� tvorí používate�ská knižnica, ktorá bude realizovaná akosúbor typu DLL. V súboroch DLL sa nachádzajú funkcie, ktoré zabezpečujúkonverziu prezentácie z návrhovej formy do výstupnej HTML prezentácie.

Prednos�ou takto navrhnutého riešenia je to, že sa dá ponaprogramovaní modulov DLL realizova� �ubovo�ný formát výstupnej prezentácie.

3.4 Prezentácia

Prvá zo šablón formátovania prezentácie bude obsahova� predpis preformátovanie všetkých prvkov prezentácie. Ostatné môžu by� jednoduchšie,pričom sa zoh�adnia požiadavky kladené na špecifické druhy prezentácií.

Základná a asi najpoužívanejšia koncepcia formátovania používate�skéhorozhrania prezentácie vychádza z rozdelenia plochy obrazovky do piatich častí:titulného pruhu, pruhu so štruktúrou obsahu, hlavného okna prezentácie,navigačného pruhu a okrajov.

Titulný pruh bude obsahova� informácie o názve prezentácie, a autoroch.Pruh so štruktúrou obsahu bude obsahova� stromovú štruktúru

prezentácie s možnos�ou zbali� a rozbali� jednotlivé vetvy. Bude obsahova� triúrovne nadpisov. Po kliknutí na nadpis v nej sa v hlavnom okne prezentácieobjaví príslušná čas� textu.

Hlavné okno prezentácie bude ma� posuvník vo zvislom smere.Navigačný pruh bude obsahova� tlačidlá pre pohyb v prezentácii na

zvolenej úrovni vpred a vzad, o úroveň vyššie a pre presun na začiatokprezentácie.


3.5 Model funkcií

V tejto kapitole sa budeme venova� funkcionálnemu modelu vytváranéhosoftvérového systému. Berúc do úvahy rozsah vytváraného systému sa sústredímeiba na diagram tokov údajov (DFD). V DFD diagrame sa dajú identifikova�niektoré samostatné bloky (procesy), v ktorých prebieha spracovanie informácií.Tieto budú slúži� ako základ architektúry systému. Načrtnutá je štruktúra systémuaž do druhej úrovne. Podrobnému opisu procesov druhej úrovne sa budemevenova� v kapitole podrobný návrh systému. V DFD sme identifikovalinasledujúce komponenty:

3.5.1 Externé entity

Softvérový systém je používaný dvoma externými entitami:– [E01] Tvorca prezentácie – používate� systému, ktorý vytvára, prípadne

modifikuje prezentáciu. Má k dispozícii všetky nástroje potrebné navykonanie funkcií, ktoré boli opísané v katalógu požiadaviek (kap. 2.1).Ďalšie podrobnosti vi� kap. 3.2.1.

– [E02] Študent prezentácie – používate�, ktorému je určený finálny výstupsystému – prezentácia. Ďalšie podrobnosti vi� kap. 3.2.2.

3.5.2 Úložiská údajov

Po analýze kap. 3.3 boli v systéme identifikované nasledujúce úložiská údajov: – [D1] Projekty – obsahuje kompletnú informáciu o celom projekte.

V dohodnutom formáte sú tu uložené informácie z dátových úložísk D3,D4 a D5. Bude pritom uložený v samostatnom súbore a dá sa pod�apotreby načíta� spä� do editora prezentácie alebo môže by� použitý nakonverziu do formy vhodnej na prezentáciu (napr. do HTML pomocoukonverzného modulu).

– [D2] Šablóny – obsahuje informácie o formátovaní všetkých objektov, naktoré môže by� dané formátovanie použité (napr. odsadenie textu,farba…). Toto umožňuje doda� celej prezentácii jednotný vzh�ad aprispie� tak k jej čitate�nosti.

– [D3] Komponenty – hlavné úložisko celého systému. Obsahuje všetkykomponenty, ktoré sa vyskytujú v projekte vrátane ich atribútov.Komponenty môžu by� rôznych typov, napr. text, obrázok, linka… Ďalšiepodrobnosti o komponentoch vi� kap. 3.1.3.

– [D4] Obrazovky – na tomto mieste sú uložené všetky obrazovky použitév projekte, vrátane ich atribútov a vzájomného prepojenia. Predstavujúzáklad pre HTML obrazovky výslednej prezentácie.

– [D5] Štruktúra nadpisov – obsahuje stromovú štruktúru nadpisov(nadpisy sú taktiež komponenty a sú uložené v D3). Určuje celkovúštruktúru prezentácie a je z nej odvodený aj obsah prezentácie.

– [D6] Komponenty a [D7] Obrazovky – predstavujú prúd údajov potrebnýna vytvorenie výslednej HTML prezentácie, sú odvodené z úložiska D1.Formálne sú zhodné z úložiskami D3 a D4, ale sú používané inýmprocesom, a preto obsahujú navyše údaje potrebné na HTML konverziu


(vi� kap. 3.3.2). Ak by bol použitý iný konverzný modul (napr. do PDF),mali by tieto úložiská úplne iný charakter ako D3 a D4.

– [D7] CSS šablóny – sú použité na formátovanie výslednej HTMLprezentácie. Sú vyextrahované z úložiska D1 vytváraním množínkomponentov s rovnakým výsledným formátovaním. Následne sú CSSšablóny aplikované na HTML výstup.

3.5.3 Procesy

V DFD diagrame sme identifikovali na základe rozboru kap. 3 nasledujúceprocesy:

(1) Editor prezentácie – Hlavný proces ktorý vytvára a modifikuje vytváranúprezentáciu. Umožňuje tvorcovi prezentácie manipuláciu s projektom,ktorý je aj graficky znázornený na ploche. Viac sa o editore prezentáciedozviete z kap. 3.1. Z funkčného h�adiska je možné rozdeli� editor natieto procesy:(1.1) Správa šablón – proces na základe pokynov tvorcu prezentácia

manipulije so šablónami. Umožňuje ich vytváranie, modifikáciu,uloženie a načítanie šablón.

(1.2) Správa komponentov – proces s najvyššou prioritou, riadi všetkypožiadavky spojené s komponentami – pridávanie, modifikáciua ich odoberanie z projektu. Zároveň modifikuje komponentypod�a priložených šablón. Stará sa o konzistenciu a správneradenie konponentov do úložiska údajov D3.

(1.3) Správa obrazoviek – proces koordinujúci vytváranie a radenieobrazoviek pod�a pokynov tvorcu prezentácie. Zabezpečuje taktiežprira�ovanie komponentov na dané obrazovky.

(1.4) Správa nadpisov – interný proces, ktorý sa stará o konzistenciustromovej štruktúry nadpisov. Automaticky modifikuje číslovaniea úrovne nadpisov pri pridávaní nových kapitol do prezentácie.Zo získaných informácií vytvára strom nadpisov, ktorý slúži nagenerovanie obsahu ako aj na uchovanie štruktúry prezentácie.

(1.5) Správa projektov – Zabezpečuje rozhranie s diskovým subsystémompočítača. Zhromaž�uje všetky informácie o stave projektu a ukladáich do úložiska údajov D1. Následne môže z D1 spätne načíta�uložený stav projektu.

(2) Konverzný modul – zabezpečuje konverziu prezentácií vytvorenýchv editore prezentácie do formátu HTML. Výsledný produkt bude potomdostupný študentovi prezentácie. Vnútorne je členený z dvoch procesov.(2.1) Interpretátor údajov – zabezpečuje prevod projektu do stavu

vhodného na vykonanie HTML konverzie. Vytvára dátové toky,ktoré tvoria základ obrazoviek a komponentov analýzou dátovéhoúložiska D1. Zabezpečuje taktiež vytvorenie CSS šablón.

(2.2) Tvorenie obrazoviek – vykonáva samotný prevod do HTML. Vytvárazoznamy použitých komponentov, index, obsah a dodávaprezentácii pomocou CSS šablón jednotný vzh�ad. Pridáva taktiežprvky na ovládanie prezentácie.


3.5.4 Použitá notácia

Obr. č. 8. Prvá úroveň DFD diagramu


– externá entita

– proces (elementárny)

– úložisko údajov

– tok údajov

��

��

��

��

�

��

��

��

�

��

��

��

�

��

�� !�"�

�#�� !�!��$�#�%��

�� !�� !�

Obr. č. 9. Druhá úroveň DFD diagramu – Konverzný modul

Obr. č. 10. Druhá úroveň DFD diagramu – Editor prezentácie


�&��#�� !"

�'(

)�� #�� !

�'�

)�� !��

�'&

)��

�

�'�

)�� $�#�%�

��

��

�(��"��#�%�"

�'*

)�� !��

�

�� !�"

�*��!�+��

�

�#�� !�!��$�#�%��

�$�#�%��$�#�%��

!�� #�� !�

�#�� !�!��!��

��

�� !�

�� !�"

�'�

��+��

�

�,��-))�$�#�%�"�.��#�� !"�/��"

�'�

�

� ��#�� !

��

��

�

��

�� !�

!��#�� !�

�-))�$�#�%��

�-))�$�#�%��!��#�� !�

3.6 Logický model údajov

Táto podkapitola sa zaoberá návrhom logického modelu údajov vyvíjanéhosystému. Rozhodli sme sa poskytnú� konceptuálny náh�ad na údaje v systémea preto predkladáme konceptuálny diagram, ktorý má znázorni� základné vz�ahymedzi údajovými entitami. Na tejto úrovni abstrakcie sa nezaoberáme atribútamiani metódami, našim cie�om je len predstavi� vz�ahy medzi údajmi. Obr. č. 11zobrazuje diagram tohto modelu. Pri návrhu sme použili bežné technikytypovania, generalizácie a agregácie na vyjadrenie vz�ahov medzi údajmi.Z dôvodov preh�adnosti sme do diagramu neuviedli názvy vz�ahov, ktorévyplývajú z použitej notácie a podrobne ich opisujeme pri popise údajových entít.

3.6.1 Diagram modelu údajov

Použitá notácia


Názoventity Vyjadrenie údajovej entity s jej názvom.

Vz�ah medzi entitami.Možná kardinalita vz�ahu:

n – môže ma� vz�ah k 0 až viacerým prvkom,1 – má vz�ah iba k jednej inštancii entity,0..1 – nemá vz�ah k žiadnej alebo iba jednej

inštancii entity.

Vz�ah generalizácie.

Vz�ah agregácie.

Obr. č. 11. Diagram logického modelu údajov

3.6.2 Údajové entity

Prezentácia – Entita reprezentuje údaj samotnej prezentácie. Je to komplexnévyjadrenie súhrnných informácií o dokumente, ktorý je výsledkom vytváranéhosystému. Vo všeobecnosti uvažujeme, že Prezentácia môže pozostáva� z Kapitol az Obrazoviek. Takáto koncepcia umožňuje členenie dokumentu pod�a kapitol avytvori� tak bežnú hierarchiu. Typické použitie tohto prístupu je pre písanieskrípt, učebných textov a pod. Členenie pod�a obrazoviek umožňujeprepracovanejšie a hlavne univerzálnejšie riešenia pre používate�a. Takýmtoprístupom môže používate� jednoducho vytvori� dokumenty typu elektronickénápovedy a pod.

Obrazovka – Reprezentuje objekt, ktorý zodpovedá jednej stránke nazobrazenie. To znamená, že obsah obrazovky sa zobrazuje naraz na obrazovkepočítača. Vz�ah agregácie pri tejto entite vyjadruje hierarchické členenieobrazoviek. Jedna obrazovka pozostáva z elementárnych prvkov zvanékomponenty.

Komponenta – Ide o údaj, ktorý reprezentuje element na obrazovke.Takýmto elementom môže by� Nadpis (text reprezentujúci názov kapitoly,podkapitoly, článku, resp. nižšie úrovne), Text (štandardný text), Obrázok(statický grafický objekt), Linka (odkaz na iný údaj v prezentácii), Animácia


Prezent á cia

Obrazovka

Komponenta

Nadpis

TypNadpisu

Kapitola Šablóna

Text

Typ Textu

Obrázok

TypObrázku

Linka

Typ Linky

Animácia

TypAnimácie

Zvuk

Typ Zvuku

ŠtýlNadpisu

Štýl Textu

Štýl Linky

ŠtýlObrázku

1

1

n

n

n

n

nnn

1

1

1

10..1

0..1

0..1

0..1 nn n

1

n1

n1

n1

n1

n1

n1

n0..1

0..1

1

n

ŠtýlAnimácie

Štýl Zvuku

nn

1

1

(dynamický grafický objekt), Zvuk (zvukový objekt). Komponenty sú v rámciobrazovky zre�azené tak, ako za sebou nasledujú, čo je vyjadrené vz�ahom. EntitaKomponenta generalizuje entity Nadpis, Text, Obrázok, Linka, Animácia a Zvuk.Naviac každá z generalizovaných entít má svoj typ, ktorý vyjadruje vlastnostientity. Entity Nadpis a Text sú špecializované vz�ahom z typmi šablóny Štýlnadpisu a Štýl textu.

Kapitola – Táto entita vyjadruje kontext údajov spojených s kapitolou vrámci prezentácie. Ako sme spomenuli pri entite Prezentácia, prezentácia môžepozostáva� z nieko�kých kapitol. Táto entita vyjadruje hierarchické členeniekapitol so vz�ahom na nadpis kapitoly.

Šablóna – Reprezentuje údaj o predrobených šablónach aplikovate�nýchna obrazovku. Šablóna je predpis, akým štýlom majú by� zobrazené nadpisy,textu, pozadia prezentácie a podobne. Preto má táto entita vz�ahy s rôznymištýlmi. Samotné štýlu potom špecializujú typy jednotlivých komponent (vdiagrame je naznačená iba špecializácia textu a nadpisu kvôli preh�adnostidiagramu), tz. predpisujú typ pre konkrétnu komponentu.

Nadpis – Ide o základnú komponentu označujúcu kapitolu aleboobrazovku. Nadpis môže by� v priamom vz�ahu s kapitolou a ako taký ju definuje.Naopak, každá kapitola môže by� definovaná nadpisom, ale nie je to nutnos�.Obrazovky nemajú priamy vz�ah s nadpisom, ale môžu nadpis obsahova�.

Text – Ide o základnú komponentu prezentácie. Obsahuje textové pole�ubovolnej ve�kosti. Typ tejto komponenty môže by� druh písma, ve�kos� písma,farba písma, okraje a pod.

Obrázok – Ide o súbor s grafickým zobrazením. Typ obrázku sa v�ahujepredovšetkým na jeho formát, ale aj rozmery a pod.

Linka – Ide o odkaz prepájajúci rôzne časti textu v rámci prezentácie,alebo odkaz na index prezentácie (zoznam k�účových slov), alebo odkaz na inýdokument (dokument mimo prezentácie). Typy linky sa vz�ahuje na tietomožnosti a na rôzne druhy formátovania ako sú farba, ve�kos� a pod.

Animácia – Ide o súbor s dynamickým grafickým objektom. Typanimácie môže by� podobne ako pri obrázku jej rozmery, formát a pod.

Zvuk – Ide o odkaz na súbor so zvukovým záznamom. Typ zvuku hovorío formáte zvukového záznamu.

3.7 Návrh šablón

Cie�om návrhu šablón je vytvori� súbor napísaný v jazyku CSS2, ktorý dovolíopísa� základnú množinu elementov použitých pri značkovaní textu látkyprezentácie. Vzh�adom na to, že konkurenčný tím je postavený pred rovnakúúlohu, a na možnos� zdie�ania látky prezentácie medzi oboma tímami sme sarozhodli kooperova� s jeho členmi na vytvorení jednotého predpisu preformátovanie prezentácie. Okrem možnosti zdie�ania obsahu, formy alebo oboch,by táto spolupráca mala prinies� aj zvýšenie kvality návrhu, ke�že sa zvýšikontrola pri používaní týchto predpisov. Proces návrhu prebieha v úzkom súvises jeho implementáciou a ešte nie je ukončený, preto je potrebné prezentovanévýsledky bra� s oh�adom na túto skutočnos�.


Jazyk CSS2 dovo�uje opísa� ve�mi širokú množinu elementov a umožňujerôzne spôsoby výberu týchto elementov. Preto je potrebné definova� zvládnute�núpodmnožinu elementov, ktorá by najlepšie vystihovala potreby tvorbymultimediálnej prezentácie obsahu predmetu na odbore Informatika.

3.7.1 Aktuálny zoznam elementov

Tento zoznam obsahuje elementy HTML, ktorých použitie je dohodnutés konkurenčným tímom a ktoré sú použité v prezentácii časti látky predmetuArchitektúra počítačov. Zoznam sa pravdepodobne ešte rozšíri, avšak tu uvedenéelementy by sa mali zachova�.

Element OpisBODY Reprezentuje pozadie, na ktorom je umiestnený všetok obsah

dokumentu.P Všeobecný odstavec. Základný text.P.formula Odstavec obsahujúci vzorec alebo iný obsah, ktorý má by�

odsadený z�ava ale nemá by� uvedený značkou.P.noteheader Odstavec obsahujúci text „Poznámka“. Má menší význam

ako nadpis štvrtej úrovne.P.note Odstavec obsahujúci text poznámky. Poznámka by mala by�

zobrazená písmom s menšou ve�kos�ou ako je základný textprezentácie.

P.object Odstavec obsahujúci vložený objekt. Napr. obrázok aleboanimáciu.

P.objecttext Odstavec obsahujúci opis obrázku. Napr. „Obr. č. x. …“PRE Odstavec obsahujúci text príkladu, výpis programu alebo iný

text, ktorý je potrebné zobrazi� fontom s pevnou šírkouznaku.

P.code Detto s tým rozdielom, že ide o normálny odstavec a teda jemožné použi� �alšie formátovanie ako úvodzovky, indexy,mocniny, zvýraznenia a pod.

SUB Dolný index. Používa sa najmä v matematických výrazoch.SUP Horný index. Detto.EM Bežné zvýraznenie. Používa sa všade, kde je potrebné vyznači�

čas� textu. Zvyčajne sa zobrazí ako kurzíva.STRONG Zvláštne zvýraznenie. Používa sa, ak je potrebné upozorni� na

zvláš� dôležitú čas� textu. Je potrebné používa� ho s mierou.Zvyčajne sa zobrazí ako polotučné písmo.

VAR Označenie premennej.IMG Obrázok.A Odkaz.H1 Nadpis kapitoly.H2 Nadpis podkapitoly.H3 Nadpis článku.H4 Nadpis štvrtej úrovne.UL Nečíslovaný zoznam.OL Číslovaný zoznam.


LI Položka zoznamu.DL Definícia.DT Objekt definície.DD Text definície.TABLE Tabu�ka.


4 Prototypovanie4.1 Ciele prototypovania

Táto čas� dokumentácie sa zaoberá prototypovaním vytváraného systému.Prototyp sme sa rozhodli vytvori� z dôvodov predvedenia niektorých požiadaviek,a teda predovšetkým pre spoluprácu so zadávate�om projektu. To znamená, že sazameriame na implementáciu jasných a zrejmých požiadaviek, s ktorými nie súžiadne pochybnosti vzh�adom na predstavy zadávate�a. Radi by sme poznamenali,že k nižšie uvedeným cie�om prototypovania sme dospeli po konzultácii sozadávate�om projektu.

Cie�om prototypovania je vytvori� jednoduché ovládacie prostredie, ktoréby umožnilo vytvori� základnú štruktúru prezentácie, umožnilo by editova� text avklada� niektoré základné komponenty ako obrázky, animácie a pod. Prototyp máposkytnú� preh�ad o vložených komponentách, poskytnú� zoznam týchtokomponent a zoznam obrazoviek. Dôležité je, aby systém vedel prekonvertova�špecifikáciu prezentácie do univerzálneho jazyka, aby bolo možné výslednúprezentáciu prezera� na �ubovolnom počítači. Nie je požiadavka, aby totoprostredie malo ucelenú formu, ktorá by bola použitá aj vo finálnom produkte.Je potrebné, aby toto prostredie jednoduchým spôsobom predviedlo príslušnépožiadavky. Nasleduje zoznam požiadaviek, ktoré má prototyp predvies�(požiadavky sú uvádzané s číslom zhodným s ID uvedeným v katalógupožiadaviek [vi� 2.1]):

1.1 Vytvorenie novej prezentácie1.2 Uloženie prezentácie1.3 Otvorenie existujúcej prezentácie.

Tieto požiadavky musia by� implementované, aby bolo umožnenézákladné manipulovanie s prezentáciou.

1.8.1 Export do HTML.Táto požiadavka musí by� implementovaná kvôli predvedeniumožností prekladania špecifikácie prezentácie do univerzálnehojazyka, pomocou ktorého je prezentácia prezerate�ná na�ubovolnom počítači. Túto požiadavku realizuje tzv. konverznáutilita.

2.1 Šablóny vzh�adu prezentácie. Je potrebné implementova� jednu šablónu, ktorá by bolaaplikovate�ná na prezentáciu a predpísala by jej vzh�ad.

3.1 Pridávanie obrazoviek.3.2 Preusporiadanie obrazoviek.3.3 Odstraňovanie obrazoviek.

Tieto požiadavky je potrebné realizova�, aby bolo zadávate�oviumožnené vytvára� základnú štruktúru prezentácie a prípadne ju ajmeni�.

4.1.1.1 Vkladanie obyčajného textu.4.1.1.2 Vkladanie nadpisu.

Tieto požiadavky majú poskytnú� základné komponenty prevytváranie prezentácie.


4.1.2 Vkladanie obrázkových komponent.4.1.3 Vkladanie animačných komponent.

Je potrebné poskytnú� už v prototype väčší komfort pre používate�aa umožni� mu do prezentácie vloži� obrázok alebo animáciu

6.1 Nové komponenty: Používate�ovi bude poskytnutý zoznamkomponent, z ktorého bude môc� jednoducho vybra� žiadanúkomponentu a použi� ju v prezentácii.

6.4 Obrazovková štruktúra prezentácie: Je potrebné, aby mal používate�k dispozícii preh�ad komponent, z ktorých pozostáva aktuálnaprezentácia.

1.0.0.1.1 Požiadavka na počítač tvorcu prezentácie.1.0.0.1.2 Požiadavka na počítač študenta prezentácie.

Samozrejme už v tejto fáze je potrebné, aby prototyp spĺňalsystémové požiadavky na náročnos� vyžadovaného hardvéru.

4.2 Vyhodnotenie prototypovania (systém)

Vyhodnotenie prototypu možno rozdeli� do dvoch základných skupín, ktorévychádzajú z návrhu softvérového systému.

4.2.1 Prostredie pre tvorbu prezentácii

Základom bola práca užívate�a so systémom a grafické prostredie. Navrhovanérozloženie základných prvkov na obrazovke, ktoré bude použité vo výslednejaplikácii, plne vyhovuje komfortnej práci. Prototyp umožňuje vkladanie trochrôznych druhov komponent na obrazovku – text, nadpis, obrázok. Obrázok a textsa vkladá ako cesta k súboru na disku. Nadpis je možné vytvára� v prostredíprototypu. Text a obrázok je možné upravova� len v externom editore. Výslednáaplikácia bude podporova� viacej komponent, ale výber bol zúžený len na tútomnožinu kvôli možnostiam prekladača realizovaného v prototype.

Text možno upravova� priamo v prototype. Ďalšia možnos�, ktorúprototyp podporuje, je vytvori� nový textový súbor a prida� ho priamo doprezentácie. Tento spôsob načrtol základné požiadavky pri úprave komponenty,ktoré sa bude da� využi� vo výslednej aplikácii – jednoduchos� prístupu k textu,jeho úprava a aktualizovanie komponenty v prezentácii.

Jednoduchos� práce s prototypom je možné zlepši� zadefinovanímklávesových skratiek pre najčastejšie používané funkcie, prípadne pridanietlačidiel, ktoré zastúpia najčastejšie používané funkcie.

4.2.2 Tvorba výstupnej prezentácie

Návrh prototypu predpokladal možnos� vytvorenia len jednej obrazovkyprezentácie. Po zadefinovaní základnej štruktúry pre prezentáciu bol návrhrozšírený na podporu viacerých obrazoviek. Odsimulovali sme si aj rozhranie,ktoré bude použité v hlavnej aplikácii pre komunikáciu s používate�skouknižnicou. Na simuláciu sme použili jedinú funkciu, ktorej vstupom je vytvorenáštruktúra obsahujúca prezentáciu. Funkcia predstavujúca používate�skú knižnicupotom z informácii obsiahnutých v štruktúre vytvorila výslednú prezentáciu.


Pri realizácii bola tiež odskúšaná práca prekladača. Ten vytvára zo štruktúryvýsledné HTML dokumenty, ktoré potom pospája pomocou jednej stránky dovýslednej prezentácie. Z h�adiska toho, že nebolo možné implementova� všetkymožnosti prekladača, bol výber komponent zúžený na tri.

4.3 Vyhodnotenie prototypovania (prezentácia)

Ke�že prototyp prostredia pre tvorbu prezentácií nemôže a ani nemá za cie�obsiahnu� všetky potrebné elementy HTML, bolo potrebné vytvori� dokument,ktorý by umožnil návrh a odladenie šablóny formátovania. Za týmto účelom bolaupravená čas� textu skrípt z danej problematiky. Do tohto dokumentu bolapridaná sekcia, ktorá by mala obsahova� všetky navrhnuté elementy a takdemonštrova� vlastnosti šablóny.


5 Podrobný NávrhKoncepcia návrhu systému priblížila spôsob práce a prístupu používate�ak systému. Detailnejší návrh jednotlivých častí systému poskytujú nasledujúcekapitoly. Zamerali sme sa na opis najdôležitejších vlastností systému. Niektorédetaily boli vynechané.

Základom systému je editor prezentácie.

5.1 Editor prezentácie

Základný modul aplikácie. Jeho úlohou je správa štruktúry celej prezentácie.Základom celej prezentácie sú komponenty umiestnené na obrazovkách.Obrazovky sú organizované pod�a následnosti.

Komponenty predstavujú vstup do systému. Text, obrázok, animáciaa zvuk sú komponenty uložené v externých súboroch. Sú podporovanénajčastejšie používane typy súborov. Ostatné komponenty – nadpis a odkaz sazadávajú priamo cez rozhranie aplikácie. Komponenty vstupujú do aplikácie cezmodul načítanie komponent. Ten na základe typu komponentu zabezpečínačítanie externých súborov v prípade, ak sú dáta komponenty uložené v súbore,alebo priame načítanie cez rozhranie v prípade odkazu a nadpisu. Externé súborysa automaticky kopírujú do adresára projektu.

Komponenty majú svoje vlastnosti. Napríklad font, zarovnanie, ve�kos�písma u textovej komponenty. Všetky tieto vlastnosti sú uložené v pamätikomponentov projektu. Pamä� komponentov obsahuje len vlastnostikomponentov a odkaz na súbor, kde sa nachádzajú dáta. Je tým zníženánáročnos� na pamä�. Text nadpisu a odkazu je vlastnos� komponenty, nie sú tedauložené na disku.

Pretože vlastnosti komponentov je potrebné upravova� aj neskôr cezrozhranie programu je tu modul správa vlastností komponent. Tá umožňujezmenu vlastností jednotlivých komponent. Pre textové komponenty jeimplementovaný jednoduchý textový editor, ktorý umožňuje úpravu textukomponenty.

Komponenty sú umiestňované na obrazovky. Obrazovky potom tvoriaprezentáciu. Po načítaní komponenty a jej uložení do pamäti komponent sakomponent umiestni na niektorú obrazovku, pod�a potrieb používate�a.Túto činnos� zabezpečuje modul správa štruktúry prezentácie. Jej úlohou jeposkytnú� používate�ovi možnos� meni� poradie komponent a obrazoviekprezentácie. Takto vzniknutá štruktúra prezentácie je uložená v moduleprezentácia.

Prezentácia je vlastne zre�azenie obrazoviek. Na každej obrazovkesa potom nachádza zre�azenie komponent. Komponenty na obrazovkesú určované len svojím poradovým číslom v pamäti komponent. Je tak možnépoveda�, že sú to len odkazy na komponenty uložené v pamäti komponent.

Prezentáciu je potrebné uloži� do výstupného súboru pre neskoršiepoužitie. Túto činnos� zabezpečuje v/v modul prezentácie. Jeho úloha je tedaukladanie a opätovné načítanie súboru prezentácie. Poskytuje však tiež pridanie


prezentácie k už existujúcej prezentácii. Je tak možné spája� viaceré prezentáciedo jednej.

Prezentácia je nakoniec preložená pomocou externého modulu dll(konverzná knižnica) do výslednej prezentácie. Konverzná knižnica podporujeniektoré nastavenia, informácie o sebe a možnos� náh�adu prezentácie. Tietofunkcie sú prístupné pomocou modulu rozhranie dll.

Posledná funkcia, ktorú poskytuje konverzná knižnica je konverziaprezentácie. Pri tomto sa predá prezentácia konverznej knižnici, ktorá vykoná jejpreklad.

Obr. 12. DFD editora prezentácie

5.2 Konverzná utilita

Konverzná utilita je určená pre exportovanie projektu prezentácie, vytvorenejv editačnom programe, do �ubovolného formátu, ktorý je definovaný príslušnoukonverznou utilitou. Je reprezentovaná ako používate�ská knižnica, dynamickypripájaná k editoru (DLL – Dynamic-Link Library). Takýmto spôsobomje zabezpečená univerzálnos� editora a možnos� jeho rozšírenia o �ubovo�ný početformátov určených pre export projektu prezentácie.


5.2.1 Vnútorná štruktúra konverznej utility

Na obrazku 2. sa nachádza základná koncepcia konverznej utility, ktorá zachytávaspoločne črty pre �ubovo�nú z nich. Poskytuje nasledovné funkcie:

Interpret údajov

Predstavuje načítanie projektu prezentácie zo vstupného súboru do údajovýchštruktúr, ktoré sú zhodné s údajovými štruktúrami editora pre uchovávanieprojektu prezentácie.

Obr. 13. DFD používate�skej knižnice


Konvertovanie projektu prezentácie

Táto funkcia zabezpečuje samotné konvertovanie projektu prezentáciedo definovaného formátu, od ktorého taktiež závisí aj presný spôsob tejtokonverzie. Výsledok konverzie je súbor, alebo skupina súborov, ktoré v diagramepredstavuje úložisko prezentácia.

Zobrazenie prezentácie

Zabezpečí zobrazenie prezentácie po vykonaní konvertovania, pre účelskontrolovania výsledku. Z dôvodu použitia �ubovo�ného exportného formátu,je nutné, aby konverzná utilita samotná, definovala spôsob, akým sa prezentáciazobrazí po vykonaní konvertovania. Zobrazenie konvertovanej a uloženejprezentácie môže by� riešené interným prehliadačom, ktorý je súčas�ou konverznejutility, alebo pomocou externého prehliadača nainštalovaného na počítači,ktorý je definovaný explicitne programátorom alebo používate�om. Konečnériešenie zobrazenia je na slobodnej vôli programátora konverznej utility.Nako�ko zobrazenie prezentácie po vykonaní každého konvertovania môže by�rušivé, je možnos� túto funkciu obís� implementačne, alebo v rámci nastaveniakonverznej utility.

Nastavenie konverznej utility

Táto funkcia umožňuje vykona� nastavenie parametrov konverznej utility, ktorépriamo súvisia s konverziou, alebo so zobrazením prezentácie. Konkrétneparametre, ktoré bude možné nastavova�, závisia od typu konverznej utility.Nastavenie vykonáva tvorca projektu prezentácie prostredníctvom editora,pomocou ktorého bude možné funkciu nastavenia konverznej utility vyvola�.

5.2.2 Rozhranie konverznej utility

Nako�ko konverzná utilita bude môc� vykonáva� export do rozličných formátov,je nutné navrhnú� univerzálne rozhranie, ktoré umožní realizova� jej základnéfunkcie spolu s funkciami, ktoré sú nevyhnutné pre spoluprácu programus používate�skou knižnicou.

Identifikácia konverznej utility

Pomocou tohto rozhrania je možné, prenosom re�azca písmen, zisti� názovkonverznej utility, ktorý slúži na jednoznačné pomenovanie, pod ktorýmsa konverzná utilita bude v editori identifikova�.

Opis konverznej utility

Pomocou tohto rozhrania je možné, taktiež prenosom re�azcom písmen, zisti�stručný opis používate�skej knižnice, ktorý poskytuje základné informácieo používate�skej knižnici.


Konvertovanie projektu prezentácie

V tomto prípade je prenášaným údajom opä� re�azec písmen, ktorý definujeumiestnenie a názov súboru, v ktorom je projekt prezentácie uložený.To znamená, že pred vykonaním konvertovania je nutné projekt prezentácieuloži� na pevný disk alebo iné záznamové médium.

Náh�ad na projekt prezentácie

Toto rozhranie je prakticky totožné s rozhraním konvertovania projektuprezentácie, no dopĺňa ho o možnos� definovania časti projektu prezentácie,na ktorú sa náh�ad vytvára. Definovanie týchto častí je umožnené pomocou dvochceločíselných parametrov.

Nastavenie konverznej utility

Cez toto rozhranie sa neprenášajú žiadne údaje. Ide iba o volanie funkciekonverznej utility, ktorá umožní jej nastavenie priamym editovaním parametrovkonverznej utility. Toto riešenie je opodstatnené tým, že každá konverzná utilitamôže ma� vlastnú sadu parametrov pre nastavovanie, prípadne žiadne, a niejepreto možné vykonáva� nastavenie univerzálne pomocou editora a následnýmprenosom parametrov vo forme toku údajov.

5.3 Návrh konverznej utility do formátu HTML

Nako�ko cie�om projektu je vytvorenie webovej multimediálnej prezentácie,je navrhnutá konverzná utilita, ktorá zabezpečí konvertovanie projektu prezentáciedo statickej HTML stánky. Pre potreby formátovania vzh�adu stránky sú použitékaskádové štýly.

Základná koncepcia konverznej utility do formátu HTML(HTML konvertor) je totožná so základnou koncepciou uvedenou v kapitole 5.2.Nako�ko však ide o konkrétnu implementáciu, je nutné upresni� významyjednotlivých funkcií a opísa� detailnejšie ich funkciu.

5.3.1 Nastavenie konverznej utility

Parametre, ktoré je možné ovplyvňova� sú nasledovné:– výber externého prehliadača pre prezeranie prezentácie po skonvertovaní,

pričom je umožnené deaktivova� zobrazenie skonvertovanej prezentácie,alebo jej časti po vykonaní konverzie

– cesta k priečinku, do ktorého sa budú uklada� súbory vytváranépri tvorení náh�adu na určitú čas� prezentácie

– druh použitých kaskádových štýlov pre formátovanie obsahupoužívate�om vytvorených obrazoviek (predpripravené, špeciálne určenépre konvertovaný projekt prezentácie)

– nastavenie vzh�adu používate�ského rozhrania prezentácie,kde si používate� môže vybra� časti, ktoré budú tvori� používate�skérozhranie (nadpis prezentácie, obsah, navigačnú lištu) ako aj ich rozmer.


V prípade obsahu si môže ešte vybra� spôsob použitej technológiepre jeho vytvorenie (HTML, JavaScript). Pre potreby špecifikovaniaformátovania používate�ského rozhrania je možné vybra� súborkaskádových štýlov, v ktorom je definované jeho formátovanie nezávisleod formátovania používate�ských obrazoviek.

5.3.2 Konvertovanie projektu prezentácie

Na obrázku 3. je znázornený DFD funkcie, ktorá vykonáva samotnékonvertovanie projektu prezentácie do HTML stránky. Táto funkcia zabezpečujekonvertovanie projektu prezentácie do HTML stránky. Ako zdroj prekladu čerpáúdaje z úložísk Obrazovky, Komponenty a Štruktúra nadpisov, v ktorých súuložené všetky potrebné údaje o projekte prezentácie. Pre potreby riadeniakonverzie použije údaje z úložiska Nastavenie, v ktorom sú uložené všetkypotrebné parametre nastavené pomocou funkcie Nastavenie konverznej utility,určujúce spôsob konverzie. Výsledok konverzie predstavuje úložisko HTMLprezentácia, ktorého obsah je tvorený skupinou súborov (HTML dokumenty,súbory kaskádových štýlov, obrázky, animácie…), zaradené do viacerých adresárovpre väčšiu preh�adnos�i.

Obr. 14. DFD konvertovania projektu prezentácie do HTML

Z analýzy vychádzajúc poskytuje nasledovné funkcie, ktoré sú potrebnépre vykonanie konverzie a to v nasledovnom poradí:


Tvorenie CSS šablón

Ide o funkciu, ktorá zabezpečuje tvorbu dvoch nezávislých súborov kaskádovýchštýlov (*.CSS súbory) pre formátovanie používate�ského rozhrania a obrazoviek.

Pre potrebu formátovania vzh�adu používate�ského rozhrania sa používapredpripravený súbor kaskádových štýlov s pevným formátom, v ktorompoužívate� môže dodatočne meni� parametre jednotlivých štýlov.

Pre potrebu formátovania vzh�adu vytváraných obrazoviek sa používa bu�predpripravený, podobne ako pri používate�skom rozhraní, alebo generovanýkaskádový súbor. Obsah generovaného kaskádového súboru sa tvorí na základeinformácii získaných z nastavení jednotlivých komponent, ktoré tvoria obsahobrazoviek prezentácie.

Tvorenie používate�ského rozhrania prezentácie

Funkcia vytvorí HTML dokumenty, ktoré budú tvori� základ používate�skéhoprostredia HTML prezentácie. Ide o vytvorenie nasledovných častí:

– Štartovacia stránka – ktorá tvorí základ celej HTML prezentácie adefinuje rozmiestnenie jednotlivých prvkov rozhrania.

– Nadpis – slúži na zobrazenie názvu a prípadne autora prezentácie– Obsah – obsahuje obsah prezentácie tvorený z nadpisov umiestnených

v prezentácii. Pomocou neho je možná rýchla navigácia a pohyb pojednotlivých kapitolách prezentácie.

– Navigačná lišta – obsahuje tlačítka pre jednoduchý pohybpo obrazovkách. Pohyb je umožnený o jednu obrazovku vpred a vzada zobrazenie prvej obrazovky.

Tvorenie používate�ských obrazoviek

Je to najdôležitejšia funkcia, ktorá zabezpečuje konvertovanie obrazovieka komponentov z projektu prezentácie do HTML dokumentov a ich formátovaniezabezpečuje pomocou už vytvorených kaskádových štýlov. Aby sa zabezpečilamodulárnos� tejto funkcie, a umožnilo sa jednoduché dopĺňanie nových druhovkomponent, obsah obrazovky sa vytvára postupným konvertovaním jednotlivýchkomponent. Pre každú komponentu je tak určená samostatná konverzná funkcia,ktorých doplnením, alebo zmenením sa dajú jednoducho rozširova� možnostikonverznej utility.

Kopírovanie zdrojov

Táto funkcia zabezpečuje skopírovanie všetkých súborov (obrázky, animácie,odkazované dokumenty…) potrebných pre správne zobrazenie a fungovanieHTML prezentácie do adresárov prezentácie. Takýmto spôsobom sú všetkypotrebné súbory sústredené na jedno miesto, čo umožňuje jednoduchúmanipuláciu s vytvorenou prezentáciou, jej prípadné kopírovanie, alebodistribuovanie na CD-ROM nosičoch.


5.3.3 Zobrazenie prezentácie

Umožňuje zobrazenie prezentácie pomocou externého web prehliadača.Jeho výber je umožnený prostredníctvom funkcie nastavenia konverznej utility.

5.4 Formátovanie prezentácie

Táto čas� dokumentácie nadväzuje na kapitolu 3.7 a venuje sa opisu prvkovpoužívate�ského rozhrania prezentácie – titulného pruhu, navigačného pruhua pruhu s obsahom.

5.4.1 Titulný pruh

Titulný pruh plní orientačnú funkciu na najvyššej úrovni – prezentuje názovprezentácie a autora jej obsahu. Z rôznych dôvodov sa najčastejšie umiestňujena horný okraj priestoru pre prezentáciu.

Vzh�adom na to, že pri prezeraní prezentácie plochu obrazovky častozaberajú aj �alšie prvky (panel úloh a stavový riadok naspodu a titulný panel,panel ponuky, lišta s ikonami a prípadne �alšie hore), zmenšuje sa priestor presamotný obsah prezentácie vo vertikálnom smere. Naopak, požiadavkana rozumnú šírku riadkov vedie k uvolneniu okrajov tohto priestoru. Na základetýchto okolností boli vytvorené dve alternatívne riešenia umiestnenia titulnéhopruhu – zvyčajné (hore) a moderné (na pravom okraji umiestnené zvislo).

Pri použití prvého je potrebné minimalizova� jeho rozmery. V jehoprospech hrá to, že text môže by� priamo zapísaný v HTML. Druhý naopakumožňuje uvo�ni� priestor navrchu, avšak jeho obsah je potrebné vytvori�v grafickom editore a vloži� ako obrázok.

Bolo by ideálne, keby si používate� mohol zvoli�, ktoré umiestnenie a akýspôsob zadávania informácií mu vyhovuje.

5.4.2 Navigačný pruh

Navigačný pruh by mal pomáha� používate�ovi orientova� sa v prezentácii(napr. poskytnú� informáciu o pozícii v texte) a u�ahči� mu základný pohyb v jejobsahu (vpred, vzad, o úroveň vyššie).

Pri našom projekte sme sa rozhodli umiestni� navigačný pruh na spodnýokraj. Toto umiestnenie ako i rozhodnutie o minimalizácii ve�kosti navigačnýchprvkov (nezaberajú ani tretinu šírky pruhu) prirodzene vytvorilo priestorna umiestnenie informácie o vlastníkovi autorských práv k prezentácii.

Kvôli jednoduchosti a prenosite�nosti boli navigačné funkcie obmedzenéna odkazy umožňujúce presun na predchádzajúcu, nasledujúcu a prvú obrazovkuv rámci prezentácie. Tieto odkazy sú umiestnené v�avo a umiestnenie informácieo vlastníkovi autorských práv vpravo.


5.4.3 Pruh s obsahom

Významným pomocníkom pri orientácii a navigácii v prezentácii je obsah.Je dobré, ak je vždy poruke, ale. Čím je podrobnejší (a tým aj užitočnejší),tým je rozsiahlejší a znovu sú�aží o priestor s podávanou látkou.

Jeho dostupnos� je vyriešená tým, že je mu venovaný samostatný pruhumiestnený na�avo. Kompromisom medzi použite�nos�ou, podrobnos�oua zabraným priestorom bolo obmedzenie hĺbky zobrazovanej hierarchie na triúrovne. To znamená, že nadpisy štvrtej úrovne, ktoré namajú ani číslovanie,sa v obsahu nezobrazujú. Hierarchia je vystihnutá ve�kos�ou a rezom písmaa odsadením. Takže číslovanie, ktoré nie je kritické pre orientáciu a zaberánezanedbate�né miesto, bolo presunuté do popisiek, ktoré sa zobrazia pri krátkompodržaní ukazovate�a myši na položke.

Ďalším spôsobom ako spríjemni� prácu s obsahom je použitierozba�ovacieho stromu. Jeho vetvy sa rozbalia / zbalia pri kliknutí na symbol prednadpisom.

Po kliknutí na nadpis v obsahu je zobrazená v hlavnom priestoreprezentácie čas� látky začínajúca zvoleným nadpisom.


6 Implementácia6.1 Editor prezentácie

Základom celej aplikácie je štruktúra zre�azená vo�ná pamä� (ZVP).

6.1.1 Zreťazená voľná pamäť

Ide o obojsmerne zre�azenú pamä�, do ktorej je možné uloži� �ubovo�nú dátovúštruktúru. Poskytuje množstvo operácií, takže pri dedení nie je potrebnéimplementova� také ve�ké množstvo nových metód.

6.1.2 Dedené dátové štruktúry

Zo zre�azenej vo�nej pamäti sú potom odvodené ostatné dátové štruktúryv programe.

6.1.3 Štruktúra prezentácie

Prezentácia je využitie možnosti vklada� do ZVP �ubovolnú štruktúru. ZVPpredstavuje zoznam obrazoviek. Prvkom je obrazovka. Tá obsahuje zre�azeniekomponentov na obrazovke. Toto zre�azenie je tiež tvorené ZVP. Do jednotlivýchbuniek ZVP zre�azenia obrazoviek sa tak vkladá opä� ZVP zre�azeniekomponentov na obrazovke. Prvok zre�azenia komponentov je tvorený typomkomponentu a odkazom do pamäte komponentov. V nej sú uložené atribútyobrazoviek.

6.1.4 Pamäť komponentov

Pamä� komponentov je špeciálna štruktúra. V tomto prípade je celá ZVProzdelená na časti. Každá čas� je číslovaná od nuly. Jednotlivé časti sú použiténa ukladanie komponentov. Pridávanie komponentov je jednoduchá záležitos�.Stačí prida� komponent a priradi� jej prvé vo�né poradové číslo. Prvé vo�né,pretože ak sa zmaže komponent, ostatné komponenty si musia zachova� svojeporadové číslo. Vznikajú tak diery. A nové komponenty sa musia uklada� na prvévo�né miesto. Dôvod, prečo sa vznikajú tieto diery je v tom, že v štruktúreprezentácie sú uložené len odkazy do pamäti komponent. Ak by sa číslovanieposúvalo, musela by sa prečíslova� celá prezentácia.

6.2 Rozhranie konverznej utility

Rozhranie konverznej utility má za úlohu sprístupni� funkcie používate�skejknižnice. Zároveň presne definuje spôsob komunikácie medzi používate�skouknižnicou a programom, ktorý využíva jej funkcie. Pre zabezpečenie tejtokomunikácie sú definované nasledovné funkcie:


��

��

Funkcia, ktorá po zavolaní vráti znakový re�azec ukončený znakom ��,obsahujúci názov konverznej utility.

�� !��

Funkcia, ktorá po zavolaní vráti znakový re�azec ukončený znakom ��,obsahujúci popis konverznej utility.

��

��"!��

Funkcia, ktorá po zavolaní zobrazí konfiguračné okno, pomocou ktoréhoje možné nastavi� parametre konverznej utility.

�� #��$��

��%�&�'! ��(��(��)��

Funkcia, ktorá zabezpečí vytvorenie náh�adu na preložený projektprezentácie v definovanom formáte. Vstupom je znakový re�azecukončený znakom �� (��%�&�'! ��), ktorý obsahuje absolútnu cestuk projektovému súboru a dvojica celočíselných parametrov(��, ��)��), ktoré bližšie definujú čas� prezentácie, pre ktorú sa mánáh�ad vytvori�. Výstupom funkcie je dvojhodnotový príznak, ktorýurčuje, či bolo vytvorenie náh�adu na vybranú čas� prezentácie úspešnéalebo nie.

��

��%�&�'! ��

Funkcia, ktorá zabezpečí finálny preklad projektu prezentáciedo definovaného formátu. Vstupom je znakový re�azec ukončený znakomNULL (��%�&�'! ��), ktorý obsahuje absolútnu cestu k projektovémusúboru. Výstupom funkcie je dvojhodnotový príznak, ktorý určuje, či bolpreklad prezentácie úspešný alebo nie.

6.3 Konvertovanie projektu prezentáciedo formátu HTML

Finálny preklad ako aj vytváranie náh�adu prezentácie je v podstate rovnaké.Líšia sa iba v spôsobe adresovania zdrojov (obrázky, animácie, prípadne iné nietextové časti prezentácie) v jednotlivých HTML dokumentoch. V prípadefinálnej kompilácie sú všetky tieto zdroje nakopírované v poslednej fázekompilácie do adresárov vytváranej prezentácie a použijú sa referencie na taktoskopírované zdroje pomocou relatívnych adries. V prípade vytvárania náh�adu,


aby sa zamedzilo zbytočnému kopírovaniu niekedy objemných súborov,sa použijú referencie na zdroje uložené v projektových adresároch pomocouabsolútnych adries.

Pre účely procesu kompilácie projektu prezentácie sú implementovanénasledovné objekty:

�� – slúži ako hlavný objekt, ktorý v sebe združuje ostatné pomocnéobjekty. Obsahuje všetky potrebné parametre a metódy pre vytvorenieHTML prezentácie z údajov získaných z projektu prezentácie.

�'�� – slúži pre tvorbu súborov kaskádových štýlov a topredovšetkým v prípade tvorby explicitných kaskádových štýlov, kde saprezentácia formátuje presne pod�a používate�ského nastaveniajednotlivých komponentov.

�'�� – slúži ako preklenutie medzi vnútorným procesom kompiláciea používate�om. Nako�ko proces kompilácie je nezávislý od vývojovéhoprostredia, slúži tento objekt ako akási jednotná informačná štruktúra,do ktorej sa počas procesu kompilácie zapisuje jej stav, a metódy,ktoré slúžia pre správu používate�ského rozhrania konverznej utility,z nej tieto informácie môžu číta� a následne zobrazova�.

6.3.1 Tvorenie CSS šablón

Pre potrebu vytvárania kaskádových štýlov je implementovaná metóda��**��'�� , ktorá vytvorí obsah súborov kaskádových štýlova uloží ich do príslušných súborov.

Pre tvorbu obsahu kaskádového súboru pre používate�ské prostredie slúžimetóda �'�� **��'��+��, ktorá iba otvorísúbor kaskádových štýlov vybraný používate�om a vráti jeho obsah.

Pre tvorbu obsahu kaskádového súboru pre obrazovky slúži metóda�'�� **��'��+��'�� , ktorá pracuje v dvoch módoch.V prvom obdobne ako predošlá metóda a v druhom, ak používate� vyberiepoužitie explicitného formátovania, zabezpečí programové vytvorenie obsahusúboru kaskádových štýlov pod�a formátovacích informácií obsiahnutýchv komponentoch. Na to využíva metódy �'�� **+��#��,pomocou ktorej sa identifikujú jedinečne zformátované komponenty a '��"�'�� **��'��+��'�� ,��, ktorá slúžina vytvorenie samotného obsahu kaskádového súboru na základe jedinečnezformátovaných komponent.

6.3.2 Tvorenie používateľského prostredia prezentácie

Vytváranie používate�ského prostredia prezentácie zabezpečuje metóda��**��, ktorá postupne zavolá metódy, ktoré zabezpečiavytvorenie jednotlivých HTML dokumentov tvoriacich používate�ské prostredie.

��**�� – vytvorenie štartovacieho HTML dokumentu(index.html), ktorý definuje rozmiestnenie jednotlivých častípoužívate�ského prostredia pomocou HTML rámcov.

��**��-�� – vytvorenie hornej časti používate�skéhoprostredia, ktorá obsahuje názov prezentácia a jej autora.


��**��-�� – vytvorenie obsahovej časti navigácie. V základezabezpečí vytvorenie obsahovej štruktúry prezentácie pomocou HTMLtagov, no taktiež je možnos� jej vytvorenia pomocou JavaScriptu, čozabezpečí metóda ��**��-��.��.

��**��/�� – vytvorenie spodnej časti používate�skéhoprostredia, ktoré obsahuje možnos� navigácie pohybom po obrazovkáchpomocou jednoduchého JavaScriptu.

��**��+�� – vytvorenie prázdneho dokumentu, ktorý jepoužitý ako okreje používate�ského prostredia.

6.3.3 Tvorenie používateľských obrazoviek

Tvorenie obrazoviek zabezpečuje jednoduchá metóda��**��'��, ktorá v slučke pre každú obrazovku volámetódu ��**��'��0��, ktorá zabezpečuje vytvorenie HTMLdokumentu reprezentujúceho konkrétnu obrazovku. Táto metóda v slučkeprechádza a prekladá jednotlivé komponenty umiestnené na obrazovke a takskladá obsah danej obrazovky.

Pre preklad každého druhu komponenty je určená jedna metóda,ktorá špecifickým spôsobom zabezpečí jej preklad a vráti jej HTML zápis.

Pri preklade jednotlivých komponent sa používa tiež metóda�'�� **1��'��, ktorá slúži na zistenie označeniakaskádového štýlu pre konkrétnu komponentu.

6.3.4 Kopírovanie zdrojov

Kopírovanie zdrojov zabezpečuje metóda ��**��+�� ,ktorá podobne ako v prípade tvorenia obrazoviek, v slučke volá metódu��**��+�� 0��, ktorá zabezpečuje kopírovanie zdrojovz jednotlivých komponent nachádzajúcich sa na konkrétnej obrazovke.

Pre každú relevantnú komponentu je implementovaná samostatnámetóda, ktorá zabezpečuje identifikovanie zdroja v komponente a pomocoumetódy ��**��+�� jeho skopírovanie do adresárov prezentácie.

6.3.5 Stav konvertovania prezentácie

Aby používate� mohol by� informovaný o stave práve prebiehajúcejprezentácie je implementovaný objekt �'��. Ten reprezentuje stavprekladu prezentácie vo vnútorných premenných spolu s ich prípadným bližšímpopisom či doplňujúcimi informáciami. Počas prekladu sa jeho stav spolus informáciami zapisuje do tohoto objektu pomocou metódy�'��**'��#��"�� a �'��**'��'��. Pomocou metódy��**1��'�� sa tieto informácie môžu z objektu prečíta�a následne zobrazi� používate�ovi.


6.4 Formátovanie prezentácie

Súhra HTML, CSS, JavaScript-u, Flash a obrázkov vytvára komplex prezentácie,ktorá je výsledným produktom programu a ktorá je zodpovedná za dojemkoncového používate�a. Pre potreby knižnice konvertujúcej prezentáciu do HTMLboli vytvorené tri prototypy prezentácie (�alej ich budeme nazýva� skrátenešablóny).

Šablóna č. 1 bola vytvorená ako prvá s umiestnením titulného pruhuhore. Šablóny č. 2 a 3 majú titulný pruh umiestnený vertikálne na pravom okraji.Šablóny č. 1 a 2 sú totožné až na umiestnenie titulného pruhu. Šablóna č. 3má modernejší vzh�ad.

Obr. 15. Šablóna č. 1

6.4.1 Organizácia súborov

Prezentácia je organizovaná do súborov. Súbor ��2�� obsahuje opisrozloženia jednotlivých rámcov prezentácie (hlavný [��], titulný, navigačnýa obsah). Každý z týchto rámcov je opísaný vo zvláštnom súbore(jednotlivé súbory [obrazovky] prezentácie, ��2��, ��2�� a ��2��).

Štýly sú definované v samostatnom súbore s príponou .css a pripájajúsa ku každému súboru reprezentujúcemu rámec prostredníctvom značky 3��45v hlavičke HTML. Rovnako je v hlavičke definovaná znaková sada a titul súboru.

6.4.2 Používateľské rozhranie

Ako už bolo spomenuté, používate�ské rozhranie je tvorené súbormi ��2��, ��2�� a ��2��.

Súbor ��2�� v šablóne č. 1 obsahuje dva riadky textu, pričom prvý jeoznačený ako 67 triedy -�� a druhý ako # triedy �!��. V šablónach č. 2 a 3je miesto nich použitý obrázok vo formáte JPEG s rozmermi 32 × 423 pixelov.


Vo všetkých šablónach je telo titulného pruhu triedy �� a v ňom je definovaný)�8 tiež triedy ��.


Navigácia v súbore ��2�� je riešená vloženým JavaScript kódom.Tri funkcie (��, ��&�� a ��) operujú nad po�om ��"��,v ktorom sú zapísané mená súborov obsahujúcich jednotlivé obrazovky,a premennou �� , uchovávajúcou aktuálnu obrazovku. Po kliknutína navigačné odkazy (# triedy ��, � tridy ��) sa zavolá príslušná funkcia,ktorá do hlavného rámu prezentácie načíta príslušný súbor. Navigačné odkazysú uzavreté do )�8 triedy �� a informácia o vlastníkovi autorských právdo � triedy �� a )�8 triedy ��"��. Telo je opä� triedy ��.

Najzložitejšou čas�ou používate�ského rozhrania je pruh s obsahom.Do súboru ��2�� sú vložené odkazy na dva JavaScript-ové súbory – – ��2% a ��!��!��2% . Prvý z nich obsahuje kód rozba�ovacieho stromu(ide o upravený kód z ��*99$$$2 ��$��2��9��!�� 9��9), druhýdefinuje jeho štruktúru. Čo sa týka formátovania, telo i oddiel )�8 sú triedy ��.Pre obsah je definované zvláštne formátovanie nadpisov, ke�že takto sú označenéjeho jednotlivé položky. So stromom súvisí trojica obrázkov rozmeru 22 × 12pixelov �2%�", �2%�" a �2%�" zobrazujúcich sa pri otvorenej a zatvorenej vetvestromu a pri listoch v tomto poradí.

Štruktúra obsahu sa určuje obsahom premennej -:,,�0),'.tá obsahuje záznamy �� (globálne formátovanie obsahu) a ! (vlastná štruktúra). Záznam ! obsahuje nadpisy najvyššej hierarchie definovanépoložkami �� (nadpis), !�� (cesta k cie�u), ��"�� (vždy ;��;), ��(popis v bubline, štandardne nadpis s číslom), prípadne �alší ! obsahujúcinižšiu úroveň. Položka ! teda umožňuje rekurzívne použitie.Obsah sa do vlastného súboru ��2�� vloží vytvorením nového'��)��$��-�� v kóde JavaScript-u.



6.4.3 Látka prezentácie

Vlastný obsah prezentácie sa nachádza v hlavnom ráme prezentácie označenomako ��. Rovnako všetky odkazy nasledované z látky prezentácie sa zobrazujúv tomto priestore. Umiestnenie textu prezentácie do prostriedka obrazovky bolodocielené použitím 20% okraja vpravo.


7 TestovanieTáto kapitola sa zaoberá testovaním vytváraného systému. Testovanie systému jedôležitou fázou životného cyklu softvéru a nie je možné túto čas� opomenú� alebozanedba�. Testovanie prebiehalo na verzii systému VSAM Editor v2.0 a podie�alisa na ňom tak vývojári ako aj externí spolupracovníci. V tejto kapitole opisujemevšetky testy, ktoré boli vykonané na spomenutej verzii systému.

Samotnú fázu testovania sme rozdelili na dve časti – alfa testovanie a betatestovanie. Čas� alfa testovania bola vykonávaná v prostredí vývoja. To znamená,že testovaný systém bol spustený na počítači, na ktorom sa vyvíjal a testovali hovývojári. Po úspešnom dokončení alfa testovana, sme prešli k beta testovaniu.Ide o fázu, kedy bol systém poskytnutý externým spolupracovníkom, ktorí systémtestovali pod�a návodu v prostredí zákazníka.

7.1 Alfa testovanie

V tejto časti uvádzame zoznam všetkých testov, ktoré boli vykonané na systémevo fáze alfa testovania. Testy boli vykonávané vývojármi systému a vyústilido verzie systému 0.9. Testy sú zoradené v tabu�kách pre väčšiu preh�adnos�.

Legenda:

ID – Identifikačné číslo testuNázov – Názov testuPožiadavky – Číslo požiadavky, ktorá je testovaná

(pod�a katalógu požiadaviek)Účel – Cie� testuPodmienky – Podmienky, ktoré musia by� splnené pri vykonaní testu.Krok – Čas� testuAkcia – Úloha, ktorá sa musí pri teste vykona�Očak. reakcia – Želané správanie sa systému pri vykonanej akciiPoznámka – Dodatok k časti testu


7.2 Beta testovanie

Beta testovanie slúži na overenie funkčnosti systému v prostredí používate�a.Na tento účel sme poskytli systém VSAM verzie 0.9 nieko�kým používate�om,ktorý nespolupracovali na vývoji, aby systém otestovali. Ako postup testovaniaslúži nasledujúca tabu�ka. Pod�a šablóny vyplní obsluha náhodný početobrazoviek, nie však menší ako 15. Výsledný projekt od nieko�kých nezávislýchzdrojov je overovaný, či sú splnené všetky požiadavky kladené na systém.


8 ZáverVýsledkom nášho dvojsemetrového snaženia je systém, ktorý umožňuje vytvára�prezentácie pre potreby predmetu Architektúra počítačov. Pozostáva z dvoch častí.Prvou je samotný editor prezentácie, kde je možné pridáva� podporovanékomponenty. Prístup k tomuto modulu má pedagóg, ktorý tvorí prezentáciu.Výstup je zabezpečený cez používate�skú knižnicu. Tá konvertuje prezentáciudo výstupnej formy HTML stránky. K tomuto výstupu ma prístup študent.Prezentáciu je možné prehliada� vo vo�ne dostupných prehliadačoch, takžeje zabezpečená jej dostupnos�.

Z h�adiska možností však musíme konštatova�, že návrh systému je�aleko širší a umožňuje ve�ké možnosti. Náš implementovaný systém je plnefunkčná demonštrácia jeho možností. Na komplexnú implementáciu je všakpotrebný dlhší čas. Predbehli sme tak aj požiadavky zadania.

Funkčnos� navrhnutého systému je možné overi� na implementovanejaplikácii so vzorkou študijných materiálov z predmetu Architektúra počítačov.


Tímový projekt | Dokumentácia k riadeniu projektu

1

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Tímový projekt

Multimediálna podpora predmetu Architektúra počítačov

Dokumentácia k riadeniu projektu

Tím č. 9 Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel Mésároš Vedúci tímového projektu: Ing. Ján Hudec letný semester šk. r. 2003/2004


2

Obsah 0 Úvod................................................................................................................................I 1 Ponuka............................................................................................................................II 2 Plán projektu.................................................................................................................III 3 Úlohy členov tímu........................................................................................................IV 4 Zápisy zo stretnutí..........................................................................................................V 5 Posudky........................................................................................................................VI 6 Preberacie protokoly...................................................................................................VII 7 Štábna kultúra............................................................................................................VIII


1

0. Úvod Dokumentácia riadenie projektu obsahuje všetky aspekty potrebné k získaniu prehľadu o riadení nášho projektu Multimediálna podpora predmetu Architektúra počítačov. Jej účelom je v čo najväčšej miere zefektívniť prácu tímu ako aj podporovať plánovanie a riadenie procesu tvorby výsledného produktu. Obsahovo je tvorený z nasledujúcich častí: • Ponuka – obsahuje kompletnú ponuku nášho tímu spolu s jej prezentáciou • Plán projektu – rozpis dlhodobých plánov na dané časti vývoja systému, ako aj

krátkodobé plány, ktoré sa budú priebežne dopĺňať. • Úlohy členov tímu - obsahuje podrobne rozpísané jednotlivé úlohy členov tímu

z dlhodobého ako krátkodobého hľadiska. Ďalej obsahuje rozdelenie práce pri tvorbe jednotlivých článkov ako aj percentuálne vyjadrenie práce členov tímu na jednotlivých kapitolách.

• Zápisy zo stretnutí – záznamy zo všetkých doposiaľ vykonaných stretnutí, ktoré boli venované tímovému projektu.

• Posudky – k jednotlivým kontrolným bodom pre náš projekt ako aj projekt konkurenčného tímu.

• Preberacie protokoly – doklady o prevzatí dokumentácie vedúcim tímového projektu na príslušných kontrolných bodoch.

• Štábna kultúra – všeobecne dodržiavané pravidlá pri tvorbe projektu a dokumentácie.


1

1. Ponuka V tejto kapitole uvádzame kompletnú ponuku ako sme ju prezentovali v treťom týždni semestra. Ponuka sa bola vypracovaná na projekt Multimediálna podpora predmetu Architektúra počítačov. Na tomto mieste uvádzame aj priesvitky vytvorené za účelom prezentácie. 1.1 Obsah ponuky Predstavenie tímu

Riešiteľský tím pozostáva z piatich študentov inžinierskeho štúdia Fakulty informatiky a informačných technológií Slovenskej technickej univerzity v Bratislave. Bc. Viliam Bedeč Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Programovaniu sa venuje už devä_ rokov. Začal programovaním v jazyku Basic. Štyri roky programuje v jazyku C/C++. Vytvoril softvérový produkt EIFL vo vývojovom prostredí Borland C++ Builder, ktorý bol publikovaný v časopise PC World. (Ide o kompresor zvukových súborov do formátu MP3.) V rámci bakalárskeho projektu vytvoril softvérový systém pre chemickotechnologickú fakultu STU v Bratislave pre spracovanie cyklovoltampérmetrických meraní. Ďalej ovláda programovanie v jazykoch asemblér, VHDL, PHP, HTML. Má skúsenosti s tvorbou aplikácii menšieho rozsahu. Bc. Peter Hlocký Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Tvorbe softvérových produktov sa venuje vyše 8 rokov. Prvé skúsenosti s programovaním nabral pri kódovaní v jazyku Pascal. Z ďalších programovacích jazykov ovláda C++ a VHDL. Má skúsenosti s tvorbou programov v strojovom jazyku procesorov rodiny 51 a x86. Je tvorcom hardvérovej časti statického vnútroobvodového emulátora a jeho firmvéru pre KIVT FEI STU. Počas praxe nabral skúsenosti s webovými aplikáciami, HTML a s interpretom PHP. Bc. Marek Hrablay Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Programovaniu sa venuje sedem rokov. Ovláda programovanie v C/C++ a Macromedia Flash MX. Má praktické skúsenosti s tvorbou aplikácií menšieho rozsahu. Je tvorcom ovládacieho programu vnútroobvodového emulátora S–ICE v. 1.0 vytvoreného pre KIVT FEI STU Bratislava. Ďalším prínosom pre tím je absolvovanie predmetov Princípy softvérového inžinierstva a zapísaný predmet Architektúra softvérových systémov.


2

Bc. Tomáš Chmel Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Informatika, špecializácia Počítačové systémy a siete. Programovaniu sa venuje 5 rokov. Ovláda programovanie v jazykoch Asemblér, C/C++, OpenGL, VHDL,PHP. Svoje skúsenosti získal programovaním softvérových systémov menšieho rozsahu v rámci bakalárskeho štúdia, ako aj v rámci svojho voľného času. Je tvorcom programu PCIV, určeného pre meranie koncentračných profilov nosičov náboja v polovodičových vzorkách, vypracovaného v rámci záverečného projektu bakalárskeho štúdia. Bc. Marcel Mésároš Absolvoval bakalárske štúdium na Fakulte elektrotechniky a informatiky STU v Bratislave v odbore Elektronika. Programovaniu sa venuje už vyše 11 rokov. Ovláda programovanie v jazykoch Asemblér (x86, TMS370, x51, Z80), C/C++, BASIC, Pascal, SQL, HTML a ďalších. Približne rovnaký čas má skúsenosti s DTP a prípravou dokumentov pre tlač, ovláda programy QuarkXPress, Adobe Photoshop, Adobe PageMaker, Adobe Illustrator, Adobe Acrobat.

Motivácia

Prvý kontakt s počítačovým inžinierstvom získavajú študenti FIIT STU v Bratislave na hodinách predmetu Architektúra počítačov. Náplňou tohto predmetu je predovšetkým oboznámenie sa so základnými stavebnými prvkami počítačových systémov a princípmi ich fungovania. Doterajší spôsob výučby spočíval v štúdiu skrípt, účasti na prednáškach a cvičeniach dennej formy štúdia. Nakoľko problematika architektúry počítačov napreduje závratným tempom, vydávané skriptá nestíhajú zachytáva_ nové poznatky v tejto oblasti. Rýchlej a jednoduchej aktualizácii študijného materiálu bránia s ňou spojené vysoké finančné a časové náklady.

V súčasnosti existujú technológie, ktoré umožňujú jednoduchšiu prezentáciu, aktualizáciu a v neposlednom rade aj dostupnosť učebných materiálov. Riešením tohto problému sa zaoberá téma Multimediálna podpora predmetu Architektúra počítačov v rámci Tímového projektu, na ktorej sa náš tím rozhodol pracovať. Za dôvody, ktoré nás viedli k tomuto rozhodnutiu, považujeme najmä chuť využiť vedomosti členov tímu nadobudnuté počas bakalárskeho štúdia v odbore Informatika v zameraní Počítačové systémy a siete a taktiež náš odborný záujem v tejto oblasti. Náš tím má ambíciu poskytnúť riešenie, ktoré bude spĺňať všetky požiadavky naň kladené a v maximálnej možnej miere poskytnúť používateľovi prijemné pracovné prostredie s množstvomdoplnkových funkcií.

Snahou nášho tímu je ušiť produkt na mieru zákazníka podľa jeho predstáv. Jednou z našich základných priorít je vytvoriť plne funkčný systém s použitím metód a techník softvérového inžinierstva, tak aby bolo možné výsledný produkt nasadiť v reálnom prostredí.


3

Ponuka

Náš produkt bude spĺňať kompletnú špecifikáciu zadania: – navrhnúť a realizovať produkt, ktorý multimediálnymi prostriedkami

umožní vytvoriť rámce zodpovedajúce požadovaným kapitolám predmetuArchitektúra počítačov,

– navrhnúť a realizovať náplň jednotlivých častí, – produkt implementovať ako hypermediálnu prezentáciu

s kapacitnými nárokmi na jedno CD-Rom médium a voľne dostupný prehliadač.

Na základe požiadaviek zákazníka bude vytvorený systém, ktorý bude tvorený dvomi modulmi. Prvý modul bude predstavovať vývojové prostredie pre tvorbu multimediálnych prezentácii. Tvorcovi prezentácie bude umožňovať:

– vytvorenie štruktúry multimediálnej prezentácie, – vkladanie článkov, obrázkov a animácii do štruktúry prezentácie, – jednoduché aktualizovanie údajov prezentácie, – jednoduché modifikovanie celej štruktúry prezentácie, – využitie softvérových výstupov z iných aplikácii, – použiť systém pre ľubovoľné prezentácie, – vytváranie testov pre kontrolu zvládnutia problematiky, – podporu tvorby pomocou elektronickej dokumentácie, – pracovať v interaktívnom, jednoduchom a graficky prepracovanom

rozhraní. Druhým modulom je prezentácia vytvorená vo vývojovom prostredí a bude prístupná študentom predmetu Architektúra počítačov. Výsledná prezentácia bude študentom umožňovať:

– prezeranie multimediálnej prezentácie vo voľne dostupných prehliadačoch,

– prehľadné a intuitívne ovládanie, – otestovať zvládnutie problematiky.


4

Predpokladané zdroje

Implementačné prostredie Výsledný systém sa bude skladať z dvoch modulov. Vývojové prostredie – prvý modul – bude vytvorené vo vývojovom prostredí Borland C++ Builder 5. Vývojové prostredie bude možné používať na počítači s operačným systémom Windows verzie 95 a novšom. Vytvorená prezentácia – druhý modul – bude HTML stránka. Do prezentácie sa budú dať pomocou vývojového prostredia vkladať nasledovné typy súborov:

– textové dokumenty – obrázky – animácie Výsledným produktom je prezentácia, ktorú je možné prezerať

pomocou voľne dostupných prehliadačov podporujúcich HTML verzie 4 a vyššie.

Hardvérové požiadavky Hardvérové požiadavky budú vyplývať z požiadaviek jednotlivých modulov. Pre vývojové prostredie to bude systém s procesorom Pentium, min. 32 MB pamäte a obrazovku s rozlíšením 800 × 600 / 16 bit. Hardvérové požiadavky na výslednú prezentáciu budú vychádzať z požiadaviek prehliadača webových stránok, na ktorom bude prezentácia spustená. Časové a priestorové požiadavky Na vypracovanie projektu v danom rozsahu bude potrebných 8 hodín týždenne na člena tímu počas dvoch semestrov. Z toho vyplývajú aj požiadavky na priestory pre prácu tímu na projekte. V miestnosti musia byť voľné počítače prístupné pre členov tímu s pripojením na Internet.

Príloha

Zoradenie ponúkaných tém podľa priority Ponúkané témy preferujeme v nasledovnom poradí:

1. Multimediálna podpora predmetu Architektúra počítačov (APS) 2. Podpora dištančného vzdelávania v predmete Systémové

programovanie a asembléry (SPA) Rozvrh členov tímu


5

Rozvrh členov tímu uvádzame samostatne na nasledujúcej strane.


6


7

1.2 Priesvitky

Slovenská technická univerzita v Bratislave Fakulta elektrotechniky a informatiky Katedra informatiky a výpočtovej techniky

Tímový projekt

Multimediálna podpora predmetu Architektúra počítačov Prezentácia ponuky Tím č. 9 Viliam Bedeč, Peter Hlocký, Marek Hrablay, Tomáš Chmel, Marcel Mésároš letný semester šk. r. 2003/2004 6. 10. 2003

Ponuka

– splnenie kompletnej špecifikácie zadania – systém tvorený dvomi modulmi

Prvý modul – prostredie pre tvorbu multimediálnych prezentácii

– vytvorenie štruktúry, vkladanie článkov, obrázkov a animácii – interaktívne rozhranie – jednoduchá aktualizácia údajov – jednoduchá modifikácia celej štruktúry prezentácie – využitie softvérových výstupov z iných aplikácii – univerzálnosť systému pre ľubovoľné prezentácie – možnosť vytvárania testov pre kontrolu zvládnutia problematiky – podpora tvorby pomocou elektronickej dokumentácie

Druhý modul – prezentácia vytvorená vo vývojovom prostredí

– prezeranie multimediálnej prezentácie vo voľne dostupných prehliadačoch – prehľadné a intuitívne ovládanie – možnosť otestovať zvládnutie problematiky


1

2. Plán projektu V tejto kapitole uvedieme dlhodobý plán projektu na zimný semester školského roku 2003/2004. V tab. č. 1 sú zobrazené jednotlivé body, ktoré sú rozplánované na jednotlivé týždne semestra. Tab. č. 1 – Dlhodobý plán na zimný semester 2003/2004

1. týždeň úvod do predmetu 2. týždeň návrh ponuky a návrh jej prezentácie 3. týždeň prezentácia ponuky 4. týždeň prvý pohovor s tímovým vedúcim, počiatočná analýza požiadaviek 5. týždeň hlbšia analýza požiadaviek, príprava otázok na interview 6. týždeň zostavenie katalógu požiadaviek 7. týždeň hrubý návrh dátových štruktúr 8. týždeň vytvorenie dokumentácie pre prvý kontrolný termín 9. týždeň podrobný návrh - funkčný diagram, dátový diagram 10. týždeň Rozčlenenie úloh implementácie, počiatok implementácie prototypu 11. týždeň implementácia prototypu 12. týždeň prezentácia riešenia a prototypu

V tab. č. 2 sú zobrazené podrobné úlohy, ktoré sú rozplánované na posledné

štyri týždne semestra škol. roku 2003/2004. Tab. č. 2 – Krátkodobý plán na posledné štyri týždne zimného semestra

9. týždeň - Definovanie základných funkcií prototypu, ktoré sa budú implementovať - Návrh dátového modelu prototypu - Návrh funkčného modelu prototypu

10. týždeň - Hlavný návrhár systému rozdelí úlohy na podúlohy a určí zodpovedných na implementovanie (traja členovia tímu) - Hlavný návrhár prezentácie rozdelí úlohy na podúlohy z pohľadu dizajnu prezentácie a určí zodpovedných na implementáciu (dva členovia tímu) - Počiatok implementácie prototypu

11. týždeň - Implementácia prototypu - Každý z členov implementuje svoju časť prototypu - Spojenie systému - Verifikácia a validácia

12. týždeň - Naplnenie systému netriviálnou vzorkou údajov - Príprava prezentácie riešenia a prototypu - Prezentácia prototypu


2

V tab. č. 3 sú zobrazené úlohy, ktoré sú rozplánované na celý letný semester

škol. roku 2003/2004. Prvé štyri týždne sú rozplánované do konkrétnych úloh, úlohy na posledné týždne sú iba hrubo načrtnuté a v priebehu riešenia projektu môžu byť prispôsobené časovým možnostiam. Tab. č. 3 - Dlhodobý plán na letný semester 2003/2004

1. týždeň Návrh základných modulov nezávislých od prostredia Návrh – fyzický model údajov Návrh – fyzický model funkcií

2. týždeň Návrh – fyzický model údajov - dokončenie Návrh – fyzický model funkcií – dokončenie Vytvorenie dokumentácie pre fyzické modely Návrh abstraktného dátového typu - strom pre štruktúru nadpisov Návrh abstraktného dátového typu - úložisko komponent Návrh abstraktného dátového typu – index Návrh zreťazenia obrazoviek

3. týždeň Implementácia abstraktného dátového typu – strom pre štruktúru nadpisov Implementácia abstraktného dátového typu - úložisko komponent Implementácia abstraktného dátového typu – index Implementácia zreťazenia obrazoviek

4. týždeň Implementácia používateľského rozhrania systému – objekty pre prácu s prostredím Implementácia konverznej utility

5. týždeň Implementácia používateľského rozhrania systému – objekty pre prácu s prostredím Implementácia konverznej utility Vytvorenie novej šablóny – viacerých

6. týždeň Implementácia používateľského rozhrania systému – objekty pre prácu s prostredím Implementácia konverznej utility Tvorba obrázkov Tvorba animácií

7. týždeň Naplnenie systému údajmi – vytvorenie prezentácie predmetu AP 8. týždeň Testovanie 1. modulu

Testovanie konverznej utility 9. týždeň Testovanie používateľského rozhrania

10. týždeň Validácia systému Tvorba elektronickej príručky Vytvorenie dokumentácie k implementácii a testovaniu

11. týždeň Dokončenie dokumentácie k implementácii a testovaniu Tvorba používateľskej príručky

12. týždeň Finalizácia


1

3. Úlohy členov tímu V tejto kapitole rozpíšeme jednotlivé úlohy členov tímu z dlhodobého a krátkodobého hľadiska. Dlhodobé úlohy sú také, ktoré člen tímu vykonáva neustále v priebehu semestra alebo také, ktoré majú charakter manažmentu činností a teda člen tímu má vedúcu úlohu v tejto oblasti. Krátkodobé úlohy majú skôr charakter čiastkových úloh, ktoré sú zadávané z týždňa na týždeň. Jednou z podkapitol tejto kapitoly je aj rozpis podielu členov tímu na autorstve dokumentácie projektu a dokumentácie k riadeniu a tiež podiel činnosti členov tímu na tvorbe ponuky k projektu. 3.1 Dlhodobé úlohy členov tímu Viliam Bedeč – Hlavný návrhár programového systému pre tvorbu dokumentácie Peter Hlocký – Vedúci tímu a správa web prezentácie Marek Hrablay – Hlavný grafik Tomáš Chmel – Hlavný analytik Marcel Mésároš – Hlavný návrhár prezentácie predmetu 3.2 Krátkodobé úlohy členov tímu Krátkodobé úlohy členov tímu sú pridelované vždy na stretnutí tímu a podľa potrieb súčasného stavu projektu. V tab. č. 3 uvádzame podrobný rozpis krátkodobých úloh členov tímu na jednotlivé týždne semestra počnúc druhým. Tab. č. 3 – Krátkodobé úlohy na zimný semester 2003/2004

2. týždeň

všetci

- stretnutie za účelom prejednania návrhov na obsah ponuky - spísanie návrhov a nápadov do dokumentu - príprava priesvitiek

úloha splnená

3. týždeň

všetci - sociálne aktivity za účelom zblíženia sa členov tímu úloha splnená

4. týždeň

- skúmať možnosti implementácie konštruktora prezentácie

- zistené možnosti implementačného prostredia Viliam Bedeč

- analýza existujúcich riešení - v úlohe pokračuje ďalší týždeň Peter Hlocký - návrh dizajnu web prezentácie - návrh vytvorený, schválený tímom

- návrh loga tímu - logo bolo navrhnuté, nebolo schválené tímom Marek Hrablay

- analýza existujúcich riešení - v úlohe pokračuje ďalší týždeň - skúmať možnosti implementácie prekladača do HTML

- analýza vykonaná, vysledky sú registrované v rácmi požiadaviek

Tomáš Chmel

- návrh plagátu tímu - návrh plagátu vykonaný, schválený tímom - návrh loga tímu - logo bolo schválené tímom Marcel

Mésároš - návrh grafickej úpravy prezentácie - návrhy prednesené na tímovom stretnutí


2

5. týždeň

- analýza existujúcich riešení prezentácií - získal materiály, pokračuje budúci týždeň Viliam Bedeč

- vytvorenie základnej úrovne katalógu požiadaviek

- úloha splnená, katalóg je kostrou analýzy projektu

Peter Hlocký - vytvoriť web prezentáciu - web prezentácia bola vytvorená a v čas spustená

- analýza existujúcich riešení - analýza v priebehu, do 6. týždňa spracuje text do dokumentácie

Marek Hrablay - analyzovať produkt ACDL - produkt analyzovaný, objaví sa v rámci

dokumentácie

Tomáš Chmel - vytvoriť spolu s Viliamom hlbšie úrovne kat. požiadaviek

- v úlohe pokračuje, do 6.týždňa bude mať komplet. výsledok

Marcel Mésároš

- analýza CICSO vzdelávacieho produktu

- produkt analyzovaný, bude súčasťou dokumentácie

6. týždeň

- analýza existujúcich aplikácii na tvorbu prezentácii

OK - vytvorený text, ktorý bude uvedený v opise problematiky

- zhrnutie výsledkov analýzy na návrh novej prezentácie - detto

Viliam Bedeč

- rozposlanie osnovy analýzy a zápisnice zo stretnutia - detto

Peter Hlocký - úvod do analýzy a popis predmetu Architektúra počítačov

OK - vytvorený úvodný text, ktorý bude uvedený v opise problematiky

- analýza výučby pomocou e-learningu OK - vytvorený text, ktorý bude uvedený v opise problematiky

Marek Hrablay - použitie multimediálnych technológii

v e-learningu - detto

- dopracovať katalóg požiadaviek

- bola vytvorená základná vrstva katalógu požiadaviek a jeho hlavných podúrovní. Na stretnutí bol doplnený podrobnejšími požiadavkami tak, aby bol pripravený na budúci týždeň

Tomáš Chmel

- dokončenie plagátu tímu - plagát bol vytvorený - analýza a návrh formátovania prezentácie - analýza bola kompletne dokončená

Marcel Mésároš

- zhrnutie výsledkov na návrh novej prezentácie - návrh je vo fáze dokončovania


3

7. týždeň

- napísať kapitolu 2.2 - scenáre použitia OK - napísať kapitolu 3.1 - hrubý návrh - architektúra systému OK

Viliam Bedeč

- napísať kapitolu 3.3 - 1. Modul OK - doplnenie katalógu požiadaviek OK - podrobný plán do konca semestra OK

Peter Hlocký

- napísať kapitolu 3.2 - Funkčný diagram obmedzené na roly používateľov - úloha

splnená - úvod k dokumentácii riadenia OK - zformátovať dokumentáciu riadenia OK

Marek Hrablay - spracovať interview v - dokončiť katalóg požiadaviek OK

Tomáš Chmel - napísať kapitolu 3.2 - Hrubý návrh

konverzná utilita OK

- napísať kapitolu 1.4 - analýza vzdelávacích produktov CISCO a ACDL OK

- napísať kapitolu 2.3 - Analýza formátovania OK

- napísať kapitolu 3.5 - 3. Modul - Prezentácia OK

- vytvoriť preberacie dokumenty OK

Marcel

Mésároš

- vytvoriť metódy a šablóny pre dokumentáciu riadenia OK

8. týždeň člen tímu úloha stav úlohy

Viliam Bedeč - navrhnúť DFD diagram Bola vytvorená kontextová úroveň a 1. úroveň

- získanie kompletných štúdijných materiálov OK Peter Hlocký

- vytlačenie dokumentácie k projektu OK Marek

Hrablay - vytvorenie FLASH animovanej ukážky presúva sa do termínu implementácie prototypu

Tomáš Chmel - navrhnúť E-R diagram vytvorená základná koncepcia E-R diagramu

- naformátovať finálnu dokumentáciu úloha splnená Marcel Mésároš

- podrobný návrh formátovania prezentácie

fomátovanie navrhnuté, treba ešte dopracovať pre potreby prototypu


4

9. týždeň - vypracovať podrobný dátový diagram spolu s Marekom OK Viliam Bedeč - rozčlenenie úloh pre implementáciu OK - vypracovať podrobný DFD diagram spolu s Tomášom OK

Peter Hlocký - vypracovať posudok ku stavu projektu tímu č.12 OK - vypracovať podrobný dátový diagram spolu s Vilom OK

Marek Hrablay - získať materiály potrebné pre implementáciu prototypu OK

Tomáš Chmel - vypracovať podrobný DFD diagram spolu s Petrom OK - vypracovať kapitolu Štábna kultúra pre riadenie projetu OK Marcel

Mésároš - vypracovať finálne formátovanie prezentácie pre prototyp riešené

10. týždeň

Viliam Bedeč - implementovať 1. časť prototypu OK

Peter Hlocký - vytvoriť E-R diagram - bol vytvorený diagram tried, kvôli lepšej názornosti

- vypracovať DFD diagram - bol vypracovaný po 2. úroveň Marek Hrablay - vytvoriť FLASH animáciu

- určená téma pre animáciu, implementovaná bude v nasledujúcom týždni

Tomáš Chmel - implementovať konverznú utilitu OK - návrh formátovania preznetácie - vytvorená šablóna pre prototyp Marcel

Mésároš - úprava dizajnu výslednej prezentácia OK

11. týždeň

- dokončenie prototypu OK Viliam Bedeč - vytvorenie kapitoly 4.2 - Vyhodnotenie

prototypovania (systém) OK

- vytvoriť kapitolu 3.6 - Model údajov OK Peter Hlocký - vytvoriť kapitolu 4.1 - Ciele

prototypovania OK - vypracovať kapitolu 3.5 - Model funkcií OK

Marek Hrablay - vytvoriť dokumentáciu k riadeniu OK

Tomáš Chmel - dokončenie prototypu - konverzná utilita OK

- vytvoriť kapitolu 3.7 - Návrh šablóny OK - vytvoriť kapitolu 4.3 - Vyhodnotenie prototypovania (prezentácia) OK Marcel

Mésároš - dokončiť implementáciu šablóny pre prototyp OK


5

3.3 Krátkodobé úlohy členov tímu – Letný semester Tab. č. 4 – Krátkodobé úlohy na letný semester 2003/2004

2. týždeň

Viliam Bedeč - návrh abstraktného dátového typu – zreťazená volná pamäť OK

Peter Hlocký - návrh abstraktného dátového typu - index OK

Marek Hrablay - návrh abstraktného dátového typu - strom OK

Tomáš Chmel - zjemnenie DFD konverznej utility OK - návrh a vytvorenie ukážky ku navigovaniu v prezentácii pomocou JavaScriptu

Pokračuje v riešení Marcel

Mésároš - návrh formátovania výsledného HTML dokumentu pomocou kaskádových štýlov na úrovni jednotlivých komponent

OK

3. týždeň Viliam Bedeč - zreťazenie komponent a obrazoviek Pokračuje v riešení

Peter Hlocký - index – doriešenie triedenia s diakritikou OK

Marek Hrablay - návrh vizuálnej stránky animácií OK Tomáš Chmel - dokumentácia návrhu OK

- návrh a vytvorenie ukážky ku navigovaniu v prezentácii pomocou JavaScriptu

Pokračuje v riešení Marcel Mésároš

- dokončenie 2. kapitoly skrípt Pokračuje v riešení 4. týždeň

Viliam Bedeč - dokončiť zreťazenie komponent a obrazoviek OK

Peter Hlocký - spolu s Marcelom spracovať skriptá od kapitoly 4.4 až do konca OK

Marek Hrablay - dokončiť štruktúru nadpisov a zdokumentovať OK

Tomáš Chmel - vytvoriť html prehliadač OK - spolu s Petrom spracovať skriptá od kapitoly 4.4 až do konca OK Marcel

Mésároš - navigovanie v prezentácii pomocou JavaScriptu OK

5. týždeň

Viliam Bedeč - sfunkčnenie prostredia aplikácie – možnosť vytvárať štruktúru prezentácie OK

Peter Hlocký - prebranie skrípt v elektronickej forme a práca na ich spracovaní spolu s Marcelom

OK

Marek Hrablay - štúdium práce v prostredí C++ Builder, príprava na prezentáciu OK

Tomáš Chmel - úprava utility na tvorbu používateľského prostredia výslednej prezentácie

OK

Marcel Mésároš

- pomoc pri formátovaní skrípt spolu s Peťom OK


6

6. týždeň - implementácia editora na zmenu a úpravu komponentov Pokračuje v riešení

Viliam Bedeč – implementácia funkcií načítania a uloženia prezentácie OK

Peter Hlocký - dokončiť kap. 4.2, urobiť kap 4.1 do podoby výslednej prezentácie OK - vypracovanie prezentácie o spôsoboch komunikácie OK

Marek Hrablay – integrácia stromovej štruktúry do projektu Pokračuje v riešení

Tomáš Chmel - implementovať konverziu obrazoviek a štruktúry komponent OK

Marcel Mésároš

- pridať funkcionalitu do používateľského rozhrania výslednej prezentácie rozbaľovaním hierarchie nedpisov

Pokračuje v riešení

7. týždeň

Viliam Bedeč - implementácia editora na zmenu a úpravu komponentov Pokračuje v riešení

Peter Hlocký - testovanie editoru naplnením systému kapitolou 4.1 a 4.2. OK – Vrátené na dopracovanie

Marek Hrablay - integrácia stromovej štruktúry do projektu Pokračuje v riešení

Tomáš Chmel - pokračovanie v implementácii konverznej utility Pokračuje v riešení - pridať funkcionalitu do používateľského rozhrania výslednej prezentácie rozbaľovaním hierarchie nedpisov

Pokračuje v riešení Marcel Mésároš

– príprava prezentácie o dosiahnutom progrese OK

8. týždeň

Viliam Bedeč - implementácia editora na zmenu a úpravu komponentov OK - testovanie nasledujúcej verzie editoru OK – VSAM v.0.9 sa môže odovzdať Peter Hlocký príprava dotazníka na testovanie OK - integrácia stromovej štruktúry do projektu Úloha pozastavená

Marek Hrablay príprava používateľskej príručky OK

Tomáš Chmel - pokračovanie v implementácii konverznej utility – atribúty komponent OK

Marcel Mésároš

- pridať funkcionalitu do používateľského rozhrania výslednej prezentácie rozbaľovaním hierarchie nadpisov

OK


7

9. týždeň

- sfunkčnenie prostredia aplikácie – možnosť vytvárať štruktúru prezentácie OK

Viliam Bedeč Oprava chýb nájdených alfa testom vo verzii 0.9 Pokračuje v riešení

- Príprava Beta testovania OK Peter Hlocký

Príprava testovacích vzoriek Pokračuje v riešení - Finalizácia používateľskej príručky OK

Marek Hrablay - Testovanie VSAM v0.9 OK

Tomáš Chmel - Prirobenie konverzie rozbaľovatelného obsahu do konverznej utility OK

Marcel Mésároš - Vytvorenie druhej šablóny OK

10. týždeň

Viliam Bedeč - oprava chýb a napísanie návrhu a implementácie na editor OK

Peter Hlocký - naplnenie programu kapitolami 4.1 a 4.2 OK

Marek Hrablay - testovanie a naplnenie programu kapitolami 4.3 OK

Tomáš Chmel - oprava chýb a úprava dokumentácie návrhu a implementácie konvertoru OK

Marcel Mésároš

- dokumentácia návrhu a implementácie výslednej prezentácie OK

11. týždeň - oprava drobných chýb VSAM OK

Viliam Bedeč - opraviť spájanie projektov - prerobiť kapitoly 4.1 a 4.2 OK

Peter Hlocký - Testovanie VSAM OK

Marek Hrablay - napísanie dokumentácie k riadeniu projektu na letný semester OK

Tomáš Chmel - oprava chýb konverznej utility OK - doplnenie kaskádového štýlu o štvrtú úroveň OK Marcel

Mésároš - formátovanie dokumentácie OK

12. týždeň - oprava posledných chybičiek editora OK

Viliam Bedeč - dopísať záver ku dokumentácii

Peter Hlocký - dokončenie prezentácie podľa kapitoly 4. pomocou editora OK - vyrobenie flash animácie do ku kapitole 4. OK

Marek Hrablay - prepísať používateľskú príručku pre najnovšiu verziu produktu

Tomáš Chmel - vyhotoveni CD média s produktom OK Marcel

Mésároš - doplniť dokumentáciu o chýbajúce časti OK


8

3.4 Podiel na autorstve dokumentácie a tvorbe ponuky Dokumentácia k projektu Kapitola 1 Opis problematiky

1.1 Výučba predemtov - Peter Hlocký 1.2 Elektronické štúdium alebo „E-Learnig“ - Marek Hrablay 1.3 Prostredia pre tvorbu prezentácií na internete - Viliam Bedeč 1.4 Analýza podobných prezentácií - Marcel Mésároš

Kapitola 2 Analýza problematiky 2.1 Katalóg požiadaviek - Tomáš Chmel 2.2 Scenáre použitia - Viliam Bedeč 2.3 Analýza formátovania prezentácie - Marcel Mésároš 2.4 Interview s J. Hudecom – Marek Hrablay Kapitola 3 Hrubý návrh architektúry 3.1 Základné vlastnosti editora prezentácií – Viliam Bedeč 3.2 Roly používateľov – Peter Hlocký 3.3 Návrh aplikácie pre tvorbu prezentácie – Viliam Bedeč a Tomáš Chmel 3.4 Návrh prezentácie – Tomáš Chmel 3.5 Model funkcií – Marek Hrablay 3.6 Model údajov - Peter Hlocký

3.7 Návrh šablóny - Marcel Mésároš Kapitola 4 Prototyp 4.1 Ciele prototypovania - Peter Hlocký

4.2 Vyhodnotenie prototypovania (systém) - Viliam Bedeč 4.3 Vyhodnotenie prototypovania (prezentácia) - Marcel Mésároš

Kapitola 5 Podrobný návrh 5.1 Editor prezentácie - Viliam Bedeč 5.2 Konverzná utilita - Tomáš Chmel 5.3 Návrh konverznej utility do formátu HTML - Tomáš Chmel 5.4 Formátovanie prezentácie - Marcel Mésároš

Kapitola 6 - Implementácia 6.2 Editor prezentácie - Viliam Bedeč

6.1 Rozhranie konverznej utility - Tomáš Chmel 6.2 Konvertovanie projektu prezentácie do formátu HTML - Tomáš Chmel 6.3 Formátovanie prezentácie - Marcel Mésároš

Kapitola 7 - Testovanie - Peter Hlocký Dokumentácia k riadeniu projektu Úvod – Marek Hrablay 1. Ponuka – Marcel Mésároš 2. Plán projektu – Peter Hlocký 3. Úlohy členov tímu – Peter Hlocký 4. Zápisnice zo stretnutí tímu – Marek Hrablay 5. Posudky na projekty – Marek Hrablay 6. Preberacie protokoly – Marek Hrablay 7. Štábna kultúra – Marcel Mésároš Používateľská príručka – Marek Hrablay


9

Podiel činnosti na tvorbe ponuky Viliam Bedeč – 25% Peter Hlocký – 20% Marek Hrablay – 15% Tomáš Chmel – 15% Marcel Méšároš – 25% Podiel činnosti na tvorbe špecifikácie Viliam Bedeč – 15% Peter Hlocký – 25% Marek Hrablay – 25% Tomáš Chmel – 15% Marcel Méšároš – 20% Podiel činnosti na tvorbe prototypu Viliam Bedeč – 30% Peter Hlocký – 10% Marek Hrablay – 10% Tomáš Chmel – 30% Marcel Méšároš – 20% Podiel činnosti na tvorbe výsledném dokumentácie Viliam Bedeč – 10% Peter Hlocký – 20% Marek Hrablay – 30% Tomáš Chmel – 15% Marcel Méšároš – 25% Podiel činnosti na tvorbe výsledného produktu Viliam Bedeč – 30% Peter Hlocký – 20% Marek Hrablay – 10% Tomáš Chmel – 25% Marcel Méšároš – 15%


1

4. Zápisy zo stretnutí Náš tím sa stretáva raz do týždňa. Na každom stretnutí preberáme aktuálne

problémy projektu, referujeme kolegom o dosiahnutých výsledkoch a rozdeľujeme nové úlohy. Po každom stretnutí je vypracovaná zápisnica zo stretnutia, ktorá má napomáhať celému tímu pri práci na projekte a slúži zároveň aj ako pomôcka pri kontrole stavu projektu. V tejto kapitole uvádzame zápisy zo všetkých doterajších stretnutí tímového projektu. 4.1 Zápisnica zo stretnutia ÚVTP č. 1 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 14.10.2003 Čas: 10:30 – 12:15 Prítomní:

Ing. Ján Hudec (vedúci tímového projektu) Bc. Marek Hrablay ([email protected]) Bc. Peter Hlocký ([email protected])

Bc. Viliam Bedeč ([email protected]) Bc. Tomáš Chmel ([email protected]) Bc. Marcel Mésároš ([email protected])

Program stretnutia: • Rozprava o procese tvorby multimediálnych prezentácií • Rozprava o možných spôsoboch uloženia dát vývojového prostredia. • Zadanie úloh pre jednotlivých členov tímu. Priebeh Stretnutia: • Po krátkej diskusii sme odhlasovali oficiálny názov nášho tímu: Kinedryl. • Spolu s vedúcim tímového projektu Ing. Jánom Hudecom sme diskutovali

o základných vlastnostiach nami vytváraného systému. Boli definované základné funkcionálne požiadavky kladené na systém, ako aj základy rozhrania s používateľom.

• Po predbežnej analýze sme rozdelili vytváraný systém na dve časti. Konštruktor prezentácie a preklad prezentácie do formátu HTML. Nasledovala diskusia o základných vlastnostiach oboch modulov ako aj o ich prepojení.

• Boli navrhnuté základy štruktúry prezentácie, ako aj rozdelenie prezentácie na komponenty. Diskusia o vlastnostiach komponentov a o ich vkladaní do prezentácie. Definovali sme základné komponenty prezentácie.

• Rozprava o možných spôsoboch uloženia dát vývojového prostredia. Viliam Bedeč načrtol možnosti implementácie navrhovanej štruktúry prezentácie.

mailto:[email protected]






2

Pripomienky: • bude potrebný indexu pojmov (OK) • obrázky by mali byť vložené priamo do textu a nie mimo neho – potenciálny

zdroj problémov pri implementácii (?) • tabuľky – editor tabuliek príliš zložitý na vytvorenie, avšak ani vloženie

tabuliek ako obrázkov nie je ideálnym riešením (?) • práca s odkazmi, možnosť asistencie programu pri vytváraní indexu /

odkazov (?) • potrebná hĺbka hierarchie štruktúry (kapitoly, podkapitoly, články, …) (?) • možnosť uložiť dáta v adresárovej štruktúre (?) Rozdelenie úloh do budúceho týždňa: • pre všetkých - pokračovať v analýze systému • Marek Hrablay - návrh loga tímu

- analýza existujúcich riešení • Peter Hlocký - návrh HTML stránky tímu • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie

- analýza existujúcich riešení • Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML

- analýza spôsobu uloženia dát systému - návrh plagátu tímu

• Marcel Mésároš - návrh loga tímu - návrh grafickej úpravy dokumentácie

Rozdelenie dlhodobých úloh: • Marek Hrablay - tvorba dokumentácie

- tvorba flash animácií - analýza a programovanie

• Peter Hlocký - tvorba HTML stránky tímu - vedúci tímu • Viliam Bedeč - dohľad nad tvorbou konštruktora prezentácie

- analýza a programovanie • Tomáš Chmel - dohľad nad tvorbou analýza prekladača do HTML

- analýza a programovanie • Marcel Mésároš - návrh dizajnu aplikácie

- dizajn a tvorba dokumentácie Zápisnicu vypracoval: Marcel Mésároš


3

4.2 Zápisnica zo stretnutia ÚVTP č. 2 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 21.10.2003 Čas: 10:15 – 12:30 Prítomní:

Ing. Ján Hudec (vedúci tímového projektu) Bc. Marek Hrablay ([email protected]) Bc. Peter Hlocký ([email protected])


Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Pokračovanie analýzy systému • Návrh katalógu požiadaviek • Zadanie úloh pre jednotlivých členov tímu. Stav plnenia úloh z minulého týždňa • Marek Hrablay - návrh loga tímu (OK)

- analýza existujúcich riešení (riešené) • Peter Hlocký - návrh HTML stránky tímu (OK) • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie

(riešené) - analýza existujúcich riešení (OK)

• Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML (riešené)

- analýza spôsobu uloženia dát systému (OK) - návrh plagátu tímu (OK)

• Marcel Mésároš - návrh loga tímu (OK) - návrh grafickej úpravy dokumentácie (OK)

Priebeh Stretnutia: • Zo všetkých podaných návrhov na logo tímu a plagát sme vybrali logo od

marcela Mésároša a plagát od Tomáša Chmela. • Viliam Bedeč prezentoval dve možné koncepcie zobrazenia učebného

materiálu – orientovanej stránkovo a so súvislým tokom textu a vloženými obrázkami. Nasledovala diskusia, ktorá možnosť bude najvhodnejšia.

• Nasledovalo stretnutie s Ing. Jánom Hudecom. Spolu s ním sme hodnotili našu ponuku ako aj prezentáciu ponuky. Následne sme ho oboznámili s aktuálnym stavom projektu a konzultovali sme s ním problémy spojené so špecifikáciou, na ktoré sme narazili počas minulého týždňa.







4

• Ing. Ján Hudec nás informoval o existujúcich riešeniach dištančného štúdia. • Začali sme s analýzou základnej úrovne katalógu požiadaviek. Po diskusii

na túto tému sme začali s rozdeľovaním práce na katalógu požiadaviek. Závery a pripomienky: • obrázky a animácie nebudú vkladané priamo do textu, ale budú tvori ť

samostatné komponenty vkladané do prezentácie (OK) • 2 triedy odkazov - na časti textu súvisiace s problematikou, a vytvorenie

slovníka pojmov – indexu (OK) • obmedzenie hĺbky úrovne nadpisov v prezentácii na 4. (OK) • nie je potrebné vytváranie tabuliek, túto možnosť však ponechávame na

ďalšiu analýzu (OK) • dáta prezentácie nebudú uložené v stromovej štruktúre, ale v jednom súbore

(kôli rýchlosti systému) (OK) • podporované formáty súborov na import a export (?) • možnosť editovania prezentácie aj v inom programe ako bude naše

vývojové prostredie (?) • možnosť asistencie pri vytváraní indexu (?) Rozdelenie úloh do budúceho týždňa: • pre všetkých - pokračovať v analýze systému

- analyzovať možné úrovne katalógu požiadaviek • Marek Hrablay - návrh flash animácií pre výsladný produkt

- analyzovať produkt ACDL (www.acdl.cz) • Peter Hlocký - vylepšenie vzľadu HTML stránky tímu • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie

- analýza existujúcich riešení • Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML

- dokončenie plagátu tímu - vytvorenie a rozposlanie základnej úrovne katalógu požiadaviek

• Marcel Mésároš - analýza formátovania výslednej prezentácie - analyzovať produkt CISCO

Zápisnicu vypracoval: Marek Hrablay

http://www.acdl.cz


5


Marek Hrablay Peter Hlocký

Viliam Bedeč Tomáš Chmel Marcel Mésároš

Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Rozdelenie úloh na analýzu podľa osnovy • Prezentovanie základného návrhu aplikácie na tvorbu prezentácie • Diskusia o návrhu Stav plnenia úloh z minulého týždňa • Marek Hrablay - analýza produktu ACDL

- analýza existujúcich riešení ??? (riešené) • Peter Hlocký - vytvoriť web prezentáciu (OK) • Viliam Bedeč - skúmať možnosti implementácie konštruktora prezentácie

(riešené) - analýza existujúcich riešení aplikácii pre tvorbu prezentácii (OK) - vytvorenie a rozoslanie katalógu požiadaviek (OK)

• Tomáš Chmel - skúmať možnosti implementácie prekladača do HTML (riešené)

- dokončenie plagátu tímu (OK) • Marcel Mésároš - návrh grafickej úpravy dokumentácie (OK) Priebeh Stretnutia: • Vilam Bedeč prezentoval základnú osnovu analýzy. Popísal jednotlivé jej

body analýzy. • Rozdelili sme si jednotlivé body analýzy s tým, že nasledujúci týždeň každý

donesie svoju časť vypracovanú a prečítame si ich navzájom, aby sme našli chyby.

• Viliam Bedeč prezentoval základnú koncepciu práce aplikácie, tvorbu prezentácie a celkovú filozofiu práce s aplikáciou. Po tomto prednese nastala hodinová diskusia o možnostiach, ktoré vyplývajú z daného riešenia.


6

Závery a pripomienky: • Rozdelili sme si časti analýzy a nasledujúci týždeň donesieme vypracované

časti • Upravili sme základný návrh aplikácie • Viliam Bedeč zakomponuje do návrhu pripomienky, ktoré boli opodstatnené • Pomocou diskusie sa všetci členovia týmu dozvedeli ako bude realizovaná

aplikácia a tvorivou diskusiou pridali ďalšie vylepšenia do návrhu Rozdelenie úloh do budúceho týždňa: • pre všetkých - spísať základnú analýzu problému • Marek Hrablay - analýza výučby pomocou e-learningu

- použitie multimediálnych technológii v e-learningu • Peter Hlocký - úvod do analýzy a popis predmetu Architektúra počítačov • Viliam Bedeč - analýza existujúcich aplikácii na tvorbu prezentácii

- zhrnutie výsledkov analýzy na návrh novej prezentácie - rozposlanie osnovy analýzy a zápisnice zo stretnutia

• Tomáš Chmel - dopracovať katalóg požiadaviek - dokončenie plagátu tímu

• Marcel Mésároš – analýza existujúcich prezentácii na internete - zhrnutie výsledkov na návrh novej prezentácie

Zápisnicu vypracoval: Viliam Bedeč 4.4 Zápisnica zo stretnutia ÚVTP č. 4 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 4.11.2003 Čas: 10:10 – 11:40 Prítomní:

Ing. Ján Hudec – vedúci tímového projektu Bc. Marek Hrablay ([email protected]) Bc. Peter Hlocký ([email protected])


Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Vyhodnotenie stavu opisu problematiky - uzavretie • Posledné úpravy katalógu požiadaviek • Dohoda na scenároch použitia • Rozprava o obsahu hrubého návrhu • Rozprava o obsah dokumentácie k riadeniu • Zadanie úloh pre jednotlivých členov tímu.







7

Stav plnenia úloh z minulého týždňa • Marek Hrablay - analýza existujúcich foriem e-learningu (OK – vytvorený text, ktorý bude uvedený v opise problematiky) • Peter Hlocký - úvod do problematiky (OK – vytvorený úvodný text, ktorý bude uvedený v opise problematiky ) • Viliam Bedeč - analýza existujúcich produktov elektronického vzdelávania (OK - vytvorený text, ktorý bude uvedený v opise problematiky) • Tomáš Chmel - Vytvorenie katalógu požiadaviek (Bola vytvorená základná vrstva katalógu požiadaviek a jeho hlavných podúrovní. Na stretnutí bol doplnený podrobnejšími požiadavkami tak, aby bol pripravený na budúci týždeň) • Marcel Mésároš - Analýza a hrubý návrh možností formátovania (Analýza bola kompletne dokončená a návrh je vo fáze dokončovania.) Priebeh Stretnutia: • Vyhodnotili sme stav úloh. Každý dostal za úlohu spísať doteraz vykonanú

prácu do formátovaného textu, aby bolo možné na budúci týždeň pristúpiť k tlačeniu dokumentu.

• Dohoda o obsahu dokumentácie : Časť 1 (opis problematiky) 1.1 – Výučba predmetov 1.2 - Formy e-learningu 1.3 – Existujúce formy elektronických prezentácií 1.4 - Analýza vzdelávacích produktov CISCO a ACDL Čast 2 (analýza) : 2.1 – katalóg požiadaviek 2.2 – Scenáre použitia 2.3 – Analýza formátovania 2.4 – Interview s Ing. J. Hudecom Časť 3 (Hrubý návrh) : 3.1 – Pohľad na systém (hrubá architektúra) 3.2 – Funkčný diagram (diagram používateľov) 3.3 – 1. Modul – strana pedagóga 3.4 – 2. Modul – konverzná utilita 3.5 – 3. Modul - prezentácia

• Dohoda termínov :

Do 10.11.2003 (pondelok), 18:00 – odovzdať všetky materiály na formátovanie Marcelovi Do 12.11.2003 (streda), 20:00 – odovzdať zformátované materiály Petrovi na vytlačenie Do 14.11.2003 (piatok), 13:00 – odovzdať dokumentáciu J. Hudecovi

• Interview s Ing. J. Hudecom o podrobných požiadavkách na systém.


8

Závery a pripomienky: • Boli jednoznačne určené ciele do ďalšieho týždňa. • Celý nasledujúci týždeň sa bude niesť v duchu tvorby a formátovania

finálnej dokumentácie na odovzdanie • Boli dopracované požiadavky do katalógu požiadaviek na základe informácií

z interview. Tým bol vytvorený podrobný katalóg požiadaviek Rozdelenie úloh do budúceho týždňa: • Marek Hrablay - Úvod k dokumentácii riadenia

- Zformátovať dokumentáciu riadenia - Spracovať interview • Peter Hlocký - Doplnenie katalógu požiadaviek

- Podrobný plán do konca semestra - Napísať kapitolu 3.2 – Funkčný diagram • Viliam Bedeč - Napísať kapitolu 2.2 – Scenáre použitia

- Napísať kapitolu 3.1 – Hrubý návrh – architektúra systému - Napísať kapitolu 3.3 – 1. Modul

• Tomáš Chmel - Dokončiť katalóg požiadaviek - Napísať kapitolu 3.2 – Hrubý návrh konverzná utilita

• Marcel Mésároš - Napísať kapitolu 1.4 – analýza vzdelávacích produktov CISCO a ACDL

- Napísať kapitolu 2.3 – Analýza formátovania - Napísať kapitolu 3.5 – 3. Modul – Prezentácia - Vytvoriť preberacie dokumenty - Vytvoriť metódy a šablóny pre dokumentáciu riadenia Zápisnicu vypracoval: Peter Hlocký


9


Bc. Marek Hrablay Bc. Peter Hlocký

Bc. Viliam Bedeč Bc. Tomáš Chmel

Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Kompletizovanie dokumentácie k prvému kontrolnému bodu • Zadanie úloh pre jednotlivých členov tímu. Stav plnenia úloh z minulého týždňa • Marek Hrablay - Úvod k dokumentácii riadenia (OK)

- Zformátovať dokumentáciu riadenia (OK) - Spracovať interview (OK) • Peter Hlocký - Doplnenie katalógu požiadaviek (OK)

- Podrobný plán do konca semestra (OK) - Napísať kapitolu 3.2 – Funkčný diagram (vypustená) • Viliam Bedeč - Napísať kapitolu 2.2 – Scenáre použitia (OK)

- Napísať kapitolu 3.1 – Hrubý návrh – architektúra systému (OK) - Napísať kapitolu 3.3 – 1. Modul -Editor (OK)

• Tomáš Chmel - Dokončiť katalóg požiadaviek (OK) - Napísať kapitolu 3.2 – Hrubý návrh konverzná utilita (OK)

• Marcel Mésároš - Napísať kapitolu 1.4 – analýza vzdelávacích produktov CISCO a ACDL (OK) - Napísať kapitolu 2.3 – Analýza formátovania (OK)

- Napísať kapitolu 3.5 – 3. Modul – Prezentácia (OK) - Vytvoriť preberacie dokumenty (OK) - Vytvoriť metódy a šablóny pre dokumentáciu riadenia

(OK)


10

Priebeh Stretnutia: • Vyhodnotili sme stav úloh. Každý spísal časť prideleného textu a odoslal ju

Marcelovi, ktorý ju má za úlohu zformátovať do výslednej podoby a pripraviť na vytlačenie. Z dôvodu jeho práce na tejto úlohe bola jeho prítomnos ť na stretnutí ospravedlnená.

• Na žiadosť správy od Marcela, mu boli opätovne poslané niektoré časti

dokumentu, ktoré zrejme zablúdili na ceste Internetom spolu s upresňujúcimi inštrukciami.

• Dohoda termínov :

Do 12.11.2003 (streda), 20:00 – odovzdať zformátované materiály Petrovi na vytlačenie Do 14.11.2003 (piatok), 13:00 – odovzdať dokumentáciu J. Hudecovi a Tímu č.12 na posúdenie

Závery a pripomienky: • Boli jednoznačne určené ciele do ďalšieho týždňa. • Nasledujúci týždeň sa bude dokončovať finálne formátovanie dokumentácie

a príprava na podrobný návrh systému pre tvorbu multimediálnych prezentácií.

Rozdelenie úloh do budúceho týždňa: • Marek Hrablay - Vytvorenie Flash Animovanej ukážky

- Doplniť dokumentáciu riadenia projektu - Získanie študijných materiálov pre predmet Architektúra počítačov vhodné pre protyp

• Peter Hlocký - Vytlačenie dokumentácie pre prvý kontrolný bod - Získanie študijných materiálov pre predmet Architektúra počítačov

• Viliam Bedeč - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Tomášom Chmelom

• Tomáš Chmel - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Viliamom Bedečom

• Marcel Mésároš - Dokončiť formátovanie dokumentácie pre prvý kontrolný bod - Detailný návrh formátovania výslednej prezentácie

Zápisnicu vypracoval: Tomáš Chmel


11


Bc. Marek Hrablay Bc. Peter Hlocký

Bc. Viliam Bedeč Bc. Tomáš Chmel Bc. Marcel Mésároš

Program stretnutia: • Prezentácia splnenia úloh z minulého týždňa • Rozprava o dátovom a funkčnom modely vytváraného systému • Návrh funkcií prototypu • Zadanie úloh pre jednotlivých členov tímu. Stav plnenia úloh z minulého týždňa • Marek Hrablay - Doplniť dokumentáciu riadenia projektu

(OK) - Získanie študijných materiálov pre predmet Architektúra počítačov vhodné pre protyp (pokračuje)

• Peter Hlocký - Vytlačenie dokumentácie pre prvý kontrolný bod (OK) - Získanie študijných materiálov pre predmet Architektúra počítačov (pokračuje)

• Viliam Bedeč - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Tomášom Chmelom (OK)

• Tomáš Chmel - Vytvorenie návrhu dátového a funkčného diagramu v spolupráci s Viliamom Bedečom (OK)

• Marcel Mésároš - Dokončiť formátovanie dokumentácie pre 1. kontrolný bod (OK) - Detailný návrh formátovania výslednej prezentácie (OK)


12

Priebeh Stretnutia: • Vyhodnotili sme stav úloh. Prioritne sme sa zaoberali stavom odovzdanej

dokumentácie k prvému kontrolnému bodu. Padli niektoré pripomienky ku štruktúre dokumentácie, ktoré začleníme do kontrolného bodu č. 2.

• Diskusia o dokumentácii konkurenčného tímu. Preberali sme pritom hlavne klady a zápory, na ktoré sme narazili počas prehliadky dokumentu.

• Začala sa rozprava o aktuálnom stave rozpracovania modelov systému. Tomáš prezentoval aktuálny stav dátového ER diagramu, Viliam načrtol hrubú štruktúru DFD diagramu.

• Ďalej sme pokračovali v príprave prototypu. Príprava dát sa presunula na

ďalší týždeň vzhľadom na to, že sa nám nepodarilo zastihnúť J. Hudeca. Diskutovali sme ďalej o funkciách, ktoré by mal prototyp obsahovať, ako aj o vizuálnej stránke systému.

• Záver stretnutia sme venovali príprave na prezentáciu stavu projektu 24.11.2003. Dohodli sme sa na forme vystúpenia ako aj na rozdelení tém a vytvorení priesvitiek na prezentáciu.

Závery a pripomienky: • Funkčný model sa javí ako príliš komplexný, bude treba zjednoduši ť niektoré

časti. • Dátový model sa bude odvíjať z hrubého náčrtu tried prototypu, ktorý

navrhol Viliam Bedeč. • Prototyp by mal obsahovať základné zložky prezentácie, čiže aspoň náčrt

štruktúry kapitol, text, obrázok a animáciu. Presnú špecifikáciu prototypu budeme hľadať budúci týžden.

Rozdelenie úloh do budúceho týždňa: • Marek Hrablay - Vypracovať podrobný dátový model systému (s Vilom)

- Získanie študijných materiálov pre predmet Architektúra počítačov vhodné pre protyp

• Peter Hlocký - Vypracovať podrobný funkčný model systému (s Tomášom) - Vypracovanie posudku k dokumentácii konkurenčného tímu

• Viliam Bedeč - Vypracovať podrobný dátový model systému (s Marekom) - Pokračovať v špecifikácii prototypu

• Tomáš Chmel - Vypracovať podrobný funkčný model systému (s Petrom) • Marcel Mésároš - Vypracovať kapitolu štábna kultúra v riadení projektu

- Návrh výslednej prezentácie vhodný pre prototyp Zápisnicu vypracoval: Marek Hrablay


13




Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Zhrnutie poznatkov pre tvorbu DFD a E-R diagramu • Diskusia s vedúcim tímového projektu o prototype a posudku • Identifikácia základných požiadaviek na prototyp • Reakcia na posudok a vyjadrenie jednotlivých členov tímu k posudku

konkurenčného tímu • Bol prezentovaný počiatočný návrh vzhľadu prezentácie • Zadelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay - Vypracovať podrobný dátový model systému (s Vilom)

(OK) - Získanie študijných materiálov z predmetu APS pre potreby prototypu (OK)

• Peter Hlocký - Vypracovať podrobný funkčný model systému (s Tomášom) (OK) - Vypracovanie posudku k dokumentácii konkurenčného tímu (OK)

• Viliam Bedeč - Vypracovať podrobný dátový model systému (s Marekom) (OK)

- Pokračovať v špecifikácii prototypu (OK) • Tomáš Chmel - Vypracovať podrobný funkčný model systému (s Petrom)

(OK) • Marcel Mésároš - Vypracovať kapitolu štábna kultúra v riadení projektu

(OK) - Návrh výslednej prezentácie vhodný pre prototyp (riešené)


14

Priebeh Stretnutia: • Vilam Bedeč a Marek Hrablay prezentovali návrh entitno-relačného

diagramu. • Tomáš Chmeľ a Peter Hlocký prezentovali návrh DFD. • Zhrnuli sme poznatky z diagramov a vzhľadom na nutnosť programovať

prototyp, úloha vytvoriť finálne verzie pripadla na Mareka – DFD a Petra – entitno-relačný diagram.

• Po príchode ing. Jána Hudeca sme prebrali otázku odovzdania rekcie na posudok a hodnotenie našej dokumentácie. Opísali sme ako chceme zjednodušiť náš finálny produkt, pretože jeho obšírnosť by mohla spôsobiť neschopnosť odovzdať funkčný produkt na posledný termín. Okrem toho sme prezentovali aj funkcie, ktoré chceme implementovať do prototypu.

• Po odchode vedúceho tímu sme si rozdelili úlohy pre tvorbu prototypu. Vilo bude robiť editor na tvorbu prezentácii a Tomáš konverznú utilitu. Marcel vytvorí design výslednej prezentácie.

• Nakoniec sme zhrnuli pripomienky k posudku konkurenčného tímu a dohodli sa, že Peter vypracuje reakciu na posudok.

• Marcel ukázal základný vzhľad prezentácie a ostatní členovia sa k nemu vyjadrili

Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Definovali sme si úlohu prototypu • Návrh DFD a E-R diagramu sa dostal do finálnej fázy Rozdelenie úloh do budúceho týždňa: • pre všetkých -- spísať základnú analýzu problému • Marek Hrablay -- finalizácia DFD diagramu

-- tvorba Flash animácie • Peter Hlocký -- finalizácia E–R diagramu • Viliam Bedeč – tvorba prototypu prostredia pre tvorbu prezentácie • Tomáš Chmel – tvorba prototypu konverznej utility • Marcel Mésároš – analýza a návrh formátovania prezentácie

– úprava dizajnu výslednej prezentácie Zápisnicu vypracoval: Viliam Bedeč


15


Ing. J. Hudec Marek Hrablay Peter Hlocký


Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentácia vytvorených DFD diagramov a diagramu tried • Prezentácia 1. fázy prototypu • Prezentácia šablóny • Rozčlenenie dokumentácie do konca semestra – pridelenie autorov • Pridelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay -- finalizácia DFD diagramu – diagram vytvorený – s

chválený s niekoľkými pripomienkami - OK -- tvorba Flash animácie – bola určená téma, ktorej sa animácia bude venovať. Preložené do nasledovného týždňa

• Peter Hlocký -- finalizácia E–R diagramu – diagram bol prerobený na diagram tried, ktorý lepšie vystihuje daný problém – bol schválený - OK

• Viliam Bedeč – tvorba prototypu prostredia pre tvorbu prezentácie – prvá fáza implementácie prebehla úspešne – bola prezentovaná – (viď nižšie) - OK

• Tomáš Chmel – tvorba prototypu konverznej utility – prvá fáza implementácie úspešne prebehla - OK

• Marcel Mésároš – analýza a návrh formátovania prezentácie – bola vytvorená prvá šablóna pre formátovanie prezentácie prototypu - OK – úprava dizajnu výslednej prezentácie - OK

Priebeh Stretnutia: • Bol prezentovaný implementovaný prototyp. Editovacie prostredie sp ĺňa

základné požiadavky naň kladené a konverzná utilita implementovaná Tomášom bez problémov funguje.

• Boli pripomienkované detailnejšie požiadavky na prototyp, ktoré budú implementované v budúcom týždni


16

• Peter prezentoval diagram tried. Tento bol pretransformovaný z entitino – relačného diagramu kvôli lepšej názornosti. Tím sa zhodol, že diagram dobre znázorňuje problematiku a je prehľadný. S miernymi pripomienkami može byť použitý do dokumentácie.

• Marek odprezentoval DFD diagram. Tento bol rozpracovaný na 2. úroveň (0. úr. je kontextová). Tím sa zhodol, že podrobnejší diagram nemá zmysel v tejto fáze robiť a tento stav dobre znázorňuje problematiku.

• Po príchode Ing. Hudeca mu boli prezentované všetky diagramy a prototyp. Vyjadril spokojnosť s odvedenou robotou.

• Na záver sme rozdelili úlohy do budúceho týždňa (viď závery a pripomienky).

Závery a pripomienky: • Dokumentácia bude obsahovať tieto kapitoly (priložené k už vytvorenej

dok.): 3.5 – Model funkcií (autor Marek Hrablay) 3.6 – Model údajov (autor Peter Hlocký) 3.7 – Návrh šablón (autor Marcel Mésároš) 4 – Prototypovanie 4.1 – Ciele prototypovania (autor Peter Hlocký) 4.2 – Vyhodnotenie prototypovania (systém) (autor Villiam Bedeč) 4.3 – Vyhodnotenie prototypovania (prezentácia) (autor Marcel Méšároš)

• Dokumentácia k riadeniu bude rozšírená o nové zápisnice, priebeh riešenia

projektu a formálne dokumenty (zodpovedný Marek Hrablay) • Do 9.12.2003 musí byť vytvorená finálna verzia prototypu (zodpovedný

Viliam Bedeč). • S ing. Hudecom sme sa dohodli na prezentácii finálnej verzie prototypu dňa

15.12.2003 o 10:00 Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- vytvorenie dokumentácie k riadeniu

-- vytvorenie kapitoly 3.5 • Peter Hlocký -- vytvorenie kapitoly 3.6, 4.1 • Viliam Bedeč – dokončenie prototypu

-- vytvorenie kapitoly 4.2 • Tomáš Chmel – dokončenie prototypu – časť konverzná utilita • Marcel Mésároš – vytvorenie kapitoly 3.7 a 4.3

– dokončenie implementácie šablóny pre prototyp Zápisnicu vypracoval: Peter Hlocký


17

4.9 Zápisnica zo stretnutia ÚVTP č. 9 Zápisnica zo stretnutia ÚVTP č. 9 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 9.12.2003 Čas: 10:15 – 10:45 Prítomní:



Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentácia 2. fázy prototypu • Kontrola stavu podkladov pre dokumentáciu a prototyp na kontrolný termín • Pridelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay -- vytvorenie dokumentácie k riadeniu – prakticky hotová,

chýba posledná zápisnica a problém s pripojením kapitoly Štábna kultúra – pripojí sa ku kompletnej -- tvorba Flash animácie – nedodané podklady, vytvorená iná -- vytvorenie kapitoly 3.5 – splnená

• Peter Hlocký -- vytvorenie kapitoly 3.6, 4.1 – splnená • Viliam Bedeč – dokončenie prototypu – po doladení splnená

-- vytvorenie kapitoly 4.2 – splnená • Tomáš Chmel – dokončenie prototypu – časť konverzná utilita – práce

budú pokračovať až do termínu odovzdania • Marcel Mésároš – vytvorenie kapitoly 3.7 a 4.3 – nesplnené, nutné dokončiť

do termínu odovzdania – dokončenie implementácie šablóny pre prototyp – pokračuje, zdržanie spôsobené negociačným procesom s konkurenčným tímom ohľadom kompatibility šablón

Priebeh Stretnutia: • Bola odprezentovaná druhá fáza prototypu. Rozšírenie o správu nadpisov. • Vzájomne sme sa informovali o plnení úloh • Navrhli sme vedúcemu projektu hodnotenie práce za etapu špecifikácie a

prototyp • Pokúsili sme sa začleniť animáciu do výslednej prezentácie


18

• Dohodnutie technických detailov okolo dokumentácie • Na záver sme rozdelili úlohy do budúceho týždňa (viď závery a

pripomienky). Závery a pripomienky: • Potreba dotiahnuť detaily na prototype – ikony, nestabilita pri

maximalizovaní okna • Rozdelenie hodnotenia práce:

o špecifikácia: § Peter 25 % § Marek 25 % § Vilo 15 % § Tomáš 15 % § Marcel 20 %

o prototyp: § Peter 10 % § Marek 10 % § Vilo 30 % § Tomáš 30 % § Marcel 20 %

• Nepodarilo sa jednoducho začleniť animáciu do prezentácie • Rozdelenie tlače dokumentácie medzi Mareka a Tomáša; podklady dostanú

od Marcela Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- vytvorenie animácie k jednej vybranej časti 2. kapitoly

učebných materiálov -- dokončenie dokumentácie k riadeniu

• Peter Hlocký -- dohľad nad dokončovacími prácami na dokumentácii • Viliam Bedeč – doladenie prototypu • Tomáš Chmel – dokončenie prototypu – časť konverzná utilita • Marcel Mésároš – vytvorenie kapitoly 3.7 a 4.3

– dokončenie implementácie šablóny pre prototyp – pripravenie 2. kapitoly učebných materiálov pre prezentáciu

Zápisnicu vypracoval: Marcel Mésároš


19




Program stretnutia: • Vyhodnotenie zimného semestra • Prezentácia 2. fázy prototypu • Kontrola stavu podkladov pre dokumentáciu a prototyp na kontrolný termín • Pridelenie úloh na nasledujúci týždeň Priebeh Stretnutia: • Oboznámili sme sa s hodnotením zimného semestra • Určili sme si náš plán a postup práce pri dokončovaní projektu (viz. Plán na

web stránke) • Informovali sme vedúceho projektu a našej predstave pokračovania práce

na projekte • Bola určená časť skrípt ktorá bude spracovaná naším týmom • Na záver sme rozdelili úlohy do budúceho týždňa Závery a poznámky: • Náš tím bude spracovávať druhú polovicu skríp Počítače. Kapitola 4.4 až do

konca. Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- návrh abstraktného dátového typu - strom • Peter Hlocký -- návrh abstraktného dátového typu - index • Viliam Bedeč – návrh abstraktného dátového typu – zreťazená volná

pamäť • Tomáš Chmel – zjemnenie DFD konverznej utility • Marcel Mésároš – návrh a vytvorenie ukážky ku navigovaniu v prezentácii

pomocou JavaScriptu – návrh formátovania výsledného HTML dokumentu pomocou kaskádových štýlov na úrovni jednotlivých komponent



20

4.11 Zápisnica zo stretnutia ÚVTP č. 11 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 2. 3. 2004 Čas: 13:05 – 13:45 Prítomní:



Program stretnutia: • Kontrola plnenia zadaných úloh • Informovanie vedúceho projektu o problémoch pri prístupe k elektronickej

verzii skrípt • Pridelenie úloh na nasledujúci týždeň Stav riešenia úloh: • Marek Hrablay -- návrh abstraktného dátového typu - strom – splnené • Peter Hlocký -- návrh abstraktného dátového typu - index – splnené

(problémy s triedením s diakritikou sa riešia) • Viliam Bedeč – návrh abstraktného dátového typu – zreťazená voľná

pamäť – splnené • Tomáš Chmel – zjemnenie DFD konverznej utility – splnené • Marcel Mésároš – návrh a vytvorenie ukážky k navigovaniu v prezentácii

pomocou JavaScriptu – rieši sa – návrh formátovania výsledného HTML dokumentu pomocou kaskádových štýlov na úrovni jednotlivých komponent – splnené

Závery a poznámky: • Vedúci projektu sa pokúsi pomôcť získať elektronickú verziu skrípt

z Architektúry počítačov • Druhá kapitola bude hotová do budúceho stretnutia • Stretnutie nabudúce nebude Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- návrh vizuálnej stránky animácií • Peter Hlocký -- index – doriešenie triedenia s diakritikou • Viliam Bedeč – zreťazenie komponent a obrazoviek • Tomáš Chmel – dokumentácia návrhu • Marcel Mésároš – návrh a vytvorenie ukážky ku navigovaniu

v prezentácii pomocou JavaScriptu – dokončenie 2. kapitoly skrípt

Zápisnicu vypracoval: Marcel Mésároš


21

4.12 Zápisnica zo stretnutia ÚVTP č. 12 Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 9. 3. 2004 Čas: 13:05 – 13:50 Prítomní:


Viliam Bedeč Tomáš Chmel

Program stretnutia: • Kontrola plnenia zadaných úloh • Zhodnotenie stavu implementácie • Upresnenie plánu • Pridelenie úloh na nasledujúci týždeň Stav riešenia úloh: • Marek Hrablay -- implementácia štruktúry nadpisov pomocou a.d.t. – strom

- splnené • Peter Hlocký -- riešenie problému s diakritikou a triedením - splnené • Viliam Bedeč – implementovanie zreťazenia komponent a obrazoviek

– v stave riešenia • Tomáš Chmel – zdokumentovanie návrhu konverznej utility – splnené • Marcel Mésároš – návrh a vytvorenie ukážky k navigovaniu v prezentácii

pomocou JavaScriptu – rieši sa – dokončenie spracovania druhej kapitoly skrípt Počítače

– rieši sa Závery a poznámky: • Všetky predchádzajúce úlohy implementácie boli splnené. Po dokončení

zreťazenia komponent a obrazoviek (naplánované na nasledujúci týždeň), budeme spájať súčiastky hlavného modulu a Tomáš započne implementáciu konverznej utility.

• Elektronická verzia skrípt je pripravená u doc. Krajčoviča – treba ju vyzdvihnúť.

• Začneme spracúvať skritá od kapitoly 4.4 do konca • Vilo predviedol návrh hlavnej obrazovky: S malými pripomienkami týkajúcich

sa editora html sme návrh schválili Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- dokončiť štruktúru nadpisov a zdokumentovať • Peter Hlocký -- spolu s Marcelom spracovať skriptá od kapitoly 4.4 až do

konca • Viliam Bedeč – dokončiť zreťazenie komponent a obrazoviek • Tomáš Chmel – vytvoriť html prehliadač • Marcel Mésároš – spolu s Petrom spracovať skriptá od kapitoly 4.4 až

do konca Zápisnicu vypracoval: Peter Hlocký


22

4.13 Zápisnica zo stretnutia ÚVTP č. 13

Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 16.3.2004 Čas: 13:05 – 14:10 Prítomní:



Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prebranie problému skrípt • Popis funkcií, ktoré budú implementované v prototype • Rozdelenie implementácie • Problém spracovania skrípt • Rozdelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay - dokončiť štruktúru nadpisov a zdokumentovať (OK) • Peter Hlocký - spolu s Marcelom spracovať skriptá od kapitoly 4.4 až do

konca (OK) • Viliam Bedeč - dokončiť zreťazenie komponent a obrazoviek (OK) • Tomáš Chmel - vytvoriť html prehliadač (OK) • Marcel Mésároš - navigovanie v prezentácii pomocou JavaScriptu (OK)

- spolu s Petrom spracovať skriptá od kapitoly 4.4 až do konca (OK)

Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Peťo doniesol potešujúcu správu – sú skriptá • Marek popísal ako dokončil stromovú štruktúru nadpisov • Marcel prezentoval navigáciu pomocou javascriptu • Tomáš popísal a ukázal nastavenia konverznej utility • Vilo nakoniec prezentoval ako si predstavuje ďalšie pokračovanie

v implementácii • Načrtol ako sa bude ďalej pokračovať v implementácii a ako sa opäť zadelia

úlohy medzi členov


23

Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Pri opise implementácie sme si určili priority na funkčnosť aplikácie, teda

ktorým funkciám dať prioritu • Vyriešil sa problém so skriptami, takže je možné pokračovať v tvorení

prezentácie Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- štúdium práce v prostredí C++ Builder, príprava na

prezentáciu • Peter Hlocký -- prebranie skrípt v elektronickej forme a práca na ich

spracovaní spolu s Marcelom • Viliam Bedeč – sfunkčnenie prostredia aplikácie – možnosť vytvárať

štruktúru prezentácie • Tomáš Chmel – úprava utility na tvorbu používateľského prostredia

výslednej prezentácie • Marcel Mésároš – pomoc pri formátovaní skrípt spolu s Peťom Zápisnicu vypracoval: Viliam Bedeč





Marcel Mésároš Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prebranie problému skrípt • Popis funkcií, ktoré budú implementované v prototype • Rozdelenie implementácie • Problém spracovania skrípt • Rozdelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrabaly -- štúdium práce v prostredí C++ Builder, príprava na

prezentáciu (OK) • Peter Hlocký -- prebranie skrípt v elektronickej forme a práca na ich

spracovaní (OK)


24

• Viliam Bedeč – sfunkčnenie prostredia aplikácie možnosť vytvárať štruktúru prezentácie (OK)

• Tomáš Chmel – úprava utility - tvorba používateľského prostredia výslednej prezentácie (OK)

• Marcel Mésároš – pomoc pri formátovaní skrípt spolu s Peťom (OK) Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Peter doniesol vypracovanú kapitolu 4.2 v HTML štruktúre

o Po ozrejmení situácie s HTML textom sme zistili že ďalšia práca na ňom je pre náš tím zbytočná z dôvodu nekompatibility s editorom prezentácie

o Konverzácia a následná dohoda s tímom č. 12 o pozastavení spoločnej tvorby skrípt vzhľadom na to, že pre náš projekt je nepoužiteľný formát skrípt spracúvaných tímom č. 12 (viď HTML)

o Peter sa zaviazal vytvoriť o probléme správu a referovať o ňom na ďalšom stretnutí

o kapitoly budú ďalej vytvárané v našom vlastnom formáte • Tom s Vilom prezentovali nové verzie programov spolu s podrobným

komentárom k postupu implementácie – zatiaľ všetko postupuje podľa časového plánu

• Marcel navrhol začať napĺňať obsahovú stránku prezentácie s daným prototypom aplikácie

o zamietnuté kvôli problémom s ukladaním prezentácie – v štádiu riešenia

• Rozprava o nadchádzajúcej prezentácii o spôsoboch komunikácie tímu o Marek dostal za úlohu vypracovať správu a pripraviť prezentáciu

• Rozdelenie úloh na ďalší týždeň Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Vyriešili sme problém so zbytočnou prácou s HTML textami • Progres vo vývoji aplikácie je na veľmi dobrej úrovni Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- vypracovanie prezentácie o spôsoboch komunikácie

– integrácia stromovej štruktúry do projektu • Peter Hlocký -- dokončiť kap. 4.2, urobiť kap 4.1 do podoby výslednej

prezentácie • Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov

– implementácia funkcií načítania a uloženia prezentácie • Tomáš Chmel – implementovať konverziu obrazoviek a štruktúry

komponent • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania

výslednej prezentácie rozbaľovaním hierarchie nadpisov

Zápisnicu vypracoval: Marek Hrablay


25





Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentovanie prvej verzie editora a konverznej utility • Diskusia o tematickom dizajne web stránky • Rozdelenie úloh na nasledujúci týždeň Stav plnenia úloh z minulého týždňa • Marek Hrablay -- vypracovanie prezentácie o spôsoboch komunikácie (OK)

– integrácia stromovej štruktúry do projektu (Pokračuje) • Peter Hlocký -- dokončiť kap. 4.2, urobiť kap 4.1 do podoby výsledném

prezentácie (OK) • Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov

(Pokračuje) – implementácia funkcií načítania a uloženia prezentácie (OK)

• Tomáš Chmel – implementovať konverziu obrazoviek a struktury komponent (OK)

• Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania výslednej prezentácie rozbaľovaním hierarchie nadpisov (Pokračuje)

Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Marek bol pokarhaný za neskoré dodanie zápisnice s minulého týždňa • Peter zreferoval, že správu ktorú uvažoval vytvoriť nevytvoril, nakoľko by do

danej situácie aj tak nepriniesla viacej svetla • Tom s Vilom prezentovali nové verzie programov, ktoré boli predvedené aj

vedúcemu projektu. Bola prezentovaná možnosť ukladania a začítavania projektu prezentácie.

o Pri prezentovaní konverznej utility sa objavili malé problémy a tak neboli jej možnosti zatiaľ prezentované.

• Rozprava o nadchádzajúcej prezentácii o dosiahnutom progrese na stretnutí RvPI 7.4.2004.

o Marcel dostal za úlohu vypracovať a pripraviť prezentáciu. Táto skutočnosť mu bude dodatočne oznámená

• Diskusia a hľadanie vhodného obrázku pre potreby tematického dizajnovania web stránky s blížiacou sa veľkou nocou.

• Rozdelenie úloh na ďalší týždeň


26

Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Progres vo vývoji aplikácie je na veľmi dobrej úrovni Rozdelenie úloh do budúceho týždňa: • Marek Hrablay – integrácia stromovej štruktúry do projektu • Peter Hlocký -- testovanie editoru naplnením systému kapitolou 4.1 a 4.2.

-- oboznámenie sa vývojovým prostredím Borland Builder a implementácia Indexu do editora

• Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov • Tomáš Chmel – pokračovanie v implementácii konverznej utility • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania

výslednej prezentácie rozbaľovaním hierarchie nedpisov – príprava prezentácie o dosiahnutom progrese



Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 6. 4. 2004 Čas: 13:15 – 14:00 Prítomní:



Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Informácia o stave implementácie • Hodnotenie priebežného testovania • Dohodnutie informácií, ktoré budú uvedené v prezentácii stavu projektu • Rozdelenie úloh pri príprave dokumentácie Stav plnenia úloh z minulého týždňa • Marek Hrablay – integrácia stromovej štruktúry do projektu (Pokračuje) • Peter Hlocký -- testovanie editoru naplnením systému kapitolou 4.1 a 4.2. (Nesplniteľná – nefungovali nadpisy a atribúty komponent) -- oboznámenie sa vývojovým prostredím Borland Builder a implementácia Indexu do editora. (Pokračuje)


27

• Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov (Pokračuje) • Tomáš Chmel – pokračovanie v implementácii konverznej utility (Pokračuje) • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania

výslednej prezentácie rozbaľovaním hierarchie nadpisov (Pokračuje) – príprava prezentácie o dosiahnutom progrese (OK) Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Peter nemohol splniť úlohu naplnenia a testovania, pretože program nebol v

stave, aby sa s ním dalo pracovať (chýbali základné prvky pre orientáciu v projekte – zobrazenie aspoň časti vložených textov); ďalšie nedostatky boli v neimplementovanom generovaní HTML kódu pre nadpisy a atribúty textu.

• Tom s Vilom zaznamenali a následne riešili problémy pri linkovaní oboch častí programu – zdržanie

• Stále chýba stromová štruktúra, ktorú má implementovať Marek • Rozprava o nadchádzajúcej prezentácii o dosiahnutom progrese na stretnutí

RvPI 7.4.2004. Dohodnuté prezentovanie častí oddelene (UI, KU, prezentácia); prototyp na zahodenie; na technické otázky budú odpoveda ť tí, ktorí sa v nich vyznajú.

• Rozdelenie úloh na ďalší týždeň Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Je potrebné dotiahnuť funkcie umožňujúce použiteľnosť aplikácie pre

testovanie • Rozdelenie častí dokumentácie

5. Podrobný návrh 5.1 Editor prezentácie (Vilo) 5.2 Konverzná utilita (Tom) 5.3 Prezentácia (Marcel) 6. Implementácia 6.1 Editor prezentácie (Vilo) 6.2 Konverzná utilita (Tom) 6.3 Prezentácia (Marcel) 7. Testovanie (Peter) 8. Používateľská príručka (Marek)

Rozdelenie úloh do budúceho týždňa: • Marek Hrablay – integrácia stromovej štruktúry do projektu

– príprava používateľskej príručky • Peter Hlocký – testovanie nasledujúcej verzie editoru

– príprava dotazníka na testovanie • Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov • Tomáš Chmel – pokračovanie v implementácii konverznej utility – atribúty

komponent • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania

výslednej prezentácie rozbaľovaním hierarchie nadpisov Zápisnicu vypracoval: Marcel Mésároš


28


Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Dátum: 20. 4. 2004 Čas: 13:05 – 15:00 Prítomní:



Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Príprava na odovzdanie priebežnej verzie • Zhodnotenie stavu verzie systému 0.9, ktorá sa bude odovzdávať • Prezentácie tejto verzie Ing. Hudecovi • Príprava krátkodobého plánu na nasledujúce štyri týždne • Zhodnotenie používateľskej príručky • Zhodnotenie alfa testovania verzie 0.9 Stav plnenia úloh z minulého týždňa • Marek Hrablay – integrácia stromovej štruktúry do projektu

(úloha pozastavená) – príprava používateľskej príručky (úloha splnená)

• Peter Hlocký – testovanie nasledujúcej verzie editoru (verzia 0.9 je pripravená na odovzdanie) – príprava dotazníka na testovanie (úloha splnená)

• Viliam Bedeč – implementácia editora na zmenu a úpravu komponentov (úloha splnená) • Tomáš Chmel – pokračovanie v implementácii konverznej utility – atribúty

komponent (úloha splnená) • Marcel Mésároš – pridať funkcionalitu do používateľského rozhrania

výslednej prezentácie rozbaľovaním hierarchie nadpisov (úloha splnená)

Priebeh Stretnutia: • Dohodli sme sa na krátkodobom pláne na ostatné štyri týždne :

o beta testovanie verzie systému 0.9 o naplnenie systému vzorkou údajov – kapitola 4 – skriptá o v prípade plnej funkčnosti za splnenie podmienok kladených na

softvérový produkt doplnenie funkcií – index a stromová štruktúra nadpisov.

o otestovanie systému a odovzdanie finálnej verzie • Zhodnotili sme systém VSAM v0.9 a zhodli sme sa, že po odstránení

miernych nedostatkov vyplývajúcich z alfa testov, je pripravený na odovzdanie

• Systém VSAM v0.9 sme prezentovali Ing. Hudecovi. Mierne nedostatky, ktoré sa pri neformálnej prezentácii objavili, odstránime


29

• Zhodli sme sa, že našou prvoradou úlohou je vytvoril systém plne funkčný a otestovaný, ktorý bude stabilný a tak pripravený na odovzdanie

Závery a pripomienky: Našou prvoradou úlohou je vytvoriť stabilný systém, ktorý by sme mohli vo finálnej verzii odovzdať. Preto sme pozastavili dopĺňanie funkcionality a v nasledujúcich dvoch týždňoch sa zameriame na testovanie a napĺňanie systému. Rozdelenie úloh do budúceho týždňa: • Marek Hrablay – Finalizácia používateľskej príručky

- Testovanie VSAM v0.9 • Peter Hlocký - Príprava Beta testovania - Príprava testovacích vzoriek • Viliam Bedeč – Oprava chýb nájdených alfa testom vo verzii 0.9 • Tomáš Chmel – Prirobenie konverzie rozbaľovatelného obsahu do

konverznej utility • Marcel Mésároš – Vytvorenie druhej šablóny Zápisnicu vypracoval: Peter Hlocký



Ing. Ján Hudec Marek Hrablay Peter Hlocký


Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Rozvrh prác na dokumentácii • Otázka implementácii ďalších funkcií do aplikácie • Testovanie aplikácie Stav plnenia úloh z minulého týždňa • Marek Hrablay - Finalizácia používateľskej príručky (OK)

- Testovanie VSAM v0.9 (OK) • Peter Hlocký - Príprava Beta testovania (OK)

- Príprava testovacích vzoriek (splnené a pokračuje) • Viliam Bedeč - Oprava chýb nájdených alfa testom vo verzii 0.9

(splnené a pokračuje) • Tomáš Chmel - Prirobenie konverzie rozbaľovateľného obsahu do

konverznej utility (OK) • Marcel Mésároš - Vytvorenie druhej šablóny (OK)


30

Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa • Nájdené chyby sa podarilo odstrániť, preto sa začneme venovať dokončeniu

dokumentácie • Rozdelili sme si dokumentáciu • Opäť sme si dali priority na implementáciu ďalších funkcií • Prebrali sme si chyby, ktoré sme našli počas testovania Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Počas testovania sa vyskytli opäť chyby, takže sme získali ďalšie možnosti

vylepšenia • Rozdelili sme si dokumentáciu a naplánovali jej ukončenie na ďalší týždeň Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- testovanie a naplnenie programu kapitolami 4.3 • Peter Hlocký -- naplnenie programu kapitolami 4.1 a 4.2 • Viliam Bedeč – oprava chýb a napísanie návrhu a implementácie na

editor • Tomáš Chmel – oprava chýb a úprava dokumentácie návrhu

a implementácie konvertoru • Marcel Mésároš – dokumentácia návrhu a implementácie výslednej

prezentácie Zápisnicu vypracoval: Viliam Bedeč





Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Prezentácia beta verzie VSAM • Rozvrh prác na dokumentácii • Testovanie aplikácie • Finalizácia tímového projektu Stav plnenia úloh z minulého týždňa • Marek Hrablay -- testovanie a naplnenie programu kapitolami 4.3

(pracoval na 4.2.2) • Peter Hlocký -- naplnenie programu kapitolami 4.1 a 4.2 (OK po 4.2.1)


31

• Viliam Bedeč – oprava chýb a napísanie návrhu a implementácie na editor (OK)

• Tomáš Chmel – oprava chýb a úprava dokumentácie návrhu a implementácie konvertoru (OK)

• Marcel Mésároš – dokumentácia návrhu a implementácie výslednej prezentácie (pokračuje)

Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa. • Peter a Marek prezentovali kapitoly 4.1, 4.2, a 4.3 naplnené pomocou

VSAMu. • Tom a Vilo referovali o dodatkoch k dokumentácii o návrhu a implementácii. • Vilo prezentoval ďalšiu beta verziu VSAM. • Znova sme preberali chyby, ktoré sme našli počas testovania a napĺňania

skrípt kapitolami. • Rozdelili sme si úlohy spojené s finalizáciou tímového projektu. Závery a pripomienky: • Rozdelili sme si úlohy na nasledujúci týždeň. • Ďalšie objavené chyby beta verzie VSAM a konvertora do HTML, budú

riešené do budúceho týždňa. • Ukončenie dokumentácie, rozdelenie jednotlivých častí dokumentácie na

formátovanie a prípravu na tlač. Rozdelenie úloh do budúceho týždňa: • Marek Hrablay -- napísanie dokumentácie k riadeniu projektu na letný

semester • Peter Hlocký -- prerobiť kapitoly 4.1 a 4.2

– testovanie VSAM • Viliam Bedeč – oprava drobných chýb VSAM, opraviť spájanie projektov • Tomáš Chmel – oprava chýb konverznej utility • Marcel Mésároš – formátovanie dokumentácie

-- doplnenie kaskádového štýlu o štvrtú úroveň Zápisnicu vypracoval: Marek Hrablay






32

Program stretnutia: • Vyhodnotenie úloh z predchádzajúceho týždňa • Dohodnutie termínu odovzdania a prezentácie produktu • Dohodnutie posledných úprav dokumentu a produktu • Rozdelenie percentuálneho hodnotenia členov tímu Stav plnenia úloh z minulého týždňa • Marek Hrablay -- napísanie dokumentácie k riadeniu projektu na letný semester (OK) • Peter Hlocký -- prerobiť kapitoly 4.1 a 4.2 (OK) • Viliam Bedeč – oprava drobných chýb VSAM, opraviť spájanie projektov (OK) • Tomáš Chmel – oprava chýb konverznej utility (OK) • Marcel Mésároš – formátovanie dokumentácie (OK)

-- doplnenie kaskádového štýlu o štvrtú úroveň (OK) Priebeh Stretnutia: • Vyhodnotili sme si úlohy z predchádzajúceho týždňa. • Za účasti členov tímu 12 sme sa dohodli na dátume a čase odovzdania a prezentovania

produktu – 17.5.2004 11:00. • Marcel doniesol sformátovanú dokumentáciu pripravenú na tlač, no zistilo sa, že v nej chýba

implementačná časť k editoru. • Rozhodlo sa, že funkciu pripájania projektov prezentácií bude s produktu vynechaná kvôli jej

prílišnej implementačnej zložitosti. • Zhodli sme sa na obsahu CD prílohy ku dokumentácii. Závery a pripomienky: • Obsah CD prílohy ku dokumentácii bude obsahovať:

o Dokumentáciu k produktu o Produkt ako inštalačný súbor o Posledná verzia internetovej stránky o Ukážky prezentácií vytvorených v editori a ručne o Zdrojové súbory produktu

• Percentuálne hodnotenie členov tímu: Člen Dokumentácia Produkt

Peter Hlocky 20% 20% Viliam Bedeč 10% 30% Marek Hrablay 30% 10% Tomáš Chmel 15% 25% Marel Mésároš 25% 15%

• Posledné úlohy na projekte, ktoré treba dorobiť do odovzdania, prípadne skorej: • Marek Hrablay -- vyrobenie flash animácie do ku kapitole 4.

-- prepísať používateľskú príručku pre najnovšiu verziu produktu • Peter Hlocký -- dokončenie prezentácie podľa kapitoly 4. pomocou editora • Viliam Bedeč – oprava posledných chybičiek editora

– dopísať záver ku dokumentácii • Marcel Mésároš – doplniť dokumentáciu o chýbajúce časti

• Dokumentáciu vytlačia a CD médiu vyhotovia Viliam Bedeč a Tomáš Chmel . Zápisnicu vypracoval: Tomáš Chmel


1

5. Posudky V tejto kapitole sú uvedené všetky doposiaľ vytvorené posudky. Jedná sa

o posudky jednotlivých častí nášho projektu konkurenčným tímom, posudky jednotlivých častí konkurenčného projektu našim tímom ako aj vyjadrenia nášho tímu k jednotlivým posudkom.


2

5.1 Posudok konkurenčného projektu, 1. kontrolný bod Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Autorský tím : Tím č. 12 Dátum: 20.11.2003 Posudzoval: Tim č.9 Autor: Peter Hlocký OBSAHOVÁ STRÁNKA Nakoľko dokumentácia k vývoju softvérového systému začína číslovaním kapitol obsahom, prejdeme rovno ku kapitole 2 – Analýza požiadaviek. Autori zaradili na začiatok tejto kapitoly úvod do problematiky. Tento je napísaný prehľadne a dobre približuje čitateľovi diskutovaný problém. Obzvlášť by sme chceli vyzdvihnúť podkapitolu 2.3 – prístup k multimediálnym kurzom, ktorá veľmi dobre opisuje prehľad životného behu elektronickej výučby. Chceli by sme sa však pozastaviť pri podkapitole 2.5 – Analýza existujúcich systémov, konkrétne Cisco Networking Academy Program. Táto časť popisuje vzdelávací program, avšak nie je z nej zrejmé ako to súvisí s elektronický vzdelávaním. Po prečítaní textu vzniká skôr dojem, že ide o denné štúdium. Celkovo by sa dalo k analýze existujúcich riešení povedať, že aj keď riešenia predstavila, neposkytla žiadne východiská. Bolo by vhodné spomenúť výhody a nevýhody jednotlivých riešení a prípadné výhody využiť vo vytváranom systéme. Využijú autori nejaké poznatky nadobudnuté analýzou alebo bola zbytočná? Ku kapitole 3 – Špecifikácia požiadaviek máme tieto pripomienky. Autori identifikovali niektoré požiadavky, avšak všetky sú funkcionálne. Na systém nie sú kladené iné druhy požiadaviek, napríklad bezpečnostné, systémové atď.? Čo sa týka uvedených požiadaviek : je ich šestnásť, ktoré popisujú funkcie systému, avšak možno by mohli byť bližšie popísané. Napríklad požiadavka č.1 – vytvoriť kapitolu. Z popisu nie je jasné či systém poskytuje napr. voľbu číslovania kapitol alebo ako je to s hierarchickým členením kapitol. Tento príklad uvádzame predovšetkým preto, aby sme upozornili, že zoznam požiadaviek by mal obsahovať podrobne rozpracované požiadavky. Existuje možnosť vytvorenia katalógu požiadaviek , kde sa môžu požiadavky hierarchicky členiť, čo pomáha pri orientovaní. Časť 3.4 – špecifikácia používateľov systému uvádza dva druhy používateľom, avšak nie sú jednoznačne určené ich názvy, čo sťažuje orientáciu v ďalšom texte. V nasledujúcej časti 3.5 je uvedené, že prezentácia je prístupná cez voľne dostupný internetovský prehľadiač, avšak potom vyvstáva otázka, či študent prezentácie, je používateľom vytváraného systému, ak využíva iba jeho výstup (ako bolo uvedené v časti 3.4 „... nebudú mať možnosť ani dôvod meniť obsah a štruktúru jednotlivých častí.“). V kapitole 4 – Návrh je zrejmá absencia časti, ktorá by čitateľovi priblížila hrubý náhľad na systém. Konkrétne by mohla obsahovať hrubú blokovú architektúru systému, ktorá by čitateľa bližšie dostala k nasledovne diskutovanému problému pri funkčnom a dátovom návrhu. Autori sa zrejme o toto pokúsili v podkapitole 4.2 – dekompozícia systému, avšak určite sa nehodí hneď do článku 4.2.1 vložiť pojednanie o súborovej správe prezentácie a probléme rušenia krížových referencií v kapitolách. Toto sú užšie problémy, na ktoré je miesto v pokročilejších fázach riešenia. V časti 4.2.2 sú spomenuté prvky obrazovky ako navigátor, navigačné tlačítka a iné. Prečo nie sú uvedené medzi požiadavkami na systém v kapitole 3?

Podkapitola 4.3 pojednáva o prípadoch použitia systému. Keď sa používa táto technika, je vhodné uviesť aj roly používateľov. Tie síce sú uvedené v kapitole 3, ale


3

názvy používateľov sú uvedené iné ako sú použité v samotnom diagrame a potom nie je jasné, kto je kto. Dostali sme sa k diagramu prípadov použitia systému tvorby prezentácií, ktorý je zobrazený na obr. 4.1 v dokumentácii. Sú tu uvedené prípady, ktoré však po dekomponovaní dávajú funkcie, ktoré nie sú nikde popísané. Máme predovšetkým na mysli vzťah k už spomínanej špecifikácii požiadaviek. Obr 4.2 znázorňuje prípady použitia systému na prehliadanie prezentácií. Prehliadanie prezentácií nie je prístupné role s popisom „pedagóg“ (nakoľko v diagrame nie je)?

Teraz by sme sa radi vyjadrili k podkapitole 4.4 – Diagramy tokov údajov. Ku kontextovému diagramu (obr. 4.3) by sme radi pripomenuli, že by sa tu mal vyskytovať iba jediný proces, ktorý reprezentuje celý systém. Nasledovne v nižších úrovniach diagramu nie je dobré dávať externé entity (ako vidíme na obr. 4.4 až 4.7). Tie by mali komunikovať iba na kontextovej úrovni s hlavným procesom. Obr. 4.4 - Ako môže z úložiska dát „Prezentácie“ vychádzať údaj „test kapitoly“? Obdobný problém sa vyskytuje aj v ostatných diagramoch. Tiež sa vyskytol problém (obr. 4.5) s úložiskom „prezentácie“, z ktorého nevychádza žiaden tok údajov. Celkovo by sa dalo povedať, že diagram tokov údajov nie je vytvorený najvhodnejšie, čomu prispela aj veľká neprehľadnosť. Neboli použité číslovanie procesov a úložiská údajov z vyšších úrovní sa bežne vyskytujú na nižších úrovniach.

Prejdime k modelu údajov popisovanom v podkapitole 4.5 – údaje v systéme. Na úvod by sme radi spomenuli, že model údajov, podobne ako model funkcií (diagram tokov údajov) nie je spracovaný dobre. Vytknúť sa mu dajú predovšetkým zásadné chyby, ktoré by sa tu nemali vyskytnúť. Model údajov nemôže obsahovať atribúty, ktoré sú zároveň entitami. Ak boli tieto atribúty myslené ako cudzie kľúče, treba pripomenúť, že tie sa uvažujú až pri fyzickom modeli a nie už pri modeli logickom. Vysvetlenie nepriniesol ani popis atribútov entít, ktorý je spracovaný biedne a takže vlastne ani nemusel byť v dokumentácii uvedený. Tiež je dobrým zvykom popisovať vzťahy medzi entitami, ktoré tu úplne chýbajú. Entita „test“ obsahuje atribúty „otázky“, „možnosti“ a pod.. Toto sú zrejme textové komponenty a asi by mal byť znázornený vzťah s entitou, ktorá by ich vystihovala (asi mali autori na mysli vyjadrenie cez kompozíciu a entitu „Element“... na čo sú tam potom tie atribúty?). Vzťah generalizácie medzi entitou „Test“ a „Dokument“ nechápeme. V predloženom modely údajov by sa dalo nájsť viac chýb, avšak zrejme už nemá zmysel ich vymenovávať všetky. Nedá nám ale nepripomenúť nevhodný príklad kompozície na strane 4.18. K obsahovej stránke dokumentácie k riadeniu projektu by sme mali iba výhrady k absencii podrobného plánu do konca zimného semestra. Ináč je táto časť spracovaná veľmi dobre. Týmto by sme chceli uzavrieť posudok k obsahovej stráne predloženej časti projektu s hodnotením, že autori evidentne vyvinuli značné úsilie pri tvorbe dokumentácie, čo sa prejavilo na dobrej analýze. Toto úsilie však mierne zmaril návrh, ktorý by možno bolo dobré prepracovať. Sumarizácia :

• klady o úvod do problematiky o dokumentácia k riadeniu projektu

• zápory o neúplný zoznam požiadaviek o absencia hrubého pohľadu na systém (architektúra) o diagram tokov údajov o dátový model


4

5.2 Posudok nášho projektu, 1. kontrolný bod Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Autorský tím : Tím č. 9 Dátum: 21.11.2003 Posudzoval: Tim č.12 Autori: Bc. Eduard Chrvala, Bc. Roman Páterek

5.2.1 Úvod Tento dokument je posudkom ku tímovému projektu Multimediálna podpora

predmetu Architektúra počítačov tímu č. 9. Je tu hodnotená výsledná dokumentácia konkurenčného tímu, čo sa týka formálnej a obsahovej stánky dokumentu. Posudok obsahuje náš názor a vylepšenia k jednotlivým hlavným kapitolám a ich spracovaniu, ako bol daný systém navrhnutý. Čo tam chýba a čo by tam nemuselo byť.

5.2.2 Formálna stránka dokumentu

Členenie dokumentu do kapitol a podkapitol je logické a štrukturované podľa obsahu rozoberanej témy na veľmi dobrej úrovni. Autori majú premyslený formát dokumentácie. V obsahu majú pomenované kapitoly „Špecifikácia a analýza požiadaviek“ a na str. 19 je jej meno iba „Analýza“ a takisto „Návrh požiadaviek“ ako „Prezentácia“. V posudzovanom dokumente sa nachádza zopár gramatických chýb. Str. 3, str. 7. Vety v dokumente sú dlhé a sem tam formulované mierne nejednoznačné, ale správnu informatívnu hodnotu. Vidno že na dokumente pracovalo viacero autorov, každý z nich má iný spôsob tvorenia dokumentácie. Formátovanie textu je zle čitateľné a únavné pre čitateľa, odporúčali by sme zväčšiť veľkosť písma a zarovnanie textu do bloku, nakoľko ešte dokument je dosť nekvalitne vytlačený, to zvyšuje jeho nečitateľnosť a prehľadnosť. Pri obrázkoch použitých ako náhľad str. 16,17,18,31 ... chýbajú ich čísla a stručný popis a ich označenie ku ktorému opisu problematiky patria (začlenenie odkazov v texte na obrázky). Pričom v hrubom návrhu sú dva obrázky jednoducho očíslované. Na číslovanie obsahu mali autori použiť formát čísel i,ii,iii a nie číslovať hneď od obsahu až po koniec dokumentu. Dokumentácia zverejnená na internetovej stránke tímu sa jednoznačne nezhoduje s vytlačenou dokumentáciou, chýba posledná kapitola.

5.2.3 Obsahová stránka dokumentu Obsahová stránka je spracovaná na vysokej úrovni, čo je znak toho, že na

projekte pracujú ľudia z dobrými znalosťami o danej problematike. Obsahová stránka je rozobraná v tomto dokumente jednotlivo pre každú kapitolu a sú tu spomenuté pripomienky k formálnej stránke jednotlivých kapitol.

Kapitola Úvod Po obsahovej stránke obsahuje všetky potrebné informácie.

Kapitola Opis problematiky V tejto kapitole je celkom dobre rozobraná problematika výučby predmetov a možnosti zvýšenia kvality výučby využitím počítačovej techniky. V cieľoch projektu autori nejednoznačne naznačili vetou „V každom prípade bude našou prioritou vytvoriť systém, ktorý bude v maximálnej miere spĺňať požiadavky naň kladené, ktorý bude na konci (aspoň sčasti) naplnený údajmi z obsahu predmetu Architektúra počítačov a ktorý


5

bude na konci letného semestra plne použiteľný na nasadenie.“, čo bude výsledkom ich práce. Výsledkom má byť CD nosič, ktorý bude multimediálna prezentácia o predmete Architektúra počítačov zadané na začiatku zimného semestra. Systém môže byť použiteľný aj s pár kapitolami, ale nespĺňa zadané požiadavky. Podkapitoly E-learning a školstvo, spôsoby komunikácie a jeho využitie sú pekne spracované. Autori sa zaoberali iba komerčnými prostrediami pre tvorbu prezentácií, čo je pre školskú výučbu dosť neefektívne. Pri analýze jednotlivých elektronických systémov využitých na výučbu sa nemuseli zaoberať formátovaním dokumentov.

Kapitola Katalóg požiadaviek Pomerne rozsiahla kapitola, ktorá vystihuje dostatočne do hĺbky všetky funkcie

systému. Hodila by sa skôr do návrhu a tiež čo sa týka chronologického poradia by bolo vhodnejšie keby návrh vysvetlil členenie systému na čo by potom detailne nadviazal katalóg požiadaviek.

Kapitola Scenáre použitia Takisto by sa táto kapitola hodila skôr do návrhu. Autori zvolili scenáre, ktoré sú

navzájom dosť podobné, dali by sa zvoliť aj scenáre zaujímavejších situácií. Niektoré formulácie viet nie sú celkom výstižné. Obrázok použitý v scenároch je málo reprezentatívny. Po formálnej stránke je táto kapitola na dobrej úrovni.

Kapitola Analýza formátovania Je pomerne rozsiahla a prehľadne spracovaná. Veľmi dobre sú popísané

jednotlivé doporučované konvencie formátovania textu. Mohli byť uvedené aj zásady vkladania audiovizuálnych dokumentov do textu. V kapitole chýba zoznam konvencií použitých v samotnej práci, obsahuje drobné pravopisné chyby. Paradoxne záver analýzy formátovania by mohol byť lepšie formátovaný.

Kapitola Interview s Ing. J. Hudecom Kapitola je výborným doplnkom v dokumentácií, slúži ako dobrá náhrada za

špecifikáciu požiadaviek. Jednotlivé otázky by mohli byť výraznejšie oddelené a lepšie formátované.

Kapitola Návrh Po formálnej stránke je návrh dobre členený. Hodil by sa pred katalóg

požiadaviek, čitateľovi by boli jednotlivé funkcie popisované v katalógu zrejmejšie. Úvod k návrhu by sa skôr hodil do analýzy existujúcich produktov. Dekompozícia systému je na dobrej úrovni. Niektoré vety nie sú dobre formulované, čitateľovi uniká ich význam. Použité diagramy názorne popisujú problematiku. Návrh mohol byť doplnený o model údajov aspoň najvyššej úrovne. Dva diagramy v návrhu sú číslované a v podkapitole prezentácia sa nachádza obrázok, ktorý nie je očíslovaný.

5.2.4 Záver Celkovo hodnotíme výsledný projekt konkurenčného tímu veľmi pozitívne.

Problematika je rozobraná na dobrej úrovni, čo sa týka opisu, analýzy a hrubého návrhu. Pokryli požiadavky zadávateľa projektu a navyše do daného projektu pridali svoje funkcie, ktoré obohacujú výsledný produkt. Len treba dať pozor na to, že aby tím bol schopný dokončiť funkcie systému, ktoré si tam navyše pridali, čo môže byť faktorom že nestihnú urobiť výsledný produkt v požadovanom čase.


6

5.3 Vyjadrenie sa k posudku, 1. kontrolný bod Projekt: Multimediálna podpora predmetu Architektúra počítačov (APS) Autorský tím posudku: Tím č. 12 Dátum: 29.11.2003 Autor: Peter Hlocký

Tento dokument slúži ako vyjadrenie k posudku k prvému kontrolnému termínu stavu projektu Multimediálna podpora predmetu Architektúra počítačov vyvíjaným tímom č.9. Na úvod by sme radi uviedli, že mierne nižšia štylistická úroveň posudku nás viedla k neporozumeniu niektorých, možno konštruktívnych kritík. Preto sa vyjadríme iba k nasledovným :

Súhlasíme s námietkami k nekonzistencii dokumentácie vytlačenej a uvedenej na internete. Tento nedostatok, spôsobený problémom pri prenose súboru, bol bezodkladne napravený. Rovnako pripúšťame nedostatok pri označovaní obrázkov a náprava bude zjednaná pri ďalšej verzii dokumentácie v druhom kontrolnom termíne.

Dovoľujeme si nesúhlasiť s námietkami k formátovaniu textu v časti 2 posudku. Domnievame sa, že formát dokumentácie bol vytvorený s maximálnym dôrazom na prehľadnosť a zrozumiteľnosť, a veľkosť písma je štandardná pre takýto druh textu. V časti 3.2 posudku nesúhlasíme s námietkou na zaradenie formátovania dokumentov, pretože je nedeliteľnou a podstatnou časťou nášho projektu a vhodne dopĺňa analýzu o poznatky z tejto oblasti. V časti 3.3 sa nám vyčíta zaradenie katalógu požiadaviek medzi analýzu a návrh systému. K takémuto rozhodnutiu nás viedol fakt, že katalóg požiadaviek je súhrnom všetkých požiadaviek na systém, ktoré sme identifikovali a ktoré priamo vyplynuli z analýzy. Pri návrhu potom tieto požiadavky realizujeme. Toto sú dôvody, ktoré nás viedli k rozhodnutiu uviesť katalóg požiadaviek medzi analýzu a návrh. Nemenej podstatným faktom však bola aj bežná prax takéhoto usporiadania aj skúsenejšími tímami ako sme my.

K ostatným námietkam sa vyjadrovať nebudeme, pretože vychádzajú iba z iného názoru na tvorbu dokumentácie k inžinierskemu dielu a pokladáme ich za nekonštruktívne.


1

6. Preberacie protokoly V tejto kapitole uvádzame preberacie protokoly, ktoré potvrdzujú prevzatie dokumentácie k projektu zadávateľom a zároveň aj posudzovateľom projektu. Preberacie protokoly sú vytvorené pre každý kontrolný bod, v ktorom sa preveruje stav riešenia projektu.


1

7. Štábna kultúra Na tomto mieste budú uvedené spoločné dohody pri tvorbe projektu ako aj príslušnej dokumentácie s cieľom zprehľadniť a uniformovať jednotlivé časti a umožniť tak bezproblémové zlúčenie výsledného produktu. Obsah štábnej dokumentácie: 1) Štábna kultúra dokumentácie k projektu

multimediálna podpora predmetu architektúra...

Documents