Programa oficial de postgrado en Ciencias, Tecnolog´ıa y Computaci´on M´aster en Computaci´on Facultad de Ciencias - Universidad de Cantabria Trabajo de fin de M´aster Generacio´n de co´digo Ada para aplicaciones embebidas y de tiempo real desde modelos din´amicos UML Alejandro P´erez Ruiz [email protected] Tutor Julio Luis Medina Pasaje Grupo Computadores y Tiempo Real Dept. Electr´onica y Computadores Septiembre 2012 Curso 2011-12 ´ Indice general 1. Introduccio´n 1 1.1. Pre´ambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Motivaci´on: La necesidad de una nueva t´ecnica para generar c´odigo . . . . . 4 1.4. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Estado del arte y de la t´ecnica 7 2.1. Perfil MARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Modelado de Aplicaciones de Alto Nivel (HLAM) . . . . . . . . . . 9 2.2. Herramientas de modelado para la generacio´n de c´odigo . . . . . . . . . . . 11 2.2.1. Rational Software Architect . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Rational Software Rhapsody . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. BoUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4. Umbrello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.5. UML2Ada2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.6. WinA&D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.7. Sumario de herramientas analizadas . . . . . . . . . . . . . . . . . . 13 2.3. Transformaciones de modelo a texto . . . . . . . . . . . . . . . . . . . . . . 15 2.3.1. Acceleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.2. MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.3. Xpand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.4. JET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.5. Eleccio´n de herramienta . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Generaci´on de co´digo 19 3.1. Principios fundamentales del disen˜o . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1. Conceptos de ingenier´ıa de software que son soportados . . . . . . . 19 3.1.2. Creacio´n de modelos para la generacio´n de c´odigo . . . . . . . . . . 20 3.1.3. Modelos de alto nivel con el perfil MARTE . . . . . . . . . . . . . . 20 3.2. Modelo UML para la generacio´n de c´odigo . . . . . . . . . . . . . . . . . . . 21 3.2.1. Conceptos y elementos principales de los diagramas de clase en UML 21 3.2.2. Diagramas de actividad . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. Elementos de UML soportados . . . . . . . . . . . . . . . . . . . . . 24 I ´Indice general II 3.3. Transformaciones de UML a c´odigo Ada . . . . . . . . . . . . . . . . . . . . 25 3.3.1. Paquetes y Clases UML 2.0 en Ada 2005. . . . . . . . . . . . . . . . 25 3.3.2. Dependencias entre clases . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.3. Asociaci´on entre clases . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.5. Clases abstractas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.6. Elementos concurrentes y de tiempo real . . . . . . . . . . . . . . . . 31 3.3.7. Procedimiento principal . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.8. Comportamiento: Diagramas de actividad . . . . . . . . . . . . . . . 34 3.4. Implementaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4. Casos de estudio 37 4.1. Problema de la cena de los filo´sofos . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.1. Especificacio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.2. An´alisis de la aplicacio´n . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.1.3. Co´digo obtenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.2. Simulador l´ogico para circuitos combinacionales . . . . . . . . . . . . . . . . 40 4.2.1. Especificacio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.2. An´alisis de la aplicacio´n . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2.3. Co´digo obtenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5. Conclusiones y trabajos futuros 44 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A. Descripci´on de los contenidos del CD adjunto 46 Referencias 47 ´ Indice de figuras 1.1. Modelos y transformaciones usados en el contexto del trabajo. . . . . . . . . 3 2.1. Arquitectura del perfil MARTE. . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. RtUnit del paquete HLAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. PpUnit del paquete HLAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Resumen de herramientas analizadas. . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Representaci´on gra´fica en UML 2.0 de las distintas relaciones entre clases. . 23 3.2. Ejemplo de diagrama de actividad con sus principales elementos nombrados. 24 3.3. A´mbito de visibilidad en las diferentes partes de un paquete Ada. . . . . . . 26 3.4. Herencia entre clases contenidas en distintos paquetes. . . . . . . . . . . . . 27 3.5. Dependencia entre clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6. Asociaci´on entre clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.7. Ejemplo de clase activa en UML representando una tarea. . . . . . . . . . . 32 3.8. Arquitectura de los mo´dulos con la funcionalidad de sus plantillas internas. 36 4.1. Diagrama de clases para el problema de los filo´sofos. . . . . . . . . . . . . . 38 4.2. Diagrama de actividad asociado a la clase Fil´osofo. . . . . . . . . . . . . . . 39 4.3. Diagrama de clases para el simulador l´ogico de circuitos combinacionales. . 41 4.4. Diagrama de actividad para la operacio´n Opera de la clase Inversor. . . . . 42 III Cap´ıtulo 1 Introducci´on Esta memoria de Trabajo de Fin de M´aster muestra el desarrollo seguido para la cons- truccio´n deungenerador dec´odigo Adaparaaplicaciones embebidasy detiemporealdesde modelos dina´micos UML. Como parte de este trabajo se han definido una serie de pautas y herramientas que permiten guiar al usuario o modelador en el paso de disen˜o a implemen- taci´on en el marco de un proceso de desarrollo dirigido por modelos que utilice UML y el perfilMARTE pararealizar aplicaciones de tiempo real. Este cap´ıtulo introduceel contexto del trabajo y presenta el desarrollo dirigido por modelos en el ´ambito de los sistemas de tiempo real. As´ı mismo se describen las motivaciones, objetivos y el proceso seguido para llevar a cabo el desarrollo del proyecto. 1.1. Pre´ambulo Actualmente, los sistemas informa´ticos van aumentando su complejidad exponencial- mente. Se requieren tiempos de desarrollo de aplicaciones ma´s cortos y procesos mucho ma´s ´agiles. Por lo que el desarrollo dirigido por modelos [Sch06] es considerado progresivamente por la industria actual como uno de las mayores objetivos para la Ingenier´ıa del Software. Ayuda a crear y mantener los diferentes artefactos necesarios en todo proceso de desarrollo de software, adema´s de facilitar la separaci´on de los distintos mo´dulos, incrementando la eficiencia del proceso, y finalmente mejorando la calidad del software. Para las aplicaciones de tiempo real, una metodolog´ıa basada en modelos nos puede ayudar a simplificar el proceso de construcci´on de los modelos de comportamiento de ana´li- sis temporal. Estos modelos constituyen la base para el disen˜o de tiempo real y el proceso de ana´lisis de la planificabilidad. Con tal prop´osito, el disen˜ador debe generar, en sincron´ıa con los modelos usados para generar el c´odigo de aplicacio´n, un modelo adicional parame- trizable adecuado para la validacio´n temporal del sistema. El modelo de ana´lisis abstrae el comportamiento temporal de todas las acciones que realiza, e incluye los para´metros de planificaci´on, sincronizaci´on einformacio´n delos tiempos deejecuci´on delos recursosquees necesaria para predecir el comportamiento de tiempo real de las aplicaciones. En el enfoque que en este trabajo se presenta, estos modelos de ana´lisis son automa´ticamente derivados desdeunmodelodedisen˜odealto nivel,en el quetenemos anotadas unconjuntom´ınimode 1 1.2. Contexto 2 caracter´ısticas detiemporeal tomadas delos requisitos delaaplicacio´n enelentornorealen el que va a ser utilizada. De la misma forma en que se realiza la generacio´n del c´odigo de la aplicacio´n como unacomposicio´n del c´odigo de suspartes constitutivas, el modelocompleto de ana´lisis de tiempo real de la aplicacio´n tambi´en puede ser generado automa´ticamente a partir del conjunto de sub-modelos de tiempo real que lo componen. El esfuerzo de investigacio´n que se presenta en este trabajo considera la definici´on de los modelos de ana´lisis de planificabilidad como parte del conjunto de herramientas y t´ecni- cas utilizadas en el proceso de ingenier´ıa dirigido por modelos. A este nivel de abstrac- ci´on, el paradigma concreto de modelado utilizado para concebir y elaborar los sistemas no se especifica, pero a efectos pra´cticos se asume que es posible expresarlo mediante UML [OMG11b]. Este es un lenguaje de modelado de prop´osito general, con ´el utilizaremos la extensi´on esta´ndar para el modelado y ana´lisis de sistemas de tiempo real, el denominado perfil MARTE [OMG11a]. Elusodet´ecnicas dedesarrollodirigidas pormodeloimplica generalmente la generacio´n de c´odigo a partir de modelos estructurales como los diagramas de clases. Con estos auto- matismos para la generacio´n del c´odigo de las clases y paquetes que forman una aplicacio´n, es por lo general f´acil obtener su c´odigo estructural. Adem´as, a fin de facilitar la ingenier´ıa inversa se suelen utilizar comentarios codificados. Estos comentarios son colocados como marcas textuales que rodean las zonas del c´odigo generado que queden incompletas. Estas zonas sonhabitualmente escritas “amano” porlos programadores y correspondenal cuerpo de los paquetes o la descripci´on funcional de funciones y procedimientos, que especifican el comportamiento de las clases. Un paso ma´s en la generacio´n de c´odigo es la utilizacio´n de las ma´quinas de estados para obtener el comportamiento de las clases. E´sto utiliza las operaciones de las clases como mensajes de control que desencadenan los eventos entre los diferentes estados. De este modo los mensajes procedentes de otros objetos pueden interactuar con el auto´mata de la clase, desafortunadamente este tipo de generadores de c´odigo no es consistente con la descripci´on del escenario requerido para realizar el ana´lisis de planificabilidad, por lo que nos impedir´ıa tener una coherencia entre los modelos para la generacio´n de c´odigo y los destinados al comportamiento temporal de la aplicacio´n. Para este cometido los elementos de modelado adecuados son los diagramas de actividad, que son capaces de representar los flujos de ejecuci´on paso a paso para las operaciones que componen las clases. De este modo el presente trabajo constituye un avance en la metodolog´ıa de desarrollo dirigido por modelos para sistemas de tiempo real al definir e implementar un nuevo tipo de generador de c´odigo. Con ´el no solo se genera el cl´asico esqueleto de las clases y sus operaciones UML,sinoquesecompletan los cuerposdelas operaciones quetengan asociado un diagrama de actividad UML. En la siguiente seccio´n sedescribe el contexto en el quese desarrolla el presente trabajo. 1.2. Contexto El generador de c´odigo desarrollado en este trabajo es una parte constitutiva de una metodolog´ıa de desarrollo dirigida por modelos que permite realizar una ana´lisis temporal 1.2. Contexto 3 Figura 1.1: Modelos y transformaciones usados en el contexto del trabajo. de las aplicaciones generadas. Esta metodolog´ıa utiliza como lenguaje de modelado UML complementado con la extensi´on del perfil MARTE para el modelado y ana´lisis de los sistemas embebidos y de tiempo real. El uso de dicho perfil es necesario para permitirnos especificar las caracter´ısticas distintivas de los sistemas de tiempo real. De este modo en la figura 1.1 se ilustra esquema´ticamente el contexto donde se situ´a el trabajo. El modelo inicial usado para describir la aplicacio´n y sus caracter´ısticas de tiempo real se construye usando la extensi´on del perfil MARTE para el modelado de aplicaciones de alto nivel (High Level Application Modeling, HLAM). Desde este punto de partida se producen dos transformaciones modelo a modelo (model-to-model, M2M). La primera de ellas, M2M A, es usada para crear una representaci´on en UML del modelo de ana´lisis temporal. Para este modelo se utilizan las capacidades para el modelado del ana´lisis de la planificabilidad presentes en MARTE (SAM). La otra transformaci´on, M2M C, crea un modelo intermedio u´til para la generacio´n de c´odigo. Para esta metodolog´ıa el lenguaje objetivo para la implementaci´on es Ada, y el modelo intermedio, denominado UMLforCode enlafigura1.1, esunmodelot´ıpicoorientado aobjetosdeUMLquecontienelainformacio´n estructural y de comportamiento de la aplicacio´n. El comportamiento de las operaciones sera´ expresado mediante los diagramas de actividad presentes en UML. La transformaci´on de modelo a texto, llamada M2T M en la figura 1.1, es necesaria para generar el modelo final para el ana´lisis de la planificabilidad, y es parte de un trabajo realizado previamente [MC11], en el que se creo´ una herramienta [MC] para el entorno de desarrollo Eclipse para la generacio´n de los modelos de ana´lisis, la invocaci´on de las herramientas de ana´lisis y la recogida de resultados en el contexto de ana´lisis de modelado. Dicha herramienta convierte modelos SAM en formalismos utilizados por MAST [HGGM01] para recoger los resultados en el modelo UML+MARTE. Este trabajo presenta las t´ecnicas y la herramienta para generar la implementaci´on 1.3. Motivaci´on: La necesidad de una nueva t´ecnica para generar c´odigo 4 del c´odigo Ada desde el modelo gen´erico orientado a objetos denominado UMLforCode. Esta generacio´n se produce a trav´es de una transformaci´on modelo a texto (model-to- text) denominada ACG (Ada Code Generation) e ilustrada en la figura 1.1. El c´odigo obtenido tras aplicar las transformaciones M2M C y ACG es consistente sema´nticamente con los modelos generados a trav´es de las otras dos transformaciones M2M A y M2T M. Posteriormente, con el c´odigo Ada generado se obtendr´an los tiempos de ejecuci´on de peor caso (WCET) a trav´es de la instrumentaci´on del c´odigo, para ser recogidos luego en el modelo SAM y realizar el ana´lisis de la planificabilidad. Estos resultados son finalmente anotados en el modelo SAM e incluyen datos de configuraci´on de tiempo real tales como prioridades (o plazos relativos) para los elementos concurrentes, y techos de prioridad (o niveles de expulsio´n) para los recursos compartidos. Estos datos de planificaci´on, llamados Conf.enlafigura1.1,seincluyencomopartedelainformacio´ndeconfiguraci´onenelmodelo UMLforCode a fin de ser utilizados para la generacio´n del c´odigo final de la aplicacio´n. Enlasiguiente seccio´n sepasar´aadetallar cua´les hansidolas motivaciones pararealizar un generador de c´odigo basado en nuevas t´ecnicas para la obtencio´n de c´odigo. 1.3. Motivacio´n: La necesidad de una nueva t´ecnica para ge- nerar c´odigo Siguiendo trabajos anteriores que han estudiado el disen˜o de sistemas de tiempo real usando formalismo de orientaci´on a objetos, podemos observar que la mayor´ıa de ellos in- cluyen la especificacio´n de la concurrencia usando modelos estructurales, habitualmente a nivel de disen˜o para implementaci´on. Estos formalismos son utilizados con el objetivo de ayudarnos en la realizacio´n del ana´lisis de planificabilidad a trav´es de la especificacio´n de un modelo simple de tareas y el uso posterior de las t´ecnicas ba´sicas de RMA [KRP+93]. Desafortunadamente, lacomplejidad delos mecanismos usadosparalageneracio´n dec´odigo hace que esta asunci´on no sea realista. Algunos ejemplos de metodolog´ıas que utilizan esta estrategia son ROOM[SGW94] [Sel98],Octopus/UML [EDZ99], ACCORD/UML [LGT98], Comet [Gom00] o los modelos de disen˜o limitados y monol´ıticos como HRT-HOOD [BW94] y OO-HARTS [MDN+03]. En la mayor´ıa de los casos el c´odigo generado corresponde sim- plemente a la descomposicio´n modular en clases y m´etodos, dejando demarcado mediante comentarios espec´ıficos el espacio para introducir el c´odigo funcional de cada m´etodo, o generando este u´ltimo mediante ma´quinas de estado. Ensayando una suertede sincretismo de estas metodolog´ıas mencionadas, y con el fin de facilitar la aplicacio´n de t´ecnicas sencillas de ana´lisis de planificabilidad, las construcciones de alto nivel para el modelado de aplicaciones en MARTE (HLAM) tambi´en facilitan el uso de modelos estructurales para la especificacio´n de la concurrencia. Sin embargo, las interacciones entre ellos (incluyendo la distribuci´on) pueden tomar patrones complejos que requieren un modelo ma´s rico para el ana´lisis. Las t´ecnicas de ana´lisis basadas en offsets se adaptanmejoraestosescenariosqueelmodelosimpledetareas.HLAMproponedosbloques de construcci´on ba´sicos, la unidad de tiempo real: RtUnit y la unidad pasiva protegida: PpUnit. En cuanto al comportamiento que define el c´odigo (el c´odigo que se encuentra dentro de las marcas o comentarios), debido a su complejidad natural, no es por lo general 1.4. Objetivo 5 solo c´odigo lineal pasivo quepuedeser modeladocomo unc´alculo detiempocomputacional, sinoqueincluyeretardos einteracciones expl´ıcitas entre objetos y nodos,sobretodocuando se convierten en parte de operaciones distribuidas (modelos de comportamiento). En estos casos, una ma´quina de estados no es directamente transformable en un modelo de ana´lisis. Desde la perspectivadeana´lisis, los modelos queson requeridos paraaplicar las t´ecnicas basadasenoffsets,sonfundamentalmenteescenarios.Unescenarioesunaexpresio´ndelpeor caso esperado para el disen˜o dado. Este es el principio fundamental empleado para tratar con la complejidad que distingue a las t´ecnicas de ana´lisis de planificabilidad basadas en RMA de otras estrategias basadas en auto´matas de tiempo o lenguajes s´ıncronos. Como lenguaje de modelado para este dominio, la seccio´n de modelado de ana´lisis de planificabilidad de MARTE (SAM) sirve para expresar este tipo de escenarios, y por lo tanto, es un formalismo adecuado para utilizar con las correspondientes herramientas de ana´lisis. Desafortunadamente estos escenarios no son necesariamente parte inicial de la especificacio´n del comportamiento del sistema. Son un medio para expresar: los est´ımulos previstos,lacargadetrabajodealtonivelylosrequerimientostemporales,peronosuelenser los datos ba´sicos utilizados para el prop´osito del disen˜o o la generacio´n de c´odigo elaborada por los disen˜adores. La creacio´n de estos modelos de ana´lisis orientados a escenarios (habitualmente el peor caso) en consonancia con el c´odigo final es en realidad el objetivo principal y una alta responsabilidad de los disen˜adores de tiempo real. Con el fin de ayudar en esta labor las herramientasnecesitanquedelmodelousadoparalageneracio´ndec´odigosepuedanobtener los comportamientos de las operaciones expresadas en los escenarios. Por esta razo´n los modelos de entrada adecuados para la generacio´n de c´odigo dentro de las operaciones en el modelo UMLforCode son los diagramas de actividad de UML. De este modo se tienen estructuras similares en ambos modelos y los modelos de ana´lisis pueden ser caracterizados con sus tiempos de ejecuci´on de peor caso instrumentando y estudiando el c´odigo final generado. La siguiente seccio´n describe los objetivos que se han propuesto para el desarrollo de este trabajo de fin de ma´ster. 1.4. Objetivo Como se ha comentado en la seccio´n 1.2 estamos inmersos en un contexto de trabajo compuesto por diferentes metodolog´ıas y transformaciones por definir e implementar. De tal modo que se plantea como objetivo para el presente trabajo realizar una contribuci´on significativa en el contexto descrito en dicha seccio´n. El objetivo concreto de este proyecto es crear un generador de c´odigo Ada con las siguientes caracter´ısticas: 1. Capaz de generar el c´odigo estructural de una aplicacio´n a trav´es de diagramas de clases UML. 2. Poder generar la implementaci´on de las operaciones de las clases que tengan asociado un modelo de actividad UML. 1.4. Objetivo 6 3. Con la ayuda del perfil MARTE y el sub-perfil HLAM ser capaz de identificar en el modelo de entrada los elementos ba´sicos de la programaci´on concurrente tales como tareas y objetos protegidos. 4. Generar c´odigo que nos permita obtener su modelo de ana´lisis temporal. Cuando se plantean los objetivos anteriores para crear un generador de c´odigo en el ´ambito de los sistemas de tiempo real, nace la necesidad de especificar modelos descritos como escenariospararealizarelana´lisisdelaplanificabilidaddelsistemaquesedisen˜a.Lacreacio´n de estos escenarios (habitualmente el peor caso) orientados al ana´lisis, nos lleva a realizar la definici´on de ´estos a trav´es de los diagramas de actividad, los cuales describen el flujo de trabajo de las operaciones. El tener la descripci´on funcional de cada operacio´n mediante diagramas de actividad facilitar´a ma´s adelante instrumentar el c´odigo de forma automa´tica para medir sus tiempos de ejecuci´on. Para satisfacer dichos objetivos, se realizaron las tareas que se describena continuacio´n: 1. Estado del arte: El objetivo de esta fase es adquirir los conceptos necesarios para la realizacio´n del proyecto, ma´s concretamente, familiarizarse con el perfil MARTE y el sub-perfilHLAM. Dentro de esta fase tambi´en se incluye un estudio de las principales metodolog´ıas, t´ecnicas y herramientas que permiten generar c´odigo para sistemas de tiempo real. 2. Desarrollo: En esta etapa del trabajo se han desarrollado una serie de transforma- ciones para trasladar los elementos ba´sicos de los diagramas de clases descritos en UML y en el sub-perfil HLAM a c´odigo Ada. Para esta labor se ha utilizado el plugin paraEclipsedenominadoAcceleo [Obe]queimplementael esta´ndardelaOMG,MOF Model to Text Language (MTL) [OMG08],y que permite crear generadores de c´odigo para cualquier metamodelo dado. 3. Validaci´on a trav´es de casos de estudio: En esta fase se analizara´ el generador de c´odigo a trav´es de dos casos de uso, el primero de ellos nos permitir´a verificar los elementos destinados a gestionar sistemas concurrentes, y el segundo utilizara´ las caracter´ısticas ba´sicas de la orientaci´on a objetos. Estas tareas se reportan en la memoria en los cap´ıtulos 2, 3 y 4 respectivamente. En el siguiente cap´ıtulo se realiza un estudio del estado del arte, se presentan conceptos clave mencionados aqu´ı y se comparan las distintas herramientas que existen actualmente para la generacio´n de c´odigo de sistemas de tiempo real.