UML: how to represent indirect operation calls in a sequence diagram?
Consider the following classes:
I would like to represent in a sequence diagram the fact that an instance of A first navigates through the b association end to reach a B instance, then navigates through its association c to reach a C instance, then calls the operation foo().
How can I represent this in a sequence diagram? Afaik, navigating from one object to an other is not a message, and thus cannot be represented by an arrow, can it? Then how can I show how the C instance is found by the A instance?
My only idea so far is to write a.b.c into the name of the C instance lifeline, but I know that this is very likely incorrect:
EDIT (28/11): I don't think that this question is a duplicate of this existing question, as here I am interested in representing in a sequence diagram how an object was able to access another object, and not how an object was obtained as a result of a method call / message.
EDIT (28/11 again): I realized that what the case I have described is wrong, as in fact an Interaction (ie. a sequence or communication diagram) has to be contained in a Classifier, and can only show Lifelines of elements accessible through the properties of the Classifier. Thus, with my current class diagram, it is in fact impossible to represent both an instance of A and an instance of C, since there is no candidate Classifier referencing both which could be used to contain the sequence diagram.
In other words, afaik, with the proposed class diagram, I cannot have a sequence diagram representing A and C, and I can only represent either A and B, or B and C.
uml
asked Nov 23 '18 at 16:43
Gwendal
1328
add a comment |
Consider the following classes:
I would like to represent in a sequence diagram the fact that an instance of A first navigates through the b association end to reach a B instance, then navigates through its association c to reach a C instance, then calls the operation foo().
How can I represent this in a sequence diagram? Afaik, navigating from one object to an other is not a message, and thus cannot be represented by an arrow, can it? Then how can I show how the C instance is found by the A instance?
My only idea so far is to write a.b.c into the name of the C instance lifeline, but I know that this is very likely incorrect:
EDIT (28/11): I don't think that this question is a duplicate of this existing question, as here I am interested in representing in a sequence diagram how an object was able to access another object, and not how an object was obtained as a result of a method call / message.
EDIT (28/11 again): I realized that what the case I have described is wrong, as in fact an Interaction (ie. a sequence or communication diagram) has to be contained in a Classifier, and can only show Lifelines of elements accessible through the properties of the Classifier. Thus, with my current class diagram, it is in fact impossible to represent both an instance of A and an instance of C, since there is no candidate Classifier referencing both which could be used to contain the sequence diagram.
In other words, afaik, with the proposed class diagram, I cannot have a sequence diagram representing A and C, and I can only represent either A and B, or B and C.
uml
asked Nov 23 '18 at 16:43
Gwendal
1328
1
Possible duplicate of Referencing an instance of a given class in sequence diagrams
– Peter Uhnak
Nov 24 '18 at 23:53
add a comment |
Consider the following classes:
I would like to represent in a sequence diagram the fact that an instance of A first navigates through the b association end to reach a B instance, then navigates through its association c to reach a C instance, then calls the operation foo().
How can I represent this in a sequence diagram? Afaik, navigating from one object to an other is not a message, and thus cannot be represented by an arrow, can it? Then how can I show how the C instance is found by the A instance?
My only idea so far is to write a.b.c into the name of the C instance lifeline, but I know that this is very likely incorrect:
EDIT (28/11): I don't think that this question is a duplicate of this existing question, as here I am interested in representing in a sequence diagram how an object was able to access another object, and not how an object was obtained as a result of a method call / message.
EDIT (28/11 again): I realized that what the case I have described is wrong, as in fact an Interaction (ie. a sequence or communication diagram) has to be contained in a Classifier, and can only show Lifelines of elements accessible through the properties of the Classifier. Thus, with my current class diagram, it is in fact impossible to represent both an instance of A and an instance of C, since there is no candidate Classifier referencing both which could be used to contain the sequence diagram.
In other words, afaik, with the proposed class diagram, I cannot have a sequence diagram representing A and C, and I can only represent either A and B, or B and C.
uml
asked Nov 23 '18 at 16:43
Gwendal
1328
Consider the following classes:
I would like to represent in a sequence diagram the fact that an instance of A first navigates through the b association end to reach a B instance, then navigates through its association c to reach a C instance, then calls the operation foo().
How can I represent this in a sequence diagram? Afaik, navigating from one object to an other is not a message, and thus cannot be represented by an arrow, can it? Then how can I show how the C instance is found by the A instance?
My only idea so far is to write a.b.c into the name of the C instance lifeline, but I know that this is very likely incorrect:
EDIT (28/11): I don't think that this question is a duplicate of this existing question, as here I am interested in representing in a sequence diagram how an object was able to access another object, and not how an object was obtained as a result of a method call / message.
EDIT (28/11 again): I realized that what the case I have described is wrong, as in fact an Interaction (ie. a sequence or communication diagram) has to be contained in a Classifier, and can only show Lifelines of elements accessible through the properties of the Classifier. Thus, with my current class diagram, it is in fact impossible to represent both an instance of A and an instance of C, since there is no candidate Classifier referencing both which could be used to contain the sequence diagram.
In other words, afaik, with the proposed class diagram, I cannot have a sequence diagram representing A and C, and I can only represent either A and B, or B and C.
uml
uml
asked Nov 23 '18 at 16:43
Gwendal
1328
asked Nov 23 '18 at 16:43
Gwendal
1328
edited Nov 28 '18 at 12:51
asked Nov 23 '18 at 16:43
Gwendal
1328
asked Nov 23 '18 at 16:43
Gwendal
1328
asked Nov 23 '18 at 16:43
Gwendal
1328
1328
1
Possible duplicate of Referencing an instance of a given class in sequence diagrams
– Peter Uhnak
Nov 24 '18 at 23:53
add a comment |
1
Possible duplicate of Referencing an instance of a given class in sequence diagrams
– Peter Uhnak
Nov 24 '18 at 23:53
1
1
Possible duplicate of Referencing an instance of a given class in sequence diagrams
– Peter Uhnak
Nov 24 '18 at 23:53
Possible duplicate of Referencing an instance of a given class in sequence diagrams
– Peter Uhnak
Nov 24 '18 at 23:53
add a comment |
2 Answers
2
active
oldest
votes
In your diagram, you have used the association notation of attributes: +b means that b is a public attribute of A that has is of class B, and similarly c is a public attribute of B. So the notation a.b.c:C could be valid.
However, I'm not 100% sure if this is really valid UML. The standard foresees an element name and not an expression that determines the element. It allows qualified name, but in a namespace not in a classifier. The optional selector that is possible on the name is also not designed for traversing multiple relationships.
So a better approach would certainly be to give a simple name to your second lifeline (e.g. x, or keep it anonymous) and add a constraint that explains how it is determined ( e.g. { x = a.b.c }. In constraints, be it in OCL, java or natural language, you are allowed to do these kind of access to public attributes.
Now, this might not be desirable from an OO design perspective: using such public members creates a strong coupling and does not offer proper encapsulation. I'd therefore use some getter.
The result would then look like:
Note that if you don't like the assumption for b being known, you can replace the illustrative comment by a real constraint, exactly the way I explained above.
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
add a comment |
Well, there are not many options. As you see it's nothing you should do anyway since you're violating the paradigm of information hiding.
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450323%2fuml-how-to-represent-indirect-operation-calls-in-a-sequence-diagram%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
In your diagram, you have used the association notation of attributes: +b means that b is a public attribute of A that has is of class B, and similarly c is a public attribute of B. So the notation a.b.c:C could be valid.
However, I'm not 100% sure if this is really valid UML. The standard foresees an element name and not an expression that determines the element. It allows qualified name, but in a namespace not in a classifier. The optional selector that is possible on the name is also not designed for traversing multiple relationships.
So a better approach would certainly be to give a simple name to your second lifeline (e.g. x, or keep it anonymous) and add a constraint that explains how it is determined ( e.g. { x = a.b.c }. In constraints, be it in OCL, java or natural language, you are allowed to do these kind of access to public attributes.
Now, this might not be desirable from an OO design perspective: using such public members creates a strong coupling and does not offer proper encapsulation. I'd therefore use some getter.
The result would then look like:
Note that if you don't like the assumption for b being known, you can replace the illustrative comment by a real constraint, exactly the way I explained above.
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
add a comment |
In your diagram, you have used the association notation of attributes: +b means that b is a public attribute of A that has is of class B, and similarly c is a public attribute of B. So the notation a.b.c:C could be valid.
However, I'm not 100% sure if this is really valid UML. The standard foresees an element name and not an expression that determines the element. It allows qualified name, but in a namespace not in a classifier. The optional selector that is possible on the name is also not designed for traversing multiple relationships.
So a better approach would certainly be to give a simple name to your second lifeline (e.g. x, or keep it anonymous) and add a constraint that explains how it is determined ( e.g. { x = a.b.c }. In constraints, be it in OCL, java or natural language, you are allowed to do these kind of access to public attributes.
Now, this might not be desirable from an OO design perspective: using such public members creates a strong coupling and does not offer proper encapsulation. I'd therefore use some getter.
The result would then look like:
Note that if you don't like the assumption for b being known, you can replace the illustrative comment by a real constraint, exactly the way I explained above.
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
add a comment |
In your diagram, you have used the association notation of attributes: +b means that b is a public attribute of A that has is of class B, and similarly c is a public attribute of B. So the notation a.b.c:C could be valid.
However, I'm not 100% sure if this is really valid UML. The standard foresees an element name and not an expression that determines the element. It allows qualified name, but in a namespace not in a classifier. The optional selector that is possible on the name is also not designed for traversing multiple relationships.
So a better approach would certainly be to give a simple name to your second lifeline (e.g. x, or keep it anonymous) and add a constraint that explains how it is determined ( e.g. { x = a.b.c }. In constraints, be it in OCL, java or natural language, you are allowed to do these kind of access to public attributes.
Now, this might not be desirable from an OO design perspective: using such public members creates a strong coupling and does not offer proper encapsulation. I'd therefore use some getter.
The result would then look like:
Note that if you don't like the assumption for b being known, you can replace the illustrative comment by a real constraint, exactly the way I explained above.
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
In your diagram, you have used the association notation of attributes: +b means that b is a public attribute of A that has is of class B, and similarly c is a public attribute of B. So the notation a.b.c:C could be valid.
However, I'm not 100% sure if this is really valid UML. The standard foresees an element name and not an expression that determines the element. It allows qualified name, but in a namespace not in a classifier. The optional selector that is possible on the name is also not designed for traversing multiple relationships.
So a better approach would certainly be to give a simple name to your second lifeline (e.g. x, or keep it anonymous) and add a constraint that explains how it is determined ( e.g. { x = a.b.c }. In constraints, be it in OCL, java or natural language, you are allowed to do these kind of access to public attributes.
Now, this might not be desirable from an OO design perspective: using such public members creates a strong coupling and does not offer proper encapsulation. I'd therefore use some getter.
The result would then look like:
Note that if you don't like the assumption for b being known, you can replace the illustrative comment by a real constraint, exactly the way I explained above.
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
answered Nov 25 '18 at 22:28
Christophe
38.9k43474
38.9k43474
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
add a comment |
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Thanks for the answer, and adding a constraint is indeed interesting! Since an Interaction is itself (surprisingly) a Class and thus a Namespace, it seems it can contain constraints. i wonder whether this is planned by the semantics, but syntactically this appears possible.
– Gwendal
Nov 28 '18 at 9:07
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
Those are not constraints but notes.
– Thomas Kilian
Nov 28 '18 at 10:17
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
@ThomasKilian sorry, I didn't put the {contraint} braces
– Christophe
Nov 28 '18 at 10:19
add a comment |
Well, there are not many options. As you see it's nothing you should do anyway since you're violating the paradigm of information hiding.
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
add a comment |
Well, there are not many options. As you see it's nothing you should do anyway since you're violating the paradigm of information hiding.
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
add a comment |
Well, there are not many options. As you see it's nothing you should do anyway since you're violating the paradigm of information hiding.
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
Well, there are not many options. As you see it's nothing you should do anyway since you're violating the paradigm of information hiding.
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
answered Nov 23 '18 at 17:35
Thomas Kilian
23.2k63460
23.2k63460
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
add a comment |
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
Thanks for the answer! My question did not assume that information hiding was considered here, hence I don't see it as a problem. In fact, in some cases such as early domain analysis, some methods advocate using UML without any information hiding, which is how I ended up asking this question.
– Gwendal
Nov 28 '18 at 8:37
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450323%2fuml-how-to-represent-indirect-operation-calls-in-a-sequence-diagram%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Possible duplicate of Referencing an instance of a given class in sequence diagrams
– Peter Uhnak
Nov 24 '18 at 23:53