Pressman Ch 10 Architectural Style

8/18/2019 Pressman Ch 10 Architectural Style

1/44

1

Definitions

• The software architecture of a program or computing system is the structureor structures of the system which comprise

– The software components

– The externally visible properties of those components

– The relationships among the components• Software architectural design represents the structure of the data and program

components that are required to build a computer-based system

• n architectural design model is transferable

– !t can be applied to the design of other systems

– !t represents a set of abstractions that enable software engineers to describearchitecture in predictable ways


2/44

"

rchitectural Design #rocess

• $asic Steps

– %reation of the data design

– Derivation of one or more representations of the architectural structure of thesystem

– nalysis of alternative architectural styles to choose the one best suited to

customer requirements and quality attributes – &laboration of the architecture based on the selected architectural style

• database designer creates the data architecture for a system to represent thedata components

• system architect selects an appropriate architectural style derived during

system engineering and software requirements analysis


3/44

'

!mportance of Software

rchitecture

• (epresentations of software architecture are an enabler for

communication between all sta)eholders interested in the development

of a computer-based system

• The software architecture highlights early design decisions that willhave a profound impact on all software engineering wor) that follows

and* as important* on the ultimate success of the system as an

operational entity

• The software architecture constitutes a relatively small* intellectually

graspable model of how the system is structured and how itscomponents wor) together


4/44

+

&xample Software rchitecture Diagrams


5/44

Software rchitectural Styles


6/44

,

%ommon rchitectural Styles

of merican omes


7/44

.

%ommon rchitectural Styles

of merican omes

-/rame

$ungalow

%ape %od

%olonial

/ederal

/our square

0ree) (evival

0eorgian

#ueblo

#rairie Style

(anch

Split level

Tidewater

ictorian

Tudor


8/44

2

Software rchitectural Style

• The software that is built for computer-based systems exhibit one ofmany architectural styles

• &ach style describes a system category that encompasses

– set of component types that perform a function required by the system

– set of connectors 3subroutine call* remote procedure call* data stream*soc)et4 that enable communication* coordination* and cooperation amongcomponents

– Semantic constraints that define how components can be integrated toform the system

– topological layout of the components indicating their runtime

interrelationships

3Source5 $ass* %lements* and 6a7man8 Software Architecture in Practice8 ddison-9esley* "::'4


9/44

;

Taxonomy of rchitectural StylesIndependent Components

%ommunicating

#rocesses

&vent Systems

%lientb?ect

>riented@ayered

(emote #rocedure %all


10/44

1:

Data /low Style

alidate Sort Apdate (eport


11/44

11

Data /low Style

• as the goal of modifiability• %haracteri7ed by viewing the system as a series of transformations on

successive pieces of input data

• Data enters the system and then flows through the components one at a timeuntil they are assigned to output or a data store

• $atch sequential style

– The processing steps are independent components

– &ach step runs to completion before the next step begins

• #ipe-and-filter style

– &mphasi7es the incremental transformation of data by successive components

– The filters incrementally transform the data 3entering and exiting via streams4

– The filters use little contextual information and retain no state betweeninstantiations

– The pipes are stateless and simply exist to move data between filters

3=ore on next slide4


12/44

1"

Data /low Style 3continued4• dvantages

– as a simplistic design in the limited ways in which the components interact with theenvironment

– %onsists of no more and no less than the construction of its parts

– Simplifies reuse and maintenance

– !s easily made into a parallel or distributed execution in order to enhance system performance

• Disadvantages

– !mplicitly encourages a batch mentality so interactive applications are difficult to create in

this style – >rdering of filters can be difficult to maintain so the filters cannot cooperatively interact to

solve a problem

– &xhibits poor performance

• /ilters typically force the least common denominator of data representation 3usually S%!! stream4

• /ilter may need unlimited buffers if they cannot start producing output until they receive all of theinput

• &ach filter operates as a separate process or procedure call* thus incurring overhead in set-up andta)e-down time



13/44

1'

Data /low Style 3continued4

• Ase this style when it ma)es sense to view your system as one that produces a well-defined easily identified output

– The output should be a direct result of sequentially transforming a well-

defined easily identified input in a time-independent fashion


14/44

1+

%all-and-(eturn Style

=ain module

Subroutine Subroutine $

Subroutine -1 Subroutine -"

#hysical layer

Data layer

Betwor) layer

Transport layer

pplication layer %lass 9%lass

%lass C

%lass

%lass E


15/44

1F

%all-and-(eturn Style

• as the goal of modifiability and scalability• as been the dominant architecture since the start of software development

• =ain program and subroutine style

– Decomposes a program hierarchically into small pieces 3i8e8* modules4

– Typically has a single thread of control that travels through various componentsin the hierarchy

• (emote procedure call style

– %onsists of main program and subroutine style of system that is decomposed into parts that are resident on computers connected via a networ)

– Strives to increase performance by distributing the computations and ta)ingadvantage of multiple processors

– !ncurs a finite communication time between subroutine call and response



16/44

1,

%all-and-(eturn Style 3continued4• >b?ect-oriented or abstract data type system

– &mphasi7es the bundling of data and how to manipulate and access data

– 6eeps the internal data representation hidden and allows access to the ob?ect only through providedoperations

– #ermits inheritance and polymorphism

• @ayered system

– ssigns components to layers in order to control inter-component interaction

– >nly allows a layer to communicate with its immediate neighbor

– ssigns core functionality such as hardware interfacing or system )ernel operations to the lowestlayer

– $uilds each successive layer on its predecessor* hiding the lower layer and providing services for theupper layer

– !s compromised by layer bridging that s)ips one or more layers to improve runtime performance

• Ase this style when the order of computation is fixed* when interfaces are specific* and whencomponents can ma)e no useful progress while awaiting the results of request to othercomponents


17/44

1.

Data-%entered Style

Shared Data

%lient %lient $ %lient %

%lient D %lient & %lient /


18/44

12

Data-%entered Style 3continued4

• as the goal of integrating the data

• (efers to systems in which the access and update of a widely accessed datastore occur

• client runs on an independent thread of control

• The shared data may be a passive repository or an active blac)board

– blac)board notifies subscriber clients when changes occur in data of interest

• t its heart is a centrali7ed data store that communicates with a number ofclients

• %lients are relatively independent of each other so they can be added*removed* or changed in functionality

• The data store is independent of the clients



19/44

1;

Data-%entered Style 3continued4

• Ase this style when a central issue is the storage* representation*

management* and retrieval of a large amount of related persistent data

• Bote that this style becomes client


20/44

":

irtual =achine Style

!nterpretation

&ngine

#rogram Data#rogram

!nstructions

#rogram

!nternal State


21/44

"1

irtual =achine Style

• as the goal of portability• Software systems in this style simulate some functionality that is not native to

the hardware and


22/44

""

!ndependent %omponent Style

Server

%lient %lient $

%lient % %lient D

#eer 9 #eer C

#eer E #eer


23/44

"'

!ndependent %omponent Style• %onsists of a number of independent processes that communicate through

messages

• as the goal of modifiability by decoupling various portions of the computation

• Sends data between processes but the processes do not directly control eachother

• &vent systems style

– !ndividual components announce data that they wish to share 3publish4 with theirenvironment

– The other components may register an interest in this class of data 3subscribe4

– =a)es use of a message component that manages communication among the othercomponents

– %omponents publish information by sending it to the message manager

– 9hen the data appears* the subscriber is invo)ed and receives the data

– Decouples component implementation from )nowing the names and locations ofother components



24/44

"+

!ndependent %omponent Style

3continued4

• %ommunicating processes style

– These are classic multi-processing systems

– 9ell-)now subtypes are client


25/44

"F

eterogeneous Styles

• Systems are seldom built from a single architectural style

• Three )inds of heterogeneity

– @ocationally heterogeneous

• The drawing of the architecture reveals different styles in different areas 3e8g8*a branch of a call-and-return system may have a shared repository4

– ierarchically heterogeneous

• component of one style* when decomposed* is structured according to the

rules of a different style

– Simultaneously heterogeneous

• Two or more architectural styles may both be appropriate descriptions for the

style used by a computer-based system


26/44

rchitectural Design #rocess


27/44

".

rchitectural Design Steps

14 (epresent the system in context

"4 Define archetypes

'4 (efine the architecture into components

+4 Describe instantiations of the system

G doctor can bury his mista)es* but an architect can only advise

his client to plant vines8G /ran) @loyd 9right


28/44

"2

18 (epresent the System in %ontext

Target system

!


29/44

";

18 (epresent the System in %ontext

3continued4

• Ase an architectural context diagram 3%D4 that shows – The identification and flow of all information into and out of a system

– The specification of all interfaces

– ny relevant support processing from


30/44

':

"8 Define rchetypes• rchetypes indicate the important abstractions within the problem domain

3i8e8* they model information4• n archetype is a class or pattern that represents a core abstraction that is

critical to the design of an architecture for the target system

• !t is also an abstraction from a class of programs with a common structure andincludes class-specific design strategies and a collection of example programdesigns and implementations

• >nly a relatively small set of archetypes is required in order to design evenrelatively complex systems

• The target system architecture is composed of these archetypes – They represent stable elements of the architecture

– They may be instantiated in different ways based on the behavior of the system

– They can be derived from the analysis class model

• The archetypes and their relationships can be illustrated in a A=@ classdiagram


31/44

'1

&xample rchetypes in umanity

• ddict


32/44

'"

&xample rchetypes in Software

rchitecture

• Bode

• Detector


33/44

''

rchetypes – their attributes


34/44

'+

rchetypes – their methods


35/44

'F

'8 (efine the rchitecture into

%omponents• $ased on the archetypes* the architectural designer refines the software

architecture into components to illustrate the overall structure andarchitectural style of the system

• These components are derived from various sources

– The application domain provides application components* which are the domain

classes in the analysis model that represent entities in the real world – The infrastructure domain provides design components 3i8e8* design classes4 that

enable application components but have no business connection

• &xamples5 memory management* communication* database* and tas) management

– The interfaces in the %D imply one or more speciali7ed components that process the data that flow across the interface

• A=@ class diagram can represent the classes of the refined architectureand their relationships


36/44

',

+8 Describe !nstantiations of the

System

• n actual instantiation of the architecture is developed by applying it

to a specific problem

• This demonstrates that the architectural structure* style and

components are appropriate• A=@ component diagram can be used to represent this instantiation


37/44

ssessing lternative

rchitectural Designs


38/44

'2

arious ssessment pproaches

8 s) a set of questions that provide the designer with an early

assessment of design quality and lay the foundation for more

detailed analysis of the architecture

•ssess the control in an architectural design 3see next slide4

• ssess the data in an architectural design 3see upcoming slide4

$8 pply the architecture trade-off analysis method

%8 ssess the architectural complexity


39/44

';

pproach 5 Iuestions -- ssessing

%ontrol in an rchitectural Design

• ow is control managed within the architectureJ

• Does a distinct control hierarchy exist* and if so* what is the role of

components within this control hierarchyJ

• ow do components transfer control within the systemJ• ow is control shared among componentsJ

• 9hat is the control topology 3i8e8* the geometric form that the control

ta)es4J

• !s control synchroni7ed or do components operate asynchronouslyJ


40/44

+:

pproach 5 Iuestions -- ssessing Data

in an rchitectural Design

• ow are data communicated between componentsJ

• !s the flow of data continuous* or are data ob?ects passed to the systemsporadicallyJ

• 9hat is the mode of data transfer 3i8e8* are data passed from one componentto another or are data available globally to be shared among systemcomponents4

• Do data components exist 3e8g8* a repository or blac)board4* and if so* what istheir roleJ

• ow do functional components interact with data componentsJ

• re data components passive or active 3i8e8* does the data component activelyinteract with other components in the system4J

• ow do data and control interact within the systemJ


41/44

+1

pproach $5 rchitecture Trade-off

nalysis =ethod

14 %ollect scenarios representing the system from the userKs point of view

"4 &licit requirements* constraints* and environment description to be certain all

sta)eholder concerns have been addressed

'4 Describe the candidate architectural styles that have been chosen to address the

scenarios and requirements

+4 &valuate quality attributes by considering each attribute in isolation 3reliability*

performance* security* maintainability* flexibility* testability* portability* reusability*

and interoperability4

F4 !dentify the sensitivity of quality attributes to various architectural attributes for a

specific architectural style by ma)ing small changes in the architecture

,4 %ritique the application of the candidate architectural styles 3from step L'4 using thesensitivity analysis conducted in step LF

$ased on the results of steps F and ,* some architecture alternatives may be

eliminated8 >thers will be modified and represented in more detail until a target

architecture is selected


42/44

+"

pproach %5 ssessing rchitectural

%omplexity• The overall complexity of a software architecture can be assessed by

considering the dependencies between components within the architecture

• These dependencies are driven by the information and control flow withina system

• Three types of dependencies

– Sharing dependency V• (epresents a dependency relationship among consumers who use the same source

or producer

– /low dependency V• (epresents a dependency relationship between producers and consumers of

resources

– %onstrained dependency M!R# V

• (epresents constraints on the relative flow of control among a set of activities suchas mutual exclusion between two components


43/44

+'

Summary

• software architecture provides a uniform* high-level view of the systemto be built

• !t depicts

– The structure and organi7ation of the software components

– The properties of the components

– The relationships 3i8e8* connections4 among the components

• Software components include program modules and the various datarepresentations that are manipulated by the program

• The choice of a software architecture highlights early design decisionsand provides a mechanism for considering the benefits of alternativearchitectures

• Data design translates the data ob?ects defined in the analysis model intodata structures that reside in the software



44/44

Summary 3continued4

• number of different architectural styles are available that encompass a setof component types* a set of connectors* semantic constraints* and atopological layout

• The architectural design process contains four distinct steps

14 (epresent the system in context"4 !dentify the component archetypes 3the top-level abstractions4

'4 !dentify and refine components within the context of various architectural styles

+4 /ormulate a specific instantiation of the architecture

• >nce a software architecture has been derived* it is elaborated and thenanaly7ed against quality criteria

Documents

Pressman Ch 10 Architectural Style