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

UTILIZAÇÃO DA TECNOLOGIA ACTIVEX DATA...

Documents

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

Angela tratamento medicamentodo -ado

Manual Para ado de Motores

Soluções SAP BO (Business Objects)

Treinamento Kanban Avanï¿½ado

4ª aula slides-ado

Diorgnes Almir Postel Flavio Jose Sciacca …tcconline.utp.br/media/tcc/2014/09/PRONTUARIO-ELETRONICO.pdf · LlSTA DE SIGLAS ASP - Active Server Pages ADO -Active Data Objects (Dados

OBJETOS DA Forest FLORESTA Objects of the • Download the ...

Relating Declarative Hypermedia Objects and Imperative ... · Relating Declarative Hypermedia Objects and Imperative Objects through the NCL Glue Language Luiz Fernando Gomes Soares

Sumário - Representante Oficial Scriptcase · Treinamento Scriptcase Professional – Online ... Utilizando macros no Scriptcase Controlando Tempo de sessão Trabalhando com “Activex

Voz Passiva - Artigo - Sintaxe ado

resa ação - Representante Oficial Scriptcase · Treinamento Scriptcase Iniciante – Online ... Utilizando macros no Scriptcase Controlando Tempo de sessão Trabalhando com “Activex

3ª Aula Slides - Ado

Business Objects BI, Análise e emissão de relatórios

3a aula slides-ado

Apresentação - SAP Business Objects BI ondemand

CONTEXTUALIZAÇÃO DE “LEARNING OBJECTS” NOrecipp.ipp.pt/bitstream/10400.22/2638/1/DM...CONTEXTUALIZAÇÃO DE “LEARNING OBJECTS” NO ENSINO DA ÁREA DA SAÚDE. O CASO DO ENSINO

Regra de contratação de MUSD por permissionárias · Regras de faturamento do MUSD: Permissionárias (regra atual) Demais agentes (regra geral) o ado o ado o ado MUSD ... • Cenário

TRAB INFANTIL FOR€ADO BRASIL

TEST ADO & APRO V ADO Hardbandingcastolin-eutectic-oiltec.com/sites/default/files/ckfinder/files/pt... · TEST ADO & APRO V ADO • Diseño Libre de Grietas • Amigable al Casing

ADMINISTRAÇÃO - BACHAREL ADO - MATUTINO