Dokument združuje výsledky analýzy existujúcich riešení vytvorených v roku 1998/1999 tímami č. 1 a 2.
Jednotlivé časti tohto dokumentu boli vypracované následovnými členmi tímu :
Tím č. 1 z roku 1998/1999 : Katedrový Informačný Systém – katedrový rozvrh Michal Čerňanský – analýza návrhu riešenia tohto projektu Viktor Beňo – analýza implementačného riešenia projektu Tím č. 2 z roku 1998/1999 : Katedrový Informačný Systém – katedrový rozvrh Peter Burger – ??? Roman Ďumbier – analýza návrhu a implementácie riešenia tohto projektu
Táto časť obsahuje súhrn požiadaviek používateľov a ich špecifikáciu, získanú tvorcami IS od pracovníkov katedry.
Požiadavky na užívateľské rozhranie :
- príjemné používateľské rozhranie
- jednoduchosť ovládania prostredníctvom menu
Funkcie systému
- zbieranie údajov do databázy
- pridávanie položiek rozvrhu ( asi vlastná tvorba rozvrhu )
- presúvanie položiek aj so vzťahmi
- automatická kontrola počas zadávania vstupných údajov
- možnosť vypnúť kontrolu kolízií
- kontrola kolízií ( interaktívna, po zadaní vstupov )
- efektívne prehľadávanie a prezeranie údajov
- oprava chýb ( mená, názvy, ... )
- výstup rozvrhu na obrazovku a tiež na tlačiareň
Údaje v databáze
- miestnostiach
- prednášajúcich
- krúžkoch
- študentoch
- predmetoch
Druhy kontrolovaných kolízií
- pedagóg nemôže byť v jednom čase v dvoch miestnostiach
- krúžok nemôže byť v jednom čase v dvoch miestnostiach
- miestnosť nemôže byť v jednom čase použitá na výuku dvoch predmetov
Iné
- cvičiaci môže mať naraz cvičenie z jedného predmetu v dvoch miestnostiach
- prezeranie pod rozličnými OS ( Unix – Lynx, Netscape, Explorer )
- verejný prístup k báze údajov s možnosťou prezerania v rámci katedry, fakulty a širšie
- autentifikovaný prístup k báze údajov s možnosťou zmeny iba na to oprávneným osobám
Takto definovaná špecifikácia je jasná a pomerne kompletná. Možno ju použiť v rámci našeho projektu s týmito rozšíreniami a úpravami. presnejšie popísať užívateľské rozhranie na základe želania zákazníka ( okná – veľkosť a umiestnenie, text – typ štýlu, veľkosť písmen, celkový vzhľad – použité farebné kombinácie ) zmena v oblasti kolízií – umožniť existenciu kolízií s možnosťou zapnutia a vypnutia oznamovania kolízií možnosť záväzného prihlasovania sa študentov na predmety možnosť vytvárať harmonogram skúškového obdobia so všetkým, čo k tomu patrí: vkladanie skúšok, časové možnosti dozoru, ... možnosť vytvoriť rozvrh hodín na časovú periódu vačšiu ako jeden týždeň dohodnúť sa so zákazníkom na použitej platforme ( pre režim vkladania údajov) a na rýchlosti odozvy systému
Pri vytváraní rozvrhu hodín sa postupuje týmto spôsobom.
Fáza I
Pracovník katedry (pani Husárová) vytvorí návrh rozvrhu podľa daných kritérií. Forma vytvárania rozvrhu v tejto fáze je manuálna, tj. na papieri bez použitia výpočtovej techniky.
Fáza II
Vytvorený rozvrh sa odovzdá pracovníkovi, ktorý spracováva rozvrh na fakultnej úrovni (pán Galan). V tejto fáze sa vytvára celý rozvrh pre 1. a 2. ročník bakalárskeho štúdia a rozvrh pre predmety, ktoré sa vyučujú v miestnostiach, ktoré sú v správe fakulty (prednášky a pod.). Ďalej kompletizujú rozvrhy za ostatné ročníky vytvorené jednotlivými katedrami. Získané informácie sa vložia do existujúceho informačného systému a zisťujú sa konflikty v rámci celej fakulty (predovšetkým ide o konflikty v pridelení miestností). Vzniknuté konflikty a prípadné zmeny sa konzultujú telefonicky.
Fáza III
V tejto fáze (pani Bieleková) sa prideľujú pedagógovia jednotlivým prednáškam a cvičeniam pomocou informačného systému už do hotového rozvrhu, ktorý vznikol v druhej fáze.
Fáza prezerania
Vstupom tejto fázy už nie sú externé informácie, ale len informácie zo systému.
Výstupom by mali byť voliteľné zostavy rozvrhov.
Nový systém by mal odstrániť pracné vytváranie rozvrhu na papieri a umožňovať nasledovné úkony:
- aby pedagóg zadával svoje časové obmedzenia
- aby pedagóg zadával údaje o predmete (nutnosť potvrdenia správcom systému)
- zobrazenie obmedzení pedagógov pri tvorbe rozvrhu
- nájdenie voľnej miestnosti na katedre
- nájdenie kde práve učí vybraný pedagóg
- nájdenie kde sa nachádza krúžok (až na úroveň študentov)
- zistiť okno v rozvrhu celého ročníka (zvolanie ročníkového sedenia)
- zistiť kedy má vybraný pedagóg voľno (zastupovanie), poprípade ktorý pedagóg má voľno
- treba overiť, či tvorba rozvrhu hodín skutočne prechádza uvedenými fázami alebo došlo k nejakým zmenám
Tím použil techniku DFD na vyjadrenie funkčných návrhových charakteristík :
Externé entity DFD :
- pedagóg: pedagogický pracovník katedry, ktorého úlohou nie je vytváranie rozvrhu, táto externá entita je definovaná pre zadávanie obmedzení
- používateľ: študent, pedagóg, akýkoľvek iný používateľ, má právo len prezerať rozvrh
- zadávateľ: pracovník katedry, ktorého úlohou je aj vytváranie katedrového rozvrhu, je oprávnený pracovať so všetkými modulmi
Základné procesy DFD :
- prezeranie rozvrhu
- editovanie rozvrhu a tabuliek
- hromadné napĺňanie
- zadávanie obmedzení
Tím použil techniku DMD na vyjadrenie dátových návrhových charakteristík :
Tím na základe tohto modelu navrhol databázové tabuľky.
Návrh sa javí ako kvalitne prevedený, ale chýbajú podrobnejšie opisy procesov a aj dátových entít. Diagramy týchto modelov (funkčný a aj dátový) sú k dispozícií a tak je možné si vytvoriť podrobný obraz o navrhovanom systéme. Model architektúry systému je navrhnutý veľmi dobre (vhodné na prebratie) – k databázovému prostriedku pristupujú len WWW server (na prezeranie) a databázový klient (napĺňanie a editovanie databáz). Návrhnuté DFD diagramy pokračujú v duchu modelu architektúry. Celý model je vhodný na náš nový rozšírený systém s tým, že do neho treba zapracovať časti uvedené vyššie ako doplnky v špecifikácii.
Tím si vybral pre implementáciu jazyk Java a prostredie Borland Jbuilder. Toto sa však stretlo s určitými problémami pri prenose prototypu na školský server (nepodarilo sa exportovať triedy prototypu a spustiť ho). Keďže uvedený problém nebol vyriešený, musel tím pristúpiť k zmene použitého jazyka aj implementačného prostredia.
Ako alternatívny jazyk bol zvolený JavaScript a PHP jazyk. Ako databáza bola použitá databáta Microsoft Access.
Rozvrhový systém je rozdelený do viacerých modulov; modul editovania databázy a rozvrhov; modul prezerania rozvrhov; modul hromadného napĺňania databázy, modul zadávania obmedzení.
V rozvrhovom systéme existujú tri druhy prístupov:
- prezeranie databázy
- editácia databázy
- zadávanie obmedzení
Prezeranie databázy slúži na rôzne výpisy z pracovnej databázy (prehľady, výpisy na obrazovku prípadne tlačiareň), užívateľ nemení obsah databázy.
Základom sú tri skripty v jazyku PHP3. Prvé dva p1.php3 a p2.php3 realizujú výber položiek, pre ktoré sa tretím skriptom p3.php3 zobrazí rozvrh. Všetky tri sa pripájajú do databázy.
V prvom prístupe do databázy pomocou programu p1.php3 klient dostane zoznam ročníkov a špecializácií pre ktoré existujú údaje v databáze. Po výbere z ponúknutých ročníkov a špecializácií sa na strane servera spustí program p2.php3, vygeneruje všetky krúžky pre vybraný ročník a špecializáciu a zobrazí to na strane klienta. Výberom krúžku a spustením programu p3.php3 na strane servera sa vygeneruje rozvrh hodín pre zvolený ročník špecializáciu a krúžok (v textovom alebo grfickom režime – podľa výberu).
Prezeranie rozvrhu je realizované len skriptami v jazyku PHP3 a nepoužíva žiadne statické HTML stránky. Ide o modul z čisto dynamických HTML stránok.
Editácia databázy vedie k zmene v rozvrhu (pridanie/vybranie predmetu/profesora/učebne...). Tieto úkony môže vykonávať len užívateľ so správnym loginom a heslom.
Editačný prístup do systému samozrejme umožňuje aj prezeranie rozvrhov bez nutnosti nového prihlasovania sa do systému pod iným menom. V prípade, že používateľ požaduje editačný prístup v čase, keď je pridelený inému používateľovi bude o tomto stave informovaný a sprístupní sa mu prezeranie rozvrhov.
V prípade, že sa práca v systéme neukončila korektne (pri poslednom editovaní), v prihlasovacej obrazovke je možné zadať špeciálne prihlasovacie meno (logout) a heslo, ktorým sa systém uvedie do konzistentného stavu. Keďže databázový klient je riešený ako aplikácia v MS Access, bez prihlásenia sa do databázy editačný modul nie je prístupný.
Pri štarte rozvrhového systému web server vygeneruje súbor, ktorý obsahuje celú databázu preloženú do jednej premennej v jazyku Java Script. Tento súbor sa spolu s ostatnými súbormi obsahujúcimi zdrojové texty funkcií v jazyku Java Script prenesie na používateľov počítač.
Takto môže používateľ rozličnými spôsobmi údaje z databázy zobrazovať bez toho, aby prostredníctvom web servera pristupoval k databáze. Takisto pri vytváraní nových záznamov (napríklad študentov, krúžkov, predmetov, ...) sa tieto dočasne ukladajú v pamäti používateľovho počítača a až na jeho pokyn sa prenesú do databázy. HTML stránky, ktoré tvoria používateľské rozhranie a funkcionalita zabezpečujúca vyššie spomínané správanie systému je vytváraná programami v jazyku Java Script, ktorý sa interpretuje na lokálnom počítači používateľa.
Zadávanie obmedzení slúži ako oznamovacia služba, užívateľ len posiela svoje požiadavky respektíve obmedzenia. Je realizované ako samostatná WWW stránka, ktorej vyplnený obsah odošle prehliadač serveru a ten sa automaticky postará o odoslanie správy elektronickou poštou. Ide o univerzálny modul, ktorý nezávisí od WWW klienta.
Hromadné napĺňanie údajov je realizované v prostredí Microsoft Access pomocou pomocných tabuliek, ktoré uchovávajú medzivýsledky importovaných údajov, dotazov (výberových, pridávacích, aktualizačných, vymazávacích), makier, formulárov a funkcií jazyka Visual Basic.
Tieto komponenty sú uložené spolu so základnou databázou, ktorá obsahuje údaje pre katedrový informačný systém.
Na používanie tohto modulu je určený len zadávateľ rozvrhu, a preto je aj úroveň prístupu riadená. Pred prístupom do databázy sa musí používateľ autentifikovať.
Je potrebné si uvedomiť rozsah a náročnosť uvedených postupov. Voľba jazyka Java preto vôbec nepripadá do úvahy hlavne z dôvodu pamäťovej i inej hárdvérovej náročnosti.
Alternátívna voľba (JavaScript, PHP, MS Access database) je omnoho výhodnejšia – neveľká hárdvérová náročnosť, jednoduchá implementácia, ľahká dostupnosť.
JavaScript
JavaScript je skriptovací jazyk, ktorý umožňuje programátorovi zo strany servera ovládať niektoré funkčnosti klienta (prehliadača).
PHP
Web server používa na dynamické generovanie stránok jazyk PHP. Program v jazyku PHP sa vykonáva na Web serveri. Výstup z tohoto programu je zdrojový kód stránky v jazyku HTML, ktorý zobrazí internetový prehliadač. Tento spôsob je ešte doplnený dynamicky stránkami HTML, ktoré sa generujú v jazyku Java Script v prvej vrstve architektúry – to znamená na lokálnom počítači používateľa. Každý z týchto dvoch modulov spolupracuje s web serverom iným spôsobom. Pri prezeraní rozvrhu sa každá požiadavka na zobrazenie rozvrhu prenáša na web server. Jeho úlohou je získať požadované údaje z databázy, vygenerovať stránku z požadovaným rozvrhom a poslať ju na zobrazenie internetovému prehliadaču. Tým je na jednej strane zabezpečené, že používateľ prezerajúci rozvrh bude mať vždy aktuálne údaje z databázy, ale na úkor rýchlosti (prenos v sieti - treba vybudovať spojenie medzi web serverom a databázou a načítať údaje). PHP3 je skriptovací jazyk vkladaný do HTML stránok. Umožňuje vývojárom web-stránok písanie rýchlych dynamicky generovaných stránok s možnosťou prístupu do databázy. Toto predstavuje výkonný nástroj pre tvorcov a demonštruje to aj silu tohoto programovacieho jazyka.
Databáza
Je použitý databázový prostriedok MS Acces. Keďže systém je navrhovaný pre platformu Microsoft Windows 98/NT, je zrejmé, že tento typ databázy je najprístupnejší a aj cenovo najvýhodnejší.
Systém sa správa niekedy čudne v prostredí MS Internet Explorer (výpisy častí kódu, zlé vypisovanie národných znakov)
- Nemožnosť zapojiť sa do editovacieho módu (neprístupné mená a heslá)
- Pri prezeraní krúžkového rozvrhu zbytočné rozdelenie výberu ročníku a odboru do jedného modulu a výberu konkrétneho krúžku do iného modulu – dalo by sa celkom pekne vyriešiť aj v jednom moduli
- Stála neprítomnosť akejkoľvek nápovedy alebo on-line príručky
- Chýba možnosť zvoliť si typ prezerača (textový/grafický) na začiatku práce s programom
- Vhodný implementačný jazyk – kombinácia PHP a JavaScriptu
- Logické rozdelenie funkcií do rôznych modulov
- Dobrý databázový systém – vďaka všeobecnej rozšírenosti a nezložitej práci nad databázami MS Access vhodný pre potreby projektu tejto veľkosti
- Prerobiť časť implementovaného programu, aby sa vyššie uvedené problémy neobjavovali a zároveň vyriešili (hlavne doplnenie on-line manuálu a správna prevádzka pre prehliadače Netscape Navigator aj Internet Explorer)
Vzhľadom k faktu, že problematika jazyka PHP a JavaScriptu je nám pomerne neznáma (zatiaľ), nebolo možné sa vyjadriť k zdrojovému kódu a posúdiť jeho efektívnosť, správnosť či jeho znovupoužiteľnosť. No na základe znalostí jazyka C++, Perl a HTML bol možný aspoň základný náhľad na riešenie.
Na analýzu riešenia bola k dispozícii kompletná dokumentácia k tímovému projektu, ako aj samotný softvérový produkt, ktorý však funguje len v prostredí internetu alebo intranetu, teda ho nebolo možné zatiaľ vyskúšať. Toto hodnotenie sa preto bude opierať o fakty uvedené v dokumentácií.
Názov tímového projektu je: Katedrový informačný systém – spracovanie katedrového rozvrhu. Projekt teda vznikal ako súčasť rozsiahlejšieho systému.
Dokumentácia je rozdelená na dve základné časti:
- dokumentácia projektu
- dokumentácia produktu
Rozdelenie celkovej dokumentácie na tieto dve časti, ktoré sa obe členia na úvod, jadro a záver, je veľmi nezvyklé a môže nastať dojem, že ide o dve samostatné dokumentácie. Pri použitých názvoch častí dokumentácie môže teda ľahko dôjsť k nesprávnemu pochopeniu obsahu tej ktorej časti. Prehľadnejšie by bolo urobiť úvod a záver spoločný a samotné obsahy dokumentácií zaradiť ako kapitoly jedinej spoločnej dokumentácie. Samotné dokumentácie sú pritom rozdelené podľa obsahu, ktorý v nich prevažuje, dokumentácia projektu sa zaoberá tímom a jeho prácou, dokumentácia produktu sa zaoberá samotnou tvorbou softvérového systému.
V krátkom Úvode je možné dozvedieť sa, čo je cieľom tímového projektu z hľadiska výučby a takisto mená členov tímu.
Ďalšou časťou dokumentácie projektu je Ponuka, ktorá bola prezentovaná a na jej základe bol tímu pridelený tento tímový projekt. Ponuka je tu uvedená celá, vrátane úvodnej strany a priesvitky, ktorá bola použitá pri prezentácii. Ponuka je urobená na vysokej úrovni, obsahuje zoznam a skúsenosti členov aj s referenciami, chýba však predstavenia sa ako tímu. Motivácia je stručná ale výstižná. Malé výhrady môžu byť k ponúkanému riešeniu, kde pri opise možností sa zachádza do podrobností (konkrétny typ servera, použité technológie a techniky). Sú tu ale uvedené aj výhody takéhoto riešenia (tieto by sa však dali aplikovať aj na menej konkrétny príklad). Ponuka takisto obsahuje aj ostatné potrebné časti ako potrebné zdroje, poradie projektov a rozvrh hodín. Priesvitka je urobená veľmi dobre.
V dokumentácií nasleduje Plán projektu na obidva semestre, pričom v zimnom semestri je robený klasickým textom, v letnom semestri boli použité novo získané poznatky z oblasti manažmentu projektov. Obidva plány sú na vysokej úrovni a obsahujú všetky potrebné prvky.
V ďalšej časti dokumentácie projektu sú uvedené zoradené Záznamy zo stretnutí tímu. Opísané sú tu všetky záznamy zo stretnutí počas vyhradeného času. Všetky záznamy majú požadovanú formu, teda obsahujú hlavičku, splnené a nesplnené úlohy, zaznamenaný je priebeh stretnutia a úlohy na najbližší čas. Výhrady sú k niektorým skorším záznamom, na ktorých sa získavali nové informácie, ktoré boli až priveľmi podrobne uvedené v zápisoch zo stretnutí. Príkladom je zápis zo stretnutia č. 2, v ktorom sú dopodrobna uvedené požiadavky na systém – teda ide o predbežnú špecifikáciu. Tej sa pritom venuje dokumentácia produktu, kde však nie sú zapracované len poznatky získané na stretnutí, ale aj z ostatných zdrojov. Súčasťou zápisu zo stretnutia je aj predbežný architektonický návrh, ktorý je však bez popisu a bez hodnotenia. V zápise zo stretnutia č. 3 je uvedená ako príloha analýza jedného existujúceho riešenia informačného systému, ktorú by tiež bolo vhodnejšie uviesť v dokumentácií k produktu. Zápisy od stretnutia č. 4 sú už spracované veľmi dobre a prehľadne, pričom obsahujú len potrebné časti.
Nasleduje Posudok tímu č. 2 na dokument vypracovaný tímom č. 1. Posudok je prehľadný, zvažuje výhody aj nevýhody, pričom nedostatky vysvetľuje a navrhuje riešenia.
Nasleduje Vyjadrenie sa k posudku, ktorý urobil tým č. 1, samotný posudok však nie je súčasťou dokumentácie.
Poslednou časťou dokumentácie k projektu je zhodnotenie. To okrem celkového zhodnotenia uvádza aj podiel členov na práci týmu, ako aj názory členov tímu na jeho prácu.
Úvod dokumentácie oboznamuje čitateľa s obsahom tímového projektu, čo sa tíka tvorby softvérového systému. Obsahuje aj menný zoznam členov tímu.
Analýza systému je rozdelená na sedem častí. Prvou je Kontext systému (DFD). Ide o kontextový diagram a diagram prvej úrovne, spolu s popisom procesov, úložísk a externých entít. Aj keď je táto časť vypracovaná dobre, je tu uvedená na nesprávnom mieste. Ďalšou časťou analýzy je Definícia požiadaviek. Sú tu uvedené základné požiadavky na systém a ich rozdelenie na tri skupiny s ich krátkym opisom. Nasleduje Analýza súčasného stavu, kde je uvedený leták na získavanie informácií od pedagogických pracovníkov školy. Tento leták je však neprehľadný a je uvedený priamo v texte, čo ešte väčšmi znepriehľadňuje obsah. Pri letáku sú vysvetlené jeho položky aj s krátkym opisom. Ďalej je v tejto časti opísaná súčasná forma tvorby rozvrhu – obeh dokumentov. Nasleduje Špecifikácia požiadaviek. Tu sú prehľadne zoradené a opísané všetky požiadavky kladené na systém. Ďalej je uvedená Špecifikácia údajov. Obsahuje model údajov (logický) a ich presný popis. Špecifikácia správania sa systému obsahuje podrobný popis všetkých funkcií systému, pričom sú funkcie zoskupené podľa práce a je dodržiavaná následnosť funkcií. Celá špecifikácia je napísaná veľmi dobre, podrobne a zrozumiteľne. V závere sú uvedené Ďalšie požiadavky a ohraničenia a Externe získané formuláre.
Nasleduje Návrh systému. Opísaná je celková architektúra systému (klient-server), sú tu uvedené vysvetľujúce obrázky, popisy a príklady. Sú tu uvážené výhody a nevýhody takéhoto riešenia. Sčasti tu chýbajú iné možné riešenia tohoto problému a dôvod výberu konečného riešenia. Opísané je rozdelenie systému na moduly, ich previazanie a spolupráca. Sú tu uvedené DFD diagramy spolu s popismi procesov, úložísk a externých entít. Popisy sú urobené veľmi prehľadne a zrozumiteľne. Nasledujú popisy splnenia niektorých požiadaviek. Sú však uvedené pod označením Požiadavka ... ,čo spôsobuje nedorozumenia. Nasledujú ohraničenia pri implementácií systému. Ďalšou časťou je Fyzický návrh systému, obrázok a jeho podrobný popis. V závere je uvedený kód umožňujúci vytvorenie požadovanej databázy v jazyku SQL.
Dodatkom je Príručka štýlu programovania.
Implementácia popisuje spôsob implementácie častí systému ako napr.: Kontrola rozvrhu a Prezeranie rozvrhu. Implementácia je písaná obšírne, pričom je opisovaný vždy niektorý súbor, ktorý je zároveň modulom v systéme. Podstatnou časťou implementácie je Graf životného cyklu entity a Štruktúra vstupu a výstupu entity, ktoré sú uvedené pre všetky použité entity.
Ďalšou časťou systému je Používateľská príručka. Je obšírna a podrobná, priemerný užívateľ počítačov sa z nej môže naučiť používať celý systém.
Nasleduje Inštalačná príručka. Tu je popísaná inštalácia produktu.
Testovanie popisuje akú metodiku členovia použili pri testovaní, neobsahuje však príklad testovacích údajov.
Poslednou časťou je Záver, v ktorom členovia zhodnotili úspešnosť tímového projektu.
Celkovo je dokumentácia napísaná dobre až na nedostatky v jej usporiadaní. Podstatné časti ako Návrh a Implementácia sú však ne veľmi vysokej úrovni, čo sa odrazilo aj na výslednom produkte.
V tohtoročnom tímovom projekte bude možné použiť všetky informácie získané minulý rok počas práce na systéme, a to hlavne čo sa týka požiadaviek naň. Bude teda možné prevziať veľkú časť špecifikácie. Keďže sa podstata projektu nezmenila, architektúra systému bude veľmi podobná, teda bude možné použiť aj niektoré časti návrhu. Okrem architektúry bude pravdepodobne možné použiť aj niektoré štruktúry údajov, funkcie a pod. V prípade implementácie bude možné využiť a identifikovať niektoré osvedčené postupy a tak sa vyvarovať omylov.
Podstatnou zmenou budú funkcie nové, rozšírené, prípadne zmenené. Treba však prehodnotiť aj ohraničenia, brané v úvahu tímom v roku 1998/1999, a prípadne ich zjemniť alebo úplne neakceptovať. Novou kapitolou v tvorbe systému pritom bude doplnenie systému o tvorbu plánu skúškového obdobia.