activity on act. diagram not under diagram in proj

[Paul Lotz]

Place an action on an activity diagram.  Make the action complex so that EA creates a new activity diagram (for detailing the action) beneath the action in the project hierarchy.  On this new diagram add an activity (common in the case in which we want to show object flow).  The new activity does not appear associated with the diagram in the project.  (Instead, it appears at the root level for the package.)  I think this is a bug.  (If we use activities instead of actions this is not the case, by the way, but I think it is more correct to use actions.)

[KP]

The UML 2.1.2 Superstructure says:

An action represents a single step within an activity, that is, one that is not further decomposed within the activity. An activity represents a behavior that is composed of individual elements that are actions. Note, however, that a call behavior action may reference an activity definition, in which case the execution of the call action involves the execution of the referenced activity and its actions (similarly for all the invocation actions). An action is therefore simple from the point of view of the activity containing it, but may be complex in its effect and not be atomic.

Which is saying that if you want to define your action in greater detail, define an activity and make your action a call behavior action that references it. To do that, right-click the action and select "Advanced > Custom Properties" and set "kind" to "CallBehavior".

HTH

[Paul Lotz]

I read that in the specification.  I see that I do need to change the action to call behavior, but I don't see how it helps resolve the particular issue, though.  Not sure if it's me.

Let me give an example.  (I wish I could post a project file, but I will include some images instead.)

Suppose we want to indicate how we would do configuration using object flow.  Then we might set up a ConfigureSystem Activity like so:
.
We need to further define what happens in the EditConfiguration action, which we can do thus: .
In practice I chose to made the original EditConfiguration action composite, which created a new activity diagram under the EditConfiguration action, but when I added an EditConfiguration activity to the EditConfiguration activity diagram, the EditConfiguration activity was not associated with the diagram but appeared in the package root: .
At least double-clicking on the EditConfiguration action does bring up the EditConfiguration activity diagram.
I tried creating a new action that was a call behavior linked to the EditBehavior activity (behavioral classifier).  This may be correct, but I still see problems here: 1) There is no hierarchy in the project for activitiees; 2) double-clicking on the new action does not bring up the EditConfiguration activity diagram--although I presume I could force it to do so by making it composite and moving the diagram, and 3) most importantly, the EditConfiguration activity still has no connection to the activity diagram on which it resides in the project.  I think the last is the biggest issue.  Why can't the EditConfiguration activity reside with the EditConfiguration diagram in the project?

[Frank Horn]

Why did you create an instance "Action1" of the EditConfiguration activity?

What I do in such cases is this:

1. Make the EditConfiguration activity composite.
2. Into the EditConfiguration diagram which is then created, drag the EditConfiguration activity (as simple link, not as instance).
3. Resize the EditConfiguration activity in the child diagram so that it fills most of the page (leavig space for common objects and activities to be placed outside and called from inside it).
4. Draw new ConfigureSubsystem1 a.s.o activities inside the EditConfiguration activity on the child diagram.

This should lead to the hierarchy in the project browser that you want.

[«Midnight»]

Frank,

My guess is that Paul is questioning the behavior of EA when he just creates the composite and adds the action.

I really don't have enough of a feel for this to wade in yet, and your (Frank's) solution works well. But there is some whisper of inconsistent behavior in the placement of elements - in the Project Browser hierarchy - here. This makes me nervous...

It might well be that this is completely 'normal' given the UML specification. If so, it would be good to see the 'different' behavior of EA clearly documented. It would also be nice to see a list of cases where similar 'different' behavior occurs, and the appropriate references to the UML specification for each. This consolidated list could appear in the EA documentation under the Composite Element section.

David

[Paul Lotz]

Why did you create an instance "Action1" of the EditConfiguration activity?

What I do in such cases is this:

1. Make the EditConfiguration activity composite.
2. Into the EditConfiguration diagram which is then created, drag the EditConfiguration activity (as simple link, not as instance).
3. Resize the EditConfiguration activity in the child diagram so that it fills most of the page (leavig space for common objects and activities to be placed outside and called from inside it).
4. Draw new ConfigureSubsystem1 a.s.o activities inside the EditConfiguration activity on the child diagram.

This should lead to the hierarchy in the project browser that you want.

Thanks, Frank.  The distinction I am trying to make is that I am detailing an action, not an activity, via an activity diagram.  This should be legal (and more proper!) in UML but EA doesn't maintain the hierarchy as I would expect.

[I am finding the distinction between activity and action in UML to be not all that meaningful.  My interpretation is that an activity should generally be composed of actions, which in turn can be detailed in further activity diagrams.  An activity diagram may have activities on it when we detail a complex structure containing multiple actions--rather than putting it in a subdiagram, but anything "atomic" on the current diagram should be an action.  (An action isn't necessarily really atomic since it can be broken down with arbitrary complexity on a separate diagram).  If there is a more accurate interpretation I'd love to hear it.]

[«Midnight»]

You've got the correct flavor Paul.

This looks like a place where legacy has dictated some of how UML handles the two element types. One goal of UML 2.x was to preserve downward compatibility in the absence of compelling contrary reason.

Some users or domains may still find it important to make the distinction. This could be particularly true in areas like modeling business practices. Though UML still has strong roots in object oriented software design, its scope has become much wider over the past decade.

Just my 0.02 FWIW,
David

[Paul Lotz]

Frank,

In practice using subactivities on an activity diagram in EA as you suggest seems to offer a number of advantages (maintenance of hierarchy, as well as ease of using embedded activity parameters).  So thanks!

What makes me nervous is:
1) From what I can tell (and I haven't found a great definition, but what I glean from the UML spec. and other sources follows) actions should work as subactivities currently do.  In other words, we should be using actions instead of subactivities (except where I noted in my previous message) and the actions should provide the same hierarchical and object flow advantages currently sported by subactivities.  I suggest the action behavior is incorrect and EA will want to fix this.
2) I don't think it is possible to convert an action to an activity or vice versa in EA, so it would be painful to start with one and then switch to the other after the fact.
3) The hierarchy is maintained well using subactivities but I wonder if pasting a linked copy of a subactivity on its subdiagram and then adding parts to it is semantically correct (I don't know the answer to this one--the inserted parts have no semantic link to the pasted link, but I suppose the pasted link functions much like a diagram frame--otherwise missing from EA, would function), although it certainly does the trick graphically.

Anyway, despite my misgivings, this seems to be the best approach currently available in EA and I will try working with it.  Thanks for your advice!

Paul

[Paul Lotz]

Here is another problem (I was afraid of this) that occurs with the subactivity link method.  If I drag an activity (paste as simple link) onto the activity diagram for the host activity and drag it onto the activity element for the host activity, then the subactivity moves below the host activity in the project (which seems proper).  Now often this is what I want, but it is not desired if the subactivity is used in multiple places (which happens, for instance, if I have factored out common behavior from a high-level use case, which is good design).

The alternative is to opt to paste the activity as an invocation of the activity (Action) which is where we were before.  At this point I would expect that we would be able to show any embedded elements (esp. activity parameters) in the invoked activity as action pins on the action, but unfortunately this is not the case.  Moreover, the action should be linked to the invoked activity, but it is not.  So we are back to the same basic issues.

[Frank Horn]

Paul,

I don't think it's as bad as you think.

1. If you drag common elements not inside the activity using them, but  beside it in a diagram, they will not move in the hierarchy. And why should they be inside when they have been factored out?

2. You can convert an activity to an action and vice versa using the "Element-Advanced-Change Type" menu.

2. When you make an action composite, drag it into it's child diagram as simple link, and create more actions inside it, the hierarchy will be as expected.

But now that I'm trying it out, I see that we have unclear terminology here. There's an "action" element which cannot be converted to an instance, and there's an "activity" element the instances of which are called "actions" as well (or "invocations" or whatever). What you have on your diagram as "Action1:EditConfiguration" is the latter.

Making this composite will not cause EA to put elements dragged inside it on the child diagram below it in the hierarchy. This simply does not work for instances.

And you cannot convert it to an activity (as opposed to instance of activity) anymore, because the activity (it's classifier) is already there.

Anyway, I think there is some logic to it. Why would you want to put details into the INSTANCE of an activity? There can be a definition (with diagrams and all) for the inner structure of an activity which shows all these, once and for all. Instances of this activity just represent invocations of it and need no further details except parameters passed and returned.

I hope this makes some sense. I'm no expert on UML specifications; only trying to make the most out of EA with as little editing effort as possible.

Frank

P.S.
David, I don't think EA is behaving inconsistently here, but simply doesn't expect us to drill down with composite instances.

[«Midnight»]

...
David, I don't think EA is behaving inconsistently here, but simply doesn't expect us to drill down with composite instances.

Not a big issue I agree. My point was basically that it would be better if Sparx would document such cases where EA makes assumptions about what we will and will not do, and uses those to modify its 'normal' behavior. As long as these are not documented the behavior is indistinguishable from a bug.

[KP]

I have replied to Paul through the support channels, but to bring this thread up-to-date, here's my answer...

The answer to the question "Why can I nest Actions beneath Activities in the project browser but I can't nest Activities beneath Actions?" is that such nesting equates to ownership, and UML Activities can own UML Actions^[1], but UML Actions can't own UML Activities. The EA project browser strictly adheres to this rule and there is no work-around.

The answer to the problem of wanting sub-activities to appear in more than one place in the project hierarchy is that they probably need to be activity instances (i.e. call behavior actions) rather than activities.

Finally, your comment "I am finding the distinction between activity and action in UML to be not all that meaningful". The way that I look at this is that nothing actually happens in an activity - it's a definition of what _can_ happen. An action is an invocation of the activity, and can occur in many different places with potentially a different outcome on each invocation depending on the inputs and the context of the call.

------------
^[1]section 12.3.4 on page 317 [of the UML 2.1.2 Superstructure] shows Activity has the association "node:ActivityNode [0..*]" which subsets Namespace::ownedElement. Action has the generalization ActivityNode.

[Paul Lotz]

1. If you drag common elements not inside the activity using them, but  beside it in a diagram, they will not move in the hierarchy. And why should they be inside when they have been factored out?

2. You can convert an activity to an action and vice versa using the "Element-Advanced-Change Type" menu.

Frank, you are correct.  Factored-out parts don't belong low-down in the hierarchy.  That was my mistake.  So yes, I think things in that respect are the way they should be.  I just need to understand the existential underpinnings of activities and actions, and Neil has given some good guidance there.

And thanks for the Change Type information.  I thought maybe I had seen it somewhere but couldn't find it when I was writing my previous message.
---

I think I'm (slowly) getting it.  Many thanks to Frank, David, and Neil for providing the answers!!!

Paul