Topics

1

Suggestions and Requests / Predefined tagged value sort order for stereotypes

« on: September 15, 2010, 02:33:34 am »

LS.

The sort order of the tagged values of a user defined stereotype seems according to the sort order of the attributes in the stereotype definition making up the tagged values of the stereotyped elements.

Unfortunately, there is no strong relation between stereotype definition and usage on this point; tagged value order seems to fluctuate over time and is not consistent for all elements sharing the same stereotype.

For the sake of consistency; please let the order of attributes in the stereotype definition ALWAYS reflect the order of tagged values for existing and newly created elements using that stereotype!

Thx'nAdv.
Agecoat

2

General Board / How to control 'browser hidden' elements

« on: November 11, 2013, 08:47:05 pm »

Hi all,

A quick search in this forum did not produce any answers on  this one, therefor this question:

In the repository, we want elements to be defined only once and used (on diagrams) many times. This also holds true for elements not shown in the project browser like Boundary and Note and perhaps other toolbox items that won't appear in the project browser when instantiated on a diagram.

Now as in any development effort of some magnitude, not only the model content but also the model structure is subject to change over time. In such case, the elements are explicitly moved from the old to the new structure and when applicable, also the diagrams they appear in.

When all its model contents is moved out or deleted, the old model structure is to be removed from the repository as well. But what about the elements created and shown in diagrams that are not shown in the project browser? Where are they located and how is their location to be altered?

A quick test seems to reveal that these 'browser hidden' elements are created in the package of the diagram they are instantiated in. When used in diagrams outside this package (by copy pasting its diagram appearance) we benefit of the single point of definition like for all 'browser visible' elements.

When deleting the package in which the 'browser hidden' element was originally created (being part of the old structure), the element seems to be deleted from the model as well, since all occurances on diagrams in the new structure are gone.

The ALt-G command does not seems to work for boundaries. Though the Properties of such an element reveal an attribute called "Package" stating the package in which the element is created (only shown on diagram occurance other than the package in which created), there is no known way of relocating the element, since it is not shown in the browser.

Question:

Is it possible to show 'browser hidden' elements (like Boundary, Note) in the browser in order manipulate their location in the same way as for 'browser shown' elements? If not possible, in what way can 'browser hidden' elements be managed (relocated)?

Thanx in advance!

Agecoat.

3

General Board / Select Property Dialog?

« on: November 22, 2010, 10:31:46 am »

Folks,

This puzzles me for some time now, perhaps some of you know a solution.

The Help File (EA 8, build 863) holds a page about "Select Property Dialog" located in "Modeling Fundamentals | Elements | Select <Item> Dialog | Select Property Dialog".

This page shows an example class diagram in which several classes are connected using Associations, Generalizations, Aggregations, etc.

Below the class diagram, a screen shot of a part of a dialog is displayed in which the resulting hierarchy of the diagram is shown.

Whatever I try, I'm not able to invoke said dialog, in order to select a property like AssociationEnd.

Why should I want that, you'll probably ask?

I have two layers of modeling (semantical versus realisation) which I want to relate in detail.

I have created a profile in which some newly defined stereotypes exist. For a stereotype extending the attribute metaclass, I want to include tagged value to relate to attribute(s) and a tagged value to relate association role(s) in the other layer. That way, I can relate realization layer attributes to semantical definitions.

I'm able to create a tagged value that relates to attribute(s) alright, but I'm not able to create a tagged value that relates to the role of an association (often resulting in an attribute in programming languages).

Unless some of you know what to do to invoke the Select Property Dialog. I am able to select a port though, but that's not good enough.

Also, there is some uncertainty about AssociationEnd versus AssociationRole. The screen shot says AssociationEnd where the metaclass only has AssociationRole.

The omg.org documentation is not very elaborate on this. Some things have changed in UML 2.3 in this area though.

Thx'nAdv.

Regards,
Agecoat

4

Bugs and Issues / Connector Middle labels visibility problem

« on: October 21, 2010, 09:29:03 pm »

Folks,

I believe the Middle Top and Bottom labels of a connector to be at fault in certain situations.

There seems to be a behavioral difference between a connector pointing from one to another class and a connector pointing from and to the same class. I can't imagine why this should be the case. I think there should be no difference.

For a connector between classes, there is a separation between connector name and connector stereotype:

- Middle Top Label: connector name
- Middle Bottom Label: connector stereotype

For a connector pointing to itself there is no such separation:

- Middle Top Label: concatenation of connector stereotype and connector name
- Middle Bottom Label: not used (at least not for stereotype)

The problem with this is that in diagrams, you can't hide the connector stereotype while showing the connnector name. This applies to connectors pointing to itself only.

I hoped for a workaround in creating a connector between two classes and altering source and destination afterwards but the label behavior seems consistent.

Any clues how to show connector name but hide connector stereotype for connector to itself?

Thx'nAdv.

Regards,
Agecoat.
(using Corporate 8.0.858)

5

Bugs and Issues / Tagged value sets: blessing or curse?

« on: September 29, 2010, 12:52:14 am »

Folks,

Not sure what the answer to this question is right now. Painted myself in a corner I think.

Created a <<profile>> package with a number of stereotypes extending metaclasses like class, attribute and association.

Each stereotype holding a set of attributes that will result in predefined tagged values for stereotyped elements.

Created several 100th of stereotyped elements with predefined tagged value set.

Findings:

Tagged value cannot be renamed in set and reapplied to existing stereotyped elements; no knowledge of previous situation results in new tagged value next to the old one.

Tagged value cannot be retyped (for instance to <memo*>) in a set and reapplied on exiting stereotyped elements; the type of existing tagged values remains unchanged.

No individual type setting possible, the user interface does not provide means for it.

You can reapply stereotype on existing individual stereotyped elements but you will loose all values.

How does one reapply the stereotype on an association?

The tagged value set does not maintain predefined order of appearance as specified in the metaclass extending stereotype. Alterations to the order of appearance cannot be applied to existing stereotyped elements.

Question:

Do I want too much here? Need to revert to modifying EAP-tables by hand? Overlooked something in the User Interface?

Regards,
Agecoat.