Action as Activity instance?

[Paolo F Cantoni]

For reasons which I won't go into here, I needed to create and "instance" of an Activity.  This may or may not be strict UML - that isn't the issue (at least not directly).

I created an activity and used <context menu>|Advanced|Convert to Instance and got an Action.

My quick read of the UML Superstructure didn't suggest that to me.  I must admit, I thought actions were just non-decomposable activities which therefore had restricted semantics which allowed the specification of atomic behaviour.

Before I report is as a bug, I'd appreciate any thoughts on the matter.

I can reset the "instance" to an Activity through the UI and thereby get the  <context menu>|Advanced|Show Classifier Properties [Ctrl+Alt+Enter] to get me back to the base activities.  So I CAN create an instance of an Activity which IS an Activity.

So is it a bug or not?

Paolo

[Geert Bellekens]

Yesterday I digged (doughed?, dought?, whatever the past sentence is for to digg) in the the uml spec to find out more about Activities and Actions, and I can understand why EA considers an action as an instance of an Activity.
from the UML 2.2 superstructure:

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).

So this means to me that Activities are the definition (Classifier?) and the Actions are the invocations (instance?) of that Activity.
If we follow this logic maybe we should not be using Actitivies in Activity diagrams at all, but only actions that invoke an Activity.

Geert

[Oliver F.]

So this means to me that Activities are the definition (Classifier?) and the Actions are the invocations (instance?) of that Activity.
If we follow this logic maybe we should not be using Actitivies in Activity diagrams at all, but only actions that invoke an Activity.

Well, for me that sounds more like a generalisation from a metaphoric level. Before we let it go confusing:
The statement from the superstructure tells us that an activity is a compund item which is built from actions as atomic entities.
A call behavior action can be refering to an arbitrary activity which means the execution of the whole activity including all of its actions.

Say activity A with actions a1,a2 and a3 and avtivity B with b1,b2 and b3. If b3 calls A, then a1, a2 and a3 are executed. If B3 calls a2 then only a2 is executed.
I do not see much room for interpretation about declarations and definitions though I'd also be glad to be proven wrong.

Oliver

[Geert Bellekens]

To be clear. I'm not saying Actions are instances of an Activity (I'm still nog 100% sure, but I doubt it). All I'm saying is that I can understand why EA chose to treat them this way.

Geert

[Paolo F Cantoni]

To be clear. I'm not saying Actions are instances of an Activity (I'm still not 100% sure, but I doubt it). All I'm saying is that I can understand why EA chose to treat them this way.

Geert

Sorry Geert, I don't agree that that that quote (which is the one I read) allows EA to come to the conclusion that Actions are instances of Activities.

All the section says to me is that OMG found a way to make some things atomic in one context and compound at another.  Now, don;t get me wrong, I think this is a marvellous thing...  All it says (to me) is as you descend the levels of composition in one context, you eventually get to the "atoms. for that context.  There's no point (in that context) in considering behaviour below that level.  However, just like real atoms are composed of sub-atomic particles, some of those behavioural atoms may, in fact be composed themselves.  You handle this by a CallBehaviour action which calls out to another Activity.

I don't think it says any more than that.  Certainly nothing, to me, is implied about Actions being instances of Activities.

My AU$0.05
Paolo

[NeilS]

I admire Geert for wheeling out the superstructure spec but for the sake of clarity I usually resort to the UML reference manual.

Here an action is described as "primitive activity node.... " and (p136)  - I don't see how you can imply instantiation.
Its there to flesh out detail.

So I think Paolo is correct

Being pragmatic however the key thing is whether the audience understands the diagram!

Neil

[«Midnight»]

I have to weigh in with Paolo about the semantic interpretation.

But the other point is valid too. If you cannot get the information across to your audience - this holds true whether the audience is human or automated - then all may be lost.

As with so many things UML gives us the tools, but does not protect us from the results of poor usage.

[Paolo F Cantoni]

So...

Could a Sparxian jump in with the rationale behind the current behaviour?

I still haven't reported it, so I'll wait one more day and then do it - to allow Sparx to explain.

It's causing me quite some grief.

I've come to the conclusion that EA's support for instances (such as might be used in Instance Models) is spotty at best and embryonic in most cases.

See my various postings as I try to create such instance models.

Paolo

[Paolo F Cantoni]

By chance, I was in another part of EAUI and I think I've found the reason why the Action as Activity Instance bug (yes, , it is a BUG - because of this discovery) came about.

If you drag an activity onto a diagram you will get EITHER a Simple Link or an Invocation (Action) - depending on how the Drag and Drop dialog has been configures (Use Ctrl+Drag to check).

Now I surmise someone in Sparx has conflated (and possibly confused) Invocation with Instance.

For the Drag and Drop functionality it should be ONE OF:
Create a NEW:
(*) Simple Link
( ) Invocation (Action)
( ) Instance

Similarly: for the context menu:
Create a NEW:
( ) Invocation (Action)
( ) Instance

Since (as I've noted elsewhere) "Convert" is not the appropriate name for what is happening here - a NEW t_object row is being created.

Reported,
Paolo

[Geert Bellekens]

I agree that the invocation (Action) will lead to much less confusion than the "instance" option.
On the other hand I'm not entirely sure what an instance of an activity would be (on the functional level). When, how and why do you use an instance of an Activity? And in those cases, wouldn't it be better to use an invocation (Action) of this activity?

PS. Im not trying to start another discussion about this, I genuinly don't know what to think of an Actity instance.

[Paolo F Cantoni]

[size=18]...[/size]

PS. I'm not trying to start another discussion about this, I genuinely don't know what to think of an Activity instance.

(Come close... I'm going to let you into a secret...)

I'm not sure either... Except that, since I model anything and everything and I have used instances to get me around other EA brick walls.  I can conceive of needing an instance of activity with one stereotype and another with a different stereotype to get different renderings.  Since EA has conflated rendering with stereotyping (since in EA you can ONLY apply rendering on a consistent basis if you apply a stereotype - that shouldn't be the case) If I need to render the same element in many different ways I may need this capability.

OK, secret's out, back to...

It's WRONG to equate invocation with instance.  Now please be clear, I'm NOT complaining about the creation of call actions that reference the activity.  I'm saying the bug is EAUI - it's the UI that's wrong, not the item created.

Paolo

[Geert Bellekens]

I'm happy I'm not alone.

So actually there are two thing involved here.
1. The wrong description of the "create instance(Action)" which should read "create invocation(Action)" which is clearly a bug and should be easy to fix
2. The option to create an instance of an Activity (in a convenient way). It seems that this functionality is not present at the moment.
You can however always create an object and set the Activity as it "instance classifier", effectively creating an instance of an Activity.

Geert

[«Midnight»]

OK, now we're making progress.

It's time to get Sparx into the loop on this one. But...

...with the rationale behind the current behaviour?...

IMHO the above assumes facts not in evidence.

[Paolo F Cantoni]

I'm happy I'm not alone.

So actually there are two thing involved here.
1. The wrong description of the "create instance(Action)" which should read "create invocation(Action)" which is clearly a bug and should be easy to fix
2. The option to create an instance of an Activity (in a convenient way). It seems that this functionality is not present at the moment.

I've received the following from Sparx:
In regard to the "Create Instance (Action)" reference.  We agree that it is bug (it should be "Create Invocation (Action)", as you mentioned) and have logged it to be fixed.  I have submitted a feature request for the option to create Activity Instances also.

So that's the first two covered...

You can however always create an object and set the Activity as it "instance classifier", effectively creating an instance of an Activity.

Geert

If you start off with an object, and then you set the classifier to something other than a class, you still get an Object instance (as of build 848.).  You need to start off with an Activity to end up with an Activity instance.

Now, from a UML point of view, it could be argued that changing the classifier type of an Instance should change the type of the Instance.

This would improve EA's rather anaemic support for Instances - recently lamented by David <Midnight>.

Thoughts? Votes?
Paolo

[Geert Bellekens]

still[/b] get an Object instance (as of build 848.).  You need to start off with an Activity to end up with an Activity instance.

Now, from a UML point of view, it could be argued that changing the classifier type of an Instance should change the type of the Instance.

This would improve EA's rather anaemic support for Instances - recently lamented by David <Midnight>.

Thoughts? Votes?
Paolo

Paolo,

I've just looked in the UML specs and there is actually no such thing as an Object. (at least not that I can find)
What looks most like the Object in EA is the InstanceSpecification. This represents the instance of a classifier.
Activities are classifiers.
If indeed EA's Object represents the UML concept InstanceSpecification then an Object with a classifier of type Actitivity is in fact an Activity instance completely by the book.

What do you think?

Geert