Reporte Técnico RT-ID-/ de Diciembre 2009 Revisado

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Reporte Técnico RT-ID-/009. 4 de Diciembre 2009 Revisado"

Transcripción

1 Reporte Técnico RT-ID-/009 Erlang Está Listo para Sistemas de Alta Integridad? Nora Sabina María Blet Departamento de Sistemas e Informática Escuela de Ingeniería Electrónica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Disciplina: Informática, Lenguajes de Programación 4 de Diciembre 2009 Revisado Secretaría de Ciencia y Técnica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Av. Pellegrini Rosario Argentina

2 Este documento es publicado por la FCEIA para su consulta externa. El mismo se publica como Reporte de Investigación para divulgación de las tareas científicas que se desarrollan en la FCEIA, Universidad Nacional de Rosario. Los autores conservan los derechos de autoría y copia de la totalidad de su trabajo aquí publicado. Luego de su posterior eventual publicación externa a la FCEIA, los requerimientos deberán dirigirse a los autores respectivos. El contenido de este reporte refleja la visión de los autores, quienes se responsabilizan por los datos presentados, los cuales no necesariamente reflejan la visión de la SeCyT-FCEIA. Tanto la SeCyT-FCEIA como los autores del presente reporte no se responsabilizan por el uso que pudiera hacerse de la información y/o metodologías publicadas. Cualquier sugerencia dirigirla a: 2

3 Erlang Está Listo para Sistemas de Alta Integridad? Nora Sabina María Blet * Departamento de Sistemas e Informática Escuela de Ingeniería Electrónica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Resumen. Este informe resume una evaluación del lenguaje de programación funcional Erlang, en comparación con los estrictos requisitos impuestos a lenguajes de programación para aplicaciones relacionadas con la fiabilidad. Para este propósito se escogen veintitrés criterios, disponibles en la literatura, que examinan el uso de Java en el desarrollo de sistemas de alta integridad. En base a lecciones aprendidas en proyectos industriales Erlang a gran escala, se discuten algunas posibles mejoras. Palabras Claves: Erlang, Programación Concurrente, Programación Distribuida, Tolerancia a Fallos, Evaluación de Lenguajes de Programación, Sistemas Totalmente Fiables. Is Erlang Ready for Use in Safety-Critical Systems? Abstract. This report summarises an assessment of the Erlang programming language against the strict requirements imposed on programming languages for safety related applications. For this purpose twenty-three criteria, available in the literature, for investigating the use of Java in the development of high integrity systems have been chosen. Based on some lessons learned on industrial projects possible further enhancements are discussed. Keywords: Erlang, Concurrent Programming, Distributed Programming, Fault-Tolerance, Assessment of Programming Languages, Safety-Critical Systems. * 3

4 1 Introducción En el contexto de sistemas distribuidos de control (NCS, por Networked Control Systems) tolerantes a fallos software mediante manejo de excepciones, un lenguaje que ofrece algunas características muy interesantes e inusuales, es Erlang. Erlang es un lenguaje funcional, concurrente y distribuido, desarrollado a fines de los 80 en los laboratorios de la corporación Ericsson, con el fin de manejar la complejidad propia del desarrollo de grandes sistemas distribuidos de control, tolerantes a fallos y con características de tiempo real flexibles (soft). La idea original era utilizar un lenguaje de alto nivel en el dominio de sistemas de telecomunicaciones de misión crítica, con requisitos de disponibilidad de hasta un %. Las aplicaciones Erlang son configurables dinámicamente, resilientes ante fallos de software o hardware y capaces de garantizar una operación non-stop, lo cual se consiguió llevando al extremo el modelo de procesos UNIX. A nivel software estos requerimientos son similares a aquellos de aplicaciones basadas en Internet, resultando Erlang un buen candidato para el desarrollo de servicios basados en Web. Usuarios tales como Amazon, Google, Yahoo, Facebook, entre otros, confían en las capacidades del lenguaje para implementar sus sistemas. Demás áreas en las cuales ha sido aplicado: organización del control de tráfico aéreo/ferroviario y de otros sistemas embebidos complejos, mensajería instantánea, sistemas de seguridad crítica para pago electrónico, bases de datos, modelado 3D, implementación de robots autónomos móviles, etc. Con el convencimiento que Erlang ofrece una visión muy reveladora para los futuros diseños de sistemas de manejo de excepciones distribuidas y concurrentes, sería un ejercicio interesante y esclarecedor evaluarlo en comparación con los estrictos requisitos impuestos a un lenguaje de programación para aplicaciones relacionadas con la fiabilidad. Para este análisis se utilizan los veintitrés criterios propuestos en un artículo de la literatura [16] que investiga el uso de Java en el desarrollo de sistemas de alta integridad. Tomando como base algunas lecciones aprendidas en proyectos industriales y transmitidas por desarrolladores Erlang, se discuten aspectos del lenguaje que deberían mejorarse. El resto del informe está estructurado de la siguiente forma: en Sección 2 se analizan cada uno de los veintitrés criterios mencionados, separados en dos niveles: obligatorios (Subsección 2.1) y aconsejables (Subsección 2.2). Los requisitos obligatorios son aquellos que un lenguaje de programación debe satisfacer para ser considerado en la implementación de sistemas de software de alta integridad. Aquéllos aconsejables se consideran favorables para obtener sistemas más eficientes, claros y estructurados. En Sección 3 se realiza el veredicto final y se propone la adopción de Erlang para la implementación de un middleware orientado a mensajes para sistemas distribuidos de control (NCS), que constituye en realidad el origen y motivo de este estudio. 2 Requisitos del lenguaje de programación 2.1 Requisitos obligatorios Seguridad de tipos. La especialidad de Erlang, en contraste con la mayoría de los lenguajes funcionales, es su naturaleza fuertemente dinámica: las variables son dinámicamente 4

5 tipificadas, es decir, no son verificadas en tiempo de compilación sino que son estrictamente chequeadas en tiempo de ejecución (type-safe), lo cual probablemente produce una significativa disminución de la performance. Aunque los mecanismos del lenguaje que proveen tolerancia a fallos ayudan a cubrir errores residuales en el código de producción, un sistema de tipos estáticos produciría claros beneficios en la práctica; más aún, es un tema recurrente año a año en las Erlang Users Conference. La alta flexibilidad del lenguaje, hace muy difícil introducir un sistema de tipos sin eliminar parte de esta propiedad. En lugar de introducir tipos estáticos, el uso de herramientas como XREF y DIALYZER (por Discrepancy AnaLYZer of Erlang programs) constituye un balance ideal entre la flexibilidad de un desarrollo Erlang con el requerimiento de obtener código robusto y seguro. DIALYZER [18], [19] es una herramienta de análisis estático automático que detecta defectos, a los que se los denomina discrepancias, en código fuente o en bytecode y que, podrían estar ocultos especialmente en aquellas partes del programa que no son comúnmente ejecutadas o ensayadas. DIALYZER es aplicado en proyectos reales del área telecomunicaciones con más de un millón de líneas de código. Efectos secundarios. La mayor parte del lenguaje y, posiblemente la menos interesante, es el subconjunto secuencial del mismo el cual, puede caracterizarse como lenguaje estrictamente funcional y que, en su mayoría está libre de efectos secundarios: sólo hay unas pocas operaciones que los producen y prácticamente no se utilizan [1]. En la parte que maneja concurrencia, típicamente se producen efectos secundarios al invocar funciones que envían o reciben mensajes, leen de una cola de ellos o generan nuevos procesos. Erlang fue intencionalmente diseñado para ser un lenguaje pequeño utilizado conjuntamente con librerías que contienen un conjunto muy grande de funciones incorporadas, comúnmente denominadas BIFs (por las siglas de built-in functions); parecen estar escritas en Erlang, pero como sería muy ineficiente o imposible hacerlo están implementadas en C en la máquina virtual Erlang (llamada BEAM). Se producen efectos secundarios al invocar algunas de estas BIFs, lo cual hace el código menos reutilizable puesto que, causan cambios permanentes a su entorno y debe conocerse el estado exacto de un proceso antes de esta operación. Debido a que Erlang se diseñó como un lenguaje para controlar aplicaciones en tiempo real, donde la manipulación del hardware y la estricta secuencia de eventos son muy importantes, no puede comportarse como un lenguaje puramente funcional: una invocación a función puede producir una acción en el hardware y no hay garantías que éste responderá siempre de la misma forma; comportándose Erlang en este caso como un lenguaje imperativo, antes que estrictamente funcional. Por tanto, si no pueden eliminarse completamente los efectos secundarios, deben mantenerse restringidos a un número pequeño de módulos del programa, escritos, ensayados y documentados por los programadores más experimentados; las reglas de programación en Erlang [1] apoyan este enfoque. En [22] se propone como posible mejora, el desarrollo de un mini-lenguaje que entre otros requisitos a satisfacer, no debería permitir que los efectos secundarios sean visibles fuera del código del mismo; tal vez inspirado en el lenguaje funcional SISAL diseñado para computación paralela. Modularidad. Armstrong [1], uno de los creadores de Erlang, aplica viejos principios fundamentales para obtener un lenguaje de programación de sistemas tolerantes a fallos, tales como aquellos descriptos en un artículo de Gray [13]; una de las claves para ello: modularidad a través de procesos y mensajes. El proceso, ciudadano de 1ª clase en Erlang, provee una bien definida unidad de modularidad, servicio y contención de fallos. La filosofía fail-fast es central en el lenguaje; el lema de Erlang es: falle! y deje que otro proceso se ocupe de la recuperación de errores. Cada proceso puede pensarse como una máquina virtual 5

6 autocontenida en cada uno de ellos; procesos auténticos son comunes en sistemas operativos mientras que extremadamente inusuales en los lenguajes de programación de producción. La unidad de compilación es el módulo, con un nombre exclusivo y que contiene funciones (como en cualquier lenguaje funcional, objetos de 1ª clase); sólo aquellas marcadas como exportadas pueden invocarse desde otros módulos. Erlang se usa a menudo en sistemas de muy alta disponibilidad denominados nueve nueves, operables el % del tiempo o inactivos menos de 31ms. al año; tales sistemas no pueden detenerse para mejorar las prestaciones o instalar mecanismos de recuperación de errores; por tanto el lenguaje provee soporte para actualizar el código mientras el sistema está en funcionamiento ( hot-code loading ) [2]. Cuando se carga una nueva versión de un módulo, los nuevos procesos generados la ejecutarán mientras que, aquellos que estaban ejecutándose lo continuarán haciendo sin perturbarse. Los usuarios pueden controlar en detalle este proceso, ya sea en el momento de la carga inicial (en sistemas embebidos) o cuando se necesite (sistemas de propósito general). Armstrong [2] propone como posible mejora considerar a los módulos objetos de 1ª clase al igual que las funciones: debería permitirse tener múltiples versiones de ellos y dejar que el recolector de basura se encargue del código viejo que ya no pueda evaluarse. Semántica formal/ Estándares internacionales. Puesto que la historia de Erlang comienza en la industria y no en la universidad, fue definido principalmente en términos de su implementación; aún no tiene definida una semántica formal. Hubo varios intentos de formalización semántica, directamente o utilizando como base el cálculo-π [21]. La semántica obtenida fue empleada en varios proyectos de verificación [10] y para realizar una traslación del lenguaje, a la que se le aplicó model checking [4]. No existen estándares estables para el lenguaje. Bien comprendido. Algunas de las razones por las cuales Erlang es tan popular en la industria son su simpleza y elegancia, más allá de que requiere un cambio de mentalidad o de forma de pensar un programa. Este lenguaje basado en la sencillez del modelo de Actor para la comunicación interprocesos, permite escribir código con menos bugs, incrementando la productividad de un programador en un factor entre 4 y 10. Erlang está ganando reputación como lenguaje para crear un prototipo en forma muy rápida y, con pequeñas modificaciones, la versión final luego de una curva de aprendizaje inicial pronunciada. De las experiencias realizadas con el lenguaje [11], se considera que cualquier programador con espíritu aventurero, en menos de un mes puede realizar un aporte no trivial a cualquier proyecto Erlang. En cuanto a la dificultad para contratar programadores, proclamada en muchas publicaciones, se considera que es la misma que en el caso de programadores expertos en aplicaciones multihilos C++ o Java. La mayoría de los programadores de lenguajes funcionales son apasionados de la programación, lo cual en general, hace que sean muy buenos en su trabajo. Erlang es open source desde hace más de una década con lo cual la comunidad de usuarios y desarrolladores crece en forma sostenida, con beneficio adicional para Ericsson puesto que, han comenzado a reparar algunos bugs y proponer mejoras al lenguaje. Soporte para aplicaciones embebidas. Erlang es utilizado hoy en día por muchas compañías para implementar sistemas embebidos complejos con características de tiempo real flexibles, donde se manejen tiempos de respuesta del orden de milisegundos, a pesar que carece de características esenciales de los lenguajes de programación en tiempo real; el elemento tiempo no es tenido en cuenta salvo por el uso de timeouts y manejo de excepciones en tiempo real. 6

7 En un artículo reciente [20] se propone la implementación de un planificador de tareas de tiempo real estrictas (hard), enteramente escrito en Erlang y perfectamente integrado con la máquina virtual, mejora esperada en el área de robótica [23]. El trabajo está aún en la etapa inicial y no encara problemas tales como, paso de mensajes en tiempo real y efectos del comportamiento impredecible del recolector de basura. Este último es un problema crucial que, debe resolverse antes de obtener verdadero soporte para tiempo real estricto. Concurrencia. Erlang fue diseñado para construir programas concurrentes non stop [1]; usa procesos concurrentes, fuertemente aislados que no utilizan memoria compartida y se comunican mediante paso de mensajes asincrónicos. Los procesos Erlang son extremadamente livianos y pertenecen al lenguaje, no al sistema operativo; pueden ejecutarse en un único procesador, en uno multicore o en una red de ellos. En el mundo de Erlang no se necesita exclusión mutua ni mecanismos de sincronización. El emulador Erlang puede crear un nuevo proceso en menos de 1µs y ejecutar millones simultáneamente [17]; cada uno ocupa menos de 1KB de memoria y el paso de mensajes entre ellos se realiza en centésimas de nanosegundos. Para obtener tolerancia a fallos el lenguaje hace uso extensivo de procesos fail-fast, una técnica muy utilizada en plataformas hardware para conseguir este fin pero no tanto en soluciones software. El modelo de programación usado comúnmente, basado en threads, hace extremadamente difícil aislar componentes entre sí: un error en uno de ellos puede propagarse hacia otros y dañar la consistencia interna del sistema. El lenguaje fue diseñado con el objetivo en mente de proveer una mejor forma de escribir programas para aplicaciones en el área de telecomunicaciones que, por naturaleza son altamente concurrentes y tolerantes a fallos: un switch maneja decenas o cientos de miles de transacciones simultáneamente. En realidad más que un lenguaje, Erlang implica toda una filosofía que se denominó Programación Orientada a Concurrencia (COP por Concurrency-Oriented Programming), por analogía con Programación Orientada a Objetos (OOP). COP provee dos de las principales ventajas de usar OOP: el polimorfismo y el uso de protocolos definidos que tienen las mismas interfaces de paso de mensajes entre instancias de diferentes tipos de procesos. En COP la estructura concurrente del programa imita aquella de la aplicación, por tanto es apropiada para aplicaciones que modelen o interactúen con el mundo real, en el cual las actividades puramente secuenciales son una rareza. A pesar de la extrema resiliencia frente a sobrecargas que exhiben las aplicaciones distribuidas Erlang, el aislamiento entre procesos no es perfecto. Un proceso puede realizar un ataque de denegación de servicio a otro y llegar a agotar recursos considerados críticos, entre otros daños. En [25] se investiga la posibilidad de detectar este tipo de ataques, en un ambicioso intento de añadir capacidades basadas en control de acceso y comunicaciones seguras mediante criptografía. Actualmente, Erlang tiene un modelo de seguridad basado en cookies (o sea, basado en la confianza), el cual puede ser adecuado para redes con firewalls pero no para aquellas abiertas. Otra posible mejora apuntada por Armstrong [2] es la modificación del actual modelo de seguridad todo o nada de Erlang, para permitir distintos niveles de seguridad o confianza. En [25] se propone una jerarquía de nodos con distintos niveles de permiso de acceso a los recursos. Predictibilidad functional. Los análisis de flujo en los lenguajes funcionales son más complejos que en el caso de lenguajes imperativos; usualmente se basan en grafos de flujo que modelan el flujo de datos y de control del fragmento de código verificado. Al momento existe una propuesta de análisis de flujo para programas en Erlang [26]. 7

8 Predictibilidad temporal. El uso de máquina virtual y recolector de basura automático complican el análisis del tiempo de ejecución en el peor caso (WCET). Análisis de la utilización de recursos. Una aplicación típica Erlang utiliza una gran cantidad de procesos livianos, cuyo requerimiento de memoria es extremadamente difícil de predecir de antemano puesto que varía dinámicamente. Se están llevando a cabo investigaciones al respecto [25]. En algunas aplicaciones descartan el uso del lenguaje por el tamaño de memoria utilizada [7]. La cuestión reside en el método actual de recolección de basura pensado para sistemas en tiempo real flexibles; la actual performance parece ser aceptable en aplicaciones con procesos de vida corta y cuya necesidad de memoria es pequeña. Se desconoce si los autores de [7] probaron invocar la función erlang:hibernate [15] entre pasos de mensajes, que reduce drásticamente el uso de memoria sin incrementar significativamente el consumo de CPU. En [27] se exploran dos arquitecturas de memoria alternativas a fin de mejorar el desempeño global; ambas están aún en etapa experimental. Sigue pendiente la investigación del uso de recolectores de basura de tipo sin interrumpir, en lugar del actual parar el mundo que no es apropiado para la implementación de sistemas de tiempo real estrictos y que complementaría el estudio realizado en [27]. En una de las últimas revisiones de Erlang (2006) se incorpora soporte completamente transparente para SMP (Symmetric Multi Processing); los tests demuestran que aplicaciones ya existentes [8], sin modificaciones al utilizar arquitecturas multicore, mejoran significativamente su performance. Compilador y entorno de ejecución validados. La validación del compilador y la máquina virtual Erlang son temas pendientes de investigación. Run-time system support. El conjunto de librerías, aplicaciones, utilidades y módulos producidos simultáneamente con cada nueva versión de Erlang, se agrupan bajo el nombre de Open Telecom Platform (OTP) y se utiliza la denominación Erlang/OTP para referirse a la plataforma completa. Erlang está constituido por un núcleo (Erlang Runtime System) sobre el cual se ejecutan las librerías, incluyendo además la máquina virtual y las librerías estándares. Estas últimas incluyen módulos para la manipulación de las principales estructuras de datos del lenguaje además de componentes genéricos encapsulados como patrones de diseño (llamados behaviors), resultado de la experiencia de muchos años de construir sistemas tolerantes a fallos. También se incluye un conjunto muy completo y documentado de librerías y aplicaciones de propósito general; más aún, existe toda una filosofía homogénea de programación subyacente a esta plataforma. Aunque el lenguaje provee muchas características de alto nivel, la verificación de componentes de Erlang/OTP es aún no trivial; una forma posible de hacerlo es mediante model checking [5], [4], [14] que utiliza como base el álgebra de procesos µcrl. Debido al uso de patrones de diseño, los espacios de estados obtenidos a partir del modelo de fallas, son relativamente pequeños y pueden generarse automáticamente, haciendo factible el uso de esta técnica de verificación. 2.2 Requisitos aconsejables Manejo de excepciones/comportamiento frente a fallos. Erlang tiene un sencillo sistema de manejo de excepciones [6] que ha probado ser muy eficiente. Aunque dicho sistema ofrece primitivas simples mediante la composición de las mismas pueden implementarse sistemas 8

9 muy complejos. Las primitivas de concurrencia no sólo posibilitan crear hilos de control sino que, permiten a partes de una aplicación el monitoreo de otras y la reinicialización de aquéllas que fallen, aún si se ejecutan en distintos hosts conectados mediante una red. Erlang propicia el enfoque de detección dinámica y manejo de errores denominado programación ofensiva (contrapuesta a la programación defensiva) o, filosofía let it crash o fail-fast ; esto lo logra usando patrones de diseño denominados árboles de supervisión, que semejan la organización jerárquica de una empresa y encapsulan el monitoreo de un proceso por otro. Este patrón de supervisión, la versión Erlang de una niñera, es magistralmente explicado en detalle por Jim Larson en [17]: determinados procesos denominados supervisores monitorean todos los procesos importantes llamados trabajadores, los cuales son los que realmente hacen el trabajo. Si un proceso termina anormalmente, el supervisor correspondiente recibe un mensaje al respecto y, dependiendo de la razón de la finalización puede realizar diferentes acciones: registrar un mensaje de error, enviar un mensaje a otro proceso acerca de este evento o arrancar nuevamente el mismo proceso o uno nuevo que lo reemplace. Dentro de esta filosofía se modelan todas las fallas como permanentes; manteniendo simple el modelo de fallas, el algoritmo de recuperación de las mismas, también lo hará. Esta estrategia permite además obtener una clara separación entre el código correspondiente a la corrección de errores, de aquél dedicado al funcionamiento normal de la aplicación, posibilitando el diseño de aplicaciones altamente escalables y robustas. Este tipo de modelo puede reproducirse en otros lenguajes. La posibilidad de reconfiguración dinámica (hot load), ya mencionada, actúa como otro mecanismo de tolerancia a fallos. Modelo de matemáticas. Erlang usa enteros con precisión arbitraria [3], sólo limitada por la memoria disponible; la aritmética entera es exacta, por lo cual no hay que preocuparse de overflows o de no poder representar enteros en ciertos tamaños de palabras. Los números en punto flotante se almacenan internamente en el formato IEEE 754 doble precisión (64-bits), pudiendo representar números reales en el rango a Larson en [17], considera que el lenguaje no es bueno en cálculos de punto flotante intensivos. Soporte para documentación del usuario. El símbolo del % indica el comienzo de un comentario hasta el final de línea y, no posee ninguno para marcar aquellos de más de una línea. Al ser Erlang un lenguaje con tipos dinámicos requiere de comentarios para describir las estructuras de datos del programa a fin de mejorar la legibilidad. Existe además un generador de documentación llamado EDOC [19], inspirado en la herramienta JAVADOC de Java y adaptado a las convenciones del mundo Erlang; EDOC genera documentación en forma automática a partir de anotaciones manuales de tipos. Subtipos y enumeraciones. Erlang no soporta enumeraciones aunque podrían emularse. Tampoco soporta subtipos; se intentó desarrollar un sistema de tipos basado en subtipos pero el proyecto no tuvo éxito en la comunidad Erlang, quizás porque en el intento de detectar más errores en tiempos de compilación, se trató de imponer un estilo de programación que es más cercano al de los lenguajes con tipos estáticos, a costa de eliminar parte de la flexibilidad característica del lenguaje. Pautas para el estilo de codificación. En [9] hay una guía para escribir buen código en Erlang basada en la experiencia de varios proyectos comerciales. 9

10 Soporte para la abstracción y ocultamiento de la información. En Erlang los procesos son los mecanismos más sólidos para proveer encapsulamiento, abstracción y aislamiento puesto que, la máquina virtual evita que el código cruce las fronteras del proceso: el paso de mensajes es el mecanismo normal para la comunicación a través de las interfaces sin violar el principio de aislamiento; los protocolos de los mensajes implementan la abstracción de dichas interfaces. Aserciones. En Erlang las variables se comportan tal como en matemáticas, cuando se realiza la única asignación posible a las mismas, en realidad se enuncia una aserción que si se viola genera una excepción. Herramientas de análisis certificadas. Se han desarrollado distintas herramientas de análisis para asistir en la depuración de programas Erlang aunque no están certificadas por organismos o normas confiables. Los programas concurrentes son difíciles de depurar y verificar. Una forma posible de verificar un programa Erlang implica obtener un modelo formal intermedio al cual puede aplicársele técnicas de model checking; en particular se utiliza álgebra de procesos μcrl como lenguaje formal [5]. Interface con otros lenguajes. Un programa Erlang tiene posibilidad de interactuar con código escrito en otro lenguaje, que correrá fuera del sistema de tiempo de ejecución Erlang a través de un puerto (port); un canal de comunicación orientado a byte. La implementación actual de este mecanismo [3] depende de la plataforma, en Unix se utiliza el concepto de pipes. Teóricamente, el programa externo podría estar escrito en cualquier lenguaje mientras pueda manejar el mecanismo de comunicación interprocesos, con el cual está implementado el puerto. Usando este mismo principio básico de operación, un proceso Erlang puede abrir un socket para comunicar entre sí nodos Erlang distribuidos. Como ayuda a los programadores existen librerías para la interfaz entre Erlang y C o Java. Por tanto es muy fácil crear drivers, por ejemplo en C, para controlar hardware o implementar partes del sistema cuya performance sea crítica y delegar a Erlang el manejo de actividades concurrentes o distribuidas complejas. En [24] se propone una interfaz a código nativo de forma simple y eficiente, utilizada para simulación de procesos físicos. Un aspecto positivo del uso del mecanismo de puertos es que cualquier error fatal en el software externo no afecta el sistema ejecutando Erlang. Una desventaja es que el cambio de contexto y la comunicación entre procesos pueden ser muy costosos. Si el tiempo es una cuestión crítica, una posible solución es el uso de linked in drivers [12], con una latencia de comunicación entre 10 y 25 veces más pequeña que en el caso de los puertos. Esto implica escribir un programa en C, de acuerdo a ciertos principios y, enlazarlo dinámicamente al sistema en tiempo de ejecución de Erlang, preservando la ilusión de que los drivers son procesos escritos en este lenguaje. Este mecanismo compromete seguridad a cambio de velocidad: un error en él puede colapsar la máquina virtual y todas las aplicaciones que se estén ejecutando. Este es un aspecto negativo de Erlang [2] que debería mejorarse. Optimización del código. La implementación por defecto de Erlang es un intérprete de bytecode HIPE, el compilador a código nativo, completamente integrado en la versión open source, translada bytecode de la máquina virtual BEAM, just-in-time o ahead-of-time a código nativo (actualmente de ULTRASPARC, x86, y AMD64). HIPE soporta la ejecución mixta de código nativo e interpretado a nivel de granularidad de funciones individuales, otorgando al usuario un control de grano fino sobre el trade-off velocidad de ejecución/tamaño de código [18]. 10

11 Durante los últimos años se experimentaron formas de generar código nativo más rápido, tratando de eliminar estadísticamente y tanto como es posible, la sobrecarga introducida por la verificación de tipos en tiempo de ejecución. Portabilidad. Erlang se basa en el uso de máquina virtual con recolector de basura lo que permite obtener portabilidad a un gran número de plataformas (Windows, Linux, BSD, MacOSX, Solaris, VxWorks, etc.). 3 Conclusiones y trabajo futuro Se evaluó el lenguaje de programación Erlang en base a veintitrés estrictos requisitos, disponibles en la literatura, para examinar el uso de un lenguaje de programación en el desarrollo de sistemas de alta integridad. Erlang no cumple con muchos de los requisitos obligatorios o lo hace sin excesivo rigor. La respuesta a la pregunta planteada en el título: Erlang aún no es apropiado para el desarrollo de sistemas totalmente confiables. Sin embargo, puede afirmarse con seguridad que es perfectamente adecuado para sistemas de importancia empresarial crítica (BCS, por businesscritical systems), donde las consecuencias de un fallo no son tan graves, en el sentido que no producen daños físicos a personas sino que, las implicancias negativas pueden ser una amenaza a la confianza o economía. Es en este área donde Erlang ha tenido un éxito considerable; uno de los aspectos por el cual es tan popular entre los desarrolladores de BCS es la inclusión de constructos para obtener tolerancia a fallos. Teniendo en mente este hecho se piensa utilizar Erlang para la implementación de un middleware orientado a mensajes, basado en el modelo arquitectural de un microkernel, para sistemas distribuidos de control (NCS) con características de tiempo real flexible. Referencias 1. Armstrong, J. L.: Making reliable distributed systems in the presence of software errors. PhD thesis, Royal Institute of Technology, Estocolmo, Suecia, (2003). 2. Armstrong, J.: A history of Erlang. En HOPL III: Proceedings of the third ACM SIGPLAN Conference on History of Programming Languages, , (2007). 3. Armstrong, J.: Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf, ISBN X, (2007). 4. Arts, T, Benac Earle, C. y Sánchez Penas, J. J.. Translating Erlang to µcrl. En Fourth International Conference on Application of Concurrency to System Design, , Canada, (2004). 5. Benac-Earle, C., Fredlund, L. y Derrick, J.: Verifying Fault-Tolerant Erlang Programs. En Proceedings of ACM SigPlan Erlang 2005 Workshop, ACM Press, (2005). 6. Carlsson, R., Gustavsson, B., y Nyblom, P.: Erlang s Exception Handling Revisited. En: Proceedings of the Third ACM SIGPLAN Erlang Workshop, 16-26, (2004). 7. Convey, C., Fredricks, A., Gagner, C., Maxwell D. y Hamel, L.: Experience Report: Erlang in Acoustic Ray Tracing. The 13th ACM SIGPLAN International Conference on Functional Programming (ICFP 2008), ACM SIGPLAN Notices 43(9): , (2008). 8. Ericsson: Erlang goes multi-core, news/archive/erlang_goes multi_core.shtml, (2006). Accedido: 21/07/09. 11

12 9. Eriksson, K., Williams, M. y Armstrong, J.: Program Development Using Erlang - Programming Rules and Conventions. Internal Ericsson document EPK/NP 95:035, (1996). Accedido: 21/07/ Fredlund, L.-A., Gurov, D., Noll, T., Dam, M., Arts, T y Chugunov, G.: A verification tool for Erlang. International Journal on Software Tools for Technology Transfer (STTT), 4(4): , (2003). 11. Fritchie, S.L., Larson, J., Christenson, N., Jones, D. y Ohman, L.: Sendmail Meets Erlang: Experiences Using Erlang for Applications. Sixth International Erlang/OTP User Conference. Stockholm, (2000). 12. Fritchie, S. L.: The evolution of Erlang drivers and the Erlang driver toolkit. En Proceedings of the 1st ACM SIGPLAN Erlang Workshop, 34 44, (2002). 13. Gray, J.: Why do computers stop and what can be done about it?. Technical Report 85.7, Tandem Computers, (1985). 14. Guo, Q. y Derrick, J.: Verification of Timed Erlang/OTP Components Using the Process Algebra µcrl. 6th ACM SIGPLAN Erlang Workshop, 55-64, (2007). 15. Jones, R., A: Million-user Comet Application with Mochiweb, Part 2. Accedido: 21/07/ Kwon, J., Wellings, A. y King, S.: Assessment of the Java Programming Language for Use in High Integrity Systems. SIGPLAN Not., 38(4):34 46, (2003). 17. Larson, J.: Erlang for concurrent programming. Commun. ACM, Vol. 52, No. 3., 48-56, (2009). 18. Lindahl, T. y Sagonas, K.: Detecting software defects in telecom applications through lightweight static analysis: A war story. En Programming Languages and Systems: Proceedings of the Second Asian Symposium (APLAS'04), Vol de LNCS, , Springer, (2004). 19. Lindahl T. y Sagonas. K.: Typer: a type annotator of Erlang code. En Proceedings of the 2005 ACM SIGPLAN Erlang Workshop, 17 25, (2005). 20. Nicosia, V.: Towards hard real-time erlang. En Erlang '07: Proceedings of the 2007 SIGPLAN workshop on Erlang Workshop, 29-36, (2007). 21. Noll, T. y Roy. C. K.: Modeling Erlang in the π-calculus. En Proceedings of the ACM SIGPLAN 2005 Erlang Workshop (Erlang 05), 72 77, ACM, (2005). 22. Nyström, S.: Ideas for a new Erlang. Technical Report , Department of Information Technology Uppsala University, (2009). 23. Santoro, C.: An Erlang framework for autonomous mobile robots. En Proceedings of the 2007 SIGPLAN workshop on Erlang Workshop, Germany, (2007). 24. Scalas, A., Casu, G. y Pili, P.: High-performance technical computing with Erlang. En Proceedings of the 7th ACM SIGPLAN workshop on ERLANG, 49-60, (2008). 25. Teller, D.: Towards a resource-safe Erlang. En Proceedings of the 3rd Workshop on Collaboration and Security, 66-71, (2007). 26. Widera, M.: Adapting Structural Testing to Functional Programming. Software Engineering Research and Practice, CSREA Press, 86-92, (2006). 27. Wilhelmsson, J.: Exploring Alternative Memory Architectures for Erlang: Implementation and Performance Evaluation. Master s Thesis, Uppsala Unviversity, (2002). 12

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

LENGUAJES DE PROGRAMACIÓN POR QUÉ HAY TANTOS Y APARECEN NUEVOS? Por: Hanna Oktaba

LENGUAJES DE PROGRAMACIÓN POR QUÉ HAY TANTOS Y APARECEN NUEVOS? Por: Hanna Oktaba LENGUAJES DE PROGRAMACIÓN POR QUÉ HAY TANTOS Y APARECEN NUEVOS? Por: Hanna Oktaba La computadora, a diferencia de otras herramientas que en general apoyan el esfuerzo físico de los humanos, fue inventada

Más detalles

Grupo de Procesadores de Lenguajes - Línea: Código Móvil Seguro

Grupo de Procesadores de Lenguajes - Línea: Código Móvil Seguro Grupo de Procesadores de Lenguajes - Línea: Código Móvil Seguro Francisco Bavera Martín Nordio Jorge Aguirre Marcelo Arroyo Gabriel Baum Ricardo Medel Resumen En el último tiempo Proof-Carrying Code (PCC)

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

A continuación resolveremos parte de estas dudas, las no resueltas las trataremos adelante

A continuación resolveremos parte de estas dudas, las no resueltas las trataremos adelante Modulo 2. Inicio con Java Muchas veces encontramos en nuestro entorno referencias sobre Java, bien sea como lenguaje de programación o como plataforma, pero, que es en realidad Java?, cual es su historia?,

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Enseñanza de programación multihilo y controladores de dispositivo en entornos Windows para alumnos de electrónica

Enseñanza de programación multihilo y controladores de dispositivo en entornos Windows para alumnos de electrónica Enseñanza de programación multihilo y controladores de dispositivo en entornos Windows para alumnos de electrónica A. Da Silva, V. Hernández y J.F. Martínez Departamento de Ingeniería y Arquitecturas Telemáticas.

Más detalles

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas Unidad I Fundamentos de Sistemas Distribuidos M.C. Juan Carlos Olivares Rojas Temario 1.1. Características de un sistema distribuido 1.2. Objetivos de los sistemas distribuidos 1.3. Ventajas y desventajas

Más detalles

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES SISTEMAS DISTRIBUIDOS DE REDES 5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES Programación remota: Introducción y generalidades INTRODUCCIÓN Debido a la dificultad de la arquitectura actual

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Técnicas Avanzadas de Testing Automático

Técnicas Avanzadas de Testing Automático Técnicas Avanzadas de Testing Automático Marcelo Frias ITBA - Buenos Aires, Argentina CONICET Preliminares: Calidad Validación y Verificación Especificaciones y V&V Análisis estático y dinámico Inspecciones

Más detalles

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil

Más detalles

SISTEMAS DE ARCHIVOS DISTRIBUIDOS

SISTEMAS DE ARCHIVOS DISTRIBUIDOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS Tema # VII Sistemas de operación II Abril-Julio 2008 Yudith Cardinale Introducción Requisitos Aspectos de Diseño Servicios de archivos Servicios de directorios Módulo

Más detalles

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO

CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO CENTRO DE RESGUARDO Centro de Cómputos de Resguardo Sitio para reubicarse luego de un desastre Sitio manejado

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

Análisis de Lenguajes de Programación II El Inicio

Análisis de Lenguajes de Programación II El Inicio Análisis de II El Inicio 08/08/2011 Docentes de la Materia Cecilia Manzino Pablo Buiras Lucio Nardelli Adscripto: Martín Ceresa (mauro@fceia.unr.edu.ar) (ceciliam@fceia.unr.edu.ar) (pablobuiras@gmail.com)

Más detalles

PROGRAMACIÓN BÁSICA DE LA COMPUTADORA. 1 Introducción. Tabla 1: Instrucciones MIPS

PROGRAMACIÓN BÁSICA DE LA COMPUTADORA. 1 Introducción. Tabla 1: Instrucciones MIPS PROGRAMACIÓN BÁSICA DE LA COMPUTADORA 1 Introducción Un sistema de computadora total incluye tanto circuitería (hardware) como programación (software). El hardware consta de los componentes físicos y todo

Más detalles

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 Prof. Edgardo Adrián Franco Martínez http://computacion.cs.cinvestav.mx/~efranco efranco.docencia@gmail.com Estructuras de datos (Prof. Edgardo A. Franco)

Más detalles

UNIVERSIDAD NACIONAL DEL SUR 1 BAHIA BLANCA DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACION CORRELATIVAS OBJETIVOS

UNIVERSIDAD NACIONAL DEL SUR 1 BAHIA BLANCA DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACION CORRELATIVAS OBJETIVOS UNIVERSIDAD NACIONAL DEL SUR 1 PROFESOR RESPONSABLE: Mg. Javier Echaiz Profesor Adjunto con Dedicación Exclusiva CARGA HORARIA Teoría 4 hs Práctica 28 hs PARA CURSAR LA MATERIA APROBADAS CURSADAS *Organización

Más detalles

Marco Teórico MARCO TEÓRICO. AGNI GERMÁN ANDRACA GUTIERREZ

Marco Teórico MARCO TEÓRICO. AGNI GERMÁN ANDRACA GUTIERREZ MARCO TEÓRICO. 13 14 Virtualización Hablar de virtualización es hablar de un concepto que describe la posibilidad de tener varios sistemas operativos funcionando al mismo tiempo en un mismo equipo físico.

Más detalles

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz Compiladores y Lenguajes de Programación Maria de Guadalupe Cota Ortiz Organizaciones que rigen las normas para estandarización de Lenguajes de Programación IEEE (Instituto de Ingenieros Eléctricos y Electrónicos)

Más detalles

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos.

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos. Contenidos Sistemas operativos Tema 3: Estructura del sistema operativo Componentes típicos del SO Servicios del SO Llamadas al sistema Programas del sistema El núcleo o kernel Modelos de diseño del SO

Más detalles

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA).

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). López, G. 1 ; Jeder, I. 1 ; Echeverría, A. 1 ; Fierro, P. (PhD.) 2 1. Laboratorio de Informática de Gestión

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 1: Introducción: 1.1 Introducción: Qué es un sistema operativo?. 1.2 Conceptos clave de un sistema operativo. 1.3 El sistema operativo como administrador

Más detalles

Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más)

Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más) Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más) Nombre del Encuestado e-mail Nombre de la Carrera Universidad Unidad Académica Sede

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Notas técnicas de JAVA Nro. 4 White Paper

Notas técnicas de JAVA Nro. 4 White Paper Tema: Notas técnicas de JAVA Nro. 4 White Paper (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) JAVA Basics : Entendiendo la Java Virtual Machine (JVM) Java, JVM, objetos, introducción,

Más detalles

Bloque II. Elementos del lenguaje de programación Java

Bloque II. Elementos del lenguaje de programación Java Bloque II. Elementos del lenguaje de programación Java 1.Introducción a los lenguajes de programación 2. Estructura de un programa 3. Datos y expresiones simples 4. Instrucciones de control 5. Entrada/salida

Más detalles

COMPUTACIÓN DE ALTA PERFORMANCE

COMPUTACIÓN DE ALTA PERFORMANCE COMPUTACIÓN DE ALTA PERFORMANCE 2011 1 TOLERANCIA A FALLOS COMPUTACIÓN DE ALTA PERFORMANCE Curso 2011 Sergio Nesmachnow (sergion@fing.edu.uy) Santiago Iturriaga (siturria@fing.edu.uy) Gerardo Ares (gares@fing.edu.uy)

Más detalles

AcuSQL Pre-compilador de SQL Embebido

AcuSQL Pre-compilador de SQL Embebido AcuSQL Pre-compilador de SQL Embebido RESUMEN EJECUTIVO AcuSQL es una sencilla y rentable solución para aquellos que utilizan sentencias SQL embebidas en sus programas COBOL para acceder fuentes de datos

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS Autores: Introducción Diego R. López RedIRIS diego.lopez@rediris.es El trabajo necesario para mantener un servidor de información

Más detalles

Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team

Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team Rafael Rodríguez-Puente 1, Eliana B. Ril-Valentin 2 1 Departamento de Técnicas de

Más detalles

Estructura del Sistema Operativo. Módulo 2. Estructuras de Sistemas Operativos

Estructura del Sistema Operativo. Módulo 2. Estructuras de Sistemas Operativos Estructura del Sistema Operativo Módulo 2 Estructuras de Sistemas Operativos Servicios de Sistemas operativos Interfaz de Usuario del Sistema Operativo Llamadas a Sistema Tipos de Llamadas a Sistema Programas

Más detalles

Programación Orientada a Objetos: Clases versus Prototipos 1

Programación Orientada a Objetos: Clases versus Prototipos 1 Programación Orientada a Objetos: Clases versus Prototipos 1 Pedro Cuesta Morales (pcuesta@uvigo.es) Departamento de Lenguajes y Sistemas Informáticos Universidad de Vigo Resumen: En este artículo se introducen

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Resumen. Contexto. Palabras clave: integración continua, software científico técnico, calidad de software.

Resumen. Contexto. Palabras clave: integración continua, software científico técnico, calidad de software. Automatización en el desarrollo de Software Crítico en el Ámbito Científico Técnico Alicia Salamon, Patricio Maller, Alejandra Boggio, Natalia Mira, Sofia Perez, Francisco Coenda. Departamento de Informática,

Más detalles

Curso de Android con Java

Curso de Android con Java Todos los Derechos Reservados Global Mentoring Experiencia y Conocimiento para tu Vida 1 Este es un tiempo único para el mundo de los celulares, en particular de los Smartphones. Este tipo de dispositivos

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

UNIVERSIDAD NACIONAL DEL SUR 1 BAHIA BLANCA DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACION

UNIVERSIDAD NACIONAL DEL SUR 1 BAHIA BLANCA DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACION UNIVERSIDAD NACIONAL DEL SUR 1 CODIGO: 792 CARRERAS Y PLANES Licenciatura en Ciencias de la Computación Plan 2007 Licenciatura en Ciencias de la Computación Plan 2011 PROFESOR RESPONSABLE: Mg. Javier Echaiz

Más detalles

El monitoreo de una variable física requiere supervisión permanente de señales que

El monitoreo de una variable física requiere supervisión permanente de señales que Capítulo 1 Marco Contextual 1.1. Formulación del problema 1.1.1. Definición del problema El monitoreo de una variable física requiere supervisión permanente de señales que varían con el tiempo. Tal información,

Más detalles

INDICE. Prefacio Parte 1: sistemas operativos tradicionales

INDICE. Prefacio Parte 1: sistemas operativos tradicionales INDICE Prefacio Parte 1: sistemas operativos tradicionales 1 1 Introducción 1.1 Qué es un sistema operativo? 1.1.1 El sistema operativo como una maquina extendida 3 1.1.2 El sistema operativo como controlador

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

INTRODUCCIÓN A JAVA. Índice

INTRODUCCIÓN A JAVA. Índice INTRODUCCIÓN A JAVA Índice Qué es Java? La plataforma Java 2 La Máquina Virtual de Java Características principales Qué ventajas tengo como desarrollador? Bibliografía 2 1 Qué es Java? La tecnología Java

Más detalles

Utilización de Ciclos Ociosos de Servidores de Internet

Utilización de Ciclos Ociosos de Servidores de Internet Utilización de Ciclos Ociosos de Servidores de Internet Champredonde Raúl 1 Pasini Ariel 2 La Battaglia Juan 3 Laboratorio de Investigación y Desarrollo en Informática 4 Facultad de Informática - Universidad

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Soluciones Java esenciales. Documento técnico de Oracle

Soluciones Java esenciales. Documento técnico de Oracle Soluciones Java esenciales Documento técnico de Oracle Soluciones Java esenciales La familia de productos Oracle JRockit es una cartera integral de soluciones Java en tiempo de ejecución que aprovecha

Más detalles

IMPLEMENTACION DE UN INTERPRETE SQL EN MANAGED CODE PARA DISPOSITIVOS MOVILES

IMPLEMENTACION DE UN INTERPRETE SQL EN MANAGED CODE PARA DISPOSITIVOS MOVILES IMPLEMENTACION DE UN INTERPRETE SQL EN MANAGED CODE PARA DISPOSITIVOS MOVILES Sebastián Mariano Salomón Luis Rogero Lucero Daniel Alejandro Giménez Gabriel Mamani Federico Martín Pascual Ing. Cesar Ignacio

Más detalles

Análisis de desempeño y modelo de escalabilidad para SGP

Análisis de desempeño y modelo de escalabilidad para SGP Análisis de desempeño y modelo de escalabilidad para SGP Este documento es producto de la experiencia de Analítica en pruebas de stress sobre el software SGP. Estas pruebas se realizaron sobre un proceso

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

U.T.4.EL ENTORNO DE DESARROLLO

U.T.4.EL ENTORNO DE DESARROLLO U.T.4.EL ENTORNO DE DESARROLLO Lenguaje Java Estamos en unos días en los que cada vez más la informática invade más campos de nuestra vida, estando el ciudadano medio cada vez más familiarizado con términos

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

SÍNTESIS DE SISTEMAS DE CONTROL DIFUSOS MEDIANTE HERRAMIENTAS DE DISEÑO DSP SOBRE FPGAS 1

SÍNTESIS DE SISTEMAS DE CONTROL DIFUSOS MEDIANTE HERRAMIENTAS DE DISEÑO DSP SOBRE FPGAS 1 SÍNTESIS DE SISTEMAS DE CONTROL DIFUSOS MEDIANTE HERRAMIENTAS DE DISEÑO DSP SOBRE FPGAS 1 S. Sánchez-Solano 1, M. Brox 2, A. Cabrera 3 1 Instituto de Microelectrónica de Sevilla (CNM-CSIC). Sevilla, España.

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

VNUML: UNA HERRAMIENTA DE VIRTUALIZACIÓN DE REDES BASADA EN SOFTWARE LIBRE

VNUML: UNA HERRAMIENTA DE VIRTUALIZACIÓN DE REDES BASADA EN SOFTWARE LIBRE VNUML: UNA HERRAMIENTA DE VIRTUALIZACIÓN DE REDES BASADA EN SOFTWARE LIBRE Fermín Galán 1, David Fernández 2 1 Agora Systems S. A.; 2 Departamento de Ingeniería Telemática, UPM fermin.galan@agora-2000.com

Más detalles

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Nombre de la asignatura: Arquitectura Cliente Servidor

Nombre del documento: Programa de Estudio de asignatura de Especialidad. Nombre de la asignatura: Arquitectura Cliente Servidor 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Arquitectura Cliente Servidor Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: SIF-1204 (Créditos) SATCA: 3-2-5 2.- PRESENTACIÓN

Más detalles

Introducción En este apartado se va a proporcionar una apreciación global del SRS.

Introducción En este apartado se va a proporcionar una apreciación global del SRS. INTRODUCCIÓN Se pretende desarrollar una aplicación web para la gestión de un restaurante que ofrece espectáculos en fechas determinadas con el fin de poner en práctica los principios de planificación

Más detalles

CURSOS DE VERANO 2014

CURSOS DE VERANO 2014 CURSOS DE VERANO 2014 CLOUD COMPUTING: LA INFORMÁTICA COMO SERVICIO EN INTERNET LA PLATAFORMA GOOGLE CLOUD PLATFORM. GOOGLE APP ENGINE Pedro A. Castillo Valdivieso Universidad de Granada http://bit.ly/unia2014

Más detalles

Fundamentos de Sistemas Operativos

Fundamentos de Sistemas Operativos Fundamentos de Sistemas Operativos Sistemas Informáticos Fede Pérez Índice TEMA Fundamentos de Sistemas Operativos 1. - Introducción 2. - El Sistema Operativo como parte de un Sistema de Computación 2.1

Más detalles

Tema 1: y el lenguaje Java 1.Programación orientada a objetos 2.El lenguaje Java 3.Compilación, bytecode y JVMs 4.Entornos de desarrollo Java 5.Java vs otros lenguajes OO Programación orientada a objetos

Más detalles

Estilos y Patrones Arquitectónicos

Estilos y Patrones Arquitectónicos Lic. Ariel Trellini Estilos y Patrones Arquitectónicos Llamando a las cosas por su nombre Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Arquitectura y Diseño de Sistemas

Más detalles

2.- Estructuras de Sistemas Operativos

2.- Estructuras de Sistemas Operativos 2.- Estructuras de Sistemas Operativos Describir los servicios que el SO proporciona a los usuarios, procesos y otros sistemas Estudiar las maneras de estrcturar un SO Explicar como se instala un SO, como

Más detalles

Arquitectura software EN-HORA

Arquitectura software EN-HORA Arquitectura de en:hora Arquitectura software EN-HORA en:hora es un software de control de acceso y presencia con una arquitectura modular. El software se implementa mediante un conjunto de componentes

Más detalles

El Framework de desarrollo del Consejo

El Framework de desarrollo del Consejo El Framework de desarrollo del Consejo Superior de Investigaciones Científicas Director de la OPCSIC Centro Técnico de Informática (CSIC) Directora Centro Técnico de Informática (CSIC) Palabras clave Framework,

Más detalles

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

Más detalles

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES Denominación de la materia SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES créditos ECTS = 36 carácter = OBLIGATORIA Ubicación dentro del plan de estudios y duración La materia está formada por 6 asignaturas

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Construyendo la seguridad de la información: Principios, Políticas y Procedimientos

Construyendo la seguridad de la información: Principios, Políticas y Procedimientos Construyendo la seguridad de la información: Principios, Políticas y Procedimientos Patricia Prandini Posgrado en Seguridad Informática Universidad de Buenos Aires Agenda I. Porqué necesitamos un marco

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Computación Grid. Adaptación de Aplicaciones Grid para el Procesamiento de Imágenes (AAG) Miguel Cárdenas Montes

Computación Grid. Adaptación de Aplicaciones Grid para el Procesamiento de Imágenes (AAG) Miguel Cárdenas Montes Grid Adaptación de Aplicaciones Grid para el Procesamiento de Imágenes (AAG) Miguel Cárdenas Montes Centro de Investigaciones Energéticas Medioambientales y Tecnológicas, Madrid, Spain Máster: Grid y Paralelismo

Más detalles

puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales?

puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? RESUMEN DE LA SOLUCIÓN Service Operations Management puede asegurar a sus clientes la calidad y disponibilidad de los servicios empresariales? agility made possible (SOM) de CA Technologies es una solución

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

Más detalles

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009

Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga. Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar pruebas de carga Documento técnico de Oracle Junio de 2009 Identificación rápida de cuellos de botella: Una mejor manera de realizar

Más detalles

Tema 1: Introducción a la gestión y planificación de redes

Tema 1: Introducción a la gestión y planificación de redes Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

OPC: De qué se trata, y cómo funciona?

OPC: De qué se trata, y cómo funciona? OPC: De qué se trata, y cómo funciona? Guía para entender la Tecnología OPC Darek Kominek, P. Eng. Alberta, Canada - 2009 Resumen Ejecutivo Este artículo sobre Tecnología OPC es una sencilla introducción

Más detalles

Agrupación en clusters de las aplicaciones de bases de datos para reducir los costos de TI Introducción

Agrupación en clusters de las aplicaciones de bases de datos para reducir los costos de TI Introducción Enero 2010 Agrupación en clusters de las aplicaciones de bases de datos para reducir los costos de TI Reorganizarse para lograr eficiencia, rendimiento y alta disponibilidad Introducción La agrupación

Más detalles

UNIVERSIDAD DE OVIEDO

UNIVERSIDAD DE OVIEDO UNIVERSIDAD DE OVIEDO ESCUELA POLITÉCNICA DE INGENIERÍA DE GIJÓN MÁSTER EN INGENIERÍA INFORMÁTICA TRABAJO FIN DE MÁSTER SPRING ROO ADD-ONS PARA PROTOTIPADO RÁPIDO JAVIER MENÉNDEZ ÁLVAREZ JULIO 2014 UNIVERSIDAD

Más detalles

picojava TM Características

picojava TM Características picojava TM Introducción El principal objetivo de Sun al introducir Java era poder intercambiar programas ejecutables Java entre computadoras de Internet y ejecutarlos sin modificación. Para poder transportar

Más detalles

COMPARACIÓN DEL RENDIMIENTO COMPUTACIONAL ENTRE DIFERENTES METODOLOGÍAS DE PROCESAMIENTO EN PARALELO PARA FEA VÍA ANSYS 14.5

COMPARACIÓN DEL RENDIMIENTO COMPUTACIONAL ENTRE DIFERENTES METODOLOGÍAS DE PROCESAMIENTO EN PARALELO PARA FEA VÍA ANSYS 14.5 Second International Conference on Advanced Mechatronics, Design, and Manufacturing Technology - AMDM 2014 1 COMPARACIÓN DEL RENDIMIENTO COMPUTACIONAL ENTRE DIFERENTES METODOLOGÍAS DE PROCESAMIENTO EN

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles