A piac által vezérelt vegyes gazdaság modellje az Egyesült Államok példáján
Esemény vezérelt tesztelési folyamat informatikai ...
Transcript of Esemény vezérelt tesztelési folyamat informatikai ...
Miskolci Egyetem
Gépészmérnöki és Informatikai Kar
Informatikai Intézet
Alkalmazott Informatikai Intézeti Tanszék
3515 Miskolc-Egyetemváros
Szakdolgozat
Feladat címe
Esemény vezérelt tesztelési folyamat informatikai támogatásá-
nak megvalósítása
Készítette:
Kovács Alex Pál
Témavezető:
Szabó Martin
egyetemi tanársegéd
Miskolci Egyetem Informatikai Intézet
Alkalmazott Informatikai Intézeti Tanszék
Miskolci Egyetem, 2020
Esemény vezérelt tesztelési folyamat informatikai támogatásának
megvalósítása
2
SZAKDOLGOZAT FELADAT
Kovács Alex Pál
Neptunkód: KS14RL
BSc mérnök-informatikus jelölt részére
A tervezés tárgyköre: Termelésinformatika
A feladat címe:
Esemény vezérelt tesztelési folyamat informatikai támogatásának
megvalósítása
A feladat részletezése:
1. A szakdolgozat célja egy olyan hordozható és platformfüggetlen szoftver
kifejlesztése, amely a különböző speciális PLC nyelvek megtanulása nélkül
lehetővé teszi a PLC programok készítését és kezelését.
2. Szakirodalmi elemzés alapján ismertesse az esemény vezérelt tesztelést, továbbá
a feladat szempontjából releváns PLC berendezéseket és programozási
nyelveket.
3. Keressen egy olyan általános leíró meta-nyelvet, amely segítségével a PLC
nyelvek közötti különbségek elfedhetők!
4. Készítsen egy olyan alkalmazást, amely képes az eltérő gépek eltérő PLC
programozási nyelveinek kezelésére!
5. Készítse fel az alkalmazást az utasítások ciklikus végrehajtására. Ha a vezérlés
nem támogatja, akkor „loop-unrolling” technikát megvalósítsa meg.
6. Készítése el az alkalmazás Android operációs rendszerre is!
7. Készítsen grafikus felhasználói felületet mind a két szoftverhez!
Tervezésvezető: Szabó Martin Alkalmazott Informatikai Intézeti Tanszék egyetemi tanársegéd
Konzulens:-
A diplomaterv kiadásának időpontja:
2020.01.20.
A diplomaterv beadásának határideje:
2020.04.30.
Miskolc, 2020.01.20.
Dr. Nehéz Károly
tanszékvezető, egyetemi docens
Miskolci Egyetem Gépészmérnöki és Informatikai Kar
Alkalmazott Informatikai
Intézeti Tanszék 3515 Miskolc-Egyetemváros
Szak : Mérnök-informatikus Azonosító szám: GEIAK-NK-01/2019-20-2f/BSc
Szakirány: Termelésinformatikai Intézményazonosító: FI 87515
Tartalomjegyzék
1. Bevezetés ......................................................................................................................................... 2
2. Feladat részletezése ......................................................................................................................... 3
3. Előzmények ..................................................................................................................................... 5
3.1. PLC – Programozható Logikai Vezérlők ................................................................................... 5
3.2. Java .......................................................................................................................................... 8
3.3. Eclipse ...................................................................................................................................... 9
3.4. JavaFX .................................................................................................................................... 12
3.5. Scene Builder ......................................................................................................................... 13
3.6. Android Studio ....................................................................................................................... 14
3.7. Maven .................................................................................................................................... 15
3.8. Gradle .................................................................................................................................... 16
3.9. MVC- Model View Controller ................................................................................................ 17
3.10. Java Script Object Notation ................................................................................................... 18
3.11. Comma Separated Value ....................................................................................................... 20
4. Rendszertervezés ........................................................................................................................... 21
5. Működés leírása ............................................................................................................................. 27
5.1. Asztali számítógépes alkalmazás ........................................................................................... 27
5.2. Android operációs rendszert futtató mobil alkalmazás ........................................................ 31
6. Tesztelés ........................................................................................................................................ 35
6.1. Manuális tesztelési folyamat ................................................................................................. 35
7. Továbbfejlesztési lehetőségek ....................................................................................................... 36
Összegzés .............................................................................................................................................. 38
Summary .............................................................................................................................................. 39
Irodalomjegyzék, hivatkozások .......................................................................................................... 41
1. Bevezetés
A megnövekedő piaci igények, előírások és korlátozások következtében a termékek tesz-
telésére a vállalatok egyre nagyobb hangsúlyt fektetnek. Ennek eredményeképpen ezen válla-
latok tesztberendezéseinek palettája szélesedik, így az új gépek használatához megfelelő szak-
értelem szükséges, amelyet legtöbb esetben új munkaerő bevonásával vagy a cégnél elhelyez-
kedő munkavállalók képzésével elégítenek ki.
A követelmények egyszerűbb kivitelezése érdekében a feladat egy olyan alkalmazás el-
készítése a Starters E-Components Generators Automotive Hungary Kft. számára, amely lehe-
tőséget ad az esemény vezérelt tesztelés bevezetésére, oly módon, hogy az alkalmazható legyen
a vállalatnál található valamennyi tesztberendezés programozása során, az eddig használt idő
alapú tesztelési folyamat megtartásával. A programmal szemben további követelmény, hogy az
egyszerűen kezelhető és könnyen értelmezhető legyen bármely személy számára, ezzel is csök-
kentve a feladat betanulásával keletkező közvetlen és közvetett költségeket.
A szoftverrel szemben állított elvárás, hogy biztosítani kell az alkalmazás könnyű kezel-
hetőségét, átláthatóságát. Alkalmazhatónak kell lennie mind asztali számítógépen, mind And-
roid operációs rendszert futtató mobil platformon úgy, hogy a két elkészített alkalmazás közötti
különbözőségek ne befolyásolják a felhasználót a tesztek elkészítésének sikerességében. A
szoftver használhatóságának nem szabad függnie a felhasználó személy programozásban szer-
zett előzetes ismereteitől. Az alkalmazás segítségével előállított kimenet formátumának alkal-
mazhatónak kell lennie a vállalatnál található valamennyi tesztelést végző berendezés progra-
mozása során. Nem utolsó sorban biztosítani kell a felhasználó számára, hogy olyan tesztbe-
rendezésekre való tesztszekvencia készítésekor is a tesztprogramhoz adhasson ciklusokat, ame-
lyek alapvetően nem kezelik azokat.
2. Feladat részletezése
A szoftver alapvető követelménye, hogy az applikáció által előállított kimenetnek alkal-
mazhatónak kell lennie a szervezetnél található valamennyi tesztelésért felelős berendezés
programozása során. A tesztszekvenciákat készítő személynek ne kelljen programozói ismere-
tekkel, automatizálási háttértudással rendelkeznie, tehát bármely laikus felhasználó számára is
könnyedén értelmezhető és igénybe vehető legyen.
A könnyebb és rugalmasabb használhatóság érdekében az alkalmazásnak Android operá-
ciós rendszert futtató mobil platformon is kényelmesen és könnyedén alkalmazhatónak kell
lennie, így hibásan megírt tesztszekvencia esetén akár a tesztelésért felelős berendezés közvet-
len környezetéből is javítható legyen.
Kulcsfontosságú kritérium, hogy a programnak használhatónak kell lennie Android ope-
rációs rendszert futtató mobil platformon is. Ezen okból kifolyólag az alkalmazás kivitelezésé-
hez a Java nyelv bizonyult a legmegfelelőbbnek Az asztali számítógépre elkészített alkalmazás
létrehozása során implementált algoritmusok döntő többsége így lényeges tartalmi változtatá-
sok nélkül alkalmazhatók a mobil applikáció megvalósítása során is.
A szoftver Java nyelven íródott összetevői az Eclipse EE nevű integrált fejlesztőkörnye-
zetének segítségével kerültek megvalósításra. Az implementálás során fontos tényező volt,
hogy az alkalmazás valódi üzemi/üzleti környezetben való alkalmazása során a felhasználóknak
új funkciókra, hibajavításokra lehet szükségük. A szoftver felépítésnél egy, a szoftvertervezés-
ben használt MVC (Model – View- Controller) elnevezésű tervezési minta szolgált az alkalma-
zás alapjául. Ennek köszönhetően az idő haladtával a szoftvert karbantartó egyéb személyek
számára is jól strukturált, ezáltal könnyen értelmezhető és módosítható legyen.
Tervezési lépések
A szoftverfolyamat tervezési fázisának első lépéseként az elkészítendő alkalmazás fő
funkcióinak kategorizálására került sor, melynek folyamán a partnercég által specifikált köve-
telmények kerültek kiegészítésre annak érdekében, hogy az alkalmazás könnyen kezelhető és
egyszerűen alkalmazható legyen.
A fő funkciók megtervezésére egy úgynevezett UML (Unified Modeling Language) nevű
szabványosított, általános célú modellező nyelv került igénybevételre a vizuális dokumentáció
könnyű áttekinthetőségének érdekében.
A funkcionális követelmények meghatározását követően az alkalmazással szemben állí-
tott nemfunkcionális követelmények meghatározására került sor. Ezek olyan követelmények,
melyek nem közvetlenül a rendszer specifikus funkcióival foglalkoznak. Ekkor kerültek meg-
határozásra olyan követelmények, mint a grafikus felhasználói felületnél használt színek, a tesz-
telő berendezések sajátosságait tároló fájl formátuma, az alkalmazás nyelve, valamint az alkal-
mazás telepíthetőségének elhagyása.
3. Előzmények
3.1. PLC – Programozható Logikai Vezérlők
A PLC azaz a programozható logikai vezérlő egy olyan mikroprocesszorral ellátott, vil-
lamos energiával működtetett szabályzó és irányító berendezés, amely nem tekinthető számító-
gépnek. Eredetileg az autóiparban található régi relés vezérlők leváltására alkották meg, azon-
ban napjainkban szinte kivétel nélkül minden iparágban megtalálható [10]. Történetük egy Ge-
neral Motors nevű cég által 1968-ban kiírt pályázat folyamán kezdődött, melynek két pályázója
a MODICON és az ALLEN-BRADLEY voltak. A pályázat során a kidolgozott koncepciónak
az alábbi szempontoknak kellett megfelelni:
• Egyszerű moduláris felépítés
• Ne tartalmazzon mozgó alkatrészeket
• Egyszerűen programozhatónak és újra programozhatónak kell lennie
• Valós idejű működés
• Magas fokú megbízhatóság
• Galvanikusan leválasztott ki- és bemenetek
• Minimális karbantartás
• Versenyképes ár
Az 1969-es évben megjelent az első Richard Morley és Odo J. Struger által tervezett Mo-
dicon 084 elnevezésű első berendezés. Morley ellenezte a computer kifejezést, mivel a szerke-
zetet elektronikai szakembereknek szánta, akiket akkoriban elriasztott volna a használattól a
használattól a computer szó [12]. A konstrukció először az autóiparban került először felhasz-
nálásra az 1970-es évek elején, amely később több változáson ment keresztül, így legfontosabb
jellemzői csak az 1980-as évek közepére alakultak ki.
A programozható logikai vezérlő (Programmable Logical Controller) az iparban széles
körben elterjedt mikroprocesszorral ellátott, programozható vezérlő rendszer, amely akár több
vezérlési feladat ellátására is képes. Ezen tulajdonsága a technológia fejlődésének szempontjá-
ból fontos, tehát ha egy termék gyártási technológiája változik ne legyen szükség új vezérlő
beruházására, hanem elegendő a vezérlő átprogramozása vagy esetleges bővítése/átalakítása az
új gyártási technológia igényeinek megfelelően.
A vezérlőket megvalósításuk szerint három kategóriába sorolhatjuk:
• Kompakt: A berendezést felépítő elemek egy egységben vannak azonban, ha a ki- és
bemenetek száma nem lenne elegendő, akkor ezek száma akár bővíthető is. A tápegy-
séget általában nem tartalmazza, ezért működtetéséhez külső 24V-os DC tápegység
szükséges.
• Moduláris: Többnyire ez a kivitelezési forma jellemző a napjainkban használatos PLC
berendezések körében, előnye, hogy felépítésük modulokból történik, így felhasználói
igény szerint, könnyedén bővíthető, alakítható. Nagy és közepes méretű folyamatok ve-
zérlésére fejlesztették ki. Annak okán, hogy a konfigurációt a felhasználó állítja össze a
modulok különbözhetnek, akár teljesítményt, akár buszok szabványit tekintve
• Mikro PLC-k (intelligens relék): kis méretű nem bővíthető, egyszerűen általában grafi-
kus felületen programozható, nem bővíthető PLC berendezések
A PLC berendezések kivitelezésüktől függetlenül hasonló felépítésűek, melyeknek fon-
tosabb építő elemei [3]:
• központi logikai egység CPU (Central Processor Unit)
• memóriaegység:
o programmemória (EPROM, EEPROM, FlashROM)
o adatmemória (RAM)
• bemeneti illesztő egység (Input Unit)
• kimeneti illesztő egység (output Unit)
• kommunikációs egység
• számláló és időzítő egység
• tápegység
A berendezések előnyei, hogy:
• alacsony költségűek,
• gyors válaszidővel rendelkeznek
• egyszerűen, gyorsan programozhatók,
• univerzálisak, különböző feladatok ellátására alkalmasak
• ellenálóak az iparban fellelhető ártalmakkal, mechanikai hatásokkal szemben
Hátrányai:
• Különböző gyártók, különböző programozási nyelvek
• Használatukhoz PLC programozási háttérismeretek szükségesek
Az 1. táblázatban látható az IEC 61131-3:2003 vagy MSZ-EN 61131-3-2003 szabvány,
amely meghatározza a PLC-k kötelező programozási nyelveit [1].
1. Táblázat: IEC 61131-3:2003 szabvány [1]
Leírás Angol rövi-
dítés
Német rövi-
dítés Megjelenítés Megjegyzés
Utasításlista IL AWL karakteres
Egyszerű sorszámozott utasításo-
kat, címeket, konstansokokat tar-
talmaz
Létradiagram LD KOP grafikus
Olyan, mint egy elektromos kap-
csolási rajz, amely 90⸰-kal el van
forgatva
Funkcióblokk diag-
ram FBD FBS grafikus
Logikai szimbólumokat tartalmaz,
különösen a Boole-algebrai felada-
tok megoldásához jó
Strukturált szöveg ST ST karakteres
Hasonló, mint a magas szintű prog-
ramozási nyelvek (C, Pascal,
Basic)
Sorrendi folyamat-
ábra SFC AS grafikus
Egyfajta összetett folyamatábra
(Grafcet)
1. ábra: PLC programozási eljárások osztályozása [2]
A PLC-k fejlesztése folyamán a gyártók számos különböző programozási nyelvet fejlesz-
tettek ki. Napjainkban a nagy mennyiségű, széles körben elterjedt különböző PLC programo-
zási nyelvből kifolyólag az eszközök között kompatibilitás lehetetlenné vált. Ennek következ-
tében megnőtt az igény mind a gyártók, mind a felhasználók részéről a nemzetközi szabványban
rögzített programnyelvek kifejlesztésére. Az IEC 1131-3 számú nemzetközi szabvány az egész
világra egységesíteni kívánja a felhasználói programnyelveket és ezek jelöléseit. A szabvány
nem új programozási nyelveket ír le, hanem a meglévő nyelveket egyesíti közös tulajdonságaik
alapján.
A programvezérlés egy lépésenként haladó vezérlés. Az egyikről a következőre lépés
egy feltétel beteljesülésének feltételének teljesülésének függvényében következik be. Ezt lefutó
vezérlésként is nevezik, amely további két csoportra bontható.
• Az idővezérelt lefutó vezérlés egy olyan programvezérlés, ahol a léptetési feltétel
kizárólag időfüggő.
• A folyamatvezérelt lefutó vezérlés során a léptetési feltétel csak a vezérelt beren-
dezés folyamatainak jeleitől függ. A vezérlőprogram lépésekre bontható. A vezé-
relt folyamat (a vezérlőprogram) lépésekre bontható, az egyik lépésről a követ-
kező lépésre történő továbbhaladás feltételekhez – a léptetési feltételekhez – kö-
tött.[11]
3.2. Java
A Java egy erősen típusos, interpretált, egyszerű, elosztott, platformfüggetlen, objektum-
orientált, C/C++ szerű programozási nyelv, amelyet a Sun Microsystems fejlesztett ki 1991-
gyel kezdődően a Green Project részeként, majd először 1995 novemberében jelent meg. A
céget 2009-ben felvásárolta az Oracle, ennek köszönhetően a Java 1.7-es verziója már ezen
vállalat neve alatt került kiadásra 2011-ben. A Java azonban nem csak programozási nyelv,
hanem egy platform is, melynek futtatásához nem elegendő a forráskód és a fordító.
A Java platform két részből áll:
• Java VM (Java Virtual Machine): a Java programozási nyelvhez készített virtuális gé-
peket nevezik JVM-nek, melynek alapvető feladata a platformfüggetlen Java bájtkód
futtatása. Ennek forrása általában Java nyelvűek, azonban léteznek olyan fordítók, ame-
lyek más programnyelvek forrását fordítják Java bájtkódra.
• Java API: több ezer használatra kész csomagokba szervezett osztály és interfész. Ennek
háromféle típusát különböztetjük meg:
o Hivatalos Java API, amelyet a JDK vagy a JRE tartalmaz
o Hivatalos API-k, amelyek külön adhatók hozzá, később az alap API-k részét is
képezhetik (pl.: Swing)
o Third party- nem hivatalos API-k
2. ábra: Java platform felépítése
A fordítás során a fordító egy úgynevezett bájtkódot állít elő, amely nem natív, de ellen-
őrzésen átesett kód. A natív kód egy olyan kód, amely közvetlenül a hardveren futtatható, így
értelemszerűen a Java kód valamivel lassabb. A Java számtalan eszközön megtalálható,
amelyre már elkészítették az adott hardverhez köthető JVM-et, ebből kifolyólag ugyan az a
programkód több különböző eszközön is futtatható akár az eredeti program változtatása nélkül
is.
A platformfüggetlenség vagy multiplatform fogalma azokra a szoftverekre, operációs
rendszerekre vagy programozási nyelvekre vonatkozik, amelyek különböző hardvereken való
futás közben is ugyanúgy működnek. Ennek elérésére a Java fordítója az egyes programok for-
ráskódjait byte-kódra fordítja le, amelyet később az aktuális hardveren található JVM (Java
Virtual Machine) értelmezi, majd fordítja a saját natív kódjára. Léteznek olyan Java fordító-
programok, amelyek feláldozva a Java program platformfüggetlenségét a forráskódot közvet-
lenül natív kódra fordítja így növelve annak futásának sebességét.
3.3. Eclipse
Az Eclipse egy nyílt forráskódú, platformfüggetlen integrált fejlesztői környezet, amelyet
eredetileg az IBM fejlesztett ki. Jelenleg az Eclipse Foundation nevű nonprofit konzurcium
kezeli. Széles körben elterjedt, nem hibátlan, de jelenleg is élő, folyamatosan javuló projekt.
2006 óta az alapítvány kezeli a szoftver éves kiadásait.
Az Eclipse egy úgynevezett Rich Client Platform alapú integrált fejlesztői környezet,
melynek komponensei:
• Core platform: Eclipse indítása, pluginek futtatása
• OSGi: Szabványos kötegelő keretrendszer
• Standard Widget Tookit: hordozható widget eszköztár
• JFace: fájl bufferek, szövegszerkesztők, szövegkezelés
• The Eclipse Workbench: szerkesztők, nézetek, perspektívák, varázslók, eszköztárak tár-
háza
A fejlesztői környezet grafikus felhasználói felülete sok AWT-t vagy Swinget használó
Java alkalmazással ellentétben az IBM által kifejlesztett Standard Widget Toolkit (SWT), va-
lamint a JFace-t használja köztes GUI rétegként így egyszerűsítve az SWT alkalmazások kivi-
telezését [7].
Az alap lehetőségek mellett további RCP-re telepíthető pluginokba szervezve található
funkciók telepíthetőek, valamint a szükséges pluginek beszerzésével további programnyelvek
támogatására van lehetőség.
Az Eclipse IDE szabadon felhasználható teljesen ingyenesen igénybe vehető környezet,
ezért esett erre a környezetre a választás, azonban annak, aki fizetős szolgáltatásokat, kereske-
delmi forgalomba hozott pluginokat kíván üzemeltetni, annak az IBM részére jogdíjat köteles
fizetni.
2. táblázat: Az Eclipse eddig megjelent kiadásai [7]
Kódnév Dátum Platform verzió Projektek
Photon 2018. június 27. 4.8 Photon projektek
Oxygen 2017. június 28. 4.7 Oxygen projektek
Neon 2016. június 4.6 Neon projektek
Mars 2015. június 24. 4.5 Mars projektek
Luna 2014. június 25. 4.4 Luna projektek
Kepler 2013. június 26. 4.3 Kepler projektek
Juno 2012. június 27. 4.2 Juno projektek
Indigo 2011. június 22. 3.7 Indigo projektek
Helios 2010. június 23. 3.6 Helios projektek
Galileo 2009. június 24. 3.5 Galileo projektek
Ganymede 2008. június 25. 3.4 Ganymede projektek
Europa 2007. június 29. 3.3 Europa projektek
Callisto 2006. június 30. 3.2 Callisto projektek
Bravo 2005. június 28. 3.1
Austin 2004. június 21. 3.0
Az Eclipse fejlesztői környezet előnyei az IntelliJ IDEA-val szemben:
• Jóval kisebb rendszerigény
• Jobb memóriamenedzsment
• Open source mivoltából adódóan dinamikusabb fejlődés
• Szabad felhasználhatóság
3. ábra: Az Eclipse indítását követően megjelenő felhasználói felület
3.4. JavaFX
A JavaFX 2008-ban jelent meg a SWING leváltása érdekében. Célja, hogy nagy teljesít-
ményű, könnyen használható grafikus platformot biztosítson Java fejlesztők számára, azonban
a SWING-et használó alkalmazások elterjedtsége miatt annak leváltása nem következett be.
A JavaFX egy olyan szoftverplatform, amely lehetővé teszi a fejlesztők számára, hogy
különböző platformokon futó rich clinet alkalmazásokat tervezzenek hozzanak létre, tesztelje-
nek debugoljank és deployoljanak [17].
Előnye, hogy a grafikus felhasználói interfész platformfüggetlen, tehát az asztali alkal-
mazások mellett akár mobil vagy webes alkalmazások fejlesztése során is használatba vehető.
Elődjéhez képest a Javanatív része, valamint használata során olyan szolgáltatások is elérhetők,
mint a CSS feldolgozás vagy szálkezelés.
A JavaFX komponensei
4. ábra: A JavaFX komponenseinek felépítése [8]
A GUI összetevői egy úgynevezett Scene Garph-ban vannak rendezve, amelyet a JavaFX
Public API segítségével építhetünk fel. A gráf elemei, vagyis a Node-okat hierarchikus fát al-
kotnak, amely nem tartalmaz kört annak elkerülése érdekében, hogy egy-egy tároló ne tartal-
mazhassa a másikat [16].
• Quantum toolkit: az alacsony szintek feletti abszatrakcióért, valamint az azok kötötti
koordinációért felel
• Prism: a JavaFX scene-jeinek raszterizálásáért és rendereléséért felelős
• Glass Windowing Toolkit:
• Media Engine: médiatartalmak lejátszásának lehetőségét biztosítja a felhasználó szá-
mára
• Web Engine: webes tartalom megjelenítését biztosítja
3.5. Scene Builder
A SceneBuilder egy Gluon által fejlesztett JavaFX-et használó ingyenes és nyílt forrás-
kódú alkalmazás, amely segítségével a felhasználó egyszerűen, a felület komponenseinek ösz-
szehúzásával készíthet alkalmazásokhoz grafikus felhasználói felületeket. Az interfész össze-
állítását követően a háttérben előáll az FXML formátumú fájl, amelyet később a fejlesztő bár-
mely projekthez hozzárendelhet. A felhasználói felület és az üzleti logika szeparációjával lehe-
tővé teszi egy csapat tagjainak számára, hogy a fejlesztők a saját alkalmazásfejlesztési terüle-
tükre összpontosítsanak [14][15].
3.6. Android Studio
Az Android Studio egy Google által fejlesztett IntelliJ Idea alapú hivatalos integrált fej-
lesztői környezet (IDE), amely segítséget nyújt a felhasználónak kifejezetten Android operációs
rendszert futtató platformra való alkalmazások fejlesztése során. A fejlesztő környezet szaba-
don felhasználható Apache License 2.0 alatt. A szoftver fejlesztés folyamatának produktivitását
növelő funkciók [9]:
• Rugalmas Gradle alapú build rendszer
• Gyors emulátor
• Egységes rendszer az összes Android-eszköz programozásához
• Változtatások valós idejű alkalmazása az alkalmazás újra indítás nélkül
• Kód minták és GitHub integráció
• Lint eszközök a teljesítmény, a használhatóság, a verzió kompatibilitása és egyéb prob-
lémák észleléséhez
• Széleskörű tesztelő eszközök és framework-ök
• C++ és NDK támogatás
• Google Cloud Platform támogatása
5. ábra: SceneBuilder kezelőfelülete
6. ábra: Android Studio felhasználói felülete
A fejlesztő környezet előnyei közé tartozik, hogy különböző helyzetekre különböző al-
kalmazásmintákkal szolgál, ennek köszönthetően a felhasználónak nincs feltétlenül szüksége
arra, hogy az alkalmazás kivitelezésének megkezdését megelőzően tanulmányozza a több száz
oldalnyi dokumentációt.
Az IDE használata a JetBrains által fejlesztett IntelliJ IDEA-nál megismert módon törté-
nik, ennélfogva támogatja az olyan szolgáltatásokat, mint a kódkiegészítés vagy a dokumentá-
ciós blokk szerkesztőben való megjelenítése. Ezek mellett tartalmaz egy SceneBuilder szerű
grafikus felhasználói felülettervezőt, amelynek segítségével lehetősége van a felhasználónak
arra, hogy megtekintse az alkalmazás felületének megjelenését a jövőben lehetséges használt
eszközökön, így elkerülve az arány vagy méretkülönbségből adódó esetleges problémákat.
3.7. Maven
Egy alkalmazás elkészítése során a programozónak célszerűtlen minden programrészletet
saját magának elkészítenie minden problémára, mivel ezek nagy többségére már léteznek má-
sok által kifejlesztett jól működő megbízható megoldások.
Az Apache Software Fondation által fejlesztett Apache Maven egy szoftverprojektek me-
nedzselésében és a build folyamatok automatizálásában segítséget nyújtó eszköz, melynek
használata során egy .xml kiterjesztésű fájlban adhatja meg a felhasználó a saját projektjének
felépítéséhez szükséges valamennyi információt.
Az Apache Maven egy úgynevezett software „project management and comprehension
tool”, amelyet Jason van Zyl készített 2002-ben. Funkcionalitásban az Apache Ant eszközhöz
hasonlít, de egyszerűbb és XML alapú a konfigurációs modellje. Alapját a project object model
(POM) képezi, ez alapján a Maven képes különböző dokumentációk, riportok build folyamatok
generálására. A POM egy buildelendő projektet, valamint annak függőségeit írja le.
A Maven hálóózatképes, ebből adódóan szükség szerint dinamkusan is képes komponen-
sek letöltésére vagy szoftvercsomagok feltöltésére különböző hosztokra, úgynevezett Repo-
sitorykba.
Egy Maven projekt élete különböző életciklusokból áll. Az alapötlet az, hogy ahhoz, hogy
minden cél végrehajtásához az azt megelőző célnak is iskeresen végre kell hajtódnia.
A projekt életciklusai:
1. Validate
2. Generate-sources
3. Process-source
4. Generate-resources
5. Process-resources
6. Process-test-sources
7. Process-test-resources
8. Compile
9. Test-compile
10. Test: unit tesztek fordítása és futtatása
11. Package
12. Install: Bemásolja a jar fájlt a ~/.m2 /repository /${groupId} /${artifactId}/ ${version}
mappába, azaz a lokális repository-ba.
13. Deploy: telepíti az alkalmazást a megadott szerverre
Így például az mvn install futását megelőzően a Maven megvizsgálja, hogy az mvn
package előtte sikeresen lefutott-e már.
3.8. Gradle
A Gradle egy olyan nyílt forráskódú automatizálási rendszer, amelyet a Google az And-
roid operációs rendszerének alapértelmezett build tool-jaként választott. Az Apache Ant és az
Apache Maven koncepciójára épít és bevezeti a domain alapú specifikus (DSL) nyelvet a
projektkonfiguráció során használt hagyományos XML formátum felváltásával. A Gradle a fel-
adatok futásának sorrendjének definiálására irányított körmentes gráfot (DAG) használ. Az ere-
deti moduljai a hangsúlyt a Java-ra, a Groovy-ra és Scala-ra helyezték. A több projektes épít-
kezés támogatására, a termelékenység növelésére tervezték.
7. ábra: Gradle fájl példa
A Gradle egyesíti a z Ant rugalmasságát és a Maven könnyű használatát de XML séma
nélkül. Groovy alapú (a JVM által támogatott) specifikus nyelvvel rendelkezik, ennek köszön-
hetően a szkriptek rövidebbek és tisztábbak. Egy Gradle projekt minden alkalommal szinkro-
nizálva letölti a könyvtárakat a megadott repositoryk-ból azonba, ha a felhasználónak nincs
hálózati kapcsolata leállíthatja azt az offline mód segítségével. Testreszabható és bővíthető kü-
lönböző projektekhez az adott technológiától függően például Java, Kotlin, Android, Groovy
és még sok más. Rendkívül gyors teljesítmény, körülbelül kétszer gyorsabb, mint a Maven. A
fejlesztői környezetek széles skáláját támogatja, valamint parancssori interfészt is biztosít a fel-
használó számára, ezen kívül interaktív web-alapú felhasználói felületet kínál az optimalizálás-
hoz és hibakereséshez.
3.9. MVC- Model View Controller
Az MVC (modell-nézet-vezérlő) egy szoftverfejlesztés során használt szerkezeti minta.
Az MVC ezt úgy kívánja elérni, hogy elkülöníti az adatok elérését és az üzleti logikát a felhasz-
nálói interfésztől és az azon végzett interakcióktól egy úgynevezett vezérlő bevezetésével a két
komponens között. Ennek előnye, hogy a felhasználói felület nem manipulálja az adatok keze-
lésének módját, valamint az adatok átszervezhetőek lesznek a nézet átszervezése nélkül. Az
egyik leggyakrabban használt iparági szabványú minta skálázható és esetleges bővítést igénylő
projektek létrehozására.
Az MVC komponensei:
▪ Model (modell): a modell reprezentálja az információt, valamint az üzleti logikát
▪ View (nézet): a modell egy adott pillanatbéli állapotának megjelenítésére szolgáló, fel-
használói interakcióra alkalmas felhasználói felület
▪ Controller (vezérlő): szerepe jellemzően a válaszadás a felhasználói input interkaci-
ókra, amelyek során a tevékenységnek megfelelően módosítja a modellben található
adatokat
Egy MVC alkalmazás általános működése:
1. Az szoftver felhasználója valamilyen interakcióba lép az alkalmazással a felhasználói
felületen keresztül
2. A controllertől beérkező eseményt átveszi a felhasználói felülettől
3. A vezérlő az eseménynek megfelelően kapcsolatba lép a modellel, manipulálja azt az
interakciónak megfelelően
4. A nézet a modell alapján generálja a manipulációnak megfelelő felhasználói felületet,
azonban nincs közvetlen tudomása a modellről
5. A felhasználói felület vár a következő eseményre
8. ábra: MVC modell
3.10. Java Script Object Notation
A JSON egy kis méretű, ember által könnyen olvasható, programnyelv független, szöveg
alapú szabvány, amely a JavaScript szkriptnyelvből alakult ki asszociatív tömbök, egyszerű
adatstruktúrák reprezentálására. Strukturált adatok tárolására továbbítására szolgál.
Elsődlegesen egy szerver és egy webes alkalmazás közötti adatátvitelre szolgáló formátum,
melyet az XML alternatív megoldásaként funkcionál [4].
Támogatott adattípusok:
• Numerikus: C-hez és Java-hoz hasonlóan lehet egész vagy lebegőpontos, viszont azok-
tól eltérően sem oktális sem decimális érték nem szerepelhet
• Karakter/karakterlánc: idézőjelek között, Unicode karakterek
• Boolean: true vagy false
• Tömb: szögletes zárójelek között sorrendhelyesen, vesszővel elválasztva egymástól, va-
lamint a tömb elemeinek nem szükséges megegyező típusúaknak lenni
• Objektum: név-érték párok rendezetlen halmaza. Az objektum adattagjai kapcsoszáró-
jelek között helyezkednek el, melyben a kötelezően string típusú különböző nevű kul-
csokat „:” karakter választja el az értéktől, amely bármilyen támogatott adattípusú érté-
ket felvehet. Az objektumok egymásba ágyazhatóak.
• Null: üres érték
9. ábra: Egy tesztberendezés sajátosságait leíró .json kiterjesztésű fájl formátuma
3. táblázat: JSON és XML formátum összehasonlítása
JSON XML
szövegformátum egyszerű egyszerű
felépítése hierarchikus hierarchikus
parse-olható JavaScriptben igen (beépített eval() függ-
vény segítségével) igen
adatok küldése AJAX hívásokkal lehetséges lehetséges
end tag nincs van
hossz rövidebb hosszabb
olvashatóság/írhatóság könnyebb, gyorsabb nehezebb, lassabb értelmez-
hetőség
tömbök használata lehetséges nincsenek
kulcsszavak nincsenek vannak
3.11. Comma Separated Value
A comma-separated-value egy elválasztott szöveges fájl, amelyben az értékeket vesszők
választják el egymástól. A CSV-fájlok általában táblázatos adatokat tárolnak egyszerű szö-
vegként. A fájl formátuma nincsen teljesen szabványosítva. Valójában a „CSV” kifejezés alatt
nem csak vesszőt, hanem bármilyen szöveg elválasztására szolgáló írásjelet kell érteni (pl.:
tabulátor, pontosvessző).
10. ábra: Példa egy .csv kiterjesztésű állományra
A CSV egy általános adatcsere-formátum, amelyet széles körben támogatnak a fogyasz-
tói, üzleti és tudományos ágazatokban használt alkalmazások. Ezen programok általában támo-
gatják az adatok CSV formátumú importálását vagy exportálását. Ez azért fontos, mert előfor-
dulhat, hogy felhasználónak információt kell átadnia egy olyan adatbázis kezelő programból,
amely az adatokat saját formátumban tárolja egy olyan alkalmazásnak, amely nem kezeli azt.
Ebben az esetben általában lehetőség van az exportálásra majd a másik alkalmazásban a CSV
beolvasására.
4. Rendszertervezés
A szoftver megtervezését megelőzően szükség volt az alkalmazástól elvárt funkcionális
követelmények meghatározására. Ezek a felhasználó által igényelt összes olyan szolgáltatást
jelentik, amelyek a rendszer működését írják le. A specifikációnak teljesnek és ellentmondás
mentesnek kell lennie annak érdekében, hogy bonyolult rendszerek specifikálása során se ke-
rüljön hiba a szoftver követelményeinek leírásakor, ne legyenek benne esetleges hiányosságok.
A szoftver funkcionális és nemfunkcionális követelményinek meghatározása a partnercég-
gel történő egyeztetések során történt. A megbeszéléseken meghatározott funkcionális követel-
mények:
• Egységes leíró meta-nyelv a tesztberendezések sajátosságainak tárolására
• Folyamatezérelt tesztelés lehetőségének biztosítása
• Tesztprogramok menthetőségének biztosítása
• Elkészült tesztszekvencia előfordítása .csv kiterjesztésű formátumú fájlba
• Ciklusba ágyazott ciklusok kezelése
• Könnyen használható grafikus felhasználói felület kialakítása
• Szoftver megvalósítása Android operációs rendszert futtató mobil platformra
A szoftverfejlesztés tervezési fázisában sor került az alkalmazással szemben állított kö-
vetelmények vázlatos kidolgozására, amelynek kivitelezéséhez egy úgynevezett Unified Mo-
delling Language került használatba vételre.
Az UML - Unified Modeling Language (egységesített modellező nyelv) - egy olyan egy-
ségesített, szabványosított nyelv (diagramok gyűjteménye), amellyel egy rendszer egyszerűen
és gyorsan modellezhető [5].
Előnye, hogy a szoftverfolyamat tervezési fázisában jól áttekinthető grafikus ábrázolásra
ad lehetőséget ábrák, diagramok formájában, valamint kiváló kommunikációs alternatívát kínál
a fejlesztők és a felhasználók között.
A használati eset diagram célja, hogy a szoftverfolyamat tervezési fázisában rögzítsük
azokat a követelményeket, amelyeket a szoftver kivitelezését követően a rendszernek tudnia
kell, tehát megtervezésre kerülnek a program alapvető funkciói, a rendszer viselkedése és a
környezettel való kapcsolata a felhasználó szemszögéből nézve. Előnyei közé tartozik, hogy
szemléletes és könnyen áttekinthető. Minden használati eset a felhasználó által végzett interak-
ciókból, valamint a rendszer által arra adott válaszaiból álló párbeszédet definiálja.
A szoftverfejlesztés tervezési fázisának első szakaszában meghatározásra kerültek az al-
kalmazástól elvárt funkcionális követelmények, valamint a funkciók működésével kapcsolatos
elvárások. Ezek reprezentálására kivitelezésre került az elkészítendő alkalmazás funkcióinak
használati eset diagramja annak érdekében, hogy a szoftver kivitelezése során a működés értel-
mezése, így az algoritmusok implementálása egyszerűbb legyen.
11. ábra: Az alkalmazás USE CASE diagramja
A diagram elkészítését követően a partnercéggel való egyeztetés során jóváhagyásra ke-
rült az alkalmazás funkcióiról kialakított elképzelés
Az elfogadott használati eset diagram kivitelezését követően az abban definiált funk-
ciók kerültek részletezésre. Az aktivitás diagram feladata az időben egymást követő folyama-
tok reprezentálása a végrehajtandó tevékenységek és a tevékenységek egymás után követke-
zőségének megadásával. Alkalmas lehet egy alrendszer vagy egy teljes rendszer leírására is.
A folyamatábrákra és a munkafolyamat diagramokra épít.
12. ábra: Az alkalmazás aktivitás diagramja
Az aktivitás diagram elemei:
• Tevékenységek: valamilyen végrehajtandó műveletsorozat, amely megoldásához ele-
gendő lehet néhány utasítás, de lehet egy összetett, sok utasításból álló tevékenység is.
Jele: lekerekített sarkú téglalap.
• Átmenetek: egy tevékenységet és az azt közvetlenül követő tevékenységet nyíllal kötjük
össze.
• Döntési pontok: segítségükkel a lehetséges kimenet alternatíváit ábrázolhatjuk. A dön-
tési pontokba legalább egy nyíl vezet, valamint legalább két alternatív tevékenységgel
rendelkezik. A lehetséges tevékenységek feltételét egy szögletes zárójelben megadott
feltétel jelzi. Jele: rombusz.
• Kezdeti és végállapot: jelölése megegyezik az állapotgép diagraméval.
• Szinkronizációs vonal: párhuzamos tevékenységek kezdetét és végét jelzi. A végét
jelző szinkronizációs pontot követő tevékenység csak akkor kezdhető el, ha minden
előtte lévő párhuzamos feladat befejeződött.
A használati eset diagram részletezésével kidolgozásra került az alkalmazás aktivitásdi-
agramja. Ennek segítségével a fő funkciók komponensekre bontva átfogóbb képet adtak az
implementáció során kivitelezendő algoritmusok összességével, így lehetőség adódott az imp-
lementálás során létrehozandó, szükséges osztályok megtervezésére.
Az osztálydiagram az UML egyik leggyakrabban használt diagram típusa, amely a szoft-
verfejlesztés különböző fázisai során más-más megközelítést igényel, azonban fő feladata az
osztályok és azok közötti kapcsolatok ábrázolása [6].
Az UML osztályozásának különböző absztrakciós szintjei:
• Analízis
• Tervezés
• Implementáció
Az osztály reprezentálása
Az osztály jelölésére alapesetben egy függőlegesen három részre osztott téglalap szolgál:
• Felső rész: osztály neve
• Középső rész: az osztály attribútumai a különböző tervezési fázisokban:
o Analízis: ismert az adattag neve
o Tervezési szint: ismert az adattag neve, valamint az adattagokon végrehajtható
operációk
o Implementációs szint: ismert az adattag neve, elérési módja, típusa és az adatta-
gokon végrehajtható operációk
• Alsó rész: műveletek leírása
Mivel az osztálydiagramot a tervezés különböző szakaszaiban is használhatjuk, ezért a
téglalapokban szereplő adatok, azok részletessége a tervezés fázisától függően változhatnak.
Egyetlen kötelezően kitöltött része az osztály megnevezése, ekkor a téglalap három részre osz-
tása el is maradhat.
13. ábra: Az eszközök és parancsok osztálydiagramja a tervezés fázisában
Az osztályokat jelölő téglalapok további rekeszekkel bővíthetőek, amelyben speciális att-
ribútumok tüntethetők fel (pl.: operációk típusai, más diagramok).
Osztály attribútumok: az osztály adattagjainak felsorolása, amelyek különböző absztrak-
ciós szinteken értelmezettek. Attribútum jelölése: láthatóság név: típus = inicializációs érték
Láthatóság: az osztály adattagjait, metódusait milyen szinten kell elrejteni a külvilág felé.
A különböző láthatósági szintek különböző jelölésekkel rendelkeznek:
3. táblázat: Láthatósági módosítók és azok jelölése osztálydiagramok esetén
Név Jele Láthatósági köre
public + bármely osztály hozzáférhet
proteced # saját és öröklött osztályok
csomagszintű / package-pri-
vate ~ csomagban lévő osztályok
private - csak saját osztály
Az alkalmazás dokumentációjának, valamint a működésének egyszerűbb megértéséhez
elkészült annak szekvencia diagramja. Ez mind a felhasználó számára mind a későbbi fejlesztés
során segítséget nyújthat a szoftver megértésében. A szekvenciadiagram fő feladata, hogy egy
időtengely mentén reprezentálja az objektumok közötti üzenetváltások egymás után követke-
zőségét. Az objektumok élettartamát, időtengelyét objektumonként egy-egy függőleges fentről
lefelé mutató elnyújtott téglalap jeleníti meg, tehát amelyik üzenetet képviselő nyíl lejjebb ta-
lálható az a felette megjelenített üzenetet követi.
14. ábra: Parancs hozzáadását reprezentáló szekvencia diagram
Elemei:
Objektumok: amelyektől egy szaggatott vonallal jelzett életvonal indul, amely fentről le-
felé az idő múlását jelképezi. Az életvonalon jelölhetők az objektum aktivitási szakaszai. Az
aktivitási szakaszt a szaggatott vonal helyett elnyújtott téglalap jelzi.
Üzenetváltások: az objektumok közötti üzenetváltásokat a küldő életvonalától a foga-
dóéig rajzolt nyíllal jelöljük. A nyílra az üzenet elnevezését írjuk, esetleg az üzenet paraméterei
és a kapcsolódó feltételeket is. Az üzenet továbbítás ideje általában nullának tekinthető, ezért a
nyilak vízszintesek.
Megjegyzések: a diagram bal szélén, megszorítások és időbeliségre utaló jelölések he-
lyezhetők el.
5. Működés leírása
5.1. Asztali számítógépes alkalmazás
Az Eclipse Által generált JAR fájl futtatását követően megjelenik a grafikus felhasználói
felület főképernyője. Az alkalmazás bal felső sarkában lévő legörülő menü mellett lévő ikonra
való kattintást követően megjelenik egy ablak, amely segítségével az alkalmazás
induló mappáját választhatja ki a felhasználó. A legördülő menüben az ebben a mappában lévő
.json kiterjesztésű fájlok listázódnak ki.
15. ábra: Asztali számítógépes alkalmazás főképernyője
A menü lenyitását követően megjelennek a felhasználó által kiválasztott mappában tárolt
JSON fájlok, amelyek az egyes tesztberendezésről tárolnak információkat. Alapértelmezetten
a JAR fájlt tartalmazó mappa lesz a kiinduló, így abban lévő előre létrehozott tesztgépek jelen-
nek meg.
A tesztberendezés kiválasztásának hatására automatikusan megjelennek a gép programo-
zásakor használható parancsok rövid leírásai, a ciklusok kezdetét és végét jelző parancsok, va-
lamint a teszt végét jelző parancs.
A bal oldali lista valamely elemét kijelölve a két lista közötti gomb megnyomására a
felhasználó egy felugró ablakot kap, a parancs paramétereinek számának megfelelő számú kö-
telezően kitöltendő mezővel, valamint a paraméterek leírásával. Ezen mezők száma a
paraméterek számától függően dinamikusan változik parancsonként. Amennyiben a felhasználó
nem töltötte volna ki az összes rendelkezésre álló mezőt, úgy a parancs hozzáadása helyett egy
piros színű figyelmeztető üzenetet kap, így addig nem adható a parancs a listához, ameddig van
üres paramétere.
Amennyiben minden paraméter megfelelően van kitöltve, úgy az „Ok” gomb megnyo-
másának hatására a megadott paraméterek behelyettesítődnek a parancs leírásába, majd beke-
rül az a jobb oldali listába.
16. ábra: A megnyitott tesztberendezés sajátosságai a bal oldali listában
Az alkalmazás kényelmes használatának érdekében a jobb oldali listában szereplő paran-
csok szerkeszthetőek. A parancsra történő dupla kattintás hatására ismét megjelenik a paramé-
terező ablak azzal a különbséggel, hogy a felhasználó által megadott paraméterekkel automati-
kusan kitöltődnek a kitöltendő mezők. Az adatok megváltoztatása, majd elfogadása után a pa-
rancs vissza kerül az eredeti helyére a megváltoztatott paraméterekkel – az „End test” nevű
parancs nem szerkeszthető és nem mozgatható, valamint ezen parancs hozzáadását követően
más parancs nem adható a tesztszekvenciához.
A parancsok sorrendjének megváltoztatásár egy úgynevezett „drag and drop” technika
került igénybevételre. A felhasználó a parancs „megragadásával” és „eldobásával” / „elenge-
désével” módosíthatja a parancsok listában elfoglalt helyét. Továbbá lehetőség van a
tesztszekvenciából való csoportos törlésre, így a ctrl + parancsok kiválasztásával majd a „De-
lete” billentyű megnyomásával egyszerre több, akár nem egymást követő parancsot is törölhet.
A felhasználónak lehetősége van a még el nem készült tesztszekvenciák mentésére. Ekkor
az induló mappa kiválasztásához hasonló ablakot kapunk, amelyben a megadott helyre ment-
hető a tesztprogram későbbi felhasználásra. A fájl mentésekor a tesztberendezésekhez hasonló
.json kiterjesztésű fájl jön létre a berendezés sajátosságaival és a jobb oldali listából mentett
tesztszekvenciával.
Lehetőség van a mentett programok visszatöltésére és szerkesztésének folytatására a jobb
felső sarokban lévő gomb megnyomásával. Ekkor ismét egy fájlválasztó ablak jelenik meg
a felhasználó számára, azonban itt nem elég mappát választani, szükség van a .json kiterjesztésű
elmentett fájl kiválasztására is.
17. ábra: Elkészült tesztszekvencia a jobb oldali listában
A sajátosságok és mentett szekvencia betöltését követően folytatható a tesztszekvencia
módosítása. Az elkészült program exportálására a jobb felső sarokban található gombra
kattintva van lehetőség. Ezen gomb megnyomását követően az alkalmazás először ellenőrzi az
„End Test” parancs meglétét. Amennyiben az nem található egy hibaüzenet figyelmezteti a
szoftver használóját erre. A parancs végét jelző parancs megléte esetén a következő validációs
lépés a ciklusok elejét és végét jelző parancsok számának egyeztetése. Amennyiben a számuk
nem egyezik úgy nem hajtható végre a loop unrolling, így erre egy „Missing End / Start loop”
üzenet figyelmezteti az alkalmazás felhasználóját. Ha az tesztszekvencia teljesen megfelel a
formai követelményeknek egy algoritmus vizsgálni kezdi a paraméterezett parancsot és a teszt-
gép sajátosságai között szereplő parancsokat. Amennyiben a paraméterek kivételével a kettő
egyezik úgy a paramétereket behelyettesíti a parancs „értékébe”, azaz a .csv kiterjesztésű fájlba
írandó sorba.
A ciklusok kezelése egy rekurzív algoritmus segítségével valósul meg. Amennyiben a
feldolgozandó tesztlépés egy ciklus kezdetét jelző lépés, úgy megkapja azon ciklus végrehajtási
számát, majd folytatja addig az előzőekben leírt előfordítási folyamatot ameddig egy ciklus
kezdetét vagy végét jelző lépés nem következik. Ha a lépés a ciklus végét jelzi, akkor a meg-
adott ciklusszám szerint megismétli a lépéseket, majd a soron következővel folytatja azonban,
ha egy újabb ciklus kezdete következik, meghívja saját magát, amelynek átadódik az új ciklus
ismétléseinek száma.
Az előfordítási folyamat befejeztével előáll egy .csv kiterjesztésű fájl a felhasználó által
megadott helyre és néven, amelyet már a vállalatnál található valamennyi berendezés értel-
mezni tud és saját nyelvére tud fordítani.
18. ábra: Az elkészült tesztszekvencia előfordításának folyamatábrája
19. ábra: Ciklusok feldolgozásáért felelős metódus
Kényelmi szempontból az alkalmazáshoz egy plusz funkció került hozzáadásra, mely-
nek segítségével felhasználó új tesztberendezéseket készíthet vagy módosíthatja a meglévőeket.
Ez a gyakorlatban egy egyszerű .txt kiterjesztésű szöveges dokumentum szerkesztéseként va-
lósul meg, amelyhez egy parancs hozzáadása funkció társul. Ekkor a szövegdobozba egy új
minta parancs kerül hozzáadásra, amely sajátosságnak paramétereit a felhasználó egyszerűen a
program használata közben megváltoztathatja.
5.2. Android operációs rendszert futtató mobil alkalmazás
A mobil platformon való futtatáshoz szükség van a .apk kiterjesztésű fájl telepítésére,
amelyet a felhasználónak engedélyeznie kell azon okból kifolyólag, mivel az nem tölthető le a
Google Play áruházából.
Az applikáció elindítását követően megjelenik a főképernyő egy felugró ablakkal, mely-
ben az alkalmazás számára szükséges engedélyezni a fájlrendszerhez való hozzáférést annak
érdekében, hogy lehetősége legyen a mappák létrehozására, valamint létrehozott tesztberende-
zések sajátosságait tároló .json kiterjesztésű fájlok másolására. Amennyiben a felhasználó nem
ad engedélyt erre, úgy az alkalmazás leáll és a következő indításkor ismét megtörténik az en-
gedélykérés.
20. ábra: Mobil applikáció főképernyője
A mappák létrehozását és a fájlok másolását követően használhatóvá válik az applikáció.
Az asztali számítógépes alkalmazástól eltérő módon itt nincs lehetősége az alkalmazás haszná-
lójának a különböző induló könyvtárak választására, így csak az előre megadott mappában ta-
lálható berendezéseket használhatja, valamint csak az előre megadott mappákba menthet vagy
exportálhat. Továbbá elhagyásra került a tesztberendezés létrehozása és szerkesztése funkció,
amelynek fő oka, hogy hordozható eszközön nem, vagy csak nehezen alkalmazható lenne és
mivel nem volt elvárás a szoftver működésével kapcsolatban, ezért itt nem került kivitelezésre.
Az applikáció funkciói a bal szélen megjelenő menüben találhatók, amely a ikon meg-
érintésével vagy a képernyő bal szélének jobbra húzásával érhető el.
21. ábra: Mobil applikáció menüje
Tesztszekvencia létrehozásához az asztali számítógépes alkalmazáshoz hasonlóan szük-
ség van a tesztgép kiválasztására, azonban itt több lehetősége nyílik erre a felhasználónak. Az
első lehetőség a menüből a „Select” menüpontot választva megjelenik egy lista, amelyben a
különböző tesztberendezések közül választhatunk. Amennyiben még nem választott gépet a
jobb alsó sarokban található parancs hozzáadására szolgáló gomb megérintésének hatására is
lehetősége van a választásra. A harmadik opció az első alkalmazáshoz képest
egy új funkció, melynek segítségével lehetőség adódik különböző QR kódok beolvasására. A
jobb felső sarokban lévő menüpontjai közül a „Read QR code” alternatívát választva egy
újabb engedély kérő ablak jelenik meg, amelyben a kamera hozzáférést szükséges engedé-
lyezni. A kamerát a QR kódra irányítva beolvassa az adott gép nevét, azonban ebben az esetben
nem az összes tesztberendezést jeleníti meg, hanem a tesztberendezést és az arra a tesztberen-
dezésre készült mentett fájlokat.
22. ábra: Kiválasztott parancs paraméterezése
Parancsok hozzáadására a jobb alsó sarokban lévő gomb segítségével van
lehetőség. A parancsok szerkesztése a listában lévő paraméterezett parancs érintésével lehetsé-
ges. Parancsok törlésére a parancs balra húzásával lehetséges, azonban a véletlen törlés elkerü-
lése érdekében a parancs törlését követően a képernyő alján megjelenik egy parancs törlésének
visszavonása lehetőség. A rendezésre itt is a számítógépes alkalmazásban megismert „drag and
drop” technika került kivitelezésre. Ekkor a parancs hosszú megérintését követően egy rövid
rezgést generál az applikáció, amely jelzi a felhasználó számára, hogy elkezdheti a parancs
mozgatását.
6. Tesztelés
6.1. Manuális tesztelési folyamat
A szoftver tesztelése folyamán az alkalmazás manuális tesztelése bizonyosodott a leg-
megfelelőbbnek, mivel az elkészült programmal szemben támasztott elvárások tesztelésének
automatizálására nem adatott lehetőség.
Elsősorban az alkalmazás által előállított .csv kiterjesztésű fájl alkalmazhatóságát vizs-
gáltuk, melynek során az elkészített tesztszekvencia és az alkalmazás által ebből előállított fájl
kifogástalan létrehozása volt az elvárás.
A megfelelő formátum megvalósítását követően a „loop unrolling”-ot megvalósító rekur-
zív algoritmus által „kibontott” ciklusok felülvizsgálatára került sor.
Az észlelt hibákat követően az alkalmazás a partnercég számára átadásra került annak
érdekében, hogy a valódi üzleti környezetben való használat során esetlegesen felmerülő hibák
összegzésre, majd kijavításra kerüljenek. Ennek köszönhetően kívántam elérni a hibák, rendel-
lenes működések számának minimalizálását.
7. Továbbfejlesztési lehetőségek
Elérhető eszközök listájának bővítése
Az alkalmazás elkészítéséhez a kivitelezés első felében a partnercég két tesztberendezés
sajátosságait bocsátotta a rendelkezésünkre, ezek segítségével kerültek implementálásra az al-
kalmazás funkcióit megvalósító algoritmusok, azonban más struktúrájú tesztberendezések ese-
tén szükséges lehet az üzleti logikai módosítása.
Integrálás más alkalmazásokkal
A PLCDataWriter egyszerű és költséghatékony módszert kínál az Excel fájlból közvet-
lenül a Siemens programozható logikai vezérlőkre történő adatok írására. Mivel a program a
háttérben fut, így a felhasználó egyéb célokra is használhatja a számítógépet. Egy tálcamenü-
bejegyzés segítségével megnézheti az adott berendezés állapotát és megváltoztathatja annak
konfigurációját, néhány lépésben elvégezheti a legfontosabb beállításokat. Ez magában foglalja
a PLC kapcsolatot, a fájl kiválasztását és a PLC adatok hozzárendelését az Excel cellákhoz
vagy sorokhoz [13].
Az alkalmazás integrálásával vagy fő funkcióinak kiemelésével és átültetésével az asztali
számítógépre kivitelezett alkalmazás hatékonyan alkalmazható lenne az elkészült tesztszekven-
ciák valós idejű átvitelére, a berendezések állapotának figyelésére, statisztikák készítésére, va-
lamint hibás tesztprogram esetén annak javítására, ezzel csökkentve a tesztelés során keletkező
lehetséges hibákból adódó kieső idő mértékét, így növelve a termékfejlesztési és tesztelési fo-
lyamatok hatékonyságát.
23. ábra: PLC Data Writer kezelőfelülete
További nyelvek hozzáadása
Mivel az alkalmazások egy olyan vállalatnál kerülnek felhasználásra, ahol előfordulhat
külföldi munkavállaló, így az program felhasználói felületén használ nyelv az angol annak ér-
dekében, hogy bárki számára érthető, esetleg könnyen fordítható legyen. Azonban a későbbi
célok közé felvehető az alkalmazásban elérhető nyelvek közé a magyar és a német nyelv.
Webes applikáció készítése
Annak érdekében, hogy az alkalmazás ne sérthesse a vállalat biztonságpolitikáját a webes
alkalmazás ötlete elvetésre került, azonban a későbbiekben az üzleti logika kivitelezését köve-
tően, a
Az alkalmazás fejlesztésével szerezhető előnyök:
• Valós idejű adatok kinyerése az elkészített tesztprogramok futása során
• Statisztika készítése a tesztberendezések/ tesztprogramok esetleges hibáiról
• Felhasználók megkülönböztetése különböző tesztberendezések programozására való jo-
gosultság szerint
• Nem szükséges az alkalmazás megléte
• Egységesített kezelőfelület, melynek segítségével teljes platformfüggetlenség érhető el
Összegzés
A meghatározott feladat egy olyan alkalmazás kivitelezése volt, amellyel különböző
PLC tesztberendezések programozásának egyszerűsítését, valamint az esemény vezérelt tesz-
telési folyamat bevezetését biztosítja a felhasználó számára. A különböző PLC berendezések
megismerését követően a feladat megoldására egy olyan általános megoldás bizonyult a leg-
megfelelőbbnek, amely során a szoftver egy .csv kiterjesztésű előfordított fájl készít a felhasz-
náló által megadott adatokból, így azt később az egyes berendezések képesek a saját specifikus
PLC programozási nyelvükre fordítani. A berendezések különbözősége egy .json kiterjesztésű
fájlformátum segítségével kerültek elfedésre/egységesítésre, amelynek előnye, hogy könnyen
olvasható, egyszerűen értelmezhető, így a felhasználó is készíthet új tesztberendezést leíró fájlt
vagy szerkesztheti azokat.
A szakdolgozatkészítés folyamán mélyebben megismertem a Java programozási nyel-
vet, betekintést nyerhettem egy projekt kivitelezésének folyamatába, valamint megismerked-
hettem az Androidra való fejlesztés sajátosságaival. A kísérleti fejlesztés tervezési szakaszában
kivitelezésre kerültek a felhasználói felület vázlatai, valamint az elvárt működést szemléltető
diagramok, amelyek segítségével leegyszerűsödött és könnyen átláthatóvá vált az alkalmazás
kivitelezése. A szoftverfolyamat fejlesztési fázisában megvalósításra kerültek a partnercégtől
kapott tesztgépek sajátosságait leíró fájlok, az alkalmazás funkcióinak megvalósítására szolgáló
algoritmusok, valamint a grafikus felhasználói felület.
Az alkalmazás tesztelését követően az Android operációs rendszert futtató platformon
alkalmazható applikáció megtervezésére került sor, melynek során egyszerűsítésre került a fel-
használó felület terve annak érdekében, hogy a kisebb mobil eszközökön is alkalmazható le-
gyen. A felhasználói felület kivitelezését követően a funkciókat megvalósító algoritmusok mó-
dosítására került sor az Android specifikus
A feladat elvégzése során kivitelezett alkalmazás a Starters E-Components Generators
Automotive Hungary Kft. visszajelzései alapján sikeresen integrálásra került a cég termékfej-
lesztési- és fejlesztési folyamataival. Hatékonyan alkalmazható a vállalatnál használt valam-
ennyi tesztberendezés programozása során, ennek köszönhetően jelentősen leegyszerűsödött és
lerövidült a különböző tesztszekvenciák elkészítése.
Summary
The defined task was to implement an application that simplifies the programming of
various PLC testbench and introduces an event-driven testing process for the user.
After learning about various PLC devices, a general solution proved to be the most su-
itable, in which the software creates a precompiled file with a .csv extension from the data
provided by the user, so that each device can later translate it to its own specific PLC program-
ming language.
The differences in equipment have been obscured/standardized using a file format with
a .json extension, which has the advantage of being easy to read, easy to interpret, so that the
user can also create or edit a file, which describes a new test equipment.
During the preparation of my dissertation, I got to know the Java programming language
deeper, gained insight into the process of implementing a project, and got acquainted with the
peculiarities of development for Android.
In the design period of the experimental development, outline of the user interface were
made, as well as diagrams illustrating the expected operation, with the help of which the imp-
lementation of the application became simplified and easily transparent.
During the development period of the software process, the files, describing the charac-
teristics of the test machines, were received from the partner company, algorithms for imple-
menting the application functions, and the graphical user interface were implemented.
After testing the application, an application for the platform running the Android ope-
rating system was designed, when the design of the user interface was simplified in order to be
applicable on smaller mobile devices.
Following the implementation of the user interface, the algorithms which implement the
functions have been modified to be Android specific.
Based on the feedback of Starters E-Components Generators Automotive Hungary Kft,
the application implemented during the task was successfully integrated with the company's
product development and development processes. It can be used effectively in the programming
process of all test equipment used in the company, thanks to the preparation of various test
sequences that has been significantly simplified and shortened it.
Köszönetnyilvánítás
Szeretnék hálás köszönetet mondani témavezetőmnek, Szabó Martinnak és Dr. Nehéz Károly
Intézet Igazgató Úrnak amiért szakmai tanácsaikkal, ötleteikkel, segítőkészségükkel és szükség
esetén építő kritikáikkal támogatták szakdolgozatom elkészültét.
Továbbá köszönöm a Starters E-Components Generators Automotive Hungary Kft-nek és a
Felsőoktatási és Ipari Együttműködési Központnak, szakdolgozat témát biztosítottak számomra
a Korszerű anyagok és intelligens technológiák FIEK létrehozása a Miskolci Egyetemen című
projekt keretein belül.
Irodalomjegyzék, hivatkozások
[1] Ferenczi István. PLC programozási alapismeretek, 2017
[2] PLC ismeretek és példatár, Maczik Mihály András, 2013
[3] Szabó Géza. Programozható logikai vezérlők, 1995
[4] ECMA international. The JSON Data Interchange Syntax, 2017
[5] Dr. Szepesné Stiftinger, Mári. Rendszertervezés 4., A rendszerfejlesztés eszközei (techni-
kák, CASE, UML), 2010
[6] FICSOR, Lajos; KRIZSÁN, Zoltán; MILEFF Péter. Szoftverfejlesztés 2011,
[7] https://hu.wikipedia.org/wiki/Eclipse
[8] https://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm
[9] https://developer.android.com/studio/intro
[10] JUHÁSZ, Róbert. Ismerkedés a PLC-vel
[11] SZABÓ, Tibor. Gépészeti automatizálás. Budapest, Eudutus Főiskola, 2011.
[12] https://plcdatatools.com/plc-data-tools/plcdatareader/
[13] https://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-
2157684.html
[14] https://gluonhq.com/products/scene-builder/
[15] https://docs.oracle.com/javafx/2/overview/jfxpub-overview.htm