Capítulo 3 – Análise de Modelos da Interface
3.5 Diagrama de Seqüência de Mensagens (MSCs)
Gráficos de Seqüência de Mensagens (MSC – Message Sequence Charts) consistem em uma linguagem gráfica e textual para a descrição e especificação de interações entre componentes de um sistema. Eles descrevem a comunicação assíncrona entre instâncias e podem ser utilizados como uma especificação geral do comportamento de comunicação de
sistemas em tempo real [6]. Uma instância é uma entidade abstrata na qual pode-se observar parte da interação com outras instâncias ou com o meio-ambiente. No MSC uma instância é denotada por uma barra vertical. E o tempo ao largo de cada eixo transcorre do topo para a base [6].
Usualmente os projetistas que analisam a especificação de interfaces e os clientes do projeto não estão familiarizados com o formalismos de redes de Petri, assim, a explicação do comportamento destes componentes através de MSCs se torna uma abordagem muito útil. A representação de um evento por meio de uma mensagem é muito mais intuitiva do que a análise das marcações de um modelo CPN. A geração do MSC se dá através da criação de mensagens pré-definidas de acordo com a evolução da simulação do modelo, através da ocorrência das transições do modelo que possuem um código associado com a chamada da função que gera a mensagem.
Essa técnica de análise é complementar as simulações, pois aqui o projetista pode definir cenários representativos da evolução do sistema para mostrar para o usuário, sem ser necessário que o usuário tenha conhecimento sobre a evolução de modelos em redes de Petri coloridas. Neste caso o usuário abstrai o método formal e se concentra apenas na análise do significado das mensagens apresentadas no MSC, ficando a cargo do projetista a geração da simulação no modelo do cenário que irá gerar o MSC.
Na Figura 9 a seguir temos, o exemplo de uma parte de um MSC construído a partir da ferramenta Design/CPN e da biblioteca MSC, disponível em [21].
O exemplo da Figura 9 apresenta três instâncias representando três estados de elementos hipotéticas. Na evolução do modelo correspondente, a ocorrências das transições, que modelam a mudança de estados dos elementos, faz com que as mensagens correspondentes a essas mudanças sejam criadas no MSC, conforme pode ser visto na figura.
Figura 9: Exemplo de um MSC
3.5.1 – Geração do Occ
O grafo de ocorrência (Occ) consiste em um grafo contendo um nó para cada marcação alcançável e um arco para cada elemento de ligação entre nós [49], ou seja, representa o espaço marcações alcançáveis do modelo CPN. A partir do grafo de ocorrência é possível se realizar verificações no espaço de estados do modelo. E essas verificações podem ser realizadas a partir de funções já presentes na ferramenta de geração do grafo de ocorrência do Design/CPN ou podem ser criadas novas funções (usando as funções existentes como base) para auxiliar nas verificações.
Ao ser gerado o Occ do modelo a ferramenta disponibiliza um relatório padrão contendo informações sobre [20]:
- As estatísticas em relação ao grafo gerado (tamanho do grafo, número de nós e arcos e completude da geração);
- Propriedades de limitação: valores máximos e mínimos de fichas nos lugares do modelo (em termos absolutos ou em função das cores);
- As marcações recorrentes do sistema (home markings);
- Propriedades de vivacidade: lista as marcações mortas, as transições que nunca ocorrem, etc.
Em relação às funções de verificação de propriedades disponibilizadas pela ferramenta podemos citar as que verificam propriedades de alcançabilidade, limitação,
recorrência, vivacidade e equidade. Além disso, existem outras funções que são disponibilizadas para facilitar o desenvolvimento de funções customizadas pelo projetista do modelo, dentre as quais podemos citar a função SearchNodes, que é uma função que percorre todo o grafo de ocorrência verificando um predicado definido pelo projetista. Maiores informações sobre a ferramenta de geração e análise do grafo de ocorrência do Design/CPN e suas funções de verificação podem ser encontradas em [20].
Então, como pode ser observado, o grafo de ocorrência permite uma ampla verificação do modelo, cabendo ao projetista a tarefa de definir quais propriedades deseja verificar, limitando o escopo da análise, e como interpretar esses resultados de modo a garantir as propriedades que o modelo do sistema deve atender.
A partir da análise do relatório do Occ podemos verificar algumas propriedades do modelo. Inicialmente podemos verificar se os valores, máximo e mínimo, das fichas nos lugares do modelo estão de acordo com o esperado. Se em um dado lugar existirem menos ou mais fichas do que o esperado, é necessário a analise para determinar se esse erro é decorrente de um comportamento não esperado do sistema ou de um erro de modelagem. Se for um comportamento não esperado, deve-se analisar o causa do erro, retrabalhar o modelo e propor as soluções no projeto da interface. Se o erro for de modelagem, o modelo deve ser corrigido e novamente analisado.
Em seguida deve-se observar as marcações recorrentes e os estados de bloqueio do sistema, verificando se estão de acordo com o comportamento esperado do sistema. Caso não estejam, deve-se observar a causa do erro e corrigir, da mesma forma explicada para o caso dos limites máximo e mínimo de fichas.
Ao verificar as marcações mortas do modelo, por exemplo, deve-se analisar o que significam e se são um comportamento esperado do sistema, corrigindo o erro caso contrário. Normalmente as marcações mortas devem estar relacionadas com a saída do aplicativo, não sendo válido outros tipos de impasses no sistema, ou seja, afora o encerramento do aplicativo não devem existir outros tipos de estados de bloqueio do modelo.
A análise do grafo de ocorrência permite também a verificação das propriedades de usabilidade já citadas, a partir do modelo. Na definição das propriedades também estão definidos quais as propriedades do modelo que devem ser utilizadas para a verificação.
Porém, as funções disponibilizadas pela ferramenta não permitem a análise de caminhos alternativos de interação, tendo sido necessário a concepção de um conjunto de funções específicas para essa tarefa, conforme apresentamos na seção a seguir.