| Sequence Diagrams [message #999073] |
Fri, 11 January 2013 09:25  |
|
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.
Follow me on Twitter @andreasindico
|
|
|
| Re: Sequence Diagrams [message #999147 is a reply to message #999073] |
Fri, 11 January 2013 12:52  |
|
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 08:49 |
|
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?
Follow me on Twitter @andreasindico
|
|
|
| Re: Sequence Diagrams [message #999568 is a reply to message #999496] |
Sat, 12 January 2013 13:46 |
|
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 #999659 is a reply to message #999606] |
Sat, 12 January 2013 20:04 |
|
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
Follow me on Twitter @andreasindico
|
|
|
| Re: Sequence Diagrams [message #999672 is a reply to message #999659] |
Sat, 12 January 2013 20:50 |
|
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 #999896 is a reply to message #999676] |
Sun, 13 January 2013 10:50 |
|
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?
Follow me on Twitter @andreasindico
|
|
|
| Re: Sequence Diagrams [message #1000297 is a reply to message #999896] |
Mon, 14 January 2013 13:04 |
|
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 14:54 |
|
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.
Follow me on Twitter @andreasindico
|
|
|
| Re: Sequence Diagrams [message #1000593 is a reply to message #1000337] |
Tue, 15 January 2013 04:13 |
|
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 19: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 19:47 |
|
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 20:14 |
|
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.
Follow me on Twitter @andreasindico
|
|
|
|
Powered by
FUDForum. Page generated in 0.03781 seconds
] 
Search
Help
Register
Login
Home
