4+1(vistas)
TRANSCRIPT
Análisis y diseño 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 manageablemanageable——byby 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 managemanage——byby 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 fit—that is fit that maintains system integrity—also 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 definición estándar, 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 organización
de un sistema de software, la selección de sus elementos estructurales y las
interfaces de que se compone, junto con con su comportamiento como se
especifica en la colaboración entre dichos elementos, la composición 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 colección de sistemas consiste de las
decisiones importantes de diseño acerca de las estructuras de software y la
interacción entre dichas estructuras que comprenden los sistemas. Estas
decisiones de diseño permiten un conjunto deseado de cualidades que el sistema
debe soportar para ser exitoso. Las decisiones de diseño 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 systemsystem——thatthat 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 best——so 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 cyclecycle——fromfrom highhigh--levellevel designdesign toto codingcoding andand
implementationimplementation——affectaffect 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 architecture—the 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.
División 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
VisiVisióón arquitectn arquitectóónicanica
Dos rasgos comunes de prDos rasgos comunes de práácticamente todo proyecto de OO cticamente todo proyecto de OO
son:son:
�� La existencia de una fuerte visiLa existencia de una fuerte visióón arquitectn arquitectóónicanica
�� La aplicaciLa aplicacióón 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 comúún alcanzado a travn alcanzado a travéés de s de
abstracciones y mecanismos en comabstracciones y mecanismos en comúúnn
Atributos de buenas arquitecturasAtributos de buenas arquitecturas
Las buenas arquitecturas se construyen en capas de Las buenas arquitecturas se construyen en capas de
abstracciabstraccióón bien definidasn bien definidas
�� Cada capa representa una abstracciCada capa representa una abstraccióón 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 máás bajo de abstraccis bajo de abstraccióónn
Existe una separaciExiste una separacióón clara entre la interfase y la n clara entre la interfase y la
implementaciimplementacióón de cada capan de cada capa
�� Los cambios a la implementaciLos cambios a la implementacióón 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 diseñño 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 travéés de s de
desarrollo iterativo e incrementaldesarrollo iterativo e incremental
A un equipo de arquitectura pequeA un equipo de arquitectura pequeñño 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 arquitectóónica 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 iteracióónn
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 múúltiples requieren vistas mltiples requieren vistas múúltiplesltiples
�� 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 implementacióón, 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 múúltiples vistasltiples vistas
Para describir completamente una arquitectura, se necesitan Para describir completamente una arquitectura, se necesitan
cuatro vistas:cuatro vistas:
�� La vista lLa vista lóógica que proporciona una imagen estgica que proporciona una imagen estáática 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 cóódigo se digo se
organiza en paquetes y librerorganiza en paquetes y libreríías 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 produccióón 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 Lógica
Funcionalidad
Vista de Producción
Rendimiento, Disponibilidad,
Tolerancia a Fallas, Escalabilidad,
Entrega e Instalación
Vista de Componentes
Manejo de Software,
Reutilización, Portabilidad
Vista de Procesos
Rendimiento,
Disponibilidad
Tolerancia a Fallas
Vista de Casos de Uso
Entendimiento
Usabilidad
Vista lVista lóógicagica
La vista lLa vista lóógica 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 téérminos rminos
de servicios a los usuariosde servicios a los usuarios
Proporciona una imagen estProporciona una imagen estáática de las clases tica de las clases
primarias y sus relacionesprimarias y sus relaciones
La vista lLa vista lóógica 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
organizaciorganizacióón 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 asignacióón de clases a componentesn de clases a componentes
�� Muestra la asignaciMuestra la asignacióón de componentes a paquetesn de componentes a paquetes
Los paquetes se organizan en una jerarquLos paquetes se organizan en una jerarquíía 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 cóódigo fuente que sirve como digo fuente que sirve como
bloque para construir la estructura fbloque para construir la estructura fíísica 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 especííficos de componentesficos de componentes
�� Ejemplos: Ejemplos: exeexe, , dlldll, programas principales (, programas principales (mainmain), ),
encabezados (encabezados (headersheaders), m), móódulos, formasdulos, formas
Agrupe las clases en un componente que tenga una funciAgrupe las clases en un componente que tenga una funcióón n
cooperativa o que necesite estar muy prcooperativa o que necesite estar muy próóximo para la eficiencia ximo para la eficiencia
de la implementacide la implementacióónn
NotaciNotacióón de componentes:n de componentes:
Nombre de componenteNombre de componente
Correspondencia entre paquetes en las Correspondencia entre paquetes en las
vistas lvistas lóógica y de componentesgica y de componentes
En general, un paquete en la vista lEn general, un paquete en la vista lóógica 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 lóógica y la estructura fgica y la estructura fíísica pueden diferir por las sica pueden diferir por las siguientes razones:siguientes razones:
�� Los paquetes en la vista lLos paquetes en la vista lóógica se combinan, para mantener gica se combinan, para mantener juntos objetos que mantienen estrecha comunicacijuntos objetos que mantienen estrecha comunicacióón para la n para la implementaciimplementacióónn
�� Los paquetes en la vista de componentes se aLos paquetes en la vista de componentes se aññaden 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 anáálisislisis
�� La estructura de distribuciLa estructura de distribucióón del trabajo de un equipo de n del trabajo de un equipo de desarrollo influencia la asignacidesarrollo influencia la asignacióón 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 cóódigo 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 cohesióón 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 reutilizacióónn
Componente con clases asignadasComponente con clases asignadas
<<entidad>>
Curso
buscarPrerequisito() : ListaDeCursos
nombre descripción lugar horaDelDiahorasCrédito
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
descomposicidescomposicióón de los procesosn de los procesos
Esta vista muestra la asignaciEsta vista muestra la asignacióón 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
asignaciasignacióón 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
sincronizacisincronizacióónn
Vista de producciVista de produccióónn
La vista de producciLa vista de produccióón 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
consideraciconsideracióónn
Los diagramas de producciLos diagramas de produccióón 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 produccióónn
Un diagrama de producciUn diagrama de produccióón muestra la asignacin muestra la asignacióón de n de
componentes a nodos en la vista de produccicomponentes a nodos en la vista de produccióón 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 víías de as de
comunicacicomunicacióón 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 topologíía 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
comunicacicomunicacióón entre procesos (IPC)n entre procesos (IPC)
�� Estrategia de IPC Estrategia de IPC –– cliente/suplidor u otra?cliente/suplidor u otra?
�� TTéécnicas de proceso distribuidocnicas de proceso distribuido
Se deben resolver situaciones que involucren mSe deben resolver situaciones que involucren múúltiples ltiples
procesadores de hardware o sistemas distribuidos durante el procesadores de hardware o sistemas distribuidos durante el
disediseñño 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 ejecucióónn
Entre las consideraciones estEntre las consideraciones estáán: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 comunicacióónn
�� LocalizaciLocalizacióón fn fíísica 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 diseñño de la o de la
arquitecturaarquitectura
�� Abstracciones de requerimientos grandes y complejosAbstracciones de requerimientos grandes y complejos
�� IdentificaciIdentificacióón de interfases crn de interfases crííticasticas
�� Obliga a los diseObliga a los diseññadores a enfocarse en temas especadores a enfocarse en temas especííficosficos
Demuestran y validan las vistas lDemuestran y validan las vistas lóógica, de procesos, de gica, de procesos, de
desarrollo y de produccidesarrollo y de produccióón de la arquitecturan de la arquitectura
La La ““Vista 4+1Vista 4+1”” de un modelo UMLde un modelo UML
Vista LVista Lóógicagica
Diagramas de clase,Diagramas de clase,
Diagramas de secuenciaDiagramas de secuencia
Vista de ProducciVista de Produccióón n
Diagramas de ProducciDiagramas de Produccióónn
Vista de ComponentesVista de Componentes
Diagramas de componentesDiagramas de componentes
Vista de ProcesosVista de Procesos
Diagramas de ProducciDiagramas de Produccióónn
Vista de Casos de UsoVista de Casos de Uso
Diagramas de casos de usoDiagramas de casos de uso
Diagramas de secuenciaDiagramas de secuencia
¿¿CCóómo 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 pááginas para un sistema grandeginas para un sistema grande
El documento incluye:El documento incluye:
�� Una descripciUna descripcióón textual la filosofn textual la filosofíía arquitecta arquitectóónica (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 lóógica (paquetes y clases gica (paquetes y clases clave)clave)
�� Escenarios especEscenarios especííficos 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 producciproduccióónn
�� Los mecanismos claveLos mecanismos clave
¿¿QuiQuiéén 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 núúcleo de los mejores y cleo de los mejores y
mmáás 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 elaboracicióón)n)
La mayorLa mayoríía 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 diseññadores lideres para las funciones principales y adores lideres para las funciones principales y
criticas del sistemacriticas del sistema
EvoluciEvolucióón del equipo de arquitecturan del equipo de arquitectura
En la fase de elaboración, los miembros están 100% dedicados al equipo de arquitectura.
Durante la Construcción, los miembros se convierten diseñadores líderes para equipos de aplicación y dan soporte al equipo de arquitectura de tiempo parcial
Equipo de Arquitectura •Arquitecto•Lideres diseñadores
•Desarrolladores de infraestructura
Equipo de Arquitectura Equipo de Arquitectura
••ArquitectoArquitecto
••PequePequeñño grupo de soporteo grupo de soporte
Equipo de AplicaciEquipo de Aplicacióón 1n 1
••DiseDiseññador Lador Lííderder
••Ingenieros de AplicaciIngenieros de Aplicacióónn
Equipo de AplicaciEquipo de Aplicacióón 2n 2
••DiseDiseññador Lador Lííderder
••Ingenieros de AplicaciIngenieros de Aplicacióónn
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 diseñño a bajo nivelo a bajo nivel
�� GuGuíías directivas de diseas directivas de diseñño y programacio y programacióónn
�� Elementos de planes de liberaciElementos de planes de liberacióónn
�� Auditorias de diseAuditorias de diseñño al sistema liberadoo al sistema liberado
La habilidad y efectividad del equipo de arquitectura es crLa habilidad y efectividad del equipo de arquitectura es críítica 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 débil, aún los
desarrolladores más expertos fracasarán
Con una buena arquitectura, un equipo de desarrollo promedio puede tener éxito. Con una arquitectura débil, aún los
desarrolladores más expertos fracasarán