Unidad 3 Ingeniería Del Software_ Unidad 3 Arquitecturas de Software

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



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,



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



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.



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:



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.



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



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



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



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



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



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.

Unidad 3 Ingeniería Del Software_ Unidad 3 Arquitecturas de Software

Documents

Transcript of Unidad 3 Ingeniería Del Software_ Unidad 3 Arquitecturas de Software