System Publikacji W Internecie Materiałów Multimedialnych

Politechnika Warszawska Rok akademicki 2011/2012 Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki

PRACA DYPLOMOWA INZYNIERSKA˙

Maciej Pachocki

System publikacji w internecie materiałów multimedialnych

Opiekun pracy: mgr in˙z.Krzysztof Chabko

Ocena ......

...... Podpis Przewodnicz ˛acego Komisji Egzaminu Dyplomowego Specjalno´s´c: In˙zynieriaSystemów Informatycznych

Data urodzenia: 15 grudnia 1989 r.

Data rozpocz ˛eciastudiów: 1 pa´zdziernika 2008 r.

Zyciorys˙

Urodziłem si˛e15 grudnia 1989 r. w Białymstoku. Ucz˛eszczałemdo gimnazjum nr 5. Nast˛epniew latach 2005-2008 uczyłem si˛ew III Liceum Ogólnokształc ˛acym w Białymstoku. W roku 2007 udało mi si˛euzyskac´ certyﬁkat CAE z j˛ezykaangiel- skiego. Od roku 2008 studiuj˛ena Politechnice Warszawskiej na wydziale EITI. Moimi głównymi zainteresowaniami s ˛apiłka no˙zna oraz hokej na lodzie. W hokeja na lodzie gram od pocz ˛atkuszkoły gimnazjalnej. Ponadto przez wiele lat sklejałem modele szybowców ucz˛eszczaj˛acdo modelarni.

...... podpis studenta

Egzamin dyplomowy

Zło˙zyłegzamin dyplomowy w dn......

Z wynikiem ......

Ogólny wynik studiów ......

Dodatkowe wnioski i uwagi Komisji ......

...... Streszczenie

Celem tej pracy było zaprojektowanie i stworzenie systemu, który b ˛edzieumo ˙z- liwiał publikowanie materiałów multimedialnych przy wykorzystaniu ogólnodost ˛ep- nego medium jakim jest dzi´sinternet. Publikacja tych materiałów miała byćdoko- nywana przez nauczyciela, który ma na celu nauczyćna odległo´sćinnych u ˙zytkow- ników systemu. Powstały system miał równie ˙zskupićsi ˛ena stronie e-learningu, z czym wi ˛azałosi ˛estworzenie okre´slonychról w systemie oraz ograniczenie upraw- nie ńdla poszczególnych u ˙zytkowników. Zaimplementowana aplikacja korzysta z relacyjnej bazy danych PostgreSQL oraz została napisana w j ˛ezykuPHP z u ˙zyciemframework’a Yii. Aplikacja jest dost ˛epna poprzez przegl ˛adark˛einternetow ˛a,a serwerem WWW wykorzystanym do obsługi ˙z˛adańu ˙zytkownikówjest serwer WWW Apache.

Słowa kluczowe: system publikacji multimediów (wideo i audio), system e-learningowy, aplikacja internetowa, PHP, Yii.

Abstract

Title: System publishing multimedia materials in internet.

Main objective of this thesis was to design and implement a system which will enable its users to publish multimedia materials over the internet. Publication of this materials should be possible for a teacher whose main purpose is to remotely teach other users of the system. Therefore, created system focuses on e-learning side which was connected with creating certain roles in system and restricting possibilites to particular users. Implemented application employs relational database system PostgreSQL and was written in PHP language with using framework Yii. Application is accessible by web browser. Web server used in system to handle user requests is Apache Web Server.

Key words: system publishing multimedia (video and audio), e-learning system, web application, PHP, Yii. Spis tresci´

1. Wprowadzenie ...... 1 2. Wybór aplikacji do analizy i podstawy współczesnych aplikacji internetowych 2 2.1. Poszukiwania aplikacji do analizy ...... 2 2.2. Czym jest aplikacja internetowa ? ...... 2 2.3. HTTP i jego ograniczenia ...... 3 2.4. Nowa technologia - AJAX ...... 3 2.5. Podejscia´ stosowane w tworzeniu aplikacji internetowych ...... 3 2.5.1. Podejscia´ programowe ...... 3 2.5.2. Podejscia´ szablonowe ...... 4 2.5.3. Podejscia´ hybrydowe ...... 4 2.5.4. Zastosowanie framework’u ...... 4 2.6. Popularnos´c´ framework’ów ...... 4 3. Przegl ˛adaplikacji umo˙zliwiaj˛acychpublikacj ˛emateriałów multimedialnych .6 3.1. YouTube ...... 6 3.1.1. Przepływ pojedynczego ˙z˛adaniaHTTP ...... 6 3.1.2. Zastosowane serwery i narz˛edziaz nimi zwi ˛azane ...... 7 3.1.3. Obsługa wideo ...... 7 3.1.4. Obsługa miniaturek zdj˛ec´ ...... 8 3.1.5. Bazy danych ...... 8 3.1.6. Priorytetyzacja szybkosci´ dost˛epudo ró˙znychcz˛esci´ serwisu ...... 9 3.1.7. Partycjonowanie baz danych ...... 9 3.1.8. Podsumowanie ...... 10 3.2. PHPmotion ...... 10 3.2.1. Wymagania serwerowe (Linux/Unix) ...... 10 3.2.2. Podstawowe mo˙zliwosci´ oferowane przez system ...... 10 3.2.3. Podsumowanie ...... 11 3.3. Plumi ...... 11 3.3.1. Podstawowe mo˙zliwosci´ systemu ...... 11 3.3.2. Podsumowanie ...... 11 3.4. Moodle ...... 11 3.4.1. Podstawowe mo˙zliwosci´ systemu ...... 12 3.4.2. Podsumowanie ...... 14 4. Tworzony system e-learningowy ...... 15 4.1. Specyﬁkacja i analiza wymagan...... ´ 15 4.1.1. Wizja, zakres oraz cel projektu ...... 15 4.1.2. Role i aktorzy w systemie ...... 15 4.1.3. Wymagania funkcjonalne ...... 16 4.1.4. Wymagania niefunkcjonalne ...... 22 4.2. Diagramy oraz scenariusze realizacji przypadków u˙zycia ...... 22 4.3. Wybrana technologia ...... 43 4.3.1. Rozwi ˛azaniai wykorzystane oprogramowanie ...... 43 4.3.2. Podstawowe elementy systemu ...... 43 4.3.3. Budowa aplikacji w PHP i prezentacja systemu po stronie przegl ˛adarki internetowej ...... 44 Spis tre´sci ii

4.3.4. Racjonalnosć´ dokonanych wyborów ...... 44 5. Implementacja systemu ...... 46 5.1. Framework Yii ...... 46 5.2. Projekt bazy danych ...... 51 5.2.1. Struktura bazy danych ...... 51 5.2.2. Oprogramowanie bazy danych ...... 51 5.2.3. Opis tabel ...... 54 5.3. Struktura stworzonej aplikacji internetowej ...... 58 5.3.1. Podstawowe elementy systemu ...... 58 5.3.2. Aplikacja serwerowa ...... 59 5.3.3. Aplikacja kliencka ...... 61 5.4. Wysyłanie i przetwarzanie plików po stronie serwera ...... 62 5.5. Testy automatyczne aplikacji ...... 68 5.5.1. Testy funkcjonalne ...... 68 5.5.2. Testowanie aplikacji napisanej w Yii ...... 68 5.5.3. Srodowisko´ testowe ...... 69 5.5.4. Wyniki testów ...... 70 6. Podsumowanie ...... 71 Narz ˛edziaimplementacji i dokumentacji ...... 72 Zał ˛acznikA: Listy kodeków oraz formatów wspieranych przez narz ˛edzieFFmpeg 73 Zał ˛acznikB: Instrukcja u˙zytkowaniasystemu ...... 75 B.1: Instrukcja dla goscia´ ...... 76 B.2: Instrukcja dla ucznia ...... 80 B.3: Instrukcja dla nauczyciela ...... 83 B.4: Instrukcja dla administratora ...... 88 Zał ˛acznikC: Instrukcja instalacji oprogramowania ...... 92 Zał ˛acznikD: Zawartosć´ doł ˛aczonejpłyty CD ...... 92 Bibliografia ...... 93 Materiały z sieci internet ...... 93 1. Wprowadzenie

W obecnych czasach w Internecie istnieje wiele serwisów umo˙zliwiaj˛acychpublikacj˛emateriałów wideo oraz audio. Najwi˛ekszymz nich jest serwis YouTube, który oferuje swoim u˙zytkownikombardzo du˙zomo˙zliwosci,´ zapewniaj ˛acprzy tym wysokie pr˛edkosci´ wysyłania oraz odtwarzania plików multimedialnych dodanych do systemu.

Poza serwisami skupionymi głównie na publikacji multimediów istniej ˛arównie˙z takie, które w podstawowym zamysle´ tworzone s ˛ado nauczania na odległos´c.´ S ˛a to tzw. systemy e-learningowe – VLE (ang. Virtual Learning Environment). Jednym z najbardziej popularnych systemów umo˙zliwiaj˛acychnauczanie na odległos´c´ jest system Moodle.

Podstawowym celem tworzonego systemu jest udost˛epnieniejego u˙zytkownikom mo˙zliwosci´ publikacji oraz zarz ˛adzaniamateriałami multimedialnymi, podobnie jak jest to mo˙zliwew serwisie YouTube. Czynnosci´ te maj ˛abyc´ mo˙zliwetylko dla wybranej kategorii u˙zytkownikóworaz odbywac´ si˛ew kontekscie´ nauczania (e-learningu). Przykładowym scenariuszem u˙zytkowanianowego systemu jest umieszczenie przez nauczyciela – lekarza kursu z materiałem wideo pokazuj ˛acymjak poprawnie wyko- nywac´ zastrzyki oraz jego odtworzenie przez ucznia – piel˛egniark˛e.

Ilos´c´ aplikacji umo˙zliwiaj˛acychna publikacj˛ew Internecie materiałów wideo i audio stale rosnie.´ Wi˛ekszos´c´ z nich jest dost˛epna poprzez przegl ˛adark˛e internetow ˛a. Coraz cz˛esciej´ celem publikacji plików nie jest wył ˛acznierozrywka. W systemach e-learningowych głównym celem jest nauczanie pewnej grupy ludzi w celu zdobycia konkretnej wiedzy.

Drugi oraz trzeci rozdział pracy stanowi ˛acz˛es´c´ teoretyczn ˛a.W rozdziale 2 przedstawione zostały podstawy współczesnych aplikacji internetowych. W kolejnym opisane zostały aplikacje internetowe, które s ˛azbli˙zonefunkcjonalnie do stworzonego systemu. Dwa rozdziały (4 i 5) opisuj ˛aproces projektowania i implementacji projektu. Rozdział 4 przedstawia wymagania postawione przed projektowanym systemem oraz wybran ˛atechnologi˛eimplementacji projektu. W rozdziale 5 opisana została implementacja systemu. Na koniec pracy przedstawione zostało podsumowanie wykonanej pracy oraz mo˙zliwosci´ dalszego rozwoju stworzonej aplikacji. 2. Wybór aplikacji do analizy i podstawy współczesnych aplikacji internetowych

2.1. Poszukiwania aplikacji do analizy

W czasie poszukiwan´ aplikacji, których funkcjonalnosć´ byłaby zbli˙zonado funkcjonalnosci´ mojego docelowego systemu zdecydowana wi˛ekszosć´ z nich została zaimplementowana w architekturze aplikacji internetowej. W zwi ˛azkuz tym serwisy wybrane do analizy s ˛aserwisami dost˛epnymipoprzez przegl ˛adark˛eWWW. Do analizy wybrałem serwisy YouTube, PHPMotion, Plumi i Moodle. Cechuj ˛asi˛e one znaczn ˛apopularnosci´ ˛ai du˙zymsukcesem osi ˛agni˛etymna rynku. Najlepszym chyba wyznacznikiem sukcesu jest ilosć´ u˙zytkownikówkorzystaj ˛acychz wybranych aplikacji.

2.2. Czym jest aplikacja internetowa ?

Zgodnie z deﬁnicj ˛azaczerpni˛et˛az publikacji [3] aplikacja internetowa jest aplikacj ˛azrealizowan ˛aw architekturze klient-serwer, która u˙zywaprzegl ˛adarkiinternetowej jako programu klienckiego. Dostarcza ona dynamicznej tresci´ poprzez serwery WWW rozproszone w Internecie. Ró˙zni si˛eznacznie od zwykłych stron internetowych, które ograniczaj ˛asi˛edo wysyłania u˙zytkownikowistatycznych tresci´ pochodz ˛acychze zwykłych plików. Aplikacja internetowa dostarcza tres´c´ genero- wan ˛adynamicznie na podstawie zawartosci´ ˙z˛adaniaHTTP, zachowan´ u˙zytkownika czy sugeruj ˛acsi˛ewzgl˛edamibezpieczenstwa.´

Rysunek 2.1. Nieodł ˛aczneelementy aplikacji internetowej 2.3. HTTP i jego ograniczenia 3

Powy˙zszailustracja przedstawia podstawowe elementy typowej aplikacji internetowej. Istnienie innych elementów poza klientem i serwerem HTTP jest zale˙zne od wybranej technologii. Standardowo w aplikacjach wykorzystuje si˛eró˙zne´zródła danych, np. bazy danych czy usługi internetowe.

2.3. HTTP i jego ograniczenia

Podstawowym protokołem wykorzystywanym do komunikacji klienta z serwerem jest protokół HTTP. Jest to protokół bezstanowy, z czym wi ˛a˙z˛asi˛epewne ograniczenia. Bazuje on na paradygmacie ˙z˛adanie-odpowied´z,a kolejne ˙z˛adaniapocho- dz ˛aceod przegl ˛adarkis ˛aniezale˙zneod pozostałych mimo, ˙zecz˛estowykonywane s ˛aw obr˛ebietej samej sesji. W celu wprowadzenia stanu pomi˛edzy ˙z˛adaniaminajcz˛esciej´ stosuje si˛e ciasteczka (ang. cookies). Ciasteczka s ˛ato pewne dane, które wysyła serwer WWW i zleca, aby zostały zapami˛etane. W tym celu posługuj˛esi˛eodpowiednim nagłów- kiem. Po otrzymaniu ˙z˛adaniaHTTP z takim nagłówkiem, przegl ˛adarkiinternetowe najcz˛esciej´ zapami˛etuj˛adane, które zostały w nim umieszczone. Dane te s ˛awysy- łane wraz z ˙z˛adaniemHTTP, pod warunkiem spełnienia odpowiednich wymogów, które s ˛azale˙zneod konkretnego ciasteczka.

2.4. Nowa technologia - AJAX

Fakt, i˙zprotokół HTTP jest protokołem bezstanowym oraz bazuje na paradygmacie ˙z˛adanie-odpowied´zokazał si˛esporym ograniczeniem w pocz ˛atkowymrozwoju aplikacji internetowych. Wszelka zmiana tresci´ na stronie internetowej wyma- gała przeładowania całej strony, co wi ˛azałosi˛ez du˙zymruchem po stronie serwe- rów WWW. Ponadto zachowanie takie było nieintuicyjne dla u˙zytkownikówwitryn. Technologi ˛a,która przyczyniła si˛edo tego, ˙zeaplikacje internetowe stały si˛ew rze- czywistosci´ interaktywne jest AJAX (ang. Asynchronous Javascript and XMLHttpRe- quest). Pozwala ona z poziomu j˛ezykaJavascript wysłac´ asynchronicznie podrz˛edne ˙z˛adanieHTTP do serwera WWW bez przeładowywania strony. Odpowied´ztakiego ˙z˛adanialub jej cz˛es´c´ jest zazwyczaj wstawiana do pewnego fragmentu strony internetowej. Rozwi ˛azanietakie sprzyja zmniejszeniu ruchu pomi˛edzyklientem, a serwerem oraz znacznie poprawia wra˙zeniei doswiadczenie´ u˙zytkownika.

2.5. Podejscia´ stosowane w tworzeniu aplikacji internetowych

2.5.1. Podejscia´ programowe W rozwi ˛azaniachstosuj ˛acychpodejscie´ programowe (lub skryptowe) zdecydowana wi˛ekszosć´ dynamicznej tresci,´ która jest odsyłana do klienta HTTP jest tworzona w obr˛ebiekodu ´zródłowego. Dotyczy to równie˙zznaczników HTML, a wi˛ec i wygl ˛adustrony prezentowanego dla u˙zytkownika koncowego.´ Stawia to progra- mistom i projektantom stron spore problemy, poniewa˙zka˙zdazmiana, zarówno w działaniu jak i wygl ˛adzieaplikacji wymaga interwencji programisty. Tworzenie aplikacji jest skupione wokół kodu ´zródłowego(ang. code-centric), co ogranicza swobod˛epracy dla projektantów interfejsów graficznych. Mechanizmy wykorzystuj ˛acetakie podejscie´ to, np. CGI lub Servlet API. 2.6. Popularno´sćframework’ów 4

2.5.2. Podejscia´ szablonowe W przeciwienstwie´ do podejscia´ programowego w tym podejsciu´ wi˛eksz˛auwag˛e skupia si˛ena formatowaniu strony (ang. page-centric), a mniej na pisaniu kodu ´zródłowego. Technologie sugeruj ˛acesi˛etakim podejsciem´ udost˛epniaj˛awiele kon- strukcji formatuj ˛acych,które nie wymagaj ˛adu˙zejwiedzy programistycznej. W takim przypadku łatwiej jest pracowac´ z plikami dla projektantów stron. Przykładowymi technologiami z takim podejsciem´ s ˛aSSI, Cold Fusion oraz Ve- locity. Nadal istnieje, podobnie jak w podejsciu´ programowym problem odseparo- wania dost˛epudo danych od ich prezentacji, co utrudnia podział pracy.

2.5.3. Podejscia´ hybrydowe Podejscia´ hybrydowe wykorzystuj ˛azarówno konstrukcje formatuj ˛acejak i kod ´zródłowy. Fragmenty kodu ´zródłowegos ˛azwyczajowo umieszczane mi˛edzyznacz- nikami HTML i s ˛aone ograniczone odpowiednimi znakami w celu pó´zniejszejinter- pretacji. Przykładowe technologie działaj ˛acew ten sposób to PHP, ASP oraz JSP. W rozwi ˛azaniachtych zarówno logika aplikacji jak i prezentacja danych jest przemie- szana. Skutkuje to trudnosciami´ przy rozwijaniu aplikacji.

2.5.4. Zastosowanie framework’u Framework jest szkieletem aplikacji, którego głównym celem jest oddzielenie logiki biznesowej od prezentacji danych. Poza tymi zaletami, implementuj ˛aone cz˛estopowtarzalne funkcjonalnosci,´ które nie musz ˛abyc´ tworzone od zera przez programistów. Framework aplikacji internetowej najcz˛esciej´ prezentuje podział na moduły dla programistów i projektantów stron. Przykładem framework’u mo˙zebyc´ Struts, który implementuje wzorzec MVC i sprawia, i˙zmo˙znawykorzystac´ JSP w pewnym stopniu odchodz ˛acod podejscia´ hybrydowego.

2.6. Popularnos´c´ framework’ów

Na rynku aplikacji internetowych coraz wi˛eksz˛apopularnos´c´ i poparcie zyskuj ˛a frameworki. Wymagaj ˛aone od programisty wi˛ekszejdyscypliny pracy, ale i sprzy- jaj ˛aszybkiemu tworzeniu programów. Najpowszechniej stosowanym i implementowanym wzorcem projektowym jest wzorzec MVC (ang. Model-View-Controller). Po- zwala on mi˛edzyinnymi na jednoznaczny podział modułów na moduły do napisania przez projektantów stron oraz moduły do napisania przez programistów aplikacji serwerowej. 2.6. Popularno´s´cframework’ów 5

Rysunek 2.2. Wzorzec projektowy Model-Widok-Kontroler

Wa˙znymiatutami tego podejscia´ jest oddzielenie dost˛epu do danych (Modelu) od prezentacji tych danych (Widoku). Podział taki umo˙zliwiana łatw ˛azmian˛ewidoku w zale˙znosci´ od ustawien´ u˙zytkownika, co okazuje si˛e przydatne w aplikacjach internetowych. 3. Przegl ˛adaplikacji umo˙zliwiaj˛acychpublikacj ˛e materiałów multimedialnych

3.1. YouTube

Na pocz ˛atkuswojego istnienia YouTube był pisany w j˛ezykuPHP. Po przej˛eciu serwisu przez ﬁrm˛eGoogle dane na temat skalowalnosci´ i technologii u˙zytej do rozwijania tego serwisu zostały przedstawione na konferencji. Odbyła si˛eona w Seattle w dniu 23 czerwca 2007 r. i została przeprowadzona przez Cuong Do. Poni˙zszeinformacje zostały sporz ˛adzonena jej podstawie. Pozycja [14] prezentuje odnosnik´ URL do zapisu wideo z tej konferencji.

3.1.1. Przepływ pojedynczego ˙z˛adaniaHTTP Zanim ˙z˛adanieod klienta (zazwyczaj jest nim przegl ˛adarkainternetowa u˙zytkownika) trafi do serwera WWW przechodzi one przez urz ˛adzenieNetScaler. Urz ˛a- dzenie te umo˙zliwiarównowa˙zenieobci ˛a˙zenia(ang. load balancing) i przechowywanie w pami˛ecipodr˛ecznejstatycznych tresci.´ Jako serwer WWW został u˙zyty serwer Apache z wł ˛aczonymmodułem mod_fastcgi, który umo˙zliwiakomunikacj˛e oprogramowania serwera Apache z innymi programami działaj ˛acymina serwerze lub innym komputerze. Z˙ ˛adaniao okreslonej´ strukturze trafiaj ˛aod serwera Apache do serwera aplikacji, który został napisany w j˛ezykuPython. Serwer ten natomiast ł ˛aczysi˛ez bazami danych i uzupełnia odpowied´zprzekazan ˛ado niego przez serwer Apache o odpowiedni ˛azawartosć.´ Po dynamicznym uzupełnieniu odpowied´zjest wysyłana do serwera Apache, który jest odpowiedzialny za jej odesłanie do przegl ˛adarkiinternetowej u˙zytkownika. 3.1. YouTube 7

Rysunek 3.1. Przepływ pojedy ´nczego˙z˛adaniaHTTP

3.1.2. Zastosowane serwery i narz ˛edziaz nimi zwi ˛azane a) serwer WWW Apache działaj ˛acyna systemie SUSE Linux, b) serwer aplikacji napisany w j˛ezykuPython, c) u˙zyciepsyco – kompilatora JIT z Pythona do C dla wa˙znychcz˛esci´ aplikacji, d) przechowywanie kodu HTML w pami˛ecipodr˛ecznejoraz serializacja obiektów w celu optymalizacji czasu dost˛epudo danych.

3.1.3. Obsługa wideo Ka˙zdy materiał wideo udost˛epnianyjest przez tzw. “mini-cluster”, czyli przez kilka komputerów. Dzi˛ekitemu jesli´ którys´ komputer ulegnie awarii materiał wideo b˛edzienadal dost˛epny. Jako serwer do obsługi wideo został u˙zytyLighttpd. Najbardziej popularne ma- teriały video zostały umieszczone w sieciach CDN (ang. Content Delivery Network), które korzystaj ˛acz pami˛ecioperacyjnej zapewniaj ˛anajszybszy dost˛epdo najcz˛e- sciej´ ogl ˛adanychmateriałów. 3.1. YouTube 8

3.1.4. Obsługa miniaturek zdj ˛ec´

Problemy • du˙za ilosć´ miniaturek, ze wzgl˛edu na to, ˙ze dla ka˙zdego materiału wideo odpowiadaj ˛a4 miniaturki; • du˙za liczba ˙z˛adan´ o miniaturki, zwi ˛azanaz tym, ˙ze na jednej stronie www mo˙zebyc´ wyswietlonych´ ich kilkadziesi ˛at. Pocz ˛atkowostosowany był serwer Apache. Nast˛epniezastosowano Squid, który okazał si˛elepszy, ale w dalszym okresie czasu malała jego wydajnosć,´ co nie było do zaakceptowania. Ostatecznie do obsługi miniaturek zdj˛ec´ wykorzystano serwer Lighttpd, który został zmodyfikowany w celu bardziej wydajnego dost˛epudo obrazków przechowywanych na dysku. Domyslnie´ serwer Lighttpd jest uruchamiany jako jeden proces z jednym w ˛atkiemgłównym. Aby odczyt z dysku nie blokował w ˛atkugłównego serwera zmieniono kod Lighttpd i wprowadzono wielow ˛atkowosć.´ Odczyty mog ˛abyc´ wykonywanie przez w ˛atkirobocze, które nie wstrzymuj ˛aw ˛atkugłównego. W ˛atek główny mo˙zezlecic´ odczyt któremus´ z w ˛atkówroboczych, a samemu w tym czasie odczytywac´ miniaturki, np. z pami˛ecipodr˛ecznej. Na pocz ˛atkuminiaturki obrazków przechowywano w zwykłych katalogach two- rz ˛acwielopoziomowe struktury drzewiaste. Sprawiało to mi˛edzyinnymi problem z kopiowaniem miniaturek na inny komputer – zajmowało to po prostu du˙zoczasu. Lepszym rozwi ˛azaniemokazało si˛eu˙zycie Google BigTable – rozproszonego maga- zynu danych. Ze wzgl˛eduna to, ˙ze jest to system rozproszony, aby zmniejszyc´ opó´znieniezastosowano du˙z˛ailosć´ poziomów pami˛ecipodr˛ecznejmi˛edzy´zródłem danych, a klientem.

3.1.5. Bazy danych

Typ i zastosowanie • relacyjna baza danych MySQL, • przechowuj ˛ametadane – dane u˙zytkowników (nazwa, hasło), tytuły opisów materiałów wideo, wiadomosci´ w systemie, itp.

Optymalizacje dost ˛epudo baz danych • optymalizacje zapytan´ SQL, • zastosowanie memcached w celu rzadszych odwołan´ do bazy danych, a cz˛est- szych do pami˛ecioperacyjnej, • stosowanie pami˛ecipodr˛ecznejpo stronie serwera aplikacji.

Replikacja baz danych Pocz ˛atkowow serwisie YouTube istniała jedna baza danych i jedna jej kopia. Wraz z rozwojem serwisu wprowadzono repliki bazy danych. Spowodowało to nie tylko szybszy odczyt, ale równie˙zproblem z propagacj ˛azapisu rekordów od bazy głównej (master) do replik baz danych. Pojawiało si˛emało przewidywalne opó´z- nienie, wynikaj ˛acez tego, ˙ze replikacja bazy danych w MySQL jest całkowicie asynchroniczna i pozbawiona wewn˛etrznegospójnego mechanizmu zapisywania. W MySQL w replikach baz danych, w przeciwienstwie´ do bazy głównej, wyst˛epuje 3.1. YouTube 9 jeden w ˛atekreplikuj ˛acy,który staje si˛eproblemem, poniewa˙zprzy dłu˙zszychuak- tualnieniach blokuje on nast˛epneuaktualnienia i zwi˛ekszaopó´znienierepliki. Aby zmniejszyc´ te opó´znieniewykorzystano fakt, ˙zew MySQL wyst˛epujejeden w ˛atekdo buforowania zapytan´ SQL i jeden w ˛atekdo ich wykonywania. Optymalizacja ta do- tyczyła zapytan´ SQL, które uaktualniały rekordy w bazie danych. Zaprojektowano narz˛edzie(DB Cache Priming), które przy wczytywaniu zapytan´ SQL do bufora, czyli przed ich wykonaniem, dokonywało odczytów tych rekordów w bazie danych, któ- rych dotyczyły zapytania oraz nie znajdowały si˛ew pami˛ecipodr˛ecznej. Dzi˛ekita- kiemu rozwi ˛azaniuw ˛atekwykonuj ˛acyzapytania nie musiał byc´ wstrzymywany ze wzgl˛eduna mog ˛acywyst ˛apic´ odczyt dyskowy, a zapytania SQL były wykonywane błyskawicznie. Spowodowało to znaczne zmniejszenie opó´znieniareplikacji.

3.1.6. Priorytetyzacja szybkosci´ dost ˛epudo ró˙znychcz ˛esci´ serwisu W trakcie rozwoju serwisu YouTube wzi˛etopod uwag˛efakt , ˙zenajwa˙zniejszejest to, aby sprawnie i szybko wyswietlane´ były strony z materiałami wideo. Skutkiem tego był podział replik baz danych na pule zasobów: pula dotycz ˛acamateriałów wideo i pula generalna na rzeczy pozostałe, np. na rzeczy zwi ˛azane z usługami spo- łecznosciowymi.´ Do baz danych w puli generalnej traﬁały bardziej skomplikowane zapytania SQL, które zajmowały wi˛ecejczasu.

3.1.7. Partycjonowanie baz danych Monolityczn ˛abaz˛e danych, która zawierała dane wszystkich u˙zytkowników podzielono na “kawałki”, z których ka˙zdyzawierał cz˛esć´ wszystkich u˙zytkowników. Ograniczyło to ilosć´ dost˛epów do dysku na jednej maszynie, a zwi˛ekszyło ilosć´ dost˛epówdo pami˛eci.

Obecnie YouTube jest pisany głównie w Javie bazuj ˛acna framework’u Guice. Do odtwarzania wideo jest wymagany Adobe Flash Player.

Podstawowe mo˙zliwosci´ oferowane przez serwis YouTube • publikowanie filmów, równie˙zw formacie High Definition; • edycja filmu przed jego opublikowaniem, mo˙zliwosć´ dodania d´zwi˛ekudo sekwencji wideo; • komentowanie obejrzanych filmów, mo˙zliwosć´ oceniania komentarzy wysta- wionych przez inne osoby, komentarze z najwy˙zsz˛ailosci´ ˛agłosów dodatnich pojawiaj ˛asi˛ena samej górze pola na komentarze – tu˙zpod odtwarzaczem z ocenianym filmem; • wypo˙zyczaniefilmów; • ocenianie filmu poprzez klikanie “Lubi˛e”; • wyszukiwanie filmów poprzez wpisanie słowa kluczowego, tematu lub tytułu filmu, dost˛epnes ˛arównie˙zró˙znefiltry w celu zaw˛e˙zeniarezultatów wyszukiwania; • prowadzenie kanału przez u˙zytkownika serwisu YouTube, w którym s ˛a umieszczane informacje o jego opublikowanych i ulubionych filmach oraz jego listy odtwarzania; • mo˙zliwosć´ subskrypcji do wybranych kanałów innych u˙zytkowników; 3.2. PHPmotion 10

• dzielenie si˛eodnosnikami´ do ﬁlmów poprzez umieszczenie ich na portalach społecznosciowych´ (np. Facebook, Twitter).

3.1.8. Podsumowanie Serwis YouTube jest chyba najlepszym przykładem serwisu rozwijanego i skie- rowanego głównie na publikowanie materiałów wideo. Głównymi jego zaletami s ˛a wysoka niezawodnos´c´ (repliki baz danych, ﬁlmy udost˛epnianeprzez “mini-cluster”) oraz szybki dost˛epdo materiałów wideo (CDN). Godnym uwagi jest fakt, ˙zew rozwoju serwisu zastosowano ró˙zneserwery WWW w zale˙znosci´ od pobieranej tresci´ w celu optymalizacji wykonywanych zadan.´

3.2. PHPmotion

PHPmotion jest darmowym systemem zarz ˛adzaniatresci´ ˛a(ang. Content Mana- gement System), który pozwala jego u˙zytkownikomdzielic´ si˛eﬁlmami, muzyk ˛aoraz zdj˛eciami. Dzi˛ekitemu oprogramowaniu mo˙znastworzyc´ własn ˛astron˛efunkcjo- nalnie zbli˙zon˛ado serwisu YouTube. Powy˙zszysystem został napisany w PHP. Na stronie programu PHPmotion mo- ˙zemyznale´zc´ wymagania co do serwerów potrzebnych do uruchomienia tego oprogramowania, co w du˙zejmierze daje przegl ˛adu˙zytychtechnologii, narz˛edzii bibliotek do zbudowania tego systemu.

3.2.1. Wymagania serwerowe (Linux/Unix) • PHP 4.3 lub wy˙zsze(z obsług ˛aCLI), • serwer bazy danych MySQL, • LAME MP3 Encoder, • Libogg + Libvorbis, • Mencoder oraz Mplayer, • FFMpeg-PHP, • GD Library 2 lub wy˙zsza, • CGI-BIN, • zdolny do uruchamiania procesów w tle.

3.2.2. Podstawowe mo˙zliwosci´ oferowane przez system • publikowanie oraz usuwanie filmów wideo; • komentowanie filmów wideo, blogów, zdj˛ec´ oraz stron profilowych; • tworzenie albumów zdj˛ec;´ • wsparcie dla formatu MP3 – automatyczne odczytywanie tytułu, gatunku, itp. z utworu muzycznego; • utworzenie własnego bloga; • mo˙zliwosć´ dodania materiałów wideo do “ulubionych”; • unikatowa strona dla ka˙zdego członka systemu, istnieje mo˙zliwosć´ zmiany informacji profilowych oraz obrazka reprezentuj ˛acegoosob˛ew systemie; • wewn˛etrznysystem komunikacji mi˛edzyu˙zytkownikamisystemu pozwalaj ˛acy na wysyłanie wiadomosci´ do u˙zytkownikóww systemie. 3.3. Plumi 11

3.2.3. Podsumowanie System PHPmotion jest ciekaw ˛apozycj ˛adla osób, które chciałyby zało˙zyc´ własny serwis z du˙z˛aliczb ˛abardzo ciekawych mo˙zliwosci.´ Wykorzystuje cz˛estospotykane i sprawdzone zestawienie: aplikacji napisanej w PHP, która korzysta z bazy danych MySQL. Ponadto w serwisie PHPmotion wykorzystano du˙zo bibliotek b˛ed˛acych oprogramowaniem open-source.

3.3. Plumi

Plumi jest darmowym systemem zarz ˛adzaniatresci´ ˛awideo, który bazuje na systemie Plone, który z kolei został napisany na podstawie systemu Zope. Domysl-´ nie system Plone przechowuje wszystkie informacje w wbudowanej transakcyjnej, obiektowej bazie danych systemu Zope – Zope Object Database (ZODB). Trzon systemu Plumi – Plone jest pisany głównie w j˛ezykuPython oraz Java- script (wł ˛aczaj˛acbibliotek˛ejQuery). Wysyłanie dowolnego pliku na serwer mo˙ze odbywac´ si˛eprzez protokół HTTP. Wi˛ekszepliki wysyłane s ˛aprzez protokół FTP.

3.3.1. Podstawowe mo˙zliwosci´ systemu • ogl ˛adaniei sci´ ˛aganiefilmów wideo, do ogl ˛adaniafilmów wykorzystywany jest darmowy odtwarzacz Flash - flowplayer; • publikowanie wideo, automatyczne generowanie miniaturek dla filmów umieszczanych w serwisie, progres wysyłania pliku wideo na serwer; • publikowanie informacji i wydarzen;´ • przegl ˛adaniemateriałów wideo po wybranej kategorii, kraju, temacie, gatunku czy etykiecie; • publikowanie stron, obrazków, dokumentów; • stworzenie oraz edycja własnego profilu i przegl ˛adanieprofili innych członków systemu; • zmiana j˛ezykainterfejsu u˙zytkownika; • dodawanie komentarzy do materiałów wideo, wa˙znychwydarzen.´

3.3.2. Podsumowanie System Plumi jest bardzo rozwini˛etymsystemem zarz ˛adzanitresci´ ˛a. Jest tak mi˛edzyinnymi, dlatego ˙zebazuje na ju˙zistniej ˛acymsystemie Plone. Ciekaw ˛arzecz ˛a wykorzystan ˛aw systemie jest obiektowy model bazy danych. Dzi˛ekiobiektowej bazie danych nie potrzeba rzutowac´ danych z programu do informacji w tabelach i na odwrót jak to ma miejsce w relacyjnym modelu bazy danych. Wa˙zn˛acech ˛a Plumi jest wykorzystanie darmowego odtwarzacza Flash – ﬂowplayera.

3.4. Moodle

System Moodle (ang. Modular Object-Oriented Dynamic Learning Environment) jest bardzo popularnym wirtualnym srodowisku´ edukacyjnym – VLE (ang. Virtual 3.4. Moodle 12

Learning Environment), który pozwala na nauk˛ena odległos´c.´ Nazywany jest rów- nie˙zsystemem zarz ˛adzaniakursami. Dane statystyczne z wrzesnia´ 2011 r. wska- zuj ˛ana to, ˙zez systemu korzysta około 47 milionów u˙zytkownikówz 211 krajów na całym swiecie.´ Moodle jest projektem typu open-source pisanym głównie w PHP. Bazuje na koncepcji programowania modularnego – jest zło˙zonyz wielu modułów, z których ka˙zdyjest odpowiedzialny za okreslony´ zestaw funkcjonalnosci.´ Zapewnia to łatwe i wygodne rozwijanie serwisu.

3.4.1. Podstawowe mo˙zliwosci´ systemu 1. Zapisywanie si˛ena kursy: a) po pozytywnym uwierzytelnieniu si˛edo systemu lub jesli´ jest to mo˙zliwe jako gos´c´ u˙zytkownikmo˙zesamodzielnie zapisac´ si˛ena kurs; b) samodzielnie zapisywanie na kurs poprzez studentów mo˙ze zostac´ wył ˛a- czone; c) zapisanie si˛ena dany kurs mo˙ze wymagac´ klucza dost˛epu,który to umo˙z- liwi; d) nauczyciele z odpowiednimi prawami mog ˛azapisywac´ lub wypisywac´ stu- dentów z kursu; e) w systemie wymagane jest jedno konto – za pomoc ˛ajednego konta mo˙zna zapisywac´ si˛ena wiele kursów. 2. Role w systemie: a) u˙zytkownik mo˙ze posiadac´ ró˙zne role w zale˙znosci´ od kontekstu, np. kursu; b) administrator kontroluje tworzenie kursów oraz tworzy nauczycieli poprzez nadawanie u˙zytkownikomroli nauczyciela w kontekscie´ kursów; c) standardowe role w systemie Moodle: • twórca kursów – mo˙zetworzyc´ kursy, nauczac´ w nich oraz nadawac´ rol˛e nauczyciela innym u˙zytkownikom; • nauczyciel – rola w konkretnym kursie; • nauczyciel nie mog ˛acyedytowac´ kursów – rola mog ˛acabyc´ przydzielona, np. dla adiunktów; • uczen´ – mo˙ze uczestniczyc´ i przegl ˛adac´ aktywnosci´ w kursie, ale nie mo˙zeich tworzyc;´ • gos´c´ – u˙zytkownik,który mo˙zetylko przegl ˛adac´ kursy w systemie. 3. Zarz ˛adzaniekursami: a) typowo nauczyciel posiada pełn ˛akontrol˛enad ustawieniami kursu; b) dla ka˙zdegokursu mo˙zezostac´ ustawiony inny motyw; c) w skład kursu mo˙zewchodzic´ wiele aktywnosci:´ Fora, Quizy, Słowniczki, Zasoby, Ankiety, Zadania, Czaty i Warsztaty; d) ostatnie zmiany w kursie od ostatniego logowania u˙zytkownikamog ˛abyc´ wyswietlane´ na stronie głównej kursu; e) integracja z poczt ˛a– kopie wypowiedzi na forum czy ocena nauczyciela mo˙ze byc´ wysyłana do u˙zytkownika, u˙zytkownik mo˙ze ustawic´ dziennie powiadomienia; f) warunkowe aktywnosci´ – u˙zytkownik mo˙ze byc´ do nich dopuszczony do- piero po spełnieniu pewnych kryteriów. 4. Podstawowe moduły: 3.4. Moodle 13

a) moduł do sporz ˛adzaniazadan´ dla uczniów: • zadania mog ˛abyc´ specyfikowane z terminem oddania oraz maksymaln ˛a mo˙zliw˛aocen ˛a; • uczniowie mog ˛awrzucic´ do systemu swoje rozwi ˛azania,które b˛ed˛aozna- czone dat ˛aich dostarczenia; • oddanie zadania po czasie jest mo˙zliwe, ale długosć´ spó´znienia jest wyra´zniewidoczna dla nauczyciela; • dla szczególnych zadan´ cała klasa mo˙zezostac´ oceniona; • nauczyciel mo˙ze pozwolic´ na ponowne oddanie pracy i zdobycie przez ucznia lepszej oceny. b) moduł czatu: • mo˙zebyc´ udost˛epnionydla ka˙zdegow danym kursie lub ograniczony do członków grup lub ról; • wspiera odnosniki´ URL, emotikony, obrazki itp. c) moduł wyboru: • przypomina w formie ankiet˛ez pojedynczym pytaniem, mo˙zebyc´ stosowany do głosowania lub zdobycia opinii od uczniów; • nauczyciel ma mo˙zliwosć´ podejrzenia kto i na co zagłosował. d) moduł forum • dost˛epnes ˛aró˙zneformy forum: ◦ wiadomosci´ o kursie, ◦ fora ogólnodost˛epne– otwarte dla wszystkich, ◦ forum z jednym w ˛atkiemna u˙zytkownika, ◦ forum typu pytanie/odpowied´z. • wiadomosci´ z forum mog ˛abyc´ wysyłane na poczt˛e; • posty mog ˛amiec´ doł ˛aczonezdj˛eciaautorów; • dyskusje mog ˛abyc´ wyswietlane´ w ró˙znejformie – zagnie˙zd˙zone,płaskie lub w ˛atkowe,poczynaj ˛acod najstarszej czy najnowszej wiadomosci;´ • istnieje mo˙zliwosć´ zapisu na forum; • w ˛atkidyskusji mog ˛abyc´ przemieszczane mi˛edzy forami lub dzielone przez nauczyciela; • mo˙zliwes ˛aoceny postów uczniów, które mog ˛amiec´ wpływ na ich oceny. e) moduł słowniczka: • pozwala uczniom ulepszac´ kurs poprzez umieszczanie w słowniczku własnych pomysłów, które przed ich opublikowaniem mo˙zezweryfiko- wac´ nauczyciel; • słowniczek pozwala uczestnikom kursu tworzyc´ i utrzymywac´ list˛edefi- nicji jak to ma miejsce w zwykłym słowniku; • wpisy w słowniczku mog ˛abyc´ wyszukiwane alfabetycznie, po kategorii, dacie czy danym autorze; • uczestnicy kursu mog ˛akomentowac´ wpisy w słowniczku. f) moduł lekcji: • lekcja stanowi pojedyncz ˛aaktywnosć,´ w której uczniowi prezentowana jest seria stron; • uczen´ decyduje o przebiegu lekcji poprzez dokonywane swoje wybory i udzielone odpowiedzi podczas jej trwania; • wybory i udzielone odpowiedzi na pytania przez ucznia mog ˛abyc´ oce- niane i mo˙zebyc´ mu wystawiona indywidualna ocena; • nauczyciel mo˙zedecydowac´ o ró˙znychustawieniach danej lekcji: 3.4. Moodle 14

◦ ró˙znysposób oceniania lekcji odbytej przez ucznia, ◦ ustawienie ograniczen´ czasowych, minimalnego rezultatu jak równie˙z zliczanie prób uczniów oraz ponawianie lekcji w przypadku niepowo- dzenia. g) moduł Quizu: • quizy oferuj ˛awiele rodzajów pytan,´ rodzajów oceniania i prezentacji oraz s ˛aautomatycznie ocenianie tu˙zpo ukonczeniu;´ • quiz mo˙znaustawic´ tak, aby był dost˛epnyuczniom tylko w wybranym oknie czasowym; • pytania w quizie mog ˛abyc´ losowane w celu redukcji oszukiwania; • nauczyciel mo˙zeustawic,´ aby do quizów mo˙znabyło podchodzic´ wiele razy; • istnieje ponad 10 rodzajów pytan,´ które mog ˛awyst ˛apic´ w quizie; • pytania w quizie s ˛aprzechowywane w kategoriach oraz s ˛acz˛esci´ ˛abazy danych (banku pytan);´ • kategorie pytan´ mog ˛abyc´ tak uło˙zone w bazie danych, ˙ze mog ˛abyc´ one u˙zytetylko w konkretnym quizie, kursie lub w dowolnym quizie na stronie. h) moduł zasobów: • nauczyciel mo˙ze wrzucac´ do kursu ró˙znego rodzaju materiały, które mog ˛apó´zniejzobaczyc´ uczniowie zapisani na kurs; • wrzucane przez nauczyciela materiały – pliki – s ˛adost˛epnedla uczniów w postaci odnosników´ do tych materiałów; • w celu otwarcia niektórych materiałów wrzuconych przez nauczyciela (zwykle plików b˛ed˛acychdokumentami w ró˙znych formatach) trzeba posiadac´ na komputerze odpowiednie oprogramowanie; • pliki MP3, pliki wideo (z popularnych serwisów oraz ze znanymi forma- tami) s ˛aotwierane w odtwarzaczu Flash.

3.4.2. Podsumowanie Moodle jest bardzo popularnym, stale rozwijanym i ciekawym srodowiskiem´ do nauki. System ten oferuje du˙zemo˙zliwosci´ zarówno dla uczniów jak i nauczycieli oraz zapewnia pomoc poprzez udost˛epnieniebardzo dobrej dokumentacji dla u˙zyt- kowników systemu. Nauczyciele mog ˛aw łatwy sposób tworzyc´ własne kursy, które mog ˛adostosowywac´ do swoich potrzeb pod wieloma wzgl˛edami. Uczniowie mog ˛a brac´ aktywny udział w przebiegu kursu oraz stale si˛erozwijac,´ a nawet wpływac´ na to, aby kurs z ich udziałem stawał si˛elepszy. Wa˙znymicechami systemu jest modułowa konstrukcja oraz współpraca z ró˙z- nymi relacyjnymi bazami danych (MySQL, PostgreSQL, MS SQL 2005, Oracle i inne). Jego popularnos´c´ i przychylnos´c´ u˙zytkownikównajlepiej swiadcz´ ˛ao tym, ˙ze przed rozpocz˛eciempisania tego systemu podj˛etobardzo dobre decyzje dotycz ˛ace implementacji. 4. Tworzony system e-learningowy

4.1. Specyﬁkacja i analiza wymagan´

4.1.1. Wizja, zakres oraz cel projektu Tworzony system b˛edziesystemem e-learningowym umo˙zliwiaj˛acymmi˛edzyinnymi publikowanie materiałów multimedialnych (wideo oraz audio). Dost˛epnab˛e- dzie równie˙zmo˙zliwos´c´ publikacji zwykłych informacji tekstowych. Mo˙zliwos´c´ publikacji materiałów udost˛epnianiab˛edziewył ˛aczniezarejestrowa- nym nauczycielom. Dokonanie tego b˛edziemo˙zliwew obr˛ebiekursu, który tworzyc´ mog ˛awył ˛acznienauczyciele. Ponadto materiały multimedialne b˛ed˛arównie˙zmogły byc´ publikowane jako niezwi ˛azanez ˙zadnymkursem – b˛ed˛adost˛epnepublicznie. Uczniowie zarejestrowani w systemie b˛ed˛amogli zapisywac´ si˛ena kursy tworzone przez nauczycieli. System b˛edziesystemem otwartym, to znaczy ka˙zdyb˛edziemógł zarejestrowac´ si˛ejako nauczyciel lub uczen.´ Ka˙zdyzalogowany nauczyciel mo˙zetworzyc´ własne kursy i publikowac´ na nich swoje materiały edukacyjne. Podsumowuj ˛ac,system ten b˛edziesystemem zarz ˛adzaniatresci´ ˛a(CMS) zarówno multimedialn ˛ajak i tekstow ˛a,z naciskiem na publikacj˛emateriałów multimedialnych. Publikacja materiałów b˛edzienajcz˛esciej´ odbywała si˛ew kontekscie´ kursu wczesniej´ utworzonego przez osob˛ezarejestrowan ˛aw systemie jako nauczyciel.

4.1.2. Role i aktorzy w systemie Przewidziane role w systemie ze wzgl˛eduna nauczanie na odległos´c´ to: a) uczen,´ b) nauczyciel. Aktorzy istniej ˛acyw systemie: a) gos´c,´ b) uczen,´ c) nauczyciel, d) administrator.

Rysunek 4.1. Relacje generalizacji mi ˛edzyaktorami w systemie 4.1. Specyﬁkacja i analiza wymaga ´n 16

4.1.3. Wymagania funkcjonalne

a) goscia:´

Id Nazwa Opis Priorytet 1 Przegl ˛adanie Ka˙zdyinternauta odwiedzaj ˛acyserwis po 1 kursów w wybraniu danej kategorii kursu mo˙ze systemie obejrzec´ tytuły i opisy kursów dost˛epnychw wybranej kategorii. Jesli´ u˙zytkownikb˛edzie chciał zapisac´ si˛ena kurs musi on byc´ zalogowany w systemie. Gosć´ ma mo˙zliwosć´ obejrzenia zawartosci´ kursów, które b˛ed˛a oznaczone jako publiczne. 2 Przegl ˛adanie Gosć´ mo˙zeobejrzec´ zawartosć´ kursów, które 1 zawartosci´ posiadaj ˛astatus publicznych. kursu 3 Rejestracja Ka˙zdaosoba odwiedzaj ˛acaserwis, który 1 nowego b˛edziedost˛epnyprzez przegl ˛adark˛e u˙zytkownika internetow ˛amo˙zezarejestrowac´ si˛ejako uczen´ lub nauczyciel u˙zywaj˛acdo tego swojego e-maila jako identyfikatora. Po pomyslnej´ rejestracji na podany e-mail zostanie wysłany odnosnik´ do aktywacji konta w systemie. 4 Wyszukiwanie Gosć´ mo˙zewyszukac´ w systemie materiały, 1 materiałów w które zostały opublikowane jako materiały systemie publiczne. Materiał mo˙zezostac´ opublikowany jako publiczny zarówno w obr˛ebiekursu jak i poza nim. 5 Filtrowanie Gosć´ mo˙zefiltrowac´ materiały poprzez 1 materiałów w stosowne filtry udost˛epnionemu przez systemie system. 6 Ogl ˛adaniei Ka˙zdaosoba, równie˙zbez rejestracji, ma 1 słuchanie dost˛epdo materiałów udost˛epnianych materiałów publicznie poprzez ich wyszukanie, a nast˛epniewybranie do odtworzenia.

b) ucznia - posiada mo˙zliwosci´ goscia´ oraz:

Id Nazwa Opis Priorytet 1 Zarz ˛adzanie Wymagania dotycz ˛acezarz ˛adzaniakontem kontem w systemie e-learningowym. 4.1. Specyﬁkacja i analiza wymaga ´n 17

1.1 Przegl ˛adanie Po klikni˛eciuw odpowiedni odnosnik´ uczen´ 2 konta po uprzednim zalogowaniu si˛edo systemu b˛edziemiał mo˙zliwosć´ przegl ˛adaniadanych zwi ˛azanychze swoim kontem. 1.2 Edycja Uczen´ mo˙zedokonac´ zmiany dowolnych 2 danych konta danych osobowych zwi ˛azanychze swoim u˙zytkownika kontem. 2 Funkcje Wymagania dotycz ˛acedost˛epudo systemu. dost˛epowedo systemu 2.1 Logowanie Zarejestrowany uczen´ w systemie mo˙ze 1 u˙zytkownika zalogowac´ si˛edo systemu podaj ˛ac poprawnie swój e-mail oraz hasło. 2.2 Wylogowanie Uczen´ po zalogowaniu si˛edo systemu mo˙ze 1 u˙zytkownika w dowolnej chwili si˛ez niego wylogowac.´ 3 Zarz ˛adzanie Wymagania zwi ˛azanez mo˙zliwosciami´ kursami dotycz ˛acymikursów w systemie. 3.1 Przegl ˛adanie Po klikni˛eciuw odpowiedni odnosnik´ uczen´ 1 kursów b˛edziemógł obejrzec´ na jakie kursy jest ucznia zapisany. 3.2 Przegl ˛adanie Po klikni˛eciuw kurs, na który jest zapisany 1 zawartosci´ uczen´ mo˙zeobejrzec´ zawartosć´ wybranego kursu kursu. 3.3 Zapisywanie Uczen´ mo˙zesamodzielnie zapisac´ si˛ena 1 si˛ena kurs kurs, który tak ˛amo˙zliwosć´ udost˛epnia. Zapisanie si˛ena kurs mo˙zewymagac´ klucza, który ustala nauczyciel przy tworzeniu kursu i mo˙zego udost˛epnic´ swoim uczniom. 4 Ogl ˛adaniei Uczen´ po zapisaniu si˛ena kurs mo˙ze 1 słuchanie ogl ˛adac´ oraz słuchac´ materiały w nim materiałów w umieszczane, równie˙zte które s ˛aprywatne, obr˛ebiekursu tzn. dost˛epnetylko dla uczniów zapisanych na dany kurs.

c) nauczyciela - ma podstawowe mo˙zliwosci´ takie same jak uczen´ oraz dodatkowo:

Id Nazwa Opis Priorytet 1 Zarz ˛adzanie Wymagania zwi ˛azanez mo˙zliwosciami´ kursami dotycz ˛acymikursów w systemie. 4.1. Specyﬁkacja i analiza wymaga ´n 18

1.1 Tworzenie Nauczyciel mo˙zepodj ˛ac´ akcj˛eutworzenia 1 nowego kursu nowego kursu, na który b˛ed˛amogli si˛e zapisywac´ uczniowie. Po opublikowaniu kursu przez nauczyciela jego kurs zostanie dodany do bazy danych oraz b˛edzie dost˛epnypod konkretn ˛akategori ˛a,któr ˛a wybiera nauczyciel w trakcie tworzenia kursu. 1.1.1 Dodawanie Nauczyciel mo˙zedodawac´ do kursu sekcje w 1 sekcji do celu podziału kursu na cz˛esci.´ Materiały kursu b˛ed˛adodawane do kursu w obr˛ebie wybranej, wczesniej´ utworzonej sekcji. 1.1.2 Dodawanie Podczas tworzenia kursu nauczyciel b˛edzie 1 materiałów mógł po wcisni˛eciuodpowiedniego´ przycisku wideo i audio wskazac´ ch˛ec´ dodania materiału multimedialnego do kursu. Po wybraniu pliku proces wysyłania pliku na serwer oraz jego post˛epb˛edziewidoczny w przegl ˛adarce. 1.1.3 Dodawanie Podczas tworzenia kursu nauczyciel b˛edzie 2 materiałów mógł dodac´ tekst do kursu poprzez wybranie tekstowych odpowiedniego przycisku i wpisanie informacji w odpowiednie pole tekstowe. 1.2 Przegl ˛adanie Nauczyciel oprócz przegl ˛adaniakursów, na 1 prowadzo- które jest zapisany mo˙zerównie˙zobejrzec´ nych list˛ekursów, które w danej chwili prowadzi. kursów 1.3 Edycja U˙zytkownikb˛ed˛acynauczycielem mo˙ze 1 danych kursu zmienic´ dane o kursie. 1.4 Usuwanie Nauczyciel mo˙zeusun ˛ac´ dowolny kurs, 1 prowadzo- który jest przez niego prowadzony. nych kursów 1.5 Usuwanie Nauczyciel mo˙zeusuwac´ sekcje wraz ze 1 sekcji z kursu wszystkimi danymi, które zostały w niej uprzednio umieszczone. 1.6 Usuwanie Nauczyciel mo˙zedokonac´ usuni˛ecia 1 materiałów materiałów wideo i audio, które wczesniej´ multimedial- dodał do danej sekcji. nych z kursu 1.7 Usuwanie Nauczyciel mo˙zedokonac´ usuni˛ecia 1 materiałów dowolnego materiału tekstowego z wybranej tekstowych z sekcji. kursu 4.1. Specyﬁkacja i analiza wymaga ´n 19

2 Zarz ˛adzanie Wymagania zwi ˛azanez mo˙zliwosciami´ materiałami dotycz ˛acymimateriałów wideo i audio w multimedial- systemie. nymi 2.1 Przegl ˛adanie System umo˙zliwianauczycielowi 2 opublikowa- przegl ˛adaniewszystkich jego materiałów, nych które dodał do systemu. materiałów 2.2 Dodawanie Nauczyciel posiada mo˙zliwosć´ dodawania 2 materiałów materiałów do systemu, które nie s ˛a wideo i audio powi ˛azanez ˙zadnymkursem. W tym przypadku automatycznie s ˛aone publicznie dost˛epne. 2.3 Wyswietlenie´ Nauczyciel mo˙zewyswietli´ c´ materiały w 2 materiałów w sposób umo˙zliwiaj˛acypodj˛eciepewnych trybie akcji dla ka˙zdegomateriału. zarz ˛adzania 2.4 Ogl ˛adaniei Nauczyciel mo˙zeobejrzec´ dowolny materiał, 2 słuchanie który został przez niego dodany do systemu. materiałów 2.5 Edycja Po dodaniu materiału do systemu dane 2 danych dotycz ˛acemateriału mog ˛azostac´ zmienione. zwi ˛azanychz materiałem 2.6 Usuni˛ecie System pozwala usun ˛ac´ dowolny materiał 2 materiału z nauczyciela. systemu 2.7 Wyszukiwanie Nauczyciel mo˙zedokonac´ wyszukania oraz 2 i filtrowanie filtracji posiadanych materiałów. materiałów 3 Zarz ˛adzanie Wymagania zwi ˛azanez mo˙zliwosciami´ zapisami dotycz ˛acymizapisów na kursy, które posiada nauczyciel. 3.1 Zapisywanie Nauczyciel mo˙zedokonywac´ zapisów 1 uczniów na uczniów na kursy, które posiadaj ˛aokreslony´ kurs rodzaj zapisów. 3.2 Wypisywanie Nauczyciel mo˙zedokonywac´ wypisów 1 uczniów z uczniów z kursów, które posiadaj ˛a kursu okreslony´ rodzaj zapisów. 4.1. Specyfikacja i analiza wymaga ń 20

d) administratora:

Id Nazwa Opis Priorytet 1 Zarz ˛adzanie Wymagania okreslaj´ ˛acemo˙zliwosci´ kontami zarz ˛adzaniakontami u˙zytkowników u˙zytkowników udost˛epnionedla administratora systemu. 1.1 Przegl ˛adanie Administrator mo˙zeprzejrzec´ wszystkich 1 u˙zytkowników u˙zytkownikóww systemie. 1.2 Dodawanie Administrator mo˙zedodac´ pełnoprawnego 1 nowych u˙zytkownikado systemu. u˙zytkowników 1.3 Usuwanie Administrator mo˙zedokonac´ usuni˛ecia 1 kont konta dowolnego u˙zytkownikaw systemie. u˙zytkowników 1.4 Edycja kont Administrator mo˙zeedytowac´ dane zwi ˛azane 2 u˙zytkowników z kontami u˙zytkownikóww dowolnym zakresie. 1.5 Wyszukiwanie Nauczyciel mo˙zedokonac´ wyszukania oraz 2 i filtrowanie filtracji kont u˙zytkownikóww systemie. u˙zytkowników 2 Zarz ˛adzanie Wymagania dotycz ˛acemo˙zliwosci´ kursami administratora zwi ˛azanychz kursami w systemie. 2.1 Przegl ˛adanie Administrator mo˙zeprzegl ˛adac´ wszystkie 2 kursów kursy w systemie. 2.2 Usuwanie Administrator mo˙zeusun ˛ac´ kurs z systemu 2 kursów wraz ze wszystkimi danymi, które s ˛a zwi ˛azanez tym kursem. 2.3 Edycja Administrator mo˙zezmienic´ zawartosć´ 3 kursów dowolnego kursu podobnie jak to czyni istniej ˛acychw nauczyciel z prowadzonym kursem. systemie 2.4 Wyszukiwanie Nauczyciel mo˙zedokonac´ wyszukania oraz 2 i filtrowanie filtracji kursów w systemie. kursów 3 Zarz ˛adzanie Wymagania okreslaj´ ˛acejakich czynnosci´ materiałami mo˙zedokonac´ administrator z dost˛epnymiw wideo i audio systemie materiałami wideo i audio. 3.1 Przegl ˛adanie Administrator mo˙zeprzegl ˛adac´ wszystkie 1 materiałów w materiały w systemie. systemie 3.2 Usuwanie Administrator mo˙zeusun ˛ac´ dowolny 1 materiałów z wskazany materiał z systemu. systemu 4.1. Specyfikacja i analiza wymaga ń 21

3.3 Zmiana Administrator mo˙zezmienic´ okreslone´ dane 2 metadanych dotycz ˛acewybranego materiału. zwi ˛azanychz materiałem 3.4 Wyszukiwanie Administrator mo˙zedokonac´ wyszukania 2 i filtrowanie oraz filtracji materiałów w systemie. materiałów 3 Zarz ˛adzanie Wymagania okreslaj´ ˛acejakich czynnosci´ materiałami mo˙zedokonac´ administrator z dost˛epnymiw wideo i audio systemie materiałami wideo i audio. 3.1 Przegl ˛adanie Administrator mo˙zeprzegl ˛adac´ wszystkie 1 materiałów w materiały w systemie. systemie 3.2 Usuwanie Administrator mo˙zeusun ˛ac´ dowolny 1 materiałów z wskazany materiał z systemu. systemu 3.3 Zmiana Administrator mo˙zezmienic´ okreslone´ dane 2 metadanych dotycz ˛acewybranego materiału. zwi ˛azanychz materiałem 3.4 Wyszukiwanie Administrator mo˙zedokonac´ wyszukania 2 i filtrowanie oraz filtracji materiałów w systemie. materiałów 4 Statystyki Wymagania okreslaj´ ˛acezakres sledzenia´ systemowe systemu oraz statystyki, do których ma dost˛epadministrator. 4.1 Przegl ˛adanie Administrator mo˙zeprzegl ˛adac´ ilosć´ ró˙znych 1 statystyk bytów w systemie (u˙zytkowników,kursów, ilosciowych´ materiałów). 4.2 Przegl ˛adanie Administrator mo˙zeprzejrzec´ logi dost˛epu 1 statystyk do systemu (logowanie i wylogowanie). dost˛epudo systemu 4.3 Przegl ˛adanie Administrator mo˙zezobaczyc´ ilosć´ zasobów 1 zasobów wykorzystywanych przez u˙zytkowników. systemu 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 22

4.1.4. Wymagania niefunkcjonalne

Id Nazwa Opis Priorytet 1 Bezpieczenstwo´ Tylko administrator systemu mo˙zedokonac´ 1 usuni˛eciakonta innego u˙zytkownika,czyli nauczyciela lub ucznia. Inni u˙zytkownicy systemu maj ˛aprawo wył ˛aczniedo edycji własnego konta. 2 Wymagania System b˛edzienapisany w j˛ezykuPHP oraz 1 systemowe b˛edzierealizowany w architekturze aplikacji internetowej. Aplikacja b˛edzienapisana w oparciu o framework Yii. Serwerem WWW b˛edzieApache działaj ˛acyna systemie linuksowym. Baz ˛adanych b˛edziejedna z darmowych, relacyjnych silników bazodanowych dost˛epnychna rynku. 3 Przyjazny System umo˙zliwiaw prosty sposób 1 interfejs przegl ˛adaniedost˛epnychkursów, graﬁczny przegl ˛adaniewłasnego konta oraz przede u˙zytkownika wszystkim kursów, na który jest zapisany dany u˙zytkownik.

4.2. Diagramy oraz scenariusze realizacji przypadków u˙zycia

a) goscia:´

PUG1. Przegl ˛adaniekursów w systemie (wł ˛aczaneprzez PUU7) Opis: Przegl ˛adaniekursów dost˛epnychw systemie w danej chwili. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ dost˛epnekategorie kursów w systemie. 3. U˙zytkownikwybiera kategori˛e,w obr˛ebiektórej chce przegl ˛adac´ kursy. 4. System wyswietla´ pierwsz ˛astron˛e rezultatów z kursami w wybranej kategorii. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛esi˛e25 kursów.

PUG2. Przegl ˛adaniezawartosci´ kursu (rozszerza PUG1 po ostatnim kroku) Opis: Przegl ˛adaniezawartosci´ kursu, który posiada status publiczny. Scenariusz główny: 1. U˙zytkownikwciska odpowiedni odnosnik´ obok kursu, który chce obejrzec.´ 2. System wyswietla´ zawartos´c´ wybranego kursu. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 23

Rysunek 4.2. Diagram przypadków u ˙zyciadla go´scia

PUG3. Rejestracja nowego u˙zytkownika Opis: Rejestracja w systemie nowego u˙zytkownikao okreslonej´ roli. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ formularz rejestracyjny. 3. U˙zytkownik poprawnie wypełnia formularz i zatwierdza wprowadzone dane (RB1). 4. System potwierdza otrzymanie danych i wysyła e-maila aktywacyjnego na podan ˛askrzynk˛epocztow ˛a. 5. Nowy u˙zytkownikaktywuje swoje konto (PUG4). Scenariusz alternatywny 1 – u ˙zytkownikpodał e-mail istniej ˛acyw systemie: 1–2. Jak w scenariuszu głównym. 3. U˙zytkownik wypełnia i zatwierdza formularz podaj ˛acidentyﬁkator - e-mail istniej ˛acyju˙zw systemie. 4. System powiadamia u˙zytkownikao zaj˛etyme-mailu. 5. Powrót do kroku 2 scenariusza głównego.

PUG4. Aktywacja konta w systemie (wł ˛aczaneprzez PUG3) Opis: Aktywacja konta w systemie po tym jak nowy u˙zytkownik pomyslnie´ uzupełnił i zatwierdził formularz rejestracyjny. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 24

Scenariusz główny: 1. U˙zytkownik otwiera odnosnik´ aktywacyjny wysłany na jego skrzynk˛e pocztow ˛a. 2. System tworzy nowego, pełnoprawnego u˙zytkownikaumo˙zliwiaj˛acmu dost˛epdo systemu poprzez funkcje dost˛epowe(logowanie i wylogowanie).

PUG5. Wyszukiwanie materiałów wideo i audio w systemie Opis: Wyszukiwanie w systemie materiałów multimedialnych oznaczonych jako publiczne. Scenariusz główny: 1. U˙zytkownikwpisuje tekst do wyszukania w głównym polu wyszukiwarki i zatwierdza wprowadzone dane. 2. System wyswietla´ pierwsz ˛astron˛e rezultatów z materiałami wideo i audio, które spełniaj ˛akryteria wyszukiwania (RB2). Kolejne strony s ˛a dost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛e si˛e10 materiałów.

PUG6. Filtrowanie materiałów wideo i audio w systemie (rozszerza PUG5 po ostatnim kroku) Opis: U˙zytkownik mo˙ze dokonac´ zaw˛e˙zenia wyników wyszukiwania poprzez zastosowanie filtrów udost˛epnionychprzez system. Scenariusz główny: 1. U˙zytkownikwybiera jeden z dost˛epnychfiltrów materiałów. 2. System wyswietla´ pierwsz ˛astron˛erezultatów z materiałami wideo i audio, które spełniaj ˛akryteria wyszukiwania i filtrowania wybrane przez u˙zytkownika(RB2 i RB3). Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛esi˛e10 materiałów.

PUG7. Ogl ˛adaniei słuchanie materiałów (rozszerza PUG5 po ostatnim kroku lub PUG2 po ostatnim kroku) Opis: Ogl ˛adaniei słuchanie materiałów multimedialnych posiadaj ˛acychsta- tus publicznych. Scenariusz główny: 1. Wyszukanie materiału multimedialnego (PUG5). 2. Sposród´ wyswietlonych´ rezultatów u˙zytkownikwybiera materiał do odtworzenia. 3. System wyswietla´ dane zwi ˛azanez wybranym materiałem oraz zaczyna odtwarzac´ materiał. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 25

b) ucznia: PUU1. Przegl ˛adaniekonta Opis: U˙zytkownikzalogowany w systemie mo˙zeprzejrzec´ dane zwi ˛azanez jego kontem w systemie. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ dane zwi ˛azanez u˙zytkownikiem w postaci dwóch formularzy (RB4).

Rysunek 4.3. Diagram przypadków u ˙zyciadla ucznia 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 26

PUU2. Edycja danych konta u˙zytkownika (rozszerza PUU1 po ostatnim kroku) Opis: Zalogowany u˙zytkownik mo˙ze zmienic´ swoje dane, które pierwotnie wprowadził w formularzu rejestracyjnym podczas procesu rejestracji. Scenariusz główny: 1. U˙zytkownikzmienia swoje dane i zatwierdza formularz. 2. System potwierdza pomysln´ ˛azmian˛edanych u˙zytkownika. Scenariusz alternatywny 1 – u ˙zytkownikzmienia swój e-mail: 1. U˙zytkownikzmienia i zatwierdza formularz podaj ˛acunikalny e-mail. 2. System wylogowuje u˙zytkownikaz systemu i wyswietla´ formularz logowania. Scenariusz alternatywny 2 – u ˙zytkownikpodał e-mail istniej ˛acyw systemie: 1. U˙zytkownik zmienia i zatwierdza formularz podaj ˛acidentyﬁkator - e-mail istniej ˛acyju˙zw systemie. 2. System powiadamia u˙zytkownikao zaj˛etyme-mailu.

PUU3. Logowanie u˙zytkownika Opis: Logowanie u˙zytkownikado systemu daj ˛acemu dost˛epdo okreslonych´ funkcji w zale˙znosci´ od posiadanej roli w systemie. Scenariusz główny: 1. U˙zytkowniknaciska odpowiedni odnosnik´ słu˙z˛acylogowaniu. 2. System wyswietla´ formularz logowania. 3. U˙zytkownikwprowadza identyﬁkator (e-mail) oraz hasło. 4. U˙zytkownikzatwierdza wprowadzone dane. 5. System przeprowadza logowanie u˙zytkownika. 6. System wyswietla´ stron˛egłówn ˛aaplikacji oraz menu bogatsze w opcje w zale˙znosci´ od roli pełnionej przez zalogowanego u˙zytkownika. Scenariusz alternatywny 1 – u ˙zytkownikwprowadza nieistniej ˛acye-mail: 1–2. Jak w scenariuszu głównym. 3. U˙zytkownikwprowadza hasło oraz e-mail nieistniej ˛acyw systemie. 4. U˙zytkownikzatwierdza formularz logowania. 5. System wyswietla´ informacj˛eo nieistniej ˛acymidentyﬁkatorze. 6. Powrót do kroku 2 scenariusza głównego. Scenariusz alternatywny 2 – u ˙zytkownikwprowadza złe hasło: 1–2. Jak w scenariuszu głównym. 3. U˙zytkownikwprowadza swój e-mail oraz nieprawidłowe hasło. 4. U˙zytkownikzatwierdza formularz logowania. 5. System wyswietla´ informacj˛eo nieprawidłowym hasle.´ 6. Powrót do kroku 2 scenariusza głównego.

PUU4. Wylogowanie u˙zytkownika Opis: Wylogowanie u˙zytkownikaz systemu konczy´ sesj˛eu˙zytkownikaw systemie. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 27

Scenariusz główny: 1. U˙zytkowniknaciska odpowiedni odnosnik´ słu˙z˛acywylogowaniu. 2. System przeprowadza wylogowanie u˙zytkownika. 3. System wyswietla´ stron˛egłówn ˛aaplikacji oraz menu główne dost˛epne dla niezalogowanego u˙zytkownika(goscia).´

PUU5. Przegl ˛adaniekursów ucznia (wł ˛aczaneprzez PUU6) Opis: Funkcja systemu umo˙zliwiaj˛acauczniowi przegl ˛adaniekursów, na któ- rej jest w danej chwili zapisany. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ opcje dost˛epnedla ucznia. 3. U˙zytkownik wybiera przycisk do wyswietlenia´ kursów, na które jest zapisany. 4. System wyswietla´ list˛ekursów, na które jest zapisany dany u˙zytkownik (RB5).

PUU6. Przegl ˛adaniezawartosci´ kursu (wł ˛aczaneprzez PUU8) Opis: Uczen´ ma dost˛epdo kursów, na które jest zapisany i mo˙zeje swobodnie przegl ˛adac.´ Scenariusz główny: 1. Wyswietlenie´ kursów, na które jest zapisany uczen´ (PUU5). 2. U˙zytkownik wybiera do wyswietlenia´ jeden sposród´ kursów, na które jest zapisany. 3. System wyswietla´ zawartos´c´ kursu.

PUU7. Zapisywanie si ˛ena kurs Opis: Uczen´ mo˙zedokonac´ samodzielnego zapisu na kurs, który to umo˙zliwia. Scenariusz główny: 1. Przegl ˛adaniekursów w systemie (PUG1). 2. U˙zytkownikwciska odpowiedni odnosnik´ obok kursu, na który chce si˛e zapisac.´ 3. System zapisuje u˙zytkownikana kurs. 4. System wyswietla´ informacj˛eo pozytywnym zapisaniu si˛ena kurs. Scenariusz alternatywny 1 – u ˙zytkownikjest ju ˙zzapisany na kurs: 1–2. Jak w scenariuszu głównym. 3. System wyswietla´ informacj˛eo tym, i˙zu˙zytkownikjest ju˙zzapisany na wybrany kurs. Scenariusz alternatywny 2 – brak miejsc wolnych do zapisu: 1–2. Jak w scenariuszu głównym. 3. System wyswietla´ informacj˛e o tym, i˙z brak jest wolnych miejsc na zapisanie si˛ena kurs. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 28

Scenariusz alternatywny 3 – wymagany kod dost ˛epudo zapisu, u ˙zytkownik podał prawidłowy kod dost ˛epu: 1–2. Jak w scenariuszu głównym. 3. System wyswietla´ okno do wprowadzenia kodu dost˛epu. 4. U˙zytkownikwprowadza i zatwierdza prawidłowy kod dost˛epu. 5. System zapisuje u˙zytkownikana kurs. 6. System wyswietla´ informacj˛eo pozytywnym zapisaniu si˛ena kurs. Scenariusz alternatywny 4 – wymagany kod dost ˛epudo zapisu, u ˙zytkownik podał nieprawidłowy kod dost ˛epu: 1–2. Jak w scenariuszu głównym. 3. System wyswietla´ okno do wprowadzenia kodu dost˛epu. 4. U˙zytkownikwprowadza i zatwierdza bł˛ednykod dost˛epu. 5. System wyswietla´ informacj˛eo podaniu nieprawidłowego kodu dost˛epu.

PUU8. Ogl ˛adaniei słuchanie materiałów w kursie Opis: Uczen´ mo˙ze ogl ˛adac´ i słuchac´ materiały umieszczone w kursach, na które jest zapisany. Scenariusz główny: 1. Wyswietlenie´ zawartosci´ kursu (PUU6). 2. U˙zytkownikwybiera materiał multimedialny, który chce obejrzec.´ 3. System wyswietla´ dane zwi ˛azanez wybranym materiałem oraz zaczyna odtwarzac´ materiał.

c) nauczyciela:

PUN1. Tworzenie nowego kursu Opis: Tworzenie nowego kursu w systemie. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ opcje dost˛epnedla nauczyciela. 3. U˙zytkownikwciska przycisk inicjuj ˛acydodawanie kursu do systemu. 4. System wyswietla´ formularz do tworzenia kursu. 5. U˙zytkownikwypełnia dane dotycz ˛acekursu i zatwierdza formularz. 6. System dodaje nowy kurs do systemu. 7. System wyswietla´ panel do edycji kursu udost˛epnianydla nauczycieli (PUN2).

PUN2. Wyswietlenie´ kursu z panelem edycyjnym (rozszerza PUN7 po ostatnim kroku oraz wł ˛aczaneprzez PUN1) Opis: Wyswietlenie´ kursu wraz z panelem do jego edycji, który jest udost˛ep- niony u˙zytkownikomposiadaj ˛acymw systemie rol˛enauczyciela. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 29

Rysunek 4.4. Diagram przypadków u ˙zyciadla nauczyciela - cz ˛e´s´c1

Scenariusz główny: 1. System wyswietla´ zawartos´c´ kursu wraz z interfejsem do jego edycji oraz danych powi ˛azanychz edytowanym kursem (RB6).

PUN3. Dodawanie sekcji do kursu (rozszerza PUN2 po ostatnim kroku) Opis: Dodawanie sekcji do kursu, który jest edytowany przez nauczyciela. Scenariusz główny: 1. U˙zytkownik wybiera zakładk˛ez formularzem do dodawania sekcji do kursu. 2. System prezentuje formularz do dodawania sekcji. 3. U˙zytkownikwpisuje tytuł nowej sekcji i zatwierdza formularz. 4. System dodaje now ˛asekcj˛edo kursu. 5. System wyswietla´ informacj˛eo pomyslnym´ dodaniu sekcji do kursu. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 30

PUN4. Dodawanie materiałów wideo i audio (rozszerza PUN2 po ostatnim kroku) Opis: Dodawanie materiałów multimedialnych do edytowanego kursu. Scenariusz główny: 1. U˙zytkownikwybiera zakładk˛ez formularzem do dodawania materiałów multimedialnych do kursu. 2. System prezentuje interfejs do dodawania multimediów. 3. U˙zytkownikwybiera pliki do wysłania z lokalnego systemu plików. 4. U˙zytkownikzatwierdza ch˛ec´ wysłania wybranych plików. 5. System odbiera pliki i wyswietla´ informacj˛eo pomyslnym´ odbiorze pli- ków. 6. System dokonuje przetwarzania plików. 7. System wyswietla´ informacje o pomyslnym´ przetworzeniu wysłanych plików. Scenariusz alternatywny 1 – nieprawidłowy plik (bez strumieni audio i wideo): 1–4. Jak w scenariuszu głównym. 5. System odbiera pliki i wyswietla´ informacj˛eo nieprawidłowych plikach. Scenariusz alternatywny 2 – nieobsługiwany plik: 1–4. Jak w scenariuszu głównym. 5. System odbiera pliki i wyswietla´ informacj˛eo nieobsługiwanych plikach.

PUN5. Dodawanie materiałów tekstowych (rozszerza PUN2 po ostatnim kroku) Opis: Dodawanie materiałów zawieraj ˛acychzwykły tekst. Scenariusz główny: 1. U˙zytkownikwybiera zakładk˛ez formularzem do dodawania materiałów tekstowych do kursu. 2. System wyswietla´ formularz do dodawania materiałów tekstowych. 3. U˙zytkownikuzupełnia dane materiału tekstowego. 4. U˙zytkownikzatwierdza formularz z wprowadzonymi danymi. 5. System dodaje nowy materiał tekstowy do wybranej sekcji. 6. System wyswietla´ informacj˛eo pomyslnym´ dodaniu materiału tekstowego.

PUN6. Edycja danych kursu (rozszerza PUN2 po ostatnim kroku oraz PUA10 po ostatnim kroku) Opis: Edycja danych o kursie pierwotnie wprowadzanych przy tworzeniu kursu. Scenariusz główny: 1. U˙zytkownikwybiera zakładk˛ez formularzem do edycji danych kursu. 2. System wyswietla´ formularz do edycji danych kursu. 3. U˙zytkownikzmienia dane dotycz ˛acekursu. 4. U˙zytkownikzatwierdza formularz. 5. System wyswietla´ informacje o pomyslnej´ zmianie danych kursu. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 31

PUN7. Przegl ˛adanieprowadzonych kursów Opis: Przegl ˛adaniekursów utworzonych przez nauczyciela. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ opcje dost˛epnedla nauczyciela. 3. U˙zytkownikwciska przycisk do wyswietlenia´ prowadzonych kursów. 4. System wyswietla´ kursy nauczyciela.

PUN8. Usuni ˛eciekursu (rozszerza PUN7 po ostatnim kroku) Opis: Usuni˛eciekursu prowadzonego przez nauczyciela. Scenariusz główny: 1. U˙zytkownik wciska przycisk do usuni˛eciakursu znajduj ˛acysi˛eobok danego kursu na liscie´ kursów. 2. System usuwa kurs z systemu.

PUN9. Usuni ˛eciesekcji z kursu (rozszerza PUN7 po ostatnim kroku oraz PUA10 po ostatnim kroku) Opis: Usuni˛eciesekcji wraz ze wszystkimi danymi, które si˛ew niej znajduj ˛a. Scenariusz główny: 1. U˙zytkownikwybiera i naciska przycisk słu˙z˛acydo usuwania sekcji. 2. System usuwa desygnowan ˛asekcj˛ez kursu.

PUN10. Usuni ˛eciemateriału wideo lub audio z kursu (rozszerza PUN7 po ostatnim kroku oraz PUA10 po ostatnim kroku) Opis: Usuni˛eciewybranego materiału multimedialnego umieszczonego w konkretnej sekcji. Scenariusz główny: 1. U˙zytkownikwybiera i naciska przycisk słu˙z˛acydo usuwania materiału. 2. System usuwa wybrany materiał z kursu.

PUN11. Usuni ˛eciemateriału tekstowego z kursu (rozszerza PUN7 po ostatnim kroku oraz PUA10 po ostatnim kroku) Opis: Usuni˛eciemateriałów zawieraj ˛acychzwykły tekst w kursie. Scenariusz główny: 1. U˙zytkownikwybiera i naciska przycisk słu˙z˛acydo usuwania materiału tekstowego. 2. System usuwa wybrany materiał tekstowy z kursu.

PUN12. Przegl ˛adanieopublikowanych materiałów Opis: Przegl ˛adaniemateriałów, które zostały dodane przez zalogowanego nauczyciela. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 32

Rysunek 4.5. Diagram przypadków u ˙zyciadla nauczyciela - cz ˛e´s´c2

Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez menu głównego aplikacji. 2. System wyswietla´ materiały nauczyciela z podziałem na strony. Kolejne strony s ˛adost˛epne przez numerowane odnosniki.´ Na ka˙zdej stronie znajduj˛esi˛e25 materiałów.

PUN13. Dodawanie materiałów wideo i audio (rozszerza PUN12 po ostatnim kroku) Opis: Dodawanie materiałów multimedialnych niezwi ˛azanychz ˙zadnymkursem w systemie. Scenariusz główny: 1. U˙zytkownikwybiera opcj˛edodawania materiałów do systemu. 2. System prezentuje formularz do dodawania multimediów. 3. U˙zytkownikwybiera pliki do wysłania z lokalnego systemu plików. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 33

4. U˙zytkownikzatwierdza ch˛ec´ wysłania wybranych plików. 5. System odbiera pliki i wyswietla´ informacj˛eo pomyslnym´ odbiorze pli- ków. 6. System dokonuje przetwarzania plików. 7. System wyswietla´ informacje o pomyslnym´ przetworzeniu wysłanych plików. Scenariusz alternatywny 1 – nieprawidłowy plik (bez strumieni audio i wideo): 1–4. Jak w scenariuszu głównym. 5. System odbiera pliki i wyswietla´ informacj˛eo nieprawidłowych plikach. Scenariusz alternatywny 2 – nieobsługiwany plik: 1–4. Jak w scenariuszu głównym. 5. System odbiera pliki i wyswietla´ informacj˛eo nieobsługiwanych plikach.

PUN14. Wyswietlenie´ materiałów w trybie zarz ˛adzania (rozszerza PUN12 po ostatnim kroku) Opis: Wyswietlenie´ materiałów wraz z interfejsem do zmiany ka˙zdegomate- riału z osobna. Scenariusz główny: 1. U˙zytkownikwybiera opcj˛edo zarz ˛adzaniamateriałami. 2. System wyswietla´ materiały nauczyciela z podziałem na strony. Kolejne strony s ˛adost˛epne przez numerowane odnosniki.´ Na ka˙zdej stronie znajduj˛esi˛e25 materiałów. Obok ka˙zdegomateriału znajduj ˛asi˛eopcje do jego zmiany.

PUN15. Ogl ˛adaniei słuchanie materiałów (rozszerza PUN14 po ostatnim kroku) Opis: Ogl ˛adaniei słuchanie materiałów posiadanych przez nauczyciela. Scenariusz główny: 1. Sposród´ listy materiałów u˙zytkownikwybiera materiał, który chce obejrzec.´ 2. System wyswietla´ dane zwi ˛azanez wybranym materiałem oraz zaczyna odtwarzac´ materiał.

PUN16. Edycja danych zwi ˛azanychz materiałem (rozszerza PUN14 po ostatnim kroku) Opis: Edycja danych dotycz ˛acychwybranego materiału. Scenariusz główny: 1. Sposród´ listy materiałów u˙zytkownik wybiera materiał, którego dane chce zmienic.´ 2. System wyswietla´ formularz do zmiany materiału. 3. U˙zytkownikzmienia dane materiału i zatwierdza formularz. 4. System wyswietla´ informacje o pomyslnej´ zmianie danych. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 34

PUN17. Usuni ˛ecie materiału z systemu (rozszerza PUN14 po ostatnim kroku) Opis: Usuni˛eciewybranego materiału z systemu. Scenariusz główny: 1. Sposród´ listy materiałów u˙zytkownikwybiera materiał, który chce usu- n ˛ac.´ 2. System wyswietla´ okno do potwierdzenia z pytaniem czy u˙zytkownikna pewno chce usun ˛ac´ wybrany materiał. 3. U˙zytkownikpotwierdza ch˛ec´ usuni˛eciamateriału. 4. System usuwa materiał z systemu. 5. System wyswietla´ now ˛alist˛emateriałów. Scenariusz alternatywny 1 – u ˙zytkownikanuluje usuwanie: 1–2. Jak w scenariuszu głównym. 3. U˙zytkownikanuluje usuwanie materiału.

PUN18. Wyszukiwanie i filtrowanie materiałów (rozszerza PUN14 po ostatnim kroku) Opis: Wyszukiwanie oraz filtrowanie materiałów, które posiada nauczyciel. Scenariusz główny: 1. U˙zytkownik wprowadza szukan ˛awartosć´ atrybutu materiału lub wybiera jeden z filtrów (RB7). 2. System wyswietla´ now ˛alist˛emateriałów.

PUN19. Wyswietlenie´ kursów umo˙zliwiaj˛acychzapisy (wł ˛aczaneprzez PUN20 i PU21) Opis: Wyswietlenie´ kursów, których rodzaj zapisów umo˙zliwiadokonywanie zapisów przez nauczyciela. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ opcje dost˛epnedla nauczyciela. 3. U˙zytkownikwciska przycisk do dokonywania zapisów. 4. System wyswietla´ kursy nauczyciela (RB8) oraz interfejs do zapisywania i wypisywania uczniów.

PUN20. Zapisanie ucznia na kurs Opis: Zapisanie ucznia na wybrany kurs prowadzony przez nauczyciela. Scenariusz główny: 1. U˙zytkownikwybiera odpowiedni ˛azakładk˛ez głównego menu aplikacji. 2. System wyswietla´ opcje dost˛epnedla nauczyciela. 3. U˙zytkownikwciska przycisk inicjuj ˛acyzapisy. 4. U˙zytkownikwybiera kurs, na który chce dokonac´ zapisu. 5. U˙zytkownik wprowadza identyﬁkator ucznia, którego chce zapisac´ na dany kurs. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 35

6. U˙zytkownikzatwierdza formularz do zapisu. 7. System zapisuje ucznia na kurs. 8. System wyswietla´ informacje o pomyslnym´ zapisie. Scenariusz alternatywny 1 – podany e-mail nie istnieje w systemie: 1–3. Jak w scenariuszu głównym. 4. System wyswietla´ informacje o nieistniej ˛acymidentyﬁkatorze. Scenariusz alternatywny 2 – u ˙zytkownikjest ju ˙zzapisany na kurs: 1–3. Jak w scenariuszu głównym. 4. System wyswietla´ informacje o tym, i˙zu˙zytkownikjest ju˙zzapisany na wybrany kurs. Scenariusz alternatywny 3 – brak wolnych miejsc: 1–3. Jak w scenariuszu głównym. 4. System wyswietla´ informacje o tym, i˙z brak jest wolnego miejsca na dokonanie zapisu na wybrany kurs.

PUN21. Wypisanie ucznia z kursu Opis: Wypisanie ucznia z wybranego kursu prowadzonego przez nauczyciela. Scenariusz główny: 1. U˙zytkownikwybiera kurs, z którego chce dokonac´ wypisu. 2. U˙zytkownik wprowadza identyﬁkator ucznia, którego chce wypisac´ z kursu. 3. U˙zytkownikzatwierdza formularz do wypisu. 4. System wypisuje ucznia z kursu. 5. System wyswietla´ informacje o pomyslnym´ wypisie. Scenariusz alternatywny 1 – podany e-mail nie istnieje w systemie: 1–3. Jak w scenariuszu głównym. 4. System wyswietla´ informacje o nieistniej ˛acymidentyﬁkatorze. Scenariusz alternatywny 2 – u ˙zytkowniknie jest zapisany na kurs: 1–3. Jak w scenariuszu głównym. 4. System wyswietla´ informacje o tym, i˙zu˙zytkowniknie jest zapisany na wybrany kurs.

d) administratora:

PUA1. Przegl ˛adanieu˙zytkowników Opis: Przegl ˛adaniekont u˙zytkownikóww systemie. Scenariusz główny: 1. W celu otwarcia panelu administracyjnego u˙zytkownik wybiera odpowiedni ˛azakładk˛ez menu głównego aplikacji. 2. System wyswietla´ panel administracyjny. 3. U˙zytkownik wciska odnosnik´ słu˙z˛acydo administrowania u˙zytkownikami. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 36

Rysunek 4.6. Diagram przypadków u ˙zyciadla administratora - cz ˛e´s´c1

4. System wyswietla´ pierwsz ˛astron˛ez u˙zytkownikamiw systemie. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛esi˛e25 u˙zytkowników.

PUA2. Dodawanie u˙zytkownikówdo systemu (rozszerza PUA1 po ostatnim kroku) Opis: Dodawanie pełnoprawnych u˙zytkowników do systemu (bez potrzeby aktywacji konta poprzez link aktywacyjny). Scenariusz główny: 1. U˙zytkownikwybiera opcj˛edodawania u˙zytkownikado systemu. 2. System wyswietla´ formularz do dodawania u˙zytkowników. 3. U˙zytkownikwypełnia i zatwierdza formularz. 4. System dodaje u˙zytkownikado systemu. 5. System wyswietla´ informacj˛eo pomyslnym´ dodaniu u˙zytkownika. Scenariusz alternatywny 1 – e-mail nie jest unikalny: 1–3. Jak w scenariuszu głównym. 4. System wyswietla´ informacj˛e,i˙zpodany e-mail jest ju˙zu˙zywany. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 37

PUA3. Wyswietlenie´ u˙zytkownikóww trybie zarz ˛adzania (wł ˛aczaneprzez PUA4, PUA5 i PUA6, rozszerza PUA1 po ostatnim kroku) Opis: Wyswietlenie´ u˙zytkownikówwraz z opcjami zmiany ka˙zdegou˙zytkownika. Scenariusz główny: 1. U˙zytkownikwybiera opcj˛ezarz ˛adzaniau˙zytkownikamiw systemie. 2. System wyswietla´ pierwsz ˛astron˛ez u˙zytkownikamiw systemie. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛esi˛e25 u˙zytkowników.Obok ka˙zdegou˙zytkownikaznajduj ˛asi˛e opcje do jego zmiany.

PUA4. Usuni ˛ecieu˙zytkownikaz systemu Opis: Usuni˛ecieu˙zytkownika z systemu wraz ze wszystkimi danymi z nim zwi ˛azanymi. Scenariusz główny: 1. Wyswietlenie´ u˙zytkownikóww trybie zarz ˛adzania(PUA3). 2. Sposród´ listy u˙zytkowników u˙zytkownik wybiera tego, którego chce usun ˛ac.´ 3. System wyswietla´ okno do potwierdzenia z pytaniem czy u˙zytkownikna pewno chce usun ˛ac´ wybranego u˙zytkownika. 4. U˙zytkownikpotwierdza ch˛ec´ usuni˛eciau˙zytkownika. 5. System usuwa u˙zytkownikaz systemu wraz ze wszystkimi jego danymi. 6. System wyswietla´ now ˛alist˛eu˙zytkowników. Scenariusz alternatywny 1 – u ˙zytkownikanuluje usuwanie: 1–3. Jak w scenariuszu głównym. 4. U˙zytkownikanuluje usuwanie u˙zytkownika.

PUA5. Edycja danych u˙zytkownika Opis: Edycja danych zwi ˛azanychz kontem wybranego u˙zytkownika. Scenariusz główny: 1. Wyswietlenie´ u˙zytkownikóww trybie zarz ˛adzania(PUA3). 2. Sposród´ listy u˙zytkowników u˙zytkownik wybiera tego, którego chce zmienic.´ 3. System wyswietla´ formularze do zmian danych u˙zytkownika(RB9). 4. U˙zytkownikazatwierdza formularz. 5. System zmienia dane u˙zytkownika. 6. System wyswietla´ informacj˛eo pomyslnej´ zmianie danych u˙zytkownika. Scenariusz alternatywny 1 – e-mail nie jest unikalny: 1–4. Jak w scenariuszu głównym. 5. System wyswietla´ informacj˛e,i˙zpodany e-mail jest ju˙zu˙zywany. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 38

PUA6. Wyszukiwanie i filtrowanie u˙zytkowników Opis: Wyszukiwanie i filtrowanie u˙zytkownikówze wzgl˛eduna wartosci´ posiadanych atrybutów. Scenariusz główny: 1. Wyswietlenie´ u˙zytkownikóww trybie zarz ˛adzania(PUA3). 2. U˙zytkownikwprowadza szukan ˛awartosć´ atrybutu u˙zytkownikalub wybiera jeden z filtrów (RB10). 3. System wyswietla´ now ˛alist˛eu˙zytkownikówspełniaj ˛acychkryteria.

Rysunek 4.7. Diagram przypadków u ˙zyciadla administratora - cz ˛e´s´c2

PUA7. Przegl ˛adaniekursów Opis: Przegl ˛adaniewszystkich kursów utworzonych w systemie. Scenariusz główny: 1. W celu otwarcia panelu administracyjnego u˙zytkownik wybiera odpowiedni ˛azakładk˛ez menu głównego aplikacji. 2. System wyswietla´ panel administracyjny. 3. U˙zytkownikwciska odnosnik´ słu˙z˛acydo administrowania kursami. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 39

4. System wyswietla´ pierwsz ˛astron˛ez kursami w systemie. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛e si˛e25 kursów.

PUA8. Wyswietlenie´ kursów w trybie zarz ˛adzania (rozszerza PUA7 po ostatnim kroku, wł ˛aczaneprzez PUA9, PUA10, PUA11) Opis: Wyswietlenie´ kursów wraz z opcjami do zmiany ka˙zdegokursu z osobna. Scenariusz główny: 1. U˙zytkownikwybiera opcj˛ezarz ˛adzaniakursami w systemie. 2. System wyswietla´ pierwsz ˛astron˛ez kursami w systemie. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛e si˛e25 kursów. Obok ka˙zdegokursu znajduj ˛asi˛eopcje do jego zmiany.

PUA9. Usuwanie kursów Opis: Usuni˛eciedowolnego kursu istniej ˛acegow systemie wraz ze wszystkimi powi ˛azanymidanymi. Scenariusz główny: 1. Wyswietlenie´ kursów w trybie zarz ˛adzania(PUA8). 2. Sposród´ listy kursów u˙zytkownikwybiera kurs, który chce usun ˛ac.´ 3. System wyswietla´ okno do potwierdzenia z pytaniem czy u˙zytkownikna pewno chce usun ˛ac´ wybrany kurs. 4. U˙zytkownikpotwierdza ch˛ec´ usuni˛eciakursu. 5. System usuwa kurs z systemu. 6. System wyswietla´ now ˛alist˛ekursów Scenariusz alternatywny 1 – u ˙zytkownikanuluje usuwanie: 1–3. Jak w scenariuszu głównym. 4. U˙zytkownikanuluje usuwanie kursu.

PUA10. Wyswietlenie´ kursu z panelem edycyjnym Opis: Wyswietlenie´ kursu wraz z panelem do jego edycji, który jest udost˛ep- niony administratorowi. Scenariusz główny: 1. Wyswietlenie´ kursów w trybie zarz ˛adzania(PUA8). 2. Sposród´ listy kursów u˙zytkownikwybiera kurs, który chce zmieniac.´ 3. System wyswietla´ zawartos´c´ kursu wraz z interfejsem do jego edycji oraz danych powi ˛azanychz edytowanym kursem (RB11).

PUA11. Wyszukiwanie i ﬁltrowanie kursów Opis: Wyszukiwanie i ﬁltrowanie kursów ze wzgl˛eduna wartosci´ posiadanych atrybutów. Scenariusz główny: 1. Wyswietlenie´ kursów w trybie zarz ˛adzania(PUA8). 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 40

2. U˙zytkownik wprowadza szukan ˛awartos´c´ atrybutu kursu lub wybiera jeden z ﬁltrów (RB12). 3. System wyswietla´ now ˛alist˛ekursów spełniaj ˛acychkryteria.

PUA12. Przegl ˛adaniemateriałów Opis: Przegl ˛adaniewszystkich materiałów dodanych do systemu. Scenariusz główny: 1. W celu otwarcia panelu administracyjnego u˙zytkownik wybiera odpowiedni ˛azakładk˛ez menu głównego aplikacji. 2. System wyswietla´ panel administracyjny. 3. U˙zytkownikwciska odnosnik´ słu˙z˛acydo administrowania materiałami. 4. System wyswietla´ pierwsz ˛astron˛ez materiałami w systemie. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛esi˛e25 kursów.

PUA13. Wyswietlenie´ materiałów w trybie zarz ˛adzania (rozszerza PUA12 po ostatnim kroku, wł ˛aczaneprzez PUA14, PUA15, PUA16) Opis: Wyswietlenie´ materiałów wraz z opcjami do zmiany ka˙zdegomateriału z osobna. Scenariusz główny: 1. U˙zytkownikwybiera opcj˛ezarz ˛adzaniamateriałami w systemie. 2. System wyswietla´ pierwsz ˛astron˛ez materiałami w systemie. Kolejne strony s ˛adost˛epnepoprzez numerowane odnosniki.´ Na jednej stronie znajduj˛esi˛e25 materiałów. Obok ka˙zdegomateriału znajduj ˛asi˛eopcje do jego zmiany.

PUA14. Usuwanie materiałów Opis: Usuni˛eciedowolnego materiału multimedialnego z systemu. Scenariusz główny: 1. Wyswietlenie´ materiałów w trybie zarz ˛adzania(PUA13). 2. Sposród´ listy materiałów u˙zytkownikwybiera materiał, który chce usu- n ˛ac.´ 3. System wyswietla´ okno do potwierdzenia z pytaniem czy u˙zytkownikna pewno chce usun ˛ac´ wybrany materiał. 4. U˙zytkownikpotwierdza ch˛ec´ usuni˛eciakursu. 5. System usuwa kurs z systemu. 6. System wyswietla´ now ˛alist˛emateriałów. Scenariusz alternatywny 1 – u ˙zytkownikanuluje usuwanie: 1–3. Jak w scenariuszu głównym. 4. U˙zytkownikanuluje usuwanie materiału.

PUA15. Zmiana danych dotycz ˛acychmateriału Opis: Zmiana danych pierwotnie podawanych podczas dodawania. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 41

Scenariusz główny: 1. Wyswietlenie´ materiałów w trybie zarz ˛adzania(PUA13). 2. Sposród´ listy materiałów u˙zytkownikwybiera materiał, który chce zmienic.´ 3. System wyswietla´ formularz do zmiany materiału. 4. U˙zytkownikwprowadza nowe dane i zatwierdza formularz. 5. System wyswietla´ informacj˛eo pomyslnej´ zmianie danych.

PUA16. Wyszukiwanie i filtrowanie materiałów Opis: Wyszukiwanie i filtrowanie materiałów ze wzgl˛eduna wartosci´ posiadanych atrybutów. Scenariusz główny: 1. Wyswietlenie´ materiałów w trybie zarz ˛adzania(PUA13). 2. U˙zytkownik wprowadza szukan ˛awartosć´ atrybutu materiału lub wybiera jeden z filtrów (RB13). 3. System wyswietla´ now ˛alist˛ekursów spełniaj ˛acychkryteria.

Rysunek 4.8. Diagram przypadków u ˙zyciadla administratora - cz ˛e´s´c3

PUA17. Wyswietlenie´ panelu statystyk systemowych (wł ˛aczaneprzez PUA18, PUA19, PUA20) Opis: Wyswietlenie´ panelu statystyk systemowych, który umo˙zliwiadost˛epdo konkretnych statystyk. Scenariusz główny: 1. W celu otwarcia panelu administracyjnego u˙zytkownik wybiera odpowiedni ˛azakładk˛ez menu głównego aplikacji. 2. System wyswietla´ panel administracyjny. 4.2. Diagramy oraz scenariusze realizacji przypadków uzycia˙ 42

3. U˙zytkownikwciska odnosnik´ słu˙z˛acydo wyswietlenia´ panelu statystyk systemowych. 4. System wyswietla´ panel statystyk systemowych.

PUA18. Wyswietlenie´ statystyk ilosciowych´ Opis: Wyswietlenie´ statystyk ilosciowych´ ró˙znychbytów istniej ˛acychw systemie. Scenariusz główny: 1. Wyswietlenie´ panelu statystyk systemowych (PUA17). 2. U˙zytkownikwciska odnosnik´ słu˙z˛acydo wyswietlenia´ statystyk iloscio-´ wych. 3. System wyswietla´ statystyki ilosciowe.´

PUA19. Wyswietlenie´ statystyk dost ˛epudo systemu Opis: Wyswietlenie´ statystyk dost˛epudo systemu - akcji logowania i wylogo- wywania u˙zytkowników. Scenariusz główny: 1. Wyswietlenie´ panelu statystyk systemowych (PUA17). 2. U˙zytkownikwciska odnosnik´ słu˙z˛acydo wyswietlenia´ statystyk dost˛epu do systemu. 3. System wyswietla´ statystyki dost˛epudo systemu.

PUA20. Wyswietlenie´ wykorzystywanych zasobów systemu Opis: Wyswietlenie´ wykorzystywanych zasobów systemowych. Scenariusz główny: 1. Wyswietlenie´ panelu statystyk systemowych (PUA17). 2. U˙zytkownik wciska odnosnik´ słu˙z˛acydo wyswietlenia´ wykorzystywanych zasobów systemu. 3. System wyswietla´ wykorzystanie zasobów systemu.

Reguły biznesowe RB1. Identyﬁkator w systemie stanowi e-mail u˙zytkownika, który musi byc´ unikalny. Ka˙zdy nowy u˙zytkownik posiada w systemie przydzielon ˛arol˛e(uczen´ lub nauczyciel) w zale˙znosci´ od tego jakiego dokonał wyboru podczas rejestracji. RB2. System dokonuje przeszukiwania na podstawie nazw materiałów oraz słów kluczowych (tagów). Najbardziej dopasowane materiały s ˛awyswietlane´ u˙zytkownikowi w pierwszej kolejnosci.´ RB3. U˙zytkownikmo˙zedokonac´ ﬁltrowania materiałów ze wzgl˛eduna typ mate- riału (opcje: dowolny, wideo, audio), dat˛edodania (opcje: dowolna, dzis,´ ten ty- dzien,´ ten miesi ˛ac)oraz czas trwania (opcje: dowolny, krótszy ni˙z5 minut, dłu˙zszy lub równy 5 minut). 4.3. Wybrana technologia 43

RB4. Dane u˙zytkownikas ˛apodzielone na informacje logowania i informacje pro- filowe. Pierwsza cz˛esć´ danych składa si˛ez e-maila i hasła u˙zytkownika. Druga natomiast to imi˛e,nazwisko, adres i data urodzenia zalogowanego u˙zytkownika. RB5. Ka˙zdapozycja na wyswietlanej´ liscie´ kursów ucznia posiada tytuł oraz opis kursu. RB6. Panel edycji nauczyciela składa si˛ez interfejsu graficznego, który umo˙zliwia zarz ˛adzaniesekcjami, materiałami multimedialnymi oraz tekstowymi, a tak˙ze zmian˛edanych o kursie. RB7. Nauczyciel mo˙zewybrac´ filtr typu materiału (opcje: dowolny, wideo, audio) lub widocznosci´ materiału (opcje: dowolna, prywatny, publiczny). RB8. Nauczyciel mo˙zedokonywac´ zapisów na swoje kursy, które posiadaj ˛acsposób zapisów: przez nauczyciela lub przez nauczyciela i ucznia. Tylko takie egzemplarze kursów s ˛aprezentowane u˙zytkownikowi. RB9. Podobnie jak przy zmianie danych dokonywanej przez samego u˙zytkownika wyswietlane´ s ˛adwa formularze – jeden do zmiany informacji logowania, a drugi do zmiany informacji profilowych. RB10. Administrator mo˙ze wybrac´ filtr roli w systemie (opcje: dowolna, uczen,´ nauczyciel). RB11. Panel edycyjny dla administratora jest ograniczony. Pozwala on na usuwanie dowolnej tresci´ z kursu oraz zmieniac´ dane bezposrednio´ dotycz ˛acedanego kursu. RB12. Administrator mo˙ze wybrac´ filtr rodzaju zapisów (opcje: dowolny, przez ucznia, przez nauczyciela, przez ucznia i nauczyciela) lub filtr widocznosci´ kursu (opcje: dowolna, prywatny, publiczny). RB13. Administrator mo˙ze wybrac´ filtr typu materiału (opcje: dowolny, wideo, audio) lub filtr widocznosci´ materiału (opcje: dowolny, prywatny, publiczny).

4.3. Wybrana technologia

4.3.1. Rozwi ˛azaniai wykorzystane oprogramowanie System e-learningowy b˛edzieaplikacj ˛anapisan ˛aw skryptowym, obiektowym j˛e- zyku PHP, który jest j˛ezykieminterpretowanym i wykonywanym po stronie serwera WWW. Dost˛epdo tego systemu u˙zytkownikb˛edziemiał poprzez wpisanie odpowiedniego adresu w przegl ˛adarce internetowej. Serwerem WWW obsługuj ˛acym˙z˛adania stron pochodz ˛acychz przegl ˛adarkiinternetowej u˙zytkownika b˛edzieserwer Apa- che. System b˛edziewykorzystywał baz˛edanych PostgreSQL do przechowywania danych trwałych zwi ˛azanychz u˙zytkownikami,kursami i materiałami.

4.3.2. Podstawowe elementy systemu 1. Serwer WWW Apache. 2. Interpreter PHP - uruchamiany jako moduł serwera Apache. 3. Serwer bazy danych PostgreSQL. 4. Srodowisko´ - system linuksowy. 4.3. Wybrana technologia 44

Rysunek 4.9. Podstawowe elementy systemu

4.3.3. Budowa aplikacji w PHP i prezentacja systemu po stronie przegl ˛adarki internetowej Jako framework do budowy aplikacji w j˛ezykuPHP został wybrany Yii. Podsta- wowym wzorcem projektowym wykorzystywanym w Yii, jak i w wi˛ekszosci´ framework’ów dla j˛ezykaPHP, jest MVC. Interfejs u˙zytkownikawidoczny w przegl ˛adarce b˛edzietworzony z pomoc ˛abibliotek napisanych głównie w j˛ezykuJavaScript oraz CSS.

4.3.4. Racjonalnosć´ dokonanych wyborów a) wybór realizacji aplikacji w architekturze aplikacji internetowej: • realizacja aplikacji podobnych do docelowej jako aplikacji internetowych; • powszechnosć,´ łatwosć´ i praktycznosć´ stosowania przegl ˛adarek WWW; • najcienszy´ mo˙zliwyklient - nie wymaga ˙zadnychdodatkowych instalacji po stronie systemu operacyjnego u˙zytkownika; • dynamiczny rozwój technologii słu˙z˛acychdo tworzenia aplikacji internetowych. b) wybór serwera WWW Apache: • najbardziej popularny serwer WWW; • posiada du˙z˛ailosć´ modułów i dost˛epnychrozszerzen,´ które mog ˛abyc´ doł ˛a- czane do serwera; • wydajny przy generowaniu dynamicznych tresci´ (np. poprzez skrypt php). c) wybór j˛ezykaPHP: • najpowszechniej stosowany j˛ezykskryptowy wykonywany po stronie serwera WWW; 4.3. Wybrana technologia 45

• platformy Moodle i PHPmotion s ˛anapisane w tym j˛ezykui stale si˛erozwi- jaj ˛a; • PHP udost˛epniaogrom mo˙zliwosci´ i jest ci ˛aglerozwijany, co zwi˛ekszajego popularnos´c;´ • stosunkowo łatwy do nauki; • na rynku istnieje wiele darmowych framework’ów (Zend, PHPCake, Code- Igniter, Yii, Symfony, itp.), które ułatwiaj ˛atworzenie aplikacji internetowych. d) wybór framework’u Yii: • zgodnie ze stron ˛a http://phpframeworks.com/top-10-php-frameworks jest to obecnie framework dla j˛ezykaPHP, który cieszy si˛enajwi˛eksz˛apopularnosci´ ˛ai przychylnosci´ ˛aprogramistów; • znacz ˛acoułatwia tworzenie aplikacji internetowych w PHP poprzez udost˛epnieniedla programisty wielu narz˛edzii mo˙zliwosci´ automatyzacji czynnosci,´ które powtarzaj ˛asi˛epodczas tworzenia aplikacji internetowej. e) wybór bazy danych PostgreSQL: • najbardziej zaawansowana baza danych typu open-source; • zgodnos´c´ bazy danych z zastosowanymi innymi elementami systemu; • dokładnie opisane stosowanie bazy danych w obszernym podr˛eczniku. 5. Implementacja systemu

5.1. Framework Yii

Wprowadzenie Framework Yii (akronim od “Yes It Is”) jest komponentowym framework’iem PHP zaprojektowanym do tworzenia du˙zych aplikacji o silnym nat˛e˙zeniu ruchu takich jak forum, systemy zarz ˛adzaniatresci´ ˛ai portale internetowe. Dlatego te˙z wprowadza on mały narzut w porównaniu do innych framework’ów oraz wspiera ró˙zne systemy pami˛eci podr˛ecznej. Wa˙zn˛acech ˛aYii jest ogrom mo˙zliwosci,´ które oferuje, wsparcie wsród´ społecznosci´ programistów oraz jego stały rozwój. Wszystkie wymienione tutaj zalety Yii miały du˙zywpływ na wybór własnie´ jego przy tworzeniu mojego systemu. Yii implementuje wzorzec projektowy MVC. Jego zalet ˛ajest oddzielenie logiki biznesowej od interfejsu graﬁcznego, dzi˛eki czemu programista mo˙ze zmieniac´ te rzeczy niezale˙znie. We wzorcu MVC model przechowuje dane oraz reguły biznesowe, widok natomiast interfejs u˙zytkownika,który stanowi ˛azazwyczaj ró˙zne formularze oraz tekst.

Rysunek 5.1. Statyczna struktura aplikacji w Yii 5.1. Framework Yii 47

Kontroler w Yii a) przykładowe ˙z˛adaniewysyłane do aplikacji napisanej z wykorzystaniem Yii oraz znaczenie poszczególnych elementów scie˙zki:´

Zgodnie z powy˙zsz˛asemantyk ˛a, dla przykładowego ˙z˛adaniau˙zytkownikatwo- rzony jest obiekt kontrolera o nazwie CourseController oraz wykonywana akcja o identyfikatorze create. b) akcje: Akcje definiowane w kontrolerze s ˛ametodami, których nazwa poprzedzona jest słowem action i maj ˛aformat “actionIdAkcji”. Akcje mog ˛abyc´ równie˙zzaimple- mentowane w postaci oddzielnych klas. W takim przypadku trzeba zadeklaro- wac´ w kontrolerze mapowanie identyfikatora akcji na konkretn ˛aklas˛e. c) filtry akcji: Filtry stosowane do akcji s ˛azazwyczaj filtrami dost˛epulub filtrami do pomiaru czasu wykonywania akcji. Najcz˛esciej´ implementuje si˛eje jako metody kontrolera, lecz mo˙znarównie˙zto zrobic´ korzystaj ˛acz oddzielnych klas.

Przepływ sterowania 1. U˙zytkownik wysyła ˙z˛adanie HTTP, np. http://hostname/index.php?r= course/show&id=1 i jest ono obsługiwane przez serwer WWW poprzez wykonanie skryptu startowego index.php. 2. Skrypt startowy tworzy i uruchamia obiekt aplikacji (dalej zwany Aplikacj ˛a). 3. Aplikacja uzupełnia informacje o ˙z˛adaniuu˙zytkownikaza pomoc ˛akomponentu aplikacji request. 4. Aplikacja okresla´ identyfikator ˙z˛adanegokontrolera i akcji dzi˛eki komponen- towi aplikacji urlManager. W tym przypadku identyfikatorem kontrolera jest course, a akcji show. 5. Aplikacja tworzy instancj˛ekontrolera CourseController. Okresla´ on, ˙zeakcja show odnosi si˛edo metody actionShow w jego klasie. Kontroler wykonuje filtry nało˙zonena akcj˛edo wykonania. Nast˛epniejesli´ filtry na to pozwalaj ˛aakcja jest wykonywana. 6. Akcja odczytuje z bazy danych model Course o ID równym 1. 7. Akcja wyswietla´ widok show stworzony dla tej akcji wraz z modelem Course. 8. Widok odczytuje dane z modelu Course i wyswietla´ odczytane atrybuty. 9. Widok wykonuje pewne widgety, które zostały w nim umieszczone. 10. Zawartosć´ wygenerowana przez widok umieszczana jest w schemacie strony. 11. Akcja wyswietla´ dynamiczn ˛azawartosć´ u˙zytkownikowi. 5.1. Framework Yii 48

Rysunek 5.2. Typowy przepływ sterowania aplikacji w Yii

Aktywny rekord Aktywny rekord (ang. Active Record) jest jedn ˛az technik, która umo˙zliwia mapowanie obiektowo-relacyjne. Ka˙zda klasa aktywnego rekordu reprezentuje konkretn ˛atabel˛e istniej ˛ac˛aw bazie danych oraz udost˛epnia szereg metod pozwalaj ˛acychna wykonywanie podstawowych operacji CRUD (create, read, update and delete). Framework Yii udost˛epnia klas˛e bazow ˛a CActiveRecord, po której dziedzicz ˛awszystkie klasy (modele) reprezentuj ˛acetabele baz danych. Instancje takich klas reprezentuj ˛arekordy w bazie danych.

resource_id = 20; $res_tag->tag="sample tag"; $res_tag->save(); ?>

Wydruk 5.1. Przykład wstawiania rekordu do bazy danych.

Wydruk 5.1 przedstawia wstawianie rekordu do bazy danych. Klasa ResTag dziedziczy po CActiveRecord i reprezentuje tabel˛e w bazie danych. Dzi˛eki temu 5.1. Framework Yii 49 obiekt tej klasy posiada własciwo´ sci´ takie jak pola w danej tabeli. W powy˙zszym przykładzie przypisujemy obiektowi wartosci´ atrybutów, z których ka˙zdyreprezen- tuje atrybut o tej samej nazwie w tabeli. Na koncu´ metod ˛asave() rekord jest wsta- wiany do bazy danych. Po wykonaniu powy˙zszegokodu mamy wstawiony rekord do tabeli z tagami, który jest zwi ˛azanyz zasobem o ID równym 20 i posiada atrybut tag o wartosci´ “sample tag”. find("tag LIKE’%jezioro%’");

// znajduje rekordz tabeli tagówo kluczugłównymrównym 16 $res_tag= ResTag::model()->findByPk(16);

// znajduje pierwszy rekordz tabeli tagów, którego atrybut // resource_id jestrówny 185 $res_tag= ResTag::model() ->findByAttributes(array("resource_id"=>185));

// znajduje wszystkie rekordyz tabeli tagów, // których atrybut resource_id jestrówny 185 $res_tags= ResTag::model() ->findAllByAttributes(array("resource_id"=>185)); ?>

Wydruk 5.2. Przykłady wyszukiwania rekordów w bazie danych.

Wydruk 5.2 prezentuje metody najcz˛esciej´ stosowane do wyszukiwania rekor- dów w bazie danych. Komentarz pod ka˙zd˛az metod krótko opisuje działanie danej metody. findByPk(16);

$res_tag->tag="new tag";

// uaktualnij rekord $res_tag->update();

// wyszukaj rekord reprezentuj ˛acy tago idrównym 17 $res_tag= ResTag::model()->findByPk(17);

// usun´ rekordz bazy danych $res_tag->delete(); ?>

Wydruk 5.3. Przykład usuwania i uaktualniania rekordu w bazie danych. 5.1. Framework Yii 50

Wydruk 5.3 prezentuje podstawowe metody udost˛epnianeprzez klas˛e CActive- Record słu˙z˛acedo usuwania i uaktualniania rekordu w bazie danych. Jak widac´ na powy˙zszych wydrukach obiekty korzystaj ˛az wygodnych metod, które wykonuj ˛apodstawowe operacje z wykorzystaniem j˛ezykaSQL. Podczas implementowania aplikacji internetowej zdecydowanie najcz˛esciej´ wykonuje si˛epod- stawowe operacje CRUD. Dzi˛ekiaktywnemu rekordowi implementowanemu przez Yii programista do wykonywania podstawowych operacji bazodanowych nie potrze- buje pisac´ prostych zapytan´ dla ka˙zdejtabeli.

Podstawowa struktura katalogowa aplikacji napisanej z wykorzystaniem Yii webapp/ index.php...... Skrypt startowy aplikacji index-test.php...... Skrypt startowy aplikacji stosowany do testów assets/...... Opublikowane pliki zasobowe css/...... Pliki CSS images/...... Obrazki themes/...... Motywy aplikacji protected/...... Chronione pliki aplikacji yiic...... Skrypt konsolowy yiic dla Unix/Linux yiic.bat...... Skrypt konsolowy yiic dla Windows yiic.php...... Skrypt konsolowy PHP yiic commands/...... Komendy ’yiic’ components/ ...... Komponenty aplikacji config/...... Pliki konfiguracyjne aplikacji console.php...... Konfiguracja aplikacji konsolowej main.php...... Konfiguracja aplikacji webowej test.php...... Konfiguracja testów funkcjonalnych controllers/...... Pliki z klasami kontrolerów SiteController.php...... Domyslny´ kontroler aplikacji extensions/...... Rozszerzenia aplikacji Yii messages/...... Tłumaczone wiadomosci´ models/...... Pliki z klasami modeli runtime/...... Pliki tymczasowe tests/...... Testy aplikacji fixtures/...... Pliki z danymi testowymi dla bazy danych unit/...... Pliki z testami jednostkowymi functional/...... Pliki z testami funkcjonalnymi bootstrap.php...... Plik startowy dla testów phpunit.xml...... Plik konfiguracyjny dla testów WebTestCase.php...... Klasa bazowa dla testów funkcjonalnych views/...... Widoki oraz pliki ze schematami strony layouts/...... Pliki ze schematami strony main.php...... Główny schemat dla wszystkich stron column1.php...... Schemat dla stron z 1 kolumn ˛a column2.php ...... Schemat dla stron z 2 kolumnami site/...... Widoki dla kontrolera o identyfikatorze ’site’ index.php...... Widok dla akcji ’index’ login.php...... Widok dla akcji ’login’ 5.2. Projekt bazy danych 51

5.2. Projekt bazy danych

5.2.1. Struktura bazy danych Podstaw ˛aprojektowanego systemu jest relacyjna baza danych oparta na silniku bazodanowym PostgreSQL. Poza opublikowanymi materiałami multimedialnymi stanowi ona główne ´zródłodanych, z których korzysta tworzony system. Diagram 5.3 przedstawia schemat bazy danych zaprojektowany z wykorzystaniem modelu zwi ˛azkówencji (ang. entity-relationship - ER). Przedstawiony poni˙zej diagram ER jest diagramem logicznym, który musiał zostac´ przekształcony na diagram fizyczny. Diagram fizyczny 5.4 przedstawia relacyjny schemat bazy danych, który został wyeksportowany do serwera bazy danych PostgreSQL. Do stworzenia diagramu ER oraz diagramu fizycznego została u˙zytanotacja Information Engineering.

5.2.2. Oprogramowanie bazy danych Po stronie bazy danych została stworzona 1 procedura składowana oraz 1 wyzwalacz. Procedura składowana o nazwie enroluser zapisuje u˙zytkownika na kurs. Została ona napisana, aby zapewnic´ brak mo˙zliwosci´ zapisania na kurs wi˛ekszejliczby u˙zytkownikówni˙zjest to mo˙zliwe. Zastosowany wyzwalacz o nazwie res_delete uruchamiany jest po usuni˛eciumateriału z systemu. Pozwala to na powi ˛azanieoperacji usuwania materiału, która jest mo˙zliwado wykonania w kilku miejscach w systemie, z wykonaniem operacji na innej tabeli w bazie danych. Operacja ta polega na odj˛eciuod przestrzeni u˙zywanejprzez u˙zytkownikarozmiaru pliku usuwanego materiału multimedialnego. Framework Yii udost˛epniawygodne metody do łatwego wykonywania transakcji w bazie danych. Zaimplementowana transakcja dotyczy operacji wykonywanych w czasie aktywacji konta w systemie. Operacje wykonywane w obr˛ebietej transakcji to usuni˛ecietymczasowego u˙zytkownikaoraz wstawienie nowego, pełnoprawnego u˙zytkownika. 5.2. Projekt bazy danych 52 Rysunek 5.3. Diagram ER bazy danych systemu 5.2. Projekt bazy danych 53 Rysunek 5.4. Schemat relacyjnej bazy danych systemu 5.2. Projekt bazy danych 54

5.2.3. Opis tabel

Tabela Opis Atrybut Opis yii_temp_user Tabela przechowuje user_id Klucz główny tabeli. dane zwi ˛azanez confirm_code Kod aktywacyjny, który tymczasowymi zostaje wysłany u˙zytkownikamiw u˙zytkownikowina systemie. Rekord tej skrzynk˛epocztow ˛apo tabeli tworzony jest pomyslnym´ po pomyslnym´ zatwierdzeniu zatwierdzeniu formularza formularza rejestracyjnego. rejestracyjnego. Atrybut password email Adres e-mail jest skrótem hasła tymczasowego podanego przez u˙zytkownika. nowego u˙zytkownika. password Skrót hasła Atrybut confirm_code tymczasowego jest losowym ci ˛agiem u˙zytkownika. znaków słu˙z˛acymdo first_name Imi˛etymczasowego aktywacji konta w u˙zytkownika. systemie. last_name Nazwisko tymczasowego u˙zytkownika. address Adres zamieszkania tymczasowego u˙zytkownika. birth_date Data urodzenia tymczasowego u˙zytkownika. role_in_system Rola w systemie tymczasowego u˙zytkownika. yii_user Tabela przechowuje user_id Klucz główny tabeli. dane pełnoprawnych email Adres e-mail nowego u˙zytkowników u˙zytkownika. systemu, którzy przeszli prawidłowo password Skrót hasła nowego przez proces u˙zytkownika. rejestracji. Wi˛ekszosć´ first_name Imi˛enowego danych zawartych w u˙zytkownika. tej tabeli jest last_name Nazwisko nowego kopiowana z tabeli u˙zytkownika. yii_temp_user, po tym address Adres zamieszkania jak u˙zytkownik nowego u˙zytkownika. aktywuje swoje 5.2. Projekt bazy danych 55

konto w systemie. birth_date Data urodzenia nowego u˙zytkownika. role_in_system Rola w systemie nowego u˙zytkownika. quota Limit danych na materiały multimedialne dodawane przez u˙zytkownika. space_used U˙zywanaprzestrzen´ danych przez u˙zytkownika. add_time Czas aktywacji konta u˙zytkownikaw systemie. yii_log Tabela przechowuje log_id Klucz główny tabeli. logi zwi ˛azanez user_id Klucz obcy tabeli, u˙zytkownikami. ł ˛acz˛acyrekord tej tabeli Rejestrowane logi z rekordem z tabeli dotycz ˛alogowania i yii_user wylogowania reprezentuj ˛acym u˙zytkownikaz u˙zytkownikaw systemu. systemie. log_type Rodzaj logu (logowanie lub wylogowanie). log_time Czas zapisu logu do systemu. yii_user_co- Tabela ł ˛acz˛aca user_id Klucz obcy tabeli, urse u˙zytkownikaz ł ˛acz˛acyrekord tej tabeli kursem. Atrybut z rekordem z tabeli role_in_course yii_user okresla´ jak ˛arol˛ew reprezentuj ˛acym tym zł ˛aczeniupełni u˙zytkownikaw u˙zytkownik.Klucz systemie. obcy user_id oraz course_id Klucz obcy tabeli, course_id stanowi ˛a ł ˛acz˛acyrekord tej tabeli klucz główny tabeli. z rekordem z tabeli yii_course reprezentuj ˛acymkurs dodany do systemu. role_in_course Rola u˙zytkownikaw kursie. 5.2. Projekt bazy danych 56

yii_course_ca- Tabela przechowuje category_id Klucz główny tabeli. tegory kategorie, do których category Nazwa kategorii kursu. mog ˛anale˙zec´ kursy Kurs musi nale˙zec´ do tworzone w systemie. jednej z wybranych kategorii. yii_resource Tabela przechowuje resource_id Klucz główny tabeli. dane zwi ˛azanez section_id Klucz obcy tabeli, materiałem ł ˛acz˛acyrekord tej tabeli multimedialnym. z rekordem z tabeli yii_section reprezentuj ˛acymsekcj˛e kursu. user_id Klucz obcy tabeli, ł ˛acz˛acyrekord tej tabeli z rekordem z tabeli yii_user reprezentuj ˛acym u˙zytkownikaw systemie. resource_na- Nazwa materiału me multimedialnego. resource_type Typ materiału multimedialnego (wideo lub audio). path_to_reso- Druga cz˛esć´ scie˙zki´ urce katalogowej do pliku reprezentuj ˛acego materiał multimedialny. Pierwsz ˛acz˛esć´ scie˙zki´ stanowi scie˙zkado´ okreslonego´ katalogu w systemie operacyjnym, gdzie s ˛a przechowywane materiały multimedialne. upload_date Czas dodania materiału multimedialnego do systemu. play_length Czas trwania materiału multimedialnego. visibility Widocznosć´ materiału multimedialnego. 5.2. Projekt bazy danych 57

ﬁlesize Rozmiar pliku reprezentuj ˛acego materiał multimedialny. view_count Liczba wyswietle´ n´ materiału multimedialnego. yii_res_tag Tabela przechowuje tag_id Klucz główny tabeli. tagi zwi ˛azanez resource_id Klucz obcy tabeli, materiałami ł ˛acz˛acyrekord tej tabeli multimedialnymi w z rekordem z tabeli systemie. yii_resource reprezentuj ˛acym materiał multimedialny. tag Nazwa tagu. yii_course Tabela przechowuje course_id Klucz główny tabeli. kursy dodawane do category_id Klucz obcy tabeli, systemu. ł ˛acz˛acyrekord tej tabeli z rekordem z tabeli yii_course_category reprezentuj ˛acym kategori˛ekursu. title Tytuł kursu. description Opis kursu. visibility Widocznos´c´ kursu. enrolment Sposób zapisu na kurs. students_limit Limit miejsc do zapisu na kurs. enroled_count Liczba osób zapisanych na kurs. access_code Kod dost˛epudo kursu. add_time Czas dodania kursu do systemu. view_count Liczba wyswietle´ n´ kursu. 5.3. Struktura stworzonej aplikacji internetowej 58

yii_section Tabela przechowuje section_id Klucz główny tabeli. sekcje nale˙z˛acedo course_id Klucz obcy tabeli, kursów. ł ˛acz˛acyrekord tej tabeli z rekordem z tabeli yii_course reprezentuj ˛acymkurs dodany do systemu. title Tytuł sekcji kursu. yii_text_reso- Tabela przechowuje resource_id Klucz główny tabeli. urce materiały tekstowe section_id Klucz tabeli, ł ˛acz˛acy nale˙z˛acedo sekcji. rekord tej tabeli z rekordem z tabeli yii_section reprezentuj ˛acymsekcj˛e kursu. user_id Klucz obcy tabeli, ł ˛acz˛acyrekord tej tabeli z rekordem z tabeli yii_user reprezentuj ˛acym u˙zytkownikaw systemie. title Tytuł materiału tekstowego. add_date Czas dodania materiału tekstowego do systemu. text_content Tres´c´ materiału tekstowego. yii_lookup Tabela przechowuje name Nazwa opcji. wa˙zneopcje, mo˙zliwe code Kod opcji. do wyboru dla u˙zytkownika type Typ opcji. koncowego.´ name_position Pozycja opcji na liscie´ do wyboru.

5.3. Struktura stworzonej aplikacji internetowej

5.3.1. Podstawowe elementy systemu Podstawowymi elementami tworzonego systemu s ˛aserwer WWW Apache, interpreter PHP oraz serwer bazy danych PostgreSQL uruchomione na systemie Li- nux Ubuntu 11.04 (Natty Narwhal). Instalacja tych wszystkich elementów została 5.3. Struktura stworzonej aplikacji internetowej 59 przeprowadzona z wykorzystaniem darmowego pakietu oprogramowania BitNami LAPPStack. Wymienione oprogramowanie pozwala na szybk ˛ai bezproblemow ˛ain- stalacj˛eserwera WWW Apache z modułem PHP, serwera PostgreSQL oraz narz˛edzia phpPgAdmin na systemie linuksowym. Narz˛edziephpPgAdmin jest aplikacj ˛aPHP pozwalaj ˛ac˛ana wygodne zarz ˛adzaniebaz ˛adanych z poziomu przegl ˛adarkiinternetowej.

5.3.2. Aplikacja serwerowa

Klasy kontrolerów Podstawowymi klasami aplikacji serwerowej napisanej z wykorzystaniem framework’a Yii s ˛aklasy kontrolerów. Ka˙zda klasa kontrolera posiada zestaw akcji, z których ka˙zdaodpowiada za obsług˛epewnego ˙z˛adaniaHTTP pochodz ˛acego od aplikacji klienckiej. Framework Yii udost˛epnia klas˛e bazow ˛a CController, po której dziedziczy ka˙zda klasa stworzonego kontrolera w systemie. Podstawow ˛a funkcjonalnosci´ ˛audost˛epnian˛aprzez t ˛aklas˛ebazow ˛ajest wyswietlanie´ widoków oraz stosowanie ró˙znegorodzaju ﬁltrów akcji.

Klasy kontrolerów w głównym katalogu kontrolerów: a) SiteController - kontroler odpowiedzialny za zarz ˛adzaniedost˛epemdo systemu (logowanie i wylogowanie). Ponadto wyswietla´ podstawowe informacje o systemie i jego mo˙zliwosciach.´ b) UserController - kontroler odpowiedzialny za tworzenie i zarz ˛adzaniedanymi zwi ˛azanymiz u˙zytkownikamiw systemie. c) SearchController - kontroler zapewnia funkcjonalnosć´ wyszukiwania mate- riałów multimedialnych, które posiadaj ˛aw systemie publiczn ˛awidocznosć.´ d) ResourceController - kontroler odpowiedzialny za obsług˛epublikowanych materiałów multimedialnych w systemie oraz zarz ˛adzaniedanymi, które s ˛az nimi zwi ˛azane. e) EnrolmentController - kontroler odpowiedzialny za zapisy i wypisy uczniów z kursów dodanych przez nauczycieli. f) CourseController - kontroler odpowiedzialny za zarz ˛adzaniekursami oraz wszystkimi danymi, które mog ˛abyc´ dodane w jego obr˛ebie. Klasy kontrolerów w katalogu kontrolerów modułu administratora: a) DefaultController - kontroler odpowiedzialny za wyswietlanie´ panelu administracyjnego. b) UserController - kontroler odpowiedzialny za zarz ˛adzaniekontami u˙zytkow- ników obecnych w systemie. c) ResourceController - kontroler odpowiedzialny za zarz ˛adzaniemateriałami multimedialnymi w systemie. d) CourseController - kontroler odpowiedzialny za zarz ˛adzanie kursami doda- nymi do systemu. e) StatController - kontroler odpowiedzialny za wyswietlanie´ panelu statystyk oraz ró˙znych,specyficznych statystyk zwi ˛azanychz systemem. 5.3. Struktura stworzonej aplikacji internetowej 60

Klasy komponentów Klasy komponentów stanowi ˛aklasy, których obiekty s ˛acz˛estowykorzystywane w aplikacji w ró˙znychmiejscach. Cz˛estoobiekty tych klas s ˛aobiektami pomocni- czymi, które wykonuj ˛abardziej skomplikowane zadania i s ˛aone wykorzystywane w ró˙znychakcjach kontrolerów.

Klasy komponentów aplikacji: a) AdminAccount - klasa przechowuje stałe informacje dotycz ˛acekonta administratora. b) Conroller - specjalizowana klasa bazowa dla kontrolerów aplikacji dziedzicz ˛acapo klasie CController. c) CourseHelper - klasa udost˛epniaj˛acametody pomocnicze dotycz ˛acekursów. d) FFmpegCommand - klasa buduj ˛acapolecenie do konwersji pliku oraz udost˛epniaj ˛acaopcje dodawane do budowanego polecenia. e) FFmpegSupport - klasa umo˙zliwiaj˛acasprawdzenie czy plik wymaga konwersji oraz czy plik mo˙ze byc´ przekonwertowany do formatu odtwarzanego przez odtwarzacz ﬂowplayer. f) HttpError - klasa przechowuje stałe reprezentuj ˛acekody bł˛edówHTTP. g) HttpMessage - klasa przechowuje stałe tekstowe reprezentuj ˛acewiadomosci´ wyswietlane´ u˙zytkownikowipodczas wyst˛epowaniabł˛edówHTTP. h) HttpCast - klasa okreslaj´ ˛acajakie wiadomosci´ s ˛awyswietlane´ u˙zytkownikowi koncowemu´ podczas wyst˛epowaniaokreslonych´ bł˛edówHTTP. i) PasswordHash - klasa umo˙zliwiaj˛acagenerowanie skrótu hasła. j) ResourceManager - klasa odpowiedzialna za wykonywanie ró˙znychzadan´ dotycz ˛acychmateriału multimedialnego dodanego do systemu. Pozwala ona mi˛e- dzy innymi na konwertowanie pliku do formatu kompatybilnego z odtwarzaczem ﬂowplayer oraz czytanie ró˙znychparametrów z pliku wideo lub audio. k) SearchEngine - klasa przechowuje stałe u˙zywaneprzy wyszukiwaniu mate- riałów multimedialnych w systemie. l) UserIdentity - klasa umo˙zliwia uwierzytelnienie u˙zytkownika próbuj ˛acego si˛ezalogowac´ w systemie.

Klasy modeli Obiekty klas modeli głównie słu˙z˛a do przechowywania danych podczas wykonywania skryptu PHP. Poza danymi znajduj ˛asi˛e w nich równie˙z reguły biznesowe oraz ró˙zne metody pomagaj ˛aceprzetwarzac´ dane. Najcz˛esciej´ klasa modelu reprezentuje tabel˛edziedzicz ˛acpo klasie CActiveRecord oraz udost˛epnia programiscie´ obiektowy dost˛epdo danych znajduj ˛acychsi˛ew bazie danych.

Klasy modeli aplikacji: a) Course - klasa modelu dla tabeli yii_course. b) CourseCategory - klasa modelu dla tabeli yii_course_category. c) Log - klasa modelu dla tabeli yii_log. d) LoginForm - klasa modelu do przechowywania danych pochodz ˛acychz formularza logowania. e) Lookup - klasa modelu dla tabeli yii_lookup. f) Resource - klasa modelu dla tabeli yii_resource. 5.3. Struktura stworzonej aplikacji internetowej 61

g) ResTag - klasa modelu dla tabeli yii_res_tag. h) Section - klasa modelu dla tabeli yii_section. i) TempUser - klasa modelu dla tabeli yii_temp_user. j) TextResource - klasa modelu dla tabeli yii_text_resource. k) User - klasa modelu dla tabeli yii_user. l) UserCourse - klasa modelu dla tabeli yii_user_course.

Klasy filtrów Zaimplementowane filtry aplikacji pełni ˛afunkcj˛ekontroli dost˛epudo ró˙znych cz˛esci´ systemu. Podstawowym wymogiem dla wykonania wielu akcji w kontrole- rach jest wymóg bycia zalogowanym w systemie. Filtr ten jest implementowany przez framework Yii i mo˙zna go zdefiniowac´ w kontrolerze dodaj ˛ac metod˛e accessRules, która zwraca tablic˛easocjacyjn ˛ao odpowiednim formacie. W tablicy tej mo˙zna okresli´ c´ wymóg bycia zalogowanym jako dowolny lub predefiniowany u˙zytkownik. Dla modułu administratora metoda ta zwi ˛azanajest ze wszystkimi akcjami kontrolerów oraz pozwala na ich wykonanie wył ˛aczniedla u˙zytkownika o okreslonej´ nazwie. Filtry aplikacji stworzone w postaci oddzielnych klas s ˛a u˙zywanew wielu miejscach oraz zazwyczaj implementuj ˛abardziej skomplikowan ˛a operacj˛ekontroli dost˛epu.

Klasy filtrów aplikacji: a) IsAjaxRequest - sprawdza czy ˙z˛adanieHTTP odebrane od u˙zytkownikajest typu AJAX. b) IsTeacherFilter - sprawdza czy zalogowany u˙zytkownikposiada w systemie rol˛enauczyciela. c) IsCourseStudentFilter - sprawdza czy u˙zytkownikposiada uprawnienia do wyswietlenia´ zawartosci´ kursu. d) IsCourseTeacherFilter - sprawdza czy nauczyciel próbuje wykonac´ operacj˛edotycz ˛ac˛awłasnego kurs. Stosowanie filtrów aplikacji do wybranych akcji kontrolera odbywa si˛epoprzez definicj˛etablicy zwracanej w metodzie filters kontrolera.

5.3.3. Aplikacja kliencka Do realizacji ró˙znychzadan´ po stronie klienta została wykorzystana biblioteka j˛ezykaJavaScript - jQuery. Podczas implementowania kodu klienckiego standar- dem stało si˛eu˙zywanieró˙znychtego typu bibliotek. Jedn ˛az ich najwa˙zniejszych zalet jest takie same wykonanie metod, które udost˛epniaj˛a,w ró˙znychprzegl ˛adar- kach internetowych. Cz˛esć´ interfejsu u˙zytkownika została zaimplementowana z u˙zyciem biblioteki jQuery UI. Biblioteka ta udost˛epniaró˙znego rodzaju kontrolki oraz widgety, które upraszczaj ˛atworzenie przyjaznego interfejsu u˙zytkownika. Kolejn ˛abibliotek ˛aJavaScript zastosowan ˛aw systemie jest biblioteka History.js. Jej główna zalet ˛ajest udost˛epnienie interfejsu pozwalaj ˛acegona jednakowe korzystanie z funkcjonalnosci´ HTML5 History API dost˛epnej we wszystkich now- szych wersjach przegl ˛adarek. Standardowo do historii przegl ˛adarki dodawana jest strona, na któr ˛awejdziemy po otwarciu odnosnika´ URL. History API pozwala na bezposredni´ ˛azmian˛ehistorii przegl ˛adarki.Wykonuj ˛acodpowiedni ˛ametod˛emo˙zna 5.4. Wysyłanie i przetwarzanie plików po stronie serwera 62 dodac´ odnosnik´ URL do stosu odwiedzonych stron, co skutkuje równie˙zzmian ˛aad- resu w pasku adresu przegl ˛adarki.Funkcjonalnosć´ udost˛epnionaprzez bibliotek˛e History.js została wykorzystana w implementacji wyszukiwania materiałów multimedialnych. W przypadku znalezienia wielu stron wyników, podczas nawigowania do kolejnych stron, do historii przegl ˛adarkidodawana jest pozycja URL zawiera- j ˛acaparametry wyszukiwania oraz numer ˙z˛adanejstrony. Jesli´ u˙zytkownikb˛edzie chciał wrócic´ do poprzedniej strony wystarczy, ˙zewcisnie´ przycisk “Wstecz” w nawigacji przegl ˛adarki,a aplikacja kliencka załaduje poprzedni ˛astron˛ewysyłaj ˛ac˙z˛adanie AJAX. Załadowanie strony po wcisni˛eciuprzez´ u˙zytkownikaprzycisku “Wstecz” lub “Dalej” w nawigacji przegl ˛adarkiodbywa si˛epoprzez dodanie funkcji zwrotnej dla zdarzen´ dodawania i zdejmowania pozycji ze stosu historii przegl ˛adarki. Przed powstaniem History API przegl ˛adarkipozwalały wył ˛aczniena zmian˛ecz˛e- sci´ adresu URL - b˛ed˛acejpo znaku # (kotwicy). Aplikacja jest kompatybilna wstecz i implementuje równie˙zten sposób działania na starszych wersjach przegl ˛adarek. Wad ˛atakiego działania jest koniecznosć´ wykonania dwóch ˙z˛adan´ po odswie˙zeniu´ strony z bie˙z˛acymirezultatami. Dzieje si˛etak poniewa˙zcz˛esć´ adresu URL po znaku kotwicy nie jest przesyłana do serwera i nale˙zywykonac´ kolejne ˙z˛adanie(AJAX) w celu uzyskania ˙z˛adanejstrony z rezultatami.

5.4. Wysyłanie i przetwarzanie plików po stronie serwera

Wysyłanie plików na serwer Najprostszym wariantem wysyłania plików na serwer jest wykorzystanie formularza HTML z mo˙zliwosci´ ˛awyboru pliku do wysłania. Proces wysyłania pliku na serwer rozpoczyna si˛ewraz z zatwierdzeniem formularza. Stosuj ˛actak ˛ametod˛e wysyłania plików u˙zytkownikkorzystaj ˛acyz przegl ˛adarkiWWW nie posiada mo˙zliwosci´ podgl ˛aduprocesu wysyłania. Mo˙zliwos´c´ podgl ˛aduprocesu wysyłania pliku na serwer stanowi jedno z wymagan´ funkcjonalnych zało˙zonych dla tworzonego systemu. Na rynku istnieje wiele wtyczek, dzi˛ekiktórym mo˙znazaimplementowac´ tak ˛afunkcjonalnos´c.´ Wy- korzystuj ˛aone technologi˛e Flash oraz ró˙zne biblioteki napisane w j˛ezyku Java- Script. Jedn ˛az takich wtyczek jest wtyczka biblioteki jQuery – Uploadify. Ponadto umo˙zliwiaona wysyłanie wielu plików jednoczesnie.´ Wi˛ecejinformacji o mo˙zliwosciach´ tego rozszerzenia mo˙zna znale´zc´ pod adresem: http://www.uploadify. com/about/. Ze wzgl˛eduna powy˙zszezalety wtyczka Uploadify została wykorzystana w procesie publikowania materiałów multimedialnych.

Odtwarzanie materiałów multimedialnych po stronie klienta W celu odtwarzania materiałów wideo/audio najbardziej wygodnym rozwi ˛a- zaniem z punktu widzenia u˙zytkownika systemu jest u˙zycie odtwarzacza Flash. Dzi˛ekitemu u˙zytkowniksystemu nie musi instalowac´ ˙zadnegododatkowego oprogramowania. Takie rozwi ˛azaniesposród´ analizowanych serwisów stosuje np. YouTube czy Plumi. W implementowanym systemie wybrano podobne rozwi ˛azanie, a jako odtwarzacz Flash wykorzystano darmowy odtwarzacz ﬂowplayer, podobnie jak zostało to zrobione w systemie Plumi. 5.4. Wysyłanie i przetwarzanie plików po stronie serwera 63

Konwersja plików po stronie serwera Z dokonanym wyborem odtwarzacza (ﬂowplayer’a) zwi ˛azanes ˛apewne ograniczenia, a zatem i wymagania. Odtwarzacz Flash mo˙zeodtwarzac´ tylko wybran ˛a, w ˛ask˛agrup˛eplików w odpowiednim formacie i odpowiednio zakodowanych stru- mieniach wideo i audio. Odtwarzacz ﬂowplayer odtwarza pliki wideo, których parametry s ˛azgodne z tabel ˛aponi˙zej:

Format Kodek wideo Kodek audio Rozszerzenie pliku FLV FLV (Sorenson MP3 .ﬂv H.263) MP4 H.264 AAC .mp4 .mov .m4v F4V H.264 AAC .f4v

Z powy˙zszegozestawienia wynika, i˙zplik o formacie i kodowaniu innym ni˙zwy- mienionym w tabeli nale˙zypoddac´ konwersji. Nowy plik wyjsciowy´ otrzymany z nie- kompatybilnego pliku wejsciowego´ powinien posiadac´ wszystkie parametry zgodne ze wspieranymi przez odtwarzacz ﬂowplayer. Dzi˛ekitakiej konwersji materiał multimedialny mo˙zebyc´ bezproblemowo dostarczany do u˙zytkownikakoncowego.´ W celu przeprowadzenia konwersji plików do odpowiedniego formatu oraz kodowania został u˙zyty FFmpeg - szybki konwerter plików wideo i audio. Narz˛edzie te działa w trybie tekstowym, co doskonale nadaje si˛edo zastosowania w systemie. Jego zaletami jest wsparcie wielu formatów i kodeków oraz szybkos´c´ konwersji.

Rysunek 5.5. Domy´slnakonwersja plików wideo i audio w systemie

Konwersja plików audio odbywa si˛edo formatu i kodowania mp3. Wynika to z tego, i˙z pliki takie potraﬁ dostarczyc´ dla u˙zytkownika plugin audio wybranego odtwarzacza Flash. 5.4. Wysyłanie i przetwarzanie plików po stronie serwera 64

Budowanie polecenia do konwertowania plików Konwerter FFmpeg podczas konwersji pliku dla wielu parametrów wyjsciowych´ strumieni audio i wideo u˙zywadomyslnych´ wartosci.´ Lepszym rozwi ˛azaniemjest ustawienie plikowi, który otrzymamy po konwersji takich parametrów jakie posiada plik wejsciowy.´ Przy takiej realizacji plik wyjsciowy´ b˛edzienieznacznie ró˙zniłsi˛eod wejsciowego.´ W celu odczytania odpowiednich wartosci´ parametrów z pliku zastosowano rozszerzenie j˛ezykaPHP - FFMPEG-PHP. Zostało ono u˙zyteprzy budowaniu komendy konwertuj ˛acejoraz przy odczytywaniu metadanych dotycz ˛acychdodanego mate- riału. Przykładowo, zostało ono wykorzystane do odczytania długosci´ trwania dodanego pliku.

Proces przetwarzania wysłanego pliku W wi˛ekszosci´ przypadków proces przetwarzania wysłanego pliku składa si˛ez dwóch etapów - dwóch sekwencji ˙z˛adanie-odpowied´z. Sekwencja ˙z˛adan´ i odpowiedzi oraz moment wykonywania poszczególnych akcji został zilustrowany na ry- sunku 5.6. W pierwszym etapie po wysłaniu pliku na serwer wtyczka Uploadify wysyła ˙z˛adanie wykonania akcji FilesUploadedAction. Diagram blokowy 5.7 przedstawia kroki podejmowane przy wykonywaniu tej akcji. W zale˙znosci´ od wyniku tej akcji najcz˛esciej´ wykonywana jest akcja FileConvertAction. Diagram blokowy 1 przedstawia przetwarzanie dokonywane w tej akcji. Przetwarzanie pliku musiało zostac´ podzie- lone na dwa ˙z˛adaniai odpowiedzi HTTP. Powodem takiej decyzji jest fakt, i˙zczas wykonania konwersji jest bardzo cz˛estodłu˙zszy ni˙z 30s. Limit 30 sekund natomiast jest nało˙zonyna wykonanie ˙z˛adania, które zostało wysłane przez aplikacj˛e w technologii Flash (w tym przypadku z u˙zyciemwtyczki Uploadify). Ograniczenie takie spowodowało, i˙zpo stronie przegl ˛adarkiwykonywane jest kolejne ˙z˛adaniez odesłaniem takich samych danych, które zostały odebrane po stronie u˙zytkownika.

Struktura katalogowa przechowywanych plików wideo i audio Pocz ˛atkowowszystkie pliki dodawane do systemu były umieszczane w jednym katalogu o nazwie uploads. Rozwi ˛azanietakie wraz ze wzrostem liczby plików staje si˛eniewydajne. Podstawowe systemowe operacje katalogowe staj ˛asi˛ecoraz dłu˙zsze z powodu zbyt du˙zejliczby plików przechowywanych w jednym katalogu. Wsku- tek tego organizacja plików została zaimplementowana metod ˛aopisan ˛aw mate- riale [12]. Zgodnie z tym sposobem plik jest umieszczany na koncu´ dodatkowej, dwupoziomowej struktury katalogowej. Nazwa katalogu pierwszego poziomu dla nowego pliku stanowi dziesi˛etnyzapis pierwszego bajtu skrótu losowej nazwy przy- pisywanej plikowi. Podobnie jest z nazw ˛akatalogu drugiego poziomu, gdzie nowy katalog nosi nazw˛edzisi˛etnegozapisu drugiego bajtu skrótu. Jednobajtowa nazwa katalogu daje 256 mo˙zliwosci´ na ka˙zdympoziomie. Ł ˛aczniemo˙zemystworzyc´ zatem 65536 katalogów. Przy losowej generacji nazw dla nowych plików otrzymujemy dobr ˛adystrybucj˛eplików. Przykładowa scie˙zkado´ pliku dodanego do systemu to uploads/10/50/ZZSORGLKSPO0141.mp3. 5.4. Wysyłanie i przetwarzanie plików po stronie serwera 65

Rysunek 5.6. Typowa sekwencja ˙z˛ada´ni odpowiedzi HTTP zwi ˛azanychz wysyła- niem i przetwarzaniem wysłanego pliku 5.4. Wysyłanie i przetwarzanie plików po stronie serwera 66

Rysunek 5.7. Działania podejmowane w akcji FilesUploadedAction 5.4. Wysyłanie i przetwarzanie plików po stronie serwera 67

Rysunek 5.8. Działania podejmowane w akcji FileConvertAction

Listy kodeków oraz formatów wspieranych przez narz ˛edzieFFmpeg Kompletny wykaz wspieranych kodeków i formatów, przez zastosowane w systemie narz˛edzieFFmpeg, znajduje si˛ew zał ˛acznikuA. 5.5. Testy automatyczne aplikacji 68

5.5. Testy automatyczne aplikacji

Dla stworzonego systemu zostały zaimplementowane testy jednostkowe oraz funkcjonalne. Testy jednostkowe zostały napisane dla ka˙zdejklasy umieszczonej w katalogu komponentów aplikacji (poza klasami, które wył ˛acznieprzechowuj ˛astałe u˙zywanew aplikacji). Testy funkcjonalne natomiast zostały napisane dla ka˙zdej klasy kontrolera. W obu przypadkach zostało wykorzystane narz˛edzie PHPUnit, które stanowi standard dla testowania aplikacji napisanych w j˛ezykuPHP. Głów- nymi atutami tego narz˛edziajest udost˛epnianieframework’a ułatwiaj ˛acegopisanie testów oraz umo˙zliwieniełatwego uruchamiania i konﬁguracji testów, a tak˙zeana- lizy ich wyników. Narz˛edziemwykorzystanym do przeprowadzania testów funkcjonalnych jest Selenium.

5.5.1. Testy funkcjonalne Selenium jest zestawem narz˛edzipozwalaj ˛acymautomatyzowac´ akcje wykonywane w przegl ˛adarkachinternetowych na ró˙znychsystemach operacyjnych. Pod- stawowym elementem Selenium jest Selenium Server. Głównymi zadaniami tego serwera jest uruchamianie, unicestwianie oraz sterowanie instancjami ró˙znych przegl ˛adarek internetowych. Protokołem słu˙z˛acymdo komunikacji z serwerem Selenium jest WebDriver. Wykorzystana biblioteka kliencka implementuj ˛acaten protokół to php-webdriver (stworzona przez Facebook). Publikacja materiałów multimedialnych jest zwi ˛azanaz wyborem plików z lokalnego systemu plików, a wi˛ecz obsług ˛asystemowego okna dialogowego. Automa- tyczne sterowanie przegl ˛adark ˛ainternetow ˛aw tym zakresie nie jest mo˙zliwe. Do przetestowania tej funkcjonalnosci´ systemu został u˙zytyprogram cnee. Umo˙zliwia on nagrywanie oraz odtwarzanie sesji protokołu X. W celach testowych stworzone zostały nagrania, które otwieraj ˛aokno wyboru plików, a nast˛epniewybieraj ˛apliki do wysłania. W metodach testowych natomiast nagrania te s ˛aodtwarzane. Funk- cjonalnos´c´ publikacji materiałów multimedialnych została przetestowana lokalnie na przegl ˛adarce internetowej Google Chrome. Wszystkie testy funkcjonalne aplikacji dziedzicz ˛apo klasie WebTestCase. Do- myslnie´ klasa ta dziedziczyła po klasie, która zapewniała uruchamianie testów z wykorzystaniem przestarzałej wersji Selenium. Klasa ta została całkowicie zmie- niona. W metodzie wykonywanej na pocz ˛atkutestu o nazwie setUp tworzona jest nowa sesja przegl ˛adarki.Metoda tearDown jest wykonywana na koncu´ testu, gdzie niszczona jest sesja przegl ˛adarki.Wszystkie metody zaimplementowane w obr˛ebie tej klasy wykorzystuj ˛awspomnian ˛abibliotek˛eklienck ˛aphp-webdriver.

5.5.2. Testowanie aplikacji napisanej w Yii Podstawowym skryptem PHP wykonywanym po odbiorze ˙z˛adaniaHTTP od u˙zytkownika jest skrypt index.php. Skrypt startowy aplikacji, który b˛edziewykonany po stronie serwera jest zale˙znyod ˙z˛adaniaHTTP. Odnosniki´ URL otwierane podczas testów posiadaj ˛ainn ˛anazw˛e skryptu - index-test.php. W czasie wykonania skryptu startowego ładowany jest plik konfiguracyjny aplikacji. W pliku tym znajduje si˛emi˛edzyinnymi deklaracja modułów, komponentów oraz parametrów aplikacji. Dzi˛ekitemu ró˙zne pliki konfiguracyjne ładowane s ˛apodczas wykonania ró˙znychskryptów startowych. Rozwi ˛azanietakie pozwala na skonfigurowanie 5.5. Testy automatyczne aplikacji 69 niezale˙znychbaz danych - bazy produkcyjnej dla głównego skryptu index.php oraz bazy testowej dla skryptu testowego index-test.php. Główn ˛aklas ˛audost˛epnian˛aprzez framework Yii, która została wykorzystana podczas wykonywania testów jest CDbFixtureManager. Jej główn ˛afunkcjonalno- sci´ ˛ajest odtwarzanie okreslonego´ stanu bazy danych przed ka˙zdorazowym wykonaniem metody testowej. W tym celu w klasie testowej deklaruje si˛etablic˛eokre- slaj´ ˛ac˛a,które tabele powinny byc´ przywrócone do okreslonego´ stanu. Stan ka˙zdej tabeli, który chcemy posiadac´ przed wykonaniem testów okreslany´ jest przez plik zawieraj ˛acytablic˛ez predefiniowanymi danymi. Pliki te znajduj ˛asi˛ew katalogu protected/tests/fixtures. Plikiem konfiguracyjnym testów uruchamianych przez narz˛edziePHPUnit jest plik phpunit.xml, który znajduje si˛ew katalogu protected/tests. Zawiera on de- klaracj˛e dwóch grup testów. Pierwsza grupa stanowi testy jednostkowe, druga natomiast testy funkcjonalne. Ponadto w pliku tym znajduj˛esi˛enazwa skryptu PHP, który jest wykonywany przed ka˙zdymtestem. Jego nazwa to bootstrap.php. Tworzona jest w nim instancja aplikacji Yii, co pozwala na korzystanie w testach z wygodnych metod udost˛epnianychprzez klas˛e CActiveRecord. Scie˙zkazapisu´ plików wysyłanych do systemu zale˙zyod wykonywanego skryptu startowego aplikacji. Dla głównego skryptu (index.php) dwupoziomowa struktura katalogowa oraz pliki umieszczane s ˛aw katalogu uploads. Dla startowego skryptu testowego (index-test.php) jest to natomiast katalog test_uploads. Katalogi zapisu plików s ˛akonfigurowalne z poziomu głównego pliku konfiguracyjnego aplikacji o nazwie main.php umieszczonego w katalogu protected/config.

5.5.3. Srodowisko´ testowe Z powodu ograniczen´ technicznych testy aplikacji zostały przeprowadzone w do- mowej sieci lokalnej. Aplikacja została przetestowana w poni˙zszychkonﬁguracjach: a) na komputerze z systemem operacyjnym Windows Vista Home Premium u˙zywaj ˛acklienta HTTP: • Google Chrome wersja 21.0.1180.75, • Mozilla Firefox wersja 12.0, • Opera wersja 11.62, • Internet Explorer wersja 9.0.8112.16421. b) na komputerze z systemem operacyjnym Linux Ubuntu 11.04 u˙zywaj˛ac klienta HTTP: • Google Chrome wersja 21.0.1180.75, • Mozilla Firefox wersja 12.0, • Opera wersja 11.62. Uruchamianie polecen´ testowych, które testuj ˛asystem na ró˙znychprzegl ˛adar- kach i systemach operacyjnych mo˙zliwe jest z u˙zyciem skryptu powłoki bash o nazwie run_tests umieszczonego w katalogu protected/tests. 5.5. Testy automatyczne aplikacji 70

Rysunek 5.9. Srodowisko´ testowe

5.5.4. Wyniki testów Wygenerowanie statystyki pokrycia kodu dla przetestowanej aplikacji serwerowej zostało przeprowadzone z u˙zyciembiblioteki PHP_CodeCoverage. Ł ˛acznieprze- prowadzono 48 testów i dokonano 5427 asercji.

Rysunek 5.10. Pokrycie kodu PHP 6. Podsumowanie

W ramach powstałej pracy in˙zynierskiej udało si˛e stworzyc´ system e-learningowy posiadaj ˛acywiele mo˙zliwosci.´ Powstała aplikacja internetowa posiada podstawow ˛afunkcjonalnos´c´ zało˙zon˛apodczas analizy wymagan´ funkcjonalnych. Bardzo dobr ˛adecyzj ˛aprojektow ˛abyło zastosowanie framework’a Yii w celu napisania aplikacji w j˛ezykuPHP. Decyzja ta pozwoliła na znaczne skrócenie czasu implementacji. Stworzenie systemu w architekturze aplikacji internetowej wi ˛azało si˛e z pewnymi wymaganiami. Jednym z takich wymagan´ było przetestowanie aplikacji na wielu przegl ˛adarkachoraz systemach operacyjnych. W zwi ˛azkuz tym, i˙z system ten stworzony został przez jedn ˛aosob˛e nie jest mo˙zliwe,aby jego zakres mo˙zliwosci´ był zbli˙zonydo zakresu prezentowanego przez systemy przedstawione w cz˛esci´ teoretycznej pracy. W zwi ˛azkuz tym system został stworzony z mysl´ ˛a,aby w pewnym stopniu wyró˙zniałsi˛ena tle przeanalizowanych serwisów.

Mój system wyró˙zniasi˛easpektami zwi ˛azanymiz funkcjonalnosci´ ˛a: a) publikowanie materiałów multimedialnych jest mo˙zliwezarówno w obr˛ebie kursu jak i poza nim, b) mo˙zliwejest wyszukanie materiałów multimedialnych opublikowanych z poziomu kursu, c) zaimplementowana została dodatkowa lista proponowanych materiałów dla materiałów nale˙z˛acychdo kursu. Ponadto w przeciwienstwie´ do wczesniej´ opisanych serwisów napisanych w PHP mój system opiera si˛e na bardzo nowoczesnym framework’u. Dzi˛eki temu jego rozwój jest prostszy, a kod nie jest powielany dzi˛ekinarz˛edziom,które udost˛epnia Yii.

Dalsze mo˙zliwosci´ rozwoju systemu: 1. Rozwój funkcjonalnosci´ zwi ˛azanychz opublikowanymi materiałami: • komentowanie materiałów, • ocenianie materiałów, • generowanie miniaturek dla dodanych materiałów wideo. 2. Rozwój funkcjonalnosci´ zwi ˛azanychz odtwarzaczem ﬂowplayer: • oprogramowanie odtwarzacza w celu lepszej interakcji z u˙zytkownikiem, • zastosowanie protokołu pseudostreaming, który pozwala na przewini˛ecie odtwarzanego materiału do dowolnego momentu na osi czasu. 3. Rozwój funkcjonalnosci´ zwi ˛azanychz przetwarzaniem plików: • rozszerzenie konwersji plików do formatu MP4 z kodowaniem H264, • umo˙zliwienieu˙zytkownikowiwyboru jakosci´ materiału do odtworzenia. Narz ˛edziaimplementacji i dokumentacji

Podczas projektowania i implementacji systemu zostały u˙zytenast˛epuj˛acena- rz˛edzia:

• Eclipse PHP Development Tools (PDT) - tworzenie aplikacji serwerowej w PHP,

• Aptana CSS and JavaScript Editor (Eclipse plug-ins) - tworzenie kodu klienckiego oraz arkuszy stylów CSS,

• yEd Graph Editor - tworzenie rysunków, diagramów przypadków u˙zyciaoraz diagramu ER,

• ERMaster - tworzenie schematu relacyjnej bazy danych,

• Selenium - wykonywanie testów automatycznych na ró˙znychprzegl ˛adarkachi systemach operacyjnych,

• PHPUnit - tworzenie, uruchomianie oraz konﬁguracja testów aplikacji,

• phpPgAdmin - zarz ˛adzaniebaz ˛adanych PostgreSQL,

• GIMP, Inkscape - tworzenie wygl ˛aduoraz instrukcji u˙zytkowaniasystemu,

• phpDocumentor 2 - tworzenie dokumentacji kodu napisanego w PHP.

• cnee - tworzenie testów automatycznych zwi ˛azanychz publikacj ˛amateriałów multimedialnych. Zał ˛acznikA: Listy kodeków oraz formatów wspieranych przez narz ˛edzieFFmpeg

Lista kodeków, których dekodowanie wspiera narz ˛edzieFFmpeg: 4xm, 8bps, 8svx_exp, 8svx_fib, aac, aac_latm, aasc, ac3, adpcm_4xm, ad- pcm_adx, adpcm_ct, adpcm_ea, adpcm_ea_maxis_xa, adpcm_ea_r1, adpcm_ea_r2, adpcm_ea_r3, adpcm_ea_xas, adpcm_ima_amv, adpcm_ima_apc, adpcm_ima_dk3, adpcm_ima_dk4, adpcm_ima_ea_eacs, adpcm_ima_ea_sead, adpcm_ima_iss, ad- pcm_ima_qt, adpcm_ima_smjpeg, adpcm_ima_wav, adpcm_ima_ws, adpcm_ms, adpcm_sbpro_2, adpcm_sbpro_3, adpcm_sbpro_4, adpcm_swf, adpcm_thp, ad- pcm_xa, adpcm_yamaha, alac, als, amrnb, amrwb, amv, anm, ansi, ape, ass, asv1, asv2, atrac1, atrac3, aura, aura2, avrp, avs, avui, ayuv, bethsoftvid, bfi, binkaudio_dct, binkaudio_rdft, binkvideo, bintext, bmp, bmv_audio, bmv_video, c93, camstudio, camtasia, cavs, cdgraphics, cdxl, cinepak, cljr, cook, cyuv, dca, dfa, dirac, dnxhd, dpx, dsicinaudio, dsicinvideo, dvbsub, dvdsub, dvvideo, dxa, dxtory, eac3, eacmv, eamad, eatgq, eatgv, eatqi, escape124, escape130, exr, ffv1, ffvhuff, flac, flashsv, flashsv2, flic, flv, fraps, frwu, g722, g723_1, g726, g729, gif, gsm, gsm_ms, h261, h263, h263i, h263p, h264, h264_vdpau, huffyuv, iac, idcinvideo, idf, iff_byterun1, iff_ilbm, imc, indeo2, indeo3, in- deo4, indeo5, interplay_dpcm, interplayvideo, j2k, jacosub, jpegls, jv, kgv1, kmvc, lagarith, libopencore_amrnb, libopencore_amrwb, libvorbis, loco, mace3, mace6, mdec, microdvd, mimic, mjpeg, mjpegb, mlp, mmvideo, motionpixels, mov_text, mp1, mp1float, mp2, mp2float, mp3, mp3adu, mp3adufloat, mp3float, mp3on4, mp3on4float, mpc7, mpc8, mpeg1video, mpeg1video_vdpau, mpeg2video, mpeg4, mpeg4_vdpau, mpegvideo, mpegvideo_vdpau, msa1, msmpeg4, msm- peg4v1, msmpeg4v2, msrle, mss1, msvideo1, mszh, mts2, mxpeg, nellymoser, nuv, paf_audio, paf_video, pam, pbm, pcm_alaw, pcm_bluray, pcm_dvd, pcm_f32be, pcm_f32le, pcm_f64be, pcm_f64le, pcm_lxf, pcm_mulaw, pcm_s16be, pcm_s16le, pcm_s16le_planar, pcm_s24be, pcm_s24daud, pcm_s24le, pcm_s32be, pcm_s32le, pcm_s8, pcm_s8_planar, pcm_u16be, pcm_u16le, pcm_u24be, pcm_u24le, pcm_u32be, pcm_u32le, pcm_u8, pcm_zork, pcx, pgm, pgmyuv, pgssub, pictor, png, ppm, prores, prores_lgpl, ptx, qcelp, qdm2, qdraw, qpeg, qtrle, r10k, r210, ralf, rawvideo, real_144, real_288, realtext, rl2, roq_dpcm, roqvideo, rpza, rv10, rv20, rv30, rv40, s302m, sami, sanm, sgi, shorten, sipr, smackaud, smackvid, smc, snow, sol_dpcm, sonic, sp5x, srt, sunrast, svq1, svq3, targa, theora, thp, tiertexseqvideo, tiff, tmv, truehd, truemotion1, truemotion2, truespeech, tscc2, tta, twinvq, txd, ultimotion, utvideo, v210, v210x, v308, v408, v410, vb, vble, vc1, vc1_vdpau, vc1image, vcr1, vima, vmdaudio, vmdvideo, vmnc, vorbis, vp3, vp5, vp6, vp6a, vp6f, vp8, vqavideo, wavesynth, wavpack, wmalossless, wmapro, wmav1, wmav2, wmavoice, wmv1, wmv2, wmv3, wmv3_vdpau, wmv3image, wnv1, ws_snd1, xan_dpcm, xan_wc3, xan_wc4, xbin, xbm, xl, xsub, xwd, y41p, yop, yuv4, zerocodec, zlib, zmbv Zał ˛acznikA: Listy kodeków oraz formatów wspieranych przez narz ˛edzieFFmpeg 74

Lista formatów, których demuksowanie wspiera narz ˛edzieFFmpeg: 4xm, aac, ac3, act, adf, adx, aea, aiff, alaw, alsa, amr, anm, apc, ape, asf, ass, au, avi, avs, bethsoftvid, bfi, bin, bink, bit, bmv, c93, caf, cavsvideo, cdg, cdxl, daud, dfa, dirac, dnxhd, dsicin, dts, dv, dv1394, dxa, ea, ea_cdata, eac3, f32be, f32le, f64be, f64le, fbdev, ffm, ffmetadata, film_cpk, filmstrip, flac, flic, flv, g722, g723_1, g729, gsm, gxf, h261, h263, h264, hls,applehttp, ico, idcin, idf, iff, ilbc, image2, image2pipe, ingenient, ipmovie, iss, iv8, ivf, jack, jacosub, jv, latm, lavfi, lmlm4, loas, lxf, m4v, matroska,webm, mgsts, microdvd, mjpeg, mlp, mm, mmf, mov,mp4,m4a,3gp,3g2,mj2, mp3, mpc, mpc8, mpeg, mpegts, mpegtsraw, mpegvideo, msnwctcp, mtv, mulaw, mvi, mxf, mxg, nc, nsv, nut, nuv, ogg, oma, oss, paf, pmp, psxstr, pva, qcp, r3d, rawvideo, realtext, rl2, rm, roq, rpl, rso, rtp, rtsp, s16be, s16le, s24be, s24le, s32be, s32le, s8, sami, sap, sbg, sdp, shn, siff, smjpeg, smk, smush, sol, sox, spdif, srt, swf, thp, tiertexseq, tmv, truehd, tta, tty, txd, u16be, u16le, u24be, u24le, u32be, u32le, u8, vc1, vc1test, video4linux2,v4l2, vmd, voc, vqf, w64, wav, wc3movie, wsaud, wsvqa, wtv, wv, x11grab, xa, xbin, xmv, xwma, yop Zał ˛acznikB: Instrukcja u˙zytkowaniasystemu

Zał ˛acznikten przedstawia podstawowe scenariusze u˙zytkowaniasystemu z po- działem na ró˙znych aktorów wyst˛epuj˛acychw systemie. Jego głównym celem jest stworzenie u˙zytkownikowimo˙zliwosci´ szybkiego skorzystania z podstawowych funkcjonalnosci´ systemu. Ponadto instrukcja ta ma za zadanie zapoznac´ u˙zytkownika z mo˙zliwosciami,´ interfejsem oraz nawigacj ˛azaimplementowanego systemu. W celu przedstawienia interakcji u˙zytkownikaz systemem oraz rezultatów podej- mowanych działan´ zaprezentowane b˛ed˛azrzuty ekranu.

Podstawowy wygl ˛adsystemu

Rysunek 1. Strona główna systemu

Podstawowe elementy interfejsu graﬁcznego systemu oznaczone na powy˙zszym zrzucie ekranu to: 1. Logo systemu. 2. Wyszukiwarka systemu. 3. Panel z informacjami logowania. 4. Menu główne systemu. 5. Główny kontener HTML przechowuj ˛acyinformacje prezentowane u˙zytkownikowi koncowemu.´ B.1. Instrukcja dla go´scia 76

B.1: Instrukcja dla goscia´

Rejestracja B.1. Instrukcja dla go´scia 77 B.1. Instrukcja dla go´scia 78

Wyszukiwanie materiałów multimedialnych B.1. Instrukcja dla go´scia 79

Przegl ˛adaniekursów w systemie B.2. Instrukcja dla ucznia 80

B.2: Instrukcja dla ucznia

Przegl ˛adaniekursów ucznia B.2. Instrukcja dla ucznia 81

Logowanie do systemu B.2. Instrukcja dla ucznia 82

Zapisywanie si ˛ena kurs B.3. Instrukcja dla nauczyciela 83

B.3: Instrukcja dla nauczyciela

Tworzenie nowego kursu w systemie B.3. Instrukcja dla nauczyciela 84 B.3. Instrukcja dla nauczyciela 85

Dodawanie materiałów wideo i audio B.3. Instrukcja dla nauczyciela 86 B.3. Instrukcja dla nauczyciela 87

Zapisanie ucznia na kurs B.4. Instrukcja dla administratora 88

B.4: Instrukcja dla administratora

Przegl ˛adanieu˙zytkowników B.4. Instrukcja dla administratora 89

Dodawanie u˙zytkownikówdo systemu B.4. Instrukcja dla administratora 90

Usuni ˛ecieu˙zytkownikaz systemu B.4. Instrukcja dla administratora 91

Funkcjonalnos´c´ zwi ˛azanaz usuwaniem i przegl ˛adaniemdotyczy równie˙zkur- sów oraz materiałów istniej ˛acychw systemie. Sekwencja czynnosci´ prowadz ˛acado realizacji tych działan´ jest bardzo podobna jak dla u˙zytkowników.W zwi ˛azkuz tym przedstawione wy˙zejdziałania dotycz ˛aceu˙zytkownikówstanowi ˛awzór post˛epowa- nia przy innych bytach w systemie. Zał ˛acznikC: Instrukcja instalacji oprogramowania

Instalacja systemu na serwerze z systemem operacyjnym Linux Ubuntu 11.04 1. Sci´ ˛agni˛eciei instalacja BitNami LAPPStack - http://bitnami.org/stack/ lappstack. 2. Zbudowanie i instalacja konwertera FFmpeg - https://ffmpeg.org/trac/ ffmpeg/wiki/UbuntuCompilationGuide. Podczas konfiguracji kompila- cji narz˛edzia FFmpeg nale˙zy dodac´ opcj˛e “–enable-shared” oraz usun ˛ac´ “–enable-libvpx” i “–enable-libx264”. 3. Dodanie do katalogu “/etc/ld.so.conf.d” pliku o nazwie “custom-libs.conf” o zawartosci´ “/usr/local/lib” oraz wykonanie polecenia “ldconfig”. Dzi˛ekitemu konwerter FFmpeg załaduje odpowiednio biblioteki linkowane dynamicznie. 4. Instalacja rozszerzenia PHP - ffmpeg-php poprzez wykonanie polecenia “sudo apt-get install php5-ffmpeg”. 5. Skopiowanie pliku rozszerzenia “ffmpeg.so” do katalogu “Zainstalowany Bit- Nami LAPPStack/php/lib/php/extensions”. 6. Skopiowanie na serwer plików z aplikacj ˛ai framework’iem Yii. 7. Konfiguracja serwera WWW Apache oraz PHP (pliki konfiguracyjne znajduj ˛a si˛ena płycie CD).

Instalacja narz ˛edzipotrzebnych do testowania 1. Instalacja PHPUnit - https://github.com/sebastianbergmann/phpunit/. 2. Instalacja XDebug - http://xdebug.org/docs/install. 3. Sci´ ˛agni˛ecieserwera Selenium - http://seleniumhq.org/download/.

Zał ˛acznikD: Zawartos´c´ doł ˛aczonejpłyty CD

Struktura katalogowa plików w głównym katalogu o nazwie webapp wygl ˛ada nast˛epuj˛aco:

webapp/ praca_inz.pdf...... ˙ Tekst pracy in˙zynierskiej config_files...... Pliki konﬁguracyjne (Apache oraz PHP) www...... Główny katalog z wszystkimi plikami framework...... Pliki framework’a Yii multimedia_cms...... Pliki stworzonej aplikacji Bibliograﬁa

[1] Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom. Systemy baz danych. Kom- pletny podr˛ecznik. Wydawnictwo Helion, wydanie drugie, 2011. [2] Krzysztof Sacha. In ˙zynieriaoprogramowania. Wydawnictwo Naukowe PWN, wydanie pierwsze, 2010. [3] Leon Shklar, Rich Rosen. Web Application Architecture: Principles, Protocols and Practi- ces. Wydawnictwo Wiley, wydanie drugie, Glasgow 2009. [4] Luke Welling, Laura Thomson. PHP i MySQL. Tworzenie stron WWW. Vademecum profesjonalisty. Wydawnictwo Helion, wydanie czwarte, 2009.

Materiały z sieci internet

[5] Informacje ogólne o Moodle. http://moodle.org/about/. [6] Informacje ogólne o Plumi. http://en.wikipedia.org/wiki/Plone_%28software% 29. [7] Informacje ogólne o serwisie YouTube. http://en.wikipedia.org/wiki/YouTube. [8] Mo˙zliwosci´ Plumi. http://en.flossmanuals.net/plumi/ch003_key-features/. [9] Mo˙zliwosci´ systemu Moodle. http://docs.moodle.org/20/en/Features. [10] Mo˙zliwosci´ systemu PHPmotion. http://phpmotion.com/content/view/17/33/. [11] Podstawowa funkcjonalnos´c´ serwisu YouTube. http://www.youtube.com/t/about_ essentials. [12] Tworzenie struktury katalogowej na podstawie skrótu. http: //michaelandrews.typepad.com/the_technical_times/2009/10/ creating-a-hashed-directory-structure.html. [13] Wymagania systemu PHPmotion. http://phpmotion.com/content/view/16/32/. [14] Cuong Do. Seattle Conference on Scalability: YouTube Scalability. http://video. google.com/videoplay?docid=-6304964351441328559, 2007.