19CSE314

Software Engineering
Design Concepts

Amrita Vishwa Vidyapeetham, Coimbatore

 Design Concepts

Pressman R S, Bruce R.Maxim, “Software engineering - A

Practitioner’s Approach”, Eighth Edition, Tata McGraw-Hill, 2014
Chapter 12: 12.1-12.4
Chapter 13: 13.1, 13.3, 13.6 2
 Topics Covered
Topic Text Book Reference
Design Within the Context of Software Engineering 12.1
The Design Process 12.2
Design Concepts 12.3
Software Architecture 13.1
Architectural Styles 13.3
Architectural Design 13.6

3
 Software Design
• Software design encompasses the set of principles, concepts,
and practices that lead to the development of a high-quality
system or product
• Design principles establish an overriding philosophy that guides
the design work you must perform
• Design concepts must be understood before the mechanics of
design practice are applied, and design practice itself leads to
the creation of various representations of the software that serve
as a guide for the construction activity that follows
• Design is pivotal to successful software engineering
4
 DESIGN WITHIN THE CONTEXT OF
SOFTWARE ENGINEERING
• Software design sits at the technical kernel of software
engineering and is applied regardless of the software process
model that is used
• Beginning once software requirements have been analyzed and
modeled, software design is the last software engineering action
within the modeling activity and sets the stage for construction
(code generation and testing)
• Each of the elements of the requirements model (Chapters 9–11)
provides information that is necessary to create the four design
models required for a complete specification of design
5
DESIGN WITHIN THE CONTEXT OF
SOFTWARE ENGINEERING

6
 Data/Class design
• The data/class design transforms class models (Chapter 10) into
design class realizations and the requisite data structures
required to implement the software
• The objects and relationships defined in the CRC diagram and
the detailed data content depicted by class attributes and other
notation provide the basis for the data design activity
• Part of class design may occur in conjunction with the design of
software architecture
• More detailed class design occurs as each software component
is designed
7
 Architectural design
• The architectural design defines the relationship between
major structural elements of the software, the
architectural styles and patterns (Chapter 13 that can be
used to achieve the requirements defined for the system,
and the constraints that affect the way in which
architecture can be implemented
• The architectural design representation—the framework
of a computer-based system—is derived from the
requirements model
8
 Interface Design
• The interface design describes how the software
communicates with systems that interoperate with it, and
with humans who use it
• An interface implies a flow of information (e.g., data
and/or control) and a specific type of behavior
• Therefore, usage scenarios and behavioral models
provide much of the information required for interface
design

9
 The design process
• Software design is an iterative process through which requirements
are translated into a “blueprint” for constructing the software
• Initially, the blueprint depicts a holistic view of software
• That is, the design is represented at a high level of abstraction—a
level that can be directly traced to the specific system objective and
more detailed data, functional, and behavioral requirements
• As design iterations occur, subsequent refinement leads to design
representations at much lower levels of abstraction
• These can still be traced to requirements, but the connection is
more subtle
10
Software Quality Guidelines and Attributes
Three characteristics of a good design
• The design should implement all of the explicit requirements
contained in the requirements model, and it must accommodate
all of the implicit requirements desired by stakeholders
• The design should 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

11
 Quality Guidelines
• In order to evaluate the quality of a design representation, you and
other members of the software team must establish technical criteria
for good design
1. A design should exhibit an architecture that (1) has been created using
recognizable architectural styles or patterns, (2) is composed of
components that exhibit good design characteristics, and (3) can be
implemented in an evolutionary fashion, thereby facilitating implementation
and testing
2. A design should be modular; that is, the software should be logically
partitioned into elements or subsystems
3. A design should contain distinct representations of data, architecture,
interfaces, and components
12
 Quality Guidelines
4. A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns
5. A design should lead to components that exhibit independent
functional characteristics
6. A design should lead to interfaces that reduce the complexity of
connections between components and with the external environment
7. A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis
8. A design should be represented using a notation that effectively
communicates its meaning
13
 Quality Attributes - FURPS
Functionality Usability Reliability Performance Supportability
• is assessed by • is assessed by • is evaluated by • is measured • combines
evaluating the considering measuring the using extensibility,
feature set and human factors, frequency and processing adaptability,
capabilities of overall severity of speed, and
the program, aesthetics, failure, the response time, serviceability
the generality consistency, accuracy of resource
of the functions and output results, consumption,
that are documentation the mean-time- throughput,
delivered, and to-failure and efficiency
the security of (MTTF), the
the overall ability to
system. recover from
failure, and the
predictability of
the program

14
 Design Concepts

Separation of
Abstraction Architecture Patterns Modularity
concerns

Information Functional
Refinement Aspects Refactoring
Hiding Independence

Object Oriented
Dependency
Design Design Classes Design for Test
Inversion
Concepts

15
 Abstraction
• When you consider a modular solution to any problem, many levels of
abstraction can be posed
• Procedural abstraction refers to a sequence of instructions that have a
specific and limited function
• An example of a procedural abstraction would be the word open for a
door
– Open implies a long sequence of procedural steps (e.g., walk to the door, reach
out and grasp knob, turn knob and pull door, step away from moving door, etc.).
• A data abstraction is a named collection of data that describes a data
object
– In the context of the procedural abstraction open, we can define a data
abstraction called door
16
 Discussion

Provide examples of three data abstractions and the

procedural abstractions that can be used to manipulate them

17
 Architecture
Structure or organization of program components (modules), the manner in which
these components interact, and the structure of data that are used by the components

Structural Framewor Dynamic Process Functional

models k models models models models
increase the
Address the
level of design
behavioral
abstraction by
aspects of the
attempting to focus on the
represent program
identify design of the can be used to
architecture as architecture,
repeatable business or represent the
an organized indicating how
architectural technical functional
collection of the structure or
design process that the hierarchy of a
program system confi
frameworks system must system
components. guration may
(patterns) that accommodate
change as a
are encountered
function of
in similar types
external events
of applications
18
 Patterns
• A pattern is a named nugget of insight which conveys the essence of a proven
solution to a recurring problem within a certain context amidst competing
concerns”
• Stated in another way, a design pattern describes a design structure that solves
a particular design problem within a specific context and amid “forces” that may
have an impact on the manner in which the pattern is applied and used
• The intent of each design pattern is to provide a description that enables a
designer to determine
– whether the pattern is applicable to the current work,
– whether the pattern can be reused (hence, saving design time), and
– whether the pattern can serve as a guide for developing a similar, but functionally or
structurally different pattern

19
 Separation of Concerns
• Separation of concerns is a design concept that suggests
that any complex problem can be more easily handled if it
is subdivided into pieces that can each be solved and/or
optimized independently
• A concern is a feature or behavior that is specified as part
of the requirements model for the software
• By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time
to solve
20
• Modularity is the most common
manifestation of separation of concerns Modularity
• Software is divided into separately
named and addressable components,
sometimes called modules, that are
integrated to satisfy problem
requirements
• The effort (cost) to develop an
individual software module does
decrease as the total number of
modules increases
• Given the same set of requirements,
more modules means smaller individual
size
• However, as the number of modules
grows, the effort (cost) associated with
integrating the modules also grows 21
 Information Hiding
• The principle of information hiding suggests that modules be “characterized by design
decisions that (each) hides from all others.”
• In other words, modules should be specified and designed so that information (algorithms
and data) contained within a module is inaccessible to other modules that have no need
for such information
• Hiding implies that effective modularity can be achieved by defining a set of independent
modules that communicate with one another only that information necessary to achieve
software function
• The use of information hiding as a design criterion for modular systems provides the
greatest benefits when modifications are required during testing and later during software
maintenance
• Because most data and procedural detail are hidden from other parts of the software,
inadvertent errors introduced during modification are less likely to propagate to other
locations within the software
22
 Functional Independence
developing modules with “ single minded” function and an “aversion” to excessive
interaction with other modules

Cohesion is an indication of the relative Coupling is an indication of the relative

functional strength of a module interdependence among modules
• A cohesive module performs a single • Coupling depends on the interface
task, requiring little interaction with other complexity between modules, the point
components in other parts of a program at which entry or reference is made to a
• Stated simply, a cohesive module should module, and what data pass across the
(ideally) do just one thing interface
• Although you should always strive for • In software design, you should strive for
high cohesion (i.e., single-mindedness), the lowest possible coupling
it is often necessary and advisable to • Simple connectivity among modules
have a software component perform results in software that is easier to
multiple functions understand and less prone to a “ripple
effect” caused when errors occur at one
location and propagate throughout a
system 23
 Refinement
• Refinement is actually a process of elaboration
• You 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
indication of the internal workings of the function or the internal structure of the
information
• You then elaborate on the original statement, providing more and more detail as each
successive refinement (elaboration) occurs
Abstraction and refinement are complementary concepts
Abstraction enables you to specify procedure and data internally but suppress the
need for “outsiders” to have knowledge of low-level details
Refinement helps you to reveal low-level details as design progresses. Both
concepts allow you to create a complete design model as the design evolves
24
 Aspects
• As requirements analysis occurs, a set of “concerns” is uncovered
• These concerns “include requirements, use cases, features, data
structures, quality of service issues, variants, intellectual property
boundaries, collaborations, patterns and contracts”
• A crosscutting concern is some characteristic of the system that
applies across many different requirements
• An aspect is a representation of a crosscutting concern
• In an ideal context, an aspect is implemented as a separate module
(component) rather than as software fragments that are “scattered”
or “tangled” throughout many components
25
 Discussion

Identify a few aspects of your project

26
 Refactoring
• Refactoring is the process of changing a software system in such a way that
it does not alter the external behavior of the code [design] yet improves its
internal structure
• When software is refactored, the existing design is examined for
redundancy, unused design elements, inefficient or unnecessary algorithms,
poorly constructed or inappropriate data structures, or any other design
failure that can be corrected to yield a better design
• Although the intent of refactoring is to modify the code in a manner that does
not alter its external behavior, inadvertent side effects can and do occur
• As a consequence, refactoring tools are used to analyze changes
automatically and to “generate a test suite suitable for detecting behavioral
changes.”
27
 Object Oriented Design Concepts
• The object-oriented (OO) paradigm is widely used in
modern software engineering
• Classes and objects, inheritance, messages, and
polymorphism, among others

28
 Design Classes – Five Types
• define all abstractions that are necessary for human-computer interaction (HCI) and
User interface classes often implement the HCI in the context of a metaphor

Business domain • identify the attributes and services (methods) that are required to implement some
element of the business domain that was defined by one or more analysis classes
classes
• implement lower-level business abstractions required to fully manage the business
Process classes domain classes

• represent data stores (e.g., a database) that will persist beyond the execution of the
Persistent classes software

• implement software management and control functions that enable the system to
System classes operate and communicate within its computing environment and with the outside
world

29
 Dependency Inversion
• High-level modules (classes) should not depend [directly]
upon low-level modules
• Both should depend on abstractions
• Abstractions should not depend on details
• Details should depend on abstractions

30
 Design for Test
• There is an ongoing chicken-and-egg debate about
whether software design or test case design (TDD)
should come first
• You need to provide appropriate test affordances—
factoring your design in a way that lets test code
interrogate and control the running system

31
 Design Concepts - Summary

Separation of
Abstraction Architecture Patterns Modularity
concerns

Information Functional
Refinement Aspects Refactoring
Hiding Independence

Object Oriented
Dependency
Design Design Classes Design for Test
Inversion
Concepts

32
 Discussion

Suggest a design pattern that you encounter in a category of

everyday things (e.g., consumer electronics, automobiles,
appliances). Briefly describe the pattern.

33
 Software Architecture
• The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components,
and the relationships among them
• The architecture is not the operational software. Rather, it is a
representation that enables you to
– analyze the effectiveness of the design in meeting its stated requirements,
– consider architectural alternatives at a stage when making design changes
is still relatively easy, and
– reduce the risks associated with the construction of the software

34
 Why is architecture important?

Software architecture provides a representation that facilitates

communication among all stakeholders

The architecture highlights early design decisions that will have a

profound impact on all software engineering work that follows

Architecture “constitutes a relatively small, intellectually graspable

model of how the system is structured and how its components work
together

35
 Architectural Descriptions
• An architectural description is actually a set of work products that reflect
different views of the system
– The blueprint metaphor - Developers regard architecture descriptions as a means of
transferring explicit information from architects to designers to software engineers
charged with producing the system components
– The language metaphor views architecture as a facilitator of communication across
stakeholder groups. This view is preferred by stakeholders with a high customer focus
– The decision metaphor represents architecture as the product of decisions involving
trade-offs among properties such as cost, usability, maintainability, and performance
– The literature metaphor is used to document architectural solutions constructed in the
past. This view supports the construction of artifacts and the transfer of knowledge
between designers and software maintenance staff

36
Architectural Decisions

37
 Architectural Style
Each style describes a system category that encompasses

1. A set of components (e.g., a database, computational

modules) that perform a function required by a system,
2. A set of connectors that enable “communication,
coordination and cooperation” among components,
3. Constraints that define how components can be
integrated to form the system, and
4. Semantic models that enable a designer to understand
the overall properties of a system by analyzing the known
properties of its constituent parts
38
A Brief Taxonomy of Architectural Styles

Data- Call-and-
Data-Flow
centered Return
Architecture
Architecture Architecture

Object-
Layered
Oriented
Architecture
Architecture
39
 Data-Centered Architecture
• A data store (e.g., a
fi le or database)
resides at the center
of this architecture
and is accessed
frequently by other
components that
update, add, delete,
or otherwise modify
data within the store

40
 Data-Flow Architectures
• This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into
output data
• A pipe-and-filter pattern has a set of components, called filters,
connected by pipes that transmit data from one component to the next

41
 Call and Return Architectures
• Main program/subprogram architectures

42
 Object-Oriented Architectures
• The components of a system encapsulate data and the
operations that must be applied to manipulate the data
• Communication and coordination between components
are accomplished via message passing

43
 Layered Architectures
• A number of different layers are
defined, each accomplishing operations
that progressively become closer to the
machine instruction set
• At the outer layer, components service
user interface operations. At the inner
layer, components perform operating
system interfacing
• Intermediate layers provide utility
services and application software
functions
44
 Question?

Present two or three examples of applications for each of the architectural styles

45
 Architectural Design
• As architectural design begins, context must be established
• To accomplish this, the external entities (e.g., other systems,
devices, people) that interact with the software and the
nature of their interaction are described
• This information can generally be acquired from the
requirements model
• Once context is modeled and all external software interfaces
have been described, you can identify a set of architectural
archetypes
46
 Architectural Design
• An archetype is an abstraction (similar to a class) that represents
one element of system behavior
• The set of archetypes provides a collection of abstractions that must
be modeled architecturally if the system is to be constructed, but the
archetypes themselves do not provide enough implementation detail
• Therefore, the designer specifies the structure of the system by
defining and refining software components that implement each
archetype
• This process continues iteratively until a complete architectural
structure has been derived
47
 Representing the System in Context

• At the architectural design level,

a software architect uses an
architectural context diagram
(ACD) to model the manner in
which software interacts with
entities external to its
boundaries

48
 Representing the System in Context
• Superordinate systems —those
systems that use the target system as
part of some higher-level processing
scheme
• Subordinate systems —those systems
that are used by the target system and
provide data or processing that are
necessary to complete target system
functionality
• Peer-level systems —those systems
that interact on a peer-to-peer basis
• Actors —entities (people, devices) that
interact with the target system by
producing or consuming information
that is necessary for requisite
49
processing
Architectural context diagram for the SafeHome
security function

50
 Defining Archetypes
• An archetype is a class or
pattern that represents a
core abstraction that is
critical to the design of an
architecture for the target
system
• In general, a relatively
small set of archetypes is
required to design even
relatively complex UML relationships for SafeHome security function
systems archetypes

51
 Refining the architecture into components
• As the software architecture is refined into components,
the structure of the system begins to emerge
• The interfaces depicted in the architecture context
diagram imply one or more specialized components that
process the data that flows across the interface
• In some cases (e.g., a graphical user interface), a
complete subsystem architecture with many components
must be designed

52
 Refining the architecture into components
SafeHome example
• External communication management —coordinates
communication of the security function with external entities
such as other Internet-based systems and external alarm
notification
• Control panel processing —manages all control panel
functionality
• Detector management —coordinates access to all detectors
attached to the system
• Alarm processing —verifies and acts on all alarm conditions
53
Overall architectural structure for SafeHome with
top-level components

54
Describing Instantiations of the System
• The architectural design that has been modeled to this
point is still relatively high level
• For further refinement, an actual instantiation of the
architecture is developed
• By this we mean that the architecture is applied to a
specific problem with the intent of demonstrating that the
structure and components are appropriate

55
An instantiation of the security function with
component elaboration

56
 Summary
• Software design commences as the first iteration of requirements
engineering comes to a conclusion
• The intent of software design is to apply a set of principles, concepts,
and practices that lead to the development of a high-quality system or
product
• The goal of design is to create a model of software that will implement
all customer requirements correctly and bring delight to those who use
it
• Software designers must sift through many design alternatives and
converge on a solution that best suits the needs of project stakeholders

57
 Summary: Design concepts emphasize…
• The need for abstraction as a mechanism for creating reusable software components
• The importance of architecture as a way to better understand the overall structure of a system
• The benefits of pattern-based engineering as a technique for designing software with proven
capabilities
• The value of separation of concerns and effective modularity as a way to make software more
understandable, more testable, and more maintainable
• The consequences of information hiding as a mechanism for reducing the propagation of side
effects when errors do occur
• The impact of functional independence as a criterion for building effective modules
• The use of refinement as a design mechanism a consideration of aspects that crosscut system
requirements
• The application of refactoring for optimizing the design that is derived
• The importance of object-oriented classes and the characteristics that are related to them
• The need to use abstraction to reduce coupling between components, and
• The importance of design for testing
58
 Summary
• In a general sense, architectural design is accomplished using four distinct steps
• First, the system must be represented in context
– That is, the designer should define the external entities that the software interacts with and
the nature of the interaction
• Once context has been specified, the designer should identify a set of top-level
abstractions, called archetypes, that represent pivotal elements of the system’s
behavior or function
• After abstractions have been defined, the design begins to move closer to the
implementation domain
• Components are identified and represented within the context of an architecture
that supports them
• Finally, specific instantiations of the architecture are developed to “prove” the
design in a real-world context
59