Object Oriented Analysis and Design

Module II

Concept of unified modelling language, Object Oriented Analysis and Design using
UML, UML Diagrams: Class Diagram, representing various features of a class,
messages, use case diagram, identifying use cases, examples.

What are models?

• A complete description of a system from a particular perspective.

• Simplification of reality.

Why models?

• Modelling achieves four aims:

1. Helps you to visualize a system as you want it to be.
2. Permits you to specify the structure or behaviour of a system.
3. Gives you a template that guides you in constructing a system.
4. Documents the decisions you have made.
• You build models of complex systems because you cannot comprehend such a system
in its entirety.
• You build models to better understand the system you are developing.

Unified Modeling Language (UML)

The Unified Modeling Language (UML) is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a software-intensive system. The UML offers
a standard way to write a system’s blueprints, including conceptual things such as business
processes and system functions as well as concrete things such as programming language
statements, database schemas, and reusable software components.

UML is a language (Unified Modeling Language) for models

• technical and graphical specification

• Graphic notation to visualize models
• Not a method or procedure

The Unified Modelling Language (UML) is an industry standard for object oriented design
notation, supported by the Object Management Group (OMG).

1
Object Oriented Analysis and Design

Language for Visualizing

• Communicating conceptual models to others is prone to error unless everyone

involved speaks the same language.
• There are things about a software system you can’t understand unless you build
models.
• An explicit model facilitates communication.

Language for Specifying

• The UML builds models that are precise, unambiguous, and complete.

Language for Constructing

UML models can be directly connected to a variety of programming languages.

• Maps to Java, C++, Visual Basic, and so on

• Tables in a RDBMS or persistent store in an OODBMS
• Permits forward engineering
• Permits reverse engineering

Language for Documenting

• The UML addresses documentation of system architecture, requirements, tests,

project planning, and release management.

Diagrams

• Diagrams graphically depict a view of a part of your model.

• Different diagrams represent different views of the system that you are developing.
• A model element will appear on one or more diagrams.

UML Diagrams

• 14 different types of diagrams

• 2 different groups
✓ Behavior & Interaction models
✓ Structural models

2
Object Oriented Analysis and Design

Key Diagrams in UML

Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects
residing in the system and the relationships between them. A class consists of its objects, and
also it may inherit from other classes. A class diagram is used to visualize, describe,
document various different aspects of the system, and also construct executable software
code.

3
Object Oriented Analysis and Design

It shows the attributes, classes, functions, and relationships to give an overview of the
software system. It constitutes class names, attributes, and functions in a separate
compartment that helps in software development. Since it is a collection of classes, interfaces,
associations, collaborations, and constraints, it is termed as a structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only
diagram that is widely used for construction, and it can be mapped with object -oriented
languages. It is one of the most popular UML diagrams. Following are the purpose of class
diagrams given below:

• It analyses and designs a static view of an application.

• It describes the major responsibilities of a system.
• It is a base for component and deployment diagrams.
• It incorporates forward and reverse engineering.

Benefits of Class Diagrams

• It can represent the object model for complex systems.

• It reduces the maintenance time by providing an overview of how an application is
structured before coding.
• It provides a general schematic of an application for better understanding.
• It represents a detailed chart by highlighting the desired code, which is to be
programmed.
• It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:

1. Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes,
operations, and semantics. Some of the following rules that should be taken into
account while representing a class are given below:
• Capitalize the initial letter of the class name.
• Place the class name in the center of the upper section.

4
Object Oriented Analysis and Design

• A class name must be written in bold format.

• The name of the abstract class should be written in italics format.
2. Middle Section: The middle section constitutes the attributes, which describe the
quality of the class. The attributes have the following characteristics:
• The attributes are written along with its visibility factors, which are public
(+), private (-), protected (#), and package (~).
• The accessibility of an attribute class is illustrated by the visibility factors.
• A meaningful name should be assigned to the attribute, which will explain
its usage inside the class.
3. Lower Section: The lower section contains methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It
demonstrates how a class interacts with data.

Relationships

In UML, relationships are of three types:

1. Dependency: A dependency is a semantic relationship between two or more classes

where a change in one class cause changes in another class. It forms a weaker
relationship.
In the following example, Student_Name is dependent on the Student_Id.

5
Object Oriented Analysis and Design

2. Generalization: A generalization is a relationship between a parent class (super class)

and a child class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.

3. Association: It describes a static or physical connection between two or more objects.

It depicts how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range

is not specified, one is considered as a default multiplicity. For example, multiple patients are
admitted to one hospital.

6
Object Oriented Analysis and Design

Aggregation: An aggregation is a subset of association, which represents has a relationship.

It is more specific than association. It defines a part-whole or part-of relationship. In this kind
of relationship, the child class can exist independently of its parent class. The company
encompasses a number of employees, and even if one employee resigns, the company still
exists.

Composition: The composition is a subset of aggregation. It portrays the dependency

between the parent and its child, which means if one part is deleted, then the other part also
gets discarded. It represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the
contacts will be lost.

ABSTRACT CLASSES

In the abstract class, no objects can be a direct entity of the abstract class. The abstract class
can neither be declared nor be instantiated. It is used to find the functionalities across the
classes. The notation of the abstract class is similar to that of class; the only differ ence is that
the name of the class is written in italics. Since it does not involve any implementation for a
given function, it is best to use the abstract class with multiple objects.

Let us assume that we have an abstract class named displacement with a method declared
inside it, and that method will be called as a drive (). Now, this abstract class method can be
implemented by any object, for example, car, bike, scooter, cycle, etc.

7
Object Oriented Analysis and Design

How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only
represents a static view of the system but also all the major aspects of an application. A
collection of class diagrams as a whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are given
below:

• To describe a complete aspect of the system, it is suggested to give a meaningful

name to the class diagram.
• The objects and their relationships should be acknowledged in advance.
• The attributes and methods (responsibilities) of each class must be known.
• A minimum number of desired properties should be specified as a greater number of
the unwanted property will lead to a complex diagram.
• Notes can be used as and when required by the developer to describe the aspects of a
diagram.
• The diagrams should be redrawn and reworked as many times to make it correct
before producing its final version.

Class Diagram Example

A class diagram describing the sales order system is given below.

8
Object Oriented Analysis and Design

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in
the establishment of the component and deployment diagrams. It helps to construct an
executable code to perform forward and backward engineering for any system, or we c an say
it is mainly used for construction. It represents the mapping with object -oriented languages
that are C++, Java, etc. Class diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application. It depicts the
high-level functionality of a system and also tells how the user handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams. It represents how an
entity from the external environment can interact with a part of the system.

Following are the purposes of a use case diagram given below:

• It gathers the system's needs.

• It depicts the external view of the system.
• It recognizes the internal as well as external factors that influence the system.
• It represents the interaction between the actors.

9
Object Oriented Analysis and Design

How to draw a Use Case diagram?

It is essential to analyze the whole system before starting with drawing a use case diagram,
and then the system's functionalities are found. And once every single functionality is
identified, they are then transformed into the use cases to be used in the use case diagram.

After that, we will enlist the actors that will interact with the system. The actors are the
person or a thing that invokes the functionality of a system. It may be a system or a private
entity, such that it requires an entity to be pertinent to the functionalities of the system to
which it is going to interact.

Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular
instance of time.

Following are some rules that must be followed while drawing a use case diagram:

• A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
• The communication of an actor with a use case must be defined in an understandable
way.
• Specified notations to be used as and when required.
• The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase online.
The top-level uses are as follows; View Items, Make Purchase, Checkout, Client Register.
The View Items use case is utilized by the customer who searches and view products. The
Client Register use case allows the customer to register itself with the website for availing
gift vouchers, coupons, or getting a private sale invitation. It is to be noted that the Checkout
is an included use case, which is part of Making Purchase, and it is not available by itself.

10
Object Oriented Analysis and Design

The View Items is further extended by several use cases such as; Search Items, Browse
Items, View Recommended Items, Add to Shopping Cart, Add to Wish list. All of these
extended use cases provide some functions to customers, which allows them to search for an
item. The View Items is further extended by several use cases such as; Search Items, Browse
Items, View Recommended Items, Add to Shopping Cart, Add to Wish list. All of these
extended use cases provide some functions to customers, which allows them to search for an
item.

Both View Recommended Item and Add to Wish List include the Customer Authentication
use case, as they necessitate authenticated customers, and simultaneously item can be added
to the shopping cart without any user authentication.

11
Object Oriented Analysis and Design

Similarly, the Checkout use case also includes the following use cases, as shown below. It
requires an authenticated Web Customer, which can be done by login page, user
authentication cookie ("Remember me"), or Single Sign-On (SSO). SSO needs an external
identity provider's participation, while Web site authentication service is utilized in all these
use cases.

The Checkout use case involves Payment use case that can be done either by the credit card
and external credit payment services or with PayPal.

12
Object Oriented Analysis and Design

Important tips for drawing a Use Case diagram

Following are some important tips that are to be kept in mind while drawing a use case
diagram:

1. A simple and complete use case diagram should be articulated.

2. A use case diagram should represent the most significant interaction among the
multiple interactions.
3. At least one module of a system should be represented by the use case diagram.
4. If the use case diagram is large and more complex, then it should be drawn more
generalized.

13