Slovenská technická univerzita v
Bratislave
Fakulta informatiky a informačných technológií
Ilkovičova 3, 842 16 Bratislava 4
Informačný systém pre komunikáciu s absolventmi
Analýza problému,
špecifikácia požiadaviek
a návrh riešenia
HISTÓRIA DOKUMENTU
Tabuľka 1.: Zaznamenanie histórie tvorby dokumentácie
|
Dátum zmeny |
Verzia |
Opis |
Autor |
|
01.11.2006 |
0.1 |
Vytvorenie dokumentu, štruktúra obsahu. |
Pažin |
|
06.11.2006 |
1.0 |
Motivácia, existujúce systémy. |
Bubanský |
|
12.11.2006 |
2.0 |
Návrh riešenia. |
Vašš |
|
12.11.2006 |
2.1 |
Úprava návrhu riešenia. |
Vašš |
|
12.11.2006 |
2.2 |
Pridaná použitá notácia, motivácia, existujúce riešenia a vlastnosti
systému. |
Bubanský |
|
13.11.2006 |
3.0 |
Pridaná analýza - bezpečnosť a nástenka. |
Pažin |
|
13.11.2006 |
3.1 |
Doplnená bezpečnosť a nástenka. |
Pažin |
|
13.11.2006 |
3.2 |
Pridaný obsah kapitoly Ostatných požiadaviek. |
Samiec |
|
14.11.2006 |
3.3 |
Doplnenie textu kapitol 3, 4 a 5. |
Všetci |
|
14.11.2006 |
3.4 |
Doplnenie schém aktivity diagramov a scenárov použitia. |
Bubanský, Stanček, Samiec, Ďuriš, Pažin |
|
14.11.2006 |
3.5 |
Tvorba štruktúry stránok. |
Vašš |
|
15.11.2006 |
4.0 |
Finálna grafická a obsahová úprava. |
Pažin |
|
15.11.2006 |
4.1 |
Kontrola a úprava obsahovej stránky. |
Samiec |
Obsah
3.3.1. Kalendár
- plánovač udalostí
4.2.1. Základná
štruktúra webových stránok
4.3.2. Entity
logického modelu údajov
5. Ďalšie požiadavky
a ohraničenia
5.4. Požiadavky
na zálohovanie
Dokument predstavuje technickú dokumentáciu systému pre evidenciu a prezentáciu absolventov vysokých škôl.
Prvá časť dokumentu predstavuje analýzu problémovej oblasti systému. V nasledujúcej časti sú podrobne špecifikované požiadavky na systém. Požiadavky sú vyjadrené pomocou diagramu prípadov použitia, aktivity diagramov a pomocou prehľadných tabuliek.
Posledná časť dokumentu obsahuje hrubý návrh systému, ktorý sa skladá z návrhu a popisu obrazoviek, návrhu dátového modelu a architektúry systému.
1.1.
Slovník pojmov
Prístup k entite definujeme ako možnosť vykonávať činnosť s počítačovým prostriedkom (napr. vykonať, zmeniť, zobraziť súbor).
Riadenie prístupu je spôsob, akým je povolený alebo zakázaný prístup. Predpisuje nielen to, kto môže mať prístup ku systémovému prostriedku, ale aj typ povoleného prístupu (napr. pri súborovom systéme právo čítať zo súboru, zapisovať do súboru, zmazať súbor, atď.).
Princíp najmenšej množiny privilégií: Obvyklou bezpečnostnou požiadavkou v počítačových systémoch je, že používateľovi nesmie byť povolené viac, ako je nevyhnutné na vykonanie operácií potrebných pre vykonávanie práce v jeho funkcii. Toto pravidlo sa volá princíp najmenšej množiny privilégií.
Bezpečnostný údaj je druh údaja, ktorý je pre prípadného útočníka ťažko získateľný. V tomto systéme ide napríklad o priezvisko matky za slobodna, alebo rodné číslo.
1.2.
Skratky
ASP Active Server Pages (aktívne serverové stránky) je skriptovací jazyk na strane servera, ktorého základom sú predovšetkým programovacie jazyky VBScript alebo JavaScript.
ASP.NET súčasť platformy Microsoft .NET Framework.
.NET Framework technológia, ktorú vyvinul Microsoft a nasadil v roku 2002. Obsahuje základné jazyky platformy .NET : Visual Basic .NET, C#, C++ .NET, J#
1.3.
Použitá notácia
Tabuľka 2.: Notácia použitá pri tvorbe diagramu prípadov použitia
|
Diagram prípadov použitia |
|
|
|
Používateľ systému, nejedná sa o konkrétnu osobu, popisuje používateľa vo vzťahu k jednotlivým prípadom použitia. |
|
|
Prípad použitia: činnosť, ktorú vykonáva užívateľ v informačnom systéme. |
|
|
Zovšeobecnenie, môže ísť o zovšeobecnenie medzi prípadmi použitia alebo medzi hráčmi. |
|
|
Závislosť medzi prípadmi použitia, prípad použitia od ktorého smeruje šípka je špeciálnym prípadom prípadu použitia, do ktorého šípka smeruje. |
|
|
Symbolizuje zahrnutie prípadu použitia, ku ktorému smeruje šípka do prípadu použitia od ktorého smeruje šípka. |
Tabuľka 3.: Notácia použitá pri tvorbe aktivity diagramu
|
Aktivity diagram |
|
|
|
Počiatočný stav diagramu činnosti, z neho sa spúšťa prvá aktivita. |
|
|
Koncový stav diagramu, posledná vykonávaná aktivita v ňom skončí. |
|
|
Delí diagram aktivít na časti, ktoré určujú, kto danú aktivitu vykonáva. |
|
|
Smer časovej následnosti jednotlivých aktivít. Prípadný komentár udáva udalosť, alebo podmienku, za ktorej aktivita daným smerom pokračuje. |
|
|
Aktivita prebiehajúca v rámci prípadu použitia. Popisuje činnosť, ktorú daná časť vykonáva. |
|
|
Vetvenie postupnosti aktivít. Šípka, ktorá vstupuje do tohto bloku udáva podmienku a vystupujúce šípky naznačujú ďalší postup pri splnení alebo nesplnení podmienky. |
Tabuľka 4.: Notácia použitá pri tvorbe dátového modelu
|
Dátový model |
|
|
|
Údajová entita spolu s atribútmi a vyznačeným primárnym kľúčom. |
|
|
Väzba medzi entitami. Čísla vyjadrujú kardinalitu väzby, tzn. koľko inštancií entity 1 môže byť vytvorených ku entite 2 (a naopak). |
2.1.
Motivácia
Z fakulty každoročne odchádza množstvo absolventov. Po absolvovaní štúdia sa rozpŕchnu do celého sveta, zamestnajú sa vo firmách na najrôznejších pozíciách, poniektorí si založia vlastné firmy a mnohí nájdu svoje uplatnenie v oblasti vedy a výskumu. Každý študent je individuálna osobnosť, každý je iný. To, čo jednému pripadá ako samozrejmosť, môže pre druhého predstavovať len ťažko riešiteľný problém, pri riešení ktorého vynaloží nemalé úsilie a strávi množstvo času.
Doba štúdia taktiež predstavuje nemalú časť života človeka, počas ktorej nadobudne množstvo kontaktov, získa množstvo priateľov. Človek však nie je socha alebo strom, celý život tráviaci na jednom mieste, ale naopak cestuje, mení svoje priority a ciele a s tým aj svoje kontaktné údaje. Veľakrát sa preto stane, že kontakty nadobudnuté počas doby štúdia zaniknú a ich opätovné získanie sa rovná hľadaniu ihly v kope sena.
Je taktiež samozrejmé, že nikto nemôže v reálnom čase sledovať všetky informačné zdroje a mať prehľad o všetkom, čo sa v oblasti, ktorá ho zaujíma deje alebo udialo. Koná sa množstvo konferencií, vedeckých seminárov, neustále sa vyvíjajú nové technológie, ktoré uľahčujú ľuďom život. Nebolo by preto skvelé, keby cesta ako sa k týmto informáciám dostať spočívala v zadaní jednej webovej adresy a pár kliknutiach myšou ? A na záver, čo môže byť pre školu väčším meradlom kvality poskytovaného vzdelania, ako úspechy jej minulých študentov?
Veľa z týchto otázok a problémov bude možné vyriešiť cez informačný systém slúžiaci na komunikáciu s absolventmi fakulty. Hlavnými úlohami vytváraného informačného systému bude preto najmä umožniť:
Ø prezentovať verejnosti absolventov fakulty
Ø udržiavať neformálny odborný kontakt medzi fakultou a absolventmi
Ø udržiavať neformálny kontakt medzi absolventmi fakulty
Ø neformálnu výmenu informácií z profesionálneho, ale i osobného života absolventov
Ø informovať o konajúcich sa akciách a seminároch
Pomocou vytváraného systému ALUMNI bude každému absolventovi poskytnutý priestor, kde sa môže prezentovať a podeliť sa o svoje úspechy z profesionálneho života, ktoré dosiahol vďaka vedomostiam nadobudnutým počas doby štúdia na fakulte. Našou snahou je taktiež vytvoriť možnosť vytvárania prehľadov absolventov, napr. podľa roku ukončenia štúdia, ktorej uplatnenie možno nájsť pri vytváraní ročeniek
Je na nás, ako sa s danými úlohami vyrovnáme, ale veríme, že aj vďaka vedomostiam, ktoré sme získali počas bakalárskeho štúdia a v praxi, dokážeme projekt dotiahnuť do úspešného konca, na konci ktorého bude stáť zavedenie systému do praxe.
Pozitívna spätná väzba budúcich používateľov tohto informačného systému, medzi ktorých sa dúfame onedlho zaradíme aj my, bude pre nás najväčšou odmenou.
2.2.
Existujúce systémy
Prvým z existujúcich systémov, ktoré sa funkcionalitou podobajú na vytváraný informačný systém je portál www.spoluziaci.sk, slúžiaci na evidenciu žiakov základných, stredných ale aj vysokých škôl. Systém umožňuje zoskupovať žiakov a študentov podľa mesta, školy, roku ukončenia štúdia na danej škole a triedy, poprípade krúžku. Ďalšou užitočnou funkciou systému je možnosť vyhľadávať registrovaných členov systému podľa mena a priezviska. Pre každú triedu existuje administrátor, medzi ktorého kompetencie patrí pridávanie a odoberanie členov triedy, pridávanie obrázkov, prípadne kontrolu nad obsahom príspevkov jednotlivých členov triedy.
Každému členovi triedy je umožnené modifikovať jeho osobné údaje, zúčastňovať sa diskusie na chate, pridávať príspevky na nástenku. Každý príspevok na nástenke je identifikovaný dátumom vytvorenia a menom autora. Systém obsahuje chaty, ktorých sa môžu zúčastňovať členovia triedy, ročníka, prípadne i neregistrovaný používatelia systému. Príspevky obsahujú dátum a čas vzniku, identifikáciu autora príspevku, prípadne je naznačené, že daný príspevok je reakciou na niektorý z už existujúcich príspevkov. Systém má tiež kalendár, do ktorého sa dajú vkladať akcie. Akcie majú určený dátum, čas a popis.
Príkladom elektronickej nástenky, ktorú plánujeme v našom systéme implementovať je úvodná stránka webového sídla fakulty na adrese www.fiit.stuba.sk. Obsahuje oznamy informujúce o aktualitách týkajúcich sa života na fakulte a zoznam podujatí súvisiacich s odborným zameraním fakulty, ktoré sa v blízkej budúcnosti budú konať. Aktuálne informácie sú prehľadne zobrazené na hlavnej stránke, staršie príspevky je možné vyhľadať v archíve podľa dátumu uverejnenia alebo pomocou fulltextového vyhľadávania.
Web stránka ďalej informuje verejnosť o fakulte, poskytujte informácie o prijímacou konaní na jednotlivých stupňoch štúdia, možnostiach, ktoré fakulta študentom ponúka a pod.
Množstvo funkcií plánovaného informačného systému obsahuje portál www.wargames.sk, venujúci sa airsoftu. Návštevníkom stránky ponúka možnosť registrácie, registrovaní používatelia majú možnosť pridávať nové príspevky do fór, možnosť komunikovať pomocou chatu alebo privátnych správ, ako aj prístup k plánovači akcií.
Plánovač slúži na informovanie registrovaných členov o konajúcich sa zrazoch hráčov. Každá akcia je charakterizovaná miestom a časom konania, názvom akcie, jej popisom a informáciou, kto daný oznam o akcií do plánovača pridal. Plánovač umožňuje prihlásiť sa na akciu a stanoviť, na koľko percent je účasť daného registrovaného člena na akcii istá. Portál obsahuje tiež rôzne štatistiky, ankety, články a inzeráty.
2.3.
Vlastnosti systému
Informačný systém budú tvoriť jednotlivé
navzájom prepojené moduly, relatívne nezávislé časti kódu, vykonávajúce len
presne vymedzenú oblasť činností, ktoré umožnia jeho budúci vývoj, aktualizáciu
a rozširovanie. Moduly môžu medzi sebou komunikovať len pomocou presne
určených rozhraní, budú zabezpečovať prístup k údajom a vykonávanie
požadovaných funkcií informačného systému.
Výhody použitia modulárneho prístupu pri vývoji informačného systému rastú s rozsiahlosťou informačného systému. Modulárny prístup umožňuje nezávislý vývoj rôznych častí kódu, prípadné zmeny kódu alebo úplné prepracovanie jedného modulu neovplyvnia tie ostatné. Vďaka tomu je možné jednotlivé funkcie systému implementovať rýchlejšie, keďže na každom module môže nezávisle pracovať iný člen tímu. Chyby v kóde rozdelenom na moduly je možné rýchlejšie nájsť i odstrániť a funkčnosť ďalších modulov ovplyvňujú len minimálne.
Informačný systém bude navrhnutý pomocou trojvrstvovej architektúry:
Ø Databázová vrstva - bude umožňovať uloženie popisných údajov vo vhodnom relačnom databázovom systéme.
Ø Aplikačná vrstva - bude obsahovať procedúry potrebné pre aktualizáciu a spracovanie databázových údajov. Služby aplikačnej vrstvy budú dostupné prostredníctvom internetových protokolov koncovým používateľom informačného systému,
Ø Prezentačná vrstva - bude zabezpečovať prihlasovanie používateľov do systému a podľa pridelených prístupových práv bude umožňovať prácu v systéme.
Pri vývoji informačného systému je našou prioritou, aby vytvorený systém bol:
Ø
Bezpečný
To znamená, aby uchovával všetky neverejné informácie o absolventoch skryté, a aby bol chránený proti rôznym hrozbám. Rovnako je našim cieľom, aby zostatkové riziká boli na čo najnižšej úrovni.
Ø
Spoľahlivý
Spoľahlivosť nášho systému radíme medzi popredné miesta v dôležitosti. Chceme, aby nami vytvorený systém presne vyhovoval špecifikácii a veríme, že pri testovaní odhalíme všetky prípadné chyby, takže výstupný produkt bude bezporuchový.
Ø
Lacný
Tento cieľ priamo nadväzuje na zadanie projektu, keďže jednou z podmienok je, aby bol systém vytvorený pomocou dostupných prostriedkov, ktoré sa na fakulte nachádzajú. Takže na dokončenie systému nebude potrebné vynaložiť žiadne dodatočné finančné prostriedky.
Ø
Používateľsky príjemný
Chceme, aby nami vytvorený systém bol príjemný na pohľad, ale taktiež aby rozhranie tohto systému bolo jednoduché, pretože chceme, aby s našim systémom boli absolventi našej fakulty spokojní, a aby vyhovoval ich požiadavkám a predstavám.
Ø
Kompatibilný
Ďalším cieľom, ktorý vyplýva priamo zo zadania je, aby systém komunikoval so systémom YonBan a taktiež so systémami, ktoré boli aktívne ešte pred spustením YonBan.
Ø
Rozšíriteľný
Vieme, že aj náš systém bude mať vo svojej podobe ako ho vytvoríme, obmedzenú životnosť. Preto je našim ďalším cieľom, aby bol ľahko rozšíriteľný, napríklad aby pri prechode fakultného systému YonBan, na iný systém, bolo jednoduché doplniť náš systém tak, aby dokázal komunikovať s týmto systémom.
2.4.
Fórum
Jednou z úloh, ktoré vyplývajú priamo z názvu projektu je vytvorenie vhodného komunikačného prostriedku. Najvhodnejším prostriedkom v tomto prípade je fórum. Diskusia, ktorá prebieha formou fóra je založená na princípe uchovávania príspevkov. Príspevky písané používateľmi sú uchovávané na neobmedzený čas, a práve preto nie je potrebné súčasné pripojenie zúčastnených používateľov. Takáto forma komunikácie je pre daný systém najvhodnejšia práve kvôli spomínaným vlastnostiam.
Neprihlásený používateľ pristupuje k fóru iba ako pozorovateľ, nemôže teda pridávať témy ani odkazy. Registrovaný používateľ má právo vytvoriť novú tému a taktiež pridať príspevok k ľubovoľnej téme, ktorá sa nachádza v systéme. Administrátor má právo odstrániť ktorýkoľvek príspevok, dokonca celú tému zo systému.
Pri vytvorení témy alebo príspevku je potrebné, aby sa uchovalo meno autora. Toto by mal systém riešiť formou automatického zistenia mena podľa prihlasovacích údajov, a následného pridania mena do danej témy alebo príspevku. Táto vlastnosť je potrebná z dôvodu, aby nebolo možné vytvárať príspevky pod falošnými menami iných používateľov.
Vymazanie príspevku súvisí s jeho obsahom, kedy pri nevhodnom obsahu (vulgarizmy, neplatená reklama, a iné) má administrátor možnosť tento príspevok odstrániť.
2.5.
Profil absolventa
V profile absolventa sa nachádzajú údaje o absolventovi, ktoré je možné rozdeliť do nasledovných skupín:
Ø
Osobné údaje absolventa
Meno, priezvisko, titul, adresa, telefón, e-mailová adresa.[1]
Ø
Údaje súvisiace so štúdiom na
fakulte
Rok ukončenia štúdia, odbor.
Zoznam školských projektov absolventa (bakalársky, diplomový), charakterizované názvom témy, kľúčovými slovami, abstraktom práce, samotnou prácou a posudkom oponenta
Ø
Údaje z profesionálneho
života absolventa
Súčasné zamestnanie.
Keďže absolvent je potenciálny používateľ systému, ktorý daný systém nemusí nikdy použiť, údaje je potrebné importovať z existujúcich systémov fakulty, napr. osobné údaje je možné importovať z informačného systému študijného oddelenia, údaje súvisiace so štúdiom zo systému YonBan. Absolvent má po prihlásení údaje meniť, ako aj dopĺňať údaje, ktoré nie sú v existujúcich systémoch archivované.
2.6.
Nástenka
Elektronická nástenka je ekvivalentom klasickej nástenky, na ktorej sa môžu zobrazovať oznamy pre používateľov systému.
Slúži na zobrazenie oznamu, ktorý tam umiestnila nejaká osoba za účelom odovzdania informácie iným osobám. Osoba umiestňujúca oznam na nástenku musí mať prístup k tejto nástenke a povolenie umiestňovať oznamy.
Každý registrovaný používateľ systému môže na nástenke vytvoriť nový oznam. Je možné špecifikovať, či je daný oznam určený pre konkrétny ročník (zobrazení v popredí pri prihlásení používateľa s rovnakým rokom ukončenia) alebo je všeobecný.
V základnom zobrazení nástenka vyberie určitý počet oznamov, ktorých platnosť sa blíži k aktuálnemu dátumu, z ktorých zobrazí dátum platnosti a čiastočný popis oznamu, ktorý je možné zobraziť v plnom znení. Aby pri veľkom počte oznamov (keď bude systém uchovávať informácie o absolventoch napríklad za posledných 10 rokov) bolo možné zobraziť prehľadnú stránku, bude po prihlásení výpis nástenky filtrovaný. Na úvodnej stránke sa nachádzajú aktuálne všeobecné oznamy a tie, ktoré sa v plánovači blížia k dátumu platnosti a po prihlásení sa zobrazia vo filtrovanej verzii podľa roku ukončenia absolventa.
Elektronická nástenka má oproti fyzickej niekoľko výhod. Oznamy na ňu umiestnené tam môžu zostať ľubovoľne dlhý čas bez straty prehľadnosti (napríklad pri použití filtrácie). Aby mali oznamy zverejňované na nástenke maximálnu výpovednú hodnotu pre svojich adresátov, je potrebné aby obsahovali nasledujúce náležitosti: kto oznam vytvoril, ak je to definované koho prioritne sa oznam týka, dokedy je oznam aktuálne (prípadne kedy bol oznam vytvorený) a obsah oznamu.
2.6.1.
Kalendár
Modul Kalendár (predchádzajúcim tímom nazvaný Plánovač) bol širšie rozpracovaný v minuloročnej dokumentácii. Podľa ich definície je to modul, ktorý udržiava a zobrazuje údaje o udalostiach usporiadaných v čase. Minimálna množina údajov, ktoré sa pre jednotlivé udalosti v plánovači musia uchovávať je dátum konania a popis obsahujúci čistý neštruktúrovaný text so samotným opisom udalosti, miesta kde sa bude odohrávať a iné.
Pretože modul Nástenka obsahuje dostatok informácií na zostavenie kalendára z úloh, ktoré sa na nástenku zahrnú, pre zjednodušenie systému sme sa rozhodli modul vyčleniť plánovač ako jednu z foriem pohľadu na nástenku. Nástenka bude obsahovať oznamy o blížiacich sa akciách, ktoré je možné si zobraziť v štandardnom formáte (ako textové oznamy usporiadané od najbližšieho) alebo v pohľade ako na plánovač.
Oznam môže obsahovať pole typu logická hodnota, ktoré bude vyjadrovať jeho zaradenie do plánovača. Každý oznam obsahuje čas, dokedy je aktuálny a minimálne popis, ktorý nám podáva bližšie informácie. To sú minimálne podmienky potrebné na vytvorenie plánovača. Miesto konania, trvanie a ďalšie potrebné údaje je možné uložiť priamo do textu oznamu.
Typy zobrazenia plánovača môžeme dosiahnuť jednoduchým filtrovaním oznamov podľa času aktuálnosti oznamu na:
Ø ročný plán akcií,
Ø mesačný plán akcií,
Ø týždenný plán akcií,
Ø denný plán akcií.
Rovnako na základe takéhoto filtrovania môžeme dosiahnuť špecifické zoskupenie, napríklad:
Ø akademický rok - sú zobrazené dva semestre a
Ø semester.
Pri takomto prístupe si plánovač nebude vyžadovať vznik ďalších entít a bude poskytovať dostatočnú funkčnosť a spoľahlivosť pre používateľa. Na základe týchto možností sme sa rozhodli modul Plánovač nezaradzovať do systému ako samostatnú entitu.
2.7.
Bezpečnosť v systéme
Určenie kto môže pristupovať k danej entite sa v poslednom období stalo veľmi dôležité pre uchovanie súkromia a dôvernosti informácií. Preto vznikli rôzne systémy riadenia prístupu. Používateľ systému môže získať prístup k dátam alebo na vykonanie operácie. Bezpečnosť sa môže riadiť lokálne na počítači, ktorý k dátam pristupuje, ale pre veľké náklady na administráciu už pri niekoľkých počítačoch prepojených do siete sa dnešné systémy vytvárajú pri zachovaní centralizovaného riadenia prístupu.
Pri vývoji technológií riadenia prístupu sa časom vyčlenili dva hlavné typy: voliteľné riadenie prístupu (DAC - Discretionary Access Control) a povinné riadenie prístupu (MAC - Mandatory Access Control).
Discretionary Access Control dáva možnosť jednotlivým používateľom prideľovať a odoberať prístupové práva. V tejto schéme môžu byť používatelia taktiež vlastníkmi objektov. Systémy založené na DAC dovoľujú používateľom povoliť alebo zakázať prístup k ľubovoľným objektom, ktoré vlastnia. Problém môže nastať, ak používateľ nie je skutočným majiteľom informácie, ktorej vlastníkom je v DAC systéme (príkladom môže byť lekár, ktorý má právo čítať lekárske záznamy pacienta, ale nie je ich skutočným majiteľom a teda nemá právo ich ďalej poskytnúť tretej strane - toto právo má len pacient). Vlastník objektu môže prideľovať práva ostatným subjektom. Je flexibilný, často sa využíva pri riadení prístupu pri webových službách. Jeho nedostatkom je vysoký počet pravidiel a ponechanie zodpovednosti za ochranu údajov na ich tvorcovi. Často skutočným majiteľom informácií (entít nachádzajúcich sa v systéme), ako aj programov, ktoré tieto informácie spracúvajú, je samotná organizácia. Preto je v niekedy výhodnejšie použiť iný typ riadenia prístupu.
V prípade Mandatory Access Control sú práva prístupu riadené organizáciou. MAC je spôsob riadenia prístupu k objektom založený na stupni dôvernosti informácie v nich obsiahnutej (stupeň dôvernosti určuje organizácia a nie vlastník informácie) a autorizácii používateľa pristupovať k informáciám označeným určitým stupňom dôvernosti. To znamená, že organizácia určí kto môže pristupovať ku informáciám určitého stupňa dôvernosti. Riadenie prístupu je povinné v zmysle, že používateľ nemá právo meniť stupeň dôvernosti informácie a tým ju poskytnúť používateľom s menšími právami.
Vo všeobecnosti nie je tento model flexibilný, ale je mimoriadne robustný.
Každý z týchto systémov má však určité nedostatky a nie je optimálny pre zložitejšie štruktúry spracúvajúce dôverné informácie. Vhodnejším typom riadenia prístupu sa javí riadenie prístupu založené na rolách (RBAC), čo je vlastne rozšírený typ MAC.
Role Based Access Control je jedným z možných spôsobov riadenia prístupu v operačných systémoch, databázových systémoch, internetových aplikáciách a podobných systémoch.
Pri RBAC je riadenie prístupu založené na rolách, ktoré presne mapujú funkcie jednotlivých používateľov v organizácii. Používatelia majú priradené roly podľa svojej funkcie, napr. administrátor, absolvent, profesor, alebo pracovník personálneho oddelenia.
Proces definovania vychádza z priamej analýzy fungovania systému, na ktorý sa aplikuje. Správna definícia rolí je kľúčová k efektívnej prevádzke RBAC systému, keďže sa predpokladá, že roly sa nebudú často meniť.
Prístupové práva sú priraďované jednotlivým rolám a používanie prostriedkov (entít) je vyhradené len pre používateľov oprávnených zastávať priradenú rolu.
RBAC je mimoriadne flexibilný, je možné nasimulovať ním DAC aj MAC.
RBAC musí umožňovať používateľovi prihlásiť sa do systému a postupne si aktivovať roly (to znamená, že nemusia byť všetky aktívne v momente vstupu do systému). Podľa tohto systému môže používateľ počas využívania systému meniť rolu, ktorú v systéme zastáva.[2]
Základný
prehľad rozdielov medzi RBAC a štandardnými systémami riadenia prístupu:
Výhody RBAC v porovnaní so štandardnými systémami riadenia prístupu sú:
Ø Rýchla a flexibilná administrácia
Ø Prehľadnosť a
Ø Nové možnosti ohraničení a riadenia práv
2.7.1.
Prihlasovanie
Prihlasovanie do systému je potrebné spracovať tak, aby sa absolvent mohol do systému prihlásiť aj po niekoľkých rokoch, keď si už napríklad nepamätá svoje heslo. Najjednoduchšie je to pomocou využitia bezpečnostného údaja. Teda využitie osobných údajov (napríklad rodného čísla), alebo údajov, ktoré sú pre ostatných používateľov ťažko identifikovateľné, ale obsahuje ich informačný systém fakulty (napríklad priezvisko matky za slobodna) umožní jednoducho a pomerne spoľahlivo overiť identitu používateľa. Zároveň chceme zachovať princíp najmenšej množiny privilégií.
Dôležitou časťou prihlasovania je stanovenie vhodného prihlasovacieho mena. Keďže používatelia by ľahko zabudli prihlasovacie mená, importované zo súčasného systému (založené na iniciálkach a osobnom čísle) je možné použiť na prihlásenie dve možnosti:
Ø prístupové meno na server student.fiit.stuba.sk , alebo
Ø vlastné, zostavené prístupové meno.
Ich vzájomné výhody a nevýhody sú popísané v ďalšom texte:
Prístupové meno na server student.fiit.stuba.sk (napríklad novak01)
Ø väčšia možnosť konfliktu (Peter a Pavol Novák v rovnakom ročníku),
Ø systém postupného pridávania znakov nie je najvýhodnejší (novak01 a novakp01),
Ø vyššia používateľská prístupnosť a jednoduchosť (jednoduché, krátke meno),
Ø nižšia bezpečnosť - je možné vytvoriť zoznam mien na brutal force attacks - útok hrubou silou priamo stiahnutím adresárovej štruktúry, ktorú poskytuje server.
Zostavené prístupové meno (napríklad peter.novak.06)
Ø štruktúra meno.priezvisko.rok_absolvovania_školy je jednoducho zapamätateľná,
Ø menšia možnosť konfliktu mien,
Ø možnosť zadania nápovede tvorby mena priamo do prihlasovacieho formulára,
Ø alternatívna možnosť peter.novak.0601 v štruktúre meno.priezvisko.rok_absolvovania_školy_deň_narodenia umožňuje rozlíšiť približne 30 absolventov s rovnakým menom a priezviskom v jednom ročníku a zároveň je bezpečnejšia - zoznam na brutal force attacks na systém by bol 30 krát dlhší ako v prípade zoznamu bez identifikátora dňa narodenia. Oproti prihlasovaciemu menu ako prístupovému menu na server student.fiit.stuba.sk je táto možnosť výrazne bezpečnejšia - zobrazenie voľne prístupného zoznamu mien a priezvisk používateľov neumožňuje žiaden fakultný systém.
Táto kapitola sa snaží vyšpecifikovať požiadavky na systém, ku ktorým sme dospeli na základe analýzy možností uvedených v predchádzajúcej kapitoly.
3.1.
Profil absolventa
Predstavuje scenár modifikovania profilu. Modifikácia profilu je v systéme uprednostnená nakoľko úvodný profil bude vytvorený systémom a v ďalších fázach je možné profil len modifikovať. Nie je možné profil vytvárať.
Obr. 3.: Aktivity diagram - modifikácia profilu absolventa
Tabuľka 5.: Scenár použitia - Modifikácia profilu absolventa
|
Názov: |
Modifikácia profilu absolventa |
|||
|
Opis: |
Používateľ chce zmeniť údaje v profile |
|||
|
Priorita: |
Stredná |
Frekvencia: |
Nízka |
|
|
Vstupná pod.: |
Používateľ je registrovaný a prihlásený |
|||
|
Výstupná pod.: |
Profil absolventa je zmenený |
|||
|
Používatelia: |
Absolvent |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Používateľ vytvorí požiadavku na zmenu profilu. |
||
|
2. |
Systém zobrazí profil absolventa, absolvent následne zmení požadované údaje. |
|||
|
3. |
Po validácií, či sú nové zadané dáta platné, je profil uložený do databázy. |
|||
Obr. 4.: Aktivity diagram - import údajov z externého systému
Tabuľka 6.: Scenár použitia - import údajov o absolventoch do systému
|
Názov: |
Import údajov o absolventoch do systému |
|||
|
Opis: |
Administrátor chce importovať údaje o absolventoch do systému |
|||
|
Priorita: |
Vysoká |
Frekvencia: |
Nízka |
|
|
Vstupná pod.: |
Administrátor je prihlásený. |
|||
|
Výstupná pod.: |
Údaje o absolventoch boli korektne importované do systému. |
|||
|
Používatelia: |
Administrátor |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Administrátor sa prihlási do systému umožňujúceho import údajov o absolventoch. |
||
|
2. |
Spomedzi poskytnutých údajov zvolí tie, ktoré chce importovať. |
|||
|
3. |
Systém importuje údaje do systému. |
|||
|
4. |
Systém zapíše do logu údaje o importe údajov. |
|||
3.2.
Fórum
Tabuľka 7.: Scenár použitia - pridanie príspevku do fóra
|
Názov: |
Pridaj príspevok do fóra |
|||
|
Opis: |
Používateľ chce pridať príspevok do fóra. |
|||
|
Priorita: |
Stredná |
Frekvencia: |
Vysoká |
|
|
Vstupná pod.: |
Používateľ je registrovaný |
|||
|
Výstupná pod.: |
Príspevok bude správne pridaný do databázy |
|||
|
Používatelia: |
Používateľ |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Používateľ vyplní všetky potrebné údaje potrebné na vytvorenie nového príspevku. |
||
|
2. |
Systém vytvorí príspevok a pridá meno autora podľa prihlasovacieho mena. |
|||
|
3. |
Zobrazí sa aktuálne fórum s pridaným príspevkom. |
|||
Obr. 5.: Aktivity diagram - pridanie príspevku do fóra
Tabuľka 8.: Scenár použitia - odstránenie príspevku z fóra
|
Názov: |
Odstráň príspevok z fóra |
|||
|
Opis: |
Administrátor chce odstrániť príspevok z fóra, a zároveň z databázy. |
|||
|
Priorita: |
Vysoká |
Frekvencia: |
Nízka |
|
|
Vstupná pod.: |
V systéme sa nachádza príspevok, ktorý je potrebné odstrániť |
|||
|
Výstupná pod.: |
Daný príspevok bude odstránený z databázy príspevkov |
|||
|
Používatelia: |
Administrátor |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Administrátor vyberie príspevok na odstránenie. |
||
|
2. |
Systém zobrazí možnosť odstránenia príspevku. |
|||
|
3. |
Administrátor vyberie možnosť odstránenia príspevku. |
|||
|
4. |
Systém príspevok odstráni z databázy. |
|||
Obr. 6.: Aktivity diagram - odstránenie príspevku z fóra
3.3.
Nástenka
Entita Nástenka nám poskytuje základné možnosti na prácu s oznamom. Popísané sú v nasledujúcom texte:
Tabuľka 9.: Scenár použitia - zobrazenie nástenky
|
Názov: |
Zobraz nástenku |
|||
|
Opis: |
Systém zobrazí obrazovku, na ktorej sa nachádzajú oznamy patriace do kategórie nástenka. |
|||
|
Priorita: |
Vysoká |
Frekvencia: |
Vysoká |
|
|
Vstupná pod.: |
- |
|||
|
Výstupná pod.: |
Zobrazí všetky informácie, ktoré sú práve v databáze pre nástenku |
|||
|
Používatelia: |
Ktokoľvek |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Používateľ vyberie možnosť zobrazenia nástenky. |
||
|
2. |
Systém vyhľadá v databáze všetky oznamy patriace do nástenky. |
|||
|
3. |
Systém zobrazí nástenku. |
|||
Obr. 7.: Aktivity diagram - zobrazenie nástenky
Systém zabezpečuje v závislosti od prihláseného používateľa (cez bezpečnostný modul[3]) filtrovanie oznamov. Ak ide len o neprihlásenú osobu, filtrovanie vráti všeobecné výsledky, o blížiacich sa akciách a výber z oznamov filtrovaný len podľa dátumu. V prípade prihlásenia vytvorí pre prihláseného používateľa nástenku, ktorá sa prioritne týka ročníka, v ktorom sa stal absolventom.
Obr. 8.: Aktivity diagram - pridaj oznam na nástenku
Tabuľka 10.: Scenár použitia - pridanie oznamu na nástenku
|
Názov: |
Pridaj oznam |
|||
|
Opis: |
Systém zobrazí obrazovku, na ktorej je možnosť pridania oznamu. |
|||
|
Priorita: |
Vysoká |
Frekvencia: |
Stredná |
|
|
Vstupná pod.: |
Používateľ je prihlásený. |
|||
|
Výstupná pod.: |
Zobrazí nástenku aj s pridaným oznamom, alebo potvrdí pridanie oznamu na nástenku. |
|||
|
Používatelia: |
Prihlásený používateľ. |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Používateľ spustí zobrazenie pridania oznamu a vyplní povinné polia. |
||
|
2. |
Systém skontroluje obsah povinných polí a vytvorí nový oznam, alebo oznámi používateľovi, ktoré údaje má doplniť. |
|||
|
3. |
Systém zobrazí nástenku, alebo správu o pridaní oznamu. |
|||
Obr. 9.: Aktivity diagram - vymaž oznam z nástenky
Tabuľka 11.: Scenár použitia - vymazanie oznamu z nástenky
|
Názov: |
Vymaž oznam |
|||
|
Opis: |
Systém zobrazí obrazovku, na ktorej je možnosť odstránenia oznamu. |
|||
|
Priorita: |
Stredná |
Frekvencia: |
Nízka |
|
|
Vstupná pod.: |
Používateľ / administrátor systému je prihlásený. |
|||
|
Výstupná pod.: |
Zobrazí nástenku s výpisom zoznamov a k vybraným oznamom pridá možnosť ich odstránenia. |
|||
|
Používatelia: |
Prihlásený používateľ / administrátor. |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Používateľ / administrátor vyberie možnosť odstrániť oznam pri konkrétnom ozname na nástenke. |
||
|
2. |
Systém vytvorí o danej akcii záznam a oznam z nástenky (databázy) odstráni. |
|||
|
3. |
Systém zobrazí nástenku, alebo správu o zmazaní oznamu. |
|||
3.3.1.
Kalendár
- plánovač udalostí
Pretože je kalendár - plánovač iba špeciálnym pohľadom na nástenku a nevyžaduje takmer žiadne zmeny v špecifikácii požiadaviek systému, rozhodli sme sa tento modul zatiaľ neimplementovať do systému. Jeho neskoršia implementácia bude vďaka modularite jednoduchá a nebude vyžadovať v systéme takmer žiadne zmeny (okrem zabezpečenia prepojenia nového modulu so systémom). Kalendár má rovnaké požiadavky ako špecifikácia entity nástenka.
3.4.
Ostatné požiadavky
Pre potreby fungovania systému ako kompaktného celku je potrebné zabezpečiť okrem štandardnej funkcionality aj nie explicitne vymenované požiadavky.
Ø export - systém zabezpečuje export vybraných údajov v elektronicky spracovateľnej forme pre potreby fakulty
Ø import - systém zabezpečuje import vybraných údajov zo systému YonBan, toto je potrebné pre fungovanie systému.
3.4.1.
Bezpečnosť
systému
Bezpečnostný model systému zabezpečí zachovanie týchto znakov.
Ø dôvernosť - k uchovávaným údajom majú prístup iba poverení používatelia. Údaje sú rozdelené na privátne a verejné. Prístup k privátnym údajom je riadený pomocou používateľských práv
Ø hodnovernosť - systém môže slúžiť aj ako overenie o absolvovaní na danej fakulte; pričom za údaje garantuje fakulta;
Ø integritu - údaje v systéme môžu meniť iba ich tvorcovia, nimi poverení používatelia a administrátor. Použité sú „built-in“ prostriedky pre zachovanie referenčnej integrity (unique, constraint, cascade);
Ø sledovateľnosť - pohyb a činnosť používateľa v rámci systému sa dá spätne sledovať.
Z pohľadu používateľov systém zabezpečí:
Ø autentifikáciu - autentifikácia používateľa prebieha pri prihlásení, systém overuje používateľa v špeciálnych prípadoch vo viacerých krokoch;
Ø autorizáciu - teda sprístupnenie určitých funkcií na základe prístupových práv a
Ø audit - systém zaznamenáva významné udalosti, ktoré používateľ vykonáva.
Pri prezentovaní, prípadne exporte údajov v systéme využijeme DAC takto: údaje, ktoré systém využíva sú verejné, neverejné alebo chránené (verejný môže byť oznam o pridaní nového ročníka absolventov, neverejný napríklad oznam o blížiacom sa stretnutí konkrétneho ročníka a chránený je napríklad profil absolventa). Verejné údaje sa zobrazujú všetkým používateľom systému. Neverejné údaje sa zobrazujú iba registrovaným používateľom. Chránené údaje sa na stránke zobrazujú iba ich tvorcovi.
Pri vkladaní nových údajov, úprave údajov, alebo ich importovaní využijeme RBAC. Každá zmena údajov v systéme je dôsledkom operácie v niektorom z jeho modulov a je o nej zostavený bezpečnostný záznam. Každý modul prezentuje úplný zoznam operácií, ktoré sa nad ním môžu vykonať. Zlúčením operácií do skupín v systéme vznikajú roly, pričom dve role môžu obsahovať aj tú istú operáciu. Pri prihlásení má každý používateľ systému priradenú jednu alebo viac rolí, ktoré určujú, aké operácie môže vykonávať.
Obr. 10.: Aktivity diagram - bezpečnostný modul a jeho nadväznosť na iné moduly
3.4.2.
Prihlasovanie
Možnosť prihlásenia bude zobrazená na každej stránke pre neprihlásených používateľov. Prihlasovanie bude prebiehať dvoma spôsobmi, ako je to zobrazené na obrázku na nasledujúcej strane. Scenár použitia je zostavený pre priame prihlásenie.
Tabuľka 12.: Scenár použitia - priame prihlásenie do systému
|
Názov: |
Priame prihlásenie do systému |
|||
|
Opis: |
Systém zobrazí možnosť prihlásenia pre neprihláseného používateľa. |
|||
|
Priorita: |
Vysoká |
Frekvencia: |
Vysoká |
|
|
Vstupná pod.: |
Používateľ / administrátor systému je neprihlásený. |
|||
|
Výstupná pod.: |
Používateľ / administrátor systému je prihlásený. |
|||
|
Používatelia: |
Ktokoľvek. |
|||
|
Postupnosť: |
Krok |
Činnosť |
||
|
Základná: |
1. |
Používateľ / administrátor zadá prihlasovacie meno a heslo. |
||
|
2. |
Systém vytvorí o danej akcii záznam overí prístupové meno a heslo. |
|||
|
3a. |
Systém prihlási používateľa a odstráni prihlasovacie údaje zo záhlavia stránky. |
|||
|
3b. |
Systém používateľa neprihlási. |
|||
Obr. 11.: Aktivity diagram - prihlásenie do systému
Proces prihlasovania do systému môže prebiehať dvoma spôsobmi:
Ø priame prihlásenie - zahŕňa priame zadanie prihlasovacieho mena a hesla, jeho kontrolu v systéme a prihlásenie, resp. neprihlásenie používateľa.
Ø záložné prihlásenie - je rozšíreným druhom prihlásenia, kedy sa používateľovi vytvorí nové heslo na základe overenia pomocou bezpečnostného údaja, pretože ide o bezpečnostný údaj, ktorý by sa mal použiť iba v prípade straty hesla, je systém navrhnutý tak, aby akceptoval iba také heslo, ktoré nebude totožné s bezpečnostným údajom.
Poznámka: Niektoré z činností, ktoré prebiehajú v procese prihlasovania sa uskutočňujú priamo v bezpečnostnom module (napr. prihlásenie). Bezpečnostný modul však netvorí integrálnu súčasť prihlasovania (takto navrhnuté prihlasovanie je funkčné aj bez bezpečnostného modulu), avšak tento poskytuje zjednodušenie a vyššiu bezpečnosť ostatným modulom (a tým aj celému systému), lebo riadi status prihlásenia a povoľovania akcií pre každého prihláseného používateľa.
Obr. 12.: Aktivity diagram - proces odhlásenia zo systému
4.1.
Architektúra systému
Navrhovaný systém bude serverová aplikácia odpovedajúca na požiadavky používateľa. Jej výstupom bude interaktívny systém umožňujúci komunikáciu medzi používateľmi a plánovaním ich spoločných stretnutí. Členenie systému z hľadiska modulov je zobrazené na nasledujúcom obrázku.
Obr. 13.: Členenie systému z hľadiska modulov
Používateľ prichádza priamo do styku len s prezentačným modulom, ktorý prijíma požiadavky a následne k ním zobrazuje príslušnú odpoveď. Tento modul predstavuje samotný „layout“ systému a jeho správanie navonok.
Prihlásenie a odhlásenie používateľa zabezpečuje autentifikačný modul. Prijaté dáta sú overené v databáze a následne dochádza k odobreniu alebo zamietnutiu autentifikácie. Jej úspešné prevedenie má za následok nastavenie príslušných prístupových práv v module pre kontrolu oprávnení a používateľovi sa zobrazia prislúchajúce možnosti[4].
Modul na komunikáciu s databázou má za úlohu poskytovať údaje pre ostatné moduly v takom formáte aký im je prirodzený. Pri priamej požiadavke od prezentačného modulu sú výstupné dáta ešte verifikované v Module pre kontrolu oprávnení, aby bol výstup upravený pre momentálne prihláseného používateľa.
Modul pre filtrovanie slúži na výber z dát podľa požiadaviek používateľa. Príkladom môže byť jeho využitie pri vyhľadávaní absolventov podľa daných požiadaviek, prípadne pri filtrovaní vybraných správ vo fóre alebo na nástenke.
Externé a rozširujúce moduly budú komunikovať zo systémom podobne ako používateľ - zadajú do systému požiadavku, ktorá sa v systéme vyhodnotí a poskytne týmto modulom určitý výstup. Z externého modulu bude umožnený len vstup údajov (YonBan).
4.2.
Návrh obrazoviek
Návrh obrazoviek rozlišuje medzi prihláseným a neprihláseným používateľom:
Obr. 14.: Základná obrazovka neprihláseného používateľa
Obr. 15.: Obrazovka slúžiaca na zmenu nastavení profilu absolventa
4.2.1.
Základná
štruktúra webových stránok
Obr. 16.: Návrh štruktúry stránok pre neprihláseného používateľa systému
Obr. 17.: Návrh štruktúry stránok pre prihláseného používateľa systému
4.3.
Model údajov
Nasledujúca kapitola obsahuje logický ako aj fyzický dátový model požadovaného systému spolu s ich stručným popisom.
4.3.1.
Logický
model
Obrázok na nasledujúcej strane je logický model navrhovaného systému. Entity možno rozdeliť do troch oblastí: entity pre evidenciu absolventov (alm), pre bezpečnosť (sec) a pre prácu s fórom a nástenkou (frm).
4.3.2.
Entity
logického modelu údajov
V systéme sa možno rozoznať nasledujúce entity:
Ø Alm_absolvent - táto entita uchováva základné verejné informácie o absolventoch a reprezentuje absolventa ako bude uchovávaný v systéme. Tieto informácie sú dopĺňané pomocou entít alm_projekty a alm_profil, ktoré budú bližšie popísané ďalej. Okrem toho sú informácie o absolventoch dopĺňané aj entitou alm_titul, ktorá zároveň upresňuje aj entitu alm_fakultnik.
Ø Alm_projekty - obsahuje informácie o projekte, prípadne projektoch ktoré absolvent riešil ako svoje záverečné resp. diplomové práce (prípadne ďalšie projekty).
Ø Alm_profil - obsahuje súkromné informácie o absolventovi ako napríklad kontakt alebo doterajšie zamestnania ako aj súčasné zamestnanie spolu s pozíciou.
Ø Význam entít alm_administrator a alm_fakultnik je zrejmý, reprezentujú príslušných hráčov nachádzajúcich sa v systéme.
Ø Frm_pouzivatel - zovšeobecňuje entity alm_administrator, alm_fakultnik, alm_absolvent v systéme. Táto entita obsahuje ďalšiu entitu skupina, ktorá slúži na zabezpečenie bezpečnosti v systéme. To sa deje v spolupráci s entitou sec_akcia, ktorá obsahuje všetky vykonateľné operácie v systéme. Entita skupina určuje príslušnosť používateľa k skupine a na základe nej určuje aj všetky akcie ktoré používateľ môže v systéme vykonať. Táto entita tiež umožňuje používateľom prácu s diskusným fórom a nástenkou oznamov.
Ø Entita frm_prispevok popisuje základný prvok fóra. Ten prislúcha k určitej téme.
Ø Frm_oznam - reprezentuje oznam v systéme, ktorý bude umiestnený na nástenke. Môže ísť o podujatie, akciu alebo len jednoduchú správu.
Obr. 19.: Diagram modelu údajov - 1. časť
Obr. 20.: Diagram modelu údajov - 2. časť
5.1.
Hardvérové požiadavky
Na prevádzkovanie systému ALUMNI nie sú z pohľadu hardvéru kladené špeciálne požiadavky. Podmienkou je možnosť nainštalovania Internet Information Server-u, z čoho vyplýva podmienka, že na stroj na ktorom bude je systém prevádzkovaný sa musí dať nainštalovať Microsoft Windows Server 2000 v krajnom prípade Microsoft Windows XP.
ALUMNI
- Systém je možné prevádzkovať na jednom fyzickom stroji, alebo na viacerých strojoch.
- Poskytuje distribuovanú aplikačnú vrstvu.
- Poskytuje distribuovanú databázovú vrstvu.
Minimálne požiadavky na hardvér sa odvíjajú od požiadaviek pre beh virtuálnej mašiny platformy .NET a samotnej inštalácie server operačného systému.
Pre inštaláciu OS 512MB RAM a pre beh .NET Machine, aspoň 128MB operačnej pamäte pre beh samotnej aplikácie. Odporúčané min. 1024MB RAM. Je potrebné mať aspoň 10GB voľného miesta na pevnom disku pretože databáza má tendenciu rozrasť sa.
Rovnaké obmedzenia ako na operačný systém sa vzťahujú aj na architektúru počítača samotného. Je možné použiť počítače typu: x86, x86_64.
5.2.
Požiadavky na softvér
Pre potreby fungovania systému je okrem operačného systému a inštalácie samotnej aplikácie nutné mať inštalované nasledovné súčasti:
- Internet Information Server - web server,
- PostgreSql - databázový server,
- Psglodbc - PostgreSql ODBC driver,
- Internetový prehliadač - Microsoft Internet Explorer 6.0+, Mozila Firefox, Opera 9.0
Tabuľka 13.: Vzťah medzi komponentmi systému
|
Internet Information
Server |
Prehliadač |
|
.NET Virtual Machine |
Databázový server |
|
Operačný systém |
|
|
Server (fyzická časť) |
|
Vzťah medzi komponentmi znázorňuje predchádzajúca tabuľka. Internet Information Server zabezpečuje prostredie pre beh aplikácie. Aplikácia využíva návrhový vzor Model-View-Controller. Objektový model databázy je vytvorený za pomoci generovaných dataset nástroja Microsoft Visual Studio 2005, pričom ako úložisko dát sa používa SQL databáza, v našom prípade PostgreSql.
5.3.
Prevádzkové procedúry
Prevádzkové procedúry
majú za úlohu udržať systém v prevádzky schopnom stave.
Procedúry zahŕňajú:
1. Pravidelná aktualizácia hosťujúceho operačného systému (Windows Update).
2. Aktualizácia softvérových komponentov - najmä IIS, driver ODBC pre PostgreSql (Windows Update).
3. Pravidelná kontrola logov aplikácie.
4. Manuálny/automatický Vacuumining pre databázový server PostgreSql.
5.4.
Požiadavky na zálohovanie
Vzhľadom na povahu dát a frekvenciu zmien dát v systéme, je odporúčané vykonávať pravidelnú týždňovú inkrementálnu zálohu databázy systému a mesačnú kompletnú zálohu.
Prílohy
[1]
Bieliková Mária: Ako úspešne vyriešiť
projekt. Bratislava, Vydavateľstvo STU, 2000.
ISBN 80-227-1329-5
Obr. 3.: Aktivity diagram - modifikácia profilu absolventa
Obr. 4.: Aktivity diagram - import údajov z externého
systému
Obr. 5.: Aktivity diagram - pridanie príspevku do fóra
Obr. 6.: Aktivity diagram - odstránenie príspevku z fóra
Obr. 7.: Aktivity diagram - zobrazenie nástenky
Obr. 8.: Aktivity diagram - pridaj oznam na nástenku
Obr. 9.: Aktivity diagram - vymaž oznam z nástenky
Obr. 10.: Aktivity diagram - bezpečnostný modul a jeho
nadväznosť na iné moduly
Obr. 11.: Aktivity diagram - prihlásenie do systému
Obr. 12.: Aktivity diagram - proces odhlásenia zo systému
Obr. 13.: Členenie systému z hľadiska modulov
Obr. 14.: Základná obrazovka neprihláseného používateľa
Obr. 15.: Obrazovka slúžiaca na zmenu nastavení profilu
absolventa
Obr. 16.: Návrh štruktúry stránok pre neprihláseného používateľa
systému
Obr. 17.: Návrh štruktúry stránok pre prihláseného používateľa
systému
Obr. 19.: Diagram modelu údajov - 1. časť
Obr. 20.: Diagram modelu údajov - 2. časť
Tabuľka
1.: Zaznamenanie
histórie tvorby dokumentácie
Tabuľka 2.: Notácia použitá pri tvorbe diagramu prípadov použitia
Tabuľka 3.: Notácia použitá pri tvorbe aktivity diagramu
Tabuľka 4.: Notácia použitá pri tvorbe dátového modelu
Tabuľka 5.: Scenár použitia - Modifikácia profilu absolventa
Tabuľka 6.: Scenár použitia - import údajov o absolventoch do
systému
Tabuľka 7.: Scenár použitia - pridanie príspevku do fóra
Tabuľka 8.: Scenár použitia - odstránenie príspevku z fóra
Tabuľka 9.: Scenár použitia - zobrazenie nástenky
Tabuľka 10.: Scenár použitia - pridanie oznamu na nástenku
Tabuľka 11.: Scenár použitia - vymazanie oznamu z nástenky
Tabuľka 12.: Scenár použitia - priame prihlásenie do systému
Tabuľka 13.: Vzťah medzi komponentmi systému