STATECHARTS

• telefones, redes de comunicação de dados, sistemas operacionais,
• sistemas aviônicos, circuitos VLSI e
• as interfaces homem-máquina contidas em vários softwares.

Descrever o comportamento de sistemas complexos através dos seus estados e eventos pode ser considerada uma forma natural de abordagem, e por isto indicada, de proceder. Um fragmento básico desta descrição pode ser: "estando o sistema em um determinado estado A, quando um evento a a ocorre e neste mesmo momento uma condição C é verdadeira, então o sistema passa para o estado B".

Especificar sistemas do tipo reativo através da análise dos estados e eventos não é uma proposta nova. Já há algum tempo os Diagramas de Transição de Estado (DTE) baseados no formalismo conhecido como máquinas de estado finito têm sido utilizados com este propósito. O grande problema desta abordagem tradicional é a dificuldade de visualização quando usado na descrição de sistemas muito grandes e complexos, onde a multiplicidade de estados e transições entre estes estados cresce de forma exponencial.

Para que uma técnica que pretenda representar um sistema reativo através dos seus estados e eventos possa ser considerada satisfatória, ela deve ser capaz de descrever eficientemente as seguintes situações:

• 1. "Estando o avião em qualquer estado, quando a alavanca amarela for acionada, o assento deverá ser ejetado".
• 2. "O estado da caixa de câmbio de um carro é independente do sistema de freios".
• 3. "Quando o botão de seleção é acionado, entrar no modo que foi selecionado".
• 4. "Modo-de-exibição consiste de exibição-da-hora, exibição-da-data e exibição-do-cronômetro".

A declaração 1, acima, necessita da capacidade de agrupar estados em um superestado (clustering). Se não houver esta habilidade, de todos os estados existentes no sistema aviônico, deveria partir uma seta para o estado "acento ejetado" gerando uma grande poluição visual no diagrama. A declaração 2 introduz o conceito de independência ou concorrência de estados. A declaração 3 sugere a necessidade de transições mais genéricas que uma simples seta identificando um evento. Por fim, a declaração 4 mostra a possibilidade de refinamento de estados.

STATECHARTS atende a todas estas necessidades de especificação.

Os conceitos básicos modelados por STATECHARTS são:

Estado - é a situação em que um sistema se encontra em um determinado instante do tempo.

Evento - são acontecimentos que ocorrem tanto externamente ao sistema como internamente e que ao serem percebidos pelo sistema provocam transições de estado, isto é, o sistema passa de um estado A para um estado B.

Condição - é um predicado opcional associado a um evento que habilita o sistema a efetuar uma transição de estado. Em outras palavras, o sistema só passa de um estado para outro, caso ocorra um evento qualquer e se, e somente se, a condição associada for verdadeira no momento do evento.

PRINCIPAIS MECANISMOS DE STATECHARTS

Os principais mecanismos de modelagem disponibilizados por STATECHARTS são: clustering, refinamento, estado default, entrada-pela-história, concorrência e ações.

CLUSTERING

Analisando a Figura 1 encontramos os quatro estados A, B, C e D de um sistema qualquer (representados por retângulos com cantos arredondados) e uma série de setas indicando os eventos que transferem o sistema de um estado para outro. Os estados na forma como estão representados são mutuamente exclusivos entre si, isto é, o sistema não pode estar em mais de um deles ao mesmo tempo.

Figura 1

No exemplo da Figura 1, o sistema pode assumir o estado D vindo, ou do estado A, ou de B, ou de C, basta que quanto estiver em um destes três últimos estados, ocorra o evento a. Portanto, os estados A, B e C possuem uma característica em comum: a transição para D provocada. pelo evento a. Esta característica permite que se agrupem os três estados A, B e C em um superestado E, como mostra a Figura 2.

Figura 2

Note-se que as três setas referentes ao evento a que existiam na situação anterior (Figura 1) foram substituídas por apenas uma, partindo do contorno do superestado E.

Na Figura 2, os estados A, B e C contidos no superestado E são mutuamente exclusivos entre si, o que configura um OR-exclusivo. A criação do cluster E é apenas em função do evento a, não afetando a forma como os eventos b e c são representados. Quando ocorre um clustering, as setas representando os eventos não envolvidos "penetram" no contorno do superestado, indo até o (ou vindo do) estado a que se referem.

O exemplo dado mostra claramente a característica bottom-up do mecanismo de clustering, pois partiu-se de estados mais básicos para formar um estado mais abrangente.

Figura 3 - Refinamento

REFINAMENTO

É o processo inverso do clustering, isto é, funciona de forma top-down. Partindo de um estado mais abrangente, identificam-se os possíveis estados componentes. Supondo que um especificador quando estiver descrevendo o comportamento de um sistema, tenha chegado à representação mostrada na Figura 3a, onde dois estados (E e D) e três eventos (a, b e c) foram identificados. Na busca de um melhor detalhamento (refinamento) este especificador concluiu que o estado E na verdade é um conjunto de três subestados A, B e C (Figura 3b). Aos detectar estes novos três estados, analisou novamente os eventos e notou que apenas o evento a relacionava-se com todos eles; notou também que o evento b relacionava-se apenas com o estado B e o evento c apenas com o estado C. Para resolver isto, estendeu as setas representativas dos eventos b e c atravessando o contorno do estado E até os retângulos representativos dos estados B e C respectivamente, resultando na Figura 3c. Além disto descobriu mais alguns eventos que ocorriam no interior de E, entre os subestados recém identificados. Ao incluir estes novos eventos no seu diagrama, o especificador chegou à situação apresentada na Figura 2.

ESTADO DEFAULT

Supondo um determinado superestado E composto dos subestados A, B e C. Caso ocorra um evento f que resulta em uma transição para este superestado, o sistema entrará naquele subestado indicado como default, ou seja, no subestado B.

Graficamente um estado default deve ser representado como mostra a Figura 4, ou seja, através de uma pequena seta apontando para ele.

Figura 4 - Estado E, contendo o Estado default B

O sistema só não entrará no estado default se houver uma outra indicação em contrário.

No caso da Figura 4, caso ocorra o evento c, o sistema não respeita o default e vai para o estado C, pois trata-se de uma transição explicitamente indicada.

Existem duas formas de se representar um estado default, uma direta e uma outra em dois tempos. As duas, entretanto, são equivalentes. A Figura 5a mostra a forma direta e a Figura 5b mostra a forma em dois tempos.

Figura 5 - Duas formas de representar estados default

Na Figura 5a, B1 é o estado default em relação a tudo que estiver dentro de E. Agora, na Figura 5b, em primeiro lugar o superestado B é default em relação a A e C e, em segundo lugar, B1 é default em relação a B2 e B3.

ENTRADA-PELA-HISTÓRIA

(Enter-by-History)

Entrada-pela-história significa que o sistema ao reentrar em um superestado, vai entrar no seu subestado mais recentemente visitado. O sistema precisa para tanto ter a capacidade de "lembrar" qual é este último estado visitado. A entrada-pela-história é representada graficamente pela letra H dentro de um pequeno círculo.

A Figura 6a serve como exemplo para mostrar como funciona a entrada-pela-história.

Figura 6 - Canectivo "entrada-pela-história"

Quando o sistema entra em K, ou ele vai para G ou para F. Irá para G se, na última vez que esteve em K, foi em visita a um dos subestados de G, ou seja A ou B. lrá para F se, na última vez que esteve em K, foi em visita a um dos subestados de F, ou seja, C, D ou E. Se o sistema for para G, na verdade vai para B que é o subestado default dentro de G. Se for para F, vai para o subestado default C.

Uma forma de ignorar os estados default quando se usa a entrada-pela-história é mostrada na Figura 6b onde o H aparece em companhia de um asterisco. Neste caso o sistema entra no último estado básico visitado do cluster. No caso da Figura 6b, se na visita anterior a K o último estado visitado tenha sido D, então quando se reentrar no superestado K na próxima ocasião, entra-se em D.

A entrada-pela-história pode ocorrer em mais de um nível como mostra a Figura 6c, onde o sistema ou entra em G ou em F, dependendo de qual dos dois ele visitou por último. Se entrar em F, vai também "entrar-pela-história" pois o default C foi overriden, isto é, vai entrar ou em E, ou em D, ou em C, conforme tenha sido o último estado visitado.

A entrada-pela-história não se aplica quando é a primeira vez que se está entrando em um superestado, pois, obviamente, não houve visita anterior a este superestado. Neste caso vale o estado default.

CONCORRÊNCIA (ou ORTOGONALIDADE)

Em muitos casos, principalmente em sistemas complexos, o especificador precisa representar conjuntos de estados concorrentes, tais como o conjunto de estados do sistema de câmbio de velocidades de um automóvel que existe em paralelo com o seu sistema de freios. Um método eficiente de especificação deve fornecer mecanismos para que se possa representar situações deste tipo.

Figura 7 - DTE para dois conjuntos de estados concorrentes {B,C} e {E,F,G}

Um dos motivos que desestimulou o uso dos diagramas de estados tradicionais foi exatamente a dificuldade que apresenta quando se precisa tratar estados concorrentes. Para ilustrar esta dificuldade, tome-se como exemplo um sistema Y que apresenta dois conjuntos de estados concorrentes. O primeiro contendo os estados B e C, e o segundo contendo os estados E, F e G. A Figura 7 mostra como ficaria a representação em DTE clássico. Observar que, a cada momento, o sistema está em um estado do primeiro conjunto e também está, necessariamente, em um estado do segundo conjunto.

O mesmo sistema Y pode ser representado de maneira mais "enxuta", utilizando-se STATECHARTS como é mostrado na Figura 8. A notação usada para representar concorrência é um splitting de um cluster em tantos "compartimentos" quantos forem os conjuntos concorrentes de estados, através de separação de áreas por linhas tracejadas. No exemplo mostrado na Figura 8, dois conjuntos deste tipo são representados: o conjunto A e o conjunto D.

Pode ser percebido claramente que a quantidade de seis estados da Figura 7 é a mesma do produto cartesiano AÄD (2 x 3) da Figura 8. Se por acaso, em vez de 2 conjuntos, A possuísse 100 conjuntos e D, em vez de 3 conjuntos, possuísse 200, o resultado do produto cartesiano seria de 20 mil pares possíveis, o que tornaria uma correspondente representação em DTE clássico extremamente complicada.

Figura 8 - Statechart para dois conjuntos de estados concorrentes

Na Figura 8, é introduzida a notação de condição que pode opcionalmente acompanhar algum evento; é o caso do evento b seguido da condição in G, que faz com que, ao ocorrer o evento Mb, o sistema mude de estado de C para B se, e somente se, o sistema também estiver no estado concorrente G. Portanto, o sistema permanece em C, mesmo ocorrendo o evento b, caso esteja em E ou F e não em G.

Ortogondidade pode ser ententida com um AND entre dois ou mais conjuntos. Na Figura 8, por exemplo, sempre em um determinado momento do tempo o sistema apresenta um par de estados. Começa com o par B-and-F que são os estados default de cada subconjunto concorrente do sistema Y. Se em seguida ocorre o evento a o sistema vai para o par de estados C-and-G e assim por diante.

Podem ocorrer situações onde um evento afeta apenas um dos subconjuntos de Y, por exemplo, se o sistema estiver no par de estados C-and-G e ocorrer o evento d, então o sistema continua em C e muda de G para F, passando a apresentar um novo par de estados: C-and-F.

AÇÕES

Em STATECHARTS, além de especificar estados e transições, é possível também descrever as ações que ocorrem dentro do sistema a partir dos eventos.

Uma ação é representada associada a um evento e a sua notação é "x / S" onde x é o evento gatilho e S é uma ação executada. Por definição, uma ação é algo instantâneo, que não gasta tempo, enquanto que uma atividade dura um certo tempo. Por exemplo, podemos ter unia ação start (X) e uma ação stop (X) como marcos inicial e final de um atividade (X).

Uma ação também pode ser sentida pelo próprio sistema, isto é, pode se configurar em um evento a ser percebido em algum lugar do sistema. A Figura 9 mostra este fenômeno. Na primeira vez o sistema entra simultaneamente nos estados default B, F e J (trata-se de uma trinca de estados porque há uma ortogonalidade entre três conjuntos de estados). Em seguida ocorre o evento m que dispara a ação e. Como e é um evento que afeta o próprio sistema, ocorre uma transição de F para G e de B para C, fazendo com que o sistema passe a apresentar uma nova trinca de estados: C, G e I, numa espécie de reação em cadeia.

Esta capacidade de uma região "sentir" eventos internos ocorridos em outras regiões do sistema é possível graças à capacidade de broadcasting implícita ao formalismo STATECHARTS. Significa que além dos eventos do ambiente externo, também os eventos internos de um sistema podem provocar transições de estado.

CONCLUSÃO

O método STATECHARTS proposto por Harel realmente apresenta vantagens significativas sobre o DTE clássico, conseguindo representar situações que este último, ou não consegue, ou produz diagramas bastante intrincados. É o caso do tratamento de estados concorrentes e da capacidade de clustering.

Além disto, STATECHARTS pela sua abordagem visual e simplicidade de notação constitui-se em um excelente meio de comunicação entre o especificador e o usuário do sistema a ser projetado.

STATECHARTS aplica-se perfeitamente a sistemas de tempo real do tipo que reage a eventos, contudo atende perfeitamente à necessidade de especificação da interface homem-máquina de softwares em geral.

Figura 9 - Ações associadas a eventos provocando reação em cadeia

Referências bibliográficas:

[HAR 87a] HAREL, David. Statecharts: a visual formalism for complex systems. Science of Computer Programming, v. 8, p. 231-274, 1987.

[HAR 87b] HAREL, David. On visual formalisms. Rehovot: The Weizmann Inst. of Science, June 1987.

[RUM91] RUMBAUGH, J. et al. Object-oriented modeling and design. Englewood Cliffs: Prentice-Hall, 1991.

dante@celepar.gov.br