Software Design Principles

Software design principles are concerned with providing means to handle the
complexity of the design process effectively. Effectively managing the complexity will
not only reduce the effort needed for design but can also reduce the scope of
introducing errors during design.

Following are the principles of Software Design

Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the
problem into smaller pieces so that each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.
Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple
3. Software is easy to test
4. Software is easy to modify
5. Software is easy to maintain
6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the
system. They have to cooperate and communicate to solve the problem. This
communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity increases

Abstraction
An abstraction is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the implementation.
Abstraction can be used for existing element as well as the component being
designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction

i. A module is specified by the method it performs.

ii. The details of the algorithm to accomplish the functions are not visible to the
user of the function.

Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction
forms the basis for Object Oriented design approaches.

Modularity
Modularity specifies to the division of software into separate modules which are
differently named and addressed and are integrated later on in to obtain the
completely functional software. It is the only property that allows a program to be
intellectually manageable. Single large programs are difficult to understand and read
due to a large number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other

applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.
Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity

There are several advantages of Modularity

o It allows large programs to be written by several or different people

o It encourages the creation of commonly used routines to be placed in the
library and used by other programs.
o It simplifies the overlay procedure of loading a large program into main
storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased
o More linkage required, run-time may be longer, more source lines must be
written, and more documentation has to be done
Modular Design

Modular design reduces the design complexity and results in easier and faster
implementation by allowing parallel development of various parts of a system. We
discuss a different section of modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing

functions that perform only one kind of task and do not excessively interact with
other modules. Independence is important because it makes implementation more
accessible and faster. The independent modules are easier to maintain, test, and
reduce error propagation and can be reused in other programs as well. Thus,
functional independence is a good design feature which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that

modules can be characterized by the design decisions that protect from the others,
i.e., In other words, modules should be specified that data include within a module is
inaccessible to other modules that do not need for such information.

The use of information hiding as design criteria for modular system provides the
most significant benefits when modifications are required during testing's and later
during software maintenance. This is because as most data and procedures are
hidden from other parts of the software, inadvertent errors introduced during
modifications are less likely to propagate to different locations within the software.
Strategy of Design
A good system design strategy is to organize the program modules in such a
method that are easy to develop and latter too, change. Structured design methods
help developers to deal with the size and complexity of programs. Analysts generate
instructions for the developers about how code should be composed and how
pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main
components and then decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and
moves towards up the hierarchy, as shown in fig. This approach is suitable in case of
an existing system.
Module Level Concepts :
A module is logically a separable part of the program. it
is a program unit that is discreet and identifiable with respect to compiling and
loading. In terms of common programming language constructs, a module can be
a macro, a function, a procedure, a process or a package. In systems using
functional abstraction, a module is usually a procedure of function or a collection
of these.

To produce modular designs , some criteria must be used to select modules

so that the modules support well defined abstractions and are solvable and
modifiable separately. In a system using functional abstraction , coupling and
cohesion are two modularization criteria, which are often used together.
Coupling and Cohesion

Module Coupling
In software engineering, the coupling is the degree of interdependence between
software modules. Two modules that are tightly coupled are strongly dependent on
each other. However, two modules that are loosely coupled are not dependent on
each other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the
number of relations between the modules. That is, the coupling increases as the
number of calls between modules increase or the amount of shared data is large.
Thus, it can be said that a design with high coupling will have more errors.
Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct

coupling.

2. Data Coupling: When data of one module is passed to another module, this is
called data coupling.
3. Stamp Coupling: Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc. When the module passes non-
global data structure or entire structure to another module, they are said to be
stamp coupled. For example, passing structure variable in C or object in C++
language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one
module is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an

externally imposed data format, communication protocols, or device interface. This is
related to communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information
through some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share
code, e.g., a branch from one module into another module.
Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of
a module belong together. Thus, cohesion measures the strength of relationships
between pieces of functionality within a given module. For example, in highly
cohesive systems, functionality is strongly related

Cohesion is an ordinal type of measurement and is generally described as "high

cohesion" or "low cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different
elements of a module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the
element of a module form the components of the sequence, where the output
from one component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational
cohesion, if all tasks of the module refer to or update the same data structure,
e.g., the set of functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set
of purpose of the module are all parts of a procedure in which particular
sequence of steps has to be carried out for achieving a goal, e.g., the
algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated
by the fact that all the methods must be executed in the same time, the
module is said to exhibit temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements
of the module perform a similar operation. For example Error handling, data
input and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it
performs a set of tasks that are associated with each other very loosely, if at
all.
Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Cohesion is also called Intra-Module

Binding. Binding.

Coupling shows the relationships Cohesion shows the relationship within

between modules. the module.

Coupling shows the Cohesion shows the module's

relative independence between the relative functional strength.
modules.

While creating, you should aim for While creating you should aim for high
low coupling, i.e., dependency cohesion, i.e., a cohesive component/
among modules should be less. module focuses on a single function (i.e.,
single-mindedness) with little interaction
with other modules of the system.

In coupling, modules are linked to In cohesion, the module focuses on a

the other modules. single thing.
Design Notation and specifications :
Design notations are largerly meant to be used during the
process of design and are used to represents design decisions. They are meant
largely for designer so that he can quickly represents his decisions in a compact
manner that he can evaluate and modify. These notations are frequently
graphical.

Here we describe a design notations -- Structure Charts-- that can be used to

represent a function-oriented design. Then we describe a simple design language
to specify a design. Though the design document, the final output of the design
activity, typically also contains other things like design decisions taken and
background, its primary purpose is to document the design itself.

Structure Chart represent hierarchical structure of modules. It breaks down

the entire system into lowest functional modules, describe functions and
sub-functions of each module of a system to a greater detail. Structure
Chart partitions the system into black boxes (functionality of the system is
known to the users but inner details are unknown). Inputs are given to the
black boxes and appropriate outputs are generated.
Modules at top level called modules at low level. Components are read from
top to bottom and left to right. When a module calls another, it views the
called module as black box, passing required parameters and receiving
results.
Symbols used in construction of structured chart
1. Module
It represents the process or task of the system. It is of three types.
 Control Module
A control module branches to more than one sub module.
 Sub Module
Sub Module is a module which is the part (Child) of another module.
 Library Module
Library Module are reusable and invokable from any module.

2. Conditional Call
It represents that control module can select any of the sub module on the
basis of some condition.

3. Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module.
A curved arrow represents loop in the module.
 All the sub modules cover by the loop repeat execution of module.
4. Data Flow
It represents the flow of data between the modules. It is represented by
directed arrow with empty circle at the end.

5. Control Flow
It represents the flow of control between the modules. It is represented
by directed arrow with filled circle at the end.

6. Physical Storage
Physical Storage is that where all the information are to be stored.
Example : Structure chart for an Email server

Types of Structure Chart:

1. Transform Centered Structured:
These type of structure chart are designed for the systems that receives
an input which is transformed by a sequence of operations being carried
out by one module.
2. Transaction Centered Structure:
These structure describes a system that processes a number of different
types of transaction.

Modules in a system can be categorized into few classes. There are some
modules that obtain information from their subordinates and then pass it to
their subordinate.There are five types of modules :
1. Input Module
2. Output Module
3. Coordinate Module
4. Transform Module
5. Composite Module
Structured Design Methodology
Introduction: - Creating the software system design is the major
concern of the design phase. Many design techniques have been
proposed over the years to provide some discipline in handling
the complexity of designing large systems. The aim of design
methodologies is not to reduce the process of design to a
sequence of mechanical steps but to provide guidelines to aid the
designer during the design process. Here we describe the
structured design methodology for developing system designs.
Structured design methodology (SDM) views every software
system as having some inputs that are converted into the desired
outputs by the software system. The basic principle behind the
structured design methodology, as with most other
methodologies, is problem partitioning. Structured design
methodology partitions the system at the very top level into
various subsystems, one for managing each major input, one for
managing each major output, and one for each major
transformation. The modules performing the transformation deal
with data at an abstract level, and hence can focus on the
conceptual problem of how to perform the transformation
without bothering with how to obtain clean inputs or how to
present the output.
The rationale behind this partitioning is that in many systems,
particularly data processing systems, a good part of the system
code deals with managing the inputs and outputs. The modules
dealing with inputs have to deal with issues of screens, reading
data, formats, errors, exceptions, completeness of information,
structure of the information, etc. Similarly, the modules dealing
with output have to prepare the output in presentation formats,
make charts, produce reports, etc. Hence, for many systems, it is
indeed the case that a good part of the software has to deal with
inputs and outputs. The actual transformation in the system is
frequently not very complex—it is dealing with data and getting it
in proper form for performing the transformation or producing
the output in the desired form that requires considerable
processing. This partitioning is at the heart of the structured
design methodology. There are four major steps in the
methodology:
1. Restate the problem as a data flow diagram
2. Identify the input and output data elements
3. First-level factoring
4. Factoring of input, output, and transform branches
We will now discuss each of these steps in more detail.

 Restate the Problem as a Data Flow Diagram

To use this methodology, the first step is to construct the data
flow diagram for the problem. However, there is a fundamental
difference between the DFDs drawn during requirements analysis
and those drawn during structured design. In the requirements
analysis, a DFD is drawn to model the problem domain. The
analyst has little control over the problem, and hence his task is to
extract from the problem all the information and then represent it
as a DFD. During design activity, we are no longer modeling the
problem domain, but are dealing with the solution domain and
developing a model for the eventual system. That is, the DFD
during design represents how the data will flow in the system
when it is built.
In this modeling, the major transforms or functions in the
software are decided, and the DFD shows the major transforms
that the software will have and how the data will flow through
different transforms. As the system does not yet exist, the
designer has complete freedom in creating a DFD that will solve
the problem stated in the SRS. The general rules of drawing a DFD
remain the same; we show what transforms are needed in the
software and are not concerned with the logic for implementing
them. Consider the example of the simple automated teller
machine that allows customers to withdraw money. A DFD for
this ATM is shown in Figure.

Figure: Data flow diagram of an ATM.

There are two major streams of input data in this diagram. The
first is the account number and the code, and the second is the
amount to be debited. Notice the use of * at different places in the
DFD. For example, the transform “validate,” which verifies if the
account number and code are valid, needs not only the account
number and code, but also information from the system database
to do the validation. And the transform debit account has two
outputs, one used for recording the transaction and the other to
update the account.

 Identify the Most Abstract Input and Output Data

Elements
Most systems have some basic transformations that perform the
required operations. However, in most cases the transformation
cannot be easily applied to the actual physical input and produce
the desired physical output. Instead, the input is first converted
into a form on which the transformation can be applied with ease.
Similarly, the main transformation modules often produce
outputs that have to be converted into the desired physical
output. The goal of this second step is to separate the transforms
in the data flow diagram that convert the input or output to the
desired format from the ones that perform the actual
transformations.
For this separation, once the data flow diagram is ready, the next
step is to identify the highest abstract level of input and output.
The most abstract input data elements are those data elements in
the data flow diagram that are farthest removed from the physical
inputs but can still be considered inputs to the system. The most
abstract input data elements often have little resemblance to the
actual physical data. These are often the data elements obtained
after operations like error checking, data validation, proper
formatting, and conversion are complete. Most abstract input data
elements are recognized by starting from the physical inputs and
traveling toward the outputs in the data flow diagram, until the
data elements are reached that can no longer be considered
incoming. The aim is to go as far as possible from the physical
inputs, without losing the incoming nature of the data element.
This process is performed for each input stream. Identifying the
most abstract data items represents a value judgment on the part
of the designer, but often the choice is obvious.
Similarly, we identify the most abstract output data elements by
starting from the outputs in the data flow diagram and traveling
toward the inputs. These are the data elements that are most
removed from the actual outputs but can still be considered
outgoing. These data elements may also be considered the logical
output data items, and the transforms in the data flow diagram
after these data items are basically to convert the logical output
into a form in which the system is required to produce the output.
Consider now the data flow diagram of the automated teller
shown in above Figure. The two most abstract inputs are the
dollar amount and the validated account number. The validated
account number is the most abstract input, rather than the
account number read in, as it is still the input—but with a
guarantee that the account number is valid. The two abstract
outputs are obvious. The abstract inputs and outputs are marked
in the data flow diagram.

 First-Level Factoring
Having identified the central transforms and the most abstract
input and output data items, we are ready to identify some
modules for the system. We first specify a main module, whose
purpose is to invoke the subordinates. The main module is
therefore a coordinate module. For each of the most abstract input
data items, an immediate subordinate module to the main module
is specified. Each of these modules is an input module, whose
purpose is to deliver to the main module the most abstract data
item for which it is created.

Similarly, for each most abstract output data item, a subordinate

module that is an output module that accepts data from the main
module is specified. Each of the arrows connecting these input and
output subordinate modules are labelled with the respective
abstract data item flowing in the proper direction.

Finally, for each central transform, a module subordinate to the

main one is specified. These modules will be transform modules,
whose purpose is to accept data from the main module, and then
return the appropriate data back to the main module. The data
items coming to a transform module from the main module are on
the incoming arcs of the corresponding transform in the data flow
diagram. The data items returned are on the outgoing arcs of that
transform. Note that here a module is created for a transform,
while input/output modules are created for data items.
Let us examine the data flow diagram of the ATM. We have
already seen that this has two most abstract inputs, two most
abstract outputs, and two central transforms. Drawing a module
for each
of these, we get the structure chart shown in Figure

Figure: First-level factoring for ATM.

As we can see, the first-level factoring is straightforward, after the
most abstract input and output data items are identified in the
data flow diagram. The main module is the overall control
module, which will form the main program or procedure in the
implementation of the design. It is a coordinate module that
invokes the input modules to get the most abstract data items,
passes these to the appropriate transform modules, and delivers
the results of the transform modules to other transform modules
until the most abstract data items are obtained. These are then
passed to the output modules.
 Factoring the Input, Output, and Transform
Branches
The first-level factoring results in a very high-level structure,
where each subordinate module has a lot of processing to do. To
simplify these modules, they must be factored into subordinate
modules that will distribute the work of a module. Each of the
input, output, and transformation modules must be considered
for factoring. Let us start with the input modules.

The purpose of an input module, as viewed by the main program,

is to produce some data. To factor an input module, the transform
in the data flow diagram that produced the data item is now treated
as a central transform. The process performed for the first-level
factoring is repeated here with this new central transform, with the
input module being considered the main module. A subordinate
input module is created for each input data stream coming into this
new central transform, and a subordinate transform module is
created for the new central transform. The new input modules now
created can then be factored again, until the physical inputs are
reached.

Factoring of input modules will usually not yield any output

subordinate modules. The factoring of the input module get-
sorted-list in the first-level structure is shown in Figure 6.8. The
transform producing the input returned by this module (i.e., the
sort transform) is treated as a central transform. Its input is the
word list. Thus, in the first factoring we have an input module to
get the list and a transform module to sort the list. The input
module can be factored further, as the module needs to perform
two functions, getting a word and then adding it to the list. Note
that the looping arrow is used to show the iteration.

The factoring of the output modules is symmetrical to the factoring

of the input modules. For an output module we look at the next
transform to be applied to the output to bring it closer to the
ultimate desired output. This now becomes the central transform,
and an output module is created for each data stream going out of
this transform. During the factoring of output modules, there will
usually be no input modules. In our example, there is only one
transform after the most abstract output, so this factoring need not
be done.

Figure (B): Factoring the central transform

If the data flow diagram of the problem is sufficiently detailed,

factoring of the input and output modules is straightforward.
However, there are no such rules for factoring the central
transforms. The goal is to determine sub transforms that will
together compose the overall transform and then repeat the
process for the newly found transforms, until we reach the atomic
modules. Factoring the central transform is essentially an exercise
in functional decomposition and will depend on the designers'
experience and judgment. One way to factor a transform module is
to treat it as a problem in its own right and start with a data flow
diagram for it. The inputs to the data flow diagram are the data
coming into the module and the outputs are the data being
returned by the module. Each transform in this data flow diagram
represents a sub transform of this transform. The central
transform can be factored by creating a subordinate transform
module for each of the transforms in this data flow diagram. This
process can be repeated for the new transform modules that are
created, until we reach atomic modules. The factoring of the central
transform count-the-number-of-different-words is shown in
Figure (B).This was a relatively simple transform, and we did not
need to draw the data flow diagram. To determine the number of
words, we have to get a word repeatedly, determine if it is the same
as the previous word (for a sorted list, this checking is sufficient to
determine if the word is different from other words), and then
count the word if it is different. For each of the three different
functions, we have a subordinate module, and we get the structure
shown in Figure (B).
 Object oriented methodology:
Object-oriented methodology (OOP) is a popular approach for designing and building software
systems. It is based on the concept of "objects" which are instances of classes and have
properties and methods. This approach allows for creating modular and reusable code, and
facilitates the modeling of real-world objects and their interactions. OOP is used to design and
implement complex software systems in an organized and structured way, by breaking down the
problem into smaller, manageable parts. This makes it easier to understand, code, test and
maintain the software. Additionally, OOP allows for encapsulation, inheritance and
polymorphism, which are concepts that aid in the organization, reuse and maintenance of
software systems.
Object oriented design:-

1)Objects

2)Messages

3)Abstraction

4)Class

5)Attributes

6)Operations

7)Inheritance

8)Polymorphism

9)Encapsulation

10)Hierarchy
Objects: Object is an entity,which has a state and a defined set of operations,which operate on that state.The
state is represented as a set of object attributes. Every object has some properties associated with it, along
with some methods for performing operations on those attributes.

Messages: objects communicate by passing messages.Messages consist of the identity of the target
object,the name of the requested operation and any other operation needed to perform the function.In some
distributed systems,object communications are implemented directly as text messages which object excgange.

Abstraction: Abstraction is used in object-oriented design to deal with complexity. Abstraction is the removal of
the unnecessary and the amplification of the necessary.

Class: Some of the objects may have common characteristics and we can group the objects according to
these characteristics .This type of grouping is known as a ClASS. Hence ,a class is a set of objects that share
a common structure and a common behavior.
 “A class represents a template for several object and describe how these objects are structured internally.”

In object oriented system, each objects belongs to a class.an objects,that belongs to a certain class is called an
instance of that class.The class describes the structure ,behavior and information of the instance,while the
current state of the instance is defined by the operations performed on the instance.

Classes are useful because they act as a blue print for objects.

Attributes: An attributes is a data value held by the objects in a class.the square classes has two attributes,a
colour and array of points.Each attributes has a value for each object instance.

Operations:An operations is a function or transformation that may be applied to or by objects in a class.In the
square class,we have two operations:set colour() and draw(). All oblects in a class in a class share the same
operations. Each operation has a target object as an implicit argument. The behavior of the operations depends
on the class of its target.

Inheritance: It allows us to derive a class from another class or a hierarchy of classes that share a set of
attributes and methods.It is a relationship between a superclass and a subclass ,where the subclass inherits
data and behavior from the superclass.

~A class derived from another class is called a subclass or child class.and a class from which the subclass is
derived is called a super class or parent class.

~In the subclass,the inherited attributes or methods can be used directly like any other attributes or methods.

~The subclass can write a new method with the same signature as the one in the superclass a process called
method overriding.

Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can
be assigned the same name. This is known as polymorphism, which allows a single interface is performing functions for
different types. Depending upon how the service is invoked, the respective portion of the code gets executed.

Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are linked to a single
unit. Encapsulation not only bundles essential information of an object together but also restricts access to the data and
methods from the outside world.

Hierarchy: It allows code reusability. “IS–A” hierarchy − It defines the hierarchical relationship in inheritance, whereby
from a super-class, a number of subclasses may be derived which may again have subclasses and so on. For example, if
we derive a class Rose from a class Flower, we can say that a rose “is–a” flower.

Cohesion and Coupling: Two OO Design Principles

Cohesion and Coupling deal with the quality of an OO design. Generally, good OO design
should be loosely coupled and highly cohesive. Lot of the design principles, design patterns
which have been created are based on the idea of “Loose coupling and high cohesion”.

The aim of the design should be to make the application:

 easier to develop
 easier to maintain
 easier to add new features
 less fragile

Coupling: In object oriented design, Coupling refers to the degree of direct knowledge that one element has
of another. In other words, how often do changes in class A force related changes in class B.
There are two types of coupling:
1. Tight coupling : In general, Tight coupling means the two classes often change together.

2.Loose coupling : In simple words, loose coupling means they are mostly independent. If the only knowledge
that class A has about class B, is what class B has exposed through its interface, then class A and class B are
said to be loosely coupled. In order to over come from the problems of tight coupling between objects, spring
framework uses dependency injection mechanism with the help of POJO/POJI model and through dependency
injection its possible to achieve loose coupling.

Cohesion:
Cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Coupling is all about how
classes interact with each other, on the other hand cohesion focuses on how single class is designed. Higher the
cohesiveness of the class, better is the OO design.

Benefits of Higher Cohesion:

 Highly cohesive classes are much easier to maintain and less frequently changed.

 Such classes are more usable than others as they are designed with a well-focused purpose.

~~Steps to Analyze & design object oriented system

1. Create use case model:

The first step in the analysis and design of an object-oriented system is to recognize the actors interlinked
with the system. After that, create the use case and draw the use case diagram.

2.Draw activity diagram:

The activity Diagram demonstrates the dynamic nature of a system by creating the flow of control form activity. An activity
addresses a procedure on some class in the framework that outcomes in an adjustment of the condition of the system. The below
figure shows the activity graph handling a request to convey a few products.

3.Draw the interaction diagram :

A interaction diagram shows a collaboration, comprising a bunch of articles and their relationship, including the messages
that might be dispatched among them. Interaction diagram address the unique perspective on a system.
Steps for drawing interaction diagrams :
a. Initially, we ought to distinguish that the objects as for each use case.
b. Then we draw the sequence diagrams for each use case.
c. Then we draw the collaboration diagrams for each use case.

4.Draw the class diagram : The class diagram is responsible for showing the relationship between the classes. There are four
types of relationships available in class diagrams :
d. Association –
It is a semantic connection between classes. At the point when an association associates two classes, each class can send
messages to the next in sequence or a collaboration diagram. They may be bi-directional or unidirectional in nature.
 e. Dependencies –
They connect two classes and are always unidirectional in nature and display that one class, depends on the definitions of
another class.
f. Aggregations –
They are a stronger form of association that shows the relationship between a whole and its parts.
g. Generalizations –
They are used to display an inheritance relationship between the two classes.

5.Design of State chart diagrams :

A state chart is utilized to show the state space of a given class, the occasion that influences progress starting with one state
then onto the next, and the activity that outcome from a state change. A state change graph for a “book” in the library
management system is shown below :

6. Draw component and development diagram :

These diagrams address the static execution perspective on a system they are identified with class diagrams in that a segment
ordinarily guides to at least one class, interface, or coordinated effort