Obrázek 19: Prototyp přehledu obsahu kurzu
6.6 Výběr kurzu
6.6.1 Popis
Tento případ užití slouží studentům jako rozcestník v rámci kurzů. Kurzy lze řadit podle jednotlivých kritérií a filtrů. Každý kurz obsahuje informaci, zda je student na tento kurz přihlášen.
6.6.2 Základní posloupnost událostí (Přehled kurzů)
1. Uživatel vybere „Přehled kurzů“ z hlavního menu systému.
2. Systém zobrazí filtr, ve kterém je možno vybrat:
• Zobrazit kurzy k předmětům, které má uživatel zapsané.
• Filtrování podle fakult, studijních oborů.
• Časové filtrování.
• Filtrovat podle zadáného textu.
3. Po potvrzení filtru systém vypíše vyhovující kurzy s následujícími informacemi:
• Název kurzu.
• Počet volných míst v kurzu pro běžné studenty a pro studenty pozorovatele.
• Indikaci zapsání do kurzu.
6.6.3 Alternativní posloupnosti událostí
6.6.3.1 Detail kurzu
1. Uživatel přejde z přehledu kurzů na detail pomocí ovládacího prvku.
2. Systém zobrazí detailní informace o kurzu (dostupné informace).
3. Systém zobrazí ovládací prvky pro přihlášení podle dostupnosti kurzu pro daného uživatele (přihlásit jako účastník, přihlásit jako pozorovatel).
4. Uživate vybere přihlásit/odhlásit daný kurz jako účastník nebo jako student pozorovatel.
5. Systém informuje uživatele o úspěšném přihlášení a přejde na přehled obsahu kurzu v případě, že se uživatel na kurz přihlásil.
6. Systém informuje uživatele o úspěšném odhlášení z kurzu a přejde na přehled kurzů v případě, že se uživatel z kurzu odhlásil.
6.6.4 Doplňující informace
Speciální požadavky Komunikace se studijní agendou.
Předpoklady Uživatel je přihlášen jako student.
Konečné podmínky Přechod na úvodní stránku.
Přidaná hodnota Řízená účast studentů na kurzech.
Přehled dostupných kurzů.
6.6.5 Diagram případu užití
6.7 Testování
6.7.1 Popis
Teto případ užití slouží k ověření znalostí studentů. Systém rozlišuje dva druhy testů. Povinný test, který student musí vyplnit na základě požadavků pedagoga, a test nepovinný, tzv. samotest sloužící převážně k výuce studenta.
6.7.2 Základní posloupnost událostí (povinný test) 1. Uživatel zvolí „Vyplnit test“ z přehledu obsahu kurzu.
2. Systém vygeneruje instanci testu z testu.
3. Uživatel vyplní instanci testu a potvrdí vyhodnocení.
4. Systém vyhodnotí instanci testu.
5. Jestliže test obsahuje otázky, které jsou označeny jako systémem Obrázek 20: Diagram případu užití Výběr kurzu
6. Systém zobrazí otázky a správné odpovědi.
6.7.3 Alternativní posloupnosti událostí
6.7.3.1 Samotest (self test)
1. Uživatel zvolí „Testovat znalosti“ z přehledu obsahu kurzu.
2. Systém zobrazí formulář, kde student vybere počet otázek testu.
3. Uživatel potvrdí volbu.
4. Systém vygeneruje test.
5. Uživatel vyplní test a potvrdí vyhodnocení testu.
6. Systém vyhodnotí test.
7. Systém zobrazí uživatelovy otázky a správné odpovědi.
6.7.3.2 Přehled výsledků
1. Uživatel zvolí přehled výsledků testů z přehledu obsahu kurzu.
2. Systém zobrazí možnost filtrování podle:
• Data.
• Odkaz na detail testu.
6.7.4 Doplňující informace
Speciální požadavky Nejsou definovány.
Předpoklady Uživatel je přihlášen jako student. Kurz obsahuje, alespoň jeden, soubor veřejně přístupných otázek.
Konečné podmínky Přechod na přehled obsahu kurzu.
Přidaná hodnota Studenti mají možnost ověřit si své znalosti.
6.7.5 Diagram případu užití
6.7.6 Prototyp povinného testu
6.8 Administrace systému
6.8.1 Popis
Případ užití slouží pověřené osobě ke správě celého systému. Podmnožina úkonů administrátora odpovídá součtu množin úkonů všech uživatelů. Jinými slovy má administrátor v systému neomezená práva. Případ užití umožňuje navíc administrovat uživatelská práva.
Obrázek 21: Diagram případu užití Testování
Obrázek 22: Prototyp povinného testu
6.8.2 Základní posloupnost událostí (správa uživatelů)
1. Uživatel vybere „Správa uživatelů“ v hlavním menu systému.
2. Systém zobrazí abecedně seřazený seznam uživatelů a filtr s možností filtrování podle práv, typu uživatele, atp.
3. Uživatel má možnost přidat, upravit a mazat práva jednotlivých uživatelů a uživatele pomocí ovládacích prvků, které jsou u každého uživatele.
4. Uživatel potvrdí volbu.
5. Systém informuje uživatele o stavu provedené operace.
6.8.3 Alternativní posloupnosti událostí
6.8.3.1 Administrace kurzů
Administrace kurzů probíhá stejně jako administrace kurzů pedagogy.
6.8.3.2 Administrace systému
1. Uživatel zvolí „Administraci systému“ z hlavního menu administrátora.
2. Systém zobrazí servisní menu, v němž může uživatel změnit:
• Soubor s kaskádovými styly.
• Databázový zdroj.
6.8.4 Doplňující informace
Speciální požadavky Je kladen velký důraz na zabezpečení celého případu užití a pohybu admistrátora v systému.
Předpoklady Uživatel je přihlášen jako administrátor s neomezenými právy.
Konečné podmínky Přechod na přihlašovací stránku.
Přidaná hodnota Administrace systému a práv uživatelů.
6.8.5 Diagram případu užití
6.8.6 Prototyp správy uživatelů
Obrázek 23: Diagram případu užití Administrace systému
Obrázek 24: Prototyp správa uživatelů
7 Architektura
7.1 Úvod
V této kapitole je popsána architektura ELP, který je vyvíjen v rámci této diplomové práce. Jsou stanoveny fundamenty celé architektury a je poskytnut náhled do architektury pomocí více různých pohledů.
7.2 Reprezentace architektury
Architektura je reprezentována řadou pohledů, konkrétně pomocí pohledu případů užití, logického pohledu, procesního pohledu a pohledu nasazení. V rámci těchto pohledů jsou použity diagramy tříd, sekvenční diagramy, diagramy případů užití a ostatní diagramy.
7.3 Architektonické cíle a omezení
• Všichni uživatélé (pedagogové, studenti) musí mít veškerou funkčnost systému přístupnou i mimo školní síť LIANE.
• Bude použita oddělená síťová architektura. Aktivním učastníkem bude klientská část přístupná přes webové rozhraní. Pasivním prvkem pak server umístěný na školní síti LIANE.
• Veškerá uložená data musí být zajištěna proti zneužití třetí osoby.
• Systém musí být přístupný jen oprávněným uživatelům.
• Všechny požadavky na systém z kapitoly 4 musí být vzaty v potaz.
7.4 Pohled na architekturu prostřednictvím případů užití
Pohled na architekturu pomocí případů užití je velmi důležitý. Zobrazuje systém z pohledu jeho funkčnosti poskytované uživatelům. Z těchto důvodů se podrobněji modelem případů užití zabývá již kapitola 6. Následuje obecný pohled na podstatnou část systému pomocí případů užití.
Nejdůležitější případy užití ELP Administrace kurzů.
Administrace obsahu kurzu.
Administrace testů.
Přihlášení na kurz.
Výběr kurzu.
Přihlášení.
Vzdělávání.
Testování.
Komunikace.
Administrace systému.
Aktéři případů užití: Pedagog - Garant, Přednášející, Cvičící.
Student - Účastník, Pozorovatel.
Administrátor.
Obrázek 25: Pohled na podstatnou část systému prostřednictvím případů užití
7.5 Logický pohled na architekturu
Pro ELP byla zvolena zapouzdřená síťová architektura s centrálním umístěním aplikace i dat, rozdělená do tří vrstev. Tato je optimální pro rovnoměrné rozložení výkonu. Jednotlivé vrstvy budou důsledně odděleny a komunikace bude probíhat pouze se sousedními vrstvami. Výhody této architekury jsou především v levné a snadné administraci systému a jednoduššího zabezpečení dat.
Obrázek 26: Třívrstvá architektura ELP
7.5.3 Rozdělení do vrstev a balíčků
Systém je logicky rozdělen do tří vrstev a čtyř balíčků tak, jak je zobrazeno na následujícím obrázku.
7.5.3.1 Rozhraní
Vrstva reprezentuje rozhraní používané uživatelem. Jsou to formuláře, ovládací prvky apod., které slouží uživateli k interakci se systémem. V systému je reprezentováno stránkami. Vrstva rozhraní obsahuje jeden balíček uživatelského rozhraní, který je společný pro všechny uživatele.
7.5.3.2 Funkční
Vrstva reprezentuje třídy, které poskytují obchodní funkčnosti systému. Je rozdělena do dvou logických balíčků funkcionalita systému a služby. Balíček funkcionalita systému obsahuje veškerou funkčnost systému popsanou v kapitole Vize. Balíček služby poskytuje přístup k informačnímu systému Stag.
7.5.3.3 Middleware
Vrstva reprezentuje třídy a mechanizmy zprostředkovávající přístup k relační databázi. Zprostředkovává tzv. objektově-relační mapování.
Obrázek 27: Rozělení do vrstev a balíčků
7.5.4 Use-case realizace
Tato sekce obsahuje logický pohled na vybrané případy užití pomocí sekvenčních diagramů a diagramů tříd. Diagram tříd zobrazuje vztahy mezi jednotlivými třídami. Sekvenční diagram zachycuje interakce a časovou posloupnost.
7.5.4.1 Administrace kurzů Diagram tříd
Obrázek 28: Diagram tříd administrace kurzů
Sekvenční diagram vytvoření kurzu
Sekvenční diagram smazání kurzu
Obrázek 29: Sekvenční diagram vytvoření kurzu
Obrázek 30: Sekvenční diagram smazání kurzu
Sekvenční diagram úpravy kurzu
Obrázek 31: Sekvenční diagram úpravy kurzu
7.5.4.2 Výběr kurzu Diagram tříd
Sekvenční diagram
Obrázek 32: Diagram tříd výběru kurzu
7.4.4.3 Testování Diagram tříd
Obrázek 34: Diagram tříd testování
Sekvenční diagram cvičného testu
Sekvenční diagram povinného testu
Obrázek 36: Sekvenční diagram povinného testu Obrázek 35: Sekvenční diagram cvičného testu
7.6 Procesní pohled
7.7 Pohled nasazení
7.7.1 Klientský počítač
Reprezentuje uživatele připojené ke školní síti LIANE. Jsou to především pedagogové a administrátor přistupující k systému ze školních počítačů. Z menší části také studenti ubytovaní na kolejích a připojení ke školní síti
7.7.2 Externí klientský počítač
Reprezentuje uživatele využívající slušeb systému mimo školní síť. Jsou to především studenti přistupující k systému z domova prostřednictvím internetu a pedagogové přistupující rovněž vně školní sítě pomocí internetu.
Obrázek 38: Pohled nasazení
Obrázek 37: Kontextový diagram z pohledu procesů
7.7.3 E-learningový server
Reprezentuje školní server složený z webového a databázového serveru.
7.7.4 Studijní agenda
Reprezentuje stávající systém studijní agendy Stag poskytující ELP potřebné informace o vyučovaných předmětech.
7.8 Velikost a výkon
Navržená architektura musí splňovat požadavky uvedené v kapitole Vize.
Požadavky na výkon systému určují především tato kritéria a požadované vlastnosti.
• Schopnost systému plynule, do tří sekund, zpracovávat minimálně 85% všech požadavků připojených uživatelů pokud počet uživatelů nepřesáhne počet 90.
• Plynule, v řádu sekund, přistupovat k velkému množství (tisíce) záznamů v databázi.
7.9 Kvalita
Navržená architektura bere v potaz požadavky na kvalitu z kapitoly Vize.
Systém musí splňovat následující požadavky:
• Poskytnout funkcionalitu se střední dobou poruchy maximálně 500 hodin.
• Uživatelské rozhraní je intuitivní a uživatelsky přívětivé. Bežný uživatel, pedagog a student TUL, je schopen intuitivně využívat služeb systému.
• Klientská část systému je kompatibilní se standartními (rok 2009) internetovými prohlížeči.
8 Závěr
Vývoj softwaru řízený procesním frameworkem, jakým je RUP, vnáší do projektu řád a kontrolu nad procesy i projektem samotným. Šetří náklady a snižuje rizika spojená s vývojem softwaru, která byla popsána v již úvodu. Každému členu týmu vymezuje role a s tím spojené zodpovědnosti i úkoly. Díky RUP je mnohem snadnější posoudit, v jakém stádiu vývoje projekt je a jestli bude možné dokončit ho v požadovaném termínu. Nevýhodou, která se u velkých projektů stává nepodstatnou, je nutnost nastudování a implementace frameworku, což konkrétně u RUP není triviální záležitostí. Tvorba znovupoužitelných komponent vede k lepší testovatelnosti již v průběhu vývoje a rovnoměrnějšímu rozdělení práce mezi vývojáři, ale i mezi celé týmy. Udržování aktuální dokumentace a zapracovávání změnových požadavků přispívá k přehlednosti a dobré koordinaci týmu.
V rámci incepční a elaborační fáze byla provedena analýza a návrh ELP.
Byly mimo jiné vypracovány modely případů užití, sekvenční diagramy a byly postaveny fundamenty architektury ELP. Rovněž byla vytvořena e-learningová lekce popisující metodiku RUP. Tato je zpracována formou html kódu a je připravena pro pozdější použití v e-learningovém systému.
Navržený ELP je možno v budoucnu rozšířit o další funkčnosti a rozhraní.
Možným rozšířením by mohlo být doplnění komunikačních kanálů o sms bránu a umožnit tak uživatelům příjem automatických zpráv systému na mobilní telefony.
ELP by neměl být pouhým elektronickým transferem výukového obsahu, měl by být tvořen v kontextu s technologií sématického webu (dále jen SeWe).
V současnosti je v drtivé většině situace taková, že stroje nad daty
„neuvažují“ a jediným prostředkem získání znalostí je vyhledávání založené na klíčových slovech nebo adresářích definovaných lidmi. To sebou nese řadu problémů, uživatelé musí umět tvořit dotazy tak, aby bylo vyhledávání úspěšné, závislé i na slovníku daného jazyka. Někdy vyhledávací služby vrátí dokumentů mnoho (většinu irelevantních). Nebo je naopak dotaz příliš úzký (nevhodně volený).
Vyhledávání je ale pouze první fází, udá lokaci potencionálně zajímavého zdroje, ale nevyextrahuje z něj skutečně hledanou informaci, výsledky často nejsou dále jednoduše strojově použitelné a nejsou vidět v kontextu.
SeWe umožnuje, aby i distribuovaně vytvářený obsah byl mapován na jednotící ontologie a tak systematicky zpřístupněn. Bylo by tedy možné sestavovat kurzy podle individuálních potřeb. Technologie SeWe umožnují vyhledat, zmapovat a vizuálně prezentovat i konceptuálně složité oblasti studovaného tématu i bez didakticky předdefinovaného pořadí pojmů.
SeWe není orientován jen na e-learning. Naopak, je integrující platformou vzdělávání s dalšími procesy v organizaci. A pedagog (expert, autorita) není jediným zdrojem obsahu, na vytváření se masivně podílejí i studující (komunita). Obsah je přizpůsoben potřebám a možnostem studujícího na základě „sémantických pravidel“.
Klíčovými prvky SeWe je konceptualizace dat, jejichž prostředkem jsou ontologie (formalizované reprezentace znalostí určené k jejich sdílení a znovupoužití).
Hlavní přínos SeWe pro ELP je možnost přesně zachytit obsah výukového materiálu (přes doménové ontologie) a možnost přesně zasadit výukový materiál do kontextu, strukturovat jej do logických celků a mapovat je na pojmy.
Seznam použité literatury
[1] ALDORF, Filip. Metodika RUP. [s.l.], 2002. 120 s. Diplomová práce. Dostupný z WWW: <http://objekty.vse.cz/Objekty/RUP >.
[2] PORTIER, Bertrand. SOA terminology overview: Development processes, models, and assets. SOA and Web services [online]. 2007 [cit. 2007-04-05], s. 1.
Dostupný z WWW: <http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/ >.
[3] MARCHESI, Michele, et al. Extreme Programming Perspectives. [s.l.]: Addison-Wesley Professional, 2002. 640 s. ISBN 0-201-77005-9.
[4] KROLL, Per, BOOCH, Grady, KRUCHTE, Kruchten. The Rational Unified Process Made Easy: A Practitioner\'s Guide to the RUP. [s.l.] : Addison-Wesley Professional, 2003. 464 s. ISBN 0-321-16609-4.
[5] Rational Unified Process: Best practices for software development teams. IBM staff [online]. 2003 [cit. 2009-02-30], s. 6-6. Dostupný z WWW:
<http://www.ibm.com/developerworks/rational/library/253.html >.
[6] Liane [online]. 2008 [cit. 2009-01-26]. Dostupný z WWW: <http://liane.tul.cz/cz/
O_síti_LIANE >.
[7] ŠTORK, Radim, VITOUŠ, Otto. Rational Unified Process: stručný průvodce . [s.l.] : [s.n.], 2000. 155 s. ISBN 80-238-6358-4.
Seznam obrázků
Obrázek 1: Schéma projektu RUP...15
Obrázek 2: Schéma projektu XP...16
Obrázek 3: Iterace...19
Obrázek 4: Fáze vývoje a jejich milníky...21
Obrázek 5: Zdrojová a časová náročnost fází...21
Obrázek 6: Kontextový diagram ELP...30
Obrázek 7: Tvorba definic testů, testů a instancí...33
Obrázek 8: Dotazy v rámci kurzu...36
Obrázek 9: Časová osa projektu...39
Obrázek 10: Diagram podstatných případů užití ELP...43
Obrázek 11: Diagram případu užití...44
Obrázek 12: Případ užití Administrace kurzů...47
Obrázek 13: Prototyp zakládání kurzu...48
Obrázek 14: Diagram případu užití "Administrace obsahu"...50
Obrázek 15: Prototyp přidání obsahu...51
Obrázek 16: Případ užití Administrace testů...54
Obrázek 17: Prototyp tvorby definice testu...54
Obrázek 18: Diagram případu užití Vzdělávání...56
Obrázek 19: Prototyp přehledu obsahu kurzu...56
Obrázek 20: Diagram případu užití Výběr kurzu...58
Obrázek 21: Diagram případu užití Testování...60
Obrázek 22: Prototyp povinného testu...60
Obrázek 23: Diagram případu užití Administrace systému...62
Obrázek 24: Prototyp správa uživatelů...62
Obrázek 25: Pohled na podstatnou část systému prostřednictvím případů užití...64
Obrázek 26: Třívrstvá architektura ELP...65
Obrázek 27: Rozělení do vrstev a balíčků...66
Obrázek 28: Diagram tříd administrace kurzů...67
Obrázek 29: Sekvenční diagram vytvoření kurzu...68
Obrázek 30: Sekvenční diagram smazání kurzu...68
Obrázek 32: Diagram tříd výběru kurzu...70
Obrázek 33: Sekvenční diagram výběru kurzu...70
Obrázek 34: Diagram tříd testování...71
Obrázek 35: Sekvenční diagram cvičného testu...72
Obrázek 36: Sekvenční diagram povinného testu...72
Obrázek 37: Kontextový diagram z pohledu procesů...73
Obrázek 38: Pohled nasazení...73
Seznam tabulek
Tabulka 1: Vybrané role z XP a jejich obdoby v RUP...17Přílohy
Příloha A: Obsah přiloženého CD
Na přiloženém CD jsou umístěny tyto adresáře:
/DP
Tento dokument ve formátu PDF a ODT.
/RUP
Elearningová lekce RUP do ELP.
/PROT Prototypy.
Příloha B: Prototypy
Prototyp přehled obsahu kurzu
Prototyp vytvoření nového kurzu
Prototyp přidání obsahu kurzu
Prototyp tvorby definice testu
Prototyp povinného testu
Prototyp správa uživatelů