Generador de código C eficiente y orientado a objetos desde diagramas UML

[Jonathan Marino]

Hola,

Les cuento el trabajo de tesis para Ing. Informática con el que estoy trabajando y que espero le sea muy útil a la comunidad de embebidos y para el proyecto CIAA en particular.

Va estar para fin de año y espero sugerencias.

Se trata de un generador de código C orientado a objetosy para sistemas embebidos. En la codificación del mismo me base en el trabajo de Axel Tobias Schreiner: " Object Oriented Programming with ANSI", el trabajo es muy bueno pero muy poco performante para sistemas embebidos, así que introduje grandes cambios en la forma de codificar, basado también en otros trabajos y en parte inspiración mía y se mostrará en mi trabajo cómo esos cambios mejoran sustancialmente la performance.

Este código permite trabajar con los conceptos de herencia, polimorfismo, clases, interfaces, visibilidad pública protegida y privada y otros. Además algo que no he visto en ningún compilador de un lenguaje -orientado a objetos como C++ es poder inicializar un objeto en ROM (obviamente pudiendo llamar solo a métodos constantes), esta forma de codificar en C si lo permite llevando el diseño orientado a objetos puro (con herencia y polimorfismo) a contextos nunca vistos.

Un punto siempre encontra de trabajar en forma orientada a objetos en C es tener que lidiar con un montón de overhead e inicializar correctamente un montón de punteros a funciones que es muy propenso a errores.

La forma habitual de enfrentar esto ha sido o aceptarlo así y codificar todo a mano o tener un preprocesador como Schreiner propone, la desventaja obvia de esto es que se está introduciendo casi un lenguaje nuevo desconocido por todos (hay que capacitar gente) y que no es entendido por nuestro IDE.

Mi propuesta es usar modelos UML (que es un lenguaje estándar) y a partir de allí crear los archivos .c y .h (entendidos por cualquier IDE) dejando luego para el programador tan solo codificar los cuerpos de los métodos.

Ahí termina mi trabajo junto con una corrida en la EDU-CIAA de una aplicación de ejemplo (Quizás simular un controlador con distintos tipos de sensores y salidas)

Quiero agregar que pasar a trabajar en forma MDD (model driven development) va a ser un cambio gigante para la comunidad de embebidos, además de por todo lo bueno que tiene trabajar con modelos, porque esos diagramas uml se van a poder utilizar con otras herramientas que por ejemplo hagan verificaciones o puedan diseñar y generar las pruebas unitarias y funcionales. En un futuro el modelado va a poder cubrir casi toda la codificacion recurriendo quizas a extensiones de UML como MARTE. Además es parte esencial de muchos procesos de desarrollo para sistemas embebidos como Harmony de IBM.

Bueno quiero saber qué les parece esta propuesta y que tienen para sugerirme,

Saludos,

Jonathan Marino

[Mariano Cerdeiro]

Hola Jonathan,

la verdad no entiendo del todo pero intento contestar. No se cual seria la diferencia entre C orientado a objetos y C++. Y si se genera un C orientado a objetos en base a otro lenguaje da igual si es C o C++. Cual es la ventaja de que sea orientado a objetos o no si es igualmetne generado? Osea si alguien generac codigo cua es la ventaja de generar C orientado a objetos o generar C o generar C++, no se si sentiende mi duda.

Que significa que el trabajo de Schreiner sea poco performante? en que se mide esto y que se quiere mejorar?

Respecto a

>. Además algo que no he visto en ningún compilador de un lenguaje -orientado a objetos como C++ es poder inicializar un objeto en ROM (obviamente pudiendo llamar solo a métodos constantes), esta forma de codificar en C si lo permite llevando el diseño orientado a objetos puro (con herencia y polimorfismo) a contextos nunca vistos.

no soy experto en C++ pero no entinedo por que un buen compilador no lo podria hacer.

> Un punto siempre encontra de trabajar en forma orientada a objetos en C es tener que lidiar con un montón de overhead e inicializar correctamente un montón de punteros a funciones que es muy propenso a errores.

No entiendo esta frase. A mi no se me ocurriria trabajar en C simulando objetos, para eso lo haria en c++. A menos que quieras crear un c++ propio no veo el valor agregado.

> Mi propuesta es usar modelos UML (que es un lenguaje estándar) y a partir de allí crear los archivos .c y .h (entendidos por cualquier IDE) dejando luego para el programador tan solo codificar los cuerpos de los métodos.

Ahora si tu propuesta es trabajar en UML que importa si el codigo generado es c o c++ ú otra cosa? Al fin y al cabo es codigo generado. que ventaja tiene que sea generado en c orientado a objetos en c o c++ (diferencio c++ y c orientado a objetos por que vos lo haces, no se si hay una diferencia en tu nomeclatura)

> Quiero agregar que pasar a trabajar en forma MDD (model driven development) va a ser un cambio gigante para la comunidad de embebidos, además de por todo lo bueno que tiene trabajar con modelos, porque esos diagramas uml se van a poder utilizar con otras herramientas que por ejemplo hagan verificaciones o puedan diseñar y generar las pruebas unitarias y funcionales.

Bueno esto no se si es correcto. Yo programo a mano, pero en SE ya existe MUCHISIMA programacion en base a modelos matemáticos, matlab, simulink, uml. Osea esto existe y muchisima gente lo usa. Por eso no me parece que sea un gran cambio. pero quizas me pierdo algo... :(

Yo creo que estas perdiendo un problema de lado y es la dependencia. Cuando empezas a usar uml, un software de modelado te estas casi siempre casando con un tool. por ejemplo con matlab y simulink. Y esto te generea una GRAN dependencia a largo plazo. Si trabajas en uml uno podria pensar que no, pero por lo general los sw BUENOS BUENOS de UML no son gratis, asique estas tambien dependiendo de alguien. No se si hay un formato estandar de UML de intercambio soportado por todos los SWs, pero tenemos expertos en la lista que seguro lo saben. :)

Con C tenes la ventaja de ser un standard y poder compilar con cualquier compilador hoy o en 10 anios. :) Trabaje con Rational y con otros tooles geniales y muchisimos te generan una dependencia que uno luego tiene que pensar en serio si quiere crearce esa dependencia.

Para no mal entender, me parece genial que quieras hacer la tesis en base a la CIAA y siempre suma. No termino de tender todos los puntos y no termino de ver lo novedoso. Tampoco entiendo que se empieza habalndo de C orientado a objetos y al final esto no importa ya que se genera en base a UML, osea lo importante es el UML y no el codigo generado. ya que como usario final me importa poco si se genera c++ o c. Va importante seria que se genere codigo conforme a un standard c90 por ejemplo y si quiero alguna certificaciond que el generador la cumpla. Se se pueda testear en model in de loop, software in de loop (MIL, SIL, PIL, HIL) y etc.

Saludos.

Mariano.-

--
Has recibido este mensaje porque estás suscrito al grupo "CIAA-Firmware" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ciaa-firmwar...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/ciaa-firmware.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Eric Pernia]

Buenas noches Jonathan, me parece muy interesante tu proyecto. ¿En qué lenguaje planeas realizar toda la interfaz gráfica para dibujar los UML? Yo realicé el software gráfico de Ladder que convierte del lenguaje Ladder a código C y se monta sobre el Firmware de la CIAA. Desde el Ladder se genera en C el programa de usuario y las tareas del RTOS, luego utiliza las herramientas que utiliza la CIAA para compilar y descargar (arm-none-eabi-gcc y openOCD). Así que si es algo similar podría darte una mano. Mi desarrollo está realizado sobre Pharo3.0-Smalltalk.

Al igual que Mariano me surjen muchas dudas sobre que diferencias existen entre C orientado a objetos y el C++ que todos conocemos. Tambien tené en cuenta que si pensas montarte sobre el Firmware de la CIAA no recomendamos el uso de memoria dinámica ya que tiene un impacto muy negativo en la predictibiliad del comportamiento del sistema y acá es cuando objetos no se lleva muy bien con esa idea ya que utiliza memoria dinámica. La única manera de evitar esto es no creando objetos en tiempo de ejecución. El Sistema Operativo de Tiempo Real de la CIAA (FreeOSEK) es estático.

Por otro lado estoy trabajando en una adaptación de una VM de Java para la CIAA ya teniendo funcionando la misma para apliaciones normales y ahora trabajando con la especificación SCJ (Safety Critical specification for Java) que permite con ciertas restricciones del Java que uno conoce de la PC y agregando algunos conceptos trabajar en aplicaciones industriales con sistemas criticos y tiempo real con programas realizados en este lenguaje. Esta VM que no la progamé yo sino que realicé el port de la misma a la CIAA junto a Leo Gassman que trabaja conmigo se basa en un pluguin de eclipse que convierte a C el programa Java de usuario y además agrega la VM implementada también en C para luego permitir al igual que el soft de PLC compilar y descargar con las herramientas de la CIAA. Este soft no utiliza por el momento el Firmware de la CIAA sino que se monta directo sobre el hardware debido a que la VM tiene su propio scheduler para manejo de tareas haciendo dificil la compatibilidad con FreeOSEK. Este trabajo combina Java y C.

Saludos.

Eric.

--

[Eric Pernia]

Ojo con eso porque la flash tiene una cantidad de ecturas y escrituras. Si tenes un programa que maneja creación y destrucción de objetos en flash entonces puede ser bastantedestructivo para esa memoria del micro.

Saludos.

Eric.

El 7 de septiembre de 2015, 10:07, Jonathan Marino <jonym...@gmail.com> escribió:

Gracias Eric,

muy interesante los trabajos en los que estás trabajando.

La parte gráfica no necesité desarrollarla, cualquier editor UML que genere un .uml o un .xmi puede usarse para luego generar el código con mi herramienta. Mi preferido es Papyrus.

C orientado a objetos utiliza la sintaxis de C, no es un lenguaje nuevo, pero involucra cierta disciplina para contener oo en el código que se ajuste a sus reglas.

Los objetos pueden crearse en cualquier tipo de memoria.

Saludos,

Jonathan

[Jonathan Marino]

Me di cuenta que no mande esta respuesta al grupo.

La reenvio

---------- Mensaje reenviado ----------
De: Jonathan Marino <jonym...@gmail.com>
Fecha: 3 de septiembre de 2015, 17:27
Asunto: Re: [CIAA-Firmware] Generador de código C eficiente y orientado a objetos desde diagramas UML
Para: mcer...@gmail.com

Muchas Gracias Mariano por tus preguntas,

paso a contestar entre lineas

El 3 de septiembre de 2015, 16:47, Mariano Cerdeiro <mcer...@gmail.com> escribió:

Hola Jonathan,

la verdad no entiendo del todo pero intento contestar. No se cual seria la diferencia entre C orientado a objetos y C++. Y si se genera un C orientado a objetos en base a otro lenguaje da igual si es C o C++. Cual es la ventaja de que sea orientado a objetos o no si es igualmetne generado? Osea si alguien generac codigo cua es la ventaja de generar C orientado a objetos o generar C o generar C++, no se si sentiende mi duda.

El valor agregado del trabajo es para los sistemas embebidos en C (qué según un autor que leí es un 80% de los sistemas de este tipo). Por lo tanto el código generado es C. La ventaja de que sea orientado a objetos es que uno pueda hacer un DOO diseño orientado a objetos para resolver la problemática para la que se diseña el sistema.

Que significa que el trabajo de Schreiner sea poco performante? en que se mide esto y que se quiere mejorar?

En memoria RAM utilizada y en tiempo de ejecución. Esto se quiere mejorar en la forma de programar orientado a objetos en C

Respecto a

>. Además algo que no he visto en ningún compilador de un lenguaje -orientado a objetos como C++ es poder inicializar un objeto en ROM (obviamente pudiendo llamar solo a métodos constantes), esta forma de codificar en C si lo permite llevando el diseño orientado a objetos puro (con herencia y polimorfismo) a contextos nunca vistos.

no soy experto en C++ pero no entinedo por que un buen compilador no lo podria hacer.

Tranquilamente podria hacerlo pero no encontréalguno que lo haga, si alguien conoce alguno sería bueno que lo comparta 

> Un punto siempre encontra de trabajar en forma orientada a objetos en C es tener que lidiar con un montón de overhead e inicializar correctamente un montón de punteros a funciones que es muy propenso a errores.

No entiendo esta frase. A mi no se me ocurriria trabajar en C simulando objetos, para eso lo haria en c++. A menos que quieras crear un c++ propio no veo el valor agregado.

Contesté en el primer punto, no es para quien se decidió a trabajar en C++. Respecto de la contra de la orientación a objetos en C te sugiero leer el link que pase o hechale una mirada a esta critica del libro que encontre: http://cboard.cprogramming.com/c-programming/128610-object-oriented-c.html. Con overhead me refiero a tener que codificar mucho para tener un concepto que en C++ por ejemplo se obtendria escribiendo un punto o directamente es implícito.

> Mi propuesta es usar modelos UML (que es un lenguaje estándar) y a partir de allí crear los archivos .c y .h (entendidos por cualquier IDE) dejando luego para el programador tan solo codificar los cuerpos de los métodos.

Ahora si tu propuesta es trabajar en UML que importa si el codigo generado es c o c++ ú otra cosa? Al fin y al cabo es codigo generado. que ventaja tiene que sea generado en c orientado a objetos en c o c++ (diferencio c++ y c orientado a objetos por que vos lo haces, no se si hay una diferencia en tu nomeclatura)

Claro eso es lo bueno de los modelos el día de mañana los podes usar en cualquier otro contexto como ser no usar C y pasar a C++ o Java. 

Pero hay algo que no estas tomando en cuenta, hoy día si haces un modelo orientado a objetos para un sistema codificado en C++, no vas a tener una herramienta que lo pueda codificar correctamente en C (cómo va a manejar la herencia o el polimorfismo)

La ventaja de la generación de código automática es como dije, sacar de la carga del programador todo el overhead y la inicialización de punteros

> Quiero agregar que pasar a trabajar en forma MDD (model driven development) va a ser un cambio gigante para la comunidad de embebidos, además de por todo lo bueno que tiene trabajar con modelos, porque esos diagramas uml se van a poder utilizar con otras herramientas que por ejemplo hagan verificaciones o puedan diseñar y generar las pruebas unitarias y funcionales.

Bueno esto no se si es correcto. Yo programo a mano, pero en SE ya existe MUCHISIMA programacion en base a modelos matemáticos, matlab, simulink, uml. Osea esto existe y muchisima gente lo usa. Por eso no me parece que sea un gran cambio. pero quizas me pierdo algo... :(

Si, reconozco que hay muchisima, pero mi intención era de que estoy poniendo un granito de arena para que se utilice más, sobretodo en los programadores C para ssee. 

Yo creo que estas perdiendo un problema de lado y es la dependencia. Cuando empezas a usar uml, un software de modelado te estas casi siempre casando con un tool. por ejemplo con matlab y simulink. Y esto te generea una GRAN dependencia a largo plazo. Si trabajas en uml uno podria pensar que no, pero por lo general los sw BUENOS BUENOS de UML no son gratis, asique estas tambien dependiendo de alguien. No se si hay un formato estandar de UML de intercambio soportado por todos los SWs, pero tenemos expertos en la lista que seguro lo saben. :)

Todo el trabajo estará en eclipse bajo herramientas estandard, para UML podes utilizar papyrus, es todo libre y gratuito

Con C tenes la ventaja de ser un standard y poder compilar con cualquier compilador hoy o en 10 anios. :) Trabaje con Rational y con otros tooles geniales y muchisimos te generan una dependencia que uno luego tiene que pensar en serio si quiere crearce esa dependencia.

Yo trabaje también mucho con Rational Rhapsody y esos años de trabajo son en parte inspiración para mi tesis.

Para no mal entender, me parece genial que quieras hacer la tesis en base a la CIAA y siempre suma. No termino de tender todos los puntos y no termino de ver lo novedoso. Tampoco entiendo que se empieza habalndo de C orientado a objetos y al final esto no importa ya que se genera en base a UML, osea lo importante es el UML y no el codigo generado. ya que como usario final me importa poco si se genera c++ o c. Va importante seria que se genere codigo conforme a un standard c90 por ejemplo y si quiero alguna certificaciond que el generador la cumpla. Se se pueda testear en model in de loop, software in de loop (MIL, SIL, PIL, HIL) y etc.

Saludos.

Mariano.-

Gracias,

re preguntame lo que no eme haya expresado correctamente.

[Jonathan Marino]

Me di cuenta que no mande tampoco esta respuesta al grupo.

La reenvio

---------- Mensaje reenviado ----------
De: Jonathan Marino <jonym...@gmail.com>

Fecha: 4 de septiembre de 2015, 12:14

Asunto: Re: [CIAA-Firmware] Generador de código C eficiente y orientado a objetos desde diagramas UML

Para: martin ribelotta <martinr...@gmail.com>

Muchas Gracias Martin,

cada uno que contesta me agrega algo, con Mariano me dicuenta que tengo que destacar que un modelo para C++ puede utilizarse para C con esto.

Vos me aclaras que tenia un compilador C++ "trucho" jeje y que estaba sacando una conclución incorrecta.

Quiero aclarar un poco donde esta el valor agregado de mi tesis:

Ya existen herramientas libres y gratuitas para generar desde diagramas UML código C, pero lo que no soportan es representar herencia y visibilidad de atributos, ni distintas herramientas cómunes en otros LOO como preguntar isOf, ni permitir distintos "flavors" de codificación orientada a objetos, se ve claro en lo que dije anteriormente, con esto podes utilizar un modelo pensado para C++ y generar un C entendible. Lo más cerca a esto lo vi en Rhapsody, que permite definir una interfaz para que de ahi implementen clases, pero es mucho más limitado a lo que estoy haciendo respecto a oo por ejemplo no permite que una clase herede de la otra o que una interfaz especialice a otra.

Te contesto abajo

El 3 de septiembre de 2015, 17:30, martin ribelotta <martinr...@gmail.com> escribió:

El 3 de septiembre de 2015, 15:22, Jonathan Marino <jonym...@gmail.com> escribió:

Hola,

Les cuento el trabajo de tesis para Ing. Informática con el que estoy trabajando y que espero le sea muy útil a la comunidad de embebidos y para el proyecto CIAA en particular.

Va estar para fin de año y espero sugerencias.

Si queres anda publicando el código y lo vamos viendo. Obviamente no vamos a intervenir en tesis pero estaría bueno poder dar una opinión hablando en lineas de código en vez de conceptos abstractos.

Ok, voy a ir publicando ejemplos del código generado 

 

Se trata de un generador de código C orientado a objetosy para sistemas embebidos. En la codificación del mismo me base en el trabajo de Axel Tobias Schreiner: " Object Oriented Programming with ANSI", el trabajo es muy bueno pero muy poco performante para sistemas embebidos, así que introduje grandes cambios en la forma de codificar, basado también en otros trabajos y en parte inspiración mía y se mostrará en mi trabajo cómo esos cambios mejoran sustancialmente la performance.

Ese paper fue el que dio origen a GTK y a GNOME. Es muy bueno, muy viejo y bastante probado.

No sabia que fue el origen de GTK, si se que tiene un oo en C. 

 

Este código permite trabajar con los conceptos de herencia, polimorfismo, clases, interfaces, visibilidad pública protegida y privada y otros. Además algo que no he visto en ningún compilador de un lenguaje -orientado a objetos como C++ es poder inicializar un objeto en ROM (obviamente pudiendo llamar solo a métodos constantes), esta forma de codificar en C si lo permite llevando el diseño orientado a objetos puro (con herencia y polimorfismo) a contextos nunca vistos.

Eso no es así para nada. Yo trabajo asiduamente en C++ y todos los objetos const son rommables. Incluso las vtables de C++ son rommables. Al menos que el compilador sea una bosta (como me pasó con algunos compiladores para PIC, que tambien son una bosta)

¿Que parte de un objeto const no seria rommable?

Muchas Gracias!! Entonces no hay diferencia alli, yo tambien "rommeo" la vtable y el objeto. (Aunque se permite una vtable en RAM que da flexibilidad para otras cosas)

 

Un punto siempre encontra de trabajar en forma orientada a objetos en C es tener que lidiar con un montón de overhead e inicializar correctamente un montón de punteros a funciones que es muy propenso a errores.

La forma habitual de enfrentar esto ha sido o aceptarlo así y codificar todo a mano o tener un preprocesador como Schreiner propone, la desventaja obvia de esto es que se está introduciendo casi un lenguaje nuevo desconocido por todos (hay que capacitar gente) y que no es entendido por nuestro IDE.

Mira, ya hace mucho tiempo existen cosas embebidas orientadas a objetos como el framework RKH:

http://rkh-reactivesys.sourceforge.net/

De un asiduo de emb32@ o QP de Quantum Leap (que hasta tienen un paper similar al original que mencionas vos pero orientado a embedded)

Si, se que hace tiempo existen, a veces me siento mal de haber esperado hasta ahora para comenzar la tesis cuando desde el 2006 que tengo la idea, pero por ahora veo el valor agregado en ella como explique arriba. Decime algunas de las herramientas que conoces permiten pasar de un diagrama de clases completo con herencia a código C? Permiten flexibilizar esa generación? 

 

Mi propuesta es usar modelos UML (que es un lenguaje estándar) y a partir de allí crear los archivos .c y .h (entendidos por cualquier IDE) dejando luego para el programador tan solo codificar los cuerpos de los métodos.

¿Que editor de UML usas???? Todos los que conosco open source son horrendos. Eclipse tiene muy buenos framework para UML pero nada terminado.

para UML uso papyrus, lo veo bastante maduro. El editor UML de eclipse esta bien pero no graficas nada

 

Ahí termina mi trabajo junto con una corrida en la EDU-CIAA de una aplicación de ejemplo (Quizás simular un controlador con distintos tipos de sensores y salidas)

Quiero agregar que pasar a trabajar en forma MDD (model driven development) va a ser un cambio gigante para la comunidad de embebidos, además de por todo lo bueno que tiene trabajar con modelos, porque esos diagramas uml se van a poder utilizar con otras herramientas que por ejemplo hagan verificaciones o puedan diseñar y generar las pruebas unitarias y funcionales. En un futuro el modelado va a poder cubrir casi toda la codificacion recurriendo quizas a extensiones de UML como MARTE. Además es parte esencial de muchos procesos de desarrollo para sistemas embebidos como Harmony de IBM.

MDD se viene usando en embebidos desde que se invento el concepto. De hecho, una rapida busueda en google te saca cientos de papers y herramientas (mayormnte propietarias) donde te lo venden como la panacea.

Otra cosa es que la mayoria de la gente no lo use, porque no le conviene, porque no lo conoce o porque no le soluciona nada.

De hecho, Lea Francucci tiene escrito de eso mucho:

http://embedded-exploited.blogspot.com.ar/

 Bueno, creo que con este aporte y otros inmediatos que deberían seguir luego de él debería llevar a un uso mucho mayor de estas herramientas, además de que es todo libre y gratuito.

 

Bueno quiero saber qué les parece esta propuesta y que tienen para sugerirme,

Saludos,

Jonathan Marino

Esperamos tus comentarios. Parece muy interesante el asunto pero me gustaría ver código para opinar mas concretamente. 

Gracias Martín 

[Jonathan Marino]

Me di cuenta que no mande tampoco esta respuesta al grupo.

La reenvio

---------- Mensaje reenviado ----------
De: Jonathan Marino <jonym...@gmail.com>

Fecha: 7 de septiembre de 2015, 10:07

Asunto: Re: [CIAA-Firmware] Generador de código C eficiente y orientado a objetos desde diagramas UML

Para: Eric Pernia <ericp...@gmail.com>

Gracias Eric,

muy interesante los trabajos en los que estás trabajando.

La parte gráfica no necesité desarrollarla, cualquier editor UML que genere un .uml o un .xmi puede usarse para luego generar el código con mi herramienta. Mi preferido es Papyrus.

C orientado a objetos utiliza la sintaxis de C, no es un lenguaje nuevo, pero involucra cierta disciplina para contener oo en el código que se ajuste a sus reglas.

Los objetos pueden crearse en cualquier tipo de memoria.

Saludos,

Jonathan

El 7 de septiembre de 2015, 1:37, Eric Pernia <ericp...@gmail.com> escribió:

[Mariano Cerdeiro]

Hola Jonathan,

luego de los mails entiendo qeu tu primer mail no era del todo claro. osea el C++ o a obejtos no era lo importante de tu tesis, ya qeu eso es el resultado. lo importante es que generas en base a UML.

Te diria que hables con Leandro en copia que el tiene un generador qeu hace algo parecido a lo que vos queres:
http://sourceforge.net/u/vortextech/profile/

no se si es solo basado en statemachine o tambien uml en general.

el seguro te puede ayudar mas.

saludos.

Mariano.-

[Jonathan Marino]

Hola Mariano,

Gracias por tu mail.

La parte de cómo codificar la orientación a objetos a lenguaje C es una parte esencial en el proyecto ya que justamente es lo que se genera en base al UML. Hay que estudiar y analizar qué codificación/es usar.

El trabajo de Leandro lo vi por arriba hace un tiempo, pero por lo que tengo entendido está orientado a la parte del comportamiento del sistema representado en statecharts. Le pregunto por aca si posee también algún diagrama estructural.

Mi trabajo se centra en la estructura del sistema representado en diagramas de clase.

Son dos partes distintas complementarias en la representación de un sistema. 

Los diagramas de clase juegan un rol muy importante en el diseño de un sistema embebido oo. La mayoría de los patrones de diseño en "Design patterns for embedded systems in C", un libro de Bruce Powel Douglass, están representados en diagramas de clase.

Saludos,

Jonathan

[Mariano Cerdeiro]

Hola Jonathan,

la pregunta es en donde esta el valor agregado. yo personalmente no veo ventaja en usar c oo compardo a usar c o c++. casi que personalmente me tiraria al c o al c++.

yo creo lo bueno de lo que haces es uml. el resto yo personalmente no le veo la ventaja. no me veo eligiendo un generador por que genere codigo c oo mejor de lo que un compilador lo haria con codigo progamado en c++.

Saludos.

mariano.-

[martin ribelotta]

Coincido con Mariano en este caso. Codigo C OO se viene usando desde antes incluso de que existiera el paper al que haces alución en tu primer mail (el que digo que dio origen a GTK, gnome y olvide mencionar que sale de gimp)

Por eso, yo te recomendaria que te centres en el generador de codigo y la interfaz grafica. En todo caso, se pueden mencionar los patrones de diseño que se usan y hacer referencia a donde provienen (es tentador pensar que hay patrones nuevos, pero en el 99% de los casos son solo variaciones de patrones ya conocidos y documentados)

Por el tema de C++, cada vez se usa mas en embebidos a medida que van surgiendo mejores compiladores (gcc hace todo lo que pedis anteriormente y optimiza a extremos que un humano no podria) y mas compatibles con el estandar (el problema de C++ es que es un estandar muy grande y hay casos borde donde los compiladores, el estandar y las implementaciones difieren)

[Jonathan Marino]

Gracias Mariano y Martín,

Ya sé que hay trabajos ya realizados. Ahora los que menciona Martín no fueron pensados para sistemas embebidos. Cuando yo empecé a utilizarlo introduje varias optimizaciones que me parecen una parte importante explicarlas en la tesis. Los trabajos que vi orientados a objetos para sistemas embebidos como el de samek o el de leandro le falta varias de las cosas que tienen los trabajos anteriores. Hay también optimizaciones que pienso hacer a través de indicaciones en los diagramas, tendría que analizar si sería posible hacerlas en C++ porque son un poco extrañas a la oo.

Además de optimizaciones se me ha ocurrido una forma de implementar la visibilidad de atributos que no lo vi en ningún trabajo.

Todo esto entiendo que es propio de una tesis, hay que presentarlo, correrlo en pruebas y comparar y ver que tan bueno es.

Si hiciese un generador de código uml que hiciera tan solo pasarlo a un código igual al trabajo de Samek o el de Axel Tobias creo que valdría menos (Además hay que decidir sobre los dos), yo creo que tengo una solución superadora que agrega valor a lo anterior.

Interfaz gráfica no hay, cualquier herramienta case que genere un .uml o .xmi puede usarse. Papyrus es libre y gratuito. Lo que me estoy centrando es en el codificador pero tengo que hacer que codifique de la forma que me parece mejor y justificar por qué es mejor, por más que este basado en todos los trabajos que estuvimos hablando.

Si en algún momento todo el mundo de embebido pasa a usar C++ y se olvidan del C seguramente no se utilice más esta herramienta, por ahora la mayoría de los sistemas embebidos son en C.

Mariano, imaginate la siguiente situación, tenes que hacer una aplicación en C y estás muy cómodo diseñando orientado a objetos o incluso ya tenés un diseño o aún mejor un diagrama de clases que se podría usar en esa aplicación. Lo que deberías hacer es correr ese diseño en esta herramienta y woala! te codifica todo ese diagrama en código C.  Luego vas a cada método y escribis su cuerpo. Listo tenes tu aplicación con un diseño oo (Seguramente el desarrollo te implique algo más pero la parte qué es oo es así)

Yo cuando no tenía esto hacía unas indicaciónes a BoUML en el código que generaba para C++ para ayudarme a codificarlo en C (por ejemplo que en vez de class ponga struct y otras cosas). En ese momento usabamos un HCS12GC de freescale que no tiene compilador para C++ gratuito (Si lo hay ahora quizás sea de otra empresa). En cada situación sera distinto el motivo por el cual se utiliza C pero se usa.

Muchas gracias por ayudarme a expresar todo esto,

Saludos,

Jonathan

[Jonathan Marino]

Gracias Martín.

El 9 de septiembre de 2015, 16:55, martin ribelotta <martinr...@gmail.com> escribió:

Algunos comentarios entre lineas:

El 9 de septiembre de 2015, 16:36, Jonathan Marino <jonym...@gmail.com> escribió:

Gracias Mariano y Martín,

Ya sé que hay trabajos ya realizados. Ahora los que menciona Martín no fueron pensados para sistemas embebidos. Cuando yo empecé a utilizarlo introduje varias optimizaciones que me parecen una parte importante explicarlas en la tesis. Los trabajos que vi orientados a objetos para sistemas embebidos como el de samek o el de leandro le falta varias de las cosas que tienen los trabajos anteriores. Hay también optimizaciones que pienso hacer a través de indicaciones en los diagramas, tendría que analizar si sería posible hacerlas en C++ porque son un poco extrañas a la oo.

Además de optimizaciones se me ha ocurrido una forma de implementar la visibilidad de atributos que no lo vi en ningún trabajo.

Todo esto entiendo que es propio de una tesis, hay que presentarlo, correrlo en pruebas y comparar y ver que tan bueno es.

Tal cual, como no conocemos que es eso a lo que te referis, asumo que usas bien el criterio para definirlo como "propio de una tesis" así que ahi no digo nada.

 

Si hiciese un generador de código uml que hiciera tan solo pasarlo a un código igual al trabajo de Samek o el de Axel Tobias creo que valdría menos (Además hay que decidir sobre los dos), yo creo que tengo una solución superadora que agrega valor a lo anterior.

Interfaz gráfica no hay, cualquier herramienta case que genere un .uml o .xmi puede usarse. Papyrus es libre y gratuito. Lo que me estoy centrando es en el codificador pero tengo que hacer que codifique de la forma que me parece mejor y justificar por qué es mejor, por más que este basado en todos los trabajos que estuvimos hablando.

Entonces cual es el producto final? Un programa que toma el archivo XML generado por la herramienta y genera codigo C? Eso es util tambien.

Vas a ir en eclipse a tu archivo .uml darle boton derecho y poner generate embedded-ooc. En el mismo eclipse pudiste haber hecho tu diseño en papyrus que te generó ese .uml

 

Si en algún momento todo el mundo de embebido pasa a usar C++ y se olvidan del C seguramente no se utilice más esta herramienta, por ahora la mayoría de los sistemas embebidos son en C.

Dudo que C deje de usarse. Simplemente los porcentajes van a variar (C se viene usando desde hace 40 años)

De todas formas, C++ implementa todo lo que se habla de POO (bien, mal o regular, eso es discutible) y se usa actualmente en sistemas embebidos (en el porcentaje correspondiente, el cual va creciendo)

 

Mariano, imaginate la siguiente situación, tenes que hacer una aplicación en C y estás muy cómodo diseñando orientado a objetos o incluso ya tenés un diseño o aún mejor un diagrama de clases que se podría usar en esa aplicación. Lo que deberías hacer es correr ese diseño en esta herramienta y woala! te codifica todo ese diagrama en código C.  Luego vas a cada método y escribis su cuerpo. Listo tenes tu aplicación con un diseño oo (Seguramente el desarrollo te implique algo más pero la parte qué es oo es así)

El tema es en QUE tenes ese diseño. Si es sobre papel, es trival implementarlo en C. Si es sobre otra cosa (XML) esto podria ser una herramienta util.

Si vas al capitulo 7 del link que pasé vas a ver que no considera que sea tan trival la codificación (hay que escribir bastante lo que es propenso a errores). Yo preferiría incluso en ese caso pasar del papel a la compu y luego correr el generador. (Además podrían generarse automáticamente los testcase de los métodos en ya con ese diagrama (esto será a implementar!)) 

De todas formas, una vez que tenes un diseño, es MUY dificil cambiarlo por cualquier cosa nueva si no es una transformación automatica src->src con todo lo que estas herramientas implican (gran mastirbación academica, pero en la practica son inutiles porque todos los casos borde son los casos que QUERES resolver y la herramienta no puede)

No entendí bien esto, me explicas de nuevo? 

[Leandro Francucci]

Hola Jonathan,

Desde el punto de vista de utilizar, en mayor o en menor medida, MDD en SE u otros, por ejemplo mediante UML, es algo natural (y muy útil) que uno requiera trasladar, de manera automática, el modelo visual al código. Ahora, qué lenguaje de programación utilizas y de qué manera, está fuera de la especificación UML y obviamene de MDD. Sin embargo, UML ha sido concebido para representarse mediante los principios de la POO.

Con todo esto en mente, ¿cómo procedo cuando necesito codificar un modelo estructural, por ejemplo un diagrama de clases, y, por algún motivo particular restrictivo, el lenguaje de programación es uno estructurado como C?, para esto se me ocurren varias alternativas, una es C orientado a objetos, otra puede ser C basado en objetos, entre otras. Rhapsody te permite elegir el lenguaje de la generación de código y en caso de C, bajo qué estrategia (por ejemplo lo que llaman FunctionalC), adjunto "DouglassInC.pdf"

En mi caso particular, un simple programador de C, dependiendo del caso, suelo limitar el uso de los elementos de los modelos para no complejizar demasiado la codificación, sin embargo podría decir que siempre intento aplicar prácticas básicas como la abstracción, el encapsulamiento y el polimorfismo en lenguaje C, ya que no son parte de un lenguaje particular ni tampoco de los modelos. Por lo general y en términos de Samek, prefiero esto que esto. Lo último es algo más parecido a lo propuesto por Axel Tobias Schreiner. Sin embargo, siempre estoy investigando nuevas prácticas para aplicar estos conceptos, leyendo a Douglass, parte de la doc de Rhapsody, Samek, Dan Saks entre otros.

Por otro lado, no estoy de acuerdo en "imitar" con C un lenguaje como C++, de forma caprichosa, ya que hoy en día un buen compilador de C++ siempre será más eficiente de lo que nosotros podamos hacer desde el mismo C. Es decir, no intentar Objective-C.

Por lo que entendí, vos estás trabajando en un generador de código C a partir de un diagrama de clases, basado en las técnicas de Alex Tobias pero optimizadas. ¿Pudiste probar Papyrus-RT?, es la "gran promesa" basada en Papyrus, este incorpora un generador de código, que según prometen puede especializarse y/o extenderse.

Como bien decis, los frameworks QP y RKH, están más relacionados con el comportamiento que con los modelos estructurales. Inclusive, Samek tiene su propio generador de código (a partir del comportamiento reactivo) con la herramienta QM.

En ese sentido, desde hace bastante tiempo que tengo intenciones de crear un plug-in de Eclipse para generar código compatible con las reglas del framework RKH, a partir de un modelo de estructura que contenga clases reactivas y por lo general también activas, cuyo comportamiento dinámico se represente por medio de diagramas de estados. Mi idea era basarlo en el plug-in Acceleo para crear generadores de código a partir de modelos (MOFM2T). Por otro lado, el modelado podría provenir del plug-in tradicional como Papyrus.

Al margen: junto con Papyrus, Acceleo, y el plug-in del generador de código, mi intensión es contar con otros como ("ideas locas"):

• RKH graphical trace analyzer, plug-in de Eclipse para mostrar información sensible y dinámica, de forma gráfica o textual, durante la operación de la aplicación basada en el framework RKH. La información se extrae del sistema en ejecución cuando este pasa por determinados puntos de seguimiento, en los cuales se generan eventos que transportan información adicional. Si bien, los puntos y sus eventos están impuestos por el framework, la aplicación puede crear sus propios eventos para reportar la información que requiera cuando la misma pase por estos. Actualmente, existe la aplicación Trazer, la cual permite visualizar esta información pero de manera textual, siendo que esta es un porgrama en consola.
• RKH Configuration Wizard, plug-in de Eclipse para asistir al proceso de configuración del framework RKH. Estas se aplican en tiempo de compilación, la idea es que esta, mediante una interfaz gráfica, genere de manera automática, los archivos de configuración.

Saludos!

LF

[Jonathan Marino]

Muchas Gracias de nuevo Leandro por tu mail que me agrega nuevos conocimientos.

Te contesto abajo:

El 10 de septiembre de 2015, 15:03, Leandro Francucci <francu...@gmail.com> escribió:

Jonathan,

No entendí cuando decís que "Ya que nombraste Acceleo, genera una oo como esa", entiendo que con Acceleo puedo hacer lo que quiera, utilizando el metalenguaje especificado por UML.

Si.

A lo que me refiero es que Acceleo mismo es un lenguaje con algunas características de los orientados a objetos con esta diferencia en cuanto al polimorfismo:

Overriding in Acceleo does not behave in the same way as it does in most object oriented programming (Acceleo is not object oriented). If a module A imports a module B that extends C and if the module C defines a template tC overridden in the module B and the module C also defines a template tC1 that calls tC. If from the module A we are calling tC1, in Java and in most object oriented programming this call to tC1 would call tC in the module B since it is overridden and even if tC1 is only located in the module C we are still in the context of a module B but in Acceleo the overriding mechanism does not provide additional dispatch. It only ensure that if two templates are accessible and if one override the other, the overriding one is called. The overriding mechanism should mainly be used for dynamic overriding (explained later).

La misma diferencia se encuentra en la forma en Douglass codea objetos

No conozco ninguna herramienta que genere algo similar a lo propuesto por Samek. No veo otra alternativa que crear un proyecto Acceleo y crear el generador de código, para luego hacer un plug-in de Eclipse. Algo que me gustaría hacer, pero no lo veo físicamente realizable, por la demanda de tiempo que eso implica. Es algo que tengo pendiente.

Bueno entonces entendes que lo que voy a hacer esta bueno porque justamente es casi eso, con algunas capacidades opcionales más por parte del código generado. Podemos debatir que código debería generar. Yo voy a ir subiendo ejemplos de código generado con el tiempo. Igualmente te va a costar muy poco cuando suba el proyecto modificarlo para que haga exactamente lo que quieras te puedo dar una mano.

Respecto de la creación y destrucción de objetos, soy muy escéptico, específicamente me refiero a lo que esto implica: la asignación de memoria. Por lo general no utilizo la asignación dinámica de memoria, sino más bien, en función del tiempo de vida del objeto y otras cuestiones, utilizo memoria estática, o asignación por bloques de tamaño fijo con una garbage collector, esta última es mi preferida. Por supuesto, estas estratégias tiene sus ventajas/desventajas. En este sentido, Rhapsody tiene la opción de definir que tipo de estrategia utilizar.

Quizás agregue alguna opción para especificar el uso de memoria.

El 10 de septiembre de 2015, 15:03, Leandro Francucci <francu...@gmail.com> escribió:

Jonathan,

No entendí cuando decís que "Ya que nombraste Acceleo, genera una oo como esa", entiendo que con Acceleo puedo hacer lo que quiera, utilizando el metalenguaje especificado por UML.

No conozco ninguna herramienta que genere algo similar a lo propuesto por Samek. No veo otra alternativa que crear un proyecto Acceleo y crear el generador de código, para luego hacer un plug-in de Eclipse. Algo que me gustaría hacer, pero no lo veo físicamente realizable, por la demanda de tiempo que eso implica. Es algo que tengo pendiente.

Respecto de la creación y destrucción de objetos, soy muy escéptico, específicamente me refiero a lo que esto implica: la asignación de memoria. Por lo general no utilizo la asignación dinámica de memoria, sino más bien, en función del tiempo de vida del objeto y otras cuestiones, utilizo memoria estática, o asignación por bloques de tamaño fijo con una garbage collector, esta última es mi preferida. Por supuesto, estas estratégias tiene sus ventajas/desventajas. En este sentido, Rhapsody tiene la opción de definir que tipo de estrategia utilizar.

Por otro lado, para darse una idea de lo importante que son los modelos de comportamiento, y como han contribuido a la industria del desarrollo de software, Rhapsody nació como la versión de Statemate que generaba código C++, siendo Statemate una de las primeras herramientas que generaba código a partir de un Statechart, gracias al Profesor David Harel, además de ser una de las primeras en la industria en permitió el modelado gráfico y a partir de este poder ejecutarlo y generar código.

Saludos!

LF

El 10 de septiembre de 2015, 14:31, Jonathan Marino <jonym...@gmail.com> escribió:

Hola Leandro,

Muchas gracias por tu mail, por lo que veo andamos en la misma,

te contesto abajo

El 9 de septiembre de 2015, 20:26, Leandro Francucci <francu...@gmail.com> escribió:

Hola Jonathan,

Desde el punto de vista de utilizar, en mayor o en menor medida, MDD en SE u otros, por ejemplo mediante UML, es algo natural (y muy útil) que uno requiera trasladar, de manera automática, el modelo visual al código. Ahora, qué lenguaje de programación utilizas y de qué manera, está fuera de la especificación UML y obviamene de MDD. Sin embargo, UML ha sido concebido para representarse mediante los principios de la POO.

Con todo esto en mente, ¿cómo procedo cuando necesito codificar un modelo estructural, por ejemplo un diagrama de clases, y, por algún motivo particular restrictivo, el lenguaje de programación es uno estructurado como C?, para esto se me ocurren varias alternativas, una es C orientado a objetos, otra puede ser C basado en objetos, entre otras. Rhapsody te permite elegir el lenguaje de la generación de código y en caso de C, bajo qué estrategia (por ejemplo lo que llaman FunctionalC), adjunto "DouglassInC.pdf"

Si, conozco la forma de Douglass, la verdad no me gusta, ahorra un poco de tiempo de ejecución, pero pierde performance en memoria y peor no genera una orientacion a objetos convencional. Ya que nombraste Acceleo, genera una oo como esa. En mi tesis supongo aparecerá una crítica al mismo. Conoces si hay una estrategia que genere código como el de Samek que te gusta?

En mi caso particular, un simple programador de C, dependiendo del caso, suelo limitar el uso de los elementos de los modelos para no complejizar demasiado la codificación, sin embargo podría decir que siempre intento aplicar prácticas básicas como la abstracción, el encapsulamiento y el polimorfismo en lenguaje C, ya que no son parte de un lenguaje particular ni tampoco de los modelos. Por lo general y en términos de Samek, prefiero esto que esto. Lo último es algo más parecido a lo propuesto por Axel Tobias Schreiner. Sin embargo, siempre estoy investigando nuevas prácticas para aplicar estos conceptos, leyendo a Douglass, parte de la doc de Rhapsody, Samek, Dan Saks entre otros.

Yo también prefiero el primero al segundo. De hecho en mi tesis hay una crítica al uso de preprocesadores para obtener orientación a objetos, se pierde la imagen real, hay que aprenderse lo que quiere decir cada llamada y si es un preprocesador externo el IDE no lo reconoce por lo que se pierden herramientas como chequeos automásticos, refactoring, búsquedas, etc. A mi justamente de Axel Tobias Schreiner no me gusta que utilice un preprocesador. Ahora entiendo porque lo hacen: Incluso la "oo simple" que pasas es propensa a errores, y si lo complejizas más, más propensa a errores y si llegas a cambiar algo en la forma en que codificas a objetos, o agregas un método a la clase más básica (el padre del padre del padre...) bum! anda a cambiar todos los archivos! Por eso al tener una herramienta UML a C creo que tenemos lo mejor de los dos enfoques, C puro legible para un programador C y para el IDE y quitar la introducción de errores para hacer oo y poder agregar más herramientas oo o métodos en clases "bases" sin que tenga que cambiar el programador todos los archivos (de hecho ninguno).

Ahora el hecho de que prefieras más una forma de codificar oo que otra muestra lo que viendo queriendo decir, tengo que justificar porque mi herramienta codifica asi y no asa, y yo no compre a nadie asi que es un poco de todos y un poco de ninguno. Lo voy a presentar, correr, medir y comparar.

Por otro lado, no estoy de acuerdo en "imitar" con C un lenguaje como C++, de forma caprichosa, ya que hoy en día un buen compilador de C++ siempre será más eficiente de lo que nosotros podamos hacer desde el mismo C. Es decir, no intentar Objective-C.

Creo que sé a lo que te referis, a hacer un trabajo como C+ 3.0. Ya aclaré que tampoco me parece. Lo que sí quiero permitir que se tengan varias herramientas (opcionales) para tener cosas que se encuentran en otros Lenguajes OO, puede ser C++ o también tengo ideas de JAVA 

Por lo que entendí, vos estás trabajando en un generador de código C a partir de un diagrama de clases, basado en las técnicas de Alex Tobias pero optimizadas. ¿Pudiste probar Papyrus-RT?, es la "gran promesa" basada en Papyrus, este incorpora un generador de código, que según prometen puede especializarse y/o extenderse.

Se va a poder integrar a papyrus y papyrus RT, pero primero quiero hacer lo estrictamente necesario para la tesis 

Como bien decis, los frameworks QP y RKH, están más relacionados con el comportamiento que con los modelos estructurales. Inclusive, Samek tiene su propio generador de código (a partir del comportamiento reactivo) con la herramienta QM.

En ese sentido, desde hace bastante tiempo que tengo intenciones de crear un plug-in de Eclipse para generar código compatible con las reglas del framework RKH, a partir de un modelo de estructura que contenga clases reactivas y por lo general también activas, cuyo comportamiento dinámico se represente por medio de diagramas de estados. Mi idea era basarlo en el plug-in Acceleo para crear generadores de código a partir de modelos (MOFM2T). Por otro lado, el modelado podría provenir del plug-in tradicional como Papyrus.

Ese framework estoy usando, no se si voy a hacer la integración a papyrus aunque es muy simple. Esto lo van a super extender asi que otro que se sume seguramente lo hará.

Ya que lo conoces entendes que lo único que tengo que pensar es qué codificación se generarán a partir de los modelos. 

Al margen: junto con Papyrus, Acceleo, y el plug-in del generador de código, mi intensión es contar con otros como ("ideas locas"):

• RKH graphical trace analyzer, plug-in de Eclipse para mostrar información sensible y dinámica, de forma gráfica o textual, durante la operación de la aplicación basada en el framework RKH. La información se extrae del sistema en ejecución cuando este pasa por determinados puntos de seguimiento, en los cuales se generan eventos que transportan información adicional. Si bien, los puntos y sus eventos están impuestos por el framework, la aplicación puede crear sus propios eventos para reportar la información que requiera cuando la misma pase por estos. Actualmente, existe la aplicación Trazer, la cual permite visualizar esta información pero de manera textual, siendo que esta es un porgrama en consola.

Muy bueno! ya no le va a quedar mucha ventaja a Rhapsody que ejecuto los diagramas de estado

• RKH Configuration Wizard, plug-in de Eclipse para asistir al proceso de configuración del framework RKH. Estas se aplican en tiempo de compilación, la idea es que esta, mediante una interfaz gráfica, genere de manera automática, los archivos de configuración.

Saludos!

LF

Muchas gracias Leandro!!!.