Software Engineering

Unit – III

Software Design

Dr. S. Manikandan
HOD-IT

1
 1. Design Process

• Software Design is the process to transform the user

requirements into some suitable form, which helps the
programmer in software coding and implementation.
• During the software design phase, the design document is
produced, based on the customer requirements as
documented in the SRS document.
• Software design is an iterative process through which
requirements are translated into the blueprint for building the
software.

2
The following items are designed and documented
during the design phase:
• Different modules required.
• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the
individual modules.

3
 1.1 Characteristics for the evaluation 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 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.

4
 1.2 Software quality guidelines

1. A design is generated using the recognizable architectural

styles and compose a good design characteristic of
components and it is implemented in evolutionary manner
for testing.
2. A design of the software must be modular i.e the software
must be logically partitioned into elements.
3. In design, the representation of data , architecture, interface
and components should be distinct.
4. A design must carry appropriate data structure and
recognizable data patterns.

5
5. Design components must show the independent
functional characteristic.
6. A design creates an interface that reduce the
complexity of connections between the components.
7. A design must be derived using the repeatable
method.
8. The notations should be use in design which can
effectively communicates its meaning.

6
 1.3 Quality Attributes

The attributes of design name as 'FURPS' are as follows:

• Functionality: It evaluates the feature set and
capabilities of the program.
• Usability: It is accessed by considering the factors
such as human factor, overall aesthetics, consistency
and documentation.
• Reliability: It is evaluated by measuring parameters like
frequency and security of failure, output result
accuracy, the mean-time-to-failure(MTTF), recovery
from failure and the program predictability.
• Performance: It is measured by considering processing
speed, response time, resource consumption,
throughput and efficiency

7
• Supportability:
– It combines the ability to extend the program, adaptability,
serviceability. These three term defines the maintainability.
– Testability, compatibility and configurability are the terms using
which a system can be easily installed and found the problem
easily.

8
2. Design Concepts

9
• Abstraction- hide Irrelevant data
• Modularity- subdivide the system
• Architecture- design a structure of something
• Refinement- removes impurities
• Pattern- a repeated form
• Information Hiding- hide the information
• Refactoring- reconstruct something
• Functional Independence- Cohesion, Coupling

10
 2.1 Abstraction
• Abstraction is the act of representing essential features
without including the background details or explanations.
• Abstraction is used to reduce complexity and allow efficient
design and implementation of complex software systems.
• Many levels of abstraction can be posed. At the highest
level of abstraction, a solution is stated in broad terms
using the language of the problem environment. At lower
levels of abstraction, a more detailed description of the
solution is provided.
• A procedural abstraction refers to a sequence of
instructions that have a specific and limited function.
• A data abstraction is a named collection of data that
describes a data object.

11
 2.2 Modularity

• Modularity is the most common manifestation of

separation of concerns.
• Software is divided into separately named and
addressable components, sometimes called module.
• Modularity is the single attribute of software that allows
a program to be intellectually manageable

12
Modularity and Software Cost Graph

13
 2.3 Information Hiding

The principle of information hiding suggests that modules

be “characterized by design decisions that hides from
all others.”
In other words, modules should be specified and
designed so that information contained within a module
is inaccessible to other modules that have no need for
such information.

14
 2.4 Functional Independence

• The concept of functional independence is a direct

outgrowth of separation of concerns, modularity, and
the concepts of abstraction and information hiding.
• Functional independence is achieved by developing
modules with “single minded” function and an
“aversion” to excessive interaction with other modules.
• Independence is assessed using two qualitative
criteria: cohesion and coupling.
• Cohesion is an indication of the relative functional
strength of a module.
• Coupling is an indication of the relative
interdependence among modules.

15
 2.5 Refinement

• Stepwise refinement is a top-down design strategy

originally proposed by Niklaus Wirth. Refinement is
actually a process of elaboration.
• You begin with a statement of function that is defined
at a high level of abstraction.
• 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.

16
 2.6 Refactoring

• An important design activity suggested for many agile

methods, refactoring is a reorganization technique that
simplifies the design (or code) of a component without
changing its function or behavior.
• Fowler defines refactoring in the following manner:
“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.”

17
 2.7 Architecture

• Software architecture alludes to “the overall structure of

the software and the ways in which that structure
provides conceptual integrity for a system”
• Architecture is the 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

18
 2.8 Pattern

• 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

19
3. Design Model

20
 Elements of Design Model

1. Data design elements

• The data design element produced a model of data
that represent a high level of abstraction.
• This model is then more refined into more
implementation specific representation which is
processed by the computer based system.
• The structure of data is the most important part of the
software design.

21
2. Architectural design elements
• The architecture design elements provides us overall
view of the system.
• The architectural design element is generally
represented as a set of interconnected subsystem that
are derived from analysis packages in the requirement
model.
The architecture model is derived from following sources:
• The information about the application domain to built
the software.
• Requirement model elements like data flow diagram or
analysis classes, relationship and collaboration
between them.
• The architectural style and pattern as per availability. 22
3. Interface design elements
• The interface design elements for software represents
the information flow within it and out of the system.
• They communicate between the components defined
as part of architecture.
Following are the important elements of the interface
design:
1. The user interface
2. The external interface to the other systems,
networks etc.
3. The internal interface between various components.

23
4. Component level diagram elements
• The component level design for software is similar to the set
of detailed specification of each room in a house.
• The component level design for the software completely
describes the internal details of the each software
component.
• The processing of data structure occurs in a component and
an interface which allows all the component operations.
• In a context of object-oriented software engineering, a
component shown in a UML diagram.
• The UML diagram is used to represent the processing logic.

24
5. Deployment level design elements
• The deployment level design element shows the
software functionality and subsystem that allocated in
the physical computing environment which support the
software.
• Following figure shows three computing environment
as shown. These are the personal computer, the CPI
server and the Control panel.

25
26
 4. Architectural Design

Architectural design is defined as the process of defining a

collection of hardware and software components and
their interfaces to establish the framework for the
development of a computer system.

27
28
Architectural Context diagram for the Safe Home
security function

29
• 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

30
Overall architectural structure for Safe Home
with top-level components

31
32
 5. User Interface Design Elements

User interface is the front-end application view to which

user interacts in order to use the software.
The software becomes more popular if its user interface
is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interface screens

33
There are two types of User Interface:
• Command Line Interface: Command Line Interface
provides a command prompt, where the user types the
command and feeds to the system. The user needs to
remember the syntax of the command and its use.
• Graphical User Interface: Graphical User Interface
provides the simple interactive interface to interact with
the system. GUI can be a combination of both
hardware and software. Using GUI, user interprets the
software.

34
 5.1 Golden Rules
The following are the golden rules stated by Theo Mandel that
must be followed during the design of the interface.
Place the user in control:
• Define the interaction modes in such a way that does not
force the user into unnecessary or undesired actions
• Provide for flexible interaction
• Allow user interaction to be interruptable and undoable:
• Streamline interaction as skill level advances and allow the
interaction to be customized
• Hide technical internals from casual users
• Design for direct interaction with objects that appear on
screen:

35
Reduce the user’s memory load:
• Reduce demand on short-term memory
• Establish meaningful defaults
• Define shortcuts that are intuitive:
• The visual layout of the interface should be based on
a real-world metaphor:.
• Disclose information in a progressive fashion:

36
Make the interface consistent:
• Allow the user to put the current task into a
meaningful context
• Maintain consistency across a family of applications:
• If past interactive models have created user
expectations do not make changes unless there is a
compelling reason.

37
 User Interface Analysis

User interface analysis elements include

(1) User analysis - The goal of the user analysis to
understand the users and their use.
(2) Task analysis and modeling - The goal of task analysis is
to answer the following questions: – What work will the user
perform in specific circumstances? - What tasks and
subtasks will be performed as the user does the work?
(3) Analysis of display content - Display content can range
from reports, graphical displays or specialized information.
(4) Analysis of the work environment - The user interface for
a computer-based system, but in others, noise may be a
factor, a keyboard or mouse may not be an option. The
interface designer may consider these factors.

38
5.2 User Interface Design Process

39
• Interface analysis focuses on the profile of the users who
will interact with the system. – A more detailed task analysis
is conducted. – Analysis of the user environment focuses on
the physical work environment. Eg. Where will the interface
be located physically? Will the user be sitting, standing, or
performing other tasks unrelated to the interface?
• Interface design defines a set of interface objects and
actions (and their screen representations) to perform all
defined tasks to meet every usability goal defined for the
system.

40
• Interface construction evaluates usage scenarios by
creating prototype. As the iterative design process
continues, a user interface tool kit may be used to
complete the construction of the interface.
• Interface validation focuses on – User task
correctness – task variations – Cover user requirement
– Ease of use – Easy to learn – the users’ acceptance

41
 6. Component level design

• Component level design is the definition and design

of components and modules after the architectural
design phase.
• Component-level design defines the data structures,
algorithms, interface characteristics, and
communication mechanisms allocated to each
component for the system development.

42
Component Views
• OO View – A component is a set of collaborating
classes.
• Traditional View – A component is a functional
element of a program that incorporates processing
logic, the internal data structures required to implement
the processing logic, and an interface that enables the
component to be invoked and data to be passed to it.

43
Elaboration of a design component – OO View

44
Structure Chart for a traditional system

45
 Designing Class based components

• Basic Design Principles

• Coupling
• Cohesion

46
 Basic Design Principles applicable to
component level design
• The Open-Closed Principle (OCP). “A module
[component] should be open for extension but closed for
modification.
• Design should specify the component in a way that allows
it to be extended (within the functional domain that it
addresses) without the need to make internal (code or
logic-level) modifications to the component itself.
• The Liskov Substitution Principle (LSP). “Subclasses
should be substitutable for their base classes.
• A component that contains the base class and if that
component works properly then the same component
should work properly even if the derived class of that base
class is used by the component as a substitute.

47
• Dependency Inversion Principle (DIP). “Depend on
abstractions. Do not depend on concretions.”
• This is because of some component has to be
extended then it becomes easy to enhance it using
other abstract component instead of concrete
component.
• The Interface Segregation (Separation) Principle
(ISP). “Many client-specific interfaces are better than
one general purpose interface.
• According to this principle, designer should create
specialized interfaces for each major category.

48
Coupling

49
1. No Direct Coupling: There is no direct coupling between
M1 and M2.

2. Data Coupling
When data of one module is passed
to another module, this is called
data coupling.

50
• 3. Stamp Coupling: Two modules are stamp coupled if
they communicate using composite data items such as
structure, objects, etc. When the module passes non-
global data structure or entire structure to another module,
they are said to be stamp coupled. For example, passing
structure variable in C or object in C++ language to a
module.
• 4. Control Coupling: Control Coupling exists among two
modules if data from one module is used to direct the
structure of instruction execution in another.
• 5. External Coupling: External Coupling arises when two
modules share an externally imposed data format,
communication protocols, or device interface. This is
related to communication to external tools and devices.
51
• 6. Common Coupling: Two modules are common
coupled if they share information through some global
data items.

• 7. Content Coupling: Content Coupling exists among

two modules if they share code, e.g., a branch from
one module into another module.

52
 Cohesion
• Cohesion measures the strength of relationships
between pieces of functionality within a given module.
Types of Cohesion
• Functional Cohesion: Functional Cohesion is said to
exist if the different elements of a module, cooperate to
achieve a single function.
• Sequential Cohesion: A module is said to possess
sequential cohesion if the element of a module form the
components of the sequence, where the output from one
component of the sequence is input to the next.
• Communicational Cohesion: A module is said to have
communicational cohesion, if all tasks of the module
refer to or update the same data structure, e.g., the set
of functions defined on an array or a stack.
53
• Procedural Cohesion: A module is said to be procedural
cohesion if the set of purpose of the module are all parts of a
procedure in which particular sequence of steps has to be
carried out for achieving a goal, e.g., the algorithm for
decoding a message.
• Temporal Cohesion: When a module includes functions that
are associated by the fact that all the methods must be
executed in the same time, the module is said to exhibit
temporal cohesion.
• Logical Cohesion: A module is said to be logically cohesive if
all the elements of the module perform a similar operation. For
example Error handling, data input and data output, etc.
• Coincidental Cohesion: A module is said to have coincidental
cohesion if it performs a set of tasks that are associated with
each other very loosely, if at all.
54
 Component-Level Design Steps

• Step 1.Identify design classes in problem domain

• Step 2.Identify infrastructure design classes
• These classes are usually not present in the analysis
or architectural models
• These classes include GUI components, operating
system components, data management
components, networking components, etc.
• Step 3 – Class Elaboration
• Elaborate design classes
• Identify appropriate interfaces for each component and
elaborate attributes
• Step 4 – Storage
• Describe persistent data sources
55
• Step 5 – Elaborate Behavior
• Elaborate behavioral representations
• Step 6 – Elaborate deployment diagrams
• Step 7 – Redesign/Reconsider
• The first component-level model you create will not
be as complete, consistent, or accurate as
the nth iteration you apply to the model.
• The best designers will consider many alternative
design solutions before settling on the final
design model

56
 Pattern based design

Design patterns are typical solutions to common

problems in software design. Each pattern is like a
blueprint that you can customize to solve a particular
design problem in your code.
Design patterns are used to represent some of the best
practices adapted by experienced object-oriented
software developers.
A design pattern systematically names, motivates, and
explains a general design that addresses a recurring
design problem in object-oriented systems.
It describes the problem, the solution, when to apply the
solution, and its consequences. It also gives
implementation hints and examples.

57
 Kinds of Patterns

• Architectural patterns describe broad-based design

problems that are solved using a structural approach.
• Data patterns describe recurring data-oriented
problems and the data modeling solutions that can be
used to solve them.
• Component patterns (also referred to as design
patterns) address problems associated with the
development of subsystems and components, the
manner in which they communicate with one another,
and their placement within a larger architecture

58
• Interface design patterns describe common user interface
problems and their solution with a system of forces that
includes the specific characteristics of end-users.
• WebApp patterns address a problem set that is encountered
when building WebApps and often incorporates many of the
other patterns categories just mentioned.
• Creational patterns focus on the “creation, composition,
and representation of objects, e.g.,
– Abstract factory pattern: centralize decision of what
factory to instantiate
– Factory method pattern: centralize creation of an object
of a specific type choosing one of several
implementations
59
• Structural patterns focus on problems and solutions
associated with how classes and objects are organized and
integrated to build a larger structure, e.g.,
– Adapter pattern: 'adapts' one interface for a class into one
that a client expects
– Aggregate pattern: a version of the Composite pattern with
methods for aggregation of children
• Behavioral patterns address problems associated with the
assignment of responsibility between objects and the manner
in which communication is effected between objects, e.g.,
– Chain of responsibility pattern: Command objects are
handled or passed on to other objects by logic-containing
processing objects
– Command pattern: Command objects encapsulate an
action and its parameters 60
 Framworks

• Patterns themselves may not be sufficient to develop a

complete design. In some cases it may be necessary to
provide an implementation-specific skeletal
infrastructure, called a framework, for design work.

61
 Describing a Pattern

• Pattern name: describes the essence of the pattern in

a short but expressive name
• Problem : describes the problem that the pattern
addresses
• Motivation : provides an example of the problem
• Context : describes the environment in which the
problem resides including application domain
• Forces : lists the system of forces that affect the
manner in which the problem must be solved; includes
a discussion of limitation and constraints that must be
considered

62
• Solution : provides a detailed description of the solution
proposed for the problem
• Intent : describes the pattern and what it does
• Collaborations : describes how other patterns contribute
to the solution
• Consequences : describes the potential trade-offs that
must be considered when the pattern is implemented and
the consequences of using the pattern
• Implementation : identifies special issues that should be
considered when implementing the pattern
• Known uses : provides examples of actual uses of the
design pattern in real applications
• Related patterns : cross-references related design
patterns
63
 Pattern based design in context
Pattern based Software Design

64
 Thinking in Patterns
Shalloway and Trott [Sha05] suggest the following approach
that enables a designer to think in patterns:
• Be sure you understand the big picture—the context in which
the software to be built resides. The requirements model
should communicate this to you.
• Examining the big picture, extract the patterns that are present
at that level of abstraction.
• Begin your design with ‘big picture’ patterns that establish a
context or skeleton for further design work.
• “Work inward from the context” [Sha05] looking for patterns at
lower levels of abstraction that contribute to the design
solution.
• Repeat steps 1 to 4 until the complete design is fleshed out.
• Refine the design by adapting each pattern to the specifics of
the software you’re trying to build. 65
 Design Tasks

• Examine the requirements model and develop a

problem hierarchy.
• Determine if a reliable pattern language has been
developed for the problem domain.
• Beginning with a broad problem, determine whether
one or more architectural patterns are available for it.
• Using the collaborations provided for the architectural
pattern, examine subsystem or component level
problems and search for appropriate patterns to
address them.
• Repeat steps 2 through 5 until all broad problems have
been addressed.

66
 Common design mistakes

• A number of common mistakes occur when pattern-

based design is used. In some cases, not enough time
has been spent to understand the underlying problem
and its context and forces, and as a consequence, you
select a pattern that looks right but is inappropriate for
the solution required. Once the wrong pattern is
selected, you refuse to see your error and force-fit the
pattern.

67