Laboratório de Programação

(1)

Laboratório de

Programação

Dr. Italo Santiago Vega

Curso de Graduação Ciência da Computação

(2)

Calendário

Semana Data Tópico

21 04/08/2004 Milhão da Computação (i) 22 11/08/2004 Milhão da Computação (ii) 23 18/08/2004 Milhão da Computação (iii)

24 25/08/2004 Milhão da Computação (iv). Entrega da A21. I 25 01/09/2004 Milhão da Computação v. 2 (i)

26 08/09/2004 Milhão da Computação v. 2 (ii) 27 15/09/2004 Milhão da Computação v. 2 (iii) 28 22/09/2004 Milhão da Computação v. 2 (iv)

29 29/09/2004 Milhão da Computação v. 2 (v). Entrega da A22. 30 06/10/2004

31 13/10/2004 32 20/10/2004 33 27/10/2004 34 03/11/2004

(3)

Conteúdo

1 Critérios de Avaliação 2

1.1 Quantificação . . . 4

1.2 Penalização após a data de entrega: . . . 6

1.3 Considerações . . . 7

1.4 Estrutura do Documento . . . 9

1.5 Programação em Parceria . . . 12

2 Atividade A2: Milhão da Computação (v. 2) 13 2.1 Meta . . . 13

(4)

1 Critérios de Avaliação

Os seguintes critérios serão utilizados para avaliar os trabalhos de programação.

• A solução proposta atende ao problema apresentado. Especificamente:

– A solução representa, de forma clara, uma idéia que atende aos requisitos

especificados.

– O programa compila e executa.

– Foram elaborados testes que comprovam o atendimento a todos os requisitos

especificados.

– O programa é corretamente executado e passa em todos os testes elaborados.

• A solução constitui um produto de alta qualidade, condizente com o esperado de

(5)

comandos if não triviais, repetições, ativações de operações, etc.) são adequadamente documentados.

– O desenho geral do programa é claro e razoável. Ex.: o programa faz bom uso

das classes e operações; os algoritmos dos métodos são apropriados para a

tarefa e claramente explicados, sendo implementados de forma compreensível. Todas as classes, interfaces e métodos incluiem uma descrição “JavaDoc”

apropriada. Classes devem conter as marcas @autor e @version (utilize a data de escrita do código como valor de versão), juntamente com uma

descrição do que a classe representa e para que ela serve. Métodos devem incluir uma descrição do seu comportamento, juntamente com descrições de cada parâmetro (marca @param) e o valor de retorno, se houver (marca

(6)

1.1 Quantificação

Nota Significado

10 a solução atende a todos os critérios muito bem.

9 a solução não é exatamente a esperada, com erros superficiais 8 a solução atende à maioria dos critérios, mas pode ser melhorada.

6 a solução é satisfatória, atendendo a alguns critérios, mas precisa ser significativamente melhorada.

4 a solução é aceitável; vários critérios não foram atendidos; precisa de muitas melhorias.

(7)

1.2 Penalização após a data de entrega:

15% até a primeira semana posterior à data de entrega. Não serão aceitos trabalhos além desta data de penalização.

(8)

1.3 Considerações

Os alunos às vezes questionam porque um erro, aparentemente pequeno, provoca uma nota baixa. A principal razão é que um sistema de software que não funciona

apropriadamente, mesmo em relação a um pequeno aspecto (em sitações do “mundo real”) pode ter um alto custo ou serem até mesmo perigosos para os usuários. Uma parcela grande do alto custo de um software é decorrente da dificuldade de alteração para as empresas que o desenvolvem.

Muitos contratantes de profissionais de software exigem altos padrões de qualidade. É importante entender que “quase certo” não é o suficiente para a maior parte dos

contratantes. Além disso, do ponto de vista profissional, o “quase certo” não deveria ser bom o suficiente para o programador, mesmo atendendo às expectativas do

(9)

Assim, um erro que impede o funcionamento do programa (especialmente se ele sequer compila) pode resultar em uma redução volumosa da nota. Assim,

recomenda-se continuar trabalhando no programa, mesmo que a data de entrega esteja vencida, recebendo uma penalidade por atraso, do que submeter a avaliação de um programa inaceitável.

Em atividades que envolvem diversos alunos, todos devem estar de acordo com o trabalho entregue. Quaisquer discordâncias ou sitações extraordinárias serão tratadas diretamente pelo professor.

(10)

1.4 Estrutura do Documento

Deverá ser entregue um documento com a seguinte estrutura na data de entrega da avaliação (as páginas do trabalho deverão ser numeradas):

(11)

1. Capa

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO LABORATÓRIO DE PROGRAMAÇÃO - LP, 2004

Atividade= A2, Milhão da Computação

Turma = C22

Time= 22-<número indicado em aula> <INSCRIÇÃO>; <Nome do Aluno>

Professor= Ítalo

Data de Entrega= <a ser preenchido na entrega do documento>

(12)

2. Programação Texto descrevendo o as classes (ilustrações do BlueJ), os métodos (ilustados com mapas de execução) e outros elementos relevantes.

3. Testes e Resultados Texto descrevendo, para cada serviço oferecido pelo sistema para o usuário, o respectivo teste de aceitação.

Também, para funcionalidade interna relevante, o respectivo teste de aceitação.

4. Programa Texto do programa entregue (devidamente comentado com as marcas JavaDoc).

5. Sugestões (NÃO SERÃO CONSIDERADAS DURANTE A AVALIAÇÃO.) Sugestões para melhorias futuras desta atividade para que haja um melhor

(13)

1.5 Programação em Parceria

Programação em parceria é uma idéia relativamente nova para aumentar a

produtividade e qualidade no desenvolvimento de sistemas de software. Nas aulas de laboratório existe uma sugestiva evidência que a programação em parceria aumenta as notas (mesmo em avaliações teóricas), diminui a frustração dos alunos e melhora a taxa de sucesso dos times com parceiros em dificuldades.

O trabalho em parceria segue algumas regras que organizam a dinâmica de

programação. Um dos parceiros será o piloto, responsável pelo uso do teclado, escrita de notas e elaboração de desenhos. O outro será o navegador, observando o trabalho do piloto, procurando defeitos de software (erros sintáticos, lógicos, etc.), questionando sobre o desenho proposto e sugerindo caminhos alternativos. É importante lembrar que

(14)

2 Atividade A2: Milhão da Computação (v. 2)

Data de Entrega: 30/09/2004

2.1

2.2 Parte I: Programação

Escrever o programa que permita jogar o Milhão da Computação.

Estrutura Inicial de Classes Como ponto de partida para a organização dos

(21)

Bases de perguntas do jogo representadas por três objetos

da classe Hashtable. Histórico de perguntas já formuladas. As perguntas são armazenadas em um objeto da classe Stack.

Cada nível deverá solicitar que a respectiva base de perguntas “sorteie” as suas cinco perguntas.

Cada nível deve informar para o objeto histórico, a pergunta formulada e a alternativa correta. Cada nível do

jogo deve ser armazenado em

um objeto da classe Vector.

(22)

Sugestões:

• Criar as variáveis baseFacil_, baseMedio _e baseDificil _{da classe} BasePerguntas _{na classe} Jogo_.

• Criar as variáveis acil_, medio _e dificil _{da classe} Nivel _{na classe} Jogo_. • Criar a variável atual:Pergunta _{na classe} Jogo_.

• Criar a variável acumulado:int _{na classe} Jogador_. • Crar a variável aposta:int _{na classe} Nivel_.

• Crar a variável perguntas:Vector _{na classe} Nivel_.

• Crar a variável alternativas:Vector _{na classe} Pergunta_.

(23)

2.3 Parte II: Testes

Criar testes que mostrem o correto funcionamento do jogo implementado. Os papéis devem ser trocados nesta parte: piloto e navegador.

Sugestões:

• Criar uma classe para a realização de testes: TesteMilhao.

• Inserir um método para cada aspecto relevante dos comportamentos interno e

externo esperados do sistema. Ex.: comportamentos externos: testar formulação de pergunta, testar desistência, testar acerto, testar troca de nível, etc.

Comportamentos internos: testar cálculo da aposta, testar leitura do

arquivo-questionário, etc. Cada um destes métodos deverá instanciar o universo apropriado de objetos para que seja realizado.

(24)