UTILIZAÇÃO DA TECNOLOGIA ACTIVEX DATA...

of 91 /91
UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) UTILIZAÇÃO DA TECNOLOGIA ACTIVEX DATA OBJECTS(ADO) EM UM SISTEMA COM OBJETOS DISTRIBUÍDOS TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA COMPUTAÇÃO — BACHARELADO SUZETE TERESINHA COLLING BLUMENAU, JUNHO/2000 2000/1-64

Embed Size (px)

Transcript of UTILIZAÇÃO DA TECNOLOGIA ACTIVEX DATA...

  • UNIVERSIDADE REGIONAL DE BLUMENAU

    CENTRO DE CINCIAS EXATAS E NATURAIS

    CURSO DE CINCIAS DA COMPUTAO

    (Bacharelado)

    UTILIZAO DA TECNOLOGIA ACTIVEX DATA OBJECTS(ADO) EM UM SISTEMA COM OBJETOS

    DISTRIBUDOS

    TRABALHO DE CONCLUSO DE CURSO SUBMETIDO UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENO DOS CRDITOS NA

    DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CINCIAS DA COMPUTAO BACHARELADO

    SUZETE TERESINHA COLLING

    BLUMENAU, JUNHO/2000

    2000/1-64

  • ii

    UTILIZAO DA TECNOLOGIA ACTIVEX DATA OBJECTS(ADO) EM UM SISTEMA COM OBJETOS

    DISTRIBUDOS

    SUZETE TERESINHA COLLING

    ESTE TRABALHO DE CONCLUSO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENO DOS CRDITOS NA DISCIPLINA DE TRABALHO DE

    CONCLUSO DE CURSO OBRIGATRIA PARA OBTENO DO TTULO DE:

    BACHAREL EM CINCIAS DA COMPUTAO

    Prof. Maurcio Capobianco Lopes Orientador na FURB

    Prof. Jos Roque Voltolini da Silva Coordenador do TCC

    BANCA EXAMINADORA

    Prof. Maurcio Capobianco Lopes

    Prof. Marcel Hugo

    Prof. Wilson Pedro Carli

  • iii

    A meus pais, irmos e meu noivo,

    pelo intenso apoio que sempre me deram.

  • iv

    AGRADECIMENTOS

    Ao meu orientador, Professor Maurcio Capobianco Lopes. A orientao deste meu

    Mestre foi primordial para meu aprendizado! Agradeo por ter tido o privilgio de ter sido sua

    orientanda.

    Agradeo, principalmente, aos meus pais, Roque e Maria Mercdes, que sempre

    lutaram para proporcionar aos filhos tudo o que eles jamais tiveram para si. Sem o incentivo

    deles, eu jamais teria concludo o curso.

    Aos meus irmos, Neuza e Wanderlei, que mesmo distantes fisicamente, sempre

    estiveram apoiando e incentivando.

    Ao meu noivo, Everton, que esteve constantemente do meu lado, compartilhando as

    horas felizes e tambm as tristes. Agradeo principalmente pela sua compreenso nos

    momentos em que mais precisei. Tivemos muitos momentos felizes, e tambm momentos

    difceis: as dificuldades que passamos desde o incio da faculdade, a saudade das pessoas

    queridas, as quedas que tivemos ao longo do caminho... Mas ao lembrarmos de tudo isso,

    tambm lembramos que estivemos sempre juntos, num apoio mtuo e constante. Obrigada,

    Everton, sua presena foi fundamental para que eu pudesse concluir este trabalho!

    A Deus, pela sua constante presena em tudo o que fazemos. A f o impulso para

    lutarmos sempre, buscarmos sempre novas conquistas e quando elas acontecem, Deus est

    presente.

    A todos os meus colegas de faculdade, que ajudaram para tornar este perodo de

    estudos estimulante e alegre.

    Aos meus colegas de trabalho, que no dia-a-dia, contriburam para o meu crescimento.

    Em especial queles que me auxiliaram durante a elaborao do TCC.

    E a todos os outros amigos e parentes que incentivaram o meu estudo.

  • v

    Sumrio

    Lista de Figuras ........................................................................................................................vii

    Lista de Tabelas .........................................................................................................................ix

    Lista de Quadros.........................................................................................................................x

    Lista de Abreviaturas.................................................................................................................xi

    RESUMO ................................................................................................................................xiii

    ABSTRACT ............................................................................................................................xiv

    1 INTRODUO .....................................................................................................................1

    1.1 OBJETIVOS........................................................................................................................3

    1.2 ESTRUTURA .....................................................................................................................3

    2 ACTIVEX DATA OBJECTS (ADO) .....................................................................................5

    2.1 HISTRICO........................................................................................................................5

    2.2 DEFINIES......................................................................................................................7

    2.3 CONCEITO.........................................................................................................................8

    2.4 UDA - UNIVERSAL DATA ACCESS ............................................................................10

    2.4.1 ADO E UDA...................................................................................................................13

    2.5 OLE DB.............................................................................................................................13

    2.5.1 ADO E OLE DB .............................................................................................................16

    2.6 ADO E OLE DB COMO INTEGRANTES DE UDA MULTI PLATAFORMA ............17

    2.7 ARQUITETURAS DE CAMADAS .................................................................................18

    2.8 MODELO BSICO DE PROGRAMAO ADO ..........................................................23

    2.9 APLICAES DISTRIBUDAS COM ADO..................................................................26

    2.9.1 OBJETOS DISTRIBUDOS...........................................................................................26

    2.9.2 ACTIVEX .......................................................................................................................30

    3 DELPHI 5.0 - INOVAES DO AMBIENTE ..................................................................32

  • vi

    3.1 BANCO DE DADOS NO DELPHI 5.0 ............................................................................34

    3.2 DELPHI 5.0 E ADO..........................................................................................................35

    4 DESENVOLVIMENTO DO PROTTIPO ........................................................................36

    4.1 O TUTOR INTELIGENTE PARA O AMBIENTE DELPHI ..........................................36

    4.2 ESPECIFICAO DO PROTTIPO ..............................................................................37

    4.2.1 CASOS DE USO ............................................................................................................38

    4.2.2 DIAGRAMA DE CLASSES ..........................................................................................40

    4.2.3 DIAGRAMAS DE SEQNCIA ..................................................................................42

    4.3 DEMAIS MUDANAS NO TUTOR DELPHI ...............................................................45

    4.4 O TUTOR DELPHI NUMA VISO DISTRIBUDA......................................................46

    4.4.1 A CAMADA DE DADOS..............................................................................................49

    4.4.2 A CAMADA DE REGRAS DE NEGCIOS ................................................................50

    4.4.3 A CAMADA DE APLICAO.....................................................................................56

    4.4.4 EXECUO DE UM CASO DE USO ..........................................................................59

    5 CONSIDERAES FINAIS ..............................................................................................63

    5.1 CONCLUSES.................................................................................................................63

    5.2 DIFICULDADES ENCONTRADAS ...............................................................................64

    5.3 SUGESTES ....................................................................................................................65

    ANEXO I..................................................................................................................................66

    GLOSSRIO............................................................................................................................74

    REFERNCIAS BIBLIOGRFICAS .....................................................................................76

  • vii

    LISTA DE FIGURAS

    Figura 1 - Arquitetura de UDA ................................................................................................11

    Figura 2 - Integrao dos componentes do OLE DB................................................................15

    Figura 3 - UDA Multi Plataforma ............................................................................................17

    Figura 4 - Modelo de arquitetura de trs camadas ..................................................................20

    Figura 5 - Arquitetura de aplicao MTS.................................................................................21

    Figura 6 - O Modelo Bsico do ADO ......................................................................................24

    Figura 7 - As tecnologias de acesso a dados alternativas disponveis no Delphi 5.0...............34

    Figura 8 - Relao entre os agentes ..........................................................................................37

    Figura 9 Diagrama de Casos de Uso .....................................................................................38

    Figura 10 - Diagrama de Classes..............................................................................................40

    Figura 11 - Diagrama de seqncia Cadastrar Usurio ............................................................42

    Figura 12 - Diagrama de seqncia Cadastrar Exerccio .........................................................43

    Figura 13 - Diagrama de seqncia Aprender Exerccio..........................................................44

    Figura 14 - Diagrama de seqncia Corrigir Exerccio............................................................44

    Figura 15 - Permisses do usurio............................................................................................45

    Figura 16 - Camadas do Tutor Delphi ......................................................................................47

    Figura 17 - Modelo de Dados ...................................................................................................49

    Figura 18 - O Editor Type Library ..........................................................................................50

    Figura 19 - Mdulo de Dados Remoto do ServidorTCC..........................................................54

    Figura 20 - Configurao da Conexo ADO............................................................................55

    Figura 21 - Mdulo de Dados Cliente ......................................................................................57

    Figura 22 - Propriedades do DCOMConnection ......................................................................57

    Figura 23 - Tela de acesso do usurio ......................................................................................59

  • viii

    Figura 24- Tela inicial do Tutor Delphi....................................................................................60

    Figura 25 - Entrada de novo usurio ........................................................................................61

    Figura 26 - Log de acesso ao ServidorTcc ...............................................................................62

  • ix

    LISTA DE TABELAS

    Tabela 1 - Modelo de Componentes OLE DB .........................................................................14

    Tabela 2 - Caractersticas das camadas ....................................................................................20

    Tabela 3 - Comparao entre sistemas antigos e atuais............................................................29

    Tabela 4 - Novos Recursos do Delphi 5.0 ................................................................................33

    Tabela 5 - Mudanas bsicas no Tutor Delphi .........................................................................46

  • x

    LISTA DE QUADROS

    Quadro 1 - Definio dos Mtodos da Type Library................................................................51

    Quadro 2 - Definio da interface IUnknown ..........................................................................52

    Quadro 3 - Criao da interface Servidor Tutor Delphi ...........................................................52

    Quadro 4 - String de conexo ADO .........................................................................................56

  • xi

    LISTA DE ABREVIATURAS

    ADO ActiveX Data Objects

    API Application Program Interface

    ASP Active Server Page

    CGI Common Gateway Interface

    CICS Customer Information Control System

    COM Component Object Model

    CORBA Common Object Request Broker Architecture

    DAO Data Access Objects

    DBMS Database Manager System

    DCOM Distributed Component Object Model

    DNA Distributed Internet Application Architecture

    FTP File Transfer Protocol

    HTML Hypertext Markup Language

    HTTP Hypertext Transport Protocol

    ISAM Indexed Sequential Access Method

    ITE Integrated Translation Environment

    MDAC Microsoft Data Access Component

    MIDAS Middle-tier Application Services

    MSMQ Microsoft Message Queue Server

    MTS Microsoft Transaction Server

    ODBC Open Database Engine

    OLE DB Object Linking and Embedding - data base

    OODBMS Object Oriented Database Manager System

  • xii

    PC Personal Computer

    RAD Rapid Application Development

    RDBMS Relational Database Manager System

    RDO Remote Data Object

    RDS Remote Data Service

    SQL Structured Query Language

    UDA Universal Data Access

    UML Unified Modeling Language

  • xiii

    RESUMO

    Este trabalho tem como propsito demonstrar a utilizao da tecnologia de

    manipulao de dados chamada ActiveX Data Objects (ADO), suas caractersticas e

    benefcios de sua utilizao na implementao de sistemas, principalmente na manipulao de

    dados em sistemas com objetos distribudos e pela Web. Visando demonstrar a utilizao do

    ADO, ser adaptado o acesso aos dados no Tutorial Inteligente para Delphi ([FRA1999]),

    utilizando esta tecnologia. Para isto foi utilizada a ferramenta visual Delphi 5.0

  • xiv

    ABSTRACT

    This work aims to present the use of the data handle technology called ActiveX Data

    Objects (ADO), its features and advantages in the system development, mainly, the use of this

    technology in the distributed system development and Internet. In order to present the

    concepts and use of ADO technology, it is used to access data in a Delphi Intelligent Tutorial

    [FRA1999].

  • 1

    1 INTRODUO

    Organizaes de todos os tamanhos esto, atualmente, tendo a necessidade de criar

    solues onde todos os dados possam ser considerados, pois at bem pouco tempo atrs,

    muitas informaes eram desprezadas pelos sistemas, devido ao fato da dificuldade de

    integrao de dados provindos de fontes diferentes, mas que em muitas vezes so de relevante

    importncia nas decises da organizao, tanto a nvel operacional quanto gerencial.

    Dados e informao so o corao da maioria dos sistemas de computador, e o uso

    eficiente e efetivo da informao o que concede valor e vantagem nas estratgias de

    negcios. Atualmente, este assunto ainda mais amplo, pois as organizaes de um modo

    geral esto redefinindo suas aplicaes, implementado-as na internet e computao mvel,

    pois o acesso informao requer novos cenrios, e a complexidade de se obter essas

    informaes e integr-las cresce permanentemente. Organizaes que mantinham seus dados

    em mainframes, agora podem obter conhecimento atravs de outras fontes, como o correio

    eletrnico, internet, sistemas distribudos, bancos de dados diferentes, como Oracle, SQL

    Server ou outros. A tendncia de que as empresas que conseguirem migrar de suas

    arquiteturas de dados antigas e ultrapassadas, para sistemas com arquiteturas mais recentes e

    promissoras, como Cliente/Servidor, multicamadas e principalmente, a integrao com a

    Internet, prosperaro.

    A partir do conceito de Universal Data Access(UDA), que uma proposta de uma

    interface nica para acessar inmeros tipos de dados, tanto relacionais quanto no-relacionais,

    pode-se conseguir esta integrao das informaes. Esta proposta partiu da Microsoft, e

    utiliza tecnologias proprietrias desta empresa, ligando-a fortemente s plataformas Windows

    e ao mundo Microsoft, o qual no se pode negar que muito representativo no mercado.

    UDA consiste em uma coleo de componentes de software que interagem e usam um

    conjunto comum de interfaces em nvel de sistema, definida por Object Linking and

    Embedding - Data Base (OLE DB). OLE DB uma programao de interface para fontes

    diversas de dados, que especifica um conjunto de componentes de comunicao que

    encapsulam vrios servios de administrao de bancos de dados. Estes componentes

    permitem essa interface nica. Considerando que OLE DB uma interface de programao

  • 2

    em nvel de sistema, o ActiveX Data Objects (ADO) a interface em nvel de aplicao

    ([MIC2000]).

    Da mesma forma que o ODBC programvel atravs de objetos pelo Remote Data

    Objects (RDO), o OLE DB programvel atravs dos objetos do ADO. Esses objetos

    fornecem uma interface Component Object Model (COM) para acesso s funes das

    bibliotecas subjacentes, facilitando o uso por parte dos desenvolvedores de qualquer

    linguagem. O ADO uniformiza a interface de acesso a dados, tornando possvel acessar, da

    mesma maneira, estruturas extremamente diferentes, como bases de dados SQL, mensagens

    de uma caixa postal Exchange, bancos de imagens e arquivos texto. Esse acesso fornecido

    de uma maneira simples, orientada a componentes e compatvel com o padro de

    componentes COM ([CAL1999]).

    ADO tem como propsito prover uma interface fcil de usar e pode ser implementado

    em Visual Basic, Java, C++ e Delphi. Como ADO baseado em componentes ActiveX,

    somente pode ser utilizado em aplicaes Windows, mas nada impede que essas aplicaes

    acessem servidores que operem em outras plataformas, como Unix ou Linux, por exemplo.

    Para demonstrar a capacidade da tecnologia ADO, ser adaptado um programa que j

    foi desenvolvido em [FRA1999]. Este programa, que um Tutorial Inteligente para Delphi,

    ser aperfeioado, de forma a funcionar com objetos distribudos. Os benefcios de adaptar o

    programa para este novo paradigma so a possibilidade de se utilizar vrios bancos de dados

    nesta aplicao e a facilidade para o uso do programa, seja pela Web ou por uma rede

    local(como a dos laboratrios da FURB, por exemplo), sem a necessidade de cada aluno ter a

    base de dados do tutorial na sua prpria mquina.

    O resultado deste trabalho visa proporcionar uma maneira mais atrativa para o

    aprendizado da linguagem, alm de demonstrar a utilidade do ADO, que uma tecnologia

    emergente e com tendncia de obter sucesso no mercado.

    A especificao ser feita sobre os conceitos j existentes, com algumas adaptaes em

    nvel de estrutura fsica das tabelas, utilizando uma metodologia orientada a objetos,

    representada atravs da UML - Unified Modeling Language. A ferramenta utilizada para esta

    especificao foi o Rational Rose, devido aos recursos disponveis para aplicar as

  • 3

    representaes da UML, como o Diagrama de Classes, o Diagrama de Casos de Uso e o

    Diagrama de Seqncia.

    Foi utilizado o ambiente de programao Borland Delphi 5.0, para a implementao do

    prottipo, pois este ambiente j suporta a tecnologia ADO.

    1.1 OBJETIVOS

    O objetivo principal do trabalho implementar o uso da tecnologia ADO no prottipo

    do Tutorial Inteligente para Delphi.

    Os objetivos secundrios do trabalho so:

    a) demonstrar a tecnologia ADO;

    b) possibilitar o funcionamento do Tutorial Inteligente para Delphi, com objetos

    distribudos ou pela Web.

    1.2 ESTRUTURA

    O trabalho foi estruturado da seguinte maneira:

    O primeiro captulo apresenta a contextualizao e justificativa para o

    desenvolvimento da proposta do trabalho.

    O segundo captulo aborda a tecnologia ADO, suas caractersticas, alguns conceitos

    bsicos sobre ADO e tecnologias auxiliares para utilizao desta, como Objetos Distribudos,

    ActiveX, Universal Data Access (UDA), OLE DB e a arquitetura Multicamadas. Todas estas

    tecnologias e conceitos, esto muito ligadas ao ADO, pois a implementao deste baseada

    nestes paradigmas.

    O terceiro captulo ser sobre a ferramenta de desenvolvimento utilizada para

    desenvolver o prottipo, o Borland Delphi 5.0, suas caractersticas e inovaes,

    principalmente no que tange implementao utilizando componentes ADO e objetos

    distribudos.

    O quarto captulo descreve a especificao do prottipo, bem como detalhes de sua

    implementao.

  • 4

    O quinto captulo apresenta as consideraes finais, abrangendo as concluses do

    desenvolvimento deste trabalho, as dificuldades encontradas e as sugestes para prximos

    trabalhos.

  • 5

    2 ACTIVEX DATA OBJECTS (ADO)

    2.1 HISTRICO

    Sempre houve uma certa dificuldade para possibilitar aos desenvolvedores de software

    uma independncia do banco de dados, pois qualquer base de dados tem um modelo para

    armazenar seus dados, com tipos de dados especficos. As principais linguagens de

    programao disponibilizam componentes para fazer acesso aos dados, porm o modelo que o

    banco de dados utiliza para armazenar os dados e o modelo que alguns componentes de

    acesso a dados utilizam para armazen-los no precisam ser necessariamente os mesmos.

    Componentes podem interoperar entre linguagens, ferramentas, sistemas operacionais

    e redes, mas apresentam caractersticas comuns aos objetos como polimorfismo e

    encapsulamento. Alguns componentes, chamados comumente de caixas pretas, no podem ser

    estendidos via herana, tais como componentes OLE. Componentes CORBA, no entanto,

    permitem herana.

    Segundo [SES1998], um componente possui, no mnimo, as caractersticas a seguir :

    a) um produto de mercado: deve ser empacotado de maneira que possa ser

    comercializvel;

    b) no uma aplicao completa: um componente deve ser combinado com outros

    para gerar uma aplicao. Deve ser implementado para realizar um nmero limitado

    de tarefas;

    c) pode ser usado em combinaes imprevisveis: deve poder ser usado de maneiras

    imprevistas pelo desenvolvedor;

    d) tem uma interface bem definida: assim como com objetos clssicos, os

    componentes s podem ser manipulados atravs de uma interface, que expe suas

    funes ao mundo exterior;

    e) um objeto interopervel: um componente pode ser invocado como um objeto

    atravs da rede, de linguagens de programao e sistemas operacionais. uma

    entidade de software independente de sistemas;

    f) um objeto expansvel: os componentes suportam encapsulamento, herana e

    polimorfismo.

  • 6

    Em suma, componentes so partes de cdigo reutilizveis e independentes de

    aplicaes e sistemas.

    Em um modelo baseado em componentes, os dados so mantidos em uma camada que

    responsvel por apresent-los num formato simples e eficiente para serem utilizados por

    componentes de acesso. Muitas camadas de componentes podem ser suportadas por uma

    determinada base de dados, e uma determinada camada pode suportar vrios produtos de

    banco de dados diferentes. Isto permite s aplicaes que utilizam estes componentes, algum

    grau de independncia do banco de dados subjacente. Um exemplo de camada que permite

    essa independncia o ADO, pois baseia-se em componentes de acesso que possibilitam a

    transparncia dos dados para a camada de interface da aplicao, permitindo que esta utilize

    qualquer fonte de dados. ([SES1998]).

    ADO uma tecnologia muito recente, que em cerca de 2 anos de existncia, j tem

    uma estabilidade e tornou-se uma ferramenta de acesso a dados que pode ser usada em todos

    os tipos de desenvolvimento de aplicaes.

    O ADO parte do Microsoft Data Access Components (MDAC), o qual consiste no

    ActiveX Data Objects (ADO), no Remote Data Service (RDS), no Microsoft OLE DB

    Provider para ODBC, no prprio ODBC e nos drives para diferentes base de dados. Pelo

    motivo de utilizar todas estas tecnologias originrias e proprietrias da Microsoftt, ADO

    somente pode ser utilizado em ambientes Windows.

    Esta tecnologia pode ser implementada em Visual Basic, Java, C++ e Delphi. Na

    verso 5.0 do Delphi, esto disponveis uma srie de componentes que provem recursos para

    o ADO.

    Neste contexto, existe tambm uma estratgia para fornecer acesso a qualquer tipo de

    dados, chamada Universal Data Access (UDA - acesso a dados universal). A idia ter uma

    interface nica que permita aos programadores usar suas ferramentas prediletas para acessar

    bancos de dados relacionais e outras fontes de dados menos estruturadas. O ADO esta

    interface e por isso promete representar uma nova gerao de acesso aos dados ([CAN2000]).

  • 7

    2.2 DEFINIES

    Para entender melhor o que ADO e como funciona, necessrio inicialmente

    conhecer alguns termos, conceituados em [MIC2000]:

    a) API (Application Program Interface): uma API o mtodo especfico prescrito por

    um sistema operacional de computador ou por outro programa de aplicao, pelo

    qual um programador que escreve um programa de aplicao pode fazer pedidos ao

    sistema operacional ou outra aplicao;

    b) ASP (Active Server Page): ASP tambm uma abreviao para provedor de servio

    de aplicao. Uma pgina ASP uma pgina HTML que inclui um ou mais scripts

    (pequenos programas embutidos) que so processados no servidor Web antes da

    pgina ser enviada ao usurio. Um ASP parecido com um CGI, onde os

    programas rodam no servidor e normalmente constrem uma pgina para o usurio.

    Tipicamente, o script ASP recebe uma mensagem do requisitante, monta os

    resultados acessando a base de dados se necessrio, customiza as informaes e

    aps envia-as ao requisitante. ASP uma caracterstica do Microsoft Internet

    Information Server (IIS), mas funciona em qualquer browser. Pode-se criar um

    arquivo de ASP incluindo um script em VBScript ou JScript em um arquivo de

    HTML ou usando ActiveX Data Objects (ADO);

    c) DAO (Data Access Objects): foi a primeira interface orientada a objetos exposta

    para o Jet database engine (usado pelo Microsoft Access) e permitiu aos

    desenvolvedores Visual Basic conectar tabelas do Access - e tambm outros

    bancos de dados atravs do ODBC. DAO melhor adaptado a aplicaes de

    sistemas pequenos e monolticos, onde a camada de regras de negcio e a camada

    de acesso a dados reside no mesmo executvel;

    d) IIS (Internet Information Server): IIS um conjunto de servios, como Ftp, http,

    Web e outros servios do sistema operacional WindowsNT. So programas para

    controlar e administrar Web sites, e suportam aplicaes Web que tm interao

    com bases de dados. O uso do IIS resulta num servidor de pginas mais rpido e

    seguro;

    e) RDO (Remote Data Objects): uma interface de acesso a dados orientada a objetos

    e que tambm fornece uma interface que expe quase toda a flexibilidade e o poder

    do ODBC. O RDO limitado, entretanto, pois ele no acessa muito bem bases de

  • 8

    dados Jet ou ISAM (como arquivos .DBF, por exemplo), e s pode ter acesso a

    bancos de dados relacionais atravs de drivers ODBC existentes. mais utilizado

    com aplicaes desenvolvidas em Visual Basic;

    f) RDS (Remote Data Service): um servio de transmisso de dados por uma rede.

    Por exemplo: se uma aplicao de rede proporciona para os clientes a habilidade

    para ter acesso a dados, pode-se distribuir o processo daqueles dados entre o cliente

    e o servidor com RDS. O componente cliente envia mensagens para o servidor da

    rede. O componente servidor RDS processa estes pedidos e os envia ao Sistema de

    Administrao de Banco de Dados (DBMS) por uso de uma regra de negcios

    (camada intermediria da arquitetura utilizada pelo RDS - Middle Tier). O DBMS

    responde ao pedido e manda de volta os dados ao servidor de rede. Os componentes

    de RDS no servidor de rede transformam aqueles dados em um objeto ADO

    Recordset - conjunto de registros (mais adiante ser explicado melhor cada um dos

    objetos ADO) . Os dados so analisados gramaticalmente para transporte ao cliente

    e so mandados de volta pela cadeia ao computador cliente, onde podem ser

    exibidos em controles como um texto ou ComboBox, por exemplo.

    2.3 CONCEITO

    ActiveX Data Objects (ADO) um conjunto de componentes da Microsoft, que

    prov, no nvel de aplicao, uma interface de alto nvel para habilitar os desenvolvedores a

    acessar dados e informao a partir de qualquer linguagem de programao em qualquer base

    de dados, seja local ou remotamente ([MAR1999]).

    Essa interface, chamada ADO, uma API Microsoft que permite aos

    programadores, que escrevem aplicaes com interface visual, obterem acesso para bancos de

    dados, relacionais ou no relacionais. Por exemplo, para escrever um programa que

    proporcionaria, para os usurios de uma rede local, dados de um banco IBM DB2 ou de um

    banco de dados Oracle, podem ser inclusos comandos ADO em um arquivo HTML que seria

    identificado, ento, como um Active Server Page (ASP). Quando um usurio entrasse numa

    pgina, a pgina mandada de volta poderia incluir dados provindos de um banco de dados,

    utilizando cdigo de ADO.

  • 9

    Como parte de ActiveX, ADO tambm parte do modelo COM (Component Object

    Model), que um modelo de programao baseado em objetos desenvolvido para promover

    interoperabilidade de software, ou seja, permitir que duas ou mais aplicaes ou componentes

    cooperem facilmente entre si, mesmo que tenham sido desenvolvidos por diferentes

    fabricantes, em linguagens diferentes e at mesmo se estiverem rodando em sistemas

    operacionais diferentes([MIC2000]).

    ainda, uma evoluo do RDO (Remote Data Objects). RDO trabalha com o ODBC

    da Microsoft para ter acesso a bancos de dados relacionais, mas no bancos de dados no-

    relacionais. ADO tambm caracteriza Remote Data Services (RDS) pelo qual pode-se mover

    dados de um servidor para uma aplicao cliente, manipular os dados no cliente, e retornar

    atualizao deste ao servidor em uma nica viagem de ida-e-volta ([MIC2000]).

    ADO prov consistncia, acesso de alta performance para dados e suporte a uma

    grande variedade de necessidades de desenvolvimento, inclusive a criao de clientes de

    banco de dados front-end (2 camadas) e middle-tier (camada intermediria - modelo 3

    camadas), usando aplicaes, ferramentas, linguagens, ou browsers de Internet. ADO

    projetado para ser uma interface de dados que tenha suporte para desenvolvimentos de

    sistemas implementados com multicamadas e implementaes baseadas na Web.

    ADO implementado para funcionar com trfego de rede mnimo e otimizar o

    transporte de dados em aplicaes distribudas. projetado para combinar as melhores

    caractersticas RDO e DAO (Data Access Objects), e, eventualmente, at as substituir, usando

    convenes semelhantes, com semntica simplificada, para fazer de sua tecnologia um

    prximo passo natural para os desenvolvedores de software atuais.

    Portanto, o ADO projetado com o objetivo de ser a nica interface de dados

    necessria para quaisquer tarefas de programao. Nem todos os programadores iro migrar

    para ADO, mas certamente esta uma tecnologia a ser considerada ([CAN2000]).

    Segundo [CAN2000] as principais vantagens do ADO so:

    a) a facilidade de uso;

    b) alta velocidade;

    c) baixa sobrecarga de memria;

  • 10

    d) pouco gasto de disco;

    e) trfego de rede mnimo nos principais cenrios.

    As caractersticas mais predominantes do ADO, de acordo com [MIC2000] so:

    a) a capacidade de suportar stored procedures com parmetros de entrada, sada e

    devoluo de resultados;

    b) permitir a otimizao da comunicao;

    c) permitir o envio de mais do que um registo a partir de stored procedures.

    ADO tambm pertence ao contexto do conceito de UDA (Universal Data Access), que

    outro paradigma que est crescendo no meio da informtica, devido s grandes vantagens

    que tende a proporcionar para o acesso aos dados, de uma maneira geral.

    2.4 UDA - UNIVERSAL DATA ACCESS

    UDA uma proposta de uma interface nica para acessar inmeros tipos de dados,

    tanto relacionais quanto no-relacionais. um novo preceito que, ao invs de promover a

    idia de se tentar construir um banco de dados universal, prov acesso universal para vrios

    tipos de bancos de dados. Para que isto se torne realidade, a Microsoft e outras companhias

    de banco de dados construram um "programa de ponte" entre o banco de dados e o OLE DB

    da Microsoft. OLE DB o servio de sistema subjacente que um programador que usa ADO

    est usando de fato.

    Hoje, companhias que constrem solues Cliente/Servidor de banco de dados

    baseado em redes buscam mxima vantagem empresarial dos dados e informao distribudas

    ao longo das suas organizaes. UDA prov acesso de alto-desempenho para uma variedade

    de dados e fontes de informao em plataformas mltiplas e uma interface de programao

    fcil de usar que trabalha com praticamente qualquer ferramenta ou linguagem, alavancando

    as habilidades tcnicas que o programador j tm. As tecnologias que suportam UDA

    permitem s organizaes criar solues fceis de manter, com os dados nos clientes, na

    camada intermediria ou no servidor ([MIC2000]).

    Outro benefcio da UDA que no requer movimento caro e demorado de todos os

    dados incorporados em um nico banco de dados, nem requer compromisso com produtos de

  • 11

    um nico vendedor. UDA est baseada em especificaes abertas e trabalha com os principais

    produtos de banco de dados estabelecidos. UDA um passo evolutivo de interfaces de padro

    como ODBC, RDO, ADO, e estende significativamente a funcionalidade destas tecnologias

    ([MIC2000]).

    A figura 1 ilustra a arquitetura de UDA.

    Figura 1 - Arquitetura de UDA

    Fonte: ([MIC2000])

  • 12

    Provedores de dados so componentes que representam fontes diversas de dados como

    bancos de dados, arquivos indexados, planilha eletrnicas e arquivos de correio eletrnico.

    Os provedores expem uniformemente os dados utilizando uma abstrao comum chamada

    rowset (conjunto de linhas, registros).

    Servios, ou regras, so componentes que estendem a funcionalidade dos provedores

    de dados implementando interfaces que no so nativas do banco de dados.

    Clientes so componentes que utilizam OLE DB. Exemplos de clientes incluem

    modelos de acesso a dados de alto nvel, como ADO, aplicaes empresariais escritas em

    Visual Basic, C++, Delphi ou Java e ferramentas de desenvolvimento.

    Todas as interaes entre componentes da figura 1, que so indicadas atravs de setas

    bidirecionais, podem ultrapassar o limite de mquinas por protocolos de rede, como

    Microsoft Distributed COM (DCOM) ou HTTP. Interaes entre componentes de

    transaes so possveis por um servio de coordenao de transaes distribudas como o

    MTS (Microsoft Transaction Server). No item 2.7 deste trabalho, onde ser descrita a

    arquitetura de trs camadas, poder-se- verificar um exemplo da arquitetura de uma aplicao

    que utiliza MTS em suas transaes.

    Segundo um artigo de David Lazar, publicado em [MIC2000] , uma fora da estratgia

    UDA que integrada por um conjunto de modernas interfaces orientadas a objeto. Estas

    interfaces, bem como MTS, esto baseado no modelo COM, que prov o seguinte:

    a) os servios integrados de transaes, segurana e acesso a dados para suportar os

    diversos cenrios das aplicaes;

    b) a escolha de qualquer linguagem de programao;

    c) suporte para aplicaes de customizao e componentes reutilizveis;

    d) interoperabilidade.

    Por causa da consistncia e interoperabilidade previstas pela COM, a UDA tem sua

    arquitetura aberta e trabalha com virtualmente qualquer ferramenta ou linguagem. Tambm

    habilita a consistncia dos dados em todas as camadas do modelo de arquitetura

    multicamadas. No nvel de aplicao, os componentes ADO que fazem a interface.

  • 13

    2.4.1 ADO E UDA

    UDA realmente um passo evolutivo para o padro de dados atualmente discutido.

    conhecida a sopa de letrinhas - ODBC, RDO, MTS e DAO. UDA um passo para

    estender a funcionalidade destas tecnologias. O pacote de tecnologias que compem UDA

    consiste em ActiveX Data Objects (ADO), Remote Data Service (RDS, antigamente

    conhecido como Conector de Banco de Dados Avanado ou ADC), OLE DB, e ODBC.

    Juntas, estas interfaces provem os meios para trabalhar com qualquer fonte de dados. E

    juntas elas so conhecidos como Universal Data Access.

    2.5 OLE DB

    Por si s, ADO no capaz de qualquer coisa. Para prover alguma funcionalidade,

    ADO precisa dos servios de um provedor OLE DB.

    OLE DB a estratgia de programao que faz a interface com os dados. uma

    especificao aberta projetada para interagir com ODBC provendo um padro aberto para se

    ter acesso a todos os tipos de dados ([MIC2000]).

    Numa outra terminologia, OLE DB pode ser visto como um conjunto de componentes

    compostos de fornecedores de dados, que contm e expem dados, consumidores de dados,

    que usam os dados, e componentes de servio, que processam e transportam dados (como os

    processadores de consultas e mecanismos de cursor) ([CAN2000]).

    OLE DB define uma coleo de interfaces COM que encapsulam vrios servios de

    administrao de sistemas banco de dados. Interfaces OLE DB so projetadas para ajudar a

    integrar suavemente os componentes clientes para proporcionar alta qualidade e possibilidade

    rpida de comercializao. Alm disso, OLE DB inclui uma ponte para ODBC que habilita

    suporte continuado para a grande quantidade de drivers ODBC disponvel hoje.

    O modelo de objetos OLE DB consiste de sete componentes principais, conforme a

    tabela 1:

  • 14

    Tabela 1 - Modelo de Componentes OLE DB

    Componente Descrio

    Enumerator Enumerators uma enumerao, um identificador para uma fontes de

    dados. Clientes que no esto customizados para uma base de dados

    especfica utilizam um enumerator para procurar uma fonte de dados

    para usar.

    Data Source Objetos Data Source contm as implementaes para conectar a uma

    fonte de dados, como um arquivo ou um DBMS. H uma fbrica de

    sessions neste objeto.

    Session Sessions provem um contexto para transaes(transactions) e podem

    ser implcita ou explicitamente manejadas. Um nico objeto Data

    Source pode criar sesses mltiplas. Sessions so uma fbrica para

    transactions, commands, e rowsets.

    Transaction

    (transaes)

    Objetos Transaction so usados quando se est executando ou

    abortando transaes aninhadas a outras de mais baixo nvel.

    Command Command executam um texto de comando, como uma instruo SQL.

    Se o comando especifica um rowset, como uma instruo SELECT de

    SQL, o comando uma fbrica para o rowset.

    Rowset Rowsets expem dados em formato tabular.

    Error Objetos Error podem ser criados por qualquer interface em qualquer

    objeto OLE DB. Eles contm informao adicional sobre um erro,

    incluindo, opcionalmente, um objeto de erro customizado.

    Fonte: ([MIC2000])

    Os componentes OLE DB interagem entre si, conforme a figura 2:

  • 15

    Figura 2 - Integrao dos componentes do OLE DB

    O objeto Data Source o primeiro objeto instanciado por um enumerator e contm a

    estrutura necessria para conectar fonte de dados subjacente.

    O objeto Session controla o escopo de transaes e responsvel pela gerao dos

    dados (rowsets) da fonte de dados (Data Source) subjacente. Podem ser associadas mltiplas

    sesses (Sessions) com um nico objeto Data Source. Se o provedor OLE DB suporta

    comandos, o objeto Session tambm age como uma fbrica de classe para objetos Command

    (fbricas de classe so responsveis pela gerao de objetos COM sob requisio).

    Se o provedor OLE DB suporta queries, tambm tem que expor um objeto Command.

    Pode haver vrios objetos Command associados com um nico objeto Session. O objeto

    Command, gerado pelo objeto de Session, responsvel por especificar, preparar e executar

    comandos SQL. O objeto pode ser criado por qualquer um dos outros objetos, caso ocorra

    algum erro.

  • 16

    ADO utiliza um conjunto de objetos (ver o modelo bsico de ADO no item 2.8) para

    prover uma interface muito simples e eficiente com OLE DB que, em troca, prov acesso para

    uma variedade muito grande de tipos de dados. Isto faz de ADO uma linguagem virtualmente

    independente.

    2.5.1 ADO E OLE DB

    Muitos podem estar se perguntando porque a Microsoft introduziu a camada ADO,

    em vez de permitir que os programadores acessem o OLE DB. O principal motivo a

    complexidade do OLE DB. O ADO encapsula mais de 60 interfaces OLE DB em cerca de 20

    objetos simples. Quando se utiliza ADO, no preciso preocupar-se com interfaces, alocaes

    de memria, contagem de referncias ou fbrica de classes (todos os quais so problemas do

    OLE DB) ([CAN2000]).

    Uma resposta alternativa que o ADO tem por objetivo as ferramentas de

    programao de alto nvel, como Visual Basic, que no conseguem tratar com interfaces

    COM atravs de objetos de nvel mais baixo. Em vez disso, foram criados alguns objetos

    ActiveX que empacotam a funcionalidade OLE DB, expondo aos programadores apenas os

    conceitos mais importantes de uma maneira mais simples e fcil de usar. Com ADO, todas as

    ferramentas que oferecem suporte a tecnologia ActiveX (sejam elas compiladores completos

    ou linguagens de scripts simples) podem se associar ao modelo UDA.

    OLE DB , ento, um conjunto de interfaces de baixo nvel que provem acesso para

    dados em uma variedade de formatos e localizaes. ADO prov uma interface amigvel para

    implementadores para fazer com que o trabalho com OLE DB e UDA seja uma tarefa

    relativamente fcil. No importa qual o ambiente de programao que se utilize, a interface

    usada para se ter acesso aos dados permanece constante. Esta interface ADO que em

    contrapartida usa OLE DB.

  • 17

    2.6 ADO E OLE DB COMO INTEGRANTES DE UDA MULTI PLATAFORMA

    Enquanto o sistema operacional WindowsNT (e tambm j o seu sucessor

    Windows2000) esto emergindo como plataformas importantes para administrao de banco

    de dados, muitas organizaes confiam em uma mistura de sistemas operacionais e

    plataformas de banco de dados. Para obter xito, qualquer estratgia de acesso a dados deve

    ter performance igual e eficincia em todas as principais plataformas. UDA prov o

    fundamento para suportar o acesso eficiente a dados nas principais plataformas de

    computao atuais. Produtos que usam a arquitetura UDA para ter acesso aos principais

    gerenciadores de banco de dados, atualmente j conseguem faz-lo em plataformas diferentes

    do Windows. Na figura 3 pode ser vista como seria esta interao.

    Figura 3 - UDA Multi Plataforma

    Fonte: ([MIC2000])

  • 18

    Isto possvel porque a especificao de OLE DB define componentes de interfaces

    que possibilitam a portabilidade em outros sistemas operacionais. OLE DB est baseado na

    arquitetura COM que um modelo de objetos Windows. Isto poderia implicar que

    componentes OLE DB rodariam somente em sistemas Windows, porm, surpreendentemente

    no isso. OLE DB tem dois enfoques separados que provem portabilidade para plataformas

    de sistemas gerenciadores de banco de dados diferentes do Windows ([MAR1999]).

    A ampla disponibilidade que a arquitetura UDA possibilita para as organizaes que

    suportam plataformas de sistemas de gerenciador de banco de dados mltiplas, mais um fato

    que evidencia que os sistemas que utilizarem OLE DB e ADO tero um benefcio adicional.

    Mas importante salientar que em nenhum momento foi referenciado uma camada de

    aplicao em outras plataformas diferentes do Windows. Todos os documentos analisados at

    aqui, sempre mencionam a multiplicidade de plataforma na camada de dados, e no da de

    aplicao.

    2.7 ARQUITETURAS DE CAMADAS

    Quando se desenvolve uma aplicao utilizando ADO, no preciso obrigatoriamente

    modelar esta aplicao em trs camadas.

    Apesar da popularidade das aplicaes em trs camadas estar crescendo, ainda h

    muito espao para aplicaes em duas camadas. Ento, quais os critrios para a escolha de

    uma ou outra opo? Segundo [MIC2000], deve-se adotar a arquitetura em trs camadas para

    aplicaes com as seguintes caractersticas:

    a) mais de 50 servios ou classes;

    b) aplicaes programadas em diferentes linguagens;

    c) duas ou mais fontes de dados heterogneas, tais como dois gerenciadores de banco

    de dados;

    d) expectativa de vida de mais de trs anos para a aplicao, especialmente quando so

    previstos novas verses do sistema;

    e) alto volume de transaes (mais de 50.000 por dia ou mais de 300 usurios

    acessando o sistema concorrentemente);

    f) necessidade de comunicao com diferentes aplicaes.

  • 19

    Apesar dessas caractersticas levarem a crer que somente grandes e complexas

    aplicaes so candidatas a serem desenvolvidas usando os conceitos de trs camadas, nada

    impede o uso desses mesmos conceitos em aplicaes menores, principalmente quando estas

    aplicaes envolvem objetos distribudos.

    Seguindo a histria dos modelos de camadas das aplicaes, verifica-se que

    inicialmente, os aplicativos de bancos de dados para PC eram solues apenas de clientes: o

    programa e os arquivos de dados ficavam no mesmo computador. Num segundo momento,

    alguns programadores j disponibilizaram um nico arquivo de dados, na rede. Os

    computadores clientes ainda continham o software aplicativo e o mecanismo de banco de

    dados inteiro, mas os arquivos de bancos de dados eram, ento, acessveis a vrios usurios

    simultaneamente ([CAN2000]).

    A prxima grande transio foi o desenvolvimento de cliente/servidor. Este modelo,

    que baseado em duas camadas, tem a maioria da sua lgica rodando no cliente, que envia

    requisies SQL para o gerenciador de banco de dados que reside no servidor.

    Na arquitetura em duas camadas, a lgica da aplicao pode estar localizada tanto na

    interface, com um cliente, quanto no gerenciador de banco de dados no servidor. A interface

    roda no cliente, que envia, via SQL, chamadas a arquivos de sistema ou comandos HTTP

    atravs da rede para o servidor, que ento processa a requisio e retorna os resultados. Para

    acessar os dados, os clientes precisam estar cientes de como os mesmos esto organizados e

    armazenados no servidor. Uma variao da abordagem em duas camadas usa procedimentos

    implementados no prprio gerenciador de banco de dados (stored procedures) para processar

    requisies SQL no servidor, reduzindo o trfego de rede.

    A grande popularizao da arquitetura em duas camadas deve-se sobretudo

    disponibilidade cada vez maior de ferramentas de desenvolvimento rpido (RAD) no mercado

    e na sua simplicidade. O Visual Basic e o Delphi so os atuais lderes nesse segmento de

    mercado ([CAN2000]).

    Apesar de, primeira vista, poder se achar que colocar todo o cdigo ou boa parte dele

    no cliente seja uma boa soluo devido ao poder cada vez maior de processamento dos

    microcomputadores, uma anlise mais detalhada na maneira como as aplicaes empresariais

  • 20

    e as regras de negcio realmente se comportam, pode levar a uma concluso totalmente

    diferente.

    As corporaes esto migrando para uma arquitetura cliente/servidor em trs camadas

    para compensar as limitaes da arquitetura em duas camadas. A camada adicional fornece

    um espao para as regras de negcio. Essa camada intermediria encapsula o modelo do

    negcio associado ao sistema e o separa da interface com o cliente e do banco de dados.

    A arquitetura em trs camadas est representada na figura 4:

    Figura 4 - Modelo de arquitetura de trs camadas

    Fonte: [MIC2000]

    Na tabela 2, pode-se verificar as caractersticas de cada camada:

    Tabela 2 - Caractersticas das camadas

    Camada Tipo de Servio Caracterstica Responsvel Por

    Interface com o usurio(Apresentao)

    Aplicaes cliente Interface Apresentao e navegao

    Regras de negcios Servidores de regras de negcio

    Objetos de negcio Polticas de negcio, regras e segurana

    Banco de dados Servidores de bancos de dados

    Gerenciadores de dados

    Integridade dos dados

    A primeira camada (servios do usurio) fornece a interface visual para apresentao

    das informaes e aquisio de dados. Essa camada contm vrios componentes aptos a

    representar e manipular dados.

  • 21

    Normalmente, o desenvolvimento da camada de servios de usurios dividido em

    duas partes:

    a) desenvolvimento do layout da interface, grficos e mensagens mostradas ao usurio.

    Isso geralmente atingido com a construo do prottipo da aplicao sem o uso de

    objetos de negcios;

    b) criao do cdigo especfico da aplicao no cliente. O desenvolvedor usa

    normalmente uma linguagem de alto nvel e os pontos de entrada para os vrios

    servios de negcios para criar o fluxo de controle requerido pela aplicao. O

    desenvolvedor preocupa-se mais com a aplicao do que com a complexidade da

    modelagem do negcio.

    A camada de servios de negcio, segunda camada, uma ponte entre o usurio e o

    servio de banco de dados. Ela responde a requisies dos usurios para a execuo de uma

    tarefa, atravs de procedimentos e regras de negcio.

    A terceira camada (servios de banco de dados) contm, conceitualmente, uma

    coleo de dados usados na camada de servios de regras de negcio para tomada de decises.

    Geralmente composta por um sistema gerenciador de banco de dados ou por uma coleo

    heterognea de bancos de dados que residem em diferentes plataformas.

    Na figura 5 pode-se verificar como a arquitetura de uma aplicao que utiliza MTS

    na camada intermediria, no nvel de transaes.

    Figura 5 - Arquitetura de aplicao MTS

    Fonte: ([MAR1999])

  • 22

    No exemplo da figura 5, demonstrado uma aplicao com trs camadas, baseada no

    modelo COM. Em aplicaes MTS, componentes de lgica de aplicao so executados sob

    controles MTS que so instanciados por componentes da camada intermediria, os quais

    interligam-se aos clientes pelas tecnologias COM ou DCOM, quando em ambientes

    distribudos. Clientes podem ser aplicaes convencionais, ou pgina ASP que funcionam sob

    servidores IIS.

    Os componentes de regras de negcio (ou lgica de aplicao para alguns autores)

    podem ter acesso a vrias fontes de dados diferentes, como MSMQ (Microsoft Message

    Queue Server), CICS (Customer Information Control System,) e outros.

    Tradicionalmente, a comunicao somente feita entre camadas adjacentes ou

    internamente. No entanto, aplicaes em trs camadas no necessariamente requerem

    hardware em trs camadas. Por exemplo, alguns dos componentes da camada intermediria

    podem ser implementados no mesmo servidor do banco de dados.

    A camada intermediria da maioria das aplicaes em trs camadas so compostas de

    uma coleo de componentes que so usadas em uma variedade de transaes de regras de

    negcio invocadas pelos clientes. Cada componente automatiza uma funo do negcio.

    Objetos distribudos so, por definio, componentes. Em sistemas de objetos

    distribudos, a unidade de trabalho e distribuio o componente.

    Os servios so compostos de componentes, que agem no contexto de uma camada.

    Enquanto um servio um conceito lgico, um componente descreve, atravs de cdigo, uma

    funcionalidade do negcio. Clientes geralmente utilizam-se de diversos componentes em uma

    nica transao.

    Quando se desenvolve a camada intermediria utilizando-se componentes, obtm-se

    os seguintes benefcios :

    a) a arquitetura baseada em componentes permite desenvolver aplicaes crticas

    decompondo-as em aplicaes menores, facilitando o desenvolvimento;

    b) aplicaes podem reutilizar componentes como se fossem caixas pretas;

    c) os clientes no necessitam saber qual o banco de dados que est sendo acessado,

    nem qual o componente que est atendendo sua solicitao;

  • 23

    d) pode-se incorporar componentes externos para ir montando uma aplicao.

    Obviamente isso s possvel atravs da adoo de algum padro comum de

    comunicao entre os componentes.

    Mas onde entra o ADO nisso tudo?

    ADO justamente a tecnologia que visa fazer a ponte entre a camada da aplicao e a

    camadas de regras de negcios, se existir esta camada. Caso contrrio, ADO ser a ponte

    direta entre a aplicao e a camada de dados. Os componentes ADO fazem essa ponte

    ([MIC2000]).

    Mas preciso atentar para a seguinte questo: quando se utiliza ADO em programas

    modelados em trs camadas e h alguma requisio que precise ser feita para a camada de

    dados, ADO faz o elo entre a camada de aplicao e a fonte de dados e, se necessrio for, ir

    passar pela camada intermediria antes de chegar camada de dados, fazendo uso dos

    mtodos ali implementados, sempre interagindo tambm com OLE DB ([MIC2000]).

    2.8 MODELO BSICO DE PROGRAMAO ADO

    Basicamente, para utilizar-se ADO a seguinte sucesso de aes suficiente:

    a) conectar a uma base de dados. Pode-se assegurar que a conexo obteve sucesso;

    b) especificar um comando (ao), com parmetros ou no;

    c) executar o comando;

    d) se o comando retorna dados, estes so armazenados numa estrutura particular, onde

    se possa facilmente alterar, inserir ou excluir informaes;

    e) se for apropriado, atualizar os dados armazenados (refresh);

    f) prover uma maneira de tratamento de excees, principalmente aps tentativa de

    conexo ou de executar algum comando

    Tipicamente, todo esse roteiro utilizado, porm algumas vezes parte dele

    suficiente. Por exemplo: pode-se armazenar as informaes aps a conexo e utiliz-las

    somente para consultas.

  • 24

    Na figura 6 apresentado graficamente o modelo bsico de ADO:

    Figura 6 - O Modelo Bsico do ADO

    Fonte: [MIC2000]

    Os objetos Connection, Command e Recordset podem ser criados e destrudos

    independentemente de cada um dos outros objetos. Eles no tem herana entre si. Pode-se

    dizer que so objetos irmos. Embora possa ser criado o objeto Parameter independentemente

    de um objeto Command, ele deve ser associado a um objeto Command antes de ser utilizado.

    Field, Error e Property so objetos que existem somente dentro do contexto do objeto que os

    implementa(objeto pai), e no pode ser criado separadamente.

    O objeto ADO Connection encapsula os objetos fonte de dados do OLE DB (Data

    Source). Ele representa uma nica sesso com a fonte de dados. O objeto Connection define

    propriedades da conexo, nomeia o escopo de transaes locais, prov uma localizao

    central para tratar erros, e prov um ponto para executar queries.

  • 25

    O objeto ADO Command equivalente ao objeto OLE DB Command. O Command

    especifica a definio de dados ou declarao de manipulao dos dados a ser executada. No

    caso de um provedor de dados relacionais, esta uma instruo SQL. O objeto Command

    permite especificar parmetros e customizar o comportamento da declarao a ser executada.

    Um conjunto de objetos Parameter expe esses parmetros. O objeto Parameter representa

    parmetros de um comando.

    O objeto ADO Recordset encapsula o objeto OLE DB Rowset. O objeto Recordset a

    interface atual aos dados. Podem ser dados resultantes de uma query ou gerados de outra

    forma. O objeto Recordset prov controle em cima do mecanismo usado, do tipo de cursor

    usado, do nmero de linhas para ter acesso de cada vez, e assim por diante. O objeto

    Recordset expe um conjunto de objetos Field que contm os dados sobre as colunas no

    Recordset, como o nome, tipo, durao, e preciso, como tambm os prprios dados.

    Recordset utilizado para navegar por registros de dados. A interface Field representa uma

    coluna em um Recordset que pode ser usado para obter e modificar valores. Esta interface

    quase idntica a modelos passados.

    A interface Error representa um objeto de erro retornado de uma fonte de dados. Esta

    interface opcional e s til quando o provedor de dados subjacente pode retornar erros

    mltiplos. Se o provedor de dados est impossibilitado de devolver erros mltiplos para uma

    nica chamada de funo, o provedor usar o mecanismo COM normal de erros, ou seja, as

    mensagens de erros normais baseadas na tecnologia COM.

    Cada um dos trs objetos principais ADO (Command, Connection e Recorset) contm

    um conjunto de objetos Properties. O objeto Properties permite que ADO exponha

    dinamicamente as capacidades de um provedor especfico. Pelo fato de nem todos os

    provedores de dados terem a mesma funcionalidade, importante que ADO modele isso, para

    permitir o acesso de modo dinmico em provedor de dados especficos. Isto tambm previne

    que o modelo ADO fique desordenado, cheio de propriedades que s esto disponveis em

    certas circunstncias ([MIC2000]).

  • 26

    2.9 APLICAES DISTRIBUDAS COM ADO

    A tecnologia ADO, diante do conceito que lhe atribudo, perfeita para ser utilizada

    em aplicaes distribudas. Sua principal caracterstica, que a independncia da fonte de

    dados, tambm muito til quando trata-se de aplicaes distribudas, pois permite que uma

    mesma interface (objeto que interage com o usurio), acesse a camada intermediria (e por

    conseqncia a de dados), seja esta ltima de que fonte for.

    Resumidamente, se o usurio de um aplicao distribuda que utiliza ADO no acesso

    aos dados quiser mudar sua fonte de dados, pode faz-lo sem alterar o objeto de interface.

    Basta fazer as devidas mudanas na conexo de seus dados com os componentes ADO. Os

    componentes ADO, fisicamente, so implementados no programa servidor dos objetos

    distribudos, porm isso no quer dizer que eles deixam de ser uma interface a nvel de

    aplicao, pois eles continuam fazendo a ponte entre a camada de aplicao e a camada

    intermediria, enviando as informaes oriundas da fonte de dados, via componentes

    especficos para essa funo, para a camada de aplicao. ADO o elo entre a fonte de dados

    e a aplicao, mas, numa modelagem em trs camadas, ADO fica no nvel mais alto, entre a

    aplicao e a camada intermediria, e OLE DB fica num nvel mais baixo, fazendo a ligao

    com a camada de dados.

    Utilizando ferramentas de programao que j suportam a tecnologia ADO, como o

    caso do Delphi 5.0, do Visual Basic e do C++, por exemplo, pode-se construir aplicaes

    distribudas utilizando os prprios recursos da ferramenta, e associando a programao

    distribuda com ADO.

    Porm, antes de mais nada, preciso conhecer um pouco mais de objetos distribudos e

    de ActiveX.

    2.9.1 OBJETOS DISTRIBUDOS

    Hoje em dia o termo objeto usado por muitas pessoas que quase nunca identificam

    sobre qual campo esto se referindo, o que causa grande confuso. Existem, pelo menos,

    quatro campos diferentes em que a orientao de objetos importante:

    a) linguagens de programao orientada a objeto: nas linguagens de programao

    orientadas a objetos os programadores podem escrever um cdigo usando um

  • 27

    modelo de objetos em vez dos modelos da programao mais tradicional, em que o

    cdigo e os dados so entidades separadas;

    b) software de sistemas orientados a objetos: o software de sistemas orientados a

    objetos fornece os blocos bsicos para manipular objetos no nvel do sistema

    operacional. Sistemas de objetos permitem que objetos criados por empresas

    diferentes, talvez utilizando linguagens de programao diferentes, trabalhem

    juntos;

    c) bancos de dados orientados a objetos: so sistemas gerenciadores de banco de dados

    que substituem o modelo de banco de dados relacional por um modelo orientado a

    objetos. Um banco de dados orientados a objetos projetado para armazenar dados

    e mtodos de objetos, com tcnicas que so eficientes para o processamento

    baseado em objetos;

    d) objetos distribudos: o software de sistemas orientados a objetos permite que

    objetos, em sistemas diferentes em rede, trabalhem juntos, ou seja, os objetos

    podem se comunicar entre si, mesmo que no estejam no mesmo computador;

    Segundo [HON1999], pode-se diferenciar os objetos clssicos dos objetos distribudos

    atravs das seguintes caractersticas:

    a) um objeto clssico possui propriedades e mtodos e gerado atravs de uma

    linguagem de programao como C++, Smalltalk, Delphi, entre outras. Esses

    objetos fornecem reusabilidade de cdigo atravs de herana, encapsulamento e

    polimorfismo, propriedades fundamentais da teoria orientada a objetos. Contudo,

    esses objetos s vivem dentro de um programa e apenas o compilador que os criou

    conhece a sua existncia. O mundo externo os desconhece e no tem forma de

    acess-los;

    b) um objeto distribudo tambm uma classe que pode publicar (tornar disponvel)

    tanto suas propriedades quanto os seus mtodos, mas a linguagem e compilador

    usados para criar objetos distribudos so totalmente transparentes para a

    implementao desses. Esses objetos tm uma interface definida, onde os

    compiladores geram um cdigo a mais para serem acessados por outros objetos de

    forma totalmente transparente, isto , o invocador desconhece o local do objeto

    invocado, o sistema operacional que esse executa, podendo estar fisicamente na

    mesma mquina (processo) ou em alguma mquina remota. Objetos distribudos

  • 28

    podem ser implementados utilizando-se tecnologias como Distributed Component

    Object Model (DCOM) e Common Object Request Broker Architecture (CORBA),

    que so os mais difundidos.

    Segundo ([HON1999]) as necessidades que existiam e que ainda existem, que levaram

    os pesquisadores e os empresrios a investirem tempo e recursos no desenvolvimento dos

    objetos distribudos e as vantagens e avanos que esse conceito oferece tm ntima relao

    com os fatores de reutilizao e heterogeneidade.

    A programao e o desenvolvimento de software tm sido uma questo de reinventar o

    que j existe. Toda vez que surge a necessidade de se construir um modelo, precisa-se refazer

    todos os passos j existentes. Com isso, o desafio para a maioria dos programadores tem sido

    justamente o parar de reinventar, construir um modelo padro e a partir desse modelo padro

    ter condies de implementar melhorias, desenvolvendo, desta forma, o conceito de

    reutilizao.

    No que se refere a heterogeneidade, existe cada vez mais a necessidade das aplicaes

    serem desenvolvidas independentemente de linguagens, de plataformas de hardware, de

    software e precisarem compartilhar informaes e invocar servios umas das outras.

    A princpio criaram-se as sub-rotinas que serviram como um artifcio para construo

    desse padro. O objetivo era a criao de uma biblioteca de sub-rotinas, as quais s

    precisariam ser codificadas e testadas uma nica vez, mas que pudessem ser reutilizveis em

    qualquer programa que solicitasse a mesma funo.

    Entretanto, as sub-rotinas s apresentaram um bom funcionamento em funes

    triviais, alm disso, no auxiliaram muito na criao de software reutilizvel.

    Atualmente, existe uma nova etapa na evoluo da informtica com a utilizao dos

    objetos, os quais surgem como a primeira oportunidade real de reutilizao e heterogeneidade

    de software, e que, quando disponveis em rede, do origem aos objetos distribudos.

    A tabela 3 demonstra como evidente a situao do mercado:

  • 29

    Tabela 3 - Comparao entre sistemas antigos e atuais

    Sistemas Antigos Sistemas Atuais

    Ambiente Centralizado Ambiente Cliente/Servidor

    Forte concentrao no processamento centralizado

    Concentrao na integrao e distribuio do processamento entre os computadores da rede

    Terminais burros, modo caracter Terminais com poder de processamento e interfaces grficas intuitivas e de fcil uso

    Dificuldade para o crescimento por limites na capacidade de processamento e alto custo do computador central

    Facilidade de crescimento por permitir que o ambiente seja escalvel e a um custo linear

    Falta de integrao dos sistemas Integrao e coexistncia passam a ser pr-requisitos

    No existncia da Internet Internet e comrcio eletrnico fundamental

    Fonte: ([SES1998])

    Objetos distribudos um paradigma da computao que permite a objetos serem

    distribudos atravs de uma rede heterognea, e permitir a cada componente a total

    interoperabilidade e acesso a outros objetos. Para uma aplicao escrita em um ambiente de

    objetos distribudos, objetos remotos so acessados como se estivessem na mquina que

    efetua as requisies. Um objeto distribudo essencialmente um componente, que pode

    interoperar com outros objetos distribudos atravs de sistemas operacionais, redes,

    linguagens, aplicaes, ferramentas e equipamentos diversos. Existe uma tendncia de se

    construir sistemas computacionais abertos utilizando objetos distribudos. Alm disso, esses

    objetos distribudos possuem as mesmas caractersticas principais dos objetos das linguagens

    de programao: encapsulamento, polimorfismo e herana, tendo, dessa forma, as mesmas

    principais vantagens: fcil reusabilidade, manuteno e depurao, s para citar algumas

    ([CAP1999]).

    Mas objeto distribudo no opera sozinho. A princpio ele construdo para trabalhar

    com outros objetos e, para isso, precisa de uma espcie de barramento. Tais barramentos

    fornecem infra-estrutura para os objetos, adicionando novos servios que podem ser herdados

    durante a construo do objeto, ou mesmo em tempo de execuo para alcanar altos nveis

    de colaborao com outros objetos independentes ([CAP1999]).

  • 30

    Dois exemplos desses barramentos de tecnologias que habilitam a computao

    distribuda so o CORBA da OMG, que utiliza como middleware o ORB (Object Request

    Broker) e o DCOM da Microsoft, que utiliza o COM (Component Object Model) como

    elemento que promove a comunicao entre um objeto-cliente e um objeto-servidor

    ([FRA1997],[CAP1999]). O CORBA especifica a arquitetura completa necessria

    comunicao entre objetos distribudos. Enquanto que a arquitetura DCOM, que encontra-se

    disponvel no Windows 95, no Windows NT e Windows 2000, possui total controle dessas

    plataformas. Entretanto, conforme [HON1999], essa arquitetura apresenta deficincias no que

    diz respeito sua utilizao em outras plataformas.

    2.9.2 ACTIVEX

    Conforme [MIC2000], ActiveX um conjunto de tecnologias que permitem construir

    aplicaes empresariais para a Internet e intranets que executam em plataformas mltiplas

    (at bem pouco tempo atrs a tecnologia ActiveX ainda no era aceita em outros sistemas

    operacionais, a no ser pelo seu criador, o Windows 95, e pelo WindowsNT). Atualmente,

    aplicaes ActiveX podem ser escritas em C, C++, Delphi e Java e podem ser executadas em

    plataformas como as da famlia Windows, Macintosh, e UNIX. Objetos Java e OLE

    atualmente suportam ActiveX . Por exemplo, pode-se criar uma aplicao para recuperar

    informaes escrevendo um applet Java para a interface de usurio e usando funcionalidade

    de um componente de software existente que conecta com um banco de dados.

    O que agora conhecido como controle ActiveX foi chamado originalmente controle

    OLE e estes controles exigiram um nmero grande de mtodos implementados. Isto os fez

    demasiadamente grandes. Eles estavam carregando e arrastando consigo tantas informaes e

    caractersticas de interface que os componentes OLE no podiam viajar com rapidez por uma

    conexo tpica da Internet. A partir da foi construda uma variedade mais gil e mais

    adaptvel, que so os controles ActiveX. Estes podem implementar s as caractersticas que

    so absolutamente necessrias para o funcionamento dos controles, e nenhuma carga

    desnecessria foi requerida.

    O ActiveX , ento, um novo nome para o novo enfoque, o do desenvolvimento para

    Internet, e engloba as tecnologias chave da Microsoft de reutilizao de funes

    programadas e fornecimento de servios entre aplicativos COM e OLE.

  • 31

    Os controles ActiveX no podem executar por si s. Eles precisam de um recipiente.

    Inicialmente, este recipiente era o Visual Basic mas atualmente h muito mais escolhas. Um

    exemplo especialmente importante de um recipiente de controle ActiveX hoje um browser.

    Um engano terminolgico muito comum, confundir ActiveX com os controles

    ActiveX. O ActiveX, como j foi exposto anteriormente, um conjunto de tecnologias e um

    controle ActiveX um objeto COM que segue certos padres ao interagir com seu cliente. Um

    controle ActiveX permite usar o mesmo controle em muitos contextos diferentes. Atravs de

    suas interfaces padronizadas, pode fazer virtualmente qualquer coisa e controla

    implementaes de todos os tipos de funes, alm de estar disponvel em vrias companhias

    de software atuais.

    Do mesmo jeito que um controle ActiveX usado num programa, ele poder ser usado

    numa pgina HTML, sozinho, como um applet da linguagem Java. Dependendo da aplicao,

    esses controles podem ser usados por leigos ou s por programadores. Pode existir um

    controle que o usurio s precise escrever uma frase para fazer o que ele quer, enquanto outro

    que trate com banco de dados precise de programao mais especfica.

    Os controles ActiveX foram criados com a finalidade de combinar duas reas distintas

    das tecnologias de informtica: os controles personalizados e uma redescoberta das idias

    bsicas que regem a OLE e a programao orientada a objetos. Esses controles so os

    primeiros controles baseados em DCOM (Distributed Component Object Model)

    ([KAU1997]).Um bom motivo, ainda conforme [KAU1997] para utilizar ActiveX, que esta

    tecnologia permite utilizar a OLE atravs da Web. Isto significa que pode ser usado um

    navegador Web como um front end para um processador de textos, planilha eletrnica, banco

    de dados e ainda vrios outros aplicativos.

    Segundo [BOR1999] a tecnologia ActiveX tem muita utilidade no desenvolvimento de

    aplicaes pequenas e sem necessidade de configurao para ambiente distribudo na Web

    com ou sem arquitetura de banco de dados Cliente/Servidor multicamadas.

    Com ActiveX, programadores e WEB designers, que so programadores que

    desenvolvem pginas para internet, podem criar contedo interativo com uma grande

    variedade de ferramentas e criando aplicativos mais atrativos e prticos.

  • 32

    3 DELPHI 5.0 - INOVAES DO AMBIENTE

    O Delphi est provando que uma ferramenta de desenvolvimento completa, capaz de

    agradar desde o pequeno desenvolvedor at a mais exigente corporao. Segundo

    [CAN2000], o Delphi 5.0 a verso mais completa em recursos dentro da famlia do produto.

    J existiam, conforme [CAN2000], desde o Delphi 3.0, alguns recursos importantes

    que a tornaram uma ferramenta muito poderosa. So eles:

    a) RAD (Rapid Application Development) um termo largamente utilizado hoje na

    rea de ferramentas de desenvolvimento que significa basicamente "alta

    produtividade". No Delphi 5.0 esto disposio mais de 140 componentes j

    prontos para serem utilizados, alm de uma imensa gama de bibliotecas

    desenvolvidas por terceiros com as mais variadas utilidades. Existem tambm

    recursos de ambiente como CodeInsight e CodeCompletion que ajudam no

    aprendizado da ferramenta garantindo um menor tempo para se alcanarem os

    resultados desejados;

    b) desenvolvimento multicamadas: o Delphi implementa a arquitetura multicamadas

    baseado em um middleware chamado MIDAS que usa a estrutura de distribuio de

    objetos DCOM da Microsoft. O Delphi tem um conjunto de componentes

    especficos para fornecer toda a funcionalidade de aplicaes distribudas e no

    necessrio um conhecimento profundo do DCOM para poder implementar

    multicamadas;

    c) programao orientada a objetos: com o Delphi, o desenvolvedor tem a capacidade

    de criar aplicaes utilizando a metodologia de programao orientada a objetos;

    d) aplicaes para servidores Web: permite a criao de aplicaes que sero

    executadas em servidores Web. Isso, na verdade, no significa apenas a criao de

    formulrios ActiveX para serem exibidos dentro de pginas Web, mas sim

    aplicaes realmente voltadas para servidores. O que importante ressaltar, nesse

    recurso, a independncia de padres de servidores que essas aplicaes possuem;

    Mas o Delphi 5.0 apresenta alguns novos recursos, muito importantes, apresentados na

    tabela 4.

  • 33

    Tabela 4 - Novos Recursos do Delphi 5.0

    Recurso Descrio

    Suporte a Active Server Object Wizard e ASP

    ASP um novo recurso do IIS (Internet Information Server), que fornece uma estrutura de aplicativo para desenvolvimento de funcionalidade mais poderosa em sites WEB. O Delphi 5.0 disponibiliza a utilizao deste recurso com facilidade.

    Componentes DataSet para ADO

    No Delphi 5.0 esto disponveis componentes ADO. Estes componentes so herdados da classe TDataSet e podem ser utilizados normalmente para apresentar e editar dados. Eles j implementam automaticamente a tecnologia ADO.

    Servidores COM em Componentes

    So componentes visuais, prontos para serem utilizados na programao distribuda atravs da tecnologia COM e DCOM. Atualmente j existem servidores COM em componentes prontos no ambiente Delphi.

    Diagramas de Dados O Delphi apresenta na verso 5.0 um diagrama de dados(faz parte do tambm novo Data Module Design). O Diagrama de dados mostra uma visualizao dos componentes, incluindo relacionamento mestre/detalhe, conexes de pesquisa, propriedades vinculadas e relacionamentos genricos.

    Data Module Designer Desde a verso 2.0 o Delphi tem usado a idia de mdulo de dados, que um continer de componentes relacionados aos dados da aplicao. No Delphi 5.0, o Data Module Designer permite selecionar componentes e conect-los de maneira fcil, usando a visualizao de rvore. Pode-se ver uma parte somente do aplicativo ou este como um todo.

    Internet Express uma arquitetura que implementa a idia de gerar pgina HTML na Web para permitir que qualquer usurio interaja com o servidor da camada do meio, atravs de um servidor Web. Seria uma arquitetura de quatro camadas: O servidor SQL, o servidor do aplicativo (pode ser um servidor MIDAS), o servidor Web e finalmente, o navegador da Web.

    MIDAS 3 O MIDAS um conjunto de tecnologias distintas que trabalham juntas para tornar mais fcil construir aplicativos distribudos com Delphi. No MIDAS 3 existe apenas uma interface de comunicao entre os aplicativos, enquanto nas verses anteriores existiam duas.

    Integrated Translation Environment (ITE)

    Um dos mais novos recursos do Delphi o ITE, que possibilita a traduo de ttulos de telas, descries, etc, para outras lnguas atravs do Translation Manager.

    Fonte : ([CAN2000])

  • 34

    3.1 BANCO DE DADOS NO DELPHI 5.0

    Os aplicativos de banco de dados Delphi no tm acesso direto s fontes de dados que

    fazem referncia e no podem manipular arquivos de bancos de dados diretamente. Em vez

    disso, eles usam um mecanismo de bancos de dados disponvel, como o Borland Database

    Engine (BDE) ou ActiveX Data Objects (ADO).

    Atravs da Figura 7, pode-se verificar como as tecnologias de acesso a dados

    alternativas so disponibilizadas no Delphi 5.0.

    Figura 7 - As tecnologias de acesso a dados alternativas disponveis no Delphi 5.0

    Fonte: ([CAN2000])

    O BDE tem acesso direto a vrias fontes de dados, incluindo dBase, Paradox, ASCII,

    FoxPro, a at tabelas Access. O BDE tambm pode fazer interface com o SQL Links da

    Borland, que consistem em uma srie de drivers que permitem acesso a vrios servidores SQL

    locais e remotos. Os servidores de banco de dados incluem Oracle, Sybase, Informix,

    InterBase, SqlAnywhere, DB2, etc. Se for necessrio fazer acesso com alguma base de dados

    ou algum formato de dados diferente, o BDE pode fazer a interface com os drivers ODBC,

    embora, neste caso, possa ser utilizado tambm o ADO. Os aplicativos construdos com os

    componentes ADO do Delphi 5.0, no exigem as bibliotecas BDE ([CAN2000]).

    BDE

    IBX

    OLE DB

    ADO

    SQL LinksODBC

    Aplicativos Delphi

    Paradox

    dBase

    Access

    InterBase

    Oracle

    MS SQL Server

    DB2

    SQLAnywhere

  • 35

    O IBX (InterBase Express) apresenta novos componentes que existem no Delphi 5.0

    projetados especificamente para acessar um banco de dados InterBase, sem precisar da BDE.

    3.2 DELPHI 5.0 E ADO

    Quando o Delphi foi projetado originalmente, a Borland possua o Paradox e o Visual

    dBase e, portanto, construiu um nico mecanismo de acesso a dados compartilhado por todos

    os seus produtos. Esse mecanismo o BDE. O BDE foi projetado para muitos servidores

    SQL, incluindo Oracle e InterBase, e para acessar outra origem de dados atravs de ODBC. O

    ODBC, entretanto, era originalmente muito lento e alguns dos drivers para formatos de

    bancos de dados especficos no estavam livres de erro. Com o passar do tempo, trs coisas

    aconteceram: primeiro, a Borland vendeu seus produtos de banco de dados de usurio final;

    segundo, o papel da Microsoft como fornecedora de banco de dados ficou maior(com o MS

    Access e o SQL Server ganhando cada vez mais aceitao no setor), aumentando a freqncia

    dos programas em trabalhar com banco de dados Microsoft; terceiro, a Microsoft

    aprimorou sua estratgia de acesso a dados, introduzindo RDO, OLE DB e ADO

    ([CAN2000]).

    A Borland reconheceu estas alteraes nos ltimos anos, incluindo drivers especficos

    para o MS Access. Usando o BDE possvel conectar-se a um banco de dados Access, mas

    isso implica em usar dois mecanismos de banco de dados simultaneamente quando uma

    conexo do Access atravs do ADO um vnculo mais direto. O Delphi 5.0 oferece suporte

    tecnologia ADO diretamente, atravs de componentes DataSet especficos.

    Na verdade, podem ser escritos programas ADO sem os componentes especficos que

    o Delphi 5.0 fornece. Entretanto, os componente ADO de conjunto de dados prontos para usar

    permitem que o programador implemente o ADO utilizando as mesmas tcnicas com as quais

    est habituado.

  • 36

    4 DESENVOLVIMENTO DO PROTTIPO

    4.1 O TUTOR INTELIGENTE PARA O AMBIENTE DELPHI

    O desenvolvimento do prottipo relacionado a este trabalho no inicia da estaca zero.

    Ele uma adaptao do Tutor Delphi, o qual foi implementado anteriormente, em outro

    Trabalho de Concluso de Curso, do curso de Bacharelado em Cincias da Computao,

    abordado em [FRA1999].

    Basicamente, o Tutor Delphi formado por trs etapas principais:

    a) cadastro de um exerccio de programao em Delphi, o qual deve conter todas as

    informaes necessrias para a execuo do exerccio, como por exemplo o objetivo

    do exerccio, os componentes que devero ser utilizados, os eventos associados a

    cada componente e a descrio da ao que cada evento dever disparar. Somente o

    professor poder cadastrar exerccios;

    b) a aprendizagem do exerccio, atravs da qual o aluno vai realizar o exerccio com

    ajuda de um agente, que ir auxili-lo, passo a passo, na execuo do exerccio. Esta

    etapa deve ser executada pelo aluno;

    c) a correo do exerccio, que realizada pelo tutor, o qual vai corrigir um

    determinado exerccio do aluno que est requisitando a correo. Tanto o professor

    quanto o aluno podem fazer as correes dos exerccio, mas se for um aluno que

    solicitar a correo, somente ser permitido fazer correes de exerccios feitos pelo

    prprio aluno. No caso do professor solicitar correo de exerccios, ele poder

    escolher qual o exerccio e de qual aluno pertence o exerccio que ser corrigido.

    Cada uma dessa etapas corresponde a um objeto, ou ainda, um agente. Ao cadastro dos

    exerccios, est ligado o objeto conhecimento. Esse objeto mantm o conhecimento do

    exerccio. A etapa de aprendizagem, corresponde ao objeto aprendiz. onde o conhecimento

    repassado ao aluno. A terceira etapa, a de correo do exerccio, corresponde ao objeto

    tutor, que faz a correo do exerccio realizado pelo aluno, armazena os erros e acertos,

    informando ao aluno e ao professor os resultados.

    Na figura 8, pode ser verificada a relao entre os objetos (agentes) do sistema.

  • 37

    Figura 8 - Relao entre os agentes

    Usurio(Professor/Aluno)

    Interface

    Agente Conhecimento

    Agente Aprendiz

    Agente Tutor

    Primeiramente o usurio interage com a interface do sistema. O usurio identifica-se e

    aps obter o acesso, poder iniciar a execuo dos agentes.

    Para maiores e mais detalhadas informaes sobre o conceito de agentes inteligentes e

    tambm sobre o sistema desenvolvido pode ser consultado [FRA1999].

    4.2 ESPECIFICAO DO PROTTIPO

    Como este prottipo uma adaptao, a especificao foi revisada e foram feitas as

    devidas alteraes, necessrias para a adequao com a atual verso.

    Partindo-se da premissa de que a UML uma linguagem de modelagem e no uma

    metodologia [FUR1998], ento ser demonstrada a modelagem do prottipo atravs da

    linguagem UML, utilizando-se uma metodologia de programao orientada a objetos. Para a

    modelagem, foram utilizados os diagramas de casos de uso, de classes e de seqncia, todos

    feitos na ferramenta de modelagem Rational Rose da Rational.

  • 38

    4.2.1 CASOS DE USO

    Algumas alteraes no Tutor Delphi, foram realizadas, para melhor adapt-lo ao

    propsito deste trabalho. Ao longo da especificao, sero destacadas as principais mudanas.

    Figura 9 Diagrama de Casos de Uso

  • 39

    So 4(quatro) os casos de uso identificados neste programa:

    a) cadastrar Usurio: responsvel pela entradas dos dados referentes aos usurios do

    sistema e a gravao dos mesmos na base de dados. Somente um usurio do tipo

    Professor pode cadastrar usurios. Mudana: Este caso de uso no existia na verso

    anterior. Naquela, o cadastro de usurio era livre, ou seja, qualquer aluno poderia

    ser cadastrado por qualquer usurio, no momento da execuo do exerccio. No

    havia restries em nvel de usurio, pois a classe usurio era utilizada apenas para

    fazer o relacionamento com um determinado exerccio;

    b) cadastrar Exerccio: a entrada dos dados referentes aos exerccios e a gravao dos

    mesmos nas entidades referentes ao conhecimento. Mudana: na verso anterior as

    informaes sobre o conhecimento ficavam gravadas em arquivos .INI e na verso

    atual, foram criadas novas tabelas de dados para armazenar estas informaes.

    Somente o professor poder cadastrar exerccios;

    c) aprender Exerccio: neste caso de uso, o aprendiz recebe o conhecimento e executa

    o exerccio, informando seus dados. Mudana: neste passo no houve grandes

    alteraes. O ponto principal que a origem do conhecimento no mais os

    arquivos .INI e sim as classes que armazenam o conhecimento;

    d) corrigir Exerccio: o usurio identificado pelo sistema, escolhe um exerccio e

    solicita a correo do mesmo. O sistema faz a correo e informa o resultado.

    Mudana: na primeira verso, havia duas classes (AprenderExerccio e

    ErrosCometidos) que armazenavam o resultado do exerccio. Nesta nova verso,

    h um objeto Tutor, que gerencia a correo dos exerccios e retorna os resultados

    desta correo para o professor ou aluno que solicitou a correo. Foi criada uma

    classe nica para armazenar os resultados dos exerccios.

  • 40

    4.2.2 DIAGRAMA DE CLASSES

    A figura 10 demonstra o Diagrama de Classes.

    Figura 10 - Diagrama de Classes

    Generalizao

    Agregao

    Usuario

    CdigoNomeSenhaTipoData Do CadastroData Atualizao

    Dados Usurio( )

    1 0,n

    Evento

    Ordem de CriaoCdigo do EventoDescrioBinrio

    GravaEventos( )

    1

    0,n

    Componente

    Cdigo do ComponenteQtde. de Componentes

    GravaComponente( )

    o,n

    1

    Professor

    InformaConhecimento( )GravaUsuario( )

    0,n1

    Conhecimento

    Cdigo do ExerccioNome do ExerccioDescrioTotal de ComponentesImagem

    CadastraConhecimento( )DadosConhecimento( )

    0,nTutor

    CorrigidoVezes CorrigidoSucesso CorreoVezes AprendidoSucesso AprendizadoErro CometidoClasse ErroSubClasse ErroVezes Erro

    RetornaErrosUsuario( )CorrigirExercicio( )ArmazenaAprendizagem( )

    1

    Aluno

    Aprender( )

  • 41

    Existem 7 (sete) classes identificadas no sistema:

    a) usurio: corresponde aos usurios cadastrados no sistema e controla os acessos dos

    tipos de usurios (professor e aluno). Mudana: nesta verso a classe tem

    especializ