MetaCase Homepage
Forum Home Forum Home > > MetaEdit+
  New Posts New Posts RSS Feed - Writing generators for graphs with decompositions
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Writing generators for graphs with decompositions

 Post Reply Post Reply Page  <12
Author
Message
iceman View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Jun.2011
Points: 32
Post Options Post Options   Thanks (0) Thanks(0)   Quote iceman Quote  Post ReplyReply Direct Link To This Post Posted: 20.Jul.2011 at 06:07
Thanks for the suggestions.

Adding events for transitions would be different if I do it in the Watch example way compared to what jpt suggested. In the Watch example,  the Event role is connected to an object(button). However, in my case I have many different kinds of events which lead to a transition. Events from UI components and async events(10-15 kinds of). The events from UI components(only buttons currently) just happens to be present in another graph-"Screen Editor". Do I have to add a separate object for each class of events and associate then in the "Transition" relationship? Once I have defined the buttons in the Screen Editor graph, I want them to be available while I use the State editor graph to define the events for transitions.

I could not find the error log file in the working directory. Is it in the c:\program Files directory?
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 643
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 20.Jul.2011 at 13:38

The underlying need is for a transition to have the information of which event(s) trigger it. You have events coming from Screen Components and from Async sources. Juha-Pekka (jpt) suggested a property in the transition which would be a direct reference to a Screen Component, which would have been specified earlier in the subgraph of the source State.

Now we have a bit more information, we see that's maybe not enough, since there needs to be a way for transitions to be caused by Async events as well as Screen Components.
 
One way would be my suggestion, to place the event trigger as an object directly in the diagram and connect from the Transition to it with an Event role. The event trigger objects could be Screen Components and the various Async events. I'm guessing that at least some Async events need more information, e.g. a Timeout might need the modeler to supply its duration. [Actually I see you specify the timeout duration in the state itself, but maybe some other async events need extra info themselves.] In that case it makes sense to have a separate object type for each. Perhaps you could have an abstract object type "_Async Event", with a subtype "Timeout" with a duration property, and another subtype "Simple Async Event" with a Radio Button or Fixed List property "Event Type", listing all the non-parameterizable async events (e.g. "Power Down", "Power Up").
 
You'd thus add some object types to your graph type (Screen Component, Timeout, Simple Async Event), and in the binding for Transition you'd add an Event role that can connect to Screen Component or _Async Event.
 
An alternative would be to have a different relationship type for some of the async events, e.g. a Timeout relationship that has a property "duration" and connects the source state in a "Timeout From" role to the target state in a "Timeout To" role. You could then enforce only one Timeout transition per state by a Connectivity Constraint on the "Timeout From" role.
 
In your XML, what is the semantics of a button event action's state parameter, in particular its <name> and <value>? They sound like they specify the state to go to when that action occurs, but the name is always 'n' and the values don't match any state names in the example XML.
 
The working directory is specified by the "Start in" value of the MetaEdit+ shortcut, by default My Documents\MetaEdit+ 4.5.
Back to Top
iceman View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Jun.2011
Points: 32
Post Options Post Options   Thanks (0) Thanks(0)   Quote iceman Quote  Post ReplyReply Direct Link To This Post Posted: 22.Jul.2011 at 08:24
The semantics of a button event is the following: the value specifies the state to which the transition occurs. For example,

 <button label="SKIP" width="200" height="200" x="412" y="500" textsize="40" icon="none" adjtext="30">
                <event name="clicked">
                    <action preconditions="no" name="transition">
                        <parameter>
                            <type>state</type>
                            <name>n</name>
                            <value>4192</value>
                        </parameter>
                    </action>
                </event>
        </button>
        
There are timeout events, for example:
<event name="TimeOut">
            <action preconditions="no" name="transition">
                <parameter>
                    <type>state</type>
                    <name>n</name>
                    <value>4172</value>
                </parameter>
            </action>
        </event>
There are async events which also cause transition, for example :
      <event name="PulseCoreStatus" arg1="F1">
        <action preconditions="no" name="transition">
          <parameter>
            <type>state</type>
            <name>n</name>
            <value>4181</value>
          </parameter>
        </action>
      </event>       
In the current design there are also background actions(don't know what these are called in Statechart terminology but probably similar to the concept of onEnter) which are parametrized, for example:
    <backgroundactions>
      <rocosmessage name="FDSessionStart" type="EVENT_MESSAGE" senderid="RCP" receiverid="NA">
        <parameter type="unsigned int" name="id" vartype="text">1</parameter>
        </rocosmessage>
    </backgroundactions>

A complete state example is here : http://pastebin.com/DnMK6rmR

I'm not clear on how to write the generator for the visual syntax the modeler is going to describe. My current schema seems quite complex for what I'm trying to do after all your suggestions.    I will be very interested if you have some refactoring suggestions for my xml schema.

This is my current simple state machine description which doesn't include clustering states,orthogonality of states or refinement of states. I'm trying to scale up my design ( and the xml schema) to avoid exponential blow-up of states using Harel statechart visual notation. For meeting my requirements, i also need to extend the formal semantics for statechart as described in Harel's paper (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.131.7628&rep=rep1&type=pdf). Essentially w3c scxml doesn't yet have a domain specific requirement that I have and is good for describing a generic statechart.
Reading through the original paper, I found that your watch example is similar to the Citizen watch example Harel described in his work.
The major difference to Harel's statechart solution in my requirement is that events carry parameters and I need a dispatching mechanism for events and handling of actions.


Exploring on this front, I found that Adobe's mxml(help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7fae.html) is very close to reusing widgets in states to avoid state explosion. So, the semantics is something like if you define an EXIT button, you can includeIn s1,s2,s3. But in my state design, EXIT button and the associated event has to be mentioned in every state definition where its required. However, mxml doesn't allow me to specify the other async events and actions which are not associated with UI elements in their schema. That is done in actionscript3 code.


Edited by iceman - 22.Jul.2011 at 13:53
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 643
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 22.Jul.2011 at 14:18
Let's step back for a second and look at the wider picture. You have states, transitions and events. You have screens with buttons and texts. Some events are caused by buttons, some are asynchronous. You want a graphical language for the state machine part, and another for the screen part. And you are making an XML schema.
 
The last part interests me: why do you want to make an XML schema? Essentially you're trying to metamodel the same domain again, but with a less powerful set of concepts than GOPPRR offers. Particularly if you want to reuse or reference things, as you do, XML is no fun. Your underlying domain is a set of strongly interwoven graphs, and XML is only really intended to represent a tree, which is a much simpler world.
 
Are you planning on only generating XML from MetaEdit+? And will the XML then 1) be read by something else that will generate code, 2) be read at start-up by the system to fill the data structures of a generic state machine implementation, or 3) be read on the fly by a running state machine implementation for each transition? For 1), I'd simply write the generator in MERL - it'll be a lot easier. For 2) I'd have MERL generate either the code to initialize the data structures, or the data structures in some format better suited to graphs rather than trees. For 3) I'd probably do the same as for 2).
 
Who will use the resulting language? Is this for a known group of individuals in a particular project, e.g. your team in a company, or are you trying to create something that would be good for anybody wanting to model discrete responsive embedded systems? In either case I'm sure you want to give yourself the best chance of succeeding, so you might want to take a look at our article Worst Practices for Domain-Specific Modeling, which analysed 76 cases of DSM to see what are the traps that DSM language builders tend to fall into.
 
You might want to consider making your screen buttons send an event, rather than directly specifying the state to jump to. That's vital if you want to reuse screens or buttons, but of course adds an extra indirection if you never reuse them.
 
<state no="1">
  <button x=...>
    <onClick event="startCounter">
  </button>
  ...
  <expectedevents>
    <event name="startCounter">
      <precondition/>
      <transitionAction/>
      <transition toState="2"/>
    </event>
 
Currently, each state owns its transitions. You may want to consider whether the same transition can be triggered by the same events from multiple states. If so it might be nice to draw the transition just once, and then add an extra From role to the other source state. In that case you'd also want to separate out your transitions from a state's expectedevents to the top level of XML. You could also have multiple events triggering the same transition:
 
<state no="1"...>
<state no="2"...>
<transition>
  <fromState no="1"/>
  <event name="startCounter"/>
  <event name="someAsyncEvent"/>
  <precondition/>
  <transitionAction/>
  <toState no="2"/>
</transition>
 
As with all these design decisions, you have to weigh how often it would be useful, how much it would save then, and how easy it is to learn (language designers always underestimate this Smile).
Back to Top
iceman View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Jun.2011
Points: 32
Post Options Post Options   Thanks (0) Thanks(0)   Quote iceman Quote  Post ReplyReply Direct Link To This Post Posted: 23.Jul.2011 at 14:11
Originally posted by stevek stevek wrote:

Let's step back for a second and look at the wider picture. You have states, transitions and events. You have screens with buttons and texts. Some events are caused by buttons, some are asynchronous. You want a graphical language for the state machine part, and another for the screen part. And you are making an XML schema.


Thanks indeed for summarizing. Thats exactly what I want, but the meta-representation is internal and not necessarily xml
 
Originally posted by stevek stevek wrote:


The last part interests me: why do you want to make an XML schema?

Essentially, I wanted to start with something defined as simple FSMs in xml and define my dsvl(isn't complete yet as there are new design challenges in modeling as FSM now). As the problem scaled up to new requirements, I realized simple FSMs are not that expressive for the new requirements and I would run into similar problems described in Harel's paper. I had a look at different examples in Metaedit+ and decided to learn GOPPRR through solving my problem. This would help in two ways: improve upon my design and also allow me undertake comparison on how easy/difficult is to do the same with other tools. I appreciate your and Juha-Pekka's participation in enabling me to do this.

 
Originally posted by stevek stevek wrote:

Are you planning on only generating XML from MetaEdit+?

The xml will be read on-the-fly by a xml parser which then makes service calls. the xml is created to represent screens and the transition logic and help developers handle dynamic software specs where the client wants to change the sequence of the states(the events and the transitions), or add new ones. 
 
 
Originally posted by stevek stevek wrote:

Who will use the resulting language?

My target audience is end users who won't care if the internal representation is xml/json or any other meta-language.
The plan  is to allow end users(non-programmers) do it, without getting developers involved in changing xml by giving the end users a graphical tool.

 
Originally posted by stevek stevek wrote:


In either case I'm sure you want to give yourself the best chance of succeeding, so you might want to take a look at our article Worst Practices for Domain-Specific Modeling, which analysed 76 cases of DSM to see what are the traps that DSM language builders tend to fall into.
 


Thanks for the paper reference


Edited by iceman - 23.Jul.2011 at 14:24
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 643
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 25.Jul.2011 at 11:52
OK, many thanks for explaining the background - it really helps us understand the various forces that will mould your solution. Hopefully our suggestions will help you towards a good language for your users, and a simpler XML schema, where the interface between screens and states is not so highly coupled. That in turn will make building the generator easier: you can just iterate through states, and in each state through its screen, without having to bounce back and forth between state and screen for a single state.
Back to Top
iceman View Drop Down
Major Contributor
Major Contributor
Avatar

Joined: 19.Jun.2011
Points: 32
Post Options Post Options   Thanks (0) Thanks(0)   Quote iceman Quote  Post ReplyReply Direct Link To This Post Posted: 26.Jul.2011 at 13:49
Thanks Steven,
There is a lot of information in this thread of discussion which can be used to drastically improve my design and handle higher complexity as I have pointed out, and possible solutions you have suggested. I'm planning to solve the problems step-by-step.
The first is to start with simple FSM example and generate the exact same xml (http://pastebin.com/DnMK6rmR). The domain model (and writing the generator) for that might be more complicated and not pertaining to the best practices, but it will be useful for a reference step for improvement of the model. Wondering, how to write the generator for that. I'm working on this now.

The next one is to define models according to your suggestions for multiple events triggering same transition(and to take care of state explosion) as in the last post. For that next step, what representation other than xml can be used?  

Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 643
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 26.Jul.2011 at 17:05
Because of the high coupling in the current XML schema, the difficult bit of the generator will be line 18 in your XML (http://pastebin.com/DnMK6rmR). You'll have navigated to state 4171 in the state diagram, from there to its decomposition into a screen diagram, and within that to a button. But now you want to write out the name of the target state for that button's transition, and a button doesn't contain that information. Instead you'll need to look back up at state 4171, look at its transitions, find the one that matches this button, and see which is its target state. There are two ways to do this in MERL: with the stack or with dynamic variables.
Using the stack for complex navigation
When outputting line 18, the stack initially contains the state diagram, state 4171, the screen diagram, and the button. You want to navigate from state 4171 via a From role to a Transition relationship, which would normally be simply "do ~From;2>Transition", where the ";2" means "start navigation not from the button, but from two stack levels further out, i.e. State 4171". However, since you are now in the screen diagram you'd be looking at the right object but in the wrong graph, so you'd be told State 4171 has no From roles [in this graph]. The graph used is always the most recent graph on the stack. You thus need to get the state diagram onto the stack again, by navigating to it. The easiest way is probably to iterate over the stack itself, with a where clause to only pick out the state diagram:
 
do stack where oid=oid;4
{  do ~From;3>Transition
    where :Transition Button; = :Button Name;2
   {  do ~To.State
       {  '<value>' id '</value>' newline
       }
   }
}
 
Using dynamic variables for caching complex values
The other approach is to use dynamic variables to save information earlier, while going through the state diagram, and then use it later while going through the screen diagram. MERL's variables are dynamic / associative, which means you get things like Dictionary or Hashtable behaviour for free. Basically you form the variable name on the fly, by appending the Dictionary key to the base variable name. You can have multiple levels of keys, separating them by any character - we'll use a slash /. Here's how you'd cache which state each button goes to:
 
foreach .State
{  do ~From>Transition
   {  variable 'buttonCache/' id;2 '/' id;1 '/' :Button Name; write
         do ~To.State { id }
      close
   }
}
 
Then later, in the screen diagram and in a button, you can get line 18 like this:
 
'<value>'
variable 'buttonCache/' id;3 '/' id;2 '/' :Button Name; read
'</value>'
Back to Top
 Post Reply Post Reply Page  <12

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.05
Copyright ©2001-2022 Web Wiz Ltd.

This page was generated in 0.067 seconds.