|  | UML class diagram representation in C++ | | |
| | | DavidA |  |
|  Posted: Thu May 22, 2008 10:25 am Post subject: UML class diagram representation in C++ |  |
Hi
I am a beginner of UML. Here are a few basic questions:
1) Please can anyone refer me to an article that shows how each class
diagram relationship type may be coded in C++ (for example, what does
an aggregation look like in C++) ?
2) What would a dependancy look like in C++ and why might one use it?
3) How could I depict a global array in a class diagram, and show that
a class accesses(but not owns) it?
Thanks
David |
| |
| | | Daniel T. | |
| | Posted: Thu May 22, 2008 10:25 am Post subject: Re: UML class diagram representation in C++ | |
DavidA <dandbnews@talktalk.net> wrote:
| Quote: | I am a beginner of UML. Here are a few basic questions:
1) Please can anyone refer me to an article that shows how each class
diagram relationship type may be coded in C++ (for example, what does
an aggregation look like in C++) ?
|
If the code that implements class A must include a declaration of class
B in order to compile, the A depends on B.
If the code that implements class A calls a non-static member function
on an object of class B, then A uses B.
If the declaration of class A has a private member-variable of class B,
B&, or B*, and none of the member functions expose this fact, then A
contains a B.
The above isn't quite UML but it is very useful.
| Quote: | 3) How could I depict a global array in a class diagram, and show that
a class accesses(but not owns) it?
|
Have a class box and give it a <<Global>> stereotype. Better yet, don't
have globals. |
| |
| | | H. S. Lahman | |
| | Posted: Thu May 22, 2008 3:04 pm Post subject: Re: UML class diagram representation in C++ | |
| |  | |
Responding to DavidA...
| Quote: | I am a beginner of UML. Here are a few basic questions:
1) Please can anyone refer me to an article that shows how each class
diagram relationship type may be coded in C++ (for example, what does
an aggregation look like in C++) ?
|
There are typically many ways to implement any given OOA/D relationship
during OOP and selecting the best way will depend on nonfunctional
requirements like performance. For example, *:* associations will almost
always be reified to two 1:* associations and a collection class. But in
an extreme case one might need something as elaborate as a GoF Visitor
pattern. Similarly, usually a 1:* association will be implemented with a
library collection class. But the /kind/ of collection class could be
anything from a simple array to an implementation of a red/black tree.
There could even be situations where one uses multiple pointer attributes.
Aggregation is a special situation. It exists to provide symmetry with
composition because it covers the case where a Whole/Part relationship
exists but the Whole does not control the disposition of the Part. In
fact, aggregation would be implemented exactly the same was as a simple
association. IOW, aggregation in UML is a sort of mnemonic to map the
Class Diagram into the customer problem space rather than a
specification of the OOP implementation.
Speaking of aggregation/composition and apropos of the first paragraph,
in C++ the common way to implement composition is by making the Part
object an embedded object in the Whole implementation (i.e., declared
without a '*' or '&'). That ensures that the Part object is born and
dies with the Whole object. However, there are other ways to ensure that
constraint is honored so one does not /need/ to embed the Part; it is
just easier in C++ to do it that way. Conversely, observing an embedded
object in the C++ code does not imply that a Whole/Part relationship
exists in the OOA/D.
| Quote: |
2) What would a dependancy look like in C++ and why might one use it?
|
Dependencies are only an issue for OOP because of physical coupling in
3GLs. It does not directly affect the implementation of the association;
it simply provides a handy way of "painting" the OOA/D so that the OOP
developer will know what the dependencies are and can refactor the OOP
code to make it more maintainable from an OOP perspective.
FWIW, I think dependencies in UML are an over-specification of OOP.
Since dependencies are a pure OOP implementation problem, it is not up
to the OOA/D designer to tell the OOP developer how to manage them. They
are also unnecessary. All the books on dependency management refactoring
are very much OOP-focused and they provide their own guidelines for
recognizing dependencies (i.e., there is usually not a UML diagram in
sight).
[Note that the books on dependency management advocate getting the OOP
code to work first and then refactoring it to make it more maintainable.
The OOA/D should just specify what working is. The dependency management
is a separate and pure OOP activity.]
| Quote: |
3) How could I depict a global array in a class diagram, and show that
a class accesses(but not owns) it?
|
The short answer is: Don't Do That! B-)
There should be no global data in a well-formed OOA/D model. Some object
always owns and data and the data is accessed by whoever needs it by
navigating relationship paths. One of the primary reasons OOA/D
emphasizes relationships is so that access to data can be limited.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
LINK
blog: LINK
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
LINK
(888)OOA-PATH |
| |
| | | DavidA | |
| | Posted: Tue May 27, 2008 9:38 am Post subject: Re: UML class diagram representation in C++ | |
Thanks Daniel and H.S. for your helpful replies.
David |
| |
|
|
