Você está na página 1de 16

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico
0

Departamento de Informtica

(INF 09324) 2014/2


Prof. Vtor E. Silva Souza

Especificao do Trabalho Prtico


O trabalho prtico da disciplina consiste em desenvolver um sistema computacional para
soluo do problema descrito abaixo na linguagem de programao Java, inicialmente sem
interatividade com o usurio e posteriormente adicionando interface grfica interativa.

1. Descrio do problema
Uma revista de informtica, a EngeSoft, deseja um novo sistema para gerenciar suas
atividades. EngeSoft publicada mensalmente, sendo que uma edio tem diversos
artigos, todos versando sobre um mesmo tema. Por exemplo, a edio deste ms sobre
o tema Qualidade de Software, tendo oito artigos. De uma edio deseja-se saber o
volume, nmero, data prevista de publicao, tema e artigos submetidos.
Autores submetem artigos para uma edio especfica. De um artigo deseja-se saber os
autores e o ttulo. Os autores devem informar, alm de seus nomes, e-mails e as
instituies a que pertencem, com endereo. Para artigos com mais de um autor, deve ser
indicado um autor como contato.
Para avaliar os artigos submetidos publicao, a EngeSoft possui um conjunto de
colaboradores que avaliam artigos (chamados revisores). Dos revisores deseja-se saber o
nome, e-mail, instituio e temas para os quais est habilitado a avaliar artigos.
Essas informaes so usadas para distribuir os artigos para os colaboradores. Cada artigo
obrigatoriamente avaliado por trs revisores, todos habilitados ao tema da edio
correspondente, que atribuem notas de 0 a 10 (com at uma casa decimal) a trs itens:
originalidade, contedo e apresentao. Com base nessas avaliaes que se decide se
um artigo ser publicado ou no. Para simplificar, considere que um revisor obrigado a
avaliar um artigo quando este lhe atribudo (ou seja, no pode haver cancelamento de
atribuio).
Artigos que j foram avaliados pelos seus trs revisores esto prontos para a seleo de
quais artigos sero publicados na edio em questo, caso contrrio encontram-se ainda
em avaliao. Apenas quando todos os artigos submetidos para uma edio tiverem sido
avaliados que a seleo pode ser efetuada. Esta seleo feita pelo editor-chefe da
edio, escolhido previamente no conjunto de colaboradores. Finda a seleo, sabem-se
quais artigos foram selecionados para publicao e quais foram rejeitados.
A diretoria da revista EngeSoft gostaria de um sistema para auxiliar a tarefa do editorchefe de cada edio. O sistema dever, dadas as avaliaes dos artigos, calcular as
mdias das avaliaes e apresentar ao editor-chefe um relatrio dos artigos avaliados, por
ordem de mdia das avaliaes. So pedidos, ainda, alguns relatrios complementares,
descritos nas prximas sees.
O projeto de construo de um sistema para a revista EngeSoft se dar em duas etapas:
na primeira etapa, os dados sero mantidos em planilhas eletrnicas e, quando todos os
dados estiverem prontos, eles sero passados ao programa, que produzir relatrios de
acordo com os dados fornecidos (vide seo 2). Numa segunda etapa, ser construda
uma interface grfica com o usurio para que os dados sejam inseridos diretamente no
novo sistema, promovendo uma maior interatividade com o usurio.

Universidade Federal do Esprito Santo


Centro Tecnolgico
Departamento de Informtica

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

2. Primeira etapa
Para a primeira etapa, dever ser construdo um software sem interatividade, que efetua a
leitura dos arquivos de entrada e produz automaticamente os relatrios de sada. Para
uma transio mais lenta entre o sistema atual (manual) e um sistema completamente
informatizado, foi combinado que os cadastros seriam feitos em planilhas eletrnicas ao
longo do ms e, assim que estivessem completos (todas as informaes da edio), eles
seriam passados ao software para gerao dos relatrios.
Para o processamento destes dados e gerao dos relatrios desejados, um funcionrios
da EngeSoft ir exportar os dados das planilhas para arquivos de texto simples com
valores separados por vrgulas, conhecido como CSV (Comma Separated Values). No
entanto, para evitar conflito com representao de valores decimais (ex.: 3,9), os dados
sero exportados utilizando ponto-e-vrgula como separador (ex.: 123;456;9,5;7,8;8,0
representando que o revisor 123 avaliou o artigo 456 e atribuiu-lhe as notas 9,5; 7,8; e
8,0).
Para facilitar a leitura dos relatrios produzidos pelo programa, ser feita a importao dos
dados dos relatrios do formato CSV para planilha eletrnica. Portanto, seu programa
deve ser capaz de ler dados neste formato e gerar os relatrios tambm no mesmo
formato.
O restante desta seo especifica em detalhes como o software deve funcionar na
primeira etapa. A especificao encontra-se dividida em quatro partes: leitura dos dados,
processamento, escrita dos relatrios e tratamento de excees.
2.1. Leitura dos dados
So cinco os arquivos de entrada de dados:

Informaes da edio;
Cadastro de temas;
Cadastro de pessoas;
Cadastro de artigos;
Cadastro de revises.

Os nomes dos arquivos so especificados durante a execuo do programa (vide Seo


3). Abaixo encontra-se especificada a ordem que os dados devem aparecer em cada um
destes arquivos e os tipos de dados esperados. Note, no entanto, que todo arquivo CSV
possui uma linha de ttulo (a 1 linha) que no deve ser lida como dado, mas sim
descartada. Consulte os exemplos disponveis junto ao script de testes.
Informaes da edio
<Nome do tema>
<Nome do editor-chefe>
<Volume>
<Nmero>
<Data de publicao>
Ao contrrio dos cadastros, o arquivo de informaes da edio no encontra-se em
formato CSV. Ele contm informaes de uma nica edio (a que est sendo produzida)

Universidade Federal do Esprito Santo


Centro Tecnolgico
0

Departamento de Informtica

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

e cada informao encontra-se em uma linha diferente. Volume e nmero so numricos


(inteiros), data de publicao uma data no formato dia/ms/ano-com-4-dgitos e os
demais campos devem ser lidos como texto.
Cadastro de temas
<nome>;<cdigos dos revisores capacitados para o tema>
Os cdigos dos revisores so numricos (inteiros) e separados por vrgula. Nome deve ser
lido como texto.
Cadastro de pessoas
<cdigo>;<nome>;<email>;<instituio>;<endereo>;<tipo>
Cdigo numrico (inteiro), tipo deve ser A (para autor) ou R (para revisor) e os demais
campos devem ser lidos como texto.
Cadastro de artigos
<cdigo>;<ttulo>;<cdigos dos autores>;<cdigo do autor contato>
Todos os cdigos so numricos (inteiros) e os cdigos dos autores so separados por
vrgula. O cdigo do autor contato s obrigatrio quando o artigo tem mais de um autor.
O ttulo deve ser lido como texto.
Cadastro de revises
<cdigo do artigo>;<cdigo do revisor>;<nota originalidade>;<nota
contedo>;<nota apresentao>
Todos os dados so numricos, sendo os cdigos inteiros e as notas nmeros reais com
at 1 casa decimal.
2.2. Processamento
Lidos todos os dados, o programa deve criar objetos em memria representando as
informaes contidas nos arquivos de entrada. Tais objetos devem estar ligados
adequadamente, conforme as associaes entre as classes de objetos.
Antes de proceder para os clculos e escrita dos relatrios, preciso efetuar uma
verificao de consistncia dos dados. A tabela abaixo lista os possveis problemas de
consistncia que podem ocorrer e o que deve ser includo no relatrio de resumo (vide
prxima subseo) no caso dos dados no estarem consistentes.
#

Possvel inconsistncia

A incluir no resumo

O nome do tema em Informaes da O tema "<nome do tema>" no foi


edio no existe no Cadastro de temas encontrado no cadastro.

O
nome
do
editor-chefe
em O editor-chefe "<nome do editor-chefe>"
Informaes da edio no existe no no foi encontrado no cadastro.
Cadastro de pessoas como um revisor.

Universidade Federal do Esprito Santo


Centro Tecnolgico
0

Departamento de Informtica

Possvel inconsistncia

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

A incluir no resumo

Revisores referenciados no Cadastro de O cdigo <cdigo do revisor> associado ao


temas no correspondem a revisores no tema "<nome do tema>" no corresponde
Cadastro de pessoas.
a um revisor cadastrado.

No h ao menos 3 revisores no O tema "<nome do tema>" possui apenas


Cadastro de temas para o tema da <X> revisores. So necessrios no mnimo
edio em questo.
3 revisores.

Uma das pessoas no Cadastro de O tipo de "<nome da pessoa>" no um


pessoas possui tipo diferente de A ou R. tipo vlido: <tipo>.

Autores referenciados no Cadastro de O cdigo <cdigo do autor> associado ao


artigos no correspondem a autores no artigo "<ttulo do artigo>" no corresponde
Cadastro de pessoas.
a um autor cadastrado.

O autor de contato no Cadastro de O autor "<nome do autor de contato>"


artigos no um dos autores do artigo (<endereo do autor de contato>)
em questo.
informado como autor de contato no
corresponde a um dos autores do artigo
"<ttulo do artigo>".

Revisores referenciados no Cadastro de O cdigo <cdigo do revisor> encontrado


revises no correspondem a revisores no cadastro de revises no corresponde a
no Cadastro de pessoas.
um revisor cadastrado.

Artigos referenciados no Cadastro de O cdigo <cdigo do artigo> encontrado no


revises no se encontram no Cadastro cadastro de revises no corresponde a um
de artigos.
artigo cadastrado.

10 Revisores referenciados no Cadastro de O revisor "<nome do revisor>" avaliou o


revises no esto aptos a revisar artigo "<nome do artigo>", porm ele no
artigos do tema da edio.
consta como apto a revisar o tema "<nome
do tema>", desta edio.
11 No h exatamente trs revises para O artigo "<ttulo do artigo>" possui <X>
cada artigo no Cadastro de revises.
revises. Cada artigo deve ter exatamente 3
revises.
Alguns problemas de consistncia podem ocorrer mais de uma vez (ex.: se no cadastro de
revises houver mais de um artigo com um nmero de revises diferente de 3, o
problema #11 ocorrer uma vez para cada artigo). Nesse caso devem ser includas no
relatrio mltiplas mensagens, uma para cada ocorrncia do problema.
Caso o programa passe a verificao de consistncia sem erros, ele dever calcular as
estatsticas e as mdias das revises dos artigos de modo a possibilitar a escrita dos dados
nos relatrios. Os dados exatos a serem calculados podem ser vistos na prxima seo,
que descreve em detalhes o que deve ser escrito em cada relatrio.

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico
Departamento de Informtica

(INF 09324) 2014/2


Prof. Vtor E. Silva Souza

2.3. Escrita dos relatrios


So trs os arquivos de sada de dados, listados abaixo com seus respectivos nomes:

Resumo: relat-resumo.txt;
Relatrio de revises: relat-revisoes.csv;
Relatrio de revisores: relat-revisores.csv.

Abaixo encontra-se especificada a ordem que os dados devem aparecer em cada um


destes arquivos e os formatos que devem ser utilizados:
Resumo
EngeSoft, num. <nmero>, volume <volume> - <data>
Tema: <tema>
Editor-chefe: <editor-chefe>
Consistncia dos dados:
<consistncia>
Artigos submetidos: <nmero de artigos submetidos>
Revisores capacitados: <nmero de revisores capacitados ao tema>
Revisores envolvidos: <nmero de revisores que fizeram reviso>
Mdia artigos/revisor: <n artigos cada revisor revisou em mdia>
Ao contrrio dos relatrios, o resumo no deve ser escrito em formato CSV. Ele deve ser
escrito exatamente como acima, substituindo os termos entre < e > pelos valores
apropriados:

Nmero de volume da edio devem ser impressos normalmente como nmeros,


sem formatao especial;
A data deve ser impressa no formato <ms-por-extenso> de <ano-com-4dgitos>. Por exemplo: Setembro de 2014;
Tema e editor-chefe devem ser impressos normalmente como texto, sem
formatao especial;
O campo <consistncia> deve ser substitudo pelas mensagens de erro geradas
durante a validao da consistncia dos dados. As mensagens devem ser impressas
no formato - Erro <#>: <mensagem>, onde <#> deve ser substitudo pelo
nmero do erro (vide 1 coluna da tabela de possveis inconsistncias, apresentada
anteriormente) e <mensagem> deve ser substituda pela mensagem de erro. Por
exemplo:

Consistncia dos dados:


- Erro 8: O cdigo <cdigo do revisor> encontrado no cadastro de
revises no corresponde a um revisor cadastrado.
- Erro 11: O artigo Exemplo de Artigo possui 2 revises. Cada
artigo deve ter exatamente 3 revises.
- Erro 11: O artigo Outro Exemplo de Artigo possui 4 revises.
Cada artigo deve ter exatamente 3 revises.

Universidade Federal do Esprito Santo


Centro Tecnolgico
Departamento de Informtica

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

As mensagens de erro devem ser ordenadas primeiramente pelo nmero do erro e,


em seguida (para erros de mesmo nmero), em ordem alfabtica;
Caso no haja nenhum problema de consistncia, o campo <consistncia>
deve ser substitudo por - Nenhum problema encontrado.;
Por fim, os nmeros inteiros nas estatsticas devem ser impressos normalmente,
sem formatao, enquanto a mdia de artigos por revisor deve ser impressa com 2
casas decimais.

Caso haja qualquer problema de consistncia, as estatsticas ao final do resumo e os


demais relatrios no devem ser gerados. O programa gera s o resumo e s at a
lista de inconsistncias.
Relatrio de revises
<ttulo do artigo>;<autor de contato>;<mdia>;<nome do 1
revisor>;<nome do 2 revisor>;<nome do 3 revisor>
O relatrio de revises deve ser escrito em CSV e conter as informaes de um artigo por
linha. O ttulo do artigo, o autor de contato e os nomes dos revisores devem ser escritos
como texto, sem formatao especial. A mdia deve ser formatada para ter apenas 2
casas decimais e usar separao com vrgula (brasileira). Os revisores de uma mesma
linha do arquivo devem aparecer em ordem alfabtica. O arquivo como um todo deve ser
ordenado em ordem decrescente de mdia. Em caso de empate, ordene alfabeticamente
pelo ttulo do artigo.
Relatrio de revisores
<nome do revisor>;<nmero de artigos revisados>;<mdia das notas
atribudas>
O relatrio de revisores deve conter apenas os revisores que participaram da edio, ou
seja, que revisaram artigos. Eles devem ser includos no relatrio em ordem alfabtica dos
nomes, que devem ser escritos normalmente, sem formatao. O nmero de artigos
revisados um nmero inteiro e tambm no necessita de formatao. A mdia das notas
atribudas deve ser formatada com 2 casas decimais e separao com vrgula.
2.4. Tratamento de excees
Leitura de dados de arquivos, formatao, etc. so fontes comuns de erros e excees.
Seu programa deve tratar apenas os seguintes tipos de erro:
1. Erros de entrada e sada de dados como, por exemplo, o arquivo especificado no
existir ou o programa no ter permisso para ler ou escrever em um arquivo.
Nestes casos, o programa deve exibir a mensagem Erro de I/O (sem as aspas);
2. Erro de formatao dos dados nos arquivos, ou seja, um valor formatado de forma
incorreta nos arquivos de entrada (ex.: encontrado caractere onde esperava-se um
nmero), causando erros de parsing dos dados. Nestes casos, o programa deve
exibir a mensagem Erro de formatao (sem as aspas).
No programa sem interatividade, as mensagens devem ser impressas na tela e o
programa deve ser terminado em seguida. No caso do programa com interface grfica, as

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico

(INF 09324) 2014/2

Departamento de Informtica

Prof. Vtor E. Silva Souza

mensagens devem ser exibidas de alguma forma na interface com o usurio e o programa
deve continuar rodando, permitindo que o usurio modifique os parmetros.
Quaisquer outras situaes de erro possveis devem ser ignoradas. Pode-se assumir que
nos testes feitos durante a avaliao dos trabalhos outros tipos de erros diferentes dos
listados acima nunca acontecero.

3. Execuo (primeira etapa)


Esta seo descreve como o programa deve ser executado aps a primeira etapa (ou seja,
sem interface grfica com o usurio). Seu programa deve ser executado especificando os
nomes dos arquivos de entrada como opes de linha de comando, especificadas a seguir:

-e <arquivo>: informaes da edio;


-t <arquivo>: cadastro de temas;
-p <arquivo>: cadastro de pessoas;
-a <arquivo>: cadastro de artigos;
-r <arquivo>: cadastro de revises.

Apesar do uso do pacote default no ser recomendado, para efeito dos exemplos abaixo
vamos supor que a classe do seu programa que possui o mtodo main() chama-se Main
e encontra-se no pacote default. Portanto, para executar seu programa lendo os arquivos
edicao.txt, temas.csv, pessoas.csv, artigos.csv, revisoes.csv como arquivos de entrada, o
comando seria:
java Main -e edicao.txt -t temas.csv -p pessoas.csv -a
artigos.csv -r revisoes.csv
Recuperao de pontos1: alm dos parmetros acima, possvel recuperar pontos
perdidos: basta que seu programa aceite dois parmetros opcionais que estabelecem trs
modos de execuo diferentes. Neste caso, o programa deve poder ser chamado das trs
formas, como a seguir:
a) java Main -e edicao.txt -t temas.csv -p pessoas.csv -a
artigos.csv -r revisoes.csv: quando no forem especificadas opes de
execuo, o programa deve ler os arquivos de entrada, gerar os relatrios e
escrev-los nos arquivos de sada, como descrito anteriormente;
b) java
Main
--read-only
-e
edicao.txt
-t
temas.csv
-p
pessoas.csv -a artigos.csv -r revisoes.csv: quando especificada a
opo --read-only, o programa deve ler os arquivos de entrada, montar as
estruturas de objetos em memria e serializar essas estruturas em um arquivo
chamado engesoft.dat. Os relatrios no devem ser gerados neste caso;
c) java Main --write-only: quando especificada esta opo, o programa deve
carregar os objetos serializados no arquivo engesoft.dat, gerar os relatrios e
escrev-los nos arquivos de sada. Neste caso no h leitura de arquivo CSV.
1

Recupera pontos perdidos, o que significa que a nota do trabalho no poder ultrapassar o valor mximo
de 10 pontos.
2

Para
saber
mais
sobre
Hash
https://pt.wikipedia.org/wiki/MD5#Hashes_MD5

MD5,

visite

sua

pgina

na

Wikipedia:

Universidade Federal do Esprito Santo


Centro Tecnolgico
0

Departamento de Informtica

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

Note que as opes de execuo podem ser passadas em qualquer ordem. Portanto, o
comando
java Main --read-only -e edicao.txt -t temas.csv -p
pessoas.csv -a artigos.csv -r revisoes.csv
equivalente a:
java Main -r revisoes.csv -p pessoas.csv -e edicao.txt --readonly -t temas.csv -a artigos.csv

4. Segunda etapa
A segunda etapa consiste na criao de uma interface grfica com o usurio (GUI) que
substitua a execuo do programa conforme vista na seo 3 (chamada via terminal/linha
de comando) por uma forma mais interativa.
Ao ser executado sem parmetros (ex.: java Main) seu programa deve abrir uma janela
que permita ao usurio indicar os arquivos de entrada, executar o programa, ver os
arquivos de sada e qualquer outra interao que seja necessria para executar as
funcionalidades desenvolvidas na primeira etapa.
A segunda etapa do trabalho ser apresentada ao professor por meio de entrevista,
conforme descrito na seo 5.3.

5. Condies de entrega
O trabalho deve ser feito obrigatoriamente em dupla e em duas verses, ambas em Java:
uma sem interatividade (primeira etapa) e outra com interface grfica (segunda etapa). O
primeiro deve ser entregue at o dia 07/12/2014, enquanto o segundo deve ser
apresentado ao professor (por meio de entrevista) at o dia 15/12/2014,
impreterivelmente.
Alunos que no fizerem o trabalho em dupla sofrero penalidade de 2 pontos na nota do
trabalho. No caso de haver um nmero mpar de alunos matriculados, o professor indicar
um aluno que poder, a seu critrio, fazer o trabalho sozinho ou juntar-se a uma dupla
para formar um trio. As duplas para os trabalhos 1 e 2 devem ser as mesmas. No caso de
desistncia de aluno, o aluno que se encontrar sozinho para o trabalho 2 deve informar ao
professor para que a situao possa ser solucionada.
Dado que existem vrias verses dos compiladores Java, fica determinado o uso das
verses instaladas nas mquinas do LCEE como verses de referncia para o trabalho
prtico. Seu trabalho deve compilar e executar corretamente nas mquinas do LCEE. Alm
disso, os arquivos de cdigo-fonte devem estar em arquivos codificados com Unicode
(UTF-8) para evitar erros de compilao.

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico
0

(INF 09324) 2014/2

Departamento de Informtica

Prof. Vtor E. Silva Souza

5.1. Entrega do trabalho sem interatividade (correo automtica)


Para o trabalho da primeira etapa (vide sees 2 e 3), sua soluo dever ser compactada
e enviados por e-mail (anexo ao e-mail) para o monitor da disciplina
(caducbraga@gmail.com) e com cpia para o professor (vitorsouza@inf.ufes.br). Sero
aceitos (sem penalidade) trabalhos entregues at as 23h59 da data limite. O assunto do
e-mail dever ser o seguinte:
PAC - Trab1 - Nomes dos alunos
substituindo Nomes dos alunos pelos nomes completos dos alunos do grupo, separado
por vrgula.
Assim que possvel, o monitor responder o e-mail com um hash MD5 2 do arquivo
recebido. Para garantir que o arquivo foi recebido sem ser corrompido, gere o hash MD5
do arquivo que voc enviou3 e compare com o hash recebido na confirmao. Caso voc
no receba o e-mail de confirmao ou caso o valor do hash seja diferente, envie o
trabalho novamente. Se o problema persistir, contate o professor o mais rpido possvel.
Dada a quantidade de trabalhos que devem ser avaliados, a correo dos trabalhos da
primeira etapa passar por um processo de testes automticos. Para que os testes
automticos funcionem, o arquivo compactado enviado por e-mail deve estar no formato
zip com o nome trabalho.zip e conter o arquivo de build (explicaes a seguir) e o
cdigo-fonte. O arquivo enviado no deve conter nenhuma classe compilada. Os testes
automticos sero executados no diretrio onde encontra-se o arquivo de build. O cdigofonte pode ser organizado da forma que a dupla achar melhor, desde que o arquivo de
build esteja adequado a esta estrutura.
5.2. Preparao e execuo do script de testes
O trabalho prtico da disciplina ser avaliado em duas etapas (vide seo 6), sendo a
primeira uma avaliao objetiva, com testes automticos. Foi disponibilizado aos alunos
um script para execuo de alguns testes automticos, sendo portanto possvel garantir
que o trabalho passa nesses testes antes de submet-lo ao professor.
O script de teste funciona somente em ambientes Linux/MacOS e foi testado no LCEE.
Recomenda-se fortemente que os testes finais do seu trabalho sejam feitos no LCEE, pois
as verses das ferramentas instaladas nas mquinas do laboratrio sero consideradas
como verses de referncia para a correo do trabalho.
Para obter e executar o script, siga os passos abaixo:
1. Na pgina da disciplina, obtenha o arquivo teaching-br-pac-20142-script-java.zip;
2. Descompacte o arquivo em alguma pasta do seu sistema;
2

Para
saber
mais
sobre
Hash
https://pt.wikipedia.org/wiki/MD5#Hashes_MD5
3

MD5,

visite

sua

pgina

na

Wikipedia:

Para
gerar
hash
MD5
de
arquivos
no
Linux,
veja
as
instrues
em
http://roneymedice.com.br/2009/07/30/gerando-hash-md5-dos-arquivos-no-linux/.
J
na
pgina
http://www.mundodoshackers.com.br/como-gerar-e-checar-hashs-md5 voc encontra instrues tambm
para Windows (porm os exemplos mostram gerao de hash para strings, no para arquivos).

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico

(INF 09324) 2014/2

Departamento de Informtica

Prof. Vtor E. Silva Souza

3. Abra um terminal, acesse esta pasta;


4. Execute o script: ./test.sh e o resultado deve ser parecido com a sada abaixo:
$ ./test.sh
Script de teste PAC 2014/2 - Trabalho 1
$
O script reconhece trabalhos se forem colocados em pastas no mesmo diretrio em que se
encontra o script test.sh e se os trabalhos seguirem as instrues contidas a seguir.
Note que h j uma pasta testes, que contm os arquivos de teste executados pelo
script. O script j configurado a no considerar esta pasta como uma pasta de trabalho.
No exemplo abaixo, o comando ls mostra que h um diretrio professor dentro do qual
encontra-se a implementao do trabalho do professor. Em seguida, mostra a execuo
do script de testes sem erro algum:
$ ls -Flpah
total 8
drwxr-xr-x
5 vitor
drwxr-xr-x@ 55 vitor
drwxr-xr-x
4 vitor
-rwxr-xr-x@ 1 vitor
drwxr-xr-x
6 vitor

wheel
wheel
wheel
wheel
wheel

170B
1.8K
136B
2.0K
204B

May
May
May
May
May

30
30
30
30
30

18:00
17:54
12:30
17:57
17:24

./
../
professor/
test.sh
testes/

$ ./test.sh
Script de teste PAC 2014/2 - Trabalho 1
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
[I]
$

Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando
Testando

professor...
professor: teste 01
professor: teste 01,
professor: teste 01,
professor: teste 01,
professor: teste 02
professor: teste 02,
professor: teste 03
professor: teste 03,
professor: teste 03,
professor: teste 03,
professor: teste 03,
professor: teste 04
professor: teste 04,
professor: teste 05
professor: teste 05,
professor: teste 06
professor: teste 06,
professor: pronto!

tudo OK em relat-resumo.txt
tudo OK em relat-revisoes.csv
tudo OK em relat-revisores.csv
serializao OK!
serializao OK!
tudo OK em relat-resumo.txt
tudo OK em relat-revisoes.csv
tudo OK em relat-revisores.csv
tudo OK em relat-resumo.txt
tudo OK em relat-resumo.txt
tudo OK em relat-resumo.txt

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico

(INF 09324) 2014/2

Departamento de Informtica

Prof. Vtor E. Silva Souza

O script compara cada arquivo de sada gerado pelo trabalho do aluno com o arquivo de
sada gerado pela implementao do professor. No exemplo acima, nenhum erro foi
encontrado e tudo est OK. Quando diferenas so encontradas, as mesmas so
mostradas na tela e implicam perda de pontos na correo automtica. O aluno deve,
portanto, tentar reduzir o nmero de diferenas ao mximo possvel antes de entregar o
trabalho.
Para testar o seu trabalho, crie uma pasta com um nome qualquer dentro do mesmo
diretrio em que se encontra o script test.sh e copie seu cdigo-fonte para esta pasta.
Alm do cdigo-fonte, crie um arquivo de build do Apache Ant (http://ant.apache.org) que
indique como compilar e executar seu programa.
Os arquivos fonte podem estar organizados da forma que voc achar melhor, desde que o
Ant consiga compil-los, executar as classes geradas e limpar o projeto. Para que isso seja
feito de forma automatizada, o arquivo de build do Ant deve, obrigatoriamente, encontrarse na raiz da pasta criada e chamar-se build.xml. Alm disso, ele deve ser feito de
forma a responder aos seguintes comandos:
Comando

Resultado esperado

ant compile

O cdigo-fonte deve ser compilado, gerando os arquivos


.class para todas as classes do trabalho.

ant run

O programa deve ser executado especificando as opes -e


edicao.csv -t temas.csv -p pessoas.csv -a
artigos.csv -r revisoes.csv como parmetro.

ant run-read-only

O programa deve ser executado no modo --read-only


(ver seo 3), especificando alm disso as mesmas opes
do comando ant run acima.

ant run-write-only

O programa deve ser executado no modo --write-only


(ver seo 3).

ant clean

Todos os arquivos gerados (classes compiladas, relatrios


de sada, arquivo de serializao) e eventuais arquivos de
entrada de dados devem ser excludos, sobrando somente o
contedo original do arquivo compactado (ou seja, o
cdigo-fonte e o arquivo de build).

Caso voc no implemente as opes read-only e write-only, faa com que os respectivos
comandos funcionem da mesma forma que o comando run, ou seja, efetuem a execuo
normal.
Segue abaixo um exemplo de arquivo build.xml que atende s especificaes acima.
Em negrito encontram-se marcados os dados que devem ser adaptados dependendo do
projeto:

src: subpasta onde encontra-se todo o cdigo-fonte;


bin: subpasta onde sero colocadas as classes compiladas;

Universidade Federal do Esprito Santo


Centro Tecnolgico
Departamento de Informtica

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

meupacote.MinhaClassePrincipal: nome da classe principal do programa,


ou seja, aquela que possui o mtodo main().

<project name="TrabalhoPAC_2014_2" default="compile" basedir=".">


<description>Arquivo de build do trabalho de PAC, 2014/2.</description>
<!-- Propriedades do build. -->
<property name="src" location="src" />
<property name="bin" location="bin" />
<property name="mainClass" value="meupacote.MinhaClassePrincipal" />
<!-- Inicializao. -->
<target name="init" description="Inicializa as estruturas necessrias.">
<tstamp/>
<mkdir dir="${bin}" />
</target>
<!-- Compilao. -->
<target name="compile" depends="init" description="Compila o cdigofonte.">
<javac includeantruntime="false" srcdir="${src}" destdir="${bin}" />
</target>
<!-- Execuo normal. -->
<target name="run" depends="compile" description="Executa o programa
principal, em modo normal.">
<java classname="${mainClass}">
<arg value="-r" />
<arg value="revisoes.csv" />
<arg value="-p" />
<arg value="pessoas.csv" />
<arg value="-e" />
<arg value="edicao.txt" />
<arg value="-t" />
<arg value="temas.csv" />
<arg value="-a" />
<arg value="artigos.csv" />
<classpath>
<pathelement path="${bin}" />
</classpath>
</java>
</target>
<!-- Execuo somente leitura. -->
<target name="run-read-only" depends="compile" description="Executa o
programa principal, em modo somente leitura.">
<java classname="${mainClass}">
<arg value="-e" />
<arg value="edicao.txt" />
<arg value="-t" />
<arg value="temas.csv" />
<arg value="-p" />
<arg value="pessoas.csv" />
<arg value="--read-only" />
<arg value="-a" />
<arg value="artigos.csv" />
<arg value="-r" />
<arg value="revisoes.csv" />
<classpath>
<pathelement path="${bin}" />

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico

(INF 09324) 2014/2

Departamento de Informtica

Prof. Vtor E. Silva Souza

</classpath>
</java>
</target>
<!-- Execuo somente escrita. -->
<target name="run-write-only" depends="compile" description="Executa o
programa principal, em modo somente escrita.">
<java classname="${mainClass}">
<arg value="--write-only" />
<classpath>
<pathelement path="${bin}" />
</classpath>
</java>
</target>
<!-- Limpeza. -->
<target name="clean" description="Limpa o projeto, deixando apenas o
cdigo-fonte." >
<delete dir="${bin}"/>
<delete><fileset dir="." includes="*.txt"/></delete>
<delete><fileset dir="." includes="*.csv"/></delete>
<delete><fileset dir="." includes="*.dat"/></delete>
</target>
</project>

Recuperao de pontos4: ser dado 1 ponto extra ao grupo que preparar e enviar ao
professor, at o prazo do trabalho 1, dois conjuntos de arquivos de entrada (edicao.txt,
temas.csv, pessoas.csv, artigos.csv e revisoes.csv) que atendam aos seguintes critrios:

No conter trechos iguais a outros arquivos de teste disponveis no site;

Conter o cadastro de pelo menos 5 temas, 5 revisores, 15 autores e 10 artigos;

Os dois conjuntos de arquivos devem ser quase iguais: um deles no deve ter
inconsistncia nenhuma enquanto o outro deve apresentar de 2 a 4 inconsistncias
(a escolha do grupo), de acordo com a tabela da seo 2.2.

Os arquivos de teste enviados podero, a critrio do professor, ser disponibilizados aos


demais alunos como parte do script de testes. Atualizaes do script sero divulgadas em
sala de aula.
5.3. Apresentao do trabalho em entrevista
O trabalho completo (primeira e segunda etapas concludas) deve ser apresentado ao
professor por meio de entrevista. Para tal, os alunos devem acessar o sistema de
marcao de horrios YouCanBook.Me no seguinte endereo:
https://vitorsouza.youcanbook.me

Idem seo 3.

Universidade Federal do Esprito Santo

Programao Aplicada de Computadores

Centro Tecnolgico

(INF 09324) 2014/2

Departamento de Informtica

Prof. Vtor E. Silva Souza

Na tabela de horrios que se apresenta, cada dupla deve agendar um horrio, dentre os
horrios disponveis, at a data limite (15/12/2014), com durao de 30 minutos e
fornecendo os dados solicitados pelo formulrio (nome e e-mail). Para o propsito da
reunio, selecionar a opo Aluno(a) de Programao Aplicada de Computadores.
Ateno aos seguintes detalhes sobre o agendamento:

O sistema s permite agendamentos com antecedncia mnima de 8 horas (e


mxima de 2 semanas);
O sistema bloqueia automaticamente horrios j reservados ou em que o professor
tenha outros compromissos;
de responsabilidade do aluno achar um horrio disponvel. Planeje-se com
antecedncia para evitar problemas de ltima hora (ex.: falta de horrios
adequados).

Uma vez agendada a reunio, os alunos devem comparecer sala do professor (Ufes, CT7, 1 andar, sala 28) para a entrevista pontualmente no dia e hora marcados. A
apresentao do trabalho pode ser feita em computador porttil trazido pelos alunos ou
no computador do professor. Em qualquer caso, os alunos devem tambm trazer o
cdigo-fonte do trabalho em disco removvel (pen-drive) para o professor.
A entrevista consiste em uma apresentao do trabalho em funcionamento feita pelos
alunos, seguida de uma entrevista feita pelo professor. Na entrevista, os alunos sero
questionados individualmente sobre detalhes do trabalho e sero avaliados com relao
s respostas fornecidas. Os critrios de avaliao so descritos na seo a seguir.

6. Critrios de avaliao
O trabalho ser avaliado em duas etapas, conforme descrito na seo anterior:

Avaliao objetiva com testes automticos, valendo 10 pontos;


Avaliao subjetiva em entrevista, valendo 10 pontos.

A nota final do trabalho a mdia aritmtica simples entre as notas acima. Para a
avaliao objetiva, todo trabalho possui inicialmente nota 10 e sofre modificaes nas
situaes descritas na tabela abaixo:
Situao

Modificao

No observou as regras para envio do trabalho 1.

-1

No foi feito em dupla.

-2

No compilou nos testes automticos, mas foi possvel corrigir


manualmente (ex.: arquivos no codificados em UTF-8).

-3

No compilou nem manualmente.

-10

No gerou sadas nos testes automticos.

-5

No gerou sadas nem manualmente.

-8

Universidade Federal do Esprito Santo


Centro Tecnolgico

(INF 09324) 2014/2

Departamento de Informtica

Programao Aplicada de Computadores

Prof. Vtor E. Silva Souza

Situao

Modificao

Pequenas diferenas das sadas em relao ao teste automtico (ex.:


formatao, arredondamentos, etc.).

-1

Grandes diferenas das sadas em relao ao teste automtico (ex.:


valores sensivelmente diferentes).

-2

Entrega fora do prazo.


Opes --read-only e --write-only funcionaram no teste
automtico.

-1 por dia
+2

Para avaliao subjetiva, novamente os trabalhos comeam com nota 10 e perdem pontos
(que variam de acordo com a avaliao feita pelo professor) caso no estejam bem
escritos ou organizados. Critrios utilizados na avaliao subjetiva incluem (mas no esto
limitados a):

Uso dos princpios bsicos da orientao a objetos, como encapsulamento,


abstrao e modularizao;
Legibilidade (nomes de variveis bem escolhidos, cdigo bem formatado, uso de
comentrios quando necessrio, etc.);
Consistncia (utilizao de um mesmo padro de cdigo, sugere-se a conveno de
cdigo do Java: http://www.oracle.com/technetwork/java/codeconv-138413.html);
Eficincia (sem exageros, tentar evitar grandes desperdcios de recursos);
Uso eficaz da API Java (leitura com Scanner, API de colees, etc.) e das
funcionalidades das novas verses da plataforma (ex.: tipos genricos, lao foreach, try com recursos fechveis, etc.);
Se o aluno sabe responder questes formuladas pelo professor durante a entrevista
sobre o cdigo-fonte escrito pela dupla.

7. Pontos extra5
Para incentivar alunos que desejarem aprender contedos avanados da linguagem Java
por conta prpria, so oferecidos pontos extra para os alunos que demonstrarem na
entrevista final do trabalho que adicionaram uma ou mais das seguintes funcionalidades
ao programa:
Funcionalidade opcional

Pontos extra

Substituio da serializao descrita na seo 3 por armazenamento


em banco de dados utilizando a tecnologia JDBC.

At 2 pontos

Apesar dos pontos extras permitirem que a nota do trabalho Java ultrapasse o valor mximo de 10 pontos,
no clculo da mdia parcial do aluno, a nota mxima continua sendo 10, no podendo ser ultrapassada.

Universidade Federal do Esprito Santo


Centro Tecnolgico
0

Departamento de Informtica

Programao Aplicada de Computadores


(INF 09324) 2014/2
Prof. Vtor E. Silva Souza

Substituio da serializao descrita na seo 3 por armazenamento


em banco de dados utilizando alguma tecnologia de mapeamento
objeto/relacional (ex.: Hibernate).

At 2 pontos

A coluna Pontos extra indica o mximo de pontos extra que podem ser obtidos pela
implementao da funcionalidade extra correspondente. A pontuao exata ser
estabelecida pelo professor aps avaliado o cdigo, que deve ser explicado pelos alunos.

8. Observaes finais
Caso haja algum erro neste documento, sero publicadas novas verses e divulgadas
erratas em sala de aula. responsabilidade do aluno manter-se informado, frequentando
as aulas ou acompanhando as novidades na pgina da disciplina na Internet.