Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Guillaume on December 08, 2015, 06:32:41 pm
-
Hi,
I cannot get a Quicklinker definition to be taken into account in my MDG.
My MDG contains a UML Profile with stereotypes that extend built-in Archimate 2.
e.g.
ArchiMate_BusinessActor_Bis
ArchiMate_BusinessRole_Bis
I'm trying to replace the ArchiMate's quicklinker options with my own definition so I can create an ArchiMate_BusinessActor_Bis element with an ArchiMate_BusinessRole_Bis one via an Archimate Composition (standard one).
Taking the existing QL definitions in ArchiMate 2 MDG, I started a QuickLink document with the following:
Class,ArchiMate_BusinessActor_Bis,Class,ArchiMate_BusinessActor_Bis,,Class,ArchiMate_BusinessActor_Bis,Composition,ArchiMate_Composition,from,Composed of,Composed of,TRUE,TRUE,TRUE,TRUE,,,TRUE,TRUE,,,,
However this is never picked up by EA, even when I restart EA.
Am I missing something?
-
Hi Guillaume,
I think some things changed int he latest versions of EA.
I'd take the exiting BusinessActor segment and copy and replace with the _bis form and add to then end of the QuickLinker definitions.
QuickLinker management is certainly and arcane art... I've had some success, but more often by luck than design...
Paolo
-
Hi Paolo,
I tried it without any luck. All my elements have both stereotypes set (Archimate_BusinessActor and Archimate_BusinessActor_Bis) when I create them. It seems that Archimate2 QL takes over any definition I attempt to put in my MDG.
As a solution I can only foresee using an add'in that will automatically add my stereotype when an Archimate2 is created (far from ideal..)
Unless you have other options on the QL.
Thanks
-
QL definition is a PITA. Reduce your set to a single connector and make that very basic (the best to start from a similar that is known to work). Then stepwise go further with adjustments.
q.
-
I tried with a single entry (I read your MDG book -> QL chapter) and even with a single entry it doesn't work.
-
I'll give that one line you posted above a try.
q.
P.S. Challenging - like poking in the fog :P
-
I think I got it :P
I changed the 2nd "Composed of" to "Composed of 2" and it showed up. YAEAB or else I would not know why those labels need to be different :o
Will you send a bug report?
q.
-
I think I got it :P
I changed the 2nd "Composed of" to "Composed of 2" and it showed up. YAEAB or else I would not know why those labels need to be different :o
Will you send a bug report?
q.
Hi Guillaume & Thomas,
An educated guess... I suspect the reason that you need different labels is found in Giullaume's statement that his object have both stereotypes (if I understand him correctly - All my elements have both stereotypes set (Archimate_BusinessActor and Archimate_BusinessActor_Bis) when I create them.
)
So firstly we have the problem that (I think) QuickLinker uses only the primary stereotype - I may be proved wrong, but that's the assumption I've worked on and so far so good! QuickLinker is confused about which to apply, compounded by the semantic anomaly that you can't have two identical selectors (labels) for two different sources or endpoints.
HTH,
Paolo
-
Paolo,
the menu texts will appear in different contexts. One when linking two existing elements and the other when dragging onto empty space to create a new element. So I don't see a reason for the behavior. Anyhow, it is most annoying to see what you see. A meaningful warning to the system log would simply overcome this situation.
q.
-
Paolo,
the menu texts will appear in different contexts. One when linking two existing elements and the other when dragging onto empty space to create a new element. So I don't see a reason for the behavior. Anyhow, it is most annoying to see what you see. A meaningful warning to the system log would simply overcome this situation.
q.
I understand about the contexts. However, I'm not clear about the scenario that Guillaume is describing. Perhaps he could describe it more specifically, describing the behaviour with and without your fix.
Since I'm about to embark on a wholesale revamp of a very large QuickLinker file, I'm keenly interested in what's going on here.
Paolo
-
Hi Paolo & q,
First thanks to both of you on your additional inputs.
An educated guess... I suspect the reason that you need different labels is found in Giullaume's statement that his object have both stereotypes (if I understand him correctly
That's right. When I open the element's properties, the stereotype that shows up is the one from my custom profile i.e. Archimate_BusinessActor_Bis.
When I browse for additional stereotypes and select Archimate2 profile, I see that ArchiMate_BusinessActor is enabled.
So firstly we have the problem that (I think) QuickLinker uses only the primary stereotype - I may be proved wrong, but that's the assumption I've worked on and so far so good! QuickLinker is confused about which to apply, compounded by the semantic anomaly that you can't have two identical selectors (labels) for two different sources or endpoints.
My custom stereotype is the primary one, but QL still either gets confused or ignores my QL definition.
I tried as suggested narrowing down my UML profile & MDG to a single stereotype. I'm still having the same issue.
You can download the compiled MDG from here: http://bit.ly/1lx4ayF.
You can see the Quicklink definition in this file.
Once imported in EA, create a diagram > ArchiMate 2_Bis > ArchiMate 2_Bis
Created a business actor and try to create another one with the quicklinker.
-
Guillaume, could you provide the source EAP for the MDG?
q.
P.S. The provided MDG has ArchiMate_cs_BusinessActor as source and that works.
-
I zipped the source EAP file, available here: http://bit.ly/1OV4yR7
thanks
-
See my P.S. above
q.
-
There was a mistake in my exported MDG.
If you retrieve the updated MDG from http://bit.ly/1lx4ayF, you can see what happens.
-
Yes, I see. Will fiddle around with that...
q.
-
Just a guess.
If you're inheriting from the original Archimate_BusinessActor, the quicklink definitions defined by the archimate technology will also apply to yours.
All of the rows for BusinessActor have 'Exclusive to ST Filter + No inherit from metatype' set to true. Unless I'm mistaken this also has the effect that no entries without that property set will be considered at all. Potentially including your sub-type. If that's the case, setting it to true in your definitions may allow it to work.
-
The Business Actor menu already has an entry "Composed of" from Archimate and that will be used. I renamed your menu to "My Composed of" and it appeared below in the menu.
q.
-
The Business Actor menu already has an entry "Composed of" from Archimate and that will be used. I renamed your menu to "My Composed of" and it appeared below in the menu.
q.
So does that mean we've gotten to the bottom of the issue?
In other words, can we describe the problem and the solution - or is it still "in play"?
As I said, I'm keenly interested in the problem (and its solution) before I redevelop my QL.
Paolo
-
Fantastic, it works.
Here are the rules to follow:
- use a different name for the Groups (e.g. Business Actor Bis instead of Business Actor) - column Q
- use a different name both for "New Link Caption" and "New Link & Element Caption" (e.g. is Composed Of instead of Composed Of) - columns K and L
My final request would be to hide the inherited ArchiMate 2 QL definitions. I'm not sure if this is feasible.
-
My final request would be to hide the inherited ArchiMate 2 QL definitions. I'm not sure if this is feasible.
I have not found a way to do that. Feature request (though I see little chances for that since it will involve a structure change of the QL table)?
q.
-
Fantastic, it works.
Here are the rules to follow:
- use a different name for the Groups (e.g. Business Actor Bis instead of Business Actor) - column Q
- use a different name both for "New Link Caption" and "New Link & Element Caption" (e.g. is Composed Of instead of Composed Of) - columns K and L
My final request would be to hide the inherited ArchiMate 2 QL definitions. I'm not sure if this is feasible.
Thanks for that Guillaume,
Just to "close the circle"; what was the conceptual problem you were trying to solve - just creating your version of the Business Actor or was it more complex than that?
Paolo
-
Thanks for that Guillaume,
Just to "close the circle"; what was the conceptual problem you were trying to solve - just creating your version of the Business Actor or was it more complex than that?
I presume he like others is is trying to either improve on the UMLised Archimate or further UMLise it to make it more usable, by extending it with abstract metatypes.
You run into the same issues when prototyping TOGs suggested enhancements to Archimate. (eg https://www2.opengroup.org/ogsys/catalog/W150)
The real solution would be for Sparx to "open source" the Archimate 2 MDG and allow people to fork it.
-
+1 (also for a couple of other things like the help wiki). But chances to see that within the next 10 years are about -1.
q.
-
I sent a query to Sparx regarding the QL issue. I'll update this thread when I get an update.
Paolo, I started looking into this as I have a client who would like to use the original Open Group Archimate colour code (yellow/blue/green on the behaviour/active/passive instead of biz/app/tech), as seen in Mastering Archimate book.
I'm nearly there and plan to share it once completed so users have the alternative option.
-
Thanks for that Guillaume,
Just to "close the circle"; what was the conceptual problem you were trying to solve - just creating your version of the Business Actor or was it more complex than that?
I presume he like others is is trying to either improve on the UMLised Archimate or further UMLise it to make it more usable, by extending it with abstract metatypes.
You run into the same issues when prototyping TOGs suggested enhancements to Archimate. (eg https://www2.opengroup.org/ogsys/catalog/W150)
The real solution would be for Sparx to "open source" the ArchiMate 2 MDG and allow people to fork it.
Well I hope Guillaume confirms one way or the other. (So we don't make any presumptions :P ;D - It's a joke, )
We decided to abandon extending the supplied ArchiMate and just replaced it. We disable the supplied ArchiMate MDGs by renaming their extensions and hook up to our MDG instead.
Our need for consistency and rendering were such that we go off on a tangent. As each new release of the supplied MDGs comes out we compare and contrast with the previous version to see if anything should be promoted to ours.
Paolo
-
We decided to abandon extending the supplied ArchiMate and just replaced it. We disable the supplied ArchiMate MDGs by renaming their extensions and hook up to our MDG instead.
Which is why having it in a shared repository and being able to fork it would be more useful :-)