Statecharts

,QJHQLHUtDGH6RIWZDUH,
Máquinas de Estados y
Statecharts
2° Cuatrimestre 2000
Máquinas de estados y Statecharts
Máquinas de Estados
1. Introducción
El comportamiento reactivo de los objetos de una clase puede ser descrito formalmente en términos de
estados y eventos, usando una máquina de estados relacionado con la clase bajo consideración.
Los objetos que no presentan un pronunciado comportamiento reactivo pueden ser considerados como si
siempre estuvieran en el mismo estado. En este caso, sus clases no poseen una máquina de estados.
Clas e
M áquina de E s tado
1
0..1
Figura 1. Cada objeto de una clase se relaciona con una máquina de estados
Una máquina de estados es una abstracción de todos los posibles comportamientos, de forma similar que los
diagramas de clase son abstracciones de la estructura estática. Todo objeto sigue el comportamiento
descrito en la máquina de estados asociado a su clase y está, en un momento dado, en un estado que
caracteriza sus evolución interna.
Por ejemplo, un semáforo pasa sucesivamente de verde a amarillo, luego a rojo, entonces vuelve a amarillo
y luego a verde. Esto es durante toda su vida operacional.
Semáforo
Rojo
Amarillo
Verde
Figura 2. Máquina de estados asociada a un objeto semáforo
2. Estados
Todo objeto está en un estado particular en un momento dado. Los estados se representan con rectángulos
de ángulos redondeados. Cada estado tiene un nombre que lo identifica y que debe ser único para evitar
ambigüedad.
Es ta d o A
Es ta d o B
Figura 3. Representación de estados
Los estados están caracterizados por los conceptos de duración y estabilidad. Un objeto no está siempre en
el mismo estado y no puede estar en un estado desconocido o indefinido. Un estado es la imagen de una
Ingeniería de Software I
Pág. 1
Máquinas de estados y Statecharts
combinación instantánea de los valores contenidos en los atributos del objeto y de la presencia o ausencia de
relaciones con otros objetos.
El siguiente diagrama de clase representa personas que trabajan para empresas:
P ers ona
E dad
E m pres a
0..1
1..*
Figura 4. Personas que trabajan para empresas
No todas las personas tienen trabajo (esto se deduce de la cardinalidad de la relación). Asimismo todas las
personas están, en momento dado, en uno de los siguientes estados: {empleado, desempleado, jubilado}.
E m pleado
Jubilado
Des em pleado
Figura 5. Posibles estados de una persona
Para conocer la situación particular de una persona, es necesario estudiar:
•
Edad de la persona.
•
Presencia de una relación a una empresa.
En el siguiente diagrama, no hay ninguna relación entre José, quien tiene 36 años, y una empresa: por lo
tanto, José está desempleado. Pedro, en cambio, está relacionado con una empresa y tiene 44 años: Pedro,
entonces, está empleado. Por último, Juan no tiene ninguna relación con una empresa y tiene 78 años,
siendo Juan un jubilado.
Jos é
E dad = 36
E m pres a
P edro
E dad = 44
Juan
E dad = 78
Figura 6. Relación entre empleados y una empresa
Ingeniería de Software I
Pág. 2
Máquinas de estados y Statecharts
1..1
Construcción de los estados
Las máquinas de estado empleadas en UML son determinísticas y por eso no deben dejar ningún espacio a
construcciones ambiguas. Esto significa en particular que siempre es necesario describir el estado inicial del
sistema. Para un nivel jerárquico dado, siempre hay un y un sólo un estado inicial. En cambio, pueden haber
varios estados finales donde cada uno corresponde a una condición de fin diferente o puede no haber ningún
estado final (por ejemplo, en el caso que el sistema nunca pare). El estado inicial se representa mediante un
punto negro grande. Los estados finales se representan con un punto negro grande rodeado por un círculo.
E s tado Inic ial
E stado Interm edio
E s tado Fin al
Figura 7. Notación para representar estados especiales
Nota: varios de los diagramas de ejemplo que figuran en este apunte no tienen estado inicial. Esto es para
mantener la claridad y resaltar lo que se está explicando. Pero es importante tener siempre en cuenta que
todo diagrama debe tener su estado inicial para mantener su determinismo.
3. Transiciones
Cuando evolucionan las condiciones dinámicas, los objetos cambian de estado siguiendo las reglas descritas
en la máquina de estados asociada a su clase. Los diagramas de máquinas de estado son grafos dirigidos.
Los estados están enlazados mediante conexiones unidireccionales llamadas transiciones. El pasaje de un
estado a otro es realizado cuando una transición es disparada por un evento que ocurre dentro del dominio
del problema. El cambio de un estado a otro es instantáneo, dado que el sistema siempre debe estar en un
estado conocido.
Es ta do A
Es ta do B
Figura 8. Transición entre el estado A y el estado B
Ingeniería de Software I
Pág. 3
Máquinas de estados y Statecharts
Las transiciones no necesariamente enlazan estados distintos. El siguiente ejemplo describe un fragmento de
un analizador léxico. El reconocimiento de unidades léxicas se realiza en el estado ‘Leyendo’. La máquina
de estado se mantiene en ese estado mientras todos los caracteres leídos son no separadores.
No es s eparador
Ley endo
S eparador
Si guiente es ta do
Figura 9. Parte de un analizador léxico
4. Eventos
Un evento corresponde a la ocurrencia de una situación dada dentro del dominio del problema. En contraste
con los estados que tienen duración, un evento es por naturaleza una información instantánea que debe ser
tratada inmediatamente. Un evento es usado para disparar el pasaje de un estado a otro. Las transiciones
especifican los caminos en la máquina de estado. Los eventos determinan qué camino debe ser seguido.
La especificación completa de un evento incluye:
•
El nombre del evento.
•
La lista de parámetros.
•
El objeto que lo envía.
•
El objeto que lo recibe.
•
La descripción y el significado del evento.
Empleado
Cum ple 65
Es contratado
Jubilado
Pierde el empleo
Desempleado
Cumple 65
Figura 10. Transiciones y eventos en el estado laboral de una persona
Ingeniería de Software I
Pág. 4
Máquinas de estados y Statecharts
5. Guardas
Una guarda es una condición booleana que puede validar o invalidar el disparo de la ocurrencia de un
evento.
Estado A
Evento[ Condición ]
Estado B
Figura 11. Ejemplo de condición de disparo
Las guardas hacen posible el mantenimiento del determinismo de una máquina de estado cuando muchas
transiciones pueden ser disparadas por el mismo evento. Cuando el evento toma lugar, las guardas – las
cuales deben ser mutuamente exclusivas – son evaluadas y entonces una transición es validada y disparada.
Supongamos, por ejemplo, que si una persona mayor de 59 años pierde su empleo es automáticamente
jubilada:
Empleado
Es contratado
Cumple 65
Pierde el empleo[ ≥ 60 años ]
Jubilado
Pierde el empleo[< 60 años ]
Desempleado
Cumple 65
Figura 12. Eventos y guardas en el ejemplo de la empresa
Ingeniería de Software I
Pág. 5
Máquinas de estados y Statecharts
6. Operaciones y Acciones
La relación entre las operaciones definidas en la especificación de clases y los eventos que aparecen en los
diagramas de estados es realizada usando acciones y actividades.
Cada transición puede ser etiquetada con el nombre de una acción a ejecutar cuando la transición es
disparada por un evento. Para respetar la semántica general de la transición, la acción es considerada
instantánea y atómica.
Es tado A
Evento / Acción
Es tado B
Figura 13. La acción es instantánea
La acción corresponde a una de las operaciones declaradas en la clase del objeto que va a recibir el evento.
La acción tiene acceso a los parámetros del evento y a los atributos del objeto.
Los estados también pueden contener acciones. Éstas son ejecutadas en la entrada o en la salida del estado o
cuando un evento ocurre mientras el objeto está en el estado.
Estado
entry /
on UnEvento( Argumentos )[Condición] /
exit /
Figura 14. Notación definida para acciones dentro de estados
La acción en la entrada al estado se ejecuta de forma instantánea y atómica justo cuando se entra al estado.
De la misma forma, la acción en la salida del estado se ejecuta cuando dispara una transición que determina
un cambio de estado. La acción ante un evento interno se ejecuta en la ocurrencia de un evento que no lleva
a otro estado. Un evento interno no dispara la ejecución de las acciones de entrada y de salida – entry y exit
– a diferencia de la ejecución de una auto-transición (self-transition).
Evento / Acción
A
entry: Acción de entrada
exit: Acción de salida
on Evento: Acción
≠
B
entry: Acción de entrada
exit: Acción de salida
Figura 15. Diferencia entre una transición implícita y una acción interna
Ingeniería de Software I
Pág. 6
Máquinas de estados y Statecharts
7. Actividades
Las acciones corresponden a operaciones con tiempo de ejecución despreciable. Una operación que toma
tiempo ejecutar corresponde a un estado más que a una acción. La palabra do indica una actividad, o sea,
una operación que lleva un tiempo no despreciable y que es ejecutada mientras el objeto está en una estado
dado.
Es tado C
do: U na operación
Figura 16. La actividad Una Operación transcurre dentro del estado C
En contraste con las acciones, las actividades pueden ser interrumpidas en cualquier momento. Esto se
deduce de la duración de una actividad (que lleva un tiempo no despreciable) en contraste con la calidad de
instantánea de toda acción. Inmediatamente que una transición de salida del estado es disparada. Algunas
actividades son cíclicas y sólo paran cuando es disparada una transición de salida. Otras actividades son
secuenciales y comienzan cuando se entra al estado (inmediatamente luego de la ejecución de las acciones
de entrada). Cuando una actividad secuencial llega a su fin, es posible dejar el estado si alguna de las
transiciones puede ser recorrida. Este tipo de transiciones no son disparadas por un evento y son llamadas
transiciones automáticas. Además pueden estar protegidas por guardas:
Es tado A
Es tado B
do: U na actividad s ecuencial
E s tado A
[ X]
E s tado B
do: Una ac tividad s ecuenc ial
[ not X ]
E s tado C
Figura 17. Actividades incluidas por estados
Ingeniería de Software I
Pág. 7
Máquinas de estados y Statecharts
8. Puntos de Ejecución de Operaciones
Hay seis lugares donde se pueden especificar operaciones (o actividades) que deben ser ejecutadas. Estos
son, en orden de ejecución:
•
•
•
•
•
•
Acción asociada a la transición de entrada al estado (Op1)
Acción de entrada al estado (Op2)
Actividad dentro del estado (Una Actividad)
Acción asociada a eventos internos (Op3)
Acción de salida del estado (Op4)
Acción asociada a la transición de salida del estado (Op5)
/ Op1
Un E s tado
entr y: Op2
do: U na A ct ividad
on Un E vento: Op3
ex it: O p4
/ Op5
Figura 18. Puntos de ejecución de operaciones
9. Generalización de Estados
La lectura de los diagramas de estado puede dificultarse bastante cuando el número de conexiones entre
estados pasa a ser alto. La solución para esta situación es aplicar el principio de generalización de estados:
los estados más generales son llamados superestados y los estados más específicos, subestados. Esto facilita
la representación y hace posible enmascarar detalles.
Las nociones de superestado y subestado se corresponden con el concepto de herencia de objetos. Un estado
puede descomponerse en varios subestados disjuntos donde los subestados heredan las características de su
superestado – en particular transiciones externas. La descomposición entre subestados también es llamada
descomposición disjuntiva (descomposición de tipo ‘or exclusivo’) dado que un objeto debe estar en un y
sólo un subestado en un momento dado. Mas adelante veremos un ejemplo de descomposición conjuntiva.
Los siguientes dos diagramas ilustran la simplificación que resulta de aplicar generalización de estados:
Ingeniería de Software I
Pág. 8
Máquinas de estados y Statecharts
Ag re g a r e s tud ian te [ C an t < 1 0 ] / C a n t = C a n t + 1
Inicia li zació n
Agreg a r es tu dia nte / Ca n t = 1
Ab rir
d o : Inicia lizar cu rs o
C an ce lar cu rs o
C a n ce la d o
d o: En via r avis o s de ca ncela ción
[ Ca n t = 1 0 ] /
C re a r R e p o rte
C a n ce la r cu rs o
C er rar
e n try: Fin a liza r cu rs o
Figura 19. Statechart que no utiliza conceptos de subestado y superestado
Registrac ión
Agregar estudiante[ Cant < 10 ] / Cant = Cant + 1
Inic ializ ac ión
A gregar es tudiante /
Cant = 1
Abrir
do: Inic ializ ar curs o
Canc elado
do: E nviar avis os de c anc elación
Cancelar c urso
[ Cant = 10 ] /
Crear Reporte
Cerrar
entry : Finaliz ar curs o
Figura 20. Statechart que utiliza conceptos de subestado y superestado
Utilizando subestados se simplifica y clarifica sensiblemente la notación y es una manera de evitar la
explosión de estados.
Nótese que el evento cancelar curso parte del estado Registración (independientemente de si el objeto se
encuentra en el subestado Abrir o subestado Cerrar).
Ingeniería de Software I
Pág. 9
Máquinas de estados y Statecharts
Act ivo
Cum ple 65
Empleado
Es contratado
Jubilado
Pierde el empleo
Desempleado
Figura 21. Estado Laboral de una persona utilizando generalización
Las transiciones de entrada no son heredadas por todos los estados. Sólo un estado (el superestado o alguno
de sus subestados) puede ser el destino de esta transición. Supongamos por ejemplo, que el estado B del
siguiente diagrama es dividido en dos subestados, B1 y B2. Los dos diagramas que le siguen son
equivalentes y válidos:
A
B
B
A
B1
B2
B
B1
A
B2
Figura 22. Statecharts equivalentes
Ingeniería de Software I
Pág. 10
Máquinas de estados y Statecharts
A veces, mostrar los subestados exhaustivamente pone demasiada información en los diagramas. El detalle
de los subestados puede ser ocultado para dar una perspectiva de alto nivel. Usando concentradores (stubs)
es posible mostrar que las transiciones de entrada dentro de un estado compuesto se refieren a un subestado
en particular, sin meterse en los detalles de la representación de este subestado. Esta técnica es consistente
con las ideas de information hiding, abstracción y con los conceptos de diseño a trazo grueso y trazo fino ya
vistos en la materia.
B
C
A
Figura 23. Ocultamiento de los estados internos de B
10. Agregación de Estados
Agregación de estados es la composición de un estado mediante varios estados independientes. La
composición es de tipo conjuntivo (composición de tipo ‘and’) lo que implica que el objeto debe estar
simultáneamente en todos los estados que constituyen la agregación. La agregación de estados corresponde
a un tipo de paralelismo entre máquinas de estado.
El siguiente ejemplo ilustra diferentes vistas del concepto de agregación de estados. El estado S es una
agregación compuesta por los estados independientes T y U. T está compuesto por los subestados X, Y y Z,
y U está compuesto por los subestados A y B. El dominio de S es el producto cartesiano de T y U.
S
T
X
U
E1
A
Y
E3
E1
E4[ in Z ]
Z
E2
B
Figura 24. Conjunción entre los estados T y U
Una transición de entrada al estado S implica la activación simultánea de las máquina de estado T y U,
quedando el objeto en el estado compuesto (Z, A). Cuando el evento E3 ocurre, las máquinas de estado T y
U pueden seguir evolucionando simultáneamente. Agregando condiciones a las transiciones, como la guarda
[in Z] en la transición de A a B permite introducir relaciones de dependencia entre los componentes de la
Ingeniería de Software I
Pág. 11
Máquinas de estados y Statecharts
agregación. Cuando el evento E4 ocurre la transición de A a B sólo es válida si el objeto está también en el
estado Z en ese momento.
Es importante notar en el ejemplo anterior que el sincronismo entre estados disjuntos no es obligatorio (a
diferencia, por ejemplo de otros modelos de Maquinas de Estados Finitos como las Redes de Petri).
Mientras en estas últimas se exige una presencia obligatoria en todos los estados que deben sincronizarse
para que se dispare la transición. Siguiendo con el ejemplo anterior. Si nos encontramos en el estado (X, A)
y ocurre el evento E1 el estado instantáneo siguiente será (Y,A) y no debe leerse que la transición E1 deba
estar habilitada en ambos subestados (o sea (X, B)) para poder dispararse.
La agregación de estados, junto con generalización de estados, simplifica la representación de las máquinas
de estados. La generalización simplifica factorizando y la agregación simplifica segmentando el espacio de
estados.
11. Historia
Por omisión, una máquina de estados no tiene ninguna memoria. La notación especial H ofrece un
mecanismo para memorizar el último subestado visitado y volver a éste cuando una transición vuelve a
entrar al superestado que lo contiene. El indicador de historia se aplica al nivel en el cual el símbolo está
declarado.
Lavando
E njuagando
S ecan do
H
A brir puerta
E s perar
Cerrar puerta
Figura 25. Indicador de memora. El statechart recuerda lo último que estaba haciendo al abrir la puerta
También es posible memorizar el último subestado activo, independientemente de su nivel de profundidad.
H*
Esto se indica mediante el símbolo
. Los niveles de memoria intermedios son obtenidos poniendo un
H
en cada nivel jerárquico. En el siguiente ejemplo, el estado A memoriza el último subestado
símbolo
activo, independientemente del anidamiento de los subestados:
A
B
C
C1
C2
H*
Figura 26. Propagación del marcador de historia hacia los estados internos
Ingeniería de Software I
Pág. 12
Máquinas de estados y Statecharts
12. Transiciones temporizadas
Por definición, las demoras son actividades que duran un cierto tiempo. Una demora está, entonces,
naturalmente relacionada con un estado más que con una transición y se representa usando una actividad de
demora. La actividad de demora se interrumpe cuando el evento esperado ocurre. De hecho, este evento
dispara una transición la cual produce que el estado que contiene la actividad de demora sea abandonado. El
siguiente ejemplo ilustra una secuencia de demora de un cajero automático. Cuando el buzón que acepta los
depósitos se abre, el sistema le avisa al usuario que tiene tres minutos para realizar su depósito. Si el
depósito se realiza dentro de los tres minutos, la actividad de demora es interrumpida disparando la
transición hacia el estado B. En cambio, si el depósito no es realizado dentro del tiempo dado, la transición
automática hacia el estado de cancelación es disparada al final de la actividad de demora. En ambos casos,
el buzón se cierra por la acción de salida del estado de demora.
A
/ A b ri r b uzó n
E spe ra r po r e l d e pó si to
e n try: M o strar m e n sa j e
d o : Esp erar 3 m i nu to s
e x i t: C e rrar el b u z ó n
Ca nce l a r tra nsa cci ó n
S e re a l i zó e l de p ósi to
B
Figura 27. Finalización de un estado por una demora
Las temporizaciones pueden ser representadas usando una notación más compacta, la cual está atada
directamente a la transición que se dispara luego de la demora. El evento disparador tiene el nombre
genérico after y su parámetro especifica la duración de la temporización:
after(duración_demora)
El ejemplo anterior podría reescribirse con esta notación de la siguiente forma:
A
/ A b ri r b u zó n
E sp erar p or e l de p ósi to
afte r( 3 m i n u to s )
Ca nce l a r tra nsa cci ó n
en try: M o strar m e n sa j e
exi t: Ce rra r el b uzó n
S e rea l i zó e l de p ósi to
B
Figura 28. Disparo de un evento por una demora
Ingeniería de Software I
Pág. 13
Máquinas de estados y Statecharts
13. Introducción al Metamodelo
Una máquina de estados representa el comportamiento resultante de las operaciones ejecutadas luego de una
secuencia de cambios de estado. Una máquina de estados puede ser mostrada de acuerdo al punto de vista
del estado (mediante diagramas de statecharts) o de la acción (mediante diagramas de actividad). Una
máquina de estado especifica el comportamiento de una colaboración.
M áqui na de estado s
1
1
2ULJHQ
*
1..*
E s tado Vé rt ic e
Trans ic ión
1..*
P s eudo-estado
: {inicial, final, his toria}
*
*
'HVWLQR
*
*
E s tado
0..1
Figura 29. Metamodelo
1..2
Tipos de Evento
La ejecución de una instancia de una máquina de estados no puede ser interrumpida. En cualquier momento,
una máquina de estados debe reaccionar a un evento particular que la mueve de un estado estable a otro
estado estable. La ejecución de una máquina de estado comienza con el pseudo-estado inicial y continúa,
evento por evento, hasta que un pseudo-estado final no anidado es alcanzado.
Los eventos disparan transiciones. El disparo de una transición lleva a la máquina de estados del estado
origen al estado destino.
UML define tres tipos diferentes de eventos:
•
Eventos de Señal, causados por una señal
•
Eventos de Llamada, causados por una operación
•
Eventos de Tiempo, causados por la expiración de la demora de un timer
Ingeniería de Software I
Pág. 14
Máquinas de estados y Statecharts
El siguiente diagrama representa transiciones, sus acciones, y los diferentes eventos que las disparan:
+ E fec to
Trans ic ión
A c c ión
1
0..1
1
+ D is paro
0..1
E vento
E ventoS eñal
*
0..1
S eñal
E ventoLlam ada
E vent oTiempo
*
0..1
*
0..1
O perac ión
E x pres ión
Figura 30. Semántica y descomposición de eventos según el metamodelo
Para mas información acerca del metamodelo de todas las técnicas ver el UML
Ingeniería de Software I
Pág. 15
Máquinas de estados y Statecharts
Preguntas frecuentes
¿Qué representa un estado de un statechart?
Representa una imagen instantánea del sistema
En UML, un estado es la imagen instantánea de la combinación de los valores contenidos en los
atributos del objeto y la presencia o ausencia de relaciones entre dicho objeto y otros objetos.
¿Qué diferencias hay entre una statechart y una máquina de estados finitos?
Un statechart es una máquina de estados finitos (o finite state machine – FSM) jerárquica que soporta
los conceptos de ortogonalidad, agregación y generalización.
Generalización: un estado puede ser descompuesto en diferentes subestados disjuntos, donde los
subestados heredan las características de su superestado, en particular, transiciones externas.
Agregación: es la composición de un estado por medio de varios estados independientes.
Mi sistema no es un sistema reactivo, ¿debo usar igual statecharts?
Para sistemas transformacionales (aquéllos cuyo comportamiento consiste básicamente en transformar y
manipular datos), lo que hay que expresar es la transformación o función que se le aplican a los datos, lo
cual puede reflejarse con una relación entre la entrada y la salida. Igualmente, puede ser interesante el
modelar ciertas partes del sistema con statecharts como ser el comportamiento de la interfaz del usuario
o la forma de encadenar las operaciones sobre los datos.
¿Qué puedo tomar como eventos del sistema?
Los eventos pueden ser cambios de estados en alguno de los componentes del sistema o eventos
generados por entidades que interactúan con el sistema. Dentro del evento no debería considerarse
condiciones sobre otros elementos del sistema pues puede no hacer visibles estados posibles del sistema,
dejando la especificación muy ambigua. Además esto atenta contra la agregación y ortogonalidad de los
statecharts.
Supongamos por ejemplo, una máquina expendedora de boletos con los siguientes eventos: ‘Se inserta
moneda de 1 peso y el chofer presionó botón de boleto de 65 centavos’ y ‘Se inserta moneda de 1 peso y
el chofer presionó botón de boleto de 70 centavos’. ¿Puede pasar que el chofer presione el botón de
boleto de 65 centavos pero no se inserte ninguna moneda? Si pasa, ¿qué hay que hacer? Estas
‘ambigüedades’ se podrían salvar más fácilmente tomando los eventos ‘Se inserta moneda de 1 peso’,
‘Chofer presiona botón de boleto de 65 centavos’ y ‘Chofer presiona botón de boleto de 70 centavos’.
¿Todo objeto tiene que tener asociado un statechart?
Los objetos que no presentan un pronunciado comportamiento reactivo pueden ser considerados como si
siempre estuvieran en el mismo estado. En este caso, sus clases no poseen un statechart.
¿Es obligatorio que un statechart tenga un estado inicial?
Dado que un statechart es determinístico, no debe haber espacio para ninguna ambigüedad. Esto
significa, en particular, que siempre es necesario describir el estado inicial del sistema, el cual es único.
Dado que los statecharts pueden tener varios niveles jerárquicos (ver generalización), cada nivel
jerárquico debe tener un y sólo un estado inicial.
¿Una transición debe unir siempre diferentes estados?
No. Una transición puede reentrar al estado de donde sale.
Ingeniería de Software I
Pág. 16
Máquinas de estados y Statecharts
¿Qué diferencias hay entre un evento externo y uno interno?
La diferencia es que un evento interno no dispara la ejecución de las acciones de entrada y de salida, a
diferencia de una transición externa. Ahora, una transición externa puede reentrar al mismo estado de
donde sale, en cuyo caso sí se disparan las acciones de salida y de entrada.
¿En qué lugares se pueden especificar las operaciones que deben ser ejecutadas?
En total hay seis. En orden de ejecución son:
• Acción asociada a la transición de entrada al estado
• Acción de entrada al estado
• Actividad dentro del estado
• Acción asociada a eventos internos
• Acción de salida del estado
• Acción asociada a la transición de salida del estado
Referencias
•
David Harel. Statecharts: A Visual Formalism for complex systems. Science of Computer
Programming. Volumen 8, Nro. 3, Junio de 1987. Páginas 231 a la 274.
•
UML - Unified Modeling Language
•
Carlo Ghezzi, Mehdi Jazayeri y Dino Mandrioli. Fundamentals of Software Engineering. Prentice Hall.
1992. Páginas 167 a 188.
•
http://cui.unige.ch/Visual/statecharts.html Punteros a varias páginas de interés
Ingeniería de Software I
Pág. 17