1 de 26

1
Statecharts
2
Statecharts

• Los diagramas de estado son particularmente
  útiles para modelar sistemas embebidos porque
  estos suelen ser reactivos
• O sea, responden a eventos externos que no
  necesariamente tienen orden o periodicidad
• En 1987 Harel propone Statecharts, una evolución
  del lenguaje clásico de los diagramas de estados
• D. Harel, Statecharts A visual formalism for
  complex systems, Science of Computer
  Programming, vol. 8 num. 3, pp. 231274, junio de
  1987
• Para modelar sistemas medianamente complejos, los
  Statecharts son más compactos y claros que los
  diagramas de estados clásicos
• Principalmente porque incluyen jerarquías y
  concurrencia
• Forman parte del UML y se usan extensivamente en
  herramientas MDD para embebidos

3
Bibliografía recomendada

• M. Samek, Practical UML Statecharts in C/C,
  Capítulo 2
• También está disponible como artículo en línea de
  EE Times
• Ver en nuestra página de material de estudio

4
Para qué?

• Samek arranca elcapítulo con unejemplo
  lacalculadora quevenía con VisualBasic, que
  dabaerror si uno tecleaba cosas como 2, -, -, -,
  
• Argumenta que, de haberla modelado con una
  máquina de estados antes de sentarse a programar,
  se podían haber evitado tantos errores
• Al final del capítulo diseña ese modelo
• usando bastante de la semántica extendida que
  provee Statecharts por sobre un diagrama de
  estados clásico

5
Estados y transiciones
Reset
(Evento de) trigger(o sea, entrada)
Acción(o sea, salida)
Estados

• Como el diagrama de estados de una máquina de
  Mealy, pero usa rectángulos con esquinas
  redondeadas para los estados y un círculo lleno
  para el reset
• También pueden modelar máquinas de Moore, lo
  vemos más adelante

6
Máquinas de estados extendidas

• Extendida debido al uso de la variable
  key_count
• Los pseudoestados de decisión son otro agregado a
  la semántica clásica de las máquinas de estado
  que usa Statecharts
• 3 diapositivas atrás dijimos más compactos y
  claros

7
Jerarquías

• Lo que hicimos fue modelar el comportamiento
  dentro de esperando con una máquina de estados
• Este tipo de jerarquización permite, en muchos
  casos, economizar transiciones, entre otras
  simplificaciones
• que clarifican el diagrama y reducen la cantidad
  de errores en su edición

8
Jerarquías

• Notar que, en el ejemplo, la transición que
  dispara con pulsó empezar sale de ingresando
  tiempo
• O sea que si el sistema está en idle, pulsar
  empezar no cambia el estado
• Al menos en lo que respecta al alcance de este
  diagrama
• El comportamiento en ingresando tiempo
  probablemente también sea útil modelarlo con un
  diagrama de estados
• Podemos ponerlo allá adentro o en hoja separada

9
Actividad

• En mi microondas, si no se ingresó un tiempo y se
  presiona empezar, arranca con tiempo 30s.
  Cómo podemos modificar el diagrama de arriba
  para incorporar ese comportamiento?
• Pueden suponer que existe una variable tiempo
  que es modificada en ingresando tiempo y tomada
  por el timer cuando este arranca
• Evalúen diferentes maneras de resolverlo
• Pueden usar sintaxis de C, separando sentencias
  con , y poner acciones en las transiciones
  iniciales (o sea, resets)
• Pero triggers en los resets no, por qué?

10
Concurrencia

• Las dos sub-máquinas son independientes
• Salvo la cláusula en esperando en los
  triggers de abajo
• Por eso, a la concurrencia comúnmente se le dice
  ortogonalidad

11
Acciones Entry y Exit
12
Transiciones internas

• Notar que son similares a transiciones que
  empiezan y terminan en el mismo estado, salvo que
  no se ejecutan las acciones entry y exit
• A calentar normalmente se le dice actividad
  porque es un tanto constante

13
Transiciones locales y externas

• En las externas se ejecutan la acciones exit
  (porque sale) y entry (porque vuelve a entrar),
  en las locales no

14
Pseudoestados

• Son lugares que parecen estados pero no lo son,
  porque el sistema no puede estar en ellos
• Sirven para simplificar el diagrama e
  incorporarle algunas funciones
• Tipos
• Inicial (reset)
• Se indican con un círculo lleno negro
• Condición (o choice u opción)
• Se indican con un diamante, un circulo vacío o
  uno que contiene una C
• Lo usamos en la Diapositiva 6
• Junturas
• Se indican con un punto negro
• Sirven para juntar o bifurcar transiciones cuando
  tienen partes en común
• Historia
• Se indican con un círculo que contiene una H
• Si se entra en una transición que termina en este
  pseudoestado, el próximo estado pasa a ser el
  último estado que tenía la (sub) máquina en
  cuestión
• Fork / Join
• Misma notación y propósito que las transiciones
  de las redes de Petri
• Con un fork se abre una transición para que
  pueda terminar en estados de máquinas
  concurrentes. Join hace lo contrario.
• Final
• Se indica con un círculo que contiene una T

15
Ejemplo

• Tomado de B.P. Douglass, UML Statecharts,
  lthttp//citeseerx.ist.psu.edu/viewdoc/summary?doi
  10.1.1.104.3629gt

16
Transiciones, con más detalle

• Forma general del rótulo de una transición
• Todos los campos son optativos
• Las acciones pueden ser salidas hacia el
  exterior, o eventos que otra parte del modelo usa
  como trigger
• Tipos de eventos
• Señal
• La recepción de una señal (asincrónica)
• Es el tipo de evento más común
• Tiempo
• Se cumplió cierto tiempo desde la llegada al
  estado
• Se escribe (ej.) after 200ms o también tm(200ms)
• Llamada
• Disparado por otra parte del sistema
  sincrónicamente (o sea, esa otra parte del
  sistema espera hasta que la llamada es atendida)
• Cambio
• Cierta expresión condicional pasa a ser cierta
• Se indica con when seguido de la expresión

nombre_del_evento(parámetros) condición /
acciones
17
Transiciones, con más detalle

• Forma general del rótulo de una transición
• La condición
• La transición se dispara sólo si esa expresión es
  verdadera
• Puede incluir (ej.) in(nombre_de_un_estado), para
  condicionar la transición a que una máquina
  concurrente con esta esté en cierto estado
• como vimos en varios de los ejemplos anteriores
• Ejemplos
• evCaenPinos / GenerarRuido()
• evLlegóBola / cantBolasprint(Llegó)
• evCaenPinos(n)ngt10 / MarcarChuza()
• / Inicializar()
• cantidad 10 0
• after 10ms / InformarTimeout()AbrirPuerta()
• when cantidad 10 0 / foobar
• Pulsó_Empezarin(Puerta_Cerrada) / Arrancar

nombre_del_evento(parámetros) condición /
acciones
18
Preguntas
Actividad
19
Statechart requisitos de tiempo real
Notas con requermientos de temporización y de
calidad de servicio (quality of service o QoS)
B.P.Douglass Capturing Real-Time Requirements
lthttp//www.embedded.com/story/OEG20011016S0126gt
20
Actividades

• Dibujar el statechart de un dispenser de café y
  leche
• El dispenser puede estar desactivado (por ejemplo
  para ser llenado) o activado, para lo cual se
  utiliza un pulsador ON/OFF.
• Estando activado, se sirve café manteniendo
  presionando un pulsador CAFÉ y se detiene ese
  chorro soltando el pulsador. Lo mismo ocurre con
  la leche y su pulsador LECHE.
• Hacer dos versiones del statechart una en donde
  sólo pueda servirse una de las bebidas a la vez,
  otra en donde las dos bebidas puedan servirse
  simultáneamente.
• Dibujar el statechart de un calefactor con
  termostato
• El dispositivo cuenta con los siguientes
  pulsadores ON/OFF, CALENTAR, ESPERAR,
  TERMOSTATO, TEMP, TEMP-.
• Con ON/OFF se enciende y apaga. Al ser encendido,
  entra en un estado espera.
• Cuando el usuario presiona el pulsador CALENTAR,
  el calefactor calienta.
• Cuando presiona TERMOSTATO, entra en un estado en
  donde calienta sólo si la temperatura del
  ambiente, medida mediante un sensor, es menor que
  un valor prefijado regulable con los pulsadores
  TEMP y TEMP-.
• En el diagrama anterior, agregar otro modo de
  operación que se activa al presionar un pulsador
  SLEEP. En este nuevo modo, el calefactor calienta
  durante 10 minutos y vuelve al estado espera.

21
Cómo codificar un Statechart?

• Una posibilidad es crear un gran switch case,
  donde cada estado corresponda a un case

22
Cómo codificar un Statechart?

• B.P. Douglass, State Machines and Statecharts,
  lthttp//citeseerx.ist.psu.edu/viewdoc/summary?doi
  10.1.1.40.1095gt

23
Cómo codificar un Statechart?

• El programa puede ser un ciclo infinito
  conteniendo ese switch case
• Para implementar
• Concurrencia varios switch case en secuencia
• Jerarquías switch case anidados
• El problema es que eso va a ocupar al 100 al
  procesador por más que no tenga nada real que
  hacer porque aún no llegan estímulos
• En ciencias de la computación, esta condición se
  llama busy wait
• Igualmente, para ciertas aplicaciones es una
  solución aceptable
• En otras, el consumo que esto conlleva no lo es
• Si el procesador tiene otro código de qué
  ocuparse también, puede ir después del switch
  case, dentro del ciclo infinito
• Esto modera el problema del busy wait, pero puede
  atentar contra el cumplimiento de requerimientos
  de tiempo real

24
Idea

• Poner al procesador en modo sleep después del
  switch case?
• Sleep es un modo de bajo consumo donde el
  microcontrolador no procesa instrucciones pero sí
  funcionan sus periféricos y es capaz de detectar
  interrupciones
• Los microcontroladores normalmente ofrecen varios
  de estos modos, que se diferencian por las
  funciones que permanecen activadas y el retardo
  en volver al modo de ejecución normal
• Si se puede, se hace que del modo sleep salga al
  detectar el estímulo que actúa de trigger en la
  máquina de estados
• Si no se puede, consideremos ponerlo x tiempo
  (usando un timer), siempre que no comprometa los
  requerimientos de tiempo real

25
Maneras más avanzadas de codificarlo

• En lugar de case para cada estado
  (hardcodeado), poner los datos del Statechart
  en un array y usar una librería
• Tengan en cuenta que se pueden guardar punteros a
  funciones que contengan las condiciones y las
  acciones
• Si el switch case quedaba intrincado, esto
  puede simplificarlo
• Además, la librería puede proveer funciones
  avanzadas para resolver el tema del busy wait
• El libro de Samek presenta una librería así
• Programar el Statechart bajo un RTOS
• Usar una herramienta MDD
• Como IBM Rational Rhapsody o el Real-Time
  Workshop para Simulink de Mathworks
• Funcionan con varios RTOS populares

26
Conclusiones

• Los Statecharts son un lenguaje de creciente
  popularidad en embebidos
• Extienden el lenguaje clásico de las máquinas de
  estados, en una forma que resulta muy práctica
  para el modelado de software
• Existen diferentes maneras de implementarlos
• Cada una tiene pros y contras en cuanto a su
  complejidad, consumo, tiempo de respuesta y
  necesidad de software de base
• Sirven para detallar las ideas antes de
  implementarlas, lo que nos sirve para
• Ordenar las ideas, ponernos de acuerdo con
  colegas y documentar
• Ejecutarlos (o sea, simularlos) para corregir
  errores y explorar alternativas
• Traducirlos automáticamente a C u otro lenguaje
  de programación, si contamos con una herramienta
  MDD apropiada
• Dentro de estas, normalmente se puede elegir la
  versión de C, de las librerías y de RTOS (si
  usamos uno) y se puede trabajar sobre el código
  resultante