-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
1/12
unidad3ingenieradelsoftwaremircoles,8demayode2013
unidad3Arquitecturasdesoftware
Arquitecturas de software
Enlosiniciosdelainformtica,laprogramacinseconsiderabaunarteysedesarrollabacomotal,debidoaladificultadqueentraabaparalamayoradelas
personas, pero con el tiempo se han ido descubriendo y
desarrollandoformas y guas generales, con base a las cuales se
puedan resolver
losproblemas.Aestas,seleshadenominadoArquitecturadeSoftware,porque,a
semejanza de los planos de un edificio o construccin, estas indican
laestructura,funcionamientoeinteraccinentrelaspartesdelsoftware.
En el libro "An introduction to Software Architecture", David
Garlan y MaryShaw definen que la Arquitectura es un nivel de diseo
que hace foco enaspectos "ms all de los algoritmos y estructuras de
datos de
lacomputacineldiseoyespecificacindelaestructuraglobaldelsistemaesunnuevotipodeproblema".
Laarquitecturadesoftwaresecomponepor:
clientesyservidores.basesdedatos.filtos.nivelesensistemasjerrquico.
Entre los componentes de la arquitectura de software existe un
conjunto deinteraccionesentrelasquesobresalen:
llamadasaprocedimientos.comportamientodevariables.protocolosclienteservidor.transmicinasncronadeeventos.
3.1 Descomposicin modular
Capacidadde empleo de componentesmodulares.Si unmtodode
diseopermite ensamblar los componentesdediseo (reusables)
existentesenunsistema nuevo, producir una solucin modular que no
inventa nada yainventado.
Componenteseinteracciones
Componentes
Interacciones
Descomposicinmodular
2013(1)
mayo(1)
unidad3Arquitecturasdesoftware
Archivodelblog
lelsieViteSeguir 12
Vertodomiperfil
Datospersonales
1 Ms Siguienteblog Crearunblog Acceder
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
2/12
Capacidad de comprensin modular. Si un mdulo se puede
comprendercomounaunidadautnoma(sin referenciasaotrosmdulos)serms
fcildeconstruirydecambiar.
Continuidad modular. Si pequeos cambios en los requisitos del
sistemaprovocan cambios en los mdulos individuales, en vez de
cambiosgeneralizados en el sistema, se minimizar el impacto de los
efectossecundariosdeloscambios.
Proteccin modular. Si dentro de un mdulo se produce una
condicinaberranteysusefectosselimitanaesemdulo,seminimizarelimpactodelosefectossecundariosinducidosporloserrores.
Finalmente, es importante destacar que un sistema se puede
disearmodularmente, incluso aunque su implementacin deba ser
monoltica.Existen situaciones (por ejemplo, software en tiempo
real, softwareempotrado) en donde no es admisible que los
subprogramas
introduzcansobrecargasdememoriaydevelocidadpormnimosquesean(porejemplo,subrutinas,procedimientos).En
talessituacioneselsoftwarepodrydeberdisearseconmodularidadcomofilosofapredominante.
El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente
delprograma puede no tener un aspecto modular a primera vista, se
hamantenido la filosofa y el programa proporcionar los beneficios
de
unsistemamodular.Eldiseomodularproponedividirelsistemaenpartesdiferenciadasydefinirsusinterfaces.susventajas:claridad,reduccindecostosyreutilizacin.
Lospasosaseguirson:
1.Identificarlosmdulos
2.Describircadamdulo
3.Describirlasrelacionesentremdulos
Una descomposicinmodular debe poseer ciertas cualidadesmnimas
paraquesepuedaconsiderarsuficientevalidad.
1.Independenciafuncional
2.Acoplamiento
3.Cohesin
4.Comprensibilidad
5.Adaptabilidad
Eldiseomodularesunametodologadedesarrollodeprogramascomplejos,
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
3/12
que utiliza la filosofa TOPDOWN, conocida tambin como
diseodescendenteorefinamientoporpasossucesivosocomnmenteconocidoporlos
programadores como Divide y Vencers puesto que enfrenta
unproblemadesdeloabstracto(TOP)hacialoparticular(DOWN).
Estatcnicaconsisteendividirelproblemaenunconjuntodesubproblemas,y
estos a su vez en otros de mayor facilidad de trabajo generando
losMdulosFuncionales.
Ladescomposicinmodularcontribuyealascaractersticasdeseablesparalaprogramacin
estructurada y que permite resolver cada mdulo de
formaindependientey,sinosesaberesolveralgunodeellos,puedeasignrseleunnombre
y pasar al desarrollo de otro mdulo y, ms adelante retomar elmdulo
incompletoparadarlesolucinalobtenermayorconocimientosobredichoproceso,esdecir,
la solucindelproblemanosedetienepor
faltadeconocimientodealgnprocesoenparticular.
3.2 Patrones de
DiseoLospatronesdediseosonelesqueletodelassolucionesaproblemascomuneseneldesarrollodesoftware.Enotraspalabras,
brindanuna solucin yaprobadaydocumentadaaproblemasdedesarrollo de
software que estn sujetos a contextos similares. Debemos
tenerpresente los siguientes elementos de un patrn: su nombre, el
problema
(cuandoaplicarunpatrn),lasolucin(descripcinabstractadelproblema)ylasconsecuencias(costosybeneficios).Grande
fue mi sorpresa al averiguar que existen varios patrones de
diseopopularmenteconocidos,loscualesseclasificancomosemuestraacontinuacin:
PatronesCreacionales:Inicializacinyconfiguracindeobjetos.PatronesEstructurales:Separanlainterfazdelaimplementacin.Seocupan
decmolasclasesyobjetosseagrupan,paraformarestructurasmsgrandes.PatronesdeComportamiento:Msquedescribirobjetosoclases,describenla
comunicacinentreellos.
ObjetivosdelospatronesLospatronesdediseopretenden:
Proporcionar catlogos de elementos reusables en el diseo
desistemassoftware.Evitar la reiteracinen
labsquedadesolucionesaproblemasyaconocidosysolucionadosanteriormente.Formalizarunvocabulariocomnentrediseadores.Estandarizarelmodoenqueserealizaeldiseo.Facilitarelaprendizajedelasnuevasgeneracionesdediseadorescondensandoconocimientoyaexistente.
Asimismo,nopretenden:Imponerciertasalternativasdediseofrenteaotras.Eliminarlacreatividadinherentealprocesodediseo.
Noesobligatorioutilizarlospatrones,soloesaconsejableenelcasodetenerel
mismo problema o similar que soluciona el patrn, siempre teniendo
encuentaqueenuncasoparticularpuedenoseraplicable."Abusaroforzarelusodelospatronespuedeserunerror".CategorasdepatronesSegnlaescalaoniveldeabstraccin:
Patrones de arquitectura: Aquellos que expresan un
esquemaorganizativoestructuralfundamentalparasistemasdesoftware.Patronesdediseo:Aquellosqueexpresanesquemasparadefinirestructuras
de diseo (o sus relaciones) con las que
construirsistemasdesoftware.Dialectos:Patronesdebajonivelespecficosparaun
lenguajedeprogramacinoentornoconcreto.
Adems, tambin es importante resear el concepto de "antipatrn
de
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
4/12
diseo",quecon formasemejantea ladeunpatrn,
intentaprevenircontraerrorescomunesdediseoenelsoftware.Laideadelosantipatronesesdaraconocer
losproblemasqueacarreanciertosdiseosmuy frecuentes,paraintentar
evitar que diferentes sistemas acaben una y otra vez en el
mismocallejnsinsalidaporhabercometidolosmismoserrores.Ademsdelospatronesyavistosactualmenteexistenotrospatronescomoelsiguiente:
Interaccin:Sonpatronesquenospermiteneldiseodeinterfacesweb.
EstructurasoplantillasdepatronesParadescribirunpatrnseusanplantillasmsomenosestandarizadas,deformaqueseexpresenuniformementeypuedanconstituirefectivamenteunmediodecomunicacinuniformeentrediseadores.Variosautoreseminentesenestareahanpropuestoplantillasligeramentedistintas,sibienlamayoradefinenlosmismosconceptosbsicos.LaplantillamscomneslautilizadaprecisamenteporelGoFyconstadelossiguientesapartados:
Nombredelpatrn: nombre estndar del patrn por el cual
serreconocidoenlacomunidad(normalmenteseexpresaneningls).Clasificacin
del patrn: creacional, estructural o
decomportamiento.Intencin:Quproblemapretenderesolverelpatrn?Tambin
conocido como: Otros nombres de uso comn para
elpatrn.Motivacin:Escenariodeejemploparalaaplicacindelpatrn.Aplicabilidad:Usoscomunesycriteriosdeaplicabilidaddelpatrn.Estructura:
Diagramas de clases oportunos para describir
lasclasesqueintervienenenelpatrn.Participantes: Enumeracin y
descripcin de las
entidadesabstractas(ysusroles)queparticipanenelpatrn.Colaboraciones:
Explicacin de las interrelaciones que se
danentrelosparticipantes.Consecuencias:Consecuenciaspositivasynegativaseneldiseoderivadasdelaaplicacindelpatrn.Implementacin:
Tcnicas o comentarios oportunos de cara a
laimplementacindelpatrn.Cdigodeejemplo:Cdigofuenteejemplodeimplementacindelpatrn.Usosconocidos:Ejemplosdesistemasrealesqueusanelpatrn.Patronesrelacionados:Referenciascruzadasconotrospatrones.
3.3 Arquitectura de dominio especfico
El reto para el diseo es disear el software y hardware para
proporcionar
caractersticas deseables a los sistemas distribuidos y, al mismo
tiempo,
minimizar
losproblemaspropiosaestossistemas.Esnecesariocomprender
las ventajas y desventajas de las diferentes arquitecturas de
sistemas
distribuidos.Aquse tratandos
tiposgenricosdearquitecturasdesistemas
distribuidos:Arquitecturaclienteservidor.
Enestecasoelsistemapuedeservistocomounconjuntodeserviciosquese
proporcionanalosclientesquehacenusodedichosservicios.Losservidores
ylosclientessetratandeformadiferenteenestossistemas.
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
5/12
Arquitecturasdeobjetosdistribuidos.Paraestaarquitecturanohaydistincin
entreservidoresyclientes,yelsistemapuedeservistocomounconjuntode
objetosque interaccionancuya localizacines
irrelevante.Nohaydistincin
entre un proveedor de servicios y el usuario de estos servicios.
Ambas
arquitecturasseusanampliamenteenlaindustria,peroladistribucindelas
aplicacionesgeneralmentetienelugardentrodeunanicaorganizacin.
La distribucin soportada es, por lo tanto, intraorganizacional.
Tambin se
pueden tomar dos tipos ms de arquitecturas distribuidas que son
ms
adecuadas para la distribucin interorganizacional: arquitectura
de sistemas
peertopeer
(p2p)yarquitecturasorientadasaservicios.Lossistemaspeer
topeerhansidousadosprincipalmenteparasistemaspersonales,peroestn
comenzandoausarseparaaplicacionesdeempresa.
Sonmodelosdearquitecturaloscualessonespecficosparaalgndominiode
aplicacin.
Dostiposdemodelosdedominioespecficoson:
Modelos Genricos. Estos son abstracciones de un nmero de
sistemas
realesyqueencapsulanlascaractersticasprincipalesdeestossistemas.
Modelos de Referencia. Estos sonms abstractos, sonmodelos
idealistas.
Proporcionanunsignificadodeinformacinconrespectoasistemasdeclases
ycomparacindediversasarquitecturas.
MODELOSGENRICOS(1)
UnmodelodeCompiladoresunejemploconocidoatravsdeotrosmodelos
queexistenendominiosdeaplicacionesespecializadas:
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
6/12
AnalizadorLxico
TabladeSmbolos
AnalizadordeSintxis
AnalizadorSemntico
Generador/OptimizadordeCdigo
Un modelo de compilador genrico puede ser organizado de acuerdo
a
diversosmodelosdearquitectura.
ARQUITECTURASDEREFERENCIA
Los modelos de referencias son derivados del estudio del dominio
de una
aplicacin,enlugardelestudiodesistemasexistentes.
Puedenserutilizadoscomounabaseparalaimplementacindeunsistema
oparacompararsistemasdiversos.
Actan como un estndar, contra el cual los sistemas que pueden
ser
evaluados.
El modelo OSI es un modelo en capas para sistemas de
comunicacin, y
adems,esunmodelodereferencia.
Laarquitecturadesoftwareeslaresponsabledeladerivacindeunmodelo
desistemaestructural,unmodelodecontrolyunmodelodedescomposicin
ensubsistemas.
Lossistemasgrandesraravezconformanunmodelosimpledearquitectura.
Losmodelosdeestructuracindeunsistema incluyenmodelos
repositorios,
losmodelosclienteservidorylosmodelosdemquinaabstracta.
Losmodelosdecontrolincluyencontrolcentralizadoymodelosmanejadores
de eventos.Los modelos de descomposicin modular incluyen los
modelos
orientadosaobjetosylosmodelosdeflujodedatos.
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
7/12
3.4 Diseo de software de arquitecturamultiprocesador
Un sistema multiproceso o multitarea es aquel que permite
ejecutar
variosprocesosdeformaconcurrente,larazonesporqueactualmentelamayoriadelascpussolopuedenejecutarunprocesocadavez.Launicaformadequeseejecutendeformasimultaneavariosprocesosestenervariascpusyaseaenunamaquinaoenvariasenunsistemadistribuido.Laventajadeunsistemamultiprocesorecideen
laoperacion
llamadacambiodecontextoyconsisteenquitaraunprocesodelacpu,ejecutarotroprocesoyvolveracolocarelprimerosinqueseenteredenada.El
multiproceso no es dificil de entender : mas procesadores significa
maspotenciacomputacional.Un conjunto de tareas puede ser
completadomas rapidamente si hay
variasunidadesdeprocesoejecutandolasenparalelo.
VENTAJAS
EseconomicaLascomputadorasparalelassoninherentesescalablespermitiendoactualizarlasparaadecuarsealanecesidad
DESVENTAJAS
Puedeser limitante fisica,existen factoresque limitan
lavelocidadmaximadeunprocesadorindependientedelfactoreconomicoLasbarrerasfisicasinfranqueablestalescomolavelocidaddelaluz,efectosdetamao,lacapacidad.
3.5 Diseo de software de arquitecturacliente-servidor
Elmodeloarquitectnicoclienteservidoresunmodelodesistemaenelque
dichosistemaorganizacomounconjuntodeserviciosyservidoresasociados,ms
unosclientesqueaccedenyusanlosservicios.Elmodeloarquitectnicoclienteservidoresunmodelodesistemaenelquedichosistemaorganizacomounconjuntodeserviciosyservidoresasociados,msunosclientesqueaccedenyusanlosservicios.aarquitecturaclienteservidoresunmodelodeaplicacindistribuidaenelque
las tareas se reparten entre los proveedores de recursos o
servicios,llamadosservidores,ylosdemandantes,llamadosclientes.Unclienterealizapeticiones
a otro programa, el servidor, quien le da respuesta. Esta
ideatambin se puede aplicar a programas que se ejecutan sobre una
solacomputadora, aunque es ms ventajosa en un
sistemaoperativomultiusuariodistribuidoatravsdeunareddecomputadoras.
Enestaarquitecturalacapacidaddeprocesoestrepartidaentrelosclientesy
los servidores, aunque son ms importantes las ventajas de
tipoorganizativo debidasa la centralizacinde la gestinde la
informacin y la
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
8/12
separacin de responsabilidades, lo que facilita y clarifica el
diseo delsistema.
Laseparacinentreclienteyservidoresunaseparacindetipolgico,dondeel
servidor no se ejecuta necesariamente sobre una sola mquina ni
esnecesariamente un slo programa. Los tipos especficosde servidores
incluyen los servidores web, los servidores de archivo,
losservidores del correo, etc. Mientras que sus propsitos varan de
unosserviciosaotros,laarquitecturabsicaseguirsiendolamisma.
Unadisposicinmuycomnsonlossistemasmulticapaenlosqueelservidorse
descompone en diferentes programas que pueden ser ejecutados
pordiferentes computadoras aumentando as el grado de distribucin
delsistema.
Laarquitecturaclienteservidorsustituyealaarquitecturamonolticaenlaquenohaydistribucin,tantoanivelfsicocomoanivellgico.
Laredclienteservidoresaquellareddecomunicacionesenlaquetodoslosclientesestnconectadosaunservidor,enelquesecentralizanlosdiversosrecursosyaplicacionesconquesecuentayque
losponeadisposicindelosclientescadavezqueestossonsolicitados.Estosignificaque
todas
lasgestionesqueserealizanseconcentranenelservidor,demaneraqueenlse
disponen los requerimientos provenientes de los clientes que
tienenprioridad, los archivos que son de uso pblico y los que son
de usorestringido, los archivos que son de slo lectura y los que,
por el
contrario,puedensermodificados,etc.Estetipoderedpuedeutilizarseconjuntamenteencasodequeseesteutilizandoenunaredmixta.
CaractersticasEn la arquitectura C/S el remitente de una
solicitud es conocidocomocliente.Suscaractersticasson:
Esquieniniciasolicitudesopeticiones,tienenportantounpapelactivoenlacomunicacin(dispositivomaestrooamo).
Esperayrecibelasrespuestasdelservidor.Porlogeneral,puedeconectarseavariosservidoresalavez.
Normalmenteinteractadirectamenteconlosusuariosfinalesmediante
unainterfazgrficadeusuario.Alcontratarunservicioderedes,sedebetenerencuentalavelocidadde
conexin que le otorga al cliente y el tipo de cable que utiliza
, porejemplo:cabledecobrerondaentre1msy50ms.
Alreceptorde
lasolicitudenviadaporelclienteseconocecomoservidor.Suscaractersticasson:
Al iniciarse esperan a que lleguen las solicitudes de los
clientes,desempean entonces un papel pasivo en la
comunicacin(dispositivoesclavo).
Traslarecepcindeunasolicitud,laprocesanyluegoenvanlarespuestaalcliente.
Porlogeneral,aceptanconexionesdesdeungrannmerodeclientes(enciertoscasoselnmeromximodepeticionespuedeestarlimitado).
Noesfrecuentequeinteractendirectamenteconlosusuariosfinales.
3.6 Diseo de software de arquitecturadistribuida
Prcticamente todo los grandes sistemas informticos son en la
actualidad
sistemas distribuidos. Un sistema distribuido es un sistema en
el que el
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
9/12
procesamientodeinformacinsedistribuyesobrevariascomputadorasenvez
de estar confinado en una nica mquina. Obviamente, la ingeniera
de
sistemas distribuidos tienemucho en comn con la ingeniera de
cualquier
otro software, pero existen cuestiones especficas que deben
tenerse en
cuentacuandosediseaestetipodesistemas.
Seidentificanlassiguientesventajasdelusodeunaaproximacindistribuida
paraeldesarrolodesistemas:
1.
Comparticinderecursos.Unsistemadistribuidopermitecompartirrecursoshardwareysoftwarecomodicos,impresoras,ficherosycompiladoresqueseasocianconcomputadorasdeunared.
2.Apertura.Lossistemasdistribuidossonnormalmentesistemasabiertos,loquesignifica
que se disean sobre protocolos estndar que permiten
combinarequipamientoysoftwaredediferentesvendedores.
3. Concurrencia. En un sistema distribuido, varios procesos
pueden operar almismo tiempo sobre diferentes computadoras de la
red. Estos procesospueden (aunque no necesariamente) comunicarse
con otros durante sufuncionamientonormal.
4.Escalabilidad.Almenosenprincipio,lossistemasdistribuidossonescalablesen
tanto que la capacidad del sistema puede incrementarse
aadiendonuevos recursos para cubrir nuevas demandas sobre el
sistema. En laprctica, la red que una las computadoras individuales
del sistema puedelimitar la escalabilidad del sistema. Si se aaden
muchas
computadorasnuevas,entonceslacapacidaddelaredpuederesultarinadecuada.
5.Toleranciaadefectos.Ladisponibilidaddevariascomputadorasyelpotencialparareproducirinformacinsignificaquelossistemasdistribuidospuedensertolerantesaalgunosfallosdefuncionamientodelhardwareydelsofware.Enla
mayora de los sistemas distribuidos, se puede proporcionar un
serviciodegradadocuandoocurrenfallosdefuncionamientounacompletaprdidadeserviciosloocurrecuandoexisteunfallodefuncionamientoenlared.
Parasistemasorganizacionalesagranescala,estasventajassignificanque
los sistemas distribuidos han reemplazado ampliamente a los
sistemas
heredados centralizados que fueron desarrollados en los aos 80 y
90.Sin
embargo, comparados con sistemas que se ejecutan sobre un
nico
procesador o un clster de procesadores, los sistemas
distribuidos tienen
variasdesventajas:
1. Complejidad.Lossistemasdistribuidossonmscomplejosque
lossistemascentralizados.Estohacemsdifcilcomprendersuspropiedadesemergentesy
probar estos sistemas. Por ejemplo, en vez de que el rendimiento
delsistemadependadelavelocidaddeejcucindeunprocesador,dependedelanchodebandayde
lavelocidadde losprocesadoresde la red.Mover losrecursos de una
parte del sistema a otra puede afectar de forma radical
alrendimientodelsistema.
2. Seguridad. Puede accederse al sistema desde varias
computadorasdiferentes, y el trfico en la redpuedeestar sujeto a
escuchas
indeseadas.Estohacemsdifcilelasegurarquelaintegridaddelosdatosenelsistemasemantengayquelosserviciosdelsistemanosedegradenporataquesdedenegacindeservicio.
3. Manejabilidad. Las computadoras en un sistema pueden ser de
diferentestipos y pueden ejecutar versiones diferentes de sistemas
operativos. Los
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
10/12
defectos en una mquina pueden propagarse a otras mquinas
conconsecuenciasinesperadas.Estosignificaqueserequieremsesfuerzoparagestionarymantenerelfuncionamientodelsistema.
4. Impredecibilidad.Como todos losusuariosde laWWWsaben,
lossistemasdistribuidos tienenuna respuesta impredecible. La
respuestadependede lacarga totalenelsistema,desuorganizacinyde
lacargade la red.Comotodos ellos pueden cambiar con mucha rapidez,
el tiempo requerido pararesponder a una peticin de usuario puede
variar drsticamente de unapeticinaotra.
El reto para el diseo es disear el software y hardware para
proporcionar
caractersticas deseables a los sistemas distribuidos y, al mismo
tiempo,
minimizar los problemas inherentes a estos sistemas. Para hacer
eso, se
necesita comprender las ventajas y desventajas de las
diferentes
arquitecturasdesistemasdistribuidos.Aquse tratandos
tiposgenricosde
arquitecrurasdesistemasdistribuidos:
1.Arquitecturaclienteservidor.Enestaaproximacin,elsistemapuedeservistocomounconjuntodeservicioqueseproporcionana
losclientesquehacenuso de dichos servicios. Los servidores y los
clientes se tratan de formadiferenteenestossistemas.
2. Arquitecturas de objetos distribuidos. En este caso, no hay
distincin entreservidores y clientes, y el sistema puede ser visto
como un conjunto deobjetosque interaccionancuya localizacines
irrelevante.Nohaydistincinentreunproveedordeserviciosyelusuariodeestosservicios.
Ambasarquitecturasseusanampliamenteen la industria,pero
ladistribucindelasaplicacionesgeneralmentetienelugardentrodeunanicaorganizacin.Ladistribucinsoportadaes,porlotanto,intraorganizacional.Aqutambinseplanteandos
tiposmsdearquitecturasdistribuidasque sonmsadecuadaspara la
distribucin interorganizacional: arquitectura de sistemas
peertopeer(p2p)yarquitecturasorientadasaservicios.
Los componentes en un sistema distribuido pueden implementarse
endiferentes lenguajes de programacin y pueden ejecutarse en tipos
deprocesadores completamente diferentes. Los modelos de datos,
larepresentacindelainformacinylosprotocolosdecomunicacinpuedensertodos
diferentes. Un sistema distribuido, por lo tanto, requiere software
quepuedagestionarestaspartesdistintas,yasegurarquedichaspartessepuedancomunicar
e intercambiar datos. El trmino middleware se usa par
hacerreferencia a ese software se sita en medio de los diferentes
componentesdistribuidosdelsistemaElmiddlewareesunsoftwaredepropstiogeneralquenormalmentesecompracomo
un componente comercial ms que escribirse especialmente por
losdesarrolladores de la aplicacin. Ejemplos de middleware son
software paragestionar comunicaciones con bases de datos,
administradores
detransacciones,convertidoresdedatosycontroladoresdecomuniacin.
Los sistemas distribuidos se desarrollan normalmente utilizando
unaaproximacin orientada a objetos. Estos sistemas estn formados
por partesindependientes pobremente integradas, cada una de las
cuales puedeninteraccionar directamente con los usuario o con otras
partes del sistema.Algunas partes del sistema pueden tener que
responder a
eventosindependientes.Losobjetossoftwarereflejanestascaractersticasporlotanto,sonabstraccionesnaturalesparaloscomponenetesdesistemasdistribuidos.
3.7 Diseo de software de arquitectura detiempo real
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
11/12
Elsoftwaredetiemporealestamuyacopladoconelmundoexterno,estoes,el
software de tiempo real debe responder al mbito del problema en
untiempo dictado por el mbito del problema. Debido a que el
software detiempo real debeoperar bajo restriccionesde
rendimientomuy rigurosas,
eldiseodelsoftwareestaconducidofrecuentemente, tantopor
laarquitecturadel hardware como por la del software, por las
caractersticas del
sistemaoperativo,porlosrequisitosdelaaplicacinytantoporlosextrasdellenguajedeprogramacincomoprospectosdediseo.Lacomputadoradigitalsehaconvertidoenunamaquinaomnipresenteenalvidadiariadetodosnosotros.Lascomputadorasnospermitenverjuegos,ascomo
contar el tiempo, optimizar el gasto de gasolina de nuestras
ultimasgeneracionesdecochesyprogramaranuestrosaparatos.Todasestasinteraccionesconlascomputadorasseantilesointrusivassonejemplos
de computacin de tiempo real. La computadora esta controlandoalgo
que interactua con la realidad sobre una base de tiempo de hecho,
eltiempoeslaesenciadelainteraccin.
Lossistemasde
tiemporealgeneranalgunaaccinenrespuestaasucesosexternos. Para
realizar esta funcin, ejecutan una adquisicin y control
dedatosaaltavelocidadbajovarias ligadurasde tiempoy
fiabilidad.Debidoaque estas ligaduras son muy rigurosas, los
sistemas de tiempo real
estnfrecuentementededicadosaunanicaaplicacin.Durantemuchos aos, los
principales consumidores de sistemas de tiemporeal
eranmilitares.Sinembargo, hoy la significativa reduccindel
costedelhardwarehahechoposiblepara lamayorade las
compaas,proporcionarsistemas (y productos) de tiempo real para
diversas aplicaciones,
queincluyencontroldeprocesos,automatizacinindustrial,investigacinmedicaycientfica,
grficos de computadoras, comunicaciones locales y de largoalcance,
sistemas aeroespaciales, prueba asistida por computadora y
unvastoabanicodeinstrumentacinindustrial.ConsideracionesSobrelosSistemasComocualquiersistemabasadoencomputadora,unsistemade
tiemporealdebe integrar hardware, software, hombres y elementos de
una base
dedatos,parconseguiradecuadamenteunconjuntoderequisitosfuncionalesyderendimiento.El
problema para los sistemas de tiempo real es realzar la
asignacinimportante como la funcin, pero las decisiones de
asignacin relativas
alrendimientosonfrecuentementedifcilesdehacerconseguridad.Puedeunalgoritmodeprocesamientocumplirvarias
ligadurasde
tiempoodebeconstruirseunhardwareespecialparahacereltrabajo?Puedeunsistemaoperativocumplirnuestrasnecesidadesparaunmanejoeficiente
de interrupciones multitareas y comunicaciones, o
especificado,acoplado con el software propuesto, cumplir los
criterios de rendimiento?Estas y otrasmuchaspreguntas deben ser
respondidaspor el ingeniero desistemasdetiemporeal
-
14/5/2015
unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html
12/12
Pginaprincipal
Suscribirsea:Enviarcomentarios(Atom)
PublicadoporlelsieViteen14:44
+1 Recomendar esto en Google
Introducetucomentario...
Comentarcomo: CuentadeGoogle
Publicar Vistaprevia
4comentarios:ITHJOSEleonel 9demayode2013,6:13
excelentetrabajomuybuenainformacin
Responder
lelsieVite 9demayode2013,6:16
graciascompaeroigualmentegraciasxtuaporteesmuybuentrabajo=)
Responder
humbertohernandezmartinez 9demayode2013,10:41
informacion precisa y exacta con esto nos damos cuenta que la
arquitectura desofwareesdemuchaimportancia
Responder
MagdalyGarca 17demayode2013,22:24
MUYBUENA INFORMACION, ESTANMUYBIENDESCRITOS
CADAUNODELOSTEMAS
Responder
PlantillaWatermark.ConlatecnologadeBlogger.