Inheritance of Tagged Values between Stereotypes

[Jayson]

Hi there

I've been developing an MDG that uses multiple inheritance in the normal way to ensure that I need only define tagged values in one place rather than creating a maintainability nightmare by having to define tagged values in every stereotype that needs them.

Up until now I have been developing the MDG in a single profile package (called NZDF_EAF) and inheritance has worked perfectly for me.

However, in order to make the MDG project easier to understand and manage, I decided to break the project into a number of profiles and group the various stereotypes logically into this profiles.

My project still has a profile called NZDF_EAF, but now there are six (6) profiles nested inside it called:

* Common
* Portfolio
* Principles
* Stakeholder
* Strategy
* Structural

Most of the sterotypes which I want to inherit tagged values from are in the "Common" profile and stereotypes in all the other profiles inherit from them.

However, when I generate the MDG, inheritance no longer works.

Any suggestions on how to overcome this would be really appreciated.

Thanks

Jays  

[Jayson]

Ooops! Forgot to mention I am using Sparx 9.3

[qwerty]

Why do you split it into 6 profile packages? That rises the need to qualify the single stereotypes. I guess you're better of by simply placing packages inside a single profiles. That's simply better to bring in structure.

q.

[Jayson]

Okie, might give it a try.
But what do you mean by qualifying the stereotypes?
Do you mean profilename::stereotypename?

If so, I tried this and it didn't seem to work.

Cheers

[ZuluTen]

I suspect that I'm trying to achieve the same as you: because of the sheer quantity of stereotypes, enumerations and metaclasses sitting in an apparently haphazard fashion under the <<profile>>, I decided to have a tidy up, and carefully sorted them out into a number of sub-packages.

The result was much tidier but didn't work, even though I'd realised that I would have to update the pointer within each toolbox to refresh its knowledge of where each stereotype was newly located.

I spent much of last evening trying to fix this, but this morning noticed the following line within the EA Manual:
"A Profile package can contain several diagrams and many elements and connectors, but no other packages; do not use nested packages in a Profile"

This I think explains why my tidy up broke a previously working toolbox, so I've just gone through dumping all the stereotypes into the <<profile>> 'root'.

Maybe I've misunderstood what q. meant, but suggest you try the change on a small subset first...

[qwerty]

@ZuluTen: I was never aware of such a restriction. I used packages inside <<profile>> packages in the past without a problem. Strange.

Or maybe my memory simply deceives me. What I did was to create different diagrams focusing on certain stereotypes. But I'm pretty sure that I also used a couple of packages without any issue.

q.

[Uffe]

Let's say you've got one ChildSt inheriting from BaseSt1 and BaseSt2. Your XML file will then contain

Code: [Select]

<Stereotype name="ChildSt" ...
  generalizes="BaseSt1" baseStereotypes="BaseSt1 BaseSt2"/>In order for generalization between stereotypes in different profiles to work, you need to qualify the baseStereotypes reference. EA (10.0.1009) does not do this for you, so what you end up with is still a maintenance nightmare, albeit one with a slightly different monster (post-generation manual XML file editing).

You should also note that only one base stereotype is listed as generalizes. Exactly what effect that has I'm not sure. Possibly it controls which RefGUID tags the child may be used in (in this case, it could then be used in tags specifying BaseSt1 but not in tags specifying BaseSt2), but that's conjecture.

Ways around: I don't know of one, I'm afraid. Unless you can separate your stereotypes into completely separate inheritance hierarchies, I think you might be stuck. So it may be necessary to decide which evil is lesser: a single large profile, or duplication of tags in separate profiles. (Of course, within each profile you can set up the corresponding inheritance hierarchy to minimize the effect.)

As to that, and this is more in response to ZuluTen, having several different profiles in the same MDG Technology is not just possible, but usually a good idea (unless you run into an issue like above).

I have not had any good experiences placing packages inside a profile, but the other way around works just fine. So you wouldn't nest profiles inside each other, but place the different profiles in a single containing package. That package is only there for convenience in your MDG Technology project (you are developing your MDG Technology in a completely separate project, aren't you?), you never generate anything from it.

My MDG Technology projects typically contain a structure like this:
"MDG Technology name" (root node)
  |- Profiles
  |      |- «profile» UML Profile 1
  |      |- «profile» UML Profile 2
  |- Toolboxes
  |      |- «profile» Toolbox 1
  |      |- «profile» Toolbox 2
  |- Diagrams
  |      |- «profile» "MDG Technology name" (if there are only a small number of diagrams)
  |- Learning Center
  |      |- «profile» Learning Center Pane 1

... with additional levels as required; typically there may be some subdivision of toolboxes if there are a large number of diagrams. Only the «profile» packages are ever saved as profiles, the others are just structural sugar.
The model structure is mirrored in the directory structure on the disk, of course, which makes the MDG Technology creation process more convenient.

A word of warning: while moving stereotypes into separate profiles can usually be done in a production environment with little risk, shuffling diagram types between profiles cannot. This is because the stereotypes are only stored with their simple names, but the custom diagram type is stored as a qualified name inside each diagram's StyleEx column.

HTH,


/Uffe

[KP]

Let's say you've got one ChildSt inheriting from BaseSt1 and BaseSt2. Your XML file will then contain

Code: [Select]

<Stereotype name="ChildSt" ...
  generalizes="BaseSt1" baseStereotypes="BaseSt1 BaseSt2"/>In order for generalization between stereotypes in different profiles to work, you need to qualify the baseStereotypes reference. EA (10.0.1009) does not do this for you, so what you end up with is still a maintenance nightmare, albeit one with a slightly different monster (post-generation manual XML file editing).

Ways around: I don't know of one, I'm afraid.

In your profile, create a new stereotype class and name it "OtherProfile::BaseSt1" (or whatever the other profile is named), set it to abstract, and create a generalization to it (instead of the generalization to the actual BaseSt1 in the other profile package). That will add the fully-qualified name to the baseStereotypes attribute and save you having to edit it by hand.

[Uffe]

Aaaah - brilliant!

I actually use something similar to this when I need to create a RefGUID tag which allows selection of a «procedure» or other Sparx-defined stereotype, using the «taggedValue» connector.

I create a "«profile» External Stereotype References" package, and place a "«stereotype» procedure" in that. No metaclass or anything, this profile is never exported to disk nor included in the MDG Technology.

This homegrown «stereotype» procedure can then be used with the «taggedValue» connector in my profiles, and it all works beatifically. The reference is written to the XML file even though the "reference" profile is a big fat phony.

/Uffe