UNIVERSIDADE REGIONAL INTEGRADA
DO ALTO URUGUAI E DAS MISSÕES
CAMPUS DE FREDERICO WESTPHALEN
DEPARTAMENTO DE ENGENHARIA E
CIÊNCIAS DA COMPUTAÇÃO
PÓS-GRADUAÇÃO EM ANÁLISE E
DESENVOLVIMENTO DE SISTEMAS
UMA SOLUÇÃO PARA GERENCIAMENTO ESCOLAR USANDO UM SISTEMA
INTRAWEB COM ACESSO A BANCO DE DADOS
LEONARA PIRAN FRIGERI
Projeto de Conclusão
Prof. Dr. Nelson Zang
FREDERICO WESTPHALEN, DEZEMBRO DE
2003.
SUMÁRIO
SUMÁRIO
......................................................................................................................... 02
1.
RESPONSÁVEIS
.......................................................................................................... 03
1.1
Acadêmica .................................................................................................................... 03
1.2
Orientador
..................................................................................................................... 03
2.
JUSTIFICATIVA ......................................................................................................... 04
3.
OBJETIVOS
................................................................................................................. 05
3.1
Objetivos Gerais ........................................................................................................... 05
3.2
Objetivos Específicos
................................................................................................... 05
4.
REFERENCIAL TEÓRICO ....................................................................................... 06
5.
METODOLOGIA
......................................................................................................... 23
6.
RECURSOS E VIABILIDADE ................................................................................... 24
7.
CRONOGRAMA
.......................................................................................................... 25
8.
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................... 26
1. RESPONSÁVEIS
1.1 Acadêmica
Leonara Piran Frigeri
1.2 Orientador
Professor Leandro
Rosniak Tibola
Bacharel em
Administração pela URI – FW
Mestre em Ciências da
Computação - UFRGS - RS
2. JUSTIFICATIVA
A utilização de aplicações computacionais nas
corporações tem se tornado indispensável para o crescimento e produtividade das
mesmas. Tendo em vista que a informática está associada ao progresso e
desenvolvimento.
Porém, muitas vezes,
a implantação da informática em organizações ocorre num processo evolutivo e
gradual, onde inicialmente apenas determinadas funções são automatizadas e mais
tarde, à medida que o uso da informática vai se estabelecendo, novas funções
vão sendo informatizadas, até chegar a informatização total da empresa.
A Secretaria
Municipal de Educação de Engenho Velho possui carência nesse aspecto, dada a
falta de informatização dos trabalhos burocráticos, onde todos os relatórios
são manuais e os dados ainda são arquivados nos papéis, havendo redundância,
inconsistência e reentrada de dados. Para isso, uma solução que se propõe é:
realizar um estudo e análise Orientada a Objetos dos processos que ocorrem
nessa Secretaria e informatizar os processos referentes à parte acadêmica da
mesma, oferecendo uma solução de gerenciamento escolar usando um sistema
Intraweb com acesso a Bando de Dados, sanando com isso, algumas deficiências e
abrindo caminho para a solução das demais.
3. OBJETIVOS
3.1 Objetivos Gerais
Analisar os aspectos relevantes e construir um
sistema de Gerenciamento Escolar usando um sistema Intraweb com acesso a Banco
de Dados que auxilie nos trabalhos da Secretaria Municipal de Educação de
Engenho Velho.
3.2 Objetivos Específicos
·
Realizar
um estudo das necessidades existentes na Secretaria Municipal de Educação de
Engenho Velho;
·
Analisar
os processos que ocorrem na Secretaria Municipal de Educação de Engenho Velho,
utilizando análise Orientada a Objetos.
·
Estudar a linguagem de programação orientada a
objetos Delphi;
·
Analisar os principais banco de dados
disponíveis: DB2, Access, Firebird, MySQL, SQL Server, e escolher aquele que
melhor se adapte ao trabalho sugerido.
·
Definir
a metodologia a ser usada no desenvolvimento dos processos analisados,
considerando-se as necessidades existentes.
·
Desenvolver
um sistema de Gerenciamento Escolar para auxiliar nos trabalhos da Secretaria
Municipal de Educação de Engenho Velho;
4. REFERENCIAL TEÓRICO
A comunicação é uma
das maiores necessidades da sociedade humana desde os primórdios de sua
existência. A evolução no tratamento de informações não aconteceu somente na
área da comunicação. Equipamentos para processamento e armazenamento de
informações também foram alvo de grandes invenções ao longo do desenvolvimento
tecnológico. Com o passar dos tempos, aumentava a necessidade de
compartilhamento de dados e a troca de informações, originando então, a
interconexão.
O ponto
central do desenvolvimento de sistemas de informação está, como não poderia deixar
de ser, na solução do problema ligado à identificação dos seus elementos
componentes e na conseqüente definição de suas propriedades e inter-relações.
Em sistemas concretos, como é o caso daqueles que se
destinam à modelagem de fenômenos organizacionais, a identificação de
componentes, propriedades e inter-relações requerem pesquisa e observação, com
uma forte dose de empirismo, ao contrário dos sistemas ditos abstratos, em que
os componentes são conceitos e as propriedades e inter-relações estabelecidas
por postulados e axiomas.
A conclusão a que se pode chegar é que há
inexistência de métodos formais, que assistem os analistas de sistemas, torna a
execução de suas atribuições extremamente dependente da sua experiência
profissional e criatividade.
Uma
maneira prática de descrever sistemas, e por isso mesmo muito utilizada pelos
profissionais de análise, é visualizá-los como um conjunto de processos e
recursos relacionados.
A vantagem de se visualizar um
sistema como um conjunto de processos e recursos se deve ao fato de que os
processos possibilitam o fracionamento do sistema em subsistemas de uma maneira
bastante natural, tendo em vista que os processos podem ser caracterizados como
sistemas, no nível de fracionamento mais baixo e, inversamente, o sistema pode
ser observado como um processo único, no nível superior, mais alto.
4.1 Porque Fazer A Modelagem
Uma empresa de
desenvolvimento software bem-sucedida é aquela que oferece software de
qualidade e capaz de atender as necessidades dos usuários. Uma empresa que
consiga desenvolver esse software de maneira previsível e em determinado tempo,
utilizando recursos eficientes, será uma empresa com um negócio viável. O
principal produto é um bom software capaz de satisfazer as necessidades de seus
usuários e de seus respectivos negócios.
Para entregar um
software que satisfaça aos objetivos almejados, será necessário reunir-se e
interagir com os usuários de uma maneira disciplinada, com a finalidade de
expor e verificar os requisitos reais do sistema. Para desenvolver software de
qualidade duradoura, será necessário criar uma arquitetura de fundação sólida
aberta a modificações. Para fazer tudo isso de maneira previsível e
consistente, com uma avaliação dos custos reais do sistema, é necessário um
processo seguro de desenvolvimento que possa ser adaptado às novas necessidades
de seu negócio e de comportamento desejados do sistema.
4.1.1 Importância
Da Modelagem
O diferencial no
desenvolvimento de software está em criar o código correto e pensar em como será
possível elaborar menos software. Isso faz com que o desenvolvimento de
software de qualidade se torne uma questão de escolher a melhor arquitetura,
discernir os processos e ferramentas de desenvolvimento a serem utilizadas.
Segundo [BOO 2000,
pág 5] “Projetos de software malsucedidos falham em relação a aspectos únicos e
específicos de cada, mas todos os projetos bem sucedidos são semelhantes em
diversos aspectos. Existem muitos elementos que contribuem para uma empresa de
software fazer sucesso, um desses componentes é a utilização da modelagem”.
Através da modelagem
são construídos modelos para validar ou experimentar novas teorias, procurando
minimizar os riscos e os custos, ou seja, um modelo procura mostrar de forma
simplificada a realidade.
Os modelos fornecem
uma cópia do projeto de um sistema. Eles poderão abranger planos detalhados,
assim como planos mais gerais com uma visão ampla do sistema considerado. Um
bom modelo inclui os componentes que tem ampla repercussão e omite os
componentes menores que não são relevantes em determinado nível de abstração.
Cada modelo será uma abstração específica do sistema. Os modelos são
construídos para compreender melhor o sistema que está sendo desenvolvido.
Para [BOO 2000, pág
6] “Com a modelagem, alcançamos 4 objetivos.
1. Os modelos ajudam
a visualizar o sistema como ele é ou como se deseja que seja.
2. Os modelos
permitem especificar a estrutura ou o comportamento de um sistema.
3. Os modelos
proporcionam um guia para a construção do sistema.
4. Os modelos documentam
as decisões tomadas”.
A modelagem auxilia a equipe de desenvolvimento a
visualizar melhor o planejamento do sistema e permitir que o desenvolvimento
seja mais rápido ajudando a construir o item correto e tomar as decisões
certas. Quanto mais complexo for o sistema, maior será a probabilidade de
ocorrência de erros ou de construção de itens errados, caso não haja qualquer
modelagem. Todos os sistemas úteis e interessantes apresentam uma tendência
natural para se transformarem em algo mais complexo com o passar do tempo.
4.1.2 Princípios
Da Modelagem
O uso da modelagem
tem sua história ligada a engenharia. A escolha dos modelos a serem criados tem
influência direta sobre a maneira como um determinado problema é atacado e como
uma solução é definida, por isso, deve-se escolher bem os modelos.
A experiência indica
que a perspectiva orientada a objetos é superior para a criação de arquiteturas
flexíveis, inclusive no caso de sistemas que poderão conter grandes bancos de
dados ou vários componentes computacionais. Apesar desse fato, o ponto mais
importante é que cada visão de mundo e experiências vivenciadas conduzem a um
tipo diferente de sistema, com custos e benefícios diversos. Cada modelo poderá
ser expresso em diferentes níveis de precisão.
Nos sistemas
orientados a objetos, é possível estabelecer alguma conexão entre todos os
pontos de vista quase independentes de um sistema em uma mesma totalidade.
Nenhum modelo único é suficiente. Qualquer sistema não trivial será mais bem
investigado por meio de um pequeno conjunto de modelos quase independentes.
Para compreender sistemas orientados a objetos é preciso recorrer a várias
visões complementares e inter-relacionadas: a visão dos casos de uso, a visão
de projeto, a visão do processo, a visão da implementação do sistema e a visão
da implantação. Cada uma dessas visões poderá conter aspectos estruturais como
também aspectos comportamentais do sistema.
4.1.3 A Modelagem
Orientada A Objetos
No caso de software
existem várias maneiras de se definir um modelo. As duas maneiras mais comuns
são provenientes da perspectiva tradicional ou da perspectiva orientada a
objetos.
Segundo [BOO 2000,
pág 11] “A visão tradicional no desenvolvimento de software adota a perspectiva
de um algoritmo. Nessa visão, o principal bloco de construção de software é o
procedimento ou a função... À medida que os requisitos se modificam (e isso
certamente ocorrerá) e o sistema cresce (o que também acontecerá), será difícil
fazer a manutenção de sistemas construídos a partir do foco em algoritmos”.
Atualmente o
desenvolvimento de software tende a seguir uma perspectiva orientada a objetos.
O principal bloco de construção de todos os sistemas de software é o objeto ou
a classe.
O método orientado a
objetos para o desenvolvimento de software é uma parte do fluxo principal,
porque tem sido provado seu valor para a construção de sistemas em todos os
tipos de domínios de problemas, abrangendo todos os graus de tamanho e de
complexidade. Muitas linguagens, sistemas operacionais e ferramentas modernas
são de alguma forma, orientadas a objetos, fortalecendo a visão de mundo em
termos de objetos. Esse tipo de desenvolvimento fornece os fundamentos
conceituais para a montagem de sistemas a partir de componentes com a
utilização de tecnologias avançadas como Java Beans ou COM+.
4.2
UML (Unified Modeling Language)
“A UML (Unified
Modeling Language) é uma linguagem padrão para a elaboração da estrutura de
projetos de software. A UML poderá ser empregada para a visualização, a
especificação, a construção e a documentação de artefatos que façam uso de
sistemas complexos de software”, [BOO 2000, pág 13].
A UML é adequada para
a modelagem de sistemas, cuja abrangência poderá incluir sistemas de informação
corporativos a serem distribuídos a aplicações baseadas em Web e até sistemas
complexos embutidos de tempo real, abrangendo todas as visões necessárias ao
desenvolvimento e implantação desses sistemas. Para a aplicação da UML é
preciso compreendê-la e entender seus principais elementos: os blocos básicos
de construção da UML, as regras que determinam como esses blocos de construção
deverão ser combinados e alguns mecanismos básicos que se aplicam a toda
linguagem.
“UML é uma linguagem para modelagem; ela não guia
um desenvolvedor em como fazer análise e projeto orientado a objetos, ou qual o
processo de desenvolvimento ser seguido” [MAN 2000, pág. 39].
4.2.1 UML - Uma
Linguagem
As linguagens
fornecem um vocabulário e as regras para a combinação de palavras desse
vocabulário com a finalidade de comunicar algo. Uma linguagem de modelagem é
uma linguagem padrão para a elaboração da estrutura de projetos de software.
A modelagem permite a
compreensão de um sistema. Nenhum modelo é inteiramente suficiente
individualmente. Sempre serão necessários vários modelos, conectados entre si,
para tornar possível o entendimento de qualquer aspecto, ainda que seja o
sistema mais trivial.
O vocabulário e as
regras de uma linguagem como a UML indicam como criar e ler modelos bem
formados, mas não apontam quais modelos deverão ser criados, nem quando deverão
ser criados. Essa tarefa cabe ao processo de desenvolvimento do software. Um
processo bem definido servirá como guia para decidir quais artefatos serão
produzidos, quais atividades e trabalhadores serão escolhidos para criá-los e
gerenciá-los e como esses artefatos serão empregados para medir e controlar o
projeto como um todo.
O uso da UML para
elaborar modelos abrange modelos explícitos que facilitam a comunicação. Para
determinados itens, poderá ser melhor uma modelagem textual para outros itens,
poderá ser mais conveniente uma modelagem gráfica. Por trás de cada símbolo
empregado na notação da UML existe uma semântica bem definida. Dessa maneira,
um desenvolvedor poderá usar a UML para escrever seu modelo, e qualquer outro
desenvolvedor, ou até outra ferramenta, será capaz de interpretá-lo sem
ambigüidade.
·
UML
- Linguagem Para Especificação
Especificar significa construir modelos precisos sem
ambigüidade e completos. A UML atende a todas as decisões importantes em termos
de análise, projeto e implementação, que devem ser tomadas para o
desenvolvimento e implantação de sistemas complexos de software.
·
UML
- Linguagem Para Construção
A UML não é uma
linguagem visual de programação, mas seus modelos podem ser diretamente
conectados a várias linguagens de programação. Isso significa que é possível
mapear os modelos da UML em linguagens de programação tais como Java, C++,
Visual Basic ou até tabelas de banco de dados relacionais ou armazenamento de
dados persistentes de um bando de dados orientados a objetos. A UML é capaz de
representar tudo o que possa ser melhor expresso em termos gráficos, enquanto
as linguagens de programação representam o que é mais bem expresso em termos
textuais.
Esse mapeamento
permite a realização de uma engenharia de produção: a geração de código a
partir de um modelo em UML e desenvolvê-la em uma linguagem de programação. O
processo inverso também é possível: poderá ser reconstruído um modelo a partir
de sua implementação, revertendo-a a UML. Porém deve-se ter o cuidado para não
perder as informações ao serem passadas dos modelos para o código. A engenharia
reversa requer o suporte de ferramenta em conjunto com a intervenção humana.
·
UML
- Linguagem Para Documentação
Uma empresa de software saudável produz todos os
tipos de artefatos além do código executável bruto. Esses artefatos incluem,
mas não são limitados ao seguinte: requisitos, arquitetura, projeto, código
fonte, planos do projeto, testes, protótipos e versões.
Esses artefatos não
são apenas a parte do projeto a ser entregue, mas também são críticos para
controlar, medir e comunicar determinado sistema durante seu desenvolvimento e
após sua implantação.
A UML abrange a documentação da arquitetura do
sistema e de todos os seus detalhes. Também proporciona uma linguagem para a
expressão de requisitos e para a realização de testes. Por fim, ela oferece uma
linguagem para a modelagem das atividades de planejamento do projeto e de
gerenciamento de versões.
4.2.2 Fases do
Desenvolvimento de um Sistema em UML
Existem cinco fases
no desenvolvimento de sistemas de software: análise de requisitos, análise,
design (projeto), programação e testes. Estas cinco fases não devem ser
executadas na ordem descrita acima, mas concomitantemente de forma que
problemas detectados numa certa fase modifiquem e melhorem as fases
desenvolvidas anteriormente de forma que o resultado global gere um produto de
alta qualidade e performance.
·
Análise
de Requisitos
Esta fase captura as
intenções e necessidades dos usuários do sistema a ser desenvolvido através do
uso de funções chamadas "use-cases". Através do desenvolvimento de
"use-case", as entidades externas ao sistema (em UML chamados de
"atores externos") que interagem e possuem interesse no sistema são
modelados entre as funções que eles requerem, funções estas chamadas de
"use-cases". Os atores externos e os "use-cases" são
modelados com relacionamentos que possuem comunicação associativa entre eles ou
são desmembrados em hierarquia. Cada "use-case" modelado é descrito
através de um texto, e este especifica os requerimentos do ator externo que
utilizará este "use-case". O diagrama de "use-cases"
mostrará o que os atores externos, ou seja, os usuários do futuro sistema
deverão esperar do aplicativo, conhecendo toda sua funcionalidade sem importar
como esta será implementada. A análise de requisitos também pode ser
desenvolvida baseada em processos de negócios, e não apenas para sistemas de
software.
·
Análise
A fase de análise
está preocupada com as primeiras abstrações (classes e objetos) e mecanismos
que estarão presentes no domínio do problema. As classes são modeladas e
ligadas através de relacionamentos com outras classes, e são descritas no
Diagrama de Classe. As colaborações entre classes também são mostradas neste
diagrama para desenvolver os "use-cases" modelados anteriormente,
estas colaborações são criadas através de modelos dinâmicos em UML. Na análise,
só serão modeladas classes que pertençam ao domínio principal do problema do
software, ou seja, classes técnicas que gerenciem banco de dados, interface,
comunicação, concorrência e outros não estarão presentes neste diagrama.
·
Design
(Projeto)
Na fase de design, o
resultado da análise é expandido em soluções técnicas. Novas classes serão
adicionadas para prover uma infra-estrutura técnica: a interface do usuário e
de periféricos, gerenciamento de banco de dados, comunicação com outros
sistemas, dentre outros. As classes do domínio do problema modeladas na fase de
análise são mescladas nessa nova infra-estrutura técnica tornando possível
alterar tanto o domínio do problema quanto à infra-estrutura. O design resulta
no detalhamento das especificações para a fase de programação do sistema.
·
Programação
Na fase de
programação, as classes provenientes do design são convertidas para o código da
linguagem orientada a objetos escolhida (a utilização de linguagens procedurais
é extremamente não recomendada). Dependendo da capacidade da linguagem usada,
essa conversão pode ser uma tarefa fácil ou muito complicada. No momento da
criação de modelos de análise e design em UML, é melhor evitar traduzi-los
mentalmente em código. Nas fases anteriores, os modelos criados são o
significado do entendimento e da estrutura do sistema, então, no momento da
geração do código onde o analista conclua antecipadamente sobre modificações em
seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do
sistema. A programação é uma fase separada e distinta onde os modelos criados
são convertidos em código.
·
Testes
Um sistema
normalmente é rodado em testes de unidade, integração, e aceitação. Os testes
de unidade são para classes individuais ou grupos de classes e são geralmente
testados pelo programador. Os testes de integração são aplicados já usando as
classes e componentes integrados para se confirmar se as classes estão
cooperando uma com as outras como especificado nos modelos. Os testes de
aceitação observam o sistema como uma " caixa preta" e verificam se o
sistema está funcionando como o especificado nos primeiros diagramas de
"use-cases". O sistema será testado pelo usuário final e verificará
se os resultados mostrados estão realmente de acordo com as intenções do
usuário final.
4.2.3 O uso da UML
O objetivo da UML é descrever
qualquer tipo de sistema, em termos de diagramas orientado a objetos.
Naturalmente, o uso mais comum é para criar modelos de sistemas de software,
mas a UML também é usada para representar sistemas mecânicos sem nenhum
software. Algumas aplicações de UML:
·
Sistemas
de Informação: Armazenar,
pesquisar, editar e mostrar informações para os usuários. Manter grandes
quantidades de dados com relacionamentos complexos, que são guardados em bancos
de dados relacionais ou orientados a objetos.
·
Sistemas
Técnicos: Manter
e controlar equipamentos técnicos como de telecomunicações, equipamentos
militares ou processos industriais. Eles devem possuir interfaces especiais do
equipamento e menos programação de software de que os sistemas de informação.
Sistemas Técnicos são geralmente sistemas real-time.
·
Sistemas
Real-time Integrados:
Executados em simples peças de hardware integrados a telefones celulares,
carros, alarmes etc. Estes sistemas implementam programação de baixo nível e
requerem suporte real-time.
·
Sistemas Distribuídos: Distribuídos em
máquinas onde os dados são transferidos facilmente de uma máquina para outra.
Eles requerem mecanismos de comunicação sincronizados para garantir a
integridade dos dados e geralmente são construídos em mecanismos de objetos
como CORBA, COM/DCOM ou Java Beans/RMI.
·
Sistemas
de Software:
Definem uma infra-estrutura técnica que outros softwares utilizam. Sistemas
Operacionais, bancos de dados, e ações de usuários que executam ações de baixo
nível no hardware, ao mesmo tempo em que disponibilizam interfaces genéricas de
uso de outros softwares.
·
Sistemas
de Negócios:
descreve os objetivos, especificações (pessoas, computadores etc.), as regras
(leis, estratégias de negócios etc.), e o atual trabalho desempenhado nos
processos do negócio.
É importante perceber que a maioria dos sistemas
não possuem apenas uma destas características acima relacionadas, mas várias
delas ao mesmo tempo. Sistemas de informações de hoje, por exemplo, podem ter
tanto características distribuídas como real-time. E a UML suporta modelagens
de todos estes tipos de sistemas.
4.3 Desenvolvimento De Softwares
Orientado A Objetos
Os conceitos da orientação a objetos já vêm sido
discutidos há muito tempo, desde o lançamento da 1ª linguagem orientada a
objetos, a SIMULA. Vários "papas" da engenharia de software mundial
como Peter Coad, Edward Yourdon e Roger Pressman abordaram extensamente a
análise orientada a objetos como realmente um grande avanço no desenvolvimento
de sistemas.
Os conceitos que
Coad, Yourdon, Pressman e tantos outros abordaram, discutiram e definiram em
suas publicações foram que:
·
A
orientação a objetos é uma tecnologia para a produção de modelos que
especifiquem o domínio do problema de um sistema.
·
Quando
construídos corretamente, sistemas orientados a objetos são flexíveis a
mudanças, possuem estruturas bem conhecidas e provêm a oportunidade de criar e
implementar componentes totalmente reutilizáveis.
·
Modelos
orientado a objetos são implementados convenientemente utilizando uma linguagem
de programação orientada a objetos. A engenharia de software orientada a
objetos é muito mais que utilizar mecanismos de sua linguagem de programação, é
saber utilizar a melhor forma possível todas as técnicas da modelagem orientada
a objetos.
·
A orientação a objetos não é só teoria, mas uma
tecnologia de eficiência e qualidade comprovadas usada em inúmeros projetos e
para construção de diferentes tipo de sistemas.
·
A
orientação a objetos requer um método que integre o processo de desenvolvimento
e a linguagem de modelagem com a construção de técnicas e ferramentas
adequadas.
4.3.1 Programação
Orientada a Objetos
A programação
orientada a objetos é baseada nos conceitos de objetos e classes de objetos. A
programação orientada a objetos originou-se da necessidade de proteger as
variáveis globais em programas imperativos, de serem manipuladas e alteradas em
qualquer parte do programa.
Os conceitos de tipo abstrato de dados, que é a
definição de uma estrutura de dados definida pelas operações que afetam os
dados, e o ocultamento de informações, na qual os dados somente são acessados
através de sua interface e a estrutura de dados é desconhecida para as rotinas
de acesso, foram a base para a definição dos conceitos de programação
orientada a objetos, além da influência da área de inteligência artificial no
que se refere a objetos e relacionamentos.
No modelo orientado a
objetos, os problemas são resolvidos através de objetos que enviam e recebem
mensagens entre si. Como exemplos de Linguagem Orientadas a Objetos podemos
citar: Simula, Smalltalk, e diversas variações de linguagens imperativas que
aceitam orientação a objetos como Pascal, Delphi, C++ e Java.
Os programas
orientados a objetos possuem características básicas que são: objetos,
mensagens, métodos, classes, encapsulamento, polimorfismo e herança.
·
Objetos: Um objeto é um conjunto de
operações agregadas e restritas, que representam um elemento ou operação do
mundo real.
·
Mensagens: As mensagens são as requisições
que um objeto passa para outro para produzir um resultado desejado.
·
Métodos: Os Métodos são as descrições das
operações que um objeto pode realizar quando recebe uma mensagem.
·
Classes: Uma classe é o modelo baseado no
qual os objetos são criados. Ela consiste na descrição dos métodos e estados
que os objetos podem assumir.
·
Encapsulação: A encapsulação é o ocultamento
dos métodos e propriedades de cada objeto, para permitir realizarem somente as
operações previstas através do recebimento de mensagens.
·
Polimorfismo: O polimorfismo e a propriedade
que cada objeto tem de assumir diversas formas, respondendo e realizando
operações de acordo com as diferentes mensagens de cada objeto.
·
Herança: Herança é uma das mais
importantes propriedades do modelo orientado a objetos, que permite a definição
de novas classes e objetos baseado em outros já existentes, com todas as
características necessárias. Isto permite um grande reaproveitamento de código.
4.3.2 Orientação a
Objetos versus Técnicas Tradicionais
As técnicas tradicionais enfocam dados e
procedimentos sem uma relação definida, onde a alteração de um pode invalidar o
outro. O paradigma da orientação a objetos, ao contrário, enfoca um programa
como uma coletânea de uma entidade básica, o objeto, que encapsula dados e
procedimentos (método), existindo uma relação bem definida entre dados e
métodos, que se encontram no mesmo local.
Um sistema orientado
a objetos é um sistema mais natural, pois o desenvolvimento utilizando objetos
aproxima-se mais dos sistemas reais, com os quais estamos em contato
constantemente.
A concepção de um sistema
composto por dados e programas que utilizam estes dados passa para um sistema
composto por objetos e manipulação desses objetos, através da criação e envio
de mensagens.
A tabela abaixo
corresponde à comparação entre a orientação a objetos e técnicas tradicionais.
|
Técnicas
Orientadas a Objetos
|
Técnicas
Tradicionais
|
|
Métodos
|
Procedimentos,
funções ou sub-rotinas.
|
|
Variáveis
de Instância
|
Dados
|
|
Mensagens
|
Chamadas
de procedimentos
|
|
Classes
|
Tipos
Abstratos de Dados
|
|
Hereditariedade
|
|
|
Chamadas
sob controle do sistema
|
Chamada
sob controle do programador
|
4.3.3 Orientação a
Objetos e Object Pascal (Delphi)
Escrever tipos de
dados existentes, definir novos tipos e escrever pequenos blocos (sub-rotinas)
é a essência da programação Pascal tradicional. As modernas versões Pascal
permitem a abordagem orientada a objetos, baseadas principalmente nos conceitos
de classe, herança e polimorfismo.
Uma classe é um tipo
de dados definido pelo usuário, o qual tem um estado, uma representação e
algumas operações ou comportamento. Uma classe tem alguns dados internos e
alguns métodos, na forma de procedimentos ou funções. As classes são usadas
pelo programador para organizar o código fonte e pelo compilador para gerar o
aplicativo.
Um objeto é uma
variável do tipo de dados definido pela classe e são entidades reais. Quando o
programa é executado, os objetos ocupam parte da memória para sua representação
interna.
A relação entre
objeto e classe é a mesma que existe entre variável e tipo, entretanto em
algumas linguagens ou ambientes esta diferença não é clara. Para aumentar a
confusão, as versões anteriores ao Delphi do compilador Borland Pascal usavam a
palavra-chave object para definir classes. Por esta razão,
antigos programadores Pascal tendem a usar o termo objeto em vez de
classe para denotar um tipo, e o termo instância de objeto para indicar
objetos reais.
O Delphi introduziu
um novo modelo de objeto, baseado na palavra-chave class, mas o
modelo mais antigo ainda está disponível por questão de compatibilidade, usando
a palavra-chave object.
4.4 Sistemas de Banco de Dados
Atualmente os banco
de dados são essenciais para todos os ramos de negócios. Eles são usados para
manter registros internos, apresentar dados a consumidores e clientes na World
Wide Web e fornecer suporte a muitos outros processos comerciais. Da mesma
forma, os banco de dados são encontrados no núcleo de muitas investigações
científicas, pois com o passar do tempo, a armazenagem de informações em banco
de dados tornou-se muito usada em instituições e corporações, onde as
aplicações computacionais tornaram-se indispensáveis para o crescimento e
produtividade das empresas.
Um banco de dados possui as seguintes propriedades:
·
Um
banco de dados é uma coleção lógica coerente de dados com um significado inerente;
uma disposição desordenada dos dados não pode ser referenciada como um banco de
dados.
·
Um
banco de dados é projetado, construído e manipulado com dados para um propósito
específico; um banco de dados possui um conjunto pré-definido de usuários e
aplicações.
·
Um
banco de dados representa algum aspecto do mundo real, o qual é chamado de
“mini-mundo”; qualquer alteração efetuada no mini-mundo é automaticamente
refletida no banco de dados.
Um banco de dados pode ser criado e mantido por um
conjunto de aplicações desenvolvidas especialmente para esta tarefa ou por um
“Sistema Gerenciador de Banco de Dados” (SGBD). Um SGBD permite aos usuários criarem e manipularem
bancos de dados de propósito geral. O conjunto formado por um banco de dados
mais as aplicações que manipulam o mesmo é chamado de “Sistema de Banco de
Dados”.
Os Sistemas de
Gerência de Banco de Dados surgiram na década de 70 com o intuito de facilitar
o desenvolvimento de aplicações em banco de dados e é uma ferramenta poderosa
para criar e gerenciar grandes quantidades de dados de forma eficiente e
permitir que esses dados persistam durante um longo espaço de tempo com
segurança. Esses sistemas estão entre os tipos mais complexos de software
disponíveis. Para [GAR 2001, pág. 1], “Os recursos que um SGBD oferece ao
usuário são:
·
Armazenamento
persistente: Do
mesmo modo que um sistema de arquitetura, um SGBD admite o armazenamento de
quantidades muito grandes de dados que existem independentemente de quaisquer
processos que estejam utilizando esses dados. Porém, o SGBD vai muito além do
sistema de arquivos ao proporcionar flexibilidade, como estruturas de dados que
permitem o acesso eficiente a quantidades muito grandes de dados.
·
Interface
de programação:
Um SGBD permite ao usuário acessar e modificar dados através de uma linguagem
de consulta poderosa. Mais uma vez, a vantagem de um SGBD sobre um sistema de
arquivos é a flexibilidade para manipular dados armazenados de formas muito
mais complexas que a leitura e gravação de arquivos.
·
Gerenciamento
de transações:
Um SGBD admite o acesso concorrente a dados, isto é, o acesso simultâneo por
muitos processos distintos, as transações, ao mesmo tempo. Para evitar algumas
das conseqüências indesejáveis do acesso simultâneo, o SGBD admite o
isolamento, a aparência de que as transações são executadas uma de cada vez, e
a atomicidade, o requisito de que as transações sejam executadas completamente
ou não sejam executadas de forma alguma. Um SGBD também admite a resiliência, a
capacidade de se recuperar de muitos tipos de falhas ou erros”.
Alguns exemplos de
banco de dados:
·
Banco
de Dados Hierárquicos;
·
Banco
de Dados Distribuídos;
·
Banco
de Dados Orientados ao Objeto;
·
Banco
de Dados Relacionais.
Alguns exemplos de
Software de Banco de Dados:
·
MySQL;
·
SQL
Server;
·
Db2;
·
Oracle;
4.4.1 Banco De
Dados Orientado a Objetos
Nos dias atuais, o
banco de dados orientados a objeto é um fator emergente que integra banco de
dados e a tecnologia de orientação a objetos. Por um lado, a necessidade de
realizar manipulações complexas para os banco de dados existentes e uma nova
geração de aplicações de banco de dados geralmente requisitam mais diretamente
um banco de dados orientado a objeto. Por outro lado, aplicações de linguagens
orientadas a objeto e sistemas estão exigindo capacidades de banco de dados,
tais como continuidade, simultaneidade e transações, dos seus ambientes. Estas
necessidades estão levando à criação de sistemas poderosos, chamados banco de
dados orientados a objeto.
Os bancos de dados
orientados a objeto iniciaram-se primeiramente em projetos de pesquisa nas
universidade e centros de pesquisa. Em meados dos anos 80, eles começaram a se
tornar produtos comercialmente viáveis.
O desenvolvimento dos
Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos (SGBDOO) teve
origem na combinação de idéias dos modelos de dados tradicionais e de
linguagens de programação orientada a objetos.
No SGBDOO, a noção de
objeto é usada no nível lógico e possui características não encontradas nas
linguagens de programação tradicionais, como operadores de manipulação de
estruturas, gerenciamento de armazenamento, tratamento de integridade e
persistência dos dados.
Os modelos de dados
orientados a objetos tem um papel importante nos SGBDOO’s porque, em primeiro lugar,
são mais adequados para o tratamento de objetos complexos (textos, gráficos,
imagens) e dinâmicos (programas, simulações). Depois, por possuírem maior
naturalidade conceitual e, finalmente, por estarem em consonância com fortes
tendências em linguagens de programação e engenharia de software. O casamento
entre as linguagens de programação e banco de dados é um dos problemas que
estão sendo tratados de forma mais adequada no contexto de orientação a
objetos.
Superficialmente, pode-se dizer que orientação a
objetos corresponde à organização de sistemas como uma coleção de objetos que
integram estruturas de dados e comportamento. Além desta noção básica, a
abordagem inclui um certo número de conceitos, princípios e mecanismos que a
diferenciam das demais. Seus principais conceitos são: Abstração, Objeto,
Identidade de Objeto, Objetos Complexos, Encapsulamento, Tipo de Objetos,
Classes, Herança, Tipos de Herança, Métodos e Mensagens, Polimorfismo.
Há duas propriedades
fundamentais para a construção de um SGBDOO: extensibilidade e completude
computacional. A primeira garante que o conjunto de tipos oferecidos pelo
sistema permite a definição de novos tipos e não há distinção entre os tipos
pré-definidos e os definidos pelo usuário. A segunda implica que a linguagem de
manipulação de um banco de dados orientado a objetos pode exprimir qualquer
função computacional.
O Banco de Dados
entrou no mercado em meados da década de 80. Atualmente há mais de dez empresas
de banco de dados orientado a objetos vendendo mais de 25 produtos de banco de
dados orientado a objetos. Além disso, os banco de dados relacionais estão
incorporando recursos orientados a objeto em seus produtos da próxima geração.
Essas duas tendências devem prosseguir. Ambas proporcionam poderosos recursos
de modelagem orientada a objeto aos desenvolvedores de aplicação.
Os BDOO's constituem
uma importante etapa na evolução dos Sistemas gerenciadores de banco de dados.
Além disso, embora os BDOO's sejam normalmente caracterizados como aqueles
cujos recursos satisfazem as exigências das aplicações de banco de dados
"avançadas", todas as aplicações de banco de dados podem se
beneficiar dos poderosos conceitos de modelagem dos BDOO's.
5. METODOLOGIA
1. Na primeira fase será realizado um levantamento
bibliográfico relacionado à proposta de trabalho. Para isso, será utilizado
material bibliográfico direcionado a Análise Orientada a Objetos,
Desenvolvimento de Sistemas, Programação, Servidores, Etc.
2. Na segunda fase
será realizado um estudo na Secretaria Municipal de Educação de Engenho Velho,
analisando os processos existentes e a origem destes, tipos de relatórios
solicitados, tipos de dados e como estão armazenados.
3. Na terceira fase
será feito a análise Orientada a Objetos dos processos da Secretaria Municipal
de Educação de Engenho Velho, identificados na etapa anterior.
4. Na quarta fase,
será feito a modelagem Orientada a Objetos do sistema, definindo os padrões de apresentação e o
banco de dados a ser utilizado na implementação do mesmo.
5. Na quinta fase
acontecerá o desenvolvimento do sistema, o qual deverá possuir recursos para
sanar as necessidades diagnosticadas na etapa 2.
6. Na sexta fase
serão realizados os testes do sistema para validação do sistema.
7. Na sétima fase
será gerado o manual do sistema e realizado o treinamento dos usuários.
8. Na oitava e última
fase, acontecerá o encerramento da redação do trabalho de conclusão e do
sistema.
6. RECURSOS E VIABILIDADE
|
RECURSOS MATERIAIS
|
|
Hardware
|
|
Já
adquiridos pela URI e pela acadêmica.
|
|
Software
|
Delphi
7.0
Intraweb
7.0
Argo
UML (sem custo)
|
Já
adquirido pela acadêmica.
|
|
Internet
|
100
horas
|
Disponibilizada
pela URI e pela acadêmica.
|
|
Bibliografia
|
Livros,
revistas e catálogos.
|
Já
adquiridos pela URI.
|
|
TOTAL GERAL: 4.000,00
|
|
RECURSOS HUMANOS
|
|
|
Horas
de Trabalho
|
560
|
|
|
Horas
de Orientação
|
50
|
|
|
|
|
7. CRONOGRAMA
|
|
MÊS
|
|
Atividade
|
Dezembro
|
Janeiro
|
Fevereiro
|
Março
|
Abril
|
Maio
|
Junho
|
Julho
|
|
1
|
|
|
|
|
|
|
|
|
|
2
|
|
|
|
|
|
|
|
|
|
3
|
|
|
|
|
|
|
|
|
|
4
|
|
|
|
|
|
|
|
|
|
5
|
|
|
|
|
|
|
|
|
|
6
|
|
|
|
|
|
|
|
|
|
7
|
|
|
|
|
|
|
|
|
|
8
|
|
|
|
|
|
|
|
|
O cronograma acima referencia as atividades
descritas abaixo:
1. Levantamento e Revisão
Bibliográfica;
2. Estudo da realidade da Secretaria
Municipal de Educação de Engenho Velho e análise dos processos existentes e a
origem destes, tipos de relatórios solicitados, tipos de dados e como estão
armazenados os dados.
3. Análise Orientada a Objetos dos
processos da Secretaria Municipal de Educação;
4. Modelagem Orientada a Objetos do
sistema, definindo os padrões de apresentação, definição da linguagem de
programação para implementação do mesmo;
5. Desenvolvimento do sistema;
6. Realização dos testes do sistema;
7. Criação do manual
do sistema e treinamento dos usuários;
8.
Conclusão da redação do trabalho de conclusão e do sistema.
8. REFERÊNCIAS BIBLIOGRÁFICAS
1. ARAUJO,
Kleitor Franklint Correa de. Delphi 5 com Banco de Dados para Internet,
2ª Edição, Érica, São Paulo, 2000, 324 pg.
2. BOOCH,
Grady. RUMBAUGH, James. JACOBSON, Ivar. UML: Guia do Usuário, 9ª Edição,
Campus, Rio de Janeiro, 2000, 472 pg,
3. GARCIA-MOLINA, Hector. ULLMAN, Jeffrey D. WIDOM, Jennifer. Implementação
de Sistemas de Banco de Dados, Campus, Rio de Janeiro, 2001, 685 pg.
5. LARMAN,
Craig. Utilizando UML e Padrões, Bookman, Porto Alegre, 2000, 487 pg.
6.
RUMBAUGH, James. BLAHA, Michael. PREMERLANI,
William. EDDY, Frederick. LORENSEN, William. Modelagem e Projetos Baseados em
Objetos. Campus, Rio de Janeiro, 1994, 652 pg.
7. SHLAER, Ally. MELLOR, Stephen J. Análise De Sistemas Orientada Para
Objetos, McGraw-Hill, São Paulo, 1990, 177 pg.
8. Sites
consultados: