portal konferencyjny umozliwiajacy˛ zarzadzanie˛ konferencja...

AKADEMIA GÓRNICZO-HUTNICZA IM. STANISŁAWA STASZICA W KRAKOWIE

WYDZIAŁ ELEKTROTECHNIKI, AUTOMATYKI,INFORMATYKI I INZYNIERII BIOMEDYCZNEJ

KATEDRA AUTOMATYKI I INZYNIERII BIOMEDYCZNEJ

Praca dyplomowa magisterska

Portal konferencyjny umozliwiajacy zarzadzanie konferencja naukowawykorzystujacy Internet jako kanał komunikacyjny pomiedzy

organizatorem i uczestnikami.Conference portal for managing scientific conference using the Internet

as a communication channel between organizers and participants.

Autor: Joanna Krzek-LubowieckaKierunek studiï£¡w: Automatyka i RobotykaOpiekun pracy: dr hab. Adrian Horzyk

Kraków, 2015

Oswiadczam, swiadomy(-a) odpowiedzialnosci karnej za poswiadczenie nieprawdy, zeniniejsza prace dyplomowa wykonałem(-am) osobiscie i samodzielnie i nie korzystałem(-am)ze zródeł innych niz wymienione w pracy.

Spis tresci

1. Wstep............................................................................................................................................... 9

1.1. Wprowadzenie ....................................................................................................................... 9

1.2. Cele pracy .............................................................................................................................. 9

1.3. Zastosowanie praktyczne....................................................................................................... 10

2. Analiza obecnie istniejacych aplikacji ......................................................................................... 11

2.1. Meeting application ............................................................................................................... 11

2.1.1. O aplikacji .................................................................................................................. 11

2.1.2. Wyglad ....................................................................................................................... 12

2.1.3. Dostepne funkcjonalnosci .......................................................................................... 12

2.1.4. Cena ........................................................................................................................... 12

2.1.5. Interakcja z aplikacja ................................................................................................. 13

2.1.6. Podsumowanie ........................................................................................................... 13

2.2. ICAISC .................................................................................................................................. 13

2.2.1. O aplikacji .................................................................................................................. 13

2.2.2. Wyglad ....................................................................................................................... 13


2.2.4. Cena ........................................................................................................................... 14


2.2.6. Podsumowanie ........................................................................................................... 14

2.3. EasyChair .............................................................................................................................. 15

2.3.1. Wyglad ....................................................................................................................... 15


2.3.3. Cena ........................................................................................................................... 16


2.3.5. Podsumowanie ........................................................................................................... 16

2.4. Podsumowanie....................................................................................................................... 16

3. Wstep teoretyczny .......................................................................................................................... 19

5

6 SPIS TRESCI

3.1. Java ........................................................................................................................................ 19

3.1.1. Powstanie Javy ........................................................................................................... 19

3.1.2. Programowanie w Javie ............................................................................................. 20

3.2. Spring .................................................................................................................................... 20

3.3. Maven .................................................................................................................................... 22

3.4. Mongo DB ............................................................................................................................. 23

3.5. Angular JS ............................................................................................................................. 24

3.6. MySQL .................................................................................................................................. 26

3.7. OOP ....................................................................................................................................... 28

3.8. CRUD .................................................................................................................................... 29

3.9. REST ..................................................................................................................................... 29

4. Analiza ............................................................................................................................................ 31

4.1. Opis wymagan ....................................................................................................................... 31


4.2. Opis rozwiazania ................................................................................................................... 33

5. Implementacja................................................................................................................................ 37

5.1. Architektura ........................................................................................................................... 37

5.1.1. Czesc serwerowa........................................................................................................ 37

5.1.2. Czesc po stronie uzytkownika.................................................................................... 40

5.1.3. Persystencja danych ................................................................................................... 41

5.1.4. Obsługa błedów.......................................................................................................... 43

5.2. Projektowanie RESTowego API............................................................................................ 44

5.3. Testy....................................................................................................................................... 45

5.3.1. Testy Jednostkowe...................................................................................................... 45

5.3.2. Testy Integracyjne ...................................................................................................... 46

5.3.3. Testy kontrolerów AngularaJS................................................................................... 46

6. Wyniki ............................................................................................................................................. 47

6.1. Prezentacja aplikacji .............................................................................................................. 47

6.1.1. Strona logowania........................................................................................................ 47

6.1.2. Dashboard .................................................................................................................. 47

6.1.3. Dane uzytkownika...................................................................................................... 48

6.1.4. Kalendarz ................................................................................................................... 49

6.1.5. Nowe konto ................................................................................................................ 49

6.1.6. Nowe konto - podanie błednych danych .................................................................... 50

J. Krzek-Lubowiecka Portal konferencyjny umozliwiajacy zarzadzanie konferencja naukowa

SPIS TRESCI 7

6.1.7. Nowa konferencja ...................................................................................................... 50

6.1.8. Nowa konferencja - podanie błednych danych .......................................................... 51

6.1.9. Nowy wykład w konferencji ...................................................................................... 51

6.1.10. Opis konferencji ......................................................................................................... 52

6.1.11. Opis konferencji - edytowanie danych....................................................................... 53

6.1.12. Materiały .................................................................................................................... 53

6.1.13. Plan wykładów - widok admina................................................................................. 54

6.1.14. Plan wykładów - widok standardowego uzytkownika ............................................... 55

6.2. Podsumowanie....................................................................................................................... 56

6.2.1. Wyglad ....................................................................................................................... 56


6.2.3. Cena ........................................................................................................................... 57


6.2.5. Automatyzacja ........................................................................................................... 57

7. Wnioski ........................................................................................................................................... 59

7.0.6. UX, czyli doswiadczenie uzytkownika ...................................................................... 59

7.0.7. Co w przyszłosci? ...................................................................................................... 59

7.0.8. Uzyte narzedzia.......................................................................................................... 59

Spis rysunków.................................................................................................................................. 61


8 SPIS TRESCI


1. Wstep

1.1. Wprowadzenie

30 kwietnia 1993 roku CERN uruchomił pierwsza strone internetowa1 i opublikował standard

WorldWideWeb. W tamtym okresie przypuszczalnie nikt nie zdawał sobie sprawy, jak wiele bedzie w

stanie zmienic jedna niepozorna strona www. 22 lata pózniej ciezko juz wyobrazic sobie zycie bez stałego

dostepu do sieci. Praktycznie wszystkie informacje, jakie kiedykolwiek udało sie posiasc człowiekowi,

znajduja sie obecnie w Internecie. Aplikacje webowe umozliwiaja kontakt ze znajomymi, przeglada-

nie filmów i słuchanie muzyki, dostep do ksiazek i materiałów stworzonych na drugiej czesci globu.

Powstała (i wciaz powstaje) równiez duza grupa aplikacji porzadkujacych oraz automatyzujacych co-

dzienne zadania człowieka: zaczynajac od inteligentnych kalendarzy, aplikacji zbierajacych dane zdro-

wotne i dzienników, konczac na aplikacji monitorujacej codzienna diete i spozycie wody. Zjawisko to ma

bardzo wazny, pozytywny wpływ na zycie przecietnego zjadacza chleba - ma on coraz wiecej wolnego

czasu.

1.2. Cele pracy

Jeszcze 10 lat temu strony internetowe były statycznymi zbiorami danych o watpliwych walorach

estetycznych. Obecnie jednak stale powiekszajaca sie liczba uzytkowników majacych stały dostep do

Internetu sprawia, ze wymagania stawiane aplikacji sa coraz wieksze. Aby odniesc sukces, musi ona

byc nie tylko odporna na obciazenie, bezpieczna z punktu widzenia dostepu do wrazliwych danych, ale

tez czytelna, łatwa w obsłudze i przede wszystkim „ładna”. Aby stworzyc aplikacje, która bedzie miała

szanse zdobyc popularnosc, nalezy przede wszystkim skupic sie na doswiadczeniach uzytkownika i to

na nich oprzec swoja prace. Wybór jezyka programowania, sposobu przechowywania danych i uzytych

frameworków nalezy uzaleznic od priorytetów nadanych przez przyszłych uzytkowników aplikacji.

Waznym aspektem tego procesu jest tworzenie oprogramowania łatwo rozszerzalnego i pozwalaja-

cego dokonywac zmian bez wpływu na inne czesci projektu. Tworzenie aplikacji iteracyjnie pozwala na

biezaco zbierac opinie uzytkowników i dostosowywac działanie aplikacji do ich potrzeb. W swojej pracy

chciałabym przedstawic proces twórczy, jaki prowadzi do powstania gotowego produktu, rozpoczynajac

od analizy dziedziny i wymagan stawianych aplikacji, do rozwiazania technicznego i implementacji.1http://info.cern.ch/hypertext/WWW/TheProject.html

9

10 1.3. Zastosowanie praktyczne

1.3. Zastosowanie praktyczne

Aplikacja, która powstanie jako czesc pracy, moze posłuzyc do obsługi konferencji naukowych na

uczelniach całego swiata. Czesc teoretyczna moze stanowic przewodnik po procesie tworzenia progra-

mów internetowych.


2. Analiza obecnie istniejacych aplikacji

Prace nad nowym projektem warto rozpoczac od rozpoznania, czy podobne rozwiazania sa juz do-

stepne na rynku. Przy tym procesie nalezy zwrócic uwage na mocne oraz słabe strony kazdej z aplikacji

oraz na komentarze uzytkowników. Negatywne opinie moga okazac sie pomocne w stworzeniu aplikacji

dostarczajacej te usługi, które nie sa dostepne badz tez nie sa uzyteczne dla przecietnego uzytkownika.

Aspekty wziete pod uwage przy porównywaniu:

– wyglad,

– dostepne funkcjonalnosci,

– cena,

– interakcja z aplikacja.

2.1. Meeting application

2.1.1. O aplikacji

Meeting application [1] jest aplikacja stworzona w celu uproszczenia procesu zarzadzania konfe-

rencjami. Mozna z niej korzystac na smartfonach, tabletach i laptopach. Zapewnia obsługe wydarzen

takich jak: konferencje, koncerty i wystawy. Moze pracowac online lub offline, jednak tylko w trybie

online dostepne sa wszystkie funkcjonalnosci. Posiada duze mozliwosci dostosowywania wygladu do

potrzeb uzytkownika, np. mozna zmienic kolor tła aplikacji, czcionke czy strefe czasowa, w jakiej sie

znajdujemy. Tworzenie strony konferencji jest bardzo proste: najpierw jej własciciel tworzy wydarze-

nie, nastepnie dodaje stosowne zasoby oraz niezbedne dane, po czym potwierdza swój wybór. W tym

momencie strona jest generowana. Wartym uwagi jest, ze dwa interfejsy, jakimi sa interfejs własciciela

i członka konferencji, sa od siebie odseparowane. Członek konferencji nie ma mozliwosci edycji da-

nych samej konferencji. Aplikacja nie oferuje zadnych narzedzi do zarzadzania wieloma konferencjami.

Wspiera tworzenie strony tylko jednego wydarzenia.

11

12 2.1. Meeting application

2.1.2. Wyglad

Meeting application jest aplikacja o bardzo nowoczesnym i przejrzystym interfejsie. Duze ikony

dokładnie wskazuja, gdzie mozemy znalezc dana funkcjonalnosc. Grafika w wysokiej rozdzielczosci

dobrze prezentuje sie zarówno na ekranie komputera, jak i smartfona. Cała strona pozostawia wrazenie

dobrze zaprojektowanego UI, znacznie przyspieszajacego prace nad konferencja. Warto zauwazyc, ze

uzytkownik ma mozliwosc dostosowania strony do swoich upodoban.

2.1.3. Dostepne funkcjonalnosci

Kazda konferencja moze byc opisana za pomoca rozległej ilosci danych, na przykład:

– harmonogram,

– miejsce, w jakim konferencja sie odbywa,

– pokoje spotkan,

– mówcy,

– nowosci,

– mapa z dodanymi wskaznikami, ułatwiajacymi członkom konferencji orientacje,

– dodawanie multimediów: zdjec, filmów, dzwieku.

Aplikacja oferuje równiez wiele metod automatyzacji pracy własciciela konferencji, takich jak: wy-

syłanie mailowych powiadomien do uczestników konferencji, wsparcie dla mediów społecznosciowych,

statystyki aktywnosci, mozliwosc ustawiania poziomów dostepu do zasobów dla poszczególnych uzyt-

kowników. Poniewaz Meeting Application jest zorientowana na uzytkownika i jego doznania, została do

niej dodana opcja tworzenia i wysłania ankiety dla członków konferencji, umozliwiajaca zebranie opinii

o juz zakonczonej konferencji. Istnieje tez opcja dodawania partnerów i sponsorów wydarzenia.

2.1.4. Cena

Cena licencji wynosi 1499 dolarów. Obejmuje ona nielimitowana ilosc pobran aplikacji przez człon-

ków konferencji, dostep do wszystkich funkcjonalnosci i danych oraz wsparcie techniczne (e-mail i

telefon). Ponadto firma zobowiazuje sie do zwrotu całej kwoty w ciagu 90 dni, jezeli uzytkownik nie

bedzie usatysfakcjonowany. Nalezy równiez pamietac, ze cena ta jest niezalezna od zasobów dodanych

do konferencji. Aplikacja jest dostepna przez Internet, istnieje tez mozliwosc pobrania jej na smartfona

z systemem operacyjnym Android albo iOS. Miłym dodatkiem, biorac pod uwage cene licencji, jest

mozliwosc skorzystania z 14-dniowej wersji próbnej programu.


2.2. ICAISC 13

2.1.5. Interakcja z aplikacja

Meeting Application jest bardzo przyjazna uzytkownikowi. Na przykład tworzenie konta dla nowego

uzytkownika jest bardzo wygodne: mozna to zrobic za pomoca kodu QR, tzw. social loginu (konto spo-

łecznosciowe) badz standardowej rejestracji, przy której nalezy podac imie, nazwisko i adres e-mail.

Dane sa walidowane na stronie, co znacznie przyspiesza proces dodawania nowego konta czy nowej

konferencji i likwiduje problem przetwarzania błednych danych po stronie serwera - w tym wypadku

formularz jest przesyłany, dopiero gdy cały bedzie poprawny.

2.1.6. Podsumowanie

Meeting Application jest aplikacja powstała, aby uproscic proces tworzenia i obsługi konferencji.

Umozliwia ona centralne sterowanie konferencja. Jej uzycie jest uzasadnione w przypadku wydarzen

posiadajacych duza ilosc członków potrzebujacych jedynie dostepu do odczytu zasobów konferencji.

Nie daje ona takze mozliwosci recenzowania prac. Cena moze wydawac sie wysoka, jednak biorac pod

uwage fakt, ze ilosc uzytkowników jest nieograniczona, jej wysokosc wydaje sie uzasadniona. Istotnym

szczegółem jest równiez nieograniczony dostep do pomocy technicznej, co zupełnie izoluje własciciela

konferencji od technicznych detali stojacych za działajaca strona. Uwage zwraca równiez przejrzysty,

nowoczesny interfejs znacznie ułatwiajacy znajdowanie interesujacych nas zasobów. Jest on swietna

wizytówka konferencji, zachecajaca do wziecia w niej udziału.

2.2. ICAISC

2.2.1. O aplikacji

ICAISC [2] jest konferencja majaca na celu wymiane wiedzy oraz doswiadczenia w dziedzinie

sztucznej inteligencji i programowania. Jest skierowana do naukowców, wykładowców akademickich

i specjalistów w dziedzinie badan nad sztuczna inteligencja. Kazda edycja konferencji otrzymuje osobna

strone internetowa, na której dostepne sa jej zasoby. Analiza dotyczy strony tej konferencji naukowej.

2.2.2. Wyglad

Strona konferencji posiada przejrzysty interfejs z menu umozliwiajacym wybór opcji do wyswie-

tlenia. Warto zauwazyc, ze po kliknieciu opcji w menu przeładowuje sie cała strona, co niepotrzebnie

zwieksza ruch sieciowy. Strona jest czytelna i przejrzysta, jednak robi gorsze wrazenie niz strona Meeting

Application. Nie ma mozliwosci dodania konta do portalu społecznosciowego badz tez zamieszczenia

obszernego CV. Strona nie daje uczestnikom mozliwosci wpływania na zawartosc i nie jest w zadnym

wymiarze interaktywna, nie mozna jej wiec nazwac nowoczesna aplikacja.


14 2.2. ICAISC


Uzytkownik ma dostep do nastepujacych danych:

– zakres i tematyka,

– wazne terminy,

– miejsce,

– komitet,

– zgłoszenia,

– wykłady,

– program,

– powiazane konferencje,

– poprzednie konferencje,

– sesje specjalne,

– płatnosc.

2.2.4. Cena

Aby móc dodac materiały naukowe, nalezy byc członkiem konferencji. Koszt uczestnictwa w niej to

3600 złotych. Dostep do ogólnych danych dotyczacych konferencji nie jest ograniczony.


W systemie ICAISC wszystkie ogólne dane dotyczace konferencji sa dostepne na stronie. Aby dodac

nowy materiał, uzytkownik jest przekierowany na podstrone, gdzie konieczne jest logowanie. Ponadto

niezautentykowany uzytkownik nie moze zobaczyc szczegółów konferencji, takich jak papiery, recenzje

czy filmy wideo powiazane z konferencja. Istnieje mozliwosc przejscia na strony poprzednich edycji

konferencji. Odbywa sie to poprzez klikniecie linku, po czym uzytkownik jest przekierowany na jej

strone.

2.2.6. Podsumowanie

ICAISC jest systemem przejrzystym i czytelnym. Dane sa statyczne, nie ma mozliwosci ich edycji

na miejscu. Brakuje równiez opcji dostosowania interfejsu do potrzeb uzytkownika. Nie ma mozliwosci

zintegrowania konta uzytkownika z kontami na portalach społecznosciowych (jak chociazby LinkedIn),

czy tez dodania wiekszej ilosci zdjec.


2.3. EasyChair 15

2.3. EasyChair

Easy Chair [3] jest systemem do zarzadzania konferencjami utrzymywanym przez Uniwersytet w

Manchester. Został on stworzony z mysla o konferencjach naukowych, stad logika aplikacji wspiera prze-

pływ akcji im towarzyszacy. Wersja podstawowa jest bezpłatna, płatne natomiast sa dodatkowe usługi

w jej ramach, co czyni ja bardzo uniwersalna. Na swojej stronie twórcy Easy Chair podaja, ze jest to

obecnie najpopularniejszy system do zarzadzania konferencjami.

2.3.1. Wyglad

Interfejs strony jest czytelny i jasny, co jest mocna strona Easy Chair. Brak zbednych informacji

nie rozprasza uzytkownika i nie utrudnia mu znalezienia guzików. Strona jest nieco przestarzała i nie

wykorzystuje mozliwosci, jakie daja nowoczesne biblioteki do stylizowania aplikacji. Jest watpliwe, aby

zwykły uzytkownik był zachwycony układem strony i uznał ja za „ładna”. Niestety, uzytkownik nie ma

mozliwosci konfiguracji wygladu aplikacji.


Ze wzgledu na fakt, ze jest ich zdecydowanie wiecej niz w poprzednio opisywanych aplikacjach,

wymienione zostały tylko najciekawsze:

– przesłanie plików zip, audio, video,

– dostep do dziennika wydarzen,

– mozliwosc dodawania anonimowych raportów,

– automatyczne wysyłanie notyfikacji,

– dyskusje online,

– w razie potrzeb papiery moga posiadac subrecenzentów,

– statystyki konferencji,

– automatyczne i manualne przypisywanie papierów do recenzentów,

– eksport danych do Excela, XMLa i plików CSV,

– wsparcie w uzyskiwaniu ostatecznych wersji papierów, np. automatyczne generowanie spisu tresci,

– obsługa pokoi, w których konferencja sie odbedzie,

– lista wydarzen,

– pobranie programu konferencji.


16 2.4. Podsumowanie

2.3.3. Cena

Easy Chair oferuje trzy rodzaje licencji: free, professional i executive. Licencje typu professional i

executive oferuja wiele dodatkowych funkcjonalnosci, takich jak wysyłanie maili do managerów i pre-

legentów, obsługe pokoi konferencyjnych i inne. Obsługa, tak jak i wersja desktopowa aplikacji, jest

dołaczona tylko do licencji executive. Maksymalny rozmiar papierów w tej opcji licencji to 100 MB. Za

kazde przekroczenie tej wielkosci naliczana jest dodatkowa opłata. Ceny poszczególnych licencji zaleza

od ilosci danych przechowywanych i przetwarzanych przez aplikacje.


Procesy takie jak tworzenia nowego konta czy tworzenie nowej konferencji sa skomplikowane i nie-

przyjazne uzytkownikowi. Po utworzeniu konta w aplikacji nalezy je uaktywnic, klikajac na link wysłany

na podany adres mailowy. Jesli uzytkownik poda błedne z punktu widzenia aplikacji dane, wyswietla ona

tresc błedu, która nie jest jednak pomocna dla przecietnego uzytkownika. Jezeli bład powstanie podczas

tworzenia nowej konferencji, cały proces nalezy powtórzyc. Walidacja danych nie jest wygodna, ponie-

waz dopiero po kliknieciu przycisku ’submit’ na wypełnionym formularzu zostaja wypisane błedy. Taka

logika sprawia, ze uzytkownik musi wiele razy poprawiac formularz, w którym, po kazdym kliknieciu

’submit’, pojawia sie nowy bład. Po utworzeniu konferencji nie jest ona dostepna od reki, poniewaz

musi byc przeprocesowana przez Easy Chair pod katem poprawnosci. Uzytkownik jest informowany

droga mailowa, ze konferencja została stworzona. Pomimo ze aplikacja upraszcza i automatyzuje wiele

procesów zwiazanych z obsługa i utrzymaniem konferencji, odniesc mozna wrazenie, ze wiecej czasu

uzytkownik musi poswiecic na obsługe aplikacji ze wzgledu na jej mało przyjazne rozwiazania.

2.3.5. Podsumowanie

Easy Chair została stworzona w celu ułatwienia członkom profesjonalnych konferencji naukowych

procesu tworzenia i zarzadzania nimi. Interfejs aplikacji jest jasny i czytelny, jednak sposób, w jaki zo-

stały zaprojektowane jej funkcjonalnosci, sprawia, ze uzytkownik musi nauczyc sie obsługi samej aplika-

cji. Z punktu widzenia uzytkownika jest to zdecydowanie złe rozwiazanie. Idealna aplikacja powinna byc

przejrzysta. Nalezy przyznac, ze w wersji płatnej Easy Chair oferuje bardzo wiele mozliwosci, jednak

warto zadac pytanie, czy oprócz dodatkowych funkcji nie zostanie równiez dodany czas, jaki własciciel

konferencji bedzie musiał poswiecic na nauczenie sie obsługi nowych funkcji.

2.4. Podsumowanie

Na rynku dostepnych jest wiele aplikacji, które zostały stworzone w celu ułatwienia i automatyzacji

pracy zwiazanej z uczestnictwem w konferencjach i spotkaniach. Tylko Easy Chair jest aplikacja po-

wstała w celu wsparcia wielu konferencji naukowych. Z kolei interfejs Meeting Application jest wart

uwagi, gdyz znacznie upraszcza interakcje z programem, jednak nie oferuje zaawansowanych funkcji


2.4. Podsumowanie 17

niezbednych do obsługi konferencji naukowych. Połaczenie czytelnego interfejsu Meeting Application

z bogactwem funkcjonalnosci Easy Chair dałoby w rezultacie aplikacje, która nie dodawałaby narzutu

czasu na obsługe samego programu i pomagała członkom konferencji w zarzadzaniu nia. Warto byłoby

równiez rozwazyc kwestie automatyzacji tak duzej ilosci procesów, jak tylko mozliwe.


3. Wstep teoretyczny

3.1. Java

3.1.1. Powstanie Javy

Kazdy nowy jezyk programowania powstaje, by rozwiazac problemy, których nie był w stanie roz-

wiazac jego poprzednik. Java, jako „dziecko” jezyków C i C++ powstała, aby udoskonalic i naprawic

wiele błednych konceptów wprowadzonych przez te jezyki. Jezyk C powstał, aby zawrzec w sobie po-

zornie sprzeczne cechy jezyków programowania: łatwosc uzycia, rozszerzalnosc, wydajnosc. Przed po-

wstaniem C programista musiał wybierac miedzy jezykami dajacymi duze mozliwosci, ale nieopartymi

na zasadach programowania strukturalnego, co czyniło je trudne w rozwijaniu (COBOL, FORTRAN), ła-

twymi do nauczenia sie i uzywania, ale nieposiadajacymi struktur danych (BASIC) i bardzo wydajnymi,

ale skomplikowanymi do nauczenia i uzywania (Assembler). C stanowiło odpowiedz na problemy pro-

gramistów przy tworzeniu nowego oprogramowania i okazało sie jezykiem bardzo wydajnym, łatwym

do nauczenia sie i dajacym duze mozliwosci. Wraz ze wzrostem złozonosci budowanych systemów rósł

równiez problem z ich utrzymaniem i czytelnoscia. Dla programistów coraz wiekszym problemem była

złozonosc systemów napisanych w C, ze wzgledu na podejscie strukturalne, którego C uzywał. Dlatego

tez w 1979 Bjarne Stroustrup stworzył jezyk C++, który pierwotnie nazwał „C z klasami”. Aby zwiek-

szyc „pojemnosc” nowego jezyka, zastosował dosc ciekawy koncept w programowaniu, jakim było pro-

gramowanie obiektowe. Pozostałe cechy jezyka C nie zostały zmienione. Dzieki takiej kombinacji C++

stał sie powszechnie uzywanym jezykiem i jest nim do dzis. [4]

Wraz z coraz czestszym uzyciem technologii w zyciu codziennym pojawiła sie potrzeba tworzenia

oprogramowania na urzadzenia elektroniczne róznego typu, od mikrofalówek i telewizorów po kompu-

tery z róznymi systemami operacyjnymi. C i C++ sa jezykami kompilowanymi na okreslone urzadzenie.

Aby móc uruchomic ten sam kod na róznych maszynach, nalezy przekompilowac go odpowiednim kom-

pilatorem. Biorac pod uwage fakt, ze na kazde nowe urzadzenie nalezy stworzyc tez kompilator, okazało

sie, ze jest to rozwiazanie zbyt drogie i czasochłonne. Pojawiła sie potrzeba jezyka, który kompilowany

raz, mógłby byc uruchomiony na róznych platformach. Aby rozwiazac ten problem, w 1991 roku pra-

cownicy Sun Microsystems: James Gosling, Patrick Naughton, Chris Warth, Ed Frank i Mike Sheridan

rozpoczeli prace nad Java. Drugim waznym wydarzeniem, które wpłyneło na aktualny kształt Javy, jest

powstanie Internetu. Pod koniec 1990 roku zostały stworzone podstawy HTML, natomiast juz w 1992

19

20 3.2. Spring

roku powstała pierwsza przegladarka internetowa Netscape. Poniewaz siec szybko zyskiwała popular-

nosc i składała sie z uzytkowników korzystajacych z róznych systemów operacyjnych, coraz powszech-

niejsza stawała sie swiadomosc, ze musi istniec mozliwosc uruchomienia tego samego kodu na róznych

komputerach. Uwzgledniajac te potrzeby, pierwszy Java Developer Kit został opublikowany 21 stycznia

1996 roku. Obecnie, czyli w 2015 roku, Java jest własnoscia Oracle Company i doczekała sie wersji 8.

3.1.2. Programowanie w Javie

Biorac pod uwage wymienione zalety Javy, nie zaskakuje fakt, ze jest tak szeroko uzywana. Wraz z

powstaniem Javy Enterprise i frameworków takich jak Spring, była z powodzeniem stosowana w duzych

aplikacjach bankowych, w programach branzy telekomunikacyjnej jak i w poczatkujacych startupach.

Tworzenie nowego oprogramowania w Javie znacznie upraszcza fakt, ze istnieje bardzo wiele dodatko-

wych, darmowych bibliotek oferujacych usługi niezawarte w samej bibliotece jezyka. Istnienie swiet-

nych srodowisk programistycznych w pełni wspierajacych Jave (Eclipse, Intellij, Netbeans) równiez ma

wpływ na jej popularnosc. Wszystkie te cechy sprawiły, ze jezyk ten został wybrany jako podstawowy

w tym projekcie.

3.2. Spring

Spring jest frameworkiem opartym na licencji open-source, stworzonym przez Roda Johnsona, któ-

rego I wersja została opublikowana w marcu 2004 roku. Spring powstał w odpowiedzi na problemy

powstałe przy programowaniu aplikacji z uzyciem Enterprise Java Beans. Pomimo ze bardzo uzyteczne,

EJB były rozwiazaniem zbyt złozonym do wszystkich zastosowan - szczególnie w małych projektach,

które korzystały tylko z niewielkiej czesci funkcjonalnosci oferowanych przez framework. [5] Ponizsze

strategie zostały zastosowane przy tworzeniu Springa.

Inversion of Control (odwrócenie kontroli) i Dependency Injection (wstrzykiwanie zaleznosci)Sa one ideami majacymi na celu zmniejszenie wzajemnego powiazania miedzy obiektami w

aplikacji. W standardowym projekcie klasa A, znajac dokładny typ kazdego obiektu z nia

współpracujacego i wyniki zwracane przez ich instrukcje, synchronicznie tworzy i inicjalizuje

swoje zaleznosci. Projekt utworzony w ten sposób jest trudny do testowania i dalszej rozbudowy,

dlatego tez stosuje sie zjawisko odwrócenia kontroli, czyli oddania jej generycznej czesci

aplikacji. To ona w odpowiednim momencie wywołuje metody stworzonego przez programiste

kodu. Szczególnym i bardzo popularnym przypadkiem IoC jest Dependency Injection, czyli

„wstrzykiwanie” zaleznosci. W podejsciu z uzyciem DI klasa A deklaruje, jakiego typu maja byc

jej zaleznosci, które tworzy, i wstrzykuje w odpowiednie miejsce kontener IoC. [6]

Aspect Oriented Programming (programowanie aspektowe) Programisci zauwazyli, ze w pewnych

problemach okreslone fragmenty kodu powtarzaja sie zawsze w tej samej kolejnosci, a ich kon-

figuracja nie jest czesto zmieniana. Pojawiło sie pytanie, czy nie ma mozliwosci odseparowania


3.2. Spring 21

powtarzajacego sie kodu i aplikowania go w odpowiednich miejscach? Oczywiscie taka mozli-

wosc istnieje i oferuje ja własnie programowanie aspektowe. Jest ono wyjatkowo uzyteczne w

przypadku zarzadzania transakcjami, połaczeniami z baza danych, bezpieczenstwa aplikacji czy

logowania. Takie podejscie do problemu sprawia, ze programista skupia sie na rozwiazaniu głów-

nego celu aplikacji, usługi poboczne delegujac do aspektów. Dzieki temu kod jest równiez znacz-

nie bardziej czytelny oraz łatwiejszy w konfiguracji, gdyz w przypadku wystapienia koniecznosci

poprawienia kodu aspektowego, zmiane aplikuje sie tylko w jednym miejscu.

Convention over Configuration (konwencja nad konfiguracja) Jest to paradygmat programowania

majacy uproscic prace programisty nad tworzeniem oprogramowania i definiujacy, jakimi zasa-

dami ma sie on kierowac. Oprócz zadan głównych, takich jak implementacja logiki aplikacji,

programista musi podjac wiele decyzji pobocznych, takich jak podział projektu na pakiety, na-

zewnictwo zmiennych, klas itp. Aby ułatwic mu to zadanie, Spring korzysta z konwencji opisu-

jacej te problemy, które zostały przyjete w swiecie programistów. Takie podejscie, oprócz zdjecia

odpowiedzialnosci z programisty, ma równiez druga, równie wazna zalete: narzut zwiazany z za-

poznaniem sie z nowym projektem został zmniejszony do minimum. Poniewaz kazda firma stosuje

te same konwencje odnosnie np. umieszczania kodu zródłowego i testów, wdrozenie nowego pro-

gramisty do projektu jest o wiele prostsze.

Spring ma budowe modułowa, która pozwala na wybór tylko tych pakietów, które sa potrzebne w projek-

cie. Sercem Springa jest Core Container, składajacy sie z modułów: spring-core, spring-beans, spring-

context, spring-context-support i spring-expression. Spring core zapewnia zarzadzanie beanami, kontek-

stem oraz Expression Language. Expression Language ułatwia zarzadzaniem obiektami w czasie działa-

nia programu. [7] Ponizsze moduły mozna właczyc do projektu. [8]

Spring Web zapewnia funkcjonalnosci uzyteczne przy pisaniu aplikacji webowych, takie jak załaczanie

plików i webowy kontekst aplikacji. Zawiera równiez klienta HTTP.

Spring JDBC to dodatkowy poziom abstrakcji nad modułem Java Database Connectivity.

Test jest pakietem wspierajacym pisanie testów jednostkowych i integracyjnych za pomoca JUnita i

TestNG. Zapewnia ładowanie i wgrywanie do pamieci podrecznej kontekstu Springa.

Spring Security zapewnia autentykacje i autoryzacje w ramach kontenera.

Spring Integration umozliwia integracje z zewnetrznymi systemami poprzez adaptery.

Spring Batch jest bardzo uzyteczny w przypadku przetwarzania duzych ilosci danych.

Spring Data to projekt stworzony do nowoczesnych technologii bazodanowych, takich jak nierelacyjne

bazy danych, frameworki MapReduce i serwisy w chmurze. Zapewnia równiez wsparcie dla rela-

cyjnych baz danych.


22 3.3. Maven

Rysunek 3.1: Moduły Springa, zródło: http://docs.spring.io/spring/docs/current/spring-framework-

reference/html/overview.html

3.3. Maven

Apache Maven jest projektem do zarzadzania projektem oraz bibliotekami, z których korzysta, czyli

dependencjami. Sercem Mavena jest plik xml nazywany POM (Project Object Model), w którym defi-

niuje sie strukture projektu, sposób budowania oraz dependencje projektu. Cele Mavena, czyli sposoby

budowania oprogramowania, realizowane sa przez wtyczki, które nie sa czescia Mavena, ale sa pobie-

rane z repozytorium podczas uruchomienia budowania. [9] Ponizej przedstawionych jest osiem najwaz-

niejszych z punktu widzenia budowy aplikacji celów, nazywanych głównym cyklem zycia. Powodzenie

kazdego kolejnego celu uzaleznione jest od realizacji celów znajdujacych sie przed nim. [10]

Validate - sprawdzenie, czy projekt jest poprawny i czy wszystkie niezbedne informacje zostały okre-

slone.

Compile - kompilowanie kodu zródłowego.

Test - uruchomienie testów jednostkowych.

Package - projekt jest pakowany w paczke.

Integration-test - przeprowadzenie testów integracyjnych.

Verify - walidacja paczki.


3.4. Mongo DB 23

Install - paczka umieszczana jest w repozytorium lokalnym - moze byc uzywana przez inne projekty

jako zaleznosc.

Deploy - paczka umieszczana jest w repozytorium zdalnym.

3.4. Mongo DB

MongoDB jest nierelacyjna baza danych stworzona na licencji open-source. Jak obiecuja twórcy,

Mongo jest bardzo wydajnym i skalowalnym systemem do przechowywania danych, które składowane

sa w formacie identycznym do JSONA, zwanym BSON. Na chwile obecna MongoDB jest najpopular-

niejsza baza danych typu NoSQL. [11] Główne cechy MongoDB wypisane zostały ponizej. [12]

Zorientowanie na dokumenty Programisci sa przyzwyczajeni do rozbijania informacji do postaci

przyjmowanej przez relacyjne bazy danych. MongoDB moze przechowywac cała strukture, co jest

bardziej intuicyjne dla człowieka oraz nie wymaga tylu operacji zapewniajacych integralnosc da-

nych, co relacyjna baza danych. Na przykład, zamiast rozbijac obiekt biznesowy opisujacy ksiazke

na mniejsze struktury typu autor, tytuł i tym podobne, mozna przechowywac wszystkie dane w

jednym obiekcie, nazwanym po prostu Ksiazka.

Zapytania ad hoc MongoDB zapewnia wsparcie przeszukiwania po polach, zakresach i wyrazeniach

regularnych. Zapytania moga zwracac odpowiednie pola z dokumentu oraz zawierac zdefiniowane

przez uzytkownika funkcje JavaScriptowe.

Indeksowanie Kazde pole w MongoDB moze byc indeksowane (sa to indeksy podobne do tych uzywa-

nych w relacyjnych bazach danych).

Replikacja Mongo zapewnia wysoka wydajnosc za pomoca zestawów replik składajacych sie z dwóch

lub wiecej kopii danych. Kazdy członek zestawu w danym momencie moze odgrywac role podsta-

wowej lub wtórnej repliki. Podstawowa replika domyslnie wykonuje wszystkie odczyty i zapisy

do bazy. Replika wtórna jest kopia danych uzyskana za pomoca replikacji. Jesli pojawia sie defekt

w pierwotnej replice, zestaw replik automatycznie dokonuje wyboru, która z replik wtórnych ma

zostac replika pierwotna. Repliki wtórne moga równiez obsługiwac operacje odczytu.

Load balancing (równowazenie obciazenia) MongoDB skaluje dane horyzontalnie za pomoca mecha-

nizmu zwanego partycjonowaniem poziomym. Uzytkownik wybiera klucz, który determinuje, jak

beda rozprowadzone dane w kolekcji. Sa one dzielone na zakresy w oparciu o podany klucz i

rozprowadzone na partycje. Mongo moze działac na wielu serwerach, bilansujac obciazenie i du-

plikujac dane, by zminimalizowac ryzyko utraty danych w przypadku awarii komputera głównego.

Dodatkowe maszyny moga byc dodane do juz działajacej bazy.

Składowanie plików MongoDB moze byc uzywane jako system plików, korzystajac z równowazenia

obciazenia replikacji danych na wielu maszynach. Funkcjonalnosc ta, zwana GridFS, załaczona


24 3.5. Angular JS

jest do sterownika Mongo i dostepna jest w jezykach wspieranych przez niego. Mongo udostepnia

funkcje do manipulacji plikami i ich zawartoscia dla programistów. Zamiast składowac cały plik

w jednym dokumencie, jest on dzielony na czesci i składowany w osobnych dokumentach. W

systemach złozonych z wielu komputerów pliki moga byc rozproszone i kopiowane wiele razy

pomiedzy róznymi maszynami, co znacznie zwieksza odpornosc na błedy i awarie.

Agregacja Do procesowania duzych ilosci danych i ich agregacji MongoDB oferuje algorytmy MapRe-

duce. Framework do agregacji umozliwia uzyskanie rezulatów podobnych do tych uzyskanych za

pomoca wyrazenia SQL GROUP BY.

Wykonanie kodu JavaScript po stronie serwera JavaScript moze byc uzywany w zapytaniach, funk-

cjach agregujacych takich jak MapReduce oraz wysłany bezposrednio do bazy w celu wykonania

funkcji.

Ograniczone kolekcje MongoDB wspiera kolekcje o ograniczonej wielkosci. Ten typ kolekcji utrzy-

muje kolejnosc wstawiania, natomiast po przekroczeniu deklarowanej wielkosci zachowuje sie jak

kolejka kolista.

3.5. Angular JS

AngularJS jest frameworkiem powstałym w celu uproszczenia pracy nad dynamicznymi aplikacjami

webowymi, utrzymywanym przez Google wespół z rzesza ochotników. Celem Angulara jest uproszcze-

nie procesu pisania aplikacji webowych oraz ich testowania. Dzieki zaadaptowaniu architektury MVC,

zastosowaniu Dependency Injection (wstrzykiwanie zaleznosci) oraz wprowadzeniu konceptu zwanego

Two-way Data Binding (dwustronne wiazanie danych) ten cel został osiagniety, czyniac z Angulara jeden

z najpopularniejszych frameworków webowych. Warto tez wspomniec, ze jest on oparty na załozeniu,

ze kod deklaratywny powinien byc stosowany podczas budowy UI i wiazania komponentów ze soba,

natomiast kod imperatywny powinien słuzyc do implementowania logiki biznesowej aplikacji. Aby ze

statycznej strony internetowej stworzyc dynamiczna aplikacje webowa, stosowane sa dwie taktyki.

– Zastosowanie dodatkowej biblioteki pozwalajacej na uzyskanie aplikacji dynamicznej (np. JQu-

ery) wywoływanej, w miare potrzeb, przez kod programisty.

– Implementacja frameworku zawierajaca metody napisane przez programiste. W tym podejsciu to

framework wywołuje kod programisty. Przykładami sa Durandal i Ember.

Angular realizuje inna filozofie, starajac sie zmniejszyc rozbieznosc pomiedzy składnia HTML a ko-

dem aplikacji. Umozliwia on pisanie własnych tagów HTML, zwanych tutaj dyrektywami, i nadawanie

im własnych zachowan. Główne cele Angulara wypisane zostały ponizej.

– Rozdzielenie manipulacji na DOMie (DOM - Document Object Model) od logiki aplikacji. Umoz-

liwia to testowanie kodu i uzywanie go w wielu róznych miejscach.


3.5. Angular JS 25

– Zdecydowane odseparowanie logiki po stronie klienta od tej po stronie serwera.

– Zapewnienie struktury i konwencji w tworzeniu aplikacji webowych.

– Upraszczanie zadan wykonywanych czesto.

Kluczowe pomysły zastosowane w Angularze:

MVC wzorzec Model-View-Controller (model-widok-kontroler) izoluje logike aplikacji od warstwy

prezentacji danych. Model jest odpowiedzialny za przechowywanie danych aplikacji oraz ich od-

swiezanie. Widok jest warstwa prezentacji danych w okreslonym formacie. Kontroler z kolei zaj-

muje sie interakcja z modelami, ich walidacja, przechwytywaniem odpowiedzi uzytkownika oraz

operacjami biznesowymi aplikacji. Kontroler przechwytuje zadania, po czym manipuluje mode-

lem, aby zapewnic widokowi potrzebne dane. Nastepnie widok prezentuje je w okreslony sposób

uzytkownikowi.

Two-way Data Binding (dwustronne wiazanie danych) szablon (nieskompilowany HTML z dyrekty-

wami) jest kompilowany przez przegladarke. Kazda zmiana widoku jest natychmiastowo odwzo-

rowywana w modelu i kazda zmiana w modelu jest propagowana do widoku. Poniewaz widok jest

tylko odwzorowaniem modelu, kontroler jest odseparowany od widoku. Dzieki temu testowanie

kontrolera w izolacji bez widoku i powiazanego DOMu jest bardzo proste.

Rysunek 3.2: Two-way data binding, zródło: https://docs.angularjs.org/guide/databinding


26 3.6. MySQL

Scope (zasieg) jest „klejem” miedzy kontrolerem a widokiem, odnoszacym sie do modelu aplikacji.

Podczas linkowania szablonów na zakres jest ustawiana dyrektywa watch, która umozliwia dy-

rektywom renderowanie DOMu w czasie rzeczywistym. Zakresy mozna zagniezdzac, moga tez

posiadac strukture hierarchiczna podobna do DOM. Kontrolery i dyrektywy korzystaja z zakresu i

nie maja dostepu do siebie nawzajem. Dzieki temu odseparowaniu kontroler nie ma zadnej wiedzy

o widoku, co wspiera testowanie.

Dependency Injection (wstrzykiwanie zaleznosci) tworzy komponenty, zarzadza dependencjami oraz

wstrzykuje je tam, gdzie sa potrzebne.

Serwisy to elementy, które pozwalaja raz stworzony kod uzywac w wielu miejscach. Kazdy z serwisów

w Angularze jest inicjalizowany leniwie (jest tworzony tylko wtedy, kiedy jest potrzebny) oraz

jest singletonem (tworzonym przez odpowiednia fabryke). Serwisy pozwalaja na tworzenie frag-

mentów kodu, którego mozna wywołac w wielu miejscach w aplikacji. Moga równiez słuzyc do

przesyłania danych pomiedzy kontrolerami.

Niektóre problemy, które likwiduje Angular JS sa przedstawione ponizej.

– Problem z rejestrowaniem callbacków (wywołanie zwrotne). Sprawiaja one, ze kod staje sie nie-

czytelny. Wymuszaja tez kopiowanie tych samych fragmentów kodu w wielu miejscach w aplika-

cji.

– Problem z niskopoziomowym manipulowania DOMem poprzez wprowadzenie mozliwosci dekla-

racji, jak zmienia sie aplikacja, gdy zmienia sie jej stan.

– Problem z marshallowaniem danych do i z UI. Umozliwia to łatwe modyfikowanie formularzy,

walidacje, wyswietlanie błedów walidacji, przesyłanie obiektów do i z serwera.

– Problem z koniecznoscia posiadania duzej ilosci kodu do inicjalizacji projektu.

Jak mozna sie dowiedziec w prezentowanym na oficjalnej stronie Angulara przewodniku dla pro-

gramistów, biblioteka ta została stworzona, by wspierac aplikacje typu CRUD. Implementacja aplikacji

przeprowadzajacych duza ilosc manipulacji na DOMie w krótkim czasie, takich jak gry internetowe, ze

wzgledu na swoje wysokie wymagania, moze byc problematyczna. W takim przypadku zaleca sie uzycie

jednej z niskopoziomowych bibliotek, np. jQuery. [13]

3.6. MySQL

MySQL jest jednym z najpopularniejszych na swiecie systemów do zarzadzania relacyjnymi bazami

danych. Obecnie jest własnoscia Oracle Corporation. Ze wzgledu na duze mozliwosci oraz fakt, ze pod-

stawowa wersja MySQL jest darmowa, jest on bardzo czestym wyborem przy projektowaniu aplikacji

webowych. Oczywiscie dostepna jest równiez wersja komercyjna. Od MySQL w wersji 5.6 dostepne sa

m.in.:


3.6. MySQL 27

– składowane procedury, uzywajace jezyka proceduralnego,

– triggery,

– kursory,

– online DDL dostepny podczas korzystania z InnoDB Storage Engine,

– zestaw trybów SQL słuzacych do kontroli zachowania serwera w czasie wykonania,

– transakcje z punktami zapisu, dostepne podczas korzystania z InnoDB Storage Engine,

– zgodnosc z regułami ACID podczas korzystania z InnoDB i NDB Cluster Storage Engines,

– wsparcie dla SSL,

– umieszczanie zapytan w pamieci podrecznej,

– zagniezdzone instrukcje SELECT,

– wbudowane wsparcie dla replikacji,

– wsparcie dla UNICODE,

– partycjonowanie tabel,

– grupowe polecenia commit, zbierajace transakcje z róznych połaczen w celu zwiekszenia ilosci

tych polecen na sekunde,

– wiele silników do składowania danych, umozliwiajacych wybór kodowania dla kazdej tabeli.

Bez watpienia na popularnosc MYSQL miał wpływ fakt, ze jest on dostepny na bardzo wiele plat-

form, takich jak: [14].

– Linux (x86, S/390, IA64 (Itanium), Alpha, PowerPC, AMD64 / EM64T),

– Windows (x86, x64),

– Solaris (SPARC, x86),

– MacOS X,

– i5/OS (IBM System I),

– Novell NetWare (x86),

– SGI,

– DEC OSF


28 3.7. OOP

3.7. OOP

Przed powstaniem konceptu programowania obiektowego powszechnym podejsciem było progra-

mowanie proceduralne, w którym to jeden główny program kontrolował „przepływ” wywołan i akcji w

programie. Ponadto logika zawarta w metodach oraz dane były od siebie zupełnie odseparowane. Takie

podejscie delegowało wszystkie odpowiedzialnosci, takie jak kontrola przepływu, kolejnosc wywołan

metod, obsługa wyjatków, do jednej metody, co z kolei prowadziło do bardzo skomplikowanego kodu.

Kod napisany w ten sposób stanowi prawdziwe wyzwanie, jesli chodzi o wprowadzanie zmian w przy-

szłosci. Aby zlikwidowac te problemy, inzynierowie oprogramowania wprowadzili nowy termin - pro-

gramowanie obiektowe. Poniewaz grupowanie danych i zaleznosci miedzy nimi w obiekty jest intuicyjne

i zrozumiałe dla kazdego, programowanie obiektowe pozytywnie wpłyneło na rozumienie programów

przez programistów. Obiekt składa sie ze zmiennych opisujacych go oraz metod, czyli zachowan. Dzieki

przeniesieniu logiki przekształcajacej dane z dodatkowych funkcji do wnetrza obiektu kazdy z obiek-

tów stał sie samoorganizujacy. [15] Z punktu widzenia programisty z programowaniem obiektowym

scisle powiazanych jest 5 zasad spopularyzowanych przez Roberta C. Martina na poczatku 2000 roku.

Opisuja one podstawowe reguły oraz wzorce, jakimi powinien kierowac sie programista przy tworzeniu

programów obiektowych. [16]

Single Responsibility (pojedyncza odpowiedzialnosc) Klasa powinna miec tylko jeden powód do

zmiany.

Open-closed (otwarty-zamkniety) W celu dodania nowego zachowania powinno sie byc w stanie roz-

szerzyc kod poprzez dziedziczenie zamiast przez zmienianie kodu zródłowego danej klasy.

Liskov Substitution Principle (zasada podstawienia Liskov) Kazda klasa bazowa moze byc zasta-

piona swoja podklasa. Innymi słowy, jesli B dziedziczy zachowanie po klasie A, to w programie

musi istniec mozliwosc zastapienia obiektu A obiektem B.

Interface Segregation (separacja interfejsów) Klient nie powinien zalezec od metod, których nie

uzywa. Oznacza to podział duzych interfejsów na mniejsze, dzieki czemu kazdy klient bedzie

uzywał tylko konkretnego interfejsu, z którego metod korzysta.

Dependency Inversion (odwrócenie zaleznosci) Moduły znajdujace sie na wysokim poziomie abstrak-

cji nie powinny zalezec od tych znajdujacych sie na niskim poziomie. Pozadane jest, aby zalezały

one od pewnego kontraktu (np. interfejsu) pomiedzy modułami wysokopoziomowymi i niskopo-

ziomowymi. [17]


3.8. CRUD 29

3.8. CRUD

CRUD opisuje podstawowe funkcje dostepu do danych i interakcji z nimi. Stworzone na potrzeby

persystowania danych stosowane sa tez w kontekscie tworzenia aplikacji z interfejsem uzytkownika.

CRUD składa sie z:

Create Stwórz lub dodaj nowe encje,

Read Czytaj lub wyszukaj istniejace dane,

Update Uaktualnij lub edytuj istniejace dane,

Delete Usun (co nie zawsze oznacza fizyczne usuniecie, moze to byc np. deaktywacja) dane. [18]

3.9. REST

Od czasu powstania Internetu istniała koniecznosc komunikacji pomiedzy serwisami. Było to uzy-

skiwane za pomoca mechanizmów takich jak SOAP, CORBA, JSON-RPC czy serwisów opartych na

WSDLu, które jednak były zbyt skomplikowane na potrzeby komunikacji internetowej. Aby zapełnic

te luke, powstał Representational State Transfer (REST) - styl architekturalny stworzony dla rozproszo-

nych i skalowalnych webserwisów uzywajacych hipermediów, definiujacy jednolity interfejs komunika-

cji. Typowym protokołem, z którego korzystaja REST-owe webserwisy, jest HTTP. Aby Stworzyc serwis

w pełni zgodny z RESTem, nalezy stosowac sie do ponizszych ograniczen. [19]

Klient-serwer Klient nie powinien byc swiadomy, w jaki sposób dane sa przetwarzane oraz reprezen-

towane po stronie serwera. Takie podejscie z jednej strony sprawia, ze serwer moze zmieniac

wewnetrzna reprezentacje danych oraz detale dotyczace implementacji poszczególnych usług, z

drugiej strony zas zwieksza skalowalnosc całego systemu poprzez uproszczenie komponentów

serwera. Przenosnosc interfejsu uzytkownika pomiedzy platformami jest równiez zapewniona, po-

niewaz nie zalezy w zaden sposób od danych przetwarzanych przez system.

Bezstanowy Komunikacja pomiedzy klientem a serwerem musi byc bezstanowa z natury, co oznacza,

ze kazde zapytanie pochodzace od klienta powinno zawierac wszystkie informacje niezbedne do

jego zrozumienia przez serwer. Poza tym klient nie powinien korzystac z kontekstu na serwerze

(np. stan sesji uzytkownika). Wprowadzenie bezstanowosci sprawia, ze monitorowanie systemu

staje sie prostsze, gdyz wszystkie dane dotyczace stanu uzytkownika w danym momencie sa za-

warte w zapytaniu. Dzieki temu detekcja błedów oraz próby obsługi awarii w systemie wymagaja

mniejszej ilosci kroków. Bezstanowy system jest równiez lepiej skalowalny, poniewaz zagadnienie

współdzielenia danych uzytkownika na wielu serwerach i ich poprawnej replikacji jest zlikwido-

wane. W praktyce bezstanowosc jest realizowana poprzez dołaczenie do kazdego zapytania uzyt-

kownika wszystkich niezbednych danych (w przypadku autoryzacji/autentykacji bedzie to zaha-


30 3.9. REST

szowane hasło i ID uzytkownika). Zwieksza to ilosc danych przesyłanych przez siec, co prowadzi

do wiekszego jej obciazenia.

Cache Kolejne ograniczenie powstało, aby zmniejszyc obciazenie sieci po wprowadzeniu bezstanowo-

sci. Kazda odpowiedz od serwera powinna byc opisana jako mozliwa lub niemozliwa do skła-

dowania w schowku pamieci podrecznej po stronie klienta. Jesli odpowiedz jest oznaczona jako

mozliwa do przechowywania, klient w kolejnych interakcjach moze korzystac z wczesniej uzy-

skanych danych. Takie podejscie zmniejsza ilosc interakcji z serwerem oraz zwieksza szybkosc

odpowiedzi systemu na zadania uzytkownika. Nakłada jednak powazne ograniczenie dotyczace

aktualnosci przetwarzanych danych w wypadku, gdyby były one uzyskane z serwera nowym za-

daniem.

Jednolity interfejs Głównym konceptem rozrózniajacym RESTa od tradycyjnego podejscia, takiego jak

SOAP, jest jednolity interfejs pomiedzy komponentami. Implementacja serwisu moze z biegiem

czasu ulegac zmianie, jednak klient nie jest tego swiadomy, dzieki czemu nie musi wprowadzac

zadnych zmian w wywołaniach tegoz serwisu. Minusem takiego podejscia jest fakt, ze jednolity

interfejs zapewnia transport informacji w standardowej formie, zamiast w specyficznej dla potrzeb

aplikacji, co zmniejsza wydajnosc serwisów. REST został stworzony jako interfejs dla powszech-

nych przypadków uzycia sieci Web i moze nie byc tak efektywny w przypadku innych przypadków

uzycia. W skład jednolitego interfejsu wchodza ograniczenia pomagajace opisac zachowanie kom-

ponentów. Sa to: [20]

– identyfikacja zasobów,

– manipulacja zasobami poprzez reprezentacje,

– samoopisujace sie wiadomosci,

– hipermedia jako silnik stanu aplikacji (HATEOAS),

– system warstwowy,

– code on demand (kod na zadanie).


4. Analiza

4.1. Opis wymagan

Przed przystapieniem do implementacji projektu nalezy jasno zdeklarowac, jakie cele powinna ona

spełniac. Cele stawiane przed aplikacja:

– całkowita automatyzacja,

– proste i czytelne UI,

– ukrycie przed uzytkownikiem szczegółów implementacji.


Dane aplikacji beda udostepniane tylko zautentykowanym uzytkownikom. Wsród nich dostepne beda

role standardowego uzytkownika oraz własciciela konferencji. Mozliwosci zwykłego uczestnika konfe-

rencji sa nastepujace:

– edycja swoich danych,

– zaproszenie uzytkowników do konferencji,

– uczestnictwo w nieograniczonej liczbie konferencji,

– dodawanie zdjec do swojego profilu,

– ocenianie konferencji,

– ocenianie wykładowców,

– korzystanie z danych przypisanych do kazdej z konferencji, takich jak plan i tematyka wykładów,

mapy, spis wykładowców.

Jezeli uzytkownik jest włascicielem konferencji, zyskuje on nastepujace mozliwosci:

– dodawanie zasobów do konferencji: papierów, zdjec, filmów,

– usuniecie konferencji,

31

32 4.1. Opis wymagan

– edycja tresci konferencji,

– przypisanie wykładowców do konferencji.

Wymagania stawiane aplikacji od strony technicznej:

Skalowalnosc Juz na etapie projektowania oprogramowania nalezy rozwazyc, jaka architektura apli-

kacji sprawi, ze w przyszłosci obsługa duzej ilosci uzytkowników nie bedzie problemem. Przede

wszystkim nalezy zrezygnowac z przechowywania aktywnej sesji uzytkownika po stronie serwera

i zdecydowac sie na bezstanowosc. Przy takim podejsciu kazdy wzrost popularnosci aplikacji be-

dzie sie wiazał jedynie z dołozeniem serwera. Ponadto nalezy jak najwieksza liczbe zadan umie-

scic po stronie klienta.

Wydajnosc Czas odpowiedzi aplikacji na zadania jest bardzo waznym kryterium z punktu widzenia

uzytkownika. Znaczna latencja systemu moze skutecznie zniechecic do dalszego uzywania na-

wet najbardziej zdeterminowanego uzytkownika. Oprócz zapewnienia bezstanowosci połaczenia

klient-serwer nalezy upewnic sie, ze warstwa łaczenia z baza danych efektywnie wykorzystuje

połaczenia oraz nie doprowadza do zbyt długiego czekania uzytkowników na odpowiedz.

Odpornosc na błedy Bardzo wazna cecha systemu jest odseparowanie uzytkownika od błedów apli-

kacji. Kazdy wyjatek „przepuszczony” przez aplikacje nie dosc, ze nie wskaze uzytkownikowi,

co poszło nie tak, to moze zdradzic szczegóły implementacji konkretnego serwisu. One z ko-

lei moga posłuzyc do przygotowania ataku korzystajacego z dziur w konkretnej technologii/bi-

bliotece. Kazde dane przekazywane przez uzytkownika nalezy walidowac po stronie klienta, aby

umozliwic natychmiastowa poprawe, oraz po stronie serwera przed ich procesowaniem. Uchroni

to aplikacje przez mozliwymi atakami.

Bezpieczenstwo Kwestia ochrony danych uzytkowników jest kluczowa. Nalezy dołozyc wszelkich sta-

ran, aby uniemozliwic niepowołany dostep do nich. Na szczescie na rynku dostepnych jest wiele

gotowych rozwiazan pomagajacych odpowiednio zabezpieczyc aplikacje. Przykładem moze byc

Spring Security. Posiada on bogaty wybór metod i zródeł autentykacji uzytkownika.

Testowalnosc i łatwosc w zarzadzaniu Nalezy załozyc, ze system bedzie ulegał wielu zmianom i uła-

twic ich przeprowadzenie. Najlepszym rozwiazaniem jest luzne powiazanie komponentów ze soba

oraz umozliwienie testowania kazdego z nich osobno.

Persystowanie danych Oczywiscie aplikacja potrzebuje równiez systemu do składowania oraz zarza-

dzania danymi. Poniewaz dane przechowywane przez nia sa encjami posiadajacymi zestaw relacji,

relacyjna baza danych jest dobrym wyborem. Transakcje, dostepne w wiekszosci takich baz, sa

równiez bardzo wazne z punktu widzenia spójnosci danych. Aplikacja, oprócz danych domeno-

wych, posiada zestaw danych pomocniczych (takich jak dane o miescie, w którym odbywa sie

konferencja, czy tez o uniwersytetach w Polsce), które nie maja zdefiniowanych relacji miedzy


4.2. Opis rozwiazania 33

soba. Ponadto ich struktura moze sie zmienic wraz z upływem czasu. Dobrym rozwiazaniem jest

umieszczenie ich w nierelacyjnej bazie danych. Takie rozwiazanie sprawi, ze bedzie mozna czesto

dodawac i modyfikowac dodatkowy zestaw danych bez modyfikowania struktury danych głów-

nych. Ponadto odczytywanie ich nie wpłynie na ogólne osiagi aplikacji.

Niska cena Na koszty całej aplikacji składa sie kilka czynników. Sa to koszty wynajecia wykwalifiko-

wanych programistów, którzy stworza aplikacje, koszty oprogramowania oraz bibliotek przez nich

uzywanych, koszt narzedzi oraz sprzetu (serwery, infrastruktura sieciowa, laptopy) oraz koszty

utrzymania oprogramowania. Aby ograniczyc koszty licencji, mozna skorzystac z darmowego

oprogramowania. Natomiast na koszty utrzymania składaja sie dwa typy: koszt wsparcia ofero-

wanego klientom oraz koszt naprawiania błedów w programie. Przy automatyzacji wielu zadan w

aplikacji wsparcie techniczne dla klientów nie powinno byc konieczne, natomiast koszt utrzyma-

nia oprogramowania bedzie niski, jesli przy jego tworzeniu zostana zastosowane reguły dobrego

kodu opisane w dziale Teoria.

Atrakcyjnosc wizualna Jak powszechnie wiadomo, wiekszosc ludzi jest wzrokowcami, reagujacymi

pozytywnie na rzeczy "ładne". Aby praca z konferencjami była przyjemnoscia, warto zadbac o

efekt wizualny. Mozliwosci, jakie oferuja biblioteki takie jak Twitter Bootstrap oraz jQuery, sa

ogromne i z pewnoscia przełoza sie na pozytywne doznania uzytkowników. Nalezy pamietac, aby

akcje zawarte w aplikacji były jasne i krótkie ("Dodaj", "Usun", "Modyfikuj") oraz umieszczone

na elementach dobrze widocznych. Uzytkownik nie moze spedzic nawet jednej minuty na zasta-

nawianiu sie, jak osiagnac dany rezultat.

4.2. Opis rozwiazania

Aplikacja bedzie podzielona na dwie czesci: serwer oraz klienta. Zostanie zaimplementowana z uzy-

ciem dwóch głównych technologii: Javy po stronie serwera oraz JavaScriptu po stronie uzytkownika.

Wsparciem dla strony serwerowej bedzie Spring Framework, natomiast szkieletem aplikacji od strony

UI bedzie Angular JS. Opis czesci serwerowej znajduje sie ponizej.

Dostep do danych Poniewaz dostep do danych powinien byc ukryty przed uzytkownikiem, bedzie on

realizowany w warstwie serwerowej. Zarówno interakcje z relacyjna (MySQL), jak i nierelacyjna

baza danych (MongoDB) beda realizowane przez API stworzone w tym celu. Warstwa abstrakcji

do interakcji z baza danych bedzie Spring JDBC (Java Database Connectivity). Umozliwi ona

łatwiejsze budowanie zapytan oraz opakowanie wyjatków pochodzacych z bazy danych w wyjatki

typu unchecked.

Integracja z czescia klienta Strona serwerowa bedzie wystawiała RESTowe API udostepniajace dane

klientowi. Poza mozliwoscia wywołania metod z niego strona klienta nie bedzie wchodziła w

interakcje ze strona serwerowa. RESTowe API zostanie zaimplementowane z uzyciem modułu

Spring MVC, natomiast kazdy z webserwisów bedzie kontrolerem w sensie Springa.


34 4.2. Opis rozwiazania

Dystrybucja Aplikacja bedzie uruchamiana na kontenerze aplikacji Apache Tomcat oraz pakowana do

WARa.

Wyjatki Szczegóły błedów aplikacji nie beda udostepniane uzytkownikom. Zamiast tego zostana zde-

finiowane odpowiednie metody, które, w razie wystepowania wyjatku, przekaza kod mówiacy, ze

akcja przebiegła niepoprawnie.

Logowanie Sytuacje krytyczne beda logowane oraz zapisywane w plikach w celu umozliwienia przy-

szłej inwestygacji.

Bezpieczenstwo Dane uzytkownika do logowania to adres e-mail i hasło. Beda one przechowywane w

bazie danych. Do ich zabezpieczenia uzyty zostanie Spring Security, który bedzie zarzadzał logo-

waniem i wyciaganiem danych uzytkownika z bazy. Spring bedzie zapisywał ciasteczko sesyjne po

stronie uzytkownika, które z kolei bedzie przesyłane z kazdym zadaniem HTTP. Po wylogowaniu

Spring dezaktywuje dane ciasteczko.

Testy Aby zapewnic niezawodnosc logiki zawartej w aplikacji, testy strony serwerowej beda podzie-

lone na dwie kategorie: testy jednostkowe oraz testy integracyjne. Testy jednostkowe beda te-

stowały tylko jedna klase i beda przeprowadzane bez uzycia kontekstu Springa, natomiast testy

integracyjne beda testowały interakcje komponentów miedzy soba i beda przeprowadzane w ra-

mach kontekstu Springa. Testy beda realizowane z uzyciem frameworków testowych JUnit oraz

Spring Test.

Czesc klienta bedzie zaimplementowana przy uzyciu AngularaJS oraz bibliotek pomocniczych do

prezentowania danych. Warstwa ta bedzie zajmowała sie prezentowaniem danych uzytkownikowi. W

celu uzyskania tych danych z poziomu Angulara beda wykonywane zadania HTTP do strony serwero-

wej. Kontrolery beda zajmowały sie wykonaniem zadania, przetwarzaniem odpowiedzi oraz jej wyswie-

tleniem. Dodatkowe moduły uzyte do stworzenia „bogatego” UI:

jQuery Biblioteka JavaScriptowa umozliwiajaca łatwa manipulacje dokumentami HTML.[21]

XEditable Pakiet oferujacy bogate mozliwosci edycji oraz zapisu danych w komponentach Twitter Bo-

otstrap. [22]

Twitter Bootstrap Biblioteka składajaca sie z szablonów CSS oraz plików JavaScript, wzbogacajaca

standardowe elementy HTML.[23]

dir-Pagination Biblioteka implementujaca dyrektywy słuzace do paginacji elementów zdefiniowanych

w Angularze.[24]

Bootbox.js Biblioteka oferujaca atrakcyjne wizualnie okienka.[25]

Moment.js Proste zarzadzanie czasem poprzez JavaScript.[26]


4.2. Opis rozwiazania 35

Angular Calendar Implementacja kalendarza umozliwiajaca dodawanie do niego obiektów zdefinio-

wanych w AngularJS.[27]

DateTime picker Implementacja okienka do wybierania daty i czasu.[28]

Angular Google Maps Dyrektywy do zarzadzania mapami Google w aplikacji.[29]


36 4.2. Opis rozwiazania


5. Implementacja

5.1. Architektura

Aplikacja jest podzielona na dwie czesci: czesc serwerowa oraz czesc znajdujaca sie po stronie uzyt-

kownika. Dzieki takiemu podejsciu aplikacja bedzie skalowalna oraz zmniejszy sie widoczne i istotne

dla uzytkownika opóznienie.

5.1.1. Czesc serwerowa

Odpowiedzialnosci czesci serwerowej aplikacji:

– zarzadzanie dostepem do aplikacji,

– implementacja logiki domenowej,

– udostepnianie danych na zadanie,

– dostep do baz danych.

W tradycyjnym podejsciu korzystajacym z pakietu Spring MVC to Springowe kontrolery zajmuja sie

odbieraniem zadan HTTP i zwracaniem odpowiednich widoków (zazwyczaj plików .jsp, ale tez .html).

Taka architektura wiaze jednak niepotrzebnie strone serwerowa z warstwa wyswietlania danych, tak wiec

odseparowane od siebie zostało zarzadzanie wyswietlaniem odpowiednich stron i zarzadzanie zasobami,

czyli danymi aplikacji. Wyjatkiem jest pierwsze zadanie HTTP, na które odpowiada Spring, zwracajac

główna strone aplikacji.

37

38 5.1. Architektura

Rysunek 5.1: Logowanie do aplikacji

Kazde kolejne zadanie przeładowania strony jest realizowane przez logike zawarta w Angularze.

Strona serwera realizuje tylko zadania o zasoby.

Rysunek 5.2: Pobieranie danych

Klasy implementujace poszczególne funkcjonalnosci sa podzielone na pakiety zgodnie z funkcja,

jaka spełniaja w aplikacji. Poszczególne pakiety to:

Controller Kontroler jest komponentem obsługujacym zadanie HTTP. Po otrzymaniu zadania kontener

Springa deleguje je do odpowiedniego kontrolera, w zaleznosci od zadeklarowanych parametrów

zadania. Kontrolery sa jedynym punktem styku czesci serwerowej i czesci znajdujacej sie po stro-

nie uzytkownika. Przykładowa metoda obsługujaca zadanie typu POST jest przedstawiona poni-

zej. Warto zauwazyc, ze jako ciało zadania przyjmowany jest obiekt typu Conference. Mapowanie

pomiedzy parametrami zadania przesłanymi przez uzytkownika UI a obiektem Conference jest

dokonywane przez Springa z uzyciem bibliotek takich jak jackson-mapper.

1

2 @RequestMapping (method = RequestMethod .POST , consumes = " a p p l i c a t i o n / j s o n " )

3 @ResponseBody

4 @ResponseStatus (HttpStatus .CREATED )

5 p u b l i c String addNewConference (

6 @RequestBody Conference conference


5.1. Architektura 39

7 ) t h ro ws ConferenceException , ParseException {

8 logger .info ( " Reques t f o r c r e a t i o n new c o n f e r e n c e : " + conference .toString ( ) ) ;

9 conference .conferenceDate = dateUtils .formatDate (conference .conferenceDate ) ;

10 conferenceService .addConference (conference ) ;

11 r e t u r n " C o n f e r e n c e added s u c c e s s f u l l y . " ;

12 }

Listing 5.1: Dodaj nowa konferencje

DAO Data Access Objects sa warstwa abstrakcji nad tradycyjnym JDBC. Ukrywaja one szczegóły do-

stepu do danych przed serwisami, zajmuja sie m.in. mapowaniem danych na obiekty, przechwy-

tywaniem wyjatków zwracanych przez baze danych i translowaniem ich na wyjatki definiowane

przez Springa. Warto zauwazyc, ze kazdy z nich jest wyjatkiem typu unchecked, w zwiazku z

czym nie ma potrzeby deklarowania bloków try-catch. Zarówno dostep do danych zawartych w

bazie MySQL, jak i zawartych w MongoDB, jest realizowany przez te warstwe (ale oczywiscie

przez osobne klasy, zgodnie z zasada pojedynczej odpowiedzialnosci). Metoda z warstwy DAO

wyciagajaca zadane konferencje z bazy danych:

1 p u b l i c Conference getConferenceByNameAndStatus (String conferenceName , String ←↩conferenceStatus ) {

2 Object [ ] params = new Object [ ] {conferenceName , conferenceStatus } ;

3 r e t u r n getJdbcTemplate ( ) .queryForObject (SELECT_CONFERENCE_BY_NAME_AND_SUBJECT , params ,

4 new ParameterizedRowMapper<Conference> ( ) {

5 @Override

6 p u b l i c Conference mapRow (ResultSet resultSet , i n t i ) t h ro ws SQLException {

7 Conference conference = new Conference (

8 resultSet .getString ( " conferenceName " ) ,

9 resultSet .getString ( " c o n f e r e n c e S u b j e c t " ) ,

10 resultSet .getString ( " c o n f e r e n c e L o c a t i o n " ) ,

11 resultSet .getString ( " ownerEmail " ) ,

12 resultSet .getString ( " streetAndHouseNum " ) ,

13 resultSet .getString ( " c i t y " ) ,

14 resultSet .getString ( " p o s t a l C o d e " ) ,

15 resultSet .getString ( " c o u n t r y " ) ,

16 resultSet .getString ( " c o n f e r e n c e S t a t u s " ) ,

17 ( new SimpleDateFormat (APPLICATION_DATE_FORMAT ) .format (resultSet .getDate ( " c o n f e r e n c e D a t e←↩" ) ) ) ,

18 n u l l , n u l l ) ;

19 r e t u r n conference ;

20 }

21 } ) ;

22 }

Listing 5.2: Pobierz dane konferencji z bazy danych

Model Pakiet model zawiera w sobie klasy typu POJO (Plain Old Java Object, czyli zwykłe obiekty

Javowe) agregujace dane w logiczne obiekty. Słuza one do transportowania danych pomiedzy war-

stwami aplikacji, od warstwy DAO do warstwy kontrolerów.



Service Serwisy stanowia niejako serce aplikacji. Implementuja logike biznesowa.

1 @Transactional (rollbackFor = Throwable . c l a s s )

2 p u b l i c vo id removeConference (String conferenceName , String conferenceStatus ) {

3 logger .debug ( " Removing c o n f e r e n c e " + conferenceName + " " + conferenceStatus ) ;

4 conferenceDAO .removeConferenceSubject (conferenceName , conferenceStatus ) ;

5 conferenceDAO .removeConferenceParticipant (conferenceName , conferenceStatus ) ;

6 conferenceDAO .removeMaterialComments (conferenceName , conferenceStatus ) ;

7 conferenceDAO .removeMaterial (conferenceName , conferenceStatus ) ;

8 conferenceEventDao .removeEvent (conferenceName ) ;

9 conferenceDAO .removeConference (conferenceName , conferenceStatus ) ;

10 logger .debug ( " C o n f e r e n c e removed s u c c e s s f u l l y " ) ;

11 }

Listing 5.3: Serwis usuwajacy konferencje

5.1.2. Czesc po stronie uzytkownika

Odpowiedzialnosci czesci aplikacji znajdujacej sie po stronie uzytkownika:

– zarzadzanie widokami,

– wyswietlanie danych i ich formatowanie,

– obsługa interakcji z uzytkownikiem.

Trzonem aplikacji napisanej w AngularJS jest plik konfiguracyjny. Znajduje sie w nim deklarowanie

modułów uzytych w aplikacji oraz ich konfiguracja, czyli np.:

– deklarowanie ustawien Google Maps,

– deklarowanie sciezek routingu,

– konfiguracja zachowan dla poszczególnych zdarzen wysyłanych przez kontrolery Angularowe (za-

rzadzaja one m.in. dostepem do podstron),

– zarzadzanie logowaniem.

W projekcie przesunieta została kontrola nad wyswietlaniem odpowiednich widoków do skryptów

napisanych w Angularze. W zwiazku z tym wygodnym rozwiazaniem było zadeklarowanie powiazan

miedzy kontrolerami a widokami. Kazdy z nich współdzieli zakres, w którym jest dostepny do modyfi-

kacji odpowiedni model (lub modele). Widoki nie współdziela miedzy soba zakresów, tak wiec nie ma

mozliwosci współdzielenia miedzy nimi danych. Aby obejsc to ograniczenie, zostały stworzone serwisy,

które sa warstwa posredniczaca. Powiazanie szablonów HTML z kontrolerami:

1 $routeProvider



2 .when(’/account’, {

3 templateUrl: ’/resources/templates/account.html’,

4 controller: ’UserController’

5 })

6 .when(’/new’, {

7 templateUrl: ’/resources/templates/newAccount.html’,

8 controller: ’NewAccountController’

9 })

10 .when(’/login’, {

11 templateUrl: ’/resources/templates/logIn.html’,

12 controller: ’NavigationController’

13 })

14 .when(’/message’, {

15 templateUrl: ’/resources/templates/userMessage.html’,

16 controller: ’NewAccountController’

17 })

18 .when(’/newConference’, {

19 templateUrl: ’/resources/templates/newConference.html’,

20 controller: ’NewConferenceController’

21 })

22 .when(’/home’, {

23 templateUrl: ’/resources/templates/main.html’,

24 controller: ’NavigationController’

25

26 })

27 .when(’/conference’, {

28 templateUrl: ’/resources/templates/conference.html’,

29 controller: ’singleConferenceController’

30

31 })

32 .when(’/status’, {

33 templateUrl: ’/resources/templates/status.html’,

34 controller: ’statusController’

35 });

Listing 5.4: Routing

5.1.3. Persystencja danych

Główne dane aplikacji, łatwo dajace sie zamodelowac do postaci obiektów, zostały umieszczone w

relacyjnej bazie danych. Jej projekt jest przedstawiony na rysunku:



Rysunek 5.3: Projekt bazy danych



O ile dane główne aplikacji, takie jak informacje o konferencjach i uzytkownikach, przypuszczalnie

beda miały taka sama strukture, to juz struktura danych słownikowych moze ulec znacznej zmianie.

Aby uniknac problemów przy rozbudowie zwiazanych z koniecznoscia z przemapowaniem ich w bazie

i aplikacji, umieszczone zostały w bazie nierelacyjnej, która nie nakłada tak sztywnych ograniczen na

strukture przechowywanych danych.

5.1.4. Obsługa błedów

Obsługa błedów w aplikacji podzielona jest na dwie warstwy: przechwytywanie wyjatków rzuco-

nych po stronie kodu Javowego oraz prezentacja rezultatów akcji uzytkownikowi po stronie UI. Ponie-

waz z reguły wyjatki typu checked w Javie zmuszaja programiste do zanieczyszczania kodu blokami

try-catch, które z praktycznego punktu widzenia niczego nie daja, bloki try-catch nie zostały uzyte w

aplikacji. Zamiast tego kazda metoda mogaca rzucic wyjatek, po prostu deklaruje go w swojej sygna-

turze. Zostaje w ten sposób osiagnieta propagacja wyjatków z warstwy DAO do warstwy serwisowej, a

nastepnie do warstwy kontrolerów Springowych, które pełnia funkcje punktów styku strony serwerowej

z uzytkownikiem. W tym miejscu wyjatki sa przechwytywane (w zaleznosci od typu) oraz tłumaczone

na odpowiedni status. Jest on nastepnie zwracany uzytkownikowi w formacie json. Kod przechwytujacy

wyjatek w kontrolerze:

1 @ExceptionHandler(Exception.class)

2 @ResponseStatus(HttpStatus.METHOD_NOT_ALLOWED)

3 @ResponseBody

4 public String handleAll(Exception e) {

5 logger.warn(e.getMessage());

6 return "Something went wrong";

7 }

Listing 5.5: Łapanie wyjatków w kontrolerze

Potem status zwrócony przez serwer jest przechwytywany przez funkcje obsługujaca zadanie HTTP,

co ilustruje kolejny listing:

1 $scope.saveConference = function () {

2 $scope.conf.ownerEmail = sharedProperties.getUserEmail();

3 $scope.conf.conferenceStatus = sharedProperties.getAccountStatus();

4 $scope.conf.conferenceDate=$scope.dt;

5 $http.post(’/conferences’, $scope.conf)

6 .success(function (data) {

7 $rootScope.message = data;

8 sharedStatus.setStatus(data);

9 $location.path(’/status’);

10 })


44 5.2. Projektowanie RESTowego API

11 .error(function (data, status, headers, config) {

12 $rootScope.message = data;

13 sharedStatus.setStatus(data);

14 $location.path(’/status’);

15 });

16 };

Listing 5.6: Obsługa sytuacji wyjatkowych w kontrolerze Angulara

Nastepnie tresc wiadomosci jest wyswietlana uzytkownikowi:

Rysunek 5.4: Status błedu

Poniewaz dzielenie sie z uzytkownikiem detalami dotyczacymi wystepujacych wyjatków nic mu nie

mówi oraz niepotrzebnie eksponuje szczegóły implementacji, zostały one przed nim ukryte. Warto zwró-

cic uwage, ze „poziom” wyjatków przechwytywanych po stronie springa zalezy tylko od programisty -

mozna zadeklarowac osobna obsługe dla kazdego typu wyjatku. Mozna równiez posłuzyc sie jednym

generycznym typem, który wyłapie wszystkie wyjatki w aplikacji.

5.2. Projektowanie RESTowego API

Projektowanie API RESTowego nalezy rozpoczac od okreslenia obiektów domenowych, jakimi be-

dzie zarzadzała aplikacja. Kazdy z nich bedzie zasobem, do którego dostep musimy zapewnic poprzez

API aplikacji. Na kazdym z zasobów, czyli rzeczowników, bedzie wykonana pewna akcja, okreslana

czasownikiem. W moim wypadku czasownikami sa metody protokołu HTTP, które zostały zmapowane

z CRUDowych metod w nastepujacy sposób:[19]Akcja CRUD Metoda HTTP

CREATE POST

READ GET

UPDATE PUT

DELETE DELETETakie podejscie w naturalny sposób wykorzystuje wszystkie metody HTTP. Aby dostep do zasobów

był intuicyjny i zgodny ze sposobem, w jakim standardowo okreslamy akcje na rzeczownikach w nor-

malnym zyciu, nalezy pamietac o liczbach pojedynczej i mnogiej. Przykładem moze byc zadanie GET

„/users/13”, który mozemy rozumiec, jako „pobierz uzytkownika numer 13 z kolekcji uzytkowników”.

Postepujac zgodnie z tymi regułami, podstawowe API aplikacji jest przedstawione ponizej. Dodat-

kowe zadania, np. o zasoby kazdego z uzytkowników, sa w tworzone w sposób analogiczny i dołaczane


5.3. Testy 45

do podstawowego zadania. Na przykład zapytanie POST o dodanie papieru przez danego uzytkownika

bedzie wygladało nastepujaco: POST /confUsers/email/materials/.[20]

Akcja Metoda HTTP Zwracany status URL

Dodaj uzytkownika POST 201 CREATED /confUsers/

Modyfikuj konto uzytkownika PUT 204 NO CONTENT /confUsers/email/

Usun uzytkownika DELETE 204 NO CONTENT /confUsers/email

Pobierz liste uzytkownikow GET 200 OK /confUsers/

Dodaj uniwersytet POST 201 CREATED /universities/

Modyfikuj uniwersytet PUT 204 NO CONTENT /universities/name/

Usun uniwersytet DELETE 204 NO CONTENT /universities/name

Pobierz wszystkie uniwersy-

tety

GET 200 OK /universities/

Dodaj konferencje POST 201 CREATED /confUsers/email/conf/

Modyfikuj konferencje PUT 204 NO CONTENT /confUsers/email/conf/confName/

Usun konferencje DELETE 204 NO CONTENT /confUsers/email/conf/confName/

Pobierz wszystkie konferencje GET 200 OK /confUsers/email/conf/

5.3. Testy

5.3.1. Testy Jednostkowe

Testy jednostkowe testuja tylko jedna klase. Kazde zaleznosci z dodatkowymi komponentami, jakie

ta klasa posiada, sa zastepowane zaslepkami (tzw. mock objects). Przykładowy test, sprawdzajacy, czy

metoda z warstwy DAO została wywołana odpowiednia ilosc razy:

1 @Test

2 public void shouldCallDAOOnlyOnce() throws ConferenceException {

3 Conference conference = new Conference(VALID_CONFERENCE_NAME, ←↩VALID_CONFERENCE_STATUS);

4 when(conferenceDAO.getConferenceByNameAndStatus(VALID_CONFERENCE_NAME, ←↩VALID_CONFERENCE_STATUS)).thenReturn(conference);

5 conferenceService.getConferenceByNameAndStatus(VALID_CONFERENCE_NAME, ←↩VALID_CONFERENCE_STATUS);

6 verify(conferenceDAO.getConferenceByNameAndStatus(VALID_CONFERENCE_NAME, ←↩VALID_CONFERENCE_STATUS), times(1));

7 }

Listing 5.7: Test unitowy warstwy DAO


46 5.3. Testy

5.3.2. Testy Integracyjne

W testach integracyjnych testowane sa równiez powiazania pomiedzy klasami. Jako przykład został

przedstawiony test sprawdzajacy, czy odpowiednie konferencje zostana zwrócone na zadanie HTTP o

wszystkie konferencje uzytkownika:

1 @Test

2 p u b l i c vo id getConference_success ( ) t h r ow s Exception {

3 mockMvc .perform (get ( " / c o n f U s e r s / " + VALID_OWNER_EMAIL + " / A l l " ) )

4 .andExpect (status ( ) .isOk ( ) )

5 .andExpect (jsonPath ( " $ " , hasSize ( 1 ) ) )

6 .andExpect (jsonPath ( " $ [ 0 ] . conferenceName " , is ( "C++Conf " ) ) )

7 .andExpect (jsonPath ( " $ [ 0 ] . c o n f e r e n c e D e s c r i p t i o n " , is ( "C++ Programming " ) ) )

8 .andExpect (jsonPath ( " $ [ 0 ] . c o n f e r e n c e L o c a t i o n " , is ( " U n i v e r s i t y o f S c i e n c e and Technology " ) ) ) ;

9 }

Listing 5.8: Test integracyjny kontrolera Springowego

5.3.3. Testy kontrolerów AngularaJS

Oprócz testowania strony serwerowej nalezy równiez przetestowac działanie warstwy przegladarko-

wej. Przykładowy test sprawdzajacy zachowanie kontrolera dodajacego nowe konto uzytkownika:

1 describe ( ’ NewAccoun tCon t ro l l e r ’ , function ( ) {

2 beforeEach (module ( ’ app ’ ) ) ;

3

4 var $controller ;

5

6 beforeEach (inject (function (_$controller_ ) {

7 $controller = _$controller_ ;

8 } ) ) ;

9

10 describe ( ’ $scope . g r a d e ’ , function ( ) {

11 it ( ’ s a v e s new u s e r a c c o u n t ’ , function ( ) {

12 var $scope = { } ;

13 var controller = $controller ( ’ NewAccoun tCon t ro l l e r ’ , { $scope : $scope } ) ;

14 $scope .save ( ) ;

15 expect ($scope .user .accountStatus ) .toEqual ( ’ACTIVE ’ ) ;

16 } ) ;

17 } ) ;

18 } ) ;

Listing 5.9: Test kontrolera Angularowego


6. Wyniki

6.1. Prezentacja aplikacji

Zasoby aplikacji sa dostepne dopiero po zalogowaniu. Strona została podzielona na dwa główne

widoki: widok konta uzytkownika i dane konferencji. Dostep do pierwszego z nich jest zapewniony

przez przycisk ’Account’ dostepny w górnym pasku menu. Z kolei dostep do danych konferencji jest

zapewniony po kliknieciu w przycisk ’View’ przy nazwie konferencji na stronie głównej.

6.1.1. Strona logowania

Strona logowania do aplikacji:

Rysunek 6.1: Logowanie do aplikacji

6.1.2. Dashboard

Strona główna aplikacji widoczna po zalogowaniu. Wyswietlane sa zarówno konferencje, do których

uzytkownik jest zapisany, jak i propozycje (nadchodzace konferencje). Po kliknieciu w przycisk ’View’

przenosimy sie do widoku danych konferencji.

47

48 6.1. Prezentacja aplikacji

Rysunek 6.2: Dashboard

6.1.3. Dane uzytkownika

Widok danych uzytkownika. Wszystkie pola z wyjatkiem emaila sa edytowalne.

Rysunek 6.3: Dane uzytkownika


6.1. Prezentacja aplikacji 49

6.1.4. Kalendarz

Kalendarz z zaznaczonymi wydarzeniami, w których uzytkownik bierze udział. Dostepne sa naste-

pujace podwidoki: rok, miesiac, tydzien oraz dzien. Przyciski previous oraz next ułatwiaja nawigacje po

kalendarzu. Po zapisaniu sie do danej konferencji wszystkie wydarzenia z nia zwiazane sa automatycznie

wpisywane do kalendarza uzytkownika.

Rysunek 6.4: Kalendarz

6.1.5. Nowe konto

Tworzenie nowego konta. Kazde z pól jest walidowane osobnym walidatorem. Dzieje sie to po stronie

UI. Przycisk ’Sign in’ pozostanie nieaktywny, dopóki uzytkownik nie poprawi wszystkich błedów oraz

nie wypełni wszystkich pól wymaganych.



Rysunek 6.5: Nowe konto

6.1.6. Nowe konto - podanie błednych danych

Przykładowy komunikat walidacji danych uzytkownika przy dodawaniu nowego konta.

Rysunek 6.6: Nowe konto - podanie błednych danych

6.1.7. Nowa konferencja

Tworzenie nowej konferencji. Poprawnosc kazdego z pól jest sprawdzane po stronie UI przez wali-

dator. Przycisk ’Add’ pozostanie nieaktywny, dopóki uzytkownik nie poprawi wszystkich błedów oraz

nie wypełni wszystkich pól wymaganych.



Rysunek 6.7: Nowa konferencja

6.1.8. Nowa konferencja - podanie błednych danych

Przykładowy komunikat walidacji danych uzytkownika przy dodawaniu nowej konferencji.

Rysunek 6.8: Nowa konferencja - podanie błednych danych

6.1.9. Nowy wykład w konferencji

Dodawanie nowego wykładu do konferencji.



Rysunek 6.9: Nowy wykład

6.1.10. Opis konferencji

Widok danych konferencji. Kazde z pól jest edytowalne.

Rysunek 6.10: Opis konferencji



6.1.11. Opis konferencji - edytowanie danych

Po kliknieciu na kazde z pól mozna wyedytowac jego wartosc.

Rysunek 6.11: Opis konferencji - edytowanie danych

6.1.12. Materiały

Widok na materiały dodane do konferencji. Po kliknieciu w przycisk ’View’ plik otwiera sie w no-

wym oknie.



Rysunek 6.12: Materiały

6.1.13. Plan wykładów - widok admina

Jezeli zalogowany uzytkownik jest włascicielem danej konferencji, ma on dodatkowa mozliwosc

usuwania wykładów.

Rysunek 6.13: Plan wykładów, widok admina



6.1.14. Plan wykładów - widok standardowego uzytkownika

Standardowy uzytkownik moze tylko odczytywac plan wykładów.

Rysunek 6.14: Plan wykładów, widok standardowy



6.2. Podsumowanie

Rezultatem pracy jest aplikacja webowa oferujaca wsparcie przy zarzadzaniu konferencjami nauko-

wymi. Stanowi zapełnienie luki obecnej na rynku, zapewniajac bogactwo funkcjonalnosci oraz przejrzy-

sty interfejs uzytkownika.

6.2.1. Wyglad

Aplikacja posiada nowoczesny i przejrzysty interfejs uzytkownika, pod wzgledem stylu podobny do

Meeting application. Ilosc ikon została ograniczona do minimum. Wybrane kolory sa zywe, lecz nie

odciagaja uwagi od tresci. Zdecydowanie jest on bardziej przyjazny uzytkownikom od interfejsu Easy

Chair czy tez ICAISC.


Funkcjonalnosci oferowane przez aplikacje:

– utworzenie nowego konta,

– autentykacja uzytkownika,

– filtrowanie dostepu do zasobów w zaleznosci od okreslonych praw dostepu,

– tworzenie nowych konferencji,

– dodawanie materiałów i zdjec,

– dostep do danych konferencji oraz ich edycje,

– dodawanie wykładowców,

– dostep do danych konferencji,

– automatyczne dodawanie wydarzen do kalendarza,

– automatyczne zaznaczanie interesujacych miejsc na mapie,

– ocenianie wykładowców, konferencji i materiałów.

Pod wzgledem dostepnych funkcjonalnosci aplikacja przegrywa z aplikacja Easy Chair. Nalezy jednak

pamietac, ze ta ostatnia była budowana przez ponad 13 lat, ponadto dzieki zastosowanej architekturze

dalszy rozwój nie bedzie wymagał zmiany istniejacego kodu, istnieje równiez mozliwosc ponownego

uzycia juz stworzonych komponentów.


6.2. Podsumowanie 57

6.2.3. Cena

Istnieje kilka mozliwosci komercjalizacji wyniku pracy, jakim jest aplikacja. Kazdy z nich zakłada

umieszczenie jej na serwerze oraz udostepnienie odbiorcom, jednak róznia sie one pobieraniem od nich

opłat. Pierwszym sposobem jest nienakładanie zadnych ograniczen na funkcjonalnosci dostepne uzyt-

kownikom, lecz nałozenie opłat w zaleznosci od zuzytych zasobów, np. członek konferencji załacza-

jacy plik przekraczajacy wskazany rozmiar musiałby zapłacic za jego przechowywanie. Druga mozli-

woscia jest zaoferowanie okreslonej liczby podstawowych funkcjonalnosci wszystkim uzytkownikom,

natomiast nałozenie płatnych licencji na dodatkowe funkcje. Takie własnie podejscie stosuje Easy Chair.


Aplikacja jest bardzo responsywna, co znacznie ułatwia prace z nia. Na przykład klikniecie w pole

tygodnia w kalendarzu w widoku rocznym przenosi uzytkownika do widoku tygodnia, natomiast klik-

niecie w pole dnia ukazuje jego rozkład godzinowy.

6.2.5. Automatyzacja

Waznym aspektem pracy jest całkowita automatyzacja wszystkich procesów. Uzytkownik aplika-

cji nie potrzebuje pomocy przy obsłudze konferencji, nie powstaje równiez narzut czasowy powstały

na skutek czekania uzytkownika na odpowiedz centrum wsparcia. Jest to podejscie podobne do tego wi-

docznego w Meeting application, natomiast zupełnie przeciwne podejsciu w aplikacji Easy Chair. Dzieki

brakowi koniecznosci posiadania pracowników przegladajacych kazda nowa konferencje spadaja koszty

utrzymania aplikacji.


7. Wnioski

Cel pracy, jakim było zaprojektowanie czytelnego oraz łatwego w obsłudze portalu konferencyjnego,

został osiagniety. Dzieki zastosowaniu Javy jako jezyka implementujacego czesc serwerowa jest on prze-

nosna na wiele platform, natomiast dzieki uzyciu bibliotek w jezyku JavaScript strona jest dynamiczna i

estetyczna.

7.0.6. UX, czyli doswiadczenie uzytkownika

W swojej pracy autor starał sie zaprezentowac proces powstawania nowej aplikacji od planowania jej

funkcjonalnosci do wyboru technologii i implementacji. Mnogosc darmowych frameworków sprawia, ze

z jednej strony programista moze skorzystac z wielu juz gotowych komponentów, lecz z drugiej strony

oczekiwania uzytkowników sa bardzo wysokie. Na rynku programistycznym powszechnym jest zatrud-

nianie pracowników specjalizujacych sie w User Experience, czyli w doswiadczeniach uzytkowników

zwiazanych z interakcja z aplikacja. Obecnie aplikacja nie musi juz tylko wykonywac dobrze swojego

zadania, musi ona tez byc łatwa w uzyciu, wrecz „przezroczysta” dla zwykłego uzytkownika.

7.0.7. Co w przyszłosci?

Przypuszczalnie nikt nie jest w stanie stwierdzic, jakie wymagania w stosunku do aplikacji pojawia

sie w przyszłosci. Nie da sie przewidziec, czy biblioteki uzyte w aplikacji i obecnie działajace ze soba

bez problemów, beda kompatybilne w przyszłosci. Nie jest równiez jasne, ilu uzytkowników bedzie miał

portal konferencyjny za 5 czy 10 lat, ani tez, jakie funkcjonalnosci beda wtedy potrzebne. Dlatego warto

przemyslec architekture i unikac scisłego wiazania ze soba poszczególnych komponentów. Odseparo-

wanie strony serwerowej od warstwy działajacej w przegladarce jest bardzo dobrym tego przykładem -

jesli w przyszłosci firma Google zrezygnuje z rozwijania AngularaJS, przeniesienie logiki UI na inny

framework nie bedzie tak problematyczne, gdyz warstwa serwerowa pozostanie bez zmian.

7.0.8. Uzyte narzedzia

Uzycie Springa, jako szkieletu aplikacji znacznie wpłyneło na produktywnosc autora. Dzieki jego

modularnosci mozliwe było uzycie tylko niezbednych pakietów, co wpłyneło na ostateczna wielkosc

zbudowanej aplikacji. Szczególnie pakiet Spring MVC widocznie zmniejszył czas pracy nad czescia

59

60

webowa projektu-zamiast tworzyc własne wersje serwletów mozliwe było skorzystanie z juz gotowych

implementacji i skupienie sie na poprawnym zastosowaniu wzorca architektonicznego, jakim jest REST.

Autor zauwazył równiez, ze dzieki zastosowanym bibliotekom kod aplikacji stał sie bardzo czytelny oraz

samoopisujacy. Kolejna dobra decyzja było zastosowanie AngularaJS, jako szkieletu aplikacji po stronie

UI. Znacznie zwiekszyło to predkosc dodawania nowych funkcjonalnosci, głównie dzieki mozliwosci

wielokrotnego uzywania komponentów oraz wiekszej ich czytelnosci (podział na kontrolery i serwisy).


Spis rysunków

3.1 Moduły Springa, zródło: http://docs.spring.io/spring/docs/current/spring-framework-

reference/html/overview.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Two-way data binding, zródło: https://docs.angularjs.org/guide/databinding . . . . . . . 25

5.1 Logowanie do aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2 Pobieranie danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3 Projekt bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Status błedu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1 Logowanie do aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.3 Dane uzytkownika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Kalendarz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.5 Nowe konto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.6 Nowe konto - podanie błednych danych . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.7 Nowa konferencja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.8 Nowa konferencja - podanie błednych danych . . . . . . . . . . . . . . . . . . . . . . . 51

6.9 Nowy wykład . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.10 Opis konferencji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.11 Opis konferencji - edytowanie danych . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.12 Materiały . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.13 Plan wykładów, widok admina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.14 Plan wykładów, widok standardowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

61

62 SPIS RYSUNKÓW


Bibliografia

[1] Meeting Application, https://meetingapplication.com/

[2] ICAISC, http://www.icaisc.eu/

[3] Easy Chair, http://www.easychair.org/

[4] Schildt Herbert, Java The Complete Reference, 9th Edition, Oracle Press, 11 Marzec 2014, ISBN-

13: 978-0-07-180856-9

[5] Walls, Craig, Spring in Action, 4th Edition: Covers Spring 4, Manning Publications, 15 Pazdziernik

2014, ISBN-13: 978-1-61729-120-3

[6] Fowler Martin, Inversion of Control Containers and the Dependency Injection pattern,

http://martinfowler.com/articles/injection.html

[7] Praca zbiorowa, Spring Framework Reference Documentation,

http://docs.spring.io/spring/docs/current/spring-framework-reference/html/overview.html

[8] Projects, http://spring.io/projects

[9] Varanasi Balaji, Belida Sudha, Introducing Maven, Apress, 29 listopad 2014, ISBN-13: 978-1-484-

20842-7

[10] Available Plugins, https://maven.apache.org/plugins/index.html

[11] Introduction to MongoDB, http://docs.mongodb.org/manual/core/introduction/

[12] MongoDB Manual Contents, http://docs.mongodb.org/manual/contents/

[13] AngularJS Guide, https://docs.angularjs.org/guide/introduction/

[14] DuBois Paul, MySQL, Fifth Edition, Addison-Wesley Professional, 2 kwiecien 2013, ISBN-13:

978-0-321-83387-7

[15] Shalloway Alan, Trott R. James, Design Patterns Explained: A New Perspective on Object-Oriented

Design, Second Edition, Addison-Wesley Professional, 12 Pazdziernik 2004, ISBN-13: 978-0-321-

24714-8

63

64 BIBLIOGRAFIA

[16] SOLID, http://www.codemag.com/article/1001061

[17] The Principles of OOD, http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

[18] What is CRUD?, http://docs.jboss.org/tools/latest/en/seam/html/crud_database_application.html

[19] REST API Tutorial, http://www.restapitutorial.com/

[20] Jim Webber, Parastatidis Savas, Robinson Ian, REST in Practice, O’Reilly Media, Inc., 17 Wrze-

sien 2010, Print ISBN-13: 978-0-596-80582-1

[21] jQuery, https://jquery.com/

[22] XEditable, http://vitalets.github.io/x-editable/

[23] Twitter Bootstrap, http://getbootstrap.com/2.3.2/

[24] Dir-pagination, https://github.com/michaelbromley/angularUtils/tree/master/src/directives/pagination/

[25] Bootbox, http://bootboxjs.com/

[26] MomentJS, http://momentjs.com/

[27] Angular Calendar, http://angular-ui.github.io/ui-calendar/

[28] Date Time picker, https://github.com/Gillardo/bootstrap-ui-datetime-picker/

[29] Angular Google Maps, http://angular-ui.github.io/angular-google-maps/


portal konferencyjny umozliwiajacy˛ zarzadzanie˛ konferencja...

Documents