Chapter 6 Software Engineering Design.ppt

Software Design in Software
Engineering

Definition (Simplified):
Software Design is like creating a blueprint before building software. It involves
planning how each part of the system will work together to solve a problem or
serve users efficiently.
Real-Life Analogy: Building a Restaurant
Real-Life (Restaurant) Software Design Equivalent
Choosing location & layout
High-Level Design (System
Architecture)
Menu planning (Starters, Mains...)
Module Design (Functional
Decomposition)
Kitchen, Reception, Washroom setup Components/Classes (UI, DB, APIs)
Staff roles – cook, server, manager Responsibilities of classes/modules
Rules – hygiene, timings Design Principles (SRP, DRY, KISS)
Opening checklist
Design Specification (UML,
Flowcharts, DFDs)

"Imagine if you built a restaurant without a layout, staff roles, or a
menu. It would be chaos! Software without design is just the
same."

Example: Zomato App
•User Interface = Dining Area (what the user sees)
•Restaurant Module = Kitchen (prepares data)
•Order Module = Waiter (connects customer to kitchen)
•Payment Module = Cashier (processes payments)
•Database = Pantry (stores everything)
•Cohesion = A chef only cooks, not takes orders (focus on one job).
•Coupling = Chef doesn’t need to know the cleaner’s schedule (modules work
independently).
•Abstraction = Customer doesn’t see how the food is cooked (hide internal
complexity).
•Encapsulation = Recipes (data) stay in the kitchen, not exposed to everyone.

“Software design is where we decide how to make a product that works
well, is easy to build, and easy to fix—just like a smart restaurant setup.”

Software Design
 Software design model consists of 4
designs:
Data/class Design
Architectural Design
Interface Design
Component Design

Translating Analysis  Design

 Data/class design - Created by transforming the analysis model class-based
elements into classes and data structures required to implement the software
 Architectural design - defines the relationships among the major structural
elements of the software, it is derived from the class-based elements and flow-
oriented elements of the analysis model
 Interface design - describes how the software elements, hardware elements,
and end-users communicate with one another, it is derived from the analysis
model scenario-based elements, flow-oriented elements, and behavioral
elements
 Component-level design - created by transforming the structural elements
defined by the software architecture into a procedural description of the
software components using information obtained from the analysis model
class-based elements, flow-oriented elements, and behavioral elements

Why design is so important?
 It is place where quality is fostered.
 It provides us with representation of software that can be
assessed for quality.
 Only way that can accurately translate a customer’s
requirements into a finished software product.
 It serves as foundation for all software engineering
activities.
 Without design difficult to assess:
 Risk
 Test
 Quality

Design Process and Design Quality
 S/w design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the s/w.
 As design iteration occur, subsequent
refinement leads to design representation
at much lower levels of abstraction.

Goal of design process
 The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.
 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.

Quality Guidelines
Characteristics of good design
 A design should exhibit an architecture that
 as been created using recognizable architectural styles or
patterns,
 is composed of components that exhibit good design
characteristics and
 can be implemented in an evolutionary fashion
 A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
 A design should contain distinct representations of data, architecture,
interfaces, and components.
 A design should lead to data structures that are appropriate for the
classes to be implemented. A design should lead to components that
exhibit independent functional characteristics

Quality Guidelines (contd.)
 A design should lead to interfaces that reduce the
complexity of connections between components and with
the external environment.
 A design should be represented using a notation that
effectively communicates its meaning.

Design Principles
 S/W design is both a process and a model.
 Design process - sequence of steps that
enable the designer to describe all aspects
of the software to be built.
 Design model - created for software
provides a variety of different views of the
computer software

Design concepts
 Abstraction
 Refinement
 Modularity
 Architecture
 Information Hiding
 Functional Independence
 Refactoring
 Design Classes
 Patterns

Abstraction
 At the highest level of abstraction – a solution is stated in broad terms
 At lower level of abstraction – a more detailed description of the
solution is provided.
 Two types of abstraction:
 Procedural abstraction: Sequence of instructions that have a specific
and limited function.
Ex. Open a door
open implies long sequence of activities (e.g. walk to the door, grasp
knob, turn knob and pull the door, etc).
 Data abstraction: collection of data that describes a data object.
Ex. Open a door. – door is data object.
 Data abstraction for door would encompass a set of attributes that
describe the door. (E.g. door type, swing direction, opening
mechanism, etc.)

Refinement
 Refinement is actually a process of elaboration.
 begin with a statement of function (or description of information)
that is defined at a high level of abstraction.
 That is, the statement describes function or information
conceptually but provides no information about the internal
workings of the function or the internal structure of the
information.
 Refinement causes the designer to elaborate on the original
statement, providing more and more detail as each successive
refinement (elaboration) occurs.
 Abstraction and refinement are complementary concepts.
Abstraction enables a designer to specify procedure and data
and yet suppress low-level details.
 Refinement helps the designer to expose low-level details as
design progresses.

Modularity
 Architecture and design pattern embody modularity.
 Software is divided into separately named and addressable
components, sometimes called modules, which are integrated to
satisfy problem requirement.
 modularity is the single attribute of software that allows a
program to be intellectually manageable
 It leads to a “divide and conquer” strategy. – it is easier to solve
a complex problem when you break into a manageable pieces.
 Refer fig. that state that effort (cost) to develop an individual
software module does decrease if total number of modules
increase.
 However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.

 Undermodularity and overmodularity should be
avoided. But how do we know the vicinity of M?
 We modularize a design so that development can
be more easily planned.
 Software increments can be defined and delivered.
 Changes can be more easily accommodated.
 Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.

Architecture
 Software architecture suggest “ the
overall structure of the software and
the ways in which that structure
provides conceptual integrity for a
system.
 Simply it is a structure or organization
of program components.

Information Hiding
 The principle of information hiding suggests that
modules be "characterized by design decisions that
(each) hides from all others modules.“
 In other words, modules should be specified and
designed so that information (algorithm and data)
contained within a module is inaccessible to other
modules that have no need for such information.
 It gives benefits when modifications are required during
testing and maintenance because data and procedure
are hiding from other parts of software, unintentional
errors introduced during modification are less.

EFFECTIVE MODULAR DESIGN
 Effective modular design consist of three
things:
Functional Independence
Cohesion
Coupling

Functional Independence
 Functional independence is achieved by developing
modules addresses a specific sub-function of
requirements and has a simple interface when viewed
from other parts of the program structure.
 Independence is important –
 Easier to develop
 Easier to Test and maintain
 Reusable module.

Functional Independence
 To summarize, functional independence is a key
to good design, and design is the key to
software quality.
 To measure independence, have two qualitative
criteria: cohesion and coupling
 Cohesion is a measure of the relative functional
strength of a module.
 Coupling is a measure of the relative
interdependence among modules.

Cohesion
 Cohesion is a natural extension of the information hiding concept
 A cohesive module performs a single task within a software
procedure, requiring little interaction with procedures being
performed in other parts of a program
 Simply state, a cohesive module should (ideally) do just one thing.
 We always strive for high cohesion, although the mid-range of the
spectrum is often acceptable.
 Low-end cohesiveness is much "worse" than middle range, which
is nearly as "good" as high-end cohesion.
 So. designer should avoid low levels of cohesion when modules
are designed.

Cohesion
 When processing elements of a module are
related and must be executed in a specific order,
procedural cohesion exists.
 When all processing elements concentrate on
one area of a data structure, communicational
cohesion is present.
 High cohesion is characterized by a module that
performs one distinct procedural task.

Types of cohesion
 A module that performs tasks that are related
logically is logically cohesive.
 When a module contains tasks that are related
by the fact that all must be executed with the
same span of time, the module exhibits temporal
cohesion.
 At the low-end of the spectrum, a module that
performs a set of tasks that relate to each other
loosely, called coincidentally cohesive.

Coupling
 Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to
a module, and what data pass across the interface
 In software design, we strive for lowest possible
coupling. Simple connectivity among modules results in
software that is easier to understand and less prone to a
"ripple effect" caused when errors occur at one location
and propagate through a system.
 It occur because of design decisions made when
structure was developed.

Coupling
 Coupling is characterized by passage of control between
modules.
 “Control flag” (a variable that controls decisions in a
subordinate or superordinate module) is passed between
modules d and e (called control coupling).
 Relatively high levels of coupling occur when modules
are communicate with external to software.
 External coupling is essential, but should be limited to a
small number of modules with a structure.

 As long as simple data are passed
low coupling is exhibited(module a
and c).
 Stamp coupling is found when a
portion of a data structure is passed
is passed via module interface.
(between a and b).

 High coupling also occurs when a number of modules
reference a global data area.
 Common coupling, no. of modules access a data item in
a global data area
 So it does not mean “use of global data is bad”. It does
mean that a software designer must be take care of this
thing.

Refactoring
 An important design activity.
 Reorganization of technique that
simplifies the design of a component
without changing its function or behavior i.
e. changing a s/w system in such way that
it does not alter the external behavior yet
improves the internal structure.

Design Classes
 Five different types of design classes are suggested.
User interface classes: define all abstractions necessary
for human computer interaction.
Business domain classes: refinements of analysis classes
defined earlier.
Process classes: implement lower level business
abstraction that fully manages the business domain
classes.
Persistent classes: Represent databases

System classes: implements software
management and control functions.

Characteristics of good design classes
 Complete and sufficient: should be the complete
encapsulation of all attributes and methods.
 Primitiveness: methods should be focused on
accomplishing one service for the class.
 High cohesion: The modules should be highly
cohesive.
 Low coupling: Design classes within a
subsystem should have only limited knowledge
of classes in other subsystems.

Patterns
 Describes a design structure that solves a
particular design problem within specific
content.

The Design model
 Can be viewed in two different dimensions
Process dimension: indicates the evolution of
the design model as design tasks are
executed.
Abstraction dimension: indicates the level of
detail as each element of the analysis model
is transformed into a design equivalent and
refined iteratively.

Data Design elements
 Creates model of data and information that
is represented at high level of abstraction.
 This model is then refined into more
implementation specific representations
that can be processed by computer based
system.

Architectural design elements
 Its equivalent to the floor plan of house.
 Floor plan depicts overall layout of the rooms,their
size,shape and relationship to one another.
 It gives us a overall view of the software.
 Derived from three sources.
Info about the application domain
Analysis model elements-flow diagrams, analysis
classes
Availability of architectural styles

Interface design elements
 Equivalent to set of detailed drawings for
the doors, windows and ext utilities.
 Depicts size and shapes for doors and
windows.
 Manner in which they operate, the way in
which utilities connections come into
house and are distributed amongst rooms.

 There are three elements of interface
design
User interface (UI)
External interfaces to other systems, devices,
networks
Internal interfaces between various design
components.

Component level design elements
 Equivalent to set of detailed drawings for each
rooms in house.
 Depicts wiring and plumbing within each room,
location of switches, sinks, showers, tubs, drains,
and every other details associated with room.
 For software it fully describes internal details of
each component.
 It defines data structure, algorithm and
interfaces.

Deployment level design
elements
 Indicates how software functionality and
subsystems will be allocated within the
physical computing environment that will
support the software.

Pattern based software design
 Mature engg disciplines make use of thousand of
design patterns.
 For ex an electrical engineer uses an integrated
circuit (extr complex design pattern) to solve the
problem.
 design pattern may also contain a set of design
forces. Design forces describe non functional
requirements associated with sw.
 Forces may define the constraints.

Using patterns in design
 Design patterns can be used throughout s/w
design.
 Types of design patterns
Architectural design patterns: define overall structure
of the s/w,indicates relationship among subsystems
and s/w components.
Design Patterns: addresses specific elements of
design such as an aggregation of components to
solve some design problem, and their relationship.

Idioms:
Sometimes called coding pattern
implements an algorithmic elements of
component or a mechanism for
communication among components.

Chapter 6 Software Engineering Design.ppt

More Related Content

Similar to Chapter 6 Software Engineering Design.ppt

More from RahulBhole12

Recently uploaded

Chapter 6 Software Engineering Design.ppt

Editor's Notes