Bizarre bug in QuickLinker!

[Paolo F Cantoni]

In investigating the use of @Element in the QuickLinker, we accidentally discovered (after many hours tracking) a bizarre bug!

You can comment out a line in the QuickLinker by the use of a leading //

So far so good!  We generate the VAST bulk of our QuickLinker file via an automated process and we sprinkle some comments to help break the extremely large file up into sections - such as:
//,//,·,//,·,·,·,·,·,·,·,·,·,·,·,·,·,·,,,,,

//,//XSD Simple Type,·,//XSD Simple Type,·,·,·,·,·,·,·,·,·,·,·,·,·,·,,,,,


Notice the use of multiple // in the same line!  We've had NO problems with these since we started automating.

We had an entry in the manually managed section of the QuickLinker file concerning @Element:
//@Element,,@Element,,,Class,,Nesting,Nstng,to,nesting¯,nesting¯,True,True,True,True,(Nesting),0,,,,,
 //Doesn't Work!   Source Element type needs to be concrete!
We placed this at the start of the section where we were manually managing the concrete source types such as Activity,,@Element,,,@Element,,Nesting,Nstng,to,nesting¯,nesting¯,True,True,True,True,Nesting,0,,,,,

Class,,@Element,,,@Element,,Nesting,Nstng,to,nesting¯,nesting¯,True,True,True,True,Nesting,0,,,,,

To remind us of the issue.

We had the concrete sources working, and then added the comment.  Sometime later, we found the sources weren't working anymore - although AS USUAL there was NO indication that there was a problem.
After many hours of debugging we tracked it down to:
//@Element,,@Element,,,Class,,Nesting,Nstng,to,nesting¯,nesting¯,True,True,True,True,(Nesting),0,,,,,
 //Doesn't Work!   Source Element type needs to be concrete!
(on the same line)
Will KILL any following lines in the QuickLinker file, whereas
//@Element,,@Element,,,Class,,Nesting,Nstng,to,nesting¯,nesting¯,True,True,True,True,(Nesting),0,,,,,

//Doesn't Work!   Source Element type needs to be concrete!
(on separate lines)

Doesn't!  How Bizarre!!!

Reported,
Paolo

[matthew.james]

You have two choices now ... drink the bottle labelled "DRINK ME" or eat the cake labelled "EAT ME"

[Paolo F Cantoni]

You have two choices now ... drink the bottle labelled "DRINK ME" or eat the cake labelled "EAT ME"

I have a litre bottle of Dalwhinnie 15yo Single Malt witing for me...

Paolo

[matthew.james]

I have a litre bottle of Dalwhinnie 15yo Single Malt witing for me...

Everything will make sense after that :-)

[qwerty]

I'm not astonished that Sparx still sticks to that dinosaur format for the QL. However, I wonder why people don't really insist on something more handy that really seem to use it. Go kick their butt. Or the trainer's to send a "feature" request which requires improving (actually I mean replacing) it.

q.

[Geert Bellekens]

I'm not astonished that Sparx still sticks to that dinosaur format for the QL. However, I wonder why people don't really insist on something more handy that really seem to use it. Go kick their butt. Or the trainer's to send a "feature" request which requires improving (actually I mean replacing) it.

q.

Q, in fact they did. In v14 you can now model meta model constraints to control the quicklinker.
A big improvement over the old quicklinkder CSV definition.

I did notice however that the new method is not backwards compatible. No quicklinker in v12.1 when defined via meta model in v14.

Geert

[qwerty]

I was just looking at Paolo's code snippet which is just that silly CSV format. Not having backward compatibility is fully ok if the format is improved. I might move and look once again into V14.

q.

[Paolo F Cantoni]

I'm not astonished that Sparx still sticks to that dinosaur format for the QL. However, I wonder why people don't really insist on something more handy that really seem to use it. Go kick their butt. Or the trainer's to send a "feature" request which requires improving (actually I mean replacing) it.

q.

Q, in fact, they did. In v14 you can now model metamodel constraints to control the quicklinker.
A big improvement over the old quicklinker CSV definition.

I did notice however that the new method is not backwards compatible. No quicklinker in v12.1 when defined via meta model in v14.

Geert

Hi Geert,
As I mentioned elsewhere, we're looking to move to the v14 mechanism once we get some time.  We first have to manually reverse engineer our bespoke, handcrafted, MDG.  However, I am now concerned that we will lose backwards compatibility (we're not anticipating moving the users to v14 soon).  Does the v14 method still create the QuickLinker element (to be placed into the MDG file)?  Is it a formatting or a structural problem?

Paolo

[Eve]

It's completely new, and doesn't generate anything that earlier versions know to look for.

In terms of backwards compatibility, it will override an existing quicklinker table if one exists. (If you have a metamodel only stereotypes not mentioned in the metamodel will be taken from the quicklink table.) So your technology can include both.

[Paolo F Cantoni]

It's completely new and doesn't generate anything that earlier versions know to look for.

In terms of backwards compatibility, it will override an existing QuickLinker table if one exists. (If you have a metamodel only stereotypes not mentioned in the metamodel will be taken from the QuickLinker table.) So your technology can include both.

Thanks, Simon, for the clarification.

As I now understand what you've said, we can continue to generate the v13 QuickLinker section and overlay it with the V14 QuickLinker and distribute the one MDG until all our users have converted to v14.  Is that correct?  I am assuming that the new QuickLinker is in a new section.

Paolo

[Eve]

I'll take an example from the ArchiMate3 technology that you can see in your install directory.

Code: [Select]

          <Stereotype name="Application Internal Behavior" notes="" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0" isAbstract="true" generalizes="Internal Behavior" baseStereotypes="Internal%20Behavior">
            <stereotypedrelationships>
              <stereotypedrelationship stereotype="ArchiMate3::ArchiMate_Access" constraint="ArchiMate3::ArchiMate_DataObject"/>
              <stereotypedrelationship stereotype="ArchiMate3::Dynamic Relationship" constraint="ArchiMate3::Application Internal Behavior;ArchiMate3::ArchiMate_ApplicationEvent"/>
              <stereotypedrelationship stereotype="ArchiMate3::ArchiMate_Realization" constraint="ArchiMate3::ArchiMate_ApplicationService"/>
            </stereotypedrelationships>
          </Stereotype>
The ArchiMate 3 technology is describing its relationships mostly using the stereotyped relationship connector. The relationships it specifies go into the stereotypedrelationships node under the stereotype, grouped by the target connector type.

I've taken this example to illustrate what is different about this. It has specified that an abstract stereotype (Application Internal Behavior) has a number of valid relationships both concrete and abstract to different types, again both abstract and concrete. Instead of maintaining a spreadsheet with all of those expanded to concrete types you can specify it in the model itself. In this case, there are four connectors.

You lose a little flexibility by not defining all the rows explicitly, but gain model validation and hopefully a little sanity.

PS. Your @element relationship becomes a metaConstraint for the source and target of your Nsting stereotype referencing the metaclass Element.

[Paolo F Cantoni]

Thanks, Simon,

Food for thought!

Paolo