Software Architecture new

7/25/2019 Software Architecture new

1/46

Chapter6 Patterns and SoftwareArchitecture

Feng Zhiyong

Tianjin University

Apr 16, 2004


2/46

Introduction

Software Architecture

o!ponent"e#ationship

$iew

Functiona# %roperty&on'functiona# %roperty

Software (esign


3/46


A software architectureis a )escriptionof the

su*syste!s an) co!ponents of a software syste!

an) the re#ationships*etween the!+

Su*syste!s an) co!ponentsare typica##y specifie)

in )ifferent views to show the re#evant functiona# an)

non'functiona# properties of a software syste!+

The software architecture of a syste! is an artifact+ t

is the resu#t of the software )esign activity+


4/46

Component(1/4)

A componentis an encapsu#ate) part of asoftware syste!+

A co!ponent has an interface+ o!ponentsserve as the *ui#)ing *#oc-sfor thestructure of a syste!+

At a progra!!ing'#anguage #eve#,co!ponents !ay *e represente) as!o)u#es, c#asses, o*jects or a set of re#ate)functions+


5/46

Component(2/4)

The fo##owing figure shows three )ifferent co!ponents.


6/46

Component(3/4)--categori/e

#e!ents.

%rocessing e#e!ents (ata e#e!ents

onnecting e#e!ents


7/46

Component(4/4)--categori/e

Another categori/ation of co!ponents

)eve#ope) for the o*ject'oriente) progra!!ingpara)ig! s as fo##ows. ontro##er co!ponents

oor)inator co!ponents

nterface co!ponents Service provi)er co!ponents

nfor!ation ho#)er co!ponents

Structuring co!ponents


8/46

e!ationship(1/2)

A relationship)enotes a connection *etween

co!ponents+ A re#ationship !ay *e static or)yna!ic+ Static relationshipsshow )irect#y in source co)e+

They )ea# with the p#ace!ent of co!ponents within

an architecture+ Dynamic relationships)ea# with te!pora#

connections an) )yna!ic nteraction *etween

co!ponents+ They !ay not *e easi#y visi*#e fro! the

static structure of source co)e+


9/46

e!ationship(2/2)


10/46

"iew(1/3)

A viewrepresents a partia# aspect of a softwarearchitecture that shows specific properties of asoftware syste!+


11/46

"iew(2/3)

(escriptionS&35

Conceptual architecture:co!ponents,connectors++ ++ Module architecture:su*syste!s, !o)u#es,

e7ports, i!ports++,+

Code architecture:fi#es, )irectories+ #i*raries,

inc#u)es +++ Execution architecture:tas-s, threa)s,

processes +++


12/46

"iew(3/3)

Logical view:the )esign8s o*ject !o)e#, or acorrespon)ing !o)e# such as an entity re#ationship

)iagra!+ Process view:concurrency an) synchroni/ation

aspects+ Physical view:the !apping of the software onto the

har)ware an) its )istri*ute) aspects+ Development view:the software8s static

organi/ation in its )eve#op!ent environ!ent+

S U9:


13/46


14/46

#unctiona! and $on-functiona!

Properties

A non-functional property)enotes a feature of a syste!

that is not covere) *y its functiona# )escription+ A non'

functiona# property typica##y a))resses aspects re#ate) tothe re#ia*i#ity, co!pati*i#ity, cost, ease of use, !aintenance

or )eve#op!entof a software syste!+ The others. hangea*i#ity

nteropera*i#ity fficiency

"e#ia*i#ity

Testa*i#ity

"eusa*i#ity


15/46

Software %esi&n

oftware designis the activity perfor!e) *y a

software )eve#oper that resu#ts in the software

architecture of a syste!+ t is concerne) withspecifying the co!ponentsof a software syste! an)

the re#ationships*etween the! within given

functiona# an) non'functiona# properties+


16/46

6'2 Patterns in Software Architecture


17/46

ethodo!o&ies

9etho)o#ogies provi)e !any usefu# steps an)

gui)e#ines for constructing high';ua#ity software+ The

i!p#e!entation sections of our patterns #oose#y fo##owthese steps, a)apte) to the nee)s of the specific

pro*#e!s the patterns a))ress+

These !etho)s )efine an overa## process for software

)eve#op!entthat you can a)apt an) e7ten) to integrateyour use of patterns+

%atterns co!p#e!ent the e7isting ana#ysis an) )esign

!etho)swith a set of concrete techni;ues for so#ving

very specific *ut recurring )esign pro*#e!s+


18/46

Software Processes(1/2)

The *#an-et app#icationof !etho)o#ogies ten)s to

cause even worse pro*#e!s for software

processes+

3ow can patterns he#p here= >e wou#) #i-e to

integrate patterns into an incre!enta# )e#ivery

processthat gets ri) of the strict separation of)eve#op!ent phases+

>e are often as-e) at what point of )eve#op!ent

shou#) patterns *e use).)uring ana#ysis, high' or

#ow'#eve# )esign, or even )uring i!p#e!entation=


19/46

Architectura! St!es

An architectural style)efines a family of

software systems in terms of their structuralorganization+An architectura# sty#e e7presses

co!ponentsan) the re#ationships*etween

the!, with the constraints of their app#ication,

an) the associate) co!position an) )esignru#es for their construction+


20/46

9u#ti'phase architectura# sty#e

the !u#ti'phase sty#e for a co!pi#er inc#u)es. Processing elements: #e7er, parser, se!antor, opti!i/er,

co)e generator+

Data elements: characters, to-ens, phrases, corre#ate)

phrases, annotate) phrases, o*ject co)e+

f the !u#ti'phase architectura# sty#e is organi/e)

se;uentia##y, it a#so uses the fo##owing connectinge#e!ents. Connecting elements: proce)ure ca##s an) para!eters+


21/46

#ramewor*s

A framewor!is a partia##y co!p#ete software

?su*'@ syste!that is inten)e) to *e instantiate)+ t )efines the architecturefor a fa!i#y of ?su*'@syste!s an) provi)es the *asic *ui#)ing *#oc-sto

create the!+

t a#so )efines the p#aces where a)aptations forspecific functiona#ity shou#) *e !a)e+

n an o*ject'oriente) environ!ent a fra!ewor-

consists of a*stract an) concrete c#asses+


22/46

6'3 +na,!in& echni.ues for

Software Architecture(1/2)

A"straction

Encapsulation #nformation $iding

Modulari%ation

eparation of Concerns Coupling and Cohesion


23/46

6'3 +na,!in& echni.ues for Software

Architecture(2/2)

ufficiency& Completeness and

Primitiveness eparation of Policy and #mplementation

eparation of #nterface and

#mplementation

ingle Point of 'eference

Divide-and-Con(uer


24/46

A,straction

A*straction is one of the fun)a!enta# princip#es hu!ans

use to cope with co!p#e7ity+ ra)y Booch )efines a*straction as The essential

characteristics of an objectthat )istinguish t fro! a## other

-in)s of o*jects an) thus provi)e crisp#y )efine) conceptua#

*oun)aries re#ative to the perspective of the viewer+

The wor) 8o*jectC !ay *e rep#ace) with 8co!ponent8 to achieve

a !ore genera# )efinition of a*straction+

Severa# for!s of a*straction e7ist, such as entity a*straction,

action a*straction, virtua# !achine a*straction an) coinci)enta#

a*straction+This princip#e is a))resse) *y severa# patterns

such as the aerspattern an) the A,stract #actorpattern+


25/46

+ncapsu!ation

ncapsu#ation )ea#s with grouping the e#e!ents ofan a*stractionthat constitute its structure an)*ehavior, an) with separating )ifferenta*stractions fro! each other+ ncapsu#ation provi)es e7p#icit *arriers *etween

a*stractions+

The Forwar)er'"eceiver pattern+ for e7a!p#e,encapsu#ates the i!p#e!entation )etai#s of inter'process co!!unication !echanis!s+

ncapsu#ation fosters non'functiona# properties #i-echangea*i#ity an) reusa*i#ity+


26/46

Information 0idin&

nfor!ation hi)ing invo#ves concea#ing the )etai#s of a

co!ponent8s i!p#e!entation fro! its c#ients, to han)#e

syste! co!p#e7ity *etter an) to !ini!i/e coup#ing*etween co!ponents+ Any )etai#s of a co!ponentthat c#ients )o not nee) to -now in

or)er to use it proper#y shou#) *e hi))en *y the co!ponent+

The >ho#e'%art pattern a))resses this princip#e e7p#icit#y+ Theprincip#e of encapsu#ation is often use) as a way to achieve

infor!ation hi)ing+

nfor!ation hi)ing can a#so *e achieve) using the princip#e of

separation of interface an) i!p#e!entation, )escri*e) #ater in this

section+


27/46

odu!ariation

9o)u#ari/ation is concerne) with the !eaningfu#)eco!position of a software syste! an) with its grouping

into su*syste!s an) co!ponents+ The !ajor tas- is to )eci)e how to physica##y pac-age the entities

that for! the #ogica# structure of an app#ication+

The !ain o*jective of !o)u#ari/ation is to han)#e syste!co!p#e7ity *y intro)ucing we##')efine) an) )ocu!ente)

*oun)aries within a progra!+ 9o)u#es serve as physica# containersfor functiona#ities or

responsi*i#ities of an app#ication+

9o)u#ari/ation is c#ose#y re#ate) to the princip#e of encapsu#ation+

7a!p#esof patterns that a))ress !o)u#arity are the :ayers

pattern, the %ipes an) Fi#ters pattern an) the >ho#e'%art pattern+


28/46

Separation of Concerns(1/2) (ifferent or unre#ate) responsi*i#ities shou#) *e

separate) fro! each other within a software syste!, for

e7a!p#e *y attaching the! to )ifferent co!ponents+ o##a*orating co!ponentsthat contri*ute to the so#ution of a

specific tas- shou#) *e separate) fro! co!ponents that are

invo#ve) in the co!putation of other tas-s+

f a co!ponent p#ays )ifferent ro#es in )ifferent conte7ts, these

ro#es shou#) *e in)epen)ent an) separate fro! each other withinthe co!ponent+

A#!ost every pattern of our pattern syste! a))resses this

fun)a!enta# princip#e in so!e way+

For e7a!p#e, the 9o)e#'$iew' ontro##er pattern ?125@ separates

the concerns of interna# !o)e#, presentation to the user an) input

processing+


29/46

Coup!in& and Cohesion(1/2)

oup#ing an) cohesion are princip#es origina##y

intro)uce) as part of the structure) )esign approach+

oup#ing focuses on inter'!o)u#e aspects, whereas

cohesion e!phasi/es intra'!o)u#e characteristics+

oup#ing is the !easure of the strength of association

esta*#ishe) *y a connection fro! one !o)u#e to another

Strong coup#ing co!p#icates a syste!, since a !o)u#eis har)er to un)erstan), change, or to correct if it is

high#y interre#ate) with other !o)u#es+ o!p#e7ity can

*e re)uce) *y )esigning syste!s with wea- coup#ing

*etween !o)u#es+


30/46

Coup!in& and Cohesion(2/2)

ohesion !easures the )egree of connectivity *etween

the functions an) e#e!ents of a sing#e !o)u#e+ There

are severa# for!s of cohesion+ The !ost )esira*#e for!is functiona# cohesion, in which the e#e!ents of a

!o)u#e or co!ponent 8a## wor- together to provi)e

so!e we## *oun)e) *ehavior8+

The worst for! is coinci)enta# cohesion, in which entire#yunre#ate) a*stractions are thrown into the sa!e !o)u#e+


31/46

Sufficienc Comp!eteness and

Primitieness

Boo4 states that 8very co!ponent of a software

syste! shou#) *e sufficient, co!p#ete, an) pri!itive8+ 8Sufficient8 !eans that the co!ponent shou#) capture those

characteristics of an a*straction that are necessary to per!it a

!eaningfu# an) efficient interaction with the co!ponent+

8o!p#eteness8 !eans that a co!ponent shou#) capture a##

re#evant characteristics of its a*straction+

By 8pri!itiveness8+ Booch !eans that a## the operations a

co!ponent can perfor! can *e i!p#e!ente) easi#y+ t is a !ajor

goa# of every pattern to *e sufficient an) co!p#ete with respect to

the so#ution of a given pro*#e!+ 9any patterns are a#so re#ative#y

pri!itive an) easy to i!p#e!ent, for e7a!p#e the Strategy pattern

3E$5+


32/46

Separation of Po!ic and

Imp!ementation(1/2)

A co!ponentof a software syste! shou#) )ea#

with po#icy or i!p#e!entation, *ut not *oth. A po#icy co!ponent )ea#s with conte7t'sensitive

)ecisions, -now#e)ge a*out the se!antics an)

interpretation of infor!ation+ the asse!*#y of !any

)isjoint co!putations into a resu#t or the se#ection of

para!eter va#ues+


33/46

Separation of Po!ic and

Imp!ementation(2/2)

An implementationco!ponent )ea#s with the e7ecution

of a fu##y specifie) a#gorith! in which no conte7t'sensitive

)ecisions have to *e !a)e+ The conte7t an)interpretation are e7terna#, an) are nor!a##y supp#ie) *y

argu!ents to the co!ponent+

f it is not possi*#e to separate po#icy an) i!p#e!entation

into )ifferent co!ponents within a software architecture,there shou#) at #east *e a c#ear separation of po#icy an)

i!p#e!entation functiona#ity within a co!ponent+ The

Strategy pattern 50"789 focuses on this princip#e+


34/46

Separation of Interface and

Imp!ementation

Any co!ponent shou#) consist of two parts. An interfacepart that )efines the functiona#ity provi)e)

*y the co!ponent an) specifies how to use it+ Thisinterface is accessi*#e *y the c#ients of the co!ponent+An e7porte) interface of this type usua##y consists offunction signatures+

An implementationpart that inc#u)es the actua# co)efor the functiona#ity provi)e) *y the co!ponent+ Thei!p#e!entation part !ay a#so co!prise a))itiona#functions an) )ata structures that are on#y use)interna##y to the co!ponent+ The i!p#e!entation part is

not accessi*#e *y the co!ponent8s c#ients+


35/46


36/46

%iide-and-Con.uer

This princip#e is we##'-nown, *oth fro! the po#itics of theancient wor#) as we## as fro! co!*inatoria# a#gorith!s

such as 9erge'sort+ >e use this princip#e heavi#y in software architecture+ Top')own )esign, for e7a!p#e, )ivi)es a tas- or co!ponent intos!a##er parts that can *e )esigne) in)epen)ent#y+

The >ho#e'%art pattern approaches this techni;ue at thepattern #eve#+ ho#e'%art+ The 9icro-erne# pattern for e7a!p#e+ su*)ivi)es what once

!ight have *een a !ono#ithic *#oc- of co)e+ (ivi)e'an)'on;uer a#so often provi)es a way to rea#i/e the princip#e ofseparation of concerns+


37/46

6'4 $on-functiona! Properties of


hangea*i#ity

nteropera*i#ity fficiency

"e#ia*i#ity

Testa*i#ity"eusa*i#ity


38/46


39/46

Interopera,i!it

Software that for!s part of a syste! )oes not e7istin)epen)ent#y+ t is fre;uent#y interacting with other

syste!s or its environ!ent+ To support interopera*i#ity, a software architecture !ust *e

)esigne) to offer we##')efine) access to e7terna##y'visi*#efunctiona#ity an) )ata structures+

The interaction of a progra! with software syste!s writtenin other progra!!ing #anguages is an aspect ofinteropera*i#itythat a#so i!pacts the software architectureof an app#ication+

The Bro-er architecture is pro*a*#y the !ost pro!inente7a!p#e of a pattern that a))resses interopera*i#ity+


40/46

+fficienc

fficiency )ea#s with the use of the resources

avai#a*#e for the e7ecution of software, an) how

this i!pacts response ti!es, throughput an)

storage consu!ption+ fficiency is not on#y a !atter of using sophisticate)

a#gorith!s+ The appropriate )istri*ution of responsi*i#ities to

co!ponents, as we## as their coup#ing, are i!portant

architectura# activities for achieving efficiency in a

given app#ication+


41/46

e!ia,i!it

"e#ia*i#ity )ea#s with the genera# a*i#ity of a software

syste! to !aintain its functiona#ity, *oth in the face

of app#ication or syste! errors an) in situations ofune7pecte) or incorrect usage+ Two aspects of

re#ia*i#ity can *e )istinguishe). Fau#t to#erance+ This ai!s at ensuring correct *ehavior in

the went of errors, an) their interna# 8repair8, "o*ustness+ This )ea#s with protecting an app#ication

against incorrect usage an) )egenerate input, an) -eeping

it in a )efine) state in the went of une7pecte) errors+


42/46


43/46

eusa,i!it

"eusa*i#ity has two !ajor aspects'software

)eve#op!ent with reuse an) software

)eve#op!ent for reuse. Software )eve#op!ent with reuse !eans reusing

e7isting co!ponents an) resu#ts fro! previous

projects or co!!ercia# #i*raries, )esign ana#yses,

)esign specifications or co)e co!ponents+

Software )eve#op!ent for reuse focuses on pro)ucing

co!ponents that are potentia##y reusa*#e in future

projects as part of the current software )eve#op!ent+


44/46


45/46

)*+ ummary,1./0

%atterns a#so provi)e an i!portant contri*ution to the

*enefits you can gain fro! software architecture. They he#p with the recognition of co!!on para)ig!s, so

that high #eve# re#ationships *etween software syste!s can

*e un)erstoo) an) new app#ications *ui#t as variations on

o#) syste!s+

They provi)e support for fin)ing an appropriate architecturefor the software syste! un)er )eve#op!ent+

They provi)e support for !a-ing princip#e) choices a!ong

)esign a#ternatives+


46/46

)*+ ummary,/./0

They he#p with the ana#ysis an) )escription of high'#eve#

properties of co!p#e7 software syste!s+

They provi)e support for change an) evo#ution of softwaresyste!s+

%atterns provi)e a *ig step forwar) in supporting the

syste!atic construction of high';ua#ity software

syste!s with )efine) functiona# an) non'functiona#properties+ %atterns provi)e a prag!atic !etho) an)

process'in)epen)ent way to so#ve the !any )esign

an) i!p#e!entation pro*#e!s that software

Documents

Software Architecture new