Ketten az informatikusok szuperligájából

Beszélgetés Marx Dániellel és Varró Dániellel

---

A Neumann János Számítógép-tudományi Társaság 2003-ban Frohner Ákosnak, Marx Dánielnek és Varró Dánielnek ítélte oda a Kemény János-díjat. Ezzel a kitüntetéssel a harminc év alatti kutatók kimagasló teljesítményét ismerik el. Az októberi díjátadás után kettőjükkel beszélgettünk.

Marx Dániel

a Műegyetem számítástudományi és információelméleti tanszékének tudományos segédmunkatársa. A Kemény János-díjat "a magyar képzőművészeti alkotások webalapú adatbázisának elkészítéséért, valamint az információs technológia matematikai megalapozásában végzett kutatómunkájáért" nyerte el.

– A nagyszerű – és egyre bővülő – Web Művészeti Galéria 1996 óta látogatható. Talán még gimnazista volt, amikor elkezdődött a gyűjtemény összeállítása, feldolgozása.

– Nem, már egyetemre jártam. A galéria fizikus nagybátyám, Krén Emil ötlete volt, aki fiatal kora óta vonzódik a képzőművészethez. A kilencvenes évek második felében bontakoztak ki a világháló nyújtotta lehetőségek. Úgy látszott, hogy a gyűjtemény az internet természetes és kézenfekvő alkalmazása: minimális költséggel rengeteg képet és információt tehetünk mindenki számára elérhetővé. Krén Emil foglalkozott a tartalmi kérdésekkel, a képek és a szöveges információk összegyűjtésével, rendezésével, én a programozással.

– Mi volt a feladata?

– A képeket és a szövegeket egymáshoz kellett rendelni és keresőrendszert kellett kidolgozni. A képekből származó információkat tehát olyan formába hoztam, hogy egy program előbányássza a felhasználó kérésének megfelelő képeket. Ez a kérés lehet különleges is: ha valaki például olyan képekre kíváncsi, amelyeken viola da gamba szerepel, de nincsen cselló, megtalálhatja. Természetesen időszakok és szerzők szerint is lehet keresni.

Ki kellett dolgozni a képernyőn látható lapok elrendezését. Sokan elfelejtik, hogy egy weblapon nem a csicsa a lényeg, hanem az, hogy néhány kattintással áttekinthető módon eljussunk oda, ahová akarunk. Itt több ezer képről van szó; a hozzájuk tartozó, több ezer lapot nagyon nehézkes lenne egyenként elkészíteni. Ezért olyan programot írtam, amely a képet és az információt megfelelő módon elrendezi, majd egy megadott sablon szerint állítja elő a lapokat.

Zsigmond-kori, festett szemű lovag
a magyar képzőművészeti gyűjteményből

– Szeret versenyezni?

– Nem vagyok versenyző alkat, de különböző matematikai és programozóversenyeken részt vettem gimnazista és egyetemista koromban, most pedig az egyetem csapatát készítem fel az ACM nemzetközi programozóversenyre. Benedek Balázs barátom egy 24 órás programozóversenyen szerzett tapasztalatokat, s az ő ötlete nyomán mi is rendezünk ilyet.

– Egy vagy több feladatot kell megoldani ezen a "maratoni távon"?

– Egy feladat – egy fő motívum – van, de ez sok részfeladatból áll.

– Hogyan lehet elérni, hogy a feladat megfeleljen a kiszabott időtartamnak?

– Talán kevéssé ismert, hogy egy átlagos programozó és egy programozó guru között akár tízszeres teljesítménykülönbség is lehet. Amin az egyik egy napot dolgozik, az a másiknak esetleg tíz napba kerül. Ezért olyan feladatsort igyekeztünk összeállítani, amit talán nem tudnak teljesen megoldani 24 óra alatt, de mindenki talál benne kedvére való részt, és még a legjobb csapat sem unja el magát a verseny vége előtt.

– Végig kitartanak a résztvevők?

– Előfordul, hogy egy-két embert pár percre elnyom az álom, de még hajnali 5-kor is lelkesen verik a billentyűket, és az utolsó percekben is megpróbálják megkeresni a hibákat vagy megírni az újabb programrészleteket.

– Miért szeretik ezeket a versenyeket?

– Különös hangulata van, amikor 120 ember reggel 9-től másnap reggel 9-ig dolgozik összezárva. Éjfél is elmúlik, aztán felvirrad a nap, de még mindig nincs kész a program. Az informatikában egyébként gyakran előfordul, hogy szoros határidőket szabnak. Mindenki ismeri azt az érzést, amikor másnapra el kell készülnie a programnak, és már csak egy éjszakája marad.

– Ki a jó programozó?

– Igyekeztünk úgy összeállítani a feladatot, hogy az érjen el jó eredményt, aki "az életben" is jó programozó. A feladatkiírás körülbelül ötven oldal volt. Iszonyatos mennyiségű információt belezsúfoltunk. Az első próbatétel az, hogy valaki átlásson ennyi információt. Ez a valódi munkáknál is rendkívül fontos. Sokszor elektronikus formában átadott, több ezer oldalas dokumentációból kell kihámozni a lényeget pillanatok alatt. Először tehát meg kell érteni, mi a feladat. Utána csapatban kell dolgozni. Szét kell osztani a feladatot, együtt kell működni a többiekkel, együtt kell egészet alkotni. Egy háromfős csapat 24 óra alatt tulajdonképpen kilenc munkanapot dolgozik végig. Szükség van a matematikai, algoritmuselméleti ismeretekre, hogy a problémákra a lehető legjobb megoldást találják meg. Persze, a programozási gyakorlat is nélkülözhetetlen. Aki programozással foglalkozik, tudja, hogy nem a program megírása kerül sok időbe, hanem az, hogy a munka hibátlan legyen. Egyrészt nem szabad hibákat elkövetni, másrészt a hibákat gyorsan ki kell szűrni. Rutin és intuíció kérdése, hogyan talál rá az ember a több ezer soros program egyetlen hibás zárójelére.

– Milyen feladatokat tűznek ki?

– Tavalyelőtt például – a verseny fő támogatója, a Fornax Rt. jóvoltából – sikerült legorobotokat szereznünk. A cég – a kornak megfelelően – már nemcsak összeépíthető játékokat gyárt, hanem programozható motorokat is. A csapatoknak ilyen robotokat kellett programozniuk például arra, hogy labirintusban tájékozódjanak vagy morzekódokat olvassanak el.

– Kutatási területe – honlapjának felsorolása szerint – a "gráfszínezés, algoritmuselmélet, kombinatorikus optimalizálás, bonyolultságelmélet". A matematikai probléma az alkalmazásokból adódik, vagy a matematikai elgondolásokat ültetik át a gyakorlatba?

– Az algoritmuselmélet azzal foglalkozik, hogy milyen számításokat milyen sorrendben, milyen módon végezzünk el egy probléma számítógépes megoldása érdekében. Ez a gyakorlatban nagyon fontos, mert ha bizonyos problémáknak csak úgy "nekiállunk", akkor elképzelhető, hogy akár tízszer, százszor, ezerszer lassabb a megoldás, mint amikor a megfelelő algoritmust alkalmazzuk. Az algoritmuselméletet tehát gyakorlati alkalmazások motiválják, s én különböző gyakorlati, illetve elméleti szempontból érdekes problémákra igyekszem minél hatékonyabb megoldást találni.

Az algoritmuselmélet párja a bonyolultságelmélet. Ennek az eszköztárával azt próbáljuk megmutatni, hogy vannak olyan problémák, amelyekre, ha megfeszülünk, akkor sem találunk hatékony, gyors algoritmust. Nem azért, mert buták vagyunk, hanem azért, mert nincs. Ilyenkor más megközelítést kell keresnünk.

– Mik a gráfok és miért színezik ki őket?

– A gráfok csúcsokból és csúcsokat összekötő élekből állnak. A csúcsok lehetnek például városok és az élek városokat összekötő utak.

A gráfelmélet több száz éves része a matematikának. Nagyon sok érdekes tételt és eredményt értek el benne. Gyakorlati szempontból is fontos, mert a világban megjelenő számos dolgot a gráfokkal lehet a legjobban modellezni. Manapság különösen előtérbe került amiatt, hogy például a számítógép-hálózatok, az internet is modellezhetők úgy, mint csomópontok, amelyek élekkel vannak összekötve. A gráfok és a gráfokkal kapcsolatos algoritmusok rendkívül jelentősek.

A gráfok színezése azt jelenti, hogy minden csúcsnak egy színt adunk úgy, hogy a szomszédok különböző színt kapjanak. A színezés valójában sokkal általánosabb fogalom, és más jellegű, színeket nem tartalmazó problémák megoldására is alkalmas. Például ha állatokat kell ketrecekbe rakni úgy, hogy az egymással rossz viszonyban levő állatok különböző ketrecekbe kerüljenek, akkor itt a színek a ketrecek és a csúcsok az állatok.

A színezésekkel ütemezési, kiosztási feladatokat is modellezhetünk. Például a mobilhálózatokban a különböző bázisállomásokhoz, tehát a rádióállomásokhoz úgy kell kiosztanunk a frekvenciákat, hogy a szomszédos állomások nem kaphatják ugyanazt a frekvenciát, mert akkor interferencia lép fel. Itt az állomások a csúcsok, a kiosztandó színek a frekvenciák. A szomszédos állomások között van egy él, ami azt jelenti, hogy a szomszédos állomások nem kaphatják ugyanazt a színt, nem kaphatják ugyanazt a frekvenciát.

– Mi volt mostanáig a legnagyobb szakmai élménye?

– A legrangosabb konferenciát, amelyre eddig eljutottam, éppen Budapesten rendezték meg – a lakásomtól öt percre.

Úgy gondolom, a kutatásban az a legelső feladat, hogy tudjuk, mi az, amit mások tudnak. Az eredményeket részben a konferenciákon, részben a folyóiratokból, illetve az interneten elérhető cikkekből ismerhetjük meg.

– Kemény János, akiről a most kapott díjat elnevezték, részt vett a BASIC nyelv kidolgozásában. Gondolt már arra, hogy egyszer hasonló alkotás kerüljön ki a keze alól?

– Az eddigi időszak és a következő pár év munkáját felkészülésnek tekintem a nagy feladatra – amit még nem ismerek. De meg kell szereznem a jártasságot, hogy ha látom, mi a nagy feladat, ki tudjak állni.
 

---

Varró Dániel

a Műegyetem méréstechnika és információs rendszerek tanszékén tanársegéd. A Kemény János-díjjal "az UML-modellek transzformációja és matematikai analízise terén kifejtett tudományos munkájáért, magas szintű publikációs tevékenységéért" tüntették ki.

– A Fazekas Gimnáziumba járt, speciális matematika tagozatra. Régen inkább az ELTE matematikus vagy fizikus szakára vezetett innen az út. Miért a Műegyetemet választotta?

– Hatan-heten jöttünk ide az osztályból, többen az olimpiai csapatból is. Ők azt mondták, nekik már nem hiányzik az az elvont matematika, amit a matematikus szakon oktatnának, és egy kicsit "földhöz ragadtabb" dolgokkal szeretnének foglalkozni, én inkább azon hezitáltam, hogy matek–angol szakos tanárnak vagy informatikusnak menjek-e.

– A nyelv az informatikában is fontos szerepet játszik. Miért használnak a programozáshoz mesterséges, formális nyelveket?

– Az emberek közötti kommunikáció során a nyelvi elemek aránya körülbelül 20 százalék vagy ennél is kevesebb. Az összes többi információ "nyelven kívüli", nem verbális elemekből, például gesztusokból, hanglejtésekből származik. A számítógép ezt a "metakommunikációt" nem érti. Ahogy mondani szokták: a komputerek nem a vágyainkat teljesítik, hanem a parancsainkat. Ezenkívül az emberi nyelv többértelműségét – gondoljunk például az azonos alakú, de többféle jelentésű szavakra – a programozáshoz ki kell küszöbölnünk.

– Az utóbbi két évtizedben a programozási szemlélet átalakult. Mi a lényege ennek a változásnak?

– A kezdeti programnyelvek – építészeti hasonlattal élve – úgy működnek, mintha egy ház építésekor pontosan megmondanánk, melyik tégla hová kerüljön. Az új, objektumorientált szemléletben már a fal, a válaszfal vagy a födém az építőelem. Mondhatnám azt is, hogy a téglákból, mint építőkövekből, egy picit absztraktabb építőelemeket hozunk létre, de ezek – elvontságuk ellenére – közelebb vannak a gondolkodásunkhoz. Így az építészmérnöknek – illetve annak a szoftvermérnöknek, aki egy bonyolult információs rendszert tervez – csak a falak elhelyezésével kell törődnie.

– Ki építi föl később a falat?

– A programozó, de ahhoz, hogy le tudja rakni a téglákat, a kezében kell tartania a ház tervét. Számos szoftverrendszert még ma is szinte terv nélkül készítenek.

– Nem tekinthetjük tervnek a folyamatábrát?

– A folyamatábra fontos lépcső a szoftverek modellezése felé vezető úton, de nagyon alacsony, elemi szintű: nem sokkal haladja meg azt a programnyelvet, amelyet használunk, s csak a régi típusú, strukturált programnyelvekre működik. Az objektumorientált rendszerekhez új tervezési, modellezési nyelveket kellett kitalálni. Ezek kialakításakor természetesen merítettek ötleteket a régi jó folyamatábrából is.

– Úgy tudom, többnyire grafikus, vizuális nyelveket dolgoztak ki. Nem paradoxon, hogy egy nyelv vizuális?

– Nem, mert egy ház terve is vizuális. A vizuális tervezési módszerek más mérnöki ágazatokban nagyon beváltak, mégpedig azért, mert nem kell megépítenünk egy házat vagy összeszerelnünk egy autót ahhoz, hogy fogalmat alkothassunk a működéséről. Elég, ha modelleket, maketteket készítünk. Emiatt egyáltalán nem meglepő, hogy a szoftvertervezéshez is használnak vizuális tervezési módszereket. Az igen elterjedt UML (Unified Modelling Language, egységesített modellezőnyelv) például különböző diagramokból, tehát képekből álló tervrajzot kínál a szoftverrendszerek kifejlesztésére.

– Arról van szó, hogy egy bonyolult rendszer létrehozásához egyszerűsíteni kell?

– Ahhoz, hogy egy komplex rendszert átlássunk, ma alapvetően nem zsenialitás szükséges, hanem jó – úgy szokták mondani, absztrakciókkal támogatott – tervezési módszer. Korábban, a 60-as, 70-es években a programozó volt a mágus, aki mindenhez értett, átlátta az egész programot. Az objektumorientált technológiákkal – a 80-as, 90-es évektől kezdve – ez megszűnt, hiszen sokkal nagyobbak lettek a megalkotásra váró rendszerek. Most a tervezőcsoportoknak együtt kell működniük. A vizuális tervezési nyelvnek hatalmas szerepe van abban, hogy egy szoftvermérnök megértse azt, amit a másik mérnök csinál. Angolul tömören úgy mondják: egy kép ezer szónál is többet ér. Később, amikor részletesen akarunk valamit megfogalmazni, lemegyünk a természetes nyelvek vagy a matematika szintjére, de addig a grafikus, képi leírások nagyon hasznosak.

– Milyen szoftverek tervezésére használják az UML vizuális nyelvét?

– Az irodai alkalmazásoktól kezdve a vasúti biztonsági berendezések vagy a repülőgépek vezérlési szoftveréig nagyon széles azoknak a rendszereknek a skálája, amelyek az UML-ben leírhatók.

Sajnos, az UML esetén a tervrajzunkban még mindig lehetnek többértelmű részek, problémát jelenthet a programozónak, mire is gondolt a tervező. Egy irodai szoftvernél ez kevésbé kritikus. Ha elszáll a program, legfeljebb káromkodom egyet, aztán újraindítom. De nagyon sok olyan alkalmazás van – ezeket hívják nagy megbízhatóságú, biztonságkritikus szoftvereknek –, ahol emberéletbe vagy temérdek pénzbe kerülhet, ha a rendszer felmondja a szolgálatot. Ezért a szoftver rendszertervét – még az elkészítése és használatbavétele előtt – szigorú vizsgálatnak kell alávetnünk.

A hagyományos mérnöki ágazatokban több évszázados, matematikailag, fizikailag megalapozott módszerekkel vizsgálhatjuk, hogy a rendszerterv megfelel-e azoknak a kívánalmaknak, amelyeket a megrendelő támaszt. Előre kiszámíthatjuk például, nem dől-e össze egy ház.

A szoftverek esetén az a baj, hogy a diagramokat tartalmazó, UML-alapú rendszerterv és a matematikai leírás, ami ennek a viselkedéséért felelős, nagyon távol esik egymástól. Tehát van egy olyan leírásunk, amellyel a mérnökök szeretnek tervezni, csakhogy ez pongyola, és van egy precíz, analízisre alkalmas változat, amellyel a matematikusok vagy a matematikai analízis automatizált eszközei dolgoznak.

– Ki közvetít a két fél között? Ki végzi el a transzformációt?

– Hagyományosan az végezte el, aki tudta. Az UML-modellből "legyártottuk" a megfelelő matematikai leírást, legalábbis egy olyat, amiről azt hittük, hogy megfelelő.

A csoportunk – Pataricza András vezetésével – részben azon dolgozik, hogy ezeket a matematikai leírásokat automatikusan származtassa az UML-modellekből. A ház tervéből a statikus automatikusan jut el azokhoz a matematikai, fizikai egyenletekhez, amelyeket azután vizsgálnia kell. Az UML-modellből szintén automatikusan akarjuk megkapni azt a matematikai modellt, amellyel a szoftverünket elemezhetjük.

Például van egy vasúti kereszteződésünk, amit egy szoftveralkalmazás vezérel. Meg szeretnénk bizonyosodni arról, hogy nem kaphat-e egyszerre zöld jelzést a vonat és az autó is. A matematikai analízis megmutatja, ha valami hiba van a matematikai modellben. De ezzel még mindig csak egy absztrakt matematikai leírásban találtuk meg a hibát, nem az UML-modellben. Ezért visszafelé is szeretnénk "közlekedni" a transzformációval, hogy a mérnök rendszerében is meg tudjuk mutatni, hol a baj.

– Mi az ön feladata a csoportban?

– Ezeket a transzformációkat teszem tervezhetővé. Ez azt jelenti, hogy nemcsak a repülőgép-vezérlő vagy az irodai szoftver, hanem az automatikus transzformáció is számítógépes program. Ennek a kifejlesztéséhez azonban nem állt rendelkezésre általános eszköz. Olyan megoldásokat kellett találni, amelyek matematikailag precízek, hogy a transzformációt végrehajtó programot automatikusan létre tudjuk hozni. Ugyanakkor elvárjuk, hogy a transzformáció leírása minél inkább UML közeli legyen, mert így a mérnökök is megtervezhetik a transzformációkat. Tehát a fő kihívás az volt, hogy automatikus átmenetet teremtsünk egy magas szintű grafikus leírás és egy ennél lényegesen alacsonyabb szintű matematikai leírás között.

– Hol tart most ez a munka?

– Elkészült egy "prototípusszintű implementáció". Ez még nem késztermék, mert sok-sok olyan programozási feladat van hátra, ami egy doktorandusz idejébe nem fér bele, de a rendszert – amelyet a vizuális és automatizált modelltranszformáció rövidítéséből VIATRA-nak neveztünk el – már kipróbáltuk. Azt a nem meglepő eredményt kaptuk, hogy az UML-modellek és a matematikai leírások közötti transzformációs lépés sokkal gyorsabb, mint a matematikai analízis. Ennek az az oka, hogy a matematikai analízis során a rendszer nagyon sok lehetséges állapotát vizsgáljuk: olyan állapottereket kell bejárnunk, amelyek mérete nagyobb, mint a világegyetemben lévő atomok száma.

– Félelmetes reflexű kapus hírében áll. Van valamilyen kapcsolat a két "szakma" között?

– Az elvont, informatikai feladatok megoldása közben nagyon jó kikapcsolódás a foci. A kétféle elfoglaltság talán abban rokon, hogy mindkettő nagyfokú koncentrációt igényel. Egy kapus esetén kevésbé számít a fizikai felépítés vagy a labdaérzék, inkább az a fontos, mennyire "van ott fejben", mennyire tudja kikapcsolni a külvilágot meccs közben. A koncentráció a kutatás szempontjából is alapvető. Ha valamivel foglalkozom, akkor elsüthetik az ágyút a fülem mellett, nem nagyon kapom rá föl a fejem.

Doktori védés (Staar Gyula felvétele)

– Az internetes keresők a "Varró Dániel" kifejezésre például a "Fordítások a középkor és a reneszánsz irodalmából" találatot is kiadják. Az ember nincs ahhoz hozzászokva, hogy névrokonai bukkanjanak föl.

– Ráadásul egyidősek vagyunk! A dolognak az a pikantériája, hogy én szerepelek a telefonkönyvben. Ennek megfelelően rajongói levelek egész garmadáját kaptam, amit aztán továbbítottunk az igazi címzetthez. Amióta Szilvi, a feleségem rámondta az üzenetrögzítőnkre, hogy "Varró Dániel, a költő nem itt lakik", már csökken a telefonok száma, de Varró Dánielt, a műfordítót továbbra is keresik nálunk. Talán majd két betűvel meg egy ponttal (egy "dr." jelzéssel) különböztetem meg magam.

(Erre már nem kell sokáig várni, hiszen novemberben volt doktori disszertációjának házi védése.)

---

Természet Világa,

135. évfolyam, 2. szám, 2004. február http://www.chemonet.hu/TermVil/  http://www.kfki.hu/chemonet/TermVil/