Action vs Activity (and relationships)

[Modesto Vega]

I thought I had read a recent thread on this subject but I cannot find it and do not want to reopen this rather old thread https://sparxsystems.com/forums/smf/index.php/topic,17135.msg169988.html#msg169988.

According to https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_domains/controlflow.html

The Control Flow is a connector connecting two nodes in an Activity diagram, modeling an active transition. Control Flow connectors bridge the flow between Activity nodes, by directing the flow to the target node once the source node's activity is completed.

The issue is that Sparx EA v15 (build 1560) does not allow connecting two activities through a control flow (or object flow or interrupt flow). None of them are options in the quicklinker menu or, according to Sparx EA, a UML compliant connections. After some testing, it appears that the activity looking elements in https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_domains/controlflow.html, are actually actions (and not activities).

Are they really a relationship not compliant with UML?

The closest I can get to the diagram I want to draw is to use dependencies but, of course, this involves drawing the diagram the wrong way around. For example, if activity A is followed by to activity B - i.e., if control is handed over to activity B by activity A- this means that activity B depends on activity A or to visualise it:

Activity A ------Control Flow------->Activity B
instead of
Activity B -------Depends-----------> Activity A

The only way to draw the diagram I want, without using a custom MDG, is to draw the dependencies correctly - i.e., with the right source and destination - and reverse the directionality, which is a bit awkward to say the least.

Can anybody think of another way of achieving the desire result?

P.S.: I am trying to draw a high level activity diagram before breaking down the activities into further detail.

[qwerty]

It's no issue that you can not connect Activities. It is not allowed per UML spec and for good reason. Activities own Actions or Activity Instances (which are Actions having the kind CallBehavior). ControlFlow is only allowed between Actions, Merge, Decision, etc.

You might define a profile for your purpose. I did that once for an ARIS import where you also have those high/low level activities.

q.

P.S. See also https://stackoverflow.com/questions/60223963/cant-connect-activities-in-activity-diagram-in-ea

[Modesto Vega]

Thanks Thomas, I don't think that Sparx EA being UML compliant is a bad thig and, therefore, I am fine with not being able to connect activities via a control flow. Happy to use actions for that.

However, if you take the examples in https://stackoverflow.com/questions/60223963/cant-connect-activities-in-activity-diagram-in-ea, you could argue that the actions modelled there are part of the Checkout activity. But the checkout activity is certainly something that does not happen in isolation. It is preceded and succeeded by other activities - e.g., Shop, (Order) Fulfilment, (Order) Return and so on.

What I am after is a diagram that looks like

Shop ----> Checkout ----> (Order) Fulfilment --(optional)--> (Order) Return

If I use an Activity element to represent shop, checkout, (order) fulfilment,  and (order) return, the only way I can think of drawing the above diagram is by using dependencies between activities and

• either drawing them the wrong way around -  i.e., Shop (source) ---Depends on---> Checkout (destination), or
• drawing them the right way Checkout ---Depends on--->Shop (but draw the arrows the wrong way around).

[Geert Bellekens]

Can anybody think of another way of achieving the desire result?

P.S.: I am trying to draw a high level activity diagram before breaking down the activities into further detail.

Yes, use CallBehaviorActions that call the Activities.
It would be wrong to link the actual activities simply because they are executed in a certain sequence in a certain scenario.
You would get into serious issues if in another scenario they are executed in another sequence. (because links would appear on other diagrams)

The activities themselves are independent (unless they call another activity, but that's another case) and don't need to know about eachother.

Geert

[Modesto Vega]

Geert, I think we just crossed posts.

I can see why it would be advantageous for the activities to be defined independently of how they are orchestrated. Although, in the example I posted just before your reply, I am bit hard pressed to see any other way to orchestrate those 4 activities.

I also think, that to make my mind on how to draw this, it is worth considering the following 1) activities calling other activities, 2) when to jump from the generic (activity) to the concrete (action), and 3) whether an activity can/should have one or more Initial or Final control node.

[Eve]

I also think, that to make my mind on how to draw this, it is worth considering the following 1) activities calling other activities, 2) when to jump from the generic (activity) to the concrete (action), and 3) whether an activity can/should have one or more Initial or Final control node.

1) That's a call behavior action.
2) Not sure what you're after here. A UI action to allow you to find all call behavior actions calling an activity?
3) Yes. All activities should have an initial node and one or more final nodes.

[qwerty]

The final notes are not needed since an action without outgoing edge will swallow its token when done (and thus end the path). (That's something I learned only recently from a question on SO.)

I'm not that sure about an implicit start (would need to check that) but honestly, there shall be at least a single start edge to get the reader of the diagram aboard. Without it would be search and guess. So, just to be safe, add at least on starting node. Honestly I also never really had two starting nodes but that should be possible. Makes things harder to understand since there would be two triggers and you would not know which one fires when except you adorn the with notes. (Will try to investigate if I don't forget...)

q.

[Modesto Vega]

Adding more detail to

2) when to jump from the generic (activity) to the concrete (action)

Let's expand the  Shop > Checkout > (Order) Fulfilment > (Order) Return example further and assume that we have both a physical and online store. We are going to have at least 2 activities under "Shop" (Shop in Store and Shop online) and 2 activities under "Checkout" (Online Checkout and Checkout in Store). We will end up with something like the table below where In Store Checkout depends/flows from on Shop in Store and Online Checkout depends/flows from Shop Online.

0	Shop	>	Checkout	>	(Order) Fulfilment	>	(Order) Return
1	Shop Online	>	Online Checkout	>	(Order) Fulfilment	>	Online (Order) Return
2	Shop in Store	>	In Store Checkout	>		>	In Store (Order) Return

Row 0 is the generic and row 1 and 2 are the concrete. It is clear that Shop Online and Shop in Store are not action, they are activities; in fact they are part of a higher level activity, Shop. In this case, should all activities we presented as CallBehaviorActions.

This should also provide some context about the need, at least theoretical, for more than 1 final node (and possibly more than one initial node).

[qwerty]

As follow-up to my above post: p. 376 of UML 2.5 says

However, nodes that do not have incoming edges and require no input data to execute are immediately enabled. A single control token is placed on each enabled node and they begin executing concurrently.

q.

[Geert Bellekens]

It is clear that Shop Online and Shop in Store are not action, they are activities; in fact they are part of a higher level activity, Shop. In this case, should all activities we presented as CallBehaviorActions.

Yes, these should be represented on a diagram as CallBehaviorActions.
That allows you to put them in any sequence you want, even repeating the same Activity multiple times (under different conditions) on the same diagram.

I'm not sure if it's valid (or a good idea) to have Activities owned by other Activities, but that doesn't even matter in this case. If you want to put them on an Activity Diagram, you use CallBehaviorActions; always.

Geert

[Modesto Vega]

[SNIP]
I'm not sure if it's valid (or a good idea) to have Activities owned by other Activities, but that doesn't even matter in this case.

Looking at the diagram in p. 374 of the Unified Modelling Language 2.5.1 specification. I think the answer is that it is not valid to have activities owned by activities. However section 15.2.3.7 (p. 379) is about activity generalisation, so I guess the "correct approach" will be to say that Checkout generalises Online Checkout and In  Store Checkout and that we could have an abstract activity without any ActivityNodes and ActivityEdges. Furthermore, that section states that "A specialized Activity inherits the nodes and edges of its general Activities. ActivityNodes and ActivityEdges are RedefinableElements (see sub clause 9.2) that may be redefined in a specialized activity").

The only thing I find confusing about the way Sparx Systems has implemented this is that Actions and all controls nodes are really ActivityNodes, as per the specification. They could have implemented as one element with multiple sub-types and renditions instead of multiple elements.

[qwerty]

That accounts for historical reasons (most likely). Similarly Object is no longer existent in UML as it is now InstanceSpecification. EA is not UML compliant...

q.

[Eve]

The only thing I find confusing about the way Sparx Systems has implemented this is that Actions and all controls nodes are really ActivityNodes, as per the specification. They could have implemented as one element with multiple sub-types and renditions instead of multiple elements.

Why would that approach be better?

Both EA and UML actually have a mix of these approaches in different places, although the exact examples of either do vary. ActivityNode is an abstract type, so you wouldn't expect to see it as a concrete type in an implementation of the specification. UML extends ActivityNode with Action as all nodes that do something and ControlNode to manage the flow. Each of the action kinds and control flow kinds is a specialized class. EA doesn't store it exactly like that, but the way it presents those elements in the UI and XMI is conformant. UML conformance has nothing to do with the implementation.

Interestingly, if you look at the PseudoState from State machines, they instead use the single metaclass that identifies a different subtypes. Even UML itself isn't consistent in the way it handles these things.

[Modesto Vega]

[SNIP]
Why would that approach be better?

Because it is closer to section 7 of the specification, "Common structure", and this is the section that describes the UML metamodel. The UML metamodel has not changed as much as other parts of the specification.

[SNIP]
ActivityNode is an abstract type, so you wouldn't expect to see it as a concrete type in an implementation of the specification.

You seem to be implying that because something is an AbstractClass in the specification, instead of a Class, it cannot be implemented as a "concrete" type. Furthermore, you also seem to be implying that if something is a Class in the specification a concrete type is required. This seems to be an arbitrary design decision and I wonder (and have wondered for a while) but impact it has in some of Sparx EA odd behaviour. Specially, if things get promoted to AbstractClass or demoted to Class because a new AbstractClass is introduced.

[Eve]

[SNIP]
Why would that approach be better?

Because it is closer to section 7 of the specification, "Common structure", and this is the section that describes the UML metamodel. The UML metamodel has not changed as much as other parts of the specification.

But that's not how sections 15 and 16 structure the specific classes being described. So no, an implementation of a single root class for all activity nodes with a kind would less like the specification than EA currently is.

[SNIP]
ActivityNode is an abstract type, so you wouldn't expect to see it as a concrete type in an implementation of the specification.

You seem to be implying that because something is an AbstractClass in the specification, instead of a Class, it cannot be implemented as a "concrete" type.

Yes. "Abstract" means it "can only be instantiated by instantiating one of its specializations".¹ EA implementing that behavior is not some arbitrary design decision on our part. Unless you consider the decision to base a UML design tool on the UML specification (back before UML 2 existed) to fit into that category.

Furthermore, you also seem to be implying that if something is a Class in the specification a concrete type is required.

Regardless of the implementation, you need to be able to create the concrete types. You don't need to be able to create the abstract types.

Specially, if things get promoted to AbstractClass or demoted to Class because a new AbstractClass is introduced.

I'm not  sure what you mean by promoted or demoted. Concrete classes can have specializations. In fact Class itself fits into that category. Class is a concrete class. Behavior is an abstract specialization of class. Activity and StateMachine are both concrete specializations of Behavior. The intention of UML is that you can create Class, Activity and StateMachine, but you can only create a Behavior by creating one of its concrete children.


¹ Unified Modeling Language, v2.5.1 9.9.4.5