UNIT-III

Creating an architectural design

 Design concepts

 Software Architecture

 Data design

 Architectural styles and patterns

 Architectural Design

1
Design Within The Context Of Software
Engineering

2
Three characteristics that serve as a guide 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 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.
3
 Software Quality Guidelines

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.
4. A design should lead to data structures that are
appropriate for the classes to be implemented and are
drawn from recognizable data patterns.

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

5
 Quality Attributes
A set of software quality attributes that has been given the acronym FURPS

• Functionality
• usability
• reliability
• performance
• supportability.

The FURPS quality attributes represent a target for all software design:

• These attributes represent a more common term, maintainability— and in

addition, testability, compatibility, configurability the ease with which a
system can be installed, and the ease with which problems can be localized.

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

7
 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?

8
 Cont..
1. Abstraction
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

9
 Design Concepts Cont..

1)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,
10
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).

11
 Design Concepts Cont..

2) 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 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.

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

13
 Design Concepts Cont..
3) 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
14
 Design Concepts Cont..

4) 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.

15
 Design Concepts Cont..

5) 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
16
 Cont..

Figure: Modularity and software cost

17
 Cont..
Design Concepts

6) 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

18
 Design Concepts Cont..

7) 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

19
 Design Concepts Cont..

8) 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.

20
 Design Concepts Cont..

9) 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.

21
10) 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.
22
 Architectural Design

 Software Architecture
 Architectural Styles

23
 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

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

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

26
 Architectural styles

Taxonomy of Architectural Styles

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

27
 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

28
 Cont..

Data-centered architectures

Data-centered architectures promote integrability. 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).

29
 Cont..

Figure: Data-centered architecture

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

31
 Cont..

Figure: Data-flow architecture

32
 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

33
 Cont..

Figure: Main program/subprogram architecture

34
 Cont..

Object-oriented architectures

• The components of a system encapsulate data and the

operations

• Communication and coordination between components is

done via message

35
 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)

36
 Cont..

Figure: Layered Architecture

37
 Architectural Design

 As architectural design begins, the software to be developed

must be put into context—that is, the design should define
the external entities (other systems, devices, people) that
the software interacts with and the nature of the interaction.
 An archetype is an abstraction (similar to a class) that
represents one element of system behavior.

 Representing the System in Context

 Defining Archetypes
 Refining the Architecture into Components

38
Figure: Architectural context
diagram
39
Figure: Architectural context diagram for the
SafeHome security function
40
Figure: UML relationships for SafeHome security
Function archetypes 41
• A component diagram shows a set of
components and their relationships.
Graphically, a component diagram is a
collection of vertices and arcs.

Component diagrams commonly contain

Components,Interfaces

Relationships:
Dependency,Generalization, Association,
and Realization
43
Figure: Overall architectural structure for
SafeHome with top-level components
44
 Pattern Based Design
Concepts
• Design Patterns
• Kinds of Patterns
• Object-oriented design patterns
• Frameworks
• Describing a Pattern
• Pattern language and Repositories
 Design patterns
• A design pattern can be characterized as “a three-part rule
which expresses a relation b/w a certain context, a problem
and a solution.”
 Effective design patterns:
 It solves a problem – patterns captures solutions, not just
abstract principles or strategies.
 It is a proven concept – captures solution with a track record,
not theories.
 The solution isn’t obvious – Many problem solving
techniques.
 It describes a relationship – deeper system structures and
mechanisms.
 Kinds of Patterns
• Architectural Patterns – broad-based design problems are
solved using structural approach.
• Data Patterns – recurring data-oriented problems and data
modeling solutions
• Component patterns – address problems associated with
the development of subsystems and components.
• Interface design patterns – common user interface
problems & solutions.
• WebApp patterns – set of problems encountered when
building WebApps.
• Mobile Patterns – commonly encountered problems when
developing mobile platform.
Object-Oriented Design patterns:
 Creational Patterns – creation,
composition and representation of objects.
 Structural patterns – problems and
solutions associated with how classes and
objects are organized.
 Behavioral patterns – problems associated
with the assignment of responsibilities
b/w objects.
 Frameworks
• Implementation of skeletal infra-structure,
called a framework.
• In object-oriented context, a framework is
a collection of cooperating classes.
 Describing a pattern
 We can describe a pattern using design pattern templates.
• Pattern Name – expressive name
• Problem – problem that the pattern addresses
• Motivation – example pattern or problem
• Context – describes the environment
• Solution – detailed description
• Intent – describes the pattern
• Collaboration – other patterns contribute to the solution
• Consequences – consequences of using the pattern
• Implementation – identifies special issues when implementing
pattern
• Known uses – actual uses of the design pattern in real applications
• Related patterns – cross-references related design patterns
 Pattern language and
Repositories
• When we use the term language, the first thing that comes to mind is
either a natural language or programming language.
• When the term language is used in design patterns, it takes slightly
different meaning. A pattern language is a collection of patterns, each
described using a standardized template.
• Dozens of patterns languages have been proposed for software design.
In most cases, the design patterns that are part of pattern language are
stored in a web accessible pattern repository. The repository provides an
index of all design patterns.