Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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← [email protected];
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← [email protected];
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 ← “[email protected]”. 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← [email protected];
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← [email protected];
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← [email protected];
}
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← [email protected];
}
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← [email protected];
}
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← [email protected];
}
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