Relation of UML with Object-Oriented Design

The relationship between the UML and object-oriented design is necessary to learn and understand. There are so many diagrams introduced in the object-oriented design such as a class diagram, object diagram, interaction diagram, and collaboration diagram. These all diagrams are designed based on objects. Object-oriented designs can be converted into the unified modeling language (UML) diagrams.  It can be done based on the requirements. The design phase is much secured than the other processes; input from object-oriented design will be taken as input by the UML diagram.

Analysis of common Object-Oriented design terminologies:

Abstract class: A class that does not keep the objects inaugurated from it.

Abstraction: The description of the essential features of a product.

Aggregation: Aggregation term defines “is part of” or “contains” relationships among two classes or elements.

Association: Objects are associated with other objects, known as an association.

Attribute: Attribute is something that a class keeps such as, data or information.

Class: A stencil from which objects are forged.

Cohesion: The severity of the germaneness of an encapsulated unit such as a component or a class.

Collaboration: This terminology defines that class work in a group (collaborate) to satisfy their liabilities.

Composition: An active mode of aggregation that defines that “whole” is entirely responsible for their parts, and every “part” object is associated with the “whole” object.

Concrete class: Concrete class can be defined as a class that has objects instantiated through it.

Coupling: The intensity of dependency among two things.

Information hiding: The stipulation of external connection to facets.

Inheritance: It defines “is kind of,” “is a,” and “is like” relationships. If class “B” acquires against class “A,” class “B” automatically inherits all the attributes, operations, and properties that “A” executes.

Instance: A class that defines object as their instances.

Instantiate: You can instantiate objects from classes.

Message: A message is a request for information or an offer to act.

Messaging: Classes transmit messages with each other to collaborate.

Single inheritance: If a class directly obtains from one class only, it is known as single inheritance.

Multiple inheritances:  If a class precisely inherits from one or more classes, it is known as multiple inheritances.

Object: An object is anything like a report, concept, event, screen, thing, place, or person, etc.

Object space: Object space blends the main memory and all accessible storage space over the network, combining resolute storage just like a RDBMS (relational database).

Override: Sometimes, you need to override attributes or methods in subclasses.

Polymorphism: Polymorphism defines that disparate objects can acknowledge to the same message in diverse ways, facilitate objects to reach out with one another without knowing their rigorous type.

Stereotype: It mainly denotes a trivial usage of a modeling component.

Subclass: We will say that any class “B” is a subclass of “A,” if class “B” inherits properties from class “A.”

Superclass: We will say that any class “A” is a superclass of any class “B,” if class “B” inherits properties from class “A.”

Three elements can be learned for efficient conceptual model:

  • Mechanism of UML
  • UML building block
  • Connection to UML building blocks

UML building block

Building blocks produce a complete model by rotating around several blocks. When developing UML diagrams, these building blocks play a vital role. UML is comprised of three building blocks, like things, relationships, and diagrams. These building blocks are categorized as below:

  1. Things
  2. Relationships
  3. Diagrams
  1. Things: Things are further divided into four types of categories:
  2. Structural thing
  3. Behavioral thing
  4. Grouping thing
  5. Annotation thing
  • Structural Things: Structural things are used to design a static structure of a system.

Seven Types:

  • Class: Class defines a set of objects having complementary liabilities. It also illustrates the abstract class whose functionalities are not established.
  • Object: Object is an individual that portrays the behavior and functions of the system. Object’s notation can be defined similarly as a notation of class. The only difference between these notations is that the object’s notation always underlined.
  • Interface: Interface represents a set of operations, which specify the liabilities of a class.


  • Collaboration: Collaboration defines interaction among elements.
  • Use Case:Use case describes a subset of operations executed by a system for an individual goal.
Use-Case Name


  • Component: Component represents the substantial part of a system.
  • Node:A node can be specified as a physical component that endures at run time.
  • Behavioral Things: Behavioral things are used to design the dynamic structure of a system. More specifically, it defines the behavior of the system.

Three Types:

  • Interaction: Interaction can be defined as an attitude that dwells of a group of messages exchanged between elements to achieve a specific task. It is used to predicts the flow of messages, among particular components in a system.
  • State Machine:State Machine is advantageous when the state of an object in their life cycle is essential. It preserves a record of several different states of a system component. It represents a flow of states that an entity goes through in the software development lifecycle (SDLC).


State 1





  • Activity Diagram:It illustrates all the activities proficient by different entities of a system. It is defined similarly to that of a state machine diagram. It concludes of an initial state, a decision box, an action notation, and a final state.


Action 1





  • Grouping Things: This thing is broadly used to group the elements. It has only one part.

One Type:

  • Package
  • Annotation Things: This is one of the most important things that used to define the various elements of a model. It also has only one type.

One Type:

  • Note
  • Relationships: This category is also divided into four parts:
  • Dependency
  • Association
  • Generalization
  • Realization
  • Dependency: Dependency is something that describes the intermediary dependency relationship between the elements. Thus it plays an essential role in the UML model. The use of a dotted arrow can display it.
  • Association: Association can be explained in terms of the relationship between two elements. In other words, it is something how elements are interacting with each other. It can be represented via a dotted line with an arrow on both ends, but it is not necessary to have the arrows on both sides of the line.  
  • Generalization: There is a child-parent relationship between the elements of a system. A line with a hollow arrow on one side is used to represent a child-parent relationship. The child end inherits the properties of the parent’s end.
  • Realization: Realization is a term that can be described as one end that will depict something, and the other one will execute or perform it.
  • Diagrams: This third category is mainly classified into three types:
  • Structural diagrams
  • Class diagram
  • Object diagram
  • Package diagram
  • Component diagram
  • Deployment diagram
  1. Behavioral diagrams
  2. Activity diagram
  3. State machine diagram
  4. Use case diagram
  1. Interaction diagrams
  2. Timing diagram
  3. Sequence diagram
  4. Collaboration diagram

Pin It on Pinterest

Share This