Messages

1

Suggestions and Requests / Some clarifications on UML-2 Interfaces

« on: April 14, 2004, 08:01:08 pm »

To clarify the confusion about interfaces of classes and components:

Components are not "normal" classes. In the UML-2 metamodel, components inherit from StructuredClassifier or EncapsulatedClassifier, dependig if they have just required and/or provided interfaces, or if they have ports which carry these interfaces.

On the other hand, "normal" classes do not have the capabilities of StructuredClassifiers, henc not required/provided interfaces.

Manfred

2

Suggestions and Requests / Recursive Association: Correction & Flexibilit

« on: April 14, 2004, 08:54:31 pm »

Hi Geoff,

Recursive Associations are incorrect represented with an arrowhead, no matter what navigability is selected. This needs to be fixed (actually an old issue ....).

Also more flexibility in positioning and line shape of the recursive association would be a great improvement.

Thanks,

Manfred

3

Suggestions and Requests / Re: Custom emf for "lollipop" notation?

« on: April 16, 2004, 02:13:06 pm »

Oh, Mike,

You didn't know that with the pictures...?  

You are touching a difficult point here.... What you are talking about is to substitute a notation in the context of stereotyping an element. Unfortunately this is not easy for most tools... I'm working on a component modeling tool which allows this. But it is only possible since my tool has a MOF-2 (CMOF) implementation underneath, so I can store enough metainformation associated with the new notation to make it working harmonically with the "old" stuff. Not easy....

Manfred

4

Suggestions and Requests / Re: Custom emf for "lollipop" notation?

« on: April 14, 2004, 08:44:08 pm »

Changing the cup/lollipop connector notation would make the diagram illegal UML. While the specification allows creativity for stereotype icons, connector notations (or any other notation) is a normative representation of a particular semantic and cannot be changed. Please note, UML is not just pictures, it is a formal graphical language with a given syntax. Opening up for more "flexibility" here would be the immediate end of model-driven development.

The solution in your case would be a pair of stereotypes extending the Interface metaclass from StructuredClassifier. Since you are introducing a pair of new language elements, you can assign your own notation.

Manfred

5

Suggestions and Requests / Re: Multiple Copies of Same Element in Diagram

« on: April 16, 2004, 02:03:35 pm »

Hi Jason,

While you are in principle right with your reminder to keep diagrams simple, the need for multiple copies of the same element can show up even in very simple diagrams.

And in particular if you have to work extensively with UML-2 package merge, showing generalization explicitely is frequently necessary (otherwise it would be unclear which stage of the merge is referred to). It would be very silly to allow only one occurance of the superclass and route generalization lines all over the diagram.

The UML-2 specification (infra- and superstructure) shows you many examples of the need for duplicates...

Manfred

6

Suggestions and Requests / Multiple Copies of Same Element in Diagram

« on: April 14, 2004, 08:18:48 pm »

Hi Geoff,

In complex diagrams there is the frequent need to have more than one copy of the same element in a diagram. To be explicit: All copies represent the same model element. The multiple copies are a conveniance for the modeler to reduce line clutter in the diagram. However, this is really an important conveniance.

Thanks,

Manfred
 

7

General Board / Re: Help with 'Qualified Multiplicity'

« on: April 14, 2004, 09:25:26 pm »

Hi,

you are very close. Actually, it is not qualified multiplicity, but qualification of the association.

The semantic is as follows: The element (class) which carries the qualifier uses the qualifier to select the element on the other end of the association. However, the multiplicity on that other end becomes a new meaning! it is now the multiplicity in relation to the qualifier. For example, if the multiplicity on the other end is 1, then exactly one element is selected via the qualifier. If the multiplicty is greater then 1, then a set of elements is selected for each qualifier. The total number of selections is determined by the value range of the qualifier.

I hope this helps.

Manfred

8

General Board / Re: turn off package name?

« on: August 02, 2002, 06:31:28 am »

Thanks Geoff for looking into that.

If it is not too much to ask for, the ideal solution would be two-fold:
1. The global option to turn the "from package" annotation on
   and off for the whole diagram. (and a relocation of the
   "from package" message from below the classifier symbol
   into the top compartment)
2. A per-classifier option to show either the full path name or
   only basic classifier name (with the basic name being the
   default).

I appologize on being persistent, but these features would really
be a great help in complex diagrams.

Thank you very much in advance,

Manfred

9

General Board / Re: turn off package name?

« on: July 28, 2002, 06:59:58 pm »

Long time ago I asked for a change how the originating package is  shown (the subject was something like "package name obstructive). My recommendation then was to move the string
"(from xyz)" into the top compartment below the class name (and use a small font). This would be consistent with the style habits in UML development.
However, the full qualified pathname, as in build 500 should remain as an alternative. Sometimes it is very important to show the fully qualified pathname.
Geoff, if possible, I would kindly ask for above described change and a per-classifier flag to switch between "from xyz" string and fully qualified pathname.

Thank you very much in advance! :-)

Manfred

10

General Board / Re: Bugs in EA

« on: July 28, 2002, 07:37:55 pm »

Well, I think there is no reputation problem for EA and I have a hard time to find frustrated users in this community. And I belive these kind of statements ar just not fair. You will have to search long for a product of this quality and features, the affordable price tag, and THAT exceptional maintenance!

If you search for bug-free software, there is a group in Huston, writing software for the space shuttle..... but you won't be able to carry the price tag for THEIR testing methods. (read an article on them recently...)

Manfred

11

General Board / Re: Feature Request: Enum Handling

« on: May 16, 2002, 11:11:40 am »

Thanks, Geoff.

This sounds good! And particular thanks for your fast reply (as usual..   )

Kind regards,

Manfred

12

General Board / Feature Request: Enum Handling

« on: May 15, 2002, 02:40:11 pm »

Maybe I have overlooked this, but....

It appears to me that EA has no dedicated handling for enums, which is, however, of some importance. I kindly request the consderation of the following features:

1. In Logical Diagrams (this is the more urgent part):
   According to UML 1.4, an Enum should be represented as a
   classifier with a name and the stereotype <<enumeration>>
   in the top compartment. In the middle compartment a an
   orderedlist of literals, one on a line, representing the values.
   The literals have no type, visibility, etc.

2. Code Generation/Import:
   Enumerations should generate the corresponding statements
   in the respective language during code generation.
   <<enumeration>> classifiers should be generated from
   corresponding statements during code import.

[An early fix for "1." would be a great help, full enum support
in the near future would be wonderful...]

Thanks in advance,

Manfred

13

General Board / Re: "from package" denominator obstructive

« on: April 14, 2002, 06:57:42 am »

Thanks Geoff,

Yes, this is correct. Only interfaces and classes.

Regards,

Manfred

14

General Board / "from package" denominator obstructive

« on: April 12, 2002, 06:08:40 am »

Hi Geoff,

Is there a way to relocate the "(from package)" import denominator to a location inside the top compartment of the class box, below the class name? It is by default below the class box, where it really conflict with the "fan out" of the class.

Thanks in advance,

Manfred

15

General Board / Re: Appearance of stereotyped classes in logical d

« on: April 12, 2002, 06:16:14 am »

Hm, coming back to this topic...
It would be really nice to distinguishe between the appearance of a class as a whole, which has an alternative shape ("icon") based on its stereotype, and the stereotype icon in the top right-hand corner of the top compartment of a (conventional) class box. The latter is very useful in coplex diagrams.

Thanks,

Manfred