Assume that:
Class A has a collection of Class B (aggregation/composition)
Class C accesses the interface of Class A to obtain specific instances of Class B
Class C manipulates/uses the interface of Class B instances it gets
It follows that without a doubt, Class C has a relation with Class A. However one question remains: Should a relation be mapped from class C to class B, and why?
Yes, you should have the usual association (arrow) from C to B. Because having association means C have navigation from C to B.
As C can manipulate with B instances, the navigation from C to B also exists, and the back arrow is also necessary.
As the association works both-side, both arrows should not be shown. The contemporary UML standard does not use drawing of two-sided arrows.
If C has also fields (not local variables!) of type B, the C-B line should have the point on the B end. The same for the back direction. Look for examples here
Related
I’m trying to understand one of uml test questions. The associations are different between base and inherited classes, but do inherited classes also inherit the association between base classes, I mean, do inherited classes actually have two associations?
I also have different statements, from which I need to choose the correct one. The right answer is A, but I don’t understand why A is correct and other are not, so if it is possible, please explain every statement.
A) An instance of the ConcreteSubject class might have a reference to zero or more objects of the Observer type.
B) Each instance of the Observer class has a reference to exactly one instance of the Subject class.
C) Each instance of the Subject class has a reference to exactly one instance of the Observer class.
D) An instance of the ConcreteSubject class cannot have any reference to an instance of any other class.
E) An instance of the ConcreteObserver class might have a reference to zero or more instances of the ConcreteSubject class.
Thank you!
[This question and answer hopefully creates some pressure on universty teachers to care about the quality of their exam/quiz questions.]
First, it is important to note that the class diagram has several flaws. The role names "subject" and "object" are at the wrong (opposite) association end. Then, as you have wondered, the subject-objects association has been duplicated, since it is inherited.
Concerning the questions, both answers A and B are correct, while all others are wrong. This follows directly from reading the multiplicity constraints of the one-to-many subject-objects association.
Btw, the wording of answer options B and C is kind of flawed: it may be confusing to say "each instance of the Observer (or Subject) class", since these classes are abstract (visualized by names in italics), which implies that they do not have their own (direct) instances. However, in a general sense, one can say that they do have instances, namely all instances of their concrete subclasses. Therefore, these two answer options are confusing. But it is an important fairness requirement for any kind of exam not to use confusing questions.
I guess that your teacher considers answer B as wrong because it is about instances of the abstract classes Observer and Subject. However, in its current form, answer B is correct. It would only be incorrect, if it would be reworded as "each direct instance of the Observer (or Subject) class".
Answer C is incorrect because an instance of the Subject class may have no link to any Observer (this is implied by the 0 in the 0..* multiplicity expression).
Answer D is incorrect because the model does not contain any such constraint (which, btw, doesn't make any sense).
Answer E is incorrect because it contradicts the multiplicity constraint that any observer must observe exactly one subject, expressed by the multiplicity expression 1.
I have some objects that I want to draw a UML diagram for. The first, A, is an interface, and second, B, is an abstract class which is derived from A. The other class are C and D. C and D are subclasses of B.
B has a list of E class objects.
F is a class which all operations are performed in it. C and D class objects creates in the class according to polimorphism operations and then calls its methods according to users input.
Of course, there is a main class. The main class only creates F class object.
I want to draw a UML class diagram. What should the image be like? How can I draw F class ?
The uml class diagram which is writen by my is here.
By the way I know that's the very basic image, I'll edit it after you response.
Based on your description, this is what I think the UML diagram would look like.
For this statement "F is a class which all operations are performed in it. C and D class objects creates in the class according to polimorphism operations and then calls its methods according to users input."
It sounds like you would need to make a relationship between A and F because you are talking about polymorphism. A should have methods. B and C could have those same methods. F doesn't need a relationship to B or C because the relationship to A implies there is a class implementing A but the concrete class name is irrelevant.
Since I can not add a comment. I would suggest two points:
- Maybe the aggregation could be changed in composition if Main class gets an attribute of type F, otherwise a dependency would modelize better the relation between Main and F.
It would be more precise if a cardinality were defined on B side in the relation between B and E.
Hoppe this help to improve the good answer of ProgrammersBlock
I'm trying to make a classdiagram, but i'm having a problem. I'm not sure if I have to draw this relationship.
Example:
Let's say I have three classes, A, B and C.
I have an instance of A and B.
In class A, I create an intance.
Now I pass C to B.
I'm sure I have to draw a relation between A and C.
Do I alse need to draw a relation between B and C?
Thanking you in advance.
For class instances, there is UML's object diagram.
I have a class (Class A) which contains objects of type Class B. Class B has three subclasses.
Should Class B actually be an interface and then I can draw an aggregation association between the interface and Class A (and the three subclasses implement the interface)
or
Should Class B, be an actual Class, have 3 sub-classes and all four of the classes (Class B + 3 subclasses) implement the interface (through Class B)?
I would say to ask yourself these questions:
1. Would you ever create an instance of Class B? If yes, then it should be a regular class. If not,
2. Should class B contain any functionality that the derived classes should be able to use? If yes you should create an abstract class that the other classes inherit, if no, make it an interface.
If Class A contains objects of type Class B that means that Class B is instantiated, therefore it can't be an interface.
I have 2 questions about class diagram. firstly if i have used an object of class A in my class B , in drawing the class diagram i should associate class A with B . or association is just used when a class uses a method of the other class.
my other question is almost similar. if in class A i have a dictionary< class B, Class C> , then in class diagram should i associate the class A with B and C and say 'use'in connection?
In my view, in both cases it is a Dependency you show, not an Association.
In UML, the relationships tend to cover:
Dependency
Association
Generalization
Relization
In your case, the closest is a Dependency from Class A on B and C (represented with dashed line with arrowhead pointing to B and C). You're not directly associating (via aggregation or composition), you're not generalising A into B or C (or vice versa) nor are B or C realizing A (or vice versa).
If in doubt, I strongly suggest using a UML reverse-engineering tool and writing the source-code skeleton you know of, and see what it suggests. I use, but don't necessarily recommend, Enterprise Architect.
Associations are used when the A class "will" have an attribute of type B. I.e. at the UML level this is indicated using associations. At the code level, e.g. Java, these associations are transformed into attributes in the participant classes (one or two depending on the navigability properties of the association)