<html>Sziasztok!<br /><br />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.<br />Az indokok a kovetkezok:<br />- Az ericssonosok komolyan gondoljak, hogy a txtUML resze lesz egy oktoberi stockholmi demonak. Az animacio sokat tudna dobni ezen a demon.<br />- 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.<br />- 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).<br /><br />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.<br /><br />Mind a fenti architekturalis gondolatokhoz, mind a technikai reszletekhez szivesen fogadok otleteket, javaslatokat!<br /><br />Koszi,<br />Gergo<br /> </html>