14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware
1

Ms Siguienteblog

Crearunblog Acceder

unidad3ingenieradelsoftware
mircoles,8demayode2013

unidad3Arquitecturasdesoftware

Archivodelblog
2013(1)
mayo(1)
unidad3Arquitecturasdesoftware

Arquitecturas de software

Datospersonales
lelsieVite
Seguir

Enlosiniciosdelainformtica,laprogramacinseconsiderabaunarteyse
desarrollabacomotal,debidoaladificultadqueentraabaparalamayorade
las personas, pero con el tiempo se han ido descubriendo y desarrollando
formas y guas generales, con base a las cuales se puedan resolver los
problemas.Aestas,seleshadenominadoArquitecturadeSoftware,porque,
a semejanza de los planos de un edificio o construccin, estas indican la
estructura,funcionamientoeinteraccinentrelaspartesdelsoftware.

12

Vertodomiperfil

En el libro "An introduction to Software Architecture", David Garlan y Mary

Shaw definen que la Arquitectura es un nivel de diseo que hace foco en
aspectos "ms all de los algoritmos y estructuras de datos de la
computacineldiseoyespecificacindelaestructuraglobaldelsistemaes
unnuevotipodeproblema".
Componenteseinteracciones
Componentes
Laarquitecturadesoftwaresecomponepor:
clientesyservidores.
basesdedatos.
filtos.
nivelesensistemasjerrquico.

Interacciones
Entre los componentes de la arquitectura de software existe un conjunto de
interaccionesentrelasquesobresalen:
llamadasaprocedimientos.
comportamientodevariables.
protocolosclienteservidor.
transmicinasncronadeeventos.

3.1 Descomposicin modular

Descomposicinmodular
Capacidad de empleo de componentes modulares. Si un mtodo de diseo
permite ensamblar los componentes de diseo (reusables) existentes en un
sistema nuevo, producir una solucin modular que no inventa nada ya
inventado.

http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

1/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

Capacidad de comprensin modular. Si un mdulo se puede comprender

como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil
deconstruirydecambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema
provocan cambios en los mdulos individuales, en vez de cambios
generalizados en el sistema, se minimizar el impacto de los efectos
secundariosdeloscambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin
aberranteysusefectosselimitanaesemdulo,seminimizarelimpactode
losefectossecundariosinducidosporloserrores.
Finalmente, es importante destacar que un sistema se puede disear
modularmente, incluso aunque su implementacin deba ser monoltica.
Existen situaciones (por ejemplo, software en tiempo real, software
empotrado) en donde no es admisible que los subprogramas introduzcan
sobrecargasdememoriaydevelocidadpormnimosquesean(porejemplo,
subrutinas, procedimientos). En tales situaciones el software podr y deber
disearseconmodularidadcomofilosofapredominante.
El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del
programa puede no tener un aspecto modular a primera vista, se ha
mantenido la filosofa y el programa proporcionar los beneficios de un
sistemamodular.
Eldiseomodularproponedividirelsistemaenpartesdiferenciadasydefinir
susinterfaces.susventajas:claridad,reduccindecostosyreutilizacin.
Lospasosaseguirson:
1.Identificarlosmdulos
2.Describircadamdulo
3.Describirlasrelacionesentremdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para
quesepuedaconsiderarsuficientevalidad.
1.Independenciafuncional
2.Acoplamiento
3.Cohesin
4.Comprensibilidad
5.Adaptabilidad

Eldiseomodularesunametodologadedesarrollodeprogramascomplejos,
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

2/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

que utiliza la filosofa TOPDOWN, conocida tambin como diseo

descendenteorefinamientoporpasossucesivosocomnmenteconocidopor
los programadores como Divide y Vencers puesto que enfrenta un
problemadesdeloabstracto(TOP)hacialoparticular(DOWN).
Estatcnicaconsisteendividirelproblemaenunconjuntodesubproblemas,
y estos a su vez en otros de mayor facilidad de trabajo generando los
MdulosFuncionales.
Ladescomposicinmodularcontribuyealascaractersticasdeseablesparala
programacin estructurada y que permite resolver cada mdulo de forma
independientey,sinosesaberesolveralgunodeellos,puedeasignrseleun
nombre y pasar al desarrollo de otro mdulo y, ms adelante retomar el
mdulo incompleto para darle solucin al obtener mayor conocimiento sobre
dicho proceso, es decir, la solucin del problema no se detiene por falta de
conocimientodealgnprocesoenparticular.

3.2 Patrones de Diseo

Lospatronesdediseosonelesqueletodelassolucionesaproblemascomunesenel
desarrollodesoftware.
En otras palabras, brindan una solucin ya probada y documentada a problemas de
desarrollo de software que estn sujetos a contextos similares. Debemos tener
presente los siguientes elementos de un patrn: su nombre, el problema (cuando
aplicarunpatrn),lasolucin(descripcinabstractadelproblema)ylasconsecuencias
(costosybeneficios).
Grande fue mi sorpresa al averiguar que existen varios patrones de diseo
popularmenteconocidos,loscualesseclasificancomosemuestraacontinuacin:
PatronesCreacionales:Inicializacinyconfiguracindeobjetos.
PatronesEstructurales:Separanlainterfazdelaimplementacin.Seocupan
decmolasclasesyobjetosseagrupan,paraformarestructurasmsgrandes.
PatronesdeComportamiento:Msquedescribirobjetosoclases,describenla
comunicacinentreellos.

Objetivosdelospatrones
Lospatronesdediseopretenden:
Proporcionar catlogos de elementos reusables en el diseo de
sistemassoftware.
Evitar la reiteracin en la bsqueda de soluciones a problemas ya
conocidosysolucionadosanteriormente.
Formalizarunvocabulariocomnentrediseadores.
Estandarizarelmodoenqueserealizaeldiseo.
Facilitarelaprendizajedelasnuevasgeneracionesdediseadores
condensandoconocimientoyaexistente.
Asimismo,nopretenden:
Imponerciertasalternativasdediseofrenteaotras.
Eliminarlacreatividadinherentealprocesodediseo.
Noesobligatorioutilizarlospatrones,soloesaconsejableenelcasodetener
el mismo problema o similar que soluciona el patrn, siempre teniendo en
cuentaqueenuncasoparticularpuedenoseraplicable."Abusaroforzarel
usodelospatronespuedeserunerror".
Categorasdepatrones
Segnlaescalaoniveldeabstraccin:
Patrones de arquitectura: Aquellos que expresan un esquema
organizativoestructuralfundamentalparasistemasdesoftware.
Patronesdediseo:Aquellosqueexpresanesquemasparadefinir
estructuras de diseo (o sus relaciones) con las que construir
sistemasdesoftware.
Dialectos: Patrones de bajo nivel especficos para un lenguaje de
programacinoentornoconcreto.
Adems, tambin es importante resear el concepto de "antipatrn de
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

3/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

diseo", que con forma semejante a la de un patrn, intenta prevenir contra

errorescomunesdediseoenelsoftware.Laideadelosantipatronesesdar
a conocer los problemas que acarrean ciertos diseos muy frecuentes, para
intentar evitar que diferentes sistemas acaben una y otra vez en el mismo
callejnsinsalidaporhabercometidolosmismoserrores.
Ademsdelospatronesyavistosactualmenteexistenotrospatronescomoel
siguiente:
Interaccin:Sonpatronesquenospermiteneldiseodeinterfaces
web.
Estructurasoplantillasdepatrones
Para describir un patrn se usan plantillas ms o menos estandarizadas, de
forma que se expresen uniformemente y puedan constituir efectivamente un
mediodecomunicacinuniformeentrediseadores.Variosautoreseminentes
enestareahanpropuestoplantillasligeramentedistintas,sibienlamayora
definenlosmismosconceptosbsicos.
LaplantillamscomneslautilizadaprecisamenteporelGoFyconstadelos
siguientesapartados:
Nombre del patrn: nombre estndar del patrn por el cual ser
reconocidoenlacomunidad(normalmenteseexpresaneningls).
Clasificacin del patrn: creacional, estructural o de
comportamiento.
Intencin:Quproblemapretenderesolverelpatrn?
Tambin conocido como: Otros nombres de uso comn para el
patrn.
Motivacin:Escenariodeejemploparalaaplicacindelpatrn.
Aplicabilidad:Usoscomunesycriteriosdeaplicabilidaddelpatrn.
Estructura: Diagramas de clases oportunos para describir las
clasesqueintervienenenelpatrn.
Participantes: Enumeracin y descripcin de las entidades
abstractas(ysusroles)queparticipanenelpatrn.
Colaboraciones: Explicacin de las interrelaciones que se dan
entrelosparticipantes.
Consecuencias:Consecuenciaspositivasynegativaseneldiseo
derivadasdelaaplicacindelpatrn.
Implementacin: Tcnicas o comentarios oportunos de cara a la
implementacindelpatrn.
Cdigodeejemplo:Cdigofuenteejemplodeimplementacindel
patrn.
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,
minimizarlosproblemaspropiosaestossistemas.Esnecesariocomprender
las ventajas y desventajas de las diferentes arquitecturas de sistemas
distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de sistemas
distribuidos:Arquitecturaclienteservidor.
Enestecasoelsistemapuedeservistocomounconjuntodeserviciosquese
proporcionanalosclientesquehacenusodedichosservicios.Losservidores
ylosclientessetratandeformadiferenteenestossistemas.

http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

4/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

Arquitecturasdeobjetosdistribuidos.Paraestaarquitecturanohaydistincin
entreservidoresyclientes,yelsistemapuedeservistocomounconjuntode
objetos que interaccionan cuya localizacin es irrelevante. No hay distincin
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) y arquitecturas orientadas a servicios. Los sistemas peer
topeerhansidousadosprincipalmenteparasistemaspersonales,peroestn
comenzandoausarseparaaplicacionesdeempresa.

Sonmodelosdearquitecturaloscualessonespecficosparaalgndominiode
aplicacin.

Dostiposdemodelosdedominioespecficoson:

Modelos Genricos. Estos son abstracciones de un nmero de sistemas

realesyqueencapsulanlascaractersticasprincipalesdeestossistemas.
Modelos de Referencia. Estos son ms abstractos, son modelos idealistas.
Proporcionanunsignificadodeinformacinconrespectoasistemasdeclases
ycomparacindediversasarquitecturas.
MODELOSGENRICOS(1)

UnmodelodeCompiladoresunejemploconocidoatravsdeotrosmodelos
queexistenendominiosdeaplicacionesespecializadas:

http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

5/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

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.
Los modelos de estructuracin de un sistema incluyen modelos repositorios,
losmodelosclienteservidorylosmodelosdemquinaabstracta.

Losmodelosdecontrolincluyencontrolcentralizadoymodelosmanejadores
de eventos.Los modelos de descomposicin modular incluyen los modelos
orientadosaobjetosylosmodelosdeflujodedatos.

http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

6/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

3.4 Diseo de software de arquitectura

multiprocesador
Un sistema multiproceso o multitarea es aquel que permite ejecutar varios
procesosdeformaconcurrente,larazonesporqueactualmentelamayoriade
lascpussolopuedenejecutarunprocesocadavez.Launicaformadequese
ejecutendeformasimultaneavariosprocesosestenervariascpusyaseaen
unamaquinaoenvariasenunsistemadistribuido.
La ventaja de un sistema multiproceso recide en la operacion llamada cambio
decontextoyconsisteenquitaraunprocesodelacpu,ejecutarotroprocesoy
volveracolocarelprimerosinqueseenteredenada.
El multiproceso no es dificil de entender : mas procesadores significa mas
potenciacomputacional.
Un conjunto de tareas puede ser completado mas rapidamente si hay varias
unidadesdeprocesoejecutandolasenparalelo.

VENTAJAS
Eseconomica
Lascomputadorasparalelassoninherentesescalablespermitiendoactualizarlaspara
adecuarsealanecesidad

DESVENTAJAS
Puede ser limitante fisica, existen factores que limitan la velocidad maxima de
unprocesadorindependientedelfactoreconomico
Lasbarrerasfisicasinfranqueablestalescomolavelocidaddelaluz,efectosde
tamao,lacapacidad.

3.5 Diseo de software de arquitectura

cliente-servidor
Elmodeloarquitectnicoclienteservidoresunmodelodesistemaenelque
dichosistemaorganizacomounconjuntodeserviciosyservidoresasociados,ms
unosclientesqueaccedenyusanlosservicios.
Elmodeloarquitectnicoclienteservidoresunmodelodesistemaenelque
dichosistemaorganizacomounconjuntodeserviciosyservidoresasociados,ms
unosclientesqueaccedenyusanlosservicios.
aarquitecturaclienteservidoresunmodelodeaplicacindistribuidaenel
que las tareas se reparten entre los proveedores de recursos o servicios,
llamadosservidores,ylosdemandantes,llamadosclientes.Unclienterealiza
peticiones a otro programa, el servidor, quien le da respuesta. Esta idea
tambin se puede aplicar a programas que se ejecutan sobre una sola
computadora,
aunque
es
ms
ventajosa
en
un
sistema
operativomultiusuariodistribuidoatravsdeunareddecomputadoras.
Enestaarquitecturalacapacidaddeprocesoestrepartidaentrelosclientes
y los servidores, aunque son ms importantes las ventajas de tipo
organizativo debidas a la centralizacin de la gestin de la informacin y la
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

7/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

separacin de responsabilidades, lo que facilita y clarifica el diseo del

sistema.
Laseparacinentreclienteyservidoresunaseparacindetipolgico,donde
el servidor no se ejecuta necesariamente sobre una sola mquina ni es
necesariamente
un
slo
programa.
Los
tipos
especficos
de servidores incluyen los servidores web, los servidores de archivo, los
servidores del correo, etc. Mientras que sus propsitos varan de unos
serviciosaotros,laarquitecturabsicaseguirsiendolamisma.
Unadisposicinmuycomnsonlossistemasmulticapaenlosqueelservidor
se descompone en diferentes programas que pueden ser ejecutados por
diferentes computadoras aumentando as el grado de distribucin del
sistema.
Laarquitecturaclienteservidorsustituyealaarquitecturamonolticaenlaque
nohaydistribucin,tantoanivelfsicocomoanivellgico.
Laredclienteservidoresaquellareddecomunicacionesenlaquetodoslos
clientesestnconectadosaunservidor,enelquesecentralizanlosdiversos
recursos y aplicaciones con que se cuenta y que los pone a disposicin de
los clientes cada vez que estos son solicitados. Esto significa que todas las
gestionesqueserealizanseconcentranenelservidor,demaneraqueenl
se disponen los requerimientos provenientes de los clientes que tienen
prioridad, los archivos que son de uso pblico y los que son de uso
restringido, los archivos que son de slo lectura y los que, por el contrario,
puedensermodificados,etc.Estetipoderedpuedeutilizarseconjuntamente
encasodequeseesteutilizandoenunaredmixta.
Caractersticas
En la arquitectura C/S el remitente de una solicitud es conocido
comocliente.Suscaractersticasson:
Esquieniniciasolicitudesopeticiones,tienenportantounpapelactivoen

lacomunicacin(dispositivomaestrooamo).
Esperayrecibelasrespuestasdelservidor.
Porlogeneral,puedeconectarseavariosservidoresalavez.
Normalmenteinteractadirectamenteconlosusuariosfinalesmediante

unainterfazgrficadeusuario.
Alcontratarunservicioderedes,sedebetenerencuentalavelocidadde

conexin que le otorga al cliente y el tipo de cable que utiliza , por

ejemplo:cabledecobrerondaentre1msy50ms.
Alreceptor de la solicitud enviada por el cliente se conoce como servidor.
Suscaractersticasson:
Al

iniciarse esperan a que lleguen las solicitudes de los clientes,

desempean entonces un papel pasivo en la comunicacin
(dispositivoesclavo).
Traslarecepcindeunasolicitud,laprocesanyluegoenvanlarespuesta
alcliente.
Porlogeneral,aceptanconexionesdesdeungrannmerodeclientes(en
ciertoscasoselnmeromximodepeticionespuedeestarlimitado).
Noesfrecuentequeinteractendirectamenteconlosusuariosfinales.

3.6 Diseo de software de arquitectura

distribuida
Prcticamente todo los grandes sistemas informticos son en la actualidad
sistemas distribuidos. Un sistema distribuido es un sistema en el que el
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

8/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

procesamientodeinformacinsedistribuyesobrevariascomputadorasenvez
de estar confinado en una nica mquina. Obviamente, la ingeniera de
sistemas distribuidos tiene mucho en comn con la ingeniera de cualquier
otro software, pero existen cuestiones especficas que deben tenerse en
cuentacuandosediseaestetipodesistemas.
Seidentificanlassiguientesventajasdelusodeunaaproximacindistribuida
paraeldesarrolodesistemas:
1. Comparticinderecursos.Unsistemadistribuidopermitecompartirrecursos
hardwareysoftwarecomodicos,impresoras,ficherosycompiladoresque
seasocianconcomputadorasdeunared.
2.Apertura.Lossistemasdistribuidossonnormalmentesistemasabiertos,loque
significa que se disean sobre protocolos estndar que permiten combinar
equipamientoysoftwaredediferentesvendedores.
3. Concurrencia. En un sistema distribuido, varios procesos pueden operar al
mismo tiempo sobre diferentes computadoras de la red. Estos procesos
pueden (aunque no necesariamente) comunicarse con otros durante su
funcionamientonormal.
4.Escalabilidad.Almenosenprincipio,lossistemasdistribuidossonescalables
en tanto que la capacidad del sistema puede incrementarse aadiendo
nuevos recursos para cubrir nuevas demandas sobre el sistema. En la
prctica, la red que una las computadoras individuales del sistema puede
limitar la escalabilidad del sistema. Si se aaden muchas computadoras
nuevas,entonceslacapacidaddelaredpuederesultarinadecuada.
5.Toleranciaadefectos.Ladisponibilidaddevariascomputadorasyelpotencial
parareproducirinformacinsignificaquelossistemasdistribuidospuedenser
tolerantesaalgunosfallosdefuncionamientodelhardwareydelsofware.En
la mayora de los sistemas distribuidos, se puede proporcionar un servicio
degradadocuandoocurrenfallosdefuncionamientounacompletaprdidade
serviciosloocurrecuandoexisteunfallodefuncionamientoenlared.

Para sistemas organizacionales a gran escala, estas ventajas significan que

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.Lossistemasdistribuidossonmscomplejosquelossistemas
centralizados.Estohacemsdifcilcomprendersuspropiedadesemergentes
y probar estos sistemas. Por ejemplo, en vez de que el rendimiento del
sistemadependadelavelocidaddeejcucindeunprocesador,dependedel
ancho de banda y de la velocidad de los procesadores de la red. Mover los
recursos de una parte del sistema a otra puede afectar de forma radical al
rendimientodelsistema.
2. Seguridad. Puede accederse al sistema desde varias computadoras
diferentes, y el trfico en la red puede estar sujeto a escuchas indeseadas.
Estohacemsdifcilelasegurarquelaintegridaddelosdatosenelsistema
semantengayquelosserviciosdelsistemanosedegradenporataquesde
denegacindeservicio.
3. Manejabilidad. Las computadoras en un sistema pueden ser de diferentes
tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

9/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

defectos en una mquina pueden propagarse a otras mquinas con

consecuenciasinesperadas.Estosignificaqueserequieremsesfuerzopara
gestionarymantenerelfuncionamientodelsistema.
4. Impredecibilidad. Como todos los usuarios de la WWW saben, los sistemas
distribuidos tienen una respuesta impredecible. La respuesta depende de la
carga total en el sistema, de su organizacin y de la carga de la red. Como
todos ellos pueden cambiar con mucha rapidez, el tiempo requerido para
responder a una peticin de usuario puede variar drsticamente de una
peticinaotra.

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
arquitecturas de sistemas distribuidos. Aqu se tratan dos tipos genricos de
arquitecrurasdesistemasdistribuidos:

1.Arquitecturaclienteservidor.Enestaaproximacin,elsistemapuedeservisto
como un conjunto de servicio que se proporcionan a los clientes que hacen
uso de dichos servicios. Los servidores y los clientes se tratan de forma
diferenteenestossistemas.
2. Arquitecturas de objetos distribuidos. En este caso, no hay distincin entre
servidores y clientes, y el sistema puede ser visto como un conjunto de
objetos que interaccionan cuya localizacin es irrelevante. No hay distincin
entreunproveedordeserviciosyelusuariodeestosservicios.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin
delasaplicacionesgeneralmentetienelugardentrodeunanicaorganizacin.
Ladistribucinsoportadaes,porlotanto,intraorganizacional.Aqutambinse
plantean dos tipos ms de arquitecturas distribuidas que son ms adecuadas
para la distribucin interorganizacional: arquitectura de sistemas peertopeer
(p2p)yarquitecturasorientadasaservicios.
Los componentes en un sistema distribuido pueden implementarse en
diferentes lenguajes de programacin y pueden ejecutarse en tipos de
procesadores completamente diferentes. Los modelos de datos, la
representacindelainformacinylosprotocolosdecomunicacinpuedenser
todos diferentes. Un sistema distribuido, por lo tanto, requiere software que
puedagestionarestaspartesdistintas,yasegurarquedichaspartessepuedan
comunicar e intercambiar datos. El trmino middleware se usa par hacer
referencia a ese software se sita en medio de los diferentes componentes
distribuidosdelsistema
Elmiddlewareesunsoftwaredepropstiogeneralquenormalmentesecompra
como un componente comercial ms que escribirse especialmente por los
desarrolladores de la aplicacin. Ejemplos de middleware son software para
gestionar comunicaciones con bases de datos, administradores de
transacciones,convertidoresdedatosycontroladoresdecomuniacin.
Los sistemas distribuidos se desarrollan normalmente utilizando una
aproximacin orientada a objetos. Estos sistemas estn formados por partes
independientes pobremente integradas, cada una de las cuales pueden
interaccionar directamente con los usuario o con otras partes del sistema.
Algunas partes del sistema pueden tener que responder a eventos
independientes.Losobjetossoftwarereflejanestascaractersticasporlotanto,
sonabstraccionesnaturalesparaloscomponenetesdesistemasdistribuidos.

3.7 Diseo de software de arquitectura de

tiempo real
http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

10/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

Elsoftwaredetiemporealestamuyacopladoconelmundoexterno,estoes,
el software de tiempo real debe responder al mbito del problema en un
tiempo dictado por el mbito del problema. Debido a que el software de
tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el
diseodelsoftwareestaconducidofrecuentemente,tantoporlaarquitectura
del hardware como por la del software, por las caractersticas del sistema
operativo,porlosrequisitosdelaaplicacinytantoporlosextrasdellenguaje
deprogramacincomoprospectosdediseo.
Lacomputadoradigitalsehaconvertidoenunamaquinaomnipresenteenal
vidadiariadetodosnosotros.Lascomputadorasnospermitenverjuegos,as
como contar el tiempo, optimizar el gasto de gasolina de nuestras ultimas
generacionesdecochesyprogramaranuestrosaparatos.
Todasestasinteraccionesconlascomputadorasseantilesointrusivasson
ejemplos de computacin de tiempo real. La computadora esta controlando
algo que interactua con la realidad sobre una base de tiempo de hecho, el
tiempoeslaesenciadelainteraccin.
Los sistemas de tiempo real generan alguna accin en respuesta a sucesos
externos. Para realizar esta funcin, ejecutan una adquisicin y control de
datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a
que estas ligaduras son muy rigurosas, los sistemas de tiempo real estn
frecuentementededicadosaunanicaaplicacin.
Durante muchos aos, los principales consumidores de sistemas de tiempo
real eran militares. Sin embargo, hoy la significativa reduccin del coste del
hardware ha hecho posible para la mayora de las compaas, proporcionar
sistemas (y productos) de tiempo real para diversas aplicaciones, que
incluyencontroldeprocesos,automatizacinindustrial,investigacinmedicay
cientfica, grficos de computadoras, comunicaciones locales y de largo
alcance, sistemas aeroespaciales, prueba asistida por computadora y un
vastoabanicodeinstrumentacinindustrial.
ConsideracionesSobrelosSistemas
Como cualquier sistema basado en computadora, un sistema de tiempo real
debe integrar hardware, software, hombres y elementos de una base de
datos,parconseguiradecuadamenteunconjuntoderequisitosfuncionalesy
derendimiento.
El problema para los sistemas de tiempo real es realzar la asignacin
importante como la funcin, pero las decisiones de asignacin relativas al
rendimientosonfrecuentementedifcilesdehacerconseguridad.
Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o
debeconstruirseunhardwareespecialparahacereltrabajo?
Puede un sistema operativo cumplir nuestras necesidades para un manejo
eficiente de interrupciones multitareas y comunicaciones, o especificado,
acoplado con el software propuesto, cumplir los criterios de rendimiento?
Estas y otras muchas preguntas deben ser respondidas por el ingeniero de
sistemasdetiemporeal

http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

11/12

14/5/2015

unidad3ingenieradelsoftware:unidad3Arquitecturasdesoftware

PublicadoporlelsieViteen14:44
+1 Recomendar esto en Google

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 de
sofwareesdemuchaimportancia
Responder

MagdalyGarca 17demayode2013,22:24
MUY BUENA INFORMACION, ESTAN MUY BIEN DESCRITOS CADA UNO DE
LOSTEMAS
Responder

Introducetucomentario...

Comentarcomo:

Publicar

CuentadeGoogle

Vistaprevia

Pginaprincipal
Suscribirsea:Enviarcomentarios(Atom)

PlantillaWatermark.ConlatecnologadeBlogger.

http://ithuejutlalvf.blogspot.mx/2013/05/unidad3arquitecturasdesoftware.html

12/12