I want to create a uml diagram that can represent sentences as the one below:
"On 21/03/2020, baker A purchased from the flour company B 20 Kg of type AAA flour for 1.20 euros per kg, that he later used to produce 70 pieces of bread that he then sold to different costumers of his shop on 23/03/2020 with the price of 1.10 euro per piece."
Below you can see my first thoughts. This is quite general, I haven't added attributes yet. My problem is that I'm not sure how to represent that 2 different people make the transaction, the buyer (ie baker A) and the seller(company B), and how to show that someone (ie baker A) can be both a buyer(ie he buys from B) and a seller (ie A sells bread to costumers):
First notice that a UML Class Diagram can only represent sentence types, but not a specific sentence, which could, however, be represented by what is called an 'Object Diagram'.
How to represent that 2 different people make the transaction, the
buyer (ie baker A) and the seller(company B)
You have already represented this in your second class diagram with the associations between Buyer/Seller and Transaction, but since you've also defined Buyer and Seller to form an overlapping segmentation of Trader, you need to attach a constraint "buyer is distinct from seller" to your Transaction class.
For completeness, you should also add multiplicities at both ends of these two one-to-many associations ( a "1" at the Buyer/Seller end, and a "*" at the Transaction end).
How to show that someone (ie baker A) can be both a buyer(ie he buys
from B) and a seller (ie A sells bread to costumers)
This is already possible according to your second diagram where every Buyer and Seller is a Trader, and this segmentation is overlapping (by default), and therefore a trader can be a buyer in one transaction and a seller in another one.
There are many more diagram types than class diagrams. Do you have any constraint that it must only be one diagram? If so, why? Each diagram type focuses on a particular view onto the system under design, so they go together. It is not the purpose of UML to reflect all information in just one diagram. For example, try to complement your diagram with an acitivity diagram or sequence diagram. You'll find it helpful.
how to show that someone (ie baker A) can be both a buyer(ie he buys from B) and a seller (ie A sells bread to costumers)
You did that already with the abstraction of the Trader.
I'm not sure how to represent that 2 different people make the transaction, the buyer (ie baker A) and the seller(company B)
Just add them to Transaction as attributes.
Hint: The relation "Unit / Price / Product" is not UML compliant.
Related
Here is my sample shown also on picture below
#startuml
participant "Client" as C
participant "Server" as S
participant "Third Party" as 3PT
C -> S++: request money
S -> S: do I know you?
S -> 3PT++: give me money for client
return here you have money
S ->> S++ #005500: compute usage
S ->> 3PT: notify about computation details
deactivate S
return money
#enduml
Is it possible in PlantUml sequence diagram somehow define the lifeline for async operation to end after lifeline from which it was started? So in this case I'd like to finish the compute usage in green lifeline after return from request money lifeline. By that I would say that compute usage is asynchronous operation and can end at any time. Don't know whether this is valid from UML point of view though.
As I know there is no way for a reflexive message like S ->> S++:... or S ->> S:... to start from an OccurrenceSpecification and finish to an other (and that for a lot of tools, including mine), so the only way seems to represent the Server two times. To clearly indicate it is the same server you can indicate the name the instance, for instance (naming all instances):
#startuml
participant "c:Client" as C
participant "s:Server" as S
participant "tp:Third Party" as 3PT
participant "s:Server" as Sagain
C -> S++: request money
S -> S: do I know you?
S -> 3PT++: give me money for client
return here you have money
S ->> Sagain++: compute usage
C <-- S: money
deactivate S
Sagain ->> 3PT: notify about computation details
deactivate Sagain
#enduml
The norm says §17.12.17.1 lifelines represent only one interacting entity, but an entity can be presented by several lifelines :
norm § 17.12.17.4 (association ends of Lifeline)
represents : ConnectableElement [0..1] (opposite A_represents_lifeline::lifeline)
References the ConnectableElement within the classifier that contains the enclosing interaction
norm § 17.13.31.2 (Owned Ends of A_represents_lifeline)
lifeline : Lifeline [0..*] (opposite Lifeline::represents)
(notice the multiplicity 0..*)
Out of your problem it is strange to see the message do I know you? alone without consequences depending on the result, PlantUML manages combined fragment alt to indicate alternatives
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.
I have two classes Person and Department with two associations between them
works and
manages,
and between these two associations there is a {subset} (manages associations are subset of works association).
What should I infer about the object diagram?
Each Person which is a manager has two links to his department (one for works and the second for manages), or
each Person which is manager has only one link to his department?
By the way, besides {subset}, {nand}, {and} and {xor}, is there any other constraint notation which you can put in a class diagram?
Since you have defined two associations the objects will have two links. Simple as that. You might add a note that works is redundant in case manages has a non-zero multiplicity (since it will have one of 0..1).
You can place any constraint you like between associations - as long as they make sense.
Superstructures 2.5 states on p.111:
<prop-modifier> indicates a modifier that applies to the Property.
<prop-modifier> ::= ‘readOnly’ | ‘union’ | ‘subsets’ <property-name> |
‘redefines’ <property-name> | ‘ordered’ | ‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’ | ‘id’ | <prop-constraint>
Notice that a subsets constraint can be defined between association ends (reference properies), but not between associations. So, your question should be better stated as follows. Given a class Person with the two reference properies managedDepartment and department, representing corresponding functional associations between Person and Department, the constraint
managedDepartment subsets department
implies that for any person object p, the set of departments managed by p is a subset of or eqal to the set of departments p works for. This formalizes the business rule that a person can only be the manager of a department at which (s)he works. Symbolically,
p.managedDepartment subseteq p.department
Alternatively, one could define that the manages association specializes the worksAt association, which would imply that for any manages link there is a corresponding worksAt link.
This is the best question I've seen in a while! To answer your two questions directly:
Yes, by using Person manages {subsets works for} Department, each Person who is a manager will have two links to Department: one for works for and one for manages.
Another useful constraint you can use on a property in a class diagram is {redefines}.
Redefining a property allows you to change a property's name and tighten constraints within the context of its owning class (and within the context of subclasses). For example, you can say the following things:
In general, Deck contains 0..52 Cards
A subclass of Deck called Monster Deck only contains {redefines contains} 0..10 Monster Cards
Another subclass of Deck called Player Deck only contains {redefines contains} 0..10 Player Cards
And so on..
This is very handy for expressing requirements and business rules.
I am reading "UML distilled" by Martin Fowler, and during reading about association classes I got this quote:
What benefit do you gain with the association class to offset the
extra notation you have to
remember? The association class adds an extra constraint, in that
there can be only one instance of
the association class between any two participating objects.
Then there was an example, but I want to make sure I got this right, if for example I got:
--------- ---------
| |* *| |
| CLASS A |----------| CLASS B |
| | | | |
--------- | ---------
|
______|______
| |
| |
| CLASS C |
| |
|_____________|
then, for every distinct pair (instance of A,instance of B) there exists only one instance of class C.
So if I would take A1,A2,B1,B2-instances then for (A1,B1) (A1,B2) (A2,B1) (A2,B2) I would get 4 instances of C, nothing less, nothing more?
From the UML 2.5 specification:
Note that when one or more ends of the AssociationClass have
isUnique=false, it is possible to have several instances associating
the same set of instances of the end Classes.
Mr. Fowler may have gotten the facts wrong. There is no extra constraint, just the ability to store additional property values.
When isUnique=false, extra properties allow one to model multiple visits to the same doctor on different dates, or multiple purchases of the same products on different dates, for example.
That'd be correct, without any intention to mix concepts here but it's similar to Tables in a database where:
A 1-* C
B 1-* C
Where C can be seen as the result of breaking a many to many relationship between A and B.
For each row on B can only exist 1 and only 1 Row C and That Particular row (on C) can only me related to 1 row on A.
Hence, for each Pair of unique rows on A and B can only exist 1 row on C or none, because the * indicates 0 or more.
Your reasoning is correct: if an association class does not have one or both association ends annotated with {nonunique}, then it implies the constraint that there can be only one link between the same objects (as explained by Martin Fowler).
Notice, however, that the option of non-unique association ends has only been added in UML 2 (in 2005), and Martin Fowler's book (from 2003) refers to UML 1.x.
Some examples may help. For instance, the association LandPurchase between Person and PieceOfLand could be modeld as a UML association class (with default unique association ends), since there can be only one purchase link between a person and a piece of land. The association ProductPurchase between Person and Product can only be modeld as an association class if the association end at the Product side is annotated as {nonunique} since there can be more than one purchase link between the same person and the same product (as a type). For instance, I can buy more than one Tesla Model S cars (if I would have the money).
Similarly, in the case of Appointment between Person and Doctor, since the same person can have more than one appointment with the same doctor, the association end at the Doctor side has to be annotated as {nonunique}.
Association in UML represented (have) logical sens (UML is not tool for database modeling!). Association describe possible logical fact. E.g. Two person A and B could be married, we can draw this as association, it is representing meaning like a "we know that exist an logical connection between person A and person B". If we know what that is, we draw class association [marriage cerificate] as materialised fact.
Say we have the diagram:
I wonder whether it's known by the diagram who owns the methods.
For instance: Is pickup a method of Waiter? Is serve food then a method of Patron?
More generally, do the arrows show the owners of the methods?
This is a counterintuitive (ie bad) choice of method names.
Fred is ordering the food, that's right. He's ordering the food by calling takeOrder(), which belongs to the waiter. Imagine Frank tries to call order food on anyone other than a waiter. It wouldn't work, because they're not waiters, and they don't have takeOrder().
The methods belong to the objects that are being called.