Questions about UML class diagrams?

Hello I have a few questions about UML class diagrams any help will be appreciated

1) How do you show pointers in attributes?

2) Whats multiplicity?

3) What direction should the composition arrows be?

4) How do you put enums?

Solution 1:

According to the current UML standard 2.4.1 and the next one 2.5 (it differs almost only in more simple documentation):

• Pointers/references should be shown as arrow with small black circle (dot) at the referenced end. If it is not pointer that the object has as an attribute, but it is counted in any way, there will be arrow without the dot. If the line should have arrows on the both sides, you can omit both arrows. But not dots! If the arrow is only on one side and you KNOW, there should be no one on the other side, this empty end should be signed by a cross

Before other things you should understand

what the association is

• An association from A to B is shown as a solid line between A and B. It can represent one structure that connects class/instanc(es) of A with the class/instances of B. The structure can be of any sort and belong anywhere. All information, written about the line, describes this structure.
• If there are two structures, one structure, that connects one instance of A with instance(s) of B and another structure that connects instance of B with instance(s) of A, you can show them both in ONE association. Then, information written about its B end describes the first structure (b->a) and info about the other end describes the other structure.
• If you'll have more than one structure guiding from A to B, you have to draw two different associations.
• If a joining structure is complex, you could represent it as an Association Class. There you can define more details.
• A joining structure can connect more than two classes, then it will be shown as a large diamond with solid branches to these classes. It is still association! Attention: these two more complex associations are very badly supported by existing tools. You can easily create something absolutely senseless with them. And they are difficult. Use carefully.

• Multiplicity.
  • Case of one structure: Multiplicity on both ends of association show, how many instances of this adjacent class that structure controls.
  • Case of two structures: multiplicity on the A end of the A-B association shows, how many instances of A are controlled by the structure that guides from B to A. It has 0 or 1 on the B side. The number on the other side belongs to another structure.
• If it is not enough, you can use two associations for these two structures.

Yes, it is not easy, sorry. But it is MUCH easier, that the text of the "easier" 2.5 UML standard. Easy explanation is a false one, using it you'll quickly run into problems in any real task.

• Composition and about it.

  • There are only one composition "arrow", as you called it, it is called black or full diamond. It is on the side of the container, not parent, of course. The other one, empty diamond, is called "shared aggregation", or, shortly, "shared". It is not strictly defined and you can use it creating your own standard. Of course, it would be foolish to put it on the item side of item-container association. But it easily could be on the both ends of association.
  • Why the composition diamond can be only on one side? Because composition means, that items exist ONLY while exist reference to them from the container (or container itself). Of course, that couldn't work for both sides.
  • Often you can see name "aggregation" for "shared aggregation". It is a BAD mistake. Because, according to standard, composition, shared and even none, all three are aggregations. Somebody mixes parent and child terms.

• Simple old Enums are easy - there is a sort of class block for them, @MagicMan put it correctly. But they are obsolete already. And if you use more elaborated Java's Enumeration type (surely, other languages have it too), and you set different fields or functions for different items, you have to use class blocks for them, only you'll have to create your own stereotype (if your tool hasn't one already) and set the appropriate class block to it.

Edit:

So, simple pointer is arrow with dot. But if there exists another, back navigation, there will be NO arrows at all, and only dot(s).

In C++ instance A can have the B instance not by pointer, but directly. There is NO special UML sign for it, it should be shown in the same way as normal, pointer attribute.

Solution 2:

1) Common way is like this for a one way association(pointer): ---->, but apparently the correct way is to add a dot at the end to indicate the referenced side: ---->*

2) Multiplicty is the range it can run represented like this (0..1), ie a pointer can be null so that zero specifies it could have 0 to 1 target objects

3) Composition arrows belong on the containing object's side: Container<>-----Child

4) I've seen them represented like this:

_______________________
|   <<enumeration>>   |
|       Colors        |
|_____________________|
| Red                 |
| Green               |
| Blue                |
| ...                 |
|_____________________|

A good UML cheat-sheet: Link