Ir al contenido principal

Entradas

Mostrando las entradas etiquetadas como State Machines

Prueba de máquinas de estados planas y jerárquicas mediante casos de prueba

El artículo explora una serie de estrategias, como punto de partida, para probar software que representa máquinas de estados tanto tradicionales (o planas) como de estados anidados (o jerárquicas). Estas últimas también conocidas como Statecharts [5] o máquinas UML. Dichas estrategias se aplican bajo conceptos como el desacople de módulos, el uso de stub , spy y mock [1][6], los casos de prueba unitarios y sus fases , entre otros, los cuales permiten aplicar de manera inmediata el desarrollo de software dirigido por pruebas ( TDD ), en este caso para las máquinas de estados, con los beneficios que ello implica. Aunque lamentablemente poco explorado para la aplicación en software dirigido por eventos (reactivo). Cada una de las estrategias expuestas se respalda con ejemplos de código fuente, escritos en lenguaje C para el framework de prueba Unity y Cmock , aunque pueden extrapolarse fácilmente a otros similares.  Finalmente, el presente artículo muestra una estrateg...

Especificación de Máquinas de Estados UML y Compatibilidad en RKH

El presente artículo describe en detalle la semántica y notación de cada uno de los elementos que constituyen las máquinas de estados especificadas por UML, las cuales se basan en el modelo de comportamiento dinámico Statechart escrito por el profesor David Harel [1]. Adicionalmente, describe la compatibilidad y grado de cumplimiento de la versión 2.4.4 o superior del framework RKH [2] con la especificación de máquinas de estados definida por OMG, en la especificación “OMG Unified Modeling Language”, Version 2.5 , Capítulo 14 “StateMachine”, pág. 319 [3]. Si bien la especificación UML de OMG es libre y pública, dista bastante de ser fácil de leer e interpretar, por aquellas personas que no se dedican exclusivamente a estos temas, pero si requieren formalizar la manera en que desarrollan software, en especial aquel aplicado a los embedded systems . Por tal motivo, el objetivo fundamental del presente artículo, es acercar la especificación (semántica y notación) de U...

Modelo de transacción fiable en sistemas intercomunicados

Los embedded systems utilizan los protocolos de comunicación para enviar y recibir información crítica, tanto entre procesadores internos, como con actores externos. Dentro del mismo sistema, algunos mensajes pueden ser más críticos que otros, requiriendo un alto nivel de fiabilidad en su transferencia al medio. Para aumentar este factor en un medio poco fiable o cuando se requiere una fiabilidad extraordinaria, puede recurrise al mecanismo de transacción, el cual disminuye la probabilidad de ocurrencia de ciertos problemas, que en determinados sistemas, como los médicos, pueden incurrir en fallas muy severas. El presente artículo describe la aplicación del mecanismo de transacción "exactamente una vez" (EO - exactly once) [3], sobre un sistema que controla un motor, monitorea su velocidad de salida, su temperatura y su presión de aceite, y provee una interfaz al usuario. El sistema en cuestión intercambia información entre sus actores, utilizando el par...

Statecharts implementados mediante tablas de estados

El presente artículo tiene por objetivo mostrar las bases de una implementación de máquina de estados Statechart [2,3,5,6] en lenguaje C (compatible con C++), cuyo objetivo fundamental es lograr una representación en código fuente simple, directa, transparente, legible, flexible y compacta, que permita determinar de un sólo vistazo la topología del diagrama que representa, y así lograr una implementación sencilla de modificar, mantener e interpretar. Incluso que facilite la generalización, la reutilización, la transportabilidad, como así también la generación de código automático. Si bien dicha implementación busca maximizar la legibilidad, no descuida ni la eficiencia en el uso de recursos ni la velocidad de ejecución.

Identificación de respuestas a comandos AT en ISR. Intérprete de comandos.

Gestionar un módulo GSM por comandos AT, recibir, buscar e interpretar tanto las respuestas a comandos como las no solicitadas (URC) no es una cuestión menor si se requiere una solución eficiente, robusta y flexible. Sabiendo que cada comando AT tiene por resultado un conjunto posible de respuestas y que estas se representan por cadenas de caracteres codificadas en ASCII, en principio, el software que las recibe tiene por objetivo identificarlas de acuerdo al comando enviado, sin olvidar la detección de aquellas no solicitadas, aún cuando aguarda la respuesta a un comando enviado. También se lo conoce como intérprete de comandos AT. La intención del presente artículo es proponer una solución a esta problemática, siguiendo las ideas de la publicación Administración de módulos GSM en sistemas reactivos , basada en la estructura de datos tipo árbol y los autómatas finitos, también conocidas como máquinas de estados finitas.

Administración de módulos GSM en sistemas reactivos

Generalmente, un módulo GSM se administra por medio de comandos AT, lo cual implica enviar un comando y esperar la recepción de una respuesta. Hasta aquí, el esquema obedece a un simple modelo del tipo cliente-servidor, en el cual el módulo externo o dispositivo se comporta como servidor de comandos, procesando las solicitudes y enviando en consecuencia el resultado obtenido al cliente conectado. En este caso, el cliente es aquel que envía el comando y espera indefectiblemente una respuesta como resultado. De forma tal, que una próxima solicitud deberá esperar la respuesta del comando previo, ya que los módulos GSM tradicionales no permiten recibir un comando mientras se encuentre en procesamiento, por lo tanto, desde el punto de vista del cliente, la respuesta implica que el módulo está nuevamente listo para recibir comandos. Si así no fuera, puede que el comando se descarte o bien el procesamiento en curso se aborte. Otra de las problemáticas surge con las respuestas no solicitadas ...

Eventos y acciones en contexto

La intención del artículo es promover y fundamentar el uso de las máquinas de estados en aquellos sistemas que reaccionan ante eventos, formalmente sistemas reactivos , típicos entre los embedded systems . Sistemas reactivos y la programación orientada a eventos Los sistemas reactivos son aquellos que en gran parte reaccionan contínuamente a estímulos externos e internos. Estas reacciones dependen de los eventos que recibe el sistema y de su contexto actual. Generalmente, se manifestan por medio de acciones. Inclusive, podrían cambiar el contexto del sistema. Por contexto entendemos una situación, modo o estado particular en el cual el sistema reside. Obviamente, puede que ciertos eventos no provoquen reacciones sobre el sistema, o bien que estas no generen acciones o cambios de contexto. Por otro lado, el conjunto de reacciones establecidas dependiente de los eventos recibidos para un contexto particular define el comportamiento dinámico de un sistema reactivo.  ...

Extendiendo el formalismo de máquinas de estados - I

Cuando modelamos el comportamiento de un sistema mediante máquinas de estados no siempre todo es bonito, claro y sencillo, en ciertas ocasiones debemos tomar diversas estrategías para resolver los pocos obstáculos que presenta el formalismo convencional de máquinas de estados. A continuación resumo algunas de las problemáticas que he enfrentado al diseñar sistemas utilizando máquinas de estados, exponiendo el problema y luego presentando una o varias soluciones posibles extendiendo el formalismo convencional por medio de Statecharts.

Programación orientada a eventos

Generalmente, los embedded systems se caracterizan por reaccionar continuamente ante estímulos internos y/o externos. Estas reacciones provocan una acción determinada, la cual está en función del contexto del sistema. A estos sistemas suele denominárselos Sistemas Reactivos . Tradicionalmente el comportamiento reactivo de un sistema, se describe por medio de la combinación de las definiciones de autómatas finitos de Mealy/Moore, representados gráficamente por su correspondiente diagrama de transición de estados. Esto permite describir naturalmente su comportamiento en términos de estados, eventos, como así también transiciones. Este concepto aplicado a la programación podría denominarse programación orientada a estados o eventos . Sin embargo, si el sistema es complejo, dicha representación puede dificultarse, debido al crecimiento exponencial de estados, resultando en un diagrama caótico y no estructurado. Para que el método estado/evento sea útil, debe ser modular, jerárqui...