[Modelinterpreter] szoveges modellezes integracioja
Dévai Gergely
deva at caesar.elte.hu
Mon Aug 3 13:36:25 CEST 2015
Sziasztok!
Sokat toprengtem csutortok ota azon, hogy mi legyen a Gera Zoli altal elkezdett modularizacios/txtUML-integracios munka kovetkezo lepese. Mindenfele szempontot figyelembe veve az latszik a legkedvezobbnek, ha kiserleti jelleggel keszitunk Papyrus allapotdiagram animaciot a txtUML-hez. A debuggolas tehat alapvetoen a standard eclipse-es Java debuggolas lenne, de ezt kiegeszitenenk state machine animacioval.
Az indokok a kovetkezok:
- Az ericssonosok komolyan gondoljak, hogy a txtUML resze lesz egy oktoberi stockholmi demonak. Az animacio sokat tudna dobni ezen a demon.
- Ha a txtUML-bol generalt modellt a jelenlegi executorral kotjuk ossze, akkor megszoritjuk a debug lehetosegeket arra, amit az executor jelenleg tamogat, nem hasznaljuk ki a JDT eszkoztarat. Masreszt az igy kialakulo architektura egy vegrehajthato Java kodbol egy modellen keresztul egy masik vegrehajthato Java-t allit elo, ami eleg furcsa lenne.
- Hosszabb tavon a elkepzelheto a model executor jelenlegi Java generatoranak olyan modositasa, hogy a kimenet txtUML legyen. Ez ket dologhoz adna tamogatast egyszerre: (1) modellvegrehajtas, (2) round-trip-editing. Itt persze egy nagyon fontos kerdes a txtUML futasi ideju hatekonysaga (es annak javithatosaga).
A technikai megvalositas teren meg nincs kiforrott elkepzelesem. Valami lightweight megoldasban gondolkozom, pl. a txtUML runtime-ot kiegesziteni egy olyan funkcioval, ami (segedinformaciok alapjan) megtalalja a txtUML modellbol generalt Papyrus diagramot, es allapotvaltozasokkor kiszinezi az aktualis allapotot. Varhatoan ehhez meg Moka engine-t sem kell irni. Viszont meg kell oldani a debug target virtualis gepeben futo txtUML modell es a frontend Eclipse-ben levo diagramok kozotti (egyiranyu) kommunikaciot.
Mind a fenti architekturalis gondolatokhoz, mind a technikai reszletekhez szivesen fogadok otleteket, javaslatokat!
Koszi,
Gergo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/modelinterpreter/attachments/20150803/7c82c9e2/attachment.html>
More information about the Modelinterpreter
mailing list