LLD 2— UML Diagrams

Agenda:

In this article, we will discuss UML Diagrams.

UML Diagrams: (Considering important for interviews)
1) Class Diagram
2) UseCase Diagram

Schema Design: (Assuming SQL DB to be used)
1) Finding Cardinalities
2) How to represent different relationships in Schema Design

UML stands for Unified Modelling Language. The purpose of UML is to standardize the way to represent things in a design diagram. For example: a class is represented in a rectangle having 3 sections.

Two types of UML Diagrams

1. Structural UML diagrams (concerned with the structure of the codebase)
   - Class diagram
   - Component diagram
   - Package diagram
   - Object diagram
2. Behavioral UML diagrams (concerned with how the system works/interacts)
   - Activity diagram (Imp. go through separately)
   - Use case diagram
   - Sequence diagram (Imp. go through separately)

Here we will talk only about the Use Case Diagram and Class Diagram as it is most important for the LLD interview.

Use Case Diagram:

It helps to define a set of use cases (functionalities) that can be handled by a software system along with who is going to use those functionalities. Service is the behavior of a software system, that’s why it is a kind of behavioral UML diagram.

For simplicity, let's consider an example of Flipkart System to draw a Use Case Diagram which has some basic functionalities.

Keywords:

1. System Boundary: Represented by a rectangle and contains a complete scope of the system (all the required and supported use cases).
2. Use Case: Functionality/ features (or we can say different actions) supported by a system. Represented by Oval.
   Example: For the Flipkart system, the following functionalities can be considered.

3. Actors: Entities that interact with the system to perform actions.
Example: Clients, Vendors, Logistics Team, DB Administrators, etc.

Actors

4. Includes: If Use Case A needs to perform some other Use Case B to complete its functionality, it means A includes B. In simple words, B is included in A, when the algorithmic execution of A includes the algorithmic execution of B.

Example: For checkout, payment needs to be made.

5. Extends: If for a Use Case A, there are specialized types B, C, D, etc. then B, C, D extends A. For example: Use Case SignUp can have different types, SignUp by Mobile, SignUp by Email, SignUp by SSO, etc.

Note: Usually all requirements are not considered for the Use Case diagram. A small set of requirements or a subset of products is usually considered.

Class Diagram:

It helps us to represent different entities in a software system and the relation between those entities. Entities may be classes, interfaces, abstract classes, etc.

1. Class: A class is represented as a rectangle having 3 sections in it.
   - Class Name
   - Attributes
   - Methods

How attributes are represented:

Attributes representation in class diagram

How methods are represented:

Methods representation in a class diagram

2. Interfaces: An interface is represented by a rectangle having two sections.
- Interface Name (bounded in << >>)
- Methods (methods are represented as same in class)

Interface representation in class diagram

3. Abstract Class: An abstract class is represented by a rectangle. All things are the same as class, the only difference is the name of the abstract class is written in Italics.

Abstract class representation in a class diagram

Relationship b/w different entities

1. Inheritance (Is-A Relationship): When one entity B implements another entity A, then B is said to have an Is-A relationship with A. It is represented by a pointed arrow (Child -IsA-> Parent)

2. Association (Has-A Relationship): When one entity A has another entity B as an attribute, then A is said to have a Has-A relationship with B.

Association is further divided into 2 types

• Composition: When the existence of one entity depends on the existence of another entity, it is said to have a composition relationship.
• Aggregation: When the existence of one entity does not depend on the existence of another entity, it is said to have an aggregation relationship.

Cardinality:

It is the degree of Has-A relationship between two entities. In simple words, how many of entityA is associated with how many of entityB. Different cardinalities are:

• 1:1 (One-One relationship)
• 1:M (One-Many relationship)
• M:1 (Many-One relationship)
• M: M (Many-Many relationship)

Note: whenever we define cardinality for a relationship, do check for which particular relation we are talking about. Eg: A course class can have List<Users> as participants and a User as an instructor. We cannot directly define cardinality relationship b/w class can users directly, for participants it will be different and for instructor, it will be different. (Consider a course class like an online course batch.)
Thus, between two entities, there can be more than two relationship.

How to find cardinality b/w two entities (in non-ambiguous way😅)

Considering the same course class and user entity. A Class has List<Users> as participants and A Class has a User as an instructor.

Now to find the cardinality b/w Class and Users for participant's relationship,

• Always move from left to right. Create an arrow and put 1 on the left side.

• Now check, 1 instance of the class can have how many users as participants. Answer is Many. So, put M on the right side too.

• Now move from right to left and check the same. 1 instance of a User as a participant can belong to how many classes. Answer is Many.

Thus, the cardinality relationship is M: M (Many-Many Relationship)

Similarly, for the instructor relationship, it is M:1 (Many-One relationship)