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.
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.
Let's say I have class Foo that has an association to some thing(s) that fulfill(s) a role. This role could be fulfilled by either (strictly) one Bar xor any number of Baz. Similarly, the role might be fulfilled by either any number or Bar xor any number of Baz (but a mixed collection is intolerable). Are there reasonable ways to represent these in a class diagram using only associations, classes, and interfaces? I would (really) like to avoid using OCL or constraint elements.
(The reason I would like to avoid these is because we are generating code from our UML. We have already implemented generation that handles associations, classes, and interfaces. Dealing with OCL would be quite the task. Constraint elements wouldn't be so bad but still quite a lot of work.)
I would start with the picture below and create several different versions before deciding which one generates best code (junior-40).
The yellow blocks represent necessary "glue code" needed to straighten your example against your other requirements
Consider creating an abstract class Thing and derive Bar and Baz from it. It abstract the whole role, can contain some own atts and methods if needed and is quite flexible and extendible.
Now Account has an association only with AccountOwner (role "role", as Jim L. has explained in his comment, a role name must be unique in this context).
Note that this does not eliminate the need of some additional restrictions. For example, all linked "roles" should be of the same type. Sometimes is not easy (or even possible) to remove all restrictions. Otherwise we would make complete systems out of class diagram. I agree though, that as much information as possible should be contained in classes, their taxonomies and features (atts, assocs and methods).
EXAMPLE:
EXAMPLE 2 (after comments):
This version overcomes the need to use OCL ant yet keeps the simplicity and flexibility:
Multiplicities are now also derived and refined for each concrete "role". No OCL needed. :)
You add a constraint on the class in OCL:
(self.role->exists(r|r.oclIsType(Bar)) and self.role->notexists(r|r.oclIsType(Baz)) ) or
(self.role->exists(r|r.oclIsType(Baz)) and self.role->notexists(r|r.oclIsType(Bar)))
You can try this out with MDriven Designer.
The reason for introducing OCL (object constraint language) in the UML specification was just this; ability to add constraint not possible or practical to convey with simple cardinality and type information
Could this image help you ? It is extracted from the norm.
Are you thinking of something like the following:
(source: uml-diagrams.org)
Where Account is your Foo, Person is your Bar, and Corporation is your Baz.
You can then specify multiplicity on each of the two associations: [1] for Bar (Person) and [1..*] for Baz (Corporation).
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.
:)
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
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