UNIVERSIDADE FEDERAL DE GOIAS – UFG

CAMPUS CATALAO – CaC

DEPARTAMENTO DE CIENCIA DA COMPUTACAO – DCC

Bacharelado em Ciencia da Computacao

Projeto Final de Curso

Modelos de Teste Funcional para Aplicacoes Web

Autor: Bianor Vicente Sousa Neto

Orientadora: Liliane do Nascimento Vale

Catalao - 2008

Bianor Vicente Sousa Neto

Modelos de Teste Funcional para Aplicacoes Web

Monografia apresentada ao Curso de

Bacharelado em Ciencia da Computacao da

Universidade Federal de Goias Campus Catalao

como requisito parcial para obtencao do tıtulo de

Bacharel em Ciencia da Computacao

Area de Concentracao: Engenharia de Software

Orientadora: Liliane do Nascimento Vale

Catalao - 2008

V. S. Neto, Bianor

Modelos de Teste Funcional para Aplicacoes Web/Liliane do Nasci-

mento Vale- Catalao - 2008

Numero de paginas: 108

Projeto Final de Curso (Bacharelado) Universidade Federal de Goias, Campus

Catalao, Curso de Bacharelado em Ciencia da Computacao, 2008.

Palavras-Chave: 1. Engenharia de Software. 2. Aplicacoes Web. 3. Redes de Petri.

4. Teste Funcional.

Bianor Vicente Sousa Neto

Modelos de Teste Funcional para Aplicacoes Web

Monografia apresentada e aprovada em de

Pela Banca Examinadora constituıda pelos professores.

Liliane do Nascimento Vale – Presidente da Banca

Dr. Dino Rogerio Coinete Franklin

Dr. Vaston Goncalves Costa

Dedico esse trabalho aos meus pais, minhas irmas, minha querida esposa, amigos que

contribuıram para a realizacao deste.

AGRADECIMENTOS

Antes de tudo agradeco a Deus, pois Ele foi e e o meu sustento. Sem Ele nao teria

conseguido realizar este trabalho.

Agradeco minha mae e meu pai pelo apoio, pela motivacao e por existir na minha

vida.

Agradeco a minha esposa Cassia pelo incentivo dado e pelo apoio nos momentos

difıceis.

Agradeco ao Claiton e ao Daniel em especial, voces foram muito importantes para

mim nesta fase da minha vida.

Agradeco tambem minha orientadora Liliane do Nascimento Vale, por estender a sua

mao, quando pensava que tudo estava perdido, dando todo suporte necessario para a

realizacao deste trabalho.

De modo geral, agradeco aqueles que nao foram citados aqui, porem incentivaram e

apoiaram na realizacao deste trabalho.

RESUMO

Neto, B. Modelos de Teste Funcional para Aplicacoes Web. Curso de Ciencia

da Computacao, Campus Catalao, UFG, Catalao, Brasil, 2008, 108p.

O Ensino a Distancia e uma modalidade de ensino que surgiu visando contribuir

com a aprendizagem. Ele se caracteriza pela utilizacao de recursos didaticos organizados

que podem ser disponibilizados aos interessados por diversos meios, um deles e a rede de

computadores. Para auxiliar na aprendizagem surgiu a necessidade de criacao de sistemas

especıficos para este proposito. Para que estes sistemas cumpram com as especificacoes,

surgiu a necessidade de aplicar as tecnicas de desenvolvimento de software ja conhecidas,

evitando assim que os sistemas apresentem o menos possıvel de erros. A cada dia, esta

havendo uma crescente dependencia da sociedade em relacao aos sistemas Web, tornando-

se de fundamental importancia desenvolver sistemas que venham oferecer padroes altos de

qualidade e confiabilidade. Ate o momento, verifica-se que a atividade de teste funcional

se concentra em meios informais e manuais, possuindo pouca documentacao disponıvel, o

que impede de compreender como os procedimentos de teste ocorrem. Neste trabalho e

proposto, a modelagem de testes funcionais atraves da especificacao destes usando Redes

de Petri a Objetos para software de Ensino a Distancia.

Palavras-Chaves: Engenharia de Software, Aplicacoes Web, Redes de Petri, Teste

Funcional.

i

Sumario

1 Introducao 1

1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Ensino a Distancia 3

2.1 Definicoes e Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Ensino a Distancia no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Atualmente no Brasil . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Ambientes Virtuais de Aprendizagem . . . . . . . . . . . . . . . . . . . . . 7

2.4 Descricao Geral de Alguns Ambientes Virtuais de Aprendizagem . . . . . . 9

2.4.1 TelEduc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.2 Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.3 e-ProInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Requisitos Necessarios para um Ambiente Virtual de Aprendizagem . . . . 15

2.6 Ferramentas Utilizadas em Ambientes Virtuais de Aprendizagem . . . . . . 16

3 Teste de Software 18

3.1 Conceitos Basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Fases de Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Teste Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 Teste Estrutural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.3 Teste Baseado em Erro . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Testes de Aplicacao WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1 Teste Estrutural nas Aplicacoes Web . . . . . . . . . . . . . . . . . 24

3.3.2 Teste Funcional para Aplicacoes Web . . . . . . . . . . . . . . . . . 26

3.4 A notacao UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.1 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.2 Diagrama de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.3 Diagrama de Sequencia . . . . . . . . . . . . . . . . . . . . . . . . . 31

ii

3.4.4 Diagrama de Atividade . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Modelo de Especificacao de Teste Funcional 41

4.1 Aplicacao do Teste Funcional . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Modelo de Especificacao de Teste Funcional para Aplicacoes Web . . . . . 42

4.3 Implementacao do Modelo de Especificacao do Teste Funcional . . . . . . . 48

4.4 Execucao do Cenario de Teste . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.5 Abordagem Multi-formalismo no Contexto do Teste Funcional . . . . . . . 56

5 O SiEAD 60

5.1 Descricao do SiEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Linguagens e Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.3 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.4 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Requisistos do SiEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.1 Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3.2 Manutencao de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3.3 Casos de Usos do Sistema . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.4 Diagramas de Sequencia . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Estudo de Caso: Especificacao de Modelos de Teste Funcional para um

Sistema de Ensino a Distancia 78

6.1 Especificacao de Modelos de Testes Funcionais de um Sistema de Ensino a

Distancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.1.1 Funcionalidade Cadastrar Usuario . . . . . . . . . . . . . . . . . . . 78

6.1.2 Funcionalidade Criar um Evento . . . . . . . . . . . . . . . . . . . 79

6.2 Implementacao das Funcoes Cadastrar Usuario e Criar um Evento . . . . . 83

6.3 Cenario da Execucao de Testes . . . . . . . . . . . . . . . . . . . . . . . . 86

6.3.1 Execucao do Teste para a Funcao Cadastrar Usuario . . . . . . . . 87

6.3.2 Execucao do Teste para a Funcao Criar um Evento . . . . . . . . . 94

7 Conclusao 101

7.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Referencias 103

iii

Lista de Figuras

2.1 Estrutura Basica do TelEduc. . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Tela Central do TelEduc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Tela Central do Moodle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Tela de Entrada do e-ProInf. . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Esquema de Funcionamento do Teste Funcional [Coelho, 2005]. . . . . . . . 21

3.2 Ilustracao do Funcionamento da Tecnica de Teste Estrutural [Coelho, 2005]. 22

3.3 Diagrama de Navegacao de Paginas. . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Metamodelo para uma aplicacao Web. . . . . . . . . . . . . . . . . . . . . 27

3.5 Ator e Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Exemplo de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 Diagrama de Classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8 Diagrama de Sequencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.9 Diagrama de Atividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.10 Redes de Petri. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.11 Modelo de Especificacao para Venda de Produtos. . . . . . . . . . . . . . . 38

4.1 Modelo de Desenvolvimento em V. . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Interacao entre o Usuario e o Sistema por meio da Interface. . . . . . . . . 44

4.3 Interface do Sistema de Ensino a Distancia. . . . . . . . . . . . . . . . . . 45

4.4 Rede de Petri Ordinaria: Representacao do Sistema de Cadastro de Usuario

por Redes de Petri Ordinaria. . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Rede de Petri a Objeto: Modelo de Especificacao de Teste Funcional do

Sistema de Ensino a Distancia para a Funcao Cadastrar Usuario. . . . . . 47

4.6 Rede de Petri Ordinaria: Representacao do sistema de Cadastro de Usuario

Iterativo por Redes de Petri Ordinarias. . . . . . . . . . . . . . . . . . . . 48

4.7 Rede de Petri a Objeto: Modelo de Especificacao de Teste Funcional do

Sistema de Ensino a Distancia para a Funcao Cadastrar Usuario . . . . . . 49

4.8 Rede de Petri Ordinaria: Representacao do Sistema de Ensino a Distancia

Paralelo por Redes de Petri Ordinarias. . . . . . . . . . . . . . . . . . . . . 50

iv

4.9 Rede de Petri a Objeto: Modelo de Especificacao de Teste Funcional do

Sistema de Ensino a Distancia Paralelo. . . . . . . . . . . . . . . . . . . . . 51

4.10 Rede de Petri a Objeto: Modelo de Especificacao de teste Funcional do

Sistema de Ensino a Distancia para a Funcao Cadastrar Usuario. . . . . . 52

4.11 Diagrama de Classes Envolvendo as Principais Classes do Sistema de En-

sino a Distancia Generico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.12 Diagrama de Classes Envolvendo as Principais Classes do Sistema de En-

sino a Distancia Generico e a Classe de Teste. . . . . . . . . . . . . . . . . 53

4.13 Diagrama de Casos de Uso para o Sistema de Ensino a Distancia. . . . . . 57

4.14 Representacao do Sistema de Ensino a Distancia Generico por Diagrama

de Atividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.15 Representacao do Sistema de Ensino a Distancia Generico por Redes de

Petri Interpretadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.16 Diagrama de Sequencia do Sistema de Ensino a Distancia para a Operacao

de Cadastro de Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1 Tela Inicial do Sistema - Autenticacao do Usuario no Sistema. . . . . . . . 66

5.2 Tela de Selecao de Cursos Matriculados. . . . . . . . . . . . . . . . . . . . 67

5.3 Tela Principal do Sistema do Curso Selecionado. . . . . . . . . . . . . . . . 67

5.4 Diagrama de Casos de Uso - Generico. . . . . . . . . . . . . . . . . . . . . 68

5.5 Diagrama de Casos de Uso - Inclusao. . . . . . . . . . . . . . . . . . . . . . 69

5.6 Diagrama de Casos de Uso - Agenda. . . . . . . . . . . . . . . . . . . . . . 69

5.7 Diagrama de Casos de Uso - Quadro de Aviso. . . . . . . . . . . . . . . . . 69

5.8 Diagrama de Casos de Uso - Glossario. . . . . . . . . . . . . . . . . . . . . 70

5.9 Diagrama de Casos de Uso - Material Didatico. . . . . . . . . . . . . . . . 70

5.10 Diagrama de Casos de Uso - Mensagens. . . . . . . . . . . . . . . . . . . . 70

5.11 Diagrama de Casos de Uso - Forum. . . . . . . . . . . . . . . . . . . . . . 71

5.12 Diagrama de Casos de Uso - Manutencao de Usuario. . . . . . . . . . . . . 71

5.13 Diagrama de Sequencia - Cria Evento. . . . . . . . . . . . . . . . . . . . . 72

5.14 Diagrama de Sequencia - Altera Evento. . . . . . . . . . . . . . . . . . . . 73

5.15 Diagrama de Sequencia - Excluir Evento. . . . . . . . . . . . . . . . . . . . 74

5.16 Diagrama de Sequencia - Cadastrar Usuario . . . . . . . . . . . . . . . . . 75

5.17 Diagrama de Sequencia - Alterar Usuario . . . . . . . . . . . . . . . . . . . 76

5.18 Diagrama de Sequencia - Excluir Usuario . . . . . . . . . . . . . . . . . . . 77

6.1 Selecao da Opcao Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . 79

6.2 Adicionar um Novo Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3 Diagrama de Atividades para a Funcao Cadastrar Usuario. . . . . . . . . . 80

6.4 Selecao da Opcao de Criar um Evento. . . . . . . . . . . . . . . . . . . . . 81

v

6.5 Cadastrar um Novo Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.6 Diagrama de Atividades para a Funcao Criar um Evento. . . . . . . . . . . 82

6.7 Redes de Petri Interpretada para a Funcao Criar um Evento. . . . . . . . . 83

6.8 Redes de Petri Interpretada: Modelo de Especificacao da Funcionalidade

Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.9 Redes de Petri a Objeto: Modelo de Especificacao de Teste Funcional da

Funcionalidade Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . 84

6.10 Redes de Petri Ordinaria: Modelo de Especificacao Funcionalidade Criar

um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.11 Redes de Petri a Objeto: Modelo de Especificacao Funcionalidade Criar

um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.12 Diagrama de Classes Envolvendo as Principais Classes do Sistema de En-

sino a Distancia - Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . 86

6.13 Diagrama de Classes Envolvendo as Principais Classes do Sistema de En-

sino a Distancia - Criar um Evento. . . . . . . . . . . . . . . . . . . . . . . 87

6.14 Classe de Teste Envolvendo as Classes do Sistema de Ensino a Distancia -

Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.15 Classe de Teste Envolvendo as Classes do Sistema de Ensino a Distancia -

Criar um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.16 Interface Grafica do Teste para a Operacao Cadastrar Usuario. . . . . . . . 89

6.17 Interface Grafica do Teste para a Operacao Criar um Evento. . . . . . . . 89

6.18 Caso de Teste 1 - Resultado para o Teste do Campo Nome do Usuario da

Funcao Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.19 Caso de Teste 1 - Resultado para o Teste do Campo Nome do Usuario da

Funcao Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.20 Caso de Teste 3 - Resultado para o Teste do Campo Email da Funcao

Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.21 Caso de Teste 4 - Resultado para o Teste do Campo Grupo de Usuario da

Funcao Cadastrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.22 Caso de Teste 1 - Resultado para o Teste do Campo Evento da Funcao

Criar um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.23 Caso de Teste 2 - Resultado para o Teste do Campo Data da Funcao Criar

um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.24 Caso de Teste 3 - Resultado para o Teste do Campo Descricao da Funcao

Criar um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.25 Caso de Teste 4 - Resultado para o Teste do Campo Telefone da Funcao

Criar um Evento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.26 Diagrama de Sequencia para a Operacao de Cadastrar Usuario. . . . . . . 100

vi

6.27 Diagrama de Sequencia para a Operacao de Criar Evento. . . . . . . . . . 100

vii

Lista de Tabelas

2.1 Requisitos Exigidos pelo TelEduc. . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Valores dos Atributos apos o Disparo das Transicoes. . . . . . . . . . . . . 56

viii

Capıtulo 1

Introducao

1.1 Contexto

As tecnologias da informacao e comunicacao tem facilitado o aparecimento ambientes

virtuais que auxiliam na aquisicao do conhecimento. Escolas, residencia e empresa tornaram-

se lugares potenciais de aprendizado. A todo momento, pessoas dedicam seus estudos em

casa, tendo acesso a formacao e ao aprendizado a distancia. Devido as exigencias pes-

soais, os interessados podem ter acesso a escolas de informacao disponıveis na rede de

computadores. Como previa [McLuhan, 1969] na decada de 60, o “planeta tornou-se a

nossa sala de aula e o nosso endereco virtual”. O ciberespaco contribuiu com a ideia de

ter tempo exclusivo para a aprendizagem. Nao ha mais distincao de lugar para adquirir

aprendizado, este pode ser em qualquer lugar e no tempos disponıvel.

O Ensino a Distancia e uma modalidade de ensino que surgiu visando contribuir com

a aprendizagem. Ele caracteriza-se pela utilizacao de recursos didaticos organizados, que

podem ser disponibilizados aos interessados por diversos meios, um deles pela rede de

computadores.

Com o desenvolvimento de sistemas web para contribuir com a aprendizagem, surgiu a

necessidade de aplicar as tecnicas de desenvolvimento de software ja conhecidas, evitando

assim que os sistemas desenvolvidos apresentem menos erros. Utilizando estas tecnicas, e

possıvel no final do processo de desenvolvimento obter um software com qualidade maior.

1.2 Objetivos

Este trabalho tem por objetivo aplicar os modelos de teste funcional em um sistema

web utilizado para o ensino a distancia.

Sera proposto um estudo de caso, onde alguns requisitos serao criados para realizacao

do estudo de caso. De posse dos resultados obtidos, sera possıvel fazer uma comparacao

1

com as saıdas esperadas, podendo identificar possıveis erros do sistema.

1.3 Estrutura do Trabalho

Este trabalho esta dividido em 5 capıtulos. No Capıtulo 2 e feito um levantamento

sobre o Ensino a Distancia, buscando informar quando surgiu e os principais sistemas

existentes atualmente. E tambem apresentada funcionalidades basicas que um sistema

web para aplicacoes de aprendizagem atraves da redes de computadores deve possuir.

No Capıtulo 3 inicia-se o processo de levantamento de informacoes referente ao teste

de software. Neste, e abordado informacoes a respeito dos testes para aplicacao web, visto

que o sistema testado neste trabalho, foi desenvolvido para aplicacoes web. Neste capıtulo

tambem sao apresentado nocoes da notacao UML (Unified Modeling Language) e tambem

informacoes sobre as Redes de Petri.

No Capıluto 4 inicia o processo de modelagem da especificacao de teste funcional,

demonstrando como e realizado essa modelagem utilizando as Redes de Petri.

Em virtude de realizar testes em um sistema ja desenvolvido, no Capıtulo 5 sera

realizado a descricao do sistema escolhido para realizar os testes.

De posse dos conteudos expostos, no Capıtulo 6 e realizado o estudo de caso no Sistema

a Distancia, aplicando os conhecimentos adquiridos, posteriormente sendo confrontadas

as saıdas do teste com as saıdas esperadas.

Posteriormente no Capıtulo 6 sera abordado as conclusoes retiradas deste trabalho e

sugestoes de trabalhos futuros.

2

Capıtulo 2

Ensino a Distancia

O Brasil veem apresentando melhoras nos ındices da Educacao, em virtude do desen-

volvimento das novas tecnologias para a Educacao. Uma destas, e o Ensino a Distancia.

Este esta se desenvolvendo e tornando-se uma realidade positiva na Educacao do paıs.

Neste capıtulo, e feito um levantamento sobre o Ensino a Distancia, definicoes, carac-

terısticas, como esta atualmente, referencia de alguns ambientes utilizados para a apren-

dizagem, dentre outros.

2.1 Definicoes e Caracterısticas

Os termos Ensino a Distancia ou EAD, Aprendizagem Aberta, Teleducacao, Educacao

Continuada, Educacao a Distancia sao maneiras diferentes da tradicional de se fazer

educacao. Sao nomenclaturas diferentes para designar a saıda do modo comum (sala de

aula) em que encontra-se acostumados a fazer educacao, para uma maneira diferente de

se educar. Este conceito pode ser explicado tambem como a obtencao de conhecimentos

fora das formas tradicionais de aprendizagem.

Esta obtencao de conhecimentos fora da forma tradicional de aprendizagem pode ser

feita atraves da combinacao de tecnologias convencionais e modernas que possibilitam o

estudo individual ou em grupo, nos locais de trabalho ou fora deles, atraves de metodos

de orientacao e tutoria a distancia, contanto com atividades presenciais ou nao, como

reunioes do grupo para estudo ou avaliacoes.

Varios autores apresentam uma definicao para a EAD, entre elas destacam-se:

[Nunes, 1992]

“Um metodo racional de compartilhar conhecimentos, habilidades e atitudes,

atraves da aplicacao da divisao do trabalho, de princıpios organizacionais e

uso extensivo de meios de comunicacao, atingindo um grande numero de estu-

dantes ao mesmo tempo. E uma forma industrializada de ensinar e aprender.”

3

[Tarouco, 1999]

“Caracterizada pela separacao do professor e o aluno no espaco e/ou tempo, o

controle do aprendizado e realizado mais intensamente pelo aluno do que pelo

instrutor distante, a comunicacao entre alunos e professores e mediada por

documentos impressos ou alguma forma de tecnologia.”

[Cruz, 1999]

“O ensino a distancia e o tipo de metodo de instrucao em que as condutas

docentes acontecem a parte das discentes, de tal maneira que a comunicacao

entre o professor e o aluno se possa realizar mediante textos impressos, por

meios eletronicos, mecanicos ou por outras tecnicas.”

Dessa forma, pode-se afirmar que a EAD e uma maneira de ensino diferente nao

utilizando o padrao do ensino presencial, sem no entanto, deixar de lado pontos positivos

ja aperfeicoados pelo ensino presencial. Estes pontos seriam apresentacao de conteudos,

interacao entre alunos, aplicacao praticas e avaliacoes [Education, 1997].

A EAD e uma modalidade de ensino caracterizada pela utilizacao de recursos didaticos

organizados, que podem ser apresentados aos interessados em varios meios como: radio,

telefone, televisao, cartas, e-mail, teleconferencia, apostilas impressas, jornais, etc. Ao

observar estes meios, pode-se perceber que os mesmos a cada momento estao evoluindo,

em busca constante para atender a necessidade do estudante.

Para determinar um Ensino a Distancia deve-se observar a existencia de determinadas

caracterısticas essenciais:

• Separacao fısica e temporal entre professor e aluno [Pratt e Palloff, 1999]:

Esta caracterıstica refere-se ao fato do docente nao estar presente onde o aluno

esta estudando. O docente pode estar em um estudio de televisao ministrando

sua aula, e o discente em uma sala de aula muito distante. Apesar de estarem

dispersos geograficamente, isto nao impossibilita a comunicacao entre eles, atraves

de tecnologias diversas que servem para auxiliar no aprendizado;

• Comunicacao bidirecional [Aretio, 1998]: Como o proprio nome ja diz, bidire-

cional, significa que entre o estudante e o professor ha um canal de comunicacao.

Neste, o estudante e o professor busca manter uma relacao de dialogo. Este dialogo

mesmo sendo virtual, contribui para o processo de aprendizagem;

• Controle do aprendizado e realizado pelo aluno, enquanto o professor

faz o acompanhamento superficialmente [Pratt e Palloff, 1999]: Neste ponto

surge a preocupacao principalmente com o aluno, e nao com a instituicao. Neste, o

4

aluno controla o seu aprendizado, podendo iniciar quando puder e dar seguimento

quando tiver com seu tempo disponıvel para o estudo. Devido a esta caracterıstica,

percebe-se que o EAD nao possui uma rigidez referente ao requisito de espaco, onde

estudar, e nem de tempo, quando estudar, desde que sejam cumpridas as etapas

necessaria proposta pelo professor;

2.2 Ensino a Distancia no Brasil

O Ensino a Distancia no Brasil iniciou-se no ano de 1923, em que Edgard Roquette

Pinto fundou a Radio Sociedade do Rio de Janeiro, que posteriormente chamada de

Radio MEC. Atraves desta radio, deu-se inıcio a programas de EAD por radiodifusao

[Ortriwano, 1985].

No ano de 1939 foi fundado o Instituto Universal Brasileiro. No decorrer de algunas

anos, o Instituto tornou-se um dos pioneiros na EAD no nosso paıs, oferecendo cursos

profissionalizantes em todo territorio nacional. Ate o ano de 2000, o Instituto Universal

Brasileiro foi responsavel pelo atendimento de mais de tres milhoes de alunos em cursos

a distancia.

Em 1967 o Ministerio da Educacao fundou a FUNTEVE, Fundacao Centro Brasileiro

de Televisao Educativa, atualmente chamada de TVE criada no Rio de Janeiro. Em Sao

Paulo, o Governo criou a Fundacao Padre Anchieta, atualmente chamada de TV Cultura.

Ela tinha por objetivo a promocao de atividades educativas e culturais via radio e TV.

Em 1991 o Projeto “Um Salto para o Futuro”foi criado para atualizar os professores de

series do Ensino Medio e tambem para auxiliar na formacao de professores que estavam

cursando universidade. Este era baseado em programas de televisao, com nucleos de

reunioes em escolas e universidades. Criado pela Fundacao Roquete Pinto, TVE/Rio em

parceria com a Secretaria Nacional de Educacao Basica e alguns estados, o projeto foi

incorporado em 1997 a programacao do canal TV Escola, criado pelo MEC em 1995.

Mesmo com o desenvolvimento do EAD no Brasil, ha deficits no ensino, pois existem

regioes com grandes desigualdades sociais, tornando assim o acesso restrito ao ensino. Em

virtude desta diferenca, o Ensino a Distancia surge no meio como um aliado na busca de

democratizacao do ensino.

Em 1998, foi instituıdo o Plano Nacional de Educacao, no qual aponta diversas prio-

ridades para o ensino brasileiro, dentre estas destaca-se [Saniani, 1998]:

• Elevacao global do nıvel de escolaridade da populacao;

• Melhoria da qualidade de ensino em todos os nıveis;

• Reducao das desigualdades sociais e regionais em relacao ao acesso e permanencia.

5

Para alcancar estes objetivos, foram criadas algumas metas as quais destacam-se:

• Utilizar canais educativos para disseminar os programas culturais e educativos, ga-

rantindo assim, que comunidades basicas tenham acesso a esse meio;

• Apoiar financeiramente a pesquisa na area de Ensino a Distancia.

Apos estudos relevantes na area, percebeu-se que a EAD e a ferramenta imprescindıvel

para conseguir alcancar o objetivo proposto no Plano Nacional de Educacao, em virtude,

como dita nas caracterısticas da EAD, da possibilidade de atingir areas remotas.

Com o avanco da tecnologia (banda larga) e os baixos custos de hardware, tornaram-

se possıvel o acesso ao cursos a distancia. Por ser um paıs de dimensoes continentais, o

Brasil investiu na EAD visando o acesso das pessoas que estao afastadas geograficamente,

cobrindo esta restricao que a geografia do nosso paıs impoe.

2.2.1 Atualmente no Brasil

Em virtude dos precos estarem equivalentes ao dos cursos presenciais, o EAD vem

crescendo no Brasil. O numero de cursos oferecidos aumentou mais de seis vezes em tres

anos, enquanto o de matrıculas teve avanco de mais de quatro vezes, de acordo com o

Censo de Educacao Superior de 2006, do Ministerio da Educacao (MEC).

Os cursos de graduacao aumentaram 8,3% no numero de cursos oferecidos e de 5% na

quantidade de matrıcula efetuada. Os cursos tecnologicos mostraram acrescimo de 31,3%

no numero de inscritos. Em 2005, os alunos do EAD representavam 2,6% de todos os

estudantes, ja no ano seguinte representavam 4,4% [Boas, 2008].

O presidente do Conselho Cientıfico da Associacao Brasileira de Educacao a Distancia

(Abed), Waldomiro Loyolla, ressaltou que o curso a distancia nao pode ser comparado

como mais caro ou mais barato do que os realizados presencialmente. Segundo Waldomiro,

e incomparavel distinguir por precos. De acordo com o presidente, ha um mito que cursos

a distancia sao mais baratos.

Entretanto, o presidente do conselho disse que a crenca nao e verdadeira. Para ele, e

a demanda que determina se o curso a distancia sera mais caro. “Toda vez que se ganha

em escala, pode ser que fique mais barato. Para voce oferecer o curso tem toda uma fase

de preparacao, que pode ficar cara se for oferecida para um pequeno grupo”[Boas, 2008].

Segundo ele, o curso a distancia nao surgiu para substituir o ensino presencial. “Eles

oferecem flexibilidade para quem tem resistencia geografica ou temporal. No geral, eles

nao sao preferencia”[Boas, 2008].

Estudos do Instituto Nacional de Estudos e Pesquisas Educacionais Anısio Teixeira

(INEP) mostram que, em 7 das 13 areas avaliadas no Exame Nacional de Desempenho de

6

Estudantes (Enade), os alunos que cursaram o Ensino a Distancia se saıram melhor que

os de cursos presenciais.

2.3 Ambientes Virtuais de Aprendizagem

Os Ambientes Virtuais de Aprendizagem (AVA) sao sistemas criados especificamente

com o intuito de colaborar no Ensino a Distancia. Sao sistemas que armazenam, dispo-

nibilizam e administram conteudos expostos no ambiente. Estes sistemas sao capazes de

oferecer tecnologias de informacao que permite a cada participante evoluir no seu estudo

de acordo com o seu tempo e ritmo [Moraes, 2002].

Os AVA’s podem ser utilizados tanto em atividades presenciais na qual permitem que

os participantes atraves das tecnologias da informacao se interajam, como tambem se

fosse semi-presenciais, na qual estes sistemas servem como um suporte a comunicacao e a

troca de informacao entre os participantes. De acordo com [Moraes, 2002], “Em qualquer

situacao de aprendizagem, a interacao entre os participantes e de extrema importancia.

E por meio das interacoes que se torna possıvel a troca de experiencias, o estabelecimento

de parcerias e a cooperacao”.

O uso dos AVA’s pode influir em determinadas vantagens:

• Interacao entre o aluno e computador;

• Possibilidade de individualizar a atencao a um aluno especıfico;

• O aluno torna-se capaz de impor seu proprio ritmo, definindo a sequencia a ser

seguida e o tempo a ser gasto;

• Possibilidade de apresentar conteudos de estudo de uma maneira mais criativa,

atrativa e integrada, em virtudes dos vastos recursos existentes ao se usar um com-

putador.

Segundo [Azevedo, 2002], existem duas abordagens pedagogicas no Ensino a Distancia:

A primeira e o auto-instrucional, na qual constitui-se a ideia de que a transmissao da

informacao e a base da educacao. Este primeiro modelo refere-se ao fato do aluno aprender

o que lhe e ensinado, a partir de um meio de transmissao sempre definido, entrando em

contato com o professor para esclarecer alguma duvida que seja criada. Ja o segundo

modelo, o colaborativo, segue a ideia que a interacao do aluno com o professor deve

ocorrer em todo momento, desde o surgimento de uma questao, a sua problematizacao,

a discussao, posteriormente surgindo assim possıveis duvidas e por fim, o esclarecimento

atraves da troca de informacao.

7

Nao importando o tipo de modelo pedagogico escolhido, este sistema deve possuir um

conjunto basico de funcionalidades que viabilizem a proposta criada ao ser planejado o

curso.

Estas funcionalidades podem ser divididas de acordo com [Gonzalez, 2005] em quatro

categorias:

• Ferramentas de Coordenacao;

• Ferramentas de Comunicacao;

• Ferramentas de Producao dos Alunos ou de Cooperacao;

• Ferramentas de Administracao.

Ferramentas de Coordenacao

A primeira destas ferramentas e a de coordenacao. Esta ferramenta ajuda na co-

ordenacao do curso. Atraves das ferramentas de coordenacao, o professor e capaz de

disponibilizar aos alunos, informacoes metodologicas do curso (duracao, objetivos, ex-

pectativas, bibliografias, meios de avaliacao), informacoes do funcionamento do ambiente

(descricao dos recursos do sistema, como agenda, forum), informacoes pedagogicas como

materiais de apoio (guias, tutoriais), material de leitura (textos de referencias, links, bi-

bliografias). Em fim, um conjunto de ferramentas que viabilizara que o ambiente esteja

de acordo para a utilizacao por parte do aluno [Gonzalez, 2005].

Ferramentas de Comunicacao

As ferramentas de comunicacao caracterizam-se por serem funcoes disponıveis no am-

biente de aprendizagem que permitem a comunicacao dos alunos com os professores, e

dos alunos com eles mesmos. Estas ferramentas de comunicacao podem ser dividas em

sıncronas e assıncronas [Gonzalez, 2005]. Na secao 2.7 estes tipos de comunicacao e abor-

dado com mais clareza.

Ferramentas de Producao do Aluno ou Cooperacao

As ferramentas de producao do aluno ou de cooperacao, sao ferramentas capazes de

expor trabalho feito por um aluno, ou ferramentas capazes de expor trabalhos feitos por

alunos atraves da cooperacao, onde cada membro do grupo cooperou para que o produto

final tenha sido criado com sucesso. Por exemplo, esta ferramenta seria um portfolio com

8

o produto final obtido [Gonzalez, 2005].

Ferramentas de Administracao

As ferramentas de administracao sao ferramentas necessarias para o gerenciamento do

sistema, para que o curso planejado flua como o planejado.

Estas ferramentas podem ser de diversos tipos, abaixo seguem algumas delas [Gonzalez, 2005]:

• Ferramentas de cronograma de curso: esta ferramenta permite controlar o

cronograma do curso, sendo que, a medida que uma etapa seja finalizada, novos

modulos sao disponibilizados;

• Ferramenta de inscricoes: esta ferramenta permite que seja administrado as ins-

cricoes realizadas em determinado curso. Se a mesma e aceita, verifica pagamentos,

dentre outras;

• Ferramenta de controle de acesso a determinados modulos do sistema:

esta ferramenta auxilia o administrador do sistema determinar qual parte do sistema

o usuario podera acessar. Um professor, por exemplo, tem acesso ao cadastro de

material didatico, ja o aluno nao possui;

• Ferramentas de apoio ao tutor, para inserir conteudos, verificar alunos,

etc: esta ferramenta disponibiliza meios para que o tutor possa inserir corretamente

seus conteudos;

• Ferramentas de visualizacao de desenvolvimento do aluno: esta ferramenta

funciona como um monitor para o administrador, em que ele ira verificar se o aluno

esta cumprindo corretamente o curso e se ele esta adquirindo aproveitamento ne-

cessario.

2.4 Descricao Geral de Alguns Ambientes Virtuais

de Aprendizagem

No mundo e tambem no Brasil, diversas universidades tem-se desenvolvido em busca

de um AVA que lhes proporcionem melhores resultados. Sendo assim, diversos AVA’s

foram criados, como o Moodle, Teleduc, AulaNet, e-Proinfo, SOLAR, WebCT, etc. A

seguir e apresentado a descricao de alguns AVA’s.

9

2.4.1 TelEduc

Iniciou-se em 1998, encontrando-se na versao 4.0.1, o TelEduc e um sistema de ensino a

distancia criado no Nied (Nucleo de Informatica Aplicada a Educacao) sobre a orientacao

da professora Dra. Heloısa Vieira da Rocha do Instituto de Computacao da Universidade

Estadual de Campinas. O objetivo, era formar professores para trabalhar em diversos

recursos que a informatica poderia contribuir na educacao. Seguia-se o principio que o

professor para trabalhar com a informatica com seus alunos, deveria ser capaz de usar

os recursos, observar as dificuldades do aluno junto ao computador, intervir e auxiliar o

aluno a romper estas dificuldades [TelEduc, 2008].

Tentando minimizar as dificuldades surgidas pelo uso da informatica, o TelEduc foi

criado de uma forma participativa, em que todas as ferramentas disponibilizadas foram

idealizadas atraves de opinioes de usuarios. Sendo assim, a partir do momento que um re-

curso e disponibilizado, o mesmo ja passou antes por diversas discussoes para ser moldado

com intuito de facilitar o aprendizado.

Com o passar dos anos, o projeto ainda continua em franco desenvolvimento, a cada

momento surgindo funcionalidades que estao em alta, e que depois de aprovadas, sao

disponibilizadas no TelEduc.

Dentre os recursos oferecidos por este AVA tem-se [TelEduc, 2008]:

• Ferramentas de Coordenacao: Agenda, Dinamica do Curso, Leituras, Ativi-

dades, Perguntas Frequentes, Grupos, Material de Apoio, Enquetes;

• Ferramentas que apoiam a autoria: Controle de acesso;

• Ferramentas de Administracao: Gerenciamento de inscricoes, Estipulacao de

datas de inıcio de um curso, gerenciamento de alunos e de professores, relatorios de

utilizacao;

• Ferramentas de Comunicacao: Bate-Papo, Forum de Discussao, Mural, Diario

de Bordo, Perfil, Correio Eletronico.

Este AVA foi criado tendo como elemento principal a ferramenta Atividades. Ao ser

lancado uma atividade, para solucionar o que se propoe, deve-se fazer uma busca para

chegar a uma solucao aceitavel. Sendo assim, outros recursos disponibilizados surgem para

viabilizar a comunicacao entre os participantes. Atraves da Figura 2.1 pode-se identificar

a estrutura basica utilizada no AVA TelEduc.

Nesta Figura 2.1 tem-se uma atividade para ser realizada. Quando um aluno entra no

sistema, ele visualiza a atividade proposta. Atraves dos recursos oferecidos pelo sistema,

o aluno vai pesquisar (Material de Apoio), vai discutir entre os participantes (Grupo de

Discussao) dentre outros ate chegar a solucao desta atividade.

10

Figura 2.1: Estrutura Basica do TelEduc.

Um ponto importante no AVA TelEduc, e que o mesmo e um software livre. Sendo

assim, podem ser feitas modificacoes nas ferramentas, desde que siga os termos da GNU

(General Public License).

O TelEduc foi criado usando a linguagem PHP1 e utilizando o banco de dados MySQL2,

pode ser instalado em qualquer servidor Linux. Uma das premissas no desenvolvimento

deste AVA e o desenvolvimento de um ambiente leve e robusto para que possa ser acessado

por qualquer computador que tenha acesso a internet. Na Tabela 4.1, segue os requisitos

mınimos exigido para a instalacao deste AVA.

Como exemplo do TelEduc, na Figura 2.2, mostra a tela central do sistema no qual

aparece em destaque a Ferramenta Atividade.

2.4.2 Moodle

Apos falar sobre um AVA brasileiro, este AVA Moodle (Modular Object Oriented Dy-

namic Learning Enviroment) ou Ambiente de Aprendizagem Dinamico, Modular e Orien-

tado a Objetos, foi criado em 2001. Este sistema e livre, desenvolvido inicialmente na

1PHP e o acronico de Hypertext Preprocessor e e uma linguagem de programacao utilizada para gerar

conteudos dinamicos na Web. Foi criada em 1994 por Rasmus Lerdof [Wikipedia, 2008f].2MySQL e um sistema de gerenciamento de banco de dados que utiliza a linguagem SQL (Struc-

tured Query Language), ou Linguagem de Consulta Estruturada, para trabalhar com sua interface

[Wikipedia, 2008e].

11

Maquina PC - Pentium II 333 MHz, 64 de RAM, 4.5

GB de Disco Rıgido

Sistema Operacional Linux

Servidor Web Apache

Banco de Dados MySql

Outros PHP

Linguagem de Programacao SendMail (Programa de envio de e-mails) ou

Lynx (Navegador para uso de scripts no ser-

vidor)

Tabela 2.1: Requisitos Exigidos pelo TelEduc.

Curtin University of Tecnology na Australia. Em 2 de marco de 2008 foi lancada a versao

1.9.1+.

O Moodle segue a ideia de todo AVA, servir como um ambiente de cooperacao na

aprendizagem. O Moodle em 05 de junho de 2008 era utilizado em mais de 43000 entidades

disponibilizando um total de 1 milhao de cursos com mais de 20 milhoes de usuarios

cadastrados em todo o mundo, como pode ser conferido no site [Moodle, 2008].

O Moodle e uma referencia de AVA, em virtude de ser desenvolvido de forma mo-

dular, o que permite assim grande flexibilidade para adicionar, configurar ou remover

funcionalidades. Sendo assim, existe uma comunidade crescente de usuarios que contribui

no desenvolvimento e apoio de novos usuarios. Este AVA segue a filosofia do WYSIWYG,

do ingles “What You See Is What You Get”, traduzindo “O que voce ve e o que voce

tem”, ou seja, e uma capacidade do ambiente permitir que o que esta sendo manipulado

na tela seja semelhante ao que sera ao imprimir.

Um fator que diferencia o Moodle de outros AVAs e que o seu criador Martin Dougia-

mas tem formacao em educacao. Quando teve a ideia de criar um AVA, buscou primeira-

mente privilegiar a educacao, ao contrario de outros AVAs que privilegiam a construcao

de novas ferramentas computacionais.

Este AVA segue os termos da GNU (General Public License) e pode ser instalado em

ambientes Unix, Linux, Windows e Mac OS. Desenvolvido utilizando a linguagem PHP,

porem diferentemente tambem do TelEduc, a base de dados deste AVA pode ser MySQL,

PostgreSQL, Oracle, Access, Interbase ou OBDC. O AVA Moodle encontra-se atualmente

traduzido em mais de 70 linguagens em todo o mundo inclusive para o portugues.

Os recursos disponibilizados pelo Moodle sao: materiais, avaliacao do curso, chat,

dialogo, diario, forum, glossario, licao, pesquisa de opiniao, questionario, tarefa, trabalho

com revisao e wiki. A Figura 2.3 mostra a tela inicial do AVA Moodle, em que o aluno

entra com seu Nome de Usuario e Senha e tem acesso ao sistema.

12

Figura 2.2: Tela Central do TelEduc

2.4.3 e-ProInfo

Este AVA diferentemente dos outros citados acima e um sistema publico, desenvolvido

pela Secretaria de Educacao a Distancia ou SEED do MEC e algumas outras instituicoes

de ensino. Ele e licenciado por meio da GNU (General Public License). Atualmente o

sistema conta com mais de 100 mil cadastrados que participaram em algum dos mais de

mil cursos ja cadastrado no sistema [e ProInfo, 2008].

O e-ProInfo utiliza a internet para concepcao, administracao e desenvolvimento de

diversas acoes, como os cursos a distancia, servindo como um complemento de cursos

presenciais, projetos de pesquisas, projetos colaborativos e outros diversos tipos de apoio

de aprendizagem a distancia.

O responsavel pela manutencao do e-ProInfo fica a disposicao de cada entidade cadas-

trada. Esta, ira cadastrar os responsaveis de acordo com o perfil de acesso de cada um.

Definido o perfil dos usuarios, estes terao direitos especıficos de acordo com os recursos

disponıveis para este. Os perfis existentes neste AVA sao [e ProInfo, 2008]:

• Administrador de Entidade;

• Administrador de Curso;

• Administrador de Modulo;

• Administrador de Turma;

13

Figura 2.3: Tela Central do Moodle.

• Colaboradores(monitores, professores, orientadores, pesquisadores, etc);

• Alunos;

• Visitantes.

Este AVA e composto por duas partes principais, o site do administrador do sistema

e o site do participante. Dentre os recursos disponıveis para o apoio as atividades dos

participantes, tem-se: Tira Duvidas, Agenda, Avisos, Diario e Biblioteca. Outros recur-

sos, estao disponıveis para a interacao entre os participantes, como E-mail, Chat, Forum

de Discussoes e Banco de Dados de Projetos. Existem tambem ferramentas de avaliacao

de desempenho, como estatısticas de atividades e questionarios, servindo de base para o

professor verificar o nıvel de desempenho dos participantes. A Figura 2.4 mostra a tela

inicial do sistema. Ao entrar no sistema, o utilizador tem aceso aos recursos citados acima.

Apesar de este AVA ser criado pela SEED, ele e muito utilizado pelas entidades que

estao cadastradas no sistema. Basta que a entidade entre em contato, solicitando que

seja feito um termo de parceria e concessao de direitos da entidade com a SEED, a partir

de ser avaliado o pedido, caso seja aprovada, a entidade esta liberada para utilizar os

potenciais do sistema [e ProInfo, 2008].

14

Figura 2.4: Tela de Entrada do e-ProInf.

2.5 Requisitos Necessarios para um Ambiente Vir-

tual de Aprendizagem

Segundo Rossett [Rossett, 1989], para se criar um AVA, deve haver integracao de

conteudos, aplicacoes e servicos do Ensino a Distancia, desenvolvendo-se uma infra-

estrutura de software que satisfaca os principais requisitos a seguir:

• Escalabilidade: Deve ser capaz de permitir o acesso a centenas de usuarios, possuir

grande capacidade de armazenamento de conteudos, sendo possıvel ser acessado pelo

uso de sistemas multiprocessados, que permitem alto volume de processamento de

conteudo de aprendizagem;

• Acessibilidade: A estrutura de Ensino a Distancia deve permitir o acesso ao conhe-

cimento e ofertar informacoes atraves do software desenvolvido, em qualquer lugar,

em qualquer local e em qualquer momento;

• Extensibilidade: A medida que as tecnologias e os requisitos evoluem, a estru-

tura de Ensino a Distancia deve permitir que novos componentes sejam integrados

facilmente;

• Flexibilidade: Deve prover um ambiente de trabalho flexıvel e um modelo de

processo que possa ser configurado para satisfazer as necessidades da organizacao;

• Interoperabilidade: A estrutura de Ensino a Distancia deve permitir que conteudos

15

e outros dados possam ser compartilhados por outras ferramentas separadas ou por

sistemas conectados pela Internet;

• Reusabilidade: Conteudos reutilizaveis sao essenciais para economizar tempo e

o custo do desenvolvimento de novos conteudos de treinamento: Em um ambiente

de Ensino a Distancia atualizado, os conteudos devem ser criados em componentes

que sao unidos em bases de dados unificadas que permitem guardar objetos ou

partes constituintes para serem usados novamente por criadores ou utilizadores de

conteudo;

• Seguranca: As aplicacoes internas sao abertas aos socios, clientes e provedores ex-

ternos. Para outro servico ter acesso mais rapido, a estrutura de Ensino a Distancia

nao deve comprometer a seguranca de dados, informacao ou conhecimento. Deve-

se criar mecanismos que protejam o sistema inviabilizando o acesso que nao seja

permitido;

• Tendencias de Padroes: A cada momento surge novos padroes importantes no

Ensino a Distancia. Os esforcos de padronizacoes e colaboracoes servem para mel-

horar os recursos de aprendizagem, estruturas de conteudo e dados de administracao

de usuario.

2.6 Ferramentas Utilizadas em Ambientes Virtuais

de Aprendizagem

Os Ambientes Virtuais de Aprendizagem apresentam diversas ferramentas que po-

dem promover a comunicacao sıncrona como a assıncrona. As ferramentas sıncronas sao

ferramentas que permitem a comunicacao simultanea, ou seja em tempo real, em que es-

tudantes e professores estao em contato em tempo real, no mesmo espaco de tempo. Para

exemplificar esta ferramenta, pode-se destacar as salas de bate-papo, vıdeo conferencia,

etc. Abaixo segue os principais exemplos deste tipo de comunicacao

• Chat : Comunicacao que ocorre em tempo real entre duas ou mais pessoas, chamada

tambem como bate-papo;

• Videoconferencia: Comunicacao bidirecional atraves de envio de audio e vıdeo

em tempo real, via Web,por meio de cameras ligadas ao computador;

• Teleconferencia: Todo o tipo de conferencia a distancia que ocorre em tempo real,

envolvendo transmissao e recepcao de diversos tipos de mıdia (material impresso,

radio, tv, radio e tv web) [Gonzalez, 2005], assim como suas combinacoes;

16

• Audio-conferencia: Sistema de transmissao de audio, recebido por um ou mais

usuarios simultaneamente.

Do outro lado, temos as ferramentas assıncronas. Esta ferramenta, nao necessaria-

mente exige que os participantes estejam conectados ao mesmo tempo em um mesmo

local, sendo assim, caso o participante nao possua disponibilidade de participar em fer-

ramentas sıncronas, ele pode participar atraves desta outra ferramenta. Esta ferramenta

pode ser exemplificada por um mural, forum de discussao, etc [Gonzalez, 2005]. Abaixo

segue os principais exemplos deste tipo de comunicacao:

• E-mail : Forma digital de dialogo utilizado pela Internet;

• Grupos de Discussao: Utilizado para estimular a troca de informacoes atraves

de mensagens entre membros de uma comunidade virtual que tem interesses afins.

Esta tambem e chamada de lista de discussao;

• World Wide Web (WWW): Definida como um grande sistema de informacoes

que permite a recuperacao de informacao hipermıdia. Ela possibilita o acesso uni-

versal de um grande numero de pessoas a um grande universo de documentos;

• FTP e Download : Disponibilizacao de arquivos contendo audio, texto, imagens

ou vıdeos;

• Vıdeo e Audio sob demanda: permite assistir-se, assincronamente, vıdeos ou

audios previamente gravados e armazenados no servidor.

Visando romper as restricoes espaco-temporais inerentes aos cursos realizados a distancia,

a comunicacao por texto, como o chat, as mensagens instantaneas e os foruns de dis-

cussao estao sempre disponıveis no conjunto de ferramentas oferecidas pelos AVA’s. Por

limitacoes de ordem tecnica, o audio e o vıdeo sıncrono sao menos presentes, embora pos-

sam ser suportados de maneira complementar por aplicacoes externas aos AVA’s, como

os programas o Windows Live Messenger 3 e o Skype4

3Windows Live Messenger e um programa da mensagens instantaneas criado pela Microsoft Cor-

poration e atualmente o Messenger mais usado no mundo com mais de 230 milhoes de usuarios

[Wikipedia, 2008d].4Skype e um programa que realiza ligacoes telefonicas e videoconferencias pela Internet. Com a funcao

chamada Voz por IP (VoIP), os usuarios podem fazer ligacoes para outros contatos cadastrados no servico

sem nenhum tipo de custo, bem como fazer chamadas do computador para um telefone fixo ou celular a

precos mais baixos que as tarifas convencionais [Wikipedia, 2008g].

17

Capıtulo 3

Teste de Software

O teste e uma das atividades mais utilizadas no desenvolvimento de um software, pois

atraves dele e possıvel fornecer evidencias reais do tamanho da confiabilidade do software

testado [Maldonado, 1997].

Neste capıtulo, sera feito um levantamento sobre testes, como montar um caso de

teste (planejar, projetar, executar, avaliar). Sera abordado os tipos de teste, enfocando

tambem os testes para aplicacao web que tem o foco deste trabalho. Posteriormente sera

apresentado a notacao UML e as Redes de Petri.

3.1 Conceitos Basicos

No princıpio a preocupacao da computacao situava-se no desenvolvimento de hardware

capazes de suportar cada vez mais armazenamento e desempenho. Apos estes fatores

limitantes serem resolvidos, surgiu-se a necessidade de desenvolvimento de sistemas mais

robustos libertando o usuario comum da necessidade de passar muito tempo em frente ao

computador para realizar uma operacao especıfica.

Em virtude da necessidade decorrente do desenvolvimento dos hardwares, novos soft-

wares comecaram a ser criados ou aperfeicoados. Como nao havia um padrao de desen-

volvimento de softwares, cada desenvolvedor fazia da forma que lhe agradava, culminando

na dificuldade excessiva de comunicacao entre os desenvolvedores em um grande projeto.

Na decada de 1960 foi criado o termo Engenharia de Software e utilizado oficialmente

em 1968 na NATO Conference on Software Engineering (Conferencia sobre Engenharia

de Software da OTAN). Este termo foi criado em virtude do desenvolvimento do software

estar envolvido na conhecida crise do software [Mcilroy, 1968].

Devido a esta crise, passa-se a utilizar um conceito proposto por Friedrich Ludwig

Bauer a respeito da engenharia. Para ele, a “Engenharia de software e a criacao e a uti-

lizacao de solidos princıpios de engenharia a fim de obter software de maneira economica,

que seja confiavel e que trabalhe eficientemente em maquinas reais”[Mcilroy, 1968].

18

Apesar do processo de desenvolvimento de software ja existente, certos fatores ocorrem

no decorrer do desenvolvimento do software que passam despercebidos. Uma atividade

relacionada a Garantia de Qualidade de Software tem sido introduzida no decorrer do

processo de desenvolvimento, a VV&T. Esta sigla que significa Verificacao, Validacao e

Teste e e uma nomenclatura usada que na verdade significa a utilizacao destes meios para

minimizar a ocorrencia de erros e riscos associados [Pressman, 2000].

O teste e uma das atividades mais utilizadas no desenvolvimento de um software,

pois atraves de uma varredura dinamica no software, fornece evidencias reais do ta-

manho da confiabilidade do software em questao [Maldonado, 1997]. De acordo com

[Myers, 1998], “Software deve ser previsıvel e consistente, nao oferecendo nenhuma sur-

presa aos usuarios”, gerando assim uma tranquilidade para o usuario do software.

A atividade de teste de software e processo de executar o software de uma maneira

controlada e com o objetivo de avaliar se o mesmo se comporta como o requerido. Para

este controle ser eficiente, esta atividade de teste requer atencao e cuidado antes de in-

iciar. Para realizar o processo de forma controlada, o processo de teste de um software

envolve algumas etapas principais e estas devem ser executadas durante todo transcorrer

do desenvolvimento de um teste de software. Estas etapas sao [Delamaro, 1993]:

• Planejamento de testes - Nesta etapa, busca-se a criacao de um plano de teste.

Neste momento, sao definidas as etapas e categorias de testes a serem criadas. Iden-

tificando as informacoes existentes no projeto e o proposito do teste a ser testado.

Contem tambem os requisitos do software que sera testado, regras, estrategias, fer-

ramentas, tecnicas que serao utilizadas, recursos necessarios e um cronograma no

qual consta as atividades a serem executadas e a sua duracao.

• Projeto de casos de teste - Nesta etapa, consiste em descrever os requisitos do

sistema e exemplificar o possıvel comportamento que se espera de cada acao. Ou

seja, documentar cada caso.

• Execucao de testes - Apos o desenvolvimento dos modelos de testes criados, passa-

se a parte da pratica, onde realmente ira perceber os possıveis resultados a partir

do domınio de entrada no software.

• Avaliacao dos resultados coletados - Finalmente chega a fase mais esperada,

aquela que possivelmente ira dizer se o software em desenvolvimento esta no caminho

correto. De posse do projeto de casos de teste1, sabem-se os possıveis resultados

que deve ser obtidos. Ao confrontar com os resultados obtidos, ao observar alguma

1Casos de Teste: E caracterizado por uma entrada e uma saıda. A entrada e composta por dados ou

informacoes que sao importantes para que um programa seja processado e a saıda por sua vez, seria a

resposta do programa apos ser processado [Farines et al., 2000].

19

discrepancia, imediatamente deve ser informado aos desenvolvedores, para o quanto

mais cedo resolver as pendencias encontradas.

Segundo [Myers, 1998], a atividade de teste e a tarefa de executar um software com

interesse de encontrar um erro. Na procura pelo erro, um caso de teste bom e aquele que

possui alta probabilidade de revelar a presenca de erros e ja um teste bem sucedido e

aquele que localiza a presenca de um erro ainda nao descoberto.

Para obter um software de alta qualidade a primeira ideia e que deve ser executada

todas as possıveis combinacoes de um domınio de entradas caracterizando-se como teste

exaustivo. Mas apos diversos estudos e praticas, percebeu-se que na maioria das vezes,

o teste exaustivo e impraticavel devido as restricoes principalmente de tempo e custos.

Sendo assim, e necessario determinar quais casos de teste devem ser utilizados, a fim de

que a maioria dos possıveis erros existentes possam ser encontrado e que o caso de teste

utilizado nao seja tao grande inviabilizando a sua realizacao [Souza, 1996].

3.2 Fases de Teste de Software

Quando os testes sao elaborados, tecnicas ou fases devem ser estabelecidas como forma

de obter maior qualidade e seguranca durante a execucao dos mesmos. Dentre estas

tecnicas de teste, destacam-se os testes funcional, estrutural e baseado em erros. Na

verdade, a diferenca entre estas tecnicas citadas, esta na origem dos dados utilizados

para avaliar ou construir os conjuntos de casos de teste, sendo que cada uma possui um

conjunto de criterios com que venha acolher o objetivo de obter um software com maior

qualidade [Maldonado, 1991].

Visando a busca da qualidade, tecnicas e criterios de teste tem uma maneira cuidadosa

e rigorosa para selecionar um subconjunto do domınio de entrada e, com isso, ser eficiente

para determinar a presenca de erros, claro que, ao mesmo tempo atender a restricao de

tempo e custos associados a um projeto de software [Souza, 1996]. Em virtude da atual

conjuntura existirem inumeros criterios, a Engenharia de Software, atraves de estudos

empıricos e teoricos, busca o desenvolvimento de estrategias de teste com uma boa relacao

em termos de custo e benefıcio.

Antes de abordar estas tres tecnicas de teste de software, e necessario ressaltar que

nenhuma delas separadamente e completa, mas quando usadas uma junto da outra, pro-

vavelmente serao capazes de assegurar um teste de boa qualidade [Pressman, 1997]. Segue

abaixo um levantamento como e estas tres tecnicas em questao.

20

3.2.1 Teste Funcional

O teste funcional ou comumente chamado de “caixa preta”, trata-se o software em

desenvolvimento como uma caixa na qual o conteudo e desconhecido sendo conhecido

apenas seu lado externo [Pressman, 2000]. Desta maneira, o encarregado da atividade de

teste utiliza a especificacao dos requisitos do software para derivar casos de testes que serao

empregados sem se preocupar com o que foi implementado no software [Beizer, 1990]. A

especificacao correta e de acordo com os requisitos do usuario e essencial para este tipo

de teste [Vicenzi, 1998].

Na Figura 3.1 ilustra o processo de funcionamento do Teste Funcional. Nele tem-se

os Dados de Entrada que e o caso de teste que sera utilizado para testar o sistema. O

Programa e o software que sera testado. O Dados de Saıda sao os resultados obtidos apos

a execucao do software. De posse destes Dados de Saıda, eles serao confrontados com

a Saıda Esperada, verificando assim quais foram os tipos de Dados de Entrada que nao

se comportaram de acordo com o esperado no fim da execucao do programa. Apos este

confrontamento, tem-se resultados que irao ajudar melhorar a qualidade do software.

Figura 3.1: Esquema de Funcionamento do Teste Funcional [Coelho, 2005].

O Teste Funcional possui algumas limitacoes. Uma delas se refere em quantificar a

quantidade de testes que devem ser executadas. Dessa forma alguns criterios ou estrategias

foram estabelecidos para amenizar o problema.

Segundo [Pressman, 1997] alguns criterios podem ser utilizados para realizacao do

Teste Funcional sao:

• Particionamento de equivalencia - este criterio divide o domınio de entrada

em classes de dados validas e invalidas que irao exercitar uma funcao do software

especifico. Em cada classe existente e escolhido um elemento que representa toda a

classe. Desta maneira, o objetivo e gerar menos casos de testes e que cada elemento

de uma classe invalida represente um caso de teste distinto.

• Analise do Valor Limite - Criterio complementar ao particionamento de equi-

valencia. Ao inves de selecionar qualquer elemento de uma classe, os casos de testes

sao escolhidos nas fronteiras das classes, em virtudes destes pontos concentrarem

um grande numero de erros.

21

• Grafo de Causa-Efeito - Estuda-se a combinacao das condicoes de entrada do

programa. As condicoes de entrada (causa) e as acoes (efeitos) sao combinadas

dando origem a um grafo que determinara os casos de teste [Souza, 2000].

3.2.2 Teste Estrutural

E tambem conhecido como teste de “caixa branca”, pois seu maior enfoque esta na

implementacao e na estrutura da funcao, para a escolha dos casos de teste [Souza, 2000].

O Teste Estrutural baseia-se no funcionamento interno do programa, testando os possıveis

caminhos logicos do programa que devam ou nao ser percorridos [Sugeta, 2004].

Nessa tecnica, os programas sao representados por meio do Grafo de Fluxo de Controle

ou Grafo de Programa que e caracterizado por ser um grafo orientado em que o vertice

representa um bloco de comandos e as arestas sao representadas como sendo o desvio, ou

o caminho de um bloco para o outro, quando o primeiro comando do bloco e executado

todos os demais comandos do bloco sao executados em sequencia. Atraves deste grafo,

os componentes a serem executados sao escolhidos, formalizando as caracterısticas do

Teste Estrutural [Souza, 2000], [Sugeta, 2004]. A Figura 3.2 ilustra tal processo do Teste

Estrutural.

Figura 3.2: Ilustracao do Funcionamento da Tecnica de Teste Estrutural [Coelho, 2005].

O Teste Estrutural utiliza-se de criterios para determinar quais partes do programa

devem ser executadas no teste. Entre esses criterios [Souza, 2000] destaca:

• Criterios Baseados na Complexidade: atraves de dados sobre a complexidade

do programa, determinam-se os requisitos de teste;

• Criterios Baseados no Fluxo de Controle: baseia-se no controle de execucao

do programa atraves comandos ou desvios, sendo que estes determinam requisitos

22

de teste. Os criterios mais conhecidos desta tecnica sao: Todos-Nos, Todos-Arcos

e Todos-Caminhos. O criterio Todos-Nos e definido como sendo a necessidade de

todos os comandos serem executados no mınimo uma vez, cobrindo todos os nos ou

vertices do grafo de programa. No criterio Todos-Arcos todas as arestas do grafo

de programa que correspondem ao controle de transferencia devem ser executadas

pelo menos uma vez. E por fim, o criterio de Todos-Caminhos define que todos os

caminhos e combinacoes de arcos devem ser executados, porem, em um programa

podem existir varios loops o que torna esse criterio inviavel;

• Criterios Baseados no Fluxo de Dados: utiliza informacoes sobre o fluxo de

dados do programa. As interacoes que envolvem as variaveis de referencia devem

ser testadas;

Uma desvantagem verificada na tecnica estrutural e a dificuldade de se determinar

se um caminho e executavel ou nao, sendo necessario que o “testador”identifique quais

caminhos sao executaveis.

3.2.3 Teste Baseado em Erro

A tecnica de Teste Baseada em Erros consiste na utilizacao de informacoes de erros

que sao cometidos com maior frequencia no processo de desenvolvimento de software e

tambem sobre os tipos especıficos de erros que se desejam revelar [Demillo, 1987].

No teste baseado em erros, a partir de um programa considerado como correto, sao

gerados uma colecao de programas (copias ou mutantes), e a partir daı sao planejados

testes com a intencao de provocar diferencas de comportamento no programa original e

em suas copias [Souza, 2000]), [Sugeta, 2004], [Delamaro et al., 2003].

Dois criterios que se concentram em erros sao os criterios de Semeadura de Erros

(Error Seeding) [Budd, 1981] e Analise de Mutantes (Mutation Analysis) [Demillo, 1978].

• Criterio Semeadura de Erros: erros sao inseridos propositalmente no programa

e durante os testes, tanto os erros naturais quanto os inseridos propositalmente

devem ser encontrados. A partir de estimativas de probabilidade, o numero de erros

naturais ainda existentes no programa pode ser calculado [Goel, 1985].

• Criterio de Analise de Mutantes: a partir de modificacoes inseridas no pro-

grama, geram-se copias do programa que sao chamados de mutantes. O intuito

desta tecnica e descobrir casos de teste que identifique a diferenca entre o programa

original e as copias (mutantes) [Demillo, 1987].

23

3.3 Testes de Aplicacao WEB

No inıcio, as aplicacoes Web eram utilizadas especialmente para apresentacao de in-

formacoes que continham basicamente textos. Basicamente os Web Sites eram compostos

por arquivos HTML (Hypertext Markup Language) estaticos. A arquitetura usada era a

cliente-servidor, onde o cliente era o browser 2 do usuario e o servidor eram os computa-

dores onde os arquivos HTML estavam armazenados.

Com a popularizacao da internet, as aplicacoes Web desenvolveram, surgindo soft-

wares para comercio eletronico, divulgacao de informacoes, entretenimento, trabalho, etc

[Offutt, 2002]. Com este desenvolvimento, surgiram varios sistemas complexos utilizados

em areas crıticas, surgindo assim, a necessidade de haver metodologias e ferramentas para

o teste de aplicacoes Web. Um agravante no teste de software web, e que as aplicacoes

Web atuais sao dinamicas e heterogeneas. Este agravante pode gerar novos desafios para

o desenvolvimento de software e para a atividade de teste [Offutt e Wu, 2002], tais com:

• O controle de execucao e alterado diretamente pelo usuario. Ao pressionar um deter-

minado botao, ele pode modificar totalmente o contexto de execucao do programa.

• Os componentes de hardware e software sao heterogeneos e devem ser integrados

dinamicamente. Em aplicacoes tradicionais certos atributos como compatibilidade

e interoperabilidade nao sao tao exigidas como nas aplicacoes Web.

• As tecnologias estao evoluıdo e sendo modificadas constantemente, requerendo mo-

dificacoes e evolucao constante nos metodos e ferramentas de testes.

• Os requisitos do sistema sao alterados rapidamente, surgindo a necessidade de di-

minuicao do tempo de desenvolvimento e manutencao.

• A equipe de desenvolvimento deve ser formada por pessoal com habilidades e conhe-

cimento diversos.

3.3.1 Teste Estrutural nas Aplicacoes Web

Neste tipo de teste, modelos sao propostos para manifestar defeitos associados a in-

formacao manipulada pela aplicacao ao comportamento de navegacao e aos estados de-

pendentes da interacao de objetos na aplicacao Web. Os elementos da aplicacao Web

sao capturados considerando modelos de: objeto, de fluxo de controle e de dados e de

comportamento. Estes elementos da aplicacao Web de acordo com [Liu et al., 1990] sao:

2Chamado tambem de Web browser, o browser e um programa (navegador) que permite seus usuarios

navegar atraves de documentos virtuais dispostos na Internet. O Mozilla Firefox, Internet Explorer,

Safari, Opera e Google Chrome sao os principais browsers encontrados no mercado [Wikipedia, 2008b].

24

• Pagina do cliente: documento HTML ou XML (eXtensible Markup Language)

com scripts embutidos, no qual sao visualizados pelo navegador Web do cliente;

• Pagina servidora: scripts como CGI3, PHP, ASP4 executado pelo servidor Web

no lado servidor;

• Componente: e qualquer modulo de programa que interaja com uma pagina

cliente, com uma pagina servidora ou com outro componente. Exemplo, um web

template5 HTML.

No modelo de objetos, fluxo de controle e o fluxo de dados, os elementos da aplicacao

Web sao considerados objetos compostos de atributos como os documentos HTML ou

XML e por operacoes como as funcoes que sao implementadas por uma linguagem de

programacao.

No modelo de comportamento da aplicacaoWeb, deseja-se capturar dois aspectos: a

navegacao entre paginas e dependencias de estado na interacao entre objetos.

Utilizando o diagrama de navegacao de paginas (Page Navigation Diagram - PND)

[Liu et al., 1990] e possıvel representar o comportamento de navegacao de paginasWeb.

A pagina visualizada depende da satisfacao da condicao especificada. A Figura 3.3 exem-

plifica um diagrama de navegacao por paginas.

Na Figura 3.3 o usuario esta navegando por um site de compras. Ao deparar com

um produto, o usuario resolve compra-lo. Quando solicita a funcao comprar produto,

o sistema lhe redireciona para a pagina entrar.jspx que dara inıcio ao processo para

concluir sua compra. Caso o usuario nao possua nenhuma conta cadastrada, o sistema lhe

redireciona para a pagina nova conta.jspx para cadastramento de uma nova conta. Criado

seu nome de usuario e senha, o sistema lhe encaminha para a pagina detalhes da conta.jspx

onde o sistema ira solicitar o preenchimento de alguns dados que indicara as preferencias

do usuario. De posse agora dos dados cadastrados, novamente quando o usuario tentar

entrar no sistema, a pagina entrar.jspx sera acionada. Com os dados aceitos, o usuario sera

encaminhado a pagina pedidos.jspx para conclusao do seu pedido. Caso o usuario entre

com os dados incorretos, o mesmo sera redirecionado para a pagina erro.jspx que exibira

3CGI e o acronico da expressao inglesa Common Gateway Interface e consiste em uma tecnologida

que permite gerar paginas dinamicas, possibilitando assim, que o navegador possa passar parametros de

uma pagina para a outra [Wikipedia, 2008c]4ASP e o acronico de Active Server Page e consiste numa estrutura de programacao em Script que

utiliza VBScript, JScript, PerlScript ou Python no lado do servidor para criar conteudos dinamicos

[Wikipedia, 2008a].5Web Template pode ser traduzido como Modelos de Paginas Web. Sao modelos que definem o layout

de uma pagina, preocupando-se apenas com a aparencia e onde sera disposto o texto na pagina, mas nao

o seu conteudo [Wikipedia, 2008h].

25

Figura 3.3: Diagrama de Navegacao de Paginas.

uma aviso que os dados estao incorretos. Conforme pode ser visto, o PND representa a

satisfacao da condicao especificada.

3.3.2 Teste Funcional para Aplicacoes Web

Para entender qualquer tipo de sistema, de modo geral, e utilizado modelos para

auxiliar na compreensao. [Ricca e Tonella, 2002] descrevem uma aplicacao Web generica

por meio de um metamodelo UML que e instanciado para representar uma determinada

aplicacao Web. Este metamodelo generico e apresentado na Figura 3.4, e e composto das

seguintes classes:

• Pagina Web: nela estao contidas informacoes visuais para o usuario, ligacoes para

outras paginas (links), formularios e frames ;

• Pagina Estatica: pagina Web que consta conteudo fixo;

• Pagina Dinamica: pagina Web que consta um conteudo que pode ser alterado,

em virtude da entrada de dados pelo usuario;

• Frame: regiao na pagina Web, cuja navegacao pode ser independente;

• Pagina no Frame : ao ser ativado um link, pode ser carregado uma pagina diferente

no frame;

26

Figura 3.4: Metamodelo para uma aplicacao Web.

• Formulario: e um conjunto de variaveis de entrada, fornecidas pelo usuario para

gerar uma pagina dinamica;

• Ramo Condicional: condicao que provoca alteracao na pagina Web quando sa-

tisfeita, a partir de valores de entrada.

[Ricca e Tonella, 2002] apresentaram duas abordagens de teste. Um deles e o modelo

estatico, no qual analisa caminhos de navegacao ou fluxo de informacoes fornecidas pelo

usuario. O outro e o modelo dinamico, no qual avalia a aplicacao Web por meio da

execucao de casos de teste.

No modelo de teste estatico, consegue-se encontrar defeitos relacionados a:

• Paginas inalcancaveis: paginas contidas no servidor, mas que nao podem ser

alcancadas a partir da pagina inicial;

• Paginas fantasmas: paginas associadas a ligacoes pendentes, ou seja, que indicam

paginas que nao existem;

• Frames alcancados: frames nos quais paginas podem ser carregadas;

• Paginas Cruzadas: estas paginas somente sao encontradas se for percorrendo

outras paginas, conhecidas como dominadoras. Estas paginas sao obrigatoriamente

percorridas pois possuem informacoes importantes a navegacao;

• Caminho mais curto: determina o caminho mınimo de paginas a serem percorri-

das para alcancar a pagina desejada;

27

• Dependencia de dado: uma variavel e utilizada em um formulario. Quando esta

variavel e propagada e encontra outro formulario que utiliza a mesma variavel, pode

acontecer dela nao ter sido definida ou ser utilizada de forma incorreta.

No teste dinamico, e possıvel a identificacao de defeitos relacionados aos fluxos de

controle e de dados entre as paginas da aplicacao Web. O caso de teste neste caso,

constitui-se de uma sequencia de paginas da aplicacao associadas ao dados de entrada.

Alguns criterios de teste estrutural aplicados a programas tradicionais sao estendidos

para teste de aplicacao Web e empregados nos testes dinamicos. [Ricca e Tonella, 2002]

propoem os seguintes criterios:

• Teste de Pagina (Page testing): cada pagina deve ser visitada pelo menos uma

vez em algum caso de teste;

• Teste de Ligacao (hyperlink testing): cada ligacao de cada pagina da aplicacao

deve ser percorrida pelo menos uma vez;

• Teste de Definicao-Uso (definition-use testing): todos os caminhos da navegacao

que exercitam uma associacao de uso deve ser exercitadas;

• Teste de todos os Usos (all-uses testing): pelo menos um caminho de navegacao

que exercita cada associacao definicao-uso deve ser exercitado;

• Teste de Todos-Caminhos (all-paths testing): cada caminho na aplicacao deve

ser percorrido pelo menos uma vez em algum caso de teste.

Os criterios teste de Definicao-Uso e Teste de todos-Caminhos nem sempre sao aplicaveis,

pois podem requerer um numero excessivo de elementos o que torna seu custo excessivo.

A seguir e apresentado as principais linguagens de modelagem de especificacao utiliza-

das neste trabalho para o teste funcional. Serao apresentados as linguagens semi-formais

da UML e o formalismo das Redes de Petri.

3.4 A notacao UML

Na decada de 90, desenvolveram-se os metodos e notacoes para modelagem segundo

a abordagem orientada a objetos. Em virtude desta proliferacao, houve a necessidade da

existencia de uma linguagem que viesse tornar-se uma norma, que fosse aceita e utilizada

seja por industria, entidades academicas e outros.

Buscando esta linguagem, alguns esforcos foram feitos neste sentido de normatizar, sur-

gindo em 1996 a UML (Unified Modeling Language), posicionando como uma linguagem

28

unificadora de notacoes, diagramas e formas de representacoes existentes em diferentes

metodos. Seus idealizadores foram Grady Booch, James Rumbaugh e Ivar Jacobson.

A UML buscou tornar-se a linguagem de modelagem padrao, sendo independente

da linguagem de programacao escolhida, bem como dos processos de desenvolvimento.

O objetivo da UML e que, dependendo do tipo de projeto, da ferramenta de suporte,

ou da organizacao envolvida, devem ser adotados diferentes processos ou metodologias,

mantendo-se a utilizacao da mesma linguagem de modelacao.

Ao se criar a UML, buscou-se a como princıpio basico a simplicidade. Outro princıpio

foi a coerencia na unificacao dos diferentes modelos ja existentes, como o de Booch

[Booch, 1994], OMT (Object Modeling Technique) [Rumbaugh e Premerlanoi, 1991] e o

OOSE (Object-Oriented Software Engineering) [JACOBSON et al., 1992]. Quando nen-

hum destes modelos oferece um elemento extremamente necessario que fora descoberto,

este novo elemento e criado caso ele seja indispensavel.

A UML e uma linguagem semi-formal, ou seja, nao consegue representar formalmente

o fluxo de dados e de controle do sistema. Devido ela ser semi-formal, nao e possıvel gerar

um modelo matematico que seja capaz de verificar ela completamente.

A UML e uma linguagem de modelagem grafica (visual), orientada a objetos que pode

ser empregada em varias fases de desenvolvimento de um software. E composta de dois

tipos de diagramas: diagramas estaticos e diagramas dinamicos. Os diagramas estaticos

compreendem a relacao do sistema com os dados. Os diagramas que se enquadram nessa

descricao sao: Diagramas de Classes, de Objetos, de Componentes e de Implantacao.

Ja os diagramas dinamicos referem-se a parte de controle do sistema como o envio de

mensagens e ordens de ativacao. Os diagramas dessa categoria sao: Diagramas de Casos

de Uso, de Sequencia, de Colaboracao, de Atividades e de Estado-Transicao.

A seguir, sao apresentadas as descricoes de alguns diagramas abordados neste trabalho.

3.4.1 Diagrama de Caso de Uso

Este tipo de diagrama e usado para identificar o comportamento do sistema em si-

tuacoes no qual e solicitada alguma acao. Segundo Ivar Jacobson, pode-se dizer que um

Caso de Uso e um “documento narrativo que descreve a sequencia de eventos de um ator

que usa um sistema para completar um processo”. Os componentes deste diagrama sao:

“atores”e o “caso de uso”. Veja na Figura 3.5.

O papel do ator e representar qualquer entidade que interage com o sistema, tendo

algumas caracterısticas:

• O ator nao e parte do sistema, mas sim, representa papeis que o usuario pode

desempenhar.

29

Figura 3.5: Ator e Caso de Uso.

• O ator pode interagir ativamente como receber informacoes do sistema.

• Ele pode representar um usuario, uma maquina ou entao outro sistema.

Ja o caso de uso, Figura 3.6, e uma sequencia de acoes que o sistema pode executar,

acionado geralmente por um ator e produz um resultado que contribui para os objetivos

do sistema. Algumas de suas caracterısticas sao:

• Um caso de uso pode ser iniciado por um ator para realizar uma operacao, ou entao

por outro caso de uso.

• Ele gera um dialogo entre o ator e o sistema, ou mesmo entre casos de uso.

• Todos os casos de usos juntos representam todas as situacoes possıveis de utilizacao

no sistema.

Figura 3.6: Exemplo de Caso de Uso.

O diagrama de caso de uso e utilizado preferencialmente na fase de especificacao de

requisitos, tendo como funcao representar a sequencia de acoes que o usuario tem interesse

que o sistema realize.

30

3.4.2 Diagrama de Classe

Uma classe representa um conjunto de objetos que possuem comportamentos e carac-

terısticas comuns. As classes sao formadas por um retangulo dividido em tres partes, o

nome da classe, uma lista de atributos, que sao os dados que a classe possui e os metodos

que manipulam esses atributos.

Inicialmente chamado de Diagrama de Estrutura Estatica, mas mais conhecido como

Diagrama de Classes, este diagrama mostra a estrutura estatica do sistema e suas relacoes.

Na Figura 3.7 tem-se como ele e representado.

Figura 3.7: Diagrama de Classe.

3.4.3 Diagrama de Sequencia

O Diagrama de Sequencia e um tipo de diagrama de interacao definido pela UML. Este

tipo de diagrama descreve em ordem as mensagens que sao enviadas entre os objetos. Por

meio de dois eixos e feito a representacao. No eixo vertical encontra a linha de tempo,

enquanto na horizontal sao mostrados os objetos que participam de uma sequencia de

uma atividade.

Os componentes da notacao da Figura 3.8 sao os seguintes [CABRAL, 1999]:

• Os objetos sao representados por retangulo com seus nomes sublinhados;

• O tempo de vida dos objetos e representado por linhas verticais tracejadas;

• As interacoes entre objetos sao indicadas por flechas horizontais direcionadas, na

linha vertical, partindo do objeto cliente ao objeto servidor;

• As flechas horizontais sao rotuladas com mensagens;

• A ordem das mensagens e indicada com a primeira mensagem aparecendo no topo.

A numeracao das mensagens e opcional e baseada na posicao vertical.

31

Figura 3.8: Diagrama de Sequencia.

3.4.4 Diagrama de Atividade

Os Diagramas de Atividades descrevem os passos a serem percorridos para a conclusao

de uma operacao ou processo especıfico, muitas vezes representada por um metodo com

certo grau de complexidade, e podem, tambem, modelar um processo completo.

Neste diagrama, sao capturados as acoes e seus resultados. Foca-se no resultado das

mudancas de estado dos objetos. A Figura 3.9, exemplifica o Diagrama de Atividade de

um usuario executando a operacao de comprar um livro.

3.5 Redes de Petri

As Redes de Petri (RdP) foram inicialmente postuladas por Carl Adam Petri em

Comunicacao com Automatos. A partir deste trabalho, foram desenvolvidas as teorias

das Redes de Petri que constituem formalmente, uma ferramenta grafica e matematica

para modelagem de diversos tipos de sistemas voltados para a analise e controle de sis-

temas e eventos discretos, suportando atividades paralelas, concorrentes e assıncronas.

A definicao completa das Redes de Petri podem ser vistas em [Cardoso. et al., 1999],

[Alla e David, 1988], [Murata, 1989], [Peterson, 1981], [Petri, 1966].

As RdP e uma notacao formal pois atraves dela e possıvel gerar um modelo matematico

que seja capaz de representar matematicamente o que ela representa.

De maneira simplificada, uma Rede de Petri como mostrada na Figura 3.10, e apre-

sentada como um grafo orientado contendo os seguintes elementos:

32

Figura 3.9: Diagrama de Atividade

• Lugar: representa um estado, uma espera, um recurso etc;

• Ficha: indica uma condicao associada ao lugar, ou um objeto;

• Transicao: representam as acoes ou eventos que ocorrem em um sistema;

• Arcos orientados: conectam os lugares as transicoes e estas aos lugares.

Figura 3.10: Redes de Petri.

Definicao 1: Formalmente uma rede de Petri pode ser definida como uma quadrupla:

R =< P, T, Pre, Post >

Onde:

33

• P e um conjunto finito de lugares de dimensao n,

• T e um conjunto finito de transicoes de dimensao m,

• Pre : P X T → N e a aplicacao de entrada (lugares precedentes ou incidencia

anterior), com N sendo o conjunto dos numeros naturais,

• Post : P X T → N e a aplicacao de saıda (lugares seguintes ou incidencia posterior).

Para as redes de Petri marcadas a seguinte definicao e apresentada:

Definicao 2: Uma rede marcada N e uma dupla N =< R, M > onde:

• R e uma rede de Petri,

• M e a marcacao inicial dada pela aplicacao M : P → N.

Dessa forma M(p) e o conjunto de fichas contidas no lugar p. A marcacao M e a

distribuicao das fichas nos diversos lugares.

A grande diversidade de sistemas computacionais existentes apresentam caracterısticas

distintas que necessitam ser representadas de forma clara e sem ambiguidades. As redes

de Petri promovem a solucao destes problemas propondo a sua extensao. De um modo

geral as redes de Petri podem ser classificadas em: redes de baixo nıvel (Redes de Petri

ordinarias) e redes de alto nıvel.

As redes de Petri de baixo nıvel sao caracterizadas pelo tipo de marcacao que possuem.

As marcas (fichas) que se encontram nos lugares da rede nao possuem significado, indicam

apenas o seu estado.

As redes de Petri de alto nıvel, alem de representarem o seu estado, conseguem tambem

carregar informacoes. Nesta classe de rede, as marcas nao sao identicas entre si e contem

informacoes e dados relacionados a sua caracterizacao. Alguns tipos de rede de alto nıvel

sao apresentados a seguir:

• Redes de Petri Coloridas: nas fichas dessas redes sao atribuıdas cores no in-

tuito de diferenciar umas das outras o que permite representar diferentes processos

e recursos [Alla e David, 1988], [Jensen, 1990]. Em [Moncelet, 1998], um modelo

de rede de Petri colorida foi proposto para modelagem de sistemas de producao

hıbridos.

• Redes de Petri Predicado/Transicao: descreve de maneira estruturada o conjunto

controle e dados [Cardoso. et al., 1999], [Genrich, 1987]. Nestas redes, os lugares

sao chamados de predicados, as marcas sao condicoes validas do predicado e as

transicoes sao consideradas como regras da logica de primeira ordem, isto e, regras

34

com variaveis. Em [Champagnat, 1987] as redes de Petri predicado/transicao sao

abordadas para serem integradas a uma sequencia de equacoes algebro-diferenciais

para a modelagem de estocagem de gas.

• Redes de Petri Temporais/Temporizadas: sao usados na modelagem de sis-

temas que levam em consideracao o fator tempo. Sua principal aplicacao e nas si-

mulacoes, no diagnostico, na supervisao e na analise de desempenho. Nestas redes,

o tempo e representado por duracoes associadas ao lugar (p-temporizadas) ou a

transicao (t-temporizadas) [Sifakis, 1977], [Tazza, 1987], [Ramchandani, 1974].

• Redes de Petri Estocasticas: e incluıdo um tempo aleatorio associado ao disparo

de uma transicao [Ramchandani, 1974]. Incertezas nos instantes de execucao de

eventos do sistema sao consideradas, associando-se funcoes de probabilidade para

a determinacao de sua execucao. Estas redes podem ser aplicadas em sistemas

cujos eventos nao sao bem definidos, como por exemplo, o tempo de falha de uma

maquina e o de outra. A definicao do tempo nestas redes e definida atraves de uma

distribuicao que segue uma lei exponencial permitindo atribuir a rede um processo

Markoviano equivalente.

• Redes de Petri Hıbridas e Redes de Petri Contınuas: em uma rede de Petri

contınua, a marcacao de um lugar e o disparo de uma transicao correspondem a

uma variavel contınua (numero real nao negativo). A marcacao contınua e movida

de um lugar para outro determinado por uma velocidade [Alla e David, 1988].

• Rede de Petri a Objetos: pode ser considerada como uma extensao das Redes de

Petri Predicado/Transicao que aborda o conceito de paradigma orientado a objetos

[Sibertin-Blanc, 1985]. A principal motivacao do uso das Redes de Petri a Objetos se

deve principalmente pela capacidade de representar caracterısticas de concorrencia,

paralelismo, o fluxo de controle e a estrutura de dados apresentados em sistemas.

A Rede de Petri a Objeto e detalhada na proxima secao.

Redes de Petri a Objetos

Antes de definir as Redes de Petri a Objetos, e importante considerar as principais

caracterısticas do conceito de orientacao a objetos.

No paradigma orientado a objeto, o conceito de objeto visa estruturar uma aplicacao

em torno de entidades, encapsulando estruturas de dados sob a forma de uma lista de

atributos e metodos.

Atributos e metodos compoem uma classe de objetos a partir da qual podem ser

derivadas subclasses por meio da heranca o que torna possıvel herdar atributos e metodos

de classes ja definidas.

35

Entretanto, objetos sao caracterizados pela instanciacao de uma classe, sendo esta

portanto, apenas uma definicao. Aos atributos dos objetos sao atribuıdos valores que sao

manipulados e executados por operacoes (metodos).

Tambem sao importantes outros elementos que compoem o paradigma orientado a

objetos, como os conceitos de encapsulamento, abstracao, polimorfismo, modularidade e

persistencia.

O encapsulamento confere aos objetos certa independencia funcional e protecao contra

acessos nao autorizados.

A abstracao por sua vez, enfatiza detalhes significantes e suprime outros em um dado

momento.

O conceito de polimorfismo refere-se ao fato de que uma mesma mensagem pode

resultar em eventos diferentes quando recebida por objetos diferentes ou quando enviada

com parametros diferentes.

A modularidade consiste em dividir um programa em partes como funcoes individuais

a fim de reduzir a complexidade do codigo. Idealmente, um software deve apresentar alta

coesao e baixo acoplamento. A coesao confere independencia funcional ao software, ja o

acoplamento diz respeito a interconexao entre os modulos para a execucao de tarefas.

Por ultimo, a persistencia e a propriedade que um objeto tem de existir no tempo

(continuar a existir, mesmo apos o seu criador nao mais existir) e/ou no espaco.

As Redes de Petri a Objetos [Sibertin-Blanc, 1985] baseiam-se na integracao das Redes

de Petri Predicado/Transicao e do conceito de paradigma orientado a objetos. Neste

tipo de rede, as fichas sao consideradas como instancias de n-uplas de classes de obje-

tos e transportam verdadeiras estruturas de dados definidas como conjuntos de atribu-

tos de classes especıficas. As transicoes, por sua vez, tem associadas pre-condicoes e

acoes, que respectivamente, atuam sobre os atributos das fichas e modificam seus valores

[Cardoso. et al., 1999].

Em uma Rede de Petri a Objetos, os lugares correspondem aos objetos das classes com

seus atributos definidos, as transicoes tem a elas associadas as operacoes e pre-condicoes

que atuam sobre os atributos localizados nos lugares de entrada. Dessa forma, a operacao

de uma determinada transicao t so podera ser executada por um objeto se este estiver

num lugar de entrada de t [Cardoso. et al., 1999]. As Redes de Petri a Objetos podem

ser definidas formalmente como:

Definicao 3: Uma rede de Petri a objetos marcada pode ser definida pela 9-upla:

N0 =< P, T, Class, V, Pre, Post, Atc, Atr, M0 >

Onde:

36

• Class representa um conjunto finito de classes de objetos: para cada classe e definido

tambem, um conjunto de atributos;

• P e um conjunto finito de lugares, cujos tipos sao dadas por Class;

• T e um conjunto finito de transicoes;

• V e um conjunto de variaveis, cujos tipos sao dados por Class;

• Pre e a funcao lugar precedente, que a cada arco de entrada de uma transicao, faz

corresponder uma soma formal de n-uplas de elementos de V ;

• Post e a funcao lugar seguinte, que a cada arco de saıda de uma transicao faz

corresponder uma soma formal de n-uplas de elementos de V ;

• Atc e uma aplicacao, que a cada transicao associa uma condicao que envolve os

atributos das variaveis formais associados aos arcos de entrada;

• Atr e uma aplicacao, que a cada transicao associa uma acao que envolve os atributos

das variaveis formais associadas aos arcos de entrada;

• M0 e a marcacao inicial, que associa a cada lugar uma soma formal de objetos

(n-uplas de instancias de classes que pertencem a Class).

Um exemplo de rede de Petri a objetos e a representada na Figura 3.11. O conjunto

de classes e definida como:

Class = {Produto, Pedido}

A classe Produto possui os atributos:nome = identificador;

codigo = integer;

preco = float;

E a classe Pedido tem os seguintes atributos:codigo : integer;

custo : float;

tipo : identificador;

A variavel pr e do tipo Produto e a variavel pd e do tipo Pedido. O lugar Estoque

de Produtos e do tipo Produto, o lugar Buffer de Pedidos e do tipo Pedido e o lugar

Pedidos Processados e do tipo Pedido.

37

Figura 3.11: Modelo de Especificacao para Venda de Produtos.

As funcoes Pre e Post assim como as aplicacoes Atc e Ata aparecem diretamente no

grafo da Figura 3.11. A marcacao inicial M0 e dada pelos objetos que se encontram nos

lugares.

M0 =

< pr1 > + < pr2 > + < pr3 >,

< pd1 > + < pd2 >,

0

Nos lugares Estoque de Produto e Buffer de Pedidos, os objetos (fichas) possuem

valores de atributos. Por exemplo, para o objeto pr1, os valores de atributos podem ser

dados por:

Produto pr1;

nome : home theater;

codigo : 123440;

preco : 278, 50;

E para o objeto pd1, valores dos atributos podem ser dados por:

Pedido pd1;

codigo : 123440;

custo : 278, 50;

tipo : hometeather;

A definicao detalhada que fixa as regras de sensibilizacao e disparo das transicoes das

RdPO encontram-se em [Sibertin-Blanc, 1985].

Basicamente, uma transicao t e sensibilizada se ela contem lugares de entrada em

comum para que as variaveis da funcao de incidencia Pre gerem diferentes entidades

(objetos). Entretanto, e necessario que seja satisfeita a pre-condicao da transicao. Assim,

38

a transicao removera as entidades dos lugares de entrada em comum e alterara os valores

de acordo com a acao existente na transicao e, em seguida, enviara a entidade com valores

atualizados ao lugar de saıda correspondente.

Com base na Figura 3.11, seja M = (Me, Md), a marcacao da rede em que Me refere-

se ao conjunto de objetos de um lugar e Md o numero de marcacoes de cada lugar e

t a transicao. Uma transicao t e sensibilizada a partir de M se existe uma funcao de

substituicao S tal que [Sibertin-Blanc, 1985]:

S(Pre(t, p)) ≤Md(p),

Dessa forma, substituindo pelos valores da rede da Figura 3.11 tem-se:

S(Pre(pr, Estoque de Produtos))≤ Md(Estoque de Produtos),

em que Estoque de Produtos corresponde aos objetos (< pr1 > + < pr2 > + <

pr3 >) e para o lugar Buffer de Pedidos tem-se:

S(Pre(pd, Buffer de Pedidos))≤ Md(Buffer de Pedidos), em que Buffer de Pedidos

corresponde aos objetos (< pd1 > + < pd2 >).

A sensibilizacao das transicoes e uma condicao algebrica nao relacionada as estruturas

de dados, que nao podem contabilizar valores dos objetos, ficando isto a cargo das pre-

condicoes. Uma pre-condicao e uma expressao booleana em que as variaveis possuem

valores em comum do mesmo tipo. Para o exemplo da Figura 3.11 tem se que:

if(pr.nome == pd.tipo),

que correspondem a atributos com os mesmos valores e tipos de dados.

Pode-se notar, que na Figura 3.11, a transicao t e sensibilizada pela marcacao inicial.

De fato, os valores dos atributos da variavel pr associada ao arco que liga o lugar Estoque

de Produtos a transicao t podem ser substituıdos pelos valores de atributos de um dos

objetos que se encontram em Estoque de Produtos. Da mesma forma, os valores dos

atributos da variavel pd associada ao arco que liga o lugar Buffer de Pedidos a transicao

t podem ser substituıdos pelos valores de atributos de um dos objetos que se encontram

em Buffer de Pedidos.

Suponha-se que o par de objetos (pr1, pd2) verifica a condicao associada a transicao

t. Entao, a transicao pode ser disparada. No momento do disparo, o atributo custo do

objeto pd2 sera atualizado de acordo com a acao associada a transicao e, no final do

disparo, um novo objeto pd2 se encontrara no lugar Pedidos Processados com o valor do

atributo custo atualizado.

Para os valores de atributos definidos em pr1 e pd1, a execucao da rede e dada pelo

disparo da transicao t:

• Considere a marcacao inicial (os objetos pr1, pr2 e pr3 no lugar Estoque de Produtos

e pd1 e pd2 no lugar Buffer de Pedidos). Considere que os atributos dos objetos

39

pr1 e pd2 sejam armazenados respectivamente, aos atributos das variaveis de arco

pr e pd que, em seguida, sensibilizam a transicao t. Inicialmente, a pre-condicao

associada a transicao t deve ser satisfeita para que a transicao t seja executada.

A pre-condicao (if(pr.nome == pd.tipo)) verifica se os atributos nome da variavel

pr e tipo da variavel pd possui os mesmos valores. Como a condicao e satisfeita,

a transicao t e acionada, registrando-se valor do atributo preco da variavel pr no

atributo custo da variavel pd. Apos o disparo da transicao t, um novo objeto pd com

o valor do atributo custo modificado e produzido no lugar Pedidos Processados.

40

Capıtulo 4

Modelo de Especificacao de Teste

Funcional

Dando continuidade, neste capıtulo sera abordado o modelo de especificacao de teste

funcional do sistema. Nele sera exposto a especificacao formal da funcionalidade Cadas-

trar Usuario do sistema de ensino a distancia. Depois sera contemplado o modelo de

implementacao, posteriormente o modelo de execucao do teste.

4.1 Aplicacao do Teste Funcional

O teste funcional ou teste de “caixa-preta”tem como papel principal testar especi-

ficacoes de requisitos de um software a fim de garantir que as funcoes do mesmo estejam

corretas [Delamaro et al, 2007], [Beizer, 1990].

Para analisar a aplicabilidade do teste funcional, pode-se considerar a estrutura do

modelo de desenvolvimento em V da Figura 4.1. Neste modelo, para cada etapa do

desenvolvimento do software (parte esquerda do V), um conjunto de testes devem ser

planejados (parte central do V). E nas etapas finais do modelo (parte direita do V), que

as diversas atividades de teste serao realizadas, utilizando-se como dados de entrada os

casos de teste elaborados durante as etapas de desenvolvimento na parte central do V.

Os testes funcionais se concentram mais nas camadas do V que correspondem as etapas

de especificacao de requisitos e sao denominados geralmente como Testes de Aceitacao. E

fato que, atraves destes testes, as funcoes do software serao validadas, tornando-o pronto

para ser entregue e/ou distribuıdo aos clientes.

De acordo com a Figura 4.1, o lado esquerdo do V corresponde a fase de Especificacao

de requisitos, oferece apenas informacoes a respeito das funcionalidades que o software

deve desempenhar e nao considera aspectos relacionados a arquitetura ou codificacao.

A parte central do V correspondem as etapas de planejamento de testes de cada fase do

desenvolvimento. A etapa de Teste de Aceitacao valida os requisitos do software. Antes

41

Figura 4.1: Modelo de Desenvolvimento em V.

da parte direita do V ser conhecida, tem-se acesso apenas a caracterısticas funcionais,

que referem-se a funcoes que devem compor o software fornecidas pela parte esquerda do

V. No lado direito do V, o software ja se encontra no final da fase de desenvolvimento,

portanto, a arquitetura do software ja e conhecida, fornecendo um maior nıvel de detalhes

a serem considerados.

4.2 Modelo de Especificacao de Teste Funcional para

Aplicacoes Web

A execucao de um modelo de teste de um sistema web pode ser visto como a execucao

de um caso de teste. O modelo de especificacao do teste funcional para sistemas web

devera possuir caracterısticas proprias a execucao de um caso de teste. Em particular, ele

devera permitir a especificacao das estruturas de dados e ser um modelo suficientemente

formal para ilustrar as caracterısticas principais do modelo de especificacao de teste assim

definido.

O modelo de especificacao do teste funcional para sistemas web e definido por uma

Rede de Petri a Objeto [Sibertin-Blanc, 1985] tal que a Rede de Petri Ordinaria a partir

da qual define-se a estrutura de controle do modelo de teste seja dada por um Rede de

Petri Ordinaria [Aalst, 2003]. Neste caso, a Rede de Petri a Objeto correspondente pode

ser definida pela 9-upla:

N0 =< P, T, Class, V, Pre, Post, Atc, Atr, M0 >

Onde seguindo a linha de definicao da RdP Ordinaria visto no capıtulo anterior, pode-

se definir um modelo de teste a seguir:

42

• Class representa a classe de teste que e definida por um conjunto de atributos de

tres tipos:

– atributos que representam dados de entrada do teste;

– atributos que representam dados de saıda do teste;

– atributos que representam dados utilizados para caracterizar o roteiro seguido

pelo caso de teste no Rede de Petri Ordinaria subjacente.

• P e um conjunto finito de lugares (lugares de entrada Start (Inıcio), lugar de saıda

End (Fim) e lugares envolvidos nos diversos roteiros da RdP Ordinaria) cujos tipos

sao dados por Class;

• T e um conjunto finito de transicoes;

• V e um conjunto de variaveis, cujos tipos sao dados por Class;

• Pre e a funcao lugar precedente que a cada arco de entrada de uma transicao, faz

corresponder uma soma formal de n-uplas de elementos de V ;

• Post e a funcao lugar seguinte que a cada arco de saıda de uma transicao faz

corresponder uma soma formal de n-uplas de elementos de V ;

• Atc e uma aplicacao que a cada transicao associa uma condicao que envolve os

atributos das variaveis formais associados aos arcos de entrada;

• Atr e uma aplicacao que a cada transicao associa uma acao/operacao em forma de

chamada de metodos de um objeto que envolve os atributos das variaveis formais

associadas aos arcos de entrada e cujo valor de retorno da chamada (quando existir)

e repassado a valores de atributos de variaveis formais associadas aos arcos de saıda;

• M0 e a marcacao inicial que associa ao lugar de inıcio Start um objeto de teste,

instanciado de Class uma soma formal de objetos (n-uplas de instancias de classes

que pertencem a Class).

Para ilustrar as caracterısticas principais do modelo de especificacao de teste definido,

e considerado a seguir a especificacao da funcionalidade Cadastrar Usuario de um sistema

usado em Ensino a Distancia.

Modelo de Especificacao da Funcionalidade Cadastrar Usuario de um sis-

tema de Ensino a Distancia

43

A aplicacao do teste funcional ocorrera principalmente na interface do sistema desen-

volvido ja que as funcoes que serao avaliadas sao essencialmente aquelas executadas pelos

proprios usuarios na interface do sistema como e mostrado na Figura 4.2.

Figura 4.2: Interacao entre o Usuario e o Sistema por meio da Interface.

A interface do sistema de Ensino a Distancia e exemplificada na Figura 4.3 com as

principais funcionalidades que podem ser acessadas pelos usuarios: Cadastrar Usuario,

Criar Topico, Enviar Mensagem, Cadastrar Material Didatico, Pesquisar Palavra, etc.

A especificacao textual da funcao Cadastrar Usuario de um sistema de Ensino a

Distancia pode ser a seguinte:

Inicialmente o usuario ira digitar no browser o endereco onde encontra-se hospedado

o sistema de Ensino a Distancia. Ao carregar a pagina, tem-se a tela inicial do sistema.

O usuario devera entrar com seu Nome de Usuario e sua Senha, posteriormente apertar o

botao Entrar. Caso estes dados inseridos sejam aceitos pelo banco de dados do sistema, o

usuario entra em uma tela de selecao de Cursos Matriculados. Caso contrario, o sistema

notifica ao usuario que seu Nome de Usuario ou Senha sao invalidos, retornando-o para

a tela inicial do sistema.

Ao selecionar o curso desejado, o sistema ira carregar todas informacoes contidas no

banco de dados referente a ele. No menu, o usuario ira clicar em Manutencao de Usuario

posteriormente em Cadastrar Usuario. Ao realizar estes passos, aparecera uma tela onde

devera ser preenchido os campos: Nome do Usuario, Senha, E-mail, Telefone, Cidade,

Estado e Grupo de Usuarios. Caso os campos sejam preenchidos e as restricoes superadas,

o sistema faz o cadastro do novo usuario.

E claro que tal especificacao nao define formalmente o que se espera dos requisitos

da funcao Cadastrar Usuario. Sera entao necessario apos a leitura de uma especificacao

textual usar na medida do possıvel, um modelo formal, que permite a visualizacao dos

requisitos da funcao a ser implementada e testada.

A Rede de Petri Ordinaria da Figura 4.4 apresenta a estrutura de controle da funcio-

nalidade a ser testada. E fornecida uma especificacao possıvel para a funcao Cadastrar

Usuario. Neste modelo, convencionalmente foi definido um roteiro, como segue abaixo,

para as operacoes (transicoes):

44

Figura 4.3: Interface do Sistema de Ensino a Distancia.

• v usuario e senha: verifica o nome de usuario e a senha correspondente;

• v curso matriculado: verifica se este usuario esta matriculado em algum curso;

• v dados inseridos : verifica se os dados inseridos para cadastrar um novo usuario

estao corretos;

• efetua cadastro: de posse dos dados corretos, e efetuado o cadastro do novo usuario;

• exibe conclusao: envia a tela uma confirmacao do cadastramento do novo usuario;

Este roteiro e executado sequencialmente, apos os disparos, alem disso, roteiros alter-

nativos sao oferecidos, indicando a ocorrencia de falhas de algumas das operacoes como:

• e usuario e senha: indica que o nome de usuario ou a senha estao incorretos;

• e curso matriculado: caso o usuario nao esteja matriculado em nenhum curso;

45

• e dados inseridos : os dados inseridos estao incompletos ou incorretos.

A marcacao inicial da rede da Figura 4.4, corresponde a uma ficha (futuramente um

objeto de teste possuindo valores de atributos a serem manipulados) que se encontra

no lugar P1 (marcacao inicial do modelo de especificacao da funcionalidade Cadastrar

Usuario).

Figura 4.4: Rede de Petri Ordinaria: Representacao do Sistema de Cadastro de Usuario

por Redes de Petri Ordinaria.

Dessa forma, o modelo apresentado nao depende ainda de nenhuma arquitetura em

especıfico e pode ser gerado na etapa de Especificacao do modelo de desenvolvimento em

V.

Entretanto, quando a arquitetura e conhecida, tal modelo, e incrementado com o

nome dos objetos (fichas), os quais fornecerao diversos metodos, obtendo-se assim, um

novo modelo que seria utilizado na fase de “Teste de Aceitacao do modelo em V, como

mostrado na Figura 4.5.

Embora o roteiro utilizado neste trabalho para a execucao de cenarios de teste seja

o modelo sequencial apresentado na Figura 4.4, outros roteiros podem definidos para

o modelo. O primeiro roteiro e considerar um modelo de teste funcional iterativo, que

registra as tentativas do usuario para entrar com o nome do usuario e senha correta, como

pode ser observado na Figura 4.6. O modelo nao especifica o limite maximo de vezes que

o usuario pode entrar com nome do usuario e senha errada, mas sim, registra o numero

de vezes que ele entrou com nome do usuario e senha errada representado pelo atributo t

antes que o sistema finaliza a operacao Cadastrar Usuario, ilustrado na Figura 4.7, que

possui marcacao inicial situada em P1.

O segundo caso representa o paralelismo em que as operacoes de exibe conclusao,

efetua cadastro e v dados inseridos sao visualizadas na Figura 4.8.

As funcoes de verificar os dados inseridos (getVerificaDadosInseridos()), efetuar o

cadastro dos dados (getEfetuaCadastro()) e exibir o resultado da operacao (getExibe-

Conclusao()) estao sendo executadas todas em paralelo, como ilustrado na Figura 4.9.

Dessa forma e importante observar que apos o disparo da transicao t8, tres novos ob-

jetos (< us2 >, < us3 > e < us4 >) serao criados e manipulados durante a execucao

46

Figura 4.5: Rede de Petri a Objeto: Modelo de Especificacao de Teste Funcional do

Sistema de Ensino a Distancia para a Funcao Cadastrar Usuario.

das operacoes das transicoes t4, t5, t6 em paralelo, que em seguida sao conduzidas e ar-

mazenadas na transicao t9. Entretanto, o usuario nao pode entrar com nenhum dado

em paralelo e sim, em sequencia. Dessa forma, deve-se testar caracterısticas que ficam

transparentes ao usuario por exemplo, se os dados inseridos no formulario tem a tipagem

correta para inserir no banco de dados. Isso demonstra, que o modelo de teste funcional

nao simula simplesmente o comportamento do usuario, mas tambem outras caracterısticas

importantes, como o comportamento interno do sistema. Mas e importante ressaltar que

o modelo de teste simula o comportamento da funcionalidade de acordo com os dados que

o usuario fornecer ao sistema.

47

Figura 4.6: Rede de Petri Ordinaria: Representacao do sistema de Cadastro de Usuario

Iterativo por Redes de Petri Ordinarias.

4.3 Implementacao do Modelo de Especificacao do

Teste Funcional

A partir da RdP da Figura 4.4, pode-se gerar entao a RdP a Objeto da Figura 4.10

que representara o modelo de especificacao do teste da funcao Cadastrar Usuario.

Os atributos manipulados pelas variaveis que aparecerao nos arcos do modelo sao

aqueles que serao manipulados atraves da interface do usuario do sistema de Ensino a

Distancia mais alguns dados, necessarios a avaliacao do resultado do teste (por exemplo,

valores booleanos que poderao ser usados para registrar problemas durante a execucao do

insercao dos dados).

A Rede de Petri a Objeto da Figura 4.10 ilustra o metodo principal da classe de

teste. Os metodos chamados que aparecem nas transicoes do modelo sao aqueles que

sao chamados pela classe de teste durante a execucao da funcao Cadastrar Usuario. Tal

modelo ainda nao depende de uma arquitetura especıfica, sendo gerado dessa forma, a

partir da etapa de especificacao de requisitos do modelo de desenvolvimento em V.

Os parametros transmitidos no momento da chamada dos metodos serao valores de

atributos transportados pelas fichas da rede (na verdade objetos que representarao ins-

tanciacao da classe de teste especıfica). Os valores devolvidos pelos metodos chamados

serao, entao, repassados como valores de atributos especıficos transportados tambem pelas

fichas da rede.

Ja que o modelo de especificacao de teste apresentado na Figura 4.10 somente re-

presenta o metodo generico da classe de teste, e nao ainda a execucao explıcita de um

cenario de teste, e normal que nenhum objeto apareca no modelo (nao ha neste modelo

uma marcacao inicial que fixa valores de atributos necessarios a execucao do teste). E

somente durante a execucao de um cenario de teste especıfico que uma marcacao inicial

e criada.

Entretanto, quando a arquitetura e conhecida, o modelo da Figura 4.10 sera comple-

48

Figura 4.7: Rede de Petri a Objeto: Modelo de Especificacao de Teste Funcional do

Sistema de Ensino a Distancia para a Funcao Cadastrar Usuario

mentado com o nome dos objetos que fornecerao os diversos metodos como ilustrado na

Figura 4.11, fornecendo um modelo de teste utilizado na etapa Teste de Aceitacao do

Modelo em V.

A Rede de Petri a Objeto da Figura 4.10 ilustra o metodo principal da classe de

teste ClassedeTeste do Diagrama de Classes da Figura 4.12. Os metodos chamados que

aparecem nas transicoes do modelo sao aqueles que sao chamados pela classe de testes

durante a execucao da funcao Cadastrar Usuario. Em particular, eles pertencem as duas

classes: ManutencaoUsuario e ExibirSituacao que sao as principais classes da arquitetura

do sistema.

Dessa forma, a implementacao do modelo de especificacao do teste funcional que usa

as Redes de Petri a Objetos consiste, inicialmente, na geracao de uma classe de teste.

A Classe de Teste, a ser produzida de forma manual, se relacionara com a arquitetura

da funcao a ser testada. Assim, a classe de teste, que possuira valores de atributos ja

49

Figura 4.8: Rede de Petri Ordinaria: Representacao do Sistema de Ensino a Distancia

Paralelo por Redes de Petri Ordinarias.

definidos e metodos de teste, ira acessar os principais metodos da classe do sistema a ser

testado.

4.4 Execucao do Cenario de Teste

A marcacao inicial da rede e dada por um objeto de teste (ficha) o qual representa um

caso, sendo a instancia de uma classe e possui os valores de atributos a serem testados.

As variaveis de arco por sua vez, sao variaveis do mesmo tipo da classe que transportam

os valores de atributos do objeto a ser testado. A execucao do processo que e determinado

por metodos podem ser realizados mediante a avaliacao de pre-condicoes cujo resultado

deve ser verdadeiro para que uma transicao seja disparada. Ao final dos disparos, tem-

se uma marcacao final, que mostra o objeto de teste com todos os valores de atributos

atualizados, finalizando-se assim, o ciclo de vida do processo.

A medida em que as diversas etapas de desenvolvimento do software sao finalizadas, as

etapas de teste (lado direito do V) podem ser iniciadas. E evidente que na etapa Teste de

Aceitacao a arquitetura detalhada do software ja e conhecida. Para o sistema de Ensino a

Distancia, o Diagrama de Classes da Figura 4.11, pode ser considerado como um exemplo

de arquitetura simplificada onde sao apresentadas as principais classes do sistema.

No modelo de especificacao de teste da funcao Cadastrar Usuario, para simular exa-

tamente a interacao do usuario com o sistema de Ensino a Distancia, deve-se considerar

a arquitetura existente, descrever formalmente todas as atividades envolvidas durante

a execucao da funcionalidade e representar todos os dados envolvidos no momento da

operacao de cadastramento.

A verificacao automatica (sem intervencao humana) da arquitetura proposta, por

exemplo na Figura 4.12 permite a execucao correta da funcionalidade especificada pelos

principais modelos de requisitos. O modelo de especificacao de teste da funcao Cadastrar

Usuario devera ser implementado na forma de um metodo principal testaFuncao() de

uma classe de teste ClassedeTeste (que contem os principais atributos a serem testados)

50

Figura 4.9: Rede de Petri a Objeto: Modelo de Especificacao de Teste Funcional do

Sistema de Ensino a Distancia Paralelo.

que podera interagir diretamente (sem a intervencao de um usuario no sistema) com as

principais classes da arquitetura como e mostrado na Figura 4.12.

A execucao manual de um cenario por um usuario, que corresponde a um teste es-

pecıfico de uma funcionalidade de software, depende dos dados que sao passados ao soft-

ware atraves da interface do usuario. No caso do modelo de especificacao do teste que

representa o metodo principal de uma classe de teste, tais dados serao representados como

valores de atributos de uma ficha do modelo de especificacao.

Considere-se, por exemplo, um modelo de especificacao de um cenario de teste es-

pecıfico para a funcionalidade Cadastrar Usuario do Sistema de Ensino a Distancia

generico, da Figura 4.5, que pode ser conduzida por um objeto da classe ClassedeTeste,

cuja identificacao e representada por us1 com os valores de atributos seguintes:

51

Figura 4.10: Rede de Petri a Objeto: Modelo de Especificacao de teste Funcional do

Sistema de Ensino a Distancia para a Funcao Cadastrar Usuario.

52

Figura 4.11: Diagrama de Classes Envolvendo as Principais Classes do Sistema de Ensino

a Distancia Generico.

Figura 4.12: Diagrama de Classes Envolvendo as Principais Classes do Sistema de Ensino

a Distancia Generico e a Classe de Teste.

53

ClassedeTeste us1;

usuario senha : teste 1234;

nuser : 0;

cursomat : 1 2 3;

cur : 0;

dadosins : 0;

dins : 0;

efcadas : 0;

ecad : 0;

excon : 0;

econ : 0;

No inıcio do teste, tal objeto sera representado como uma ficha da RdP Ordinaria da

Figura 4.5 que se encontrara no lugar P1 (marcacao inicial do modelo de especificacao do

cenario de teste).

Para tais valores de atributos, a execucao do teste se dara atraves da sequencia de

disparos das transacoes seguintes, a partir da marcacao inicial P1:

• a marcacao inicial (o objeto us1 no lugar P1) sensibiliza a transicao t1, que nao pos-

sui pre-condicao. O disparo t1 chama o metodo getVerificaUsuarioSenha do objeto

cadusuario da classe ManutencaoUsuario, transmitindo, como valor de parametro,

o atributo usuariosenha = teste 1234 (Nome do usuario mais a senha correspon-

dente). O metodo chamado verifica a existencia do usuario e sua respectiva senha,

devolvendo um valor booleano salvado no atributo nuser do objeto us1. Apos o

disparo de t1, um novo objeto us1 (com valor do atributo nuser = 1 modificado no

final do disparo, que indica que o usuario e a senha e existente) e produzido no lugar

P2

• com um objeto us1 em P2 as duas transicoes, t2 e t3, estao sensibilizadas. Mas,

somente a pre-condicao da transicao t3, que informa a existencia do nome de usuario

e senha correspondente atraves do atributo nuser, e satisfeita. O disparo de t3

chama entao o metodo getVerifciaCursoMatriculado do objeto cadusuario da classe

ManutencaoUsuario, transmitindo, com valor de parametro, o atributo cursomat =

1 2 3; (cada numero deste refere-se a um codigo do curso cadastrado no sistema no

qual o usuario ja esta cadastrado. O sımbolo underline serve neste caso para separar

estes codigos de curso). O metodo chamado verifica se o usuario esta cadastrado

nestes cursos, devolvendo um valor booleano armazenado no atributo cadusuario do

objeto us1. Apos o disparo de t3, um novo objeto us1 (com valor do atributo cur

= 1 modificado no final do disparo, que indica que o usuario esta cadastrado nestes

cursos) e produzido no lugar P3.

54

• com um objeto us1 em P3, as duas transicoes t4 e t7, estao sensibilizadas. Mas,

somente a pre-condicao da transicao t4 que informa a validade dos cursos cadas-

trado pelo usuario atraves do atributo cur, e satisfeita. O disparo de t4 chama

o metodo getVerificaDadosInseridos do objeto cadusuario da classe ManutencaoU-

suario, transmitindo, como valor de parametro, o atributo dadosins = teste nome

(valor dos dados preenchidos pelo usuario). O metodo chamado verifica se os dados

inseridos confere com os tipos de dados exigidos, devolvendo um valor booleano

armazenado no atributo dins do objeto us1. Apos o disparo de t4, um novo objeto

us1 (com valor do atributo dins = 1 modificado no final do disparo, indica que os

campos foram preenchidos corretamente) e produzido no lugar P4.

• com um objeto us1 em P4, as duas transicoes t5 e t8, estao sensibilizadas. Mas,

somente a pre-condicao da transicao t5 que informa a validade os dados preenchi-

dos pelo usuario atraves do atributo dins, e satisfeita. O disparo t5 chama entao

o metodo getEfetuaCadastro do objeto cadusuario da classe ManutencaoUsuario,

transmitindo, como valor de parametro, o atributo efcadas = 1 ( valor booleano que

indica que os dados foram preenchidos corretamente). O metodo chamado verifica

se os dados inseridos foram cadastrado com sucesso no banco de dados, devolveundo

um valor booleano armazenado no atributo ecad do objeto us1. Apos o disparo de

t5, um novo objeto us1 (com valor do atributo ecad = 1 modificado no final do

dispara, que indica que obteve sucesso no cadastramento dos dados no banco de

dados) e produzido no lugar P5.

• um objeto us1 em P5 sensibiliza a transicao t6 que nao possui pre-condicao. O

disparo de t7 chama entao o metodo getExibeConclusao do objeto exiberesultado

da classe ExibirSituacao, transmitindo como valor de parametro o atributo excon

= 1 (confirmacao de insercao no banco de dados). O metodo chamado verifica se o

cadastro foi realizado com sucesso, devolvendo um valor booleano armazenado no

atributo econ do objeto us1. Apos o disparo de t6, um novo objeto us1 (com valor

do atributo econ = 1 modificado no final do sisparo, que indica que o cadastro foi

exibido com sucesso) e produzido no lugar de P6.

No final da execucao do teste, obtem-se uma tabela, como a Tabela 4.1, que mostra os

valores dos atributos do objeto us1 relevantes para analise dos resultados do teste. Pode-

se observar em particular o Nome do Usuario e Senha correspondente (atributo nuser =

1 do objeto us1) foi aceito pelo sistema. Posteriormente foi verificado se o usuario estava

matriculado em algum curso (atributo cur do objeto us1). Seguindo os dados inseridos

pelo usuario foi verificados (atributo dins = 1 do objeto us1). Seguindo foi verificado se

o sistema consegui cadastrar os dados corretamente no banco de dados (atributo ecad =

55

1 do objeto us1). Finalmente o resultado do sucesso do cadastramento foi exibido na tela

(atributo econ = 1 do objeto us1).

Valor Inicial Apos o Disparo da Transicao Valor Final

us1.nuser = 0 t1 us1.nuser = 1

us1.cur = 0 t3 us1.cur = 1

us1.dins = 0 t4 us1.dins = 1

us1.ecad = 0 t5 us1.ecad = 1

us1.econ = 0 t6 us1.econ = 1

Tabela 4.1: Valores dos Atributos apos o Disparo das Transicoes.

4.5 Abordagem Multi-formalismo no Contexto do Teste

Funcional

A grande maioria dos diagramas de modelagem possuem uma visao parcial do sistema,

ou seja, limitam-se a representar apenas algumas caracterısticas do mesmo. Dessa forma,

diversas notacoes graficas podem ser utilizadas ao representar um sistema, como meio de

aumentar a precisao das informacoes.

Para garantir que as especificacoes de software sejam consistentes, utiliza-se metodos

formais. Entretanto, boa parte dos desenvolvedores optam por utilizar notacoes semi-

formais, uma vez que as notacoes formais baseiam-se em equacoes matematicas complexas.

Assim, e importante definir uma maneira de incorporar notacoes formais as especificacoes

semi-formais originando um contexto de multi-formalismo de forma a beneficiar-se das

caracterısticas de cada notacao.

A modelagem semi-formal entretanto, pode ser empregada em geral, para a fase de

especificacao de requisitos (lado esquerdo do V), enquanto que as notacoes formais sao

voltadas para a validacao e verificacao do software (lado direito do V).

Neste, trabalho, foi realizado uma correspondencia intermediaria entres estas notacoes

de forma a entrelacar as informacoes do software que consequentemente, ajudam a en-

contrar um modelo de especificacao do teste funcional. Alguns diagramas semi-formais e

formais podem ser usados nas etapas de especificacao de requisitos, como por exemplo:

• Diagramas de Casos de Uso da UML, para ver as funcionalidades que o software

tem e que sao externamente observaveis por agentes externos que interagem com o

software;

• Diagramas de Atividade da UML, que mostram o fluxo de atividades e de controle

para a execucao dos processos;

56

• Diagramas de Fluxo de Dados (DFDs), em que aparecem as funcionalidades do

software assim como os fluxos de dados processados;

• Diagrama SA-RT, que e a combinacao do Diagrama de Fluxo de Dados com Dia-

grama de Fluxo de Controle;

• Rede de Petri Interpretada que especificara as estruturas de controle das funciona-

lidades especificadas;

No lado direito do V, o software ja se encontra no final da fase de desenvolvimento,

portanto, a arquitetura do software ja e conhecida, fornecendo um maior nıvel de detalhes

a serem considerados. Para isso, os seguintes diagramas podem usados:

• Diagramas de Classe da UML para ver a arquitetura do sistema (com as classes

principais que os testes vao acessar);

• Diagramas de Sequencia da UML que permitem visualizar a execucao de cada caso

de uso de acordo com os objetos da arquitetura proposta do sistema;

• Redes de Petri a Objetos, que especificara o modelo de teste (nesta etapa, o objeto

- ficha ainda nao e conhecido).

A Figura 4.13 ilustra as principais funcionalidades de um Sistema de Ensino a Distancia,

usando os Diagramas de Caso de Uso.

Figura 4.13: Diagrama de Casos de Uso para o Sistema de Ensino a Distancia.

57

Diversos modelos podem ser usados para especificar uma funcionalidade. Na fase de

especificacao de requisitos, a funcionalidade Cadastrar Usuario, ilustrada pela RdP Or-

dinaria da Figura 4.4 podera ser modelada, por exemplo, pelo Diagrama de Atividades da

UML, caracterizado por ser um diagrama semi-formal que descreve a atividades desem-

penhadas por um software, representado na Figura 4.14, e pode ser modelada tambem

pelo formalismo das Redes de Petri Interpretadas, mostradas na Figura 4.15. Em am-

bos os modelos e possıvel ver o fluxo de controle que existe no sistema. Em particular

estes modelos poderao ser considerados na elaboracao de conjuntos de testes que mais

tarde contribuirao para testar as funcao de Cadastrar Usuario do Sistema de Ensino a

Distancia.

Figura 4.14: Representacao do Sistema de Ensino a Distancia Generico por Diagrama de

Atividades.

58

Figura 4.15: Representacao do Sistema de Ensino a Distancia Generico por Redes de Petri

Interpretadas.

A execucao de tal cenario, de acordo com o Diagrama da Classe da Figura 4.11, pode

ser ilustrado tambem atraves do Diagrama de Sequencia da Figura 4.16.

Figura 4.16: Diagrama de Sequencia do Sistema de Ensino a Distancia para a Operacao

de Cadastro de Usuario.

Por meio dos Diagramas de Sequencia e possıvel visualizar o resultado da execucao de

cada caso de uso de acordo com os objetos da arquitetura do sistema. Neste contexto, o

ator sera substituıdo pelo objeto de teste o qual testara os metodos invocados do sistema.

Na Figura 4.16, e representado o resultado da execucao do teste, observando-se a interacao

que existe entre todos os objetos envolvidos diretamente no teste e os objetos das classes

ManutencaoUsuario e ExibirSituacao e conseguida atraves da manipulacao dos atributos

destes objetos por meio de chamadas de metodos.

59

Capıtulo 5

O SiEAD

Neste capıtulo sera abordada a descricao do Sistema SiEAD, descrevendo o papel dos

modulos, explicitando qual a tarefa de cada um no sistema. Sera abordado o processo de

desenvolvimento utilizando alguns diagramas da UML. Neste tambem serao abordadas as

linguagens utilizadas para desenvolve-lo.

5.1 Descricao do SiEAD

O Sistema de Educacao a Distancia (SiEAD) fora implementado para apoiar os edu-

cadores em suas atividades de ensino, como uma ferramenta complementar e/ou principal

no processo de ensino-aprendizagem.

O processo de desenvolvimento iniciou por uma pesquisa profunda sobre a dinamica

de ensino a distancia e das ferramentas ja existentes utilizadas neste proposito.

Durante a pesquisa ficou evidenciado os modulos comuns a todos os sistemas de ensino.

A partir desta evidencia, foram determinados os modulos que seriam desenvolvidos e

integrados ao SiEAD. Abaixo, segue a descricao de cada um dos modulos selecionados.

• Agenda - Parte do sistema destinado ao professor manter os alunos informados

sobre um determinado evento. Caso tenha uma prova, uma reuniao, uma aula, um

congresso dentre outros que o professor ache interessante manter os alunos informa-

dos, este modulo permitira o professor criar estes eventos.

• Mural - Parte do sistema destinado a iteracao de alunos e professores. Adotando o

envio de somente mensagens publicas, os participantes (professor e aluno) poderao

mandar mensagens entre si. Este modulo fora destacado como uma “Area de La-

zer”do sistema, possibilitando assim haver um espaco publico de descontracao entre

os participantes, tentando assim evitar que o sistema seja monotono.

60

• Quadro de Avisos - Parte do sistema destinado a postagem de avisos que pos-

suam um conteudo maior e que possuam tambem um interesse imediato ao aluno.

A princıpio este modulo pode entrar em conflito com o modulo Agenda, mas ambos

possuem diferencas significativas. Enquanto o modulo Agenda e destinado a pos-

tagem de diversos avisos sobre datas importantes, os eventos deste serao exibidos

em um calendario no qual o aluno passara o mouse em uma determinada data com

um evento inserido e verificara do que se trata. Ja o modulo Quadro de Avisos

destina-se a postagem de avisos de extrema importancia para o aluno, no qual, ao

entrar no sistema, o aluno de imediato sera avisado sobre os mesmos.

• Glossario - A medida que o professor for inserindo conteudos das disciplinas ofe-

recidas, ao deparar com uma palavra ou um termo que o mesmo ache de grande

importancia ou entao que a mesma possui um significado desconhecido por parte

dos alunos, o mesmo podera inserir no glossario para futura pesquisa por parte do

usuario.

• Material Didatico - Um dos mais importantes modulos do sistema. Intitulado

como “Livro do Sistema”, este modulo destina-se ao professor da disciplina inserir

conteudos sobre a disciplina oferecida. Neste, o professor podera inserir arquivos

em diversos formatos ou entao inserir textualmente conteudos que foram criados

por sua autoria ou textos de outras fontes que tenham importancia a disciplina e

ao assunto em estudo.

• Mensagens - Modulo com finalidade de promover o contato direto entre os alunos

promovendo assim discussoes sobre conteudos inseridos no sistema. Este modulo

tambem serve para troca de informacoes diversas entre os alunos, nao necessaria-

mente sobre os conteudos do sistema. Vale ressaltar que este modo de contato e

privado entre o remetente e o receptor, nao havendo interferencia de outros mem-

bros. Assim, caso o aluno tenha alguma duvida e queira perguntar exclusivamente a

um participante especıfico, o mesmo podera mandar uma mensagem a outro aluno.

• Cursos do Sistema - Modulo do sistema responsavel pela manutencao das dis-

ciplinas no sistema. Caso um professor interesse em ministrar uma disciplina, o

mesmo contata o administrador do sistema para criar a disciplina e tambem recebe

permissao de grupo para poder gerenciar a sua disciplina. Este modulo e a parte

onde o administrador trabalha com as disciplinas, permitindo-as de existir ou nao.

• Forum - Modulo tambem de grande importancia no sistema. Este, de carater

publico, permite ao professor e alunos postarem topicos. Posteriormente, os alunos e

professores poderao responder ao topico criado enviando seu comentario sobre o que

61

fora proposto. Sendo assim, o professor podera ir acompanhando a cada momento

quando um comentario novo for sendo inserido e posteriormente respondendo o

mesmo, atraves de apontamentos se a opiniao do aluno esta correta ou se o mesmo

errou no seu comentario. Assim, a medida que for desenrolando os comentarios,

caso um aluno tenha uma informacao mais precisa ate que a do professor, o mesmo

podera enviar seu comentario, aumentando tanto o conhecimento dos alunos como

do professor.

• Manutencao de Usuarios - Este modulo compreende a parte da administracao do

sistema quanto ao nıvel de usuario. Neste o administrador geral do sistema podera

adicionar alunos ao sistema e remover alunos que nao estao mais matriculados em

nenhuma disciplina. Neste tambem podera ser criados grupos de permissoes aos

usuarios, restringindo-os suas permissoes ao grupo de usuarios que este usuario

participa.

Como pode ser visto, alguns modulos possuem maior importancia e outros menores,

mas quando agrupados, formam uma ferramenta que pode ser utilizada no Ensino a

Distancia.

5.2 Linguagens e Banco de Dados

A seguir sera descrita as linguagens utilizadas no decorrer do desenvolvimento do

sistema, bem como o banco de dados utilizado.

5.2.1 HTML

A linguagem HTML (HyperText Markup Language) - Linguagem de Formatacao de

Hipertexto e a linguagem padrao para produzir paginas da Internet. E uma linguagem

no qual os navegadores utilizam-na para interpretar os codigos escritos nesta linguagem.

Sua primeira versao fora lancada em 1993. Atualmente encontra-se na versao 4.01 no

qual inclui os padroes de recomendacao da W3C, que e um consorcio de empresas que

regulamenta os padroes web, tentando garantir seu potencial maximo.

5.2.2 JavaScript

A linguagem JavaScript e uma linguagem criada pela entao Netscape no ano de 1995

mas no seu inıcio era chamada de LiveScript.

Esta linguagem surgiu visto a necessidade de validacao de formularios do lado do

cliente. Esta linguagem e interpretada e garante maior interatividade e atratividade em

62

sistemas que a utiliza. Isto se da devido a linguagem proporcionar a adicao de recursos

dinamicos as paginas HTML.

5.2.3 PHP

A principal linguagem utilizada neste sistema foi o PHP. A sigla PHP (Hypertext Pre-

processor) refere-se a uma linguagem de programacao de computadores que e interpretada,

de uso livre e recomendada seu uso em sites que possuem conteudos dinamicos.

Apesar de ter sido criada em 1994, apenas em 1997 surgiu a primeira versao estavel

da linguagem PHP. Esta versao estavel foi intitulada PHP 3. A partir deste ano foram

criadas novas funcionalidades da linguagem e atualmente encontra-se na versao PHP 5.

A linguagem PHP e muito parecida em tipos de dados, sintaxe e funcoes com as

linguagens C e C++. Visto isto, a sua popularizacao se tornou grande, visto que ela e

livre, possibilita aos participantes poderem sugerir inovacoes de funcionalidades, e estas

quando aprovadas sao inseridas nas novas versoes. A sua utilizacao pode ser feita embutida

na linguagem HTML e, alem disto, destaca-se pela facilidade que a linguagem lida com

servidores de base de dados como, por exemplo, o MySQL.

Outro ponto muito importante desta linguagem e que ela e multiplataforma, podendo

ser utilizada em sistemas operacionais como o Windows, Linux, Mac OS, OS/2, Solaris

dentre outros.

5.2.4 MySQL

O MySQL e um sistema de gerenciamento de banco de dados que surgiu da necessidade

de haver uma ferramenta rapida o suficiente para atender as necessidades de projeto

de seus desenvolvedores. A versao atual que se encontra e o MySQL 6.0 que oferece

recursos ate entao existentes apenas em sistemas de gerenciamento de banco de dados

mais robustos.

Sua expansao se deu devido a sua facil integracao com a linguagem PHP, exigindo

atualmente que em quase todos os pacotes de hospedagem de paginas exista a integracao

de PHP mais MySQL.

Suas caracterısticas marcantes e que a mesma e multiplataforma, suportando diversos

sistemas operacionais, possui um excelente desempenho e estabilidade, nao exige tanto do

hardware e e livre.

5.3 Requisistos do SiEAD

Iniciando a fase de desenvolvimento de um sistema, tem a fase de levantamento de

requisitos. Como o sistema e grande, sera abordado os modulos Agenda e Manutencao

63

de Usuario, visto que os mesmos serao utilizados como objetos de estudo de casos no

proximo capıtulo.

5.3.1 Agenda

Descricao

Modulo que serve para situar o usuario quanto as datas a serem cumpridas de acordo

com a exigencia do professor. Neste calendario, quando inserido algum evento, a data res-

pectiva tera uma cor diferente sinalizando que ha algum evento, e quando o usuario colocar

o mouse sobre esta data, sera exibido informacoes completas sobre o evento destacado.

Tarefas do Modulo

• Criar um Evento: Cadastra um novo evento em uma data determinada.

• Excluir um Evento: Exclui algum evento selecionado.

• Alterar um Evento: Edita um evento do calendario.

Especificacao dos Sub-Modulos

Criar um Evento‘- Os campos “Nome do evento”, “Descricao do evento”, “Data”,

“Hora”, “Descricao”sao obrigatorios para criar o novo evento.

Excluir um Evento - Para excluir um evento, e necessario que o administrador esteja

logado e sera questionado ao mesmo se ele realmente queria deletar o evento determinado.

Alterar um Evento - Para alterar um evento inserido no sistema, o administrador

deve estar logado e sera exibida uma tela questionando-o se ele realmente deseja alterar

o evento. Caso confirme positivamente, ele tera acesso ao conteudo, mas para confirmar

a alteracao, os campos fixados obrigatorios para criar um evento devem ser preenchidos.

5.3.2 Manutencao de Usuarios

Descricao

Este modulo compreende a parte da administracao do sistema quanto ao nıvel de

usuario. Neste o administrador geral do sistema podera adicionar alunos ao sistema e

remover alunos que nao estao mais matriculados em nenhuma disciplina. Neste tambem

podera ser criados grupos de permissoes aos usuarios, restringindo-os suas permissoes ao

grupo de usuarios que este usuario participa.

64

Tarefas do Modulo

• Cadastrar Usuario: Cadastro de novos usuario do sistema.

• Alterar Usuario: Alteracao dos dados pessoais de usuario, inclusive senha.

• Excluir Usuario: Exclusao de usuarios do sistema.

• Criar Grupo de Usuario: Cadastro de novos grupos de usuario no sistema.

• Alterar Grupo de Usuario: Alteracao dos grupos de usuarios ja existentes no

sistema.

• Excluir Grupo de Usuario: Exclusao dos grupos de usuarios que ja nao sao

utilizados no sistema.

Especificacao dos Sub-Modulos

Cadastrar Usuario- Neste modulo serao criados os usuarios. Para isto ocorrer, sera

exigido como campos obrigatorios “Nome de usuario”, “Senha”, “E-mail”e “Grupo de

Usuario”. Outros campos opcionais tambem serao exigidos. Nesta fase, sera tambem

definido a que grupo o usuario ira participar.

Alterar Usuario - Caso algum dado tenha sido inserido erroneamente neste sub-

modulo podera ser realizado a alteracao dos dados cadastrais do usuario. Deve-se lembrar

que os campos obrigatorios do sub-modulo Cadastrar usuario deve ser respeitado.

Excluir Usuario - Em virtude de um usuario ter sido inserido errado, ou o mesmo,

nao tenha direito de pertencer ao curso, o administrador tera o direito de excluir o usuario

intruso.

Criar Grupo de Usuario - Neste modulo serao criados os novos grupos de usuarios.

Como campo obrigatorio e exigido o “Nome do Grupo”. Outros campos nao sao obri-

gatorios, porem o seu preenchimento determinara os privilegios que um usuario tera no

sistema.

Alterar Grupo de Usuario - O mesmo acontece em alterar grupo de usuario. O

Campo obrigatorio e o “Nome do Grupo”. Os outros campos determina os privilegios de

cada grupo de usuario.

Excluir Grupo de Usuario - Quando um grupo nao e mais interessante para o

sistema, o mesmo pode ser removido.

5.3.3 Casos de Usos do Sistema

Os diagramas de caso de uso da UML servem para ver as funcionalidades que o soft-

ware tem e que sao externamente observaveis por agentes externos que interagem com o

65

software.

Apesar de optar por apresentar as funcionalidades do modulo Agenda e Manutencao

de Usuario, neste topico sera exibido todos os diagramas de caso de uso do sistema, para

dar uma ideia das funcionalidades totais do sistema.

Para comecar exibir os casos de uso, inicialmente o usuario devera informar o Nome

do Usuario e Senha para autenticacao, tendo assim posteriormente acesso as funcoes do

sistema. Na Figura Figura 5.1 e exibido a tela de autenticacao no sistema.

Figura 5.1: Tela Inicial do Sistema - Autenticacao do Usuario no Sistema.

Apos o usuario ter informado o Nome de Usuario e Senha de acesso ao sistema,

aparecera uma tela, como mostra na Figura 5.2, na qual o usuario devera identificar em

qual curso deseja ter acesso. Apos a selecao do curso, o usuario e redirecionado para a

tela principal do sistema do curso matriculado como mostra na Figura 5.3.

Ja iniciado o sistema, a Figura 5.4 apresenta um Diagrama de Caso de uso generico que

ilustra as principais funcoes do sistema do ponto de vista do usuario, alem dos principais

relacionamentos entre o sistema e o ambiente. O diagrama mostra que para a execucao

dos casos de uso de Mural, Agenda, Quadro de Aviso, Glossario, Material Didatico, Men-

sagens, Forum, Manutencao de Usuario e necessaria a interacao de um usuario, no caso

um administrador, um professor ou aluno do sistema. A seguir sao ilustradas de folha

detalhada de alguma das funcionalidades que o sistema apresenta.

Uma vantagem observada na utilizacao de Diagramas de Casos de Uso esta no fato de

que tanto os atores, quanto os casos de uso, sao possıveis candidatos a serem objetos de

teste do sistema.

A Figura 5.5 mostra os principais casos de uso referente a operacao de Mural ofe-

66

Figura 5.2: Tela de Selecao de Cursos Matriculados.

Figura 5.3: Tela Principal do Sistema do Curso Selecionado.

67

Figura 5.4: Diagrama de Casos de Uso - Generico.

recidas pelo sistema, como por exemplo, Criar Mensagem, Alterar Mensagem e Excluir

Mensagem.

A Figura 5.6 mostra os casos de uso do sistema referente a Agenda, como: Criar um

Evento, Alterar um Evento e Excluir um Evento.

A Figura 5.7 ilustra as operacoes de Quadro de Aviso, sendo possıvel realizar as funcoes

de Criar um Aviso, Alterar Aviso e Excluir Aviso.

A Figura 5.8 mostra os casos de uso do sistema referente a opercacao Glossario, como:

Cadastrar Palavra, Alterar Palavra, Excluir Palavra e Pesquisar Palavra.

A Figura 5.9 mostra os principais casos de uso referente a operacao de Material

Didatico oferecidas pelo sistema, como por exemplo, Cadastrar Material Didatico, Al-

terar Material Didatico e Excluir Material Didatico.

A Figura 5.10 ilustra as operacoes de Mensagens, sendo possıvel realizar a funcao de

Enviar uma Mensagem, Responder Mensagem e Excluir Mensagem.

A Figura 5.11 mostra os principais casos de uso referente a operacao de Forum ofere-

cidas pelo sistema, como por exemplo, Criar Categoria, Alterar Categoria, Excluir Cate-

goria, Criar Topico, Alterar Topico e Excluir Topico.

A Figura 5.12 ilustra as operacoes de Manutencao de Usuario, sendo possıvel realizar as

funcoes de Cadastrar Usuario, Alterar Usuario, Excluir Usuario, Criar Grupo de Usuarios,

Alterar Grupo de Usuarios e Excluir Grupo de Usuarios.

68

Figura 5.5: Diagrama de Casos de Uso - Inclusao.

Figura 5.6: Diagrama de Casos de Uso - Agenda.

Figura 5.7: Diagrama de Casos de Uso - Quadro de Aviso.

69

Figura 5.8: Diagrama de Casos de Uso - Glossario.

Figura 5.9: Diagrama de Casos de Uso - Material Didatico.

Figura 5.10: Diagrama de Casos de Uso - Mensagens.

70

Figura 5.11: Diagrama de Casos de Uso - Forum.

Figura 5.12: Diagrama de Casos de Uso - Manutencao de Usuario.

71

5.3.4 Diagramas de Sequencia

O Diagrama de Sequencia e um tipo de diagrama de interacao definido pela UML. Este

tipo de diagrama descreve em ordem as mensagens que sao enviadas entre os objetos. Por

meio de dois eixos e feito a representacao. No eixo vertical encontra a linha de tempo,

enquanto na horizontal sao mostrados os objetos que participam de uma sequencia de

uma atividade.

Modulo Agenda

O diagrama de sequencia Cria um Evento representa a solicitacao por parte do ator

Professor, de criar um novo evento. Para efetuar este processo, o ator Professor dispara

uma acao na Interface da Agenda solicitando esta operacao. O modulo Agenda recebe os

dados deste novo evento e verifica se estes dados podem ser cadastrados. Caso estes dados

possam ser cadastrados, retorna a Interface da Agenda uma confirmacao de cadastro,

liberando assim o disparo automatico da Criacao deste Objeto. Posteriormente, caso

este objeto tenha sido criado, uma mensagem e disparada confirmando a conclusao da

operacao. Na Figura 5.13 exibe este diagrama.

Figura 5.13: Diagrama de Sequencia - Cria Evento.

O diagrama de sequencia Altera um Evento representa a solicitacao por parte do ator

Professor, o interesse de alterar um evento existente. Para efetuar este processo, o ator

Professor dispara uma acao na Interface da Agenda solicitando uma consulta para en-

72

contrar este evento que ele quer alterar. Ao encontrar, o modulo Agenda retorna para

a Interface da Agenda com a confirmacao da consulta. Apos ter recebido o evento a ser

alterado, o ator Professor altera os dados e submete ao modulo Agenda para verificar

se este evento pode ser alterado. Se tudo ocorrer de acordo com as regras estipuladas,

a confirmacao de alteracao dos dados e confirmada para a Interface da Agenda e auto-

maticamente liberando assim o disparo da Alteracao deste Objeto. Posteriormente, caso

este objeto tenha sido alterado, uma mensagem e disparada confirmando a conclusao da

operacao. Na Figura 5.14 exibe este diagrama.

Figura 5.14: Diagrama de Sequencia - Altera Evento.

O diagrama de sequencia Excluir um Evento representa a solicitacao por parte do

ator Professor, o interesse de excluir um evento existente. Para efetuar este processo, o

ator Professor dispara uma acao na Interface da Agenda solicitando uma consulta para

encontrar este evento que ele queira excluir. Ao encontrar, o modulo Agenda retorna para

a Interface da Agenda com a confirmacao da consulta. Apos ter recebido o evento a ser

excluıdo, o ator Professor verifica se e o evento a ser excluıdo e submete os dados para

exclusao. Se tudo ocorrer de acordo com as regras estipuladas, a confirmacao de exclusao

dos dados e confirmada para a Interface da Agenda e automaticamente liberando assim o

disparo da Exclusao deste Objeto. Posteriormente, caso este objeto tenha sido excluıdo,

uma mensagem e disparada confirmando a conclusao da operacao. Na Figura 5.15 exibe

73

este diagrama.

Figura 5.15: Diagrama de Sequencia - Excluir Evento.

Modulo Manutencao Usuario

O diagrama de sequencia Cadastra Usuario representa a solicitacao por parte do ator

Professor, de cadastrar um novo usuario. Para efetuar este processo, o ator Professor

dispara uma acao na Interface da Manutencao de Usuario solicitando esta operacao. O

modulo Manutencao de Usuario recebe os dados deste novo usuario e verifica se estes

dados podem ser cadastrados. Caso estes dados possam ser cadastrados, retorna a Inter-

face da Manutencao de Usuario uma confirmacao de cadastro, liberando assim o disparo

automatico da Criacao deste Objeto. Posteriormente, caso este objeto tenha sido criado,

uma mensagem e disparada confirmando a conclusao da operacao. Na Figura 5.16 exibe

este diagrama.

O diagrama de sequencia Alterar Usuario representa a solicitacao por parte do ator

Professor, o interesse de alterar um usuario existente. Para efetuar este processo, o

ator Professor dispara uma acao na Interface da Manutencao de Usuario solicitando uma

consulta para encontrar este usuario que ele queira alterar. Ao encontrar, o modulo Manu-

tencao de Usuario retorna para a Interface da Manutencao de Usuario com a confirmacao

74

Figura 5.16: Diagrama de Sequencia - Cadastrar Usuario

75

da consulta. Apos ter recebido os dados do usuario a ser alterado, o ator Professor al-

tera os dados e submete ao modulo Manutencao de Usuario para verificar se este usuario

pode ser alterado. Se tudo ocorrer de acordo com as regras estipuladas, a confirmacao

de alteracao dos dados e confirmada para a Interface da Manutencao de Usuario e auto-

maticamente liberando assim o disparo da Alteracao deste Objeto. Posteriormente, caso

este objeto tenha sido alterado, uma mensagem e disparada confirmando a conclusao da

operacao. Na Figura 5.17 exibe este diagrama.

Figura 5.17: Diagrama de Sequencia - Alterar Usuario

O diagrama de sequencia Excluir Usuario representa a solicitacao por parte do ator

Professor, o interesse de excluir um usuario existente. Para efetuar este processo, o

ator Professor dispara uma acao na Interface da Manutencao de Usuario solicitando uma

consulta para encontrar este usuario que sera excluıdo. Ao encontrar, o modulo Manu-

tencao de Usuario retorna para a Interface da Manutencao de Usuario com a confirmacao

da consulta. Apos ter recebido o usuario a ser excluıdo, o ator Professor verifica se e

o usuario correto a ser excluıdo e submete os dados para exclusao. Se tudo ocorrer de

acordo com as regras estipuladas, a confirmacao de exclusao dos dados e confirmada

para a Interface da Manutencao de Usuario e automaticamente liberando assim o disparo

da Exclusao deste Objeto. Posteriormente, caso este objeto tenha sido excluıdo, uma

mensagem e disparada confirmando a conclusao da operacao. Na Figura 5.18 exibe este

76

diagrama.

Figura 5.18: Diagrama de Sequencia - Excluir Usuario

77

Capıtulo 6

Estudo de Caso: Especificacao de

Modelos de Teste Funcional para um

Sistema de Ensino a Distancia

Este capıtulo contempla a geracao de modelos de testes funcionais. Nele e descrito

como funciona o sistema e posteriormente inicia-se o processo de especificacao dos modelos

de teste funcionais das funcoes Cadastrar Usuario e Criar um Evento de um software de

Ensino a Distancia.

6.1 Especificacao de Modelos de Testes Funcionais de

um Sistema de Ensino a Distancia

Neste trabalho, e apresentada a execucao de testes em duas funcionalidades do sistema

abordado para o estudo de caso. Sao as funcoes de Cadastrar Usuario e Criar um Evento.

6.1.1 Funcionalidade Cadastrar Usuario

Para a operacao de Cadastrar Usuario, inicialmente o usuario do sistema seleciona no

menu Manutencao de Usuario da tela principal do sistema a opcao Cadastrar Usuario,

conforme mostra a Figura 6.1.

Ao selecionar a opcao Cadastrar Usuario, a tela de cadastro e ativada e o usuario

podera cadastrar um novo usuario, informando seus dados nos campos apropriados. No

final da operacao, o usuario seleciona a operacao Cadastrar Usuario que corresponde

salvar os dados preenchidos. Se nenhum dos dados cadastrais inseridos pelo usuario

estiver incorreto, a operacao e salva com sucesso, caso contrario uma mensagem de erro

e enviada ao usuario informando que os dados nao foram salvos. A Figura 6.2 apresenta

78

Figura 6.1: Selecao da Opcao Cadastrar Usuario.

a tela de cadastros para a opcao de adicionar um novo usuario.

O Diagrama de Atividade descreve a funcao Cadastrar Usuario apresentando todas

as atividades a serem executadas para a operacao ser realizada, bem como as restricoes

(condicoes) que existem, como pode ser observado na Figura 6.3.

6.1.2 Funcionalidade Criar um Evento

Considerando agora a funcao de Criar um Evento, o usuario deve, na tela principal do

sistema, escolher no menu Agenda, a opcao Criar um Evento, como mostra na Figura 6.4.

Ao selecionar a opcao Criar um Evento, a tela de cadastro e ativada e o usuario

podera cadastrar um novo evento, informando seus dados nos campos apropriados. No

final da operacao, o usuario seleciona a operacao Cadastrar Evento que corresponde salvar

os dados preenchidos. Se nenhum dos dados cadastrais inseridos pelo usuario estiver

incorreto, a operacao e salva com sucesso, caso contrario uma mensagem de erro e enviada

ao usuario informando que os dados nao foram salvos. A Figura 6.5 apresenta a tela de

cadastros para a opcao de adicionar um novo evento.

O Diagrama de Atividade descreve a funcao Criar um Evento apresentando todas

as atividades a serem executadas para a operacao ser realizada, bem como as restricoes

(condicoes) que existem, como pode ser observado na Figura 6.6.

Na Figura 6.7 e ilustrada a Rede de Petri Interpretada, correspondente ao Diagrama

de Atividade da Figura 6.6, representando o fluxo de controle que existe para a execucao

79

Figura 6.2: Adicionar um Novo Usuario.

Figura 6.3: Diagrama de Atividades para a Funcao Cadastrar Usuario.

80

Figura 6.4: Selecao da Opcao de Criar um Evento.

Figura 6.5: Cadastrar um Novo Evento.

81

Figura 6.6: Diagrama de Atividades para a Funcao Criar um Evento.

82

da funcao Criar um Evento.

Figura 6.7: Redes de Petri Interpretada para a Funcao Criar um Evento.

A especificacao da funcao Cadastrar Usuario, pode ser visualizada por uma RdP In-

terpretada como mostra na Figura 6.8. A partir da Figura 6.9 e obtida a RdP a Objeto,

que possui tanto o fluxo de dados, quanto o fluxo de controle. Mas no modelo apresentado

a seguir nao foi inserido ainda nenhum objeto (ficha), somente apos a execucao de um

cenario de teste, os objetos estarao presentes.

Figura 6.8: Redes de Petri Interpretada: Modelo de Especificacao da Funcionalidade

Cadastrar Usuario.

A Figura 6.10 mostra a RdP Ordinaria correspondente e na Figura 6.11, o modelo de

teste apresentado pela RdP a Objeto para a funcao Criar Evento que ilustra os metodos

principais da classe de teste.

6.2 Implementacao das Funcoes Cadastrar Usuario

e Criar um Evento

Especificar a arquitetura de um software consiste em descrever os seus componentes,

suas propriedades externas e ate mesmo seus relacionamentos com outros softwares, for-

necendo uma visao abrangente sob o ponto de vista funcional ou logico do sistema.

Diversas notacoes graficas podem ser usadas por desenvolvedores para representar

diversas caracterısticas do sistema a ser desenvolvido. Os Diagramas da UML apresentam

83

Figura 6.9: Redes de Petri a Objeto: Modelo de Especificacao de Teste Funcional da

Funcionalidade Cadastrar Usuario.

Figura 6.10: Redes de Petri Ordinaria: Modelo de Especificacao Funcionalidade Criar

um Evento.

84

Figura 6.11: Redes de Petri a Objeto: Modelo de Especificacao Funcionalidade Criar um

Evento.

somente uma visao parcial do sistema, nao levando em consideracao informacoes relevantes

sobre o fluxo de controle de dos dados que existem.

Em particular, neste trabalho, serao abordados alguns diagramas em funcao do auxılio

verificado para a geracao de testes.

Na especificacao de modelo de teste funcionais apresentado neste trabalho, para ilus-

trar a interacao do usuario com a funcionalidade desejada e para a descricao de todas

as atividades desempenhadas no momento da execucao das funcoes, sao utilizados os

Diagramas de Classe da UML, pois eles mostram de forma estrutural e estatica o relacio-

namento interno que existe entre os objetos para a execucao das funcionalidade que sao

externamente observaveis no software.

As funcoes Cadastrar Usuario e Criar um Evento do sistema foram escolhidas para

serem alvos de teste neste trabalho. Dessa forma, as Figura 6.12 e Figura 6.13 mostram

de maneira geral as principais classes que compoem cada caso de uso.

A arquitetura das funcoes a serem testadas e melhor detalhada para a correta identi-

ficacao das classes da funcionalidade especıfica que a classe de teste ira acessar.

Para a funcao Cadastrar Usuario, observada na Figura 6.14, foram implementadas

na forma de metodos de teste, as operacoes testaNomedeUsuario(), testaSenha(), testaE-

85

Figura 6.12: Diagrama de Classes Envolvendo as Principais Classes do Sistema de Ensino

a Distancia - Cadastrar Usuario.

mail(), testaGrupodeUsuario() da classe ClasseTeste, composta dos principais atributos a

serem testados sem a intervencao humana.

O mesmo criterio e aplicado para a funcao Criar um Evento, descrita na Figura 6.15.

A classe ClasseTeste que possui seus atributos e os metodos testaEvento(), testaData(),

testaDescricao() e testaTelefone() acessarao as principais classes da funcao especificada

para realizar o teste.

6.3 Cenario da Execucao de Testes

Nesta secao e considerado inicialmente o cenario da execucao do teste da funcao Ca-

dastrar Usuario. Para criar o cenario de testes, foi relevante inserir alguns casos de teste,

compostos por metodos que manipulavam atributos da classe de teste, cujo objeto cor-

respondente e usuario. A Figura 6.16 ilustra a interface grafica para a execucao do teste

com os casos de teste relacionados para a operacao cadastro de usuario.

De acordo com a Figura 6.16, para cada caso de teste, um conjunto de valores de

atributos sao determinados. Para o teste da funcao Cadastrar Usuario, quatro casos de

teste foram considerados:

• Caso 1: testa o valor do atributo nome do usuario inserido;

• Caso 2: testa o valor do atributo senha inserido;

86

Figura 6.13: Diagrama de Classes Envolvendo as Principais Classes do Sistema de Ensino

a Distancia - Criar um Evento.

• Caso 3: testa o valor do atributo email inserido;

• Caso 4: testa o valor do atributo grupo de usuario inserido.

Para o teste da funcao Criar um Evento, ilustrado na Figura 6.17, outros quatro casos

de teste foram considerados.

• Caso 1: testa o valor do atributo evento inserido;

• Caso 2: testa o valor do atributo data inserido;

• Caso 3: testa o valor do atributo descricao inserido;

• Caso 4: testa o valor do atributo telefone inserido.

6.3.1 Execucao do Teste para a Funcao Cadastrar Usuario

A operacao testaNomedeUsuario(), corresponde ao caso de teste 1. Nela contem um

nome de usuario invalido NomedoUsuario ← “123456” digitado no campo Nome do

Usuario do formulario de cadastro. Este campo aceita nomes que utilizam caracteres.

Durante a execucao dos testes, o cadastro do novo usuario nao foi aceito, em virtude do

campo nao aceitar apenas cadeias de numeros. A Figura 6.18 exibe a tela onde informa

que o nome do usuario esta incorreto.

87

Figura 6.14: Classe de Teste Envolvendo as Classes do Sistema de Ensino a Distancia -

Cadastrar Usuario.

Figura 6.15: Classe de Teste Envolvendo as Classes do Sistema de Ensino a Distancia -

Criar um Evento.

88

Figura 6.16: Interface Grafica do Teste para a Operacao Cadastrar Usuario.

Figura 6.17: Interface Grafica do Teste para a Operacao Criar um Evento.

89

testaNomedeUsuario(){NomedoUsuario← 123456;

Senha← cat0903;

Email← usuario@servidor.com;

Cidade← Cacu;

Estado← GO;

GrupodeUsuario← 1;

}

Figura 6.18: Caso de Teste 1 - Resultado para o Teste do Campo Nome do Usuario da

Funcao Cadastrar Usuario.

Na operacao testaSenha(), caso de teste 2, foi inserido um valor invalido para a senha

como por exemplo Senha ← “NULL”. Nesta etapa do teste, o sistema reconheceu o

valor incorreto da senha, visto que a senha nao pode ter um valor vazio, sendo assim o

sistema rejeitou o cadastro, conforme mostra a Figura 6.19.

testaSenha(){NomedoUsuario← usuarioteste1;

Senha← NULL;

90

Email← usuario@servidor.com;

Cidade← Cacu;

Estado← GO;

GrupodeUsuario← 1;

}

Figura 6.19: Caso de Teste 1 - Resultado para o Teste do Campo Nome do Usuario da

Funcao Cadastrar Usuario.

Na operacao testaEmail(), caso de teste 3, foi inserido um valor invalido para o campo

email como por exemplo Email ← “usuario@.com”. Nesta etapa do teste, o sistema

reconheceu o valor incorreto do campo email. Sendo assim o sistema rejeitou o cadastro,

conforme mostra a Figura 6.20.

testaEmail(){NomedoUsuario← usuarioteste2;

Senha← cat0903;

Email← usuario@.com;

Cidade← Cacu;

Estado← GO;

91

GrupodeUsuario← 1;

}

Figura 6.20: Caso de Teste 3 - Resultado para o Teste do Campo Email da Funcao

Cadastrar Usuario.

Na operacao testaGrupodeUsuario(), caso de teste 4, campo Grupo de Usuario nao foi

selecionado nenhuma das opcoes disponıveis. Nesta etapa do teste, o sistema reconheceu

a falta de preenchimento do campo Grupo de Usuario. Sendo assim o sistema rejeitou o

cadastro, conforme mostra a Figura 6.21.

testaGrupodeUsuario(){NomedoUsuario← usuarioteste2;

Senha← cat0903;

Email← usuario@servidor.com;

Cidade← Cacu;

Estado← GO;

GrupodeUsuario← NULL;

}

92

Figura 6.21: Caso de Teste 4 - Resultado para o Teste do Campo Grupo de Usuario da

Funcao Cadastrar Usuario.

93

No momento da execucao dos testes, o objeto de teste identificado por usuario1 da

Figura 6.18 e conhecido. No inıcio do teste, o objeto de teste corresponde a uma ficha e

se encontrara no lugar P1 (marcacao inicial). A execucao do teste para o caso de teste 1,

se dara atraves dos disparos das transicoes seguintes:

• a marcacao inicial (o objeto usuario1 no lugar P1) sensibiliza a transicao t1, que nao

possui pre-condicao. O disparo de t1 chama o metodo onclic addUsuario() do objeto

usuario da classe ManutencaoUsuario, transmitindo, como valor de parametro, o

atributo usr = true (valor do botao ao ser pressionado). O metodo chamado ativa

a tela de cadastros, devolvendo um valor booleano salvado no atributo rs do objeto

usuario1. Apos o disparo de t1, um novo objeto usuario1 (com valor do atributo rs

= 1 modificado no final do disparo, que indica que a tela de cadastro foi ativada) e

produzida no lugar P2.

• um objeto usuario1 em P2 sensibiliza a transicao t2 que nao possui pre-condicao.

O disparo de t2 chama o metodo onclic saveUsuario() do objeto usuario da classe

ManutencaoUsuario, transmitindo como valores de parametro o atributo usr = true

(valor do botao ao ser pressionado). O metodo chamado salva os dados do usuario

cadastrado, devolvendo um valor booleano salvado no atributo rs do objeto usua-

rio1. Apos o disparo de t2, um novo objeto usuario1 (com valor do atributo rs = 1

modificado no final do disparo, que indica que os dados foram salvos) e produzida

no lugar P3.

• com um objeto usuario1 em P3, as duas transicoes, t3 e t4, estao sensibilizadas.

mas, somente a pre-condicao da transicao t3, que informa os dados foram salvos

atraves do atributo rs, e satisfeita. O disparo de t3 chama entao o metodo on-

clic exitUsuario() do objeto usuario da classe ManutencaoUsuario, transmitindo,

como valor de parametro, o atributo usr = true (valor do boao ao ser pressionado).

O metodo sai da tela de cadastros, devolvendo um valor booleano salvado no atri-

buto rs do objeto usuario1. Apos o disparo de t3, um novo objeto usuario1 (com

valor do atributo rs = 1 modificado no final do disparo, que indica a saıda do usuario

da tela de cadastros) e produzida no lugar P4.

6.3.2 Execucao do Teste para a Funcao Criar um Evento

A operacao testaEvento(), corresponde ao caso de teste 1. Nela contem um evento

invalido Evento ← “10010101” digitado no campo Evento do formulario de cadastro.

Este campo aceita eventos que utilizam caracteres. Durante a execucao dos testes, o

cadastro do evento nao foi aceito, em virtude do campo nao aceitar apenas cadeias de

numeros. A Figura 6.22 exibe a tela onde informa que o evento esta incorreto.

94

testaEvento(){Evento← 10010101;

Data← 01/Dezembro/2008;

Local← UniversidadeFederaldeGoias;

Descricao← OlimpiadasobreInformatica

Telefone← 6484069092;

Email← usuario@servidor.com;

}

Figura 6.22: Caso de Teste 1 - Resultado para o Teste do Campo Evento da Funcao Criar

um Evento.

A operacao testaData(), corresponde ao caso de teste 2. Nela contem uma data invalida

Data ← “NULL/NULL/NULL” digitado no campo Data do formulario de cadastro.

Durante a execucao dos testes, o cadastro do evento nao foi aceito, em virtude do campo

Data nao ter sido preenchido. A Figura 6.23 exibe a tela onde informa que a data esta

incorreta.

testaData(){

95

Evento← 10aOlimpiadaBrasileiradeInformatica;

Data← NULL/NULL/NULL;

Local← UniversidadeFederaldeGoias;

Descricao← OlimpiadasobreInformatica

Telefone← 6484069092;

Email← usuario@servidor.com;

}

Figura 6.23: Caso de Teste 2 - Resultado para o Teste do Campo Data da Funcao Criar

um Evento.

A operacao testaDescricao(), corresponde ao caso de teste 3. Nela contem uma des-

cricao invalida Descricao ← “NULL” digitado no campo Descricao do formulario de

cadastro. Durante a execucao dos testes, o cadastro do evento nao foi aceito, em virtude

do campo Descricao nao ter sido preenchido. A Figura 6.24 exibe a tela onde informa que

a descricao esta incorreta.

testaDescricao(){Evento← 10aOlimpiadaBrasileiradeInformatica;

96

Data← 01/Dezembro/2008;

Local← UniversidadeFederaldeGoias;

Descricao← NULL

Telefone← 6484069092;

Email← usuario@servidor.com;

}

Figura 6.24: Caso de Teste 3 - Resultado para o Teste do Campo Descricao da Funcao

Criar um Evento.

A operacao testaTelefone(), corresponde ao caso de teste 4. Nela contem uma numero

de telefone invalido Telefone ← “64dfgsd4069092” digitado no campo Telefone do for-

mulario de cadastro. Durante a execucao dos testes, o cadastro do evento foi aceito. A

Figura 6.25 exibe a tela confirmando o cadastro do evento com o telefone incorreto.

testaTelefone(){Evento← 10aOlimpiadaBrasileiradeInformatica;

Data← 01/Dezembro/2008;

Local← UniversidadeFederaldeGoias;

97

Descricao← OlimpiadasobreInformatica

Telefone← 64dfgsd4069092;

Email← usuario@servidor.com;

}

Figura 6.25: Caso de Teste 4 - Resultado para o Teste do Campo Telefone da Funcao

Criar um Evento.

No momento da execucao dos testes, o objeto de teste identificado por evento1 da

Figura 6.18 e conhecido. No inıcio do teste, o objeto de teste corresponde a uma ficha e

se encontrara no lugar P1 (marcacao inicial). A execucao do teste para o caso de teste 1,

se dara atraves dos disparos das transicoes seguintes:

• a marcacao inicial (o objeto evento1 no lugar P1) sensibiliza a transicao t1, que nao

possui pre condicao. O disparo de t1 chama o metodo onclic addEvento() do objeto

evento da classe Evento, transmitindo, como valor de parametro, o atributo evt =

true (valor do botao ao ser pressionado). O metodo chamado ativa a tela de cadas-

tros, devolvendo um valor booleano salvado no atributo rs do objeto evento1. Apos

o disparo de t1, um novo objeto evento1 (com valor do atributo rs = 1 modificado

no final do disparo, que indica que a tela de cadastro foi ativada) e produzida no

lugar P2.

• um objeto evento1 em P2 sensibiliza a transicao t2 que nao possui pre-condicao.

O disparo de t2 chama o metodo onclic saveEvento() do objeto evento da classe

Evento, transmitindo como valores de parametro o atributo evt = true (valor do

botao ao ser pressionado). O metodo chamado salva os dados do evento cadastrado,

devolvendo um valor booleano salvado no atributo rs do objeto evento1. Apos o

98

disparo de t2, um novo objeto evento1 (com valor do atributo rs = 1 modificado no

final do disparo, que indica que os dados foram salvos) e produzida no lugar P3.

• com um objeto evento1 em P3, as duas transicoes, t3 e t4, estao sensibilizadas.

mas, somente a pre-condicao da transicao t3, que informa que os dados foram sal-

vos atraves do atributo rs, e satisfeita. O disparo de t3 chama entao o metodo

onclic exitEvento() do objeto evento da classe Evento, transmitindo, como valor de

parametro, o atributo evt = true (valor do boao ao ser pressionado). O metodo sai

da tela de cadastros, devolvendo um valor booleano salvado no atributo rs do objeto

evento1. Apos o disparo de t3, um novo objeto evento1 (com valor do atributo rs =

1 modificado no final do disparo, que indica a saıda do usuario da tela de cadastros)

e produzida no lugar P4.

A execucao dos testes para as duas funcoes abordadas foi derivada a partir dos Dia-

gramas de classe da Figura 6.14 e Figura 6.15.

E possıvel tambem obter a partir dos Diagramas de Sequencia, que permitem visualizar

a execucao de cada caso de uso de acordo com os objetos da arquitetura do software.

O ator, no contexto do modelo de teste funcional, e substituıdo pelo objeto de teste.

Assim, existe uma interacao entre o objeto de teste e o objeto das classes envolvidas,

atraves da manipulacao dos valores de atributos realizada por meio da invocacao de

metodos. A Figura 6.26 e Figura 6.27 ilustram respectivamente, resultado da execucao

dos testes para as funcoes Cadastrar Usuario e Criar um Evento.

99

Figura 6.26: Diagrama de Sequencia para a Operacao de Cadastrar Usuario.

Figura 6.27: Diagrama de Sequencia para a Operacao de Criar Evento.

100

Capıtulo 7

Conclusao

Como foi visto, a EAD e uma modalidade de ensino caracterizada pela utilizacao de

recursos didaticos organizados, que podem ser apresentados aos interessados em varios

meios como: radio, telefone, televisao, cartas, e-mail, teleconferencia, apostilas impressas,

jornais, etc. Ao observar estes meios, pode-se perceber que os mesmos a cada momento

estao evoluindo, em busca constante para atender a necessidade do estudante.

O Ambiente Virtual de Aprendizagem e um meio que tem sido muito utilizado, visto

o interesse das universidades em atender melhor os seus proprios alunos e tambem em

promover a inclusao de outros novos alunos. Dentre os AVA’s existentes, o Moodle,

Teleduc, AulaNet, e-Proinfo, SOLAR e o WebCT sao os mais utilizados, cada universidade

adequando cada um a sua necessidade. Se nenhum destes for capaz de satisfazer as

necessidades da universidade, percebe-se surgimento de AVA’s de autoria da mesma.

O desenvolvimento constante dos softwares, tem exigidos mecanismos cada vez mel-

hores, afim de garantir software finais com maior qualidade. Ao dizer software, engloba-se

sistemas de aplicacao web. Metodos de teste foram criados e desde que aplicados coeren-

temente, favoreceram na deteccao de defeitos no software a ser testado.

A atividade de teste de software e o processo de executar o software de uma maneira

controlada e com o objetivo de avaliar se o mesmo comporta como o requerido. Para este

controle ser eficiente, esta atividade de teste requer atencao e cuidado antes de iniciar

consequentemente uma analise eficiente dos resultados obtidos. Para realizar o processo

de forma controlada, o processo de teste de um software envolve algumas etapas principais

e estas devem ser executadas durante todo transcorrer do desenvolvimento de um teste

de software.

Fora apresentado a metodologia de desenvolvimento de modelos de especificacao de

teste funcional, baseado em processos de Redes de Petri a Objetos.

A partir da Rede de Petri Ordinaria pode-se originar a Rede de Petri a Objeto com

marcacao inicial em Start que possui como ficha no objeto de teste sem, no entanto,

apresentar o nome dos objetos que compoe a arquitetura do software a ser testado.

101

Quando a arquitetura do software e conhecida (parte direita do V) a versao final do

modelo de teste (em que os nomes dos objetos que contem os diversos metodos chamados

aparecem nas transicoes do modelo de teste) pode ser entao implementado na forma de

uma classe de teste. Dessa forma, tem-se a instanciacao da classe de teste que gerara a

execucao de um cenario de teste.

Posteriormente foi realizado a tarefa de geracao de um Modelo de Especificacao de

Teste Funcional para as Aplicacoes Web, servindo como um alicerce para a criacao do

cenario de teste.

Este trabalho realizou a tarefa de abordagem teorica do Ensino a Distancia, dos Testes

de Software, culminando na criacao de Modelos teoricos de Especificacao de Teste Fun-

cional e na pratica da execucao de Casos de Teste.

A informacoes obtidas no decorrer do trabalho, foram absorvidas para serem analisadas

e confrontadas a cada passo executado. As tecnicas de testes referidas neste trabalho, por

si so, nao resolvem os problemas para obter um software com maior qualidade. Devem

ser aplicadas, tentando minimizar os resultados inesperados.

No estudo de caso do capıtulo 5, pode-se perceber que os casos de testes proposto,

culminando no encontro de um erro nos casos de uso executados, ressaltando assim a

necessidade da aplicacao de testes em softwares.

7.1 Trabalhos Futuros

Como trabalhos futuros, poderia ser gerado automaticamente os testes a partir de um

modelo de teste funcional em redes de Petri. Outro trabalho seria a construcao de uma

ferramenta que permitisse a partir da especificacao de uma funcao, gerar o codigo do

sistema, pois as RdP a Objetos permitem isto, uma vez que elas descrevem de maneira

formal o fluxo de dados e de controle que existem.

102

Referencias

[Alla e David, 1988] Alla, H. e David, R. (1988). Modelling of management/production by

continuous petri net. Congres Automatique 1988, Grenoble, France: Quelle Automa-

tique dans les Industries Manufacturieres — Paris, France: AFCET. Pages: 105-118.

[Aretio, 1998] Aretio, G. (1998). Aprender a Distancia: Estudiar em la UNED. Editora

Casa Del Livro, Madri - Espanha.

[Azevedo, 2002] Azevedo, W. (2002). Longe dos olhos, perto do coracao: reflexoes sobre

distancia e proximidade na educacao online. Revista Brasileira de Aprendizagem Aberta

e a Distancia, Volume 1(Numero 2).

[Beizer, 1990] Beizer, B. (1990). Software Testing Techniques. Van Nostrand Reinhold, New

York, NY, 2a edicao edition.

[Boas, 2008] Boas, R. M. V. (2008). Numero de alunos de cur-

sos a distancia aumenta quase 20 vezes em tres anos.

http://web.infomoney.com.br/templates/news/view.asp?codigo=1021402. Acessado

em 15 de junho de 2008.

[Booch, 1994] Booch, G. (1994). Object-oriented analysis and design with applications.

Addison-Wesley.

[Budd, 1981] Budd, T. A. (1981). Mutation Analysis: Ideas, Examples, Problems and Pros-

pects. North-Holand Publishing Company.

[CABRAL, 1999] CABRAL, A. R. Y. (1999). Estudo sobre treinamento baseado em compu-

tador. Programa de Pos-Graduacao em Ciencia da Computacao. Mestrado. PUC-RS.

[Cardoso. et al., 1999] Cardoso., J., Valette, R., e Dubois, D. (1999). Possibilistic petri nets.

IEEE Trans. on Systems, Man, and Cybernetics, Part B: Cybernetics, Vol. 29, No. 5.

Pages: 573-582.

[Champagnat, 1987] Champagnat, R.; Pingaud, H. A. H. V.-R. C. F. J. V. R. (1987). A

gas storage example as a benchmark for hybrid modelling. European Journal of Auto-

mation, vol 32, n 9-10. Pages 1233-1253.

[Coelho, 2005] Coelho, R. (2005). Teste de software - mini-curso apresentado no simposio

brasileiro de engenharia de software.

[Cruz, 1999] Cruz, D. M. (1999). Manual de sobrevivencia num ambiente virtual de

educacao a distancia por videoconferencia. Fortaleza - Ceara. WISE’99.

103

[Delamaro, 1993] Delamaro, M. E. (1993). Um Ambiente de Teste Baseado na Analise de

Mutantes. Sao Carlos - Sao Paulo.

[Delamaro et al., 2003] Delamaro, M. E., Maldonado, J. C., Fabbri, S. C. P. F., Simao, A.,

Sugeta, T., Vincenzi, A. M. R., e Masiero, P. C. (2003). Proteum: A family of tools to

support specification and program testing based on mutation.

[Demillo, 1978] Demillo, F. S. . R. J. L. . R. A. (1978). Hints on Test Data Selection: Help

for the Practicing Programmer., volume 11. IEEE Computer.

[Demillo, 1987] Demillo, R. A. (1987). Software Testing and Evaluation. The Benja-

min/Cummings Publishing Company.

[e ProInfo, 2008] e ProInfo (2008). Projeto e-proinfo - ambiente colaborativo de aprendiza-

gem. http://www.eproinfo.mec.gov.br/fra eProinfo.php?opcao=1. Acessado em 23 de

junho de 2008.

[Education, 1997] Education, M. I. D. (1997). Models of distance education.

http://www.umuc.edu/ide/modlmenu.hmtl. Acessado em 29 de junho de 2008.

[Farines et al., 2000] Farines, F. J. M., da Silva Fraga, J., e da Silva de Oliveira, R. (2000).

Sistemas de Tempo Real, volume Volume 1. Sao Paulo.

[Genrich, 1987] Genrich, H. (1987). Net models of dynamically evolving data structures.

Concurrency and Nets - Advances in Petri Nets / Voss, K.; Genrich, H.J.; Rozenberg,

G. (eds.) — Berlin: Springer-Verlag. Pages 201-216.

[Goel, 1985] Goel, A. L. (1985). Software Reability Models: Assumptions, Limitations, and

Applicability. IEEE Transactions on Software Engineering.

[Gonzalez, 2005] Gonzalez, M. (2005). Fundamentos da Tutoria em Educacao a Distancia.

Editora Avercamp, Sao Paulo.

[JACOBSON et al., 1992] JACOBSON, I., CHRISTERSON, M., e JONSSON, P. (1992).

Object-oriented software engineering - a use case driven approach. Addison Wesley.

[Jensen, 1990] Jensen, K. (1990). Coloured petri nets: A high level language for system de-

sign and analysis. Report DAIMI PB–338 — Aarhus, Denmark: University, Computer

Science Department. Pages 342-416.

[Liu et al., 1990] Liu, J. W. S., Chung, J.-Y., e Lin, K.-J. (1990). Scheduling periodic jobs

that allow imprecise results. IEEE Transactions on Computers.

104

[Maldonado, 1991] Maldonado, J. C. (1991). Criterios Potenciais Usos: Uma Contribuicao

ao Teste Estrutural de Software. DCA/FEE/UNICAMP, Campinas - Sao Paulo.

[Maldonado, 1997] Maldonado, J. C. (1997). Criterios de teste de software: Aspectos

teoricos, empıricos e de automatizacao. ICMC-USP, Sao Carlos - Sao Paulo.

[Mcilroy, 1968] Mcilroy, M. D. (1968). Mass produced software components. Garmisch -

Germany - pp. 79-85. NATO Software Engineering Conference Report.

[McLuhan, 1969] McLuhan, H. M. (1969). Understanding the Media - The Extensions of

Man. The MIT Press, Massachusetts Institute of Tecnology - Cambridge.

[Moncelet, 1998] Moncelet, Gilles; Christensen, S. D. H. P. M. P. J. (1998). Dependability

evaluation of a simple mechatronic system using coloured petri nets. Daimi PB-532:

Workshop on Practical Use of Coloured Petri Nets and Design/CPN, Aarhus, Denmark,

10-12 June 1998 / Jensen, K. (ed.) — Aarhus University. Pages 189-198.

[Moodle, 2008] Moodle (2008). Projeto moodle - modular object oriented dynamic learning

enviroment. http://www.moodle.org/. Acessado em 23 de junho de 2008.

[Moraes, 2002] Moraes, M. C. (2002). Educacao a distancia, fundamentos e praticas. Uni-

camp/NIED.

[Murata, 1989] Murata, T. (1989). Petri nets: Properties, analysis and applications. Pro-

ceedings of the IEEE, Vol. 77, No. 4. Pages: 541-580.

[Myers, 1998] Myers, G. J. (1998). The art of software testing. John Wiley e Sons, New

York - USA.

[Nunes, 1992] Nunes, I. B. (junho 1992). Pequena introducao a educacao a distancia. Revista

Educacao a Distancia, (01).

[Offutt, 2002] Offutt, A. J. (2002). Quality attributes of web software applications. IEEE

Software. Number 2, Volume 19, Pages 25–32.

[Offutt e Wu, 2002] Offutt, A. J. e Wu, Y. (2002). Modeling and testing web-based ap-

plications. Relatorio Tecnico ISE-TR-02-08, George Mason University, Fairfax, VA,

EUA. Disponıvel em: http://ise.gmu.edu/techrep/2002/02 08.pdf. Acessado em 26 de

Outubro de 2008.

[Ortriwano, 1985] Ortriwano, G. S. (1985). A informacao no radio: os grupos de poder e a

determinacao dos conteudos. Editora Summus, Sao Paulo.

105

[Peterson, 1981] Peterson, J. L. (1981). Petri net theory and the modeling of systems.

Englewood Cliffs, New Jersey: Prentice Hall, Inc.

[Petri, 1966] Petri, C. A. (1966). Kommunikation mit automaten. New York: Griffiss Air

Force Base, Technical Report RADC-TR-65–377, Vol. 1. Pages: 1-Suppl. 1.

[Pratt e Palloff, 1999] Pratt, K. e Palloff, R. (1999). Building learning communities in cy-

berspace: Effective strategies for the online classroom. Jossey-Bass.

[Pressman, 1997] Pressman, R. S. (1997). Software engineering practitioners approach.

McGraw-Hill, New York - USA, 4a edicao edition.

[Pressman, 2000] Pressman, R. S. (2000). Software engineering practitioners approach.

McGraw-Hill, New York - USA.

[Ramchandani, 1974] Ramchandani, C. (1974). Analysis of asynchronous concurrent sys-

tems by timed petri nets. Cambridge, Mass.: MIT, Dept. Electrical Engineering, PhD

Thesis.

[Ricca e Tonella, 2002] Ricca, F. e Tonella, P. (2002). Testing processes of web applications.

Ann. Software Eng. Number 1-4, Volume 14, Pages 93–114.

[Rossett, 1989] Rossett, A. (1989). Educational software and published reviews: Congruence

of teacher, developer, and evaluator perceptions, volume Volume 4. San Diego - USA.

[Rumbaugh e Premerlanoi, 1991] Rumbaugh, J.and Blaha, M. e Premerlanoi, W. (1991).

Object oriented modeling and design. Prentice Hall.

[Saniani, 1998] Saniani, D. (1998). Da nova LDB ao novo Plano Nacional de Educacao: Por

uma outra polıtica Educacional. Editora Autores Associados, Campinas - Sao Paulo.

[Sibertin-Blanc, 1985] Sibertin-Blanc, C. (1985). High level petri nets with data structure.

Proceedings of the 6th european Workshop on Application and Theory of Petri Nets,

Espoo, Finland / Jensen, K. Pages: 141-170.

[Sifakis, 1977] Sifakis, J. (1977). Comportement permanent des reseaux de petri tempo-

rises. Reseaux de Petri. Paris, 23–24 Mars 1977 AFCET. / Edite par l’Institut de

Programmation de Paris. Pages 227-247.

[Souza, 2000] Souza, S. R. (2000). Validacao de especificacoes de sistemas reativos: De-

finicao e analise de criterios de teste. Master’s thesis, Instituto de Fısica de Sao Carlos,

Sao Carlos - Sao Paulo.

106

[Souza, 1996] Souza, S. R. S. (1996). Avaliacao do Custo e Eficacia do Criterio Analise de

Mutantes na Atividade de Teste de Software. Sao Carlos - Sao Paulo.

[Sugeta, 2004] Sugeta, T. (2004). Uma contribuicao para o

teste de especificacoes sdl: Aspectos teoricos e empıricos.

http://www.icmc.usp.br/ std2004/Resumos/tatiana maldonado.pdf. Acessado

em 23 de Agosto de 2008.

[Tarouco, 1999] Tarouco, L. M. R. (1999). Educacao a distancia: Tecnologias e metodos

para implantacao e acompanhamento. Fortaleza - Ceara. WISE’99.

[Tazza, 1987] Tazza, M. (1987). Quantitative analysis of a resource allocation problem: A

net theory based proposal. Concurrency and Nets - Advances in Petri Nets / Voss, K.;

Genrich, H.J.; Rozenberg, G. (eds.) — Berlin: Springer-Verlag. Pages 511-532.

[TelEduc, 2008] TelEduc (2008). Projeto teleduc - ambiente de ensino a distancia.

http://www.teleduc.org.br/. Acessado em 23 de Junho de 2008.

[Vicenzi, 1998] Vicenzi, A. M. R. (1998). Subsıdios para o Estabelecimento de Estrategias

de Teste Baseadas na Tecnica de Mutacao. Instituto de Ciencias Matematica e de

Computacao, Sao Carlos - Sao Paulo.

[Wikipedia, 2008a] Wikipedia (2008a). Asp - active server pages.

http://pt.wikipedia.org/wiki/ASP. Acessado em 23 de Agosto de 2008.

[Wikipedia, 2008b] Wikipedia (2008b). Browser - navegador.

http://pt.wikipedia.org/wiki/Navegador. Acessado em 23 de Agosto de 2008.

[Wikipedia, 2008c] Wikipedia (2008c). Cgi - common gateway interface.

http://pt.wikipedia.org/wiki/MSN Messenger. Acessado em 23 de Agosto de

2008.

[Wikipedia, 2008d] Wikipedia (2008d). Msn messenger.

http://pt.wikipedia.org/wiki/MSN Messenger. Acessado em 23 de Agosto de

2008.

[Wikipedia, 2008e] Wikipedia (2008e). Mysql - sistema de gerenciamento de banco de dados.

http://pt.wikipedia.org/wiki/MySQL. Acessado em 23 de Agosto de 2008.

[Wikipedia, 2008f] Wikipedia (2008f). Php - hypertext preprocessor.

http://pt.wikipedia.org/wiki/PHP. Acessado em 23 de Agosto de 2008.

107

[Wikipedia, 2008g] Wikipedia (2008g). Skype. http://pt.wikipedia.org/wiki/Skype. Aces-

sado em 23 de Agosto de 2008.

[Wikipedia, 2008h] Wikipedia (2008h). Web template.

http://pt.wikipedia.org/wiki/Web template. Acessado em 23 de Agosto de 2008.

108