Centro Universit

ario de An
apolis - UniEVANGELICA
Cursos Superiores de Computac
ao

SISTEMA GERENCIADOR DE HORAS

COMPLEMENTARES (SIGLOC)

RONIE
DE
NOGUEIRA

ANAPOLIS
JUNHO 2011

JESUS

RONIE DE JESUS NOGUEIRA

SISTEMA GERENCIADOR DE HORAS

COMPLEMENTARES (SIGLOC)

Trabalho de conclusao de curso I apresentado

como requisito parcial `a obtencao do grau
de Bacharel em Sistemas de Informacao do
Programa de Graduacao dos cursos superiores de Computacao, Centro Universitario de

Anapolis - UniEVANGELICA.
Orientador: Luciana Nishi

ANAPOLIS
JUNHO 2011

Termo de Aprova
c
ao

RONIE DE JESUS NOGUEIRA

SISTEMA GERENCIADOR DE HORAS COMPLEMENTARES

(SIGLOC)

Trabalho de conclusao de curso I aprovado como requisito parcial para obtencao do grau
de Bacharel em Sistemas de Informacao do Programa de Graduacao dos cursos superiores

de Computacao, Centro Universitario de Anapolis - UniEVANGELICA,

pela seguinte
banca examinadora:

Profa. Ma. Luciana Nishi

UniEVANGELICA

Prof. Ms. Rogerio Sousa e Silva

UniEVANGELICA

Profa. Esp. Noeli Antonia Pimentel

UniEVANGELICA

Anapolis, 03 de junho de 2011

Dedicat
oria

A quem eu dedico,
Dedico esse trabalho primeiramente a Deus que sempre me deu forcas pra lutar nos momentos de adversidade, minha mae que nao se faz mais presente mas
que se nao fosse por ela eu nao estaria aqui hoje, meu
pai e a toda minha familia e amigos.

Agradecimentos

Agradeco a minha orientadora por me guiar nessa

jornada e a todas as pessoas que contribuiram diretamente e indiretamente para a conclusao desse trabalho.

ii

Sum
ario

Lista de Siglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1

Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Referencial Te
orico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1

Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Processos e Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.1
4.1.1.1
4.2
4.2.1

UML (Unified Modeling Language) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3

MVC (Model - View - Controller) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4

Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5

Padroes Web W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Refer
encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iii

Ap
endice A -- Primeiro ap
endice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iv

Lista de Siglas

UML

Unified Modeling Language

MVC

Model View Controller

W3C

World Wide Web Consortium

SGBD

Sistema Gerenciador de Banco de Dados

XHTML

Extensible Hypertext Markup Language

HTML

HyperText Markup Language

XML

Extensible Markup Language

CSS

Cascading Style Sheets

UML MVC W3C SGBD XHTML HTML XML CSS

Resumo

Este projeto propoe a criacao de um sistema que tem como objetivo simplificar e facilitar a
administracao de horas complementares dos discentes dos cursos superiores de computacao

do Centro Universitario de Anapolis - UniEVANGELICA.

Visa alcancar este objetivo
atraves da explicacao dos estudos bibliograficos nos conceitos pertinentes a Engenharia
de Software (Processo, metodologia, UML, Analise, Projeto), Banco de Dados, Padroes
de Desenvolvimento Web e de Padroes de Projeto.
Palavras-chave: Engenharia de Software; Analise de Desenvolvimento de Sistemas; Open
Up; UML; Banco de Dados; W3C.

2.1

Objetivos

Objetivos Gerais

Tem se o objetivo de desenvolver um sistema para secretaria dos cursos superiores

de computacao do Centro Universitario de Anapolis - UniEVANGELICA,

a fim de solucionar o problema da administracao das horas complementares exigida na grade curricular
dos cursos. Aplicando de forma pratica os conceitos adquiridos durante a graduacao na
analise e desenvolvimento de uma aplicacao real.
Pesquisas serao realizadas no intuito de definir uma metodologia de desenvolvimento a ser utilizada, a descricao do plano de projeto para este problema e todos os
artefatos necessarios (modelagem de negocio, diagrama de casos de uso, especificacao de
casos de uso, modelo de domnio, diagrama de classe, diagrama de seq
uencia DER, MER,
arquitetura do sistema).
Outro resultado deste trabalho sera a analise dos padroes de projeto, mostrar a
importancia dos mesmos para o desenvolvimento web, que e um tipo de desenvolvimento
diferente das aplicacoes desktop. aplicacoes web sao executadas diretamente de um navegador e sao aplicacoes que rodam em qualquer sistema operacional, ou seja, aplicacoes
multiplataformas.
Mostrar a aplicabilidade do HTML, XHTML e o CSS e tambem demonstrar as
vantagens de se utilizar um padrao de arquitetura de software para desenvolvimento de
uma aplicacao web. Utlizar o padrao de desenvolvimeto web W3C para facil manutencao
do sistema, separando o conte
udo (textos, imagens e dados) e componentes de interface
e tambem nao juntando a parte de modelo, visao e controle do sistema.

2.2

Objetivos Especficos

Desenvolver um software que solucione o problema da administracao das horas complementares dos discentes;
Buscar e usar uma metodologia de desenvolvimento que melhor se encaixe no contexto do software;
Produzir os artefatos, documentacao, arquitetura e modelagem de negocio do sistema;
Desenvolver o sistema seguindo o padrao de desenvolvimento web W3C para facil
manutencao;
Aplicar o conceito do padrao de arquitetura de software MVC durante toda a fase
de analise e desenvolvimento do software.

Justificativa

A tecnologia sempre fez parte da historia do homem, desde quando criaram as

primeiras ferramentas para auxiliar nas tarefas e trabalhos de seu cotidiano. O homem
sempre procurou usar a tecnologia em seu proprio benefcio, buscando desenvolver algo
para facilitar nos seus afazeres. E toda essa inovacao tecnologica tem atingido nao apenas
uma area especfica, mas todos os flancos da vida humana, desde trabalhos simples como
uma dona de casa que usa o avanco tecnologico a seu favor como um medico que usa as
mais sofisticadas ferramentas para ser mais preciso em seus diagnosticos e resultados.
A tecnologia vem facilitando cada vez mais a vida do ser humano, nao importa
qual sua finalidade, o homem sempre procura desenvolver algo que facilite seu cotidiano.
Com o avanco tecnologico e o crescimento da informacao surgem novas solucoes para
administrar e lidar com todos esses dados, e a tecnologia da informacao surgiu com esse
proposito de gerar e usar a informacao.
Pode-se conceituar a Tecnologia da Informacao como recursos tecnologicos e computacionais para geracao e uso da informacao (REZENDE; ABREU, 2008).
Ainda Segundo (REZENDE; ABREU, 2008) Tecnologia da Informacao pode ser todo
e qualquer dispositivo que tenha capacidade para tratar dados e ou informacoes, tanto de
forma sistemica como esporadica, quer esteja aplicada ao produto, quer esteja aplicada
no processo.
Com a inovacao tecnologica computacional muitas tarefas que levavam muito
tempo para serem executadas, estavam sendo automatizados com a ajuda da tecnologia
da informacao. Solucoes foram surgindo e a cada novo dia tarefas que eram realizadas
por servicos manuais ou por ferramentas que nao eram feitas especialmente para tal finalidade com o tempo eram substitudas por um software que trazia consigo a solucao para
realizar uma tarefa x. Para desenvolver uma aplicacao com essa finalidade e necessario
o planejamento de todo o projeto, ou seja, uma metodologia de desenvolvimento, pois o
nao planejamento do projeto pode resultar em uma ferramenta defeituosa, e ate mesmo

no fracasso do sistema.
Procurar uma metodologia de desenvolvimento para um projeto real e algo que
faz parte de qualquer projeto de software e no caso deste projeto nao e diferente. Tem
se o proposito de construir uma aplicacao que auxilie a secretaria de cursos superiores de
computacao quanto ao registro de horas complementares dos discentes, e o uso de uma
metodologia de desenvolvimento e uma arquitetura apropriada sao itens necessarios para
o sucesso desse sistema.
Este trabalho sera de grande ajuda as pessoas que se interessam ou trabalham na
area de desenvolvimento e analise de sistemas, e tambem para demonstrar a importancia
de se utilizar um padrao de arquitetura de software e um padrao de desenvolvimento para
facil manutencao do sistema apos sua conclusao.

Referencial Te
orico

Apresentacao do embasamento teorico necessario para o desenvolvimento do projeto, dissertando os conceitos de engenharia de software, ciclos de vida, banco de dados
e padroes de desenvolvimento web passando por todas as etapas do desenvolvimento de
software. Conceitos de varios autores sobre o assunto.

4.1

Engenharia de Software
A engenharia tem o significado de maquinar, inventar e produzir, ou seja, usar

o conhecimento para construir algo, seja um software, casa, predio com base cientifica e
emprica. A engenharia e a arte das construcoes aliando a teoria e pratica. E a engenharia
de software nao e diferente ela surgiu para auxiliar em todos os aspectos na construcao
de um software.
A engenharia de software e uma disciplina da engenharia que se ocupa de todos os
aspectos da producao de software, desde os estagios iniciais de especificacao do sistema ate
a manutencao desse sistema, depois que ele entrou em operacao (SOMMERVILLE, 2007).
Engenharia de software e metodologia para desenvolvimento de solucoes de software, ou seja, roteiro que pode utilizar diversas tecnicas (REZENDE, 2006).
A engenharia de software tem como objetivo sistematizar a criacao, a manutencao,
a evolucao e a recuperacao de produtos intensivos de software, de modo que os prazos
estipulados sejam cumpridos e os custos estimados tambem.
A engenharia de software e os seus metodos proporcionam os detalhes de como
construir um software e todos esses metodos envolvem um conjunto de tarefas como:
planejamento de projeto, analise de requisitos de software e de sistemas, projetos da
estrutura de dados, arquitetura de software, codificacao, testes e manutencao do sistema.
Um metodo de engenharia de software e uma abordagem estruturada para o

desenvolvimento de software, cujo objetivo e facilitar a producao de software de alta

qualidade (SOMMERVILLE, 2007).

4.1.1

Processos e Desenvolvimento de Software

Segundo (SOMMERVILLE, 2007) um processo de software e um conjunto de ativi-

dades e resultados associados que levam a producao de um produto de software. Isto e

o processo de software e um conjunto de atividades e resultados associados que levam `a
producao de um produto de software.
Embora existam varios processos de software, ha algumas atividades em comum
entre eles, como: Especificacao de software, projeto e implementacao de software, validacao de software e evolucao de software, onde:
Especificacao de software: onde e definida a funcao do software, e todas as restricoes
em sua operacao;
Projeto e implementacao de software: e onde acontece a producao do software de
acordo com todas as suas especificacoes;
Validacao de software: acontece toda validacao do software para verificar se esta de
acordo com as especificacoes do cliente;
Evolucao de software: apos o software ter sido concludo ele precisa evoluir para
poder atender as necessidades mutaveis do cliente.
Ja para (REZENDE, 2006) o desenvolvimento de projeto, sistemas ou software
podem ser divididos em cinco fases. As fases sao desmembradas em subfases e todas as
subfases geram pelo menos um produto, as fases sao:
Estudo Preliminar: definicao dos requisitos funcionais, objetivos que o projeto requer concluir, elaboracao estrutural do projeto e necessidades;
Analise do sistema: tem se uma visao global do sistema atual, onde sao relatados
os requisitos funcionais observando suas vantagens e desvantagens e tudo isso feito
atraves de levantamento de dados e organizacao de informacoes;
Projeto logico: sao definidos os requisitos funcionais reais, desenhos e detalhes da
logica ideal do projeto;

Projeto fsico: execucao e codificacao do programa incluindo seus teste e interfaces

(layouts) finais de entradas e sadas;
Projeto de implantacao: disponibilizacao, execucao da implantacao do sistema e
treinamentos para clientes e usuarios que iram usar o sistema.
Segundo (PRESSMAN, 2006) durante todo processo de desenvolvimento de uma
aplicacao ha tres fases que sao encontradas: definicao, desenvolvimento e manutencao.
O processo de desenvolvimento de software contem tres fases genericas, independentemente do paradigma escolhido. As tres fases definicao, desenvolvimento e manutencao,
sao encontrados em todo o desenvolvimento de software, independentemente da area de
aplicacao, tamanho do projeto ou complexidade (PRESSMAN, 2006).
Durante a fase de definicao o foco e identificar quais sao as informacoes serao
processadas, restricoes de projeto. As exigencias essenciais do software sao identificadas,
definido o
e definido o papel de cada elemento no sistema que e a analise do sistema. E
escopo do software, sao analisados os riscos que poderao ocorrer durante todo o processo
de desenvolvimento assim como, custos, tarefas e toda a programacao de trabalho.
A fase de desenvolvimento e onde se define o projeto de software, onde os requisitos sao traduzidos para um conjunto de representacoes graficas ou baseados em alguma
linguagem que descreve toda a estrutura e arquitetura do sistema. Todas as representacoes
do sistema sao convertidas em uma linguagem de programacao para que todas as etapas sejam executadas por um computador, essa etapa e conhecida como codificacao. E tambem
e realizados todos os testes para que possa descobrir todos os defeitos que o sistema pode
conter.
E na fase de manutencao onde ocorrem as correcoes dos erros que o cliente possa
descobrir. E tambem as adaptacoes, pois com o tempo o cliente tenha novos requisitos e
uma atualizacao no software se torna necessario.
A engenharia de software veio com o objetivo de facilitar a construcao de um
software desde a sua fase de levantamento de requisitos ate sua fase de manutencao como
e dito por varios autores citados aqui. Nesse projeto nao se adotou uma metodologia
especifica para o prototipo de software que ira se construir, pois neste referencial teorico
cada autor citado tem sua visao de como se usar a engenharia de software e a analise de
desenvolvimento de sistemas.
Segundo (PRESSMAN, 2006) o processo de desenvolvimento se divide em tres

partes definicao, desenvolvimento e manutencao.

Ja para (SOMMERVILLE, 2007) o processo e um conjunto de atividades no qual sao
elas: especificacao de software, projeto e implementacao, validacao e evolucao do sistema.
E para (REZENDE, 2006) esse processo se divide bem mais processos que os autores citados acima, se dividem em: estudo preliminar, analise do sistema, projeto logico,
projeto fsico e projeto de implantacao.
Cada autor demonstra sua visao de como analisar e se desenvolver um software,
ambos usam diferentes expressoes das fases de se construir um software, mas que se bem
interpretadas tem a mesma funcao.
Neste projeto se tem a intencao de utilizar a visao do autor Pressman, visto que
ele simplifica bem as fases de desenvolvimento de software e como o projeto nao e de
grande porte, a metodologia do mesmo se encaixa para executar o desenvolvimento do

sistema para a secretaria dos cursos superiores de computacao da UniEVANGELICA.

4.1.1.1

OpenUP
O OpenUP e um processo unificado de desenvolvimento no qual se e aplicado

metodos iterativos e incrementais dentro de um ciclo de vida. Open Up e um processo

feito para pequenas equipes que se unem para trabalhar em um mesmo lugar. A equipe
e formada por partes interessadas, programadores, arquitetos, gerentes de projetos e testadores (epf.eclipse.org/wikis/openup/, 2010).
O OpenUp e baseado nas principais caracteristicas do Rational Unified Process
(RUP) que sao incluidos o desenvolvimento iterativo, casos de uso, gestao de riscos e
organizado em quatro grandes area: Comunicacao
arquitetura centrada em abordagem. E
e Colaboracao, Objetivo, Solucao e Gerencia.
O OpenUP ja vem pronto para ser usado, nao necessitando de adicoes ou alteracoes. Pode tambem ser extendido para adicionar novo conte
udo de desenvolvimento
ou personalizar o processo para qualquer ambiente especfico (epf.eclipse.org/wikis/openup/,
2010).
Em um processo de desenvolvimento incremental, os clientes identificam, em um
esboco, as funcoes a serem fornecidas pelo sistema (SOMMERVILLE, 2007).
No desenvolvimento incremental sao identificadas as funcionalidades com mais e
menos importantes. Logo apos e definida uma serie de estagios de entregas onde cada

10

entrega fornece uma funcionalidade da aplicacao.

O OpenUP divide um projeto iteracoes, esses intervalos de tempo fixo normalmente sao divididos em semanas. O plano de iteracoes define o que deve ser entregue
dentro de cada iteracao. Equipes que usam o processo OpenUP devem se auto organizar
para alcancar os objetivos de cada iteracao e se comprometer a entregar o resultados
planejados (epf.eclipse.org/wikis/openup/, 2010).
Figura 1: Ciclo de Vida OpenUP

Fonte: http://epf.eclipse.org/wikis/openup/
Nota: Fases do ciclo de vida do OpenUp

Na figura 1 uma ilustra como a iteracao funciona, o plano de projeto primeiramente define o ciclo de vida, e definido o ciclo de cada iteracao e cada iteracao gera um
micro incremento.
O Open UP, assim como o RUP e um processo iterativo incremental de desenvolvimento de software e esta estruturado em 3 camadas distintas ciclo de vida de projeto,
ciclo de vida de iteracao e ciclo de vida de micro incremento (OpenUP Processo Unificado,
2010).

11

O ciclo de vida do projeto e representado pelo plano vertical da figura 1. Essa

camada trata do ciclo de vida de projetos e trata do processo de desenvolvimento como
um todo. Da mesma forma que o Processo Unificado Rational, o Open UP divide o ciclo
de vida de projetos em quatro fases distintas (OpenUP Processo Unificado, 2010).
Figura 2: Ciclo de Vida OpenUP

Fonte: http://epf.eclipse.org/wikis/openup/
Nota: Fases do ciclo de vida do OpenUp

Segundo (epf.eclipse.org/wikis/openup/, 2010) sao essas as fases como e mostrado na

figura 2:
Iniciacao: fase em que se enfatiza o processo de analise de negocios e analise de requisitos do negocio analisado, dando uma enfase menor a arquitetura e implementacao
(OpenUP Processo Unificado, 2010);
Elaboracao: fase em que se enfatiza o processo de desenvolvimento da analise arquitetural da solucao proposta (OpenUP Processo Unificado, 2010);
Construcao: fase em que se enfatiza o processo de implementacao da solucao proposta, bem como, testes e integracao (OpenUP Processo Unificado, 2010);
Transicao: fase em que se enfatiza o processo de implantacao do release, com importante foco na realizacao do teste beta e reconfiguracao necessaria do sistema, alem
do processo de treinamento do usuario. (OpenUP Processo Unificado, 2010).
No ciclo de vida de iteracao os processos iterativos pregam a divisao de suas atividades principais em subatividades, chamadas de iteracao, onde sao aplicados os principais
passos do ciclo de vida tradicional do desenvolvimento de software. Para o Open UP, as
disciplinas tratadas sao: Requisitos, Arquitetura, Implementacao, Teste e Gerencia de
Projetos (OpenUP Processo Unificado, 2010).

12

No ciclo de vida de micro incremento um micro incremento representa um esforco

de algumas horas ate alguns dias, desenvolvido por grupos compostos por alguns membros
da equipe de desenvolvimento colaborando para atingir os objetivos da iteracao (OpenUP
Processo Unificado,

2010).

Os testes sao feitos por cada iteracao e acontecem logo apos os desenvolvedores
terem desenvolvido a solucao e integrado na base do codigo. Os testes ajudam a garantir
que a versao que foi recem implementada e estavel e disponvel, e assim que o desenvolvimento evolui.
Um dos objetivos do OpenUP e a reducao dos riscos no inicio do ciclo de vida.
Todo trabalho esta listado, controlado e atribudo atraves de uma lista de itens de trabalho. Os membros da equipe devem usar um repositorio de tarefas que precisam ser registradas e monitoradas, incluindo todas as solicitacoes e bugs (epf.eclipse.org/wikis/openup/,
2010).

4.2

UML (Unified Modeling Language)

A UML e uma notacao ou uma padronizacao unificada de modelagem de software

que congrega esforcos de varios pesquisadores e consultores da area da tecnologia da

informacao (REZENDE, 2006).
A UML se define em uma linguagem de modelagem de sistema e nao em uma
metodologia de desenvolvimento de sistema ou softwares. Ela e representada por varios
diagramas como o caso de uso que atraves de seus atores e acoes ilustram a realidade, e
usada para representar a disposicao e o relacionamento entre as classes com o diagrama
de classes ou representar a arquitetura de um sistema com o diagrama de componentes
ou mostrar o fluxo de uma atividade da aplicacao usando um diagrama de atividades.
A notacao UML define varios tipos de diagramas que retratam a apresentacao
grafica de uma colecao de elementos de modelo, freq
uentemente mostrado com um grafico
integrado por relacionamentos diversos (REZENDE, 2006).

4.2.1

Diagrama de Caso de Uso

Um modelo de caso de uso e descrito pela UML por meio de um diagrama de

caso de uso, e pode ser divido em diversos diagramas. (REZENDE, 2006).

Pode se definir dentro deste diagrama atores, casos de uso e os limites que definem

13

o problema (REZENDE, 2006).

Um diagrama de casos de uso possui os seguintes elementos: os atores e os casos
de uso e mostra outros relacionamentos como generalizacoes, associacoes e dependencia
entre os elementos.
O ator e quem interage com o sistema enviando e recebendo mensagens e trocando
informacoes;
Um caso de uso e sempre iniciado por algum ator que esta enviando ou recebendo
mensagens.

Figura 3: Diagrama de Caso de Uso

Fonte: http://epf.eclipse.org/wikis/openuppt/
Nota: Interaca
o dos atores com o sistema

A Figura 3 ilustra o funcionamento do diagrama de caso de uso, os atores, suas

acoes e inclusoes. Esse diagrama possui quatro atores: Cliente, Banco, Caixa e Profissional de Manutencao. Possui tambem cinco casos de uso que sao eles: Retirar Dinheiro,
Transferir Fundos, Depositar Fundos, Recarregar Maquina e Validar Usuario. E nesse
diagrama tres dependencias include e as associacoes entres os casos de usos e os atores.

14

4.3

MVC (Model - View - Controller)

Model View Controller (MVC) e um padrao de arquitetura de software que tem

como objetivo separar logica de negocio da logica de apresentacao permitindo que desenvolvimento, manutencao e testes sejam feitos de forma independente um do outro.
O MVC foi originalmente descrito em 1970 por Trygve Reenskaug, que no momento estava trabalhando na plataforma smalltalk.
Basicamente uma aplicacao que segue o padrao Model View Controller e dividida
em tres camadas. As letras que compoem o nome desse padrao representam cada um
desses aspectos (DALLOGLIO, 2007).
Model tem como significado modelo pois ele define e gerencia o domnio de informacao e tambem notifica aos observadores quando ha mudanca nos dados. Representa
o modelo que e responsavel pela forma que
toda a informacao que a aplicacao controla. E
o dado e armazenado e pela interacao com o banco de dados.
Figura 4: Diagrama de Caso de Uso

Fonte: http://epf.eclipse.org/wikis/openuppt/
Nota: Interaca
o dos atores com o sistema

O modelo (model ), esta camada tem como objetivo definir a interface com o
usuario, como serao distribudos e organizados todos os elementos na tela na interface do

15

usuario.
A camada de visualizacao deve ser responsavel pela visualizacao, nao exercendo
qualquer tipo de controle de fluxo da execucao da aplicacao, tampouco devera conter
logica de negocios (DALLOGLIO, 2007).
O controller tem a funcao de receber e encaminhar todos os dados e ele que
inicia a resposta ao utilizador ao invocar objetos do modelo. Ele tambem responsavel por
toda a validacao e filtragem de dados. Os controladores sao formados por um conjunto
de objetos que recebem informacoes das views e tem a responsabilidade de atualizar os
models de acordo com as requisicoes dos usuarios.
Segundo (DALLOGLIO, 2007) na camada do controlador teremos a manipulacao
dos inputs dos usuarios, sua interpretacao e a execucao das tarefas correspondentes.

4.4

Banco de Dados
Um banco de dados e projetado, construdo e povoado por dados atendendo a

uma proposta especfica. Possui um grupo de usuarios definido e algumas aplicacoes

preconcebidas, de acordo com o interesse desse grupo de usuarios (ELMASRI, 2004).
Um banco de dados pode ser automatizado ou ser criado e mantido manualmente.
Um exemplo e uma lista telefonica mantida manualmente sem a ajuda de nenhuma ferramenta computacional e um banco de dados. Um banco de dados automatizado (computadorizado) pode ser gerado e administrado por um grupo de ferramentas feitas para
essa tarefa como um por um sistema gerenciador de banco de dados.
Um sistema gerenciador de banco de dados (SGBD) e uma colecao de programas
que permite aos usuarios criar e manter um banco de dados (ELMASRI, 2004).
Um SGBD e um software que tem como proposito geral facilitar os processos de
definicao, construcao, manipulacao e compartilhamento de banco de dados entre varios
usuarios e softwares. Outras funcoes importantes de um SGBD sao protecao e manutencao
de um banco de dados.
A primeira etapa para a construcao de um banco de dados e o levantamento de
requisitos, logo apos todos os requisitos serem levantados vem `a fase chamada de projeto
conceitual, logo apos a implementacao real do banco de dados utilizando um SGBD.
Segundo (ELMASRI, 2004) durante a etapa de levantamento de requisitos, o pro-

16

jetista entrevista o possvel usuario do banco de dados para entender e documentar seus
requisitos de dados.
O esquema conceitual e uma descricao dos requisitos de dados dos usuarios e
inclui descricoes detalhadas de tipos de entidade, relacionamento e descricoes. (ELMASRI,
2004)
O ultimo passo e a fase do projeto fsico, durante a qual sao definidas as estruturas
de armazenamento interno, ndices, caminhos de acesso e organizacoes de arquivos para
arquivos do banco de dados.

4.5

Padr
oes Web W3C
Chamamos de padroes web o conjunto de documentos e normas que tem como

finalidade unificar processos e componentes para a web (BECHARA; SILVA, 2005).

A World Wide Web Consortium (W3C), fundada por Tim Berners Lee, o mesmo
inventor da internet, resolveu entao apresentar a todas as organizacoes envolvidas com
web, a importancia e a necessidade da criacao de um padrao.
Os padroes web se caracterizam por um conjunto de tecnologias que envolvem:
Estrategias de planejamento e desenvolvimento de paginas;
Especificacoes tecnicas;
Linguagens para tratamento de dados e formatacao de codigo;
Recomendacoes;
Softwares;
Procedimentos;
Entre outras.
XHTML e a abreviacao de Extensible Hypertext Markup Language, que traduzindo,
seria Linguagem Extensvel para marcacao de Hipertexto, e veio para suceder o HTML.
Desde que foi criada, a linguagem HTML sofreu evolucoes, `a medida que novas funcionalidades foram demandadas. A partir de sua u
ltima versao (4.01), o HTML

17

foi reestruturado para se adequar o outro padrao, o XML, da se tornando o XHTML

(RIBEIRO, 2006).
Com a expansao da internet, as paginas foram se tornando mais complexas, foram
entao surgindo necessidades de colorir, inserir imagens, curvas, formas e tantas outras a
fim de transformar as paginas visualmente mais apresentaveis e sofisticadas.
Em outras palavras, o uso das folhas de estilo (CSS) permite que as informacoes
do codigo-fonte de uma pagina relativas `a apresentacao sejam separadas da sua estrutura
e do seu conte
udo (RIBEIRO, 2006).
CSS e a linguagem para descrever a apresentacao de paginas Web, incluindo cores,
layout e fontes. Ele permite adaptar a apresentacao para diferentes tipos de dispositivos,
tais como telas grandes, pequenas telas ou impressoras (www.w3.org, 2011).
As folhas de estilo permitem que todos os blocos da linguagem de marcac
ao
que possuem comportamento similar herdem os padroes definidos, dessa
forma, a alteracao de um comando no CSS, ira definir automaticamente todos os elementos que compartilham das mesmas predefinic
oes.
(RIBEIRO, 2006).

Dentre as vantagens do CSS estao:

Definir a posicao dos elementos na tela;
Definir fonte, cor da letra, espacamento entre linhas tamanho do texto, alinhamento;
Definir imagem de fundo;
Definir tamanho e largura.
A utilizacao do CSS e uma grande recomendacao da W3C, pois permite varios
benefcios, tais como simplificacao da codificacao da pagina, diminuicao do tamanho dos
arquivos, facilidade na manutencao, dentre outros.

18

Metodologia

O projeto se trata de um estudo bibliografico, necessario para construir um

prototipo de software que tem como objetivo solucionar o problema da administracao
das horas complementares, que e exigida na grade curricular dos cursos superiores de

computacao da UniEVANGELICA.
A pesquisa bibliografica sera realizada a partir de meios disponveis como livros,
artigos, web sites, teses, entre outros, tornando se fonte de pesquisa para o trabalho a ser
feito, colaborando entao para a criacao do referencial teorico.
E para a elaboracao desse projeto algumas etapas foram criadas para a realizacao
da pesquisa bibliografica do mesmo, sao elas:
O entendimento do tema do projeto com suas delimitacoes sobre quais assuntos
serao mais pertinentes `a serem abordados, e se desenvolvendo uma visao primaria,
delimitando no escopo do projeto quais assuntos serao abordados no referencial
teorico e quais artefatos serao desenvolvidos junto com o projeto;
Identificacao de teorias que abordam o tema do projeto, tais como livros de engenharia de software, banco de dados, UML, analise de projetos, sistemas de informacao,
buscando entao obras relacionadas ao tema do projeto proposto.
Criacao do documento que apresentara as etapas do trabalho e seus respectivos
produtos com os seus respectivos topicos tais como: introducao, referencial teorico,
desenvolvimento e consideracoes finais;
Elaboracao do documento do plano de projeto de software especificando todo o
planejamento da construcao do prototipo, desde a fase de levantamento de requisitos
ate sua implementacao;
Construcao e implementacao do prototipo de software, seguindo as regras da Engenharia de Software, e tendo como apoio as referencias teoricas citadas.

19

Justificando que todo o processo tera revisoes, correcoes a fim de mostrar a clareza
de tal processo.
Por isso tal metodologia mostrou metodos para o desenvolvimento de software
de forma clara, objetiva e cientfica, passando pelas etapas tracadas em meio a varias
opinioes sobre o projeto e sempre embasando nos conceitos e princpios das ciencias computacionais.

20

Cronograma

Figura 5: Cronograma do Projeto

21

Refer
encias

BECHARA, E.; SILVA, M. S. Revista Webdesign. [S.l.]: Editora Artecoom, 2005.

DALLOGLIO, P. PHP Programando com Orientacao a Objetos. [S.l.]: Novatec, 2007.
ELMASRI, R. Sistemas de Banco de Dados. [S.l.]: Pearson Addison, 2004.
epf.eclipse.org/wikis/openup/. OpenUP. 2010. Disponvel em:
http://epf.eclipse.org/wikis/openup/, acessado em 25 de abril 2011.
OpenUP Processo Unificado. OpenUP Processo Unificado. 2010. Disponvel em:
http://epf.eclipse.org/wikis/openuppt/, acessado em 23 de junho 2011.
PRESSMAN, R. S. Engenharia de Software. 6a.. ed. [S.l.]: McGrawHill, 2006.
REZENDE, D. A. Engenharia De Software E Sistemas De Informacao. [S.l.]: Brasport,
2006.
REZENDE, D. A.; ABREU, A. F. de. Tecnologia da Informacao Aplicada a Sistemas De
Informacao. [S.l.]: Atlas, 2008.
RIBEIRO, D. M. Vantagens Corporativas da Aplicacao dos Padroes WEB Voltados
para Acessibilidade e Usabilidade. IEEE Software, Escola de Ciencia da Informacao,
Universidade Federal de Minas Gerais, Belo Horizonte, 2006.
SOMMERVILLE, I. Engenharia de Software. 8a.. ed. [S.l.]: Pearson Addison-Wesley,
2007.
www.w3.org. World Wide Web Consortium (W3C). 2011. Disponvel em:
http://http://www.w3.org/, acessado em 30 de abril 2011.

22

APENDICE
A -- Primeiro ap
endice

Documento de Visao.