• Nenhum resultado encontrado

Geração do Occ

No documento Alexandre Scaico_Tese Final (páginas 102-106)

Capítulo 5 – Análises no Modelo

5.3 Geração do Occ

O Grafo de Ocorrência (Occ) do modelo foi gerado para permitir a verificação das propriedades lógicas do sistema. Inicialmente foi gerado o relatório padrão da ferramenta para análise. Esse relatório é apresentado a seguir.

Statistics --- Occurrence Graph Nodes: 89089 Arcs: 238595 Secs: 68 Status: Full Scc Graph Nodes: 8194 Arcs: 8194 Secs: 616 Boundedness Properties ---

Best Integers Bounds Upper Lower

End'Allow_Nav 1 1 0 End'Allow_Nav 2 1 0 Industrial_MMI'End 1 1 1 Industrial_MMI'Login 1 1 0 Industrial_MMI'MMI 1 1 0 Loc_Rem'Allow_Nav 1 1 0 Loc_Rem'Allow_Nav1 1 1 0 Loc_Rem'Local 1 3 0 Loc_Rem'Remote 1 3 0 Loc_Rem'Wait_Conf_Loc 1 1 0 Loc_Rem'Wait_Conf_Rem 1 1 0 Login'Allow_Nav 1 1 0 Navigation'Allow_Nav 1 1 0 Navigation'But_Close 1 1 1

Navigation'Options1 1 6 6 Navigation'Options2 1 1 1 Navigation'Win_Nav1 1 6 6 Navigation'Win_Nav2 1 1 1 Switch_Breaker'Allow_Nav 1 1 0 Switch_Breaker'Allow_Nav1 1 1 0 Switch_Breaker'CB_Close 1 3 0 Switch_Breaker'CB_Open 1 3 0 Switch_Breaker'Local 1 3 0 Switch_Breaker'Wait_Conf_Close 1 1 0 Switch_Breaker'Wait_Conf_Open 1 1 0 Switchgear'Allow_Nav 1 1 0 Switchgear'Allow_Nav1 1 1 0 Switchgear'CB_Open 1 3 0 Switchgear'Local 1 3 0 Switchgear'SG_Close 1 6 0 Switchgear'SG_Open 1 6 0 Switchgear'Wait_Conf_Close 1 1 0 Switchgear'Wait_Conf_Open 1 1 0 Home Properties --- Home Markings: None

Liveness Properties

--- Dead Markings: 8192 [9996,9995,9989,9988,9981,...]

Dead Transitions Instances: None Live Transitions Instances: None

Analisando o relatório padrão é possível tirar algumas conclusões sobre o modelo do sistema. Como pode ser observado, a geração do grafo de ocorrência foi completa, o que significa que podemos fazer verificações em todo o espaço de estados do modelo.

Inicialmente são apresentados os valores máximo e mínimo de fichas em cada lugar do modelo. Analisando esses dados já obtemos um indicador se existe algum erro no sistema. Pode existir um erro se em algum lugar do modelo existirem mais ou menos fichas do que o esperado, sendo necessário a análise para determinar se o erro é decorrente do comportamento do sistema ou do processo de modelagem. Se o erro for do comportamento do sistema deve-se verificar como modificar o sistema para eliminar o erro. Para esse estudo, todos os lugares estão com seus limites máximo e mínimo dentro dos valores esperados.

Em seguida o relatório apresenta as marcações recorrentes, que são os estados do modelos sempre alcançáveis a partir de qualquer outro estado. Observamos que o relatório apresenta que não existem marcações recorrentes no sistema, embora fosse esperado que na interface todos os estados fossem recorrentes. Analisando essa propriedade observamos que não existem estados recorrentes devido à existência de diversos estados terminais, que são os estados de encerramento do aplicativo. Ao se recalcular o espaço de estados do modelo retirando do modelo a parte referente ao encerramento do aplicativo observamos que todos os estados são recorrentes e não existem estados de bloqueio no modelo. Isso também é esperado pois na interface do estudo de caso o operador do sistema sempre possui algum caminho que permita que ele chegue a qualquer estado desejado do sistema. E também não pode haver nenhum estado de bloqueio do sistema (a exceção dos estados ligados ao encerramento do aplicativo), pois isso indicaria a presença de um ou mais estados nos quais o operador não poderia mais interagir com o sistema, não podendo mais exercer as funções de comando e proteção.

Analisando os estados de bloqueio do sistema, a partir do relatório completo, verificamos que existem muitos estados terminais. Embora uma das propriedades de usabilidade que queríamos verificar indicava que o acesso à saída deveria estar sempre disponível, devemos pensar melhor nessa propriedade nesta classe de interfaces. Propomos que o acesso à saída nesse sistema só seja disponibilizado ao operador após a sua devida desautenticação. Propomos também que exista alguma forma do supervisor do sistema interromper uma sessão do operador em caso de falha do aplicativo, tendo ele o acesso à saída a partir de qualquer ponto para uso em uma eventual emergência. Não recomendamos essa característica aos operadores de modo a tornar mais seguro o uso do aplicativo, eliminando possíveis problemas de encerramento do aplicativo por um erro ou descuido do operador.

5.3.1 – Verificação das Propriedades de Usabilidade

Nesta subseção apresentaremos o resultado da verificação das propriedades de usabilidade a partir da verificação das propriedades do espaço de estados do modelo. Elencaremos a seguir as propriedades e como ela foram, ou não, verificadas.

• Reinicialização – Essa propriedade é verificada analisando as marcações recorrentes do modelo (home markings). Se a marcação inicial do modelo fizer parte das marcações recorrentes então a reinicialização é possível. Como

mostramos que se tirarmos a parte do modelo referente ao encerramento do aplicativo todas as marcações do sistema são recorrentes, e atendo para o fato de que em operação normal o aplicativo não deve ser encerrado, concluímos que essa propriedade é atendida.

• Reversibilidade – Essa propriedade é passível de verificação utilizando a função

Reachable presente na ferramenta Design/CPN. Deve-se definir qual o caminho

direto e verificar se existe um caminho partindo do nó final até o nó inicial do caminho direto. Aqui cabe uma ressalva, nessa classe de interface não basta apenas que exista a possibilidade de reversibilidade, mas também devemos verificar quais as possibilidades disso ocorrer, de modo a verificar quais os casos corretos e quais os que implicam na ocorrência de erro de interação. Para se verificar esse fato devemos nos valer das funções auxiliares desenvolvidas para a análise de caminhos alternativos, que serão apresentadas na próxima seção. Mas, analisando apenas o fato de existir reversibilidade, como no modelo todos os estados são recorrentes (retirando-se a parte do modelo que trata do encerramento do aplicativo), podemos afirmar que existe reversibilidade entre todos os estados do sistema.

• Existência de caminhos de acesso entre pontos específicos da interação – Para estados específicos da interface utiliza-se a função Reachable para garantir essa propriedade. Mas para verificar se existe mais de um caminho entre estados específicos e para analisar quais os mais indicados, deve-se utilizar as funções auxiliares desenvolvidas para esse propósito. Mas, como podemos afirmar que todos os estados do modelo são recorrentes, podemos afirmar que existem caminhos entre todos os pontos da interface, atendendo essa propriedade para qualquer que sejam os estados escolhidos.

• Acesso à Saída – Conforme já mencionado, embora essa seja uma propriedade esperada para todos os estados do sistema, não consideramos aplicável a essa classe de sistemas. Na seção anterior já discorremos acerca dessa propriedade e quais as recomendações que propomos.

No documento Alexandre Scaico_Tese Final (páginas 102-106)