Incremental conversion of large existing MDG to model-based?

[Paolo F Cantoni]

Elsewhere I mentioned the difficulty of obtaining the necessary "time and resources" to convert a large and complex hand-crafted MDG to the new model-based profiles.  It's hard to counter the management argument of "It's working OK now isn't it?".  This was compounded by our understanding that the conversion required a "big-bang" approach, so the initial "hump" appeared massive!

For us, the main place where the conversion would, initially, assist is in better specification and management of the QuickLinker.  We previously maintained the QuickLinker portion from an Excel workbook, but that has fallen behind.

It occurred to me that using high-level abstract models for managing common relationships between items would allow us to convert the existing QuickLinker to a supplemental mechanism for the model-based version.  I think I would be able to generate the model-based MDG, and then just embed it in the current MDG (having made all the existing metatypes inherit from one or other of the leaf nodes of the model-based MDG).  Hopefully, I have explained the approach well enough.  If not, just ask for clarification and I'll add it.

I would probably start with the ArchiMate rule "Aggregation, composition, and specialization relationships are always permitted between two elements of the same type, and association is always allowed between any two elements, and between any element and relationship."

Once this was working, I can remove the specific instances from the existing QuickLinker specification (a relatively simple operation).  Then I can move elements and relationships over to the model-based form on a more incremental basis.

So my question to you all (and especially any Sparxians) is...  "Based on your experiences with model-based MDG specification, is this a viable approach?"

TIA,
Paolo

[Eve]

I think it's possible. It's a little more complicated than I would like, mainly because it's possible to use the one technology file in versions of EA that support and don't support the rules. What you're trying to do isn't exactly the primary goal either.

With that in mind. EA will ignore any quicklinker entry where the behavior of that connector is already described in the metamodel.

So, you'll need to migrate all of your rules for each connector type in one step. But other than that, it should be possible.

[Paolo F Cantoni]

I think it's possible. It's a little more complicated than I would like, mainly because it's possible to use the one technology file in versions of EA that support and don't support the rules. What you're trying to do isn't exactly the primary goal either.

With that in mind. EA will ignore any QuickLinker entry where the behavior of that connector is already described in the metamodel.

So, you'll need to migrate all of your rules for each connector type in one step. But other than that, it should be possible.

(my emphasis) Thanks Eve,

That's what I was hoping for.  I don't think I'll have a version of EA problem as the organisation is a new user of Sparx and we're all on v15+.

WRT to the emphasised comment, could you elucidate?  I would have thought that if the metamodel says nothing about an association between A & B and the old-style QuickLinker says there can be, that would just be additive (and, in fact, that's what gave me the idea of this approach).  Is that not the case?

Paolo

[Eve]

No, it's not additive for individual connector types. If it was, the default behavior (when strict connector syntax is enabled) would be that the quick linker would be showing items that EA wouldn't allow you to create.

[Paolo F Cantoni]

No, it's not additive for individual connector types. If it was, the default behavior (when strict connector syntax is enabled) would be that the quick linker would be showing items that EA wouldn't allow you to create.

Maybe additive was the wrong term...

Your response implies that (without metamodel input - as with our current setup) with strict connector syntax enabled, I can specify what is allowed via the QuickLinker "Classic" - yes?  That is, the QuickLinker determines what is allowable.  Or have I misunderstood?

If the understanding is correct, when we introduce the metamodel, we get stricter compliance - that is the metamodel will take precedence over the QuickLinker "Classic" -  which is as it should be.  But if I add a new connector metatype in "Classic" which doesn't violate the metamodel, then that should be OK, shouldn't it?

Perhaps "unioned" is a better term for what I'm saying.

In any event, for the present (and perhaps for the transition period) we DON'T have Strict Connector Syntax enabled.  Does that make a difference?  Once we get things sorted, we'll "tighten the screws...".

Paolo

[adepreter]

Have a look at Labnaf (www.labnaf.one).

In two clicks, all quick links are generated from the metamodel ... which is expressed using the modeling language itself.

[Paolo F Cantoni]

Have a look at Labnaf (www.labnaf.one).

In two clicks, all quick links are generated from the metamodel ... which is expressed using the modeling language itself.

Thanks, Alain,

If the generated QuickLinks are the "Classic" ones, we already have that capability.  If they are the new model-based ones, then we need to convert our "Classics" to model-based which is the exact problem I'm investigating here.

Can you confirm which type s generated by Labnaf?

[KP]

If the understanding is correct, when we introduce the metamodel, we get stricter compliance - that is the metamodel will take precedence over the QuickLinker "Classic" -  which is as it should be.  But if I add a new connector metatype in "Classic" which doesn't violate the metamodel, then that should be OK, shouldn't it?

My understanding is that if the metamodel says anything (about a connector type+stereotype) then that's everything. If it says nothing then the old-style quicklinker is still there.

[Eve]

Have a look at Labnaf (www.labnaf.one).

In two clicks, all quick links are generated from the metamodel ... which is expressed using the modeling language itself.

As opposed to using the functionality that's built into EA, to build quick links AND model validation AND non-connector based relationships like classifiers. Version 15.1 of EA even allows you to swap out the grouping of the quick links dynamically between connector and element type.

Also, describing your metamodel "using the modeling language itself" is just a fancy way of saying you specify what's allowed by providing examples. It means that you're unable to specify relationships using a type hierarchy of possibly abstract types.

[Paolo F Cantoni]

If the understanding is correct, when we introduce the metamodel, we get stricter compliance - that is the metamodel will take precedence over the QuickLinker "Classic" -  which is as it should be.  But if I add a new connector metatype in "Classic" which doesn't violate the metamodel, then that should be OK, shouldn't it?

My understanding is that if the metamodel says anything (about a connector type+stereotype) then that's everything. If it says nothing then the old-style QuickLinker is still there.

Ohhh...

Is it possible to have a definitive statement rather than understandings?  It's quite important that we users are told what is rather than what we think it is.

Paolo

[Eve]

Is it possible to have a definitive statement rather than understandings?  It's quite important that we users are told what is rather than what we think it is.

This is your definitive answer.

EA will ignore any quicklinker entry where the behavior of that connector is already described in the metamodel.

[Paolo F Cantoni]

This is your definitive answer.

EA will ignore any QuickLinker entry where the behavior of that connector is already described in the metamodel.

As always, it is a matter of semantics.  I didn't interpret the above statement as meaning what Neil said.  I can see that Neil's explanation is a possible outcome of your statement, but it's not the only one.

Anyway, thanks to you both, we have the clarification.  If I may, I will express it as...

QuickLinker metamodel definitions override Classic definitions. As a consequence, when a metatype (type+stereotype) definition is created in the metamodel, it is the only source of QuickLinker definitions for that metatype.

Have I got it right now?  I can now see why you earlier said: "So, you'll need to migrate all of your rules for each connector type in one step."  (Although I think I can qualify that to metatype rather than just type, yes?)

Paolo

[Eve]

(Although I think I can qualify that to metatype rather than just type, yes?)

It has absolutely nothing to do with metatype. Stereotype would be the right word to use.

[Paolo F Cantoni]

(Although I think I can qualify that to metatype rather than just type, yes?)

It has absolutely nothing to do with metatype. Stereotype would be the right word to use.

Ah yes... My bad.  In our MDG, we use one stereotype => one metatype so the two concepts are synonymous.  We think in terms of metatypes, but IIRC the relationship is defined in terms of the stereotype only, without mention of the type, so it could theoretically apply to more than one type.

Anyhow, some planning required to get this to work properly for us.

Paolo

[Paolo F Cantoni]

Well, I've had a chance to play and the results look promising!

Some questions have been raised to better understand what is happening and better plan the transition.  Is it better to asks them in this thread or start a new thread per question?

Paolo