Architectural Design

Software Engineering: A Practitioners Approach, 6/e
Chapter 10 Architectural Design

copyright 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Why Architecture?
The 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, and (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 (stakeholders) 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 [BAS03].
Data Design
At the architectural level
Design of one or more databases to support the application architecture Design of methods for mining the content of multiple databases
navigate through existing databases in an attempt to extract appropriate business-level information Design of a data warehousea large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business
Data Design
At the component level
refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established simplify data structures as required
Data DesignComponent Level

1. The 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. A data dictionary should be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late in the design process. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types.
Architectural Styles
Each style describes a system category that encompasses: (1) a set of components (e.g., a 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 the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures
Data-Centered Architecture
Data Flow Architecture
Call and Return Architecture
10
Layered Architecture
11
Architectural Patterns
Concurrencyapplications must handle multiple tasks in a manner that simulates parallelism

operating system process management pattern task scheduler pattern
PersistenceData persists if it survives past the execution of the process that created it. Two patterns are common:
a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture
an application level persistence pattern that builds persistence features into the application architecture
Distribution the manner in which systems or components within systems communicate with one another in a distributed environment
A broker acts as a middle-man between the client component and a server component.
12
Architectural Design
The software must be placed into context
the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction An archetype is an abstraction (similar to a class) that represents one element of system behavior
A set of architectural archetypes should be identified
The designer specifies the structure of the system by defining and refining software components that implement each archetype
13
Architectural Context
Safehome Pro duct Internet-based system
control panel
target system: Security Function uses
uses
surveillance function peers
homeowner
uses
sensors
sensors
A system context diagram accomplishes this requirement by representing the flow of information into and out of the system , user interface and relevant support processing.
14
Component Structure
SafeHome Execut ive Funct ion select ion
Ext ernal Communicat ion Management
Securit y
Surveillance
Home management
GUI
Int ernet Int erface

Cont rol panel processing det ect or management alarm processing
15
Refined Component Structure

SafeHome Executive
Ext ernal Communicat ion Management
Security GUI Internet Interface

Co n t ro l p an e l p ro ce ssin g d e t e ct o r m an ag e m e n t alarm p ro ce ssin g
Ke y p ad p ro ce ssin g
sch e d u le r
phone co m m u n icat io n
CP d isp lay fu n ct io n s
alarm se n so se so r se n so r se n n so r se n so r se n so r se n so rr se n so r se n so r
16
Analyzing Architectural Design

1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: module view process view data flow view 4. Evaluate quality attributes by considered each attribute in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.
17
An Architectural Design Method

customer requirements
"four bedrooms, three baths, lots of glass ..."
architectural design
18
Partitioning the Architecture
horizontal and vertical partitioning are required
19
Horizontal Partitioning
define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions
function 1
function 3
function 2
20
Vertical Partitioning: Factoring
design so that decision making and work are stratified decision making modules should reside at the top of the architecture decision-makers
workers
21
Why Partitioned Architecture?

results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend
22
Flow Characteristics
Transform flow
Transaction flow
23
General Mapping Approach

isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules
add control modules as required

refine the resultant program structure using effective modularity concepts
24
Transform Mapping
a b d c data flow model x1 x2 b a c d x3 e f g h x4 i j e f g i h
"Transform" mapping
25
Factoring
direction of increasing decision making typical "decision making" modules
typical "worker" modules

26
First Level Factoring

main program controller
input controller
processing controller
output controller
27
Second Level Mapping

D C
control main
A A B C
mapping from the flow boundary outward
28
Transaction Flow
incoming flow
action path T
29
Transaction Example
fixture setting commands operator
process operator commands
fixture servos
report
display screen
robot control
robot control software

assembly record in reality, other commands would also be shown
30
Transaction Mapping Principles

isolate the incoming flow path
define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path
define the dispatch and control structure
map each action path flow individually
31
Transaction Mapping
a b t g h j m x1 b a d x2 e f g t x3 h i k
e d i
data flow model
Mapping
x4
x3.1 j
32
Isolate Flow Paths

co mmand prod uce error msg read co mmand i nva li d co mmand co mmand va li da te co mmand de te rmi ne type error msg sta tus de te rmi ne setti ng read fixtu re sta tus co mbi ned sta tus format setti ng raw se tti ng fixtu re settin g
robo t co ntro l
read reco rd
reco rd ca lcul ate ou tp ut va lu es va lu es
send co ntro l va lu e asse mbl y reco rd sta rt /sto p
format repo rt
repo rt
33
Map the Flow Model

process operator commands
command input controller read command validate command produce error message fixture status controller
determine type
report generation controller
send control value
each of the action paths must be expanded further
34
Refining the Structure Chart

process operator commands command input controller read command validate command produce error message fixture status controller determine type
report generation controller
send control value
read fixture status
determine setting
format setting
read record
calculate output values
format report
35

Architectural Design

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architectural Design

Transféré par

Droits d'auteur :

Formats disponibles

Software Engineering: A Practitioners Approach, 6/e

Chapter 10 Architectural Design

R.S. Pressman & Associates, Inc.

Why is Architecture Important?

At the architectural level

At the component level

Data DesignComponent Level

Data Flow Architecture

Call and Return Architecture

Concurrencyapplications must handle multiple tasks in a manner that simulates parallelism

operating system process management pattern task scheduler pattern

The software must be placed into context

A set of architectural archetypes should be identified

target system: Security Function uses

surveillance function peers

Ext ernal Communicat ion Management

Int ernet Int erface

Refined Component Structure

Security GUI Internet Interface

Analyzing Architectural Design

An Architectural Design Method

Partitioning the Architecture

horizontal and vertical partitioning are required

Vertical Partitioning: Factoring

Why Partitioned Architecture?

General Mapping Approach

add control modules as required

typical "worker" modules

First Level Factoring

Second Level Mapping

mapping from the flow boundary outward

robot control software

Transaction Mapping Principles

map each action path flow individually

data flow model

Isolate Flow Paths

reco rd ca lcul ate ou tp ut va lu es va lu es

send co ntro l va lu e asse mbl y reco rd sta rt /sto p

Map the Flow Model

report generation controller

send control value

each of the action paths must be expanded further

Refining the Structure Chart

report generation controller

send control value

read fixture status

calculate output values

Vous aimerez peut-être aussi