tudományos cikk kezel® rendszer back-end illetve front

Miskolci Egyetem

Informatikai Intézet

Általános Informatika Tanszék

Tudományos cikk kezel® rendszerback-end illetve front-end

megvalósításaSzakdolgozat

Készítette:

Kovács Balázs

Z4P7WO

Konzulens:

Dr. Tóth Zsolt

2018.

http://www.uni-miskolc.hu

http://www.iit.uni-miskolc.hu

http://www.iit.uni-miskolc.hu

mailto:[email protected]


Eredetiségi NyilatkozatAlulírott Kovács Balázs ; Neptun-kód:Z4P7WO a Miskolci Egyetem Gépész-

mérnöki és Informatikai Karának végz®s mérnökinformatikus szakos hallgatója

ezennel büntet®jogi és fegyelmi felel®sségem tudatában nyilatkozom és aláírásommal

igazolom, hogy Tudományos cikk kezel® rendszer back-end illetve front-end

megvalósítása cím¶ szakdolgozatom saját, önálló munkám; az abban hivatkozott

szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul ve-

szem, hogy szakdolgozat esetén plágiumnak számít:

• szószerinti idézet közlése idéz®jel és hivatkozás megjelölése nélkül;

• tartalmi idézet hivatkozás megjelölése nélkül;

• más publikált gondolatainak saját gondolatként való feltüntetése.

Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul ve-

szem, hogy plágium esetén szakdolgozatom visszautasításra kerül.

Miskolc, 2018. szeptember 13.

Kovács Balázs



Tartalomjegyzék

Eredetiség Nyilatkozat 1

1. Bevezetés 4

1.1. Célok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Motivációk, célkit¶zések . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Az alkalmazás rövid ismertetése . . . . . . . . . . . . . . . . . . . . . 5

2. Technológiák 6

2.1. Eclipse IDE - STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3. Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4. Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5. Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.7. LiquiBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.8. MyBatis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.9. JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.10. EasyMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Tervezés 10

3.1. Felhasználók és funkciók . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1. Felhasználó . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2. Szerz® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.3. Bíráló . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.4. Szerkeszt® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.5. Adminisztrátor . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Projekt felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1. Fordítás és csomagolás . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2. Parent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

TARTALOMJEGYZÉK 3

3.2.3. Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.4. Backend-service . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.5. Online-web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.6. Models modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.7. Shared modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.8. Blackbox-api modul . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.9. Blackbox-service modul . . . . . . . . . . . . . . . . . . . . . 21

3.2.10. Blackbox-dao modul . . . . . . . . . . . . . . . . . . . . . . . 21

4. Implementáció 23

4.1. Elérhet® funkciók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1. Szerz® speci�kus tevékenységek . . . . . . . . . . . . . . . . . 24

4.1.2. Szerkeszt® speci�kus tevékenységek . . . . . . . . . . . . . . . 25

4.1.3. Bíráló speci�kus tevékenységek . . . . . . . . . . . . . . . . . 26

4.1.4. Megosztott tevékenység . . . . . . . . . . . . . . . . . . . . . . 27

4.2. Kivétel kezelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1. Saját kivételek kezelése . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2. Általános kivételkezelés . . . . . . . . . . . . . . . . . . . . . . 28

4.2.3. ExceptionObjectWritter osztály . . . . . . . . . . . . . . . . . 29

4.3. HTTP kérések kezelése, illetve válaszadás . . . . . . . . . . . . . . . . 29

4.4. A két f® modul kommunikációja - HTTP Remote Invocation . . . . . 30

4.4.1. Online-web modul - HTTP Remote invocation kon�gurációja . 31

4.4.2. Backend-service modul - HTTP Remote invocation kon�guráció 32

4.5. Életciklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.1. Életciklus használata . . . . . . . . . . . . . . . . . . . . . . . 34

4.5.2. Életciklus hibakezelés . . . . . . . . . . . . . . . . . . . . . . . 35

5. Eredmények 36

5.1. Az alkalmazás m¶ködés közben . . . . . . . . . . . . . . . . . . . . . 36

6. Lehet®ségek 40

7. Összefoglalás 41

8. Summary 42

9. Köszönetnyilvánítás 43

A. CD Melléklet 45

1. fejezet

Bevezetés

1.1. Célok

Szakdolgozatom els®dleges célja a jelen IT piaci trendeknek megfelel®, Java ala-

pú webes alkalmazás elkészítése. Ennek érdekében különböz® az iparban is használt

technológiákat alkalmaztam. Ennek érdekében különböz®, az iparban is használt up-

to-date technológiákat alkalmaztam, melyeket a kés®bbiekben részleteznénk. Mind

a back-end és front-end strukturális felépítésére különös �gyelmet szenteltem, hogy

az a lehet® legátláthatóbb és továbbfejleszthet® legyen. A megvalósítások során csak

és kizárólag ingyenes szoftvereket, keretrendszereket használtam. Ezen felül fontos-

nak tartottam olyan technológiákat használni, melyek eddig számomra ismeretlenek

voltak, így b®vítve tudásomat.

A felhasználói felületnek letisztult, egyszer¶ dizájnt kell követnie, hogy a hasz-

nálata könny¶ és egyértelm¶ legyen. A tevékenységek sikerességér®l illetve sikerte-

lenségér®l minden esetben üzenetben kell tájékoztatni a felhasználókat. A személyes

adatok védelme érdekében a rendszer semilyen érzékeny adatot nem kér a felhasz-

nálóktól a regisztráció alatt, illetve utána sem. Az alkalmazás harmadik fél számára

nem adhatja tovább a regisztrált felhasználók adatait. A felhasználók csak és kizá-

rólag a saját adataikat láthatják és szerkeszthetik.

1.2. Motivációk, célkit¶zések

Az interneten megtalálható néhány, a szakdolgozatomhoz hasonló alkalmazás, mely-

b®l a magasabb színvonalúak sajnos anyagi befektetés nélkül nem érhet®ek el. Azon

potenciális célcsoportok, melyek érdekeltek a program használatában azonban nem

kívánnak �zetni érte, elkészítettem egy ingyenes altertatív megoldását, mely dolgo-

4

1. FEJEZET. BEVEZETÉS 5

zatom témájául szolgál.

Továbbá a mai társadalmi trendek arra összpontosulnak, hogy minél széleskör¶bb

tudásra tegyen szert az adott személy és minél több munkát el tudjon végezni internet

segítségével. Amennyiben az alkalmazás sikeres lenne, szélsekör¶ használat révén

min®ségi cikkek kerülnének elfogadásra. Ezért a kés®bbiekben könnyen hozzá lehetne

fejleszteni egy integrációs komponenst, ami képes kommunikálni küls®s 3rd partys,

publikálni képes alkalmazásokkal. Ezen publikálással foglalkozó alkalmazások az

általam készült programban elfogadásra került cikkek közül válogathatna, melyek

azok, amik ténylegesen publikálásra alkalmasak.

1.3. Az alkalmazás rövid ismertetése

Témám egy tudományos cikkeket kezelni képes program fejlesztése. A rendszerbe

lehet®sége van beregisztrálni bárkinek, azt követ®en válik lehet®vé az alkalmazás

használata. A kapott jogosultságok alapján kerül eldöntésre, hogy milyen menü-

pontokhoz férhet hozzá a felhasználó és milyen m¶veleteket hajthat majd végre a

cikkeken. A cikk benyújtását követ®en a szerkeszt®nek ki kell jelölnie minimum egy

bírálót, akinek véleményeznie kell azt. A cél az lenne, hogy az adott cikkhez mi-

nél több olyan bíráló f¶zzön véleményt, akik annak témájában jártasak, így adva

a legpontosabb visszajelzést a szerkeszt® számára. Amint a bírálat befejez®dött, a

szerkeszt®nek egy végs® döntést kell hoznia, mely elfogadás, elutasítás vagy módosí-

tás lehet. Az utóbbi esetén a szerz®nek el kell végeznie a módosításokat és ismételt

benyújtást követ®en a folyamat el®lr®l kezd®dik. Így a rendszernek képesnek kell

lennie arra, hogy a feltöltött cikkek státuszait kezelje és biztosítani kell, hogy csak

az arra megfelel® személyek láthassák, szerkeszthessék.

Mivel webalkalmazásról beszélünk, a felhasználó bárhonnan beadhatja a cikket.

Jelen alkalmazás nem képes publikálásra, csak a publikálhatóságának eldöntésére

hivatott, így a beadott cikkekre vonatkozóan nincs kockázat. Az elfogadott beadvá-

nyokról kapott el®zetes visszajelzések alapján a cikk kés®bbi publikálásának segítsé-

géül szolgál. Emellett a dokumentum �zikálisan nincs jelen, így egyrészt könnyebb

a megosztása, valamint több emberhez jut el (akik az adott téma szakért®i), mely

pontosabb visszajelzést ad a cikk megbízhatóságáról, érthet®ségér®l és tudományos-

ságáról.

2. fejezet

Technológiák

2.1. Eclipse IDE - STS

Az Eclipse egy integrált fejleszt®i környezet (IDE - Integrated Development Environ-

ment), amit a számítógépes programozásban használnak alkalmazások fejlesztésére.

Nyílt forráskódú, platformfüggetlen éppen ezért egyaránt használható Windows, Li-

nux és Mac rendszereken alkalmazásfejlesztésre. Szakdolgozatomban a Spring To-

ol Suite-ot használtam, ami egy Eclipse alapú fejleszt® környezet, ami kifejezetten

Spring alkalmazások fejlesztésére terveztek. [3, 8]

2.2. Java

A Java egy általános célú, platformfüggetlen, objektumorientált programozási nyelv.

Szintaxisa a C és C++ nyelvekhez hasonló, de sokkal egyszer¶bb objektummodellel

rendelkezik. A Java nyelven íródott programokat el®ször a fordító átalakítja egy úgy-

nevezett Java bájtkódra (.class). Ezt a platform független kódot futtatja a gépen lév®

Java Virtual Machine. A Java bájtkódot a JVM gépi kóddá alakítja, így lesz értel-

mezhet® a számítógép számára. A lefordított állomány bármely JVM-et futtató szá-

mítógép számára értelmezhet® és futtatható, ebb®l ered a platformfüggetlenség.[4]

2.3. Maven

Az Apache Maven egy szoftver, melyet java alapú projektek fordítására, menedzselé-

sére lehet használni. Alap ötlete az volt, hogy egyértelm¶en meg lehessen határozni,

hogy egy projekt milyen modulokból épül fel és legyen egy egyszer¶ folyamat arra,

hogy könnyen meg lehessen osztani a lefordított JAR-okat a projektek között. A

6

2. FEJEZET. TECHNOLÓGIÁK 7

Maven a POM, azaz Project Object Model fájl alapján képes menedzselni a projekt

fordítását, valamint meghatározni a függ®ségeket. A Maven-nek léteznek beépül®

moduljai számos népszer¶ IDE-hez (Eclipse, NetBeans, IntelliJ stb.), így a parancsok

futtatásához nem kell már parancssort használni.[1]

2.4. Spring

A Spring egy nyílt forráskódú keretrendszer, amely széleskör¶ megoldásokat nyújt

mind Java EE és Java SE alkalmazások fejlesztése során. Felépítése moduláris, így

elég mindig csak azokat a részeit használni amire ténylegesen szüksége van a fej-

leszt®nek, nem kell feleslegesen bevonni az összes modulját. A Spring keretrendszer

funkciói nagyjából 20 modulba szervez®dnek. Ezek a modulok Core Container, Da-

ta Access/Integration, Web, AOP, Instrumentation, Messaging és Test csoportokra

vannak felosztva. [7]

2.5. Tomcat

Az Apache Tomcat egy nyílt forráskódú implementálja a Java Servlet, JavaServer

Pages, Java Expression Language and Java WebSocket technológiákat. Webes al-

kalmazások futtatását teszi lehet®vé platformfüggetlenül. Remekül integrálódik az

Eclipse IDE fejleszt®i környezethez, ezért kézenfekv® volt a választás. Továbbá ko-

rábban is használtam már, így nem idegen számomra. [2]

2.6. MySQL

AMySQL egy többfelhasználós, többszálú, SQL-alapú relációs adatbázis-kezel® szer-

ver. Kezdetben a MySQL AB cég fejlesztette, azonban 2008-ban a Sun felvásárolta,

2010-ben pedig a Sun-t vásárolta fel az Oracle Corporation, így a MySQL napjaink-

ban az Oracle cég tulajdonát képezi. [6]

2.7. LiquiBase

A Liquibase egy nyílt forráskódú, adatbázis független plugin, mely képes arra, hogy

az adatbázis változásait kövesse, két verzió közötti eltérést meghatározza és egy del-

ta SQL-t generáljon bel®le. Kon�guráció során a Liquibasenek meg kell határozni

egy gyökér changelog fájlt, amely alapján végre tudja hajtani a benne szerepl® SQL


utasításokat. A sorrendhelyes végrehajtást a plugin biztosítja. Minden módosítást

egy egyedi changeSet xml tag-en belül kell elhelyezni, ahol meg kell adni egy id-

t és egy szerz®t. Konvenció szerint egy már korábban létrehozott és végrehajtott

changeSet-be további módosításokat nem lehet végezni. Ennek következménye az,

hogy bármilyen módosítást egy új changeSet-ben kell elhelyezni. A LiquiBase in-

tegrálható a Maven-nel, így egyedi pro�lt lehet hozzá de�niálni. A pro�lhoz goal-ok

rendelhet®k, amik a futási eredményt befolyásolják. [5]

2.8. MyBatis

A MyBatis egy keretrendszer, mely lehet®vé teszi egy egyszer¶bb módját annak,

hogy az alkalmazásunkkal adatbázis m¶veleteket hajtsunk végre. A tárolt eljárások

helyett az alkalmazásban egy mapper interfacet és az interface-hez tartozó XML fájt

kell létrehozni. Az interface-ben kell de�niálva az alkalmazás által hívható metódu-

sokat, továbbá itt kell meghatározni az XML fájlban használható paraméter neveket

is. Az XML fájlban minden metódushoz kell hogy legyen egy megfelel® de�níció a

végrehajtandó SQL utasítással. Az alkalmazás képes futás id®ben a paramétere-

ket behelyettesíteni a megfelel® helyre, majd csak ezt követ®en hajtja végre azt.

Lekérdezés során megadható, hogy az eredménynek milyen java objektummal kell

visszatérnie és a megfelel® meppelést is képes elvégezni a keretrendszer, ezzel nagy-

mértékben megkönnyítve a munkánkat. A MyBatis képes együttm¶ködni a Spring

keretrendszerrel így a kon�guráció is egyszer¶. Az együttm¶ködés eredménye, hogy

a Spring kezeli az adatbázis kapcsolatok nyitását, zárását és a tranzakció kezelést is.

2.9. JUnit

A JUnit egy tesztelést el®segít® keretrendszer java programokhoz. Kódom bonyo-

lultabb részeit tesztekkel fedtem le, ezzel biztosítva a megfelel® m¶ködést. Fordítást

során a tesztek megfutnak és jelzik, ha bármi elbukik. A bukott tesztek jelentik azt,

hogy a biznisz logika alapján megírt teszt és a futó kód összeférhetetlen állapotba

került. Ez annyit tesz, hogy a m¶ködés már nem felel meg a lefektetett feltételek-

nek többet. Egy programban mindig törekedni kell, hogy legnagyobb mennyiségben

lefedjük kódunkat tesztekkel, azonban a 100 százalékos kódlefedettség csak nagyon

speciális esetekben valósítható meg.


2.10. EasyMock

Az EasyMock szintén egy tesztelést el®segít® keretrendszer, ami képes a JUnit-tal

együttm¶ködni. Vannak esetek, amikor a programunk egy adott részét akarjuk

tesztelni úgy, hogy el®re meghatározott visszatérési értékkel akarunk dolgozni. Ergo

megszabjuk, hogy egy adott függvényhívás kötelez®en milyen objektummal kell hogy

visszatérjen anélkül, hogy azt ténylegesen meghívtuk volna. Erre szolgál segítségül

az EasyMock, ami képes arra, hogy egy egész osztályt úgymond virtuálisan kezeljen.

Tehát amikor meghívjuk azt, nem fog a kód ténylegesen megfutni, hanem az általunk

meghatározott objektummal tér vissza. Többek között azért hasznos, mert lehet úgy

alkalmazást fejleszteni, hogy a részeket egy egységként kezeljük annak ellenére, hogy

függnek egymástól az objektumok. Szakdolgozatomban az EasyMock-ot a legtöbb

esetben arra használtam, hogy a szerviz rétegben írt tesztjeimben hivatkozott dao

objektumokat mokkoljam.

3. fejezet

Tervezés

A rendszer tervezése során a következ® szempontokat tartottam szem el®tt:

• párhuzamosan egyszerre több felhasználó, konkurens módon használhassa a

webalkalmazást;

• a felhasználók minden esetben csak azokat a menüpontokat, funkciókat, cikke-

ket érhessék el, amelyhez van jogosultságuk;

• bejelentkezés nélkül csak a megfelel® funkciók legyenek elérhet®k;

• az alkalmazás GUI és Service rétege elkülönítve, két külön szerveren fusson;

• a felhasználóhoz kezeletlen kivétel ne juthasson vissza;

• hiba esetén az adatbázis módosítások ne váljanak véglegessé, így elkerülve az

adatbázis inkonzisztens állapotát.

3.1. Felhasználók és funkciók

A rendszerben meghatározott és értelmezett szerepkörök listája a következ®:

• Felhasználó;

• Szerz®;

• Bíráló;

• Szerkeszt®;

• Adminisztrátor.

10

3. FEJEZET. TERVEZÉS 11

Egészen regisztrációig minden az oldalt meglátogató személy felhasználónak te-

kinthet®. Azt a személyt, aki a regisztrációs folyamatot befejezi, egy a felhasználótól

speciálisabb szerepkörbe lehet besorolni. Emiatt egy felhasználó számára legfeljebb

négy további szerepkör osztható ki.

3.1. ábra. Felhasználói kapcsolatok

Az, hogy regisztráció után milyen további szerepköröket kapjon meg egy Felhasz-

náló, az adatbázisban lehet kon�gurálni.

3.1.1. Felhasználó

Az oldalt meglátogató személy felhasználónak tekinthet®. Általános tevékenységek

végrehajtására képes, ilyenek például a regisztráció, bejelentkezés vagy a kijelentke-

zés. Regisztrációt követ®en, ha egy személy nem kap további szerepköröket, továbbra

is felhasználó marad, azonban már képes lesz bejelentkezni és mindent elér, amihez

egy felhasználónak joga van. Mivel minden további szerepkör egy speciálisabb tí-

pusa a Felhasználónak, így minden tevékenységet örökölnek. Továbbiakban ez nem

kerül megemlítésre és a diagramokon se lesz feltüntetve. A következ® alpontokban

a felhasználóhoz köthet® általános tevékenységek részletesebb leírásait lehet megte-

kinteni.


Regisztráció

A regisztrációs menüpont az egyetlen - a bejelentkezés mellett - , amit egy regiszt-

rálatlan felhasználó képes elérni. A rendszer használatba vétele el®tt a minden fel-

használónak regisztrálnia kell magát a rendszerbe. Ezt a regisztrációs menüponton

teheti meg a megfelel® adatok megadása mellett. Néhány egyszer¶ adatot és egy

falhasználónév/jelszó párost kell megadni a sikeres regisztrációhoz. Kés®bbiekben

a rendszer a felhasználónév/jelszó helyes megadása után lesz képes azonosítani a

felhasználót.

Bejelentkezés

Regisztrációt követ®en a felhasználó a megadott felhasználónév, illetve jelszó páros-

sal képes bejelentkezni a rendszerbe. Elfelejtett jelszó visszaállítására a rendszerben

jelenleg nincs lehet®ség. Amennyiben a bejelentkezési kísérlet sikertelen, hibaüzenet

jelenik meg és a rendszer használata továbbra sem lesz engedélyezett. Sikeres beje-

lentkezést követ®en megjelenik a menüsor a kioszott jogosultságok függvényében.

Kijelentkezés

Bejelentkezést követ®en ez a menüpont mindenki számára elérhet®. Rákattintva a

jelenlegi munkamenet megsz¶nik. A rendszer a bejelentkezési képerny®re navigálja

a felhasználót.

Személyes adatok módosítása, jelszó csere

Bejelentkezést követ®en ez a menüpont is elérhet® mindenki számára. Ebben a

menüpontban van lehet®ség a regisztráció során megadott személyes adatok módo-

sítására, illetve itt lehet megváltoztatni a jelszót is. Jelszóváltást követ®en a rendszer

csak és kizárólag az új jelszóval fogja beengedni a felhasználót.

3.1.2. Szerz®

Szerz®nek az a felhasználó tekinthet®, aki képes publikálásra beküldeni egy tudomá-

nyos cikket. Tudományos cikk feltöltésére és beküldésére csak és kizárólag a szerz®

szerepkörrel rendelkez® felhasználó képes.

Használható funckiók

• Feltöltés - Egy cikk életciklusát tekintve számos állomást érint, amelyek közül

az els® ilyen a feltöltés. Szerz®ként korlátlan számú cikk feltöltése lehetséges.


3.2. ábra. Általános Felhasználói tevékenységek

Sikeres fájlfeltöltést követ®en további m¶veleteket válnak lehet®vé, melyek a

törlés, megtekintés, szerkesztés, letöltés, mentés illetve véglegesítés.

• Törlés - A cikk bármely állapotában elérhet®. Eltávolítani egy feltöltött cik-

ket egyedül csak a tulajdonosa tud. Törlést követ®en további m¶veletek nem

végezhet®k az adott cikken egyik szerepkörben lév® személy számára sem, illet-

ve a listán sem lesz tovább látható. Háttérrendszeri megvalósítás tekintetében

tényleges törlés nem történik. A fájl illetve az eddig mentett adatok megma-

radnak.

• Megtekintés - A cikk bármely állapotában elérhet® funkció, mely átfogó ké-

pet szolgáltat a megtekint® számára.

• Letöltés - A feltöltött cikk mindig tárolásra kerül a szerver fájlrendszerén,

ezért bármikor lehet®ség van azt letölteni.

• Mentés - Mentés során az addigi összes módosítás a cikken perzisztens módon

tárolásra kerül. Amennyiben mentés vagy véglegesítés nélkül zárul a szerkesz-

tés, minden addig módosított adat elvész.

• Véglegesítés - Ahhoz, hogy bírálatra kerülhessen sor, a feltöltött cikket vég-

legesíteni kell. Amennyiben a cikk nem felel meg a formai követelményeknek,

vagy hibás a form, a rendszer elutasítja a véglegesítést. Sikeres benyújtást

követ®en tovább szerkeszteni nem lehet.


Szerkesztés során társszerz®ket lehet hozzárendelni a cikkhez. A megjelölt társ-

szerz®k kizárólag megtekinteni és letölteni tudják a cikket.

3.3. ábra. Szerz®i tevékenységek

3.1.3. Bíráló

Bírálónak tekintjük azt a Felhasználót, akit a Szerkeszt® felkér egy cikk felülvizs-

gálatára. A legtöbb esetben a Bírálót a cikk témájától függ®en kérik fel, hogy egy

hozzá ért® személy véleményezhesse azt. Ezért nagyon fontos a rendszerben, hogy

mindenki aki beregisztrál a lehet® legpontosabban kitöltse, hogy mi a szakterülete

ezzel biztosítva, hogy a Szerkeszt® a megfelel® embereket kérjen fel a bírálatra.

Bírálati feltételek

• A Bíráló saját cikkeit nem bírálhatja;

• A Bíráló amennyiben meg van jelölve egy cikkben mint társszerz®, azt ugyan-

csak nem bírálhatja;

• Felkérést követ®en 7 nap áll rendelkezésre, hogy a Bíráló elfogadja, vagy eluta-

sítsa azt. Amennyiben a 7 nap letelt, a felkérés automatikusan visszautasításra

kerül.


Használható funkciók

• Megtekintés - Ha egy Bírálót felkérnek, lehet®sége van még elfogadás el®tt

megtekintenie a cikket. Itt olvashat róla több információt és hozhatja meg a

döntését azok alapján.

• Letöltés - A Bíráló letöltheti azokat a cikkeket, amikre felkérik bírálatra.

• Visszautasítás - Amennyiben a Bíráló visszautasítja a felkérést, további m¶-

veleteket nem végezhet azon és nem szabad, hogy megjelenjen neki. Amennyi-

ben az összes Bíráló visszautasítja a felkérést a Szerkeszt®nek újabb Bírálókat

kell kijelölnie.

• Elfogadás - Ha a felkérés elfogadásra kerül, a Bírálónak lehet®sége nyílik

véleményeznie azt, de csak akkor, ha már minden felkért Bíráló meghozta

a döntését. Egy cikk abban az esetben bírálható, ha legalább egy felkérés

elfogadásra kerül.

• Vélemény írás - Csak akkor érhet® el ez a funkció, ha a felkérés elfogadásra

került.

A következ® ER diagramon a Bírálóhoz tartozó tevékenységi körök láthatók:

3.4. ábra. Bírálói tevékenységek


3.1.4. Szerkeszt®

A rendszerben a Szerkeszt®k az egyedüli Felhasználók, akik láthatják az összes be-

nyújtott tudományos cikket. A Szerkeszt® feladata az, hogy megfelel® Bírálókat

bízzon meg a cikk véleményezésére és ezen vélemények alapján meghozza a végs®

döntést.

Szerkeszt®i feltételek

• A Szerkeszt® saját cikkeit nem rendelheti magához;

• A Szerkeszt® amennyiben meg van jelölve egy cikkben mint társszerz®, azt

ugyancsak nem rendelheti magához;

• Más Szerkeszt® által már kezelt cikket egy másik Szerkeszt® már nem vehet

magára és nem is végezhet rajta tevékenységeket;

A következ® ER diagramon látható, hogy milyen tevékenységek végrehajtására

képes a Szerkeszt®:

3.5. ábra. Szerkeszt®i tevékenységek

Használható funkciók

• Megtekintés - Átfogó képet szolgáltat a megtekint® számára az adott cikkr®l.


• Letöltés - A Szerkeszt® képes letölteni azon cikkeket, amiket magára vett.

• Bírálóhoz rendelés - Mivel egy cikket legalább egy Bírálónak véleményeznie

kell a rendszerben, ezért a Szerkeszt® képes arra, hogy a rendszer Bírálói közül

kiválassza a megfelel®eket és bírálatra kérje fel ®ket. Mindaddig, amíg a cikk

bírálat alatt van, csak a megtekintés funkció érhet® el. Egy cikket többször is

be lehet adni bírálatra abban az esetben, ha minden Bíráló visszautasította a

felkérést. Amennyiben legalább egy bírálat érkezik a cikkre, a Végs® Döntés

lehet®ség elérhet®vé válik a Szerkeszt®nek.

• Végs® döntés - A Bírálók felülvizsgálata után válik elérhet®vé ez a funkció.

A Szerkeszt®nek a beküldött bírálatok alapján egy végs® döntést kell hoznia,

amik a következ®k lehetnek:

� Végleges visszautasítás - A cikk nem felelt meg a követelményeknek és

publikálásra alkalmatlan. Ezt követ®en senki nem végezhet rajta további

m¶veleteket.

� Elfogadás - A cikk megfelelt a követelményeknek. Publikálható a közön-

ségnek. Amennyiben elfogadásra kerül a sor senki nem végezhet további

módosításokat a cikken.

� Javítás szükséges - További javítást kell végezni a cikken. Ekkor a

Szerz®nek lehet®sége adódik feltölteni a cikk egy újabb javított verzióját.

A visszautasított illetve elfogadott cikkek esetén már csak megtekintés lehetséges

a Felhasználók számára, mivel a cikk elérte végleges státuszát.

3.1.5. Adminisztrátor

Az Adminisztrátori szerepkör implementálása nem része a Szakdolgozatomnak, azon-

ban tervezés során felmerült, hogy kés®bbiekben szükség lehet egy ilyen jogosultságra

is.


3.2. Projekt felépítése

Szakdolgozatom tervezése során egyik f® cél az volt, hogy a gui illetve a service

réteg két külön szerveren futhasson. Els®sorban azért gondoltam, hogy fontos így

megvalósítani, mert így a controller és a service réteg er®sen elszeparálódik, valamint

a terhelés nem egyetlen szerverre öszpontosul. Ezen elgondolás alapján a projektem

felépítése a következ® ábrán látható:

3.6. ábra. Projekt felépítés

A modulokból kiinduló szaggatotott vonal azt jelzi, hogy a két modul között füg-

g®ség áll fent. Ebben az esetben ahonnan kiindul a nyíl, az függ®ségként tartalmazza

azt a modult, amire éppen mutat.

Mivel az alkalmazásom nem nagy, semmi nem indokolta, hogy funkciónként külön

hozzak létre modul-struktúrákat. Teljesen elkülöníthet®, átlátható java package-k

használatával is. Továbbá a blackbox modul tartalmazza az alkalmazás alapvet®

funkcióit, amik szükségesek a m¶ködéshez. A jelenlegi modulfelépítés miatt bárki

könnyedén hozzá tud fejleszteni további funkciókat anélkül, hogy a blackbox modu-

lokat módosítaná.

3.2.1. Fordítás és csomagolás

A projektet például le lehet fordítani konzolból az �mvn clean package� paranccsal,

de célszer¶bb az IDE-b®l megcsinálni ugyan ezt, ha van rá lehet®ség. A 4.1 képen


mindegyik modul meg van jelölve, hogy fordítást követ®en a Maven milyen csomago-

lású állományt fog készíteni bel®le. Sikeres fordítást követ®en a projekt könyvtárban

létrejött target mappában található a generált csomag, ami lehet jar, war, pom, ejb,

ear stb. Projektemben csak jar, war és pom csomagolású modulok fordulnak el®.

Általánosságban a pom csomagolású modul arra szolgál, hogy szül® modulja

legyen egy vagy több almodulnak, illetve összefogjon több almodult. B®vebb leírást

a pom csomagolású modulokról a 3.2.2 és 3.2.3 pontokban olvashat.

3.2.2. Parent

A Parent modul a szül® modulja az összes almodulnak és Bundle f®modulnak is.

Ez a modul felel®s a központi verzió kezelésért, tehát minden küls®s függ®ség ide

van bekötve. Ez azért hasznos, mert így csak egy helyen kell felügyelni a verzió-

kat és elkerüljük a verzió különböz®ségb®l adódó inkonzisztens állapotokat. Ennek

a modulnak is van még szül®je, mégpedig a spring boot keretrendszer által nyúj-

tott spring-boot-starter-parent. Ebb®l a parentb®l további hasznos kon�gurációs

elemeket illetve küls®s függ®ségeket örököl az alkalmazás.

Az összes függ®ség egy úgynevezett dependencyManagement xml tag között he-

lyezkedik el. Ez azért kell, hogy az almodulok közvetlenül ne érhessék el a füg-

g®ségeket. Ebb®l következik, hogy az éppen szükséges küls®s függ®ségeket minden

almodulban közvetlenül meg kell jelölni, verzió nélkül. Ezt követ®en válik csak hasz-

nálhatóvá.

3.2.3. Bundle

A bundle modul az alkalmazásom f® modulja és ez fogja össze a backend-service és

online-web modulokat. Részletesebb leírást a 3.2.4 és a 3.2.5 olvashat. A bundle

szintén egy pom csomagolású modul. Az alkalmazásban létrehozott modulok verziói

ide vannak bekötve, szintén dependencyManagement xml tag közé helyezve.

A Bundle két modulját kell a web szerverekre kitelepíteni és így fog m¶ködni az

alkalmazás.

3.2.4. Backend-service

A Backend-service egy war csomagolású modul. Ez a modul felel®s a háttér rendszeri

megvalósításokért, amik

• adatbázis felépítése - adatbázis szkriptek sorrendhelyes végrehajtása;


• adatbázis session kezelés;

• kiszolgálja a Online-web modultól érkez® kéréseket;

• háttérrendszeri kon�gurációk, többet között Cache, Adatbázis kapcsolat, JMS.

Ezen a szinten már nincs session kezelés illetve biztonsági megszorítás, mivel ezeket

már az Online-web modul elvégezte korábban. Ez azt jelenti, hogy a háttérrendszerre

csak megfelel® kérések juthatnak el.

Az alkalmazás automatikusan megkeresi a spring által nyújtott annotációkkal

ellátott osztályokat és automatikusan Bean-t csinál bel®lük.

3.2.5. Online-web

Az Online-web modul egy war csomagolású modul. Ez a modul számtalan dolgot

lát el, többek között

• session kezelés;

• biztonsági megszorítások;

• statikus tartalmak kiszolgálása;

• kivétel kezelés;

• HTTP kérések kiszolgálása;

• Dispatcher servlet de�níció;

• �lterek de�níciója;

• kommunikáció a backend-service modullal (HTTP Remote Invocation).

Valamennyi pontról részletesebb leírást lehet találni az implementációs részben.

3.2.6. Models modul

Ez a modul tartalmazza az alkalmazásban használt összes Plain Old Java Object (to-

vábbiakban POJO) osztályokat. Ezek létrehozásához a JAXB2 plugint használtam,

ami képes XML Schema De�nition-ben (továbbiakban XSD) de�niált típusokból

egyszer¶ Java objektumokat generálni. Többek között arra is képes ez a plugin,

hogy az XSD-ben meghatározott megszorításokat átalakítsa a Java Validation-ben

elérhet® annotációkra. Innent®l kezdve Controller szinten ki lehet er®ltetni a kérések


vizsgálatát, így biztosítva, hogy csak a megfelel® kérések juthassanak be az alkal-

mazásba. Az osztályok generálása automatikusan megtörténik az XSD mentését

követ®en és ha bármi hiba van, azt a fordító egyb®l jelzi.

Az egyszer¶ POJO osztályok mellett itt vannak de�niálva az alkalmazásban dob-

ható egyedi kivételek is.

3.2.7. Shared modul

A Shared modul tartalmaz minden olyan statikus osztályt, megvalósítást, amit az

alkalmazásban bárhol fel lehet használni. Egy kicsit félrevezet® a neve a modulnak,

talán jobban illene rá a Util elnevezés, de ez csak kés®bb merült fel.

3.2.8. Blackbox-api modul

A Blackbox-api modul tartalmazza az összes interfészt, ami az alkalmazás alap m¶-

ködéséhez kell. Kevert modul, mivel nincsenek elszeparálva a service illetve dao

interfacek. Ezt a modult mind a service és dao modulok tartalmazzák mint függ®-

ség, így képesek a megfelel® interfészek megvalósítására. Továbbá ezeken a publikus

interfészeken keresztül képesek kommunikálni egymással.

3.2.9. Blackbox-service modul

A Blackbox-service modulban kaptak helyet a service interfészek megvalósításai.

Minden service osztály meg van jelölven egy @Service annotációval. Ez jelzi a Spring

keretrendszernek, hogy ez egy service osztály és létre kell bel®le hoznia egy Bean-

t. Tervezés során úgy döntöttem, hogy ebben a rétegben kell megjelölni azokat a

metódusokat, amikhez adatbázis tranzakció kezelést kívánunk alkalmazni. Ehhez a

@Transactional annotációt kell használni. Az üzleti logika megvalósítása csak itt

engedélyezett.

3.2.10. Blackbox-dao modul

A Blackbox-dao modul a felhasználói interakcióktól legmesszebb álló komponens.

Az összes kérés a következ® lépéseken megy keresztül, miel®tt adatbázis m¶veletek

hajtódnának végre:

• HTTP kérés ellen®rzése;

• Jogosultság ellen®rzése;


• Service réteg hívása;

• Dao réteg hívása;

• Adatbázis m¶velet végrehajtása.

Itt vannak megvalósítva a dao interfészek. Minden dao osztály meg van jelölve

egy @Repository annotációval. Ez hasonlóan m¶ködik, mint a service rétegnél hasz-

nált @Service annotáció, jelzi a Spring keretrendszernek, hogy ez egy dao osztály

és létre kell bel®le hozni egy Bean-t. Ezek az osztályok már nem tartalmazhatnak

üzleti logikát, egyszer¶en csak tovább hívnak a mapper interfészekhez. Adatbázis

m¶veletekhez a MyBatis keretrendszert használtam, ami képes együtt m¶ködni a

Spring keretrendszerrel. Az adatbázis kapcsolatok nyitását, zárását, tranzakció ke-

zelését a keretrendszer elvégzi, ezzel csökkentve az implementálandó kódot és a hibák

lehet®ségét.

A MyBatis keretrendszer úgy m¶ködik, hogy de�niálni kell egy java interfészt,

ami tartalmazza a hívható metódusokat, valamint egy mapper.xml-fájlt, ami meg-

jelöli a java interfészt és tartalmazza a metódus neveket és a hozzájuk tartozó SQL

utasításokat. A keretrendszer futási id®ben képes a függvény paraméterében át-

adott adatokat mappelni és behelyettesíteni az SQL utasításba, majd az eredmény

halmazt képes visszaalakítani Java objektummá. Ennek megfelel®en a Blackbox-dao

modulban foglalnak helyet a mapper interfészek és a mapper.xml fájlok is.

4. fejezet

Implementáció

4.1. Elérhet® funkciók

Az alkalmazásban jelenlegi állapotában 4 f® menü érthet® el a felhasználók számára.

Ezek rendre

• Author menü- Szerz® menü

• Reviewer menü - Bíráló menü

• Editor menü - Szerkeszt® menü

• Personal settings menü - Személyes adatok menü

Mint korábban említettem a funkciók elérése csak a megfelel® jogosultságok meg-

létével lehetséges, így csak azok a menüpontok jelennek meg a felhasználónak, amihez

joga van. Mondhatni ez az els® biztonsági pont az alkalmazásban. A következ® ilyen

biztonsági vizsgálat a kontroller rétegben van elhelyezve, ugyanis minden kérést, ami

a felületr®l érkezik ellen®riz a rendszer, mégpedig úgy, hogy megnézi van-e jogosult-

sága az adott funkcióhoz a kérést kezdeményez® személynek. Amennyiben nincs, a

kérés nem hajtódik végre és a bejelentkezés képerny®re navigálja át a felhasználót a

rendszer.

Implementáció során egyik legnagyobb kihívást az jelentette, hogy az eltér® sze-

repkörökben lév® személyek éppen milyen tevékenységeket végezhetnek a cikk ak-

tuális státuszától függ®en. Az életciklus el®rehaladtával egyre több személy kap

jogosultságot egy adott cikkhez és mindig ellen®rizni kell, hogy státusztól függ®en

az adott személyen van-e a sor, hogy módosítsa és egyáltalán van-e jogosultsága hoz-

zá. A lenti menüpontokban részletesen taglalom az egyes jogosultságokhoz tartozó

menüponton elérhet® funkciókat valamint azok hatásait az adott cikkre.

23

4. FEJEZET. IMPLEMENTÁCIÓ 24

4.1.1. Szerz® speci�kus tevékenységek

• Feltöltés: Egy cikk feltöltéséhez egyedül csak a Szerz®nek van jogosultsá-

ga. A feltöltés tevékenység magába foglalja a kezdeti státusz beállítását, a

fájl perzisztens tárolását a fájlrendszeren, az alap adatok adatbázisban való

letárolását és a cikk feldolgozását. A cikk feldolgozása nem része a szakdolgo-

zatomnak. Ezt egy küls®s alkalmazás végzi el, melyet Pintér Tamás csinált.

Ennek részletes leírását az általa készített Szakdolgozatban lehet megtekinte-

ni. Feltöltést követ®en a cikk státusza Started lesz és megjelenik a Szerz®nek

további tevékenységek céljából. A fájl feltöltés végeredményér®l a felhasználó

tájékoztatás kap egy felugró ablakban.

4.1. ábra. Feltöltés folyamat szekvencia diagramja

• Törlés: Egy cikk törléséhez egyedül csak a Szerz®nek van jogosultsága azon-

ban nem minden státuszban engedélyezett. Cikket mindaddig lehet törölni,

ameddig nem kerül a végleges státuszok egyikébe. Törlést követ®en további

tevékenységek nem engedélyezettek a cikken. A törlés funkció jelenleg nem

törli a fájlt a fájlrendszerr®l és nem töröl semmit az adatbázisból. Egy jelz®

frissül be, ami meghatározza, hogy törölt cikkr®l van-e szó.

• Szerkesztés: A szerkesztés funkció addig érhet® el, amíg a cikk státusza Star-

ted. Szerkesztésnél lehet®ség van címet, kulcsszavakat, absztraktot megadni,

valamint társzerz®ket megjelölni. Mivel szerkesztés csak Started állapotban


lehetséges, így beadást követ®en további módosítások nem végezhet®k a cik-

ken.

� Társzerz® megjelölése: Ha egy társszerz®t hozzárendelünk a cikkhez,

az megjelenik a partnernél is, azonban csak megtekinteni tudja szerkesz-

teni nem.

� Mentés: Mentés során a cikken végzett módosítások mentésre kerülnek

az adatbázisban, azonban státuszváltás nem fog történni.

� Benyújtás: Beadást követ®en a cikk módosításai szintén ment®dnek, de

státusz váltás is történik. A cikk új státusza Submitted lesz.

• Új verzió feltöltése: Ez a funkció csak akkor válik elérhet®vé a Szerz® számá-

ra, miután egyszer körbeért az életciklus. Az Szerkeszt® nem utasította vissza

véglegesen, de nem is fogadta még el. További módosításokra visszadobta azt a

Szerz® számára. Ekkor az írt értékelés alapján a Szerz®nek módosítania kell a

cikket és feltölti az új verzióját. Ezek után a letöltés funkcióban az új verziójú

cikk tölt®dik le mindenki számára. Új verzió feltöltése során státuszváltás is

történik, melyben az új státusz Assign to reviewer lesz, ami annyit jelent,

hogy a Szerkeszt®nek ismét választania kell bírálókat, akik véleményezik a cikk

új verzióját.

4.1.2. Szerkeszt® speci�kus tevékenységek

• Cikk keresés és menedzselés: A szerkeszt® képes a publikálásra benyújtott

cikkek között keresgélni, akár bizonyos feltételek alapján is. Ezen a listán csak

azon cikkek szerepelnek, melyek Submitted állapotúak és nem az adott Szer-

keszt® által lettek feltöltve. Ekkor megtekintheti az alap adatokat a cikkr®l és

magához rendelheti további menedzselés céljából. Ebben az esetben státusz-

váltás történik és az új státusza a cikknek Assign to reviewer lesz. Innent®l

kezdve más Szerkeszt®k már nem férnek hozzá a cikkhez.

• Bírálóhoz rendelés: Amint a Szerkeszt® magához rendelt egy cikket, lehet®-

sége adódik bírálatra benyújtani azt. Ez a lehet®ség mindaddig elérhet® amed-

dig a cikk státusza Assign to reviewer. Bírálatra felkérni egy felhasználót

akkor és csak akkor lehet, ha Bíráló jogosultsággal rendelkezik. Amennyiben

legalább egy Bírálót felkérnek a felülvizsgálatra a cikkWaiting for reviewer

státuszba kerül mindaddig, amíg a felkérést legalább egy Bíráló el nem fogadja,

vagy mindenki vissza nem utasítja azt.


• Végs® döntés: Amennyiben sikeresen meghozták a bírálatot a Bírák, a Szer-

keszt®nek egy végs® döntést kell hoznia. A következ® három lehet®ség áll

rendelkezésére:

� Elfogadja, amikor is véglegesen elfogadja a cikket. Ezután további m¶-

velet nem végezhet® a cikken. Ekkor az új státusza a cikknek Accepted

lesz.

� Visszautasítja, amikor is véglegesen visszautasítja a cikket. Ezután szin-

tén nem engedélyezettek a további m¶veletek. A cikk státusza Rejected

lesz.

� További módosításra visszadobja, amikor is korrekcióra visszaküldi a Szer-

z® számára. A cikk Need precision státuszba kerül.

Need precision döntés során az életciklus elölr®l kezd®dik és ekkor válik elér-

het®vé a Szerz®nek az Új verzió feltöltése funkció is.

4.2. ábra. Végs® döntés szekvencia diagramja

4.1.3. Bíráló speci�kus tevékenységek

Bíráló jogosultsággal rendelkez® személyeket lehet felkérni, hogy bíráljanak egy adott

cikket.

• Felkérés elfogadása: Egy felkérést lehet®sége van elfogadnia a Bírálónak.

Amennyiben ezt az opciót választja, a rendszer megvizsgálja, hogy van-e még

függ® felkérés az adott cikkhez. Ha már nincs, Under preview státuszba


változik a cikk. Bírálat írása csak ebben a státuszban engedélyezett. Ha van

még függ® felkérés, a rendszer felismeri azt és nem történik meg a státusz

váltás.

• Felkérés elutasítása: A felkérés visszautasítása során a rendszer megvizsgál-

ja van-e még függ® felkérés. Abban az esetben ha már nincs, és egyik Bíráló

se fogadta el azt, státusz váltás történik és vissza kerül a cikk a Szerkeszt®-

re. Ekkor a státusz Assign to reviewer lesz újból. Ekkor a Szerkeszt®nek

keresnie kell új Bírálókat.

• Bírálat: Amennyiben a felkérés elfogadásra került a Bírálónak további teen-

d®je van. Egy bírálati formot kell kitöltenie és véleményeznie kell a cikket. Ha

ez megvan és az adott cikkhez hozzárendelt összes Bíráló meghozta a döntését,

ismételten egy státusz váltás következik és a cikk a Szerkeszt®re kerül. Ekkor

az új státusz Under verdict lesz. Ezt követ®en a Szerkeszt® meghozhatja

végs® döntését.

4.3. ábra. Bírálat szekvencia diagramja

4.1.4. Megosztott tevékenység

Cikk megtekintés: A cikk mindegyik státuszában elérhet® funkció. Ennél a funk-

ciónál nyílik lehet®ség arra, hogy egy átfogó képet kapjon a felhasználó a cikkr®l.

Szerkesztési lehet®ség itt nem elérhet®, csak olvasás lehetséges. Ezen belül a funk-

ción belül kapott helyet a letöltés gomb. Megnyomásával letöltésre kerül az utolsó

verziója a feltöltött cikknek.


4.2. Kivétel kezelés

A kivétel kezelés egy kényes része az alkalmazásoknak. Lehet egyedi kivételeket de-

�niálni illetve használhatunk már létez®ket. Egy a lényeg, hogy kezeletlen kivétel

ne juthasson vissza a felhasználói felületre, mert biztonsági rést jelenthet, illetve

rontja a felhasználói élményt, ha egy hosszú hibaüzenetet jelenítünk meg egy egy-

szer¶, érthet® üzenet helyett. Ezen elgondolásom alapján úgy döntöttem két részre

szeparálom a kivételeket:

• általános kivétel kezelés;

• illetve általam de�niált kivételek kezelése.

4.2.1. Saját kivételek kezelése

A saját kivételek lekezelése azért egyszer¶bb és barátságosabb, mert ezekre számí-

tunk. A Spring keretrendszer által nyújtott @ControllerAdvice annotációt használ-

tam arra, hogy megjelöljem a kivétel kezel® osztályaimat. Ezekben az osztályokban

de�niáltam azokat a metódusokat, amik kezelik a kivételeket. Minden kivétel típus-

ra egyedi metódust kell de�niálni úgy, hogy az @ExcetpionHandler(ExepctionType)

annotációban meghatározzuk a kezelend® kivétel típusát. A rendszer így lesz képes

eldönteni futás id®ben, hogy egy adott kivételnél éppen melyik kezel®t kell meghív-

nia.

1 @ExceptionHandler(FileUploadException.class)

2 @ResponseBody

3 private BaseReply nameAlreadyReservedException(FileUploadException

exception) {

4 return ExceptionObjectWritter.writter(exception);

5 }

4.1. Listing. Saját kivételt kezel® metódus

4.2.2. Általános kivételkezelés

Arra hivatott, hogy az általános kivételeket egy általános hibaüzenetre átalakítsa.

Ezek általában olyan kivételek, amikre nem lehet felkészülni, vagy valamilyen hibás

futás eredményei. Ezt úgy csináltam meg, hogy létrehoztam egy ExceptionHand-

lerFilter nevezet¶ �ltert, ami try...catch ágak között kezeli a kérést. Amennyiben


egy hiba idáig eljutna ez lekezeli. A HTTP kérés kódja 500-as lesz, ami egy inter-

nal server errort jelent és megjelenik egy teljesen általános hibaüzenet a felhasználó

számára.

1 public class ExceptionHandlerFilter extends OncePerRequestFilter {

2 private static Logger LOGGER = LoggerFactory.getLogger(

ExceptionHandlerFilter.class);

3

4 @Override

5 public void doFilterInternal(HttpServletRequest request ,

HttpServletResponse response , FilterChain filterChain)

6 throws ServletException , IOException {

7

8 try {

9 filterChain.doFilter(request , response);

10 } catch (Exception e) {

11 LOGGER.error("Unhandled exception: ", e);

12

13 BaseReply reply = ExceptionObjectWritter.writter("Unexpected

server error occurred.");

14

15 response.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());

16 response.getWriter ().write(GsonWritter.write(reply));

17 }

18 }

19 }

4.2. Listing. Általános kivételt kezel® �lter

4.2.3. ExceptionObjectWritter osztály

Ez az osztály statikus metódusokat tartalmaz. Ezek a metódusok annyit csinálnak,

hogy átalakítják a paraméterben átadott kivétel objektumot egy általános válaszra,

amit a felhasználói felület könnyen tud értelmezni.

4.3. HTTP kérések kezelése, illetve válaszadás

Webes alkalmazásoknál a felhasználó kéréseket küld a szerver felé. Azért, hogy ne

lehessen bármit beküldeni, meg kell határozni, hogy milyen url kérésekre, milyen

paramétereket fogad el a rendszer. Tehát webes alkalmazásoknál van egy URL gy¶j-

temény, amikre a rendszer �gyel és ha kérés érkezik valamelyikre, kezeli azt. Minden

egyéb kérés elutasításra kerül. A spring keretrendszer-ben egy ilyen HTTP kéréseket

kezelni képes osztályt Controller osztályoknak nevezünk és @RestController anno-

tációval láttam el ®ket. Ez az annotáció jelzi a keretrendszernek, hogy a megjelölt


osztály egy controller.

1 @RequestMapping("/submission/remove")

2 public RemoveSubmissionResponse removeSubmission(@RequestBody

@Valid RemoveSubmissionRequest request) {

3 RemoveSubmissionResponse removeSubmissionResponse = authorService

.removeSubmission(request);

4 removeSubmissionResponse.setSuccess(true);

5 removeSubmissionResponse.getMessages ().add(MessageWritter.

writeHTML(

6 "You have successfully removed your submission with ID <b>" +

request.getSubmissionId () + " </b>"));

7 return removeSubmissionResponse;

8 }

4.3. Listing. Kérést kezel® metódus

Ezen osztályokban minden metódus egy @RequestMapping(paraméter) annotá-

cióval van megjelölve, ami azt jelenti, hogy az a metódus az annotáció paraméterben

megadott url kérést fogja kiszolgálni. A controller osztályok nem túl sok mindent

csinálnak, üzleti logikát nem tartalmazhatnak. Hívást kezdeményeznek a service

rétegbe és ha sikeres választ kapnak, továbbítják azt a felhasználó felé.

4.4. A két f® modul kommunikációja - HTTP Remote

Invocation

Mint azt említettem a tervezésnél, a service illetve a GUI rétegem szerver szinten

is elkülönül. Ezeknek kommunikálniuk kell egymással valamilyen úton-módon. Eh-

hez egy úgynevezett HTTP Remote Invocation használtam. Ennek kon�gurációja

gyakorlatilag annyiból áll, hogy a hívó oldalon de�niálni kell azokat az interfészeket,

amiket lehet hívni és ahhoz egy service URL-t. A fogadó oldalon pedig kon�gurálni

kellett azt, ami képes a paraméterben átadott invocation objektumból kiszedni a

service osztályt és metódust. Amennyiben a rendszer talál hozzá bean de�níciót a

hívás sikeresen végrehajtódik, egyéb esetben kivétel dobódik és a hívás sikertelenül

zárul.

Ahhoz, hogy ez m¶ködhessen de�niálni kellett egy RemoteInvocation osztályt,

ami tárolja a hívási objektumot méghozzá thread safe módon. Ez annyit jelent,

hogy minden híváshoz egyedi szál jön létre és addig foglalja azt, ameddig a válasz

nem ér véget. Ezek maximális számát a web szerverben lehet kon�gurálni. Ez az

osztály felel®s azért, hogy a service rétegben látható legyen az adott session valamint


a service réteghez tartozó spring security contextet is itt építettem fel. Pongyolán

megfogalmazva a RemoteInvocation osztályt adja át az egyik szerver a másiknak.

Erre azért volt szükség, mert a session és a security context csak az Online-web

modulban létezik, a service nem tud róluk, azonban én használni akartam ®ket.

Ezek minden hívás során felépülnek és a hívás végeztével megsz¶nnek létezni. A

hívás kezel® metódusa a következ® kódrészleten látható.

1 @Override

2 public Object invoke(Object targetObject)

3 throws NoSuchMethodException , IllegalAccessException ,

InvocationTargetException {

4

5 MDC.put("session", sessionId);

6 LOGGER.trace("Current Security Context in the thread {}",

SecurityContextHolder.getContext ());

7

8 SecurityContextHolder.setContext(context);

9

10 try {

11 Object remoteInvocationReturn = super.invoke(targetObject);

12

13 if (LOGGER.isDebugEnabled ()) {

14 LOGGER.debug("Invocation result --> {}", GsonWritter.write(

remoteInvocationReturn));

15 }

16 return remoteInvocationReturn;

17 } finally {

18 MDC.remove("session");

19 SecurityContextHolder.setContext(new SecurityContextImpl ());

20 }

21 }

4.4. Listing. Remote Invocation hívást lekezel® metódusa

4.4.1. Online-web modul - HTTP Remote invocation kon�gu-

rációja

A RemoteInvocationCon�g nevezet¶ osztályban de�niáltam a hívható service in-

terfészeket és a remote service URL-t. Ezek a bean de�níciók egyenként egy Http

Invoker Proxy Factory Bean-nel térnek vissza, ami tartalmazza a service URL-t, a

service interfészt és a Remote Invocation Factory-t. Az alábbi kódrészletben egy

service de�níció és a Http Invoker Proxy Factory Bean-t létrehozó metódus látható.


1 @Bean

2 public HttpInvokerProxyFactoryBean customUserDetailsServiceInvoker

() {

3 return getHttpInvokerProxyFactoryBean(CustomUserDetailsService.

class);

4 }

5

6 private HttpInvokerProxyFactoryBean getHttpInvokerProxyFactoryBean(

Class serviceInterface) {

7 HttpInvokerProxyFactoryBean invoker = new

HttpInvokerProxyFactoryBean ();

8 invoker.setServiceUrl(REMOTE_URL);

9 invoker.setServiceInterface(serviceInterface);

10 invoker.setRemoteInvocationFactory(getRemoteInvocationFactory ());

11 return invoker;

12 }

4.5. Listing. Remote Invocation service kon�guráció

4.4.2. Backend-service modul - HTTP Remote invocation kon-

�guráció

A service rétegben de�niálni kellett egy Bean-t ami meghatározta, hogy milyen

speciális service URL-re kell küldeni a kérést. Továbbá itt kellett de�niálni a Remo-

teInvocationExecutort, ami megvizsgálja, hogy az invocation objektumban küldött

interfészhez tartozik-e implementáció. Amennyiben igen, végrehajtja a kérést, egyéb

esetben kivétel dobódik. A következ® képen az Bean de�níció látható, ami megha-

tározza a service URL-t.

1 @Bean("/remoting")

2 HttpInvokerServiceExporter accountService () {

3 HttpInvokerServiceExporter exporter = new

HttpInvokerServiceExporter ();

4 exporter.setService(new DummyInterfaceImpl ());

5 exporter.setServiceInterface(DummyInterface.class);

6 exporter.setRemoteInvocationExecutor(new

CustomRemoteInvocationExecutor ());

7 return exporter;

8 }

4.6. Listing. Remote Invocation hívást lekezel® metódusa


4.5. Életciklus

Egy cikk a benyújtástól a kiadásig számtalan státuszon megy keresztül. Ezeket a

státuszváltásokat nevezzük a cikk életciklusának. Kód szinten egy map-ben van

meghatározva, hogy egy konkrét státuszból milyen státuszváltások engedélyezettek.

A map kulcs értéke jelöli a konkrét státuszt, a kulcshoz tatozó érték pedig egy lista,

ami azokat a státuszokat tartalmazza, amibe engedélyezett a státuszváltás. Minden

státusz váltást megel®z egy ellen®rzés, amiben a rendszer megvizsgálja, hogy az adott

státuszból lehet-e váltani a kért státuszba. Ha nem lehetséges kivételes esemény

keletkezik. A következ® képen az engedélyezett státuszváltásokat de�niáló map egy

részlete látszik:

1 private static final Map <SubmissionStatus , List <SubmissionStatus >>

STATE_HOLDER = new HashMap <SubmissionStatus , List <

SubmissionStatus >>();

2

3 static

4 {

5 STATE_HOLDER.put(SubmissionStatus.STARTED , Arrays.asList(

SubmissionStatus.SUBMITTED));

6 STATE_HOLDER.put(SubmissionStatus.SUBMITTED , Arrays.asList(

SubmissionStatus.ASSIGN_TO_REVIEWER , SubmissionStatus.DELETED));

7 ...

8 }

4.7. Listing. Engedélyezett státuszváltások

A képen az látszik, hogy a Started állapotból csak és kizárólag Submitted álla-

potba válthat a cikk státusza. Minden egyéb esetben kivétel keletkezik. A következ®

Submitted státuszból csak Assign to reviewer és Deleted státuszokba válthat.

Tervezés során �gyelembe kellett venni azt, hogy bármilyen módosítás az adat-

bázisban biztonságos legyen és ha kivételes esemény történik, akkor minden vissza-

vonásra kerüljön, ezzel elkerülve az inkonzisztens állapotot. Ezért minden státusz

váltásnak egy adatbázis tranzakcióba kell kerülnie. Ez annyit jelent, ha a státusz

váltás hívása során nem nyitunk új tranzakciót, az alkalmazás futási id®ben kivételt

fog dobni.

1 @Transactional(propagation = Propagation.MANDATORY , rollbackFor =

Exception.class)

2 public void doLifecycle(LIFECYCLE lifecycleRequest)

4.8. Listing. Adatbázis session kikényszerítés a Lifecycle osztályban


A képen a második sorban láthat Propagation.MANDATORY az, ami jelzi a

metódusnak, hogy kell létezni tranzakciónak. Amennyiben ez nem teljesül futás

id®ben kivétel keletkezik.

Az életciklus kívülr®l egy generikus metódus segítségével hívható, melynek nincs

visszatérési értéke. Paraméterül egy Lifecycle típust, vagy annak leszármazott osz-

tályait lehet átadni. Ebb®l következik, hogy minden státuszváltáshoz egyedi, a stá-

tuszváltást jellemz® osztály lett létrehozva, mely kiterjeszti a fentebb említett Li-

fecycle osztályt. Általában elég volt használni az alap Lifecycle osztályban de�niált

adattagokat, így csak névlegesség miatt kellett az új osztályokat de�niálni.

Az életciklusba való belépés során a paraméterben átadott kötelez® adatok ellen-

®rzése minden esetben megtörténik. Amennyiben azok nem megfelel®ek, az életcik-

lus m¶ködése leáll és hibaüzenet generálódik. Ha az adatok megfelelnek a követelmé-

nyeknek, ellen®rzés történik arra, hogy a következ® státuszba lépés az megengedett-e

a cikk jelenlegi státuszától függ®en. Ha nem, hibaüzenet keletkezik és a folyamat

megáll. Ha a státusz váltás engedélyezett, akkor a paraméter típusától függ®en

végrehajtódik a kezel® metódus. Amennyiben a végrehajtás során kivétel keletke-

zik minden visszavonásra kerül és hibaüzenet generálódik. Minden más esetben a

státuszváltást követ®en a futási folyamat tovább haladhat.

4.5.1. Életciklus használata

Azon szerviz osztályokba, ahol a Lifecycle-t használni akarjuk, be kell injektálni

mint egy Spring Beant. Szakdolgozatomban a konstruktor alapú bean hivatkozást

használtam. Injektálást követ®en képesek vagyunk használni a publikus metódusait

ezen osztályoknak. A Lifecycle osztálynak egyetlen doLifecycle metódusa van, ami

kívülr®l hívható.

Életciklus hívás során két kötelez® paramétert mindig meg kell adni. Ez az új

státusz és maga a Submission.

A Bírálóhoz rendelés életciklusa kódrészlet második sorában látható az a rész,

ami biztosítja, hogy új tranzakció nyíljon a metódus meghívása során, és ha bár-

milyen kivétel keletkezik, visszavonásra kerüljön minden módosítás. A 9. sorban

kérdezzük le az adatbázisból a cikk adatait, amely nem egy egyszer¶ lekérdezés.

Itt biztosítani kellett a kizárólagosságot, tehát ameddig az életciklus nem végzi el

a feladatát nem szabad az adott cikken adatbázis módosításokat végezni. A cikk

lekérdezésére egy olyan select lett írva, ami biztosítja, hogy addig ne lehessen mó-

dosítani a cikket, ameddig a tranzakció nyitva van, vagy egy update nem érkezik rá

a tranzakción belül. A 12. sorban látható a tényleges életciklus hívása.


1 @Override

2 @Transactional(propagation = Propagation.REQUIRES_NEW , rollbackFor

= Exception.class)

3 public AssignToReviewerResponse assignToReviewer(

AssignToReviewerRequest request)

4 {

5 AssignToReviewerResponse response = new AssignToReviewerResponse

();

6

7 AssignToReviewerLifecycle assignToReviewerLifecycle = new

AssignToReviewerLifecycle ();

8 assignToReviewerLifecycle.setNewStatus(SubmissionStatus.

WAITING_FOR_REVIEWERS);

9 assignToReviewerLifecycle.setSubmission(manuscriptDao.

getSubmissionForUpdate(request.getManuscriptId ()));

10 assignToReviewerLifecycle.setReviewers(request.getReviewers ());

11

12 lifecycle.doLifecycle(assignToReviewerLifecycle);

13

14 return response;

15 }

4.9. Listing. Bírálóhoz rendelés életciklusa

A Submission select for update kódrészletben az 5. sor lehet érdekes. Ennek

következtében az adatbázisban a cikk sora zárolásra kerül mindaddig, ameddig egy

update nem érkezik a sorra a tranzakción belül, vagy a tranzakció zárásra nem kerül.

1 <select id="getSubmissionForUpdate" resultMap="getSubmissionMap">

2 <include refid="selectSubmission"/>

3 WHERE

4 submission.SUBMISSION_ID = #{ submissionID}

5 FOR UPDATE

6 </select >

4.10. Listing. Submission select for update

4.5.2. Életciklus hibakezelés

Az életcikluson belül minden nem várt esemény le van kezelve, és egy egyedi kivétel

dobódik helyette. Tehát az Lifecycle osztályból egyedül StateChangeNotAllowed

kivétel dobódhat.

5. fejezet

Eredmények

5.1. Az alkalmazás m¶ködés közben

Az alkalmazás használata el®tt be kell jelentkezni az alkalmazásba. Ezt a következ®

bejelentkezési form kitöltésével teheti meg a felhasználó. Bejelentkezést követ®en

5.1. ábra. Bejelentkezési form

a f®képerny® tárul a felhasználók szeme elé. A f®képerny®n láthatóak az aktuális

hírek, megjegyzések melyek információ jelleggel bírhatnak. A jobb fels® sarokban

lett elhelyezve a menüsor.

5.2. ábra. Menüsor

36

5. FEJEZET. EREDMÉNYEK 37

A fenti menüsorban láthatóak az elérhet® menüpontok, azokra kattintva a meg-

felel® pontra lehet navigálni. A kijelentkezés gombra kattintva a felhasználó a beje-

lentkezés képerny®re navigálódik automatikusan.

Minden f®menü úgy lett megcsinálva, hogy a legfels® sávban látható, épp hol

vagyunk, alatta pedig egy rövid leírás mi érhet® el az adott oldalon. Itt található

egy gomb, amely lehet®vé teszi a felhasználónak, hogy feltöltsön egy új tudományos

cikket a rendszerbe. A sikerességet illetve a hibát is egy felugró ablak jelzi. Az

sikeresen záródó cikk feltöltését követ®en rögtön megjelenik a felhasználó számára

további tevékenységek céljából.

5.3. ábra. Sikeres cikkfeltöltés

Itt még nem tekinthet® benyújtott cikknek a feltöltött dokumentum, mivel nem

felel meg a követelményeknek teljesen, illetve nem történt meg a véglegesítés sem. A

kis ceruza ikonra kattintva a lista végén lehet a form-ot kiegészíteni, illetve véglege-

síteni. A kuka ikon, amely egy X jellel van megjelölve, véglegesen eltávolítja listából

a feltöltött cikket. Ha a felhasználó az ikonokra viszi az egerét, egy felugró buborék

információt szolgáltat, mire is használható az a gomb.

5.4. ábra. Cikk törlés gomb 5.5. ábra. Cikk szerkesztése gomb

A legalsó lista tartalmazza azokat a cikkeket, amelyeken megjelölték az éppen


bejelentkezett felhasználót, mint egy társszerz®. Ekkor azt a cikket nem szerkeszt-

heti, azonban a papír ikonra kattintva további információkat olvashat róla. A cikk

beküldését követ®en elérhet®vé válik a Szerkeszt® jogosultsággal rendelkez® felhasz-

nálóknak, hogy megtekintsék, illetve magukra vegyék azt. Amennyiben a talált cikk

megtetszik a szerkeszt®nek magára veheti további tevékenységek céljából.

5.6. ábra. Cikk keresése

Ha a felhasználó megtekinti az Editor menüpontot és az áttekint®re navigál lát-

hatja az éppen még folyamatban lév® cikkek bírálatát és a már lezártakat. Ha

sikeresen megszerzett egy tudományos cikket a szerkeszt®, egyb®l két tevékenység

válik lehet®vé számára. A papír ikon további adatot szolgáltat a cikkr®l, a két sze-

mélyt és egy plusz jelet ábrázoló ikon pedig lehet®vé teszi, hogy Bírálókhoz rendelje

azokat.

5.7. ábra. Bírálóhoz rendelés gomb

A gomb megnyomását követ®en ki lehet választani a megfelel® bírálókat. Fel-

kérést követ®en a bírálónak lehet®sége adódik elfogadni illetve visszautasítani a fel-

kérést. Amennyiben elfogadja azt, jogosulttá válik arra, hogy bírálja. Az elérhet®

gombok és az azokhoz tartozó buborék üzenetek a következ® képen látható.

5.8. ábra. Felkérés elfogadása gomb 5.9. ábra. Felkérés visszautasítása gomb


Amint megtörtént a bírálói form kitöltése, az editornak egy végs® döntés kell

hoznia. Ezt úgy teheti meg, hogy a megfelel® formot kitölti. Amennyiben a cikk

a bíráló által is elfogadásra kerül, további tevékenység a megtekintésen kívül nem

végezhet® rajta. A végs® formot az alábbi képen lehet megtekinteni.

5.10. ábra. Végs® bírálati form

A form beküldését követ®en a cikk életciklusa lezárult. Megjelenik a szerkeszt®-

nek a lezárt cikkek listáján jelezve, hogy publikálásra készen áll. A listán látható a

cikk egyedi azonosítója, a beadás dátuma, a véglegesítés dátuma és a végs® döntés.

Ezt a következ® képen tekinthetik meg.

5.11. ábra. Lezárt cikkek listája

6. fejezet

Lehet®ségek

Terveim között van, hogy az alkalmazást korszer¶sítem, és a kódot teljesen kicserél-

jem, hogy használja a Java 8-ban bevezetett új megoldásokat. Ezek mellett további

funkcionalitásokat szeretnék beépíteni, amelyek még könnyebbé tennék a használatot

és látványossá tenné azt. Az adminisztrátori jogosultsághoz tartozó funkcionalitások

is implementálásra kerülnének, ami akár egy újabb alkalmazást is jelenthetne. Ez

azt jelentené, hogy az adminisztrátori alkalmazás egy szeparált szerveren futhatna.

Továbbá a kés®bbiekben be lehetne építeni plágium vizsgálatot is. Ezzel egy

újabb státusz kerülne bevezetésre, és mindaddig abban is maradna a feltöltött du-

komentum, ameddig a vizsgálat be nem fejez®dik. Ha a vizsgálat elbukik, plágium

gyanújával tiltó listára kerülne az.

Ezen felül integrációt lehetne kiépíteni, egy publikálni képes rendszerrel, így az

elfogadott cikkek akár automatikusan meg is jelenhetnének.

40

7. fejezet

Összefoglalás

A kit¶zött célok megvalósítása sikeresnek bizonyult, a program a piaci igényeknek

megfelel®en kívántam elkészíteni. Az alkalmazás képes fogadni és kezelni a cikkek

bizonyos státuszait, a felhasználók jogosultságait, valamint a felhasznált adatokat

biztonsággal tárolja. Jelen dolgozatomat több alkalommal szükségesnek tartottam

újra írni, mert folyamatosan fejlesztettem és mindig a legkorszer¶bb megoldásokat

kívántam felhasználni, ezzel növelve hatékonyságát. A folyamatos kód-, valamint

front-end fejlesztése szélesítette tudásomat, adott újabb ötleteket a program kiahsz-

nálhatóságának b®vítése érdekében.

A front-end az elvárásoknak eleget tesz, egyszer¶ és átlátható alkalmazást készí-

tettem, ezzel könnyítve annak használatát.

A program tervezése során a program nem volt hivatott arra, hogy a felhaszná-

lóktól szenzitív adatokat kérjen és tároljon. Ez a véglegesítéskor is sikeresen megma-

radt. A regisztáricó után az alkalmazás egyb®l használatba vehet®, nem kér plusz

adatokat a kés®bbiekben sem.

A programot attól függetlenül, hogy a speci�kációban meghatározottan m¶kö-

dik, nem tekintem befejezettnek. Számos plusz funkciót lehet hozzáfejleszteni, akár

kódfrissítés, akár további alkalmazások összekapcsolásáról legyen szó. Potenciált lá-

tok abban, hogy a program a jöv®ben sikeres lehet, és érdemes lesz továbbfejleszteni

akár egy kutatómunka, tanulmány során.

41

8. fejezet

Summary

The developed web application is allow for the users to submit scienti�c papers and

can handle those statuses. It can handle di�erent roles. These are Author, Reviewer

and Editor. The application can be used everyone for free after an easy registra-

tion process. At this moment the program can handle the the judgement/opinions

but cannot publishing the articles. Nevertheless if it is proves successful there are

a several opportunity to improve or expand the application. I have used JAVA

programming language to develop my application.

I have refactored the program several times which result the code base is clean

and easy to understand. The base advantage of the front end is that, easy to use

and unequivocal for everyone.

I wanted that my application be free for everyone because the similar, demanding

programs cannot be used for everyone for free.

At the end I have successfully achieved all my goals.

42

9. fejezet

Köszönetnyilvánítás

Szeretném megköszönni mindazoknak, akik munkájukkal hozzájárultak a dolgoza-

tom elkészítéséhez. Köszönettel tartozom konzulensemnek Tóth Zsoltnak a dolgoza-

tom elkészítésében való segítségéért, szakmai tanácsaiért. Hálás vagyok az Általános

Informatikai Intézeti tanszékvalamennyi dolgozójának. Végül, de nem utolsó sorban

köszönettel tartozom szeretteimnek, akik mindenben támogattak és kitartottak mel-

lettem.

Köszönöm szépen!

43

Irodalomjegyzék

[1] Apache maven. https://hu.wikipedia.org/wiki/Apache_Maven.

[2] Apache tomcat. https://hu.wikipedia.org/wiki/Apache_Tomcat.

[3] Eclipse. https://hu.wikipedia.org/wiki/Eclipse.

[4] Java programozási nyelv. https://hu.wikipedia.org/wiki/Java_

(programoz%C3%A1si_nyelv).

[5] Liquibase plugin. https://en.wikipedia.org/wiki/Liquibase.

[6] Mysql database. https://hu.wikipedia.org/wiki/MySQL.

[7] Spring framework. https://projects.spring.io/spring-framework/.

[8] Spring tool suite. https://spring.io/tools/sts.

44

https://hu.wikipedia.org/wiki/Apache_Maven

https://hu.wikipedia.org/wiki/Apache_Tomcat

https://hu.wikipedia.org/wiki/Eclipse

https://hu.wikipedia.org/wiki/Java_(programoz%C3%A1si_nyelv)

https://hu.wikipedia.org/wiki/Java_(programoz%C3%A1si_nyelv)

https://en.wikipedia.org/wiki/Liquibase

https://hu.wikipedia.org/wiki/MySQL

https://projects.spring.io/spring-framework/

https://spring.io/tools/sts

A. függelék

CD Melléklet

A CD mellékleten a következ®k találhatóak meg:

• Dolgozat: a szakdolgozat állományai találhatóak meg ebben a mappában La-

TeX és PDF formátumban.

• Program: a forráskód található meg eben a mappában

45

tudományos cikk kezel® rendszer back-end illetve front

Documents