1) El documento describe aspectos de arquitectura de software como la complejidad inherente a los sistemas y la necesidad de descomponerlos para hacerlos más manejables. 2) También discute cómo la arquitectura debe hacer que el desarrollo y gestión de los sistemas sea más fácil al proveer abstracciones y conceptos unificadores. 3) Finalmente, explica que la arquitectura debe considerar el comportamiento dinámico del sistema y el soporte necesario para sus funcionalidades.

1. Análisis y diseño de sistemas 2
USAC
Primer semestre 2006
Ing. Ricardo Morales
Arquitectura

2. AspectosAspectos dede arquitecturaarquitectura
ClearlyClearly thenthen,, complexitycomplexity isis aa keykey concernconcern thatthat wewe wouldwould likelike softwaresoftware
architecturearchitecture toto addressaddress.. ThisThis complexitycomplexity presentspresents itselfitself inin twotwo primaryprimary guises:guises:
IntellectualIntellectual intractabilityintractability.. TheThe complexitycomplexity isis inherentinherent inin thethe systemsystem beingbeing builtbuilt,,
andand maymay arisearise fromfrom broadbroad scopescope oror sheersheer sizesize,, noveltynovelty,, dependenciesdependencies,,
technologiestechnologies employedemployed, etc. Software, etc. Software architecturearchitecture shouldshould makemake thethe systemsystem
moremore 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 inin thethe organizationorganization andand
processesprocesses employedemployed inin buildingbuilding thethe systemsystem,, andand maymay arisearise fromfrom thethe sizesize ofof
thethe projectproject ((numbernumber ofof peoplepeople involvedinvolved inin allall aspectsaspects ofof buildingbuilding thethe systemsystem),),
dependenciesdependencies inin 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 betterenhancing communication, providing better
work partitioning with decreased and/orwork partitioning with decreased and/or moremore manageablemanageable dependenciesdependencies,,
etc.etc.

3. Aspectos de arquitectura
Given that we need to decompose the system to address complexity, what
new 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 coupling
between components (or pieces), facilitated by clean interfaces,
simplifying the problem by dividing it into reasonably independent
pieces that can be tackled separately.
• Do we have all the necessary pieces?
• The structure must support the functionality or services required of
the system. Thus, the dynamic behavior of the system must be
taken into account when designing the architecture. We must also
have 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 the
right properties

4. Arquitectura de software
Que 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

5. 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

6. Arquitectura de softwareArquitectura de software
TheThe softwaresoftware architecturearchitecture ofof aa programprogram oror computingcomputing systemsystem isis thethe structurestructure oror structuresstructures
ofof thethe systemsystem,, whichwhich comprisecomprise softwaresoftware elementselements,, thethe externallyexternally visiblevisible propertiesproperties ofof
thosethose elementselements,, andand thethe relationshipsrelationships amongamong themthem..
""ExternallyExternally visible"visible" propertiesproperties areare thosethose assumptionsassumptions otherother elementselements cancan makemake ofof anan
elementelement,, suchsuch asas itsits providedprovided servicesservices,, performanceperformance characteristicscharacteristics,, faultfault handlinghandling,,
sharedshared resourceresource usageusage,, andand soso onon.. Let'sLet's looklook atat somesome ofof thethe implicationsimplications ofof thisthis definitiondefinition
in morein more detaildetail..
FirstFirst,, architecturearchitecture defines softwaredefines software elementselements.. TheThe architecturearchitecture embodiesembodies informationinformation
aboutabout howhow thethe elementselements relaterelate toto eacheach otherother.. ThisThis meansmeans thatthat itit specificallyspecifically omitsomits
certaincertain informationinformation aboutabout elementselements thatthat doesdoes notnot pertainpertain toto theirtheir interactioninteraction..
SecondSecond,, thethe definitiondefinition makesmakes clearclear thatthat systemssystems cancan andand dodo comprisecomprise moremore thanthan oneone
structurestructure andand thatthat nono oneone structurestructure cancan irrefutablyirrefutably claimclaim toto bebe thethe architecturearchitecture..
ThirdThird,, thethe definitiondefinition impliesimplies thatthat everyevery computingcomputing systemsystem withwith software has asoftware has a
softwaresoftware architecturearchitecture becausebecause everyevery systemsystem can becan be shownshown toto comprisecomprise elementselements
andand thethe relationsrelations amongamong themthem.. EvenEven though every system has an architecture, itthough 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 asas thatthat
behaviorbehavior can becan 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 clearlyclearly
partpart ofof thethe architecturearchitecture..
FinallyFinally,, thethe definitiondefinition isis indifferentindifferent asas toto whetherwhether thethe architecturearchitecture forfor aa systemsystem isis aa
goodgood oneone oror aa badbad oneone,, meaningmeaning thatthat itit willwill allowallow oror preventprevent thethe systemsystem fromfrom meetingmeeting
itsits behavioralbehavioral,, performanceperformance,, andand lifelife--cyclecycle requirementsrequirements.. WeWe dodo notnot acceptaccept trialtrial andand
error aserror as thethe bestbest wayway toto choosechoose anan architecturearchitecture forfor aa systemsystem——thatthat is, picking anis, picking an
architecture at random, building the system from it, and hopingarchitecture at random, building the system from it, and hoping for the bestfor the best——so thisso this
raises the importance of architecture evaluation and architecturraises the importance of architecture evaluation and architecture designe design

7. Influencia del ambienteInfluencia del ambiente
ThereThere areare threethree classesclasses ofof influenceinfluence thatthat comecome fromfrom thethe developingdeveloping
organizationorganization:: immediateimmediate businessbusiness, long, long--termterm businessbusiness,, andand
organizationalorganizational structurestructure..
AnAn organizationorganization maymay havehave anan immediateimmediate businessbusiness investmentinvestment inin certaincertain
assetsassets,, suchsuch asas existingexisting architecturesarchitectures andand thethe productsproducts basedbased onon themthem..
TheThe foundationfoundation ofof aa developmentdevelopment projectproject may bemay be thatthat thethe proposedproposed
systemsystem isis thethe nextnext in ain a sequencesequence ofof similarsimilar systemssystems,, andand thethe costcost
estimatesestimates assumeassume aa highhigh degreedegree ofof assetasset rere--use.use.
AnAn organizationorganization maymay wishwish toto makemake a longa long--termterm businessbusiness investmentinvestment inin
anan infrastructureinfrastructure toto pursuepursue strategicstrategic goalsgoals andand maymay viewview thethe proposedproposed
systemsystem asas oneone meansmeans ofof financingfinancing andand extendingextending thatthat infrastructureinfrastructure..
TheThe organizationalorganizational structurestructure cancan shapeshape thethe softwaresoftware architecturearchitecture. In. In
somesome casescases thethe developmentdevelopment ofof somesome ofof thethe subsystemssubsystems can becan be
subcontractedsubcontracted becausebecause thethe subcontractorssubcontractors providedprovided specializedspecialized
expertiseexpertise.. ThisThis waswas mademade possiblepossible by aby a divisiondivision ofof functionalityfunctionality inin thethe
architecturearchitecture thatthat allowedallowed isolationisolation ofof thethe specialitiesspecialities..

8. Influencias en arquitecturaInfluencias en arquitectura
ArquitecturesArquitectures areare influencedinfluenced byby thethe
backgroundbackground andand experienceexperience ofof thethe architectsarchitects
ArquitecturesArquitectures areare influencedinfluenced byby thethe technicaltechnical
enviromentenviroment

9. Recomendaciones (proceso)Recomendaciones (proceso)
TheThe architecturearchitecture shouldshould bebe thethe productproduct ofof a singlea single
architectarchitect oror aa smallsmall groupgroup ofof architectsarchitects withwith anan identifiedidentified
leaderleader..
TheThe architectarchitect ((oror architecturearchitecture team)team) shouldshould havehave thethe
functionalfunctional requirementsrequirements forfor thethe systemsystem andand anan
articulatedarticulated,, prioritizedprioritized listlist ofof qualityquality attributesattributes ((suchsuch asas
securitysecurity oror modifiabilitymodifiability)) thatthat thethe architecturearchitecture isis expectedexpected
toto satisfysatisfy..
TheThe architecturearchitecture shouldshould bebe wellwell documenteddocumented,, withwith atat
leastleast oneone staticstatic viewview andand oneone dynamicdynamic viewview,, usingusing anan
agreedagreed--onon notationnotation thatthat allall stakeholdersstakeholders cancan understandunderstand
withwith aa minimumminimum ofof efforteffort..
TheThe architecturearchitecture shouldshould bebe circulatedcirculated toto thethe system'ssystem's
stakeholdersstakeholders,, whowho shouldshould bebe activelyactively involvedinvolved inin itsits
reviewreview..

10. Recomendaciones (proceso)Recomendaciones (proceso)
TheThe architecturearchitecture shouldshould bebe analyzedanalyzed forfor applicableapplicable quantitativequantitative
measuresmeasures ((suchsuch asas maximummaximum throughputthroughput)) andand formallyformally evaluatedevaluated forfor
qualityquality attributesattributes beforebefore itit isis too latetoo late toto makemake changeschanges toto itit..
TheThe architecturearchitecture shouldshould lendlend itselfitself toto incrementalincremental implementationimplementation viavia
thethe creationcreation ofof a "a "skeletalskeletal"" systemsystem inin whichwhich thethe communicationcommunication pathspaths
areare exercisedexercised butbut whichwhich atat firstfirst hashas minimalminimal functionalityfunctionality.. ThisThis
skeletalskeletal systemsystem cancan thenthen bebe usedused toto ""growgrow"" thethe systemsystem
incrementallyincrementally,, easingeasing thethe integrationintegration andand testingtesting effortsefforts..
TheThe architecturearchitecture shouldshould resultresult in ain a specificspecific ((andand smallsmall)) setset ofof
resourceresource contentioncontention areasareas,, thethe resolutionresolution ofof whichwhich isis clearlyclearly
specifiedspecified,, circulatedcirculated,, andand maintainedmaintained.. ForFor exampleexample,, ifif networknetwork
utilizationutilization isis anan areaarea ofof concernconcern,, thethe architectarchitect shouldshould produce (produce (andand
enforceenforce)) forfor eacheach developmentdevelopment teamteam guidelinesguidelines thatthat willwill resultresult in ain a
minimumminimum ofof networknetwork traffictraffic.. IfIf performanceperformance isis aa concernconcern,, thethe
architectsarchitects shouldshould produce (produce (andand enforceenforce) time) time budgetsbudgets forfor thethe majormajor
threadsthreads

11. Recomendaciones (Estructura)Recomendaciones (Estructura)
TheThe architecturearchitecture shouldshould featurefeature wellwell--defineddefined modulesmodules whosewhose functionalfunctional
responsibilitiesresponsibilities areare allocatedallocated onon thethe principlesprinciples ofof informationinformation hidinghiding andand
separationseparation ofof concernsconcerns.. TheThe informationinformation--hidinghiding modulesmodules shouldshould includeinclude
thosethose thatthat encapsulateencapsulate idiosyncrasiesidiosyncrasies ofof thethe computingcomputing infrastructureinfrastructure,,
thusthus insulatinginsulating thethe bulkbulk ofof thethe softwaresoftware fromfrom changechange shouldshould thethe
infrastructureinfrastructure changechange..
EachEach modulemodule shouldshould havehave aa wellwell--defineddefined interfaceinterface thatthat encapsulatesencapsulates oror
""hideshides"" changeablechangeable aspectsaspects ((suchsuch asas implementationimplementation strategiesstrategies andand
datadata structurestructure choiceschoices)) fromfrom otherother softwaresoftware thatthat usesuses itsits facilitiesfacilities.. TheseThese
interfacesinterfaces shouldshould allowallow theirtheir respectiverespective developmentdevelopment teamsteams toto workwork
largelylargely independentlyindependently ofof eacheach otherother..
QualityQuality attributesattributes shouldshould bebe achievedachieved usingusing wellwell--knownknown architecturalarchitectural
tacticstactics specificspecific toto eacheach attributeattribute..
TheThe architecturearchitecture shouldshould nevernever dependdepend onon a particulara particular versionversion ofof aa
commercialcommercial productproduct oror tooltool.. IfIf itit dependsdepends uponupon a particulara particular commercialcommercial
productproduct,, itit shouldshould bebe structuredstructured suchsuch thatthat changingchanging toto aa differentdifferent productproduct
isis straightforwardstraightforward andand inexpensiveinexpensive..

12. Recomendaciones (Estructura)Recomendaciones (Estructura)
ModulesModules thatthat produce dataproduce data shouldshould bebe separateseparate fromfrom modulesmodules thatthat
consume data.consume data. ThisThis tendstends toto increaseincrease modifiabilitymodifiability becausebecause changeschanges areare
oftenoften confinedconfined toto eithereither thethe productionproduction oror thethe consumptionconsumption sideside ofof data.data.
IfIf newnew datadata isis addedadded,, bothboth sidessides willwill havehave toto changechange,, butbut thethe separationseparation
allowsallows forfor aa stagedstaged (incremental)(incremental) upgradeupgrade..
ForFor parallelparallel--processingprocessing systemssystems,, thethe architecturearchitecture shouldshould featurefeature wellwell--
defineddefined processesprocesses oror taskstasks thatthat dodo notnot necessarilynecessarily mirrormirror thethe modulemodule
decompositiondecomposition structurestructure.. ThatThat isis,, processesprocesses maymay threadthread throughthrough moremore
thanthan oneone module; a module maymodule; a module may includeinclude proceduresprocedures thatthat areare invokedinvoked asas
partpart ofof moremore thanthan oneone processprocess..
EveryEvery tasktask oror processprocess shouldshould bebe writtenwritten soso thatthat itsits assignmentassignment toto aa
specificspecific processorprocessor can becan be easilyeasily changedchanged,, perhapsperhaps eveneven atat runtimeruntime..
TheThe architecturearchitecture shouldshould featurefeature aa smallsmall numbernumber ofof simplesimple interactioninteraction
patternspatterns.. ThatThat isis,, thethe systemsystem shouldshould dodo thethe samesame thingsthings inin thethe samesame
wayway throughoutthroughout.. ThisThis willwill aidaid inin understandabilityunderstandability, reduce, reduce developmentdevelopment
time,time, increaseincrease reliabilityreliability,, andand enhanceenhance modifiabilitymodifiability.. ItIt willwill alsoalso showshow
conceptualconceptual integrityintegrity inin thethe architecturearchitecture,, whichwhich,, whilewhile notnot measurablemeasurable,,
leadsleads toto smoothsmooth developmentdevelopment..

13. TheThe ArchitectureArchitecture DefinesDefines
ConstraintsConstraints onon ImplementationImplementation
AnAn implementationimplementation exhibitsexhibits anan architecturearchitecture ifif itit conformsconforms toto thethe
structuralstructural designdesign decisionsdecisions describeddescribed byby thethe architecturearchitecture.. ThisThis
meansmeans thatthat thethe implementationimplementation mustmust bebe divideddivided intointo thethe prescribedprescribed
elementselements,, thethe elementselements mustmust interactinteract withwith eacheach otherother inin thethe
prescribedprescribed fashion,fashion, andand eacheach elementelement mustmust fulfillfulfill itsits responsibilityresponsibility toto
thethe othersothers asas dictateddictated byby thethe architecturearchitecture..
ResourceResource allocationallocation decisionsdecisions alsoalso constrainconstrain implementationsimplementations..
TheseThese decisionsdecisions may be invisiblemay be invisible toto implementorsimplementors workingworking onon
individualindividual elementselements.. TheThe constraintsconstraints permitpermit aa separationseparation ofof concernsconcerns
thatthat allowsallows managementmanagement decisionsdecisions toto makemake thethe best usebest use ofof
personnelpersonnel andand computationalcomputational capacitycapacity.. ElementElement buildersbuilders mustmust bebe
fluentfluent inin thethe specificationspecification ofof theirtheir individualindividual elementselements butbut notnot inin
architecturalarchitectural tradeoffstradeoffs.. ConverselyConversely,, architectsarchitects needneed notnot bebe expertsexperts inin
allall aspectsaspects ofof algorithmalgorithm designdesign oror thethe intricaciesintricacies ofof thethe programmingprogramming
languagelanguage,, butbut theythey areare thethe onesones responsibleresponsible forfor thethe architecturalarchitectural
tradeoffstradeoffs..

14. TheThe architecturearchitecture inhibitsinhibits oror enablesenables aa
system'ssystem's qualityquality attributesattributes
WhetherWhether aa systemsystem willwill bebe ableable toto exhibitexhibit itsits desireddesired ((oror requiredrequired)) qualityquality
attributesattributes isis substantiallysubstantially determineddetermined byby itsits architecturearchitecture..
IfIf youryour systemsystem requiresrequires highhigh performanceperformance,, youyou needneed toto managemanage thethe
timetime--basedbased behaviorbehavior ofof elementselements andand thethe frequencyfrequency andand volumevolume ofof interinter--
elementelement communicationcommunication..
IfIf modifiabilitymodifiability isis importantimportant,, youyou needneed toto assignassign responsibilitiesresponsibilities toto
elementselements suchsuch thatthat changeschanges toto thethe systemsystem dodo notnot havehave farfar--reachingreaching
consequencesconsequences..
IfIf youryour systemsystem mustmust bebe highlyhighly securesecure,, youyou needneed toto managemanage andand protectprotect
interinter--elementelement communicationcommunication andand whichwhich elementselements areare allowedallowed toto accessaccess
whichwhich informationinformation.. YouYou maymay alsoalso needneed toto introduceintroduce specializedspecialized elementselements
((suchsuch as aas a trustedtrusted kernelkernel)) intointo thethe architecturearchitecture..
IfIf youyou believebelieve scalabilityscalability willwill bebe neededneeded inin youryour systemsystem,, youyou havehave toto
carefullycarefully localizelocalize thethe useuse ofof resourcesresources toto facilitatefacilitate thethe introductionintroduction ofof
higherhigher--capacitycapacity replacementsreplacements..
IfIf youryour projectproject needsneeds toto deliverdeliver incrementalincremental subsetssubsets ofof thethe systemsystem,, youyou
mustmust carefullycarefully managemanage interinter--componentcomponent usageusage..
IfIf youyou wantwant thethe elementselements ofof youryour systemsystem toto be rebe re--usable inusable in otherother
systemssystems,, youyou needneed toto restrictrestrict interinter--elementelement couplingcoupling soso thatthat whenwhen youyou
extractextract anan elementelement itit doesdoes notnot come outcome out withwith tootoo manymany attachmentsattachments toto
itsits currentcurrent environmentenvironment toto bebe usefuluseful..

15. TheThe architecturearchitecture inhibitsinhibits oror enablesenables
aa system'ssystem's qualityquality attributesattributes (II)(II)
TheThe strategiesstrategies forfor thesethese andand otherother qualityquality attributesattributes areare
supremelysupremely architecturalarchitectural.. ItIt isis importantimportant toto understandunderstand,,
howeverhowever,, thatthat architecturearchitecture alonealone cannotcannot guaranteeguarantee
functionalityfunctionality oror qualityquality.. PoorPoor downstreamdownstream designdesign oror
implementationimplementation decisionsdecisions cancan 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 aa functionfunction ofof architecturalarchitectural designdesign.. ToTo
ensureensure qualityquality, a, a goodgood architecturearchitecture isis necessarynecessary,, butbut notnot
sufficientsufficient..

16. WhyWhy IsIs SoftwareSoftware ArchitectureArchitecture
ImportantImportant??
ThereThere areare fundamentallyfundamentally threethree reasonsreasons forfor softwaresoftware architecture'sarchitecture's
importantanceimportantance..
CommunicationCommunication amongamong stakeholdersstakeholders. Software. Software architecturearchitecture representsrepresents
aa commoncommon abstractionabstraction ofof aa systemsystem thatthat mostmost ifif notnot allall ofof thethe system'ssystem's
stakeholdersstakeholders can use as acan use as a basisbasis forfor mutualmutual understandingunderstanding,, negotiationnegotiation,,
consensusconsensus,, andand communicationcommunication..
EarlyEarly designdesign decisionsdecisions. Software. Software architecturearchitecture manifestsmanifests thethe earliestearliest
designdesign decisionsdecisions aboutabout aa systemsystem,, andand thesethese earlyearly bindingsbindings carrycarry weightweight
farfar outout ofof proportionproportion toto theirtheir individualindividual gravitygravity withwith respectrespect toto thethe
system'ssystem's remainingremaining developmentdevelopment,, itsits deploymentdeployment,, andand itsits maintenancemaintenance
lifelife.. ItIt isis alsoalso thethe earliestearliest pointpoint atat whichwhich designdesign decisionsdecisions governinggoverning thethe
systemsystem toto bebe builtbuilt can becan be analyzedanalyzed..
TransferableTransferable abstractionabstraction ofof aa systemsystem. Software. Software architecturearchitecture constitutesconstitutes
aa relativelyrelatively smallsmall,, intellectuallyintellectually graspablegraspable modelmodel forfor how ahow a systemsystem isis
structuredstructured andand howhow itsits elementselements workwork togethertogether,, andand thisthis modelmodel isis
transferabletransferable acrossacross systemssystems. In particular,. In particular, itit can becan be appliedapplied toto otherother
systemssystems exhibitingexhibiting similarsimilar qualityquality attributeattribute andand functionalfunctional requirementsrequirements
andand cancan promotepromote largelarge--scalescale rere--use.use.

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. VisiVisióón arquitectn arquitectóónicanica
Dos rasgos comunes de prDos rasgos comunes de práácticamente todo proyecto de OOcticamente 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 en 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 des de
abstracciones y mecanismos en comabstracciones y mecanismos en comúúnn

24. Atributos de buenas arquitecturasAtributos de buenas arquitecturas
Las buenas arquitecturas se construyen en capas deLas 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 yCada 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 lan 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 violann de una capa no violan
suposiciones hechas por sus clientessuposiciones hechas por sus clientes

25. 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 des de
desarrollo iterativo e incrementaldesarrollo iterativo e incremental
A un equipo de arquitectura pequeA un equipo de arquitectura pequeñño y con experiencia dirigido poro 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

26. 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 sistemaLos diagramas de clases no muestran como el sistema
encaja en el hardwareencaja en el hardware
Los diagramas deLos diagramas de deploymentdeployment o implementacio implementacióón, non, no
muestran que partes del sistema son componentesmuestran que partes del sistema son componentes
empaquetados (COTS,empaquetados (COTS, commercial offcommercial off--thethe--shelfshelf))

27. Una arquitectura requiere mUna arquitectura requiere múúltiples vistasltiples vistas
Para describir completamente una arquitectura, se necesitanPara 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 lastica 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 sedigo se
organiza en paquetes y librerorganiza en paquetes y libreríías y el uso de paquetes deas 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 otrasFinalmente una vista de escenarios que explica como las otras
cuatro vistas funcionan juntascuatro vistas funcionan juntas

28. El ModeloEl 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

29. Vista lVista lóógicagica
La vista lLa vista lóógica de la arquitectura tiene que ver congica 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éérminosrminos
de servicios a los usuariosde servicios a los usuarios
Proporciona una imagen estProporciona una imagen estáática de las clasestica de las clases
primarias y sus relacionesprimarias y sus relaciones
La vista lLa vista lóógica se captura en diagramas de clasegica se captura en diagramas de clase
que contienen los paquetes, clases y relaciones queque contienen los paquetes, clases y relaciones que
representan las abstracciones clave del sistema enrepresentan las abstracciones clave del sistema en
desarrollodesarrollo

30. Vista de componentesVista de componentes
La vista de componentes de la arquitectura se ocupa de laLa vista de componentes de la arquitectura se ocupa de la
organizaciorganizacióón actual del software dentro del ambiente den actual del software dentro del ambiente de
desarrollodesarrollo
Los diagramas de componentes se crean para mostrar losLos diagramas de componentes se crean para mostrar los
paquetes (en desarrollo) y componentes que forman elpaquetes (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 ena de capas en
donde cada capa tiene una interfase bien definidadonde cada capa tiene una interfase bien definida

31. ¿¿QuQuéé es un componente?es un componente?
Un componente es una unidad de cUn componente es una unidad de cóódigo fuente que sirve comodigo 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 paraLos 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óónn
cooperativa o que necesite estar muy prcooperativa o que necesite estar muy próóximo para la eficienciaximo para la eficiencia
de la implementacide la implementacióónn
NotaciNotacióón de componentes:n de componentes:
Nombre de componenteNombre de componente

32. Correspondencia entre paquetes en lasCorrespondencia 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 correspondergica 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 lassica pueden diferir por las
siguientes razones:siguientes razones:
Los paquetes en la vista lLos paquetes en la vista lóógica se combinan, para mantenergica se combinan, para mantener
juntos objetos que mantienen estrecha comunicacijuntos objetos que mantienen estrecha comunicacióón para lan para la
implementaciimplementacióónn
Los paquetes en la vista de componentes se aLos paquetes en la vista de componentes se aññaden paraaden para
implementar funcionalidad de bajo nivel que no se representadaimplementar 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 den del trabajo de un equipo de
desarrollo influencia la asignacidesarrollo influencia la asignacióón de paquetes y componentesn de paquetes y componentes
en la vista de componentesen la vista de componentes

33. Clases y componentesClases y componentes
Los componentes son piezas de software que generan laLos componentes son piezas de software que generan la
base del cbase del cóódigo fuentedigo fuente
Las clases son asignadas a componentes. El componente esLas 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 elRecuerde...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
horaDelD
ia
horasCré
dito

34. Vista de procesosVista de procesos
La vista de procesos de arquitectura se enfoca en laLa 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 laEl 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 ysu confiabilidad, rendimiento, manejo del sistema y
sincronizacisincronizacióónn

35. Vista de producciVista de produccióónn
La vista de producciLa vista de produccióón de arquitectura asocian 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 enfuncionamiento y tolerancia a fallas se toman en
consideraciconsideracióónn
Los diagramas de producciLos diagramas de produccióón se crean para mostrarn se crean para mostrar
los diferentes nodos (procesadores y dispositivos)los diferentes nodos (procesadores y dispositivos)
en el sistemaen el sistema

36. Diagrama de producciDiagrama de produccióónn
Un diagrama de producciUn diagrama de produccióón muestra la asignacin muestra la asignacióón den 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 deProcesadores 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 deas de
comunicacicomunicacióón entre ellosn entre ellos
Los elementos esenciales de un diagrama de desarrollo sonLos elementos esenciales de un diagrama de desarrollo son
los nodos y sus conexioneslos nodos y sus conexiones

37. Asociando paquetes de desarrollo aAsociando paquetes de desarrollo a
procesos ejecutablesprocesos ejecutables
Asociar paquetes de desarrollo a procesos ejecutablesAsociar paquetes de desarrollo a procesos ejecutables
involucra entendimiento de la topologinvolucra entendimiento de la topologíía del sistema y lasa 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 minimizarMantener las asociaciones de clases juntas para minimizar
comunicacicomunicacióón entre procesos (IPC)n entre procesos (IPC)
Estrategia de IPCEstrategia 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úúltiplesltiples
procesadores de hardware o sistemas distribuidos durante elprocesadores de hardware o sistemas distribuidos durante el
disediseñño del sistemao del sistema

38. Asociando procesos ejecutables a hardwareAsociando procesos ejecutables a hardware
Los procesos se deben asignar a un dispositivo de hardwareLos 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 sistemaSobrecarga o balance de procesadores en un sistema
distribuidodistribuido
Tolerancia a fallasTolerancia a fallas
......

39. 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 lao 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, degica, de procesos, de
desarrollo y de produccidesarrollo y de produccióón de la arquitecturan de la arquitectura

40. LaLa ““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óónn
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

41. ¿¿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) ynica (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 clasesgica (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 yVistas de nivel superior de las vistas de desarrollo, proceso y
producciproduccióónn
Los mecanismos claveLos mecanismos clave

42. ¿¿QuiQuiéén desarrolla la arquitectura deln 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 ycleo 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 una 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 yadores lideres para las funciones principales y
criticas del sistemacriticas del sistema

43. 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 ArquitecturaEquipo 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

44. 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ííticatica
para elpara 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