Mona Lisa, a modellek modellje

Tudsz Javaban programozni? E kérdésre nagyon sokan bólintanak, ám amikor például sales automation rendszert kell készíteni, akkor elakadnak. Mert noha pontosan tudják, mit jelent egy osztály, vagy mi az öröklődés, amikor meghallgatják a domain szakértőt arról, hogy mi az, amit a szoftvernek csinálnia kellene, mégsem értik pontosan. Ahhoz ugyanis, hogy a domain szakértő és a fejlesztő szót értsenek, szükség van egy közös, domain specifikus nyelvre (DSL), amelyen keresztül kommunikálni tudnak egymással a rendszerre vonatkozó igényekkel kapcsolatban.

A DSL-ek ahhoz kellenek, hogy az üzleti és az informatikai tudás együtt egy működő informatikai rendszert adjanak ki. Olyan nyelvekről van szó, amelyek segítségével az informatikában kevésbé járatos elemzők le tudják írni saját gondolatvilágukat, meg tudják fogalmazni a fejlesztendő szoftverrel kapcsolatos igényeiket. Egy DSL az általános célú nyelvekhez képest – mint a Python vagy a Java – sokkal szűkebb világot tud leírni, sokkal kevesebb dolgot lehet vele megfogalmazni. Ám azt annál pontosabban! A DSL-ek, amelyeket modellezési nyelveknek is nevezünk, lehetővé teszik – amennyiben a fogalomrendszerünket képesek vagyunk leírni DSL-ben –, hogy az informatikai rendszerünkből forráskódokat állítsunk elő.

‍

Mona Lisa, a modell

‍

A modell nem más, mint a valós világ egyszerűsített absztrakciója.

Egy modell nyelvét metamodellnek, a modell nyelvének megfogalmazásához szükséges nyelvet pedig meta-metamodellnek nevezzük. Ahhoz, hogy DSL metamodelleket hozzunk létre, olyan környezetekre van szükségünk, amelyet le lehet írni egy DSL nyelvvel. Ehhez pedig egy olyan absztrakciós szintre, nyelvi formára, ami képes arra, hogy megfogalmazzunk benne egy DSL-t.

Vegyünk egy példát! Egy zeneszám leírásához kell egy arra alkalmas nyelv, ilyen lehet például a hangjegyek világa és egy olyan modellezési környezet, amelyben meg tudjuk fogalmazni, hogyan néz ki egy zenemű leírása. Ha ez kész, a zenemű a valós világban lejátszható.

Festmények esetében már bonyolultabb a helyzet, hiszen nem könnyű meghatározni, mi az a metanyelv, amely leír egy képzőművészeti alkotást. Ennek ellenére ma már a mesterséges intelligencia (AI) képes arra, hogy metaszinten leírja, hogyan néz ki például egy középkori festmény, sőt ezt meg is jelenítse. Olyannyira, hogy tavaly mintegy 430 ezer dollárért árverezték el azt a mesterséges intelligencia által készített festményt, amelynek metamodellje a Mona Lisát vette alapul. Noha nem tudjuk, mi a festmény metamodellje, az AI képes volt ezt feltölteni, és ebből újra legenerálni a festményt.

Egy általános metamodellezési környezet négy szintből áll: Nulladik szinten – M0 – a valós dolgok találhatók, például egy zenemű. M1-es szinten a modell első számú képe, azaz a szoftverünk. M2-es szinten írjuk le azt, milyen képességekkel rendelkezik az M1 szinten szereplő szoftver, azaz ez a metamodellek szintje. Végül az M3-as a meta-metamodellek világa: az a nyelvi szint, amely képes arra, hogy segítségével modelleket tudjunk megfogalmazni.

Egy bizonyos meta-metamodell által meghatározott architektúra a modelling space. Ennek legfelső, M3-as metaszintjén a Meta-Object Facility (MOF) szerepel, ez az UML* szabvány szerinti réteg, amiben le lehet írni modellezési nyelveket. Az UML az M2 szinten szerepel, ide betölthetjük a saját modellünket, ami az alkalmazás futtatása alatt tartalmazni fogja azokat az entitásokat, melyeket reprezentálni szeretnénk.

‍

Nézzünk néhány modelling space-t!

‍

Ezek egymással párhuzamos, ugyanakkor azonos metaszintű leírók. Itt az M3-as szinten, azaz a MOF szintjén szerepel középen a MOF library, a jobb oldalon pedig az EBNF – ez alkalmas arra, hogy lehívja a metamodellt, abban megfogalmazza a Java programot, amiben pedig leírja, hogyan néznek ki az egyes entitásaink. A másik oldalon az RDF hasonló módon épül fel.

Ahhoz, hogy ezeket a metamodell elemeket le tudjuk írni, használni tudjuk és low coding platformokat hozzunk létre, a metaszintek közötti átjárásokat biztosítanunk kell. Ezek az átjárások teszik lehetővé azt, hogy modellkonverziók segítségével újabb modelleket állítsunk elő.

A modell-transzformáció a modell-létrehozás és -módosítás automatizált módja, amelynek eredményeképpen csökkennek a hibák és erőforrást takarítunk meg. Arról szól, hogyan lehet két metamodell között átjárást biztosítani úgy, hogy az első a problémateret írja le, a másik pedig egy konkrét informatikai megvalósítást Javaban.

‍

Miért nem alkalmas az UML arra, hogy általános szinten le tudjunk modellezni rendszereket?

‍

Ehhez először is beszéljünk a szemantikáról! A szemantika azt a működési módot írja le, ahogyan egy számítógép követi a végrehajtandó programot egy specifikus nyelven. Ahhoz, hogy megfogalmazzuk UML-ben a gondolatvilágunkat, ahhoz az UML-nek szemantikai tartalmat kellene adni. Ilyennel azonban nem rendelkezik; az UML nem végrehajtható elemsorozat, a szemantikája nem végrehajtásra, hanem modellezésre való. Ez azt jelenti, hogy absztrakciókat és különböző specifikációs technikákat hoz össze az UML, és ha szeretnénk felhasználni arra, hogy működőképes rendszert írjunk le, ahhoz az UML-nek speciális, kiterjesztett változatával kell dolgoznunk, ez pedig a FUML**.

A development platform olyan absztrakciós szint, amely egyfajta DSL-t, metamodellt próbál átadni a végfelhasználójának és mint ilyen, próbálja leszűkíteni a használatát például adatbázisok tervezésére, üzleti folyamatok tervezésére, user interface vagy más webalkalmazások tervezésére. A low coding platform már 15-20 éve jelen van az informatikában, 2014-ben aztán a Forrester ismét felemelte a témát. Korábban ezt MDA*** vagy hasonló modellezési koncepciónak nevezték, ma már elég sokan foglalkoznak ilyen típusú platformokkal – a legnagyobb játékosok az OutSysems, az Appian, és a Salesforce.

Mivel leszűkített domainspecifikus nyelvekkel, leszűkített metamodellrendszerekkel dolgoznak, ezért sokkal gyorsabban lehet létrehozni azokat az alkalmazástípusokat, amiket szeretnénk lemodellezni.

Ahhoz, hogy egy low code platformot előállítsunk, két dologra biztosan szükség van: business domainre és architektúrára.

A low coding platform a business domaint képezi le az architektúrára, a business domain által megfogalmazott modellelemeket ülteti át az architektúrára. Így az architektúra képes lesz arra, hogy az alkalmazást futtassa.

‍

Modellezés lépésről lépésre

‍

Ahhoz, hogy létrehozzunk egy modellezési platformot, több technical space-re lehet szükségünk, ilyenek az UML, az XML****, a Java és az RDF*****.

Az általunk definiált low coding platform második verziója az Ecore, amely az Eclipse világ metaobject facility rétege, az Ecore réteg M3 szintű leírása, ez alkalmas arra, hogy nyelveket definiáljunk. Az Epsilon egy metamodell-transzformációs nyelv, amely segítségével a különböző modelljeinket transzformálni tudjuk, illetve az Eclipse Siriusa alkalmas arra, hogy modell editorokat hozzunk létre.

Hogyan definiálhatunk egy domain modellt? Ehhez elsősorban létre kell hoznunk egy üzleti szótárat, ebben le tudjuk írni a koncepcióinkat, az ezek közti relációkat. Ezeket aztán az EMF/Ecore párosban fogalmazzuk meg.

A következő szinten egy grafikus modellező eszköz az Eclipse Sirius segítségével leírjuk, hogy fog kinézni maga a modell. A reprezentációban displayed elemeket, alakokat, színeket, betűtípusokat használunk a modell megfogalmazásához.

Utolsó lépésben a model driven toolok segítségével ezeket az elemeket ki lehet generálni, validálni, összehasonlítani, transzformálni.

‍

Ecore modell

‍

Egy M3-as szintű modell részlete, az a szint, amiben le tudjuk írni, hogy milyen modell elemeink léteznek M2-es szinten. Létezhet olyan, hogy Eclass, minden classunkhoz tartozhatnak supertype-ok, minden classhoz tartozhatnak attribútumok, referenciák. Egy attribútumnak adattípusai vannak, egy referenciának pedig egymásra mutató értékei lehetnek. Az Ecore metamodell leírása révén kifejezhetjük azt, hogy milyen típusú modelleket szeretnénk létrehozni.

A BlackBelt-nél a saját magunk által definiált környezet a JUDO. Ez cégünk

digitális business platformja, amely enterprise célokat szolgál és három nagy modellezést felületet fog össze: a business modelling, a humán workflow, és a document composition. Ezek azok a területek, amelyekkel a saját leírásaink felhasználásával újabb és újabb alkalmazásplatformokat tudunk létrehozni.

A JUDO első három évéből sok mindent megtanultunk.

1. A saját technical space-ünkben dolgoztunk – ezt senkinek nem ajánlanám ma már. Az adatmodell részünk könnyen definiálható, akár Pythonban könnyen leírható eszközrendszer, ugyanakkor egy metamodell viselkedését leírni nagyon nehéz. Ehhez arra van szükségünk, hogy olyan előre gyártott elemekkel tudjunk dolgozni, az Epsilonnak, Ecorenak a szintjén, amik nem állnak rendelkezésre a saját technical space-ek tekintetében.
2. A UI-t szintén nem egyszerű leírni, a modellezésére sok kísérlet van, nekünk létezik is egy UI leírónk, de ennek működése nem teljes.

Mi az, amit a továbbfejlesztett, kettes változatban szeretnénk elérni?

Van egy core generátorunk, egy modell interpreterünk és egy domain modellünk, valamint szeretnénk beépíteni a BPMN******-t futtató környezetnek. A teljes rendszerünk úgy fog kinézni, hogy egy web based modellező eszközünk lesz, ennek segítségével lehet létrehozni újabb és újabb modelleket. A modeller interfacen keresztül létre lehet hozni, le lehet generálni magukat a modellezett elemeket, és utána ezeket ki lehet publikálni valamilyen tetszőleges futtatókörnyezetekre.

Akinek modellezéssel kapcsolatos kérdése, észrevétele van, vagy a cégén belül szeretne modellező környezetet létrehozni, annak az Ecore és az Epsilon világában érdemes körülnéznie. Egy ilyen környezet létrehozása alkalmas arra, hogy az ismétlődő, sokszor végrehajtott feladatainkat meg tudjuk fogni egy metamodellezett rendszerben, majd ezt a rendszert utána újra és újra fel tudjuk használni illetve át tudjuk adni a felhasználóinknak. Akik ebben a metakörnyezetben képesek lesznek arra, hogy bizonyos modellszintű működéseket leírjanak.

...........................................................................

*UML: Unified Modeling Language, szabványos, általános célú modellező nyelv

**FUML: Foundational Unified Modeling Language; az UML azon részhalmaza, amelyre szabványos, pontos végrehajtási szemantika van

***MDA: Model-Driven Architecture; modellvezérelt achitektúra

****XML: Extensible Markup Language; kiterjeszthető jelölő nyelv

*****RDF: Resource Description Framework; erőforrás-leírási keretrendszer

******BPMN: Business Process Model and Notation; egységes folyamatábra-alapú jelölés üzleti folyamatok modellezéséhez