Dátum	Verzió	Leírás	Szerző
2017.11.14.	1.0	Kezdeti verzió	Nagy Áron
2017.11.21.	1.1	Pre-Alpha verzió	Nagy Áron Mikulás Bálint Péter
2017.11.28.	1.2	Alpha verzió	Nagy Áron
2017.12.01.	1.3	Béta Verzió	Nagy Áron
2017.12.01.	1.4	HTMl Verzió	Süle Ábel

Tartalomjegyzék

1. Bevezetés

A MiskolcApp elengedhetetlen kelléke a stabil és megbízható háttér amelyet egy megfelelően megtervezett rendszer szolgáltat. Ennek következtében szó lesz magáról a felhasználói felületről és az adatbázis rendszerről.
Előbbi részletesen tartalmazza azokat a rétegeket amelyeken az információ és az adatok keresztül mennek.
Utóbbi a programban található adatok tárolását és felhasználását segíti elő. Ez egy szerveren lesznek eltárolva benne folyamatosan frissülő adatokkal, értékekkel.

2. Felhasználói felület

Az ábra a felhasználói felülelet az ún. User Interface-t mutatja.
Amint látható három nagy csoportra osztható az egész felület:

• Az emberi (Human) érzékelés összetevői.
• A hardveres (Hardware) rész.
• A szoftveres (Software) rész.

Miről is szólnak ezek a különböző alegységek? Célszerű ha az adat átvitel szempontjából közelítjük meg ezt a kérdést. Az ábra bal oldalán feltüntetett agyi (Brain) területen fogalmazódik meg a felhasználóban a végrehajtandó feladat/parancs. A felhasználóban ezután megfogalmazódik a készülékkel való kapcsolat teremtés gondolata. Minket elsősorban az érdekel, hogy milyen eszközökkel tud kommunikálni egymással a felhasználó és a készülék. Az applikáció jellegéből adódóan elég két komoly területet elkülíteni.
Az első az ún. érzékelési (Senses) terület. Ez azt takarja ahogyan a felhasználó érzékeli a telefon által visszaküldött információkat. Jelen esetben képi információkra számítunk, ami az érzékelés szempontjából csak a szemet érinti.
A másik az ún.kezelési (Actuators) terület található. Ebben azt határozzuk meg, hogy a felhasználó hogyan visz be adatokat valamint hogyan bírja feladatvégzésre a programot. Szintén a program jellegéből adódóan itt elég csak az érintés hiszen se képi se hangalapú információ bevitel nem történik.
Tovább haladva a hardver felé fogalmazódik meg az előző kérdés a gép oldaláról. Hogyan? Milyen periférikus hardverekkel kommunikál a gép a felhasználóval? A felhasználó által letapintott felületet az ún. érintő képernyő (Touch Screen) fogja érzékelni. Szinten ez a képernyő látja el képi információkkal a felhasználót folyadék kristályos kijelző (Liquid Crystal Display) útján. Az ábrán tisztán látható, hogy itt hordozható elektronikai eszközökre gondoltunk (okostelefonok, tabletek stb.). Hogy mind a bemeneti (input), kimeneti(output) információ csere hibátlanul létrejöjjön olyan integrált áramkörre van szükség amely képes a matematikai-logikai (CPU), grafikai (GPU) és egyéb műveletek elvégzésére. Ezen belül létre kell hozni benne egy ún. Mobil Computer részt amely a szoftveres részekkel fogja a kapcsolatot tartani. Magán a szoftveres részen belül található a Kernel Space amely két nagy alrendszerre bontható:

• Grafikai alrendszer
• Beviteli alrendszer

Az előbbi a kimeneti az utóbbi a bemeneti adatokért felel.
A Kernel Space melett találjuk User Space-t amely két részből áll:

• Middleware
• MiskolcApp

A Middleware gyakorlatilag megkönnyíti az alkalmazás és a Kernel közti kommunikációt, mondhatni “hídat képez” a két rész között.
A MiskolcApp rész pedig már a maga az általunk fejlesztésre kerülő alkalmazás ahol egyaránt találkoznak a be- és kimeneti adatok. Maguk az adatok egyébként a szoftveres részen belül egy Be- és Kimeneti Hurkot képeznek (Input-Output Loop) hiszen itt szinte folyamatosan kétinányú adatfeldolgozás történik.

3. Adatmodellek

A MiskolcApp-nak jellegéből adódóan nagy mértékű és megbízható adatbázis rendszerre van szüksége. Mivel ez külső forrás által nem oldható meg ezért az adatbázis rendszer létrehozása is kiemelt szerepet kap a projekt folyamán. A továbbiakban az adatbázis felépítésről, leírásáról és implementálásáról lesz szó.

3.1. Adatbázis kezelő kiválasztása

Az implementáció MySQL-el történik amely többfelhasználós, többszálú, SQL-alapú relációs adatbázis kezezlő szoftver. Az illesztő felületek lehetőséget adnak arra hogy az adatbázis-kezelő kapcsoltatot teremtsen az általunk használt Eclipse programozói GUI-val.

3.2. Szemantikai adatmodell

A szemantikai adatmodellek közül számunkra az ER-modell jelenti a legpratikussabb megoldást. Az alkalmazás ER modellje a következő:

Amint látható az alkalmazás két lényegi részre különül el, a menetrendre és több “egyéb” egyedekre. Az ábrában felül kaptak helyet a menetrenddel kapcsolatos egyedek.
A Stop egyed a megállókat a Line egyed a vonalakat tartalmazza és olyan kapcsolatban vannak a Timetable egyeddel, hogy a Timetable-hez több megálló és vonal is tartozhat, de egy megálló és egy vonal csak egy Timetable-ben kaphat helyet.
Az, hogy az egyedek mely tulajdonságokkal rendelkeznek és hogy azok miket határoznak meg és miért, részletes leírásra kerül az ER modell-ből Relációs modell-be történő konvertálásnál.
A továbbiakban kerülnek kibontásra a hátralevő egyedek:
A User egyed a felhasználókat tartalmazza míg a Service a szolgáltatásokat és ezen két egyed olyan ún. “több-több” kapcsolatban vannak, hogy egy szolgáltatás több felhasználóval is alakíthat ki kapcsolatott és szintúgy, egy felhaszáló több szolgáltatással is.
Másképp alakul a helyzet a Service és a Pictures egyedek között (utóbbi a képeket tartalmazó egyed) ott ugyanis egy kép csak egy szolgáltatáshoz kapcsolódhat viszont egy szolgáltatás több képet is igénybe vehet. Ugyanez a szituáció a Pictures és Company egyedek között (utóbbi a cégeket tartalmazó egyed) hiszen egy céghez több kép is társulhat de maga egy kép csak egy képpel képes kapcsolatot kialakítani. Valamint létezik még egy érteklésre létrehozott egyed mely a Service egyedhez kapcsolódik és a Rate nevet viseli.

3.3 Relációs adatmodell

A konvertáció folyamata az alábbi módon történik:

A Timetable egyedből tábla képződik azonos névvel az alábbi tulajdonságokkal:
TTInex, amely a tábla elsődleges kulcsa, egyben index.
LineID, amely a Line táblából származó külső kulcs és a vonalat határozza meg (pl. 1-es villamos)
Day, amely többértékű tulajdonság ezért a felvehető értékeit egy külön Day nevű táblázatban fogjuk tárolni.
Run, amely az adott nap első járatától számított index az adott járatra nézve.
StopIndex, amely az adott Run n-edik megállója.
StopID, amely a Stop táblából származó külső kulcs és a megálló nevét határozza meg.
Hour, amely az órát adja meg.
Minute, amely a percet adja meg.

Ezt követően következik a logikailag ettől külön álló de szintén az adatbázis részét képező egyedek és tulajdonságaik konvertációja:

A Service egyedből tábla képződik az alábbi tulajdonságokkal:
ServiceID, amely a tábla elsődleges kulcsa.
ServiceName, amely az adott szolgáltatás nevét tartalmazza.
ServiceType, amely többértékű tulajdonság ezért felvehető értékeit egy külön ServiceType táblázatban fogjuk tárolni és az adott szolgáltatás típusát tartalmazza
Day amely egy többértékű tulajdonság és ugyanazon a Day táblán veszi fel az értékeit mint a korábban említett Timetable tábla.
Open, amely a nyitási időpont (óó:pp).
Close, amely a zárási időpont(óó:pp).
Text, amely szöveges leírást tartalmaz az eggyes szolgáltatásokról.
Picture, amely a Picture táblázatból származó külső kulcs és a szolgáltatással kapcsolatos képet/képeket határozza meg.

A Rate egyedből tábla képződik a következő tulajdonságokkal:
RateID, amely a tábla elsődleges kulcsa.
Text, amely a szöveges értékelést tartalmazza.
Timestamp, amely az értékelés beérkezésének időpontját tartalmazza.
Point, amely egy többértékű tulajdonság ami a Point táblából veszi fel az értékeit.

A User egyedből tábla képződik az alábbi tulajdonságokkal:
UserID, amely az egyed elsődleges kulcsa.
A Name típusú tulajdonságot két tulajdonság a FirstName és a LastName határozza meg így a relációs modellbe már csak ezek kerülnek bele ahol:
FirstName, amely a felhasználó vezetéknevét tartalmazza.
LastName, amely a felhasználó keresztnevét tartalmazza.
UserName, amely a felhasználó által szabadon választott alternatív név.
Password, amely a felhasználó által megadott jelszó.
Gender, amely többértékű tulajdonság ezért egy külön Gender táblázatból veszi fel az értékeit.

A Pictures egyedből tábla képződik az alábbi tulajdonságokkal:
PictureID, amely a tábla elsődleges kulcsa.
PictureName, amely a kép neve.
Link, amely az adott képre mutató link.

A Company egyedből tábla képződik az alábbi tulajdonságokkal:
CompanyID, amely a táblázat elsődleges kulcsa.
Company, amely az adott cég neve.
E-mail, amely a cég oldaláról kommunikációt folytató személy e-mail címe.
Text, amely az adott cégről szóló leírás.
Picture, amely egy Pictures táblázatból származó kulcs és az adott céggel kapcsolatos képet/képeket tartalmazza.

A továbbiakban a többértékű tulajdonságok értékeit tartalmazó táblák leírása következik:

Day tábla:
DayID, amely a tábla elsődleges kulcsa.
DayType, amely a nap típusát tartalmazza. (előzetesen: hétköznap, szombat, vasárnap)
Ezt a táblát egyaránt használja a Timetable és a Service tábla.

ServiceType tábla:
SerTypeID, amely a tábla elsődleges kulcsa.
SerType, amely a szolgáltatás típusát tartalmazza. (előzetesen: látnivaló, hotel, étterem, kávéház, apartman, szabadidő[pl. uszoda, mozi stb.])

UserType tábla:
UTypeID, amely a tábla elsődleges kulcsa.
UType, amely a felhaszáló típusát tartalmazza. (előzetesen: inhabitant, tourist, administrator)

Gender tábla:
GenderID, amely a tábla elsődleges kulcsa
Gender, amely a felhasználó nemét tartalmazza. (előzetesen: férfi, nő)

Point tábla:
PointID, amely a tábla elsődleges kulcsa.
Point, amely a pontozást tartalmazza.

Ezenkívűl található a modellben egy úgy Switchboard. Erre a több-több kapcsolat miatt van szükség amely Service és a User tábla között fennáll. Ez mindössze annyit csinál, hogy veszi mindkét tábla elsődeleges kulcsát és külső kulcsként magába foglalja. Erre azért van szükség mert az esetleges implementáció során nem tudnánk közvetlen kapcsolatot teremteni a két tábla között hiszen mindkettőben lenne egy-egy külső kulcs ami egy még létre nem jött táblára mutatna.

Végül az elkészült modell ábrázolása:

3.4. Az adatbázissal kapcsolatot tartó osztályok

Az adatbázisasal az ún. DB_main osztály fogja tartani a kapcsolatot.