2. Projeto 1 - Documentação - Projetos

UNIVERSIDADE FEDERAL DE SANTA CATARINA
Sistema Gerenciador Para Atribuição De Professores Às
Disciplinas
Jorge Berti
Orientador: Vitório Bruno Mazzola
Florianópolis, 09 de Julho de 2010.
2010/1
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
Sistema gerenciador para atribuição de professores às disciplinas
Jorge Berti
Trabalho de conclusão de curso apresentado como parte dos
requisitos para obtenção do grau de Bacharel em Ciências da
Computação .
Florianópolis, 2010
ERRATA
Folha
Linha
Onde se lê
Leia-se
2010/1
Jorge Berti
Sistema gerenciador para atribuição de professores às disciplinas
Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do
grau de Bacharel em Ciências da Computação.
Orientador(a): Vitório Bruno Mazzola
Banca examinadora
..................................
..................................
Dedico este trabalho à toda
minha família, minha namorada
Julie e especialmente ao meu
falecido pai, que infelizmente não
teve a oportunidade de ver seu
filho formado como Bacharel em
Ciências da Computação.
AGRADECIMENTOS
Agradeço primeiramente à instituição que
me acolheu, ao meu orientador Vitório Bruno
Mazzola, que aceitou ser meu orientador,
ajudando a definir o tema e ajudando no
desenvolvimento do trabalho em si e igualmente
aos demais membros da banca.
EPÍGRAFE
“O sucesso é construído de 99 por cento de fracasso.”
Soichiro Honda
RESUMO
ABSTRACT
SUMÁRIO
Introdução ................................................................................................................ 11
1 Planejamento do projeto...................................................................................... 12
2 O Padrão MVC ...................................................................................................... 21
2.1 História do padrão MVC ................................................................................................. 21
2.2 O que é o padrão MVC .................................................................................................................... 21
2.3 Motivação para o uso do padrão MVC ............................................................................................. 22
3 Ambiente de desenvolvimento C# ...................................................................... 23
3.1 Sobre o C#..................................................................................................................... 23
3.2 Porque usar o C# ........................................................................................................... 24
4 Banco de dados Postgre SQL ............................................................................. 25
4.1 Sobre o PostgreSQL ...................................................................................................... 25
4.1.1 Histórico ...................................................................................................................... 25
4.1.2 Características ............................................................................................................ 25
4.1.3 Custos para desenvolvê-lo .......................................................................................... 26
4.2 Porque usar o Postgre SQL ........................................................................................... 26
5 Sistema gerenciador de professores ................................................................. 27
5.1 O problema .................................................................................................................... 27
5.2 Motivação ...................................................................................................................... 27
5.3 Pré requisitos ................................................................................................................ 27
5.4 Modelagem .................................................................................................................... 27
Considerações finais ..................................................................................................
Anexo 1 – Cópias de algum documento....................................................................
Anexo 2 – Cópias de outro documento .....................................................................
INTRODUÇÃO
Hoje, a coordenação de curso de Ciências da Computação faz a inscrição dos
professores com as disciplinas ministradas de forma não automatizada e sem uma
política de tentar alternar quais professores, dentro dos seus domínios de disciplinas
afins , lecionarão uma disciplina em um determinado semestre.
Esse cenário causa certa estagnação, a partir do momento em que há pouca
alternância em relação à qual professor leciona uma disciplina. Com a criação desse
sistema, professores que possuem interesse em lecionar uma disciplina terão a
oportunidade de fazê-lo, através de um método sistemático, imparcial e livre de
qualquer tendencionismo.
Este trabalho consiste na documentação e implementação de um sistema para
gerenciar quais professores lecionarão quais disciplinas em um determinado semestre,
baseado em algumas políticas pré definidas que serão apresentadas no decorrer do
trabalho.
Além do escopo principal, serão apresentadas features, tais como envio , via email para cada professor, com sua(s) disciplina(s) que lhe foram atribuídas, uma
interface web para “candidatura” de um professor para ministrar uma disciplina de sua
área de atuação.
Para o desenvolvimento do sistema usaremos a linguagem C#, através da IDE
Visual Studio, fornecido graças a uma parceria entre a UFSC e a Microsoft, o banco de
dados será o Postgre, por ser um banco robusto, gratuito e de nosso domínio de
conhecimento e a técnica de implementação será orientada a objetos, usando como
padrão de projeto o MVC(Model View Controller).
11
1 PLANEJAMENTO DO PROJETO
No semestre 2010.1, cursamos a disciplina “Planejamento e Gestão de Projetos”.
Nessa disciplina, aprendemos como devemos elaborar um plano de projetos .
Um plano de projetos é uma estrutura de informações dividas seções, em que cada uma
dessas seções são definidas características do projeto, como por exemplo, o escopo e os
pré-requisitos do projeto.
Termo de Abertura de Projeto
Titulo do Projeto
Sistema de gerenciamento de professores e
disciplinas
Aluno(s)
Jorge Berti
Data
06/05/2010
Justificativa
Tomamos a iniciativa de desenvolver esse
sistema porque, hoje em dia, na UFSC o
gerenciamento das disciplinas e os professores
que as ministram é feita de maneira manual.
Existe também o problema na estagnação de
quem ministra as disciplinas, ou seja, não há
uma renovação, sistematizada, de diferentes
professores ministrarem uma mesma disciplina
a cada semestre.
Descrição
Desenvolver um sistema que faça o
gerenciamento das disciplinas, na UFSC, bem
como os professores que a ministram.
Objetivo(s)
Desenvolver um sistema que faça o
gerenciamento das disciplinas, na UFSC, bem
como os professores que a ministram.
Desenvolver também sua documentação para
apresentação em TCC.
Será satisfatório, para o sucesso do projeto,
entregar um documento de TCC completo que
seja aprovado pela banca, bem como também o
sistema cumprir com os requisitos acordados.
12
Premissas
Será necessário o acesso a dados dos
professores, como sua identificação, disciplinas
de sua área
Restrições
O trabalho deverá ser apresentado até a metade
do semestre em que estivermos matriculados na
disciplina de Projetos 2.
Estimativa do custo total
(R$)
Estimando o tempo gasto em que o
desenvolvedor vai gastar para desenvolver o
projeto e que esse tempo poderia ser usado para
trabalhar em outro lugar podemos estimar um
custo , de mão de obra, no valor de cerca de R$
8000,00.
Estimativa da duração total
Duração de 18 meses (3 semestres) com 3
marcos bem definidos:
1- Apresentação da proposta ao final
primeiro semestre.
2- Apresentação de um esboço
documentação do TCC, ao final
segundo semestre.
3- Apresentação do documento final
TCC, bem como o sistema em si,
final do terceiro semestre.
Partes interessadas e
responsabilidades
Orientador
Vitório Bruno Mazzola
Gerente de projeto
Jorge Berti
Interessado
Manuel Lino
do
da
do
do
ao
Assinaturas de aprovação
Referências
2. Escopo
2.1 Declaração do escopo
13
O projeto a ser desenvolvido é o TCC que aborda o desenvolvimento de
um sistema que gerencia as disciplinas de um curso de graduação ou pós-graduação.
Os critérios de aceitação são o de ter a documentação do TCC aprovada
pela banca, bem como sua defesa, o sistema em questão deverá ter a capacidade de
cadastrar e gerenciar disciplinas e seus professores.
O projeto é dividido em três marcos para entregas:
Ao final do primeiro semestre, deverá ser entregue a declaração do tema do TCC.
2- Ao término do segundo semestre, deverá ser entregue um
esboço da documentação final do TCC, bem como também um esboço dos códigos do
sistema.
Em meados do meio do terceiro semestre deverá ser entregue o documento final do
TCC, deverá ser feita a defesa do projeto e entrega do sistema funcionando, cumprido
com os requisitos definidos.
As restrições são que os 2 primeiros semestre possuem um tempo limite
de 6 meses e o terceiro semestre um tempo limite de 3 meses. O TCC somente será
concluído se a banca o aprovar.
2.2 EAP
1. Introdução do projeto
1.1 Definir tema.
1.2 Definir orientador.
1.3 Elaborar declaração do projeto.
2. Projeto 1 - Documentação
2.1 Elaborar esboço do trabalho final.
2.2 Reuniões com o orientador do TCC.
3. Projeto 1 - Desenvolvimento
3.1 Iniciar o desenvolvimento do sistema em questão.
3.2 Avaliar critérios de aceitação junto ao orientador de TCC.
4. Projeto 2 - Documentação
4.1 Finalizar o trabalho final e adequar mudanças propostas pelo
orientador de TCC.
4.2 Elaborar a apresentação para a banca avaliadora.
4.3 Apresentar o trabalho concluído a banca avaliadora.
5. Projeto 2 - Desenvolvimento
14
5.1 Finalizar o desenvolvimento do sistema.
5.1 Verificar a aceitação do mesmo.
2.3 Dicionário do EAP
Componente de EAP
Descrição
Definir tema.
Definir um tema para o TCC.
Definir orientador.
Definir um orientador segundo a
área do TCC escolhida.
Elaborar declaração de projeto.
Elaborar o plano de execução do
TCC.
Elaborar esboço do trabalho final.
Iniciar o desenvolvimento do TCC,
entregando um esboço inicial do
mesmo.
Reuniões com o orientador do TCC.
Reunir-se periodicamente com o
orientador para resolução de
duvidas e verificação de sugestões.
Iniciar o desenvolvimento do sistema.
Iniciar o desenvolvimento do
sistema e seus testes segundo
critérios
definidos
junto
ao
orientador.
Avaliar critérios de aceitação junto ao
orientador
Efetuar avaliações periódicas junto
ao orientador do TCC.
Finalizar o trabalho final.
Concluir o desenvolvimento do
TCC, adequando as normas da
UFSC.
Elaborar a apresentação para a banca
avaliadora.
Elaborar a apresentação para a
banca avaliadora, slides e texto a ser
falado.
Apresentar o trabalho para a banca
avaliadora.
Apresentação do TCC para a banca.
Finalizar
sistema.
Finalizar o sistema, com todos os
requisitos acordados previamente
o
desenvolvimento
do
15
funcionando.
Verificar a aceitação do sistema.
Testar o sistema.
2.4 Pacotes de trabalho.
Introdução ao projeto
ID: 1
Descrição do pacote de trabalho: Definição do tema, orientador e plano de execução
do TCC, além de registrar no sistema de projetos da UFSC.
Critério de aceitação: Tudo estar registrado no sistema de controle de TCCs da
UFSC conforme suas normas.
Entregáveis: Nenhum.
Premissas: Nenhum
Restrições: Nenhum
Projeto 1 – Documentação
ID: 2
Descrição do pacote de trabalho: Elaboração de um esboço inicial do TCC final a
ser entregue.
Critério de aceitação: O trabalho deve ser aceito pelo orientador do TCC.
Entregáveis: Esboço do TCC.
Premissas:
16
Restrições: O prazo deve ser cumprido bem como as normas de desenvolvimento da
universidade.
Projeto 1 – Desenvolvimento
ID: 3
Descrição do pacote de trabalho: Desenvolvimento de uma versão inicial do sistema
em questão.
Critério de aceitação: Deve ser aceito pelo orientador do TCC.
Entregáveis: Sistema parcialmente desenvolvido.
Premissas
Restrições: O prazo deve ser cumprido bem como as normas de desenvolvimento da
universidade.
Projeto 2 – Documentação
ID: 4
Descrição do pacote de trabalho: Complementação do esboço inicial com o restante
do trabalho, além das sugestões propostas pelo orientador.
Critério de aceitação: Deve ser aprovado pela banca avaliadora.
Entregáveis: Trabalho final de conclusão de curso.
Premissas:
Restrições: Deve ser cumprido o prazo de apresentação e entrega, bem como as
normas de desenvolvimento da universidade.
Projeto 2 – Desenvolvimento
ID: 5
Descrição do pacote de trabalho: Desenvolvimento da versão final do sistema.
Critério de aceitação: Deve ser aprovado pela banca avaliadora.
Entregáveis: Sistema totalmente desenvolvido com todas as funcionalidades
17
definidas.
Premissas:
Restrições: Deve ser cumprido o prazo de apresentação e entrega, bem como as
normas de desenvolvimento da universidade.
3. Tempo
3.1 Definição e Seqüenciamento das Atividades
ID
Atividade
Atividade(s) precedente(s)
1.1
Definição do tema
Nenhuma
1.2
Definição do orientador
1.1
1.3
Elaborar
projeto.
do
1.2
2.1
Elaborar esboço do trabalho
final.
1.3
2.2
Reuniões de planejamento
com orientador.
2.1
3.1
Iniciar desenvolvimento do
sistema.
2.2
3.2
Definir critérios de avaliação
junto ao orientador.
3.1
4.1
Finalizar o trabalho final.
3.2
4.2
Elaborar a apresentação
para a banca avaliadora.
4.1
4.3
Apresentar o trabalho a
banca avaliadora.
4.2
5.1
Finalizar o desenvolvimento
do sistema.
4.3
5.2
Verificar
5.1
declaração
a
aceitação
do
18
sistema.
3.2 Estimativa de Tamanho dos Pacotes de Trabalho da EAP
ID
Pacote de trabalho
Tamanho
estimado/Unidade
1
Introdução do projeto
4 meses
2
Projeto 1. Documentação
3 meses
3
Projeto 1. Desenvolvimento
3 meses
4
Projeto 2. Documentação
3 meses
5
Projeto 2. Desenvolvimento
3 meses
3.3 Estimativa de Duração de Atividades
ID
Atividade
Duração
estimada/Unidade
1.1
Definição do tema
1 mês
1.2
Definição do orientador
1 mês
1.3
Elaborar declaração do projeto.
2 meses
2.1
Elaborar esboço do trabalho final.
1.5 meses
2.2
Reuniões
de
orientador.
3.1
Iniciar desenvolvimento do sistema.
1.5 meses
3.2
Definir critérios de avaliação junto ao
orientador.
1.5 meses
4.1
Finalizar o trabalho final.
1.5 meses
4.2
Elaborar a apresentação para a banca
avaliadora.
1.5 meses
planejamento
com
1.5 meses
19
4.3
Apresentar
avaliadora.
o
trabalho
a
banca
1 dia
5.1
Finalizar o desenvolvimento do sistema.
1.5 meses
5.2
Verificar a aceitação do sistema.
1.5 meses
4. Custos
4.1 Estimativa de Custo
Item
Quantidade
Valor
unitário
Valor total
Mão de obra
18
R$1000,00
R$18000,00
18
R$100,00
R$1800,00
Custo
gerais
manutenção
de
4.2 Baseline de custo
Introdução ao projeto – R$ 4400,00
Projeto 1 – Documentação – R$ 3300,00
Projeto 1 – Desenvolvimento - R$ 3300,00
Projeto 2 – Documentação - R$ 3300,00
Projeto 2 – Desenvolvimento - R$ 3300,00
5. Qualidade
20
Normas, Políticas, Diretrizes:
Normas ABNT para documentação do projeto e trabalho de conclusão de curso.
Normas da UFSC para desenvolvimento, apresentação e aprovação do TCC.
Abordagem de garantia de qualidade:
Introdução do projeto – será avaliado pelo coordenador de projetos da UFSC ao
final do semestre referido.
Projeto 1 – Documentação e Desenvolvimento – será avaliado periodicamente
pelo orientador do TCC com uma avaliação final do esboço do projeto.
Projeto 2 – Documentação e Desenvolvimento – será avaliado periodicamente
pelo orientador do TCC e será feita uma avaliação final por uma banca
avaliadora a ser definida.
Abordagem de controle de qualidade:
Reuniões com o orientador de projeto, testes e validação de software.
6. Riscos
Risco
Probabili
dade
Impacto
Prioridade
Estratégia
de resposta
Ações de
prevenção
Problemas de
saúde com
desenvolvedo
r
Problemas de
saúde com
orientador
10%
Projeto
para
total
nenhuma
Visitas
regulares
ao médico
20%
Não
serão
feitas
avaliaçõ
es
média
Buscar
outro
orientador
Plano de
contingênci
a
21
2 O PADRÃO MVC
2.1 HISTÓRIA DO PADRÃO MVC
O MVC foi descrito originalmente em 1979 por Trygve Reenskaug, que então
trabalhava no Smalltalk na Xerox PARC. A implementação original é descrita em
detalhes no artigo "Applications Programming in Smalltalk-80: How to use Model–
View–Controller".
2.2 O QUE É O PADRÃO MVC
É um padrão de projeto que divide um projeto em 3 camadas (3-tier), chamadas :
Modelo, Visão e Controle.
2.2.1 Modelo
É a camada que define o modelo de dados usado pelo sistema, bem como as regras do
negócio.
Responsável pelo controle de acesso e tratamento dos dados vindos do banco. As
requisições de ações vinda da camada de controle, por exemplo, passam pela cama de
modelo, que realiza as operações junto à um banco de dados, por exemplo.
2.2.1 Visão
Essa camada é responsável por “renderizar” a camada de modelo, para criar um
meio de iteração com usuário. Conhecida com interface, ela é que recebe os estímulos
externos, como um clique com o mouse em um botão, e traduz essa ação como uma
mensagem para a camada de controle.
2.2.1 Controle
A camada de controle realiza as operações lógicas do programa, como se nessa
camada estivessem todas as engrenagens que fazem a “máquina” funcionar.
Essa camada recebe os estímulos da cama de visão, realizando operações lógicas
ou matemáticas, podendo retornar ao usuário uma resposta.
Pode também interagir com a camada de modelo, podendo, por
exemplo,consultar algum dado em banco para assim realizar alguma operação.
22
Diagrama conceitual do padrão MVC
2.2 MOTIVAÇÃO PARA USAR O PADRÃO MVC
Nossa motivação para utilizar o padrão MVC é que com o aumento da
complexidade das aplicações desenvolvidas, torna-se relevante a separação entre os
dados e a apresentação das aplicações. Desta forma, alterações feitas no layout não
afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.
23
3 Ambiente de desenvolvimento C#
3.1 O que é o C#
3.1.1 História
Segundo o site Wikipedia, durante o desenvolvimento da plataforma .NET, as
bibliotecas foram escritas originalmente numa linguagem chamada Simple Managed C
(SMC), que tinha um compilador próprio. Mas, em Janeiro de 1999, uma equipe de
desenvolvimento foi formada por Anders Hejlsberg, que fora escolhido pela Microsoft
para desenvolver a linguagem. Dá-se inicio à criação da linguagem chamada Cool. Um
pouco mais tarde, em 2000, o projeto .NET era apresentado ao público na Professional
Developers Conference (PDC), e a linguagem Cool fora renomeada e apresentada como
C#.
A criação da linguagem, embora tenha sido feita por vários programadores, é
atribuída principalmente a Anders, hoje um Distinguished Engineer na Microsoft. Ele
fora o arquiteto de alguns compiladores da Borland, e entre suas criações mais
conhecidas estão o Turbo Pascal e o Delphi.
3.1.2 Características
C# é uma linguagem de programação orientada a objectos criada pela Microsoft,
faz parte da sua plataforma .NET. A empresa baseou C# nas linguagens C++ e Java, e
ela é considerada a linguagem símbolo do .NET, por ter sido criada praticamente do
zero para funcionar na nova plataforma, sem preocupações de compatibilidade com
código existente. O compilador C# foi o primeiro a ser desenvolvido, e a maior parte
das classes da plataforma foram desenvolvidas nesta linguagem.
O C# é constituído por diversificadas características. Por exemplo, a linguagem
suporta ponteiros através da palavra reservada unsafe (código não-seguro), que é
obrigatório. Seu uso não é aconselhável, e blocos de códigos que o usam geralmente
requisitam permissões mais altas de segurança para poderem ser executados. As
operações aritméticas são verificadas contra transbordamento de dados. C# também
suporta as operações aritméticas básicas como adição, subtracção, multiplicação e
divisão. Esses símbolos são chamados operadores, e "operam" os valores das variáveis.
Um coletor de lixo também é suportado, um processo usado para a manutenção
de memória. Com este recurso, é possível recuperar a zona de memória que um
programa já não utiliza. Quando isto não ocorre pode acontecer a chamada perda de
memória, um erro comum que pode levar ao término não desejado do programa em
execução por esgotamento da memória livre.
Em C# não existe herança múltipla, ou seja, cada classe só pode herdar apenas
uma outra classe e não mais do que uma, no entanto é possível simular herança múltipla
utilizando interfaces. Assim, através da herança reduzimos código através da sua
reutilização..
Os destrutores são funções que se encarregam de realizar as tarefas que são
necessárias executar quando um objecto deixa de existir. Quando este já não está a ser
utilizado por nenhuma variável, deixa de ter sentido que esteja armazenado na memória,
portanto, o objecto deve ser destruído para liberar espaço. Para isto é chamada a função
destrutor. Os destrutores não podem ser definidos em estruturas, são apenas usados em
classes, e uma classe pode apenas ter um destrutor, eles não podem ser herdados ou
24
sobrecarregados, nem podem ser chamados pois são invocados automaticamente.
Também não pode ser modificado nem de algum modo ter parâmetros.
O C# suporta sobrecarga de métodos e de operadores, mas não suporta
argumentos padrão. As únicas conversões implícitas por padrão são conversões seguras
tais como, a ampliação de inteiros e conversões de um tipo derivado para um tipo base.
Não existem conversões implícitas entre inteiros e variáveis booleanas, enumerações e
ponteiros nulos. Qualquer conversão implícita definida pelo utilizador deve ser
explicita, apesar do C# ser baseado em variáveis estáticas é possível converter os tipos
de dados de uma variável, desde que essa conversão seja possível, pode ser convertido
qualquer tipo primitivo para string, mas nem sempre é possível o contrário. Uma string
que representa um número pode ser convertida para um tipo numérico, um número pode
sempre ser convertido para um número com mais bits, exemplo, um tipo byte (8 bits)
pode ser convertido para um do tipo int (32 bits). O contrário nem sempre é possível, de
um tipo com mais bits para representá-lo para um com menos bits. Desde que o valor
não exceda o limite do tipo menor, a conversão ocorrerá sem problemas, senão a
execução lança uma exceção. Nas conversões que sempre poderão acontecer, o mesmo
é feito automaticamente, sem precisar "forçar" nenhuma dessas conversões. A forma
mais simples de efectuar a conversão é usando a classe Convert, que implementa vários
métodos que permite a conversão de qualquer tipo para outro. Todas as conversões de
tipo são validadas em função do tipo real da variável em tempo de execução, sem
excepções.
Existem diversos mecanismos para criação de novos tipos de dados a partir de
tipos já existentes. Um desses mecanismos permite a criação de vectores. Os vectores
são todos derivados de uma mesma classe do ambiente .NET, o que significa
compartilhar várias operações, métodos e atributos. Os objectos e vectores são
necessariamente alocados dinamicamente na memória heap (área de memória
reservada) com o uso do operador new.
25
4 BANCO DE DADOS POSTGRE SQL
4.1 Sobre o POSTGRESQL
Hoje, o PostgreSQL é um dos SGBDs (Sistema Gerenciador de Bancos de
Dados) de código aberto mais avançados, contando com recursos como:










Consultas complexas
chaves estrangeiras
Integridade transacional
Controle de concorrência multi-versão
Suporte ao modelo híbrido objeto-relacional
Gatilhos
Visões
Linguagem Procedural em várias linguagens (PL/pgSQL, PL/Python,
PL/Java, PL/Perl) para Procedimentos armazenagem
Indexação por texto
Estrutura para guardar dados Georeferenciados PostGIS
4.1.1 HISTÓRICO
O PostgreSQL é um dos resultados de uma ampla evolução que se iniciou com o
projeto Ingres, desenvolvido na Universidade de Berkeley, Califórnia. O líder do
projeto, Michael Stonebraker, um dos pioneiros dos bancos de dados relacionais, deixou
a universidade em 1982 para comercializar o Ingres, porém retornou a ela logo em
seguida. Após seu retorno a Berkeley, em 1985, Stonebraker começou um projeto pósIngres com o objetivo de resolver problemas com o modelo de banco de dados
relacional. O principal problema era a incapacidade do modelo relacional compreender
“tipos” (atualmente, chamados de objetos), ou seja, combinações de dados simples que
formam uma única unidade.
O projeto resultante, chamado Postgres, era orientado a introduzir a menor
quantidade possível de funcionalidades para completar o suporte a tipos. Estas
funcionalidades incluíam a habilidade de definir tipos, mas também a habilidade de
descrever relações - as quais até este momento eram amplamente utilizadas, mas
completamente mantidas pelo usuário. No Postgres, o banco de dados "compreendia" as
relações e podia obter informações de tabelas relacionadas utilizando regras.
Iniciando em 1986, a equipe divulgou uma série de documentos descrevendo a
base do sistema e em 1988 o projeto possuía um protótipo funcional. A versão 1 foi
liberada para um grupo pequeno de usuários em junho de 1989, seguida pela versão 2
com um sistema de regras reescrito em junho de 1990. Para a versão 3, liberada em
1991, o sistema de regras foi reescrito novamente, mas também foram adicionados
suporte para múltiplos gerenciadores de armazenamento e um melhorado motor de
consultas. Já em 1993, Postgres havia crescido imensamente em popularidade e possuía
uma grande demanda por suporte e por novas funcionalidades. Após a liberação da
versão 4, a qual era uma simples versão de limpeza, o projeto foi oficialmente
abandonado pela Universidade de Berkeley.
26
Entretanto, devido ao fato do seu código fonte estar sob uma licença BSD, o seu
desenvolvimento foi continuado. Em 1994, dois estudantes de Berkeley, Andrew Yu e
Jolly Chen, adicionaram um interpretador SQL para substituir a linguagem QUEL
(desenvolvida para o Ingres) e o projeto foi renomeado para Postgres95. Com a
divulgação de seu código pela Internet, Postgres95 iniciou uma nova vida como
software open source.
Em agosto de 1996, Marc Fournier, Bruce Momjian e Vadim B. Mikheev
lançaram a primeira versão externa da Universidade de Berkeley e deram início à tarefa
de estabilizar o código herdado. Também em 1996, o projeto foi renomeado para
PostgreSQL a fim de refletir a nova linguagem de consulta ao banco de dados: SQL. A
primeira versão de PostgreSQL, a 6.0, foi liberada em janeiro de 1997. Desde então, um
grupo de desenvolvedores e de voluntários de todo o mundo, coordenados pela Internet,
têm mantido o software e desenvolvido novas funcionalidades.
As principais características acrescentadas nas versões 6.x são o en:MVCC
(Multiversion Concurrency Control – Controle de Concorrência Multiversões),
melhorias no SQL e novos tipos de dados nativos (novos tipos de datas e hora e tipos
geométricos).
Em maio de 2000 foi liberada a versão 7.0. As versões 7.x trouxeram as
seguintes novas funcionalidades: Write-Ahead Log (WAL), esquemas SQL, outer joins,
suporte a IPv6, indexação por texto, suporte melhorado a SSL e informações estatísticas
do banco de dados.
A versão 8.0 foi lançada em janeiro de 2005 e entre outras novidades, foi a
primeira a ter suporte nativo para Microsoft Windows (tradicionalmente, o PostgreSQL
só rodava de forma nativa em sistemas Unix e, em sistemas Windows - através da
biblioteca Cygwin). Dentre as muitas novidades da versão 8.x, pode-se destacar o
suporte a tablespaces, savepoints, point-in-time recovery, roles e Two-Phase Commit
(2PC). Em julho de 2009 foi lançada a versão mais recente: 8.4.
4.1.2 CUSTOS PARA DESENVOLVÊ-LO
A versão 8.3.0 do PostgreSQL apresenta mais de 570 mil linhas de código, o que
segundo o modelo COCOMO exigiria um esforço estimado de pouco mais de 157
pessoas-ano para o seu desenvolvimento. Estima-se que o tempo necessário para uma
empresa desenvolver um software deste porte é de 3 anos e meio (aproximadamente 43
meses), o que corresponderia a cerca de 43 programadores trabalhando em paralelo.
Considerando que o salário médio de um programador nos EUA é de cerca de US$
56.286,00 por ano, e multiplicando por 2,4 para considerar custos adicionais além do
salário dos programadores, o custo estimado para o desenvolvimento de um software do
porte do PostgreSQL 8.3.0 é de US$ 21.220.945,00.
4.2 PORQUE USAR O POSTGRE SQL
O PostgreSQL foi adotado por nós por ser um banco de dados muito poderoso e
robusto, não devendo em nada aos outros bancos de dados consagrados, como o Oracle, por
exemplo.
Assim como as distribuições Linux, ele possui forte participação da comunidade em seu
desenvolvimento e manutenção.
Outro fator importante é o de que estamos um tanto habituados a trabalhar com esse
tipo de banco, reduzindo assim com qualquer perda de tempo em alguma curva de
aprendizado caso adoestássemos outro tipo de banco.
27
Além do que foi citado, não podemos deixar de citar que o PostgreSQL é um banco de
dados gratuito, de código aberto, diminuindo então os gastos com essa áera do nosso
problema durante o desenvolvimento desse projeto.
5 SISTEMA GERENCIADOR DE PROFESSORES
5.1 O PROBLEMA
A Coordenação dos cursos de Ciências da Computação e Sistemas de
Informação não possuir um sistema computacional para poder gerenciar a atribuição de
professores que ministrarão as disciplinas.
A falta desse sistema pode causar uma maior lentidão do processo, bem como
uma maior dificuldade em evitar conflitos de horários , por exemplo: verificar um
conflito de horário entre duas ou mais disciplinas que um professor for ministrar.
Um outro problema que propõe-se a tentar resolver é a de um professor ficar
muito tempo ministrando uma determinada disciplina, não dando chance à outros
professores, da mesma área de atuação, de ministrar tal disciplina. Com esse
gerenciados, esse problema será resolvido de forma democrática e imparcial, através de
políticas bem definidas
5.2 MOTIVAÇÃO
A principal motivação que nos leva ao desenvolvimento deste trabalho é que ele
envolve muitos conceitos aprendidos ao longo do curso e que estes pertencem às nossas
áreas de interesse, como por exemplo: planejamento de projeto, análise de projeto,
levantamento de requisitos, modelagem do programa e da base de dados, e por fim, o
desenvolvimento em si.
Outro importante motivo é o de poder aproveitar a oportunidade de pode dar um
retorno à nossa instituição, que teve o empenho em poder ajudar em nossa formação
acadêmica. Sendo assim, nossa forma de agradecer esse empenho é o de desenvolver
esse sistema com o intuito de poder facilitar o trabalho da coordenação de nosso curso e
,quem sabe, o trabalho da coordenação de outros cursos dentro da UFSC
5.3 PRÉ REQUISITOS





O sistema deverá ser capaz de adicionar, remover, exibir e editar dados
dos professores agregados ao curso.
O grupo de disciplinas afins (GPDA) de um professor também deverá ser
de possível edição.
O sistema deverá ser capaz de adicionar, remover, exibir e editar dados
das disicplinas agregados ao curso.
O sistema deverá ser capaz de atribuir os professores às disciplinas que
são de seu domínio de disciplinas afins.
Deverá resolver problemas de consistência, em que um professor não
poderá ministrar uma disciplina fora de sua área de atuação, nem
ministrar disciplinas em mesmo horário.
28

Deverá gerar relatórios das disciplinas atribuídas aos professores, sendo
possível também gerar relatórios individuais para cada professor, ao
selecionar um professor.
5.4 MODELAGEM
5.4.1 DA MODELAGEM DA BASE DE DADOS
A principio as entidades de nossa base serão simples. Serão unidades:




Professores, comporto por um ID, nome, identificação interna e uma id, que será
uma chave estrangeira para uma tabela que representa uma relação do tipo
muitos para muitos com a tabela de disciplinas.
Disciplinas, composta por um id, nome, id para a área da disciplina(hardware,
POO, matemática discreta...etc), horário da disciplina
Tabela realacional entre professores e disciplinas, com id própria, idprofessor,
iddisciplina
Tabela áreas, que podem ser, por exemplo, hardware, programação e matemática
discreta, com id e o nome da área
Diagrama ER da base de dados
29