SOFTWARE ENGINEERING

CSE
V SEMESTER ​
​
UNIT – IIUN
Module-III- II
 Contents

SOFTWARE DESIGN
Design process:
• Design concepts,
• Design model, design heuristic,
• Architectural design architectural styles,
• Architectural design, and architectural mapping using data flow.

User interface design:

• Interface analysis,
• Interface design

Component level design:

• Designing class-based components,
• Traditional components.
 Design process

• Software design is an iterative process through which requirements are

translated into a “blueprint” for constructing the software.

• Initially, the blue print depicts a holistic view of software. That is, the design
is represented at a high level of abstraction— a level that can be directly
traced to the specific system objective and more detailed data, functional, and
behavioral requirements.

• During the design process the software requirements model is

transformed into design models that describe the details of the data
structures, system architecture, interface, and components.

• Design is considered to be high level of abstraction.

Design process
 Design process

• Quality Attributes of a good Design

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
 Design process

Software Quality Guidelines and Attributes

Design and Quality Guidelines

• A good design should exhibit good architectural structure

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

Quality Guidelines

• A design should be modular; that is, the software should be logically partitioned into
elements or subsystems.

• A design should contain distinct representations of data, architecture, interfaces, and

components.

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

A design should lead to components that exhibit independent functional

characteristics.

• A design should lead to interfaces that reduce the complexity of connections

between components and with the external environment.
 Design process

Quality Guidelines ..

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

Quality attributes
• Functionality is assessed by evaluating the feature set and capabilities of the
program, the generality of the functions that are derived and the security of the
overall system

• Usability is assessed by considering human factors, overall aesthetics, consistency

and documentation

• Reliability is evaluated by measuring the frequency and severity of failure, the

accuracy of output results, the meantime-to-failure, the ability to recover form
failure, and the predictability of the program

• Performance is measured by processing speed, response time, resource

consumption, throughput, and efficiency

• Supportability combines the ability to extend the program, adaptability,

serviceability, testability, compatibility, configurability, the ease with which a system
can be installed, and the ease with which problems can be localized
 Design process

The Evolution of Software Design

• The evolution of software design is a continuing process that has now spanned
almost six decades.

• All these methods have a number of common characteristics:

1. A mechanism for the translation of the requirements model into a design

representation,
2. A notation for representing functional components and their interfaces,
3. Heuristics for refinement and partitioning, and
4. Guidelines for quality assessment. Regardless of the design method that is
used, you should apply a set of basic concepts to data, architectural,
interface, and component-level design.
 Design model

Design model can be viewed as

–Process dimension indicating the evolution of the design model as design tasks
are executed as part of the software process.

–Abstraction dimension represents the level of detail as each element of the

analysis model is transformed into a design equivalent and then refined iteratively
• Design Model Elements are as follows

• Data design elements

• Architectural design elements
• Interface design elements
• Component-level design elements
• Deployment-level design elements
 Design model

• Data design elements

– Data design creates a model of data and/or information that is

represented at a high level of abstraction.
– Data model is then refined into progressively more implementation-
specific representations that can be processed by the computer-based
system

• Architectural level
• Component level
• Databases and files
• Data structures
 Design model

Architectural design elements

• The architectural design for software is the equivalent to the floor plan of a
house.
• The floor plan depicts the overall layout of the rooms; their size, shape, and
relationship to one another; and the doors and windows that allow movement into
and out of the rooms.
• The floor plan gives us an overall view of the house.
• Architectural design elements give us an overall view of the software.

– The architectural model is derived from

• 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
• The availability of architectural patterns and styles
 Design model

• Interface design elements

– The interface design elements for software tell how information flows into and
out of the system and how it is communicated among the components defined
as part of the architecture
– Important elements of interface design
• The user interface (UI): Usability design incorporates aesthetic elements
(e.g., layout, color, graphics, interaction mechanisms), ergonomic elements
(e.g., information layout and placement, metaphors, UI navigation), and
technical elements (e.g., UI patterns, reusable components). In general, the
UI is a unique subsystem within the overall application architecture.
• External interfaces to other systems, devices, networks or other producers
or consumers of information. The design of external interfaces requires
definitive information about the entity to which information is sent or
received.
• Internal interfaces between various design components. The design of
internal interfaces is closely aligned with component-level design
 Design model

Design Model - Interface Elements

6
 Design model
Component-level design elements

The component-level design for software is the equivalent to a set of detailed

drawings (and specifications) for each room in a house. These drawings depict
wiring and plumbing within each room, the location of electrical receptacles and
wall switches, faucets, sinks, showers, tubs, drains, cabinets, and closets.

• Component-level design for software fully describes the internal detail of

each software component.
• Component-level design defines data structures for all local data objects and
algorithmic detail for all processing that occurs within a component and an
interface that allows access to all component operations
• The design details of a component can be modelled at many different
levels of abstraction.
• An UML activity diagram can be used to represent processing logic. Detailed
procedural flow for a component can be represented using either pseudocode
or diagrammatic form (e.g., flowchart or box diagram.

7
 Design model

Component Elements

Sensor

SensorManagemen t

8
 Design model

Deployment-level design elements

• Deployment-level design elements indicate how software functionality and

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

• Deployment diagrams shows the computing environment but does not

explicitly indicate configuration details

9
 Component-level design

• Component-level design occurs after the first iteration of the

architectural design
• It strives to create a design model from the analysis and architectural
models
• A component-level design can be represented using some intermediate
representation (e.g. graphical, tabular, or text-based) that can be translated
into source code
• The design of data structures, interfaces, and algorithms should
conform to well-established guidelines to help us avoid the
introduction of errors

9
 Component-level design

Software component
Define
•
d
A software component is a modular building block for computer
software
– It is a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces
• A component communicates and collaborates with
– Other components
– Entities outside the boundaries of the system
• Three different views of a component
– An object-oriented view
– A conventional view
– A process-related view

5 9
 Component-level design
Object-oriented View
•
Define
A component is viewed as a set of one or more collaborating classes
•
d to identify all attributes and
Each problem domain (i.e., analysis) class and infrastructure (i.e.,
design) class is elaborated
operations that apply to its implementation
– This also involves defining the interfaces that enable classes to
communicate and collaborate
• This elaboration activity is applied to every component defined as
part of the architectural design
• Once this is completed, the following steps are performed
1) Provide further elaboration of each attribute, operation, and interface
2) Specify the data structure appropriate for each attribute
3) Design the algorithmic detail required to implement the processing
logic associated with each operation
4) Design the mechanisms required to implement the interface to include
the messaging that occurs between objects

5
6 9
 Component-level design
Conventional View
•
Define
A component is viewed as a functional element (i.e., a module) of a
d
program that incorporates
– The processing logic
– The internal data structures that are required to implement the processing
logic
– An interface that enables the component to be invoked and data to be
passed to it
• A component serves one of the following roles
– A control component that coordinates the invocation of all other problem
domain components
–
A problem domain component that implements a complete or partial
function that is required by the customer
–
An infrastructure component that is responsible for functions that support
the processing required in the problem domain

9
 Component-level design

Define
Process-related View
d
• Emphasis is placed on building systems from existing components
maintained in a library rather than creating each component from
scratch
• As the software architecture is formulated, components are selected
from the library and used to populate the architecture
• Because the components in the library have been created with reuse in
mind, each contains the following:
– A complete description of their interface
– The functions they perform
– The communication and collaboration
they require

9 9
 Component-level design

Component-level Design Principles

• Open-closed principle
– A module or component should be open for extension but closed for modification
– The designer should specify the component in a way that allows it to be extended without the
need to make internal code or design modifications to the existing parts of the component
• Liskov substitution principle
– Subclasses should be substitutable for their base classes
– A component that uses a base class should continue to function properly if a subclass of the
base class is passed to the component instead
• Dependency inversion principle
– Depend on abstractions (i.e., interfaces); do not depend on concretions
– The more a component depends on other concrete components (rather than on the interfaces)
the more difficult it will be to extend
• Interface segregation principle
– Many client-specific interfaces are better than one general purpose interface
– For a server class, specialized interfaces should be created to serve major categories of clients
– Only those operations that are relevant to a particular category of clients should be specified
in the interface

11
 Component-level design

Component-Level Design Guidelines

Components:
Naming conventions should be established for components that are specified as part
of the architectural model and then refined and elaborated as part of the component-
level model.
Interfaces
Interfaces provide important information about communication and
Dependencies and Inheritance
It is a good idea to model dependencies from left to right and inheritance from
bottom(derived classes)to top (base classes).

13
 Component-level design

Cohesion
• Cohesion is the “single-mindedness’ of a component
• It implies that a component or class encapsulates only attributes and
operations that are closely related to one another and to the class or
component itself
• The objective is to keep cohesion as high as possible
• The kinds of cohesion can be ranked in order from highest (best) to
lowest (worst)
– Functional
• A module performs one and only one computation and then returns a result
– Layer
• A higher layer component accesses the services of a lower layer component
– Communicational
• All operations that access the same data are defined within one class

(More on next slide) 14

 Component-level design
Cohesion (continued)
• Kinds of cohesion (continued)
– Sequential
• Components or operations are grouped in a manner that allows the first to
provide input to the next and so on in order to implement a sequence of
operations
– Procedural
• Components or operations are grouped in a manner that allows one to be
invoked immediately after the preceding one was invoked, even when no data
passed between them
– Temporal
• Operations are grouped to perform a specific behavior or establish a certain
state such as program start-up or when an error is detected
– Utility
• Components, classes, or operations are grouped within the same category
because of similar general functions but are otherwise unrelated to each other

15
 Component-level design

Coupling

• As the amount of communication and collaboration increases between

operations and classes, the complexity of the computer-based system
also increases
• As complexity rises, the difficulty of implementing, testing, and
maintaining software also increases
• Coupling is a qualitative measure of the degree to which operations
and classes are connected to one another
• The objective is to keep coupling as low as possible

(More on next slide)

16
 Component-level design
Coupling (continued)
• The kinds of coupling can be ranked in order from lowest (best) to
highest (worst)
– Data coupling
• Operation A() passes one or more atomic data operands to operation B(); the
less the number of operands, the lower the level of coupling
– Stamp coupling
• A whole data structure or class instantiation is passed as a parameter to an
operation
– Control coupling
• Operation A() invokes operation B() and passes a control flag to B that directs
logical flow within B()
• Consequently, a change in B() can require a change to be made to the meaning
of the control flag passed by A(), otherwise an error may result
– Common coupling
• A number of components all make use of a global variable, which can lead to
uncontrolled error propagation and unforeseen side effects
– Content coupling
• One component secretly modifies data that is stored internally in another
component
(More on next slide)
17
 Component-level design

Coupling (continued)
• Other kinds of coupling (unranked)
– Subroutine call coupling
• When one operation is invoked it invokes another operation within side of it
– Type use coupling
• Component A uses a data type defined in component B, such as for an instance
variable or a local variable declaration
• If/when the type definition changes, every component that declares a variable
of that data type must also change
– Inclusion or import coupling
• Component A imports or includes the contents of component B
– External coupling
• A component communicates or collaborates with infrastructure components
that are entities external to the software (e.g., operating system functions,
database functions, networking functions)

18
 Component-level design
Conducting Component-Level Design
1) Identify all design classes that correspond to the problem domain as defined
in the analysis model and architectural model
2) Identify all design classes that correspond to the infrastructure domain
• These classes are usually not present in the analysis or architectural models
• These classes include GUI components, operating system components, data
management components, networking components, etc.
1) Elaborate all design classes that are not acquired as reusable
components
a) Specify message details (i.e., structure) when classes or components collaborate
b) Identify appropriate interfaces (e.g., abstract classes) for each component
c) Elaborate attributes and define data types and data structures required to
implement them (usually in the planned implementation language)
d) Describe processing flow within each operation in detail by means of pseudocode
or UML activity diagrams

(More on next slide)

19
 Component-level design

Conducting Component-Level Design (continued)

4) Describe persistent data sources (databases and files) and
identify the classes required to manage them
5) Develop and elaborate behavioral representations for a class
• or component
This can be done by elaborating the UML state diagrams created for the analysis
model and by examining all use cases that are relevant to the design class
4) • Elaborate deployment diagrams to provide additional
implementation detail
Illustrate the location of key packages or classes of components in a system by
using class instances and designating specific hardware and operating system
• environments
4) Factor every component-level design representation and always
• consider alternatives
Experienced designers consider all (or most) of the alternative design solutions before
settling on the final design model
The final decision can be made by using established design principles and
guidelines

20
 Component-level design

Designing Conventional Components

• Conventional design constructs emphasize the maintainability of a
functional/procedural program
– Sequence, condition, and repetition
• Each construct has a predictable logical structure where control enters
at the top and exits at the bottom, enabling a maintainer to easily
follow the procedural flow
• Various notations depict the use of these constructs
– Graphical design notation
• Sequence, if-then-else, selection, repetition (see next slide)
– Tabular design notation (see upcoming slide)
– Program design language
• Similar to a programming language; however, it uses narrative text embedded
directly within the program statements

22
 Component-level design

Graphical Design Notation

T F

Sequence If-then-else

T
F F
T
F T
T
F

Selection Repetition
23
 Graphical Example used for Algorithm Analysis
1 int functionZ(int y) 3
2 {
3 int x = 0;
4
4 while (x <= (y * y))
5 { 6 7
6 if ((x % 11 == 0) &&
7 (x % y == 0))
9
8
9
{
printf(“%d”, x);
12 13
10 x++;
11 } // End if 10
12 else if ((x % 7 == 15
13 0) ||
14 (x % y == 16
15 1))
16 { 18
17 printf(“%d”, y);
18 x = x + 2;
19 } // End else 20
printf(“\n”);
20 } // End of list\n");
printf("End 21
21 while
return 0;
22 } // End functionZ 24
 Software Architecture

What is software Architecture

•When you consider the architecture of a building, many different attributes come to
mind. At the most simplistic level, you think about the overall shape of the physical
structure. But in reality, architecture is much more. It is the manner in which the
various components of the building are integrated to form a cohesive whole.
•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
•Software architecture enables to
– Analyze the effectiveness of the design in meeting its stated requirements
– Consider architectural alternatives at a stage when making design changes is
still relatively easy
– Reduce the risks associated with the construction of the software

1
 Software Architecture
• Architectural design represents the structure of data and program
components that are required to build a computer-based system.
• It considers the architectural style that the system will take, the structure
and properties of the components that constitute the system, and the
interrelationships that occur among all architectural components of a system

• Architecture two levels of the design – data design

architectural
considers design. Data
and design enables us to represent the data
component of the architecture.
• Architectural design focuses on the representation of the
structure of
software components, their properties, and interactions

2
 Software Architecture
Why Is Architecture Important?
•Representations of software architecture are an enabler for communication between
all parties, interested in the development of a computer-based system.
•The architecture highlights early design decisions that will have a profound impact
on all software engineering work that follows and, as important, on ultimate success
of the system as an operational entity.
•Architecture constitutes a relatively small, intellectually graspable model of how
the system is structured and how its components work together.

3
 Software Architecture
Architectural Descriptions
• Each of us has a mental image of what the word architecture means.
In
reality, however, it means different things to different people.
• The implication is that different stakeholders will see an architecture from
different viewpoints that are driven by different sets of concerns.
•An architectural description is actually a set of work products that
•reflect different views
An architectural of the system.
description exhibit of a software-based system
mustbuilding.
characteristics that are analogous to those noted for the office
•Developers want clear, decisive guidance on how to proceed with design.
• Customers want a clear understanding on the environmental changes that must
occur and assurances that the architecture will meet their business needs.
 Software Architecture
Architectural Decisions
•Each view developed as part of an architectural description addresses a
specific stakeholder concern.
•To develop each view (and the architectural description as a whole) the system
architect considers a variety of alternatives and ultimately decides on the specific
architectural features that best meet the concern.
• Therefore, architectural decisions themselves can be considered to be one view
of the architecture.
• The reasons that decisions were made provide insight into the structure of a
system and its conformance to stakeholder concerns.
 Software Architectural Styles

1. A Brief Taxonomy ofArchitectural

Styles
2. Architectural Patterns
3. Organization and Refinement
CommonArchitectural Styles of Homes

8
 Software Architectural Style
• The software that is built for computer-based systems exhibit one of many
architectural styles
• Each style describes a system category that encompasses
– A set of component types that perform a function required by the system
– A set of connectors (subroutine call, remote procedure call, data stream,
socket) that enable communication, coordination, and cooperation
among components
– constraints that define how components can be integrated to
form the system;
– semantic models that enable a designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts

9
 Abrief Taxonomyof ArchitecturalStyles
Independent
Components

Communicati Event
ng Processes Systems

Implicit Explicit
Client/Server Peer-to-Peer Invocati Invocati
on on

Data Data-Centered
Flow

Batch Pipe Repository Blackboar

Sequential and d
Filter

Virtual Call
Machine andReturn

Main Program Object

and Layere Oriente
Interpreter Rule-Based Subroutine d d
System Remote Procedure 10
Call
 Software Architectural Style
A Brief Taxonomy of Architectural Styles
•Data-centered architectures.
•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.
•illustrates a typical data-centered style. Client software accesses a central
repository. In some cases the data repository is passive. That is, client software
accesses the data independent of any changes to the data or the actions of other
client software. A variation on this approach transforms the repository into a
ď
͞ laĐkďoard
 Data-Centered Style

ClientA Client B Client C

Shared Data

Client D Client E Client F

12
 Software Architectural Style
Data-flow architectures
• 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 shows has a set of components, called
filters, by pipes that transmit data from one component to the next.
connected
• Each filter works independently of those components upstream
and
downstream, is designed to expect data input of a certain form,
and
produces data output (to the next filter) of a specified form.
• However, the filter does not require knowledge of the workings of
its
neighboring filters.
 Data Flow Style

pipe

Validate Sort Update Report

fIilter

14
 Software ArchitecturalStyle
Call and return architectures.
• This architectural style enables you to achieve a program structure that
is
relatively easy to modify and scale.
••Main
A number of substyles exist within
program/subprogram this category:
architectures: This classic program structure
decomposes function into a control hierarchy where a
invokes a number of program program turn
components
other that Figure illustrates an architecture of this type. may
components. invoke
• Remote call architectures: The still
components of a main
procedure
program/subprogram architecture are distributed multiple
across
computers on a network.
 Call-and-Return Style

Main module

Subroutine B
SubroutineA

SubroutineA-1 SubroutineA-2

Application layer Class V Class W

Transport layer

Network layer Class X Class Y

Data layer
Class Z
Physical layer
16
 Software ArchitecturalStyle
Object-oriented architectures
•The components of a system encapsulate data and the operations that must
be
applied to manipulate the data.
•Communication and coordination between components are accomplished via
message passing.
Layered architectures.
• The basic structure of a layered architecture is illustrated in Figure.
•A number of different layers are defined, each accomplishing operations
that progressively become closer to the machine instruction set.
•At the outer layer, components service user interface operations.
••At the inner layer,layers
Intermediate components perform
provide operating
utility system
services and interfacing.
application
Software functions.
Layered architectures
 Architectural Patterns
• As the requirements model is developed, you’ll notice that the software must
address a number of broad problems that span the entire application.
• For example, the requirements model for virtually every e-commerce
application is faced with the following problem: How do we offer a broad
array of goods to a broad array of customers and allow those customers to
purchase our goods online?
• Architectural patterns address an application-specific problem within a
specific context and under a set of limitations and constraints. The pattern
proposes an architectural solution that can serve as the basis for architectural
design.

19
 Software Architectural
Organization and Refinement
•Because the design process often leaves you with a number of architectural alternatives, it is
important to establish a set of design criteria that can be used to assess an architectural design
that is derived.
Control.
•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? What is the
control topology (i.e., the geometric form that the control takes)? Is control synchronized or
do components operate asynchronously?
Data.
•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 (e.g., a blackboard or repository) exist, and if so,
what is their role? How do functional components interact with data components? 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?
 Architectural Design Steps
• 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.

1. Represent the system in context

2. Define archetypes
3. Refine the architecture into components
4. Describe instantiations of thesystem

1
 Architectural Design Steps

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

2
 Architectural Design Steps

"Super"ordinatesystems

Usedby
I/ I/ I/
Use
F F F
s
Target
system Produces
Produceso or Peer
Actors I/ I/ consumes s
r
F F Depends
consumes
on

"Sub"ordinate
systems 3
 Arhitectural Design Steps
• 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
• those systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality
- Peer-level systems
• Interact on a peer-to-peer basis with target system to produced or
consumed by peers and target system
– Actors
• People or devices that interact with target system to produce or consume
data

4
 Architectural Design Steps

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
•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
The archetypes and their relationships can be
•system
– illustrated
They can beinderived from class
a UML the analysis class model
diagram

5
 Architectural Design Steps

• Archetypes in Software Architecture

• Node -Represents a cohesive collection of input and
output elements of the home security function
• Detector/Sensor - An abstraction that encompasses all sensing equipment
that feeds information into the target system.
• Indicator - An abstraction that represents all mechanisms (e.g., alarm siren,
flashing lights, bell) for indicating that an alarm condition is occurring.
• Controller - An abstraction that depicts the mechanism that allows the arming
or disarming of a node. If controllers reside on a network, they have the ability
to communicate with one another.

6
Archetypes – their attributes

7
Archetypes – their methods

8
 Architectural Design Steps

Refine the Architecture into Components

• Based on the archetypes, the architectural designer the software
refines
architecture into components to illustrate overall structure
the architectural style of the system and
• 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
• These components are derived from various sources

– Theinterfaces in the ACD imply one or morespecialized

components that modelthe data that flow across the interface.

9
 Architectural Design Steps
• AUML classdiagram can represent the classesof the refined
architecture and their relationships

10
 Architectural Design Steps

Describe Instantiations of the System

•The architectural design that has been modeled to this point is still
relatively high level.
•The context of the system has been represented, archetypes that indicate the
important abstractions within the problem domain have been defined, the overall
structure of the system is apparent, and the major software components
have been identified.
• However, further refinement (recall that all design is iterative) is still
necessary.

11
 Architectural Mapping using Data
• Transform mapping is a set of design steps that allows a DFD with
transform flow characteristics to be mapped into a specific
architectural style.
– Information must enter and exit software in an ͞exterŶal
world͟ . Such externalized data must be converted into an
internal form for processing. Information enters along paths that
transform external data into an internal form. These paths are identified
are Incoming flow.
– Incoming data are transformed through a transform center and move along
the paths that now lead o͞ ut͟ of the software. Data moving along thesepaths are
called Outgoing flow.
• Transaction Flow
– flow Is often characterized by a Singledata item
called Transaction, that triggers other data flow along one of many paths.
Information
– Transaction flow is characterized by data moving along an incoming path
that converts external world information into a transaction
– The transaction is evaluated and, based on its value, flow along one of
many action paths is initiated. The hub of information from which many
action paths emanate is called a transaction center
1
 Architectural Mapping using Data
Flow
Flow Characteristics

Transform flow

Transaction
flow

2
 Architectural Mapping using Data
Flow
• Transform Mapping
1. Review the fundamental system model.
2. Review and refine data flow diagrams for the software
3. Determinewhether the DFD has transform or transaction flow
characteristics.
4. Isolate the transform center by specifying incoming and outgoing flow
boundaries.
5. Perform f͞ irst-level factoring
6. Perform ͞second-level factoring
7.Refinethe first-iteration architecture using design heuristics for
improved software quality.

3
 Architectural Mapping using Data
Flow
Transform Mapping

g h
b
a f
d e

c i
j
data flow model

x1
"Transform" mapping

x2 x3 x4

b c d e f g i

a h j

4
 Architectural Mapping using Data

Factoring

direction of increasing
decision making typical "decision
making"
modules

typical "worker" modules

5
 Architectural Mapping using Data
Flow
First Level Factoring

main program
controller

input processing output

controller controller controller

6
 Architectural Mapping using Data

SecondLevel
Factoring
main
D
C
control

A
B
A

B
C

mapping from the D

flow boundary outward

7
 Architectural Mapping using
Data
• Transaction Mapping
1. Review the fundamental system model.
2. Review and refine data flow diagrams for the software
3. Determine whether the DFD has transform or transaction flow
characteristics.
4. Isolate the transaction center and the flow characteristics along each of
the
action paths.
5. Map the DFD in a program structure amenable to transaction processing.
6. Factor and refine the transaction structure and the structure of each
action path.
7. Refine the first-iteration architecture using design heuristics for improved
software quality.

8
 Architectural Mapping using Data
Flow
isolate Flow Paths

error
command msg
produce fixturesetting
read error
msg status format
comman
d determine
invalidcommand setting setting
validate read raw setting
command fixture
command
combined
status status
determine
validcommand type

read
robot control record record

calculate
output
send values values
control
value format
report
assembly report
record
start/stop

10
 Architectural Mapping using Data
Flow
TransactionMapping

Data flow f
model
a e
b d
t mapping x1

g i program
l h structure
k
b t
j
m
a x2 x3 x4
n

d e f g l m n
h x3.1

i j

9
 Architectural Mapping using
Data Flow
Map the
FlowModel
process
operator
commands

command determine
input type
controller

read produce error fixture status report send

validate
command message controller generation contro
command
controller value

each of the action paths must be expandedfurther

11
 Architectural Mapping using Data
Flow
Refining
process
operator
command
s

comman determin
d input e
controller type

read validate produce fixture report send

comman error status generatio
d comman messag controlle n contro
d e r controller l
value

read determine format

fixture setting setting calculat
read forma
status e
t
recor output
report
d
values

12
 Architectural Mapping using Data Flow

•Refining the Architectural Design

•Any discussion of design refinement should be prefaced with the following
comment:
•You should be concerned with developing a representation of software that
will meet all functional and performance requirements and merit acceptance
based on design measures and heuristics.
• Refinement of software architecture during early stages of design
is to be encouraged.