Software Engineering

B.Tech IT/III Sem-I

Unit-4 PPT SLIDES

Text Books:1.Software Engineering, A practitioner’s approach

Roger s. Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition

1
 UNIT 4 SYLLABUS
• Design Engineering : Design process and
Design quality, Design concepts, the design
model.
• Creating an architectural design : Software
architecture, Data design, Architectural styles
and patterns, Architectural Design.

2
 Software Design

• Design ->The first step in the development phase for any engineered
product.
• It serves as the foundation for all software engineering and software
maintenance steps that follow.

• The goal of a designer is to produce a model (or representation) of an

entity that will later be built.

• Input of software design: Req. analysis models and specification doc.

• Output of software design: Design models and design specification doc.

• Design - translates the requirements into a completed design model for a

software product.
- provides the representations of software that can be assessed for
quality.
 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?

4
 Design Engineering
• It covers the set of principles, concepts, and practices that
lead to the development of a high quality system or product.
• Goal of design engineering is to produce a model or
representation that depict:
– Firmness – program should not have any bug that inhibits its functions.
– Commodity – suitable to its intended use.
– Delight - pleasurable to use
• The design model provides detail about software data
structures, architecture, interfaces, and components that are
necessary to implement the system.
 Software Design
• Software design model consists of 4
designs:
– Data/class Design
– Architectural Design
– Interface Design
– Component Design
Translating Analysis  Design
• Data/class design - Created by transforming the analysis
model class-based elements into classes and data structures
required to implement the software
• Architectural design - defines the relationships among the
major structural elements of the software, it is derived from
the class-based elements and flow-oriented elements of the
analysis model
• Interface design - describes how the software elements,
hardware elements, and end-users communicate with one
another, it is derived from the analysis model scenario-based
elements, flow-oriented elements, and behavioral elements
• Component-level design - created by transforming the
structural elements defined by the software architecture into a
procedural description of the software components using
information obtained from the analysis model class-based
elements, flow-oriented elements, and behavioral elements
 Why design is so important?
• It is place where quality is fostered.
• It provides us with representation of software that can be
assessed for quality.
• Only way that can accurately translate a customer’s
requirements into a finished software product.
• It serves as foundation for all software engineering
activities.
• Without design difficult to assess:
– Risk
– Test
– Quality
Design Process and Design Quality
• S/w design is an iterative process through which
requirements are translated into a “blueprint” for
constructing the s/w.
• As design iteration occur, subsequent refinement leads
to design representation at much lower levels of
abstraction.
• Design creates a representation or model of the software
– Quality is established during Design
– Design should exhibit firmness, commodity and
design
– Design sits at the kernel of S/W Engineering
– Design sets the stage for construction
 The Engineering
Design Process
→Begins with a recognition of need for a
product, service, or system

→During the idea phase encourage a wide

variety of solutions through brainstorming,
literature search, and talking to users

→Best solutions are selected for further

refinement

→Models or prototypes are made and

problems that arise may require new ideas to
solve and a return to an earlier stage in the
process

→Finally drawings are released to

manufacturing for production
Design is an Iterative Process
 Goal of design process
• The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.

• The design must 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.
 Quality Guidelines
Characteristics of good design
1) A design should exhibit an architecture that
– as been created using recognizable architectural styles or patterns,
– is composed of components that exhibit good design characteristics and
– can be implemented in an evolutionary fashion.

2) A design should be modular; that is, the software should be logically

partitioned into elements or subsystems.

1) A design should contain distinct representations of data, architecture,

interfaces, and components.

1) A design should lead to data structures that are appropriate for the classes
to be implemented and are drawn from recognizable data patterns.

1) A design should lead to components that exhibit independent functional

characteristics
 Quality Guidelines (contd.)
• A design should lead to interfaces that reduce the complexity of
connections between components and with the external
environment.

• A design should be derived using a repeatable method that is driven

by information obtained during software requirements analysis.

• A design should be represented using a notation that effectively

communicates its meaning.

QUALITY
FURPS quality attributes
ATTRIBUTES
• Functionality
* Feature set and capabilities of programs
* Security of the overall system

• Usability
* user-friendliness
* Aesthetics
* Consistency
* Documentation

• Reliability
* Evaluated by measuring the frequency and severity of failure
* MTTF

• Performance
* Processing Speed, Response Time
* Resource Consumption
* Efficiency

• Supportability
* Extensibility
* Adaptability 16
* Serviceability
 Design Concepts
• Design concepts provide the necessary framework for
“to get the thing on right way”.

1. Abstractions
2. Architecture
3. Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Re-factoring
9. Design Classes
 Abstraction
• At the highest level of abstraction – a solution is stated in broad
terms
• At lower level of abstraction – a more detailed description of the
solution is provided.

Two types of abstraction:

1. Procedural abstraction: Sequence of instructions that have a
specific and limited function.
Ex. Open a door
→ open implies long sequence of activities (e.g. walk to the door, grasp knob,
turn knob and pull the door, etc).

2. Data abstraction: collection of data that describes a data object.

Ex. Open a door. – door is data object.
→ Data abstraction for door would encompass a set of attributes that describe
the door. (E.g. door type, swing direction, opening mechanism, etc.)
 Architecture
• Software architecture suggest “ the overall structure of the software
and the ways in which that structure provides conceptual integrity
for a system.

• Structure or organization of program components (modules) and

their interconnection.

• No. of different models can use to represent architecture.

Structural Model- represent architecture as an organized
collection of components
Framework model – Increase level of design abstraction by
identifying repeatable architectural design frameworks
(patterns).
Dynamic model – address behavior of the program architecture
and indicating how system or structure configuration may
change as a function.
Process Model – focus on design of the business or technical
process that the system must accommodate.
Functional models – used to represent the functional hierarchy
of a system.
 Patterns
– A design structure that solves a particular design problem
within a specific context.

– It provides a description that 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

20
 Modularity
• Architecture and design pattern embody modularity.

• Software is divided into separately named and addressable

components, sometimes called modules, which are integrated to
satisfy problem requirement.

• modularity is the single attribute of software that allows a program to

be intellectually manageable

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

• It leads to a “Divide and Conquer” strategy : it is easier to solve a

complex problem when broken into sub-modules
21
 Modularity
• Refer fig. that state that effort (cost) to develop an individual
software module does decrease if total number of modules
increase.
• However as the no. of modules grows, the effort (cost) associated
with integrating the modules also grows.
Modularity and software cost
 Modularity
• We modularize a design so that –
– development can be more easily planned.
– Software increments can be defined and delivered.
– Changes can be more easily accommodated.
– Testing and debugging can be conducted more
efficiently and long-term maintained can be conducted
without serious side effects.
 Modularity
• Five criteria that define an effective modular system:

- Modular decomposability:
a design method provides a systematic mechanism for decomposing the
problem into sub-problems --> reduce the complexity and achieve the
modularity

- Modular composability:
• a design method enables existing design components to be assembled into a
new system.

- Modular understandability:
• a module can be understood as a standalone unit it will be easier to build and
easier to change.

- Modular continuity:
• small changes to the system requirements result in changes to individual
modules, rather than system-wide changes.

- Modular protection:
• an aberrant condition occurs within a module and its effects are constrained
within the module.
 Information Hiding
• Modules should be specified and designed so that information
(algorithm and data) contained within a module is inaccessible to
other modules that have no need for such information.

• The principle of information hiding suggests that modules be

"characterized by design decisions that (each) hides from all others
modules.“

• The intent of information hiding is to hide the details of data

structure and procedural processing behind a module interface.

• Effective modularity achieved by defining a set of Independent

modules that communicate with one another only that information
necessary to achieve S/W function

• Benefits: when modifications are required during testing and

maintenance, because data and procedure are hiding from other
parts of software, unintentional errors introduced during modification
are less.
 Functional Independence
• A direct outgrowth of Modularity, abstraction and
information hiding.

• Modules that have a "single-minded" function and an

aversion to excessive interaction with other modules.

• Independence is important –
– Easier to develop
– Easier to Test and maintain
– Error propagation is reduced
– Reusable module.

26
 Advantages of Functional
Independence
• Better understandability and good design:
– Complexity of design is reduced,
– Different modules easily understood in isolation:
• modules are independent

• Functional independence reduces error propagation.

– degree of interaction between modules is low.
– an error existing in one module does not directly affect other
modules.

• Reuse of modules is possible.

 Functional Independence
• To summarize, functional independence is a key to good design, and
design is the key to software quality.

• Independence is assessed by two quantitative criteria:

(1) Cohesion
(2) Coupling
Cohesion
• Performs a single task requiring little interaction with other
components
• Cohesion is a measure of the relative functional strength of a module.

Coupling
• Measure of interconnection among modules
• Coupling is a measure of the relative interdependence among
modules.

→ Coupling should be low and cohesion should be high for good design
 Cohesion
A measure of how well a component “fits
together”.
• A component should implement a single logical
entity or function.

• A cohesive module performs a single task within a

software procedure, requiring little interaction with
procedures being performed in other parts of a program.

• We always strive for high cohesion.

Range of Cohesion

Functional (Most Required)

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental (Least Required)

 Types of Cohesion
• Functional cohesion: Each part of a component is necessary for the
execution of a single function.

• Sequential cohesion: Elements are involved in activities such that output

data from one activity becomes input data to the next

• Communicational Cohesion: Elements contribute to activities that use

the same input or output data

• Procedural cohesion: Elements are related only by sequence, i.e. all part
of a procedure (algorithm)

• Temporal cohesion: Elements are involved in activities that are related in

such a way that all the task must be executed within the same time limit.

• Logical cohesion: Components which perform similar functions are

grouped.

• Coincidental cohesion: Elements contribute to activities with no

meaningful relationship to one another
 Coupling
• A measure of interconnection among modules in a
program structure.
• Coupling depends on the interface complexity between
modules
• Goal: to strive for lowest possible coupling.
Coupling: Degree of dependence
among components

No dependencies Loosely coupled-some dependencies

Highly coupled-many dependencies

Range of Coupling

Content (Most Required)

Common

Control

Stamp

Data (Least Required)

 Types of Coupling
• Data coupling: Two components are data coupled if there are
homogeneous data items.

• Stamp coupling : Two modules are stamp coupled, if they communicate via
a composite data item.

• Control coupling: Data from one module is used to direct order of instruction
execution in another.

• Common coupling : Two modules are common coupled, if they share some
global data.

• Content coupling : Content coupling exists between two modules, if they

share code.
 Refinement
• Process of elaboration from high level abstraction to the lowest level
abstraction.

• High level abstraction begins with a statement of functions (or

description of information).

• That is, the statement describes function or information conceptually

but provides no information about the internal workings of the
function or the internal structure of the information.

• Refinement causes the designer to elaborate on the original

statement, providing more and more detail as each successive
refinement (elaboration) occurs.

• Abstraction and refinement are complementary concepts.

Abstraction enables a designer to specify procedure and data and
yet suppress low-level details.

• Refinement helps the designer to expose low-level details as

design progresses.
 Refactoring
• A reorganization technique that simplifies the design (or
internal code structure) of a component without changing
its function or external behaviour

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

• Removes redundancy, unused design elements,

inefficient or unnecessary algorithms, poorly constructed
or inappropriate data structures, or any other design
failures
37
 Design classes
• Refines the analysis classes by providing design detail
that will enable the classes to be implemented.

• Creates a new set of design classes that implement a

software infrastructure to support the business solution.

 Characteristics of well formed design class:

o Complete and sufficient
o Primitiveness
o High Cohesion
o Low Coupling

38
 Characteristics of a Well-
Formed Design Class
• Complete and sufficient
– Contains the complete encapsulation of all attributes and methods that exist
for the class
– Contains only those methods that are sufficient to achieve the intent of the
class
• Primitiveness
– Each method of a class focuses on accomplishing one service for the class
• High cohesion
– The class has a small, focused set of responsibilities and single-mindedly
applies attributes and methods to implement those responsibilities
• Low coupling
– Collaboration of the class with other classes is kept to an acceptable
minimum
– Each class should have limited knowledge of other classes in other
subsystems

39
 Types of Design Classes
→ Class represents a different layer of design architecture.

• User interface classes – define all abstractions necessary for human-

computer interaction

• Business domain classes – Refinement of the analysis classes that identity

attributes and services (methods) that are required to implement some
element of the business domain

• Process classes – implement business abstractions required to fully

manage the business domain classes

• Persistent classes – represent data stores (e.g., a database) that will

persist beyond the execution of the software

• System classes – implement software management and control functions

that enable the system to operate and communicate within its computing
environment and the outside world
40
 Design Model
• The design model can be viewed in two different dimensions
– (Horizontally) The process dimension indicates the evolution of the
parts of the design model as each design task is executed.
– (Vertically) The abstraction dimension represents the level of detail
as each element of the analysis model is transformed into the
design model and then iteratively refined.

• Elements of the design model use many of the same UML

diagrams used in the analysis model
– The diagrams are refined and elaborated as part of the design
– More implementation-specific detail is provided
– Emphasis is placed on
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architecture

41
 Dimensions of the Design
Model
High

Analysis model
Abstraction Dimension

Design model

Data/Class Architectural Interface Component-level Deployment-level

Low Elements Elements Elements Elements Elements

Process Dimension (Progression)

 The Design Model
high

analysis model

class diagrams
analysis packages
use-cases - text class diagrams
Requirements:
CRC models use-case diagrams constraints
analysis packages
collaboration diagrams
activity diagrams CRC models interoperability
data flow diagrams swim lane diagrams collaboration diagrams targets and
control-flow diagrams collaboration diagrams data flow diagrams
processing narratives state diagrams control-flow diagrams
configuration
sequence diagrams processing narratives
state diagrams
sequence diagrams

design class realizations

subsystems
collaboration diagrams technical interface component diagrams
design class realizations
design design classes
subsystems
Navigation design activity diagrams
collaboration diagrams
GUI design sequence diagrams
component diagrams
design model design classes
refinements to: activity diagrams
refinements to: sequence diagrams
component diagrams
design class realizations design classes
subsystems activity diagrams
low collaboration diagrams sequence diagrams deployment diagrams

architecture interface component-level deployment-level

elements elements elements elements

process dimension
 Design Model (continued)
• Design model elements are not always developed in a
sequential fashion
– Preliminary architectural design sets the stage
– It is followed by interface design and component-level design,
which often occur in parallel

• The design model has the following layered elements

– Data/class design
– Architectural design
Component-level Design
– Interface design
– Component-level design
Interface Design
• A fifth element that follows all of
the others is deployment-level design Architectural Design

Data/Class Design

44
 Design Model
1. Data Design elements
Data design creates a model of data that is represented at a high level
of abstraction.

Refined progressively to more implementation-specific representation

for processing by the computer-based system.

 The structure of data has always been an important part of software design.

• Component level – the design of data structures and the associated

algorithms required to manipulate them is essential to the creation of high-
quality applications.

• Application level – the translation of a data model into a database design is

pivotal to achieving business objective of a system.

• Business level -the collection of information stored in disparate databases

and reorganized into a “data warehouse” that can have an impact on the
success of the business itself.
 Design Model
2. Architectural design elements
– Depicts the overall layout of the software

Derived from three sources-

Information about the application domain of the software to be built

Analysis model such as dataflow diagrams or analysis classes, their

relationships

Architectural pattern and styles

3. Interface Design elements

Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the
architecture.

Includes :
o User interface
o External interfaces to other systems, devices etc
o Internal interfaces between various components 46
 Interface Elements

MobilePhone

WirelessPDA

Cont rolPanel

LCDdisplay
LEDindicators
keyPadCharacteristics K eyPad
speaker
wirelessInterface

readKeyStroke()
decodeKey ()
displayStatus()
lightLEDs()
sendControlMsg()

<<int erfac e>>

K eyPad

readKeystroke()
decodeKey()

Figure 9 .6 UML int erfac e represent at ion for Cont rolPa ne l

 Design Model
4. Component level design elements
– Describes the internal detail of each software component by way
of data structure definitions, algorithms, and interface
specifications

– UML diagram can be used

SensorManagement
Sensor

48
 Design Model
5. Deployment level design elements

– Indicates how software functionality and subsystems

will be allocated within the physical computing
environment that will support the software

– UML deployment diagram is developed and refined

Deployment Elements
Cont rol Panel CPI server

Security homeownerAccess

Personal computer

externalAccess

Security Surveillance

homeManagement communication

Figure 9 .8 UML deployment diagram for SafeHome

 Pattern-based Software Design
• A pattern is a recurring solution to a standard problem, in a context.
• Christopher Alexander, a professor of architecture…
– “A 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.”

 Mature engineering disciplines make use of thousands of design

patterns for such things as buildings, highways, electrical circuits,
factories, weapon systems, vehicles, and computers.

 Design patterns also serve a purpose in software engineering.

– Patterns support reuse of software architecture and design

51
 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
 Using Patterns In Design
• Once the analysis phase is done the designer can use the pattern which
can help him examine about how the problem to be solved and the
constraints that are imposed by problem.

TYPES OF DESIGN PATTERNS

• Architectural patterns
– Define the overall structure of software
– Indicate the relationships among subsystems and software components
– Define the rules for specifying relationships among software elements

• Design patterns
– provides a scheme for refining the subsystems or components of a
software system, relationships among components, or the mechanisms
for effecting inter-component communication or solve some design
problem

• Coding patterns or Idioms

– Describe language-specific patterns that implement an algorithmic or
data structure element of a component, a specific interface protocol, or
a mechanism for communication among components
 Frameworks
 A framework defines the architecture for a family of (sub-) systems
and provides the basic building blocks to create them. It also defines
the places where adaptations for specific functionality should be
made.
 A framework, an extension of patterns, provide an architectural
skeleton for the design of complete sub-systems within a specific
application domain.
→ A Framework is a code Skeleton that can be fleshed out with
specific classes or functionality that have been designed to address
the problem at hand.
→ A Framework is a collection of “Plug Points” (also called hooks and
slots) that enable it to be adapted to a specific problem domain.
→ A Plug Point enable a designer to integrate problem or functionality
within the skeleton.
 In order to increase effectiveness, frameworks can be applied with
no changes , additional features can be added via plug points.
 Architectural Design
 Establishing the overall structure of a software system

Objectives
• To introduce architectural design and to discuss its
importance

• To explain why multiple models are required to document

a software architecture

• To describe types of architectural model that may be used

 Software architecture
• The design process for identifying the sub-systems making up a
system and the framework for sub-system control and
communication is architectural design.

• The output of this design process is a description of the software

architecture.

 Software architectural design represents the structure of the data

and program components that are required to build a computer-
based system.

 Two Levels
Data Design
Architectural Design
 Software Architecture
WHAT.. ??
• “The software architecture of a program or computing system is
the structure or structures of the system, which comprise the
software components, the externally visible properties of those
components, and the relationships among them.”
WHY.. ??
• It is not operational software but it is representation that enables
software engineer to
– Analyze the effectiveness of design in meeting its stated
requirement.
– consider architectural alternatives at a stage when making
design changes is still relatively easy,
– reduce the risks associated with the construction of the
software.
 Importance of Software Architecture
• Representations of software architecture are an enabler
for communication between all parties (stakeholders)
interested in the development.

• Architecture highlights early design decisions that will

have a profound impact on all software engineering work
that follows.

• Architecture “constitutes a relatively small, intellectually

graspable model of how the system is structured and
how its components work together”.
 Data Design
• Data design translates data objects defined as part of the
analysis model into
– Data structures at the software component level
– A possible database architecture at the application level

• It focuses on the representation of data structures that are

directly accessed by one or more software components

• The challenge is to store and retrieve the data in such way

that useful information can be extracted from the data
environment
Data Design at architectural design
• Today, business (i.e. irrespective of its size large or small) have
dozens of database serving many applications encompassing
hundreds of gigabytes of data.

• Challenge is to extract useful information from its data environment,

particularly when the information desired is cross-functional.

• To solve this challenge, developed technique called

– Data Mining (also called knowledge discovery in databases
(KDD)),
– Data Warehouse

• Data mining that navigate through existing databases in an attempt

to extract appropriate business-level information
 Data Design at architectural design
• However, the existence of multiple databases, their
different structures, the degree of detail contained with
the databases, and many other factors make data mining
difficult within an existing database environment.

• A data warehouse is a separate data environment that is

not directly integrated with day-to-day applications but
encompasses all data used by a business

• A data warehouse is a large, independent database that

encompasses some, but not all, of the data that are
stored in databases that serve the set of applications
required by a business.
Data design at the component level
• Component level focuses on the representation of data
structures that are directly accessed by one or more
software components.
Principles are applicable to data design
1. The systematic analysis principles applied to function and
behavior should also be applied to data.
2. All data structures and the operations to be performed on
each should be identified.
3. A data dictionary should be established and used to
define both data and program design (operations)
4. Low-level data design decisions should be deferred until
late in the design process.
Data design at the component level
5. The representation of data structure should be known
only to those modules that must make direct use of the
data contained within the structure.
6. A library of useful data structures and the operations
that may be applied to them should be developed.
7. A software design and programming language should
support the specification and realization of abstract
data types.
 Architectural Style
 Objective : to establish a structure for all components of the system.
• Style describes a system category that encompasses:-
1. A set of components (e.g., a database, computational modules) that perform a
function required by a system;

1. a set of connectors that enable “communication, co-ordinations and

cooperation” among components;

1. constraints that define how components can be integrated to form the system

1. semantic models that enable a designer to understand the overall properties of

a system

It can be represent by
– Data-centered architecture
– Data flow architecture
– Call and return architecture
– Object oriented architecture
– Layered architecture.
 A Taxonomy of Architectural
Styles
Data Flow
Data-Centered

Batch Sequential Pipe and

Filter Repository Blackboard

Call and Return

Main Program Object

and Subroutine Layered Oriented
Remote Procedure Call

65
 Data-centered architecture
• A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that update,
add, delete, or otherwise modify data within the store.

• Client software accesses a central repository which is in passive state (in

some cases) i.e. client software accesses the data independent of any
changes to the data or the actions of other client software.

• So, in this case transform the repository into a “Blackboard”.

• A blackboard sends notification to subscribers when data of interest

changes, and is thus active.

• Data-centered architectures promote integrability i.e. existing components

can be changed and new client components can be added to the
architecture without concern about other clients.

• Data can be passed among clients using the blackboard mechanism. So

Client components independently execute processes
Data-centered architecture
 Data Flow architecture
• This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into
output data.

• A pipe and filter pattern has a set of components, called filters,

connected by pipes that transmit data from one component to the
next.

• Each filter works independently (i.e. upstream, downstream) and is

designed to expect data input of a certain form, and produces data
output (to the next filter) of a specified form.

• the filter does not require knowledge of the working of its

neighboring filters.

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

termed batch sequential.
 Data Flow Style
• Has the goal of modifiability
• Characterized by viewing the system as a series of
transformations on successive pieces of input data
• Data enters the system and then flows through the components
one at a time until they are assigned to output or a data store
• Batch sequential style
– The processing steps are independent components
– Each step runs to completion before the next step begins
• Pipe-and-filter style
– Emphasizes the incremental transformation of data by successive
components
– The filters incrementally transform the data (entering and exiting via
streams)
– The filters use little contextual information and retain no state
between instantiations
– The pipes are stateless and simply exist to move data between filters
69
Data Flow architecture

Pipes and filters

Batch Sequential
 Call-and-Return Style
• Architecture style enables a software designer (system architect) to achieve a
program structure that is relatively easy to modify and scale.

 Two sub-styles exist within this category:

• Main program and subroutine style

– Decomposes a program hierarchically into small pieces (i.e., modules)
– Typically has a single thread of control that travels through various
components in the hierarchy
– Main program invokes a number of components, which in turn invoke still
other components

• Remote procedure call style

– Consists of main program and subroutine style of system that is
decomposed into parts that are resident on computers connected via a
network
– Strives to increase performance by distributing the computations and
taking advantage of multiple processors
71
Call and return architecture
 Call-and-Return Style
• Object-oriented or abstract data type system
– Emphasizes the bundling of data and how to manipulate and access data
– Keeps the internal data representation hidden and allows access to the object
only through provided operations
– Permits inheritance and polymorphism
• Communication and coordination between components is accomplished via
message passing.

• Layered system
– Assigns components to layers in order to control inter-component interaction
– Only allows a layer to communicate with its immediate neighbor
– Assigns core functionality such as hardware interfacing or system kernel
operations to the lowest layer
– Builds each successive layer on its predecessor, hiding the lower layer and
providing services for the upper layer
– Is compromised by layer bridging that skips one or more layers to improve
runtime performance

73
 Layered architecture

• A number of different layers are defined, each

accomplishing operations that progressively become
closer to the machine instruction set.
• At the outer layer, components examine user interface
operations.
• At the inner layer, components examine operating
system interfacing.
• Intermediate layers provide utility services and
application software functions.
Layered Architecture
 Architectural Patterns
An Architectural Pattern is a general, reusable
solution to a commonly occurring problem in
software architecture within a given context.
→ A template that specifies approach for some behavioral
characteristics of the system
→ Patterns are imposed on the architectural styles

Architectural Patterns are often documented as

software design patterns
 Definition
• “An Architectural Pattern is a named collection
of design decisions that are applicable to a
recurring design problem, parameterized to
account for different software development
contexts in which that problem appears”.
 Architectural Patterns
An Architectural Pattern is determined by-
1) A set of element types (such as data repository or
data component)
2) Topological layout of the element indicating their
interrelationships.
3) A set of semantic constraints (e.g. filters in a pipe-
and-filters style)
4) Set of interaction mechanisms that show how the
elements coordinate through the allowed topology
Difference between Pattern and
Style
The main difference is that a pattern can
be seen as a solution to a problem , while
a style is more general and does not
require a problem to solve for its
appearance.
 Architectural Patterns
• Concurrency—applications must handle multiple tasks in a
manner that simulates parallelism
– operating system process management pattern
– task scheduler pattern
• Persistence—Data persists if it survives past the execution
of the process that created it. Two patterns are common:
– a database management system pattern that applies the storage
and retrieval capability of a DBMS to the application architecture
– an application level persistence pattern that builds persistence
features into the application architecture
• Distribution— the manner in which systems or components
within systems communicate with one another in a distributed
environment
– A broker acts as a ‘middle-man’ between the client component
and a server component.
 Organization and Refinement
The following questions provide an assessment
about the design that has been derived
Control:
• “How is the control managed within the
architecture”
Data:
• “How does data communicates between components”
• “What is the mode of Data transfer”
• “Is the data flow continuous”
• “Are data components passive or active”
Architectural Design Steps

1) Represent the system in context

2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system

82
 Architectural Design
• The software must be placed into context
– the design should define the external entities (other
systems, devices, people) that the software interacts
with and the nature of the interaction
• A set of architectural archetypes should be identified
– An archetype is an abstraction (similar to a class) that
represents one element of system behavior
• The designer specifies the structure of the system by
defining and refining software components that
implement each archetype

83
 1. Represent the System in
Context
• Use an architectural context diagram (ACD) that shows
– The identification and flow of all information into and out of a system
– The specification of all interfaces
– Any relevant support processing from/by other systems
• An ACD models the manner in which software interacts with entities external to
its boundaries
• An ACD identifies systems that interoperate with the target system
– Super-ordinate systems
• Use target system as part of some higher level processing scheme
– Sub-ordinate systems
• Used by target system and provide necessary data or processing
– Peer-level systems
• Interact on a peer-to-peer basis with target system to produce or
consume data
– Actors
• People or devices that interact with target system to produce or consume
data 84
 Represent the System in Context
"Super"ordinate systems

Used by

I/F I/F I/F

Uses

Target system
Produces or
Produces or consumes Peers
Actors consumes I/F I/F
Depends on

"Sub"ordinate systems
85
 Architectural Context
Safehome Internet-based
Product system

control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses

uses

sensors sensors

86
 2. Define Archetypes
• Archetypes indicate the important abstractions within the problem
domain (i.e., they model information)
• 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
• It is also an abstraction from a class of programs with a common
structure and includes class-specific design strategies and a
collection of example program designs and implementations
• Only a relatively small set of archetypes is required in order to
design even relatively complex systems
• The target system architecture is composed of these archetypes
– They represent stable elements of the architecture
– They may be instantiated in different ways based on the
behavior of the system
– They can be derived from the analysis class model
• The archetypes and their relationships can be illustrated in a UML
class diagram
 Archetypes
Controller

communicates with

Node

Detector Indicator

Figure 10.7 UML relationships for SafeHome security function archetypes

(adapted from [BOS00]) 88
 3. Refine the Architecture into
Components
• Based on the archetypes, the architectural designer refines the
software architecture into components to illustrate the overall
structure and architectural style of the system
• These components are derived from various sources
– The application domain provides application components, which are the
domain classes in the analysis model that represent entities in the real
world
– The infrastructure domain provides design components (i.e., design
classes) that enable application components but have no business
connection
• Examples: memory management, communication, database, and task
management
– The interfaces in the ACD imply one or more specialized components
that process the data that flow across the interface
• A UML class diagram can represent the classes of the refined
architecture and their relationships
Component Structure
SafeHome
Executive

Function
selection

External
Communication
Management

Security Surveillance Home

management

GUI Internet
Interface

Control detector alarm

panel management processing
processing

90
 4. Describe Instantiations of the
System
• An actual instantiation of the architecture is developed
by applying it to a specific problem

• This demonstrates that the architectural structure, style

and components are appropriate

• A UML component diagram can be used to represent

this instantiation
Refined Component Structure
SafeHome
Executive

External
Communication
Management

Security

GUI Internet
Interface

Cont rol det ect or alarm

panel management processing
processing

Keypad
processing phone
scheduler
communicat ion

CP display
funct ions
alarm

sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
92 sensor
 Assessing Alternative Architectural
Designs
Various Assessment Approaches

• Ask a set of questions that provide the designer with

an early assessment of design quality and lay the
foundation for more detailed analysis of the
architecture
o Assess the control in an architectural design
o Assess the data in an architectural design Apply the
architecture trade-off analysis method

• Assess the architectural complexity

 Approach A: Questions -- Assessing
Control in an Architectural Design

• How is control managed within the architecture?

• Does a distinct control hierarchy exist, and if so, what is the role of
components within this control hierarchy?
• How do components transfer control within the system?
• How is control shared among components?
• Is control synchronized or do components operate asynchronously?

94
 Approach A: Questions -- Assessing
Data in an Architectural Design
• How are data communicated between components?
• Is the flow of data continuous, or are data objects passed
to the system sporadically?
• What is the mode of data transfer (i.e., are data passed
from one component to another or are data available
globally to be shared among system components)
• Do data components exist (e.g., a repository or
blackboard), and if so, what is their role?
• Are data components passive or active (i.e., does the data
component actively interact with other components in the
system)?
• How do data and control interact within the system?

95
 Approach B: Architecture Trade-
off Analysis Method
1) Collect scenarios representing the system from the user's point of
view
2) Elicit requirements, constraints, and environment description to be
certain all stakeholder concerns have been addressed
3) Describe the candidate architectural styles that have been chosen to
address the scenarios and requirements
4) Evaluate quality attributes by considering each attribute in isolation
(reliability, performance, security, maintainability, flexibility,
testability, portability, reusability, and interoperability)
5) Identify the sensitivity of quality attributes to various architectural
attributes for a specific architectural style by making small changes
in the architecture
6) Critique the application of the candidate architectural styles (from
step #3) using the sensitivity analysis conducted in step #5

96
Approach C: Assessing Architectural
Complexity
• The overall complexity of a software architecture can be
assessed by considering the dependencies between
components within the architecture
• These dependencies are driven by the information and control
flow within a system
• Three types of dependencies
– Sharing dependency UV
• Represents a dependency relationship among consumers who use the
same source or producer
– Flow dependency UV
• Represents a dependency relationship between producers and
consumers of resources
– Constrained dependency U “XOR” V
• Represents constraints on the relative flow of control among a set of
activities such as mutual exclusion between two components

97
 Approach D: Architectural
Description Language
• Architectural Description Language (ADL)
provides a semantics and syntax for describing a
software architecture.

– HOFMAN suggests-ADL should provide the designer

with the ability to decompose architectural blocks and
represent interfaces between components.