SEPM-Module 3

Presented by,
Dr. Neethu Anna Sabu
• Software Design Process:
• The software design process translates user requirements into a suitable form for software
coding and implementation.
• The Software Requirement Specification (SRS) document assesses user requirements, while
more specific requirements are needed for coding.
• The output of the design process can be directly used in programming languages for
implementation.
• It is an iterative process that translates requirements into a blueprint for constructing the
software.
• The design is initially represented at a high level of abstraction, directly linked to specific system
objectives and detailed requirements.
• Subsequent refinements lead to lower levels of abstraction that can still be traced to requirements
Key aspects of the design process and quality
• Design Definition Design is where stakeholder requirements,
business needs, and technical considerations converge to
formulate a system.
• It creates a model that details software architecture, data
structures, interfaces, and components

• Importance of Design Design allows for quality assessment and

improvement before code generation, testing, and user
involvement
• Without design:Systems may be unstable.
• Difficult to test.
• Unassessed quality until late in the process.
Design Process
• Software design is iterative.
• Begins with high-level abstraction traceable to system objectives.
• Refinement leads to detailed design representations, still
traceable to requirements.
Quality Guidelines

•Technical criteria for good design.

•Key guidelines:

•Use recognizable architectural styles.

•Compose components with good design characteristics.
•Use appropriate data structures.
•Ensure independent functional characteristics of components.
•Use interfaces to reduce complexity.
•Use repeatable methods based on requirements analysis.
•Use effective notation.
Quality Attributes

•FURPS stands for:

•Functionality
•Usability
•Reliability
•Performance
•Supportability
•These attributes should be considered during design.
Technical Reviews
• Quality is assessed through technical reviews (TRs) by the
software team.
• TRs aim to identify errors, omissions, or ambiguities in the design
before implementation.
Design Principles
• Simplicity: Impart necessary information without ambiguity.
• Interfaces: Manage data flow between components carefully.
• Iterative development: Always strive for simplicity.
Design Model Elements

• Data Design: Transforms class models into design class realizations.

• Architectural Design: Defines relationships between major structural
elements.
• Interface Design: Describes communication between software
elements.
• Component-level Design: Elaborates software components.
• Deployment-level Design: Allocates architecture and components to
the physical environment.
Assessing Design Quality

• Technical Reviews: Evaluate the evolving design.

• Quality Guidelines and Attributes: Used to define good design.
• Design Principles: Applied to achieve internal and external quality.
Quality Assurance

• SQA Plan: Defines the team’s Software Quality Assurance strategy.

• SQA Activities: Reviews, inspections, and testing to filter errors.
• Goal: To identify and remove errors early, improving defect removal
efficiency.
Design Metrics
• Design metrics measure the efficiency of the design aspect of the
software, considering architectural, object-oriented, and user
interface design.
• Architectural design metrics focus on the characteristics of the
program architecture and the effectiveness of modules.
• Object-oriented design metrics include size, functionality,
complexity, coupling, completeness, sufficiency, primitiveness,
similarity, and volatility.
• User Interface design metrics include layout appropriateness
• Design Principles:.
• The design process should not suffer from “tunnel vision.”
• The design should be traceable to the analysis model.
• The design should minimize the intellectual distance between the software
and the problem as it exists in the real world. The software structure should
mimic the problem domain's structure.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change and degrade
gently.
• The design should be assessed for quality during creation, not after
completion and be reviewed to minimize conceptual errors
• The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered
• Design is not coding, coding is not design
Quality Consideration
• The design model should be assessed for quality as it is being
created.
• Designs should be reviewed to minimize conceptual errors.
• Structured analysis aims to improve quality and reduce the risk of
system failure.
• A focus should be placed on reliability, flexibility, and
maintainability of the system
THE DESIGN PROCESS
• Design and Software Quality
• the quality of the evolving design is assessed with a series of formal technical
reviews or design walkthroughs
• Goal of the design process
• The design must implement all of the explicit requirements contained in the
analysis model
• The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective
 Technical criteria for good design

• A design should exhibit an architectural structure that has been created using recognizable
design patterns, is composed of components that exhibit good design characteristics and can
be implemented in an evolutionary fashion, thereby facilitating implementation and testing.
• A design should be modular; that is, the software should be logically partitioned into
elements that perform specific functions and subfunctions.
• A design should contain distinct representations of data, architecture, interfaces, and
components (modules).
• A design should lead to data structures that are appropriate for the objects to be
implemented and are drawn from recognizable data patterns.
• A design should lead to components that exhibit independent functional characteristics.
• A design should lead to interfaces that reduce the complexity of connections between
modules and with the external environment.
• A design should be derived using a repeatable method that is driven by information
obtained during software requirements analysis.
• all of these methods have a number of common characteristics:
(1) a mechanism for the translation of analysis model into a
design representation,
(2) a notation for representing functional components and their
interfaces,
(3) heuristics for refinement and partitioning, and
(4) guidelines for quality assessment
Design Concepts
• Software design involves principles, concepts, and practices for
creating a high-quality system.
• Key design concepts include:
• Abstraction Simplifies a problem by ignoring details and focusing on
essential aspects, achieved through modeling. -hiding complex
details and showing only the essential features of an object or system,
making it easier to understand and work with.
• Architecture Refers to the structure and organization of software
components and their relationships. A high-level software design is
sometimes referred to as the software architecture.
• Aspects These are mechanisms that go beyond subroutines and
inheritance-advanced software design concepts or mechanisms
that go beyond basic elements like subroutines (functions/methods)
and inheritance (a core concept of object-oriented programming)
• Separation of Concerns This involves dividing a complex problem into
manageable parts.
• Modularity Logically partitioning software into elements or subsystems. A
modular design is easy to understand.
• Information Hiding This makes program maintenance easier and reduces
unintended side effects. Object-oriented design uses objects to hide data.
• Functional Independence: Achieved through modules with focused
functions and limited interaction.
• Refinement A top-down strategy that develops the design by detailing
procedural levels. Successive refinement of high-level functions into more
detailed functions is denoted as top-down decomposition.
• Refactoring This reorganizes the existing design to simplify components
and improve understanding
• Patterns: Patterns are commonly accepted solutions to recurring
design problems.
• Design patterns provide a common vocabulary and help produce
flexible, efficient, and maintainable designs. Architectural patterns
offer solutions to high-level design problems, while design patterns
suggest class structures and interactions.

• A good design should be correct, understandable, efficient, and maintainable.

• Understandability is a major concern and can be enhanced through abstraction
and decomposition. An understandable design is modular and layered.
• Good design should exhibit firmness, commodity, and delight.
• Firmness means the program should not have bugs that inhibit its
function.
• Commodity means the design should be suitable for its intended
purpose.
• Delight means the design should be pleasurable to use.
• An understandable design is modular and layered.
• A good design should also be assessed via technical reviews
 Design Model
• The design model offers details regarding the software architecture,
data structures, interfaces, and components necessary for system
implementation.
• It is a representation or model of the software; not a program.
• It provides detail about software architecture, data structures, interfaces,
and components that are necessary to implement the system
• Each element of the requirements model provides information
necessary to create the different design models required for a
complete design specification
• A design's quality can be assessed before implementation, allowing
for inexpensive corrections of errors, omissions, or inconsistencies
• The design model can be viewed in two dimensions: process and
abstraction.
• Process dimension shows the design model's evolution as design tasks
are executed as part of the software process.
• Abstraction dimension represents the level of detail as each element of
the analysis model is transformed.
Four major elements of the design model
• Data. At the architectural (application) level, data design focuses on files or
databases. At the component level, data design considers the data structures that
are required to implement local data objects.
• Architecture. The architectural design element is usually depicted as a set of
interconnected subsystems, often derived from analysis packages within the
requirements model.
• Components. Component-level elements define each of the modules
(components) that populate the architecture.
• Interface. Interface design elements model external and internal interfaces and
the user interface
Pattern based software design
• Pattern designing refers to the application of design patterns, which
are reusable and proven solutions to common problems encountered
during the design and implementation of software systems.
• patterns are proven, time-tested solutions that help developers create
more scalable, maintainable, and flexible code.
• idea is to speed up the development process by providing well-
tested, proven development/design paradigms.
• Design patterns are programming language-independent strategies
for solving a common problem.
• To find out which pattern to use, you just have to try to understand the
design patterns and their purposes
Characteristics of Pattern Designing
• Problem-Solution Approach-identify common design problems and
provide well-defined solutions that have been proven effective in
similar contexts.
• Reusability-promote code reusability-saving time and effort.
• Abstraction-focus on high-level design concepts
• Common Vocabulary-common vocabulary and set of terms that
developers can use to discuss and communicate design concepts
• Proven Solutions-solutions that have been tried and tested in real-
world scenarios.
Types of Design Patterns
• Creational Design Patterns
• These patterns deal with object creation mechanisms, trying to
create objects in a manner suitable to the situation.
• The goal is to make the system independent of the way the objects
are created, composed, and represented.
• give a lot of flexibility in what gets created, who creates it, how it
gets created, and, when.
• Examples:
• Singleton Pattern: Ensures that a class has only one instance
and provides a global point of access to it.
• Factory Method Pattern: Defines an interface for creating an
object, but allows subclasses to alter the type of objects that will
be created.
• Abstract Factory Pattern: Provides an interface for creating
families of related or dependent objects without specifying their
concrete classes.
• Builder Pattern: Allows the construction of a complex object step
by step.
• Prototype Pattern: Creates a new object by copying an existing
object, known as a prototype.
Structural Design Patterns
• Structural Design Patterns are concerned with how classes
and objects are composed to form larger structures
• deal with object composition and how objects are structured to
form larger structures.
• They help ensure that the system remains flexible by identifying
simple ways to realize relationships between entities.
• Examples:
• Adapter Pattern: Allows incompatible interfaces to work together
by providing a wrapper that converts one interface to another.
• Composite Pattern: Composes objects into tree-like structures
to represent part-whole hierarchies. Clients can treat individual
objects and composites uniformly.
• Decorator Pattern: Allows functionality to be added to an object
dynamically without altering its structure.
• Facade Pattern: Provides a simplified interface to a complex
subsystem, making it easier for clients to interact with.
• Behavioral Patterns: These patterns deal with how objects interact
and communicate with each other.
Examples include:
• Observer: Allows a subject to notify its observers about changes
without knowing who or what those observers are.
• Strategy: Defines a family of algorithms and allows them to be
interchangeable.
• Command: Encapsulates a request as an object, allowing for
parameterization of clients with different requests.
• Iterator: Provides a way to access elements of a collection
sequentially without exposing its underlying structure.
• State: Allows an object to alter its behavior when its internal state
changes.
• Template Method: Defines the steps of an algorithm, allowing
subclasses to implement some steps.