A pályázati munka összefoglalása

A kutatás-fejlesztési központok fejlesztése és megerősítése KMOP-1.1.2-08/1-2008-0002 A pályázati munka összefoglalása

Budapest, 2012.05.31.

Szerkesztette: Gonda János

Felelős kiadó: Gábori László

Tartalomjegyzék EGY PÁLYÁZAT HATÁSA AZ OKTATÁSRA ÉS KUTATÁSRA

5

AZ ELTE INFORMATIKAI KOOPERÁCIÓS KUTATÁSI ÉS OKTATÁSI KÖZPONT

17

ADAPTÍV SZOFTVERFEJLESZTÉSI KÖRNYEZET

23

EURÓPAI MUNKAÜGYI ADATOK ELEMZÉSE

29

PROGRAMTRANSZFORMÁCIÓS TECHNIKÁK ÉS ALKALMAZÁSAIK

37

MOBIL TECHNOLÓGIA ALKALMAZÁSAI

53

IRIS ÉS ALAKZATFELISMERÉS

57

EVOLÚCIÓS ELVŰ TUDÁS REPREZENTÁCIÓ

65

ÖNKORMÁNYZATOK GEOINFORMATIKAI ADATBÁZISA

79

AMNIS

93

Egy pályázat hatása az oktatásra és kutatásra1 Gonda János

1. Bevezetés 2008-ban alakult az ELTE-Soft Kutatás-fejlesztő Nonprofit Korlátolt Felelősségű Társaság, röviden az ELTE-Soft Nonprofit Kft, és 2009-ben alakult közhasznú szervezetté. A cég tagjai

 Eötvös Loránd Tudományegyetem;  AITIA International Informatikai Zártkörűen Működő Részvénytársaság;  CITYLOG Logisztikai Szolgáltató és Tanácsadó Korlátolt Felelősségű Társaság;  MultiRáció Gazdasági- és Pénzügyinformatikai Fejlesztő és Szolgáltató Korlátolt Felelősségű Társaság;  NETvisor Informatikai és Kommunikációs Zártkörűen Működő Részvénytársaság. Az ELTE-Soft Kft. fő tevékenysége „Egyéb természettudományi, műszaki kutatás, fejlesztés (közhasznú)”. Az ELTE szenátusa a CCLVIII/2008. (XI. 24.) határozatával hozzájárult az ELTE Soft Kutatás-fejlesztő Nonprofit korlátolt felelősségű társaság létrehozásához, pontosabban szólva „az ELTE Soft Kutatás-fejlesztő Nonprofit korlátolt felelősségű társaság alapításában részvétel támogatásáról”. A határozat mellékletében egyebek között az alábbiak találhatóak:

 a Társaság törekszik arra, hogy legalább 50%-os kutatási feladatot tartalmazó megrendeléseket vállaljon el, pályázattal támogatott munkák esetén ettől csak nagyon indokolt esetben térhet el;  az Egyetem vállalja, hogy amennyiben egy pályázatnál szüksége van gazdasági partnerre, elsősorban a Társaságot kéri fel, amennyiben az megfelel a pályázati feltételeknek;  a Társaság vállalja, hogy minden rendelkezésére álló eszközzel támogatja az ELTE Informatikai Karán folyó oktatást és oktatásfejlesztést;  a Társaság, amennyiben szükséges és lehetséges, más karok oktatási feladatait is támogatja;  az Egyetem (Informatikai Kar) elősegíti, hogy a Társaság működése során létrejött kutatási eredmények megjelenjenek az oktatásban is.

1 Az Informatika a Felsőoktatásban 2011, Debrecen konferencián elhangzottak aktualizált változata (lásd Gonda J. (2011))

A kutatás-fejlesztési központok fejlesztése és megerősítése Az ELTE-Soft Kft. küldetése az Eötvös Loránd Tudományegyetem támogatása abban, hogy az infokommunikációs szoftvertechnológiai kutatás vezető hazai oktatófejlesztő centruma legyen. Az ELTE-Soft célja, hogy az info-kommunikáció területén:

 hasznosítsa az Eötvös Loránd Tudományegyetemen több, mint háromszáz éve felhalmozott elméleti tudásanyagot tervszerű, szabályozott, a piaci kihívásoknak is megfelelő körülmények között;  kiszolgálja a gazdasági és a kormányzati szféra alkalmazott kutatási és kísérleti fejlesztési igényeit;  megismertesse az egyetemi oktatókat és hallgatókat a valós piaci igényekkel;  elméleti területen támogassa a gazdasági és közigazgatási szakembereket;  megteremtse a kétirányú szakemberáramlás kedvező és biztonságos feltételeit. Az ELTE a hazai egyetemek vezető intézményeként a legnagyobb létszámú oktatógárdával és hallgatóállománnyal rendelkezik, akik folyamatosan bővítik a tudományterületek széles spektrumának művelésében szerzett naprakész ismereteiket és tapasztalataikat. Az ELTE-Soft Kft-nek mint az ELTE meghatározó tulajdonában lévő gazdasági társaságnak széleskörű együttműködési lehetősége van a projektek feladatait ellátó teamek szakmai szempontú összeállításánál. Ezért mind a versenyszféra, mind az államés közigazgatás legtöbb területén kedvező munkatárs-merítési esélyt tud biztosítani partnereinek. A Kft. a tevékenységét gazdasági társasági formában végzi. Ennek előnye, hogy a kihívásokra gyorsan tud reagálni, ugyanakkor ez párosul a társaság nonprofit és közhasznú jellegéből adódóan az egyetem oktatási és szakemberképzési céljainak hosszú távú támogatásával. A társaság stratégiai területe az infokommunikációs kutatás-fejlesztés területén olyan nagy innováció-tartalmú feladatok elvégzése, amelyek a természet- és társadalomtudományos alapkutatásra támaszkodva az alkalmazott kutatáson át a műszaki fejlesztéstől a szoftvertermékek fejlesztéséig terjednek. Az ELTE-Soft Kft. szakmai előzménye az ELTE Informatikai Kooperációs Kutatási és Oktatási Központ (IKKK), valamint a GVOP1 -3.2.2.-2004-07-0005/3.0 pályázat végrehajtása során keletkezett tudományos és műszaki eredmények. A társaság sikeresen pályázott „A kutatás-fejlesztési központok fejlesztése és megerősítése” tárgyában kiírt KMOP-1.1.2-08/1 pályázaton (Pályázat3 2008). A konstrukció a K+F tevékenységet végző szervezetek, felsőoktatási intézmények, költségvetési és közhasznú kutatóintézetek már létező, eredményeket felmutatni képes, a vállalati együttműködés előmozdítására kialakított K+F központjaiból (KKK-k és RET-ek) alakított gazdasági társaságok megerősítését tűzte ki célul. A pályázat megvalósítási ideje 2009. szeptember 1. és 2012. március 31. közötti időszak, amely három hónappal túl6

Egy pályázat hatása az oktatásra és kutatásra nyúlhat, és a valóságban két hónappal túl is nyúlt. A projekt költségvetése 940 millió Ft, amelyből 470 millió Ft-ot az ipari partnerek és 470 millió Ft-ot a Nemzeti Fejlesztési Ügynökség biztosít.

2. Előzmények 2.1. Az első lépések 1999-ben az OMFB (Országos Műszaki Fejlesztési Bizottság) Kooperációs Kutató Központ (a továbbiakban KKK) néven programot hirdetett meg annak a kormányzati prioritásnak érvényesítése érdekében, hogy „erősítse a felsőoktatási intézmények, kutatóintézetek és a vállalati szféra kapcsolatát; olyan intézményhálózatot hozzon létre, melyben megvalósul az oktatás, a K+F, a tudás- és technológia-transzfer stratégiai célú integrációja; továbbá elősegítse valódi műszaki áttörést eredményező, új technológiai tudást létrehozó kutatási programok megvalósítását”. Pályázatot magyarországi egyetemek és főiskolák önállóan vagy közösen és vállalkozásokkal konzorciumban nyújthattak be (Pályázat1 1999). 2005. januárjában a KKK-program végrehajtásáért felelős NKTH (Nemzeti Kutatási és Technológiai Hivatal) a program utólagos, ex-post értékelését határozta el. Az értékelést a Netwin Üzleti Tanácsadó Kft és a Laser Consult Műszaki - Tudományos és Gazdasági Tanácsadó Kft. konzorciuma készítette el (Horváth és Mogyorósi 2005). A továbbiakban többször hivatkozunk erre a tanulmányra. A 90-es években – elsősorban az Egyesült Államokban korábban elindított hasonló kezdeményezések hatására – egyre több ország indított el közfinanszírozású projekteket ún. kompetenciaközpontok létrehozására. Az évezred végén járva csak Európában 14 országban volt már ilyen program. Tartalmilag voltak jelentős eltérések ezek között, azonban mindegyikben közös volt a kutatási tevékenység interdiszciplináris jellege, aktív szerepvállalás a doktorandusz-programokban és együttműködés a vállalkozási szektorral. A magyarországi kooperációs kutató központ (KKK) program ebbe a folyamatba illeszkedett szervesen. A KKK pályázat célját a kiíró és állami oldalról finanszírozó OMFB olyan új kutatási központok létrehozásában, illetve már működő intézmények működésének megerősítésében fogalmazta meg, „amelyben a magyar felsőoktatási intézmények, egyéb non-profit kutatóhelyek és az üzleti innovációs szféra szerves kapcsolatai létrejöhetnek, és amelyben az oktatás, a gazdasági és társadalmi célorientált kutatás-fejlesztés és a tudás-, valamint technológiai hálózatok stratégiai célú integrálása megvalósulhat.” A KKK pályázat céljai – csak a témához kapcsolódóakat kiemelve – a következők voltak:

 biztosítsák az üzleti szemléletű célirányos alkalmazott kutatás és technológiafejlesztés beépülését az oktatási/képzési és felsőoktatási kutatási tevékenységbe, ezzel segítsék elő a piaci szemlélet meghonosítását a felsőoktatási intézményrendszerben; 7

A kutatás-fejlesztési központok fejlesztése és megerősítése  alapozzák meg a felsőoktatási intézmények és a gazdasági partnerek közötti együttműködésen keresztül a konkrét vállalkozási igényeket kielégítő kutatási együttműködést, valamint tudás- és technológia-transzfert;  munkahelyeket teremtsenek a végzős diplomás és PhD-fokozattal rendelkezők számára;  segítsék elő a felsőoktatási intézmények kutatási kapacitásának és képességének növelését és külső források elérésének lehetőségeit. Egyértelmű elvárásként fogalmazódott meg „a technológiai áttörést elősegítő multidiszciplináris kutatásfejlesztés és innovációk” irányába történő célirányos stratégia kialakításának igénye. A KKK-k elsődleges feladataként a piacorientált alkalmazott kutatás került meghatározásra, azonban igen erős oktatási, képzési program megléte is szerepelt követelményként. „A KKK a tudomány, a kutatás, képzés és a gazdaság meghatározott céljainak és erőforrásainak egyesítését jelenti.” Az 1999 augusztusában meghirdetett KKK-pályázatra 63 szándéknyilatkozat érkezett. Az első fordulóra ebből 21 pályázatot nyújtottak be, majd ezek elsődleges értékelését követően meghívásos alapon 8 pályázat került a második fordulóba. Végül az OMFB 5 pályázatot ítélt támogatásra érdemesnek, összesen 1 083 millió Ft költségvetési támogatást megítélve. Szerződéskötésre 2001 augusztusában került sor. A magyar vállalati szektor meghatározó része akkor (és jelenleg is) kevésbé volt érdekelt hosszabb távon hasznot hajtó, egyben kockázatosabb kutatási tevékenységek finanszírozásával bekapcsolódni a KKK-programba. Az egyetemi környezet azonban nem vállalati fejlesztőintézet, az alapfokú és PhD-képzés igényei tudományos kutatást feltételeznek. E kettős szempontrendszer egyidejű megfelelési kényszere nagyon komoly problémaként fogalmazódott meg esetenként a KKK-intézetek stratégiájának meghatározásakor. Az intézetek mind kutatási programjaikban, mind saját, illetve a befogadó és más egyetemekkel közösen folytatott oktatási/képzési programjaiban több, mint félezer hallgató számára nyújtottak speciális, Magyarországon máshol el nem érhető ismeretszerzési és képességfejlesztési lehetőséget. A KKK-program egyik leglátványosabb eredménye az oktatási/képzési szegmensen belül a PhD képzésben résztvevők számának ugrásszerű megnövekedése az adott szűkebb egyetemi közegben. Az intézetek szinte mindegyike ezen a téren jelentősen „túlteljesítette” vállalt kötelezettségeit. Az intézetek, saját pénzügyi forrásaik terhére ösztöndíjat alapítottak vagy ösztöndíj- kiegészítést nyújtottak. A vállalati PhD ösztöndíj-nyújtás is gyakorlattá vált. A PhD-hallgatók számára a KKK korszerű kutatási infrastrukturális hátteret (laboratórium), szakmai segítséget (témavezetők mentorsága) és publikálási lehetőséget nyújtott. A tanulmány azonban azt is megállapította a hallgatókkal készített interjú alapján, hogy a hallgatók megítélése szerint a KKK-ban végzett gyakorlati kutatási témákat publikációs szempontból tudományos értékkel bírónak nehezebben tudják elfogadtatni, ami a PhD megszerzése szempontjából negatív motivációként jelentkezik. Ugyanakkor

8

Egy pályázat hatása az oktatásra és kutatásra a hallgatók azt is jelezték, hogy nagy presztizs-értéke van a KKK-intézetekben folytatott tevékenységüknek. Az intézetek mind kutatási programjaikban, mind saját, illetve a befogadó és más egyetemekkel közösen folytatott oktatási/képzési programjaiban nagyszámú hallgató számára nyújtottak speciális, Magyarországon máshol el nem érhető ismeretszerzési és képességfejlesztési lehetőséget. Összességében a tanulmány megállapította, hogy a KKK mint struktúra kedvező hatással van az adott ágazatra, a résztvevő vállalatok innovációs tevékenységére, a PhDhallgatók képzésére és elhelyezkedésére, továbbá a befogadó felsőoktatási intézmény szakmai munkájára. Néhány fontosabb megállapítás:

 a hallgatók a KKK-beli munka során egyrészt közvetlen kapcsolatba kerülnek az adott téma nemzetközi irodalmával, problémák felvetésével és új eszközök használatának lehetséges módjaival. Másrészt többletismeretet szereznek a műszaki problémák gyakorlati megoldásai terén, megtanulják, hogy megszerzett tudásukat technológiailag miként tudják alkalmazni. Interdiszciplináris csoportban való munkavégzésük képessége is fejlődik, amelynek munkaerő-piaci értéke egyre magasabb, és elsajátítása a klasszikus oktatási rendszeren belül csak esetleges. További fontos tényező az üzleti magatartás elsajátítása (pl. tárgyalási készség, partnerekkel való kapcsolattartás, projektmenedzselés, pályázati tevékenység stb.). A hallgatók egyöntetű véleménye szerint a KKK-ban eltöltött idő a munkaerő-piaci pozíciójukat jelentősen javítja;  a hallgatók többsége úgy érzi, a KKK a hagyományos egyetemi képzési kínálaton túl nagyon fontos képességek és készségek fejlesztéséhez járul hozzá. Több, mint 70%-uk gondolja úgy, hogy a KKK-ban végzett kutatói, oktatói vagy projekt-menedzselési feladatok révén alkalmasabbá váltak műszaki problémák megoldására, bővültek műszaki ismereteik, hatékonyabban és eredményesebben tudják alkalmazni megszerzett ismereteiket;  külön meg kell említeni a KKK-intézetekben folyó PhD-képzések jelentőségét. Egyrészt a program, és különösen az állami pénzügyi részvétel jelentősen megnövelte az adott egyetemi környezetben a PhD-hallgatók számát, másrészt vonzotta vállalati PhD-ösztöndíjak alapítását. A PhD-hallgatók által végzett kutatási és oktatási tevékenység gyakorlat-orientáltsága olyan minőségi addicionális elemmel gazdagította az egyetemek képzési kínálatát, amely másképpen nehezen lett volna elérhető. Az a tény, hogy nagyon alacsony a 3 év alatt fokozatot szerzett PhD-hallgatók száma, egyrészt szorosan kapcsolódik a hazai általános trendhez, másrészt összefügg a KKK-kutatások gyakorlati jellegével, amely a publikációs tevékenység szempontjából egyértelműen hátrányként jelentkezik;  egy új típusú együttműködési kultúra is megjelent a kampuszok falain belül: a tanszékek újfajta együttműködése alakult ki, mivel az egyes projektek több szervezeti egység ismereteinek integrálását igényelték; 9

A kutatás-fejlesztési központok fejlesztése és megerősítése  a program révén létrejött intézetek tevékenysége elősegítette az oktatásnak a piaci igényekhez való alkalmazkodását, a kutatási eredmények és gyakorlati ismeretek tananyagokba való beépülését, javította a hallgatóknak a gazdasági partnerekkel való kapcsolatteremtési feltételeit;  a KKK mint struktúra kedvező hatással van az adott ágazatra, a résztvevő vállalatok innovációs tevékenységére, a PhD-hallgatók képzésére és elhelyezkedésére, továbbá a befogadó felsőoktatási intézmény szakmai munkájára.

2.2. A második kiírás A tanulmány fentebbi megállapításai mutatják, hogy az elképzelés életképesnek, sikeresnek mutatkozott, így 2004-ben újabb intézmények számára is pályázatot hirdettek koordinációs kutató központok létesítésére (Pályázat2 2004). A pályázati kiírás szerinti támogatható tevékenységek

      

tudományos alap- stratégiai és alkalmazott kutatás, kísérleti fejlesztés; hallgatók, oktatók, kutatók szakmai és tudományos továbbképzése; kutatási eredmények adaptálása, továbbfejlesztése; innovációs projekt megvalósíthatósági tanulmánya; know-how beszerzése, licencvásárlás; szabadalom, használati minta, védjegy és mintaoltalmi bejelentés; jogi, iparjogvédelmi, pénzügyi, üzleti tanácsadás igénybevétele.

A fenti célokból az első négy mindenképpen érinti a felsőoktatás oktatási és kutatási tevékenységét. Az ELTE Informatikai Kara a Gazdasági és Közlekedési Minisztérium által meghirdetett Gazdasági Versenyképesség Operatív Program keretében, az "Európa Pályázat Előkészítő Alap" közreműködésével sikerrel pályázott az "ELTE Informatikai Kooperációs Kutatási és Oktatási Központ (ELTE IKKK)" létrehozására és működtetésére. Az IKKK célja egy többkomponensű, nyitott technológiai szoftverfejlesztő környezet és a hozzá kapcsolódó szakember-koncentráció létrehozása volt, ami minőségileg magasabb szintre emeli a hazai szoftveripar versenyképességét. A környezetet szolgáltatásszerűen felhasználják a konzorcium tagjai és külső vállalkozások kritikus szoftverek fejlesztésére. A projekt keretében az Egyetem és a gazdasági partnerek szakembereinek együttműködésével hasznosítás-orientált célzott alapkutatások és alkalmazott kutatások folytak, amelyektől a konzorcium tagjai jelentős gazdasági eredményeket vártak. Az elképzelések szerint a készülő szoftvertermékek bázisát nyújthatnák egy profitorientált termékoktatási vállalkozásnak is. A kutatás-fejlesztési eredmények átkerültek az oktatásba. Az egyetem kutatói alkalmazói tapasztalatokra, a konzorcium többi tagjának munkatársai pedig kutatói-oktatói tapasztalatokra tettek szert (ELTE-IKKK 2004).

10

Egy pályázat hatása az oktatásra és kutatásra A létrejött konzorciumban az alábbi szervezetek vettek részt:

 Eötvös Loránd Tudományegyetem;  AITIA International Informatikai Zártkörűen Működő Részvénytársaság;  CITYLOG Logisztikai Szolgáltató és Tanácsadó Korlátolt Felelősségű Társaság;  MultiRáció Gazdasági- és Pénzügyinformatikai Fejlesztő és Szolgáltató Korlátolt Felelősségű Társaság;  NETvisor Informatikai és Kommunikációs Zártkörűen Működő Részvénytársaság;  ParaComputer Informatikai Betéti Társaság;  SQI Magyar Szoftverminőség Tanácsadó Intézet Korlátolt Felelősségű Társaság;  Zolix Számítástechnikai Szaktanácsadó Közkereseti Társaság. Az IKKK 2004. december 1-én kezdte meg a működését, és 2007. november 30án sikeresen befejezte a pályázati munkát. A kiírás szerinti fenntartási időszakaszt is ide számítva (2010. november 30-ig), a pályázat során összesen

 101 publikáció jelent meg nemzetközi tudományos fórumokon (szaklapban, konferencián);  a hasznosítható szoftvertermékek vagy megoldások száma 18;  az érintett oktatási programok száma 12;  gazdasági partner részvételével készült dolgozat (PhD, TDK, diplomamunka) száma 22. A publikációk illetve az elkészült szoftverek és egyéb termékek jelentős részében a szerzők és alkotók között igen nagy számban találunk reguláris képzésben résztvevő hallgatókat, doktoranduszokat, illetve olyan személyeket, akik a doktori iskolát éppen elvégezve a disszertációjukon dolgoztak. A fentiekben felsorolt eredmények mellett sok oktatási anyag, segédanyag készült, amelyek készítésében szintén jelentős mértékben vették ki részüket a hallgatók, doktoranduszok, doktorálás előtt állók. Az említett eredmények alapján döntött úgy az ELTE, hogy részt kíván venni a már működő kooperációs kutató központok megerősítését, folytatását támogató újabb pályázati kiíráson.

3. A jelen A KKK-k első szakaszának lezárásaként elkészült jelentés (Horváth és Mogyorósi 2005) az alábbi megállapítást tette: „Az egyetemi befogadó környezet viszonylagos rugalmatlansága kedvezőtlen a gyors reakciókat igénylő és a vállalati partnerek részéről megszokott üzleti működés szempontjából. Minden KKK-intézet a befogadó egyetem 11

A kutatás-fejlesztési központok fejlesztése és megerősítése szervezeti egységeként működik, ugyan önálló alszámlával rendelkezik, de adminisztratív és gazdálkodási szempontból függetlennek nem tekinthető. Mind az egyetemi vezetők, mind a megkérdezett vállalatok azt az álláspontot képviselik, hogy a rendszer fejlesztése egyértelműen megköveteli a függetlenebb jogi intézménnyé válást.” Feltehetően az idézett megállapításnak köszönhetően a KKK-k számára kiírt újabb pályázatok lényegesen különböztek a korábbi feltételektől. A Nemzeti Fejlesztési Ügynökség által 2007-ben, majd 2008-ban és 2009-ben kiírt GOP-1.1.2 illetve KMOP1.1.2 pályázatban a pályázók köre az olyan gazdasági társaságok, amelyek kettős könyvvitelt vezetnek, és nem tartoznak az EVA hatálya alá. A korábbi kiírásoknál a felsőoktatási intézmény volt a fő pályázó, ez változott meg az újabb kiírásban. Ennek hatására az érintett egyetemek létrehozták a saját gazdasági társaságukat. Az ELTE számára is fontos volt, hogy részt tudjon venni az újabb pályázaton, de elképzelése szerint ennél szélesebb körű tevékenységre kell létrehozni a társaságot. Az egyetem olyan szervezetet akart alapítani, amely általában szolgálja az egyetemi feladatok megoldásához esetenként szükséges rugalmasságot, innovációs hajlandóságot, egyszerű ügyintézést, amely elősegíti az egyetemen keletkezett kutatási-fejlesztési eredmények széles körű elterjesztését, illetve amely kutatási-fejlesztési projekteket tud az egyetem felé közvetíteni, az egyetem bázisán megoldani. Ebben a szellemben vett részt az ELTE az ELTE-Soft Kft létrehozásában, és szintén a fent megfogalmazott célok és feladatok jobb kihasználása és megoldása érdekében alakult át a társaság 2009-ben közhasznú társasággá. A Kft. megalakulása lehetővé tette, hogy az ELTE-IKKK-ban megkezdett tevékenység folytatódhasson. Az ELTE-Soft sikeresen vett részt a KMOP-2008-1.1.2-es pályázaton, és 2009. szeptember 1-én megkezdte a pályázatban vállalt feladatok megoldását. A pályázat futamideje elvileg három év, ám a támogatói szerződés megkötése után megmaradt idő ennél kevesebb, a pályázat lezárására a vállalás szerint 2012. március 31-én kerül sor, ám ez az idő három hónappal meghosszabbítható, és a valóságban két hónappal túl is terjedt az eredetileg elgondolt lezárásnál.

Alkalmazott Alkalmazott×hónap Alkalmazás átlagos hossza Megbízott Megbízás×hónap Megbízás átlagos hossza Foglalkoztatott (alk.+megb.) Foglalkoztatott×hónap Foglalkoztatás átlagos hossza

Össze- Hall- Doktosen gató randusz 83 28 10 941 164 170 11,34 5,86 17,00 43 6 3 277 14 25 6,44 2,33 8,33 121 1 218 10,07

32 178 5,56

Poszt- H+D+P H+D+P doktor együtt % 4 40 48,19% 47 381 40,49% 11,75 9,53 84,01% 4 13 30,23% 61 100 36,10% 15,25 7,69 119,41%

12 8 195 108 16,25 13,50

50 481 9,62

1. táblázat Foglalkoztatási adatok (fő, fő×hónap illetve hónap egységben) 12

41,32% 39,49% 95,57%

Egy pályázat hatása az oktatásra és kutatásra Az ELTE-Soft egyik legfontosabb vállalása az volt, hogy a teljes pályázati összeg (vagyis a támogatás és az önrész együttes összege) 10,01%-át a pályázat megvalósításában résztvevő hallgatók, doktoranduszok és posztdoktorok (a tudományos fokozatot 2004. január 1-t követően elnyert résztvevők) személyi juttatására fordítja – és ezt a vállalását a pályázatot megvalósító konzorcium teljesítette, sőt, túlteljesítette. A vállalás nyílvánvaló célja az volt, hogy minél több fiatal vegyen részt a valós élethez igazodó kutató- és fejlesztő munkában. Az eredményt mutatja az 1. táblázat. Az 1990-es évekhez képest az informatikai oktatásban résztvevő hallgatók száma jelentősen megnőtt, például az ELTE-n az elmúlt évszázadban évente mintegy 100 hallgató kezdte meg tanulmányait ezen a szakon, míg jelenleg csupán nappali tagozatra 300nál több hallgatót iskoláznak be, sőt, az idei évben az ELTE informatikai teljes felvételi kerete körülbelül 900 fő. Ezzel a kérdéssel kapcsolatosak az alábbi problémák:  az informatikai alapszak úgynevezett gyakorlatigényes szak, így jogosult szakképzési hozzájárulást befogadni, ám a gyakorlatigényesség egyben azt a kötelezettséget is rója a felsőoktatási intézményre, hogy minden hallgatónak biztosítson hathetes egybefüggő szakmai gyakorlatot. Egy ilyen pályázat, egy ilyen vállalás ennek az előírásnak a megoldásában is segíti az egyetemet;  hasonló problémát jelent a hallgatók számára kiírandó szakdolgozati témák megadása. A pályázat valós, gyakorlati megoldást igénylő feladatok kiírását teszi, tette lehetővé.

4. Összefoglalás Az 1999-ben elindított KKK-program alapvetően sikeresnek bizonyult. Ezt az alábbi eredmények igazolják:

 a korábbi laza és véletlenszerű kapcsolatok mellett létrejött az egyetem és néhány gazdasági vállalkozás tartós, szervezeti szintű kapcsolata;  az oktatási intézményekben jelentős szemléletváltozásra került sor, az oktatásban a korábbiaknál nagyobb mértékben veszik figyelembe és vezetik be a gyakorlati életben előforduló, megoldandó feladatokat;  sok hallgató, doktorandusz és posztdoktor számára biztosított és biztosít szakmailag kihívást jelentő, ugyanakkor anyagilag elismert tevékenységet;  a vállalatok számára közel hozta, könnyebben elérhetővé tette a kutatási kapacitásokat;  megváltozott az a vélekedés, hogy „aki tudja, csinálja, aki nem tudja, oktatja”, hiszen egyrészt az oktatók is „csinálták”, másrészt a vállalkozások dolgozói is „oktatták”;  a hallgatók az első munkába állásuk során már nem egy teljesen ismeretlen közegbe csöppennek, számukra is ismertek a vállalkozásoknál folyó „technológiai folyamatok”, számukra is világos, hogy egy alkotás nem csupán műszaki-tudomá13

A kutatás-fejlesztési központok fejlesztése és megerősítése nyos eredmény, hanem egy termék, amelyet el kell tudni adni, vagyis a műszakitudományos tevékenység mellett fontos és megkerülhetetlen a gazdasági eredményesség is. A gyakorlat oktatásban való mind alapvetőbb megjelenését láthatjuk a (Horváth et al 2010), (Horváth 2011) és (Horváth et al 2011) publikációkban. A kooperációs kutató központok megindulásakor az volt a célkitűzés, hogy a résztvevő intézmények három szakaszban érjék el azt a szintet, amikor már teljesen önállóan meg tudnak állni a saját lábukon. Az induláskor eredményesen pályázó intézmények már a harmadik körnél tartanak, míg az olyan intézmények, mint például az ELTE, a második szakaszt koptatják, illetve fejezik be. Reméljük, számukra is lesz harmadik kör, és annak végeztével minden bizonnyal egy erős központ végzi a kooperációs tevékenységet.

Irodalomjegyzék ELTE-IKKK (2004) http://www.inf.elte.hu/karunkrol/szervezet/tud%C3%A1sk%C3%B6zpontok/Lapok/I KK.aspx ELTE-Soft honlapja (2009) http://eltesoft.hu/ Horváth P., Mogyorósi P. (2005) Értékelési zárójelentés (Kooperációs Kutató Központok Program: A vállalkozások versenyképességére gyakorolt hatások; Expost értékelés eredményei) Netwin Kft és Laser Consult Kft konzorciuma; készült az NKTH megrendelésére Horváth Z., Kozsik T., Lövei L. (2010) Software engineering education in cooperation with industrial partners. Teaching Mathematics and Computer Science 8/1, 133-148 Horváth Z. (2011) Central European Cooperation in Computer Science Education - a CEEPUS network. Conference on ICT Innovation in Central and Eastern Europe supported by EIT ICT Labs Horváth Z., Kozsik T., Lövei L. (2011) Software engineering education in cooperation with industrial partners. Conference on ICT Innovation in Central and Eastern Europe - supported by EIT ICT Labs Pályázat1 (1999) http://epa.oszk.hu/00000/00029/00038/ Pályázat2 (2004) Pályázati felhívás Felsőoktatás és a vállalatok közötti kooperatív kutatást és technológiatranszfert segítő partnerkapcsolatok és hálózatok kiépítésének támogatása (Kooperációs Kutató Központok, KKK) (GVOP-2004-3.2.2) http://www.nih.gov.hu/palyazatok-eredmenyek/gvop/felsooktatas-vallalatok Pályázat3 (2008) PÁLYÁZATI FELHÍVÁS ÉS ÚTMUTATÓ Gazdaságfej-lesztési Operatív Program és a Közép-Magyarországi Operatív Program Kutatás-fejlesztési központok fejlesztése, megerősítése c. pályázati konstrukcióhoz; Kódszám: GOP2008-1.1.2., KMOP-2008-1.1.2. http://www.nfu.hu/doc/1100 14

Egy pályázat hatása az oktatásra és kutatásra Szenátusi határozat (2008) http://www.elte.hu/file/szen081124.pdf Gonda J. (2011) Egy pályázat hatása az oktatásra és kutatásra; Informatika a felsőoktatásban 2011; Konferencia kiadvány, 888-895. o. http://nodes.agr.unideb.hu/if2011/dokumentum/IF2011_CD_Kiadvany.pdf

15

Az ELTE Informatikai Kooperációs Kutatási és Oktatási Központ Összeállította: Kerek Ágnes Szakmailag ellenőrizte: Kozma László

1. A háttér A Nemzeti Fejlesztési Terv Gazdasági Versenyképesség Operatív Program támogatási rendszere keretében benyújtott „ELTE Informatikai Kooperációs Kutatási és Oktatási Központ (ELTE IKKK) létrehozása és működtetése” tárgyú GVOP-3.2.2.-200407-0005/3.0 jelű pályázat 2004-ben került benyújtásra, és 2005 júniusában hatályba lépett a támogatási szerződés. A szerződés a projektben vállalt feladatok teljesítését három éves időtartamban, a 2004. december és 2007. december közötti időszakra vonatkozóan írta elő. Ezek az IKKK elindulásának hivatalos körülményei. A puszta tények mögött azonban, már 2004-ben is lázas és szerteágazó tevékenység zajlott, hiszen a lehetőség óriási volt a frissen önállóvá vált Kar életében. E tevékenységek bemutatására vállalkozunk az alábbiakban. Bár 2004-ben még korántsem élt olyan erősen a köztudatban a tudásháromszög ma oly divatos fogalma, a magyar innovációs politika prioritásai között természetesen már megjelent a tudásalapú társadalom igénye, ami az elérhető pályázati kiírások tartalmát nagymértékben meghatározta. A Nemzeti Fejlesztési Terv keretében a GVOP Irányító Hatóság Kooperációs Kutató Központok, KKK-k létrehozása tárgyában kiírt pályázat elsődleges céljaként a hazai K+F tevékenység versenyképességének, hatékonyságának növelését jelölte meg. Ennek érdekében az elvárás olyan partnerségek, hálózatok létrehozása volt, amelyben felsőoktatási intézmények és az innovációban érdekelt vállalati-üzleti szereplők kooperatív kutatási programja valósítható meg. A KKK-k létrehozásának szándéka azonban jóval többet jelentett pusztán közös kutatási projektek elindításánál. A KKK-k iránti igény egy radikális szemléletváltás eredményeképpen merült fel, amely szerint az innováció, a tudás gyakorlati célú hasznosítása, csakis a felsőoktatásban folyó szakemberképzés, a kutatás és a piaci orientációjú fejlesztőmunka összehangolásával lehet igazán hatékony. A KKK-kra így az a szerep várt, hogy egy új típusú, dinamikus visszacsatoláson működő integratív együttműködési modellt valósítsanak meg vállalatok és felsőoktatási intézmények között. Az ELTE-n az IKKK az elsők között vállalta fel ezt a feladatot.

2. A kezdetek A partnerek köre korábbi sikeres együttműködések nyomán formálódott. Az alapító tagok a következők voltak:

A kutatás-fejlesztési központok fejlesztése és megerősítése  AITIA International Részvénytársaság;  Er-Petro Kereskedelmi és Szolgáltató Korlátolt Felelősségű Társaság;  Multiráció Gazdaság- és Pénzügy-informatikai Fejlesztő és Szolgáltató Kft.;  NETvisor Informatikai és Kommunikációs Szolgáltató Kft.;  ParaComputer Informatikai Bt.;  SQI Magyar Szoftverminőség Tanácsadó Intézet Kft.;  Zolix Számítástechnikai Szaktanácsadó Közkereseti Társaság;  Eötvös Loránd Tudományegyetem Informatikai Kar. A konzorciumnak az IKKK belső felépítése, mechanizmusai, illetve külső kapcsolatrendszerének meghatározása során több szempontot kellett egyidejűleg érvényesítenie. Első lépésben ki kellett dolgozni azon célzott alapkutatási és alkalmazott kutatási projektek körét, amelyek párhuzamos futtatásával az IKKK be tudja tölteni integrációs szerepét. Az egyeztetések eredményeképpen a pályázatban egy öt komponensből álló nyitott szoftverfejlesztő környezet megvalósítását tűztük ki célul, amelyet szolgáltatásszerűen felhasználhatnak az alapító tagok valamint külső vállalkozások kritikus szoftvereik fejlesztésére. Az 5 komponens a következő: 1. adaptív szoftverfejlesztési környezet; 2. multi-ágens alapú szimulációs környezet; 3. szoftverminőség-becslést és-ellenőrzést végző központ; 4. távközlési szolgáltatásmodellező központ; 5. intelligens raszterkép-interpretáló rendszer. Ezeknek megfelelően került kialakításra a projekt öt kutatási főiránya. A technológia- és tudástranszfer IKKK-n belüli optimális működtetése a három pólus, az oktatáskutatás-innováció között további lényeges követelményeket támasztott a célkitűzések megfogalmazása során. Az oktatási póluson első és legfontosabb követelmény a kutatási eredmények oktatásban való megjelenítése volt. Ennek elsődleges csatornáját a reguláris képzés jelentette. A kutatási eredmények tananyagokban való megjelenése mellett fontos cél volt a graduális és posztgraduális hallgatók kutatási feladatokba való bevonása is, ami a piaci szemlélet és alkalmazás-orientált gondolkodásmód közvetítését tette lehetővé. Több diplomamunka, szakdolgozat, PhD-értekezés illetve TDK dolgozat született a kutatási témákban, külső témavezető bevonásával.

18

Az ELTE Informatikai Kooperációs Kutatási és Oktatási Központ A kutatási póluson a pályázati kiírás értelmében olyan kutatási feladatokat kellett kitűznünk, amelyek nemzetközi szinten is aktuális problémák területén számottevő eredményeket tudnak produkálni. Ugyanakkor fontos szempont volt, hogy a témák gazdasági szempontból is relevánsak legyenek, és a generált tudásbázison kereskedelmileg hasznosítható szoftvertermékek/megoldások születhessenek. Az oktatás-kutatási póluson, a humánerőforrás biztosítása terén végül az IKKK működésének nem elhanyagolható hozadékaként új munkahelyek teremtésére, a kutatási kapacitás növelésére nyílt mód.

1. ábra Az IKKK-ban foglalkoztatottak száma és megoszlása Az innovációs póluson a készülő szoftvertermékektől/szolgáltatásoktól várt gazdasági haszon jelenik meg hangsúlyosan. A kutatási eredmények folyamatosan beépülnek a szoftverfejlesztési környezetbe, így azok felhasználásra kerülnek a környezeten fejlesztést végző partnerek által. A környezetet a partnereken kívül szerződéses alapon külső felek is felhasználták. Az IKKK fennállása alatt több nemzetközi és hazai üzleti és kutatási partnerrel kötöttünk szerződést. Végezetül pedig, mintegy a három pólus összekapcsolásaként ki kell emelnünk azt a tényezőt is, hogy az IKKK keretein belül generált tudást a végzett hallgatók magukkal viszik a munkaerőpiacra, amely így vállalatok igen széles körét érheti el. Az ELTE és a partnerek együttműködésének eredményeképpen létrejött technológiai tudástranszfer elősegítette a régió informatikai kis- és középvállalatai versenyképességének megőrzését is, valamint új vállalkozások, új munkahelyek létrehozásához járult hozzá. A kis- és középvállalatok számára olyan középtávú innovációs döntéseket tett lehetővé, amelyek a biztos pályázati támogatás hiányában, a piaci bizonytalansági tényezők miatt nem valósulhattak volna meg.

19

A kutatás-fejlesztési központok fejlesztése és megerősítése

3. Az IKKK működésben Hároméves működése alatt az IKKK-t dr. Kátai Imre professzor igazgatta nagy szakmai hozzáértéssel. A projektfeladatok elvégzése 2004. decemberében indult, és a működőképes IKKK-szervezet létrejöttét követően a stratégiai céloknak megfelelően egyidejűleg és egymást generálva kezdődtek meg a feladatok előkészítési munkálatai, így a kutatási tevékenység megkezdése mellett az oktatási tevékenység előkészítése és beindítása, valamint a termékek/szolgáltatások piaci lehetőségeinek felmérése.

A kutatási főirányok részletes bemutatása 3.1. Adaptív szoftver fejlesztése Az 1. sz. kutatási főirány vezetője Bagoly Zsolt (ELTE TTK Információtechnológiai Laboratórium) volt. Az adaptív szoftverfejlesztési környezet kutatási főirány a humán-számítógép kapcsolat javítását tűzte ki célul: a számítógép-felhasználói szokások automatikus elemzésével és az eredmény egyrészt automatikus, azonnali visszacsatolásként megjelenő alkalmazásával, másrészt a nagyobb, több felhasználót érintő statisztikus analízis alapján a további szoftverfejlesztés elősegítésével lehetőséget teremt arra, hogy a számítógépes alkalmazások (például irodai programok) alkalmazkodni tudjanak a felhasználók igényeihez, szokásaihoz. A főirány keretében kidolgozásra került az adaptív adatgyűjtő rendszer a felhasználói interakciók nyomon követésére, rögzítésére és elemzésére, a kapcsolódó off-line kiértékelő, statisztikai és adatelemző eszközökkel. Elkészült és tesztelésre került egy, az adatgyűjtő alkalmazást magában foglaló OpenOffice.org alapú irodai szoftver. A fejlesztés eredményeképpen létrejöttek az adaptív modulhoz kapcsolódó oktatási anyagok, ami alapján a projekt eredményei az oktatásban is hasznosulhattak. Az adaptív szoftverlabor munkájába számos hallgatónak lehetősége nyílt bekapcsolódni.

3.2. Szimulációs központ A 2. sz. kutatási főirány vezetői Kozsik Tamás (ELTE) és Gulyás László (AITIA Informatikai Rt.) voltak. A kutatási főirány a multi-ágens alapú modellezés és szimuláció magyarországi elterjesztésében kívánt úttörő szerepet vállalni és egyben szolgáltató központ szerepét betölteni. Ennek érdekében került sor egy szimulációs eszköztár (szoftverrendszer) kifejlesztésére. Az ágens-alapú és részvételi szimulációk létrehozását egyaránt támogató szimulációs keretrendszer kidolgozásán túlmenően a kutatási főirányban vizsgáltuk a funkcionális nyelvi megoldások alkalmazásának lehetőségeit is. Ezen kívül kutatások folytak a szimulációs eredmények létrehozását, feldolgozását és publikálását támogató vizualizációs és analitikus módszerek terén. A Szimulációs központ oktatási tevékenységével egyaránt megcélozta a felsőoktatásban tanuló hallgatókat és – tanfolyamok formájában – az üzleti szféra szereplőit.

20

Az ELTE Informatikai Kooperációs Kutatási és Oktatási Központ

3.3. Szoftverminőség-becslést és –ellenőrzést végző központ A 3. sz. kutatási főirány vezetői Balla Katalin (SQI Magyar Szoftverminőség Tanácsadó Intézet) és Kozma László (ELTE) voltak. A főirány az informatikai minőségbiztosítás regionális helyzetének felmérését, az alkalmazott szabványok, modellek, szoftverjellemzők vizsgálatát tűzte ki célul. Szoftverminőségi modellek és szabványok összehangolására vonatkozó modellt dolgoztunk ki, amely az ISO 9001:2000 szabvány és a CMMI modell összehangolásának lehetőségeit mutatja be. Kiemelt területként foglalkoztunk a szoftver minőségének egyik meghatározó elemével, az alkalmazott technológiával. Kutatásunk tárgyát képezte a szoftverek komplexitásának mérése, a fejlesztés során felmerülő bizonytalansági tényezők felderítése, a vállalati alkalmazások számára különösen fontos komponens alapú technológiák vizsgálata. Vizsgáltuk a szoftverbonyolultsági mértékek alkalmazásainak szoftverminőséget érintő és a fejlesztési folyamatra gyakorolt hatásait. Új, általánosan használható és validált bonyolultsági mértékeket dolgoztunk ki, és valósítottuk meg azok szoftveres implementációját. Az elért eredmények felhasználásával speciális előadásokat és tanfolyamokat tartottunk.

3.4. Távközlési támogató alkalmazások A 4. sz. kutatási főirány vezetői Benczúr András (ELTE), Schnell György (NETvisor Informatikai és Kommunikációs Szolgáltató Kft.). A főirányon belül célkitűzésünk egy olyan fejlesztő-oktató-kutatóközpont létrehozása volt, ahol a résztvevők éles, a világpiaci színvonalnak megfelelő szoftverek fejlesztése közben ismerkednek ezzel a szakterülettel, illetve ehhez kapcsolódóan alkalmazott kutatásokat végeznek. Kutatásokat folytattunk többek között a szolgáltatásmodellezés, műszaki nyilvántartás és automatizált létesítés, teljesítmény- és SLA-felügyelet, szélessávú technológiák, NGN OSS, ember-gép interfészek, modell- és szándékorientált szoftvertechnológiák, minőségi, küldetéskritikus szoftverfejlesztési módszertanok területén. A témakörben oktatási tematikákat, segédleteket fejlesztettünk és vezettünk be.

3.5. Intelligens raszterkép-interpretáló rendszer Az 5. sz. kutatási főirány vezetői Elek István (ELTE) és Gábori László (Er-Petro Kereskedelmi és Szolgáltató Kft.) voltak. A kutatási főirány célja elsősorban rasztervektor konverziót is igénylő térinformatikai rendszerek létrehozása volt, amelyek azonban hasznosíthatóak bármely intelligens képértelmező probléma megoldásában is. Az IRIS rendszer (Intelligent Raster image Interpretation System) egy olyan térinformatikai programrendszer, amely előfeldolgozást (szűrési, csoportosító eljárások) követően jó minőségű, automatikus raszter-vektor konverzióra képes elsősorban szkennelt térképeken, űrfelvételeken, légi fotókon. Létrehoztunk egy feldolgozási eljárás-gyűjteményt, megvalósítottunk csoportképző eljárásokat, valamint egy, a tematikus szimbólumok jelentését tartalmazó térképi tudásbázist. Ezzel a térkép/kép felismerés egy intelligens módját valósítottuk meg. Mindezeket a funkciókat egy keretrendszerbe integráltuk. A témakörben oktatási anyagok készültek, előadásokat tartottunk.

21

A kutatás-fejlesztési központok fejlesztése és megerősítése

3.6. Összegzés Az alábbi táblázat a szerződésben vállalt és 2007-ig teljesített feladatokat számszerűsítve mutatja be. Mutató megnevezése Publikációk nemzetközi tudományos fórumokon Nemzetközi kutatási/üzleti partnerek száma Hasznosítható szoftvertermék/megoldás száma Érintett oktatási programok száma Gazdasági partner részvételével készült dolgozat (PhD, TDK, diplomamunka) Több partneres projektek száma Ipari partner által jelentősen támogatott projektek száma

Szerződésben vállalt

Elért eredmény

14

81

4

3

13

14

8

10

12

17

2

3

4

4

2. ábra Projekt szintű mutatók

4. Zárszó helyett Az IKKK három éves fennállása alatt valamennyi szerződésben vállalt feladatának eleget tett, és betöltötte úttörő szerepét egy új együttműködési modell kialakítása terén. Működésének eredményeképpen kialakult egy olyan együttműködési forma, amely mind az ipari partnerek mind pedig az Egyetem számára kölcsönös előnyökkel járt. Már indulásakor számolnunk kellett azzal a nyilvánvaló igénnyel, hogy az elért eredmények, működőképes együttműködési struktúrák továbbélését valamilyen formában biztosítani kell. És bár a konkrét forma sokáig kétséges volt, éppen az együttműködési szándék szilárdságát és az IKKK életképességét bizonyítja a tény, hogy a megteremtett alapokon végül létrejött és sikeres pályázati periódust zárt az ELTE-Soft Kft. Az ELTE IKKK létrejötte óta folyamatosan működik szoros kapcsolatban az ELTE Informatikai Karával és az ipari partnereivel, amelyek között kiemelt szereppel bír az ELTE-Soft Kft.

22

Adaptív szoftverfejlesztési környezet Bagoly Zsolt

Bevezetés Az adaptív felhasználói felület az egyik legérdekesebb és legnagyobb kihívást jelentő feladata a felhasználói felületek fejlesztésének, ugyanis a cél az, hogy olyan felületet készítsünk, amely alkalmazkodik a felhasználó szokásaihoz, és ezt úgy érjük el, hogy lényegében semmilyen információnk nincs arra vonatkozólag, hogy a felhasználó pontosan hogyan kívánja kezelni az adott alkalmazást. Az adaptív környezet előnye elég nyilvánvaló: egy sokak által használt alkalmazás kezelőfelületének kialakítása igen problémás, hiszen rendkívül sok, sokszor egymással ellentmondó feltételeknek kell megfelelni. Elég csak arra az egyszerű példára gondolni, hogy teljesen más menüpontokat/eszköztárakat használ mondjuk egy író és megint mást egy titkárnő. Az esetek többségében – pl. a Microsoft Office-nál – ezt a problémát a felhasználók visszajelzései alapján orvosolják: az első verzió vagy verziók egy, a fejlesztők által elképzelt felülettel rendelkezik/nek, majd az ezt követő verziókat a felhasználók visszajelzései alapján módosítják. Természetesen ez azt jelenti, hogy a felhasználók egy csoportja az eszközölt változtatásokat nehezen fogadja el. Az adaptív technológiának pontosan az a lényege, hogy ezt a problémát orvosolja. Ebben a kontextusban a felület rugalmasan van kialakítva, és a felhasználó szokásait figyelve a felület folyamatosan alkalmazkodik. Az alábbiakban vázoljuk az adaptív szoftverek fejlődését (1. pont), általános leírását (2.pont), majd konkrét megvalósítását az EuroOffice irodai programcsomag keretén belül (3. pont).

1. Az adaptív szoftverek fejlődése Az adaptív módszerek kialakításának ötlete már a számítástechnika korai szakaszában felmerült. Az első ismert adaptív technológiát alkalmazó megoldás a Gordon Pask és Robin McKinnon-Wood által létrehozott Musicolour rendszerben jelenik meg. A rendszer működésének lényege, hogy a zenész által játszott dalt digitalizálják, egy számítógép feldolgozza az adatokat, majd különböző fényhatásokat generál ezek segítségével. A fényhatások ezek után visszahatnak az előadóra, így az alkalmazkodik az új körülményekhez, ami változást idéz elő a dalban. Pask és McKinnon-Wood más fejlesztéseknél is alkalmazta az adaptív technológiát, az egyik ilyen a SAKI (Self-Adaptive Keyboard Instructor) volt. Ez egy zenei oktatóprogram, amely a következőképpen működött. A program gyakorlófeladatokat generált, amelyeket a felhasználó – jelen esetben a zenét tanuló – reakciójának figyelembevételével módosított. Ha sok hiba volt a feladat megoldásában, akkor könnyített, ha jó volt a megoldás, akkor nehezített. Ennek egyik következménye nem csak az oktatás egy részének automatizálása lett, hanem hogy a feladatok egyre változatosabbak lettek.

A kutatás-fejlesztési központok fejlesztése és megerősítése Ugyancsak oktatási céllal fejlesztette ki 1992-ben C. Thomas and M. Krogsaeter a Flexcelt, amely egy adaptív megoldásokat alkalmazó kiterjesztés volt a Microsoft Excelhez. A program a felhasználó által az Excelbe bevitt parancsokat figyeli, azok segítségével feltérképezi a felhasználó szokásait, és ezek alapján különféle javaslatot tesz alternatív megoldásokra. Ennek a módszernek az általános bevezetésére tett kísérletet a Microsoft, amikor 1996-ban bemutatták az office asszisztenst (Office Assistent, amit „clippy”-nek is becéztek). Ez a Microsoft Office-ba beépített segítő különféle tanácsokkal látta el a felhasználót, aminek fogadtatása a felhasználók részéről meglehetősen vegyes volt.

3. ábra Ugyanúgy a Microsoft Office-nál kísérleteztek először adaptív felhasználói felülettel: a Microsoft Office 2000-ben szerepelt az ún. split menu, aminek lényege, hogy a 24

Adaptív szoftverfejlesztési környezet menüpontok fentről lefelé a leggyakrabban használtak szerint voltak rendezve, és csak az első néhány jelent meg. Ez azonban igencsak megosztotta a felhasználókat: a menük folyamatos változását nehezen lehetett követni, így a későbbi verziókban ezt a megoldást már nem használták.

2. Adaptív kezelőfelületek általános modellje Egy adaptív programnak két fontos tulajdonsággal kell rendelkeznie, adaptivitás és adaptibilitás. Az adaptibilitás (3. ábra) a program azon tulajdonsága, amely lehetővé teszi, hogy a felhasználó közvetlen módon változtassa meg a program bizonyos tulajdonságait – felhasználói felület esetén például a színeket, hátteret, betűméretet, ablakok méretét stb. Már az egyszerűbb grafikus felülettel rendelkező programok is rendelkeznek ezzel a tulajdonsággal, a komplikáltabbak esetén pedig ez egyenesen nélkülözhetetlen.

4. ábra 25

A kutatás-fejlesztési központok fejlesztése és megerősítése Kevesebb program rendelkezik az adaptivitás tulajdonságával (4. ábra), amelynek során a program figyeli a felhasználó szokásait, és ennek segítségével változtat a tulajdonságain. Szűkebb értelemben az ilyen szoftvert nevezzük adaptív szoftvernek. Működési elve a következő. A program adatokat gyűjt a felhasználó szokásairól (melyik menüpontokat használja és mikor, használ-e billentyűparancsokat stb), majd ezeket az információkat tárolja. A felhasználónak nem kell közvetlenül megváltoztatnia a kezelőfelületet, ezt ugyanis a szoftver végzi: a beérkezett adatok alapján modellezi a felhasználó szokásait, és megpróbálja „kitalálni”, hogy milyen lenne az ideális felhasználói felület. Ha ez megtörtént, adott szabályok szerint módosításokat eszközöl a kezelőfelületen.

3. Adaptív megoldások az EuroOffice-on belül Az irodai programcsomagok ideális alanyai az adaptív felületek fejlesztésének, ugyanis nem csupán széles körben alkalmazzák azokat, de a kezelőfelületük elég összetett ahhoz, hogy az adaptivitás előnyei nyilvánvalóak legyenek. Jelenleg több irodai csomag is létezik, és ezek különböző megoldást alkalmaznak a kezelőfelülettel kapcsolatos kérdésekben. Az EuroOffice-t az különbözteti meg a többi irodai alkalmazástól, hogy a szokásos megoldásokon kívül rendelkezik adaptív megoldásokkal.

3.1. Az EuroOffice adaptív felület Az EuroOffice jelenleg az egyetlen olyan irodai alkalmazás, amelyik adaptív kezelőfelülettel rendelkezik. Hogy a felhasználók felé rugalmasabb legyen a rendszer, maga az adaptív felület külön kiterjesztés formájában tölthető le és telepíthető. Ráadásul, ha a felhasználó nem kíván a kiterjesztés nyújtotta lehetőségekkel élni, akkor nem szükséges a kiterjesztést eltávolítania, elég az adaptív felület menüpontban kikapcsolnia az adaptivitást. Az adaptív felület során a menüpontok méretei változnak, ami szükségessé tette az irodai program kódjának módosítását, így ez a kiterjesztés csak az EuroOffice irodai alkalmazásra telepítve működik. Mivel az EuroOffice standard kezelőfelülete lényegében azonos az OpenOffice kezelőfelületével, a felhasználók könnyen megismerkedhetnek az adaptív felület nyújtotta lehetőségekkel:  a menüpontok könnyebb használata érdekében megfigyeli a felhasználói szokásokat, és a ritkán használt menüpontokat összezsugorítja. (A felhasználói szokásokat tartalmazó statisztikát a felhasználó saját mappájában tárolja, és sosem továbbítja);  a kurzor alatt látható menüpontot a jobb láthatóság érdekében felnagyítja;  különféle vizuális hatások alkalmazása, mint például a felnagyított menüpontok sima görgetése. Az EuroOffice azonban nem csak a programban, hanem a hozzá tartozó kiter26

Adaptív szoftverfejlesztési környezet jesztéseknél is támogatja az adaptivitást. Ennek implementálása az EuroOffice Extension Creator (EOEC) alkalmazásban történik. Az EOEC szoftver egy segédprogram, amelynek a segítségével egyszerűbbé válik kiterjesztések programozása Python programozási nyelven mind az OpenOffice-hoz, mind az EuroOffice-hoz. A program létrehozza a szükséges könyvtárstruktúrát és azokat a fájlokat, amelyek fontosak lehetnek egy kiterjesztés esetén. Az egyik ilyen fájl – az extensioncore.py – tartalmazza azokat a segédfüggvényeket és osztályokat, amelyeket érdemes a kiterjesztéshez használnunk. Ebben találhatóak azok a függvények és osztályok, amelyek lehetővé teszik adaptív felülettel rendelkező kiterjesztések elkészítését.

3.2. Az EuroOffice Ribbon Az EuroOffice másik adaptivitással kapcsolatos kiterjesztése az EuroOffice Ribbon. Mint a neve is mutatja, ez egy szalag típusú felhasználói felületet biztosít a felhasználó számára. Első pillantásra nem látszik az adaptivitás biztosítása, azonban a kialakítása miatt sokkal rugalmasabb, és lényegesen több lehetőséget biztosít, mint a Microsoft Office hasonló kialakítású kezelőfelülete. Az egyik legfontosabb előnye a programnak, hogy ez kiterjesztés formájában létezik, azaz a felhasználó eldöntheti, hogy telepíti-e, de ha telepítette, és nem kívánja használni, akár ki is kapcsolhatja. Ezen kívül a működése is rugalmas: az EuroOffice Ribbon menüpontban aktiválhatjuk vagy deaktiválhatjuk az új kezelőfelületet, így nem kell feltétlenül a kiterjesztés-kezelőt használni, ha ki akarjuk a szalagot kapcsolni. A kiterjesztés xml-fájlok formájában tárolja a kezelőfelület paramétereit, lehetővé téve annak gyors átalakítását, ugyanis a kiterjesztés úgy van megalkotva, hogy ezeket menet közben is lehet alakítani és így a módosítások azonnaliak. A felhasználó nem csak a kiterjesztésben található xml-fájlokat használhatja, hanem saját maga újakat is készíthet, és egy konfigurációs fájl segítségével használhatja azt a beépített helyett. Ráadásul ezt minden támogatott komponensre (szövegszerkesztő, táblázatkezelő, bemutató-készítő, képszerkesztő és képletszerkesztő) külön-külön elkészítheti, amelyek egymástól függetlenül működhetnek. Az alapul szolgáló xml-fájlokban a felhasználó változatos elrendezésekben hozhat létre különböző GUI-elemekből álló kezelőfelületet. Több különböző elemet lehet definiálni a felületen: gombok, ikonok, jelölőmezők, legördülő menük stb, amelyeknek a méretét és a relatív pozícióját is meghatározhatjuk – ez utóbbi elegendő, ugyanis a méreteket a program automatikusan számolja ki. Hogy még változatosabb legyen az elemek elhelyezése, lehetőség van ún. „dummy” elemeket is definiálni, ami egy adott pozícióba egy üres elemet tesz. A vezérlőelemekhez kapcsolódó parancsokat nem csak a beépített office-parancsok közül lehet kiválasztani, hanem a felhasználó saját maga által írt makrókat is köthet az elemekhez. Ugyanígy bizonyos elemek – pl. legördülő menük – elemei is szabadon megadhatóak. A kezelőfelület – mint ahogy az a szalag-jellegű felületeknél megszokott – több 27

A kutatás-fejlesztési központok fejlesztése és megerősítése fület tartalmaz, amely füleken az elemek blokkokba csoportosítva találhatóak. A felhasználó mind a fülek és blokkok számát, mind azok elhelyezését és csoportosítását is meghatározhatja, és csak rajta múlik, hogy egy blokkhoz hány vezérlőelemet helyez. Az EuroOffice Ribbon kialakításához nem volt szükség az EuroOffice kódjának módosításához, így nem csak EuroOffice, hanem LibreOffice és OpenOffice környezetben is működik. Hogy ezt ellenőrizzük, több tesztjegyzőkönyv is készült azzal kapcsolatban, hogy a különböző operációs rendszereken (Windows XP, Windows 7, Ubuntu) futó különböző irodai alkalmazásokra (EuroOffice, LibreOffice) telepített EuroOffice Ribbon hogyan működik. A vizsgálat során mind a megjelenést, mind a különböző funkciók működését ellenőriztük. Utóbbiak nem csak a különböző vezérlőelemek funkcionalitását, hanem az elhelyezésük változtatását, valamint a ribbon különféle módosítását is jelentették.

28

Európai munkaügyi adatok elemzése Helesfai Gábor

Bevezetés Korunk egyik legnagyobb kihívása a munkaerőpiac alakulásának követése, és annak megértése, hogy milyen tényezők befolyásolják a foglalkoztatottak és munkanélküliek arányát térben és időben. Mivel az Európai Unió a világ egyik legjelentősebb gazdasági tényezője, érdemes ennek a problémának a vizsgálatát ebben a térségben megvizsgálni. A másik tényező, amely miatt érdemes európai országok munkaügyi adatait összehasonlítani, az országok közötti különbségekből fakad. Az Európai Unió kialakulása egy hosszú ideig tartó folyamat, ezért különbségek lehetnek a már korábban az egységes piachoz csatlakozott országok és a később csatlakozottak között. Természetesen a munkaügyi adatok igen sok tényezőtől függenek és ezek elemzése egy rendkívül összetett folyamat. Éppen ezért ezek vizsgálatát első lépésben olyan becslési módszerek segítségével érdemes végezni, amelyek általános trendeket próbálnak az adatokban megtalálni. Ezeknek a módszereknek két típusa létezik: az egyik az adatok földrajzi elhelyezkedését (becslőfüggvények módszere), a másik pedig azok időbeli változását (idősor-analízis) veszi alapul. Az elemzés eredménye természetesen csak egyike azon indikátoroknak, amelyek jellemzik ezt a problémakört, így érdemes azt úgy elkészíteni, hogy maga a módszer többször és más típusú adatokon is elvégezhető legyen. A projekt célja a vázolt problémák megoldása, azaz elkészíteni egy általános elemző rendszert, és ennek segítségével elkészíteni az európai munkaügyi adatokra vonatkozó elemzést. A munkafolyamat több szakaszból tevődött össze, amelyeket az alábbi fejezetekben ismertetünk. Az első fejezetben a statisztikai adatok elemzésével kapcsolatos elméleti hátteret ismertetjük. A második fejezetben a munkaügyi adatok beszerzését és az ezek segítségével kialakított adatbázis kialakítását és felépítését ismertetjük. A harmadik fejezetben az elemző modul és a hozzá tartozó segédprogramok (adatbázis előkészítése, elemzés, riportgenerálás) felépítését mutatjuk be. A negyedik fejezetben az elemzés eredményeit és az azokból levont következtetéseket ismertetjük.

1. Becslési módszerek elméleti háttere Az adatok összetettsége miatt többféleképpen elemezhetjük a munkanélküliségi adatokat. Ezeknek az elemző módszereknek két főbb típusa létezik: az egyik az egyidejű becslés, amelynek során azonos időpontok adatait használjuk, a másik az idősor analízis, ahol egyazon adat időbeli vizsgálatát vesszük alapul.

A kutatás-fejlesztési központok fejlesztése és megerősítése

1.1. Egyidejű becslések Az egyidejű becsléseknek három típusa létezik: direkt, szintetikus és összetett. Az első típusban közvetlenül az adatokból, a másodikban modellek segítségével, a harmadik esetben pedig mindkét módszert felhasználva készül el a becslés. Ezt a típusú elemzést elsősorban kistérségi becslésekre alkalmazzák, ami az EURAREA projekt keretén belül európai szinten részletesen megtörtént. Az elemzés során több típusú modellt néztek több ország adataira, aminek következtében megkaphattuk az optimális becslési módszert. Kiderült, hogy NUTS3 szinten az ún. GREG (G REGression) becslés a legoptimálisabb, amit az alábbi formula határoz meg: =

+

(

−

),

ahol egy adott terület „ ” területegységhez (megye, régió stb.) tartozó becslőfüggvény, egy adott területegységhez „ ” időpontban kiszámolt direkt becslés, az adott területhez tartozó regisztrált munkanélküliek száma, a statisztikai hivatal által készített felmérésben kapott munkanélküliek száma, pedig a regressziós együttható, amelyet az egész országra vonatkoztatva kell kiszámolni. Mivel az EURAREA projekt mélyrehatóan foglalkozott az egyidejű becslések problémakörével, a jelen vizsgálat során az ott tapasztalt eredményeket felhasználtuk, és elsősorban az idősor-analízissel kapcsolatos vizsgálatokra koncentráltunk.

1.2. Idősor-analízis Az idősorelemzés során a feladat az, hogy matematikai statisztikai módszerek felhasználásával egy adott mennyiség időfüggéséből minél több információt tudjunk kiszedni. A problémát az jelenti, hogy a mennyiségek tartalmaznak egy zajfaktort, amely egyrészt a mérés statisztikai jellegéből, másrészt a változók egyéb mennyiségektől való függésének komplexitásából adódik. Munkaügyi adatok esetén az első tényezőben a mintavétel módszere játszik döntő szerepet, míg a másik tényezőt a gazdaságot befolyásoló több különböző tényező okozza. A módszer az esetek többségében az, hogy veszünk egy – empirikus vagy heurisztikus módon meghatározott – modellt, amely leírja az adatok időbeni viselkedését, és ennek a modellnek a paramétereit becsüljük meg úgy, hogy az idősort felbontjuk jel és zaj komponensekre. Munkaügyi adatok esetén nyugodtan feltételezhető, hogy ez a zaj normális eloszlást követ (ez a centrális határeloszlás tételéből következik, ugyanis a munkanélküliséget befolyásoló tényezők várható értéke és szórása is véges, valamint lényegében egymástól függetlenek), valamint, hogy a modell lineáris. Éppen ezért a jel és zaj felbontást érdemes Kálmán-szűrővel elvégezni. A Kálmán-szűrő segítségével elvégezhető egy idősor felbontása jelre és zajra, ha a zaj normális eloszlású, az idősorra alkalmazott modell pedig lineáris. A módszer lényege a következő: [Kalman1] az + 1-edik becslést az -edik becslés és az új mérés súlyozott átlaga adja. A súlyok kiszámítását a kovariancia minimalizálásával kapjuk meg. A rekurzió következménye, hogy a Kálmán-szűrőnek nem kell a teljes adathalmaz 30

Európai munkaügyi adatok elemzése a megfelelő becslés kiszámításához, ami előnyös hiányzó adatok esetén. Mivel az LFS adatok havi vizsgálatát csak 2005-től követelték meg, a havi idősorok nem teljesek, így más módszerrel nem biztos, hogy lehetséges volna a jel - zaj felbontás. A Kálmán-szűrő fenti tulajdonsága viszont nem csak kezeli a hiányos adatokat, hanem a becslés során ezekre a pontokra is produkál jóslatot.

2. Az adatbázis 2.1. Munkaügyi adatok beszerzése és szűrése Az elemzéshez kétféle adatra van szükség: az egyik a rendszeres időközönként végzett statisztikai felmérések eredménye, a másik pedig a regisztrált munkanélküliekre vonatkozó adatok (az utóbbi azért lényeges, mert a becslőfüggvény számításánál ez lesz a magyarázó változó). Ezen adatok beszerzésében sok segítséget kaptunk az ÁFSZ munkatársaitól. A statisztikai felmérések adatait – a tagországok statisztikai hivatalai mellett – egy európai szervezet, az EUROSTAT kezeli. A szervezet lehetőséget biztosít arra, hogy a központi adatbázis foglalkoztatási adatait elemzés céljaira felhasználjuk, így a munkaügyi statisztikai adatok ( Labour Force Survey (LFS) database) az Európai Unió összes tagországára rendelkezésre álltak. Sajnálatos módon hasonló központi adatbázis nem áll rendelkezésre a regisztrált munkanélküliekre vonatkozóan, úgyhogy azokat két forrásból szereztük be. Az egyik ilyen forrás a foglalkoztatási hivatalok online felülete, ugyanis néhány országban ezek nyilvánosan hozzáférhető adatok. Ha valamilyen okból ezek az adatok nem voltak hozzáférhetőek, akkor az ÁFSZ munkatársainak segítségével közvetlenül vettük fel a kapcsolatot az adott ország munkaügyi szervével. Az adatok beérkezése után az első lépés ezek szűrése az alábbi szempontok alapján. A becslőfüggvények elkészítéséhez szükséges, hogy mind a regisztrált munkanélküliekre, mind a statisztikai módszerrel mért munkanélküliségre vonatkozó adatok legalább régió szinten rendelkezésre álljanak. Ezen a szűrőn nem mentek át a NUTS2 méretű országok (pl. Észtország), adatvédelmi törvények miatt az LFS adatbázisban anonimizált régiókat tartalmazó országok (pl. Németország, Ausztria), valamint azok az országok, amelyekhez nem sikerült a regisztrált munkanélküliek adatait beszerezni (pl. Csehország). Végeredményben hét ország (Belgium, Dánia, Franciaország, Magyarország, Portugália, Spanyolország és Svédország) adatait tudtuk felhasználni az elemzéshez.

2.2. Az adatbázis felépítése Az adatbázist a MySQL adatbázis-kezelő program segítségével építettük ki. Az országokra vonatkozó adatok több táblában szerepelnek, így az egységesség mellett az áttekinthetőség is biztosítható. A nyers adatokból különböző scriptek olvassák be a táblákba a szükséges információkat. A fontosabb táblák a következők:

31

A kutatás-fejlesztési központok fejlesztése és megerősítése       

az LFS adatokat tartalmazó tábla; a regisztrált munkaügyi adatokat tartalmazó tábla; az országok nevét és kódjait tartalmazó tábla; az idősorokkal kapcsolatos adatokat (név, mezők) tartalmazó tábla; az idősorokat tartalmazó tábla; a népszámlálási adatokat tartalmazó tábla; az országok régiószerkezetét tartalmazó tábla.

3. Az elemző modul Az elemzéshez használt programok elkészítése során a MultiRáció Kft. által kifejlesztett és a mai napig sikeresen üzemeltetett Kisterületi Munkaügyi Statisztikai Rendszert (KMSR) vettük alapul [KMSR1], [KMSR2]. Bár a program elsősorban magyar kistérségi adatok becslésére lett kifejlesztve, felépítésének és működésének vizsgálata nagyban hozzájárult az európai adatokat elemző rendszer kiépítéséhez. Mivel az elemzések nagy része statisztikai természetű, a program R nyelven készült el. Ezt a programozási nyelvet kifejezetten statisztikai számítások elvégzésére és azok kiértékelésére fejlesztették ki, így több olyan, már előre megírt modult tartalmaz, amely a program működését hatékonnyá teszi. Maga a program több különálló modulból épül fel: beolvasó és előkészítő modul, becslőfüggvény modul, idősorelemző modul és riportgenerátor, amelyeknek a működését az alábbiakban mutatjuk be.

3.1. Adatok beolvasása és előkészítése Az adatok beolvasása két lépcsőben történik. Az első lépésben a nyers adatokat beolvassuk az adatbázisba. Ezt több különböző script végzi, ugyanis míg az LFS adatok egységesek, addig a regisztrált munkanélküliek adatai országtól függően más-más formátumban érkeztek. A második lépcsőben egy R-script beolvassa az adatokat az adatbázisból, majd elvégzi a szükséges előkészítő lépéseket:  beolvassa az LFS és regisztrált munkaügyi adatokat;  aggregálja az LFS súlyfaktorokat és a segédváltozókat régiókra és PSU-kra (PSU – Primary Sampling Unit, a mintavétel alapegysége, amelyre a becslés hibájának kiszámításakor van szükség);  módosítja az adatokat a súlyfaktorok függvényében.

3.2. Becslőfüggvény kiszámítása Hogy a becslőfüggvény kiszámítása általános legyen, ezek számítását egy külön függvény végzi, amelynek a paramétereit a parancssorból lehet változtatni. A paraméterekkel nem csak azt adhatjuk meg, hogy melyik becslőfüggvényt alkalmazzuk, hanem 32

Európai munkaügyi adatok elemzése azt is, hogy milyen típusú rétegzést vagy rétegzéseket vegyünk figyelembe. Ez utóbbi általában a nem, korosztály és iskolai végzettség közül szokott kikerülni. A függvény bemenete az LFS adatokat valamint a regisztrált munkanélküliek adatait tartalmazó tábla, kimenete pedig a becslőfüggvény és annak hibája a munkanélküliekre és foglalkoztatottakra vonatkozóan, valamint a népesség adat.

3.3. Idősorelemzés és modellek Mivel az idősor-analízis során rengeteg változatot kell gyorsan és hatékonyan kielemezni, olyan megoldást kellett találni, ahol a modellek egy nagy családját lehet különböző paraméterek megválasztásával leírni. Ez, és az a tény, hogy az idősoroknál a trend tagot lineárisnak, a zajt pedig normális eloszlásúnak tételezzük fel, az R dlm csomagjának használatára ösztönzött. Ez a csomag, mint ahogy az a nevében is benne van (DLM – Dynamic Linear Model), lehetővé teszi a dinamikus lineáris modellek elkészítését. Ráadásul a csomagban állapotteret tudunk definiálni, azaz a célnak – modellcsaládok leírása paraméterek segítségével – tökéletesen megfelel. Egy teljesen általános dlm-elemet az alábbi egyenletek határoznak meg: ( ) = ( ) ( ) + ( ) ( ) = ( ) ( – 1) + ( ), ahol az idő, ( ) a mért idősor, ( ) a rendszer valódi állapota, ( ) a megfigyelési hiba, ( ) pedig fejlődési hiba. Ha -, pedig -dimenziós, akkor az és mátrixok rendre × illetve × -méretűek. Mivel normális eloszlást tételezünk fel a hibákról, ezért az alábbi feltételek is fennállnak: ( ) ~ (0, ( )) ( ) ~ (0, ( )) (0) ~ ( (0), (0)), ahol ( , ) az várható értékű és szórású normális eloszlást, , és szórásmátrixokat, pedig az a priori eloszlás várható értékét jelöli. Látható, hogy egy dlmobjektum megadásához elegendő megadni az ( ), ( ), ( ), ( ), (0) és (0) értékeket. A gyakorlatban ez úgy került megvalósításra, hogy a modell egy külön scriptben szereplő függvényben van definiálva, amely függvény paraméterei meghatározzák egyrészt azt, hogy melyik modellcsaládot írja le, másrészt azon paramétereket, amelyek a modell specifikálásánál és az illesztésnél játszanak szerepet.

3.4. Riportgenerálás Nagy mennyiségű adat kiértékelése során rengeteg ábra és táblázat készül, amelyet az átláthatóság és a könnyebb kiértékelés érdekében érdemes egy dokumentumba 33

A kutatás-fejlesztési központok fejlesztése és megerősítése beilleszteni. Hogy ez a folyamat ne emésszen fel túl sok időt, egy riportgeneráló program is elkészült, amely ezt automatizálja. A cél a következő volt. Adott egy R parancsokat tartalmazó script, amelynek a kimenete több kép, táblázat és szöveg. Készítsünk egy olyan programot, amely az előbbi R-scriptet tartalmazó odt-dokumentumot átalakít egy, a script helyett a script futásának az eredményét – azaz a képeket, táblázatokat és szöveget – tartalmazó odt-dokumentummá. Az első változat egy parancssorban kiadandó R-program volt, amely az odt dokumentumot közvetlenül az xml struktúrán keresztül írja át. Miután elkészítettük a nyers dokumentumot, a script megkeresi az R programot tartalmazó részt, lefuttatja, majd – az odt szabványnak megfelelően – átírja a dokumentumot. A második változat egy, az EuroOffice irodai programcsomaghoz készített kiterjesztés formájában készült el. A motiváció az volt, hogy a hasonló riportokat a felhasználó általában egy irodai programmal szerkeszti, így a riport elkészítése sokkal kényelmesebb. Miután a kiterjesztés települt, megjelenik az RODTRiport menüpont az „Eszközök” menüben. Ha erre rákattint a felhasználó, akkor a kiterjesztés megkeresi a dokumentumban található és tag-ek segítségével elkülönített programrészeket, azokat lefuttatja, majd az ott meghatározott módon azonnal beilleszti azokat a dokumentumba. A kiterjesztés segítségével képeket, táblázatot és szöveget is beilleszthetünk a dokumentumba, amelyeket formázni is tudunk. A riportgeneráló erőssége különösen a munkaügyi adatokkal kapcsolatos elemzések során nyilvánul meg: minden egyes ország minden régiójához több kép és táblázat is tartozhat, amelyeket kézzel, egyesével a dokumentumba illeszteni rendkívül időigényes lenne. E helyett – felhasználva a kiterjesztés adta lehetőségeket – egy egy-két oldalt kitevő R-scriptet tartalmazó template segítségével az elemzés eredményét közvetlenül integrálhatjuk a riportba. Ezt nem csak a szükséges elemek – kép, szöveg, táblázat – megjelenítését lehetővé tevő függvények segítik, hanem azok a segédfüggvények és változók is, amelyeket a riport elkészítése során gyakran használunk.

4. Munkaügyi adatok elemzése és kiértékelése 4.1. Modellek és paraméterek Bár a dlm-csomag segítségével megadott modellek igen speciálisnak tűnnek, a benne szereplő mátrixok és vektorok dimenziójának tetszőleges volta, az ezekben szereplő paraméterek nem triviális szerepe, valamint ezen értékek időbeli függésének lehetősége szinte korlátlan mennyiségű modell előállítását teszi lehetővé. Éppen ezért érdemes különféle szempontok alapján kiválasztani azokat a modelleket, amelyekre vonatkozó elemzés releváns információt szolgáltat a munkaügyi adatok időbeli változására. Az elemzéshez használt modelleket az alábbi kritériumrendszer alapján választottuk ki: 1. ne legyen sok paraméter: természetesen ez egy elég szubjektív meghatározás, amit azzal tettünk precízebbé, hogy olyan modelleket vizsgáltunk, amelyek kezdeti paramétereit (lásd később) empirikusan értelmezni tudtunk, értékét pedig meg tudtuk becsülni; 34

Európai munkaügyi adatok elemzése 2. trend és szezonalitás: a különböző adatok jellege, illetve korábbi elemzések arra utaltak, hogy a munkanélküliséget jellemző idősoroknak két fő komponense van. Az egyik a trend, amit az adott gazdasági helyzet határoz meg, a másik pedig egy negyedéves szezonális komponens, amely a különböző gazdasági ágazatok szezonális periodicitásával magyarázható. Így tehát olyan modelleket vizsgáltunk, amelyekben elsősorban ezek a tényezők játszanak komoly szerepet. A fenti szempontok azonban még mindig elég általánosak, így ezek közül többféle esetet megnéztünk és összehasonlítottunk: 1. regressziós tag: munkaügyi adatok elemzéséhez érdemes magyarázó változókat használni, ám egyáltalán nem nyilvánvaló, hogy ezeket miként kell figyelembe venni. A leggyakrabban alkalmazott modell a regisztrált munkanélküliek idősorait regressziós együtthatóként veszik figyelembe. A modellcsaládot úgy definiáltuk, hogy paraméterként megadható egy regressziós tag; 2. paraméterek időfüggése: az idősorok ábráit nézve alapból látszik, hogy egyes paraméterek nem állandóak az időben, itt főleg a szórásmátrixok paraméterei jönnek szóba. Ez nem meglepő, hiszen az idők során többször változtak az adatfelvétel körülményei, így érdemes figyelembe venni ezen paraméterek időbeli változásának lehetőségét is. A modell ezt úgy definiálja, hogy megadhatjuk azokat a tartományokat, ahol valószínűleg változás történt, a modell automatikusan figyelembe veszi és időfüggő mennyiségekként kezeli ezeket. A modellválasztáshoz szervesen kapcsolódik a kezdeti paraméterek megválasztásának kérdése, ez ugyanis lényegében az a priori modell megadásával egyenértékű. Könnyen belátható, hogy – főleg időfüggő mennyiségek esetén – a modellben szereplő paraméterek száma még a legegyszerűbb esetben is nagy lehet, ami felveti az ezekre való érzékenység kérdését. Az ebből származó problémákat kétféleképpen oldottuk meg. Egyrészt a modulban helyet kapott egy paraméterbecslő rész is, amely az ún. Maximum Likelihood Estimation (MLE) módszer segítségével adott kezdeti paramétereket megadva meghatározza az optimális paramétereket. Ez úgy történik, hogy az adott paraméterek segítségével felírjuk a likelihood-függvényt (ez egyszerű, hiszen normális eloszlást feltételeztünk), majd azokat a paramétereket használjuk, amelyek ennek az extrémumai. A másik módszer empirikus alapú, a kezdeti feltételeknek megfelelő paramétereket az adott mennyiségek értelmezésének segítségével próbáltuk meghatározni. Az esetek többségében azonban érdemes volt a kettőt együtt alkalmazni: először egy empirikus becslést alkalmaztunk a paraméterekre, majd ezeket optimalizáltuk az MLE módszerrel.

4.2. Kiértékelés Az elemző program képes rövid idő alatt több modellcsaládon végigfutni és elvégezni az elemzést egészen a jelentés elkészítéséig. Ám az így kapott adathalmaz – külö35

A kutatás-fejlesztési központok fejlesztése és megerősítése nösen, ha több modellt több különböző kezdeti feltétellel hasonlítunk össze – még így is nehezen kezelhető, így felmerül az igény arra, hogy szoftveres megoldást találjunk az adatok – legalább félautomatikus – kiértékelésére. Természetesen idősorokra – különösen, ha azok nem sok pontból állnak – nincs általános módszer, viszont van néhány egyszerű szabály, amely segíthet. Mivel ez a terület is folyamatosan fejlődik, a programnak ezen része úgy lett kialakítva, hogy más szempontrendszerek egyszerűen átvehetőek legyenek. Az egyik tényező, amely az adott modellhez tartozik az eloszlás normalitásának vizsgálata. Pontosabban az történik, hogy nullhipotézisként feltételezzük, a Kálmánszűrés után kapott hibatag normális eloszlású, és erre a hipotézisre végzünk teszteket. A leggyakrabban alkalmazott ilyen teszt a Shapiro-Wilk teszt. Ha a teszt eredménye kicsi, akkor a nullhipotézis elvethető. A másik fontos vizsgálat a Ljung-Box teszt, ahol az eloszlás autokorrelációját vizsgáljuk. A nullhipotézis az, hogy nincs autokorreláció. Egy adott szignifikanciaszint esetén a nullhipotézis elvethető, ha a teszt értéke nagyobb, mint , , ahol ℎ a szabadsági fokok száma. Mivel a modellek között rangsort akarunk felállítani, ezért érdekes fordítva gondolkodni, azaz melyik az a modell, amelynél egyre kisebb szignifikanciaszint esetén még nem vethető el a nullhipotézis, a többinél még igen. Erre használhatjuk a tesztek során kapott -értéket, amely pontosan ezt adja meg. Mivel egy modellhez több teszt is tartozik (a Ljung-Box tesztet nem csak autokorrelációra, hanem az eltolt idősor és az eredeti korrelációjára is érdemes alkalmazni), ezért minden modellhez a legkisebb értéket rendeljük, és az a modell lesz a legoptimálisabb, amelyre ez az érték a legnagyobb. A harmadik vizsgálat az ún. heteroszkedaszticitás vizsgálata, amely a variancia időfüggését vizsgálja. Ezt nem tesztek segítségével, hanem azon modellek összehasonlításával végeztük el, ahol az egyik modellben időfüggő, a másikban pedig időben állandó varianciák szerepeltek.

Irodalomjegyzék [Kalman1] Welch G., Bishop G. (2006) An Introduction to the Kalman Filter [KMSR1] Banai M., Koleszár K., Lázár Gy., Lukács B., Prisznyák M., Varga I. (2000) A KISTERÜLETI MUNKAÜGYI STATISZTIKA MÓDSZERTANA ÉS ENNEK ALKALMAZÁSA (I.) [KMSR2] Banai M., Koleszár K., Lázár Gy., Lukács B., Prisznyák M., Varga I. (2000) A KISTERÜLETI MUNKAÜGYI STATISZTIKA MÓDSZERTANA ÉS ENNEK ALKALMAZÁSA (II.)

36

Programtranszformációs technikák és alkalmazásaik Statikus programelemzés és refaktorálás Tóth Melinda, Szűgyi Zalán, Mészáros Mónika, Dévai Gergely, Horváth Zoltán Ipari méretű szoftverkódok karbantartása, későbbi átalakítása vagy éppen megértése nehéz feladat. Ennek legfőbb oka a kódok nagy mérete és komplexitása. Így szükségessé válik olyan szoftverek fejlesztése, amelyek szoftverek forráskódjait elemzik, megértik, illetve azokat a felhasználó igényei szerint tudják transzformálni fél-automatikusan a programozó által vezérelve, vagy esetleg teljesen automatikusan bizonyos kritériumoknak megfelelően. Mindenegyes átalakítás a szoftverek forráskódjában az adott pontokon végrehajtott változásokon kívül sok egyéb ponton megváltoztathatja a program viselkedését. Ezen programpontok kézzel történő megkeresése (és szükség esetén ezek megváltoztatása) igen időigényes, esetenként lehetetlen. Mivel az iparban a programok gyakran csapatmunkában készülnek, egy-egy fejlesztőnek nincs rálátása a teljes szoftver szerkezetére és részleteire, így nem is tudja a szükséges kapcsolatokat felderíteni. Amit nem lehet manuálisan kivitelezni, ott jogosan merül fel a kérés, hogy végezze el a számítógép a programozó helyett, de legalábbis segítsen neki a kivitelezésben. A statikus forráskód-elemző eszközök egyik fő célja, hogy nagy szoftverek forrásait elemezzék, és az elemzések eredményeit célzottan tudják a programozók elé tárni, ezzel megkönnyítve a fejlesztők mindennapos tevékenységeit: felhasználhatóak az elemzési eredmények biztonságos program-transzformációk megvalósítására, de segíthetnek a programozóknak a hibakeresésben, programmegértésben stb. A statikus programelemzési technológiák általánosíthatóak, de azon szemantikus elemzések, amelyek a kódrészletek közötti összefüggéseket, kapcsolatokat tudják elemezni, erősen nyelvspecifikusak. Ennek megfelelően mi három különböző (ám technológiai megoldásokban néhol hasonló) statikus elemző eszközt készítettünk el: RefactorErl (Erlang programok elemzése és átalakítása), F# elemző (F# programok elemzése és stílusegységesítő átalakítása), Grocker (C++ programok elemzése és megértésének támogatása). Ezeken az eszközökön kívül fejlesztettünk egy alkalmazás-specifikus nyelvet is (Feldspar projekt).

1. Erlang projekt – RefactorErl Az Erlang egy dinamikusan típusos, funkcionális, elosztott programozási nyelv, amelyet a 80-as években kezdtek el fejleszteni az Ericsson egyik kutató laboratóriumában. A nyelvet azon célból alkották meg, hogy könnyen és hatékonyan lehessen telekommunikációs szoftvereket fejleszteni benne. Ennek eredményeképpen a nyelv fő jellemzőjévé vált a konkurens, elosztott, valós-idejű, hibatűrő programok írására való lehetőségek biztosítása. A nyelv dinamikussága megnehezíti a statikus elemzést, és bi-

A kutatás-fejlesztési központok fejlesztése és megerősítése zonyos esetekben lehetetlenné teszi a pontos információk kiszámítását. Ezekben az esetekben egy elfogadható minőségű közelítést számolunk és biztosítunk a felhasználónak. A RefactorErl projekt elsődleges célkitűzése Erlang programok refaktorálása volt a statikusan, fordítási időben kiszámított információ alapján. A refaktorálásokhoz szükséges pontos tudás a forráskód szintaxisáról és szemantikájáról azonban jól használható más jellegű feladatokra is. Így a refaktorálás mellett fontos szerepet kapott az ipar igényeinek kielégítése, a programmegértés támogatása. Statikus elemzés és az eredmények tárolása – A statikus programelemzés szükséges eszköze, hogy az előállított információt (úgy mint kódszerkezet, statikus és dinamikus szemantika, függőségek) egy megfelelő reprezentációban tároljunk. Elengedhetetlen feltétel az ipari alkalmazhatóság előkészítéséhez, hogy ez a reprezentáció perzisztens legyen, hatékony adatelérést tegyen lehetővé, valamint az, hogy az elemzések a lehető legnagyobb mértékben inkrementálisak legyenek (azaz kisebb kódrészletek módosítása esetén ne kelljen az egész kódbázist újraelemezni). A perzisztencia szerepe abban nyilvánul meg, hogy sok millió sornyi forráskód elemzése idő- és erőforrás-igényes feladat, így nem tarthatjuk a kiszámított információt csupán a memóriában, ahonnan a program (esetlegesen nem várt) terminálása miatt elveszhet, illetve minden használat előtt újra kell számolni. Ezért egy kompromisszumos megoldással éltünk, amely egy időigényesebb kezdeti elemzési fázist eredményez, ám eltárolja az elemzett eredményeket a merevlemezen is, így azok bármikor, gyorsan hozzáférhetőek. Fontos szempont, hogy az adatokat hatékonyan és gyorsan tudjuk lekérdezni a fejlesztett reprezentációnkból. Ehhez egy Szemantikus Program Gráf (Semantic Program Graph, SPG) modellt dolgoztunk ki, amely lehetővé teszi fix hosszúságú lekérdezésekkel komplex adatok kinyerését. Ez utóbbi egy igen nagy előny az annotált szintaxisfa alapú reprezentációkhoz képest, hisz azokban bizonyos adatok kinyerése csak a teljes szintaxisfa bejárásával érhető el. Az Erlang programokat tehát egy gráfban tároljuk. Az SPG egy irányított, élcímkézett, háromrétegű gráf, amely az Erlang programok lexikális, szintaktikus és szemantikus entitásait tartalmazza a csúcsaiban, az élei pedig az entitások közötti kapcsolatokat reprezentálják. A lexikális réteg tartalmazza mindazon információkat, amelyek szükségesek ahhoz, hogy a program eredeti külalakját meg tudjuk őrizni a transzformálások során. Ebben a rétegben tároljuk mind a lexikális előfeldolgozás (pre-processzálás) előtti és utáni token információt, ezen kívül a megjegyzéseket és white-space információt is. A lexikális és szintaktikus elemzést generált elemzők végzik, amelyeket a RefactorErl projekt által definiált környezetfüggetlen nyelvtan-definíció alapján állítunk elő. Ez lehetővé teszi azt, hogy a nyelv változásaihoz mérten könnyen tudjuk az eszközt hangolni. Másik előnye, hogy ezzel a nyelvtan alapján tudjuk garantálni az automatikus stílushelyreállítást a refaktorálások alatt. A szintaktikus réteg alapja a program absztrakt szintaxisfája, erre a rétegre épül a szemantikus réteg, amely tartalmazza a különböző szemantikus elemzések eredményét: függvényhívási gráf, változó láthatóság, dinamikus hívások, adatfolyamok, mellékhatások stb. Az eszköz egy kiemelt, egyedi funkcionalitása, hogy nem csak forráskódból, de a lefordított forrásokból (bájtkód, beam állomány) is fel tudja építeni a programgráfot. 38

Programtranszformációs technikák és alkalmazásaik Refaktorálás – A refaktorálás olyan szintaxis-alapú forráskód átalakítást jelent, amely a program viselkedését megtartja. Ehhez igen pontos és körültekintő elemzésekre és előfeltétel-vizsgálatra van szükség, amely csak egy széleskörű elemzőrendszerre támaszkodva tud megvalósulni, valamint igen fontos, hogy a szükséges információ hatékonyan kinyerhető legyen. Ezeket a feltételeket teremti meg a RefactorErl eszköz. Másrészt, minden egyes transzformáció másként módosítja a forráskódot, sőt, a refaktorálástól függően egy transzformáció is több ponton módosítja a programot más-más módon. Ha minden szintaktikus elem létrehozását, módosítását, illetve a környező lexikális információ létrehozását le kellene programozniuk az átalakítások fejlesztőinek, akkor igen fárasztó és potenciális hibákat hordozó műveletet kellene végrehajtaniuk. Így a refaktorálásokhoz tartozó program-módosításokhoz egy szintaxisfa-módosítás vezérelt keretrendszert hoztunk létre. Ez a keretrendszer biztosítja, hogy a törölt, beszúrt illetve módosított szintaxisfa-részekhez tartozó környezeti információt (milyen white-space-ekkel kell kitölteni, milyen elválasztókra van szükség) a környezetfüggetlen nyelvtan alapján generálni tudja, illetve, ami szintén elengedhetetlen, a szemantikus információt is helyreállítja. Ez utóbbi esetében fontos, hogy ezt inkrementális módon tesszük, azaz, amikor változtatjuk a forráskódot, nincs szükség a teljes forrás újraelemzésére, csak a módosítás és a környezet alapján helyreállítjuk a szemantikus információt. A RefactorErl eszköz refaktoráló keretrendszere gyors és hatékony prototípus készítést tesz lehetővé. A refaktorálások két elkülönülő részből állnak. Az első fázis az előfeltételek ellenőrzésének és a szükséges információ kigyűjtésének fázisa. Ezek az előfeltételek azért szükségesek, hogy meg tudjuk állapítani, a transzformáció biztonságosan végrehajtható-e, illetve nem változtatja-e meg a program jelentését. Az első fázisban gyűjtögetjük azokat az információkat, amelyek szükségesek az előfeltételek ellenőrzéséhez illetve a későbbi transzformációs részhez. Ha valamely előfeltétel nem teljesül, akkor két eset állhat elő: 1. a transzformáció végrehajtását megtagadjuk, mert a transzformálás megváltoztatná a program viselkedését. Például egy mellékhatásos kifejezést nem emelhetünk ki változóba; 2. kérjük a refaktorálás paramétereinek megváltoztatását a felhasználótól, ha interaktív módban fut a rendszer. Például, ha a függvényátnevezés transzformációnál megadott új függvénynév miatt ütközés lenne a függvénynevekben, akkor erről tájékoztatva a felhasználót, kérünk egy új függvénynevet. A refaktorálás következő fázisa a transzformáció végrehajtása. Bár általában egy egységnek kezeljük a transzformációt, de mégis több apró lépésből áll. Először a konkrét transzformációt hajtjuk végre, majd egy kompenzációs részben további programkódmódosítással elérjük, hogy a program viselkedése ne változzon. Például ilyen kompenzációs fázisnak tekintjük azt, amikor a dinamikus hívásokat transzformáljuk, vagy éppen a makrók törzsét frissítjük a refaktorálásnak megfelelően. A RefactorErl eszköz több, mint húsz implementált refaktorálást tartalmaz, és folyamatosan bővül ezek száma is. Ezeket a transzformációkat több nagyobb csoportba oszthatjuk: 39

A kutatás-fejlesztési központok fejlesztése és megerősítése 1. átnevezések – egy-egy nyelvi elem átnevezése (változó, függvény, modul, fejléc-fájl, rekord, rekord-mező, makró); 2. mozgatások – egy-egy nyelvi egység áthelyezése modulok illetve fejléc-fájlok között (függvény, makró, rekord); 3. függvény interfészének módosítása – a függvény paramétereinek csoportosítása, bővítése, átalakítása (paraméter-átrendezés, paraméterek rendezett -esbe csoportosítása, rekord bevezetése rendezett -es paraméterek helyett, függvény-interfész változás-követés (regexp modulra) stb.); 4. kifejezések belső szerkezetének átalakítása – (függvény-kiemelés vagy behelyettesítés, változó-kiemelés vagy -eliminálás stb.); 5. párhuzamos végrehajtás támogatása – függvények aszinkron végrehajtása, Erlang-viselkedésekké alakítás (gen_server behaviour) stb.; 6. egyéb – importok eliminálása vagy bevezetése, listagenerátorok átalakítása stb. Szoftver-komplexitás metrikák és refaktorálás – Szoftvermetrikák segítségével mérőszámokat adhatunk forráskódok minőségének, megbízhatóságának, karbantarthatóságának mérésére. Több szoftverfejlesztő cég határoz meg kódolási konvenciókat ezen mérőszámok korlátozására. Ezeket a konvenciókat azonban manuálisan nehéz ellenőrizni, illetve a „rossz” kódokat „jó” kódokká transzformálni sem triviális. A RefactorErl elemzéseire támaszkodva szoftver-komplexitás metrikákkal egészítettük ki a rendszert (beágyazottsági mélység, rekurzivitás illetve vég-rekurzivitás ellenőrzés, hívási és hivatkozási számok, stílusjegyek ellenőrzése (pl. megfelelő tördelés) stb.). Ezen metrikaértékek lekérdezhetőek egy metrikus lekérdező nyelv segítségével, illetve lekérdezhetőek a nyelvi entitások tulajdonságaiként a Szemantikus Lekérdező Nyelv segítségével is. Továbbá készítettünk egy prototípus alkalmazást, amely a refaktorálások során figyelmeztetéseket ad, ha valamely metrika kritikus értéket vett fel. Elemeztük, hogy a különböző refaktorálások hogyan hatnak a különböző metrikaértékekre. Ezek alapján ajánlásokat is tehetünk arra, hogy milyen transzformáció tud metrika-értékeket csökkenteni, azaz „jó” kódokat eredményezni. A meglévő refaktorálásainkat felhasználva automatikus refaktorálás-ajánlásokat is adhatunk a programozónak, hogyan használja eszközünket. Tulajdonság-alapú tesztelés és viselkedési ekvivalencia vizsgálat – Ahhoz, hogy biztosítani tudjuk a felhasználókat arról, hogy a RefactorErl rendszer által megvalósított transzformációk nem rontják el a szoftverek viselkedését, széles körben ellenőriztük az elemző- és transzformációs rendszereket. A cél természetesen az eszköz megbízhatóságának növelése és az esetleges hibák kiszűrése volt. Az eset-alapú tesztelési mechanizmusok mellett foglalkoztunk tulajdonság-alapú teszteléssel is, amelynek segítségével az adatok mentén általánosított, specifikációra illetve viselkedési ekvivalenciára támaszkodó ellenőrzést végeztünk.

40

Programtranszformációs technikák és alkalmazásaik Mivel az eszközünket a gyakorlatban is alkalmazni kívánjuk, nyilvánvalóan fontos, hogy a megvalósított transzformációk (és természetesen az egész keretrendszer, amely az elemzéseket, interfészeket biztosítja) jól tesztelt, megbízható legyen, hiszen forráskódok szerkezetét változtatják, így egy hibásan kivitelezett transzformáció elronthat egy egyébként hibátlan programot. Széleskörű tesztelésünk egy fontos szeletét a tulajdonság-alapú teszteléseink adják. Ehhez a QuickCheck tulajdonság-alapú tesztelő keretrendszerre támaszkodva írunk fel tulajdonságokat a refaktorálásokról, és ellenőrizzük véletlenszerűen generált paraméter-értékekre azok teljesülését. A tesztelés generált adatokkal sokkal hatékonyabb, mint előre gyártott teszthalmazzal, hiszen olyan eseteket is magába foglalhat, amelyeket egy fejlesztő sosem írna fel (vagy nem is tudna felírni). A refaktorálások és elemzések véletlenszerű paraméterekkel való tesztelése akkor válik nehézkessé, amikor az elemző és transzformációs lépések bemenetéül szolgáló véletlenszerű programokat akarjuk előállítani, hiszen a program, mint olyan, egy szokatlanul nagy komplexitású tesztadat, amelyet bonyolult a meglévő eszközökkel leírni. Ezt a problémát úgy hidaltuk át, hogy a meglévő adatgeneráláshoz rendelkezésre álló leírók fölé egy jóval absztraktabb réteget emeltünk: formális attribútum-nyelvtanokkal írjuk le a tesztadatainkat, és ezekből állítjuk elő a jól megszokott tulajdonság-alapú tesztelők által feldolgozott adatgenerátorokat. Tehát jelen esetben az Erlang-programoknak megadtuk egy attribútum-nyelvtan leírását, majd ebből származtattuk a megfelelő generátort, amely véletlenszerű (és adott tulajdonságoknak megfelelő) Erlang-nyelvű programok szintaxisfáját állítja elő. A szintaxisfákat természetesen szöveggé alakítva töltjük be az elemző rendszerbe. A véletlenszerű programok előállítása mellett az eszköz tulajdonság-alapú teszteléséhez szükség van egyéb adatokra és a tesztelendő tulajdonságra is. Refaktoráló folyamatainkat úgy teszteltük az ismertetett generált programokon, hogy a refaktorálási paramétereket is véletlenszerűen generáltuk, továbbá transzformáció-specifikus módon megfogalmaztunk megőrzendő programtulajdonságokat, vagy éppen azt írtuk le tulajdonságokban, hogy milyen jól meghatározott módon kell megváltoznia a kódnak (például, ha kiemelünk egy kifejezés-sorozatot egy függvénybe, akkor a hívási gráfban egygyel több függvény lesz, és meghatározott módon létrejön egy új él, amely abból a függvényből mutat az új függvénybe, amelyből a kifejezéseket kiemeltük). A refaktorálásoknak egyetlen fontos közös tulajdonsága van, miszerint a program észlelhető viselkedését nem változtatják meg, így olyan tesztelő tulajdonságot is felírtuk, amely a viselkedési ekvivalenciát vizsgálja a transzformáció előtti és utáni kód között. A transzformációk mellett teszteltük az elemző folyamatainkat és a forráskódok tárolására felépített szemantikus gráfot is. Az elemzők tesztelésekor különösen figyelni kellett arra, hogy az elemzéseket párhuzamos aszinkron folyamatok végzik, így bizonyos tulajdonságok nem determinisztikusak. Kódmegértés támogatása – Amint azt korábban említettük már, az ipari igényeket követve az eszköz elemzéseinek eredményét a rektorálásokon kívül is felhasználhatóvá tettük. Ennek központjába a kódmegértés támogatása került. Ennek eredményeképpen fejlesztettünk egy lekérdező nyelvet, amely a RefactorErl szemantikus információit elérhetővé teszi az Erlang-fejlesztők számára; függőségi kapcsolatokat számítottunk és tettünk elérhetővé a fejlesztőknek. 41

A kutatás-fejlesztési központok fejlesztése és megerősítése Clustering – Clustering (klaszterezés) alatt azt a folyamatot értjük, amikor a nyelv entitásait csoportosítjuk az azok közötti kapcsolatok alapján. A RefactorErl rendszer támogatja modulok és függvények csoportosítását. Az előbbi egy jellemző használati esete, hogy a lehető legjobban kapcsolódó modul-csoportokat határozzuk meg egy nagyobb modul-halmazból, mindemellett pedig azonosítsuk azokat a modulokat, amelyek könyvtári modulként több clustert is használnak. Ez a modul-clustering, mely eredményeképpen előálló kisebb csoportok már könnyebben karbantarthatóak. A csoportosítás egy másik formája a függvény-clustering, amely nagyra duzzadt modulokban implementált függvényeket csoportosít a közöttük lévő kapcsolatok alapján több kisebb modulra. Ennek a végrehajtásához a modulok szerkezetét is át kell alakítani, amelyet a refaktorálásaink támogatnak (mozgatások, átnevezések stb.). Szemantikus Lekérdező Nyelv – Definiáltunk egy lekérdező nyelvet, amelyet úgy terveztünk, hogy a lehető legnagyobb mértékben alkalmazkodjon az Erlang-nyelv fogalmaihoz, így lehetőleg könnyen elsajátítható legyen a fejlesztők számára. A nyelv az Erlang-nyelv szemantikus entitásai köré épül. Selector-ok formájában határozzuk meg az entitások közötti kapcsolatokat, illetve property-k formájában kötöttünk tulajdonságokat hozzájuk. Ezek mellett lehetővé tettük az eredmények szűrését, illetve lekérdezések összefűzhetőségét, iterálását, lezárását, beágyazását. Szemléltetésként lássunk egy példát: 1. a „mods” egy entitás, amely azonosítja az elemzett modulokat; 2. a „funs” egy selector, amely a modulokban implementált függvényeket adja vissza; 3. a „name” egy property, amely egy adott modulra visszaadja, annak nevét; 4. a „dirty” egy property, amely egy függvényről megmondja, hogy mellékhatásos-e; 5. „mods[name = ”mod1.erl”].funs[dirty]” egy lekérdezés, amely megadja a „mod1” modul mellékhatásos függvényeit. Függőségi kapcsolatok vizualizálása – A függvények közötti kapcsolatokat a függvényhívási gráfon keresztül lehet legjobban vizualizálni. Így készítettünk egy alkalmazást, amely függvényhívási gráfokat rajzol. Ezek a gráfok tartalmazzák a dinamikus függvényhívás-információkat is, illetve jelölik, ha a hívások mentén körök keletkeznek a gráfban. A függvényhívási kapcsolatok alapján modul-függőségi gráfokat is definiáltunk, amelyek alapján akkor van kapcsolat két modul között, ha van olyan függvény az egyik modulban, amelyik meghívja a másik modul egy függvényét. Tehát a függvényhívási gráfból kiemelt információt vetítjük át a modulokra. Mivel ezek a gráfok ipari alkalmazások esetén igen nagyra nőnek, ezért különböző szempontok szerint tettük lehetővé az eredmények szűkítését, hogy az információ, amely rákerül egy-egy függőségi gráfra, feldolgozható legyen az emberi szem számára. Modul-csoportok közötti kapcsolatgráfot is azonosítottunk, amely a modulok közötti függőségeket vetíti a modul-csoportokra. 42

Programtranszformációs technikák és alkalmazásaik Ipari felhasználás támogatása különböző interfészekkel – Ahhoz, hogy minél inkább ki tudjuk szolgálni a felhasználók különböző igényeit, több interfészen keresztül is elérhetővé tettük a RefactorErlt. Az Erlang-fejlesztők által leginkább használt szerkesztőkbe és fejlesztői környezetekbe (Emacs, Vim, Eclipse) integráltuk a rendszert, de emellett támogatjuk az egyszerű konzolos használatot is. Elérhetővé tettünk az Erlang shellből egy interaktív és egy szkriptelhető interfészt is. Ezen kívül támogatjuk a parancssori használatot is. A leginkább ipari használatot megcélzó fejlesztésünk a RefactorErl webes felülete, amely lehetővé teszi egy jellemzően távoli szerveren futó RefactorErlhez való csatlakozást egy böngészőből. Ez a felület főként a kódmegértés támogatási funkcionalitását biztosítja, a kódok nézegetését támogatja, módosítását nem. Támogatja a több-felhasználós használatot, azaz egy-egy futó RefactorErl példányhoz több fejlesztő tud csatlakozni. Ez utóbbi azért fontos, mert az ipari használat tanulsága az, hogy 2-3 millió sornyi forráskód elemzése erőforrás-igényes feladat (8-10 GB memóriaigénye van, és 10-15 óráig tarthat a kezdeti elemzés elvégzése), amely erőforrás nem áll rendelkezésre a fejlesztő asztali gépében. Mivel egy fejlesztő csapat általában ugyanazon a forráskód-halmaz különböző részein dolgozik, ezért költségkímélőbb, ha egy szerveren futó RefactorErl-példányhoz többen hozzá tudnak férni. A korábbiakban ismertetett interfészek is támogatják a távoli szerverhez való kapcsolódást.

2. C++ projekt – Grocker A projektet ipari partnerek támogatásával fejlesztjük. Célja egy statikus elemző program készítése, amely elsődleges feladata, hogy segítse a programozót ismeretlen, ipari méretű kódok megértésében. Az elemzőt C++ programozási nyelvhez fejlesztjük, de a belső adatszerkezeteinket úgy terveztük meg, hogy nyelvfüggetlen módon reprezentálja a programot. Ezáltal az elemzőnk kiterjeszthető tetszőleges programozási nyelvek, sőt, interfész-leíró nyelvek elemzésére is. Mivel a projekt célja, hogy ipari méretű forráskódokat elemezzen, ezért fontos, hogy képes legyen óriási méretű adatszerkezetek kezelésére és azokban való hatékony keresésre. Az adatszerkezetek mérete akkora lehet, hogy nem biztos, elfér a memóriában. Az elemzőnket úgy terveztük, hogy az adatokat adatbázisban tároljuk és csak a gyakran használatos részek legyenek a memóriában. Mindez transzparens módon történik, a perzisztens modul által. A többi modul felé az egész adatszerkezet úgy látszik, mintha az egész a memóriában lenne. A projekt az ismeretlen szoftverek megértésének segítségére összpontosít. A megértéshez a szoftver statikus elemzése és összefüggéseinek feltérképezése mellett szükséges az elemzések eredményeinek megfelelő megjelenítése is. A projekt során kutatásokat végeztünk a megjelenítés lehetőségeiről. Fontosnak tartottuk, hogy az eredményeinket egyszerű formában, könnyen áttekinthető módon jelenítsük meg, úgy, hogy minden lényegi információt megtartsunk. A felület tervezésekor figyelembe vettük a különböző felhasználói igényeket. Például egy menedzser más aspektusaira kíváncsi egy projektnek mint egy programozó. Ezen felhasználói igények kielégítéséhez különböző nézeteket definiáltunk. Ezek mellett a rendszer eszközöket ad, amelyek segítik a programozót, hogy a megszerzett tudását regisztrálja és stratégiát alkosson az ismeretszerzés 43

A kutatás-fejlesztési központok fejlesztése és megerősítése további irányai felé, emellett a menedzserek számára statisztikát készít a projekt állapotáról. Ezek mellett a rendszer keretet ad ahhoz, hogy a felhasználók elekronikus módon rögzítsék a rendszerrel kapcsolatban megszerzett információkat, és ezeket az információkat megosszák egymással. Jelen pillanatban három nézet áll rendelkezésünkre az alkalmazásunkban, amelyek azonban a későbbiekben bővíthetők, kiegészíthetők. 1. A szöveges nézet a forráskód szövegszerű megjelenítésére szolgál, és elsősorban a programozóknak ajánljuk; 2. az UML-szerű nézet a program moduljainak kapcsolatát írja le. Hasznos információkat szolgáltat mind programozóknak, mind menedzsereknek; 3. a 3D nézet a projekt felépítését háromdimenziós fastruktúrában ábrázolja. Főként menedzsereknek hasznos, mivel az egész projekt szerkezetéről ad képet; 4. a szintaxisfa nézet a forráskód absztrakt szintaxisfáját ábrázolja. Ez a speciális nézet mindig aktív, és folyamatos szinkronizációban van a többi nézettel, azaz, ha a fenti három nézetben kiválasztunk egy elemet, akkor az a speciális nézetben is aktív lesz és fordítva. Ez a nézet ezáltal vezérlőként is szolgál. Több felhasználó kezelése – Mivel az eszközünket elsődlegesen arra a célra terveztük, hogy ipari környezetben használják, ezért szükséges, hogy támogassa a több-felhasználós üzemmódot, azaz a programozók lássák egymás publikus megjegyzéseit, amelyeket hozzáfűznek a kódhoz, illetve a menedzser meg tudja nézni, kinek melyik modult mennyire sikerült megértenie. A program moduláris szerkezete lehetővé teszi, hogy egy elemző részhez több kliens is csatlakozzon: egy céges környezetben az elemző modul tud egy szerveren futni és a grafikus felület erre rá tud csatlakozni. Így hosszabb távon a Web-es kliensnek meg lesz az a nagy előnye, hogy egy dolgozó úgy tudja használni az elemzőnket, hogy valójában nem kell semmit sem telepítenie a gépére, elég a kedvenc böngészőjével rácsatlakozni a szerveren futó alkalmazásunkra. Mindazonáltal szükségesnek tartjuk, hogy legyen egy önálló programként létező kliensprogram is, amely nem függ a webes szabványok korlátaitól. A programunk azonban önállóan egy helyi gépen is tud működni, ezáltal egy dolgozó akkor is tudja használni az alkalmazást, ha az adott cégben még nem építették ki az infrastruktúrát a kliens-szerver használathoz.

Megjelenítési módok – Amint azt korábban már említettünk, az eszközben többféle nézetben is meg tudjuk jeleníteni a forráskódokat. Szöveges nézet – A szöveges nézet a forráskód szöveges megjelenítésére szolgál. A kapcsolat természetesen itt is megvan a speciális nézettel, azaz, ha rákattintunk a forráskód egy entitására, akkor az aktiválja a megfelelő absztrakt szintakszisfa-elemet a speciális nézetben. 44

Programtranszformációs technikák és alkalmazásaik A szöveges nézet rendelkezik a ma elvárható szolgáltatásokkal, például szintakszis kiemelés, a kódblokkok bezárása stb. Ezen felül vizuálisan is jelzi az annotált entitásokat. UML-szerű nézet – Az UML-nézet elsődlegesen a megértendő projekt modulszintű összefüggéseit hivatott megjeleníteni. Segítségével könnyen meghatározhatjuk a rendszer kulcsmoduljait, valamint képet kapunk a modulok egymásra épüléséről és kapcsolataikról. A nézetet úgy terveztük, hogy ne csak az osztályokat írja le és azok egymás közötti kapcsolatát jelenítse meg, hanem tetszőleges szerkezetű modulok megjelenítésére alkalmas legyen. Ezáltal nemcsak a C++ programozási nyelv objektumorientált paradigmát támogató nyelvi eszközeivel megírt programokat tudja ábrázolni, hanem a nyelv más paradigmái alapján fejlesztett projektek megjelenítése sem okoz gondot. Sőt, nemcsak a C++ nyelven megírt programokat, hanem más, például egy interfész-leíró nyelven definiált absztrakt projekteket is vizualizálni tud. 3D-nézet – A 3D-nézet a megértendő projekt struktúrájáról egy háromdimenziós megjelenítést ad. Ez a nézet elsősorban a projekt magasabb szintű áttekintésére szolgál, de a mélyebb összefüggéseket is ki tudja mutatni. A nézetet elláttuk a kényelmes használatához szükséges funkciókkal, mint a nézet forgatása, nagyítása, kicsinyítése, görgetése. A kezelő felületen beállíthatjuk, hogy milyen részletességgel ábrázolja a projekt összefüggéseit, így lehetőségünk van a teljes projektről egy átfogó képet kapni, valamint a projekt egy részletére ránagyítva a részletesebb információkat is kinyerni. A projekt megismertségének fokát színkódokkal ábrázoljuk, amely látványos képet mutat a projekt megértésének állapotáról. Ezen felül különböző sémák beállítására is lehetőségünk van. A nézet használatához OpenGL szükséges, és ajánlott a hardveres gyorsítás.

A program telepítése, használata – A programunk tervezésekor egyik fontos szempont volt, hogy egyrészt kiszolgálja a vállalati igényeket, másrészt pedig könnyen kipróbálható legyen. Ezt úgy oldottuk meg, hogy minimalizáltuk a programunk külső függőségeit. Más szóval, – ésszerű keretek közt – minden külső eszközt hozzáadtunk a programunk csomagjához. Ennek egyik kritikus pontja az adatbázis-kezelő volt. Vannak robusztus, jól skálázható, nagy terhelhetőségű, vállalati felhasználásra szánt adatbázis-kezelő rendszerek, amelyek telepítése bonyolultabb, és vannak könnyen telepíthető, könnyűsúlyú adatbázis-kezelők is, amelyek kevésbé alkalmasak vállalati környezetben való használatra. Mi azt a megoldást választottuk, hogy készítettünk egy sqlwrapper modult, amely biztosít egy konkrét adatbázis-független interfészt az adatok eltárolására, beolvasására, majd implementáltuk a kapcsolatot több adatbázis-kezelő rendszer felé. Így a programunk tetszőleges adatbázissal együtt tud működni. Jelen pillanatban a MySql és az SQLite adatbázis-kezelő alkalmazásokat támogatjuk. A programunk csomagja beépítetten tartalmazza az SQLite adatbázis-kezelőt is, ezáltal letöltés és telepítés után a programot külön adatbázis-kezelő szoftver telepítése nélkül rögtön ki is lehet próbálni. 45

A kutatás-fejlesztési központok fejlesztése és megerősítése A felhasználók számára, az egyszerű telepítés lehetőségének érdekében a projektből Linuxos telepítőcsomagot készítünk Suse és Ubuntu disztribúciókhoz, de a projekt build rendszere által könnyen lefordítható forráskódból is.

3. F# Projekt Az F# egy multiparadigmás programozási nyelv, amelyet a Microsoft fejlesztett ki az OCaml nyelv alapjaiból kiindulva. A nyelv célja, hogy ötvözze az imperatív, a funkcionális és az objektumorientált nyelvek valamint a .Net keretrendszer előnyeit. Az Eötvös Loránd Tudományegyetem Informatikai Karának kutatócsoportja F# nyelven írt programok elemzését segítő programcsomagot készített, amely programok elemzésére és szintaktikus refaktorálására szolgáló keretrendszeren túl tartalmaz még hatékonyság vizsgálatára alkalmas eszközöket is. Saját munkánkat a – szintén saját fejlesztésű – tulajdonság-alapú tesztelést megvalósító eszközünkkel ellenőriztük. Statikus elemzés - Az F# programok elemzését szolgáló kódelemző eszközünk segítségével egy F# programról le tudjuk választani és vissza tudjuk illeszteni annak dokumentációs szerkezetét (formázások és megjegyzések). A módszerünk előnye, hogy a leválasztás után a dokumentációs szerkezet és a tényleges programkód külön-külön is elemezhetővé, feldolgozhatóvá és átalakíthatóvá válik, ugyanakkor – mivel a dokumentációs szerkezet visszailleszthető – nem vesznek el a programból a felhasználó számára lényeges részek. A dokumentációs szerkezet leválasztása – A dokumentációs szerkezet leválasztását a tokenek formázásának kigyűjtésével kezdjük, amelyet egy speciális lexikális elemző végez. Az elemzés során mindenegyes tokennél feljegyezzük a formázást. Az elemzés után a tokenek formázása elhagyható, amely a gyakorlatban egy – az adott token típusától függő – átalakítást vagy egyszerűsítést jelent. A műveletet a tördelés leválasztása követi, amely során egy speciális nyelvi elemző nyelvi szerkezetenként feljegyzi a tördelést, majd törli a white-space-eket a programkódból. A leválasztás utolsó lépése a megjegyzések leválasztása. Az elemzés során heurisztikák segítségével minden megjegyzésről kikövetkeztetjük, hogy a programkód mely részére vonatkozik. Feljegyzés után a megjegyzések is törölhetőek a programból. A dokumentációs szerkezet elemzése – A formázás leválasztása után a forráskódban – nyelvi elemenként – meghatározzuk a leggyakrabban használt stílust és az ettől való esetleges eltéréseket. Ez tárolás szempontjából is előnyös (a továbbiakban elég csak ezeket tárolni), de ennél hasznosabb eredménye ennek a módszernek, hogy ezek után nagyon könnyen meg tudjuk mutatni egy adott kód vagy egy programozó stílusát, valamint azonnal rá tudunk mutatni a programkód azon részeire, ahogy a stílus eltér a programban jellemzően használttól. A dokumentációs szerkezet visszaillesztése – Elsőként a megjegyzéseket helyezzük vissza a kódba, mégpedig pontosan ahhoz a nyelvi elemhez, amelyhez tartoztak. Ha leválasztás és visszaillesztés közben a program bizonyos részei más helyre kerültek, akkor a megjegyzés is automatikusan az új helyre fog kerülni. Ezek után a tárolt stílusinformációk alapján visszaillesztjük a white-space-eket, és megformázzuk a tokeneket. 46

Programtranszformációs technikák és alkalmazásaik Stílusegyesítő transzformálás – Eszközünk segítségével a programkódról leválasztott stílusinformáció külön elemezhető. A dokumentációs szerkezet elemzésekor meghatározott leggyakrabban használt stílust és az ettől való eltéréseket felhasználva a szintaktikus refaktor eszközünk segítségével könnyedén átalakíthatjuk a programokat. Az egyik legkézenfekvőbb stílusegyesítő átalakítás során úgy változtatjuk a programot, hogy mindenhol a leggyakrabban használt stílust használja. Ehhez nem kell mást tenni, mint az „eltérések listáját” (azokat a stílusinformációkat, amelyek különböznek a leggyakrabban használtaktól) törölni, majd a módosított dokumentációs szerkezetet visszailleszteni. Ez az átalakítás azért is hasznos, mert az egységes stílusú programok jobban átláthatóak, így potenciálisan kevesebb hibát tartalmaznak, így eszközünk – közvetett módon – a programok helyességét is növeli. Szintaktikus refaktoráló eszközünk ahhoz is használható, hogy átalakítsuk a programkódot egy adott kódolási konvenciónak megfelelőre. Ebben az esetben elég a leggyakrabban használt stílust módosítani az új kódolási konvenciónak megfelelően, majd ezt egy üres eltérés-listával visszailleszteni a kódba. Ez utóbbi funkció különösen hasznos a nagy és több programozó által közösen készített szoftver-rendszerek esetében, így eszközünk hasznos kiegészítője lehet a verziókövető rendszereknek. Keretrendszerünk használata megkönnyíti a refaktor programok írását is, amelyben – módszerünk szerint – refaktorálás előtt a program dokumentációs szerkezetét leválasztjuk a forráskódról, majd a refaktorálás után visszaillesztjük. Ezzel a módszerrel refaktorálás során sem a kód stílusával, sem pedig a megjegyzések elhelyezkedésével nem kell foglalkozni, így a refaktorálást végző kód egyszerűbb és lényegre törőbb lehet. Habár a módszerünk nyelvfüggetlen, annak implementációja erősen függ a konkrét nyelvtantól, így azt is megvizsgáltuk, hogy ezt a függőséget hogyan lehet gyengíteni. Ennek a megoldására született egy módszer, amely egy olyan nyelvet definiál, amely segítségével EBNF-ben megadott nyelvtanokhoz lehet a kódok nyelvfüggő részeit generálni, ezáltal is növelve a keretrendszer adaptálhatóságát más nyelvekre. Hatékonyságmérés – Az F# programok elemzését szolgáló eszközünk többféle hatékonyságmérő eszközt is tartalmaz:  a programban mely adatszerkezeteket milyen gyakorisággal és hatékonysággal használtunk;  a program hány tényleges programsort, hány üres sort és hány csak megjegyzést tartalmazó sort tartalmaz;  milyen függvényeket használtunk a programban és milyen gyakorisággal;  egyszerűbb tisztán funkcionális függvények költségeit ki tudjuk következtetni. Tulajdonság-alapú tesztelés – A program minőségének biztosítására tulajdonság-alapú tesztelést készítünk. Tulajdonság-alapú tesztelés során a tesztelendő funkcionalitás elvárt viselkedését specifikáljuk predikátumok formájában egy alkalmas nyelvi eszközkészlettel, majd véletlenszerűen generált tesztadatokat használva a program bemeneteként ellenőrizzük, hogy a specifikált predikátumok minden esetben teljesülnek-e. A predikátumokban feltételeket fogalmazhatunk meg a bemeneti adatokra, leírhatjuk, 47

A kutatás-fejlesztési központok fejlesztése és megerősítése hogy milyen tulajdonságai vannak a végeredményeknek, és specifikálhatjuk a bemenet és a kimenet közötti kapcsolatot. A tulajdonság-alapú tesztelést használtuk a forráskód egységesítését végző szintaktikus refaktoráló eszközünk ellenőrzésére is.

4. Feldspar projekt A digitális jelfeldolgozásnak számos ipari alkalmazása van, ezek jellemzően valós idejű, sebességkritikus rendszerek. Ez igaz projektünk célterületére, a telekommunikációs célú digitális jelfeldolgozásra is. Ezeket a rendszereket speciális célú hardvereszközökön futtatják, kihasználva azok speciális utasításkészletét és párhuzamos programozási támogatását. Ezeket az eszközöket alacsony szinten, jellemzően C nyelven programozzák, mert így a programozó teljes felügyeletet kap a hardver speciális szolgáltatásai felett, és képes kihasználni azokat. Ennek azonban ára van: a programkódok nehezen áttekinthetőek, nem hordozhatóak, fejlesztésük és karbantartásuk költséges. A Feldspar-projekt célja egy alkalmazásterület-specifikus programozási nyelv és fordítóprogramjának megalkotása, amelynek futási idejű hatékonysága versenyképes a jelenleg használt programokkal szemben, ugyanakkor jelentősen emeli a programozás absztrakciós szintjét, így orvosolva a felsorolt problémákat. A nyelvet az Ericsson, a svédországi Chalmers egyetem és az ELTE-Soft Kft. és az ELTE kutatói közösen fejlesztik. Az ELTE feladata elsősorban a fordítóprogram fejlesztése, amely képes a magas absztrakciós szintű Feldspar programokat hatékony, hardverközeli tárgykóddá transzformálni. A generált tárgykód C-nyelvű program, hiszen – az eddigiek alapján – a projekt számára fontos célhardvereket jellemzően ezen a nyelven programozzák. A Feldspar beágyazott nyelv. Ez azt jelenti, hogy a programozó számára biztosított felülete több, speciálisan megvalósított Haskell könyvtárból áll, azaz a Haskell a Feldspar gazdanyelve. A könyvtárak által biztosított függvények nem számításokat végeznek, hanem egy adatszerkezetet építenek fel, amely az elvégzendő számítást reprezentálja. Ez az adatszerkezet a fordítóprogram illetve az interpreter bemenete. Ez a felépítés számos előnnyel rendelkezik: nincs szükség lexikális, szintaktikus és szemantikus elemzésre, mert ezeket a feladatokat a gazdanyelv (esetünkben a Haskell) fordítóprogramja megoldja. A Haskell programozási nyelvre több ok miatt esett a választás. Egyrészt kiválóan alkalmas gazdanyelvnek, hiszen szintaxisa minimális, típusrendszere pedig kiemelkedően fejlett, ami nagyon hasznosnak bizonyul a beágyazott nyelvek szemantikájának kifejezéséhez. A másik ok, hogy a Haskell számos nyelvi eleme (például listafeldolgozó függvényei) jól használhatóak vektorok feldolgozásához, ami fontos a digitális jelfeldolgozó algoritmusok szempontjából. Így a Feldspar célja tulajdonképpen az, hogy Haskell-be ágyazzuk be azokat a Haskell nyelvi elemeket, amelyek az alkalmazási területünkön jól használhatók és megfelelően hatékony alacsony szintű kódra fordíthatók. Fordítóprogram – A Feldspar nyelv célja, hogy digitális jelfeldolgozó algoritmusokat magas absztrakciós szinten, konkrét hardver-architektúráktól és operációs rendszerektől függetlenül lehessen megfogalmazni. Ez a koncepció az iparban azonban 48

Programtranszformációs technikák és alkalmazásaik csak akkor versenyképes, ha létezik a nyelvhez egy olyan fordítóprogram, amely képes a jelenleg alkalmazott, tapasztalt programozók által fejlesztett alacsony szintű, platformfüggő, C-nyelvű programokkal összevethető teljesítményű tárgykódot generálni. Ez a Feldspar fordítóprogramjának feladata. A fordítási folyamat első lépése, hogy a Feldspar program Haskell-programként kerül ellenőrzésre a Haskell fordító (vagy interpreter) által, így kiderülnek az esetleges típushibák. Ezután a programot a Haskell futtatókörnyezete végrehajtja, és ennek során felépül a Feldspar program ún. magnyelvi reprezentációja. Ezen reprezentáció építése során már számos magas szintű optimalizációs lépés kerül végrehajtásra. A magnyelvi reprezentációt a Feldspar fordító átalakítja az úgynevezett absztrakt imperatív formára. Ez már az imperatív programozási nyelvek megszokott konstrukcióit tartalmazza. Ezen a reprezentáción hajthatók végre az alacsony szintű és hardverfüggő optimalizációs transzformációk, az optimalizált programot pedig utolsó lépésként C-nyelvű programszöveggé alakítja a fordítóprogram. Az alacsony szintű optimalizációs transzformációk felhasználják a klasszikus statikus programanalízis módszereit, hiszen ezek segítségével dönthető el, hogy egy átalakítás ekvivalens programot eredményez-e. Ezeket az elemzéseket és magukat az átalakításokat az absztrakt imperatív reprezentáción valósítottuk meg. A Feldspar fordító egyes publikus kiadásaiban az alábbi optimalizációs transzformációk kerültek megvalósításra:

 konstansok és változók továbbterjesztése a programkódban előre haladva;  konstansok és változók visszafelé terjesztése;  ciklusok kigörgetése;  konstansok összevonásának speciális esetei;  C99 szabvány szerinti, optimálisabb függvényszignatúrák generálása. Az elemzési és transzformációs lépések implementációja során megfigyeltük, hogy ezek megvalósítása egy jól behatárolható sémát követ: Mindegyik meghatározott sorrendben bejárja a szintaxisfát, közben információt közvetít a csúcspontok között. Az információtovábbítás irányát tekintve elkülönítettünk felülről lefelé, alulról felfelé terjedő, valamint állapot-jellegű információkat. Ezek a megfigyelések egy keretrendszer kidolgozásához vezettek, amelynek használatával egységesen és lényegesen rövidebben lehet leírni az elemzési és transzformációs lépéseket. Az absztrakt imperatív reprezentációhoz kidolgoztunk egy felhasználói interfészt is, amelynek segítségével minta - akció párosokat írhatnak fel a Feldspar felhasználói. Ezeket a mintákat a Feldspar fordító illeszteni próbálja a fordítási folyamat során keletkező imperatív reprezentációra, és az illeszkedő kódrészleteket a megadott akciónak megfelelően átalakítja. Ezzel a technikával eszközt adtunk a felhasználók kezébe, hogy testre szabhassák a keletkező C programkódot. Az eszköz implementációja szintén a korábban említett keretrendszer segítségével valósult meg. 49

A kutatás-fejlesztési központok fejlesztése és megerősítése A Feldspar nyelv egyes könyvtárai már a szintaxisfa felépítése során is végeznek optimalizációs célú tevékenységeket. Ezen könyvtárak kidolgozása többnyire a svéd egyetemi kutatócsoport feladata volt, de a hatékonyságelemzések tapasztalataira támaszkodva az ELTE kutatói is hozzájárultak ezen könyvtárak fejlődéséhez:

 sikerült hatékonyabbá tenni a konkatenáció műveletét a több szegmensből álló vektorok bevezetése segítségével;  az általunk kidolgozott bitvektor könyvtár használata gyorsabb, és kevesebb memóriát igénylő tárgykódhoz vezet a logikai értékek sorozatát használó algoritmusok megvalósításakor;  a Feldspar magnyelvének reprezentációjához javasolt változtatásaink hatékonyabbá tették az adatfolyamok feldolgozását. Kidolgoztunk egy véges adatfolyamokat kezelő könyvtárat;  a digitális jelfeldolgozáshoz speciálisan készített hardverek egyik jellegzetessége a SIMD (single instruction, multiple data - egy utasítás, több adat) optimalizáció képessége. Ezek speciális utasításokat jelentenek, amelyek képesek például egyszerre négy számpáron elvégezni valamilyen aritmetikai műveletet. Sikerült kidolgoznunk a Feldspar-hoz egy SIMD-könyvtárat, ahol az algoritmusok implementációjának absztraktságát megőrizve, a programozó által kontrollált módon lehet SIMD-optimalizációt használni. A Feldspar fordító elkészítése során külön figyelmet kellett szentelni a digitális jelfeldolgozásban kitüntetett szereppel rendelkező tömböknek és mátrixoknak. A Feldspar nyelv egy flexibilis és absztrakt tömb- illetve vektor-fogalmat használ. A fordítóprogram szempontjából a leglényegesebb különbség a C nyelv által biztosított tömbökhöz képest, hogy a Feldspar tömbjei számon tartják a méretüket. A különbség áthidalását konzisztens módon egy új C-típus bevezetésével oldottuk meg, amely egységes módon képes kezelni az egy- és többdimenziós tömböket, és számon tartja a bennük tárolt elemek számát, valamint a rendelkezésre álló pufferterületet. Kiegészítő funkciók – Mivel a Feldspar beágyazott nyelv és a könyvtárai által biztosított függvények nem számításokat végeznek, hanem az elvégzendő számításokat reprezentáló adatszerkezetet építenek fel, mely számos előnyt és hátrányt hordoz. Előnye, hogy nincs szükség lexikális, szintaktikus és szemantikus elemzésre, mert ezeket a feladatokat a gazdanyelv (esetünkben a Haskell) fordítóprogramja megoldja. Hátrány viszont, hogy nem férünk hozzá a forráskód szöveges reprezentációjához. Ez pedig megnehezíti a felhasználók munkáját, amikor a generált tárgykód és a forráskód közötti összefüggéseket keresi, hibát keres, vagy a program futását szeretné nyomon követni. Ennek a problémának a megoldása érdekében több fejlesztést is végeztünk: 50

Programtranszformációs technikák és alkalmazásaik

 a Feldspar fordítóprogramja képes a generált kódban megőrizni a forráskódban használt függvény- és paraméterneveket. Ezt egy előfordító segítségével valósítottuk meg, amely kigyűjti a forrásszövegből azoknak az azonosítóknak a neveit, amelyeket a generált kódban meg szeretnénk jeleníteni a könnyebb olvashatóság érdekében. Az előfordító által kigyűjtött azonosítók a fordítás későbbi fázisában az absztrakt imperatív reprezentációba kerülnek beillesztésre a korábban említett transzformációs keretrendszer segítségével;  megalkottunk egy nyelvi primitívet, amely lehetővé teszi a programok nyomkövetését: ∶:

−>

−>

A függvény tehát kap egy egész számot, amely a nyomkövetés során azonosító szerepet tölt be. A másik paraméter egy Feldspar-érték, amelyet a függvény változtatás nélkül visszaad eredményként. A függvény funkcionalitás szempontjából tehát lényegében identitás, a belőle generált C-nyelvű tárgykód azonban egy mellékhatásos függvényhívás, amely egy logfájlba írja a megadott azonosítót, a függvényhívás időpontját és a Feldspar-értéket. Módszert dolgoztunk ki a beágyazott programozási nyelvek forráskódjának és az abból generált tárgykód közötti kölcsönös megfeleltetés előállításához. Az ötlet a gazdanyelv (esetünkben a Haskell) fordítójának újrafelhasználása. Ezen fordító szintaktikus elemző modulja segítségével előállítjuk a program gazdanyelvi szintaxisfáját. Ebben a szintaxisfában megtalálhatóak a forrásszöveg pozícióinformációi is. A nyelvi primitívek közé felveszünk egy új, címkézésre alkalmas konstrukciót. Ennek segítségével újrageneráljuk a forráskódot az eredeti pozícióinformációkkal felcímkézve az egyes kifejezésrészleteket. A módosított forráskódot ezután a beágyazott nyelv fordítóprogramja dolgozza fel, amely az egyes transzformációk végrehajtása során karbantartja a pozícióinformációkat, a tárgykód generálásakor pedig egymáshoz rendeli a forrás- és a tárgykód egymásnak megfelelő pozícióit. Ez a reláció a tárgykód mellett a fordító kimenete. A módszer Feldspar-ra történő alkalmazása folyamatban van. Rendszer réteg – Eddig a Feldspar nyelv és a hozzá készült fordítóprogram azon moduljairól esett szó, amelyek a digitális jelfeldolgozást végző rendszerek adatfeldolgozó algoritmusainak fejlesztését célozzák. Ezt nevezzük adatfeldolgozó rétegnek (datapath layer). Kutatásunk kiterjedt a nyelv egy olyan kiterjesztésére is, amely az adatfeldolgozó algoritmusokat egységes alkalmazásba szervező rendszerközeli réteg (system layer) leírására is alkalmas. A rendszerközeli rétegnek biztosítania kell az egyes algoritmusok ütemezését, a közöttük való adatáramlás technikai megvalósítását (üzenetküldéssel vagy osztott memóriával), a rendszer dinamikus újrakonfigurálhatóságát. A rendszerközeli réteg egy párhuzamos rendszer, amely az operációs rendszer és a Feldspar-eljárások között he51

A kutatás-fejlesztési központok fejlesztése és megerősítése lyezkedik el, fogadja a feldolgozandó adatokat, és végrehajt rajtuk egy meghatározott transzformáció-sorozatot. Ilyen transzformációs láncok egymástól függetlenül, párhuzamosan működnek, és önállóan konfigurálhatók. Feltérképeztük a rendszerközeli réteggel kapcsolatos elvárásokat, és modellt alkottunk a működésének leírására. Tanulmányoztuk a Haskell programozási nyelv által biztosított nyelvi eszközöket abból a célból, hogy a rendszerközeli réteg leírására egy absztrakt nyelvet hozzunk létre. A feladat megoldása érdekében kidolgoztunk egy adatfolyamok leírására alkalmas beágyazott nyelvi réteget a Feldspar nyelv részeként. Az adatfolyam-gráf csomópontjaiban önmagukban nem párhuzamos Feldspar programok találhatók, a gráf élei pedig a közöttük fennálló adatáramlást definiálják. Az adatfolyam-gráf párhuzamos feldolgozási láncai jelzik a párhuzamosítás lehetőségét. Ütemezéshez a következő sémát használtuk: az elérhető processzormagok számának megfelelő szálat indítunk, amelyek feladatot keresnek maguknak egy pufferből. Lefuttatható feladat a gráf egy olyan csomópontja, amelynek bemenő adatai rendelkezésre állnak. A naiv round robin ütemezés nem minden esetben vezetett az elvárt hatékonyság eléréséhez, ezért nyelvi elemeket dolgoztunk ki a feladatok több különböző pufferbe való beosztásához és a feladatválasztás algoritmusának finomhangolásához. Tesztelés – A generált C-programok hatékonyságát és helyességét folyamatosan monitorozzuk. A feladat automatizálása érdekében kifejlesztettünk egy tesztelő keretrendszert, amely minden éjszaka több száz Feldspar-program esetén vizsgálja a fordítóprogram és az interpreter konzisztenciáját. Ezen túlmenően a tesztelő rendszer a következő képességekkel is rendelkezik:  programok futási idejének automatizált mérése;

 programok fordítási idejének automatizált mérése;  a tesztelés lefedettségének mérése Összefoglalás – A fentiekben bemutattuk a Feldspar programozási nyelv és fordítóprogramja fejlesztésének azon aspektusait, amelyek a nemzetközi fejlesztő csapaton belül az ELTE kutatóinak feladatkörébe tartozott. A fejlesztések eredményei több publikus kiadásban jelentek meg, amelyek elérhetőek a http://feldspar.inf.elte.hu weblapról. Az Ericsson jelenleg vizsgálja a nyelv ipari alkalmazhatóságának lehetőségeit.

52

Mobil technológia alkalmazásai Lőrincz András

1. Intelligens mobil alkalmazások A technológia rohamos fejlődése egyre közelebb hozza azokat az alkalmazásokat, amelyek már partnerként segítik a felhasználót. Ehhez a felhasználó evolúciós adottságait és kényszereit, valamint kulturális megszokásait is figyelembe kell vennie a gépnek. Evolúciós adottság és kényszer például a kommunikációs modalitás, a kép, hang, tapintás és szagok halmaza, amelyben sem a billentyűzet, sem az egér nem tekinthető optimálisnak. Az intelligens kommunikáció másik eleme, hogy intelligens partnereink az aktuális helyzet viszonyát saját céljaikkal kapcsolatban igen hatékonyan tudják jelezni, például nevetéssel, sírással, dühös arckifejezéssel, esetleg parancsszavakkal vagy fenyegető mozdulatokkal. Hasonló kulturális háttérrel rendelkező partnerek félszavakból is megértik egymást. Régóta kapcsolatban levő emberek már rezdülésekből is tudnak következtetni. Egyes „játszmákban” (vö. játékelmélet), például pókerben vagy diplomáciai, üzleti tárgyalásokban az ilyen 30 − 100 időtartamú és általában leplezhetetlen mikroérzelmek felismerése nagy előnyhöz juttathatja a tárgyaló felet. Fordítva: ha a gép nem ismeri fel azokat a jeleket, amelyeket küldeni szoktunk kommunikációink során, akkor a gépi kommunikáció lassú lesz, hatásfoka kicsi lesz, az együttműködés szintje alacsony lesz. Olyan lesz a szituáció, mint amikor egy autista partnerrel szeretnénk megegyezésre jutni. Az intelligens mobil alkalmazásokban tehát elsődleges az érzelmi állapotok, érzelmi jelek felismerése. Különösen aktuális a feladat, mert a mobil eszközök rendelkeznek frontális kamerával, velünk vannak egész nap, pontosan detektálhatják mozgásunkat, szituációinkat, szokásainkat. Minden adott tehát az okos telefonok számára ahhoz, hogy tevékenységünket megismerjék és előre jelezhessék. Hatékony akkor lesz az előrejelzés, ha csak akkor szólal meg a „partner”, ha kell és ha lehet, tehát ha az információ fontos és annak felfogására képesek is vagyunk. Projektünk erről szól, az arc mozgásának detektálásához és az arckifejezésfelismeréshez készítettünk algoritmusokat. Az algoritmusok egy része már fut Android mobil eszközökön. Hivatalos indításuk május végére várható. Ez az alkalmazás halmozottan fogyatékos személyek számára teszi lehetővé a számítógép használatát.

A kutatás-fejlesztési központok fejlesztése és megerősítése

2. OpenCV „fejegér” Android operációs rendszerre 2.1. Történeti áttekintés A mobileszközök piacra kerülésének kezdetén kizárólag gombok segítségével volt elképzelhető a vezérlés, a navigálás, és a különféle funkciók is ezek segítségével voltak elérhetőek. Minden eseményt egy adott gomb váltott ki a pillanatnyi menütől és az adott szoftvertől függően. Később megjelentek alapszintű hangvezérlést kínáló mobiltelefon szoftverek, ám kiforratlan mivoltuk és a hardverek felkészületlensége miatt nem tudtak egyszerű és gyors navigálást nyújtani a felhasználóknak a rendszer felett. Az érintőképernyő piacra kerülésével a végfelhasználók már közvetlenül a kijelzővel érintkezésbe lépve tudták irányítani készülékeiket, amely jelentősen felgyorsította a navigálást és az információszerzést. Itt már megkaptuk a lehetőséget, hogy maguknak az érintések tulajdonságainak a manipulálásával (érintési erősség, érintési idő, stb.) tudjuk befolyásolni a kiváltott eseményt anélkül, hogy a pozíciót megváltoztatnánk. A mobiltelefonok komoly platformmá nőtték ki magukat, egyre jobban felzárkózva az asztali számítógépek képességeihez, megtartva a hordozhatóságot és az áruk – a telefonos árukapcsolás következtében – elérhető és versenyképes.

2.2. A probléma Az érintőképernyők azonban örököltek bizonyos hátrányokat, valamint újakat hoztak létre. Vannak olyan körülmények, amikor kényelmetlen, esetleg nem lehetséges vagy nem biztonságos fizikai interakciót létesíteni a mobileszközünkkel. Néhány példa erre:  a fagyos, hideg idő rendkívül kényelmetlenné teszi a készülékünkkel folytatott interakciót, ellehetetlenítve így a kezelést a szöveges üzenetek küldésétől a navigálásig;  telefonon történő filmlejátszás közben felmerülhet az igény fényerő, hangerő állítására, amelyet kivitelezve megszakad az élmény, és így kellemetlenséget és frusztrációt okoz;  vezetés közben veszélyhelyzet jöhet létre, ha készülékünkkel foglalkozunk, és ha a tevékenység mind figyelmünket, mind kezünket igénybe veszi. A probléma másik oldala a mozgássérült, fogyatékkal élő emberek és a mobileszközök kapcsolatának kérdése. Számítógépekre már évek óta léteznek alternatív megoldások, azonban mobil platformokra ez a probléma korántsem megoldott. Mozgásukban korlátozott emberek gyakran nem tudják kezelni ezeket az eszközöket, mert számukra egyik vezérlő interfész sem alkalmas. Az érintőkijelzők elterjedése lehetővé tette, hogy a fenti problémákat áthidaló, innovatív, mégis az érintést élethűen szimuláló megoldást adjunk. A telefon előlapi kameráját használva vizsgálhatjuk a felhasználó fejmozgását (amennyiben a kamera számára az tisztán látható). A fej mozgatása is teljes kontrollt tesz lehetővé a rendszer felett, ha a 54

Mobil technológia alkalmazásai mozgást kurzormozgássá transzformáljuk. A kontroll közvetlen fizikai interakciótól mentes.

Egy másik algoritmuscsoport az arckifejezés becslésével foglalkozik. Olyan algoritmust választottunk és fejlesztettünk, amely jól párhuzamosítható annak érdekében, hogy a mobil eszközbeli GPU használatával elég gyors lehessen. Az eredményeket publikáltuk, publikáljuk. A módszert számítógépes játékok alatti viselkedés felismerésére és intelligens, emocionálisan is illesztett segítségnyújtásra kívánjuk felhasználni.

55

IRIS és alakzatfelismerés Digitális képelemzési módszerek a térinformatikában Topografikus térképek raszter-vektor konverziójának automatizálása Szendrei Rudolf

A téma ismertetése A kutatási célunk az volt, hogy a térinformatikában ismert raszter-vektor konverzió problémáját kutassuk, áttekintsük a tudomány mai állása szerint a témához kapcsolódó módszereket, bemutassuk ezek előnyeit és hátrányait, majd pedig ezek alapján újakat hozzunk létre. Az új módszerektől azt vártuk, hogy további eszközök álljanak rendelkezésére azoknak, akik a raszter-vektor transzformációt szeretnék vizsgálni, vagy akár saját alkalmazást szeretnének készíteni a jövőben. További célunk volt, hogy a módszereket egy saját magunk által elkészített keretprogramba ágyazva biztosítsunk egy olyan rendszert, amelyben a térképészek által igényelt speciális eszközök könnyen beépíthetők, használhatók. Ahhoz, hogy ezt hatékonyan tudjuk használni, néhány fontosabb módszert magunk implementáltunk.

A kutatás mérföldkövei Első lépésként kutatásokat végeztünk a szakirodalomban két fontos szempont szerint. Egyrészt a meglévő módszereken túlmutatóan akartunk kutatni, amihez szükséges volt tisztában lenni azzal, hogy mely problémakörökre adottak már hatékony megoldások. Ezeket a szükséges, kismértékű változtatásokkal alkalmaztuk. Szintén fontos volt számunkra, hogy adott módszereknél melyek azok a csapdák, amelyek zsákutcákat jelenthetnek. A kutatásunk alapját képező témakörök az előbb említetteken kívül találhatóak, lévén térképi textúrázottsággal mindezidáig érdemben nem foglalkozott kutatás. Második lépésként áttekintettük azokat a fájlformátumokat, amelyek raszteres képek tárolására szolgálnak, illetve azon vektoros adatszerkezeteket, amelyeket térképek, térképi objektumok leírására használnak napjainkban. Elemeztük és rangsoroltuk ezeket a probléma és a felhasználhatóság szempontjából. Szintén vizsgálat tárgyává tettük, hogy az igen sok helyen használt, elterjedt tömörítési szabványok miként befolyásolják a megoldhatóságot. Ez alatt értjük például a kvantálást, a wavelet vagy diszkrét koszinusz-transzformáció által keltett látható illetve szemrevételezés szempontjából nem szignifikáns eltérések következményeit. Mivel a téma alapját raszteres képek feldolgozása adja, ezért meg kellett ismerkednünk azokkal a digitális szűrési módszerekkel, amelyek segítik a konverzió végrehajtását. A digitalizált térképek raszteres változatai mind színüket, mind tónusaikat tekintve – akár a nyomdai eljárásnak, akár a feldolgozó elektronikának köszönhetően –

A kutatás-fejlesztési központok fejlesztése és megerősítése többel rendelkeznek, mint amennyit egy felhasználó a térképet vizsgálva megkülönböztet. Ezen okból szükséges, hogy az adott színeket csoportokba foglaljuk. Ez a színtérben történő klaszterezés és osztályozás, kvantálás, vagy más egyéb módszerrel történő lépés szerves része a folyamatnak. Ezek alapján olyan szűrőket kerestünk, valamint hozzájuk olyan paramétereket, amelyek együttesen egy hatékony szűrőbankként funkcionálnak.

A kutatás célja Elképzeléseink szerint a problémára ismert eszközök tárházát az eddigi vektorizálási módszereken kívül szerettük volna a minták felismerésének lehetőségével bővíteni. Ez a meglátás a mintaillesztés általánosítását jelentette esetünkben. Segítségével a térképek textúrázottságát többlet-információként lehet hasznosítani. Az eddigi vektorizálási módszereket tekintve mondhatni egyedüliként alkalmazták az éldetektáló szűrőket. Mivel a számítógépes világban a térképi objektumokat pontnak, vonalnak, szakasznak vagy továbbmenve poligonoknak tételezzük fel, ezért az élek kulcsfontosságú szereppel bírnak. Szükségünk van ezek meghatározására, megtalálására ahhoz, hogy egy adott poligont kifejezhessünk annak határoló oldalaival. Ezt a módszert általában a csúcs- vagy sarokdetektorokkal szokták finomítani. Ennek lényege az, hogy közvetlenül a poligon csúcsait keressük. Bármelyik módszert is vesszük alapul, vagy alkalmazzuk akár együttesen, hatékonyan és megbízhatóan csak olyan térképeket fogunk tudni feldolgozni segítségükkel, amelyek nem rendelkeznek átlapoló objektumokkal. Tipikus problémát jelentenek azok az esetek, amikor fontossági sorrend alapján a térképi rétegek egymást elfedő módon kerülnek ábrázolásra. Erre igen egyszerű példa az, amikor hidat ábrázolunk egy folyón. A képen ilyenkor a folyó poligonja megszakad, vagy precízebben megfogalmazva, a folyó több poligonra bomlik.

A raszter-vektor konverzió háttere Fontos alapkőként kell kezelnünk a fentiek ismeretében a térképek hierarchikus, strukturált felépítését. A térképeknek sok fajtáját ismerjük, az egyszerű utcaszintű mindennapos használatra szánt változattól a kataszteri típusún át az űrfotókig bezárólag. Utóbbi kivételével ezeknél sokféle ábrázolási, jelölési módszerrel találkozhatunk. Nem jelenthetünk ki egyetlen módszert sem győztesként, amely képes lenne megbirkózni az ezek által hordozott összes anomáliával, ezért nem is vártuk el, hogy találunk olyan teljesen automatikusan működő eljárást, amely külső beavatkozás nélkül egy raszteres térképet vektoros formába konvertál. Vagy ha képes is lenne minderre, az eredmény korántsem lenne kielégíthetőnek mondható. Ezért gyengítettünk az elvárásainkon, és csupán azt szögeztük le, hogy a programot használó személynek minimális mennyiségű döntést kelljen hoznia a program használata során. Ezek a döntések több okból adódhatnak.

58

IRIS és alakzatfelismerés A felhasználói közbeavatkozás elkerülhetetlen annak érdekében, hogy a kívánt vektoros terméket előállítsuk. Ennek az is az oka, hogy a felhasználók különböző módon értékelhetnek ki bizonyos szituációkat, attól függően, hogy milyen célt szeretnének elérni a konverzió használata során. Ahhoz, hogy csökkentsük a felhasználóhoz intézett kérdések számát, az eljárásnak tanulékonynak kell lennie. A sok hasonló problémára adott azonos válasz esetén képesnek kell lennünk olyan adatbázist felépíteni és használni, amely a gép előtt ülő személynek a problémához való viszonyulását modellezi. Egy kellően jól felépített modell sokat segíthet a konverzió végrehajtásában azzal, ha a döntési helyzetekben megfelelően szimulálja a várt válasz eredményét. Ezekhez a szimulációkhoz valószínűségi változókat kell rendelnünk, és meg kell határoznunk azok valószínűségét. Az ilyen módon készített statisztikát felhasználhatjuk a valószínűség-számításban használt tételek és bizonyítások segítségével úgy, hogy minimalizáljuk az adott szituációban a félreosztályozás valószínűségét. Egyik igen érdekes kutatási terület, hogy milyen módon építünk fel egy térképek vektorizálását segítő tanuló algoritmust. Ilyenkor arra keressük a választ, hogy az ilyen típusú algoritmusok a valószínűségi küszöbértékek függvényében milyen osztályozási pontosságot tudnak elérni várható értékben. Le kell szögeznünk, hogy a tanuló algoritmusok segítségül szolgálnak, de a felhasználónak minden körülmények között rendelkeznie kell azzal a lehetőséggel, hogy megváltoztasson számára esetlegesen nem tetsző döntéseket. Pontosan ezek a döntések az alapkövei egy tanulási folyamatnak. Ezek azok a visszajelzések, amelyek befolyásolják a későbbi szimulált döntéseket. Ezzel a módszerrel nem csak csökkenthetjük a feldolgozási időt, de folyamatosan tanuló adatokkal látjuk el a rendszert. Fontos hangsúlyozni azt, hogy ahogyan a térképeknek is igen sok típusa létezik, úgy típus szerint külön-külön modelleket kell felépíteni ahhoz, hogy megfelelő szimulációt nyerjünk. Végül, de nem utolsó sorban foglalkoznunk kell azokkal a térképi többlet-információkkal, amelyek egy átlagos szemlélő számára kézenfekvőek ugyan, mégis, ezek nélkül a konverzió eredménye pusztán poligonok halmazának volna tekinthető. Korábban már említésre került az, hogy ugyan mi tudjuk, a folyó átfolyik a híd alatt, mégis, ábrázolást tekintve kettéosztja a híd a folyó poligonját. Az ehhez hasonló okok követelik meg azt, hogy foglalkozzunk az objektumok hierarchiájával, ábrázolási jellegzetességeivel, amelyek jórészt feloldhatják azokat a problémákat, amelyeket a nélkül csak kézzel, egyedileg tudnánk kezelni. A hierarchiát tekintve azon anomáliával kívántunk foglalkozni, amikor egymástól diszjunkt poligonok egy csoportja nem térképi objektumot jelöl, hanem a térképnek az adott területre vonatkozó jellemzőjének kulcsát ábrázolja. Ez tipikusan akkor fordul elő például, ha mondjuk egy lankás tájat valamilyen egységes típusú növénytakaró borít. Ekkor a növényzet típusát jelölhetik akár apró kis köröcskék is. Tudjuk, hogy ezek a köröcskék a konverzió során poligonokká alakulnak. Az is világos, hogy a térképen 59

A kutatás-fejlesztési központok fejlesztése és megerősítése nincsenek ezeken a helyeken valódi objektumok. Ezeket a jeleket mintázatként értelmezhetjük. A mintázat felismerésére az éldetektáló és csúcsdetektáló módszerek lehetnek kiindulási alapok ugyan, de ezek eredményei nehezen hasznosíthatóak a feladat szempontjából. Ezekkel kapcsolatban mutattunk be olyan módszereket, amelyek szerves részét képezték kutatásainknak.

A térképi textúrázottság felismerése A mintafelismerésre használt első módszer a számítógépes grafikában ismert mintaillesztésen alapul. A nehézségeket csökkentve feltehetjük, hogy a minta a képen nem lett elforgatva, tükrözve, nyújtva, stb. Az egyetlen affin transzformáció, amelyet megengedünk, az eltolás. Megengedjük azonban, hogy a korábban analóg módon tárolt képen a minta sérült, hiányos vagy nyomdai hibákkal terhelt legyen. Feltételezhetjük azt is, hogy a minta háttérszíne eltérő lehet, vagy akár a minta tónusai eltolódtak. Ezen szín- és tónusbeli problémákra a szűrési eljárások adnak hathatós segítséget. A jó illesztés alapjaként megfelelő távolságfüggvényt kellett bevezetnünk, amely egyrészt optimális illesztést biztosít, másrészt segítségével küszöbértéket is meg lehet határozni, hogy elvessük azokat az eseteket, amikor az adott területen a kérdéses minta nem fordulhat elő. A térképek textúrázottságának felismerésére legegyszerűbb algoritmusként végrehajthatunk egy nyers erővel végzett keresést, amikor a mintának minden lehetséges illesztését kipróbáljuk a képen, és négyzetes eltérésben keressük a minimális helyet a térképen. Ennél a megoldásnál előszűrések segítségével lényegesen jobb módszert sikerült adnunk, amely szinte lineáris időben hajtható végre. A minimális hellyel kapcsolatban el kell mondanunk, hogy bár ez a hely lesz az, amelynél a minta a képen lévő részlettől a legkevésbé tér el, ez nem garantálja, hogy az adott pontban a minta elő is fordul. Ahhoz, hogy a találat releváns eredményt adjon, fontos meghatározni azt a küszöbértéket, amely szerint eldönthetjük, hogy a kapott terület valós találat-e. Mivel a minta egy képen több helyen is előfordul, ezért a minták elhelyezkedésének eldöntését a küszöbérték függvényében kellett tanulmányoznunk. Az ismétlődő mintázatok esetében célszerű olyan keresési módszer választása, amely a kereséssel egy időben biztosítja a mintákkal való lefedés esetén a fedő „csempék” átlapolásainak számát, illetve az átlapoló területek méretét minimalizálja. Ez azért is fontos, hogy a mintakeresést felgyorsítsuk, és egy lefedett területet ne fedjünk le többször. Az átlapolások esetében észrevettük, hogy az átlapolási tulajdonság mértéke a minta méretével arányosan nő. Ez egyenes következménye annak, hogy a minta önmagában rendelkezik ebben az esetben az ismétlődés tulajdonságával. Ahhoz, hogy hatékony kereső eljárást találjunk, meg kellett határoznunk a mintának az önmagában való ismétlődését. Egy minta önmagában való ismétlődésének vizsgálata nyers erővel csak exponenciális időben ellenőrizhető. Gondoljunk arra, hogy adott egy kép, és a képben ismétlő60

IRIS és alakzatfelismerés dést kell keresnünk. Mivel nincs mintaméretünk rögzítve, ezért meg kell vizsgálnunk az összes kis részképet a bemenő adatunkban, hogy azok a képben más pozíción megtalálhatóak-e. Ha egy olyan részmintát találunk, amellyel átlapolást megengedően lefedhető hézagmentesen a teljes kép, akkor ezzel találtunk egy mintakernelt. A mintakernel keresése célszerűségi okokból a teljes méretet folyamatosan csökkentő módon történhet. Ha találunk egy kernelt, akkor az eljárást rekurzívan végre kell hajtanunk a kernelre. Amennyiben a kernel szintén rendelkezik a fentebb vázolt tulajdonsággal, akkor ezt semi-kernelnek nevezzük. Azt a kernelt, amelyik pedig nem redundáns felépítésű, totális kernelnek nevezzük. A térképészetben eddig nem alkalmazott módszereket kívántunk ezen megoldás érdekében felhasználni. A hasonlóság és az önhasonlóság keresésére más szakágakban található technológiákat is kipróbáltunk. Valamennyi módszer lényege az emberi látás hiányosságainak felhasználásával történő képanalízis. Ezeknél a teret spektrális összetevőkre bontják. Három igen elterjedt eszközt vizsgáltunk, az igényeinknek megfelelően specializálva. A diszkrét koszinusz-transzformációt, vagy röviden DCT-t, a waveletalapú szűrőket és a Haar-like feature-t használó neurális hálóra épülő Viola és Jones által ismertetett objektumfelismerő módszert. Utóbbit, mint a látással leginkább összefüggő wavelet-alapú szűrőt kell megemlítenünk. A DCT-eljárás alapja az, hogy az emberi látás nem a klasszikus vörös, kék, zöld színek alapján működik, hanem fényerősség és krominancia szerint. Szemünk a fényerősség érzékelésében sokkal jobb, mint a színek árnyalatainak megkülönböztetésében. A módszer tehát ebben a színtérben dolgozik, és a képet 8 × 8-as részblokkokra osztva működik. A transzformáció során az adatok az időtartományból frekvenciatartományba transzformálódnak, és a blokk felső sarkában megjelenik az intenzitásértékek átlaga, mint hordozó frekvencia, míg a jobb alsó sarokhoz közelítve az egyre magasabb frekvenciaértékeket találhatjuk meg. Ennek lényege, hogy az emberi szem számára nehezen, vagy lényegében nem érzékelt magas frekvenciás összetevőket elhagyhatjuk. Ennek egyik lehetséges változata a kvantálás, amikor a frekvenciasávokra meghatározott együtthatókkal elosztjuk a blokkban a hozzájuk tartozó pozícióban tárolt értéket. Mintaillesztés szempontjából a kapott összetevőkkel gyorsan és hatékonyan tudunk számolni. Lényegében erre a mozzanatra épül az MPEG-szabványnak az elmozdulás-vektorokat kihasználó tömörítési algoritmusa. A wavelet-szűrőket röviden tárgyalva azt mondhatjuk, hogy a térnek szintén egyfajta időtérből frekvenciatérbe történő transzformációját valósítjuk meg. Azonban a DCT-vel szemben sok előnnyel bír, mivel segítségével lehetséges kifejezetten speciális frekvenciatartományokat elemezni, valamint nem alakul ki a klasszikus blokkosodás a képen. A kép blokkosodása ugyanis olyan információkkal terheli a bemenő adatokat, amelyek megnehezítik a számunkra fontos műveletek végrehajtását. Bár esetünkben nem releváns tulajdonság, de megemlítendő, hogy a wavelet-alapú transzformáció közkedvelt a sávszélesség optimális kihasználása miatt a multimédiás anyagok interneten keresztüli valós idejű közvetítése során.

61

A kutatás-fejlesztési központok fejlesztése és megerősítése Végül, de nem utolsó sorban Viola és Jones módszerét röviden összefoglalva egy olyan eljárásról van szó, amelyik egy neurális hálót használ fel két lépésben. Első lépésben tanulóadatokkal állítjuk be a háló neuronjainak súlyait. A módszer sorban választja ki a legmeghatározóbb Haar-like feature-ök közül azokat, amelyek a leginkább illeszkednek a pozitív tanulóadatokhoz és a legkevésbé a negatív tanulóadatokhoz (maximális szeparációt keresünk). A tanulási folyamatot az AdaBoost nevű eljárással lehet felgyorsítani. Második lépésként a betanított neurális hálót alkalmazhatjuk a képek feldolgozásánál objektumok keresésére. Tapasztalataink szerint ez a módszer a problémában felmerülő viszonylag kisméretű objektumokhoz képest igen hosszú futási időt mutat, hiszen a mintát sokszor kell feldolgoznunk pusztán már a tanulási folyamat során.

A kutatás eredményei A kutatás keretén belül elkészült egy univerzális GeoFilterBank nevű szűrőbank keretprogram, amely további, felhasználók által írt bővítményekkel dinamikusan bővíthető. A program három fő részre osztható: 1. szűrők: a fejlesztői környezet biztosít egy szűrősablon API-t a szükséges interfész megvalósításokkal együtt, így ezt felhasználva mások is írhatnak könynyedén saját szűrőket, és használhatják azokat ebben a rendszerben; 2. import modulok: a program jelen pillanatban beépített módon, saját kóddal biztosítja a raszteres fájlok megnyitását. Az import modulok halmaza tetszőlegesen bővíthető, amennyiben a felhasználó saját képformátumot kíván használni; 3. export modulok: saját kódban megírt export modulok állnak rendelkezésre, amelyek szintén bővíthetők. Ennek előnye, hogy speciális mentési lehetőségek állnak rendelkezésre, valamint nem csak raszteres, hanem vektoros adatok is könnyen exportálhatók ily módon. A program támogatja a többnyelvűséget, az egyes nyelvi fordítások xml-fájlokban tárolódnak (jelenleg angol és magyar nyelvű a program). További támogatás adott a többmagos processzorok használatához, hogy a nagyméretű (akár több száz megapixeles) képek esetén is gyors szűrővégrehajtást kapjunk.

Publikációk, konferenciacikkek Szendrei R., Elek I., Fekete I. (2011) Automatic Recognition of Topographic Map Symbols Based on Their Textures. Lecture Notes in Computer Science 6729, pp. 299 – 306 Szendrei R., Elek I., Márton M. (2011) Graph-Based Feature Recognition of Line-Like Topographic Map Symbols. Lecture Notes in Computer Science 6729, pp. 291 – 298

62

IRIS és alakzatfelismerés Szendrei R., Fekete I., Elek I., Márton M. (2011) A Knowledge-Based Approach to Raster-Vector Conversion of Large Scale Topographic Maps. Acta Cybernetica 20, Szeged, pp. 145 – 165 Szendrei R. (2010) Automatic parallelization of raster image filters. In Zoran Majkic, Dan Tamir, Guoyin Wang, Proceedings of the 2010 International Conference on Artificial Intelligence and Pattern Recognition, pp. 30 – 33, 2010. ISBN 978-1-60651015-5 Szendrei R., Fekete I., Elek I. (2009) Texture based recognition of topographic map symbols. In Dmitrios A. Karras, Zoran Majkic, Etienne E. Kerre, Chunping Li editor, Proceedings of the 2009 International Conference on Artificial Intelligence and Pattern Recognition, pp. 7 – 10, July 2009. ISBN 978-1-60651-007-0 Szendrei R., Elek I. (2009) Automatic symbol recognition for topographic maps. In Geomatics – Riga, p. 42, 2009

Konferencia részvétel Szendrei R. (2009) Moduláris szűrőbank fejlesztése és alkalmazása a raszter-vektor konverzió automatizálásában. Fény – Tér – Kép Konferencia előadás, Dobogókő, 2009. november 12.

Poszter Szendrei R., Fekete I., Elek I., Márton M. (2009) A nagyléptékű topográfiai térképek raszter-vektor konverziójának tudásalapú megközelítése. IRFIX’09 Konferencia, Budapest, 2009. november 20.

63

Evolúciós elvű tudás reprezentáció Elek István, Roden János, Nguyen Thai Bihn

1. Bevezetés Az evolúció egyik kiemelkedően fontos momentuma az intelligencia spontán megjelenése. Az evolúcióbiológia nem vizsgálja ezt a kérdést, pedig kézenfekvő, hogy az organizmusok fejlődésére óriási hatással kellett lennie a saját boldogulásukhoz, a környezetük megértéséhez nélkülözhetetlen elemző képesség, egyfajta egyszerű intelligencia. Ennek létrejötte nélkül nem lett volna lehetséges magasabb fejlettségű lények kialakulása.

E munka célja annak megmutatása, hogy emlékezni képes entitásokban az egyszerű intelligencia elemi tapasztalatokból spontán kialakulhat. Az entitások élettere egy mesterséges világ, az internet, amely elég nagy és elég változékony ahhoz, hogy a világ egy egyszerű modellje legyen. Ebben a mesterséges világban URL-ről URL-re vándorolva látogatják, gyűjtik az energiaforrásául szolgáló fájlokat. Tudásbázisukban tárolva az ismereteket, működésük egyre eredményesebb lesz, egyre jobban képesek lesznek az energiaforrások megszerzésére irányuló helyes döntések meghozatalára. Számosan e lények közül elpusztulnak, mert életük kezdetén, nem rendelkezvén még tapasztalatokkal, a véletlennek óriási szerep jut a túlélésükben. A szerencsésebbeknek lehetőségük van a tapasztalatok megszerzésére, és így további életesélyeik javítására. A kísérleti eredmények ezt a működési mechanizmust bizonyítják. Amíg a tudásbázisok egyénhez kötöttek, addig atomizálódott lények sokaságát látjuk, akik kizárólag saját boldogulásukra optimalizálják a működésüket. Ha megengedjük a lények tudásbázisainak cseréjét, részleges átvételét, vagyis a kommunikációt, akkor a mesterséges világ egyszerű lényei egyszerű társadalomként kezdenek működni.

2. Evolúció és intelligencia Darwin óta az evolúció lankadatlanul az érdeklődés középpontjában áll. Főként biológusok és paleontológusok kutatják az egykori vagy éppen mai élőlények fejlődését. Egyesek számára mind a mai napig megemészthetetlen a spontán, teremtés nélküli törzsfejlődés gondolata, míg mások a véletlennek tulajdonítják, hogy aminosavcsomókból elindulva létrejött az élet. A törzsfejlődés során kifejlődtünk mi is, a magas fokú intelligenciával rendelkező lények, akik képesek megérteni és alakítani a környező világot. Vajon mindez hogyan

A kutatás-fejlesztési központok fejlesztése és megerősítése történhetett? Miként vált lehetségessé egyszerű aminosav-kombinációkból megalkotni gondolkodó lényeket? Valóban, igen fontos kérdés, hogy hogyan keletkezett az intelligencia. E kutatás tárgya nem az élet kialakulása, hanem az intelligencia megjelenése. Az élet keletkezésének problémáján biológusok ezrei dolgoznak, ami nem azonos az intelligencia kialakulásával. Annak ellenére így van ez, hogy nem ismerünk olyan spontán létrejött intelligenciát, amely ne élő szervezetben alakult volna ki. Úgy tűnik, mintha csak élő rendszerekben létezne intelligencia, mintha az élő anyag fejlődésének volna egy állomása az intelligenciával rendelkező lény megjelenése. Az intelligencia-definíciók megfogalmazása nem egyszerű feladat. Valamennyi próbálkozás az emberi intelligenciát igyekszik definiálni (pl. Turing), ami egyben ezen definíciók használhatóságát erősen korlátozza. Az evolúció korai szakaszának folyamataiban ugyanis ezek a definíciók nem alkalmazhatók, pedig egy kezdetleges lény, ha képes a környezetét értelmezni és saját érdekében cselekedni, okulni a tapasztalataiból, akkor mi ez, ha nem intelligencia, még ha igen egyszerű is. Feltesszük azt a kérdést, hogy lehetséges-e élő szervezeten kívüli intelligenciát megalkotni? Lehetséges-e unintelligens elemekből intelligens dolgokat létrehozni? Egyáltalán miért csak a biológiai rendszerekkel kapcsolatban használjuk az evolúció fogalmát? Lehetséges-e olyan önszerveződő, tudatos cselekvésű, saját maga boldogulását képviselni képes objektum spontán létrejötte, amely emlékezik a vele történt eseményekre, azokat képes kiértékelni a maga hasznára, és képes okulni a jó és rossz tapasztalatokból? Ez a kutatás erre a kérdésre ad választ. A válasz az, hogy lehetséges megalkotni ilyen lényeket. Ezek a digitális evolúciós gépek, amelyek működését röviden bemutatjuk. Ismertetjük a digitális evolúciós gép létrehozásának alapelveit, elméleti hátterét, és azt a mesterséges világot, amely életteréül szolgál a digitális lényeknek. Fontos hangsúlyozni, hogy nem az élet kialakulását modelleztük. Létrehoztunk egy mesterséges világot, amely kellően nagy és bonyolult ahhoz, hogy a benne való boldogulás ne legyen gond nélkül való. Létrehoztunk nagy tömegben digitális lényeket, akiknek egyetlen feladatuk az ebben a mesterséges világban történő eligazodás és helytállás. A legfontosabb eredményünk az, hogy az intelligencia létrejötte spontán módon lehetséges, bonyolult algoritmusok nélkül, néhány egyszerű alapelvre támaszkodva. Ez a működési mechanizmus azonban sokkal inkább lesz az ösztönös cselekvés, az érzelmek alapján történő döntések, ha úgy tetszik, az előítéletes gondolkodás modellje, mint a racionális megfontolásokon, körültekintő kiértékelésre alapuló gondolkodásé. Ez azonban nem hátránya a modellnek, mivel az evolúció kezdetén aligha volt lehetséges, hogy az aminosavak összekapcsolódásából bonyolult algoritmusok realizálódjanak, pontosabban csak annyira bonyolultak, amennyire ez a folyamatok kémiájából és fizikájából következhet. Összetettebb gondolkodási sémák, mint amilyen az ember racionális gondolkodása, az állatvilágban ismeretlen (mai ismereteink szerint). Feltételezhető, hogy ezt a fajta gondolkodást meg kellett előznie egy ösztönös cselekvésre sarkalló, primitívebb gondolkodási mechanizmusnak. Ennek létrehozására tettünk kísérletet. 66

Evolúciós elvű tudás reprezentáció Nevezzük intelligens objektumnak, ami a következő képességekkel rendelkezik:  képes minden esemény tárolására, amely az objektummal az eddigi működése során történt;  az események kiértékelésének képessége (pl. hasznos, haszontalan, káros, veszélyes volt-e az adott esemény az objektum számára);  milyen eredményre vezetett az objektum boldogulása szempontjából a helyzet kiértékeléséből következő reakció. Az az objektum tehát, amely képes a környezetének paramétereit és a benne, vele történő eseményeket memorizálni, kiértékelni, cselekedni és okulni, az intelligens. Vegyük észre, hogy ez a intelligencia definíció egyénre szabott, individuális tudást tételez fel, mert az objektummal történtek nyilvánvalóan különbözőek, ráadásul a sorrendjük is szinte tetszőleges lehet. Ha az objektumok nagy térbeli elterjedéssel rendelkeznek, akkor az egymástól távol lévő helyek paramétereiben jelentős különbségek állhatnak fent, ami rányomhatja bélyegét az intelligenciára. Vegyük észre, hogy ez az intelligencia-definíció egyénre szabott, individuális tudást tételez fel, mert az objektummal történtek nyilvánvalóan különbözőek, ráadásul a sorrendjük is szinte tetszőleges lehet. Ha az objektumok nagy térbeli elterjedéssel rendelkeznek, akkor az egymástól távol lévő helyek paramétereiben jelentős különbségek állhatnak fent, ami rányomhatja bélyegét az intelligenciára.

3. A tudásbázis alapelvei Mivel még nem tudjuk pontosan, hogy milyen lesz szerkezetileg és működését tekintve a tudásbázis, ezért fogalmazzuk meg fenomenologikusan, felszínes ismérvek szerint, a mély struktúrák ismerete nélkül, hogy milyen legyen a majdani tudásbázis. 1. A tudásbázis tudáselemekből áll, nevezzük ezeket atomoknak; 2. valamennyi atom kapcsolódik legalább egy másik atomhoz; 3. az atomok egy gráf csúcspontjai, amelyek bármely másik atomhoz kapcsolódhatnak; 4. az atomi kapcsolatokból utak, séták alapján áll össze a tudás egészét tartalmazó tudásgráf; 5. a már egyszer bejárt útvonalak legyenek jutalmazva, ha ez a bejárás a lény számára pozitív eredménnyel zárult (a kapcsolat megerősítése); annál erősebb legyen egy kapcsolat, minél többször történt meg a pozitív eredményű bejárás. Ez egyben azt is jelenti, hogy a ritkán használt, vagy többször is negatív eredményt hozó kapcsolatok háttérbe szorulnak (felejtés), bár sohasem tűnnek el; 6. engedjünk meg csoportképzést tetszőleges atomokra; nevezzük őket komplex tudáselemnek vagy kontextusnak; 7. az egyszerű és a komplex tudáselemekre is ugyanazok a műveletek vonatkozzanak; 67

A kutatás-fejlesztési központok fejlesztése és megerősítése 8. engedjük meg egymásnak ellentmondó atomok létét a tudásbázisban. Mivel semmi nem törlődik a tudásgráfból az idők folyamán, ezért előfordulhat, hogy például a megváltozott környezet miatt egy előzőleg bevált bejárás az új viszonyok között rendre rossz eredményt hoz, és így az egyre gyengébb lesz, vagyis egyre kevésbé jó ötlet ezt az utat járni. Alkossuk meg a tudásgráfot atomokból és ezek kapcsolataiból. Az ágak a kapcsolatrendszert, a csomópontok az atomokat jelentik. Definiáljuk továbbá a kontextus fogalmát, amely tetszőleges atomokból álló csoport. Az alapelvekben kikötöttük, hogy ne különböztessük meg az egyszerű és a komplex elemeket, így kontextusnak egyaránt lehet eleme egy egyszerű atom és egy másik kontextus, vagyis egy komplex tudáselem is. Vegyük az atomok közötti kapcsolat erősségét, amit jellemezzünk egy számmal, amely minden alkalommal, amikor végigmegyünk a két csúcspont közötti élen, növekszik, ha jó eredményre vezetett a vonalon való végighaladás, vagy csökken, ha rossz eredményre vezetett a vonalon való végighaladás. Tekintsük a tudásbázis két atomját, amelyek között darab atomon keresztül vezet az út. Származtassuk a távolságot a kapcsolat erősségéből. Az egyes csomópontok közötti erősségek reciprokait véve, majd ezeket összegezve és normálva a pontok számával kapjuk a távolságot. Vagyis minél erősebb a kapcsolat két csomópont között, annál közelebb vannak egymáshoz.

4. A digitális evolúciós gépek a szintetikus világban A fenti elvek alapján megalkottunk olyan digitális lényeket (crawlereket, rövidítve DEM-nek, digital evolutionary machine-nek neveztük őket), amelyek járják a mesterséges világot, amely esetünkben az internet lett, és URL-ről URL-re járva gyűjtik az információt az elérhető digitális táplálékról (amik különböző típusú fájlok). A peremfeltételek alapvetően befolyásolhatják a gépek működését. Biztosan másképpen működnek, ha korlátlanul állnak rendelkezésre erőforrások, mint ha versenyezni kell értük. A korlátlan esetben elegendő, ha a tudásbázisuk az erőforrások megtalálását segíti, míg a versengő esetben nemcsak megtalálni kell az erőforrásokat, hanem a versenytársakat is le kell győzni, meg kell előzni valamilyen módon. Egyszerre sok DEM létezése szükséges azért, hogy az eltérő környezetből származó eltérő tudásbázisú gépek jöjjenek létre. Ez a konstrukció biztosítja a sokféle irányú fejlődés lehetőségét. A fejlődési folyamat nyilvánvalóan nem lineáris, mivel az eltérő környezetben ,,nevelkedett'' gépek másképpen fognak reagálni a környezet megváltozásaira. Jelentősebb környezetváltozáshoz való alkalmazkodás az egyik tudásbázisnak kisebb, a másiknak nagyobb kihívást jelenthet. A túl nagy feladat eredménye lesz majd az elhullás jelensége, aholis a változásokhoz alkalmazkodni nem képes gépek ,,elpusztulnak'', és megmaradnak az ,,életképesek'' (noha célszerű lenne egyszerre sok helyről indítani a lényeket, egyelőre azonban egy helyről indulnak, amiből érdekes következmények származnak, mint például a tülekedés következtében sokan elhullnak már az elején).

68

Evolúciós elvű tudás reprezentáció A választott mesterséges világ, a web, kellően nagy és változatos ahhoz, hogy modelljéül szolgáljon a világnak.

5. A Dem-rendszer A digitális evolúciós gépek létrehozására és életük figyelemmel kísérésére kifejlesztettünk egy programrendszert, amely a folyamatok kézben tartását, a működés monitorozását végzi. A rendszer több együttműködő komponensből áll, amelyek segítségével tetszőleges számú DEM-et tudunk elindítani vagy megállítani, a környezeti paramétereket tudjuk beállítani, valamint egy adatbázisban rögzítjük a DEM-ek és digitális világ tulajdonságait. A DEM-ek működésük során folyamatos kapcsolatban állnak az adatbázissal, ahová beírják a meglátogatott URL-címeket, az ott talált erőforrás-fájlokat és energiaállapotukat. A működésük tapasztalatait saját tudásbázisukban rögzítik, amely tanácsot ad nekik a következő cél-URL-re vonatkozóan. Amikor energiájuk az ,,éhség''szint alá csökken, további erőforrást kell szerezniük. A folyamat nyilvánvalóan időbeliséget tételez fel, vagyis a folyamat előrehaladása időben történik (ha nem is valós időben, de ha időzítőben gondolkodunk, akkor is helyes a gondolatmenet). Ha már mindent megettek az adott URL-en, akkor tovább kell menniük. A kérdés az, hogy hová menjenek, ahol további erőforrásokat találnak. A DEM-ek működésük kezdetén, amikor még kevés tudás áll rendelkezésükre, jobb híján az adott URL-en lévő link(ek) által megadott helyre mennek tovább. Ezen vagy van valami ehető, vagy nincs, vagy van rajta további link, vagy nincs. Ha van ehető, akkor a lépés eredményes volt, ha nincs, akkor továbbmegy a következő linkre. Ekkor persze fogy az energiája, mert minden lépés energiát fogyaszt, sőt, az egyhelyben állás is. Ha olyan URL-re téved, amelyik zsákutca, akkor visszalép. Ha nem létező helyre mutat a link, akkor az sem jó lépés, mert nem eredményezett energianyereséget, sőt, vesztett a hiábavaló mozgáson. A DEM-ek későbbi életszakaszában, amikor már több tapasztalat áll rendelkezésre (azoknak, akik még életben vannak), a továbblépésben segítséget nyújt a saját tudásbázisuk, amely tanácsot ad a továbblépés URL-jére vonatkozóan. Azok az URL-ek ugyanis, amelyek előzőleg már energiaforrást adtak a lényeknek, megerősített útvonalként kerültek be a tudásbázisba, és mint ilyen, javasolt, meglátogatandó URL-ként jelennek meg a tudásbázis tanácsaként. Így tehát a továbblépés bevált helyekre történik meg. Ha persze időközben mások is meglátogatták ezt a helyet, és az még nem regenerálódott, akkor mégsem bizonyult jó lépésnek. Ebből a példából az is látható, hogy nem elegendő csak a lények monitorozása, hanem a már bejárt világ állapotterét is rögzíteni kell az adatbázisban, elvégre ennek hiányában nem állapítható meg, hogy egy erőforrás rendelkezésre áll-e vagy sem. Pontosabban, ha ezt nem tároljuk, akkor minden erőforrás mindig rendelkezésre fog állni, akárhányan tolonganak is a környékén. Az ilyen esetek kerülendők, mert olyan URL-ek, amelyeken bőven van táplálék, mint például valamilyen médiatárak (pl. youtube vagy MEK – Magyar Elektronikus Könyvtár) fekete lyukként az egyszer odatévedt DEM-et többé nem engedik távozni. Ez tehát azt jelenti, hogy mindenképpen le kell képeződnie az adatbázisban a bejárt térrészeknek is.

69

A kutatás-fejlesztési központok fejlesztése és megerősítése A rendszer ahhoz is eszközöket biztosít, hogy az adatbázisból tetszőleges legyűjtéseket végezzünk a DEM-ek működésének elemzésére. Akár „élőben” is figyelhetjük, ahogy egyik helyről a másikra vándorolnak. Legyűjthetjük azt is, hogy kik vannak még életben, kik pusztultak el, hol, mikor, mi történt.

6. Futtatási eredmények Az első futtatások során először elindítottunk 20 000 DEM-et. A tér paraméterezését úgy végeztük el, hogy az egy helyben tartózkodás ne legyen jó stratégia. Vegyük szemügyre az 5. ábra sorait, amelyek a DEM-ek néhány adatát mutatják a DemWorkers nevű táblában. A nem túl beszédes Guid azonosítókon kívül neveket is adtunk nekik, hogy könnyebb legyen emberi nyelven beszélni róluk. Energiatartalmuk és pillanatnyi státuszuk, születési idejük is látható. Ha a Diedat mező nem Null, akkor még élnek. Látható, hogy ha az energy_content mező zérus alá csökken, akkor a Diedat mezőben is benne van a pusztulás időpontja.

5. ábra DemWorkers nevű tábla az elindult lények paramétereit mutatja A mesterséges világ valaha meglátogatott node-jaiból néhányat mutat a 6. ábra. Igen hasznos lehet, ha grafikusan is meg akarjuk mutatni a DEM-ek mozgását a térben. A ContentTypes nevű tábla néhány lehetséges erőforrás-fájltípus energiatartalmát adja meg (15. ábra). Ezen paraméterek változtatása befolyásolhatja a DEM harcmodorát. Az egyik leginformatívabb tábla a hajónapló, azaz a Logbook nevű tábla, amelybe minden alkalommal történik egy bejegyzés, valahányszor egy DEM mozgást végez. Például egy 1000 DEM-ből álló csapat elindítása után a harmadik napon már több mint 3.5 millió rekordot tartalmaz. 70

Evolúciós elvű tudás reprezentáció

6. ábra ArtiworldNodes nevű tábla a meglátogatott URL-eket mutatja

7. ábra ContentTypes nevű tábla a táplálék típusokat mutatja

71

A kutatás-fejlesztési központok fejlesztése és megerősítése A programrendszer adminisztrációs felületén indíthatók el a lények. Beállítható a számuk, testi paramétereik, és a tiltott domain-nevek. Ugyanitt állíthatjuk be a ContentTypes tábla tartalmát is, amelyben az egyes energiaforrás-fájlok alapenergia-értékeit adhatjuk meg (az alap azt jelenti, hogy ennek egész számú többszöröse lesz a tényleges energiaérték, amely a fájl méretével lesz arányos). Az első futtatásokat 1000 lénnyel indítottuk, de később végeztünk 10 000 valamint 50 000 egyedszámú futtatásokat is. Vizsgáljuk meg a következő ábrákat (8. ábra-14. ábra), amelyek az kísérleti futtatás eredményeit mutatják. Nem egyetlen URL-ről indult az össze lény, nehogy emiatt a nagy tülekedésben tömeges pusztulás következzen be, hanem ezer különböző helyről. A 8. ábra mégis olyan jelenséget mutat, amely „egymás eltaposásából” ered. Nyilvánvalóan látható, hogy a lények számához képest az erőforrások száma kevés, emiatt folyamatosan csökken az életben maradó lények száma. Egyes esetekben az is látszik, hogy sokan energiaszegény környékre tévedtek, ahol a biztos pusztulás várt rájuk. Nem lévén tudásbázisuk, nem tudták kiértékelni a helyzetet, és a vak véletlen nem hozott megoldást a számukra. A 9. ábra mutatja, hogy a tömeges kihalási szakaszok után voltak prosperáló időszakok, amikor olyan környékre kerültek a DEM-ek, ahol elegendő mennyiségben állt rendelkezésre táplálék. Igaz, ehhez az kellett, hogy elpusztuljon a populáció 75%-a. A 10. ábra során már jól kirajzolódik egy hiperbola, amelynek az eleje nagyon gyors, tömeges pusztulást mutat, viszont egy kisebb, a kezdeti populáció 15 − 20%-a stabilan élhető környezet talált. Lényeges változás nem tapasztalható négy nap után sem, ahogy ezt a 10. ábra mutatja. A környezet és a lények paramétereinek megváltoztatása a folyamatokban minőségi változást nem hozott. A görbék lefutása más volt, de a végeredmény jellegét tekintve nem alapvetően különböző. Ezek alapján megállapítható, hogy a mesterséges világban, vagyis a weben, van olyan környezet, amelyben akár gondolkodás nélküli lények is megtalálhatják a továbbélés feltételeit. Kedvező környezetben mindenféle intelligencia és tudásbázis nélkül is életben lehet maradni. Ez a tapasztalat egybevág azokkal az előzetes várakozásokkal, hogy a korai evolúció időszakában semmiféle intelligencia megléte, semmilyen gondolkodás nem segíthette az akkori primitív életformákat a túlélésben. Az ősi Föld környezeti paraméterei feltételezhetően ugyanúgy kedveztek a kezdeti primitív formák fennmaradásának, mint a mi mesterséges világunk egy szerencsés, kisebb csapatnak. A fentebb említett, energiaforrásokban gazdag URL-ek csak részben magyarázzák a szerencsés lények lehorgonyzását ezeken a helyeken. Hasonlóan kedvező túlélési esélyeket biztosító eset lehet, amikor két weboldal, amelyeken sok kép van, kölcsönös linkeket tartalmaz egymás URL-jére. További lehetséges struktúrákat nem említünk, már csak azért sem, mert a programok futtatása által létrejött adatbázisok vizsgálata most is folyamatban van. Adatbányászati módszerekkel vizsgáljuk az adatbázist, hogy felismerjük azokat a helyeket, amelyek hosszabb távon biztosíthatják a lények életben maradását. A következő érdekes kérdés, hogy kezdetben miért pusztulnak el a lények tömegesen, és miért figyelhetők meg átmeneti konszolidációs időszakok, amelyeket újabb, 72

Evolúciós elvű tudás reprezentáció már kisebb mérvű pusztulások követnek. A kezdeti, nagymérvű pusztulásnak számos oka van, amelyek egyidejűleg befolyásolják a jelenséget. Ugyan egyszerre sok helyről indulnak el a lények, de ezen helyek száma kisebb, mint a lények száma, vagyis egyes induló URL-ek körül torlódás keletkezik. Így előfordulhat, hogy az erőforrást elsőnek elfogyasztó lény után a többiek számára nem marad hozzáférhető fájl. Ha túl sokáig áll fenn egy ilyen állapot, akkor a hiábavaló mozgások felemésztik a hátrányos helyzetben lévő lények energiáját, vagyis elpusztulnak. Egy másik lehetséges magyarázat a pusztulásokra, hogy számos olyan URL létezik, amely nem tartalmaz semmiféle erőforrást és linket. Ezek tehát zsákutcák. Intelligencia hiányában az ide egyszer bejutott lények sosem tudnak kiszabadulni, vagyis elfogy az energiájuk. Az is gyakori eset, hogy egy URL-en már nem érvényes link található, vagyis a link sehová sem mutat (pl. 404-es hiba, nincs ilyen fájl). Ebben az esetben is biztos pusztulás vár a lényekre, noha a Logbook és a DemWorkers nevű táblákban üres marad a DiedAt mező, sőt az energiájuk is 99.5 marad (egy lépés 0.5 egységet csökkent az energiájukon). Noha formailag ezek a lények nem pusztultak el, de nyilvánvaló, hogy viselkedésük az örök passzivitás, a mozgás képtelensége.

8. ábra A DEM workerek száma 5 perccel az indulás után (1000 egyedes futás) I

73

A kutatás-fejlesztési központok fejlesztése és megerősítése

9. ábra A DEM workerek száma 60 perccel az indulás után (1000 egyedes futás)

10. ábra A DEM workerek száma 120 perccel az indulás után (1000 egyedes futás) 74

Evolúciós elvű tudás reprezentáció

11. ábra A DEM workerek száma 15 órával az indulás után (1000 egyedes futás)

12. ábra A DEM workerek száma 4 nappal az indulás után (1000 egyedes futás) 75

A kutatás-fejlesztési központok fejlesztése és megerősítése

13. ábra A DEM workerek száma 32 órával az indulás után (10 000 egyedes futás)

14. ábra A DEM workerek száma60 órával az indulás után (10 000 egyedes futás)

76

Evolúciós elvű tudás reprezentáció

Irodalomjegyzék [1] C. Adami: Ab Initio of Ecosystems with Artificial Life, arXiv:physics\/0209081 v1 22 Sep 2002 [2] C. Adami: Sequence Complexity in Darwinian Evolution, Comlexity, 2003, Wiley Periodicals, Vol.8, No.2 [3] Albert, Barabasi: Statistical mechanics of complex networks, Reviews of modern physics, VOLUME 74, January 2002 [4] Chow, SS, Wilke CO, Ofria C, Lenski RE, Adami C. 2004. Adaptive radiation from resource competition in digital organisms. Science (New York, N.Y.). 305(5680):84-6. [5] Barabasi -- Albert -- Jeong: Mean-field theory for scale-free random networks, Preprint submitted to Elsevier Preprint, 5 July 2002. [6] L. Dollo: http:\//en.wikipedia.org/wiki/Dollo's\_law [7] I. Elek: Principles of Digital Evolution Machines, International Conference of Artificial Intelligence and Pattern Recognition, 2008, Orlando, FL [8] I. Elek: Evolutional Aspects of the Construction of Adaptive Knowledge Base, The Sixth International Symposium on Neural Networks (ISNN 2009), Wuhan, China [9] I. Elek: A Computerized Approach of the Knowledge Representation of Digital Evolution Machines in an Artificial World, LECTURE NOTES IN COMPUTER SCIENCE 6145: pp. 533-540. (2010) [10] I. Elek: Digital Evolution Machines in an Artificial World: a Computerized Model, International Conference on Artificial Intelligence and Pattern Recognition (AIPR10). Orlando, USA, 2010.07.12-2010.07.14., Paper 169. [11] G. F. Gause: Experimental studies on the struggle for existence, Journal of Experimental Biology 9: 389-402, 1932 [12] S. J. Gould: Dollo on Dollo's law: irreversibility and the status of evolutionary laws, Journal of the history of biology (Netherlands) 3: 189?212. doi:10.1007\/BF00137351. PMID 116096510, (1970) [13] M. Newman -- A-L. Barabasi -- D. J. Watts: The structure and Dynamics of Networks, Princeton University Press, 2006 [14] E. A. Ostrowski, C. Ofria, R.E. Lenski: Ecological specialization and adaptive decay in digital organisms, The American Naturalist. 169(1):E1-20-E1-20., 2007 [15] S. Russel -- P. Norvig: Artificial Intelligence: A Modern Approach, Prentice Hall, 2002

77

Önkormányzatok geoinformatikai adatbázisa 5. Kutatási főirány Nagy térinformatikai adatbázisok alprojekt Gábori László, Nguyen Thai Binh, Weninger Zoltán

1. Bevezetés Az utóbbi időben a szakmai és a kormányzati szervek érdeklődésének homlokterébe kerültek az önkormányzatok szolgáltatásainak biztosítása, ezek hatékony és egységes kialakításának igénye, illetve a szolgáltatásokat akadályozó tényezők, valamint az egységes szolgáltatások alapját képező adatbázisok vizsgálata. Az önkormányzatok szolgáltatási feladatai közül kiemelkedik az építéshatósági szakszolgálati feladatok ellátása, mivel gazdaságélénkítő és lakossági közérzetjavító szerepe miatt politikai elvárás az épített környezettel kapcsolatos átlátható és hatékony igazgatásszervezési rendszer kialakítása. Az érdeklődés további oka, hogy bár Magyarországon az e-kormányzati fejlesztések és szolgáltatások bevezetése bizonyos területeken gyorsan haladt előre, az épített környezettel kapcsolatos elektronikus szolgáltatások és eljárások terjedése eddig elmaradt az egyéb területeken elért eredményektől. Ráadásul az informatika fejlődésének eredményeként megfigyelhető adat-koncentrációs folyamatokkal szemben áll az önkormányzati rendszer és a kapcsolódó jelenlegi jogi szabályozás decentralizált feladat- és hatáskör megszabása. Kétszintű a jogi környezet szabályozása: az épített környezettel kapcsolatos jogszabályok a területrendezés szintjéig központosító jelleggel szabályoznak, és ezt egy működő központi adatbázissal (TeIR – Országos területfejlesztési és Területrendezési Információs Rendszer) támogatják. Ugyanakkor településszabályzási tervet, építési szabályzatot települési önkormányzati szinten lehet jóváhagyni, az előírt nyilvántartások vezetésére nincs központi támogatás, valamint a jogszabály szerinti önkormányzati hatáskörben vezetett adattartalmak gyakran átfedik más közigazgatási szervek feladatköreinek adattartalmait. Így településenként változatos formájú és adattartamú adatbázisok léteznek, valamint a különböző szerkezetű egyedi megoldásokat féltékenyen őrzik és titkolják mások elől az őket megalkotó vállalkozások szerzői jogaira hivatkozva. Az Európai Közösségen belüli térinformációs infrastruktúra (INSPIRE) kialakítását megalapozó nemzeti téradat-infrastruktúra nem hozható létre az önkormányzati adatvagyon komplex szempontú hasznosítása nélkül. Az INSPIRE direktíva célja a területi adatok felhasználását akadályozó körülmények megszüntetésével és az interoperabilitás növelésével a már rendelkezésre álló adatok hozzáférhetőségi és tovább-feldolgozási mértékének az optimalizálása. Az unió nem indít új, széleskörű területi adatgyűjtési programokat az egyes tagállamokban, de megköveteli a már rendelkezésre álló területi adatok nyilvántartásának és a kapcsolódó szolgáltatásoknak az olyan szintű átalakítását, amelyek segítségével ezek az adatok mindenki számára hozzáférhetővé válnak.

A kutatás-fejlesztési központok fejlesztése és megerősítése A sokféle hatás, szempont, igény következtében aktuálissá vált az önkormányzati feladatkört lefedő egységes, integrált és térinformatikai alapú informatikai rendszer létrehozása. Vizsgálatunk tárgya ennek egy fontos, ha nem a legfontosabb eleme, az adatbázis geometriai adatokat tartalmazó logikai modelljének a megalkotása. A geometriai adatok logikai modelljének kidolgozása és rögzítése lehet az az alap, amelyre felépíthető egy korszerű, a teljes építéshatósági ügyintézést támogató informatikai rendszer. A geometriai adatok logikai modelljének egyszerre kell kielégítenie a 2, 2,5 és 3D igényeket, így hosszú távon megfelelő alapot nyújtva a felhasználói igények változásának megfelelően várhatóan továbbfejlődő ügyintézési folyamatoknak.

1. A jelenlegi helyzet bemutatása A jelenlegi helyzetet jellemző tulajdonságok és korlátok számbavételével igazoljuk témakörünk fontosságát és indokoljuk kiemelt kezelését. Az épített környezettel kapcsolatos jogi szabályozás definiálja a fejlesztés mozgásterét. A papíralapú építéshatósági ügyintézés csak hősöket és áldozatokat „teremt”, esélytelen egy mai kornak megfelelő működésre. A fejezetben áttekintjük a téradatok, térképek helyét és szerepét az építéshatósági ügyintézésben, és tárgyaljuk az önkormányzati és a földhivatali nyilvántartások közötti átfedéseket.

2.1. Az épített környezet szabályozása Az épített környezettel kapcsolatos folyamatok irányítása és szabályozása jelenleg két minisztérium hatáskörébe tartozik, és a vonatkozó jogszabályokat is két törvény, valamint a kapcsolódó rendeletek tartalmazzák (1996. évi XXI. Törvény a területfejlesztésről és a területrendezésről, valamint az 1997. évi LXXVIII. Törvény az épített környezet alakításáról és védelméről). A területrendezési és településrendezési tervek készítésének folyamataiban minden minisztériumnak szerepe van az egyeztetések során. A terveknek két különbözőképpen szabályozott szintje van: az egyik a területrendezés és településrendezés, míg a másik a helyi építési szabályzat és szabályozási terv. A sokféle egyeztetési, véleményeztetési, engedélyezési folyamatból célszerű kiemelni az építés hatósági engedélyezési eljárást, amelynek eredményeként már nem csak újabb tervek készülnek, hanem épületek valósulnak meg.

2.2. Téradatok, térképek helye és szerepe az építésügyi eügyintézésben Az építéshatósági ügyintézésben a vezetékjog-engedélyezési eljárás 426 napos átlagos átfutási ideje (ELMŰ-adat) semmivel nem magyarázható tényadat. A hosszú ügyintézési folyamat miatt az eljárások sokba kerülnek mind a hatóság, mind az építtető oldalán, és jelentős a tervezett objektumok létrehozásának elhúzódásából származó ki80

Önkormányzatok geoinformatikai adatbázisa eső haszon. Központi rendszer hiányában az egyes hivatalok sokszor eltérő gyakorlatot követnek. A hatóságok leterheltsége is különböző, amit a hivatalok területfüggő delegálása miatt nem lehet optimalizálni. A papíralapú ügyintézés a sokszereplős engedélyezési eljárás során jelentős dokumentum-előállítási és -kezelési (nyomtatási, szállítási, tárolási, stb.) költséget okoz, valamint egyes tevékenységek (iktatás, adatellenőrzés) hivatalonkénti újbóli ismétlésével jár. Nehezen átlátható folyamatok és informatikailag gyengén támogatott tevékenységek jellemzik a mai építéshatósági ügyintézést. Az ügyfél-hivatal kapcsolat alá-fölérendeltségi viszonyon alapul. Az építésügyi hatósági folyamatok állapotát, színvonalát pillanatnyilag az általános gazdasági helyzet romlása miatt bekövetkező drasztikus ügyszámcsökkenés „mentette meg”, de egy várható gazdasági növekedéskor újra előbukkannak ezek a súlyos hiányosságok. Triviális megoldás az építéshatóságok informatikai rendszerének centralizálása: különösen a vonalas építmények (közművek, autópályák, utak, vasutak, stb.) tervezési folyamataiban és engedélyeztetési eljárásaiban jelentkeznének az azonnali eredmények, a felgyorsult ügyintézés mellett megteremtve a több hatósági hatóterületet érintő épített objektumok egy egységként történő kezelésének a lehetőségét. Az iktatást, formai és tartalmi ellenőrzést, a határozathozatalt és a lekérdezést-elemzést támogató informatikai rendszer az elektronikus ügyintézés bevezetésével megszünteti vagy jelentősen lecsökkenti a fejezet elején ismertetett jelen rendszer működéséből fakadó hátrányokat. Az elektronikus ügyintézésnek is több megvalósítási változata lehet:  az egyszerűbb esetben az ügyiratokra, a kérelemre, a határozatra, a felhívásokra, stb. korlátozódik, de ezek digitalizálása is jelentős eredményeket hoz;  teljes körű megvalósításakor a kérelem mellékletei, a műszaki tervek és térképek is digitális formában jelennek meg a rendszerben (persze az sem mindegy, hogy raszteres – képi – vagy vektoros formában). Az elektronikus ügyintézés legszembetűnőbb eredménye a műszaki tervek digitális tárolásából fakadó előnyök egész sora: az új rendszerben mindig meghatározható az aktuális tervváltozat, nincs szükség papíralapú másolatok garmadára, vektoros adattárolás estén automatikus ellenőrzési eljárások dolgozhatók ki és alkalmazhatók, a változások vezetése automatizálható, változások időbelisége jól követhető, stb. Sajnos az elektronikus ügyintézést 2004-ben elrendelő KET (2004. évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól) bevezetése óta eltelt közel egy évtized közigazgatás-fejlesztése után, a minősített iratkezelő rendszerek kötelező bevezetését követően több évvel az építés-engedélyezés esetében még mindig jogszabály tiltja az elektronikus ügyintézést. Az épített környezet alakításáról és védelméről szóló 1997. évi LXXVIII. törvény 53/A. § (1) a következők szerint rendelkezik: „Az építésügyi hatósági engedélyezési eljárásokban – kormányrendeletben meghatározott eljárások kivételével – az ügyfél nem jogosult és a hatóság nem köteles elektronikus úton kapcsolatot tartani.” 81

A kutatás-fejlesztési központok fejlesztése és megerősítése A papíralapú ügyintézés mellett az építésügyi hatóságok jelenleg a következő nyilvántartásokat vezetik, adatokat kezelik:  a települések közigazgatási területét ábrázoló földmérési alaptérképek (bel- és külterület ábrázolásával);  a helyi építési szabályzat és a településrendezési tervek nyilvántartása;  a telekalakítási engedélyek mellékletét képező tervek;  a belterületi közműnyilvántartás;  az építmény-nyilvántartás;  az átnézeti nyilvántartási térkép;  a külterületen lévő nyomvonalas és kapcsolódó létesítmények nyilvántartása;  építészeti-műszaki tervezői, településtervezői, településrendezési szakértői, építésügyi műszaki és igazgatási szakértői, beruházás-lebonyolítói, energetikai tanúsítói, vállalkozó kivitelezői, műszaki ellenőri, felelős műszaki vezetői névjegyzék vezetése;  a lakásépítéssel, megszűnéssel kapcsolatos nyilvántartás;  a hatósági, építésfelügyeleti ellenőrzések jegyzőkönyveinek nyilvántartása;  az építésügyi és építésfelügyeleti hatósági eljárások következtében szükségessé vált pénzösszeg behajtásának nyilvántartása;  a bauxitcementtel épült építmények nyilvántartása;  az egyéb jogszabályban megjelölt nyilvántartások. A felsorolt nyilvántartások közül az építmény-nyilvántartást és a közműnyilvántartást az építésügyi hatásági ügyek intézése során a 4. fejezetben bemutatott megoldásunk segítségével és minimális többletmunkával naprakésszé lehetne fejleszteni, majd ezt az állapotot folyamatosan fent lehetne tartani.

2.3. Átfedések az önkormányzati és a földhivatali nyilvántartások között Jelen gyakorlatban az államilag előírt földhivatali és önkormányzati téradatok nagyrészt fedik egymást. A duplán, vagyis kétszeres költséggel vezetett adatok aktualitása viszont sohasem egyezik, az eltérések elsősorban a rögzített események időbeli egymásután következéséből erednek, vagyis soha nem is egyezhetnek. Definiálható, hogy az érvényes jogszabályok által előírt jelenlegi folyamatszabályozás államigazgatási szinten egy jó nyilvántartást sem eredményez, nem is eredményezhet. Az átfedéssel érintett területek:  a települések közigazgatási területét ábrázoló földmérési alaptérképek (bel- és külterület ábrázolásával);  a belterületi közműnyilvántartás;  az építmény-nyilvántartás; 82

Önkormányzatok geoinformatikai adatbázisa  a külterületen lévő nyomvonalas és kapcsolódó létesítmények nyilvántartása;  a lakásépítéssel, megszűnéssel kapcsolatos nyilvántartás. Az ingatlan-nyilvántartási térképeken az épületeket a telekkönyvi hagyományok miatt két szinten tartják nyilván:  ha az épület és a földrészlet tulajdonosa azonos személy vagy szervezet, akkor az épület saját HRSZ nélkül van feltüntetve a térképen és regisztrálva az ingatlannyilvántartásban (a földrészlet egyedi azonosítóján);  ha az épület tulajdonosa nem azonos a földrészletével, akkor az épület saját helyrajzi számot kap, amelyet feltüntetnek a térképen is. A helyrajzi számhoz tulajdoni lapot is készít a földhivatal, így az épület önállóan is forgalomképessé válik. Az ilyen épületeket egyéb önálló ingatlanoknak nevezi a jogszabály. Az ingatlan-nyilvántartás pontatlanságát a HRSZ nélküli épületfeltüntetéseken kívül a következő szempontok és érdekek is okozzák:  a tulajdonosok az elmúlt évtizedekben számos különböző célú épületet építettek építési engedély nélkül;  az épületekkel kapcsolatos érvényes építési és használatbavételi engedély földhivatali térképeken történő feltüntetése külön eljárási díjhoz kötött, amelynek a költségét a tulajdonosnak kell kifizetni;  az épületfeltüntetés elmaradása nincs következetesen szankcionálva;  az épület-feltüntetéshez számos, a tulajdonos számára további költséget eredményező joghatás társulhat, pl. adófizetés, vagyonnyilatkozatban történő feltüntetés, stb. A fenti okok miatt az önkormányzat azzal a helyzettel szembesül, hogy a közhiteles földhivatali nyilvántartásnál a saját nyilvántartása mindig pontosabb, használhatóbb. Ugyanakkor az önkormányzat saját nyilvántartása egyedi és csak szűk körben használható: amíg az ingatlan-nyilvántartás adatai országosan egységesek és a TAKARNET24en keresztül bárki, bárhonnan és bármikor lekérheti, addig a naprakészebb önkormányzati adatok egyediek és gyakorlatilag hozzáférhetetlenek. Ezért modellünk megalkotásánál alapcélként definiáljuk az önkormányzati adatvagyon hasznosíthatóságának, a nemzeti téradat infrastruktúrába illesztésének térinformatikai eszközökkel történő támogatását, illetve az adatprezentáció alapját képező adatintegráció feltételének számító adattisztítás, adatkonszolidáció valamint adatmigráció eljárásrendjének kidolgozását az egységes formátumú és adattartalmú, folyamatos működtetésű adatbázis kialakításának céljából. Témakörünk szempontjából fontos elméleti és gyakorlati tapasztalatok, ajánlott megoldások az irodalomjegyzékben találhatóak.

83

A kutatás-fejlesztési központok fejlesztése és megerősítése

3. Javasolt megoldás Ahhoz, hogy az építéshatósági ügyintézés jelenlegi helyzetéből a kívánt célt elérjük, egy jól megtervezett tevékenység-sorozatot kell végrehajtani. Ennek egy fontos és időrendben is elől álló eleme a geometriai adatokat tartalmazó adatbázis megtervezése, modellezése és a gyakorlatban történő kipróbálása. A javasolt megoldással szembeni alapkövetelmény, hogy a rendszerben folyamatosan követhessük a nyilvántartott téradatok eredetét: térbeli információ felvitele és adatmódosítása csak dokumentum alapján történhessen, és ez a forrásdokumentum a rendszerben bármikor lekérdezhető legyen. A fejezet első két alpontjában összefoglaljuk a kutatás során kidolgozott elméleti modell főbb jellemzőit, majd a harmadik alpontban bemutatjuk az ideális modell egy gyakorlati megvalósítását biztosító pilotprojektünket és az ezzel elért eredményeket.

3.1. Az adatbázis Az építéshatósági ügyintézés szempontjából kétféle informatikai struktúraszintű megoldási variáns lehetséges: egyik megoldásban létezik központi, országos térinformatikai adatbázis, míg a másik megoldásban ez nem létezik, helyi szinten kell megoldani a feladatokat. A kutatási célunk teljesítése érdekében a tudományos modell kidolgozása során az ügyintézési folyamat központi szereplőjét, az önkormányzati folyamatrészt modellezzük. A modellezés során a következő főbb szempontokat kell figyelembe venni:  a kidolgozott szoftverelemek ne csak az önkormányzatoknál, hanem a központi térinformatikai szolgáltató rendszerben is alkalmazhatók legyenek, valamint a folyamatban résztvevő többi hatóság térinformatikai jellegű feladatait is támogassák a fejlesztett elemek;  a kidolgozott szoftverelemek tetszőleges minősített iratkezelő rendszerhez csatlakoztathatók legyenek;  a téradatok adatbázis-kezelőjét többféle relációs adatbázis közül lehessen kiválasztani (Oracle, PostgreS, MySQL);  a jogosultsági rendszer összekapcsolható legyen a minősített iratkezelő és a központi térinformatikai adatbázist kezelő rendszer jogosultságkezelésével (egyszeri belépés követelménye, stb.). A szoftver adatbázisa általános objektumorientált térkép-adatbázisra épül, amelynek részhalmaza a DAT1-M1 szabályzatban definiált adatbázis. Mondhatjuk tehát, hogy a DAT1-M1 szabályzatban definiált adatszerkezettel felülről kompatibilis. Mivel általános célú, ezért képes tetszőleges adatforrásból származó térképeket tárolni. A térkép egyszerű tárolásán túl a modell a következő fontosabb tulajdonságokkal rendelkezik: 84

Önkormányzatok geoinformatikai adatbázisa         

tetszőlegesen bővíthető objektumszerkezet; több térkép tárolására alkalmas adatszerkezet; időbeli és jogi változások egyszerű és gyors követése; változás-betöltés hatékony támogatása; változás-vezetés követhető támogatása; objektum-kapcsolatok korrekt kezelése; kapcsolat több külső adatbázis objektumaival; topológia hatékony kezelése; térképkészítés hatékonyságának növelése.

Egyed-kapcsolat diagram: LOAD_EVENT 0+ LOAD

MAP_VERSION 0+

0,1

0,1 SURFACE 0+ 1+

GROUP 0+ 0+ USER 0+ 0+

0+

0+

0+

MAP

BOUNDARY 0+

0+

0+ OBJECT 0+

0+

0,1

0+

1+

0+

1+ POINT 0+ 0+

0+ 0,1

HIERARCHY_ELEMENT 0+ HIERARCHY

0,1

0,1

LINE

0+

LABEL 0+

0+

SYMBOL 0+

0,1

VISUAL_ATTRIBUTE

15. ábra

3.2. A folyamat Az ideális modell koncepciójának megalkotásánál a következő események várható bekövetkezését vettük figyelembe:

85

A kutatás-fejlesztési központok fejlesztése és megerősítése  az államigazgatásban a jelenlegi papíros alapú ügyintézést fel kell váltania a digitálisnak;  várhatóan jogszabályi előírás lesz, hogy minden építéshatósági engedélyezési folyamatban a beruházói oldalon megfelelő működési engedéllyel rendelkező szakembernek (mérnöknek) kell majd közreműködnie. A dokumentumok szabványos formátumúak, így a tervező és a hivatalok közötti kommunikáció a papíros alapról elektronikus adatcserére fog áthelyeződni;  az államigazgatásban el kell terjednie annak a szemléletnek, hogy a különféle igazolásokat nem az ügyfélnek kell papíralapon hoznia, hanem a kontrolladatokat az eljáró hivatalnak elektronikus úton kell lekérnie az adott adatok karbantartásával megbízott hivataltól;  mivel az ügyekkel kapcsolatos dokumentumok elektronikusak, ezért kedvezőbb költségű ezek mozgatása és tárolása. Az archiválás és levéltárazás teljes, egyszerűbb és áttekinthetőbb szabályrendszere könnyebben kidolgozható és megvalósítható. A felsorolt események várható bekövetkezése, a szükséges intézkedések megtétele jelentősen javítja majd az ügyintézés teljesítménymutatóit, lecsökkenti az ügyintézési ráfordításokat, az ügyintézési időket és költségeket, valamint támogatja a törvény előtti egyenlőséget, ezzel javítja az állampolgári közérzetet, növeli a befektetői bizalmat, öszszességében jelentős gazdaságélénkítő hatásukkal számolunk.

3.3. A pilot ismertetése Az előző két alpontban bemutatott általános elméleti megoldás gyakorlati megvalósítása és kipróbálása érdekében összeállítottunk egy pilot-projektet. A K+F pilot-projekt célja, hogy gyakorlati példákon keresztül bemutassuk az építéshatósági ügyintézés térinformatikai vetületét, és kidolgozzuk a téradatokkal kapcsolatos hatósági ügyintézést legjobban támogató szoftverváltozatot. A tudományos modell az alapfolyamatra koncentrál, elsősorban a geometriai adatok adatmanipulációját és a megjelenítést támogatja. A tudományos modell nem kész szoftver, egyszerű a jogosultság- és a hibakezelése. 3.3.1 A feladat lehatárolása, kapcsolatok egyéb rendszerekkel Mivel a szoftvercsomag valamennyi tevékenységet támogató, teljes körű funkcionalitását a rendelkezésre álló rövid idő és kis kapacitás miatt nem tudtuk volna biztosítani, ezért a feladatot úgy határoztuk meg, hogy csak a kritikus tevékenységek készüljenek el, és ehhez a lehető legkevesebb programozási kapacitást használjunk fel. Ezért nem a tudományos szoftvernek, hanem az előre definiált kapcsolatoknak kell biztosítani egyrészről a térinformatikai adatbázis aktualizálásához szükséges forrásadatokat, másrészről azokat a szolgáltatásokat, amelyeket a naprakészen tartott adatbázisból a karbantartást végző igényel. A saját térinformatikai adatbázis tartalmazza a módosító adatok jóváhagyásának azonosító adatait és a módosítások érvényességének kezdetét.

86

Önkormányzatok geoinformatikai adatbázisa Az elkészített szoftver egy kisebb-nagyobb módosítást igénylő interfész segítségével bármilyen iratkezelő rendszerhez, valamint az adott szakterület szakrendszeréhez, esetünkben az építésügyi rendszerhez illeszthető. Ugyancsak interfésszel megoldható a geometriai adatok feldolgozottsági státuszainak azonnali visszacsatolása az iktató és/vagy a szakhatósági rendszerekbe. Az illeszkedést a tudományos modell estében egy egyszerű adatrögzítő programmal oldottuk meg, ami lehetővé teszi az iratkezelő és a szakrendszerekből származó tetszőleges nyilvántartási és leíró adatok, dátumok egyszerű felvitelét, valamint az ügyhöz tartozó digitális formájú dokumentumok, ezen belül elsősorban a térinformatikai adatbázis aktualizálásához szükséges geometriai adatokat tartalmazó állományok csatolását.

16. ábra Az üggyel kapcsolatos kérelmek és határozatok nyilvántartási adatait valamint a csatolt fájlokat NoSql típusú Mongo adatbázisban tároljuk. Ugyanitt tároljuk a geometriai adatokat tartalmazó forrásfájlokat és magukat a geometriai adatokat is. Külső geoinformatikai adatokat tartalmazó szabványos fájlok (ESRI, DAT, stb.) adatait először GeoJSON formátumba konvertáljuk az egységes geometriai állomány érdekében, és ebben a formátumban tároljuk a Mongoban. A szoftverhez tartozik egy szervízprogram, amely a Mongo adatbázisból a másik, Postgres SQL adatbázisba konvertálja a térinformatikai adatokat. A kezdeti ősfeltöltés is ezen a folyamaton keresztül valósult meg, így pontosan dokumentált a térinformatikai adatbázis valamennyi adata.

87

A kutatás-fejlesztési központok fejlesztése és megerősítése Ezzel a szervizprogrammal lehet az egyes kérelmekhez tartozó épületfeltüntetési rajzok geometriai adatait is a Mongoból betölteni a Postgres adatbázisba. A geoinformatikai adatok webes megjelenítését támogató mapserver az SQL adatbázishoz csatlakozva folyamatosan mutatja az időközbeni, az ügyintézés előrehaladtával bekövetkező adatváltozásokat. 3.3.2 Az elkészült modell gyakorlati kipróbálása Az elkészült modell gyakorlati kipróbálása érdekében együttműködési megállapodást kötöttünk a Siófoki Önkormányzattal, így a pilot-modell adatbázisának tartalma az önkormányzat illetékességi területének nyilvántartási adatai lettek. Az Önkormányzattal kötött megállapodás keretében átvett adatok betöltése a következők szerint történt:  a földrészlet-adatok betöltése teljes körűen megtörtént; az adatok objektumként kezelhető formában álltak rendelkezésre;  az épületadatokat spagetti formában kaptuk, épületobjektumoknak történő megfeleltetésük automatikusan csak kb. 50%-ban volt elvégezhető, de a prezentációs céloknak így is megfelelt. Az így létrehozott adatbázis már alkalmassá vált az önkormányzat Építéshatósági Osztályának leggyakoribb hatósági feladataival kapcsolatos geometria-adatok karbantartásának és a téradatok megjelenítésének kismintán történő kipróbálására, bemutatására. Konkrét példákon keresztül követhettük az építeni vagy lebontani tervezett épületeknek az építési engedély kérésétől a használatbavételi engedély megadásáig történő, hatósági folyamat szintű megjelenítését illetve megjelölését a térképen. Az eszközzel jól demonstrálható az elsőfokú építésügyi hatóság térinformatikai adatbázisában az épületadatok naprakészen tartását biztosító szolgáltatás nyújtása. 3.3.3 Az önkormányzattal egyeztetett építésügyi hatósági eljárás folyamat ábrája Az eljárás folyamatát a 17. ábra mutatja (lásd alább). 3.3.4 Eredmények A működő modell lehetővé teszi a geometriai adatok térbeli elhelyezkedés és ügytípus szerinti karbantartását és megjelenítését. Ügytípus az építéshatósági ügyintézési folyamat elemei, és ezek egy része a geometriai adatok módosulását is eredményezheti. A valóságos ügyintézési folyamat elemeinek csak egy része olyan tevékenység, amelyeknél a státuszváltozás mellett a geometriai adatok is változnak. Siófok belterületét mutatja a 18. ábra, a színes épületek az építés különböző fázisaiban vannak (nem valódi adatok). A térképen az épületek az építkezés fázisának megfelelő színnel láthatók:

88

Önkormányzatok geoinformatikai adatbázisa

Kére l em

Szi gnál ás

Iktatás

M egérkezett

Várakozás

Kérel em i ktatása

Kérel em áttéte l i l l etékeshez

Nem

Hatá skör

Ig en Ügyfél kö r m egál l apítá sa

El j á rást m egi ndító végzés Várakozás hi á nypótl ásra Űrl ap fel dol gozás

T ervek egyeztetése - Országos építésügyi szabál yzattal , - Hel yi re ndezési tervvel , - Vonatkozó j ogszabál yokkal .

Igen Hi ánypótl ás

Fel szól ítás hi á nypótl ásra

Ne m Értesítés kül dé se a hel yszi ni szem l éről

Hel yszíni sze m l e e l végzése Szükség es Jegyzőkönyv készítése h el yszíni szem l éről

Ki egé szítés Nem szükséges Szakha tósá gok á l l ásfogl al ásai nak b eszerzése Határi dő l e j árt, el utasító végzés Hatá rozat el készítése

Nem

Postá zás - Ügyfél ne k, - azoknak, aki kre nézve j ogot vagy kötel ezettséget ál l apít m eg, - szakhatóságoknak, j ogszabá l yban m eghatáro zott m ás ható ságo knak vagy ál l am i sze rveknek.

T érti vevény Átvéte l i dőpontj ána k rög zítése

Fe l l ebbezé s

Igen

Vi zsgál at

Hel yes vol t

saj át ha táskörben Nem vol t Igen

Határozat j ogerősítés Értesítés

II. fokú el bírl ás fel l ebb ezés tová bb kül dése

Irattározás

17. ábra 89

A kutatás-fejlesztési központok fejlesztése és megerősítése     

építési engedély kérelem beérkezése, (piros); határozathozatal építési engedély kiadásáról (barna); értesítés építkezés megkezdésének bejelentéséről (kék); használatbavételi engedély iránti kérelem beérkezése (zöld); határozathozatal használatbavételi engedély megadásáról (fekete).

18. ábra Az építkezési fázisok térképen való megjelenítését az alábbi ábrasor mutatja.

19. ábra

20. ábra

az építkezéshez kiválasztott terület a 30057/12 hrsz., a térképen nincs épület

a pirossal megjelenő alapterületű épületre az építési engedély iránti kérelmet beadták 90

21. ábra

22. ábra

az építési engedélyt megkapta az építtető

az építkezés megkezdését bejelentette az építtető

23. ábra

24. ábra

a használatbavételi engedély kérése megtörtént

a használatbavételi engedély kiadva

Az egyes objektumok ügyintézési fázis-alapú térképi megjelenítése különösen fontossá válik, felértékelődik  a kormányzati feladatok átszervezésénél, építéshatóságok területi átszervezésekor, összevonásakor, stb.;  intézményen belüli átszervezéskor, új munkatársak munkába állásakor, stb.;  ingatlantulajdonos, építő, beruházó személyének megváltozásakor. Siófok Önkormányzat építéshatósági irodája 2010-ben kb. 2200 ügyben hozott határozatot. Ezek közül kb. 850 építkezéssel (építési engedéllyel) kapcsolatos ügy volt. Ezzel az ügymennyiséggel öt szakember foglalkozott. A napi munkavégzést, a szakmai, ügyintézési átláthatóságot javítaná a modellezett megoldás.

A kutatás-fejlesztési központok fejlesztése és megerősítése A bemutatott modell úgy lett kialakítva, hogy az ügyintézési folyamatok, folyamatelemek és megjelenítési szabályok törzsadat-szintűek, ezért a modell általánosságban is használható megoldás az önkormányzatok egyéb geoinformatikai jellegű feladatainál is. Alkalmazhatóságát a következő területeken javasoljuk kipróbálni, bemutatni:  közmű-nyilvántartás;  telekalakítás nyilvántartása;  fakivágás, -ültetés nyilvántartása;  időszakos területfoglalások nyilvántartása (rendezvények, építkezések, útlezárások, stb. miatt). Ezzel az adatbővítéssel a modell az építéshatósági iroda munkáján kívül az önkormányzat többi szakmai szervezetének munkájához is kapcsolódik. Ugyancsak támogatja a polgármester és a képviselőtestület döntési mechanizmusát. Az adatállomány-változások folyamatos vezetésével és alkalmas jogosultsági rendszerrel a többi államigazgatási szerv (katasztrófavédelem, tűzoltóság, munkavédelem, stb.) a településsel kapcsolatos naprakész nyilvántartási adatokhoz juthat. Település honlapján megjeleníthető aktuális adatokat tartalmazó térkép az állampolgári tájékoztatás hatékony eszköze lehet, ezzel is biztosítva az önkormányzati munka átláthatóságát.

Irodalomjegyzék TeIR (Országos területfejlesztési és Területrendezési Információs Rendszer) https://teir.vati.hu/ TAKARNET24 https://gate.gov.hu/sso/ap/ApServlet?partnerid=fomi DAT1-M1 szabályzat - FVM Földügyi és Térképészeti Főosztálya Budapest, 1996, 1999. építésügy Hollandiában http://www.geonovum.nl/dossiers/rostandaarden/destandaarden és www.omgevingsloket.nl LADM (Land Administration Domain Model) http://www.fig.net/pub/fig2012/am00.04/am00.04_lemmen_uitermark_et_al_6046.p df DAT (Digitális AlapTérkép) http://fish.fomi.hu/termekekhonlap/adathaz/termekek/szabalyzatok/dat_szabvany.ht m INSPIRE direktívák http://inspire.jrc.ec.europa.eu/

92

AMNIS Egy folyamatvezérelt adaptív vállalatirányítási rendszer tervezése és fejlesztése Fekete István, Giachetta Roberto, Máriás Zsigmond, Turó Zsolt

A témában résztvevő munkatársak: Suhajda Zoltán (Amnis Laboris Kft., az AMNIS-koncepció kidolgozója, doktorandusz) Takács Tamás (Amnis Laboris Kft., rendszer-tervező), Fekete István (ELTE IK, docens, projektvezető), Máriás Zsigmond (ELTE IK, doktorandusz), Giachetta Roberto (ELTE IK, tanársegéd, doktorandusz); továbbá: Bánsághi Anna (doktorandusz), Bedő Dániel, Fung Alexandra, Garai Márton, Gazsó János, Kossovics Balázs, Nagy Tamás, Szalmási Zsolt, Turó Zsolt (ELTE IK, hallgatók)

1. Bevezetés Az AMNIS egy korábbi működő prototípussal rendelkező általános célú folyamatmodellező és folyamatkezelő rendszer, amelyet tipikusan az üzleti szférában, vállalati környezetben lehet sikeresen alkalmazni. Az AMNIS új alapokról történő továbbfejlesztése a KMOP-1.1.2-08/1-2008-0002 pályázat keretében, az ELTE-Soft Kft és az Amnis Laboris Kft. közötti megbízásos szerződés szerint valósult meg. A projekt a pályázat 3. mobil kommunikációs és az 5. térinformatikai főirányához, azokon belül négy témakörhöz kapcsolódik. A rendszer kiindulási pontja az evolúciós elv, amelyet a vállalat működési folyamatainak matematikai és informatikai modellezésére, valamint a folyamatok változásainak követésére specializáltunk. Az új fejlesztést az a körülmény tette alapvetően szükségessé, hogy a rendszer dokumentumkezelő funkciója hatékonysági okokból új objektumelvű adattárolási paradigmát kívánt. A jelenlegi fejlesztés keretében az AMNIS-t – a saját korábbi hagyományainak megfelelően – a mozgatható üzemanyag-kutakat használó cégek vállalati folyamataira specializáltuk. Ebben az alkalmazásban mind a mobil kommunikáció, mind a térinformatika releváns része a rendszer működésének. Az említett négy pályázati pillér a teljes szoftver integrált egységében jelenik meg. A rendszer működésében az evolúciós elvet a könnyen szerkeszthető vállalati folyamatok és az azokban áramló dokumentumok jelenítik meg. Az alábbi ismertetésben kitérünk még a rendszer architektúrájára és a fejlesztés szoftverkomponenseire is.

A kutatás-fejlesztési központok fejlesztése és megerősítése

2. Az AMNIS alapelvei A modern vállalati rendszerekre jellemző, hogy modulokból állnak, amelyek számos előre definiált üzleti funkciót tartalmaznak. A rendszer bevezetése során a „gap”-analízisben felfedett speciális elvárásokat és különbségeket a szoftver módosításával, testre szabásával és paraméterezésével valósítják meg. Mivel a vállalatoknak folyamatosan új kihívásokkal kell szembenézniük, üzletviteli folyamataik gyakran változnak, a szoftverrendszereik módosítása gyakorta szükséges, ami folyamatosan magas költséget jelent. A szoftvertechnológiában ismert tény, hogy a szoftverrendszerek fejlesztési és bevezetési költségeit messze felülmúlják a karbantartás és módosítás későbbi költségei (kb. 30:70% arányban).

25. ábra Tankoló automata megrendelése és szállítása Ez nem csak a nagyvállalatok, hanem a kisebb cégek által használt rendszereket is jellemzi. Ebben a szférában ráadásul a vállalatok sokkal kisebb IT-költségvetéssel rendelkeznek. A gondokat jelentősen enyhítheti egy olyan rendszer fejlesztése, amely egy94

AMNIS szerű módon, a szoftver módosítása nélkül testre szabható és bevezethető, majd az üzemeltetés során a cég üzleti folyamatainak megfelelően adaptívan változtatható. Az AMNIS ezt a következőkben vázolt koncepcionális alapvetések mentén valósítja meg. A rendszer semmilyen specifikus üzleti logikát nem tartalmaz, helyette azonban eszközkészletet ad a felhasználóknak annak megvalósítására. Mindezt a vállalati folyamatok és az azokban szereplő dokumentumok („bizonylatok”) központba állításával valósítja meg. Az AMNIS úgy tekint a vállalati folyamatokra, mint dokumentumok sorozatára, amelyek közt a dokumentum egyes celláinak adattartalma áramlik. A folyamatok definiálásához az AMNIS egyfajta grafikus programozási nyelvhez hasonló szerkesztőfelületet biztosít. A grafikus eszköz segítségével a feltárt valós vállalati munkafolyamatokat (25. ábra) modellező AMNIS-folyamatok megalkothatók.

26. ábra Evolúció - AMNIS analógia

3. Evolúciós megközelítés A szervezetet az összetett függvény matematikai fogalmával modellezzük. Ha nagyszámú, de csak néhány, egyszerű működést megvalósító alapelemből sokféle összetett működésű szervezetet szeretnénk építeni, akkor – az evolúciós analógia alapján – kézenfekvő megoldás az összetett függvények alkalmazása (26. ábra). A biológiában az 95

A kutatás-fejlesztési központok fejlesztése és megerősítése alapelemeket mindössze húszféle aminosav alkotja; azok összekapcsolásával keletkeznek a fehérjék, amelyek felépítik az igen nagy változatosságot mutató biológiai szervezeteket. A külvilág hatásai, pl. az ingerek terjedése vagy akár az anyagcsere mind megfeleltethetők az információáramlásnak, és így párhuzamba állíthatók a vállalati folyamatokkal. Az AMNIS alapelve és célja az, hogy benne megvalósíthassuk a gazdasági rendszerek „aminosav” alapelemeit, és azok kapcsolatainak rögzítésével felépítsük a vállalatok belső függvényeit. Ezen a módon kialakíthatóvá válik a (biológiai rendszerek esetén látott) nagyfokú változatosság és adaptív képesség, ami a mai vállalati rendszerek esetén új és innovatív elemnek számít. Az AMNIS aminosavai a dokumentumok, amelyek rögzített adatkapcsolataik által alkotják a folyamatokat, a vállalati rendszerek fehérjéit. A fehérjék összessége pedig magát a vállalati rendszert mint szervezetet alkotja. Az AMNIS-dokumentumok összekötésével kapott folyamatok összességének az állapotai határozzák meg a teljes vállalati rendszert. Az állapotok átmenetét a folyamatok definíciója, az ún. folyamat-sablonok, illetve az azokon működő dokumentum-generálási szabályok („fehérje-szintézis”) határozzák meg. Az említett adaptív képesség az AMNIS esetében azt jelenti, hogy a változó gazdasági folyamatokat a rendszer a kód átírása nélkül, pusztán a dokumentum-generálási szabályok módosításával képes követni.

4. Dokumentumok és üzleti folyamatok Az AMNIS-koncepció alapvetően a folyamatokra helyezi a hangsúlyt. A cégek sikeres és hatékony működésének egyik feltétele a vállalati folyamatok pontos ismerete és tudatos betartása. A folyamatok változása az AMNIS rendszerben „adaptív módon” – programozás nélkül –, csupán a grafikus felület használatával követhető. A rendszer egyik erőssége az a grafikus felület, amellyel a vállalati folyamatok gráfja rugalmas módon megszerkeszthető. A folyamat-gráf csomópontjaiban a vállalat működésére jellemző elemi tevékenységek találhatók. Ezeket a folyamat szerkesztését végző felhasználó az elemi vállalati tevékenységek listájából választhatja ki (27. ábra). A kialakult folyamatábra tetszőlegesen nagyítható és kicsinyíthető, topologikusan átrendezhető a képernyőn (28. ábra). A folyamatok mellett fogalmilag a dokumentumok játsszák a fő szerepet az AMNIS szemléletében. A vállalatok meglepően nagy hányada egy dokumentumorientált rendszert valósít meg. Tulajdonképpen a dokumentumok, illetve azok adatai „áramlanak” a rendszer folyamatainak gráfjában.

96

AMNIS

27. ábra Elemi vállalati tevékenységek listája 97

A kutatás-fejlesztési központok fejlesztése és megerősítése

28. ábra Egyszerű vállalati folyamat: tankolás ellenőrzése A dokumentumok csekély számú általános, fejléc információt tartalmazó mezői mellett, típusonként eltérő számú adatmezőt tartalmaznak. Egy csomópontra nagyítva a megfelelő dokumentum mezői tárulnak elénk (29. ábra).

29. ábra A folyamatszerkesztő egy kinagyított csúcspontja 98

AMNIS A gráf csomópontjai, vagyis a folyamat állomásai között az adatok áramlását a vékony nyilak mutatják. Ez a tényleges adatátvitel elvégzését is jelenti, ha a folyamatra adódik a végrehajtási vezérlés. Az üzleti környezet folyamatos változásából következően az AMNIS-dokumentumok felépítése is folyamatosan változik, új dokumentum-típus verziók jönnek létre. A munkafolyamatok gráfjában az egyes csúcsok a végrehajtás szempontjából a következő típusokba sorolhatók. (1) Párhuzamos: egy ilyen csomóponttól kezdve két végrehajtási szálon – aszinkron módon – ágaztatható el a folyamat futása. (Például egy logisztikai munkafolyamatban ameddig az egyik szálon a beszerzésről és a leszállítás előkészítéséről gondoskodunk, addig egy másik szálon a szerződések kitöltésének párhuzamos eljárása folyhat.) (2) Szinkronizáló: a párhuzamos folyamatok egyeztetésének, az egy végrehajtási szálba való szervezésének az eszköze. (Például az előző logisztikai folyamathoz visszatérve tegyük fel, hogy az egyik szálon a beszerzés már véget ért, az áru leszállításra kész, ám a másik szálon még várakozunk a szerződés megkötésére vagy a pénz beérkezésére. Ha az akadályok elhárulnak, akkor a két folyamat a leszállítás csomópontra lépve egy szálon folytatódik tovább.) (3) Feltételhez kötött: ahogy a neve is mutatja, a csomópont végrehajtásához egy bizonyos feltétel teljesülése szükséges. (Például, ha egy dolgozó autóval jár be, akkor nem szükséges útiköltséges nyomtatványt kitölteni számára.) (4) Iteráló: az ilyen típusú csúcsban foglalt műveletet a csúcsban paraméterként megadott számosságban hajt végre a rendszer. (Például leírható az, hogy minden nap küldjön ki összesítő kimutatást elektronikus levélben a napi árumozgásokról.)

5. Adatmodell és objektum-elvű adattárolás Az AMNIS-ban mint folyamatvezérelt vállalati rendszerben nagy mennyiségű, különböző sémákba tartozó dokumentumot kell tárolni egyetlen adatbázisban. Az attribútumok száma és mennyisége dokumentumtípusonként változik. Ennek a nagy mennyiségű adatnak mind a tárolása, mind az attribútumok alapján történő gyors lekérdezése nehézségekbe ütközik, ezért megoldandó feladatot jelent. A tárolt dokumentumok mindegyike pontosan egy dokumentumtípushoz tartozik. Például egy járműkövető rendszerben nyilvántarthatunk gépjárműveket és célállomásokat mint dokumentumokat. A teherautót leíró dokumentumok tartalmazhatják a sofőr nevét, a teherautó átlagfogyasztását és a rendszámát, míg a célállomásokat a megnevezésük, címük és a GPS-koordinátáik írják le. Minden dokumentumtípusnak lehetnek altípusai (pl. a járművek között személyautók, teherautók és pótkocsis kamionok). Min-

99

A kutatás-fejlesztési központok fejlesztése és megerősítése den dokumentumtípus örökli a szülő típus összes attribútumát, és kiterjeszti azt további attribútumokkal. Ez a struktúra megfelel az objektumorientált programozási paradigmában használt osztályhierarchia koncepciójának, ahol a dokumentumtípusok az osztályoknak, a leszármazás a specializációnak felel meg, egy konkrét dokumentum pedig egy példányosított objektum.

30. ábra Adattárolás A rendszer adatbázis-rétegében a legfontosabb feladat a kategóriarendszer és az előfordulások tárolása és karbantartása, valamint a leíró adatok alapján történő lekérdezések. Mivel az adatbázisban nagyon sok dokumentumot tárolunk, nem csak egy-egy objektum, hanem objektumhalmazok szűrőfeltételek alapján történő lekérdezése is szükséges. A szűrőfeltételek tartalmazhatnak a dokumentumtípusra vonatkozó megszorításokat valamint a leíró adatok egy részhalmazára vonatkozó lekérdezéseket. Ez az adat100

AMNIS hierarchia és a hozzá kapcsolódó lekérdezések egyéb alkalmazásokban is hasznosnak bizonyulhatnak, pl. e-commerce rendszerekben vagy térinformatikai adatbázisokban. Az üzleti környezet folyamatos változásából következően az AMNIS-dokumentumok felépítése is folyamatosan változik, új dokumentum-típus verziók jönnek létre. A korábbi sémaverziók szerint tárolt adatok visszakeresésének is ugyanolyan gyorsnak kell lennie, mint a nemrég tárolt dokumentumok elérésének. Míg bizonyos lekérdezéstípusok esetén elfogadható 30-60 másodpercnél hosszabb válaszidő, addig a folyamatokat kiszolgáló lekérdezések döntő többségénél 1-2 másodperc alatt kell tartani az átlagos válaszidőt a lekérdezett adatok mennyiségétől függetlenül, a keretrendszer hatékony folyamatkezelésének érdekében. Az AMNIS-rendszer fejlesztése során több megvalósítási koncepció is felmerült. Az adatok tárolásához és lekérdezéséhez három különböző prototípust készítettünk. Két megvalósításban relációs adatbázis-kezelő rendszert használtunk: az egyik esetben az „entity-attribute-value” adatmodell egy módosított megvalósítását, a másikban „on-thefly” generált adattáblákban mentettük el az AMNIS-dokumentumokat. A harmadik megvalósítás a dokumentumorientált, sémamentes MongoDB adatbázisban tárolta az adatokat. A rendszereken futtatott „benchmark” tesztek eredményeit (30. ábra) részletesen ismerteti az [1] cikk. Az összehasonlítás alapján a MongoDB-alapú megvalósítást implementáltuk az AMNIS rendszerben.

6. Geoinformatika és mobilkommunikáció Az AMNIS rendszer egyedi tulajdonsága az, hogy „üresen” is értékes eszközt nyújt a vállalatok számára, általános folyamataik leírására és megvalósítására. Mód van arra, hogy a cég szakemberei maguk fejlesszék hozzá a vállalati működésre jellemző funkcionalitásokat. Leginkább azonban úgy számíthat az AMNIS sikeres marketingre, ha egy-egy speciális üzletágban, az ott szükséges funkcionalitással kínálják a vállalatok számára. Egy ilyen üzletág a saját üzemanyag-ellátó rendszerrel, azaz mozgatható benzinkutakkal és tankoló járművekkel (jellemzően munkagépekkel) rendelkező cégek folyamatainak támogatása. A pályázat keretében elkészült a Térinformatikai és mobilkommunikációs (T+M) alrendszer terve, és megvalósításra kerültek a következő funkciók: a céghez tartozó közlekedő járművek mozgásának nyomon követése GPS adatok alapján, a járművek mozgásának térképi megjelenítése, valamint a járművek vezetőivel való kommunikáció, amely a dokumentumcserét is magában foglalja (31. ábra). A vállalatok számára igen fontos, hogy alkalmazottai folyamatos kommunikációban álljanak, különösen olyan esetben, amikor az alkalmazottak nem egy központi helyen dolgoznak, hanem folyamatos kiküldetésben vannak, vagy kihelyezett területeken tartózkodnak. Ide tartoznak a saját üzemanyag-ellátó rendszert használó cégek, amelyek tipikusan a mezőgazdaság, az építőipar, az útépítés, a szállítmányozás stb. üzletágainak 101

A kutatás-fejlesztési központok fejlesztése és megerősítése szereplői. A külső munkahelyek (pl. mezőgazdasági területek) általában csak a mobilkommunikációra adnak lehetőséget az adatok internetes továbbítása esetén. A mai mobiltechnológiában – legyen szó mobiltelefonról, táblagépről vagy autóba szerelt kommunikációs/navigációs eszközről – már minden esetben adott az Internet-használat lehetősége.

31. ábra Térinformatika Az intelligens flottakövetés meghatározó részét képező üzemanyag-kontrolling rendszerének elemeit a pályázati szakaszban feltártuk, de részletes tervezés és a megvalósítás egy későbbi fejlesztés célját képezi.

7. A rendszer szoftverkomponensei Az AMNIS-rendszer architektúrája korszerű szoftver-komponensekből épül fel (32. ábra). A rendszer a felhasználók számára a webes frontend-en keresztül, vagyis a HTML5/JavaScript/AJAX-alapú webes kezelő-felületen érhető el. Ezen módon érhetők el az AMNIS-rendszer folyamatainak, dokumentumainak és dokumentum-típusainak általános adminisztrációs funkciói. Ezen a felületen keresztül lehetséges a folyamatok elindítása is, és a futtatás során a felhasználói interakciók is itt történnek.

102

AMNIS

32. ábra Az AMNIIS rendszer architektúrja Az AMNIS erőssége (és látványos oldala) a HTML5 és JavaScript technológiával fejlesztett grafikus felület, amellyel a vállalati folyamatok gráfja rugalmas módon megszerkeszthető. A folyamatábra tetszőlegesen nagyítható-kicsinyíthető, topologikusan átrendezhető a képernyőn. A gráf csúcsai a folyamat állomásainak felelnek meg. A közöttük történő adatáramlás irányát nyilak azonosítják. A folyamat végrehajtása során a tényleges adatátvitel is megtörténik. Az alkalmazás funkcióinak elérését a böngészőből a PHP-alkalmazásként implementált, vékonykliensként működő proxy szerver teszi lehetővé. A párhuzamosan futtatható üzleti folyamatok végrehajtását az önálló kiszolgálóként üzemelő alkalmazás-szerver biztosítja. A logikai keret implementációja Python nyelven készült. Az operációs rendszertől független szálkezelés a Stackless és a széles körű protokoll-implementációt támogató Twisted keretrendszerben valósult meg.

103

A kutatás-fejlesztési központok fejlesztése és megerősítése Az inhomogén típusú dokumentumok a non-SQL jellegű MongoDB-ben kerülnek tárolásra. A rendszer korábbi verziójának nagy adattömeg esetén tapasztalt lelassulását sikerült kiküszöbölni. A fejlesztés a projektmunka követelményrendszerének megfelelő módon történt. Létrehoztuk a projekt fejlesztői oldalát is a [3] alatt látható címen, a szakmai kommunikáció és a verziókövetés céljára. Számos olyan – elsősorban technikai – részletet, amelyekre ez a leírás nem térhet ki, az érdeklődők ott megtalálhatják.

Publikációk: [1] Zs. Máriás, T. Nikovits, T. Takács, R. Giachetta: A Study of Large Amount of Inhomogeneous Data in Workflow Management Systems. Annales Univ. Sci. Budapest., Sect. Comp. 37 (2012) 275-292. [2] Suhajda Z., Máriás Zs., Takács T., Giachetta R., Turó Zs.: Az AMNIS folyamat alapú vállalatirányítási rendszer fejlesztése. Poszter, ELTE Innovációs Nap, 2012. febr. 24. [3] Az AMNIS projekt fejlesztői weboldala: http://docs.amnisworkflow.hu

104