CENTRO UNIVERSITRIO VILA VELHA

CURSO DE CINCIA DA COMPUTAO

BRUNO MARTINS DA COSTA
CAYO M. DA CRUZ FONTANA
SISTEMA DE EGRESSOS
VILA VELHA
2008
BRUNO MARTINS DA COSTA
CAYO M. DA CRUZ FONTANA
SISTEMA DE EGRESSOS
Monograa desenvolvida durante a disci-
plina de Trabalho de Concluso de Curso
apresentada ao Curso de Cincia da Com-
putao do Centro Universitrio de Vila Ve-
lha, como requisito parcial para a obteno
do ttulo de Bacharel em Cincia da Com-
putao, sob orientao do prof. Cristiano
Biancardi.
Orientador: Cristiano Biancardi
VILA VELHA
2008
BRUNO MARTINS DA COSTA
CAYO M. DA CRUZ FONTANA
SISTEMA DE EGRESSOS
BANCA EXAMINADORA
Prof. Msc. Cristiano Biancardi
Centro Universitrio Vila Velha
Orientador
Prof. Msc. Otaclio Jos Pereira
Centro Universitrio Vila Velha
Prof. Msc. Susila Abreu dos San-
tos Lima
Centro Universitrio Vila Velha
Trabalho de Concluso de Curso
aprovado em 21/10/2008.
Aos meus pais ...
AGRADECIMENTOS
Agradecemos primeiramente a Deus, por estar sempre presente em nossas vidas,
assim como neste trabalho nos dando fora, coragem, concentrao e crena pelo
projeto, onde nos superamos a todo o momento. Aos nossos Pais, pelo apoio e cre-
dibilidade depositada em ns e em nosso trabalho. Ao apoio dos nossos colegas de
sala, que sempre nos ajudaram, seja pela troca de conhecimentos ou pela imensa
ajuda na hora das maiores diculdades. Ao orientador do trabalho, pela oportunidade
concedida, pelo apoio, contribuio e disponibilizao que foram essenciais para a
concluso deste trabalho. Aos professores do curso de Cincia da Computao da
instituio, pela contribuio em nosso conhecimento acadmico, imprescindvel para
o desenvolvimento deste trabalho. s nossas companheiras Brunella e Pollyanna, pela
compreenso e companheirismo desde o incio do trabalho, pois estivemos ausentes
em inmeros momentos durante o desenvolvimento deste. E nalmente, agradece-
mos a todos de uma forma geral que, diretamente ou indiretamente, contriburam para
completar nosso objetivo. Muito obrigado todos vocs!
""A estratgia a cincia do emprego do espao e do tempo. O espao, podemos
reganh-lo. O tempo no!"
autor desconhecido.
LISTA DE FIGURAS
1 Fonte X Tcnica de Levantamento . . . . . . . . . . . . . . . . . . . . . 24
2 Problemas levantados X Causas . . . . . . . . . . . . . . . . . . . . . . 25
3 Enterprise Architect 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Visual Studio 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 MySQL Server 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6 Fireworks 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7 DB-Designer 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8 Diagrama de Caso de Uso Principal . . . . . . . . . . . . . . . . . . . . 29
9 Diagrama de Caso de Uso, Administrador . . . . . . . . . . . . . . . . . 31
10 Descrio do Caso de uso: Manter Curso . . . . . . . . . . . . . . . . . 32
11 Descrio do Caso de uso: Manter Coordenador . . . . . . . . . . . . . 32
12 Descrio do Caso de uso: Manter Frum . . . . . . . . . . . . . . . . . 33
13 Diagrama de Casos de Uso, Coordenador . . . . . . . . . . . . . . . . . 34
14 Descrio do Caso de uso: Avaliar Empresa . . . . . . . . . . . . . . . 35
15 Descrio do Caso de uso: Validar Oportunidade . . . . . . . . . . . . . 35
16 Descrio do Caso de uso: Gerenciar Frum . . . . . . . . . . . . . . . 36
17 Descrio do Caso de uso: Gerar Relatrio . . . . . . . . . . . . . . . . 36
18 Diagrama de Casos de Uso, Empresa . . . . . . . . . . . . . . . . . . . 37
19 Descrio do Caso de uso: Manter Dados Empresa . . . . . . . . . . . 38
20 Descrio do Caso de uso: Manter Oportunidade . . . . . . . . . . . . . 38
21 Descrio do Caso de uso: Gerar Feedback . . . . . . . . . . . . . . . . 39
22 Diagrama de Casos de Uso, Egresso . . . . . . . . . . . . . . . . . . . 40
23 Descrio do Caso de uso: Manter Dados Egresso . . . . . . . . . . . . 41
24 Descrio do Caso de uso: Visualizar Oportunidade . . . . . . . . . . . 41
25 Descrio do Caso de uso: Interagir Frum . . . . . . . . . . . . . . . . 42
26 Diagrama de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
27 Diagrama de Pacotes do subsistema Administrador . . . . . . . . . . . 45
28 Diagrama de Pacotes do subsistema Cliente . . . . . . . . . . . . . . . 45
29 Diagrama de Classes da camada Entity, pacote Administrador . . . . . 46
30 Diagrama de Classes da camada Business, pacote Administrador . . . 47
31 Classe Genrica que efetua a conexo com o banco de dados . . . . . 48
32 Diagrama de Classes, camada Data Access, pacote Administrador . . . 49
33 Diagrama de Classes da camada Facade, pacote Administrador . . . . 50
34 Diagrama de Classes da camada UI, pacote Administrador . . . . . . . 51
35 Diagrama de Classes da camada Entity, pacote Cliente . . . . . . . . . 52
36 Diagrama de Classes da camada Business, pacote Cliente . . . . . . . 53
37 Diagrama de Classes da camada Data Access, pacote Cliente . . . . . 54
38 Diagrama de Classes da camada Facade, pacote Cliente . . . . . . . . 55
39 Diagrama de Classes da camada UI, pacote Cliente . . . . . . . . . . . 56
40 Diagrama de Estados do Objeto Oportunidade . . . . . . . . . . . . . . 57
41 Diagrama de Navegao . . . . . . . . . . . . . . . . . . . . . . . . . . 58
42 Diagrama Relacional do Banco de Dados . . . . . . . . . . . . . . . . . 59
43 Diagrama de Sequncia - Manter Curso . . . . . . . . . . . . . . . . . . 61
44 Diagrama de Sequncia - Manter Coordenador . . . . . . . . . . . . . . 62
45 Diagrama de Sequncia - Inserir Tpico, Frum, Mensagem . . . . . . 63
46 Diagrama de Sequncia - Avaliar Empresa . . . . . . . . . . . . . . . . 64
47 Diagrama de Sequncia - Validar Oportunidade . . . . . . . . . . . . . . 65
48 Diagrama de Sequncia - Gerar Relatrio . . . . . . . . . . . . . . . . . 66
49 Diagrama de Sequncia - Manter Dados Empresa . . . . . . . . . . . . 67
50 Diagrama de Sequncia - Manter Oportunidade . . . . . . . . . . . . . . 68
51 Diagrama de Sequncia - Manter Dados Egresso . . . . . . . . . . . . . 69
52 Diagrama de Sequncia - Visualizar Oportunidades . . . . . . . . . . . 70
53 Botes e Imagens do Sistema . . . . . . . . . . . . . . . . . . . . . . . 72
54 Prototipagem - Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
55 Prototipagem - Cadastro de Egressos . . . . . . . . . . . . . . . . . . . 75
56 Prototipagem - Cadastro de Empresa . . . . . . . . . . . . . . . . . . . 75
57 Prototipagem - Cadastro de coordenador . . . . . . . . . . . . . . . . . 76
58 Prototipagem - Cadastro de curso . . . . . . . . . . . . . . . . . . . . . 76
59 Prototipagem - Exibio, Alterao e Desativao de Curso . . . . . . . 77
60 Prototipagem - Exibio do menu do Coordenador . . . . . . . . . . . . 77
61 Prototipagem - Exibio de Oportunidades para Coordenador . . . . . . 78
62 Prototipagem - Exibio de Oportunidade detalhada . . . . . . . . . . . 78
63 Prototipagem - Validao de Oportunidades . . . . . . . . . . . . . . . . 79
64 Prototipagem - Exibio de Oportunidade para Empresa . . . . . . . . . 80
65 Prototipagem - Cadastro de Oportunidades . . . . . . . . . . . . . . . . 81
66 Prototipagem - Exibio de Oportunidades para Egresso . . . . . . . . 81
67 Viso Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
68 Pacotes Lgicos do Sistema . . . . . . . . . . . . . . . . . . . . . . . . 84
69 Viso Lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
LISTA DE SIGLAS E ABREVIATURAS
IES: Instituio de Nvel Superior.
UML: Unied Modeling Language.
OMG: Object Management Group.
CSS: Cascading Style Sheets.
HTML: Hyper Text Markup Language.
XML: EXtensible Markup Language.
DLL: Dynamic-link library.
WEB: World Network
POP: Post Ofce Protocol
SMTP: Simple Mail Transfer Protocol
IIS: Internet Information Service
SUMRIO
RESUMO
ABSTRACT
1 INTRODUO 16
1.1 MOTIVAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 CONCEITOS 18
2.1 ANLISE DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 LEVANTAMENTO DE REQUISITOS . . . . . . . . . . . . . . . . . . . . 18
2.3 LINGUAGEM DE MODELAGEM UNIFICADA . . . . . . . . . . . . . . . 19
2.4 CONCEITOS DE ORIENTAO A OBJETOS . . . . . . . . . . . . . . . 19
2.5 ANLISE ORIENTADA A OBJETOS . . . . . . . . . . . . . . . . . . . . 20
2.6 ATORES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 MODELO DE CASO DE USO . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 DIAGRAMA DE CLASSE . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 DIAGRAMA DE SEQUNCIA . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10 DIAGRAMA DE ESTADOS DE NAVEGAO . . . . . . . . . . . . . . . 22
2.11 DIAGRAMA DE PACOTES . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.12 MODELO RELACIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 LEVANTAMENTO DE REQUISITOS 24
3.1 ENTREVISTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 MODELAGEM DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 TECNOLOGIAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 DIAGRAMAS DE CASO DE USO . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2 LISTA DOS CASOS DE USO . . . . . . . . . . . . . . . . . . . . 30
3.5 DESCRIO DOS CASOS DE USO . . . . . . . . . . . . . . . . . . . . 31
3.5.1 CASOS DE USO DO ATOR ADMINISTRADOR . . . . . . . . . . 31
3.5.2 CASOS DE USO DO ATOR COORDENADOR . . . . . . . . . . 34
3.5.3 CASOS DE USO DO ATOR EMPRESA . . . . . . . . . . . . . . 37
3.5.4 CASOS DE USO DO ATOR EGRESSO . . . . . . . . . . . . . . 40
4 ESPECIFICAO DE PROJETO 43
4.1 DIAGRAMA DE PACOTES . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 DIVISO EM CAMADAS . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 DIAGRAMAS DE CLASSES . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 CAMADA DE ENTIDADES (ENTITY), ADMINISTRADOR . . . . 46
4.3.2 CAMADA DE NEGCIOS (BUSINESS), ADMINISTRADOR . . 47
4.3.3 CAMADA DE ACESSO A DADOS (DATA ACCESS), ADMINIS-
TRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.4 CAMADA DE FACHADA (FACADE), ADMINISTRADOR . . . . . 49
4.3.5 CAMADA DE INTERFACE COM O USURIO (UI), ADMINIS-
TRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.6 CAMADA DE ENTIDADES (ENTITY), CLIENTE . . . . . . . . . 52
4.3.7 CAMADA DE NEGCIOS (BUSINESS), CLIENTE . . . . . . . . 53
4.3.8 CAMADA DE ACESSO AOS DADOS (DATA ACCESS), CLIENTE 53
4.3.9 CAMADA DE FACHADA (FACADE), CLIENTE . . . . . . . . . . 54
4.3.10 CAMADA DE INTERFACE COM O USURIO (UI) , CLIENTE . . 55
4.4 DIAGRAMA ESTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.1 OPORTUNIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 DIAGRAMA DE NAVEGAO . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 DIAGRAMA RELACIONAL DO BANCO DE DADOS . . . . . . . . . . . 58
5 DIAGRAMAS DE SEQUNCIA 60
5.1 ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.1 MANTER CURSO . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2 MANTER COORDENADOR . . . . . . . . . . . . . . . . . . . . 62
5.1.3 MANTER FRUM (INCLUI GERENCIAR FRUM) . . . . . . . 62
5.2 COORDENADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.1 AVALIAR EMPRESA . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.2 VALIDAR OPORTUNIDADE (INCLUI NOTIFICAR EGRESSO) . 64
5.2.3 GERENCIAR FRUM . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.4 GERAR RELATRIO . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 EMPRESA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.1 MANTER DADOS EMPRESA . . . . . . . . . . . . . . . . . . . . 67
5.3.2 MANTER OPORTUNIDADE . . . . . . . . . . . . . . . . . . . . 67
5.4 EGRESSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4.1 MANTER DADOS EGRESSO . . . . . . . . . . . . . . . . . . . 68
5.4.2 VISUALIZAR OPORTUNIDADE . . . . . . . . . . . . . . . . . . 68
5.4.3 INTERAGIR FRUM . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 PADRONIZAO 71
7 PROTOTIPAGEM 73
8 DOCUMENTOS DE ARQUITETURA 82
8.1 VISO FSICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2 VISO LGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9 ESTRUTURA TECNOLGICA 86
9.1 HOSPEDAGEM DO SITE (FATORES A CONSIDERAR) . . . . . . . . . 86
10 PROJETO DE SEGURANA 88
11 CONCLUSO 89
12 REFERNCIAS BIBLIOGRFICAS 90
ANEXO A 92
RESUMO
RESUMO
Necessitando a busca por prossionais qualicados e de conhecimentos tcitos,
as empresas tm recorrido s instituies de ensino superior (IES) para contratao
de pessoas. Os contratantes passaram a fazer contatos diretamente com as coor-
denaes dos cursos com o intuito de encontrar os estudantes mais qualicados por
meio de referncias dos coordenadores. Entretanto, por conitos de horrios entre o
trabalho e a faculdade, ou mesmo por falta de experincia prossional, os contratan-
tes e os prprios coordenadores, tm preferncia por alunos formados, ou seja, os
alunos que egressaram da IES. Partindo deste conceito, este trabalho prope projetar
e implementar uma aplicao Web, com a nalidade de prover um novo conceito em
egressos acadmicos possibilitando a interao entre o mercado de trabalho, o recm
formado e a intituio. Para isso, sero utilizadas as seguintes ferramentas: plata-
forma .NET, especicamente a linguagem C-Sharp por ser uma poderosa tecnologia
de desenvolvimento de softwares tanto para a Web quanto para as demais aplicaes,
a ferramenta case Enterprise Architect 6.5 para anlise e modelagem da UML (Unied
Modeling Language), Macromedia FireWorks 8 para a edio de imagens e bitmaps
na interface do projeto e o MySQL Server 5.0 para a persistncia dos dados utilizados.
Palavras-chave: IES, UML.
ABSTRACT
ABSTRACT:
Need to search for qualied professionals and tacit knowledge, companies have
resorted to higher education institutions (HEI) to employ people. Contractors started to
make contact directly with the coordination of courses with the aim of nding the most
qualied students by means of references coordinators. However, in times of conict
between work and college, or even a lack of professional experience, contractors and
their coordinators, have formed a preference for students, ie students who graduate
s(egress) from the ISS. Under this concept, this paper proposes designing and imple-
menting a Web application, in order to provide a new concept in academic graduates
allowing the interaction between the labor market, and the newly formed institution.
This will use the following tools: platform. NET, specically the C-Sharp language as a
powerful technology for the development of software for both the Web and for the other
applications, the tool case Enterprise Architect 6.5 for analysis and modeling of UML
(Unied Modeling Language), Macromedia Fireworks 8 for the editing of images and
bitmaps at the interface of the project and MySQL Server 5.0 for the persistence of the
data used.
Keywords: HEI, UML.
16
1 INTRODUO
Atualmente o mercado de trabalho tem sido muito exigente na contratao de pro-
ssionais. Os contratantes passaram a fazer contatos diretamente com as coorde-
naes das IES, buscando estudantes qualicados por meio de referncias dos co-
ordenadores. Aps a concluso da graduao, os vnculos do egresso com a IES
podem ser comprometidos, inviabilizando o contato direto da coordenao com esse
egresso. Desta forma, a instituio no consegue referenciar aos contratantes estes
novos prossionais.
Ao ingressar em uma instituio, o aluno passa a criar um forte vnculo com cole-
gas de curso, professores, coordenadores e outros colaboradores da instituio. En-
tretanto este vnculo no somente acadmico, passa a ser tambm prossional.
Com a concluso do curso, caso o aluno no queira fazer uma especializao (ps-
graduao, mestrado, etc.) na mesma IES, esses vnculos adquiridos ao longo do
curso possivelmente enfraquecem.
Diante dessa situao, este trabalho visa implementar umsistema que possibilitar
as instituies manterem vnculos com os alunos formados atravs da atualizao dos
seus dados prossionais e pessoais, bem como dispor de anncios de empregos,
concursos, novos cursos, cursos de extenso, eventos prossionais, etc. Desta forma,
as empresas, ao procurarem por prossionais nas IES, tero uma maior expectativa na
contratao de prossionais qualicados. Da mesma maneira, os egressos tero um
grande meio de comunicao com a instituio e empresas da sua rea de atuao.
1.1 MOTIVAO
Combase empesquisas realizadas nas principais IES nacionais, no foramencon-
tradas solues que realizassem a interao entre o mercado de trabalho, os egressos
e as instituies.
17
Ao concluir a graduao, h possibilidade do egresso sentir diculdade em ingres-
sar no mercado de trabalho.
1.2 JUSTIFICATIVA
O Sistema de Egressos uma soluo que visa relacionar as principais exigncias
e necessidades do atual mercado de trabalho, desvendar quais as regras desta nova
economia, quais as perspectivas do mercado de trabalho para os prximos anos e
fornecer subsdios aos prossionais quanto s atitudes e habilidades a serem desen-
volvidas para atender esta nova demanda prossional e, assim, estar em condies de
conquistar uma posio na atual economia e manter sua empregabilidade no futuro.
As empresas sero beneciadas com uma nova ferramenta para encontrar pros-
sionais qualicados.
As IES que utilizarem a ferramenta tero um diferencial para oferecer aos seus
egressos, bem como poder utilizar os relatrios estatsticos para obter o perl dos
prossionais exigidos pelo mercado de trabalho atual.
1.3 OBJETIVO
Desenvolver um sistema WEB que auxilie os egressos de uma IES a ingressarem
no mercado de trabalho, mantendo seus dados atualizados, disponibilizando-os para
a instituio poder acompanhar sua trajetria prossional e acadmica, aproximando
o mercado do egresso.
18
2 CONCEITOS
Seguem os principais conceitos para a anlise e desenvolvimento do projeto Sis-
tema de Egressos.
2.1 ANLISE DE REQUISITOS
A anlise de requisitos, primeira fase do desenvolvimento de um software, o
momento em que o engenheiro de software estuda o problema e tenta entender o que
precisa ser feito pelo sistema a ser desenvolvido.
O estudo dos requisitos muito importante, pois o mesmo exerce um forte impacto
na qualidade do produto nal. Sem o entendimento completo e correto dos requisitos
no ser possvel desenvolver um sistema que atenda de forma satisfatria s neces-
sidades do cliente.
Os conceitos apresentados a seguir foram de suma importncia para a organiza-
o, compreenso e desenvolvimento do Sistema de Egressos.
2.2 LEVANTAMENTO DE REQUISITOS
Atravs do levantamento de requisitos so compreendidas e identicadas s prin-
cipais funcionalidades (requisitos funcionais) e restries (requisitos no-funcionais)
que devem ser consideradas para atender s necessidades do cliente.
O requisito uma condio ou capacidade que deve ser alcanada ou possuda
por um sistema ou componente deste para satisfazer um contrato, padro, especi-
cao ou outros documentos formalmente impostos, ou seja, uma ao (requisitos
funcionais) ou propriedade (requisitos no-funcionais) [BEZERRA - 2002].
19
2.3 LINGUAGEM DE MODELAGEM UNIFICADA
Na metade da dcada de 1990, Grady Booch (Rational Software Corporation), Ivar
Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de mtodos
orientados a objetos, comearam a utilizar as melhores idias e partiram para a cria-
o de uma linguagem unicada de modelagem.
Comisso esperavamfornecer ao mercado uma linguagemmais concreta e madura
com os quais os desenvolvedores de ferramentas pudessem criar uma ferramenta
mais utilizvel [HTTP://WWW.LINHADECODIGO.COM.BR].
A UML a linguagem padro para especicar, visualizar, comunicar, documentar
e construir artefatos de um sistema de software utilizando diversos diagramas [FALBO
- 2002].
A mesma foi utilizada para modelar os requisitos levantados para o Sistema de
Egressos traduzindo-os em forma de diagramas.
2.4 CONCEITOS DE ORIENTAO A OBJETOS
A orientao a objetos gerencia a complexidade dos problemas do mundo real,
abstraindo conhecimento relevante e encapsulando-o dentro de objetos. Do ponto de
vista da modelagem de sistemas, um objeto uma entidade que incorpora uma abs-
trao relevante no contexto de uma aplicao. Um objeto possui um estado (informa-
o), exibe um comportamento bem denido, expresso por um nmero de operaes
para examinar ou alterar seu estado, e tem identidade nica [FALBO - 2002].
Para o desenvolvimento do projeto foi preciso:
Identicar as classes (classe: modelo que descreve a estrutura e o comporta-
mento de um objeto [FALBO - 2002]);
Identicar Hierarquias de Generalizao/Especializao (caractersticas comuns
ou especcas - Herana [FALBO - 2002]);
Identicar Hierarquias de Generalizao/Especializao (caractersticas comuns
ou especcas - Herana [FALBO - 2002]);
20
Identicar associaes e atributos (relaes e propriedades dos objetos e clas-
ses [FALBO - 2002]);
Denir as operaes (interaes das classes e objetos).
2.5 ANLISE ORIENTADA A OBJETOS
Formalmente, o termo anlise corresponde a "quebrar"um sistema em seus com-
ponentes e estudar como tais componentes interagem com o objetivo de entender
como esse sistema funciona. Em um processo de desenvolvimento orientado a obje-
tos, o resultado da anlise so modelos que representam as estruturas das classes de
objetos componentes do sistema. Alm disso, a anlise tambm resulta em modelos
que especicam as funcionalidades do sistema de software. [BEZERRA - 2002].
2.6 ATORES
Atores so usurios e/ou outros meios externos que desenvolvem algum papel
na aplicao, gerando informaes para o sistema ou necessidade de informaes
geradas a partir do mesmo.
Existem atores que podem desempenhar mais de um papel no sistema, No Sis-
tema de Egressos existem usurios com diferentes permisses, com isso foi neces-
srio criar um ator para cada diferente tipo de situao possvel no ambiente. Os
atores so quem desempenham os casos de uso, um mesmo ator pode estar em um
ou mais casos de uso. Cada ator possui um nome que ter relao direta com a sua
funo, possuir uma descrio que denir o que ele faz e com quem ele interage
[HTTP://IMASTERS.UOL.COM.BR].
Na terminologia da UML, qualquer elemento externo que interage com o sistema
denominado ator.
2.7 MODELO DE CASO DE USO
Um caso de uso especica um comportamento de um sistema segundo uma pers-
pectiva externa e uma descrio de um conjunto de seqncias de aes realizadas
21
pelo sistema para produzir um resultado de valor observvel por um ator [BOOCH -
2000].
Um modelo de caso de uso descreve como diferentes tipos de usurios interagem
com o sistema para resolver um problema. Como tal, ele descreve as metas dos
usurios, as interaes entre os usurios e o sistema, bem como o comportamento
necessrio do sistema para satisfazer estas metas.
O mesmo consiste em um conjunto de elementos de modelo. Os elementos de
modelo mais importantes so: casos de uso, atores e as relaes entre eles. O dia-
grama de caso de uso usado para descrever gracamente um subconjunto do mo-
delo para simplicar a comunicao. Normalmente existiro vrios diagramas de caso
de uso associados a um determinado modelo, cada um mostrando um subconjunto
de elementos relevantes para um determinado m. O mesmo elemento de modelo
pode ser exibido em vrios diagramas de caso de uso, mas cada instncia tem que
ser consistente.
Se alguma ferramenta for usada para manter o modelo de caso de uso, esta res-
trio de consistncia deve ser automatizada, de forma que quaisquer alteraes em
um elemento de modelo (alterao do nome, por exemplo) sero automaticamente
reetidas em todos os diagramas que mostram o elemento.
O modelo de caso de uso pode conter pacotes que so usados para estruturar
o modelo e simplicar a anlise, a comunicao, a navegao, o desenvolvimento, a
manuteno e o planejamento do projeto.
2.8 DIAGRAMA DE CLASSE
Classe a representao de um conjunto de coisas reais ou abstratas que so
reconhecidos como sendo do mesmo tipo por compartilhar as mesmas caractersticas
de atributos, operaes, relaes e semntica [FURLAN, 1998].
O diagrama denota a estrutura esttica de um sistema, isto , as classes, os re-
lacionamentos entre suas instncias (objetos), restries e hierarquias. O diagrama
considerado esttico, pois a estrutura descrita sempre vlida em qualquer ponto no
ciclo de vida do sistema.
22
2.9 DIAGRAMA DE SEQUNCIA
O diagrama de Sequncia utilizado para representar as caractersticas da itera-
o dos casos de uso, representa a colaborao dinmica entre um nmero de obje-
tos, sendo seu objetivo principal mostrar a seqncia de mensagens enviadas entre
objetos. um grco bidimensional, onde a dimenso vertical representa o tempo e a
dimenso horizontal os diferentes objetos [BOOCH - 1998].
O comportamento do sistema uma descrio do que um sistema faz, sem ex-
plicar como ele o faz. Uma parte desta descrio um diagrama de seqncia do
sistema, ilustrando as interaes de atores e as operaes iniciadas por eles [LAR-
MAN - 2000].
2.10 DIAGRAMA DE ESTADOS DE NAVEGAO
Trata-se de representao grca especializada, que contm os diversos elemen-
tos que compem a arquitetura do software, tais como: as pginas e links, os compo-
nentes, mdulos e elementos de base de dados, as interfaces com sistemas externos
(protocolos de comunicao), entre outros, bemcomo a interligao desses elementos
atravs do uxo de navegao da interface.
Esse tipo de representao uma importante ferramenta no processo de manuten-
o de sistemas de softwares, a primeira atividade nesse tipo de projeto identicar
os itens que compem a arquitetura do sistema bem como os seus relacionamentos
(denio do escopo do projeto de manuteno) [HTTP://WWW.DGZ.ORG.BR].
2.11 DIAGRAMA DE PACOTES
Em muitos casos um nico diagrama de classes pode ser exageradamente grande
para representar todo o sistema. Assim conveniente utilizar-se de um elemento para
organizar os subsistemas do modelo. Para isto utilizam-se os diagramas de pacote.
Um pacote representa um grupo de classes (ou outros elementos) que se relaciona
comoutros pacotes atravs de uma relao de dependncia. Umdiagrama de pacotes
pode ser utilizado em qualquer fase do processo de modelagem e visa organizar os
modelos.
23
A utilizao do diagrama de pacotes se faz necessrio para que se possa obter
uma viso de nvel mais ampla do sistema, mostrando sua decomposio em subsis-
temas [FURLAN, 1998].
A UML dene um diagrama de pacotes como um modelo que descreve como os
elementos so organizados dentro de pacotes e suas dependncias. Esse diagrama
mostra pacotes importados e extenses de pacotes [MEDEIROS - 2004].
2.12 MODELO RELACIONAL
O modelo relacional um modelo de dados, adequado a ser o modelo subjacente
de um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princpio
em que todos os dados esto guardados em tabelas (ou, matematicamente falando,
relaes). Toda sua denio terica e baseada na lgica de predicados e na teoria
dos conjuntos.
O modelo relacional foi o primeiro modelo de banco de dados formal. Somente
depois seus antecessores (bancos de dados hierrquicos e em rede) passaram a ser
tambm descritos em linguagem formal.
24
3 LEVANTAMENTO DE
REQUISITOS
Para levantar os requisitos deste projeto utilizamos a tcnica da Entrevista, que
consiste especicamente de uma conversa formal com o entrevistado no formato
pergunta-resposta, por se tratar de uma forma eciente de se obter informaes perti-
nentes ao desenvolvimento do sistema.
3.1 ENTREVISTA
Seguem as guras 1 e 2 com as informaes obtidas durante a fase de levanta-
mento de requisitos.
Fonte Tcnica de Levantamento
Professores: Entrevista.
Cristiano Biancardi e
Otaclio Pereira.
Figura 1: Fonte X Tcnica de Levantamento
3.2 MODELAGEM DO SISTEMA
Durante a fase de modelagem foram denidas as ferramentas para o desenvolvi-
mento do projeto, os atores e suas funcionalidades, os casos de uso e suas descri-
es.
A maior diculdade nesta atividade est no equilbrio (tradeoff) entre simplicidade
(favorecendo a comunicao) e a complexidade (favorecendo a preciso) do modelo
[WWW.WIKIPEDIA.ORG].
25
Problemas levantados Causas
Pouca interao do ex-aluno(egresso)com Atualmente so uitilizadas outras
a instituio aps a concluso da graduao. ferramentas (e-mail, etc.) que no
tem sido ecazes para a interao
com os alunos formados, e que na
maioria dos casos, tal interao
ca muito enfraquecida.
No h a utilizao, por parte da institui- A instituiofaz uso de uma
o, de uma ferramenta especca com ns ferramenta semelhante, blog
de informaes aos egressos, como opertuni- acadmico, para os alunos
idades, seminrios, cursos, entre outros. matriculados, mas para os
egressos no.
Pouca interao do mercado de trabalho Soluo ainda no proposta
(empresas),IES e egressos. anteriormente.
A instituio no possui um acompanhamento A instituio no utiliza uma
dos dados prossionais e pessoais dos seus ferramenta que a mantenha
ex-alunos. atualizada quanto a trajetria
prossional dos seus ex-alunos.
Falta de um meio informatizado das empresas No h um controle de vnculos
atuantes no mercado, divulgarem oportuni- com empresas, tampouco,
dades especicamente aos egressos de uma gerenciamento de oportunidades.
instituio.
Figura 2: Problemas levantados X Causas
26
3.3 TECNOLOGIAS UTILIZADAS
Segue abaixo as tecnologias utilizadas para a engenharia do projeto:
A gura 3 refere-se a uma tela de demonstrao da ferramenta Enterprise Architect
6.5, uma ferramenta bastante completa e poderosa para a modelagem da UML, alm
de possuir uma boa integrao com o Visual Studio, outra ferramenta que tambm
ser utilizada.
Figura 3: Enterprise Architect 6.5
A gura 4 refere-se a uma tela de demonstrao da ferramenta Visual Studio 2008,
que permite aos desenvolvedores criarem aplicaes de pequena grande porte, com
um alto nvel de abstrao e orientao a objetos. Esta ferramenta, alm de ser ro-
busta na construo de seus projetos, possibilita criar aplicativos mais seguros, ge-
renciveis e conveis.
Figura 4: Visual Studio 2008
A gura 5 refere-se a uma tela de demonstrao da ferramenta de banco de dados
27
MySQL Server 5.0, uma poderosa ferramenta de gerenciamento de dados bastante
convel que fornece recursos de proteo e desempenho para clientes de aplicativos
incorporados, utilizando simples armazenamento de dados locais. Esta ferramenta
tambm possui uma integrao profunda com o Visual Studio, no qual utilizaremos no
desenvolvimento deste projeto.
Figura 5: MySQL Server 5.0
A gura 6 refere-se a uma tela de demonstrao da ferramenta Fireworks 8, uma
Excelente ferramenta para se trabalhar com imagens, oferecendo integrao com Java
scripts pr-prontos. Muito til na criao de layouts na web e com muita rapidez,
oferecendo uma interface direta com recursos indispensveis para trabalhar com a
camada de apresentao.
Figura 6: Fireworks 8
A gura 7 refere-se logomarca do software DB-Designer 4, uma ferramenta gra-
tuita de designer visual para modelagem relacional de dados, oferecendo uma ma-
neira eciente para os projetos. Proporciona uma viso ampla da estrutura completa,
28
alm dos relacionamentos das tabelas, evitando erros comuns nas relaes das mes-
mas.
Figura 7: DB-Designer 4
3.4 DIAGRAMAS DE CASO DE USO
O modelo de caso de uso molda os requisitos funcionais do sistema, facilitando o
entendimento do negcio por parte do analista e permite que clientes, sem conheci-
mento de anlise, consigam perceber quais os requisitos estaro sendo desenvolvidos
no processo de desenvolvimento do sistema [BEZERRA - 2002].
3.4.1 OBJETIVO
O objetivo desse documento compilar os artefatos gerados durante a fase de
anlise e detalhamento de requisitos do projeto. A gura 8 descreve o cenrio retra-
tando as interaes de todos os atores do sistema e seus respectivos casos de uso.
Segue abaixo descrio dos atores do sistema proposto:
Administrador: esse ator tem privilgios irrestritos no sistema, ele o principal
gestor da aplicao. Dentre as aes possveis que o administrador pode executar,
destacam-se o gerenciamento dos dados pertinentes aos cursos da instituio, co-
ordenadores dos cursos, egressos e empresas. Tornando-o assim pea chave na
utilizao da soluo.
Coordenador: uma vez inserido um coordenador de um curso, ele ter as funes
29
de validar ou no as vagas disponibilizadas pelas empresas devidamente cadastradas,
gerenciar fruns, dentre outras.
Empresa: o ator empresa tem a funo de criar, atualizar ou excluir seu cadastro
no sistema, enviar oportunidades disponveis para o coordenador avali-las, enviar
feedbacks para a instituio em relao aos resultados de seus processos seletivos,
ou seja, se houve ou no a contrao do egresso, com o objetivo de gerar uma base
estatstica com ns de gerar relatrios para tomadas de decises da instituio de
ensino, entre outras.
Egresso: o egresso tem funo de criar, atualizar ou excluir seu cadastro, uma
vez que ele tem total responsabilidade sobre a veracidade dos dados inseridos. Como
tambm, analisar as vagas existentes e candidatar-se, participar de fruns criando
enquetes e postando mensagens.
Figura 8: Diagrama de Caso de Uso Principal
30
3.4.2 LISTA DOS CASOS DE USO
Segue a lista dos principais casos de uso.
CASOS DE USO DO ATOR ADMINISTRADOR
Manter Curso;
Manter Coordenador;
Manter Frum (Inclui Gerenciar Frum).
CASOS DE USO DO ATOR COORDENADOR
Avaliar Empresa;
Validar Oportunidade;
Gerenciar Frum.
Gerar Relatrio.
CASOS DE USO DO ATOR EMPRESA
Manter Dados Empresa;
Manter Oportunidades (Inclui Gerar Feedback).
CASOS DE USO DO ATOR EGRESSO
Manter Dados Egresso;
Interagir Frum;
Visualizar Oportunidade.
31
3.5 DESCRIO DOS CASOS DE USO
Seguem as descries de seqncias de eventos que cada ator pode desempe-
nhar no sistema para completar um processo.
3.5.1 CASOS DE USO DO ATOR ADMINISTRADOR
A gura 9 representa os casos de uso do ator administrador, que destinado ao
usurio de autoridade mxima do sistema. Hierarquicamente seu perl espelharia o
de um diretor de graduao de uma IES.
Figura 9: Diagrama de Caso de Uso, Administrador
As guras 10, 11 e 12 descrevem os casos de uso de ator Administrador.
32
Figura 10: Descrio do Caso de uso: Manter Curso
Figura 11: Descrio do Caso de uso: Manter Coordenador
33
Figura 12: Descrio do Caso de uso: Manter Frum
34
3.5.2 CASOS DE USO DO ATOR COORDENADOR
A gura 13 representa os casos de uso do ator coordenador, que destinado a
um professor de determinado curso. Geralmente, este usurio o real coordenador
do curso na Instituio, mas isso pode variar conforme escolha do Administrador, des-
crito anteriormente.
Figura 13: Diagrama de Casos de Uso, Coordenador
As guras 14, 15, 16 e 17 descrevem os casos de uso de ator Coordenador.
35
Figura 14: Descrio do Caso de uso: Avaliar Empresa
Figura 15: Descrio do Caso de uso: Validar Oportunidade
36
Figura 16: Descrio do Caso de uso: Gerenciar Frum
Figura 17: Descrio do Caso de uso: Gerar Relatrio
37
3.5.3 CASOS DE USO DO ATOR EMPRESA
A gura 18 representa os casos de uso do ator empresa, que destinado s em-
presas, principalmente aquelas atuantes no mercado local.
Figura 18: Diagrama de Casos de Uso, Empresa
As guras 19, 20 e 21 descrevem os casos de uso de ator Empresa.
38
Figura 19: Descrio do Caso de uso: Manter Dados Empresa
Figura 20: Descrio do Caso de uso: Manter Oportunidade
39
Figura 21: Descrio do Caso de uso: Gerar Feedback
40
3.5.4 CASOS DE USO DO ATOR EGRESSO
A gura 22 representa os casos de uso do ator egresso, que destinado aos alu-
nos que concluram a graduao.
Figura 22: Diagrama de Casos de Uso, Egresso
As guras 23, 24 e 25 descrevem os casos de uso de ator Egresso.
41
Figura 23: Descrio do Caso de uso: Manter Dados Egresso
Figura 24: Descrio do Caso de uso: Visualizar Oportunidade
42
Figura 25: Descrio do Caso de uso: Interagir Frum
43
4 ESPECIFICAO DE PROJETO
Durante a fase de projeto, caram denidos os subsistemas (pacotes), a quan-
tidade de camadas que a aplicao ir trabalhar as relaes das entidades de cada
pacote em cada camada, o dicionrio de dados dos diagramas classes, o diagrama de
estados da entidade oportunidade, diagrama de navegao, o diagrama relacional do
banco de dados e dicionrio de dados, os diagramas de sequncias e a padronizao
do sistema.
4.1 DIAGRAMA DE PACOTES
O projeto foi subdividido em trs subsistemas, contendo um pacote administrativo,
pertinentes ao Administrador e ao Coordenador (gestores da aplicao), o pacote Cli-
ente referente ao Egresso e Empresa, e o pacote Utilitrio. Cada pacote representa
um subsistema do projeto.
A gura 26 mostra a diviso em pacotes do Sistema de Egressos
Figura 26: Diagrama de Pacotes
As funcionalidades comuns aos subsistemas Administrador e Cliente esto contidas
44
no pacote Utilitrio, com o intuito de prover a reusabilidade, ou seja, a utilizao des-
sas funcionalidades em outros projetos.
4.2 DIVISO EM CAMADAS
Utilizando o conceito de diviso em camadas, baseado na arquitetura .NET de
padres de projetos, os pacotes foram divididos nas camadas: User Interface (UI),
Services Interfaces (Facade), Business Component, Entity e Data Access.
User Interface (UI): camada de apresentao onde o usurio ter a interface de in-
terao como sistema, podendo, a todo o momento, trocar informaes como mesmo.
Services Interface (Facade): conhecida como Fachada, esta camada faz a inter-
face entre a camada de apresentao (UI) e a camada de Negcios (Business Layer)
onde utilizada uma forma simples para acessar vrios objetos do negcio.
Business Component : onde so realizadas as regras de negcios do sistema.
Tambm conhecida como Business Layer, esta camada trata as principais funcionali-
dades e complexidades do sistema.
Entity: esta camada representa todas as classes ou estruturas do sistema. Aqui os
objetos so estruturados para poderem ser criados em outras camadas da aplicao.
Data Access: didaticamente conhecida como Gerncia de Dados, esta camada
possui todas as operaes que o sistema necessitar para trocar mensagens ou infor-
maes com o banco de dados fsico [CUNNINGHAM, 2003].
A seguir, as guras 27 e 28 mostram os pacotes divididos nas cinco camadas, em
cada pacote:
45
Figura 27: Diagrama de Pacotes do subsistema Administrador
Figura 28: Diagrama de Pacotes do subsistema Cliente
46
4.3 DIAGRAMAS DE CLASSES
A seguir esto representados os diagramas de classe dos pacotes Administrador
e Cliente.
4.3.1 CAMADA DE ENTIDADES (ENTITY), ADMINISTRADOR
O diagrama de classes da camada Entity (Entidades) representa todos os objetos
e suas caractersticas. A gura 29 representa o diagrama de classes da camada de
entidades do pacote Administrador.
Figura 29: Diagrama de Classes da camada Entity, pacote Administrador
47
O dicionrio de dados do diagrama de classes da camada Entity do pacote admi-
nistrador encontra-se no Anexo A.
4.3.2 CAMADA DE NEGCIOS (BUSINESS), ADMINISTRADOR
O diagrama de classes da camada Business (Negcios) representa todas as re-
gras de negcios e operaes dos objetos, mostrando suas relaes, dependncias,
agregaes e composies. A gura 30 representa o diagrama de classes da camada
de negcios do pacote Administrador.
Figura 30: Diagrama de Classes da camada Business, pacote Administrador
O dicionrio de dados do diagrama de classes da camada Business do pacote ad-
ministrador encontra-se no Anexo A.
48
4.3.3 CAMADA DE ACESSO A DADOS (DATA ACCESS), ADMINIS-
TRADOR
O diagrama de classes da camada Data Access (Acesso a Dados) representa
todos os objetos e suas caractersticas. A gura 31 representa a classe de acesso
dados do pacote Administrador.
Note que todas as classes dependem da classe genrica, que onde a aplicao
acessa o banco de dados sicamente, por atravs de um conjunto de classes (Dlls)
que foram abstradas na implementao do projeto.
Figura 31: Classe Genrica que efetua a conexo com o banco de dados
A gura 32 representa o mtodo SalvarDados, utilizado no exemplo, recebe os pa-
rmetros vindos de outras classes da camada Data Access, retornando em uma es-
trutura de lista (vetor) os possveis resultados da consulta fsica.
49
Figura 32: Diagrama de Classes, camada Data Access, pacote Administrador
4.3.4 CAMADA DE FACHADA (FACADE), ADMINISTRADOR
A camada de fachada (facade) representa uma interface da camada de apresenta-
o com a camada de negcios (Business) e entidades (Entity), contemplando todas
as funcionalidades da camada de negcios. Apenas contm as operaes e o seu
tipo de retorno, deixando toda a implementao lgica na camada de negcios.
A gura 33 representa o diagrama de classes da camada de fachada do pacote
administrador.
50
Figura 33: Diagrama de Classes da camada Facade, pacote Administrador
4.3.5 CAMADA DE INTERFACE COM O USURIO (UI), ADMINIS-
TRADOR
O diagrama de classes da camada User Interface (Interface com o Usurio) repre-
senta todas as classes desta camada. A gura 34 representa o diagrama de classes
da camada de entidades do pacote Administrador 34..
51
Figura 34: Diagrama de Classes da camada UI, pacote Administrador
52
4.3.6 CAMADA DE ENTIDADES (ENTITY), CLIENTE
O diagrama de classes da camada Entity (Entidade) representa todos os objetos
e suas caractersticas. A gura 35 representa o diagrama de classes da camada de
entidades do pacote Cliente 35..
Figura 35: Diagrama de Classes da camada Entity, pacote Cliente
O dicionrio de dados do diagrama de classes da camada Entity do pacote cliente
encontra-se no Anexo A.
53
4.3.7 CAMADA DE NEGCIOS (BUSINESS), CLIENTE
O diagrama de classes da camada Business (Negcios) representa todas as re-
gras de negcios e operaes dos objetos, mostrando suas relaes, dependncias,
agregaes e composies. A gura 36 representa o diagrama de classes da camada
de negcios do pacote Cliente 36.
Figura 36: Diagrama de Classes da camada Business, pacote Cliente
O dicionrio de dados do diagrama de classes da camada Business do pacote
cliente encontra-se no Anexo A.
4.3.8 CAMADA DE ACESSO AOS DADOS (DATA ACCESS), CLI-
ENTE
O diagrama de classes da camada Data Access (Acesso a Dados) representa
todos os objetos suas caractersticas. A gura 37 representa o diagrama de classes
da camada de acesso aos dados do pacote Cliente.
54
Note que todas as classes dependem da camada de Data Access contida no pa-
cote Administrador, onde esto implementadas as classes de acesso ao banco de
dados fsico 37.
Figura 37: Diagrama de Classes da camada Data Access, pacote Cliente
4.3.9 CAMADA DE FACHADA (FACADE), CLIENTE
A camada de fachada (facade) representa uma interface da camada de apresenta-
o com a camada de negcios (Business) e entidades (Entity), contemplando todas
as funcionalidades da camada de negcios. Apenas contm as operaes e o seu
tipo de retorno, deixando toda a implementao lgica na camada de negcios.
A gura 38 representa o diagrama de classes da camada de fachada do pacote
cliente 38.
55
Figura 38: Diagrama de Classes da camada Facade, pacote Cliente
4.3.10 CAMADA DE INTERFACE COM O USURIO (UI) , CLIENTE
O diagrama de classes da camada User Interface (Interface com o Usurio) repre-
senta todas as classes desta camada. A gura 39 representa o diagrama de classes
da camada de entidades do pacote Cliente 39.
56
Figura 39: Diagrama de Classes da camada UI, pacote Cliente
57
4.4 DIAGRAMA ESTADOS
4.4.1 OPORTUNIDADE
A gura 40 mostra que ao ser inserida uma oportunidade no sistema, atinge o es-
tado pendente. Aps passar pelo processo de validao, onde ela poder ou no ser
visualizada pelos egressos, ele atingir os estados: vlido ou invlido exclusivamente
40.
Figura 40: Diagrama de Estados do Objeto Oportunidade
58
4.5 DIAGRAMA DE NAVEGAO
O diagrama de navegao permite a visualizao do uxo principal do sistema
proposto. Muitas vezes no possvel, antes da implementao do projeto, traar
exatamente todas as possveis telas e funcionalidades que a aplicao ter. A gura
41 representa o diagrama de navegao do Sistema 41.
Figura 41: Diagrama de Navegao
4.6 DIAGRAMA RELACIONAL DO BANCO DE DADOS
O diagrama relacional mostra as relaes que ocorrem nas tabelas (chamadas
de entidades na fase de modelagem). Atravs deste, possvel saber como ser a
persistncia fsica de todas as informaes que sero inseridas, atualizadas ou remo-
vidas do Sistema de Egressos. A gura 42 representa o diagrama relacional do banco
de dados 42.
59
Figura 42: Diagrama Relacional do Banco de Dados
O dicionrio de dados do diagrama relacional do banco de dados encontra-se no
Anexo A deste.
60
5 DIAGRAMAS DE SEQUNCIA
Um diagrama de seqncia descreve a maneira como os grupos de objetos co-
laboram em algum comportamento ao longo do tempo. Em sntese, ele representa
as interaes entre objetos de um cenrio, realizadas atravs de operaes ou mto-
dos (procedimentos ou funes). Este diagrama construdo a partir do Diagrama
de Casos de Uso e d nfase a ordenao temporal em que as mensagens so
trocadas entre os objetos de um sistema. Entende-se por mensagens, os servios
solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitaes
[HTTP://PT.WIKIPEDIA.ORG].
O Sistema de Egressos apresentou os seguintes Diagramas de Sequncia:
5.1 ADMINISTRADOR
Seguem os diagramas de sequncia referentes aos Casos de Uso do ator admi-
nistrador.
5.1.1 MANTER CURSO
O Caso de Uso Manter Curso engloba as operaes de inserir, alterar e desativar
um curso no portal de acordo com os mesmos oferecidos pela Instituio de ensino.
Assim, a gura 43 visa manter um curso no Sistema de Egressos 43.
61
Figura 43: Diagrama de Sequncia - Manter Curso
62
5.1.2 MANTER COORDENADOR
O Diagrama de Sequncia apresentado na gura 44 visa manter um coordenador
no Sistema de Egressos 44.
Figura 44: Diagrama de Sequncia - Manter Coordenador
5.1.3 MANTER FRUM (INCLUI GERENCIAR FRUM)
Incluir "Gerenciar Frum"signica que o ator administrador tem as mesmas per-
misses e funcionalidades que o ator coordenador, porm, somente o coordenador
poder inserir um "Frum".
Os diagramas de sequncia "EXCLUIR FRUM, TPICO, MENSAGEM"e "ALTE-
RAR FRUM, TPICO, MENSAGEM"no foram apresentados pela semelhana ao
diagrama "INSERIR FRUM, TPICO, MENSAGEM".
O Diagrama de Sequncia apresentado na gura 45 visa inserir um frum, um
tpico ou uma mensagem no Sistema de Egressos 45.
63
Figura 45: Diagrama de Sequncia - Inserir Tpico, Frum, Mensagem
5.2 COORDENADOR
Seguem os diagramas de sequncia referentes aos Casos de Uso do ator coorde-
nador.
5.2.1 AVALIAR EMPRESA
O Diagrama de Sequncia apresentado na gura 46 visa avaliar uma empresa no
Sistema de Egressos 46.
64
Figura 46: Diagrama de Sequncia - Avaliar Empresa
5.2.2 VALIDAR OPORTUNIDADE (INCLUI NOTIFICAR EGRESSO)
O Diagrama de Sequncia apresentado na gura 47 visa avaliar uma nova oportu-
nidade lanada por uma empresa devidamente cadastrada Sistema de Egressos 47.
5.2.3 GERENCIAR FRUM
O diagrama de sequncia "GERENCIAR FRUM"no foi apresentado pela seme-
lhana ao diagrama de sequncia "MANTER FRUM"do Caso de Uso "Administra-
dor". Diferem-se na ao de inserir um novo frum, podendo somente o administrador
executar tal sequncia na aplicao.
65
Figura 47: Diagrama de Sequncia - Validar Oportunidade
66
5.2.4 GERAR RELATRIO
O Diagrama de Sequncia apresentado na gura 48 visa gerar relatrios de di-
versos dados, como por exemplo, egressos contratados num determinado perodo,
quantidade de vagas oferecidas num determinado perodo, quantitativos de vagas no
momento, quantidade de empresas cadastradas, etc 48.
Figura 48: Diagrama de Sequncia - Gerar Relatrio
5.3 EMPRESA
Seguem os diagramas de sequncia referentes aos Casos de Uso do ator em-
presa.
5.3.1 MANTER DADOS EMPRESA
O Diagrama de Sequncia apresentado na gura 49 visa manter os dados (inserir,
alterar ou excluir) do perl de uma empresa devidamente castrada no Sistema de
Egressos 49.
67
Figura 49: Diagrama de Sequncia - Manter Dados Empresa
5.3.2 MANTER OPORTUNIDADE
O Diagrama de Sequncia apresentado na gura 50 visa manter os dados (inse-
rir, alterar ou excluir) do perl de um egresso devidamente castrado no Sistema de
Egressos50.
5.4 EGRESSO
Seguem os diagramas de sequncia referentes aos Casos de Uso do ator egresso.
5.4.1 MANTER DADOS EGRESSO
O Diagrama de Sequncia apresentado na gura 51 visa manter os dados (inse-
rir, alterar ou excluir) do perl de um egresso devidamente castrado no Sistema de
Egressos51.
68
Figura 50: Diagrama de Sequncia - Manter Oportunidade
5.4.2 VISUALIZAR OPORTUNIDADE
O Diagrama de Sequncia apresentado na gura 52 visa visualizar as oportuni-
dades enviadas pelas empresas cadastradas no portal e validadas pelo coordenador
52.
5.4.3 INTERAGIR FRUM
O diagrama de sequncia "INTERAGIR FRUM"no foi apresentado pela seme-
lhana ao diagrama de sequncia "GERENCIAR-FRUM"do Caso de Uso "COOR-
DENADOR". Nesse caso os dois atores podero inserir, alterar e excluir tpicos e
mensagens.
69
Figura 51: Diagrama de Sequncia - Manter Dados Egresso
Figura 52: Diagrama de Sequncia - Visualizar Oportunidades
70
6 PADRONIZAO
padronizao da interface com o usurio, em sua maioria, descrita em um ar-
quivo CSS, linguagem de estilos para HTML e XML.
Topo Superior (Master Page):
Imagem azul com guras dissolvidas de alunos esquerda.
Logo da instituio dissolvida direita.
Corpo das Telas (padres WEB):
Cor de fundo azul bem claro: #EDF7FC;
Fonte: FONT-WEIGHT: normal; FONT-SIZE: 11px; COLOR: black; FONT-FAMILY:
Tahoma, Verdana,
Arial, Helvetica, sans-serif; BACKGROUND-COLOR: #f9f9f9; MS Sans Serif, nor-
mal, tamanho 10, cor preta;
Telas centralizadas no centro da tela do usurio;
Tabelas HTML:
table.bordasimples border-collapse: collapse;
table.bordasimples tr td border:0px solid white;
table.bordasimples2 border-collapse: collapse;
table.bordasimples2 tr td border:0px solid red;
table.bordafrente border-collapse: collapse;
table.bordafrente tr td border:0px solid #efefef;
Classe de caixa de texto:
FONT-WEIGHT: bold;
71
FONT-SIZE: 11px;
COLOR: Black;
FONT-FAMILY: Verdana;
TEXT-DECORATION: none.
Figura 53: Botes e Imagens do Sistema
72
7 PROTOTIPAGEM
Um prottipo pode ser considerado uma implementao concreta, embora parcial,
de um programa. Os prottipos podem ser criados para explorar mltiplas questes
durante o desenvolvimento do software. Um prottipo de uma interface com o usurio
tem como principal objetivo conseguir captar as necessidades efetivas e concretas do
utilizado.
Atravs da prototipagem foi possvel obter as reais necessidades das principais
vertentes da soluo.
A gura 54 representa a pgina inicial do Sistema (Home). Atravs do menu dis-
ponvel na parte superior, o usurio poder navegar pelo sistema. Observe que, ini-
cialmente, no temos todas as funcionalidades disponveis no sistema. Para tanto, o
usurio necessitar autenticar-se na aplicao 54.
A gura 55 representa o formulrio de cadastro de egressos. Este formulrio pos-
sui um web service onde o usurio entra com o CEP e o sistema retorna o endereo
completo 55.
A gura 56 representa o formulrio de cadastro de empresas. Assim como o for-
mulrio anterior, este formulrio possui um web service onde o usurio entra com o
CEP e o sistema retorna o endereo completo 56.
As guras 57, 58 e 59 esto relacionadas ao usurio administrador.
A gura 57 representa o formulrio de cadastro de coordenador. Note o nome do
usurio autenticado, na barra de menu da aplicao. Nesta ocasio, um administrador
est autenticado 57.
A gura 58 representa o formulrio de cadastro de cursos 58.
A gura 59 representa o formulrio de consulta a cursos atravs de um compo-
nente web chamado GridView, onde podemos tambm alterar os dados do curso ou
desativ-lo 59.
73
Figura 54: Prototipagem - Principal
As guras 60, 61, 62 e 63 esto relacionadas ao usurio coordenador.
A gura 60 representa a pgina inicial do usurio coordenador sendo exibida a
rvore do item consultas. Note o nome do usurio autenticado, na barra de menu da
aplicao. Nesta ocasio, um coordenador est autenticado 60.
A gura 61 representa o formulrio de consulta s oportunidades lanadas, pelas
empresas, direcionadas ao curso no qual coordenado pelo usurio autenticado. No
item Detalhes, o usurio poder ver todos os detalhes da oportunidade 61.
A gura 62 representa a viso da oportunidade detalhada 62.
A gura 63 representa o formulrio de consulta s oportunidades que esto em es-
tado de espera. Esta situao ocorre quando a oportunidade, enviada pela empresa,
aguarda a validao do coordenador. Caso seja vlida, a oportunidade exibida para
todos os egressos do curso, caso contrrio, a oportunidade removida 63.
As guras 64 e 65 esto relacionadas ao usurio Empresa.
A gura 64 representa o formulrio onde so exibidas as oportunidades que j
foram cadastradas pelo usurio. Alm de poder visualizar as mesmas, o usurio ainda
poder excluir, caso seja necessrio. Note o nome do usurio autenticado, na barra
74
Figura 55: Prototipagem - Cadastro de Egressos
de menu da aplicao. Nesta ocasio, uma empresa est autenticada 64.
A gura 65 representa o formulrio de cadastro de oportunidades. Note que a
empresa poder associar qualquer curso, que esteja disponvel, para determinada
oportunidade 65.
A gura 66 representa o formulrio para o egresso, autenticado neste momento,
onde so exibidas as oportunidades disponibilizadas pelo coordenador do seu curso.
Note o nome do usurio autenticado na barra de menu da aplicao 66.
75
Figura 56: Prototipagem - Cadastro de Empresa
Figura 57: Prototipagem - Cadastro de coordenador
76
Figura 58: Prototipagem - Cadastro de curso
Figura 59: Prototipagem - Exibio, Alterao e Desativao de Curso
77
Figura 60: Prototipagem - Exibio do menu do Coordenador
Figura 61: Prototipagem - Exibio de Oportunidades para Coordenador
78
Figura 62: Prototipagem - Exibio de Oportunidade detalhada
Figura 63: Prototipagem - Validao de Oportunidades
79
Figura 64: Prototipagem - Exibio de Oportunidade para Empresa
Figura 65: Prototipagem - Cadastro de Oportunidades
80
Figura 66: Prototipagem - Exibio de Oportunidades para Egresso
81
8 DOCUMENTOS DE
ARQUITETURA
8.1 VISO FSICA
A viso fsica (viso de contexto) mostra uma viso em alto nvel do funcionamento
do sistema e da seqncia geral dos processos e contemplada na gura 67. A viso
fsica do sistema mostra os ns (computadores clientes e servidores) e componentes
fsicos (executveis, bibliotecas e aplicaes de bancos de dados) da soluo 67.
Servidor WEB, onde a aplicao estar sicamente disponvel para os usurios, com
a. NET Framework 3.5 instalado, rodando um Windows 2003 com IIS 7.0, garantindo
o mximo de desempenho nesta plataforma.
Conectado ao .NET WEB Server, ter o Servidor de Banco de Dados MySQL
Server com a verso 5.0 (verso estvel do banco) onde sero persistidas todas as
informaes do sistema.
Tambmter umservidor pop/smtp para envio/recebimento de emails, o Exchange
Server atendendo principalmente a demanda de envio de emails automticos pelas
funcionalidades do sistema.
Pela intranet ou pela internet, o sistema poder ser acessado por qualquer cate-
goria de usurio.
82
Figura 67: Viso Fsica
8.2 VISO LGICA
A viso lgica descreve as mais importantes classes e a sua organizao dentro
de pacotes de servios e subsistemas, alm da organizao desses subsistemas em
camadas. Diagramas de pacotes podem ser includos para ilustrar o relacionamento
entre camadas, pacotes, subsistemas e classes que so signicantes arquitetural-
mente. As guras 68 e 69 exibem a viso lgica do sistema de forma explicativa e
ilustrativa respectivamente, mostrando a sua organizao em pacotes lgicos. Nesta
tabela so descritos os principais pacotes lgicos do sistema:
83
Figura 68: Pacotes Lgicos do Sistema
84
Figura 69: Viso Lgica
85
9 ESTRUTURA TECNOLGICA
A instalao fsica de um projeto de software necessita de uma infra-estrutura de
hardware e rede para troca de dados, alm dos custos gerados pela hospitalidade da
soluo.
9.1 HOSPEDAGEMDOSITE (FATORES ACONSIDERAR)
Segue abaixo alguns aspectos a considerar na hospedagem de uma web site:
Os custos xos mensais, incluindo as taxas extras para instalao, gesto de do-
mnios, mudana de provedor.
Mensalidades que variem de acordo com o nmero de acessos e o volume de
contedo publicado (se o site muito acessado ou muito atualizado, tarifas extras
podem pesar no oramento).
O preo do servio nem sempre o principal fator de avaliao, na medida em que
outros requisitos podem ser mais crticos para a hospedagem do site, de acordo com
os seus objetivos de negcio e a natureza do contedo.
A compatibilidade do servidor com diferentes tecnologias, seja Linux, ASP.NET,
Java, PHP, Perl, Ajax, scripts CGI e outras. O Suporte a conexes com bancos de
dados (MySQL, SQL Server).
O desempenho do sistema, a resposta dos programas e das pginas, a base de
equipamentos atualizada, o espao em disco disponvel, com discos redundantes.
Nmero de conexes de alta velocidade disponveis, de forma que haja garantia
de que, ao cair uma delas, as outras mantero o(s) site(s) no ar. importante tam-
bm que a taxa de utilizao destas conexes no esteja prxima do seu limite de
demanda.
86
Contabilizao e anlise, em tempo real, dos acessos dos usurios, com informa-
es sobre nmero de visitas nicas, de pginas visitadas, sites de origem, palavras-
chave utilizadas em ferramentas de busca, tempo mdio da visita, percursos mais
visitados.
Essas questes so de grande importncia quando feito um estudo de custos e
benefcios com a hospedagem de uma aplicao na WEB.
87
10 PROJETO DE SEGURANA
Manuteno do sistema: realizao de backups dirios, manuteno de servi-
dores web redundantes (para o caso de emergncias), rewalls e medidas de
segurana (incluindo a segurana das instalaes).
Acesso ao sistema: A segurana do sistema ser feita atravs do controle da
entrada de dados no sistema, ou seja, pela utilizao do cdigo de acesso e
senha. Todos os usurios sero cadastrados no banco de dados e tero um
cdigo de acesso (login) e uma senha de no mnimo seis caracteres.
Entrada de dados: os seguintes controles sero usados nos campos que rece-
bero dados como a utilizao de tabelas para facilitar os preenchimentos; ta-
manhos dos campos limitados ao tamanho do banco de dados; Se algum campo
obrigatrio no for preenchido, o sistema apresenta uma mensagem avisando
que o campo deve ser preenchido; os campos das telas de entrada de dados
esto agrupados de acordo com a sua natureza.
Backup: o backup do banco de dados ser feito atravs de um script automtico,
onde ser realizado o backup dos dados do banco e dos arquivos da aplica-
o, caso seja feita alguma alterao de programa equivocada, o arquivo correto
poder ser restaurado. O horrio que ser realizado a rotina de backup ser
denida pela empresa que utilizar o sistema.
88
11 CONCLUSO
O Sistema de Egressos tem a proposta de prover a integrao entre o mercado de
trabalho, instituio de ensino e egressos, possibilitando a interao online para ns
prossionais e/ou acadmicos.
A organizao na distribuio de oportunidades aos egressos permite que as mes-
mas sejam disponibilizadas de acordo com sua rea pertinente, previamente selecio-
nada pelo empregador.
Dessa forma, o Sistema de Egressos ser um diferencial da instituio com os
mercados de trabalho, agregando aos seus egressos informaes pertinentes as suas
respectivas reas prossionais.
O desenvolvimento deste projeto teve como grande benefcio o aprendizado para
o complemento da grade acadmica e prossional, pois foi possvel aplicar uma gama
considervel de conhecimentos adquiridos durante o curso de Cincia da Computa-
o, praticando as atividades de analista de sistemas e programador.
De maneira geral, este sistema pode ser utilizado em qualquer Instituio de en-
sino que deseja manter vnculos com seus alunos egressos e propiciar a reciclagem
constante da grade curricular dos cursos oferecidos, focando atender as verdadeiras
e atuais necessidades do mercado de trabalho.
Tem-se como propostas de trabalhos futuros, a integrao do Banco de Dados
da Instituio (Centro Universitrio de Vila Velha - UVV) com o da aplicao, dessa
forma ser possvel importar os Coordenadores e Egressos para a aplicao sem a
necessidade de o ator Administrador inserir um coordenador ou o prprio egresso se
cadastrar, e o desenvolvimento do Schedulador (System Scheduler) - sistema geren-
ciador de tarefas previamente agendadas pelo administrador do sistema, funcionar
como uma espcie de Rob na execuo de operaes - para enviar mensagens aos
egressos quanto chegada de datas de processos seletivos das vagas disponibiliza-
das pelas empresas devidamente cadastradas na aplicao.
89
12 REFERNCIAS
BIBLIOGRFICAS
[BEZERRA - 2002] - BEZERRA, Eduardo. Princpios de Anlise e Projeto de
Sistemas com UML. 8
a
ed. Rio de Janeiro: Elsevier , 2002.
[HTTP://WWW.LINHADECODIGO.COM.BR] - NOGUEIRA, Admilson. UML - Uni-
ed Modeling Language - Introduo e Histrico.
Disponvel em <http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=763>.
Acesso em 28 dez. 2008, 22:30:00.
[FALBO - 2002] - FALBO, Ricardo. Anlise de Sistemas - Notas de Aula. Vitria:
UFES, 2002.
[FALBO - 2003] - FALBO, Ricardo. Projeto de Sistemas - Notas de Aula. Vitria:
UFES, 2003.
[HTTP://IMASTERS.UOL.COM.BR] - NOGUEIRA, Admilson. UML - Projetos de
Sistemas Orientados a Objetos. Disponvel em<http://imasters.uol.com.br/artigo/3877/atores>.
Acesso em 28 dez. 2008, 22:00:30.
[BOOCH - 1998] - BOOCH, Grady; JACOB, Jean Paul; RUMBAUGH, James. The
Unied Modeling Language Reference Manual. Addison-Wesley, 1998.
[LARMAN - 2000] - LARMAN, Craig. Utilizando UML e Padres: Uma Introduo
a Anlise e ao Projeto Orientados a Objetos; trad. Luiz A. Meirelles Salgado. Porto
Alegre: Bookman, 2000.
[HTTP://WWW.DGZ.ORG.BR] - ARAKAKI, Reginaldo; SOUZA, Alexandra A. Pro-
cesso de Manuteno de Software Web apoiado pela modelagem IHC. Disponvel em
Http://www.dgz.org.br/dez06/Art01.htm. Acesso em 19 out. 2008, 18:00:00.
[MEDEIROS - 2004] - MEDEIROS, Ernani Sales de. Desenvolvendo Software com
UML 2.0 : denitivo, So Paulo: Makron Books, 2004.
90
CUNNINGHAM, Ward. Enterprise Solution Patterns Using Microsoft.NET. Micro-
soft, 2003.
JEZIERSKI, Edward A., Application Architecture for .NET: Designing Applications
and Services. Microsoft, 2002.
MARIANI, Rico; BOHLING, Brandon; SMITH, Connie U.; BARBER, Scott. Impro-
ving .NET Application Performance and Scalability. Microsoft, 2004.
WITHALL, Stephen. Software Requirement Patterns. Microsoft, 2007.
[FURLAN - 1998] - Furlan, Jos Davi. Modelagem de Objetos atravs da UML:
Anlise e Desenho Orientados a Objetos, So Paulo: Makron Books, 1998.
[WWW.WIKIPEDIA.ORG] - Enciclopdia Livre.
Disponvel em <http://pt.wikipedia.org/wiki/Engenharia de software >. Acesso em
17 out. 2008, 21:45:00.
[HTTP://PT.WIKIPEDIA.ORG] - Enciclopdia Livre.
Disponvel em <http://pt.wikipedia.org/wiki/Diagrama de sequC3AAncia>. Acesso
em 20 out. 2008, 19:45:00.
91
ANEXO A
Este anexo contm as tabelas com os dicionrios de dados dos diagramas de
classes:
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120