How to represent STL Map in UML diagra? [duplicate]

This question already has answers here: Closed 10 years ago.

Possible Duplicate:

How to describe a contained map in UML class diagram?

I want a notation for S开发者_开发知识库TL MAP in UML diagram.

---

Depending on what you want to model and how. I have many times just modeled the composition/aggregation relationship of the class containing the map to the map stored elements and added an attribute to the relationship:

class MyEnclosingType {
   std::map<int,MyEnclosedType*> m_map;
};

MyEnclosingType <>-------------------------- MyEnclosedType
                         << map >>

Depending on the tool you are using, some do recognize it. For example BoUML, IIRC, will automatically draw something similar to this:

MyEnclosingType <>-------------------------- MyEnclosedType
                              ^
                              |
                              | << bind Key=int >>
                              |
                             map 

I don't think it was exactly like that, but somehow similar. At the end UML is a tool for people to read, not for computers. If you do believe in code generation (good luck) then the question is what strange construct you need to use for your software to understand your intentions.

Some other tools will have the STL or allow you to add parametrized types and you can use that to represent the same code as:

                                                 Key=string
                                                 Value=MyEnclosedType
MyEnclosingType <>-------------------------- map

Where both MyEnclosingType and map would be surrounded by solid boxes, and Key and Value would be represented by a discontinuous box overlapping the map box as with other parametrized types.

I would try to reverse engineer a simple code sample with a map with your tool of choice and see what the tool generates for you. If you don't like it, just think on what you can do to actually offer as much insight to the problem as you can with what the tools enables you to.

---

You can just treat it as a native data type. Most of the time there is no reason to do something else.

There is no 'right' or 'wrong' here. The only questions is what makes the architecture more understandable to the team.