unidad 3_ arquitecturas de software

14/5/2015 UNIDAD3:ARQUITECTURASDESOFTWARE

http://ithluisvite.blogspot.mx/ 1/8

UNIDAD3:ARQUITECTURASDESOFTWARE

MIRCOLES,1DEMAYODE2013

CONTENIDO:3.1DESCOMPOSICINMODULAR3.2PATRONESDEDISEO3.3ARQUITECTURADEDOMINIOESPECFICO3.4DISEODESOFTWAREDEARQUITECTURAMULTIPROCESADOR3.5DISEODESOFTWAREDECLIENTESERVIDOR3.6DISEODESOFTWAREDEARQUITECTURADISTRIBUIDA3.7DISEODESOFTWAREDEARQUITECTURADETIEMPOREAL

UNIDAD3:ARQUITECTURASDESOFTWARE

3.1DESCOMPOSICINMODULAR

Capacidad de empleo de componentes modulares. Si un mtodo de diseo permiteensamblar los componentes de diseo (reusables) existentes en un sistema nuevo,producirunasolucinmodularquenoinventanadayainventado.

Capacidad de comprensin modular. Si un mdulo se puede comprender como unaunidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y decambiar.

Continuidad modular. Si pequeos cambios en los requisitos del sistema provocancambiosen losmdulos individuales,envezdecambiosgeneralizadosenelsistema,seminimizarelimpactodelosefectossecundariosdeloscambios.

Proteccinmodular.Sidentrodeunmduloseproduceunacondicinaberranteysusefectosse limitanaesemdulo,seminimizarel impactode losefectossecundariosinducidosporloserrores.

Finalmente, es importante destacar que un sistema se puede disearmodularmente,incluso aunque su implementacin deba ser monoltica. Existen situaciones (porejemplo,softwareen tiempo real,softwareempotrado)endondenoesadmisiblequelossubprogramasintroduzcansobrecargasdememoriaydevelocidadpormnimosquesean(porejemplo,subrutinas,procedimientos).Entalessituacioneselsoftwarepodrydeberdisearseconmodularidadcomofilosofapredominante.

Elcdigosepuededesarrollarenlnea.Aunqueelcdigofuentedelprogramapuedenotenerunaspectomodularaprimeravista,sehamantenidolafilosofayelprogramaproporcionarlosbeneficiosdeunsistemamodular.El diseo modular propone dividir el sistema en partes diferenciadas y definir susinterfaces.susventajas:claridad,reduccindecostosyreutilizacin.

Lospasosaseguirson:

1.Identificarlosmdulos

2.Describircadamdulo

2013(1)mayo(1)

CONTENIDO:3.1DESCOMPOSICINMODULAR3.2PATRONESD...

ARCHIVODELBLOG

Joseluisvite

Vertodomiperfil

DATOSPERSONALES

0 Ms Siguienteblog Crearunblog Acceder



3.Describirlasrelacionesentremdulos

Una descomposicin modular debe poseer ciertas cualidades mnimas para que sepuedaconsiderarsuficientevalidad.

1.Independenciafuncional

2.Acoplamiento

3.Cohesin

4.Comprensibilidad

5.Adaptabilidad

3.2PATRONESDEDISEO

Unpatrndediseoes: unasolucinestndarparaunproblemacomndeprogramacinunatcnicaparaflexibilizarelcdigohacindolosatisfacerciertoscriterios un proyecto o estructura de implementacin que logra una finalidaddeterminadaunlenguajedeprogramacindealtonivelunamaneramsprcticadedescribirciertosaspectosdelaorganizacindeunprogramaConexionesentrecomponentesdeprogramasLaformadeundiagramadeobjetoodeunmodelodeobjeto.

Ejemplos:

Les vamos a presentar algunos ejemplos de patrones de diseo que ya conocen. Acada diseo de proyecto le sigue el problema que trata de resolver, la solucin queaportaylasposiblesdesventajasasociadas.Undesarrolladordebebuscarunequilibrioentre lasventajasy lasdesventajasa lahoradedecidirquepatrnutilizar.Lonormales,comoobservaramenudoenlacienciacomputacionalyenotroscampos,buscarelbalanceentreflexibilidadyrendimiento.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 adependenciasindeseablesqueimpidenmodificacionesenlaimplementacin.Solucin: esconda algunos componentes, permitiendo slo accesos estilizados alobjeto.Desventajas: la interfaz no puede, eficientemente, facilitar todas las operacionesdeseadas.Elaccesoindirectopuedereducirelrendimiento.

Subclase(herencia):

Problema:abstraccionessimilaresposeenmiembrossimilares(camposymtodos).Estarepeticinestediosa,propensaaerroresyunquebraderodecabezaduranteelmantenimiento.

3.3ARQUITECTURADEDOMINIOESPECFICO

Existendosmodelosdedominioespecfico:



Modelosgenricosquesonabstraccionesdevariossistemasreales.Modelosdereferenciaquesonmodelosabstractosydescribenaunaclasemayordesistemas.

1. Modelogenrico:flujodedatosdeuncompilador2. Modelodereferencia:laarquitecturaOSI

El reto para el diseo es disear el software y hardware para proporcionarcaractersticasdeseablesa lossistemasdistribuidosy,almismotiempo,minimizar losproblemas propios a estos sistemas. Es necesario comprender las ventajas ydesventajasdelasdiferentesarquitecturasdesistemasdistribuidos.Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos:Arquitecturaclienteservidor.Enestecasoelsistemapuedeservistocomounconjuntodeserviciosqueseproporcionanalosclientesquehacenusodedichosservicios.Losservidoresy losclientesse tratande formadiferenteenestossistemas.Arquitecturasdeobjetosdistribuidos.Paraestaarquitecturanohaydistincinentreservidoresyclientes,yelsistemapuedeser visto como un conjunto de objetos que interaccionan cuya localizacin esirrelevante. No hay distincin entre un proveedor de servicios y el usuario de estosservicios.Ambasarquitecturasseusanampliamenteenlaindustria,peroladistribucinde las aplicaciones generalmente tiene lugar dentro de una nica organizacin. Ladistribucin soportadaes, por lo tanto, intraorganizacional. Tambin sepueden tomardostiposmsdearquitecturasdistribuidasquesonmsadecuadasparaladistribucininterorganizacional: arquitectura de sistemas peertopeer (p2p) y arquitecturasorientadasaservicios.Los sistemas peertopeer han sido usados principalmente para sistemas personales,peroestncomenzandoausarseparaaplicacionesdeempresa.Loscomponentesenunsistemadistribuidopuedenimplementarseendiferenteslenguajesdeprogramacinypuedenejecutarseentiposdeprocesadorescompletamentediferentes.Losmodelosdedatos,larepresentacindelainformacinylosprotocolosdecomunicacinpuedenser todosdiferentes.Unsistemadistribuido,por lo tanto, requieresoftwarequepuedagestionarestaspartesdistintas,yasegurarquedichaspartessepuedancomunicareintercambiardatos.Eltrminomiddlewareseusaparahacerreferenciaaesesoftwarese ubica enmedio de los diferentes componentes distribuidos del sistema. Bernstein(Bernstein, 1996) resume los tipos de middleware disponibles para soportarcomputacin distribuida. El middleware es un software de propsito general quenormalmente se compra como un componente comercial ms que escribirseespecialmente por los desarrolladores de la aplicacin. Ejemplos demiddleware sonsoftware para gestionar comunicaciones con bases de datos, administradores detransacciones,convertidoresdedatosycontroladoresdecomunicacin.Lossistemasdistribuidos se desarrollan normalmente utilizando una aproximacin orientada aobjetos.Estossistemasestnformadosporpartesindependientespobrementeintegradas,cadaunadelascualespuedeinteraccionardirectamenteconlosusuariosoconotraspartesdel sistema. Algunas partes del sistema pueden tener que responder a eventosindependientes. Los objetos software reflejan estas caractersticas por lo tanto, sonabstraccionesnaturalesparaloscomponentesdesistemasdistribuidos.

3.4DISEODESOFTWAREDEARQUITECTURAMULTIPROCESADOR

Unsistemamultiprocesoomultitareaesaquelquepermiteejecutarvariosprocesosdeformaconcurrente,la razn es porque actualmente la mayora de las cpus solo pueden ejecutar un proceso cada vez.Lanica formadequeseejecutende formasimultaneavariosprocesoses tener variascpusyaseaenunamaquinaoenvariasenunsistemadistribuido.La ventaja de un sistema multiproceso reside en la operacin llamada cambio decontextoyconsisteenquitaraunprocesodelaCPU,ejecutarotroprocesoyvolvera



colocarelprimerosinqueseenteredenada.El multiproceso no es difcil de entender: ms procesadores significa ms potenciacomputacional.Unconjuntodetareaspuedesercompletadomsrpidamentesihayvariasunidadesdeprocesoejecutndolasenparalelo.

VENTAJASEseconmica

Lascomputadoras paralelasson inherentesescalablespermitiendoactualizarlasparaadecuarsealanecesidad

DESVENTAJASPuedeserlimitantefsica,existenfactoresquelimitanlavelocidadmximade

unprocesadorindependientedelfactoreconmico

Las barreras fsicas infranqueables tales como la velocidad de la luz, efectos detamao,lacapacidad.

3.5DISEOSOFTWAREARQUITECTURACLIENTE/SERVIDOR

ModeloCliente/Servidor:Estemodeloesunprototipodesistemasdistribuidosquemuestracomolosdatosyelprocesamientosedistribuyenalolargodevariosprocesadores.Esunaformadedividirlasresponsabilidadesdeunsistemadeinformacinseparandolainterfazdelusuariodelagestindelainformacin.Elfuncionamientobsicodeestemodeloconsisteenqueunprogramacliente realizapeticionesaunprogramaservidor, yesperahastaqueelservidorderespuesta.Caractersticas de un cliente: En la arquitectura C/S el remitente de una solicitud esconocidocomocliente.Suscaractersticasson:

Esquieniniciasolicitudesopeticiones,tienenportantounpapelactivoenlacomunicacin(dispositivomaestrooamo).Esperayrecibelasrespuestasdelservidor.Porlogeneral,puedeconectaseavariosservidoresalavez.Normalmenteinteractadirectamenteconlosusuariosfinalesmedianteunainterfazgrficadeusuario.

CaractersticasdeunservidorEn lossistemasC/Sel receptorde lasolicitudenviadaporclienteseconocecomoservidor.

Suscaractersticasson:

Aliniciarseesperanaquelleguenlassolicitudesdelosclientes,desempeanentoncesunpapelpasivoenlacomunicacin(dispositivoesclavo).Traslarecepcindeunasolicitud,laprocesanyluegoenvanlarespuestaalcliente.Porlogeneral,aceptanconexionesdesdeungrannmerodeclientes(enciertoscasoselnmeromximodepeticionespuedeestarlimitado)Noesfrecuentequeinteractendirectamenteconlosusuariosfinales.

Ventajas:

Centralizacindelcontrol:Losaccesos,recursosylaintegridaddelosdatossoncontroladosporelservidordeformaqueunprogramaclientedefectuosoonoautorizadonopuedadaarelsistema.Escalabilidad:Sepuedeaumentarlacapacidaddeclientesyservidorespor



separado.Fcilmantenimiento

Desventajas:

Lacongestindeltrfico(amayornmerodeclientes,msproblemasparaelservidor).Elsoftwareyelhardwaredeunservidorsongeneralmentemuydeterminantes.Unhardwareregulardeunordenadorpersonalpuedenopoderserviraciertacantidaddeclientes.Normalmentesenecesitasoftwareyhardwareespecfico,sobretodoenelladodelservidor,parasatisfacereltrabajo.Porsupuesto,estoaumentarelcosto

3.6DISEODESOFTWAREDEARQUITECTURADISTRIBUIDA

Unsistemadistribuidoesunsistemadeinformacinenelcuallasfuncionesserepartenpor reas de trabajo diferentes que trabajan de forma coordinada para asumir losobjetivosquelaorganizacinasignaaesesistemadeinformacin.

Elementosdeunsistemadistribuido:

Enlseintegran.

Laplataformadeproceso.Unavezdiseadoelsistema,eselelementoencargadodeproporcionarlosrecursosfsicosyelsoftwaredebaseparaejecutarlo.Estformadopor losMainframe,PCs,PDAs, telfonos, etc Loselementosde la conectividad.Son los encargados se proporcionar el transporte para comunicar e integrar loselementos de la plataforma de proceso. Son bsicamente las redes y lascomunicaciones. El almacenamiento de datos, formado por los datos en si y losgestoresdonde

Se localizan. Los elementos de software donde se incluyen las aplicaciones, losservicios

Queayudanacrearlasylasinterfacesqueayudanausarlas.Enestecomponenteseintegran las arquitecturas posibles para crearlas: centralizada, Batch, transaccional,cliente/servidorbasadoensistemaoperativo,cliente/servidorbasadaenInternetyaplicacionesWebInternet.Alolargodelaexposicinpondremosespecialcuidadoenpresentarlascaractersticasyposibilidadeslastresltimas.Sistemasdeseguridad.Finalmente, debe realizarse la gestin del sistema como un conjunto integrado ycoordinado a travs de los recursos de direccin y administracin. La gestin delsistema debe permitir la coexistencia de varios centros de gestin diferentes. Partefundamental del sistema de gestin es el cuadro demandos. Hay dos cuadros de



mandosdiferentes:Elcuadrodemandosdeseguimientodelosobjetivosdenegociopensadoparaproporcionarinformacinautomticaalosgestoresdecomolarealidadsemueverespectoa lasprevisionesde losobjetivosdenegocioentiemporeal. Elcuadro de mandos de explotacin desde donde se centraliza y coordina toda laadministracin,supervisinyexplotacindelsistema.

3.7DISEO DE SOFTWARE DE TIEMPO REAL

Las computadoras se utilizan para controlar una amplia variedad de sistemas desdemaquinasdomesticas sencillas hasta plantas enteras de fabricacin. Estas computadoras interactandirectamente condispositivoshardware.El softwarededichos sistemases softwarede tiemporeal embebido que debe reaccionar a eventos generados por el hardware y emitir seales decontrolcomorespuestaaestoseventos.Estembebidoensistemashardwaremquinaydeberesponder,entiemporeal,aeventosdelentornodelsistema.

Lossistemasdetiemporealembebidossondiferentesdeotrostiposdesistemasdesoftware.Sucorrecto funcionamientodependedequeelsistema respondaa loseventosdentrodeuncortointervalodetiempo.Sepuededefinirunsistemadetiemporealcomosigue:

Unsistemadetiemporealesunsistemasoftwarecuyocorrectofuncionamientodependedelosresultados producidos por el mismo y del instante del tiempo en el que se producen estosresultados.Unsistemadetiemporealblando(soft)esunsistemacuyofuncionamientosedegradasilosresultadosnoseproducendeacuerdoconlosrequerimientostemporalesespecificados.Unsistema de tiempo real duro (hard) es un sistema cuyo funcionamiento es incorrecto si losresultadosnoseproducendeacuerdoconlaespecificacintemporal.

Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero enalgunoscasos,nonecesitaunarespuestarpida.Porejemplo,elsistemadebombeodeinsulinaes un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa aintervalosperidicosnoesnecesariorespondermuyrpidamentealoseventosexternos.

Unaformadeverunsistemadetiemporealescomounsistemadeestmulo/respuesta.Dandoundeterminadoestimulodeentrada,elsistemadebeproducir lacorrespondientesalida.Sepuede,por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo una lista de losestmulosrecibidosporelsistema,lasrespuestasasociadasyeltiempoenquedichasrespuestasdebenproducirse.

Losestmulospuedenperteneceradosclases:

Estmulosperidicos.Ocurren a intervalos de tiempopredecibles.Por ejemplo, si el sistemadebeexaminarunsensorcada50milisegundosyrealizarunaaccin(respuesta)dependiendodelvalordeesesensor(estmulo).

Estmulosaperidicos.Ocurrende forma regular.Normalmente sonprovocadosutilizandoelmecanismode interrupcionesde lacomputadora.Unejemplodedichoestmulopodraserunainterrupcinpara indicarqueuna transferenciadeE/Ssehacompletadoyque losdatosestndisponiblesenelbfer.

Losestmulosperidicosenunsistemadetiemporealsongeneradosnormalmenteporsensoresasociadosalsistema.Estosproporcionaninformacinsobreelestadodelentornodelsistema.Lasrespuestas son dirigidas a un conjunto de actuadores que controlan algn equipo como unabomba,que influyeenelentornodelsistema.Losestmulosaperidicospuedengenerarseporactuadoresoporsensores.Amenudoindicanalgunacondicinexcepcionalcomounfalloenelhardware,quedebesermanejadoporel sistema.Estemodelosensorsistemaactuadordeunsistemadetiemporealembebido.

Unsistemadetiemporealtienequeresponderaestmulosqueocurrenendiferentesinstantesdetiempo.Porlotanto,setienequeorganizarsuarquitecturaparaque,tanprontocomoserecibaunestmulo,elcontrolseatransferidoalmanejadoradecuado.Estonoesprcticoenprogramassecuenciales. Por consiguiente, los sistemas de tiempo real se disean como un conjunto de



Pginaprincipal

Suscribirsea:Entradas(Atom)

PublicadoporJoseluisviteen18:44 2comentarios:

procesos concurrentes que cooperan entre s. Con el objetivo de soportar la gestin de estosprocesos, laplataformadeejecucinpara lamayorade lossistemasde tiemporeal incluyeunsistema operativo de tiempo real. Las facilidades que proporciona este sistema operativo sonaccedidas a travs del sistema de soporten tiempo de ejecucin (runtime system) para ellenguajedeprogramacindetiemporealutilizado.

Lageneralidaddeestemodeloestmulorespuestadeunsistemade tiempo realconduceaunmodeloarquitectnicogenricoabstractoenelquehaytrestiposdeprocesos.Paracadatipodesensor,hayunprocesodegestindelsensorlosprocesoscomputacionalescalculanlarespuestarequeridaparaelestmulorecibidoporelsistemalosprocesosdecontroldeactuadorescontrolanel funcionamiento del actuador. Este modelo permite recoger rpidamente los datos desde elsensor (antesdeque lasiguienteentradaestdisponible)ypermitequesuprocesamientoy larespuestaasociadaalactuadorserealicenmstarde.

Laarquitecturagenricapuedeinstanciarseavariasarquitecturasdeaplicacionesdiferentesqueamplan el conjunto de arquitecturas. Las arquitecturas de aplicaciones de tiempo real soninstanciasdelaarquitecturaconducidaporeventosenlacualelestimulo,directaoindirectamente.Provocalageneracindeeventos.

Los lenguajes de programacin desarrollados para sistemas de tiempo real tienen que incluirfacilidadesparaaccederalhardwaredelsistema,ydeberaserposiblepredecir laduracindeoperacionesparticularesrealizadasenestosleguajes.Lossistemasdetiemporealdurostodavaseprogramanalgunasvecesenensambladorparaquepuedancumplirselosestrechosplazosdetiempo (deadline). Los lenguajes a nivel de sistemas como C, que permiten generar cdigoeficientetambinseutilizanengeneral.

La ventaja de utilizar un lenguaje de programacin de sistemas de bajo nivel comoC es quepermite el desarrollo de programas muy eficientes. Sin embargo, estos lenguajes no incluyenconstrucciones para soportar la concurrencia o la gestin de recursos compartidos. Estas seimplementan atreves de llamadas al sistema operativo de tiempo real que no pueden sercomprobadosporelcompilador,de formaque loserroresdeprogramacinsonmsprobables.Los programas son tambin ms a menudo ms difcil de comprender debido a que lascaractersticasdetiemporealnoestnexplicitasenelprograma.

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

REALIZADOPOR:JOSELUISVITEPEREZ

Recomendar esto en Google

PlantillaPictureWindow.Imgenesdeplantillasdesololos.ConlatecnologadeBlogger.

unidad 3_ arquitecturas de software

Documents