Anlisis y diseo de sistemas 2

USAC

Primer semestre 2006

Ing. Ricardo Morales

Arquitectura

AspectosAspectos de de arquitecturaarquitectura

ClearlyClearly thenthen, , complexitycomplexity isis a a keykey concernconcern thatthat wewe wouldwould likelike software software

architecturearchitecture toto addressaddress. . ThisThis complexitycomplexity presentspresents itselfitself in in twotwo primaryprimary guises:guises:

IntellectualIntellectual intractabilityintractability. . TheThe complexitycomplexity isis inherentinherent in in thethe systemsystem beingbeing builtbuilt, ,

andand may may arisearise fromfrom broadbroad scopescope oror sheersheer sizesize, , noveltynovelty, , dependenciesdependencies, ,

technologiestechnologies employedemployed, etc. Software , etc. Software architecturearchitecture shouldshould makemake thethe systemsystem

more more understandableunderstandable andand intellectuallyintellectually manageablemanageablebyby providingproviding

abstractionsabstractions thatthat hidehide unnecessaryunnecessary detaildetail, , providingproviding unifyingunifying andand simplifyingsimplifying

conceptsconcepts, , decomposingdecomposing thethe systemsystem, etc., etc.

ManagementManagement intractabilityintractability. . TheThe complexitycomplexity lieslies in in thethe organizationorganization andand

processesprocesses employedemployed inin buildingbuilding thethe systemsystem, , andand may may arisearise fromfrom thethe sizesize ofof

thethe projectproject ((numbernumber ofof peoplepeople involvedinvolved in in allall aspectsaspects ofof buildingbuilding thethe systemsystem), ),

dependenciesdependencies in in thethe projectproject, use , use ofof outsourcingoutsourcing, , geographicallygeographically distributeddistributed

teamsteams, etc. Software , etc. Software architecturearchitecture shouldshould makemake thethe developmentdevelopment ofof thethe

systemsystem easiereasier toto managemanagebyby enhancing communication, providing better enhancing communication, providing better

work partitioning with decreased and/orwork partitioning with decreased and/or more more manageablemanageable dependenciesdependencies, ,

etc.etc.

Aspectos de arquitectura

Given that we need to decompose the system to address complexity, whatnew problems emerge that have to be dealt with by the architecture?

How do we break this down into pieces?

A good decomposition satisfies the principle of loose couplingbetween components (or pieces), facilitated by clean interfaces, simplifying the problem by dividing it into reasonably independentpieces that can be tackled separately.

Do we have all the necessary pieces?

The structure must support the functionality or services required ofthe system. Thus, the dynamic behavior of the system must be taken into account when designing the architecture. We must alsohave the necessary infrastructure to support these services.

Do the pieces fit together?

This is a matter of interface and relationships between the pieces. But good fitthat is fit that maintains system integrityalso has to do with whether the system, when composed of the pieces, has theright properties

Arquitectura de softwareQue es arquitectura de software?No existe una definicin estndar, sin embargo se presentan algunas definiciones:

La arquitectura de sw de un programa o sistema computacional es la estructura

del sistema que incluye componentes de sw, las propiedades visibles de dichos

componentes y las relaciones entre ellos Software Architecture in Practice, Len

Bass, Paul Clements, and Rick Kazman, Addison-Wesley, 1997.

Arquitectura es el conjunto de decisiones significativas acerca de la organizacin

de un sistema de software, la seleccin de sus elementos estructurales y las

interfaces de que se compone, junto con con su comportamiento como se

especifica en la colaboracin entre dichos elementos, la composicin de dichos

elementos estructurales y de comportamiento en sistemas progresivamente mas

grandes." The UML Modeling Language User Guide, Booch, Jacobsen,

Rumbaugh, Addison-Wesley, 1999.

La arquitectura de software de un sistema o coleccin de sistemas consiste de las

decisiones importantes de diseo acerca de las estructuras de software y la

interaccin entre dichas estructuras que comprenden los sistemas. Estas

decisiones de diseo permiten un conjunto deseado de cualidades que el sistema

debe soportar para ser exitoso. Las decisiones de diseo proveen una base

conceptual para el desarrollo, soporte y mantenimiento de sistemas

As a sufficiently good compromise to the current technical debate, we offer the

definition of software architecture that David Garlan and Dewayne Perry have

adopted for their guest editorial in the April 1995 IEEE Transactions on Software

Engineering devoted to software architecture:

The structure of the components of a program/system, their interrelationships, and

principles and guidelines governing their design and evolution over time.

The bottom line is that software architecture is about structural properties of a

system. Structural properties can be expressed in terms of components,

interrelationships, and principles and guidelines about their use. The exact

structural properties to consider and the ways to represent them vary depending

upon what is of structural interest to the consumer of the architecture.

Arquitectura de software

Arquitectura de softwareArquitectura de softwareTheThe software software architecturearchitecture ofof a a programprogram oror computingcomputing systemsystem isis thethe structurestructure oror structuresstructuresofof thethe systemsystem, , whichwhich comprisecomprise software software elementselements, , thethe externallyexternally visible visible propertiesproperties ofofthosethose elementselements, , andand thethe relationshipsrelationships amongamong themthem..

""ExternallyExternally visible" visible" propertiesproperties are are thosethose assumptionsassumptions otherother elementselements can can makemake ofof ananelementelement, , suchsuch as as itsits providedprovided servicesservices, , performanceperformance characteristicscharacteristics, , faultfault handlinghandling, , sharedshared resourceresource usageusage, , andand so so onon. . Let'sLet's looklook atat somesome ofof thethe implicationsimplications ofof thisthis definitiondefinitionin more in more detaildetail..

FirstFirst, , architecturearchitecture defines software defines software elementselements. . TheThe architecturearchitecture embodiesembodies informationinformationaboutabout how how thethe elementselements relate relate toto eacheach otherother. . ThisThis meansmeans thatthat itit specificallyspecifically omitsomitscertaincertain informationinformation aboutabout elementselements thatthat doesdoes notnot pertainpertain toto theirtheir interactioninteraction. .

SecondSecond, , thethe definitiondefinition makesmakes clearclear thatthat systemssystems can can andand do do comprisecomprise more more thanthan oneonestructurestructure andand thatthat no no oneone structurestructure can can irrefutablyirrefutably claimclaim toto be be thethe architecturearchitecture. .

ThirdThird, , thethe definitiondefinition impliesimplies thatthat everyevery computingcomputing systemsystem withwith software has a software has a software software architecturearchitecture becausebecause everyevery systemsystem can be can be shownshown toto comprisecomprise elementselementsandand thethe relationsrelations amongamong themthem. . EvenEven though every system has an architecture, it though every system has an architecture, it does not necessarily follow that the architecture is known to andoes not necessarily follow that the architecture is known to anyone. yone.

FourthFourth, , thethe behaviorbehavior ofof eacheach elementelement isis partpart ofof thethe architecturearchitecture insofarinsofar as as thatthatbehaviorbehavior can be can be observedobserved oror discerneddiscerned fromfrom thethe pointpoint ofof viewview ofof anotheranother elementelement. . SuchSuch behaviorbehavior isis whatwhat allowsallows elementselements toto interactinteract withwith eacheach otherother, , whichwhich isis clearlyclearlypartpart ofof thethe architecturearchitecture. .

FinallyFinally, , thethe definitiondefinition isis indifferentindifferent as as toto whetherwhether thethe architecturearchitecture forfor a a systemsystem isis a a goodgood oneone oror a a badbad oneone, , meaningmeaning thatthat itit willwill allowallow oror preventprevent thethe systemsystem fromfrom meeting meeting itsits behavioralbehavioral, , performanceperformance, , andand lifelife--cyclecycle requirementsrequirements. . WeWe do do notnot acceptaccept trialtrial andanderror as error as thethe best best wayway toto choosechoose anan architecturearchitecture forfor a a systemsystemthatthat is, picking an is, picking an architecture at random, building the system from it, and hoping architecture at random, building the system from it, and hoping for the bestfor the bestso this so this raises the importance of architecture evaluation and architecturraises the importance of architecture evaluation and architecture design e design

Influencia del ambienteInfluencia del ambiente

ThereThere are are threethree classesclasses ofof influenceinfluence thatthat come come fromfrom thethe developingdevelopingorganizationorganization: : immediateimmediate businessbusiness, long, long--termterm businessbusiness, , andandorganizationalorganizational structurestructure.. AnAn organizationorganization may may havehave anan immediateimmediate businessbusiness investmentinvestment in in certaincertain

assetsassets, , suchsuch as as existingexisting architecturesarchitectures andand thethe productsproducts basedbased onon themthem. . TheThe foundationfoundation ofof a a developmentdevelopment projectproject may be may be thatthat thethe proposedproposedsystemsystem isis thethe nextnext in a in a sequencesequence ofof similar similar systemssystems, , andand thethe costcostestimatesestimates assumeassume a a highhigh degreedegree ofof assetasset rere--use.use.

AnAn organizationorganization may may wishwish toto makemake a longa long--termterm businessbusiness investmentinvestment in in anan infrastructureinfrastructure toto pursuepursue strategicstrategic goalsgoals andand may may viewview thethe proposedproposedsystemsystem as as oneone meansmeans ofof financingfinancing andand extendingextending thatthat infrastructureinfrastructure..

TheThe organizationalorganizational structurestructure can can shapeshape thethe software software architecturearchitecture. In . In somesome cases cases thethe developmentdevelopment ofof somesome ofof thethe subsystemssubsystems can be can be subcontractedsubcontracted becausebecause thethe subcontractorssubcontractors providedprovided specializedspecializedexpertiseexpertise. . ThisThis waswas made made possiblepossible by a by a divisiondivision ofof functionalityfunctionality in in thethearchitecturearchitecture thatthat allowedallowed isolationisolation ofof thethe specialitiesspecialities..

Influencias en arquitecturaInfluencias en arquitectura

ArquitecturesArquitectures are are influencedinfluenced by by thethe

background background andand experienceexperience ofof thethe architectsarchitects

ArquitecturesArquitectures are are influencedinfluenced by by thethe technicaltechnical

enviromentenviroment

Recomendaciones (proceso)Recomendaciones (proceso)

TheThe architecturearchitecture shouldshould be be thethe productproduct ofof a single a single architectarchitect oror a a smallsmall groupgroup ofof architectsarchitects withwith anan identifiedidentifiedleaderleader..

TheThe architectarchitect ((oror architecturearchitecture team) team) shouldshould havehave thethefunctionalfunctional requirementsrequirements forfor thethe systemsystem andand ananarticulatedarticulated, , prioritizedprioritized listlist ofof qualityquality attributesattributes ((suchsuch as as securitysecurity oror modifiabilitymodifiability) ) thatthat thethe architecturearchitecture isis expectedexpectedtoto satisfysatisfy..

TheThe architecturearchitecture shouldshould be be wellwell documenteddocumented, , withwith atatleastleast oneone staticstatic viewview andand oneone dynamicdynamic viewview, , usingusing ananagreedagreed--onon notationnotation thatthat allall stakeholdersstakeholders can can understandunderstandwithwith a a minimumminimum ofof efforteffort..

TheThe architecturearchitecture shouldshould be be circulatedcirculated toto thethe system'ssystem'sstakeholdersstakeholders, , whowho shouldshould be be activelyactively involvedinvolved in in itsitsreviewreview..

Recomendaciones (proceso)Recomendaciones (proceso)

TheThe architecturearchitecture shouldshould be be analyzedanalyzed forfor applicableapplicable quantitativequantitativemeasuresmeasures ((suchsuch as as maximummaximum throughputthroughput) ) andand formallyformally evaluatedevaluated forforqualityquality attributesattributes beforebefore itit isis too late too late toto makemake changeschanges toto itit..

TheThe architecturearchitecture shouldshould lendlend itselfitself toto incremental incremental implementationimplementation viaviathethe creationcreation ofof a "a "skeletalskeletal" " systemsystem in in whichwhich thethe communicationcommunication pathspathsare are exercisedexercised butbut whichwhich atat firstfirst has has minimalminimal functionalityfunctionality. . ThisThisskeletalskeletal systemsystem can can thenthen be be usedused toto ""growgrow" " thethe systemsystemincrementallyincrementally, , easingeasing thethe integrationintegration andand testingtesting effortsefforts..

TheThe architecturearchitecture shouldshould resultresult in a in a specificspecific ((andand smallsmall) ) setset ofofresourceresource contentioncontention areasareas, , thethe resolutionresolution ofof whichwhich isis clearlyclearlyspecifiedspecified, , circulatedcirculated, , andand maintainedmaintained. . ForFor exampleexample, , ifif networknetworkutilizationutilization isis anan areaarea ofof concernconcern, , thethe architectarchitect shouldshould produce (produce (andandenforceenforce) ) forfor eacheach developmentdevelopment team team guidelinesguidelines thatthat willwill resultresult in a in a minimumminimum ofof networknetwork traffictraffic. . IfIf performanceperformance isis a a concernconcern, , thethearchitectsarchitects shouldshould produce (produce (andand enforceenforce) time ) time budgetsbudgets forfor thethe majormajorthreadsthreads

Recomendaciones (Estructura)Recomendaciones (Estructura)

TheThe architecturearchitecture shouldshould featurefeature wellwell--defineddefined modules modules whosewhose functionalfunctionalresponsibilitiesresponsibilities are are allocatedallocated onon thethe principlesprinciples ofof informationinformation hidinghiding andandseparationseparation ofof concernsconcerns. . TheThe informationinformation--hidinghiding modules modules shouldshould includeincludethosethose thatthat encapsulateencapsulate idiosyncrasiesidiosyncrasies ofof thethe computingcomputing infrastructureinfrastructure, , thusthus insulatinginsulating thethe bulkbulk ofof thethe software software fromfrom changechange shouldshould thetheinfrastructureinfrastructure changechange..

EachEach module module shouldshould havehave a a wellwell--defineddefined interfaceinterface thatthat encapsulatesencapsulates oror""hideshides" " changeablechangeable aspectsaspects ((suchsuch as as implementationimplementation strategiesstrategies andanddata data structurestructure choiceschoices) ) fromfrom otherother software software thatthat uses uses itsits facilitiesfacilities. . TheseTheseinterfaces interfaces shouldshould allowallow theirtheir respectiverespective developmentdevelopment teamsteams toto workworklargelylargely independentlyindependently ofof eacheach otherother..

QualityQuality attributesattributes shouldshould be be achievedachieved usingusing wellwell--knownknown architecturalarchitecturaltacticstactics specificspecific toto eacheach attributeattribute..

TheThe architecturearchitecture shouldshould nevernever dependdepend onon a particular a particular versionversion ofof a a commercialcommercial productproduct oror tooltool. . IfIf itit dependsdepends uponupon a particular a particular commercialcommercialproductproduct, , itit shouldshould be be structuredstructured suchsuch thatthat changingchanging toto a a differentdifferent productproductisis straightforwardstraightforward andand inexpensiveinexpensive..

Recomendaciones (Estructura)Recomendaciones (Estructura)

Modules Modules thatthat produce data produce data shouldshould be be separateseparate fromfrom modules modules thatthatconsume data. consume data. ThisThis tendstends toto increaseincrease modifiabilitymodifiability becausebecause changeschanges are are oftenoften confinedconfined toto eithereither thethe productionproduction oror thethe consumptionconsumption sideside ofof data. data. IfIf newnew data data isis addedadded, , bothboth sidessides willwill havehave toto changechange, , butbut thethe separationseparationallowsallows forfor a a stagedstaged (incremental) (incremental) upgradeupgrade..

ForFor parallelparallel--processingprocessing systemssystems, , thethe architecturearchitecture shouldshould featurefeature wellwell--defineddefined processesprocesses oror taskstasks thatthat do do notnot necessarilynecessarily mirrormirror thethe module module decompositiondecomposition structurestructure. . ThatThat isis, , processesprocesses may may threadthread throughthrough more more thanthan oneone module; a module may module; a module may includeinclude proceduresprocedures thatthat are are invokedinvoked as as partpart ofof more more thanthan oneone processprocess..

EveryEvery tasktask oror processprocess shouldshould be be writtenwritten so so thatthat itsits assignmentassignment toto a a specificspecific processorprocessor can be can be easilyeasily changedchanged, , perhapsperhaps eveneven atat runtimeruntime..

TheThe architecturearchitecture shouldshould featurefeature a a smallsmall numbernumber ofof simple simple interactioninteractionpatternspatterns. . ThatThat isis, , thethe systemsystem shouldshould do do thethe samesame thingsthings in in thethe samesamewayway throughoutthroughout. . ThisThis willwill aidaid in in understandabilityunderstandability, reduce , reduce developmentdevelopmenttime, time, increaseincrease reliabilityreliability, , andand enhanceenhance modifiabilitymodifiability. . ItIt willwill alsoalso show show conceptual conceptual integrityintegrity in in thethe architecturearchitecture, , whichwhich, , whilewhile notnot measurablemeasurable, , leadsleads toto smoothsmooth developmentdevelopment..

TheThe ArchitectureArchitecture Defines Defines

ConstraintsConstraints onon ImplementationImplementation

AnAn implementationimplementation exhibitsexhibits anan architecturearchitecture ifif itit conformsconforms toto thethestructuralstructural designdesign decisionsdecisions describeddescribed by by thethe architecturearchitecture. . ThisThismeansmeans thatthat thethe implementationimplementation mustmust be be divideddivided intointo thethe prescribedprescribedelementselements, , thethe elementselements mustmust interactinteract withwith eacheach otherother in in thetheprescribedprescribed fashion, fashion, andand eacheach elementelement mustmust fulfillfulfill itsits responsibilityresponsibility totothethe othersothers as as dictateddictated by by thethe architecturearchitecture..

ResourceResource allocationallocation decisionsdecisions alsoalso constrainconstrain implementationsimplementations. . TheseThese decisionsdecisions may be invisible may be invisible toto implementorsimplementors workingworking ononindividual individual elementselements. . TheThe constraintsconstraints permitpermit a a separationseparation ofof concernsconcernsthatthat allowsallows managementmanagement decisionsdecisions toto makemake thethe best use best use ofofpersonnelpersonnel andand computationalcomputational capacitycapacity. . ElementElement buildersbuilders mustmust be be fluentfluent in in thethe specificationspecification ofof theirtheir individual individual elementselements butbut notnot in in architecturalarchitectural tradeoffstradeoffs. . ConverselyConversely, , architectsarchitects needneed notnot be be expertsexperts in in allall aspectsaspects ofof algorithmalgorithm designdesign oror thethe intricaciesintricacies ofof thethe programmingprogramminglanguagelanguage, , butbut theythey are are thethe onesones responsibleresponsible forfor thethe architecturalarchitecturaltradeoffstradeoffs..

TheThe architecturearchitecture inhibitsinhibits oror enablesenables a a

system'ssystem's qualityquality attributesattributes

WhetherWhether a a systemsystem willwill be be ableable toto exhibitexhibit itsits desireddesired ((oror requiredrequired) ) qualityqualityattributesattributes isis substantiallysubstantially determineddetermined by by itsits architecturearchitecture. .

IfIf youryour systemsystem requiresrequires highhigh performanceperformance, , youyou needneed toto managemanage thethetimetime--basedbased behaviorbehavior ofof elementselements andand thethe frequencyfrequency andand volumevolume ofof interinter--elementelement communicationcommunication..

IfIf modifiabilitymodifiability isis importantimportant, , youyou needneed toto assignassign responsibilitiesresponsibilities totoelementselements suchsuch thatthat changeschanges toto thethe systemsystem do do notnot havehave farfar--reachingreachingconsequencesconsequences..

IfIf youryour systemsystem mustmust be be highlyhighly securesecure, , youyou needneed toto managemanage andand protectprotectinterinter--elementelement communicationcommunication andand whichwhich elementselements are are allowedallowed toto accessaccesswhichwhich informationinformation. . YouYou may may alsoalso needneed toto introduce introduce specializedspecialized elementselements((suchsuch as a as a trustedtrusted kernelkernel) ) intointo thethe architecturearchitecture..

IfIf youyou believebelieve scalabilityscalability willwill be be neededneeded in in youryour systemsystem, , youyou havehave totocarefullycarefully localizelocalize thethe use use ofof resourcesresources toto facilitatefacilitate thethe introductionintroduction ofofhigherhigher--capacitycapacity replacementsreplacements..

IfIf youryour projectproject needsneeds toto deliverdeliver incremental incremental subsetssubsets ofof thethe systemsystem, , youyoumustmust carefullycarefully managemanage interinter--componentcomponent usageusage..

IfIf youyou wantwant thethe elementselements ofof youryour systemsystem toto be rebe re--usable in usable in otherothersystemssystems, , youyou needneed toto restrictrestrict interinter--elementelement couplingcoupling so so thatthat whenwhen youyouextractextract anan elementelement itit doesdoes notnot come out come out withwith too too manymany attachmentsattachments totoitsits currentcurrent environmentenvironment toto be be usefuluseful..

TheThe architecturearchitecture inhibitsinhibits oror enablesenables

a a system'ssystem's qualityquality attributesattributes (II)(II)

TheThe strategiesstrategies forfor thesethese andand otherother qualityquality attributesattributes are are

supremelysupremely architecturalarchitectural. . ItIt isis importantimportant toto understandunderstand, ,

howeverhowever, , thatthat architecturearchitecture alonealone cannotcannot guaranteeguarantee

functionalityfunctionality oror qualityquality. . PoorPoor downstreamdownstream designdesign oror

implementationimplementation decisionsdecisions can can alwaysalways undermineundermine anan

adequateadequate architecturalarchitectural designdesign. . DecisionsDecisions atat allall stagesstages ofof

thethe lifelife cyclecyclefromfrom highhigh--levellevel designdesign toto codingcoding andand

implementationimplementationaffectaffect systemsystem qualityquality. . ThereforeTherefore, , qualityquality

isis notnot completelycompletely a a functionfunction ofof architecturalarchitectural designdesign. . ToTo

ensureensure qualityquality, a , a goodgood architecturearchitecture isis necessarynecessary, , butbut notnot

sufficientsufficient..

WhyWhy IsIs Software Software ArchitectureArchitecture

ImportantImportant??

ThereThere are are fundamentallyfundamentally threethree reasonsreasons forfor software software architecture'sarchitecture'simportantanceimportantance.. CommunicationCommunication amongamong stakeholdersstakeholders. Software . Software architecturearchitecture representsrepresents

a a commoncommon abstractionabstraction ofof a a systemsystem thatthat mostmost ifif notnot allall ofof thethe system'ssystem'sstakeholdersstakeholders can use as a can use as a basisbasis forfor mutual mutual understandingunderstanding, , negotiationnegotiation, , consensusconsensus, , andand communicationcommunication..

EarlyEarly designdesign decisionsdecisions. Software . Software architecturearchitecture manifestsmanifests thethe earliestearliestdesigndesign decisionsdecisions aboutabout a a systemsystem, , andand thesethese earlyearly bindingsbindings carrycarry weightweightfarfar out out ofof proportionproportion toto theirtheir individual individual gravitygravity withwith respectrespect toto thethesystem'ssystem's remainingremaining developmentdevelopment, , itsits deploymentdeployment, , andand itsits maintenancemaintenancelifelife. . ItIt isis alsoalso thethe earliestearliest pointpoint atat whichwhich designdesign decisionsdecisions governinggoverning thethesystemsystem toto be be builtbuilt can be can be analyzedanalyzed..

TransferableTransferable abstractionabstraction ofof a a systemsystem. Software . Software architecturearchitecture constitutesconstitutesa a relativelyrelatively smallsmall, , intellectuallyintellectually graspablegraspable modelmodel forfor how a how a systemsystem isisstructuredstructured andand how how itsits elementselements workwork togethertogether, , andand thisthis modelmodel isistransferabletransferable acrossacross systemssystems. In particular, . In particular, itit can be can be appliedapplied toto otherothersystemssystems exhibitingexhibiting similar similar qualityquality attributeattribute andand functionalfunctional requirementsrequirementsandand can can promotepromote largelarge--scalescale rere--use.use.

To be sure, the primary focus is on the architecturethe structural elements of the system together with their

externally visible properties and relationships. However, there are higher-level decisions that guide and

constrain the system decomposition and structuring decisions (meta-architecture), and there may be lowerlevel

decisions that guide and constrain the next level(s) of design and implementation (architecture guidelines and

policies). This is captured in the layered model of software architecture shown in Figure.

We have found that this model provides a highly effective separation of concerns, helping architects to

organize their decision-making process and providing focus for action.

At the same time, the model organizes the architecture description, which consists of models, descriptions,

explanations, etc., that capture the architectural decisions and help different stakeholders visualize the

architecture and see how their concerns are addressed by it. The architectural description (ideally, at any rate)

guides the creation of the system, and it is what we return to when we want to evolve the system.

Modelo de arquitectura

The meta-architecture is a set of high-level decisions that will strongly influence the

integrity and structure of the system, but is not itself the structure of the system. The

meta-architecture, through style, patterns of composition or interaction1, principles,

and philosophy, rules certain structural choices out, and guides selection decisions

and trade-offs among others. By choosing communication or co-ordination

mechanisms that are repeatedly applied across the architecture, a consistent

approach is ensured and this simplifies the architecture. It is also very useful at this

stage, to find a metaphor or organizing concept2 that works for your system. It will help

you think about the qualities that the system should have, it may even help you think

about what components you need (in Conceptual Architecture), and it will certainly

help you make the architecture more vivid and understandable.

Meta Architecture

Architecture is at the center of our layered decision model, and at the center of

the architecting activity. It is where the system structures are created, taking into

account system priorities and constraints,and ensuring that the system will

achieve the system objectives and architectural requirements. This work is

informed and constrained by the decisions made in the Meta-Architecture.

Within the architecture layer, we use different views to enhance the

understandability of the architecture and to focus on particular concerns

separately. We distinguish between Conceptual, Logical and Execution views, as

shown in Figure and described below.

Arquitectura

Conceptual Architecture

The Conceptual Architecture identifies the high-level components of the system, and

the relationships among them. Its purpose is to direct attention at an appropriate

decomposition of the system without delving into details. Moreover, it provides a

useful vehicle for communicating the architecture to non-technical audiences, such as

management, marketing, and users. It consists of the Architecture Diagram (without

interface detail) and an informal component specification for each component.

Logical Architecture

In Logical Architecture, the externally visible properties of the components are made

precise and unambiguous through well-defined interfaces and component

specifications, and key architectural mechanisms are detailed. The Logical

Architecture provides a detailed blueprint from which component developers and

component users can work in relative independence. It incorporates the detailed

Architecture Diagram (with interfaces), Component and Interface Specifications, and

Component Collaboration Diagrams, along with discussion and explanations of

mechanisms, rationale, etc.

Execution Architecture

An Execution Architecture is created for distributed or concurrent systems. The

process view shows the mapping of components onto the processes of the physical

system, with attention being focused on such concerns as throughput and scalability.

The deployment view shows the mapping of (physical) components in the executing

system onto the nodes of the physical system.

Divisin de arquitectura

Architectural Views and Structure and Behavior

Both structural and behavioral views are important to thinking through and representing

architecture:

Structural View. If we accept that architecture is the high-level structure of the system

comprised of components, their interrelationships, and externally visible properties

(adaptation of the Bass, Clements, Kazman definition), the structural view is central. It

consists of the Architecture Diagram (stereotyped UML Class Diagram), and Component and

Interface Specifications.

Behavioral View. In decomposing the system into components and designing their

interfaces, and in designing mechanisms to address key cross-cutting concerns, we have to

answer the question How does this work? Likewise, in understanding and using the

architecture, we have to be able to answer the same question. This is the role of the

behavioral view, with its Component Collaboration or Sequence Diagrams (stereotyped UML

Sequence and Collaboration Diagrams).

Structural and behavioral views are applicable for each of the Conceptual, Logical and

Execution Architecture views (or layers), as shown in Figure 4.

Vistas de arquitectura

To help maintain system integrity or to address cross-cutting concerns, architects

may include decisions focused at guiding or constraining lower-level design or

even implementation in the architecture decision set. Recall our caution: the only

justifiable reason for restricting the intellectual freedom of designers and

implementers is demonstrable contribution to strategic and systemic properties

that otherwise could not be achieved. That said, there is a fair amount that

architects can valuably do to help designers and implementers in applying the

architecture and in paying attention to the right characteristics of the problem so

that their decisions, in turn, are in alignment with all that is explicit in the

architecture and all that is implicit in the architecture concept.

Architectural guidelines and policies

VisiVisin arquitectn arquitectnicanica

Dos rasgos comunes de prDos rasgos comunes de prcticamente todo proyecto de OO cticamente todo proyecto de OO

son:son:

La existencia de una fuerte visiLa existencia de una fuerte visin arquitectn arquitectnicanica

La aplicaciLa aplicacin de un ciclo de vida bien manejado, iterativo e n de un ciclo de vida bien manejado, iterativo e

incrementalincremental

La arquitectura debe ser simpleLa arquitectura debe ser simple

Comportamiento comComportamiento comn alcanzado a travn alcanzado a travs de s de

abstracciones y mecanismos en comabstracciones y mecanismos en comnn

Atributos de buenas arquitecturasAtributos de buenas arquitecturas

Las buenas arquitecturas se construyen en capas de Las buenas arquitecturas se construyen en capas de

abstracciabstraccin bien definidasn bien definidas

Cada capa representa una abstracciCada capa representa una abstraccin coherenten coherente

Cada capa tiene una interfase controlada y bien definidaCada capa tiene una interfase controlada y bien definida

Cada capa se construye sobre facilidades controladas y Cada capa se construye sobre facilidades controladas y

bien definidas a un nivel mbien definidas a un nivel ms bajo de abstraccis bajo de abstraccinn

Existe una separaciExiste una separacin clara entre la interfase y la n clara entre la interfase y la

implementaciimplementacin de cada capan de cada capa

Los cambios a la implementaciLos cambios a la implementacin de una capa no violan n de una capa no violan

suposiciones hechas por sus clientessuposiciones hechas por sus clientes

Desarrollando la arquitectura del sistemaDesarrollando la arquitectura del sistema

El diseEl diseo de la arquitectura tiene que ver con el manejo de riesgoso de la arquitectura tiene que ver con el manejo de riesgos

Las buenas arquitecturas se determinan mejor a travLas buenas arquitecturas se determinan mejor a travs de s de

desarrollo iterativo e incrementaldesarrollo iterativo e incremental

A un equipo de arquitectura pequeA un equipo de arquitectura pequeo y con experiencia dirigido por o y con experiencia dirigido por

un Arquitecto Jefe se le debe asignar la responsabilidad de:un Arquitecto Jefe se le debe asignar la responsabilidad de:

Definir y mantener la integridad arquitectDefinir y mantener la integridad arquitectnica del sistemanica del sistema

Aprobar todos los cambios a las interfases de paquetesAprobar todos los cambios a las interfases de paquetes

Evaluar los riesgos del proyectoEvaluar los riesgos del proyecto

Proponer el orden y contenido de cada iteraciProponer el orden y contenido de cada iteracinn

Dimensiones de la arquitectura de softwareDimensiones de la arquitectura de software

Diferentes perspectivas para diferentes interesadosDiferentes perspectivas para diferentes interesados

Usuario final, cliente, gerente de proyectoUsuario final, cliente, gerente de proyecto

Ingeniero de sistema, desarrollador, arquitecto, probadorIngeniero de sistema, desarrollador, arquitecto, probador

Perspectivas mPerspectivas mltiples requieren vistas mltiples requieren vistas mltiplesltiples

Los diagramas de clases no muestran como el sistema Los diagramas de clases no muestran como el sistema

encaja en el hardwareencaja en el hardware

Los diagramas de Los diagramas de deploymentdeployment o implementacio implementacin, no n, no

muestran que partes del sistema son componentes muestran que partes del sistema son componentes

empaquetados (COTS, empaquetados (COTS, commercial offcommercial off--thethe--shelfshelf))

Una arquitectura requiere mUna arquitectura requiere mltiples vistasltiples vistas

Para describir completamente una arquitectura, se necesitan Para describir completamente una arquitectura, se necesitan

cuatro vistas:cuatro vistas:

La vista lLa vista lgica que proporciona una imagen estgica que proporciona una imagen esttica de las tica de las

clases primarias y sus relacionesclases primarias y sus relaciones

La vista de componentes que muestra como el cLa vista de componentes que muestra como el cdigo se digo se

organiza en paquetes y librerorganiza en paquetes y libreras y el uso de paquetes de as y el uso de paquetes de

software comercial (COTS, software comercial (COTS, commercial offcommercial off--thethe--shelfshelf))

La vista de procesos para mostrar los procesos y tareasLa vista de procesos para mostrar los procesos y tareas

La vista de producciLa vista de produccin para mostrar los procesadores, n para mostrar los procesadores,

dispositivos y enlaces en el ambiente operacionaldispositivos y enlaces en el ambiente operacional

Finalmente una vista de escenarios que explica como las otras Finalmente una vista de escenarios que explica como las otras

cuatro vistas funcionan juntascuatro vistas funcionan juntas

El Modelo El Modelo Vista 4+1Vista 4+1

Vista Lgica

Funcionalidad

Vista de Produccin

Rendimiento, Disponibilidad,

Tolerancia a Fallas, Escalabilidad,

Entrega e Instalacin

Vista de Componentes

Manejo de Software,

Reutilizacin, Portabilidad

Vista de Procesos

Rendimiento,

Disponibilidad

Tolerancia a Fallas

Vista de Casos de Uso

Entendimiento

Usabilidad

Vista lVista lgicagica

La vista lLa vista lgica de la arquitectura tiene que ver con gica de la arquitectura tiene que ver con

los requerimientos funcionales del sistemalos requerimientos funcionales del sistema

Que es lo que el sistema proveerQue es lo que el sistema proveer en ten trminos rminos

de servicios a los usuariosde servicios a los usuarios

Proporciona una imagen estProporciona una imagen esttica de las clases tica de las clases

primarias y sus relacionesprimarias y sus relaciones

La vista lLa vista lgica se captura en diagramas de clase gica se captura en diagramas de clase

que contienen los paquetes, clases y relaciones que que contienen los paquetes, clases y relaciones que

representan las abstracciones clave del sistema en representan las abstracciones clave del sistema en

desarrollodesarrollo

Vista de componentesVista de componentes

La vista de componentes de la arquitectura se ocupa de la La vista de componentes de la arquitectura se ocupa de la

organizaciorganizacin actual del software dentro del ambiente de n actual del software dentro del ambiente de

desarrollodesarrollo

Los diagramas de componentes se crean para mostrar los Los diagramas de componentes se crean para mostrar los

paquetes (en desarrollo) y componentes que forman el paquetes (en desarrollo) y componentes que forman el

sistema que se estsistema que se est desarrollandodesarrollando

Muestra la asignaciMuestra la asignacin de clases a componentesn de clases a componentes

Muestra la asignaciMuestra la asignacin de componentes a paquetesn de componentes a paquetes

Los paquetes se organizan en una jerarquLos paquetes se organizan en una jerarqua de capas en a de capas en

donde cada capa tiene una interfase bien definidadonde cada capa tiene una interfase bien definida

QuQu es un componente?es un componente?

Un componente es una unidad de cUn componente es una unidad de cdigo fuente que sirve como digo fuente que sirve como

bloque para construir la estructura fbloque para construir la estructura fsica de un sistemasica de un sistema

Los estereotipos (con iconos alternos) pueden ser usados para Los estereotipos (con iconos alternos) pueden ser usados para

definir tipos especdefinir tipos especficos de componentesficos de componentes

Ejemplos: Ejemplos: exeexe, , dlldll, programas principales (, programas principales (mainmain), ),

encabezados (encabezados (headersheaders), m), mdulos, formasdulos, formas

Agrupe las clases en un componente que tenga una funciAgrupe las clases en un componente que tenga una funcin n

cooperativa o que necesite estar muy prcooperativa o que necesite estar muy prximo para la eficiencia ximo para la eficiencia

de la implementacide la implementacinn

NotaciNotacin de componentes:n de componentes:

Nombre de componenteNombre de componente

Correspondencia entre paquetes en las Correspondencia entre paquetes en las

vistas lvistas lgica y de componentesgica y de componentes

En general, un paquete en la vista lEn general, un paquete en la vista lgica puede corresponder gica puede corresponder directamente a un paquete en la vista de componentesdirectamente a un paquete en la vista de componentes

La estructura lLa estructura lgica y la estructura fgica y la estructura fsica pueden diferir por las sica pueden diferir por las siguientes razones:siguientes razones:

Los paquetes en la vista lLos paquetes en la vista lgica se combinan, para mantener gica se combinan, para mantener juntos objetos que mantienen estrecha comunicacijuntos objetos que mantienen estrecha comunicacin para la n para la implementaciimplementacinn

Los paquetes en la vista de componentes se aLos paquetes en la vista de componentes se aaden para aden para implementar funcionalidad de bajo nivel que no se representada implementar funcionalidad de bajo nivel que no se representada durante el andurante el anlisislisis

La estructura de distribuciLa estructura de distribucin del trabajo de un equipo de n del trabajo de un equipo de desarrollo influencia la asignacidesarrollo influencia la asignacin de paquetes y componentes n de paquetes y componentes en la vista de componentesen la vista de componentes

Clases y componentesClases y componentes

Los componentes son piezas de software que generan la Los componentes son piezas de software que generan la

base del cbase del cdigo fuentedigo fuente

Las clases son asignadas a componentes. El componente es Las clases son asignadas a componentes. El componente es

un conjunto de clases que guardan cohesiun conjunto de clases que guardan cohesin entre sn entre s..

Recuerde...el objetivo de los componentes es aumentar el Recuerde...el objetivo de los componentes es aumentar el

grado de reutilizacigrado de reutilizacinn

Componente con clases asignadasComponente con clases asignadas

Curso

buscarPrerequisito() : ListaDeCursos

nombre descripcin lugar horaDelDiahorasCrdito

Vista de procesosVista de procesos

La vista de procesos de arquitectura se enfoca en la La vista de procesos de arquitectura se enfoca en la

descomposicidescomposicin de los procesosn de los procesos

Esta vista muestra la asignaciEsta vista muestra la asignacin de componentes a procesosn de componentes a procesos

El diagrama de componentes se actualiza para mostrar la El diagrama de componentes se actualiza para mostrar la

asignaciasignacin de componentes a los procesosn de componentes a los procesos

La vista de procesos se ocupa de la disponibilidad del sistema, La vista de procesos se ocupa de la disponibilidad del sistema,

su confiabilidad, rendimiento, manejo del sistema y su confiabilidad, rendimiento, manejo del sistema y

sincronizacisincronizacinn

Vista de producciVista de produccinn

La vista de producciLa vista de produccin de arquitectura asocia n de arquitectura asocia

componentes a nodos de procesamientocomponentes a nodos de procesamiento

Requerimientos tales como rendimiento, Requerimientos tales como rendimiento,

funcionamiento y tolerancia a fallas se toman en funcionamiento y tolerancia a fallas se toman en

consideraciconsideracinn

Los diagramas de producciLos diagramas de produccin se crean para mostrar n se crean para mostrar

los diferentes nodos (procesadores y dispositivos) los diferentes nodos (procesadores y dispositivos)

en el sistemaen el sistema

Diagrama de producciDiagrama de produccinn

Un diagrama de producciUn diagrama de produccin muestra la asignacin muestra la asignacin de n de

componentes a nodos en la vista de produccicomponentes a nodos en la vista de produccin de un sisteman de un sistema

Procesadores y dispositivos son estereotipos comunes de Procesadores y dispositivos son estereotipos comunes de

NodoNodo

Los nodos se conectan en un diagrama que refleja las vLos nodos se conectan en un diagrama que refleja las vas de as de

comunicacicomunicacin entre ellosn entre ellos

Los elementos esenciales de un diagrama de desarrollo son Los elementos esenciales de un diagrama de desarrollo son

los nodos y sus conexioneslos nodos y sus conexiones

Asociando paquetes de desarrollo a Asociando paquetes de desarrollo a

procesos ejecutablesprocesos ejecutables

Asociar paquetes de desarrollo a procesos ejecutables Asociar paquetes de desarrollo a procesos ejecutables

involucra entendimiento de la topologinvolucra entendimiento de la topologa del sistema y las a del sistema y las

prioridades del sistema incluyendo:prioridades del sistema incluyendo:

Arquitectura, velocidad y capacidad de ProcesadorArquitectura, velocidad y capacidad de Procesador

Mantener las asociaciones de clases juntas para minimizar Mantener las asociaciones de clases juntas para minimizar

comunicacicomunicacin entre procesos (IPC)n entre procesos (IPC)

Estrategia de IPC Estrategia de IPC cliente/suplidor u otra?cliente/suplidor u otra?

TTcnicas de proceso distribuidocnicas de proceso distribuido

Se deben resolver situaciones que involucren mSe deben resolver situaciones que involucren mltiples ltiples

procesadores de hardware o sistemas distribuidos durante el procesadores de hardware o sistemas distribuidos durante el

disediseo del sistemao del sistema

Asociando procesos ejecutables a hardwareAsociando procesos ejecutables a hardware

Los procesos se deben asignar a un dispositivo de hardware Los procesos se deben asignar a un dispositivo de hardware

para su ejecucipara su ejecucinn

Entre las consideraciones estEntre las consideraciones estn:n:

Tiempos de respuesta y rendimiento total del sistemaTiempos de respuesta y rendimiento total del sistema

Ancho de banda y capacidad de comunicaciAncho de banda y capacidad de comunicacinn

LocalizaciLocalizacin fn fsica del hardware requeridosica del hardware requerido

Necesidades de procesamiento distribuidoNecesidades de procesamiento distribuido

Sobrecarga o balance de procesadores en un sistema Sobrecarga o balance de procesadores en un sistema

distribuidodistribuido

Tolerancia a fallasTolerancia a fallas

......

Vista de casos de usoVista de casos de uso

Los casos de uso son los que impulsan el diseLos casos de uso son los que impulsan el diseo de la o de la

arquitecturaarquitectura

Abstracciones de requerimientos grandes y complejosAbstracciones de requerimientos grandes y complejos

IdentificaciIdentificacin de interfases crn de interfases crticasticas

Obliga a los diseObliga a los diseadores a enfocarse en temas especadores a enfocarse en temas especficosficos

Demuestran y validan las vistas lDemuestran y validan las vistas lgica, de procesos, de gica, de procesos, de

desarrollo y de produccidesarrollo y de produccin de la arquitecturan de la arquitectura

La La Vista 4+1Vista 4+1 de un modelo UMLde un modelo UML

Vista LVista Lgicagica

Diagramas de clase,Diagramas de clase,

Diagramas de secuenciaDiagramas de secuencia

Vista de ProducciVista de Produccin n

Diagramas de ProducciDiagramas de Produccinn

Vista de ComponentesVista de Componentes

Diagramas de componentesDiagramas de componentes

Vista de ProcesosVista de Procesos

Diagramas de ProducciDiagramas de Produccinn

Vista de Casos de UsoVista de Casos de Uso

Diagramas de casos de usoDiagramas de casos de uso

Diagramas de secuenciaDiagramas de secuencia

CCmo se documenta la arquitecturamo se documenta la arquitectura??

La arquitectura se documenta en un documento de arquitecturaLa arquitectura se documenta en un documento de arquitectura

Aproximadamente 100 pAproximadamente 100 pginas para un sistema grandeginas para un sistema grande

El documento incluye:El documento incluye:

Una descripciUna descripcin textual la filosofn textual la filosofa arquitecta arquitectnica (las vistas) y nica (las vistas) y los requerimientos clavelos requerimientos clave

Concesiones hechas y alternativas consideradasConcesiones hechas y alternativas consideradas

Una vista de nivel superior de la vista lUna vista de nivel superior de la vista lgica (paquetes y clases gica (paquetes y clases clave)clave)

Escenarios especEscenarios especficos de la arquitecturaficos de la arquitectura

Vistas de nivel superior de las vistas de desarrollo, proceso y Vistas de nivel superior de las vistas de desarrollo, proceso y producciproduccinn

Los mecanismos claveLos mecanismos clave

QuiQuin desarrolla la arquitectura del n desarrolla la arquitectura del

software?software?

Lo hace el equipo de arquitectura: un grupo nLo hace el equipo de arquitectura: un grupo ncleo de los mejores y cleo de los mejores y

mms experimentados desarrolladoress experimentados desarrolladores

Se establece al inicio del proyecto (antes de la fase de elaboraSe establece al inicio del proyecto (antes de la fase de elaboracicin)n)

La mayorLa mayora de los proyectos de cierta complejidad requieren un a de los proyectos de cierta complejidad requieren un

equipo de arquitectura, no un solo arquitectoequipo de arquitectura, no un solo arquitecto

Dirigido por el arquitecto jefe que estDirigido por el arquitecto jefe que est dedicado 100%dedicado 100%

Incluye a los diseIncluye a los diseadores lideres para las funciones principales y adores lideres para las funciones principales y

criticas del sistemacriticas del sistema

EvoluciEvolucin del equipo de arquitecturan del equipo de arquitectura

En la fase de elaboracin, los miembros estn 100% dedicados al equipo de arquitectura.

Durante la Construccin, los miembros se convierten diseadores lderes para equipos de aplicacin y dan soporte al equipo de arquitectura de tiempo parcial

Equipo de Arquitectura ArquitectoLideres diseadores

Desarrolladores de infraestructura

Equipo de Arquitectura Equipo de Arquitectura

ArquitectoArquitecto

PequePequeo grupo de soporteo grupo de soporte

Equipo de AplicaciEquipo de Aplicacin 1n 1

DiseDiseador Lador Lderder

Ingenieros de AplicaciIngenieros de Aplicacinn

Equipo de AplicaciEquipo de Aplicacin 2n 2

DiseDiseador Lador Lderder

Ingenieros de AplicaciIngenieros de Aplicacinn

Beneficios de un equipo de arquitecturaBeneficios de un equipo de arquitectura

EntregasEntregas

Documento de arquitecturaDocumento de arquitectura

Partes de documentos de disePartes de documentos de diseo a bajo nivelo a bajo nivel

GuGuas directivas de diseas directivas de diseo y programacio y programacinn

Elementos de planes de liberaciElementos de planes de liberacinn

Auditorias de diseAuditorias de diseo al sistema liberadoo al sistema liberado

La habilidad y efectividad del equipo de arquitectura es crLa habilidad y efectividad del equipo de arquitectura es crtica tica para el para el xito del proyectoxito del proyecto

Con una buena arquitectura, un equipo de desarrollo promedio puede tener xito. Con una arquitectura dbil, an los

desarrolladores ms expertos fracasarn

Con una buena arquitectura, un equipo de desarrollo promedio puede tener xito. Con una arquitectura dbil, an los

desarrolladores ms expertos fracasarn