how to draw template specialization - template inheritance ?
nguillot
I would like to draw class diagrams for classes with template
parameters.
I prefer asking with sample to be sure I manage make me hunderstand.
I use to code in C++, so I'll write the code in C++.
1) "template and inheritances"
Imagine I have this class:
template <typename T> class SpecialVector : public vector<T>;
How do I draw SpecialVector<T>:
-------
---------| T |
| -------
| vector |
----------------
/_\
|
| -------
--------------------| T |
| -------
| SpecialVector |
-------------------------
I don't like it because: how to know T of vector is the same type than
T of SpecialVector?
2) template specialization
Maybe it's the same question: if I've got a templated class:
template <typename T> class vector;
How do I draw a specialization for vector<int>?
Is it just
-------
---------| T |
| -------
| vector |
----------------
/_\
|
----------------------
| vector<int> |
----------------------
Thanks for the answers.
Nicolas.
H. S. Lahman
> I would like to draw class diagrams for classes with template
> parameters.
>
Basically my response is: Don't Do That!
Things like STL templates are pure OOPL mechanisms that are only
relevant to 3GL type systems. (Note that a UML Class Model represents a
class system, not a type system; big difference.) IOW, templates are an
implementation mechanism for OOP. UML is a notation for OOA/D which is
at a higher level of abstraction than OOP. So trying to specify that
sort of thing in a UML Class Diagram is usurping the prerogatives of OOP
design; it is implementation pollution that over-specifies the solution
for OOP.
<aside>
In anticipation of an obvious question, what if one were doing OOA/D for
an OOPL compiler where notions like templates are part of the problem
space? The answer is that one would abstract that problem space
differently than the OOPL itself does. That is, one would have first
class objects like Template that were related as peers to objects like
Responsibility that they qualify and one would organize the
responsibilities around compiler activities rather than program
execution activities. For example,
<pre>
1 R1 invokes *
[CallTemplate] --------------------- [Responsibility]
+ generateCallCode() | *
A | has
| R2 |
+------------+-----------+---... | R3
| | |
[ConcreteTypeX] [ConcreteTypeY] <*>
[Class]
</pre>
So when invocation contexts were encountered in the source, R1 would be
instantiated to the correct concrete type and object code for the caller
would be written correctly. [One might have a similar
ImplementationTemplate attached to [Responsibility] to write code for
the object itself to execute at run time when the responsibility is
invoked. But that is trickier because source and template statements are
interleaved. IOW, the compiler activities for generating the
responsibility code are more complex than simply invoking the right
template version in a collaboration.]
Caveat. This probably isn't the way a compiler's second pass would be
modeled because the compiler also has to deal with output from lexical
analysis and things like operator overloading so a more holistic design
would be needed. This was just the simplest way to make the point that a
compiler is solving a different problem -- object code generation --
than the program source code is solving so it needs to be abstracted
around that problem space. IOW, it needs to model the operational
semantics of compilation and OOPL syntax is peripheral to that.
</aside>
<Hot Button>
I don't know whether OMG introduced notation for dealing with 3GL
templates in v2.0. If they did, they shouldn't have. (More precisely,
such model elements should not be included in an MDA profile for OOA/D.)
There is already enough 3GL stuff in UML like 'protected' that is a
legacy from the Booch notation (aka "Graphical C++"). OOPLs should
implement OOA/D designs, not the other way around. Cluttering an OOA/D
notation with 3GL implementation artifacts is letting the tail wag the dog.
</Hot Button>
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Ken Lloyd
Consider what Lahman says within his context, then ignore it.
IF you are doing OOAD by UML "pictures", Lahman is correct. However, if you
are using the UML closely mapped to Category Theoretic mathematical
constructs, where Type templated constructs are critical to the design, then
by all means use the templating technique (obviously not just OOP).
For an excellent background of this technique - not just of STL concepts,
but of a Category Theoretic approach to OOAD - see Alex Stepanov and Paul
McJones' book "Elements of Programming" (Addison-Wesley, 2009).
Ken Lloyd
Sr. Software Architect
Responding to nguillot...
--
You received this message because you are subscribed to the Google Groups
"UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en.