Chapter -1

Introduction to Software Design

1
 Software design
 Software design is a phase in software development where:

 The what (is the problem), during RE, of the software under attention is
converted to How (is the problem solved)?

 RE = understanding the problem and the need of customers, then

 SD = Solving the Solution (using NL and Modeling NOT programming)

2
 Why Should The Software Be
Designed At All?
 Because:
 We can’t just throw few dozens of programmers to start programming without any
detailed plans.
 Design is highly creative stage in software development where the designer plans

 how the system or program should meet the customer’s

needs
 how to make system effective and efficient

3
 What is Software Design?
• Software design sits at the technical kernel of SE and is applied regardless of

the software Project Management that is used. [R. Pressman]

• Software Design is an iterative and creative process targeting to create solution for the users

requirements.

• Software design is an iterative process through which requirements are translated into a “blueprint”
for constructing the software.

• If two things describe SD they must be:

 Realizing the SRS in NL (natural language) and

 Achieving Quality solution (Reliability, Efficiency, Maintainability, Usability …) 4

 Design and Software Qualities
• Rememeber that, the importance of software design can be stated with a single word Quality.
• Thinking software quality and design in separate keeps them so forever.

• Design is the only way that we can accurately translate a customer's requirements into a finished software
product or system.

• The difference between several software developed for the same purpose is nothing more that

difference in Quality.

• Software Quality includes Reliability, Efficiency, Maintainability, Usability

• Means to assure qualities are formal technical reviews or design walkthroughs

during design process.

5
 Design and Software Qualities ....
 For the systems to be reliable, the designers should count on

completeness, consistency, availability and robustness.

 Efficiency of a system can be measured through its use of resources

such as processor time, memory, network access and so on.

 By separating the concerns, designers can help the future maintainers to

gain clear understanding of their original ‘mental models’.

6
 SW Quality;10 heuristics of UI design
1. Visibility of system status
2. Match between system and the real world

3. User control and freedom: give freedom to user but until they become dangerous
4. Consistency and standards: if ok &cancel buttons are left & right. must always be so

5. Error prevention: male/female check/combobox is better than textbox where user can enter wrong data
6. Recognition rather than recall ( Minimize the user's memory load by making objects,
actions, and options visible.)
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
7
10. Help and documentation
 Design Strategies
• Before sinking into Design Process detail ,Pick a strategy[aka

Methodology]

 Function Oriented Design: Program = function + data + control

 Object Oriented Design : Program = Class(objects) + control

 Service Oriented Design: Program = +/-/*/(/) (services)

8
Complexity of design

 “The most common miracles of software engineering are the

transitions from analysis to design and design to code.”
[Richard Dué]
 No question, Design is the toughest SE activity, Why?
Creativity is the most Expensive human element found in
scarce and core for design.
9
 Function Oriented Design Strategy
• Design is decomposed into set of interacting units where a unit

has specified function

• Conceals the details of an algorithm in a function but system state information is not

hidden.

• The activities of this strategy;

• Data-flow design

• Structural decomposition

• Detailed design description

10
 Object-oriented design strategy
 Is based on the idea of information hiding.

 System is viewed as a set of interacting objects, with their own private state.

 Dominant design strategy for new software systems.

 Objects communicate by calling on services offered by other objects rather than sharing

variables. This reduces the overall system coupling.

 Message passingallows objects to be implemented as concurrent processes.

• Kinds of concurrent object implementation

• Passive objects : holds data, but does not initiate control

• Active objects : owns a thread of control and can initiate control activity
11
 Software Design Activities
 In software design and architecture, several key activities are performed to ensure that a
software system is well-structured, maintainable, scalable, and meets the requirements of
stakeholders.
 These activities generally occur during the planning and early stages of the software
development life cycle (SDLC). Here's a breakdown of the main activities:
1. Requirement Analysis
 Objective: Understand and document what the system is supposed to do.
 Activities: Gather functional and non-functional requirements from stakeholders.
 Create use cases, user stories, and scenarios to capture system behaviors.
 Prioritize requirements based on business value and technical feasibility.
12
 Software Design Activities …
2. System Architecture Design

 Objective: Establish the high-level structure of the software system.

 Activities: Define the system's components, modules, and their relationships.

 Choose architectural patterns (e.g., microservices, monolithic, layered).

 Determine deployment architecture (e.g., cloud, on-premise, hybrid).

 Address non-functional requirements like scalability, security, and performance.

 Create system-level diagrams like component diagrams and deployment diagrams.

13
 Software Design Activities …
3. High-Level Design (HLD)

 Objective: Create a blueprint of how the system will function.

 Activities: Break down the architecture into subsystems or modules.

 Define interactions between components, using techniques like sequence diagrams and

flowcharts.

 Specify key design patterns (e.g., MVC, Singleton, Factory) for the solution.

 Identify key data structures and algorithms to solve specific problems.

 Develop API contracts, database schemas, and external interfaces. 14

 Software Design Activities …
4. Low-Level Design (LLD)

 Objective: Provide detailed design for individual components or modules.

 Activities: Define the internal structure of each module or component.

 Write detailed class diagrams, including relationships like inheritance and associations.

 Define data flow and logic for each function and method.

 Choose specific technologies, frameworks, and libraries to implement the design.

 Handle error conditions, edge cases, and exception handling in detail.

15
 Software Design Activities …
5. Prototyping
 Objective: Create a working model or simulation of the system to validate design decisions.
 Activities: Build small, functional prototypes of key components or features.
 Test assumptions regarding system behavior, performance, or usability.
 Refine design based on feedback from stakeholders and users.

6. Design Validation
Objective: Ensure that the design meets the requirements and quality standards.
Activities: Conduct design reviews with stakeholders and technical teams.
 Perform trade-off analysis between different design options.
 Validate the design against functional and non-functional requirements. 16
 Software Design Activities …
7. Technology Selection
 Objective: Choose the tools, frameworks, and technologies for implementation.
 Activities: Evaluate and select programming languages, development frameworks, and
libraries.
 Choose databases, messaging systems, and middleware for integration.
 Decide on tools for version control, CI/CD pipelines, testing, and monitoring.

8. Design Documentation
 Objective: Record the design decisions, architecture, and guidelines for development.
 Activities: Create technical specifications that detail the system’s architecture and design.
 Maintain up-to-date documentation for APIs, database schemas, and system components.
17
 Provide guidelines for coding standards, testing strategies, and deployment configurations.
 Software Design Activities …
9. Risk Identification and Mitigation

 Objective: Identify and address potential risks to the software project.

 Activities: Perform risk analysis for architecture and design decisions.

 Identify potential bottlenecks or failure points in the system.

10. Design Iteration and Refinement

 Objective: Continuously improve and refine the software design.

 Activities: Iterate on the design based on feedback from prototypes, early development, and

testing. 18
 Design Considerations
 Design considerations are specific factors or constraints that need to be taken into account
during the software design process.
 These include:
1. Scalability
Consideration: Will the system need to handle increasing loads, such as more users or data?
Design Response: The system should be designed to scale horizontally (e.g., by adding more
servers) or vertically (e.g., by upgrading hardware).
2. Performance
Consideration: How fast should the system respond under different loads?
Design Response: Optimize for speed by reducing bottlenecks, minimizing database queries,
and caching frequently accessed data. 19
 Design Considerations
 Security
 Consideration: What are the potential threats to the system’s data and functionality?
 Design Response: Use encryption, secure authentication mechanisms, and follow security
best practices such as input validation and access controls.
 Maintainability
 Consideration: How easy is it to modify, extend, or fix the system in the future?
 Design Response: Use modular design, clear documentation, and follow coding standards
that make the codebase easy to understand and update.
 Usability
 Consideration: Is the system intuitive and user-friendly for its intended users?
 Design Response: Incorporate UX/UI best practices, conduct usability testing, and design
20
interfaces that are simple and effective.
 Design Principles
 Design principles are general rules or guidelines that influence the design of software
systems.
 Adhering to these principles helps ensure the system is flexible, maintainable, and robust.
 Separation of Concerns
 Principle: Divide the system into distinct sections where each section addresses a separate
concern or functionality.
 Example: In a web application, separate the business logic from the user interface and the
data access layer.
 Single Responsibility Principle (SRP)
 Principle: Every module or class should have one, and only one, reason to change, meaning
it should do one thing well.
 Example: A class responsible for user authentication should not also handle database
queries.

21
 Design Principles …
 Open/Closed Principle (OCP)
 Principle: Software entities should be open for extension but closed for modification.
 Example: Use interfaces or abstract classes to allow new behaviors to be added without
changing existing code.
 Liskov Substitution Principle (LSP)
 Principle: Objects of a superclass should be replaceable with objects of a subclass without
affecting the correctness of the program.
 Example: If Bird is a superclass and Penguin is a subclass, the system should be able to
handle Penguin where Bird is expected.

22
 Design Principles …
 Composition Over Inheritance
 Principle: Prefer composing objects with smaller behaviors over inheriting behaviors from
parent classes.
 Example: Instead of creating a class FlyingCar that inherits both Car and Airplane,
compose a class that includes Flyable and Driveable behaviors.
 Favor High Cohesion and Loose Coupling
 Cohesion: Modules should focus on a specific task and do it well, increasing readability and
maintainability.
 Coupling: Dependencies between modules should be minimized to reduce the impact of
changes in one module on others.
23
 Tackling Design Problem
• Any design problems must be tackled in three stages;

1. Study and understand the problem [review the SRS]

2. Identify gross features of an optimal solution [Architectural Design]

3. Describe each abstraction and component used in the solution

[detail design]

24
Tackling Design Problem
….

25
 CHAPTER - 2
Design Patterns
 What is a design Pattern?

 A design pattern is a mechanism to design reusability for reccuring design

problems.

 Given a reccuring design problem and a proven experience of solving it there is no

need for amateur application designers to go that rough path (creating the design
solution) by them selves.

 Do we have a design pattern for every design probllems?

 It depends! for example in terms of ASPECTS yes we have 26

 Classification of Design patterns
• Based on their Gross (High-level) purpose, Design Patterns are broadly grouped in to:

1. Creational Patterns
• provide various object creation mechanisms, which increase flexibility and reuse of
existing code.

2. Structural patterns

• concerned with how classes and objects can be composed, to form larger structures

3. Behavioral patterns

• concerned with algorithms and the assignment of responsibilities between objects.

27
1. Creational Design
Patterns
• “Creational design patterns are design patterns that deal with
object creation mechanisms, trying to create objects in a manner
suitable to the situation.
• The basic form of object creation could result in design problems or added
complexity to the design. Creational design patterns solve this problem by
somehow controlling this object creation.”
• CDPs define the best possible way in which an object can be
created considering reuse and changeability.
• Examples: Factory, Abstract Factory, Builder, Prototype and Singleton
design patterns are Creational DPs.

16
 Creational Patterns
• if reuseability and changeability are desired qualities for the
…software

you are designing, hard coding (making it part of the programming

code) the actual instantiation is a pitfall and should be avoided.

• In such scenarios, we can make use of patterns to give this a more

general and fl exible approach using the appropriate

creational pattern.
29
 A. Factory
Pattern
Definition:
The Factory pattern provides a way to use an instance as a
object factory. The factory can return an instance of one of
several possible classes (in a subclass hierarchy),
depending on the data provided to it.
If you have a class having several subclasses of
implementation based on the nature of the user input
(request type), then this pattern is an ideal solution to build
the selector with.
30
 When is right to use the factory
pattern
 When a class can't anticipate which kind of class of object it
must create.

 When you have classes that are derived from the same
subclasses

 When you want to insulate the client from the actual type

that is being instantiated.

31
Factory pattern: Structure

32
Example
:
public abstract class Product { public class TestClientFactory {
public void writeName(String name)
public static void main(String[] args) {
{ System.out.println("My name is
ProductFactory pf = new
"+name); } ProductFactory();
}
Product prod;
public class ProductA extends Product { }
prod = pf.createProduct("A");
public class ProductB extends Product
{ public void writeName(String name) {
prod.writeName("John Doe");
StringBuilder tempName = new prod = pf.createProduct("B");
StringBuilder().append(name);
prod.writeName("John Doe");
System.out.println("My reversed name is" +
tempName.reverse()); }
}} }
public class ProductFactory { Product When TestClientFactory is executed
createProduct(String type)
the result is:
{ if(type.equals("B"))
• c:> My name is John Doe
return new ProductB();
else
• c:> My reversed name is eoD nhoJ
33
return
} new ProductA();
B. Abstract Factory
Pattern
• Definition
• The Abstract Factory pattern is a creational pattern related to the
Factory Method pattern, but it adds another level of abstraction.
• What this means is that the pattern encapsulates a group of individual
concrete factory classes (unlike the concrete factory methods which are
derived in subclasses) which share common interfaces.
• The client software uses the Abstract Factory which provides an
interface for creating families of related or dependent objects without
specifying their concrete classes.
• This pattern separates the implementation details of a set of
objects from its general usage.
22
Where to use the Abstract Factory
Design Pattern
• Use AF Pattern when:
 You need to create sets of objects that share a common
theme and where the client only needs to know how to
handle the abstract equivalence of these objects, i.e.
the implementation is not important for the client.
 The Abstract Factory is often employed when there is
a need to use different sets of objects and where the
objects could be added or changed some time during
the lifetime of an application.
35
Abstract Factory DP: Structure

36
Abstract Factory DP: participants & role
in
the structure

37
C. The Singleton Pattern
• Definition

• The Singleton pattern provides the possibility to control

the number of instances (mostly one) that are allowed
to be made. We also receive a global point of access to
it (them).

38
Singleton Pattern:Where
to use
• When only one instance or a specific number of instances
of a class are allowed.

• Benefits of the singleton pattern includes:

• Controlled access to unique instance.

• Reduced name space.

• Allows refinement of operations and representations.

39
Singleton
pattern:Drawbacks/consequences
• Singleton pattern is also considered an anti-pattern
by some people, who feel
that it is overused, introducing
unnecessary limitations in situations where a sole
instance of a class is not actually required.

• Singleton structure is shown below (Java):

40
Singleton pattern:
Example
package com.logica.singleton;
public class FileLogger {
private static FileLogger
logger;
private FileLogger() {// made
private to Prevent clients
from using the constructor
}
//Control the accessible (allowed) instances
public static FileLogger getFileLogger()
{ if (logger == null) {
logger = new FileLogger();
}
return logger;
}
public synchronized void log(String msg) {
} Write to log file...
// 29
Design
Patterns
Structural Design Patterns
• “In software engineering, structural design
patterns are design patterns that ease the
design by identifying a simple way to realize
relationships between entities.”
• Structural Patterns describe how objects and classes can
be
combined to form structures.
• Hence, they help during designing a software Components’
structure.
class patterns Vs. object patterns
• We distinguish between object patterns and class patterns.

• The difference is that class patterns describe relationships and

structures with the help of inheritance.

• Object patterns, on other hand, describe how objects can be

associated and aggregated to form larger, more complex structures.
 The Adapter (aka Wrapper)
Pattern
• Definition
• The Adapter pattern is used to translate the interface of one class into another
interface. This means that we can make classes work together that couldn't otherwise
because of incompatible interfaces.
• A class adapter uses multiple inheritance (by extending one class and/or implementing
one or more classes) to adapt one interface to another. An object adapter relies on
object aggregation.
Adapter DP: Where to use
• The Adapter Pattern is used when we want to:
• Use an existing class, and its interface does not match the one you
need.
• Create a reusable class that cooperates with unrelated or unforeseen
classes, that is, classes that don't necessarily have
compatible interfaces.
• Increase transparency of classes.
• Make a pluggable kit.
• Generally, when we want to reuse classes in an application that
expects classes with a different interface, we do not want (and
often cannot) to change the reusable classes to suit our
application.
Adapter Pattern:
Structure In the class-diagram at left:
• A Client class expects/ collaborates with a
certain interface (called the Target interface)
• An available interface doesn't match the
Target interface
• An Adapter class bridges the gap
between
the Target interface and the available
interface by Adapting the interface of the
adaptee to the target interface.
• The available interface is called the
Adaptee
• Target: Defines the application-specific
interface that clients use.
• Adaptee: Defines an existing interface that
needs adapting.
Bridge Pattern
• Definition
•Decouple an abstraction or interface from its implementation so that the
two can vary independently.
• Bridge makes a clear-cut between abstraction and implementation.
Bridge Pattern: Where
to Bridge
The use pattern is ideal to employ when you want to:
• Separate the abstract structure and its concrete implementation.
• Share an implementation among multiple objects,
• Reuse existing resources in an 'easy to extend' fashion.
• Hide implementation details from clients. Changes in implementation
should have no impact on clients.
Bridge Pattern: Consequences
Benefits
• Implementation can be selected or switched at run-time.
• The abstraction and implementation can be independently
extended or composed.
• Changing an implementation class doesn't require recompiling the
Abstraction class and its clients
Bridge Pattern: Structure
• In the class-diagram at left:
• Abstraction defines the abstract interface
and maintains the Implementor reference.
Also forwards client requests to its
Implementor object
• Refined Abstraction extends the interface
defined by Abstraction.
• Implementor defines the interface for
implementation classes.
• ConcreteImplementor implements the
Implementor interface.
Composite Pattern
• Definition
• The Composite pattern helps you to create tree structures of objects without the need
to force clients to differentiate between branches and leaves regarding usage. The
Composite pattern lets clients treat individual objects and compositions of objects
uniformly.
• Compose objects into tree structures to represent part-whole hierarchies.
Composite pattern:Where to use
The need for employing composite patterns in design comes when you
need to:
• represent a part-whole relationship in a tree structure.
• clients to be able to ignore the differences between compositions of
objects and individual objects.
• Let the structure can have any level of complexity and is dynamic.
Composite Pattern: Consequences
Benefits
• Define class hierarchies consisting of primitive objects and composite objects.
• Makes it easier to add new kind of components.
• Clients don't have to be changed for new Component classes added.
Drawbacks/consequences
• The Composite pattern makes it easy for you to add new kinds of components to
your collection as long as they support a similar programming interface.
• On the other hand, this has the disadvantage of making your system overly
general. You might find it harder to restrict certain classes where this
would normally be desirable.
Composite Pattern: Structure
• The key to the Composite
pattern is an abstract class
that represents both
primitives and their
containers.
• For the graphics system, this
class is Graphic.
• Graphic declares operations like
Draw that are specific to
graphical objects.
 Design
Patterns
Behavioral Design Patterns
Behavioral Design
Patterns
• “In software engineering, behavioral design patterns are design
patterns that identify common communication patterns
between objects and realize these patterns. By doing so,
these patterns increase flexibility in carrying out this
communication.”
• Behavioral patterns are patterns that focuses on the interactions
between cooperating objects with louse coupling.
Behavioral Design
patterns … with algorithms and the assignment of
• BDPs are concerned
responsibilities between objects.
• They describe not just patterns of objects or classes but also the
patterns of communication between them.
• They characterize complex control flow that's difficult to follow at
run-time.
• They shift our focus away from flow of control to let you
concentrate just on the way objects are
interconnected.
 Behavioral Design Pattern tree

Behavioral Design
Patterns

Behavioral Object
Behavioral Class Patterns
Patterns

Template Observer Mediator The Command Strategy Chain of

Interpreter State pattern
Method pattern pattern Pattern pattern Responsibility
 Chain-of-responsibility Pattern
Definition

• The Chain-of-responsibility pattern lets more than one object handle a

request without mutual knowledge.

• We avoid coupling between the sender of a request and the possible

receivers.

• We place all receivers in a chain which lets the receiving objects pass the

request along to the next receiver in the chain until one receiver handles it,

or the end of the chain is reached.

 Where to use
 When more than one object may handle a request, and the handler isn't
known.
 When you want to issue a request to one of several objects without
specifying the receiver explicitly.
 When the set of objects that can handle a request should be specified
dynamically.
 Chain-of-Responsibility: Consequences
• Benefits

• It reduces coupling.

• It increases the flexibility of handling a request.

• Drawbacks

• Reception isn't guaranteed since a request has no explicit receiver, there's

no guarantee it will be handled unless the chain is configured properly.
Chain-of-Responsibility: Structure
Command
Pattern
Definition
• The Command pattern is used to create objects that represents actions
and events in an application. A command object
encapsulates an action or event and contains all information
required to understand exactly what has happened.
• By passing the command object as a parameter we can, extract the
needed information about occurred actions and events.
Command Pattern:Where to use
• Where you want an action that can be represented in many ways, like
dropdown
• menu, buttons and popup menu.
• To create undo/redo functionality
Thank
You

54