Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: csousa on August 23, 2013, 05:32:38 am
-
I'd like the ability to refine the Archimate MDG (primarily in the arrangement of toolboxes and diagram types to better support cross-layer viewpoint modeling).
I know I can manually edit the MDG's XML file to affect changes to the toolboxes..etc. (can be an error prone process). I would rather work properly from the originating/source model.
I searched briefly to see if any of the source models were available but couldn't find them....anyone know if they are available?
-
The source is owned by Sparx and I have not seen any sign they would make it available. Maybe if you put enough bread on the board the will shift it over.
q.
-
The recommended approach would be to create your own technology. In it define your own diagram types and corresponding toolboxes that are using the Archimate elements. Where necessary you could also define extensions to the existing elements.
-
Thanks Simon,
There are two aspects of the Archimate 2.0 MDG that are problematic. The first is just a convenience feature of adding more diagram types and corresponding toolboxes.
The second issue relates to the underlying UML construct that was used in the Archimate 2.0 MDG for Realization.
Instead of a UML realization (with the stereotype of ArchiMate_Realization), the MDG uses a UML Dependency with the stereotype of ArchiMate_Realization. When using traceability and relationship matrix features, one cannot distinguish out the realizations from the "used by" or other similar dependencies. (I can't imagine why a dependency was used as a foundational element for realization, perhaps there was a good reason?)
Applying a minor refinements to the MDG is really what I want to do (not re-work the entire MDG). Is there a mechanism to request refinements like this from Sparx?
P.S.- Respectfully I understand that the source models are not available, but given that one can edit the open XML to achieve similar refinements, I would assert that not providing the source models is just an inconvenience for customers.
-
In that case, add your new diagram types to your technology and define toolboxes to match. Then define a profile that defines Archimate realization the way you want and use that instead of the sparx archimate connector.
-
Thanks Simon,
Here is a synopsis of the issue. I was able to correct it with an edit to the underlying XML of the Archimate MDG
Problem: The Archimate 2.0 MDG Models its Realization as a stereotype of a UML dependency. This causes traceability confusion in Sparx EA’s traceability dialogues as realizations cannot be distinguished from dependencies (e.g., the Archimate “used by”).
Consider a Simple Model Pattern
'My Application Component' - Realizes -> "My Application Service"
'My Applicaiton Component' - Uses -> "Another Component"
<< Traceability window shows two "depends on" links >>
Solution: A Correction to the Underlying Type that the Archimate Realization was made to a copy of the MDG Plugin. Note: Existing realizations in a model need to be re-created (or updated), while newly created ones will appear correctly.
<< Post correction, the traceability dialogue shows one "implements" relationship and one "depends on" relationship.>>
-
There is one feature that I can't seem to correct via an XML edit (perhaps you can assist with)?
While I was able to get the fix to work without errors, when I edit the "Quicklink Data" segment of the MDG's XML file (change dependency to Realisation), the MDG's quicklink menu breaks (becomes unavailable).
The quicklink data tag looks like a delimited data set with three columns of specific interest.
New Link Type
New Link ST
New Link Direction
In the case of an Archimate Realization, the existing MDG would state
Dependency, ArchiMate_Realization, to
this would be changed to...
Realisation, ArchiMate_Realization, to
When I run a test and edit the quicklink data (no longer appears).
Any suggestions on what the approach / issue might be?
Any chance of releasing this open source MDG source model so I can do this properly without having to recreate the entire MDG (or releasing a patched MDG for Archimate)?
-
First, I'll re-iterate that changing the Archimate technology directly is not recommended. Even if you had the source (which we are not planning on releasing) or were 100% confident in your changes you are making your Archimate models incompatible with anyone who doesn't have your version of the technology. The errors that this would cause are likely to be subtle. The recommended approach is still to create your own technology that extends the Archimate technology.
Now that I've said that and if you're still insistent on taking that risk... Changing to Realization instead of Realisation may solve your problem.
-
Now that I've said that and if you're still insistent on taking that risk... Changing to Realization instead of Realisation may solve your problem.
That bad old heritage from UK. That will only vanish when the Queen eats at Burger King. Or America will have a King - without burger.
q.
-
Thanks for the warning Simon, fair points.
The intent would be to version the Archimate MDG and ensure that my team is all using the correct version.
Two final questions to close off this thread:
1) Can one build an MDG that only changes the one defect without having to redefine the Archimate MDG in its entirety (I don't see how this it is possible to redefine an existing connector) If this is not possible and Sparx will not release the MDG source models of this open source framework then...
2) Is there a way to log a defect against the existing MDG so that it can be rectified in future releases? An Archimate realization should never have been modelled as a dependency.
-
1) Taking Simon's warning you can fiddle around with the MDG. Quite some people have done so.
2) Send a bug report using the link bottom right.
q.
-
Just a quick update. Bug report was filed.
Rather than classify the root cause as an issues relating to the way the Archimate 2.0 MDG was constructed, Sparx support has decided that the best way to solve this problems to extend the traceability window, relationship matrix (etc...) to interpret meta-types/stereotypes.