7

I have an object which is instantiated during compilation according to the build configuration. As far as the surrounding software considered, the object exposes the same interface. I would like to model the fact that the instantiation decision is taken during compilation (i.e. static polymorphism), as opposed to the usual dynamic polymorphism.

Is there a way to depict a static polymorphism in UML class diagram?

Here is more or less what I need:

enter image description here

Obviously, only one of the above type definitions will be instantiated at compilation.

TylerH
  • 20,799
  • 66
  • 75
  • 101
SomeWittyUsername
  • 18,025
  • 3
  • 42
  • 85
  • 1
    http://stackoverflow.com/questions/4557141/static-polymorphism-definition-and-implementation – flup May 23 '13 at 23:37
  • Do the callers of methods on the interface know at compile time which explicit subclass implementation to call? If so, how is this achieved? – flup May 25 '13 at 08:52
  • @flup - No, they don't know. Otherwise the entire purpose of polymorphism would've been lost. The explicit implementation is derived from the build environment configuration. – SomeWittyUsername May 25 '13 at 15:33
  • If I understand you right, the callers are compiled to use the interface and the concrete function to call is determined at runtime. So it is dynamic/subtype polymorphism. What happens at compile time is the dependency injection? – flup May 25 '13 at 19:00
  • @flup No, the concrete implementation is decided at compile time according to a preprocessor flag which differs per build configuration. The interface for both implementations is the same. – SomeWittyUsername May 25 '13 at 19:51

5 Answers5

3

I think the UML representation will be same for static and dynamic polymorphism. UML is about how classes interact at runtime -- I don't believe there's a UML format for describing templates, but I could be wrong.

Chirag Desai
  • 1,249
  • 1
  • 10
  • 22
  • UML is not about how classes interact at runtime. Class diagrams are about **static** relations between different entities. Other UML diagrams can be used to describe the runtime behavior. – SomeWittyUsername May 23 '13 at 08:25
  • 1
    Yea I agree it depicts static relations at runtime. But still I think there is no way to differentiate static/dynamic polymorphism. – Chirag Desai May 23 '13 at 09:11
  • Well, that's the difference between dynamic and static polymorphism - first is about relations at runtime and second about relations at compile time. – SomeWittyUsername May 23 '13 at 17:22
  • There is indeed a UML way to describe templates, a rectangle in the top right corner of the class that lists the templates types. There is also a way to denote template binding as a special kind of inheritance. – flup May 24 '13 at 21:03
  • http://stackoverflow.com/questions/860501/what-is-the-correct-way-to-represent-template-classes-with-uml – flup May 24 '13 at 21:14
  • @flup That's interesting, thanks. However, my question is slightly different - I want to choose between the different inheritance variants at compile time. – SomeWittyUsername May 24 '13 at 23:34
  • @icepack yes, I think your question has little to do with UML templates. They are used in the Curiously Recurring Template Pattern which is a different type of static polymorphism. The poster copied a bit too much of someone else's answer to another question :) – flup May 25 '13 at 08:41
2

I would use stereotypes to solve the problem. So you can mark dynamic and static

user2004268
  • 23
  • 3
  • 1
    But that would result in not-so-clear diagram. Suppose I mark *static* on interface --> derived class connection. This will naturally mean 2 *static* derivations, while the intention is to have just one of them (we're talking about polymorphism after all). Actually, currently I just added a XOR notation between the 2 derivations on the class diagram. Maybe I'll combine it with your suggestion, thanks. – SomeWittyUsername May 24 '13 at 06:25
  • Your idea with XOR sounds not bat. – user2004268 May 24 '13 at 06:44
2

I think your diagram is fine. What you are describing seems to best described as a sequence diagram describing your compilation process. (Kind of like how you'd draw a factory sequence diagram I guess)

As you correctly point out, interactions at runtime occur with some unknown concrete thing behind the interface, so you never really have to bother about concrete classes in those sequence or interaction diagrams. It's completely irrelevant there.

If there is a good deal of this happening then a deployment diagram might also be a good idea to help show what concrete implementations occur under what circumstances.

You'd want to document classes that implement your interfaces of course, and that's just a normal class diagram exactly as you've drawn it.

LoztInSpace
  • 5,584
  • 1
  • 15
  • 27
  • Interesting insights! Never thought about sequence diagram for compilation - a bit unconventional but why not? Deployment diagram also sounds like a good idea. Thanks, +1 – SomeWittyUsername May 24 '13 at 10:35
1

Combining from @ChiragDesai and @user2004268 answers and linked question (Static polymorphism definition and implementation):

  1. Polymorphism type is an implementation detail and as such it doesn't have active role in design diagrams.
  2. Implementation details can be present in UML diagram but have a complementary and informal role. Stereotypes and notes can be used to clarify the intentions.
Community
  • 1
  • 1
SomeWittyUsername
  • 18,025
  • 3
  • 42
  • 85
0

Use an empty class utility with stereotype Singleton with a generic boolean parameter named e.g. #ifdef(YOUR_FLAG), whose true specialization has the instance as a static member with public or implementation visibility.

EDITED (in reply to a comment)

Draw this in your UML tool:

Pseudo-C++-code:

class Foo; 

template <
   Boolean #ifdef(WHATEVER)
> struct Bar {};

template <> 
struct Bar<true> {
  public: 
    static Foo the_foo;
};

and add utility and Singleton stereotypes (but DON'T try to generate code from that ;) )

Solkar
  • 1,228
  • 12
  • 22
  • Not sure I understand. Can you add an example diagram? – SomeWittyUsername May 24 '13 at 07:18
  • One thing that I find disturbing about UML is that drawing that funny diagrams properly often takes longer than writing the code; pls see my EDIT above. – Solkar May 24 '13 at 07:52
  • That's the implementation. I'm not asking *how* to implement static polymorphism but how to depict it in diagram. Actually, I have something similar to your snippet (although I don't see the meaning of static member in your example - I don't want to restrict the number of objects with specific specialization, I want to **choose** one of the existing specializations during compilation). – SomeWittyUsername May 24 '13 at 07:59
  • No that's not the implementation. This is textual description of what you may draw in your diagram. – Solkar May 24 '13 at 08:01
  • Well, that's exactly the question. I know how to describe my intentions and want to use UML for design purposes instead of textual descriptions. – SomeWittyUsername May 24 '13 at 08:05
  • I somehow think I put it decently clear already, but anyway: 1.Draw a template class (like my first "Bar"). 2. Draw an instantiated template class (like my second "Bar"). 3. Add an "instantiates" link between them. 4. add the stereotype labels I mentioned. – Solkar May 24 '13 at 08:13
  • 1. What is *template class* in UML? Don't know such notation. Anyway, I have a regular class drawn using the C++ template naming semantics (<...>), but that's not part of formal UML spec, as far as I know. 2. Most important - I don't see how your stereotypes clarify the purpose (and singleton isn't related to the problem at all) – SomeWittyUsername May 24 '13 at 08:18
  • So you know what a C++ template is, but you cannot translate that to UML? – Solkar May 24 '13 at 08:30
  • Is there a purpose to this question? Template concept is related to implementation, not design and as such it should be derived from design, not vice versa. Nothing in the question implies usage of templates, similar result can be achieved with #ifdefs or build configuration. – SomeWittyUsername May 24 '13 at 08:34
  • Ok, let's finish this, you're wasting my time. I told you several times what that pseudo-code was meant for and how to work with that. Simply take or leave it. Bye. – Solkar May 24 '13 at 08:39
  • You posted something unrelated to the question and now you claim I'm wasting **your time** by attempting to squeeze something useful out of it? This answer would better be deleted altogether. I suggest you to start taking account for your actions. Good bye. – SomeWittyUsername May 24 '13 at 08:44