Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - IanCornwell

Pages: [1]
1
General Board / Re: extend abstract metaclass
« on: July 04, 2023, 11:07:52 pm »
Have you tried to change from EnumerationLiteral to Attribute, just to see if that works?

Years earlier we had done that - use Attribute as the base metaclass which our stereotype for enumeration literals extends. But when I look at it today, I wonder why we did that - an enumeration literal is not an attribute, it's a literal which is a totally different kind of thing, and it's totally unrelated in the UML metamodel and in realisations in code. About the only similarity I can see is a that adding a literal to an enum in a UML diagram is a bit like adding an attribute to a class. However I cannot see any suitable EA metaclass to choose as the base for a stereotype for enumeration literals.

2
I looked at the XMI in case of inspiration, because that is more familiar to me than the database. This made me realise that I was probably mistaken when I said there were no "HDN=1" in the Geometry strings - I must have been looking at slightly truncated strings having used the copy function of the debugger. There are indeed "HDN=1" appearing after "LRB" in the Geometry strings for the affected associations. So I can try finding the HDN=1 after LRB and changing to HDN=0, and I expect this will work.

3
Our community has a set of models that use a common UML profile that was created 20 years ago and is currently being updated. We use our own stereotyped composition association, and for reasons now forgotten it has the part as source end and the composite at the target end – so it must be drawn from part to composite. That way round is unexpected to the majority of today’s modellers, so we are updating our profile to use a more conventional kind of association instead. For consistency of the model – at least how the modellers see “Source” and “Target” when they inspect association properties – we would also like to update the existing associations. There are thousands, so we would automate this. I have been exploring EA scripting for this.
A script successfully navigates to all Connector objects, identifies the right ones, and manipulates their properties. Properties that are objects are read-only, but the leaf-level attributes can be changed, and I seem to have successfully swapped ClientID and SupplierID, and ClientEnd and SupplierEnd internal properties like Aggregation, Role, Cardinality and Navigable – so the diagrams basically look the same as before.

For a minority of associations this breaks the geometry of the link on the diagram. I found DiagramLink.Geometry, but I couldn’t find any documentation of the Geometry format, or a way to know which links will break, and how to correct them. As a compromise it may be feasible to manually look through a hundred diagrams and force link redrawing by a minute adjustment of the positions of affected classes.

A more severe problem is that some multiplicities disappear from diagrams. All our compositions have multiplicity stated at the part end (which was the source but will now be the target) and not at the composite end (which is implicitly always 1). The UI has Visibility | Set Label Visibility which brings up a dialog of selection boxes with various labels, and in that the multiplicity of the composite end is unchecked (hidden) – or after supplier-client swapping it’s the part end multiplicity that is hidden (but we need to see it). I can change this in the UI, but I want to avoid doing that for one thousand associations.

I have read that HDN=0 / HDN = 1 within geometry determines visibility, but that doesn’t agree with what I am seeing - where the Geometry strings for links with missing visibility don’t have any HDN=1, and where if I manually change the label visibility in the UI, to force the multiplicity of the part end to appear, the only change in the Geometry strings is to nudge what looks like coordinates by 1 – no more or fewer fields and no change to HDNs.

Any ideas of a better approach to swapping the roles of source and target with respect to the composition?
If not, any information on how the visibility of multiplicities could be scripted, given the apparent non-use of HDN for this?
And is there any idea how to avoid needing to manually force a redraw of diagram links with broken geometry?

4
Bugs and Issues / Issues with paste of enumeration stereotypes
« on: October 28, 2014, 08:56:31 pm »
An important long-lived model happens to use classes with an <<enumeration>> stereotype, rather than using the enumeration UML element type.

However in EA v11 a copy & paste of such a <<enumeration>> automatically converts to a UML enumeration.
This creates inconsistency with the other enumerations (hundreds) in the model.
Does anybody know of a way to disable that automatic conversion so we can preserve package contents when we copy & paste?

Pages: [1]