8.0 Sequence diagrams, message property changes.

[ChrisBD]

Say that you have a classifier with a number of operations and it is used on a sequence diagram.

If an operation is deleted from the classifier and it is also used by one of the messages within the sequence diagram no warning is shown on operation deletion that it is used elsewhere nor is the diagram flagged as needing a change. The message remains with a label for the operation that no longer exists.

Neither project integrity checks nor model validation flag up that the message is using an operation that no longer exists either.

[Paolo F Cantoni]

Please submit a Registered Bug Report or Bug Report and tell us the name,
leaving a note here to say you've done it.
We users can then vote for it using a Registered Bug Report or Bug Report with the same name[/color]

Paolo

[ChrisBD]

Okay.
I didn't realise that I need to post here for "voting", but I've sent a Registered bug report titled:
"Handling of referenced classifier operation deletion"
that details what I've posted above.

[Paul Lotz]

I agree this is important, and I submitted a registered bug report as a "vote" as well.

I think that messages (sequence diagrams) and triggers (statemachine diagrams) should be capable of linking to signals (either elements typed as Signals or elements typed as Classes with the <<signal>> stereotype) or operations (which may also really be receptions--that is, they may have a <<signal>> keyword) and that it should be possible that a change in one place should update all the others.

In particular, for a publish-subscribe system, it should be possible to make the signal definitions the masters, so that if one adds an attribute (for instance) to a signal, the messages and triggers and the receptions on all the receivers should update.

Paul

[Paolo F Cantoni]

Okay.
I didn't realize that I need to post here for "voting", but I've sent a Registered bug report titled:
"Handling of referenced classifier operation deletion"
that details what I've posted above.

Hi Chris,

Neither did we (users) until recently.  There is no other mechanism for users, collectively, to indicate support for a feature or bug.

Make of that what you will...

Paolo

[KP]

I didn't realise that I need to post here for "voting"

You don't need to. Feel free to add your support to feature requests that other users make - Sparx do take into account the volume of support when deciding which new features we are going to implement - but "voting for bug reports" is unnecessary.

[SomersetGraham]

+1

[Paolo F Cantoni]

You don't need to. Feel free to add your support to feature requests that other users make - Sparx do take into account the volume of support when deciding which new features we are going to implement - but "voting for bug reports" is unnecessary.

Since there are many serious bugs reported over many years still outstanding, how can users influence which defects get fixed and which don't?  Decisions are being made "in smoke filled rooms, by unelected participants" (reference to an Australian political taunt).  

I'm not denying Sparx's right to decide when and where to fix defects - but if they care about user opinion, they should provide a mechanism for user input into the decision.

Paolo

[PhamNuwen]

In general, model validation should include the capability to check that all objects have a classifier and that all messages to objects of a given class are supported by that class.  This was a feature of Rose going back over decade ago.  (Setting the classifier should be a standard option - not one hidden under "Advanced".)

I submitted a feature request for this in 2008 - to no avail. So, I created a work-around by saving the project to an XMI file and writing an XSLT script to apply the above rules.   I will share the XSLT with anyone that is interested.

Convergence to zero warnings from these rules is a good (partial) metric for determining if the class design is nearing completion.