14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE
0

Ms Siguienteblog

Crearunblog Acceder

UNIDAD3:ARQUITECTURASDESOFTWARE
MIRCOLES,1DEMAYODE2013

ARCHIVODELBLOG

2013(1)
mayo(1)

CONTENIDO:
3.1DESCOMPOSICINMODULAR
3.2PATRONESDEDISEO
3.3ARQUITECTURADEDOMINIOESPECFICO
3.4DISEODESOFTWAREDEARQUITECTURAMULTIPROCESADOR
3.5DISEODESOFTWAREDECLIENTESERVIDOR
3.6DISEODESOFTWAREDEARQUITECTURADISTRIBUIDA
3.7DISEODESOFTWAREDEARQUITECTURADETIEMPOREAL

CONTENIDO:3.1DESCOMPOSICI
NMODULAR3.2PATRONES
D...

DATOSPERSONALES

Joseluisvite
Vertodomiperfil

UNIDAD3:ARQUITECTURASDESOFTWARE
3.1DESCOMPOSICINMODULAR
Capacidad de empleo de componentes modulares. Si un mtodo de diseo permite
ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo,
producirunasolucinmodularquenoinventanadayainventado.
Capacidad de comprensin modular. Si un mdulo se puede comprender como una
unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de
cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan
cambiosenlosmdulosindividuales,envezdecambiosgeneralizadosenelsistema,
seminimizarelimpactodelosefectossecundariosdeloscambios.
Proteccinmodular.Sidentrodeunmduloseproduceunacondicinaberranteysus
efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios
inducidosporloserrores.
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
lossubprogramasintroduzcansobrecargasdememoriaydevelocidadpormnimosque
sean(porejemplo,subrutinas,procedimientos).Entalessituacioneselsoftwarepodry
deberdisearseconmodularidadcomofilosofapredominante.
Elcdigosepuededesarrollarenlnea.Aunqueelcdigofuentedelprogramapuede
notenerunaspectomodularaprimeravista,sehamantenidolafilosofayelprograma
proporcionarlosbeneficiosdeunsistemamodular.
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus
interfaces.susventajas:claridad,reduccindecostosyreutilizacin.
Lospasosaseguirson:
1.Identificarlosmdulos
2.Describircadamdulo
http://ithluisvite.blogspot.mx/

1/8

14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE

3.Describirlasrelacionesentremdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se
puedaconsiderarsuficientevalidad.
1.Independenciafuncional
2.Acoplamiento
3.Cohesin
4.Comprensibilidad
5.Adaptabilidad
3.2PATRONESDEDISEO
Unpatrndediseoes: unasolucinestndarparaunproblemacomnde
programacin
unatcnicaparaflexibilizarelcdigohacindolosatisfacerciertoscriterios

un proyecto o estructura de implementacin que logra una finalidad

determinada

unlenguajedeprogramacindealtonivel

unamaneramsprcticadedescribirciertosaspectosdelaorganizacinde
unprograma

Conexionesentrecomponentesdeprogramas

Laformadeundiagramadeobjetoodeunmodelodeobjeto.
Ejemplos:
Les vamos a presentar algunos ejemplos de patrones de diseo que ya conocen. A
cada diseo de proyecto le sigue el problema que trata de resolver, la solucin que
aportaylasposiblesdesventajasasociadas.Undesarrolladordebebuscarunequilibrio
entrelasventajasylasdesventajasalahoradedecidirquepatrnutilizar.Lonormal
es,comoobservaramenudoenlacienciacomputacionalyenotroscampos,buscarel
balanceentreflexibilidadyrendimiento.

Encapsulacin(ocultacindedatos):
Problema: los campos externos pueden ser manipulados directamente a partir del
cdigo externo, lo que conduce a violaciones del invariante de representacin o a
dependenciasindeseablesqueimpidenmodificacionesenlaimplementacin.
Solucin: esconda algunos componentes, permitiendo slo accesos estilizados al
objeto.
Desventajas: la interfaz no puede, eficientemente, facilitar todas las operaciones
deseadas.Elaccesoindirectopuedereducirelrendimiento.
Subclase(herencia):
Problema:abstraccionessimilaresposeenmiembrossimilares(camposymtodos).
Estarepeticinestediosa,propensaaerroresyunquebraderodecabezaduranteel
mantenimiento.
3.3ARQUITECTURADEDOMINIOESPECFICO
Existendosmodelosdedominioespecfico:
http://ithluisvite.blogspot.mx/

2/8

14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE

Modelosgenricosquesonabstraccionesdevariossistemasreales.

Modelosdereferenciaquesonmodelosabstractosydescribenaunaclase
mayordesistemas.

1. Modelogenrico:flujodedatosdeuncompilador
2. Modelodereferencia:laarquitecturaOSI

El reto para el diseo es disear el software y hardware para proporcionar

caractersticasdeseablesalossistemasdistribuidosy,almismotiempo,minimizarlos
problemas propios a estos sistemas. Es necesario comprender las ventajas y
desventajasdelasdiferentesarquitecturasdesistemasdistribuidos.
Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos:
Arquitecturaclienteservidor.Enestecasoelsistemapuedeservistocomounconjunto
deserviciosqueseproporcionanalosclientesquehacenusodedichosservicios.Los
servidores y los clientes se tratan de forma diferente en estos sistemas. Arquitecturas
deobjetosdistribuidos.
Paraestaarquitecturanohaydistincinentreservidoresyclientes,yelsistemapuede
ser visto como un conjunto de objetos que interaccionan cuya localizacin es
irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos
servicios.Ambasarquitecturasseusanampliamenteenlaindustria,peroladistribucin
de las aplicaciones generalmente tiene lugar dentro de una nica organizacin. La
distribucin soportada es, por lo tanto, intraorganizacional. Tambin se pueden tomar
dostiposmsdearquitecturasdistribuidasquesonmsadecuadasparaladistribucin
interorganizacional: arquitectura de sistemas peertopeer (p2p) y arquitecturas
orientadasaservicios.
Los sistemas peertopeer han sido usados principalmente para sistemas personales,
peroestncomenzandoausarseparaaplicacionesdeempresa.Loscomponentesen
unsistemadistribuidopuedenimplementarseendiferenteslenguajesdeprogramacin
ypuedenejecutarseentiposdeprocesadorescompletamentediferentes.Losmodelos
dedatos,larepresentacindelainformacinylosprotocolosdecomunicacinpueden
sertodosdiferentes.Unsistemadistribuido,porlotanto,requieresoftwarequepueda
gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e
intercambiardatos.Eltrminomiddlewareseusaparahacerreferenciaaesesoftware
se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein
(Bernstein, 1996) resume los tipos de middleware disponibles para soportar
computacin distribuida. El middleware es un software de propsito general que
normalmente se compra 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, convertidores de datos y controladores de comunicacin. Los sistemas
distribuidos se desarrollan normalmente utilizando una aproximacin orientada a
objetos.
Estossistemasestnformadosporpartesindependientespobrementeintegradas,cada
unadelascualespuedeinteraccionardirectamenteconlosusuariosoconotraspartes
del sistema. Algunas partes del sistema pueden tener que responder a eventos
independientes. Los objetos software reflejan estas caractersticas por lo tanto, son
abstraccionesnaturalesparaloscomponentesdesistemasdistribuidos.
3.4DISEODESOFTWAREDEARQUITECTURAMULTIPROCESADOR
Unsistemamultiprocesoomultitareaesaquelquepermiteejecutarvariosprocesosdeformaconcurrente,
la razn es porque actualmente la mayora de las cpus solo pueden ejecutar un proceso cada vez.
La nica forma de que se ejecuten de forma simultanea varios procesos es tener varias cpus ya sea en
unamaquinaoenvariasenunsistemadistribuido.

La ventaja de un sistema multiproceso reside en la operacin llamada cambio de

contextoyconsisteenquitaraunprocesodelaCPU,ejecutarotroprocesoyvolvera
http://ithluisvite.blogspot.mx/

3/8

14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE

colocarelprimerosinqueseenteredenada.
El multiproceso no es difcil de entender: ms procesadores significa ms potencia
computacional.
Unconjuntodetareaspuedesercompletadomsrpidamentesihayvariasunidades
deprocesoejecutndolasenparalelo.
VENTAJAS
Eseconmica
Las computadoras paralelas son inherentes escalables permitiendo actualizarlas para
adecuarsealanecesidad
DESVENTAJAS
Puedeserlimitantefsica,existenfactoresquelimitanlavelocidadmximade
unprocesadorindependientedelfactoreconmico
Las barreras fsicas infranqueables tales como la velocidad de la luz, efectos de
tamao,lacapacidad.

3.5DISEOSOFTWAREARQUITECTURACLIENTE/SERVIDOR
ModeloCliente/Servidor:
Estemodeloesunprototipodesistemasdistribuidosquemuestracomolosdatosyel
procesamientosedistribuyenalolargodevariosprocesadores.Esunaformadedividir
lasresponsabilidadesdeunsistemadeinformacinseparandolainterfazdelusuariode
lagestindelainformacin.Elfuncionamientobsicodeestemodeloconsisteenque
un programa cliente realiza peticiones a un programa servidor, y espera hasta que el
servidorderespuesta.
Caractersticas de un cliente: En la arquitectura C/S el remitente de una solicitud es
conocidocomocliente.
Suscaractersticasson:
Esquieniniciasolicitudesopeticiones,tienenportantounpapelactivoenla
comunicacin(dispositivomaestrooamo).
Esperayrecibelasrespuestasdelservidor.
Porlogeneral,puedeconectaseavariosservidoresalavez.

Normalmenteinteractadirectamenteconlosusuariosfinalesmedianteuna
interfazgrficadeusuario.
Caractersticas de un servidor En los sistemas C/S el receptor de la solicitud enviada
porclienteseconocecomoservidor.
Suscaractersticasson:
Aliniciarseesperanaquelleguenlassolicitudesdelosclientes,desempean
entoncesunpapelpasivoenlacomunicacin(dispositivoesclavo).
Traslarecepcindeunasolicitud,laprocesanyluegoenvanlarespuestaal
cliente.

Porlogeneral,aceptanconexionesdesdeungrannmerodeclientes(en
ciertoscasoselnmeromximodepeticionespuedeestarlimitado)
Noesfrecuentequeinteractendirectamenteconlosusuariosfinales.

Ventajas:
Centralizacindelcontrol:Losaccesos,recursosylaintegridaddelosdatos
soncontroladosporelservidordeformaqueunprogramaclientedefectuoso
onoautorizadonopuedadaarelsistema.
Escalabilidad:Sepuedeaumentarlacapacidaddeclientesyservidorespor
http://ithluisvite.blogspot.mx/

4/8

14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE

separado.
Fcilmantenimiento
Desventajas:
Lacongestindeltrfico(amayornmerodeclientes,msproblemaspara
elservidor).

Elsoftwareyelhardwaredeunservidorsongeneralmentemuy
determinantes.Unhardwareregulardeunordenadorpersonalpuedeno
poderserviraciertacantidaddeclientes.Normalmentesenecesitasoftware
yhardwareespecfico,sobretodoenelladodelservidor,parasatisfacerel
trabajo.Porsupuesto,estoaumentarelcosto

3.6DISEODESOFTWAREDEARQUITECTURADISTRIBUIDA

Unsistemadistribuidoesunsistemadeinformacinenelcuallasfuncionessereparten
por reas de trabajo diferentes que trabajan de forma coordinada para asumir los
objetivosquelaorganizacinasignaaesesistemadeinformacin.
Elementosdeunsistemadistribuido:

Enlseintegran.
Laplataformadeproceso.Unavezdiseadoelsistema,eselelementoencargado
deproporcionarlosrecursosfsicosyelsoftwaredebaseparaejecutarlo.Estformado
por los Mainframe, PCs, PDAs, telfonos, etc Los elementos de la conectividad.
Son los encargados se proporcionar el transporte para comunicar e integrar los
elementos de la plataforma de proceso. Son bsicamente las redes y las
comunicaciones. El almacenamiento de datos, formado por los datos en si y los
gestoresdonde
Se localizan. Los elementos de software donde se incluyen las aplicaciones, los
servicios
Queayudanacrearlasylasinterfacesqueayudanausarlas.Enestecomponentese
integran las arquitecturas posibles para crearlas: centralizada, Batch, transaccional,
cliente/servidorbasadoensistemaoperativo,cliente/servidorbasadaenInternety
aplicacionesWebInternet.Alolargodelaexposicinpondremosespecialcuidadoen
presentarlascaractersticasyposibilidadeslastresltimas.Sistemasdeseguridad.
Finalmente, debe realizarse la gestin del sistema como un conjunto integrado y
coordinado a travs de los recursos de direccin y administracin. La gestin del
sistema debe permitir la coexistencia de varios centros de gestin diferentes. Parte
fundamental del sistema de gestin es el cuadro de mandos. Hay dos cuadros de
http://ithluisvite.blogspot.mx/

5/8

14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE

mandosdiferentes:Elcuadrodemandosdeseguimientodelosobjetivosdenegocio
pensadoparaproporcionarinformacinautomticaalosgestoresdecomolarealidad
semueverespectoalasprevisionesdelosobjetivosdenegocioentiemporeal.El
cuadro de mandos de explotacin desde donde se centraliza y coordina toda la
administracin,supervisinyexplotacindelsistema.

3.7DISEO DE SOFTWARE DE TIEMPO REAL

Las computadoras se utilizan para controlar una amplia variedad de sistemas desde maquinas
domesticas sencillas hasta plantas enteras de fabricacin. Estas computadoras interactan
directamente con dispositivos hardware. El software de dichos sistemas es software de tiempo
real embebido que debe reaccionar a eventos generados por el hardware y emitir seales de
controlcomorespuestaaestoseventos.Estembebidoensistemashardwaremquinaydebe
responder,entiemporeal,aeventosdelentornodelsistema.
Lossistemasdetiemporealembebidossondiferentesdeotrostiposdesistemasdesoftware.Su
correcto funcionamiento depende de que el sistema responda a los eventos dentro de un corto
intervalodetiempo.Sepuededefinirunsistemadetiemporealcomosigue:
Unsistemadetiemporealesunsistemasoftwarecuyocorrectofuncionamientodependedelos
resultados producidos por el mismo y del instante del tiempo en el que se producen estos
resultados.Unsistemadetiemporealblando(soft)esunsistemacuyofuncionamientosedegrada
silosresultadosnoseproducendeacuerdoconlosrequerimientostemporalesespecificados.Un
sistema de tiempo real duro (hard) es un sistema cuyo funcionamiento es incorrecto si los
resultadosnoseproducendeacuerdoconlaespecificacintemporal.
Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero en
algunoscasos,nonecesitaunarespuestarpida.Porejemplo,elsistemadebombeodeinsulina
es un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a
intervalosperidicosnoesnecesariorespondermuyrpidamentealoseventosexternos.
Unaformadeverunsistemadetiemporealescomounsistemadeestmulo/respuesta.Dandoun
determinadoestimulodeentrada,elsistemadebeproducirlacorrespondientesalida.Sepuede,
por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo una lista de los
estmulosrecibidosporelsistema,lasrespuestasasociadasyeltiempoenquedichasrespuestas
debenproducirse.
Losestmulospuedenperteneceradosclases:
Estmulos peridicos. Ocurren a intervalos de tiempo predecibles. Por ejemplo, si el sistema
debeexaminarunsensorcada50milisegundosyrealizarunaaccin(respuesta)dependiendodel
valordeesesensor(estmulo).
Estmulos aperidicos. Ocurren de forma regular. Normalmente son provocados utilizando el
mecanismo de interrupciones de la computadora. Un ejemplo de dicho estmulo podra ser una
interrupcin para indicar que una transferencia de E/S se ha completado y que los datos estn
disponiblesenelbfer.

Losestmulosperidicosenunsistemadetiemporealsongeneradosnormalmenteporsensores
asociadosalsistema.Estosproporcionaninformacinsobreelestadodelentornodelsistema.Las
respuestas son dirigidas a un conjunto de actuadores que controlan algn equipo como una
bomba, que influye en el entorno del sistema. Los estmulos aperidicos pueden generarse por
actuadoresoporsensores.Amenudoindicanalgunacondicinexcepcionalcomounfalloenel
hardware, que debe ser manejado por el sistema. Este modelo sensorsistema actuador de un
sistemadetiemporealembebido.
Unsistemadetiemporealtienequeresponderaestmulosqueocurrenendiferentesinstantesde
tiempo.Porlotanto,setienequeorganizarsuarquitecturaparaque,tanprontocomosereciba
unestmulo,elcontrolseatransferidoalmanejadoradecuado.Estonoesprcticoenprogramas
secuenciales. Por consiguiente, los sistemas de tiempo real se disean como un conjunto de
http://ithluisvite.blogspot.mx/

6/8

14/5/2015

UNIDAD3:ARQUITECTURASDESOFTWARE

procesos concurrentes que cooperan entre s. Con el objetivo de soportar la gestin de estos
procesos, la plataforma de ejecucin para la mayora de los sistemas de tiempo real incluye un
sistema operativo de tiempo real. Las facilidades que proporciona este sistema operativo son
accedidas a travs del sistema de soporten tiempo de ejecucin (runtime system) para el
lenguajedeprogramacindetiemporealutilizado.
La generalidad de este modelo estmulorespuesta de un sistema de tiempo real conduce a un
modeloarquitectnicogenricoabstractoenelquehaytrestiposdeprocesos.Paracadatipode
sensor,hayunprocesodegestindelsensorlosprocesoscomputacionalescalculanlarespuesta
requeridaparaelestmulorecibidoporelsistemalosprocesosdecontroldeactuadorescontrolan
el funcionamiento del actuador. Este modelo permite recoger rpidamente los datos desde el
sensor (antes de que la siguiente entrada est disponible) y permite que su procesamiento y la
respuestaasociadaalactuadorserealicenmstarde.
Laarquitecturagenricapuedeinstanciarseavariasarquitecturasdeaplicacionesdiferentesque
amplan el conjunto de arquitecturas. Las arquitecturas de aplicaciones de tiempo real son
instanciasdelaarquitecturaconducidaporeventosenlacualelestimulo,directaoindirectamente.
Provocalageneracindeeventos.
Los lenguajes de programacin desarrollados para sistemas de tiempo real tienen que incluir
facilidades para acceder al hardware del sistema, y debera ser posible predecir la duracin de
operacionesparticularesrealizadasenestosleguajes.Lossistemasdetiemporealdurostodava
seprogramanalgunasvecesenensambladorparaquepuedancumplirselosestrechosplazosde
tiempo (deadline). Los lenguajes a nivel de sistemas como C, que permiten generar cdigo
eficientetambinseutilizanengeneral.
La ventaja de utilizar un lenguaje de programacin de sistemas de bajo nivel como C es que
permite el desarrollo de programas muy eficientes. Sin embargo, estos lenguajes no incluyen
construcciones para soportar la concurrencia o la gestin de recursos compartidos. Estas se
implementan atreves de llamadas al sistema operativo de tiempo real que no pueden ser
comprobados por el compilador, de forma que los errores de programacin son ms probables.
Los programas son tambin ms a menudo ms difcil de comprender debido a que las
caractersticasdetiemporealnoestnexplicitasenelprograma.

ESPERO QUE LA INFORMACION QUE AQU SE PRESENTA LES SEA DE GRAN

UTILIDADPARASUSINVESTIGACIONES
REALIZADOPOR:JOSELUISVITEPEREZ

PublicadoporJoseluisviteen18:44 2comentarios:
Recomendar esto en Google

Pginaprincipal
Suscribirsea:Entradas(Atom)

PlantillaPictureWindow.Imgenesdeplantillasdesololos.ConlatecnologadeBlogger.

http://ithluisvite.blogspot.mx/

7/8

14/5/2015

http://ithluisvite.blogspot.mx/

UNIDAD3:ARQUITECTURASDESOFTWARE

8/8