UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE
PROGRAMA DE PÓS-GRADUAÇÃO EM AUTOMAÇÃO INDUSTRIAL - PGAI
Formação: Mestrado em Automação Industrial
DISSERTAÇÃO DE MESTRADO OBTIDA POR
Fabrício Noveletto
Desenvolvimento de um Ambiente de Programação
Visual Orientado a Objetos para Robôs Móveis
Apresentada em 10 / 10 / 2003 perante a banca examinadora:
Prof. Dr. Antonio Heronaldo de Sousa - Presidente - CCT/UDESC Prof. PhD. Alcy Rodolfo Carrara - PUC/PR
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE
PROGRAMA DE PÓS-GRADUAÇÃO EM AUTOMAÇÃO INDUSTRIAL - PGAI
DISSERTAÇÃO DE MESTRADO
Mestrando: FABRÍCIO NOVELETTO – Engenheiro Eletricista Orientador: Prof. Dr. ANTONIO HERONALDO DE SOUSA – CCT/UDESC
Desenvolvimento de um Ambiente de Programação
Visual Orientado a Objetos para Robôs Móveis
DISSERTAÇÃO APRESENTADA COMO REQUISITO À OBTENÇÃO DO TÍTULO DE MESTRE EM AUTOMAÇÃO INDUSTRIAL DA UNIVERSIDADE DO ESTADO DE SANTA CATARINA, CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT, ORIENTADA PELO PROFESSOR DR. ANTONIO HERONALDO DE SOUSA.
AGRADECIMENTOS
Ao amigo e orientador, Professor Antonio Heronaldo de Sousa por sua dedicação e sabedoria no acompanhamento em todos estes anos de estudo.
A professora Regina de Felice Souza pelo seu incentivo, apoio e presteza. Ao Professor Marcelo da Silva Hounsell por suas significantes contribuições no decorrer deste trabalho.
A todos os professores do Departamento de Engenharia Elétrica e a coordenação do Mestrado em Automação Industrial.
A minha esposa Elaine por seu apoio irrestrito durante toda esta jornada. A família de minha esposa e toda minha família por estar sempre ao meu lado em todos os momentos de minha vida, em especial meu pai Ademar, minha mãe Eronildes e minha irmã Alessandra.
Ao amigo Adriano Bresolin pelo companheirismo em todos estes anos de estudo.
SUMÁRIO
SUMÁRIO ... I
RESUMO ...IV
ABSTRACT...V
INTRODUÇÃO GERAL ...
1Motivação... 1
Objetivo... 1
Justificativa ... 2
Delimitação ... 3
Panorama geral da dissertação ... 3
CAPÍTULO 1: ROBÔS MÓVEIS
Introdução ... 51.1. Considerações iniciais... 5
1.2. Evolução dos robôs móveis ... 6
1.3. Robôs móveis e suas aplicações ... 10
1.3.1. Robôs industriais ... 10
1.3.2. Robôs de serviço... 11
1.3.3. Robôs de campo ... 11
1.4. Característica dos robôs móveis ... 12
1.5. O Robô Khepera ... 13
1.5.1. Motores e controle do motor... 15
1.5.2. Sensores infravermelhos de proximidade e luz ambiente ... 18
1.5.3. O protocolo de comunicação serial ... 22
1.6. Linguagens de programação para robôs móveis ... 23
1.6.1. Ambientes de programação para o robô Khepera... 24
CAPÍTULO 2: PROGRAMAÇÃO VISUAL ORIENTADA A OBJETOS
Introdução ... 29
2.1. Evolução das linguagens de programação ... 29
2.2. O paradigma da programação orientada a objetos ... 32
2.3. Elementos da programação orientada a objetos ... 33
2.3.1. Abstração ... 34
2.3.2. Encapsulamento... 34
2.3.3. Herança ... 35
2.3.4. Polimorfismo... 36
2.4. O conceito de objeto ... 37
2.4.1. Métodos internos e variáveis públicas ... 40
2.5. O conceito de classes ... 41
2.6. Hereditariedade... 44
2.7. Considerações finais sobre programação orientada a objetos... 46
2.8. Linguagem de Programação Visual ... 47
2.9. Alguns aspectos sobre o uso de linguagens visuais ... 48
2.10. Linguagens visuais orientadas a objetos... 51
CAPÍTULO 3: DESENVOLVIMENTO DO AMBIENTE K++
Introdução ... 533.1. A linguagem de programação K++... 53
3.1.1. Hierarquia e descrição de classes... 54
3.1.2. Tipologia e representação de dados ... 56
3.1.3. Estruturas de controle ... 58
3.1.4. Operações dedicadas... 59
3.2. O ambiente de programação K++ ... 61
3.3. Implementação do ambiente K++... 63
3.4. As classes Serial e Khepera ... 64
3.4.1. A classe Serial... 64
3.4.2. A classe Khepera ...65
3.4.2.1. Descrição dos métodos da classe Khepera... 67
CAPÍTULO 4: RESULTADOS OBTIDOS
Introdução ... 81
4.1. Usando o ambiente de programação K++... 81
4.2. Programação procedimental usando o K++ ... 84
4.2.1. Exemplo 1 – Robô AGV... 85
4.2.2. Exemplo 2 – Robô AGV... 87
4.2.3. Exemplo 3 – Robô Explorador... 88
4.2.4. Exemplo 4 – Robô Explorador... 91
4.3. Programação orientada a objetos usando o K++ ... 92
4.3.1. Exemplo 1 – Robô Explorador... 92
4.3.1.1. Definindo a classe Explorador ...92
4.3.1.2. Definindo o objeto AGV ... 93
4.3.2. Exemplo 2 – Robô que se move em direção à luz ... 94
4.3.2.1. Definindo a classe Besouro... 95
4.3.2.2. Definindo o objeto BEETLE ... 96
4.4. Programação avançada usando o Visual C++ ... 99
CONCLUSÃO...103
Melhorias futuras e possíveis desdobramentos ... 104
REFERÊNCIAS BIBLIOGRÁFICAS ...105
ANEXOS...109
RESUMO
Este trabalho apresenta um estudo sobre o desenvolvimento de um ambiente de programação para robô móvel, chamado K++. Foi usado como base para o desenvolvimento do ambiente o paradigma da programação orientada a objetos,
conjuntamente com a programação visual.
A principal característica deste ambiente é usar, em conjunto, estruturas gráficas e estruturas textuais para melhor representar dados e algoritmos. O K++ combina características como a reusabilidade da programação orientada a objetos e a acessibilidade da programação visual. O uso de estruturas visuais orientadas a objetos, melhoram a qualidade e a acessibilidade das informações trocadas no desenvolvimento de algoritmos para robôs móveis.
Além disso, através de uma classe desenvolvida para implementar a comunicação com o robô móvel, o ambiente K++ permite simulações em tempo real. Neste sentido, os resultados dos testes com algoritmos desenvolvidos com o K++ foram amplamente satisfatórios.
ABSTRACT
This work presents a study on the development of a environment programming for mobile robots, called K++. It was used as base for the development of the environment the paradigm of the object-oriented programming, jointly with to
visual programming.
The main characteristic of this environment is to use, together, structures graphs and textual structures for best to represent data and algorithms. K++ combines characteristics as the reusability of the object-oriented programming and the accessibility of the visual programming.
The use of visual structures object-oriented, they improve the quality and the accessibility of the information changed in the development of algorithms for mobile robots. Besides, through a class developed to implement the communication with the mobile robot, the K++ environment allows simulations in real time. In this sense, the results of the tests with algorithms developed with K++, they were thoroughly satisfactory.
INTRODUÇÃO GERAL
• Motivação
Os robôs móveis estão cada vez mais presentes dentro das empresas e em outras diversas áreas, executando as mais variadas tarefas. Mas apesar do crescente número de aplicações onde é feito o uso da robótica móvel, a tarefa de programar um robô ainda oferece bastante dificuldade. Além da tecnologia sofisticada do próprio robô, os softwares empregados na sua programação são bastante complexos e exigem um alto grau de conhecimento relacionado à linguagem de programação. Sendo assim, a dificuldade em programar robôs faz com que menos pessoas possam realmente explorar as potencialidades dos robôs e de suas aplicações.
• Objetivo
Este trabalho tem por objetivo desenvolver uma linguagem de programação para robôs móveis, que minimize as dificuldades encontradas na maioria das linguagens de programação usadas para este propósito. Com isto objetiva-se aumentar o universo de pessoas capazes de desenvolver aplicações para robôs móveis. Para este trabalho utilizou-se como referência o robô móvel Khepera.
Desta forma propôs-se utilizar os conceitos da programação orientada a objetos em conjunto com os conceitos da programação visual. A utilização destes conceitos deu origem a uma nova linguagem de programação visual orientada a objetos chamada de K++ (em alusão ao robô Khepera).
A idéia central da linguagem K++ é combinar as principais características obtidas com o uso da programação visual e da programação orientada a objetos: a acessibilidade e a reusabilidade, respectivamente.
Mais especificamente, além do desenvolvimento de um ambiente de programação para robôs móveis, o presente trabalho objetivou a implementação dos mecanismos de interação com um robô real, através da utilização das estruturas da linguagem K++.
• Justificativa
O ambiente de programação visual orientado a objetos para robôs móveis K++ se justifica pela necessidade do aprimoramento e desenvolvimento de novas
ferramentas que possam auxiliar a programação e o uso desses robôs, uma vez que há um crescente número de estudos envolvendo o uso dos robôs móveis. (NOVELETTO, 2003a) (NOVELETTO, 2003b) (NOVELETTO, 2003c).
Uma das dificuldades envolvidas na pesquisa de robôs móveis está no custo do próprio robô. O seu alto custo acaba muitas vezes inviabilizando bons projetos. Neste sentido, optou-se usar para a validação do ambiente K++ o robô móvel Khepera, que possui funcionalidades semelhantes às de robôs móveis de maior porte, sendo amplamente usado na comunidade acadêmica e científica. A grande vantagem do uso de robôs móveis de pequeno porte para o estudo e o desenvolvimento de aplicações está justamente em seu tamanho e custo reduzidos, pois permite a criação de ambientes para simulações com maior facilidade e com menor custo (MONDANA, 1993).
Em geral a programação desse tipo de robô é realizada de forma textual, através do compilador GNU C ou com o uso de ambientes de programação visual como o LabVIEW® e o MatLab®. Um dos problemas no uso da programação textual está no elevado nível de envolvimento com detalhes intrínsecos à linguagem C. Já com o uso dos ambientes de programação visuais citados, por serem softwares fechados, ocorre uma perda na flexibilidade de programação do robô, uma vez que apenas o uso das bibliotecas desses ambientes limita o desenvolvimento de aplicações para o robô. Neste sentido, o K++ por ser um software aberto, permite que futuras modificações possam ser feitas de acordo com as necessidades do projeto.
O K++ foi desenvolvido com a ferramenta de programação Visual C++, que usa a linguagem C++, dando suporte a programação orientada a objetos. Além disso, essa ferramenta visual permite que as alterações no software possam ser feitas com maior agilidade (KRUGLINSKI, 1996).
No ambiente proposto (K++), o uso do paradigma da programação orientada a objetos em conjunto com a programação visual possibilita o reuso de funções e
minimiza os erros de programação, garantindo desta forma um maior grau de produtividade no desenvolvimento de aplicações para o robô.
O K++, por ser uma linguagem visual, usa uma simbologia gráfica para representar dados e classes e a programação é feita de forma estruturada baseada em arranjos gráficos. Além disso, a linguagem K++ utiliza ícones para representar as operações dedicadas efetuadas pelo robô.
O desenvolvimento de algoritmos de forma visual possibilita a ocultação de detalhes de implementação, focando a programação no nível da aplicação. Já o uso de ícones e de elementos visuais de programação possibilita a criação de algoritmos
de maneira bastante produtiva, facilitando a compreensão do algoritmo.
• Delimitação
A delimitação da pesquisa realizada neste trabalho se restringe ao desenvolvimento de uma linguagem visual de programação orientada a objetos para robôs móveis. Especificamente o ambiente permitirá que as aplicações desenvolvidas com o K++ sejam executadas diretamente em um robô Khepera real. Além disto, está previsto para um trabalho futuro, a geração do código em linguagem C relativo ao algoritmo desenvolvido no K++, para que o robô possa operar em modo autônomo.
• Panorama geral da dissertação
No capítulo 1 são feitas algumas considerações que têm por objetivo proporcionar uma visão mais ampla a cerca dos robôs móveis e suas aplicações. Com base no conhecimento dos aspectos gerais que englobam a robótica móvel, é possível compreender melhor a real necessidade de se criar ferramentas de desenvolvimento de aplicações.
O capítulo 2 faz um breve apanhado sobre os principais tipos de linguagens de programação, e dá a sustentação teórica necessária para melhor compreender os objetivos embutidos na escolha da programação visual em conjunto com a programação orientada a objetos como plataforma para este trabalho.
O capítulo 3 aborda os aspectos envolvidos no desenvolvimento do ambiente de programação visual orientado a objetos para robô móvel, chamado de K++. Estes aspectos contemplam a idéia de se usar os paradigmas da programação orientada a objetos em conjunto com a programação visual para melhorar o desenvolvimento de aplicações para robôs móveis com simulação em tempo real usando o próprio robô. Além do uso desses paradigmas de programação, o desenvolvimento do ambiente também leva em consideração os aspectos psicológicos de aprendizagem envolvidos no processo.
O capítulo 4 mostra a implementação de algoritmos através do ambiente de
programação K++. Neste capítulo também são abordados alguns aspectos sobre a utilização do ambiente K++, bem como, todo o processo de criação de algoritmos usando a programação procedimental e a programação orientada a objetos neste ambiente. Por fim, serão apresentados alguns aspectos sobre o uso de programação avançada para o desenvolvimento de novos métodos a partir do Visual C++.
Encerrando o trabalho, são relatadas as conclusões do trabalho e sugeridas as propostas para trabalhos futuros.
CAPÍTULO 1
ROBÔS MÓVEIS
Introdução
As considerações feitas neste capítulo têm por objetivo proporcionar uma visão mais ampla a cerca dos robôs móveis e suas aplicações. Com base no conhecimento dos aspectos gerais que englobam a robótica móvel, é possível compreender melhor a real necessidade de se criar ferramentas de desenvolvimento de aplicações.
1.1 Considerações iniciais
De acordo com a Robotic Industries Association (RIA) um robô pode ser definido como sendo um manipulador programável multifuncional, capaz de mover materiais, partes, ferramentas ou dispositivos específicos através de movimentos variáveis programados para realizar uma variedade de tarefas (RUSSEL, 1995).
O termo robô se origina da palavra tcheca robota, que significa trabalho escravo. Este termo foi usado pela primeira vez em 1921 na peça teatral Rossum’s Universal Robots, escrita pelo escritor tcheco Karel Capek (ASIMOV, 1994). Desde então a palavra robô vem sendo utilizada para se referir às máquinas que executam trabalhos para ajudar as pessoas.
Ao longo da história o homem evoluiu criando mecanismos para facilitar sua vida. Neste sentido, os robôs vêm cumprindo um papel importante na vida do homem moderno estando presentes em um número cada vez maior principalmente dentro das indústrias.
A competitividade do mercado estabelece a necessidade de se produzir com maior velocidade, maior qualidade e menores custos, o que justifica a crescente utilização de robôs dentro dos processos industriais. Outra importante aplicação na área de robótica é o uso de robôs móveis para a execução de tarefas consideradas de risco para o homem. Tarefas como a exploração de ambientes insalubres,
manuseio de material radioativo, localização de minas terrestres e submarinas, são alguns exemplos das aplicações para os robôs móveis.
1.2 Evolução dos robôs móveis
No final da década de 40, o professor W. Grey Walter, um renomado neurofisiologista, construiu duas tartarugas eletromecânicas bastante avançadas para aquela época (DI PAOLO, 1998). Seu interesse era estudar o comportamento destes robôs móveis, que por ele foram denominadas de tartarugas. Do ponto de
vista mecânico e eletrônico, estas tartarugas eram bastante simples: os movimentos eram feitos por três rodas montadas em triciclo, sendo duas de propulsão e uma de direção, e eram comandadas por motores elétricos independentes para cada uma delas. Os sentidos eram determinados por um sistema de sensoriamento bastante simples, formado por um sensor de luz e um sensor de contatos, montados externamente. A alimentação de energia era fornecida por uma bateria comum, montada na parte de trás da tartaruga, e uma carapaça de plástico abrigava e protegia todo o conjunto. A figura 1.1 mostra uma tartaruga sem a carapaça.
Figura 1.1. Tartaruga eletromecânica desenvolvida por Walter
O processador a bordo das tartarugas era extremamente simples: um circuito analógico com apenas duas válvulas eletrônicas, que comandavam os motores das rodas e de direção a partir da informação dos sensores. As tartarugas podiam fazer apenas duas coisas: evitar obstáculos grandes, recuando quando batia em algum, e seguir alguma fonte de luz. Quando a fonte de luz era muito intensa, o robô recuava, ao invés de avançar.
Apesar dos notáveis estudos desenvolvidos por W. Grey Walter, alguns autores identificam como o primeiro robô móvel construído, um robô desenvolvido pelo Stanford Research Institute em 1968, chamado Shakey (GROOVER, 1988). Este robô tinha uma grande variedade de sensores, que incluíam uma câmara de vídeo e sensores de toque e navegava entre as salas do laboratório, enviando sinais de rádio a um computador, que permitia efetuar algumas tarefas como empurrar caixas e evitar obstáculos (NITZAN, 1985). O robô Shakey, ilustrado na figura 1.2, tinha uma unidade de processamento embarcada que coletava os sinais sensoriais e os enviava para um computador remoto que executava o processamento, transmitindo ao robô o comando que geraria a ação desejada.
Figura 1.2. Robô Shakey
Em 1977 foram desenvolvidos alguns trabalhos com o veículo StanfordCart do Stanford Artificial Intelligence Laboratory (BOTELHO, 1996). O StanfordCart trabalhava em uma área plana, com obstáculos colocados separadamente e utilizava um sistema de navegação baseado no "parar e seguir", parando e fazendo leitura de seus sensores a cada metro percorrido, realizando o planejamento da rota a seguir (BRUMIT, 1992).
Durante os anos 80 vários trabalhos foram desenvolvidos em todo o mundo, usando robôs baseados em reconhecimento de imagens através da visão. Outro importante estudo sobre robôs móveis foi o desenvolvimento do robô Khepera, da empresa K-Team, no Microcomputing Laboratory do Swiss Federal Institute of Technology, com o apoio de outras entidades de pesquisa da Europa (MONDADA, 1993). O robô Khepera tem a capacidade de desviar-se de obstáculos e seguir ou evitar fontes luminosas, além de permitir a utilização de algumas extensões, como sistemas de visão, rádio controle e um pequeno manipulador. Dado o seu tamanho extremamente reduzido e seu custo relativamente baixo, comparado a outros robôs no mercado, o robô Khepera tornou-se um sucesso dentro das universidades em várias partes do mundo (BOTELHO, 1996).
Atualmente, principalmente nas grandes indústrias, tem-se destacado a utilização dos AGV’s (Automated Guided Vehicle), podendo executar desde tarefas simples de transporte, até soluções de transporte mais complexas.
Uma outra aplicação muito importante para os robôs móveis está no campo da exploração espacial. Um exemplo deste tipo de robô é o robô Sojourner, visto na figura 1.3, que realizou uma das maiores façanhas da pesquisa do espaço pelo homem: a exploração à distância do planeta Marte.
Figura 1.3. Robô espacial Soujouner
Atualmente o grande destaque entre os robôs móveis é o Honda Humanoid Robot, mostrado na figura 1.4 (MAIOR, 1998). Este robô se assemelha aos seres humanos, possuindo cabeça, tronco e membros, e possui um sofisticado sistema de equilíbrio, fazendo com que o robô possa subir escadas, se manter em pé e até mesmo chutar uma bola.
Figura 1.4. Robô humanóide Honda
1.3 Robôs móveis e suas aplicações
Trabalhar com robôs móveis é uma tarefa bastante complexa, em que é necessário um alto grau de conhecimento sobre todos os aspectos que envolvem a aplicação. As tarefas realizadas por um robô móvel podem variar de aplicações menos complexas, como o transporte de carga dentro de uma planta industrial, a até sofisticados sistemas de exploração espacial. A interação do robô com o ambiente (os diversos sensores necessários, grau de segurança, etc) e o tipo do ambiente (planos, buracos, obstáculos fixos e móveis entre outros) determinam o grau de
complexidade da aplicação.
Atualmente no mercado mundial de robôs móveis, existem basicamente três tipos de robôs móveis, que podem ser divididos em industriais, de serviço e de campo.
1.3.1 Robôs industriais
Os robôs industriais são geralmente plataformas móveis que executam tarefas pesadas, como, por exemplo, carregar grande quantidade de materiais e pintar grandes aviões, e geralmente, não têm uma autonomia muito grande (MONDANA, 1996). Um dos principais métodos de navegação utilizado por esse tipo de robô é através do uso de linhas pintadas no chão, que são usadas para definir o caminho que o robô deve seguir. Um exemplo deste tipo de robô industrial é o AGV, ilustrado na figura 1.5, e pode ser guiado de várias formas, sendo que as mais comuns são as trilhas pintadas no chão da fábrica e as trilhas magnéticas. Além disso, existem também os AGV’s guiados por laser, que são indicados para situações onde a estrutura da fábrica inviabiliza o uso de sensores ópticos e magnéticos e por fim, os AGV’s guiados por GPS, quando a aplicação exige transporte em ambiente externo.
Figura 1.5. Exemplo de uma célula de manufatura usando um AGV
1.3.2 Robôs de serviço
A robótica de serviço é reconhecida como uma importante área de aplicação para um futuro próximo. Sistemas de robótica móvel autônoma que executam tarefas de serviço podem ser utilizados por todos os tipos de aplicação como transporte, manipulação, exploração, vigilância, entre outros, em ambientes estruturados e com um mínimo de conhecimento prévio destes (FIRBY, 1993). Os robôs de serviço são utilizados principalmente para carregar materiais leves, para limpeza e para vigilância, como por exemplo, na limpeza nos metrôs da França.
1.3.3 Robôs de campo
Os robôs de campo são desenvolvidos para realizar tarefas em ambientes não estruturados e geralmente perigosos. Estes robôs têm evoluído muito nos últimos anos. Suas aplicações são a exploração espacial, mineração, limpeza de acidentes nucleares, desativação de minas terrestres (MÄCHLER, 1995) e submarinas,
exploração submarina a grandes profundidades, navegação em auto-estradas, exploração de vulcões, e muitas outras (MONDANA, 1996). O sistema de navegação destes robôs, principalmente os usados em exploração espacial, unem a tele-operação com comportamentos reativos.
Além das três categorias principais, pode-se dizer que também existem robôs usados para pesquisa, e são usados principalmente pela área acadêmica para o desenvolvimento de novas tecnologias. Muitas empresas que produzem robôs comerciais vendem versões para pesquisa de seus modelos. Um exemplo deste tipo de robô é o Khepera da empresa K-Team, que é amplamente utilizado na comunidade acadêmica.
1.4 Característica dos robôs móveis
Basicamente um robô móvel é composto por um sistema de processamento de dados, sensores e atuadores, onde os dados coletados pelos sensores são processados e enviados ao sistema de processamento que analisa os dados e controla os atuadores (NITZAN, 1985).
A principal característica de um robô móvel, como o próprio nome já diz, é a sua capacidade de locomoção. É esta capacidade de locomoção que possibilita aos robôs móveis um universo muito grande de aplicações.
Os robôs móveis possuem três formas básicas de locomoção: rodas, corpos articulados e pernas, podendo utilizar uma ou a associação dessas configurações, geralmente através de motores e atuadores pneumáticos (GROOVER, 1988). A forma de locomoção do robô deve levar em conta vários fatores como a finalidade, o tipo de terreno em que opera, fonte de alimentação e autonomia de energia.
Uma das principais características dos robôs móveis atuais é o uso de sensores externos que os tornam autônomos e capazes de operar em ambientes com obstáculos. Estes sensores permitem ao robô extrair informações do ambiente, levando-o a reagir às mudanças do mesmo de forma inteligente.
Os sensores podem ser classificados em sensores com contato e sensores sem contato. Os sensores com contato ou táteis são dispositivos que indicam o contato entre eles e algum outro objeto, e são normalmente usados em robôs industriais ou manipuladores. Já os sensores sem contato, como os sensores de
visão, ultra-som e infravermelho são os principais tipos de sensores usados na robótica móvel. Os sensores de visão são amplamente utilizados na robótica principalmente para fazer o mapeamento de ambientes. Já os sensores de ultra-som
são usados na robótica para localização de superfície de objetos, determinação da posição do robô em um dado ambiente, esquemas de navegação e para detecção de obstáculos. Alguns robôs como o robô Khepera, por exemplo, também usam sensores infravermelhos para detectar objetos e medir a intensidade de luz ambiente (K-TEAM, 2002).
A evolução tecnológica dos sensores e atuadores, em conjunto com o processamento dos dados, permitiu o desenvolvimento de uma variedade de robôs apta a lidar com vários tipos de aplicações, melhorando consideravelmente o desempenho e a confiabilidade destas máquinas. A figura 1.6 mostra um esquema
básico de um robô móvel, composto de sensores, atuadores, CPU e fonte de energia.
Figura 1.6. Componentes de um robô
1.5 O Robô Khepera
O Khepera é um robô móvel que possui funcionalidades semelhantes às de robôs móveis de maior porte. Ele pode ser controlado através de um cabo RS-232 conectado a porta serial do PC ou pode rodar em modo autônomo. Geralmente o Khepera é usado conectado ao PC nas fases de implementação e testes de programas. Após esta fase, a aplicação pode ser transferida diretamente para a memória do robô, possibilitando que o robô trabalhe em modo autônomo, ou seja, sem estar conectado ao PC (K-TEAM, 1999a) (K-TEAM, 1999b).
O Khepera é um robô sofisticado que incorpora em sua unidade de processamento um processador Motorola 68331 de 32 bits funcionando a uma freqüência de 16 MHz e possui uma memória RAM de 256 Kbytes e uma memória EPROM que pode variar de 128 a 256 Kbytes de acordo com o modelo do robô.
O movimento do robô é obtido através de dois servo-motores DC acoplados a caixas de redução 25:1 com um sofisticado sistema de sensoriamento obtido por sensores magnéticos e sinais de quadratura com uma resolução de 12 pulsos/mm.
Além disso, o Khepera possui um sistema de baterias recarregáveis, que permitem uma autonomia de 30 minutos em movimento contínuo no modo
autônomo.
O sensoriamento do ambiente é feito por oito sensores infravermelhos (IR) com emissor e receptor no mesmo componente, que permitem a obtenção de valores de proximidade do robô em relação a objetos e níveis de luz ambiente.
A comunicação com o robô é feita através de uma interface serial RS-232 com velocidade de comunicação de até 38 Kbps.
Outra característica importante é a dimensão do robô que mede apenas 55 mm de diâmetro e 30 mm de altura. Também podem ser acrescentados ao módulo básico do robô, módulos para visão, rádio controle e um manipulador. A figura 1.7 mostra um robô Khepera com sistema de visão e garra, operando em modo autônomo (K-TEAM, 1999b).
Figura 1.7. Robô Khepera
Com todas essas funcionalidades o robô Khepera possibilita o teste em ambientes reais de algoritmos desenvolvidos em simulações para o planejamento de trajetórias, desvio de obstáculos, processamento de dados sensoriais, inteligência artificial, entre muitos outros (LUND, 1996) (FLOREANO, 1996).
1.5.1 Motores e controle do motor
Como já mencionado cada roda é movida por um motor DC acoplado a uma
caixa de redução 25:1, onde um encoder incremental é colocado no eixo do motor, enviando 24 pulsos por rotação da roda. Isto permite uma resolução de 600 pulsos por rotação da roda, o que corresponde a 12 pulsos/mm da trajetória percorrida pelo robô (K-TEAM, 1999b).
O processador do Khepera controla diretamente a energia enviada aos motores, além de ler os pulsos enviados pelos encoders (contadores digitais de posição). Uma rotina de interrupção detecta cada pulso do encoder incremental e atualiza um contador de posição da roda.
A energia aplicada ao motor pode ser ajustada pelo processador fazendo o chaveamento ON/OFF a uma determinada freqüência por um dado tempo. A freqüência de chaveamento básica é constante e suficientemente alta para não deixar o motor reagir a um simples chaveamento. Desta forma, o motor reage a um tempo médio de energia, que pode ser modificado mudando o período em que motor fica chaveado em ON (K-TEAM, 1999b). Este método em que somente a proporção entre os períodos ON e OFF é modificada é chamado de PWM (pulse width modulation), e é ilustrado na figura 1.8.
A figura 1.8, bem como as figuras ilustradas adiante neste capítulo foram mantidas conforme as referências bibliográficas para que não houvesse possíveis distorções na tradução dos termos utilizados.
Figura 1.8. O controle PWM (K-TEAM, 1999b)
O valor PWM é definido pelo tempo que o motor fica chaveado em ON, sendo que este valor pode ser ajustado diretamente ou pode ser gerenciado por um controlador local para o motor. O controlador do motor pode executar o controle da velocidade ou da posição do motor, ajustando o valor correto do PWM de acordo com a velocidade real ou posição real dos encoders.
O funcionamento dos motores também pode ser ajustado através de dois controladores PID executados em uma rotina de interrupção do processador. Cada termo destes controladores (Proporcional, Integral e Derivativo) é associado a uma
constante Kp, Ki e Kd respectivamente.
Nesse caso, o controle do motor pode ser efetuado de dois modos: o modo de velocidade e o modo de posição. A figura 1.9 ilustra os controladores do motor e os níveis de acesso permitido ao usuário.
Figura 1.9. Estrutura dos níveis de controles do motor e níveis de configuração do usuário (K-TEAM, 1999b)
O modo de controle ativo é determinado pelo tipo de comando recebido. Se o controlador recebe um comando de controle de velocidade, este é chaveado para o modo de velocidade. Se o controlador recebe um comando de controle de posição, o modo de controle é a automaticamente chaveado para o modo de posição. Parâmetros de controle diferentes (Kp, Ki e Kd) podem ser ajustados para cada um dos dois modos de controle.
Usando o modo de velocidade, o controlador terá como entrada um valor para a velocidade das rodas, e o controle do motor modificará a velocidade das rodas. A modificação da velocidade das rodas é feita da maneira mais rápida possível de forma abrupta, sendo que nenhuma limitação para a aceleração é considerada neste modo.
Usando o modo de posição, o controlador terá como entrada a posição alvo da roda, com máxima aceleração e velocidade. Usando estes valores, o controlador do motor acelera a roda até que a velocidade máxima seja atingida e desacelera até alcançar a posição alvo. Este movimento segue um perfil trapezoidal que pode ser visto na figura 1.10.
Figura 1.10. Curvas de aceleração e desaceleração para o controle de posição (K-TEAM, 1999b)
Os valores de entrada e o modo de controle podem ser mudados a qualquer momento. O controlador atualizará e executará o novo perfil no modo de posição, ou simplesmente seguirá com uma determinada velocidade até que novos valores sejam ajustados para o modo de velocidade.
A velocidade dos motores usa como unidade pulso/10 ms, que corresponde a 8mm/s, atingindo uma velocidade máxima é de 127/10ms, que corresponde a 1m/s. Já, no controle de posicionamento do robô, a unidade retornada é equivalente a um pulso do encoder, que corresponde a 0,08 mm.
1.5.2 Sensores infravermelhos de proximidade e luz ambiente
Os sensores infravermelhos (IR) estão dispostos em ângulos apropriados como mostrado na figura 1.11 (vista superior), cobrindo o campo de atuação do robô.
Figura 1.11. Posição dos sensores infravermelhos (K-TEAM, 1999b)
Os sensores são montados de forma que emissor e receptor fiquem no mesmo componente, e podem efetuar dois tipos de medidas:
• A luminosidade do ambiente. Esta medição é feita usando somente a parte receptora do dispositivo, sem haver a emissão de luz. Uma nova medição é feita a cada 20 ms. Durante estes 20 ms, os sensores são lidos seqüencialmente a cada 2,5 ms, totalizando desta forma a leitura de cada um
dos oito sensores.
• A luz refletida pelos obstáculos. Esta medição é realizada através da emissão de luz pela parte emissora do dispositivo. O valor retornado é a diferença entre a medição feita com emissão de luz e a medida feita sem emissão de luz (luz ambiente). De modo similar à leitura de luz ambiente, uma nova medida é feita a cada 20 ms e os sensores são lidos seqüencialmente a cada 2,5 ms.
A sensibilidade na resposta dos sensores de proximidade (onde a luz é refletida pelo obstáculo) está diretamente relacionada ao tipo de material reflexivo. A escala de sensibilidade de proximidade possui uma resolução de 10 bits com valores entre 0 e 1023, sendo que quanto maior o valor mais próximo do obstáculo o robô se
encontra. Estes valores dependem também da refletividade do obstáculo. Quanto melhor for a refletividade, maior será a sensibilidade do sensor. O plástico branco, por exemplo, tem uma ótima refletividade, enquanto uma madeira escura tem uma baixa refletividade. A figura 1.12 mostra a resposta dos sensores para alguns tipos de materiais como: plástico preto, isopor verde, esponja rosa, plástico branco, plástico cinza, madeira e cobre (K-TEAM, 2002a).
Figura 1.12. Valores medidos da luz refletida por vários tipos de objetos versus a distância do objeto (K-TEAM, 1999b)
Os sensores de luminosidade funcionam de forma similar aos sensores de proximidade com uma escala de sensibilidade com resolução de 10 bits, sendo 450 o valor padrão aproximado para um ambiente escuro. Deste modo, quanto menor o valor retornado pelo sensor de luz ambiente, mais próximo da fonte de luz o robô se encontra. É importante salientar que estas medidas dependem fortemente de fatores como a distância da fonte de luz, sua cor, intensidade, posição vertical, entre outros. A figura 1.13 mostra os valores típicos de luz ambiente medidos pelos sensores a uma determinada distância de uma fonte de luz de 1 Watt TEAM, 1999b)
(K-TEAM, 1999b).
.
Figura 1.13. Valores típicos para medida da luz ambiente versus distância de uma fonte de luz de 1 Watt (K-TEAM, 1999b)
É necessário conhecer todos os aspectos do ambiente em que o robô está inserido, pois, além das imprecisões do ambiente, pode haver diferenças físicas entre as características de cada sensor. A figura 1.14 mostra uma medição feita por seis sensores de um mesmo robô colocado em condições idênticas. Pequenas diferenças de condições, como orientação vertical do sensor, condições de luz ambiente e a cor do piso, podem provocar diferenças nas medidas.
Figura 1.14. Valores típicos de luz refletida por um obstáculo versus distância do obstáculo para sensores do mesmo tipo em condições idênticas (K-TEAM, 1999b)
1.5.3 O protocolo de comunicação serial
O controle do robô pode ser feito através de um computador usando uma porta de comunicação serial RS-232. A configuração dos parâmetros de comunicação da porta serial (baudrate, start bit, stop bit e bit de paridade) no computador deve estar de acordo com a configuração dos parâmetros de comunicação serial existente no hardware do robô (K-TEAM, 1999b). Esta configuração é feita através de jumpers localizados na parte superior do robô, como mostra a figura 1.15.
Figura 1.15. Posição e configuração dos jumpers (K-TEAM, 1999b)
Nos modos 01, 02 e 03 a comunicação é feita com velocidade de 9600, 19200 e 38400 bps respectivamente.
A comunicação entre o computador e o robô Khepera é feita enviando e recebendo mensagens no padrão ASCII. A comunicação se efetua através de comandos enviados do computador para o Khepera, e quando necessário, uma
resposta é enviada do Khepera para o computador.
A comunicação é sempre iniciada pelo computador, e é baseada em dois tipos de interações com o robô. O primeiro tipo é a interação com o robô através de ferramentas de controle, que possibilitam manipular aspectos mais específicos do robô como por exemplo, iniciar uma aplicação armazenada na memória ROM do robô ou simplesmente reiniciar o robô.
O segundo tipo de interação é chamado de protocolo de controle, e permite controlar todas as funcionalidades do robô. Cada interação entre o robô e o computador é composta por:
• Um comando, iniciando com uma ou duas letras maiúsculas no formato ASCII, seguido, se necessário, por um conjunto de parâmetros separados por virgula (de acordo com o comando executado) e finalizado por um retorno de carro ou avanço de linha, enviado do computador para o robô.
• Uma resposta, iniciando com um ou dois caracteres minúsculos, iguais aos do comando de envio. Dependendo do comando, uma seqüência de números, separados por virgula, é enviada após o caractere inicial e finalizada por um retorno de carro ou avanço de linha, enviado do robô para o computador.
Este protocolo de controle pode implementar até 18 diferentes comandos para o controle do robô (K-TEAM, 1999b).
1.6 Linguagens de programação para robôs móveis
As linguagens de programação para robôs móveis geralmente são linguagens
proprietárias, ou seja, feitas exclusivamente para a programação de um determinado robô. Um dos problemas desse tipo de linguagem é que a programação fica limitada a um conjunto predefinido de funções destinadas ao controle do robô. Muitas vezes, essa limitação imposta pela linguagem de programação não permite que as potencialidades do robô sejam exploradas na sua totalidade.
Alguns modelos de robôs permitem que, além da sua própria linguagem de programação, suas funções sejam acessadas por meio de alguma outra linguagem. O acesso ao robô por meio de uma linguagem de alto nível proporciona um acréscimo importante no desenvolvimento de aplicações.
Além das linguagens de programação para robôs móveis reais, existem ainda os ambientes de simulação. Através do modelamento matemático do robô é possível desenvolver um ambiente de simulação capaz de se aproximar de forma satisfatória
dos modelos reais. Pelo fato de não ser necessária a presença do robô real, a grande vantagem dos ambientes simulados é o baixo custo de desenvolvimento.
1.6.1 Ambientes de programação para o robô Khepera
O Khepera pode ser programado de várias maneiras. A maneira mais comum é enviar comandos ao robô usando um protocolo de comunicação específico, através de qualquer software de comunicação serial. Fica claro que estes programas não podem implementar nenhum tipo de algoritmo, pois eles não podem manipular
os dados enviados e recebidos do robô. Para que se possa passar algum tipo de tarefa para o robô há a necessidade de programas mais sofisticados. Dentre os ambientes de programação mais conhecidos para a programação do Khepera existe o KTProject, que é uma interface gráfica para ambiente Windows desenvolvida pelo próprio fabricante do robô para que programas desenvolvidos em C sejam compilados e gravados diretamente na memória do Khepera, permitindo que o mesmo execute tarefas em modo autônomo. Outra importante ferramenta de programação é o GNU C Cross Compiler, usada para o desenvolvimento de aplicações nativas nas plataformas Windows, Linux e Sun TEAM, 1999b) (K-TEAM, 2002b).
O Khepera também pode ser programado através de ambientes de simulação. Um exemplo de ambiente de simulação é o Webots (CYBERBOTICS, 2003), um simulador para robôs móveis desenvolvido pela Cyberbotics. Este software, ilustrado na figura 1.16, tem se mostrado uma importante ferramenta para pesquisadores e professores que atuam na área de robótica, agentes autônomos, visão computacional e inteligência artificial. O simulador inclui modelos de dois robôs reais, o robô Alice e o robô Khepera produzidos pela empresa suíça K-Team, e permite incluir vários módulos, como módulo de visão e garras. O usuário pode programar virtualmente o robô usando C ou C++, que é compatível com o robô real. Um ambiente de edição 3D permite que o usuário crie os seus próprios cenários de
trabalho.
Figura 1.16. Webots - Ambiente de simulação para o robô Khepera
Também são utilizados outros ambientes para desenvolvimento de pesquisa com o robô Khepera, como o LabVIEW e o MatLAB. Esses dois ambientes possibilitam, através da instalação de plugins, efetuar a comunicação com o robô, através da porta serial do microcomputador (K-TEAM, 1999b).
O LabVIEW (Laboratory Visual Environment Workbench) é um ambiente de programação visual orientada a fluxo de dados muito utilizado na área de engenharia, mais especificamente em aplicações de aquisição de dados, controle, simulação, processamento de sinais e análise (NATIONAL, 2000). Ele é composto de uma grande variedade de instrumentos virtuais, mais conhecidos por VI (virtual instruments) que podem ser interligados para formar alguma aplicação. No caso do robô Khepera, os instrumentos virtuais básicos, são formados por motores e sensores e podem ser acessados através de painéis frontais. Com os painéis disponíveis para o controle dos motores é possível ler a posição e velocidade instantânea de cada roda, controlar a velocidade e posição de cada roda e configurar os parâmetros da curva de velocidade, por exemplo.
Os painéis frontais são descritos por diagramas que estabelecem a lógica de programação desde o processamento das informações de entrada até a geração
dos dados de saída. Estes diagramas são compostos por símbolos que representam os controles e indicadores do painel frontal e por operações e estruturas predefinidas na linguagem. Além das estruturas predefinidas, também é possível a criação de sub-rotinas.
O painel de controle para configurar a velocidade de cada motor, mostrado na figura 1.17, pode alterar a velocidade dos motores através de botões deslizantes, ou manualmente, digitando o valor da velocidade no campo apropriado. A figura 1.18 mostra o diagrama correspondente ao painel frontal para o controle dos motores.
Figura 1.17. Painel frontal do controle de velocidade dos motores
Figura 1.18. Diagrama correspondente ao painel frontal para controlar a velocidade dos motores
Da mesma forma, os valores retornados pelos sensores infravermelhos do robô podem ser visualizados através de um painel de controle. O painel de controle para leitura dos sensores, mostrado na figura 1.19, é composto por 8 medidores que indicam através de uma barra o valor de cada sensor.
Figura 1.19. Painel de sensores para mostrar a leitura dos sensores infravermelhos
Através destes painéis de controle é possível desenvolver um grande número de aplicações para o Khepera. Um exemplo de uma aplicação para o robô Khepera usando o LabVIEW pode ser visto na figura 1.20, que mostra o painel de um veículo
de Braitenberg. A estrutura de controle foi baseada no trabalho de V. Braitenberg (BRAITENBERG, 1984). A figura 1.21 mostra o diagrama VI que corresponde ao painel do veiculo de Braitenberg.
Figura 1.20. Painel do veículo de Braitenberg
Figura 1.21. Diagrama do veículo de Braitenberg
CAPÍTULO 2
PROGRAMAÇÃO VISUAL ORIENTADA A OBJETOS
Introdução
Este capítulo tem por objetivo fazer um breve apanhado sobre os principais tipos de linguagens de programação, e dar a sustentação teórica necessária para melhor compreender os objetivos embutidos na escolha da programação visual em conjunto com a programação orientada a objetos como plataforma para este trabalho.
2.1 A evolução das linguagens de programação
As linguagens de programação basicamente evoluíram a partir do surgimento do primeiro computador. Inicialmente, as linguagens eram baseadas em um conjunto de códigos binários que representavam alguma instrução do processador. Essas linguagens são conhecidas como linguagens de máquina e, basicamente existe uma linguagem para cada família de processador. Apesar de simples, comparadas às
linguagens de alto nível disponíveis atualmente, as linguagens de máquina são bastante eficientes no que diz respeito à velocidade de execução das instruções. O fato de se programar usando código binário ou hexadecimal, faz com que esse tipo de linguagem não seja a mais adequada para a descrição de um programa, uma vez que os programas desenvolvidos podem ser sofisticados e essa linguagem primitiva não é nem um pouco amigável ao programador. Uma evolução nas linguagens de baixo nível veio com o uso da linguagem Assembly, que faz uso de códigos mnemônicos, facilitando assim o desenvolvimento de programas (SETHI, 1996).
O próximo passo no sentido da evolução das linguagens de programação foi as linguagens de alto nível não-estruturadas, que são mais sofisticadas que as linguagens de baixo nível e seus comandos não estão diretamente vinculados ao processador e sistema utilizados, permitindo seu uso em diferentes plataformas e tornando a linguagem mais flexível. Do mesmo modo, a semântica de seus termos
torna-se mais genérica, não estando associada ao conjunto de instruções que irão efetivamente implementá-la durante a execução do programa, onde operações mais sofisticadas podem ser emuladas por seqüências de instruções mais simples do que em linguagem de máquina. As linguagens COBOL (1959) e BASIC (1963) são exemplos de linguagens não-estruturadas (GUDWIN, 1997). Apesar de melhorar consideravelmente o desenvolvimento de software, as linguagens de programação não-estruturadas geralmente não oferecem uma estrutura de controle adequada, admitindo, por exemplo, o uso de desvios incondicionais (GOTO) que dificultam a compreensão do código.
Neste sentido, surgiram as linguagens de programação estruturadas, também conhecidas como procedimentais. Diferentemente das linguagens não-estruturadas, as linguagens estruturadas possibilitam o uso de estruturas de controle, que tornam possíveis operações como o teste de condições (IF – THEN – ELSE), o controle de repetição de blocos de código (FOR – WHILE – DO) e a seleção de alternativas (SWITCH - CASE). As linguagens procedimentais permitem que o código do programa seja separado em módulos chamados de funções ou procedimentos. As linguagens procedimentais são caracterizadas pela existência de algoritmos, que determinam uma seqüência de chamadas de procedimentos, que constituem o programa. As linguagens procedimentais mais comuns são o C, o PASCAL e o FORTRAN (GUDWIN, 1997).
Existem também as linguagens de programação funcionais, que evidenciam um estilo de programação diferente das linguagens procedimentais. Esse tipo de linguagem tem um conjunto de regras sintáticas e semânticas que podem ser estendidas de muitas maneiras permitindo a criação de novas formas de expressar problemas de uma maneira muito inteligível e de fácil manutenção. A programação funcional enfatiza a avaliação de expressões, ao invés da execução de comandos. As expressões nessas linguagens são formadas utilizando-se funções para combinar valores básicos. As linguagens funcionais mais conhecidas são o LISP e o PROLOG.
Seguindo a constante evolução das linguagens de programação, surgiu então, o paradigma da programação orientada a objetos. As linguagens orientadas a objetos foram originadas a partir da necessidade de se organizar o processo de
programação em uma linguagem. Na verdade a programação orientada a objetos é uma técnica de programação. Uma linguagem é dita uma linguagem orientada a objetos, se ela suporta o estilo de programação orientada a objetos. Um dos objetivos da engenharia de software é separar o projeto de desenvolvimento de um software em diversos módulos, de tal forma que o seu desenvolvimento e manutenção possam ser implementados com baixo custo. No passado, os paradigmas da engenharia de software derivavam os módulos baseados na funcionalidade de um sistema que correspondiam basicamente a módulos procedimentais. O paradigma de orientação a objeto mudou essa concepção,
idealizando a idéia de objetos, como módulos que se comunicam por meio de mensagens, encapsulando ao mesmo tempo dados e funções. A primeira linguagem orientada a objetos que se tem notícia é o Simula, desenvolvido em 1967. Posteriormente veio o Smalltalk em 1970 (GUDWIN, 1997). Atualmente, existe uma enorme diversidade de linguagens orientadas a objetos, abrangendo desde linguagens de propósito geral, até linguagens para multimídia e programação em lógica. Linguagens como o C++ incorporam características das linguagens de programação orientadas a objetos. Já a linguagem Java é totalmente orientada a objetos.
A evolução na capacidade de processamento do hardware também permitiu que surgissem novas linguagens de programação, como as linguagens visuais, que aproveitam essa capacidade de processamento para o desenvolvimento de ambientes gráficos (WHITLEY, 1996). Pode-se dizer que uma informação visual é mais fácil de ser entendida do que uma informação textual, portanto, a especificação de um programa por meio de diagramas, ícones e outros recursos visuais tende a tornar a programação mais fácil, permitindo que um grupo maior de usuários tenha acesso ao desenvolvimento de programas. Uma representação visual de um programa normalmente limita a flexibilidade dos programas que podem ser desenvolvidos, mas em contrapartida, as linguagens de programação visual permitem que programas sejam elaborados com mais facilidade e de forma mais
rápida do que a programação somente textual.
Seguindo as características da programação visual, existem também as linguagens de programação que não são somente visuais, mas têm parte de sua
especificação determinada de forma visual. Normalmente este tipo de linguagem de programação visual não é simplesmente uma linguagem, mas uma ferramenta de programação que adota uma linguagem de programação textual, com recursos de programação visual, a fim de melhorar a produtividade no desenvolvimento de aplicações. Em outros casos, as ferramentas de programação visual efetivamente participam da elaboração do programa, como por exemplo na determinação de hierarquia de classes e métodos, em linguagens orientadas a objeto. As linguagens incluídas nesta categoria são normalmente desenvolvimentos de linguagens de programação convencional ou textual, acrescidas das ferramentas visuais. Algumas
linguagens que usam esse tipo de recurso são o Delphi, o Visual Basic e o Visual C++ (GUDWIN, 1997).
Por fim, é possível citar as linguagens de programação visual puras, onde o programa é descrito exclusivamente por meio de gráficos e diagramas. Neste tipo de programação, o programa é elaborado através de diagramas com nós e arcos, sendo que os nós representam módulos de software, a partir de uma biblioteca prévia de módulos, e os arcos determinam a conexão entre os diferentes módulos. Devido à forte dependência dos módulos de software, o uso deste tipo de linguagem torna-se bastante específico, limitando desta forma o universo de aplicações. Um exemplo deste tipo de linguagem é o Simulink, que trabalha em conjunto com o Matlab e é usado para simulação de sistemas dinâmicos (GUDWIN, 1997).
2.2 O paradigma da programação orientada a objetos
Um dos principais objetivos da programação orientada a objetos é reduzir a complexidade no desenvolvimento de software e aumentar sua produtividade. Neste sentido, o aumento da complexidade dos ambientes computacionais que se caracterizam por sistemas heterogêneos, podem se beneficiar com o uso da programação orientada a objetos (VOSS, 1991).
A programação orientada a objetos não tem a intenção de substituir a
programação estruturada tradicional, podendo então, ser considerada como uma evolução de práticas que são recomendadas na programação estruturada (LEE, 2002). O modelo de objetos permite a criação de bibliotecas que tornam efetivos o
compartilhamento e a reutilização de código, reduzindo o tempo de desenvolvimento e, principalmente, simplificando o processo de manutenção das aplicações.
A grande dificuldade para compreender a programação orientada a objetos é a diferença de abordagem do problema, pois, enquanto a programação estruturada tem como principal foco as ações através de procedimentos e funções, a programação orientada a objetos se preocupa com os objetos, suas propriedades e seus relacionamentos.
2.3 Elementos da programação orientada a objetos
A utilização da programação orientada a objetos permite um aumento de produtividade pelo reuso de elementos de software. Ela também contempla as características psicológicas do programador, pois nos modelos de aprendizagem, a organização da informação de entrada conduz à aprendizagem mais rápida e à melhor memorização (SOUSA, 1999). A recuperação da informação armazenada se torna muito mais fácil se esta é organizada desde o início. Os itens na memória de longo prazo são tanto mais prontamente recuperados quanto mais se acham estruturados ou categorizados. O estratagema dos métodos propostos para o desenvolvimento de sistemas de memória consiste em aprender a organizar as informações que devemos aprender, de modo que elas possam ser novamente encontradas em nossa memória, quando necessário. Este ponto vai ao encontro da estruturação da programação orientada a objetos. Os objetos (entidades) são organizados ou categorizados em classes, formando uma estrutura hierarquizada, possibilitando uma boa organização da informação, que é captada pelas pessoas envolvidas no desenvolvimento dos programas.
Por fim, pode-se dizer que o desenvolvimento de um programa orientado a objetos, é baseado em quatro princípios básicos: abstração, encapsulamento, herança e polimorfismo, que serão discutidos a seguir.
2.3.1 Abstração
A abstração é o processo de extrair as características essenciais de um objeto real e é necessária para se ter um modelo o mais exato possível da realidade sobre o qual se possa operar. O conjunto de características resultante da abstração forma um tipo de dados abstrato com informações sobre seu estado e comportamento. A abstração no entanto pode não produzir os mesmos resultados para diferentes observadores, pois, dependendo do contexto onde é utilizada, a abstração de um objeto descrito por uma pessoa pode ser diferente na visão de
outra. No desenvolvimento de software a abstração é o mecanismo básico utilizado para realização da análise do domínio da aplicação, e cada passo do processo de engenharia de software é um aprimoramento do nível de abstração da solução (PRESSMAN, 1995).
2.3.2 Encapsulamento
Através do encapsulamento, os atributos de um objeto só podem ser alterados por métodos definidos na própria classe, garantindo desta forma a integridade dos atributos do objeto. A única maneira de um objeto alterar os atributos de um outro objeto é através da ativação de um de seus métodos por uma mensagem. Este conceito, onde atributos e métodos são visíveis apenas através de mensagens, é conhecido como encapsulamento. O encapsulamento funciona como uma proteção para os atributos e métodos, além de tornar explícito qualquer tipo de comunicação com o objeto (WINBLAND, 1993).
Um exemplo prático de encapsulamento no mundo real pode ser descrito por um vídeo cassete. Em um vídeo cassete existe um número determinado de funções que podem ser executadas, como por exemplo, avançar, voltar, gravar, tocar, parar e ejetar a fita. Dentro do vídeo cassete, porém, há várias outras funções sendo realizadas como acionar o motor, desligar o motor, acionar o cabeçote de gravação,
liberar o cabeçote, e outras operações mais complexas. Essas funções são escondidas dentro do mecanismo do vídeo cassete e não temos acesso a elas diretamente. Quando a tecla play é pressionada, o motor é ligado e o cabeçote de
reprodução é acionado, sem que para isso, seja necessário saber como é feito internamente.
A principal vantagem do encapsulamento é poder esconder a complexidade do código e proteger os dados, permitindo o acesso a eles apenas através de métodos evitando que seus dados sejam corrompidos por aplicações externas.
No exemplo do vídeo cassete, quando o método gravar é acionado, o aparelho grava as informações presentes na fita de vídeo em um formato padrão, que poderá ser lido por outros aparelhos similares. Se não existisse o método gravar e fosse possível o acesso direto à fita, cada pessoa poderia estabelecer uma
maneira diferente de gravar informações, fazendo com que o processo de se gravar uma fita de vídeo se tornasse uma tarefa complicada, pois o usuário teria que conhecer toda a complexidade do aparelho. Isso acarretaria numa perda de compatibilidade pois não haveria uma forma de proteger os dados para que fossem sempre gravados em um formato padrão. Neste caso, o encapsulamento funciona tanto para proteger os dados, como para simplificar o uso de um objeto.
Outro exemplo pode ser dado pelos aplicativos desenvolvidos para a plataforma Windows. Em aplicações deste tipo, quando em alguma parte do programa onde é necessário o uso de um botão OK e um botão Cancela, por exemplo, não é preciso entender como ele foi escrito, nem saber quais são seus dados internos. Basta saber como construí-lo, mudar o texto que contém a informação do botão e depois incluí-lo no programa, sem correr o risco de corromper a estrutura interna do botão, definida em uma biblioteca padrão.
2.3.3 Herança
O conceito de herançapermite definir uma nova classe, com base em uma já existente. Uma classe-filha pode ser criada herdando os membros de dados e os métodos de uma classe-pai. Assim, novas classes podem ser criadas pela especialização da classe-pai, formando uma hierarquia de classes (WINBLAND,
1993).
De uma maneira bastante simples, pode-se dizer que herança é o aproveitamento e extensão das características de uma classe existente. Na natureza
existem muitos exemplos de herança. No reino animal, os mamíferos herdam a característica de terem uma espinha dorsal por serem uma subclasse dos vertebrados, podendo ainda, acrescentar a essa característica, outras, como ter sangue quente e amamentar. Os roedores herdam todas as características dos vertebrados e mamíferos e acrescentam outras, e assim por diante. Em programação, a herança ocorre quando um objeto aproveita a implementação (estruturas de dados e métodos) de um outro tipo de objeto para desenvolver uma especialização dele. A herança permite a formação de uma hierarquia de classes, onde cada nível é uma especialização do nível anterior, que é mais genérico.
Em programação orientada a objetos, é comum desenvolver estruturas genéricas para depois ir acrescentando detalhes. Isto simplifica o código e permite uma organização maior de um projeto, fazendo com que seja possível a reutilização de código. Se for preciso implementar um botão azul e já temos uma classe que define as características de um botão cinza, podemos fazer com que nossa implementação seja uma subclasse do botão cinza, e depois estender suas características. Desta forma, nos concentramos apenas no necessário, que neste caso é a cor do botão, e evitamos ter que definir novamente todas as características para um novo botão.
2.3.4 Polimorfismo
O termo polimorfismo significa ter muitas formas. Em programação, esta definição pode ser traduzida pelo envio de uma mesma mensagem para um conjunto de objetos, onde cada objeto responde de forma diferente em função da mensagem recebida (WINBLAND, 1993). Polimorfismo também pode ser definido como sendo a propriedade de se utilizar um mesmo nome para fazer coisas diferentes. Por exemplo, mandar alguém correr pode produzir resultados diferentes dependendo da situação. Se a pessoa estiver parada e em pé, irá obedecer à ordem simplesmente correndo. Se a pessoa estiver no volante de um carro, o resultado será o aumento
da pressão do pé no acelerador.
Em programação, uma mesma mensagem poderá provocar um resultado diferente, dependendo dos argumentos que foram passados e do objeto que o
receberá. Por exemplo, o envio de uma instrução que desenhe para uma subclasse de polígono, poderá desenhar um triângulo, um retângulo ou um pentágono, dependendo da classe que receber a instrução. Isto é muito útil para escrever programas versáteis, que possam lidar com vários tipos diferentes de objetos.
2.4 O conceito de objeto
Objetos são a base da tecnologia orientada a objetos e consistem de modelos ou abstrações de objetos reais e preservam as características essenciais de um
objeto real, ou seja, o seu estado e o seu comportamento. Desta forma qualquer objeto real pode ser abstraído para filtrar seu estado e comportamento. A Tabela 1 mostra alguns exemplos.
Tabela 2.1. Exemplos de objetos reais
OBJETO ESTADO COMPORTAMENTO
Carro velocidade, marcha, cor, modelo, marca
troca marchas, acelera, dá partida, freia
Gato nome, raça, com fome, com preguiça mia, dorme, se estica, brinca, caça
Caneta cor, nível de tinta escreve, coloca mais tinta
Toca-fitas ligado, girando, tocando, gravando liga, grava, toca, avança, volta, para
Em programação orientada a objetos, o estado de um objeto é representado por membros de dados, e seu comportamento implementado com métodos, sendo que, a única forma de mudar o estado dos dados é através de métodos. Por exemplo, para mudar o estado do vídeo cassete para ligado, é necessário utilizar o método liga. A figura 2.1 representa um objeto de software.
Figura 2.1. Representação de um objeto de software
Tudo o que o objeto de software sabe (seu estado) e tudo o que ele pode fazer (o seu comportamento) é determinado pelos seus membros de dados e pelos seus métodos.
Para entender melhor o conceito de objeto, no exemplo a seguir, um avião Cessna 185 será representado através de um objeto de software, neste caso, um objeto chamado ppHCC, como mostra a figura 2.2. Neste objeto, as variáveis que indicam o estado atual do avião são dadas pela velocidade, direção e altitude, podendo ter seus valores alterados através dos métodos públicos partida(), acelera(), leme(direção), aileron(direção), elevador(posição) e altímetro(). A mudança no estado das variáveis do avião pode, por exemplo, fazer o avião ganhar altitude, velocidade ou mudar de direção.
Figura 2.2. O objeto ppHCC
Sabe-se que um objeto sozinho não tem muita utilidade, portanto, um avião sem piloto, não teria muita utilidade. Para que um objeto seja funcional, é necessário que ele interaja com outros objetos, para que desta maneira se possa construir modelos de comportamento mais complexo.
Um objeto solicita a outro que execute uma determinada atividade através de uma mensagem, podendo também transmitir informações de um objeto para outro (JONES, 2001). No exemplo do avião Cessna, é necessário que haja um outro objeto, neste caso um objeto piloto, que envie mensagens para o avião para que ele possa sair do chão. No exemplo ilustrado na figura 2.3, um avião voa a uma velocidade de 280 Km/h e 2,5 Km de altura, onde um objeto Dumont (um piloto) invoca o método elevador() sobre o objeto ppHCC com o parâmetro (+2). O método é então executado, fazendo o elevador se mover duas posições para cima, aumentando a altitude e reduzindo a velocidade (mudando o estado dos dados do objeto ppHCC).
Figura 2.3. Troca de mensagens entre objetos
2.4.1 Métodos internos e variáveis públicas
A única maneira de se mudar qualquer estado do avião é através dos seus métodos públicos, já que os campos de dados são privativos e o seu acesso direto não é permitido ao mundo externo. Se os campos de dados fossem públicos, seria possível alterá-los diretamente, podendo comprometer o funcionamento normal do objeto. A figura 2.4 ilustra uma nova versão do avião Cessna ppHCC, onde é possível alterar diretamente os valores dos membros de dados, sem usar os métodos. Pela notação utilizada, é possível notar que agora os membros de dados direção, altitude e velocidade podem ser acessados publicamente.
Figura 2.4. Membros de dados acessados publicamente
Isto pode ser comparado a mover o leme, aileron e elevador com a mão, em vez de usar o manche e o pedal, tornando o avião mais difícil de usar e comprometendo a sua segurança. A maioria das linguagens de programação permite o uso de campos de dados públicos. Geralmente, as desvantagens desse procedimento são maiores que as vantagens; portanto, é aconselhável que se use o encapsulamento dos dados pelos métodos sempre que possível.
Um objeto complexo pode ter centenas de métodos, mas geralmente, alguns poucos métodos interessam a quem vai usá-lo. Por exemplo, quem dirige um carro não precisa saber de coisas como injetar combustível e provocar faísca. E precisa somente ligar a ignição. Neste caso, ligar a ignição é um método público, que interessa ao motorista; já injetar combustível e provocar faísca são métodos internos (ou privados) ao funcionamento do automóvel, que podem ser chamados por outros métodos sem que o motorista precise se preocupar.
2.5 O conceito de classes
Uma classe é uma descrição de um conjunto de objetos quase idênticos, e consiste em métodos e dados que resumem as características comuns de um conjunto de objetos (WINBLAND, 1993). As características de estado e
comportamento do objeto ppHCC ilustrado nos exemplos anteriores, são características de qualquer avião Cessna 185 que sai da fábrica. Estas características são definidas nas classes que podem ser vistas como a planta usada para construir o avião.
A figura 2.5 representa uma classe, e pode-se observar a semelhança com o diagrama utilizado para representar os objetos. O retângulo levemente apagado sugere que a classe é apenas um molde onde se encaixam os objetos. Apesar desta semelhança, a classe não é um objeto, pois não possui um estado, nem um comportamento específico, portanto, uma classe não é algo que existe e que possa
ter estados. De uma maneira geral, uma classe pode ser definida como um gabarito com o qual objetos podem ser construídos.
Figura 2.5. Representação de uma classe
Por exemplo, com as plantas que contêm o projeto de um avião Cessna, pode-se construir vários aviões Cessna. O projeto inclui as especificações do motor, da fuselagem, da asa, desenhos em perspectiva, moldes, entre outros, e descreve em detalhes tudo o que o Cessna pode fazer, ou seja, como vai funcionar o elevador, o aileron, o leme, o trem de pouso e outros. Portanto, contêm tudo o que um Cessna tem, mas não é um Cessna.
