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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez

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

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

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

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

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

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

Ciclo de vida del software

Ciclo de vida del software Ciclo de vida del software Definición El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Confiable,

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

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

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

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

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

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

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

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

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

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

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

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

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

Introducción al Software basado en Componentes. Motivación. Un poco de historia.

Introducción al Software basado en Componentes. Motivación. Un poco de historia. Introducción al Software basado en Componentes Juan José Moreno Navarro Curso de Doctorado LSIIS (junto con Lars-Ake Fredlund) Motivación Antecedentes: Sistemas distribuidos y el problema de la reutilización.

Más detalles

DISEÑO DE UN CURSO INTERACTIVO Y ADAPTATIVO DE PROCESADORES DE LENGUAJES

DISEÑO DE UN CURSO INTERACTIVO Y ADAPTATIVO DE PROCESADORES DE LENGUAJES Alfonseca, M., Carro, R.M., Pulido, E. and Rodríguez, P. (2000): Diseño de un curso interactivo y adaptativo de procesadores de lenguajes. Proceedings of JENUI 2000: VI Jornadas sobre la Enseñanza Universitaria

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

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

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8 Documento de Competencias Grado en INGENIERÍA INFORMÁTICA Facultad de Informática, UPV/EHU 1 Estructura general del Grado 1.1 Fundamentos de Tecnología de los Principios de Diseño de Sistemas Digitales

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

D E S C R I P C I Ó N

D E S C R I P C I Ó N ADAPTOR pertenece a la nueva generación en herramientas de Integración de Sistemas (EAI) fuertemente inspirada en el paradigma SOA y capaz de funcionar en un bus de servicios (ESB), es la forma más eficiente

Más detalles

Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011

Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011 Módulo 1. Fundamentos de Computadores Informática y Programación Escuela de Ingenierías Industriales y Civiles Grado en Ingeniería en Ingeniería Química Curso 2010/2011 1 CONTENIDO Tema 1. Introducción

Más detalles

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su

CAPÍTULO 5. Hemos utilizado la técnica de programación orientado a objetos por su 88 CAPÍTULO 5 5. IMPLEMENTACIÓN 5.1 Modelo Utilizado en Programación. Hemos utilizado la técnica de programación orientado a objetos por su eficiencia y eficacia en el modelo mvc, ya que permite la reutilización

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

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

aspectos y no estaríamos donde estamos hoy, si hubiéramos utilizado otra herramienta.

aspectos y no estaríamos donde estamos hoy, si hubiéramos utilizado otra herramienta. 4D es una plataforma de aplicación Web, flexible, potente y muy escalable. Este documento examina los requerimientos comunes para servidores de aplicación Web, y discute las ventajas ofrecidas por la línea

Más detalles

Software Computacional y su clasificación

Software Computacional y su clasificación Software Computacional y su clasificación Capítulo 5 El software En modo sencillo el software permite que las personas puedan contarle a la computadora cierto tipo de problemas y que ésta a su vez le ofrezca

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

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

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

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

Descripción de las posiciones del área de sistemas

Descripción de las posiciones del área de sistemas Descripción de posiciones del área de Sistemas Operador/Data Entry Entrar y verificar datos provenientes de distintas vías de ingreso. Monitorear procesos, programas y resultados. Seguir los formatos apropiados

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

Herramientas Informáticas I. Software: Clasificación y Funcionalidad Facultad de Ciencias Económicas y Jurídicas Universidad Nacional de La Pampa

Herramientas Informáticas I. Software: Clasificación y Funcionalidad Facultad de Ciencias Económicas y Jurídicas Universidad Nacional de La Pampa Herramientas Informáticas I Software: Clasificación y Funcionalidad Facultad de Ciencias Económicas y Jurídicas Universidad Nacional de La Pampa 2013 Introducción La clasificación del Software permitirá

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

Datos parciales. Datos Parciales. La Programación estructurada se concentra en las acciones que controlan el flujo de datos.

Datos parciales. Datos Parciales. La Programación estructurada se concentra en las acciones que controlan el flujo de datos. Unidad I Conceptos Básicos de la Programación Orientada a Objetos 1.1 Paradigma de la Programación Orientada a Objetos Paradigma. Según el Diccionario de la Real Academia de la Lengua Española, paradigma

Más detalles

Módulo 2. Inicio con Java

Módulo 2. Inicio con Java Módulo 2. Inicio con Java Objetivos: -Clasificar el lenguaje de programación Java según las formas de clasificar los lenguajes de programación. -Describir el funcionamiento de la plataforma Java. -Explicar

Más detalles

TCP/IP. IRI 2 do cuatrimestre 2015

TCP/IP. IRI 2 do cuatrimestre 2015 TCP/IP IRI 2 do cuatrimestre 2015 Redes y Protocolos Una red es un conjunto de computadoras o dispositivos que pueden comunicarse a través de un medio de transmisión en una red. Los pedidos y datos de

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

Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co. Universidad Pedagógica y Tecnológica de Colombia. Colombia

Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co. Universidad Pedagógica y Tecnológica de Colombia. Colombia Facultad de Ingeniería ISSN: 0121-1129 revista.ingenieria@uptc.edu.co Universidad Pedagógica y Tecnológica de Colombia Colombia Amézquita-Mesa, Diego Germán; Amézquita-Becerra, Germán; Galindo-Parra, Omaira

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

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

Wireless Sensor Network in a nuclear facility: A technology aplication proposal

Wireless Sensor Network in a nuclear facility: A technology aplication proposal Wireless Sensor Network in a nuclear facility: A technology aplication proposal CNEA,IB (1) U. FASTA (2) Maciel, F. 1 - Fernández, R. O. 1 - Vilugron, R. M. 2 This work presents an overview of a pretended

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

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

Servicios avanzados de supercomputación para la ciència y la ingeniería

Servicios avanzados de supercomputación para la ciència y la ingeniería Servicios avanzados de supercomputación para la ciència y la ingeniería Servicios avanzados de supercomputación para la ciència y la ingeniería HPCNow! provee a sus clientes de la tecnología y soluciones

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

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

RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide

RODRIGO TAPIA SANTIS (rtapiasantis@gmail com) has a. non-transferable license to use this Student Guide Introducción Objetivos del Curso Al finalizar este curso, debería estar capacitado para: Instalar, crear y administrar Oracle Database 11g Versión 2 Configurar la base de datos para una aplicación Utilizar

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

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

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

Cloud Computing. Rodrigo Moreno Rosales DN-11

Cloud Computing. Rodrigo Moreno Rosales DN-11 Cloud Computing Rodrigo Moreno Rosales DN-11 Cloud Computing La computación en la nube,conocido también como servicios en la nube, informática en la nube, nube de cómputo o nube de conceptos, es un paradigma

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

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

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

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

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

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

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

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

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

CAPITULO 1 INTRODUCCIÓN

CAPITULO 1 INTRODUCCIÓN CAPITULO 1 INTRODUCCIÓN La seguridad en las redes de comunicaciones se ha convertido en un aspecto de importancia para los proveedores del Internet y para los clientes debido a la prioridad que ha tomado

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

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica.

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica. RAID Como se dijo anteriormente, el ritmo de mejora de prestaciones en memoria secundaria ha sido considerablemente menor que en procesadores y en memoria principal. Esta desigualdad ha hecho, quizás,

Más detalles

Análisis técnico de HP LoadRunner

Análisis técnico de HP LoadRunner Informe técnico Análisis técnico de HP LoadRunner Índice El contexto actual 2 Los límites de las pruebas manuales 2 Una nueva visión de las pruebas de rendimiento: HP LoadRunner 3 La solución y la terminología

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

Framework para el desarrollo ágil de aplicaciones

Framework para el desarrollo ágil de aplicaciones Framework para el desarrollo ágil de aplicaciones 1 Índice INTRODUCCIÓN... 3 QUÉ ES UN FRAMEWORK?... 3 VENTAJAS DE UTILIZAR UN FRAMEWORK... 4 DESVENTAJAS DE UTILIZAR UN FRAMEWORK... 5 CARACTERÍSTICAS DE

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberació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