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
Related
I'd like to express (visually) in UML that class Foo returns class Bar. The Bar object is created in one of Foo's methods and returned as a result.
I don't know whether to use a dependency or association relationship for this. Any suggestions?
EDIT
I should clarify that the UML diagram I'm working on doesn't contain any class attributes or operations. It's just intended as an overview that shows relationships between classes. Descriptions of attributes and operations are already generated from the source code (via Doxygen).
EDIT 2
I should further clarify that I want to show this relationship from a class diagram. I apologize for not being clear from the start.
EDIT 3
Upon further digging around, looking at examples, I realized that it's more important to document that Foo creates Bar. The fact that one of Foo's methods returns Bar is an implementation detail that I can leave out of my class diagram. So now, my question is: what's the best way to show a "Foo creates Bar" relationship in a class diagram?
As I've mentioned in my third edit, I realized it was more important to document the relationship that Foo creates Bar. The fact that some of Foo's methods return Bar is a detail better left to the Doxygen documentation (in my situation anyway).
As mentioned by others, the fact that Foo returns Bar can also be represented in the operations compartment of the Foo class, or in behavioral diagrams. But in my question, I've constrained myself to only class diagrams without listing attributes and operations.
I've done some digging around, and have discovered that UML has the <<create>> predefined stereotype for a usage dependency, illustrated here as
+------------+ +------------+
| | <<create>> | |
| Datasource +-- -- -- -- -->+ Connection |
| | | |
+------------+ +------------+
The <<create>> stereotype is described in the UML 2.4.1 Superstructure specification, page 704 as:
A usage dependency denoting that the client classifier
creates instances of the supplier classifier.
A usage dependency is (UML 2.4.1 Superstructure, page 139)
a relationship in which one element requires another element (or set
of elements) for its full implementation or operation.
Furthermore:
The usage dependency does not specify how the client uses the supplier
other than the fact that the supplier is used by the definition or
implementation of the client.
The UML spec also has the <<instantiate>> predefined stereotype, defined as:
A usage dependency among classifiers indicating that operations on the
client create instances of the supplier.
There seems to be some overlap between the <<create>> and <<instantiate>> stereotypes.
Return types from methods are expressed in the method definition within the class. Most tools can turn on/off attribute and method visibility. If class Foo creates or operates on class Bar, you can use a directional association from Foo to Bar. It doesn't sound like a dependency.
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.
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.
Is it valid to have an Interface as part of a sequence diagram. For instance, is the following UML valid? The purpose of the interfaces is to show extensibility and testability points in the design. You could extend by providing a different implementation for each interface and better test by replacing the interfaces with mocks. However, I don't know if this violates the rules of UML. Thanks in advance.
GameService:IGameService GameRepository:IGameRepository
| |
| |
|--------------------------->|
| |
| |
| |
P.S.: Sorry for the poor's man diagram.
Yes, this is possible. Both classes and interfaces are subclasses of Classifier in the UML metamodel. Classifiers are the ones linked to the elements in the sequence diagram
Of course a lifeline in a sequence diagram can represent an (instance of an) interface. From the perspective of the diagram, it doesn't matter much---there are no restrictions on where the operations/messages on the events should come from.
If you want to indicate that the operations have to come e.g. from the signature of the target (IGameRepository), you have to document/encode this separately, e.g. in OCL.
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