ARCHITECTURAL ARCHITECTURAL DESIGN DESIGN

Why is Architecture Important?Why is Architecture Important?

Representations of software architecture are an Representations of software architecture are an enabler for communication between all parties enabler for communication between all parties (stakeholders) interested in the development of a (stakeholders) interested in the development of a computer-based system.computer-based system.

The architecture highlights early design decisions The architecture highlights early design decisions that will have a profound impact on all software that will have a profound impact on all software engineering work that follows and, as important, on engineering work that follows and, as important, on the ultimate success of the system as an operational the ultimate success of the system as an operational entity.entity.

Architecture “constitutes a relatively small, Architecture “constitutes a relatively small, intellectually graspable model of how the system is intellectually graspable model of how the system is structured and how its components work together” structured and how its components work together” [BAS03].[BAS03].

Architectural design represents the structure of data and program components that are required to build a computer based system.

Architecture is not the operational software. Rather 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 at a stage when making design changes is still relatively easy

(3)Reducing the risks associated with the construction of the software.

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

Like other software engineering activities, data design creates a model of data and/or information that is represented at a high level of abstraction. This data model is then refined into progressively more implementation specific representations that can be processed by the computer based program.

The structure of data has always been an important part of software design. At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. The data design activity translates the elements of the requirements model into data structures at the software component level.

Data DesignData Design

Data DesignData Design

At the architectural level …At the architectural level …• Design of one or more databases to support Design of one or more databases to support

the application architecturethe application architecture• Design of methods for ‘mining’ the content of Design of methods for ‘mining’ the content of

multiple databasesmultiple databases navigate through existing databases in an attempt navigate through existing databases in an attempt

to extract appropriate business-level informationto extract appropriate business-level information Design of a data warehouse—a large, independent Design of a data warehouse—a large, independent

database that has access to the data that are database that has access to the data that are stored in databases that serve the set of stored in databases that serve the set of applications required by a businessapplications required by a business

Data design at the component level focuses on the representation of data structures that are directly accessed by one or more software components. A set of principles can be applied for data design.

1. Systematic analysis principles applied to function and behavior should also be applied to data.

2. All data structures and the operations to be performed on each should be identified.

3. Data dictionary should be established and used to define both data and program 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 must make direct use of the data contained within in the data structure.

6. A library of useful data structures and operations should be developed.

7. A software design and its implementation language should support the specification and realization of abstract data types.

Architectural Styles

The software that is built for computer-based systems exhibits one of the many architectural styles. Each style encompasses

1. a set of components, that perform a function required by the system

2. a set of connectors that enable communication, coordination and cooperation among components

3. constrains that define how components can be integrated to form the system

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

Architectural StylesArchitectural Styles

Data-centered architecturesData-centered architectures Data flow architecturesData flow architectures Call and return architecturesCall and return architectures Object-oriented architecturesObject-oriented architectures Layered architecturesLayered architectures

Data-Centered ArchitectureData-Centered Architecture

A data store resides at the centre of this and is accessed by other components that update, add, delete, modify within the store.

Data Flow ArchitectureData Flow Architecture

This is applied when input data are to be transformed through a series of computational or manipulative components into output data.

Data Flow ArchitectureData Flow Architecture

A pipe and filter pattern has a set of components called filters, connected by pipes that transmit data from one component to the next. Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form and produces data output of a specified form. However, the filter does not require knowledge of the working of its neighboring filters.

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

Call and Return ArchitectureCall and Return Architecture

This style enables a software designer to achieve a program structure that is relatively easy to modify and scale

Mini program/subprogram architectures.Remote procedure call architectures.

Layered ArchitectureLayered Architecture

A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.

Object oriented architectureObject oriented architecture

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

MAPPING

Software requirements can be mapped to various requirements. The transition from information flow to program structure is accomplished as a part of six-step process.

Establish type of information flow Flow boundaries indicated DFD is mapped into program structure Control hierarchy defined Resultant structure refined using design measures and heuristics Architectural description refined and elaborated  

Two type of information flow are transform flow and transaction flow.

In transform flow externalized data must be converted in to an internal form for processing. Information enters the system along paths that transform external data into an internal form and the paths are identified as incoming flow. Data moving along the paths after transformation are called outgoing flow. Overall data flow occurs in a sequential manner.

In transaction flow, information flow is often characterized by a single data item, called transaction, that triggers other data flow along one of many paths.

TRANSFORM MAPPING

It is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style.

Review fundamental system model

Review and refine data flow diagrams for the

software

Determine whether the DFD has transform or

transaction characteristics

Isolate the transform center by specifying incoming

and outgoing flow boundaries

Perform first level factoring

Perform second level factoring

Refine the first iteration architecture using design

heuristics for improved software quality

Transform Transform MappingMapping

data flow model

"Transform" mapping

ab

c

d e fg h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j

FactorinFactoringg

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

First Level First Level FactoringFactoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller

Second Level Second Level MappingMapping

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control

Second level factoring is accomplished by mapping individual transforms of DFD into appropriate modules within the architecture

TRANSACTION MAPPINGReview fundamental system model

Review and refine data flow diagrams for the software

Determine whether the DFD has transform or transaction characteristics

Identify the transaction center and flow characteristics along each action path Map the DFD to a program structure amenable to transaction processing Factor and refine the transaction structure and the structure of each action path Refine the first iteration architecture using design heuristics for improved software quality

OBJECT ORIENTED OBJECT ORIENTED DESIGN DESIGN

Object oriented design transforms the analysis Object oriented design transforms the analysis

model created using object-oriented analysis in to model created using object-oriented analysis in to

a design model that serves as a blueprint for a design model that serves as a blueprint for

software constructionsoftware construction An object-oriented system draws upon class An object-oriented system draws upon class

definitions that are derived from the analysis modeldefinitions that are derived from the analysis model OOD is divided into two major activities OOD is divided into two major activities

• System DesignSystem Design

• Object DesignObject Design

System design defines the product

architecture (the system functions and classes

encapsulated in the subsystems). System design

focuses on the specification of three components:

the user interface, data management functions, and

task management facilities.

Object design focuses on the internal details

of the individual classes and the messaging

scheme. The design specification document form

the SEPA web site is applicable to OOD. The OOD

projects must be reviewed to ensure quality.

Design for Object-oriented System

The conventional Pyramid concept is introduced for

OOD, which contains four layers

Responsibilities layer (highest layer - contains data structure detail and algorithmic detail for each object's attributes and operations)

Message layer (establishes the internal and external interfaces for the system, including the details of communication among object collaborators)

Class and object layer (contains class hierarchy including representations of each object)

Subsystem layer (lowest level - contains representations of each of the subsystems and the necessary infrastructure that enable the software to achieve the customer's requirements)

Object-oriented Design Issues

Decomposability - facility of design method that allows the designer to decompose the problem into easily solved subproblems

Composability - degree to which design method ensures that modules constructed for one project can be reused in another

Understandability - ease with which a component can be understood without examining other components

Continuity - ability to isolate changes made in one module and restrict the propagation of changes to other modules

Protection - architectural characteristic that reduces the propagation of side effects when errors occur

Object-Oriented System Design Process

Partition the analysis model into subsystems.Subsystems should have well defined communication

interfaces with few exceptions classes should collaborate within their subsystem

Keep number of subsystems small partition subsystem internally to reduce complexity

Identify concurrency dictated by the problem. Allocate subsystems to processors and tasks

Allocate each subsystem to an independent processor (or) allocate subsystems to same processor and provide concurrency support through operating system features Develop user interface design

Choose basic strategy for implementing data managementManagement of data critical to the application itself

creation of infrastructure for storage and retrieval of objects

Identify global resources and control mechanisms to access them

Design control mechanism for system (including task management)

Consider how subsystem boundary conditions should be handled

Review and consider trade-offs

The Object Design

Object descriptionsprotocol description - object interface specified by

defining each message an object can receive and the operation triggered by message (or)

implementation description - shows implementation details for each operation implied a message passed to the object

Designing algorithms and data structuresalgorithm categories: data manipulation,

computation, monitors refinement of operation programs defined during OOA

Design optimization

The Object Design

Review object-relationship model to ensure implemented design leads to efficient resource utilization, add redundancy where necessary revise attribute data structures and related operation algorithms to improve processing efficiency create attributes to save derived information and avoid re-computation

Modularity is important aspect of object-oriented design quality (the program design language should support object definition) 

Describing Design Pattern

Design Pattern Specification Components

•Name •Intent •Design forces motivating the pattern •Solution that mitigates these design forces •Classes required to implement the solution •Responsibilities and collaborations among the solution classes •Implementation suggestions •Source code examples or templates •Cross-references to related design patterns