La presente publicación es la segunda parte del artículo Modelos y frameworks en embedded software de manera simple, que explora las características y los beneficios de utilizar modelos y frameworks para disminuir el costo, la complejidad y el tiempo de desarrollo del software de un embedded system. Específicamente, esta parte analiza el uso de los frameworks más tradicionales del mercado, para lograr que los conceptos expuestos en la primera parte se materialicen y se conviertan rápidamente en parte de nuestro software.
Para que la codificación de los Statecharts concurrentes y colaborativos, no se convierta en un obstáculo, limite o impida su uso, existen paquetes de software disponibles, que proveen la manera y las reglas adecuadas para codificar el modelo de comportamiento diseñado, en un embedded system, dentro de un marco formal, simple, bien definido y estructurado, como ser el framework QP de Quantum Leaps, Rational Rhapsody de IBM, o el framework RKH. Al mismo tiempo, todos estos utilizan el concepto de objeto activo y la comunicación mediante el intercambio de mensajes asincrónicos, entre otras cuestiones.
Por otro lado, si bien las herramientas Visual State de IAR y Yakindu de Itemis incorporan el modelado de Statecharts y la generación automática de código a partir de estos, no soportan el concepto de objeto activo ni proveen los servicios necesarios para la interacción de múltiples Statecharts en ejecución simultánea, como propone UML. Una cuestión a analizar con este tipo de herramientas es cómo modelar un sistema que posee diferentes e independientes procesadores de eventos representados por máquinas de estados, donde cada uno de estos posee un nivel de prioridad de ejecución particular. Si bien con estas herramientas podríamos modelar cada proceso con una región ortogonal contenida en un estado ortogonal, a estas no se les puede asignar una prioridad de ejecución, ya que heredan la prioridad de la máquina de estados que las contiene, y por lo tanto no podríamos realizar un análisis de planificabilidad del sistema para determinar si el mismo alcanzará o no sus restricciones temporales. En ciertos sistemas puede que esta limitación sea totalmente invalidante.
Desarrollo efectivo
Para alcanzar un mayor nivel de productividad en el desarrollo, se recomienda que junto al uso de modelos y frameworks, se utilicen otras herramientas tal que faciliten:
- el desarrollo iterativo e incremental,
- el modelado visual,
- la ejecución o simulación gráfica del modelo junto con
- la verificación automática del mismo y
- la generación automática del código que lo representa,
- las pruebas unitarias y
- la integración continua.
Si bien existen herramientas que incorporan todas estas características, como Rational Rhapsody, el precio de su licencia, las restricciones de soporte y actualización, la fuerte y abrumadora dependencia que generan, y la alta complejidad en su uso, las convierte un tanto restrictivas a solo unas pocas grandes compañías, que no es lo que precisamente esperamos para todos los niveles de la industria, como ser unidades académicas, equipos de investigación, jóvenes empresas, etc. Como nota ilustrativa, Rational Rhapsody es un sucesor directo de la herramienta Statemate, que fue desarrollada inicialmente por un equipo de investigación a cargo del Dr. David Harel, creador de la sintaxis y semántica de los Statecharts. Se ha dicho que Statemate fue de las primeras herramientas visuales en generar código automáticamente a partir de un modelo gráfico.
No obstante, este ecosistema puede construirse a partir de paquetes de software de código abierto, por ejemplo el IDE Eclipse y el plug-in Papyrus-RT, siendo este uno de los tantos componentes de las soluciones que provee Polarsys para el desarrollo de embedded systems, tanto para la ingeniería como para el desarrollo de software. De todas maneras, su uso requiere cierto grado de experiencia y habilidades en la ingeniería de software para poder aprovechar todas sus capacidades.
Quantum Leaps ofrece una solución intermedia, ya que provee el framework de código abierto para el desarrollo de aplicaciones comerciales con una licencia de bajo costo relativo, y también una herramienta visual para el modelado y posterior generación automática de código, entre otras simples herramientas. Esto logra una buena alternativa de alta calidad, usada por una gran cantidad de empresas y segmentos del mercado, por ejemplo forma parte del software del vehículo Curiosity!. Esto puede verificarse a través de varios artículos públicos que explican su uso mediante Autocoder, una herramienta desarrollada por JPL para la generación automática de código a partir de un modelo, como así también su simulación y verificación mediante SPIN.
Del orden de la solución QP, también está disponible el framework RKH de Vortex, el cual posee algunas diferencias con QP, específicamente la codificación de las máquinas de estados es un tanto más simple y directa, reflejando en el código lo que el modelo indica, donde la topología de los Statecharts se almacena como datos en ROM, evitando
de esta manera su codificación con código condicional (if-else,
switch-case), que se ofusca en la medida que aumenta la complejidad.
Adicionalmente, esta estrategia de implementación es sumamente eficiente
en términos de tiempo de ejecución. También cuenta con el ambiente de prueba listo para efectuar pruebas unitarias de máquinas de estados, basado en los frameworks Unity, Cmock y Ceedling, para mayor información al respecto ver la publicación "Prueba de máquinas de estados planas y jerárquicas mediante casos de prueba". La tercera publicación del artículo incluye la descripción detallada del framework RKH.
Por otro lado, está en proceso de desarrollo un conjunto de herramientas para el modelado visual, su animación y la generación automática de código, junto con la visualización estricta del comportamiento del sistema de software, para determinar cuestiones relacionadas con las máquinas, el uso de los servicios del framework, el tiempo de respuesta, el uso de memoria, el rendimiento, la temporización, entre otras cuestiones.
El conjunto de herramientas Rhapsody posee el framework OXF, del cual existe documentación relevante que permite comprender el objetivo y magnitud tanto de Rhapsody como de un framework para desarrollar embedded software.
¿Porqué un framework?
Por lo general, el software de aplicación de los sistemas embebidos requiere un conjunto común de servicios. Particularmente, en el dominio de los sistemas de tiempo-real, aquellos reactivos o dirigidos por eventos, requieren gestionar la recepción y manejo de eventos, ejecutar máquinas de estados, manejar memoria, gestionar el intercambio de mensajes, gestionar el tiempo mediante temporizadores, abstraer el sistema operativo y/o plataforma subyacente, registrar la operación del sistema en tiempo de ejecución, proveer de mecanismos que contribuyan a la robustez y la fiabilidad, entre otras tantas. Usualmente, el código que produce dicha funcionalidad, es similar entre aplicaciones del mismo dominio, el cual ronda entre el 60% y 90%, es decir, de una manera u otra estos porcentajes representan código ya implementado en sistemas anteriores.
Aún así, y por lo general, cada vez que se construye un nuevo sistema, se genera código para realizar dichas funciones, como si fueran cuestiones particulares o novedosas del mismo.
Ahora, ¿no sería más provechoso comenzar el próximo proyecto, con una aplicación parcialmente completa, que ya sabe cómo hacer estas cosas?, tal que sólo preocupe agregar el código específico de la aplicación requerida (el cual se extiende entre un 10% a un 40% del total).
Por esta razón, si se capturan estas cuestiones comunes, de forma tal que, puedan reutilizarse como están, especializarse según corresponda o reemplazarse fácilmente si es necesario, se construye un conjunto de funciones, que conforma el esqueleto de las aplicaciones, o en otras palabras, un framework.
Así, un framework puede definirse como una aplicación parcialmente completa, cuyas partes son personalizadas por el usuario, para lograr la aplicación específica.
Ventajas de su uso
De acuerdo con los lineamientos anteriores, el uso de un framework como QP, RKH u OXF:Minimiza la complejidad de las aplicaciones
Emplear código que ya ha sido construido, probado y usado por otros programadores, incrementa la confiabilidad y reduce el tiempo de programación y validación.
Reduce drásticamente el tiempo de lanzamiento al mercado de nuevos productos
Focaliza los equipos de desarrollo en conseguir los requerimientos funcionales específicos del producto
Sus actualizaciones mejoran la aplicación sin programación adicional
Al utilizarse en la industria para la construcción de sistemas, el framework se encuentra en constante revisión, con lo cual evoluciona con el tiempo, subsanando defectos, adoptando nuevas ideas y descartando las que no resultan.
Promueve la adopción de un lenguaje y técnicas comunes entre los desarrolladores
Generando un nivel de abstracción tal que la implementación del modelo, resulte más clara y fácil de modificar. Reutilizando estrategias para resolver cuestiones arquitectónicas, de concurrencia y de otras índoles.
Comentarios
Publicar un comentario