SysML: Best practices regarding Activities and Actions

[Arne Krüger]

According to my understanding so far the interaction between Activities are expressed by placing Actions classified by Activities (Activity instantiations?) on Activity Diagrams and connecting these with object and control flows. EA seems to support this approach; when I drag an Activity into an Activity Diagram the default is to instantiate a Call Activity Action classified with the dragged Activity. When the Activity Diagram is the Composite Structure Diagram of a parent Activity the created Action is nested into the parent. When I drop into a standalone Acitvity Diagram the Actions are created in the parent package.

Tracing between activities, actions and activity diagrams is straight forward: Activites list all their instatiations as "is classifier of <Actions>" and individual Actions are likewise linked to their classifying Activities via "instance of <Activity>" and their parent Activity Diagram via "owned by <Diagram/Package>" in the Traceability window.

However, suppose a certain activity is used in several contexts, that is appears in multiple Activity Diagrams: should there be multiple Call Activity Actions classified with the Activity scattered over multiple diagrams or should I keep the Actions in a separate package tree - essentially one instance per acitivity - and pull those into Diagrams as required?

[Geert Bellekens]

Arne,

An action is always local to it's owning Activity and cannot be used in multiple places.
The each have there unique set of incoming and outgoing relations. If you start using shared actions you end up with the same problem as when you would use Activities directly on an Activity Diagram.

I wrote an article about this subject  a while ago: https://bellekens.com/2012/12/09/uml-best-practice-there-are-no-activities-on-an-activity-diagram/

Geert