<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">What you should do is the following:</font>
<br>
<br><font size=2 face="sans-serif">1. Create a new package called CrossLinks
(the name doesn't really matter).</font>
<br><font size=2 face="sans-serif">2. In the package create a class diagram
called myTemporaryAssociaitons.</font>
<br><font size=2 face="sans-serif">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)</font>
<br><font size=2 face="sans-serif">4. Do the same for TgtTypeSystem and
TgtDataStore.</font>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">8. Do the same in the rule where you
create the TypeSystem associated with the part. </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">I hope this helps.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Adi</font>
<br>
<br>
<br><font size=2 face="sans-serif">-----------------------------------<br>
Aditya Agrawal<br>
Researcher<br>
IBM T. J. Watson<br>
mailto:aagrawa@us.ibm.com<br>
+1 (914) 784-6068 (TL 863)<br>
</font>
<br>
<br><font size=2><tt>great-users-bounces@list.isis.vanderbilt.edu wrote
on 04/04/2005 05:40:18 PM:<br>
<br>
> Dear Gurkan,<br>
> <br>
> People often get confused with the packet passing semantics in GReAT.<br>
> The rule of thumb is, that all objects that a rule receives via its
<br>
> input ports, must be supplied by one rule.<br>
> Say you have rule R1 with input ports I1, I2, and you want R0 to <br>
> suppy packets of R1. Then R0 must supply both I1 and I2, and there
<br>
> is no way around this.<br>
> The constraint is strict because of the problems you have been <br>
> groping about: e.g. how to match up the objects from two different
<br>
> rules, how to form the packets.<br>
> This is not trivial, mainly because the order of packets produced
by<br>
> a rule is not deterministic.<br>
> <br>
> Howevere there is panacea for your problems. There is a new feature
<br>
> in the GReAT language, which we called Global namespace.<br>
> You can create a designated UML package model, and create classes
in<br>
> it just like for any ordinary UML class diagram.<br>
> The root class of such a package (i.e. the class which is not <br>
> contained in any other classes) automatically becomes accessible <br>
> inside any rule of your transformation.<br>
> We created this feature for exactly the reason of getting rid of <br>
> passing excess objects through a set of rules.<br>
> <br>
> This feature is ready, but there has been no public release yet, and<br>
> we are still adding many new language features to GReAT.<br>
> If you're willing to use a possibly less reliable and robust tool,
<br>
> we can provide you with an internal GReAT release which contains <br>
> this feature. <br>
> Let me know, what would you like to do.<br>
> <br>
> Thanks,<br>
> Attila<br>
> <br>
> <br>
> > -----Original Message-----<br>
> > From: Gürkan Özhan [mailto:gurkanozhan@gmail.com] <br>
> > Sent: Monday, April 04, 2005 16:07<br>
> > To: great-users<br>
> > Subject: [great-users] Serial vs Parallel execution<br>
> > <br>
> > <br>
> > I have provided a simplified version of my exercise in the <br>
> > attachment. The versions of GME and GReAT are the latest <br>
> > releases, namely, version 4.11.10 for GME and version 1.3.3 <br>
> > for GReAT ( and UDM version is 2.21).<br>
> > <br>
> > I am having difficulting in writing parallel transformation <br>
> > definitions. The problem is, I need to start two parallel <br>
> > branches, construct them independently in their own branches,
<br>
> > but then need to use some parts from both branches in a <br>
> > further rule. I use a block to function as a synchronizer for
<br>
> > the parallel branches, so that inputs from both branches are
<br>
> > available for the rule following the block. Unfortunately I <br>
> > could not succeed in achieving this. The scenario only works
<br>
> > as expected if I carry all the references serially through a
<br>
> > single branch, hence loosing space efficiency and introducing
<br>
> > unnecessary and confusing complexity.<br>
> > <br>
> > I have provided three start rules in the configuration. Of <br>
> > these three, only StartSerial block works successfully, while
<br>
> > StartMoreParallel and StartParallel do not. Details are below:<br>
> > <br>
> > (This is the point where the Initialize block ends in a debug
<br>
> > session. I expect the execution of the next rule, but it does
<br>
> > not execute.)<br>
> > <br>
> > Start Rule Name: StartMoreParallel<br>
> > <br>
> > Snapshot of Debug Step 9 (end of block Initialize):<br>
> > In Variables<br>
> > Tgt_RF<br>
> > has no value<br>
> > Src_Rf <br>
> > has no value<br>
> > Out Variables<br>
> > S_T1_Part<br>
> > NewSrcMain.PartA<br>
> > NewSrcMain.PartB<br>
> > S_T2_Part<br>
> > NewSrcMain.PartC<br>
> > NewSrcMain.PartD<br>
> > T_DataStore<br>
> > TgtMain.TgtDataStore<br>
> > TypeSystem<br>
> > TgtMain.TgtTypeSystem<br>
> > <br>
> > At Debug Step 4 (CreateTgtType1Data(dataStore:I, Part:I, <br>
> > typeSystem:I, type1:P, type1Ref:P, tgtPart1:P)<br>
> > No match and skip :-(<br>
> > At Debug Step 3 (CreateTgtType2Data(dataStore:I, Part:I, <br>
> > typeSystem:I, type2:P, type2Ref:P, tgtPart2:P)<br>
> > No match and skip :-(<br>
> > <br>
> > Eventhough the input ports are provided with matching data, <br>
> > neither CreateTgtType1Data, nor CreateTgtType2Data match and
<br>
> > execute. I thought that a block stacks all of its packets at
<br>
> > its output ports until the last packet is produced, and only
<br>
> > after that,the next rule following the block starts.<br>
> > <br>
> > Also, isn't there a mechaism to make a port repeat its value
<br>
> > n times? Let me explain this with the above example: In our <br>
> > case S_T1_Part has 2 packets, whereas, T_DataStore and <br>
> > TypeSystem have 1 packet. Therefore T_DataStore and <br>
> > TypeSystem should repeat their data as many times as <br>
> > S_T1_Part's packet count(in this case 2 times)<br>
> > <br>
> > A similar scenario is with start block StartParallel. Here we
<br>
> > are stuck after the rule CreateTgtDataStoreAndData. The <br>
> > following rules CreateTgtType1Data and CreateTgtType2Data <br>
> > just don't execute.<br>
> > <br>
> > The transformation only succeeds with the start block <br>
> > StartSerial. In this scenario we carry all the necessary <br>
> > references serially through a single path till the end of <br>
> > CreateTgtDataStoreAndData block. However, this sort of <br>
> > implementation results in unnecessary carrying of packets <br>
> > through previous rules that will be required in some other <br>
> > rule that is farther away. This is really a space efficiency
<br>
> > killer and complicates understanding of the rules in <br>
> > scenarios where the target model is huge and has modular <br>
> > subparts that can be constructed independently, but pieces of
<br>
> > those subparts are used as inputs in some rule that is <br>
> > further away in the rule execution sequence.<br>
> > <br>
> > Thanks in advance.<br>
> > <br>
> > Gürkan Özhan<br>
> > <br>
> _______________________________________________<br>
> great-users mailing list<br>
> great-users@list.isis.vanderbilt.edu<br>
> http://list.isis.vanderbilt.edu/mailman/listinfo/great-users<br>
</tt></font>