System publikacji w internecie materiałów multimedialnych
Transkrypt
										System publikacji w internecie materiałów multimedialnych
                                        
                                        
                                Rok akademicki 2011/2012
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA INŻYNIERSKA
Maciej Pachocki
System publikacji w internecie
materiałów multimedialnych
Opiekun pracy:
mgr inż. Krzysztof Chabko
Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.........................................
Podpis Przewodniczacego
˛
Komisji Egzaminu Dyplomowego
Specjalność:
Inżynieria Systemów Informatycznych
Data urodzenia:
15 grudnia 1989 r.
Data rozpoczecia
˛
studiów:
1 października 2008 r.
Życiorys
Urodziłem sie˛ 15 grudnia 1989 r. w Białymstoku. Uczeszczałem
˛
do gimnazjum
nr 5. Naste˛ pnie w latach 2005-2008 uczyłem sie˛ w III Liceum Ogólnokształcacym
˛
w Białymstoku. W roku 2007 udało mi sie˛ uzyskać certyfikat CAE z jezyka
˛
angielskiego. Od roku 2008 studiuje˛ na Politechnice Warszawskiej na wydziale EITI.
Moimi głównymi zainteresowaniami sa˛ piłka nożna oraz hokej na lodzie. W
hokeja na lodzie gram od poczatku
˛
szkoły gimnazjalnej. Ponadto przez wiele lat
sklejałem modele szybowców uczeszczaj
˛
ac
˛ do modelarni.
.....................................
podpis studenta
Egzamin dyplomowy
Złożył 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 bedzie
˛
umożliwiał publikowanie materiałów multimedialnych przy wykorzystaniu ogólnodostep˛
nego medium jakim jest dziś internet. Publikacja tych materiałów miała być dokonywana przez nauczyciela, który ma na celu nauczyć na odległość innych użytkowników systemu. Powstały system miał również skupić sie˛ na stronie e-learningu, z
czym wiazało
˛
sie˛ stworzenie określonych ról w systemie oraz ograniczenie uprawnień dla poszczególnych użytkowników.
Zaimplementowana aplikacja korzysta z relacyjnej bazy danych PostgreSQL oraz
została napisana w jezyku
˛
PHP z użyciem framework’a Yii. Aplikacja jest dostepna
˛
poprzez przegladark
˛
e˛ internetowa,
˛ a serwerem WWW wykorzystanym do obsługi
żada
˛ ń użytkowników jest 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 treści
1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2. Wybór aplikacji do analizy i podstawy współczesnych aplikacji internetowych
2.1. Poszukiwania aplikacji do analizy . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Czym jest aplikacja internetowa ? . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. HTTP i jego ograniczenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Nowa technologia - AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5. Podejścia stosowane w tworzeniu aplikacji internetowych . . . . . . . . . . . .
2.5.1. Podejścia programowe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2. Podejścia szablonowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.3. Podejścia hybrydowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.4. Zastosowanie framework’u . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6. Popularność framework’ów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
3
3
3
3
4
4
4
4
3. Przeglad
˛ aplikacji umożliwiajacych
˛
publikacje˛ materiałów multimedialnych
3.1. YouTube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. Przepływ pojedynczego żadania
˛
HTTP . . . . . . . . . . . . . . . . . .
3.1.2. Zastosowane serwery i narzedzia
˛
z nimi zwiazane
˛
. . . . . . . . . . .
3.1.3. Obsługa wideo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4. Obsługa miniaturek zdjeć
˛ . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5. Bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.6. Priorytetyzacja szybkości dostepu
˛
do różnych cześci
˛
serwisu . . . . .
3.1.7. Partycjonowanie baz danych . . . . . . . . . . . . . . . . . . . . . . . .
3.1.8. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. PHPmotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Wymagania serwerowe (Linux/Unix) . . . . . . . . . . . . . . . . . . .
3.2.2. Podstawowe możliwości oferowane przez system . . . . . . . . . . . .
3.2.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Plumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. Podstawowe możliwości systemu . . . . . . . . . . . . . . . . . . . . .
3.3.2. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4. Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1. Podstawowe możliwości systemu . . . . . . . . . . . . . . . . . . . . .
3.4.2. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
7
8
8
9
9
10
10
10
10
11
11
11
11
11
12
14
4. Tworzony system e-learningowy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1. Specyfikacja i analiza wymagań . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Wizja, zakres oraz cel projektu . . . . . . . . . . . . . . . . . . . . . . .
4.1.2. Role i aktorzy w systemie . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3. Wymagania funkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4. Wymagania niefunkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Diagramy oraz scenariusze realizacji przypadków użycia . . . . . . . . . . . .
4.3. Wybrana technologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Rozwiazania
˛
i wykorzystane oprogramowanie . . . . . . . . . . . . . . .
4.3.2. Podstawowe elementy systemu . . . . . . . . . . . . . . . . . . . . . . .
4.3.3. Budowa aplikacji w PHP i prezentacja systemu po stronie przegladarki
˛
internetowej . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
15
15
16
22
22
43
43
43
44
ii
Spis treści
4.3.4. Racjonalność dokonanych wyborów . . . . . . . . . . . . . . . . . . . .
5. Implementacja systemu . . . . . . . . . . . . . . . . . . . .
5.1. Framework Yii . . . . . . . . . . . . . . . . . . . . . . .
5.2. Projekt bazy danych . . . . . . . . . . . . . . . . . . . .
5.2.1. Struktura bazy danych . . . . . . . . . . . . . .
5.2.2. Oprogramowanie bazy danych . . . . . . . . . .
5.2.3. Opis tabel . . . . . . . . . . . . . . . . . . . . .
5.3. Struktura stworzonej aplikacji internetowej . . . . . .
5.3.1. Podstawowe elementy systemu . . . . . . . . .
5.3.2. Aplikacja serwerowa . . . . . . . . . . . . . . .
5.3.3. Aplikacja kliencka . . . . . . . . . . . . . . . . .
5.4. Wysyłanie i przetwarzanie plików po stronie serwera
5.5. Testy automatyczne aplikacji . . . . . . . . . . . . . .
5.5.1. Testy funkcjonalne . . . . . . . . . . . . . . . .
5.5.2. Testowanie aplikacji napisanej w Yii . . . . . .
5.5.3. Środowisko testowe . . . . . . . . . . . . . . . .
5.5.4. Wyniki testów . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
51
51
51
54
58
58
59
61
62
68
68
68
69
70
6. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Narzedzia
˛
implementacji i dokumentacji . . . . . . . . . . . . . . . . . . . . . . . . .
72
Załacznik
˛
A: Listy kodeków oraz formatów wspieranych przez narzedzie
˛
FFmpeg 73
Załacznik
˛
B: Instrukcja użytkowania systemu
B.1: Instrukcja dla gościa . . . . . . . . . . . .
B.2: Instrukcja dla ucznia . . . . . . . . . . . .
B.3: Instrukcja dla nauczyciela . . . . . . . . .
B.4: Instrukcja dla administratora . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
76
80
83
88
Załacznik
˛
C: Instrukcja instalacji oprogramowania . . . . . . . . . . . . . . . . . .
92
Załacznik
˛
D: Zawartość dołaczonej
˛
płyty CD . . . . . . . . . . . . . . . . . . . . . .
92
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Materiały z sieci internet
93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Wprowadzenie
W obecnych czasach w Internecie istnieje wiele serwisów umożliwiajacych
˛
publikacje˛ materiałów wideo oraz audio. Najwiekszym
˛
z nich jest serwis YouTube,
który oferuje swoim użytkownikom bardzo dużo możliwości, zapewniajac
˛ przy tym
wysokie pre˛ dkości wysyłania oraz odtwarzania plików multimedialnych dodanych
do systemu.
Poza serwisami skupionymi głównie na publikacji multimediów istnieja˛ również
takie, które w podstawowym zamyśle tworzone sa˛ do nauczania na odległość. Sa˛
to tzw. systemy e-learningowe – VLE (ang. Virtual Learning Environment). Jednym
z najbardziej popularnych systemów umożliwiajacych
˛
nauczanie na odległość jest
system Moodle.
Podstawowym celem tworzonego systemu jest udostepnienie
˛
jego użytkownikom
możliwości publikacji oraz zarzadzania
˛
materiałami multimedialnymi, podobnie jak
jest to możliwe w serwisie YouTube. Czynności te maja˛ być możliwe tylko dla wybranej kategorii użytkowników oraz odbywać sie˛ w kontekście nauczania (e-learningu).
Przykładowym scenariuszem użytkowania nowego systemu jest umieszczenie przez
nauczyciela – lekarza kursu z materiałem wideo pokazujacym
˛
jak poprawnie wykonywać zastrzyki oraz jego odtworzenie przez ucznia – pielegniark
˛
e.
˛
Ilość aplikacji umożliwiajacych
˛
na publikacje˛ w Internecie materiałów wideo i
audio stale rośnie. Wie˛ kszość z nich jest dostepna
˛
poprzez przegladark
˛
e˛ internetowa.
˛ Coraz cze˛ ściej celem publikacji plików nie jest wyłacznie
˛
rozrywka. W
systemach e-learningowych głównym celem jest nauczanie pewnej grupy ludzi w
celu zdobycia konkretnej wiedzy.
Drugi oraz trzeci rozdział pracy stanowia˛ cześć
˛ teoretyczna.
˛ W rozdziale 2 przedstawione zostały podstawy współczesnych aplikacji internetowych. W kolejnym
opisane zostały aplikacje internetowe, które sa˛ zbliżone funkcjonalnie do stworzonego systemu. Dwa rozdziały (4 i 5) opisuja˛ proces projektowania i implementacji projektu. Rozdział 4 przedstawia wymagania postawione przed projektowanym
systemem oraz wybrana˛ technologie˛ implementacji projektu. W rozdziale 5 opisana
została implementacja systemu. Na koniec pracy przedstawione zostało podsumowanie wykonanej pracy oraz możliwości dalszego rozwoju stworzonej aplikacji.
2. Wybór aplikacji do analizy i podstawy
współczesnych aplikacji internetowych
2.1. Poszukiwania aplikacji do analizy
W czasie poszukiwań aplikacji, których funkcjonalność byłaby zbliżona do funkcjonalności mojego docelowego systemu zdecydowana wiekszość
˛
z nich została zaimplementowana w architekturze aplikacji internetowej. W zwiazku
˛
z tym serwisy
wybrane do analizy sa˛ serwisami dostepnymi
˛
poprzez przegladark
˛
e˛ WWW.
Do analizy wybrałem serwisy YouTube, PHPMotion, Plumi i Moodle. Cechuja˛ sie˛
one znaczna˛ popularnościa˛ i dużym sukcesem osiagni
˛ etym
˛
na rynku. Najlepszym
chyba wyznacznikiem sukcesu jest ilość użytkowników korzystajacych
˛
z wybranych
aplikacji.
2.2. Czym jest aplikacja internetowa ?
Zgodnie z definicja˛ zaczerpniet
˛ a˛ z publikacji [3] aplikacja internetowa jest aplikacja˛ zrealizowana˛ w architekturze klient-serwer, która używa przegladarki
˛
internetowej jako programu klienckiego. Dostarcza ona dynamicznej treści poprzez serwery WWW rozproszone w Internecie. Różni sie˛ znacznie od zwykłych stron internetowych, które ograniczaja˛ sie˛ do wysyłania użytkownikowi statycznych treści
pochodzacych
˛
ze zwykłych plików. Aplikacja internetowa dostarcza treść generowana˛ dynamicznie na podstawie zawartości żadania
˛
HTTP, zachowań użytkownika
czy sugerujac
˛ sie˛ wzgle˛ dami bezpieczeństwa.
Rysunek 2.1. Nieodłaczne
˛
elementy aplikacji internetowej
2.3. HTTP i jego ograniczenia
3
Powyższa ilustracja przedstawia podstawowe elementy typowej aplikacji internetowej. Istnienie innych elementów poza klientem i serwerem HTTP jest zależne
od wybranej technologii. Standardowo w aplikacjach wykorzystuje sie˛ różne źró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 wia˛ża˛ sie˛ pewne ograniczenia. Bazuje on na paradygmacie żadanie-odpowiedź,
˛
a kolejne żadania
˛
pochodzace
˛ od przegladarki
˛
sa˛ niezależne od pozostałych mimo, że czesto
˛
wykonywane
sa˛ w obre˛ bie tej samej sesji.
W celu wprowadzenia stanu pomiedzy
˛
żadaniami
˛
najcześciej
˛
stosuje sie˛ ciasteczka (ang. cookies). Ciasteczka sa˛ to pewne dane, które wysyła serwer WWW
i zleca, aby zostały zapamie˛ tane. W tym celu posługuje˛ sie˛ odpowiednim nagłówkiem. Po otrzymaniu żadania
˛
HTTP z takim nagłówkiem, przegladarki
˛
internetowe
najcze˛ ściej zapamie˛ tuja˛ dane, które zostały w nim umieszczone. Dane te sa˛ wysyłane wraz z żadaniem
˛
HTTP, pod warunkiem spełnienia odpowiednich wymogów,
które sa˛ zależne od konkretnego ciasteczka.
2.4. Nowa technologia - AJAX
Fakt, iż protokół HTTP jest protokołem bezstanowym oraz bazuje na paradygmacie żadanie-odpowiedź
˛
okazał sie˛ sporym ograniczeniem w poczatkowym
˛
rozwoju
aplikacji internetowych. Wszelka zmiana treści na stronie internetowej wymagała przeładowania całej strony, co wiazało
˛
sie˛ z dużym ruchem po stronie serwerów WWW. Ponadto zachowanie takie było nieintuicyjne dla użytkowników witryn.
Technologia,
˛ która przyczyniła sie˛ do tego, że aplikacje internetowe stały sie˛ w rzeczywistości interaktywne jest AJAX (ang. Asynchronous Javascript and XMLHttpRequest). Pozwala ona z poziomu jezyka
˛
Javascript wysłać asynchronicznie podrzedne
˛
żadanie
˛
HTTP do serwera WWW bez przeładowywania strony. Odpowiedź takiego
żadania
˛
lub jej cze˛ ść jest zazwyczaj wstawiana do pewnego fragmentu strony internetowej. Rozwiazanie
˛
takie sprzyja zmniejszeniu ruchu pomiedzy
˛
klientem, a
serwerem oraz znacznie poprawia wrażenie i doświadczenie użytkownika.
2.5. Podejścia stosowane w tworzeniu aplikacji internetowych
2.5.1. Podejścia programowe
W rozwiazaniach
˛
stosujacych
˛
podejście programowe (lub skryptowe) zdecydowana wie˛ kszość dynamicznej treści, która jest odsyłana do klienta HTTP jest tworzona w obre˛ bie kodu źródłowego. Dotyczy to również znaczników HTML, a wiec
˛
i wygladu
˛
strony prezentowanego dla użytkownika końcowego. Stawia to programistom i projektantom stron spore problemy, ponieważ każda zmiana, zarówno w
działaniu jak i wygladzie
˛
aplikacji wymaga interwencji programisty.
Tworzenie aplikacji jest skupione wokół kodu źródłowego (ang. code-centric), co
ogranicza swobode˛ pracy dla projektantów interfejsów graficznych. Mechanizmy
wykorzystujace
˛ takie podejście to, np. CGI lub Servlet API.
2.6. Popularność framework’ów
4
2.5.2. Podejścia szablonowe
W przeciwieństwie do podejścia programowego w tym podejściu wieksz
˛
a˛ uwage˛
skupia sie˛ na formatowaniu strony (ang. page-centric), a mniej na pisaniu kodu
źródłowego. Technologie sugerujace
˛ sie˛ takim podejściem udostepniaj
˛
a˛ wiele konstrukcji formatujacych,
˛
które nie wymagaja˛ dużej wiedzy programistycznej. W takim przypadku łatwiej jest pracować z plikami dla projektantów stron.
Przykładowymi technologiami z takim podejściem sa˛ SSI, Cold Fusion oraz Velocity. Nadal istnieje, podobnie jak w podejściu programowym problem odseparowania doste˛ pu do danych od ich prezentacji, co utrudnia podział pracy.
2.5.3. Podejścia hybrydowe
Podejścia hybrydowe wykorzystuja˛ zarówno konstrukcje formatujace
˛ jak i kod
źródłowy. Fragmenty kodu źródłowego sa˛ zwyczajowo umieszczane miedzy
˛
znacznikami HTML i sa˛ one ograniczone odpowiednimi znakami w celu późniejszej interpretacji.
Przykładowe technologie działajace
˛ w ten sposób to PHP, ASP oraz JSP. W rozwiazaniach
˛
tych zarówno logika aplikacji jak i prezentacja danych jest przemieszana. Skutkuje to trudnościami 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, implementuja˛ one
cz˛esto powtarzalne funkcjonalności, które nie musza˛ być tworzone od zera przez
programistów. Framework aplikacji internetowej najcześciej
˛
prezentuje podział na
moduły dla programistów i projektantów stron. Przykładem framework’u może być
Struts, który implementuje wzorzec MVC i sprawia, iż można wykorzystać JSP w
pewnym stopniu odchodzac
˛ od podejścia hybrydowego.
2.6. Popularność framework’ów
Na rynku aplikacji internetowych coraz wieksz
˛
a˛ popularność i poparcie zyskuja˛
frameworki. Wymagaja˛ one od programisty wiekszej
˛
dyscypliny pracy, ale i sprzyjaja˛ szybkiemu tworzeniu programów. Najpowszechniej stosowanym i implementowanym wzorcem projektowym jest wzorzec MVC (ang. Model-View-Controller). Pozwala on mie˛ dzy innymi 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ść framework’ów
5
Rysunek 2.2. Wzorzec projektowy Model-Widok-Kontroler
Ważnymi atutami tego podejścia jest oddzielenie dostepu
˛
do danych (Modelu) od
prezentacji tych danych (Widoku). Podział taki umożliwia na łatwa˛ zmiane˛ widoku
w zależności od ustawień użytkownika, co okazuje sie˛ przydatne w aplikacjach
internetowych.
3. Przeglad
˛ aplikacji umożliwiajacych
˛
publikacje˛
materiałów multimedialnych
3.1. YouTube
Na poczatku
˛
swojego istnienia YouTube był pisany w jezyku
˛
PHP. Po przejeciu
˛
serwisu przez firme˛ Google dane na temat skalowalności i technologii użytej do
rozwijania tego serwisu zostały przedstawione na konferencji. Odbyła sie˛ ona w
Seattle w dniu 23 czerwca 2007 r. i została przeprowadzona przez Cuong Do.
Poniższe informacje zostały sporzadzone
˛
na jej podstawie. Pozycja [14] prezentuje
odnośnik URL do zapisu wideo z tej konferencji.
3.1.1. Przepływ pojedynczego żadania
˛
HTTP
Zanim żadanie
˛
od klienta (zazwyczaj jest nim przegladarka
˛
internetowa użytkownika) trafi do serwera WWW przechodzi one przez urzadzenie
˛
NetScaler. Urza˛
dzenie te umożliwia równoważenie obcia˛żenia (ang. load balancing) i przechowywanie w pamie˛ ci podre˛ cznej statycznych treści. Jako serwer WWW został użyty
serwer Apache z właczonym
˛
modułem mod_fastcgi, który umożliwia komunikacje˛
oprogramowania serwera Apache z innymi programami działajacymi
˛
na serwerze
lub innym komputerze.
Żadania
˛
o określonej strukturze trafiaja˛ od serwera Apache do serwera aplikacji, który został napisany w jezyku
˛
Python. Serwer ten natomiast łaczy
˛
sie˛ z
bazami danych i uzupełnia odpowiedź przekazana˛ do niego przez serwer Apache o
odpowiednia˛ zawartość. Po dynamicznym uzupełnieniu odpowiedź jest wysyłana
do serwera Apache, który jest odpowiedzialny za jej odesłanie do przegladarki
˛
internetowej użytkownika.
7
3.1. YouTube
Rysunek 3.1. Przepływ pojedyńczego żadania
˛
HTTP
3.1.2. Zastosowane serwery i narzedzia
˛
z nimi zwiazane
˛
a)
b)
c)
d)
serwer WWW Apache działajacy
˛ na systemie SUSE Linux,
serwer aplikacji napisany w jezyku
˛
Python,
użycie psyco – kompilatora JIT z Pythona do C dla ważnych cześci
˛
aplikacji,
przechowywanie kodu HTML w pamieci
˛ podrecznej
˛
oraz serializacja obiektów
w celu optymalizacji czasu dostepu
˛
do danych.
3.1.3. Obsługa wideo
Każdy materiał wideo udostepniany
˛
jest przez tzw. “mini-cluster”, czyli przez
kilka komputerów. Dzie˛ ki temu jeśli któryś komputer ulegnie awarii materiał wideo
b˛edzie nadal doste˛ pny.
Jako serwer do obsługi wideo został użyty Lighttpd. Najbardziej popularne materiały video zostały umieszczone w sieciach CDN (ang. Content Delivery Network),
które korzystajac
˛ z pamie˛ ci operacyjnej zapewniaja˛ najszybszy dostep
˛ do najcze˛
ściej ogladanych
˛
materiałów.
3.1. YouTube
8
3.1.4. Obsługa miniaturek zdjeć
˛
Problemy
• duża ilość miniaturek, ze wzgledu
˛
na to, że dla każdego materiału wideo
odpowiadaja˛ 4 miniaturki;
• duża liczba żada
˛ ń o miniaturki, zwiazana
˛
z tym, że na jednej stronie www
może być wyświetlonych ich kilkadziesiat.
˛
Poczatkowo
˛
stosowany był serwer Apache. Nastepnie
˛
zastosowano Squid, który
okazał sie˛ lepszy, ale w dalszym okresie czasu malała jego wydajność, co nie było
do zaakceptowania.
Ostatecznie do obsługi miniaturek zdjeć
˛ wykorzystano serwer Lighttpd, który
został zmodyfikowany w celu bardziej wydajnego dostepu
˛
do obrazków przechowywanych na dysku. Domyślnie serwer Lighttpd jest uruchamiany jako jeden proces
z jednym watkiem
˛
głównym. Aby odczyt z dysku nie blokował watku
˛
głównego serwera zmieniono kod Lighttpd i wprowadzono wielowatkowość.
˛
Odczyty moga˛ być
wykonywanie przez watki
˛
robocze, które nie wstrzymuja˛ watku
˛
głównego. Watek
˛
główny może zlecić odczyt któremuś z watków
˛
roboczych, a samemu w tym czasie
odczytywać miniaturki, np. z pamieci
˛ podrecznej.
˛
Na poczatku
˛
miniaturki obrazków przechowywano w zwykłych katalogach tworzac
˛ wielopoziomowe struktury drzewiaste. Sprawiało to miedzy
˛
innymi problem z
kopiowaniem miniaturek na inny komputer – zajmowało to po prostu dużo czasu.
Lepszym rozwiazaniem
˛
okazało sie˛ użycie Google BigTable – rozproszonego magazynu danych. Ze wzgle˛ du na to, że jest to system rozproszony, aby zmniejszyć
opóźnienie zastosowano duża˛ ilość poziomów pamieci
˛ podrecznej
˛
miedzy
˛
źródłem
danych, a klientem.
3.1.5. Bazy danych
Typ i zastosowanie
• relacyjna baza danych MySQL,
• przechowuja˛ metadane – dane użytkowników (nazwa, hasło), tytuły opisów
materiałów wideo, wiadomości w systemie, itp.
Optymalizacje dostepu
˛
do baz danych
• optymalizacje zapytań SQL,
• zastosowanie memcached w celu rzadszych odwołań do bazy danych, a czest˛
szych do pamie˛ ci operacyjnej,
• stosowanie pamie˛ ci podrecznej
˛
po stronie serwera aplikacji.
Replikacja baz danych
Poczatkowo
˛
w 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ż problem z propagacja˛ zapisu rekordów od bazy
głównej (master) do replik baz danych. Pojawiało sie˛ mało przewidywalne opóźnienie, wynikajace
˛
z tego, że replikacja bazy danych w MySQL jest całkowicie
asynchroniczna i pozbawiona wewnetrznego
˛
spójnego mechanizmu zapisywania.
W MySQL w replikach baz danych, w przeciwieństwie do bazy głównej, wystepuje
˛
3.1. YouTube
9
jeden watek
˛
replikujacy,
˛
który staje sie˛ problemem, ponieważ przy dłuższych uaktualnieniach blokuje on nastepne
˛
uaktualnienia i zwieksza
˛
opóźnienie repliki. Aby
zmniejszyć te opóźnienie wykorzystano fakt, że w MySQL wystepuje
˛
jeden watek
˛
do
buforowania zapytań SQL i jeden watek
˛
do ich wykonywania. Optymalizacja ta dotyczyła zapytań SQL, które uaktualniały rekordy w bazie danych. Zaprojektowano
narz˛edzie (DB Cache Priming), które przy wczytywaniu zapytań 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 sie˛ w pamieci
˛ podrecznej.
˛
Dzieki
˛ takiemu rozwiazaniu
˛
watek
˛
wykonujacy
˛ zapytania nie musiał być wstrzymywany ze
wzgl˛edu na mogacy
˛ wystapić
˛
odczyt dyskowy, a zapytania SQL były wykonywane
błyskawicznie. Spowodowało to znaczne zmniejszenie opóźnienia replikacji.
3.1.6. Priorytetyzacja szybkości dostepu
˛
do różnych cześci
˛
serwisu
W trakcie rozwoju serwisu YouTube wzieto
˛ pod uwage˛ fakt , że najważniejsze jest
to, aby sprawnie i szybko wyświetlane były strony z materiałami wideo. Skutkiem
tego był podział replik baz danych na pule zasobów: pula dotyczaca
˛ materiałów
wideo i pula generalna na rzeczy pozostałe, np. na rzeczy zwiazane
˛
z usługami społecznościowymi. Do baz danych w puli generalnej trafiały bardziej skomplikowane
zapytania SQL, które zajmowały wiecej
˛
czasu.
3.1.7. Partycjonowanie baz danych
Monolityczna˛ baze˛ danych, która zawierała dane wszystkich użytkowników
podzielono na “kawałki”, z których każdy zawierał cz˛eść wszystkich użytkowników.
Ograniczyło to ilość doste˛ pów do dysku na jednej maszynie, a zwiekszyło
˛
ilość
dost˛epów do pamie˛ ci.
Obecnie YouTube jest pisany głównie w Javie bazujac
˛ na framework’u Guice.
Do odtwarzania wideo jest wymagany Adobe Flash Player.
Podstawowe możliwości oferowane przez serwis YouTube
• publikowanie filmów, również w formacie High Definition;
• edycja filmu przed jego opublikowaniem, możliwość dodania dźwieku
˛
do sekwencji wideo;
• komentowanie obejrzanych filmów, możliwość oceniania komentarzy wystawionych przez inne osoby, komentarze z najwyższa˛ ilościa˛ głosów dodatnich
pojawiaja˛ sie˛ na samej górze pola na komentarze – tuż pod odtwarzaczem z
ocenianym filmem;
• wypożyczanie filmów;
• ocenianie filmu poprzez klikanie “Lubie”;
˛
• wyszukiwanie filmów poprzez wpisanie słowa kluczowego, tematu lub tytułu
filmu, doste˛ pne sa˛ również różne filtry w celu zawe˛ żenia rezultatów wyszukiwania;
• prowadzenie kanału przez użytkownika serwisu YouTube, w którym sa˛
umieszczane informacje o jego opublikowanych i ulubionych filmach oraz jego
listy odtwarzania;
• możliwość subskrypcji do wybranych kanałów innych użytkowników;
3.2. PHPmotion
10
• dzielenie sie˛ odnośnikami do filmów poprzez umieszczenie ich na portalach
społecznościowych (np. Facebook, Twitter).
3.1.8. Podsumowanie
Serwis YouTube jest chyba najlepszym przykładem serwisu rozwijanego i skierowanego głównie na publikowanie materiałów wideo. Głównymi jego zaletami sa˛
wysoka niezawodność (repliki baz danych, filmy udostepniane
˛
przez “mini-cluster”)
oraz szybki doste˛ p do materiałów wideo (CDN). Godnym uwagi jest fakt, że w rozwoju serwisu zastosowano różne serwery WWW w zależności od pobieranej treści w
celu optymalizacji wykonywanych zadań.
3.2. PHPmotion
PHPmotion jest darmowym systemem zarzadzania
˛
treścia˛ (ang. Content Management System), który pozwala jego użytkownikom dzielić sie˛ filmami, muzyka˛ oraz
zdj˛eciami. Dzie˛ ki temu oprogramowaniu można stworzyć własna˛ strone˛ funkcjonalnie zbliżona˛ do serwisu YouTube.
Powyższy system został napisany w PHP. Na stronie programu PHPmotion możemy znaleźć wymagania co do serwerów potrzebnych do uruchomienia tego oprogramowania, co w dużej mierze daje przeglad
˛ użytych technologii, narzedzi
˛
i bibliotek do zbudowania tego systemu.
3.2.1. Wymagania serwerowe (Linux/Unix)
•
•
•
•
•
•
•
•
•
PHP 4.3 lub wyższe (z obsługa˛ CLI),
serwer bazy danych MySQL,
LAME MP3 Encoder,
Libogg + Libvorbis,
Mencoder oraz Mplayer,
FFMpeg-PHP,
GD Library 2 lub wyższa,
CGI-BIN,
zdolny do uruchamiania procesów w tle.
3.2.2. Podstawowe możliwości oferowane przez system
•
•
•
•
•
•
•
•
publikowanie oraz usuwanie filmów wideo;
komentowanie filmów wideo, blogów, zdjeć
˛ oraz stron profilowych;
tworzenie albumów zdje˛ ć;
wsparcie dla formatu MP3 – automatyczne odczytywanie tytułu, gatunku, itp.
z utworu muzycznego;
utworzenie własnego bloga;
możliwość dodania materiałów wideo do “ulubionych”;
unikatowa strona dla każdego członka systemu, istnieje możliwość zmiany
informacji profilowych oraz obrazka reprezentujacego
˛
osobe˛ w systemie;
wewne˛ trzny system komunikacji miedzy
˛
użytkownikami systemu pozwalajacy
˛
na wysyłanie wiadomości do użytkowników w systemie.
3.3. Plumi
11
3.2.3. Podsumowanie
System PHPmotion jest ciekawa˛ pozycja˛ dla osób, które chciałyby założyć własny
serwis z duża˛ liczba˛ bardzo ciekawych możliwości. Wykorzystuje czesto
˛
spotykane
i sprawdzone zestawienie: aplikacji napisanej w PHP, która korzysta z bazy danych
MySQL. Ponadto w serwisie PHPmotion wykorzystano dużo bibliotek bed
˛ acych
˛
oprogramowaniem open-source.
3.3. Plumi
Plumi jest darmowym systemem zarzadzania
˛
treścia˛ wideo, który bazuje na systemie Plone, który z kolei został napisany na podstawie systemu Zope. Domyślnie 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 jezyku
˛
Python oraz Javascript (właczaj
˛
ac
˛ biblioteke˛ jQuery). Wysyłanie dowolnego pliku na serwer może
odbywać sie˛ przez protokół HTTP. Wieksze
˛
pliki wysyłane sa˛ przez protokół FTP.
3.3.1. Podstawowe możliwości systemu
• ogladanie
˛
i ściaganie
˛
filmów wideo, do ogladania
˛
filmó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 wydarzeń;
• przegladanie
˛
materiałów wideo po wybranej kategorii, kraju, temacie, gatunku
czy etykiecie;
• publikowanie stron, obrazków, dokumentów;
• stworzenie oraz edycja własnego profilu i przegladanie
˛
profili innych członków
systemu;
• zmiana je˛ zyka interfejsu użytkownika;
• dodawanie komentarzy do materiałów wideo, ważnych wydarzeń.
3.3.2. Podsumowanie
System Plumi jest bardzo rozwinietym
˛
systemem zarzadzani
˛
treścia.
˛ Jest tak
mi˛edzy innymi, dlatego że bazuje na już istniejacym
˛
systemie Plone. Ciekawa˛ rzecza˛
wykorzystana˛ w systemie jest obiektowy model bazy danych. Dzieki
˛
obiektowej
bazie danych nie potrzeba rzutować danych z programu do informacji w tabelach
i na odwrót jak to ma miejsce w relacyjnym modelu bazy danych. Ważna˛ cecha˛
Plumi jest wykorzystanie darmowego odtwarzacza Flash – flowplayera.
3.4. Moodle
System Moodle (ang. Modular Object-Oriented Dynamic Learning Environment)
jest bardzo popularnym wirtualnym środowisku edukacyjnym – VLE (ang. Virtual
3.4. Moodle
12
Learning Environment), który pozwala na nauke˛ na odległość. Nazywany jest również systemem zarzadzania
˛
kursami. Dane statystyczne z września 2011 r. wskazuja˛ na to, że z systemu korzysta około 47 milionów użytkowników z 211 krajów
na całym świecie.
Moodle jest projektem typu open-source pisanym głównie w PHP. Bazuje na
koncepcji programowania modularnego – jest złożony z wielu modułów, z których
każdy jest odpowiedzialny za określony zestaw funkcjonalności. Zapewnia to łatwe
i wygodne rozwijanie serwisu.
3.4.1. Podstawowe możliwości systemu
1. Zapisywanie sie˛ na kursy:
a) po pozytywnym uwierzytelnieniu sie˛ do systemu lub jeśli jest to możliwe
jako gość użytkownik może samodzielnie zapisać sie˛ na kurs;
b) samodzielnie zapisywanie na kurs poprzez studentów może zostać wyła˛
czone;
c) zapisanie sie˛ na dany kurs może wymagać klucza dostepu,
˛
który to umożliwi;
d) nauczyciele z odpowiednimi prawami moga˛ zapisywać lub wypisywać studentów z kursu;
e) w systemie wymagane jest jedno konto – za pomoca˛ jednego konta można
zapisywać sie˛ na wiele kursów.
2. Role w systemie:
a) użytkownik może posiadać różne role w zależności od kontekstu, np.
kursu;
b) administrator kontroluje tworzenie kursów oraz tworzy nauczycieli poprzez
nadawanie użytkownikom roli nauczyciela w kontekście kursów;
c) standardowe role w systemie Moodle:
• twórca kursów – może tworzyć kursy, nauczać w nich oraz nadawać role˛
nauczyciela innym użytkownikom;
• nauczyciel – rola w konkretnym kursie;
• nauczyciel nie mogacy
˛ edytować kursów – rola mogaca
˛ być przydzielona,
np. dla adiunktów;
• uczeń – może uczestniczyć i przegladać
˛
aktywności w kursie, ale nie
może ich tworzyć;
• gość – użytkownik, który może tylko przegladać
˛
kursy w systemie.
3. Zarzadzanie
˛
kursami:
a) typowo nauczyciel posiada pełna˛ kontrole˛ nad ustawieniami kursu;
b) dla każdego kursu może zostać ustawiony inny motyw;
c) w skład kursu może wchodzić wiele aktywności: Fora, Quizy, Słowniczki,
Zasoby, Ankiety, Zadania, Czaty i Warsztaty;
d) ostatnie zmiany w kursie od ostatniego logowania użytkownika moga˛ być
wyświetlane na stronie głównej kursu;
e) integracja z poczta˛ – kopie wypowiedzi na forum czy ocena nauczyciela
może być wysyłana do użytkownika, użytkownik może ustawić dziennie
powiadomienia;
f) warunkowe aktywności – użytkownik może być do nich dopuszczony dopiero po spełnieniu pewnych kryteriów.
4. Podstawowe moduły:
3.4. Moodle
13
a) moduł do sporzadzania
˛
zadań dla uczniów:
• zadania moga˛ być specyfikowane z terminem oddania oraz maksymalna˛
możliwa˛ ocena;
˛
• uczniowie moga˛ wrzucić do systemu swoje rozwiazania,
˛
które bed
˛ a˛ oznaczone data˛ ich dostarczenia;
• oddanie zadania po czasie jest możliwe, ale długość spóźnienia jest
wyraźnie widoczna dla nauczyciela;
• dla szczególnych zadań cała klasa może zostać oceniona;
• nauczyciel może pozwolić na ponowne oddanie pracy i zdobycie przez
ucznia lepszej oceny.
b) moduł czatu:
• może być udoste˛ pniony dla każdego w danym kursie lub ograniczony do
członków grup lub ról;
• wspiera odnośniki URL, emotikony, obrazki itp.
c) moduł wyboru:
• przypomina w formie ankiete˛ z pojedynczym pytaniem, może być stosowany do głosowania lub zdobycia opinii od uczniów;
• nauczyciel ma możliwość podejrzenia kto i na co zagłosował.
d) moduł forum
• doste˛ pne sa˛ różne formy forum:
◦ wiadomości o kursie,
◦ fora ogólnodostepne
˛
– otwarte dla wszystkich,
◦ forum z jednym watkiem
˛
na użytkownika,
◦ forum typu pytanie/odpowiedź.
• wiadomości z forum moga˛ być wysyłane na poczte;
˛
• posty moga˛ mieć dołaczone
˛
zdjecia
˛
autorów;
• dyskusje moga˛ być wyświetlane w różnej formie – zagnieżdżone, płaskie
lub watkowe,
˛
poczynajac
˛ od najstarszej czy najnowszej wiadomości;
• istnieje możliwość zapisu na forum;
• watki
˛
dyskusji moga˛ być przemieszczane miedzy
˛
forami lub dzielone
przez nauczyciela;
• możliwe sa˛ oceny postów uczniów, które moga˛ mieć wpływ na ich oceny.
e) moduł słowniczka:
• pozwala uczniom ulepszać kurs poprzez umieszczanie w słowniczku
własnych pomysłów, które przed ich opublikowaniem może zweryfikować nauczyciel;
• słowniczek pozwala uczestnikom kursu tworzyć i utrzymywać liste˛ definicji jak to ma miejsce w zwykłym słowniku;
• wpisy w słowniczku moga˛ być wyszukiwane alfabetycznie, po kategorii,
dacie czy danym autorze;
• uczestnicy kursu moga˛ komentować wpisy w słowniczku.
f) moduł lekcji:
• lekcja stanowi pojedyncza˛ aktywność, w której uczniowi prezentowana
jest seria stron;
• uczeń decyduje o przebiegu lekcji poprzez dokonywane swoje wybory i
udzielone odpowiedzi podczas jej trwania;
• wybory i udzielone odpowiedzi na pytania przez ucznia moga˛ być oceniane i może być mu wystawiona indywidualna ocena;
• nauczyciel może decydować o różnych ustawieniach danej lekcji:
3.4. Moodle
14
◦ różny sposób oceniania lekcji odbytej przez ucznia,
◦ ustawienie ograniczeń czasowych, minimalnego rezultatu jak również
zliczanie prób uczniów oraz ponawianie lekcji w przypadku niepowodzenia.
g) moduł Quizu:
• quizy oferuja˛ wiele rodzajów pytań, rodzajów oceniania i prezentacji oraz
sa˛ automatycznie ocenianie tuż po ukończeniu;
˛
uczniom tylko w wybranym
• quiz można ustawić tak, aby był dostepny
oknie czasowym;
• pytania w quizie moga˛ być losowane w celu redukcji oszukiwania;
• nauczyciel może ustawić, aby do quizów można było podchodzić wiele
razy;
• istnieje ponad 10 rodzajów pytań, które moga˛ wystapić
˛
w quizie;
• pytania w quizie sa˛ przechowywane w kategoriach oraz sa˛ cześci
˛ a˛ bazy
danych (banku pytań);
• kategorie pytań moga˛ być tak ułożone w bazie danych, że moga˛ być
one użyte tylko w konkretnym quizie, kursie lub w dowolnym quizie na
stronie.
h) moduł zasobów:
• nauczyciel może wrzucać do kursu różnego rodzaju materiały, które
moga˛ później zobaczyć uczniowie zapisani na kurs;
• wrzucane przez nauczyciela materiały – pliki – sa˛ dostepne
˛
dla uczniów
w postaci odnośników do tych materiałów;
• w celu otwarcia niektórych materiałów wrzuconych przez nauczyciela
(zwykle plików be˛ dacych
˛
dokumentami w różnych formatach) trzeba
posiadać na komputerze odpowiednie oprogramowanie;
• pliki MP3, pliki wideo (z popularnych serwisów oraz ze znanymi formatami) sa˛ otwierane w odtwarzaczu Flash.
3.4.2. Podsumowanie
Moodle jest bardzo popularnym, stale rozwijanym i ciekawym środowiskiem do
nauki. System ten oferuje duże możliwości zarówno dla uczniów jak i nauczycieli
oraz zapewnia pomoc poprzez udostepnienie
˛
bardzo dobrej dokumentacji dla użytkowników systemu. Nauczyciele moga˛ w łatwy sposób tworzyć własne kursy, które
moga˛ dostosowywać do swoich potrzeb pod wieloma wzgledami.
˛
Uczniowie moga˛
brać aktywny udział w przebiegu kursu oraz stale sie˛ rozwijać, a nawet wpływać na
to, aby kurs z ich udziałem stawał sie˛ lepszy.
Ważnymi cechami systemu jest modułowa konstrukcja oraz współpraca z różnymi relacyjnymi bazami danych (MySQL, PostgreSQL, MS SQL 2005, Oracle i
inne). Jego popularność i przychylność użytkowników najlepiej świadcza˛ o tym, że
przed rozpocze˛ ciem pisania tego systemu podjeto
˛ bardzo dobre decyzje dotyczace
˛
implementacji.
4. Tworzony system e-learningowy
4.1. Specyfikacja i analiza wymagań
4.1.1. Wizja, zakres oraz cel projektu
Tworzony system be˛ dzie systemem e-learningowym umożliwiajacym
˛
miedzy
˛
innymi publikowanie materiałów multimedialnych (wideo oraz audio). Dostepna
˛
be˛
dzie również możliwość publikacji zwykłych informacji tekstowych.
Możliwość publikacji materiałów udostepniania
˛
bedzie
˛
wyłacznie
˛
zarejestrowanym nauczycielom. Dokonanie tego bedzie
˛
możliwe w obrebie
˛
kursu, który tworzyć
moga˛ wyłacznie
˛
nauczyciele. Ponadto materiały multimedialne bed
˛ a˛ również mogły
być publikowane jako niezwiazane
˛
z żadnym kursem – bed
˛ a˛ dostepne
˛
publicznie.
Uczniowie zarejestrowani w systemie bed
˛ a˛ mogli zapisywać sie˛ na kursy tworzone
przez nauczycieli.
System be˛ dzie systemem otwartym, to znaczy każdy bedzie
˛
mógł zarejestrować
si˛e jako nauczyciel lub uczeń. Każdy zalogowany nauczyciel może tworzyć własne
kursy i publikować na nich swoje materiały edukacyjne.
Podsumowujac,
˛ system ten bedzie
˛
systemem zarzadzania
˛
treścia˛ (CMS) zarówno
multimedialna˛ jak i tekstowa,
˛ z naciskiem na publikacje˛ materiałów multimedialnych. Publikacja materiałów bedzie
˛
najcześciej
˛
odbywała sie˛ w kontekście kursu
wcześniej utworzonego przez osobe˛ zarejestrowana˛ w systemie jako nauczyciel.
4.1.2. Role i aktorzy w systemie
Przewidziane role w systemie ze wzgledu
˛
na nauczanie na odległość to:
a) uczeń,
b) nauczyciel.
Aktorzy istniejacy
˛ w systemie:
a)
b)
c)
d)
gość,
uczeń,
nauczyciel,
administrator.
Rysunek 4.1. Relacje generalizacji miedzy
˛
aktorami w systemie
16
4.1. Specyfikacja i analiza wymagań
4.1.3. Wymagania funkcjonalne
a) gościa:
Id
Nazwa
Opis
Priorytet
1
Przegladanie
˛
kursów w
systemie
Każdy internauta odwiedzajacy
˛ serwis po
wybraniu danej kategorii kursu może
˛
w
obejrzeć tytuły i opisy kursów dostepnych
wybranej kategorii. Jeśli użytkownik bedzie
˛
chciał zapisać sie˛ na kurs musi on być
zalogowany w systemie. Gość ma możliwość
obejrzenia zawartości kursów, które bed
˛ a˛
oznaczone jako publiczne.
1
2
Przegladanie
˛
zawartości
kursu
Gość może obejrzeć zawartość kursów, które
posiadaja˛ status publicznych.
1
3
Rejestracja
nowego
użytkownika
Każda osoba odwiedzajaca
˛ serwis, który
bedzie
˛
dostepny
˛
przez przegladark
˛
e˛
internetowa˛ może zarejestrować sie˛ jako
uczeń lub nauczyciel używajac
˛ do tego
swojego e-maila jako identyfikatora. Po
pomyślnej rejestracji na podany e-mail
zostanie wysłany odnośnik do aktywacji
konta w systemie.
1
4
Wyszukiwanie
materiałów w
systemie
Gość może wyszukać w systemie materiały,
które zostały opublikowane jako materiały
publiczne. Materiał może zostać
opublikowany jako publiczny zarówno w
obrebie
˛
kursu jak i poza nim.
1
5
Filtrowanie
materiałów w
systemie
Gość może filtrować materiały poprzez
stosowne filtry udostepnione
˛
mu przez
system.
1
6
Ogladanie
˛
i
słuchanie
materiałów
Każda osoba, również bez rejestracji, ma
dostep
˛ do materiałów udostepnianych
˛
publicznie poprzez ich wyszukanie, a
nastepnie
˛
wybranie do odtworzenia.
1
b) ucznia - posiada możliwości gościa oraz:
Id
Nazwa
Opis
1
Zarzadzanie
˛
kontem
Wymagania dotyczace
˛ zarzadzania
˛
kontem
w systemie e-learningowym.
Priorytet
17
4.1. Specyfikacja i analiza wymagań
1.1
Przegladanie
˛
konta
Po kliknieciu
˛
w odpowiedni odnośnik uczeń
po uprzednim zalogowaniu sie˛ do systemu
be˛ dzie miał możliwość przegladania
˛
danych
zwiazanych
˛
ze swoim kontem.
2
1.2
Edycja
danych konta
użytkownika
Uczeń może dokonać zmiany dowolnych
danych osobowych zwiazanych
˛
ze swoim
kontem.
2
2
Funkcje
doste˛ powe do
systemu
Wymagania dotyczace
˛ dostepu
˛
do systemu.
2.1
Logowanie
użytkownika
Zarejestrowany uczeń w systemie może
zalogować sie˛ do systemu podajac
˛
poprawnie swój e-mail oraz hasło.
1
2.2
Wylogowanie
użytkownika
Uczeń po zalogowaniu sie˛ do systemu może
w dowolnej chwili sie˛ z niego wylogować.
1
3
Zarzadzanie
˛
kursami
Wymagania zwiazane
˛
z możliwościami
dotyczacymi
˛
kursów w systemie.
3.1
Przegladanie
˛
kursów
ucznia
Po kliknieciu
˛
w odpowiedni odnośnik uczeń
be˛ dzie mógł obejrzeć na jakie kursy jest
zapisany.
1
3.2
Przegladanie
˛
zawartości
kursu
Po kliknieciu
˛
w kurs, na który jest zapisany
uczeń może obejrzeć zawartość wybranego
kursu.
1
3.3
Zapisywanie
sie˛ na kurs
Uczeń może samodzielnie zapisać sie˛ na
kurs, który taka˛ możliwość udostepnia.
˛
Zapisanie sie˛ na kurs może wymagać klucza,
który ustala nauczyciel przy tworzeniu
kursu i może go udostepnić
˛
swoim uczniom.
1
4
Ogladanie
˛
i
słuchanie
materiałów w
obre˛ bie kursu
Uczeń po zapisaniu sie˛ na kurs może
ogladać
˛
oraz słuchać materiały w nim
umieszczane, również te które sa˛ prywatne,
tzn. dostepne
˛
tylko dla uczniów zapisanych
na dany kurs.
1
c) nauczyciela - ma podstawowe możliwości takie same jak uczeń oraz dodatkowo:
Id
Nazwa
Opis
1
Zarzadzanie
˛
kursami
Wymagania zwiazane
˛
z możliwościami
dotyczacymi
˛
kursów w systemie.
Priorytet
18
4.1. Specyfikacja i analiza wymagań
1.1
Tworzenie
nowego kursu
Nauczyciel może podjać
˛ akcje˛ utworzenia
nowego kursu, na który bed
˛ a˛ mogli sie˛
zapisywać uczniowie. Po opublikowaniu
kursu przez nauczyciela jego kurs zostanie
dodany do bazy danych oraz bedzie
˛
dostepny
˛
pod konkretna˛ kategoria,
˛ która˛
wybiera nauczyciel w trakcie tworzenia
kursu.
1
1.1.1
Dodawanie
sekcji do
kursu
Nauczyciel może dodawać do kursu sekcje w
celu podziału kursu na cześci.
˛
Materiały
bed
˛ a˛ dodawane do kursu w obrebie
˛
wybranej, wcześniej utworzonej sekcji.
1
1.1.2
Dodawanie
materiałów
wideo i audio
Podczas tworzenia kursu nauczyciel bedzie
˛
mógł po wciśnieciu
˛
odpowiedniego przycisku
wskazać cheć
˛ dodania materiału
multimedialnego do kursu. Po wybraniu
pliku proces wysyłania pliku na serwer oraz
jego postep
˛ bedzie
˛
widoczny w przegladarce.
˛
1
1.1.3
Dodawanie
materiałów
tekstowych
Podczas tworzenia kursu nauczyciel bedzie
˛
mógł dodać tekst do kursu poprzez wybranie
odpowiedniego przycisku i wpisanie
informacji w odpowiednie pole tekstowe.
2
1.2
Przegladanie
˛
prowadzonych
kursów
Nauczyciel oprócz przegladania
˛
kursów, na
które jest zapisany może również obejrzeć
liste˛ kursów, które w danej chwili prowadzi.
1
1.3
Edycja
danych kursu
Użytkownik bed
˛ acy
˛ nauczycielem może
zmienić dane o kursie.
1
1.4
Usuwanie
prowadzonych
kursów
Nauczyciel może usunać
˛ dowolny kurs,
który jest przez niego prowadzony.
1
1.5
Usuwanie
sekcji z kursu
Nauczyciel może usuwać sekcje wraz ze
wszystkimi danymi, które zostały w niej
uprzednio umieszczone.
1
1.6
Usuwanie
materiałów
multimedialnych z
kursu
Nauczyciel może dokonać usuniecia
˛
materiałów wideo i audio, które wcześniej
dodał do danej sekcji.
1
1.7
Usuwanie
materiałów
tekstowych z
kursu
Nauczyciel może dokonać usuniecia
˛
dowolnego materiału tekstowego z wybranej
sekcji.
1
19
4.1. Specyfikacja i analiza wymagań
2
Zarzadzanie
˛
materiałami
multimedialnymi
Wymagania zwiazane
˛
z możliwościami
dotyczacymi
˛
materiałów wideo i audio w
systemie.
2.1
Przegladanie
˛
opublikowanych
materiałów
System umożliwia nauczycielowi
przegladanie
˛
wszystkich jego materiałów,
które dodał do systemu.
2
2.2
Dodawanie
materiałów
wideo i audio
Nauczyciel posiada możliwość dodawania
materiałów do systemu, które nie sa˛
powiazane
˛
z żadnym kursem. W tym
przypadku automatycznie sa˛ one publicznie
dostepne.
˛
2
2.3
Wyświetlenie
materiałów w
trybie
zarzadzania
˛
Nauczyciel może wyświetlić materiały w
sposób umożliwiajacy
˛ podjecie
˛
pewnych
akcji dla każdego materiału.
2
2.4
Ogladanie
˛
i
słuchanie
materiałów
Nauczyciel może obejrzeć dowolny materiał,
który został przez niego dodany do systemu.
2
2.5
Edycja
danych
zwiazanych
˛
z
materiałem
Po dodaniu materiału do systemu dane
dotyczace
˛ materiału moga˛ zostać zmienione.
2
2.6
Usunie˛ cie
materiału z
systemu
System pozwala usunać
˛ dowolny materiał
nauczyciela.
2
2.7
Wyszukiwanie
i filtrowanie
materiałów
Nauczyciel może dokonać wyszukania oraz
filtracji posiadanych materiałów.
2
3
Zarzadzanie
˛
zapisami
Wymagania zwiazane
˛
z możliwościami
dotyczacymi
˛
zapisów na kursy, które
posiada nauczyciel.
3.1
Zapisywanie
uczniów na
kurs
Nauczyciel może dokonywać zapisów
uczniów na kursy, które posiadaja˛ określony
rodzaj zapisów.
1
3.2
Wypisywanie
uczniów z
kursu
Nauczyciel może dokonywać wypisów
uczniów z kursów, które posiadaja˛
określony rodzaj zapisów.
1
20
4.1. Specyfikacja i analiza wymagań
d) administratora:
Id
Nazwa
Opis
Priorytet
1
Zarzadzanie
˛
kontami
użytkowników
Wymagania określajace
˛ możliwości
zarzadzania
˛
kontami użytkowników
udostepnione
˛
dla administratora systemu.
1.1
Przegladanie
˛
użytkowników
Administrator może przejrzeć wszystkich
użytkowników w systemie.
1
1.2
Dodawanie
nowych
użytkowników
Administrator może dodać pełnoprawnego
użytkownika do systemu.
1
1.3
Usuwanie
kont
użytkowników
Administrator może dokonać usuniecia
˛
konta dowolnego użytkownika w systemie.
1
1.4
Edycja kont
użytkowników
Administrator może edytować dane zwiazane
˛
z kontami użytkowników w dowolnym
zakresie.
2
1.5
Wyszukiwanie
i filtrowanie
użytkowników
Nauczyciel może dokonać wyszukania oraz
filtracji kont użytkowników w systemie.
2
2
Zarzadzanie
˛
kursami
Wymagania dotyczace
˛ możliwości
administratora zwiazanych
˛
z kursami w
systemie.
2.1
Przegladanie
˛
kursów
Administrator może przegladać
˛
wszystkie
kursy w systemie.
2
2.2
Usuwanie
kursów
Administrator może usunać
˛ kurs z systemu
wraz ze wszystkimi danymi, które sa˛
zwiazane
˛
z tym kursem.
2
2.3
Edycja
kursów
istniejacych
˛
w
systemie
Administrator może zmienić zawartość
dowolnego kursu podobnie jak to czyni
nauczyciel z prowadzonym kursem.
3
2.4
Wyszukiwanie
i filtrowanie
kursów
Nauczyciel może dokonać wyszukania oraz
filtracji kursów w systemie.
2
3
Zarzadzanie
˛
materiałami
wideo i audio
Wymagania określajace
˛ jakich czynności
może dokonać administrator z dostepnymi
˛
w
systemie materiałami wideo i audio.
3.1
Przegladanie
˛
materiałów w
systemie
Administrator może przegladać
˛
wszystkie
materiały w systemie.
1
3.2
Usuwanie
materiałów z
systemu
Administrator może usunać
˛ dowolny
wskazany materiał z systemu.
1
21
4.1. Specyfikacja i analiza wymagań
3.3
Zmiana
metadanych
zwiazanych
˛
z
materiałem
Administrator może zmienić określone dane
dotyczace
˛ wybranego materiału.
2
3.4
Wyszukiwanie
i filtrowanie
materiałów
Administrator może dokonać wyszukania
oraz filtracji materiałów w systemie.
2
3
Zarzadzanie
˛
materiałami
wideo i audio
Wymagania określajace
˛ jakich czynności
może dokonać administrator z dostepnymi
˛
w
systemie materiałami wideo i audio.
3.1
Przegladanie
˛
materiałów w
systemie
Administrator może przegladać
˛
wszystkie
materiały w systemie.
1
3.2
Usuwanie
materiałów z
systemu
Administrator może usunać
˛ dowolny
wskazany materiał z systemu.
1
3.3
Zmiana
metadanych
zwiazanych
˛
z
materiałem
Administrator może zmienić określone dane
dotyczace
˛ wybranego materiału.
2
3.4
Wyszukiwanie
i filtrowanie
materiałów
Administrator może dokonać wyszukania
oraz filtracji materiałów w systemie.
2
4
Statystyki
systemowe
Wymagania określajace
˛ zakres śledzenia
systemu oraz statystyki, do których ma
dostep
˛ administrator.
4.1
Przegladanie
˛
statystyk
ilościowych
Administrator może przegladać
˛
ilość różnych
bytów w systemie (użytkowników, kursów,
materiałów).
1
4.2
Przegladanie
˛
statystyk
doste˛ pu do
systemu
Administrator może przejrzeć logi dostepu
˛
do systemu (logowanie i wylogowanie).
1
4.3
Przegladanie
˛
zasobów
systemu
Administrator może zobaczyć ilość zasobów
wykorzystywanych przez użytkowników.
1
22
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
4.1.4. Wymagania niefunkcjonalne
Id
Nazwa
Opis
Priorytet
1
Bezpieczeństwo
Tylko administrator systemu może dokonać
usuniecia
˛
konta innego użytkownika, czyli
nauczyciela lub ucznia. Inni użytkownicy
systemu maja˛ prawo wyłacznie
˛
do edycji
własnego konta.
1
2
Wymagania
systemowe
System bedzie
˛
napisany w jezyku
˛
PHP oraz
be˛ dzie realizowany w architekturze aplikacji
internetowej. Aplikacja bedzie
˛
napisana w
oparciu o framework Yii. Serwerem WWW
bedzie
˛
Apache działajacy
˛ na systemie
linuksowym. Baza˛ danych bedzie
˛
jedna z
darmowych, relacyjnych silników
bazodanowych dostepnych
˛
na rynku.
1
3
Przyjazny
interfejs
graficzny
użytkownika
System umożliwia w prosty sposób
przegladanie
˛
dostepnych
˛
kursów,
przegladanie
˛
własnego konta oraz przede
wszystkim kursów, na który jest zapisany
dany użytkownik.
1
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
a) gościa:
PUG1. Przegladanie
˛
kursów w systemie (właczane
˛
przez PUU7)
Opis: Przegladanie
˛
kursów dostepnych
˛
w systemie w danej chwili.
Scenariusz główny:
1.
2.
3.
4.
Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
System wyświetla dostepne
˛
kategorie kursów w systemie.
Użytkownik wybiera kategorie,
˛ w obrebie
˛
której chce przegladać
˛
kursy.
System wyświetla pierwsza˛ strone˛ rezultatów z kursami w wybranej
kategorii. Kolejne strony sa˛ dostepne
˛
poprzez numerowane odnośniki.
Na jednej stronie znajduje˛ sie˛ 25 kursów.
PUG2. Przegladanie
˛
zawartości kursu (rozszerza PUG1 po ostatnim kroku)
Opis: Przegladanie
˛
zawartości kursu, który posiada status publiczny.
Scenariusz główny:
1. Użytkownik wciska odpowiedni odnośnik obok kursu, który chce obejrzeć.
2. System wyświetla zawartość wybranego kursu.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
23
Rysunek 4.2. Diagram przypadków użycia dla gościa
PUG3. Rejestracja nowego użytkownika
Opis: Rejestracja w systemie nowego użytkownika o określonej roli.
Scenariusz główny:
1. Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
2. System wyświetla formularz rejestracyjny.
3. Użytkownik poprawnie wypełnia formularz i zatwierdza wprowadzone
dane (RB1).
4. System potwierdza otrzymanie danych i wysyła e-maila aktywacyjnego
na podana˛ skrzynke˛ pocztowa.
˛
5. Nowy użytkownik aktywuje swoje konto (PUG4).
Scenariusz alternatywny 1 – użytkownik podał e-mail istniejacy
˛ w systemie:
1–2. Jak w scenariuszu głównym.
3. Użytkownik wypełnia i zatwierdza formularz podajac
˛ identyfikator e-mail istniejacy
˛ już w systemie.
4. System powiadamia użytkownika o zajetym
˛
e-mailu.
5. Powrót do kroku 2 scenariusza głównego.
PUG4. Aktywacja konta w systemie (właczane
˛
przez PUG3)
Opis: Aktywacja konta w systemie po tym jak nowy użytkownik pomyślnie
uzupełnił i zatwierdził formularz rejestracyjny.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
24
Scenariusz główny:
1. Użytkownik otwiera odnośnik aktywacyjny wysłany na jego skrzynke˛
pocztowa.
˛
2. System tworzy nowego, pełnoprawnego użytkownika umożliwiajac
˛ mu
doste˛ p do systemu poprzez funkcje dostepowe
˛
(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żytkownik wpisuje tekst do wyszukania w głównym polu wyszukiwarki
i zatwierdza wprowadzone dane.
2. System wyświetla pierwsza˛ strone˛ rezultatów z materiałami wideo i
audio, które spełniaja˛ kryteria wyszukiwania (RB2). Kolejne strony sa˛
doste˛ pne poprzez numerowane odnośniki. Na jednej stronie znajduje˛
sie˛ 10 materiałów.
PUG6. Filtrowanie materiałów wideo i audio w systemie (rozszerza PUG5
po ostatnim kroku)
Opis: Użytkownik może dokonać zawe˛ żenia wyników wyszukiwania poprzez
zastosowanie filtrów udostepnionych
˛
przez system.
Scenariusz główny:
1. Użytkownik wybiera jeden z dostepnych
˛
filtrów materiałów.
2. System wyświetla pierwsza˛ strone˛ rezultatów z materiałami wideo i audio, które spełniaja˛ kryteria wyszukiwania i filtrowania wybrane przez
użytkownika (RB2 i RB3). Kolejne strony sa˛ dostepne
˛
poprzez numerowane odnośniki. Na jednej stronie znajduje˛ sie˛ 10 materiałów.
PUG7. Ogladanie
˛
i słuchanie materiałów (rozszerza PUG5 po ostatnim kroku
lub PUG2 po ostatnim kroku)
Opis: Ogladanie
˛
i słuchanie materiałów multimedialnych posiadajacych
˛
status publicznych.
Scenariusz główny:
1. Wyszukanie materiału multimedialnego (PUG5).
2. Spośród wyświetlonych rezultatów użytkownik wybiera materiał do odtworzenia.
3. System wyświetla dane zwiazane
˛
z wybranym materiałem oraz zaczyna
odtwarzać materiał.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
25
b) ucznia:
PUU1. Przegladanie
˛
konta
Opis: Użytkownik zalogowany w systemie może przejrzeć dane zwiazane
˛
z jego
kontem w systemie.
Scenariusz główny:
1. Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
2. System wyświetla dane zwiazane
˛
z użytkownikiem w postaci dwóch
formularzy (RB4).
Rysunek 4.3. Diagram przypadków użycia dla ucznia
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
PUU2.
26
Edycja danych konta użytkownika (rozszerza PUU1 po ostatnim
kroku)
Opis: Zalogowany użytkownik może zmienić swoje dane, które pierwotnie
wprowadził w formularzu rejestracyjnym podczas procesu rejestracji.
Scenariusz główny:
1. Użytkownik zmienia swoje dane i zatwierdza formularz.
2. System potwierdza pomyślna˛ zmiane˛ danych użytkownika.
Scenariusz alternatywny 1 – użytkownik zmienia swój e-mail:
1. Użytkownik zmienia i zatwierdza formularz podajac
˛ unikalny e-mail.
2. System wylogowuje użytkownika z systemu i wyświetla formularz logowania.
Scenariusz alternatywny 2 – użytkownik podał e-mail istniejacy
˛ w systemie:
1. Użytkownik zmienia i zatwierdza formularz podajac
˛ identyfikator e-mail istniejacy
˛ już w systemie.
2. System powiadamia użytkownika o zajetym
˛
e-mailu.
PUU3. Logowanie użytkownika
Opis: Logowanie użytkownika do systemu dajace
˛ mu dostep
˛ do określonych
funkcji w zależności od posiadanej roli w systemie.
Scenariusz główny:
1.
2.
3.
4.
5.
6.
Użytkownik naciska odpowiedni odnośnik służacy
˛ logowaniu.
System wyświetla formularz logowania.
Użytkownik wprowadza identyfikator (e-mail) oraz hasło.
Użytkownik zatwierdza wprowadzone dane.
System przeprowadza logowanie użytkownika.
System wyświetla strone˛ główna˛ aplikacji oraz menu bogatsze w opcje
w zależności od roli pełnionej przez zalogowanego użytkownika.
Scenariusz alternatywny 1 – użytkownik wprowadza nieistniejacy
˛ e-mail:
1–2.
3.
4.
5.
6.
Jak w scenariuszu głównym.
Użytkownik wprowadza hasło oraz e-mail nieistniejacy
˛ w systemie.
Użytkownik zatwierdza formularz logowania.
System wyświetla informacje˛ o nieistniejacym
˛
identyfikatorze.
Powrót do kroku 2 scenariusza głównego.
Scenariusz alternatywny 2 – użytkownik wprowadza złe hasło:
1–2.
3.
4.
5.
6.
Jak w scenariuszu głównym.
Użytkownik wprowadza swój e-mail oraz nieprawidłowe hasło.
Użytkownik zatwierdza formularz logowania.
System wyświetla informacje˛ o nieprawidłowym haśle.
Powrót do kroku 2 scenariusza głównego.
PUU4. Wylogowanie użytkownika
Opis: Wylogowanie użytkownika z systemu kończy sesje˛ użytkownika w systemie.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
27
Scenariusz główny:
1. Użytkownik naciska odpowiedni odnośnik służacy
˛ wylogowaniu.
2. System przeprowadza wylogowanie użytkownika.
3. System wyświetla strone˛ główna˛ aplikacji oraz menu główne dostepne
˛
dla niezalogowanego użytkownika (gościa).
PUU5. Przegladanie
˛
kursów ucznia (właczane
˛
przez PUU6)
Opis: Funkcja systemu umożliwiajaca
˛ uczniowi przegladanie
˛
kursów, na której jest w danej chwili zapisany.
Scenariusz główny:
1. Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
2. System wyświetla opcje dostepne
˛
dla ucznia.
3. Użytkownik wybiera przycisk do wyświetlenia kursów, na które jest
zapisany.
4. System wyświetla liste˛ kursów, na które jest zapisany dany użytkownik
(RB5).
PUU6. Przegladanie
˛
zawartości kursu (właczane
˛
przez PUU8)
Opis: Uczeń ma doste˛ p do kursów, na które jest zapisany i może je swobodnie
przegladać.
˛
Scenariusz główny:
1. Wyświetlenie kursów, na które jest zapisany uczeń (PUU5).
2. Użytkownik wybiera do wyświetlenia jeden spośród kursów, na które
jest zapisany.
3. System wyświetla zawartość kursu.
PUU7. Zapisywanie sie˛ na kurs
Opis: Uczeń może dokonać samodzielnego zapisu na kurs, który to umożliwia.
Scenariusz główny:
1. Przegladanie
˛
kursów w systemie (PUG1).
2. Użytkownik wciska odpowiedni odnośnik obok kursu, na który chce sie˛
zapisać.
3. System zapisuje użytkownika na kurs.
4. System wyświetla informacje˛ o pozytywnym zapisaniu sie˛ na kurs.
Scenariusz alternatywny 1 – użytkownik jest już zapisany na kurs:
1–2. Jak w scenariuszu głównym.
3. System wyświetla informacje˛ o tym, iż użytkownik jest już zapisany na
wybrany kurs.
Scenariusz alternatywny 2 – brak miejsc wolnych do zapisu:
1–2. Jak w scenariuszu głównym.
3. System wyświetla informacje˛ o tym, iż brak jest wolnych miejsc na
zapisanie sie˛ na kurs.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
28
Scenariusz alternatywny 3 – wymagany kod dostepu
˛
do zapisu, użytkownik
podał prawidłowy kod dostepu:
˛
1–2.
3.
4.
5.
6.
Jak w scenariuszu głównym.
System wyświetla okno do wprowadzenia kodu dostepu.
˛
Użytkownik wprowadza i zatwierdza prawidłowy kod dostepu.
˛
System zapisuje użytkownika na kurs.
System wyświetla informacje˛ o pozytywnym zapisaniu sie˛ na kurs.
Scenariusz alternatywny 4 – wymagany kod dostepu
˛
do zapisu, użytkownik
podał nieprawidłowy kod dostepu:
˛
1–2.
3.
4.
5.
Jak w scenariuszu głównym.
System wyświetla okno do wprowadzenia kodu dostepu.
˛
Użytkownik wprowadza i zatwierdza błedny
˛
kod dostepu.
˛
System wyświetla informacje˛ o podaniu nieprawidłowego kodu dostepu.
˛
PUU8. Ogladanie
˛
i słuchanie materiałów w kursie
Opis: Uczeń może ogladać
˛
i słuchać materiały umieszczone w kursach, na
które jest zapisany.
Scenariusz główny:
1. Wyświetlenie zawartości kursu (PUU6).
2. Użytkownik wybiera materiał multimedialny, który chce obejrzeć.
3. System wyświetla dane zwiazane
˛
z wybranym materiałem oraz zaczyna
odtwarzać materiał.
c) nauczyciela:
PUN1. Tworzenie nowego kursu
Opis: Tworzenie nowego kursu w systemie.
Scenariusz główny:
1.
2.
3.
4.
5.
6.
7.
Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
System wyświetla opcje dostepne
˛
dla nauczyciela.
Użytkownik wciska przycisk inicjujacy
˛ dodawanie kursu do systemu.
System wyświetla formularz do tworzenia kursu.
Użytkownik wypełnia dane dotyczace
˛ kursu i zatwierdza formularz.
System dodaje nowy kurs do systemu.
System wyświetla panel do edycji kursu udostepniany
˛
dla nauczycieli
(PUN2).
PUN2. Wyświetlenie kursu z panelem edycyjnym (rozszerza PUN7 po ostatnim kroku oraz właczane
˛
przez PUN1)
Opis: Wyświetlenie kursu wraz z panelem do jego edycji, który jest udostep˛
niony użytkownikom posiadajacym
˛
w systemie role˛ nauczyciela.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
29
Rysunek 4.4. Diagram przypadków użycia dla nauczyciela - cze˛ ść 1
Scenariusz główny:
1. System wyświetla zawartość kursu wraz z interfejsem do jego edycji oraz
danych powiazanych
˛
z 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żytkownik wybiera zakładke˛ z formularzem do dodawania sekcji do
kursu.
2. System prezentuje formularz do dodawania sekcji.
3. Użytkownik wpisuje tytuł nowej sekcji i zatwierdza formularz.
4. System dodaje nowa˛ sekcje˛ do kursu.
5. System wyświetla informacje˛ o pomyślnym dodaniu sekcji do kursu.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
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żytkownik wybiera zakładke˛ z formularzem do dodawania materiałów
multimedialnych do kursu.
2. System prezentuje interfejs do dodawania multimediów.
3. Użytkownik wybiera pliki do wysłania z lokalnego systemu plików.
4. Użytkownik zatwierdza cheć
˛ wysłania wybranych plików.
5. System odbiera pliki i wyświetla informacje˛ o pomyślnym odbiorze plików.
6. System dokonuje przetwarzania plików.
7. System wyświetla informacje o pomyślnym 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 wyświetla informacje˛ o nieprawidłowych plikach.
Scenariusz alternatywny 2 – nieobsługiwany plik:
1–4. Jak w scenariuszu głównym.
5. System odbiera pliki i wyświetla informacje˛ o nieobsługiwanych plikach.
PUN5.
Dodawanie materiałów tekstowych (rozszerza PUN2 po ostatnim
kroku)
Opis: Dodawanie materiałów zawierajacych
˛
zwykły tekst.
Scenariusz główny:
1. Użytkownik wybiera zakładke˛ z formularzem do dodawania materiałów
tekstowych do kursu.
2. System wyświetla formularz do dodawania materiałów tekstowych.
3. Użytkownik uzupełnia dane materiału tekstowego.
4. Użytkownik zatwierdza formularz z wprowadzonymi danymi.
5. System dodaje nowy materiał tekstowy do wybranej sekcji.
6. System wyświetla informacje˛ o pomyślnym 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.
2.
3.
4.
5.
Użytkownik wybiera zakładke˛ z formularzem do edycji danych kursu.
System wyświetla formularz do edycji danych kursu.
Użytkownik zmienia dane dotyczace
˛ kursu.
Użytkownik zatwierdza formularz.
System wyświetla informacje o pomyślnej zmianie danych kursu.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
31
PUN7. Przegladanie
˛
prowadzonych kursów
Opis: Przegladanie
˛
kursów utworzonych przez nauczyciela.
Scenariusz główny:
1.
2.
3.
4.
Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
System wyświetla opcje dostepne
˛
dla nauczyciela.
Użytkownik wciska przycisk do wyświetlenia prowadzonych kursów.
System wyświetla kursy nauczyciela.
PUN8. Usuniecie
˛
kursu (rozszerza PUN7 po ostatnim kroku)
Opis: Usunie˛ cie kursu prowadzonego przez nauczyciela.
Scenariusz główny:
1. Użytkownik wciska przycisk do usuniecia
˛
kursu znajdujacy
˛ sie˛ obok
danego kursu na liście kursów.
2. System usuwa kurs z systemu.
PUN9. Usuniecie
˛
sekcji z kursu (rozszerza PUN7 po ostatnim kroku oraz
PUA10 po ostatnim kroku)
Opis: Usunie˛ cie sekcji wraz ze wszystkimi danymi, które sie˛ w niej znajduja.
˛
Scenariusz główny:
1. Użytkownik wybiera i naciska przycisk służacy
˛ do usuwania sekcji.
2. System usuwa desygnowana˛ sekcje˛ z kursu.
PUN10. Usuniecie
˛
materiału wideo lub audio z kursu (rozszerza PUN7 po
ostatnim kroku oraz PUA10 po ostatnim kroku)
Opis: Usunie˛ cie wybranego materiału multimedialnego umieszczonego w konkretnej sekcji.
Scenariusz główny:
1. Użytkownik wybiera i naciska przycisk służacy
˛ do usuwania materiału.
2. System usuwa wybrany materiał z kursu.
PUN11. Usuniecie
˛
materiału tekstowego z kursu (rozszerza PUN7 po ostatnim kroku oraz PUA10 po ostatnim kroku)
Opis: Usunie˛ cie materiałów zawierajacych
˛
zwykły tekst w kursie.
Scenariusz główny:
1. Użytkownik wybiera i naciska przycisk służacy
˛ do usuwania materiału
tekstowego.
2. System usuwa wybrany materiał tekstowy z kursu.
PUN12. Przegladanie
˛
opublikowanych materiałów
Opis: Przegladanie
˛
materiałów, które zostały dodane przez zalogowanego nauczyciela.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
32
Rysunek 4.5. Diagram przypadków użycia dla nauczyciela - cze˛ ść 2
Scenariusz główny:
1. Użytkownik wybiera odpowiednia˛ zakładke˛ z menu głównego aplikacji.
2. System wyświetla materiały nauczyciela z podziałem na strony. Kolejne
strony sa˛ doste˛ pne przez numerowane odnośniki. Na każdej stronie
znajduje˛ sie˛ 25 materiałów.
PUN13. Dodawanie materiałów wideo i audio (rozszerza PUN12 po ostatnim
kroku)
Opis: Dodawanie materiałów multimedialnych niezwiazanych
˛
z żadnym kursem w systemie.
Scenariusz główny:
1. Użytkownik wybiera opcje˛ dodawania materiałów do systemu.
2. System prezentuje formularz do dodawania multimediów.
3. Użytkownik wybiera pliki do wysłania z lokalnego systemu plików.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
33
4. Użytkownik zatwierdza cheć
˛ wysłania wybranych plików.
5. System odbiera pliki i wyświetla informacje˛ o pomyślnym odbiorze plików.
6. System dokonuje przetwarzania plików.
7. System wyświetla informacje o pomyślnym 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 wyświetla informacje˛ o nieprawidłowych plikach.
Scenariusz alternatywny 2 – nieobsługiwany plik:
1–4. Jak w scenariuszu głównym.
5. System odbiera pliki i wyświetla informacje˛ o nieobsługiwanych plikach.
PUN14. Wyświetlenie materiałów w trybie zarzadzania
˛
(rozszerza PUN12
po ostatnim kroku)
Opis: Wyświetlenie materiałów wraz z interfejsem do zmiany każdego materiału z osobna.
Scenariusz główny:
1. Użytkownik wybiera opcje˛ do zarzadzania
˛
materiałami.
2. System wyświetla materiały nauczyciela z podziałem na strony. Kolejne
strony sa˛ doste˛ pne przez numerowane odnośniki. Na każdej stronie
znajduje˛ sie˛ 25 materiałów. Obok każdego materiału znajduja˛ sie˛ opcje
do jego zmiany.
PUN15. Ogladanie
˛
i słuchanie materiałów (rozszerza PUN14 po ostatnim
kroku)
Opis: Ogladanie
˛
i słuchanie materiałów posiadanych przez nauczyciela.
Scenariusz główny:
1. Spośród listy materiałów użytkownik wybiera materiał, który chce obejrzeć.
2. System wyświetla dane zwiazane
˛
z wybranym materiałem oraz zaczyna
odtwarzać materiał.
PUN16. Edycja danych zwiazanych
˛
z materiałem (rozszerza PUN14 po
ostatnim kroku)
Opis: Edycja danych dotyczacych
˛
wybranego materiału.
Scenariusz główny:
1. Spośród listy materiałów użytkownik wybiera materiał, którego dane
chce zmienić.
2. System wyświetla formularz do zmiany materiału.
3. Użytkownik zmienia dane materiału i zatwierdza formularz.
4. System wyświetla informacje o pomyślnej zmianie danych.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
34
PUN17. Usuniecie
˛
materiału z systemu (rozszerza PUN14 po ostatnim
kroku)
Opis: Usunie˛ cie wybranego materiału z systemu.
Scenariusz główny:
1. Spośród listy materiałów użytkownik wybiera materiał, który chce usunać.
˛
2. System wyświetla okno do potwierdzenia z pytaniem czy użytkownik na
pewno chce usunać
˛ wybrany materiał.
3. Użytkownik potwierdza cheć
˛ usuniecia
˛
materiału.
4. System usuwa materiał z systemu.
5. System wyświetla nowa˛ liste˛ materiałów.
Scenariusz alternatywny 1 – użytkownik anuluje usuwanie:
1–2. Jak w scenariuszu głównym.
3. Użytkownik anuluje 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żytkownik wprowadza szukana˛ wartość atrybutu materiału lub wybiera jeden z filtrów (RB7).
2. System wyświetla nowa˛ liste˛ materiałów.
PUN19. Wyświetlenie kursów umożliwiajacych
˛
zapisy (właczane
˛
przez
PUN20 i PU21)
Opis: Wyświetlenie kursów, których rodzaj zapisów umożliwia dokonywanie
zapisów przez nauczyciela.
Scenariusz główny:
1.
2.
3.
4.
Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
System wyświetla opcje dostepne
˛
dla nauczyciela.
Użytkownik wciska przycisk do dokonywania zapisów.
System wyświetla 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.
2.
3.
4.
5.
Użytkownik wybiera odpowiednia˛ zakładke˛ z głównego menu aplikacji.
System wyświetla opcje dostepne
˛
dla nauczyciela.
Użytkownik wciska przycisk inicjujacy
˛ zapisy.
Użytkownik wybiera kurs, na który chce dokonać zapisu.
Użytkownik wprowadza identyfikator ucznia, którego chce zapisać na
dany kurs.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
35
6. Użytkownik zatwierdza formularz do zapisu.
7. System zapisuje ucznia na kurs.
8. System wyświetla informacje o pomyślnym zapisie.
Scenariusz alternatywny 1 – podany e-mail nie istnieje w systemie:
1–3. Jak w scenariuszu głównym.
4. System wyświetla informacje o nieistniejacym
˛
identyfikatorze.
Scenariusz alternatywny 2 – użytkownik jest już zapisany na kurs:
1–3. Jak w scenariuszu głównym.
4. System wyświetla informacje o tym, iż użytkownik jest już zapisany na
wybrany kurs.
Scenariusz alternatywny 3 – brak wolnych miejsc:
1–3. Jak w scenariuszu głównym.
4. System wyświetla informacje o tym, iż 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żytkownik wybiera kurs, z którego chce dokonać wypisu.
2. Użytkownik wprowadza identyfikator ucznia, którego chce wypisać z
kursu.
3. Użytkownik zatwierdza formularz do wypisu.
4. System wypisuje ucznia z kursu.
5. System wyświetla informacje o pomyślnym wypisie.
Scenariusz alternatywny 1 – podany e-mail nie istnieje w systemie:
1–3. Jak w scenariuszu głównym.
4. System wyświetla informacje o nieistniejacym
˛
identyfikatorze.
Scenariusz alternatywny 2 – użytkownik nie jest zapisany na kurs:
1–3. Jak w scenariuszu głównym.
4. System wyświetla informacje o tym, iż użytkownik nie jest zapisany na
wybrany kurs.
d) administratora:
PUA1. Przegladanie
˛
użytkowników
Opis: Przegladanie
˛
kont użytkowników w systemie.
Scenariusz główny:
1. W celu otwarcia panelu administracyjnego użytkownik wybiera odpowiednia˛ zakładke˛ z menu głównego aplikacji.
2. System wyświetla panel administracyjny.
˛ do administrowania użytkowni3. Użytkownik wciska odnośnik służacy
kami.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
36
Rysunek 4.6. Diagram przypadków użycia dla administratora - cze˛ ść 1
4. System wyświetla pierwsza˛ strone˛ z użytkownikami w systemie. Kolejne
strony sa˛ doste˛ pne poprzez numerowane odnośniki. Na jednej stronie
znajduje˛ sie˛ 25 użytkowników.
PUA2. Dodawanie użytkowników do systemu (rozszerza PUA1 po ostatnim
kroku)
Opis: Dodawanie pełnoprawnych użytkowników do systemu (bez potrzeby
aktywacji konta poprzez link aktywacyjny).
Scenariusz główny:
1.
2.
3.
4.
5.
Użytkownik wybiera opcje˛ dodawania użytkownika do systemu.
System wyświetla formularz do dodawania użytkowników.
Użytkownik wypełnia i zatwierdza formularz.
System dodaje użytkownika do systemu.
System wyświetla informacje˛ o pomyślnym dodaniu użytkownika.
Scenariusz alternatywny 1 – e-mail nie jest unikalny:
1–3. Jak w scenariuszu głównym.
4. System wyświetla informacje,
˛ iż podany e-mail jest już używany.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
37
PUA3. Wyświetlenie użytkowników w trybie zarzadzania
˛
(właczane
˛
przez
PUA4, PUA5 i PUA6, rozszerza PUA1 po ostatnim kroku)
Opis: Wyświetlenie użytkowników wraz z opcjami zmiany każdego użytkownika.
Scenariusz główny:
1. Użytkownik wybiera opcje˛ zarzadzania
˛
użytkownikami w systemie.
2. System wyświetla pierwsza˛ strone˛ z użytkownikami w systemie. Kolejne
strony sa˛ doste˛ pne poprzez numerowane odnośniki. Na jednej stronie
znajduje˛ sie˛ 25 użytkowników. Obok każdego użytkownika znajduja˛ sie˛
opcje do jego zmiany.
PUA4. Usuniecie
˛
użytkownika z systemu
Opis: Usunie˛ cie użytkownika z systemu wraz ze wszystkimi danymi z nim
zwiazanymi.
˛
Scenariusz główny:
1. Wyświetlenie użytkowników w trybie zarzadzania
˛
(PUA3).
2. Spośród listy użytkowników użytkownik wybiera tego, którego chce
usunać.
˛
3. System wyświetla okno do potwierdzenia z pytaniem czy użytkownik na
pewno chce usunać
˛ wybranego użytkownika.
4. Użytkownik potwierdza cheć
˛ usuniecia
˛
użytkownika.
5. System usuwa użytkownika z systemu wraz ze wszystkimi jego danymi.
6. System wyświetla nowa˛ liste˛ użytkowników.
Scenariusz alternatywny 1 – użytkownik anuluje usuwanie:
1–3. Jak w scenariuszu głównym.
4. Użytkownik anuluje usuwanie użytkownika.
PUA5. Edycja danych użytkownika
Opis: Edycja danych zwiazanych
˛
z kontem wybranego użytkownika.
Scenariusz główny:
1. Wyświetlenie użytkowników w trybie zarzadzania
˛
(PUA3).
2. Spośród listy użytkowników użytkownik wybiera tego, którego chce
zmienić.
3. System wyświetla formularze do zmian danych użytkownika (RB9).
4. Użytkownika zatwierdza formularz.
5. System zmienia dane użytkownika.
6. System wyświetla informacje˛ o pomyślnej zmianie danych użytkownika.
Scenariusz alternatywny 1 – e-mail nie jest unikalny:
1–4. Jak w scenariuszu głównym.
5. System wyświetla informacje,
˛ iż podany e-mail jest już używany.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
38
PUA6. Wyszukiwanie i filtrowanie użytkowników
Opis: Wyszukiwanie i filtrowanie użytkowników ze wzgledu
˛
na wartości posiadanych atrybutów.
Scenariusz główny:
1. Wyświetlenie użytkowników w trybie zarzadzania
˛
(PUA3).
2. Użytkownik wprowadza szukana˛ wartość atrybutu użytkownika lub wybiera jeden z filtrów (RB10).
3. System wyświetla nowa˛ liste˛ użytkowników spełniajacych
˛
kryteria.
Rysunek 4.7. Diagram przypadków użycia dla administratora - cze˛ ść 2
PUA7. Przegladanie
˛
kursów
Opis: Przegladanie
˛
wszystkich kursów utworzonych w systemie.
Scenariusz główny:
1. W celu otwarcia panelu administracyjnego użytkownik wybiera odpowiednia˛ zakładke˛ z menu głównego aplikacji.
2. System wyświetla panel administracyjny.
3. Użytkownik wciska odnośnik służacy
˛ do administrowania kursami.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
39
4. System wyświetla pierwsza˛ strone˛ z kursami w systemie. Kolejne strony
sa˛ doste˛ pne poprzez numerowane odnośniki. Na jednej stronie znajduje˛
sie˛ 25 kursów.
PUA8. Wyświetlenie kursów w trybie zarzadzania
˛
(rozszerza PUA7 po ostatnim kroku, właczane
˛
przez PUA9, PUA10, PUA11)
Opis: Wyświetlenie kursów wraz z opcjami do zmiany każdego kursu z osobna.
Scenariusz główny:
1. Użytkownik wybiera opcje˛ zarzadzania
˛
kursami w systemie.
2. System wyświetla pierwsza˛ strone˛ z kursami w systemie. Kolejne strony
sa˛ doste˛ pne poprzez numerowane odnośniki. Na jednej stronie znajduje˛
sie˛ 25 kursów. Obok każdego kursu znajduja˛ sie˛ opcje do jego zmiany.
PUA9. Usuwanie kursów
Opis: Usunie˛ cie dowolnego kursu istniejacego
˛
w systemie wraz ze wszystkimi
powiazanymi
˛
danymi.
Scenariusz główny:
1. Wyświetlenie kursów w trybie zarzadzania
˛
(PUA8).
2. Spośród listy kursów użytkownik wybiera kurs, który chce usunać.
˛
3. System wyświetla okno do potwierdzenia z pytaniem czy użytkownik na
pewno chce usunać
˛ wybrany kurs.
4. Użytkownik potwierdza cheć
˛ usuniecia
˛
kursu.
5. System usuwa kurs z systemu.
6. System wyświetla nowa˛ liste˛ kursów
Scenariusz alternatywny 1 – użytkownik anuluje usuwanie:
1–3. Jak w scenariuszu głównym.
4. Użytkownik anuluje usuwanie kursu.
PUA10. Wyświetlenie kursu z panelem edycyjnym
Opis: Wyświetlenie kursu wraz z panelem do jego edycji, który jest udostep˛
niony administratorowi.
Scenariusz główny:
1. Wyświetlenie kursów w trybie zarzadzania
˛
(PUA8).
2. Spośród listy kursów użytkownik wybiera kurs, który chce zmieniać.
3. System wyświetla zawartość kursu wraz z interfejsem do jego edycji oraz
danych powiazanych
˛
z edytowanym kursem (RB11).
PUA11. Wyszukiwanie i filtrowanie kursów
Opis: Wyszukiwanie i filtrowanie kursów ze wzgledu
˛
na wartości posiadanych
atrybutów.
Scenariusz główny:
1. Wyświetlenie kursów w trybie zarzadzania
˛
(PUA8).
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
40
2. Użytkownik wprowadza szukana˛ wartość atrybutu kursu lub wybiera
jeden z filtrów (RB12).
3. System wyświetla nowa˛ liste˛ kursów spełniajacych
˛
kryteria.
PUA12. Przegladanie
˛
materiałów
Opis: Przegladanie
˛
wszystkich materiałów dodanych do systemu.
Scenariusz główny:
1. W celu otwarcia panelu administracyjnego użytkownik wybiera odpowiednia˛ zakładke˛ z menu głównego aplikacji.
2. System wyświetla panel administracyjny.
3. Użytkownik wciska odnośnik służacy
˛ do administrowania materiałami.
4. System wyświetla pierwsza˛ strone˛ z materiałami w systemie. Kolejne
strony sa˛ doste˛ pne poprzez numerowane odnośniki. Na jednej stronie
znajduje˛ sie˛ 25 kursów.
PUA13. Wyświetlenie materiałów w trybie zarzadzania
˛
(rozszerza PUA12
po ostatnim kroku, właczane
˛
przez PUA14, PUA15, PUA16)
Opis: Wyświetlenie materiałów wraz z opcjami do zmiany każdego materiału z
osobna.
Scenariusz główny:
1. Użytkownik wybiera opcje˛ zarzadzania
˛
materiałami w systemie.
2. System wyświetla pierwsza˛ strone˛ z materiałami w systemie. Kolejne
strony sa˛ doste˛ pne poprzez numerowane odnośniki. Na jednej stronie
znajduje˛ sie˛ 25 materiałów. Obok każdego materiału znajduja˛ sie˛ opcje
do jego zmiany.
PUA14. Usuwanie materiałów
Opis: Usunie˛ cie dowolnego materiału multimedialnego z systemu.
Scenariusz główny:
1. Wyświetlenie materiałów w trybie zarzadzania
˛
(PUA13).
2. Spośród listy materiałów użytkownik wybiera materiał, który chce usunać.
˛
3. System wyświetla okno do potwierdzenia z pytaniem czy użytkownik na
pewno chce usunać
˛ wybrany materiał.
4. Użytkownik potwierdza cheć
˛ usuniecia
˛
kursu.
5. System usuwa kurs z systemu.
6. System wyświetla nowa˛ liste˛ materiałów.
Scenariusz alternatywny 1 – użytkownik anuluje usuwanie:
1–3. Jak w scenariuszu głównym.
4. Użytkownik anuluje usuwanie materiału.
PUA15. Zmiana danych dotyczacych
˛
materiału
Opis: Zmiana danych pierwotnie podawanych podczas dodawania.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
41
Scenariusz główny:
1. Wyświetlenie materiałów w trybie zarzadzania
˛
(PUA13).
2. Spośród listy materiałów użytkownik wybiera materiał, który chce zmienić.
3. System wyświetla formularz do zmiany materiału.
4. Użytkownik wprowadza nowe dane i zatwierdza formularz.
5. System wyświetla informacje˛ o pomyślnej zmianie danych.
PUA16. Wyszukiwanie i filtrowanie materiałów
Opis: Wyszukiwanie i filtrowanie materiałów ze wzgledu
˛
na wartości posiadanych atrybutów.
Scenariusz główny:
1. Wyświetlenie materiałów w trybie zarzadzania
˛
(PUA13).
2. Użytkownik wprowadza szukana˛ wartość atrybutu materiału lub wybiera jeden z filtrów (RB13).
3. System wyświetla nowa˛ liste˛ kursów spełniajacych
˛
kryteria.
Rysunek 4.8. Diagram przypadków użycia dla administratora - cze˛ ść 3
PUA17. Wyświetlenie panelu statystyk systemowych (właczane
˛
przez
PUA18, PUA19, PUA20)
Opis: Wyświetlenie panelu statystyk systemowych, który umożliwia dostep
˛ do
konkretnych statystyk.
Scenariusz główny:
1. W celu otwarcia panelu administracyjnego użytkownik wybiera odpowiednia˛ zakładke˛ z menu głównego aplikacji.
2. System wyświetla panel administracyjny.
4.2. Diagramy oraz scenariusze realizacji przypadków użycia
42
3. Użytkownik wciska odnośnik służacy
˛ do wyświetlenia panelu statystyk
systemowych.
4. System wyświetla panel statystyk systemowych.
PUA18. Wyświetlenie statystyk ilościowych
Opis: Wyświetlenie statystyk ilościowych różnych bytów istniejacych
˛
w systemie.
Scenariusz główny:
1. Wyświetlenie panelu statystyk systemowych (PUA17).
2. Użytkownik wciska odnośnik służacy
˛ do wyświetlenia statystyk ilościowych.
3. System wyświetla statystyki ilościowe.
PUA19. Wyświetlenie statystyk dostepu
˛
do systemu
Opis: Wyświetlenie statystyk dostepu
˛
do systemu - akcji logowania i wylogowywania użytkowników.
Scenariusz główny:
1. Wyświetlenie panelu statystyk systemowych (PUA17).
2. Użytkownik wciska odnośnik służacy
˛ do wyświetlenia statystyk dostepu
˛
do systemu.
3. System wyświetla statystyki dostepu
˛
do systemu.
PUA20. Wyświetlenie wykorzystywanych zasobów systemu
Opis: Wyświetlenie wykorzystywanych zasobów systemowych.
Scenariusz główny:
1. Wyświetlenie panelu statystyk systemowych (PUA17).
2. Użytkownik wciska odnośnik służacy
˛ do wyświetlenia wykorzystywanych zasobów systemu.
3. System wyświetla wykorzystanie zasobów systemu.
Reguły biznesowe
RB1. Identyfikator w systemie stanowi e-mail użytkownika, który musi być unikalny. Każdy nowy użytkownik posiada w systemie przydzielona˛ role˛ (uczeń lub
nauczyciel) w zależności 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 sa˛ wyświetlane użytkownikowi w pierwszej kolejności.
RB3. Użytkownik może dokonać filtrowania materiałów ze wzgledu
˛
na typ materiału (opcje: dowolny, wideo, audio), date˛ dodania (opcje: dowolna, dziś, ten tydzień, ten miesiac)
˛ oraz czas trwania (opcje: dowolny, krótszy niż 5 minut, dłuższy
lub równy 5 minut).
4.3. Wybrana technologia
43
RB4. Dane użytkownika sa˛ podzielone na informacje logowania i informacje profilowe. Pierwsza cze˛ ść danych składa sie˛ z e-maila i hasła użytkownika. Druga
natomiast to imie˛ , nazwisko, adres i data urodzenia zalogowanego użytkownika.
RB5. Każda pozycja na wyświetlanej liście kursów ucznia posiada tytuł oraz opis
kursu.
RB6. Panel edycji nauczyciela składa sie˛ z interfejsu graficznego, który umożliwia zarzadzanie
˛
sekcjami, materiałami multimedialnymi oraz tekstowymi, a także
zmiane˛ danych o kursie.
RB7. Nauczyciel może wybrać filtr typu materiału (opcje: dowolny, wideo, audio)
lub widoczności materiału (opcje: dowolna, prywatny, publiczny).
RB8. Nauczyciel może dokonywać zapisów na swoje kursy, które posiadajac
˛ sposób
zapisów: przez nauczyciela lub przez nauczyciela i ucznia. Tylko takie egzemplarze
kursów sa˛ prezentowane użytkownikowi.
RB9. Podobnie jak przy zmianie danych dokonywanej przez samego użytkownika
wyświetlane sa˛ dwa formularze – jeden do zmiany informacji logowania, a drugi do
zmiany informacji profilowych.
RB10. Administrator może wybrać filtr roli w systemie (opcje: dowolna, uczeń,
nauczyciel).
RB11. Panel edycyjny dla administratora jest ograniczony. Pozwala on na usuwanie dowolnej treści z kursu oraz zmieniać dane bezpośrednio dotyczace
˛ danego
kursu.
RB12. Administrator może wybrać filtr rodzaju zapisów (opcje: dowolny, przez
ucznia, przez nauczyciela, przez ucznia i nauczyciela) lub filtr widoczności kursu
(opcje: dowolna, prywatny, publiczny).
RB13. Administrator może wybrać filtr typu materiału (opcje: dowolny, wideo,
audio) lub filtr widoczności materiału (opcje: dowolny, prywatny, publiczny).
4.3. Wybrana technologia
4.3.1. Rozwiazania
˛
i wykorzystane oprogramowanie
System e-learningowy be˛ dzie aplikacja˛ napisana˛ w skryptowym, obiektowym je˛
zyku PHP, który jest je˛ zykiem interpretowanym i wykonywanym po stronie serwera
WWW. Doste˛ p do tego systemu użytkownik bedzie
˛
miał poprzez wpisanie odpowiedniego adresu w przegladarce
˛
internetowej. Serwerem WWW obsługujacym
˛
żadania
˛
stron pochodzacych
˛
z przegladarki
˛
internetowej użytkownika bedzie
˛
serwer Apache. System be˛ dzie wykorzystywał baze˛ danych PostgreSQL do przechowywania
danych trwałych zwiazanych
˛
z użytkownikami, kursami i materiałami.
4.3.2. Podstawowe elementy systemu
1.
2.
3.
4.
Serwer WWW Apache.
Interpreter PHP - uruchamiany jako moduł serwera Apache.
Serwer bazy danych PostgreSQL.
Środowisko - 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 przegladarki
˛
internetowej
Jako framework do budowy aplikacji w jezyku
˛
PHP został wybrany Yii. Podstawowym wzorcem projektowym wykorzystywanym w Yii, jak i w wiekszości
˛
framework’ów dla je˛ zyka PHP, jest MVC. Interfejs użytkownika widoczny w przegladarce
˛
b˛edzie tworzony z pomoca˛ bibliotek napisanych głównie w jezyku
˛
JavaScript oraz
CSS.
4.3.4. Racjonalność dokonanych wyborów
a) wybór realizacji aplikacji w architekturze aplikacji internetowej:
• realizacja aplikacji podobnych do docelowej jako aplikacji internetowych;
• powszechność, łatwość i praktyczność stosowania przegladarek
˛
WWW;
• najcieńszy możliwy klient - nie wymaga żadnych dodatkowych instalacji po
stronie systemu operacyjnego użytkownika;
• dynamiczny rozwój technologii służacych
˛
do tworzenia aplikacji internetowych.
b) wybór serwera WWW Apache:
• najbardziej popularny serwer WWW;
• posiada duża˛ ilość modułów i dostepnych
˛
rozszerzeń, które moga˛ być doła˛
czane do serwera;
• wydajny przy generowaniu dynamicznych treści (np. poprzez skrypt php).
c) wybór je˛ zyka PHP:
• najpowszechniej stosowany jezyk
˛
skryptowy wykonywany po stronie serwera WWW;
4.3. Wybrana technologia
45
• platformy Moodle i PHPmotion sa˛ napisane w tym jezyku
˛
i stale sie˛ rozwijaja;
˛
• PHP udoste˛ pnia ogrom możliwości i jest ciagle
˛
rozwijany, co zwieksza
˛
jego
popularność;
• stosunkowo łatwy do nauki;
• na rynku istnieje wiele darmowych framework’ów (Zend, PHPCake, CodeIgniter, Yii, Symfony, itp.), które ułatwiaja˛ tworzenie aplikacji internetowych.
d) wybór framework’u Yii:
• zgodnie ze strona˛ http://phpframeworks.com/top-10-php-frameworks
jest to obecnie framework dla jezyka
˛
PHP, który cieszy sie˛ najwieksz
˛
a˛ popularnościa˛ i przychylnościa˛ programistów;
• znaczaco
˛
ułatwia tworzenie aplikacji internetowych w PHP poprzez udoste˛ pnienie dla programisty wielu narzedzi
˛
i możliwości automatyzacji czynności, które powtarzaja˛ sie˛ podczas tworzenia aplikacji internetowej.
e) wybór bazy danych PostgreSQL:
• najbardziej zaawansowana baza danych typu open-source;
• zgodność bazy danych z zastosowanymi innymi elementami systemu;
• dokładnie opisane stosowanie bazy danych w obszernym podreczniku.
˛
5. Implementacja systemu
5.1. Framework Yii
Wprowadzenie
Framework Yii (akronim od “Yes It Is”) jest komponentowym framework’iem
PHP zaprojektowanym do tworzenia dużych aplikacji o silnym nate˛ żeniu ruchu
takich jak forum, systemy zarzadzania
˛
treścia˛ i portale internetowe. Dlatego też
wprowadza on mały narzut w porównaniu do innych framework’ów oraz wspiera różne systemy pamie˛ ci podrecznej.
˛
Ważna˛ cecha˛ Yii jest ogrom możliwości,
które oferuje, wsparcie wśród społeczności programistów oraz jego stały rozwój.
Wszystkie wymienione tutaj zalety Yii miały duży wpływ na wybór właśnie jego przy
tworzeniu mojego systemu.
Yii implementuje wzorzec projektowy MVC. Jego zaleta˛ jest oddzielenie logiki
biznesowej od interfejsu graficznego, dzieki
˛
czemu programista może zmieniać
te rzeczy niezależnie. We wzorcu MVC model przechowuje dane oraz reguły
biznesowe, widok natomiast interfejs użytkownika, który stanowia˛ zazwyczaj różne
formularze oraz tekst.
Rysunek 5.1. Statyczna struktura aplikacji w Yii
5.1. Framework Yii
47
Kontroler w Yii
a) przykładowe żadanie
˛
wysyłane do aplikacji napisanej z wykorzystaniem Yii
oraz znaczenie poszczególnych elementów ścieżki:
Zgodnie z powyższa˛ semantyka,
˛ dla przykładowego żadania
˛
użytkownika tworzony jest obiekt kontrolera o nazwie CourseController oraz wykonywana akcja
o identyfikatorze create.
b) akcje:
Akcje definiowane w kontrolerze sa˛ metodami, których nazwa poprzedzona jest
słowem action i maja˛ format “actionIdAkcji”. Akcje moga˛ być również zaimplementowane w postaci oddzielnych klas. W takim przypadku trzeba zadeklarować w kontrolerze mapowanie identyfikatora akcji na konkretna˛ klase.
˛
c) filtry akcji:
Filtry stosowane do akcji sa˛ zazwyczaj filtrami dostepu
˛
lub filtrami do pomiaru
czasu wykonywania akcji. Najcześciej
˛
implementuje sie˛ je jako metody kontrolera, lecz można również to zrobić korzystajac
˛ z oddzielnych klas.
Przepływ sterowania
1. Użytkownik wysyła ż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 Aplikacja).
˛
3. Aplikacja uzupełnia informacje o żadaniu
˛
użytkownika za pomoca˛ komponentu
aplikacji request.
4. Aplikacja określa identyfikator żadanego
˛
kontrolera i akcji dzieki
˛
komponentowi aplikacji urlManager. W tym przypadku identyfikatorem kontrolera jest
course, a akcji show.
5. Aplikacja tworzy instancje˛ kontrolera CourseController. Określa on, że akcja
show odnosi sie˛ do metody actionShow w jego klasie. Kontroler wykonuje filtry
nałożone na akcje˛ do wykonania. Nastepnie
˛
jeśli filtry na to pozwalaja˛ akcja jest
wykonywana.
6. Akcja odczytuje z bazy danych model Course o ID równym 1.
7. Akcja wyświetla widok show stworzony dla tej akcji wraz z modelem Course.
8. Widok odczytuje dane z modelu Course i wyświetla odczytane atrybuty.
9. Widok wykonuje pewne widgety, które zostały w nim umieszczone.
10. Zawartość wygenerowana przez widok umieszczana jest w schemacie strony.
11. Akcja wyświetla dynamiczna˛ zawartość użytkownikowi.
5.1. Framework Yii
48
Rysunek 5.2. Typowy przepływ sterowania aplikacji w Yii
Aktywny rekord
Aktywny rekord (ang. Active Record) jest jedna˛ z technik, która umożliwia
mapowanie obiektowo-relacyjne. Każda klasa aktywnego rekordu reprezentuje
konkretna˛ tabele˛ istniejac
˛ a˛ w bazie danych oraz udostepnia
˛
szereg metod pozwalajacych
˛
na wykonywanie podstawowych operacji CRUD (create, read, update
and delete). Framework Yii udostepnia
˛
klase˛ bazowa˛ CActiveRecord, po której
dziedzicza˛ wszystkie klasy (modele) reprezentujace
˛ tabele baz danych. Instancje
takich klas reprezentuja˛ rekordy w bazie danych.
<?php
$res_tag = new ResTag;
$res_tag->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 tabele˛ w bazie danych. Dzieki
˛
temu
5.1. Framework Yii
49
obiekt tej klasy posiada właściwości takie jak pola w danej tabeli. W powyższym
przykładzie przypisujemy obiektowi wartości atrybutów, z których każdy reprezentuje atrybut o tej samej nazwie w tabeli. Na końcu metoda˛ save() rekord jest wstawiany do bazy danych. Po wykonaniu powyższego kodu mamy wstawiony rekord
do tabeli z tagami, który jest zwiazany
˛
z zasobem o ID równym 20 i posiada atrybut
tag o wartości “sample tag”.
<?php
// znajduje pierwszy rekord z tabeli tagów, którego
// atrybut tag zawiera łańcuch "jezioro"
$res_tag = ResTag::model()->find("tag LIKE ’%jezioro%’");
// znajduje rekord z tabeli tagów o kluczu głównym równym 16
$res_tag = ResTag::model()->findByPk(16);
// znajduje pierwszy rekord z tabeli tagów, którego atrybut
// resource_id jest równy 185
$res_tag = ResTag::model()
->findByAttributes(array("resource_id"=>185));
// znajduje wszystkie rekordy z tabeli tagów,
// których atrybut resource_id jest ró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 najcześciej
˛
stosowane do wyszukiwania rekordów w bazie danych. Komentarz pod każda˛ z metod krótko opisuje działanie danej
metody.
<?php
// wyszukaj rekord reprezentujacy
˛
tag o id równym 16
$res_tag = ResTag::model()->findByPk(16);
$res_tag->tag = "new tag";
// uaktualnij rekord
$res_tag->update();
// wyszukaj rekord reprezentujacy
˛
tag o id równym 17
$res_tag = ResTag::model()->findByPk(17);
// usuń rekord z 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 udostepniane
˛
przez klase˛ CActiveRecord służace
˛ do usuwania i uaktualniania rekordu w bazie danych.
Jak widać na powyższych wydrukach obiekty korzystaja˛ z wygodnych metod,
które wykonuja˛ podstawowe operacje z wykorzystaniem jezyka
˛
SQL. Podczas implementowania aplikacji internetowej zdecydowanie najcześciej
˛
wykonuje sie˛ podstawowe operacje CRUD. Dzieki
˛ aktywnemu rekordowi implementowanemu przez
Yii programista do wykonywania podstawowych operacji bazodanowych nie potrzebuje pisać prostych zapytań dla każdej tabeli.
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......................Domyślny kontroler aplikacji
extensions/.......................................Rozszerzenia aplikacji Yii
messages/..........................................Tłumaczone wiadomości
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 kolumna˛
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
Podstawa˛ projektowanego systemu jest relacyjna baza danych oparta na silniku
bazodanowym PostgreSQL. Poza opublikowanymi materiałami multimedialnymi
stanowi ona główne źródło danych, z których korzysta tworzony system. Diagram
5.3 przedstawia schemat bazy danych zaprojektowany z wykorzystaniem modelu
zwiazków
˛
encji (ang. entity-relationship - ER).
Przedstawiony poniżej diagram ER jest diagramem logicznym, który musiał
zostać 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żyta notacja 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żytkownika na
kurs. Została ona napisana, aby zapewnić brak możliwości zapisania na kurs
wi˛ekszej liczby użytkowników niż jest to możliwe. Zastosowany wyzwalacz o nazwie res_delete uruchamiany jest po usunieciu
˛
materiału z systemu. Pozwala
to na powiazanie
˛
operacji usuwania materiału, która jest możliwa do wykonania w
kilku miejscach w systemie, z wykonaniem operacji na innej tabeli w bazie danych.
Operacja ta polega na odje˛ ciu od przestrzeni używanej przez użytkownika rozmiaru
pliku usuwanego materiału multimedialnego.
Framework Yii udoste˛ pnia wygodne metody do łatwego wykonywania transakcji
w bazie danych. Zaimplementowana transakcja dotyczy operacji wykonywanych w
czasie aktywacji konta w systemie. Operacje wykonywane w obrebie
˛
tej transakcji
to usunie˛ cie tymczasowego użytkownika oraz wstawienie nowego, pełnoprawnego
użytkownika.
Rysunek 5.3. Diagram ER bazy danych systemu
5.2. Projekt bazy danych
52
Rysunek 5.4. Schemat relacyjnej bazy danych systemu
5.2. Projekt bazy danych
53
54
5.2. Projekt bazy danych
5.2.3. Opis tabel
Tabela
Opis
Atrybut
Opis
yii_temp_user
Tabela przechowuje
dane zwiazane
˛
z
tymczasowymi
użytkownikami w
systemie. Rekord tej
tabeli tworzony jest
po pomyślnym
zatwierdzeniu
formularza
rejestracyjnego.
Atrybut password
jest skrótem hasła
podanego przez
nowego użytkownika.
Atrybut confirm_code
jest losowym ciagiem
˛
znaków służacym
˛
do
aktywacji konta w
systemie.
user_id
Klucz główny tabeli.
confirm_code
Kod aktywacyjny, który
zostaje wysłany
użytkownikowi na
skrzynke˛ pocztowa˛ po
pomyślnym
zatwierdzeniu
formularza
rejestracyjnego.
email
Adres e-mail
tymczasowego
użytkownika.
password
Skrót hasła
tymczasowego
użytkownika.
first_name
Imie˛ tymczasowego
użytkownika.
last_name
Nazwisko
tymczasowego
użytkownika.
address
Adres zamieszkania
tymczasowego
użytkownika.
birth_date
Data urodzenia
tymczasowego
użytkownika.
role_in_system
Rola w systemie
tymczasowego
użytkownika.
user_id
Klucz główny tabeli.
email
Adres e-mail nowego
użytkownika.
password
Skrót hasła nowego
użytkownika.
first_name
Imie˛ nowego
użytkownika.
last_name
Nazwisko nowego
użytkownika.
address
Adres zamieszkania
nowego użytkownika.
yii_user
Tabela przechowuje
dane pełnoprawnych
użytkowników
systemu, którzy
przeszli prawidłowo
przez proces
rejestracji. Wiekszość
˛
danych zawartych w
tej tabeli jest
kopiowana z tabeli
yii_temp_user, po tym
jak użytkownik
aktywuje swoje
55
5.2. Projekt bazy danych
konto w systemie.
yii_log
yii_user_course
Tabela przechowuje
logi zwiazane
˛
z
użytkownikami.
Rejestrowane logi
dotycza˛ logowania i
wylogowania
użytkownika z
systemu.
Tabela łacz
˛ aca
˛
użytkownika z
kursem. Atrybut
role_in_course
określa jaka˛ role˛ w
tym złaczeniu
˛
pełni
użytkownik. Klucz
obcy user_id oraz
course_id stanowia˛
klucz główny tabeli.
birth_date
Data urodzenia nowego
użytkownika.
role_in_system
Rola w systemie
nowego użytkownika.
quota
Limit danych na
materiały
multimedialne
dodawane przez
użytkownika.
space_used
Używana przestrzeń
danych przez
użytkownika.
add_time
Czas aktywacji konta
użytkownika w
systemie.
log_id
Klucz główny tabeli.
user_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_user
reprezentujacym
˛
użytkownika w
systemie.
log_type
Rodzaj logu (logowanie
lub wylogowanie).
log_time
Czas zapisu logu do
systemu.
user_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_user
reprezentujacym
˛
użytkownika w
systemie.
course_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_course
reprezentujacym
˛
kurs
dodany do systemu.
role_in_course
Rola użytkownika w
kursie.
56
5.2. Projekt bazy danych
yii_course_ca- Tabela przechowuje
kategorie, do których
tegory
moga˛ należeć kursy
tworzone w systemie.
yii_resource
Tabela przechowuje
dane zwiazane
˛
z
materiałem
multimedialnym.
category_id
Klucz główny tabeli.
category
Nazwa kategorii kursu.
Kurs musi należeć do
jednej z wybranych
kategorii.
resource_id
Klucz główny tabeli.
section_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_section
reprezentujacym
˛
sekcje˛
kursu.
user_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_user
reprezentujacym
˛
użytkownika w
systemie.
resource_name
Nazwa materiału
multimedialnego.
resource_type
Typ materiału
multimedialnego (wideo
lub audio).
path_to_resource
Druga cześć
˛ ścieżki
katalogowej do pliku
reprezentujacego
˛
materiał
multimedialny.
Pierwsza˛ cześć
˛ ścieżki
stanowi ścieżka do
określonego katalogu w
systemie operacyjnym,
gdzie sa˛
przechowywane
materiały
multimedialne.
upload_date
Czas dodania materiału
multimedialnego do
systemu.
play_length
Czas trwania materiału
multimedialnego.
visibility
Widoczność materiału
multimedialnego.
57
5.2. Projekt bazy danych
yii_res_tag
yii_course
Tabela przechowuje
tagi zwiazane
˛
z
materiałami
multimedialnymi w
systemie.
Tabela przechowuje
kursy dodawane do
systemu.
filesize
Rozmiar pliku
reprezentujacego
˛
materiał
multimedialny.
view_count
Liczba wyświetleń
materiału
multimedialnego.
tag_id
Klucz główny tabeli.
resource_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_resource
reprezentujacym
˛
materiał
multimedialny.
tag
Nazwa tagu.
course_id
Klucz główny tabeli.
category_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_course_category
reprezentujacym
˛
kategorie˛ kursu.
title
Tytuł kursu.
description
Opis kursu.
visibility
Widoczność 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 dostepu
˛
do kursu.
add_time
Czas dodania kursu do
systemu.
view_count
Liczba wyświetleń
kursu.
58
5.3. Struktura stworzonej aplikacji internetowej
yii_section
yii_text_resource
yii_lookup
Tabela przechowuje
sekcje należace
˛ do
kursów.
Tabela przechowuje
materiały tekstowe
należace
˛ do sekcji.
Tabela przechowuje
ważne opcje, możliwe
do wyboru dla
użytkownika
końcowego.
section_id
Klucz główny tabeli.
course_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_course
reprezentujacym
˛
kurs
dodany do systemu.
title
Tytuł sekcji kursu.
resource_id
Klucz główny tabeli.
section_id
Klucz tabeli, łacz
˛ acy
˛
rekord tej tabeli z
rekordem z tabeli
yii_section
reprezentujacym
˛
sekcje˛
kursu.
user_id
Klucz obcy tabeli,
łacz
˛ acy
˛ rekord tej tabeli
z rekordem z tabeli
yii_user
reprezentujacym
˛
użytkownika w
systemie.
title
Tytuł materiału
tekstowego.
add_date
Czas dodania materiału
tekstowego do systemu.
text_content
Treść materiału
tekstowego.
name
Nazwa opcji.
code
Kod opcji.
type
Typ opcji.
name_position
Pozycja opcji na liście
do wyboru.
5.3. Struktura stworzonej aplikacji internetowej
5.3.1. Podstawowe elementy systemu
Podstawowymi elementami tworzonego systemu sa˛ serwer WWW Apache, interpreter PHP oraz serwer bazy danych PostgreSQL uruchomione na systemie Linux 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 szybka˛ i bezproblemowa˛ instalacje˛ serwera WWW Apache z modułem PHP, serwera PostgreSQL oraz narzedzia
˛
phpPgAdmin na systemie linuksowym. Narzedzie
˛
phpPgAdmin jest aplikacja˛ PHP
pozwalajac
˛ a˛ na wygodne zarzadzanie
˛
baza˛ danych z poziomu przegladarki
˛
internetowej.
5.3.2. Aplikacja serwerowa
Klasy kontrolerów
Podstawowymi klasami aplikacji serwerowej napisanej z wykorzystaniem
framework’a Yii sa˛ klasy kontrolerów. Każda klasa kontrolera posiada zestaw
akcji, z których każda odpowiada za obsługe˛ pewnego żadania
˛
HTTP pochodzacego
˛
od aplikacji klienckiej. Framework Yii udostepnia
˛
klase˛ bazowa˛ CController, po
której dziedziczy każda klasa stworzonego kontrolera w systemie. Podstawowa˛
funkcjonalnościa˛ udoste˛ pniana˛ przez ta˛ klase˛ bazowa˛ jest wyświetlanie widoków
oraz stosowanie różnego rodzaju filtrów akcji.
Klasy kontrolerów w głównym katalogu kontrolerów:
a) SiteController - kontroler odpowiedzialny za zarzadzanie
˛
dostepem
˛
do systemu (logowanie i wylogowanie). Ponadto wyświetla podstawowe informacje o
systemie i jego możliwościach.
b) UserController - kontroler odpowiedzialny za tworzenie i zarzadzanie
˛
danymi zwiazanymi
˛
z użytkownikami w systemie.
c) SearchController - kontroler zapewnia funkcjonalność wyszukiwania materiałów multimedialnych, które posiadaja˛ w systemie publiczna˛ widoczność.
d) ResourceController - kontroler odpowiedzialny za obsługe˛ publikowanych
materiałów multimedialnych w systemie oraz zarzadzanie
˛
danymi, które sa˛ z
nimi zwiazane.
˛
e) EnrolmentController - kontroler odpowiedzialny za zapisy i wypisy uczniów
z kursów dodanych przez nauczycieli.
f) CourseController - kontroler odpowiedzialny za zarzadzanie
˛
kursami oraz
˛
wszystkimi danymi, które moga˛ być dodane w jego obrebie.
Klasy kontrolerów w katalogu kontrolerów modułu administratora:
a) DefaultController - kontroler odpowiedzialny za wyświetlanie panelu administracyjnego.
b) UserController - kontroler odpowiedzialny za zarzadzanie
˛
kontami użytkowników obecnych w systemie.
c) ResourceController - kontroler odpowiedzialny za zarzadzanie
˛
materiałami
multimedialnymi w systemie.
d) CourseController - kontroler odpowiedzialny za zarzadzanie
˛
kursami dodanymi do systemu.
e) StatController - kontroler odpowiedzialny za wyświetlanie panelu statystyk
oraz różnych, specyficznych statystyk zwiazanych
˛
z systemem.
5.3. Struktura stworzonej aplikacji internetowej
60
Klasy komponentów
Klasy komponentów stanowia˛ klasy, których obiekty sa˛ czesto
˛
wykorzystywane
w aplikacji w różnych miejscach. Czesto
˛
obiekty tych klas sa˛ obiektami pomocniczymi, które wykonuja˛ bardziej skomplikowane zadania i sa˛ one wykorzystywane
w różnych akcjach kontrolerów.
Klasy komponentów aplikacji:
a) AdminAccount - klasa przechowuje stałe informacje dotyczace
˛ konta administratora.
b) Conroller - specjalizowana klasa bazowa dla kontrolerów aplikacji dziedziczaca
˛ po klasie CController.
c) CourseHelper - klasa udostepniaj
˛
aca
˛ metody pomocnicze dotyczace
˛ kursów.
d) FFmpegCommand - klasa budujaca
˛ polecenie do konwersji pliku oraz udostep˛
niajaca
˛ opcje dodawane do budowanego polecenia.
e) FFmpegSupport - klasa umożliwiajaca
˛ sprawdzenie czy plik wymaga konwersji
oraz czy plik może być przekonwertowany do formatu odtwarzanego przez
odtwarzacz flowplayer.
f) HttpError - klasa przechowuje stałe reprezentujace
˛ kody błedów
˛
HTTP.
g) HttpMessage - klasa przechowuje stałe tekstowe reprezentujace
˛ wiadomości
wyświetlane użytkownikowi podczas wystepowania
˛
błedów
˛
HTTP.
h) HttpCast - klasa określajaca
˛ jakie wiadomości sa˛ wyświetlane użytkownikowi
końcowemu podczas wystepowania
˛
określonych błedów
˛
HTTP.
i) PasswordHash - klasa umożliwiajaca
˛ generowanie skrótu hasła.
j) ResourceManager - klasa odpowiedzialna za wykonywanie różnych zadań dotyczacych
˛
materiału multimedialnego dodanego do systemu. Pozwala ona mie˛
dzy innymi na konwertowanie pliku do formatu kompatybilnego z odtwarzaczem flowplayer oraz czytanie różnych parametrów z pliku wideo lub audio.
k) SearchEngine - klasa przechowuje stałe używane przy wyszukiwaniu materiałów multimedialnych w systemie.
l) UserIdentity - klasa umożliwia uwierzytelnienie użytkownika próbujacego
˛
sie˛ zalogować w systemie.
Klasy modeli
Obiekty klas modeli głównie służa˛ do przechowywania danych podczas
wykonywania skryptu PHP. Poza danymi znajduja˛ sie˛ w nich również reguły
biznesowe oraz różne metody pomagajace
˛
przetwarzać dane. Najcześciej
˛
klasa
modelu reprezentuje tabele˛ dziedziczac
˛ po klasie CActiveRecord oraz udoste˛ pnia
programiście obiektowy doste˛ p do danych znajdujacych
˛
sie˛ w bazie danych.
Klasy modeli aplikacji:
a)
b)
c)
d)
Course - klasa modelu dla tabeli yii_course.
CourseCategory - klasa modelu dla tabeli yii_course_category.
Log - klasa modelu dla tabeli yii_log.
LoginForm - klasa modelu do przechowywania danych pochodzacych
˛
z formularza logowania.
e) Lookup - klasa modelu dla tabeli yii_lookup.
f) Resource - klasa modelu dla tabeli yii_resource.
5.3. Struktura stworzonej aplikacji internetowej
g)
h)
i)
j)
k)
l)
61
ResTag - klasa modelu dla tabeli yii_res_tag.
Section - klasa modelu dla tabeli yii_section.
TempUser - klasa modelu dla tabeli yii_temp_user.
TextResource - klasa modelu dla tabeli yii_text_resource.
User - klasa modelu dla tabeli yii_user.
UserCourse - klasa modelu dla tabeli yii_user_course.
Klasy filtrów
Zaimplementowane filtry aplikacji pełnia˛ funkcje˛ kontroli dostepu
˛
do różnych
cz˛eści systemu. Podstawowym wymogiem dla wykonania wielu akcji w kontrolerach jest wymóg bycia zalogowanym w systemie. Filtr ten jest implementowany
przez framework Yii i można go zdefiniować w kontrolerze dodajac
˛ metode˛
accessRules, która zwraca tablice˛ asocjacyjna˛ o odpowiednim formacie. W tablicy
tej można określić wymóg bycia zalogowanym jako dowolny lub predefiniowany
użytkownik. Dla modułu administratora metoda ta zwiazana
˛
jest ze wszystkimi
akcjami kontrolerów oraz pozwala na ich wykonanie wyłacznie
˛
dla użytkownika
o określonej nazwie. Filtry aplikacji stworzone w postaci oddzielnych klas sa˛
używane w wielu miejscach oraz zazwyczaj implementuja˛ bardziej skomplikowana˛
operacje˛ kontroli doste˛ pu.
Klasy filtrów aplikacji:
a) IsAjaxRequest - sprawdza czy żadanie
˛
HTTP odebrane od użytkownika jest
typu AJAX.
b) IsTeacherFilter - sprawdza czy zalogowany użytkownik posiada w systemie
role˛ nauczyciela.
c) IsCourseStudentFilter - sprawdza czy użytkownik posiada uprawnienia do
wyświetlenia zawartości kursu.
d) IsCourseTeacherFilter - sprawdza czy nauczyciel próbuje wykonać operacje˛ dotyczac
˛ a˛ własnego kurs.
Stosowanie filtrów aplikacji do wybranych akcji kontrolera odbywa sie˛ poprzez
definicje˛ tablicy zwracanej w metodzie filters kontrolera.
5.3.3. Aplikacja kliencka
Do realizacji różnych zadań po stronie klienta została wykorzystana biblioteka
j˛ezyka JavaScript - jQuery. Podczas implementowania kodu klienckiego standardem stało sie˛ używanie różnych tego typu bibliotek. Jedna˛ z ich najważniejszych
zalet jest takie same wykonanie metod, które udostepniaj
˛
a,
˛ w różnych przegladar˛
kach internetowych. Cze˛ ść interfejsu użytkownika została zaimplementowana z
użyciem biblioteki jQuery UI. Biblioteka ta udostepnia
˛
różnego rodzaju kontrolki
oraz widgety, które upraszczaja˛ tworzenie przyjaznego interfejsu użytkownika.
Kolejna˛ biblioteka˛ JavaScript zastosowana˛ w systemie jest biblioteka History.js.
Jej główna zaleta˛ jest udostepnienie
˛
interfejsu pozwalajacego
˛
na jednakowe korzystanie z funkcjonalności HTML5 History API dostepnej
˛
we wszystkich nowszych wersjach przegladarek.
˛
Standardowo do historii przegladarki
˛
dodawana jest
strona, na która˛ wejdziemy po otwarciu odnośnika URL. History API pozwala na
bezpośrednia˛ zmiane˛ historii przegladarki.
˛
Wykonujac
˛ odpowiednia˛ metode˛ można
5.4. Wysyłanie i przetwarzanie plików po stronie serwera
62
dodać odnośnik URL do stosu odwiedzonych stron, co skutkuje również zmiana˛ adresu w pasku adresu przegladarki.
˛
Funkcjonalność udostepniona
˛
przez biblioteke˛
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 przegladarki
˛
dodawana jest pozycja URL zawierajaca
˛ parametry wyszukiwania oraz numer żadanej
˛
strony. Jeśli użytkownik bedzie
˛
chciał wrócić do poprzedniej strony wystarczy, że wciśnie przycisk “Wstecz” w nawigacji przegladarki,
˛
a aplikacja kliencka załaduje poprzednia˛ strone˛ wysyłajac
˛ żada˛
nie AJAX. Załadowanie strony po wciśnieciu
˛
przez użytkownika przycisku “Wstecz”
lub “Dalej” w nawigacji przegladarki
˛
odbywa sie˛ poprzez dodanie funkcji zwrotnej
dla zdarzeń dodawania i zdejmowania pozycji ze stosu historii przegladarki.
˛
Przed powstaniem History API przegladarki
˛
pozwalały wyłacznie
˛
na zmiane˛ cze˛
ści adresu URL - be˛ dacej
˛
po znaku # (kotwicy). Aplikacja jest kompatybilna wstecz
i implementuje również ten sposób działania na starszych wersjach przegladarek.
˛
Wada˛ takiego działania jest konieczność wykonania dwóch żada
˛ ń po odświeżeniu
strony z bieżacymi
˛
rezultatami. Dzieje sie˛ tak ponieważ cześć
˛ adresu URL po znaku
kotwicy nie jest przesyłana do serwera i należy wykonać kolejne żadanie
˛
(AJAX) w
celu uzyskania żadanej
˛
strony 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żliwościa˛ wyboru pliku do wysłania. Proces wysyłania pliku na
serwer rozpoczyna sie˛ wraz z zatwierdzeniem formularza. Stosujac
˛ taka˛ metode˛
wysyłania plików użytkownik korzystajacy
˛ z przegladarki
˛
WWW nie posiada możliwości podgladu
˛
procesu wysyłania.
Możliwość podgladu
˛
procesu wysyłania pliku na serwer stanowi jedno z wymagań funkcjonalnych założonych dla tworzonego systemu. Na rynku istnieje
wiele wtyczek, dzie˛ ki którym można zaimplementować taka˛ funkcjonalność. Wykorzystuja˛ one technologie˛ Flash oraz różne biblioteki napisane w jezyku
˛
JavaScript. Jedna˛ z takich wtyczek jest wtyczka biblioteki jQuery – Uploadify. Ponadto
umożliwia ona wysyłanie wielu plików jednocześnie. Wiecej
˛
informacji o możliwościach tego rozszerzenia można znaleźć pod adresem: http://www.uploadify.
com/about/. Ze wzgle˛ du na powyższe zalety 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 rozwia˛
zaniem z punktu widzenia użytkownika systemu jest użycie odtwarzacza Flash.
Dzi˛eki temu użytkownik systemu nie musi instalować żadnego dodatkowego oprogramowania. Takie rozwiazanie
˛
spośród analizowanych serwisów stosuje np.
YouTube czy Plumi. W implementowanym systemie wybrano podobne rozwiazanie,
˛
a jako odtwarzacz Flash wykorzystano darmowy odtwarzacz flowplayer, podobnie
jak zostało to zrobione w systemie Plumi.
63
5.4. Wysyłanie i przetwarzanie plików po stronie serwera
Konwersja plików po stronie serwera
Z dokonanym wyborem odtwarzacza (flowplayer’a) zwiazane
˛
sa˛ pewne ograniczenia, a zatem i wymagania. Odtwarzacz Flash może odtwarzać tylko wybrana,
˛
wask
˛ a˛ grupe˛ plików w odpowiednim formacie i odpowiednio zakodowanych strumieniach wideo i audio. Odtwarzacz flowplayer odtwarza pliki wideo, których parametry sa˛ zgodne z tabela˛ poniżej:
Format
Kodek wideo
Kodek audio
Rozszerzenie pliku
FLV
FLV (Sorenson
H.263)
MP3
.flv
MP4
H.264
AAC
.mp4 .mov .m4v
F4V
H.264
AAC
.f4v
Z powyższego zestawienia wynika, iż plik o formacie i kodowaniu innym niż wymienionym w tabeli należy poddać konwersji. Nowy plik wyjściowy otrzymany z niekompatybilnego pliku wejściowego powinien posiadać wszystkie parametry zgodne
ze wspieranymi przez odtwarzacz flowplayer. Dzieki
˛ takiej konwersji materiał multimedialny może być bezproblemowo dostarczany do użytkownika końcowego.
W celu przeprowadzenia konwersji plików do odpowiedniego formatu oraz kodowania został użyty FFmpeg - szybki konwerter plików wideo i audio. Narzedzie
˛
te działa w trybie tekstowym, co doskonale nadaje sie˛ do zastosowania w systemie.
Jego zaletami jest wsparcie wielu formatów i kodeków oraz szybkość konwersji.
Rysunek 5.5. Domyślna konwersja plików wideo i audio w systemie
Konwersja plików audio odbywa sie˛ do formatu i kodowania mp3. Wynika to
z tego, iż pliki takie potrafi dostarczyć dla użytkownika 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 wyjściowych
strumieni audio i wideo używa domyślnych wartości. Lepszym rozwiazaniem
˛
jest
ustawienie plikowi, który otrzymamy po konwersji takich parametrów jakie posiada
plik wejściowy. Przy takiej realizacji plik wyjściowy bedzie
˛
nieznacznie różnił sie˛ od
wejściowego.
W celu odczytania odpowiednich wartości parametrów z pliku zastosowano rozszerzenie je˛ zyka PHP - FFMPEG-PHP. Zostało ono użyte przy budowaniu komendy
konwertujacej
˛
oraz przy odczytywaniu metadanych dotyczacych
˛
dodanego materiału. Przykładowo, zostało ono wykorzystane do odczytania długości trwania dodanego pliku.
Proces przetwarzania wysłanego pliku
W wie˛ kszości przypadków proces przetwarzania wysłanego pliku składa sie˛ z
dwóch etapów - dwóch sekwencji żadanie-odpowiedź.
˛
Sekwencja żada
˛ ń i odpowiedzi oraz moment wykonywania poszczególnych akcji został zilustrowany na rysunku 5.6.
W pierwszym etapie po wysłaniu pliku na serwer wtyczka Uploadify wysyła żada˛
nie wykonania akcji FilesUploadedAction. Diagram blokowy 5.7 przedstawia kroki
podejmowane przy wykonywaniu tej akcji. W zależności od wyniku tej akcji najcz˛eściej wykonywana jest akcja FileConvertAction. Diagram blokowy 1 przedstawia
przetwarzanie dokonywane w tej akcji. Przetwarzanie pliku musiało zostać podzielone na dwa żadania
˛
i odpowiedzi HTTP. Powodem takiej decyzji jest fakt, iż czas
wykonania konwersji jest bardzo czesto
˛
dłuższy niż 30s. Limit 30 sekund natomiast jest nałożony na wykonanie żadania,
˛
które zostało wysłane przez aplikacje˛
w technologii Flash (w tym przypadku z użyciem wtyczki Uploadify). Ograniczenie
takie spowodowało, iż po stronie przegladarki
˛
wykonywane jest kolejne żadanie
˛
z
odesłaniem takich samych danych, które zostały odebrane po stronie użytkownika.
Struktura katalogowa przechowywanych plików wideo i audio
Poczatkowo
˛
wszystkie pliki dodawane do systemu były umieszczane w jednym
katalogu o nazwie uploads. Rozwiazanie
˛
takie wraz ze wzrostem liczby plików staje
si˛e niewydajne. Podstawowe systemowe operacje katalogowe staja˛ sie˛ coraz dłuższe
z powodu zbyt dużej liczby plików przechowywanych w jednym katalogu. Wskutek tego organizacja plików została zaimplementowana metoda˛ opisana˛ w materiale [12]. Zgodnie z tym sposobem plik jest umieszczany na końcu dodatkowej,
dwupoziomowej struktury katalogowej. Nazwa katalogu pierwszego poziomu dla
nowego pliku stanowi dziesie˛ tny zapis pierwszego bajtu skrótu losowej nazwy przypisywanej plikowi. Podobnie jest z nazwa˛ katalogu drugiego poziomu, gdzie nowy
katalog nosi nazwe˛ dzisie˛ tnego zapisu drugiego bajtu skrótu. Jednobajtowa nazwa
katalogu daje 256 możliwości na każdym poziomie. Łacznie
˛
możemy stworzyć zatem 65536 katalogów. Przy losowej generacji nazw dla nowych plików otrzymujemy
dobra˛ dystrybucje˛ plików. Przykładowa ścieżka do 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 żada
˛ ń i odpowiedzi HTTP zwiazanych
˛
z wysyłaniem i przetwarzaniem wysłanego pliku
5.4. Wysyłanie i przetwarzanie plików po stronie serwera
Rysunek 5.7. Działania podejmowane w akcji FilesUploadedAction
66
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 narzedzie
˛
FFmpeg
Kompletny wykaz wspieranych kodeków i formatów, przez zastosowane w systemie narze˛ dzie FFmpeg, znajduje sie˛ w załaczniku
˛
A.
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żdej klasy umieszczonej w
katalogu komponentów aplikacji (poza klasami, które wyłacznie
˛
przechowuja˛ stałe
używane w aplikacji). Testy funkcjonalne natomiast zostały napisane dla każdej
klasy kontrolera. W obu przypadkach zostało wykorzystane narzedzie
˛
PHPUnit,
które stanowi standard dla testowania aplikacji napisanych w jezyku
˛
PHP. Głównymi atutami tego narze˛ dzia jest udostepnianie
˛
framework’a ułatwiajacego
˛
pisanie
testów oraz umożliwienie łatwego uruchamiania i konfiguracji testów, a także analizy ich wyników. Narze˛ dziem wykorzystanym do przeprowadzania testów funkcjonalnych jest Selenium.
5.5.1. Testy funkcjonalne
Selenium jest zestawem narzedzi
˛
pozwalajacym
˛
automatyzować akcje wykonywane w przegladarkach
˛
internetowych na różnych systemach operacyjnych. Podstawowym elementem Selenium jest Selenium Server. Głównymi zadaniami tego
serwera jest uruchamianie, unicestwianie oraz sterowanie instancjami różnych
przegladarek
˛
internetowych. Protokołem służacym
˛
do komunikacji z serwerem
Selenium jest WebDriver. Wykorzystana biblioteka kliencka implementujaca
˛ ten
protokół to php-webdriver (stworzona przez Facebook).
Publikacja materiałów multimedialnych jest zwiazana
˛
z wyborem plików z lokalnego systemu plików, a wie˛ c z obsługa˛ systemowego okna dialogowego. Automatyczne sterowanie przegladark
˛
a˛ internetowa˛ w tym zakresie nie jest możliwe. Do
przetestowania tej funkcjonalności systemu został użyty program cnee. Umożliwia
on nagrywanie oraz odtwarzanie sesji protokołu X. W celach testowych stworzone
zostały nagrania, które otwieraja˛ okno wyboru plików, a nastepnie
˛
wybieraja˛ pliki
do wysłania. W metodach testowych natomiast nagrania te sa˛ odtwarzane. Funkcjonalność publikacji materiałów multimedialnych została przetestowana lokalnie
na przegladarce
˛
internetowej Google Chrome.
Wszystkie testy funkcjonalne aplikacji dziedzicza˛ po klasie WebTestCase. Domyślnie 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 zmieniona. W metodzie wykonywanej na poczatku
˛
testu o nazwie setUp tworzona jest
nowa sesja przegladarki.
˛
Metoda tearDown jest wykonywana na końcu testu, gdzie
niszczona jest sesja przegladarki.
˛
Wszystkie metody zaimplementowane w obrebie
˛
tej klasy wykorzystuja˛ wspomniana˛ biblioteke˛ kliencka˛ php-webdriver.
5.5.2. Testowanie aplikacji napisanej w Yii
Podstawowym skryptem PHP wykonywanym po odbiorze żadania
˛
HTTP od użytkownika jest skrypt index.php. Skrypt startowy aplikacji, który bedzie
˛
wykonany
po stronie serwera jest zależny od żadania
˛
HTTP. Odnośniki URL otwierane podczas testów posiadaja˛ inna˛ nazwe˛ skryptu - index-test.php. W czasie wykonania skryptu startowego ładowany jest plik konfiguracyjny aplikacji. W pliku tym
znajduje sie˛ mie˛ dzy innymi deklaracja modułów, komponentów oraz parametrów
aplikacji. Dzie˛ ki temu różne pliki konfiguracyjne ładowane sa˛ podczas wykonania różnych skryptów startowych. Rozwiazanie
˛
takie pozwala na skonfigurowanie
5.5. Testy automatyczne aplikacji
69
niezależnych baz danych - bazy produkcyjnej dla głównego skryptu index.php oraz
bazy testowej dla skryptu testowego index-test.php.
Główna˛ klasa˛ udoste˛ pniana˛ przez framework Yii, która została wykorzystana
podczas wykonywania testów jest CDbFixtureManager. Jej główna˛ funkcjonalnościa˛ jest odtwarzanie określonego stanu bazy danych przed każdorazowym wykonaniem metody testowej. W tym celu w klasie testowej deklaruje sie˛ tablice˛ określajac
˛ a,
˛ które tabele powinny być przywrócone do określonego stanu. Stan każdej
tabeli, który chcemy posiadać przed wykonaniem testów określany jest przez plik
zawierajacy
˛ tablice˛ z predefiniowanymi danymi. Pliki te znajduja˛ sie˛ w katalogu
protected/tests/fixtures.
Plikiem konfiguracyjnym testów uruchamianych przez narzedzie
˛
PHPUnit jest
plik phpunit.xml, który znajduje sie˛ w katalogu protected/tests. Zawiera on deklaracje˛ dwóch grup testów. Pierwsza grupa stanowi testy jednostkowe, druga
natomiast testy funkcjonalne. Ponadto w pliku tym znajduje˛ sie˛ nazwa skryptu
PHP, który jest wykonywany przed każdym testem. Jego nazwa to bootstrap.php.
Tworzona jest w nim instancja aplikacji Yii, co pozwala na korzystanie w testach z
wygodnych metod udoste˛ pnianych przez klase˛ CActiveRecord.
Ścieżka zapisu plików wysyłanych do systemu zależy od wykonywanego skryptu
startowego aplikacji. Dla głównego skryptu (index.php) dwupoziomowa struktura
katalogowa oraz pliki umieszczane sa˛ w katalogu uploads. Dla startowego skryptu
testowego (index-test.php) jest to natomiast katalog test_uploads. Katalogi zapisu
plików sa˛ konfigurowalne z poziomu głównego pliku konfiguracyjnego aplikacji o
nazwie main.php umieszczonego w katalogu protected/config.
5.5.3. Środowisko testowe
Z powodu ograniczeń technicznych testy aplikacji zostały przeprowadzone w domowej sieci lokalnej. Aplikacja została przetestowana w poniższych konfiguracjach:
a) na komputerze z systemem operacyjnym Windows Vista Home Premium używajac
˛ klienta 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żywajac
˛
klienta HTTP:
• Google Chrome wersja 21.0.1180.75,
• Mozilla Firefox wersja 12.0,
• Opera wersja 11.62.
Uruchamianie poleceń testowych, które testuja˛ system na różnych przegladar˛
kach i systemach operacyjnych możliwe jest z użyciem skryptu powłoki bash o
nazwie run_tests umieszczonego w katalogu protected/tests.
5.5. Testy automatyczne aplikacji
70
Rysunek 5.9. Środowisko testowe
5.5.4. Wyniki testów
Wygenerowanie statystyki pokrycia kodu dla przetestowanej aplikacji serwerowej zostało przeprowadzone z użyciem biblioteki PHP_CodeCoverage. Łacznie
˛
przeprowadzono 48 testów i dokonano 5427 asercji.
Rysunek 5.10. Pokrycie kodu PHP
6. Podsumowanie
W ramach powstałej pracy inżynierskiej udało sie˛ stworzyć system
e-learningowy posiadajacy
˛
wiele możliwości.
Powstała aplikacja internetowa
posiada podstawowa˛ funkcjonalność założona˛ podczas analizy wymagań funkcjonalnych.
Bardzo dobra˛ decyzja˛ projektowa˛ było zastosowanie framework’a Yii w celu
napisania aplikacji w je˛ zyku PHP. Decyzja ta pozwoliła na znaczne skrócenie czasu
implementacji. Stworzenie systemu w architekturze aplikacji internetowej wiazało
˛
si˛e z pewnymi wymaganiami. Jednym z takich wymagań było przetestowanie
aplikacji na wielu przegladarkach
˛
oraz systemach operacyjnych.
W zwiazku
˛
z tym, iż system ten stworzony został przez jedna˛ osobe˛ nie jest
możliwe, aby jego zakres możliwości był zbliżony do zakresu prezentowanego przez
systemy przedstawione w cze˛ ści teoretycznej pracy. W zwiazku
˛
z tym system został
stworzony z myśla,
˛ aby w pewnym stopniu wyróżniał sie˛ na tle przeanalizowanych
serwisów.
Mój system wyróżnia sie˛ aspektami zwiazanymi
˛
z funkcjonalnościa:
˛
a) publikowanie materiałów multimedialnych jest możliwe zarówno w obrebie
˛
kursu jak i poza nim,
b) możliwe jest wyszukanie materiałów multimedialnych opublikowanych z poziomu kursu,
c) zaimplementowana została dodatkowa lista proponowanych materiałów dla
materiałów należacych
˛
do kursu.
Ponadto w przeciwieństwie do wcześniej opisanych serwisów napisanych w PHP
mój system opiera sie˛ na bardzo nowoczesnym framework’u. Dzieki
˛
temu jego
rozwój jest prostszy, a kod nie jest powielany dzieki
˛ narzedziom,
˛
które udoste˛ pnia
Yii.
Dalsze możliwości rozwoju systemu:
1. Rozwój funkcjonalności zwiazanych
˛
z opublikowanymi materiałami:
• komentowanie materiałów,
• ocenianie materiałów,
• generowanie miniaturek dla dodanych materiałów wideo.
2. Rozwój funkcjonalności zwiazanych
˛
z odtwarzaczem flowplayer:
• oprogramowanie odtwarzacza w celu lepszej interakcji z użytkownikiem,
• zastosowanie protokołu pseudostreaming, który pozwala na przewiniecie
˛
odtwarzanego materiału do dowolnego momentu na osi czasu.
3. Rozwój funkcjonalności zwiazanych
˛
z przetwarzaniem plików:
• rozszerzenie konwersji plików do formatu MP4 z kodowaniem H264,
• umożliwienie użytkownikowi wyboru jakości materiału do odtworzenia.
Narzedzia
˛
implementacji i dokumentacji
Podczas projektowania i implementacji systemu zostały użyte nastepuj
˛
ace
˛ narz˛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życia oraz
diagramu ER,
• ERMaster - tworzenie schematu relacyjnej bazy danych,
• Selenium - wykonywanie testów automatycznych na różnych przegladarkach
˛
i
systemach operacyjnych,
• PHPUnit - tworzenie, uruchomianie oraz konfiguracja testów aplikacji,
• phpPgAdmin - zarzadzanie
˛
baza˛ danych PostgreSQL,
• GIMP, Inkscape - tworzenie wygladu
˛
oraz instrukcji użytkowania systemu,
• phpDocumentor 2 - tworzenie dokumentacji kodu napisanego w PHP.
• cnee - tworzenie testów automatycznych zwiazanych
˛
z publikacja˛ materiałów
multimedialnych.
Załacznik
˛
A: Listy kodeków oraz formatów
wspieranych przez narzedzie
˛
FFmpeg
Lista kodeków, których dekodowanie wspiera narzedzie
˛
FFmpeg:
4xm, 8bps, 8svx_exp, 8svx_fib, aac, aac_latm, aasc, ac3, adpcm_4xm, adpcm_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, adpcm_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, adpcm_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, indeo4, 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, msmpeg4v1, 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łacznik
˛
A: Listy kodeków oraz formatów wspieranych przez narzedzie
˛
FFmpeg
74
Lista formatów, których demuksowanie wspiera narzedzie
˛
FFmpeg:
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łacznik
˛
B: Instrukcja użytkowania systemu
Załacznik
˛
ten przedstawia podstawowe scenariusze użytkowania systemu z podziałem na różnych aktorów wystepuj
˛
acych
˛
w systemie. Jego głównym celem
jest stworzenie użytkownikowi możliwości szybkiego skorzystania z podstawowych
funkcjonalności systemu. Ponadto instrukcja ta ma za zadanie zapoznać użytkownika z możliwościami, interfejsem oraz nawigacja˛ zaimplementowanego systemu.
W celu przedstawienia interakcji użytkownika z systemem oraz rezultatów podejmowanych działań zaprezentowane bed
˛ a˛ zrzuty ekranu.
Podstawowy wyglad
˛ systemu
Rysunek 1. Strona główna systemu
Podstawowe elementy interfejsu graficznego systemu oznaczone na powyższym
zrzucie ekranu to:
1.
2.
3.
4.
5.
Logo systemu.
Wyszukiwarka systemu.
Panel z informacjami logowania.
Menu główne systemu.
Główny kontener HTML przechowujacy
˛ informacje prezentowane użytkownikowi końcowemu.
B.1. Instrukcja dla gościa
B.1: Instrukcja dla gościa
Rejestracja
76
B.1. Instrukcja dla gościa
77
B.1. Instrukcja dla gościa
Wyszukiwanie materiałów multimedialnych
78
B.1. Instrukcja dla gościa
Przegladanie
˛
kursów w systemie
79
B.2. Instrukcja dla ucznia
B.2: Instrukcja dla ucznia
Przegladanie
˛
kursów ucznia
80
B.2. Instrukcja dla ucznia
Logowanie do systemu
81
B.2. Instrukcja dla ucznia
Zapisywanie sie˛ na kurs
82
B.3. Instrukcja dla nauczyciela
B.3: Instrukcja dla nauczyciela
Tworzenie nowego kursu w systemie
83
B.3. Instrukcja dla nauczyciela
84
B.3. Instrukcja dla nauczyciela
Dodawanie materiałów wideo i audio
85
B.3. Instrukcja dla nauczyciela
86
B.3. Instrukcja dla nauczyciela
Zapisanie ucznia na kurs
87
B.4. Instrukcja dla administratora
B.4: Instrukcja dla administratora
Przegladanie
˛
użytkowników
88
B.4. Instrukcja dla administratora
Dodawanie użytkowników do systemu
89
B.4. Instrukcja dla administratora
Usuniecie
˛
użytkownika z systemu
90
B.4. Instrukcja dla administratora
91
Funkcjonalność zwiazana
˛
z usuwaniem i przegladaniem
˛
dotyczy również kursów oraz materiałów istniejacych
˛
w systemie. Sekwencja czynności prowadzaca
˛ do
˛
z tym
realizacji tych działań jest bardzo podobna jak dla użytkowników. W zwiazku
przedstawione wyżej działania dotyczace
˛ użytkowników stanowia˛ wzór postepowa˛
nia przy innych bytach w systemie.
Załacznik
˛
C: Instrukcja instalacji
oprogramowania
Instalacja systemu na serwerze z systemem operacyjnym Linux Ubuntu
11.04
1. Ściagni
˛ e˛ cie i instalacja BitNami LAPPStack - http://bitnami.org/stack/
lappstack.
2. Zbudowanie i instalacja konwertera FFmpeg - https://ffmpeg.org/trac/
ffmpeg/wiki/UbuntuCompilationGuide. Podczas konfiguracji kompilacji narze˛ dzia FFmpeg należy dodać opcje˛ “–enable-shared” oraz usunać
˛
“–enable-libvpx” i “–enable-libx264”.
3. Dodanie do katalogu “/etc/ld.so.conf.d” pliku o nazwie “custom-libs.conf” o
zawartości “/usr/local/lib” oraz wykonanie polecenia “ldconfig”. Dzieki
˛ temu
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 BitNami LAPPStack/php/lib/php/extensions”.
6. Skopiowanie na serwer plików z aplikacja˛ i framework’iem Yii.
7. Konfiguracja serwera WWW Apache oraz PHP (pliki konfiguracyjne znajduja˛
sie˛ na płycie CD).
Instalacja narzedzi
˛
potrzebnych do testowania
1. Instalacja PHPUnit - https://github.com/sebastianbergmann/phpunit/.
2. Instalacja XDebug - http://xdebug.org/docs/install.
3. Ściagni
˛ e˛ cie serwera Selenium - http://seleniumhq.org/download/.
Załacznik
˛
D: Zawartość dołaczonej
˛
płyty CD
Struktura katalogowa plików w głównym katalogu o nazwie webapp wyglada
˛
nast˛epujaco:
˛
webapp/
praca_inż.pdf.......................................Tekst pracy inżynierskiej
config_files.........................Pliki konfiguracyjne (Apache oraz PHP)
www........................................Główny katalog z wszystkimi plikami
framework...............................................Pliki framework’a Yii
multimedia_cms...................................Pliki stworzonej aplikacji
Bibliografia
[1] Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom. Systemy baz danych. Kompletny podrecznik.
˛
Wydawnictwo Helion, wydanie drugie, 2011.
[2] Krzysztof Sacha. Inżynieria oprogramowania. Wydawnictwo Naukowe PWN, wydanie
pierwsze, 2010.
[3] Leon Shklar, Rich Rosen. Web Application Architecture: Principles, Protocols and Practices. 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żliwości Plumi. http://en.flossmanuals.net/plumi/ch003_key-features/.
[9] Możliwości systemu Moodle. http://docs.moodle.org/20/en/Features.
[10] Możliwości systemu PHPmotion. http://phpmotion.com/content/view/17/33/.
[11] Podstawowa funkcjonalność 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.
                                     doc
                    doc download
															download                                                         Reklamacja
															Reklamacja                                                         
		     
		     
		     
		    