Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency in OOPS

Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency

26/06/2010

These terms signify the relationships between classes. These are the building blocks of object oriented programming and very basic stuff. But still for some, these terms look like Latin and Greek. Just wanted to refresh these terms and explain in simpler terms.

Association

Association is a relationship between two objects. In other words, association defines the multiplicity between objects. You may be aware of one-to-one, one-to-many, many-to-one, many-to-many all these words define an association between objects. Aggregation is a special form of association. Composition is a special form of aggregation.

Example: A Student and a Faculty are having an association.

Aggregation

Aggregation is a special case of association. A directional association between objects. When an object ‘has-a’ another object, then you have got an aggregation between them. Direction between them specified which object contains the other object. Aggregation is also called a “Has-a” relationship.

Composition

Composition is a special case of aggregation. In a more specific manner, a restricted aggregation is called composition. When an object contains the other object, if the contained object cannot exist without the existence of container object, then it is called composition.

Example: A class contains students. A student cannot exist without a class. There exists composition between class and students.

Difference between aggregation and composition

Composition is more restrictive. When there is a composition between two objects, the composed object cannot exist without the other object. This restriction is not there in aggregation. Though one object can contain the other object, there is no condition that the composed object must exist. The existence of the composed object is entirely optional. In both aggregation and composition, direction is must. The direction specifies, which object contains the other object.
Example: A Library contains students and books. Relationship between library and student is aggregation. Relationship between library and book is composition. A student can exist without a library and therefore it is aggregation. A book cannot exist without a library and therefore its a composition. For easy understanding I am picking this example. Don’t go deeper into example and justify relationships!

Ads by Google

Abstraction

Abstraction is specifying the framework and hiding the implementation level information. Concreteness will be built on top of the abstraction. It gives you a blueprint to follow to while implementing the details. Abstraction reduces the complexity by hiding low level details.
Example: A wire frame model of a car.

Generalization

Generalization uses a “is-a” relationship from a specialization to the generalization class. Common structure and behaviour are used from the specializtion to the generalized class. At a very broader level you can understand this as inheritance. Why I take the term inheritance is, you can relate this term very well. Generalization is also called a “Is-a” relationship.

Example: Consider there exists a class named Person. A student is a person. A faculty is a person. Therefore here the relationship between student and person, similarly faculty and person is generalization.

Realization

Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.

Example: A particular model of a car ‘GTB Fiorano’ that implements the blueprint of a car realizes the abstraction.

Dependency

Change in structure or behaviour of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other class it this happens.

Example: Relationship between shape and circle is dependency.

Q. Write and explain important relationships that are used in object-oriented modeling?

A relationship is a general term covering the specific types of logical connections found on class and objects diagrams. A relationship references one or more related elements. There is no general notation for a relationship. In most cases the notation is some kind of a line connecting related elements. Specific subclasses of the relationship define their own notation. Instance Level Relationships - Association- Association is a relationship between classifiers which is used to show that instances of classifiers could be either linked to each other or combined logically or physically into some aggregation. Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of another object inside it. Associations in UML can be implemented using following ways: 1) Multiplicity 2) Aggregation 3) Composition Multiplicity in UML: Multiplicity indicates the no of instance of one class is linked to one instance of another class. The various multiplicity values are listed below: Notation Description 1 Only One Instance 0..1 Zero or One Instance * Many Instance 0..* Zero or Many Instance 1..* One or Many Instance Aggregation:  Aggregation represents the set of Main Classes that are dependent on Sub-Classes, the Main class cannot exist without Sub-Class but the Sub-Class can exists without the Main Class. Aggregation (shared aggregation) is a "weak" form of aggregation when part instance is independent of the composite: the same (shared) part could be included in several composites, and if composite is deleted, shared parts may still exist. Shared aggregation is shown as binary association decorated with a hollow diamond as a terminal adornment at the aggregate end of the association line. The diamond should be noticeably smaller than the diamond notation for N-ary associations. Search Service has a Query Builder using shared aggregation Composition in UML: Composition represents the set of Main Classes that are dependent on Sub-Classes, the Main class cannot exists without Sub-Class and the Sub-Class cannot exists without the Main Class. The Sub-Class can represent only one composite relation with the Main class. Composition (composite aggregation) is a "strong" form of aggregation. Composition requirements/features listed in UML specification are: it is a whole/part relationship, it is binary association, part could be included in at most one composite (whole) at a time, and if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it. Note, that UML does not define how, when and specific order in which parts of the composite are created. Also, in some cases a part can be removed from a composite before the composite is deleted, and so is not necessarily deleted as part of the composite. Composite aggregation is depicted as a binary association decorated with a filled black diamond at the aggregate (whole) end. Folder could contain many files, while each File has exactly one Folder parent. If Folder is deleted, all contained Files are deleted as well. When composition is used in domain models, both whole/part relationship as well as event of composite "deletion" should be interpreted figuratively, not necessarily as physical containment and/or termination. UML specification needs to be updated to explicitly allow this interpretation.  Class Level Relationships- Generalization- The Generalization relationship indicates that one of the two related classes (the subclass) is considered to be a specialized form of the other (the super type) and superclass is considered as 'Generalization' of subclass. In practice, this means that any instance of the subtype is also an instance of the superclass. An exemplary tree of generalizations of this form is found in binomial nomenclature: human beings are a subclass of simian, which are a subclass of mammal, and so on. The relationship is most easily understood by the phrase 'an A is a B' (a human is a mammal, a mammal is an animal). The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line (or tree of lines) that connects it to one or more subtypes. The generalization relationship is also known as the inheritance or "is a" relationship. The superclass in the generalization relationship is also known as the "parent", superclass, base class, or base type. The subtype in the specializatioan relationship is also known as the "child", subclass, derived class, derived type,inheriting class, or inheriting type. Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading. Generalization-Specialization relationship A is a type of B E. g. "an oak is a type of tree", "an automobile is a type of vehicle"  Realization In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies. A realization is indicated by a dashed line with an unfilled arrowhead towards the supplier. Realizations can only be shown on class or component diagrams. A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface. Dependency-  Dependency relationship is used to show that some element or a set of elements depends on other model element(s), and on class diagrams is usually represented by usage dependency or abstraction. A dependency is rendered as a dashed arrow between elements. The element at the tail of the arrow (the client)depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an optional stereotype and an optional name. Data Access depends on Connection Pool It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.