UNIT-III

Chapter-I

Creating an architectural design

❖Design concepts

❖Software Architecture

❖Data design

❖Architectural styles and patterns

❖Architectural Design

SILPA C 1
 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.

2
 Design Concepts

A set of fundamental software design concepts has evolved over

the history of software engineering.
Each helps you answer the following questions:
1. What criteria can be used to partition software into individual
components?
2. How is function or data structure detail separated from a
conceptual representation of the software?
3. What uniform criteria define the technical quality of a
software design?

SILPA C 3
 Cont..
Design Concepts

1. Abstractions
2. Architecture
3. Patterns
4. Separation of Concerns
5. Modularity
6. Information Hiding
7. Functional Independence
8. Refinement
9. Re-factoring
10. Aspects
11. Design Classes
4
 Design Concepts Cont..

ABSTRACTION

Many levels of abstraction

• Highest level of abstraction : Solution is stated in broad terms

using the language of the problem environment

• Lower levels of abstraction : More detailed description of the

solution is provided

• Procedural abstraction

-- Refers to a sequence of instructions that 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,
5
step away from moving door, etc.)
 Cont..

Data abstraction
-- Named collection of data that describe a data
object
✓ The data abstraction for door would encompass a set of
attributes that describe the door (e.g., door type, swing
direction, opening mechanism, weight, dimensions).

6
 Design Concepts Cont..

ARCHITECTURE

Software 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.

Shaw and Garlan [Sha95a] describe a set of properties that should

be specified as part of an architectural design:
✓ Structural properties: e.g., modules, objects, filters
✓ Extra-functional properties: how the design architecture
achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.
✓ Families of related systems.

7
 Cont..

Architecture Models
(a) Structural Models
-- An organized collection of program components
(b) Framework Models
-- Represents the design in more abstract way
(c) Dynamic Models
-- Represents the behavioral aspects indicating changes as
a function of external events
(d) Process Models
-- Focus on the design of the business or technical process
(e) Functional models
--can be used to represent the functional hierarchy of a
system.

8
 Design Concepts Cont..
PATTERNS
“Each pattern describes a problem which occurs over and over
again in our environment, and then describes the core of the
solution to that problem, in such a way that you can use this
solution a million times over, without ever doing it the same way
twice.” --Christopher Alexander

• Provides a description to enables a designer to determine the

followings :

(a) Whether the pattern is applicable to the current work

(b) Whether the pattern can be reused

(c) Whether the pattern can serve as a guide for developing a

similar but functionally or structurally different pattern
9
 Design Concepts Cont..

Separation of Concerns

• Separation of concerns is a design concept [Dij82] 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.

10
 Design Concepts Cont..

MODULARITY

• Divides software into separately named and addressable components,

sometimes called modules

• Modules are integrated to satisfy problem requirements

• Consider two problems p1 and p2. If the complexity of p1 is cp1 and

of p2 is cp2 then effort to solve p1=cp1 and effort to solve p2=cp2

• If cp1>cp2 then ep1>ep2

• The complexity of two problems when they are combined is often

greater than the sum of the perceived complexity when each is taken
separately

• Based on Divide and Conquer strategy : it is easier to solve a complex

problem when broken into sub-modules
11
 Cont..

Figure: Modularity and software cost

12
 Cont..
Design Concepts

INFORMATION HIDING

• Information contained within a module is inaccessible to other

modules who do not need such information

• Achieved by defining a set of Independent modules that

communicate with one another only that information necessary to
achieve software function

• Provides the greatest benefits when modifications are required

during testing and later

• Errors introduced during modification are less likely to propagate

to other location within the software

13
 Design Concepts Cont..

FUNCTIONAL INDEPENDENCE

• It is achieved by design a software that each module address

a specific sub function of requirements and has a simple
interface when viewed from other parts of program structure
• Why independence is so important?
=> Independent modules are easier to maintain
=> Error propagate is reduced
=> Reusable modules are possible

• Independence is assessed by two quantitative criteria:

Cohesion
-- Performs a single task requiring little interaction with
other components
Coupling
--Measure of interconnection among modules
• Coupling should be low and cohesion should be high for good
design
14
 Cont..
Design Concepts
REFINEMENT & REFACTORING

Refinement
• Process of elaboration from high level abstraction to the
lowest level abstraction.
• High level abstraction begins with a statement of functions.
• Refinement causes the designer to elaborate providing more
and more details at successive level of abstractions.
• Abstraction and refinement are complementary concepts.

Refactoring
• Organization technique that simplifies the design of a
component without changing its function or behavior.
• Examines for redundancy, unused design elements and
inefficient or unnecessary algorithms.

15
 Design Concepts Cont..

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”.
• An aspect is a representation of a crosscutting concern.
• A crosscutting concern is some characteristic of the
system that applies across many different requirements.

16
 DESIGN CLASSES Cont..

• Class represents a different layer of design architecture.

Five types of Design Classes
1. User interface class
-- Defines all abstractions that are necessary for human computer
interaction
2. Business domain class
-- Refinement of the analysis classes that identity attributes and
services to implement some of business domain
3.Process class
-- implements lower level business abstractions required to fully
manage the business domain classes
4.Persistent class
-- Represent data stores that will persist beyond the execution
of the software
5.System class
-- Implements management and control functions to operate and
communicate within the computer environment and with the
outside world.
17
 Architectural Design

❖ Software Architecture
❖ Architectural Styles

SILPA C 18
 Cont..
What Is Architecture?

“The architecture of a system is a comprehensive

framework that describes its form and structure—its components
and how they fit together.” --Jerrold Grochow

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.
--Bass, Clements, and Kazman [Bas03]

SILPA C 19
 Cont..

• Software Architecture is not the operational software. It is a

representation that enables a software engineer to

➢ Analyze the effectiveness of the design in meeting its

stated requirements.

➢ consider architectural alternative at a stage when

making design changes is still relatively easy .

➢ Reduces the risk associated with the construction of the

software.

SILPA C 20
 Cont..

Why Is Architecture Important?

Three key reasons

1. Representations of software architecture enables

communication and understanding between
stakeholders.

2. Highlights early design decisions to create an operational

entity.

3. Constitutes a model of software components and their

interconnection.

SILPA C 21
 Architectural styles

Taxonomy of Architectural Styles

❖ Data-centered architectures
❖ Data-flow architectures
❖ Call and return architectures
❖ Object-oriented architectures
❖ Layered architectures

SILPA C 22
 Cont..

• Definition: An architectural style is a transformation that is

imposed on the design of an entire system. The intent is to
establish a structure for all components of the system.

• Each styles describes a system category that encompasses:

1. a set of components

2. a set of connectors that enables “communication and

coordination

3. Constraints that define how components can be

integrated to form the system

4. Semantic models to understand the overall properties

of a system
SILPA C 23
 Cont..

Data-centered architectures

❖ Data-centered architectures promote integrability

[Bas03]. That is, existing components can be changed and
new client components added to the architecture without
concern about other clients (because the client components
operate independently).

SILPA C 24
 Cont..

Figure: Data-centered architecture

SILPA C 25
 Cont..

Data-flow architectures

• Shows the flow of input data, its computational components

and output data

• Structure is also called pipe and Filter

• Pipe provides path for flow of data

• Filters manipulate data and work independent of its

neighboring filter

• If data flow degenerates into a single line of transform, it is

termed as batch sequential.

SILPA C 26
 Cont..

Figure: Data-flow architecture

SILPA C 27
 Cont..
Call and return architectures

• Achieves a structure that is easy to modify and scale

• Two sub styles

(1) Main program/sub program architecture

-- Classic program structure

-- Main program invokes a number of components,

which in turn invoke still other components

(2) Remote procedure call architecture

--Components of main program/subprogram are

distributed across computers over network

SILPA C 28
 Cont..

Figure: Main program/subprogram architecture

SILPA C 29
 Cont..

Object-oriented architectures

• The components of a system encapsulate data and the

operations

• Communication and coordination between components is

done via message

SILPA C 30
 Cont..

Layered architectures

• A number of different layers are defined

• Inner Layer( interface with OS)

• Intermediate Layer (Utility services and application

function)

• Outer Layer (User interface)

SILPA C 31
 Cont..

Figure: Layered Architecture

SILPA C 32