Você está na página 1de 9

Uma arquitetura de componentes para processamento de imagens ambientais.

Allan Gonçalves de Oliveira1, Gustavo Liberatti1, Rodicrisller Rodrigues¹, Josiel


Maimone de Figueiredo1, Cláudia Martins1, Andréia Bonfante1
1
Instituto de Computação – Universidade Federal de Mato Grosso (UFMT)
Av. Fernando Correia da Costa s/n. - 78060-900 – Cuiabá – MT - Brazil
allan@pgfa.ufmt.br
{liberatti.gustavo,rodi.067}@gmail.com,
{josiel,claudia,andreia}@ufmt.br

Resumo

Diante do crescente aumento da utilização de imagens de sensoriamento remoto em várias áreas do


saber como fontes de informações, este trabalho propõe uma arquitetura baseada em serviços e
componentes visando uma arquitetura flexível e interoperável para o processo de análise e
interpretação de imagens de sensoriamento remoto.
Palavras Chave: Sensoriamento Remoto, Imagens multi-espectrais, Arquitetura orientada a
componentes, Arquitetura orientada a serviços, Componentes de Software.
Abstract
Given the increasing use of sensing images in several remote areas of knowledge as sources of
information, this work proposes an architecture based on services and components targeting a flexible
and interoperable architecture for the process of analysis and interpretation of remote sensing images.
Key-Words: Remote Sensing, Multispectral Images, Service component architecture, Service-
Oriented Architectures, Software Components.

1. Introdução
A necessidade de controle e gerenciamento dos recursos ambientais tem levantado discussões
e impulsionado pesquisas que buscam reforçar e aperfeiçoar esse processo. Os esforços vão
desde áreas correlatas da geografia, quanto na computação. Nesse contexto é notável a
crescente participação das imagens de sensoriamento remoto (SR). Por sensoriamento remoto
entende-se um conjunto de técnicas para a obtenção de dados com o auxílio de sensores
remotamente localizados, normalmente, em satélites artificiais, ou e em aviões (aeroportados).
As imagens contêm grande quantidade de informações, o que nem sempre é de fácil
interpretação para o ser humano. Segundo Crósta (1992), o sistema visual humano, não é
capaz de processar grande volume de informações presentes em uma imagem, apesar da sua
notável capacidade de reconhecer padrões. Isso se deve a vários tipos de distorções inerentes
ao processo de aquisição , transmissão e visualização de imagens.
Desse modo, o papel das técnicas de processamento digital de imagens (PDI) é facilitar
essa interpretação, realçando, ou mesmo extraindo as informações mais relevantes ao
especialista de um dado domínio. O grande problema surge quando analisado o custo
computacional envolvido na tarefa de processamento de imagens. Imagens adquiridas via SR
acarretam um peso a mais, devido a sua natureza possivelmente multiespectral. O termo
multiespectral refere-se a retratar uma mesma região sob diversas faixas do espectro
eletromagnético. Portanto, não se lida apenas com uma imagem, mas sim com uma
composição de várias imagens referentes a um mesmo objeto.
Muitas vezes é necessário o uso de computadores de alto desempenho, para executarem
tarefas de processamento de imagens, por exemplo a utilização de uma seqüência de imagens
ambientais com intuito de estabelecer uma previsão do tempo. Esse é um tipo de operação em
que o volume de informação envolvida é alto, requerendo mais poder computacional.
Para solucionar problemas onde é requerido um grande poder computacional, técnicas de
computação distribuída se tornam bem viáveis, quanto ao custo em relação ao desempenho
alcançado. Segundo PISA (2004), “um modelo distribuído representa a abordagem com
melhor relação custo/benefício para a implementação de sistemas de armazenamento e
comunicação de imagens (PACS) para aplicações médicas”. Ele propõe um sistema de
compartilhamento de imagens médicas baseado em modelos P2P e serviços web.
No contexto das aplicações distribuídas, se encontra a Arquitetura Orientada a Serviços
(SOA1), que nada mais é que a construção de um sistema baseado em técnicas de
modularização de software, onde cada componente desse sistema é visto como um serviço
que pode ser consumido por uma aplicação.
Partindo do conceito de serviços surge um novo padrão de implementação destes, onde
cada serviço esta associado a uma unidade de implementação denominada componente,
definindo assim a Arquitetura Orientada a Componentes (SCA2).
Esse trabalho apresenta a construção de uma arquitetura para processamento de imagens
de sensoriamento remoto, envolvendo duas abordagens recentes para sistemas distribuídos,

1 SOA ­ Do Inglês Service­Oriented Architecture
2 SCA – Do Inglês Service Component Architecture
que são: Arquitetura Orientada a Serviços, e Arquitetura Orientada a Componentes.
Na Subseção a seguir é feita uma breve apresentação da fundamentação teórica necessária
ao entendimento do trabalho apresentado. Na Seção 2 é apresentado o objetivo do trabalho,
seguido pela apresentação da metodologia utilizada na Seção 3. Por fim são apresentados
alguns resultados na Seção 4 e uma conclusão na Seção 5.

1.1. Arquitetura Orientada a Serviços e Arquitetura Orientada a Componentes

1.1.1. Arquitetura Orientada a Serviços


No que diz repeito a SOA, as definições giram em torno da palavra serviços. Na definição
dada por Merson (2006), SOA é: “um padrão arquitetural em que os componentes do sistema
são usuários de serviços ou provedores de serviços”.
Brown (2008), diz que a Arquitetura Orientada a Serviços é uma descendente das técnicas
de modularização de software utilizadas a mais de 50 anos. A diferença entre SOA e as outras
técnicas de modularização é que os módulos são serviços, o que proporciona maior
flexibilidade mesmo em ambientes que demandam constante mudança de requisitos, e onde
inúmeras tecnologias são utilizadas.
Na programação, um serviço, pode ser entendido como um abstração que encapsula uma
função do software. No contexto de processamento de imagens, por exemplo, um filtro de
contraste pode ser entendido como um serviço.

1.1.2. Arquitetura Orientada a Componentes


Arquitetura de Componentes de Serviços (SCA) busca simplificar a criação e a integração de
aplicações construídas utilizando-se a arquitetura orientada a serviços. Ela disponibiliza um
ou mais serviços que estão associados a uma unidade de implementação.
Como o próprio nome sugere, a unidade de implementação base de uma Arquitetura
Orientada a Componentes é denominada componente. Esses componentes podem trabalhar
juntos para solucionar um problema de um determinado domínio, através das composições3.
A criação das composições dá-se mediante um arquivo de configuração descrito em XML
(Extensible Markup Language) , denominado Service Component Definition Language
(SCDL - comumente pronunciado como “skiddle”). Através desse arquivo, descreve-se os
componentes contidos em uma composição e como eles se relacionam entre si.
De acordo com Chappell (2007), um componente é uma implementação feita em alguma
linguagem de programação, que foi devidamente configurada. A configuração de cada
componente fica a encargo do arquivo de configuração SCDL.
Um componente é formado pelos seguintes elementos: serviços, referências,
propriedades, e bindings. A Figura 1 ilustra as partes que compõe um componente.

3 Do Inglês Composite.
Figura 1: Representação visual das partes que compões um componente.
(LEITE, 2008)

Explicar cada parte que compõe um componente não é o foco desse trabalho, explicação
essa que pode ser encontrada em Leite (2008). Porém, a definição de serviços é importante
para a apresentação da arquitetura proposta.

1.1.3. Serviços
Em uma Arquitetura Orientada a Componentes, um componente, ao implementar uma lógica
de negócio, expõe soluções através de serviços. Cada serviço é composto por uma ou mais
operações, sendo que a maneira como ele é definido varia de acordo com a tecnologia usada.
Utilizando a linguagem Java, por exemplo, pode-se expor serviços através do uso de
interfaces.

2. Objetivo
A arquitetura proposta teve por objetivo alcançar uma estrutura flexível, uma vez que a área
em que se aplica está em constante mudança, tornando-se necessário a inclusão de novas
funcionalidades ao longo do tempo. Além da flexibilidade que serviços e componentes bem
definidos proporcionam, o processamento distribuído deve ser destacado, tendo em vista, que
processamento de imagens de sensoriamento remoto, demandam grande poder computacional.
O diferencial maior dessa arquitetura, é a utilização da Arquitetura Orientada a
Componentes para a implementação do SOA. SCA descreve um modelo que permite
encapsular aplicações e dados utilizando a abstração de SOA. Com isso a características do
SOA, como flexibilidade, modularização e baixo acoplamento, podem ser unidas com as
vantagens oferecidas pela utilização de composições de componentes do SCA.
As composições formam uma sequência de execução de serviços que solucionam um
problema de um determinado domínio.

3. Materiais e Métodos
Para execução deste trabalho, partiu-se do modelo relacional proposto por Figueiredo (2005)
assim como é mostrado no item Resultados e Discussões. Para execução dos testes foram
utilizadas imagens do sensor CBERS 2B, na Órbita 166, Ponto 113, datada de 09/08/2008 da
cidade de Sinop/MT; delimitada no canto superior esquerdo pela latitude 11°43'39,8022"S e
longitude 55°40'40,1031" W e no canto inferior direito pela latitude 12°05'06,7233"S e
longitude 55°21'42,4531", disponíveis no site do Instituto Nacional de Pesquisas Espaciais.
4. Resultados e Discussões

4.1. Definição dos Componentes Base


A definição dos componentes base da arquitetura baseou-se na álgebra relacional proposta por
Figueiredo (2005). Dois componentes principais foram definidos, esses componentes são
ilustrados na Figura 2. O operando imagem conta apenas com uma interface de serviço S1, ao
passo que o operador imagem além de contar com uma interface de serviço S2, faz uso de
duas referências, uma para o serviço S1 e outra pra S2.

Figura 2: Modelos de componentes para (a) operando imagem, e (b)  
operador imagem. (LEITE, 2008)

A implementação dos componentes, foi feita utilizando-se do modelo para criação de


componentes em Java, definido através de especificações pelo padrão Open Service Oriented
Architecture (OSOA). OSOA é um padrão aberto (open pattern), resultado de um trabalho
colaborativo de grandes empresas, tais como: IBM, Sun, Oracle, Red hat, e Siemens.

4.2. Detalhamento dos Componentes Base


Como a implementação dos componentes SCA foi feita em JAVA 4, utilizou-se das interfaces
para definição dos serviços. A implementação do componente fica a encargo de uma classe
Java, que expõe os serviços através da implementação das operações definidas em uma
interface.

Figura 3: Diagrama de Classes mostrando a definição das implementações e serviços dos


componentes Operando Imagem (à direita) e Operador Imagem (à esquerda), apresentados
na Figura 4. (LEITE, 2008)

A classe OperandImpl, implementa o componente Operando Imagem. As interfaces


OperandOuterService e OperandInnerService são para distinção entre operações que serão
dedicadas a um acesso externo ao domínio as que serão usadas pelos componentes do mesmo
4 Java – Linguagem de programação orientada a objetos.
domínio respectivamente.
A interface ProcessorService e a classe ProcessorImpl definem, respectivamente, a
interface de serviço e a implementação mínima, comuns a todos os operadores imagem. Como
não há a instância “Operador Imagem”, sendo essa apenas uma abstração, a classe que a
define é abstrata, ou seja, não permite a criação de objetos a partir dela. Nota-se ainda o uso
do estereótipo <<composite>>, com a intenção de mencionar o uso do padrão de projeto
composite na estruturação de tal classe.
A utilização do padrão composite possibilita uma forma flexível de criar estruturas
hierárquicas de árvores, mantendo cada elemento, que forma essa estrutura, apto a operar sob
uma interface uniforme. Assim, é possível estabelecer uma hierarquia entre os vários
operadores imagem existente.
Uma decorrência do uso do padrão anteriormente mencionado, é que ao invés do
componente operador imagem possuir uma referência para outro componente deste tipo,
pode-se estender tal característica, e permitir uma lista de referências.

4.3. Interface
Denota-se por interface de um sistema como sendo a camada de interação com o usuário,
neste projeto desenvolvida utilizando a tecnologia JSP (JavaServer Pages), associada com a
tecnologia Ajax (Asynchronous Javascript And XM) com o intuito de tornar transparente ao
usuário a estrutura computacional distribuída e permitir fácil interação do mesmo com o
sistema.
Um protótipo de alta fidelidade é apresentado na Figura 6, contendo as primitivas
(algoritmos de processamento de imagens), Domínios (sequências de processamento salvas
pelo sistema) e Processamento ou linha de processamento (sequência de algoritmos e
domínios) que será aplicada na imagem carregada no sistema através de upload.

Figura 4:Protótipo de alta fidelidade da interface web de interação com o sistema.

4.4. Detalhamento do Gerente de Domínio


O ambiente necessário para a tecnologia SCA é implementado pela Apache Tuscany SCA
(Servidor de components SCA) que associado ao servidor de Aplicações Tomcat, viabiliza sua
integração com uma plataforma web.
O servidor Tuscany 1.4 possui limitações quando a implementação dinâmica de domínios,
técnica utilizada na criação de uma linha de processamento baseando-se na arquitetura
proposta.
O Composite Manager (Gerente de Domínio), componente Java desenvolvido segundo o
paradigma orientado a objeto, projetado para suprir a necessidade do servidor Apache
Tuscany SCA em interagir diretamente com a interface web de forma dinâmica em tempo de
execução. Este componente tem como principal função receber uma lista de componentes
encapsulados em objetos Java e gerar o arquivo SCDL que configura o domínio SCA
(sequência de processamento), de modo a permitir ao servidor Tuscany instanciar os
componentes necessários e executar o processamento nas imagens correspondentes.

4.5. Processamento de Imagens na Arquitetura Proposta


O presente trabalho pôde ter sua proposta validada através da real utilização da arquitetura
nele descrita. No caso apresentado, foi utilizado um segmento da imagem do INPE CBERS
2B, representado pela Figura 5. Como ilustrado na Figura 6, nela foi realizado um processo de
realce delineando de forma mais consistente os contornos da imagem para apresentá-la mais
segmentada para o especialista humano, atravé do filtro Sobel; posteriormente, como
apresentado na Figura 7, a imagem foi submetida à binarização, ou seja, segmentou-se os
diversos tons de cinza em dois grupos principais (preto e branco), facilitando a identificação
de componentes na imagem.

Figura 5: Imagem original

Para prover isso os componentes que descrevem os operadores imagens receberam uma
implementação concreta especifica afim de realizar o processamento sobre a imagem. A
lógica com os algoritmos dos filtros para processamento de imagem foram inseridos nas
classes GradientMagnitude e Thresholding implementando a classe abstrata ProcessorImpl,
que define o que é essencial em um componente operador imagem. No arquivo SCDL foram
descritos os componentes GradientMagnitudeComponent e ThresholdingComponent que
promoveram os serviços que, respectivamente, realizaram o realce dos contornos e a
binarização na imagem.
Figura 5: Imagem depois de aplicado   Figura 6: Imagem depois de sofrer o  
o realce processo de binzarização

O processamento aplicado sobre a imagem. dentro da arquitetura proposta, apresentou


resultados compatíveis com as técnicas de processamento utilizadas. A linha de
processamento, descrita pela associação dos componentes que abstraem os processadores de
imagem da álgebra implementada pela arquitetura, possibilita uma fácil aplicação dos
mesmos processadores a outras imagens sem a necessidade de configuração do ambiente.

5. Conclusão
A arquitetura proposta mostra-se eficiente quanto ao seu objetivo. O uso bem definido dos
serviços proporciona maior modularização do sistema. Com a modularização, ao se alterar a
forma como um serviço soluciona um problema, não é necessário que seja feita alteração nos
usuários daquele serviço, desde que a interface do contrato seja mantido inalterada. Outras
grandes vantagens que podem ser notadas nessa arquitetura, é a separação da lógica de
negócio dos detalhes de comunicação, bem como as várias automatizações realizadas pelo
ambiente de execução do SCA.
Seguindo a especificação proposta, a abstração dos operadores de imagem, é possível que
a arquitetura seja estendida para solução de problemas de domínios diferentes, e não apenas
de processamento de imagens. Áreas como Banco de Dados e Inteligência Artificial são áreas
muito presentes nas soluções envolvendo imagens de sensoriamento remoto, e seguindo o
modelo definido é possível que especialistas dessas áreas adicionem novas funções
incrementando as funcionalidades do sistema.
6. Referências
BROWN, Paul C. Implementing SOA: Total Architecture in Practice. 1. ed. United States of America:
Addison-Wesley Professional, 2008.
CHAPPELL, David. Introducing SCA. 2007. Disponível em:
<http://www.davidchappell.com/articles/Introducing_SCA.pdf/>. Acessado em: 10 de julho de 2008.
CRÓSTA, Álvaro P. Processamento Digital de Imagens de Sensoriamento
Remoto. Campinas: Gráfica-ASE-Unicamp, 1992.
FIGUEIREDO, Josiel M. Formalização do domínio imagem para buscar por conteúdo em SGBCs
relacionais. 2005. 136 f. Tese (Doutorado em Ciência da Computação) – Universidade de São Paulo, São Carlos,
2005.
LEITE, Douglas Siqueira. Utilizando técnicas de processamento digital de imagens para extração de
informações em imagens de sensoriamento remoto. 2008. 1 v. Dissertação (Graduação) - Curso de Ciência da
Computação, Universidade Federal de Mato Grosso, Cuiabá, 2008.
MERSON, Paulo. SOA – o que se ganha e o que se perde. Mundo Java, Rio de Janeiro, ano 4, n. 19, p. 40-44,
2006.
PISA, Ivan Torres ; Paulo Roberto L. Lopes ; HOLANDA, A. J. ; Daniel F. Pires ; RUIZ, Evandro Eduardo
Seron . MIDster: Sistema Distribuído de Imagens Médicas Baseado em Modelos Peer-to-Peer (P2P) e
Serviços Web. In: CBIS'2004 - IX Congresso Brasileiro de Informática em Saúde, 2004, Ribeirão Preto-SP.
Anais do CBIS'2004 - IX Congresso Brasileiro de Informática em Saúde, 2004.