2

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?

user3251111
  • 43
  • 1
  • 4

2 Answers2

3

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.

example Class diagram


  • 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.

Gangnus
  • 24,044
  • 16
  • 90
  • 149
  • Two nits to pick: 1) "If there are two structures [...] you can show them both in ONE association." - That's not correct. Associations always imply referential integrity. So you can only do that if one is always the reverse direction of the other, i.e. iff object A1 pointing to B always implies B pointing to A1. If the two structures can be inconsistent to one another, i.e. object A1 pointing to B and B pointing to A2, you'll have to use two associations. – Carsten Feb 13 '14 at 13:55
  • 2) In case of the complex association to the right of the illustration, there can only be navigability decorations on the ends at the classes, not at the association node. – Carsten Feb 13 '14 at 13:55
  • @Carsten Thank you. But I am afraid, I can agree only partly. 1. Of course. But it is the requirement of good style, not of UML standard. It IS correct. You can, but you needn't. Choose, according to the style. 2. And how would you show the case of class D? (When you are criticizing, propose the correct variant, please). And according to standard, again here it is on us to choose the strategy of using or non-using the navigability/owning. When we use them, "navigabilityNotation and nonnavigabilityNotation applies to UMLEdges that have as modelElements Associations,..." (uml st.2.5, p.772). – Gangnus Feb 13 '14 at 14:51
  • @Carsten citation continued: "...InstanceSpecifications that have an Association as classifier, Properties, or Slots". So, the diagram is correct in this part. – Gangnus Feb 13 '14 at 14:52
  • 1) No, it's not correct. See UML 2.5 11.5.3 (Association Semantics): "An Association declares that there can be links [...]. A link is a tuple with one value for each memberEnd of the Association" and the navigation semantics section starting with "For an Association with N memberEnds, choose any N-1 ends [...]". Given e.g. classes A and B and an association in between with cardinality 0..1 on both ends, you can't have an instance of A pointing to an instance of B without that B instance pointing back to the same A instance. Try expressing it with the mentioned tuple semantics and you'll see. – Carsten Feb 13 '14 at 18:22
  • 2) You are quoting the DI part of the spec. That is only concerned with diagram representation, not the UML metamodel itself. You can't deduce model validity from what's possible in the DI model. Regarding the edge between D and "more complex association", try expressing that with the structures of Class (11.4), Association (11.5) and Property (9.5). You won't be able to, because there is no notion of navigation from a class instance to an association, but only through the association to a class instance. Again, cf. the sections from UML 2.5 11.5.3 from above. – Carsten Feb 13 '14 at 18:42
  • @Carsten 2. we ARE talking on the diagram representation. And BTW, if we explicitly can make an arrow on the diagram, how it can be that it has no support in model? Or you have missed something, or they have missed something. – Gangnus Feb 14 '14 at 08:28
  • @Carsten "Given e.g. classes A and B and an association in between with cardinality 0..1 on both ends, you can't have an instance of A pointing to an instance of B without that B instance pointing back to the same A instance. " I am afraid, your argument is not true. And I don't understand how it could help you at all. To the subject: When a relationship A-B is thought over, their mutual navigation in most cases is set as two dependent constructions. For example, setting a new item in a.b[], you have to set a items of all appropriate b.a[]. Their closeness and dependence is NATURAL. – Gangnus Feb 14 '14 at 08:36
  • Gangnus, regarding 1. that's what I said was required and you said it wasn't unless I have seriously misunderstood you. 2. But you can only have a valid diagram with a valid underlying model. And that's just not possible in a valid model. It appears you drew the diagram in VP - try exporting your VP model to XMI/UML2. You'll see that they will export the assoc in question not as an association (because you can't express that stuff), but as a class containing VP-specific extensions and with 3 individual assocs to represent the ends. And given the UML tuple semantics, UML's definition is sound. – Carsten Feb 14 '14 at 09:17
  • @Carsten 1. The use of neither one nor two lines for two (a.b and b.a) relationships is required. You can easily see it in the diagrams that are used in the standard document itself. 2. It is not the task of UML to define what model is valid. It merely expresses these models. As for Association doc:"The arrow .... This notation is for documentation purposes only and has no general semantic interpretation. It is used to capture some application-specific detail ..." You created your limits. You have rights to. But we needn't follow them. – Gangnus Feb 14 '14 at 09:33
  • Gangnus, 1) correct, you don't need to show the lines, showing just the properties in the classes is an option. But when you do, the use of just 1 line for two relationships, as suggested in your original post, is wrong. Please point to a concrete example in the standard for what you are talking about. 2) Your quote is about the reading order ("PlayedInYear" in fig. 11.27). Totally different thing. Also, both the metamodel structure and the "Semantics" section in the spec is normative. So yeah, it is the task of the UML to define what model is valid with regard to the standard. – Carsten Feb 14 '14 at 12:27
  • @Carsten BTW, if you'll put here a post on your views on the thing, you will surely get a plus from me. We should support the theme we are interested in(uml). And some difference in views is not important - when everybody think the same, there is no progress. – Gangnus Feb 14 '14 at 21:55
  • Gangnus, thanks. I didn't because I think it doesn't add much value to your (otherwise) very informative post. Let's just leave this here for others to read and, as StackOverflow suggests "avoid extended discussions" ;) – Carsten Feb 14 '14 at 23:17
1

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

Durandal
  • 5,575
  • 5
  • 35
  • 49
  • Attention! Pointers/references ARE often shown by arrows, but it is NOT correct. The correct is to put a "dot" on the referenced side of the association. Arrow means *navigability* only. Navigability CAN be represented by direct reference (show it as arrow and dot), but it needn't to. It can be realized as reference to reference to..., or can get the pointer as a result of some pointer arithmetics. In these latter cases it will be arrow without dot. And when navigability goes to both sides, both arrows are omitted, so there could be even a dot without an arrow. – Gangnus Jan 31 '14 at 09:13
  • Hah, this stuff is way more complicated that I remember. So a simple pointer would be `---->*` then? – Durandal Feb 01 '14 at 01:31
  • Yes, simple pointer is arrow with dot. But if there exists another, back navigation, there will be NO arrows at all, and only point(s). And better put these comments to my answer under **my** answer - it would be easier to look at them and I'll get the notifications automatically. – Gangnus Feb 01 '14 at 14:38
  • An "arrow with dot" is a pleonasm. It doesn't make sense (and just overpopulates the diagram). A dot implies the "navigability" arrow. – Gerd Wagner Feb 14 '14 at 09:35
  • @gwag yes, but if you look on the upper association, I can't remove the arrow without setting the navigability to "undefined". Which doesn't match the dot. The tools should NOT show arrow when the dot is present, but automatically set the end to "navigable" in model. – Gangnus Feb 14 '14 at 17:15