[great-users] User Interaction During Rule Execution

[Attila Vizhanyo]

Dear Gurkan:

GReAT offers both sequenced and parallel rule execution semantics.
Semantics of the parallel execution really means undetermenistic, that is, you are supposed to use it, when the execution order of your rules doesn't matter.
If you want to apply different rules for the same pattern, try to come up with a good guard condition, and create test/case constructs to check for the validity for those condition. The semantics of the test/case constructs correspond to conditional execution statements in general purpose programming languages. The condition expressions can evaluate both static and dynamic data, that changes during run-time. 
We do not support user interaction facilities in our tools currently, and there is neither any plan to do this.
I think you should be able to get the effect, if you implemented the user interface in a library, and use the library from AttributeMapping code, and depending on the user input you could modify model data. Later you could check the value of the data in a guard condition, and use the Test/Case constructs to branch the execution flow.

>    Another scenario is that, there may be more than one 
> pattern matches for a given source input, and that only one 
> of the matches must be considered and the rest must be 
> ignored. Here, againg the user may provide the decision, so 
> that only one of the guard expressions return true and all 
> the others return false.
Each rule (red rectangle) has an attribute called "For All?", which is true by default.
If you set this attribute false, the pattern matcher will stop after the first match for each packet.
However, the pattern matcher finds the matches in a non-determenistic order, which might be a problem depending on your use-case scenario.

HTH,
Attila


> -----Original Message-----
> From: Gürkan Özhan [mailto:gurkanozhan at gmail.com] 
> Sent: Thursday, April 07, 2005 15:26
> To: great-users
> Subject: [great-users] User Interaction During Rule Execution
> 
> 
> Attila, Adi,
>   Thank you both. The information you've provided did really help us.
>   And I am looking forward ro seeing the next GReAT release 
> with the global namespace facility ;-)
> 
>   By the way, I have another question: Is there a mechanism 
> to allow user interaction during rule executions in a way 
> affecting the choice of the next rule to execute? What I try 
> to mention is that the world is not always deterministic, we 
> may not be able to determine the sequence of productions at 
> rule definition time. This may especially be the case when we 
> want to construct a more detailed design (PSM) from a more 
> abstract/conceptual design (PIM) using GReAT transformations.
>     There may be a rule where there can be more than one 
> possible target model sub-graph production schemas for a 
> given source pattern match. This is possibly an excellent 
> place where the user (designer) is asked to make a selection 
> among the available alternatives. (The user may well be 
> provided with a context reflecting a snapshot of the state so 
> far, to aid in making a best fit decision).
>    Another scenario is that, there may be more than one 
> pattern matches for a given source input, and that only one 
> of the matches must be considered and the rest must be 
> ignored. Here, againg the user may provide the decision, so 
> that only one of the guard expressions return true and all 
> the others return false.
>    
>   If there is no such facility yet (I believe there is not), 
> is there any future consideration to implement this user 
> interaction concept? Alternatively, do you think it is  
> possible to write a plugin/add-on to GReAT to provide it in a 
> simpler way?
> 
>    Take care,
> 
> Gürkan Özhan
> 
> 
> On Apr 5, 2005 12:58 AM, Aditya Agrawal <aagrawa at us.ibm.com> wrote:
> > 
> > Until global namespaces are available you can use temporary 
> > associations to get the same effect and this feature is well tested 
> > and supported in GReAT already.
> > 
> > What you should do is the following:
> > 
> > 1. Create a new package called CrossLinks (the name doesn't really 
> > matter).
> > 2. In the package create a class diagram called 
> myTemporaryAssociaitons. 
> > 3. In the myTemporaryAssociaitons  class diagram drag a 
> reference of the
> > SrcPart class from the SrcMeta package. (ctrl+shift drag or 
> copy and right
> > click paste as reference) 
> > 4. Do the same for TgtTypeSystem and TgtDataStore. 
> > 5. create new simple association types in between them as 
> you need. In your
> > case there will be one from SrcPart to TgtTypeSystem (called say
> > srcPart2TypeSystem) and another from SrcPart to 
> TgtDataStore called say
> > (called say srcPart2DataStore). Please remember to change 
> the role name so
> > that they are unique. 
> > 
> > 6. Now these new association types that you have defined 
> can be used 
> > in the transformations. They are temporary and will not surface in 
> > your output.
> > 
> > 7. In the initialize transformation where you find the SrcPart of 
> > interest and create a new DataStore,  you should also create a new 
> > association of type srcPart2DataStore. Now you don't need to pass 
> > along the DataStore as it can be retrieved from the SrcPart 
> by finding 
> > the srcPart2DataStore association from it in the subsequent rule.
> > 
> > 8. Do the same in the rule where you create the TypeSystem 
> associated 
> > with the part.
> > 
> > For examples on how these temporary cross associations are 
> used please 
> > refer to the StateChart example. In the example the 
> CrossLink package 
> > contains the temporary associations and these are used 
> throughout the 
> > transformations.
> > 
> > I hope this helps.
> > 
> > Thanks,
> > Adi 
> > 
> > 
> > -----------------------------------
> > Aditya Agrawal
> > Researcher
> > IBM T. J. Watson
> > mailto:aagrawa at us.ibm.com
> > +1 (914) 784-6068 (TL 863)
> > 
> > 
> > great-users-bounces at list.isis.vanderbilt.edu wrote on 04/04/2005 
> > 05:40:18 PM:
> > 
> > 
> > > Dear Gurkan,
> > > 
> > > People often get confused with the packet passing semantics in 
> > > GReAT. The rule of thumb is, that all objects that a rule 
> receives 
> > > via its input ports, must be supplied by one rule. Say 
> you have rule 
> > > R1 with input ports I1, I2, and you want R0 to suppy 
> packets of R1. 
> > > Then R0 must supply both I1 and I2, and there is no way 
> around this.
> > > The constraint is strict because of the problems you have been 
> > > groping about: e.g. how to match up the objects from two 
> different 
> > > rules, how to form the packets.
> > > This is not trivial, mainly because the order of packets 
> produced by
> > > a rule is not deterministic.
> > > 
> > > Howevere there is panacea for your problems. There is a 
> new feature
> > > in the GReAT language, which we called Global namespace.
> > > You can create a designated UML package model, and create 
> classes in
> > > it just like for any ordinary UML class diagram.
> > > The root class of such a package (i.e. the class which is not 
> > > contained in any other classes) automatically becomes accessible 
> > > inside any rule of your transformation.
> > > We created this feature for exactly the reason of getting rid of 
> > > passing excess objects through a set of rules.
> > > 
> > > This feature is ready, but there has been no public 
> release yet, and 
> > > we are still adding many new language features to GReAT. 
> If you're 
> > > willing to use a possibly less reliable and robust tool, we can 
> > > provide you with an internal GReAT release which contains this 
> > > feature. Let me know, what would you like to do.
> > > 
> > > Thanks,
> > > Attila
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Gürkan Özhan [mailto:gurkanozhan at gmail.com]
> > > > Sent: Monday, April 04, 2005 16:07
> > > > To: great-users
> > > > Subject: [great-users] Serial vs Parallel execution
> > > > 
> > > > 
> > > > I have provided a simplified version of my exercise in the
> > > > attachment. The versions of GME and GReAT are the latest 
> > > > releases, namely, version 4.11.10 for GME and version 1.3.3 
> > > > for GReAT ( and UDM version is 2.21).
> > > > 
> > > > I am having difficulting in writing parallel transformation
> > > > definitions. The problem is, I need to start two parallel 
> > > > branches, construct them independently in their own branches, 
> > > > but then need to use some parts from both branches in a 
> > > > further rule. I use a block to function as a synchronizer for 
> > > > the parallel branches, so that inputs from both branches are 
> > > > available for the rule following the block. Unfortunately I 
> > > > could not succeed in achieving this. The scenario only works 
> > > > as expected if I carry all the references serially through a 
> > > > single branch, hence loosing space efficiency and introducing 
> > > > unnecessary and confusing complexity.
> > > > 
> > > > I have provided three start rules in the configuration. Of
> > > > these three, only StartSerial block works successfully, while 
> > > > StartMoreParallel and StartParallel do not. Details are below:
> > > > 
> > > > (This is the point where the Initialize block ends in a debug
> > > > session. I expect the execution of the next rule, but it does 
> > > > not execute.)
> > > > 
> > > > Start Rule Name: StartMoreParallel
> > > > 
> > > > Snapshot of Debug Step 9 (end of block Initialize):
> > > > In Variables
> > > >    Tgt_RF
> > > >       has no value
> > > >    Src_Rf 
> > > >       has no value
> > > > Out Variables
> > > >    S_T1_Part
> > > >       NewSrcMain.PartA
> > > >       NewSrcMain.PartB
> > > >    S_T2_Part
> > > >       NewSrcMain.PartC
> > > >       NewSrcMain.PartD
> > > >    T_DataStore
> > > >       TgtMain.TgtDataStore
> > > >    TypeSystem
> > > >       TgtMain.TgtTypeSystem
> > > >       
> > > > At Debug Step 4 (CreateTgtType1Data(dataStore:I,
> > Part:I,
> > > > typeSystem:I, type1:P, type1Ref:P, tgtPart1:P)
> > > >    No match and skip :-(
> > > > At Debug Step 3 (CreateTgtType2Data(dataStore:I,
> > Part:I,
> > > > typeSystem:I, type2:P, type2Ref:P, tgtPart2:P)
> > > >    No match and skip :-(
> > > >    
> > > > Eventhough the input ports are provided with matching data,
> > > > neither CreateTgtType1Data, nor CreateTgtType2Data match and 
> > > > execute. I thought that a block stacks all of its packets at 
> > > > its output ports until the last packet is produced, and  only 
> > > > after that,the next rule following the block starts.
> > > > 
> > > > Also, isn't there a mechaism to make a port repeat its value
> > > > n times? Let me explain this with the above example: In our 
> > > > case S_T1_Part has 2 packets, whereas, T_DataStore and 
> > > > TypeSystem have 1 packet. Therefore T_DataStore and 
> > > > TypeSystem should repeat their data as many times as 
> > > > S_T1_Part's packet count(in this case 2 times)
> > > > 
> > > > A similar scenario is with start block StartParallel. Here we
> > > > are stuck after the rule CreateTgtDataStoreAndData. The 
> > > > following rules CreateTgtType1Data and CreateTgtType2Data 
> > > > just don't execute.
> > > > 
> > > > The transformation only succeeds with the start block
> > > > StartSerial. In this scenario we carry all the necessary 
> > > > references serially through a single path till the end of 
> > > > CreateTgtDataStoreAndData block. However, this sort of 
> > > > implementation results in unnecessary carrying of packets 
> > > > through previous rules that will be required in some other 
> > > > rule that is farther away. This is really a space efficiency 
> > > > killer and complicates understanding of the rules in 
> > > > scenarios where the target model is huge and has modular 
> > > > subparts that can be constructed independently, but pieces of 
> > > > those subparts are used as inputs in some rule that is 
> > > > further away in the rule execution sequence.
> > > > 
> > > > Thanks in advance.
> > > > 
> > > > Gürkan Özhan
> > > > 
> > > _______________________________________________
> > > great-users mailing list great-users at list.isis.vanderbilt.edu
> > >
> > http://list.isis.vanderbilt.edu/mailman/listinfo/great-users
> > 
> > _______________________________________________
> > great-users mailing list
> > great-users at list.isis.vanderbilt.edu
> > http://list.isis.vanderbilt.edu/mailman/listinfo/great-users
> > 
> > 
> >
> _______________________________________________
> great-users mailing list
> great-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/great-users
>