I was running a tutorial today, and a we were designing a Class diagram to model a road system. One of the constraints of the system is that any one segment of road has a maximum capacity; once reached, no new vehicles can enter the segment.
When drawing the class diagram, can I use capacity as one of the multiplicities? This way, instead of having 0..* vehicles on a road segment, I can have 0..capacity vehicles.
I had a look at ISO 1905-1 for inspiration, and I thought that what I want is similar to what they've called a 'multiplicity element'. In the standard, it states:
If the Multiplicity is associated with an element whose notation is a text string (such as an attribute, etc.), the multiplicity string will be placed within square brackets ([]) as part of that text string. Figure 9.33 shows two multiplicity strings as part of attribute specifications within a class symbol. -- section 9.12
However, in the examples it gives, they don't seem to employ this feature in the way I expected - they annotate association links rather than replace the multiplicities.
I would rather get a definitive answer for the students in question, rather than make a guess based on the standard, so I ask here: has anyone else faced this issue? How did you overcome it?
According to the UML specification you can use a ValueSpecification for lower and upper bounds of a multiplicity element. And a ValueSpecification can be an expression. So in theory it must be possible although the correct expression will be more complex. Indeed it mixes design and instance level.
In such a case it is more usual to use a constraint like this:
UML multiplicity constraint http://app.genmymodel.com/engine/xaelis/roads.jpg
Related
In an UML class diagram:
a) Do you have to state attributes that are aggregated? Or is it enough with the arrows indicating aggregation?
b) Do I have to add "id" as an attribute or is it a given?
Thanks.
You are using a shared aggregation in the picture. That does not have any defined semantics as per UML 2.5 (see p. 110). If you need a composite aggregation the diamond must be filled. In that case the aggregated object will be deleted along with the aggregating one (the latter must assure that constraint). In your model it makes no sense. No employee aggregates a department. Even vice versa I would have doubts or at least reason for discussion.
An id is only needed if it has a business purpose (e.g. an article number). If you transform your model to a database you introduce an artificial id for technical reasons. But on an abstract business level they are not modeled.
Your models only differ in the use of attributes for associated classes. The B variant is preferred. But you need to place the attributes as role names towards the associated classes (as -department and -branch). What you have placed in the middle of the connectors is rather the association name. Badly chosen with the + in front. Naming associations is rarely needed. So get rid of that. Role names shall be placed near the class that takes the role. Also it's a good idea to use the dot-notation to show that the roles represent owned properties. Just place a small black dot near the left hand side of both (near where the role names should go).
As for the dot-notation UML 2.5 states on p. 18:
Dot notation is used to denote association end ownership, where the dot shows that the Class at the other end of the line owns the Property whose type is the Class touched by the dot. See 11.5.4 for details of Association notation and 11.5.5 for examples.
Also as JimL. commented the A-version uses associations plus attributes which introduces redundancy. This is not illegal but likely not intended and at least leads to confusion.
Trying to implement a class diagram and I am not sure how should it done properly. Here is the problem:
Miners can extract gold, silver and coal (the mines are homogeneous, always contains one type). In addition, there are some dangerous mines: e.g some might collapse or be radioactive.
How can I represent this on a class diagram? First, I thought it can be done with one Mines class. From that with generalization I candefine the collapsible and radioactive mines. But I can't decide how to deal with the different material types. Should that be classes too or attributes in the Mines class?
The simpler the better. Without specific behavior in the statement depending on the extracted substance it is enough to have only one class Mine, and the the list of possible substances being known an enumeration is enough. Because a mine produces only one substance the multiplicity is 1.
The statement doesn't say if the mine can both be radioactive and collapse or not.
Supposing a mine can both be radioactive and can collapse, you can use an attribute for each danger:
It is also possible to use a enumeration for the danger and the multiplicity 0..2 but it is also necessary to have a constraint saying each danger appears at most one time, so this is not a simple way.
Else if even less probable a mine can have at most one danger you can again use a enumeration with the multiplicity 1:
or with the multiplicity 0..1:
The best way to model this is by defining the material in the mine as an enumeration. An enumeration is a data type, which you can use to define an attribute, as follows:
The dependency arrow from Mine to Material is redundant, because it is already implied by the fact that it is used as an attribute type, but in a more complex class diagram, I find it helpful to easily see which enumerations are used by which classes.
I did not use generalization for the various types of mines, because the subclasses would not have special features, so I go for the most simple solution.
I did not use generalization for the dangers, because a mine may be both collapsing and radioactive.
I am not entirely clear about multiplicities.
From what I understand, (1..*) close to instructor class means 1 Instructor can have many Courses.
And (1..1) near course class, means 1 class can have 1 instructor.
Is this a correct reasoning?
Note: Please ignore contents of Course class
First: the round brackets around the multiplicities are wrong. Leave them away.
Your diagram "means" that an Instructor has exactly one relation to Course. Additionally it has a private property teachingCourses as a list. The semantics ot the 1..1 is absolutely not transparent. Vice versa a Course has 1..* Instructors (hopefully not at the same time). Plus it has a private property leadInstructor (your naming is not orthogonal here).
Now, most likely you meant this:
There's an instructor to hold 1..* courses and a course has exactly one lead instructor. I omitted the local properties and used role names marked as owned properties (the dots). That eliminates the redundancy from your diagram.
Note: as #Ister commented, 1 is a shortcut for 1..1. Both mean "exactly one". Where a .. appears in a multiplicity it separates lower bounds (on the left) from upper bounds (right).
Let's say I have class A with associations to classes X, Y, and Z, respectively. I need to indicate that only one of these associations may be instantiated for any given instance of class A (so, an xor constraint). I know how to do this if the constraint is just across two associations. Obviously I can just make three seperate xor constraints (X-Y, X-Z, Y-Z) but I'm wondering if there is a better/cleaner/proper way to do it?
edit: The multiplicity constraints on the respective associations are not the same. Using an abstract class or interface will not work. Furthermore, a note is insufficient. I need to use some sort of formalized structure, preferably something standardized (e.g. by OMG) to express this because I am programmatically processing the model elements (i.e. it isn't just a picture). I understand how the underlying model for UML provides for this facility. It also specifies (though slightly vaguely) how it should be notated. I guess my main issue is, in fact, with finding a tool that allows me to make that notation. I don't think MagicDraw does so. I should have stated these things earlier.
FWIW, I'm using MagicDraw. It would be a nice bonus if the I could do this in a way that MagicDraw actually understood. I can live with it if that isn't possible.
The xor constraint is just a stylized and rather under-specified constraint for the 2-way case.
You can define an explicit constraint (in Complete OCL) as:
context A
inv OnlyAorBorC: A->size() + B->Size() + C->size() <= 1
MagicDraw may allow you to specify a similar contextual Constraint on A.
If "X", "Y" and/or "Z" can be somehow generalized (I mean, if you not doing this puraly for a conditional flow control), you can make an interface (or and abstract class) "I" for example, and make "X", "Y" and "Z" implement this interface. Then, you put an association with multiplicity 1 between A and the interface I.
See the diagram below:
Edit: The example above doesn't work in the case of A having different cardinalities between X, Y and Z. For this case, the only way that I can see is use an UML Constraint to restrict those relationships. You can define a Constraint in UML putting some OCL expression between curly braces. E. g.
Here, account owner is either Person or Corporation and this {xor} is predefined UML constraint.
I'm not sure about the details of your cardinalities requirements but, a combination between this {xor} and the interface example that I gave might be enough. At least it gives you a little bit more of options, like:
If you need to know more about the UML constraints subject, I got this example from uml-diagrams.org: http://www.uml-diagrams.org/constraint.html
I'm really a beginner in dealing in Java, suprise, and we have have to make an UML class chart for a situation. I'm totally unsure about my UML-diagram and I wanted to ask, if someone with a little bit more expierience could take a look. Thank you.
This is the situation:
For poker in the Texas Hold'em variant following information is given:
For a pokergame you need between two and twelve players and a card deck, that has 52 cards. Each card has a label (e.g., "King"), a value (2 to 14) and a color (e.g., Cross). Further specified for a poker game are the sum of all inserts (the pot, e.g., 450), and five (common) cards from the deck.
For each player the name, the credit (e.g., 7592) and the current hand, two cards from the card deck and a value (e.g., "Full House?").
For each player it is also noted whether he has the dealer position or not.
Task: Design an UML class chart for the game without functionalities (the classes to be used are indicated by bold). For the classes, type the necessary instance variables, including their (Java-compliant) data types. Draw all the relationships between the classes. Pay attention to the information given above multiplicities.
This is my solution:
What is meant by functionalities? Did I do the relations right? Do I need methods?
I tried to get the information from the text into a diagram:
You could replace the enumerations by plain attributes of type 'String'. I didn't fill out all values of HandValue (the three dots are not valid UML).
It is not clear to me whether a hand always has a value. If it has, then replace multiplicity 0..1 by 1.
If I understand the text correctly, a hand has only two cards, but this seems odd to me, I think it should be five.
You could add a composition diamond on the association between CardDeck and Card, but it is not clear from the text whether this is appropriate.
You could add a constraint, that the commonCards of a PokerGame should be a subset of the cards of the cardDeck of the PokerGame; also, that the cards of the hand of each of the players of the PokerGame are a subset of the cards of the cardDeck of the PokerGame.
You could draw an open arrowhead at the end of each association (not a triangle arrowhead; this would mean generalization), i.e. at the side where I have mentioned the multiplicity and the instance variable name.
You could specify multiplicities at the other ends of the associations, but these multiplicities are not mentioned in the text.
I didn't specify any visibilities (public/private/protected), because these are not specified in the text either.
You should not so much care about aggregation. This does not add much value to a design (but only in rare cases). Firstly your arrows are wrong. They represent generalization in UML. You need simple associations. Just leave away the arrows (which need to be unfilled open triangles) except you want to express navigability to be just in one direction (which in most cases is also nothing you need absolutely). What you should do is to use roles at the ends of the associations rather then putting typed properties in the classes. Further you should follow conventions that say class names start with an upper case letter (though I'm not really familiar with Java).
The above is a partial model to show what I mean. Note that I have added a dealer association. This assures that there is exactly one dealer in the game. The {subsets players} constraint tells that the dealer must be one of the players (thanks to JimL. for the hint). Using just the flag could lead to multiple dealers with the flag set. There should be a constraint that tells isDealer is true only for the one that is linked with the dealer association.