How do I denote a pure virtual function in a UML class diagram?
I am a student learning C++. I am creating a UML class diagram for my program that involves inheritance and abstract / concrete classes, but I'm not too sure how I would denote a pure virtual function. Any help is appreciated, thank you!
c++ uml class-diagram virtual-functions pure-virtual
add a comment |
I am a student learning C++. I am creating a UML class diagram for my program that involves inheritance and abstract / concrete classes, but I'm not too sure how I would denote a pure virtual function. Any help is appreciated, thank you!
c++ uml class-diagram virtual-functions pure-virtual
add a comment |
I am a student learning C++. I am creating a UML class diagram for my program that involves inheritance and abstract / concrete classes, but I'm not too sure how I would denote a pure virtual function. Any help is appreciated, thank you!
c++ uml class-diagram virtual-functions pure-virtual
I am a student learning C++. I am creating a UML class diagram for my program that involves inheritance and abstract / concrete classes, but I'm not too sure how I would denote a pure virtual function. Any help is appreciated, thank you!
c++ uml class-diagram virtual-functions pure-virtual
c++ uml class-diagram virtual-functions pure-virtual
asked Nov 12 '18 at 21:44
john greyjohn grey
182
182
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The UML standard does indicate that a behavioral feature (e.g. a method/operation) can have its property isAbstract
set to indicate that it is abstract and has no implementation. There is however nothing about how this should be shown in the diagram.
According to uml-diagrams.org and other sources, in older UML versions (1.4.x), an abstract operation was shown with a name in italic or with a textual {abstract}
marker following its name. The italic convention was widely used (See also here).
The current UML doesn't use anymore use italic and does not indicate how to represent the isAbstract
property. Nevertheless, the {abstract}
marker should still be valid.
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even ifabstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).
– Christophe
Nov 13 '18 at 0:07
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
1
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
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%2f53270548%2fhow-do-i-denote-a-pure-virtual-function-in-a-uml-class-diagram%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The UML standard does indicate that a behavioral feature (e.g. a method/operation) can have its property isAbstract
set to indicate that it is abstract and has no implementation. There is however nothing about how this should be shown in the diagram.
According to uml-diagrams.org and other sources, in older UML versions (1.4.x), an abstract operation was shown with a name in italic or with a textual {abstract}
marker following its name. The italic convention was widely used (See also here).
The current UML doesn't use anymore use italic and does not indicate how to represent the isAbstract
property. Nevertheless, the {abstract}
marker should still be valid.
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even ifabstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).
– Christophe
Nov 13 '18 at 0:07
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
1
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
add a comment |
The UML standard does indicate that a behavioral feature (e.g. a method/operation) can have its property isAbstract
set to indicate that it is abstract and has no implementation. There is however nothing about how this should be shown in the diagram.
According to uml-diagrams.org and other sources, in older UML versions (1.4.x), an abstract operation was shown with a name in italic or with a textual {abstract}
marker following its name. The italic convention was widely used (See also here).
The current UML doesn't use anymore use italic and does not indicate how to represent the isAbstract
property. Nevertheless, the {abstract}
marker should still be valid.
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even ifabstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).
– Christophe
Nov 13 '18 at 0:07
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
1
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
add a comment |
The UML standard does indicate that a behavioral feature (e.g. a method/operation) can have its property isAbstract
set to indicate that it is abstract and has no implementation. There is however nothing about how this should be shown in the diagram.
According to uml-diagrams.org and other sources, in older UML versions (1.4.x), an abstract operation was shown with a name in italic or with a textual {abstract}
marker following its name. The italic convention was widely used (See also here).
The current UML doesn't use anymore use italic and does not indicate how to represent the isAbstract
property. Nevertheless, the {abstract}
marker should still be valid.
The UML standard does indicate that a behavioral feature (e.g. a method/operation) can have its property isAbstract
set to indicate that it is abstract and has no implementation. There is however nothing about how this should be shown in the diagram.
According to uml-diagrams.org and other sources, in older UML versions (1.4.x), an abstract operation was shown with a name in italic or with a textual {abstract}
marker following its name. The italic convention was widely used (See also here).
The current UML doesn't use anymore use italic and does not indicate how to represent the isAbstract
property. Nevertheless, the {abstract}
marker should still be valid.
edited Nov 12 '18 at 23:03
answered Nov 12 '18 at 22:21
ChristopheChristophe
39k43475
39k43475
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even ifabstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).
– Christophe
Nov 13 '18 at 0:07
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
1
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
add a comment |
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even ifabstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).
– Christophe
Nov 13 '18 at 0:07
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
1
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
P. 99 of UML 2.5: The name of an abstract Classifier is shown in italics, where permitted by the font in use
– Thomas Kilian
Nov 12 '18 at 23:31
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian yes, but this applies only to classifiers not to operations. It's very different from the 1.4 standard, where it is explicitly said "If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract." (page 3-46).
– Christophe
Nov 12 '18 at 23:48
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even if
abstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).– Christophe
Nov 13 '18 at 0:07
@ThomasKilian the notation of Behavioral Features and of Operations do not mention anymore italic notation (but still underlined for static). But both use the { property... } notation (even if
abstract
is not explicitly mentioned p108-109 + 116). I agree however with you in that I wouldn't be shocked by an italic, since it was so heavily used in the past (including pre-UML notations, e.g. in GoF).– Christophe
Nov 13 '18 at 0:07
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
Since both Italic as {abstract} are only indicated in relation to Classifiers, you could maybe update your answer. It currently states that {abstract} should be valid, and there is no indication in the specs that says that it is more valid than italics.
– Geert Bellekens
Nov 13 '18 at 7:33
1
1
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
I guess the comments above are good enough. Nothing is perfect, even specifications.
– Thomas Kilian
Nov 13 '18 at 9:04
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.
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%2f53270548%2fhow-do-i-denote-a-pure-virtual-function-in-a-uml-class-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