<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Sziasztok!<br>
<br>
Nem a diagramokból generáljuk a kódot, hanem a modellből. A
diagramok csak pluszban generált "képek", vagy Papyrusban, vagy
Siriusban, vagy UML Designerben, vagy SVG-ben vagy... Tehát a
szövegből keletkezik a modell, és mellé -- csak a user számára --
diagramok.<br>
<br>
A modellvégrehajtás számára alapvetően 2 módszert látok:<br>
<br>
(1) A modellből generált Java kód, ahogyan most is csináljuk. Ahogy
Boldi alább írta, ebben az esetben nem sokat változik a projektünk.
Sőt, még az inkrementalitás is megmarad, csak a modellt már nem a
Papyrus fogja változtatni, hanem egy szöveges editor (szintén
inkrementálisan).<br>
<br>
(2) A másik megoldás, ha maga a szöveges modell-leírás
végrehajtható. Ezt a filozófiát követi a txtUML. Ezen belül további
két lehetőségről tudok, mindegyikkel kísérletezünk abban a
projektben:<br>
(2/a) Beágyazás létező programozási nyelvbe, pl. Javába. (Ezt
hívjuk a txtUML projektben JtxtUML-nek.) Ekkor a futtatást és a
debuggolást a standard Java keretrendszer végzi, kiegészítve
modell-specifikus dolgokkal, pl. state machine animációval.<br>
(2/b) Xtext + Xbase segítségével egy saját szintaxisú nyelvet
létrehozni, és a keretrendszer által biztosított API segítségével
leképezni a szintén a keretrendszer által biztosított Java modellre.
A háttérben ekkor is Java program fog futni, de a debug
(breakpoint-ok, highlight stb.) a saját szintaxisú fájlon történik.
(Ezt hívjuk XtxtUML-nek.)<br>
(A 2/b eset kombinálható a 2/a-val, ha a saját szintaxis leképezése
éppen a 2/a-ban adott Java API-t használja. Ekkor Java-s és saját
szintaxisú szöveges UI is rendelkezésre áll, de a végrehajtó logika
csak egyszer van implementálva.)<br>
A (2) alatti scenáriók jelentősebb hatással lennének a jelenlegi
Model Executor projektre. Ebben az esetben a mostanihoz hasonló
modell --> Java leképezés első körben nem szükséges. Hosszabb
távon azonban újra szükség lehet rá, abban az esetben, más
eszközökkel (Papyrus, UML Designer stb.) editált modelleket
szeretnénk futtatni, vagy akár "round-trip-editing"-et
megvalósítani.<br>
<br>
Végül szeretném megjegyezni, hogy nincs ericssonos döntés ezzek
kapcsolatban. Akár az is lehet, hogy továbbra is a Papyrus lesz a
preferált UI.<br>
Én személyesen a (2/a) + (2/B) kombinációban hiszek, ahol a Java UI
a nagyon kevés és stabil függősége miatt fallback megoldásként is
szolgálhat.<br>
<br>
Uff! :-)<br>
<br>
Gergő<br>
<br>
<div class="moz-cite-prefix">On 08/26/2015 10:30 AM, Boldizsár
Németh wrote:<br>
</div>
<blockquote cite="mid:55DD7934.9060401@caesar.elte.hu" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Sziasztok!<br>
<br>
Ha a read-only diagrammokból továbbgenerálunk kódot, az azt
jelenti, hogy nem kell sok mindent változtatni. Tehát az alább
leírt célok/feature-ök reálisak lehetnek.<br>
<br>
Egyedül az inkrementalitást bukjuk ebben az esetben, mert minden
modell-t újra föl kell olvasni amikor megváltozott. Ezt mondjuk
kétféleképp lehet kezelni:<br>
A) A txtUML tud kicsi modelleket generálni (mondjuk minden osztály
számára külön modell), amik egymást importálják. Ezeket mindig
frissen be lehet tölteni, amikor megváltozik (mert megváltozik a
forrásául szolgáló txtUML kód).<br>
B) A txtUML a forrás megváltozásakor képes a memóriában tartott
UML modellt utánahúzni. Ekkor ugyanúgy kapnánk értesítéseket a
változásról, mint most.<br>
<br>
Mit gondoltok, szerintetek ez járható út? Voltak már ilyen
ötletek/kísérletek?<br>
<br>
Boldi<br>
<br>
<div class="moz-cite-prefix">On 2015.08.26. 8:25, Dévai Gergely
wrote:<br>
</div>
<blockquote
cite="mid:98b9fm4i1bjndavvqp9u6v7k.1440569244005@email.android.com"
type="cite">
<p dir="ltr">Sziasztok!</p>
<p dir="ltr">Szeptember végén lesz egy olyan release, amit
Ericssonon belül már meghirdetnek majd. Ezért a szeptemberben
az osztálymodellezés minél teljesebb körű támogatása,
stabilitás, dokumentáció lesz fókuszban. </p>
<p dir="ltr">Utána logikusan a kapszulák következnek, DE ezt
alapvetően az határozza meg, milyen döntés születik az
editorral kapcsolatban. Fontos észrevenni, hogy hiába lesz az
executor használható, a teljes toolchain használhatatlan a
Papyrus jelen állapotával, nem is beszélve a model compare
& merge UML szintű megvalósításáról. Az egyedül járható
útnak a szöveges modellezés tűnik, generált, read-only
diagramokkal. Ezt a döntést viszont még nem hozta meg az
Ericsson. Ennek a döntésnek próbálunk elébe menni a sok
txtUML-es aktivitással. </p>
<p dir="ltr">Üdv, <br>
Gergő </p>
<p dir="ltr">---- Boldizsár Németh írta ----</p>
<p dir="ltr">> Szia!
<br>
> <br>
> Nézegettem a 2015-ös plan-t. <br>
> (<a moz-do-not-send="true"
href="https://plc.inf.elte.hu/modelinterpreter/trac/wiki/Plan2015%29%0D">https://plc.inf.elte.hu/modelinterpreter/trac/wiki/Plan2015)
</a>;<br>
> Az egyik megjegyzésem, hogy ez októberben véget ér.
<br>
> <br>
> Más dolgok:
<br>
> - A szeptemberi-októberi feladatok egyemberesnek tűnnek
(alf hekkelés).
<br>
> <br>
> Emellett lehetne még:
<br>
> - Magasabb szintű osztálymodellezés (komponensek)
<br>
> - DataType, Enum support
<br>
> - Variables view: asszociációk mentén való haladás
<br>
> - A variables view-ban kijelölt stateful class-ra
átugrunk a debug <br>
> view-ban
<br>
> - Debug view filterezése class-ra
<br>
> <br>
> (Ezzel a két utóbbi dologgal szerintem javulna a debug
view-ben az <br>
> instance-ok navigálhatósága)
<br>
> <br>
> A later-ből a Variable View lényegében meg van oldva.
<br>
> A Breakpoint view-t adja alánk a Moka.
<br>
> Stack Frame line-okra akkor fog menni, ha már a ralf UI
része úgy áll <br>
> (tudunk benne highlight-olni).
<br>
> Expression view-t nem szeretnénk addig csinálni, amíg a
ralf nem fix.
<br>
> <br>
> Mindezt összevetve pedig szerintem év végén vagy jövő év
elején már <br>
> lehetne egy olyan pöpec demót csinálni, amivel el lehet
menni cégekhez.
<br>
> <br>
> Boldi</p>
<br>
<br>
---- Boldizsár Németh írta ----<br>
<br>
Szia!<br>
<br>
Nézegettem a <a moz-do-not-send="true" href="tel:2015">2015</a>-ös
plan-t. <br>
(<a moz-do-not-send="true"
href="https://plc.inf.elte.hu/modelinterpreter/trac/wiki/Plan2015">https://plc.inf.elte.hu/modelinterpreter/trac/wiki/Plan2015</a>)<br>
Az egyik megjegyzésem, hogy ez októberben véget ér.<br>
<br>
Más dolgok:<br>
- A szeptemberi-októberi feladatok egyemberesnek tűnnek (alf
hekkelés).<br>
<br>
Emellett lehetne még:<br>
- Magasabb szintű osztálymodellezés (komponensek)<br>
- DataType, Enum support<br>
- Variables view: asszociációk mentén való haladás<br>
- A variables view-ban kijelölt stateful class-ra átugrunk a
debug <br>
view-ban<br>
- Debug view filterezése class-ra<br>
<br>
(Ezzel a két utóbbi dologgal szerintem javulna a debug view-ben
az <br>
instance-ok navigálhatósága)<br>
<br>
A later-ből a Variable View lényegében meg van oldva.<br>
A Breakpoint view-t adja alánk a Moka.<br>
Stack Frame line-okra akkor fog menni, ha már a ralf UI része
úgy áll <br>
(tudunk benne highlight-olni).<br>
Expression view-t nem szeretnénk addig csinálni, amíg a ralf nem
fix.<br>
<br>
Mindezt összevetve pedig szerintem év végén vagy jövő év elején
már <br>
lehetne egy olyan pöpec demót csinálni, amivel el lehet menni
cégekhez.<br>
<br>
Boldi<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Modelinterpreter mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Modelinterpreter@plc.inf.elte.hu">Modelinterpreter@plc.inf.elte.hu</a>
<a class="moz-txt-link-freetext" href="https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter">https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter</a>
</pre>
</blockquote>
<br>
</body>
</html>