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.
Related
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
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
Someone can help me with the question below?
How is a bidirectional non-containment relation (= “normal” association according to UML 2.0) modeled within EMF?
Create two references a -> b, and b -> a. Then set one reference as the opposite of the other.
I have a situation where class A has a B and cannot exist without the B, but B can exist completely independent from the A.
From the perspective of A this is a composition relationship, but from the perspective of B this is an aggregate relationship.
What do I do??
If A is composed of B, it is association with composed end on A class side. Composition and aggregation are types of association ends. It is possible to have composition on the one side and aggregation on the other side.
You can identify composition by answering question.. is Class A composed of class B ? If yes, it is composition on class A side... example: Is computer composed of memory, CPU etc ? All computer components are in composition with computer.
Example for aggregation: particular chair is placed in room. It is aggregation, because the room is not composed of chair (room is composed of walls, window etc.). But chair can be in composition with furniture placed in room.
In common usage, an association would not be both composition and aggregation and it depends on the application. A taxi/tire relationship would be composition with the black filled diamond adjacent to the taxi. The tire can exist in a parts department independent of the taxi, but a taxi cannot be dispatched without 4 tires. The parts department can exist without tires so that would be aggregation.
Your abstract example is either an aggregation or a composition, where the parts are separable (in the sense that they do not existentially depend on the aggregate). You didn't make any statement about the exclusivity of your B parts. If they cannot be shared among two or more A's, then your association between A and B is a composition.
Notice that it's a widespread mistake to think that composition is defined as an aggregation where the composite existentially depends on the component. The UML Specification states that this is typically, but not necessarily, the case for compositions. Rather what defines a composition is that the components are exclusive parts that are not shared with other composites.
See also my answer to a related SO question.
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)