Creating an Architectural Design

Chapter – 10
 Introduction
• Architectural design represents
• Structure of the data + program components required to
build a computer-based system.
• Begins with data design and proceeds to the derivation of
one or more representations of the architectural structure
of the system.
• The resulting architectural model:
- Encompasses both the data architecture +program
structure.
• Alternative architectural patterns are analyzed
• to determine the structure - best suited to the customer's
requirements.
• Architectural model is subjected to software quality
review
 What is software Architecture
• Contains various components, with visible properties of
those components and relationships among them.
(Various components are integrated to form a cohesive whole)
• Architectural level – details of algorithm not given
• Overall shape of the physical structure

It is a representation that enables a software engineer to:

(1) analyze the effectiveness of the design in meeting its
stated requirements
(2) consider architectural alternatives
(design changes is easy)
(3) reduce the risks associated with the construction of the
software.
 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 a important, on the 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.
 What is software Architecture
Software architecture considers two levels of design:
1. Data Design – action translates data objects defined as
part of the analysis model into data structures at the
software component level and when necessary, a
database architecture at the application level.
2. Architectural design – representation of the structure
of software components, their properties and relations
 Data Design
Data Design at the architectural level
• In large businesses, the challenge is to extract useful
information from the data environment.
• To solve these challenges data mining techniques were
developed (Knowledge Discovery in Databases).
Data Mining:
• It navigates through existing databases in an attempt to
extract appropriate business level information.
• But these databases would have different structures
• the degree of details may be different
• data mining becomes difficult.
 Data Mining
• Data mining (sometimes called data or knowledge
discovery) is the process of analyzing data from different
perspectives and summarizing it into useful information
• information that can be used to increase revenue, cuts costs, or
both.
• Data mining software is one of a number of analytical
tools for analyzing data.
• It allows users to analyze data from many different
dimensions or angles, categorize it, and summarize the
relationships identified.
• Technically, data mining is the process of finding
correlations or patterns among dozens of fields in large
relational databases.
 Data Design
Data Warehousing
• Warehouse – storage place, depository
• It adds another layer to the data architecture on top
of databases.
• Data warehouse is a separate data environment
encompasses all data used by business.
• It is a large, independent database that encompasses
some, but not all, of the data that are stored in databases
used by individual applications.
• Many characteristics are different from regular databases.
• They are subjected to orientation, integration, time
variancy, non-volatility.
 DATA WAREHOUSING
• A data warehouse is essentially a set of hardware
and software components that are used to analyze
in a more effective manner, the massive amount of
data that an organization has accumulated, and
thereby facilitate sound business decisions.
• Data in a Data Warehouse is extracted from
heterogeneous sources as and when it is generated.
• Data Warehousing is a method of extracting useful
information from on-line / off-line databases for
the purpose of decision support and analysis.
• Data Warehousing is a concept.
 Data design at the component level
• Focuses on the representation of data structures that are
directly accessed by software components.
Principles for data specification and design:
1. Systematic analysis principles applied to function and
behavior should also be applied to data.
(data object identified, alternative data organizations should be
considered)
2. All data structures and the operations to be performed on
each should be identified.
(efficient data structure picked)
3. Data dictionary should be established and used to define
both data and program design.
(define the data items within the class & processing applied
to data items)
 Data design at the component level
Principles for data specification and design:
4. Low level design processes should be deferred
until late in the design process.
5. Representations of data structure should be
known only to those modules that makes use of
it.(information hiding)
6. A library of useful data structures and operations
should be developed. (class libraries)
7. A software design and its implementation
language should support the specification and
realization of abstract data types
 Architectural Style and Patterns
• Software built for computer-based systems also
exhibits one of many architectural styles
Architectural Style Elements:
1. Set of components
2. Set of connections - that enable communication,
coordination, and cooperation among components
3. Constraints defining - how components can be
integrated to form the system
4. Semantic models - enable designers to understand
the overall system properties by analyzing
properties of its constituent parts
•
Architectural Style 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.
• An architectural pattern, imposes a transformation on the
design of an architecture.
• However, a pattern differs from a style in a number of
fundamental ways,
• Scope of a pattern is less broad focusing on one aspect of the
architecture rather than the architecture in its entirety.
• Patterns imposes rules on the architecture, describing how the
software will handle some aspect of its functionality at the
infrastructure level
• Architectural patterns tend to address specific behavioral issues
within the context of the architecture.
 Architectural Styles
1.Data centered:
• A data-store (file or database) resides at the center of
architecture and is accessed frequently by other components
• that update, delete, or modify data within the store.
• The client software accesses a central repository.
• (Railway reservation system)
• This style promotes integrability
- existing components can be changed
- new client components can be added to the architecture
without concern about other clients
- The client components operate independently.
Data-Centered Architecture
 Architectural
2.Data flow architecture:
Styles
Input data is transformed by a series of computational or
manipulative components into output data
This style described as a pipe and filter pattern:
• Components are called filters, transforms data and transmit
them through the pipes to the next filter.
• Each filter works independently of those components
• It expects data input and generates output in specified form.
• It does not require knowledge of the working of its
neighboring filters.
• If the data flow degenerates a single line of transforms -
batch sequential.
• This pattern accepts a batch of data and then applies a series
of sequential components (filters) to transform it.
• (There is no data flow in data-centered architecture. Data
stay in the center they do not flow.)
Data Flow Architecture
 Architectural Styles
3.Call and return architecture
• Enables software designer to achieve a program
structure relatively easy to modify and scale
Sub-styles
• Main program / subprogram architectures:
• the program structure is decomposed into a control
hierarchy
• i.e. a main program invokes a number of program
components which in turn may invoke still other
components.
• Remote procedure call architectures:
• the components of the main program / subprogram are
distributed across multiple computers on a network.
Call and Return Architecture
 Architectural Styles
4.Object oriented architectures
- Encapsulate data and the operations that must be applied
to manipulate the data.
- Communication and coordination between components is
accomplished by message passing.
5.Layered architectures:
• Number of different layers are defined
• Each accomplishing operations that progressively become
closer to the machine instruction set
• Outer layer - components service user interface operations.
• Inner layer - components perform OS interfacing.
• Intermediate layers - provide utility services and application
software functions.
Layered Architecture
 Architectural Patterns
• Architectural patterns for software defines a
specific approach for handling some behavioral
characteristics of the system.
• Few architectural pattern domains are
• Concurrency
• Persistence
• Distributions
 Architectural Design
• Software to be developed must be put into context
(i.e., define external entities and define the nature of
interactions)
• Information acquired – In analysis model
Information gathered – In requirement engineering
• Define and refine software components that implement
architecture
• Continue process iteratively - until complete architectural
structure has been derived.
 Architectural Design
Representing the System in Context:
• System engineer must model the context
• Context diagram - models in which the system
interacts with external entities
(Uses ACD – Architectural Context diagram)
(Input, Output, User interface, Processing)
 Architectural Design
• Systems that interoperate with the target system are represented as:
• Super ordinate systems - using the target system as part of some
higher level processing scheme
• Subordinate systems - used by the target system to provide data
or processing needed to complete the target system
• Peer level systems - producing or consuming information needed
by peers and the target system
• Actors – those entities that interact with the target system by
producing or consuming information that is necessary for requisite.
• Interfaces must be defined (relationship)
• All the data that flow into or out of the target system must be
identified
 Architectural Design
Super ordinate system

Used by

Target System

Peers
Actors Used Depends on

Subordinate systems
 Architectural Design

Safe home Internet based

Product product
Used by

Control
Panel Target System Surveillance
Security function
Home Function
owners
Uses Uses
Actors Uses

Sensors Sensors
• Defining Archetypes
• 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.
• The target system architecture is composed of these
archetypes, which represent stable elements of the
architecture but may be instantiated in many different
ways.
• The following archetypes are
• Node – represents a collection of input and output elements
• Detector – an abstraction that encompasses all information into
the target system
• Indicator – an abstraction that represents all mechanisms for
indication
• Controller – an abstraction that depicts the mechanism that
allows the arming & disarming of a node.
 Assessing alternative architectural designs
• Architectural style depends on - requirements.
• Combine different styles, derive - a new design that
best fits the requirements.
• Number of alternatives which fit the requirements.
• Assess different alternatives by asking questions
regarding data and controls.
• Preliminary idea regarding - quality of design.
 Assessing alternative architectural designs
Architecture Trade-off Analysis Method (ATAM) :
 Developed by Software Engineering Institute (SEI)
 Iterative process
 Perform required activities in sequence
1. Collect scenarios
- Use Cases are developed to represent the system from the
user’s point of view.
2. Elicit requirements, constraints, and environmental
description
- Information required for requirement engineering
3. Describe architectural styles/patterns chosen to
address scenarios and requirements
- (module view, process view, data flow view)
 Assessing alternative architectural designs
4. Evaluate quality attributes independently
- e.g., reliability, performance, security, maintainability,
flexibility, testability, portability, reusability,
interoperability)
4. Identify sensitivity points for architecture
- any attributes significantly affected by variation in the
architecture
4. Critique candidate architectures (from step 3)
using the sensitivity analysis (conducted in step 5)
 Assessing alternative architectural designs
• Dependencies between components within the architecture
• Dependencies – information /control flow between systems
• Architectural Complexity (similar to coupling)
• Sharing dependencies:
- dependence relationships among consumers
- who use the same resource or producers
- who produce for the same consumers
• Flow dependencies:
• Relationships between producers & consumers of
resources
• Constrained dependencies :
• The relative flow among a set of components
 Assessing alternative architectural designs
Architectural Description Language (ADL)
• Provides syntax and semantics for describing
software architecture
• Provides designers
• with ability to decompose components
• Compose individual components into large components
• Combines components
• define interfaces between components (connection)
Mapping Requirements to Software Architecture
Transition from DFD to program structure is as :
1. The type of information flow is established.
2. Flow boundaries are indicated.
3. DFD is mapped into program structure.
4. Control hierarchy is defined.
5. Resultant structure refined using design measures
6. Architectural description is refined and elaborated
Mapping Requirements to Software Architecture
The whole method is called information flow.
There are two types of flows:
1. Transform flow
2. Transaction flow
• Transform flow - data flow is sequential & flows
in small number of straight line paths;
• Transaction flow - a single data item triggers
information flow along one of many paths
Mapping Requirements to Software Architecture
Transform Flow:
• Information enters and exits the software in an “external
form”
( i.e. data typed on a keyboard, voice commands to voice
recognition systems, tones on a telephone line)
• This form of data cannot be understood by the software
• Externalized data converted into an internal form for
processing.
(External data  Internal data)
• Data enters the software converted into internal form,
processed (transformed) and converted into external form to
interact with the outside world.
(Data  enters s/w  internal form  processed  external)
Mapping Requirements to Software Architecture
• Two paths for conversion of data:
• Incoming path (path that does conversion of incoming
data is called incoming flow )
• Outgoing path (path that converts data for sending out is
called outgoing flow
• Central part:
• does actual processing (transformation) called transform
center.
• Overall flow of data in a sequential manner
• Follows one, or only few, “straight line” paths.
Mapping Requirements to Software Architecture
Transaction Flow:
• Flows a single data item, called a transaction, but
• Triggers data flow along one of many paths i.e. there is
branching.
• Data moving along an incoming path that converts external
world information into a transaction.
• Transaction evaluated based on its value, flow along one of
many action paths is initiated.
• Information flow - many action paths emanate called
transaction center.
Eg: Receives a user command - control panel.
Depending on command there are: three different paths
flow will continue.
 Mapping Requirements to Software Architecture
• DFD for large systems – transform + transaction
• Within a transaction flow we have one action path which
would have transform flow.
• Eg, Process password action path in the user interaction
subsystem shows transform flow characteristics.

Transaction Flow
Mapping Requirements to Software Architecture
Transform mapping
• A set of design steps allows DFD with transform flow
characteristics to be mapped into a specific architectural
style.
Design steps:
1. Review the fundamental system model
- Data flow into and out of the function
- i.e. consider the level 0 and level 1 DFD.
2. Review and refine DFD for the software:
- Information from analysis model refined
- i.e. refine DFD to get level 2 and 3 DFD.
- At level 3 of DFD:
- each transform exhibits high level of cohesion
- process implied by a transform performs a single function
that can be implemented as a component.
Mapping Requirements to Software Architecture
3. Determine whether the DFD has transform or
transaction flow characteristics:
- Incoming data: only one
- outgoing : appears to be three
(i) alarm condition
(ii) second one is for display (Sensor, telephone)
- so action path is only one.
- Hence it can be considered as transform flow.
4. Isolate the transform center by specifying
incoming and outgoing boundaries:
Mapping Requirements to Software Architecture
5. Perform “first level factoring”:
- We know that there is transform flow
- We divide structure in 3 different controls
(i) incoming path
(ii) transform
(iii) outgoing path.
- One main controller called monitor sensors
executive which controls and supervises three
controllers
(sensor input controller, alarm conditions controller
and alarm output controller)
 Mapping Requirements to Software Architecture

Monitor
sensors
Second level factoring
executive
For monitor sensors

Monitor
Sensor Alarm Alarm sensors
input Conditions Output executive
controller controller controller

First level factoring Sensor Alarm Alarm

For monitor sensors input Conditions Output
controller controller controller

Format Generate Connection

Display alarm To phone

Generate
Generate
Pulses
display
Mapping Requirements to Software Architecture
6. Perform second level factoring:
- Assign one program component to each bubble
- Decide the modules which are going to do actual
work.
- Using controls decided in the first level of
factoring
- Worker modules decided in the second level of
factoring
- Decide the complete program structure.
- This is the first iteration architecture.
Mapping Requirements to Software Architecture
7. Refine the first iteration architecture using design
heuristics for improved software quality:
• Refinement modules are to produce
• sensible factoring
• good cohesion
• minimal coupling
• a structure that can be implemented without difficulty
• tested without confusion
• maintained
• Sensor input controller and Alarm conditions controller
are removed and Format display and generate display are
combined to give Produce display.