Um Sistema Virtual para a Proposta de Projetos, Inscricao ...

tamerunSoftware and s/w Development

Aug 15, 2012 (5 years and 3 months ago)

530 views

UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO

CENTRO TECNOLÓGICO

CURSO DE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO





VITOR FAIÇAL CAMPANA





Sistema virtual para publica
ção de
temas
para

projetos
com

sele
ção

autom
ática

de
alunos









VITÓRIA

2006
VITOR FAIÇAL
CAMPANA





Sistema virtual para publicação de
temas para projetos
com

seleção
autom
á
ti
ca

de alunos























VITÓRIA

2006
Monografia apresentada

como exigência parcial para
obtenção do título de Engenheiro de Computação à
Universidade Federal do Espírito Santo sob orientação
do Prof. Dr.
Orivaldo de Lira Tavares.

V
V
I
I
T
T
O
O
R
R


F
F
A
A
I
I
Ç
Ç
A
A
L
L


C
C
A
A
M
M
P
P
A
A
N
N
A
A








Sistema virtual para publicação de
temas para projetos
com

seleção
autom
á
ti
ca

de alunos





COMISS
ÃO EXAMINADORA


_________________________________________________

Prof. Orivaldo de Lira Tavares

UFES
-

Universidade Federal do Espírito Santo



___________________________________________________

Prof.
Sergio Teixeira

Faculdade Salesiana de Vitória


_____
______________________________________________

Prof.
Marcello Novaes

UFES
-

Universidade Federal do Espírito Santo




Vitória
-

ES,
28

de
dezembro

de 2006.
RESUMO


O principal objetivo desse trabalho foi desenvolver uma aplicação
Web

em
que professores da
universidade possa
m

cadastrar temas para projetos a
serem
desenvolvidos e a própria aplicação se encarregue de selecionar
os alunos para
desenvolvedores desses projetos
,

além de disponibilizar um ambiente que
permite o
envio de propostas para temas por org
anizações ou empresas externas a instituição.




































2

LISTA DE FIGURAS



Figura 2.1: Representação da arquitetura cliente/servidor

................................
........

10

Figura 2.2: Uma arquitetura de hardware cliente
-
servidor duas camadas.

...............

10

Figura 2.3: Uma arquitetura de hardware cliente
-
servidor três camadas

..................

11

Figura 2.4: Uma arquitetura de hardware cliente
-
servidor n camadas

......................

11

Figura 2.5: Camadas de Software

................................
................................
.............

12

Figura 2.6: Tipos mais comuns de Servlet Containers

................................
..............

19

Figura 2.7: Representação de um mapeamento O/R e um banco OO

......................

21

Figura 2.8: Benchmarks do db4o e algumas soluções de mapeamento O/R

............

22

Figura 2.9: Página do Departamento de Engenharia de Sistemas e Computação da
UERJ

................................
................................
................................
..................

24

Figura 2.10: Página do Projeto Poli
-
Cidadã da Escola Politécnica da USP

..............

25

Figura 2.11: Projeto Poli
-
Cidadã
-

Cadastro de Temas (Dados do Organismo)

........

26

Figura 2.12: Projeto Poli
-
Cidadã
-

Cadastro de Temas (Descrição do Tema)

..........

27

Figura 3.1: Diagrama de Casos de Uso para Professor
, Aluno e Organização.
........

30

Figura 4.1: Diagrama de Classes

................................
................................
..............

39

Figura 4.2: Diagrama de seqüência
-

Caso de uso “Cadastrar
-
se”.

..........................

44

Figura 4.3: Diagrama de seqüência
-

Caso de uso “Autenticar
-
se”.

..........................

45

Figura 4.4: Diagrama de seqüência
-

Caso de uso “Cadastrar T
ema”.

.....................

45

Figura 4.5: Diagrama de seqüência


Casos de uso “Consultar Temas”, “Fazer
Pergunta”, “Verificar Resultado” e “Aceitar Tema” para o ator “Aluno”.

............

46

Figura 4.6: Diagrama de seqüência


Casos de uso “Consultar Temas”, “Responder
Pergunta” e “Verificar Resultado” para o ator “Professor”

................................
..

47

Figura 4.7: Diagrama
de seqüência


Caso de uso “Consultar Proposta” e “Aceitar
Proposta”

................................
................................
................................
............

48

Figura 4.8: Diagrama de seqüência


Caso de uso “Cadastrar Proposta”

................

48

Figura 4.9: Diagrama de seqüência


Casos de uso “Verificar a situação das
propostas” e “Fazer Pergunta” para o ator “Organização”

................................
.

49

Figura 5.1: Modelo Conceitual do Sistema

................................
................................

51

Figura 5.2: AlunoDAO

................................
................................
...............................

52

Figura 5.3: ProfessorDAO

................................
................................
.........................

53

Figura 5.4
: OrganizacaoDAO

................................
................................
....................

54

Figura 5.5: TemaDAO

................................
................................
...............................

55

Figura 5.6: PropostaDAO

................................
................................
..........................

56

Figura 5.7: DesenvolvedorDAO

................................
................................
.................

57


3

Figura 5.8: PerguntaDAO

................................
................................
..........................

58

Figura 5.9: Modelo de navegação


Cenário Cadastro do caso de u
so Cadastrar
-
se

................................
................................
................................
...........................

59

Figura 5.10: Modelo de navegação
-

Caso de uso Autenticar
-
se

..............................

60

Figura 5.11: Modelo de navegação
-

Caso de us
o Cadastrar Proposta

....................

61

Figura 5.12: Modelo de navegação
-

Cenário Cadastro do caso de uso Cadastrar
Tema

................................
................................
................................
..................

61

Figura 5.13: Modelo

de navegação
-

Caso de uso Consultar Propostas/Verificar
Situação das Propostas

................................
................................
.....................

62

Figura 5.14: Modelo de navegação
-

Caso de uso Consultar Temas

........................

62

Figura 5.15: Modelo de navegação
-

Caso de uso Fazer Pergunta

..........................

63

Figura 5.16: Modelo de navegação
-

Caso de uso Aceitar Tema

..............................

63

Figura 6.1: Tela inicial do sistema

................................
................................
.............

65

Figura 6.2: Tela de autenticação do sistema

................................
.............................

65

Figura 6.3: Tela de
cadastro de aluno

................................
................................
.......

66

Figura 6.4: Tela de cadastro de professor

................................
................................
.

66

Figura 6.5: Tela de cadastro de organização

................................
............................

67

Figura 6.6: Tela de navegação do aluno

................................
................................
...

68

Figura 6.7: Tela de resultado da busca por temas

................................
....................

68

Figura 6.8: Tela de exibição de um Tema

................................
................................
.

69

Figura 6.9: Tela de verificação de resultado de um tema com seleção em andamento

................................
................................
................................
...........................

70

Figura 6.10: Tela de verificação de resultado de um tema com seleção finalizada
...

71

Figura 6.11: Tela de navegação do professor

................................
...........................

72

Figura 6.12: Tela de consulta de propostas

................................
..............................

72

Figura 6.13: Tela de exibição de proposta

................................
................................

73

Figura 6.14: Tela de
cadastro de tema

................................
................................
......

74

Figura 6.15: Tela de tema

................................
................................
.........................

75

Figura 6.16: Tela de navegação da organização

................................
......................

76

Figura 6.17: Tela de cadastro de proposta para temas

................................
.............

77

Figura 6.18: Tela de exibição de proposta quando originou algum tema

..................

78









4

SUMÁRIO


CAPÍTULO 1
-

INTRODUÇÃO

................................
.............................

6

1.1.

O
BJETIVOS

................................
................................
................................
.........

6

1.2.

J
USTIFI
CATIVAS

................................
................................
................................
..

7

1.3.

M
ETODOLOGIA

................................
................................
................................
...

7

1.4.

E
STRUTURA DO TRABALHO

................................
................................
..................

8

CAPÍTU
LO 2
-

TECNOLOGIAS E TRABAL
HOS CORRELATOS

.........

9

2.1.

T
ECNOLOGIAS E
M
ÉTODOS

................................
................................
..................

9

2.1.1.

Arquitetura cliente
-
servidor

................................
................................
......

9

2.1.2.

Orientação a Objetos

................................
................................
.............

13

2.1.3.

UML (Unified Modeling Language)

................................
........................

14

2.1.4.

S
ervlets e JSP

................................
................................
.......................

16

2.1.5.

NetBeans IDE

................................
................................
........................

20

2.1.6.

JavaScript

................................
................................
..............................

20

2.1
.7.

Db4o


Banco de Dados Orientado a Objetos

................................
.......

21

2.1.8.

Sistema WEB Gerenciador de Perfis (SWGP)

................................
.......

23

2.2.

S
ISTEMAS
C
ORRELATOS

................................
................................
...................

23

CAPÍTULO 3
-

ESPECIFICAÇÃO DE REQ
UISITOS

..........................

28

3.1.

D
ESCRIÇÃO DO
M
INI
-
M
UNDO

................................
................................
.............

28

3.2.

C
ASOS DE
U
SO

................................
................................
................................

29

3.2.1.

Caso de Uso Cadastrar
-
se

................................
................................
....

30

3.2.2.

Caso de Uso Autenticar
-
se

................................
................................
....

32

3.2.3.

Caso de Uso Cadastrar Tema

................................
...............................

32

3.2.4.

Caso de Uso Consultar Temas

................................
..............................

33

3.2.5.

Caso d
e Uso Fazer Pergunta

................................
................................

34

3.2.6.

Caso de Uso Responder Pergunta

................................
........................

35

3.2.7.

Aceitar tema

................................
................................
...........................

35

3.2.8.

Caso de Uso Verificar Resultado

................................
...........................

36

3.2.9.

Caso de Uso Cadastrar Proposta

................................
..........................

36

3.2.10.

Caso de Uso V
erificar Situação das Propostas

................................
.....

37

3.2.11.

Caso de Uso Consultar Propostas

................................
.........................

37

3.2.12.

Caso de uso Aceitar Proposta

................................
...............................

38

CAPÍTULO 4
-

ANÁLISE

................................
................................
....

39

4.1.

D
IAGRAMA DE
C
LASSES

................................
................................
....................

39

4.2.

D
ICIONÁRIO DE DAD
OS

................................
................................
......................

40

4.3.

D
IAGRAMAS DE
S
EQUÊNCIA

................................
................................
...............

44

CAPÍTULO 5
-

PROJETO
................................
................................
...

50

5.1
.

M
ODELO
C
ONCEITUAL

................................
................................
.......................

51

5.2.

M
ODELO DE
P
ERSISTÊNCIA

................................
................................
...............

51

5.3.

M
ODELOS DE
N
AVEGAÇÃO

................................
................................
................

58




5

CAPÍTULO 6
-

IMPLEMENTAÇÃO E TELA
S DO SISTEMA

..............

64

6.1.

I
MPLEMENTAÇÃO

................................
................................
..............................

64

6.2.

T
ELAS DO
S
ISTEMA

................................
................................
...........................

64

CAPÍTULO 7
-

CONSIDERAÇÕES FINAIS

................................
........

80

7.1.

A
VALIAÇÃO DO
P
ROTÓTIPO

................................
................................
................

80

7.2.

T
R
ABALHOS
F
UTUROS

................................
................................
.......................

80

7.3.

A
PRENDIZADO ADQUIRIDO

................................
................................
.................

81

REFERÊNCIAS BIBLIOGR
ÁFICAS

................................
.....................

82



6

CAPÍTULO 1
-

INTRODUÇÃO

A cr
iação da Internet permitiu a comunicação e a transferência de dados entre
máquinas de todo o mundo, sendo considerado o instrumento de comunicação de
mais rápido crescimento mundial. As informações encontram
-
se espalhadas pelos
computadores que fazem parte

da rede. Qualquer usuário pode conectar
-
se a essa
rede mundial para ter acesso a variados serviços e informações, tais como:
documentações, textos, imagens, listas de discussão, serviços de compras, entre
outros.

Originada da ARPANET, uma rede criada para

fins militares, a Internet era
utilizada em seus primórdios basicamente por usuários avançado de computadores,
mas conforme foram surgindo as inovações que tornaram seu uso mais acessível a
rede passou a ser utilizada por pesquisadores e estudantes. Atual
mente, é muito
comum que se tenha em casa um computador pessoal, e é muito comum que as
pessoas tenham acesso a esse tipo de tecnologia, tanto em casa quanto no
trabalho, em agências bancárias, em bibliotecas, nos shoppings, em instituições de
ensino. Torn
ou
-
se fácil disponibilizar e divulgar informações a respeito de trabalhos
realizados, congressos, seminários, publicações etc.

Foi nesse contexto que surgiu a motivação para esse projeto, uma Aplicação
Web

onde professores t
ê
m a possibilidade de propor tem
as para projetos que
gostariam de orientar e os alunos poder
em

aceitar desenvolver esses projetos,
desde que sejam selecionados
pelo sistema
de acordo com os perfis definidos po
r

proponente e aluno. O sistema permit
e

ainda que representantes de empresas ou

organizações

cadastrem propostas
de
temas que serão avaliadas por professores.


1.1.

Objetivos

Facilitar e agilizar o contato entre professores orientadores e alunos que
tenham interesse em desenvolver algum projeto acadêmico, além de ser uma
oportunidade para

aproximar a Universidade e as empresas interessadas em
colaborar no desenvolvimento científico, a partir do cadastro de propostas para
temas
.



7

Objetivo específico

Desenvolver um sistema
W
eb

para permitir a publicação de idéias para
projetos e a seleção de

interessados em desenvolvê
-
los.


1.2.

Justificativas

É uma forma de centralizar a oferta de temas para projetos acadêmicos,
tornando
-
as acessíveis a um número muito maior de alunos, fazendo com que os
alunos que já se interessem por alguma área espec
í
fica tenh
am facilidade em
encontrar temas para desenvolver e que outros adquiram interesse.

A possibilidade de empresas ou indústrias cadastrarem propostas beneficiará
essas organizações e a comunidade acadêmica. As empresas por terem a
oportunidade de enviar temas

a serem pesquisados para melhoria dos seus
processos e os alunos por terem a oportunidade de pesquisar temas atuais e de
relevância.


1.3.

Metodologia


Foi feito o levantamento de trabalhos correlatos e das tecnologias apropriadas
para o desenvolvimento.


As f
ases de especificação de requisitos e análise foram desenvolvidas
conforme [Falbo 1] e a fase de projeto, conforme [Falbo 2] e [Falbo 3].


Na camada de apresentação foi utilizado JSP e as entidades são classes
Java. Na camada de persistência, foi utilizado

o banco de dados
orientado a objeto
db4o
.


A seguinte metodologia foi utilizada no desenvolvimento desse trabalho:



Identificação dos contornos do problema e dos objetivos do sistema;



Análise e assimilação de bibliografia sobre padrões de projeto para
web

e
tecnologia JSP;



Implementação e execução de testes no sistema.



8

1.4.


Estrutura do trabalho

Este trabalho é organizado em 7 capítulos, estruturados da seguinte forma.

O presente capítulo apresenta uma introdução sobre o projeto desenvolvido,
descrevendo cont
exto, motivação, objetivo, bem como a metodologia utilizada no
mesmo.


O Capítulo 2


Tecnologias e Trabalhos Correlatos
-

mostra conceitos e a
descrição de tecnologias utilizadas no desenvolvimento do projeto, além disso
,

são
apresentados sistemas semelha
ntes ao proposto por esse trabalho.

O Capítulo 3


Especificação de Requisitos
-

traz a especificação de
requisitos do sistema desenvolvida utilizando a técnica de modelagem de casos de
uso.

O Capítulo 4


Análise



apresenta o modelo de análise produzido

neste
trabalho. Desenvolvido focando na estrutura de informação, no comportamento do
sistema.

O Capítulo 5


Projeto



incorpora a tecnologia a todos os requisitos
essenciais do usuário, projetando o que
foi

realizado

na implementação.

O Capítulo 6


Imp
lementação e Telas do Sistema


apresenta aspectos
gerais da implementa
çã
o. Também
mostra as principais telas da aplicação
.

O Capítulo 7


Considerações finais


são apresentadas as conclusões sobre
o presente trabalho, as dificuldades enfrentadas e as per
spectivas sobre possíveis
trabalhos futuros.

E finalmente Referências Bibliográficas


são explicitadas todas as fontes de
conhecimento utilizadas para o desenvolvimento do projeto.







9

CAPÍTULO 2
-

TECNOLOGIAS E TRABAL
HOS CORRELATOS

Esse capítulo apresenta as tecnolo
gias utilizadas na implementação, bem
como os conceitos utilizados no decorrer das fases de desenvolvimento do sistema.
Além disso, são apresentados sistemas semelhantes ao proposto por esse trabalho,
que serviram como apoio na definição dos requisitos.


2.1.

T
ecnologias e Métodos

Nesta seção serão apresentados as principais tecnologias e métodos
utilizados para desenvolvimento do projeto.


2.1.1.

Arquitetura cliente
-
servidor

Segundo [Renaud]

“cliente/servidor é um conceito lógico, mais precisamente
um paradigma, ou mo
delo para interação entre processos de software em execução
concorrente”. Isso significa dizer que a metodologia cliente/servidor foi criada com o
objetivo de possibilitar que vários tipos de aplicações, executadas em máquinas
distintas, se comuniquem entr
e si, sem que a execução de um processo interfira no
do outro.

Baseado neste conceito, a arquitetura cliente/servidor estabeleceu um novo
paradigma de processamento de dados, diversificando o processamento entre dois
processos de software distintos (clien
te e servidor). Ao mesmo tempo a arquitetura
visa fornecer recursos que coordenem estes processos de forma que, a perda de
sincronização, não resulte em alterações ou perda de informações para o sistema.

Seu funcionamento se baseia no seguinte esquema: o
usuário do sistema,
através do processo de software cliente, envia o pedido de requisição ao processo
de software servidor, que por sua vez devolve ao cliente os resultados solicitados.
Todos os processos de software rodam sobre o controle do Sistema Opera
cional
que coordena todos os recursos do sistema computacional utilizado (Figura 2.1).



10



Figura
2
.
1
: Representação da arquitetura cliente/servidor. [Silva]


Camadas de Hardware Cli
ente
-
Servidor


O uso mais comum para arquiteturas cliente
-
servidor é explorar o poder dos
PCs para gerenciar interfaces gráficas com o usuário, mantendo a integridade dos
dados do negócio em uma máquina hospedeira central. Em sua forma mais simples,
a arqu
itetura cliente
-
servidor envolve múltiplos clientes fazendo requisições para um
único servidor, como mostra a figura
2.2.
Este modelo mostra uma arquitetura de
hardware em duas camadas (
two
-
tier
).



Figura
2
.
2
: Uma arquitetura de hardware cliente
-
servidor duas camadas. [Falbo 2]




A figura 2.3 mostra uma arquitetura cliente
-
servidor em três camadas, na qual
máquinas
-
cliente estão conectadas via uma rede local a um servidor local de
aplicação que, por sua vez
, se comunica com um servidor de dados central.


11


Figura
2
.
3
: Uma arquitetura de hardware cliente
-
servidor três camadas. [Falbo 2]


Em uma arquitetura de três camadas, a noção de cliente e servidor começa a
s
e tornar nebulosa. Um PC que hospeda uma aplicação de interface
é certamente
um cliente

e a máquina hospedeira da base de dados é certamente um servidor.
Mas o servidor local de aplicação é algumas vezes um cliente e outras um servidor,
dependendo da direç
ão de comunicação. Esta arquitetura pode ser estendida para
n
camadas (
n
-
tier
), como mostra a figura 2.4. Nestes casos, a distinção entre cliente
estrito e servidor estrito é destruída, tornando o termo um padrão conceitual.


Figura
2
.
4
: Uma arquitetura de hardware cliente
-
servidor n camadas. [Falbo 2]


12

Camadas de Software Cliente
-
Servidor

Para discutir o desenvolvimento de software em uma arquitetura multicamada
de hardware, é necessário primeiro dissecar a a
plicação de software em camadas
.

Os componentes de uma aplicação de negócio podem ser agrupados em pelo
menos três categorias principais, como mostra a figura 2.5:



Camada de Apresentação: é a camada mais externa do sistema de software.
Sua função é captura
r estímulos de eventos externos e realizar alguma edição dos
dados de entrada. É encarregada também de apresentar respostas aos eventos
para o mundo exterior. Geralmente, é localizada em uma máquina cliente, tal como
um PC, entretanto, esta não é uma regra

rigorosa;



Camada de Lógica do Negócio: contém o código que executa e impõe a política
do negócio. Regras, regulamentos e cálculos são encontrados nesta camada. É a
camada mais móvel, podendo ser localizada em clientes remotos, no servidor central
ou em qu
alquer outro local intermediário;



Camada de Gerência de Dados: provê acesso a dados corporativos. Gerencia
requisições concorrentes de acesso às bases de dados, assim como a sincronização
de elementos de dados distribuídos. Muito desta camada estará no mes
mo local
físico que os dados.



Figura
2
.
5
: Camadas de Software. [Falbo 2]


13

2.1.2.

Orientação a Objetos

[Rumbaugh] define orientação a objetos como: "uma nova maneira de pensar
os problemas utilizando modelos organi
zados a partir de conceitos do mundo real. O
componente fundamental é o objeto que combina estrutura e comportamento em
uma única entidade". Dizer que um software é orientado a objetos significa que ele é
organizado como uma coleção de objetos separados, q
ue incorporam tanto a
estrutura como o comportamento dos dados. A Orientação a Objetos (OO) trouxe
vários novos conceitos ao desenvolvimento de software, como: Abstração,
Encapsulamento, Objeto, Classe, Atributo, Operação, Método, Mensagem, Evento,
Interfa
ce, Generalização, Herança e Polimorfismo.


Por que utilizar orientação a objetos?

Quando bem empregada, a Orientação a Objetos traz diversas vantagens:
reutilização, confiabilidade, modelo de sistema mais realístico, facilidade de
interoperabilidade e de
manutenção, aumento da qualidade, maior produtividade e
unificação do paradigma (da análise a implementação) [Martin, Jacobson, Fuzion].


Muitos foram os métodos desenvolvidos para a aplicação da orientação a
objetos no processo de análise e projeto. Metod
ologias como a de Booch, OMT,
OOSE, Shlaer/Mellor, Coad/Yourdon, Martin/Odell, Wirfs/Brock e Embley/Kurtz são
alguns exemplos [Jacobson, Furlan]. Com o decorrer do tempo, as metodologias de
Booch, a OMT (de Rambaugh) e a OOSE (de Jacobson) evoluíram, seus
autores se
uniram e lançaram uma linguagem de notação unificada, chamada
Unified Modeling
Language

(UML) (discutida em detalhes no próximo tópico) e também lançaram uma
metodologia orientada a objetos chamada
Rational Unified Process

(RUP) que
abrange todo

o processo de desenvolvimento de um sistema.

A Orientação a Objetos é um paradigma que pode ser aplicado ao longo de
todo o processo de construção do software. Dessa forma, tem
-
se as metodologias
acima descritas, que atuam no processo de análise e projeto

e, no ciclo de
implementação, existem as tecnologias de
back
-
end

(banco de dados) e as de
front
-
end

(linguagens e ferramentas de programação) [Furlan]. Os Bancos de Dados têm
evoluído no sentido de suportar a tecnologia OO. Inicialmente foram lançados
ban
cos objeto
-
relacional que suportam apenas alguns dos conceitos OO, mantendo

14

a estrutura do modelo relacional. Em seguida, surgiram os bancos de dados
realmente OO, tais como o
Jasmine

da
CA Computer Inc
, que suportam,
efetivamente, os conceitos OO. Entreta
nto, devido a questões como a falta de
habilidade em OO pelas empresas, dentre outras, esses bancos de dados tiveram
pouca penetração no mercado [Belloquim]. Com isso, continuou o domínio no
mercado dos bancos de dados relacionais e objeto
-
relacionais, for
çando de certa
forma os desenvolvedores a "quebrar" o paradigma da OO no momento de
implementar o banco de dados, tendo
-
se que utilizar técnicas de mapeamento
objeto
-
relacional para acomodar os dois modelos no sistema. As primeiras
linguagens de programaçã
o orientadas a objetos apareceram em meados de 1966,
como o Simula e, em 1972, o
Smalltalk
. Linguagens com maior penetração no
mercado, tais com Pascal e C, evoluíram e criaram versões OO, como o C++, por
exemplo. Outras linguagens, já criadas dentro do co
nceito da OO, como o Java, por
exemplo, possibilitaram uma maior difusão do uso dessa tecnologia pelo mercado.
Viu
-
se também o rápido crescimento de ambientes de desenvolvimento integrados,
que permitem a construção visual dos sistemas de forma rápida (RAD

-

Rapid
Application Development
) e com uso de componentes previamente montados. São
exemplos dessas linguagens/ferramentas o
Visual Basic

e o
Delphi
.


2.1.3.

UML (Unified Modeling Language)

No tópico anterior, foi descrita a criação de várias metodologias Orient
adas a
Objeto (OO). Entretanto, era necessário um caminho comum. Então, James
Rumbaugh e Grady Booch combinaram suas metodologias: OMT e Booch,
respectivamente, através da
Rational Corporation
, nos Estados Unidos, e criaram
um método comum: o
Unified Metho
d

(UM), lançado em 1995. Em seguida, deu
-
se a
adesão de Ivar Jacobson, outro grande metodologista, contribuindo com as idéias de
sua metodologia OOSE. Esses três personagens lançaram, então, a
Unified
Modeling Language
(UML) versão 0.9 em 1996. A UML versã
o 1.1 foi submetida ao
Object Management Group

(OMG) e aprovada como padrão mundial de linguagem
de notação de projetos OO.

O objetivo da UML é prover uma linguagem padrão que permita modelar um
sistema, bem como visa dotar o mercado mundial de orientação

a objetos de uma
linguagem única de modelagem, que permita a troca de modelos de forma natural

15

entre os construtores de softwares [Fuzion]. Com a UML é possível [Mattiazzi]:
descrever eficazmente requisitos de software, caracterizar a arquitetura (lógica
e
física) de um sistema, focalizar na arquitetura em vez da implementação e direcionar
programadores, aumentando a produtividade e diminuindo os riscos.

Segundo [Furlan], "a UML é uma linguagem de modelagem, não uma
metodologia". Assim, na construção de um

software, a UML deve ser usada em
conjunto com uma metodologia de Engenharia de Software Orientada a Objetos, tais
como a metodologia Vincit e a RUP (
Rational Unified Process
). Não se recomenda a
utilização do paradigma clássico (
waterfall
) visto que a UM
L adapta
-
se melhor com
paradigmas incrementais e similares. Por outro lado, a UML não se restringe a
diagramas, ela apresenta uma série de conceitos e recursos que facilitam a
identificação de objetos e classes, associando
-
os aos requisitos do sistema, bem

como oferece formas de planejar e gerenciar projetos baseados nesses requisitos
[Mattiazzi].

A UML apresenta os seguintes diagramas que, em conjunto, modelam todo o
sistema [Mattiazzi, Furlan, Fuzion]:



Diagrama de Classe: utilizado para representar as div
ersas classes de objetos
do sistema, seus atributos e operações, bem como a associação entre cada uma
delas (herança, generalização, composição, agregação, etc.);



Diagrama de Caso de Uso: usado para demonstrar o relacionamento entre
atores e casos de uso;



Diagramas de Seqüência: tipo de diagrama de interação que apresenta a
interação de seqüência de tempo dos objetos que participam na interação;



Diagrama de Colaboração: tipo de diagrama de interação que mostra uma
interação dinâmica de um caso de uso e seus

objetos relacionados;



Diagrama de Estado: utilizado para demonstrar as seqüências de estados que
um objeto assume em sua vida, em função do seu uso no sistema;



Diagrama de Atividade: tipo de diagrama de estado no qual a maioria dos
estados são ações. Desc
reve o fluxo interno de uma operação;



Diagrama de Componente: usado para representar os diversos componentes
dos sistemas e suas dependências;


16



Diagrama de Implantação: utilizado para demonstrar elementos de configuração
de processamento run
-
time.


O uso de

um tipo ou outro de diagrama depende, muitas vezes, do grau de
detalhamento necessário para o desenvolvimento do sistema. Os diagramas de
classe, de casos de uso e de seqüência são os mais utilizados.


2.1.4.


Servlets e JSP

Se um dia a Internet era composta, pr
incipalmente, de páginas estáticas com
conteúdo institucional, hoje ela oferece uma infinidade de aplicações com conteúdo
dinâmico e personalizado.

Diversas tecnologias possibilitaram essa revolução: seja para construir um
simples site com conteúdo dinâmi
co ou para construir um complexo sistema de
Business
-
To
-
Business
, é necessária a utilização de ferramentas que possibilitem
consultas a bancos de dados, integração com sistemas corporativos, entre outras
inúmeras funcionalidades.

Dentre as diversas tecnolo
gias disponíveis atualmente para o
desenvolvimento dessa classe de aplicações, destaca
-
se a de Servlets e a de
páginas JSP (
Java Server Pages
). A utilização de Servlets e de páginas JSP oferece
diversas vantagens em relação ao uso de outras tecnologias (co
mo PHP, ASP e
CGI). As principais vantagens são herdadas da própria linguagem Java:



Portabilidade: a aplicação desenvolvida pode ser implantada em diversas
plataformas, como por exemplo, Windows, Unix e Macintosh, sem que seja
necessário modificar ou mesmo

reconstruir a aplicação;



Facilidade de programação: a programação é orientada a objetos, simplificando
o desenvolvimento de sistemas complexos. Além disso, a linguagem oferece
algumas facilidades, como por exemplo, o gerenciamento automático de memória
(e
struturas alocadas são automaticamente liberadas, sem que o desenvolvedor
precise se preocupar em gerenciar esse processo);


17



Flexibilidade: o Java já se encontra bastante difundido, contando com uma
enorme comunidade de desenvolvedores, ampla documentação e

diversas
bibliotecas e códigos prontos, dos quais o desenvolvedor pode usufruir;


Além dessas vantagens,
a arquitetura de Servlets e páginas JSP possibilitam

alguns benefícios adicionais [Temple]:



Escalabilidade: na maior parte dos servidores de aplicaçõe
s modernos, é
possível distribuir a carga de processamento de aplicações desenvolvidas em
diversos servidores, sendo que servidores podem ser adicionados ou removidos de
maneira a acompanhar o aumento ou decréscimo dessa carga de processamento;



Eficiência:

os Servlets carregados por um servidor persistem em sua memória
até que ele seja finalizado. Assim, ao contrário de outras tecnologias, não são
iniciados novos processos para atender cada requisição recebida; por outro lado,
uma mesma estrutura alocada em

memória pode ser utilizada no atendimento das
diversas requisições que chegam a esse mesmo Servlet;



Recompilação automática: páginas JSP modificadas podem ser
automaticamente recompiladas, de maneira que passem a incorporar imediatamente
as alterações sem

que seja necessário interromper o funcionamento da aplicação
como um todo;


O que são Servlets?

Servlets são classes Java, desenvolvidas de acordo com uma estrutura bem
definida, e que, quando instaladas ju
nto a um Servidor que implemente

um Servlet
Conta
iner (um servidor que permita a execução de Servlets, muitas vezes chamado
de Servidor de Aplicações Java), podem tratar requisições recebidas de clientes.

Ao receber uma requisição, um Servlet pode capturar parâmetros desta
requisição, efetuar qualquer pr
ocessamento inerente a uma classe Java, e devolver
uma página HTML, por exemplo.




18

Exemplo de Servlet

import java.io.*;

import javax.servlet.http.*;

/ / Servlet simples que retorna página HTML com o endereço IP

/ / do cliente que está fazendo o acesso

publ
ic class RemoteIPServlet extends HttpServlet {

public void doGet( HttpServletRequest p_request,


HttpServletResponse p_response)

throws IOException {

PrintWriter l_pw = p_response.getWriter ();

l_pw.println(“<HTML><BODY>”);

l_pw.println(“O

seu endereço IP é
\
”” +

p_reques t.getRemoteAddr () + “
\
””);

l_pw.println(“</BODY>< /HTML>”);

l_pw.flush ();

}

}


O que são páginas JSP?

As páginas JSP, ou Java Server Pages, foram criadas para contornar
algumas das limitações no desenvolvimento com Servl
ets: se em um Servlet a
formatação da página HTML resultante do processamento de uma requisição se
mistura com a lógica da aplicação em si, dificultando a alteração dessa formatação,
em uma página JSP essa formatação se encontra separada da programação,
po
dendo ser modificada sem afetar o restante da aplicação.

Assim, um JSP consiste de uma página HTML com alguns elementos
especiais, que conferem o caráter dinâmico da página. Esses elementos podem
tanto realizar um processamento por si, como podem recuperar

o resultado do
processamento realizado em um Servlet, por exemplo, e apresentar esse conteúdo
dinâmico junto à página JSP.

Existe também um recurso adicional bastante interessante na utilização de
páginas JSP: a recompilação automática, que permite que al
terações feitas no
código da página sejam automaticamente visíveis em sua apresentação. Assim, não

19

é necessário interromper o funcionamento da aplicação para incorporar uma
modificação de
layout
, por exemplo.

Exemplo de página JSP

<!

Página JSP Simples que

imprime endereço IP da máquina que

está fazendo o acesso a esta página

>

<HTML>

<BODY>

O seu endereço IP é “<%= request.getRemoteAddr () %>”

</BODY>

</HTML>


Servlet Container


O container é o componente responsável pelo controle das servlets: ele a
inst
ancia e utiliza à medida que se faz necessário. Os três tipos mais comuns de
instalação de Servlet
Container

e
Webservers

são mostrados na figura 2.6.


Figura
2
.
6
: Tipos mais comuns de Servlet Containers. [T
emple]



No primeiro, todas as requisições vão direto para o
webserver
, que também é
o container. No tipo dois, o
webserver

usa o container como um
plugin

e envia as
requisições pertinentes ao mesmo, enquanto, no tipo três, as requisições são feitas
direta
mente ao
webserver

ou ao container.


20

Tomcat


O Tomcat é um servidor de aplicações Java para
web
. É software livre e de
código aberto surgido dentro do conceituado projeto Apache Jakarta e oficialmente
endossado pela Sun como a Implementação de Referência (R
I) para as tecnologias
Java Servlet e Java

Server Pages (JSP). Atualmente, o Tomcat tem seu próprio
projeto dentro da Apache Software Foundation. O Tomcat é robusto e eficiente o
suficiente para ser utilizado mesmo em um ambiente de produção[Wikipedia].


T
ecnicamente, o Tomcat é um Container
Web
, parte da plataforma
corporativa Java Enterprise Edition (J2EE ou Java EE) que abrange as tecnologias
Servlet e JSP, incluindo tecnologias de apoio relacionadas como Realms e
segurança,
JNDI Resources e JDBC DataSou
rces
. O Tomcat tem a capacidade de
atuar também como servidor
W
eb/HTTP, ou pode funcionar integrado a um servidor
web

dedicado como o Apache httpd ou o Microsoft IIS.


2.1.5.

NetBeans IDE


A
NetBeans

IDE
é um ambiente de desenvolvimento
-

uma ferramenta p
a
ra
programadores, que permite a você escrever, compilar,
debugar

e instalar
programas. A IDE é completamente escrita em Java, m
as pode suportar qualquer
lingua
gem de programação. Existe também um gra
nde número de módulos para
estender

a IDE NetBeans. A NetBeans IDE é um produto livre, sem restrições de
como ele pode ser usado.


2.1.6.

JavaScript


JavaScript é uma poderosa linguagem de criação de scripts baseada em
objetos; os programas em JavaScript podem se
r incorporados diretamente nas
páginas
Web

que usam HTML. Quando combinado com o modelo de objeto de
documento (DOM) definido por um navegador
Web
, JavaScript permite criar
conteúdo em Dynamic HTML (DHTML) e aplicativos interativos do lado cliente da
Web
.
A sintaxe de JavaScript baseia
-
se naquela de linguagens de programação
muito utilizadas, como C, C++ e Java, o que a torna familiar e fácil para
programadores experientes. Ao mesmo tempo, JavaScript é uma linguagem de

21

criação de scripts interpretada, forne
cendo um ambiente flexível de programação, de
fácil aprendizado para novos programadores.


2.1.7.

Db4o


Banco de Dados Orientado a Objetos

Atualmente percebe
-
se uma procura crescente por ferramentas que facilitem
a integração entre o mundo orientado a objetos (a

linguagem e o
framework
) e o
mundo relacional (o banco de dados).

F
erramentas de mapeamento objeto
relacional nada mais são do que um "tradutor" entre duas línguas totalmente
diferentes.

Em todas as traduções você acaba perdendo as sutilezas de uma língua

ou
tendo que usar muito mais palavras para expressar um conceito que é relativamente
simples na língua de origem. No mapeamento O/R não é diferente
,

você acaba
perdendo uma série de recursos da programação OO, ou tendo que escrever muito
mais código para
simular no banco de dados algo simples na linguagem (como por
exemplo, uma propriedade do tipo
array

ou o gerenciamento de uma herança).

Podemos então

acredit
ar

que estaremos em um mundo perfeito quando todos
os banco
s

de dados permitirem que você simplesm
ente pegue seu objeto do jeito
que ele está e jogue
-
o no banco de dados

(
podendo ser

chama
do

de banco de
objetos) sem se preocupar com camadas e mais camadas de código para "traduzir"
um objeto em

query

.

Já existem várias tentativas de se fazer isso, inc
luindo algumas muito
avançadas como o

Prevayler (bambooprevalence

e

xprevail

nas encarnações .Net).
No entanto, a falta de confiabilidade nos equipamentos e sistema operacional
,

aliadas
a

certa dose de preconceito
,

faz com que essa solução ainda seja rotul
ada
como "algo para o futuro".


Figura
2
.
7
: Representação de um mapeamento O/R e um b
anco OO
. [Db4o]



22

Um banco realmente OO deve permitir que você faça suas consultas de forma
orientada a objetos, como se estivesse pesquisando em uma
Array
,
List

ou qualquer
outro
container

de objetos.

É aqui que se encaixa o db4o
.


O
db4objects
:

O
db4objec
ts(db4o)

surgiu


alguns anos
,

inicialmente apenas para
Java
.
Com a grande semelhança de código entre o
.Net e o Java
, foi um pulo para que
fosse criada uma versão
.Net
. Hoje, as versões
.Net

e
Java

caminham lado a lado,
tendo ambas os mesmos recursos.

N
ã
o
é
precis
o

instalar nem configurar um servidor de banco de dados
,

para

aplicação cliente/servidor
,

o

próprio db4o provê recursos para que isso seja feito,
mas sempre de uma forma simples, sem a necessidade de ser um PHD em
configuração de banco de dados.

Quando
se
fal
a
em db4o, algumas perguntas são inevitáveis:

a)

Não
se tem

problemas de
desempenho
?

Não. Alguns testes mostram inclusive que o db4o é muito mais rápido que
soluções que envolvam o uso de
H
ibernate

por exemplo. Veja
benchmarks
:



Figura
2
.
8
: Benchmarks do db4o e algumas soluções de mapeamento O/R
.[Db4o]

b)

Ele
custa

caro?


23

Não. A licença do db4o é
open
-
sour
ce

dual como a do
MySql
, ou seja, se
você está desenvolvendo para uso dentro de sua empresa, criando seu
website

ou
desenvolvendo um programa GPL
(
General Public License
) ou seja
,

desenvolvendo
software livre,

ele é gratuito para você.

Mas mesmo que você pr
ecise distribuir sua
aplicação, o custo da licença
runtime

é muito baixo.


2.1.8.

Sistema
WEB
Gerenciador de Perfis (S
W
GP)


Sistema
w
eb

criado
por

[
Thiago
, 2006]

como projeto de graduação. Esse

sistema
gerencia e auxilia o desenvolvimento de novos sistemas comput
acionais
que tenham a necessidade de utilizar métodos RI

(Recuperação de Informação)
.


O S
W
GP disponibiliza
alé
m da interface
w
eb

de gerência, um banco de dados
comum para o armazenamento de todas as necessidades inerentes aos sistemas
computacionais em de
senvolvimento, sendo assim todos os objetos com perfis
armazenados nesse banco, criando dessa forma um: “banco de perfis
compartilhado”, que poderá ser utilizado por todas as novas aplicações.


2.2.

Sistemas Correlatos

Nesta seção são apresentados sistemas seme
lhantes ao proposto por esse
trabalho, que já estão em utilização em outras instituições de ensino do país. Um
deles é a página do Departamento de Engenharia de Sistemas e Computação da
UERJ, o outro, a página do Projeto Poli
-
Cidadã da Escola Politécnica d
a USP
(ubirajara.lac.usp.br/policidada).


2.2.1.

P
ágina do Departamento de Engenharia de Sistemas e Computação da
UERJ

(
www.desc.eng.uerj.br
)
:

Nessa página há

uma seção, mostrada na figura 2.
9
, que apresenta uma lista
de professores, e para cada um destes professores, uma relação de temas para
Projeto de Graduação que eles estariam interessados em orientar. Qualquer pessoa
tem acesso a esta lista, e o aluno que se interessar por algum tema deve entrar em
contato com o p
rofessor informando o interesse. O sistema não realiza a seleção
dos alunos.


24



Figura
2
.
9
: Página do Departamento de Engenharia de Sistemas e Computação da UERJ




2.2.2.

Projeto Poli
-
Cidadã
:

Esse projeto
tem como
objetivo estabelecer mecanismos para incentivar a
realização de Projetos de Conclusão da Graduação que atendam necessidades
identificadas junto a organismos representativos da sociedade. Ou seja, deseja
-
se
propor aos alunos de graduação e professores orien
tadores alternativas de temas
obtidos a partir de manifestação de órgãos representativos da sociedade, e que
sejam compatíveis com o escopo de um Trabalho de Formatura.

A figura 2.
10

mostra a página inicial do sistema. Visitantes podem obter
informações so
bre o Projeto Poli
-
Cidadã e cadastrar temas. Alunos e professores
têm acesso à lista de temas cadastrados e à lista de projetos já concluídos.



25


Figura
2
.
10
: Página do Projeto Poli
-
Cidadã da Escola Politécni
ca da USP


O cadastro de temas é feito como demonstrado nas figuras 2.
11

e 2.1
2
.
Inicialmente o visitante cadastra informações relacionadas ao Organismo a que
pertence, e em seguida dá uma descrição completa do tema proposto, para que o
tema possa ser aval
iado pela Comissão Gestora do Poli
-
Cidadã, que decidirá se
será gerado um projeto para os alunos das engenharias.




26


Figura
2
.
11
: Projeto Poli
-
Cidadã
-

Cadastro de Temas (Dados do Organismo)



27


Figura
2
.
12
: Projeto Poli
-
Cidadã
-

Cadastro de Temas (Descrição do Tema)













28

CAPÍTULO 3
-

ESPECIFICAÇÃO DE REQ
UISITOS

A Especificação de Requisitos foi desenvolvida usando a técnica de
modelagem de casos de uso e, portanto, apr
esenta os diagramas de casos de uso
gerados, bem como as descrições dos atores e dos casos de usos identificados
nesses diagramas.


3.1.

Descrição do Mini
-
Mundo

O “Sistema virtual para publica
r

temas
de

projetos e sele
cionar

interessados
em desenvolvê
-
los” visa

facilitar e agilizar o contato entre professores orientadores e
alunos dando aos professores a possibilidade de propor temas para projetos que
gostariam de orientar e aos alunos várias opções de temas aos quais estão
capacitados a desenvolver. O sistema p
ermitirá ainda que representantes de
empresas ou organizações cadastrem propostas para temas, que por sua vez serão
direcionadas automaticamente para os professores que possuem um perfil
adequado
ao

assunto abordado na proposta, de modo a
torná
-
la

um tema
de
projeto, o que beneficiará empresas e alunos
,

a
s empresas porque terão a
oportunidade de enviar temas a serem pesquisados para melhoria dos seus
processos e os alunos por terem a oportunidade de pesquisar temas atuais e de
relevância.

O Sistema terá trê
s atores: Professor, Aluno e
Organização
, cada um terá
acesso a funcionalidades diferentes do sistema.

Após se cadastrar
,

o professor deverá efetuar
login

no sistema e então estará
apto a cadastrar temas, indicando entre outras coisas, su
a

descrição
, data

limite de
confirmação por parte dos alunos selecionados

e o número de
desenvolvedores
.

O aluno
após

se
cadastrar e efetuar
login

no sistema, poderá realizar uma
busca

entre os temas que atendem ao seu perfil

por
Título, por
S
ituação (seleção em
andamento
ou encerrada) ou por Professor responsável
.

Se o aluno tiver alguma dúvida ou sugestão, relacionada ao tema poderá
entrar na área de exibição do tema e fazer uma pergunta, que poderá ser
respondida, posteriormente, pelo professor que cadastrou o tema

ou qu
alquer

29

outro que esteja capacitado para isso
. Ao encontrar um tema de seu interesse o
aluno poderá
confirmar o seu interesse em desenvolvê
-
lo
.

Pessoa ou empresa de fora do ambiente acadêmico, chamada aqui de
Organização

também deverá se cadastrar para pode
r
indicar necessidades de sua
empresa, que depois de avaliadas por algum professor com formação relacionada
ao assunto poderão ser transformadas em novos temas para desenvolvimento.

Imediatamente após o cadastramento de um tema,

aluno
,

professor

e até
mesm
o organização em caso de temas criados a partir de

sua

proposta

terão acesso
à lista de
alunos

habilitados a desenvolver o tema.
Os candidatos serão
classificados de acordo com a adequação de seu perfil ao perfil do tema, ou
seja, os alunos que mais possuí
rem as características desejadas para o
desenvolvimento do tema terão maior prioridade.



3.2.

Casos de Uso

Os casos de uso descrevem o sistema a partir de uma visão externa, ou seja,
compreensível tanto por desenvolvedores, analistas, projetistas e testadores
quanto
pelos usuários do sistema. Como o próprio nome diz, caso de uso é a forma de o
usuário usar o sistema. Os usuários interagem com o sistema através dos seus
casos de uso.

Nenhum sistema computacional existe isoladamente. Sempre se espera que
o mesmo

interaja ou com um usuário ou com outro sistema, que são considerados
atores. Em suma, um caso de uso é uma interação típica entre um ator e o sistema.
Os casos de uso além de servirem para o desenvolvimento do sistema também são
úteis para a realização d
os testes.

Um diagrama de caso de uso especifica as funcionalidades que um sistema
tem a oferecer a seus usuários, segundo cada perspectiva individual. Um diagrama
de caso de uso é composto por um ator e seus casos de uso. A associação entre um
ator e o c
aso de uso significa que ambos podem interagir, mais precisamente enviar
mensagens, um para o outro.

A figura 3.1 apresenta o diagrama de casos de uso do sistema, as subseções
seguintes apresentam uma descrição detalhada de cada um deles.


30



Figura
3
.
1
: Diagrama de Casos de Uso para Professor, Aluno e
Organização
.


3.2.1.

Caso de Uso Cadastrar
-
se

Este caso de uso é responsável pelo cadastro de
professores, alunos e
organizações

(Empresa
s

ou Instituiç
ões
), bem como c
onsulta e alteração dos dados.

Curso Normal:

Cadastro:



Professor:
O
usuário

informa seus dados incluindo: nome,
e
-
mail
,
senha para
autenticação no sistema, departamento, telefone, sexo
,

data de nascimento

e um
breve resumo de sua Formação e Área de Intere
sse (esse texto é utilizado pelo
sistema para extração do perfil do professor)
. O sistema verifica se já não há
nenhum
professor

cadastrad
o

com esse

nome e
e
-
mail. Caso os dados sejam
válidos o novo usuário é registrado.



Aluno: O
usuário

informa seus dados

incluindo: matrícula, nome, e
-
mail, senha
para autenticação no sistema, curso, telefone sexo, data de nascimento e um breve
resumo de suas Experiências e Conhecimentos (esse texto é utilizado pelo sistema
para
extração do perfil do aluno
). O sistema verif
ica se já não há nenhum

aluno
cadastrado com a

mesma matrícula, nome e e
-
mail
. Caso os dados sejam válidos o
novo usuário é registrado.


31



Organização
: O
usuário

informa seus dados incluindo: nome, documento, tipo
(publica/privada), nome da pessoa de contato
ou responsável, endereço, bairro,
cidade, UF, CEP, telefone para contato, e
-
mail, URL, senha para autenticação no
sistema e uma breve descrição sobre a entidade. O sistema verifica se já não há
nenhuma empresa cadastrada com
o mesmo

documento
, e
-
mail ou UR
L. Caso os
dados sejam válidos o novo usuário é registrado.

Excluir Cadastro:

Após autenticar
-
se no sistema o usuário pode excluir seu cadastro. O sistema
verifica se o usuário não possui nenhum vinculo com algum tema ou proposta e o
exclui.

A
lterar Dados
:

Após autenticar
-
se no sistema o
usuário

pode alterar seu cadastro, inserindo
novos dados. Os novos dados são validados e a alteração registrada.

Consultar Dados:

A
pós autenticar
-
se no sistema o usuário

pode consultar seus dados inseridos
no cadastro.

Cu
rsos Alternativos:

Cadastro:

Se o
usuário

digitar dados inválidos uma mensagem de erro é exibida,
solicitando correção da informação inválida.

Excluir Cadastro:

Se o
usuário

possui

vinculo com temas ou

propostas de temas cadastradas
uma mensagem de erro é

exibida, indicando a necessidade de excluir suas
propostas e tentar novamente.

Alterar Dados:

Se o
usuário

digitar dados inválidos uma mensagem de erro é exibida,
solicitando correção da informação inválida.


32

3.2.2.

Caso de Uso Autenticar
-
se

Caso de uso responsá
vel por autenticar o usuário no sistema. Aluno,
Professor ou
Organização

deverá executar a ação para ter acesso às outras
funções.

Curso Normal:

O
usuário

deseja acessar o sistema, informa seu
login

e senha e seleciona a
opção acessar o sistema.

O sistema
verifica se o
login

informado está cadastrado no sistema e se a
senha está correta. O sistema verifica o tipo de usuário e as funcionalidades do
sistema que

ele

terá acesso.

Cursos Alternativos:

Se o
usuário

informar
login

ou senha inválidos
uma mensagem d
e erro é
exibida, solicitando correção da informação inválida.


3.2.3.

Caso de Uso Cadastrar Tema

Este caso de uso é responsável pelo cadastro de temas, bem como consulta
ou alteração de dados relativos ao tema e exclusão do tema.


Curso Normal:

Cadastro:

Após a
utenticar
-
se no sistema, o professor poderá cadastrar um tema. Ele
informará o título do tema e sua descrição,
á
rea de conhecimento, o número de
candidatos que serão selecionados e a data de finalização
para confirmação dos
alunos selecionados
. Os dados sã
o validados e o novo tema inserido na base de
dados.
Imediatamente após o cadastramento do tema

o sistema
já permite verificar
os alunos selecionados para desenvolver o projeto do tema
, a partir do casamento
dos perfis dos alunos e do tema.




33

Alterar Dados
:

Após autenticar
-
se o professor poderá escolher entre os temas que cadastrou
aquele que deseja alterar. Os novos dados devem ser inseridos, eles serão
validados e a alteração será registrada.

É importante dizer que a ordem de seleção dos candidatos ao te
ma é
calculada dinamicamente, de modo que alunos que antes se encontravam
classificados para o tema, após a alteração podem tornar
-
se inadequados por não
satisfazerem o novo perfil.

Excluir Cadastro:

Após autenticar
-
se o professor poderá excluir algum tema

que cadastrou. Se
a data de finalização do processo de seleção já expirou, os alunos que tiverem sido
selecionados a desenvolver um projeto desse tema deverão ser contatados.

Consultar Dados:

Após autenticar
-
se o professor poderá escolher entre os temas
que cadastrou
aquele que deseja consultar, será informado ainda do número de candidatos ao
tema. Se a data de
confirmação dos alunos
já expirou, a lista dos alunos
selecionados também será exibida.

Cursos Alternativos:

Cadastro:

No caso de dados inválidos:

uma mensagem de erro deverá ser exibida,
solicitando correção da informação inválida.

Alterar Dados:

No caso de dados inválidos: uma mensagem de erro deverá ser exibida,
solicitando correção da informação inválida.


3.2.4.

Caso de Uso Consultar Temas

Este caso

de uso é responsável pela consulta a temas oferecida aos alunos e
professores.



34

Curso Normal:



Aluno: O aluno
durante a

consulta
, que já é realizada automaticamente aos
temas que possuem o seu perfil, poderá filtrar o resultado da seleção por

T
ítulo,
Situa
ção e P
rofessor

e digitará o termo a ser pesquisado
.
A partir da

lista de temas

exibida,

o

aluno poderá então escolher aquele que deseja
visualizar detalhes
.



Professor: O professor
poderá filtrar
a
consulta por Título
,
Situação
,

Área
, se é
para exibir apen
as os seus temas, e digitará o termo a ser pesquisado.
A partir da
lista de temas exibida, o professor poderá então escolher aquele que deseja
visualizar detalhes.



Organização
:
A partir da Verificação da Situação das Propostas a Organização
poderá
visualiz
ar os dados dos temas criados, que estarão acompanhando os dados
da própria proposta em forma de uma lista. Para visualizar detalhes de um tema o
usuário poderá escolher aquele que desejar.

Cursos Alternativos:


Não há.


3.2.5.

Caso de Uso Fazer Pergunta



Aluno: S
e o aluno tiver alguma dúvida ou sugestão relacionada ao tema poderá
entrar na área de exibição do tema e fazer uma pergunta ao professor que cadastrou
o tema.



Organismo: Se o organismo tiver alguma dúvida ou sugestão relacionada ao
tema gerado por uma de
suas propostas poderá entrar na área de exibição do tema
e fazer uma pergunta ao professor que cadastrou o tema.



Professor: Se o professor também estiver interessado em fazer alguma
pergunta relacionada ao projeto essa funcionalidade estará disponível, des
sa forma
possibilitando criar uma
espécie de
lista de discussão.

Curso Normal:

Na tela de exibição do tema, o
usuário

digitará sua pergunta ou sugestão e
confirmará sua inclusão.



35

Cursos Alternativos:


Caso o número de caracteres da pergunta exceda o máxim
o permitido, uma
mensagem de erro deve ser exibida, solicitando a correção da informação.


3.2.6.

Caso de Uso Responder Pergunta

Ao entrar na área de exibição de um tema, se o
usuário

(Professor, Aluno ou
Organização)
verificar que há perguntas
que ele sabe respo
nder, poderá selecionar
responder tal pergunta

e
digitar a resposta
.

Curso Normal:

O
usuário

digitará a resposta e confirmará sua inclusão.

Cursos Alternativos:


Caso o número de caracteres da resposta exceda o máximo permitido, uma
mensagem de erro deve s
er exibida, solicitando a correção da informação.


3.2.7.

Aceitar tema

Este caso de uso é responsável pela aceitação ou não do aluno desenvolver
o tema no período
até
a data limite para confirmação.

Curso Normal:

Aceitação:

Depois de processada a classificação do
s candidatos ao tema, pelo critério de
semelhança entre perfil do aluno e do tema, o aluno pode escolher aceitar ou não
desenvolver o tema.

Rejeição:

O aluno poderá desistir de desenvolver um tema e rejeitar a oportunidade.

Cursos Alternativos:

Não há.



36

3.2.8.

C
aso de Uso Verificar Resultado

Este caso de uso é responsável pela exibição do resultado da seleção d
os

aluno
s para um determinado tema.

Curso Normal:



Aluno:
A
o

consultar temas o
aluno deverá ser informado, dos temas em
que ele se enquadrou ao perfil e des
se
s

quais já excederam a data de
confirmação
. O aluno deverá, então, escolher entre esses temas, aquele que
deseja verificar o resultado. Será exibida a lista em ordem de classificação
com o nome dos alunos selecionados para desenvolver o tema e a opção de

aceitar ou não

mesmo não estando

na lista como classificado
, mas sim como
suplente
.



Professor: Após autenticar
-
se no sistema, o professor deverá ser
informado, dos temas que ele cadastrou, quais já excederam a data de
confirmação dos alunos
. O professor d
everá, então, escolher entre esses
temas, aquele que deseja verificar o resultado. Será exibida uma lista com
matrícula,
nome

e situação. Caso o professor queira ter mais detalhes sobre
um determinado aluno, bastará selecionar esse aluno e todos os dados
serão
exibidos.



Organização: Ao verificar o andamento de suas propostas, a organização
poderá querer visualizar dados de temas criados a partir da mesma e ao
visualizar os dados do tema quer
er

ainda verificar a lista de alunos que
desenvolverá tal tema
.
Assim uma lista de alunos será exibida e esta lista
será somente para leitura, não sendo permitido visualizar mais detalhes sobre
os alunos.

Cursos Alternativos:


Não há.


3.2.9.

Caso de Uso Cadastrar Proposta

Este caso de uso é responsável pelo cadastro de Pro
postas, que poderão,
posteriormente,
criar

novos temas.


37

Curso Normal:

A Organização

informa os dados da proposta incluindo:
T
ítulo,
Á
rea de
conhecimento,
D
escrição, e
R
ecursos
D
isponibilizados para o
D
esenvolvimento da
solução

além de uma Observação se for

necessário
.

Cursos Alternativos:


No caso de dados inválidos, ou que excedam o máximo de caracteres
permitido uma mensagem de erro é exibida, solicitando correção.


3.2.10.

Caso de Uso Verificar Situação das Propostas


Este caso de uso é responsável pelo acompan
hamento da Situação das
Propostas feitas por um
a

Organização
.

Curso Normal:

A

organização

consulta as propostas feitas por el
a
, tendo como resultado a
situação em que elas se encontram
,

que pode ser de
A
ceita
, em Avaliação

ou
R
ejeitada com as devidas justi
ficativas do professor que a avaliou. Em caso de
aceitação, é possível visualizar o tema gerado para cadastramento de perguntas e
sugestões.

Cursos Alternativos:


Não há.


3.2.11.

Caso de Uso Consultar Propostas


Este caso de uso é responsável pela consulta
a

prop
ostas incluídas por
Organizações
.

Curso Normal:

O professor terá a opção de exibir a lista de propostas inseridas, ele poderá
escolher a proposta que deseja visualizar tendo acesso aos dados d
a

organi
zação
e
da proposta, podendo avaliar e
torná
-
la

tema se
for o caso.

Cursos Alternativos:


Não há.


38

3.2.12.

Caso de uso Aceitar Proposta


Depois do professor consulta as propostas, ele pode concluir que a proposta
é interessante a ponto de se tornar um tema para projeto e então cadastrar a partir
da proposta um tema.

Cur
so Normal:

Depois do professor consulta a proposta, ele pode concluir que a proposta é
interessante a ponto de se tornar um tema para projeto, e então cadastrar a partir da
proposta um tema através da opção aceitar proposta que abrirá o cadastro de tema
c
om alguns dados previamente preenchidos.

Cursos Alternativos:


Não há.



39

CAPÍTULO 4
-

ANÁLISE

A análise foi desenvolvida em duas etapas principais, a primeira focando na
estrutura de informação do sistema, a segunda em seu comportamento. Nas seções
4.1 e 4.2, são apres
entados os produtos da primeira etapa, diagrama de classe e um
dicionário de dados. Na seção 4.3, é apresentado o produto da segunda etapa:
diagramas de seqüências.


4.1.

Diagrama

de Classes

Através da especificação dos casos de usos foi possível identificar as

seguintes classes: Professor, Aluno, Organi
zação
, Tema, Desenvolvedor, Pergunta
e Proposta. Segue na figura 4.1 o Diagrama de Classes para o sistema, mostrando o
relacionamento entre as classes e seus atributos.


Figura
4
.
1
: Diagrama de Classes



40

4.2.

Dicionário

de dados

Nesta seção é apresentada uma listagem contendo um detalhamento de
todos os elementos de dados envolvidos no sistema. Nela são mostradas as classes
identificadas na fase de análise, bem como os at
ributos de cada uma das classes,
juntamente com suas descrições.


Professor:

Representa os professores cadastrados no sistema.



id_professor: número de identificação do professor;



nome: nome do professor;



email: e
-
mail do professor. O e
-
mail será utilizado
para efetuar o
login

no
sistema;



senha: senha para acesso ao sistema;



departamento: departamento ao qual o professor pertence;



telefone: telefone para contato (opcional);



sexo: sexo do professor;



dt_nascimento: data de nascimento do professor;



.formacaoAre
aInterece: Um texto contento a formação do professor(títulos de
mestrado, doutorado...) e suas áreas de interesse e desenvolvimento de trabalhos.

Esse texto é utilizado pelo sistema para extrair o perfil do professor.


Aluno:
Representa os alunos cadastra
dos no sistema.



matricula: número de matrícula do aluno na universidade;



nome: nome do
a
luno;



email: e
-
mail do aluno. O e
-
mail será utilizado para efetuar o
login

no sistema;



senha: senha para acesso ao sistema;



curso: curso a que o aluno pertence;



telefon
e: telefone para contato

(opcional)
;


41



sexo: sexo do aluno;



dt_nascimento: data de nascimento do aluno;



experienciaConhecimentos: Texto contendo uma breve descrição de atividades
já realizadas pelo aluno(estágio, iniciação cientifica...), áreas de interesse
e
conhecimentos sobre ferramentas, tecnologias ou assuntos
. Esse texto é utilizado
pelo sistema para extrair o perfil do aluno
.


Organi
zação
:
Representa
a
s
organizações

(empresas ou instituições) cadastradas
no
sistema
.



Id_organi
zacao
: número de identifica
ção d
a

organi
zação
;



nome: nome d
a

organização
;



documento: número do documento d
a

organi
zação
. No caso de Empresa CNPJ,
Pessoa Física CPF;



tipo: tipo de organi
zação

(Governo, Fundação, ONG, Associação, Empresa
Privada, Empresa Pública, Pessoa Física e Outro
s);



contato: nome da pessoa de contato;



email: e
-
mail para contato. O e
-
mail será utilizado para efetuar o
login

no
sistema;



senha: senha para acesso ao sistema.



endereço: endereço d
a

organi
zação, logradouro e número
;



complemento: complemento do endereço d
a organização;



bairro: bairro d
a

organi
zação
;



cidade: cidade d
a

organi
zação
;



uf:
estado/
unidade federativa d
a

organi
zação
;



cep: CEP da organização;



telefone: telefone para contato;



url: Endereço eletrônico da organização;


42



descrição: Uma breve descrição
da
empresa, organização ou instituição, falando
sobre sua área de atuação e atividades.


Tema
: Representa os temas que os professores podem cadastrar no sistema.



id_tema: número de identificação do tema;



id_professor: número de identificação do professor que
cadastrou o tema;



id_proposta: número de identificação da proposta que originou o tema;



titulo: título do tema;



area: área de conhecimento relacionada ao tema;



descricao: descrição do tema
. Esse texto é utilização pelo sistema para extrair o
perfil do tema
;



ndesenvolvedores: número
previsto de vagas para desenvolvedores
;



dtFimConfirmacaoAluno: data limite para o aluno classificado aceitar participar
do desenvolvimento do projeto relacionado ao tema;


Desenvolvedores:
Representa os alunos que já foram seleci
onados pelo sistema
para desenvolver o tema e já confirmaram a participação no desenvolvimento do
projeto.



id_aluno: matrícula do aluno
desenvolvedor
;



id_tema: número de identificação do tema em que o aluno se
tornou
desenvolvedor
;



situação: situação do al
uno em relação ao desenvolvimento do tema, diz se ele
está
confirmado, pendente ou cancelado
;



suplente
: indica se o aluno foi
classificado fora da quantidade de vagas
previstas para desenvolvedores e se encontra na condição de suplência
.




43

Pergunta
:
Repres
enta

as informações correspondentes as perguntas relacionadas
aos temas.



id_pergunta: número de identificação da pergunta;



id_tema: número de identificação do tema ao qual essa pergunta está
relacionada;



id_aluno
_pergunta
:
número de identificação

do aluno
que registrou a pergunta
(se foi um aluno);



id_organi
zacao_pergunta
: número de identificação d
a

organi
zacao

que registrou
a pergunta (se foi um
a

organi
zacao
);



id_professor_pergunta: número de identificação do professor que registrou a
pergunta (se foi um p
rofessor);



id_aluno_resposta: número de identificação do aluno que registrou a resposta
(se foi um aluno);



id_organizacao_resposta: número de identificação da organizacao que registrou
a resposta (se foi uma organizacao);



id_professor_resposta: número de i
dentificação do professor que registrou a
resposta (se foi um professor);



pergunta: texto da pergunta;



dt_pergunta: data em que a pergunta foi registrada;



resposta: resposta à pergunta(opcional);



dt_resposta: data em que a resposta foi
registrada
.


Propost
a:
Representa as propostas cadastradas pelos Visitantes.



id_proposta: número de identificação da proposta;



id_organi
zacao
: número de identificação d
a

organi
zacao

que registrou a
proposta;



titulo: título da proposta;



area: área de conhecimento relacionada à

proposta;


44



descricao: descrição da proposta
. Esse texto é utilizado para extrair o perfil da
proposta
;



recursos: recursos disponibilizados pel
a

organi
zação

para desenvolvimento da
proposta (opcional);



situação: informa a situação da proposta, diz se ela já

foi avaliada por algum
professor e se foi aceita/rejeitada, se está em avaliação ou se ainda não foi avaliada;



observação: Um texto contendo alguma observação sobre a proposta se for o
caso. Esse campo pode ser preenchido tanto pela própria organização ao

cadastra a
proposta tanto pelo professor ao necessitar explicar algo sobre sua avaliação da
proposta.


4.3.

Diagramas

de Sequência

Nesta seção serão apresentados os diagramas de seqüência para os casos
de uso “
Cadastrar
-
se”, “Autenticar
-
se”, “Cadastrar Tema”,

Consultar Temas”, “Fazer
Pergunta”, “Responder Pergunta”, “Verificar Resultado”, “Aceitar Tema”, “Aceitar
Proposta” e “Verificar situação das propostas” apresentando informações
relacionadas aos cenários mais importantes:



A figura 4.2 mostra o diagrama de

seqüência para o caso de uso
“Cadastrar
-
se”;



Figura
4
.
2
: Diagrama de seqüência
-

Caso de uso “Cadastrar
-
se”.



45



A figura 4.3 apresenta
o diagrama de seqüência para o caso de uso
“Autenticar
-
se”;


Figura
4
.
3
: Diagrama de seqüência
-

Caso de uso “Autenticar
-
se”.




A figura 4.4 representa o diagrama de
seqüência para o caso de uso
“Cadastrar Tema”;


Figura
4
.
4
: Diag
rama de seqüência
-

Caso de uso “Cadastrar Tema”.




46



A figura 4.5 apresenta o diagrama de seqüência para os casos de uso
“Consultar Temas”, “Fazer Pergunta”, “Verificar resultado” e “Aceitar Tema” para
o ator “Aluno”.



Figura
4
.
5
: Diagrama de seqüência


Casos de uso “Consultar Temas”, “Fazer Pergunta”,
“Verificar Resultado” e “Aceitar Tema” para o ator “Aluno”.








47



A figura 4.6 apresenta o diagrama de seqüência para os casos de uso
“Consultar Tema”, “Resp
onder Pergunta” e “Verificar resultado” para o ator
“Professor”.


Figura
4
.
6
: Diagrama de seqüência


Casos de uso “Consultar Temas”, “Responder Pergunta”
e “Verificar Resultado” para o ator “Professor”




A f
igura 4.7 apresenta o diagrama de seqüência para os casos de uso
“Consultar Proposta” e “Aceitar Proposta”.


48


Figura
4
.
7
: Diagrama de seqüência


Caso de uso “Consultar Proposta” e “Aceitar Proposta”




A figur
a 4.8 apresenta o diagrama de seqüência para o caso de uso
“Cadastrar Proposta”.


Figura
4
.
8
: Diagrama de seqüência


Caso de uso “Cadastrar Proposta”


49



A figura 4.9 apresenta o diagrama de seqüência para os c
asos de uso
“Verificar situação das propostas” e “Fazer Pergunta” para o ator “Organi
zação
”.


Figura
4
.
9
: Diagrama de seqüência


Casos de uso “Verificar a situação das propostas” e
“Fazer Pergunta” para o a
tor “Organi
zação












50

CAPÍTULO 5
-

PROJETO

Por se tratar de um sistema do tipo
Web
, deve
-
se levar em consideração uma
linguagem

de programação

que permita a construção de sistemas que operem em
ambientes
multiplataforma
,

independente de plataforma em que vai ser e
xecutado
(onde plataforma seria, por exemplo, o sistema operacional)
, já que este sistema
poderá ser operado pelo usuário utilizando um navegador
Web
. Por isso, a aplicação
será desenvolvida utilizando a linguagem orientada a objetos Java, que possui
mecan
ismos de herança simples.


Outro ponto positivo do uso de um sistema
Web

é a possibilidade de utilizar
dispositivos portáteis tais como: PDA, Notebook e celulares para o acesso ao
sistema sem a necessidade de implementar uma interface específica para eles,

pois
os dispositivos mais novos já possuem mecanismos de acesso a redes através de
conexões sem fio e podem acessar páginas
Web

com seus
softwares

nativos.


Para a persistência das informações foi optado por usar o banco de dados
orientado a objetos
. Exis
tem
algumas

opções de banco de dados