MODULE-3 SOFTWARE DESIGN

MODULE-3

SOFTWARE DESIGN: Software design

Design process
Design concepts
Coupling
Cohesion
Functional independence Design patterns Modelview controller Publish subscribe Adapter
Command
Strategy Observer Proxy
Facade
Architectural styles
Layered Client Server
Tiered Pipe and filter User interface designCase Study

3.1 Software Designe

Software design is model of software which translates the requirements into finished software
product in which the details about software data structures, architecture, interfaces and
components that are necessary to implement the system are given.

3.1.1 Designing within the Context of Software Engineering

 Software design is a vital activity during the process of software development, it is carried out
irrespective of any process model used.
 During software engineering process, the first task is to identify and analyze the requirements.
Based on this analysis the software design is developed. This design serves as a basis for code
generation and testing. Hence software design is an intermediate process which translates the
analysis model into design model.
 The four types of elements of analysis model are scenario based elements, class based
elements, behavioral elements, and flow oriented elements.
 During the scenario based analysis various models such as use case diagrams, activity
diagrams or swimlane diagrams are created. During the class based analysis the class
diagrams are created. During flow oriented analysis the Data flow diagrams are created.
Behavioral analysis can be done using state diagrams and sequence diagrams.The class based
elements of analysis model are used to create class diagrams.
 The flow oriented elements and class based elements are used to create architectural
design.

1
MODULE-3 SOFTWARE DESIGN

 The scenario based elements, flow oriented elements and behavioral elements are used to
create Interface design. The interface design describes how software communicates with systems.

 The class based elements, flow oriented elements and behavioral elements are used to create
component level design. This design transforms the structural elements of software architecture
into procedural description of software module. (Refer Fig. 3.1.1).

 Software design is very important for assessing the quality of software. Because design is the
only way that we can accurately translate the user requirements into the finished software product.

 Without software design, it is difficult to test the software product. Not only this, but for
making a small change in the software - it is the software design which helps us to make the
necessary changes without disturbing other part of the software

Design Process

 Software design is an iterative process using which the user requirements can be translated
into the software product.
 At the initial stage of the software is represented as an abstract view. During the sub-sequent
iterations data, functional and behavioral requirements are traced in detail. That means at
each iteration the refinement is made to obtain lower level details of the software product.

Characteristics of Good Design

1) The good design should implement all the requirements specified by the customer. Even if
there are some implicit requirements of the software product then those requirements should
also be implemented by the software design.
2) The design should be simple enough so that the software can be understood easily by the
developers, testers and customers.
3) The design should be comprehensive. That means it should provide complete picture of the
software.

Quality Guideline The goal of any software design is to produce high quality software. In order
to evaluate quality of software there should be some predefined rules or criteria that need to be
used to assess the software product. Such criteria serve as characteristics for good design. The
quality guidelines are as follows

2
MODULE-3 SOFTWARE DESIGN
1. The design architecture should be created using following issues -

 The design should be created using architectural styles and patterns.

 Each component of design should possess good design characteristics.
 The implementation of design should be evolutionary, so that testing can be
performed at each phase of implementation.

2. In the design the data, architecture, interfaces and components should be clearly represented.
3. The design should be modular. That means the subsystems in the design should be logically
partitioned.
4. The data structure should be appropriately chosen for the design of specific problem.
5. The components should be used in the design so that functional independency can be
achieved in the design.
6. Using the information obtained in software requirement analysis the design should be created.
7. The interfaces in the design should be such that the complexity between the connected
components of the system gets reduced. Similarly interface of the system with external
interface should be simplified one.
8. Every design of the software system should convey its meaning appropriately and effectively.

Quality Attributes(FURPS Model)

The design quality attributes popularly known as FURPS (Functionality, Usability, Reliability,
Performance and Supportability) is a set of criteria developed by Hewlett and Packard. Following
table represents meaning of each quality attribute

Quality attribute Meaning

Functionality Functionality can be checked by assessing the set of features and
capabilities of the functions. The functions should be general and
should not work only for particular set of inputs. Similarly the
security aspect should be considered while designing the function.
Usability The usability can be assessed by knowing the usefulness of the
system.
Reliability Reliability is a measure of frequency and severity of failure.
Repeatability refers to the consistency and repeatability of the
measures. The Mean Time To Failure (MTTF) is a metric that is
widely used to measure the product's performance and reliability.
Performance It is a measure that represents the response of the system.
Measuring the performance means measuring the processing
speed, memory usage, response time and efficiency.
Supportability It is also called maintainability. It is the ability to adopt the
enhancement or changes made in the software. It also means the
ability to withstand in a given environment.

3
MODULE-3 SOFTWARE DESIGN
Design Concepts

The software design concept provides a framework for implementing the right software.

Following are certain issues that are considered while designing the software -

 Abstraction
 Modularity
 Architecture
 Refinement
 Pattern
 Information hiding
 Functional independence
 Refactoring
 Design classes

3.3.1 Abstraction
The abstraction means an ability to cope up with the complexity. Software design occurs at
different levels of abstraction. At each stage of software design process levels of abstractions
should be applied to refine the software solution. At the higher level of abstraction, the solution
should be stated in broad terms and in the lower level more detailed description of the solution
is given.

While moving through different levels of abstraction the procedural abstraction and data
abstraction are created.

The procedural abstraction gives the named sequence of instructions in the specific function.
That means the functionality of procedure is mentioned by its implementation details are hidden.
For example : Search the record is a procedural abstraction in which implementation details are
hidden(i.e. Enter the name, compare each name of the record

against the entered one, if a match is found then declare success !! Other wise declare 'name not
found')

In data abstraction the collection of data objects is represented. For example for the procedure
search the data abstraction will be record. The record consists of various attributes such as record
ID, name, address and designation.

3.3.2 Modularity

 The software is divided into separately named and addressable components that called as
modules.
 Monolithic software is hard to grasp for the software engineer, hence it has now become a
trend to divide the software into number of products. But there is a co-relation between the
number of modules and overall cost of the software product.

Following argument supports this idea -

"Suppose there are two problems A and B with varying complexity. If the complexity of problem
A is greater than the complexity of the problem B then obviously the efforts required for solving
the problem A is greater than that of problem B. That also means the time required by the
problem A to get solved is more than that of problem B."

4
MODULE-3 SOFTWARE DESIGN
The overall complexity of two problems when they are combined is greater than the sum of
complexity of the problems when considered individually. This leads to divide and conquer
strategy (according to divide and conquer strategy the problem is divided into smaller
subproblems and then the solution to these subproblems is obtained).dividing the software
problem into manageable number of pieces leads to the concept of modularity. It is possible to
conclude that if we subdivide the software indefinitely then effort required to develop each
software component will become very small. But this conclusion is invalid because the total
number of modules get increased the efforts

required for developing each module also gets increased. That means the cost associated with
each effort gets increased. The effort(cost)required . for integration these modules will also get
increased. The total cost required to develop such software product is shown in Fig. 3.3.1.

The Fig. 3.3.1 provides useful guideline for the modularity and that is - overmodularity or the
undermodularity while developing the software product must be avoided. We should
modularize the software but the modularity must remain near the region denoted by M

 Modularization should be such that the development can be planned easily, software
increments can be defined and delivered, changes can be more easily accommodated and
long term maintenance can be carried out effectively.
 Meyer defines five criteria that enable us to evaluate a design method with respect to its
ability to define an effective modular system :
 Modular decomposability : A design method provides a systematic mechanism for
decomposing the problem into sub-problems. This reduces the complexity of the problem
and the modularity can be achieved.
 Modular composability : A design method enables existing design components to be
assembled into a new system.

 Modular understandability : A module can be understood as a standalone unit. It will be

easier to build and easier to change.

5
MODULE-3 SOFTWARE DESIGN
 Modular continuity : Small changes to the system requirements result in changes to
individual modules, rather than system-wide changes.

 Modular protection : An aberrant condition occurs within a module and its effects are
constrained within the module.

Importance :

 Due to modularity, each task forms a separate, distinct program module. At

implementation time each module and its inputs and outputs are well-defined; there is no
confusion in the intended interface with other system modules.

 The testing of modules and their integrity with other modules can be tested independently.

 Some modules may be defined by standard procedures which are used and reused in different
programs or parts of the same program.

 Large projects containing modules become easier to monitor and control.

3.3.3 Architecture
Architecture means representation of overall structure of an integrated system. In architecture
various components interact and the data of the structure is used by various components. These
components are called system elements. Architecture provides the basic framework for the
software system so that important framework activities can be conducted in systematic manner.

In architectural design various system models can be used and these are

Model Functioning
Structural model Overall architecture of the system can be represented using this model
Framework This model shows the architectural framework and corresponding
model applicability.
This model shows the reflection of changes on the system due to external
Dynamic model
events.
Process model The sequence of processes and their functioning is represented in this model
Functional model The functional hierarchy occurring in the system is represented by this model.

3.3.4 Refinement

 Refinement is actually a process of elaboration.

 Stepwise refinement is a top-down design strategy proposed by Niklaus WIRTH.
 The architecture of a program is developed by successively refining levels of procedural
detail.
 The process of program refinement is analogous to the process of refinement and partitioning
that is used during requirements analysis.
 Abstraction and refinement are complementary concepts. The major difference is that - in the
abstraction low-level details are suppressed. Refinement helps the designer to elaborate low-
level details.

6
MODULE-3 SOFTWARE DESIGN
3.3.5 Pattern
According to Brad Appleton the design pattern can be defined as - It is a named
nugget(something valuable) of insight which conveys the essence of proven solution to a
recurring problem within a certain context.

In other words, design pattern acts as a design solution for a particular problem occurring in
specific domain. Using design pattern designer can determine whether-

 Pattern can be reusable.

 Pattern can be used for current work.
 Pattern can be used to solve similar kind of problem with different functionality.

3.3.6 Information Hiding

Information hiding is one of the important property of effective modular design. The term
information hiding means the modules are designed in such a way that information contained in
one module cannot be accessible to the other module (the module which does not require this
information). Due to information hiding only limited amount of information can be passed to
other module or to any local data structure used by other module.

The advantage of information hiding is basically in testing and maintenance. Due to information
hiding some data and procedures of one module can be hidden from another module. This
ultimately avoids introduction of errors module from one module to another. Similarly one can
make changes in the desired module without affecting the other module.

3.3.7 Functional Independence

 The functional independence can be achieved by developing the functional modules with
single-minded approach.
 By using functional independence functions may be compartmentalized and interfaces are
simplified.
 Independent modules are easier to maintain with reduced error propagation.
 Functional independence is a key to good design and design is the key to software quality.
 The major benefit of functional independence is in achieving effective modularity.
 The functional independence is assessed using two qualitative criteria - Cohesion and
coupling.

3.3.7.1 Cohesion

 With the help of cohesion the information hiding can be done.

 A cohesive module performs only “one task” in software procedure with little interaction
with other modules. In other words cohesive module performs only one thing.
 Different types of cohesion are :

1. Coincidentally cohesive - The modules in which the set of tasks are related with each
other loosely then such modules are called coincidentally cohesive.
2. Logically cohesive - A module that performs the tasks that are logically related with each
other is called logically cohesive.
3. Temporal cohesion - The module in which the tasks need to be executed in some specific
time span is called temporal cohesive.

7
MODULE-3 SOFTWARE DESIGN
4. Procedural cohesion - When processing elements of a module are related with one
another and must be executed in some specific order then such module is called procedural
cohesive.
5. Communicational cohesion - When the processing elements of a module share the data
then such module is communicational cohesive.

 The goal is to achieve high cohesion for modules in the system

3.3.7.2 Coupling

 Coupling effectively represents how the modules can be "connected" with other module or
with the outside world.
 Coupling is a measure of interconnection among modules in a program structure.
 Coupling depends on the interface complexity between modules.
 The goal is to strive for lowest possible coupling among modules in software design.
 The property of good coupling is that it should reduce or avoid change impact and ripple
effects. It should also reduce the cost in program changes, testing and maintenance.
 Various types of coupling are : i) Data coupling - The data coupling is possible by
parameter passing or data interaction. ii) Control coupling - The modules share related
control data in control coupling. iii) Common coupling - In common coupling common data
or a global data is shared among the modules. iv)Content coupling - Content coupling
occurs when one module makes use of data or control information maintained in another
module

Sr.
Coupling Cohesion
No.
Coupling represents how the modules
In cohesion, the cohesive module performs only one
1. are connected with other modules or
thing.
with the outside world.
With coupling interface complexity
2. With cohesion, data hiding can be done.
is decided.
The goal of coupling is to achieve
3. The goal of cohesion is to achieve high cohesion.
lowest coupling.
Various types of couplings are - Data Various types of cohesion are - Coincidental
4. coupling, Control coupling, Common cohesion, Logical cohesion, Temporal cohesion,
coupling and Content coupling. Procedural cohesion and Communicational cohesion.

3.3.8 Refactoring

Refactoring is necessary for simplifying the design without changing the function or behaviour.
Fowler has defined refactoring as "the process of changing a software system in such a way that
the external behaviour of the design do not get changed, however the internal structure gets
improved".

Benefits of refactoring are -

 The redundancy can be achieved.

 Inefficient algorithms can be eliminated or can be replaced by efficient one.
 Poorly constructed or inaccurate data structures can be removed or replaced.

8
MODULE-3 SOFTWARE DESIGN
 Other design failures can be rectified.

The decision of refactoring particular component is taken by the designer of the software system.

3.3.9 Design Classes

Design classes are defined as the classes that describe some elements of problem domain, focus
on various aspects of problem from user's point of view.

The goal of design classes is :

1. To refine the analysis classes by providing the detail design, so that further implementation
can be done easily.
2. To create new set of classes for implementing the infrastructure of the software.

There are five different types of design classes

User Interface Class

The user interface class defines all the abstractions that are necessary for Human
Computer Interface(HCI). The user interface classes is basically a visual representation of
the HCI.

Business Domain Class

Business domain classes are the refinement of analysis classes. These classes identify the
attributes and services that are needed to implement some elements of business domain.

Process Class
Process class implement lower level business abstractions used by the business domain.

Persistent Class
These classes represent the data store such as databases which will be retained as it is
even after the execution of the software.

9
MODULE-3 SOFTWARE DESIGN
System Class
These classes are responsible for software management and control functions that are
used for system operation

Each class must be well formed design class. Following are some characteristics of well
formed design classes -

 Complete and Efficient

A design class must be properly encapsulated with corresponding attributes and methods.
Design class must contain all those methods that are sufficient to achieve the intent of the
class.
 Primitiveness
Methods associated with one particular class must perform unique service and the class
should not provide another way to implement the same service.
 High Cohesion
A cohesive designed class must posses small, focused set of responsibilities and these
responsibilities must be associated with all the attributes of that class.
 Low Coupling
Design classes must be collaborated with manageable number of classes. If one design class
is collaborated with all other design classes then the implementation, testing and
maintenance of the system becomes complicated. The law of Demeter suggests that the one
particular design class should send messages to the methods of neighbouring design classes
only.

Desin Patterns

Definition of design pattern

A design pattern is a general, reusable solution to a common problem in software design. It helps
solve issues that come up often within a certain context.

In general, a pattern has four essential elements:

 Pattern name:
This is the name given to the pattern so it can be easily referred to. It helps people talk about
designs clearly. Having a good name makes it easier to understand and discuss the design.
Choosing the right name can be difficult.
 Problem:
This describes when and why to use the pattern. It explains the problem and its situation. It

10
MODULE-3 SOFTWARE DESIGN
might include details like the algorithm for solving the problem, the class or object structure
needed, or the conditions that should be met before using the pattern.

Solution:
The solution explains the parts of the design, how they connect, and what they do. It doesn’t give
exact code or detailed implementation. Instead, it acts like a template that can be used for
different problems in different situations.

Consequence:
Consequences describe what happens when you use the pattern, including the results and any
trade-offs. In software, this often means considering things like space and time efficiency. Listing
the consequences helps you evaluate if the design pattern is a good choice.

State the role and patterns while developing system design

3.4.1 Creational Pattern

Creational design pattern are the design pattern that are used for object creation mechanism. This
type of pattern is used in the situation when basic form of object creation could result in design
problems or increase complexity of a code base.
The creational patterns show how to make the software design flexible.

There are five well-known design patterns that are part of creational patterns. These are:

1) Abstract factory pattern: Used to create objects from many related classes.
2) Builder pattern: Separates how an object is built from how it looks.
3) Factory method pattern: Used to create objects from different subclasses.
4) Prototype pattern: Defines what kinds of objects to make by copying an existing object.
5) Singleton pattern: Makes sure there is only one object of a class and provides a global way
to access it.

3.4.2 Structural Pattern

 In software engineering, structural design patterns help simplify design by showing easy
ways to create connections between objects.
 Structural patterns act like blueprints for combining different classes and objects to build
bigger systems.
 Structural patterns are like data structures.

11
MODULE-3 SOFTWARE DESIGN
Here are some types of structural design patterns:

1. Bridge: Splits the interface of an object from how it is built inside.

2. Adapter: Connects or matches different classes so they can work together.
3. Composite: Lets you treat a group of objects and a single object in the same way (like a tree
structure).
4. Decorator: Adds new features to an object without changing its structure.
5. Façade: Gives a simple interface to a complicated system.
6. Flyweight: Shares objects to save memory when many similar objects are needed
7. Private class data: Limits access to class data to keep it safe.
8. Proxy: An object that acts on behalf of another object.

3.4.3 Behavioural Pattern

 Behavioural design patterns describe how objects talk to each other.

 They help objects work together and make communication easier and more flexible.
 These patterns explain how objects share messages and divide tasks.

Some types of behavioural design patterns:

1. Chain of responsibility: Passes a request along a chain of handlers until one can handle it.
2. Command: Puts all the details of a request into one object.
3. Interpreter: Defines how to read and process sentences in a language (good for custom
languages).
4. Iterator: Lets you go through the items in a collection one by one.
5. Mediator: Helps objects talk to each other through one central object (the mediator), instead
of talking directly.
6. Null object: Provides a default object to avoid using null.
7. Memento: Saves and restores an object’s state (like undo).
8. Observer: Keeps track of other objects; when one changes, the others get updated
automatically.
9. State: Changes an object’s behavior when its state changes.
10. Strategy: Puts an algorithm inside a class so it can be changed easily.
11. Template method: Defines the steps of an algorithm but lets subclasses fill in the details.
12. Visitor: Adds new operations to a class without changing the class itself.

3.5 Model-View-Controller

Problem:
When we add new features to an app, the user interface often needs to change. Different users
may want different things, which can cause conflicts. Making a flexible system is costly and
error-prone if the user interface is too connected to the core logic.

Solution:
Model-View-Controller (MVC) splits the app into three parts: model, view, and controller. This
keeps the user interface separate from the main logic.

Structure (How it works):

1) A user asks for a web page from the server. The server sends this request to the controller.
2) The controller then gets the needed data from the model.

12
MODULE-3 SOFTWARE DESIGN
3) The model talks to the database and sends the data to the controller after checking it.
4) The controller sends this data to the view to display it properly.
5) The view prepares and sends the nicely formatted data back to the controller.
6) The controller sends this final presentation to the user who asked for the web page. This is
the answer to the user’s request.

Participating classes:
The purpose of each part of MVC is:

⭐ Model

1. Handles the business logic or data rules.

2. Talks to the database to get data.
3. Checks if the data is correct.
4. Sends the correct data to the controller.

⭐ View

1) Gets data from the controller and prepares how it will look.
2) Shows this prepared data to the user.

⭐ Controller

1. Handles the flow: gets requests from the user (client), sends them to the model, and then to
the view. It also goes back from the view to the client.
2. Sends the final response to the user (client).

Known uses:

 MVC is mostly used in web development.

 A famous example of MVC is the user interface framework in Smalltalk.

13
MODULE-3 SOFTWARE DESIGN
Consequences

⭐ Advantages of MVC

1. Easy to make changes because business logic and presentation (UI) are separate.
2. Applications can be built faster.
3. Developers can work together more easily.
4. Overall development is faster.

⭐ Disadvantages of MVC

1) It’s complex and hard to learn and use.

2) Not good for simple apps, as it can make them slower or too complicated.

3.6 Publisher-Subscriber Pattern

⭐ Problem

 Often in apps, data changes in one place, and many parts of the app depend on it.
 For example, in GUI apps, if internal data changes, many views showing that data also need
to update.

⭐ Solution:

 Have a special part (component) that notifies all the other parts when data changes.
 In this pattern:
 One part is the Publisher (also called Subject). It knows about the data changes.
 The other parts are Subscribers (also called Observers). They get updates when data
changes.
 The publisher maintains a registry of currently subscribed components. Whenever a
component wants to become a subscriber, it makes use of subscribe interface offered by
publisher.
 Whenever the publisher changes the state, it sends the notification to all its subscribers.
 The subscribers then retrieve the changed data.
 Following are the freedoms used in publisher-subscriber pattern -
○ The publisher can decide which internal state changes it will notify to its subscribers.
○ An object can be subscriber to many publishers.
○ An object can take both the roles - it can be publisher or it can be a subscriber.
 Based on publisher-subscriber pattern the push and pull models are derived.
 In the push model, the publisher sends all updated data to subscribers.
 In the pull model, the publisher sends only basic info about changes. Subscribers must ask
the publisher for the full data when they need it.
 The push model is less flexible. The pull model is more flexible.

14
MODULE-3 SOFTWARE DESIGN

Known Uses:

 Event messaging: The Publisher-Subscriber pattern is used a lot in delivery and shipping.
 As online shopping grows, sending packages is very common.
 Delivery companies need to use their resources well.
 To deliver better, they need current info about where drivers are.
 Pub/Sub messaging helps them get this info and manage deliveries better.

✅ Advantages:

1. Supports working in a distributed system.

2. Easy to extend or add features.

✅ Disadvantages:

1) Not very efficient.

2) Hard to implement.

3.7 Adapter
Sometimes two parts of a system work well on their own but can’t work together directly. In that
case, we use an adapter to connect them.
In object-oriented design, the adapter pattern helps different classes or objects work together. It
acts like a bridge, just like a real-world power adapter lets you plug one type of device into
another kind of outlet.

Problem:
How to make two parts of a system with different interfaces work together smoothly?

Solution:
Change the original interface into another one using an adapter object in between.

His pattern Also called:Wrapper pattern (a type of GoF design pattern).

Types of Adapters:

1. Object adapters
2. Class adapters

15