IT6602 - SA

8/17/2019 IT6602 - SA

http://slidepdf.com/reader/full/it6602-sa 1/49

SRI BHARATHI ENGINEERING COLLEGE FOR WOMEN

Pudukkottai to Aranthangi road, Kaikkurihi, Pudukkottai ! "##$$%

Department of Information Technology

IT6602 – SOFTWARE ARCITECT!RE

S!"#ECT $OTES

III %EAR & 'I SE(ESTER IT

)RE*!+ATIO$ 20,-.

Prepared by,

Mrs. M.Abinaya B.Tech., (M.E)., MISTE,

(Lect. / IT)

8/17/2019 IT6602 - SA


IT6602 SOFTWARE ARCITECT!RES + T / C

- 0 0 -

!$IT I I$TROD!CTIO$ A$D ARCITECT!RA+ DRI'ERS

Introduction – hat is so!t"are architecture# – Standard $e!initions – Architectura% structures –

In!%uence o! so!t"are architecture on or&ani'ationboth business and technica% – Architecture

Business yc%e Introduction – *unctiona% re+uireents – Technica% constraints – -ua%ityAttributes.

!$IT II 1!A+IT% ATTRI"!TE WORSO/

-ua%ity Attribute orshop – $ocuentin& -ua%ity Attributes – Si part scenarios – ase

studies.

!$IT III ARCITECT!RA+ 'IEWS

Introduction – Standard $e!initions !or 0ie"s – Structures and 0ie"s 1epresentin& 0ie"s

a0ai%ab%e notations – Standard 0ie"s – 234 0ie" o! 15P, Sieens 2 0ie"s, SEI6s perspecti0es

and 0ie"s – ase studies

!$IT I' ARCITECT!RA+ ST%+ES

Introduction – $ata !%o" sty%es – a%%return sty%es – Shared In!oration sty%es E0ent sty%es – ase studies !or each sty%e.

!$IT ' DOC!(E$TI$* TE ARCITECT!RE

7ood practices – $ocuentin& the 8ie"s usin& 5ML – Merits and $eerits o! usin& 0isua%

%an&ua&es – 9eed !or !ora% %an&ua&es Architectura% $escription Lan&ua&es – AME – ase

studies. Specia% topics: S;A and eb ser0ices – %oud oputin& – Adapti0e structures.

TE3T "OOS4

4. Len Bass, Pau% %eents, and 1ic <a'an, =So!t"are Architectures Princip%es and

Practices>,?nd Edition, Addisones%ey, ?@@.

25 Anthony Lattan'e, =Architectin& So!t"are Intensi0e Syste. A Practitioner6s 7uide>,

Auerbach Pub%ications, ?@4@.

REFERE$CES4

4. Pau% %eents, *e%i Bachann, Len Bass, $a0id 7ar%an, aes I0ers, 1eed Litt%e, Pau%o

Merson, 1obert 9ord, and udith Sta!!ord, =$ocuentin& So!t"are Architectures. 8ie"s and

Beyond>, ?nd Edition, Addisones%ey, ?@4@.?. Pau% %eents, 1ic <a'an, and Mar <%ein, =E0a%uatin& so!t"are architectures: Methods

and case studies. Addisones%ey, ?@@4.

. 1aCuar Buyya, aes Brober&, and Andr'eC 7oscinsi, =%oud oputin&. Princip%es andParadi&s>, ohn i%ey D Sons, ?@44

2. Mar ansen, =S;A 5sin& a0a eb Ser0ices>, Prentice a%%, ?@@F

G. $a0id 7ar%an, Brad%ey Scher%, and Shan&en hen&, =So!t"are ArchitectureBasedSe%!Adaptation,>4GH.Mieso< $eno, Laurence Tianruo an&, and an Jan& (eds.),

=Autonoic oputin& and 9et"orin&>. Sprin&er 8er%a&, ?@@K.

8/17/2019 IT6602 - SA


!$IT I

I$TROD!CTIO$ A$D ARCITECT!RA+ DRI'ERS

I$TROD!CTIO$

Typical 78t 8ninformati9e pre:entation of :oft;are architect8re

Fig8re taen !ro a syste description !or an under"ater acoustic siu%ation, purports

to describe that syste6s top%e0e% architecture and is precise%y the ind o! dia&ra ost o!tendisp%ayed to he%p ep%ain architecture. Eact%y "hat can "e te%% !ro it#

• The syste consists o! !our e%eents.

• Three o! the e%eents Prop Loss Mode% (M;$P), 1e0erb Mode% (M;$1), and

9oise Mode% (M;$9) i&ht ha0e ore in coon "ith each other than "ith

the !ourthontro% Process (P)because they are positioned net to each

other.

• A%% o! the e%eents apparent%y ha0e soe sort o! re%ationship "ith each other,

since the dia&ra is !u%%y connected.

Is this an architecture# hat can "e not te%% !ro the dia&ra#

What is the nature of the elements?

hat is the si&ni!icance o! their separation# $o they run on separate processors# $o they

run at separate ties# $o the e%eents consist o! processes, pro&ras, or both# $o they

represent "ays in "hich the proCect %abor "i%% be di0ided, or do they con0ey a sense o! runtie

separation# Are they obCects, tass, !unctions, processes, distributed pro&ras, or soethin&

e%se#

What are the responsibilities of the elements?

hat is it they do# hat is their !unction in the syste#

What is the significance of the connections?$o the connections ean that the e%eents counicate "ith each other, contro% each

other, send data to each other, use each other, in0oe each other, synchroni'e "ith each other,

share soe in!orationhidin& secret "ith each other, or soe cobination o! these or other

re%ations# hat are the echaniss !or the counication# hat in!oration !%o"s across the

echaniss, "hate0er they ay be#

8/17/2019 IT6602 - SA


What is the significance of the layout?

hy is P on a separate %e0e%# $oes it ca%% the other three e%eents, and are the others

not a%%o"ed to ca%% it# $oes it contain the other three in an ip%eentation unit sense# ;r is there

sip%y no roo to put a%% !our e%eents on the sae ro" in the dia&ra#

This dia&ra does not sho" a so!t"are architecture. e no" de!ine "hat does constitute

so!t"are architecture:

The software architecture of a program or computing system is the structure or structures

of the system, which comprise software elements, the externally visible properties of those

elements, and the relationships among them.

Let6s %oo at soe o! the ip%ications o! this de!inition in ore detai%.

• Architecture de!ines so!t"are e%eents

• The de!inition aes c%ear that systes can and do coprise ore than one structure and

that no one structure can irre!utab%y c%ai to be the architecture.

• The de!inition ip%ies that e0ery coputin& syste "ith so!t"are has a so!t"are

architecture because e0ery syste can be sho"n to coprise e%eents and the re%ations

aon& the.

• The beha0ior o! each e%eent is part o! the architecture inso!ar as that beha0ior can be

obser0ed or discerned !ro the point o! 0ie" o! another e%eent. Such beha0ior is "hat

a%%o"s e%eents to interact "ith each other, "hich is c%ear%y part o! the architecture.

• The de!inition is indi!!erent as to "hether the architecture !or a syste is a &ood one or a

bad one, eanin& that it "i%% a%%o" or pre0ent the syste !ro eetin& its beha0iora%,

per!orance, and %i!ecyc%e re+uireents.

OTER /OI$TS OF 'IEWThe study o! so!t"are architecture is an attept to abstract the coona%ities inherent in syste

desi&n, and as such it ust account !or a "ide ran&e o! acti0ities, concepts, ethods, approaches,

and resu%ts.

• Architecture is high-level design. ;ther tass associated "ith desi&n are not

architectura%, such as decidin& on iportant data structures that "i%% be encapsu%ated.

• Architecture is the overall structure of the system. The di!!erent structures pro0ide the

critica% en&ineerin& %e0era&e points to ibue a syste "ith the +ua%ity attributes that "i%%

render it a success or !ai%ure. The u%tip%icity o! structures in an architecture %ies at the

heart o! the concept.

• Architecture is the structure of the components of a program or system, their

interrelationships, and the principles and guidelines governing their design and

evolution over time. Any syste has an architecture that can be disco0ered and ana%y'ed

independent%y o! any no"%ed&e o! the process by "hich the architecture "as desi&ned or

e0o%0ed.

8/17/2019 IT6602 - SA


• Architecture is components and connectors. onnectors ip%y a runtie echanis !or

trans!errin& contro% and data around a syste. hen "e spea o! re%ationships aon&

e%eents, "e intend to capture both runtie and nonruntie re%ationships.

ARCITECT!RA+ STR!CT!RES A$D 'IEWS

Architectura% structures can by and %ar&e be di0ided into three &roups, dependin& on the broad

nature o! the e%eents they sho".

• Module structures.

ere the e%eents are odu%es, "hich are units o! ip%eentation. Modu%es

represent a codebased"ay o! considerin& the syste. They are assi&ned areas o!

!unctiona% responsibi%ity. There is %ess ephasis on ho" the resu%tin& so!t"are ani!ests

itse%! at runtie. Modu%e structures a%%o" us to ans"er +uestions such as hat is the

priary !unctiona% responsibi%ity assi&ned to each odu%e# hat other so!t"are e%eents

is a odu%e a%%o"ed to use# hat other so!t"are does it actua%%y use# hat odu%es are

re%ated to other odu%es by &enera%i'ation or specia%i'ation (i.e., inheritance)

re%ationships#

• Component-and-connector structures.

ere the e%eents are runtie coponents ("hich are the principa% units o!

coputation) and connectors ("hich are the counication 0ehic%es aon&

coponents). oponentandconnector structures he%p ans"er +uestions such as hat

are the aCor eecutin& coponents and ho" do they interact# hat are the aCor shared

data stores# hich parts o! the syste are rep%icated# o" does data pro&ress throu&h

the syste# hat parts o! the syste can run in para%%e%# o" can the syste6s structure

chan&e as it eecutes#

8/17/2019 IT6602 - SA


• Allocation structures.

A%%ocation structures sho" the re%ationship bet"een the so!t"are e%eents and thee%eents in one or ore eterna% en0ironents in "hich the so!t"are is created and

eecuted. They ans"er +uestions such as hat processor does each so!t"are e%eent

eecute on# In "hat !i%es is each e%eent stored durin& de0e%opent, testin&, and syste

bui%din&# hat is the assi&nent o! so!t"are e%eents to de0e%opent teas#

SOFTWARE STR!CT!RES

MOD!"

Modu%ebased structures inc%ude the !o%%o"in& structures.

Decomposition# The units are odu%es re%ated to each other by the is a subodu%e o!

re%ation, sho"in& ho" %ar&er odu%es are decoposed into sa%%er ones recursi0e%y unti%

they are sa%% enou&h to be easi%y understood. ses# The units are re%ated by the uses re%ation. ;ne unit uses another i! the correctness

o! the !irst re+uires the presence o! a correct 0ersion (as opposed to a stub) o! the second. !ayered# Layers are o!ten desi&ned as abstractions (0irtua% achines) that hide

ip%eentation speci!ics be%o" !ro the %ayers abo0e, en&enderin& portabi%ity. Class or generali$ation# The c%ass structure a%%o"s us to reason about reuse and the

increenta% addition o! !unctiona%ity.

COM%O&"&'-A&D-CO&&"C'O(

oponentandconnector structures inc%ude the !o%%o"in& structures

%rocess or communicating processes: The units here are processes or threads that are

connected "ith each other by counication, synchroni'ation, and/or ec%usion

operations. Concurrency# The concurrency structure is used ear%y in desi&n to identi!y the

re+uireents !or ana&in& the issues associated "ith concurrent eecution. )hared data or repository# This structure coprises coponents and connectors that

create, store, and access persistent data

8/17/2019 IT6602 - SA


Client-server# This is use!u% !or separation o! concerns (supportin& odi!iabi%ity), !or

physica% distribution, and !or %oad ba%ancin& (supportin& runtie per!orance).

A!!OCA'*O&

A%%ocation structures inc%ude the !o%%o"in& structures

Deployment# This 0ie" a%%o"s an en&ineer to reason about per!orance, data inte&rity,

a0ai%abi%ity, and security *mplementation# This is critica% !or the ana&eent o! de0e%opent acti0ities and bui%ds

processes. Wor+ assignment# This structure assi&ns responsibi%ity !or ip%eentin& and inte&ratin&

the odu%es to the appropriate de0e%opent teas.

8/17/2019 IT6602 - SA


RE+ATI$* STR!CT!RES TO EAC OTER

Each o! these structures pro0ides a di!!erent perspecti0e and desi&n hand%e on a syste, and each

is 0a%id and use!u% in its o"n ri&ht. In &enera%, appin&s bet"een structures are any to any.

Indi0idua% structures brin& "ith the the po"er to anipu%ate one or ore +ua%ity attributes.

They represent a po"er!u% separationo! concerns approach !or creatin& the architecture.

WIC STR!CT!RES TO COOSE<

<ruchten6s !our 0ie"s !o%%o":

!ogical. The e%eents are ey abstractions, "hich are ani!ested in the obCectoriented

"or%d as obCects or obCect c%asses. This is a odu%e 0ie". %rocess. This 0ie" addresses concurrency and distribution o! !unctiona%ity. It is a

coponentand connector 0ie". Development. This 0ie" sho"s the or&ani'ation o! so!t"are odu%es, %ibraries,

subsystes, and units o! de0e%opent. It is an a%%ocation 0ie", appin& so!t"are to the

de0e%opent en0ironent. %hysical. This 0ie" aps other e%eents onto processin& and counication nodes and

is a%so an a%%ocation 0ie".

I$F+!E$CE OF SOFTWARE ARCITECT!RE O$ OR*A$I=ATIO$>"OT

"!SI$ESS A$D TEC$ICA+

An architecture is the resu%t o! a set o! business and technica% decisions. There are any

in!%uences at "or in its desi&n, and the rea%i'ation o! these in!%uences "i%% chan&e dependin& on

the en0ironent in "hich the architecture is re+uired to per!or. E0en "ith the sae

re+uireents, hard"are, support so!t"are, and huan resources a0ai%ab%e, an architect desi&nin&

a syste today is %ie%y to desi&n a di!!erent syste than i&ht ha0e been desi&ned !i0e yearsa&o.

ARCITECT!RES ARE I$F+!E$CED "% S%STE( STAEO+DERS

Many peop%e and or&ani'ations interested in the construction o! a so!t"are syste are

re!erred to as staeho%ders. E.&. custoers, end users, de0e%opers, proCect ana&er etc. a0in& an acceptab%e syste in0o%0es properties such as per!orance, re%iabi%ity,

a0ai%abi%ity, p%at!or copatibi%ity, eory uti%i'ation, net"or usa&e, security,

odi!iabi%ity, usabi%ity, and interoperabi%ity "ith other systes as "e%% as beha0ior. The under%yin& prob%e, o! course, is that each staeho%der has di!!erent concerns and

&oa%s, soe o! "hich ay be contradictory. The rea%ity is that the architect o!ten has to !i%% in the b%ans and ediate the con!%icts.

ARCITECT!RES ARE I$F+!E$CED "% TE DE'E+O/I$* OR*A$I=ATIO$S5

Architecture is in!%uenced by the structure or nature o! the de0e%opent or&ani'ation.

There are three c%asses o! in!%uence that coe !ro the de0e%opin& or&ani'ations:

iediate business, %on&ter business and or&ani'ationa% structure.

8/17/2019 IT6602 - SA


An or&ani'ation ay ha0e an iediate business in0estent in certain assets, such as

eistin& architectures and the products based on the. An or&ani'ation ay "ish to ae a %on&ter business in0estent in an in!rastructure

to pursue strate&ic &oa%s and ay re0ie" the proposed syste as one eans o! !inancin&

and etendin& that in!rastructure.

The or&ani'ationa% structure can shape the so!t"are architecture.

ARCITECT!RES ARE I$F+!E$CED "% TE "AC*RO!$D A$D E3/ERIE$CE

OF TE ARCITECTS5

I! the architects !or a syste ha0e had &ood resu%ts usin& a particu%ar architectura%

approach, such as distributed obCects or ip%icit in0ocation, chances are that they "i%% try

that sae approach on a ne" de0e%opent e!!ort. on0erse%y, i! their prior eperience "ith this approach "as disastrous, the architects ay

be re%uctant to try it a&ain. Architectura% choices ay a%so coe !ro an architectNs education and trainin&, eposure

to success!u% architectura% patterns, or eposure to systes that ha0e "ored particu%ar%y

poor%y or particu%ar%y "e%%.

The architects ay a%so "ish to eperient "ith an architectura% pattern or techni+ue

%earned !ro a boo or a course.

ARCITECT!RES ARE I$F+!E$CED "% TE TEC$ICA+ E$'IRO$(E$T

A specia% case o! the architectNs bac&round and eperience is re!%ected by the technical

environment .

The en0ironent that is current "hen an architecture is desi&ned "i%% in!%uence that

architecture. It i&ht inc%ude standard industry practices or so!t"are en&ineerin& pre0a%ent in the architectNs pro!essiona% counity.

RA(IFICATIO$S OF I$F+!E$CES O$ A$ ARCITECT!RE

The in!%uences on the architect, and hence on the architecture, are sho"n in *i&ure 4..

8/17/2019 IT6602 - SA


In!%uences on an architecture coe !ro a "ide 0ariety o! sources. Soe are on%y ip%ied, "hi%e

others are ep%icit%y in con!%ict.

Architects need to no" and understand the nature, source, and priority o! constraints on

the proCect as ear%y as possib%e.

There!ore, they must identify and actively engage the stakeholders to solicit their needs

and expectations.

Architects are in!%uenced by the re+uireents !or the product as deri0ed !ro its

staeho%ders, the structure and &oa%s o! the de0e%opin& or&ani'ation, the a0ai%ab%e

technica% en0ironent, and their o"n bac&round and eperience.

TE ARCITECT!RE AFFECTS TE FACTORS TAT I$F+!E$CE TE(

1e%ationships aon& business &oa%s, product re+uireents, architects eperience,

architectures and !ie%ded systes !or a cyc%e "ith !eedbac %oops that a business can

ana&e.

A business ana&es this cyc%e to hand%e &ro"th, to epand its enterprise area, and to tae

ad0anta&e o! pre0ious in0estents in architecture and syste bui%din&.

TE ARCITECT!RE "!SI$ESS C%C+E

The so!t"are architecture o! a pro&ra or coputin& syste is the structure or structures

o! the syste, "hich coprise so!t"are e%eents, the eterna%%y 0isib%e properties o! thosee%eents, and the re%ationships aon& the.

8/17/2019 IT6602 - SA


*i&ure sho"s the !eedbac %oops. Soe o! the !eedbac coes !ro the architecture

itse%!, and soe coes !ro the syste bui%t !ro it. So!t"are architecture is a resu%t o! technica%, business and socia% in!%uences. Its eistence

in turn a!!ects the technica%, business and socia% en0ironents that subse+uent%y in!%uence

!uture architectures.

This cyc%e o! in!%uences, !ro en0ironent to the architecture and bac to the en0ironent, the

Architecture usiness Cycle AC.

o" or&ani'ationa% &oa%s in!%uence re+uireents and de0e%opent strate&y.

o" re+uireents %ead to architecture. o" architectures are ana%y'ed.

o" architectures yie%d systes that su&&est ne" or&ani'ationa% capabi%ities and

re+uireents.

Wor?ing of architect8re 78:ine:: cycle4

4. The architecture a!!ects the structure o! the de0e%opin& or&ani'ation. An architecture

prescribes a structure !or a syste it particu%ar%y prescribes the units o! so!t"are that ust

be ip%eented and inte&rated to !or the syste. Teas are !ored !or indi0idua%

so!t"are unitsO and the de0e%opent, test, and inte&ration acti0ities around the units.

Lie"ise, schedu%es and bud&ets a%%ocate resources in chuns correspondin& to the units.

Teas becoe ebedded in the or&ani'ationNs structure. This is !eedbac !ro the

architecture to the de0e%opin& or&ani'ation.?. The architecture can a!!ect the &oa%s o! the de0e%opin& or&ani'ation. A success!u% syste

bui%t !ro it can enab%e a copany to estab%ish a !ootho%d in a particu%ar aret area. The

architecture can pro0ide opportunities !or the e!!icient production and dep%oyent o! the

sii%ar systes, and the or&ani'ation ay adCust its &oa%s to tae ad0anta&e o! its

8/17/2019 IT6602 - SA


ne"!ound epertise to p%ub the aret. This is !eedbac !ro the syste to the

de0e%opin& or&ani'ation and the systes it bui%ds.

. The architecture can a!!ect custoer re+uireents !or the net syste by &i0in& the

custoer the opportunity to recei0e a syste in a ore re%iab%e, tie%y and econoica%

anner than i! the subse+uent syste "ere to be bui%t !ro scratch.

2. The process o! syste bui%din& "i%% a!!ect the architectNs eperience "ith subse+uentsystes by addin& to the corporate eperience base.

G. A !e" systes "i%% in!%uence and actua%%y chan&e the so!t"are en&ineerin& cu%ture. i.e,

The technica% en0ironent in "hich syste bui%ders operate and %earn.

SOFTWARE /ROCESSES A$D TE ARCITECT!RE "!SI$ESS C%C+E

Software process is the ter &i0en to the or&ani'ation, reuti%i'ation, and ana&eent o!

so!t"are de0e%opent acti0ities.

The 0arious acti0ities in0o%0ed in creatin& so!t"are architecture are:

Creating the 78:ine:: ca:e for the :y:tem

• It is an iportant step in creatin& and constrainin& any !uture re+uireents.

• o" uch shou%d the product cost#

• hat is its tar&eted aret#

• hat is its tar&eted tie to aret#

• i%% it need to inter!ace "ith other systes#

• Are there syste %iitations that it ust "or "ithin#

• These are a%% the +uestions that ust in0o%0e the systeNs architects.

• They cannot be decided so%e%y by an architect, but i! an architect is not consu%ted in the

creation o! the business case, it ay be ipossib%e to achie0e the business &oa%s.

!n@er:tan@ing the re8irement:• There are a 0ariety o! techni+ues !or e%icitin& re+uireents !ro the staeho%ders.

• *or e:

4. ;bCect oriented ana%ysis uses scenarios, or =use cases> to ebody re+uireents.

?. Sa!etycritica% systes use ore ri&orous approaches, such as !initestateachine

ode%s or !ora% speci!ication %an&ua&es.

• Another techni+ue that he%ps us understand re+uireents is the creation o! prototypes.

• 1e&ard%ess o! the techni+ue used to e%icit the re+uireents, the desired +ua%ities o! the

syste to be constructed deterine the shape o! its structure.

Creating or :electing the architect8re

In the %andar boo The Mythical Man-Month, *red Broos ar&ues !orce!u%%y ande%o+uent%y that conceptua% inte&rity is the ey to sound syste desi&n and that conceptua%

inte&rity can on%y be had by a sa%% nuber o! inds coin& to&ether to desi&n the syste6s

architecture.

Doc8menting an@ comm8nicating the architect8re

• *or the architecture to be e!!ecti0e as the bacbone o! the proCectNs desi&n, it ust be

counicated c%ear%y and unabi&uous%y to a%% o! the staeho%ders.

8/17/2019 IT6602 - SA


• $e0e%opers ust understand the "or assi&nents it re+uires o! the, testers ust

understand the tas structure it iposes on the, ana&eent ust understand the

schedu%in& ip%ications it su&&ests, and so !orth.

AnalyBing or e9al8ating the architect8re

• hoosin& aon& u%tip%e copetin& desi&ns in a rationa% "ay is one o! the architectNs

&reatest cha%%en&es.

• E0a%uatin& an architecture !or the +ua%ities that it supports is essentia% to ensurin& that the

syste constructed !ro that architecture satis!ies its staeho%ders needs.

• 5se scenariobased techni+ues or architecture tradeo!! ana%ysis ethod (ATAM) or cost

bene!it ana%ysis ethod (BAM).

Implementing the :y:tem 7a:e@ on the architect8re

• This acti0ity is concerned "ith eepin& the de0e%opers !aith!u% to the structures and

interaction protoco%s constrained by the architecture.

• a0in& an ep%icit and "e%%counicated architecture is the !irst step to"ard ensurin&

architectura% con!orance.En:8ring that the implementation conform: to the architect8re

• *ina%%y, "hen an architecture is created and used, it &oes into a aintenance phase.

onstant 0i&i%ance is re+uired to ensure that the actua% architecture and its representation

reain to each other durin& this phase.

WAT (AES A *OOD ARCITECT!RE

7i0en the sae technica% re+uireents !or a syste, t"o di!!erent architects in di!!erent

or&ani'ations "i%% produce di!!erent architectures, ho" can "e deterine i! either one o! the is

the ri&ht one#

e di0ide our obser0ations into t"o c%usters: process recoendations and product (or

structura%) recoendations.

/roce:: recommen@ation: are a: follo;:4

The architecture shou%d be the product o! a sin&%e architect or a sa%% &roup o! architects

"ith an identi!ied %eader. The architect (or architecture tea) shou%d ha0e the !unctiona% re+uireents !or the

syste and an articu%ated, prioriti'ed %ist o! +ua%ity attributes that the architecture is

epected to satis!y. The architecture shou%d be "e%% docuented, "ith at %east one static 0ie" and one

dynaic 0ie", usin& an a&reedon notation that a%% staeho%ders can understand "ith a

iniu o! e!!ort. The architecture shou%d be circu%ated to the systeNs staeho%ders, "ho shou%d be

acti0e%y in0o%0ed in its re0ie". The architecture shou%d be ana%y'ed !or app%icab%e +uantitati0e easures (such as

aiu throu&hput) and !ora%%y e0a%uated !or +ua%ity attributes be!ore it is too %ate to

ae chan&es to it.

8/17/2019 IT6602 - SA


The architecture shou%d %end itse%! to increenta% ip%eentation 0ia the creation o! a

=se%eta%> syste in "hich the counication paths are eercised but "hich at !irst has

inia% !unctiona%ity. This se%eta% syste can then be used to =&ro"> the syste

increenta%%y, easin& the inte&ration and testin& e!!orts.

The architecture shou%d resu%t in a speci!ic (and sa%%) set o! resource contention areas,

the reso%ution o! "hich is c%ear%y speci!ied, circu%ated and aintained.

/ro@8ct ):tr8ct8ral. recommen@ation: are a: follo;:4

The architecture shou%d !eature "e%%de!ined odu%es "hose !unctiona% responsibi%ities

are a%%ocated on the princip%es o! in!oration hidin& and separation o! concerns. Each odu%e shou%d ha0e a "e%%de!ined inter!ace that encapsu%ates or =hides>

chan&eab%e aspects !ro other so!t"are that uses its !aci%ities. These inter!aces shou%d

a%%o" their respecti0e de0e%opent teas to "or %ar&e%y independent o! each other. -ua%ity attributes shou%d be achie0ed usin& "e%%no"n architectura% tactics speci!ic to

each attribute. The architecture shou%d ne0er depend on a particu%ar 0ersion o! a coercia% product or

too%. Modu%es that produce data shou%d be separate !ro odu%es that consue data. This

tends to increase odi!iabi%ity. *or para%%e% processin& systes, the architecture shou%d !eature "e%%de!ined processors

or tass that do not necessari%y irror the odu%e decoposition structure. E0ery tas or process shou%d be "ritten so that its assi&nent to a speci!ic processor can

be easi%y chan&ed, perhaps e0en at runtie.

The architecture shou%d !eature a sa%% nuber o! sip%e interaction patterns.

F8nctional re8irement:

Each chi%d odu%e has responsibi%ities that deri0e partia%%y !ro considerin&

decoposition o! the !unctiona% re+uireents. Those responsibi%ities can be trans%ated into use

cases !or the odu%e. Another "ay o! de!inin& use cases is to sp%it and re!ine the parent use

cases. *or eap%e, a use case that initia%i'es the "ho%e syste is broen into the initia%i'ations

o! subsystes. This approach has traceabi%ity because an ana%yst can !o%%o" the re!ineent.

In our eap%e, the initia% responsibi%ities !or the &ara&e door opener "ere to open and c%ose

the door on re+uest, either %oca%%y or reote%yO to stop the door "ithin @.4 second "hen an

obstac%e is detectedO and to interact "ith the hoe in!oration syste and support reote

dia&nostics. The responsibi%ities are decoposed into the !o%%o"in& !unctiona% &roups

correspondin& to the odu%es:

• 5ser inter!ace. 1eco&ni'e user re+uests and trans%ate the into the !or epected by the

raisin&/%o"erin& door odu%e.

8/17/2019 IT6602 - SA


• 1aisin&/%o"erin& door odu%e. ontro% actuators to raise or %o"er the door. Stop the door

"hen it reaches either !u%%y open or !u%%y c%osed.

• ;bstac%e detection. 1eco&ni'e "hen an obstac%e is detected and either stop the descent o!

the door or re0erse it.

• ounication 0irtua% achine. Mana&e a%% counication "ith the hoe in!oration

syste.

• Sensor/actuator 0irtua% achine. Mana&e a%% interactions "ith the sensors and actuators.

• Schedu%er. 7uarantee that the obstac%e detector "i%% eet its dead%ines.

$ia&nosis. Mana&e the interactions "ith the hoe in!oration syste de0oted to

dia&nosis.

Con:traint:

onstraints o! the parent odu%e can be satis!ied in one o! the !o%%o"in& "ays:

• The decoposition satis!ies the constraint. *or eap%e, the constraint o! usin& a certain

operatin& syste can be satis!ied by de!inin& the operatin& syste as a chi%d odu%e. Theconstraint has been satis!ied and nothin& ore needs to be done.

• The constraint is satis!ied by a sin&%e chi%d odu%e. *or eap%e, the constraint o! usin& a

specia% protoco% can be satis!ied by de!inin& an encapsu%ation chi%d odu%e !or the

protoco%. The constraint has been desi&nated a chi%d. hether it is satis!ied or not

depends on "hat happens "ith the decoposition o! the chi%d.

• The constraint is satis!ied by u%tip%e chi%d odu%es. *or eap%e, usin& the eb

re+uires t"o odu%es (c%ient and ser0er) to ip%eent the necessary protoco%s. hether

the constraint is satis!ied depends on the decoposition and coordination o! the chi%dren

to "hich the constraint has been assi&ned.

In our eap%e, one constraint is that the counication "ith the hoe in!oration systeis aintained. The counication 0irtua% achine "i%% reco&ni'e i! this counication is

una0ai%ab%e, so the constraint is satis!ied by a sin&%e chi%d.

1!A+IT% ATTRI"!TESTo be eanin&!u%, +ua%ity attribute re+uireents ust be specic about ho" an

app%ication shou%d achie0e a &i0en need. A coon prob%e I re&u%ar%y encounter in

architectura% docuents is a &enera% stateent such as =The app%ication ust be sca%ab%e>.

/erformance

A per!orance +ua%ity re+uireent denes a etric that states the aount o! "or an

app%ication ust per!or in a &i0en tie, and/or dead%ines that ust be et !or correct

operation.

Thro8ghp8t

Throu&hput is a easure o! the aount o! "or an app%ication ust per!or in unit tie.

or is typica%%y easured in transactions per second (tps), or essa&es processed per second

(ps). *or eap%e, an on%ine banin& app%ication i&ht ha0e to &uarantee it can eecute 4,@@@

8/17/2019 IT6602 - SA


tps !ro Internet banin& custoers. An in0entory ana&eent syste !or a %ar&e "arehouse

i&ht need to process G@ essa&es per second !ro tradin& partners re+uestin& orders.

Re:pon:e Time

This is a easure o! the %atency an app%ication ehibits in processin& a business

transaction. 1esponse tie is ost o!ten (but not ec%usi0e%y) associated "ith the tie an

app%ication taes to respond to soe input. A rapid response tie a%%o"s users to "or ore

e!!ecti0e%y, and conse+uent%y is &ood !or business.

An ece%%ent eap%e is a pointo!sa%e app%ication supportin& a %ar&e store. hen an

ite is scanned at the checout, a !ast, second or %ess response !ro the syste "ith the iteNs

price eans a custoer can be ser0ed +uic%y. This aes the custoer and the store happy, and

thatNs a &ood thin& !or a%% in0o%0ed staeho%ders.

Scala7ility

o" "e%% a so%ution to soe prob%e "i%% "or "hen the si'e o! the prob%e increases.

This is use!u% in an architectura% contet. It te%%s us that sca%abi%ity is about ho" a desi&n can

cope "ith soe aspect o! the app%icationNs re+uireents increasin& in si'e.

Re8e:t +oa@

In the per!ect "or%d and "ithout additiona% hard"are capacity, as the %oad increases,

app%ication throu&hput shou%d reain constant (i.e., 4@@ tps), and response tie per re+uest

shou%d increase on%y %inear%y (i.e., 4@ s).

A sca%ab%e so%ution "i%% then perit additiona% processin& capacity to be dep%oyed to

increase throu&hput and decrease response tie. This additiona% capacity ay be dep%oyed int"o di!!erent "ays, one by addin& ore P5s (and %ie%y eory) to the achine the

app%ications runs on (sca%e up), the other !ro distributin& the app%ication on u%tip%e achines

(sca%e out).

(o@ia7ility

The odiabi%ity +ua%ity attribute is a easure o! ho" easy it ay be to chan&e an

app%ication to cater !or ne" !unctiona% and non!unctiona% re+uireents. 9ote the use o! =ay> in

the pre0ious sentence. Predictin& odiabi%ity re+uires an estiate o! e!!ort and/or cost to ae

a chan&e. ou on%y no" !or sure "hat a chan&e "i%% cost a!ter it has been ade. Then you nd

out ho" &ood your estiate "as.

Modiabi%ity easures are on%y re%e0ant in the contet o! a &i0en architectura% so%ution.

This so%ution ust be epressed at %east structura%%y as a co%%ection o! coponents, the

coponent re%ationships and a description o! ho" the coponents interact "ith the en0ironent.

Then, assessin& Modiabi%ity re+uires the architect to assert %ie%y chan&e scenarios that capture

ho" the re+uireents ay e0o%0e.

han&e scenarios are:

8/17/2019 IT6602 - SA


• Pro0ide access to the app%ication throu&h re"a%%s in addition to eistin& =behind the

re"a%%> access.

• Incorporate ne" !eatures !or se%!ser0ice checout ioss.

• The ;TS speech reco&nition so!t"are 0endor &oes out o! business and "e need to

rep%ace this coponent.

• The app%ication needs to be ported !ro Linu to the Microso!t indo"s p%at!or.

Sec8rity

Security is a cop%e technica% topic that can on%y be treated soe"hat supercia%%y

here. At the architectura% %e0e%, security boi%s do"n to understandin& the precise security

re+uireents !or an app%ication, and de0isin& echaniss to support the.

The ost coon securityre%ated re+uireents are:

• Authentication: App%ications can 0eri!y the identity o! their users and other

app%ications "ith "hich they counicate.

• Authori'ation: Authenticated users and app%ications ha0e dened access ri&hts to the

resources o! the syste. *or eap%e, soe users ay ha0e readon%y access to theapp%icationNs data, "hi%e others ha0e read–"rite.

• Encryption: The essa&es sent to/!ro the app%ication are encrypted.

• Inte&rity: This ensures the contents o! a essa&e are not a%tered in transit.

• 9onrepudiation: The sender o! a essa&e has proo! o! de%i0ery and the recei0er is

assured o! the senderNs identity. This eans neither can subse+uent%y re!ute their

participation in the essa&e echan&e.

A9aila7ility

A0ai%abi%ity is re%ated to an app%icationNs re%iabi%ity. I! an app%ication isnNt a0ai%ab%e !or

use "hen needed, then itNs un%ie%y to be !u%%%in& its !unctiona% re+uireents. A0ai%abi%ity isre%ati0e%y easy to speci!y and easure.

*ai%ures in app%ications cause the to be una0ai%ab%e. *ai%ures ipact on an app%icationNs

re%iabi%ity, "hich is usua%%y easured by the ean tie bet"een !ai%ures. The %en&th o! tie any

period o! una0ai%abi%ity %asts is deterined by the aount o! tie it taes to detect !ai%ure and

restart the syste. onse+uent%y, app%ications that re+uire hi&h a0ai%abi%ity inii'e or

pre!erab%y e%iinate sin&%e points o! !ai%ure, and institute echaniss that autoatica%%y detect

!ai%ure and restart the !ai%ed coponents.

Other 18ality Attri78te:

There are nuerous other +ua%ity attributes that are iportant in 0arious app%icationcontets. Soe o! these are:

• Portabi%ity: an an app%ication be easi%y eecuted on a di!!erent so!t"are/ hard"are

p%at!or to the one it has been de0e%oped !or# Portabi%ity depends on the choices o!

so!t"are techno%o&y used to ip%eent the app%ication, and the characteristics o! the

p%at!ors that it needs to eecute on. Easi%y portab%e code bases "i%% ha0e their p%at!or

8/17/2019 IT6602 - SA


dependencies iso%ated and encapsu%ated in a sa%% set o! coponents that can be rep%aced

"ithout a!!ectin& the rest o! the app%ication.

• Testabi%ity: o" easy or di!cu%t is an app%ication to test# Ear%y desi&n decisions can

&reat%y a!!ect the aount o! test cases that are re+uired. As a ru%e o! thub, the ore

cop%e a desi&n, the ore di!cu%t it is to thorou&h%y test. Sip%icity tends to proote

ease o! testin&. Lie"ise, "ritin& %ess o! your o"n code by incorporatin& pretested

coponents reduces test e!!ort.

• Supportabi%ity: This is a easure o! ho" easy an app%ication is to support once it is

dep%oyed. Support typica%%y in0o%0es dia&nosin& and in& prob%es that occur durin&

app%ication use. Supportab%e systes tend to pro0ide ep%icit !aci%ities !or dia&nosis, such

as app%ication error %o&s that record the causes o! !ai%ures. They are a%so bui%t in a

odu%ar !ashion so that code es can be dep%oyed "ithout se0ere%y incon0eniencin&

app%ication use.

8/17/2019 IT6602 - SA


!$IT II

1!A+IT% ATTRI"!TE WORSO/

1!A+IT% ATTRI"!TE WORSO/

The -A is one "ay to disco0er, docuent, and prioriti'e a systeNs +ua%ity attributes

ear%y in its %i!e cyc%e. This is the third edition o! a technica% report describin& the -A. e ha0e

narro"ed the scope o! a -A to the creation o! prioriti'ed and re!ined scenarios. This report

describes the ne"%y re0ised -A and describes potentia% uses o! the re!ined scenarios &enerated

durin& it.

The -ua%ity Attribute orshop (-A) is a !aci%itated ethod that en&a&es syste

staeho%ders ear%y in the syste de0e%opent %i!e cyc%e to disco0er the dri0in& +ua%ity attributes

o! a so!t"areintensi0e syste. The -A is systecentric and staeho%der !ocusedO it is used

be!ore the so!t"are architecture has been created. The -A pro0ides an opportunity to &ather

staeho%ders to&ether to pro0ide input about their needs and epectations "ith respect to ey

+ua%ity attributes that are o! particu%ar concern to the

Both the syste and so!t"are architectures are ey to rea%i'in& +ua%ity attribute re+uireents in

the ip%eentation. A%thou&h architecture cannot &uarantee that an ip%eentation "i%% eet its

+ua%ity attribute &oa%s, the "ron& architecture "i%% sure%y spe%% disaster. As an eap%e, consider security. It is di!!icu%t, aybe e0en ipossib%e, to add e!!ecti0e security to a syste as an

a!terthou&ht. oponents as "e%% as counication echaniss and paths ust be desi&ned or

se%ected ear%y in the %i!e cyc%e to satis!y security re+uireents. The critica% +ua%ity attributes ust

be "e%% understood and articu%ated ear%y in the de0e%opent o! a syste, so the architect can

desi&n an architecture that "i%% satis!y the. The -A is one "ay to disco0er, docuent, and

prioriti'e a systeNs +ua%ity attributes ear%y in its %i!e cyc%e.

8/17/2019 IT6602 - SA


It is iportant to point out that "e do not ai at an abso%ute easure o! +ua%ityO rather

our purpose is to identi!y scenarios !ro the point o! 0ie" o! a di0erse &roup o! staeho%ders

(e.&., architects, de0e%opers, users, sponsors). These scenarios can then be used by the syste

en&ineers to ana%y'e the systeNs architecture and identi!y concerns (e.&., inade+uate

per!orance, success!u% denia%o!ser0ice attacs) and possib%e iti&ation strate&ies (e.&.,

prototypin&, ode%in&, and siu%ation).

1AW (etho@

The -A is a !aci%itated, ear%y inter0ention ethod used to &enerate, prioriti'e, and

re!ine +ua%ity attribute scenarios be!ore the so!t"are architecture is cop%eted. The -A is

!ocused on syste%e0e% concerns and speci!ica%%y the ro%e that so!t"are "i%% p%ay in the syste.

The -A is dependent on the participation o! syste staeho%dersindi0idua%s on "ho the

syste has si&ni!icant ipact, such as end users, insta%%ers, adinistrators (o! database

ana&eent systes Q$BMSR, net"ors, he%p dess, etc.), trainers, architects, ac+uirers, syste

and so!t"are en&ineers, and others. The &roup o! staeho%ders present durin& any one -Ashou%d nuber at %east G and no ore than @ !or a sin&%e "orshop. In preparation !or the

"orshop, staeho%ders recei0e a =participantNs handboo> pro0idin& eap%e +ua%ity attribute

taonoies, +uestions, and scenarios. I! tie a%%o"s, the handboo shou%d be custoi'ed to the

doain o! the syste and contain the +ua%ity attributes, +uestions, and scenarios that are

appropriate to the doain and the %e0e% o! architectura% detai% a0ai%ab%e.

The contribution o! each staeho%der is essentia% durin& a -AO a%% participants are epected to

be !u%%y en&a&ed and present throu&hout the "orshop. Participants are encoura&ed to coent

and as +uestions at any tie durin& the "orshop. o"e0er, it is iportant to reco&ni'e that

!aci%itators ay occasiona%%y ha0e to cut discussions short in the interest o! tie or "hen it isc%ear that the discussion is not !ocused on the re+uired -A outcoes. The -A is an intense

and deandin& acti0ity. It is 0ery iportant that a%% participants stay !ocused, are one tie, and

%iit side discussions throu&hout the day.

The -A in0o%0es the !o%%o"in& steps:

4. -A Presentation and Introductions

?. Business/Mission Presentation

. Architectura% P%an Presentation

2. Identi!ication o! Architectura% $ri0ers

G. Scenario Brainstorin&

H. Scenario onso%idation

F. Scenario Prioriti'ation

. Scenario 1e!ineent

8/17/2019 IT6602 - SA


The !o%%o"in& sections describe each step o! the -A in detai%.

Step ,4 1AW /re:entation an@ Intro@8ction:

In this step, -A !aci%itators describe the oti0ation !or the -A and ep%ain each step

o! the ethod. e recoend usin& a standard s%ide presentation that can be custoi'ed

dependin& on the needs o! the sponsor. 9et, the !aci%itators introduce these%0es and thestaeho%ders do %ie"ise, brie!%y statin& their bac&round, their ro%e in the or&ani'ation, and their

re%ationship to the syste bein& bui%t.

Step 24 "8:ine::&(i::ion /re:entation

A!ter Step 4, a representati0e o! the staeho%der counity presents the business and/or

ission dri0ers !or the syste. The ter =business and/or ission dri0ers> is used care!u%%y here.

Soe or&ani'ations are c%ear%y oti0ated by business concerns such as pro!itabi%ity, "hi%e

others, such as &o0ernenta% or&ani'ations, are oti0ated by ission concerns and !ind

pro!itabi%ity eanin&%ess. The staeho%der representin& the business and/or ission concerns

(typica%%y a ana&er or ana&eent representati0e) spends about one hour presentin&

• the systeNs business/ission contet

• hi&h%e0e% !unctiona% re+uireents, constraints, and +ua%ity attribute re+uireents

$urin& the presentation, the !aci%itators %isten care!u%%y and capture any re%e0ant in!oration

that ay shed %i&ht on the +ua%ity attribute dri0ers. The +ua%ity attributes that "i%% be re!ined in

%ater steps "i%% be deri0ed %ar&e%y !ro the business/ission needs presented in this step.

Step -4 Architect8ral /lan /re:entation

hi%e detai%ed syste architecture i&ht not eist, it is possib%e that hi&h%e0e% syste

description, contet dra"in&s, or other arti!acts ha0e been created that describe soe o! thesysteNs technica% detai%s. At this point in the "orshop, a technica% staeho%der "i%% present the

syste architectura% p%ans as they stand "ith respect to these ear%y docuents. In!oration in

this presentation ay inc%ude

• p%ans and strate&ies !or ho" ey business/ission re+uireents "i%% be satis!ied

• ey technica% re+uireents and constraintssuch as andated operatin& systes,

hard"are, idd%e"are, and standardsthat "i%% dri0e architectura% decisions

• presentation o! eistin& contet dia&ras, hi&h%e0e% syste dia&ras, and other "ritten

descriptions

Step 4 I@entification of Architect8ral Dri9er:

$urin& steps ? and , the !aci%itators capture in!oration re&ardin& architectura% dri0ers

that are ey to rea%i'in& +ua%ity attribute &oa%s in the syste. These dri0ers o!ten inc%ude hi&h

%e0e% re+uireents, business/ission concerns, &oa%s and obCecti0es, and 0arious +ua%ity

attributes. Be!ore undertain& this step, the !aci%itators shou%d ecuse the &roup !or a 4Ginute

brea, durin& "hich they "i%% caucus to copare and conso%idate notes taen durin& steps ? and

. hen the staeho%ders recon0ene, the !aci%itators "i%% share their %ist o! ey architectura%

8/17/2019 IT6602 - SA


dri0ers and as the staeho%ders !or c%ari!ications, additions, de%etions, and corrections. The idea

is to reach a consensus on a disti%%ed %ist o! architectura% dri0ers that inc%ude hi&h%e0e%

re+uireents, business dri0ers, constraints, and +ua%ity attributes. The !ina% %ist o! architectura%

dri0ers "i%% he%p !ocus the staeho%ders durin& scenario brainstorin& to ensure that these

concerns are represented by the scenarios co%%ected.

Step G4 Scenario "rain:torming

A!ter the architectura% dri0ers ha0e been identi!ied, the !aci%itators initiate the

brainstorin& process in "hich staeho%ders &enerate scenarios. The !aci%itators re0ie" the parts

o! a &ood scenario (stiu%us, en0ironent, and response) and ensure that each scenario is "e%%

!ored durin& the "orshop.

Each staeho%der epresses a scenario representin& his or her concerns "ith respect to the

syste in roundrobin !ashion. $urin& a noina% -A, at %east t"o roundrobin passes are ade

so that each staeho%der can contribute at %east t"o scenarios. The !aci%itators ensure that at%eastone representati0e scenario eists !or each architectura% dri0er %isted in Step 2.Scenario

&eneration is a ey step in the -A ethod and ust be carried out "ith care.

e su&&est the !o%%o"in& &uidance to he%p -A !aci%itators durin& this step:

4. *aci%itators shou%d he%p staeho%ders create "e%%!ored scenarios. It is teptin& !or

staeho%ders to recite re+uireents such as =The syste sha%% produce reports !or

users.>hi%e this is an iportant re+uireent, !aci%itators need to ensure that the +ua%ity

attribute aspects o! this re+uireent are ep%ored !urther. *or eap%e, the !o%%o"in&

scenario sheds ore %i&ht on the per!orance aspect o! this re+uireent: = A remote user

reuests a database report via the !eb during peak usage and receives the report within five seconds.>9ote that the initia% re+uireent hasnNt been %ost, but the scenario !urther

ep%ores the per!orance aspect o! this re+uireent. *aci%itators shou%d note that +ua%ity

attribute naes by these%0es are not enou&h. 1ather than say = the system shall be

modifiable,> the scenario shou%d describe "hat it eans to be odi!iab%e by pro0idin& a

speci!ic eap%e o! a odi!ication to the syste 0is0is a scenario.

?. The 0ocabu%ary used to describe +ua%ity attributes 0aries "ide%y. eated debates o!ten

re0o%0e around to "hich +ua%ity attribute a particu%ar syste property be%on&s. It doesnNt

atter "hat "e ca%% a particu%ar +ua%ity attribute, as %on& as thereNs a scenario that

describes "hat it eans.

. *aci%itators need to reeber that there are three &enera% types o! scenarios and to ensure

that each type is co0ered durin& the -A:

a. use case scenarios in0o%0in& anticipated uses o! the syste

b. &ro"th scenarios in0o%0in& anticipated chan&es to the syste

c. ep%oratory scenarios in0o%0in& unanticipated stresses to the syste that can

inc%ude uses and/or chan&es

8/17/2019 IT6602 - SA


2. *aci%itators shou%d re!er to the %ist o! architectura% dri0ers &enerated in Step 2 !ro

tie to tie durin& scenario brainstorin& to ensure that representati0e scenarios eist

!or each one.

Step 64 Scenario Con:oli@ation

A!ter the scenario brainstorin&, sii%ar scenarios are conso%idated "hen reasonab%e. To

do that, !aci%itators as staeho%ders to identi!y those scenarios that are 0ery sii%ar in content.

Scenarios that are sii%ar are er&ed, as %on& as the peop%e "ho proposed the a&ree and !ee%s

that their scenarios "i%% not be di%uted in the process. onso%idation is an iportant step because

it he%ps to pre0ent a =di%ution> o! 0otes durin& the prioriti'ation o! scenarios (Step F).Such a

di%ution occurs "hen staeho%ders sp%it their 0otes bet"een t"o 0ery sii%ar scenarios .As a

resu%t, neither scenario rises to iportance and is there!ore ne0er re!ined (Step ). o"e0er, i!

the t"o scenarios are sii%ar enou&h to be er&ed into one, the 0otes i&ht be concentrated, and

the er&ed scenario ay then rise to the appropriate %e0e% o! iportance and be re!ined !urther.

*aci%itators shou%d ae e0ery attept to reach a aCority consensus "ith the staeho%ders be!ore er&in& scenarios. Thou&h staeho%ders ay be tepted to er&e scenarios "ith

abandon, they shou%d not do so. In actua%ity, 0ery !e" scenarios are er&ed.

Step H4 Scenario /rioritiBation

Prioriti'ation o! the scenarios is accop%ished by a%%ocatin& each staeho%der a nuber o!

0otes e+ua% to @U o! the tota% nuber o! scenarios &enerated a!ter conso%idation. The actua%

nuber o! 0otes a%%ocated to staeho%ders is rounded to an e0en nuber o! 0otes at the discretion

o! the !aci%itators. *or eap%e, i! @ scenarios "ere &enerated, each staeho%der &ets @ @., or

K, 0otes rounded up to 4@. 8otin& is done in roundrobin !ashion, in t"o passes. . Staeho%ders

can a%%ocate any nuber o! their 0otes to any scenario or cobination o! scenarios. The 0otes arecounted, and the scenarios are prioriti'ed accordin&%y.

Step 4 Scenario Refinement

A!ter the prioriti'ation, dependin& on the aount o! tie reainin&, the top !our or !i0e

scenarios are re!ined in ore detai%. *aci%itators !urther e%aborate each one, docuentin& the

!o%%o"in&:

*urther c%ari!y the scenario by c%ear%y describin& the !o%%o"in& si thin&s:

4. stiu%us the condition that a!!ects the syste

?. response the acti0ity that resu%ts !ro the stiu%us

. source o! stiu%us the entity that &enerated the stiu%us

2. en0ironent the condition under "hich the stiu%us occurred

G. arti!act stiu%ated the arti!act that "as stiu%ated

H. response easure the easure by "hich the systeNs response "i%% be e0a%uated

V $escribe the business/ission &oa%s that are a!!ected by the scenario.

V $escribe the re%e0ant +ua%ity attributes associated "ith the scenario.

8/17/2019 IT6602 - SA


V A%%o" the staeho%ders to pose +uestions and raise any issues re&ardin& the scenario. Such

+uestions shou%d concentrate on the +ua%ity attribute aspects o! the scenario and any concerns

that the staeho%ders i&ht ha0e in achie0in& the response ca%%ed !or in the scenario. See the

eap%e tep%ate !or scenario re!ineent in Appendi A. This step continues unti% tie runs out

or the hi&hest priority scenarios ha0e been re!ined. Typica%%y, tie runs out !irst.

1AW "enefit:

The -A pro0ides a !oru !or a "ide 0ariety o! staeho%ders to &ather in one roo at onetie

0ery ear%y in the de0e%opent process. It is o!ten the !irst tie such a eetin& taes p%ace and

&enera%%y %eads to the identi!ication o! con!%ictin& assuptions about syste re+uireents. In

addition to c%ari!yin& +ua%ity attribute re+uireents, the -A pro0ides increased staeho%der

counication, an in!ored basis !or architectura% decisions, ipro0ed architectura%

docuentation, and support !or ana%ysis and testin& throu&hout the %i!e o! the syste.

The resu%ts o! a -A inc%ude• a %ist o! architectura% dri0ers

• the ra" scenarios

• the prioriti'ed %ist o! ra" scenarios

• the re!ined scenarios

This in!oration can be used to

• update the or&ani'ationNs architectura% 0ision

• re!ine syste and so!t"are re+uireents

• &uide the de0e%opent o! prototypes

• eercise siu%ations

• understand and c%ari!y the systeNs architectura% dri0ers

• in!%uence the order in "hich the architecture is de0e%oped

• describe the operation o! a syste

In short, the architect can use this in!oration to desi&n the architecture. In addition, a!ter the

architecture is created, the scenarios can be used as part o! a so!t"are architecture e0a%uation. I!

the Architecture Tradeo!! Ana%ysis MethodSM (ATAMSM)2 is se%ected as the so!t"are

architecture e0a%uation ethod, the scenarios &enerated durin& the -A can be incorporated as

seed scenarios in that e0a%uation .

The -A %ends itse%! "e%% to the capture o! any architectura%%y re%e0ant ateria%s. So!t"are

architectura% docuentation is a co%%ection o! 0ie" pacets p%us any docuentation that app%ies

to ore than one 0ie" Q%eents @?bR. Each 0ie" pacet contains a priary presentation, a

cata%o& o! the 0ie"Ns e%eents (inc%udin& e%eent beha0ior), a contet dia&ra, a 0ariabi%ity

8/17/2019 IT6602 - SA


&uide, architecture bac&round (rationa%e, ana%ysis resu%ts, and assuptions about the

en0ironent), and other in!oration inc%udin& appin& to re+uireents.

Se0era% pieces o! this in!oration "i%% be &%eaned direct%y !ro the -A. *or eap%e,

scenario &eneration can %ead to the creation o! use case dia&ras, contet dia&ras, or their

e+ui0a%ent. 1e!ined scenarios can be docuented as se+uence dia&ras or co%%aboration

dia&ras. Staeho%dersN concerns and any other rationa%e in!oration that is captured shou%d be

recorded indi0idua%%y in a !or that can be inc%uded in the appropriate 0ie" pacet or o0er0ie"

docuentation. $etai%s that ep%ain ho" to transition these arti!acts into architectura%

docuentation is the subCect o! on&oin& research. In addition to the ore iediate bene!its

cited abo0e, the scenarios continue to pro0ide bene!its durin& %ater phases o! de0e%opent. They

pro0ide input !or ana%ysis throu&hout the %i!e o! the syste and can be used to dri0e test case

de0e%opent durin& ip%eentation testin&.

DOC!(E$TI$* 1!A+IT% ATTRI"!TES

I$TROD!CTIO$

$e0e%opin& hi&h +ua%ity so!t"are is hard, especia%%y "hen the interpretation o! ter

=+ua%ity> is patchy based on the en0ironent in "hich it is used. In order to no" i! +ua%ity has

been achie0ed, or de&raded, it has to be easured, but deterinin& "hat to easure and ho" is

the di!!icu%t part.

So!t"are -ua%ity Attributes are the benchars that describe systeNs intended beha0ior

"ithin the en0ironent !or "hich it "as bui%t. The +ua%ity attributes pro0ide the eans !or

easurin& the !itness and suitabi%ity o! a product. So!t"are architecture has a pro!ound a!!ect on

ost +ua%ities in one "ay or another, and so!t"are +ua%ity attributes a!!ect architecture.

Identi!yin& desired syste +ua%ities be!ore a syste is bui%t a%%o"s syste desi&ner too%d a so%ution (startin& "ith its architecture) to atch the desired needs o! the syste "ithin

the contet o! constraints (a0ai%ab%e resources, inter!ace "ith %e&acy systes, etc). hen a

desi&ner understands the desired +ua%ities be!ore a syste is bui%t, then the %ie%ihood o!

se%ectin& or creatin& the ri&ht architecture is ipro0ed.

)cenarios

Stateents %ie =a syste "i%% ha0e hi&h per!orance> or =a syste "i%% be user

!riend%y> are acceptab%e in the rea%%y ear%y sta&es o! re+uireents e%icitation process (i.e.

business concept brainstorin&). As ore in!oration becoes a0ai%ab%e, the abo0e stateents

becoe use%ess as they are eanin&%ess !or the purpose o! actua%%y desi&nin& a so%ution. In each

o! the t"o eap%es abo0e an attept is ade to describe the beha0ior o! a syste. Both

stateents are use%ess as they pro0ide no tan&ib%e "ay o! easurin& the beha0ior o! the syste.

The +ua%ity attributes ust be described in ters o! scenarios, such as ="hen 4@@ users

initiate Wcop%ete payentN transition, the payent coponent, under nora% circustances, "i%%

process the re+uests "ith an a0era&e %atency o! three seconds.> This stateent, or scenario,

a%%o"s an architect to ae +uanti!iab%e ar&uents about a syste. A scenario de!ines the source

o! stiu%us (users), the actua% stiu%us (initiate transaction), the arti!act a!!ected (payent

8/17/2019 IT6602 - SA


coponent), the en0ironent in "hich it eists (nora% operation), the e!!ect o! the action

(transaction processed), and the response easure ("ithin three seconds). ritin& such detai%ed

stateents is on%y possib%e "hen re%e0ant re+uireents ha0e been identi!ied and an idea o!

coponents has been proposed.

ritin& e!!ecti0e scenarios taes soe tie to %earn. But it6s an iportant si%%, as it6s in

the scenarios "here the desired 0a&ue so!t"are beha0iors are turned into tan&ib%e and

easurab%e &oa%s. Measurab%e &oa%s te%% "hat architectura% approaches and tactis to app%y as you

desi&n the syste. It6s easiest to %earn by %ooin& at eap%es. See this resource on ho" you can

do"n%oad a cata%o& o! o0er 4@@ "e%% de!ined +ua%ity attribute scenarios.

Achieving /ualities

Scenarios he%p describe the +ua%ities o! a syste, but they donNt describe ho" they "i%% be

achie0ed. Architectura% tactics describe ho" a &i0en +ua%ity can be achie0ed. *or each +ua%ity

there ay be a %ar&e set o! tactics a0ai%ab%e to an architect. It is the architectNs Cob to se%ect the

ri&ht tactic in %i&ht o! the needs o! the syste and the en0ironent. *or eap%e, a per!orance

tactics ay inc%ude options to de0e%op better processin& a%&oriths, de0e%op a syste !or para%%e% processin&, or re0ise e0ent schedu%in& po%icy. hate0er tactic is chosen, it ust be Custi!ied and

docuented.

'a0onomy of )oft1are /ualities

;0er the past 4@ years so!t"are architects ha0e de0ised a %ist o! coon so!t"are

+ua%ities. It "ou%d be naX0e to c%ai that the %ist be%o" is as a cop%ete taonoy o! a%% so!t"are

+ua%ities – but itNs a so%id %ist o! &enera% so!t"are +ua%ities copi%ed !ro respectab%e sources.

$oain speci!ic systes are %ie%y to ha0e an additiona% set o! +ua%ities in addition to the %ist

be%o".

Syste +ua%ities can be cate&ori'ed into !our parts: runtie +ua%ities, nonruntie

+ua%ities, business +ua%ities, and architecture +ua%ities. Each o! the cate&ories and its associated+ua%ities are brie!%y described be%o". ;ther artic%es on this site pro0ide ore in!oration about

each o! the so!t"are +ua%ity attributes %isted be%o", their app%icab%e properties, and the con!%icts

the +ua%ities.

(untime )ystem /ualities

1untie Syste -ua%ities can be easured as the syste eecutes.

2unctionality

$e!inition: the abi%ity o! the syste to do the "or !or "hich it "as intended.

%erformance

$e!inition: the response tie, uti%i'ation, and throu&hput beha0ior o! the syste. 9ot to

be con!used "ith huan per!orance or syste de%i0ery tie.

)ecurity

$e!inition: a easure o! systeNs abi%ity to resist unauthori'ed attepts at usa&e or

beha0ior odi!ication, "hi%e sti%% pro0idin& ser0ice to %e&itiate users.

Availability (eliability 3uality attributes falls under this category

8/17/2019 IT6602 - SA


$e!inition: the easure o! tie that the syste is up and runnin& correct%yO the %en&th o!

tie bet"een !ai%ures and the %en&th o! tie needed to resue operation a!ter a !ai%ure.

sability

$e!inition: the ease o! use and o! trainin& the end users o! the syste. Sub +ua%ities:

%earnabi%ity, e!!iciency, a!!ect, he%p!u%ness, contro%.

*nteroperability

$e!inition: the abi%ity o! t"o or ore systes to cooperate at runtie

&on-(untime )ystem /ualities

9on1untie Syste -ua%ities cannot be easured as the syste eecutes.

Modifiability

$e!inition: the ease "ith "hich a so!t"are syste can accoodate chan&es to its

so!t"are

%ortability

$e!inition: the abi%ity o! a syste to run under di!!erent coputin& en0ironents. The

en0ironent types can be either hard"are or so!t"are, but is usua%%y a cobination o! the t"o. (eusability

$e!inition: the de&ree to "hich eistin& app%ications can be reused in ne" app%ications.

*ntegrability

$e!inition: the abi%ity to ae the separate%y de0e%oped coponents o! the syste "or

correct%y to&ether.

'estability

$e!inition: the ease "ith "hich so!t"are can be ade to deonstrate its !au%ts

usiness /ualities

9onSo!t"are Syste -ua%ities that in!%uence other +ua%ity attributes.

Cost and )chedule$e!inition: the cost o! the syste "ith respect to tie to aret, epected proCect

%i!etie, and uti%i'ation o! %e&acy and ;TS systes.

Mar+etability

$e!inition: the use o! the syste "ith respect to aret copetition.

Appropriateness for Organi$ation

$e!inition: a0ai%abi%ity o! the huan input, a%%ocation o! epertise, and a%i&nent o! tea

and so!t"are structure. Business process reen&ineerin&

Architecture /ualities

-ua%ity attributes speci!ic to the architecture itse%!.

Conceptual *ntegrity

$e!inition: the inte&rity o! the o0era%% structure that is coposed !ro a nuber o! sa%%

architectura% structures.

Correctness

$e!inition: accountabi%ity !or satis!yin& a%% re+uireents o! the syste.

Domain )pecific /ualities

-ua%ity attributes !ound in speci!ic business doains.

8/17/2019 IT6602 - SA


)ensitivity

$e!inition: the de&ree to "hich a syste coponent can pic up soethin& bein&

easured.

Calibrability

$e!inition: abi%ity o! a syste to reca%ibrate itse%! to soe speci!ic "orin& ran&e.

SI3 /ART SCE$ARIOS

A +ua%ity attribute scenario is a +ua%ityattributespeci!ic re+uireent. It consists o! si

parts.

4. Source o! stiu%us. This is soe entity (a huan, a coputer syste, or any other

actuator) that &enerated the stiu%us.

?. Stiu%us. The stiu%us is a condition that needs to be considered "hen it arri0es at a

syste.

. En0ironent. The stiu%us occurs "ithin certain conditions. The syste ay be in an

o0er%oad condition or ay be runnin& "hen the stiu%us occurs, or soe other condition

ay be true.2. Arti!act. Soe arti!act is stiu%ated. This ay be the "ho%e syste or soe pieces o! it.

G. 1esponse. The response is the acti0ity undertaen a!ter the arri0a% o! the stiu%us.

H. 1esponse easure. hen the response occurs, it shou%d be easurab%e in soe !ashion

so that the re+uireent can be tested.

Fig 25, 1!A+IT% ATTRI"!TE SCE$ARIOS

1!A+IT% ATTRI"!TE SCE$ARIOS

A &enera% scenario is A re+uest arri0es !or a chan&e in !unctiona%ity, and the chan&e ust

be ade at a particu%ar tie "ithin the de0e%opent process "ithin a speci!ied period. A

systespeci!ic 0ersion i&ht be A re+uest arri0es to add support !or a ne" bro"ser to a eb

based syste, and the chan&e ust be ade "ithin t"o "ees.

A9aila7ility :cenario

8/17/2019 IT6602 - SA


A0ai%abi%ity is concerned "ith syste !ai%ure and its associated conse+uences. A syste

!ai%ure occurs "hen the syste no %on&er de%i0ers a ser0ice consistent "ith its speci!ication. Such

a !ai%ure is obser0ab%e by the syste6s userseither huans or other systes.

;nce a syste !ai%s, an iportant re%ated concept becoes the tie it taes to repair it.

Since a syste !ai%ure is obser0ab%e by users, the tie to repair is the tie unti% the !ai%ure is no

%on&er obser0ab%e. This ay be a brie! de%ay in the response tie.

The a0ai%abi%ity o! a syste is the probabi%ity that it "i%% be operationa% "hen it is needed.

This is typica%%y de!ined as

mean time

mean time

α =¿ failure ¿¿failure+meantime ¿repair ¿

*ro this coe ters %ie KK.KU a0ai%abi%ity, or a @.4U probabi%ity that the syste "i%%

not be operationa% "hen needed.

A9aila7ility *eneral Scenario:

*ro these considerations the portions o! a0ai%abi%ity scenario is sho"n in *i&ure ?.?.

4. Source o! stiu%us. e di!!erentiate bet"een interna% and eterna% indications o! !au%ts or

!ai%ure since the desired syste response ay be di!!erent. In our eap%e, the

unepected essa&e arri0es !ro outside the syste.

fig 252 a9aila7ility general :cenario

?. Stiu%us. A !au%t o! one o! the !o%%o"in& c%asses occurs.

oission. A coponent !ai%s to respond to an input. crash. The coponent repeated%y su!!ers oission !au%ts.

tiin&. A coponent responds but the response is ear%y or %ate.

response. A coponent responds "ith an incorrect 0a%ue.

. Arti!act. This speci!ies the resource that is re+uired to be hi&h%y a0ai%ab%e, such as a

processor, counication channe%, process, or stora&e.

8/17/2019 IT6602 - SA


2. En0ironent. The state o! the syste "hen the !au%t or !ai%ure occurs ay a%so a!!ect the

desired syste response. *or eap%e, i! the syste has a%ready seen soe !au%ts and is

operatin& in other than nora% ode, it ay be desirab%e to shut it do"n tota%%y.G. 1esponse. There are a nuber o! possib%e reactions to a syste !ai%ure. These inc%ude

%o&&in& the !ai%ure, noti!yin& se%ected users or other systes, s"itchin& to a de&raded

ode "ith either %ess capacity or %ess !unction, shuttin& do"n eterna% systes, or

becoin& una0ai%ab%e durin& repair. In our eap%e, the syste shou%d noti!y the

operator o! the unepected essa&e and continue to operate nora%%y.

H. 1esponse easure. The response easure can speci!y an a0ai%abi%ity percenta&e, or it can

speci!y a tie to repair, ties durin& "hich the syste ust be a0ai%ab%e, or the duration

!or "hich the syste ust be a0ai%ab%e.

(ODIFIA"I+IT%

Modi!iabi%ity is about the cost o! chan&e. It brin&s up t"o concerns.

4. hat can chan&e (the arti!act)# A chan&e can occur to any aspect o! a syste, ost

coon%y the !unctions that the syste coputes, the p%at!or the syste eists on (the

hard"are, operatin& syste, idd%e"are, etc.), the en0ironent "ithin "hich the syste

operates (the systes "ith "hich it ust interoperate, the protoco%s it uses to

counicate "ith the rest o! the "or%d, etc.), the +ua%ities the syste ehibits (its

per!orance, its re%iabi%ity, and e0en its !uture odi!ications), and its capacity (nuber

o! users supported, nuber o! siu%taneous operations, etc.). The cate&ory o! p%at!or

chan&es is a%so ca%%ed portabi%ity. Those chan&es ay be to add, de%ete, or odi!y any

one o! these aspects.

?. hen is the chan&e ade and "ho aes it (the en0ironent)# Most coon%y in the

past, a chan&e "as ade to source code. That is, a de0e%oper had to ae the chan&e,

"hich "as tested and then dep%oyed in a ne" re%ease. han&es can be ade to the

ip%eentation (by odi!yin& the source code), durin& copi%e (usin& copi%etie

s"itches), durin& bui%d (by choice o! %ibraries), durin& con!i&uration setup (by a ran&e o!

techni+ues, inc%udin& paraeter settin&) or durin& eecution (by paraeter settin&). A

chan&e can a%so be ade by a de0e%oper, an end user, or a syste adinistrator.

. ;nce a chan&e has been speci!ied, the ne" ip%eentation ust be desi&ned,

ip%eented, tested, and dep%oyed. A%% o! these actions tae tie and oney, both o!

"hich can be easured.

(o@ifia7ility *eneral Scenario:

*ro these considerations "e can see the portions o! the odi!iabi%ity &enera% scenarios.*i&ure ?. &i0es an eap%e:

8/17/2019 IT6602 - SA


Fig

25- mo@ifia7ility general :cenario

A de0e%oper "ishes to chan&e the user inter!ace. This chan&e "i%% be ade to the code at

desi&n tie, it "i%% tae %ess than three hours to ae and test the chan&e, and no sidee!!ect

chan&es "i%% occur in the beha0ior.

4. Source o! stiu%us. This portion speci!ies "ho aes the chan&esthe de0e%oper, asyste adinistrator, or an end user. %ear%y, there ust be achinery in p%ace to a%%o"

the syste adinistrator or end user to odi!y a syste, but this is a coon

occurrence.

?. Stiu%us. This portion speci!ies the chan&es to be ade. A chan&e can be the addition o!

a !unction, the odi!ication o! an eistin& !unction, or the de%etion o! a !unction. It can

a%so be ade to the +ua%ities o! the systeain& it ore responsi0e, increasin& its

a0ai%abi%ity, and so !orth. The capacity o! the syste ay a%so chan&e. Increasin& the

nuber o! siu%taneous users is a !re+uent re+uireent.

. Arti!act. This portion speci!ies "hat is to be chan&edthe !unctiona%ity o! a syste, its

p%at!or, its user inter!ace, its en0ironent, or another syste "ith "hich itinteroperates.

2. En0ironent. This portion speci!ies "hen the chan&e can be adedesi&n tie, copi%e

tie, bui%d tie, initiation tie, or runtie. In our eap%e, the odi!ication is to occur

at desi&n tie.G. 1esponse. hoe0er aes the chan&e ust understand ho" to ae it, and then ae it,

test it and dep%oy it. In our eap%e, the odi!ication is ade "ith no side e!!ects.

H. 1esponse easure. A%% o! the possib%e responses tae tie and cost oney, and so tie

and cost are the ost desirab%e easures. Tie is not a%"ays possib%e to predict,

ho"e0er, and so %ess idea% easures are !re+uent%y used, such as the etent o! the chan&e

(nuber o! odu%es a!!ected).

/ERFOR(A$CE

Per!orance is about tiin&. E0ents (interrupts, essa&es, re+uests !ro users, or the

passa&e o! tie) occur, and the syste ust respond to the. There are a 0ariety o!

characteri'ations o! e0ent arri0a% and the response but basica%%y per!orance is concerned "ith

ho" %on& it taes the syste to respond "hen an e0ent occurs.

8/17/2019 IT6602 - SA


A per!orance scenario be&ins "ith a re+uest !or soe ser0ice arri0in& at the syste.

Satis!yin& the re+uest re+uires resources to be consued. hi%e this is happenin& the syste

ay be siu%taneous%y ser0icin& other re+uests.

/erformance *eneral Scenario:

*ro these considerations "e can see the portions o! the per!orance &enera% scenario,

an eap%e o! "hich is sho"n in *i&ure ?.2: 5sers initiate 4,@@@ transactions per inute

stochastica%%y under nora% operations, and these transactions are processed "ith an a0era&e

%atency o! t"o seconds.>

Fig 25 performance general :cenario

4. Source o! stiu%us. The stiu%i arri0e either !ro eterna% (possib%y u%tip%e) or interna%

sources. In our eap%e, the source o! the stiu%us is a co%%ection o! users.

?. Stiu%us. The stiu%i are the e0ent arri0a%s. The arri0a% pattern can be characteri'ed as periodic, stochastic, or sporadic. In our eap%e, the stiu%us is the stochastic initiation

o! 4,@@@ transactions per inute.

. Arti!act. The arti!act is a%"ays the syste6s ser0ices, as it is in our eap%e.

2. En0ironent. The syste can be in 0arious operationa% odes, such as nora%,

eer&ency, or o0er%oad. In our eap%e, the syste is in nora% ode.

G. 1esponse. The syste ust process the arri0in& e0ents. This ay cause a chan&e in the

syste en0ironent (e.&., !ro nora% to o0er%oad ode). In our eap%e, the

transactions are processed.

H. 1esponse easure. The response easures are the tie it taes to process the arri0in&

e0ents (%atency or a dead%ine by "hich the e0ent ust be processed), the 0ariation in thistie (Citter), the nuber o! e0ents that can be processed "ithin a particu%ar tie inter0a%

(throu&hput), or a characteri'ation o! the e0ents that cannot be processed (iss rate, data

%oss). In our eap%e, the transactions shou%d be processed "ith an a0era&e %atency o!

t"o seconds.

8/17/2019 IT6602 - SA


SEC!RIT%

Security is a easure o! the syste6s abi%ity to resist unauthori'ed usa&e "hi%e sti%%

pro0idin& its ser0ices to %e&itiate users. An attept to breach security is ca%%ed an attac and

can tae a nuber o! !ors. It ay be an unauthori'ed attept to access data or ser0ices or to

odi!y data, or it ay be intended to deny ser0ices to %e&itiate users.

Security can be characteri'ed as a syste pro0idin& nonrepudiation, con!identia%ity,

inte&rity, assurance, a0ai%abi%ity, and auditin&.

4. 9onrepudiation is the property that a transaction (access to or odi!ication o! data or

ser0ices) cannot be denied by any o! the parties to it. This eans you cannot deny that

you ordered that ite o0er the Internet.

?. on!identia%ity is the property that data or ser0ices are protected !ro unauthori'ed

access. This eans that a hacer cannot access your incoe ta returns on a &o0ernent

coputer.. Inte&rity is the property that data or ser0ices are bein& de%i0ered as intended. This eans

that your &rade has not been chan&ed since your instructor assi&ned it.

2. Assurance is the property that the parties to a transaction are "ho they purport to be. This

eans that, "hen a custoer sends a credit card nuber to an Internet erchant, the

erchant is "ho the custoer thins they are.G. A0ai%abi%ity is the property that the syste "i%% be a0ai%ab%e !or %e&itiate use. This

eans that a denia%o!ser0ice attac "on6t pre0ent your orderin& this boo.

H. Auditin& is the property that the syste tracs acti0ities "ithin it at %e0e%s su!!icient to

reconstruct the. This eans that, i! you trans!er oney out o! one account to another

account, in S"it'er%and, the syste "i%% aintain a record o! that trans!er.

Sec8rity *eneral Scenario:

The portions o! a security &enera% scenario are &i0en be%o". *i&ure ?.G presents an

eap%e. A correct%y identi!ied indi0idua% tries to odi!y syste data !ro an eterna% siteO

syste aintains an audit trai% and the correct data is restored "ithin one day.

Fig 25G :ec8rity general :cenario

8/17/2019 IT6602 - SA


4. Source o! stiu%us. The source o! the attac ay be either a huan or another syste. It

ay ha0e been pre0ious%y identi!ied (either correct%y or incorrect%y) or ay be current%y

unno"n. The di!!icu%ty "ith security is a%%o"in& access to %e&itiate users and

deterinin& %e&itiacy. I! the on%y &oa% "ere to pre0ent access to a syste, disa%%o"in&

a%% access "ou%d be an e!!ecti0e de!ensi0e easure.

?. Stiu%us. The stiu%us is an attac or an attept to brea security. This as an

unauthori'ed person or syste tryin& to disp%ay in!oration, chan&e and/or de%ete

in!oration, access ser0ices o! the syste, or reduce a0ai%abi%ity o! syste ser0ices. In

*i&ure ?.G, the stiu%us is an attept to odi!y data.

. Arti!act. The tar&et o! the attac can be either the ser0ices o! the syste or the data

"ithin it. In our eap%e, the tar&et is data "ithin the syste.

2. En0ironent. The attac can coe "hen the syste is either on%ine or o!!%ine, either

connected to or disconnected !ro a net"or, either behind a !ire"a%% or open to the

net"or.

G. 1esponse. 5sin& ser0ices "ithout authori'ation or pre0entin& %e&itiate users !ro usin&

ser0ices is a di!!erent &oa% !ro seein& sensiti0e data or odi!yin& it. Thus, the syste

ust authori'e %e&itiate users and &rant the access to data and ser0ices, at the sae

tie reCectin& unauthori'ed users, denyin& the access, and reportin& unauthori'ed

access. 9ot on%y does the syste need to pro0ide access to %e&itiate users, but it needs

to support the &rantin& or "ithdra"in& o! access. ;ne techni+ue to pre0ent attacs is to

cause !ear o! punishent by aintainin& an audit trai% o! odi!ications or attepted

accesses. An audit trai% is a%so use!u% in correctin& !ro a success!u% attac. In *i&ure ?.G,

an audit trai% is aintained.

H. 1esponse easure. Measures o! a syste6s response inc%ude the di!!icu%ty o! ountin&

0arious attacs and the di!!icu%ty o! reco0erin& !ro and sur0i0in& attacs. In our

eap%e, the audit trai% a%%o"s the accounts !ro "hich oney "as ebe''%ed to be

restored to their ori&ina% state. ;! course, the ebe''%er sti%% has the oney, and he ust

be traced do"n and the oney re&ained, but this is outside o! the rea% o! the coputer

syste.

!SA"I+IT%

5sabi%ity is concerned "ith ho" easy it is !or the user to accop%ish a desired tas and

the ind o! user support the syste pro0ides. It can be broen do"n into the !o%%o"in& areas:

4. Learnin& syste !eatures. I! the user is un!ai%iar "ith a particu%ar syste or a particu%ar

aspect o! it, "hat can the syste do to ae the tas o! %earnin& easier#

?. 5sin& a syste e!!icient%y. hat can the syste do to ae the user ore e!!icient in itsoperation#

. Minii'in& the ipact o! errors. hat can the syste do so that a user error has inia%

ipact#

2. Adaptin& the syste to user needs. o" can the user (or the syste itse%!) adapt to ae

the user6s tas easier#

G. Increasin& con!idence and satis!action. hat does the syste do to &i0e the user

con!idence that the correct action is bein& taen#

8/17/2019 IT6602 - SA


In the %ast !i0e years, our understandin& o! the re%ation bet"een usabi%ity and so!t"are

architecture has deepened (see the sidebar 5sabi%ity Mea u%pa). The nora% de0e%opent

process detects usabi%ity prob%es throu&h bui%din& prototypes and user testin&. The %ater a

prob%e is disco0ered and the deeper into the architecture its repair ust be ade, the ore the

repair is threatened by tie and bud&et pressures. In our scenarios "e !ocus on aspects o!

usabi%ity that ha0e a aCor ipact on the architecture. onse+uent%y, these scenarios ust be

correct prior to the architectura% desi&n so that they "i%% not be disco0ered durin& user testin& or

prototypin&.

!:a7ility *eneral Scenario:

*i&ure ?.G &i0es an eap%e o! a usabi%ity scenario: A user, "antin& to inii'e the

ipact o! an error, "ishes to cance% a syste operation at runtieO cance%%ation taes p%ace in

%ess than one second. The portions o! the usabi%ity &enera% scenarios are:

4. Source o! stiu%us. The end user is a%"ays the source o! the stiu%us.

?. Stiu%us. The stiu%us is that the end user "ishes to use a syste e!!icient%y, %earn to use

the syste, inii'e the ipact o! errors, adapt the syste, or !ee% co!ortab%e "ith thesyste. In our eap%e, the user "ishes to cance% an operation, "hich is an eap%e o!

inii'in& the ipact o! errors.

. Arti!act. The arti!act is a%"ays the syste.2. En0ironent. The user actions "ith "hich usabi%ity is concerned a%"ays occur at runtie

or at syste con!i&uration tie. Any action that occurs be!ore then is per!ored by

de0e%opers and, a%thou&h a user ay a%so be the de0e%oper, "e distin&uish bet"een these

ro%es e0en i! per!ored by the sae person. In *i&ure 2., the cance%%ation occurs at

runtie.

G. 1esponse. The syste shou%d either pro0ide the user "ith the !eatures needed or

anticipate the user6s needs. In our eap%e, the cance%%ation occurs as the user "ishes and

the syste is restored to its prior state.H. 1esponse easure. The response is easured by tas tie, nuber o! errors, nuber o!

prob%es so%0ed, user satis!action, &ain o! user no"%ed&e, ratio o! success!u% operationsto tota% operations, or aount o! tie/data %ost "hen an error occurs. In *i&ure ?.G, the

cance%%ation shou%d occur in %ess than one second.

8/17/2019 IT6602 - SA


!$IT – '

DOC!(E$TI$* TE ARCITECT!RE

!SE OF DOC!(E$TI$* TE ARCITECT!RE

4. Architecture docuentation is both prescripti0e and descripti0e. That is, !or soe

audiences it prescribes "hat shou%d be true by p%acin& constraints on decisions to be

ade. *or other audiences it describes "hat is true by recountin& decisions a%ready ade

about a syste6s desi&n.

?. A%% o! this te%%s us that di!!erent staeho%ders !or the docuentation ha0e di!!erent needs

di!!erent inds o! in!oration, di!!erent %e0e%s o! in!oration, and di!!erent treatents

o! in!oration.

. ;ne o! the ost !undaenta% ru%es !or technica% docuentation in &enera%, and so!t"are

architecture docuentation in particu%ar, is to "rite !ro the point o! 0ie" o! the reader.

$ocuentation that "as easy to "rite but is not easy to read "i%% not be used, and easyto read is in the eye o! the beho%deror in this case, the staeho%der.

2. $ocuentation !aci%itates that counication. Soe eap%es o! architectura%

staeho%ders and the in!oration they i&ht epect to !ind in the docuentation are

&i0en in Tab%e K.4.

&' In addition, each staeho%der coes in t"o 0arieties: seasoned and ne". A ne"

staeho%der "i%% "ant in!oration sii%ar in content to "hat his seasoned counterpart

"ants, but in sa%%er and ore introductory doses. Architecture docuentation is a ey

eans !or educatin& peop%e "ho need an o0er0ie": ne" de0e%opers, !undin& sponsors,

0isitors to the proCect, and so !orth.

Sta?ehol@er: an@ the comm8nication nee@: :er9e@ 7y architect8re

8/17/2019 IT6602 - SA


'IEWS

The concept o! a 0ie", "hich you can thin o! as capturin& a structure, pro0ides us "ith the

basic princip%e o! docuentin& so!t"are architecture "ocumenting an architecture is a matter of

documenting the relevant views and then adding documentation that applies to more than one

view. This princip%e is use!u% because it breas the prob%e o! architecture docuentation into

ore tractab%e parts, "hich pro0ide the structure !or the reainder o! this chapter:

• hoosin& the re%e0ant 0ie"s• $ocuentin& 0ie"

• $ocuentin& in!oration that app%ies to ore than one 0ie"

Choo:ing The Rele9ant 'ie;:

A 0ie" sip%y represents a set o! syste e%eents and re%ationships aon& the, so

"hate0er e%eents and re%ationships you dee use!u% to a se&ent o! the staeho%der counity

constitute a 0a%id 0ie". ere is a sip%e step procedure !or choosin& the 0ie"s !or your proCect.

/ro@8ce a can@i@ate 9ie; li:t4

Be&in by bui%din& a staeho%der/0ie" tab%e. our staeho%der %ist is %ie%y to be di!!erent

!ro the one in the tab%e as sho"n be%o", but be as coprehensi0e as you can. *or the co%uns,

enuerate the 0ie"s that app%y to your syste. Soe 0ie"s app%y to e0ery syste, "hi%e others

on%y app%y to systes desi&ned that "ay. ;nce you ha0e ro"s and co%uns de!ined, !i%% in each

ce%% to describe ho" uch in!oration the staeho%der re+uires !ro the 0ie": none, o0er0ie"

on%y, oderate detai%, or hi&h detai%.

Sta?ehol@er: an@ the architect8re @oc8mentation

8/17/2019 IT6602 - SA


25 Com7ine 9ie;:4

The candidate 0ie" %ist !ro step 4 is %ie%y to yie%d an ipractica%%y %ar&e nuber o!

0ie"s. To reduce the %ist to a ana&eab%e si'e, !irst %oo !or 0ie"s in the tab%e that re+uire on%y

o0er0ie" depth or that ser0e 0ery !e" staeho%ders. See i! the staeho%ders cou%d be e+ua%%y "e%%

ser0ed by another 0ie" ha0in& a stron&er consistency. 9et, %oo !or the 0ie"s that are &ood

candidates to be cobined that is, a 0ie" that &i0es in!oration !ro t"o or ore 0ie"s atonce. *or sa%% and ediu proCects, the ip%eentation 0ie" is o!ten easi%y o0er%aid "ith the

odu%e decoposition 0ie". The odu%e decoposition 0ie" a%so pairs "e%% "ith users or

%ayered 0ie"s. *ina%%y, the dep%oyent 0ie" usua%%y cobines "e%% "ith "hate0er coponent

andconnector 0ie" sho"s the coponents that are a%%ocated to hard"are e%eents.

-5 /rioritiBe4

A!ter step ? you shou%d ha0e an appropriate set o! 0ie"s to ser0e your staeho%der

counity. At this point you need to decide "hat to do !irst. o" you decide depends on the

detai%s speci!ic proCect. But, reeber that you donNt ha0e to cop%ete one 0ie" be!ore startin&

another. Peop%e can ae pro&ress "ith o0er0ie"%e0e% in!oration, so a breadth!irst approachis o!ten the best. A%so, soe staeho%dersN interests supersede others.

8/17/2019 IT6602 - SA


DOC!(E$TI$* A 'IEW

/rimary pre:entation e%eents and their re%ationships, contains ain in!oration about

these syste , usua%%y &raphica% or tabu%ar.

Element catalog detai%s o! those e%eents and re%ations in the picture,

ConteJt @iagram ho" the syste re%ates to its en0ironent

'aria7ility g8i@e ho" to eercise any 0ariation points a 0ariabi%ity &uide shou%d inc%ude

docuentation about each point o! 0ariation in the architecture, inc%udin&

4. The options aon& "hich a choice is to be ade

?. The bindin& tie o! the option. Soe choices are ade at desi&n tie, soe at

bui%d tie, and others at runtie.

Architect8re 7ac?gro8n@ –"hy the desi&n re!%ected in the 0ie" cae to be# an

architecture bac&round inc%udes

4. rationa%e, ep%ainin& "hy the decisions re!%ected in the 0ie" "ere ade and "hy

a%ternati0es "ere reCected

?. ana%ysis resu%ts, "hich Custi!y the desi&n or ep%ain "hat "ou%d ha0e to chan&e in

the !ace o! a odi!ication

. assuptions re!%ected in the desi&n

*lo::ary of term: used in the 0ie"s, "ith a brie! description o! each.

Other information inc%udes ana&eent in!oration such as authorship, con!i&uration

contro% data, and chan&e histories. ;r the architect i&ht record re!erences to speci!ic

sections o! a re+uireents docuent to estab%ish traceabi%ity.

8/17/2019 IT6602 - SA


DOC!(E$TI$* TE 'IEWS !SI$* !(+

Architecture in soe sense epresses "hat is essentia% about a so!t"are syste, and that

essence is independent o! %an&ua&es and notations to capture it. 9e0erthe%ess, today the 5ni!ied

Mode%in& Lan&ua&e (5ML) has eer&ed as the de !acto standard notation !or docuentin& a

so!t"are architecture.

o"e0er, it ust be said that 5ML aes its ain contribution in a 0ie"6s priary

presentation, and its secondary contribution in the beha0ior o! an e%eent or &roup o! e%eents.

It is up to the architect to au&ent the 5ML pictures "ith the necessary supportin&

docuentation (the e%eent cata%o&, the rationa%e, and so !orth) that a responsib%e Cob re+uires.

5ML pro0ides no direct support !or coponents, connectors, %ayers, inter!ace seantics,

or any other aspects o! a syste that are supree%y architectura%.

(OD!+E 'IEWS

1eca%% that a odu%e is a code or ip%eentation unit and a odu%e 0ie" is an

enueration o! odu%es to&ether "ith their inter!aces and their re%ations.

Interface:

Interface: in !(+

*i&ure sho"s ho" odu%e inter!aces can be represented in 5ML. 5ML uses a %o%%ipop

to denote an inter!ace, "hich can be appended to c%asses and subsystes, aon& other thin&s.

5ML a%so a%%o"s a c%ass sybo% (bo) to be stereotyped as an inter!aceO the openheaded

dashed arro" sho"s that an e%eent rea%i'es an inter!ace. The botto o! the c%ass sybo% can be

annotated "ith the inter!ace6s si&nature in!oration: ethod naes, ar&uents, ar&uent types,

and so !orth. The %o%%ipop notation is nora%%y used to sho" dependencies !ro e%eents to the

inter!ace, "hi%e the bo notation a%%o"s a ore detai%ed description o! the inter!ace6s synta, such

as the operations it pro0ides.(o@8le:

5ML pro0ides a 0ariety o! constructs to represent di!!erent inds o! odu%es. *i&ure K

sho"s soe eap%es. 5ML has a c%ass construct, "hich is the obCectoriented specia%i'ation o!

a odu%e. Paca&es can be used in cases "here &roupin& o! !unctiona%ity is iportant, such as to

represent %ayers and c%asses. The subsyste construct can be used i! a speci!ication o! inter!ace

and beha0ior is re+uired.

8/17/2019 IT6602 - SA


EJample: of mo@8le notation in !(+

Aggregation

In 5ML, the subsyste construct can be used to represent odu%es that contain other odu%esO

the c%ass bo is nora%%y used !or the %ea0es o! the decoposition. Subsystes are used both as

paca&es and asc%assi!iers. As paca&es, they can be decoposed and hence are suitab%e !or odu%e a&&re&ation. Asc%assi!iers, they encapsu%ate their contents and can pro0ide an ep%icit

inter!ace. A&&re&ation is depicted in one o! three "ays in 5ML

• Modu%es ay be nested

Decompo:ition in !(+ ;ith ne:ting5 The aggregate mo@8le i: :ho;n a: a pac?age )left.K

@ecompo:ition in !(+ ;ith arc: )right.5

• A succession o! t"o dia&ras (possib%y %ined) can be sho"n, "here the second is

a depiction o! the contents o! a odu%e sho"n in the !irst.

An arc denotin& coposition is dra"n bet"een the parent and the chi%dren.

*eneraliBationEpressin& &enera%i'ation is at the heart o! 5ML in "hich odu%es are sho"n as c%asses

(a%thou&h they ay a%so be sho"n as subsystes). *i&ure K. sho"s the basic notation a0ai%ab%e

in 5ML.

8/17/2019 IT6602 - SA


Doc8menting generaliBation in !(+ ;ith t;o line :tyle:

The t"o dia&ras in *i&ure are seantica%%y identica%. 5ML a%%o"s an e%%ipsis (Y) in

p%ace o! a sub odu%e, indicatin& that a odu%e can ha0e ore chi%dren than sho"n and that

additiona% ones are %ie%y. Modu%e Shape is the parent o! odu%es Po%y&on, irc%e, and Sp%ine,each o! "hich is a subc%ass, chi%d, or descendant o! Shape. Shape is ore &enera%, "hi%e its

chi%dren are specia%i'ed 0ersions.

CO(/O$E$T>A$D>CO$$ECTOR 'IEWS

There is no sin&%e pre!erred strate&y to docuent coponentandconnector (D)

0ie"s in 5ML, but a nuber o! a%ternati0es. Each a%ternati0e has its ad0anta&es and

disad0anta&es. ;ne natura% candidate !or representin& coponentandconnector types be&ins

"ith the 5ML c%ass concept. *i&ure i%%ustrates the &enera% idea usin& a sip%e pipeand!i%ter

syste. ere, the !i%ter architectura% type is represented as the 5ML c%ass *i%ter . Instances o!

!i%ters, such as Sp%itter , are represented as correspondin& obCects in an obCect instance dia&ra.

To pro0ide a naespace boundary, enc%ose the descriptions in paca&es.

Type: a: cla::e: an@ in:tance: a: o7Lect: eJemplifie@ ;ith a :imple pipe an@ filter

8/17/2019 IT6602 - SA


Component:

The type&in:tance relation:hip in architect8ral @e:cription: i: a clo:e match to the

cla::&o7Lect relation:hip in a !(+ mo@el5 !(+ cla::e: li?e component type: in

architect8ral @e:cription: are fir:tcla:: entitie: an@ are rich :tr8ct8re: for capt8ring

:oft;are a7:traction:5 The f8ll :et of !(+ @e:cripti9e mechani:m: i: a9aila7le to @e:cri7e

the :tr8ct8re propertie: an@ 7eha9ior of a cla:: ma?ing thi: a goo@ choice for @epicting

@etail an@ 8:ing !(+>7a:e@ analy:i: tool:5 /ropertie: of architect8ral component: can 7e

repre:ente@ a: cla:: attri78te: or ;ith a::ociation:K 7eha9ior can 7e @e:cri7e@ 8:ing !(+

7eha9ioral mo@el:K an@ generaliBation can 7e 8:e@ to relate a :et of component type:5 The

:emantic: of an in:tance or type can al:o 7e ela7orate@ 7y attaching one of the :tan@ar@

:tereotype:K for eJample the Mproce::N :tereotype can 7e attache@ to a component to

in@icate that it r8n: a: a :eparate proce::5

Interface:

Interface: to component: :ometime: calle@ port: can 7e :ho;n in fi9e ;ay: a:

:ho;n in Fig8re 5,,@e:cri7e@ in increa:ing or@er of eJpre::i9ene::5 o;e9er a: eJpre::i9ene:: ri:e: :o @oe:

compleJity

:o yo8 :ho8l@ pic? the fir:t :trategy that ;ill :er9e yo8r p8rpo:e:5

Option ,4 $o eJplicit repre:entation5 +ea9ing o8t interface: lea@: to the :imple:t @iagram:

78t

:8ffer: from the o79io8: pro7lem that there i: no ;ay to characteriBe the name: or the

propertie: of

the interface: in the primary pre:entation5 Still thi: choice might 7e rea:ona7le if the

component:

ha9e only one interface if the interface: can 7e inferre@ from the :y:tem topology or if the@iagram

i: refine@ el:e;here5

Thi: /DF file ;a: con9erte@ 7y Atop C( to /DF Con9erter free 9er:ion

http4&&;;;5chmcon9erter5com&chm>to>p@f&

A@@i:on We:ley 4 Soft;are Architect8re in /ractice Secon@ E@ition

220 & 6-

Option 24 Interface: a: annotation:5 Repre:enting interface: a: annotation: pro9i@e: a

home for

information a7o8t them altho8gh annotation: ha9e no :emantic 9al8e in !(+ :o cannot

7e 8:e@ a:

a 7a:i: for analy:i:5 Again if the @etaile@ propertie: of an interface are not of concern thi:

approach

might 7e rea:ona7le5

Option -4 Interface: a: cla::&o7Lect attri78te:5 Treating interface: a: attri78te: of a

cla::&o7Lect

8/17/2019 IT6602 - SA


ma?e: them part of the formal :tr8ct8ral mo@el 78t they can ha9e only a :imple

repre:entation in a

cla:: @iagramPe::entially a name an@ a type5 Thi: re:triction limit: the eJpre::i9ene:: of

thi:

option5

Option 4 Interface: a: !(+ interface:5 The !(+ lollipop notation pro9i@e: a compact

@e:cription

of an interface in a cla:: @iagram @epicting a component type5 In an in:tance @iagram a

!(+

a::ociation role corre:pon@ing to an interface in:tance an@ 8alifie@ 7y the interface type

name

pro9i@e: a compact ;ay to :ho; that a component in:tance i: interacting thro8gh a

partic8lar

interface in:tance5 Thi: approach pro9i@e: 9i:8ally @i:tinct @epiction: of component: an@

interface:in ;hich interface: can clearly 7e :een a: :87:er9ient5

o;e9er thi: :trategy pro9i@e: no mean: to @epict the :er9ice: re8ire@ from a

componentQ:

en9ironment often a ?ey part of an interface5 F8rthermore it i: meaningf8l for a

component type to

ha9e :e9eral in:tance: of the :ame interface type 78t it i: not meaningf8l to :ay that a cla::

realiBe:

:e9eral 9er:ion: of one !(+ interface5 For eJample there i: no ea:y ;ay to @efine a

Splitter

filter type that ha: t;o o8tp8t port: of the :ame type 8:ing thi: techni8e5 Finally 8nli?ecla::e:

!(+ interface: @o not ha9e attri78te: or :87:tr8ct8re5

Option G4 Interface: a: cla::e:5 De:cri7ing interface: a: cla::e: containe@ 7y a component

type

o9ercome: the lac? of eJpre::i9ene:: of the pre9io8: alternati9e:4 We can no; repre:ent

interface

:87:tr8ct8re an@ in@icate that a component type ha: :e9eral interface: of the :ame type5 A

component in:tance i: mo@ele@ a: an o7Lect containing a :et of interface o7Lect:5 o;e9er

7y

repre:enting interface: a: cla::e: ;e not only cl8tter the @iagram 78t al:o lo:e clear 9i:8al

@i:crimination 7et;een interface: an@ component:5 We co8l@ 8:e a notational 9ariation in

;hich the

interface: are containe@ cla::e: a: :ho;n in the lo;er part of option G in Fig8re 5,,5

In@icating

point: of interaction i: co8nterint8iti9e ho;e9er a: containment 8:8ally in@icate: that a

cla:: o;n:

8/17/2019 IT6602 - SA


other cla::e: ;ho:e in:tance: may or may not 7e acce::i7le thro8gh in:tance: of the parent

cla::5

Fig8re 5,,5 Fi9e ;ay: to repre:ent interface: to component: )port:.

Connector:

There are three rea:ona7le option: for repre:enting connector:5 Again the choice i:

7et;een

eJpre::i9ene:: an@ :emantic match on the one han@ an@ compleJity on the other5

Option ,4 Connector type: a: a::ociation: an@ connector in:tance: a: lin?:5 In an

architect8ral

7oJ>an@>line @iagram of a :y:tem the line: 7et;een component: are connector:5 One

tempting ;ay




22, & 6-to repre:ent connector: in !(+ i: a: a::ociation: 7et;een cla::e: or lin?: 7et;een o7Lect:5

Thi:

approach i: 9i:8ally :imple pro9i@e: a clear @i:tinction 7et;een component: an@

connector: an@

8:e: the mo:t familiar relation:hip in !(+ cla:: @iagram:4 a::ociation5 (oreo9er

a::ociation: can

7e la7ele@ an@ a @irection a::ociate@ ;ith the connector can 7e in@icate@ ;ith an arro;5

!nfort8nately connector: an@ a::ociation: ha9e @ifferent meaning:5 A :y:tem in an

architect8ral

@e:cription i: 78ilt 8p 7y choo:ing component: ;ith 7eha9ior eJpo:e@ thro8gh theirinterface: an@

connecting them ;ith connector: that coor@inate their 7eha9ior:5 A :y:temQ: 7eha9ior i:

@efine@ a:

the collecti9e 7eha9ior of a :et of component: ;ho:e interaction i: @efine@ an@ limite@ 7y

the

connection: 7et;een them5

In contra:t altho8gh an a::ociation or lin? in !(+ repre:ent: a potential for interaction

7et;een

the element: it relate: the a::ociation mechani:m i: primarily a ;ay of @e:cri7ing a

concept8al

relation:hip 7et;een t;o element:5 In a@@ition an a::ociation i: a relation:hip 7et;een

!(+

element: :o it cannot :tan@ on it: o;n in a !(+ mo@el5 Con:e8ently a connector type

cannot 7e

repre:ente@ in i:olation5 In:tea@ yo8 m8:t re:ort to naming con9ention: or to :tereotype:

;ho:e

8/17/2019 IT6602 - SA


meaning: are capt8re@ 7y @e:cription in !(+Q: o7Lect con:traint lang8age5 F8rther the

approach

@oe: not allo; yo8 to :pecify a connectorQ: interface:5

Option 24 Connector type: a: a::ociation cla::e:5 One :ol8tion to the lac? of eJpre::i9ene::

i: to

8alify the a::ociation ;ith a cla:: that repre:ent: the connector type5 In thi: ;ay the

connector

type or connector attri78te: can 7e capt8re@ a: attri78te: of a cla:: or o7Lect5

!nfort8nately thi:

techni8e :till @oe: not pro9i@e any ;ay of eJplicitly repre:enting connector interface:5

Option -4 Connector type: a: cla::e: an@ connector in:tance: a: o7Lect:5 One ;ay to gi9e

connector: fir:t>cla:: :tat8: in !(+ i: to repre:ent connector type: a: cla::e: an@

connector

in:tance: a: o7Lect:5 !:ing cla::e: an@ o7Lect: ;e ha9e the :ame fo8r option: for

repre:entingrole: a: ;e ha@ for interface:4 not at all a: annotation: a: interface: realiBe@ 7y a cla:: or

a: chil@

cla::e: containe@ 7y a connector cla::5 *i9en a :cheme for repre:enting interface: an

attachment

7et;een a componentQ: interface an@ a connectorQ: interface may 7e repre:ente@ a: an

a::ociation

or a @epen@ency5

Sy:tem:

In a@@ition to repre:enting in@i9i@8al component: an@ connector: an@ their type: ;e al:o

nee@ toencap:8late graph: of component: an@ connector:4 :y:tem:5 Three option: are a9aila7le5

Option ,4 Sy:tem: a: !(+ :87:y:tem:5 The primary !(+ mechani:m for gro8ping relate@

element: i: the pac?age5 In fact !(+ @efine: a :tan@ar@ pac?age :tereotype calle@

M:87:y:temN to gro8p !(+ mo@el: that repre:ent a logical part of a :y:tem5 The choice of

:87:y:tem: i: appropriate for any mapping of component: an@ connector: an@ it ;or?:

partic8larly

;ell for gro8ping cla::e:5 One of the pro7lem: ;ith 8:ing :87:y:tem: a: @efine@ in !(+

,5 i:

that altho8gh they are 7oth a cla::ifier an@ a pac?age the meaning i: not entirely clear5

Some ha9e

arg8e@ that ;e :ho8l@ 7e a7le to treat a :87:y:tem a: an atomic cla::>li?e entity at certain

:tage: in

the @e9elopment proce:: an@ later 7e a7le to refine it in term: of a more @etaile@

:87:tr8ct8re5

a9ing the a7ility to @o thi: ;o8l@ ma?e the :87:y:tem con:tr8ct more appropriate for

mo@eling

8/17/2019 IT6602 - SA


architect8ral component:5

Option 24 Sy:tem: a: containe@ o7Lect:5 O7Lect containment can 7e 8:e@ to repre:ent

:y:tem:5

Component: are repre:ente@ a: in:tance: of containe@ cla::e: an@ connector: are mo@ele@

8:ing

one of the option: o8tline@ earlier5 O7Lect: pro9i@e a :trong encap:8lation 7o8n@ary an@

carry ;ith

them the notion that each in:tance of the cla:: ha: the a::ociate@ :87:tr8ct8re5 o;e9er

thi:

approach ha: pro7lem: the mo:t :erio8: 7eing that a::ociation: 8:e@ to mo@el connector:

7et;een containe@ cla::e: are not :cope@ 7y the cla::5 That i: it i: not po::i7le to :ay that a

pair

of cla::e: interact: 9ia a partic8lar connector mo@ele@ a: an a::ociation only in the conteJt

of a

partic8lar :y:tem5 So for eJample in@icating that t;o containe@ cla::e: interact 9ia ana::ociation

i: 9ali@ for in:tance: of cla::e: 8:e@ any;here el:e in the mo@el5

Option -4 Sy:tem: a: colla7oration:5 A :et of comm8nicating o7Lect: connecte@ 7y lin?: i:




222 & 6-

@e:cri7e@ in !(+ 8:ing a colla7oration5 If ;e repre:ent component: a: o7Lect: ;e can 8:e

colla7oration: to repre:ent :y:tem:5 A colla7oration @efine: a :et of participant: an@

relation:hip:that are meaningf8l for a gi9en p8rpo:e ;hich in thi: ca:e i: to @e:cri7e the r8ntime

:tr8ct8re of the

:y:tem5 The participant: @efine cla::ifier role: that o7Lect: play or conform to ;hen

interacting5

Similarly the relation:hip: @efine a::ociation role: that lin?: m8:t conform to5

Colla7oration @iagram: can 7e 8:e@ to pre:ent colla7oration: at either the :pecification or

the

in:tance le9el5 A :pecification>le9el colla7oration @iagram :ho;: the role: @efine@ ;ithin

the

colla7oration arrange@ in a pattern to @e:cri7e the :y:tem :87:tr8ct8re5 An in:tance>le9el

colla7oration @iagram :ho;: the o7Lect: an@ lin?: conforming to the role: at the

:pecification le9el

an@ interacting to achie9e the p8rpo:e5 Therefore a colla7oration pre:ente@ at the in:tance

le9el i:

7e:t 8:e@ to repre:ent the r8ntime :tr8ct8re of the :y:tem5

8/17/2019 IT6602 - SA


Fig8re 5,2 ill8:trate: thi: approach5 The Filter architect8ral type i: repre:ente@ a:

pre9io8:ly5

In:tance: of filter: an@ pipe: are repre:ente@ a: corre:pon@ing cla::ifier role:Pfor

eJample

&Splitter in@icate: the Splitter rolePan@ a::ociation role:5 The o7Lect: an@ lin?:

conforming

to tho:e role: are :ho;n in the colla7oration @iagram at the in:tance le9el in@icate@ 7y

8n@er:core@

name:5

Fig8re 5,25 Sy:tem: a: colla7oration:

Altho8gh thi: i: a nat8ral ;ay to @e:cri7e r8ntime :tr8ct8re: it lea9e: no ;ay to eJplicitly

repre:ent

:y:tem>le9el propertie:5 There i: al:o a :emantic mi:matchK a colla7oration @e:cri7e: a

repre:entati9e interaction 7et;een o7Lect: an@ pro9i@e: a partial @e:cription ;herea: an

architect8ral config8ration i: meant to capt8re a complete @e:cription5A++OCATIO$ 'IEWS

In !(+ a @eployment @iagram i: a graph of no@e: connecte@ 7y comm8nication

a::ociation:5 Fig8re

5,- pro9i@e: an eJample5 $o@e: may contain component in:tance: ;hich in@icate: that

the component

li9e: or r8n: on the no@e5 Component: may contain o7Lect: ;hich in@icate: that the o7Lect

i: part of the

component5 Component: are connecte@ to other component: 7y @a:he@>arro;

@epen@encie: )po::i7ly

thro8gh interface:.5 Thi: in@icate: that one component 8:e: the :er9ice: of anotherK a:tereotype may 7e

8:e@ to in@icate the preci:e @epen@ency if nee@e@5 The @eployment type @iagram may al:o

7e 8:e@ to

:ho; ;hich component: may r8n on ;hich no@e: 7y 8:ing @a:he@ arro;: ;ith the

:tereotype

M:8pport:N5




22- & 6-

Fig8re 5,-5 A @eployment 9ie; in !(+

A no@e i: a r8ntime phy:ical o7Lect that repre:ent: a proce::ing re:o8rce generally ha9ing

at lea:t a

memory an@ often proce::ing capa7ility a: ;ell5 $o@e: incl8@e comp8ting @e9ice: 78t al:o

h8man or

8/17/2019 IT6602 - SA


mechanical proce::ing re:o8rce:5 $o@e: may repre:ent type: of in:tance:5 R8ntime

comp8tational

in:tance: 7oth o7Lect: an@ component: may re:i@e on no@e in:tance:5

$o@e: may 7e connecte@ 7y a::ociation: to other no@e:5 An a::ociation in@icate: a

comm8nication path

7et;een them5 The a::ociation may ha9e a :tereotype to in@icate the nat8re of the

comm8nication path

)for eJample the ?in@ of channel or net;or?.5

The ne:ting of :ym7ol: ;ithin the no@e :ym7ol :ignifie: a compo:ition a::ociation 7et;een

a no@e cla::

an@ con:tit8ent cla::e: or a compo:ition lin? 7et;een a no@e o7Lect an@ con:tit8ent

o7Lect:5

Documents

IT6602 - SA