Generated profile XML file has no

[fwoolz]

Bug report filed-----

=========================================
I have the latest and greatest release of EA Ultimate (7.5.850), running on Windows 7. I've just tried creating a profile for the first time with this particular combination of EA and Windows, and have encountered a problem. When extending a MetaClass, the "extend" association stereotype shows as "Extends" (Upper case E); this of course resists correction within EA to "extends" (lower case e). Exporting the profile to XML results in an XML file with no <AppliesTo> elements; thus importing the profile XML results in an EMPTY profile in the Resources window.

Using Access to link to the EAP file, I then corrected "Extends" to "extends" for each profile connector, then repeated the process. Now the profile imports correctly!

Case-(in)sensitivity of stereotype names in EA has never been completely consistent in its behavior; this seems to be another example. Has anyone else seen this issue?

Cheers,
Fred Woolsey

[Paolo F Cantoni]

Yes Fred,, I've seen it.

Paolo

[fwoolz]

Paolo,

If YOU hadn't, I would have wondered whether I was hallucinating!

There are obviously bits of code that care about stereotype case and others that don't. The UML 2.2 spec recommends the following (Infra, 13.1.8, pg. 199):

Code: [Select]

Style Guidelines
The first letter of an applied stereotype should not be capitalized. so it isn't clear why EA would want to capitalize the 'E' in 'extends'. In fact, the UML spec seems to call for something akin to automatic variable naming in, say, Visual Studio - The type definition would be capitalized ("Extends"), while the application of the stereotype to a connector (as in a profile diagram) would not be capitalized ("extends"). So EA seems to be working backwards in this case (no pun intended)!

Fred

[KP]

I think TOGAF has an «Extends» which is causing the problem. For now, try disabling TOGAF while saving profiles; Fix to follow...

[fwoolz]

Thanks, Neil...

[Paolo F Cantoni]

I think TOGAF has an «Extends» which is causing the problem. For now, try disabling TOGAF while saving profiles; Fix to follow...

Ah yes! I've been using TOGAF but now I normally have it disabled.

That explains the "apparently" inconsistent behaviour...

I'll watch out in future when using TOGAF.

Will the fix be in v8 or later?

Paolo

[fwoolz]

This brings up the whole issue of EA and its handling of stereotypes. From the UML 2.2 spec (Super, 18.1.2):

18.1.2 Profiles History and design requirements
The Profile mechanism has been specifically defined for providing a lightweight extension mechanism to the UML standard. In UML 1.1, stereotypes and tagged values were used as string-based extensions that could be attached to UML model elements in a flexible way. In subsequent revisions of UML, the notion of a Profile was defined in order to provide more structure and precision to the definition of Stereotypes and Tagged values. The UML 2.0 infrastructure and superstructure specifications have carried this further, by defining it as a specific meta-modeling technique. Stereotypes are specific metaclasses, tagged values are standard metaattributes, and profiles are specific kinds of packages.

EA still seems to treat applied stereotypes more or less as simple strings ala UML 1.1, which, combined with inconsistent use of and significance of case, leads to name collisions when multiple profiles are loaded. The table t_stereotypes does have a mechanism for tracking the originating profile (using the VisualType field), but stereotypes are not full-fledged objects and thus can't be instantiated when "applied". I'm not convinced that this is a major problem, but case sensitivity issues need to be sorted out along with consistent differentiation of identically named stereotypes based on their originating profile (namespace).

Fred W

[fwoolz]

Neil & Paolo,

Simply disabling TOGAF within a session didn't work, but disabling TOGAF, then restarting EA did the trick!

Cheers,
Fred

[Paolo F Cantoni]

Funny, I was just checking out that same section (18.1.2) yesterday...

Your points are well made Fred.

On top of this, there's the problem of profile vs MDG.  MDG stereotypes don't get into t_stereotypes at all.  I think they should.  The namespace is the MDG technology name.

Paolo

[fwoolz]

Paolo,

GMTA, as they say...

IMHO, if a profile is included in an MDG technology file, the profile should be loaded as a resource just like a profile XML file & wind up in t_stereotype like other profile-based stereotypes. There's that consistency thang again!

Cheers,
Fred