UNICAMP - UNIVERSIDADE ESTADUAL DE CAMPINASINSTITUTO DE COMPUTACAO

Sistema de Informacao para Gerenciamento deCandidatos ao Programa de Pos-Graduacao do

IC/UNICAMP

Relatorio final

Disciplina:

MO410 - Bancos de Dados

Componentes:

Cristiano Dalmaschio Ferreira (049239)

Jaudete Daltio (049240)

Conteudo

1 Introducao e Motivacao 1

2 Metodologia 2

3 Etapa de Levantamento de Requisitos e Projeto 33.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2 Diagrama Entidade-Relacionamento Proposto . . . . . . . . . . . . . . . . . . . . . . 73.3 Funcionalidades Desejaveis do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Etapa de Implementacao 164.1 Tecnologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Implementacao do Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Casos de uso implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Caso de uso: Cadastrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.2 Caso de uso: Inscrever . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3.3 Caso de uso: Fazer Upload de Documentos . . . . . . . . . . . . . . . . . . . 214.3.4 Caso de uso: Indicar Recomendante . . . . . . . . . . . . . . . . . . . . . . . 214.3.5 Caso de uso: Acessar Documentos . . . . . . . . . . . . . . . . . . . . . . . . 224.3.6 Caso de uso: Emitir Parecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.7 Caso de uso: Alocar Candidato-Professor . . . . . . . . . . . . . . . . . . . . 224.3.8 Caso de uso: Acessar Parecer . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.9 Caso de uso: Definir Candidatos Aceitos . . . . . . . . . . . . . . . . . . . . . 234.3.10 Caso de uso: Notificar Candidatos Aceitos . . . . . . . . . . . . . . . . . . . . 23

4.4 Funcionalidades desejaveis Implementadas no Sistema . . . . . . . . . . . . . . . . . 234.5 Consultas Suportadas pelo Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Dificuldades Enfrentadas 26

6 Trabalhos Futuros 27

7 Conclusoes 28

A Apendice - Banco de Dados em SQL 30

B Apendice - Banco de Dados Implementado 37

C Apendice - Telas da Interface do Sistema 38

Lista de Figuras

1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Arquitetura adotada e tecnologias utilizadas. . . . . . . . . . . . . . . . . . . . . . . 183 Modelo Relacional Implementado, gerado pelo software ERWin [3] . . . . . . . . . . 194 Casos de Uso Implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Banco de Dados Implementado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Interface de Cadastro para Usuarios Candidatos no Sistema . . . . . . . . . . . . . . 387 Interface de Login no sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1

8 Interface da Escolha de Papel para Acessar o Sistema . . . . . . . . . . . . . . . . . 409 Interface do Formulario de Inscricao: Dados Pessoais e Endereco . . . . . . . . . . . 4110 Interface do Formulario de Inscricao: Dados sobre o Programa e Outras Informacoes 4211 Interface do Formulario de Inscricao: Formacao Academica . . . . . . . . . . . . . . 4312 Interface do Formulario de Inscricao: Insercao de varias Formacoes Academicas . . . 4413 Interface do Formulario de Inscricao: Bolsas de Estudo . . . . . . . . . . . . . . . . . 4514 Interface do Formulario de Inscricao: Experiencia Profissional . . . . . . . . . . . . . 4615 Interface do Formulario de Inscricao: Envio de Documentos Juntamente com a Ins-

cricao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4716 Interface do Formulario de Inscricao: Areas de Interesse e Plano de Trabalho . . . . 4817 Interface do Formulario de Inscricao: Indicacao de Recomendantes . . . . . . . . . . 4918 Interface para a Emissao de Parecer com a Visualizar dos Documentos do Candidato 5019 Interface de Acesso a Documentos do Candidato: Historico . . . . . . . . . . . . . . 5120 Interface para a Alocacao de Candidatos a Professores Avaliadores . . . . . . . . . . 5221 Interface para a Avaliacao Final dos Candidatos . . . . . . . . . . . . . . . . . . . . 53

2

1 Introducao e Motivacao

O Instituto de Computacao (IC) da UNICAMP oferece cursos de Mestrado Academico e Dou-torado em Ciencia da Computacao. O curso de Mestrado do IC-UNICAMP foi criado oficialmenteem 1977, e o de Doutorado em 1993 (ambos no entao Departamento de Ciencia da Computacao doIMECC-UNICAMP). Estes cursos tem recebido boas avaliacoes dos orgaos de fomento a pesquisa ede outras entidades. Tanto o Mestrado quanto o Doutorado do IC tem grande prestıgio na industriae nas universidades brasileiras, e atraem estudantes de toda a America Latina.

O processo seletivo do programa de pos-graduacao do IC da UNICAMP recebe muitas inscricoespor ano. A inscricao e a avaliacao dos candidatos pela Comissao de Pos-Graduacao (CPG) demandaum certo empenho por parte dos envolvidos e uma deficiencia existente atualmente e a dificuldadede recuperacao de informacoes referentes a processos anteriores. A inscricao e avaliacao via “papel”fazem com que muitas informacoes importantes sejam perdidas, tanto no que diz respeito aos dadosdos candidatos, que posteriormente podem se tornar alunos regulares, como tambem a respeito daselecao em si, de quais docentes auxiliaram no processo e de que forma.

O objetivo deste trabalho e a especificacao e implementacao de um sistema web que permitao gerenciamento do processo de selecao de candidatos nos programas de pos-graduacao oferecidospelo IC. A solucao proposta devera prover o gerenciamento de dados relacionados ao processo deselecao. Dentre esses dados estao as fichas de inscricao dos candidatos, as cartas de recomendacao eos pareceres emitidos pelos professores avaliadores. Desta forma, espera-se armazenar um historicorelativo aos processos seletivos que ocorrem. Com isso, sera possıvel tambem fazer um levantamentosobre as tentativas feitas por um candidato para ingressar no programa e, sempre que necessario,saber quais foram seus resultados em processos anteriores.

As principais contribuicoes deste trabalho sao:

• Levantamento dos documentos e formularios necessarios para a inscricao de candidatos deMestrado e Doutorado no IC, o que possibilita a correcao de possıveis inconsistencias e re-dundancias existentes;

• Modelagem e implementacao de um banco de dados que comporta as informacoes armazena-das pelo sistema;

• Especificacao e implementacao parcial de um sistema web, utilizando o banco de dados im-plementado, para o gerenciamento do processo de selecao do programa de pos-graduacao doIC;

• Armazenamento digital das informacoes relativas aos processos de selecao;

• Possibilitar consultas as informacoes relativas a processos seletivos realizados.

O restante deste documento esta organizado como segue. A secao 2 descreve a metodologiaempregada no desenvolvimento deste projeto. A secao 3 mostra aspectos relevantes da etapade levantamento e analise de requisitos, incluindo a versao final do diagrama de casos de uso edo diagrama ER. Questoes relativas a implementacao do sistema sao exibidas na secao 4. Emsequencia, descreve-se as principais dificuldades enfrentadas no desenvolvimento do projeto nasecao 5. A secao 6 descreve alguns possıveis trabalhos futuros e, finalmente, a secao 7 mostra asconclusoes deste projeto.

1

2 Metodologia

A metodologia utilizada no desenvolvimento do projeto consistiu em tres etapas: levantamentoe analise de requisitos, implementacao e validacao do sistema.

A primeira etapa consistiu no levantamento dos formularios e documentos necessarios paraa inscricao de candidatos no processo de selecao da pos-graduacao e em uma analise do funci-onamento atual desse processo. Com base nesses requisitos, especificou-se os casos de uso quedeveriam ser contemplados pelo sistema e projetou-se uma versao inicial do diagrama Entidade-Relacionamento para o gerenciamento dos dados manipulados. Foram realizadas varias entrevistascom os professores Ricardo Torres e Rodolfo Jardim de Azevedo, envolvidos no processo de selecao,que destacaram algumas funcionalidades desejaveis do sistema. Essas entrevistas influenciaramsubstancialmente na especificacao do sistema, impactando diretamente na segunda etapa prevista,a implementacao. O diagrama Entidade-Relacionamento proposto inicialmente passou por variosrefinamentos e simplificacoes, baseados nas informacoes obtidas nas entrevistas e em discussoesentre os desenvolvedores, adequando-se a atender as necessidades previstas do sistema.

A segunda etapa consiste na implementacao do banco de dados relacional gerado a partir dodiagrama ER proposto na etapa de requisitos e a implementacao do sistema de gerencimento webpara o processo de selecao. Realizou-se a princıpio uma analise das tecnologias disponıveis vi-sando uma escolha apropriada de quais seriam utilizadas na implementacao. Por restricoes detempo disponıvel para o desenvolvimento do projeto, essa etapa contemplou a implementacao deum sub-conjunto dos casos de uso especificados, capaz de simular um processo seletivo. Os ca-sos de uso escolhidos foram: CADASTRAR e INSCREVER (relacionados ao usuario candidato);ACESSAR DOCUMENTOS e EMITIR PARECER (relacionados ao usuario professor); ALOCARCANDIDATO-PROFESSOR, ACESSAR PARECER, DEFINIR CANDIDATOS ACEITOS e NO-TIFICAR CANDIDATOS ACEITOS (relacionados ao usuario CPG). A descricao desses casos deuso pode ser encontrada na secao 3.1. Ainda nessa etapa, realizou-se uma nova entrevista com oprofessor Rodolfo Jardim de Azevedo a respeito das interfaces desejaveis para as funcionalidadesdos usuarios CPG e professor. A implementacao foi baseada nas tecnologias PHP, JavaScript, CSS,HTML e o SGBD PostgreSQL, descritas na secao 4.1.

Algumas atividades da primeira e da segunda etapa foram sobrepostas, como o refinamentodo diagrama Entidade-Relacionamento e analise das tecnologias. Assim que a primeira etapa foiconcluıda, a implementacao do banco de dados foi iniciada.

A ultima etapa previa a validacao do sistema, atraves da simulacao de um processo seletivocompleto, passando pela inscricao de candidatos, a emissao de pareceres e chegando a definicaodos candidatos aceitos. Nessa simulacao, criaria-se candidatos fictıcios para o sistema realizando-se inicialmente uma validacao pelos proprios desenvolvedores do projeto. Posteriormente seriarealizada uma validacao pelos dos professores entrevistados na fase de requisitos, que se dispuserama auxiliar a validacao do sistema. Como se tratam de usuarios reais do sistema, espera-se que essavalidacao seja mais conclusiva.

As dificuldades encontradas em relacao as tecnologias utilizadas na implementacao (descritasem 4.1) acarretaram atrasos no cronograma previsto, nao sendo possıvel a finalizacao das etapasde implementacao e validacao. Espera-se que ate a data prevista para a demonstracao, a im-plementacao seja finalizada e seja possıvel fazer alguma validacao. Entretanto, a validacao comusuarios reais, que possibilitara uma validacao mais conclusiva, possivelmente nao sera realizada.A descricao detalhada das atividades realizadas nas etapas de levantamento de requisitos e imple-mentacao encontra-se nas secoes 3 e 4, respectivamente.

2

3 Etapa de Levantamento de Requisitos e Projeto

Essa etapa consistiu no levantamento dos formularios e documentos necessarios para a inscricaode candidatos no processo de selecao da pos-graduacao e em uma analise do funcionamento atualdesse processo. Foram realizadas tres entrevistas com professores envolvidos no processo seletivoda pos-graduacao, Ricardo Torres e Rodolfo Jardim de Azevedo, uma apresentacao do sistemaproposto para a classe de MO410 e varias discussoes entre os envolvidos no projeto.

As entrevistas com professores trouxeram varios esclarecimentos a respeito do funcionamentodo processo de selecao dos candidatos, por exemplo, sobre o conteudo de um parecer, como ele evisualizado dentro do processo e como e construıda a classificacao dos candidatos. Novas funcio-nalidades antes nao previstas para o sistema foram adicionadas na tentativa de melhor refletir anecessidade real do sistema. Uma delas foi possibilitar que os professores do IC possam consultaras fichas de inscricao de candidatos nao selecionados e permitir convida-los para ingressarem comoalunos especiais, possibilitando que futuramente se tornem alunos regulares.

Percebeu-se tambem a necessidade de simplificacao do sistema atraves de um refinamento dasinformacoes realmente relevantes para o sistema. A intencao e diminuir o quanto possıvel o volumede dados digitados, que poderia impossibilitar a adocao do sistema. Os demais alunos da disciplinade MO410 apresentaram sugestoes a respeito da manipulacao dos documentos em papel que foramconsideradas nas decisoes de projeto e incorporadas ao sistema.

Todo esse processo resultou numa serie de decisoes que sao apresentadas a seguir, agrupadas emtres sub-secoes. A sub-secao 3.1 apresenta o diagrama final de casos de uso abrangidos pelo sistema.A sub-secao 3.2 ilustra o diagrama Entidade-relacionamento proposto para a implementacao. Osrequisitos funcionais e outras caracterısticas desejaveis do sistema, que foram levantados na fase derequisitos, estao descritos na sub-secao 3.3.

3.1 Diagrama de Casos de Uso

O levantamento dos casos de uso foi feito com o intuito de identificar as principais funcionali-dades a serem tratadas pelo sistema, de forma a automatizar o sistema atual de gerenciamento doprocesso seletivo. Ao todo, foram identificados 4 atores, que correspondem aos diferentes usuariosdo sistema e 20 casos de uso, realizados por esses atores. Os atores identificados na primeira etapado projeto foram mantidos. Esses atores e suas correspondentes descricoes sao mostrados a seguir.

• CANDIDATO: Usuario do sistema candidato ao processo de pos-graduacao do IC-UNICAMP. Pode ser candidato ao programa de Mestrado em Ciencia da Computacao ouao programa de Doutorado em Ciencia da Computacao. Utilizara o sistema para realizar suainscricao em um processo seletivo.

• CPG: Usuario do sistema integrante da Comissao de Pos-Graduacao do IC-UNICAMP. Podeser um professor ou um funcionario do IC. Utilizara o sistema para realizar todo o gerencia-mento do processo seletivo, desde sua criacao a avaliacao final dos candidatos.

• PROFESSOR: Usuario do sistema professor do IC, que pode eventualmente participar doprocesso de selecao dos candidatos do programa de pos-graduacao. Utilizara o sistema paraemitir parecer(es) a respeito de candidatos de acordo com os criterios estabelecidos pela CPG.

• RECOMENDANTE: Usuario do sistema de alguma instituicao ou empresa. Utilizara osistema a pedido de um candidato para a emissao de carta de recomendacao com informacoessobre o candidato para o processo de selecao.

3

Em reunioes com os professores envolvidos no processo seletivo identificou-se a necessidade deum mesmo usuario assumir varios papeis no sistema, ou seja, ser varios atores (nao necessaria-mente ao mesmo tempo). Isto ocorre, por exemplo, para todos os professores do IC que fazemparte da comissao de pos-graduacao e, portanto, deverao assumir no sistema os papeis de CPGe PROFESSOR. Ocorre tambem para professores do IC indicados por candidatos para emitiremcartas de recomendacao e portanto poderao assumir tanto o papel de PROFESSOR como de RE-COMENDANTE no sistema.

Depois de varias discussoes a respeito de qual era o melhor tratamento para esses casos, decidiu-se por isolar os papeis de cada ator no sistema, com base em permissoes. Dessa forma, um usuariocom multiplos papeis tera de selecionar, assim que entrar no sistema, qual visao deseja ter do sistemabaseado no papel que deseja assumir no momento (qual ator deseja ser). Assim, as funcionalidadesdisponıveis para cada usuario serao agrupadas de acordo com seus papeis.

Com a finalizacao da fase de levantamento de requisitos, alguns casos de uso tiveram suasemantica modificada (ou restringida), outros foram incorporados e um foi removido. O caso deuso removido foi PENDENCIAS DOCUMENTOS RECEBIDOS, que compreendia a atualizacaodo sistema, por parte da CPG, do status dos documentos enviados pelo CANDIDATO em papel.Isto possibilitaria a visualizacao de quais documentos foram efetivamente recebidos e quais estavampendentes.

Baseando-se nos requisitos levantados, decidiu-se que, durante o processo de selecao, os docu-mentos em “papel” deverao ser enviados em versao digital, por meio de um upload no sistema. OHistorico devera ser scaneado e o Curriculum Vitae deve ser enviado em formato pdf ou txt. Todosos documentos necessarios devem constar no sistema para que a inscricao possa ser concluıda e ocandidato passe a fazer parte do processo seletivo, logo nao havera pendencias desses documentos.A apresentacao dos documentos em papel, bem como a autenticacao do Historico sera realizadaapenas para candidatos aprovados, no ato da matrıcula, juntamente com os demais documentosnecessarios.

O caso de uso PREENCHER CADASTRO do usuario PROFESSOR foi removido, ja queos unicos dados de professor, apos a simplificacao do modelo, sao nome e matrıcula. Criou-seum novo caso de uso para o RECOMENDANTE para que ele possa entrar no sistema com seusdados pessoais antes de emitir uma carta de recomendacao. Esse caso de uso foi chamado dePREENCHER CADASTRO.

A Figura 1 ilustra o diagrama construıdo com base nas informacoes obtidas sobre o processo deselecao da pos-graduacao, indicando o relacionamento entre os atores e os casos de uso identificados.

Os casos de uso identificados sao listados a seguir, acompanhados de suas descricoes e dos atoresque podem realiza-los no sistema.

1. ABRIR PROCESSO SELETIVO: Abertura de um processo seletivo no programa depos-graduacao do IC. Inclui a especificacao do tipo de processo, Mestrado ou Doutorado emCiencia da Computacao e do perıodo em que as inscricoes estarao abertas para os candidatos.Ator: CPG;

2. ACESSAR DOCUMENTOS: Acesso aos documentos, enviados pelo candidato, gerenci-ados pelo sistema. Esses documentos incluem a sua ficha de inscricao, o resultado do POS-COMP e os documentos que sao enviados por upload, como Historico e Curriculum Vitae.Atores: CPG, PROFESSOR;

3. ACESSAR PARECER: Acesso ao resultado de um parecer emitido, constando um co-mentario geral a respeito do candidato e o conceito dado por um professor avaliador. Ator:

4

Figura 1: Diagrama de Casos de Uso

CPG;

4. ACOMPANHAR STATUS AVALIACAO: Acompanhamento do status do processoseletivo, cartas de recomendacao ja emitidas e visualizacao do resultado quando ja disponıvel.Possibilita o pedido de uma nova carta de recomendacao a um recomendante em substituicaoa alguma que ainda nao tenha sido enviada. Ator: CANDIDATO;

5. ALOCAR CANDIDATO-PROFESSOR: Alocacao de candidatos aos professores. Essesprofessores serao responsaveis por avaliar os candidatos atraves da emissao de pareceres. Cadacandidato sera alocado para varios professores. Cada professor podera avaliar mais de umcandidato. Essa alocacao pode ou nao possuir criterios pre-definidos, como alocar candidatosde uma mesma instituicao a um mesmo professor avaliador. Ator: CPG;

6. ALTERAR SENHA: Alteracao de senha de acesso ao sistema a partir de uma contade usuario. Todos os usuarios do sistema possuem suas respectivas contas, portanto estecaso de uso abrange todos os atores. Atores: CPG, RECOMENDANTE, PROFESSOR,CANDIDATO;

5

7. CADASTRAR: Criacao de uma conta para acessar o sistema e cadastro dos login e senha.Ator: CANDIDATO;

8. CRIAR CONTA PARA PROFESSOR/CPG: Criacao de uma conta para acessar osistema para os usuarios que sao professores do IC ou usuarios CPG. Este caso de uso temo intuito de limitar quais usuarios terao acesso as funcionalidades relacionadas a selecao decandidatos e gerencia do processo seletivo. Ator: CPG;

9. CADASTRAR CONCEITOS PARECER: Cadastro dos conceitos e respectivos pesosusados na avaliacao dos candidatos do processo seletivo de pos-graduacao em um parecer.Esses conceitos serao utilizados tambem para a avaliacao final do candidato, que definiraquais serao aceitos para ingressar como alunos regulares. Ator: CPG;

10. CONSULTAR ALUNOS NAO APROVADOS: Disponibiliza as fichas dos alunos naoaprovados para ingressar no programa de pos-graduacao, ordenados por seus conceitos finais,para que professores interessados em novos orientados possam analisar seus perfis e convida-los para ingressar como alunos especiais. O intuito e que, posteriormente (possivelmente nosemestre seguinte), esses alunos ingressem como alunos regulares. Ator: PROFESSOR;

11. DEFINIR CANDIDATOS ACEITOS: Definicao de quais candidatos inscritos no pro-grama serao selecionados para ingressar como alunos regulares no IC, de acordo com ospareceres emitidos pelos professores avaliadores e os documentos do candidato. Neste casode uso, sao atribuıdos aos candidatos seus conceitos finais. Ator: CPG;

12. EMITIR CARTA RECOMENDACAO: Emissao de uma carta de recomendacao a res-peito de um candidato do programa de pos-graduacao. Essa emissao apenas e permitidapara recomendantes indicados pelos candidatos. Assim que uma carta for emitida, o sistemadevera apresentar ao candidato o novo status da carta de recomendacao, para que este possaacompanhar as cartas enviadas e tenha tempo habil para solicitar uma outra carta a um novorecomendante antes do prazo final de inscricao. Ator: RECOMENDANTE;

13. EMITIR PARECER: Emissao de um parecer em relacao a um candidato do programa depos-graduacao alocado pelo CPG para avaliacao. Esse parecer devera conter um comentariogeral sobre o candidato, baseado nos dados que se tem no sistema a seu respeito e docu-mentacao enviada e um conceito. No caso de impossibilidade de um professor avaliar oscandidatos para ele alocados, um usuario do tipo CPG podera acessar o sistema e emitir oparecer em seu lugar. Atores: PROFESSOR, CPG;

14. FAZER UPLOAD DE DOCUMENTO: Upload dos documentos necessarios para a ins-cricao do candidato, como Historico, que deve ser scaneado e Curriculum Vitae em formatopdf ou txt. O Curriculum Vitae podera possuir todos os campos que o candidato julgarnecessario. Ator: CANDIDATO;

15. INDICAR RECOMENDANTE: Indicacao de um profissional (de uma instituicaoacademica ou de uma empresa) para emitir uma carta de recomendacao a respeito de umcandidato. A partir dessa indicacao, o sistema devera enviar um e-mail ao endereco forne-cido pelo candidato fornecendo um login e uma senha para o recomendante entrar no site epreencher a carta de recomendacao. Ator: CANDIDATO;

16. INSCREVER: Inscricao dos candidatos no programa de pos-graduacao do IC. Essa ins-cricao consiste no preenchimento de todos os dados que atualmente constam no formulario de

6

inscricao e o envio, via upload, dos demais documentos em formato eletronico. Este caso deuso pode ocorrer incrementalmente, de forma que o candidato pode acessar o sistema variasvezes ate concluir efetivamente sua inscricao. Apenas inscricoes concluıdas serao analisadasno processo seletivo. Ator: CANDIDATO;

17. NOTIFICAR CANDIDATOS ACEITOS: Notificacao, atraves do envio de e-mails, aoscandidatos aceitos para ingressarem no programa de pos-graduacao do IC como alunos regu-lares. Essa notificacao faz-se necessaria dada a necessidade de confirmacao do interesse docandidato a vaga. Por restricoes administrativas, o IC possui um prazo pre-definido (e poucoflexıvel) para apresentar a relacao dos alunos ingressantes na pos-graduacao. Ator: CPG;

18. PREENCHER CADASTRO: Preenchimento dos dados cadastrais de uma conta ja criadaautomaticamente pelo sistema para um recomendante ao ser indicado por um CANDIDATOpara emitir uma carta de recomendacao. Ator: RECOMENDANTE;

19. RECORDAR SENHA: Envio da senha de acesso ao sistema para o endereco de e-maildo usuario cadastrado. Esta funcionalidade sera util para usuarios esporadicos do sistema,que nao o acessam com muita frequencia, mas que em um acesso gostariam de recuperarsuas informacoes cadastradas em momentos anteriores. Atores: RECOMENDANTE, CAN-DIDATO, PROFESSOR, CPG;

20. RECUPERAR POSCOMP: Recuperacao das notas obtidas pelo candidato no POS-COMP para cadastro no sistema. Essas notas sao solicitadas pelo IC diretamente a comissaoorganizadora do POSCOMP. Assim, o IC recebe um arquivo contendo as notas de todos osalunos inscritos no processo de selecao. Esse caso de uso devera cadastrar as notas do POS-COMP dos candidatos a partir das notas fornecidas nesse arquivo. Seria interessante tambempermitir analises estatısticas relacionadas ao desempenho individual de cada candidato, re-cuperando sua colocacao geral dentre os inscritos e dentre os inscritos da mesma instituicaode ensino. Ator: CPG.

3.2 Diagrama Entidade-Relacionamento Proposto

Com a finalizacao da fase de levantamento de requisitos, o diagrama entidade-relacionamentoproposto inicialmente sofreu algumas modificacoes. Em reunioes com os professores envolvidos,identificou-se a necessidade de alteracoes no diagrama para sua melhor adequacao as funcionalidadesdo sistema. Com esse intuito, algumas entidades, atributos e relacionamentos foram incorporadose outros foram removidos.

Inicialmente, buscou-se por atributos superfluos em todo o diagrama. Esses atributos foramremovidos de forma a tornar o diagrama final o mais enxuto possıvel. Alguns exemplos de atribu-tos removidos sao: descricao do orgao financiador, o numero de semestres cursados para formacoesacademicas e o tipo de relacao entre o candidato e o recomendante. Outros atributos eliminadosapareciam principalmente herdados de superclasse e eram dispensaveis para o funcionamento cor-reto do sistema. Por exemplo, a entidade PESSOA foi renomeada para EXTERNOS, pois, poropiniao do professor entrevistado, decidiu-se simplificar ao maximo a entidade PROFESSOR. Den-tre os atributos dispensaveis estavam os relacionados ao endereco, por exemplo, pois se consideraque o endereco dos professores do IC e o seu proprio gabinete na UNICAMP. Esses atributos eramantes herdados de PESSOA e, com essa nova definicao, apenas recomendantes e candidatos os her-dariam. Como ambos sao usuarios externos do sistema, optou-se por essa renomeacao. Entende-se

7

que a semantica da heranca ficaria prejudicada se continuasse existindo uma entidade pessoa nosistema que nao fosse superclasse de professor.

Constatou-se tambem que o conceito de “Ficha” para um candidato era importante para osistema. Dentro de um processo seletivo, ocorre, por muitas vezes, que um candidato e referenci-ado pelo numero de sua ficha. Dessa forma, a entidade anteriormente chamada de PROCESSO-CANDIDATO foi renomeada para FICHA e dentre seus atributos estao o resultado da selecao e anota final atribuıda ao candidato.

Pensou-se, em um primeiro momento, em fornecer os campos do Curriculum Vitae no sistema.Porem, durante a ultima entrevista realizada com o professor Rodolfo Jardim Azevedo, essa decisaofoi modificada. Segundo ele, para a analise de um candidato e necessaria uma separacao de suasinformacoes. As informacoes realmente relevantes sobre o candidato devem constar no formulariode inscricao e informacoes secundarias devem ser apresentadas no Curriculum Vitae. E relevante,por exemplo, informacoes a respeito das bolsas de estudo ja obtidas pelo candidato, como o orgaofinanciador, o nıvel da bolsa e o perıodo de duracao. Porem, o nome e a area do projeto, o nomedo orientador e outros dados nao sao considerados tao importantes.

Essa separacao diminui a quantidade de documentos diretamente acessados por um professoravaliador ao emitir um parecer sem, no entanto, prejudicar o candidato: qualquer informacaoadicional pode ser encontrada no Curriculum. Considerando essa decisao de projeto, as entidadesreferentes ao Curriculum, como publicacoes e idioma, foram removidas do diagrama.

A entidade anteriormente chamada de PERMISSAO foi renomeada para PAPEL, por estarrelacionada aos varios papeis que um usuario pode assumir no sistema (como ja discutido na secao3.1) e a cada papel estao associadas funcionalidades especıficas que devem ser disponibilizadas pelaaplicacao.

Por questoes de flexibilidade em relacao aos dados fornecidos pelo candidato, que podem variarde acordo com o processo seletivo ao qual ele se inscreve, alguns atributos e relacionamentosanteriormente relacionados com a entidade CANDIDATO passaram a pertencer a entidade FICHA.Foi o caso dos atributos numero e ano do POSCOMP, condicoes em relacao a bolsa, plano detrabalho e informacoes adicionais. O mesmo para os relacionamentos com areas de interesse,documentos enviados, inscricoes anteriores e outras instituicoes tentadas.

A versao final do diagrama entidade-relacionamento com essas modificacoes e ilustrado naFigura 3.2, constando as cardinalidades maximas e mınimas de cada relacionamento. Em seguidasao listadas as entidades e os atributos identificados, seguidos de suas descricoes.

• AREA-INTERESSE : Dados relacionados as areas de interesse de pesquisa relacionados aCANDIDATO(s).

– id-area: Chave da relacao AREA-INTERESSE;

– nome: Informacao sobre o nome da AREA-INTERESSE.

• AREA-INTERESSE-FICHA: Relacao entre uma FICHA de inscricao e as AREA-INTERESSE(s) relacionadas.

– id-ficha: Chave da relacao FICHA;

– ordem: Informa a ordem de preferencia da AREA-INTERESSE;

– id-area: Chave da relacao AREA-INTERESSE.

• BOLSA: Informacoes sobre bolsas que os CANDIDATO(s) tiveram durante sua formacaoacademica.

8

USUARIO

CANDIDATO

PROFESSOR RECOMENDANTE

PARECERCARTA_RECOMENDACAO

FORMACAO_ACADEMICA

BOLSA

EXPERIENCIA_PROFISSIONAL

PREMIO

INSCRICAO_ANTERIOR

OUTRAS_INSTITUICOES

DOCUMENTOS_ENVIADOS

EXTERNOCPG

INSTITUICAO

AREA_INTERESSE

ORGAO_FINANCIADOR

PROCESSO_SELETIVOCONCEITOS

FICHA

POSCOMP

n

(0,n)

PAPEL

FUNCIONALIDADE

CANDIDATO-RECOMENDACAO

(1,1)

(0,n)

(2,n)

(1,1)

(1,1)

(1,1)

(0,n)

(3,3)

(0,n)

(1,1)

(0,n)

(1,1)(1,n)

(1,1)

(0,n) (0,n)

(1,1)

(0,n)

(1,1)

(0,n)

(0,1)

(0,n)

(1,1)

(0,n) (1,n)(1,n)

(0,n)

(0,n)

(1,n)

(1,n)

(1,n)

(1,1)

(0,n)

(1,1)

(1,1)

(0,n)

(0,n)

(1,1)

(0,n)

(1,1)

(1,1)

(1,1)

(1,1)

(1,n)(0,n)

(1,1)

(1,1)

(0,n)

Data_pedido

ordem

Data_contato

– id-bolsa: Chave da relacao BOLSA;

– nivel: Nıvel da BOLSA(s) de estudo(s) tida(s), anteriormente, pelo CANDIDATO;

– data-inicio: Data de inıcio da BOLSA(s) de estudo(s) tida(s), anteriormente, pelo CAN-DIDATO;

– data-fim: Data de fim da BOLSA(s) de estudo(s) tida(s), anteriormente, pelo CANDI-DATO;

– titulo-projeto: Tıtulo do projeto relacionado a BOLSA.

• CANDIDATO : Especializacao de EXTERNO. Candidatos no processo de selecao do pro-grama de pos-graduacao do IC.

– id-usuario: Chave da relacao USUARIO;

– rg: RG de USUARIO EXTERNO CANDIDATO;

– data-nascimento: Data de nascimento do CANDIDATO;

– local-nascimento: Local de nascimento do CANDIDATO;

– nacionalidade: Nacionalidade do CANDIDATO;

– telefone: Telefone para contato com o CANDIDATO;

– fax: Fax para contato com o CANDIDATO;

9

• CANDIDATO-RECOMENDACAO : Relacao entre o CANDIDATO e o RECOMENDANTEque emitira a CARTA-RECOMENDACAO para o processo de selecao da pos-graduacao doIC.

– id-candidato-recomendacao: Chave da relacao CANDIDATO-RECOMENDACAO;

– id-usuario-recomendante: Chave da relacao USUARIO RECOMENDANTE;

– id-usuario-candidato: Chave da relacao USUARIO CANDIDATO;

– data-pedido: Data em que o CANDIDATO pediu a CARTA-RECOMENDACAO parao RECOMENDANTE.

• CARTA-RECOMENDACAO : Carta de recomendacao elaborada por um RECOMENDANTEa respeito de um CANDIDATO no processo de selecao da pos-graduacao do IC.

– id-carta: Chave da relacao CARTA-RECOMENDACAO;

– data-envio: Data de envio da carta de recomendacao;

– descricao-conheceu: Resposta do recomendante a pergunta: “Descreva em que condicoesconheceu o candidato (como professor, orientador, chefe, colega) e o perıodo em que istoocorreu.”

– descricao-desempenho: Resposta do recomendante a pergunta: “Como voce avalia odesempenho do candidato nas atividades que acompanhou de perto analisando sua capa-cidade, dedicacao, iniciativa, criatividade e motivacao?”

– descricao-avaliacao: Resposta do recomendante a pergunta: “Como voce avalia a ex-periencia academica em computacao do candidato, ate o momento, em termos de conhe-cimentos teoricos, habilidade de programacao e abrangencia de formacao?”

– descricao-potencial-doutorado: Resposta do recomendante a pergunta: “Caso o candi-dato esteja se inscrevendo ao doutorado, como voce avalia o seu potencial para realizacaode pesquisa original? Por favor, procure fundamentar sua resposta.”

– compara-anos: Resposta do RECOMENDANTE a pergunta: “Comparando com alunosque conheci em ... anos, eu classificaria o candidato da seguinte maneira.”

– aproveitamento-disciplinas: Classificacao do aproveitamento em disciplinas do CANDI-DATO comparando outros alunos que o recomendante conheceu nos ultimos ‘X’ anos;

– perseveranca: Classificacao da perseveranca do CANDIDATO comparando outros alu-nos que o recomendante conheceu nos ultimos ‘X’ anos;

– conhecimento-cientifico: Classificacao do conhecimento cientıfico do CANDIDATO com-parando outros alunos que o recomendante conheceu nos ultimos ‘X’ anos;

– iniciativa-criatividade: Classificacao da iniciativa e criatividade do CANDIDATO com-parando outros alunos que o recomendante conheceu nos ultimos ‘X’ anos;

– capacidade-expressao-oral: Classificacao da capacidade de expressao oral do CANDI-DATO comparando outros alunos que o recomendante conheceu nos ultimos ‘X’ anos;

– capacidade-expressao-escrita: Classificacao da capacidade de expressao escrita do CAN-DIDATO comparando outros alunos que o recomendante conheceu nos ultimos ‘X’ anos;

• CONCEITOS : Especificacao das faixas de conceitos que serao usadas para que o PROFES-SOR avaliador responda o PARECER associado ao PROCESSO-SELETIVO.

10

– id-conceito: Chave da entidade CONCEITO;

– peso: Peso a ser considerado para a questao a ser respondida pelo PROFESSOR avali-ador no PARECER associado ao PROCESSO-SELETIVO. Valores validos: A+, A, A-,dentre outros;

– nota: Valor numerico associado ao peso no CONCEITO que sera usado para realizaroperacoes de media no PARECER associado ao PROCESSO-SELETIVO;

• CPG : Especializacao de USUARIO. Usuarios que terao acesso a funcoes de gerenciamentodo sistema.

– id-usuario: Chave da relacao USUARIO CPG.

• DOCUMENTOS-ENVIADOS : Documentos necessarios no processo de selecao que foramenviados pelos CANDIDATO(s).

– id-documento: Chave da relacao DOCUMENTOS-ENVIADOS;

– nome-arquivo: Nome dado pelo sistema ao arquivo enviado;

– documento: Documento enviado por upload no sistema. Tipos possıveis: .pdf e .txt;

– extensao: Identificacao do tipo do arquivo para o browser. Tipos possıveis: applica-tion/pdf e text/plain.

• EXPERIENCIA-PROFISSIONAL: Informacoes sobre experiencias profissionais dos CANDI-DATO(s).

– id-experiencia-profissional: Chave da relacao EXPERIENCIA-PROFISSIONAL;

– instituicao-empresa: Indicacao da instituicao ou empresa na qual o CANDIDATO teveEXPERIENCIA-PROFISSIONAL;

– tipo-trabalho: Indicacao do tipo de trabalho prestado pelo CANDIDATO na empresaem que teve EXPERIENCIA-PROFISSIONAL;

– data-inicio: Data de inıcio da EXPERIENCIA-PROFISSIONAL do CANDIDATO;

– data-fim: Data de fim da EXPERIENCIA-PROFISSIONAL do CANDIDATO.

• EXTERNO : Especializacao de USUARIO. Pessoas externas que terao acesso a funcionalida-des de usuarios finais no sistema.

– id-usuario: Chave da relacao USUARIO EXTERNO;

– nome: Nome completo de EXTERNO;

– logradouro-end: Campo logradouro no endereco de EXTERNO;

– numero-end: Campo numero no endereco de EXTERNO;

– complemento-end: Campo complemento no endereco de EXTERNO;

– cep-end: Campo CEP no endereco de EXTERNO;

– cidade-end: Campo cidade no endereco de EXTERNO;

– estado-end: Campo estado no endereco de EXTERNO.

• FICHA: Ficha de inscricao que simula a relacao entre um CANDIDATO e um PROCESSO-SELETIVO.

11

– id-ficha: Chave de FICHA;

– num-poscomp: Numero de inscricao do POSCOMP;

– ano-poscomp: Ano de inscricao do POSCOMP;

– solicita-bolsa: resposta a pergunta O CANDIDATO solicita bolsa? Valores validos:Sim, Nao;

– condicoes-bolsa: resposta a pergunta Caso esteja pleiteando bolsa e nao possa ser aten-dido, o CANDIDATO tem condicoes de cursar o Programa? Valores validos: Sim, Nao;

– programa-agencia: resposta a pergunta Caso o CANDIDATO tenha se candidatado aoPICDT, ou a outro programa/agencia, indicar.

– situacao-programa-agencia: resposta a pergunta Caso o CANDIDATO tenha se can-didatado ao PICDT, ou a outro programa/agencia, indicar a situacao atual. Valoresvalidos: Aprovado, Reprovado, Em julgamento;

– plano-trabalho: resposta a pergunta Sugestao sucinta de um possıvel plano de trabalhoproposto pelo CANDIDATO dentro de uma das areas de interesse citadas anteriormente;

– informacoes-adicionais: Espaco utilizado pelo CANDIDATO para listar outras in-formacoes nao constantes nos campos anteriores consideradas relevantes;

– id-possivel-orientacao: Chave de POSSIVEL-ORIENTACAO;

– data-inscricao: Data em que o formulario de inscricao completo e devidamente preen-chido foi submetido no sistema.

– resultado: Resultado da avaliacao do CANDIDATO ao programa de pos-graduacao.

– nota: Nota final atribuıda a um CANDIDATO.

• FORMACAO-ACADEMICA: Informacoes a respeito da formacao academica dos CANDI-DATO(s) no processo de selecao do IC.

– id-formacao: Chave da relacao FORMACAO-ACADEMICA;

– nome-curso: Nome do curso realizado na instituicao relacionada a FORMACAO-ACADEMICA;

– titulacao: Especifica qual o tipo de titulacao vinculado a FORMACAO-ACADEMICA.Valores validos: Graduacao, Especializacao, Mestrado, Doutorado;

– completo: A realizacao do curso relacionada a FORMACAO-ACADEMICA foi com-pleta? Valores validos: Sim, Nao;

– data-inicio: Data de inıcio da realizacao do curso relacionado a FORMACAO-ACADEMICA;

– data-fim: Data de finalizacao da realizacao do curso relacionado a FORMACAO-ACADEMICA.

• FUNCIONALIDADE : Funcionalidades disponıveis no sistema.

– id-funcionalidade: Chave de FUNCIONALIDADE;

– nome: Nome da FUNCIONALIDADE;

– descricao: Descricao da FUNCIONALIDADE;

– link: Link da funcionalidade.

12

• INSCRICAO-ANTERIOR: Informacoes a respeito de candidaturas anteriores do CANDI-DATO a algum outro programa de pos-graduacao na Unicamp.

– id-inscricao-anterior: Chave da relacao INSCRICAO-ANTERIOR;

– nome-programa: Informa o nome do programa de pos-graduacao da UNICAMP em queo CANDIDATO se candidatou anteriormente;

– data-inscricao: Informa a data de inscricao do programa de pos-graduacao da UNICAMPem que o CANDIDATO se candidatou anteriormente;

– resultado: Informa o resultado do programa de pos-graduacao da UNICAMP em que oCANDIDATO se candidatou anteriormente.

• INSTITUICAO : Informacoes a respeito das Instituicoes Academicas.

– id-instituicao: Chave da relacao INSTITUICAO;

– nome: Nome da INSITUICAO, sem abreviacoes;

– sigla: Sigla para o nome da INSTITUICAO;

– cidade: Cidade em que se situa a INSTITUICAO.

– estado: Estado em que se situa a INSTITUICAO.

• ORGAO-FINANCIADOR: Agencia de fomentos que fornece subsıdios financeiros a umaBOLSA.

– id-orgao: Chave primaria de ORGAO-FINANCIADOR;

– nome: Nome da instituicao financiadora de BOLSA;

– sigla: Sigla da instituicao financiadora de BOLSA;

• OUTRAS-INSTITUICOES : Outras instituicoes em que o CANDIDATO esta se candida-tando, constando a ordem de sua preferencia.

– id-outras-instituicoes: Chave da relacao OUTRAS-INSTITUICOES;

– ordem-preferencia: Informa a ordem de sua preferencia relacionada as outras instituicoespara as quais o CANDIDATO esta se candidatando.

• PAPEL: Papeis possıveis de acesso ao sistema.

– id-papel: Chave de PAPEL;

– tipo: Tipo da papel de acesso ao sistema. Valores validos: CPG, Professor, Recomen-dante e Candidato.

• PARECER: Parecer emitido por um PROFESSOR avaliador a respeito de um CANDIDATOno processo de selecao da pos-graduacao do IC.

– id-parecer: Chave da relacao PARECER;

– comentario: Comentarios sobre o parecer do PROFESSOR avaliador no PARECERassociado ao PROCESSO-SELETIVO;

– id-conceito: Chave da entidade CONCEITO. Conceito dado pelo PROFESSOR avalia-dor no PARECER associado ao PROCESSO-SELETIVO;

13

• POSCOMP : Reflete o resultado do POSCOMP associado ao CANDIDATO.

– num-inscricao: Numero de inscricao do POSCOMP;

– ano: Ano em que o POSCOMP foi realizado;

– id-usuario: Chave da relacao USUARIO;

– num-acertos-matematica: Numero de acertos nas questoes de matematica do POS-COMP;

– num-acertos-fundamentos: Numero de acertos nas questoes de fundamentos do POS-COMP;

– num-acertos-tecnologica: Numero de acertos nas questoes de tecnologia do POSCOMP.

• POSSIVEL-ORIENTACAO : Possıvel contato entre um CANDIDATO ao programa de pos-graduacao e um PROFESSOR do IC sobre uma possıvel orientacao.

– id-possivel-orientacao: Chave de POSSIVEL-ORIENTACAO;

– data-contato: Data em que o CANDIDATO entrou em contato com o PROFESSOR doIC a respeito da orientacao.

– id-usuario: Chave da relacao USUARIO.

• PREMIO : Informacoes sobre premios que os CANDIDATO(s) tiveram durante sua formacaoacademica.

– id-premio: Chave da relacao PREMIO;

– descricao: Informacoes a respeito de premios e distincoes academicas do CANDIDATO.

• PROCESSO-SELETIVO : Informacoes a respeito do processo seletivo aberto pela CPG parao ingresso de alunos de mestrado e doutorado para o programa de pos-graduacao do IC.

– id-selecao: Chave primaria de PROCESSO-SELETIVO;

– ano: Ano em que os aprovados no PROCESSO-SELETIVO ingressarao no IC;

– semestre: Semestre em que os aprovados no PROCESSO-SELETIVO ingressarao no IC.Valores validos: primeiro, segundo;

– tipo: Tipo de processo seletivo. Valores validos: mestrado, doutorado;

– data-abertura: Data de abertura do PROCESSO-SELETIVO, quando se inicia o cadas-tro de CANDIDATOS;

– data-limite: Data de encerramento do PROCESSO-SELETIVO.

• PROFESSOR: Especializacao de USUARIO. Professores do IC que participarao do processode avaliacao dos candidatos ao programa de pos-graduacao e demais professores.

– id-usuario: Chave da relacao USUARIO;

– matricula: Matrıcula do PROFESSOR no IC;

– nome: Nome completo do PROFESSOR.

• RECOMENDANTE : Especializacao de EXTERNO. Profissionais que escrevem cartas derecomendacao para um CANDIDATO no processo de selecao da pos-graduacao do IC.

14

– id-usuario: Chave da relacao USUARIO;

– instituicao-empresa: Instituicao ou Empresa do RECOMENDANTE;

– grau-academico: Grau academico mais alto do RECOMENDANTE;

– cargo: Cargo do RECOMENDANTE na instituicao-empresa;

– instituicao-grau: Instituicao em que o RECOMENDANTE obteve o maior grauacademico;

– ano-grau: Ano em que o RECOMENDANTE obteve o maior grau academico;

– area-especialidade: Area de especialidade do RECOMENDANTE;

• USUARIO : Usuarios que irao acessar o sistema.

– id-usuario: Chave da relacao USUARIO;

– login: Login do USUARIO que permite o acesso ao sistema;

– senha: Senha do USUARIO que permite o acesso ao sistema;

– e-mail: Endereco de e-mail usado para contato com USUARIO - sempre que possıvel, oinstitucional.

3.3 Funcionalidades Desejaveis do Sistema

Com a finalizacao do levantamento e especificacao dos requisitos, verificou-se a existencia devarias caracterısticas e funcionalidades desejaveis para a aplicacao. Essas caracterısticas influ-enciam substancialmente as decisoes descritas anteriormente, porem nao podem ser totalmentecontempladas apenas pelos diagramas de casos de uso e o modelo entidade-relacionamento.

Primeiramente, espera-se que com a adocao do sistema proposto a inscricao de candidatos aoprograma possa ser feita totalmente “on-line”. Com isso, dispensa-se o envio de documentos empapel e assinaturas, inclusive para as cartas de recomendacao. As cartas de recomendacao possuemum peso consideravel na avaliacao do candidato e portanto, uma preocupacao pertinente ao sistemae evitar fraudes, embora essa questao nao seja um dos objetivos desse trabalho.

Uma funcionalidade desejavel do sistema nesse sentido e instruir o usuario RECOMENDANTEa cadastrar seu e-mail institucional, da universidade ou da empresa a qual esta vinculado. As contasde recomendantes, como usuarios externos, podem ser criadas para qualquer e-mail indicado porum candidato durante sua inscricao. Isto pode permitir que pessoas nao devidamente autorizadasexecutem tal papel no sistema. Os e-mails institucionais serao uma forma indireta de validacao:atraves dele sera estabelecido o contato com o recomendante para o envio de sua conta no sistema.Caso o e-mail indicado nao seja o institucional, constara no contato inicial com o recomendanteuma notificacao. Havera tambem uma verificacao, por parte da CPG, para validacao das cartas derecomendacao emitidas por esses recomendantes. Os enderecos de e-mail tambem serao utilizadospara a busca por usuarios ja cadastrados no sistema antes da criacao de uma nova conta.

Ja a validacao dos documentos enviados via upload, como o Historico, nao sera realizada para ainscricao do candidato. O original deste documento devera ser apresentado apenas pelos candidatosaprovados, no momento de realizacao da matrıcula, quando entao ocorrera a conferencia. Caso sejaconstatada a fraude, o candidato tera que prestar esclarecimentos, podendo ser ate desclassificado.

Deseja-se tambem que o candidato possa acompanhar o andamento do processo seletivo atravesdo sistema. Este acompanhamento sera importante para casos em que, por exemplo, ocorramproblemas com as cartas de recomendacao. O candidato podera acompanhar pelo sistema quaiscartas ja foram emitidas e quais continuam pendentes. Caso as pendencias se estendam (algum

15

recomendante nao possa emitir a carta de recomendacao dentro do prazo), o candidato poderasolicitar um outro recomendante, em substituicao a uma carta nao emitida. Alem disso, o candidatopodera ser notificado caso haja problemas com os arquivos enviados por ele pelo sistema via upload.Podera tambem ser informado do resultado do processo seletivo e manifestar seu interesse pela vagade aluno regular ou abrir mao dela.

Uma outra funcionalidade importante e possibilitar que o usuario CPG, na abertura de umnovo processo seletivo, possa manter os mesmos conceitos de avaliacao definidos em um processoseletivo anterior. Deve permitir tambem a realizacao de “rodadas” de avaliacao pelos professoresna emissao de pareceres. Ocorre que nem sempre uma unica rodada e conclusiva o suficiente arespeito da nota final que deve ser associada a um candidato. Quando os pareceres emitidos porprofessores sobre um mesmo candidato sao muito discrepantes, a nota atribuıda ao candidato nao euma media dos conceitos desses pareceres. E necessaria uma re-avaliacao do candidato, por outrosprofessores, na tentativa de entrar em um consenso a respeito de qual e a real nota do candidato. Osistema devera ainda apresentar uma listagem de todos os pareceres emitidos para um candidato,incluindo seus respectivos avaliadores, de forma a facilitar a identificacao de casos desse tipo etambem a atribuicao da nota final do candidato.

Um outro ponto importante e a alimentacao automatica do sistema com os dados do poscompdos candidatos e manipulacoes sobre esses dados. Atualmente, o CPG solicita diretamente paraa comissao organizadora do POSCOMP os resultados de seus candidatos. Essa informacao edevolvida em um arquivo que armazena todas as notas pedidas. Seria interessante que o sistemapudesse extrair, a partir desse arquivo, as notas de cada candidato para apresenta-las durante suaavaliacao. E desejavel tambem a realizacao de consultas no sistema do tipo: “Qual a colocacao noPOSCOMP do candidato X em relacao a todos os candidatos que fizeram o mesmo POSCOMP queele?”, ou “qual a colocacao no POSCOMP do candidato X em relacao aos candidatos que fizeramo mesmo POSCOMP que ele e estudaram na mesma instituicao de ensino?”. Estas informacoesapresentariam, de certa forma, um melhor perfil do candidato em relacao aos demais.

Um fato recorrente e que professores do IC convidam alunos nao aprovados no processo paraingressarem como alunos especiais, com expectativa de posteriormente ingressarem como regulares.Uma outra funcionalidade do sistema e prover meios para que os professores interessados em novosorientados possam analisar alunos nao aprovados apos o termino do processo de selecao. Essaanalise podera ser realizada considerando-se notas finais proximas ao ponto de corte (estabelecidodurante o processo seletivo) ou por areas de interesse, por exemplo. Deseja-se que o sistema possaauxiliar esse tipo de consulta aos dados dos candidatos e dessa forma facilitar a busca dos professorespor novos alunos.

4 Etapa de Implementacao

Essa etapa consiste na implementacao do sistema de gerenciamento prosposto para o programade pos-graduacao do IC/UNICAMP. Foram realizadas analises a respeito das tecnologias disponıveispara a escolha de qual melhor se adequava ao projeto. Realizou-se tambem uma nova entrevistacom o professor Rodolfo Jardim Azevedo a respeito de algumas interfaces das funcionalidades degerenciamento do CPG e da emissao de parecer. As sugestoes feitas pelo professor nessa entrevistaforam fundamentais na implementacao desses casos de uso.

A implementacao realizada e apresentada a seguir, agrupadas em cinco sub-secoes. A sub-secao4.1 descreve as tecnologias utilizadas em toda a etapa de implementacao. A sub-secao 4.2 apresentaa implementacao realizada para o Banco de Dados proposto, no modelo relacional. A sub-secao 4.3apresenta os casos de uso implementados. A sub-secao 4.4 descreve alguns requisitos funcionais e

16

caracterısticas desejaveis do sistema abrangidos na implementacao e, finalmente, algumas consultasdisponıveis no sistema estao descritas na sub-secao 4.5.

4.1 Tecnologias Utilizadas

Este projeto esta sendo desenvolvido utilizando o servidor web Apache [13], a linguagem deprogramacao PHP [6], a linguagem de programacao JavaScript [11], a scripts HTML [9] e CSS [10]para visualizacao e o sistema gerenciador de banco de dados PostgreSQL [7]. A seguir, sera apre-sentada uma breve descricao dessas tecnologias.

O Apache e um servidor web do codigo aberto, extremamente configuravel, robusto e de altaperformance desenvolvido por uma equipe de voluntarios, o Apache Group [4], buscando criar umservidor web com muitas caracterısticas e com codigo fonte disponıvel gratuitamente via Inter-net. Segundo [1], o Apache e mais usado que todos os outros servidores web do mundo juntos.Esse servidor possui suporte a scripts cgi usando linguagens como Perl, PHP, Shell Script, ASP,dentre outras. Alem disso, possui suporte a tipos mime, personalizacao de logs e varias outrascaracterısticas.

O PHP e uma linguagem de programacao de alto nıvel, normalmente utilizada para desenvolvi-mento de conteudos web dinamicos. E uma linguagem interpretada, fracamente tipada que executano lado do servidor das aplicacoes.

O JavaScript e uma linguagem de script, interpretada, que permite adicionar caracterısticasativas ao codigo HTML em que esta inserida. E executada no lado cliente das aplicacoes e possuimecanismos que permitem o tratamento de eventos oriundos da navegacao de uma pagina pelousuario, possibilitando assim interatividade em codigos HTML.

O HTML e uma linguagem de marcacao amplamente conhecida e utilizada para apresentacaode interfaces web. CSS e utilizado para definir o estilo em uma interface web de modo a separaresse estilo do codigo HTML.

O PostgreSQL e um sistema gerenciador de banco de dados (SGBD) objeto-relacional, de codigoaberto, que implementa a linguagem SQL de acordo com os padroes ANSI-SQL 92/99. Implementatambem mecanismos para a garantia da integridade referencial, como atualizacoes e remocoes emcascata. Esse SGBD permite ainda a utilizacao de tabelas aninhadas, heranca de tabelas, controlemulti-versao de concorrencia, dentre outras funcionalidades. O pgAdminIII [5] e uma ferramentagrafica utilizada para auxiliar no gerenciamento desse SGBD.

Desde a entrega do ultimo relatorio, houve uma mudanca brusca a respeito das tecnologiasempregadas no desenvolvimento deste projeto. Inicialmente, a implementacao do sistema seriarealizada utilizando-se as tecnologias Python [8], Zope [12, 14] e Plone [2, 15]. Os desenvolvedoresdo sistema nao tinham conhecimento a respeito dessas tecnologias e essa escolha foi motivada pelapossibilidade de se adquirir conhecimento nessas ferramentas. A primeira vista, acreditou-se quea utilizacao dessas tecnologias nao trariam grandes dificuldades e agilizariam o processo de desen-volvimento. Por isso, foi investido aproximadamente um mes para investigacao dessas ferramentas.Porem, elas se mostraram demasiadamente complexas, dado o curto tempo disponıvel para apren-dizado e desenvolvimento do sistema. Esse foi o principal fator de atraso na implementacao doprojeto. Assim, optou-se pela utilizacao de outras tecnologias, com as quais os desenvolvedores jaestao mais familiarizados.

A Figura 2 mostra a arquitetura adotada no sistema alvo deste projeto. Essa figura ilustratambem as tecnologias utilizadas em cada elemento dessa arquitetura. Nessa figura, pode ser ob-servado que o JavaScript, HTML e CSS sao utilizados no lado do cliente. Os codigos em JavaScriptsao utilizados basicamente para validacao de formularios e para implementar algumas funcionali-

17

dades, por exemplo possibilitar que o usuario inclua mais de uma formacao academica, conformemostrado na secao 4.3.2. O servidor Apache gerencia as requisicoes HTTP e delega a execucaode codigo PHP para o modulo de PHP. O PHP e utilizado para implementar todas as regras denegocio envolvidas no sistema e tambem para realizar os acessos ao banco de dados PostgreSQL.Por fim, o gerenciamento do SGBD sera realizado utilizando-se a ferramenta pgAdminIII.

Web Browser

HTMLCSSJavaScript

Servidor Web

Apache

Módulo PHP

Postgresql

pgAdminIII Banco de

Dados

PHP

Cliente Servidor

Figura 2: Arquitetura adotada e tecnologias utilizadas.

4.2 Implementacao do Banco de Dados

Essa tarefa abrange a implementacao do banco de dados utilizando-se o SGBD PostgreSQL.Realizou-se um mapeamento do diagrama Entidade-Relacionamento proposto na etapa de requi-sitos para o modelo relacional. A Figura 3, gerada no software ERWin [3], ilustra o diagramarelacional implementado, constando as relacoes criadas, a identificacao das chaves primarias e es-trangeiras(FK), seus atributos e tipos correspondentes. Alem disso, as integridades referenciaisentre as relacoes sao representadas atraves de linhas conectoras entre as relacoes, sendo que osterminadores preenchidos representam cardinalidade maxima ‘n’ enquanto os nao preenchidos re-presentam cardinalidade maxima ‘1’.

Alguns tipos de atributos foram ajustados na geracao do banco de dados no PostgreSQL. Osatributos chave usados apenas com o intuito de identificacao (como id-usuario, id-ficha, id-carta,dentre outros) foram implementados como auto-incrementaveis, atraves do tipo “serial” suportadopelo PostgreSQL. Para o armazenamento dos arquivos fornecidos pelo candidato durante a inscricaono processo de selecao optou-se pelo tipo OID. O Apendice A descreve-se os scripts em SQLutilizados para a criacao do banco de dados.

Para povoar algumas das tabelas criadas que serao “bases” de outras referencias, como astabelas INSTITUICAO e ORGAO-FINANCIADOR, tambem foram construıdos scripts em SQL.Outras tabelas, cujos preenchimentos nao serao contemplados pelos casos de uso implementados,serao povoadas manualmente para possibilitar testes. As demais, serao povoadas diretamente pelosistema web implementado.

18

USUARIO

id_usuario: int

login: varchar(20)senha: varchar(20)e_mail: varchar(30)

CANDIDATO

id_usuario: int

rg: varchar(20)data_nascimento: datelocal_nascimento: varchar(30)nacionalidade: varchar(30)telefone: varchar(20)fax: varchar(20)

PROFESSOR

id_usuario: int

matricula: intnome: varchar(50) RECOMENDANTE

id_usuario: int

instituicao_empresa: varchar(30)grau_academico: varchar(30)cargo: varchar(50)instituicao_grau: varchar(30)ano_grau: intarea_especialidade: varchar(50)

PARECER

id_parecer: int

id_usuario: intid_ficha: intid_conceito: intcomentario: varchar(1000)

CANDIDATO_RECOMENDACAO

id_candidato_recomendacao: int

id_usuario_recomendante: intid_usuario_candidato: intdata_pedido: date

CARTA_RECOMENDACAO

id_carta: int

data_envio: datedescricao_conheceu: varchar(1000)descricao_desempenho: varchar(1000)descricao_avaliacao: varchar(1000)descricao_potencial_doutorado: varchar(1000)compara_anos: intaproveitamento_disciplinas: varchar(20)perseveranca: varchar(20)conhecimento_cientifico: varchar(20)iniciativa_criatividade: varchar(20)capacidade_expressao_oral: varchar(20)capacidade_expressao_escrita: varchar(20)id_candidato_recomendacao: int

FORMACAO_ACADEMICA

id_formacao: int

id_usuario: intid_instituicao: intnome_curso: varchar(50)titulacao: varchar(30)completo: varchar(4)data_inicio: datedata_fim: date

BOLSA

id_bolsa: int

id_usuario: intid_orgao: intnivel: varchar(30)titulo_projeto: varchar(500)data_inicio: datedata_fim: date

EXPERIENCIA_PROFISSIONAL

id_experiencia_profissional: int

id_usuario: intinstituicao_empresa: varchar(50)tipo_trabalho: varchar(50)data_inicio: datedata_fim: date

PREMIO

id_premio: int

descricao: varchar(1000)id_usuario: int

INSCRICAO_ANTERIOR

id_inscricao_anterior: int

nome_programa: varchar(50)data_inscricao: dateresultado: varchar(30)id_ficha: int

OUTRAS_INSTITUICOES

id_outras_instituicoes: int

ordem_preferencia: intid_ficha: intid_instituicao: int

DOCUMENTOS_ENVIADOS

id_documento: int

nome_arquivo: varchar(100)documento: OIDextensao: varchar(50)id_ficha: int

EXTERNO

id_usuario: int

nome: varchar(50)logradouro_end: varchar(100)numero_end: intcomplemento_end: varchar(20)cep_end: varchar(10)cidade_end: varchar(30)estado_end: varchar(30)

CPG

id_usuario: int

INSTITUICAO

id_instituicao: int

nome: varchar(50)sigla: varchar(10)cidade: varchar(30)estado: varchar(30)

AREA_INTERESSE

id_area: int

nome: varchar(50)

ORGAO_FINANCIADOR

id_orgao: int

nome: varchar(50)sigla: varchar(20)

PROCESSO_SELETIVO

id_selecao: int

ano: intsemestre: varchar(20)tipo: varchar(20)data_abertura: datedata_limite: dateid_usuario: int

CONCEITOS

id_conceito: int

peso: varchar(10)nota: floatid_selecao: int

FICHA

id_ficha: int

num_poscomp: varchar(20)ano_poscomp: intsolicita_bolsa: varchar(4)condicoes_bolsa: varchar(4)programa_agencia: varchar(30)situacao_programa_agencia: varchar(30)plano_trabalho: varchar(5000)informacoes_adicionais: varchar(1000)data_inscricao: dateid_possivel_orientacao: intid_usuario: intid_selecao: intresultado: varchar(30)nota: float POSCOMP

num_inscricao: int

ano: intnum_acertos_matematica: intnum_acertos_fundamentos: intnum_acertos_tecnologica: intclassificacao_nacional: intid_usuario: int

POSSIVEL_ORIENTACAO

id_possivel_orientacao: int

data_contato: dateid_usuario: int

AREA_INTERESSE_CANDIDATO

id_area: intid_ficha: int

ordem: int

PAPEL

id_papel: int

tipo: varchar(20)

USUARIO_PAPEL

id_usuario: intid_papel: int

FUNCIONALIDADE

id_funcionalidade: int

nome: varchar(50)descricao: varchar(50)link: varchar(100)

PAPEL_FUNCIONALIDADE

id_papel: intid_funcionalidade: int

Figura 3: Modelo Relacional Implementado, gerado pelo software ERWin [3]

4.3 Casos de uso implementados

A Figura 4 ilustra o diagrama de casos de uso construıdo na etapa de requisitos, indicando osatores e as acoes identificadas. Os casos de uso destacados em cinza foram os escolhidos para aimplementacao e sao descritos nas proximas subsecoes. As ilustracoes das interfaces implementadaspara os caso de uso descritos encontram-se no Apendice C.

4.3.1 Caso de uso: Cadastrar

Este caso de uso corresponde a criacao de uma conta para um usuario CANDIDATO acessaro sitema. Inclui a especificacao de um login e de uma senha. Esses dados sao inseridos na relacao“usuario” e e criado um identificador unico para esse candidato no sistema. A tela correspondente ainterface desse caso de uso e ilustrada na Figura 6. A interface possui um campo para a confirmacaoda senha e faz a validacao entre esse campo e a senha digitada, tambem ilustrada na figura. Eimportante ressaltar que apenas o cadastro de candidatos podera ser realizada externamente pelosistema, atraves dessa funcionalidade. O cadastro de usuarios CPG e professores deve ser realizadopor algum usuario do CPG ja autenticado no sistema. A criacao de cadastros de recomendantessera feita atraves da indicacao para uma recomendacao, sendo que nessa situacao o recomendanterecebera, automaticamente via e-mail (indicado pelo candidato no momento de sua inscricao), umlogin e uma senha (gerada aleatoriamente) para acessar o sistema.

19

Figura 4: Casos de Uso Implementados

4.3.2 Caso de uso: Inscrever

Este caso de uso e responsavel por realizar a inscricao de candidatos em um programa de pos-graduacao do IC, de mestrado ou de doutorado. A inscricao consiste na selecao de um processoseletivo aberto e no preenchimento de todos os dados que atualmente constam no formulario deinscricao. Parte dessas informacoes fornecidas sao armazenadas na relacao “candidato”, partena relacao “ficha”, e outras informacoes em relacoes auxiliares. Esse caso de uso pode ocorrerincrementalmente, de forma que o candidato pode acessar o sistema varias vezes ate concluirefetivamente sua inscricao. Apenas inscricoes concluıdas serao analisadas no processo seletivo.

A interface desse caso de uso foi fragmentada em varias etapas, sendo fortemente baseada noformulario de inscricao utilizado atualmente. As Figuras 9, 10, 14 e 16 ilustram algumas das inter-faces implementadas no sistema para esse caso de uso. Alguns dados fornecidos no formulario deinscricao original possibilitavam a insercao de varias instancias em uma mesma categoria, como ocaso de “Formacao Academica”, “Bolsas de Estudo”,“Experiencia Profissional”e “Premios e Dis-tincoes Academicas”. Para manipular essas categorias de forma flexıvel, sem poluir a interface,optou-se por disponibilzar apenas uma instancia da categoria para preenchimento na tela principal

20

e, ao se desejar inserir uma nova instancia, a instancia anterior e apresentada no canto superiorda tela de forma resumida, acompanhada de uma opcao de modificacao. A operacao de modi-ficacao abre uma nova janela apresentando os dados ja inseridos, para atualizacao. Apos todas asinsercoes desejaveis, se prossegue com a inscricao. Essa funcionalidade e ilustrada para a FormacaoAcademica nas Figuras 11, 12, para as Bolsas de Estudo na Figura 13 e Experiencia Profissionalna Figura 14.

Alguns campos dos formularios de interface possuem validacoes, como verificacoes de camposde preenchimento obrigatorio nao serem nulos, campos numericos nao possuırem caracteres, cam-pos que representam datas possuirem datas validas e anteriores a data corrente e campos e-mailpossuırem enderecos de e-mail validos. Os casos de uso “Fazer Upload de Documentos” e “Indi-car Recomendante” tratam eventos que ocorrem durante o caso de uso “Inscrever”, mas possuemalgumas caracterısticas particulares e por isso sao descritos separadamente nas duas proximas sub-secoes.

4.3.3 Caso de uso: Fazer Upload de Documentos

Este caso de uso foi proposto com o intuito de tornar o processo de inscricao de candidatostotalmente via sistema web, sem o envio de documentos em papel para analise no processo seletivo.Como discutido na secao 3.3, a validacao pelo documento original, em papel, sera realizada apenasno ato na matrıcula, para os candidatos aceitos no programa, e caso seja caracterizada fraude ocandidato podera ser desclassificado.

A funcionalidade desse caso de uso no processo de inscricao e permitir que o candidato envie oCurriculum Vitae e os Historicos Escolares em formato eletronico pelo sistema juntamente com seusdados de inscricao. Apos a analise de algumas alternativas, optou-se por armazenar esses arquivosno proprio banco de dados, associando-os com a ficha do candidato. Armazena-se tambem aextensao de cada arquivo enviado, para facilitar a exibicao pelo browser. As extensoes permitidaspelo sistema, por sugestao do professor Rodolfo Jardim Azevedo sao txt e pdf. A Figura 15 ilustraa interface que permite o envio de arquivos durante o processo de inscricao.

4.3.4 Caso de uso: Indicar Recomendante

Este caso de uso esta vinculado a duas operacoes: a criacao de contas no sistema para usuariosrecomendantes e o registro na inscricao do candidato das informacoes a respeito de suas cartas derecomendacao. Um dos dados preenchidos pelo candidato ao fazer a indicacao de um recomendantee o endereco de e-mail do recomendante. A interface do sistema para esse caso de uso e ilustrada naFigura 17. Atraves desse e-mail, busca-se pelo recomendante no sistema e caso ele ja seja registrado,lhe e enviada uma notificacao automatica, via e-mail, de que possui uma carta de recomendacaopendente a ser emitida pelo sistema para o candidato em questao.

Caso o recomendante nao possua cadastro no sistema, cria-se automaticamente uma conta paraele, usando-se como login o proprio e-mail e gera-se uma senha aleatoria. Esses dados, que permitemo acesso ao sistema para a emissao da carta de recomendacao, sao enviados para o recomendanteautomaticamente, via e-mail, com uma notificacao sobre a carta de recomendacao pendente a seremitida para o candidato em questao. Essas operacoes sao realizadas internamente pelo sistema,nao possuindo interfaces ilustrativas.

21

4.3.5 Caso de uso: Acessar Documentos

Este caso de uso corresponde ao acesso de documentos relacionados a um candidato tanto aousuario CPG como ao usuario professor. Consiste basicamente em acessar todas as informacoesexistentes no sistema sobre um candidato. Isto inclui o formulario de inscricao completo, os arquivosenviados pelo sistema durante sua inscricao (Curriculum Vitae e Historicos Escolares), suas cartasde recomendacao e seu resultado do POSCOMP.

Esse caso de uso nao possui, entretanto, uma interface especıfica no sistema. O acesso aosdocumentos do candidato ocorre em dois momentos: quando um professor deseja emitir um parecersobre um candidato (logo, todas as suas informacoes dele devem estar acessıveis) e quando umusuario CPG deseja fazer a avaliacao final do candidato (e pode desejar consultar essas informacoespara concluir, juntamente com os pareceres emitidos para o candidato, se o candidato deve ser aceitoou nao). O acesso a documentos durante a emissao de parecer e ilustrado na Figura 18. Cadahiperlink da interface abre uma nova janela no browser exibindo as informacoes armazenadas comoilustrado na Figura 19. As novas janelas que exibem os documentos sao, na verdade, auxiliares,pois o foco principal dessa tarefa e a emissao do parecer, que por isso permanece na janela principal.

4.3.6 Caso de uso: Emitir Parecer

Este caso de uso corresponde a acao de um professor, previamente alocado pelo CPG, emitirum parecer sobre um candidato. O parecer consiste na atribuicao de um conceito ao candidato(dentre os previamentre cadastrados para o processo seletivo em questao), e um comentario quejustifique o conceito atribuıdo sempre que o professor julgar necessario. Com base nos pareceresemitidos pelos professores sera feita a avaliacao final do candidato, resultando em sua aceitacao ounao no programa. Para a emissao do parecer, o professor deve inicialmente analisar as informacoesdisponıveis no sistema a respeito do candidato que fundamentarao sua avaliacao. A Figura 18ilustra a interface do sistema para a emissao de parecer, sendo que o acesso aos documentos e feitocomo descrito pelo caso de uso “Acessar Documentos”.

4.3.7 Caso de uso: Alocar Candidato-Professor

Este caso de uso corresponde a atividade realizada por usuarios CPG ao alocarem professorespara emitirem pareceres sobre candidatos inscritos. A entrevista realizada com o professor RodolfoJardim de Azevedo trouxe alguns esclarecimentos sobre o funcionamento atual dessa alocacao. Se-gundo ele, em geral, um mesmo grupo de professores avalia os mesmos candidatos. E os candidatosavaliados por um professor, em geral, pertencem a mesma instituicao academica, ou pelo menostodos os candidatos de uma mesma instituicao sao alocados para um mesmo professor (a menosque essa quantidade de candidatos seja muito grande).

Essas informacoes sobre o processo impactaram diretamente na interface desse caso de uso,ilustrado na Figura 20. Atraves dela os candidatos aparecem agrupados por instituicao academicae e possıvel selecionar os candidatos isoladamente ou todos de uma mesma instituicao. E possıvelselecionar tambem um conjunto de professores.

A partir de uma selecao de candidatos e professores a alocacao e realizada. Os candidatos eprofessores selecionados sao removidos de suas respecitivas listas na proxima exibicao da mesmainterface. O processo e repetido ate que todos os candidatos tenham sido alocados para professores.

Essa interface tambem possui flexibilidade para selecionar apenas um candidato e um profes-sor para avalia-lo, o que e necessario para o caso de pareceres muito discrepantes de um mesmocandidato, que acarreta em uma nova rodada de emissao de pareceres.

22

4.3.8 Caso de uso: Acessar Parecer

Este caso de uso relaciona-se a atividade do usuario CPG acessar os parecer emitidos porprofessores sobre um candidato. Esse acesso consiste na visualizacao dos conceitos atribuıdos ecomentarios realizados pelos professores sobre os candidatos. Em geral, o acesso aos pareceres temfuncionamento similar ao caso de uso “Acessar Documentos” descrito anteriormente. Ocorre quedepois de emitido um parecer, ele passa a ser vinculado ao candidato tornando-se mais um dosdocumentos existentes sobre o candidato.

4.3.9 Caso de uso: Definir Candidatos Aceitos

Este caso de uso corresponde a avaliacao final realizada pelos usuarios CPG, que selecionamos candidatos aceitos e recusados no processo de selecao. A interface do sistema para essa funci-onalidade e ilustrada na Figura 21. Com base nas informacoes existentes sobre os candidatos econsiderando-se principalmente os conceitos atribuıdos pelos professores que os avaliaram, decide-sese um candidato sera aceito ou nao.

Essa interface exibe os candidatos ordenados pela media das avaliacoes recebidas, apresentandoos conceitos obtidos em cada parecer. Um dado importante, que por sugestao do professor RodolfoJardim de Azevedo foi incorporado a essa interface, e a discrepancia entre o maior e o menor conceitorecebidos pelo candidato. Segundo ele, em casos de avaliacoes muito diferentes e necessaria umanova rodada de avaliacao para esse candidato. Esses casos nem sempre sao faceis de se identificar.A interface proposta explicita essa informacao, facilitando a identificacao dessas situacoes. Casoas informacoes apresentadas nessa tela nao sejam por si so conclusivas, o usuario CPG pode optarpor acessar os documentos do candidato antes de dar sua avaliacao final.

4.3.10 Caso de uso: Notificar Candidatos Aceitos

Este caso de uso corresponde a notificacao automatica dos candidatos aceitos para ingressaremno programa de pos-graduacao. Com a finalizacao de um processo seletivo, os candidatos aceitos saonotificados via e-mail e tem um prazo pre-estabelecido pelo CPG para manisfestarem seu interessepela vaga. Ocorre algumas vezes de alunos nao serem aceitos mas tambem nao serem eliminados,e a confirmacao do interesse pela vaga faz com que haja tempo para selecionar um novo candidato.Mesmo quando nao ha desistencia, os candidatos nessa situacao deverao ficar disponıveis paraconsultas no sistema. Ocorre casos em que professor convidam alguns desses candidatos paraingressarem no programa como alunos especiais, para posteriormente ingressarem como regularesno semestre seguinte. A notificacao via e-mail e feita automaticamente pelo sistema e nao possuiuma interface associada.

4.4 Funcionalidades desejaveis Implementadas no Sistema

Das funcionalidades especificadas na secao 3.3 algumas foram implementadas e sao descritas aseguir. As demais sao sugeridas como extensoes do projeto.

Uma das funcionalidades atendida foi que o sistema proposto possibilitasse que o processo deinscricao de candidatos ao programa e de avaliacao de candidatos fosse feito totalmente “on-line”.Isto foi implementado atraves do envio de arquivos contendo os documentos antes enviados empapel e seu armazenamento no banco de dados proposto. Isso automatiza nao so a inscricao docandidato, que nao entrega documentos em papel, como tambem o processo de emissao de parecerese avaliacao final. Os varios professores alocados para avaliar um mesmo candidato poderao faze-lo ao mesmo tempo, sem ter que compartilhar pastas de documentos ou fichas. Espera-se que

23

a possibilidade de realizacao dessas atividades em paralelo traga mais agilidade ao processo deselecao.

Outra funcionalidade desejavel do sistema era relacionada a validacao do usuario recomendante.Nesse sentido, a implementacao instrui o usuario candidato a cadastrar o e-mail institucional dorecomendante, e e atraves desse e-mail que se faz a busca pelo seu registro no sistema, seu cadastroquando nao encontrado no sistema e a notificacao de cartas pendentes. Desta forma, o e-maildo RECOMENDANTE e vinculado a carta de recomendacao emitida, tornando-o mais vısıvel, equando nao se trata de um e-mail institucional o CPG podera tomar as providencias necessariaspara a validacao do recomendante.

Uma importante funcionalidade identificada em entrevistas com o professor Rodolfo Jardim e aidentificacao de pareceres muito discrepantes emitidos por professores sobre um mesmo candidato.Isso faz necessaria uma re-avaliacao do candidato, por outros professores, na tentativa de entrar emum consenso a respeito de qual e a real nota do candidato. As interfaces propostas tentam identificaressas situacoes apresentando, alem dos conceitos dados pelos professores (apresentados proximosuns dos outros), a diferenca entre o conceito maximo e o mınimo obtido pelo candidato. E possıveltambem acessar os documentos do candidato, inclusive os pareceres emitidos para visualizacao dasjustificativas de cada conceito nas avaliacoes dos professores, o que permitira uma escolha maisadequada do professor que devera ser alocado para avaliar o candidato na proxima rodada deavaliacoes.

Uma outra funcionalidade desejavel era prover meios para que os professores interessados emnovos orientados pudessem analisar candidatos nao aprovados apos o termino do processo de selecao.Isto e permitido atraves de uma das consultas previstas no sistema, que recupera uma listagemdos alunos que nao foram aceitos mas tambem nao foram recusados. Caso algum professor tenhainteresse, podera acessar todos os documentos disponiveis no sistema sobre o candidato.

O gerenciamento de usuarios com varios papeis no sistema e feito apos a efetuacao do login(ilustrado na Figura 7) como ilustrado na figura 8. Desta forma e possıvel, apos o login, escolherqual papel quer representar no sistema e visualizar apenas as funcionalidades disponıveis paraaquele papel. Isso torna a interface mais clara, isolando as funcionalidades. Alem disso, a mudancade papel no sistema nao exige que o usuario tenha que sair do sistema e logar novamente.

4.5 Consultas Suportadas pelo Sistema

As consultas implementadas no sistema podem ser agrupadas em tres principais tipos:(1) asconsultas tıpicas da aplicacao, como insercao e recuperacao de informacoes no banco para preenchi-mento de cadastros, recuperacao de informacoes para construcao de interfaces e menus, e outros;(2) as consultas voltadas para o usuario professor, apresenta informacoes relevantes a respeito docandidato e auxilia a avaliacao do professor a respeito do candidato na emissao do parecer; e (3)consultas voltadas para o usuario CPG, que apresenta estatısticas relacionadas ao processo deselecao em si, e caracterısticas relevantes sobre ele.

A seguir, algumas consultas tıpicas do sistema sao apresentadas seguidas da implementacaoem SQL.

“Retorna as funcionalidades de um usuario de id <id-usu>, segundo uma permissao <id-permiss>”select f.nome, f.linkfrom usuario as u, usuario-papel as up, papel as p, papel-funcionalidade as pf, funcionalidade as fwhere u.id-usuario=up.id-usuario and up.id-papel=p.id-papel and p.id-papel=pf.id-papel and pf.id-

24

funcionalidade=f.id-funcionalidade and u.id-usuario=<id-usu> and p.id-papel=<id-permiss>;

“Retorna as permissoes de um usuario com id <id-usu>”select p.id-papel, p.tipofrom usuario-papel as up, papel as pwhere up.id-papel=p.id-papel and up.id-usuario=<id-usu>;

A seguir, algumas consultas voltadas para o usuario professor sao apresentadas seguidas daimplementacao em SQL.

“Retorna a posicao no POSCOMP do candidato de id-usuario <id> dentre os candidatosinscritos para o processo seletivo que vieram da mesma instituicao dado o id do processo seletivo<id-proc>”select count(*)from Poscomp as p1, Poscomp as p2, Candidato as c, Ficha as f, Formacao-Academica as fa1,Formacao-Academica as fa2where f.id-selecao=<id-proc> and f.id-usuario=c.id-usuario and p1.id-usuario=c.id-usuario andp2.id-usuario=<id> and p1.classificacao-nacional < p2.classificacao-nacional and p1.ano=(selectmax(p11.ano) from Poscomp as p11 where p11.id-usuario=p1.id-usuario) and p2.ano=(selectmax(p22.ano) from Poscomp as p22 where p22.id-usuario=p2.id-usuario) and p1.id-usuario=fa1.id-usuario and p2.id-usuario=fa2.id-usuario and fa1.id-instituicao=fa2.id-instituicao and fa1.data-fim=(select max(faa1.data-fim) from Formacao-academica as faa1 where faa1.id-usuario=fa1.id-usuario) and fa2.data-fim=(select max(faa2.data-fim) from Formacao-academica as faa2 wherefaa2.id-usuario=fa2.id-usuario)

“Retorna a posicao no POSCOMP do candidato de id-usuario <id> dentre todos candida-tos inscritos para o processo seletivo dado o id do processo seletivo <id-proc>”select count(*)from Poscomp as p1, Poscomp as p2, Candidato as c, Ficha as f,where f.id-selecao=<id-proc> and f.id-usuario=c.id-usuario and p1.id-usuario=c.id-usuario andp2.id-usuario=<id> and p1.classificacao-nacional < p2.classificacao-nacional and p1.ano=(selectmax(p11.ano) from Poscomp as p11 where p11.id-usuario=p1.id-usuario) and p2.ano=(selectmax(p22.ano) from Poscomp as p22 where p22.id-usuario=p2.id-usuario)

A seguir, algumas consultas votadas para usuarios CPG sao apresentadas seguidas por suasimplementacoes em SQL.

“Retorne o id, o nome e o numero de alunos inscritos das instituicoes que possuem candi-datos que participam do processo de id <id-proc>”select i.id-instituicao, i.nome, count(c.id-usuario)from Instituicao as i, Formacao-academica as fa, Candidato as c, Ficha as fwhere f.id-selecao=<id-proc> and f.id-usuario=c.id-usuario and c.id-usuario=fa.id-usuario andfa.id-instituicao=i.id-instituicao and fa.data-fim=(select max(faa.data-fim) from Formacao-Academica as faa where fa.id-usuario=faa.id-usuario)group by i.id-instituicao, i.nome

“Retorna as instituicoes e o numero de candidatos que as escolheram como primeira opcao

25

no processo seletivo de id <id-proc>”select i.nome, count(c.id-usuario) as num-candidatosfrom Candidato as c, Ficha as f, Outras-instituicoes as oi, Instituicao as iwhere f.id-selecao=<id-proc> and f.id-usuario=c.id-usuario and f.id-ficha=oi.id-ficha and oi.id-instituicao=i.id-instituicao and oi.ordem-preferencia=1group by i.nomeorder by num-candidatos desc

“Retorna o nome da instituicao e a media dos pesos dos conceitos atribuıdos a todos osalunos da instituicao ordenados por essa media em ordem decrescente, dado id <id-proc> doprocesso seletivo”select i.nome, avg(co.nota) as mediafrom Candidato as c, Ficha as f, Parecer as p, Conceitos as co, Formacao-academica as fa,Instituicao as iwhere f.id-selecao=<id-proc> and f.id-usuario=c.id-usuario and c.id-usuario=p.id-usuario andp.id-usuario=c.id-usuario and c.id-usuario=fa.id-usuario and fa.id-instituicao=i.id-instituicaogroup by i.nomeorder by media desc

“Retorne as outras instituicoes em que os candidatos ao processo seletivo do IC tambem secandidataram. As tuplas de retorno sao ordenadas em ordem descrescente em relacao numero decandidatos que tentaram na instituicao. Alem do nome da instituicao, o numero de candidatostambem e retornado. O id <id-proc> do processo seletivo e dado.”select i.nome, count(c.id-usuario) as num-candidatosfrom Candidato as c, Ficha as f, Outras-instituicoes as oi, Instituicao as iwhere f.id-selecao=<id-proc> and f.id-usuario=c.id-usuario and f.id-ficha=oi.id-ficha and oi.id-instituicao=i.id-instituicaogroup by i.nomeorder by num-candidatos desc

5 Dificuldades Enfrentadas

As dificuldades iniciais encontradas no projeto relacionavam-se a especificacao dos requisitosdo sistema. O processo de selecao para o programa de pos-graduacao sofre constantes mudancasno que diz respeito aos criterios de avaliacao dos candidatos, nao sendo possıvel precisar ate queponto a padronizacao no processo e realmente desejavel. A falta de divulgacao a respeito dasparticularidades do processo de avaliacao tambem dificultou a especificacao de requisitos, umavez que os desenvolvedores (alunos de mestrado do IC) tem conhecimento apenas de parte doprocesso, correspondente a inscricao de candidatos. Essas dificuldades foram contornadas atravesde entrevistas com professores envolvidos no processo, Rodolfo Jardim de Azevedo e Ricardo Torres,e discussoes na equipe de desenvolvimento. Tanto o diagrama de casos de uso quanto o diagramaEntidade-Relacionamento proposto passaram por varias versoes intermediarias ate alcancar a versaodescrita nesse documento, implementada no sistema.

Posteriormente, surgiram alguns problemas decorrentes da informatizacao do processo, como oenvio de documentos via papel que nao era mais desejavel. Para essa situacao, propos-se a solucaode envio de documentos em formato eletronico. Varias questoes tiveram de ser consideradas, como

26

quais extensoes de arquivos eram aceitaveis, como autentica-los e como armazena-los, no bancode dados proposto ou fora dele. Alem disso, durante as entrevistas com os professores detectou-sea existencia de algumas funcionalidades desejaveis ao sistema, nao previstas anteriormente, quedeveriam ser atendidas.

Entretanto, a principal dificuldade enfrentada relaciona-se as tecnologias de implementacaodo sistema. Inicialmente, a implementacao do sistema seria realizada utilizando-se as tecnologiasPython, Zope e Plone. Era conhecido que o aprendizado da tecnologia se tratava de um dosdesafios do projeto e tambem uma motivacao. Acreditou-se que a utilizacao dessas tecnologiasagilizariam o processo de desenvolvimento e investiu-se aproximadamente um mes para investigacaodessas ferramentas. Entretanto a curva de aprendizado se mostrou muito superior a estimada eessas ferramentas se mostraram demasiadamente complexas, dado o curto tempo disponıvel paraaprendizado e desenvolvimento do sistema. Apos muitas tentativas, optou-se por abandonar aproposta inicial e iniciar a implementacao em outras tecnologias, descritas na secao 4.1. Porem, oandamento do projeto foi altamente prejudicado, ocasionando um atraso em relacao ao cronogramainicial no que diz respeito a implementacao do sistema, fazendo com que a etapa de validacao naofosse realizada como proposta incialmente.

6 Trabalhos Futuros

Dada as dificuldades encontradas no desenvolvimento do projeto (descritas na secao 5) e oatraso no cronograma previsto causado por essas dificuldades, a etapa de validacao do sistema naofoi realizada. A realizacao de testes com usuarios reais possivelmente traria contribuicoes muitosignificativas para o projeto, considerando-se que as informacoes obtidas das entrevistas com osprofessores envolvidos no processo seletivo foram extremamente relevantes. Portanto, o principaltrabalho futuro vislumbrado para o projeto e a realizacao de uma etapa de validacao no sistemaimplementado.

Alem disso, varios casos de uso foram especificados e descritos, mas nao foram efetivamenteimplementados no sistema. Grande parte deles tratam de funcionalidades de gerenciamento decontas no sistema, como “alterar” e “recordar senha”, que possuem implementacoes trabalhosas maspouco significativas para a essencia do processo seletivo. O caso de uso que permite ao candidato“acompanhar o status da sua avaliacao”, ao contrario, possui grande relevancia para o sistema navisao do candidato, por se tratar da unica ponte de comunicacao de um candidato ja inscrito como sistema. Alem disso, os casos de uso do usuario recomendante tambem nao foram contempladospela implementacao, como a “emissao de cartas de recomendacao” e o “preenchimento de cadastro”.A implementacao desses casos de uso tambem e sugerida como trabalhos futuros desse projeto. Aimplementacao de todos os casos de uso propostos tornaria a validacao do sistema proposto maisconclusiva.

A “criacao de processos seletivos” e “definicao dos conceitos” a serem usados no processo, apesarde poderem ser feitas manualmente no banco de dados, tambem devem ser consideradas comotrabalhos futuros no sistema. Alem disso, um estudo do formato atual fornecido do resultado doPOSCOMP e a implementacao de um mecanismo de recuperacao automatica para cada candidatotambem traria grandes contribuicoes para o projeto. Ficam propostas tambem, como projetosfuturos, opcoes de edicao e exclusao de informacoes cadastradas pelos casos de uso implementados,que em alguns casos e desejavel.

27

7 Conclusoes

Este documento apresentou a proposta de um Sistema de Informacao para o Gerenciamentodo Processo Seletivo da Pos-Graduacao do Instituto de Computacao da Unicamp. A propostado sistema e informatizar todo o processo existente atualmente, considerando as visoes do CPG,que gerencia todo o processo de selecao; dos professores, que avaliam os candidatos emitindopareceres; dos recomendantes, que participam do processo emitindo cartas de recomendacao sobreos candidatos e, por fim, dos candidatos que se inscrevem nos processos seletivos.

A metodologia adotada no desenvolvimento deste projeto previa tres etapas: o levantamentode requisitos e projeto, a implementacao e a validacao do sistema proposto. As etapas realizadassao descritas neste documento. Devido as dificuldades encontradas no decorrer do projeto, princi-palmente relacionas as tecnologias, a etapa de validacao nao foi realizada. Entretanto, considera-seque as contribuicoes inicialmente previstas para o projeto foram alcancadas. Sao elas:

• O levantamento dos documentos e formularios necessarios para a inscricao de candidatos deMestrado e Doutorado no IC, identificando possıveis inconsistencias e redundancias existen-tes. Alem disso, as entrevistas realizadas com professores envolvidos no processo de selecaotrouxeram a tona varios requisitos e funcionalidades desejaveis para o sistema, que estaodocumentados neste documento.

• A modelagem e implementacao do banco de dados relacional capaz de comportar as in-formacoes armazenadas pelo sistema. Este trabalho propos uma modelagem que abrange oscasos de uso identificados e as funcionalidades propostas.

• A especificacao e a implementacao do sistema web, utilizando o banco de dados implemen-tado, para o gerenciamento do processo de selecao do programa de pos-graduacao do IC.Embora alguns casos de uso nao tenham sido implementados, um subconjunto de casos deuso (considerado mais importante) foi implementado.

• O armazenamento digital das informacoes relativas aos processos de selecao. Isso trazinumeras vantagens ao processo em si, relacionadas a facilidade de acesso das informacoesquanto a mobilidade e acesso paralelo por usuarios diferentes.

• Possibilidade de consultas a informacoes relativas a processos seletivos realizados. Algumasconsultas foram implementadas no sistema, e inumeras outras podem ser realizadas conside-rando os dados armazenados. A possibilidade de recuperacao de informacoes nesse sistemapode trazer grandes contribuicoes e muelhorias a processos futuros.

Por fim, percebeu-se um grande interesse por parte desses professores entrevistados (potenciaisusuarios reais do sistema) em ter um sistema desse tipo implementado e em funcionamento para ge-renciar o processo de selecao do IC. Esses usuarios possuem alem da visao sobre o funcionamento doprocesso em si, uma visao mais ampla dos problemas existentes no processo atual e podem contri-buir substancialmente para na implementacao de um sistema real para este proposito. Considera-seque a principal contribuicao dada por este projeto foi o levantamento e documentacao das carac-terısticas do processo, funcionalidades e problemas a serem tratados, e alem disso, a sugestao eimplementacao de uma solucao para alguns deles.

28

Referencias

[1] http://news.netcraft.com/. Acessado em junho de 2006.

[2] http://plone.org. Acessado em abril de 2006.

[3] http://www3.ca.com/solutions/. Acessado em maio de 2006.

[4] http://www.apache.org/. Acessado em junho de 2006.

[5] http://www.pgadmin.org/. Acessado em maio de 2006.

[6] http://www.php.net. Acessado em junho de 2006.

[7] http://www.postgresql.org/. Acessado em abril de 2006.

[8] http://www.python.org/. Acessado em junho de 2006.

[9] http://www.w3.org/markup/. Acessado em junho de 2006.

[10] http://www.w3schools.com/css/default.asp. Acessado em junho de 2006.

[11] http://www.w3schools.com/js/default.asp. Acessado em junho de 2006.

[12] http://www.zope.org. Acessado em abril de 2006.

[13] Apache Software Foundation. http://httpd.apache.org/. Acessado em junho de 2006.

[14] A. Latteier, M. Pelletier, C. McDonough, and P. Sabaini. The Zope Book. 2.6 edition. Dis-ponıvel on-line em http://www.zope.org/Documentation/Books/ZopeBook/2 6Edition, aces-sado em abril de 2006.

[15] A. McKay. The Definitive Guide to Plone. 1st edition, 2004. Disponıvel on-line emhttp://plone.org/documentation/manual/definitive-guide, acessado em abril de 2006.

29

A Apendice - Banco de Dados em SQL

Descricao dos scripts em SQL utilizados para a criacao do banco de dados no PostgreSQL.

CREATE TABLE FUNCIONALIDADE (id-funcionalidade serial NOT NULL,nome varchar(50) NOT NULL,descricao varchar(50) NOT NULL,link varchar(100) NULL,PRIMARY KEY (id-funcionalidade));

CREATE TABLE PAPEL ( id-papel serial NOT NULL,tipo varchar(20) NOT NULL,PRIMARY KEY (id-papel));

CREATE TABLE PAPEL-FUNCIONALIDADE (id-papel int NOT NULL,id-funcionalidade int NOT NULL,PRIMARY KEY (id-papel, id-funcionalidade),FOREIGN KEY (id-funcionalidade) REFERENCES FUNCIONALIDADE,FOREIGN KEY (id-papel) REFERENCES PAPEL);

CREATE TABLE USUARIO (id-usuario serial NOT NULL,login varchar(20) NULL,senha varchar(20) NULL,e-mail varchar(30) NULL,PRIMARY KEY (id-usuario));

CREATE TABLE USUARIO-PAPEL (id-usuario int NOT NULL,id-papel int NOT NULL,PRIMARY KEY (id-usuario, id-papel),FOREIGN KEY (id-papel) REFERENCES PAPEL,FOREIGN KEY (id-usuario) REFERENCES USUARIO);

CREATE TABLE PROFESSOR (matricula int NULL,nome varchar(50) NULL,id-usuario int NOT NULL,PRIMARY KEY (id-usuario),FOREIGN KEY (id-usuario) REFERENCES USUARIO

30

);

CREATE TABLE POSSIVEL-ORIENTACAO (id-possivel-orientacao serial NOT NULL,data-contato date NULL,id-usuario int NULL,PRIMARY KEY (id-possivel-orientacao),FOREIGN KEY (id-usuario) REFERENCES PROFESSOR);

CREATE TABLE EXTERNO (id-usuario int NOT NULL,nome varchar(50) NULL,logradouro-end varchar(100) NULL,numero-end int NULL,complemento-end varchar(20) NULL,cep-end varchar(10) NULL,cidade-end varchar(30) NULL,estado-end varchar(30) NULL,PRIMARY KEY (id-usuario),FOREIGN KEY (id-usuario)REFERENCES USUARIO);

CREATE TABLE CANDIDATO (id-usuario int NOT NULL,data-nascimento date NULL,local-nascimento varchar(30) NULL,nacionalidade varchar(30) NULL,telefone varchar(20) NULL,fax varchar(20) NULL,rg varchar(20) NULL,PRIMARY KEY (id-usuario),FOREIGN KEY (id-usuario) REFERENCES EXTERNO );

CREATE TABLE CPG (id-usuario int NOT NULL,PRIMARY KEY (id-usuario),FOREIGN KEY (id-usuario) REFERENCES USUARIO);

CREATE TABLE PROCESSO-SELETIVO (id-selecao serial NOT NULL,data-limite date NOT NULL,tipo varchar(20) NOT NULL,data-abertura date NOT NULL,id-usuario int NULL,ano int NULL,

31

semestre varchar(20) NULL,PRIMARY KEY (id-selecao),FOREIGN KEY (id-usuario) REFERENCES CPG);

CREATE TABLE FICHA (id-ficha serial NOT NULL,id-selecao int NOT NULL,id-usuario int NOT NULL,num-poscomp varchar(20) NULL,ano-poscomp int NULL,resultado varchar(30) NULL,nota real NULL,solicita-bolsa varchar(4) NULL,condicoes-bolsa varchar(4) NULL,programa-agencia varchar(30) NULL,situacao-programa-agencia varchar(30) NULL,id-possivel-orientacao int NULL,data-inscricao date NULL,plano-trabalho varchar(5000) NULL,informacoes-adicionais varchar(1000) NULL,PRIMARY KEY (id-ficha),FOREIGN KEY (id-possivel-orientacao) REFERENCES POSSIVEL-ORIENTACAO,FOREIGN KEY (id-usuario) REFERENCES CANDIDATO,FOREIGN KEY (id-selecao) REFERENCES PROCESSO-SELETIVO);

CREATE TABLE AREA-INTERESSE (id-area serial NOT NULL,nome varchar(50) NULL,PRIMARY KEY (id-area));

CREATE TABLE AREA-INTERESSE-CANDIDATO (id-area int NOT NULL,id-ficha int NOT NULL,ordem int NULL,PRIMARY KEY (id-area, id-ficha),FOREIGN KEY (id-ficha) REFERENCES FICHA,FOREIGN KEY (id-area) REFERENCES AREA-INTERESSE);CREATE TABLE POSCOMP (num-inscricao int NOT NULL,ano int NOT NULL,num-acertos-matematica int NOT NULL,num-acertos-fundamentos int NOT NULL,num-acertos-tecnologica int NOT NULL,

32

id-usuario int NULL,classificacao-nacional int NULL,PRIMARY KEY (num-inscricao),FOREIGN KEY (id-usuario) REFERENCES CPG,FOREIGN KEY (id-usuario) REFERENCES CANDIDATO);CREATE TABLE RECOMENDANTE (id-usuario int NOT NULL,instituicao-empresa varchar(30) NULL,cargo varchar(50) NULL,grau-academico varchar(30) NULL,instituicao-grau varchar(30) NULL,ano-grau int NULL,area-especialidade varchar(50) NULL,PRIMARY KEY (id-usuario),FOREIGN KEY (id-usuario) REFERENCES EXTERNO);

CREATE TABLE CONCEITOS (id-conceito serial NOT NULL,peso varchar(10) NOT NULL,nota real NULL,id-selecao int NULL,PRIMARY KEY (id-conceito),FOREIGN KEY (id-selecao) REFERENCES PROCESSO-SELETIVO);

CREATE TABLE PARECER (id-parecer serial NOT NULL,comentario varchar(1000) NULL,id-ficha int NULL,id-conceito int NULL,id-usuario int NOT NULL,PRIMARY KEY (id-parecer),FOREIGN KEY (id-conceito) REFERENCES CONCEITOS,FOREIGN KEY (id-ficha) REFERENCES FICHA,FOREIGN KEY (id-usuario) REFERENCES CANDIDATO,FOREIGN KEY (id-usuario) REFERENCES PROFESSOR);

CREATE TABLE CANDIDATO-RECOMENDACAO (id-candidato-recomendacao serial NOT NULL,id-usuario-recomendante int NOT NULL,id-usuario-candidato int NOT NULL,data-pedido date NULL,PRIMARY KEY (id-candidato-recomendacao),FOREIGN KEY (id-usuario-candidato) REFERENCES CANDIDATO,

33

FOREIGN KEY (id-usuario-recomendante) REFERENCES RECOMENDANTE);

CREATE TABLE CARTA-RECOMENDACAO (id-carta serial NOT NULL,data-envio date NULL,descricao-conheceu varchar(1000) NULL,descricao-desempenho varchar(1000) NULL,descricao-avaliacao varchar(1000) NULL,descricao-potencial-doutorado varchar(1000) NULL,aproveitamento-disciplinas varchar(20) NULL,conhecimento-cientifico varchar(20) NULL,iniciativa-criatividade varchar(20) NULL,perseveranca varchar(20) NULL,capacidade-expressao-oral varchar(20) NULL,capacidade-expressao-escrita varchar(20) NULL,compara-anos int NULL,id-candidato-recomendacao int NULL,PRIMARY KEY (id-carta),FOREIGN KEY (id-candidato-recomendacao)REFERENCES CANDIDATO-RECOMENDACAO);

CREATE TABLE INSTITUICAO (id-instituicao serial NOT NULL,nome varchar(50) NULL,sigla varchar(10) NULL,cidade varchar(30) NULL,estado varchar(30) NULL,PRIMARY KEY (id-instituicao));

CREATE TABLE FORMACAO-ACADEMICA (id-formacao serial NOT NULL,id-usuario int NOT NULL,nome-curso varchar(50) NULL,data-inicio date NULL,data-fim date NULL,completo varchar(4) NULL,titulacao varchar(30) NULL,id-instituicao int NULL,PRIMARY KEY (id-formacao),FOREIGN KEY (id-instituicao) REFERENCES INSTITUICAO,FOREIGN KEY (id-usuario) REFERENCES CANDIDATO);

CREATE TABLE ORGAO-FINANCIADOR (

34

id-orgao serial NOT NULL,nome varchar(50) NOT NULL,sigla varchar(20) NOT NULL,PRIMARY KEY (id-orgao));

CREATE TABLE BOLSA (id-bolsa serial NOT NULL,id-usuario int NOT NULL,nivel varchar(30) NULL,data-inicio date NULL,id-orgao int NULL,titulo-projeto varchar(500) NULL,data-fim date NULL,PRIMARY KEY (id-bolsa),FOREIGN KEY (id-orgao) REFERENCES ORGAO-FINANCIADOR,FOREIGN KEY (id-usuario) REFERENCES CANDIDATO);

CREATE TABLE EXPERIENCIA-PROFISSIONAL (id-experiencia-profissional serial NOT NULL,id-usuario int NOT NULL,instituicao-empresa varchar(50) NULL,tipo-trabalho varchar(50) NULL,data-inicio date NULL,data-fim date NULL,PRIMARY KEY (id-experiencia-profissional),FOREIGN KEY (id-usuario) REFERENCES CANDIDATO);

CREATE TABLE PREMIO (id-premio serial NOT NULL,id-usuario int NOT NULL,descricao varchar(1000) NULL,PRIMARY KEY (id-premio),FOREIGN KEY (id-usuario) REFERENCES CANDIDATO);

CREATE TABLE INSCRICAO-ANTERIOR (id-inscricao-anterior serial NOT NULL,nome-programa varchar(50) NULL,data-inscricao date NULL,resultado varchar(30) NULL,id-ficha int NULL,PRIMARY KEY (id-inscricao-anterior),FOREIGN KEY (id-ficha) REFERENCES FICHA);

35

CREATE TABLE OUTRAS-INSTITUICOES (id-outras-instituicoes serial NOT NULL,ordem-preferencia int NULL,id-instituicao int NULL,id-ficha int NULL,PRIMARY KEY (id-outras-instituicoes),FOREIGN KEY (id-instituicao) REFERENCES INSTITUICAO,FOREIGN KEY (id-ficha) REFERENCES FICHA);

CREATE TABLE DOCUMENTOS-ENVIADOS (id-documento serial NOT NULL,nome-arquivo varchar(100) NULL,extensao varchar(50) NULL,documento OID NULL,id-ficha int NULL,PRIMARY KEY (id-documento),FOREIGN KEY (id-ficha) REFERENCES FICHA);

36

B Apendice - Banco de Dados Implementado

Este relatorio foi escrito antes da implementacao ser finalizada e alguns pontos descritos nesterelatorio nao estao totalmente condizentes com a implementacao realizada. As principais modi-ficacoes realizadas foram no diagrama ER. A versao utilizada na implementacao e ilustrada naFigura 5. As modificacoes realizadas visam tornar o sistema mais robusto, sendo possıvel reapro-veitar alguns dados do candidato (como bolsas, experiencias profissionais e formacoes academicas)em diferentes fichas de inscricao de um mesmo candidato. Essa funcionalidade de “reaproveita-mento” nao foi contemplada na implementacao do sistema, mas e considerada desejavel para osistema. As alteracoes influenciam diretamente os scripts SQL apresentados neste relatorio, tantopara a criacao do banco de dados como na exemplificacao de algumas consultas, que estao de acordocom o diagrama da Figura 3 e nao o diagrama final implementado.

USUARIO

id_usuario: int

login: varchar(50)senha: varchar(50)e_mail: varchar(50)

CANDIDATO

id_candidato: int

rg: varchar(20)data_nascimento: datelocal_nascimento: varchar(30)nacionalidade: varchar(30)telefone: varchar(20)fax: varchar(20)

PROFESSOR

id_professor: int

matricula: intnome: varchar(50)

RECOMENDANTE

id_recomendante: int

instituicao_empresa: varchar(30)grau_academico: varchar(30)cargo: varchar(50)instituicao_grau: varchar(30)ano_grau: intarea_especialidade: varchar(50)

PARECER

id_parecer: int

id_professor: intid_ficha: intid_conceito: intcomentario: varchar(1000)

CARTA_RECOMENDACAO

id_carta: int

data_pedido: datedata_envio: datedescricao_conheceu: varchar(1000)descricao_desempenho: varchar(1000)descricao_avaliacao: varchar(1000)descricao_potencial_doutorado: varchar(1000)compara_anos: intaproveitamento_disciplinas: varchar(20)perseveranca: varchar(20)conhecimento_cientifico: varchar(20)iniciativa_criatividade: varchar(20)capacidade_expressao_oral: varchar(20)capacidade_expressao_escrita: varchar(20)id_recomendante: intid_ficha: int

FORMACAO_ACADEMICA

id_formacao: int

id_instituicao: intnome_curso: varchar(50)titulacao: varchar(30)completo: varchar(4)data_inicio: datedata_fim: date

BOLSA

id_bolsa: int

id_orgao: intnivel: varchar(30)titulo_projeto: varchar(500)data_inicio: datedata_fim: date

EXPERIENCIA_PROFISSIONAL

id_experiencia_profissional: int

instituicao_empresa: varchar(50)tipo_trabalho: varchar(50)data_inicio: datedata_fim: date

PREMIO

id_premio: int

titulo_premio: varchar(50)descricao: varchar(1000)

INSCRICAO_ANTERIOR

id_inscricao_anterior: int

nome_programa: varchar(50)data_inscricao: varchar(50)resultado: varchar(30)

OUTRA_INSTITUICAO

id_outras_instituicoes: int

ordem_preferencia: intid_ficha: intid_instituicao: int

DOCUMENTO_ENVIADO

id_documento: int

tipo: varchar(100)documento: OIDextensao: varchar(50)

EXTERNO

id_usuario: int

nome: varchar(50)logradouro_end: varchar(100)numero_end: intcomplemento_end: varchar(20)cep_end: varchar(10)cidade_end: varchar(30)estado_end: varchar(30)

CPG

id_cpg: int

INSTITUICAO

id_instituicao: int

nome: varchar(50)sigla: varchar(10)cidade: varchar(30)estado: varchar(30)

AREA_INTERESSE

id_area: int

nome: varchar(50)

ORGAO_FINANCIADOR

id_orgao: int

nome: varchar(50)sigla: varchar(20)

PROCESSO_SELETIVO

id_selecao: int

ano: intsemestre: varchar(20)tipo: varchar(20)data_abertura: datedata_limite: dateid_cpg: int

CONCEITO

id_conceito: int

peso: varchar(10)nota: float

FICHA

id_ficha: int

solicita_bolsa: varchar(4)condicoes_bolsa: varchar(4)programa_agencia: varchar(30)situacao_programa_agencia: varchar(30)plano_trabalho: varchar(5000)informacoes_adicionais: varchar(1000)ordem_preferencia_unicamp: intdata_inscricao: dateid_possivel_orientacao: intid_candidato: intid_selecao: intresultado: varchar(30)nota: float

POSCOMP

num_inscricao_poscomp: int

ano: intnum_acertos_matematica: intnum_acertos_fundamentos: intnum_acertos_tecnologica: intclassificacao_nacional: intnum_acertos: int

POSSIVEL_ORIENTACAO

id_possivel_orientacao: int

data_contato: dateid_professor: intAREA_INTERESSE_CANDIDATO

id_area: intid_ficha: int

ordem: int

PAPEL

id_papel: int

tipo: varchar(20)

USUARIO_PAPEL

id_usuario: intid_papel: int

FUNCIONALIDADE

id_funcionalidade: int

nome: varchar(50)descricao: varchar(50)link: varchar(100)

PAPEL_FUNCIONALIDADE

id_papel: intid_funcionalidade: int

FICHA_BOLSA

id_bolsa: intid_ficha: int

FICHA_EXPERIENCIA

id_experiencia_profissional: intid_ficha: int

FICHA_PREMIO

id_ficha: intid_premio: int

FICHA_POSCOMP

id_ficha: intnum_inscricao_poscomp: int

FICHA_DOCUMENTOS

id_ficha: intid_documento: int

FICHA_FORMACAO

id_ficha: intid_formacao: int

FICHA_INSCRICAO_ANTERIOR

id_ficha: intid_inscricao_anterior: int

PROCESSO_CONCEITO

id_selecao: intid_conceito: int

Figura 5: Banco de Dados Implementado

37

C Apendice - Telas da Interface do Sistema

Figura 6: Interface de Cadastro para Usuarios Candidatos no Sistema

38

Figura 7: Interface de Login no sistema

39

Figura 8: Interface da Escolha de Papel para Acessar o Sistema

40

Figura 9: Interface do Formulario de Inscricao: Dados Pessoais e Endereco

41

Figura 10: Interface do Formulario de Inscricao: Dados sobre o Programa e Outras Informacoes

42

Figura 11: Interface do Formulario de Inscricao: Formacao Academica

43

Figura 12: Interface do Formulario de Inscricao: Insercao de varias Formacoes Academicas

44

Figura 13: Interface do Formulario de Inscricao: Bolsas de Estudo

45

Figura 14: Interface do Formulario de Inscricao: Experiencia Profissional

46

Figura 15: Interface do Formulario de Inscricao: Envio de Documentos Juntamente com a Inscricao

47

Figura 16: Interface do Formulario de Inscricao: Areas de Interesse e Plano de Trabalho

48

Figura 17: Interface do Formulario de Inscricao: Indicacao de Recomendantes

49

Figura 18: Interface para a Emissao de Parecer com a Visualizar dos Documentos do Candidato

50

Figura 19: Interface de Acesso a Documentos do Candidato: Historico

51

Figura 20: Interface para a Alocacao de Candidatos a Professores Avaliadores

52

Figura 21: Interface para a Avaliacao Final dos Candidatos

53