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.

· UML - Linguagem Para Visualização

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:

· Microsoft Access;

· 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	Pentium II, HD 1.3 GB, 128 RAM	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
Acadêmica	Horas de Trabalho		560
Orientador	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.

4. HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4ª Edição, Sagra Luzzatto, Porto Alegre, 2001, 203 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: