ARCHITECTURAL DESIGN. Why is Architecture Important? Representations of software architecture are an...
-
Upload
eleanore-hamilton -
Category
Documents
-
view
216 -
download
0
Transcript of ARCHITECTURAL DESIGN. Why is Architecture Important? Representations of software architecture are an...
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