Eclipse Community Forums: UML2 Tools » Defining Activity as the root element of ActivityD

Help

Home

Home » Modeling » UML2 Tools » Defining Activity as the root element of ActivityD

Show: Today's Messages :: Show Polls :: Message Navigator

Defining Activity as the root element of ActivityD [message #471238]

Fri, 06 July 2007 11:25

Philippe

Messages: 100
Registered: July 2009

Senior Member

Hi,

I know I already asked this question but I have new arguments about it.

my use case is simple:
A class can owns several Activities as ownedBehavior, I think it's the
good way to attach behavior to a class. But I really want to edit these
activities on diagrams, and I cannot do it for now because the root for
an activity Diagram has to be a package.

Providing the possibilities to see several activities on one diagram
seems not so important, a navigation link using the Behavior property of
a Call Behavior Action should be sufficient.

Several modelers have already clearly defined that activity has to be
the root element for an activity diagram and I think it's the good choice.

I'd like to have the opinion of others about it.

Regards
Philippe

Report message to a moderator

Re: Defining Activity as the root element of ActivityD [message #471246 is a reply to message #471238]

Tue, 10 July 2007 13:20

Tatiana Fesenko

Messages: 530
Registered: July 2009

Senior Member

Hello Philippe,

Could you specify advantages of Activity presentation as a root of a diagram
in full, please?
And of cource any other opinion on this topic is also very important for us.

Thanks,
Tatiana.

> Hi,
>
> I know I already asked this question but I have new arguments about
> it.
>
> my use case is simple:
> A class can owns several Activities as ownedBehavior, I think it's the
> good way to attach behavior to a class. But I really want to edit
> these
> activities on diagrams, and I cannot do it for now because the root
> for
> an activity Diagram has to be a package.
> Providing the possibilities to see several activities on one diagram
> seems not so important, a navigation link using the Behavior property
> of a Call Behavior Action should be sufficient.
>
> Several modelers have already clearly defined that activity has to be
> the root element for an activity diagram and I think it's the good
> choice.
>
> I'd like to have the opinion of others about it.
>
> Regards
> Philippe

Report message to a moderator

Re: Defining Activity as the root element of ActivityD [message #471252 is a reply to message #471246]

Wed, 11 July 2007 10:36

Philippe

Messages: 100
Registered: July 2009

Senior Member

Hello Tatiana,

I'll try to be as clear as possible and separate the advantages that I
see at having Activity as the root for an Activity diagram.

In my opinion, the greatest advantage of having Activity as a root of an
ActivityD is that one could really create a diagram from any activity in
its model file, independently on what owns the activity
In general an Activity can be owned by any Classifier, in practical use
an Activity can be owned by a Class as OwnedBehavior, or even by a
"parent" activity for using sub-activities in its definition.
The diversity of the possible containers could be an argument for
choosing the root of activity diagram, so why only package, why not any
classifier ?
As Activity is a behavior, I'm a little reluctant to link it to a
package that is more a structural element.
(In parallel, StateMachine is also a Behavior and a "root" element for
the StateMachineDiagram)

In response to one of your comment:
"Package is used as a root element of ActivityD because there may be
several activities in it. You can create as much activities as you want
in a single package. Fig. 12.36 from UML 2.1 is an example of such cases."

Having several activities in one package doesn't have to imply that an
activity diagram have to represents several activities along side.
Also from the UML spec:
"Actions have no further decomposition in the activity containing them.
However, the execution of a single action may
induce the execution of many other actions. For example, a call action
invokes an operation that is implemented by an
activity containing actions that execute before the call action completes."

I understand it as an activity has to be self-explanatory at its detail
level. As Package navigation, "Subactivity" navigation should be a good
thing but allowing to mix the details level on the same diagram seems
not so good.
I really don't find a case where two or more activities along side on a
diagram would be useful. If that the case, it would merely consist of
another activity diagram where we would mix plain activities and action
nodes.It appears one more time as a detail level mixing to me.
I come again to my conclusion: One diagram per activity seems to be the
good granularity choice.

I Hope that others can express their thoughts and maybe point me where
I'm wrong.

Thanks,
Philippe

Tatiana Fesenko wrote:
> Hello Philippe,
>
> Could you specify advantages of Activity presentation as a root of a
> diagram in full, please? And of cource any other opinion on this topic
> is also very important for us.
> Thanks,
> Tatiana.
>
>> Hi,
>>
>> I know I already asked this question but I have new arguments about
>> it.
>>
>> my use case is simple:
>> A class can owns several Activities as ownedBehavior, I think it's the
>> good way to attach behavior to a class. But I really want to edit
>> these
>> activities on diagrams, and I cannot do it for now because the root
>> for
>> an activity Diagram has to be a package.
>> Providing the possibilities to see several activities on one diagram
>> seems not so important, a navigation link using the Behavior property
>> of a Call Behavior Action should be sufficient.
>>
>> Several modelers have already clearly defined that activity has to be
>> the root element for an activity diagram and I think it's the good
>> choice.
>>
>> I'd like to have the opinion of others about it.
>>
>> Regards
>> Philippe
>
>

Report message to a moderator