Extend UML::Realization Fails on Profile Export

[wikitect]

This is a confirmed bug. If a class extends the UML::Realization metaclass then on saving as a UML profile the stereotype will incorrectly be defined as extending 'Realisation' (with a 's' not a 'z').

e.g.

Code: [Select]

<Stereotype name="realises"metatype="realises" notes="TRAK. Give physical form to.&#xA;&#xA;Used in:&#xA;- Resource realises
Node&#xA;- Resource Interaction realises Need&#xA;- Organisation realises Enterprise&#xA;- Port Connection realises Resource Interaction"
bgcolor="16764108" fontcolor="-1" bordercolor="-1" borderwidth="1" hideicon="0">
                        <AppliesTo>
                              <Apply type="Realisation">
                                    <Property name="direction" value="Source -&gt; Destination"/>
                              </Apply>
                        </AppliesTo>
                  </Stereotype>
The solution is to correct by hand after saving the profile.

[Paolo F Cantoni]

All this inconsistency was supposed to have been fixed back in 2009 (see): Dear Geoffrey...

Dear oh dear...

Paolo

[wikitect]

Paolo - I agree about consistency being paramount (it's hard enough if the tool and extensions to it provide/enforce consistency).

In terms of the 'realisation' it makes sense to take the UML spec with a 'z' i.e. 'Realization' since a UML profile by definition extends UML metaclasses and these things are concerned with consistency between users of different tools. In other words there's no point EA being self-consistent based on the wrong thing - it's what's universally accepted (the UML spec) that matters.

I don't understand why such simple things take so long to be fixed.

In this particular case it isn't simply a spelling problem. Even correcting this doesn't cause the object in the imported profile to behave as a relationship (connector) - it behaves as a class (object) so something else is broken.

[Eve]

The question is why do you think that it matters? For that matter, why do you think it's wrong?

The profile is intended only for consumption of EA. EA still uses 'Realisation' internally to provide backwards compatibility.

Either way will work when the profile is used by EA. I've just seen that you're describing that it doesn't work, and that does happen from the Resources window, but you can use the toolbox that is created automatically from the profile.

[wikitect]

The question is why do you think that it matters? For that matter, why do you think it's wrong?

The profile is intended only for consumption of EA. EA still uses 'Realisation' internally to provide backwards compatibility.

Don't be naive. Of course it matters - A UML profile is not just for EA it's the basic unit of consistency between all UML modelling tools that use the same profile. Hence it does very much matter whether the profile is generated correctly.

Either way will work when the profile is used by EA. I've just seen that you're describing that it doesn't work, and that does happen from the Resources window, but you can use the toolbox that is created automatically from the profile.

The work I'm doing supports an EA framework TRAK (http://trak.sf.net) and it is patently daft to assume that the whole world uses a single modelling tool. Since we need to make sure everyone uses the same EA building blocks the profile generated by Sparx EA is vital and it has to be correct.


It is more than a little strange that the UML::Realization metaclass (which is correct according to the UML spec) gets translated into 'Realisation' in the profile. There is no UML 'Realisation' class.

It also is patently wrong when a tool cannot import correctly the UML profile that it generated in the same way that any other UML profile would be imported. The fact that there is an additional 'get-out' from a separate pane is neither here nor there - this is a work around and the error/bug within Sparx EA remains.

I don't much care for the attitude. It is clearly an error and the lack of understanding of the use of a UML profile beyond Sparx EA and the need to consistency and correctness is worrying. Rather than fob off with a workaround you'd be better fixing the root cause of the problem. This isn't the only bug with profile generation - this seems to be a poor cousin in terms of fixing things.

[Eve]

I'll try to clarify.

The reason I said that importing into EA is that to my knowledge that profile format is unique to Sparx Systems. You'll find that the profiles distributed by OMG and other sources I have found all use XMI. (I also note that at least one profile distributed by OMG was exported to XMI by EA.)

So, is your issue with the profile that you are trying to write a tool that uses the profiles exported by EA?

I agree with you that the Resources Window is not handling Realization (with either spelling) stereotypes correctly. If you send in a bug report about it I will make sure that it is corrected.

What other bugs do you know of in profile generation? A quick look hasn't revealed any to me.

[wikitect]

So, is your issue with the profile that you are trying to write a tool that uses the profiles exported by EA?

The UML profile generated by EA is for any other UML modelling tool that needs to be able to create TRAK views - hence the stereotypes.

I agree with you that the Resources Window is not handling Realization (with either spelling) stereotypes correctly. If you send in a bug report about it I will make sure that it is corrected.

I was told that this specific one has been raised.

What other bugs do you know of in profile generation? A quick look hasn't revealed any to me.

* There is another bug with extending UML::Trace. (#11048919)
* In addition if a class inherits from 2 others (multiple inheritance) then it isn't exported into the UML profile. It will cope with one specialisation + extending a metaclass but cannot have more than one parent as such.

* On a similar vein stereotypes that don't extend a metaclass directly (e.g. via an abstract parent which does) are not shown on import back into EA.

This is from a telephone and email conversation on the 8th July 2010 with Ben Constable. Ben said:

* Notes on experiences with architecture and profile development in
Enterprise Architect:
      * Some consistency issues eg. When developing Profiles, visual
modeling for all configuration would be better, such as when specifying
toolbox items (currently via text strings) which can become inconsistent
with original definitions.

      * Multiple inheritance in profiles. Known limitation. Ben to
check on progress.

I will do some tests to see what happens in round-tripping a UML profile generated by EA when other UML classes are extended.

[wikitect]

Right, done some initial tests. I've created a gash profile that contains stereotypes that extend every UML metaclass that EA offers.

1) In terms of exported class names only Realisation differs from the metaclass name.
2) In the imported profile in the Resources pane the following fail to look/behave properly:

- Send
- Receive
- Enumeration
- DiagramGate
- Sub-Activity
- Trace
- SysBoundary
- StateLifeline
- Synch(H)
- Synch(V)
- StereoTagValue
- Sub-State
- TimeLine
- ValueLifeLine
- n-ary Association
- LoopNode
- ProtocolTransition
- Realization
- Boundary
- Synchronization
- ConditionalNode
- Include
- PackagingComponent
- FlowFinal
- Extend
- ProtocolConformance
- ProtocolStateMachine
- Self--Message

- all appears to have the default folder/package icon and create a class

I haven't tested the stereotypes that appear to have proper icons

[KP]

The UML profile generated by EA is for any other UML modelling tool that needs to be able to create TRAK views - hence the stereotypes.

No, use XMI for sharing profiles between UML modelling tools. EA's UML profile format is for consumption by EA only.

[KP]

Right, done some initial tests.

Silly question, but why? Your profile is embedded in a technology, isn't it? And you aren't loading your technology into the Resources window are you? Because that approach was deprecated when custom toolboxes were introduced in EA 7.0. The functionality hasn't been removed from EA because some people are still using technologies developed with EA 6.5 and earlier, but I certainly wouldn't recommend developing new technologies with the intention of loading them into the Resources window, because you miss out on all the new functionality.

[wikitect]

The UML profile generated by EA is for any other UML modelling tool that needs to be able to create TRAK views - hence the stereotypes.

No, use XMI for sharing profiles between UML modelling tools. EA's UML profile format is for consumption by EA only.

And where does it say this? I can find no reference to this. The user guide at http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/exportprofile_2.html for exporting a profile says nothing about profiles for EA vs other tools. Given that the primary purpose of generating a profile is for others as a means of sharing stereotypes this would seem to be a big omission - if true.

[wikitect]

Right, done some initial tests.

Silly question, but why? Your profile is embedded in a technology, isn't it? And you aren't loading your technology into the Resources window are you?

Aagh!

Please do me the favour of reading what I've written.

The UML profile for TRAK is:
1) exported as a bare UML profile - the purpose of which is to provide a library of the TRAK stereotypes for TRAK viewpoints. See http://trakumlprofile.sf.net .UML profiles are primarily about sharing - and not being tool-specific.

2) incorporated into the MDG for TRAK for those that use Sparx EA. See http://mdgfortrak.sf.net This then allows other functionality to be incorporated on top of the base UML profile.

The reason that I use the Resources window is that this is where the user is directed in order to load a UML profile. What you seem to suggest is that it is loaded under Resources but you've then not got to look at the result.

If you look at http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/umlprofiles.html, http://www.sparxsystems.com/resources/developers/uml_profiles.html where does it state that the Resources window should not be used and is deprecated?

The point is that if the means of loading a profile is via the Resources window then the user - rightly - expects that the list of stereotypes then shown as a result is correct and behaves correctly. You can't just dismiss this and say 'don't look or touch, go somewhere else'.

I'd have a lot more sympathy if you just admitted that it's buggy and the workaround is to use something else rather than try and pretend that this is the product of deliberate design.