Szakdolgozat. Költségnyilvántartó program háztartások részére. Miskolci Egyetem Gépészmérnöki és Informatikai Kar Általános Informatikai Tanszék

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Általános Informatikai Tanszék

Szakdolgozat Költségnyilvántartó program háztartások részére

Készítette: Kékedi Gábor Szak: Gazdaságinformatikus Bsc Témavezető: Szűcs Miklós mérnöktanár Konzulens: Dr. Makó Judit egyetemi adjunktus

Miskolci Egyetem 2014.

Kékedi Gábor: Költségnyilvántartó program háztartások részére

MISKOLCI EGYETEM Gépészmérnöki és Informatikai Kar Analízis Tanszék Szám:..................................

SZAKDOLGOZAT FELADAT Kékedi Gábor (BTM3F9) gazdaságinformatikus jelölt részére. A szakdolgozat tárgyköre: szoftverfejlesztés A szakdolgozat címe: Költségnyilvántartó program háztartások részére A feladat részletezése: -

Kliens programok kialakításának módjainak ismertetése,

-

A tervezés ismertetése (adatbázisterv, funkcionális terv, dizájn),

-

Az alkalmazás elkészítésének és tesztelésének leírása,

-

Statisztikák megjelenítése.

Témavezető(k): Szűcs Miklós mérnöktanár (Általános Informatikai Tsz.) Konzulens(ek): Dr. Makó Judit, egyetemi adjunktus (Analízis Tsz.) A feladat kiadásának ideje: 2014.09.18 A feladat beadási határideje: 2014.11.21 .................................................... Dr. Szigeti Jenő tanszékvezető

2.


1. szükséges (módosítás külön lapon). A szakdolgozat feladat módosítása nem szükséges. .................................

......................................................................

dátum

témavezető(k)

2. A feladat kidolgozását ellenőriztem: témavezető (dátum, aláírás):

konzulens (dátum, aláírás):

.............................................

………............................................

.............................................

......………......................................

.............................................

.................………...........................

3. A szakdolgozat beadható: .................................

......................................................................

dátum 4. A szakdolgozat

témavezető(k)

........................... szövegoldalt .......................... program protokollt (listát, felhasználói leírást) ........................... elektronikus adathordozót (részletezve) ........................... ........................... egyéb mellékletet (részletezve) ...........................

tartalmaz. ................................. dátum

...................................................................... témavezető(k)

3.


5. bocsátható. A szakdolgozat bírálatra nem bocsátható. A bíráló neve:.....................…………..……………………............................................ ….............................

……………..…............................................

dátum

tanszékvezető

6. A szakdolgozat osztályzata a témavezető javaslata: …..…………….................... a bíráló javaslata: ……….……………...................... a szakdolgozat végleges eredménye: ......................... Miskolc, ......................................... ........................................................... a Záróvizsga Bizottság Elnöke

4.


5.

EREDETISÉGI NYILATKOZAT

Alulírott Kékedi Gábor, Neptun-kód: BTM3F9, a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végzős gazdaságinformatikus szakos hallgatója ezennel büntetőjogi és fegyelmi felelősségem tudatában nyilatkozom és aláírásommal igazolom, hogy a Költségnyilvántartó program háztartások részére 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 veszem, 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 veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül. Miskolc ,.............év ………………..hó ………..nap

…….……………………………….… Hallgató


6.

Tartalom 1.

Bevezetés ............................................................................................................................ 8

2.

Kliens programok kialakításának módjainak ismertetése ................................................ 10

3.

2.1

Önálló alkalmazások .................................................................................................. 10

2.2

Kliens-szerver alkalmazások ..................................................................................... 11

2.3

Többrétegű alkalmazások .......................................................................................... 12

A tervezés ismertetése ...................................................................................................... 15 3.1

3.1.1

Az adatbázis célja ............................................................................................... 15

3.1.2

A szükséges táblák ............................................................................................. 15

3.1.3

A táblák mezőinek meghatározása ..................................................................... 16

3.1.4

Kapcsolatok felállítása a táblák között ............................................................... 16

3.1.5

Adatbázis szemléltetés modellekkel ................................................................... 17

3.1.6

Adatbázis típus ................................................................................................... 19

3.2

Funkcionális terv ........................................................................................................ 20

3.2.1

Kiadáskezelés ..................................................................................................... 20

3.2.2

Bevételkezelés .................................................................................................... 21

3.2.3

Kategóriakezelés ................................................................................................. 22

3.2.4

Lokalizáció ......................................................................................................... 23

3.2.5

Statisztikák ......................................................................................................... 24

3.3

4.

Adatbázisterv ............................................................................................................. 15

Dizájn terv.................................................................................................................. 24

3.3.1

Kategóriapanel .................................................................................................... 25

3.3.2

A bevételpanel és a kiadáspanel ......................................................................... 25

3.3.3

Statisztika panel .................................................................................................. 26

3.3.4

Adatok részletei ablak ........................................................................................ 27

3.3.5

Megerősítő / figyelmeztető ablak ....................................................................... 27

Az alkalmazás elkészítésének és tesztelésének leírása ..................................................... 29 4.1

Az implementáció menete.......................................................................................... 29

4.2

Képernyőminták ......................................................................................................... 32

4.2.1

Kategória ............................................................................................................ 32

4.2.2

Bevétel/kiadás ..................................................................................................... 33

4.2.3

Statisztika ........................................................................................................... 35

Kékedi Gábor: Költségnyilvántartó program háztartások részére 4.3 5.

7.

Az alkalmazás tesztelése ............................................................................................ 36

Statisztikák megjelenítése................................................................................................. 39 5.1

Kiadások kategóriánként - kördiagram ...................................................................... 41

5.2

Kiadások kategóriánként - oszlopdiagram ................................................................. 42

6.

Összefoglalás .................................................................................................................... 43

7.

Summary........................................................................................................................... 45

8.

Felhasznált irodalom ........................................................................................................ 47 8.1

Internetes hivatkozások .............................................................................................. 47


8.

1. Bevezetés Annak ellenére, hogy a pénzügyek mindig is egy központi szerepet töltöttek be a mindennapjainkban, hajlamosak vagyunk felületesen, hanyagul kezelni azokat. Sajnos a legtöbb ember, akik nem rendelkeznek semmilyen pénzügyi ismerettel, képzettséggel, de sokszor azok is, akik igen, rengeteg pénzügyileg rossz döntést hoznak. [1] Gondoljunk azokra, az emberekre, akik annyi megtakarítással sem rendelkeznek, hogy pár hónapig megéljenek, ha esetleg elvesztenék az állásukat, mégis könnyen ugranak bele egy személyi kölcsönbe, mindössze azért, hogy el tudjanak menni nyaralni, esetleg megvegyenek egy nagyobb háztartási eszközt, amihez kell egy kis önerő. Nemcsak a személyi kölcsönök esetén felelőtlenek az emberek, hanem más pénzügyi termékekkel kapcsolatban is. Ahelyett, hogy megvizsgálnának több opciót, lehetőséget is, például egy biztosítás esetén, nagyrészük rögtön az első ajánlatra rábólint. A megtakarítások hiányának az egyik oka, hogy sokan úgy gondolkodnak, hogy ha bizonyos összeggel nő a fizetésük, tehát többet keresnek, akkor többet is költhetnek, ha viszont csökken a fizetésük, akkor analóg módon kevesebbet, tehát a megtakarítás meg sem fordul a fejükben. Egy másik szignifikáns ok, hogy nem tudjuk, hova folyik el a pénzünk. Egyrészt kiadásaink egy része impulzív vásárlás, ami azt jelenti, hogy valójában nincs szükségünk az adott termékre, vagy szolgáltatásra, csupán az adott pillanatban érezzük úgy. Másrészt kevesen vezetik, a költségeiket, bevételeiket, ha igen, akkor is csak nagy tételekben gondolkodnak. Nézzük meg például, ha a munkahelyen minden alkalommal veszünk egy 250Ft-os üdítőt és egy 250Ft-os péksüteményt, ami összesen 500Ft, ezt felszorozva az egy évben levő munkanapok számával, ami 253 volt 2014-ben, máris láthatjuk, hogy 136000Ft-ot elköltöttünk és nem is emlékszünk, hogy mire. [1] Következésképpen, nem tudjuk visszamenőleg megnézni sem, mikor, mire és mennyit költöttünk, pedig sokszor ez nagyon jól jönne; gondoljunk csak bele, ha megnézhetnénk, hogy mikor


9.

vettünk utoljára mikrohullámú sütőt, egy egyszerű kereséssel, ahelyett, hogy a talán nem is létező blokk után vadászunk a házban. Az elhangzottak alapján úgy gondoltam, hogy mennyivel megkönnyítené a helyzetet egy alkalmazás, aminek segítségével vezethetjük a bevételeinket, valamint a kiadásainkat, visszanézhetjük őket, hogy melyik időszakban, mire költöttünk, milyen bevételekre tettünk szert. Láthatnánk statisztikákat, hogy hogyan aránylik a bevételünk a kiadásainkhoz, hogyan aránylanak kategóriánként egymáshoz a bevételek, valamint a kiadások.


10.

2. Kliens programok kialakításának módjainak ismertetése Az internet terjedésének köszönhetően, egyre többen és többen kapcsolódtak fel a világhálóra, ami drasztikus változást eredményezett a mindennapi életünkben, legyen szó: tanulásról, munkavégzésről vagy szórakozásról. Az alkalmazások jelentős része webessé vált, képesek online kommunikálni más alkalmazásokkal, különböző üzleti folyamatokat lebonyolítani, aminek köszönhetően nagymértékben átalakult a vállalatok felépítése és működése. [2] Az idő múlásával az alkalmazások kialakítása folyamatosan változott, a kezdetleges kliens-szerver architektúrát felváltották a többrétegű alkalmazások, ahol egyik réteg a böngészőben megtekinthető felület, amit a felhasználó ér el, a többi réteg közé tartozik az adatbázis szerver, valamint az alkalmazás szerver. Mivel egyre több felhasználó rendelkezett internet hozzáféréssel, így egyre több olyan felhasználó is, aki minimális informatikai ismerettel rendelkezett, muszáj volt egyszerűsíteni az alkalmazásokon, hogy elég érthetőek legyenek. Ez tulajdonképpen a web 2.0. [2] Az asztali alkalmazások egy részét leváltották a webes alkalmazások. A két típus fejlesztési módszerei között jelentős eltérés van. Utóbbi esetén a logika nagy része a szerveren található, ennek köszönhetően az új verziók könnyen eljutnak a felhasználókhoz, az asztali alkalmazásokkal ellentétben, ahol a felhasználónak sok esetben egyedül kell telepíteni a frissítéseket, ami rengeteg időbe telik, továbbá kompatibilitási problémákat is okozhatnak. [2] Az internet, mint kommunikációs közeg egységes átviteli protokollt határoz meg, a http-t (https), valamint egységes tartalom leírást, ami pedig, nem más, mint a HTML, XML, újabban pedig csatlakozott a JSON is. Kijelenthetjük, hogy az internet, kommunikációs és megjelenítési platformként is szolgál egy időben.[2]

2.1 Önálló alkalmazások  Olyan szoftver, ami képes offline, internet hozzáférés nélkül működni.


11.

 Nem igényli a futáshoz, hogy az operációs rendszer valamilyen szolgáltatást futasson.  Ide tartoznak a szállítható alkalmazások, amik tulajdonképpen egy futtatható fájlból állnak, nem szükséges telepíteni őket.  A helyi gépen tároljuk a különböző adatokat. [2][3]

1. ábra [2]

2.2 Kliens-szerver alkalmazások Az 1980-tól kezdték először használni a kliens-szerver megnevezést, ahol a kliens ügyfelet, a szerver pedig kiszolgálót jelöl. Ez az architektúra növeli a használhatóságot, a rugalmasságot, a bővíthetőséget. Kliens: kliensnek nevezzük azt a számítógépet, amely szolgáltatást vesz igénybe egy vagy több szervertől, a kliens és a szerver közös számítógép hálózaton található. Mivel az alkalmazás logika nagy része a kliensen található, ezért szokás vastagkliensnek is hívni, ezeket a programokat. [4] Jellemzők  Kérésekkel fordul a szerverhez.  Fogadja a válaszokat a szervertől.  A felhasználó igényeit egy grafikus felületen keresztül viszi be, így kommunikál a szerverrel tulajdonképpen. Szerver: a kiszolgáló általában egy nagy erőforrású számítógépet, illetve szoftvert jelent, ami biztosítja a rajta tárolt esetleg létrehozott adatok, szolgáltatások elérést.


12.

Jellemzők  Várja a kliensek kéréseit, passzívan viselkedik.  A beérkező kéréseket feldolgozza, majd a választ visszaküldi a kliensnek.  Általában több kliens szolgál ki egy szerver.  Mivel a felhasználó grafikus interfészen keresztül kommunikál, így a szerver nem közvetlen, hanem közvetett kapcsolatban áll a szerverrel. [4]

2. ábra [2]

2.3 Többrétegű alkalmazások Ebben az esetben, a webes alkalmazások jellemzően több rétegből állnak, ami minimálisan 3 réteget jelent. Különböző folyamatokra bonjuk a megjelenítést, az adatkezelést, valamint az üzleti logikát. Ennek köszönhetően a fejlesztőknek könnyebb lesz karbantartani az alkalmazásokat, valamint a lefejlesztett új funkciókat is könnyen integrálhatjuk a rendszerbe. Rétegek  Megjelenítés: Általában ez a felhasználói interfész, szokás Front End-nek is nevezni, általában egy web-böngésző.  Üzleti logika: Middleware, itt futnak az üzleti folyamatok, a hosszú életű tranzakciók.


13.

 Perzisztencia: Az adatok perzisztens tárolása tartósságot jelent. Más néven Back End, azaz egy hátsó oldali nagy kapacitású számoló és tároló réteg. Gyakran összekeverik a háromrétegű architektúrát, a Model-View-Controller, azaz MVC architektúrával, amit a megjelenítésben szokás használni. Utóbbinál a Model réteg jelenti az adatokat, amivel a Controller és a View is kommunikál, szemben a háromrétegű architektúrával, ahol a megjelenítési réteg kizárólag az üzleti logikán keresztül fogja elérni az adatokat. [5] Előfordulhat, hogy a három réteg nem elég, mert nem elég robosztus a programunk, esetleg hirtelen megnövekedett a felhasználószám és gondolnunk kell a skálázhatóságra, akkor további rétegekre bonthatjuk az egyes rétegeket. Ismert példa erre, amikor a Back-end réteget tovább bontjuk, az úgy nevezett ORM által megvalósított, DAO tervezési minta segítségével. [6] Jellemzők  Mivel a felhasználó gépén, csak a böngésző fut, nem kell semmit telepíteni, ahhoz hogy fusson az alkalmazás, ezért szokás vékony kliensnek is nevezni.  Az első pontból következik, hogy frissítések esetén sem kell a klienseknek telepíteni, csak a szerverhez kell hozzányúlni.  Szintén az első pont eredménye, hogy a platform függetlenség, valamint hogy nincs szükség nagy erőforrású gépek használatára.  A jól megoldott skálázásnak köszönhetően, rengeteg felhasználó használhatja az alkalmazást és a terhelés egyenletes eloszlik, sokkal jobban, mint egy kliens szerver architektúra esetén.  A rendszer egyes rétegei önmagukban is tesztelhetőek, az egyes komponensek újrahasznosíthatóak.[6]


3. ábra [2]

14.


15.

3. A tervezés ismertetése 3.1 Adatbázisterv 3.1.1 Az adatbázis célja Adatbázis segítségével valósítjuk meg az adatok perzisztens tárolását, így az alkalmazásban végrehajtott műveletek eredményei, úgy, mint az új elemek felvétele, meglévők módosítása, esetleg törlése, az alkalmazásból való kilépés után is megmaradnak. A szoftver a felhasználó által felvett bevételeket, kiadásokat fogja kezelni, nyilvántartani. Egy bevételek és kiadások kategóriákba, azon belül alkategóriákba sorolhatóak. Tehát a tárolandó adatok körébe tartoznak a következők:  Kategória  Alkategória  Bevétel  Kiadás Az

adatbázisnak

köszönhetően,

készítünk

majd

statisztikákat

is

időintervallumokra bontva, hogy az egy adott időszakban, milyen bevételeink, milyen kiadásaink voltak, szűrhetünk majd kategóriákra stb. 3.1.2 A szükséges táblák Az összegyűjtött információkat először témakörökre, majd táblákra bonjuk. [7] A táblákat normalizáljuk, ugyanis kerülnünk kell a redundanciát, az információatom ismétlődését, de figyelnünk kell arra is, hogy értékes adat ne vesszen el a normalizálás során. Az eddigi tervek alapján, az alábbi tábláink lesznek:  Kategória tábla (Category)  Alkategória tábla (Subcategory)  Bevétel tábla (Income)  Kiadás tábla (Expense)


16.

3.1.3 A táblák mezőinek meghatározása Meghatározzuk, hogy mit szeretnénk megtudni a táblákról, és, hogy ehhez milyen jellemző adatok szükségesek. [7]

Ennek ismeretében határozzuk meg a

mezőneveket. Meg kell jelölnünk egy mezőt, amely betölti az elsődleges kulcs szerepét, tehát egyértelműen azonosítja a tábla rekordjait. Általában ez egy automatikusan generált, egyszerű sorszámozású mező, amit maga az adatbázis biztosít. Minden táblában tehát lesz egy szám típusú azonosító mező. Kategória tábla esetén tároljuk még a kategória nevét, valamint a típusát, ami azt jelöli, hogy a kategória bevételt jelöl-e vagy kiadást. Az alkategória adatai: azonosító, alkategória név. A bevételhez tartozik azonosító, összeg, megjegyzés, valamint mivel az alkalmazás képes lesz különbséget tenni egyszeri és rendszeres kiadások között, ezért szükség van egy rendszerességet tároló mezőre, valamint egy kezdő- és egy végdátumra, hogy a szóban forgó bevételek esetén tudjuk tárolni, hogy mikortól, meddig tart a bevétel. A kiadások teljesen analóg módon tárolódnak, mint a bevételek. Azaz a következő mezők lesznek: azonosító, összeg, kezdő dátum, végdátum, rendszeresség.  Kategória (azonosító, név, kategória típus)  Alkategória (azonosító, név)  Bevétel (azonosító, név, összeg, kezdődátum, végdátum, rendszeresség)  Kiadás (azonosító, név, összeg, kezdődátum, végdátum, rendszeresség) 3.1.4 Kapcsolatok felállítása a táblák között Egy adott kategóriához több alkategória is tartozhat, tehát egy-több kapcsolat van a két tábla között, így szükségünk lesz egy kategória mezőre az alkategória táblában, ami megmutatja, hova tartozik, ki a „szülője”. Az alkategóriákban már nem tároljuk, hogy bevételhez, vagy kiadáshoz tartozik, ugyanis ez már megtalálható a hozzátartozó kategóriában. Ahhoz, hogy tudjuk, hova soroljuk a bevételt illetve a kiadást, szükséges egy alkategória mező mindkét táblában.


17.

Ezen információk birtokában az adatbázis struktúra így alakult:  kategória (azonosító, név, típus),  alkategória (azonosító, név, kategória),  bevétel (azonosító, név, összeg, kezdődátum, végdátum, rendszeresség, alkategória),  kiadás (azonosító, név, összeg, kezdődátum, végdátum, rendszeresség, alkategória). 3.1.5 Adatbázis szemléltetés modellekkel Az informatikában megjelenő szakirodalom legelterjedtebb nyelve az angol, ezért nem magyarul láthatjuk az modellekben megjelenő adatokat. Mivel ez még a fejlesztés fázisára vonatkozik,a felhasználói élményt nem befolyásolja, hasonlóan ahhoz, hogy az implementálási rész is alapvetően angolul történik. Az ER, azaz egyed-kapcsolat modell segítségével leírhatjuk az adatbázis szerkezetét grafikusan. A téglalapok jelölik az egyedeket, amikből később adatbázis táblái lesznek, az ellipszisek a tulajdonságokat, amikből pedig az adatbázis mezői. A nyilak jelzik a táblák közötti kapcsolatokat, a szimpla nyílvégek azt jelentik, hogy egy darab entitás kötődik az adott oldalhoz, a dupla nyílvégek pedig, hogy több entitás. Láthatjuk, hogy az alkategóriához egy darab fő vagy szülőkategória tartozik, de egy adott főkategóriának lehet több alkategóriája is.


18.

4. ábra Az egyed-kapcsolat modellt könnyen átalakíthatjuk relációs adatmodellé, amely már szinte teljesen megegyezik egy relációs adatbázis felépítésével, ugyanis itt már meg vannak határozva a konkrét táblák, a mezők a típusukkal, méretükkel, beleértve a kapcsoló táblákat, elsődleges és idegen kulcsokat.

5. ábra


19.

3.1.6 Adatbázis típus Attól függően, hogy milyen szempontok alapján rendeljük egymáshoz az adatokat, az alábbi adatbázis típusokat különböztetjük meg: [8]    

hierarchikus modell, hálózati modell, relációs modell, objektum orientált modell. Az előző fejezetekben vázolt struktúra relációs modellen alapul. Az

alkalmazás objektum orientált modellt használ, ami azt jelenti, hogy az adatbázis kezelő rendszer objektumokkal dolgozik és nem táblázatos formában kezeli az adatokat. A két modell közötti konverzió egyszerű és könnyen átlátható, mivel alapvetően az objektum orientált világban, a relációs modell tábláit az üzleti logikában osztályok jelölik, a rekordok pedig objektumok lesznek. Ennek az adatbázis modellnek az implementálásához, az ObjectDB adatbázis, egy külső osztálykönyvtárt használok. Az ObjectDB, tehát egy objektum orientált adatbázis kezelő rendszer, ami rendkívül gyors, megbízható és könnyű használni. Biztosítottak az alapvető adatbázis szolgáltatások, a tárolástól és a lekérdezéstől kezdve a tranzakció kezelésen át egészen a szinkronizáltságig, ami lehetővé teszi, a szálkezelést. [9] ObjectDB adatbázis főbb jellemzői:  100%-ban tiszta Java alapú objektum orientált adatbázis kezelő rendszer (ODBMS)  Nincs jogvédett API, sztenderd Java API-kat használ, például a JPA 2-t vagy a JDO 2-t  Gyorsabb bármelyik JPA / JDO versenytársánál  A kisméretű adatbázisfájloktól, egészen a nagyméretű fájlokig használható  Egyetlen jar fájlra van szükségünk, külső függőségek nélkül  Haladó lekérdező és indexelési képességek  Több felhasználós környezetben is hatékony  Bármilyen típusú és méretű alkalmazásba könnyen beágyazható  Tomcat,Jetty, GlassFish, JBoss és Spring által tesztelt [9]


20.

3.2 Funkcionális terv 3.2.1 Kiadáskezelés A pénzügyeink menedzselésének egyik fő része a kiadások nyilvántartása. Ide fog beletartozni az új kiadások felvétele, a meglévő kiadások módosítása valamint törlése. Ezzel a három művelettel mindent meg tudunk majd csinálni, amit szeretnénk.  Kiadásfelvétel: Lehetőségünk van új kiadás felvételére, ami így belekerül a költségvetésünkbe. Az új kiadás gombra kattintva tehetjük ezt meg. Szükséges kitöltenünk az összes mezőt, kivéve a megjegyzést, az nem kötelező. Választhatunk, hogy egyszeri vagy rendszeres kiadásról van szó. Utóbbi esetben meg kell adnunk, a gyakoriságot, ami lehet havi, heti, napi továbbá ki kell választanunk egy kezdő dátumot, hogy mettől éljen a kiadás, valamint megadhatunk egy befejezési dátumot, hogy meddig éljen a kiadás rendszeressége. Az OK gombra kattintva elmentjük a kiadást, a Mégsem gombra való kattintás esetén egy felugró ablak figyelmeztet bennünket, hogy biztos ki akarunk-e lépni, mert az újonnan felvitt adataink elvesznek. Ha megerősítjük a kilépést, akkor az új kiadás felvitele meghiúsul, ha nem erősítjük meg, akkor lehetőségünk van véglegesíteni a kiadás felvételt.  Kiadásmódosítás: A listából kiválasztva egy darab kiadást (szigorúan csak egyet) módosíthatjuk ezt. A felugró ablakban megjelennek a kiadáshoz tartozó adatok. Az azonosítót, valamint rendszerességet (napi, heti, havi) nem módosíthatjuk. A rendszerességbe nem tartozik bele, hogy a végdátumot beállítjuk. (egyszeri kiadás esetén beszélünk végdátumról) Ha végeztünk az OK gombra kattintva elmenthetjük a kiadást, a Mégsem gomb esetén egy felugró ablak figyelmeztet bennünket, hogy biztos ki akarunk-e lépni, mert a módosításaink elvesznek. Ha megerősítjük a kilépést, akkor a kiadás


21.

módosítása meghiúsul, ha nem erősítjük meg, akkor lehetőségünk van véglegesíteni a kiadás módosítását.  Kiadástörlés: A kiadás listából kiválasztva a megfelelő eleme(ke)t , tehát akár többet is egyszerre törölhetjük azokat a költségvetésünkből. Ha a törlés opciót választjuk egy felugró ablak jelenik meg, hogy biztosan törölni szeretnénk-e az alábbi elemeket. Ha megerősítjük a döntésünket, azaz az OK gombra kattintunk, akkor törlődnek a költségvetésünkből az adatok, ha nem, tehát a Mégsem gombra kattintunk, akkor a törlés művelet meghiúsul. 3.2.2 Bevételkezelés  Bevételfelvétel: Lehetőségünk van új bevétel felvételére, ami így belekerül a költségvetésünkbe. Az új bevétel gombra kattintva tehetjük ezt meg. Szükséges kitöltenünk az összes mezőt, kivéve a megjegyzést, az nem kötelező. Választhatunk, hogy egyszeri vagy rendszeres bevételről van szó. Utóbbi esetben meg kell adnunk, a gyakoriságot, ami lehet havi, heti, napi továbbá ki kell választanunk egy kezdő dátumot, hogy mettől éljen a bevétel, valamint megadhatunk egy befejezési dátumot, hogy meddig éljen a bevétel rendszeressége Az OK gombra kattintva elmentjük a bevételt, a Mégsem gombra való kattintás esetén egy felugró ablak figyelmeztet bennünket, hogy biztos ki akarunk-e lépni, mert az újonnan felvitt adataink elvesznek. Ha megerősítjük a kilépést, akkor az új bevétel felvitele meghiúsul, ha nem erősítjük meg, akkor lehetőségünk van véglegesíteni a bevételfelvételt.  Bevétel módosítás: A listából kiválasztva egy darab bevételt (szigorúan csak egyet) módosíthatjuk ezt. A felugró ablakban megjelennek a bevételhez tartozó adatok. Az azonosítót, valamint rendszerességet (napi, heti, havi) nem módosíthatjuk. A rendszerességbe nem tartozik bele, hogy a végdátumot beállítjuk. (egyszeri bevétel esetén beszélünk végdátumról) Ha végeztünk az


22.

OK gombra kattintva elmenthetjük a bevételt, a Mégsem gomb esetén egy felugró ablak figyelmeztet bennünket, hogy biztos ki akarunk-e lépni, mert a módosításaink elvesznek. Ha megerősítjük a kilépést, akkor a bevétel módosítása meghiúsul, ha nem erősítjük meg, akkor lehetőségünk van véglegesíteni a bevétel módosítását.  Bevételtörlés: A bevétel listából kiválasztva a megfelelő eleme(ke)t, tehát akár többet is egyszerre törölhetjük azokat a költségvetésünkből. Ha a törlés opciót választjuk egy felugró ablak jelenik meg, hogy biztosan törölni szeretnénk-e az alábbi elemeket. Ha megerősítjük a döntésünket, azaz az OK gombra kattintunk, akkor törlődnek a költségvetésünkből az adatok, ha nem, tehát a Mégsem gombra kattintunk, akkor a törlés művelet meghiúsul. 3.2.3 Kategóriakezelés Mind a bevételeinket, mind a kiadásainkat kategóriákba sorolhatjuk. A kategóriák két részből állnak, főkategória és alkategória. A főkategórián belül találhatóak az alkategóriák, amik természetesen logikailag összetartoznak. A főkategóriák típussal is rendelkeznek, amik azt mutatják meg, hogy bevételhez vagy kiadáshoz rendelhetőek-e majd a főkategóriához tartozó alkategóriák. A kiadás- és bevételkezeléshez hasonló műveletek találhatóak meg a kategóriakezelésnél is.  Kategória/alkategória felvétel: Lehetőségünk van új főkategória felvételére, ami így belekerül a költségvetésünkbe. Az új főkategória gombra kattintva tehetjük ezt meg. Szükséges kitöltenünk az összes mezőt. Az OK gombra kattintva elmentjük a kategóriát, a Mégsem gombra való kattintás esetén egy felugró ablak figyelmeztet bennünket, hogy biztos ki akarunk-e lépni, mert az újonnan felvitt adataink elvesznek. Ha megerősítjük a kilépést, akkor az új főkategória felvitele meghiúsul, ha nem erősítjük meg, akkor lehetőségünk van véglegesíteni a főkategória felvételét. Az alkategória felvétele analóg módon


23.

történik, azzal a különbséggel, hogy amikor ki kell választanunk első lépésként egy főkategóriát, amihez szeretnénk alkategóriát felvenni.  Kategória/alkategória módosítás: A listából kiválasztva egy darab főkategóriát (szigorúan csak egyet) módosíthatjuk ezt. A felugró ablakban megjelennek a bevételhez tartozó adatok. Az azonosítón kívül mindent módosíthatunk. Ha végeztünk az OK gombra kattintva elmenthetjük a főkategóriát, a Mégsem gomb esetén egy felugró ablak figyelmeztet bennünket, hogy biztos ki akarunke lépni, mert a módosításaink elvesznek. Ha megerősítjük a kilépést, akkor a főkategória módosítása meghiúsul, ha nem erősítjük meg, akkor lehetőségünk van véglegesíteni a főkategória módosítását. Az alkategória módosítása analóg módon történik, kiválasztjuk a főkategóriát, amelynek egyik alkategóriáját szeretnénk módosítani, azután az alkategória módosítására kattintunk.  Kategória/alkategória törlés: A főkategória listából kiválasztva a megfelelő eleme(ke)t, tehát akár többet is egyszerre törölhetjük. Ha a törlés opciót választjuk egy felugró ablak jelenik meg, hogy biztosan törölni szeretnénk-e az alábbi elemeket. Ha megerősítjük a döntésünket, azaz az OK gombra kattintunk, akkor törlődnek az adatok, ha nem, tehát a Mégsem gombra kattintunk, akkor a törlés művelet meghiúsul. 3.2.4 Lokalizáció Lehetőség van, hogy a felhasználó különböző nyelveken használja az alkalmazást. Az elsődlegesen támogatott nyelvek a magyar és az angol. A nyelvválasztás egy „combobox” vezérlő segítéségével történik, amely a bárhonnan elérhető majd az alkalmazásban. Ha nyelvet szeretnénk váltani, kiválasztjuk a megfelelőt, azután egy információs üzenet jelenik meg, miszerint a nyelv sikeresen átállítódott, azonban, ahhoz, hogy ténylegesen érzékeljük, újra kell indítani az alkalmazást.


24.

A többnyelvűség biztosítására célszerű már a fejlesztés elején gondolni, hiszen nem nagyon találkozunk már olyan programokkal, ahol nem lehetne kiválasztani a használt nyelvet, továbbá rengeteg időt megspórolunk a későbbiek során. 3.2.5 Statisztikák Ez a funkció tekinthető a program azon részének, ahol a felvitt adatainkról kimutatásokat készíthetünk/láthatunk. Lehetőségünk van megadni kezdő és befejezési dátumot, hogy mikorra legyenek érvényesek az eredmények. Ennek a megvalósításnak köszönhetően, könnyedén láthatunk, évi, havi, heti, napi statisztikát is, attól függően, mekkora a kezdő és végdátum közötti intervallum. Az intervallum zárt, tehát mind a kezdő, mind a végdátum bevételei és kiadásai is figyelembe lesznek vége a számítás során. Természetesen láthatjuk az egyenlegünket is adott időszakra vonatkozóan. Torta, valamint oszlop diagramok teszik szemléletesebbé a megjelenített adatokat. Bővebben az 5. fejezetben lesz szó erről a témáról.

3.3 Dizájn terv A tervezés során igyekeztem egyszerű felületet kigondolni, amit a felhasználó különösebb nehézségek nélkül képes használni, de mégis biztosítja a felhasználó élményt. A különböző adatokon panelek segítségével navigálhatunk.


25.

3.3.1 Kategóriapanel A kategóriák megjelenítésénél vertikálisan kettéosztott képernyő fogad minket, ugyanis, így egyszerre láthatjuk majd a főkategóriákat és a hozzájuk tartozó alkategóriákat. Az előbbi bal oldalt, az utóbbi pedig jobb oldalt helyezkedik el. A főkategóriákat kiválasztva, a jobb oldali táblázat frissül, azaz betöltődnek a kiválasztott főkategóriához tartozó alkategóriák.

6. ábra 3.3.2 A bevételpanel és a kiadáspanel A bevételpanel szinte teljesen ugyanúgy néz ki, mint a kiadáspanel, hiszen teljesen ugyanazokra az adatokra van szükségünk, mindkettő esetén, így a felület sem igényelt nagy változtatásokat.


26.

7. ábra 3.3.3 Statisztika panel Miután elvégeztük a szükséges beállításokat a statisztika lekérdezéséhez, kör és oszlop diagramnak köszönhetően láthatjuk szemléletesebben. A diagram értelmezését szövegcímkék könnyítik majd meg.

8. ábra


27.

3.3.4 Adatok részletei ablak Amennyiben új elemet szeretnénk létrehozni, vagy meglévőt módosítani, akkor az alábbi képhez hasonló ablakkal fogunk találkozni. Értelemszerűen létrehozás esetén üres mezők lesznek jobb oldalt, módosítás esetén, pedig a módosítandó elemre vonatkozó adatok.

9. ábra

3.3.5 Megerősítő / figyelmeztető ablak Amivel még találkozhatunk, az a megerősítő ablak és a figyelmezető ablak. Amennyiben törölni szeretnénk valamilyen adatot a művelet végrehajtása előtt egy megerősítő ablak fogad minket, hogy biztosak vagyunk-e a törlésben. A figyelmeztető ablakot akkor kapjuk, ha például a módosításra kattintunk, de nem jelöltük ki a módosítandó elemet. A két típus meglehetősen hasonló, a felsőrészen található a szöveges üzenet, az alsó részen pedig a bezárásához szükséges gomb. Ezek megjelenése esetén, rögtön rájuk kerül a fókusz és csak akkor tudjuk folytatni a munkánkat, ha előtte az bezárjuk az ablakot, így lényegében ki van küszöbölve, hogy rengeteg megerősítő / figyelmeztető ablak legyen a háttérben, figyelmen kívül hagyva.


10. ábra

28.


29.

4. Az alkalmazás elkészítésének és tesztelésének leírása 4.1 Az implementáció menete Miután összeállt a specifikáció, hogy milyen funkciókkal fog rendelkezni az alkalmazás, a kódolást az adatbázis megvalósításával kezdtem. Az táblákat megvalósító osztályokat írtam meg először, amiket, mivel objektum orientált adatbázist használok különböző annotációkkal (például @Entity) kell ellátni, hogy az adatbázis API tudja, hogy az osztályok táblákként fognak funkcionálni, a belőlük létrehozott objektumok pedig a rekordok lesznek. Ezt követte az adatbázis létrehozásáért és kapcsolattartásáért felelős osztály elkészítése. Így, hogy már képes voltam adatbázis kapcsolatot létrehozni, elkezdhettem az alapvető műveleteket biztosító függvények írását. Az egyszerűbbekkel kezdtem és haladtam a bonyolultabbak felé, a rekordok létrehozása volt az első, ezt követték a lekérdezések, azonosító, név alapján valamint az összes adat visszanyerése, majd következett a törlés, végül, de nem utolsó sorban a módosítások. A függvények implementálásánál két réteget definiáltam, egy úgynevezett repository és egy service réteget. Mindkettő további két részből állt, egy csak interfészeket tartalmazó és egy megvalósítást tartalmazó részből. Ennek a lényege, hogyaz alsóbb réteg, ami jelen esetben a repository szolgáltatásokat nyújt a felette lévő service rétegnek a megfelelő interfészen keresztül. Úgy kell ezt elképzelni, mint a számítógép hálózatok területén elterjedt ISO-OSI modell paradigmája. Így lehetőségünk van arra, hogy lecseréljük az adatbázisréteget, anélkül, hogy sok helyen kellene módosítanunk a programot, hiszen, csak a legalsó réteget megváltoztatni, mivel definiált interfészen keresztül történik a működés. Az üzleti logika a service réteg szolgáltatásait hívja a felhasználó interakcióknak megfelelően, a service réteg továbbítja a kéréseket a repositorynak, és az onnan kapott választ, visszaadja az üzleti logikának. A következő lépés a felhasználói felület összerakása volt. Mivel megvoltak az osztályok, a megfelelő tulajdonságokkal, attribútumokkal, már tudtam, hogy miket kell


30.

megjeleníteni a táblázatokban. Ebből következik, hogy az is megvan, hogy új adatok felvitelénél a megjelenő ablakon milyen adatokat kérjünk be a felhasználótól. Az első lépés a kategóriákhoz majd az alkategóriákhoz tartozó felület elkészítése volt, mivel az alkategória függ a kategóriától, a bevételek és a kiadások pedig az előző kettőtől. Ezután következtek a bevételekhez és a kiadásokhoz tartozó felületek, amik szinte teljesen megegyeznek a kiadásokra vonatkozóakkal, így ott sok időt tudtam spórolni és gyorsan tudtam haladni. A felületeken megjelenő szövegcímkéket nem statikusan égettem be, hanem egy dinamikus szöveget adtam meg, ami fájlból fogja megkapni az értékét, attól függően, hogy milyen nyelven funkcionál az adott pillanatban az alkalmazás. Sajnos beleestem abba a hibába, hogy a szövegeket nem az elejétől fogva kezeltem így, ennek eredményeképpen lett egy kis plusz munkám, hogy ezt bevezessem és megvalósítsam; a jövőben már figyelek arra, hogy ilyen jellegű hibát ne kövessek el még egyszer. A felületet és rajta lévő vezérlők által a felhasználóknak lehetővé tett funkciókat úgy próbáltam meg implementálni, hogy ne úgynevezett spagetti kódot írjak. Ez alatt azt értem, hogy nem az üzleti logikát nem közvetlenül a felhasználói felület mögé írom. A modell-nézet-vezérlő (Model-View-Controller) [5] néven ismert paradigmát

alkalmaztam

a

megvalósítás

során,

amelynek

pont

az

előbb

megfogalmazott problémának a kiküszöbölése a célja. Az alábbi ábrán látható a mintának egy általános reprezentációja, azonban többféle megvalósítás is létezik, attól függően, hogy melyik mi a feladata és hogyan kommunikálnak egymással.


31.

11. ábra [5] Nézzük meg a főbb komponensek szerepét, jellemzőit. [5] A modellbe tartozik az alkalmazás állapota, valamint a különböző adatok is, beleértve az adatbázisban tároltakat is. A nézet felelős az adatok megjelenítéséért, a felhasználói felület reprezentálásáért. Az én implementációmban a vezérlő kapcsolja össze a modellt és a nézetet. A felhasználó által kiváltott események, például gombon való kattintás lekezelését a nézet továbbítja a vezérlőnek, ahol a vezérlő a kérésnek megfelelő adatokat létrehozza, módosítja vagy törli és frissíti a nézetet, ezáltal az aktuális állapot kerül a felhasználó elé. Az előbbieknek köszönhetően a nézet komponenseket könnyen be lehetne illeszteni más Java Swing alkalmazásokba, a modell pedig más hasonló logikájú Java alkalmazásokba. Manapság a robosztusság és az újrafelhasználhatóság érdekében a nagyobb rendszerek, szinte kivétel nélkül az MVC paradigma valamilyen változatát próbálják követni.


32.

4.2 Képernyőminták Mivel véget ért az implementáció, nézzük meg, hogy milyen felülete lett az alkalmazás

jelenlegi

verziójának

és

dizájntervezésben található tervekkel.

lehetőségünk

van

összehasonlítani

a

Az adatok egy generált adatbázisból

származnak, csak illusztráció jellegűek, azért, hogy lássuk, hogy hogyan helyezkednek el az adatterülethez tartozó adatok. 4.2.1 Kategória Baloldalt láthatóak a főkategóriák, amin ha kattintunk, automatikusan betöltődnek a jobb oldalon a kijelölt főkategóriához tartozó alkategóriák. Az egyes táblázatok fölött a megfelelő funkcióhoz tartozó gombok találhatóak meg.

12. ábra Létrehozás, módosítás esetén az alábbi ablakok jelennek meg a kategóriával, illetve az alkategóriával kapcsolatban. A különbség a létrehozás és a módosítás között, hogy előbbi esetén üresek a kitöltendő mezők, utóbbi eseten a módosítandó elemre vonatkozó adatok találhatók a mezőkben.


33.

13. ábra

14. ábra 4.2.2 Bevétel/kiadás Mivel a bevételpanel szinte teljesen hasonlóan néz ki a kiadáspanelhez, ezért nem lesz mindkettőről képernyőminta. A 15. ábrán látható, hogy a kategóriához hasonlóan itt is a táblázat fölött találhatóak a funkciókat biztosító gombok, azonban itt található egy szűrő rész is, ahol a megfelelő paramétereket megadva, a „checkbox”-ot bepipálva szűrhetjük az adathalmazt. A rekordokat a megjegyzés kivételével, bármelyik mezője alapján szűkíthetjük. Kiadás létrehozásánál, módosításánál pedig az 16. ábra fogad minket. Előbbi esetén üresek a kitöltendő mezők, utóbbi esetén, pedig a módosítandó elemre vonatkozó adatok töltődnek be a mezők értékéül.


15. ábra

16. ábra

34.


35.

Amennyiben úgy kattintunk a módosításra, vagy a törlés gombra, hogy egy rekordot sem jelöltünk ki, akkor a következő kép fogad minket, ugyanis nincs mit módosítani vagy törölni.

17. ábra Abban az esetben, ha több rekordot jelöltünk ki és úgy kattintunk a módosításra, akkor láthatjuk a 16. ábrán megjelenő üzenetet, ugyanis egyszerre csak egy adatot módosíthatunk. Törlés esetében nincs ilyen probléma, mivel több elemet is törölhetünk egyszerre.

18. ábra 4.2.3 Statisztika Magáról az elkészült statisztikáról lesz majd későbbi fejezetben kép, ami a program által készített kimutatás pdf formátumban való exportálásáról készült. A 19. ábrán látható a szűrő rész, valamint a megjelenített statisztika elhelyezkedése.


36.

19. ábra

4.3 Az alkalmazás tesztelése A szoftverfejlesztés egyik része a szoftvernek a tesztelés, mely során egy kontrollált környezetben futtatjuk a programot és értékeljük a kapott eredményeket, hogy megfelelnek-e az elvárásoknak. A hagyományos megközelítés szerint a tesztelés fő célja, hogy a hibákat minél hamarabb megtaláljuk, ezáltal csökkenjen, azok kijavításának a költsége. [10] Az elsődleges teszt, amit készítettem az úgynevezett komponens teszt (Unit Testing). Ennek lényege, hogy egy meghatározott funkcionalitást ellenőriz, hogy megfelelően működik-e. Az ellenőrzés a „fehér doboz” módszerrel történik, ahol ismerjük a struktúra felépítését, ellentétben a „fekete doboz” módszerrel, ahol az egyes megadott inputokra kapott outputok alapján próbáljuk kitalálni a belső működést. Ehhez a tesztelés a Java világában közismert JUnit-ot használtam, ami egy egyszerű, nyílt forráskódú keretrendszer, ami lehetővé teszi, hogy írjunk és futtassunk ismételhető teszteket. [11] Jellemzői:  „Kikövetelhetjük” az elvárt eredmény,  bővítmények, lehetőségek, hogy megosszuk a gyakori teszt adatokat,


37.

 a tesztek futtatásához környezet biztosítása. A következő képen láthatjuk, hogy az általam írt komponens teszteknek mi lett az eredménye. 30 körüli teszt készült és abból mind sikeresen lefutott. Egyik hasznos tulajdonsága ennek a fajta tesztnek, hogy ha új funkciót implementálok, és azután lefuttatom őket, kiderül, hogy az új funkcionalitás befolyásolta-e az eddigi működést. Ebből kifolyólag, ha egy új rész implementálása elkészült, lefutattam a teszteket, hogy megtudjam elrontottam-e valamit, vagy minden megfelelő maradt.

20. ábra Elsősorban az adatbázis műveletek álltak a tesztek központjában, mivel azokat tartottam az egyik legfontosabbnak. Például a létrehozás funkcióra vonatkozó teszt abból áll, hogy miután létrehoztam és beszúrtam a rekordot a táblába, lekérdezem az adatbázisból és megnézem, hogy visszakapom-e az imént beszúrt rekordot. További tesztelés közé tartozott az alfatesztelés, amit általában a fejlesztő végez a kódírás közben, tehát jelen esetben én. Ha úgy éreztem, hogy elkészültem egy


38.

funkcióval, akkor ellenőriztem, hogy azt implementáltam-e, amit szerettem volna, valamint, hogy úgy működik-e ahogy azt elvárom. Az ebben a fázisban felmerülő hibák okára gyorsan rájöttem, hiszen benne voltam a gondolatmenetben, viszont a javítás nehézsége sokszor változó volt. Például sok olyan hibát találtam, hogy a felületen megjelenő szövegcímkékkel probléma volt, aminek az volt az oka, hogy elgépeltem a fájlban lévő szövegkulcsok értékét és így nem egyezett a felületre kivezetett névvel. Amikor véget ért az alfatesztelés fázisa, befejeződött az implementáció, akkor következett a béta teszt. Két barátomat kértem fel erre a feladatra, egy programtervező informatikus és egy gépészmérnök hallgatót. Előbbi, mivel szakmabeli, tudja, hogy mik lehetnek a potenciális hibák, könnyen rálát a területre, utóbbi, mivel valamilyen szinten laikus, olyan dolgokat is kipróbálhat, ami nem jutnának a fejlesztők eszébe. Nekik köszönhetően derült ki, hogy új kategória vagy alkategória felvétel esetén, vagy meglévő törlése, illetve módosítása esetén, a szűrőfelület részén nem frissülnek a válaszható kategóriák, alkategóriák. Ez a kisebb problémák közé tartozott, hiszen az adott művelet végrehajtása után újra le kellett kérdezni az adatokat az adatbázisból és feltölteni a paneleket, hogy az aktuális adatok jelenjenek meg. Egy másik probléma volt, hogy ha olyan kategóriát, alkategóriát akartak törölni, ami már függött valami adattól, bevételtől esetleg kiadástól, akkor a program összeomlott, ugyanis kivétel keletkezett és erre nem volt felkészítve.


39.

5. Statisztikák megjelenítése Egy korábbi fejezetben, már érintőlegesen volt szó, erről a funkcióról, most ez egy picit bővebben ki lesz fejtve. A program egyik fő modulja, hogy lehetősége van a felhasználónak

felvitt

adatokból

igényeinek

megfelelő

kimutatást

készíteni.

Tulajdonképpen ez az alkalmazás legértékesebb része, a lefejlesztésének az értelme. Az adataink a bevételekre és a kiadásokra épülnek, amelyek kategóriákba, azon belül alkategóriákba vannak rendezve. A bevételekhez és a kiadásokhoz tartozik még időpont is, ami egy fontos szerepet játszik majd. A statisztika készítés első lépése, hogy átgondoljuk, konkrétan mire is vagyunk kíváncsiak. Ha ez megvan, akkor a paramétereket meg kell adni a felületen. A dinamikus lekérdezésnek köszönhetően, szinte bármilyen kimutatást készíthetünk, nincsenek kizárólag előre beégetett lekérdezések. Két fő részből áll a paraméterezés. Az első az időpont, ahol beállíthatjuk, hogy mettől meddig vagyunk kíváncsiak az adatokra, ennek köszönhetően könnyen láthatunk napi, heti, havi kimutatásokat, attól függően, hogy mekkora intervallumot állítottunk be. Fontos megjegyezni, hogy nyílt intervallumról van szó, tehát a megadott időpontok már nem lesznek benne a lekérdezett adatokban; a kezdődátumtól egy nappal későbbi adat már igen, a végdátumtól egy nappal korábbi adat szintén igen. A második rész nem az adatok időbeliségét, hanem a típusát célozza meg. Lenyíló vezérlőkkel választhatjuk ki, mire van szükségünk. Az első ilyen vezérlő azt tartalmazza, hogy bevételre szeretnénk statisztikát, vagy kiadásra, vagy mindkettőre. Amennyiben a mindkettőt választjuk, az azt jelenti, hogy az adott időszakra vonatkozóan fogja összehasonlítani a kiadásokat és a bevételeket a program. Ebben az esetben a következő vezérlő, amely a kategóriákra vonatkozik, automatikusan deaktiválódik. Ha a bevételre, vagy kiadásra kattintunk a kiválasztáskor, akkor a választásunktól függően a kategóriákat tartalmazó vezérlőbe betöltődnek a vagy a bevételekhez vagy a kiadáshoz tartozó kategóriák, plusz még egy lehetőség, az „összes” elnevezésű címke.

Amennyiben az összest választjuk ki a második

vezérlőből, úgy láthatjuk majd az adott idő intervallumra vonatkozóan, a bevétel vagy


40.

kiadás összegét kategóriákra csoportosítva. Amennyiben nem az „összes” nevű lehetőséget választjuk ki, hanem egy speciális kategóriát, akkor megtekinthetjük az kiválasztott

bevétel

vagy kiadás

kiválasztott

kategóriájához

tartozó

összes

alkategóriához tartozó összegeket, azaz, hogy adott alkategóriánként mennyi bevételünk vagy kiadásunk van. Miután a paraméterezés megtörtént az eredményt a két leggyakoribb ábrázolási módban megtekinthetjük, ami nem más, mint a torta, valamint az oszlop diagram. Kinek melyik tetszik jobban, melyiket látja át jobban, azt használja. Az alábbi képeken látható, hogy milyenek valójában a diagramok, azonban fontos megjegyezni, hogy a képen nem mérethűek, az alkalmazásban más méretarányban jelennek meg. Ha szeretnénk, megkaphatjuk az képen látható méretarányokkal is a diagramokat is, ugyanis jobb egérgombbal kattintva az alkalmazásban a diagramon exportálhatjuk, kinyomtathatjuk pdf, xps vagy png formátumban. Az ábrákhoz tartozó kiadás és bevételadatok nem egy létező háztartás adatai, hanem általam felvitt adatok a szemléltetés és tesztelés kedvéért, azonban ezek a számadatok fiktívség ellenére a valóságnak is megfelelőek lehetnek. A kategóriákhoz [12] is igyekeztem a mindennapjainkban előforduló dolgokat keresni.


5.1 Kiadások kategóriánként - kördiagram

21. ábra

41.


5.2 Kiadások kategóriánként - oszlopdiagram

22. ábra

42.


43.

6. Összefoglalás A dolgozat megírásával és az alkalmazás elkészítésével a háztartások költségnyilvántartását próbáltam megkönnyíteni. Napjaink felgyorsult világában központi szerepet tölt be a pénz, az elvégzett munkánkért fizetést kapunk, amit a fogyasztói társadalom révén részben elköltünk, részben megtakarítunk. Sajnos az emberek nagy része, nincs tisztában a pénzügyeinek legalapvetőbb dolgaival; például nem tudják hova úszik el a fizetésük, holott rengeteg felesleges, impulzus alapú költekezéssel rendelkeznek. [1] Ezt a problémát szerettem volna megoldani, úgy, hogy legyen egy program, aminek segítségével vezetni lehet a bevételeinket és a kiadásainkat lehetővé téve az adatok visszamenőleg való megtekintését. A dolgozat első részében a különböző típusú kliens alkalmazások kerülnek ismertetésre, az önálló alkalmazásoktól kezdve, a kliens szerver alkalmazásokon át, a többrétegű alkalmazásokig, hogy lássuk milyen lehetőségek voltak a program architektúrájának kialakítására. A következő fejezet már a konkrét tervezésről szól. Az adatbázis tervezésben láthatjuk a tárolandó adatok struktúráját, azt, hogy az egyes objektumoknak milyen tulajdonságait tároljuk. A funkcionális tervezés - ahogyan a nevei is jelzi – az alkalmazás által kínált funkciókat, szolgáltatásokat mutatja be, amelyet a felhasználó igénybe tud venni. A dizájn tervezés a program kinézetét határozza meg, a különböző vezérlők, valamint a megjelenített adatok pozícióját. Az alkalmazás elkészítésének leírásában megtekinthetőek az egyes lépések kronológiai sorrendben, amelyek elvezettek a program végállapotához. A fejlesztés során sokszor nehézségekbe ütköztem egyes funkciók implementálása során, ilyenkor, ha többszöri próbálkozás utána sem jutottam eredményre, más megoldáshoz folyamodtam. A tesztelésről szóló fejezetben, egyrészt hangsúlyozom mennyire is fontos egy szoftver tesztelése, hogy biztosak legyünk a megfelelő működésben, másrészt a tesztelést segítő osztálykönyvtárak is bemutatásra kerülnek. A statisztikák jelentik az addig felvitt kiadásokból és bevételekből generált eredményeket. Ez az alkalmazás kulcspontja lényegében, ahol a grafikonoknak,


44.

ábráknak köszönhetően sokkal szemléletesebben láthatjuk a bevételeinket és kiadásainkat, mintha egy sok soros táblázatot látnánk. Az általam meghatározott célokat (véleményem szerint) kielégítően meg tudtam valósítani, ugyanis elkészült egy alkalmazás, amely lehetővé teszi, hogy dokumentáljuk a költségeinket és a bevételi forrásainkat, ennek köszönhetően tudatosabban közelíthetjük majd meg a pénzügyeinket, bár a program még messze van a tökéletestől. További fejlesztési lehetőségek közé sorolható, mondjuk egy büdzsé funkció, ahol kategóriánként meghatározhatnánk egy limitet, ami fölé nem költekezhetünk egy adott időszakban. A szakdolgozat és a program készítés során megismerkedtem az objektum orientált adatbázis rejtelmeivel, azt is megtanultam, hogy kell látványos ábrákat készíteni külső osztálykönyvtár segítségével. Tisztában vagyok vele, hogy zajlik az elejétől egy alkalmazás elkészítése már nem csak elméleti, hanem gyakorlati szinten is. Végül, de nem utolsó sorban szeretnék köszönetet mondani témavezetőmnek Szűcs Miklós mérnöktanárnak a közvetlen segítőkészségéért és iránymutatásaiért, úgy érzem sokat sikerült szakmailag fejlődnöm a közös munkánk során.


45.

7. Summary With my thesis, I wanted to make households’ financies easier. Nowadays, in this continuously accelerating world, money has a central role in our daily lives, we get salary for our work, that we partly spend and partly save. Unfortunately, most people are not fully aware of their issues in connection with money, for instance they do not know exactly what they spend money for, however they have a lot of impulse and unnecessary spending. This is the problem, I wanted to solve with implementing a program which can store and handle incomes and expenses. In the first chapter of my thesis, different type of applications can be read such as standalone applications, client-server applications and multilayered applications to show how the various architectures can be structured. The next chapter is about the planning. In the database planning, we can see the structure of the data that we storeand the properties of the objects. Functional planning contains the features offering by the application. Design planning defines the user interface of the software for example the positions of the controls and data which will be displayed. In the chapter about implementing the software, you can see the different steps which lead to the application’s current version. After that I write some thoughts about the importance of testing and the different libraries I used to test the functionality. Statistics show generated results from the incomes and expenses, where we can see nice pie and bar charts. In my esteem, I achived my goals, since the application is done and enable to monitor incomes and expenses. Due to this, we can be aware of our issues about money more precisely, however the application is not perfect and can contain several new functions. For example, a budget feature can be implemented which will be responsible for defining an expense limit based on various categories that cannot be stepped across.


46.

During writing my thesis, I could get acquainted with the secrets of object oriented database, and I also know how to display intuitive charts with usage of external libraries. Last but not least, I would like to say a big thanks to Miklós Szűcs for his direct help and support, I feel I gain a lot of experience during our work.


47.

8. Felhasznált irodalom 8.1 Internetes hivatkozások [1] Kiszámoló – Egy blog a pénzügyekről http://kiszamolo.hu/mennyibe-kerul-a-croissant/(letöltve: 2014.09.30)

[2] Webadatbázis – programozás http://ade.web.elte.hu/wabp/lecke1_lap1.html(letöltve: 2014.10.02) http://ade.web.elte.hu/wabp/kepek/01_architektura_w650.jpg (letöltve: 2014.10.02) http://ade.web.elte.hu/wabp/kepek/02_architektura_w650.jpg (letöltve: 2014.10.02) http://ade.web.elte.hu/wabp/kepek/03_architektura_w650.jpg (letöltve: 2014.10.02) [3] Wikipedia – Standalone software http://en.wikipedia.org/wiki/Standalone_software(letöltve: 2014.10.05) [4] Wikipedia – Kliens-szerver architektúra http://hu.wikipedia.org/wiki/Kliens-szerver_architekt%C3%BAra (letöltve: 2014.10.05) [5]

MVC

modell

-

http://hu.wikipedia.org/wiki/Modell-n%C3%A9zet-

vez%C3%A9rl%C5%91(letöltve: 2014.11. 04) http://upload.wikimedia.org/wikipedia/commons/3/3e/MVC_Diagram_3.jpg [6] Wikipedia – Többrétegű architektúra http://hu.wikipedia.org/wiki/T%C3%B6bbr%C3%A9teg%C5%B1_architecht%C 3%BAra(letöltve: 2014.10.05) [7] Adatbázis tervezés lépései http://users.atw.hu/csermajor/x3/szamitogepterem/tudnikell/e_4.htm (letöltve: 2014.10.11) [8] Adatbázis típusok


48.

http://www.tankonyvtar.hu/hu/tartalom/tamop425/0033_SCORM_MFGGT6002/sco_0 6_02.htm(letöltve: 2014.10.14) [9] ObjectDB - Objektum orientált adatbázis http://www.objectdb.com/object/db/database/overview(letöltve: 2014.10.15) [10] Szoftvertesztelés - http://en.wikipedia.org/wiki/Software_testing (letöltve: 2014.11. 04) [11] JUnit - http://junit.org/faq.html#overview_1 (letöltve: 2014.11. 04) [12] Kiszámoló – Egy blog a pénzügyekről – Az alkalmazás tesztadatbázisának kategóriái http://kiszamolo.hu/tartsd-kezben-a-penzugyeidet/(letöltve: 2014.10.18) http://kiszamolo.hu/koltsegvetes.xls(letöltve: 2014.10.18)

Szakdolgozat. Költségnyilvántartó program háztartások részére. Miskolci Egyetem Gépészmérnöki és Informatikai Kar Általános Informatikai Tanszék

Recommend Documents