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.
Related
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.
When creating relationships in an Object Class Diagram for an Object Relational Database, should the diamonds on the ends of the relationship links be filled in or not.
Here is an image of my Class diagram:
http://canning.co.nz/Weltec/Class_Diagram.png
It's a choice between Composition and Aggregation, which Wikipedia explains quite well.
In practice though, I think a valid answer is to just not worry about the difference, unless it's a school assignment. I've found that trying to make very detailed UML diagrams isn't terribly useful in practice.
Composition relationship has a coloured diamond shape structure ending at a class if it belongs to a 'is a' relationship (i.e- the entity cannot exist without the parent class) whereas the aggregation has an empty diamond shape ending at a class if it belongs to a 'has a' relationship (i.e- the entity can exist without the existence of the parent class.
A full diamond denotes Composition, or a 'owns' relationship. You use it when the referenced entity can't exist without the class representing it. An example would be order to order item. The order item just doesn't make sense without the order.
An empty diamond denotes Aggregation, or a 'has' relationship. A quick glance at your diagram makes me think this is the correct diagram element to use in your case.
But I agree with #mpartel: If there aren't any specific requirements to distinguish between the two just ignore the diamonds.
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.
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.
I usually get so confused with UML and this situation is no different.
Let's say I have an interface IAnimal, class Food and Cat:
interface IAnimal {
void Feed(Food food);
}
class Cat : IAnimal {
void Feed(Food food) {
//code
}
}
I've got 3 questions about drawing UML class diagram for these 3 elements:
I assume I should use association between IAnimal and Food or Cat and Food. Should there be an arrow on one side of the association line, if yes, then on which side and why there?
if I write Feed as an IAnimal method on diagram, should I write a method Feed inside class Cat or do I write only additional Cat methods?
the most important: should the association be between IAnimal and Food, Cat and Food, or both?
UML defines a number of relationship types.
Relationships have a number of different notations:
Association relationships have a base notation of a solid path
Dependency relationships have a base notation of a dashed arrow
Generalization relationships have a base notation of a solid path with a triangular arrowhead
Realization relationships have a base notation of a dashed arrow with a triangular arrowhead (a mix of dependency and generalization)
Pictorially
+---------------------------+
| <<interface>> |
| IAnimal |
+---------------------------+ +--------+
| + Feed(food: Food) : void |- - - - <<use>> - - - ->| Food |
+---------------------------+ +--------+
^
/_\
|
|
|
+-----------+
| Cat |
+-----------+
That is:
The relationship between IAnimal and Food is a usage relationship.
This is shown as a dependency with the stereotype «use»
The relationship between IAnimal and Cat is a realization relationship.
Association relationships are used to indicate connections between two or more classifiers. This implies that at least one of the classes has an attribute of the other type (or a collection). In fact, attributes and association ends contain the same information and can be interchanged.
So, IMHO, the relationships you describe should not be modelled as associations.
How picky you are about this kind of stuff depends to a great extent on what you're using UML for in the first place.
If you have some sort of whizzy UML-to-code translator, then you need to be picky (but it looks like you're more comfortable with code than with boxes and lines - so why would you use such a tool?)
If you're simply using UML to communicate with other people, then you can afford to be somewhat less picky.
Craig Larman's "Applying UML and Patterns" stresses this point, by including diagrams that look as if they've been sketched on a whiteboard. A solid line which the UML standard says should be dotted is fine in that sort of diagram. So with arrowheads and so forth.
It's clear to me that the line should go from IAnimal to Food.
Whether the arrowhead adds clarity (for human readers) is a matter of choice, but it indicates a unidirectional relationship:
From this introductory piece:
"In a uni-directional association, two
classes are related, but only one
class knows that the relationship
exists."
Assuming a class diagramm, you should have a "use" association between IAnimal and Food and a "is a" association between Cat and IAnimal and Dog and IAnimal:
IAnimal ----> Food
^ ^
// \\
// \\
Cat Dog
I'd argue that IAnimal would have HAVE-A Food, since it's metabolized, but if you really want to denote HAS-A I think it should be an aggregation (open diamond) or composition symbol (filled in diamond), depending on the cascading delete characteristics.
There are two schools of thought with UML, according to Martin Fowler. There are the "sketchers", who use the notation on whiteboards and odd pieces of paper to communicate enough of their ideas to fellow developers.
Then there are those who view UML as engineering drawings, where every last detail of a design must be captured.
I'm firmly in the former camp. As a former engineer, I can tell you from personal experience that UML does not have the power of real engineering drawings to fully capture a software design.
If you happen to believe in the latter, please do a complete desktop or web UI design using UML and post it here.
1) No associations should be written between the interface IAnimal and the type Food. Associations are only used to connect types with proprieties inside classes. E.G
class Animal
{
Food foodEaten;
}
class Food
{
//Implementation code
}
then you should write an association indicating the connection between those two types.
What you should draw instead is an dependency indicating that the interface IAnimal depends on the type Food. The dependency is drawn same as the association in the picture above, just change the straight line to a dotted one.
2) No, do not write those methods and do not write dependecies. Leave all notations only on the Interface IAnimal