Eclipse Community Forums: Papyrus

Home » Modeling » Papyrus » Sequence Diagrams

Fri, 11 January 2013 04:25

Eclipse User

Consider this simple example:

I have a model with a class ClassA containing two instances of two different classes (say bObj:ClassB and cObj:ClassC).
ClassA provides an Operation (i.e. classAOperation(int param)) related to a Behavior specified by means of a SequenceDiagram.

Now the behavior consists of invoking an Operation of bObj:ClassB (i.e. classBOperation(int param)) and an Operation of cObj:ClassC (i.e. classCOperation(int param)).

I am wondering how to model, this very simple behavior, via SD.
The question is basically related to LifeLine.

According to the OMG spec. a Lifeline can only represent (Represents attribute) a ConnectableElement, which in my case are two and correspond to the ClassA Properties realizing the composition to a ClassB and a ClassC instance (bObj and cObj). The Problem is I also need to have a reference to the container of these connectable elements, that is to say the ClassA instance which is actually performing such emergent behavior. It is that instance which sends messages (related to the operation call) o to the bObj:ClassB and cObj:ClassC lifelines.
Also as this behavior corresponds to the ClassA:classAOperation(int param) invocation I also need to represents by means of a formal gate the classAOperation(int param) message. But again, as I can't mode the container Lifeline I can't see to which attach the classAOperation(int param) message end.

Re: Sequence Diagrams [message #999147 is a reply to message #999073]

Fri, 11 January 2013 07:52

Eclipse User

Hi, Andrea,

A Collaboration is a structured classifier in which you can create any
number of parts (owned attributes) to define ad hoc collaboration roles
for your sequence diagram. The interaction "behind" your diagram would
be an owned behaviour of the collaboration.

Classifiers can refer to the Collaboration via CollaborationUses as
part of their specification.

HTH,

Christian

On 2013-01-11 09:25:07 +0000, Andrea Sindico said:

> Consider this simple example:
>
> I have a model with a class ClassA containing two instances of two
> different classes (say bObj:ClassB and cObj:ClassC). ClassA provides an
> Operation (i.e. classAOperation(int param)) related to a Behavior
> specified by means of a SequenceDiagram.
>
> Now the behavior consists of invoking an Operation of bObj:ClassB (i.e.
> classBOperation(int param)) and an Operation of cObj:ClassC (i.e.
> classCOperation(int param)).
>
> I am wondering how to model, this very simple behavior, via SD. The
> question is basically related to LifeLine.
>
> According to the OMG spec. a Lifeline can only represent (Represents
> attribute) a ConnectableElement, which in my case are two and
> correspond to the ClassA Properties realizing the composition to a
> ClassB and a ClassC instance (bObj and cObj). The Problem is I also
> need to have a reference to the container of these connectable
> elements, that is to say the ClassA instance which is actually
> performing such emergent behavior. It is that instance which sends
> messages (related to the operation call) o to the bObj:ClassB and
> cObj:ClassC lifelines.
> Also as this behavior corresponds to the ClassA:classAOperation(int
> param) invocation I also need to represents by means of a formal gate
> the classAOperation(int param) message. But again, as I can't mode the
> container Lifeline I can't see to which attach the classAOperation(int
> param) message end.

Re: Sequence Diagrams [message #999496 is a reply to message #999147]

Sat, 12 January 2013 03:49

Eclipse User

Hi Christian,
I guess you mean Communication Diagram. Actually the same thing holds for Communication diagrams as well as there is no way (at least it seems to me) to make a Lifeline representing the container instance, which is the one actually sending messages to its parts.
What am I doing wrong?

Re: Sequence Diagrams [message #999568 is a reply to message #999496]

Sat, 12 January 2013 08:46

Eclipse User

Hi, Andrea,

Communication diagrams are an alternative to sequence diagrams to
visualize an Interaction. My point was that you can create the
Interaction as an owned behaviour of a Collaboration instead of your
ClassA.

In the collaboration, create roles (owned attributes) of type ClassB,
ClassC, and ClassA. Then create an Interaction as an owned behaviour
of the collaboration and create lifelines for these roles.

Then create a CollaborationUse in ClassA that references the
collaboration and maps elements of ClassA to the collaboration's roles
using Dependencies referenced as the collaboration-use's "role
bindings".

HTH,

Christian

On 2013-01-12 08:49:31 +0000, Andrea Sindico said:

> Hi Christian,
> I guess you mean Communication Diagram. Actually the same thing holds
> for Communication diagrams as well as there is no way (at least it
> seems to me) to make a Lifeline representing the container instance,
> which is the one actually sending messages to its parts. What am I
> doing wrong?

Re: Sequence Diagrams [message #999606 is a reply to message #999568]

Sat, 12 January 2013 11:37

Eclipse User

Hi Christian,
It is exactly what I was looking for.
Thank you very much for your kind help and very detailed and useful explanation.

Andrea

Re: Sequence Diagrams [message #999659 is a reply to message #999606]

Sat, 12 January 2013 15:04

Eclipse User

I managed to do what you suggested.
I created two Role Bindings in CollaborationUse with dependencies. I used the Client attributes to refer to the ClassA.bObj and ClassA.cObj attributes while the Supplier attributes to refer to the related properties of the CollaborationUse. Is it correct?
Also, as I do not have an attribute for the ClassA instance I can't see how to bind the ClassA instance with the related property of the CollaborationUse.
I noticed the editor suggested me many alternatives to specify the binding:

- Abstraction
- ComponentRealization
- Dependency
- Deployment
- InterfaceRealization
- Manifestation
- Realization
- Substitution
- Usage

Should I always use dependency for this purpose or there might be cases in which another kind of binding is more appropriate?

thank you for your kind help

Re: Sequence Diagrams [message #999672 is a reply to message #999659]

Sat, 12 January 2013 15:50

Eclipse User

Hi, Andrea,

Yes, Dependency is the most appropriate type for a role binding. The
other metaclasses are subtypes of Dependency that have specific
semantics associated with them.

Yes, your role bindings as you describe them are correct.

A dependency can have any named element as a client, so I would think
that you could just bind the ClassA itself to the corresponding role in
the collaboration. Technically, this would be incorrect (there's a
well-formedness rule that requires the elements on both ends of the
role bindings to be ConnectableElements), but I don't know how else it
could be done. If your ClassB and ClassC ever need to send messages
back to ClassA (instead of just receiving messages), then they would
need either a variable of a property of type ClassA. These are both
connectable elements.

HTH,

Christian

On 2013-01-12 20:04:45 +0000, Andrea Sindico said:

> I managed to do what you suggested. I created two Role Bindings in
> CollaborationUse with dependencies. I used the Client attributes to
> refer to the ClassA.bObj and ClassA.cObj attributes while the Supplier
> attributes to refer to the related properties of the CollaborationUse.
> Is it correct?
> Also, as I do not have an attribute for the ClassA instance I can't see
> how to bind the ClassA instance with the related property of the
> CollaborationUse.
> I noticed the editor suggested me many alternatives to specify the binding:
>
> - Abstraction
> - ComponentRealization
> - Dependency
> - Deployment
> - InterfaceRealization
> - Manifestation
> - Realization
> - Substitution
> - Usage
>
> Should I always use dependency for this purpose or there might be cases
> in which another kind of binding is more appropriate?
>
> thank you for your kind help

Re: Sequence Diagrams [message #999676 is a reply to message #999672]

Sat, 12 January 2013 16:04

Eclipse User

Here is an excerpt of the UML spec 2.5 (beta-1)

The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.

It seems the problem is again about the need to refer to ConnectableElement.

My concern is about how to model this

ClassA {
  ClassB b;
  ClassC c;
  public void   classAOperation(int param){
     b.classBOperation(param);
     c.classCOpereation(param);
  }

}

I'd like to have a aObject:ClassA lifeline receiving a message from a formal gate referred to classAOperation invocation. Within the scope of this ActionExecutionSpecification it should call the other two lifelines operations.

It is quite strange we can't find the correct way to do that in UML Smile

Re: Sequence Diagrams [message #999896 is a reply to message #999676]

Sun, 13 January 2013 05:50

Eclipse User

Hi Christian,
there is stil something which does not convince me.

1. It seems there is a difference between Collaboration properties (attributes) and Roles. In Papyrus Composite Structure Diagrams it allows me to create connectors only between two properties BUT when binding a CollaborationUse (RoleBinding) it looks for CollaborationRoles. What am I doing wrong?

2. Also in the ClassA.classAOperation I can't specify a reference to a behavior (Method). Or should I specifiy the behavior defined in the used Collaboration?

Re: Sequence Diagrams [message #1000297 is a reply to message #999896]

Mon, 14 January 2013 08:04

Eclipse User

Hi, Andrea,

On 2013-01-13 10:50:30 +0000, Andrea Sindico said:

> Hi Christian,
> there is stil something which does not convince me.
>
> 1. It seems there is a difference between Collaboration properties
> (attributes) and Roles. In Papyrus Composite Structure Diagrams it
> allows me to create connectors only between two properties BUT when
> binding a CollaborationUse (RoleBinding) it looks for
> CollaborationRoles. What am I doing wrong?

There is no CollaborationRole metaclass. What do you mean by "it looks
for CollaborationRoles" ? If Papyrus is restricting the choice of
values to the connectable elements in the
Collaboration::collaborationRole list, then that makes sense to me.
There is a constraint that requires all suppliers of a
CollaborationUse's roleBindings to be roles of the Collaboration that
is the use's type.

But, there shouldn't be anything missing from the collaborationRole
list. It subsets StructuredClassifier::role, which includes all of the
owned properties.

> 2. Also in the ClassA.classAOperation I can't specify a reference to a
> behavior (Method). Or should I specifiy the behavior defined in the
> used Collaboration?

An Operation's method must be a behaviour owned by its context
classifier or some classifier that inherits it. It really shouldn't be
owned by some other classifier like a Collaboration, so it makes sense
that Papyrus wouldn't allow you to choose that.

Re: Sequence Diagrams [message #1000337 is a reply to message #1000297]

Mon, 14 January 2013 09:54

Eclipse User

Hi Christian,
you are right there are is no CollaborationRole metaclass. I thought that because of the presence of a CollaborationRole element in the Composite Structure Diagram palette. It actually refers to the Collaboration:collaborationRole list and when I try to graphically create one (CollaborationRole) it correctly allows me to chose one of the collaboration attributes. So what does it mean? Should I create one role for each attribute of the collaboration representing a participant? Isn't it redundant?
The OMG spec (2.5 beta-1)
The roles of a Collaboration will be played by instances when interacting with each other. Their relationships relevant for the given task are shown as Connectors between the roles.
Thus it seems connectors shall be defined between pair of roles. However the editor allows me to draw connectors only between two collaboration properties. Is it correct?

I agree an Operation shouldn't refer (via its method attribute) to a behavior not owned by the Classifier owning that operation. My concern is that if that operation is the signature of a behavior represented by a collaboration use it should be possible to link the two. How would you do that? It would be nice if CollaborationUse was a Behavior.

Re: Sequence Diagrams [message #1000593 is a reply to message #1000337]

Mon, 14 January 2013 23:13

Eclipse User

On 2013-01-14 14:54:26 +0000, Andrea Sindico said:

> Hi Christian,
> you are right there are is no CollaborationRole metaclass. I thought
> that because of the presence of a CollaborationRole element in the
> Composite Structure Diagram palette. It actually refers to the
> Collaboration:collaborationRole list and when I try to graphically
> create one (CollaborationRole) it correctly allows me to chose one of
> the collaboration attributes. So what does it mean? Should I create
> one role for each attribute of the collaboration representing a
> participant? Isn't it redundant? The OMG

That sounds odd. I should have thought the collaborationRole property
would be derived from the ownedAttribute (perhaps indirectly). Why
would one have attributes owned by a Collaboration that aren't
collaboration roles? That's the entire reason for adding attribtues in
the first place. I don't get it.

> spec (2.5 beta-1) The roles of a Collaboration will be played by
> instances when interacting with each other. Their relationships
> relevant for the given task are shown as Connectors between the roles.
> Thus it seems connectors shall be defined between pair of roles.
> However the editor allows me to draw connectors only between two
> collaboration properties. Is it correct?

Well, the properties of the Collaboration are the collaboration roles,
so yes, those are the things that you would connect using Connectors.
Connectors are required by Interactions to serve as "message pathways"
(I think that's the UML 1.x terminology from way back). Lots of
complexity for even the simplest of interaction models ... :-(

> I agree an Operation shouldn't refer (via its method attribute) to a
> behavior not owned by the Classifier owning that operation. My concern
> is that if that operation is the signature of a behavior represented by
> a collaboration use it should be possible to link the two. How would
> you do that? It would be nice if CollaborationUse was a Behavior.

The CollaborationUse isn't meant to specify the Behaviour of an
operation or class in the way that an owned behaviour can do. It's
more of an informative/documentation thing, as I understand it.

I wonder whether there's a way that you could introduce a "self"
Variable into the context of your operation, to serve as the
connectable element of type ClassA?

I'm sorry, but you've gone beyond my own personal experience with UML
modeling. I'm afraid somebody with more expertise in UML behaviour
modeling is needed here.

cW

Re: Sequence Diagrams [message #1005283 is a reply to message #999073]

Thu, 24 January 2013 14:25

Eclipse User

Hi you two,

maybe this is not relevant anymore, but technically the simplest solution
would have been to:

- create the interaction as owned behavior of ClassA
- create another lifeline for ClassA in addition to those for the properties
- label the additional lifeline with self!

This is at least the UML-compliant way. See the notation rules for lifelines
in UML 2.5 beta 1:

<lifelineident> ::= ([<connectable-element-name>[‘[‘ <selector> ‘]’]] [:
<class_name>] [decomposition]) | ‘self’
<selector> ::= <expression>
<decomposition> ::= ‘ref’ <interactionident> [‘strict’]

And the corresponding description:

"
If the name is the keyword self, then the Lifeline represents the object of
the classifier that encloses the Interaction that owns the
Lifeline. Ports of the encloser may be shown separately even when self is
included.
"

Anyway, I suspect that Papyrus is able to deal with such (self) lifelines
properly.

HTH,

Marc-Florian

"Andrea Sindico" schrieb im Newsbeitrag
news:kcolpj$2ki$1@xxxxxxxxe.org...

Consider this simple example:

I have a model with a class ClassA containing two instances of two different
classes (say bObj:ClassB and cObj:ClassC).
ClassA provides an Operation (i.e. classAOperation(int param)) related to a
Behavior specified by means of a SequenceDiagram.

Now the behavior consists of invoking an Operation of bObj:ClassB (i.e.
classBOperation(int param)) and an Operation of cObj:ClassC (i.e.
classCOperation(int param)).

I am wondering how to model, this very simple behavior, via SD.
The question is basically related to LifeLine.

According to the OMG spec. a Lifeline can only represent (Represents
attribute) a ConnectableElement, which in my case are two and correspond to
the ClassA Properties realizing the composition to a ClassB and a ClassC
instance (bObj and cObj). The Problem is I also need to have a reference to
the container of these connectable elements, that is to say the ClassA
instance which is actually performing such emergent behavior. It is that
instance which sends messages (related to the operation call) o to the
bObj:ClassB and cObj:ClassC lifelines.
Also as this behavior corresponds to the ClassA:classAOperation(int param)
invocation I also need to represents by means of a formal gate the
classAOperation(int param) message. But again, as I can't mode the container
Lifeline I can't see to which attach the classAOperation(int param) message
end.

Re: Sequence Diagrams [message #1005294 is a reply to message #1005283]

Thu, 24 January 2013 14:47

Eclipse User

Hi, Marc-Florian,

Thanks! That is good information to have. However, this does mean
that the lifeline ends up without a 'represents' association to some
connectable element. That is an unfortunate asymmetry, but is probably
not too difficult for a tool that analyzes the interaction model to
interpret.

cW

On 2013-01-24 19:25:18 +0000, Florian Wendland said:

> Hi you two,
>
> maybe this is not relevant anymore, but technically the simplest
> solution would have been to:
>
> - create the interaction as owned behavior of ClassA
> - create another lifeline for ClassA in addition to those for the properties
> - label the additional lifeline with self!
>
> This is at least the UML-compliant way. See the notation rules for
> lifelines in UML 2.5 beta 1:
>
> <lifelineident> ::= ([<connectable-element-name>['[' <selector> ']']]
> [: <class_name>] [decomposition]) | 'self'
> <selector> ::= <expression>
> <decomposition> ::= 'ref' <interactionident> ['strict']
>
> And the corresponding description:
>
> "
> If the name is the keyword self, then the Lifeline represents the
> object of the classifier that encloses the Interaction that owns the
> Lifeline. Ports of the encloser may be shown separately even when self
> is included.
> "
>
> Anyway, I suspect that Papyrus is able to deal with such (self)
> lifelines properly.
>
> HTH,
>
> Marc-Florian

-------- 8< --------

Re: Sequence Diagrams [message #1005302 is a reply to message #1005294]

Thu, 24 January 2013 15:14

Eclipse User

Thank you very much!
it also says at page 607

If the name is the keyword self, then the Lifeline represents the object of the classifier that encloses the Interaction that owns the Lifeline. Ports of the encloser may be shown separately even when self is included.

Re: Sequence Diagrams [message #1005305 is a reply to message #1005302]

Thu, 24 January 2013 15:24

Eclipse User

In the LifeLines' constraints at page 660 I would add

inv: self.name='self' implies self.represents.isEmpty()
inv: self.name<>'self' implies self.represents.notEmpty()

What do you think?

Previous Topic:	ActionExecutionSpecification vs. BehaviorExecutionSpecification
Next Topic:	Message Arguments

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 11:44:04 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter