PETROBRAS/E&P/GEREX/GETINF/GEARQ

Av. República do Chile, 65/s.1452 - Centro

Rio de Janeiro, RJ - CEP 20035-900

Tel.: (021) 534-4662/534-3770 - Fax.: (021) 534-3608

e-mail: chaia@ep.petrobras.gov.br, srporto@ep.petrobras.gov.br

Modelagem e projeto orientados a objetos são uma nova maneira de pensar nos problemas usando modelos organizados em torno de conceitos do mundo real (Rumbaugh et al, 1991). O funcionamento do raciocínio humano, que estrutura e classifica o mundo ao seu redor de forma hierárquica e compartimentada, é mais "orientado a objetos" que a relações matemáticas ou a módulos estruturados. Não há dúvida que modelar e projetar com orientação a objetos é fundamentalmente diferente do que com o enfoque tradicional: requer uma maneira diferente de idealizar a decomposição, e produz arquiteturas de software grandemente à parte da cultura de modelagem e projeto estruturados (Booch, 1994). Os modelos e projetos orientados a objetos são mais próximos do mundo real do que os tradicionais. Os modelos de negócio orientados a objetos são mais facilmente construídos e compreendidos pelos profissionais das áreas de negócio. Conseqüentemente, o mesmo ocorre com os modelos que formam a Arquitetura de Informação orientada a objetos. Arquitetura de Informação pode ser definida como o conjunto de representações gráficas (diagramas, grafos, modelos, matrizes etc.) das informações de interesse de uma organização. Objetos de negócio (processos e procedimentos, formulários, arquivos em papel etc.), da Arquitetura de Negócio, serão objetos de software (programas, telas, tabelas de bases de dados etc.). Arquitetura de Negócio pode ser definida como o conjunto de representações gráficas (diagramas, grafos, modelos, matrizes etc.) dos objetos de negócio de interesse de uma organização. Outros objetos de software serão acrescidos para se formar sistemas de computador capazes de apoiar o negócio.

A unidade fundamental é o objeto. Além de estrutura de dados, a construção do objeto agrega comportamento. Podem ser ainda acrescidos regras, conhecimento, responsabilidades, ciclo de vida. Estes elementos, apenas fracamente conectados no enfoque tradicional, são fortemente acoplados uma vez que são partes integrantes do objeto. Uma vez modelado, o objeto é utilizado como uma peça que se pega na prateleira e se encaixa em um sistema, sem sofrer modificações.

Na Arquitetura de Informação orientada a objetos, a orientação a objetos provê embasamento desde a fase de planejamento até a fase de construção, tanto de softwares quanto de bases de dados.

Serão apresentadas a seguir, resumidamente, algumas das principais características de orientação a objetos.

Podemos definir objeto como abstração de um particular aspecto de interesse, incluindo não somente sua estrutura, como nos métodos tradicionais, mas também comportamento, regras, conhecimento, responsabilidades, ciclo de vida, intrínsecos ao aspecto em questão. Objetos com características comuns são agrupados em classes.

Pode-se compreender apenas uma pequena quantidade de informações ao mesmo tempo. Assim, utilizamos abstração para enfocar somente a parte mais importante do que estamos estudando com maior conteúdo semântico. Objetos, como abstrações de elementos do mundo real, representam informações bem compartimentadas de forma coesa e densa (Graham, 1994). A orientação a objetos facilita especialmente a abstração empregada no processo de modelagem.

Organizar objetos em classes simplifica vastamente a compreensão de sistemas inerentemente complexos (Booch, 1994). A hierarquização das classes obtidas, de acordo com suas semelhanças e diferenças, facilita o reuso e o controle de redundâncias além de simplificar a classificação dos demais objetos participantes do sistema. No processo de classificação, a definição das classes e a hierarquização das mesmas acontece, geralmente, concomitantemente.

Uma característica derivada da forma muito comum de hierarquia "é um", é a herança. Subclasses herdam estrutura e comportamento das subclasses às quais estão ligadas, evitando assim redundâncias e inconsistências. Deve-se observar a possibilidade de herança múltipla no caso em que uma subclasse pode ter relacionamento "é um" com mais de uma superclasse.

Modularidade é a propriedade de um sistema decomposto em um conjunto de módulos com alta coesão e baixo acoplamento. Quando aplicada a sistemas orientados a objetos, traz consigo certos requisitos próprios dos quais destaca-se o encapsulamento. Encapsular significa ocultar as informações intrínsecas ao módulo dentro do mesmo, significa enxergar cada objeto como uma unidade fechada com características visíveis apenas pelo próprio objeto. Para se conhecer informações de objetos, deve-se obtê-las através de requisições àqueles e não por meio de verificações diretas externas ao objeto.

Os objetos existem em convívio com outros objetos, e não isoladamente. Assim, chama-se comportamento às ações e reações de um objeto, mudando de estado e trocando mensagens, em contato com os demais objetos. É sua atividade visível. É representado pelos chamados métodos, descritos para cada classe de objetos.

Quando é necessário guardar um dado, de maneira que este ocupe um certo espaço durante um certo período de tempo, devemos prover a persistência do mesmo. Neste caso, as preocupações quanto a eficiência e eficácia são as mesmas dos SGBD convencionais. Além destas, é necessário tratar versões do objeto.

Outras características bastante interessantes, provenientes da área de inteligência artificial, são a representação de conhecimento e a definição de regras sobre objetos ou classes de objetos. É crescente a colaboração entre as áreas de orientação a objetos e de inteligência artificial, trazendo grandes contribuições a ambas.

A expressão "orientado a objetos" tornou-se quase sinônima de modernidade, qualidade e valor nos círculos de Tecnologia de Informação (Graham, 1994). Mas há hoje grande confusão sobre o que é orientação a objetos. A maior parte dos trabalhos nesta área se referem tão-somente à programação orientada a objetos. Vamos estatuir que orientação a objetos é toda uma filosofia de modelagem e projeto que abrange todas as fases da Tecnologia de Informação: planejamento, análise, projeto e construção.

A história da orientação a objetos se assemelha à história da computação. Inicialmente a preocupação era com a programação, surgindo depois projeto e análise. Modelagem de simulação é, particularmente, um problema difícil quando programado em uma linguagem convencional de terceira geração (COBOL, FORTRAN, C, Pascal etc.). A programação orientada a objetos iniciou-se com o desenvolvimento da linguagem Simula em 1967 especificamente para simulação de eventos discretos, continuando com a criação da linguagem Smalltalk, que introduziu o termo "orientado a objetos", nos anos 70. Esta última quase fez da noção de objeto um mito. Desde então surgiram várias linguagens inspiradas por aquelas e que se dizem orientadas a objetos. Algumas linguagens tradicionais, como Pascal e C, foram estendidas para suportar orientação a objetos.

A fase seguinte, nos anos 80, caracterizou-se pelo interesse nas interfaces gráficas com usuários (GUI). Os pioneiros nesta área criaram a interface WIMP - W para windows (janelas), I para icons (ícones) , M para mice (plural de mouse) e P para pointers (ponteiros). Os conceitos básicos de Smalltalk estão fortemente ligados a interfaces WIMP. A conseqüência mais evidente do sucesso das interfaces WIMP é o grande número de bibliotecas de objetos que foram construídas para desenvolvimento de interfaces deste tipo. Sem a reusabilidade inerente à orientação a objetos, estas interfaces não poderiam ter sido construídas em tão larga escala (Graham, 1994), sendo demasiado complexas e de custo de desenvolvimento muito elevado. Como exemplos temos Presentation Manager e Windows, para PC-compatíveis, e OpenLook e OSF Motif para sistemas abertos baseados em UNIX.

Desde os meados dos anos 70, tem havido considerável influência mútua entre as áreas de pesquisa e desenvolvimento em inteligência artificial e em orientação a objetos. As principais contribuições da inteligência artificial à orientação a objetos foram a sofisticação das teorias sobre herança, e a inclusão de conceitos (regras, mensagens, conhecimento, responsabilidades) como partes de objeto.

As demandas comerciais, juntamente ao amadurecimento da programação orientada a objetos, levaram à necessidade de as áreas de pesquisa e desenvolvimento em orientação a objetos se preocuparem com engenharia de software (nos moldes dos métodos estruturados), reusabilidade dos softwares (modularidade), sistemas abertos, e concorrência na utilização de dados persistentes, que suportassem orientação a objetos. Os benefícios de reusabilidade e extensibilidade podem ser aplicados a especificações e projetos assim como a códigos (Graham, 1994). Em um contexto mais geral de engenharia de software, quanto mais alto, em termos de abstração, o nível de reuso, maior o benefício (Prieto-Diaz, 1987), (Biggerstaff, 1989), (Sommerville, 1989).

Uma vez que os esforços foram mais voltados a assuntos como interface com usuários e programação do que a assuntos como gerenciamento de bases de dados ou arquivos, houve muitos problemas relacionados a desempenho dos softwares baseados em linguagens orientadas a objetos. Assim, as linguagens orientadas a objetos fracassaram muito freqüentemente no tratamento de persistência, de compartilhamento, de concorrência etc. O desenvolvimento de sistemas gerenciadores de bancos de dados orientados a objetos (SGBDOO) é uma resposta a estes problemas (Graham, 1994). A solução de construção de SGBDOO aparece, entretanto, em um momento em que os bancos de dados relacionais começaram a se tornar confiáveis, sendo cada vez mais utilizados pelas empresas. Assim, os principais fornecedores ofereceram diversas extensões ditas pós-relacionais aos SGBD comerciais esperando, deste modo, prover produtos capazes de aliar características de orientação a objetos à qualidade dos produtos relacionais, cada vez mais consagrada.

Presentemente, a ênfase da área de orientação a objetos migrou da construção e codificação para planejamento, análise e projeto. Cresce a consciência da importância de sistemas abertos e padrões. A ênfase maior tem sido sobre utilização de métodos e ferramentas orientadas a objetos na elaboração de aplicações com pesada carga computacional e que manipulem grandes volumes de dados. Nos últimos anos, tem crescido muito a discussão sobre duas importantes correntes: incorporar a métodos estruturados e ferramentas tradicionais características da orientação a objetos; ou criar métodos e ferramentas completamente novos e puramente orientados a objetos. Quanto aos SGBD, há importantes questões ainda em aberto. Como tratar eficientemente persistência de objetos, granularidade (nível de visão do objeto) e versões de objetos? Como conseguir a eficiência desejada, compatível com a alcançada pelas linguagens declarativas de consultas relacionais, baseando as consultas na identidade de objetos? Parece até irônico que esta última característica seja comum aos SGBDOO e aos primeiros SGBD hierárquicos e de rede (Graham, 1994).

Uma visão geral sobre a história da orientação a objetos nos mostra uma época de criação inovadora na década de 70, de grande confusão nos anos 80, tanto quanto a conceitos como a aplicação dos mesmos, e de amadurecimento na corrente década.

O futuro da orientação a objetos parece bastante promissor. Três dos maiores "gurus" nesta área estão unidos para formar uma linguagem padrão para modelagem orientada a objetos (Meyer, 1996).

Muitos softwares, aplicações geralmente especificadas, construídas, mantidas e, na maior parte das vezes, utilizadas apenas pelo próprio usuário, seja este profissional de informática ou não, são de fato simples. Estes sistemas tendem a ter propósito limitado e curta vida, e muito raramente as características de reusabilidade, manutenibilidade e extensibilidade são importantes.

Estamos interessados em softwares para utilização em empresas. Dentre estes encontramos aplicações que apresentam comportamentos muito variados, como por exemplo sistemas reativos que causam eventos e são comandados por eventos do mundo real; aplicações que mantêm a integridade de milhares de registros de dados permitindo, ao mesmo tempo, alterações e consultas concorrentes; aplicações em que tempo e espaço são recursos escassos, como sistemas que controlam entidades do mundo real como o tráfego de uma rede ferroviária. Tais sistemas tendem a ter uma vida longa e, com o passar do tempo, muitos usuários dependem de seu funcionamento apropriado. Normalmente é muito difícil, senão impossível, um desenvolvedor individual compreender todo o escopo do sistema e seus detalhes. Esta complexidade é uma propriedade da essência do "grande" software. Devemos considerar maneiras mais disciplinadas de tratar a complexidade.

Os problemas que tentamos solucionar com um software geralmente envolvem elementos complexos com requisitos algumas vezes contraditórios tais como usabilidade, desempenho, custo, confiabilidade, além da natural complexidade do problema.

Esta complexidade é conseqüência da "diferença de impedância" que existe entre usuários e desenvolvedores. Os usuários acham muito difícil precisar suas necessidades de tal forma que os desenvolvedores possam entender. Este fenômeno não demonstra propriamente falha de usuários ou de desenvolvedores. Ocorre porque cada grupo conhece bem seu próprio campo, e mal o campo do outro. Usuários e desenvolvedores têm perspectivas diferentes da natureza do problema.

Mesmo que os usuários tenham perfeito conhecimento de suas necessidades, os instrumentos com que os desenvolvedores contam para descrevê-las são alguns desenhos (diagramas) acompanhados de grande volume de textos. Estes documentos possibilitam interpretações diversas, e freqüentemente apresentam elementos que são mais projetos ou intenções do que requisitos essenciais.

A estes complicadores todos não há como escapar.

A tarefa fundamental da equipe de desenvolvimento de software é "construir" a ilusão de simplicidade - para salvaguardar os usuários desta vasta e freqüentemente arbitrária complexidade externa (Booch, 1994). Tentamos escrever menores códigos inventando mecanismos inteligentes e poderosos que nos dão impressão de simplicidade, e também reusando código e partes de projetos. Entretanto, softwares atualmente desenvolvidos usualmente são medidos em centenas de milhares de linhas de código em linguagem de programação de alto nível. Mesmo que o sistema seja bem modularizado e organizado, o número de componentes pode ser muito grande. Isto demanda uma equipe de desenvolvedores. Há sempre dificuldades significativas com a coordenação de qualquer equipe de desenvolvimento, o que pode ser agravado pelo tamanho da equipe, ou por espalhamento geográfico. O principal desafio do coordenador de uma equipe de desenvolvimento é manter a unidade e a integridade do projeto (Booch, 1994).

Uma empresa geralmente não produz todos os componentes necessários ao desenvolvimento de seus produtos finais. Na indústria de software, em que é possível expressar quase todos os níveis de abstração, esta prática é bastante comum. As demais empresas trabalham sobre códigos e padrões bem estabelecidos. Na indústria de software existem bem poucos destes padrões, e o reuso é bastante baixo. A liberdade que a falta de componentes reutilizáveis traz é muito grande, permitindo quase tanta flexibilidade quanto se possa imaginar. Assim o desenvolvimento de software continua sendo um empreendimento de trabalho intensivo.

Quando são relacionadas as vantagens de se utilizar a orientação a objetos como metodologia para a construção de uma abordagem mais natural do mundo real, temos uma visão normalmente ligada aos profissionais da área de Informática. Tentaremos relacionar as vantagens desta metodologia do ponto de vista de geocientistas.

Na verdade, quando imaginamos universos construídos pelo homem, tais como o ambiente bancário, linhas de produção de fábricas e comércio por exemplo, podemos utilizar metodologias tradicionais de modelagem destes ambientes sem causar grandes "traumas" às regras e leis que os regem.

Um universo definido pelo homem, assim como as próprias tecnologias tradicionais de modelagem, tem como características uma certa rigidez de definições e, ao mesmo tempo, uma flexibilidade quanto a alteração, eliminação ou adição de regras.

A rigidez das definições advém da vontade humana de gerar uma condição de contorno bem especificada que contenha as entidades e ações que comporão o campo a ser criado. No caso das ciências ligadas à Natureza esta rigidez, caso exista, não é totalmente apreendida pelo ser humano. Logo, ela na prática não existe como parte do relacionamento homem-Natureza.

O homem, enquanto criador dos seus ambientes próprios de trabalho, pode também alterar estes ambientes e eliminar regras para eles definidas. A partir daí, e apenas neste momento, é que elas devem se comportar rigidamente. Esta flexibilidade não existe(1) na Natureza ou, novamente, se existe não é captada nem controlada pelo ser humano. Este precisa considerar a Natureza como um campo fixo de observação cujas leis básicas são aos poucos identificadas e consideradas estáveis por um determinado tempo, até nova interpretação dos fenômenos observados surgir. A variedade de interpretações referentes a um mesmo fenômeno contribui ainda mais para a escolha de uma metodologia de modelagem orientada a objetos na área de Geociências.

A orientação a objetos, como vimos acima, está mais próxima ao raciocínio humano. Ela capta satisfatoriamente as diversas hierarquias classificatórias que o homem cria na intenção de retratar o Universo ao seu redor.

Podemos ver isto claramente no trabalho de Hoffman e Tripathi (1993) onde são analisadas as interações entre soluções e minerais na natureza de modo a possibilitar o desenvolvimento de um sistema capaz de recriar difíceis interpretações geoquímicas. O sistema modelado é capaz de imitar satisfatoriamente o raciocínio, as habilidades analíticas e as interpretações de geoquímicos experientes (Hoffman e Tripathi, 1993). No que os autores chamam de módulo de Representação do Conhecimento (Knowledge Representation), encontraremos toda esta inteligência artificial. Os objetos foram representados em diversas classes: Elementos, Metais, Componentes, Ligantes, Complexos, Minerais, Gases, Sistemas Naturais e Grupos de Componentes. Estas classes possuem propriedades e relacionamentos do tipo "é um" e "é parte de" que as caracterizam e às suas ligações com outras classes de objetos (Fig.1). É interessante notar que um objeto, como por exemplo o Urânio ou o Mercúrio, pode ser ao mesmo tempo colocado tanto na classe Elementos como na classe Metais. As subclasses podem ser criadas quase que indefinidamente, assim como as propriedades e os relacionamentos entre as classes, de modo que com um maior detalhamento ou um aumento do conhecimento nesta área pode-se ampliar o escopo do modelo de objetos que a representa. Sistemas classificatórios gerados em paralelo podem assim ser representados em uma matriz de relacionamentos que não entram em choque.

Na área de sistemas voltados para informações de dados geográficos, podemos visualizar vantagens semelhantes. Classes de objetos de Pontos, Linhas e Áreas necessitam ter acopladas em suas definições as ações específicas que podem ser executadas com suas instâncias (ou objetos) e entre instâncias de diferentes classes. Bases relacionais não garantem, pela ausência das características acima expostas, a integridade das entidades, a integridade referencial, o tratamento satisfatório de tipos de dados abstratos e geométricos, o fecho transitivo e o desempenho para grande número de pequenas transações, situação característica de dados não convencionais. Isto só pode ser alcançado através de uma camada adicional de processos e procedimentos externos ao sistema gerenciador de bancos de dados (SGBD) (Herring, 1992). Logo, podemos perceber que o tratamento de dados espaciais em sistemas de informação torna-se mais viável quando se utiliza a tecnologia de orientação a objetos desde a fase de modelagem até a fase de construção de um sistema completo (Frank e Egenhofer, 1992).

Na área de geologia estrutural também são necessários tratamentos espaciais que tornam as metodologias tradicionais não tão satisfatória quanto a orientação a objetos. Utilizando esta metodologia é possível tratar geometrias de indicadores cinemáticos do sentido de falhas cisalhantes amplamente conhecidos que são de difícil tratamento por sistemas convencionais (Zhang e Bjørnerud, 1995).

O interesse pela utilização da orientação a objetos têm crescido, como vimos acima, como decorrência de necessidades de áreas específicas do conhecimento humano onde as metodologias convencionais de modelagem e análise não mais satisfazem. Na indústria do petróleo podemos exemplificar este interesse através da criação de um organismo que pretende padronizar o conhecimento da área utilizando a metodologia de orientação a objetos. Este organismo é a POSC (Petrotechnical Open Software Corporation) criada e mantida por grandes empresas de petróleo e da área de Informática. A intenção é criar um padrão de objetos de modo a facilitar não só o intercâmbio comercial de informações como a construção de sistemas que mais satisfatoriamente atendam às necessidades da indústria do petróleo. Também na área de Cartografia, responsável pela construção de Sistemas de Informações Geográficas, foi formado um grupo de trabalho, o OpenGIS, que possui intenções semelhantes às da POSC porém em uma outra área de atuação.

BOOCH, Grady. Object-Oriented Analysis and Design with Applications. Redwood City, USA : Benjamin/Cummings, 1994.

Brooks, Frederick P. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, New York, vol. 20, n.4, p. 10-19, Apr. 1987.

Biggerstaff, T. e Richter, C. Re-usability Framework, Assessment and Directions. Tutorial: Software Reuse - Emerging Technology. IEEE Computer Society, EH0278-2, p. 3-11. 1989.

FRANK, Andrew U., EGENHOFER, Max J. Computer Cartography For GIS: An Object-Oriented View On The Display Transformation. Computers & Geosciences, Oxford, v. 18, n. 8, p. 975-987, 1992.

Graham, I. Object Oriented Methods. Addison-Wesley : Wokingham, England, 1994.

herring, john R. TIGRIS: A Data Model For An Object-Oriented Geographic Information System. Computers & Geosciences, Oxford, v. 18, n. 4, p. 443-452, 1992.

hoffmann, forrest M. e TRIPATHI, Vijay S. A Geochemical Export System Prototype Using Object-Oriented Knowledge Representation And A Production Rule System. Computers & Geosciences, Oxford, v. 19, n. 1, p. 53-60, 1993.

MEYER, Bertrand (ed.). Gurus Share Insights On Objects. Entrevista com Grady Brooch, Ivar Jacobson e James Rumbaugh. Computer, New York, v. 29, n. 6. p. 95-99, Jun. 1996.

Prieto-Diaz, R. e Freeman, P. Classifying software for reusability. IEEE Software, [S. l.], v. l4, n.1, p. 6-16, 1987.

Rumbaugh, James E. et al. Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey : Prentice Hall, 1991.

Sommerville, I. Software Engineering. Wokingham, England : Addison-Wesley, 1989.

Zhang, Hubao, Bjørnerud, M. A Macintosh Application Program for Simulating Shear-Sense Indicators Using Object-Oriented Programming. Computers & Geosciences, Oxford, v. 21, n. 3, p. 365-375, 1995.