Module III - Software Design Conepts

1
 Design
Design creates a representation or model of the
software, but unlike the requirements model
(that focuses on describing required data,
function, and behavior), the design model
provides detail about
– software architecture,
– data structures,
– interfaces, and
– components
that are necessary to implement the system.

2
 Design
• Design allows you to model the system or product
that is to be built
• Design is the place where software quality is
established.
• The quality of the design is assessed with a series of
technical reviews

work product:
A design model that encompasses architectural,
interface, component level, and deployment
representations is the primary work product that is
produced during software design.
3
 Requirements Model -> Design Model

Co m p o n e n t -
sc e n a r i o - b a se d f l o w- o r i e n t e d L e v e l D e sig n
e l e me nt s e l e me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
In t e r f a c e D e sig n
Analysis Model

A r c h it e c t u r a l D e sig n
c l a ss- b a se d be ha v i or a l
e l e me nt s e l e me nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cla ss D e sig n
collaboration diagrams

Design Model

4
 Design Principles
• The design process should not suffer from ‘tunnel vision.’
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should “minimize the intellectual distance” between
the software and the problem as it exists in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• 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.
• The design should be assessed for quality as it is being created,
not after the fact.
• The design should be reviewed to minimize conceptual (semantic)
errors.
8
Design Concepts
1. Abstraction—data, procedure, control
2. Architecture—the overall structure of the software
3. Patterns—”conveys the essence” of a proven design solution
4. Separation of concerns—any complex problem can be more easily
handled if it is subdivided into pieces
5. Modularity—compartmentalization of data and function
6. Hiding—controlled interfaces
7. Functional independence—single-minded function and low coupling
8. Refinement—elaboration of detail for all abstractions
9. Aspects—a mechanism for understanding how global requirements
affect design
10. Refactoring—a reorganization technique that simplifies the design
11. OO design concepts
12. Design Classes—provide design detail that will enable analysis
classes to be implemented
9
1. Abstraction
Abstraction can be posed at the highest level or lowest
level
door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

procedural abstraction – ‘open’ a door
data abstraction 10
1. Abstraction
• A solution is stated in large terms using the language of the
problem environment at the highest level abstraction.
• The lower level of abstraction provides a more detail
description of the solution.
• A sequence of instruction that contain a specific and limited
function refers in a procedural abstraction.
• A collection of data that describes a data object is a data
abstraction.

11
2. Architecture
“The overall structure of the software and the ways in which
that structure provides conceptual integrity for a system.”

Structural properties. This aspect of the architectural design

representation defines the components of a system (e.g., modules,
objects, filters) and the manner in which those components are packaged
and interact with one another. For example, objects are packaged to
encapsulate both data and the processing that manipulates the data and
interact via the invocation of methods

Extra-functional properties. The architectural design description should

address how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other system
characteristics.

Families of related systems. The architectural design should draw upon

repeatable patterns that are commonly encountered in the design of
families of similar systems. In essence, the design should have the ability
to reuse architectural building blocks.
12
 3. Patterns
A Pattern conveys the essence of a proven solution to a recurring within a
certain context amidst competing concerns

A design pattern describes a design structure and that structure solves a

particular design problem in a specified content.

The intent of each design pattern is to support design engineer to determine:

a. Whether the pattern is applicable to current project
b. Whether the pattern can be reused
c. Whether the pattern can serve as a guide for developing a similar
functionality

13
 4. Separation of Concerns
• 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.

14
 5. Modularity
"modularity is the single attribute of software that allows a
program to be intellectually manageable".

• Monolithic software (i.e., a large program composed of a

single module) cannot be easily grasped by a software
engineer.
– The number of control paths, span of reference, number
of variables, and overall complexity would make
understanding close to impossible.

• In almost all instances, you should break the design into

many modules, hoping to make understanding easier and
as a consequence, reduce the cost required to build the
software.
15
Sizing Modules: Two Views
What's How big
inside?? is it??

MODULE

16
 Modularity: Trade-offs
What is the "right" number of modules for a specific
software design?

module development cost

cost of
software module
integration
cost

optimal number number of modules

of modules

- Under-modularity or over-modularity should be avoided 17

6. Information Hiding
module
• algorithm
controlled
interface • data structure

• details of external interface

• resource allocation policy

clients
"secret"

a specific design decision

18
 Why Information Hiding?
• Reduces the likelihood of “side effects”
• limits the global impact of local design decisions
• emphasizes communication through controlled
interfaces
• discourages the use of global data
• leads to encapsulation—an attribute of high
quality design
• Avoids inadvertent errors introduced during
modification
• results in higher quality software
19
 7. Functional Independence
• Functional independence is achieved by
developing modules with ‘single minded’
function
• It avoids excessive interaction with modules
• Independent modules are easier to develop
and maintain, side-effects reduced, error
propagation is reduced and reusability is
possible

20
 7. Functional Independence
• Functional independence is achieved by two
factors: Cohesion and Coupling
• A cohesive module performs a single task and
it requires a small interaction with the other
components in other parts of the program.
• Coupling is an indication of interconnection
between modules in a structure of software.
• Coupling depends on the interface complexity
between the modules
• Increase the cohesion and decrease the
coupling 21
Coupling vs Cohesion

22
23
8. Stepwise Refinement
open

walk to door;
reach for knob;

open door; repeat until door opens

turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

24
 9. Aspects
• Consider two requirements, A and B.
Requirement A crosscuts requirement B “if
a software decomposition [refinement] has
been chosen in which B cannot be
satisfied without taking A into account.
• An aspect is a representation of a cross-
cutting concern.
• It is important to identify aspects so that
the design can accommodate them
25
 Aspects—An Example
• Consider two requirements for the SafeHomeAssured.com
WebApp. Requirement A is described via the use-case
Access camera surveillance via the Internet. A design
refinement would focus on those modules that would enable a
registered user to access video from cameras placed
throughout a space. Requirement B is a generic security
requirement that states that a registered user must be
validated prior to using SafeHomeAssured.com. This
requirement is applicable for all functions that are available to
registered SafeHome users. As design refinement occurs, A*
is a design representation for requirement A and B* is a
design representation for requirement B. Therefore, A* and B*
are representations of concerns, and B* cross-cuts A*.

• An aspect is a representation of a cross-cutting concern.

Therefore, the design representation, B*, of the requirement,
a registered user must be validated prior to using
SafeHomeAssured.com, is an aspect of the SafeHome
WebApp.
26
10. Refactoring
• 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.”
• It reduces the technical cost and makes the code more
efficient and maintainable.
• 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.
27
OO Design Concepts
• Design classes
– Entity classes
– Boundary classes
– Controller classes
• Inheritance—all responsibilities of a superclass is
immediately inherited by all subclasses
• Messages—stimulate some behavior to occur in
the receiving object
• Polymorphism—a characteristic that greatly
reduces the effort required to extend the design
28
 Design Classes
• Analysis classes are refined during design to become entity
classes
• Entity classes are the fundamental building blocks of systems
• Boundary classes are developed during design to create the
interface (e.g., interactive screen or printed reports) that the
user sees and interacts with as the software is used.
– Boundary classes are designed with the responsibility of
managing the way entity objects are represented to users.
• Controller classes are designed to manage
– the creation or update of entity objects;
– the instantiation of boundary objects as they obtain
information from entity objects;
– complex communication between sets of objects;
– validation of data communicated between objects or
between the user and the application. 29
 REFERENCES
• Roger Pressman, Software Engineering: A
Practitioner’s Approach, 8th Edition,
McGraw-Hill, 2019.
• http://walderson.com/IBM/Practices/Scaling
Agile/core.tech.common.extend_supp-
ibm/guidances/guidelines/finding_analysis_c
lasses_B6C80552.html

30