Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on February 24, 2020, 04:50:18 pm
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
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?
-
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.
-
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.
-
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
-
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.
-
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
-
(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.
-
(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
-
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
-
Doesn't bother me too much.
If the question could help others probably better to be a separate post. If it's not then keeping it here may reduce noise.
-
A very basic metamodel described using a metamodeling language is feasible.
But in the real world, describing a realistic Enterprise Architecture with that approach makes the metamodel unreadable and difficult to manage.
And if you add strategy and solution architecture then it is just not feasible for a member of the human kind at least.
By using the modeling language itself, you can scale and you make your end users happy.
You can change and deploy the metamodel in two clicks.
We could easily add the ability to specify the relationships using a type hierarchy of abstract types, but we haven't see the need yet.
It would make it easier for the administrator but not necessarily for the end user.
Here we have Strategy, Enterprise Architecture and Solution Architecture in a single language metamodel.
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=ECF05395-8B5B-4973-AA4B-27E521AA5D30
You can't do that with a meta-modeling language.
Nor can you do this with ArchiMate by the way (for several reasons).
-
We could easily add the ability to specify the relationships using a type hierarchy of abstract types, but we haven't see the need yet.
It would make it easier for the administrator but not necessarily for the end user.
That's very interesting. I would say that the language that the metamodel is defined should be completely transparent to the end user.
That's a point that I'd be more than happy to discuss with you further, but perhaps in another thread. In this thread Paolo is seeking help on a concrete issue that specifically involve moving to a system that allows the use of abstract metatypes to simplify his own job of defining that metamodel.
-
We could easily add the ability to specify the relationships using a type hierarchy of abstract types, but we haven't see the need yet.
It would make it easier for the administrator but not necessarily for the end user.
That's very interesting. I would say that the language that the metamodel is defined should be completely transparent to the end user.
That's a point that I'd be more than happy to discuss with you further, but perhaps in another thread. In this thread Paolo is seeking help on a concrete issue that specifically involve moving to a system that allows the use of abstract metatypes to simplify his own job of defining that metamodel.
Wot she sed...
I'm seeking concrete solutions... Hopefully involving less work than currently... :)
Paolo
-
An enterprise, a country, a human, a team, the earth, the universe ... these are all systems.
So the first thing you need is the semantics of a system that can be fortuitous or intentional and that can belong to the digital, physical and mental sphere (any combination)
http://www.depreter.org/AutomationByNature/doc/030%20Systems%20Semantics.htm
From systems semantics you can derive more specifically the semantics of an enterprise including the internal system that transforms the enterprise i.e. the transformation framework.
These more specific semantics are represented using a conceptual metamodel (here at 2 levels of details):
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=5173F22F-829E-4427-95E4-0694E39D9F8A
From the conceptual metamodel you can derive your language metamodel i.e. the metamodel expressed in the language used by the end user
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=ECF05395-8B5B-4973-AA4B-27E521AA5D30
The required language metamodel
- varies a lot depending on the existing enterprise culture and architecture maturity.
- needs to be readable easily by end users; so use the language that the end user uses)
- evolves very quickly over time, especially in the beginning; so it needs to be changeable very easily
This is summarized on this page
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=6A67F237-E1E4-41a2-BF3E-F922E1B18FF8