Nyelvtannácik előnyben

Az utóbbi években erősen lecsengett a modellezés és a modellező eszközök iránti figyelem. Ennek hátterében többféle ok húzódhat*, de tény, hogy a standard modellezési nyelv (UML) és modellező eszközök robusztussága nem segít a helyzeten. Ugyanakkor sok projektben felmerülne az igény kisebb, domain-specifikus nyelvek használatára, amelyekhez viszont sok esetben mellőzni kellene a fejlesztői környezetekben meghonosodott kényelmi funkciókat. Vagy mégsem?

Amióta számítógépekkel dolgozunk, a szakemberek mindig is törekedtek arra, hogy csökkentsék a munkafolyamataikban és a végtermékben jelentkező komplexitást, és olyan eszközöket hozzanak létre, melyekkel gyorsítani és egyszerűsíteni lehet a kódolást. Ezt a célt szolgálja, ha absztraktabbá, szervezettebbé tesszük a fejlesztést és az összetartozó logikai egységeket önálló, önmagukban is megragadható blokkokban kezeljük. Röviden: modelleket építünk.

A szoftvermodellezés mára erősen szabványosított, bizonyos értelemben már-már túlszabályozott területté vált, melynek köszönhetően gyakran előfordul, hogy viszonylag egyszerű problémák megoldásához is óriási eszközkészletet kell megmozgatnunk: az UML a legtöbb projekt igényeihez képest feleslegesen sok nyelvi elemet tartalmaz, aminek adott esetben csak a töredékére volna szükségünk. Ráadásul, a legtöbb modellezőeszköz nem támogatja a modell tömeges módosítását, átszerkesztését: a modelleket jellemzően „rajzoláson” keresztül kell létrehozni, ami, amellett, hogy lassú, az alapvetően szöveges interfészekhez szokott fejlesztőktől idegen. A megoldást részben a DSL-ek (domain-specific language), vagyis a kicsi, jellemzően egyetlen egyszerű célra létrehozott nyelvek jelenthetik, melyekben könnyű kezelni egy-egy feladatot. A szabványos útról történő letérés mellett, a DSL-ek praktikus korlátja ugyanakkor, hogy a saját nyelv létrehozásakor nem feltétlenül kapunk olyan funkciókat – például: nyelvi ellenőrzés, kódkiegészítés stb. –, melyek rendkívül fontosak és hasznosak lennének a hatékony munkához.

Mit kellene tehát tudnia egy ilyen eszköznek? Először is egyszerűnek kell lennie, hiszen célorientált nyelvekhez használjuk, melyeknél nincs szükség nagy komplexitásra. Elengedhetetlen elvárás a flexibilitás is, mivel könnyen előfordulhat, hogy valamilyen egyedi megközelítést akarunk használni a metamodellünkben. A harmadik feltétel pedig, hogy– az UML vizuális nyelvével szemben – az eszköz alapvetően szöveges legyen: ne kelljen ábrákat rajzolni ahhoz, hogy a rendszerbe adatokat rögzítsünk.

A 2006-ban keletkezett és 2008 óta Eclipse-es projektként futó Xtext ezeket a feltételeket tökéletesen kielégíti. Nagy előnye, hogy ANTLR-re (Another Tool for Language Recognition) épül, melynek köszönhetően a rendszer automatikusan rendelkezésünkre bocsátja a teljes parsing és lexing támogatást – bármilyen nyelvet is írjunk. Az Xtext az EMF-fel (vagyis az Eclipse-es világban a metamodellek létrehozására használható eszközzel) integrálódik: ha a rendszerbe betöltünk egy metamodellt, abból az Xtext automatikusan el tudja készíteni a nyelvtant.

Nézzünk egy konkrét példát!

Létrehozunk egy egyszerű adatbázis-leíró nyelvet, mely táblákat és szekvenciákat tartalmaz. A tábláknak vannak oszlopai, az oszlopoknak van adattípusa, és paraméterezni lehet, hogy az oszlop kötelező (not nullable) vagy sem. Ezen túl, a táblákhoz felvehetőek idegen kulcsok is: egy tábla valamely oszlopa mutathat egy másik tábla valamely oszlopára.

‍

A metamodellhez tartozó nyelvtan ezt nagyon tömören megfogalmazza.

‍

A létrejövő nyelvtan önmagában nem ad arra lehetőséget, hogy például korlátozzuk, milyen oszlopokat szerepeltethetünk az idegen kulcskifejezésekben – emiatt elméletben itt könnyen követhetnénk el hibákat érvénytelen (pl. két teljesen másik tábla oszlopai közötti, vagy az esetünkben tiltani kívánt önmagunkra történő) hivatkozások révén. Ezek elkerülésére azt szeretnénk elérni, hogy (a legtöbb IDE-hez hasonlóan) a rendszer automatikusan felajánlja azokat az elemeket, amelyek közül az adott helyen szabályosan válogathatunk. Hasonlóképp, olyan egyszerű formai hibák esetén, mint például ha a kódban egy név kisbetűvel kezdődik, azt szeretnénk, ha a rendszer egy felugró szövegbuborékban automatikusan figyelmeztessen, hogy ez nem a megfelelő formátum. Ezekben a helyzetekben nyújtanak segítséget az Xtext scoping és validátor funkciói.

‍

‍

Hogy mi az Xtext Achilles-sarka?

Könnyű rávágni, hogy maga az Eclipse, hiszen ma már nagyon sokan nem ebben az ökoszisztémában dolgoznak, és a trendeket figyelve, valószínűleg ez a jövőben is egyre inkább így lesz majd. Egészen 2016-ig jogos is lett volna ez az aggály, ekkor azonban a Microsoft előrukkolt egy Language Server Protocol (LSP) nevű megoldással, mely lehetővé teszi, hogy a nyelvi ellenőrzés a kódolásra használt eszköztől függetlenül, attól „távol” történjen. Ha utóbbi ismeri az LSP-protokollt, akkor az Xtext-ben elkészített nyelvi szerver zökkenőmentesen tudja majd támogatni a fejlesztést, akár egyszerre többfajta IDE esetére is. Tehát hiába alakult úgy a szakma az elmúlt 6-8 évben, hogy egyre növekszik a népszerű kódoló platformok száma, időközben azt is sikerült megugrani, hogy megmaradjon a nyelvi kiterjeszthetőség lehetősége, akár webes IDE-k esetén is.

‍

‍

__________________________

* Itt pl. a fix áras projektek (és módszertanok) visszaszorulására, a (technológia-)monolitikus (és így könnyen generálhatóvá tehető) architektúrák súlyvesztésére, valamint a piaci megrendelések zömét jelentő fejlesztések jellemző műszaki kihívásait sikeresen leküzdő, jól bejáratott keretrendszerek (pl. Spring) elterjedésére érdemes gondolni.

‍