Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on April 27, 2017, 10:05:46 am
-
As I've mentioned, we're maintaining our own MDG file outside of the Sparx provided mechanisms.
One thing we've thought about doing is to add additional properties (attributes) to the <Stereotype> section - this is to aid various automation and validation initiaives. We added a new attribute (of our making) and EA didn't complain when we loaded the new MDG.
<Stereotype name="AbbrvtnOf" metatype="Abbreviation Of" notes="" cx="101" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="49407" borderwidth="-1" hideicon="0" strictness="all" nature="Arc">
(See "nature" attribute)
We think we'll go ahead and give it a go. Apart from the maintenance problem - which we already have anyway, are there any other downsides?
Paolo
-
I use a model to generate my MDG and looking at the xml where I've added attributes to stereotypes they come out as tag values
Something like this
<Stereotype name="Application Component" metatype="Application Component" ...>
<TaggedValues>
<Tag name="Pace Layer" type="enumeration" description="State the pace layer. Reference Gartner Pace layering" unit="" values="Record,Differentiation,Innovation" default=""/>
<Tag name="COTS name" type="String" description="If the app is a Commercial Off-the-Shelf (COTS) product state the common name for it." unit="" values="" default=""/>
...
</TaggedValues>
Not sure how Sparx EA will store the data in its database as defined in your stereotype. Its uncharted territory doing it that way to me I'm afraid.
Any particular reason why you don't use a Sparx EA model to generate the MDG? Its so much more easier than messing around down at the XML level.
-
I use a model to generate my MDG and looking at the xml where I've added attributes to stereotypes they come out as tag values
Something like this
<Stereotype name="Application Component" metatype="Application Component" ...>
<TaggedValues>
<Tag name="Pace Layer" type="enumeration" description="State the pace layer. Reference Gartner Pace layering" unit="" values="Record,Differentiation,Innovation" default=""/>
<Tag name="COTS name" type="String" description="If the app is a Commercial Off-the-Shelf (COTS) product state the common name for it." unit="" values="" default=""/>
...
</TaggedValues>
Not sure how Sparx EA will store the data in its database as defined in your stereotype. Its uncharted territory doing it that way to me I'm afraid.
Any particular reason why you don't use a Sparx EA model to generate the MDG? Its so much more easier than messing around down at the XML level.
Hi Sunshine,
I didn't explain myself well enough. I'm NOT looking to add properties to the stereotype that are to be applied to the instance that ends up in the repository. As you note, that's what the Tagged Values are for.
I'm, rather, trying to tag the metatype itself, a sort of metatag if you like. That's why we need to attach it to the MDG file entry itself.
Why? Well, it has something to do with the second question you posed, why not use Sparx's mechanisms?
It sort of "just happened". We started by modifying a clone of the ArchiMate MDG file, mainly just changing the shape scripts. We found we could round-trip such changes very speedily (<1min) by directly editing the affected stereotype. After a while, we got to understand the structure of the MDG file and just kept going. We've now been able to generate our QuickLinker file from declarative information stored in spreadsheets and databases (some 350,000 rows) and we inject it directly into the MDG. As our modelling environment evolves, we are able to evolve the MDG file pretty rapidly, in sync. Most recently, we had a work experience student develop an editor macro to split the <Stereotypes/> section into it's 200 odd constituent stereotypes (stored as separate files) and reassemble into any arbitrary order we want. (That's where the nature property comes in, we separated arcs from vertices and then had the stereotypes in alphabetical order). We want to access the
nature property to allow us to store the arcs separate from the vertices. Ther splitter macro will use the value of the nature property (as it currently uses the value of the metatype - to get the file name to use). By having complete(?) control over the MDG, we can do a lot of stuff outside it to maintain/enforce consistency etc.
Does that help?
Paolo