[Modelinterpreter] EXE cikk javaslatok

[Gergely Dévai]

Sziasztok!

> Arról egy szó sem esik a cikkben, hogy a trace-ek segítségével a külső 
> komponensek üzenetei is rögzítésre kerülnek. Ezt szerintem meg lehetne 
> említeni, hogy nem csak a randomizáció miatt van.

Ez olyan téma, ami interpretálás esetén is felmerül, ezért nem 
elsődleges fontosságú ebben a cikkben. De ha belefér, beleírható 
valahova, ahová odaillik.

> " However, UML models are usually non-deterministic by nature." => 
> However, there is no accepted semantics for the execution of an UML 
> model that is completely deterministic.

Erre írtam át: "However, UML models running with several instances of 
active classes can be non-deterministic."

> "A deterministic model simulator hides this, and execute only one 
> execution path of the many possible" => A deterministic model 
> simulator chooses only one execution path of the many possible.

Beleírva.

> "A better approch is to keep the execution non-deterministic (or even 
> randomize it intentionally), " => A better approach is to choose 
> randomly from the possible pathes,

Beleírva, de pathes ==> paths.

> "The results make it clear that the requirement about high runtime 
> performance leads to the code generation solution." - Ezt nem az adott 
> fejezet végére kellene tenni? Kicsit korai az eredményekről beszélni 
> az introduction-ben.

Valahogy be kell vezetni, hogy miért hasonlítjuk össze egyáltalán a 
kódgenerálós végrehajtást a modellfordítással. A későbbi eredményekre 
utalás egyfajta motiváció. Ha zavarónak érztek, át lehet írni valami 
ilyesmire:
"This paper analyses how model simulation can be realized via code 
generation. In such a case, a natural question arises: ..."

>
> "What is the difference between model execution via code generation 
> and model compilation?" - Ide írnám zárójelbe, hogy model simulation, 
> mert a felsorolásban már így van említve.

Beleírtam.

>
> "Model simulation has to be prepared to replay traces" - Talán 
> execution traces egyértelműbb lenne, így szerepelt korábban.

Ezt is.

>
> "Model compilers might have to emit" => szerintem itt a might fölösleges

Kiszedtem.

>
> Mintha duplikáció lenne itt: az első hasáb alján már szó van arról, 
> hogy milyen részei vannak a cikknek, majd ez újra kezdődik a második 
> hasáb alján. Szerintem az utóbbi helyen kellene maradnia, az előbbi 
> helyről meg eltűnnie a Section III-at leíró résznek.

Az első hasáb alján nem a cikk felépítéséről van szó, hanem bevezetjük, 
hogy miért foglalkozunk egyáltalán kódgenerálással. Lásd a korábbi 
megjegyzést.

> "but it needs improvement in the mass test execution use case" => but 
> is not sufficient for mass test execution - ez nem igaz?

Az Ericssonosok kérték, hogy fogalmazzunk óvatosabban.

> A végére egy mondat, ami összefoglalja a tapasztalatainkat? Mondjuk 
> hogy sok ilyen eszközt megvizsgáltunk, de nem volt olyan open source, 
> ami kielégítette volna a követelményeket.

Bizonytalan vagyok. Óvatosan kell fogalmazni, mert a workshop szervezői 
csinálták az fUML-t, Alf-ot és a MoliZ-t. :)

> Architecture:
>
> Az ábra jó lenne, ha nem az előző fejezetben lenne, hanem mondjuk a 
> hasáb alján.

Odébb raktam, most épp a második hasáb tetején van.

> "We realize both animation and breakpoint support using Java 
> breakpoints" -> Both animation and breakpoint support is realized 
> using Java breakpoints
>
> "we get a notification via the JDI" -> a notification is delivered 
> from the JDI
>
> "we signal this on in the frontend and wait for user action" -> the 
> user is notified and the runtime waits for user action
>
> " we highlight the corresponding state or transition" -> The 
> corresponding state or transition is highlighted

Ezeket mind javítottam az első kivételével. A "we" a legelső mondatban 
jobban kifejezi, hogy ez a mi szándékos design döntésünk. A többi dolog, 
ami ebből következik, az pedig passzívban van. (Bár állítólag a sok 
passzív mondat segíti az olvasókat, hogy elaludjanak a cikk fölött. :) )

Gergő