Pug2009 documento final

Prêmio Universitário Felipe
Gaúcho 2009

Aproximando a academia e o mercado
Java do Ceará

Fortaleza - Ceará
Julho de 2010

Prêmio Universitário Felipe Gaúcho 2009 CEJUG, Página 1

"Se eu enxerguei longe, foi por ter subido nos ombros de gigantes.”

– Isaac Newton


Índice

Patrocínio
4
Mudança do nome
5
O que é?
6
O que mudou no PUG 2009?
7
Critérios de avaliação
8
Banca avaliadora
11
Alunos x Instituições
17
Avaliadores x Estados
18
Trabalhos
19
Trabalhos
20
Trabalhos
21
Classiﬁcação ﬁnal do PUG 2009
22
Avaliações
23
Pespectivas para o PUG 2010
82
Veracidade do documento
83


Patrocínio

USIX Technology IVIA
Empresa cearense que tem como Fundada em 1996, a IVIA é uma
foco o mercado de seguradoras, empresa especializada em T.I,
atuando com desenvolvimento atuando com software e serviços.
de software. Certiﬁcada CMMI 2, MPS.BR E.

Fortes Informática Atlântico
Empresa pertencente ao Grupo É uma instituição de P&D que
Fortes, 20 anos de atuação em provê soluções tecnológicas que
T.I, desenvolvendo softwares nas geram valor em forma de
áreas contábil, RH, etc. inovação.


Mudança do nome

Em virtude do falecimento do Felipe Gaúcho, no dia 06 de março
deste ano, a coordenação do CEJUG, em conjunto com seus
conselheiros, alterou o nome do PUJ - Prêmio Universitário Java - para
PUG - Prêmio Universitário Felipe Gaúcho, a ﬁm de homenagear e
imortalizar o criador do programa.

Felipe Gaúcho, 1969 - 2010


O que é?

Um dos objetivos do PUG é promover a sinergia entre academia e
mercado de TI, permitindo que a produção universitária receba a
avaliação de experientes proﬁssionais de mercado. Esta avaliação, mais
do que premiar um aluno, revela o quão próximo da realidade de
mercado estão os cursos de graduação em TI no Ceará.

O CEJUG não interfere nas notas e comentários entregues pelos
avaliadores. Todas as informações fornecidas pelos avaliadores foram
compiladas para facilitar a leitura dos dados e também para preservar
os endereços de contato dos avaliadores.


O que mudou no PUG 2009?
‣ Categoria Mobile - uma categoria especial Java ME (Micro Edition) - a
Sagarana está patrocinando uma categoria piloto em tecnologias JME. Esta
categoria será avaliada para a inclusão oficial do JME no PUG a partir de sua
quarta edição.

‣ Ranking CEJUG - a partir desta edição o PUG terá um ranking por
universidades e por professores.

‣ Limite de trabalhos, que agora passa a ser no máximo 25 - para garantir a
qualidade das avaliações. Se o número de submissões exceder este limite,
uma banca especial escolherá os vinte cinco melhores trabalhos para a
competição.

‣ Trabalhos em grupo passam a ser aceitos, mas o prêmio vai apenas para 1
aluno - o professor deve indicar na submissão quem é o autor principal do
trabalho.

‣ Um aluno pode competir com apenas um trabalho - o aluno não pode
submeter dois trabalhos no mesmo PUG.

‣ Professores não podem avaliar trabalhos das instituições de ensino onde
trabalham.

‣ Alunos não podem avaliar trabalhos de alunos da mesma instituição onde
estudam (seu colegas de faculdade).

‣ A melhor e a pior nota dos alunos serão eliminadas da competição, que terá
a média final calculada por média harmônica com duas casas decimais. A
nota mínima dos trabalhos será 1.00 e a nota máxima 10.

‣ As notas submetidas pelos avaliadores serão comparadas com as médias
finais dos alunos, revelando quão longe da média cada avaliador ficou para
cada trabalho. A idéia é extrair automaticamente dos resultados finais os
avaliadores mais regulares da competição - um bom feedback aos avaliadores.

‣ Teremos prêmios para os 5 melhores trabalhos, e 1 prêmio para o professor
do trabalho vencedor. Além disso, todos os participantes receberão
certificados de participação no PUG 2009 (PDF assinado pelo Footprint).


Critérios de avaliação

Uma caraterística em jovens estudantes é associar a qualidade do
que produzem a critérios individuais, associando a nota que recebem
em pequenos detalhes – um ponto para pontualidade, um ponto para
apresentação, outra para documentação, etc. Apesar de ser prática
comum no ensino fundamental e ainda existir na avaliação de trabalhos
em cursos de graduação, esta barganha de qualidade não sobrevive no
mercado de software e não é prática comum nas empresas de
Tecnologia da Informação.

Quando empresas entregam produtos a clientes, o primeiro impacto
sempre revela a satisfação do cliente com o produto que ele comprou, de
acordo com a expectativa do contrato firmado entre o consumidor e o
fornecedor. Se o cliente não ficar satisfeito com o resultado, dificilmente
o fornecedor do software irá convencêlo a mudar de opinião por
detalhes internos da aplicação. No mercado de TI, os conceitos de bom e
ruim sempre prevalecem sobre o detalhamento do que foi feito, e
reconhecer este valor de mercado é um aprendizado duro que o aluno
pratica ao competir no PUG. Baseado nesta premissa, o PUG procura
renomados profissionais no mercado de TI e concede a estes
profissionais o privilégio e a responsabilidade sobre a avaliação dos
trabalho apresentados pelos alunos. Acreditamos fielmente que a visão
de profissionais com vários anos de experiência no mercado de software
é mais do que suficiente para uma avaliação justa de trabalhos
acadêmicos. O CEJUG procurou também convidar para o PUG 2008
diversos profisionais de fora do Estado do Ceará, reforçando a
imparcialidade na avaliação dos trabalhos – uma vez que a maioria
destes profissionais não conhece as universidades e os alunos
participantes do prêmio.

Além de profissionais, os alunos competidores e seus professores
também participam da avaliação processo conhecido como revisão aos
pares – pois acreditamos que ao avaliarem seus colegas os alunos
amadurecem o senso crítico sobre qualidade de software e reconhecem
em seus pares o contexto universitário onde estão inseridos. Os
professores, por sua vez, avaliam a qualidade de software sob a ótica
acadêmica, identificando o potencial educacional dos enunciados e o
aprendizado dos alunos durante a execução dos trabalhos.


Apesar do PUG concentrar a qualidade das avaliações na qualidade
das pessoas, os avaliadores receberam como sugestão a lista de critérios
abaixo. * Nenhum avaliador foi obrigado a seguir estes critérios, foram
apenas sugestões, linhas gerais.

‣ Avaliação independente de tecnologias específicas: o avaliador deve
evitar ao máximo associar as tecnologias utilizadas para realizar o
trabalho à qualidade do trabalho. Trabalhos realizado com Swing/AWT,
Servlet/JSP ou EJB3/JPA devem sofrer o mesmo olhar crítico, sem
nenhuma qualificação a priori. O que está sendo avaliado é a qualidade
do trabalho do aluno e a qualidade do enunciado. O PUG não tem
nenhuma intenção de comparar ou avaliar as tecnologias utilizadas nos
trabalhos – e o aluno, como futuro profissional, deve entender a
qualidade de seu trabalho como algo associado a seu conhecimento e
habilidade técnica, e nunca dependente de tecnologias ou ferramentas
específicas.

‣ Qualidade acadêmica do trabalho: um ponto importante é o
aprendizado do aluno durante a implementação do trabalho e a
qualidade do enunciado. O quanto o trabalho permitiu ao aluno
aprender é um quesito importante e reflete a qualidade do aluno e do
professor.

‣ Forma e conteúdo: trabalhos com visual impressionante mas que
dependem muito de frameworks ou bibliotecas devem ser avaliados com
cautela e confrontados com trabalhos pobres visualmente mas que
baseiamse em projetos elaborados do ponto de vista de conhecimento
emtecnologia da informação (algoritmos, estruturas de dados, técnicas
de programação). A qualidade do que o aluno realmente aprendeu e
produziu é mais relevante do que a qualidade visual que a tecnologia lhe
permitiu – o conteúdo do trabalho é mais relevante que a forma do
trabalho, mas ambos tem impacto na qualidade final do produto.

‣ Qualidade de software do mercado de TI: a avaliação deve também
considerar o trabalho do aluno como um projeto de software comercial,
identificando pontos onde o projeto seria mal avaliado por critérios de
qualidade adotados pelas empresas de TI. Dentre os tópicos mais
comuns, destacamse: documentação, artefatos de distribuição
(deployment), existência de testes unitários ou funcionais, organização
do código fonte, comentários no código, uso correto de estruturas de
dados e da API Java, etc.


‣ IHC – Interação HumanoComputador: acabamento ﬁnal e visual do
trabalho – internacionalização, uso correto do português, das cores,
distribuição dos componentes, etc. Se o trabalho não tiver interface
gráﬁca, ou isso não for o mais importante no trabalho, ignore este
quesito.

‣ Desempenho: considerando a função do trabalho, qual o seu
desempenho, tamanho e número de dependências?


Banca avaliadora

Foram convidados 10 profissionais de mercado, além dos 8 alunos e
seus professores. Infelizmente, apenas 3 professores puderam avaliar
os trabalhos (40%) e apenas 1 aluno não entregou a sua avaliação,
perdendo um ponto na média final. Profissionais possuem peso 7 e
alunos possuem peso 1. Não foram consideradas as notas dos
professores.

O minicurrículo dos profissionais que entregaram as avaliações
para o PUG 2009 estão enumerados na tabela abaixo:

Adriano Almeida - Caelum - SP

Página 10
Alexandre Gomes - SEA Tecnologia - InfoQ - DF

Página 11
Cláudio Rocha - IVIA - CE

Página 11
Fabiane Nardon - Zilics - JavaTools Community - SP

Página 12
Hebert Aquino - BRQ - CE

Página 12
João Victor - USIX - CE

Página 13
Julio Viegas - SPC Brasil - Globalcode - SP

Página 13
Loiane Groner - IBM - ESJUG - SP

Página 14
Ricardo Ferreira - Red Hat / JBoss - SP

Página 14
Rodrigo Rebouças - Dataprev - iDEZ - PBJUG - PB

Página 15

Nome Mini-currículo
É bacharel em Sistemas de Informação
pela Faculdade de Infor mática e
Administração Paulista e possui as
certificações SCJP e SCWCD. Desenvolve
sistemas desde 2005 e é entusiasta
Adriano Almeida práticas agéis de desenvolvimento, como
testes unitários, integração contínua,
pair programming entre outras.
Atualmente é instrutor, desenvolvedor e
consultor pela Caelum.


Mestre e Bacharel em Ciência da
Computação pela Universidade de
Brasília (2007, 2001); Diretor Técnico
da SEA Tecnologia; Mais de 10 anos de
experiência em arquitetura e
desenvolvimento de software; Mais de 4
anos de experiência em gestão de
projetos e liderança de equipes;
Experiência em editorial de revistas e
sites de conteúdo técnicos (MundoJava
Alexandre Gomes e InfoQ); Instrutor de cursos oﬁciais da
Sun Microsystems, SAP e RedHat/JBoss
com centenas de horas ministrando
treinamentos para a iniciativa pública e
privada; Palestrante em dezenas de
eventos tecnológicos nacionais e
internacionais; Grande defensor da
utilização de modelos colaborativos e
ágeis para a gestão empresarial;
Atualmente com pesquisas em modelos
arquiteturais para a computação ubíqua.

Graduado em Administração de
Empresas, possui pouco mais de 9 anos
de experiência em desenvolvimento de
software na tecnologia Java. Trabalha
Cláudio Rocha na Ivia desde 2005 tendo participado
neste período em projetos Java para
diversas instituições de variados portes.


Fabiane Bizinella Nardon é Mestre em
Ciência da Computação pela UFRGS e
Doutora em Sistemas Eletrônicos pela
USP. Atuou em diversas instituições de
grande porte, em projetos de larga
escala e de grande impacto social, como
o Sistema SIGA-Saúde, vencedor do
Duke’s Choice Award’2005. Atualmente
é Diretora de Tecnologia da Zilics, onde é
responsável pelas definições
tecnológicas em projetos na área de
saúde, e líder do grupo de pesquisa de
computação na nuvem do LSI/USP. Foi
diretora de diversos grupos sem fins
lucrativos, como o Capítulo Latino-
Fabiane Nardon Americano do CORBAmed e a Sociedade
Brasileira de Informática em Saúde,
além de ter sido membro do OpenJDK
Governance Board, o órgão responsável
pela criação da constituição do Java
Open Source. Atualmente é líder da
JavaTools Community do Java.net, uma
comunidade que réune mais de 800
projetos open source do mundo todo e
membro do comitê arquitetural da
Fundação OpenEHR. Recebeu o Special
Jury Award no concurso
Simagine’2006, em Barcelona, pela
criação da aplicação Virtual Health Pet.
Em 2006, foi apontada como Java
Champion pela Sun Microsystems.

Hebert de Aquino trabalha há 7 anos
com desenvolvimento Java, com foco no
desenvolvimento Java SE e Java EE. É
bacharelado em Ciências da Computação
e faz mestrado pela Universadade de
Hebert Aquino Fortaleza (UNIFOR).
Atualmente, trabalha como Arquiteto de
Software na BRq e possui algumas
certificações da Sun (SCJP, SCWCD,
SCBCD, SCEA e SCMAD).


Graduado em Informática pela
Universidade de Fortaleza e Mestre em
Administração de Empresas pela
Universidade de Fortaleza (2006).
Atualmente é o Gerente Técnico da
Matriz da USIX Technology onde tem
como principal responsabilidade a
gestão de todo o Portfólio de Projetos e
Operações. Possui certificações Project
João Victor Management Professional (PMP) e
Information Technology Infrastructure
Library (ITIL).
Têm experiência em gerenciamento de
Prog ramas e Portfólio, atuando
principalmente em projetos corporativos
de g randes organizações, como
Bradesco, SulAmérica Seguros, Brasil
Veículos (Seguradora do Banco do
Brasil) dentre outras.

For mado em Desenvolvimento de
Sistemas pela UNISUL, foi
instrutor Java certificado pela Sun
Microsystems. Possui mais de 10
anos de experiência na área de
tecnologia como instrutor(ministra
aulas de Java desde 2001), arquiteto,
Julio Viegas consultor e desenvolvedor de
sistemas de software. Colaborador ativo
no RSJUG, XP-RS, CEJUG e
outras comunidades. Possui as
certificações SCJP 5, SCJA 1, SCEA 1 e
5, SCDJWS 1.4 e 5, SCWCD 1.4, SCBCD 5,
Sun Certified Trainer.


Bacharel em Ciência da Computação,
atua como IT Specialist num projeto
internacional na IBM – Hortolândia-SP -
voltado para a plataforma Java Web.
Atua como embaixadora técnica e de
relacionamento do IBM Academic
Initiative. Coordenadora do ESJUG
(Grupo de Usuários Java do Espírito
Santo) e jug leader do CampinasJUG/
Loiane Groner Java Campinas (Grupo de Usuários Java
de Campinas-SP e Região). Possui 4 anos
de experiência na palataforma Java e
experiência 2 anos como Teacher
Assistant. Atuou por 2 anos como
Delegada Estudantil da SBC (Sociedade
Brasileira de Computação) na FAESA.
Escreve sobre java e desenvolvimento no
blog http://loiane.com e no blog em
inglês http://loianegroner.com

Ricardo Ferreira trabalha na JBoss, a
divisão de Middleware da Red Hat
atuando como Solutions Architect e
como especialista em SOA e BPM. Possui
mais de 12 anos de experiência na área
de desenvolvimento de softwares, 8
destes anos dedicados a soluções em
Java / JEE de missão crítica. É
especialista em soluções de EAI e
plataformas de negócios baseadas em
BPM. Já esteve em diversos projetos
SOA em empresas do governo,
telecomunicações e construção civil
Ricardo Ferreira liderando equipes em plataformas como
Progress (Sonic), webMethods, BizTalk,
AquaLogic e JBoss SOA Platform. É
colunista da revista Mundo Java onde
escreve periodicamente artigos sobre
SOA e BPM na coluna "SOA na Prática".
Além disso, possui diversas certificações
de grandes players da indústria como
Sun, IBM, Oracle e Borland, entre elas:
SCEA, SCBCD, SCWCD, SCJP, IBM
Certified SOA Solution Designer, IBM
Certified RUP Solution Designer, Oracle
SOA Architect Certified Expert e
Borland JBuilder Certified Developer.


Possui graduação em Ciência da
Computação pela Universidade Federal
de Campina Grande (2003) e mestrado
em informática pela Universidade
Federal de Campina Grande (2005).
Tem experiência na área de Ciência da
Computação, com ênfase em Gerência de
Serviços de TI e Engenharia de
Software, atuando principalmente nos
Rodrigo Rebouças seguintes temas: gerência de serviços
orientada a negócios; gerência de
mudanças em TI; ITIL; processos de
desenvolvimento de software;
engenharia de software; arquitetura de
software. Atualmente é Analista de T.I e
arquiteto de software da Dataprev, JUG
Leader do PBJUG e co-fundador da
Melon Tech.


Alunos x Instituições
UFC IFCE FA7 UNIFOR

IFCE
UFC 2
2

FA7
1
UNIFOR
3

UFC - Universidade Federal do Ceará
IFCE - Instituto Federal de Educação, Ciência e Tecnologia do Ceará
FA7 - Faculdade 7 de Setembro
UNIFOR - Universidade de Fortaleza


Avaliadores x Estados
CE SP DF PB

CE
3

SP
PB 5
1
DF
1


Trabalhos

Brincadeira de criança
IFCE
Aluno: Marcos Paulo
Professor: Fernando Parente

C3U - Chat 3D Unifor
UNIFOR
Aluno: Daniel Valente
Professor: Julio Guido
Militão

Codificação de Huff
man
FA7
Aluno: Francisco Jo
sé de
Lima
Professor: Leonard
o Holanda


Trabalhos

Gerenciador de Documentos
UFC
Aluno: Diego Aguiar Sousa
Professor: Iális Cavalcante

Indexador Semântico
UNIFOR
Aluno: Germano Duarte
Professor: Raimundo Tales

Labirinto Dinâmico
c/ grafos
UNIFOR
Aluno: Carlos Albé
rcio
Maciel
Professor: Rafael B
arbosa


Trabalhos

Simulador de Árvore B+ em
Java FX
IFCE
Aluno: Anderson de Matos
Professor: Glauber Cintra

Sistema de fretes
UFC
Aluno: Rafael Sales
Professor: Vânia Ponte Vidal


Classificação final do PUG
2009
O quadro abaixo apresenta a classificação final do PUG 2009:

# Média Aluno Professor Instituição

Daniel Valente de
1 8.84 Julio Guido Militão UNIFOR
Macedo

Francisco José de Leonardo Gomes de
2 7.78 FA7
Lima Holanda

Carlos Albercio Maciel Rafael Garcia
3 7.26 UNIFOR
Lopes Júnior Barbosa

Marcos Paulo Souza
4 7.06 Fernando Parente IFCE
Damasceno

Germano Machado Raimundo Tales
5 6.8 UNIFOR
Duarte Benigno Rocha

Anderson Severo de Glauber Ferreira
6 6.7 IFCE
Matos Cintra

Rafael de Castro Vânia Maria Ponte
7 5.81 UFC
Dantas Sales Vidal

Iális Cavalcante de
8 5.75 Diego Aguiar Souza UFC/Sobral
Paula Júnior

Siglas: - 1º lugar - campeão

- 2º lugar

- 3º lugar

- 4º lugar

- 5º lugar


Avaliações
1º - Daniel Valente de Macedo
Campeão PUG 2009
Faculdade: UNIFOR
Professor: Julio Guido Militão
Média aritmética: 8,84
Link p/ o trabalho: http://tiny.cc/ue6gb

Proﬁssionais

Nota Avaliação
Excelente manual, muito completo e detalhado. O sistema
funcionou sem problema nenhum em um MacOS, parabéns pela
compatibilidade entre as diferentes plataformas, pois havia
bibliotecas disponíveis. A qualidade da usabilidade do projeto é
excepcional, fiquei realmente encantado. Sobre o código, pode-se
melhorar alguns tratamentos de exceções, onde em várias
lugares elas são perdidas.
9.5
O código está bastante simples e fácil de ler, expressividade no
código é um fator que acho muito importante e seu código está
expressivo em grande parte do projeto (mesmo usando Swing
que é uma API que não favorece código expressivo). Parabéns
novamente. A ideia simples de um chat via socket, que é algo que
fazemos na Caelum no nosso curso básico de Java foi muito bem
aplicada. Com certeza mostrarei esse projeto para meus alunos.
Uma pena não ter testes unitarios.


Proﬁssionais

Nota Avaliação
Impressionante resultado visual e com grande potencial de
pesquisa e evolução pelas gerações subsequentes de estudantes.
O código está simples e muito bem estruturado, o que reflete a
clareza e sobriedade de idéias do aluno. Algumas observações,
entretanto, se fazem necessárias para aperfeiçoamento deste
futuro profissional.

Atente-se ao português. Apesar de ter uma mensagem clara na
documentação, o excesso de termos coloquiais e falhas
constantes de concordância prejudicam a impressão final de um
10
contrante. Em projetos reais, se há alguma opção que não deve
ser selecionada, não a disponibilize no projeto, como é o caso do
checkbox 'Fullscreen' apresentado na incialização do jogo mas
cuja seleção é proibida pela documentação. Em próximas
oportunidades, revise a documentação após concluído todo o
trabalho de desenvolvimento. Algumas instruções pareceram-me
obsoletas (e.g., não existe o arquivo PUJ2009.zip para importação
do projeto, as libs não vieram configuradas). Logging com
System.out.println não é uma boa prática. O algoritmo de colisão
com as coordenadas hard coded não poderia ser melhor
flexibilizado?

O trabalho do Daniel utilizou um componente já recorrente em
trabalhos com implementação que é o Chat porém incorporou à
ele toda a interatividade da computação gráfica. A proposta ficou
bem interessante.
9.4
Este trabalho foi implementado com o lado cliente e lado servidor.
No lado cliente estava toda a lógica de apresentação gráfica, e o
lado servidor que realizava o controle dos diálogos. Também
houve a necessidade de se estabelecer um protocolo de
comunicação para que os clientes pudessem reconhecer a ação
executada pelo outro cliente.


Proﬁssionais

Nota Avaliação
Fabiane Nardon - Zitrics - JavaTools Community - SP
Infelizmente a aplicação não fornece um jar pronto para ser
executado, o que facilitaria bastante a avaliação da ferramenta. O
sistema fornece um arquivo .bat para execução, mas o mesmo
não funciona por não existir o jar necessário. Lembre-se: facilitar
o uso da aplicação é fundamental para você ter sucesso no seu
9 produto! Após instalar o Eclipse, as instruções estavam claras e
precisas e foi muito fácil executar a aplicação.

Gostei muito do cuidado com a interface, criando roupas para o
PUJ, CEJUG, etc. Existe uma boa quantidade de JavaDoc no
código, o que facilita o entendimento. De modo geral, o código
está bem organizado e bem formulado.

Excelente projeto com boa documentação porém não gerou o
9.8 Javadoc.
Gerou uma vídeo-aula de como configurar a aplicação.


Proﬁssionais

Nota Avaliação
João Victor - USIX Technology - CE
Justificativa para a nota: O sistema apresentado é muito bom
visualmente. Utilizou de um modismo tecnológico (Second Life)
para desenvolver a aplicação. Consegue atender o propósito da
ferramenta com muita clareza e praticidade e os comandos são
bastante conhecidos para quem esta acostumado a jogar no
micro. Outro ponto importante é a utilização de tecnologia 3D
para aprimorar o aplicativo. Um ponto negativo foi não
disponibilizar um “executável” para rodar a aplicação.

A documentação do projeto esta excelente. Possui um vídeo
explicativo para colocar a aplicação para funcionar, além de um
tutorial escrito. A documentação cobre desde a preparação da
9.6 aplicação até o modo de utilização da mesma.

Sobre o valor do projeto em relação ao mercado: A aplicação
utiliza-se de um modismo tecnológico e pode ser explorado pelo
mercado. O Chat pode ser aprimorado e ganhar espaço no mundo
da tecnologia. Sendo ousado na opinião, poderemos num futuro
próximo ter esse tipo de chat como o padrão de comunicação do
mercado em substituição ao MSN, Gtalk e outros.

Sobre os critérios de qualidade: A aplicação parece estável,
porém não foi testada por múltiplos usuários, sendo assim, não
se pôde avaliar a robustez do aplicativo. Provavelmente não se
utilizou de ferramentas de PMD ou Findbugs , mas teve
preocupação com warnings no código.

Faltou melhorar a mobilidade. Pode ser trabalhado para se tornar
8.9 um jogo semelhante ao second life. Projeto com alto potencial de
vendas e alta qualidade.


Proﬁssionais

Nota Avaliação
UI bem finalizada, bom uso de Swing, aplicação bem intuitiva.
Arquivo de instrução super claro e objetivo, bem detalhado,
qualquer pessoa conseguiria fazer a instalação com
um mínimo de conhecimento. Achei a idéia do vídeo-tutorial show
de bola!

Demonstrou bom uso de Sockets e da bilbioteca OpenGL.
9.5 Encontrado comparação de objetos com == em vez de .equals
(má prática e não é
correto: operador == entre objetos compara a referência e não o
conteúdo/valores do objeto).

Encontrado blocos catch vazios (muito feio!) – ao menos faça uso
de impressão de stacktrace, ignorar uma exception é uma
péssima prática!
Pouco uso de interface de coleções. Exemplo: dê preferência para
usar List nomeDoObj = new ArrayList().

Considerando que o trabalho do aluno começou com 10.0 pontos,
houveram certos aspectos do trabalho que me fizeram destacar
alguns destes pontos, decrementando o valor da nota para 9.25.
Os aspectos avaliados foram:

Faltou a criação de um laucher mais apropriado para executar o
programa cliente e o programa servidor. Apesar da correta
execução do projeto dentro do ambiente Eclipse, isso torna o
aplicativo voltado para conhecedores da plataforma Java, o que
compromete o requisito não funcional de usabilidade do software.
Para este ponto, foi retirado 0.5 ponto.
9.25
Apesar de excelente aplicação do conceito de sockets Java para
comunicação de processos via remoting, faltou alguma
preocupação sobre como questõs de Threads e sockets usam
recursos visuais do AWT. Nos testes efetuados, o cursor do mouse
apresentou intermitências durante a execução, e alguns pequenos
e rápidos congelamentos de tela ocorreram, talvez relacionados a
como a biblioteca nativa se comporta com diversos threads
acessando a API. Talvez o uso de uma lib visual mais "Thread-
Safe" como o Swing poderia resolver o caso, mas acredito que a
aplicação de AWT possa estar relacionada sobre como a
dependência do framework lwjgl requer para funcionar. Para este
ponto, foi retirado 0.25 ponto.


Proﬁssionais

Nota Avaliação
Meus critérios de avaliação:
a) Facilidade de instalação e execução

Script para execução do projeto apenas em .bat... (podia ter
usado um script ANT, para que funcione no Linux ou MAC OS).
Estou usando um MAC OS. Não consegui rodar o projeto.
Tentei rodar no Linux. Também sem sucesso.
Ter uma IDE como requisito de software para rodar o projeto
também não é interessante.

b) Qualidade do manual e material de documentação

8 Muito bom.

c) Qualidade do código produzido (código e design do projeto)

Evite usar System.out.println para imprimir as mensagens do
sistema, dentro das classes do sistema.
Parametrize a porta. Leia de um arquivo de configuração ou
receba por parâmetro, na classe GameServer.java. Eu posso
querer mudar esta porta e não quero alterar o código pra isso. ;-)
Lógica do jogo muito misturada com elementos de interface.

d) Inovação do projeto

Muito bom.

Alunos

Nota Avaliação
Anderson Severo de Matos - aluno IFCE
O programa roda muito leve e causa excelente impressão. Um
ponto muito ruim é a necessidade de utilizar o Eclipse para poder
testar a aplicação, porém consegui rodar seguindo os passos do
8.25 tutorial apenas importando o arquivo .ZIP e executando as duas
classes indicadas. Não cheguei a ter problema com vídeo, não sei
em máquinas mais simples. Código extremamente organizado,
provavelmente houve um ótimo trabalho de orientação por parte
do professor. Ausência de javadoc.


Alunos

Nota Avaliação
Carlos Albercio Maciel - aluno UNIFOR
Trabalho com documentação simples, mas objetiva. O trabalho
8 poderia ter ficado mais interessante se tivesse utilizado menos
API já existentes que facilitam o trabalho, mas o mesmo ficaria
árduo e não daria tempo de fazer devido ao espaço de tempo
dado ao desenvolvido.

Diego Aguiar Souza - aluno UFC/Sobral
Um ótimo sistema, com uma boa interface. Faltou apenas a
9.5 documentação, muito embora o código esteja bem definido no
quesito organização.

Francisco José Lima - aluno FA7
Não possuo uma placa de aceleração gráfica para poder realizar o
1 teste. A execução do aplicativo deve ser independente do uso de
IDE.

Germano Machado Duarte - aluno UNIFOR
8 Trabalho com documentação simples, mas objetiva. A grande
quantidade de API usada fez com que o trabalho perdesse seu
valor, tirando um pouco o mérito do aluno.

Marcos Paulo - aluno IFCE
Considerações Positivas: Grande trabalho, de dar inveja a
qualquer desenvolvedor, o resultado final ficou muito bom. Muito
bem documentado, e o video também foi uma ótima idéia para
facilitar a execução do programa, rodou perfeitamente no
8 Windows 7, um dos sistemas operacionais que testei.

Considerações Negativas: Infelizmente não consegui fazê-lo
executar no MacOS X Snow Leopard, nem no Ubuntu 9.10, não
achei legal o fato do trabalho utilizar bibliotecas fora do Java, que
são diferentes a cada SO.

Rafael Sales - aluno UFC
1
Não entregou a avaliação.

2º - Francisco José de Lima
vice-campeão PUG 2009
Faculdade: FA7
Professor: Leonardo Gomes de Holanda
Link p/ o trabalho: http://tiny.cc/n07n2


Proﬁssionais

Nota Avaliação
Muito legal a ideia do projeto. Sistema simples, funcionando e fácil
de usar. Excelente. Parabéns por ter usado uma ferramenta (Ant)
para facilitar o build do projeto. Muito boa a separação entre
9.2 Model, View e Controller na aplicação. No sistema existe uma
classe chamada Referencia que está com código vazio. É isso
mesmo? O sistema ficou muito bom, mas como eu garanto que as
regras de negócio estão funcionando corretamente? O ideal é que
existissem alguns testes unitários pelo menos para as lógicas mais
complicadas. Muito bom projeto. Parabéns.

A documentação do projeto está simples e objetiva. O assunto é
extremamente enriquecedor para a vida profissional do aluno e
um bom uso da tecnologia foi feito. Entretanto, ressalto alguns
pontos que podem ser melhorados em novas oportunidades.

Ao longo do desenvolvimento de qualquer projeto, é comum o
acúmulo de códigos mal feitos e/ou desnecessários criados no
10 calor das emoções. Essas pendências, na linguagem comum, são
conhecidas por débitos técnicos e devem ser rotineiramente
eliminadas de seu código para o bem de sua clareza e facilidade de
manutenção. No projeto submetido, encontra-se, por exemplo,
uma classe Referencia que sequer possui conteúdo e, na classe
Controle, o método getHuffman está disponível mas nunca foi
usado. Ainda, num aparente preciosismo, ou over-engineering,
temos a classe Tabela com a única responsabilidade de encapsular
um atributo do tipo Map. ão seria excesso de capricho?

A aplicação disponibilizada pelo Francisco José é relativamente
9.8 pequena, porém seu código mostrou uma divisão de
responsabilidades das classes em um nível adequado o que facilita
sua leitura promovendo uma fácil manutenção.


Proﬁssionais

Nota Avaliação
Fabiane Nardon - Zitrics - JavaTools Community - SP
A documentação do projeto foi suficiente para instalar e executar o
aplicativo. No código fonte, algumas classes não estão
documentadas com JavaDoc.

Os textos utilizados na aplicação estão hard coded e não
internacionalizados. Seria mais adequado utilizar um resource
bundle.

Poderia haver um pouco mais de cuidado com a interface, pois em
diferentes sistemas operacionais, os elementos da tela não ficam
corretamente alinhados.

7 Senti falta de uma funcionalidade simples na interface que
permitiria testar melhor o software: uma funcionalidade que
permitisse abrir um arquivo já comprimido e pedir que seja feita a
descompressão. Da forma como a aplicação foi organizada, a única
forma de descomprimir um arquivo é antes comprimi-lo na mesma
tela.

A classe CodigoHuffman está implementada como um Singleton,
mas para que a implementação seja realmente correta, deveria
haver uma diretiva synchronized no método getInstance e a
implementação de um construtor privado para evitar que exista
mais de uma instância da classe criada.

Javadoc - Faltou o Javadoc e não comentou todas as classes
deixando a documentação pobre.
6 Aplicação - Criou uma classe Referencia sem necessidade.
Deixo referencias do Svn dentro do código-fonte.
Interface - Baixa usabilidade deveria ter criado um help colocou
apenas um sobre o projeto.


Proﬁssionais

Nota Avaliação
Justificativa para a nota: Fez um excelente trabalho, porém
poderia explorar melhor a interface para deixá-la mais intuitiva.
Conseguiu comprovar a compressão e a descompressão dos
arquivos o que valida o trabalho em termos práticos.

Possui uma documentação bem simples, porém funcional. A forma
de execução do aplicativo é bem fácil e rodou “out of the box”. Não
possui javadoc do aplicativo.

7.3 Sobre o valor do projeto em relação ao mercado: O aplicativo
implementa um algoritmo conhecido de compressão de dados.
Sendo assim, possui pouco apelo no mercado. Caso o aplicativo
implementasse um algoritmo inovador teria um enorme apelo,
principalmente para grandes infra-estruturas onda o volume de
dados armazenados são enormes.

Sobre os critérios de qualidade: A aplicação parece ter sido escrita
sem utilização de nenhuma IDE, utilizou-se apenas de um ant
build para compilação. Diante disso, possui vários problemas de
imports dentre outros e com certeza não passou PMD ou Findbugs.

Já existem uma série de códigos disponíveis para tal, tornando a
5.2 exploração comercial inviável. Porém possui uma boa interface, na
minha opinião. Possui um potencial de vendas baixo e uma
qualidade média.

Aplicação bem intuitiva, bom uso de Swing, arquivo de instrução
claro e objetivo. Projeto é espelho do que se propõe a fazer. Fez
uso correto do padrão de projeto utilizado. Uso correto de
interfaces de coleções.

8.5 Projeto não possui documentação e não possui comentários ao
longo do código. Achei alguns blocos de código repetidos, poderia
ter criado métodos para reuso de código e facilitar uma
manutenção futura (caso fosse necessário). Exemplo: métodos
fromByteArray da classe Util (poderia ter feito cast do object e
chamado o outro método). Quase todos os atributos das classes
são public ou default. Não fez uso de encapsulamento.


Proﬁssionais

Nota Avaliação
alguns destes pontos, decrementando o valor da nota para 9.0. Os
aspectos avaliados foram:

O código do programa apresenta pouco controle de instâncias de
objetos quanto as suas referências. Erros do tipo
NullPointerException são considerados básicos demais para uma
aplicação que está sendo distribuida e deverá ser usado em larga
escala. No consegui avaliar se o programa dispara algum erro
9 desta natureza, mas pelo código fonte dá pra perceber que
'potencialmente' isso ocorrerá, o que me estimula a retirar 0.75
pontos do resultado final. Quando um projeto é mantido apenas
por um programador, falhas como essa tendem a ser contornadas
ou inibidas. Mas em um projeto onde vários programadores atuam
no código fonte, este tipo de controle de código deve ser
obrigatório.

Documentação apresenta poucas instruções sobre questões de
ambiente do programa. Não fala por exemplo que para executar o
mesmo é necessário usar uma JVM versão 6.0 ou superior. Para
este ponto, foi descontado 0.25 ponto.


Proﬁssionais

Nota Avaliação

Excelente. 1 click no codificacaohuffman.jar e voilá!


Muito bom


Classe "Referencia.java" vazia.
A classe "CodigoHuffman" era para ser um Singleton?
private static CodigoHuffman instance = null;

public static CodigoHuffman getInstance(){
if(instance == null)
instance = new CodigoHuffman();
return instance;
}
9 Tá faltando o construtor privado.

Os métodos "main" e "getHuffman()" da classe "Controle" não
estão sendo usados.

Acertou na trave na implementação do controlador do MVC.

A classe "Controle" deveria receber diretamente o evento do
ActionListener. Ela deveria implementar "ActionListener" e ser
adicionada como Listener do botão. Assim ela iria traduzir
diretamente o evento da interface no evento do "modelo".
É uma sugestão para você melhorar sua implementação do MVC.


Baixa

Em resumo, o projeto está bem documentado, não é um ótimo
exercício de implementação do algoritmo de compressão, foi bem
implementado. Só não é inovador por se tratar de um projeto de
sala de aula, um exercício sobre a implementação do algoritmo. De
fato, inovação não é objetivo da equipe.


Alunos

Nota Avaliação
Anderson Severo - aluno IFCE
O software apresenta de forma direta a aplicação do algoritmo de
7.3 Huffman e explicita que não deve ser utilizado com propósito
comercial ou mais sério. O desenvolvedor não forneceu javadoc.
Exemplificação de conteúdo acadêmico incluindo menção do autor,
no documento tutorial, de fontes sobre o assunto na Internet.

Carlos Albercio - aluno UNIFOR
O trabalho poderia ter ficado mais interessante se exibi-se algum
percentual de andamento da compressão, pois ao selecionar um
7 arquivo de 28mb o mesmo ficou “travado” até que a compressão
fosse concluída, sem contar que o mesmo não fez a compressão,
não sei se deu algum erro durante o processo, pois o mesmo não
apresentou nenhum resultado, assim imagino que a memória deve
ter “estourado” ou algo do tipo.

Daniel Valente - aluno UNIFOR
Trabalho está bem legal e seu código também, porém a parte visual
7.5 poderia estar um pouco mais didática, como outros trabalhos do
PUJ (Ex: o de grafos, árvores e SO).

Diego Aguiar - aluno UFC/Sobral
8 Funciona conforme o esperado, contudo, comparado aos demais
programas com uma boa GUI, este ficou devendo, além de possuir
um botão sem nenhuma funcionalidade. Faltou a documentação.

Germano Duarte - aluno UNIFOR
6 Ao selecionar um arquivo maior do que 10mb o sistema fica em
espera até que a compressão for concluída. Seria interessante
mostrar uma tela de status da compressão.

Considerações Positivas: Bom programa didático, pode ser utilizado
para demonstração da codificação de Huffman muito bem. Bom
tutorial.

6 Considerações Negativas: Tem classes vazias no src, péssima,
péssima, péssima utilização do swing, a interface ficou
organizadinha mas o código está horrendo, não curto a filosofia
drag and drop e acredito que possa ter sido utilizado nesse
programa, pra mim, usar o swing na mão pode ser mais produtivo
que o drag and drop se você utilizar bem. Levou nota porque em
comparação.

1


3º - Carlos Albercio
Faculdade: UNIFOR
Professor: Rafael Garcia Barbosa
Link p/ o trabalho: http://tiny.cc/0uhak

Proﬁssionais

Nota Avaliação
Manual sucinto e direto. Código de algumas classes um pouco
extensos e de leitura complicada. Algumas refatorações, como
7 extrações de métodos facilitariam a leitura do código. É preciso
também tomar cuidado com os famosos números mágicos no meio
do código. Boa usabilidade, mas visualmente poderia ser melhor
trabalhado. Sistema simples e objetivo. Parabéns.

Desde já, é importante que nossos futuros profissionais atentem-se
aos detalhes estáticos de seus trabalhos. Apesar de completa e
clara, a documentação poderia ter sido mais bem acabada.
Infelizmente, nossa cultura ainda preconiza a forma sobre o
conteúdo. Portanto, é importante que, ao se entregar qualquer
produto final a clientes ou parceiros, atente-se aos ajustes finos
que podem fazer a diferença para a primeira impressão (aquela que
fica).
8
O projeto está funcional e desenvolve-se sobre a curiosa teoria dos
grafos cuja complexidade no necessariamente precisa ser refletiva
no código. No geral, observa-se métodos de longa extensão, com
profundos níveis de aninhamento e carência de documentação não
javadoc que dificultam sua compreensão imediata. Ademais,
existem algumas dependências entre a lógica (Grafo) e a GUI
(JFramePrincipal) que não é bem vista pela comunidade
desenvolvedora.

Achei que a código poderia ter sido quebrado em um maior número
8.4 de classes de forma a facilitar a leitura e manutenção. De qualquer
forma a proposta era muito boa e o Labirinto Dinâmico do Carlos
Albércio estava muito fácil de instalar e possuía boa
documentação.


Proﬁssionais

Nota Avaliação
A documentação estava concisa, mas suficiente para entender o
sistema e utilizá-lo. A execução do sistema ocorreu sem problemas.

A interface é simples, mas bem elaborada.

8 Nem todos os métodos possuem JavaDoc adequados, o que
dificulta um pouco a compreensão do código.

Algumas partes do código poderiam ter sido fatoradas em métodos
para que o código ficasse mais organizado e sua manutenção mais
fácil. Exemplo: no método Grafo.moverBoneco, o mesmo pedaço de
código é repetido várias vezes, com pouca variação.

Javadoc - Javadoc não foi gerado e não respeitou alguns code
8.5 conventions. Algumas classes não foram comentadas.
Instruções foram simples deixando falhas. Bom Trabalho mas faltou
alguns pequenos detalhes.

Justificativa para a nota: A aplicação parece bem interessante e
fácil de usar. Não tem um visual muito agradável, mas para o jogo
que se propõe ser atende ao nível mínimo de aparência. Vale
salientar que a aplicação utilizou-se de swing com leiaute estático.
Foi fácil colocar a aplicação para funcionar. Executou de forma “out
of the box”, sem muita complicação.

Possui dois manuais bem funcionais, porém ambos muito pobres
em qualidade visual o que deixa transparecer que não houve
cuidado ao criar os manuais. A aplicação não possui Javadoc para
7.3 deixa o código legível.

Sobre o valor do projeto em relação ao mercado: É uma aplicação
que pode ser comercializada como jogo para crianças. Bem fácil de
ser entendida. Se refinada poderia ser mais um joginho no
mercado. Porém, vale salientar que já existem joginhos dessa
natureza.

Sobre os critérios de qualidade: A aplicação utilizou-se de recursos
de programação não muito recomendáveis, como java.util.Vector e
muitos resources. Provavelmente não se utilizou de ferramentas de
PMD ou Findbugs, porém nos teste a aplicação não travou.


Proﬁssionais

Nota Avaliação
Faltaram alguns ajustes de interface. Pode ser comercializado como
7.5 biblioteca em algum engine de jogo. Possui um potencial de vendas
médio e alta qualidade.

Aplicação bem intuitiva, bom uso de Swing, arquivo de instrução
claro e objetivo. Deixou o aprendizado sobre Grafos mais atrativo.
Fez uso de documentação, mas poderia ter colocado alguns
comentários dentro de métodos para facilitar entendimento de
bloco de código.
8
Achei alguns blocos de código repetidos, poderia ter criado métodos
para reuso de código e facilitar uma manutenção futura (caso fosse
necessário). O FindBugs achou algumas linhas de código com Bad
Practice, mas nada muito sério. O mais relevante que achei foi
concatenação de Strings em loop com operador + - dê preferência
a StringBuffer (só uma dica para melhorar a performance).


Proﬁssionais

Nota Avaliação
alguns destes pontos, decrementando o valor da nota para 7.75.
Os aspectos avaliados foram:

1) Documentação não cobre detalhes de execução e ambiente do
programa. Um ponto por exemplo era explicitar que o programa
necessita de uma JVM versão 6.0 ou superior. Ao tentar executar o
programa de acordo com as instruções (Usando um JVM 5.0), tive
um problema de classVersion logo de cara. Por conhecer Java,
solucionei o problema, mas considerando uma pessoa que não é
técnica, ela não consequiria executar o programa corretamente.
Para este ponto, descontei 0.50 ponto.

2) O código do programa não oferece uma boa separação de
camadas entre os componentes da camada de apresentação e os
componentes do modelo. Como foi adotado um modelo baseado em
7.75
MVC, uma separação das dependências por meio de factories,
interfaces e/ou Dependency Injection se faria necessário. Existem
classes do modelo que possuem imports diretos para classes da
camada de apresentação (Ex: import javax.swing.*) o que torna o
código mais acoplado em dificil de manter. Para este ponto,
descontei 1.0 ponto.

3) O código do programa apresenta pouco controle de instâncias
de objetos quanto as suas referências. Erros do tipo
NullPointerException são considerados básicos demais parauma
escala. Não consegui avaliar se o programa dispara algum erro
desta natureza, mas pelo código fonte dá pra perceber que
pontos do resultado final. Quando um projeto é mantido apenas por
um programador, falhas como essa tendem a ser contornadas ou
inibidas. Mas em um projeto onde vários programadores atuam no
código fonte, este tipo de controle de código deve ser obrigatório.


Proﬁssionais

Nota Avaliação
Excelente. Basta executar o JAR. 1 click.

Não há documentação

4 Ruim.

JFramePrincipal é uma "GOD Class". O código que constrói e
manipula a interface está todo misturado com o código da estrutura
de dados.


Baixa.

Alunos

Nota Avaliação
O software assim como o arquivo com as instruções são bem
8 simples, porém, claros e objetivos. Consegui executar sem
problemas e o gerador de labirintos funcionou corretamente no que
se propôs. O código me pareceu organizado e minimamente
comentado. Ausência de javadoc.

Trabalho bem divertido de se usar e bem explicativo visualmente
em relação ao objetivo do trabalho. Porém na parte do codigo acho
7.5 que poderia ter tido um menor acoplamento da estrutura de dados
Grafo em relação a interface gráfica, podendo deixando ela
independente da interface e possibilitanto o uso da mesma para
outros objetivos.

9 O programa executou conforme o esperado, e possui um GUI muito
amigável. Contudo, o autor ficou devendo na parte de documentação.


Alunos

Nota Avaliação
Francisco José de Lima - aluno FA7
Bom manual de instruções, pois é objetivo e claro. O aplicativo é
de fácil inicialização.
Boa interface gráfica, porém precisa de alguns ajustes para poder
rodar em ambiente GNU/Linux. Interface intuitiva o que facita o
entendimento.

7 Métodos comentados, porém poderia adicionar mais informações
sobre o comportamento. Alguns métodos precisam de um
"refactoring", pois estão muito grandes ou agregam
funcionalidades que poderiam ser desacopladas. O programa
atende ao que ele se propõe e não ocorre falhas. Boa escolha do
tema, pois o aplicativo exige boa capacidade de raciocínio e
criatividade.

8 Trabalho bem estruturado com boa padronização e documentação
do código. Interface simples e de fácil entendimento.


Considerações Positivas: O Programa realmente faz o que propõe,
bastante didático, bastante intuitivo, consegui fazê-lo funcionar
sem precisar ler o manual. Javadoc bom se comparado ao dos
outros ou ao meu mesmo.

Considerações Negativas: Praticamente toda a lógica ficou em
apenas uma classe com várias linhas, não achei que isso ficou
legal. Além disso, a interface pareceu que ele fez sim a mão o que
é bem legal, mas o código ficou horrível, colocou toda a interface
6 em apenas uma classe, podia ter extendido o FramePrincipal de
Jframe e ter feito um sigleton utilizado ele na classe Grafo e
separado alguns componentes que fossem ficar mais complexo em
outras classes ou em até metódos, ao inves de sair inicializando-os
e setando suas propriedades de uma formada jogada no código,
também poderia ter feito uma classe interna para poder usar o
ActionListener ao inves de inicializalo e implementar o método
action performed como parametro do metodo addActionListener.
Também podia ter feito uma classe de carregamento das imagens.
Acredito que teria sido uma melhor prática e não precisava ser um
mestre do swing para isso, são conceitos de OO que senti muita
falta no software.



4º - Marcos Paulo Souza Damasceno
Faculdade: IFCE
Professor: Fernando Parente
Link p/ o trabalho: http://tiny.cc/auxz3

Proﬁssionais

Nota Avaliação
Bem direto a execução do programa e a ideia de mostrar as
Threads em execução com um exemplo bastante didático foi
excelente. No entanto, o projeto pecou na usabilidade, por exemplo,
após finalizar a definição da quantidade de usuários e do tempo e
clicando em "Definir" a janela não é fechada. Com relação ao
código, a API Swing é bastante poluída e nem sempre herdar dos
componentes Swing são a melhor saída para conseguir um código
6.7 legível. Muitas vezes utilizar composição no lugar pode tornar o
código mais simples.

As variáves declaradas no programa são bem claras e o código está
bem organizado. Outro ponto crítico é o tratamento das exceções. É
imprescindível indicar ao usuário que algo está dando errado na sua
aplicação. No entanto, com o tratamento através do
System.out.println o usuário não sabe que a aplicação está com
problemas, a não ser que ele tenha conhecimento suficiente para
verificar o log da aplicação.


Proﬁssionais

Nota Avaliação
A documentação está recheada de argumentos contra possíveis
decepções da avaliação. A submissão do projeto nas vésperas do
prazo, a pouca idade do estudante à época do desenvolvimento, a
ausência de IDE e outros poréns não devem ser motivos para se
tecer justificativas precipitadas do trabalho proposto. Nenhum
desses argumentos aliviam o rigor da avaliação. Desculpar-se antes
de se apresentar é uma tremenda gafe que deve ser evitada em
todas as situações de nossas vidas. Um palestrante que começa
uma palestra dizendo estar nervoso e que não conhece a fundo o
assunto tem mil vezes mais chances de fracasso do que se tivesse
administrado internamente suas fraquezas e tentado se superar
silenciosamente. Mesmo no mercado de trabalho, por exemplo, é
mais transparente e honroso assumir o não alcance dos objetivos
iniciais e estabelecer novos prazos para sua realização do que
tentar disfarçar uma produção aquém de seu potencial. Portanto,
estudantes, desde já, ergam a cabeça, assumam o ônus de suas
decisões e sigam adiante.
6
O funcionamento geral do sistema é adequado ao tema proposto,
mas é importante observar regras básicas do desenvolvimento Java.
Está fora do bom costume, por exemplo, a criação de classes com
nomes iniciando por letras minúsculas (e.g.
InterfacePrincipal.telaDefinicoes) e variáveis com nomes iniciando
em letras maiúsculas (TelaInicia.Comeco). Também faz parte das
boas práticas de projeto o desacoplamento máximo entre as
camadas arquiteturais. No sistema entregue, entretanto, a classe
Crianca, que representa a lógica do jogo, possui profundos laços de
dependência com os painéis da camada de apresentação.

A documentação parece ter sido concebida às pressas, pecando no
português (e.g. durmindo) e com excesso de coloquialismos (e.g.
'Pronto, temos uma thread para cada criancÃßa e elas estarão ali
brincando e tudo mais'). Durante a execução de uma amostragem
com 5 crianças, 3 com bolas e 1 bola no cesto, os sistema parou
com StackOverflowError.


Proﬁssionais

Nota Avaliação
O Marcos apresentou uma aplicação que aborda a utilização e
controle de Threads. Sua app se mostrou fácil de instalar, com uma
10 boa granularidade na definição das classes exibindo uma boa
divisão de responsabilidades. A forma/disposição na tela com que
abordou o assunto também facilitou bastante o entendimento dos
conceitos propostos.


Proﬁssionais

Nota Avaliação
Embora o autor tenha se preocupado em fazer uma documentação
completa, sugiro um pouco mais de atenção ao texto, tanto no que
se refere a erros de português quanto ao estilo da documentação.
Sendo uma documentação de um software ou produto, deveria ser
um pouco mais formal.

Aparentemente a aplicação requer Java 6 para executar
corretamente (apresentou erros em Java 1.5), mas esta informação
não está presente da documentação. Em algumas situações, a
aplicação apresentou java.lan g.NullPointerException durante a
execução. Em termos de usabilidade, o fato de as definições serem
zeradas a cada simulação é bastante inconveniente, pois obriga o
usuário a refazer as definições a cada nova simulação.
Nas minhas simulações, nem sempre o programa se comportou
como descrito na documentação. Por exemplo, simulando 5
crianças, 2 crianças com bolas e 1 bola no cesto, com tempos de 5
segundos para brincar e 5 para descansar para todos, as crianças
6 nunca descansam. Parece que a aplicação fica paralizada em um
certo ponto. Os textos utilizados na aplicação estão hard coded e
não internacionalizados, o que não é adequado. Seria mais
adequado que estes textos estivessem em bundles. O código está
muito pouco documentado. Seria importante incluir javadocs nas
classes.

Nem todas as variáveis obedecem os padrões de nomenclatura.
Existem variáveis com primeira letra maiúscula, por exemplo. Da
mesma forma, nem todos os nomes de métodos obedecem estes
padrões. O tratamento de exceções também não é adequado.
Existem exceções que são escondidas por um try...catch sem log.
Exemplo: veja método "Brincar". Como são usadas diversas
variáveis estáticas, é necessário avaliar onde colocar a diretiva
synchronized para evitar conflitos.

Um ponto a destacar é que a lógica está separada da camada de
apresentação, o que é um bom princípio.


Proﬁssionais

Nota Avaliação
Javadoc - Documentação Pobre, não informa o que faz cada classe e
método, baixa legibilidade do código fonte não respeita alguns java
code convetions.
7
Interface pouco intuitiva o botão começar veio antes das definições.
Na criação da criança já deveria ser informada o intervalo de
tempo.

Justificativa para a nota: O sistema apresentado é relativamente
usual. O layout não deixa claro alguns detalhes do funcionamento
do aplicativo. A aplicação fez o que se propõe a fazer, porém o
funcionamento é bem simplista.

A documentação é bem pobre e deixa muito a desejar. O javadoc só
possui casca, não possui comentários. Aparentemente gerou o
javadoc sem a preocupação de fazê-lo entendível.
6.5
Sobre o valor do projeto em relação ao mercado: A aplicação tem
pouquíssimo apelo no mercado, pelo fato de ser um simulador e
possuir algoritmos clássicos de produtor consumidor.

Sobre os critérios de qualidade: A aplicação não parou de funcionar
em nenhum teste e suportou vários cenários. Não se utilizou de
PMD e FindBugs além de não se preocupar em documentar as
classes métodos e etc.

Única aplicação comercial se for usado como suporte ao
6.5 aprendizado. Qualidade gráfica boa. O programa funcionou bem.
Baixo potencial de vendas e qualidade média.


Proﬁssionais

Nota Avaliação
Aplicação bem intuitiva, UI com alertas e validação, bom uso de
Swing, arquivo de instrução claro e objetivo. Deixou o aprendizado
de Threads bem divertido. Projeto não possui documentação e não
possui comentários ao longo do código.

Encontrado comparação de Strings com == em vez de .equals (má
prática e não é correto: operador == entre objetos compara a
referência e não o conteúdo/valores do objeto). Encontrado
variáveis e atributos iniciadas com letra maiúscula (não é erro, mas
8.5 não está dentro do padrão de convenção do java).Encontrado
alguns atributos com modificador default.

Poderia ter declarado como private para o uso de encapsulamento,
como utilizado em atributos de outras classes. Encontrado
comandos vazios (apenas ; no código) - ocorreu muito após bloco
catch. Chamada do método getFrame da classe TelaInicial - seria
interessante fazer o uso do pattern singleton adequadamente nesse
caso, já que o atributo Comeco é private static. Encontrado blocos
catch vazios (muito feio!) – ao menos faça uso de impressão de
stack trace, ignorar uma exception é uma péssima prática!


1) O código do programa apresenta pouco controle de instâncias de
objetos quanto as suas referências. Erros do tipo
8.25
pontos do resultado final. Quando um projeto é mantido apenas
por um programador, falhas como essa tendem a ser contornadas
ou inibidas. Mas em um projeto onde vários programadores atuam
no código fonte, este tipo de controle de código deve ser
obrigatório.

2) Código com pouca organização de camadas e excesso de
dependências entre os componentes. Para este quesito, foi
descontado 1.0 ponto.


Profissionais

Nota Avaliação

Excelente. 1 click no jar.


Ruim


Algumas variáveis com letra maiúscula, classes com letra
minúscula.
8
A classe "teste" em "PBrincadeiraDeCrianca.java" não tem um bom
nome.

As variáveis com uma letra dificultam a leitura do código, como "c",
"b", "a".

A classe "Crianca" acessa a classe "PLogCesto", criando
acoplamento entre lógica e elemento de interface.
Apesar destes pequenos detalhes, o código está bem estruturado,
no geral.


Bom

Alunos

Nota Avaliação
O programa tinha grande potencial de apresentar uma interface gráfica mais
rica e/ou intuitiva. O código está imaturo em relação aos outros trabalhos
7.5 apresentados (nomes de métodos, atributos, classes internas), mas a
simulação corre sem problemas. Com tempo e um pouco de atenção é
possível observar o comportamento das imagens(segundo definido) e
entendê-las como Threads. Javadoc apresentado.


Alunos

Nota Avaliação
Carlos Albercio - aluno UNIFOR
A tela ficou meio deformada, não dando pra ver todos os
componentes do sistema e a parte do log poderia ter uma auto-
rolagem” para que o usuário não tivesse que ficar baixando o log
manualmente para poder entender o que esta acontecendo no
sistema.

Algumas mensagens de erro poderia explicar melhor o que
6.5 aconteceu para que ela fosse exibida, como por exemplo quando
aperta o botão começar sem ter criado alguma criança, diz algo
como “que as crianças podem ter sido criadas, mas os tempo não
terem sido definidos e que tem que certificar-se de criar as crianças
e definir seus tempos”, invés disso poderia simplesmente informar
que nenhuma criança foi criada.

Alguns padrões de criação de variáveis e métodos não foram
seguidos, alguns começam com letra maiúscula e o código está
pouco documentado.

Poderia ter tido um pouco mais de trabalho na estruturação do
8 código, porém já foi justificado no próprio documento auxiliar um
dos motivos. Mas o objetivo final foi bem realizado com uma
representação visual de uma forma bem intuitiva e didática.

Funcionou conforme o esperado, exceto pelo fato de as threads
7 entrarem em deadlock em alguns testes e o programa não fazer um
tratamento adequado, ou exibir alguma mensagem. Não possui
documentação, embora possua um bom tutorial.

Francisco José - aluno FA7
Pouca documentação. O aplicativo é de fácil inicialização.
Boa interface gráfica, porém apresentando uma falha na
renderização do cesto. Interface intuitiva o que facita o
4 entendimento.

Métodos sem comentáros. O programa não esta funcionando como
informado no manual de instruções, após as bolas serem guardadas
no cesto a criança que ficou esperando não pegou a bola no cesto.

Dificuldade para ver todos os componentes do sistema e a parte do
5.5 log poderia ter uma auto- rolagem”. Mensagens de erro com textos
de difícil entendimento. Alguns padrões de criação de variáveis e
métodos não foram seguidos, alguns começam com letra maiúscula
e o código está pouco documentado.


Alunos

Nota Avaliação
1

5º - Germano Machado Duarte
Faculdade: UNIFOR
Professor: Raimundo Tales Benigno
Link p/ o trabalho: http://tiny.cc/n1g7f

Proﬁssionais

Nota Avaliação
Muito bom tema. O aluno fez bom uso do JSF e de CSS. Código
enxuto e simples de ler. Ajustes como conditional comments para
usuários de internet explorer são sempre bem vindos (vale estudar
graceful degradation).
8.5
O Lucene hoje em dia é uma das ferramentas mais utilizadas nas
empreas para fazer buscas textuais. Muitos (eu inclusive) reclamam
da complexidade de sua API e configurações que devem ser feitas
quando se precisa de um ajuste mais fino. Nesse caso, existem
ferramentas que te auxiliam, como o Hibernate Search ou o Solr,
que eu recomendo ao aluno estudar.


Proﬁssionais

Nota Avaliação
Trata-se de um dos conteúdos submetidos mais avançados e cujo
domínio teórico e prático tem grandes potenciais de distinção
profissional. A documentação está bem escrita, mas carece de
instruções sobre o uso da interface Web (como indexar, como
pesquisar).

No aplicativo, nenhuma URL pode ser indexada, por ausência da
biblioteca ICU [1]. Ao se realizar o download manual da citada lib,
outra dependência insatisfeita é revelada [2]. Se nenhuma URL é
informada, uma StringIndexOutOfBoundsException é lançada.

Infelizmente, com todos esses problemas, tornou-se inviável a
1
avaliação de tão promissor trabalho.

[1] javax.servlet.ServletException: #{servidorBean.indexarPagina}:
java.lang.NoClassDefFoundError: com/ibm/icu/text/
StringPrepParseException
javax.faces.webapp.FacesServlet.service(FacesServlet.java:
277)

[2] javax.servlet.ServletException: #{servidorBean.indexarPagina}:
java.lang.NoClassDefFoundError: Could not initialize class
com.hp.hpl.jena.iri.IRIFactory
j ava x . f a c e s . w e b a p p. Fa c e s S e r v l e t . s e r v i c e
(FacesServlet.java:277)

Instalei a app no Tomcat 6.0.26 (que acabara de baixar da Apache) conforme
as instruções e acessei-a no endereço indicado. Quando fui interagir com a
funcionalidade de indexação o browser acusou uma
7.7 java.lang.NoClassDefFoundError: com/ibm/icu/text/
StringPrepParseException. Em outro momento apareceu um outro stacktrace
na página acusando o erro java.lang.NoClassDefFoundError: Could
not initialize class com.hp.hpl.jena.iri.IRIFactory.


Proﬁssionais

Nota Avaliação
A execução do programa falhou por falta da biblioteca
icu4j-3.4.4.jar e só foi possível testar a aplicação depois de depurar
o código e descobrir o que estava faltando. Cuidado ao distribuir
suas aplicações! Um usuário normal provavelmente teria desistido
de testar sua aplicação no primeiro erro. Os testes foram realizados
em um Tomcat 6, sem nenhuma configuração adicional, conforme
instruções de instalação.

Cuidado na utilização de marcas. Você provavelmente não poderia
usar o nome "Google" na sua aplicação (a menos que você tenha
tido autorização do Google para isso).

As classes precisam ser melhor documentadas: falta Javadoc em
muitas delas.

Tome cuidado com alguns elementos que podem prejudicar muito a
8.5 performance da sua aplicação. A aplicação criada pode manipular
uma grande quantidade de dados e performance neste caso é muito
importante. Um exemplo: tente não criar objetos que poderiam ser
reaproveitados dentro de laços. No método
OntologyClass.createIndex, um DecimalFormat é criado com a
mesma definição a cada iteração do laço. Tente fazer este tipo de
criação de objetos fora do laço e você terá ganhos significativos de
performance.

Na aplicação, o botão Listar Primeiros está sem ação.

A aplicação faz uma boa separação entre camadas, implementando
o modelo MVC.

A escolha do tema do trabalho é interessante e apresenta um bom
nível de complexidade, trabalhando com diversas tecnologias
diferentes e algumas delas não usuais.

Javadoc - Faltou o Javadoc e não comentou todas as classes
8 deixando a documentação pobre. Apenas criou um documento do
que estava sendo feito.


Proﬁssionais

Nota Avaliação
Justificativa para a nota: Infelizmente não rodou, sendo assim, não
consegui comprovar a utilização e a veracidade da aplicação. Apesar
de não conseguir executar a aplicação a mesma parece esta bem
escrita. O WAR estava faltando uma dependência que foi necessária
baixar: http://dev.eclipse.org/viewsvn/index.cgi/org.eclipse.sdk-
feature/plugins/com.ibm.icu/

Possui pouca documentação, mas parece esta bem estruturada.
Possui descrição do Javadoc incompleta.
6
Sobre o valor do projeto em relação ao mercado: É uma aplicação
de grande valor de mercado, pois a medida que a tecnologia se
desenvolve, cada vez mais arquivos são compartilhados no mundo e
a dificuldade e encontrá-los passa a ser crítica já que o tempo esta
cada vez mais concorrido.

Sobre os critérios de qualidade: A aplicação pecou por não funcionar
e por faltar biblioteca no war. Possui javadoc incompleto, mas
ap arent ement e o cód i g o p rod uz i d o é b em p rofi ssi onal .
Aparentemente não utilizou-se de PMD e Findbugs.

Tive problemas de setup não explicados na documentação. Sem
6.9 diferenciais que poderiam ser atrativos na comercialização, porém
poderia ser utilizado como uma máquina de busca de um site.
Potencial de vendas médio e qualidade média.

UI bem limpa, JSPs com código limpo e bem organizado. Arquivo de
instrução claro e objetivo. Trabalho bem interessante e interessante
o fato de ter juntado conhecimento acadêmico com framework
9 utilizado pelo mercado. Fez bom uso do framework. Fez uso de
documentação em algumas classes e alguns métodos. Alguns em
português e outros em inglês (é bom seguir um padrão). Poderia ter
adicionado mais comentários ao longo do código.

Foram encontradas algumas Bad Practices, mas nada assustador.


Proﬁssionais

Nota Avaliação

1) Apesar da aplicação não apresentar problemas na hora do
deployment, durante a execução do programa, ocorreu um erro
grave na hora de realizar uma indexação de uma URL. Ao entrar
com a URL a clicar no botão "Indexar", ocorreu o seguinte erro:

javax.faces.FacesException: #{servidorBean.indexarPagina}:
java.lang.NoClassDefFoundError: com/ibm/icu/text/
StringPrepParseException

Como o problema está relacionado a uma questão básica de
7.25
dependências de arquivos JAR, foi decontado 2.0 do candidato
principalmente por se tratar de uma funcionalidade que é
principal para a solução.

2) O código do programa apresenta pouco controle de instâncias
de objetos quanto as suas referências. Erros do tipo
pontos do resultado final. Quando um projeto é mantido apenas por
um programador, falhas como essa tendem a ser contornadas ou
inibidas. Mas em um projeto onde vários programadores atuam no
código fonte, este tipo de controle de código deve ser obrigatório.


Pug2009 documento final

Recommandé

Recommandé

Contenu connexe

Similaire à Pug2009 documento final

Similaire à Pug2009 documento final (20)

Pug2009 documento final