System do zarz ˛adzania archiwum obrazów ISO

Transkrypt

Politechnika Warszawska
Wydział Elektroniki i Technik
Informacyjnych
Instytut Informatyki
Rok akademicki 2013/2014
Praca dyplomowa inżynierska
Michał Daniel Toporowski
System do zarzadzania
˛
archiwum
obrazów ISO - aplikacja w
architekturze trójwarstwowej
Opiekun pracy:
dr inż. Jarosław Dawidczyk
Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specjalność: Informatyka – Inżynieria
systemów informatycznych
Data urodzenia: 14 marca 1991 r.
Data rozpoczecia
˛
studiów: 1 października 2010 r.
Życiorys
Nazywam si˛e . . . .
.....................................
podpis studenta
Egzamin dyplomowy
Złożył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..................................................................................
Streszczenie
Praca ta prezentuje proces tworzenia systemu do zarzadzania
˛
archiwum
obrazów ISO dla ośrodków edukacyjnych, zbudowanego przy wykorzystaniu
architektury trójwarstwowej. W ramach pracy przedstawiono zagadnienie i
technologie wybrane do jego realizacji, model funkcjonalny i model danych
oraz sposób implementacji i testowania.
Słowa kluczowe: archiwum ISO, podrecznik,
˛
architektura trójwarstwowa
Abstract
Title: An ISO archive management system - an application in the three-tier
architecture
This thesis describes the development process of an ISO archive management system based on the three-tier architecture. The thesis presents the
matter, the technologies chosen for its realisation, the functional and data
model, as well as the methods of implementation and testing.
Key words: ISO archive, manual, three-tier architecture
Spis treści
1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1. Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2. Opis dziedziny . . . . . . . . . . . . .
2.1. Poje˛ cia dotyczace
˛ zagadnienia . .
2.1.1. Podre˛ cznik . . . . . . . . .
2.1.2. Archiwum ISO . . . . . . .
2.1.3. Wersjonowanie . . . . . . .
2.1.4. Użytkownik . . . . . . . . .
2.2. Rozwiazania
˛
obecne na rynku . .
2.2.1. Obecny system OKNO PW
2.2.2. Dropbox . . . . . . . . . . .
2.2.3. Rapidshare . . . . . . . . .
2.2.4. QNAP . . . . . . . . . . . .
2.2.5. Podsumowanie . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
3
3
4
4
4
5
6
6
6
3. Opis technologii . . . . . . . . . . . .
3.1. Architektura trójwarstwowa . . .
3.1.1. Warstwa prezentacji . . . .
3.1.2. Warstwa logiki aplikacji . .
3.1.3. Warstwa danych . . . . . .
3.2. Je˛ zyk programowania . . . . . . .
3.3. System zarzadzania
˛
baza˛ danych
3.3.1. Oracle . . . . . . . . . . . .
3.3.2. HSQLDB . . . . . . . . . . .
3.3.3. MySQL . . . . . . . . . . . .
3.3.4. PostgreSQL . . . . . . . . .
3.3.5. Podsumowanie . . . . . . .
3.4. Doste˛ p do danych . . . . . . . . .
3.4.1. JDBC . . . . . . . . . . . .
3.4.2. Hibernate . . . . . . . . . .
3.5. Szkielet budowy aplikacji . . . . .
3.5.1. Spring . . . . . . . . . . . .
3.5.2. EJB . . . . . . . . . . . . .
3.5.3. ObjectLedge . . . . . . . . .
3.5.4. Podsumowanie . . . . . . .
3.6. Technologie warstwy prezentacji .
3.6.1. Szablony Velocity . . . . . .
3.6.2. JQuery . . . . . . . . . . . .
3.6.3. Ajax . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
8
9
9
10
11
11
11
12
12
12
12
13
14
14
15
15
16
17
17
17
18
ii
Spis treści
3.7. Technologie wspierajace
˛ testowanie . . . . .
3.7.1. JUnit . . . . . . . . . . . . . . . . . . .
3.7.2. DBUnit . . . . . . . . . . . . . . . . .
3.8. Dodatkowe narze˛ dzia . . . . . . . . . . . . .
3.8.1. Budowanie aplikacji - Apache Maven
3.8.2. Kontrola wersji - Git . . . . . . . . . .
3.9. Podsumowanie . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
20
20
21
21
4. Model funkcjonalny . . . . . . . . . . .
4.1. Aktorzy systemu . . . . . . . . . . .
4.2. Wymagania funkcjonalne . . . . . .
4.2.1. Wymagania bezpieczeństwa
4.2.2. Podre˛ czniki . . . . . . . . . .
4.2.3. Przedmioty . . . . . . . . . .
4.2.4. Osoby . . . . . . . . . . . . .
4.2.5. Zarzadzanie
˛
aktualizacja˛ . .
4.3. Makiety . . . . . . . . . . . . . . . .
4.4. Przypadki użycia . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
23
24
24
25
25
26
26
26
5. Model danych . . . . . . . . . . . . .
5.1. Model logiczny . . . . . . . . . .
5.1.1. Osoba . . . . . . . . . . .
5.1.2. Rola . . . . . . . . . . . .
5.1.3. Jednostka organizacyjna
5.1.4. Typ jednostki . . . . . . .
5.1.5. Przedmiot . . . . . . . . .
5.1.6. Archiwum . . . . . . . . .
5.1.7. Wersja archiwum . . . . .
5.1.8. Folder . . . . . . . . . . .
5.1.9. Plik . . . . . . . . . . . . .
5.2. Model fizyczny . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
31
31
31
32
32
32
33
33
33
6. Implementacja . . . . . . . . . . . . . . . . . . . . . .
6.1. Automatyczna aktualizacja archiwów . . . . . . .
6.1.1. Wykrywanie zmian w katalogach . . . . .
6.1.2. Raportowanie zmian w katalogach . . . . .
6.1.3. Generowanie i udostepnienie
˛
nowej wersji
6.1.4. Pobieranie archiwów . . . . . . . . . . . . .
6.2. Doste˛ p do danych . . . . . . . . . . . . . . . . . .
6.2.1. Obiekty POJO oraz DAO . . . . . . . . . .
6.2.2. Filtrowanie danych . . . . . . . . . . . . . .
6.3. Mechanizmy bezpieczeństwa . . . . . . . . . . . .
6.3.1. Mechanizm kont użytkowników . . . . . .
6.3.2. System bezpieczeństwa ObjectLedge’a . .
6.3.3. Integracja mechanizmów . . . . . . . . . .
6.4. Technologia AJAX . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
36
37
38
39
39
39
40
41
41
42
43
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7. Testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1. Testy jednostkowe przy użyciu DBUnit . . . . . . . . . . . . . . . . . . . 46
8. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A. Wyglad
˛ gotowej aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Spis treści
iii
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Wprowadzenie
1.1. Motywacja
Inspiracja˛ dla niniejszej pracy było zapotrzebowanie Ośrodka Kształcenia na Odległość Politechniki Warszawskiej (OKNO PW) na system do
zarzadzania
˛
podrecznikami.
˛
W ramach procesu nauczania, istnieje potrzeba
udost˛epniania materiałów dydaktycznych studentom uczestniczacym
˛
w zajeciach
˛
prowadzonych przez ośrodek. System istniejacy
˛
obecnie umożliwia publikacj˛e podreczników
˛
w formie archiwów ISO. Pojawia si˛e jednak
problem zwiazany
˛
z faktem, że treści podre˛ czników cz˛esto ulegaja˛ zmianie i
wówczas konieczne jest reczne
˛
zlokalizowanie zmian, ponowne zbudowanie
archiwum i udost˛epnienie go użytkowikom. Rozwiazaniem
˛
tego problemu
byłby system, który pozwoliłby na automatyzacj˛e tego procesu.
1.2. Cel pracy
Celem pracy jest stworzenie systemu do zarzadzania
˛
archiwum obrazów
ISO dla uczelni wyższych, posiadajacego
˛
funkcjonalność automatycznej aktualizacji archiwów. System zostanie zbudowany przy wykorzystaniu architektury trójwarstowej.
2. Opis dziedziny
Zadaniem systemu, który jest przedmiotem niniejszej pracy, jest umożliwienie ośrodkom edukacyjnym sprawnego udost˛epniania multimedialnych materiałów dydaktycznych. Z założenia, materiały udost˛epniane sa˛
użytkownikom w ramach kursów, w których uczestnicza,
˛ zaś treść materiałów może ulegać zmianom.
Rozważany system byłby wykorzystywany przez użytkowników zdalnych,
toteż pożadane
˛
jest, aby zasoby były publikowane w uniwersalnym formacie, a dost˛ep do nich był w jak najwi˛ekszym stopniu niezależny od platformy sprz˛etowo-programowej użytkownika. Z powodu zmienności treści
materiałów oczekiwane jest, aby proces ich aktualizacji wymagał minimalnych nakładów pracy od autorów oraz osób zarzadzaj
˛
acych
˛
systemem, zaś
dla użytkowników końcowych zachodził w sposób całkowicie przezroczysty.
Istotna˛ kwestia˛ jest także zapewnienie, aby użytkownicy posiadali dost˛ep
jedynie do materiałów dotyczacych
˛
kursów, w których uczestnicza˛ oraz
umożliwienie nadzorowania kursu przez osob˛e go prowadzac
˛ a.
˛
2.1. Pojecia
˛
dotyczace
˛ zagadnienia
Poniżej wymieniono najważniejsze elementy i poj˛ecia zwiazane
˛
z zagadnieniem. Ze wzgl˛edu na motywacj˛e i przeznaczenie pracy, zdecydowano si˛e
na wykorzystanie terminologii osadzonej w rzeczywistości uczelni wyższej,
niemniej system spełniajacy
˛ podane założenia mógłby posiadać również zastosowanie w innych organizacjach.
3
2.1. Pojecia
˛
dotyczace
˛ zagadnienia
2.1.1. Podrecznik
˛
Podrecznik
˛
jest zasobem udost˛epnianym studentom w systemie.
Po-
drecznik
˛
posiada form˛e płyty, zawierajac
˛ a˛ materiały dydaktyczne w formie
elektronicznej, w skład której moga˛ wchodzić np. treści tekstowe i multimedialne oraz interaktywna aplikacja pozwalajac
˛ a˛ na ich przegladanie.
˛
Podreczniki
˛
sa˛ zorganizowane w ramach przedmiotów - kursów posiadajacych
˛
uczestników (studentów) oraz osob˛e prowadzac
˛ a˛ (wykładowc˛e).
2.1.2. Archiwum ISO
Archiwum ISO, nazywane również obrazem ISO jest to format zapisu
danych dysków optycznych. Obraz jest plikiem, zazwyczaj posiadajacym
˛
rozszerzenie .iso, zawierajacym
˛
dokładne odwzorowanie binarnych danych
danego nośnika optycznego. W skład obrazu wchodza˛ dane i metadane
zorganizowane w systemie plików ISO 9660 (dla nośnika typu CD) lub UDF
(dla nośników DVD oraz Blu-ray).
Obrazy ISO sa˛ stosowane m.in.
do
emulacji nap˛edów optycznych oraz wymiany płyt poprzez sieć.
W systemie służacym
˛
do udost˛epniania multimedialnych podre˛ czników
studentom, wygodnym wydaje si˛e być rozwiazanie,
˛
w którym podre˛ cznik
jest dost˛epny jako obraz płyty możliwy do pobrania poprzez aplikacj˛e internetowa.
˛ Format ISO jest uniwersalny i pozwala na dokładne zapisanie
danych nośnika. Powszechnie dost˛epne programy umożliwiaja˛ bezpośrednie nagranie obrazu na płyt˛e, badź
˛ zamontowanie go w systemie jako dysku
wirtualnego.
2.1.3. Wersjonowanie
Treści podreczników
˛
moga˛ ulegać zmianom w skutek np. pojawienia si˛e
nowej wiedzy, czy wykrycia bł˛edów. Istotne jest zapewnienie studentom
dostepu
˛
do aktualnej wersji. Ponadto, pożadany
˛
byłby mechanizm kontroli wersji, pozwalajacy
˛ na przywrócenie poprzedniej wersji archiwum w
przypadku bł˛edu, badź
˛ tworzenie wersji niepublikowanych w systemie (np.
testowych).
2.2. Rozwiazania
˛
obecne na rynku
4
2.1.4. Użytkownik
Spośród osób wykorzystujacych
˛
omawiany system można wyróżnić 4
główne kategorie. Pierwsza˛ kategoria˛ jest Student, czyli osoba posiadajaca
˛
możliwość pobierania materiałów dydaktycznych dotyczacych
˛
przedmiotów, na które jest zapisany. Ponadto, istnieje Wykładowca, czyli osoba
prowadzaca
˛
i nadzorujaca
˛
przedmioty. Doktorant łaczy
˛
w sobie funkcje
studenta i wykładowcy. W stosunku do przedmiotów, na które ucz˛eszcza
posiada cechy studenta, zaś w stosunku do przedmiotów przez siebie
prowadzonych - cechy wykładowcy. Niezb˛edna jest również osoba zarzadza˛
jaca
˛ systemem, czyli Administrator.
2.2. Rozwiazania
˛
obecne na rynku
Na rynku nie istnieje system dokładnie realizujacy
˛ opisane założenia, ale
jest obecnych wiele rozwiaza
˛ ń realizujacych
˛
pewien zakres funkcjonalności
wymaganych dla tej aplikacji, dlatego zdecydowano si˛e przedstawić kilka z
nich, zwracajac
˛ uwag˛e na funkcje istotne z punktu widzenia omawianego
zagadnienia.
2.2.1. Obecny system OKNO PW
System obecnie używany w OKNO PW pozwala zalogowanym użytkownikom/studentom na dost˛ep do podre˛ czników dotyczacych
˛
kursów, w
których uczestnicza.
˛ Typowy podre˛ cznik zawiera treści w formacie HTML
lub PDF, pliki multimedialne, pliki XML opisujace
˛ jego strukture˛ oraz interaktywna˛ aplikacj˛e pozwalajac
˛ a˛ na przegladanie
˛
treści. Całość materiałów jest udost˛epniana studentom poprzez stron˛e internetowa˛ jako obraz
nośnika optycznego w formacie ISO.
Funkcjonalnościa,
˛ jakiej system nie posiada jest automatyczna aktualizacja archiwów. Specyfika udost˛epnianych treści wymaga co pewien czas
ich modyfikacji, np. gdy w treści wykryto bład,
˛ badź
˛ zachodzi potrzeba jej
rozszerzenia. Wówczas konieczne jest zbudowanie nowego obrazu płyty i zastapienie
˛
nim obecnego na serwerze pliku. Nakłada to na administratorów
5
2.2. Rozwiazania
˛
obecne na rynku
żmudne zaj˛ecie recznego
˛
tworzenia i udost˛epniania archiwów. Nie istnieje
również żaden mechanizm kontroli wersji.
2.2.2. Dropbox
Rozwiazaniem,
˛
które zawiera cz˛eść poruszanych tu zagadnień sa˛ systemy synchronizacji i udost˛epniania plików, takie jak Dropbox. W systemie Dropbox użytkownik posiada swój katalog na serwerze, w którym
może umieszczać pliki i foldery. Możliwe jest przegladanie
˛
katalogu przy
użyciu strony internetowej, badź
˛ instalacja aplikacji klienckiej, która synchronizuje zawartość katalogu zdalnego z katalogiem lokalnym. Lokalny
katalog jest skanowany na bieżaco
˛ i w razie wykrycia zmiany aktualna wersja wysyłana jest na serwer, analogicznie w przypadku zmiany pliku na
serwerze, plik jest pobierany do katalogu lokalnego. Zaimplementowana
jest także kontrola wersji - domyślnie przechowywana jest historia zmian
z ostatnich 30 dni i użytkownik posiada możliwość przywrócenia starszej
wersji danego pliku. Użytkownik posiada również tzw. katalog publiczny pliki umieszczone w nim sa˛ dost˛epne dla wszystkich użytkowników Internetu dysponujacych
˛
adresem URL. Dropbox posiada również wiele innych
funkcjonalności np. współdzielenie folderów, czy wykrywanie konfliktów
plików.
Wykorzystanie systemu Dropbox w kontekście omawianego zagadnienia
mogłoby polegać na przechowywaniu treści w katalogach współdzielonych
i przyznaniu dost˛epu do nich użytkownikom.
Pozwalałoby to jednak
użytkownikom na wykonywanie dowolnych czynności na udost˛epnianych
plikach, co nie byłoby wskazane.
Alternatywnym rozwiazaniem
˛
byłoby
umieszczenie treści w katalogu publicznym i udost˛epnienie użytkownikom
jedynie adresów URL do plików. Nie jest to jednak wystarczajace.
˛
W celu realizacji założeń konieczne byłoby jednak dodatkowej aplikacji zarzadzaj
˛
acej
˛
i udost˛epniajacej
˛
adresy użytkownikom do tego uprawnionym.
2.2. Rozwiazania
˛
obecne na rynku
6
2.2.3. Rapidshare
Kolejna˛ grupa˛ systemów spełniajacych
˛
cz˛eść opisanych założeń sa˛ internetowe portale służace
˛ do udost˛epniania plików, np. Rapidshare. Serwis
taki pozwala użytkownikowi na przesłanie na serwer pliku, który nast˛epnie b˛edzie możliwy do pobrania przez innych użytkowników sieci poprzez
podanie adresu URL. Wprawdzie system jest wykorzystywany głównie do
udost˛epniania pojedynczych plików, ale jest dost˛epna również aplikacja
pozwalajaca
˛ na zamontowanie sieciowego folderu jako wirtualnego dysku
w systemie Windows i zarzadzanie
˛
plikami z poziomu menedżera plików.
Podobnie, jak Dropbox, serwis Rapidshare jest dobrym narz˛edziem do
wymiany plików, natomiast nie jest to rozwiazanie
˛
wystarczajace
˛ do realizacji omawianego zagadnienia, gdyż użytkownikowi końcowemu może być
udost˛epniony jedynie zbiór adresów URL.
2.2.4. QNAP
QNAP Inc. dostarcza rozwiaza
˛ ń dla biznesu z zakresu sieciowego składowania danych.
Ilość oferowanych usług jest bardzo duża, natomiast
w kontekście tej pracy godna uwagi jest usługa współdzielonego folderu
ISO. QNAP umożliwia zamontowanie obrazu ISO jako sieciowego folderu
współdzielonego i dost˛ep do zawartych w nim plików przy użyciu aplikacji
webowej.
Jest to interesujace
˛
rozwiazanie,
˛
lecz brakuje mu dostosowania do
potrzeb ośrodka kształcenia, umożliwiajacego
˛
zarzadzanie
˛
kursami i ich
uczestnikami.
2.2.5. Podsumowanie
Rozwiazania
˛
obecnie dost˛epne na rynku pozwalaja˛ na spełnienie jedynie cz˛eści przyj˛etych założeń. Nie istnieje jednak system, który w całości
odpowiadałby potrzebom wynikajacym
˛
z zagadnienia. Stworzenie takiego
systemu umożliwiłoby ośrodkom edukacyjnym udost˛epnianie materiałów
dydaktycznych w sposób wygodny dla uczestników kursów, prowadzacych
˛
oraz administratorów.
3. Opis technologii
Istotnym etapem projektowania systemu jest wybór technologii, w jakiej
zostanie zbudowany. Składa si˛e na to wybór architektury systemu, j˛ezyka
programowania, technologii używanych do prezentacji oraz przechowywania danych, jak również decyzja o wykorzystaniu lub nie zewn˛etrznych
szkieletów i bibliotek. Ważne jest rozpoznanie rynku pod katem
˛
dost˛epnych
rozwiaza
˛ ń i wybranie najlepszych dla projektowanego systemu.
Przed przystapieniem
˛
do wyboru architektury i technologii warto zastanowić si˛e, jakie stoja˛ przed nimi wymagania w kontekście funkcji realizowanych przez system.
System b˛edzie wykorzystywany przez wielu
użytkowników, z których wi˛ekszość b˛edzie logowała si˛e do niego zdalnie,
przy użyciu własnych maszyn. Dobrym rozwiazaniem
˛
wydaje si˛e wi˛ec realizacja interfejsu użytkownika w postaci aplikacji webowej. W ten sposób
można oszcz˛edzić użytkownikom prac˛e zwiazan
˛
a˛ z instalacja˛ i konfiguracja˛ aplikacji oraz wyeliminować problemy zwiazane
˛
z kompatybilnościa˛
z platforma˛ sprz˛etowa˛ i programowa˛ użytkowników. Do obsługi wystarczajaca
˛ jest przegladarka
˛
internetowa kompatybilna z powszechnie przyj˛etymi
standardami. Ponadto, do pracy systemu niezb˛edne jest przechowywanie
danych dotyczacych
˛
m.in. użytkowników, przedmiotów, czy podre˛ czników.
Wymagany jest również moduł, który realizowałby operacje biznesowe oraz
wymieniał dane z użytkownikami.
3.1. Architektura trójwarstwowa
Wzorcem, która wpasowuje si˛e w podane wyżej wymagania jest architektura trójwarstwowa.
Zakłada ona rozdzielenie aplikacji na 3 warstwy -
warstw˛e prezentacji, logiki aplikacji oraz danych.
Warstwy komunikuja˛
8
3.1. Architektura trójwarstwowa
sie˛ ze soba,
˛ ale stanowia˛ niezależne moduły. Rozwiazanie
˛
takie niesie ze
soba˛ wiele zalet, wśród których warto wymienić możliwość realizacji warstw
przy użyciu różnych technologii, czy możliwość rozproszenia systemu na
oddzielne maszyny w celu zwi˛ekszenia wydajności. Również, w przypadku
konieczności zmian w jednej z warstw, pozostałe nie powinny zostać nimi
dotkni˛ete. Poniżej została przedstawiona charakterystyka każdej z warstw.
3.1.1. Warstwa prezentacji
Górna warstwa w architekturze trójwarstwowej to warstwa prezentacji,
czyli graficzny interfejs użytkownika.
Jej podstawowa funkcja to przyj-
mowanie poleceń użytkownika i prezentacje wyników w zrozumiałej dla
niego postaci. Nie powinna natomiast zawierać kodu wykonujacego
˛
operacje biznesowe lub dost˛ep do danych. Jest to jedyna warstwa wchodzaca
˛ w
interakcje z użytkownikiem systemu.
Warstwa prezentacji jest realizowana jako strona webowa, dostepna
˛
poprzez przegladark˛
˛
e internetowa˛ klienta. Istnieja˛ dwie koncepcje jej realizacji, tzw. cienki i gruby klient. W koncepcji cienkiego klienta, wszystkie operacje wykonywane sa˛ po stronie serwera, zaś przegladarka
˛
klienta
dostaje jedynie statyczne treści. Koncepcja grubego klienta zakłada wykonywanie cz˛eści operacji po stronie klienta, dzi˛eki czemu strony staja˛ si˛e dynamiczne. Obecnie coraz cz˛eściej wykorzystywana jest druga koncepcja,
ponieważ dynamiczne treści pozwalaja˛ zwi˛ekszyć komfort i ergonomi˛e pracy.
3.1.2. Warstwa logiki aplikacji
Środkowa˛ warstwa˛ jest warstwa logiki aplikacji, która odpowiada za
przetwarzanie poleceń użytkownika, wykonywanie obliczeń i operacji biznesowych realizujacych
˛
funkcjonalności systemu oraz przekazywanie i
przetwarzanie danych pomi˛edzy pozostałymi warstwami.
Do implementacji warstwy logiki zazwyczaj wykorzystywany jest obiektowy j˛ezyk programowania.
To pozwala na lepsze odwzorowanie natury
świata, który również jest obiektowy. J˛ezyki obiektowe dostarczaja˛ wiele
mechanizmów zwi˛ekszajacych
˛
efektywność procesu programowania, a także
3.2. Jezyk
˛
programowania
9
czytelność i łatwość utrzymania kodu, np. dziedziczenie, abstrakcyjność,
przecia˛żanie metod, hermetyzacja, czy szeroki zestaw narz˛edzi.
3.1.3. Warstwa danych
Warstwa danych odpowiada za składowanie, pobieranie i zapis danych.
Do tego celu w aplikacjach trójwarstwowych wykorzystywana jest najcz˛eściej relacyjna baza danych. Przemawia za tym wiele argumentów, wśród
których warto wymienić prosty i uniwersalny sposób reprezentacji danych,
standardowy mechanizm dost˛epu w postaci j˛ezyka SQL, czy dost˛epne w
nich mechanizmy transakcyjności i synchronizacji.
3.2. Jezyk
˛
programowania
Podstawowa˛ kwestia˛ przy wyborze technologii realizacji systemu informatycznego jest wybór j˛ezyka programowania. Jak wcześniej pokazałem,
pożadane
˛
jest użycie j˛ezyka opartego na paradygmacie obiektowym. Obecnie w tej dziedzinie na rynku konkuruja˛ dwie kluczowe technologie - Java
oraz C#.
Java
Java jest obiektowym je˛ zykiem programowania stworzonym przez Sun
Microsystems, a obecnie rozwijanym przez Oracle. Cecha˛ charakterystyczna˛
jest kompilacja kodu źródłowego do kodu bajtowego wykonywanego przez
maszyn˛e wirtualna.
˛ Pozwala to na zachowanie niezależności od systemu
operacyjnego i architektury sprz˛etu. Java pozwala na użycie wielu mechanizmów programowania obiektowego takich, jak klasy, interfejsy, dziedziczenie, metody wirtualne i abstrakcyjne, czy klasy anonimowe. Wśród innych istotnych cech tego j˛ezyka należy wymienić wbudowane wsparcie dla
wielowatkowości,
˛
restrykcyjna˛ obsług˛e wyjatków,
˛
automatyczne zwalnianie
pami˛eci przy użyciu garbage collectora oraz pakietowanie.
C#
Najwi˛ekszym konkurentem j˛ezyka Java jest C# opracowany przez firm˛e
Microsoft. Docelowym środowiskiem programów napisanych w tym j˛ezyku
10
˛
baza˛ danych
jest platforma .NET. C# posiada wiele cech wspólnych z Java˛ m.in. kluczowe
mechanizmy obiektowości, automatyczne zwalnianie pami˛eci oraz obecność
warstwy pośredniej pomi˛edzy aplikacja˛ a systemem operacyjnym. Do interesujacych
˛
właściwości j˛ezyka C# warto zaliczyć delegaty, wyrażenia lambda i
typy domniemane i anonimowe.
Istotnym ograniczeniem w przypadku aplikacji wykorzystujacych
˛
j˛ezyk
C# jest fakt, iż ich środowisko pracy, czyli .NET Framework zaimplementowano jedynie w systemie operacyjnym Microsoft Windows. Istnieja˛
wprawdzie alternatywne implementacje takie, jak Mono, czy DotGNU, które
współpracuja˛ z innymi systemami, lecz w momencie pisania tej pracy projekty te nie były jeszcze gotowymi i stabilnymi rozwiazaniami.
˛
Podsumowanie
Jezyki
˛
C# i Java oferuja˛ podobne standardy dla programisty. Ze wzgl˛edu
na wi˛eksza˛ otwartość i brak ograniczeń zwiazanych
˛
z platforma˛ został
wybrany j˛ezyk Java.
˛
baza˛ danych
Po ustaleniu, że dane systemu b˛eda˛ przechowywane przy pomocy relacyjnej bazy danych, kolejnym krokiem jest wybranie systemu zarzadza˛
nia baza˛ danych (ang. DBMS. Database Management System). Zadaniem
takiego systemu jest przechowywanie danych oraz umożliwienie wykonywania na nich operacji przy użyciu kwerend w j˛ezyku SQL.
Istotne właściwości, jakie powinna spełniać baza danych opisuje si˛e
skrótem ACID (ang. atomicity, consistency, isolation, durability), czyli atomowość, spójność, izolacja i trwałość.
Gwarantuja˛ one, że transakcje,
czyli pojedyncze operacje na danych z logicznego punktu widzenia, b˛eda˛
przetwarzane poprawnie, a baza nie b˛edzie zawierała niespójnych danych. Z
uwagi na fakt, że projektowany system nie b˛edzie produktem komercyjnym,
istotne jest również, aby system zarzadzania
˛
baza˛ danych był w pełni darmowy.
˛
baza˛ danych
11
3.3.1. Oracle
Jednym z najważniejszych rozwiaza
˛ ń na rynku baz danych jest baza Oracle. Posiada ona wiele wersji komercyjnych różniacych
˛
si˛e możliwościami.
Oracle wspiera szereg technologii bazodanowych, takich jak transakcyjność,
indeksowanie, partycjonowanie, zmaterializowane perspektywy, zaawansowane operacje na złaczeniach
˛
czy mechanizmy bezpieczeństwa. Dostarcza
również własny j˛ezyk proceduralny PL/SQL.
Do użytku darmowego dost˛epna jest wersja Oracle Database Express
Edition, która posiada ona jednak istotne ograniczenia. Na przechowywanie
danych użytkownika może być użyte maksymalnie 11GB przestrzeni
dyskowej, zaś SZBD może wykorzystywać maksymalnie jeden procesor i
1GB pami˛eci.
3.3.2. HSQLDB
HSQLDB jest systemem zarzadzania
˛
baza˛ danych napisanym w j˛ezyku
Java, wspierajacym
˛
wi˛ekszość technologii bazodanowych. Cecha˛ charakterystyczna˛ tej bazy jest brak konieczności instalacji, co czyni ja˛ bardzo
dobrym rozwiazaniem
˛
do wykorzystania w trakcie prac nad systemem. Nie
jest jednak cz˛esto wykorzystywana jako środowisko produkcyjne, co jest
spowodowane głównie mniejsza˛ wydajnościa˛ przy dużej ilości danych w stosunku do innych baz danych.
3.3.3. MySQL
Jednym z bardziej rozpowszechnionych systemów baz danych jest
MySQL. W poczatkowym
˛
okresie rozwoju, pod adresem tej technologii
kierowane było wiele słów krytyki, ponieważ nie była zgodna ze standardem SQL i nie wspierała kluczowych mechanizmów takich, jak transakcje.
Niemniej, szybkość odczytu danych z tej bazy spowodowała, że zdobyła
ona duża˛ popularność wśród twórców stron internetowych. Obecne wersje
MySQL wspieraja˛ już wi˛ekszość standardów SQL. W porównaniu z innymi
systemami baz danych MySQL posiada jednak nadal wiele braków, m.in.
3.4. Dostep
˛ do danych
12
ignowanie klauzul CHECK, czy ograniczone wsparcie dla indeksów i wi˛ezów
integralności.
3.3.4. PostgreSQL
PostgreSQL jest darmowym systemem zarzadzania
˛
baz danych, w pełni
zgodnym ze standardem ACID. W odróżnieniu od MySQL, jest technologia˛
od lat uznawana˛ i cieszac
˛ a˛ si˛e dobra˛ reputacja˛ w świecie baz danych. Posiada m.in. wsparcie dla wi˛ezów integralności, złacze
˛ ń, widoków, wyzwalaczy
i indeksowania.
Dostarcza również interfejsów dla wielu j˛ezyków pro-
gramowania, w tym Javy. Pozwala na wykonywanie procedur składowanych
utworzonych we wspieranych j˛ezykach lub własnym j˛ezyku proceduralnym
PL/pgSQL. PostgreSQL posiada otwarty kod źródłowy i wysokie możliwości
rozszerzania i dostosowania do własnych potrzeb.
3.3.5. Podsumowanie
Do realizacji warstwy danych w niniejszym systemie wybrano baz˛e
danych PostgreSQL. Nie nakłada ona zb˛ednych ograniczeń i wydaje si˛e posiadać najwi˛eksze możliwości spośród darmowych rozwiaza
˛ ń.
3.4. Dostep
˛ do danych
Po wyborze bazy danych oraz j˛ezyka programowania, należy si˛e zdecydować, w jaki sposób te dwie technologie b˛eda˛ połaczone,
˛
innymi słowy,
w jaki sposób b˛edzie zrealizowany dost˛ep do warstwy danych z poziomu
warstwy logiki aplikacji.
3.4.1. JDBC
Podstawowym sposobem na dost˛ep do bazy danych z poziomu aplikacji
napisanej w j˛ezyku Java jest technologia JDBC. Aby wykonać operacj˛e
na bazie danych przy użyciu JDBC konieczna jest inicjalizacja sterownika
dedykowanego dla danej bazy danych, nast˛epnie nawiazanie
˛
połaczenia
˛
i
wykonanie zapytań SQL.
13
3.4. Dostep
˛ do danych
JDBC jest dobrym rozwiazaniem
˛
dla systemów, w których istnieje
niewielka liczba rodzajów zapytań do bazy danych.
temów, rozwiazanie
˛
takie nie jest wystarczajace.
˛
Dla wi˛ekszych sys-
Konieczność re˛ cznego
tworzenia zapytań SQL na podstawie danych w postaci obiektowej jest zazwyczaj pracochłonne. Kod implementujacy
˛ takie operacje jest nieczytelny,
a co za tym idzie, podatny na bł˛edy i trudny w utrzymaniu.
Ponadto
rozwiazanie
˛
nie jest przenośne - zmiana typu bazy danych może powodować
konieczność zmian w kodzie, co jest niezgodne z przyj˛etym założeniem
rozłaczności
˛
warstw danych i logiki aplikacji.
3.4.2. Hibernate
Unikni˛ecie problemów zwiazanych
˛
z przejściem z warstwy danych opartej
paradygmacie relacyjnym do warstwy logiki aplikacji opartej na paradygmacie obiektowym jest możliwe dzi˛eki wykorzystaniu technologii mapowania
obiektowo-relacyjnego (ang. ORM, Object-Relational Mapping). Najpopularniejszym narz˛edziem pozwalajacym
˛
na wykorzystanie tej technologii jest
Hibernate.
Hibernate stanowi zestaw bibliotek dla j˛ezyka Java. Z poziomu warstwy
aplikacji widoczne sa˛ tzw. obiekty trwałe (ang. persistence objects), nazywane również encjami, jako że odpowiadaja˛ encjom z obiektowego modelu
danych. Te obiekty zarzadzane
˛
sa˛ przez biblioteki Hibernate’a, który przy
użyciu JDBC wykonuje odpowiednie operacje na bazie danych. Wykonywanie operacji na danych nie wymaga wykorzystywania SQL-a specyficznego dla danej bazy.
Proste operacje np.
zapis encji sa˛ dost˛epne
bezpośrednio poprzez interfejsy Hibernate’a, bardziej skomplikowane moga˛
być realizowane przy użyciu HQL, czyli obiektowego j˛ezyka zapytań bazujacego
˛
na encjach lub mechanizmu kryteriów, który pozwala na zbudowanie
zapytania w całkowicie obiektowy sposób.
Przejście pomi˛edzy warstwa˛ relacyjna˛ a obiektowa˛ opiera si˛e na zdefiniowaniu mapowania, w którym odpowiednim bytom ze świata obiektowego
takim, jak klasy i pola, przypisywane sa˛ odpowiadajace
˛ im byty w świecie
relacyjnym takie, jak tabele i kolumny. Mapowania moga˛ być utworzone na
3.5. Szkielet budowy aplikacji
14
dwa sposoby - przy użyciu adnotacji JPA (Java Persistence API) oraz HBM
(Hibernate Mapping), czyli plików XML definiujacych
˛
powiazania
˛
pomi˛edzy
klasami a danymi w strukturze relacyjnej.
Warto podkreślić również, że w aplikacji napisanej zgodnie z dobrymi
praktykami, programista operuje jedynie na obiektach POJO, natomiast
wszystkie operacje bazodanowe sa˛ wykonywane przez szkielet Hibernate,
co oznacza, że jest to rozwiazanie
˛
niezależne od typu wykorzystywanej bazy
danych. Przepi˛ecie na inna˛ baz˛e danych wymaga jedynie zmiany w pliku
konfiguracyjnym.
Przy tworzeniu rozbudowanego systemu w architekturze wielowarstwowej, warto zastanowić si˛e nad oparciem go o szkielet aplikacyjny.
Szkielety dostarczaja˛ zestaw bibliotek oraz trzon aplikacji zgodnej z przyj˛etym wzorcem projektowym, pozostawiajac
˛ programiście wypełnienie go kodem realizujacym
˛
pożadane
˛
funkcjonalności.
Pozwala to na oszcz˛edze-
nie pracy dzi˛eki wykorzystaniu gotowych rozwiaza
˛ ń oraz utrzymanie przemyślanej i czytelnej struktury kodu.
Szkielet powinien wspierać technologie odpowiadajace
˛
za dost˛ep do
danych np. Hibernate, jak również technologie warstwy prezentacji - np.
serwlety. Sa˛ to klasy, majace
˛ za zadanie dostarczanie treści w odpowiedzi
na żadania
˛
wysyłane przez przegladark˛
˛
e internetowa˛ użytkownika. Gotowa
aplikacja webowa umieszczana jest na serwerze aplikacyjnym wspierajacym
˛
serwlety np. Apache Tomcat.
3.5.1. Spring
Jednym z najbardziej popularnych szkieletów jest Spring Framework.
Oferuje wsparcie dla architektury MVC, dost˛ep do danych przy użyciu
JDBC lub mapowania obiektowo-relacyjnego, zdalne wywoływanie procedur, wstrzykiwanie zależności, wsparcie dla testowania i wiele innych udogodnień. Spring posiada modułowa˛ budow˛e pozwalajac
˛ a˛ na rozszerzanie
15
dostepnych
˛
funkcjonalności. Rozwiazanie
˛
jest proste w konfiguracji i bardzo
rozpowszechnione, choć można spotkać pod jego adresem również głosy krytyki zarzucajace
˛ mu brak całościowej koncepcji zapewniajacej
˛
spójność.
3.5.2. EJB
Do technologii o dużych możliwościach należy również Enterprise Java
Beans. Oferuje mi˛edzy innymi dost˛ep do danych poprzez JPA, wiele mechanizmów wspierajacych
˛
wielowatkowość,
˛
np.
asynchroniczne wywołania
metod, czy harmonogramowanie zadań, wstrzykiwanie zależności oraz wsparcie dla technologii WebServices. EJB jest głównie technologia˛ warstwy
logiki aplikacji, do tworzenia aplikacji webowych zwykle jest łaczona
˛
z innym
szkieletem np. JavaServer Faces lub wspomnianym wcześniej Springiem.
3.5.3. ObjectLedge
Mało znanym, aczkolwiek interesujacym
˛
szkieletem jest szkielet ObjectLedge.
Oparty jest na architekturze MVC, czyli model-widok-kontroler.
Posiada wsparcie dla technologii Apache Velocity w warstwie prezentacji
oraz Hibernate w warstwie danych, jak również mechanizmy takie, jak
wstrzykiwanie zależności, Intake’i (pozwalajace
˛ na walidacj˛e danych), wsparcie dla technologii Ajax oraz wbudowany system bezpieczeństwa.
ObjectLedge wykorzystuje koncepcj˛e serwletów, implementujac
˛ własny
serwlet o nazwie LedgeServlet. Skierowanie żadania
˛
do serwletu powoduje
przekazanie kontroli do klasy HttpDispatcher, która decyduje, w jaki
sposób zostanie przetworzone żadanie.
˛
Za interakcje z użytkownikiem
odpowiedzialne sa˛ akcje, widoki i komponenty. Zadaniem akcji jest wykonanie operacji zleconej przez użytkownika, zadaniem widoku jest pobranie
danych i dostarczenie ich użytkownikowi. Komponent pełni rol˛e taka,
˛ jak
widok, lecz nie stanowi samodzielnej strony, tylko może być wstawiony, jako
element widoku.
ObjectLedge zapewnia komunikacj˛e pomi˛edzy warstwa˛
logiki aplikacji a warstwa˛ prezentacji przy użyciu technologii Apache Velocity, szerzej opisanej w rozdziale 3.6.
Implementacja widoku wymaga
16
implementacji szablonu Velocity oraz odpowiadajacej
˛
jej klasy javowej implementujacej
˛
interfejs Builder. Wysłanie żadania
˛
z adresem URL widoku
powoduje najpierw wykonanie metody build z klasy widoku, która wstawia
dane do kontekstu. Nast˛epnie przetwarzany jest szablon Velocity, w którym
dostepne
˛
sa˛ wcześniej wstawione dane. Analogiczne operacje wykonywane
sa˛ dla komponentów widoku. Akcje moga˛ być wywołane poprzez dodanie
do adresu URL parametru action z nazwa˛ akcji. Spowoduje to wywołanie
metody process w klasie akcji implementujacej
˛
interfejs Valve.
ObjectLedge posiada mechanizm nazywany wstrzykiwaniem zależności.
Pozwala on na zdefiniowanie w pliku konfiguracyjnym klas lub cz˛eściej
interfejsów, dla których implementujace
˛
je obiekty b˛eda˛ automatycznie
dostarczane przez szkielet. Oszcz˛edza to prac˛e zwiazan
˛
a˛ z wywoływaniem
konstruktorów, a ponadto w razie konieczności zmiany implementacji,
wystarczy podmienić nazw˛e klasy implementujacej
˛
interfejs w konfiguracji
nie modyfikujac
˛ kodu wykorzystujacego
˛
ten interfejs.
Mocna˛ strona˛ szkieletu ObjectLedge jest wbudowany system bezpieczeństwa. Zawiera on mechanizm autoryzacji użytkowników, jak również
rozbudowany system kontroli uprawnień. Uprawnienia sa˛ weryfikowane
zarówno przy próbie uruchomienia widoku lub akcji przez aplikacj˛e webowa,
˛ jak i bezpośrednio przez użytkownika poprzez wpisanie adresu URL.
Programista z poziomu kodu Javy ma także dost˛ep do API umożliwiajacego
˛
operacje na systemie bezpieczeństwa. Sposób wykorzystania mechanizmów
bezpieczeństwa ObjectLedge’a w implementacji niniejszego systemu został
szerzej opisany w rozdziale 6.3.
3.5.4. Podsumowanie
Zdecydowano si˛e na oparcie aplikacji o szkielet ObjectLedge. Jego zaletami sa˛ wsparcie dla technologii Ajax, Hibernate i Velocity oraz wbudowany
system bezpieczeństwa o dużych możliwościach.
17
3.6. Technologie warstwy prezentacji
Kolejna˛ decyzja˛ jest wybór technologii do implementacji warstwy prezentacji. Można tu wyróżnić technologie działajace
˛ po stronie serwera, komunikujace
˛ si˛e z warstwa˛ logiki aplikacji i przygotowujace
˛ wyświetlane treści
oraz technologie po stronie klienta osadzone w przegladarce
˛
internetowej
użytkownika.
3.6.1. Szablony Velocity
Technologia Apache Velocity jest silnikiem szablonów. Dzi˛eki niej treści
stron moga˛ być generowane z szablonów po stronie serwera.
Szablony
moga˛ zawierać m.in. operacje na zmiennych, instrukcje warunkowe, czy
petle.
˛
Programista może także zdefiniować własne makra implementujace
˛
żadane
˛
przez niego operacje. Sa˛ one przetwarzane przez silnik Velocity, a do
przegladarki
˛
klienta wysyłany jest wynik.
Apache Velocity dobrze integruje si˛e ze szkieletem ObjectLedge,
który posiada wbudowane mechanizmy przekazywania obiektów z kodu
napisanego w j˛ezyku Java do szablonów Velocity.
Ponadto, pakiet
ledge-web dostarcza szereg narz˛edzi usprawniajacych
˛
proces tworzenia
stron przy użyciu Velocity.
3.6.2. JQuery
W aplikacji tworzonej w koncepcji grubego klienta, cz˛eść kodu wykonywana jest przez przegladark˛
˛
e po stronie klienta. Powszechnym standardem jest implementacja tego kodu w j˛ezyku JavaScript. Programowanie
w czystym JavaScripcie nie należy jednak do najefektywniejszych, dlatego
powstało wiele bibliotek zwi˛ekszajacych
˛
możliwości tego j˛ezyka. Jedna˛ z
najpopularniejszych jest jQuery.
JQuery oferuje m.in. uproszczenie tworzenia żada
˛ ń HTTP potrzebnych
do realizacji technologii Ajax, dodanie przydatnych instrukcji nieobecnych
w JavaScripcie (np. p˛etli foreach), czy lepszy dost˛ep do DOM (ang. Document
Object Model), czyli obiektowego modelu dokumentu HTML.
18
Do jQuery można dołaczyć
˛
bibliotek˛e o nazwie jQueryUI, która zawiera
zestaw gotowych elementów interfejsu użytkownika, efektów i motywów
stron, co pozwala na proste i szybkie utworzenie strony o przyjaznym dla
użytkownika wygladzie.
˛
3.6.3. Ajax
Technologia Ajax (ang. Asynchronous JavaScript and XML) pozwala na
budowanie dynamicznych aplikacji webowych. W aplikacjach zbudowanych
bez wykorzystania tej technologii, wymiana danych pomi˛edzy serwerem i
klientem opiera si˛e na wysyłaniu przez klienta żada
˛ ń HTTP i synchronicznym przesyłaniu przez serwer odpowiedzi, zawierajacych
˛
treść prezentowanej strony.
Co za tym idzie, każda próba interakcji użytkownika z
aplikacja˛ wymagajaca
˛
wymiany danych z serwerem skutkuje ponownym
przesłaniem i renderowaniem strony.
Technologia Ajax pozwala na asynchroniczna˛ komunikacj˛e klienta z serwerem. Po wykonaniu akcji do serwera wysyłane jest żadanie,
˛
natomiast po
otrzymaniu odpowiedzi wywoływana jest asynchronicznie wskazana funkcja
jezyka
˛
JavaScript. Odpowiedź nie zawiera treści strony, lecz jedynie dane,
które zostaja˛ przetworzone przez kod po stronie klienta, który aktualizuje
wyświetlana˛ stron˛e. Dzi˛eki temu interakcja użytkownika z aplikacja˛ webowa˛ i pobranie danych z serwera nie wymaga przesyłania i renderowania
całej strony.
Wbrew nazwie, dane przekazywane pomi˛edzy serwerem i klientem w
technologii Ajax nie musza˛ być w formacie XML. Obecnie coraz cz˛eściej
wykorzystywany jest format JSON (ang.
JavaScript Object Notation), w
którym sposób reprezentacji danych jest taki sam, jak w wykorzystywanym
po stronie klienta j˛ezyku JavaScript. Duża˛ zaleta˛ formatu JSON stanowi
fakt, iż jest on znacznie lżejszy i łatwiejszy do przetwarzania, niż XML.
19
˛ testowanie
˛ testowanie
Ostatnim istotnym elementem systemu informatycznego sa˛ testy jednostkowe pozwalajace
˛ na weryfikacj˛e poprawności wytworzonego kodu. W celu
efektywnej implementacji testów, warto rozważyć wykorzystanie istnieja˛
cych na rynku szkieletów przeznaczonych do tego celu.
3.7.1. JUnit
Podstawowym
narz˛edziem
wspomagajacym
˛
testowanie
aplikacji
napisanej w j˛ezyku Java jest szkielet JUnit. Pozwala on na implementacj˛e
testów w j˛ezyku Java, przy jednoczesnym zachowaniu separacji testów od
kodu.
Utworzenie testu jednostkowego przy użyciu JUnit może zostać zrealizowane poprzez napisanie klasy dziedziczacej
˛
po klasie TestCase. Klasa
może zawierać metody testujace
˛ oraz metody wykonujace
˛ si˛e przed i po
wykonaniu testu. Wewnatrz
˛
metod testujacych
˛
wykonywane sa˛ operacje do
weryfikacji, a nast˛epnie za pomoca˛ asercji sprawdzana jest zgodność zwróconego wyniku z oczekiwanym. W przypadku różnicy rzucany jest wyjatek
˛
i
test kończy si˛e niepowodzeniem.
3.7.2. DBUnit
Wartym uwagi rozszerzeniem szkieletu JUnit jest DBUnit. Oprócz mechanizmów zawartych w JUnit, dostarcza on dodatkowo narz˛edzia ułatwiajace
˛
testowanie metod wykorzystujacych
˛
baz˛e danych.
Test jednostkowy oparty na DBUnit tworzony jest analogicznie, jak
w przypadku JUnit.
Przed wykonaniem testu nast˛epuje inicjalizacja
połaczenia
˛
z baza˛ danych. W metodach testowych wykonywane sa˛ operacje,
których poprawność weryfikowana jest za pomoca˛ asercji.
Ciekawa˛ funkcjonalnościa,
˛ jaka˛ posiada DBUnit jest możliwość załadowania danych z pliku XML przed każdym testem. Dzi˛eki temu programista
może być pewien, jakie dane znajduja˛ si˛e w bazie bez konieczności re˛ cznego
ich wstawiania.
20
3.8. Dodatkowe narzedzia
˛
3.8. Dodatkowe narzedzia
˛
Budujac
˛ system informatyczny,
poza technologiami bezpośrednio
tworzacymi
˛
wyjściowy produkt, warto również wziać
˛ pod uwag˛e wykorzystanie dodatkowych narz˛edzi przydatnych w trakcie prac nad implementacja.
˛
Na uwag˛e zasługuja˛ mi˛edzy innymi narz˛edzia do budowania aplikacji oraz
systemy kontroli wersji
3.8.1. Budowanie aplikacji - Apache Maven
Narz˛edzie Apache Maven przeznaczone jest do budowania aplikacji utworzonych w technologii Java. Opiera si˛e plikach POM (ang. Project Object Model), zawierajacych
˛
konfiguracj˛e budowania modułu. Dzi˛eki wykorzystaniu Mavena, kompilacja nawet rozbudowanych i wielomodułowych
systemów sprowadza si˛e do wywołania prostego polecenia mvn clean
install.
Maven posiada system wtyczek pozwalajacych
˛
rozszerzyć jego funkcjonalności, dzi˛eki czemu może być użyty nie tylko do kompilacji kodu Javy, ale
również wykonywania testów jednostkowych, operacji na systemie plików,
czy wykonywania skryptów SQL. Wspierane jest również budowanie archiwów aplikacji webowych, czyli plików .war.
Silna˛ strona˛ Mavena jest również zarzadzanie
˛
modułami. Po kompilacji
modułu, jest on umieszczany w lokalnym repozytorium. Podłaczenie
˛
do
projektu zewn˛etrznych bibliotek sprowadza si˛e do dodania w pliku POM
danego modułu znacznika <dependency>.
Kompilujac,
˛ Maven odszuka
pakiety w lokalnym repozytorium i rozwia˛że zależności. W przypadku nieznalezienia modułu istnieje również możliwość przeszukania repozytoriów
sieciowych. Oczywiście, aby dołaczenie
˛
modułu w ten sposób było możliwe,
musi być on również zbudowany przy użyciu narz˛edzia Maven, jednak jest
ono rozpowszechnione stopniu, pozwalajacym
˛
na spełnienie tego warunku
w wiekszości
˛
przypadków. Jako moduły Mavena moga˛ być podłaczone
˛
m.in.
sterownik PostgreSQL, biblioteki Hibernate’a, czy komponenty szkieletu ObjectLedge.
21
3.9. Podsumowanie
3.8.2. Kontrola wersji - Git
Podczas implementacji wskazane jest przechowywanie kopii zapasowej
kodu, jak również jego archiwalnych wersji. Moga˛ one uratować projekt
w przypadku utraty danych lub nieumyślnego wprowadzenia zmian psujacych
˛
istniejace
˛ już funkcjonalności. Do tego celu można użyć systemu
kontroli wersji, którego przykładem jest Git. Bazuje on na przechowywaniu
kopii kodu w repozytorium lokalnym oraz sieciowym. Podstawowe operacje
udost˛epniane przez Git to commit - zapisanie zmian do lokalnego repozytorium, push - wysłanie zmian z repozytorium lokalnego do repozytorium
sieciowego, pull - pobranie zmian z repozytorium sieciowego do repozytorium lokalnego oraz merge - połaczenie
˛
dwóch gał˛ezi projektu (powstałych
na skutek celowego rozdzielenia kodu lub dokonania zmian przez kilku programistów). Git może być obsługiwany z poziomu linii komend, jak również
przy pomocy wtyczek do popularnych środowisk programistycznych takich
jak Eclipse, czy IntelliJ Idea.
3.9. Podsumowanie
Podsumowujac
˛ decyzje podj˛ete w niniejszym rozdziale, aplikacja zostanie
zbudowana w architekturze trójwarstwowej, przy użyciu j˛ezyka programowania Java, szkieletu ObjectLedge, bazy danych PostgreSQL, technologii Hibernate do mapowania relacyjno-obiektowego, technologii Apache
Velocity, JavaScript, Ajax i jQuery w warstwie prezentacji oraz DBUnit
do testów jednostkowych.
Kod b˛edzie budowany przy użyciu narz˛edzia
Maven, zaś aplikacja webowa zostanie uruchomiona na serwerze aplikacyjnym Tomcat.
4. Model funkcjonalny
Po rozpoznaniu dziedziny i wybraniu technologii, kolejnym krokiem
procesu projektowania systemu informatycznego jest utworzenie modelu
funkcjonalnego. Pozwoli on na określenie, jakie wymagania powinien spełniać system do zarzadzania
˛
archiwami ISO. Sa˛ to wymagania biznesowe specyfikuja,
˛ jakie funkcjonalności b˛edzie udost˛epniał system, nie wchodzac
˛
w szczegóły implementacyjne.
4.1. Aktorzy systemu
Podstawowym zagadnieniem projektowania systemu jest określenie aktorów. Mianem aktora w inżynierii oprogramowania nazywa si˛e zewn˛etrzny
obiekt, który zachodzi w interakcj˛e z projektowanym systemem. W ogólnym
przypadku może być to osoba fizyczna, badź
˛ inny system. W niniejszym systemie nieprzewidziana jest integracja z innymi systemami, dlatego jedynymi
aktorami b˛eda˛ użytkownicy.
Przy założeniu, że odbiorca˛ systemu jest uczelnia wyższa, użytkownicy
moga˛ zostać podzieleni cztery kategorie - studentów, którzy ucz˛eszczaja˛ na
przedmioty i powinni mieć dost˛ep do podre˛ czników dla tych przedmiotów,
wykładowców, którzy prowadza˛ przedmioty i powinni móc zarzadzać
˛
przedmiotami oraz należacymi
˛
do nich podre˛ cznikami i doktorantów, którzy
moga˛ jednocześnie ucz˛eszczać na przedmioty i je prowadzić.
Niezb˛edny
jest również administrator, którego odpowiedzialnościa˛ b˛edzie zarzadzanie
˛
całym systemem. Zależności pomi˛edzy aktorami zostały przedstawione na
rysunku 4.1.
4.2. Wymagania funkcjonalne
23
Rysunek 4.1. Aktorzy systemu
Niniejszy rozdział zawiera spis wymagań, jakie powinien spełniać system do zarzadzania
˛
archiwami ISO. Wymagania funkcjonalne stanowia˛ podstaw˛e dla dalszych etapów procesu tworzenia systemu informatycznego oraz
pozwalaja˛ na upewnienie si˛e, że wykonawca i klient jednakowo rozumieja˛
treść zagadnienia.
Uwaga W dalszej cz˛eści opisu b˛edzie używane sformułowanie przedmiot
dotyczacy
˛
danej osoby, oznaczajace
˛
w przypadku studenta - przedmiot,
na który ucz˛eszcza oraz w przypadku wykładowcy - przedmiot przez niego
prowadzony.
Jako, że doktoranci łacz
˛ a˛ w sobie cechy studentów i wykładowców, nie
bed
˛ a˛ explicite wymienieni w treści wymagań funkcjonalnych.
Przyjmuje
sie˛ założenie, że doktorant wobec przedmiotów, na które ucz˛eszcza posiada
funkcj˛e studenta, a wobec przedmiotów, które prowadzi - funkcj˛e wykładowcy.
24
4.2.1. Wymagania bezpieczeństwa
Dost˛ep do systemu powinien wymagać zalogowania przy użyciu nazwy
użytkownika oraz hasła. System przed wykonaniem dowolnej operacji przez
użytkownika powinien sprawdzać jego uprawnienia. Każda próba nieautoryzowanego dost˛epu powinna kończyć si˛e niepowodzeniem. Z poziomu
graficznego interfejsu użytkownika funkcje niedost˛epne dla użytkowników
nie powinny być dla nich widoczne. W szczególności, studenci i wykładowcy
powinni mieć dost˛ep jedynie do przedmiotów ich dotyczacych.
˛
4.2.2. Podreczniki
˛
W ramach zarzadzania
˛
podre˛ cznikami, czyli materiałami dydaktycznymi w formie elektronicznej system powinien udost˛epniać nast˛epujace
˛
funkcjonalności:
Wyświetlenie listy podreczników
˛
Student i wykładowca powinni mieć możliwość wyświetlenia listy podreczników
˛
dla przedmiotów ich dotyczacych.
˛
Lista powinna zawierać
nazw˛e podrecznika,
˛
nazw˛e przedmiotu, oraz łacze
˛
do pobrania podre˛ cznika.
Pobranie podrecznika
˛
System powinien umożliwiać studentom i wykładowcom pobranie podreczników
˛
dla przedmiotów ich dotyczacych
˛
w postaci archiwum nośnika
optycznego w formacie ISO. Pobrana powinna zostać wersja podre˛ cznika
określona w systemie jako aktualna.
Kontrola wersji podreczników
˛
System powinien przechowywać archiwalne wersje podre˛ czników.
Wykładowca powinien mieć możliwość przełaczenia
˛
wersji danego podrecznika
˛
aktualnie dost˛epnej do pobrania.
Dodanie, edycja usuniecie
˛
podreczników
˛
Wykładowca powinien mieć możliwość dodania, edycji i usuni˛ecia podreczników
˛
dla przedmiotów przez niego prowadzonych. Funkcjonalność
25
powinna być również dost˛epna dla administratora w stosunku do wszystkich podreczników.
˛
4.2.3. Przedmioty
W ramach zarzadzania
˛
przedmiotami, system powinien udost˛epniać
użytkownikom nast˛epujace
˛ funkcjonalności:
Wyświetlenie listy przedmiotów
Student i wykładowca powinni mieć możliwość wyświetlenia listy podreczników
˛
dla przedmiotów ich dotyczacych.
˛
Lista powinna zawierać kod
przedmiotu, nazw˛e oraz opis.
Edycja opisu przedmiotu
Wykładowca powinien mieć możliwość edycji opisu przedmiotów przez
niego prowadzonych.
Dodanie przedmiotu
Administrator powinien mieć możliwość dodania przedmiotu.
4.2.4. Osoby
W
ramach
zarzadzania
˛
osobami,
system
powinien
udost˛epniać
użytkownikom nast˛epujace
˛ funkcjonalności:
Wyświetlenie listy osób
Administrator powinien mieć możliwość wyświetlenia wszystkich osób
zarejestrowanych w systemie. Lista powinna zawierać login osoby, imi˛e,
nazwisko, adres e-mail oraz PESEL oraz łacze
˛
do edycji i usuni˛ecia danej
osoby.
Dodanie, edycja i usuniecia
˛
osób
Administrator powinien mieć możliwość dodania, edycji i usuni˛ecia osoby. W trakcie dodania i edycji system powinien umożliwiać administratorowi wybranie rodzaju osoby (student, wykładowca, doktorant lub administrator)
26
4.3. Makiety
4.2.5. Zarzadzanie
˛
aktualizacja˛
System powinien udost˛epniać nast˛epujace
˛ funkcjonalności zwiazane
˛
z
aktualizacja˛ podreczników:
˛
Sporzadzenie
˛
raportów zmian w katalogach źródłowych
Administrator powinien mieć możliwość sporzadzenia
˛
raportu informujacego
˛
o zmianach w plikach źródłowych archiwów. Raport ogólny powinien
zawierać list˛e archiwów wraz z liczba˛ plików i katalogów do aktualizacji,
badź
˛ usuni˛ecia. Raport szczegółowy powinien być sporzadzany
˛
dla konkretnego archiwum i zawierać list˛e plików i katalogów do aktualizacji, badź
˛
usuni˛ecia.
Generacja nowej wersji archiwum
Administrator powinien mieć możliwość uruchomienia generacji nowej
wersji archiwum. Mechanizm powinien utworzyć nowa˛ wersj˛e i sprawić,
aby była wersja˛ aktualnie dost˛epna˛ dla użytkowników.
4.3. Makiety
Aby uzyskać pewność, że klient akceptuje koncepcj˛e realizacji aplikacji,
oprócz spisania wymagań funkcjonalnych warto również przygotować makiety, które pokazuja˛ wyglad
˛ projektowanej aplikacji.
Makiety nie maja˛
na celu jak najlepszego odwzorowania docelowej aplikacji, lecz jedynie
pokazanie ogólnej koncepcji i rozmieszczenia elementów w graficznym interfejsie użytkownika. W ramach projektowania zostały przygotowane makiety
listy podreczników
˛
(rysunek 4.2) widzianej przez studenta oraz listy archiwów do aktualizacji (rysunek 4.3) widzianej przez administratora.
4.4. Przypadki użycia
Kiedy ustalone sa˛ wymagania, jakie ma spełniać system, można przystapić
˛
do utworzenia przypadków użycia. Przypadek użycia opisuje interakcje aktorów z systemem. Przypadki użycia można opisać przy użyciu
27
Rysunek 4.2. Makieta listy podreczników
˛
Rysunek 4.3. Makieta listy archiwów do aktualizacji
zunifikowanego j˛ezyka modelowania (UML). Na rysynku 4.4 został przedstawiony diagram przypadków użycia dla funkcjonalności zwiazanych
˛
z podrecznikami
˛
(archiwami).
Na diagramie zawarta jest jedynie informacja, jakie przewiduje si˛e możliwości interakcji użytkownika z systemem. Doprecyzowanie przebiegu interakcji umożliwiaja˛ scenariusze przypadków użycia. Poniżej zawarte sa˛ scenariusze dla przypadku aktualizacji archiwów oraz pobrania podre˛ cznika.
PU: Aktualizacja archiwów
Aktorzy uczestniczacy:
˛
Administrator
28
Scenariusz główny:
1. Użytkownik uwierzytelnia si˛e w aplikacji.
2. Użytkownik wybiera z menu stron˛e służac
˛ a˛ do aktualizacji archiwów.
3. System
wyświetla
użytkownikowi
list˛e
archiwów
wraz
z
liczba˛
zmienionych i usuni˛etych plików i katalogów.
4. Użytkownik wybiera opcj˛e Aktualizuj
5. System dokonuje aktualizacji archiwum i wyświetla użytkownikowi informacj˛e o poprawnym przebiegu operacji.
PU: Pobranie podrecznika
˛
Aktorzy uczestniczacy:
˛
Student
Scenariusz główny:
1. Użytkownik uwierzytelnia si˛e w aplikacji.
2. Użytkownik wybiera z menu stron˛e zawierajac
˛ a˛ list˛e podre˛ czników.
3. System wyświetla użytkownikowi list˛e podre˛ czników dost˛epnych dla
niego.
4. Użytkownik wybiera opcj˛e Pobierz
5. System przesyła podrecznik
˛
w formacie ISO do przegladarki
˛
internetowej
użytkownika
6. Użytkownik zapisuje otrzymany plik w swoich zasobach.
29
Rysunek 4.4. Diagram przypadków użycia dla funkcjonalności zwiazanych
˛
z podrecznikami
˛
5. Model danych
Jednym z kluczowych etapów projektowania systemu opartego na relacyjnej bazie danych jest projekt modelu danych.
Proces projektowania
został podzielony na dwa etapy. Najpierw, na podstawie analizy dziedziny
opisanej w rozdziale 2 został utworzony model logiczny opisujacy
˛ ogólna˛
koncepcj˛e realizacji modelu danych niewchodzac
˛ a˛ w szczegóły implementacyjne.
Nast˛epnie, na podstawie modelu logicznego został utworzony
model fizyczny, który stanowi jego implementacj˛e dla konkretnego systemu
zarzadzania
˛
baza˛ danych.
5.1. Model logiczny
Model logiczny został zrealizowany w postaci modelu zwiazków-encji,
˛
który reprezentuje obiekty świata i ich cechy jako encje i atrybuty. Zależnosci pomi˛edzy encjami opisuja˛ zwiazki
˛
jeden do jednego, jeden to wielu
lub wiele do wielu. Model został przedstawiony w postaci opisowej oraz
diagramu znajdujacego
˛
si˛e na rysunku 5.1.
5.1.1. Osoba
Encja Osoba określa użytkownika korzystajacego
˛
z systemu. Osoba jest
opisana za pomoca˛ atrybutów takich, jak login, hasło, imi˛e, nazwisko, adres
e-mail oraz numer PESEL.
Ze wzgl˛edu na brak dobrego naturalnego identyfikatora (imiona i
nazwiska moga˛ si˛e powtarzać, login oraz e-mail moga˛ ulec zmianie, natomiast PESEL nie jest posiadany przez wszystkie osoby) wykorzystany został
sztuczny identyfikator.
31
5.1. Model logiczny
Dodatkowo, na login, e-mail oraz PESEL zostały nałożone ograniczenia
unikalności, aby zapobiec dublowaniu kont użytkowników.
5.1.2. Rola
Zgodnie z analiza,
˛ osoby można podzielić na kilka kategorii różniacych
˛
sie˛ funkcja˛ i zestawem uprawnień. Takie kategorie reprezentowane sa˛ przez
encje˛ Rola.
Ponieważ liczba kategorii jest skończona, rozwiazaniem
˛
alternatywnym
do tworzenia encji mogłoby być umieszczenie ich jako atrybutu encji Osoba.
Zauważmy jednak, że stworzenie dodatkowej encji nie wia˛że si˛e z duża˛
pracochłonnościa,
˛ natomiast znacznie upraszcza wprowadzanie zmian w
przypadku, gdyby pojawiła si˛e konieczność dodania nowych ról.
Kluczowymi atrybutami encji Rola sa˛ identyfikator oraz kod. Dla zwi˛ekszenia informacji wprowadzono również nazw˛e oraz opcjonalny opis.
Rola znajduje si˛e w relacji jeden do wielu z Osoba.
˛
5.1.3. Jednostka organizacyjna
Organizacje takie, jak uczelnie wyższe posiadaja˛ strukture˛ hierarchiczna.
˛
Uczelnia może być podzielona na wydziały, te na instytuty i zakłady. Jednostk˛e w hierarchii uczelni reprezentuje encja Jednostka organizacyjna.
Jednostka organizacyjna posiada nazw˛e oraz opis.
Podobnie, jak w
poprzednich przypadkach, został wprowadzony sztuczny identyfikator.
W celu reprezentacji hierarchii, encja znajduje si˛e w rekursywnym
zwiazku
˛
jeden do wielu. Jednostka organizacyjna znajduje si˛e również
w zwiazku
˛
jeden do wielu z encja˛ Osoba.
5.1.4. Typ jednostki
Encja reprezentuje typ jednostki organizacyjnej. Zawiera sztuczny identyfikator oraz nazw˛e.
Ponieważ typy również moga˛ posiadać hierarchi˛e, encja znajduje si˛e w
rekursywnym zwiazku
˛
jeden do wielu. Ponadto znajduje si˛e w zwiazku
˛
jeden
do wielu z Jednostka˛ organizacyjna˛
5.1. Model logiczny
32
5.1.5. Przedmiot
Encja Przedmiot reprezentuje przedmiot prowadzony na uczelni. Przedmiot jest opisany przez kod, nazw˛e oraz opis. Kod przedmiotu powinien być
unikalny w ramach jednostki organizacyjnej, dlatego można by zastosować
identyfikator złożony ze zwiazku
˛
z jednostka˛ organizacyjna˛ oraz kodu przedmiotu. Z uwagi na to, że przedmiot wchodzi w relacje z kilkoma innymi
encjami używanie długiego złożonego identyfikatora byłoby niewygodne i
kosztowne, dlatego zastosowano identyfikator sztuczny.
Pomi˛edzy Przedmiotem, a Osoba˛ znajduja˛ si˛e dwa zwiazki
˛
- pierwszy
określa uczestnictwo danej osoby w przedmiocie, zaś drugi prowadzenie
przedmiotu przez dana˛ osob˛e. Przedmiot wchodzi również w zwiazek
˛
z
Archiwum.
5.1.6. Archiwum
Encja Archiwum reprezentuje podre˛ cznik w formacie archiwum ISO. Jej
atrybuty to sztuczny identyfikator, nazwa oraz opcjonalny opis.
Archiwum może posiadać wersje, stad
˛ zwiazek
˛
jeden do wielu z
encja˛ Wersja archiwum. Dla każdego archiwum zdefiniowany jest jeden
nadrz˛edny katalog źródłowy zawierajacy
˛
treści wchodzace
˛
w skład tego
archiwum, co reprezentuje zwiazek
˛
jeden do jednego z encja˛ Folder.
5.1.7. Wersja archiwum
Encja reprezentuje wersj˛e archiwum. Zawiera numer wersji, dat˛e utworzenia, ścieżk˛e do fizycznej lokalizacji pliku .iso, flag˛e określajac
˛ a,
˛ czy
dana wersja jest pokazywana oraz opcjonalny opis.
Numer wersji jednoznacznie identyfikuje ja˛ w ramach archiwum, dlatego
został utworzony identyfikator złożony, w skład którego wchodzi zwiazek
˛
z
encja˛ Archiwum oraz atrybut numer wersji.
5.2. Model fizyczny
33
5.1.8. Folder
Encja Folder oraz encja Plik zostały stworzone w celu odwzorowania struktury katalogów źródłowych, z których budowane sa˛ archiwa na
potrzeby mechanizmu automatycznej aktualizacji archiwów.
Encja Folder reprezentuje znajdujacy
˛ si˛e na serwerze katalog źródłowy.
Encja jest opisana przez identyfikator, nazw˛e, oraz dwie flagi. Flaga czy
aktualny jest prawdziwa, jeśli w najnowszej wersji archiwum znajduje si˛e
aktualna wersja katalogu. Flaga do usuniecia
˛
jest prawdziwa, jeśli dany
katalog znajduje si˛e w najnowszej wersji archiwum, ale został już usuni˛ety
z systemu pliku.
Podobnie, jak w wypadku jednostek organizacyjnych, struktura katalogów jest drzewiasta, co odwzorowuje rekursywny zwiazek
˛
jeden do wielu.
Ponadto katalog może zawierać pliki, co reprezentuje zwiazek
˛
z encja˛ Plik
5.1.9. Plik
Encja Plik reprezentuje znajdujacy
˛ si˛e na serwerze plik wchodzacy
˛ w
skład danych źródłowych, z których generowane sa˛ archiwa. Encja jest
opisana przez sztuczny identyfikator, nazw˛e, oraz dwie flagi o takim samym
znaczeniu, jak w przypadku encji Folder.
5.2. Model fizyczny
Model fizyczny został utworzony w oparciu o model logiczny i stanowi
jego implementacj˛e dla systemu zarzadzania
˛
baza˛ danych PostgreSQL. Na
podstawie encji i atrybutów zostały stworzone tabele i kolumny, wskazano
również jawnie typy danych oraz klucze obce realizujace
˛ zwiazki.
˛
Zwiazki
˛
wiele do wielu, które nie moga˛ być zaimplementowane bezpośrednio w technologii relacyjnej, zostały wyeliminowane przy użyciu zwiazków
˛
jeden do
wielu oraz tabel intersekcji. Model fizyczny został przedstawiony w formie
schematu tabel znajdujacego
˛
si˛e na rysunku 5.2.
5.2. Model fizyczny
Rysunek 5.1. Diagram zwiazków
˛
encji
34
5.2. Model fizyczny
Rysunek 5.2. Schemat tabel systemu
35
6. Implementacja
Po wykonaniu prac analitycznych, można przystapić
˛
do implementacji systemu informatycznego zgodnie z przyj˛etymi założeniami. Niniejszy
rozdział przedstawia sposoby implementacji elementów systemu do
zarzadzania
˛
archiwami ISO, które zostały uznane przez autora za istotne
dla działania systemu lub interesujace
˛ i warte omówienia.
6.1. Automatyczna aktualizacja archiwów
Kluczowym elementem systemu do zarzadzania
˛
archiwami ISO jest
moduł automatycznej aktualizacji archiwów.
W omawianym systemie
składa si˛e on z dwóch mechanizmów - wykrywania i raportowania zmian
w katalogach oraz aktualizacji i generowania archiwów. Współpraca tych
mechanizmów odbywa si˛e poprzez baz˛e danych przy użyciu encji Folder i
Plik opisanych w rozdziale 5.
6.1.1. Wykrywanie zmian w katalogach
Pierwszym krokiem jest wykrywanie zmian w katalogach. Do tego celu
wykorzystano interfejs WatchService dost˛epny w pakiecie java.nio, który
został zawarty w wersji 1.7 Javy.
Wykrywanie zmian zrealizowane jest w oddzielnym watku,
˛
który powoływany jest wraz z uruchomieniem aplikacji webowej. Główna metoda watku
˛
zawiera po pierwsze inicjalizacj˛e mechanizmu, czyli pobranie serwisu oraz
zarejestrowanie katalogów, które b˛eda˛ obserwowane pod katem
˛
zmian.
Nastepnie,
˛
watek
˛
wchodzi w p˛etl˛e, w której znajduje si˛e instrukcja:
1
WatchKey key = watchService . take ( ) ;
37
Metoda take jest blokujaca
˛ - gdy w systemie plików nie zachodza˛ zmiany
- czeka. W przeciwnym razie zwraca obiekt typu WatchKey, z którego za
pomoca˛ p˛etli:
1
for ( WatchEvent<?> watchEvent : key . pollEvents ( ) ) {
/∗ przetwarzanie zdarzenia ∗/
}
możliwe jest pobranie obiektu typu WatchEvent reprezentujacego
˛
zdarzenie, które zaszło w systemie plików.
W ciele p˛etli odczytywane sa˛ is-
totne dane zdarzenia, czyli rodzaj (dodanie, modyfikacja lub usuni˛ecie) oraz
nazwa pliku, którego dotyczy. Nast˛epnie wywoływana jest metoda interfejsu
słuchacza.
Powiadomiony o zmianie w systemie plików obiekt implementujacy
˛
słuchacz wywołuje metody serwisowe, które powoduja˛ aktualizacj˛e struktury bazodanowej reprezentujacej
˛
strukture˛ katalogów. W przypadku dodania pliku lub folderu do odpowiedniej tabeli wstawiany jest wiersz, zaś
w przypadku modyfikacji lub usuni˛ecia dany wiersz jest oznaczany jako
odpowiednio nieaktualny lub usuni˛ety.
6.1.2. Raportowanie zmian w katalogach
Dzi˛eki działajacemu
˛
w tle watkowi,
˛
w bazie danych zawarte sa˛ aktualne
dane na temat obserwowanych katalogów. Administrator systemu poprzez
aplikacj˛e webowa˛ może sprawdzić stan archiwów. Zostały stworzone dwa
raporty - ogólny, pokazujacy
˛ liczb˛e nieaktualnych lub usuni˛etych plików
i katalogów dla każdego archiwum (rys. 6.1), oraz szczegółowy - pokazujacy
˛ list˛e nieaktualnych lub usuni˛etych plików i katalogów dla konkretnego
archiwum (rys. 6.2).
Sprawdziwszy, że w katalogu źródłowym archiwum zaszły zmiany, administrator może wybrać opcj˛e Aktualizuj, która spowoduje wywołanie
mechanizmu generowania i aktualizacji archiwów.
38
Rysunek 6.1. Ogólny raport zmian w katalogach
Rysunek 6.2. Szczegółowy raport zmian w katalogach
6.1.3. Generowanie i udostepnienie
˛
nowej wersji
Etap ten rozpoczyna si˛e w momencie uruchomienia aktualizacji przez
administratora z poziomu aplikacji webowej. Proces ten składa si˛e z trzech
operacji - wygenerowania nowego pliku archiwum, aktualizacji struktury
katalogów w bazie danych oraz aktualizacji aktualnej wersji archiwum w
bazie danych.
Generowanie archiwum Z plików źródłowych zawartych w katalogu
głównym danego archiwum generowany jest nowy plik archiwum w formacie ISO. Do tworzenia archiwów wykorzystano narz˛edzie mkisofs. Jest to
program działajacy
˛ z poziomu linii komend, który wchodził w skład wi˛ekszości dystrybucji systemu Linux dost˛epnych na rynku w momencie pisania
tej pracy. Do wywoływania zewn˛etrznego programu użyto obiektu Runtime
zawartego w standardowej bibliotece j˛ezyka Java.
6.2. Dostep
˛ do danych
39
Aktualizacja struktury Nast˛epnie, aktualizowana jest struktura bazodanowa reprezentujaca
˛ strukture˛ katalogów. Pliki i foldery, które były oznaczone jako nieaktualne zostaja˛ oznaczone jako aktualne, zaś oznaczone
jako usuni˛ete zostaja˛ usuni˛ete z bazy danych.
Aktualizacja wersji archiwum Po poprawnym wykonaniu powyższych
kroków tworzona jest nowa encja typu WersjaArchiwum i zapisywana do
bazy danych. Ponadto, jest ona oznaczana jako wersja aktualnie opublikowana.
6.1.4. Pobieranie archiwów
Z punktu widzenia użytkownika końcowego mechanizm automatycznej
aktualizacji jest niewidoczny bezpośrednio. Użytkownik poprzez aplikacj˛e
webowa˛ ma dost˛ep do listy podre˛ czników, na której może wybrać odnośnik
Pobierz. Wówczas aplikacja znajduje w tabeli wersji archiwów wersj˛e oznaczona˛ jako aktualnie opublikowana,
˛ odnajduje odpowiadajacy
˛ jej plik .iso i
kieruje go do przegladarki
˛
internetowej użytkownika.
6.2. Dostep
˛ do danych
Ważnym elementem implementacji jest realizacja dost˛epu do danych
trwałych. W niniejszym systemie opiera si˛e ona na mechanizmach szkieletu
Hibernate oraz wykorzystaniu obiektów POJO i DAO.
6.2.1. Obiekty POJO oraz DAO
Obiekty POJO (ang. Plain Old Java Object) charakteryzuja˛ si˛e tym, że
zawieraja˛ jedynie pola oraz metody dost˛epu do nich. Te proste i lekkie
obiekty zostały wykorzystane do reprezentacji encji modelu danych, które,
po zdefiniowaniu mapowania Hibernate’a, staja˛ si˛e obiektami trwałymi.
Mianem DAO (ang. Data Access Object) określa si˛e obiekt zawierajacy
˛
metody dost˛epu do danych. Dzi˛eki zgromadzeniu wszystkich operacji na
40
6.2. Dostep
˛ do danych
danych w obiektach DAO zapewnione jest odizolowanie modelu od kontrolera w architekturze MVC, a kod jest stosunkowo czytelny i łatwy w utrzymaniu.
W celu usprawnienia tworzenia obiektów DAO wykorzystano mechanizm dziedziczenia.
Interfejs BaseDao specyfikuje podstawowe operacje,
jakie moga˛ być wykonane na wszystkich encjach takie, jak zapis, usuni˛ecie, pobranie po identyfikatorze, czy pobranie wszystkich encji danego
typu.
Klasa AbstractGenericDao dostarcza domyślnych implementacji
powyższych metod. Dzi˛eki temu, utworzenie DAO dla nowej encji wia˛że si˛e
jedynie z utworzeniem klasy dziedziczacej
˛
po abstrakcyjnej klasie bazowej.
Klasa taka posiada już zaimplementowane podstawowe operacje. Oczywiście moga˛ być zdefiniowane dodatkowe operacje specyficzne dla danej encji,
np. DAO dla archiwum posiada metod˛e pobrania archiwum po nazwie katalogu głównego. Każde DAO zostało utworzone w postaci interfejsu. Jego
implementacja jest dostarczana do klas je wykorzystujacych
˛
przy użyciu
mechanizmu wstrzykiwania zależności.
6.2.2. Filtrowanie danych
Złożone zapytania, wymagajace
˛ zaawansowanego filtrowania budowane
sa˛ w sposób obiektowy, przy użyciu zawartego w bibliotece Hibernate mechanizmu kryteriów (ang. Criteria Queries).
Wydruk 6.1 przedstawia wykorzystanie mechanizmu wyszukiwania
przykładem.
Metoda getByExample() zwraca list˛e encji pasujacych
˛
do
obiektu entity tzn.
posiadajacych
˛
identyczne wartości pól, jak encja
przykładowa. Dzi˛eki opcji .enableLike(MatchMode.START) w wynikach
dopuszczone sa˛ również encje, których pola znakowe rozpoczynaja˛ si˛e od
wartości podanych w przykładzie. Wartości null sa˛ ignorowane. Metoda
createCriteria() zwraca obiekt implementujacy
˛ interfejs Criteria dla
danej klasy.
1
public L i s t <T> getByExample ( f i n a l T e n t i t y ) {
f i n a l Example example = Example . create ( e n t i t y )
. ignoreCase ( )
. enableLike ( MatchMode .START ) ;
41
6.3. Mechanizmy bezpieczeństwa
return c r e a t e C r i t e r i a ( ) . add ( example ) . l i s t ( ) ;
5
}
Wydruk 6.1. Pobieranie encji na podstawie przykładu
Wydruk 6.2 przedstawia metod˛e pobierajac
˛ a˛ wszystkie archiwa dla
wybranej osoby tj.
dana osoba.
archiwa dotyczace
˛
przedmiotów, na które ucz˛eszcza
Zauważmy, że pomimo pobierania danych z wielu tabel,
sprowadza si˛e to jedynie do nałożenia ograniczenia na identyfikator Osoby,
bez konieczności używania słowa join. Zapytanie zawierajace
˛ złaczenia
˛
zostanie utworzone automatycznie przez Hibernate na podstawie zdefiniowanych aliasów i mapowań.
1
5
public L i s t <Archiwum> getUserArchives ( f i n a l Long personId ) {
return c r e a t e C r i t e r i a ( )
. c r e a t e A l i a s ( " przedmiot " , " p " )
. c r e a t e A l i a s ( " p . uczestnicy " , "u" )
. add ( R e s t r i c t i o n s . eq ( "u . id " , personId ) )
. list ();
}
Wydruk 6.2. Pobieranie archiwów dla użytkownika
Kolejna˛ niezwykle istotna˛ kwestia˛ przy implementacji systemu dla
wielu użytkowników jest zadbanie o bezpieczeństwo. Użytkownik systemu
powinien mieć dost˛ep jedynie do danych i operacji dla niego przeznaczonych. Implementacja opiera si˛e na użyciu dwóch mechanizmów - mechanizmu kont użytkowników opartego o encje Osoba i Rola oraz systemu
bezpieczeństwa wbudowanego w szkielet ObjectLedge.
6.3.1. Mechanizm kont użytkowników
Każda osoba korzystajaca
˛ z systemu jest identyfikowana przez encj˛e Osoba.
Każda osoba posiada rol˛e.
Zgodnie z wymaganiami, zostały pre-
definiowane cztery role - student, wykładowca, doktorant i administrator.
W przypadku wyświetlania studentom, doktorantom i wykładowcom list
przedmiotów i podreczników,
˛
pobierane sa˛ obiekty na podstawie zwiazków
˛
42
pomi˛edzy encja˛ Osoba i Przedmiot.
Dzi˛eki temu obiekty niedotyczace
˛
użytkownika nie sa˛ mu wyświetlane. Ponieważ wszystkie metody pobierajace
˛ podreczniki
˛
i archiwa odwołuja˛ si˛e do encji Osoba, nie ma również
możliwości, aby za pomoca˛ spreparowanych parametrów żadania
˛
uzyskać
nieuprawniony dost˛ep.
6.3.2. System bezpieczeństwa ObjectLedge’a
Budujac
˛ aplikacj˛e na szkielecie ObjectLedge, można wykorzystać wbudowany w niego rozbudowany system bezpieczeństwa. Operuje on na bytach takich, jak użytkownik, przywilej, rola i grupa zasobów. Użytkownik
jest bytem wykorzystujacym
˛
system, przywilej określa prawo do wykonania
danej operacji, a rola jest zestawem przywilejów. Użytkownikom moga˛ być
przypisane role w ramach danej grupy zasobów.
W aplikacji system bezpieczeństwa wykorzystany jest na dwa sposoby.
Po pierwsze do klas reprezentujacych
˛
widoki i akcje została dodane adnotacje. Pokazuje to poniższy przykład:
1
5
@AccessConditions (
@AccessCondition ( permissions = { " view_subjects " } )
)
public class UserSubjectIndex extends AbstractBuilder {
/∗ kod widoku ∗/
};
Dzieki
˛
dodaniu adnotacji dost˛ep do widoku UserSubjectIndex b˛edzie
możliwy jedynie, gdy użytkownik b˛edzie zalogowany w aplikacji oraz
bedzie
˛
posiadał przywilej view_subjects. Próba nieuprawnionego dost˛epu
spowoduje rzucenie wyjatku
˛
przez mechanizmy ObjectLedge’a, który po
przechwyceniu, spowoduje przekierowanie na stron˛e informujac
˛ a˛ o braku
uprawnień.
System bezpieczeństwa ObjectLedge’a może być również wykorzystany w
szablonach Velocity. Metoda
1
$policy . check ( $link )
zwraca wartość true, jeśli użytkownik posiada uprawnienie do wejścia na
URL znajdujacy
˛ si˛e w zmiennej $link. Przekazujac
˛ wynik do instrukcji
43
6.4. Technologia AJAX
warunkowej można w łatwy sposób wyświetlać w aplikacji webowej jedynie
te łacza,
˛
do których użytkownik posiada uprawnienia.
6.3.3. Integracja mechanizmów
Warto jeszcze wyjaśnić w jaki sposób powyższe dwa mechanizmy zostały
zintegrowane.
Najprostszym nasuwajacym
˛
si˛e sposobem byłoby odw-
zorowanie jeden do jednego - każdej osobie przyporzadkowany
˛
jest jeden użytkownik systemu bezpieczeństwa. Zauważmy jednak, że wszyscy
użytkownicy danej kategorii np. studenci posiadaja˛ te same uprawnienia
i z perspektywy mechanizmu bezpieczeństwa sa˛ równi. Dlatego tworzenie
dla każdej osoby użytkownika i przypisywanie mu ról i uprawnień byłoby
nadmiarowe. Zdecydowano si˛e wi˛ec na rozwiazanie,
˛
w którym każdej roli
przypisany jest jeden użytkownik systemu bezpieczeństwa.
Co za tym
idzie, w domyślnej konfiguracji system bezpieczeństwa operuje na czterech
użytkownikach.
W oparciu o powyższa˛ koncepcj˛e zaimplementowano mechanizm logowania do aplikacji. Po podaniu nazwy użytkownika i hasła, system najpierw
weryfikuje je w tabeli osób, a nast˛epnie próbuje zalogować użytkownika systemu bezpieczeństwa odpowiadajacego
˛
roli osoby logujacej
˛
si˛e.
Jak pokazano w rozdziale 3.6 dynamiczne i interaktywne strony internetowe moga˛ być utworzone przy wykorzystaniu technologii Ajax oraz jQuery.
Technologie te zostały użyte na ekranach listy osób i przedmiotów, na
których widnieje pole wyszukiwania. Po wpisaniu w to pole tekstu, aplikacja
asynchronicznie pobiera dane pasujace
˛ do podanego tekstu i aktualizuje
zawartość listy bez konieczności powtórnego renderowania strony.
W znaczniku HTML <input> wyświetlajacym
˛
pole tekstowe zostało
zdefiniowane zdarzenie onkeyup wywołujace
˛ po puszczeniu klawisza przez
użytkownika funkcj˛e JavaScript.
Funkcja przesyła żadanie
˛
HTTP POST
44
do serwera w celu otrzymania aktualnych danych. Zostały tu wykorzystane mechanizmy jQuery, dzi˛eki czemu zamiast re˛ cznego tworzenia żada˛
nia, możliwe jest użycie funkcji jQuery.post. Funkcja przyjmuje parametry takie, jak adres URL, dane żadania
˛
oraz funkcja callback. Jako adres
podany jest adres pseudowidoku AJAX, który zdefiniowany jest w konfiguracji ObjectLedge’a jako obsługujacy
˛ żadania
˛
ajaksowe. W danych żadania
˛
przekazywana jest nazwa serwisu i metody oraz jej parametry. Funkcja callback oznacza funkcj˛e JavaScript, która b˛edzie wykonana asynchronicznie
po otrzymaniu odpowiedzi od serwera.
Po otrzymaniu żadania
˛
POST, serwer za pomoca˛ mechanizmów ObjectLedge’a wywołuje odpowiednia˛ metod˛e, która pobieraja˛ dane (za pomoca˛ opisanej w rozdziale 6.2.2 metody wyszukujacej
˛
encje po przykładzie).
Nastepnie
˛
odpowiedź zawierajaca
˛
pobrane dane jest odsyłana do klienta
w formacie JSON. Przegladarka
˛
klienta wykonuje wówczas funkcj˛e zdefiniowana˛ wcześniej jako callback, która na podstawie otrzymanych danych
aktualizuje list˛e.
Wynik działania mechanizmu został przedstawiony na rysunku 6.3.
Ponieważ w pole imie˛ i nazwisko wpisano odpowiednio “j” i “k”, na liście widoczne sa˛ jedynie osoby o imionach rozpoczynajacych
˛
si˛e na “i” oraz
nazwiskach rozpoczynajacych
˛
si˛e na “k”.
Rysunek 6.3. Lista osób z zastosowanym filtrem
7. Testy
Ważnym etapem w procesie tworzenia aplikacji jest również jej
testowanie.
Dla wybranych fragmentów kodu warto stworzyć testy jed-
nostkowe, które stanowia˛ gwarancj˛e ich poprawności. Istotne jest jednak
podjecie
˛
decyzji, które fragmenty kodu b˛eda˛ testowane. Z jednej strony,
korzystne jest posiadanie jak najwi˛ekszej liczby testów. Wówczas wykonujac
˛ je regularnie podczas rozwoju aplikacji zapewniona jest stała kontrola
poprawności jej działania. Z drugiej strony obłożenie testami jednostkowymi
100% kodu jest zbyt pracochłonne lub czasem wre˛ cz niewykonalne.
Uzasadnione jest testowanie fragmentów kodu majacych
˛
istotny wpływ
na poprawne działanie aplikacji.
Testowanie bardzo złożonych obiek-
tów wia˛że si˛e z koniecznościa˛ zasymulowania rzeczywistego środowiska
pracy za pomoca˛ tzw.
mock objects.
Jest to wskazane, o ile nakład
pracy zwiazany
˛
z utworzeniem mock objects i testów jednostkowych nie
jest znaczacy
˛ w porównaniu z czasem przeznaczonym na implementacj˛e.
Testowanie bardzo prostych fragmentów kodu, w których istnieje niewielkie
prawdopodobieństwo popełnienia bł˛edu, jest zazwyczaj pozbawione uzasadnienia.
Kierujac
˛ si˛e powyższymi przesłankami zdecydowano si˛e na utworzenie
testów jednostkowych sprawdzajacych
˛
poprawność nietrywialnych metod
obiektów DAO oraz metod serwisowych, które maja˛ za zadanie wykonywanie
operacji na kilku obiektach DAO. Przetestowanie tych obiektów nie wymaga
znacznej pracochłonności, pozwala natomiast na zweryfikowanie, że operacje na danych, majace
˛ kluczowy wpływ na działanie systemu, wykonywane
sa˛ poprawnie.
7.1. Testy jednostkowe przy użyciu DBUnit
46
Do testowania wykorzystano szkielet DBUnit opisany w rozdziale 3.7.2.
Testy jednostkowe zostały utworzone jako klasy dziedziczace
˛
po klasie
TestCase. Implementacja polega na zainicjalizowaniu testu oraz implementacji metod testowych. Metoda˛ testowa˛ jest każda metoda rozpoczynajaca
˛
sie˛ słowem test. Wykorzystano również funkcjonalność DBUnit pozwalajac
˛ a˛
na ładowanie danych z plików XML.
Klasom testowym dostarczane sa˛ implementacje obiektów DAO lub klas
serwisowych wraz z testowa˛ sesja˛ Hibernate’a, wykonujace
˛
operacje na
testowej bazie danych.
Wewnatrz
˛
metody wykonywane sa˛ operacje na
testowanych obiektach, a nast˛epnie za pomoca˛ asercji sprawdzana jest
zgodność zwróconego wyniku z oczekiwanym.
Wydruk 7.1 zawiera wybrana˛ metod˛e testujac
˛ a˛ odczyt danych. Wykonywana jest operacja pobrania osoby po nazwie użytkownika, a nast˛epnie jest
weryfikowane, czy zwrócone zostały właściwe dane.
1
5
public void testGetByLogin ( ) {
Osoba osoba = osobaDao . getByLogin ( " jkowalski " ) ;
Assert . assertNotNull ( osoba ) ;
Assert . assertEquals ( osoba . getLogin ( ) , " jkowalski " ) ;
}
Wydruk 7.1. Metoda testujaca
˛ odczyt danych
Wydruk 7.2 zawiera wybrana˛ metod˛e testujac
˛ a˛ zapis danych. Testowana
jest metoda serwisowa getOrCreateFileByPath, której zadaniem jest
znalezienie w strukturze bazodanowej encji Plik o podanej ścieżce, badź
˛
utworzenie jej, jeśli nie istnieje. Najpierw wykonywana jest transakcja, a
nastepnie
˛
jest weryfikowane, czy zapisane dane rzeczywiście znajduja˛ si˛e w
bazie danych.
1
5
public void testGetOrCreateFileByPath ( ) throws ServiceException {
Plik plik ;
Transaction tx = plikDao . beginTransaction ( ) ;
try {
plik = filesystemService
. getOrCreateFileByPath ( " t e s t f o l d e r / f i l e " ) ;
plikDao . save ( p l i k ) ;
tx . commit ( ) ;
} catch ( Exception e ) {
47
tx . rollback ( ) ;
throw e ;
10
}
p l i k = f i l e s y s t e m S e r v i c e . getFileByPath ( " t e s t f o l d e r / f i l e " ) ;
Assert . assertNotNull ( p l i k ) ;
Assert . assertEquals ( p l i k . getNazwa ( ) , " f i l e " ) ;
15
}
Wydruk 7.2. Metoda testujaca
˛ zapis danych
Niespełnienie warunku zawartego w asercji powoduje rzucenie wyjatku
˛
i
zakończenie testu niepowodzeniem.
Mechanizm testów jednostkowych został podpi˛ety pod narz˛edzie Apache
Maven, dzi˛eki czemu podczas wykonywania standardowego polecenia kompilacji mvn clean install uruchamiane sa˛ również testy jednostkowe.
Pozwala to na ciagł
˛ a˛ kontrol˛e poprawności testowanego kodu.
8. Podsumowanie
W ramach niniejszej pracy inżynierskiej powstał systemu do zarzadzania
˛
multimedialnymi materiałami dydaktycznymi w formie archiwów ISO. Proces tworzenia systemu zawierał wszystkie etapy obecne w procesie budowy
systemów informatycznych - rozpoznanie zagadnienia, analiz˛e wymagań,
prototypowanie, wybór technologii, utworzenie modelu danych oraz implementacj˛e i testy.
Prace zakończyły si˛e sukcesem - ich skutkiem jest powstanie działajacej
˛
aplikacji.
Pomimo ukończenia, system posiada możliwości rozwoju. Przykładowo,
rozszerzona może być funkcjonalność wersjonowania tak, aby kontrola wersji obejmowała również pliki źródłowe. Do aplikacji webowej można dodać
nowe widoki i akcje realizujace
˛ nowe funkcjonalności. W nietrudny sposób
system może być dostosowany do obsługi nie tylko archiwów ISO ale także
innych, np. ZIP.
Na koniec, warto podkreślić, zestaw funkcjonalności, jakie oferuje powstały system, jest nieobecny w żadnym innym dost˛epnym na rynku systemie. Jest to zatem rozwiazanie
˛
wnoszace
˛ wartość dodana˛ do świata informatyki.
A. Wyglad
˛ gotowej aplikacji
Niniejszy dodatek przedstawia zrzuty ekranu przedstawiajace
˛ wyglad
˛ gotowej aplikacji.
A. Wyglad
Rysunek A.1. Ekran logowania
50
51
A. Wyglad
Rysunek A.2. Lista osób
A. Wyglad
Rysunek A.3. Formularz dodawania osób
52
A. Wyglad
Rysunek A.4. Ogólny raport zmian w katalogach
53
A. Wyglad
Rysunek A.5. Szczegółowy raport zmian w katalogach
54
Bibliografia
[1] Dokumentacja Apache Velocity.
http://velocity.apache.org/engine/releases/velocity-1.5/
vtl-reference-guide.html.
[2] Dokumentacja Hibernate ORM.
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/.
[3] Dokumentacja jQuery.
http://api.jquery.com/.
[4] Dokumentacja PostgreSQL.
http://www.postgresql.org/docs/9.3/interactive/index.html.
[5] Podrecznik
˛
Java SE 7.
http://docs.oracle.com/javase/tutorial/index.html.
[6] Bauer Christian, King Gavin. Hibernate in Action. Manning, Greenwich 2005.
[7] Garcia-Molina Hector, Ullman Jeffrey, Widom Jennifer. Systemy baz danych.
Kompletny podrecznik.
˛
Helion, wydanie ii, Gliwice 2011.

System do zarz ˛adzania archiwum obrazów ISO

Transkrypt

Podobne dokumenty

poziom podstawowy

Paulina Stec - Opracowanie i implementacja programu do

Patenty na oprogramowanie - monopol na pomysły?

Dzień Kobiet – 8 marca

Wprowadzenie do teorii chaosu w nierównowagowej mechanice

Sofizmaty - Zakład Logiki Stosowanej