Software Engineering

SEMTZC344 – CS8
BITS Pilani Dr. Rama Satish K V
Pilani|Dubai|Goa|Hyderabad
Guest Faculty, WILP- BITS, Pilani
1
 BITS Pilani
Pilani|Dubai|Goa|Hyderabad

SEMTZC344 – CS#8
Software Design Concepts
2
 3

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

• The slides presented here are obtained from the authors of the
books and from various other contributors. I hereby
acknowledge all the contributors for their material and inputs.
• I have added and modified a few slides to suit the requirements
of the course. 4

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Agenda for CS #8

1) Review CS#7
– Project Metrics
– Estimation techniques
– Project Scheduling
2) Software Design Concepts
3) Patterns
4) Cohesion, Coupling
5) Q&A

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Purpose of Design

➢ Design is where customer requirements, business needs, and

technical considerations all come together in the formulation of a
product or system
➢ The design model provides detail about the software data structures,
architecture, interfaces, and components
➢ The design model can be assessed for quality and be improved
before code is generated and tests are conducted
➢ Does the design contain errors, inconsistencies, or omissions?
➢ Are there better design alternatives?
➢ Can the design be implemented within the constraints, schedule,
and cost that have been established?
6

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 How to Design

➢ A designer must practice diversification and convergence-[Belady]

➢ The designer selects from design components, component solutions, and
knowledge available through catalogs, textbooks, and experience
➢ The designer then chooses the elements from this collection that meet the
requirements defined by requirements engineering and analysis modeling
➢ Convergence occurs as alternatives are considered and rejected until one particular
configuration of components is chosen
➢ Software design is an iterative process through which requirements are translated
into a blueprint for constructing the software
➢ Design begins at a high level of abstraction that can be directly traced back to the
data, functional, and behavioral requirements
➢ As design iteration occurs, subsequent refinement leads to design representations
at much lower levels of abstraction

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 How to Design

➢ Design is an intellectually challenging task

➢ Numerous possibilities the system must accommodate
➢ Nonfunctional design goals (e.g., ease of use, ease to maintain)
➢ External factors (e.g., standard data formats, government
regulations)

➢ We can improve our design by studying examples of good design.

Many ways to leverage existing solutions
➢ Cloning: Borrow design/code in its entirety, with minor adjustments
➢ Reference models: Generic architecture that suggests how to
decompose the system
8

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 The Design Process

Design is creative, but so many things influence it

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Analysis Model to Design

➢ Each element of the analysis model provides information that is

necessary to create the four design models
➢ The data/class design transforms analysis classes into design classes
along with the data structures required to implement the software
➢ The architectural design defines the relationship between major
structural elements of the software; architectural styles and design
patterns help achieve the requirements defined for the system
➢ The interface design describes how the software communicates with
systems that interoperate with it and with humans that use it
➢ The component-level design transforms structural elements of the
software architecture into a procedural description of software
components
10

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Analysis → Design

11

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Wisdom of Design

➢ "Questions about whether design is necessary or affordable are quite beside

the point; design is inevitable. The alternative to good design is bad design,
[rather than] no design at all." Douglas Martin (Author)
➢ "You can use an eraser on the drafting table or a sledge hammer on the
construction site." Frank Lloyd Wright (Architect, Structural Designer)
➢ "The public is more familiar with bad design than good design. If is, in effect,
conditioned to prefer bad design, because that is what it lives with; the new
[design] becomes threatening, the old reassuring." Paul Rand (Graphic
Designer)
➢ "Every now and then go away, have a little relaxation, for when you come
back to your work your judgment will be surer. Go some distance away
because then the work appears smaller and more of it can be taken in at a
glance and a lack of harmony and proportion is more readily seen." Leonardo
DaVinci(Genius)
12

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Software Design Manifesto

➢ Mitch Kapor, the creator of Lotus 1-2-3, presented a “software

design manifesto” in Dr. Dobbs Journal. He applied ideas of Roman
architecture critic Vitruvius over software design. According to him,
good software design should exhibit:
➢ Firmness: A program should not have any bugs that inhibit its
function.
➢ Commodity: A program should be suitable for the purposes for
which it was intended.
➢ Delight: The experience of using the program should be pleasurable
one.

13

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Task Set for Software Design

1)Examine the information domain model and design appropriate data

structures for data objects and their attributes
2)Using the analysis model, select an architectural style (and design
patterns) that are appropriate for the software
3)Partition the analysis model into design subsystems and allocate
these subsystems within the architecture
– a)Design the subsystem interfaces
– b)Allocate analysis classes or functions to each subsystem
4)Create a set of design classes or components
– a)Translate each analysis class description into a design class
– b)Check each design class against design criteria; consider inheritance issues
– c)Define methods associated with each design class
– d)Evaluate and select design patterns for a design class or subsystem 14

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Task Set for Software Design

5)Design any interface required with external systems or devices

6)Design the user interface
7)Conduct component-level design
– a)Specify all algorithms at a relatively low level of abstraction
– b)Refine the interface of each component
– c)Define component-level data structures
– d)Review each component and correct all errors uncovered
8)Develop a deployment model
- Show a physical layout of the system, revealing which components
will be located where in the physical computing environment

15

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Fundamental Design Concepts

➢ Abstraction—data, procedure, control

➢ Architecture—the overall structure of the software
➢ Patterns—‖conveys the essence‖ of a proven design solution
➢ Separation of concerns—any complex problem can be more easily handled if it is
subdivided into pieces
➢ Modularity—compartmentalization of data and function
➢ Information Hiding—controlled interfaces
➢ Functional independence—single-minded function and low coupling
➢ Refinement—elaboration of detail for all abstractions
➢ Aspects—a mechanism for understanding how global requirements affect design
➢ Refactoring—a reorganization technique that simplifies the design
The beginning of wisdom (for a software engineer) is to recognize the difference
between getting program to work, and getting it right
16

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Abstraction

Abstraction
–process –extracting essential details
–entity –a model or focused representation
Enablers:
Information hiding
–the suppression of inessential information
Encapsulation
–process –enclosing items in a container
–entity –enclosure that holds the items
17

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Data Abstraction

18

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Procedural Abstraction

19

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Software Architecture

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

The architectural model is derived from three sources:

–information about the application domain for the software to be built;
–specific requirements model elements such as data flow diagrams or
analysis classes, their relationships and collaborations for the
problem at hand, and
–the availability of architectural patterns and styles.

20

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Architectural Specifications

➢ 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. 21

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Patterns

➢ An architectural pattern expresses a fundamental structural

organization schema for software systems. It provides a set of
predefined subsystems, specifies their responsibilities, and includes
rules and guidelines for organizing the relationships between them.
➢ A design pattern provides a scheme for refining the subsystems or
components of a software system, or the relationships between
them. It describes a commonly-recurring structure of
communicating components that solves a general design problem
within a particular context.
➢ An idiom is a low-level pattern specific to a programming language.
An idiom describes how to implement particular aspects of
components or the relationships between them using the features of
the given language. 22

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Design Patterns

➢ The best designers in any field have an uncanny ability to see

patterns that characterize a problem and corresponding patterns that
can be combined to create a solution
➢ A description of a design pattern may also consider a set of design
forces.
➢ Design forces describe non-functional requirements (e.g., ease of
maintainability, portability) associated the software for which the
pattern is to be applied.
➢ The pattern characteristics (classes, responsibilities, and
collaborations) indicate the attributes of the design that may be
adjusted to enable the pattern to accommodate a variety of
problems.
23

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Pattern Template

Design Pattern Template

Pattern name —describes the essence of the pattern in a short but expressive name
Intent —describes the pattern and what it does
Also-known-as —lists any synonyms for the pattern
Motivation —provides an example of the problem
Applicability —notes specific design situations in which the pattern is applicable
Structure —describes the classes that are required to implement the pattern
Participants —describes the responsibilities of the classes that are required to
implement the pattern
Collaborations —describes how the participants collaborate to carry out their
responsibilities
Consequences —describes the ―design forces‖ that affect the pattern and the
potential trade-offs that must be considered when the pattern is implemented
Related patterns —cross-references related design patterns 24

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

The Observer Pattern

25

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Multiple displays using the Observer
Pattern

26

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 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.

27

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Modularity

➢ "modularity is the single attribute of software that allows a program

to be intellectually manageable" –Glen Myers
➢ 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.

28

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Modularity: Trade-Offs

29

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Information Hiding

30

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

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
➢ results in higher quality software

31

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Functional Independence

➢ Functional independence is achieved by developing modules with

"single-minded" function and an "aversion" to excessive interaction
with other modules.
➢ Cohesion is an indication of the relative functional strength of a
module.
➢ –A cohesive module performs a single task, requiring little
interaction with other components in other parts of a program. Stated
simply, a cohesive module should (ideally) do just one thing.
➢ Coupling is an indication of the relative interdependence among
modules.
➢ –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. 32

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Functional Independence

33

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Refactoring

Fowler [FOW99] 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.”

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.

34

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 To Summarize

➢ A software design creates meaningful engineering representation (or model) of

some software product that is to be built.
➢ Designers must strive to acquire a repertoire of alternative design information and
learn to choose the elements that best match the analysis model.
➢ A design model can be traced to the customer's requirements and can be assessed
for quality against predefined criteria. During the design process the software
requirements model (data, function, behavior) is transformed into design models
that describe the details of the data structures, system architecture, interfaces, and
components necessary to implement the system.
➢ Each design product is reviewed for quality
➢ identify and correct errors, inconsistencies, or omissions,
➢ whether better alternatives exist, and
➢ whether the design model can be implemented within the project constraints

35

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

We will explore more on Architectural Design in the next class …

36

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Thank You for your
time & attention !
Contact : satishkvr@[Link]

Slides are Licensed Under : CC BY-NC-SA 4.0 37

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956