Object State - name rendering

[Paolo F Cantoni]

In a recent post: [size=13]NewBie question[/size]  I mentioned setting the object state using the context menu dialog [Ctrl+Shift+S].  On that dialog is a check-box:  [ ] Merge State with Instance name.

If the name of the Instance is empty, the Classifier is Order, the state is Paid and the checkbox is unset then the rendering is:
: Order
[Paid]

if you set the check-box, then the rendering is:
: [Paid] : Order]

if you add a name for the instance say "Order", you get:
Order[Paid] : Order
where the state is postfixed to the name.

In the other post, I manually set the name to:
PaidOrder and UnpaidOrder

But it seems to me a more general rule that says
when constructing a name for the instance. the most common renderings would be:
[State]Classififer or Classifier[State]
Example: [Paid]Order  or Order[Unpaid]

I think it would be a time saver (and increase consistency) if the [ ] Merge State with Instance name were enhanced with:
[ ] Prefix (else Postfix) and [ ] Use Classifier Name
If both were set, in the above example we'd get:
[Paid]Order: Order

Lastly, a checkbox [ ] Suppress State markers would suppress the enclosing "[" and "]" for the state giving:
PaidOrder: Order.

Thoughts?
Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

Paolo said:

Lastly, a checkbox [ ] Suppress State markers would suppress the enclosing "[" and "]" for the state giving:
PaidOrder: Order.

I think without the state markers, PaidOrder and UnpaidOrder would be taken as two different orders instead of two states of the same order.  Otherwise, I like what you are suggesting.  I'm wondering on which diagrams you would normally include the state notation on an object?  For example, I don't think it would be used on a Composite Structure diagram.  :-/  

Does the Superstructure Document speak to this type of state notation?

[«Midnight»]

I agree Jim,

Unfortunately I don't know what the superstructure spec says either, and don't have time to look.

The Sparx folks certainly do know, so let's see if they either answer - there might be a good reason for the status quo - or make some changes.

David

[Paolo F Cantoni]

I think without the state markers, PaidOrder and UnpaidOrder would be taken as two different orders instead of two states of the same order.  Otherwise, I like what you are suggesting.  I'm wondering on which diagrams you would normally include the state notation on an object?  For example, I don't think it would be used on a Composite Structure diagram.  :-/

Does the Superstructure Document speak to this type of state notation?

In higher order models you can mark PaidOrder and UnpaidOrder as «inferred» objects (see: [size=13]Inferred UML elements[/size]) this alerts you to the fact that these objects are merely expository.

Paolo

[Paolo F Cantoni]

Just got back to this again...

When you select [X] Merge State with Instance name, the state is immediately abutted with the name.  This causes wrap propblems.  Perhaps the leading "[" could be added as a wrapping point?

Actually, if the name already contains a space, then there should be a space prior to the "[".  Even better, an [  ] Add space separator checkbox would be better still (Defaulting to true of there's already a space in the Object name.

Thoughts? Votes?
Paolo

[size=0]©2007 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

Perhaps the leading "[" could be added as a wrapping point?

I like this option best; I don't want to think about wrapping issues and check boxes as I develop a model.