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.
Related
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).
I have one object, call it type A which has four data members of another object type, call it B. How do I show this in a UML class diagram so that its clear there are four B objects type in every A object?
Is the only solution to put "4" next to the arrow head pointing to class B?
It depends on what you want to achive, in sense of how you need to distinguish between those objects in context of their association/link, that is - what kind of role they play:
if there are all equal, no special differences in their role in context of A, them a multiplicity 4..4 will do the job, naming the association end properly (for example my_Bs)
If these object play different role in connection with A, then you can use separate associations with lower multiplicities each one, 2, 3 or even 4 pieces (for example, if B is a Wheel and A is Car, then you can put 2 associations with multiplicities 2..2 each, and call then "front" and "rear", or even 4 associations "front_left", "front_right"...)
Here is how the both cases look like. On the second one I showd different possible options (with max. 5 elements of B), just to give you an idea.
It's probably clear by now, but the fundamental concept here is the role of the association end.
Aleks answer is the best. However you can also represent the multiplicity in one box like this :
You cal also use composite structure diagram. See example below:
From my point of view, myBs defined as an attribute of type B on class A has a different meaning of myBs defined as a association's role between A and B (which is also different as defining it as a composition/aggregation).
If it is an attribute, then it's not a role. In that case, there is only a simple dependency relation between A and B, which must appear in the diagram.
I think that problem comes from unconsciously think from a "Relationnal Data (BMS)" and/or a "Object Oriented Programming" point of view, but UML is not intended for that.
:)
What is the differences between property owned by an association and a property owned by a class in UML?
is there a simple example helps me understand the differences?
The difference is more conceptual than anything else. If you have a property attached to an association, then you will have an association class, with the desired property.
Here is an example of a mailman sending letters to clients (the attribute weight is bound to the association):
The difference is very concrete, but traditionally ignored.
A is associated to B. A,B are classes.
If B end of the association is "association owned" and navigable, it means, that you can easily reach instance of B from A, either by reference, or by some method(s). It should be shown by arrow.
If B end is "classifier owned", you know a bit more. it means, that A has an attribute, that is a direct reference. (No functions or reference counting here). It should be shown by arrow and "dot"- a small black filled circle.
If you are going to B by a.smth.smthelse.b, it is arrow, but surely no dot.
If you are going to B by a.b, it is arrow and dot.
If you haven't decided yet, it is arrow again.
Traditionally modellers show arrows only. But it is not a good tradition, and is against UML standard. Diagrams are more useful if we decide as much as possible on them, not in code.
If both ends are navigable, both arrows disappear and you may see only dot(s).
The association lines with cross with dot on one side, or arrow on one side and only dot on the other are senseless.
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