FACULDADE MATER DEI REVISTA DE INFORMÁTICA FACULDADE MATER DEI REVISTA DE INFORMÁTICA MATER DEI. Vol. 3 número 3 ano 2006 Anual. Pato Branco Paraná

Transcrição

1 FACULDADE MATER DEI MATER DEI Vol. 3 número 3 ano 2006 Anual Pato Branco Paraná 1

2 Catalogação na fonte por: Berenice de Lima Rodrigues/Bibliotecária CRB-9/1160 R454 Revista de Informática Mater Dei / Faculdade Mater Dei. -- Pato Branco, PR, v. 3, n. 3, jan./dez Periodicidade: anual ISSN: X 1. Informática - Periódicos. CDD:

3 MATER DEI ÓRGÃO DE DIVULGAÇÃO CIENTÍFICA DO CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO DA FACULDADE MATER DEI ISSN X Vol. 3 número 3 ano 2006 Anual Pato Branco - Paraná 3

4 Os artigos publicados na Revista de Informática Mater Dei são de responsablidade de seus autores. As informações neles contidas, bem como as opiniões emitidas, não representam pontos de vista da Instituição de Ensino Superior: Faculdade Mater Dei. Diretor Geral Vice-Diretora Geral Diretor Executivo Coordenador de Sistemas de Informação Editor Supervisor Editorial Conselho Consultivo Dr. Guido Victor Guerra Profa. Ivone Maria Pretto Guerra Prof. Rubens Fava Prof. Géri Natalinho Dutra, Mestre pela UFPR Prof. Omero Francisco Bertol, Mestre pela PUC-PR Prof. Dirceu Antonio Ruaro, Doutor pela UNICAMP Prof. Ademir Roberto Freddo, Mestre pelo CEFET-PR Profa. Andréia Smiderle, Mestre pela UFPR Profa. Beatriz Terezinha Borsoi, Mestre pela UFPR Prof. Edenilson José da Silva, Mestre pela UFPR Prof. Fernando José A. Schenatto, Mestre pela UFSC Prof. Fernando Schütz, Mestre pela UFSC Prof. Géri Natalino Dutra, Mestre pela UFPR Prof. Henrique Oliveira da Silva, Doutor pela UFRGS Prof. Marcos Vinícius de Bortolli, Mestre pela UFPR Profa. Soelaine Rodrigues, Mestre pela UFSC Secretária Editorial Diagramação e Capa Revisão Ortográfica Marisol Tomasini Dutra Lilyane Helena Sartori Maureen Elizabeth D Aquino Mendry Impressão (46) Faculdade Mater Dei Fone: (46)

5 APRESENTAÇÃO A utilização de ferramentas de informática na atualidade é fator indiscutível. O que torna-se prioridade é oferecer recursos e espaços para a divulgação de tantas novidades. Com periocidade anual, a revista do curso de Sistemas de Informação da Faculdade Mater Dei pretende ser um elo entre a instituição e a comunidade na questão da informática, abrindo uma nova possibilidade para que acadêmicos, professores e profissionais da área, apresentem o resultado de seus estudos e pesquisas. Todos os envolvidos no processo de criação do terceiro volume desta revista acreditam que a modernidade pode ser suplantada a cada dia e cabe a eles buscar os caminhos para que um número cada vez maior de pessoas possa usufruir de tanto conhecimento, aplicando-o no seu dia-a-dia, o que resulta na melhoria da qualidade de vida de todos. A Faculdade Mater Dei sente-se orgulhosa de oferecer à comunidade esta revista que, muito mais do que um informativo técnico, é uma das novas janelas para a inclusão digital. Dr. Guido Victor Guerra Diretor Geral 5

6 6

7 NOTA DO EDITOR Neste terceiro número da Revista de Informática Mater Dei, são apresentados artigos de professores, pesquisadores, especialistas, acadêmicos e profissionais da área de informática. Na abertura o acadêmico Maykon Titon apresenta o seu trabalho de diplomação no qual descreve a implementação de um framework para criação e manutenção de bancos de dados através de sentenças SQL. No artigo seguinte, o professor Robison Cris Brito e o acadêmico Juliano Simionatto, falam sobre a linguagem Java na automação industrial. A seguir, a pesquisadora e professora Rúbia Eliza de Oliveira Schultz, apresenta parte da sua pesquisa de mestrado abordando algoritmos de programação genética. No quarto artigo, o especialista Luciano Basso Buzzacaro, discorre sobre a importância da administração de recursos de hardware e software em ambientes corporativos. Concluindo a primeira metade da revista, um grupo de acadêmicos do Departamento de Sistemas de Informação da UNIPAR de Cascavel, apresentam uma proposta para a geração de interfaces adaptativas. No artigo seguinte, Jair Ott e Pablo A. Michel, também acadêmicos da UNIPAR, abordam a importância do gerenciamento de riscos em projetos de desenvolvimento de software. Ainda nesta edição, o analista de sistemas, Evandro Miguel Kuszera, descreve a implementação de um firewall baseado em GNU/Linux que utiliza as funcionalidades de bridging e filtro de pacotes fornecidos pelo kernel do sistema operacional. Em seguida, a mestranda Lissandra Luvizão Lazzarotto e seu colega Alcione de Paiva Oliveira, apresentam aspectos teóricos e aplicações relacionadas ao data mining e às redes neurais. Completando esta edição, o professor Elcio Luiz Pagani Bortolin, fala sobre a configuração de acesso remoto com autenticação de usuários através dos modelos de segurança radius e portslave. No último artigo, o professor Jorge Roberto Grobe e o acadêmico Gustavo Julian Grobe, descrevem a aplicação da estatística em resultados de análise de solos utilizando o aplicativo Microsoft Excel. Boa Leitura! Prof. Omero Francisco Bertol, M.Sc. omero@utfpr.edu.br Editor 7

8 8

9 SUMÁRIO ARTIGO 1 - MAYKON TITON FRAMEWORK PARA CRIAÇÃO E MANUTENÇÃO DE BANCOS DE DADOS SQL...11 ARTIGO 2 ROBISON CRIS BRITO E JULIANO SIMIONATTO JAVA NA AUTOMAÇÃO INDUSTRIAL...19 ARTIGO 3 - RÚBIA ELIZA DE OLIVEIRA SCHULTZ PROGRAMAÇÃO GENÉTICA: EVOLUINDO PROGRAMAS DE COMPUTADOR...27 ARTIGO 4 - LUCIANO B. BUZZACARO ADMINISTRAÇÃO DE RECURSOS DE HARDWARE E SOFTWARE EM AMBIENTE CORPORA- TIVO...37 ARTIGO 5 - DOUGLAS T. S. FINKLER, ANDRÉ A. DOS SANTOS, MARILSON M. DOS SANTOS E GIANI CARLA ITO UMA PROPOSTA PARA A GERAÇÃO DE INTERFACES ADAPTATIVAS...45 ARTIGO 6 - JAIR OTT E PABLO A. MICHEL A IMPORTÂNCIA DO GERENCIAMENTO DE RISCOS EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE: ESTUDO DE CASO DO SISTEMA DE CONTROLE DE VEÍCULOS...51 ARTIGO 7 - EVANDRO MIGUEL KUSZERA IMPLEMENTAÇÃO DE BRIDGING FIREWALL UTILIZANDO GNU/LINUX...59 ARTIGO 8 - LISSANDRA LUVIZÃO LAZZAROTTO E ALCIONE DE PAIVA OLIVEIRA ASPECTOS TEÓRICOS E APLICAÇÕES RELACIONADOS AO DATA MINING E ÀS REDES NEURAIS...65 ARTIGO 9 - ELCIO LUIZ PAGANI BORTOLINI CONFIGURAÇÃO DE ACESSO REMOTO COM AUTENTICAÇÃO DE USUÁRIOS ATRAVÉS DE RADIUS E PORTSLAVE...75 ARTIGO 10 - JORGE ROBERTO GROBE E GUSTAVO JULIAN GROBE APLICAÇÕES DA ESTATÍSTICA USANDO MICROSOFT EXCEL

10 10

11 ARTIGO 1 FRAMEWORK PARA CRIAÇÃO E MANUTENÇÃO DE BANCOS DE DADOS SQL MAYKON TITON 1 titonmk@yahoo.com.br RESUMO A utilização de bancos de dados baseados no padrão SQL fornece meios relativamente simples de realizar mudanças na estrutura dos dados através de scripts SQL; contudo, o gerenciamento desses scripts torna-se um problema à medida que aumenta a demanda por alterações na base de dados. Para minimizar esse problema, é necessário o uso de um Framework capaz de facilitar as operações com o banco de dados. Neste cenário este artigo, que se baseia na monografia de minha autoria com o título de Framework para criação e manutenção de bancos de dados SQL em Delphi para.net, visa descrever os principais aspectos relacionados ao funcionamento do Framework proposto. 1. A QUESTÃO DA ATUALIZAÇÃO DAS ESTRUTURAS DE DADOS 1 Universidade Tecnológica Federal do Paraná (UTFPR). Muitos dos aplicativos atualmente desenvolvidos utilizam algum tipo de banco de dados. Na maioria dos casos, é utilizado um banco de dados com suporte à linguagem SQL (Structured Query Language, ou Linguagem de Consulta Estruturada), pelo fato de que esse é o padrão dominante de bancos de dados, especialmente para uso comercial. Grande parte das aplicações que utilizam bancos de dados tem um problema relacionado à atualização de suas estruturas de dados, quando se faz necessário modificar a mesma: é necessário desenvolver scripts em SQL capazes de transformar uma estrutura já existente, que está em uso, para uma nova estrutura, de forma que não ocorra perda das informações já incluídas. Nessa categoria encontram-se vários tipos de modificações, como a adição ou exclusão de colunas em uma tabela, manutenção de stored procedures e triggers, entre outras coisas que eventualmente necessitam de modificações em uma base de dados. Tais alterações são feitas através de scripts no padrão SQL, capazes de modificar as estruturas anteriormente citadas. No caso de aplicativos desenvolvidos como Sistemas de Informação corporativos, esse cenário de modificação das estruturas de dados é relativamente comum, a fim de adaptar o sistema às necessidades da empresa. Especialmente nesses casos, o problema da atualização do modelo lógico das informações armazenadas é bem significativo, e despende um certo esforço para criar, manter e distribuir os scripts responsáveis pela atualização de cada versão do modelo lógico. Além disso, como cada script é construído presumindo uma estrutura de dados específica, eles se tornam obsoletos assim que uma nova atualização do modelo lógico de informações se faz necessária. Também há o problema das atualizações seqüenciais: se uma determinada base de dados encontra-se em uma versão X, e ela deve ser atualizada para uma versão X+k, é necessário que seja feita a execução do script que atualiza a versão X para a versão X+1, depois o script que atualiza a versão X+1 para a versão X+2, e assim por diante, até X+k; isso acontece porque cada script presume a existência de uma determinada estrutura de dados, e a única forma de garantir que essa estrutura vai estar de acordo com o esperado é fazendo as atualizações em seqüência. Tudo isso gera um problema de distribuição desses scripts, e necessita de algum esforço para que esse processo seja estruturado. Com o uso de um Framework que seja capaz de lidar com esses problemas, todo o processo de manutenção das estruturas de dados, triggers e stored procedures seria desnecessário, pois o próprio Framework seria responsável por gerar os comandos SQL necessários para tornar a estrutura lógica de informações existente no 11

12 servidor de banco de dados igual ao modelo descrito através do uso do Framework. Ou seja, com o uso do Framework proposto todo o trabalho atribuído à criação e manutenção de scripts SQL direcionados para a manutenção das estruturas de dados não seria mais necessário, reduzindo assim o esforço para modificar o modelo lógico de armazenagem das informações utilizadas por um aplicativo. Por conseqüência, o Framework também seria responsável por criar a base de dados, caso ela ainda não esteja criada no SGBD. Também é interessante prover, através do Framework, uma estrutura capaz de fornecer um controle de versão das estruturas de dados utilizada pelo aplicativo. 2. SGBD E O PADRÃO SQL Um SGBD (Sistema Gerenciador de Banco de Dados) é o conjunto de softwares capazes de realizar o gerenciamento de uma base de dados. O principal objetivo de um SGBD é retirar da aplicação cliente a responsabilidade de gerenciar o acesso, manipulação e organização dos dados, permitindo que através de uma interface padronizada seja possível que seus clientes incluam, alterarem ou consultem informações. Em bancos de dados relacionais a interface é constituída pelas APIs (Application Programming Interface) ou drivers do SGBD, que executam comandos na linguagem SQL. Na definição de Korth e Silberschatz (1989), um SGBD pode ser definido por:... uma coleção de arquivos inter-relacionados e um conjunto de programas, que permitem a diversos usuários acessar e modificar esses arquivos. Um propósito central de um sistema de banco de dados é proporcionar aos usuários uma visão abstrata dos dados. Isto é o sistema esconde certos detalhes de como os dados são armazenados ou mantidos. Porém, para que o sistema seja utilizável, os dados precisam ser recuperados eficientemente. Segundo Garcia-Molina e Ullman (2001), um SGBD é caracterizado por:... sua habilidade de admitir o acesso eficiente a grandes quantidades de dados, os quais persistem ao longo do tempo. Eles também são caracterizados por seu suporte para linguagens de consulta poderosas e transações duráveis que podem ser executadas de forma concorrente de um modo que parece atômico e independente de outras transações. Um sistema gerenciador de banco de dados é caracterizado por ser extremamente complexo, sendo responsável pela persistência, organização e recuperação dos dados. Basicamente, um SGBD é responsável por disponibilizar: Métodos de acesso; Integridade Semântica; Segurança; Controle de Concorrência; Independência. Existem vários modelos de implementação desses requisitos. Do ponto de vista da aplicação cliente, a característica fundamental é a questão do método de acesso, que consiste normalmente da utilização de uma linguagem padronizada, na qual a aplicação cliente pode fazer requisições ao SGBD. Normalmente esta linguagem é dividida em partes: Linguagem de definição de dados (DDL, Data Definition Language, do inglês). Linguagem de manipulação de dados (DML, Data Manipulation Language, do inglês). A fim de suprir essa necessidade de definição de linguagens para tratamento das partes acima citadas, foi desenvolvido o padrão SQL que é amplamente utilizado nos SGBDs atuais. A linguagem SQL então opera como um meio de comunicação entre o cliente e o SGBD, sendo capaz de suportar todas as especificações estabelecidas para a DDL e DML em um determinado SGBD. A SQL (Structured Query Language, ou Linguagem de Consulta Estruturada), é uma linguagem de pesquisa declarativa para bancos de dados relacionais. O padrão SQL deriva da Álgebra Relacional, e muitas de suas funções são derivadas desse modelo. Existem muitas versões da SQL. Originalmente, essa linguagem foi desenvolvida pela IBM no Laboratório de Pesquisa de San José, e implementada inicialmente como parte do projeto do Sistema R no início dos anos 70. Com o tempo a SQL se estabeleceu como um padrão, 12

13 vindo a incorporar a maioria dos produtos comerciais atuais. Em 1986 o ANSI (American National Standards Institute) e a ISO (International Standards Organization) estabeleceram um padrão para a SQL. Em 1989 foi publicada uma extensão para esse padrão, e em 1992 foi feita uma nova revisão, gerando assim o padrão SQL- 92, que é amplamente difundido. A linguagem SQL pode ser dividida em diversas partes: Linguagem de definição de dados (DDL, Data Definition Language), que proporciona comandos para definição de esquemas de relações, exclusão de relações, criação de índices e modificação nos esquemas de relações. Linguagem interativa de manipulação de dados (DML, Data Manipulation Language), é uma linguagem de consulta baseada tanto na álgebra relacional quanto no cálculo relacional de tuplas. Também inclui comandos para adição, exclusão e modificação de tuplas (linha de uma relação) no banco de dados. Definição de visões: uma parte da SQL DDL que possui comandos para definição de visões. Autorização: parte da SQL DDL com comandos responsáveis por definir permissões de acesso a relações e visões. Integridade: Outra parte da SQL DDL, possui comandos para especificação de regras de integridade que os dados armazenados devem obedecer. Isso inclui a manipulação de chaves primárias, chaves estrangeiras, restrições de valores de domínio, entre outros. Controle de transações: A SQL inclui comandos para especificação de inicialização e finalização de transações no banco de dados. Por se tratar de um padrão extremamente difundido, a SQL representa uma alternativa viável para ser utilizada no Framework proposto. 3. MODELO DE IMPLEMENTAÇÃO É notório o problema que existe para criar, manter e distribuir scripts SQL de atualização da base de dados. A necessidade de alterar as estruturas lógicas de armazenamento de informações em softwares da área de Sistemas de Informação é relativamente alta, e de uma forma geral ocorre com freqüência significativa em qualquer software que faça uso de um SGBD. Para resolver esse problema, o Framework proposto visa disponibilizar ao desenvolvedor de software uma forma simples de manter atualizada a estrutura lógica das informações utilizada por seus aplicativos. Isso é feito através de um conjunto de classes capazes de abstrair as estruturas de dados, tornando-as simples de serem manipuladas. O Framework, chamado de DataStruct, consiste essencialmente das seguintes classes: TInst: Responsável pelo processo de criação e manutenção das estruturas de dados no servidor. É capaz de abstrair tabelas, índices, restrições, stored procedures e triggers e fornecer uma forma estabelecer controle de versão sobre o modelo de dados. TSQLGen: Uma classe especial, cujos métodos são abstratos, utilizada como interface entre a classe TInst e as classes responsáveis por gerar os scripts SQL específicos de cada SGBD. Seus métodos abstratos são utilizados como um indicativo do que as classes descendentes devem implementar. TDSConnection: Classe com métodos abstratos, utilizada como interface entre a classe TInst e a classe que realiza a conexão efetiva com o banco de dados. Essa classe não é instanciada diretamente, mas sim as suas classes descendentes. Seus métodos abstratos são utilizados como um indicativo do que as classes descendentes devem implementar. TDSQuery: Com objetivos semelhantes à classe TDSConnection, compõe-se de uma coleção de métodos abstratos, que atuam como uma interface, especificando o que as classes descendentes devem implementar. As classes descendentes de TDSQuery devem implementar as funcionalidades descritas nesta classe, que são relativas a consultas de dados. Essa classe não é instanciada diretamente. TTableDescriptions: Classe capaz de encapsular uma coleção de objetos TTableDescriptionItem. Esta classe é encapsulada por TInst. TTableDescriptionItem: Descreve os dados referentes a uma tabela, como seu nome e campos no banco de dados. TFieldDescriptions: Armazena uma coleção de TFieldDescriptionItem e é utilizada por TTableDescriptionItem. 13

14 TFieldDescriptionItem: Abstrai os dados referentes aos campos de uma tabela no banco de dados. As classes acima descritas representam o núcleo do Framework. Contudo, há uma série de classes auxiliares, como classes que descrevem os índices, restrições, stored procedures e triggers. A idéia básica de funcionamento do Framework é a seguinte: em um primeiro momento, todas as estruturas de dados são definidas na forma de instâncias de classes do DataStruct. Uma vez definidas estas informações, é chamada uma rotina de uma instância de TInst, que vai se conectar ao banco de dados e comparar as estruturas de dados existentes no servidor com a estrutura de dados que está definida na forma de instâncias de classes naquele momento. Após identificar as diferenças, os comandos SQL necessários para tornar o modelo de dados no SGBD igual à estrutura definida em memória na forma de instâncias de classes são gerados e emitidos para o banco de dados. Ao final da rotina, a estrutura dos dados no servidor é igual à estrutura de dados definida localmente, na forma de instâncias de classes. Dessa forma, o programador não se preocupa em momento nenhum sobre os comandos SQL que devem ser enviados para o SGBD a fim de adaptar a estrutura de dados existente às novas necessidades. Tudo o que o programador precisa fazer é adicionar a estrutura lógica necessária nas instâncias das classes do DataStruct, e o próprio Framework se encarrega de gerar os comandos SQL necessários para efetivar a alteração de estrutura dos dados, dispensando o esforço de criar, manter e distribuir scripts SQL para realizar tal tarefa. A questão de como obter as informações da estrutura de dados presente no SGBD é uma tarefa difícil, pois os metadados (dados sobre os dados, ou seja, a especificação de que dados estão armazenados e quais as suas características) são armazenados de formas diversas, dependendo do SGBD utilizado. A fim de resolver esse problema, o DataStruct gerencia tabelas de metadados criadas e mantidas pelo próprio Framework, que contém os metadados necessários para efetivar a operação de atualização do modelo lógico de dados anteriormente descrita. Devido à grande quantidade de instruções SQL específicas de cada SGBD, bem como variações de sintaxe de comandos de uso geral, é necessário modularizar a geração do código SQL efetivo. Por isso, a classe TInst é responsável apenas por abstrair as principais características das estruturas de dados, enquanto que um descendente da classe TSQLGen implementa de fato a montagem dos comandos SQL. Assim, para cada SGBD pode ser desenvolvida uma classe descendente de TSQLGen específica, sem precisar alterar o código existente na classe TInst. Tal modularização também facilita enormemente a utilização de vários SGBDs por uma única aplicação, já que, essencialmente, basta alterar a classe descendente de TSQLGen utilizada por TInst para que os comandos SQL gerados pelo DataStruct sejam compatíveis com outro SGBD. Como a conexão com o SGBD pode ser feita com o uso de diversas tecnologias de acesso a dados, uma classe descendente de TDSConnection deve ser utilizada, de acordo com a tecnologia que se deseja utilizar. Por conseqüência da diferença entre classes de cada tecnologia de acesso a dados, é preciso abstrair também a consulta aos mesmos (query). Isso é feito através de uma classe descendente de TDSQuery, construída para implementar consultas através de uma tecnologia de acesso a dados específica. Na figura 1 podem ser vistas as dependências das principais classes do Framework: Figura 1. Dependências das principais classes do Framework Estão presentes também no DataStruct uma série de classes que auxiliam a manipulação dos 14

15 metadados. De uma forma geral, essas classes não possuem funcionalidades especiais codificadas em métodos, e são utilizadas essencialmente para armazenar informações utilizados por outras classes. Nessa categoria estão as classes TFieldMetadata, TIndexData, TIndexMetadata, TConstraintData, TPrimaryKeyData, TPrimaryKeyMetadata, TForeignKeyData, TForeignKeyMetadata, TUniqueKeyData, TUniqueKeyMetadata, TCheckConstraintData, TCheckConstraintMetadata, TStoredProcedureData, TStoredProcedureMetadata, TTriggerData e TTriggerMetadata. Nas figuras 2 e 3 pode-se visualizar a hierarquia de tais classes. Figura 2. Hierarquia das classes de dados de constraints Na figura 2 estão as classes que abstraem informações relacionados a restrições (constraints) no banco de dados. Dessas, TConstraintData é a classe base das demais classes citadas e contém algumas propriedades comuns a todos os tipos de restrições de dados, como o nome da restrição e o nome da tabela a que se aplica a restrição. As classes imediatamente descendentes de TConstraintData representam tipos específicos de restrições: TPrimaryKeyData: Contém as informações necessárias para descrever uma restrição do tipo chave primária. TForeignKeyData: Contém as informações necessárias para descrever uma restrição do tipo chave estrangeira. TUniqueKeyData: Contém as informações necessárias para descrever uma restrição do tipo chave única. TCheckConstraintData: Contém as informações necessárias para descrever uma restrição do tipo checagem (check). Já as classes do terceiro nível, descendentes das classes TPrimaryKeyData, TForeignKeyData, TUniqueKeyData e TCheckConstraintData são utilizadas para representar os metadados armazenados no próprio SGBD. Figura 3. Hierarquia das demais classes de suporte do Framework Presentes na figura 3, existem mais algumas classes de suporte do Framework. TFieldMetadata é uma classe capaz de armazenar os metadados de um campo de tabela, e uma instância dessa classe representa uma tupla da tabela de metadados de campos mantida pelo Framework. TIndexData e TIndexMetadata são classes complementares, utilizadas para abstrair os dados relativos a um índice no banco de dados, onde a primeira é capaz de abstrair os as informações essenciais de um índice, enquanto a segunda abstrai uma tupla completa da tabela de metadados de índices mantida pelo DataStruct. As últimas classes, TStoredProcedureData e TTriggerData, são utilizadas para abstrair as informações de Stored Procedures e Triggers, respectivamente; já suas classes descendentes TStoredProcedureMetadata e TTriggerMetadata são capazes de abstrair uma tupla completa da tabela de metadados de Stored Procedures e Triggers. 4. MODELO DE UTILIZAÇÃO A utilização do DataStruct é relativamente simples. O primeiro objeto instanciado normalmente é da classe TInst, já que esta classe agrupa toda a definição do modelo lógico. Em seguida, um objeto de geração de SQL deve ser instanciado (descendente de TSQLGen), de acordo com o SGBD utilizado, e ligado à classe TInst através da propriedade SQLGenerator presente na classe TInst. Do ponto de vista da geração do código SQL efetivo proporcionado por descendentes de TSQLGen, atualmente existe suporte para quatro SGBDs diferentes no DataStruct: SQLServer, MySQL, Interbase e Oracle, que são providos pelas classes TSQLServerGen, TMySQLGen, 15

16 TIBSQLGen e TOraSQLGen, respectivamente. Vale lembrar também, para adicionar suporte a outros SGBDs basta implementar uma classe descendente de TSQLGen com a sintaxe e comandos específicos para o SGBD desejado. A partir desse ponto já é possível utilizar esse novo SGBD em conjunto com o DataStruct, bastando ligar uma instância dessa nova classe a uma instância de TInst. O último passo é adicionar os componentes de conexão ao SGBD. O DataStruct tem suporte a duas tecnologias de acesso a dados, que estão presentes na linguagem em que foi implementado: dbexpress e dbgo. Essas duas tecnologias são suportadas pelas classes TDbExpConnection e TDbGoConnection, respectivamente. Estas classes são descendentes de TDSConnection, e funcionam como uma interface entre a classe de conexão específica da tecnologia escolhida e o DataStruct; por isso, além dessas classes de interface, é necessário adicionar uma instância da classe de conexão com o SGBD específica da tecnologia que se pretende utilizar. As classes descendentes de TDSConnection não implementam o protocolo de comunicação em si, atuando apenas como mediadores entre o DataStruct e o acesso efetivo ao SGBD. Uma vez adicionadas as instâncias das classes de conexão efetiva com o SGBD e a instância da classe de interface com o DataStruct, basta ligar o objeto de interface com a instância de TInst, através da propriedade DSConnection presente em TInst. Um exemplo típico do uso do DataStruct está demonstrado na figura 4. dbexpress. A ligação entre esses objetos pode ser visualizada na figura 5. Figura 5. Ligações entre os objetos do exemplo de uso do DataStruct (em vermelho) A definição do modelo lógico dos dados pode ser feita através de métodos disponíveis na classe TInst. Para isso existem métodos que definem tabelas, campos de tabelas, índices, restrições, Stored Procedures e Triggers. Tais métodos devem ser incluídos em eventos específicos disponíveis na classe TInst, como demonstrado na figura 6. Figura 6. Eventos de definição do modelo lógico de dados. Figura 4: Exemplo de uso do DataStruct Na figura 4, o objeto Inst é uma instância de TInst; OraSQLGen1 uma instância de TOraSQLGen; DbExpConnection1 uma instância de TDbExpConnection e SQLConnection1 uma instância de TSQLConnection, que é a classe de conexão com o SGBD nativa da tecnologia Uma vez definidas as instâncias de classes necessárias e o modelo lógico dos dados, basta efetivar uma chamada ao método InstallSystem da classe TInst, em tempo de execução do aplicativo, para que a estrutura definida nas instâncias de classes do aplicativo seja comparada com a estrutura existente no servidor, e as altera- 16

17 ções necessárias sejam feitas automaticamente. Assim, sempre que necessário o programador apenas altera a definição do modelo lógico nos eventos de TInst, sem se preocupar de forma nenhuma com as implicações em gerar scripts SQL para modificar a estrutura dos dados no SGBD. 5. CONSIDERAÇÕES FINAIS O uso do DataStruct facilita em muito a manutenção de bases de dados. Através dele é possível dispensar a criação e manutenção de scripts SQL necessários para alterar o modelo lógico dos dados utilizados por um software. Devido à enorme flexibilidade do DataStruct, é possível implementar o suporte a praticamente qualquer SGBD utilizando uma ampla gama de tecnologias; isso é possível graças às classes que fornecem uma interface padronizada tanto na questão da geração do código SQL efetivo para um SGBD quanto na interface com a tecnologia de acesso a dados. Além disso, a abstração da conexão com o SGBD possibilitada através das classes TDSConnection e TDSQuery, permite que seja possível implementar suporte a praticamente qualquer tecnologia de acesso a dados, bastando implementar descendentes dessas classes utilizando a tecnologia desejada. Do ponto de vista da tecnologia envolvida, o DataStruct representa um modelo funcional e padronizado de definição da estrutura lógica de dados utilizada por um aplicativo, facilitando a manutenção da mesma. Não obstante o DataStruct seja implementado em uma linguagem específica, o modelo de classes e funcionamento pode ser implementado em qualquer linguagem, representando uma alternativa testada e comprovada em relação a qualquer outro modelo de definição de dados existente. Em última análise, o uso do DataStruct aumenta a produtividade do desenvolvedor de software, já que dispensa uma série de atividades necessárias para manter uma base de dados. REFERÊNCIAS GARCIA-MOLINA, Hector; ULLMAN, Jeffrey D.;WIDOM, Jennifer. Implementação de Sistemas de Banco de Dados. Rio de Janeiro: Campus, Pg 19. KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistema de Bancos de Dados. São Paulo: McGraw- Hill, TITON, Maykon. Framework para criação e manutenção de bancos de dados SQL em Delphi para.net. Monografia (Tecnólogo em Sistemas de Informação) UTFPR, Pato Branco. 17

18 18

19 ARTIGO 2 JAVA NA AUTOMAÇÃO INDUSTRIAL ROBISON CRIS BRITO 1, JULIANO SIMIONATTO 2 robison@pb.cefetpr.br julianosimionatto@gmail.com RESUMO Este artigo apresenta as informações necessárias para o desenvolvimento de aplicativos Java que utilizam a porta serial e paralela. A utilização dessas portas se torna necessário no processo de automação, onde o software acessa remotamente dispositivos eletro-eletrônicos como lâmpada e sensores. utilizada, pois pode-se usar todo o poder computacional, como Sistemas Gerenciadores de Banco de Dados e acesso a rede, unindo-o com o ato de acionar equipamentos, abrir portas, ligar dispositivos e ainda poder receber informações do meio, como temperatura e pressão. Vale lembrar que esses hardwares podem ser acionados via Internet, ou ainda via dispositivos móveis, onde o usuário pode enviar ou receber informações de qualquer parte do mundo. O segredo para que um programa possa trabalhar com outros hardwares são as portas de comunicação serial e paralela. Essas portas podem enviar e receber bits. Estes, sendo recebidos e interpretados por circuitos eletrônicos, chamados interfaces de comunicação, que devem ser compatíveis com o tipo de comunicação: serial ou paralela. Essas interfaces podem ser desenvolvidas ou adquiridas em eletrônicas. Seu funcionamento também pode variar de acordo com a necessidade do aplicativo. 1. INFORMAÇÕES GERAIS A utilização de um ambiente computacional para o acionamento de dispositivos é algo que vem sendo explorado há muitos anos, desde os primeiros filmes de ficção científica, onde personagens controlavam equipamentos ou verificavam seus estados utilizando telas de computadores ou ainda comandos de voz. Com a difusão dos computadores, esse tipo de operação tornou-se cada vez mais freqüente. Inicialmente os programadores utilizavam linguagens de programação mais complexas, como C ou ainda, assembler. Com o avanço das linguagens de alto nível, começaram a ser desenvolvidas rotinas e componentes para o acesso a esse tipo de recurso, sem a necessidade do programador estudar arduamente seus conceitos e funcionalidades. A automação é uma técnica cada vez mais 1 Professor da UTFPR Campus Pato Branco PR - Brasil. Via do Conhecimento, Km 1 - Pato Branco PR Acadêmico da UTFPR Campus Pato Branco PR - Brasil. Figura 1. Estrutura de um aplicativo que utilize acionamento/ recepção remota A Figura 1 exibe o funcionamento de um aplicativo que utiliza o processo de Automação. O computador, que na verdade pode ser um PDA, ou mesmo um celular desde que tenha uma porta de comunicação, executa o software desenvolvido. Esse software, modifica as informações binárias existentes nas portas serial ou paralela do computador, que por sua vez é ligado em um dispositivo eletrônico chamado interface. Esse dispositivo deve ser compatível com a porta utilizada pelo sistema desenvolvido, se o mesmo utiliza a comunicação pela porta paralela (ex. porta da impressora, chamada DB-25P). Assim, deve ser desenvolvida uma interface para receber essas informações no padrão paralelo, acionando interruptores ou liberando energia elétrica para algum acionamento. Também pode ocor- 19

20 rer o inverso, onde sensores enviam informações do ambiente para a interface, que encaminham essas informações para a porta serial/paralela, onde o software fica recebendo as variações dos sinais. Atenção As portas seriais e paralela estão ligadas diretamente à placa mãe de seu computador. Muito cuidado ao conectar circuitos eletrônicos a essa porta, pois, uma descarga elétrica ou um componente com a polaridade invertida poderá causar danos irreparáveis ao seu computador. Figura 2 Comunicação Paralela, cada bit é representado por uma linha de comunicação e devem chegar ao destino ao mesmo tempo. 2. COMUNICAÇÃO SERIAL X PARALELA É importante, antes do desenvolvimento de um aplicativo que utilize automação, conhecer as principais características - particularidades, vantagens e desvantagens - da comunicação serial/paralela. A comunicação paralela é a mais simples de programar. Por serem enviados todos os bits simultaneamente, são necessários vários pinos para comunicação. Para enviar um byte (8 bits) são necessários 8 pinos, por esse motivo periféricos que utilizam essa comunicação, como algumas impressoras, necessitam de cabos onde no seu interior se encontram vários fios, e esses cabos devem ser curtos, para não acontecer o espalhamento de bits (os bits sofrem atrasos aleatórios na transmissão, quanto menor o cabo, menor o espalhamento). Outra desvantagem da comunicação paralela é que quando ligamos o computador (boot), o mesmo costuma enviar informações para os pinos paralelos, a fim de fazer testes, e se tiver dispositivos ligados a essa porta, os mesmos serão ligados e desligados de forma aleatória. Na Figura 2, pode-se ver como funciona a comunicação paralela e na Figura 3 a porta paralela existente em alguns computadores. Figura 3 Conectores DB25 Macho e DB25 Fêmea, o último é encontrado em alguns computadores para ligar a impressora. Na comunicação serial, como o próprio nome sugere, os bits são enviados em série, um após o outro, e para saber onde termina um byte e começa o outro, é utilizada uma taxa de transmissão, chamada baudrate, fazendo com que o transmissor e o receptor trabalhem na mesma velocidade. Na comunicação serial pode ser usado apenas dois fios, um para enviar informação e outro para receber. Os cabos costumam ser mais finos e seu comprimento pode ser maior do que um cabo paralelo. Hoje, essa é a tecnologia mais utilizada, a prova é a substituição das portas serias e paralelas tradicionais por portas seriais USB (Universal Serial Bus ou barramento serial universal). A desvantagem da serial está no hardware que receberá essas informações, que são mais complexos. Na Figura 4 temos o funcionamento da comunicação serial e na Figura 5 é apresentada a porta serial tradicional encontrada em grande parte dos computadores. Figura 4 Porta Serial, os bits são enviados um após o outro, sendo utilizado uma única linha de comunicação. 20