A kétirányú modellezés (RTE, round-trip engineering) a modellvezérelt architektúrában olyan szoftverfejlesztői eszközfunkció, amely két vagy több egymással összefüggő szoftveres leíró elemet szinkronban tart. Ilyen szoftveres leíró elemek lehetnek például a forráskód, a modellek, a konfigurációs fájlok, a dokumentáció és hasonlók, melyek között a szinkronizáció történik. Kétirányú modellezésre akkor van szükség, ha ugyanazt az adatot több helyen is tároljuk, és fennáll a veszélye, hogy ezek eltérővé válnak, ha csak az egyiket módosítjuk.Tegyük fel, egy információt csupán egyetlen artefaktumban (például a forráskódban) vettek fel vagy változtattak meg, aminek következtében az hiányozni kezdett a többi artefaktumból (például a modellekből), vagy ellentmondásba került azokkal.

Áttekintés A kétirányú modellezés (RTE) szorosan kapcsolódik a hagyományos szoftverfejlesztési szakterületekhez: az előre irányuló tervezéshez (szoftver létrehozása specifikációkból), a visszafejtéshez (specifikációk létrehozása meglévő szoftverből), és az újratervezéshez (reengineering) (meglévő szoftver megértése és módosítása). Sokan tévesen úgy gondolják, hogy a kétirányú modellezés (RTE) egyszerűen csak az előre irányuló tervezés és a visszafejtés együttes meglétét jelenti. Ezzel szemben a kétirányú modellezés megkülönböztető jegye szemben az előre irányuló tervezéssel és a visszafejtéssel éppen az a képesség, hogy képes az egymással párhuzamosan alakuló, létező artefaktumokat összehangolni azáltal, hogy minden egyes artefaktumot fokozatosan (inkrementálisan) frissít, hogy az megfeleljen a többi artefaktumon eszközölt módosításoknak.Ezenkívül az előre irányuló tervezés is tekinthető a kétirányú modellezés (RTE) egy sajátos megnyilvánulásának, amelyben kizárólag a specifikáció adott, ahogyan a visszafejtés is, amikor pedig csak a szoftver létezik. Számos újratervezési folyamat is megérthető a kétirányú modellezés keretében, amikor a szoftver aktualizálása a korábban visszafejtett specifikációban eszközölt változások lekövetésére szolgál.

Típusok Különböző könyvek kétféle RTE-t írnak le: : 459 

részleges vagy egyirányú RTE: a kód és modell magasabb szintű reprezentációján végrehajtott változtatások tükröződnek az alacsonyabb szinten, de egyébként nem; az utóbbi megengedett lehet, de olyan korlátozásokkal, amelyek nem feltétlenül befolyásolják a magasabb szintű absztrakciókat teljes vagy kétirányú RTE: a változásoktól függetlenül mind a magasabb, mind az alacsonyabb szintű kód- és modellreprezentációk szinkronizálódnak, ha bármelyikük megváltozik

Automatikus szinkronizálás A kétirányú modellezés (RTE) másik fontos sajátossága, hogy automatikusan frissíti az artefaktumokat, amint automatikusan következetlenségeket észlel. Ebből a szempontból eltér az előre irányuló tervezéstől és a visszafejtéstől, melyek hagyományosan manuális, de akár automatikus módszereket is alkalmazhatnak (az artefaktumok automatikus létrehozása vagy analízise útján). Az automatikus frissítés történhet rögtön vagy lekéréses alapon. A rögtöni RTE esetében az összes kapcsolódó artefaktum haladéktalanul frissítésre kerül bármelyikük módosítását követően. A lekéréses RTE esetében az artefaktumok készítői egyidejűleg aktualizálhatják az artefaktumokat (még elosztott rendszerben is), majd egy adott időpontban választhatják az összehasonlítás futtatását a következetlenségek felismerése céljából, és dönthetnek egyesek érvényesítéséről (propagálásáról), valamint a lehetséges ütközések kezeléséről.

Iteratív szemlélet A kétirányú modellezés során a fejlesztés gyakran ismétlődő, több lépcsős folyamatként zajlik. A modell és a felülvizsgált kód szinkronizálását követően továbbra is szabadon eldönthető, mi a legjobb további munkamódszer: akár a kód további módosítása, akár a modell megváltoztatása. A szinkronizáció bármelyik irányban, tetszőleges időpontban elvégezhető, és a ciklus szükség szerint tetszőleges alkalommal megismételhető.

Szoftver Számos szoftvereszköz és kutatási prototípus támogatja ezt a kétirányú modellezési megközelítést; egy 2007-es könyv több ilyen példát is felsorol Rational Rose, a Together, az ESS-Model, a BlueJ és a Fujaba is utóbbiról ismert, hogy képes a tervezési minták azonosítására is.

Korlátozások Egy Visual Studióval foglalkozó, 2005-ben kiadott könyv példaként említi, hogy az RTE-eszközök egyik gyakori gondja, hogy a visszafejtéssel nyert modell nem egyezik meg az eredetivel, kivéve, ha az eszközöket a forráskódban hagyott, munkaigényes kódjelölésekkel támogatják. A UML viselkedési elemei különösen nagy nehézséget okoznak a kétirányú modellezési folyamatban.

Rendszerint az UML-osztálydiagramok csak részlegesen támogatottak; ámde bizonyos UML fogalmaknak, például az asszociációknak és a tartalmazási viszonynak (containment), nincs egyszerű leképezése a legtöbb programozási nyelvre, ami korlátozza a létrehozott kód felhasználhatóságát, valamint a kódelemzés és a visszafejtés pontosságát (pl. a tartalmazási viszonyt nehéz a kódban azonosítani).

A kétirányú modellezés (RTE) egy járhatóbb változata valósul meg a keretrendszer API-k (alkalmazásprogramozási felületek) esetében, melynek során az alkalmazás keretrendszer API használatát leíró modell szinkronban van az alkalmazás kódjával. Ilyen körülmények között, az API meghatározza mindazokat a helyes módokat, ahogyan a keretrendszert az alkalmazásokban használni lehet, ez pedig lehetővé teszi az API-használat precíz és hiánytalan felderítését a kódban, továbbá olyan hasznos kód megalkotását, amely helyes API-használatot implementál. Ebbe a kategóriába tartozó két jelentős RTE-megvalósítás a keretrendszer-specifikus modellező nyelvek, valamint a Spring Roo (Java).

A kétirányú modellezés kritikus fontosságú a több modell közötti, valamint a modellek és a kód közötti konzisztencia fenntartásához az Object Management Group (OMG) modellvezérelt architektúrájában (MDA). Az OMG dolgozta ki a QVT (query/view/transformation lekérdezés/nézet/transzformáció) szabványt a modellvezérelt architektúrában (MDA) megkívánt modellátalakítások kezelésére. Jelenlegi ismereteink szerint ebből a szabványból kevés megvalósítás született.

Vitatott kérdések

A kódgenerálás vitatott kérdései A modellek alapján történő kódgenerálás (előre irányuló tervezés) lényege, hogy a felhasználó absztrakt szinten modellezi a megoldásokat, melyeket adott modelladatok hordoznak, és ezt követően egy automatizált eszköz e modellekből generálja a szoftverrendszer forráskódjának részeit vagy egészét. Bizonyos eszközöknél a felhasználó elkészítheti a program forráskódjának vázlatát egy sablon segítségével, amelyben előre megadott helyőrzőket (tokeneket) a generálás során automatikusan a megfelelő kódrészekre cserél a rendszer.

Az UML-diagramokat, ha modellvezérelt fejlesztésben alkalmazzák, sokszor azért bírálják, mert nem elég részletesek, így nem tartalmaznak minden olyan információt, amit a forráskódban megtalálhatunk. Vannak fejlesztők, akik szerint „a kód maga a terv”.

Hátrányok Fennáll annak a veszélye, hogy a generált kód hamar eltér a modelltől, vagy a visszafejtett modell már nem tükrözi pontosan a kódot, illetve e két probléma egyszerre is jelentkezhet, ha többször egymás után végeznek újratervezést.

Az UML viselkedési (dinamikus) aspektusait tekintve, az olyan funkcióknak, mint az állapotdiagramok, sok programozási nyelvben nincs egyértelmű megfelelőjük. Ennek következtében a kódgeneráláskor történő átültetésük oda vezethet, hogy az általános programozási elemek (például if, switch, enum) vagy hiányoznak, vagy félreértelmeződnek. Szerkesztés és visszaimportálás esetén előfordulhat, hogy a modell különbözővé vagy hiányossá válik. Hasonló a helyzet azon kódtöredékekkel, melyeket a kódgenerálás szakaszában a tervezési minta-implementációhoz és az egyedi (felhasználóspecifikus) logikához alkalmaznak: egymásba ágyazódva nehézkes lehet a visszafejtésük.

További általános problémaként említhető a fejlett modellező eszközök hiánya, melyek tudásban felvehetnék a versenyt a modern IDE-k funkcionalitásával (pl. tesztelés, hibakeresés, navigáció terén) általános és domain programozási nyelvekhez.

Szoftverfejlesztési példák Valószínűleg a kétirányú modellezés leggyakoribb típusa az UML (Unified Modeling Language) és a hozzájuk tartozó forráskód, valamint az adatmodellezésben alkalmazott ER-diagramok és az adatbázismodell közötti szinkronizáció.

Az UML-re épülő kétirányú modellezés három alapvető fejlesztői eszközt igényel:

Forráskódszerkesztő UML-szerkesztő az attribútumok és metódusok kezeléséhez Az UML-struktúra vizuális megjelenítése

Jegyzetek

Fordítás

Kategória:Szoftverfejlesztés