Você está na página 1de 87

UNIVERSIDADE FEDERAL DE SANTA CATARINA

Relatório 1: Metodologia para Ensino de Programação Orientada a Objetos com Jogos 2D

Kaléu Caminha

Florianópolis, 2º semestre de 2012

UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE SISTEMAS DE INFORMAÇÃO

Relatório 1: Metodologia para Ensino de Programação Orientada a Objetos com Jogos 2D

Kaléu Caminha

Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção de grau de Bacharel em Sistemas de Informação.

Florianópolis, 2º semestre de 2012

Kaléu Caminha

Relatório 1: Metodologia para Ensino de Programação Orientada a Objetos com Jogos 2D

Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção de grau de Bacharel em Sistemas de Informação.

Orientador

Professor Doutor Ricardo Pereira e Silva

Banca Examinadora

Leandro José Komosinski Patrícia Vilain

Para os avaliadores deste relatório 1

Percebi ao finalizar este primeiro relatório o grande número de páginas. Acredito que isto se deve ao alto número de ilustrações e listas utilizados e também a um detalhamento (talvez desnecessário de laguns capítulos).

Sem dúvida visualizo que isso precisará ser corrigido para a versão final de modo que o trabalho não fique por demais extenso, solicito ajuda para como tratar esta questão. Muito Obrigado

Sumário

Lista de Reduções

10

Resumo

11

 

1 Introdução

12

1.1 Justificativa

13

1.2 Objetivo Geral

15

1.3 Objetivos Específicos

15

1.4 Metodologia de Pesquisa

15

2 Fundamentação Teórica

17

2.1

Programação Orientada a Objetos

17

2.1.1 Conceitos POO

18

2.1.2 Estruturas Básicas de Programação em Java

18

2.2

Jogos 2D

19

2.2.1 Desenho de imagens

20

2.2.2 Animações

20

2.2.3 Tiles e Composição de Cenários

20

2.2.4 / Plano Cartesiano

Pontos

21

2.2.5 Sprites

21

2.2.6 Dispositivos de Entrada

21

2.2.7 Execução de sons

21

2.2.8 Taxa de Quadros e atualização do jogo

22

2.2.9 Acumuladores de Tempo

22

2.2.10 Gravidade

22

2.2.11 Detecção e Tratamento de Colisões

22

2.2.12 O Game Loop

23

2.2.13 Movimentação e Gravidade nos cenários

23

2.3

Frameworks Orientado a Objetos

23

2.3.1 Frameworks OO

23

2.3.2 Metodologias de Desenvolvimento de Frameworks OO

24

2.3.3 Uso de Frameworworks OO

24

2.4

Padrões Pedagógicos

25

2.4.1 O Mais Importante Primeiro (Early Bird)

25

2.4.2 Espiral (Spiral)

26

2.4.3 Metáfora Consistente (Consistent Mataphor)

26

2.4.4 Caixa de Brinquedos (Toy Box)

26

2.4.6

Disposição do território (Lay of the Land)

27

 

2.4.7 Corrigir para cima (Fixer Upper)

28

2.4.8 Maior que a Vida (Larger than Life)

28

2.4.9 Sprint de Projeto dos Estudantes (Student Design Sprint)

28

2.4.10 Engano

(Mistake)

28

2.4.11 Canal de Teste (Test Tube)

29

2.4.12 Preencha as Lacunas (Fill in the Blanks)

29

2.4.13 Estrela de Ouro (Gold Star)

29

2.4.14 Avalie isto novamente Sam (Grade it again Sam)

29

3 Experiência prévia com ensino de POO e Jogos

31

3.1 Conteúdos trabalhados

31

 

3.2 Metodologia

33

 

3.2.1 Exemplo 1 – Movimentando uma bola

34

3.2.2 Exemplo 2 – Construindo o primeiro jogo

35

3.2.3 Exemplo 3 – Ítens e fases

35

3.2.4 Exemplo 4 – Guerra Especial

36

3.2.5 – Personagens e Cenários

37

3.2.6 – Jogo de Luta

38

3.2.7 – Revisão

38

3.3 Avaliação e Resultados

39

 

3.3.1 Teórica

Avaliação

39

3.3.2 da Motivação

Avaliação

40

3.3.3 Avaliação Prática

40

3.3.3.1 Grupo 1 – PowerMusic

40

3.3.3.2 Grupo 2 – Champions Fighter

41

3.3.3.3 Grupo 3 – Ghomaine

41

3.3.3.4 Grupo 4 – Ice Crown Citadel

41

3.3.3.5 Grupo 5 – Moluscation

41

3.3.3.6 Grupo 6 – Terrorist Strategy

41

3.3.3.7 Grupo 7 – God of Worms

41

3.3.3.8 Grupo 8 – Sami Game

41

3.3.4

Resultado avaliação prática

41

3.3.4

Conclusão ao final do módulo

42

4 Ensino de Programação Orientada a Objetos

43

4.1

Metodologias para Ensino OO

43

4.1.1

Isaias Camilo Boratti

44

4.1.1.1 Análise Geral do Método

46

4.1.1.2 Pontos Fortes

47

4.1.1.3 Pontos

Fracos

50

4.1.1.4 Conclusão

53

4.1.2

David J. Barnes e Michael Kölling

53

4.1.2.2

Análise geral do método

58

 

4.1.2.3 Pontos fracos

 

59

4.1.2.4 Conclusão

60

4.1.3

Bruno Feijó et al

60

4.1.3.1

Análise geral do método

62

4.1.4

Stelios

Xinogalos

62

4.1.4.1 O

Uso de ambientes de programação

63

4.1.4.2 Diretrizes para o Ensino das lições propostas

64

4.1.4.3 Análise Geral do

método

70

4.1.5

Michael Caspersen

71

4.1.5.1 As etapas da metodologias

72

4.1.5.2 O

Framework conceitual

73

4.1.5.3 O início

 

73

4.1.5.4 Padrões de Código

73

4.1.5.5 Outros elementos da metodologia

74

4.1.5.6 Análise Geral da Metodologia

74

4.3

Diretrizes para o Ensino de OO

 

74

4.3.1 Princípios baseados na prática com o BlueJ

74

4.3.2 Representações visuais para todas as estruturas e conceitos trabalhados

75

4.3.3 Operações de abstração e framework conceitual

75

4.3.4 Ambiente educacional + Ambiente profissional

75

4.3.5 Processo sistemático de desenvolvimento

75

4.3.6 A partir do zero

 

76

4.3.7 Todos os recursos usados devem ser explicados

76

4.3.8 Estilo de Código-fonte

 

76

4.3.9 Lista abrangente de exercícios e desafios

76

4.3.10 Todos os exemplos devem envolver jogos

76

5 Framework Java para Jogos 2D

 

77

5.1 Aquisição do Conhecimento de Domínio

77

5.2 Modelagem do Framework:

 

77

 

5.2.1 Generalização

77

5.2.2 Flexibilização

78

5.2.3 Modelagem das Classes

79

5.3Validação

 

79

5.4

Documentação

 

79

6 Metodologia de Ensino

80

6.1 Módulo

1:

Objetos Primeiro

80

6.2 Módulo 2: Mini-Game

 

81

6.3 Módulo

3:

Jogo 2D

81

6.4 Avaliação da Metodologia

 

81

7.1

Trabalhos Futuros

82

8 Bibliografia

83

8.1 Livros

83

8.2 Artigos e Documentos acadêmicos

83

8.3 Bibliografia para código-fonte e materiais didáticos desenvolvidos pelo autor

84

8.4 Bibliografia

Consultada

85

Índice de ilustrações

Ilustração 1: Cenário baseado em Tiles

20

Ilustração 2: Exemplo de uma Sprite

21

Ilustração 3: Movimentando uma bola na tela

34

Ilustração 4: Exemplo mais complexo utilizando a bola criada anteriormente

34

Ilustração 5: Tela final do jogo desenvolvido com o auxílio do roteiro

35

Ilustração 6: Terceira fase do exemplo com diversos itens na tela

36

Ilustração 7: Versão final do jogo Guerra Espacial

37

Ilustração 8: Personagem saltando sobre um inimigo representado por uma bola vermelha

38

Ilustração 9: Exemplo jogo de luta

38

Ilustração 10: A Construção do modelo. Fonte: Boratti

48

Ilustração 11: Representação Visual de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha

49

Ilustração 12: Implementação de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha

50

Ilustração 13: Representação Visual de um Array. Fonte: Boratti. adaptado por Kaléu Caminha

50

Ilustração 14: Instanciação de objeto e chamada de método em código

59

Ilustração 15: Objetos na bancada de objetos (em vermelho) e chamada de método de um

objeto.

.59

Ilustração 16: Instanciação de um objeto no objectKarel com a ajuda da interface gráfica

65

Ilustração 17: Criação de uma tarefa a partir dos métodos de um robô

66

Ilustração 18: Execução de um programa. à direita a visualização do robô, à esquerda a lista de tarefas e abaixo a descrição do que ocorre no interior do método em execução

66

Ilustração 19: Criação sistemática de um programa orientado a objetos

72

Índice de tabelas

Tabela

1:

Conceitos POO

18

Tabela 2: Documentação de frameworks

25

Tabela 3: Tabela demonstrando os conteúdos trabalhados na experiência prévia com ensino de orientação a objetos baseado em jogos

32

Tabela 4: Índice de acerto em cada um dos critérios de avaliação do jogo 2D

42

Tabela 5: Conteúdos e Exemplos da metodologia de Boratti

46

Tabela 6: Conteúdos e exemplos da metodologia de Barnes

56

Tabela 7: Conteúdos e exmplos da metodologia de Feijó

62

Tabela 8: Conteúdos e ambiente de programação na metodologia de Xinogalos

64

Lista de Reduções

POO

Programação Orientada a Objetos

OO

Orientação a Objetos

2D

Duas dimensões

Resumo

O presente trabalho busca o desenvolvimento de uma metodologia de ensino de Programação Orientada a Objetos tendo como campo de prática os jogos em duas dimensões. São descritas as ferramentas, o roteiro de aulas com sua respectiva carga horária, avaliações e exercícios a serem utilizados na metodologia apresentada, bem como um framework Java que abstrai os principais recursos específicos da plataforma e algoritmos avançados, importantes para o desenvolvimento de jogos.

1 Introdução

Por volta de abril de 2011 o autor deste trabalho viveu a experiência de ensinar Programação Orientação a Objetos para alunos entre 15 e 17 anos no curso técnico de programação no SENAI de São José, em Santa Catarina.

Dentre muitas dificuldades, as que mais se destacaram eram a evidente desmotivação dos alunos com o tema de programação, a dificuldade com a sintaxe e recursos específicos do Java e a ausência de método para transformação de um problema em um conjunto de classes que representariam sua respectiva solução.

A partir desta constatação, iniciou-se na turma do semestre seguinte uma busca por soluções para estes problemas que culminou em duas grandes mudanças, a primeira foi a adoção da metodologia de ensino criada por David J. Barnes e Michael Kölling utilizando o BlueJ como ambiente de programação e no semestre seguinte, com a mesma turma, iniciou-se um trabalho de desenvolvimento de jogos em Java a partir dos materiais desenvolvidos por Bruno Feijó e Esteban Clua.

Ficou evidente após a aplicação destas práticas que a motivação dos estudantes aumentou e os problemas com certas sintaxes e recursos do Java também diminuíram. Entretanto, na análise dos trabalhos finais de desenvolvimento de jogos, ficou evidente que para metade da turma, ainda havia um grande abismo entre o que sabiam e o domínio prático dos principais conceitos de Programação Orientada a Objetos.

Acredita-se que a inexperiência e a falta de método do autor que acarretaram nas dificuldades percebidas nos alunos ao final do processo de ensino aprendizagem.

E este é o ponto de partida para este trabalho, a busca por métodos, práticas, conceitos e ferramentas que auxiliem alunos – principalmente os que possuem maiores dificuldades com programação – a modelarem e desenvolverem softwares que solucionem problemas com os quais eles próprios venham a se deparar no seu dia-a-dia, deste modo, que se aprenda não apenas a desenvolver códigos orientado a objetos, mas principalmente, conseguir “enxergar os objetos”, como bem colocado pelo professor Ricardo Pereira e Silva na primeira reunião de orientação.

1.1 Justificativa

Na Orientação a Objetos, as metodologias e ferramentas de ensino não são tão maduras quanto nos paradigmas mais antigos como a programação estruturada e funcional (Xinogalos), de forma que muitos professores de ciência da computação (Xinogalos, Proulx, Caspersen, Bennedsen, Rosenberg, Kölling, Barnes, Boratti) que se depararam diante da tarefa de ensinar orientação a objetos, iniciaram uma série de pesquisas em busca de diretrizes, ferramentas e metodologias que norteasse essa importante tarefa.

O autor considera, pela experiência com ensino que a grande maioria dos exemplos didáticos em Java, mesmo em algumas metodologias recentes, trabalha com softwares muito simples para serem interessantes ou fora da área de interesse e conhecimento da maioria dos jovens estudantes de programação.

Um exemplo é o primeiro projeto apresentado no livro texto do ambiente BlueJ, uma máquina de vender bilhetes de trem, algo completamente fora da realidade brasileira, porém, mesmo que adaptássemos o projeto para, por exemplo, uma máquina de vender café, ainda teríamos a distância do aluno entre simular uma máquina de vender café e programar uma máquina de vender café da vida real.

Esta é a vantagem da área de jogos, é possível que o estudante crie algo com o qual ele efetivamente poderá se divertir e além disso, a maioria dos jovens com os quais trabalhei, aos 15 e 16 anos, já possuem um grande número de horas de experiência com jogos, permitindo que eles tragam um conhecimento prévio para a atividade de programação, facilitando a fixação dos conceitos com situações problema com as quais eles já estão familiarizados.

Além desta perspectiva, o uso de jogos para o ensino de programação é um recurso já utilizado por muitos instrutores na comunidade de educadores de ciência da computação, não só pela sua capacidade de estimular os alunos, mas também por ser um tipo de aplicação para o qual convergem os maiores desafios da computação (Feijó) independente do paradigma de programação utilizado.

Porém, livros com conteúdos nesta área geralmente são complexos, utilizando recursos das linguagens de programação que envolvem um grande número de conceitos e regras de sintaxe, o que dificulta sua aplicação didática em sala de aula. Por exemplo, para que seja possível desenhar uma imagem na tela (recurso essencial no desenvolvimento de jogos) em Java é preciso conhecer conceitos complexos como herança e sobrecarga de métodos.

A partir disto, percebe-se que o suporte ao desenvolvimento de jogos em fases iniciais do ensino de programação exige o auxilio de ferramentas que tornem mais fácil o desenvolvimento de recursos como uso de sons, imagens e cenários.

Duas soluções atuais foram encontradas, a primeira, um ambiente de programação denominado Greenfoot (Kölling, 2010) desenvolvido para permitir o ensino de programação com interação e visualização, permitindo uma inclusão rápida e fácil de imagens, sons e posicionamento de elementos em um cenário. A segunda, é o conjunto de bibliotecas denominado JavaLib (Proulx, 2010), cujo objetivo é permitir que o estudante mantenha o foco no projeto do jogo, no seu comportamento e na representação de cada cena através de formas geométricas simples. Mais recentemente a biblioteca foi ampliada para permitir o ensino de OO através da arte de escrever e tocar músicas com abstrações de notas e arranjos musicais.

Para este projeto, foi escolhida uma abordagem próxima a de Proulx pois como relata Xinogalos - que utilizou e ainda utiliza o ambiente BlueJ parcialmente em sua metodologia - é importante preparar os estudantes para serem profissionais usando ferramentas profissionais de desenvolvimento, manter o aluno por muito tempo em ambientes especificamente voltados para o ensino pode torná-lo por demais acostumado aos recursos didáticos e limitadores destes ambientes, não desenvolvendo plenamente as habilidades de programação e abstração, necessárias a um profissional.

Outro fator favorável ao uso de bibliotecas e frameworks no ensino deriva do fato

de

ser muito comum no desenvolvimento de software o aprendizado de novas bibliotecas

e

frameworks. Sendo necessário ao profissional de programação o domínio das

habilidades de compreensão da documentação e utilização de tais bibliotecas e frameworks.

Observa-se também que alguns conceitos como Interfaces e classes abstratas tem sua aplicação observada mais frequentemente em frameworks, sendo a extensão de um framework uma possível forma de estudo de tais conceitos.

Deste modo, considera-se essencial para este trabalho o desenvolvimento de um framework cuja responsabilidade é abstrair as funções básicas necessárias para jogos 2D como construção de cenários, execução de sons, animações, desenho de imagens e demais necessidades dos jogos 2D de modo que o aluno possa se concentrar, no projeto e construção das classes e de suas interações.

A proposta da metodologia deve conter elementos de plano de aula, carga horária,

atividades

práticas

e

avaliações

de

modo

que

possa

ser

reproduzida

em

cursos

introdutórios de Programação Orientada a Objetos com duração de 72 horas/aula. Também é sugerida uma atividade prática de longa duração a ser desenvolvida em laboratório com o auxílio do professor para cursos com uma carga horária mais extensa.

Por fim, justifica-se a escolha da linguagem Java em uníssono com Feijó que caracteriza cinco vantagens para esta linguagem: 1) Permite aplicações em um grande número de plataformas; 2) Roda em mais de um Sistema Operacional e conta com um bom ambiente de programação gratuito (NetBeans); 3) O Java é uma linguagem Orientada a Objetos; 4) Java é um ponto de partida para a programação para internet; e 5) A próxima geração de linguagens orientadas a objetos será uma evolução natural do Java.

1.2 Objetivo Geral

Criar

uma

metodologia

de

ensino

de

desenvolvimento de jogos 2D.

1.3 Objetivos Específicos

Orientação

a

Objetos

através

do

Documentar a experiência do autor com ensino de orientação a objetos baseada em jogos anterior a este estudo;

Apresentar e analisar algumas das principais metodologias de ensino de programação orientada a objetos ressaltando seus pontos fortes e fracos segundo a experiência do autor;

Definir diretrizes para o desenvolvimento da metodologia a partir das metodologias estudadas e da experiência anterior do autor;

Elencar elementos pedagógicos que auxiliem a construção da metodologia;

Construir um framework Orientado a Objetos que atenda as principais características de jogos 2D e esteja de acordo com as diretrizes definidas;

Documentar uma metodologia que atenda a um curso introdutório de programação orientada a objetos de 72 horas aula;

Definir uma atividade de longa duração a ser desenvolvida pelos estudantes em período de aula para disciplinas cujo ano letivo seja superior à 72 horas/aula;

1.4 Metodologia de Pesquisa

Inicia-se

com

a

fundamentação

teórica

de

alguns

elementos

considerados

essenciais ao trabalho como programação orientada a objetos, jogos em duas dimensões, frameworks orientados a objeto e elementos pedagógicos para a ciência da computação.

Após, considera-se essencial a documentação da metodologia utilizada para o ensino de orientação a objetos baseados em jogos 2D na experiência que deu origem ao tema do presente trabalho, de modo que as dificuldades e pontos fortes do ensino anterior fortaleça a nova metodologia que será desenvolvida.

Após, será realizada uma pesquisa nas metodologias para ensino de orientação a objetos, sendo escolhidas para detalhamento as consideradas pelo autor como mais relevantes ao desenvolvimento deste trabalho. A partir deste detalhamento serão definidas diretrizes para o ensino de OO que deverão ser contempladas nesta metodologia.

Com as diretrizes definidas, bem como os elementos de jogos em duas dimensões, será proposto um framework que atenda a estes elementos.

Em seguida, é proposta a metodologia de ensino utilizando os elementos apresentados nos capítulos anteriores. Neste ponto, o framework poderá ser revisto diversas vezes até atingir uma versão final que suporte as diretrizes propostas.

2 Fundamentação Teórica

Este capítulo apresenta alguns elementos básicos ao trabalho sem, entretanto,

apresentar um estrutura lógica sequencial entre estes elementos, de modo que servem

como base para os demais capítulos e discussões.

2.1 Programação Orientada a Objetos

Biologia e matemática. Esta era a formação base de Alan Kay quando ele criou a

Smalltalk, reconhecida como a primeira linguagem totalmente orientada a objetos, no

famoso laboratório da Xerox PARC em Palo Alto, no final dos anos 60.

Observamos a influência desta formação em dois dos princípios iniciais que

nortearam sua pesquisa, o primeiro era que ele inicialmente pensava em objetos ”como

células biológicas e/ou computadores individuais em uma rede, apenas habilitados a se

comunicarem através de mensagens.”. O segundo, que pode ter sido uma das origens às

modernas classes, é derivado de sua raiz matemática, que lhe fez perceber que “cada

objeto poderia ter certas álgebras relacionadas a ele, e que poderiam haver famílias

destas álgebras, o que seria muito útil.”

Além disso, foi fortemente influenciado pela Sketchpad, Simula, Lisp, o projeto da

ARPAnet e a (segundo ele), quase inacreditável arquitetura dos discos rígidos B500 da

Burroughs.

Estes princípios são compatíveis com Boratti que coloca sobre o paradigma de

Programação Orientada a Objetos:

“Esse paradigma procura abordar a resolução de um problema através de uma construção que represente, da melhor forma possível, como as coisas acontecem no mundo real.

O mundo real é constituído por entidades que interagem entre si. Uma entidade pode

ser definida como alguma coisa que tenha sua própria existência, características e que

apresente alguma função no mundo real

consequentemente a identificação do paradigma de programação orientada a objetos”.

uma

entidade pode ser denominada objeto e,

Portanto Programação Orientada a Objetos corresponde um modo de programar no

qual são construídos objetos (entidades, células), pertencentes à classes, que interagem

entre si (através de mensagens) e possuem características próprias.

2.1.1 Conceitos POO

Os conceitos relacionados à POO que serão abordados pela metodologia foram selecionados principalmente a partir da metodologia de Barnes. Para uma melhor organização, estes foram organizados em dois níveis de dificuldade segundo a experiência do autor:

Nível Básico

Nível Avançado

Classe;

Métodos de acesso e métodos modificadores;

Variáveis e Tipos;

Notação de ponto;

Variável de Instância / atributo;

Objetos / Instâncias / instanciação de objetos;

Parâmetros;

Construtores;

Abstração;

Encapsulamento / Modificadores de acesso;

Associação / Composição;

Listas / Iteração;

Tabela 1: Conceitos POO

Herança / Especialização / Generalização;

Classes abstratas;

Interfaces;

Polimorfismo: Variáveis polimórficas / Polimorfismo de método;

Sobrescrita de método;

Modificador static: contantes de classe / métodos estáticos;

Tratamento de Erros / Try

Design de responsabilidade, Princípio da Responsabilidade Única;

Coesão, acoplamento e refatoração;

Catch;

2.1.2 Estruturas Básicas de Programação em Java

De modo a permitir o uso desta metodologia em cursos introdutórios de programação se faz fundamental o ensino de conceitos de determinadas estruturas básicas de controle e de repetição. as estruturas e conceitos básicos que serão abordadas na metodologia serão:

Estruturas condicionais (if, else e else if);

Estruturas de repetição (while, for);

Arrays / Matrizes unidimensionais e bimensionais;

Instrução de atribuição (=, +=, -=, etc);

Variáveis Locais;

Comentários;

Enum;

2.2 Jogos 2D

Esta seção apresenta os principais conceitos utilizados na arquitetura de jogos em duas dimensões a partir do material desenvolvido por Perucia e que acompanha um framework desenvolvido na linguagem de programação C++ para o desenvolvimento destes jogos. Um jogo desenvolvido com este framework, pode apresentar, dentre outros recursos:

Menu principal e de opções;

Personagem animado controlável por teclado;

Cenários com profundidade;

Itens especiais de jogo;

Interação do personagem com cenário e itens;

Inimigos e interação do personagem com estes inimigos;

Controle de pontos de vida do personagem;

Execução de sons;

A arquitetura de um jogo pode envolver diversos subsistemas, um jogo 2D sempre apresentará pelo menos alguns dos subsistemas abaixo:

Interface gráfica (menus, botões, controle, etc);

Tratador de eventos de teclado e/ou joystick;

Gerenciador de dados (fases, gráficos, etc);

Gerenciador de física (velocidade, movimento, colisão, etc);

Engine gráfica (exibição de imagens, rotação, efeitos especiais, etc);

Engine sonora;

Engine lógica (o coração do jogo);

Camadas de abstração de hardware;

Sistema de configuração do jogo (opções, nível de dificuldade, salvamento, etc);

Sistema de menus;

Sistema de ajuda;

Sistema de música;

A partir de Perucia et al, dos exemplos tratados por Feijó e da experiência pessoal do autor foram selecionados os principais conceitos envolvendo a arquitetura de jogos e que serão indispensavelmente cobertos pelo framework que oferecerá suporte a metodologia

2.2.1 Desenho de imagens

O desenho de imagens na tela a partir de determinados arquivos-fonte é uma operação frequente e pode ser complementada com recursos desejáveis como transparência, rotação, aumento ou redução do tamanho original e espelhamento que corresponde ao desenho da mesma imagem só que em posição invertida ou espelhada.

2.2.2 Animações

Animações são sequências de imagens que se alternam em função de um determinado tempo. Em um jogo, é importante que seja possível aumentar e diminuir a velocidade de uma animação (em casos por exemplo, da movimentação de um personagem mais rápido ou devagar) e que assim como nas imagens, seja possível aplicar efeitos de transparência, rotação, aumento ou redução do tamanho e espelhamento.

2.2.3 Tiles e Composição de Cenários

“Tiles são imagens adicionadas em um cenário e divididas em pedaços iguais de tamanho fixo” (Perucia et al). Tiles podem ser utilizados em conjunto com arquivos de configuração para criar cenários complexos. Segue abaixo uma demonstração de construção de um cenário baseado em Tiles.

Segue abaixo uma demonstração de construção de um cenário baseado em Tiles. Ilustração 1: Cenário baseado

Ilustração 1: Cenário baseado em Tiles

Na experiência de ensino de POO baseado em jogos, os alunos requisitaram em vários momentos recursos extras associados ao uso de cenários com Tiles, como por exemplo: que os tiles possam ser escondidos e reexibidos (para casos por exemplo onde existam passagens secretas), que possuam tratamento de colisão com o personagem e demais objetos do jogo e que possam também serem movimentados

2.2.4 Pontos / Plano Cartesiano

Um jogo em duas dimensões ocorre em um plano cartesiano. É importante que existam abstrações para pontos neste plano e operações entre estes pontos como calculo da distância e detecção de ponto mais próximo dentre um conjunto de pontos por exemplo.

2.2.5 Sprites

“Sprites são estruturas com imagens próprias que permitem a criação de animações e o livre posicionamento na tela” (Perucia). Uma sprite em geral é representada por um único arquivo dividido em quadros de tamanho fixo, contendo cada quadro uma imagem. A mesma sprite pode ser posicionada em um determinado ponto da tela exibindo apenas um dos seus quadros internos por vez. A mudança da exibição destes quadros ao longo do tempo resulta em uma animação.

destes quadros ao longo do tempo resulta em uma animação. Ilustração 2: Exemplo de uma Sprite

Ilustração 2: Exemplo de uma Sprite

2.2.6 Dispositivos de Entrada

A interação com o jogo irá ocorrer sempre através de um dispositivo. Os dois mais comuns são teclado e mouse. No caso do teclado é preciso que o desenvolver tenha disponível a informação de se uma (ou um conjunto) determinada tecla está ou não pressionada em um determinado momento no tempo. No caso do mouse, as principais necessidades são a posição do ponteiro do mouse e se o botão esquerdo foi pressionado.

Também é importante que exista uma interface para um joystick, ou seja, um controle tradicional de video-game com 4 botões de ação e quatro botões direcionais.

2.2.7

Execução de sons

Os

recursos

de

som

disponíveis

para

o

desenvolvedor

são

apenas:

1)

carregamento dos arquivos de som; 2) tocar um som (com ou sem loop) e 3) parar um som. O arquivo de áudio pode ser no formato wave, comumente usado em jogos.

2.2.8 Taxa de Quadros e atualização do jogo

Representa o número de quadros de um jogo que uma aplicação consegue executar em um segundo. O jogo irá sempre executar uma chamada de atualização do estado do jogo em loop. A taxa de quadros representa o número de repetições deste quadro em um segundo.

2.2.9 Acumuladores de Tempo

É comum em jogos eletrônicos determinadas ações somente ocorrerem após um determinado tempo. Para realizar este cálculo de tempo uma estrutura conhecida como acumulador de tempo pode ser fornecida. Esta estrutura inicializa com o tempo que irá controlar e, a cada atualização do jogo, deve também ser atualizada. A estrutura fornece uma interface para que o desenvolver identifique se o fim do tempo já chegou e a possibilidade de reiniciar o acumulador.

2.2.10 Gravidade

A gravidade pode ser representada em um jogo por um número em pixels por segundo que representa a aceleração da gravidade. Na vida real, a força da gravidade pode ser contrabalanceada pelo atrito com o ar. Em um jogo, ao invés de utilizar o atrito com o ar, cada objeto recebe um número que representa a aceleração da gravidade sobre ele. Isso permite por exemplo, que um objeto passe a ter um salto maior, simplesmente se a força da gravidade sobre ele for diminuída.

No mundo real, existe um ponto em que o atrito com o ar se iguala a força gravitacional de modo que a velocidade de queda permanece constante. Isto é reproduzido em um jogo, através de uma velocidade máxima que um objeto pode receber quando está em queda.

2.2.11 Detecção e Tratamento de Colisões

A detecção de colisões ocorre verificando se duas formas geométricas que representam objetos do jogo, se tocam. Estas formas geométricas são comumente retângulos e/ou círculos, e a colisão será verificada através de operações matemáticas simples que verificam a intersecção destas formas.

Após a detecção ter ocorrido é necessário tratar a colisão. Ou seja, se o personagem colidir com uma parede à direita, ele não poderá mais se mover para a direita e deverá ser reposicionado para o exato momento antes da colisão.

Uma das formas de dividir este tratamento é tratando primeiro a colisão com o eixo vertical e somente após, com o eixo horizontal.

Também é importante que o desenvolvedor tenha condições de saber para qual direção ocorreu a colisão.

2.2.12 O Game Loop

Todo jogo de computador ocorre dentro de um laço de repetição. Este laço realiza três operações básicas:

Entrada: onde são verificados os comandos emitidos pelos dispositivos de entrada, mensagens via rede, etc;

Processamento: onde é feito o cálculo das posições dos objetos, colisão, etc;

Desenho: onde os objetos são apresentados na tela do dispositivo.

2.2.13 Movimentação e Gravidade nos cenários

Os cenários são um dos grandes núcleos do jogo. A grande maioria dos jogos possuem cenários grandes que podem ser percorridos por um jogador. Além disso, o efeito da gravidade deve parar de ocorrer quando um jogador encosta no chão, geralmente definido em função do cenário.

2.3 Frameworks Orientado a Objetos

Este capítulo disserta sobre o desenvolvimento e uso de frameworks orientados a objetos a partir do trabalho de Silva, esclarecendo as metodologias de desenvolvimento existentes bem como as maneiras de documentá-la de modo a proporcionar o uso adequado dos frameworks de acordo com as diferentes necessidades dos seus usuários.

2.3.1 Frameworks OO

Frameworks Orientados a Objetos correspondem a um conjunto de classes que se adaptam ao desenvolvimento de aplicações de um domínio específico, oferecendo estruturas flexíveis para os pontos em que aplicações de um mesmo domínio diferem entre si.

Duas

das

principais

características

de

um

framework

são

alterabilidade

e

extensibilidade:

Alterabilidade: Permite que os conceitos específicos das aplicações sejam suportados a partir de estruturas flexíveis do framework;

Extensibilidade: Garante que o framework possa ser estendido no seu conjunto de funcionalidades, ou seja, tenha sua manutenibilidade garantida;

Um framework sempre depende de outros artefatos de software para existir, basicamente, as aplicações específicas de um domínio que o originaram e as aplicações geradas a partir dele.

2.3.2 Metodologias de Desenvolvimento de Frameworks OO

Muitos elementos do processo de desenvolvimento de um framework são comuns à diversas metodologias, podemos elencar estes elementos da seguinte forma:

Aquisição de conhecimento de domínio: A primeira etapa é o estudo de aplicações desenvolvidas para o mesmo domínio do framework de modo a identificar generalidades e especificidades dentro das aplicações.

Construção da estrutura de classes: Após a análise, é realizada a modelagem de classes. Esta modelagem pode ser dividida em cinco etapas iterativas:

Generalização: Criação de classes para as estruturas idênticas das aplicações;

Flexibilização: Localização das especificidades dos frameworks;

Aplicação de meta padrões: Criação de métodos template que podem ser flexibilizados através de métodos hooks para os pontos de flexibilização encontrados;

Aplicação de Padrões de Projeto: Incluir classes de um padrão (design pattern) já catalogado e conhecido para uma determinada estrutura do framework;

Aplicação de Princípios de OO: Aplicação de princípios específicos de Orientação a Objetos como uso de herança e composição.

Implementação: Criação do framework em uma linguagem de programação;

Avaliação: O framework deve ser avaliado a partir do desenvolvimento de aplicações do domínio para o qual foi criado;

Refinamento: A partir do desenvolvimento de novas aplicações, o conhecimento

sobre o domínio aumentará, possibilitando a melhoria do framework.

2.3.3 Uso de Frameworks OO

Um framework deve facilitar o desenvolvimento de aplicações de um domínio. Se

entender o framework for muito complexo, pode ser mais fácil desenvolver a aplicação

sem o framework.

Uma das formas de garantir uma documentação que atenda às necessidades dos

usuários do framework é adaptando a documentação à estas necessidades. Segue

abaixo uma proposta de documentação específica para três tipos de usuários comuns:

Tipo de Usuário

Tipo de Documentação

Precisa decidir qual framework utilizar para o desenvolvimento de uma aplicação

Precisa descobrir como desenvolver uma aplicação

Precisam conhecer em detalhes o projeto do framework para o desenvolvimento de aplicações complexas

Descrição do que pode e do que não pode ser feito com o framework.

Receitas específicas de como utilizar um determinado recurso e/ou desenvolver uma aplicação (Cookbook).

Podem ser utilizados diagramas, descrições mais detalhadas da estrutura das classes, código fonte e outras ferramentas. As questões chave para este entendimento são:

Quais classes usar: Quais classes concretas do framework podem ser utilizadas e quais devem ser criadas pelo desenvolvedor;

Quais métodos: devem ser redefinidos pelo desenvolvedor (métodos abstratos) e quais devem ser definidos pelo framework. Entra aqui também a definição dos métodos template;

O que os métodos fazem: qual o cmportamento dos métodos definidos pelo framework.

Tabela 2: Documentação de frameworks

2.4 Padrões Pedagógicos

Como apoio às metodologias de ensino de programação orientada a objetos os

autores frequentemente recorrem à padrões pedagógicos que são projetados para

capturar as melhores práticas e a excelência da arte de aprender e ensinar (THE

PEDAGOGICAL PATTERNS PROJECT) .

Para o ensino de ciências da computação, Joseph Bergin documentou catorze

padrões pedagógicos. Os padrões possuem vários níveis de aplicação, desde a

organização geral de uma disciplina até mesmo práticas em sala de aula. Os padrões são

apresentados em ordem de escala, iniciando pelos que envolvem o planejamento de

cursos semestrais até atividades diárias em salas de aula.

2.4.1

O Mais Importante Primeiro (Early Bird)

O curso é organizado de modo que o mais importante deve ser apresentado primeiro (e frequentemente), e caso isto seja impossível, o quanto antes. Por exemplo, se funções for mais importante que estruturas if, ensine funções primeiro, se objetos são mais importantes que funções, ensine objetos primeiro.

Esta prática é importante porque os estudantes geralmente se lembram melhor do que viram primeiro e é importante que eles percebam desde o início a ideia principal do curso.

Alguns exemplos são:

Ensinar objetos primeiro;

Ensinar projeto primeiro;

Ensinar concorrência primeiro em sistemas operacionais;

Ensinar requisitos de usuário primeiro em Banco de Dados;

Ensinar recursão antes de loops;

2.4.2 Espiral (Spiral)

Quando um conteúdo é trabalhado em sua ordem lógica, o instrutor precisa entrar em muitos detalhes, tornando o ensino desgastante para os estudantes.

Uma solução é trabalhar os conteúdos em fragmentos que permitam que o estudante resolva um determinado problema, posteriormente, mais fragmentos são trabalhados de modo a resolver outros problemas, e assim, sucessivamente, trabalhando o mesmo conteúdo mas em nível de detalhe crescente.

Deste modo, desde cedo o estudante é empoderado a construir aplicações.

2.4.3 Metáfora Consistente (Consistent Mataphor)

Ao ensinar tópicos complexos, é importante utilizar metáforas cuja base seja conhecida pelos estudantes, de modo que ele tenham clareza sobre como o sistema deve se comportar e possam fazer conexões dos novos conceitos com conceitos que já são bem conhecidos por eles.

2.4.4 Caixa de Brinquedos (Toy Box)

O objetivo deste padrão é permitir que desde cedo os estudantes possam entrar em contato com o conhecimento da área do curso através de ferramentas pedagógicas

ilustrativas, os brinquedos.

Estes brinquedos podem ser classes que abstraem parte da complexidade envolvida no desenvolvimento de um software de maior escala, ferramentas que tornam a programação mais acessível, ou qualquer outro tipo de artefato que permita que os estudantes desenvolvam projetos maiores e mais interessantes.

Um dos requisitos deste padrão é que os instrutores precisam preparar o material e ter tempo disponível para que os estudantes explorem os recursos disponibilizados.

2.4.5 Caixa de Ferramentas (Tool Box)

Desde o início do curso os estudantes desenvolvem ferramentas que lhes serão úteis em fases avançadas do curso, funcionando também como ensino de reuso de software.

Os exercícios do curso devem ter diversos níveis e nos níveis iniciais os estudantes são estimulados a discutir e desenvolver seus componentes. É importante também que o projeto de software para reuso seja discutido e apresentado o quanto antes pelo instrutor.

Estes componentes desenvolvidos pelos alunos podem ser complementados por bibliotecas fornecidas pelo instrutor. Um bom exemplo da aplicação deste padrão é o uso de elementos construídos em disciplinas de estruturas de dados.

2.4.6 Disposição do território (Lay of the Land)

Os estudantes devem examinar um artefato do domínio que estão estudando de maior complexidade, de modo a ver a imagem real de um produto na sua área de atuação.

Isto permite que eles façam conexões das diversas partes do sistema com os concteúdos que estão aprendendo, situando cada um deles no contexto de uma aplicação real.

Exemplos podem ser:

Um software com várias classes interagindo em Orientação a Objetos;

Um modelo entidade relacionamento com diversos relacionamentos em um curso de bases de dados;

O projeto completo de um software em um curso de projeto orientado a objetos.

É importante que o artefato seja algo semelhante ao que o instrutor deseja que o estudante desenvolva ao final do curso. É essencial também, que o artefato tenha um

design e utilize os conceitos do curso de forma excelente.

Assim, as diversas partes do artefato a suas interações podem ser examinadas pelos estudantes e posteriormente utilizadas como exemplo de um determinado conceito do curso.

2.4.7 Corrigir para cima (Fixer Upper)

Neste padrão, um artefato de grande porte é oferecido aos alunos com falhas cuidadosamente preparadas. Este padrão permite o ensino de novos conceitos e da análise e correção de erros.

As falhas devem ser óbvias para a maioria dos leitores, contendo uma ou duas falhas de maior complexidade.

A origem do nome do padrão vem da expressão “Fixxer Upper” que representa uma casa vendida em condições ruins, de modo que o comprador precisará repará-la após a compra.

2.4.8 Maior que a Vida (Larger than Life)

Em cursos de literatura, sociologia e história por exemplo, é comum que os estudantes trabalhem com textos que eles não teriam condições de criar.

E como ler é mais fácil do que escrever, este padrão fala sobre usar artefatos de software de maior complexidade e bem escritos como exemplos a serem copiados.

Esta é uma forma de estimular o conhecimento sobre o desenvolvimento de softwares reais que os estudantes ainda não teriam condições de projetar e desenvolver.

Um exemplo são bibliotecas padrão das linguagens de programação atuais.

2.4.9 Sprint de Projeto dos Estudantes (Student Design Sprint)

Ensinar a projetar softwares é hoje reconhecido como necessidade por muitos instrutores. Este padrão sugere o uso de atividades que permitam que os estudantes projetem soluções para problemas, recebam feedback, projetem novamente, recebam novo feedback, e assim sucessivamente.

Um exemplo de atividade é separar os alunos em grupos de dois ou três e solicitar o projeto para um determinado problema. Ao final, são levantadas questões que não podem ser respondidas com um design inadequado e os estudantes são organizados em grupos de 4 ou 5 de modo que cada grupo tem pelo menos duas propostas de projeto. Eles são desafiados a criarem uma nova proposta, ao final, mais questões podem ser

levantadas e alguns projetos discutidos. O processo pode continuar enquanto o professor desejar.

2.4.10 Engano (Mistake)

Os estudantes são estimulados a criarem artefatos com erros propositais, de modo a ensiná-los como reconhecer erros e suas consequências.

Todos cometemos erros, profissionais experientes geralmente conseguem reconhecer um erro quando visualizam as consequências de um, estudantes não sabem reconhecer estes erros.

2.4.11 Canal de Teste (Test Tube)

Também conhecido como “teste e veja”, este padrão força que os estudantes

”. Desde

testem suas próprias perguntas para questões do tipo “O que aconteceria se eu que exista acesso a um computador, eles podem testar suas hipóteses.

É importante que o instrutor forneça listas de exercícios levando em conta as principais dúvidas apresentadas colocando em diversos pontos questões do tipo “O que aconteceria se você

Isto pode ser usado para testar as regras de sintaxe de uma linguagem por exemplo e/ou o uso de operadores.

Um bom exemplo é o ensino de loops, onde a simples mudança de algumas variáveis podem gerar impressões na tela diferentes, de 1 até 10 ou mesmo um loop infinito.

2.4.12 Preencha as Lacunas (Fill in the Blanks)

É muito difícil e o tempo gasto seria muito alto para estudantes iniciantes desenvolverem softwares complexos, porém, o que eles podem fazer com as habilidades iniciais geralmente é muito chato.

A solução proposta é disponibilizar um software complexo que os estudantes possam analisar e deixar pequenas lacunas no software a serem implementadas pelos alunos com os conhecimentos que possuem. Um exemplo simples é uma definição de classe em Java onde o corpo de um método foi deixado em branco.

2.4.13 Estrela de Ouro (Gold Star)

Os estudantes devem ser recompensados pelo que eles fazem bem e jamais os

deprecia por ainda não terem atingido as competências almejadas.

2.4.14 Avalie isto novamente Sam (Grade it again Sam)

Permita que trabalhos e atividades sejam enviados posteriormente para reavaliação. Isso estimula os estudantes a criarem erros e os motiva a melhorarem seus trabalhos para melhorar suas notas.

3 Experiência prévia com ensino de POO e Jogos

No primeiro semestre de 2012, no curso Técnico em Programação articulado com o Ensino Médio do SENAI São José em Santa Catarina, na disciplina de Programação Orientada a Objetos II, foi trabalhado um módulo de desenvolvimento de jogos com Java. A turma trabalhada possui 33 alunos entre 16 e 18 anos.

Esta disciplina está presente no terceiro semestre do curso. Os estudantes já chegam a esta disciplina com uma base sobre alguns conceitos básicos de OO como construção de classes, métodos, atributos e parâmetros, bem como conceitos básicos de estruturas de programação como if, while, switch, dentre outros. Entretanto, por ser um curso paralelo ao ensino médio e pelo perfil do público, é comum que eles cheguem na terceira fase após o período de férias sem se lembrar com exatidão dos conteúdos trabalhados nos semestres anteriores, sendo necessário relembrá-los.

Este módulo teve duração de 76 horas/aula. Destas, 40 horas/aula foram utilizadas para o ensino dos conceitos de Programação e Jogos 2D. As demais 28 horas foram utilizadas pelos alunos em sala com orientação do professor para o desenvolvimento do jogo.

3.1 Conteúdos trabalhados

O conteúdo foi dividido em duas categorias, Programação Orientada a Objetos (foco da disciplina) e Jogos 2D. Além destes conteúdos, questões como uso de controle de versão e uma IDE de programação também foram abordados, porém, por não fazerem parte deste estudo, não serão citados.

Segue abaixo tabela com os conteúdos trabalhados e um identificador para cada

um:

Conteúdos POO

Conteúdos Jogos 2D

C1) Composição; C2) Encapsulamento; C3) Herança; C4) Polimorfismo; C5) sobrecarga e sobreescrita de métodos e construtores; C6) Classes abstratas, C7) Interfaces; C8) Enum; C9) Métodos e atributos estáticos C10) Tratamento de Exceção C11) Padrões de desenvolvimento (frameworks);

C20) Sprites; C21) TileMaps; C22) Animação; C23) Desenho 2D; C23) Captura Eventos Teclado; C24) Captura Eventos Mouse.

Tabela 3: Tabela demonstrando os conteúdos trabalhados na experiência prévia com ensino de orientação a objetos baseado em jogos.

Para melhor entendimento, segue abaixo uma descrição breve de como cada um

dos conteúdos foi trabalhado:

C1) Composição: Para formar objetos de um jogo, como personagens de luta, era preciso ter uma classe composta de outras que representassem imagens, 'magias' dos personagens, etc;

C2) Encapsulamento: Alguns recursos como colisão de personagens com o cenário foi encapsulado pelo professor e fornecido através de classes, como forma de passar o conceito, depois, no desenvolvimento do jogo e dos exemplos em aula eles foram sembre lembrados de encapsular a lógica de alguns elementos do jogo dentro de sua respectiva classe;

C3) Herança: Todos os objetos do jogo precisavam estender uma classe chamada GameObject que já possuía características básicas de um objeto, como a posição inicial, métodos de acesso e métodos modificadores a estes atributos;

C4) Polimorfismo: É comum termos itens em jogos 2D, estes itens podem aumentar a vida do personagem, deixá-lo mais rápido ou mais lento, dentre outras características. Uma das formas de se trabalhar o polimorfismo foi com classes que representavam itens, estas classes estendiam uma classe Item, e todos os itens, representados com subclasses abstratas eram referenciados no projeto como objetos da classe Item, para permitir extensão do software. Também foi visto polimorfismo de método com métodos de colisão que podiam receber diferentes parâmetros.

C5) Sobrescrita de métodos e construtores: A maioria dos métodos implementados pelos estudantes eram da própria classe ou abstratos. A sobrescrita foi trabalhada apenas quando os estudantes estendiam uma classe que representava um objeto com gravidade. A lógica responsável por parar o objeto em caso de queda se ele colidisse com um chão era um comportamento padrão que os estudantes precisavam sobrescrever quando haviam especificidades nos seus objetos, sempre lembrando de chamar o método sobrescrito da classe superior para não perder o efeito da gravidade;

C6) Classes abstratas: A classe GameObject, da qual todos os objetos do jogo devem herdar, é abstrata e exige a implementação de dois métodos, um para execução da lógica do objeto e outro para desenhá-lo.

C7) Classes Interface: Cada fase do jogo era representada por uma classe que implementava uma interface. Esta interface apresentava métodos para quando uma fase iniciava, era carregada, desenhada ou estava em execução;

C8) Enum: Quando foram trabalhados jogos de luta, um enum foi utilizado para controlar o estado do personagem, ou seja, se ele estava pulando, apanhando ou em estado normal;

C9) Métodos e atributos estáticos: O framework utilizado apresentava diversos métodos estáticos, principalmente para recuperar a referência aos objetos que capturam ações dos periféricos e realizam operações de desenho. Os atributos estáticos foram trabalhados para representar as teclas do teclado;

C10) Tratamento de Exceção: Sempre que uma imagem era carregada para o jogo, corria-se o risco dela não existir. Neste caso, uma exceção era gerada internamente pelo software e o estudante deveria tratá-la. Infelizmente neste ponto, apenas era exibida uma mensagem de erro ao usuário e o tratamento de exceção não foi visto em sua plenitude, quando o programador usa exceções para manter o software funcionando mesmo em caso de falhas.

C11) Padrões de desenvolvimento (frameworks): Foi utilizado durante toda a disciplina o framework javaPlay (Feijó et al), de modo que o conceito de framework foi trabalhado constantemente;

C20) Sprites: Em um jogo onde o jogador precisava mover uma nave pelo cenário, foi utilizada uma sprite com a imagem da nave em todas as direções. Como suporte, foi fornecida uma classe que desenhava os quadros de uma sprite, adaptada do framework javaPlay;

C21) TileMaps: Cada cenário era representado por um conjunto de Tiles e um arquivo de configuração que dizia como posicionar os tiles no cenário. Uma classe que desenhava o cenário a partir do arquivo de configuração foi fornecida;

C22) Animação: Foi usado o efeito de bombas explodindo, onde a cada fatia de tempo era preciso mudar a imagem da bomba desenhada na tela;

C23) Desenho 2D: Nos exemplos iniciais foram utilizados somente figuras geométricas simples como círculos e linhas. Todas desenhadas pela API Graphics do próprio Java;

C24) Captura de Eventos Teclado: Através da classe Keyboard fornecida pelo framework javaPlay com métodos para saber se uma determinada tecla estava pressionada;

C25) Captura de Eventos Mouse: Através da classe Mouse fornecida pelo framework javaPlay com métodos para saber se o botão esquerdo ou direito do mouse estava pressionado e qual a posição do cursor na tela;

3.2 Metodologia

O principal elemento da metodologia foi o uso de exemplos, no qual era aplicado um determinado conjunto de conceitos na construção de um jogo e, a seguir, atividades práticas de melhoria do exemplo apresentado de modo a permitir que o estudante tivesse um contato com o conceito e a sua implementação.

Apenas em um único momento iniciaram o desenvolvimento com uma tela vazia, neste caso, tinham em mãos um script que os guiaria pelos conceitos e recursos básicos do javaPlay.

Antes do início deste módulo com jogos houve uma revisão breve dos conceitos de classe, métodos, atributos, e outros conceitos básicos de OO.

Todos os exemplos foram desenvolvidos tendo como base o framework javaPlay

(Feijó). E, após um período de aulas teóricas, os alunos puderam desenvolver seu próprio

jogo, com tema livre. Seguem abaixo o relato dos exemplos utilizados:

3.2.1 Exemplo 1 – Movimentando uma bola

No primeiro momento, foi apresentado um exemplo de uma bola se movimentando

horizontalmente na tela a partir do movimento do teclado (Caminha, Exemplo 1). Esta

lição demonstrou o uso básico do framework, como acessar o teclado e como criar um

objeto de jogo, no caso, a bola.

o teclado e como criar um objeto de jogo, no caso, a bola. Ilustração 3: Movimentando

Ilustração 3: Movimentando uma bola na tela

Após a apresentação, os estudantes receberam a tarefa de permitir o movimento

vertical da bola no eixo vertical sem perder o movimento horizontal existente. Ao final, um

exemplo de um jogo mais complexo (Caminha, Exemplo 2) utilizando o objeto da bola foi

mostrado para exemplificar o potencial do que eles estavam aprendendo. Também foi

disponibilizado um tempo para que eles fizessem alterações neste exemplo mais

complexo, agora porém, de forma livre.

neste exemplo mais complexo, agora porém, de forma livre. Ilustração 4: Exemplo mais complexo utilizando a

Ilustração 4: Exemplo mais complexo utilizando a bola criada anteriormente

3.2.2

Exemplo 2 – Construindo o primeiro jogo

No segundo momento, era importante que os estudantes iniciassem o desenvolvimento de um jogo simples, porém, passando por todas as etapas do processo de desenvolvimento, já que na etapa anterior, haviam apenas realizado uma modificação.

Para auxiliá-los foi fornecido um roteiro de 10 passos (Caminha, javaPlay em 10 passos)que guiava a construção de um jogo (Caminha, Exemplo 3) no qual o personagem controla um jogador em formato de bola (verde) que deve fugir de alguns inimigos (bolas amarelas e vermelhas) até um elemento de chegada, uma estrela.

e vermelhas) até um elemento de chegada, uma estrela. Ilustração 5: Tela final do jogo desenvolvido

Ilustração 5: Tela final do jogo desenvolvido com o auxílio do roteiro

3.2.3 Exemplo 3 – Ítens e fases

Passamos agora a melhorar o jogo desenvolvido com o auxílio do roteiro. A primeira atividade foi o uso do framework para poder realizar a passagem de fases. Então, foi construído um jogo com três fases.

1. A primeira fase corresponde ao jogo já criado na etapa anterior;

2. Na segunda fase o personagem também pode capturar itens. Um dos itens é representado por um quadrado verde e aumenta a velocidade do jogador. O segundo é um quadrado vermelho e inverte a movimentação. Para a construção dos itens foi criada uma classe abstrata que obriga o programador a implementar um método de ação quando o personagem tem colisão com alguns dos itens. Antes de avançar para a terceira fase, os estudantes são orientados a criar um novo tipo de item;

3. Na terceira fase, uma única lista é utilizada para armazenar os diversos itens do jogo. Quando existe colisão com algum deles o método definido na classe abstrata

é executado.

é executado. Ilustração 6: Terceira fase do exemplo com diversos itens na tela 3.2.4 Exemplo 4

Ilustração 6: Terceira fase do exemplo com diversos itens na tela

3.2.4 Exemplo 4 – Guerra Especial

A partir deste ponto, iniciou-se o trabalhando com o uso de imagens e a criação de novos objetos a partir de objetos já existentes. Decidi utilizar uma metáfora similar aos projetos anteriores e escolhi um jogo no qual o jogador controla uma nave que se move pelo cenário e precisa destruir as naves inimigas (Caminha, Guerra Espacial).

Como este projeto era complexo, ele foi divido em 4 etapas:

Etapa 1: apenas foi desenhada uma nave que se movimentava livremente pelo cenário, de modo a trabalhar o uso das classes para desenho de imagens;

Etapa 2: a nave foi capaz de atirar. Os tiros eram criados pela nave, de modo a trabalhar que um objeto era capaz de criar outros objetos ao longo da execução do software. Estes tiros são armazenados em uma lista, trabalhando a capacidade dinâmica de armazenamento das listas;

Etapa 3: uma nave inimiga é criada e o objetivo é, com os tiros, eliminar a nave inimiga. Este módulo trabalha principalmente a interação entre três objetos diferentes em tempo de execução. Também é adicionada uma classe que gerencia

a explosão que ocorre quando o tiro acerta a nave.

Etapa 4: um segundo jogador é adicionado e explosões especiais são adicionadas quando uma nave inimiga atinge um dos jogadores. Várias naves inimigas são criadas e os tiros de ambos os jogadores podem acertar as naves. Isto cria um ambiente complexo que só pode ser gerenciado através do uso de listas. Cada

jogador é construído com uma classe de modo a estimular os estudantes na identificação de código duplicado e possibilidade de herança.

de código duplicado e possibilidade de herança. Ilustração 7: Versão final do jogo Guerra Espacial 3.2.5

Ilustração 7: Versão final do jogo Guerra Espacial

3.2.5 – Personagens e Cenários

Nesta etapa, era importante demonstrar os mesmos conceitos abordados em outro contexto. Foi escolhido o contexto de jogos com cenários e gravidade. Nestes jogos um personagem se movimenta por um cenário que possui uma estrutura considerada como chão e pode saltar sobre obstáculos, plataformas e outros. Como este projeto envolvia grande complexidade, foi dividido em 2 etapas:

Etapa 1: Apenas um personagem (chamado Ryu) se movimentando por um cenário construído a partir de um arquivo de configuração. Toda a colisão com o cenário é feita por uma classe que encapsula a lógica. Os alunos não são instruídos sobre a lógica utilizada pela classe devido a sua complexidade. Os estudantes são instruídos sobre como controlar os pulos do personagem (Caminha, Exemplo Ryu);

Etapa 2: Após, são adicionados inimigos na fase representados por bolas vermelhas que rolam em direção ao jogador, semelhante as naves inimigas no jogo Guerra Espacial (Caminha, Exemplo Ryu 2).

Ilustração 8: Personagem saltando sobre um inimigo representado por uma bola vermelha 3.2.6 – Jogo

Ilustração 8: Personagem saltando sobre um inimigo representado por uma bola vermelha

3.2.6 – Jogo de Luta

Como exemplo final foi trabalhado um jogo de luta utilizando o mesmo personagem

anterior contra outro personagem (chamado Vegeta). Neste jogo os personagens

possuem golpes e um deles pode atingir o outro. Este material serviu principalmente

como estímulo ao desenvolvimento dos jogos dos alunos no projeto final e demonstrou

comportamentos mais complexos de interação entre os objetos (Caminha, Ryu vs

Vegeta).

de interação entre os objetos (Caminha, Ryu vs Vegeta). Ilustração 9: Exemplo jogo de luta 3.2.7

Ilustração 9: Exemplo jogo de luta

3.2.7 – Revisão

Ao final foi preparado um material de revisão de todos os conceitos relembrando os

3.3 Avaliação e Resultados

A avaliação da disciplina foi feita através de conhecimentos e habilidades. Por conhecimento entende-se as capacidades teóricas, avaliadas com três provas de curta duração e uma de revisão sobre todo o conteúdo. Por habilidades entende-se a capacidade prática de desenvolver um jogo utilizando os conceitos aprendidos.

Para avaliar o nível de motivação com a disciplina, principalmente ao trabalharmos o tema de jogos, foram incluídas questões sem peso avaliativo e de resposta voluntária nas provas teóricas.

3.3.1 Avaliação Teórica

As três primeiras provas avaliaram diferentes aspectos ao longo das 40 horas/aula trabalhadas e ao final do conteúdo, houve uma prova com todo o conteúdo abordado durante o ensino. As três primeiras provas foram divididas em duas partes, a primeira parte era sempre aplicada no início das atividades e a segunda ao final. Segue a descrição de cada uma e a média de pontuação obtida.

Primeira prova: foi aplicada logo após a construção do primeiro jogo e abordou conceitos complexos como classes abstratas, interface e herança. A média geral da prova em uma escala de 0 a 100 foi de 66 pontos e meio (Caminha, Prova 2 a e Prova 2b).

Segunda prova: Após este resultado baixo os mesmos conceitos foram retrabalhados nos exemplos posteriores e a segunda prova foi aplicada após o exemplo com uso de itens e diversas fases, de modo que polimorfismo foi incluído com os demais conteúdos na prova. A média geral da turma foi de 90 pontos em uma escala de 0 a 105 (Caminha, Prova 3 a e Prova 3b).

Terceira Prova: A terceira prova teve como foco o reuso de código com composição e herança, acrescido de alguns poucos tópicos sobre jogos 2D. A média geral foi de 73 em uma escala de 0 a 100 (Caminha, Prova 4a e 4b).

Prova de Revisão: A prova revisão foi aplicada a todos os alunos após a revisão com o objetivo de verificar de forma ampla o entendimento teórico da disciplina após todo o conteúdo trabalhado. Esta prova teve pelo menos um tópico sobre cada conteúdo trabalhado e a média geral da turma foi de 72 pontos em uma escala de 0 a 100 (Caminha, Prova de Revisão).

Após a análise da prova percebi que as questões envolvendo os conceitos de herança, composição, polimorfismo, classes abstratas e classes interface foram

devidamente absorvidos.

Porém, tive índice de erro de quase 50% em uma questão que envolvia a identificação e classificação de algumas estruturas básicas como atributos, métodos e construtores (questão 3 da prova de revisão). Porém, no momento de correção da prova praticamente todos percebiam e compreendiam o erro após este ter sido identificado.

A hipótese levantada é que esta dificuldade ocorreu poque foi trabalhado muito com estruturas básicas já prontas que eles apenas copiavam, colavam e modificavam para a sua necessidade, até mesmo quando era criada uma aplicação do zero, eles tinham um roteiro com códigos fonte de apoio.

Como trabalhamos neste modelo por dois meses e a disciplina anterior de Orientação a Objetos havia sido ministrada no ano anterior, acredito que eles acabaram esquecendo o nome de algumas estruturas simples.

3.3.2 Avaliação da Motivação

Na primeira prova, logo após a construção do primeiro jogo os estudantes foram perguntados se estava sendo interessante aprender Orientação a Objetos com Jogos. 82% disseram que sim, 9% não responderam e 9% disseram que não fazia diferença. Havia uma opção para o caso de não estar gostando, nenhum estudante marcou esta opção.

Ficou claro também na relação de convivência que o interesse havia aumentado muito em relação à disciplina de Programação Orientada a Objetos I onde havíamos trabalhado com softwares Desktop e com exemplos proposto por Barnes.

Ao final, pelo menos 5 alunos demonstraram grande interesse em seguir a carreira de programador de jogos.

3.3.3 Avaliação Prática

Ao final das 40 horas aula teóricas, os estudantes tiveram 28 horas aula para desenvolver o próprio jogo. Os 33 alunos se organizaram em 8 grupos e desenvolveram os seguintes trabalhos:

3.3.3.1 Grupo 1 – PowerMusic

Jogo similar ao popular GuitarHero onde o jogador simula que está tocando uma guitarra no acompanhamento da música e deve pressionar os botões correspondendo a nota da guitarra no momento exato indicado por uma animação na tela.

3.3.3.2

Grupo 2 – Champions Fighter

Jogo de luta como o apresentado no exemplo para a turma com personagens clássicos de diferentes desenhos animados e jogos de vídeo-game. Cada personagem pode dar socos, chutes e alguns contém um especial.

3.3.3.3 Grupo 3 – Ghomaine

Jogo de luta como o apresentado no exemplo para a turma com personagens clássicos de diferentes desenhos animados e jogos de vídeo-game com o diferencial de cada personagem contém de 2 à 3 ataques especiais específicos.

3.3.3.4 Grupo 4 – Ice Crown Citadel

Jogo com muitas fases onde três jogadores unem habilidades distintas para derrotar diversos inimigos. Cada inimigo representa uma fase no jogo.

3.3.3.5 Grupo 5 – Moluscation

Um personagem criado pelos estudantes deve percorrer um cenário pulando por obstáculos e bombas. A cada fase é possível ganhar alguns poderes especiais.

3.3.3.6 Grupo 6 – Terrorist Strategy

Jogo no estilo do clássico Bomberman onde dois personagens disputam entre si lançando bombas em um cenário com obstáculos.

3.3.3.7 Grupo 7 – God of Worms

Disputa entre duas minhocas realizado em turnos. Cada minhoca, no seu turno, pode lançar um tiro sobre a outra escolhendo um ângulo e uma força.

3.3.3.8 Grupo 8 – Sami Game

Jogo similar a um futebol de botão no qual cada personagem é um círculo que precisa acertar uma bola e jogá-la para dentro do gol adversário.

3.3.4 Resultado avaliação prática

A avaliação técnica do jogo contou com diversos critérios para verificar se os conceitos de Orientação a Objetos foram aprendidos corretamente, segue abaixo os critérios, o respectivo índice de acerto médio dos grupos e o número de grupos que atenderam perfeitamente ao critério:

Critério

Porcentagem de Acerto

Número de Grupos com acerto máximo

Uso de Composição

90%

6

Uso de Herança

81%

4

Uso de Polimorfismo

38%

3

Classes Enum

38%

3

Classes Abstratas

38%

3

Uso de Listas (ArrayList)

88%

5

Tabela 4: Índice de acerto em cada um dos critérios de avaliação do jogo 2D

A avaliação mostrou de forma clara que os estudantes não conseguiram identificar

em seus projetos oportunidades para uso de recursos mais avançados de programação

como polimorfismo e classes abstratas.

Foi identificado na maioria dos projetos oportunidades do uso destes recursos, de

modo que as restrições não foram decorrentes dos jogos projetados.

Outros conceitos mais básicos como herança e composição foram absorvidos com

tranquilidade e implementados com qualidade pela maioria dos grupos. No caso de

herança, apesar de todos terem utilizado pelo menos alguma classe com herança,

existiam muitos lugares no código onde a herança seria adequada e o grupo não

percebeu. Por isso que apenas metade dos grupos atingiram aproveitamento perfeito

neste quesito, tendo, todos os outros, aproveitamento parcial.

3.3.4 Conclusão ao final do módulo

Ficou evidente o grande aumento da motivação dos alunos, principalmente pela

qualidade de muitos dos jogos apresentados ao final da disciplina.

Porém, a ênfase em um grande conjunto de códigos previamente elaborados que

eles apenas modificavam acabou por gerar dificuldade em reconhecer quando e como

aplicar um determinado conceito aprendido para um problema novo. Por exemplo, eles

tinham facilidade em entender quando usar herança para os casos semelhantes aos

apresentados em sala, mas não em casos diferentes.

Acredito que a metodologia aqui adotada carece de maturidade na elaboração de

atividades e exemplos que permita aos estudantes adquirirem maturidade no processo de

desenvolvimento e identificarem adequadamente onde cada conceito pode ser aplicado.

4 Ensino de Programação Orientada a Objetos

O ensino de programação em Java implica em grandes desafios para o ensino de

programação orientada a objetos. segundo Barnes, um programa mínimo em java possui numerosos obstáculos de sintaxe tas como: escrever uma classe; escrever um método main; a criação de um objeto utilizando a palavra-chave new; uma atribuição a uma variável, a declaração de uma variável, incluindo o tipo; uma chamada de método;

utilizando a notação de ponto; possivelmente, uma lista de parâmetros.

Podemos somar a isso o excesso de conhecimento necessário para realizar operações básicas de input e output, o grande número de termos como instância, herança, método com os quais os estudantes não estão familiarizados e a dificuldade adicional para os estudantes cuja língua nativa não é o inglês (Clark).

Por fim, alguns autores (Barnes, Feijó) identificaram a necessidade de ensinar através de projetos, para que os conceitos possam ser vistos em aplicações reais.

Esta seção visa apresentar algumas metodologias para o ensino de Orientação a Objetos com Java e extrair ao final, um conjunto de diretrizes guia para o presente trabalho.

4.1 Metodologias para Ensino OO

Para a elaboração deste trabalho foram escolhidas cinco metodologias de ensino de Orientação a Objetos. Os critérios para a escolha foram a sua relevância entre os instrutores de programação e a experiência prática do autor deste trabalho com cada metodologia.

A primeira metodologia é a desenvolvida pelo professor do Departamento de

Informática e Estatística da Universidade Federal de Santa Catarina, Isais Camilo Boratti.

Metodologia responsável pelo primeiro contato do autor com Orientação a Objetos.

A segunda é a de maior abrangência internacional, principalmente por ter sido a

primeira metodologia a vir acompanhada de um livro texto e de uma ferramenta que oferecesse suporte total a ela. É a metodologia construída por David J. Barnes e Michael

Kolling utilizando o BlueJ como ambiente de programação. Esta metodologia foi utilizada parcialmente pelo autor para um curso de Programação Orientada a Objetos I de 90 horas aula.

A terceira escolhida foi a metodologia de introdução à ciência da computação com

jogos que deu origem ao curso apresentado no capítulo três, baseada no trabalho de Bruno Feijó do VisionLab da PUC do Rio de Janeiro.

A quarta, é a metodologia desenvolvida por Stelios Xinogalos ao longo de quatro

anos de ensino de programação orientada a objetos. Xinogalos também trabalhou com a

metodologia de Barnes e Kolling, porém com o tempo, passou a adotá-la apenas parcialmente no projeto do seu curso, utilizando um conjunto mais abrangente de ferramentas.

Por fim, para atender uma necessidade observada pelo autor deste trabalho, foi adotada a metodologia de Caspersen, que trabalha com uma abordagem baseada na modelagem do problema a ser resolvido antes de trabalhar como produzir o código para um determinado problema.

Para cada metodologia é apresentada a sequencia de seções da metodologia com os respectivos conteúdos e exemplos trabalhados. Após, é feita uma descrição geral do método, uma análise dos pontos fortes e fracos de cada metodologia e uma revisão final.

4.1.1 Isaias Camilo Boratti

Esta metodologia foi vivenciada pelo autor como aluno no primeiro semestre de 2007, no curso de Sistemas de Informação da Universidade Federal de Santa Catarina, na disciplina de Programação Orientada a Objetos I.

A disciplina foi ministrada pelo próprio professor Isaias Camilo Boratti que, no mesmo ano, em agosto, publicou o livro que documenta a metodologia intitulado “Programação Orientada a Objetos em Java”.

O livro está organizado em oito capítulos conforme tabela abaixo:

Capítulo

Exemplos de Projetos Desenvolvidos

Principais Conceitos abordados

Capítulo 1

Nenhum projeto desenvolvido

Relação POO com o mundo real;

 

Processo de Abstração;

Operações de Abstração.

Capítulo 2

Nenhum projeto desenvolvido

Objetos e Classes;

 

Representação visual de objetos e classes;

Linguagem Java;

Capítulo 3

Imprimir na tela uma linha de texto;

Método main;

Calcular a soma de dois números;

Identificadores;

Escrever um programa que determine a área

Tipagem de valores;

Variáveis;

de um círculo;

 

Criação de objetos;

String / sequência de caracteres;

Declaração de atributos;

Declaração de métodos;

Construtores;

Parâmetros e Argumentos;

Compilação Java;

Processo de modelagem de um software a partir de um problema;

Capítulo 4

Escrever uma aplicação que determine a

Implementação de métodos;

distância entre dois pontos;

Métodos de acesso e métodos modificadores;

 

Implementação de construtores;

Escopo;

Comentários;

Parâmetros;

Implementação de objetos / referência para um espaço de memória;

Tipagem de valores;

Atribuição;

Conversão explícita de tipo;

Expressões aritméticas;

Expressões Lógicas;

Capítulo 5

Escrever um programa que determine a

Processos de repetição / loops;

idade média de um grupo de pessoas;

Processos de tomada de decisão.

Escrever um programa que determine a

Ex: if, switch;

média de idade das pessoas do sexo masculino e também a média de idade das pessoas do sexo feminino de um grupo de pessoas;

Classe Aluno;

Classe Triângulo;

Encapsulamento;

Modificadores de acesso;

Palavra chave this;

Verificar se um número é primo;

Capítulo 6

Desenvolver uma aplicação que faça uma análise do desempenho de alunos em determinada disciplina. A aplicação deve determinar, para cada um dos alunos, a sua média final, juntamente com uma informação dizendo se o aluno foi aprovado ou não. Considerar que o aluno tenha realizado três avaliações, todas com o mesmo peso;

Em um determinado jogo de dados

participam dois jogadores. Cada jogador deve lançar o dado e computar para si os pontos obtidos. Será considerado vencedor o jogador que atingir um total de 100 pontos ou mais. Sempre que no lançamento do dado, o jogador obter o valor 1 ou 6, este terá direito a um novo lançamento;

Modelagem das classes Funcionario, Chefe

e Apoio, sendo as duas últimas subclasses de

Funcionario;

Modelagem da classe abstrata Contribuinte e das subclasses Fisico e Juridico.

Capítulo 7

“Desenvolver uma aplicação que avalie o desempenho de um grupo de estudantes em

determinada disciplina

que

prevê a realização

de vários testes e uma prova final

a

média dos

testes terá peso de 60% e a prova final peso de ”

40%

Capítulo 8

Herança;

A palavra-chave super;

Reutilização de código;

Sobreposição de métodos;

Polimorfismo;

Polimorfismo de método;

Sobrecarga de métodos;

Classes abstratas;

Arranjos / Arrays;

Arrays Multidimensionais;

Operações com arrays.

Atributos de classe;

Métodos de classe;

Métodos da classe Math;

Manipulação de Strings;

Classe Character;

Tabela 5: Conteúdos e Exemplos da metodologia de Boratti

4.1.1.1 Análise Geral do Método

A metodologia inicia demonstrando que o mundo real “é constituído por entidades

que interagem entre si”, e que tais entidades possuem características e funções, podendo

também serem chamadas de objetos.

Dessa forma, a construção de um software orientado a objetos passa pelo processo

de identificação dos objetos envolvidos e de como estes objetos irão se relacionar entre si

para a resolução de um determinado problema.

A partir

disto,

Boratti

conduz

o

estudante

pelo

conceito

de

abstração,

que

corresponde:

“ao processo utilizado na análise de determinada situação, através da qual observa-se uma realidade, tendo-se por objetivo a determinação dos aspectos e fenômenos considerados essenciais, excluindo-se todos os aspectos considerados irrelevantes.”

E a partir de problemas simples como “determinar o raio de um círculo” demonstra

como o problema pode ser modelado em termos de objetos com características e funções

interagindo entre si, modela as classes que representam estes objetos e apresenta sua

respectiva implementação em Java.

Os conceitos chave são demonstrados na medida em que são úteis para resolver

problemas mais complexos e sub seções complementares se encarregam de

determinados aspectos da linguagem Java como operadores matemáticos e detalhes de

sintaxe, sem necessariamente, serem parte da solução dos problemas apresentados.

Ao final de cada seção, é apresentado um resumo dos conceitos e conhecimentos

trabalhados, uma lista de exercícios, geralmente extensa e abrangente, nos casos que

apresentem conteúdo prático, diversos exercícios resolvidos também são fornecidos.

Por fim, ressalta-se que todos os códigos construídos por Boratti são em língua

portuguesa e sempre que apresentam recursos novos, são comentados com descrições

detalhadas do seu comportamento.

4.1.1.2 Pontos Fortes

4.2.1.2.1 Operações de Abstração

No capítulo introdutório da metodologia, Boratti traz o conceito de operações de

abstração que “mostram como o ser humano mentaliza, organiza e modela o mundo ao

seu redor”. Estas operações são úteis na medida em que definem uma taxionomia para

as interações entre as entidades no mundo real e podem ser representadas diretamente

através de código orientado a objetos. Logo, o processo de analisar uma interação entre

entidades no mundo real e o código que deve ser construído para resolver problemas

envolvendo esta interação pode ser mais adequadamente identificado.

As Operações de abstração são demonstradas utilizando representações parecidas

com o utilizado pelo diagrama de classes da UML para as classes identificadas.

Segue abaixo as quatro operações de abstração:

Classificação / Instanciação: Classificação corresponde a determinar um

conjunto de características de um determinado grupo de objetos de modo a

classificá-los em uma categoria ou classe. Instanciação é o processo inverso, no qual exemplos (instâncias) de determinadas categorias são ressaltados. Por exemplo a Classe Carro e Instância carro vermelho do josé;

Generalização e Especialização: Generalização ocorre quando determinamos características comuns a conjunto de classes e assim, criamos uma classe mais genérica. Especialização é o inverso, quando a partir de uma classe genérica, determinamos classes especialistas. Por exemplo, a classe genérica Médico poderia ser especializada em Obstetra, Pediatra e Ornitolaringologista;

Agregação / Decomposição: A Agregação é caracterizada pela relação de “é composto por” entre duas classes. A decomposição é quando dizemos que um objeto “é parte de” outro objeto. Por exemplo, a classe Carro é composta por objetos da classe Motor. Já um objeto da classe Motor é parte de um objeto da classe Carro;

Associação: Ocorre quando dois objetos possuem algum tipo de ligação entre si mas podem existir independentemente do outro, Por exemplo, na relação que ocorre entre objetos das classes Professor e Aluno.

4.2.1.2.2 Processo de Modelagem

Boratti coloca que o modelo de resolução de um problema, ou seja, o software, é o resultado de um processo de abstração que em orientação a objetos corresponde à identificação dos objetos com suas características e funções e a respectiva modelagem das suas classes.

e funções e a respectiva modelagem das suas classes. Ilustração 10: A Construção do modelo. Fonte:

Ilustração 10: A Construção do modelo. Fonte: Boratti

4.2.1.2.3 Representação Visual de Objetos

Após a identificação dos objetos é necessário representá-los visualmente pelo projetista de software. A visualização proposta por Boratti utiliza um círculo para representar um objeto com um texto dentro representando o identificador deste objeto.

Quando um objeto é composto por outros objetos estes são representados como círculos dentro do círculo maior. No caso de atributos simples de um objeto como números e textos, estes objetos são representados com um retângulo.

textos, estes objetos são representados com um retângulo. Ilustração 11: Representação Visual de Objetos. Fonte:

Ilustração 11: Representação Visual de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha

4.2.1.2.4 Implementação de Objetos

Recordo, como estuante do professor Isaías Boratti, que fortaleceu muito o meu aprendizado no momento que compreendi que cada objeto ocupava um espaço na memória e que uma variável, na verdade, era um apontador para este espaço na memória.

Este aspecto da implementação de objetos é tratada na seção 4.8 onde Boratti coloca que “a identificação de um objeto constitui-se em uma posição na memória (portanto, uma variável) que armazena o endereço do espaço de memória ocupado por aquele objeto”.

Para exemplificar este conceito o seguinte código é apresentado:

Ponto umPonto, outroPonto; // Um ponto contém um atributo inteiro x e um y umPonto = new Ponto(); outroPonto = new Ponto(); outroPonto.redefina_se(2.0, 3.0); // este método altera os valores de x e y

E a partir do código acima, é utilizada uma adaptação da visualização de objetos demonstrando que as variáveis são apenas apontadores para os objetos:

Ilustração 12: Implementação de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha 4.2.1.2.5 Representação Visual

Ilustração 12: Implementação de Objetos. Fonte:

Boratti. Adaptado por Kaléu Caminha

4.2.1.2.5 Representação Visual de um Array

Arranjos, como são chamados os tradicionais Arrays por Boratti são “elementos que

armazenam vários valores”. Para facilitar o ensino foi criado um modelo visual para o uso

de arrays. Para exemplificar o modelo usaremos o seguinte código:

int[] numeros = new int[8]; int cont = 2; numeros[1] = 34; numeros[cont] = 15; numeros[cont+1] = numeros[cont] – 10;

O código acima apresentaria a seguinte representação visual:

acima apresentaria a seguinte representação visual: Ilustração 13: Representação Visual de um Array. Fonte:

Ilustração 13: Representação Visual de um Array. Fonte: Boratti. adaptado por Kaléu Caminha

4.1.1.3 Pontos Fracos

4.2.1.3.1 Início pelo método main com Hello World

Após os dois primeiros capítulos de introdução, com uma explicação detalhada e

abrangente sobre orientação a objetos e o processo de modelagem, o primeiro programa

mostrado tem como problema “Imprimir uma linha na tela” e o seguinte código-fonte:

public class Programa1

{

//Declaração do método main

public static void main(String[] parametro)

{

System.out.println(“Primeiro Programa!”);

}

}

O programa que resolve este problema não envolve a criação de nenhum objeto, e o único método chamado é um método acessado através de um atributo estático da classe System, usando notação de ponto.

E isto é feito dentro do método main, um método estático que exige como parâmetro um array de strings, conteúdos que somente serão trabalhado nos capítulos sete e oito.

É evidente que esta abordagem se torna necessária na medida em que Boratti, por não adotar nenhuma ferramenta que suporte a execução de código sem a criação do método main, não tem saída a não ser iniciar por ele.

Esta abordagem porém, não é interessante pois a primeira porção de código que o estudante enxerga é algo absolutamente incompreensível para ele, devido a grande quantidade de conceitos envolvidos (Kolling e Rosemberg).

4.2.1.3.2 Primeiro o código, depois o conceito

Em diversos exemplos, certas regras de sintaxe são apresentadas, cujos conceitos envolvidos somente são trabalhados em seções ou capítulos posteriores.

Um exemplo é a primeira classe com a qual os alunos tem contato. A classe Círculo, apresentada como o terceiro trecho de código com o qual os estudantes tem contato.

public class Circulo

{

//Declaração do atributo protected double raio;

//Declaração dos métodos public Circulo()

{

raio = 0.0;

}

public double forneceArea()

{

double area; area = 3.1415*raio*raio; return area;

}

public void recebaValorRaio(double vRaio)

{

}

}

raio = vRaio;

Esta classe apresenta mais de 10 conceitos: comentários, declaração de atributos, tipagem de variáveis, declaração de método com retorno, declaração de método sem retorno, declaração de um construtor, assinatura de classe, parâmetros, atribuições, operações matemáticas e uso de modificadores de acesso.

A maioria destes conceitos só serão trabalhados posteriormente, por exemplo, atribuições serão detalhadas no capítulo 4 enquanto modificadores de acesso somente serão vistos no capítulo 5.

Percebe-se que esta abordagem tem como intenção demonstrar a modelagem completa de uma classe adequadamente escrita para resolver um problema. Isto fica claro pelo uso de modificadores de acesso desde o início, com a intenção de evitar que estudantes declarem atributos como públicos.

Isto causa, porém, uma sobrecarga de conceitos apresentados sem a devida possibilidade do estudante experimentar cada um deles e suas consequências para o programa, sem saber qual a função de cada palavra-chave.

4.2.1.3.3 Métodos estáticos desde o início

Para complementar o exemplo do capítulo 3 no qual é preciso determinar a área de um círculo a partir do seu raio, é apresentada uma classe chamada Interface (que não tem nenhuma relação com o conceito de interfaces em Java) responsável por solicitar ao usuário um número que irá representar o raio do círculo.

O principal método desta classe chamado “pegaValorRaio” contém 4 linhas, conforme apresentado abaixo:

String valorLido; valorLido = JoptionPane.showImputDialog(“Digite o raio: ”); double valor = Double.parseDouble(valorLido); return valor;

O problema deste método é que as principais instruções são métodos estáticos de

classes específicos da biblioteca do Java. Isso nada ensina sobre orientação a objetos,

sendo necessários apenas para que o programa seja minimamente interessante.

Construções como esta são utilizadas em outros pontos como no capítulo 4 com o uso do método sqrt da classe Math, responsável por recuperar a raiz quadrada de um número.

A grande crítica a esta abordagem é que métodos e atributos estáticos são

ensinados apenas no capítulo 8, de modo que o estudante precisa simplesmente ignorar o fato da sintaxe ser diferente de outros objetos com os quais ele trabalha.

O autor já presenciou, como professor, estudantes que foram ensinados sob metodologias parecidas chamando métodos diretamente das classes, sem diferenciar se um método era ou não estático.

4.1.1.4 Conclusão

A metodologia se mostra muito interessante ao tornar claro para o estudante o

processo de construção de um software, a sua respectiva modelagem de objetos e

classes e as diversas representações visuais do programa.

Também se mostra interessante a forma de abordar os conceitos sempre que possível a partir de problemas do mundo real. Observa-se porém que a complexidade dos problemas tratados é muito pequena como por exemplo, calcular a média de um grupo de alunos ou determinar a área de um círculo.

Um dos motivos para o uso de exemplos triviais é a dificuldade em utilizar recursos avançados de programação em função da complexidade destes recursos conforme apresentado pela linguagem Java. De forma mais clara isto é visto na modelagem da classe Interface que para recuperar um valor digitado pelo usuário precisa de métodos estáticos logo no início da metodologia.

Este ponto ressalta que alguns dos pontos fracos observados na metodologia poderiam ser melhor trabalhados com o apoio de um ferramental adequado como um editor que não exigisse a criação de um método main para executar código ou uma ferramenta que permitisse executar métodos diretamente dos objetos.

4.1.2 David J. Barnes e Michael Kölling

“Partindo de Objetos em Java”. Esta é a primeira frase do livro-texto para a

metodologia. A metodologia utiliza o ambiente de programação BlueJ e possui como algumas de suas linhas guia:

Uma abordagem iterativa: A partir do uso do padrão “Early Bird”, documentado na seção 2.4 os principais conceitos são apresentados primeiro de uma forma simplificada para que um determinado problema seja resolvido. Posteriormente no curso, os mesmos conceitos são retomados segundo outro ponto de vista e o conhecimento é aprofundado;

Sem completa cobertura da linguagem: em função do foco do livro ser em POO, detalhes específicos da linguagem java não são abordados a menos que sejam necessários para a resolução de um determinado problema;

Abordagem baseada em projeto: ao invés de introduzir uma nova construção e então fornecer exercícios para aplicar a construção aprendida, primeiro é fornecido um objetivo e um problema. A análise do problema determina o que será necessário e então, os recursos da linguagem e os conceitos são apresentados;

Sequencia dos conceitos em vez de construções de linguagem: é preferível, sempre que existe conflito entre trabalhar construções de linguagem ou os conceitos, trabalhar os conceitos e o mínimo possível das construções de linguagem que auxiliem a implementar o conceito.

A metodologia está organizada em duas partes: 1) Fundamentos da Orientação a Objetos e 2) Estruturas de aplicação. Na primeira parte são abordados os conceitos básicos como classes, objetos, métodos, etc. Na segunda, conceitos importantes para o desenvolvimento de aplicações e reuso como herança, polimorfismo e interfaces são abordados.

O livro-texto da metodologia possui 13 capítulos, sendo os 7 primeiros reservados para a primeira parte e os seis últimos para a segunda. O último capítulo é reservado para um estudo de caso de uma aplicação de maior porte.

Segue abaixo descrição dos exemplos e conteúdos trabalhados em cada capítulo:

Capítulo

Exemplos de Projetos Desenvolvidos

Principais Conceitos abordados

Capítulo 1

Objetos e

Classes

Capítulo 2

Entendendo as

definições de

classe

Capítulo 3

Interação entre

objetos

Capítulo 4

Agrupando

objetos

Capítulo 5

Comportamento

mais sofisticado

Capítulo 6

Objetos bem-

comportados

Capítulo 7

Design de

Classes

Capítulo 8

Herança

Desenhos simples de algumas formas

geométricas;

Exemplo utilizando um objetos do projeto

anterior para desenhar uma figura;

Exemplo simples com classes de alunos que participam de aulas de laboratório.

Simulação uma máquina de vender bilhetes de trem;

Armazenamento de informações sobre um livro.

Implementação de um mostrador de um

relógio digital com horas e minutos;

Uma simulação simples de um correio eletrônico.

Implementação simples de um bloco de

anotações eletrônico;

Um sistema de leilão;

Um analisador de registros de acesso a uma página web.

Implementação de um programa de diálogo

semelhante ao Eliza utilizado para fornecer um

“suporte técnico” para clientes;

Animação gráfica com bolas que quicam.

Estágios iniciais de um diário que armazena compromissos;

Implementação de uma calculadora de mesa;

Um jogo iterativo de aventura baseado em texto;

Métodos;

Parâmetros.

Objetos;

Classes;

Construtores;

Parâmetros;

Campos;

Métodos de acesso e

modificadores;

Atribuição e instrução condicional.

Modularização;

Criação de objeto;

Diagramas de objeto;

chamadas de método;

depuradores.

Coleções;

Arrays;

Loops.

Abstração;

Iteradores;

Utilizando classes de

biblioteca;

Lendo a documentação;

Escrevendo a

documentação.

Depuração;

Automação de testes.

Design baseado na

Testes;

responsabilidade;

 

Acoplamento;

Coesão;

Refatoração.

Um banco de dados de CDs e vídeos;

Herança;

 

Subtipagem;

Substituição;

Variáveis polimórficas.

Mais sobre

Continuação do banco de dados de CDs e

herança

vídeos do capítulo 8;

Capítulo 10

Uma simulação de caçador-caça conhecida como

Técnicas

“raposa-coelho”.

adicionais de

abstração

Capítulo 11

Implementação de um catálogo de endereços;

Tratamento de

erros

Capítulo 12

Sistema de reserva de lugares em um cinema;

Design de

aplicações

Capítulo 13

Combinação de um sistema de reserva de

Estudo de caso

táxis com um sistema de gerenciamento e de

simulação.

tipo estático e dinâmico;

Sobrescrição;

Escolha dinâmica de método.

Classes abstratas;

Interfaces.

Programação defensiva;

Lançamento e tratamento de exceção;

Informe de erro;

Processamento de

arquivos simples.

Descobrindo classes;

Cartões CRC;

Padrões;

Design de interfaces.

Desenvolvimento integral de aplicação.

Tabela 6: Conteúdos e exemplos da metodologia de Barnes

4.1.2.1 Diretrizes

De forma complementar, para que obtenha uma boa compreensão da metodologia,

segue-se o trabalho de KÖLLING e ROSENBERG, que, a partir da experiência com o

desenvolvimento de diversos cursos utilizando o ambiente BlueJ elencaram oito diretrizes

adequadas para o ensino de programação orientada a objetos:

4.1.2.1.1 Objetos primeiro

É consenso entre muitos professores de Programação Orientada a Objetos que é

melhor ensinar a criar e manipular objetos antes de qualquer outra coisa. Esta atividade,

porém, é difícil nos ambientes tradicionais, pois para executar o método de um objeto é

preciso:

1. Uma classe contendo um método main estático com um array de Strings como

parâmetro;

2. Uso de uma variável tipada;

4.

A instanciação de um objeto;

5. A sintaxe de chamada de um método;

6. A visualização do resultado da chamada do método.

Com BlueJ a primeira atividade é abrir um projeto existente e criar objetos a partir das classes, em seguida, os estudantes podem chamar métodos destes objetos e visualizar seu estado. Tudo isso sem escrever nenhuma linha de código.

4.1.2.1.2 Não inicie com uma tela em branco.

Um dos maiores erros em programação OO é iniciar com uma tela vazia.

Escrever projetos OO envolvem a definição de quais classes o programa terá e quais métodos cada classe deverá ter, e este, é um exercício extremamente difícil para estudantes novatos.

Ao invés disso, pode-se iniciar com pequenas modificações e adições em código existente.

4.1.2.1.3 Leia código

Muitos

estudantes

são

forçados

a

começar

a

programar

sem

terem

lido

praticamente nenhum código. Isso não acontece em nenhuma outra disciplina.

Estudantes aprendem mais quando tem acesso a códigos bem escritos que eles possam utilizar como base para os seus projetos.

4.1.2.1.4 Use projetos grandes

Programas curtos dificilmente deixam claro as vantagens em se utilizar Orientação a Objetos.

A sugestão é que sejam utilizados programas bem escritos com um número maior de classes e métodos que permitam aos estudantes compreenderem as vantagens do uso de OO, assimilarem a importância de um código limpo e comentado, pratiquem a leitura de código e estudem a interação entre as classes.

4.1.2.1.5 Não inicie com o método main

O método main exige muitos conceitos para ser compreendido. O ideal é que os estudantes só sejam apresentados a ele após terem se envolvido com os conceitos principais como a criação de objetos e chamada de métodos.

4.1.2.1.6

Não use “Hello world”

Para se fazer um “Hello World” em Java é preciso iniciar do método main, que por sua vez significa: 1) construir uma classe da qual nenhum objeto é criado. 2) construir um método (o main) que não age sobre um objeto.

Isso não é Programação OO e fere outras diretrizes já apresentadas.

4.1.2.1.7 Mostre a estrutura do programa

Classes e seus relacionamentos são muito importantes. É essencial que os estudantes possam visualizar a estrutura dos programas nos quais trabalham.

O BlueJ exibe a estrutura do programa em um diagrama semelhante ao diagrama

de classes da UML. Quando o BlueJ não estiver sendo utilizado é importante que o

professor encontre meios de mostrar claramente esta estrutura.

4.1.2.1.8 Tenha cuidado com a interface do usuário

É importante ensinar uma forma de realizar a interface com o usuário para

fornecimento de parâmetros e para a impressão de resultados do software.

Em Java, podemos fazer isso com Applets, com a API de entrada e saída ou com frameworks GUI como o Swing.

Porém, nenhuma destas alternativas é simples o suficiente para ser utilizada em cursos introdutórios. São sugeridos então, dois caminhos para lidar com este problema:

1. Específico no BlueJ, são as janelas pop-up que solicitam ao usuário os valores para os parâmetros dos métodos e as janelas que exibem os retornos dos métodos;

2. Um projeto maior com classes que encapsulem a interface com o usuário e que os estudantes apenas precisem aprender a utilizar seus métodos.

4.1.2.2 Análise geral do método

Não é sem mérito que esta metodologia está sendo adotada por um grande número de instrutores de programação orientada a objetos em todo o mundo. Sem dúvida que a metodologia trouxe grandes contribuições e dentre os pontos fortes podemos destacar: 1) a abordagem baseada em projetos que permite ao estudante aprender a resolver problemas; 2) a priorização do conceito antes das estruturas de construção da linguagem, dando sentido ao que o aluno está aprendendo; 3) O rico acervo de projetos trabalhados, trazendo diversas dimensões importantes da computação; 4) O uso do Bluej que permite que se inicie a tarefa de ensinar diretamente através de objetos e escrita de seus

métodos.

Além destes, na prática com a metodologia foi possível perceber que os estudantes

que em geral possuem mais dificuldade com programação se sentiam mais seguros e

confiantes ao verem os objetos na tela e poder manipulá-los. É visível que muitos alunos

não se sentem a vontade quando se deparam diariamente nas aulas de programação

com telas repletas de código-fonte, sem outras representações visuais do trabalho que ele

está realizando.

4.1.2.3 Pontos fracos

Apesar do inúmero sucesso, é importante ressaltar algumas dificuldades geradas

pela metodologia. Estas dificuldades foram percebidas em prática do autor com a mesma

e através da pesquisa de Xinogalos.

4.1.2.3.1 Ênfase nas técnicas de visualização e manipulação direta do BlueJ

Em função do BlueJ disponibilizar interface gráfica para instanciação de objetos e

chamada de métodos, alguns alunos ficam por demais “acomodados” a esta maneira de

trabalhar, o que gera dificuldades com instanciação de objetos e chamadas de métodos

direto do código-fonte. Isso porque no BlueJ, a diferença entre a forma de manter objetos

em variáveis e chamar métodos destas variáveis (Ilustração 14) é muito diferente da

forma como a mesma ação é feita no BlueJ (Ilustração 15).

como a mesma ação é feita no BlueJ (Ilustração 15). Ilustração 14: Instanciação de objeto e

Ilustração 14: Instanciação de objeto e chamada de método em código

14: Instanciação de objeto e chamada de método em código Ilustração 15: Objetos na bancada de

Ilustração 15: Objetos na bancada de objetos (em vermelho) e chamada de método de um objeto

Outra crítica é a que métodos que possuem retorno são chamados da mesma forma que métodos sem retorno. Esta questão causa confusão ao tentar passar para os estudantes que métodos com retorno devem ser sempre atribuídos a uma variável. Métodos com retorno, no BlueJ, imprimem o valor retornado na tela. Quando, posteriormente o autor trabalhou métodos com retorno sem o uso do BlueJ, uma das dúvidas apresentas foi questionando se, quando se retornava um valor, este valor não deveria ser impresso na tela?

4.1.2.3.2 Ênfase em projetos existentes

Em função da utilização de projetos com uma boa quantidade de código pronto, a dificuldade em iniciar projetos do zero se mostrou muito maior. Além disso, métodos get e set, bem como construtores, são geralmente fornecidos pelos projetos e os alunos raramente os implementam.

4.1.2.3.3 Ensino posterior do método main:

O ensino apenas no final do curso do método main exige que os alunos utilizem apenas o BlueJ para testar código, potencializando as dificuldades comentadas no item 1.

4.1.2.4 Conclusão

Percebe-se que o BlueJ apesar de suas inúmeras qualidades, não pode ser visto como a única solução, pois, em concordância com Xinogalos, “mais de uma ferramenta é necessário para suportar as diferentes necessidades cognitivas no ensino de programação”, de modo que esta metodologia apesar de sua qualidade, pode ser complementada com atividades e práticas em ambientes profissionais de desenvolvimento.

4.1.3 Bruno Feijó et al

A metodologia apresentada por Feijó visa segundo ele próprio “apresentar os conceitos e os bons hábitos da arte de programar”. Seu material aborda não apenas a programação orientada a objetos mas também a programação estruturada e brevemente a programação guiada a eventos.

Apesar do foco não ser orientação a objetos, sua metodologia e o framework que o

acompanha serviram de base e inspiração para a metodologia descrita no capítulo três e consequentemente, base e inspiração para o presente trabalho.

O livro-texto da metodologia apresenta 9 capítulos que segundo sugestão da metodologia poderia ser trabalhado em uma disciplina de 64 h/aula em 16 aulas de 4 h/aula cada, conforme modelo abaixo:

Semana 1: apresentação e capítulo 1;

Semana 2: Capítulo 2;

Semana 3: Capítulo 3;

Semana 4 a 6: Capítulo 4;

Semana 7: Capítulo 5;

Semana 8: Capítulo 6;

Semanas 9 a 11: Capítulo 7;

Semanas 12 a 14: Capítulo 8;

Semanas 15 e 16: Capítulo 9;

Segue abaixo organização dos capítulos, exemplos e conteúdos apresentados.

Capítulo

Exemplos de Projetos Desenvolvidos

Principais Conceitos abordados

Capítulo 1

Computadores

Capítulo 2 Variáveis, Tipos de Dados e Expressões

Capítulo 3

Controles de

Fluxo por

comandos de

seleção

Capítulo 4

Métodos e

Soluções

Capítulo 5 Dados compostos como vetores

Nenhum exemplo trabalhado;

Pequenos exemplos didáticos demonstrando os conceitos;

Pequenos exemplos didáticos demonstrando os conceitos;

Pequenos exemplos didáticos demonstrando os conceitos;

Pequenos exemplos didáticos demonstrando os conceitos;

Capítulo 6 Usando mais objetos e classes simples

Jogo similar ao tradicional Pong;

Capítulo 7

Classes, objetos,

Continuação do jogo similar ao tradicional Pong;

herança

Capítulo 8

Jogo específico desenvolvido para o livro e

Programação

continuação do jogo similar ao tradicional pong;

Gráfica

Capítulo 9 Programação guiada a eventos

Jogo específico desenvolvido para o livro.

Entrada de Dados;

Saída de Dados;

Expressões;

estruturas de tomada de

Comentários;

Variáveis;

decisão if-else e switch.

Métodos;

Métodos Estáticos;

Sobrecarga de métodos;

Loops.

Vetores unidimensionais;

Vetores bidimensionais;

Classes;

Strings;

Leitura e gravação de arquivos;

Classes abstratas e interfaces.

Classes e objetos;

Modificador static;

Encapsulamento;

Herança;

Classes abstratas.

Conceitos de jogos 2D;

Captura de dados do teclado e do mouse.

Tabela 7: Conteúdos e exmplos da metodologia de Feijó

4.1.3.1 Análise geral do método

A proposta é muito abrangente, segundo Feijó, pretende-se do capítulo 1 ao 6 trabalhar com programação estruturada, no 7 e no 8 orientação a objetos e no capítulo 9, programação guiada a eventos.

Em função até mesmo deste grande conjunto de paradigmas, o livro não oferece um bom suporte para os conceitos de orientação a objetos, os exemplos são poucos, muito limitados e as explicações dos conceitos não acompanham boas referências visuais.

Em contrapartida, oferece um rico material sobre como unir conceitos de jogos em duas dimensões com técnicas de programação, tanto estruturada quanto orientada a objetos.

Um grande mérito está no uso do framework para trabalhar classes abstratas e interfaces, pois, para que o aluno possa criar uma fase, deve implementar uma interface e para criar um objeto no jogo, deve estender uma classe abstrata que já fornece os atributos de posicionamento de um objeto na tela.

4.1.4 Stelios Xinogalos

Ao fim de 4 anos de avaliações e modificações, Xinogalos chegou a uma metodologia que utiliza três ambientes de programação: objectKarel (Satratzemi), BlueJ e Jcreator (um ambiente profissional de programação simplificado). O material didático utilizado é baseado no material que acompanha o objectKarel e na metodologia de Barnes com o BlueJ, descrita na seção 2.4.2.

O curso estruturado por Xinogalos possui 12 lições de 4 horas aula semanais, duas teóricas e duas em laboratório. As aulas são divididas na seguinte estrutura:

Aula

Temas trabalhados

Ambiente

1

Objetos, classes, herança: objeto, construção e inicialização de um objeto, mensagens/métodos, atributos e comportamentos de um objeto, herança, superclasse, subclasse, hierarquia de herança, diagrama de classe UML

objectKarel

2

Herança em vários níveis, polimorfismo e sobrescrita.

objectKarel

3

Definição de Classe: campos, construtores, métodos de acesso, métodos modificadores, estrutura de retorno, parâmetros, escopo de variáveis, estruturas condicionais.

BlueJ

4

Interação com objeto: abstração, modularização, objetos criando objetos, múltiplos construtores, diagrama de classe, diagrama de objetos, tipos primitivos, tipos de objetos, chamadas de métodos internos e externos.

BlueJ

5

Métodos estáticos: métodos de instância vs métodos de classe, o método main, execução sem o BlueJ, byte code, Java Virtual Machine.

BlueJ, JCreator

6, 7

Agrupando objetos em coleções: Coleções de tamanho flexível (ArrayList), coleções de tamanho fixo (arrays), classes genéricas, iteradores, loops (while, for, for-each).

BlueJ, JCreator

8

Usando bibliotecas de classe: Classes padrão do Java, leitura de documentação, interface vs implementação de uma classe, explorando e usando classes (HashMap, Random, HashSet), modificadores de acesso (public, private), informações escondidas, variáveis de classe (estáticas).

BlueJ, JCreator

9

Projeto de Classes: acoplamento, coesão, encapsulamento, duplicação de código, projeto dirigido à responsabilidade, reuso de código.

BlueJ, JCreator

10

Melhorando a estrutura com herança: hierarquia de classes, superclasse, subclasse, construtor da superclasse, “subtyping”, substituição, “autoboxing”.

BlueJ, JCreator

11

Polimorfismo, sobrescrita: tipos dinâmicos e estáticos, busca dinâmica de método, super, acesso protegido.

BlueJ, JCreator

12

Classes abstratas e Interface.

BlueJ, JCreator

Tabela 8: Conteúdos e ambiente de programação na metodologia de Xinogalos

4.1.4.1 O Uso de ambientes de programação

A escolha do ambiente de programação que será utilizado é difícil e importante.

Ambientes profissionais são inadequados para trabalhar aspectos introdutórios,

ambientes de micro-mundos como o objectKarel são interessantes para trabalhar

conceitos mas não uma linguagem específica, já ambientes educacionais são

interessantes para transferir os conceitos para uma determinada linguagem, porém, sem

a transição para uma IDE profissional os estudantes ficam condicionados às

características específicas das ferramentas educacionais.

A dinâmica de 4 anos no curso apresentado mostrou que mais de uma ferramenta é necessária para que os diversos aspectos cognitivos possam ser trabalhados. Esta dinâmica gerou as seguintes diretrizes sobre o uso de ambientes de programação:

Use um ambiente de micro-mundo para uma introdução curta dos principais aspectos de programação orientada a objetos: o ambiente escolhido deve suportar o ensino dos principais conceitos de OO sem preocupações com a sintaxe. O conceito de objeto deixa de ser abstrato pois agora os objetos podem ser manipulados, os estudantes também ganham confiança na sua capacidade de programação;

Use um ambiente educacional para apresentar os conceitos vistos no micro- mundo para a sua implementação em Java: a transição para um ambiente educacional é mais suave do que para um ambiente profissional pois ambientes específicos para o ensino eliminam a complexidade permitindo que os estuantes possam se dedicar a sintaxe dos conceitos fundamentais. É essencial que estes ambientes tenham ferramentas de visualização e manipulação direta de classes e objetos e permitam a invocação dinâmica de métodos. O tempo com o um ambiente educacional não deve se estender muito para evitar falsas percepções, principalmente sobre os aspectos dinâmicos da Orientação a Objetos.

Use um ambiente profissional para prepará-los para o futuro: É inevitável que esta transição aconteça, a maior preocupação deve ser quando realizá-la. Neste curso foi decidido realizar esta transição na quinta lição dando ênfase para as características destes ambientes que poderiam ajudar os estudantes como 1) Visão das classes em árvore; 2) Navegação rápida dentro de uma classe; 3) auto- completar de código; 4) o destaque de sintaxe. Ao realizar esta transição os estudantes se sentem mais confiantes com o seu conhecimento.

4.1.4.2 Diretrizes para o Ensino das lições propostas

As lições são baseadas como já mencionado no livro-texto que acompanha o BlueJ., seguindo suas principais diretrizes.

Concomitantemente, é utilizada a abordagem “modelo primeiro” de Bennedsen e Caspersen (2004) conforme documentada na seção 4.1.5.

Abaixo, seguem as diretrizes relacionadas a cada lição trabalhada. As lições utilizam projetos do livro-texto que acompanha o BlueJ.

4.1.4.2.1 Lição 1: Objetos, classes e herança no objectKarel

Na primeira lição, são apresentados os conceitos básicos de classe, objeto e método. Os estudantes iniciam criando um novo objeto da classe “Robo” com a ajuda da interface Gráfica (Ilustração 16), depois, devem utilizar os métodos do robô (como “mover”, “virar para a esquerda”, etc) para realizar tarefas específicas como completar um determinado percurso.

tarefas específicas como completar um determinado percurso. Ilustração 16: Instanciação de um objeto no objectKarel

Ilustração 16: Instanciação de um objeto no objectKarel com a ajuda da interface gráfica

O programa vai sendo construído a partir de botões onde o estudante seleciona os métodos que irá executar, criando uma sequencia que no objectKarel é chamada de tarefa (Ilustração 17).

Ilustração 17: Criação de uma tarefa a partir dos métodos de um robô Após, podem

Ilustração 17: Criação de uma tarefa a partir dos métodos de um robô

Após, podem executar o programa e observar qual o comportamento do robô para

cada método e o que isso significa na linguagem dos robôs (por exemplo, virar para a

esquerda significa mudar a frente do robô em 90 graus negativos.), estas informações são

fornecidas na forma de texto no rodapé do ambiente (Ilustração 18).

na forma de texto no rodapé do ambiente (Ilustração 18). Ilustração 18: Execução de um programa.

Ilustração 18: Execução de um programa. à direita a visualização do robô, à esquerda a lista de tarefas e abaixo a descrição do que ocorre no interior do método em execução.

Em uma segunda atividade, problemas mais complexos são apresentados de modo

que é necessário utilizar herança para a criação de uma nova classe com métodos que

irão facilitar a realização da tarefa.

Xinogalos ressalta que é essencial durante o processo explicar que cada método

muda o estado interno do objeto (mesmo que os alunos não possam ver as variáveis de

instância). Também é importante utilizar exemplos que utilizem vários objetos da mesma

classe para evitar que os estudantes considerem os dois conceitos como a mesma coisa.

4.1.4.2.2 Lição 2: Herança em vários níveis, polimorfismo e sobrescrita.

A didática se mantém a mesma e agora os problemas apresentados exigem a construção de uma hierarquia de classes. Também são utilizados exemplos que trabalhem a necessidade da sobrescrita de métodos como por exemplo, robôs mais velozes que no método “move”, andam mais rápido que os robôs utilizados nos exercícios anteriores. O polimorfismo, também é trabalhado com cuidado por se uma das principais dificuldades observadas nos estudantes.

4.1.4.2.3 Lição 3: Definição de classe

A definição de uma classe é apresentada aos alunos utilizando o exemplo de uma máquina de vender bilhetes (TicketMachine no livro texto que acompanha o BlueJ). Os estudantes criam instâncias desta classe, chamam seus métodos, observam a implementação em Java da classe e por fim, tem a oportunidade de realizar pequenas modificações nela.

No primeiro ano do curso foram identificadas as dificuldades mais comuns referentes ao ensino do paradigma de POO, é importante que o instrutor esteja atento a elas desde o início do ensino para reforçar o entendimento destes tópicos. Segue abaixo as principais dificuldades encontradas:

A compreensão e uso de múltiplos construtores;

O uso do this é de difícil compreensão e em geral os estudantes o evitam;

A inicialização dos campos no construtor;

Costumam declarar o tipo de retorno de métodos “set”;

Tentam acessar valores de campos privados diretamente, sem o uso de métodos get;

Outras dificuldades são atribuídas mais especificamente ao uso dos recursos do BlueJ, são elas:

Não declaração do tipo das variáveis que armazenam os objetos. Isso pode ser trabalhado dando ênfase na janela de instanciação de um objeto à variável onde o objeto será armazenado e o tipo desta variável. O BlueJ já apresenta estas informações, porém, comumente passam despercebidas.

Chamada de métodos. Frequentemente métodos com retorno são chamados da

mesma maneira que métodos void. No BlueJ, é possível chamar ambos os tipos de métodos da mesma forma, de modo qque o resultado de métodos com retorno frequentemente é interpretado como “impressão do valor na tela”;

Por fim, é essencial verificar se os conceitos aprendidos no objectKarel foram efetivamente transportados para o Java. Isso pode ser feito solicitando que os estudantes representem em Java os modelos dos robôs criados nas últimas duas lições.

4.1.4.2.4 Lição 4: Interação entre objetos

Estudantes são apresentados aos conceitos de modularização, abstração e interação entre objetos utilizando o exemplo de um relógio digital com duas classes, uma representando um relógio digital e outra que representa um mostrador de dois números. O Relógio é composto por dois mostradores, um para as horas e outro para os minutos.

As dificuldades observadas nesta etapa foram:

Os estudantes não tem certeza onde devem inicializar os campos;

Não sabem como manipular este novo tipo;

Tem dificuldades com a notação de ponto.

Para estas dificuldades é recomendado o uso de diagramas de objetos e atividades onde os estudantes identifiquem chamadas de método internas e externas;

4.1.4.2.5 Liçao 5: O método main

nesta aula é apresentado como executar código Java sem o BlueJ. Uma introdução sobre uso de métodos estáticos versus métodos de instância é feita utilizando o BlueJ.

Após, os estudantes criam seu próprio método main no Jcreator para um projeto que eles já tenham conhecimento como o TicketMachine.

Esta lição também é aproveitada para falar sobre compilação, “byte code” e máquina virtual.

As principais dificuldades encontradas foram:

Uso de parâmetros formais da chamado do construtor (Ex: new Classe(Type param); );

O tipo das variáveis dos objetos são esquecidos;

Esquecem argumentos em chamadas de métodos;

Esquecem os parênteses em chamadas de métodos sem argumentos;

Para lidar com estas questões é sugerido:

Atividades que são de alguma forma “silenciadas” pelo BlueJ como o tipo das variáveis que armazenam os objetos são demonstrados utilizando as caixas de diálogo do BlueJ e seu paralelo em sintaxe Java;

Exemplos e tarefas são realizados em cima de projetos já conhecidos;

Um programa contendo erros comuns é apresentado e os estudantes são ensinados a reconhecer os erros e tratá-los.

4.1.4.2.6 Lição 6: Agrupando objetos em um ArrayList

Uso de coleções em programação é comum e necessário mesmo em programas de baixa complexidade. Alguns autores já colocam o uso de ArrayList como prioridade sobre Arrays por ser uma estrutura mais adequada para representar listas continuas.

Durante os quatro anos de curso os autores identificaram diversas dificuldades envolvendo o uso de ArrayList`s e chegaram às seguintes conclusões:

1. O uso dos diagramas de objetos são fundamentais desde o início do projeto. Os estudantes são estimulados a criar um diagrama de objetos para um dado programa e simular operações de remoção e inclusão no diagrama de objetos.

2. São oferecidos exercícios para com código incompleto para que os estudantes preencham os espaços vazios com determinados comandos.

3. Após, são construídos programas do zero.

4.1.4.2.7 Lição 7: Agrupando objetos em coleções (ArrayList vs Array)

O uso de Arrays é apresentado e o mesmo projeto no qual foi trabalhado o uso de ArrayList é agora modificado para funcionar com Arrays.

4.1.4.2.8 Lição 8: Utilizando bibliotecas de classe

Nesta aula os estudantes são apresentados à documentação das classes Java, com ênfase nas classes String e HashMap. A aula também apresenta a estrutura de pacotes.

4.1.4.2.9 Lição 9: Projeto de Classes

O projeto de classes é algo difícil de ser realizado e a simples exposição dos principais conceitos teóricos para uma solução bem projetada não causa um grande impacto no aprendizado. É importante que os estudantes entendam através de uma

aplicação os problemas de um mau projeto de classes.

A maior dificuldade encontrada foi a limitação do tempo que impossibilita o

desenvolvimento de uma solução completa, na qual, o entendimento dos principais

conceitos de um bom projeto de classes seria trabalhado.

4.1.4.2.10 Lição 10: Melhorando a estrutura com Herança

O projeto desta lição é uma biblioteca multimídia de CD's e DVD`s. A primeira

versão do projeto não usa herança, de modo que muito código acaba sendo duplicado.

Quando os alunos são perguntados sobre como resolver o problema, eles se recordam da apresentação feita com o objectKarel e facilmente compreendem o uso de herança.

A maior dificuldade percebida é a chamada do construtor da superclasse através da subclasse. Uma sugestão é utilizar o debugger para ver a execução do código passo a passo e os campos sendo preenchidos.

4.1.4.2.11 Lição 11: Polimorfismo e Sobrescrita

Através de uma continuação do exemplo visto anteriormente, é realizado um exemplo onde cada subclasse sobrescreve o comportamento de um método na classe pai.

4.1.4.2.12 Lição 12: Classes abstratas e Interface

Nesta aula o uso de classes abstratas e interface são utilizados para expandir a simulação de um ambiente com raposas e coelhos para conter diversos tipos de animais.

Percebeu-se que não é difícil para os estudantes compreenderem o conceito e o implementarem, porém, demonstram grande dificuldade em perceber quando uma classe deve ser declarada como concreta, abstrata ou interface.

4.1.4.3 Análise Geral do método

As duas principais conclusões de Xinogalos são 1) a necessidade de avaliação continua dos cursos de modo a validar as pesquisas e dar continuidade aos processos de melhoria e que 2) mais de uma ferramenta é necessário para suportar as diferentes necessidades cognitivas no ensino de programação.

O artigo também clarifica como integrar alguns dos diferentes tipos de ambientes

de ensino de programação desenvolvidos até o momento de modo a garantir um ensino

eficaz ao mesmo tempo em que prepara os estudantes para o mercado.

É muito rica a descrição detalhada de todas as aulas realizadas e das principais dificuldades em cada tema, de modo que o instrutor, sabendo de antemão as dificuldades mais comuns, pode atacá-las logo no início das atividades.

A partir do material apresentado não foi possível identificar pontos fracos na metodologia proposta por Xinogalos, na medida em que copia os pontos fortes da metodologia de Barnes e adiciona ela o aspecto de modelagem e uso de ferramentas profissionais de programação.

4.1.5 Michael Caspersen

Caspersen propõe um método baseado muito no fornecimento aos estudantes do modelo conceitual, antes de iniciar a codificação, bem como em um processo sistemático de transformação de um modelo para código-fonte.

Segundo Caspersem, modelagem conceitual é a definição de características de orientação a objetos e provê uma perspectiva unificada e uma aproximação pedagógica com foco sobre o aspecto de modelagem da orientação a objetos.

Esta visão contempla um dos papéis da linguagens de programação segundo Knudsen & Madsen (1988, citado por Caspersen) que é justamente o uso da linguagem de programação para expressar conceitos e fenômenos.

Para que seja possível a sistematização do processo de desenvolvimento, foram identificadas técnicas para a criação sistemática de programas orientado a objetos em 4 diferentes níveis de abstração: