sistema de egressos

CENTRO UNIVERSITÁRIO VILA VELHA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
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
Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso
apresentada ao Curso de Ciência da Computação do Centro Universitário de Vila Velha, como requisito parcial para a obtenção
do título de Bacharel em Ciência da Computação, sob orientação 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 Universitário Vila Velha
Orientador
Prof. Msc. Otacílio José Pereira
Centro Universitário Vila Velha
Prof. Msc. Susiléa Abreu dos Santos Lima
Centro Universitário Vila Velha
Trabalho de Conclusão 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 força, coragem, concentração e crença pelo
projeto, onde nos superamos a todo o momento. Aos nossos Pais, pelo apoio e credibilidade depositada em nós 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 dificuldades. Ao orientador do trabalho, pela oportunidade
concedida, pelo apoio, contribuição e disponibilização que foram essenciais para a
conclusão deste trabalho. Aos professores do curso de Ciência da Computação da
instituição, pela contribuição em nosso conhecimento acadêmico, imprescindível para
o desenvolvimento deste trabalho. Às nossas companheiras Brunella e Pollyanna, pela
compreensão e companheirismo desde o início do trabalho, pois estivemos ausentes
em inúmeros momentos durante o desenvolvimento deste. E finalmente, agradecemos a todos de uma forma geral que, diretamente ou indiretamente, contribuíram para
completar nosso objetivo. Muito obrigado à todos vocês!
""A estratégia é a ciência do emprego do espaço e do tempo. O espaço, podemos
reganhá-lo. O tempo não!"
autor desconhecido.
LISTA DE FIGURAS
1
Fonte X Técnica 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
Descrição do Caso de uso: Manter Curso . . . . . . . . . . . . . . . . .
32
11
Descrição do Caso de uso: Manter Coordenador . . . . . . . . . . . . .
32
12
Descrição do Caso de uso: Manter Fórum . . . . . . . . . . . . . . . . .
33
13
Diagrama de Casos de Uso, Coordenador . . . . . . . . . . . . . . . . .
34
14
Descrição do Caso de uso: Avaliar Empresa . . . . . . . . . . . . . . .
35
15
Descrição do Caso de uso: Validar Oportunidade . . . . . . . . . . . . .
35
16
Descrição do Caso de uso: Gerenciar Fórum . . . . . . . . . . . . . . .
36
17
Descrição do Caso de uso: Gerar Relatório . . . . . . . . . . . . . . . .
36
18
Diagrama de Casos de Uso, Empresa . . . . . . . . . . . . . . . . . . .
37
19
Descrição do Caso de uso: Manter Dados Empresa . . . . . . . . . . .
38
20
Descrição do Caso de uso: Manter Oportunidade . . . . . . . . . . . . .
38
21
Descrição do Caso de uso: Gerar Feedback . . . . . . . . . . . . . . . .
39
22
Diagrama de Casos de Uso, Egresso
40
. . . . . . . . . . . . . . . . . . .
23
Descrição do Caso de uso: Manter Dados Egresso . . . . . . . . . . . .
41
24
Descrição do Caso de uso: Visualizar Oportunidade . . . . . . . . . . .
41
25
Descrição do Caso de uso: Interagir Fórum . . . . . . . . . . . . . . . .
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 Genérica que efetua a conexão 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 Navegação
. . . . . . . . . . . . . . . . . . . . . . . . . .
58
42
Diagrama Relacional do Banco de Dados . . . . . . . . . . . . . . . . .
59
43
Diagrama de Sequência - Manter Curso . . . . . . . . . . . . . . . . . .
61
44
Diagrama de Sequência - Manter Coordenador . . . . . . . . . . . . . .
62
45
Diagrama de Sequência - Inserir Tópico, Fórum, Mensagem . . . . . .
63
46
Diagrama de Sequência - Avaliar Empresa . . . . . . . . . . . . . . . .
64
47
Diagrama de Sequência - Validar Oportunidade . . . . . . . . . . . . . .
65
48
Diagrama de Sequência - Gerar Relatório . . . . . . . . . . . . . . . . .
66
49
Diagrama de Sequência - Manter Dados Empresa . . . . . . . . . . . .
67
50
Diagrama de Sequência - Manter Oportunidade . . . . . . . . . . . . . .
68
51
Diagrama de Sequência - Manter Dados Egresso . . . . . . . . . . . . .
69
52
Diagrama de Sequência - Visualizar Oportunidades . . . . . . . . . . .
70
53
Botões 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 - Exibição, Alteração e Desativação de Curso . . . . . . .
77
60
Prototipagem - Exibição do menu do Coordenador . . . . . . . . . . . .
77
61
Prototipagem - Exibição de Oportunidades para Coordenador . . . . . .
78
62
Prototipagem - Exibição de Oportunidade detalhada . . . . . . . . . . .
78
63
Prototipagem - Validação de Oportunidades . . . . . . . . . . . . . . . .
79
64
Prototipagem - Exibição de Oportunidade para Empresa . . . . . . . . .
80
65
Prototipagem - Cadastro de Oportunidades . . . . . . . . . . . . . . . .
81
66
Prototipagem - Exibição de Oportunidades para Egresso . . . . . . . .
81
67
Visão Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
68
Pacotes Lógicos do Sistema . . . . . . . . . . . . . . . . . . . . . . . .
84
69
Visão Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
LISTA DE SIGLAS E ABREVIATURAS
IES: Instituição de Nível Superior.
UML: Unified 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 Office Protocol
SMTP: Simple Mail Transfer Protocol
IIS: Internet Information Service
SUMÁRIO
RESUMO
ABSTRACT
1 INTRODUÇÃO
16
1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.3 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2 CONCEITOS
18
2.1 ANÁLISE DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.2 LEVANTAMENTO DE REQUISITOS . . . . . . . . . . . . . . . . . . . .
18
2.3 LINGUAGEM DE MODELAGEM UNIFICADA . . . . . . . . . . . . . . .
19
2.4 CONCEITOS DE ORIENTAÇÃO A OBJETOS . . . . . . . . . . . . . . .
19
2.5 ANÁLISE 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 SEQUÊNCIA . . . . . . . . . . . . . . . . . . . . . . . .
22
2.10 DIAGRAMA DE ESTADOS DE NAVEGAÇÃO . . . . . . . . . . . . . . .
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 DESCRIÇÃO 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 ESPECIFICAÇÃO DE PROJETO
43
4.1 DIAGRAMA DE PACOTES . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2 DIVISÃO EM CAMADAS
. . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3 DIAGRAMAS DE CLASSES . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3.1 CAMADA DE ENTIDADES (ENTITY), ADMINISTRADOR . . . .
46
4.3.2 CAMADA DE NEGÓCIOS (BUSINESS), ADMINISTRADOR . .
47
4.3.3 CAMADA DE ACESSO A DADOS (DATA ACCESS), ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.3.4 CAMADA DE FACHADA (FACADE), ADMINISTRADOR . . . . .
49
4.3.5 CAMADA DE INTERFACE COM O USUÁRIO (UI), ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.3.6 CAMADA DE ENTIDADES (ENTITY), CLIENTE . . . . . . . . .
52
4.3.7 CAMADA DE NEGÓCIOS (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 USUÁRIO (UI) , CLIENTE . .
55
4.4 DIAGRAMA ESTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.4.1 OPORTUNIDADE . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.5 DIAGRAMA DE NAVEGAÇÃO . . . . . . . . . . . . . . . . . . . . . . .
58
4.6 DIAGRAMA RELACIONAL DO BANCO DE DADOS . . . . . . . . . . .
58
5 DIAGRAMAS DE SEQUÊNCIA
60
5.1 ADMINISTRADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.1.1 MANTER CURSO . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.1.2 MANTER COORDENADOR . . . . . . . . . . . . . . . . . . . .
62
5.1.3 MANTER FÓRUM (INCLUI GERENCIAR FÓRUM)
. . . . . . .
62
5.2 COORDENADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.2.1 AVALIAR EMPRESA . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.2.2 VALIDAR OPORTUNIDADE (INCLUI NOTIFICAR EGRESSO) .
64
5.2.3 GERENCIAR FÓRUM . . . . . . . . . . . . . . . . . . . . . . . .
66
5.2.4 GERAR RELATÓRIO . . . . . . . . . . . . . . . . . . . . . . . .
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 FÓRUM . . . . . . . . . . . . . . . . . . . . . . . . .
69
6 PADRONIZAÇÃO
71
7 PROTOTIPAGEM
73
8 DOCUMENTOS DE ARQUITETURA
82
8.1 VISÃO FÍSICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
8.2 VISÃO LÓGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
9 ESTRUTURA TECNOLÓGICA
9.1 HOSPEDAGEM DO SITE (FATORES A CONSIDERAR) . . . . . . . . .
86
86
10 PROJETO DE SEGURANÇA
88
11 CONCLUSÃO
89
12 REFERÊNCIAS BIBLIOGRÁFICAS
90
ANEXO A
92
RESUMO
RESUMO
Necessitando a busca por profissionais qualificados e de conhecimentos tácitos,
as empresas têm recorrido às instituições de ensino superior (IES) para contratação
de pessoas. Os contratantes passaram a fazer contatos diretamente com as coordenações dos cursos com o intuito de encontrar os estudantes mais qualificados por
meio de referências dos coordenadores. Entretanto, por conflitos de horários entre o
trabalho e a faculdade, ou mesmo por falta de experiência profissional, os contratantes e os próprios coordenadores, têm preferência por alunos formados, ou seja, os
alunos que egressaram da IES. Partindo deste conceito, este trabalho propõe projetar
e implementar uma aplicação Web, com a finalidade de prover um novo conceito em
egressos acadêmicos possibilitando a interação entre o mercado de trabalho, o recém
formado e a intituição. Para isso, serão utilizadas as seguintes ferramentas: plataforma .NET, especificamente a linguagem C-Sharp por ser uma poderosa tecnologia
de desenvolvimento de softwares tanto para a Web quanto para as demais aplicações,
a ferramenta case Enterprise Architect 6.5 para análise e modelagem da UML (Unified
Modeling Language), Macromedia FireWorks 8 para a edição de imagens e bitmaps
na interface do projeto e o MySQL Server 5.0 para a persistência dos dados utilizados.
Palavras-chave: IES, UML.
ABSTRACT
ABSTRACT:
Need to search for qualified 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 finding the most
qualified students by means of references coordinators. However, in times of conflict
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 implementing 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, specifically 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
(Unified 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
INTRODUÇÃO
Atualmente o mercado de trabalho tem sido muito exigente na contratação de profissionais. Os contratantes passaram a fazer contatos diretamente com as coordenações das IES, buscando estudantes qualificados por meio de referências dos coordenadores. Após a conclusão da graduação, os vínculos do egresso com a IES
podem ser comprometidos, inviabilizando o contato direto da coordenação com esse
egresso. Desta forma, a instituição não consegue referenciar aos contratantes estes
novos profissionais.
Ao ingressar em uma instituição, o aluno passa a criar um forte vínculo com colegas de curso, professores, coordenadores e outros colaboradores da instituição. Entretanto este vínculo não é somente acadêmico, passa a ser também profissional.
Com a conclusão do curso, caso o aluno não queira fazer uma especialização (pósgraduação, mestrado, etc.) na mesma IES, esses vínculos adquiridos ao longo do
curso possivelmente enfraquecem.
Diante dessa situação, este trabalho visa implementar um sistema que possibilitará
as instituições manterem vínculos com os alunos formados através da atualização dos
seus dados profissionais e pessoais, bem como dispor de anúncios de empregos,
concursos, novos cursos, cursos de extensão, eventos profissionais, etc. Desta forma,
as empresas, ao procurarem por profissionais nas IES, terão uma maior expectativa na
contratação de profissionais qualificados. Da mesma maneira, os egressos terão um
grande meio de comunicação com a instituição e empresas da sua área de atuação.
1.1 MOTIVAÇÃO
Com base em pesquisas realizadas nas principais IES nacionais, não foram encontradas soluções que realizassem a interação entre o mercado de trabalho, os egressos
e as instituições.
17
Ao concluir a graduação, há possibilidade do egresso sentir dificuldade em ingressar no mercado de trabalho.
1.2 JUSTIFICATIVA
O Sistema de Egressos é uma solução que visa relacionar as principais exigências
e necessidades do atual mercado de trabalho, desvendar quais as regras desta nova
economia, quais as perspectivas do mercado de trabalho para os próximos anos e
fornecer subsídios aos profissionais quanto às atitudes e habilidades a serem desenvolvidas para atender esta nova demanda profissional e, assim, estar em condições de
conquistar uma posição na atual economia e manter sua empregabilidade no futuro.
As empresas serão beneficiadas com uma nova ferramenta para encontrar profissionais qualificados.
As IES que utilizarem a ferramenta terão um diferencial para oferecer aos seus
egressos, bem como poderá utilizar os relatórios estatísticos para obter o perfil dos
profissionais 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 instituição poder acompanhar sua trajetória profissional e acadêmica, aproximando
o mercado do egresso.
18
2
CONCEITOS
Seguem os principais conceitos para a análise e desenvolvimento do projeto Sistema de Egressos.
2.1 ANÁLISE DE REQUISITOS
A análise 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 final. Sem o entendimento completo e correto dos requisitos
não será possível desenvolver um sistema que atenda de forma satisfatória às necessidades do cliente.
Os conceitos apresentados a seguir foram de suma importância para a organização, compreensão e desenvolvimento do Sistema de Egressos.
2.2 LEVANTAMENTO DE REQUISITOS
Através do levantamento de requisitos são compreendidas e identificadas às principais funcionalidades (requisitos funcionais) e restrições (requisitos não-funcionais)
que devem ser consideradas para atender às necessidades do cliente.
O requisito é uma condição ou capacidade que deve ser alcançada ou possuída
por um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos, ou seja, é uma ação (requisitos
funcionais) ou propriedade (requisitos não-funcionais) [BEZERRA - 2002].
19
2.3 LINGUAGEM DE MODELAGEM UNIFICADA
Na metade da década de 1990, Grady Booch (Rational Software Corporation), Ivar
Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de métodos
orientados a objetos, começaram a utilizar as melhores idéias e partiram para a criação de uma linguagem unificada de modelagem.
Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura
com os quais os desenvolvedores de ferramentas pudessem criar uma ferramenta
mais utilizável [HTTP://WWW.LINHADECODIGO.COM.BR].
A UML é a linguagem padrão para especificar, 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 ORIENTAÇÃO A OBJETOS
A orientação 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 abstração relevante no contexto de uma aplicação. Um objeto possui um estado (informação), exibe um comportamento bem definido, expresso por um número de operações
para examinar ou alterar seu estado, e tem identidade única [FALBO - 2002].
Para o desenvolvimento do projeto foi preciso:
• Identificar as classes (classe: modelo que descreve a estrutura e o comportamento de um objeto [FALBO - 2002]);
• Identificar Hierarquias de Generalização/Especialização (características comuns
ou específicas - Herança [FALBO - 2002]);
• Identificar Hierarquias de Generalização/Especialização (características comuns
ou específicas - Herança [FALBO - 2002]);
20
• Identificar associações e atributos (relações e propriedades dos objetos e classes [FALBO - 2002]);
• Definir as operações (interações das classes e objetos).
2.5 ANÁLISE ORIENTADA A OBJETOS
Formalmente, o termo análise corresponde a "quebrar"um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender
como esse sistema funciona. Em um processo de desenvolvimento orientado a objetos, o resultado da análise são modelos que representam as estruturas das classes de
objetos componentes do sistema. Além disso, a análise também resulta em modelos
que especificam as funcionalidades do sistema de software. [BEZERRA - 2002].
2.6 ATORES
Atores são usuários e/ou outros meios externos que desenvolvem algum papel
na aplicação, gerando informações para o sistema ou necessidade de informações
geradas a partir do mesmo.
Existem atores que podem desempenhar mais de um papel no sistema, No Sistema de Egressos existem usuários com diferentes permissões, com isso foi necessário criar um ator para cada diferente tipo de situação possível no ambiente. Os
atores são 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á relação direta com a sua
função, possuirá uma descrição que definirá 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 especifica um comportamento de um sistema segundo uma perspectiva externa e é uma descrição de um conjunto de seqüências de ações realizadas
21
pelo sistema para produzir um resultado de valor observável por um ator [BOOCH 2000].
Um modelo de caso de uso descreve como diferentes tipos de usuários interagem
com o sistema para resolver um problema. Como tal, ele descreve as metas dos
usuários, as interações entre os usuários e o sistema, bem como o comportamento
necessário do sistema para satisfazer estas metas.
O mesmo consiste em um conjunto de elementos de modelo. Os elementos de
modelo mais importantes são: casos de uso, atores e as relações entre eles. O diagrama de caso de uso é usado para descrever graficamente um subconjunto do modelo para simplificar a comunicação. Normalmente existirão vários diagramas de caso
de uso associados a um determinado modelo, cada um mostrando um subconjunto
de elementos relevantes para um determinado fim. O mesmo elemento de modelo
pode ser exibido em vários diagramas de caso de uso, mas cada instância tem que
ser consistente.
Se alguma ferramenta for usada para manter o modelo de caso de uso, esta restrição de consistência deve ser automatizada, de forma que quaisquer alterações em
um elemento de modelo (alteração do nome, por exemplo) serão automaticamente
refletidas em todos os diagramas que mostram o elemento.
O modelo de caso de uso pode conter pacotes que são usados para estruturar
o modelo e simplificar a análise, a comunicação, a navegação, o desenvolvimento, a
manutenção e o planejamento do projeto.
2.8 DIAGRAMA DE CLASSE
Classe é a representação de um conjunto de coisas reais ou abstratas que são
reconhecidos como sendo do mesmo tipo por compartilhar as mesmas características
de atributos, operações, relações e semântica [FURLAN, 1998].
O diagrama denota a estrutura estática de um sistema, isto é, as classes, os relacionamentos entre suas instâncias (objetos), restrições e hierarquias. O diagrama é
considerado estático, pois a estrutura descrita é sempre válida em qualquer ponto no
ciclo de vida do sistema.
22
2.9 DIAGRAMA DE SEQUÊNCIA
O diagrama de Sequência é utilizado para representar as características da iteração dos casos de uso, representa a colaboração dinâmica entre um número de objetos, sendo seu objetivo principal mostrar a seqüência de mensagens enviadas entre
objetos. É um gráfico bidimensional, onde a dimensão vertical representa o tempo e a
dimensão horizontal os diferentes objetos [BOOCH - 1998].
O comportamento do sistema é uma descrição do que um sistema faz, sem explicar como ele o faz. Uma parte desta descrição é um diagrama de seqüência do
sistema, ilustrando as interações de atores e as operações iniciadas por eles [LARMAN - 2000].
2.10 DIAGRAMA DE ESTADOS DE NAVEGAÇÃO
Trata-se de representação gráfica especializada, que contém os diversos elementos que compõem a arquitetura do software, tais como: as páginas e links, os componentes, módulos e elementos de base de dados, as interfaces com sistemas externos
(protocolos de comunicação), entre outros, bem como a interligação desses elementos
através do fluxo de navegação da interface.
Esse tipo de representação é uma importante ferramenta no processo de manutenção de sistemas de softwares, a primeira atividade nesse tipo de projeto é identificar
os itens que compõem a arquitetura do sistema bem como os seus relacionamentos
(definição do escopo do projeto de manutenção) [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
com outros pacotes através de uma relação de dependência. Um diagrama de pacotes
pode ser utilizado em qualquer fase do processo de modelagem e visa organizar os
modelos.
23
A utilização do diagrama de pacotes se faz necessário para que se possa obter
uma visão de nível mais ampla do sistema, mostrando sua decomposição em subsistemas [FURLAN, 1998].
A UML define um diagrama de pacotes como um modelo que descreve como os
elementos são organizados dentro de pacotes e suas dependências. Esse diagrama
mostra pacotes importados e extensões 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 princípio
em que todos os dados estão guardados em tabelas (ou, matematicamente falando,
relações). Toda sua definição é teórica e baseada na lógica 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 hierárquicos e em rede) passaram a ser
também descritos em linguagem formal.
24
3
LEVANTAMENTO DE
REQUISITOS
Para levantar os requisitos deste projeto utilizamos a técnica da Entrevista, que
consiste especificamente de uma conversa formal com o entrevistado no formato
pergunta-resposta, por se tratar de uma forma eficiente de se obter informações pertinentes ao desenvolvimento do sistema.
3.1 ENTREVISTA
Seguem as figuras 1 e 2 com as informações obtidas durante a fase de levantamento de requisitos.
Fonte
Professores:
Cristiano Biancardi e
Otacílio Pereira.
Técnica de Levantamento
Entrevista.
Figura 1: Fonte X Técnica de Levantamento
3.2 MODELAGEM DO SISTEMA
Durante a fase de modelagem foram definidas as ferramentas para o desenvolvimento do projeto, os atores e suas funcionalidades, os casos de uso e suas descrições.
A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade
(favorecendo a comunicação) e a complexidade (favorecendo a precisão) do modelo
[WWW.WIKIPEDIA.ORG].
25
Problemas levantados
Pouca interação do ex-aluno(egresso)com
a instituição após a conclusão da graduação.
Não há a utilização, por parte da instituição, de uma ferramenta específica com fins
de informações aos egressos, como opertuniidades, seminários, cursos, entre outros.
Pouca interação do mercado de trabalho
(empresas),IES e egressos.
A instituição não possui um acompanhamento
dos dados profissionais e pessoais dos seus
ex-alunos.
Falta de um meio informatizado das empresas
atuantes no mercado, divulgarem oportunidades especificamente aos egressos de uma
instituição.
Causas
Atualmente são uitilizadas outras
ferramentas (e-mail, etc.) que não
tem sido eficazes para a interação
com os alunos formados, e que na
maioria dos casos, tal interação
fica muito enfraquecida.
A instituiçãofaz uso de uma
ferramenta semelhante, blog
acadêmico, para os alunos
matriculados, mas para os
egressos não.
Solução ainda não proposta
anteriormente.
A instituição não utiliza uma
ferramenta que a mantenha
atualizada quanto a trajetória
profissional dos seus ex-alunos.
Não há um controle de vínculos
com empresas, tampouco,
gerenciamento de oportunidades.
Figura 2: Problemas levantados X Causas
26
3.3 TECNOLOGIAS UTILIZADAS
Segue abaixo as tecnologias utilizadas para a engenharia do projeto:
A figura 3 refere-se a uma tela de demonstração da ferramenta Enterprise Architect
6.5, uma ferramenta bastante completa e poderosa para a modelagem da UML, além
de possuir uma boa integração com o Visual Studio, outra ferramenta que também
será utilizada.
Figura 3: Enterprise Architect 6.5
A figura 4 refere-se a uma tela de demonstração da ferramenta Visual Studio 2008,
que permite aos desenvolvedores criarem aplicações de pequena à grande porte, com
um alto nível de abstração e orientação a objetos. Esta ferramenta, além de ser robusta na construção de seus projetos, possibilita criar aplicativos mais seguros, gerenciáveis e confiáveis.
Figura 4: Visual Studio 2008
A figura 5 refere-se a uma tela de demonstração da ferramenta de banco de dados
27
MySQL Server 5.0, uma poderosa ferramenta de gerenciamento de dados bastante
confiável que fornece recursos de proteção e desempenho para clientes de aplicativos
incorporados, utilizando simples armazenamento de dados locais. Esta ferramenta
também possui uma integração profunda com o Visual Studio, no qual utilizaremos no
desenvolvimento deste projeto.
Figura 5: MySQL Server 5.0
A figura 6 refere-se a uma tela de demonstração da ferramenta Fireworks 8, uma
Excelente ferramenta para se trabalhar com imagens, oferecendo integração com Java
script’s pré-prontos. Muito útil na criação de layouts na web e com muita rapidez,
oferecendo uma interface direta com recursos indispensáveis para trabalhar com a
camada de apresentação.
Figura 6: Fireworks 8
A figura 7 refere-se à logomarca do software DB-Designer 4, uma ferramenta gratuita de designer visual para modelagem relacional de dados, oferecendo uma maneira eficiente para os projetos. Proporciona uma visão ampla da estrutura completa,
28
além dos relacionamentos das tabelas, evitando erros comuns nas relações das mesmas.
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 negócio por parte do analista e permite que clientes, sem conhecimento de análise, consigam perceber quais os requisitos estarão 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
análise e detalhamento de requisitos do projeto. A figura 8 descreve o cenário retratando as interações de todos os atores do sistema e seus respectivos casos de uso.
Segue abaixo descrição dos atores do sistema proposto:
Administrador: esse ator tem privilégios irrestritos no sistema, ele é o principal
gestor da aplicação. Dentre as ações possíveis que o administrador pode executar,
destacam-se o gerenciamento dos dados pertinentes aos cursos da instituição, coordenadores dos cursos, egressos e empresas. Tornando-o assim peça chave na
utilização da solução.
Coordenador: uma vez inserido um coordenador de um curso, ele terá as funções
29
de validar ou não as vagas disponibilizadas pelas empresas devidamente cadastradas,
gerenciar fóruns, dentre outras.
Empresa: o ator empresa tem a função de criar, atualizar ou excluir seu cadastro
no sistema, enviar oportunidades disponíveis para o coordenador avaliá-las, enviar
feedbacks para a instituição em relação aos resultados de seus processos seletivos,
ou seja, se houve ou não a contração do egresso, com o objetivo de gerar uma base
estatística com fins de gerar relatórios para tomadas de decisões da instituição de
ensino, entre outras.
Egresso: o egresso tem função de criar, atualizar ou excluir seu cadastro, uma
vez que ele tem total responsabilidade sobre a veracidade dos dados inseridos. Como
também, analisar as vagas existentes e candidatar-se, participar de fóruns 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 Fórum (Inclui Gerenciar Fórum).
CASOS DE USO DO ATOR COORDENADOR
• Avaliar Empresa;
• Validar Oportunidade;
• Gerenciar Fórum.
• Gerar Relatório.
CASOS DE USO DO ATOR EMPRESA
• Manter Dados Empresa;
• Manter Oportunidades (Inclui Gerar Feedback).
CASOS DE USO DO ATOR EGRESSO
• Manter Dados Egresso;
• Interagir Fórum;
• Visualizar Oportunidade.
31
3.5 DESCRIÇÃO DOS CASOS DE USO
Seguem as descrições de seqüências de eventos que cada ator pode desempenhar no sistema para completar um processo.
3.5.1 CASOS DE USO DO ATOR ADMINISTRADOR
A figura 9 representa os casos de uso do ator administrador, que é destinado ao
usuário de autoridade máxima do sistema. Hierarquicamente seu perfil espelharia o
de um diretor de graduação de uma IES.
Figura 9: Diagrama de Caso de Uso, Administrador
As figuras 10, 11 e 12 descrevem os casos de uso de ator Administrador.
32
Figura 10: Descrição do Caso de uso: Manter Curso
Figura 11: Descrição do Caso de uso: Manter Coordenador
33
Figura 12: Descrição do Caso de uso: Manter Fórum
34
3.5.2 CASOS DE USO DO ATOR COORDENADOR
A figura 13 representa os casos de uso do ator coordenador, que é destinado a
um professor de determinado curso. Geralmente, este usuário é o real coordenador
do curso na Instituição, mas isso pode variar conforme escolha do Administrador, descrito anteriormente.
Figura 13: Diagrama de Casos de Uso, Coordenador
As figuras 14, 15, 16 e 17 descrevem os casos de uso de ator Coordenador.
35
Figura 14: Descrição do Caso de uso: Avaliar Empresa
Figura 15: Descrição do Caso de uso: Validar Oportunidade
36
Figura 16: Descrição do Caso de uso: Gerenciar Fórum
Figura 17: Descrição do Caso de uso: Gerar Relatório
37
3.5.3 CASOS DE USO DO ATOR EMPRESA
A figura 18 representa os casos de uso do ator empresa, que é destinado às empresas, principalmente aquelas atuantes no mercado local.
Figura 18: Diagrama de Casos de Uso, Empresa
As figuras 19, 20 e 21 descrevem os casos de uso de ator Empresa.
38
Figura 19: Descrição do Caso de uso: Manter Dados Empresa
Figura 20: Descrição do Caso de uso: Manter Oportunidade
39
Figura 21: Descrição do Caso de uso: Gerar Feedback
40
3.5.4 CASOS DE USO DO ATOR EGRESSO
A figura 22 representa os casos de uso do ator egresso, que é destinado aos alunos que concluíram a graduação.
Figura 22: Diagrama de Casos de Uso, Egresso
As figuras 23, 24 e 25 descrevem os casos de uso de ator Egresso.
41
Figura 23: Descrição do Caso de uso: Manter Dados Egresso
Figura 24: Descrição do Caso de uso: Visualizar Oportunidade
42
Figura 25: Descrição do Caso de uso: Interagir Fórum
43
4
ESPECIFICAÇÃO DE PROJETO
Durante a fase de projeto, ficaram definidos os subsistemas (pacotes), a quantidade de camadas que a aplicação irá trabalhar as relações das entidades de cada
pacote em cada camada, o dicionário de dados dos diagramas classes, o diagrama de
estados da entidade oportunidade, diagrama de navegação, o diagrama relacional do
banco de dados e dicionário de dados, os diagramas de sequências e a padronização
do sistema.
4.1 DIAGRAMA DE PACOTES
O projeto foi subdividido em três subsistemas, contendo um pacote administrativo,
pertinentes ao Administrador e ao Coordenador (gestores da aplicação), o pacote Cliente referente ao Egresso e Empresa, e o pacote Utilitário. Cada pacote representa
um subsistema do projeto.
A figura 26 mostra a divisão em pacotes do Sistema de Egressos
Figura 26: Diagrama de Pacotes
As funcionalidades comuns aos subsistemas Administrador e Cliente estão contidas
44
no pacote Utilitário, com o intuito de prover a reusabilidade, ou seja, a utilização dessas funcionalidades em outros projetos.
4.2 DIVISÃO EM CAMADAS
Utilizando o conceito de divisão em camadas, baseado na arquitetura .NET de
padrões 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 apresentação onde o usuário terá a interface de interação com o sistema, podendo, a todo o momento, trocar informações com o mesmo.
Services Interface (Facade): conhecida como Fachada, esta camada faz a interface entre a camada de apresentação (UI) e a camada de Negócios (Business Layer)
onde é utilizada uma forma simples para acessar vários objetos do negócio.
Business Component: onde são realizadas as regras de negócios do sistema.
Também conhecida como Business Layer, esta camada trata as principais funcionalidades e complexidades do sistema.
Entity : esta camada representa todas as classes ou estruturas do sistema. Aqui os
objetos são estruturados para poderem ser criados em outras camadas da aplicação.
Data Access: didaticamente conhecida como Gerência de Dados, esta camada
possui todas as operações que o sistema necessitará para trocar mensagens ou informações com o banco de dados físico [CUNNINGHAM, 2003].
A seguir, as figuras 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 estão 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 características. A figura 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 dicionário de dados do diagrama de classes da camada Entity do pacote administrador encontra-se no Anexo A.
4.3.2 CAMADA DE NEGÓCIOS (BUSINESS), ADMINISTRADOR
O diagrama de classes da camada Business (Negócios) representa todas as regras de negócios e operações dos objetos, mostrando suas relações, dependências,
agregações e composições. A figura 30 representa o diagrama de classes da camada
de negócios do pacote Administrador.
Figura 30: Diagrama de Classes da camada Business, pacote Administrador
O dicionário de dados do diagrama de classes da camada Business do pacote administrador encontra-se no Anexo A.
48
4.3.3 CAMADA DE ACESSO A DADOS (DATA ACCESS), ADMINISTRADOR
O diagrama de classes da camada Data Access (Acesso a Dados) representa
todos os objetos e suas características. A figura 31 representa a classe de acesso à
dados do pacote Administrador.
Note que todas as classes dependem da classe genérica, que é onde a aplicação
acessa o banco de dados fisicamente, por através de um conjunto de classes (Dll’s)
que foram abstraídas na implementação do projeto.
Figura 31: Classe Genérica que efetua a conexão com o banco de dados
A figura 32 representa o método SalvarDados, utilizado no exemplo, recebe os parâmetros vindos de outras classes da camada Data Access, retornando em uma estrutura de lista (vetor) os possíveis resultados da consulta física.
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 negócios (Business) e entidades (Entity), contemplando todas
as funcionalidades da camada de negócios. Apenas contêm as operações e o seu
tipo de retorno, deixando toda a implementação lógica na camada de negócios.
A figura 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 USUÁRIO (UI), ADMINISTRADOR
O diagrama de classes da camada User Interface (Interface com o Usuário) representa todas as classes desta camada. A figura 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 características. A figura 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 dicionário de dados do diagrama de classes da camada Entity do pacote cliente
encontra-se no Anexo A.
53
4.3.7 CAMADA DE NEGÓCIOS (BUSINESS), CLIENTE
O diagrama de classes da camada Business (Negócios) representa todas as regras de negócios e operações dos objetos, mostrando suas relações, dependências,
agregações e composições. A figura 36 representa o diagrama de classes da camada
de negócios do pacote Cliente 36.
Figura 36: Diagrama de Classes da camada Business, pacote Cliente
O dicionário 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), CLIENTE
O diagrama de classes da camada Data Access (Acesso a Dados) representa
todos os objetos suas características. A figura 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 pacote Administrador, onde estão implementadas as classes de acesso ao banco de
dados físico 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 negócios (Business) e entidades (Entity), contemplando todas
as funcionalidades da camada de negócios. Apenas contêm as operações e o seu
tipo de retorno, deixando toda a implementação lógica na camada de negócios.
A figura 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 USUÁRIO (UI) , CLIENTE
O diagrama de classes da camada User Interface (Interface com o Usuário) representa todas as classes desta camada. A figura 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 figura 40 mostra que ao ser inserida uma oportunidade no sistema, atinge o estado pendente. Após passar pelo processo de validação, onde ela poderá ou não ser
visualizada pelos egressos, ele atingirá os estados: válido ou inválido exclusivamente
40.
Figura 40: Diagrama de Estados do Objeto Oportunidade
58
4.5 DIAGRAMA DE NAVEGAÇÃO
O diagrama de navegação permite a visualização do fluxo principal do sistema
proposto. Muitas vezes não é possível, antes da implementação do projeto, traçar
exatamente todas as possíveis telas e funcionalidades que a aplicação terá. A figura
41 representa o diagrama de navegação do Sistema 41.
Figura 41: Diagrama de Navegação
4.6 DIAGRAMA RELACIONAL DO BANCO DE DADOS
O diagrama relacional mostra as relações que ocorrem nas tabelas (chamadas
de entidades na fase de modelagem). Através deste, é possível saber como será a
persistência física de todas as informações que serão inseridas, atualizadas ou removidas do Sistema de Egressos. A figura 42 representa o diagrama relacional do banco
de dados 42.
59
Figura 42: Diagrama Relacional do Banco de Dados
O dicionário de dados do diagrama relacional do banco de dados encontra-se no
Anexo A deste.
60
5
DIAGRAMAS DE SEQUÊNCIA
Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Em síntese, ele representa
as interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama
de Casos de Uso e dá ênfase a ordenação temporal em que as mensagens são
trocadas entre os objetos de um sistema. Entende-se por mensagens, os serviços
solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações
[HTTP://PT.WIKIPEDIA.ORG].
O Sistema de Egressos apresentou os seguintes Diagramas de Sequência:
5.1 ADMINISTRADOR
Seguem os diagramas de sequência referentes aos Casos de Uso do ator administrador.
5.1.1 MANTER CURSO
O Caso de Uso Manter Curso engloba as operações de inserir, alterar e desativar
um curso no portal de acordo com os mesmos oferecidos pela Instituição de ensino.
Assim, a figura 43 visa manter um curso no Sistema de Egressos 43.
61
Figura 43: Diagrama de Sequência - Manter Curso
62
5.1.2 MANTER COORDENADOR
O Diagrama de Sequência apresentado na figura 44 visa manter um coordenador
no Sistema de Egressos 44.
Figura 44: Diagrama de Sequência - Manter Coordenador
5.1.3 MANTER FÓRUM (INCLUI GERENCIAR FÓRUM)
Incluir "Gerenciar Fórum"significa que o ator administrador tem as mesmas permissões e funcionalidades que o ator coordenador, porém, somente o coordenador
poderá inserir um "Fórum".
Os diagramas de sequência "EXCLUIR FÓRUM, TÓPICO, MENSAGEM"e "ALTERAR FÓRUM, TÓPICO, MENSAGEM"não foram apresentados pela semelhança ao
diagrama "INSERIR FÓRUM, TÓPICO, MENSAGEM".
O Diagrama de Sequência apresentado na figura 45 visa inserir um fórum, um
tópico ou uma mensagem no Sistema de Egressos 45.
63
Figura 45: Diagrama de Sequência - Inserir Tópico, Fórum, Mensagem
5.2 COORDENADOR
Seguem os diagramas de sequência referentes aos Casos de Uso do ator coordenador.
5.2.1 AVALIAR EMPRESA
O Diagrama de Sequência apresentado na figura 46 visa avaliar uma empresa no
Sistema de Egressos 46.
64
Figura 46: Diagrama de Sequência - Avaliar Empresa
5.2.2 VALIDAR OPORTUNIDADE (INCLUI NOTIFICAR EGRESSO)
O Diagrama de Sequência apresentado na figura 47 visa avaliar uma nova oportunidade lançada por uma empresa devidamente cadastrada Sistema de Egressos 47.
5.2.3 GERENCIAR FÓRUM
O diagrama de sequência "GERENCIAR FÓRUM"não foi apresentado pela semelhança ao diagrama de sequência "MANTER FÓRUM"do Caso de Uso "Administrador". Diferem-se na ação de inserir um novo fórum, podendo somente o administrador
executar tal sequência na aplicação.
65
Figura 47: Diagrama de Sequência - Validar Oportunidade
66
5.2.4 GERAR RELATÓRIO
O Diagrama de Sequência apresentado na figura 48 visa gerar relatórios de diversos dados, como por exemplo, egressos contratados num determinado período,
quantidade de vagas oferecidas num determinado período, quantitativos de vagas no
momento, quantidade de empresas cadastradas, etc 48.
Figura 48: Diagrama de Sequência - Gerar Relatório
5.3 EMPRESA
Seguem os diagramas de sequência referentes aos Casos de Uso do ator empresa.
5.3.1 MANTER DADOS EMPRESA
O Diagrama de Sequência apresentado na figura 49 visa manter os dados (inserir,
alterar ou excluir) do perfil de uma empresa devidamente castrada no Sistema de
Egressos 49.
67
Figura 49: Diagrama de Sequência - Manter Dados Empresa
5.3.2 MANTER OPORTUNIDADE
O Diagrama de Sequência apresentado na figura 50 visa manter os dados (inserir, alterar ou excluir) do perfil de um egresso devidamente castrado no Sistema de
Egressos50.
5.4 EGRESSO
Seguem os diagramas de sequência referentes aos Casos de Uso do ator egresso.
5.4.1 MANTER DADOS EGRESSO
O Diagrama de Sequência apresentado na figura 51 visa manter os dados (inserir, alterar ou excluir) do perfil de um egresso devidamente castrado no Sistema de
Egressos51.
68
Figura 50: Diagrama de Sequência - Manter Oportunidade
5.4.2 VISUALIZAR OPORTUNIDADE
O Diagrama de Sequência apresentado na figura 52 visa visualizar as oportunidades enviadas pelas empresas cadastradas no portal e validadas pelo coordenador
52.
5.4.3 INTERAGIR FÓRUM
O diagrama de sequência "INTERAGIR FÓRUM"não foi apresentado pela semelhança ao diagrama de sequência "GERENCIAR-FÓRUM"do Caso de Uso "COORDENADOR". Nesse caso os dois atores poderão inserir, alterar e excluir tópicos e
mensagens.
69
Figura 51: Diagrama de Sequência - Manter Dados Egresso
Figura 52: Diagrama de Sequência - Visualizar Oportunidades
70
6
PADRONIZAÇÃO
padronização da interface com o usuário, em sua maioria, é descrita em um arquivo CSS, linguagem de estilos para HTML e XML.
Topo Superior (Master Page):
Imagem azul com figuras dissolvidas de alunos à esquerda.
Logo da instituição dissolvida à direita.
Corpo das Telas (padrões 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, normal, tamanho 10, cor preta;
Telas centralizadas no centro da tela do usuário;
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: Botões e Imagens do Sistema
72
7
PROTOTIPAGEM
Um protótipo pode ser considerado uma implementação concreta, embora parcial,
de um programa. Os protótipos podem ser criados para explorar múltiplas questões
durante o desenvolvimento do software. Um protótipo de uma interface com o usuário
tem como principal objetivo conseguir captar as necessidades efetivas e concretas do
utilizado.
Através da prototipagem foi possível obter as reais necessidades das principais
vertentes da solução.
A figura 54 representa a página inicial do Sistema (Home). Através do menu disponível na parte superior, o usuário poderá navegar pelo sistema. Observe que, inicialmente, não temos todas as funcionalidades disponíveis no sistema. Para tanto, o
usuário necessitará autenticar-se na aplicação 54.
A figura 55 representa o formulário de cadastro de egressos. Este formulário possui um web service onde o usuário entra com o CEP e o sistema retorna o endereço
completo 55.
A figura 56 representa o formulário de cadastro de empresas. Assim como o formulário anterior, este formulário possui um web service onde o usuário entra com o
CEP e o sistema retorna o endereço completo 56.
As figuras 57, 58 e 59 estão relacionadas ao usuário administrador.
A figura 57 representa o formulário de cadastro de coordenador. Note o nome do
usuário autenticado, na barra de menu da aplicação. Nesta ocasião, um administrador
está autenticado 57.
A figura 58 representa o formulário de cadastro de cursos 58.
A figura 59 representa o formulário de consulta a cursos através de um componente web chamado GridView, onde podemos também alterar os dados do curso ou
desativá-lo 59.
73
Figura 54: Prototipagem - Principal
As figuras 60, 61, 62 e 63 estão relacionadas ao usuário coordenador.
A figura 60 representa a página inicial do usuário coordenador sendo exibida a
árvore do item consultas. Note o nome do usuário autenticado, na barra de menu da
aplicação. Nesta ocasião, um coordenador está autenticado 60.
A figura 61 representa o formulário de consulta às oportunidades lançadas, pelas
empresas, direcionadas ao curso no qual é coordenado pelo usuário autenticado. No
item Detalhes, o usuário poderá ver todos os detalhes da oportunidade 61.
A figura 62 representa a visão da oportunidade detalhada 62.
A figura 63 representa o formulário de consulta às oportunidades que estão em estado de espera. Esta situação ocorre quando a oportunidade, enviada pela empresa,
aguarda a validação do coordenador. Caso seja válida, a oportunidade é exibida para
todos os egressos do curso, caso contrário, a oportunidade é removida 63.
As figuras 64 e 65 estão relacionadas ao usuário Empresa.
A figura 64 representa o formulário onde são exibidas as oportunidades que já
foram cadastradas pelo usuário. Além de poder visualizar as mesmas, o usuário ainda
poderá excluir, caso seja necessário. Note o nome do usuário autenticado, na barra
74
Figura 55: Prototipagem - Cadastro de Egressos
de menu da aplicação. Nesta ocasião, uma empresa está autenticada 64.
A figura 65 representa o formulário de cadastro de oportunidades. Note que a
empresa poderá associar qualquer curso, que esteja disponível, para determinada
oportunidade 65.
A figura 66 representa o formulário para o egresso, autenticado neste momento,
onde são exibidas as oportunidades disponibilizadas pelo coordenador do seu curso.
Note o nome do usuário autenticado na barra de menu da aplicação 66.
75
Figura 56: Prototipagem - Cadastro de Empresa
Figura 57: Prototipagem - Cadastro de coordenador
76
Figura 58: Prototipagem - Cadastro de curso
Figura 59: Prototipagem - Exibição, Alteração e Desativação de Curso
77
Figura 60: Prototipagem - Exibição do menu do Coordenador
Figura 61: Prototipagem - Exibição de Oportunidades para Coordenador
78
Figura 62: Prototipagem - Exibição de Oportunidade detalhada
Figura 63: Prototipagem - Validação de Oportunidades
79
Figura 64: Prototipagem - Exibição de Oportunidade para Empresa
Figura 65: Prototipagem - Cadastro de Oportunidades
80
Figura 66: Prototipagem - Exibição de Oportunidades para Egresso
81
8
DOCUMENTOS DE
ARQUITETURA
8.1 VISÃO FÍSICA
A visão física (visão de contexto) mostra uma visão em alto nível do funcionamento
do sistema e da seqüência geral dos processos e é contemplada na figura 67. A visão
física do sistema mostra os nós (computadores clientes e servidores) e componentes
físicos (executáveis, bibliotecas e aplicações de bancos de dados) da solução 67.
Servidor WEB, onde a aplicação estará fisicamente disponível para os usuários, com
a. NET Framework 3.5 instalado, rodando um Windows 2003 com IIS 7.0, garantindo
o máximo de desempenho nesta plataforma.
Conectado ao .NET WEB Server, terá o Servidor de Banco de Dados MySQL
Server com a versão 5.0 (versão estável do banco) onde serão persistidas todas as
informações do sistema.
Também terá um servidor pop/smtp para envio/recebimento de emails, o Exchange
Server atendendo principalmente a demanda de envio de emails automáticos pelas
funcionalidades do sistema.
Pela intranet ou pela internet, o sistema poderá ser acessado por qualquer categoria de usuário.
82
Figura 67: Visão Física
8.2 VISÃO LÓGICA
A visão lógica descreve as mais importantes classes e a sua organização dentro
de pacotes de serviços e subsistemas, além da organização desses subsistemas em
camadas. Diagramas de pacotes podem ser incluídos para ilustrar o relacionamento
entre camadas, pacotes, subsistemas e classes que são significantes arquiteturalmente. As figuras 68 e 69 exibem a visão lógica do sistema de forma explicativa e
ilustrativa respectivamente, mostrando a sua organização em pacotes lógicos. Nesta
tabela são descritos os principais pacotes lógicos do sistema:
83
Figura 68: Pacotes Lógicos do Sistema
84
Figura 69: Visão Lógica
85
9
ESTRUTURA TECNOLÓGICA
A instalação física de um projeto de software necessita de uma infra-estrutura de
hardware e rede para troca de dados, além dos custos gerados pela hospitalidade da
solução.
9.1 HOSPEDAGEM DO SITE (FATORES A CONSIDERAR)
Segue abaixo alguns aspectos a considerar na hospedagem de uma web site:
Os custos fixos mensais, incluindo as taxas extras para instalação, gestão de domínios, mudança de provedor.
Mensalidades que variem de acordo com o número de acessos e o volume de
conteúdo publicado (se o site é muito acessado ou muito atualizado, tarifas extras
podem pesar no orçamento).
O preço do serviço nem sempre é o principal fator de avaliação, na medida em que
outros requisitos podem ser mais críticos para a hospedagem do site, de acordo com
os seus objetivos de negócio e a natureza do conteúdo.
A compatibilidade do servidor com diferentes tecnologias, seja Linux, ASP.NET,
Java, PHP, Perl, Ajax, scripts CGI e outras. O Suporte a conexões com bancos de
dados (MySQL, SQL Server).
O desempenho do sistema, a resposta dos programas e das páginas, a base de
equipamentos atualizada, o espaço em disco disponível, com discos redundantes.
Número de conexões de alta velocidade disponíveis, de forma que haja garantia
de que, ao cair uma delas, as outras manterão o(s) site(s) no ar. É importante também que a taxa de utilização destas conexões não esteja próxima do seu limite de
demanda.
86
Contabilização e análise, em tempo real, dos acessos dos usuários, com informações sobre número de visitas únicas, de páginas visitadas, sites de origem, palavraschave utilizadas em ferramentas de busca, tempo médio da visita, percursos mais
visitados.
Essas questões são de grande importância quando é feito um estudo de custos e
benefícios com a hospedagem de uma aplicação na WEB.
87
10
PROJETO DE SEGURANÇA
• Manutenção do sistema: realização de backups diários, manutenção de servidores web redundantes (para o caso de emergências), firewalls e medidas de
segurança (incluindo a segurança das instalações).
• Acesso ao sistema: A segurança do sistema será feita através do controle da
entrada de dados no sistema, ou seja, pela utilização do código de acesso e
senha. Todos os usuários serão cadastrados no banco de dados e terão um
código de acesso (login) e uma senha de no mínimo seis caracteres.
• Entrada de dados: os seguintes controles serão usados nos campos que receberão dados como a utilização de tabelas para facilitar os preenchimentos; tamanhos dos campos limitados ao tamanho do banco de dados; Se algum campo
obrigatório não for preenchido, o sistema apresenta uma mensagem avisando
que o campo deve ser preenchido; os campos das telas de entrada de dados
estão agrupados de acordo com a sua natureza.
• Backup: o backup do banco de dados será feito através de um script automático,
onde será realizado o backup dos dados do banco e dos arquivos da aplicação, caso seja feita alguma alteração de programa equivocada, o arquivo correto
poderá ser restaurado. O horário que será realizado a rotina de backup será
definida pela empresa que utilizará o sistema.
88
11
CONCLUSÃO
O Sistema de Egressos tem a proposta de prover a integração entre o mercado de
trabalho, instituição de ensino e egressos, possibilitando a interação online para fins
profissionais e/ou acadêmicos.
A organização na distribuição de oportunidades aos egressos permite que as mesmas sejam disponibilizadas de acordo com sua área pertinente, previamente selecionada pelo empregador.
Dessa forma, o Sistema de Egressos será um diferencial da instituição com os
mercados de trabalho, agregando aos seus egressos informações pertinentes as suas
respectivas áreas profissionais.
O desenvolvimento deste projeto teve como grande benefício o aprendizado para
o complemento da grade acadêmica e profissional, pois foi possível aplicar uma gama
considerável de conhecimentos adquiridos durante o curso de Ciência da Computação, praticando as atividades de analista de sistemas e programador.
De maneira geral, este sistema pode ser utilizado em qualquer Instituição de ensino que deseja manter vínculos 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 integração do Banco de Dados
da Instituição (Centro Universitário de Vila Velha - UVV) com o da aplicação, dessa
forma será possível importar os Coordenadores e Egressos para a aplicação sem a
necessidade de o ator Administrador inserir um coordenador ou o próprio egresso se
cadastrar, e o desenvolvimento do Schedulador (System Scheduler) - sistema gerenciador de tarefas previamente agendadas pelo administrador do sistema, funcionará
como uma espécie de Robô na execução de operações - para enviar mensagens aos
egressos quanto à chegada de datas de processos seletivos das vagas disponibilizadas pelas empresas devidamente cadastradas na aplicação.
89
12
REFERÊNCIAS
BIBLIOGRÁFICAS
[BEZERRA - 2002] - BEZERRA, Eduardo. Princípios de Análise e Projeto de
Sistemas com UML. 8a ed. Rio de Janeiro: Elsevier , 2002.
[HTTP://WWW.LINHADECODIGO.COM.BR] - NOGUEIRA, Admilson. UML - Unified Modeling Language - Introdução e Histórico.
Disponível em <http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=763>.
Acesso em 28 dez. 2008, 22:30:00.
[FALBO - 2002] - FALBO, Ricardo. Análise de Sistemas - Notas de Aula. Vitória:
UFES, 2002.
[FALBO - 2003] - FALBO, Ricardo. Projeto de Sistemas - Notas de Aula. Vitória:
UFES, 2003.
[HTTP://IMASTERS.UOL.COM.BR] - NOGUEIRA, Admilson. UML - Projetos de
Sistemas Orientados a Objetos. Disponível 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
Unified Modeling Language Reference Manual. Addison-Wesley, 1998.
[LARMAN - 2000] - LARMAN, Craig. Utilizando UML e Padrões: Uma Introdução
a Análise 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. Processo de Manutenção de Software Web apoiado pela modelagem IHC. Disponível 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 : definitivo, São Paulo: Makron Books, 2004.
90
CUNNINGHAM, Ward. Enterprise Solution Patterns Using Microsoft.NET. Microsoft, 2003.
JEZIERSKI, Edward A., Application Architecture for .NET: Designing Applications
and Services. Microsoft, 2002.
MARIANI, Rico; BOHLING, Brandon; SMITH, Connie U.; BARBER, Scott. Improving .NET Application Performance and Scalability. Microsoft, 2004.
WITHALL, Stephen. Software Requirement Patterns. Microsoft, 2007.
[FURLAN - 1998] - Furlan, José Davi. Modelagem de Objetos através da UML:
Análise e Desenho Orientados a Objetos, São Paulo: Makron Books, 1998.
[WWW.WIKIPEDIA.ORG] - Enciclopédia Livre.
Disponível em <http://pt.wikipedia.org/wiki/Engenharia de software >. Acesso em
17 out. 2008, 21:45:00.
[HTTP://PT.WIKIPEDIA.ORG] - Enciclopédia Livre.
Disponível em <http://pt.wikipedia.org/wiki/Diagrama de sequC3AAncia>. Acesso
em 20 out. 2008, 19:45:00.
91
ANEXO A
Este anexo contém as tabelas com os dicionários 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