DESIGN ENGINEERING

Design is a core engineering activity. Design creates a model of the software. Design engineering
encompasses the set of principles, concepts and practices that lead to the development of a high quality
system or product.
The goal of design engineering is to produce a model or representation that exhibits firmness,
commodity and delight. Design engineering for computer software changes continually as new methods,
better analysis and broader understanding evolve.
 A product should be designed in a flexible manner to develop quality software.

DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING:

Software design is the last software engineering action within modeling activity and sets the stage for
development. The analysis model, manifested by scenario-based, class- based, flow-oriented and behavior
elements, feed the design task.

Design model produces a data/class design, an architectural design, an interface design, a component design
and a deployment design.
 The data/class design transforms the analysis class models into design class realizations and data
structures require implementing the software. Part of class design may occur as each software component
is designed.
 The architectural design defines the relationship between major structural elements of software, the
architectural styles and design patterns and the constraints that affect the way in which architectural can
be derived from system specifications, the analysis model and interaction of subsystems defined within
analysis model.

Fig: Translating the Requirements model to Design model

16
 The interface design describes how the software communicates with systems that interoperate with it, and
with humans who use it. Usage scenarios and behavioral models provide much of information required
for the interface design.
 The component-level design transforms structural element of the software architecture into a procedural
description of software components. Information from class-based models, flow models, behavioral
models serve as basis for component design.

DESIGN PROCESS AND DESIGN QUALITY:

Importance of software design can be stated with one word QUALITY. Software design serves as foundation
for all software engineering and software support activities that follow.

Software design is an interactive process through which requirements are translated into a "blueprint" for
constructing the software. Initially, design is represented at a high level of abstraction. As iteration occurs,
subsequent refinement leads to design representations at lower levels of abstraction.

The following characteristics serve as a guide for evaluation of good design:

1. The design must implement all explicit requirements contained in analysis model, and accommodate all
implicit requirements desired by customer.
2. Design must be a readable, understandable guide for those who generate code, who test and support the
software.
3. Design should provide a complete picture of the software, addressing data, functional and behavioral
domains.
 Each of these characteristics is goal of the design process.

Quality Guidelines: Guidelines for quality design are:

1. A design should exhibit an architecture that
a) has been created using recognizable architectural styles/patterns.
b) composed of components that exhibit good design characteristics.
c) can be implemented in an evolutionary fashion.
2. A design should be modular; software should be logically partitioned into elements or sub-systems.
3. It should contain distinct representations of data, architecture, interfaces and components.
4. It should lead to data structures that are appropriate for the classes to be implemented.
5. It should lead to components that exhibit independent functional characteristics.
6. It should lead to interfaces that reduce complexity of connections between components and external
environment.
7. It should be represented using a repeatable (iterative) method.
8. It should be represented using a notation that effectively communicates its meaning.

 Design engineering encourages good design through the application of fundamental design principles,
systematic methodology and through review.

17
Quality Attributes: Hewlett-Packard (HP) developed a set software quality attributes, given by the acronym
FURPS:
1. Functionality: It is assessed by evaluating feature set and capabilities of the program, generality of
functions and security of overall system.
2. Usability: It is assessed by considering human factors, overall aesthetics, consistency and documentation.
3. Reliability: It is evaluated by measuring frequency & severity of failure, ability to recover, accuracy of
output results, Mean- Time-To-Failure (MTTF) and predictability of the program.
4. Performance: It is measured by processing speed, response time, resource consumption, throughout and
efficiency.
5. Supportability: It combines the ability to extend the program (extensibility), adaptability, serviceability,
which represent maintainability of the project.

These quality attributes must be considered as soon as design commences, but not after the design is
complete and construction has begun.

DESIGN CONCEPTS

Fundamental software design concepts provide necessary framework for "getting it right".

1. Abstraction: At highest level of abstraction, a solution for design problem is stated in broad terms using
language of the problem environment. At lower levels of abstraction, a more detailed description of
solution is provided.
 A data abstraction is a named collection of data that describes a data object.
 A procedural abstraction refers to a sequence of instructions that have a specific and limited function.
Name of procedural abstraction implies these functions, but specific details are suppressed.

2. Architecture: It is the structure or organization of program components (modules), their interaction, and
structure of data that are used by components. "Components can be generalized to represent major
system elements & their interactions.
A set of architectural patterns enable a software engineer to reuse design level concepts. One goal of
software design is to derive an architectural rendering of a system, which serves as a framework to conduct
detailed design activities.
Architectural design can be represented using one or more of a number of different models:
1. Structural models: Represent architecture as collection of program components.
2. Framework models: Increase the level of design abstraction by attempting to identify repeatable
architectural design frameworks that are encountered in similar types of applications.
3. Dynamic models: Address behavioral change aspects of program architecture.
4. Process models: Focus on design of business or technical process that the system must accommodate.
5. Functional models: Can be used to represent functional hierarchy of a system.

18
3. Patterns:"A design pattern describes a design structure that solves a particular design problem within a
specific context amid "forces"(constraints) that may have an impact on the manner in which pattern is
applied and used."
Intent of each design pattern is to provide a description that enables a designer to determine:
i. Whether pattern is applicable to the current work.
ii. Whether pattern can be reused (hence, saving design time)
iii. Whether pattern can serve as a guide for developing a similar, but functionally or structurally
different pattern.

4. Modularity: Software architecture and design patterns embody modularity, i.e., software is divided into
separately named and addressable components, sometimes called modules that are integrated to satisfy
problem requirements.
Modularity is the single attribute of software that allows a program to the intellectually manageable
(by breaking big process into modules). Modularity leads to a "divide and conquer" strategy, it’s easier to
solve a complex problem when you break it into manageable pieces, hence effort required to develop
becomes negligibly small.
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 maintenance can be conducted without serious side effects.

5. Information Hiding: It suggests that "modules should be specified and designed so that information
(algorithms, data) contained within a module is inaccessible to other modules that have no need for such
information."
Hiding defines and enforces access constraints to both procedural detail within a module and any
local data structure used by the module. As most data and procedure are hidden from other parts of the
software, errors during modification are less likely to propagate to other locations within the software.

6. Functional Independence: It is achieved by developing modules with "single-minded" function and an

"aversion" to excessive interaction with other modules.
Functional independence is a key to good design and design is the key to software quality. Independence
is assessed using two qualitative criteria:
 Cohesion: Cohesion is an indication of relative functional strength of a module. A cohesive module
performs a single task, requiring little interaction with other components.
 Coupling: Coupling is an indication of interconnection among modules in software architecture.
Coupling depends on the interface complexity between modules.

7. Refinement: Stepwise refinement is a top-down design strategy, which is actually a process of

elaboration. A program is developed by successively refining levels of procedural detail.
It defines/begins with a statement of function that is defined at a high level of abstraction.
Refinement helps the designer to reveal low-level details as design progresses, thus in creating a
complete design model.

19
8. Refactoring: “Refactoring is the process of changing a software system in such a way that it does not
alter external behavior of the code (design) yet improves its internal structure”.
When software is refactored, the existing design is examined for redundancy, unused design
elements, poorly constructed data structures, unnecessary algorithms etc for better design.

9. Design Classes: As the design model evolves, the software team must define a set of design classes that:
 Refine analysis classes by providing design detail that will enable the classes to be implemented.
 Create a new set of design classes that implement a software infrastructure to support the business
solution.
Design classes provide more technical detail as a guide for implementation. Five different types of
design classes, each representing a different layer of design architecture are suggested. They are:
1. User Interface Classes: These define all abstractions that are necessary for Human Computer Interaction
(HCI). HCI occurs within context of a metaphor (Ex: Order form, a checkbook) and design classes for
interface may be visual representations of elements of metaphor.
2. Business Domain Classes: These are often refinements of the analysis classes defined earlier. The classes
identify attributes and services (operations) that are required to implement some element of the business
domain.
3. Process Classes: These implement lower-level business abstractions required to fully manage business
domain classes.
4. Persistent Classes: These represent data stores (DBs) that will persist beyond execution of the software.
5. System Classes: These implement software management and control functions that enable system to
operate and communicate. These are also known as supporting classes.
As design model evolves, software team must develop a complete set of attributes and operations for each
design class.

Four characteristics of a well-formed design class:

1. Complete and Sufficient: A design class should be the complete encapsulation of all attributes and methods
that can reasonably be expected to exist for the class. Sufficiency ensures that the design class contains only those
methods that are sufficient to achieve the intent of the class.(No more and No less).
2. Primitiveness: Methods associated with a design class should be focused on accomplishing one service
the class. Once the service has been implemented, with a method, the class should not provide another
way to accomplish same thing.
3. High Cohesion: A cohesion design class has a small, focused set of responsibilities and single- mindedly
applies attributes and methods to implement those responsibilities.
4. Low Coupling: Collaboration between design classes should be kept to an acceptable minimum. If a
design model is highly coupled, system is difficult to implement, test & maintain. So, design classes in a
subsystem should have only limited knowledge of classes in other subsystems. It is also called as "Law of
Demeter", suggests that a method should only send messages to methods in neighboring classes.

20
THE DESIGN MODEL

The design model can be viewed in two different dimensions:

 The process dimension indicates evolution of design model as design tasks are executed as part of the
software process.
 The abstraction dimension represents level of detail as each element of analysis model is transformed
into a design equivalent and then refined iteratively.

Fig: Dimensions of the Design Model

21
The elements of design model use many of same UML diagrams that were used in analysis model..The
difference is that these diagrams are refined and elaborated as part of design, more implementation- specific
detail is provided and emphasis is on architectural structure and style, components & interfaces.

Elements of design model:

1. Data Design Elements: Data design also sometimes referred as "Data Architecting". Data design creates
a model of data and/or information that is represented at a high level of abstraction.
In many software applications, architecture of data will have a profound influence on architecture of
software that must process it. Structure of data always plays important role in software design.
 At program component level, design of data structures and associated algorithms required to
manipulate them is essential to the creation of high-quality applications.
 At application level, translation of data model into a DB is important to achieve business objectives.
 At business level, collection of information stored in DBs and reorganized into a "data warehouse"
enables data mining or knowledge discovery.

2. Architectural Design Elements: These give us an overall view of the software. It is derived from 3
sources:
i.Information about application domain for software to be built.
ii.Specific analysis model elements such as DFDs or analysis classes, their relationships and
collaborations for the problem.
iii.Availability of architectural patterns and styles.

3. Interface Design Elements: These tell how information flows into and out of the system and how it is
communicated among components designed as part of the architecture. There are 3 important elements of
interface design:
i. User Interface (UI): Design of a UI incorporates aesthetic elements (Ex: color, layout, graphics),
ergonomic elements (information layout and placement, navigation), and technical elements (UI
patterns, reusable components). In general, UI is a unique subsystem within overall application architecture.
ii. External interfaces to other systems, devices, networks, other producers/consumers of
information: The design of external interfaces requires definitive information about the entity to
which information is sent or received. In every case, this information should be collected during
Requirement Engineering and verified. This design should incorporate error checking and appropriate security
features.
iii. Internal interfaces between various design components: It is closely aligned with component level
design. Design realizations of analysis classes represent all operations and messaging schemes
required to enable communication and collaboration between operations in various classes.

In some cases, an interface is modeled in same way as a class."An interface is a set of operations that
describes some part of the behavior of a class and provides access to those operations."

22
4. Component-Level Design Elements: Component level for software fully describes the internal detail of
each software component. To accomplish this, component-level design defines detail for all processing
that occurs within a component and an interface that allows access to all component operations.

Design details of a component can be modeled at many different levels of abstraction. An activity
diagram can be used to represent processing logic. Detailed procedural flow for a component can be
represented using either pseudo code or some diagrammatic form.

5. Deployment-Level Design Elements: These indicate how software functionality and subsystems will be
allocated within the physical computing environment that will support the software.
Deployment diagram shows the computing environment but does not explicitly indicate configuration
details. Each instance of deployment is identified.
During design, a UML deployment diagram is first developed, and then refined. In a deployment diagram,
each subsystem would be elaborated to indicate components that it implements.

23
PATTERN-BASED SOFTWARE DESIGN
Throughout the design process, a software engineer should look for every opportunity to reuse existing
design patterns (when they meet needs of the design) rather than creating new ones.
Describing a Design Pattern: Mature engineering disciplines make use of thousands of design patterns, for
things such as buildings, highways, electrical circuits, factories, weapons, computers etc. A description of
design pattern may also consider a set of design forces.
Design forces describe non-functional requirements (Ex: Portability) associated the software for
which the pattern is to be applied. These also define the constraints that may restrict the manner in which
design is to be implemented. Design forces describe the environment and constraints that must exist to make
design pattern applicable.
 Pattern characteristics (classes, responsibilities & collaborations) indicate the attributes of the design that
may be adjusted to enable the pattern to accommodate a variety of problems.
The names of design patterns should be chosen with care and should have a meaningful name.

Using Patterns in Design: Design patterns can be used throughout software design. The problem description
is examined at various levels of abstraction to determine if it is amenable to one or more following types of
patterns:
1. Architectural Patterns: These patterns,
 Define overall structure of the software,
 Indicate relationships among subsystems & software components,
 Define rules for specifying relationships among the elements (class, components, packages, subsystems)
of the architecture.
2. Design Patterns: These patterns address a specific element of the design such as an aggregation of
components to solve some design problem, relationships among components, or mechanisms for
effecting component-to component communication.
3. Coding Patterns: These are also called idioms; these language- specific patterns generally implement an
algorithmic element of a component, a specific interface protocol, or a mechanism for communication
among components.

Each of these pattern types differs in the level of abstraction and degree to which it provides direct guidance
for construction activity of software process.

Frameworks: “A framework is not an architectural pattern, but rather a skeleton with a collection of "plug
points" (also called hooks and slots) that enable it to be adapted to a specific problem-domain."
Plug points enable designer to integrate problem specific classes or functionality within the skeleton.
In O-O context, framework is collection of co-operating classes.
 To be most effective, frameworks are applied with no changes, additional design elements may be added,
but only via plug points that allow designer to flesh out the framework selection.

24
Creating Architectural Design: Software architecture, Data design, Architectural Styles and Patterns,
Architectural Design, Assessing alternative Architectural Designs, Mapping data flow into software
Architecture.
________________________________________________________________________________________.
CREATING AN ARCHITECTURAL DESIGN
SOFWARE ARCHITECTURE
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”.
The software architecture of a computing system is the structure of the system, which comprise
software components, externally visible properties of those components and the relationships among them.
Architecture is representation that enables software engineer to,
1. Analyze effectiveness of design in meeting its stated requirements.
2. Consider architectural alternatives at a stage when making design changes is still relatively easy.
3. Reduce the risks associated with the construction of software.
 In the context of architectural design, a software component can be as simple as a program module, a class
or a database.

Why is Architecture Important? The three key reasons that software architecture is important are:
1. Representations of software architecture are an enabler for communication between all parties
(stakeholders) interested in dev of a computer-based system.
2. Architecture highlights early design decisions that will have a profound impact on all software
engineering work and on ultimate success of system.
3. Architecture “constitutes a relatively smalls intellectually graspable model of how system is structured
and how its components work together.
 Architectural styles and patterns can be applied to the design of other systems and represent a set of
abstractions that enable software engineers to describe architecture inpredictable ways.

DATA DESIGN
Data Design actions translate data objects as part of the analysis model into DSS at software component level,
and when necessary, a database architecture at application level.

Data Design at the Architectural Level: In today’s software business environment, where a lot of data and
databases are used, the challenge is to extract useful information, particularly when information desired is
cross- functional.

1
 To solve this challenge, business IT community has developed Data Mining techniques, also called
Knowledge Discovery in Databases (KDD), that navigate through existing databases to extract appropriate
business level in formation.
 An alternative solution, called a Data Warehouse is a large, independent database that has access to data
that are stored in databases that serve set of applications required by a business.

Data Design at the Component Level: Data design at the component level focuses on representation of data
structures that are directly accessed by one or more software components.

 In actuality, data design begins during creation of analysis model.

Set of Principles for Data Specification are:

1. The systematic analysis principles applied to functions and behavior should also be applied to data:
Representations of data flow and content should also be developed and reviewed, data objects should
be identified, alternative data organizations should be considered, and impact of data modeling on
software design should be evaluated.
2. All Data Structure and operations to be performed on each should be identified: Design of an
efficient data structure (DS) must take the operations to be performed into account. The attributes and
operations encapsulated within a class satisfy this principle.
3. A mechanism for defining content of each data object should be established and used to define both
data and operations applied to it: Class diagrams define the attributes contained within a class and
operations that are applied to attributes.
4. Low-level data design decisions should be deferred until late in the design process: Overall data
organization may be defined during requirements analysis, refined during data design work, and
specified in detail during component- level design.
5. The representation of a data structure should be known only to those modulesthat must make direct
use of data contained within the structure: Concepts of information hiding and coupling provide
important insight into the quality of a software design.
6. A library of useful DS and operations that may be applied to them should be developed: A class
library achieves this principle.
7. A software design and programming language should support the specification and realization of
abstract data types: The implementation of a sophisticated data structure can be made exceedingly
difficult if no means for direct specification of structure exists in programming language chosen for
implementation
These principles form a basis for a component level data design approach, that can be integrated in to both
analysis and design activities.

2
ARCHITECTURAL STYLES AND PATTERNS

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 style describes a system category that encompasses:

1. A set of components (Ex: database, computational modules) that perform a function required by a system.
2. A set of connectors that enable “communication, coordination, and cooperation” among components.
3. Constraints that define how components can be integrated to form system.
4. Semantic models that enable a designer to understand overall properties of a system by analyzing know
properties its constituent parts.

An architectural pattern, like an architectural style, imposes a transformation on the design of an entire system.
A Pattern differs from a style in number of fundamental ways:

 Scope of a pattern is less broad, focusing on one aspect of the architecture, rather than architecture entirely.
 A pattern will describe how software handles some aspect of its functionality at the infrastructure level.
 Architectural patterns bend to address specific behavioral issues within the context of architecture (Ex:
Interrupts)

ARCHITECTURAL STYLES:

1. Data-Centered Architecture: A data store (Ex: Database) resides at the center of this architecture and is
accessed frequently by other components that update, add, delete, or modify data within the store.

Fig: Data-Centered Architecture

Client software access a central repository. It accesses data independent of any changes to data/actions of other
client software. A data-centered architecture promotes inerrability. i.e., existing components can be changed
and new client components added to the architecture without concern about other clients. Client components
independently execute processes.
3
2. Data-Flow Architecture: This architecture is applied when input data are to be transformed through a
series of computational (or manipulative) components in to output data.
A pipe and filter structure has a set of components called filters, connected by pipes that transmit data
from one component to the next. Each filter works independently and produces data output of a specified
form.

Fig: Data-Flow Architecture

If the data flow degenerates into a single line of transforms, it is termed “batch sequential”. This structure
accepts a batch of data and then applies a series of sequential components to transform it.

3. Call and Return Architecture: It enables a software designer (system architect) to achieve a program
structure that is relatively easy to modify and scale.
Main program/subprogram Architecture: The classic program structure decomposes function into a
control hierarchy, where a “main” program invokes no of program components, which in turn may invoke
still other components.

Fig: Main Program/Subprogram Architecture

Remote Procedure Call Architecture: The components of main program/subprogram architecture are
distributed across multiple computers on a network.

4
4. Object-Oriented Architecture: Components of a system encapsulate data and the operations that must be
applied to manipulate the data communication and coordination between components is accomplished via
message passing.

Fig: Object-Oriented Architecture

5. Layered Architecture: In this architecture, a number of different layers are defined, each accomplishing
operations that progressively become closer to the machine instruction set.

Fig: Layered Architecture

 At outer layer, components service under UI operations.

 At the inner layer, components perform OS interfacing.
 Intermediate layers provide utility services and application software functions.
 Once requirements engineering uncovers the characteristics and constraints of the system to be built,
the architectural style or combination of styles that best fits can be chosen.

5
Architectural Patterns: “Architectural patterns define a specific approach for handling some behavioral
characteristic of the system”. Some domains can be:
1. Concurrency: Many applications must handle multiple tasks in a manner that simulates parallelism. There
are a number of different approaches to handle concurrency.
i. Operating System Process Management Patterns: It provides built in operating system features that
allow components to execute concurrently. Pattern also incorporates operating system functionality
that manages the communication between processes, scheduling and other capabilities required to
achieve concurrency.
ii. Task Scheduler at application level: This pattern contains a set of active objects each contains a tick ()
operation, which performs its functions, before returning control back to scheduler.
2. Persistence: Persistent data are stored in a database or file and may be read or modified by other processes
at a later time. TWO architectural patterns are used to achieve persistence.
i. DBMS Pattern: Applies the storage and retrieval capability of a DBMS to the application architecture.
ii. Application Level Persistence Pattern: It builds persistence features into the application architecture.
3. Distribution: Distribution problem addresses the manner in which systems or components within systems
communicate with one another in a distributed environment. Broker pattern addresses this problem.
CORBA is an example for broker pattern.
Broker Pattern: A broker acts as a “middle-man” between the client component and server component. The
client sends a message to the broker, and broker completes connection.

Organization and Refinement: Following questions provide insight into architectural style that has been
derived.
 Control: How is control managed within the architecture? Does a distinct control hierarchy exist? How
do components transfer control within the system? How is control shared among components? What is
the control topology? Is control synchronized (or) do components operate asynchronously?
 Data: How are data communicated between components? Is the data flow continuous? What is the
made of data transfer? Do data components exist? What is the made of data transfer? Do data
components exist? If so, what is their roe? How do functional components interact with data
components? Are data components passive/active?

ARCHITECTURAL DESIGN
As architectural design begins, the software to be developed must be put into context i.e. the design
should define the external entities (other systems, people, and devices) that the software interacts with and the
nature of interaction.
Once context is modeled and all external software interfaces have been described, you can identify a
set of architectural archetypes. An archetype is an abstraction (similar to a class) that represents one element
of system behavior. The set of archetypes provides a collection of abstractions that must be modeled
architecturally if the system is to be constructed, but the archetypes themselves do not provide enough
implementation detail. Therefore, the designer specifies the structure of the system by defining and refining
software components that implement each archetype. This process continues iteratively until a complete
architectural structure has been derived
6
Representing the System in Context: At the architectural design level, a software architect uses an
Architectural Context Diagram (ACD) to model the manner in which software interacts with external ent ities
to its boundaries.

Fig: Architectural Context Diagram

Referring to the figure, systems that incorporate with the target system are represented as:

1. Superordinate Systems: Those systems that use the target system as part of some higher level processing
scheme.
2. Subordinate Systems: Systems that are used by target system and provide data or processing that are
necessary to complete target system functionality.
3. Peer-Level Systems: Systems that interact on a peer- to – peer basis (i.e. information is produced or
consumed by the peers and the target system)
4. Actors: Entities that interact with the target system by producing/consuming information that is necessary
for requisite processing.

 Each of these external entities communicates with the target system through an interface (small shaded
rectangles in fig). All data that flow into and out of the target system must be identified at this stage.

7
Defining Archetypes: “An archetype is a class or pattern that represents a core abstraction that is critical to the design
of architecture for target system”. Archetypes can be derived by examining the analysis classes.
 Target system architecture is composed of these archetypes, which represent stable elements of the
architecture.
Following archetypes can be defined for an application:
 Node: Represents a cohesive collection of input and output elements of the application.
 Detector: An abstraction that encompasses all sensing equipment that feeds information into target system.
 Indicator: An abstraction that represents all mechanisms for indicating an occurrence of a condition.
 Controller: An abstraction that depicts the mechanism that allows the arming/disarming of a node. If
controllers reside on a network, they have ability to communicate with one another.

Refining the Architecture into Components: As software architecture is refined into components, the
structure of the system begins to emerge. Analysis classes represent entities within the application domain that
must be addressed within the software architecture. So, application domain is one source for derivation and
refinement of components.

Another source is Infrastructure Domain. The architecture must accommodate many infrastructure
components that enable application components, but have no business connection to the application domain.
 Interfaces depicted in ACD imply one or more specialized components that process data that flow across
interface. In some cases, complete subsystem architecture with many components must be designed.

Fig: Refining the Architecture into Components

Describing Instantiations of the System: An actual instantiation of the system architecture is developed,
when further refinement (as all design is iterative), is still necessary. By this, the architecture is applied to a
specific problem with the intent of demonstrating that the structure and components are appropriate.
8
ASSESSING ALTERNATIVE ARCHITECTURAL DESIGNS
Design results in a no of architectural alternatives that are assessed to determine which is the most
appropriate for the problem to be solved.
Architecture Trade-Off Analysis Method: The Software Engineering Institute (SEI) has developed an
Architecture Trade –off Analysis Method (ATAM) that establishes an iterative evaluation process for software
architectures. The design analysis activities that follow are performed iteratively:
1) Collect Scenarios: A set of use-cases is developed to represent the system from the user’s point of view.
2) Elicit Requirements, constraints and Environments Description: This info is required as part of RE and is
used to be certain that all stakeholder concerns have been addressed.
3) Describe architectural styles/patterns that have been chosen to address the scenarios and requirements
4) Evaluate quality Attributes b considering each attribute in isolation: Quality attributes for architecture.
Design assessment includes reliability, performance, security, maintainability, flexibility, testability,
portability, reusability, andinteroperability.
5) Identify the sensitivity of Quality attributes to various architectural attributes for a specific architecture
style: This can be accomplished by making small changes in architecture. Attributes that are significantly
affected by variation in architecture are termed as sensitivity points.
6) Critique candidate Architectures (Developed in step 3) using sensitivity analysis conducted in stem 5:
Once architecture sensitive points have been determined, finding trade-off points is simply the
identification of architecture elements to which multiple attributes are sensitive.
These 6 steps represent first ATAM iteration. Based on results of steps 5 and 6, some architecture
alternatives may be eliminated, one or more of the remaining architectures may be modified and represented in
more detail, and then ATAM steps are reapplied.

Architectural Complexity: A useful technique for assessing the overall complexity of a proposed architecture
to consider dependencies between components within the architecture these dependencies are driven by
information/control flow within the system.
Types of Dependencies:
 Sharing Dependencies: These represent dependence relationships among consumers, who use the same
resource or producers, who produce for the same consumers.
 Flow Dependencies: These represent dependence relations between producers and consumers of resources.
 Constrained Dependencies: These represent constraints on the relative flow of control among a set of
activities.
The sharing and flow dependencies are similar to coupling. Coupling is an important design
concept that is applicable at the architectural level and component level.

Architectural Description Languages (ADL): ADL provides a semantics and syntax for describing software
architecture. ADL should provide the designer with the ability to decompose architecture components,
compose individual components into larger architectural blocks, and represent interfaces between components.
Once descriptive, language – based techniques for architecture design have been established, it is more likely
that effective assessment methods for architectures will be established as the design evolves.

9
MAPPING DATA FLOW INTO A SOFTWARE ARCHITECTURE:
Call and return structure is the mostly commonly used to structure for many types of systems, for architectural
mapping. This mapping technique enables a designer to derive reasonably complex call and return
architectures from DFDS within analysis model. This technique, sometimes called “structured Design.”
 Structured Design is often characterized as a data flow oriented design method, as it provides a convenient
transition from a DFD to software architecture. Type of info flow is the driver for mapping approach.

TRANSACTION FLOW: Information enters the system along paths that transform external data into an
internal form. These paths are identified as incoming flow. At the kernel of software, a transition occurs.
Incoming data are passed through a “transform center” and begin to move along paths that now lead out the
software. Data moving along these paths are called outgoing flow.
 Overall data flow occurs in a sequential manner and follows one, or only a few “straight line” paths. When
a segment of a DFD exhibits these characteristics, Transform Flow is present.

TRANSACTION FLOW: Usually a transaction triggers data flow along one of many paths. 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 paths is initiated. The
hub of information flow from which many action paths emanate is called as “transaction center”.

TRANSFORM MAPPING: Transform Mapping is a set of design steps that allows a DFD with transform
flow characteristics to be mapped into a specific architecture style. To map these DFDs into architecture,
following design steps are initiated.
Step 1: Review the Fundamental System Model: Fundamental system model or context diagram (Level 0
DFD) depicts an operation (function) as a single transformation, representing the external producers and
consumers ofdata that flow into and out of the function.

10
Step 2: Review and Refine DFDs for the Software: Information obtained from analysis models is refined to
produce greater detail. i.e., process implied by a transform performs a single, distinct function that can be
implemented as a component in software.

Step 3: Determine whether DFD has Transform (or) Transaction Flow Characteristics: In general,
information flow within a system can always be rep as transform. However, in this step, designer selects
global (software- wide) flow characteristics based on the prevailing nature of the DFD. Local regions of
transform or transaction flow or isolated. These sub flows can be used to refine program architecture derived
from a global characteristic described earlier. Hence, an overall transform characteristic will be assumed for
information flow.
Step 4: Isolate Transform Center by Specifying Incoming and Outgoing Flow Boundaries: Usually,
incoming and outgoing flow boundaries are open to interpretation. i.e. different designers may select slightly
11
different points in the flow as boundary locations. Proper care should be taken when boundaries are selected; a
variance of one bubble along flow path will have little impact on final program structure.
Step 5: Perform “First-level Factoring”: Factoring results in a program structure in which top-level
components perform decision-making and low-level components perform input, computation and output work.
Middle-level components perform some control and do moderate amounts of work. This type of mapping
results in top-down distribution of control.

In the first-level factoring a main controller resides at the top of the program structure and coordinates the
following subordinate control functions. When transform flow is encountered, a DFD is mapped to a specific
structure (call & return architecture) that provides control for incoming, transform, outgoing information
processing.
 No of modules at first level should be limited to minimum.

Step 6: Perform “Second-Level Factoring”: Second-level factoring is accomplished by mapping individual

transforms (bubbles) of a DFD into appropriate modules within the architecture. Beginning at transform center
boundary and moving outward along incoming and the outgoing paths, transforms are mapped into sub-
ordinate levels of the software structure.
Second-level factoring illustrates a one – to – one mapping between DFD transform and software
modules, different mappings frequently occur. Practical considerations and measures of design quality dictate
the outcome of second-level factoring. Review and refinement may lead to changes in this structure, but it can
serve as a “first- iteration” design.
 Factoring is accomplished by moving outward from the transform center boundary on incoming flow side.
 Components mapped in preceding manner represent an initial design of software architecture.

12
Step 7: Refine First-Iteration Architecture using Design Heuristics for Improved Software Quality: A
first iteration architecture can always be refined by applying concepts of functional independence. Components
are exploded/imploded to produce sensible factoring, good cohesion, minimal coupling and most importantly, a structure
that can be implemented without difficulty, tested without confusion and maintained without grief.
Refinements are dictated by analysis and assessment methods as well as practical considerations and
common sense. Software requirements coupled with human judgment is the final arbiter.

 The objective of preceding seven steps is to develop an architectural representation of software. i.e., once
the structure is defined, we can evaluate and refine software architecture by viewing it as a whole.
 Modifications at this time require little additional work, yet can have a profound impact on software quality.

TRANSACTION MAPPING: In many software applications, a single data item triggers one of a no of
information flows. This data item is called as a transaction.
Design steps for transaction mapping are similar and identical to steps for transform mapping. A major
difference lies in the mapping of DFD to software structure.
Step 1: Review the Fundamental System Model: This step is identical to corresponding step for transform
mapping.
Step 2: Review and Refine DFDs for Software: This step is identical to corresponding step for transform
mapping.
Step 3: Determine whether the DFD has Transform or Transaction Flow Characteristics: This step is
identical to corresponding step in transform mapping. (Refer step 3 in transform mapping). However, flow boundaries
must be established for both flow types.
Step 4: Identify the Transaction Center and Characteristics along each of the Action Paths: The location
of the transaction center can be immediately discerned from the DFD. The transaction center lies at the origin
of a no of action paths that flow radially from it.
The incoming path and all action paths must also be isolated. Each action path must be evaluated for
its individual flow characteristic. Incoming, transform and outgoing flow are indicated with boundaries.

13
Step 5: Map DFD in a Program Structure Amenable to Transaction Processing: The transaction flow is
mapped into an architecture that contains an incoming branch and a dispatch branch. Structure of incoming
branch is developed in much the same way as transform mapping. Starting at transaction center, bubbles along
incoming path are mapped into modules.
Structure of dispatch branch contains a dispatcher module that controls all subordinate action modules.
Each action flow path of DFD is mapped to a structure that corresponds to its specific flow characteristics.
Step 6: Factor and Refine the Transaction Structure and Structure of Each Action Path: Each action
path of DFD has its own information flow characteristics, i.e., transform or transaction flow. The action path –
related “substructure” is developed using the design steps.
Step 7: Refine First – Iteration Architecture Using Design Heuristics for Improved Software Quality:
This step is identical to corresponding step for transform mapping.

In both design approaches, criteria such as module independence, practicality and maintainability must be
carefully considered as structural modifications are proposed.

Refining Architectural Design: Refinement of software architecture during early stages of design is to be
encouraged. The approach for optimization is one of the true benefits derived by developing a representation
of software architecture.
 Structural simplicity reflects both elegance and efficiency.

14