umaferramentagrÁficapara … · 2014-08-04 · hippler, a. r.. a graphical tool for modeling and...

ALEXANDER RIEGER HIPPLER

UMA FERRAMENTA GRÁFICA PARAMODELAGEM E DISCRETIZAÇÃO DE

SISTEMAS DE TEMPO REAL

LONDRINA–PR

2013




Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

Orientador: Prof. Dr. Adilson Luiz Bonifacio

LONDRINA–PR

2013

Alexander Rieger HipplerUma Ferramenta Gráfica para Modelagem e Discretização de Sistemas de

Tempo Real/ Alexander Rieger Hippler. – Londrina–PR, 2013-46 p. : il. (algumas color.) ; 30 cm.

Orientador: Prof. Dr. Adilson Luiz Bonifacio

– Universidade Estadual de Londrina, 2013.

1. Sistemas de tempo real. 2. Teste baseado em modelos. I. Adilson LuizBonifacio. II. Universidade Estadual de Londrina

CDU 02:141:005.7




Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

BANCA EXAMINADORA

Prof. Dr. Adilson Luiz BonifacioUniversidade Estadual de Londrina

Orientador

Profa. Dra. Jandira Guenka PalmaUniversidade Estadual de Londrina

Prof. Dr. Wesley AttrotUniversidade Estadual de Londrina

Londrina–PR, 06 de Dezembro de 2013

LONDRINA–PR2013

Aos meus pais, que foram a razão de todas as minhas conquistas

AGRADECIMENTOS

Em primeiro lugar agradeço aos meus pais, Franz Hippler Neto e Margot AstridRieger Hippler, por serem exemplos de pessoas durante toda a minha vida e por todoo apoio e dedicação que me deram não somente na graduação, além de me ensinar queesforço e persistência são muito importantes para obter sucesso nos objetivos. Aos meusirmãos Fernando e Franz Walter, e minhas cunhadas, Nataniela e Naissa, por toda amotivação dada durante os últimos anos.

Agradeço ao meu orientador, o professor Adilson Luiz Bonifacio, por toda a paciên-cia e inúmeras horas de revisão de textos. Foi um prazer imenso e uma ótima experiênciaos últimos dois anos em que trabalhamos juntos.

Muito obrigado à minha namorada Laura pelo empenho em me manter motivadodurante os últimos anos, do vestibular à formatura. A todos os colegas de sala que tivena graduação, mas especialmente Matheus, Jéssica, Cezar, João José, Vinicius, Fredericoe Rodrigo, que participaram comigo dos momentos mais difíceis e dos cronogramas maisapertados.

Aos meus avós, Opa Walter e Oma Ingrid. Sem dúvidas o respeito e o interesse devocês pelas minhas conquistas, por menores que fossem, me motivaram muito a querercada vez mais. Ao meu amigo de infância, Matheus Bergamasco, por ter me ajudado emtodas as vezes que precisei, por mais longe que estivesse.

Aos meus colegas de trabalho na Guenka: Renan, Marcelo, Ernesto, Samuel, João,Thiago, Ricardo e Bruno, e também à Jandira, por me conceder essa oportunidade. Aexperiência obtida nos últimos meses ajudou muito no desenvolvimento desse trabalho.

"Mar calmo nunca fez bom marinheiro"Autor Desconhecido

HIPPLER, A. R.. Uma Ferramenta Gráfica para Modelagem e Dis-cretização de Sistemas de Tempo Real. 46 p. Trabalho de Conclusão deCurso (Graduação). Bacharelado em Ciência da Computação – UniversidadeEstadual de Londrina, 2013.

RESUMO

O processo de teste possui um papel fundamental no ciclo de vida de um software. Umaabordagem rigorosa bastante difundida são os testes baseado em modelos que utilizaformalismos para garantir maior precisão na análise e geração de casos de teste parasistemas críticos. Sistemas críticos e de tempo real, em geral, possuem execução comrestrições de tempo onde uma falha pode acarretar grandes prejuízos. Existem algumastécnicas específicas para lidar com sistemas dessa natureza, devido à dificuldade de serepresentar a evolução contínua de tempo em sistemas computacionais. Um modelo quecaptura os aspectos de um sistema de tempo real são os chamados Timed Input OutputAutomata (TIOA). Conjuntos de teste podem ser extraídos de um TIOA através do seumodelo discretizado, que ainda é capaz de lidar com os aspectos de tempo e suas restrições.Esse trabalho propõe o desenvolvimento de uma ferramenta que proporciona a modelagemde modelos TIOA, possibilita sua discretização e ainda facilita o processo de extração detestes para sistemas dessa natureza.

Palavras-chave: modelos. tioa. sistema de tempo real. discretiza-ção.modelagem.teste de software

HIPPLER, A. R.. A Graphical Tool for Modeling and Discretizationof Real Time Systems. 46 p. Final Project (Undergraduation). Bachelor ofScience in Computer Science – State University of Londrina, 2013.

ABSTRACT

The testing process is an important step of a software life cycle. A well-known rigorousapproach is model-based testing that uses formalisms to ensure more accuracy on test casegeneration and analysis for critical systems. Critical and real-time systems, in general,deal with time restrictions in its execution, where a fault can cause large losses. Thereare some proposed techniques to deal with systems of this nature, since the continuoustime evolution is non-trivial issue on computational systems Such aspects of real-timesystems can be captured by Timed Input Output Automata (TIOA). Test suites can bethen extracted from a TIOA model following its subjacent discretized model that is ableto cope with time aspects and its restrictions. This work proposes the development of agraphical tool in order to manipulate and discretize TIOA models, as well as to ease thetest case extraction for systems of this nature.

Keywords: models. tioa. real time system. discretization. modelling. softwaretesting

LISTA DE ILUSTRAÇÕES

Figura 1 – Processo de teste de software baseado em modelos . . . . . . . . . . . . 21Figura 2 – Modelo TIOA de um sistema de controle de porta automática . . . . . 23Figura 3 – Trecho do grid obtido da discretização do modelo mostrado em 2 . . . 25Figura 4 – Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 5 – Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 27Figura 6 – Pacote GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 7 – Pacote TIOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 8 – Pacote Junglayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 9 – Pacote GRID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 10 – Pacote Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figura 11 – Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 12 – Diagrama de Sequencias . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figura 13 – Janela Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 14 – Alterando propriedades de um estado e de uma transição . . . . . . . . 36Figura 15 – Discretização de modelos TIOA . . . . . . . . . . . . . . . . . . . . . . 36Figura 16 – Discretização de modelos TIOA concluída . . . . . . . . . . . . . . . . 37Figura 17 – Extração de casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 18 – Extração de casos de teste concluída . . . . . . . . . . . . . . . . . . . 38Figura 19 – Visualização de Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 20 – Exemplo de caso de teste . . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 21 – TIOA utilizado no caso de entrada #5 . . . . . . . . . . . . . . . . . . 41Figura 22 – Número de Estados no Grid . . . . . . . . . . . . . . . . . . . . . . . . 42Figura 23 – Número de Transições no Grid . . . . . . . . . . . . . . . . . . . . . . 42Figura 24 – Casos de Teste Extraídos . . . . . . . . . . . . . . . . . . . . . . . . . . 43

LISTA DE TABELAS

Tabela 1 – Entradas de análise da ferramenta . . . . . . . . . . . . . . . . . . . . 40Tabela 2 – Resultados obtidos com execuções das entradas descritas em 1 . . . . . 41

LISTA DE ABREVIATURAS E SIGLAS

TBM: Teste Baseado em Modelos;

TIOA: Timed Input Output Automata;

SUT: System Under Test;

IUT: Implementation Under Test;

UML: Unified Modeling Language;

BTDA: Bounded Time Domain Automata;

MEF: Máquina de Estados Finitos.

LISTA DE SÍMBOLOS

𝑆: conjunto de estados;

𝑠0: estado inicial;

Σ: o conjunto de símbolos de ação;

𝐶: conjunto de relógios de um modelo;

Φ𝑐 condição de relógio, pode ser associada a um estado ou transição;

𝑇 : conjunto de transições entre estados do modelo;

𝑣0: mapeamento de relógios do modelo para respectivos valores iniciaisde execução. É um conjunto de interpretações 𝑣(𝑐), ∀𝑐 ∈ 𝐶;

𝐼𝑛𝑣: mapeamento de invariantes de cada estado de um modelo. É umafunção 𝐼𝑛𝑣 : 𝑆 → Φ𝑐 que mapeia cada condição de relógio de umestado;

[𝐶 y Q ≥]: mapeamento associado a uma transição de modelo queindica quais valores serão reiniciados ao executar a transição;

𝐼: ações de entrada do conjunto Σ;

𝑂: ações de saída do conjunto Σ;

𝑔: granularidade de tempo.

SUMÁRIO

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . 16

3 Fundamentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.1 Teste Baseado em Modelos . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 TIOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Discretização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

14

1 INTRODUÇÃO

Conforme a computação se firma na sociedade atual, a demanda por sistemas comrequisitos de tempo tornam-se mais comuns. Dentre esses sistemas existem variações comrelação a complexidade de suas funcionalidades e a necessidade de garantia dos requisi-tos. Sistemas críticos e de tempo real, em geral, são sistemas com restrições temporais ecom evolução contínua de tempo que, em caso de falha, podem resultar em danos irre-paráveis. Exemplos de sistemas com essas características são os microcomputadores quecontrolam motores automobilísticos, sistemas de controle de tráfego aéreo e sistemas mé-dicos. Parte dos sistemas críticos e de tempo real são desenvolvidos utilizando ferramentasconvencionais de implementação e validação. Na prática, muitos sistemas desse tipo sãodesenvolvidos utilizando linguagens de alto nível sem a preocupação de tratar o tempo deuma forma mais explícita, o que torna difícil verificar que as restrições temporais foramimplementadas [1]. Por isso, a etapa de teste em sistemas como estes possui um papelfundamental no ciclo de vida dos sistema. A exigência por segurança e confiabilidade emsistemas críticos e de tempo real vem crescendo rapidamente, e a relação destes itens coma correção temporal colocam em dúvida o uso de metodologias e ferramentas convencio-nais de teste e validação. Em geral, o teste de software consiste em aplicar um conjunto detestes à implementação para observar as reações obtidas do sistema, e então compará-lasàs reações esperadas conforme a especificação [2]. Estima-se que 30 a 50% do custo totalde desenvolvimento de um software seja decorrente da atividade de teste. A tendência éque esses esforços com testes aumentem devido aumento da complexidade dos sistemas etambém de sua qualidade [3].

Falhas em um sistema podem ser decorrentes de um mau entendimento do pro-blema a ser solucionado ou da solução proposta, problemas habitualmente encontrados nodecorrer do desenvolvimento de um software. Modelos formais são criados com o objetivode obter uma representação livre de ambiguidades. O Teste Baseado em Modelos (TBM)é uma abordagem de teste de software que utiliza rigor matemático. Várias abordagensdesse tipo vêm sendo propostas para facilitar a etapa de teste, como métodos automatiza-dos para extrair casos de teste mais precisos e eficientes [4]. Porém ainda existem poucasaplicações reais de Teste Baseado em Modelos [2, 5], principalmente para sistemas detempo real.

As técnicas de TBM visam reduzir os custos com teste de software, além de me-lhorar a qualidade e eficiência do processo. Os esforços concentram-se principalmente naexecução automática de teste e na geração automática de casos de teste. No entanto, ageração e execução de conjuntos de teste para sistemas temporizados acarretam maiorcomplexidade ao processo, e poucas técnicas e ferramentas lidam com este cenário. Uma

Capítulo 1. Introdução 15

das dificuldades é a modelagem de sistemas de tempo real e a representação satisfatóriada evolução contínua do tempo. O modelo Timed Input Output Automata captura os as-pectos de tempo, porém, extrair casos de teste diretamente de um TIOA é impraticáveldevido à dificuldade de lidar com tempo contínuo [6]. Para lidar com este problema vá-rios trabalhos propõem soluções baseadas na discretização dos modelos [7, 8, 9]. Modelosgerados através da discretização, como grafos de região de relógio [10, 11] ou grids [9, 2],capturam aspectos da execução dos sistemas de tempo real.

Neste cenário, este trabalho propõe o desenvolvimento de um ambiente gráficopara a modelagem de sistemas de tempo real baseada em TIOA. A ferramenta permitea discretização dos modelos TIOA e extração de dados de teste para sistemas de temporeal. A técnica implementada lida com o ajuste dos modelos para que as discretizaçõespossam ser tratáveis e ainda assim representativas.

O texto está organizado como segue: no capítulo 2 estão descritos trabalhos deoutros autores relacionados com o assunto abordado por este. O capítulo 3 possui defini-ções de termos e alguns temas importantes para um bom entendimento do trabalho. Jáno capítulo 4 estão informações referentes ao desenvolvimento da ferramenta proposta,tais como diagramas e alguns detalhes de implementação, além de informações sobre aferramenta pronta. Execuções feitas e algumas análises estão no capítulo 5. Por fim, ocapítulo 6 possui as considerações finais e conclusões do trabalho.

16

2 TRABALHOS RELACIONADOS

Existem diversos formalismos e ferramentas baseados em autômatos e modelos deestados para sistemas temporais [12]. Neste capítulo será abordada uma visão geral detrabalhos relacionados ao proposto.

Um modelo formal amplamente utilizado para sistemas de tempo real é o autômatotemporal definido por Alur e Dill [13, 14]. Neste tipo de abordagem, o modelo é ummulti-grafo finito orientado com um conjunto finito de variaveis de relógio, chamado dew-automata. Cada estado do grafo consiste em uma localização e um conjunto de valorespara os relógios do sistema.

Para a discretização, Alur e Dill utilizam uma granularidade de tempo baseada naquantidade de regiões de relógio do modelo. Região de relógio é um conjunto de valoresdado através das restrições impostas aos relógios do modelo [13, 10]. Como a granularidadedepende do número de regiões de relógio, um modelo com muitas regiões vai possuir umagranularidade fina, o que pode resultar num crescimento exponencial no número de estadosdo sistema e então tornar impraticável sua utilização [6].

Lynch et al. [12] propõem o modelo formal Timed Input Output Automata (TIOA)para representar a continuidade do tempo em sistemas de tempo real. En-Nouaary [10]e Springintveld [15] propuseram métodos de cobertura de falhas para sistemas temporaismodelados em TIOA. En-Nouaary também trabalha em [8] uma abordagem que modificaa estrutura do TIOA. Neste modelo, as verificações das transições são feitas apenas emalguns momentos definidos segundo os limites dos relógios, assim sendo, não é possívelgarantir que existem ou não falhas nas lacunas de tempo.

Bonifácio e Moura [9] desenvolveram um framework para discretizar modelosTIOA, onde pode ser utilizada uma granularidade de tempo mais grossa para a dis-cretização, reduzindo o número de estados do modelo discretizado. Contudo, a eficácia dométodo é dada por propostas de testes, o que restringe a conjunto de falhas detectáveis[6].

Bozga et al. [16] mostraram estudos de caso da aplicação KRONOS1, ferramentaque objetiva auxiliar no trabalho de designers de sistemas de tempo real a projetar es-pecificações de sistemas. Segundo o artigo, a ferramenta foi capaz de detectar falhas emsistemas que em testes prévios não foram encontrados.

A ferramenta desenvolvida no trabalho tem o objetivo de trabalhar a modelagemde sistemas em TIOA, modelo proposto por Lynch et al. [12]. Além disso, TIOAs podem1 desenvolvida em VERIMAG, um laboratório conjunto entre UJF, Ensimag e CNRS, disponível em

http://www.imag.fr/VERIMAG/PEOPLE/Sergio.Yovine/kronos/kronos.html

Capítulo 2. Trabalhos Relacionados 17

ser discretizados em grid utilizando o algoritmo de discretização proposto por Bonifácioe Moura [9] e, do grid gerado, casos de teste podem ser extraídos utilizando o algoritmotambém proposto por Bonifácio e Moura no mesmo trabalho.

18

3 FUNDAMENTAÇÃO

Este capítulo visa fundamentar os conceitos considerados importantes para o en-tendimento do trabalho.

3.1 Teste de Software

Testes em softwares são realizados para verificar a concordância entre uma espe-cificação e sua implementação, garantindo assim que um sistema ou uma seção específicadesempenhem seu papel esperado e, com uma especificação bem definida, que o sistemapossui um nível aceitável de falhas. Um teste de software pode ser classificado como sendode: Caixa-branca, ou teste estrutural, que verifica se a estrutura do sistema coincide coma estrutura especificada; e Caixa-preta, ou teste funcional, que analisa as saídas obtidasa partir de um conjunto de entradas.

Testes de caixa-preta são baseados nos requisitos funcionais de um sistema defi-nidos na etapa de análise. Funcionam a partir da óptica do usuário, ou seja, focam nassaídas produzidas para entradas específicas, sem se preocupar em como o sistema seráestruturado ou funciona.

Tais entradas fornecidas ao sistema são chamadas de casos de teste. Casos de testesão extraídos da especificação e são sequências de entradas do sistema onde o resultadoesperado da execução é conhecido. Com isso, ao aplicar um caso de teste à implementaçãodo sistema obtém-se um resultado que deverá estar em concordância com o resultadoesperado pela especificação, garantindo o funcionamento correto do sistema especificado.

Num conjunto de casos de testes, chamado de suite de testes, dois ou mais delespodem cobrir um mesmo comportamento do sistema, causando redundância no conjuntode teste [4]. Assim, uma suite de teste eficiente não depende apenas do número de casosde teste, mas sim da abrangência que essa suite possui.

3.1.1 Teste Baseado em Modelos

Nas abordagens mais tradicionais de teste os casos de teste são modelados utili-zando o apoio de linguagem natural. Utilizar abordagens desse tipo podem gerar ambi-guidades na interpretação, o que pode causar testes mal elaborados e aplicados e, conse-quentemente, falhas no software podem acabar não sendo identificados [4].

O teste baseado em modelos é uma abordagem de teste de caixa-preta onde oSUT(System Under Test) passa a ter seus aspectos representados por linguaguens bem

Capítulo 3. Fundamentação 19

definidas como UML, ou por um ou mais modelos formais, evitando assim o uso delinguagem natural.

Existem diferentes abordagens de teste baseado em modelos, dependendo do mo-delo utilizado, dos aspectos sendo testados, do nível do formalismo adotado e do quãoprofundo o sistema testado pode ser observado [3].

Segundo [3], alguns elementos são requisitos necessários para a aplicação do testebaseado em modelo:

Implementação: é a implementação do SUT, chamada de IUT (Implementation Un-der Test). A implementação não precisar ser apenas código-fonte, como pode ser tambémalgo físico, como um pedaço de hardware ou um sistema embarcado em algum equipa-mento.

Especificação: dita o que o SUT deve e não deve fazer. Para o TBM, a especifi-cação deve estar na forma de um ou mais modelos formais, ou seja, deve possuir valoressintáticos e semânticos formais. O teste se resume em comparar a implementação com aespecificação.

Conformance: para poder checar se a implementação está de acordo com a espe-cificação é necessário definir formalmente o que caracteriza a conformidade. Tal definiçãodeve relacionar a IUT e a especificação. Porém, como o IUT não é um objeto formal, elanão é passível de um raciocínio formal.

Para alcançar o raciocínio formal assume-se que qualquer implementação podeser representado por um conjunto de modelos formais. Esse pressuposto é chamado depressuposto de teste. Assim, a conformance pode ser expressada como uma relação formalentre os modelos de implementação e os de especificação.

Teste: através do ato de aplicar estímulos à implementação e observar suas respos-tas, é possível obter o comportamento da implementação. Cada experimento, consistindono estímulo a ser fornecido e na resposta esperada, caracteriza um caso de teste. A exe-cução do teste consiste em aplicar um caso de teste ao sistema. O sistema é consideradoaprovado no teste executado caso o comportamento observado esteja de acordo com oesperado. Caso contrário, o sistema é reprovado.

Teste de Conformance: consiste em uma suíte de teste em que a indicação de que osistema foi aprovado na execução de todos os testes implica que o sistema foi implementadoconforme o especificado. Uma suíte de teste com essa característica é dito completo.

Geração de testes: um algoritmo de extração de casos de teste a partir de umaespecificação é chamado de geração de teste. O algoritmo é dito completo se a suíte deteste gerada é completa para toda a especificação. A geração de teste é o aspecto maisbenéfico e visível do Teste Baseado em Modelos, visto que o TBM possibilita a automação


de geração em larga escala de casos de teste confiáveis.

Como a modelagem do sistema em modelos formais não depende exclusivamente daimplementação, as duas atividades podem ser feitas paralelamentes durante o decorrer doprojeto (veja Figura 1). Também é possível utilizar ferramentas disponíveis no mercado,como MatLab1 e LabView2, que geram o código-fonte a partir de modelos formais.

Visto que os modelos formais para sistemas temporais são passíveis de possuirexecuções infinitas e de ser impraticável representar a continuidade do tempo em um casode teste, a extração de casos de teste ocorre a partir de um modelo discretizado, comoregiões de relógio ou em grid, como o descrito na seção 3.2.2.

Uma maneira trivial de extrair casos de teste de um grid é percorrer todos oscaminhos possíveis do grid, onde cada caminho caracteriza uma execução do sistema.Uma execução do sistema é dada por uma sequência intercalada de estados e ações,podendo as ações ser de entrada ou saída. Do conjunto de execuções podem ser extraídosos casos de teste ao projetar cada execução ao conjunto de ações de entrada. Isso significaque apenas as ações de entrada se manterão e as ações de saída serão descartadas.

Para a execução de teste baseado em modelos, vários tipos de modelos formaispodem ser utilizados para descrever o SUT, com diferentes níveis de abstração, diferentessintaxes e diferentes semânticas. Alguns dos modelos mais utilizados são Máquinas deEstados Finitos (MEF) [17, 4], Bounded Time Domain Automaton (BTDA) e TimedInput/Output Automaton (TIOA) [11, 6, 2].

3.2 Sistemas de Tempo Real

Sistemas de tempo real são sistemas computacionais que devem reagir a estímulosexternos em prazos específicos bem definidos [1]. Isso resulta em requisitos de naturezatemporal sobre a execução de sistemas desse tipo. Não estar de acordo com o prazodefinido de resposta resulta em uma falha temporal.

Assim, o comportamento correto de um sistema de tempo real não é dado apenaspela validade dos resultados obtidos, mas também do tempo que o sistema leva parachegar a esses resultados. Uma reação fora do prazo pode não ter utilidade ou até mesmorepresentar ameaças.

Alguns sistemas possuem restrições de tempo não tão críticas, como videoconferên-cias e players de áudio. Por outro lado, sistemas de controle de air-bags, de monitoramento1 http://www.mathworks.com/products/matlab/2 http://www.ni.com/labview/


Initial

Especificação

Implementação Modelo formal

Casos deteste

Veredito

Análise de Requisitos

Modelagem

Extração de casos de teste

Execução de testes

Figura 1 – Processo de teste de software baseado em modelos

de pacientes e de supervisão e controle de usinas nucleares estão entre os sistemas comrestrições mais rigorosas.

Possuir um pequeno tempo médio de resposta não garante que os requisitos detempo serão atendidos. Para isso, diz-se que o sistema deve ser previsível [1]. Um sistema édito previsível quando se possui duas informações: a carga máxima, momento de máximacarga computacional que o sistema pode sofrer, que inclui prever eventos passíveis deacontecer simultâneamente; e hipótese de falha, que descreve quais falhas podem ocorrere quais são aceitáveis para continuar a atender os requisitos.

Sistemas de tempo real podem ser classificados como Sistemas Não Críticos deTempo Real ("Soft Real Time Systems") e Sistemas Críticos de Tempo Real ("Hard RealTime Systems"). No último, as consequências de uma falha excedem os benefícios de umfuncionamento normal do sistema, enquanto no primeiro ambos possuem o mesmo peso.

3.2.1 TIOA

O modelo TIOA, utilizado principalmente na modelagem de sistemas temporiza-dos, é uma variação do modelo BTDA, formalizado por Gawlick et al [12]. Um BTDA


possui estados, símbolos de ação, variáveis de relógio, invariantes de estado e transiçõesentre estados para representar o funcionamento de um software. A progressão do sistemaé dada por uma sequência de evoluções contínuas de tempo, interrompidas por transiçõesdiscretas [18].

Um BTDA B é formalmente caracterizado por uma tupla (𝑆, 𝑠0, Σ, 𝐶, 𝑣0, 𝐼𝑛𝑣, 𝑇 ),sendo:

∙ S: o conjunto de estados do modelo;

∙ 𝑠0: o estado inicial do sistema;

∙ Σ: o conjunto de símbolos de ação;

∙ 𝐶: conjunto de relógios do sistema;

∙ 𝑣0: uma interpretação inicial de relógios. É um conjunto de interpretações 𝑣(𝑐), ∀𝑐 ∈𝐶

∙ 𝐼𝑛𝑣: mapeamento de invariantes de cada estado. É uma função 𝐼𝑛𝑣 : 𝑆 → Φ𝑐 quemapeia cada condição de relógio de um estado;

∙ 𝑇 : conjunto de transições do modelo, onde 𝑇 ⊆ (𝑆 × Σ × Φ𝑐 × [𝐶 y Q ≥] × 𝑆);

A interpretação de uma transição (𝑠, 𝑧, 𝛿, 𝜃, 𝑟) é que o sistema parte do estado 𝑠 emuda para o estado 𝑟 com a ação 𝑧, se a condição 𝛿 estiver sendo satisfeita no momentoda transição. Com a execução da transição, o mapeamento 𝜃 ∈ [𝐶 y Q ≥] indica quaisvalores de relógio serão alterados. Note que o reset de valores de relógio pode possuirquaisquer valores, não apenas zero.

Uma condição 𝛿 possui a forma c op x, onde 𝑐 ∈ 𝐶, 𝑜𝑝 ∈ {<, ≤, =, ≥, >} e 𝑥 éum número finito não negativo. Assume-se que uma transição é instantânea e que cadarelógio 𝑐 ∈ 𝐶 possui o domínio {0, ∞}.

A definição formal de um TIOA é dada por uma tupla (𝐵, 𝐼, 𝑂) [9], onde

∙ B é um BTDA;

∙ I e O particional Σ de 𝐵 entre ações de entrada e ações de saída, respectivamente.

Assim, ao particionar o conjunto de ações de um BTDA entre ações de saída eações de entrada, é caracterizado um TIOA.

A figura 2 é um modelo TIOA de um sistema de controle de portas automáticas.O sistema inicia em um estado de inicialização e permanece nesse estado por no máximo5 unidades de tempo.


Inicial

Inicializando,𝑟𝑒𝑙_𝑖𝑛𝑖 ≤ 5

Fechada

Abrindo,𝑟𝑒𝑙_𝑜𝑝 ≤ 4

Fechando,𝑟𝑒𝑙_𝑜𝑝 ≤ 4

Aberta,𝑟𝑒𝑙_𝑠𝑡𝑎𝑡𝑒 ≤ 5

fim_inic, (𝑟𝑒𝑙_𝑖𝑛𝑖 ≤ 5), ( )

abre, ( ), (𝑟𝑒𝑙_𝑜𝑝 := 0)

fim_abre, (𝑟𝑒𝑙_𝑜𝑝 ≤ 4), (𝑟𝑒𝑙_𝑒𝑠𝑡𝑎𝑑𝑜 := 0) feche, (𝑟𝑒𝑙_𝑒𝑠𝑡𝑎𝑑𝑜 == 5), (𝑟𝑒𝑙_𝑜𝑝 := 0)

fim_feche, (𝑟𝑒𝑙_𝑜𝑝 == 4), ()

Figura 2 – Modelo TIOA de um sistema de controle de porta automática

Esse sistema de controle de portas automáticas possui os relógios rel_inic, rel_op,rel_estado, os estados Inicializando, Fechada, Abrindo, Aberta e Fechando. Abre e fechasão ações de entradas e fim_abre, fim_fecha e fim_inic ações de saída.

3.2.2 Discretização

Extrair casos de testes diretamente de um TIOA é impraticável, visto que é im-possível representar em um caso de teste a continuidade e a infinitude do tempo[2, 9].Para extrair casos de testes é então necessário realizar uma discretização dos movimentosdo modelo.


Discretizar um modelo significa obter um conjunto finito de representações dosistema, dada uma granularidade definida de tempo 𝑔. Para representar esse conjuntogerado, muitos trabalhos utilizam de regiões de relógio e gráficos de amostragem [2, 11].

Em [9] é proposta uma técnica de discretização que gera um autômato grid pararepresentar o conjunto gerado de representações. Para a discretização, é escolhida umagranularidade de tempo qualquer 𝑔, sendo 𝑔 um número positivo finito.

Um grid é definido formalmente como uma tupla 𝐺 = (𝑆, 𝑠, Σ, 𝑇 ) [6], onde:

∙ S é o conjunto finito de estados do modelo;

∙ s é o estado inicial do grid;

∙ Σ∪𝑔 é o conjunto de rótulos do grid, sendo Σ o conjunto de ações do TIOA utilizadona discretização e 𝑔 a granularidade escolhida;

∙ 𝑇 ∈ (𝑆 × (Σ ∪ 𝑔) × 𝑆) é o conjunto finito de transições entre estados do grid atravésda ação 𝑧 ∈ (Σ ∪ 𝑔).

Um trecho do grid obtido ao discretizar o TIOA da figura 2 é exibido na na figura3. Nesse caso, a granularidade de tempo escolhida foi 0.5.


dawda

Inicializando, 0.0 0.0 0.0

Inicializando, 0.5 0.5 0.5

Fechada,0.0 0.0 0.0

...

Fechada,0.5 0.5 0.5

...

...

...

0.5

fim_inic

0.50.5

0.5

abre

abre

fim_inic

Figura 3 – Trecho do grid obtido da discretização do modelo mostrado em 2

26

4 DESENVOLVIMENTO

A ferramenta gráfica foi modelada utilizando fundamentos da UML (Unified Mo-delling Language) e desenvolvida utilizando a linguagem Java. É possível ver na Figura 4a organização do sistema em pacotes. Para auxiliar no desenvolvimento foi utilizada comosuporte a biblioteca Jung 1.

Os pacotes tioa e grid possuem as classes pertinentes aos respectivos modelosformais, suas classes de estados e transições e as classes responsáveis por fazer a leiturados modelos em arquivos. No pacote junglayer estão as classes relacionadas à bibliteocaJung e personalizações para a solução em questão. Em gui estão as classes de interfacegráfica, como JFrames, JPopups e JDialogs. O pacote misc possui classes de propósitogeral, como os de auxílio para que o sistema reconheça os tipos de arquivos utilizados.

Figura 4 – Diagrama de Pacotes

Os principais objetivos da ferramenta são a modelagem visual de TIOAs, a discre-tização em grid do modelo criado, a extração de um conjunto de casos de testes a partirdo grid gerado e a visualização de grids, exibido na figura 5. Nas imagens 6, 7, 8, 9 e 10 épossível ver as classes existentes dentro de cada pacote. A imagem 11 mostra o diagramade classes completo e a relação entre cada pacote e classe.

No pacote gui (Figura 6) estão as classes:1 disponível em http://jung.sourceforge.net/

Capítulo 4. Desenvolvimento 27

Figura 5 – Diagrama de Casos de Uso

∙ Frame: é a janela principal da ferramenta. Possui a área de edição de TIOAs eo menu principal, do qual é possível criar, abrir e salvar modelos, além de acessara janela com atributos do TIOA e as janelas que dão acesso as ferramentas dediscretização e extração;

∙ TIOAEditor: classe responsável por exibir o TIOA e gerenciar as modificaçõesfeitas ao modelo;

∙ MultiEditor: área de edição de TIOAs dentro do Frame que possui várias instânciasdo TIOAEditor, suportando assim que vários TIOAs sejam exibidos e modificadosao mesmo tempo;

∙ ExtractorUI: janela que faz a interface gráfica entre o usuário e a ferramenta deextração de casos de teste. O usuário fornece de entrada um arquivo salvo contendoum modelo grid e escolhe onde salvar os casos de teste extraídos;

∙ DiscretizatorUI: faz a interface entre o usuário e a ferramenta de discretização.Deve ser dado de entrada um modelo TIOA salvo, a granularidade desejada para adiscretização e o caminho do arquivo que será escrito o grid gerado’;

∙ StateMenu: menu simples para auxiliar o usuário na manipulação de estados.Através dele o usuário pode excluir, abrir a janela de edição do estado ou tornar oestado como estado inicial do modelo;


Figura 6 – Pacote GUI


∙ TransitionMenu: similar ao StateMenu, possibilita que o usuário exclua uma tran-sição ou abra a janela de edição da transição;

∙ PopupPropertiesTIOATransitions: janela onde é possível alterar as proprieda-des de uma transição entre estados do TIOA;

∙ PopupPropertiesTIOAState: similar ao item anterior, uma janela com propósitode alterar as propriedades de um estado do TIOA;

∙ PopupTIOADeclarations: útil para ver as operações de entrada, saída e relógiosdo TIOA sendo trabalhado;

∙ GRIDEditor: classe responsável por gerir as modificações necessárias em um grid;

∙ GRIDMultiEditor: relacionada os grids sendo visualizados em seus respectivosframes;

∙ GRIDVisualizator: janela onde é possível visualizar grids obtidos com a ferra-menta.

O pacote tioa (Figura 7) possui as seguintes classes, construídas segundo as defi-nições apresentadas em [9]:

∙ TIOA: classe principal do pacote, possui as informações que unem os estados etransições em um TIOA;

∙ TIOAState: estado de um TIOA;

∙ TIOATransitions: transição entre estados do TIOA;

∙ TIOAParser: classe responsável por ler corretamente TIOAs salvos em arquivos;

Foram organizadas no pacote junglayer (Figura 8) as seguintes classes:

∙ EditingModalTIOAMouse: resposável pela configuração das ações que serão to-madas conforme o usuário utilizar o mouse para modificar TIOAs;

∙ EditingTIOAMousePlugin: responsável por entender os comandos do mouse erealizar a ação configurada;

∙ PopupMenuMousePlugin: classe responsável por gerenciar qual menu de opçõesserá exibido, levando em consideração se o objeto selecionado é um estado ou umatransição;

∙ EditinModalGRIDMouse: similar à EditingModalTIOAMouse, porém para con-figurações específicas de grid;


Figura 7 – Pacote TIOA

∙ EditingGRIDMousePlugin: similar à EditingTIOAMousePlugin, utlizada paramodificações feitas em grids.

As seguintes classes estão no pacote grid (Figura 9):

∙ GRID: classe principal do pacote, responsável por unir estados e transições de grid;

∙ GRIDState: estado de um grid, possui um nome e uma configuração de relógio;

∙ ClockConf: classe que representa uma configuração de relógio;

∙ GRIDTransition: transição entre estados de grid;

∙ GRIDParser: classe responsável por fazer a leitura de grids salvos em disco.

Por fim, no pacote misc (Figura 10) estão as classes:


Figura 8 – Pacote Junglayer

Figura 9 – Pacote GRID


Figura 10 – Pacote Misc

∙ SuitFileFilter: classe responsável por fazer com que a ferramenta identifique suitesde teste salvos em disco;

∙ TioaFileFilter: classe responsável por fazer com que a ferramenta identifique TI-OAs salvos em disco;

∙ GridFileFilter: classe responsável por fazer com que a ferramenta identifique gridssalvos em disco.

Na imagem 12 é exibido um diagrama de sequências com as principais atividades daferramenta. O diagrama mostra as interações entre o usuário, a ferramenta desenvolvidano trabalho e a ferramenta de discretização de modelos e extração de casos de teste.

A ferramenta desenvolvida possibilita a manipulação de TIOAs, a discretizaçãoem grid e a extração de casos de teste seguindo os algoritmos propostos em [9], além davisualização de modelos grid.

Na figura 13 é exibida a janela inicial da ferramenta, já com TIOAs abertos paraedição.

Ao clicar nos botões "Draw", "Select/Move"e "Translade", o usuário pode, respec-tivamente, desenhar novos estados e/ou transições; selecionar um ou mais estados paraalterar seu posicionamento; e alterar a posição do TIOA na tela.

O estado inicial é destacado com linhas mais grossas que outros estados e suafonte é exibida em negrito. O estado ou transição atualmente selecionado é destacado dosdemais com fonte azul. A figura 14 mostra como é possível alterar as propriedades de umestado ou uma transição recém criados ou existentes.

Cada janela interna possui um TIOA, é possível visualizar a localização e o nomedo arquivo no título. Em caso de arquivos novos, o título é "Untitled"até que o modeloseja salvo ou descartado. Através da ferramenta é possível iniciar modelos novos, abrirmodelos salvos, salvar modelos já existentes e salvar modelos em diferentes localizaçõese/ou diferentes nomes.


Figura 11 – Diagrama de Classes

Depois de criar um modelo TIOA é possível discretizá-lo utilizando a ferramenta,obtendo assim um grid. As figuras 15 e 16 mostram a janela de interface com a ferramentade discretização antes e depois da execução. Nela são configurados os parâmetros dadiscretização, como granularidade desejada, TIOA de entrada e arquivo de saída do grid.Para garantir uma execução finita do modelo é determinado um valor limite de tempo paraa discretização. Esse valor é dado pelo valor de tempo mais alto encontrado no modeloacrescido da granularidade escolhida.

Também é possível selecionar para que a ferramenta de extração de casos de testeseja executada imediatamente após à discretização, sendo necessário para isso definir qualo arquivo de saída dos casos de teste.

Para grids já criados, é possível rodar exclusivamente a extração de casos de teste.


Figura 12 – Diagrama de Sequencias

Para isso é utilizado a interface mostrada nas figuras 17 e 18.

Também é possível visualizar os grids criados pela ferramenta e para isso é utilizadaa interface "Grid Visualizator"(Figura 19). Quando o grid é criado pela ferramenta aindanão existem informações salvas sobre a posição dos estados na visualização, nesse casoé carregado um posicionamento padrão. A partir deste posicionamento o usuário podemodificar as posições de cada estado e, quando salvo o modelo, as posições também sãosalvas para serem carregadas em visualizações futuras.

Durante o desenvolvimento da ferramenta, uma das dificuldades encontradas foientender o fluxo de informação das classes de interação com a biblioteca Jung, pois osmanuais oficiais exibem casos básicos de manipulação de grafos. A implementação e com-binação de técnicas de manipulação de grafos acabou tomando mais recursos do que foramplanejados no planejamento.

Outro problema que muito afetou o cronograma foram bugs encontrados na fer-ramenta de discretização de modelos e extração de casos de teste. A partir do estado daimplementação no momento do início do projeto, poucos trechos de código se mantive-


Figura 13 – Janela Principal

ram, uma vez que quase toda a ferramenta estava passível de falhas e erros, descobertosconforme novos modelos eram fornecidos como testes.

Também com o desenvolvimento da ferramenta gráfica novas funcionalidades eadaptações precisaram ser feitas à ferramenta de discretização para que ambas funcionas-sem de acordo.

Devido a esses atrasos de cronograma e problemas reportados durante a imple-mentação, a funcionalidade de ajuste de TIOAs para uma dada granularidade não foiimplementada. Porém, a não implementação dessa funcionalidade não afetou em nada asoutras funcionalidades da ferramenta, uma vez que os algoritmos utilizados prevêem casosonde o TIOA não é ajustado à granularidade escolhida.


Figura 14 – Alterando propriedades de um estado e de uma transição

Figura 15 – Discretização de modelos TIOA


Figura 16 – Discretização de modelos TIOA concluída

Figura 17 – Extração de casos de teste


Figura 18 – Extração de casos de teste concluída

Figura 19 – Visualização de Grids

39

5 EXPERIMENTOS

Este capítulo possui análises referentes à execuções da ferramenta e de resultadosobtidos.

Para verificar estatísticas relacionados aos grids gerados e à quantidade de casosde teste extraídos, as entradas mostradas na tabela 1 foram aplicados à ferramenta. Natabela 2 encontra-se a quantidade de estados e transições dos grids resultantes com adiscretização e a quantidade de casos de testes extraídos do grid, além do tempo totalgasto para discretizar o modelo e extrair os casos de teste.

A partir de cada caso dado de entrada é possível verificar que o número de estados,transições e relógios do TIOA, assim como a granularidade escolhida e o valor limite detempo, impactam no tamanho do grid gerado e consequentemente no número de casosde testes extraídos. Além disso, a quantidade de casos de testes extraídos depende dire-tamente da quantidade de estados e transições no grid, uma vez que para grids maiores,mais casos de testes são necessários para satisfazer todos os caminhos possíveis.

Para o caso 3 foi escolhido um TIOA igual ao dos casos 3 e 4, mas com umagranularidade mais fina, utilizando a abordagem de escolha de granularidade definida porDill e Alur [14], onde a granularidade deve ser 1/𝑛, com 𝑛 sendo o número de estadosdo modelo. Pode-se perceber que ao utilizar uma granularidade de tempo mais grossadiminuimos a explosão de estados do grid resultante, tornando o modelo mais práticode ser trabalhado e, por isso, a escolha de granularidades mais grossas na discretizaçãoproposta por Bonifácio e Moura [9] possibilitou uma melhor manipulação do modelo.

A quantidade de casos de teste extraídos se mostrou grande, mesmo para TIOAspequenos. Isso se dá pela ausência de um modelo de falhas, que possibilita a geração deconjuntos de casos de testes mais sucintos ainda que com boa eficácia. Tomando comoexemplo o caso 7, foram extraídos 74.411 casos de testes. Se cada caso de teste levar1 minuto para ser executado e desconsiderando possíveis janelas de tempo necessáriasentre casos de testes, levaria ao todo cerca de 1235 horas para que todos os testes fossemexecutados. Contando que nenhuma interrupção ocorra, isso significa uma alocação derecurso computacional por quase 52 dias.

Os TIOAS usados nos casos 8 e 9 foram criados utilizando como base o TIOA docaso 7. No caso 8, a granularidade escolhida foi metade da granularidade escolhida nocaso 7, enquanto no caso 9 o limite foi dobrado. Ao analisar esses três casos, é possívelverificar que ao diminuir a granularidade na mesma proporção em que o limite aumenta,os impactos são quase os mesmos no grid gerado.

Em alguns casos o tempo de extração de casos de teste foi muito grande, tornando

Capítulo 5. Experimentos 40

Test Case No. 17Case:< 1, abre, manter_aberta, 1, manter_aberta, 1, manter_aberta, 1, manter_aberta>

Execution Output:<( inicializando, [0-0-0-0-0-0]), 1, ( inicializando, [1-1-1-1-1-1]), fim_inic, ( fechada,[1-1-1-1-1-1]), abre, ( abrindo, [1-1-1-0-1-1]), fim_abre, ( aberta, [1-1-1-0-0-1]),manter_aberta, ( manter_aberta, [1-1-1-0-0-1]), 1, ( manter_aberta, [2-2-2-1-1-2]),manteve_aberta, ( aberta, [2-2-2-1-0-2]), manter_aberta, ( manter_aberta, [2-2-2-1-0-2]), 1, ( manter_aberta, [3-3-3-2-1-3]), manteve_aberta, ( aberta, [3-3-3-2-0-3]),manter_aberta, ( manter_aberta, [3-3-3-2-0-3]), 1, ( manter_aberta, [4-4-4-3-1-4]),manteve_aberta, ( aberta, [4-4-4-3-0-4]), >

Figura 20 – Exemplo de caso de teste

??

Estados Transições Clocks Granularidade LimiteCaso #1 3 3 2 1 5Caso #2 3 3 2 0.25 5Caso #3 5 5 4 2 5Caso #4 5 5 4 1 5Caso #5 5 5 4 0.17 5Caso #6 5 5 4 0.5 5Caso #7 6 9 6 1 5Caso #8 6 9 6 0.5 5Caso #9 8 10 4 1 10Caso #10 8 10 4 1 5Caso #11 8 10 5 0.5 5Caso #12 8 10 5 1 5

Tabela 1 – Entradas de análise da ferramenta

o processo mais passivo de sofrer interferências externas, como quedas de energia ouo encerramento do processo por parte do sistema operacional. Assim, não foi possíveldeterminar o número exato de casos de teste para alguns dos exemplos.

A figura 21 mostra o TIOA utilizado como entrada no caso #7. No gráfico 24, ascolunas com valores zerados são casos em que não foi possível definir o número exato decasos de teste.

Para os casos de 3 a 6 foram dados de entrada o TIOA descrito na imagem 2,alternando a granularidade escolhida. Um exemplo de caso de teste extraído pode servisto na figura ??.


Estados no Grid Transições no Grid Casos de Teste Tempo total de execuçãoCaso #1 14 19 39 1sCaso #2 44 64 294 1sCaso #3 32 34 26 1sCaso #4 124 145 512 1sCaso #5 5358 5681 Indeterminado >50hCaso #6 435 491 4767 3h48mCaso #7 656 1040 74411 6h31mCaso #8 3697 6226 Indeterminado >30hCaso #9 3791 6243 Indeterminado >50hCaso #10 1392 3315 Indeterminado >60hCaso #11 5120 12147 Indeterminado >60hCaso #12 1914 4639 Indeterminado >60h

Tabela 2 – Resultados obtidos com execuções das entradas descritas em 1

Figura 21 – TIOA utilizado no caso de entrada #5


1 2 3 4 5 6 7 8 9 10 11 120

1,000

2,000

3,000

4,000

5,000

TIOAs de Entrada

Esta

dos

noG

rid

Figura 22 – Número de Estados no Grid

1 2 3 4 5 6 7 8 9 10 11 120

2,000

4,000

6,000

8,000

10,000

12,000

TIOAs de Entrada

Tran

siçõe

sno

Grid

Figura 23 – Número de Transições no Grid


1 2 3 4 5 6 7 8 9 10 11 120

20,000

40,000

60,000

80,000

TIOAs de Entrada

Cas

osde

Test

e

Figura 24 – Casos de Teste Extraídos

44

6 CONCLUSÃO

Este trabalho contemplou o desenvolvimento de uma ferramenta de modelagem ediscretização de sistemas críticos de tempo real. O formalismo adotado pela ferramentafoi o TIOA, capaz de modelar e capturar características de sistemas dessa natureza. Alémda modelagem, a ferramenta permite a realização da discretização do modelo TIOA deuma especificação. O resultado da discretização é um autômato grid que permite lidarcomputacionalmente com a evolução contínua do tempo desses sistemas. A ferramentaainda proporciona a extração de dados de teste seguindo os algoritmos propostos porBonifácio e Moura [9]. O desenvolvimento da ferramenta foi guiado pelo planejamento eespecificação baseado nos modelos da UML. A linguagem de programação adotada foi oJava, com apoio da biblioteca Jung e da ferramenta de desenvolvimento NetBeans.

Alguns experimentos foram realizados na ferramenta através de exemplos sim-ples de especificações em TIOA. Com base nesses experimentos foi possível analisar aferramenta em termos de usabilidade, funcionalidades e desempenho. Em termos de usa-bilidade, a ferramenta se mostrou eficiente, uma vez que a manipulação de TIOAs se dáde forma intuitiva e simples e com poucas limitações. Com relação as funcionalidades, aferramenta se comportou de maneira adequada, possibilitando a manipulação visual dosmodelos, a discretização e ainda a extração de casos de testes, ao longo dos experimentosrealizados. Já o desempenho da ferramenta se apoia nas técnicas de discretização disponí-veis, assim sua escalabilidade é refletida pelos resultados apresentados nos experimentos,evidenciando que foi é possivel controlar a explosão de estados no grid gerado.

Como trabalho futuro, pretende-se diminuir o conjunto de casos de teste utilizandoum modelo de falhas. Também objetiva-se alterar a maneira com que um grid recém criadoé organizado na tela de visualização de forma que as características do grid sejam levadasem consideração ao tentar alcançar uma boa organização espacial.

45

REFERÊNCIAS

1 FARINES, J.-M.; FRAGA, J. d. S.; OLIVEIRA, R. S. Sistemas de Tempo Real. [S.l.]:IME-USP, 2000.

2 EN-NOUAARY, A.; DSSOULI, R. A guided method for testing timed input outputautomata. In: Proceedings of the 15th IFIP international conference on Testing ofcommunicating systems. Berlin, Heidelberg: Springer-Verlag, 2003. (TestCom’03), p.211–225. ISBN 3-540-40123-7. Disponível em: <http://dl.acm.org/citation.cfm?id=1764575.1764596>.

3 TRETMANS, J. Formal methods and testing. In: HIERONS, R. M.; BOWEN,J. P.; HARMAN, M. (Ed.). Berlin, Heidelberg: Springer-Verlag, 2008. cap. Model basedtesting with labelled transition systems, p. 1–38. ISBN 3-540-78916-2, 978-3-540-78916-1.Disponível em: <http://dl.acm.org/citation.cfm?id=1806209.1806210>.

4 JUNIOR, G.; BONIFÁCIO, A. L. A tool to support model-based testing activities.In: IEEEXPLORE DIGITAL LIBRARY. SBESC 2011 - WSE. Florianópolis, Brazil:Ieeexplore Digital Library, 2011. p. 21–26. ISBN 978-1-4673-0427-6. Disponível em:<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6114880>.

5 BERTOLINO, A. Software testing research: Achievements, challenges, dreams.In: 2007 Future of Software Engineering. Washington, DC, USA: IEEE ComputerSociety, 2007. (FOSE ’07), p. 85–103. ISBN 0-7695-2829-5. Disponível em:<http://dx.doi.org/10.1109/FOSE.2007.25>.

6 JUNIOR, G.; BONIFÁCIO, A. L. Detecção de falhas em autômatos grid. In: SBC.XIII Workshop de Teste e Tolerância a Falhas. Ouro Preto, MG: SBC, 2012. p. 131–144.

7 SPRINGINTVELD, J.; VAANDRAGER, F.; D’ARGENIO, P. R. Testing timedautomata. In: IN B. JONSSON AND J. PARROW (EDS.), PROC. FTRTFT’96, LNCS1135. [S.l.]: Springer, 1996. p. 130–147.

8 EN-NOUAARY, A.; HAMOU-LHADJ, A. A boundary checking technique for testingreal-time systems modeled as timed input output automata (short paper). In: Proceedingsof the 2008 The Eighth International Conference on Quality Software. Washington, DC,USA: IEEE Computer Society, 2008. (QSIC ’08), p. 209–215. ISBN 978-0-7695-3312-4.Disponível em: <http://dx.doi.org/10.1109/QSIC.2008.53>.

9 BONIFáCIO, A. L.; MOURA, A. V. A new method for testing timed systems.Software Testing, Verification and Reliability, mar. 2013. ISSN 09600833. Disponível em:<http://dx.doi.org/10.1002/stvr.454>.

10 EN-NOUAARY, A.; DSSOULI, R.; KHENDEK, F. Timed wp-method:Testing real-time systems. IEEE Trans. Softw. Eng., IEEE Press, Piscataway,NJ, USA, v. 28, n. 11, p. 1023–1038, nov. 2002. ISSN 0098-5589. Disponível em:<http://dx.doi.org/10.1109/TSE.2002.1049402>.

11 EN-NOUAARY, A. A scalable method for testing real-time systems. Software QualityControl, Kluwer Academic Publishers, Hingham, MA, USA, v. 16, n. 1, p. 3–22, mar.2008. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-007-9021-8>.

http://dl.acm.org/citation.cfm?id=1764575.1764596



http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6114880

http://dx.doi.org/10.1109/FOSE.2007.25

http://dx.doi.org/10.1109/QSIC.2008.53

http://dx.doi.org/10.1002/stvr.454

http://dx.doi.org/10.1109/TSE.2002.1049402

http://dx.doi.org/10.1007/s11219-007-9021-8

Referências 46

12 SEGALA, R. et al. Liveness in timed and untimed systems. Inf. Comput., v. 141,n. 2, p. 119–171, 1998. Disponível em: <http://dblp.uni-trier.de/db/journals/iandc/iandc141.html>.

13 ALUR, R. Timed automata. In: Proceedings of the 11th International Conference onComputer Aided Verification. London, UK, UK: Springer-Verlag, 1999. (CAV ’99), p.8–22. ISBN 3-540-66202-2. Disponível em: <http://dl.acm.org/citation.cfm?id=647768.733787>.

14 ALUR, R.; DILL, D. L. A theory of timed automata. Theoretical Computer Science,Elsevier Science Publishers Ltd., Essex, UK, v. 126, n. 2, p. 183–235, abr. 1994. ISSN03043975. Disponível em: <http://dx.doi.org/10.1016/0304-3975(94)90010-8>.

15 SPRINGINTVELD, J.; VAANDRAGER, F.; D’ARGENIO, P. R. Testingtimed automata. Theor. Comput. Sci., Elsevier Science Publishers Ltd., Essex,UK, v. 254, n. 1-2, p. 225–257, mar. 2001. ISSN 0304-3975. Disponível em:<http://dx.doi.org/10.1016/S0304-3975(99)00134-6>.

16 DAWS, C. et al. The tool kronos. In: In Proc. of Hybrid Systems III, LNCS 1066.[S.l.]: Springer Verlag, 1996. p. 208–219.

17 BONIFáCIO, A. L.; MOURA, A. V.; aO, A. d. S. S. A generalized model-based testgeneration method. In: Proceedings of the 2008 Sixth IEEE International Conferenceon Software Engineering and Formal Methods. Washington, DC, USA: IEEE ComputerSociety, 2008. (SEFM ’08), p. 139–148. ISBN 978-0-7695-3437-4. Disponível em:<http://dx.doi.org/10.1109/SEFM.2008.17>.

18 BONIFáACIO, A. L.; MOURA, A. S.; JC, M. Conformance testing by modelchecking timed extended finite state machine. Brazilian Symposium on Formal Methods,p. 43–58, 2006.

http://dblp.uni-trier.de/db/journals/iandc/iandc141.html

http://dblp.uni-trier.de/db/journals/iandc/iandc141.html



http://dx.doi.org/10.1016/0304-3975(94)90010-8

http://dx.doi.org/10.1016/S0304-3975(99)00134-6

http://dx.doi.org/10.1109/SEFM.2008.17

umaferramentagrÁficapara … · 2014-08-04 · hippler, a. r.. a graphical tool for modeling and...

Documents