Modeling Calls between operations

[tweber]

I have a need to show a call from one operation (owned by class1) to another operation (owned by class2).  The diagram shows class1 and class2.  I've tried dragging the operations from each class onto the diagram, but neither shows any relationship to the class that owns it, and choices of connection don't include association (the closest is 'usage', but I would prefer 'call').  I've also created classes, stereotyped them as EAUML::function, made them children of their respective classes, and dragged them onto the diagram.  Even though they are children, they do not show as strong <<aggregation>>s, unless I actually create a 'Composition to Whole' relationship. I'd appreciate any suggestions.

[PDC]

I assume you are using a Sequence Diagram. In which case it doesn't really make sense to represent Operations as lifelines. Lifelines are intended to be typed by a Classifer, and I think the UML spec is restrictive that those classifiers do not (cannot) include Operation as a classifier for the lifeline. That semantic distinction is probably why SysML tools (like EA) don't support what you are trying to show (Operations as lifelines) and is probably why you're struggling to get it to represent that way.

One solution could be to model your Operations as Classes (Blocks) and then you will be able to have lifelines that represent your Operations. You'd need some kind of Relationship between your 'Operation' pseudo-Block and the actual Block that owns the associated Operation... but it probably also depends on exactly what you are trying to communicate, who you are communicating to and how bothered they are about syntax & semantics.

[tweber]

Sorry, Phil.  I was using a class diagram.  I have yet to find a way to attach an image to this post.
I may be able to show my issue better if I can figure out how to attach a screenshot.

[Geert Bellekens]

Sorry, Phil.  I was using a class diagram.  I have yet to find a way to attach an image to this post.
I may be able to show my issue better if I can figure out how to attach a screenshot.

Post an image on a public image hosting site such as imgur.com and then put the link here.

Geert

[tweber]

Here it is. Thanks for the feedback.
https://imgur.com/TzdNux3

[Geert Bellekens]

What you created are CallOperationAction, calling the operation you created them from.

There are a few ways to model behavior. Sequence diagram and Activity diagrams are the suited for this.

I don't think it's a good idea to try and mix structure and behavior aspects into one diagram, as you seem to be trying to do.
That's not how UML was conceived.

Geert

[tweber]

Understood.  It's interesting though that I can drag one of the operations of a class onto the diagram, and it does not show as a composed element (i.e., a strong aggregation). You're right that EA shows the dragged element as a called operation (action). I need to show associations between classes, but at the operation level.  Activity diagrams and sequence diagrams (and state machines) would show the correct relationships among called operations), but I am dealing with an audience with limited UML exposure.  Static (i.e. class) diagrams and stereotyped dependency or association connections are a bit easier to understand. 

[Geert Bellekens]

Understood.  It's interesting though that I can drag one of the operations of a class onto the diagram, and it does not show as a composed element (i.e., a strong aggregation).

No, it isn't. An action calling an operation owned by your class is not part of your class. It should be owned by the activity that owns the activity diagram.

And even it would be owned by your class, ownership is not expressed with a composition.
In fact ownership in EA is not expressed in diagrams at all, unless you create a nesting connector yourself.

Geert

[PDC]

There are a few ways to model behavior. Sequence diagram and Activity diagrams are the suited for this.

I don't think it's a good idea to try and mix structure and behavior aspects into one diagram...

ownership in EA is not expressed in diagrams at all, unless you create a nesting connector yourself

(slightly off-topic...)
Really good points. I often find that Allocate is useful here too.
Stakeholders/Managers etc often want the 'everything-on-one-page' view, but as Systems Engineers we still need to educate that SysML serves a particular purpose, and 'bending the rules' is sometimes useful but often just adds confusion. It's one of the big benefits and also big pitfalls of EA - it's super flexible and lets you bend the rules a bit, but we do have to be careful that what we end up with is still correct and meaningful (especially when we need the model to do even basic things for us like checking traceability, consistency, design queries, simulations....)

[Richard Freggi]

In UML you can't show operation messages (I think this is what you call 'calls') in a class diagram.
And messages are not constraints so they can;t be represented by associations.
Sparx EA supports UML, you must be proficient in UML to use EA.  Good place to start: http://www.uml-diagrams.org/