Showing posts with label uml. Show all posts
Showing posts with label uml. Show all posts

2010-07-01

Relationships Between Classes

Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the relationship between them. The following table shows the kinds of relationships between classes, their notation, and what they mean.

Sr. No.RelationSymbolDescription
1AssociationWhen two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:
1 a.MultiplicityAn example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).
1 b.Directed AssociationAssociation between classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.
1 c.Reflexive AssociationNo separate symbol. However, the relation will point back at the same class.An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.
2AggregationWhen a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.
2 a.CompositionComposition is a variation of the aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.
3Inheritance/GeneralizationAlso called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.
4RealizationIn a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.