[great-users] User Interaction During Rule Execution
Gürkan Özhan
gurkanozhan at gmail.com
Fri Apr 8 00:26:22 CDT 2005
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
>
>
>
More information about the great-users
mailing list