5 Architecture New

7/25/2019 5 Architecture New

1/55

Software Architecture 1

Software Architecture


2/55


Background Any complex system is composed of

sub-systems that interact

While designing systems, an approachis to identify sub-systems and howthey interact with each other

SW Arch tries to do this for software A recent area, but a lot of interest in it


3/55

Software Architecture !

Background" Architecture is the system design at the

highest le#el

$hoices about technologies, products touse, ser#ers, etc are made at arch le#el %ot possible to design system details and

then accommodate these choices

Arch must be created accommodating them

&s the earliest place when properties likerel'perf can be e#aluated


4/55

Software Architecture (

Architecture Arch is a design of the sw that gi#es a #ery

high le#el #iew of parts and they relate toform the whole )artitions the sys in parts such that each part

can be comprehended independently And describes relationship between parts

A complex system can be partitioned in

many di* ways, each pro#iding a useful#iew Same holds true of software also +here is no uniue structure many possible


5/55

Software Architecture .

Architecture /efn0 Software arch is the structure or

structures which comprise elements, theirexternally #isible properties, and

relationships among them or elements only interested in external

properties needed for relationship specication /etails on how the properties are supported is

not important for arch +he defn does not say anything about whether

an arch is good or not 3 analysis needed for it An arch description describes the di*erent

structures of the system


6/55


5ey 6ses of Arch /escriptions 6nderstanding and communication

By showing a system at a high le#el

and hiding complexity of parts, archdescr facilitates communication

+o get a common understandingbetween the di* stakeholders 7users,

clients, architect, designer,"8 or negotiation and agreement Arch descr can also aid in

understanding of existing systems


7/55


6ses" :euse

A method of reuse is to compose systems fromparts and reuse existing parts

+his model is facilitated by reusing componentsat a high le#el pro#iding complete ser#ices

+o reuse existing components, arch must bechosen such that these components t together

with other components ;ence, decision about using existing

components is made at arch design time


8/55

Software Architecture xample

Suppose we ha#e to design and build a simplesystem for taking an on-line sur#ey of studentson a campus +here is a set of multiple-choice

uestions, and the proposed system willpro#ide the sur#ey form to the student, whocan ll and submit it on-line We also want thatwhen the user submits the form, he'she is also

shown the current result of the sur#ey, that is,what percentage of students so far ha#e lledwhich options for the di*erent uestions

Software Architecture 2!


24/55

Software Architecture 2(

An >xample

/esign a system for taking online sur#ey ofstudents on campus ultiple choice uestions, students submit

online When a student submits, current result of the

sur#ey is shown

&s best built using web a !-tier architecture

is proposed ;as a client, ser#er, and a database

components 7each of a di* type8 $onnector between them are also of di* types


25/55

Software Architecture 2.

>xample"


26/55


>xample"

At arch le#el, details are not needed0

7;ow is the 6:F of the sur#ey setG What are the modules that gointo building these components and what language are they

written inG Huestions like these are not the issues at this le#el8 +he connectors are explicitly stated, which

implies that the infrastructure should pro#idehttp, browser, etc

+he choice of connectors imposes constraintson how the components are nally designedand built


27/55


>xtension 1

+his arch has no security 3 anyone cantake the sur#ey

We want that only registered studentscan take the sur#ey 7at most once8+o identify students and check for one-only

submission, need a authentication ser#er

%eed to use cookies, and ser#er has to bebuilt accordingly 7the connector betweenser#er and auth ser#er is http with cookies8


28/55

Software Architecture 2xtension 1"


29/55

the connection between the client

and the ser#er is that of http0

it is somewhat di*erent from the connection inthe earlier architecture

&n the rst architecture, plain http is suIcient&n this one, as cookies are also needed, theconnector is really http J cookies So,

if the user disables cookies, the reuiredconnector is not a#ailable and thisarchitecture will not work

Software Architecture 2=


30/55

Software Architecture !?

>xtension 2

&t was found that /B is freuently down or impro#ing reliability, felt that if /B

is down, student is gi#en an oldersur#ey result and sur#ey data stored+he sur#ey data gi#en can be outdated

by at most . sur#ey data points

or this, will add a cache comp, whichwill store data as well as results


31/55

Software Architecture !1

>xtension 2"


32/55


>xample"

Ene change increased security, 2ndincreased performance and

reliability &e Arch le#el choices ha#e a big

impact on system properties

+hat is why, choosing a suitablearch can help build a good system


33/55

Software Architecture !!

Architectural Styles for $C$@iew

/i* systems ha#e di* $C$ structure

Some structures are general and are

useful for a class of problems 3architectural styles

An arch style denes a family of archs thatsatisfy the constraint of that style

Styles can pro#ide ideas for creating archfor a sys they can be combined also

We discuss a few common styles


34/55

Software Architecture !(

)ipe and lter

Well suited for systems that mainly do datatransformations0 some input data is recei#ed and the goal of the system is to

produce some output data by suitably transforming the inputdata

A system using this style uses a network oftransforms 7and composing them 8 to achie#e thedesired result

;as one component type 3 lter ;as one connector type 3 pipe

A lter does some transformation and passes data toother lters through pipes


35/55

Software Architecture !.

)ipe and ilter"

lter may ha#e more than one input and more than oneoutput

A lter is independent need not know the id of lterssending'recei#ing data concerned only with the data arri#ing on the pipe

ilters can be asynchronous and are producers or consumersof data

A pipe is unidirectional channel which mo#es streams of datafrom one lter to another

A pipe is a 2-way connector )ipes ha#e to perform bu*ering, and synchroniation

between lters blocking the producer when the bu*er is full and blocking the

consumer lter when the bu*er is empty


36/55


)ipe and lter"

)ipes should work without knowingthe identify of producers'consumers

A pipe must connect the output portof one lter to input port of another

ilters may ha#e indep thread of

control


37/55


>xample

A system needed to count thefreuency of di*erent words in a le

Ene approach0 rst split the le into aseuence of words, sort them, thencount the Kof occurrences

+he arch of this system can naturallyuse the pipe and lter style


38/55

Software Architecture !xample


39/55

Software Architecture !=

Shared-data style

+wo component types 3 data repository and dataaccessor

/ata repository0 pro#ides reliable permanent storage could be le systems or databases

/ata accessors 7are computational >lements8 access data in repositories, perform computations, and

may put the results back also7share the results with

other components8 $ommunication between data accessors is only

through the repository 7components do notdirectly communicate with each other8


40/55

Software Architecture (?

Shared-data style" +wo #ariations possible

Black board style0 if data is posted in a repository, all accessors are

informed

Er, starts the execution of the components that need toact upon this new data

ie shared data source is an acti#e agent

:epository style0 passi#e repository components access the repository as and when they want

>g database oriented systems web systemsprogramming en#ironments,


41/55

>xample $onsider a student registration system in a uni#ersity

+he system clearly has a central repository whichcontains information about courses, students,prereuisites, etc &t has an Administrator component that

sets up the repository, rights to di*erent people, etc +he:egistration component allows students to register andupdate the information for students and courses +heAppro#als component is for granting appro#als for thosecourses that reuire instructorLs consent +he :eportscomponent produces the report regarding the studentsregistered in di*erent courses at the end of theregistration +he component $ourse eedback is used fortaking feedback from students at the end of the course

Software Architecture (1


42/55


>xample

A student registration system of a uni#ersity

:epository contains all the data aboutstudents, courses, schedules,"

Accessors like admin, appro#als, registration,reports which perform operations on the data

$onnectors using this transaction ser#ice allowcomplete transactions 7which may in#ol#emultiple reads and writes and preser#eatomicity8 to be performed by an application


43/55

Software Architecture (!

>xample"


44/55

Software Architecture ((

>xample

$omponents do not directlycommunicate with each other

>asy to extend 3 if a scheduler isneeded, it is added as a newaccessor %o existing component needs to be

changed Enly one connector style in this 3

read'write


45/55

Software Architecture (.

$lient-Ser#er Style

Basic paradigms of distributed computing +wo component types 3 clients and ser#ers $lients can only communicate with the ser#er, but not with

other clients

$ommunication is initiated by a client which sends reuestand ser#er recei#es the reuest, performs the ser#ice, and

returns the results to the client who reuested Ene connector type 3 reuest'reply, which is asymmetric

communication is freuently synchronousMthe client waitsfor the ser#er to return the results before proceeding

Eften the client and the ser#ers reside on di*erentmachines


46/55


$lient-ser#er style"

A general form of this style is the n-tier structure

A !-tier structure is commonly usedby many application and websystems

$lient-tier contains the clients iddle-tier contains the business rules

/atabase tier has the information


47/55

(9

Some other styles )ublish-subscribe style

Some components generate e#ents, and otherssubscribe to them

En an e#ent, those component that subscribe to it are

in#oked )eer-to-peer style 7obDect-oriented style8

&f we take a client-ser#er style, and generalie each

component to be a client as well as a ser#er,components are peersand any component can

reuest a ser#ice from any other component Fike obDect oriented systems components use

ser#ices from each other through methods $ommunication processes style

components in this model are processes or threads )rocesses which execute and communicate with each

other through message passing


48/55

Architectural Styles

Styles can pro#ide ideas forcreating arch for a sys

they can be combined also

Software Architecture (#aluating Architectures

Arch impacts non-functional attributeslike modiability, performance,reliability, portability, etc Attr like usability etc are not impacted

Arch plays a much bigger impact onthese than later decisions

So should e#aluate a proposed arch for

these properties


50/55

>#aluating Architectures Some of the attributes on which architecture

has a signicant impact are0 performance,

:eliability a#ailability,

security 7some aspects of it8,

modiability,

reusability,

)ortability H0 ;ow should this e#aluation be doneG

any di*erent ways

Software Architecture .?


51/55

>#aluating Architectures

or some attributes likeperformance and reliability0 it is possible to build formal models

using techniues like ueuingnetworks and use them for assessingthe #alue of the attribute

Software Architecture .1


52/55

Software Architecture .2

>#aluating Architectures"

)rocedural approach 3 follow a seuence of steps &dentify the attributes of interest to di*erent stakeholders Fist them in a table

or each attribute, e#aluate the architectures underconsideration 7experience-based analysis is done8 toassess the le#el supported by the architecture 7good,8

Based on this table, the architecture is either accepted orreDected

&f reDected, it may be enhanced to impro#e theperformance for the attribute for which the proposedarchitecture was unsatisfactory


53/55

Software Architecture .!

Summary

Arch of a sw system is its structurescomprising of elements, their externalproperties, and relationships

Arch is a high le#el design

+hree main #iew types 3 module,component and connector, and allocation

$omponent and connector 7$C$8 #iew ismost commonly used


54/55

Software Architecture .(

Summary"

+here are some $C$ styles thatare commonly used, eg pipe-and-

lter, shared data, client ser#er, An arch description should

document the di*erent #iews andtheir relationship


55/55

Summary"

Arch can be analyed for #ariousnon-functional attributes like

performance, reliability, security,etc

one approach for analying

architectures, which e#aluatesattributes of interest underdi*erent scenarios

Documents

5 Architecture New