UNIT-III-DESIGN

ENGINEERING
Software Design
◦Software design is a mechanism to transform user
requirements into some suitable form, which helps the
programmer in software coding and implementation.
◦It deals with representing the client's requirement, as
described in SRS (Software Requirement Specification)
document, into a form, i.e., easily implementable using
programming language.
Objectives of Software Design
◦Correctness: A good design should be correct, which means that it
should correctly implement all of the system's features.
◦Efficiency: A good software design should consider resource,
time, and cost optimization parameters.
◦Understandability: A good design should be easy to grasp, which
is why it should be modular, with all parts organized in layers.
◦Completeness: The design should include all components, such
as data structures, modules, and external interfaces, among
others.
◦Maintainability: A good software design should be flexible when
the client issues a modification request.
Software Design Process
three levels or phases of design:
◦Interface Design
◦Architectural Design
◦Detailed Design
Elements of a System
◦Architecture: This is the conceptual model that defines the
structure, behavior, and views of a system. We can use flowcharts
to represent and illustrate the architecture.
◦Modules: These are components that handle one specific task in
a system. A combination of the modules makes up the system.
◦Components: This provides a particular function or group of
related functions. They are made up of modules.
◦Interfaces: This is the shared boundary across which the
components of a system exchange information and relate.
◦Data: This is the management of the information and data flow.
◦Interface Design
◦Interface design is the specification of the interaction
between a system and its environment.
◦This phase proceeds at a high level of abstraction
with respect to the inner workings of the system i.e,
during interface design, the internal of the systems
are completely ignored, and the system is treated as
a black box.
◦Attention is focused on the dialogue between the
target system and the users, devices, and other
systems with which it interacts.
◦Interface design should include the following details:
◦Precise description of events in the environment, or
messages from agents to which the system must respond.
◦Precise description of the events or messages that the
system must produce.
◦Specification of the data, and the formats of the data
coming into and going out of the system.
◦Specification of the ordering and timing relationships
between incoming events or messages, and outgoing
events or outputs.
◦Architectural Design
◦Architectural design is the specification of the
major components of a system, their
responsibilities, properties, interfaces,
and the relationships and interactions
between them.
◦In architectural design, the overall structure of
the system is chosen, but the internal details
of major components are ignored.
◦Issues in architectural design includes:
◦Gross decomposition of the systems into major
components.
◦Allocation of functional responsibilities to
components.
◦Component Interfaces.
◦Component scaling and performance properties,
resource consumption properties, reliability
properties, and so forth.
◦Communication and interaction between
components.
◦ Detailed Design
◦ Detailed design is the specification of the internal elements of all major
system components, their properties, relationships, processing,
and often their algorithms and the data structures.
◦ The detailed design may include:
◦ Decomposition of major system components into program units.
◦ Allocation of functional responsibilities to units.
◦ User interfaces.
◦ Unit states and state changes.
◦ Data and control interaction between units.
◦ Data packaging and implementation, including issues of scope and
visibility of program elements.
◦ Algorithms and data structures.
Software Design Concepts:
◦Abstraction (Hide Irrelevant data)
◦Modularity (subdivide the system)
◦Architecture(design a structure of something)
◦Refinement(removes impurities)
◦Design Patterns (a Repeated form)
◦Information/Data Hiding(Hide the Information)
◦Refactoring(Reconstruct something)
Abstraction
◦One of the fundamental concepts of object-oriented
programming (OOP) languages is an abstraction.
◦Its primary purpose is to deal with complexity by
concealing internal details from the user.
◦This allows the user to build more complicated logic on
top of the offered abstraction without having to understand
or even consider all the hidden complexity.
Modularity
◦Modularity refers to breaking a system or project into smaller sections to
lessen the system's or project's complexity.
◦Similarly, modularity in design refers to the division of a system into smaller
elements that can be built independently and then used in multiple systems to
execute different purposes.
◦Sometimes to deal with Monolithic software (means "composed all in one
piece or too large), which is difficult to grasp for software engineers, it is
required to partition the software into components known as modules. As a
result, modularity in design has become a trend that is also essential.
Architecture
◦A system's software architecture represents the design decisions
linked to the general structure and behavior of the system.
◦It specifies how components of a software system are constructed,
as well as their relationships and communication.
◦It acts as a software application blueprint and a development
foundation for the developer team.
Refinement
◦Refinement means removing any impurities and improving
the quality of something.
◦The software design refinement idea is a process of building
or presenting the software or system in a detailed manner,
which implies elaborating on a system or software.
◦In addition, refinement is essential for identifying and
correcting any possible errors
Design Patterns
◦A Software Design Pattern is a general, reusable solution to a
commonly occurring problem within a given context in software
design.
◦They are templates to solve common software engineering
problems, representing some of the finest practices experienced
object-oriented software engineers utilize.
◦It discusses the problem, the remedy, when to use it, and the
repercussions (the usually bad effect of an event, action, or
decision).
◦It also provides implementation guidance and examples.
Information/Data Hiding
◦Simply put, information hiding implies
concealing information so that an unauthorized
entity cannot access it.
◦In software design, information hiding is
accomplished by creating modules in such a
way that information acquired or contained in
one module is concealed and cannot be
accessible by other modules.
Refactoring
◦Refactoring is the process of reorganizing code without affecting its
original functionality.
◦Refactoring aims to improve internal code by making modest
changes that do not affect the code's exterior behavior.
◦Computer programmers and software developers refactor code to
improve the software's design, structure, and implementation.
◦As a result, Refactoring increases code readability while decreasing
complications. Refactoring can also assist software engineers in
locating faults or vulnerabilities in their code.
Levels of Software Design
Architectural Design:
◦The architecture of a system can be viewed as the overall
structure of the system and the way in which structure
provides conceptual integrity of the system.
◦The architectural design identifies the software as a system
with many components interacting with each other. At
this level, the designers get the idea of the proposed
solution domain.
Preliminary or high-level design:
◦Here the problem is decomposed into a set of
modules, the control relationship among various
modules identified, and also the interfaces among
various modules are identified.
◦The outcome of this stage is called the program
architecture. Design representation techniques used
in this stage are structure chart and UML.
Detailed design:
◦Once the high-level design is complete, a
detailed design is undertaken. In detailed
design, each module is examined carefully to
design the data structure and algorithms.
◦The stage outcome is documented in the form
of a module specification document.
◦Software Architecture :
Software Architecture defines fundamental organization of a
system and more simply defines a structured solution. It
defines how components of a software system are
assembled, their relationship and communication between
them. It serves as a blueprint for software application and
development basis for developer team.
◦A software architecture defines structure of a system.
◦A software architecture defines behavior of a system.
◦A software architecture defines component relationship.
◦A software architecture defines communication structure.
◦A software architecture balances stakeholder’s needs.
◦A software architecture influences team structure.
◦A software architecture focuses on significant elements.
◦A software architecture captures early design decisions .
◦Importance of Software Architecture :
Software architecture comes under design phase of software development life
cycle. It is one of initial step of whole software development process. Without
software architecture proceeding to software development is like building a
house without designing architecture of house.
◦So software architecture is one of important part of software application
development. In technical and developmental aspects point of view below are
reasons software architecture are important.
◦Selects quality attributes to be optimized for a system.
◦Facilitates early prototyping.
◦Allows to be built a system in component wise.
◦Helps in managing the changes in System.
◦Advantages of Software ◦Disadvantages of Software
Architecture : Architecture :
◦Provides a solid foundation for ◦Sometimes getting good tools and
software project. standardization becomes a problem
◦Helps in providing increased for software architecture.
performance. ◦Initial prediction of success of
◦Reduces development cost. project based on architecture is not
always possible.
◦Software Architecture –
◦Architecture defines the blueprints of a system. It
serves as a communication and coordination
mechanism for the elements. It designs a structured
solution while keeping the performance, security etc.
in check. It impacts the quality, maintainability and
overall performance of the system.
◦ Software Design –

◦Software design is the method of coming up

with a plan that takes the user requirements,
available resources to find an optimal
design. This lays the path for the developers
and the managers to develop the project to
meet the customer’s demands.
◦Importance Of Software Design Architecture :
◦Bring the focus onto the structure while keeping the
implementation hidden
◦To address the demands of the customers
◦Optimal use of resources while providing effective product
◦Improve the trust in the organizations
◦Realize the use-cases and scenarios
◦Predict the product release beforehand
◦Software Architecture Design Factors :
When a structured framework is designed for the
product to conceptualize its behavior, software
elements and relationship etc. in that case different
aspects related to the software product are
considered for designing the software architecture.
The below figure represents all these factors.
◦Major Goals Of Software Design Principles :
◦Establishes a bridge between business and technical
requirements
◦To identify those requirements that concern the structure of
the project
◦To make the project’s architecture scalable, stable and testable
◦Consider the overall consequences of the decisions
◦Make the project flexible
◦Design principles :
◦When different design principles are followed during software
architecture design it not only makes the designing process
simpler but also it results easier and faster development of the
product with low cost, low effort, and minimized requirement
maintenance and follow-up.
◦Separation Of Concerns –
◦This principle states that the software should be distinguished
based on the working of the software. For example this can be
achieved by segregating the business model from the
implementation part so that the different people concerned for
each module do not have to worry about the other one.
◦ Encapsulation –
It helps in hiding parts of application from the other parts. This helps in improving
the project as it ensures changes in one part will not affect to the other part of the
application.
◦ Don’t Repeat Yourself (DRY) –
Avoids the duplication of the functionality which comes within a single application.
Means avoids repetition and implement one piece of code for a single component.
This principle will decrease the complexity of the application.
◦ Principle of Least Knowledge –
It is also called as LoD (Law of Demeter) which helps in avoiding interdependency in
between the components. As the components are unknown about internal
architecture of the product which contains other components or objects.
Unified Modeling Language
(UML):
◦The full form of UML is “Unified Modeling
Language”. It is a general-purpose modeling
language.
◦The main aim of UML is to define a standard way
to visualize how a system has been designed.
◦It is quite similar to blueprints used in other fields of
engineering.
◦UML is not a programming language, it is rather a
visual language.
What is Unified?
◦UML aims to provide a standardized way to
visualize and design systems, making it easier
for different stakeholders to understand and
communicate about a system regardless of
their backgrounds or the specific domains they
work in.
What is Modeling?
◦Modeling involves creating abstract
representations of a system. In the
context of UML, modeling refers to
creating diagrams and other artifacts that
represent different aspects of a software
system, such as its structure, behavior,
and interactions.
What is Language?
◦UML provides a set of symbols, notations,
and rules for creating models. It’s a
formal language that allows developers,
designers, and other stakeholders to
express their ideas, designs, and
requirements using a common set of
symbols and semantics.
Structural Diagrams:
◦Structural diagrams depict a static view or structure of
a system. It is widely used in the documentation of
software architecture.
◦Class Diagram: Class diagrams are one of the most
widely used diagrams. It is the backbone of all the
object-oriented software systems. It depicts the static
structure of the system. It displays the system's class,
attributes, and methods. It is helpful in recognizing the
relation between different objects as well as classes.
Vital components of a Class
Diagram:
◦The class diagram is made up of three sections:
◦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.
◦ A class name must be written in bold format.
◦ The name of the abstract class should be written in italics format.
◦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.
◦Lower Section: The lower section contain 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:
◦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.
Generalization:
◦ A generalization is a relationship between a parent
class (superclass) 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.
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.
Aggregation:
◦ An aggregation is a subset of association, which
represents has a relationship. It is more specific then
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 difference 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.
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 more 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.
UML 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
◦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.
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.
◦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.
◦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.
UML Object Diagram
◦Object diagrams are dependent on the class diagram as they
are derived from the class diagram. It represents an
instance of a class diagram. The objects help in portraying a
static view of an object-oriented system at a specific
instant.
◦Both the object and class diagram are similar to some extent;
the only difference is that the class diagram provides an
abstract view of a system. It helps in visualizing a particular
functionality of a system.
Notation of an Object
Diagram
Purpose of Object Diagram
◦ The class diagram provides an abstract view which comprises of classes and their
relationships, whereas the object diagram represents an instance at a particular
point of time.
◦ Following are the purposes enlisted below:
◦ It is used to perform forward and reverse engineering.
◦ It is used to understand object behavior and their relationships practically.
◦ It is used to get a static view of a system.
◦ It is used to represent an instance of a system.
Example of Object Diagram
How to draw an Object
Diagram?
◦All the objects present in the system should be examined
before start drawing the object diagram.
◦Before creating the object diagram, the relation between the
objects must be acknowledged.
◦The association relationship among the entities must be
cleared already.
◦To represent the functionality of an object, a proper meaningful
name should be assigned.
◦The objects are to be examined to understand its functionality.
Sequence Diagram
◦The sequence diagram represents the flow of messages in the
system and is also termed as an event diagram.
◦It portrays the communication between any two lifelines as a
time-ordered sequence of events, such that these lifelines took
part at the run time.
◦In UML, the lifeline is represented by a vertical bar, whereas
the message flow is represented by a vertical dotted line that
extends across the bottom of the page. It incorporates the
iterations as well as branching.
Purpose of a Sequence Diagram
◦To model high-level interaction among active
objects within a system.
◦To model interaction among objects inside a
collaboration realizing a use case.
◦It either models generic interactions or some
certain instances of interaction.
Notations of a Sequence
Diagram
◦Lifeline
◦An individual
participant in the
sequence diagram is
represented by a
lifeline. It is positioned
at the top of the
diagram.
◦ Actor
◦ A role played by an entity that
interacts with the subject is called as
an actor. It is out of the scope of the
system. It represents the role, which
involves human users and external
hardware or subjects. An actor may
or may not represent a physical
entity, but it purely depicts the role of
an entity. Several distinct roles can be
played by an actor or vice versa.
◦ Activation
◦ It is represented by a thin
rectangle on the lifeline. It
describes that time period in
which an operation is performed
by an element, such that the top
and the bottom of the rectangle is
associated with the initiation and
the completion time, each
respectively.
Messages
◦Call Message: It
defines a particular
communication
between the lifelines of
an interaction, which
represents that the
target lifeline has
invoked an operation.
◦Return Message: It
defines a particular
communication between the
lifelines of interaction that
represent the flow of
information from the
receiver of the
corresponding caller
message.
◦Self Message: It
describes a
communication,
particularly between the
lifelines of an interaction
that represents a
message of the same
lifeline, has been
invoked.
◦Recursive Message: A self
message sent for recursive
purpose is called a recursive
message. In other words, it
can be said that the
recursive message is a
special case of the self
message as it represents
the recursive calls.
◦Create Message: It
describes a
communication,
particularly between the
lifelines of an
interaction describing
that the target (lifeline)
has been instantiated.
◦Destroy Message: It
describes a
communication,
particularly between the
lifelines of an
interaction that depicts
a request to destroy the
lifecycle of the target.
◦Duration Message: It
describes a
communication
particularly between the
lifelines of an interaction,
which portrays the time
passage of the message
while modeling a system.
Composite Structure
Diagram:
◦The composite structure diagrams show parts within
the class. It displays the relationship between the
parts and their configuration that ascertain the
behavior of the class. It makes full use of ports, parts,
and connectors to portray the internal structure of a
structured classifier. It is similar to class diagrams,
just the fact it represents individual parts in a detailed
manner when compared with class diagrams.
Object Diagram:
◦ It describes the static structure of a
system at a particular point in time. It can
be used to test the accuracy of class
diagrams. It represents distinct instances
of classes and the relationship between
them at a time.
Component Diagram:
◦ It portrays the organization of the physical
components within the system. It is used for
modeling execution details. It determines
whether the desired functional requirements
have been considered by the planned
development or not, as it depicts the structural
relationships between the elements of a
software system.
Deployment Diagram:
◦It presents the system's software and its
hardware by telling what the existing physical
components are and what software
components are running on them.
◦It produces information about system
software. It is incorporated whenever software
is used, distributed, or deployed across
multiple machines with dissimilar
configurations.
Package Diagram:
◦ It is used to illustrate how the packages
and their elements are organized.
◦It shows the dependencies between distinct
packages.
◦It manages UML diagrams by making it
easily understandable. It is used for
organizing the class and use case diagrams.
Behavioural Diagrams:
◦Behavioral diagrams portray a dynamic view of a
system or the behavior of a system, which describes
the functioning of the system.
◦State Machine Diagram: It is a behavioral diagram.
it portrays the system's behavior utilizing finite state
transitions. It is also known as the State-
charts diagram. It models the dynamic behavior of a
class in response to external stimuli.
Activity Diagram:
◦ It models the flow of control from one
activity to the other. With the help of an
activity diagram, we can model
sequential and concurrent activities. It
visually depicts the workflow as well as
what causes an event to occur.
Use Case Diagram:
◦ It represents the functionality of a
system by utilizing actors and use cases.
◦It encapsulates the functional
requirement of a system and its
association with actors. It portrays the
use case view of a system
Interaction Diagrams
◦Interaction diagrams are a subclass of behavioral diagrams
that give emphasis to object interactions and also depicts the
flow between various use case elements of a system. In simple
words, it shows how objects interact with each other and how
the data flows within them.
◦Sequence Diagram: It shows the interactions between the
objects in terms of messages exchanged over time. It
delineates in what order and how the object functions are in a
system.
Communication Diagram:
◦It shows the interchange of sequence
messages between the objects. It focuses
on objects and their relations. It describes
the static and dynamic behavior of a
system.
Timing Diagram:
◦ It is a special kind of sequence diagram used
to depict the object's behavior over a specific
period of time. It governs the change in state
and object behavior by showing the time and
duration constraints.
Interaction Overview
diagram:
◦ It is a mixture of activity and
sequence diagram that depicts a
sequence of actions to simplify the
complex interactions into simple
interactions.