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.
Related
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.
Say I have a relationship like this
Class Lion{
private int health;
public void eat(Food f){
health+=f.getweight();
}
}
Class Food{
private int weight;
}
Then, am I right to say that the relationship is an association but not an aggregation or composition.
And can I say that Lion uses Food and draw the UML Diagram like this
+-----+ +-----+
| Lion| _____uses___>|Food |
+-----+ +-----+
Also this relationship would have no multiplicity because Lion does not have an array of Food, neither does food have an Array of Lions as instance variables. Unlike in composition and aggregation where the relationship has a multiplicity.
What if I wish for Food to use Lion in the same way too. Do I Draw two arrows between the two classes?
A <<uses>> relation is a dependency and not an association, which makes much sense with Lion and Food since the association would have been gone once the Food is swallowed by the Lion.
As for the aggregation: this is about the lifetime of objects. A shared aggregation has no defined semantics and shall only be used after the domain has defined it. A composite aggregation tells that the aggregated object dies along with the object aggregating it. That would not really make sense. If the Lion is shot the Food is still there.
I would not know how Food would make use of the Lion at all.
In fact, Food is not a Property or an Attribute of Lion, so the relation between them is not an Association. The fact that you can not specify the multiplicity is also another hint for saying that the relation between Lion and Food is not an Association.
Your Lion Class uses Food to eat so you can think about the UML Usage relationship. But according to UML Specification "A Usage is a Dependency in which the client Element (aka Lion) requires the supplier Element (aka Food) for its full implementation or operation. This is not your case here, you just need to know that the Food exist, you do not really care about its implementation.
So in fact if Lion knows what is Food , you do not need any relationship between them (Cf screenshot ).
Just if your Lion does not know what is Food you need an ElementImport relation between them.
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.
This is embarrassing, I apologize for not including the diagram image ( I thought I included it, but I should be more careful and verify it in the post )
I know almost nothing about UML, but to my knowledge an arrow with hollow head represents inheritance relationship ( ie ANDSpecification class inherits from CompositeSpecification class ), while the other type of arrow tells us we can navigate from ANDSpecification to CompositeSpecification?
a) But why does the diagram connecting ANDSpecification and CompositeSpecification contain both types of arrows? Perhaps because in addition to ANDSpecification inheriting from CompositeSpecification, it also has a property of type CompositeSpecification?
b) What is the meaning of numbers next to arrows?
First of all, could you please provide the source of your class diagram implementation, your inputs are not clear enough to determine the realtionships between the classes.
(A) There are two types of arrows, the arrow with a rectangular head describes "Generalization".
The specific classifier inherits part of its definition from the
general classifier. The general classifier is at the arrow end of the
connector. Attributes, associations, and operations are inherited by
the specific classifier. Use the Inheritance tool to create a
generalization between two classifiers.
The second type of arrows describes "Association"
A relationship between the members of two classifiers. There are two
types of it, Aggregation and Composition.
(B) The numbers beside arrows simply describes "Multiplicity"
Multiplicity of an association end is the number of possible instances
of the class associated with a single instance of the other end.
┬─────────────────────────┬───────────────────────────────────────────────────────┬
│ Multiplicities | Explanation |
│ | |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|0..1 | zero or one instance. |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|0..* or * | no limit on the number of instances (including none) |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|1 | exactly one instance |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|1..* | at least one instance |
├─────────────────────────┼───────────────────────────────────────────────────────┼
You can find helpful examples in the links below.
Explanation of the UML arrows
http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
http://edutechwiki.unige.ch/en/UML_class_diagram
If I had a class Airplane and a class Wing, if there was a composition relationship between the two, does Airplane have a member variable of type Wing in the class diagram, shown in the Airplane box?
ASCII art!
+-------------+ 1 1..* +----------+
| Airplane |<*>------------| Wing |
+-------------+ +----------+
where <*> represents a filled diamond, indicating composition. I used multiplicity 1..*, since it's possible to have aircraft that are essentially a single wing (such as the B-2), and although nobody builds them anymore AFAIK, you have biplanes (2 or 3 wings, depending on how you're counting), triplanes, etc.
No. Compositions and aggregations are kinds of associations and are shown like associations, i.e., with lines between classes (with solid and hollow diamonds, respectively, on the containing side). As a general rule, if you have an attribute whose type is a class, your model is wrong.
Implementation is a completely separate matter from analysis/design. You may implement associations in a variety of ways, including using member variables e.g. in C++.
I'm not sure at 100%, but as far I remember no. Is just implicit that u will'have a variable of type Wing.
No, it doesn't. But that doesn't mean that you can't have an attribute that is of class type. You just can't have both. It's a choice about what you want to emphasise.