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