1.Introduction to Object-oriented Analysis and Design (OOAD)

OOAD is a technique used to analyze and design an application or system. It is based on a common set of principles that help us design a better system or application.

I assume that you already know the concepts of object-oriented design (OOD), object-oriented analysis (OOA) as well as understand the syntax of object-oriented programming. (object-oriented programming or OOP) in languages ​​such as: Java, C++, C#, Python, JavaScript.

1.1.Introduction to OOA, OOD and UML

1.1.1.Object-oriented Analysis

When developing software, during the object-oriented analysis phase, we define system requirements, classes, and relationships between classes.

Then use it to create a model by defining the roles of objects in the system and the tasks that the system will have to perform.

The analysis phase does not include any detailed implementation. Instead, we will define use cases here.

1.1.2.Object-oriented Design

OOD is the beginning of the implementation of the defined requirements and models created in the OOA phase.

In this step, the models are further refined by adding additional constraints. These models are often built using Unified Modeling Language (UML) diagrams such as class diagrams or sequence diagrams.

1.1.3.Unified Modeling Language (UML)

UML is used to visualize (or represent) the behavior and structure of the system. It is known as a tool that provides software engineers and software developers with the ability to analyze, design and develop systems.

UML diagrams can be divided into 2 types:

• Structural UML diagrams
• Behavioral UML diagrams

The most common structural diagrams in software development are class diagrams. The most commonly used behavioral diagrams are use case diagrams, activity diagrams, and sequence diagrams.

The diagrams above are also the ones we will explore within the scope of this article.

2.Use case diagram

Use case diagram depicts how users interact with the system. These interactions are called use cases. Here, the use case will be described from the user’s perspective to the system. After completing the use case diagram, we can understand the functions that the system needs to build from the perspective of users.

2.1.Components of use case diagram

• Actor : Users are called actors. Actors can be people, machines, hardware, or other systems. There are two types of actors:
  • Primary actors (active actors): These are external people or systems that interact with the system, they are placed on the left side of the use case diagram.
  • Secodary actors (passive actors): Actors used by the system to support active actors in the use case diagram. They are placed to the right in the use case diagram.
• Use case : This is the defined functionality of the system that the actor will use to represent the interaction with the system.

Actors and use cases are represented as follows:

2.2.Relationships in use case diagram

There are four types of relationships in the use case diagram:

2.2.1.Association

Association : Shows the relationship between actor(s) and use case(s). It describes how the actor performs certain functions. All actors in the use case diagram must have at least one association with any use case.

Association is represented by a solid line, as follows:

2.2.2.Generalization

Generalization : This relationship is also known as inheritance. In inheritance in oop , we have parent classes and child classes.

Similarly, in the use case diagram, we have parent use cases and child use cases as well as parent actors and child actors. Child (use case/actor) will inherit the behavior of parent (use) case/actor).

Generalization is indicated by a solid line with an arrow pointing from child (use case/actor) to parent (use case/actor) as follows:

2.2.3.Extend

Extend : Used to describe the relationship between two use cases. It indicates a use case (extended use case) that extends the behavior of another use case (base use case). It is used to extend the functionality of the base use case. The extended use case does not execute all the time but depends on certain conditions.

Extend is indicated by a dashed line with an arrow pointing to one side (towards the base use case), and has the text <<extend>> above it as follows:

2.2.4.Include

Include : Used to describe the relationship between use cases. It indicates a use case that must include the behavior of another use case. The included use case will execute only after executing the base use case.

Include is indicated by a dashed line with an arrow pointing to one side (towards the base use case), and has the text <<include>> above it as follows:

With the Transfer Fund use case, we see it <<include>> another use case is Check Sufficient Fund . If the base use case of Check Sufficient Fund fails or fails, the Transfer Fund use case is considered incomplete.

2.3.Benefits of use case diagram:

• Explain the flow of activities and the purpose of use cases, helping us to define the context and needs of the system.
• Explain the behavior of the system from the user’s perspective.

3.Class diagram

Class diagrams are used to describe the static structure of the system. It is used during the design process to specify the roles and responsibilities of the system.

Class diagrams are widely used in OOD modeling because it is directly convertible to OOP programming languages.

A class diagram is made up of:

• Collection of classes
• Set of relationships between classes.

3.1.Common notations in class diagram

• Class notation
• Interfaces, abstract classes, and enumeration
• Access modifiers

3.1.1.Class notation

The following figure shows a Movie class with its attributes and methods.

• The first section is the class name
• The second section is a list of attributes : describing the properties of the object, for example, students will have student ID, first and last name, date of birth, etc.
• The last section shows methods : representing the behavior of objects.

3.1.2.Interface, abstract class, and enumeration

We can declare an abstract class using the abstract keyword, the class name will be italicized, similar to interface, enumeration, annotation.

3.1.3.Access modifiers

We can also represent private, public, and protected data in the class diagram.

• Public: Shown with + . sign
• Private: Shown by – sign
• Protected: Shown with # sign

3.2. Relationships in class diagram

3.2.1.Generalization (inheritance) (“is a”)

This relationship represents a class that inherits another class. It is represented by a solid line leading from the child class to the parent class with an empty arrowhead representing the inheritance relationship as follows:

3.2.2.Simple association (“has a”)

This is the relationship between two classes established through their objects. In this relationship, nobody owns anyone, and the lifecycles of the two classes are independent. For example, a member comes to register with the librarian at the library.

This relationship is represented as follows:

3.2.3.Aggregation (“is part of”)

Aggregation describes the relationship between the container and the object in the container. Objects in the container can exist independently of the container. As in the example below, Table , Bed , Chair objects can still exist outside of Room . Aggregation is represented as follows:

Another example is the phone and the battery, when the battery (object) is damaged, it can be replaced with another battery in the phone (container) to continue using. Or wheels and cars:

3.2.4.Composition (constituent – “is entirely made of”)

An object can consist of many smaller objects, and the relationship between “part” objects (part objects can be understood as parts of a complete object) and “whole” objects is called composition. The lifecycle of “part” objects depends on the lifecycle of “whole” objects.

In the example below, we can see, when Leg , Seat , Arm objects are created, they must be specified to which Chair they belong, otherwise they are meaningless. Composition is represented as follows:

One more example is that Hotel contains many Room , when the Hotel is canceled, the Rooms will also be canceled.

3.2.5.Dependency (dependencies)

Dependency indicates that a class will depend on other class(s) for its implementation.

We have 2 classes: RegistrationManager and Student . The RegistrationManager class relies on the Student class to implement its behavior because the Student class’s object is passed as a parameter to one of the methods in the RegistrationManager class.

When the Student class changes, it can affect the RegistrationManager class because the addStudent method relies on the Student object to complete. Dependency is represented as follows:

3.3. Multiplicity in class diagram

Multiplicity indicates how many objects of each class participate in relationships, and multiplicity can be expressed as follows:

Eg

Each customer must have from 1 to 5 bank accounts. Each bank account belongs to only one customer.

A student can register for many courses, or not register at all. A course can have many students registered, or no students are registered.

A school can have 1 or more teachers, 1 teacher can teach at 1 school or many schools. A school must have one or more toilets.

In the next article, we will learn about Sequence Diagram and Activity Diagram.