Attribute constraints: How to show?

[rodrigoy]

Hi there... I put a constraint on my class attribute, but it doesn't appear in my class diagram... why?!

I'd like that my class diagram shows my attributes like this:

- id : int {oid}
- name : String {required, unique}
- age : int {>0}

Is it possible? How?

RodrigoY...
EA version: 4.51.751
Brazil

[Paolo F Cantoni]

Hi there... I put a constraint on my class attribute, but it doesn't appear in my class diagram... why?!

I'd like that my class diagram shows my attributes like this:

- id : int {oid}
- name : String {required, unique}
- age : int {>0}

Is it possible? How?

RodrigoY...
EA version: 4.51.751
Brazil

Excellent idea Rodrigo!  I too was wondering about that two days ago!  Submit a formal suggestion to Sparx!

Paolo

[rodrigoy]

You're saying that EA doesn't support it? Are you sure?

Rodrigo Y.

[Paolo F Cantoni]

You're saying that EA doesn't support it? Are you sure?

Rodrigo Y.

Possibly.
Because of the way in which EA's interface has been constructed (I hesitate to say designed) the facility may well be available, it's just not necessarily obvious.

In addition, the UML standard defines constraints on UML elements (as opposed to EA elements) and their representation.  However, a class attribute (as far as I can see) is not a UML element!

I think (like you), it is a very useful extension.  Formally reporting the problem will allow the Sparxians to tell you how it may already be done, then you can tell us!

Paolo

[rodrigoy]

I've submited the feature... let's see how long does it take for their response ...

Rodrigo Y.

[sargasso]

Not a bad idea...  a couple of observations.

Attributes can have multiple constraints.  How wide do you want the class box to go.

Optionality - I don't want to show them all the time.

bruce

p.s. I'm a bit curious about your example constraints.
{oid}  looks like a type not a constraint?
{required}  the class must have this attribute?
{unique} since there is only one of these attributes its value will always be unique
{>0} declare type "natural number", always implements this constraint.

[AshK]

I just wish to confirm that you cannot display feature constraints as described.

You may find this interesting: we've recently added a feature to display Executable UML decorations on the diagram.  

To do so, simply add one tagged value with the name "xUML" (or "XUML") and that value will be displayed to the right of the attribute.

I hope this information is useful.

[Paolo F Cantoni]

I just wish to confirm that you cannot display feature constraints as described.

You may find this interesting: we've recently added a feature to display Executable UML decorations on the diagram.  

To do so, simply add one tagged value with the name "xUML" (or "XUML") and that value will be displayed to the right of the attribute.

I hope this information is useful.

OK, I'll bite!  What's Executable UML and where is it defined?  (Not criticising, just asking - and interested!

Paolo

[Paolo F Cantoni]

Not a bad idea...  a couple of observations.

Attributes can have multiple constraints.  How wide do you want the class box to go.

Optionality - I don't want to show them all the time.

bruce

p.s. I'm a bit curious about your example constraints.
{oid}  looks like a type not a constraint?
{required}  the class must have this attribute?
{unique} since there is only one of these attributes its value will always be unique
{>0} declare type "natural number", always implements this constraint.

bruce and I are running "tag team" on this...
I thoroughly endorse bruce's point about using datatype to enforce constraints naturally.  In fact, I'd prefer that UML included the idea of Domain (in addition to Datatype).  A Datatype is essentially unbounded.  A Domain is a constrained Datatype.  Thus Integer is the datatype, NaturalNumber is the Domain.  For my conceptual modelling, the datatype field is used to store either a Datatype or a Domain.  By storing the Domain as a separate classifier, you can make the actual Domain constraint as complex as required and applicable (automatically) to all instances.

For the present, I use a stereotyped class for both Datatypes and Domains, but I'm thinking of asking Sparx to implement Domains when they (finally) implement UML Datatypes and Enumerations.

Thoughts anyone?

Paolo

[sargasso]

You may find this interesting: we've recently added a feature to display Executable UML decorations on the diagram.  
 
To do so, simply add one tagged value with the name "xUML" (or "XUML") and that value will be displayed to the right of the attribute.

C L!

B U T

1) its not editable like the rest of the attribute inplace editor

2) it needs a "link to element feature/aspect" as required elsewhere.

3) the class does not automatically resize when the tag is deleted.

bruce

edit:

I'd prefer that UML included the idea of Domain (in addition to Datatype).

Yes, yes, yes!!!!!!!!!