Mastering the Art of Object-Oriented Design: A Comprehensive Guide to UML Diagrams -1

What is UML?

Embracing the complexity of system design requires a multifaceted approach, and Unified Modeling Language (UML) emerges as the beacon guiding software engineers through this intricate landscape. UML serves as a dynamic lens, enabling us to perceive a system from diverse perspectives, unraveling its intricacies in a coherent manner. Unlike programming languages, UML doesn’t dwell in code but rather illuminates the behavioral and structural dimensions of a system, providing a standardized framework for visualization.

Key Points About UML:

1. Holistic View through Models: In the realm of software engineering, UML acts as a unifying force, allowing stakeholders to comprehend the system’s facets comprehensively. It transforms abstract concepts into tangible representations, fostering a shared understanding among diverse roles within a project.
2. Analyzing, Designing, and Developing: UML empowers software engineers and developers with a suite of tools, facilitating a structured approach to analyze, design, and develop software systems. It transcends the boundaries of mere visualization, serving as a robust foundation for the entire software development lifecycle.
3. Modeling Processes: UML extends its prowess beyond static representations, seamlessly integrating process modeling into its repertoire. By providing a visual vocabulary for expressing system behavior, it becomes an invaluable asset in articulating intricate processes within the software.
4. Communication Across Stakeholders: UML emerges as a universal language in the software realm, adept at bridging the communication gap between various stakeholders. From analysts deciphering requirements to authors shaping the narrative of the software, UML acts as a conduit for effective and clear communication.

Types of UML Diagrams

UML diagrams can be classified into two categories:

• Structural UML diagrams
• Behavioral UML diagrams

The following illustration represents the subcategories of structural and behavioral UML diagrams:

Structural UML diagrams

Structural diagrams represent the static structure of the system. They never depict the system’s dynamic behavior. The most commonly used structural diagram in software development is the class diagram.

Behavioral UML diagrams

Behavioral diagrams represent the dynamic behavior of elements in the system. All systems experience dynamic occurrences. In object-oriented programming, we use behavioral diagrams to illustrate the dynamic behavioral semantics of a problem or its implementation. The most commonly used behavioral diagrams are use case diagrams, activity diagrams, and sequence diagrams.

UML diagrams used in the OOD interview

In a typical OOD interview process, the following are the most widely asked UML diagrams:

• Class diagram
• Use case diagram
• Sequence diagram
• Activity diagram

Class Diagram

a class diagram is like a visual blueprint for a computer program. It shows the different parts of the program (called classes), what they have inside them (attributes and methods), and how they connect to each other. This diagram helps software developers understand and plan how their program will work. It’s particularly useful for designing programs using object-oriented principles. Think of it as a roadmap that guides developers in turning their ideas into actual computer code, making the whole process easier to manage and share with others.

Why use class diagrams?

• Visual Clarity: Offering a clear visual representation of the system, class diagrams facilitate a better understanding of the overall structure and organization of classes for both developers and stakeholders.
• Effective Communication Tool: Acting as a powerful communication tool within a development team, class diagrams ensure a shared understanding of the system’s design, streamlining collaboration and preventing misunderstandings.
• Blueprint for Code Implementation: By specifying classes, their attributes, and the relationships between them, class diagrams provide a foundational blueprint for code implementation. This guides developers in translating the visual representation into actual, executable code.
• Refactoring Guidance: When modifying or improving existing code, class diagrams offer valuable insights into potential impacts on other parts of the system. This aids developers in making informed decisions during the refactoring process.
• Static Structure Representation: Class diagrams vividly represent the static structure of a system, illustrating how different parts interact and relate to each other.
• Direct Mapping with Object-Oriented Languages: Class diagrams have a direct correlation with object-oriented programming languages, making them a seamless bridge between conceptual design and practical implementation.
• Representation of System Duties or Responsibilities: Beyond structure, class diagrams represent the duties and responsibilities of the system, providing a holistic view of its functionality.
• Versatility in Engineering: Class diagrams find utility in both forward and reverse engineering processes, facilitating the creation of visual representations during system development and aiding in understanding existing code structures.

Popular notations in the class diagram

The following are some essential notations of the class diagram:

• Class notation
• Interface, abstract class, and enumeration
• Access modifiers

Class Notation:

In a class diagram, a class is represented by a rectangle divided into three compartments: class name, attributes, and methods. For example:

+ - - - - - - - - - -+
| Animal |
| - - - - - - - - - -|
| - species |
| - age |
| - - - - - - - - - -|
| + makeSound() |
| + eat() |
+ - - - - - - - - - -+

In this example, “Animal” is the class name, and it has attributes like “species” and “age,” along with methods such as “makeSound()” and “eat()”.

2. Interface, Abstract Class, and Enumeration:

Interface: Represented with <<interface>> stereotype, an interface defines a set of methods that must be implemented by any class implementing the interface. Example:

<<interface>> Shape
--------------
+ draw()

Abstract Class: Shown in italics, an abstract class cannot be instantiated on its own and may contain abstract methods. Example:

<<abstract>> Vehicle
--------------------
- speed: float
--------------------
+ start()
+ abstract accelerate()

Enumeration: Represented as a circle, denoting a set of named values. Example:

<<enumeration>> DaysOfWeek
---------------------------
+ MONDAY
+ TUESDAY
+ WEDNESDAY

3. Access Modifiers:

You may use character symbols to specify the visibility of the associated object when defining methods or attributes. The most widely used access modifiers are as follows:

Public: A public member can be seen anywhere in the system. It is represented by a + symbol.

Private: Members can only be accessible from within the class. It is inaccessible from outside the class. It is represented by a - symbol.

Protected: Members are only accessible within the class and derived classes. It is represented by the # symbol.

Example:

+ - - - - - - - - - -+
| Car |
| - - - - - - - - - -|
| - model: string |
| # color: string |
| - - - - - - - - - -|
| + startEngine() |
| - stopEngine() |
+ - - - - - - - - - -+

In this example, “model” is private, and “color” is protected. Methods are denoted as public.

Association:

provides a mechanism to communicate one object with another object, or one object provides services to another object. Association represents the relationship between classes.

The association can be divided into two categories:

• Class association (Inheritance)
• Object association

Class association

Inheritance falls under the category of class association. Creating a new class from the existing class(es) is called inheritance. Apart from its own behaviors and attributes, the child class inherits the characteristics of its parent(s). A solid line leads from the child class to the parent class with a hollow arrowhead representing the inheritance relationship.

The following class diagram represents the inheritance relationship:

Example:

+-------------------+       +---------------------+
|   Order           |       |   Customer          |
|-------------------|       |---------------------|
|   - orderId       |       |   - customerId     |
|   - totalAmount   |       |   - name            |
|-------------------|       |---------------------|
| + calculateTotal()|       | + placeOrder()      |
+-------------------+       +---------------------+

The class association represents a 
connection between the "Order" and "Customer" classes.

Object association

Object association (relationship between objects) can be divided into the following categories:

1. Simple association

2. Composition

3. Aggregation

1. Simple association

The weakest connections between objects are made through simple association. It is achieved through reference, which one object can inherit from another. The following is an example of a simple association:

Example:

+------------+      +-------------+
|   Person   |      |   Address   |
|------------|      |-------------|
|   - name    |      |   - street  |
|   - age     |      |   - city    |
|------------|      |-------------|
| + setAddress()|    | + getPerson()|
+------------+      +-------------+

A simple association denotes a basic relationship between
 "Person" and "Address" classes.

2. Aggregation

Aggregation describes the relationship between the container and the object it contains. An object may contain an aggregate of another object. Aggregation is denoted by a line with an unfilled diamond head towards the container.

Aggregation is a weaker relationship because:

• Aggregate objects are not a part of the container.
• Aggregate objects can exist independently.

Example:

+-----------------+      +---------------------+
|   University    |      |        Department   |
|-----------------|      |---------------------|
|   - name        |      |   - departmentName  |
|   - location    |      |   - numProfessors   |
|-----------------|      |---------------------|
| + addDepartment()|     | + addProfessor()    |
|-----------------|      +---------------------+

Here, University "has" Departments, implying an aggregation relationship.

3. Composition

An object may be composed of smaller objects, and the relationship between the “part” objects and “whole” objects is known as composition.

In the example below, the Chair class can be composed of other objects of Arm, Seat, and Leg types. Composition is denoted by a line with a filled diamond head at the composer class pointing to the component class.

Composition is a strong relationship because:

• The composed object becomes a part of the composer.
• Composed objects cannot exist independently.

Example:

+-----------------+      +---------------------+
|   House         |      |       Room          |
|-----------------|      |---------------------|
|   - address     |      |   - roomNumber      |
|-----------------|      |---------------------|
| + addRoom()     |      | + getRoomDetails()  |
|-----------------|      +---------------------+
A House "is composed of" Rooms, and 
the existence of rooms is tied to the existence of the house.

Some additional types of association

The following are some types of simple associations based on navigation:

• Single-direction navigation is called one-way association and is denoted by an arrow toward the server object.

The class diagram of one-way association

• If we navigate in both directions, the association is called a two-way association and is denoted by a line between two objects.

The class diagram of two-way association

• Binary, ternary, and n-ary associations are based on the number of objects.
• Association in which two objects are involved is called a binary association. The binary association includes one-way or two-way navigation.
• Association between the objects of exactly three classes is a ternary association and is denoted by a diamond with lines connected to associated objects.
• Association between more than three classes is called n-ary association.

Additional Types of Association — Dependency:

Dependency indicates that one class is dependent on another class(es) for its implementation. Another class may or may not depend on the first class. A dashed arrow denotes dependency.

In the example above, we have two classes — RegistrationManager and Student. The RegistrationManager class relies on the Student class for its behavior because the object of the Student class is passed as a parameter to one of the functions in the RegistrationManager class.

Example:

+-----------------+      +---------------------+
|   Logger        |      |      Database       |
|-----------------|      |---------------------|
|                 |      |                     |
| + logMessage()  |      | + saveData()        |
|-----------------|      +---------------------+
The "Logger" class is dependent on the "Database" 
class for saving data, reflecting a dependency relationship.

Understanding these UML class diagram elements is crucial for effectively designing and communicating software structures.