UFSM

Dissertao de Mestrado
PADRES DE PROJETO NO
DESENVOLVIMENTO DE SISTEMAS
DE PROCESSAMENTO DE IMAGENS
Daniel Welfer
PPGEP
Santa Maria, RS, Brasil
2005
PADRES DE PROJETO NO
DESENVOLVIMENTO DE SISTEMAS
DE PROCESSAMENTO DE IMAGENS
por
Daniel Welfer
Dissertao apresentada ao Curso de Mestrado do Programa de
Ps-Graduao em Engenharia da Produo, rea de concentrao em
Tecnologia da Informao, da Universidade Federal de Santa Maria
(UFSM, RS), como requisito parcial para obteno do grau de
Mestre em Engenharia da Produo
PPGEP
Santa Maria, RS, Brasil
2005
Universidade Federal de Santa Maria
Centro de Tecnologia
Programa de Ps-Graduao em Engenharia da Produo
A Comisso Examinadora, abaixo assinada,
aprova a Dissertao de Mestrado
PADRES DE PROJETO NO
DESENVOLVIMENTO DE SISTEMAS DE
PROCESSAMENTO DE IMAGENS
elaborada por
Daniel Welfer
como requisito parcial para obteno do grau de
Mestre em Engenharia da Produo
COMISSO EXAMINADORA:
Prof. Ph.D. Marcos Cordeiro dOrnellas
(Presidente/Orientador - UFSM-Departamento de Eletrnica e Computao)
Prof. Dr. Felipe Martins Mller
(UFSM-Departamento de Eletrnica e Computao)
Prof. Dr. Jos Antnio Trindade Borges da Costa
(UFSM-Departamento de Fsica)
Santa Maria, 01 de fevereiro de 2005
CIP CATALOGAO NA PUBLICAO
Welfer, Daniel
Padres de Projeto no Desenvolvimento de Sistemas de Pro-
cessamento de Imagens / Daniel Welfer. Santa Maria: Programa
de Ps-Graduao em Engenharia da Produo, 2005.
85 f.: il.
Dissertao (mestrado) Universidade Federal de Santa
Maria. Programa de Ps-Graduao em Engenharia da Pro-
duo, Santa Maria, BRRS, 2005. Orientador: Marcos Cordeiro
dOrnellas.
1. Engenharia de software . 2. Padres de projeto. 3. Pro-
gramao orientada por objetos. 4. Linguagem de Modelagem
Unicada. I. dOrnellas, Marcos Cordeiro. II. Ttulo.
UNIVERSIDADE FEDERAL DE SANTA MARIA
Reitor: Prof. Dr. Paulo Jorge Sarkis
Vice-Reitor: Prof. Dr. Clovis Silva Lima
Pr-Reitor de Ps-Graduao e Pesquisa: Prof. Dr. Ney Luis Pippi
Diretor do Centro de Tecnologia: Prof. Dr. Felipe Martins Mller
Coordenador do PPGEP: Prof. Dr. Joo Hlvio de Oliveira Righi
Coordenador da rea de Tecnologia da Informao: Prof. Dr. Marcos C. d Ornellas
b Essa dissertao foi escrita utilizando a ferramenta de edio L
A
T
E
X2

Tell me and I forget.

Teach me and I remember.
Involve me and I learn.
Benjamin Franklin
Dedico esta dissertao aos meus pais
Paulo Welfer e Renata Welfer
e aos meus irmos Marcos, Tiago e Mrcia
AGRADECIMENTOS
Em primeiro lugar a DEUS que, dentre todas as outras coisas, me deu a vida.
Quero agradecer tambm, de forma muito especial, ao meu orientador Prof. Marcos
Cordeiro dOrnellas que pela sua pacincia, incentivo e auxlio propiciou um ambiente
de trabalho agradvel e produtivo.
Coordenao de Apoio ao Pessoal de Ensino Superior(CAPES) por ter nanciado esse
estudo. E, nalmente, a todos os integrantes do grupo PIGS (Grupo de Processamento de
Informaes Multimdia) que indiretamente, contribuiram para o desenvolvimento desse
trabalho. De forma especial aos alunos de graduao emCincia da Computao Grasiela,
Mnica e Gabrielle (Turma da Mnica), que pelo exmio conhecimento em progra-
mao ajudaram a aumentar a aplicao desse trabalho alm de apontar alguns equvocos
que inicialmente apresentava.
RESUMO
Essa dissertao apresenta componentes de software para processamento e anlise de ima-
gens digitais e um sistema capaz de control-los de forma organizada. Os componentes
precisam ser funcionais, exveis, legveis e de fcil manuteno. Assim, alcanar esses
requerimentos bsicos uma necessidade no processo de desenvolvimento de software.
Componentes de software so projetados para serem usados em uma variedade de ambi-
entes. A arquitetura da linguagem de programao utilizada, no caso Java, permite que
os programas sejam montados a partir de blocos de software. Dessa forma o projetista
pode incorporar facilmente esse componente em uma aplicao, necessitando conhecer
apenas sua interface de entrada e sada. No entanto, encontrar a abstrao certa para
construir software reutilizvel no uma tarefa fcil. Mesmo os projetistas mais experi-
entes em orientao por objetos freqentemente precisam revisar um projeto vrias vezes
antes de conseguir uma soluo apropriada. Por essa razo, a idia de padres de pro-
jeto tem ganhado terreno rapidamente, desde que estabelece uma soluo para um certo
problema de projeto. Estes padres especicam uma maneira para construir, estruturar
e manipular entidades de software em um estilo racional visando, principalmente, geren-
ciar a sua complexidade no domnio de processamento digital de imagens para assegurar a
sua qualidade. Nesse trabalho foram construdos componentes para segmentao de ima-
gens baseado em ltros de convoluo, para melhoria da qualidade da imagem atravs do
processo de equalizao automtica, para armazenamento da imagem em arquivos gr-
cos de diferentes formatos, na criao de um componente para visualizar o histograma,
na visualizao da imagem na tela atravs de interface grca, na converso da imagens
coloridas para tons de cinza e no processo de limiarizao.
Palavras-chave: Engenharia de software , padres de projeto, programao orientada por obje-
tos, Linguagem de Modelagem Unicada.
ABSTRACT
This dissertation presents software components for processing and analysis of digital
images and a system capable to control them in an organized way. The Components
must be functional, context-free, readable and maintainable. So far, achieving these ba-
sic requirements is a need in the software development process. Software components
are designed to be reusable in a variety of different environments. The architecture of
programming language used, in the case Java, allows programs to be assembled from
software building blocks. In that way the designer can incorporate easily these compo-
nents into an application, needing just to know your entrance and exit interface. However,
to nd the right abstractions to build extensible and reusable software is not an easy task.
Even experienced object-oriented designers often need to review a design several times
before getting to one appropriate solution. Therefore, the idea of design patterns has
gained ground quickly since it provides a solution to a certain design problem. These pat-
terns specify a way to build, structure, and manipulate software entities in a reasonably
fashion, aiming mainly, to management your complexity in the domain of digital imaging
processing to assure your quality. In this paper were built components for image segmen-
tation based on convolution lters, for improvement of the quality of the image through
the process of automatic equalization, for image storage in graphic les of different for-
mats, in the creation of a component to visualize the histogram, in the visualization of the
image in the screen through graphic interface, in the conversion of the colored images for
grayscale formats and in the thresholding process.
Keywords: Software Engineering, Design Patterns, Object Oriented Paradigm, Unied Model-
ing Language.
LISTA DE FIGURAS
Figura 2.1: Os trs personagens do processo de componentizao segundo Padmal Vitha-
rana, [VIT 2003]. a) pode-se observar que os componentes so fabricados
para vrios ns sendo que, no h uma relao explcita entre eles, isto ,
so concebidos para serem independentes. b) O montador precisa encontrar
e inter-relacionar os componentes a m de resolver o problema do cliente.
c) O produto de software nal pronto para ser utilizado. . . . . . . . . . . 21
Figura 2.2: Esquema do sistema projetado para suportar a componentizao. . . . . . . 22
Figura 3.1: Uso do diagrama de classes para o problema da equalizao de imagens . . 26
Figura 3.2: A operao de equalizao demonstrada via diagrama de atividades. a ) ex-
ibe o processo de equalizao mais genrico se preocupando apenas com a
entrada e sada de informaes. b ) Explode o processo de equalizao
original permitindo assim visualizar a seqncia lgica exigida pelo algo-
ritmo. Em ambas ilustraes o crculo preto representa o incio do processo
e o crculo circunscrito em outro o seu trmino. . . . . . . . . . . . . . . . 28
Figura 4.1: Desenvolvimento de software em camadas. . . . . . . . . . . . . . . . . . 30
Figura 4.2: a) Mscara 3 x 3 hipottica. b)Imagem original tons de cinza. . . . . . . . 31
Figura 4.3: a) Conhecido como RectIter e percorre os pixels no sentido de cima para
baixo obedecendo a ordem da esquerda para direita. b)Conhecido como
RookIter e permite uma navegao arbitrria no que diz respeito a ordem.
Nesse exemplo seguido o sentido de cima para baixo porm a ordem varia
entre esquerda e direita e da direita para a esquerda. . . . . . . . . . . . . . 32
Figura 4.4: Esquema para o uso dos operadores JAI. . . . . . . . . . . . . . . . . . . . 37
Figura 4.5: Implementao da lgica central do componente de converso para tons de
cinza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 4.6: a )Imagem original colorida. b )Imagem em tons de cinza. . . . . . . . . . 40
Figura 4.7: Visualizao do histograma da imagem da gura 4.6 b). . . . . . . . . . . 41
Figura 4.8: a ) Interface grca confusa e desorganizada. b ) Uma interface com a
mesma eccia porm organizada atravs do agrupamento de funcionalida-
des similares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 5.1: Um exemplo de aplicao do padro arquitetural Layer: o modelo OSI. . . 46
Figura 5.2: viso das Camadas de um sistema com seus componentes internos e como
eles se relacionam. Adaptado de Buschmann et al. [BUS 1996]. . . . . . . 48
Figura 5.3: Uma ferramenta de construo de diagramas UML para a modelagem de
software orientado por objetos. . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 5.4: Iterface grca construda com a mescla dos trs Look and Feel nativos do
Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 5.5: Um exemplo clssico do uso do padro Abstract Factory: mudando o estilo
visual dos componentes grcos do JDK. . . . . . . . . . . . . . . . . . . 53
Figura 5.6: Componente grco construdo a partir de uma hierarquia de pacotes Java.
(Imagem obtida da documentao HTML do j2sdk1.4.1_02) . . . . . . . . 55
Figura 5.7: Opadro de projeto Faade atuando para tornar umcomponente mais exvel.
a) mostra a maneira confusa com que as novas classes E e F se comunicam
com as classes do componente. b) a aplicao do padro Faade para fazer
o meio campo entre as interfaces dos componentes e das classes novas E e F. 56
Figura 5.8: Duas funes na linguagem C que expressam a mesma inteno. Adaptao
de Buschmann et al. [BUS 1996]. . . . . . . . . . . . . . . . . . . . . . . 59
Figura 6.1: Usando os comentrios de documentao para explicar um componente. . . 63
Figura 6.2: As trs classes bsicas do framework StoneAge. . . . . . . . . . . . . . . 64
Figura 6.3: Como feito o controle das chamadas dos mtodos por componentes grcos. 65
Figura 6.4: Uma alternativa de controle mais legvel. . . . . . . . . . . . . . . . . . . 66
Figura 6.5: Uma viso mais completa da estruturao do sistema base segundo o padro
de projeto de controle denominado de Command. . . . . . . . . . . . . . . 67
Figura 6.6: A primeira interface j funcional do StoneAge. . . . . . . . . . . . . . . . 68
Figura 6.7: A coleo Vector utilizada para resolver o problema da operao undo. . 69
Figura 6.8: As operaes de Undo e Redo sob a perspectiva de um padro idiomtico. . 70
Figura 6.9: A modelagem UML das operaes Save e Save As . . . . . . . . . . . . 71
Figura 7.1: O kernel de convoluo utilizado: a ) ltro vertical e b ) ltro horizontal de
Frei e Chen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 7.2: Modelo Algbrico para encontrar o Thresholding, onde k o limite especi-
cado pelo usurio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 7.3: As vrias etapas necessrias para detectar a borda. . . . . . . . . . . . . . 75
Figura 7.4: O modelo estrutural do padro Builder. O objeto Image o produto que
est sendo construdo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figura 7.5: A viso de projeto completa do componente de segmentao baseado em
mscaras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 7.6: A interface grca do componente de segmentao baseado em contornos. 78
LISTA DE TABELAS
Tabela 4.1: Alguns operadores pontuais presentes na JAI. . . . . . . . . . . . . . . . . 35
Tabela 4.2: Operadores de rea implementados pela JAI. . . . . . . . . . . . . . . . . 35
Tabela 4.3: Operadores Geomtricos: manipulam a forma, tamanho e orientao da
imagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tabela 4.4: Operadores de arquivo: essenciais para iniciar qualquer processamento e/ou
armazenar os resultados do mesmo. . . . . . . . . . . . . . . . . . . . . . 36
Tabela 4.5: Outros operadores muito usuais. . . . . . . . . . . . . . . . . . . . . . . . 36
Tabela 5.1: Os padres de projeto de Gamma agrupados em categorias ans. . . . . . . 51
LISTA DE ABREVIATURAS E SIGLAS
API (Application Programming Interface). Interface de programao para construo de
software.
AWT (Abstract Window Toolkit). API que prov, entre outros, componentes grcos de inter-
face com o usurio.
CBSD (Component-Based Software Development). Desenvolvimento de software baseado em
componentes.
CVS (Concurrent Version System). Mecanismo para gerenciar verses de software.
GUI (Graphics User Interface). Interface grca com o usurio.
HCI (Human-Computer Interaction). Interao entre homem e mquina.
JAI (Java Advanced Imaging). API Java para processamento de imagens.
JDK (Java Development Kit). Kit de Desenvolvimento Java.
OOP (Object-Oriented Programming). Programao orientada por objetos.
PIGS (Programmers Imaging Generic System). Grupo de pesquisa dedicado ao estudo de
imagens digitais da UFSM.
RMI (Remot Method Invocation). Invocao de Mtodos Remotos na construo de software
cliente-servidor.
STL (Standart Template Library). Biblioteca C++ para programao genrica.
UML (Unied Modeling Language). Linguagem de Modelagem Unicada.
SUMRIO
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Estrutura da dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 REFERENCIAIS TERICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Construo de Software Adaptvel . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Padres de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Desenvolvimento de Software Baseado em Componentes . . . . . . . . . . . . 20
2.4 Linguagem de Modelagem Unicada - UML . . . . . . . . . . . . . . . . . . . 21
3 A MELHORIA DA QUALIDADE DE PRODUTOS E PROCESSOS NA ENGEN-
HARIA DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Utilizando um Processo de Software . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Programao Orientada por Objetos . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 A Ferramenta de Modelagem Unicada para Projetar Software no Modelo
de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 DESENVOLVIMENTO DE SOFTWARE NO DOMNIO DE PROCESSAMENTO
DE IMAGENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 A Camada Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 A Camada de Aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 A camada de Interface com o Usurio . . . . . . . . . . . . . . . . . . . . . . 41
5 PADRES DE CONSTRUO DE SOFTWARE PARA O PROCESSAMENTO
DE IMAGENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1 Os padres Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Da Lama Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Padres Gamma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 Padres de Criao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.2 Padres Estruturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.3 Padres Comportamentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Padres Idiomticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6 STONEAGE: UMAFERRAMENTAJAVABASEADAEMCOMPONENTES PARA
O PROCESSAMENTO DE IMAGENS . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1 A Linguagem de Programao . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 A Aplicao dos Padres no StoneAge . . . . . . . . . . . . . . . . . . . . . . 64
7 APLICAO: UMCOMPONENTE PARASEGMENTAODE IMAGENS BASEADO
EM FILTROS DE CONVOLUO . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1 O processo de segmentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2 Os padres utilizados para projetar o componente . . . . . . . . . . . . . . . 75
8 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
15
1 INTRODUO
Atualmente, o processamento e a anlise de imagens esto sendo empregados nas mais di-
ferentes reas do conhecimento. Na rea mdica, por exemplo, as imagens so utilizadas para
diagnosticar patologias. No domnio geoespacial, elas so utilizadas para visualizar o estado
climtico de uma regio ou at mesmo para registrar o relevo de outros planetas. No campo co-
mercial, as imagens esto cada vez mais presentes no cotidiano das pessoas atravs das cmeras
digitais e scanners cada vez mais portteis.
Porm, as imagens digitais, normalmente so dependentes de um software que gerencia
todo o seu processamento ou anlise. E , justamente nesse contexto, que os padres de projeto
so utilizados. Os padres de projeto so formas de construo de software comprovadamente
funcionais que garantem legibilidade, fcil manuteno e reutilizao de cdigo-fonte no desen-
volvimento de alguma aplicao computacional.
Os softwares existentes para computao cientca envolvendo imagens, geralmente so
concebidos para funcionarem sob uma nica plataforma de sistema operacional alm de, no
seremde domnio livre, isto , so proprietrios. Umbomexemplo a biblioteca MMORPHque
s funciona se agregada no programa MATLAB e que, por sua vez, no disponibiliza livremente
seu cdigo-fonte para que seja aprimorado pela comunidade de usurios.
Nessas circunstncias, essa dissertao tem por objetivo desenvolver um software para o
processamento e anlise de imagens que tenha como principais caractersticas a independncia
de plataforma operacional, cdigo-livre e cuja implementao tenha sido baseada em padres
de projeto. Esse software recebeu o nome de StoneAge
1
e sua codicao foi feita atravs
da linguagem de programao Java associada com a interface para programao voltada para
imagens Java Advanced Imaging (JAI).
O StoneAge utiliza a idia de componentizao para resolver os vrios problemas que en-
volvem as imagens. Ele funciona como um repositrio de componentes independentes que, por
sua vez, abrigamdiferentes algoritmos para manipular as imagens. Porm, tanto esse repositrio
quanto os inmeros componentes, se utilizam da idia de padres de projeto para assegurar as
caractersticas anteriormente citadas como reuso, legibilidade e fcil manuteno de cdigo-
fonte. Essas caractersticas tornam um componente de software adaptvel, isto , que pode ser
reaplicado em outros contextos de forma rpida e funcional. Assim, o problema apresentado
1
O StoneAge pode ser obtido livremente em (http://www.inf.ufsm.br/~welfer).
16
por essa dissertao o de identicar e implementar padres de projeto para o desenvolvimento
de componentes de software adaptveis para problemas de processamento e anlise de imagens.
1.1 Estrutura da dissertao
O captulo 2 apresenta a reviso bibliogrca dos principais tpicos abordados nessa disser-
tao como os padres de projeto propriamente dito, o processo de componentizao e a ferra-
menta de modelagem unicada (UML) que foi utilizada para projetar o StoneAge. No captulo
3 descrito a aplicao de processos de engenharia de software, como a UML e programao
orientado por objetos, para obter software de qualidade. O captulo 4 apresenta como ocorre
o desenvolvimento de software especialmente para o processamento de imagens. O captulo 5
descreve os padres de construo arquitetural, de projeto e idiomticos para a construo de
software. O captulo 6 apresenta os padres aplicados no StoneAge alm da linguagem de pro-
gramao utilizada. A seguir, no captulo 7, mostrado um componente para segmentao de
imagens presente no StoneAge e os padres utilizados para a sua implementao. Por m, no
captulo 8, so apresentadas as consideraes nais desse trabalho.
17
2 REFERENCIAIS TERICOS
Neste captulo apresentado uma viso global sobre a gerao de software adaptvel. Para
isso, ser descrito na seo 2.1 algumas noes de engenharia de software para a produo
de componentes exveis. Na seo 2.2 descreve-se as principais caractersticas dos padres
de projeto. A seo 2.3 aborda o desenvolvimento de software baseado em componentes as-
sim como seus riscos e desaos. A seo 2.4 encerra o captulo abordando a linguagem de
modelagem unicada - UML (Unied Modeling Language) e como a mesma empregada para
projetar componentes de software tanto em nvel conceitual como na fase de implementao.
2.1 Construo de Software Adaptvel
A implementao de um componente capaz de resolver problemas especcos em diferentes
contextos e aplicaes uma tarefa difcil de ser realizada. Isso ocorre porque essa imple-
mentao no concebida para ser um mdulo ou artefato de cdigo isolado, mas sim, para
atuar em extensos, inmeros e distintos pacotes de software que necessitam da mesma soluo
[WEI 1999]. Para isso se faz necessrio incorporar ao desenvolvimento desse componente, tc-
nicas de engenharia de software capaz de torn-lo, acima de tudo, adaptvel.
Porm, para tornar uma soluo adaptvel necessrio prever as diversas situaes onde ela
pode ser utilizada, o que, na maioria das vezes, de difcil percepo, principalmente para um
desenvolvedor com pouca experincia. Nesse contexto, segundo Karsten Weihe [WEI 1999], os
projetistas desse componente reutilizvel devem se preocupar em usar uma abordagem tanto em
baixo quanto em alto nvel. A etapa de tornar o componente adaptvel atravs de tcnicas em
baixo nvel refere-se a reutilizao de funes atravs de tipos parametrizados de dados, conhe-
cidos como genricos pelos usurios das linguagens Eiffel e Ada ou gabaritos STL (Standart
Template Library) da linguagem C++ [GAM 2000]. A idia central dessa abordagem manipu-
lar tipos primitivos de dados como inteiros, reais, caracteres e outros de maneira simplicada.
Para isso, uma das formas possveis denir um tipo abstrato de dados, como uma funo ou
uma classe, capaz de aceitar, sem especicaes predenidas, todos os tipos primitivos imple-
mentados pela linguagemde programao usada [JOS 1999][DEI 2001]. Dessa forma, ganha-se
exibilidade e independncia de dados levando a implementao de um algoritmo a se tornar um
componente de software adaptvel a vrias circunstncias dentro de uma ou diversas aplicaes.
18
J na construo de cdigo adaptvel atravs de uma abordagem em alto nvel, utiliza-se
tcnicas de programao orientada por objetos associada com as metodologias de constru-
o de software baseadas principalmente em padres arquiteturais e de projeto [BUS 1996]
[GAM 2000]. Um padro nada mais do que a descrio de uma determinada soluo para um
problema que aparece com freqncia no projeto de software [COO 1998]. Dessa forma, uma
vez que a equipe de projeto esteja familiarizada com certos padres, a mesma pode aplic-las
na soluo de problemas semelhantes [GAM 2000]. Assim, um padro um conjunto de infor-
maes sobre um dado problema que capta a sua estrutura essencial e caracteriza um conjunto
de solues comprovadamente bem sucedidas para o mesmo.
Dessa forma, para gerar componentes reutilizveis e, naturalmente adaptveis, para proble-
mas de processamento de imagens digitais, no basta apenas identicar os objetos que so fre-
qentemente usados pelos programadores, como tambm interpretar esses objetos e manipul-
los de forma que suas interfaces
1
e seus relacionamentos com outros objetos, propiciem o
seu acoplamento com outras aplicaes de forma satisfatria. Esse o grande desao desse
trabalho e um importante passo para auxiliar na implementao de componentes complexos
muito comuns em problemas de processamento de imagens e que, posteriormente, possam ser
necessrios em muitos outros contextos. Assim, concluindo essa seo, deve-se projetar um
componente que atenda o maior nmero de requerimentos possveis, o que, muitas vezes, no
claro na fase de projeto, precisando assim, construir esse conhecimento antes da aplicao
dos padres de projeto anteriormente citados. Esse conhecimento, em engenharia de software,
faz parte da denio do modelo conceitual e sua preocupao a especicao do domnio
do problema no mundo real para s ento, iniciar a descrio dos componentes de software
[LAR 2000].
2.2 Padres de Projeto
A idia de uma linguagem de padres originria do arquiteto e matemtico Christopher
Alexander, que no nal da dcada de 70 escreveu dois livros que especicavam e descreviam
o uso de padres em projetos arquitetnicos [ALE 1977, ALE 1979] mais especicamente no
planejamento de projetos de edifcios e cidades [GAM 2000]. Alexander provou que os mto-
dos de construo at ento utilizados geravam produtos que no satisfaziam os indivduos e a
sociedade, ou seja, no atendiam as suas reais necessidades. Na busca pela qualidade dos produ-
tos e conseqente satisfao das pessoas, Alexander estabeleceu 253 padres que descreviam,
em uma forma de catlogo, os problemas que se repetem em diferentes contextos ao mesmo
tempo que, formalizava uma soluo para os mesmos. Esses padres alcanavam a qualidade
porque, na sua soluo, Alexander enfatizava a comunicao entre as pessoas que participavam,
mesmo que indiretamente, da elaborao do projeto [SAL 1997] [LEA 1993]. A partir dessa
idia pode-se reutilizar uma soluo na construo de casas, edifcios e outros obtendo resulta-
dos diferentes, otimizando o tempo de construo de alguma estrutura e, principalmente, sendo
1
A interface aqui tem o sentido de especicar as operaes que uma determinada unidade de programa dene
19
capaz de atender os desejos dos usurios nais de alguma obra ou produto.
Quando essa idia de identicar padres de problemas foi utilizada no processo de desen-
volvimento de software, principalmente atravs dos catlogos de Gamma et al. [GAM 2000]
e Buschmann et al. [BUS 1996], uma nova maneira de pensar em projetos de software surgiu
[MAY 2003].
Essa nova abordagemassociada como paradigma de programao orientada a objetos deniu
23 padres de projeto comumente conhecidos como padres da Gangue dos Quatro (Gang of
Four) GoF referentes a Erich Gamma e seus colegas. Esses padres so divididos em trs ca-
tegorias: os padres de criao, padres estruturais e os padres comportamentais. A primeira
categoria intuitivamente representa formas para o processo de criao ou instanciamento de
objetos. A segunda identica os padres que compe as classes ou grupos de classes e o l-
timo, isto , os padres comportamentais caracterizam a interao e responsabilidades entre
os objetos, isto , a comunicao entre eles [COO 1998]. Atravs desse catlogo de padres
consegue-se solucionar problemas de projeto assegurando a concepo de componentes adap-
tveis e portanto reutilizveis de fragmentos de cdigo.
Porm esses no so os nicos padres existentes. Segundo Steven Metsker [MET 2002]
existem outros 77 padres que, juntos, provavelmente caracterizam os 100 mais usuais. Entre
esses outros padres pode-se citar os de Buschmann et al. [BUS 1996], que se preocupa em
aplicar formas timas de construo de software sob vrios nveis como o arquitetural, o de
projeto e o idiomtico. O Padro arquitetural cataloga formas para organizar a estrutura funda-
mental de um sistema, isto , aquela parte que ir dar suporte bsico a vrias operaes bsicas.
J o de projeto muito similar aos do Gamma, ou seja, normaliza a construo de componentes
que sero agregados ao sistema e toda a comunicao envolvida entre os objetos responsveis
por essa tarefa. Por m o padro idiomtico utiliza vantagens especcas da linguagem de pro-
gramao que se est sendo utilizada para otimizar o desenvolvimento de algum componente.
Esse padro idiomtico ocorre em baixo nvel e nele se enquadram os generics das linguagens
anteriormente descritas. Um bom exemplo do uso desses padres idiomticos encontrado em
[DOR 2001] e [DOR 2003], que utiliza o paradigma genrico promovido pela biblioteca STL
da linguagem de programao C++ para amenizar a trade dependncia entre tipo de imagem,
estruturas de dados e algoritmos utilizados na resoluo de problemas de processamento de
imagens.
Atualmente a comunidade que trabalha com padres de construo de software tem crescido
muito. Vrios congressos sobre o tema foram implantados em vrias partes do mundo. En-
tre esses congressos
2
cita-se o PLoP (Pattern Languages of Programs), SugarloafPLoP (Con-
ferncia Latino-Americana em Linguagens de Padres para Programao), OOPSLA (Object-
Oriented Programming, Systems, Languages and Applications), ECOOP (European Conference
on Object-Oriented Programming), EuroPLoP (European Conference on Pattern Languages of
Programs) e o VikingPLoP(The Nordic Conference on Pattern Languages of Programs).
2
Informaes mais detalhadas podem ser obtidas no site do grupo dedicado a aumentar a qualidade do desen-
volvimento de software (http://hillside.net/conferences/).
20
Na prxima seo descrito um modelo de organizao de software conhecido como com-
ponentes. Esses componentes esto intimamente ligados aos padres pois sua estrutura interna
concebida baseada em padres de construo. Assim, conclui-se que os padres so um im-
portante passo para o processo de gerao de cdigo-fonte reutilizvel porm, precisam ser
complementados com a idia de componentes para atribuir uma estrutura organizacional para
os cdigos desenvolvidos.
2.3 Desenvolvimento de Software Baseado em Componentes
Essa nova abordagem de planejamento de software adaptvel exige uma implementao
atravs de mdulos denominados componentes. Na mesma medida com que o paradigma de
desenvolvimento estruturado e orientado a objetos inuenciaram programadores e projetistas
do mundo inteiro, tambm assim, o desenvolvimento de software baseado em componentes tem
emergido como a prxima revoluo na concepo de sistemas computacionais [VIT 2003].
Essa tendncia conseqncia natural de uma srie de vantagens como fcil manuteno, maior
qualidade e tempo e custos reduzidos de desenvolvimento. Eles possuem manuteno acessvel
pois permitemsubstituir componentes obsoletos por outros mais robustos e estveis; apresentam
maior qualidade porque so testados e reutilizados em vrias aplicaes; e por m, apresentam
menor tempo e custo de desenvolvimento porque, utilizando-o para ns mais amplos, a sua
codicao d-se apenas uma vez e no proporcional ao nmero de vezes em que o problema
surge.
Atravs das vantagens oferecidas pelo CBSD (Component-Based Software Development )
possvel identicar trs personagens principais: o desenvolvedor do componente, o montador e
o cliente ou usurio nal. De forma simples, o desenvolvedor aquele que cria o componente,
isto , o programador ou fabricante. O montador aquele que, conhecendo apenas as interfaces
do componente, utiliza-o para resolver algum problema de forma totalmente aplicvel, isto ,
usando-o diretamente. E por ltimo o cliente o que recebe uma aplicao nal construda
com componentes previamente selecionados e que atendam sua lista de requisitos. A gura 2.1
demonstra a atuao desses trs elementos que implementam o processo de desenvolvimento de
software desde a sua concepo at o seu uso pelo cliente nal.
Porm, como esses trs elementos atuam sob fases e graus de conhecimento distintos sobre
o processo de componentizao, acabam se submetendo a um grande risco que pode compro-
meter a eccia geral ou parcial de um sistema. O principal problema que pode ocorrer nessa
abordagem o efeito cascata[VIT 2003], isto , qualquer erro na fase de desenvolvimento do
componente, acarreta erros ou diculdades na fase de montagem no atendendo, dessa forma,
os desejos do cliente de forma satisfatria ou obrigando-o a se adequar ao sistema.
Um modelo parecido com o da gura 2.1 proposto por Mohamed Fayad et al., [FAY 2003].
Nele, a construo de um componente estvel ocorre em trs camadas. So elas: a EBTs (En-
during Business Themes), BOs (Business Objects) e a IOs (Industrial Objects). A camada EBT
representa as classes que implementam a lgica permanente de um componente, isto , o ncleo
21
Figura 2.1: Os trs personagens do processo de componentizao segundo Padmal Vitharana,
[VIT 2003]. a) pode-se observar que os componentes so fabricados para vrios ns sendo que,
no h uma relao explcita entre eles, isto , so concebidos para serem independentes. b) O
montador precisa encontrar e inter-relacionar os componentes a m de resolver o problema do
cliente. c) O produto de software nal pronto para ser utilizado.
da implementao. Os BOs so classes que se utilizam da lgica oferecida pelo EBT para im-
plementar mais objetos concretos. A camada mais externa IO aquela que mapeia os BOs em
objetos de aplicao, isto , que associa um determinado objeto ou conjunto deles para resolver
um problema real.
Dessa forma, o principal desao do desenvolvimento de software baseado em componentes
o de criar mecanismos para gerenciar a refatorao de cdigo que sempre ocorre quando
os requisitos do sistema se modicam de tal forma que sua manuteno seja simples e rpida
[BOO 1999]. Entre esses mecanismos cita-se o controle de verses, isto , CVS (Concurrent
Version System), identicao profunda do domnio do problema, testes de validao, avaliao
do grau de interoperabilidade entre os componentes, localizao de componentes adequados
durante o processo de montagem, checagem da procedncia do componente, avaliao de como
um sistema legado pode interagir com os componentes e qual o risco dessa operao entre
outros. Como o processo de refatorao enfatiza outros aspectos que no o processo de criao
de componentes adaptveis, ele foge do escopo desse trabalho.
Na seo 2.4, apresentado ainda a UML como uma importante ferramenta seja para tra-
balhar com padres de projeto ou componentes. Ela pode ser vista como o complemento nal
necessrio para a construo de software adaptvel uma vez que capaz de especicar todas as
etapas necessrias para a sua implementao.
2.4 Linguagem de Modelagem Unicada - UML
Para projetar os componentes de software para os problemas de processamento de imagens,
foi utilizada a Linguagem de Modelagem Unicada (UML). Atualmente ela a notao gr-
ca mais amplamente utilizada para a modelagem de sistemas orientados a objetos pois sua
linguagem visual e rica em recursos necessrios para formalizar, documentar e demonstrar a
22
criao, comportamento e estrutura dos objetos [DEI 2001], [ARM 2003], [ENG 2000]. Para
que isso ocorra h uma srie de convenes que so utilizadas para expressar a construo e
o relacionamento dessas entidades de software tornando-a assim uma linguagem padro onde
qualquer pessoa pode, facilmente, interpret-la e ento entender a complexidade que o sistema
apresenta. Esse estgio de alto nvel da modelagem mais conhecido como modelo estrutural
e sua principal caracterstica a denio das classes utilizadas e como essas se relacionam
entre si na soluo do problema. No caso de um componente de software, por exemplo, pode-se
ter um ou mais modelos estruturais dependendo da complexidade do sistema, isto , utiliza-
se uma hierarquia de componentes e sub-componentes que implementam modelos prprios a
m de modularizar a soluo de forma mais legvel. Dessa forma, a UML torna-se uma ferra-
menta essencial no apenas para documentar um sistema mas como tambm para desenvolver
sua soluo antes do processo de codicao.
A gura 2.2 utiliza a notao UML e a noo de componentizao para demonstrar como o
StoneAge foi projetado. O cone central representa o framework, isto , o software base imple-
mentado para abrigar vrios componentes que foram desenvolvidos para um determinado m.
Esse n central representado por uma estrutura do tipo pacote com o esteretipo intuitivo
sua funo, ou seja, um framework. Os componentes so representados pelos retngulos com
duas guias horizontais e possuem um relacionamento de dependncia com outra estrutura que
representa seu cdigo fonte gerador, isto , a classe de viso pblica que implementa toda a
complexidade do componente. J o cone do framework apresenta tambm um relacionamento
de dependncia porm em relao aos componentes executveis. Esta uma forma bastante
simplicada do esquema de desenvolvimento uma vez que, na prtica, um componente pode ser
formado por vrias classes e/ou interfaces. Assim, para ns organizacionais, todos os compo-
nentes presentes no StoneAge foram abrigados em sub-pacotes.
Figura 2.2: Esquema do sistema projetado para suportar a componentizao.
No captulo 3, descrito mais detalhadamente as caractersticas da UML e a programao
de software orientado por objetos como mecanismos para propiciar melhor qualidade tanto no
processo quanto no produto de software que est sendo desenvolvido.
23
3 A MELHORIA DA QUALIDADE DE PRODUTOS E
PROCESSOS NA ENGENHARIA DE SOFTWARE
A construo de um software de qualidade depende, principalmente, da sua conformidade
com as especicaes de seus requisitos [POP 2003]. Essas especicaes, comumente co-
nhecidas como engenharia de requisitos, ocorrem antes da fase de projeto e implementao
pois ela que vai formalizar o que se espera do artefato de software que ser desenvolvido.
Independente se um componente ou um framework
1
que se est querendo construir, essa
especicao que ir descrever as necessidades e os desejos que essas entidades devem possuir
e intuitivamente devem ser encontradas antes de qualquer passo posterior de desenvolvimento.
Segundo Craig Larman [LAR 2000], essa etapa pode ser dividida em cinco fases para ns orga-
nizacionais: a descrio global sobre o que se quer desenvolver, quem o cliente, quais so os
objetivos, quais as funes do sistema e por m quais os atributos desse sistema.
Tome-se como exemplo o desenvolvimento de uma classe para efetivar o realce de bordas
de imagens visando possivelmente uma segmentao, ou em outras palavras a implementao
de um componente para encontrar o gradiente de uma imagem. A primeira fase, consiste de
uma simples especicao dos objetivos gerais onde se esclarece a nalidade do sistema, o que
corresponde a fase de denir a interface do componente, ou seja, a entrada de uma imagem e a
obteno do resultante gradiente da mesma. A prxima fase reconhecer o cliente desse com-
ponente. Aqui a unidade especialista de software projetada para ser agregada a um framework.
Dessa forma sua construo deve implementar primitivas que permitam sua unio essa enti-
dade maior de software. Essas primitivas podem ser, por exemplo, caractersticas da linguagem
de programao utilizada, isto , se um framework foi projetado com determinada linguagem,
possivelmente, para ns de compatibilidade, o componente far uso da mesma ferramenta. Nos
objetivos, pode-se enfatizar o processo de realce de bordas de forma mais detalhada, isto , sob
qual tipo de semntica o algoritmo funcionar, isto , em imagens tons de cinza ou multiespec-
trais, qual algoritmo ser utilizado para otimizar esse processo, quais as vantagens dessa soluo
em relao aos outros algoritmos. J nas funes do sistema, especica-se como ele opera, em
relao s suas entradas, por exemplo, se o usurio pode escolher qual algoritmo de uma coleo
de outros vai ser aplicado na imagem ou se o sistema detectar isso automaticamente. Na ltima
1
software que agrega os componentes desenvolvidos.
24
fase, isto , na identicao dos atributos do sistema pode-se visualizar um componente com
interface grca para facilitar a sua utilizao por parte do usurio, outro atributo seria a sua
modularidade, isto , se caria mais legvel o separar em diversas classes entre outros.
Dessa forma, construir e renar um repositrio de requisitos um importante passo para
assegurar a construo de um software de qualidade. Porm, isso no garante que o produto
nal foi implementado da melhor forma possvel uma vez que, por motivos de pouca expe-
rincia, o cdigo fonte produzido pode carecer em simplicidade tornando-se muito extenso e
pouco lgico. Assim, ele pode sofrer refatorao vrias vezes durante seu ciclo de desenvolvi-
mento a m de tornar-se mais enxuto porm sem alterar sua funcionalidade original. Sua ope-
racionalidade original mantida porque a interface do componente respeitada, porm a sua
complexidade interna pode sofrer alteraes [FOW 1999]. Construir um cdigo limpo auxilia
na manuteno que ele vir a sofrer com as mudanas em suas especicaes funcionais em
decorrncia de alguma nova necessidade por parte do usurio.
3.1 Utilizando um Processo de Software
Atravs do que foi escrito at o momento pode-se perceber que o desenvolvimento de soft-
ware que almeja certas qualidades operacionais no uma tarefa trivial. Isso deve-se princi-
palmente ao fato de serem construes extremamente abstratas e, portanto, complexas. Peters
e Pedrycs [PET 2001] expressam bem esse problema: ...eles esto entre as construes hu-
manas contemporneas mais abstratas, pois no so regidos por nenhuma lei da fsica. Par-
ticularmente eles no envelhecem, no ocupam espao, no se desgastam e no apresentam
continuidade.
Nesse contexto faz-se necessrio utilizar uma metodologia que auxilie o seu desenvolvi-
mento desde o princpio, garantindo que o produto seja convel, ecaz, eciente e de f-
cil manuteno. A esse recurso utilizado d-se o nome de processo de software e seu obje-
tivo especicar mtodos e tcnicas a serem utilizados pelas pessoas, no caso projetistas e
programadores, a m de desenvolverem e manterem em algum tipo de artefato de software
[DON 2001]. Nesse estgio so utilizadas ferramentas de engenharia de software que foram
criadas e vem evoluindo h mais de 30 anos e sua funo prover mecanismos para anali-
sar e validar as trs fases principais do processo de desenvolvimento de software que so: a
anlise dos requisitos, a fase de projeto e a fase de implementao. A fase de requisitos a
mesma descrita no incio desse captulo, ou seja, visualiza o sistema como uma caixa-preta
se preocupando apenas com o que entrada ou sada de dados. A fase de projeto trata das
especicidades do sistema, isto , qual o algoritmo ser utilizado para prover a soluo exigida
pelos requisitos, qual a linguagem de programao, entre outros. J a fase de implementao
refere-se a gerao de cdigo-fonte, documentao e testes de validao. Para gerenciar es-
sas trs fases vrios modelos de ciclo de vida de software vem sendo estudados entre eles: o
modelo cascata, incremental, espiral, evolucionrio, de prototipao, orientado a objetos entre
outros [PET 2001]. Esses modelos so chamados de universais pois descrevem apenas as fases
25
bsicas do processo de desenvolvimento, o que os tornam bastante genricos e, portanto, pouco
precisos.
Mesmo assim faz-se necessrio escolher um deles porm com um auxlio adicional. Dessa
forma, o prximo passo necessrio escolher uma ferramenta que d suporte esse modelo
escolhido. No caso dessa pesquisa foi utilizado o modelo de programao orientado por objetos
associado com a ferramenta de modelagem grca UML para construir o StoneAge.
3.2 Programao Orientada por Objetos
Na perspectiva de programao por objetos, surgida na segunda metade da dcada de 70, o
desenvolvimento de um sistema centrado em uma entidade denominada classe, enquanto que a
viso tradicional enfatiza os algoritmos de forma seqencial. At aqui no h nenhumproblema,
pois ambas as formas conseguem resolver os problemas exigidos pelos requisitos dos usurios.
O problema que a abordagem de codicao estruturada de software, isto , aquela centrada
nos algoritmos com suas funes ou procedimentos, torna-se muito complexa quando o sistema
vai ganhado propores maiores o que, conseqentemente, torna sua manuteno muito difcil
[BOO 1999]. Esse problema fcil de enxergar mesmo que teoricamente pois se o algoritmo
a unidade que implementa toda a lgica de uma soluo e o processo de desenvolvimento atre-
lado a ele, logo todo o cdigo produzido ca dependente da complexidade que ele implementa.
J no modelo de objetos, comumente chamado de OOP (Object-Oriented Programming)
consegue-se ocultar a complexidade de alguma soluo e manipul-la de forma mais exvel,
ou seja, com a possibilidade de criao de vrias instncias de classes, com a utilizao das
vantagens do encapsulamento, e com o reuso mais efetivo de objetos para resolver problemas
especcos em outros contextos [PET 2001]. Com essa modelagem outra caracterstica muito
desejvel e importante em um sistema alcanada, isto , a legibilidade. A legibilidade con-
seguida porque o desenvolvedor/programador pode organizar seu cdigo fonte em classes, que
nada mais so que objetos em tempo de codicao, a corresponderem ao problema que se est
sendo analisado [COA 1993]. Por exemplo, na construo de um componente que realiza a
operao de equalizao em uma imagem o programador pode criar uma srie de classes que
resolvem vrias etapas desse processo isoladamente. Por exemplo, o primeiro passo adquirir a
imagem, ento uma classe dever ser criada para permitir o acesso a matriz de pixels de determi-
nado arquivo grco. Aps isso outra classe deve ser desenvolvida para computar o histograma
dessa imagem uma vez que a equalizao uma operao baseada no histograma. O prximo
passo computar, na mesma classe, o histograma normalizado e acumulado encontrando assim
a funo de transferncia que ir reetir a nova distribuio das intensidades dos pixels na ima-
gem [SAN 1995]. Essas ltimas operaes so implementadas na mesma classe porque no so
complexas e dispensam qualquer modularidade. Por m deve-se criar uma classe para exibir a
imagem na tela atravs de uma janela. A gura 3.1 demonstra esse processo.
Os trs retngulos dessa gura representam as classes utilizadas para resolver o problema,
26
Figura 3.1: Uso do diagrama de classes para o problema da equalizao de imagens
sendo que, cada uma delas representada por um arquivo com extenso class
2
. Os mtodos
e atributos de cada classe foram abstrados por motivos de simplicao. Outra notao im-
portante e muito til presente na gura 3.1 o retngulo com a borda superior direita dobrada.
Esse o cone de uma nota, ou um note e muito utilizado para explicar visualmente algum
processo ou entidade. Ele pode ser visto como uma documentao visual resumida do dia-
grama. Assim, para o funcionamento ecaz do programa a classe implementada pelo arquivo
OpenImage.class necessita do arquivo grco que ir conter a imagem
3
a ser equalizada.
Aps isso a classe representada pelo arquivo EqualizeImage.class far todo o processa-
mento que ir efetivar a operao de equalizao. Aps isso a classe DisplayImage ir exibir
essa imagem no monitor atravs dos componentes de interface grca nativos da linguagem
Java. Essas classes apresentam-se sob uma relao de dependncia. Por exemplo, a classe
DisplayImage depende da classe EqualizeImage para funcionar corretamente. Essa re-
lao de dependncia ocorre atravs da conveno grca de uma linha tracejada com uma seta
aberta em uma das extremidades.
Essa operao de equalizao muito importante para facilitar a visualizao de uma ima-
gem. Comparando a imagem original com a ps-processada pode-se notar que essa ltima est
mais ntida pois suas bordas foram realadas por esse processo de distribuio mais uniforme da
luminosidade, que o objetivo da equalizao. Atravs da equalizao, por exemplo, pode-se
avaliar melhor visualmente o resultado de uma segmentao
4
.
2
Arquivo com essa extenso representa o programa executvel que interpretado pela mquina virtual Java.
3
A imagem utilizada nesse exemplo parte integrante do toolbox de processamento de imagens do MatLab -
(http://www.mathworks.com/) c 1994-2004 The MathWorks, Inc.
4
O uso de algoritmos de segmentao foi abordado em trabalho publicado no XXIV Encontro Nacional de
Engenharia de Produo, [WEL 2004] e no X International Conference on Industrial Engineering Management,
[DOR 2004].
27
3.3 A Ferramenta de Modelagem Unicada para Projetar Software no
Modelo de Objetos
A UML foi desenvolvida logo aps as primeiras linguagens de programao orientada por
objetos como um meio para analisar e projetar os novos sistemas de software centrados nesse
novo paradigma [BOO 1999]. Criada por Grady Booch, Ivar Jacobson e James Rumbaugh
em 1995, com a denominao de mtodo unicado, foi aperfeioada e tornou -se a linguagem
padro de modelagem
5
da indstria de desenvolvimento de software [KOB 1999].
Essa ferramenta possui diversas notaes grcas capaz de atender as vrias construes
propiciadas por uma linguagem orientada por objetos. Sua operacionalidade pode ser dividida
em quatro categorias: estrutural, comportamental, de agrupamento e de anotao. A seguir
apresentado uma descrio sobre cada grupo:
o grupo estrutural da UML abriga, principalmente, as notaes de diagrama de classes,
objetos, componentes, interfaces e os seus relacionamentos. Por exemplo, as guras 2.2
e 3.1 utilizam- -se respectivamente dos diagramas de componentes e de classes para de-
monstrar exemplos concretos do projeto de software em diferentes nveis de complexi-
dade.
o grupo comportamental modela as caractersticas dinmicas de um sistema, ou seja, os
passos que ele realiza para resolver algum problema no decorrer do tempo. So represen-
tantes dessa categoria o diagrama de atividades, de estados, de casos de uso, de colabo-
rao e de seqncias. A gura 3.2 mostra o uso do diagrama de atividades para projetar
e documentar o uxo de informaes manipuladas para distribuir mais uniformemente a
luminosidade em uma imagem.
na terceira categoria, isto , no agrupamento cita-se o diagrama de pacotes que pode
abrigar em seu interior outros pacotes ou estruturas a m de criar uma hierarquia para ns
organizacionais.
O anotacional apenas existe para fornecer informao visual sobre algum processo ou es-
quema. Por exemplo, a gura 3.1 utiliza duas dessas estruturas para explicar visualmente
o que est acontecendo ou como o sistema foi modelado, isto , ele pode servir como uma
espcie de lembrete para o desenvolvedor.
A UML no serve apenas para projetar um sistema de software, ela serve tambm, para
document-lo. Dessa forma a tradicional documentao de cdigo via estrutura de comentrios
ganha um grande aliado uma vez que, a UML, visual e assim consegue-se enxergar e entender
os relacionamentos que as vrias entidades de software podem implementar entre si. Esse pro-
cesso ameniza a complexidade do sistema, o que por sua vez facilita a manuteno do mesmo.
5
A UML padronizada e mantida pela OMG - Object Management Group. (http://www.omg.org)
28
Figura 3.2: A operao de equalizao demonstrada via diagrama de atividades. a ) exibe o
processo de equalizao mais genrico se preocupando apenas com a entrada e sada de in-
formaes. b ) Explode o processo de equalizao original permitindo assim visualizar a
seqncia lgica exigida pelo algoritmo. Em ambas ilustraes o crculo preto representa o
incio do processo e o crculo circunscrito em outro o seu trmino.
Alm disso, ela permite renar o processo de concepo do sistema por qualquer desenvolvedor
atravs de suas notaes grcas padro.
Portanto, um modelo de programao associado com uma linguagem grca de modelagem
tende a produzir um software de qualidade, uma vez que, em seu processo de projeto deve-se
conseguir tratar o maior nmero possvel de excees evitando assim a futura refatorao de
cdigo o que signica economia de tempo e dinheiro.
No prximo captulo, apresentado as principais caractersticas do processo de desenvolvi-
mento de software no domnio do processamento e anlise de imagens. Essa etapa funda-
mental para posteriormente identicar e aplicar os padres de construo na implementao do
StoneAge. Assim, essencial para a correta construo de cdigo adaptvel entender tanto o
domnio da aplicao quanto dos conceitos de engenharia de software.
29
4 DESENVOLVIMENTO DE SOFTWARE NO DOMNIO DE
PROCESSAMENTO DE IMAGENS
A computao voltada para imagens existe h mais de trinta anos. No comeo, ela se res-
tringia aos grandes centros e laboratrios de pesquisa devido aos caros recursos computacionais
que eram empregados[SHA 2000]. Segundo Gonzalez e Woods [GON 2000], o processamento
de imagens comeou a ganhar importncia em 1964 quando o Laboratrio de Propulso a Jato
do Centro de Tecnologia de Pasadena, na Califrnia, utilizou um computador de grande porte
associado a tcnicas de processamento para realizar o melhoramento de imagens da Lua que
foram transmitidas pela sonda Ranger 7.
Porm, com a evoluo do hardware no que diz respeito ao aumento de poder de processa-
mento, reduo dos custos de memria, advento das linguagens de programao de alto nvel,
aumento da capacidade dos dispositivos de armazenamento aliados a existncia de sistemas ope-
racionais voltados para usurios no especialistas, a computao voltada para imagens tornou-se
acessvel a quase todos. Dessa forma, o desenvolvimento de software para processamento de
imagens chegou ao alcance de qualquer pessoas dotada de um simples computador de mesa
ou at mesmo porttil tornando-se assim, um tema muito atrativo e til para pesquisadores das
mais diferentes reas do conhecimento. Para Gonzalez e Woods [GON 2000] aplicaes que
envolvem imagens podem ser encontradas em astronomia, biologia, defesa, medicina, apoio a
lei, arqueologia, fsica, geograa, em aplicaes industriais, geologia, engenharia e cincia dos
materiais.
No entanto, apesar do fcil acesso aos recursos computacionais atuais necessrios para a pro-
gramao de software para resolver problemas de imagens, deve haver um certo cuidado quanto
ao seu projeto, isto , na forma como ser implementado. Normalmente, o desenvolvimento
de grandes sistemas de software, o que muito caracterstico no desenvolvimento voltado para
imagens, ocorre em camadas [VL 2002]. Dentre essas, as mais utilizadas so: a camada cen-
tral ou ncleo, a camada de aplicao e a de apresentao. O principal objetivo dessas camadas
tornar o software exvel em relao as suas funcionalidades, isto , decomp-lo em blocos
de funes similares no seu nvel de abstrao [BUS 1996]. Como por exemplo pode-se citar
a ltima camada que tem a funo de interagir com o usurio e, cujo objetivo, se preocupar
apenas em propiciar uma entrada e sada de informaes que torne o sistema fcil de usar. A
gura 4.1 apresenta um esquema organizacional baseado na idia de camadas.
30
Figura 4.1: Desenvolvimento de software em camadas.
Na gura 4.1 o ncleo representado pela interface de programao para imagens chamada
JAI (Java Advanced Imaging). Essa camada central responsvel pelos algoritmos essenciais
na rea de processamento de imagens. Em sua volta encontra-se a camada de aplicao onde,
utiliza-se uma srie de operadores providos pelo ncleo para resolver determinados problemas
de manipulao de imagens. Nessa gura, a ttulo ilustrativo, so citadas aplicaes de morfolo-
gia, abertura de arquivos grcos, segmentao e uma aplicao para linearizar um histograma,
isto , a operao de equalizao. A ltima camada a de interface com o usurio e comumente
chamada de camada GUI (Graphics User Interface). Essa camada de fundamental importn-
cia pois atravs dela que o usurio ser capaz de utilizar o sistema. Dessa forma, uma camada
de interface grca bem projetada pode diminuir o grau de complexidade necessria para operar
um sistema.
4.1 A Camada Central
A camada central ou ncleo responsvel pela implementao de um conjunto de funciona-
lidades bsicas para processamento de imagens. Enquadram-se nessas funcionalidades opera-
dores pontuais, de rea, geomtricos, de manipulao de arquivos grcos, de realce de bordas,
de quantizao, de regio de interesse e operaes morfolgicas. Todas essas implementaes
so utilizadas em diferentes situaes como especicado a seguir:
no momento de extrair alguma informao de determinado arquivo grco. Com os in-
meros formatos atualmente existentes muito til que a camada central se preocupe em
decodicar pelo menos os tipos mais conhecidos como, por exemplo, JPEG, BMP, TIFF,
PNG, PGM e GIF. Esse processo tambm crucial uma vez que, quase todo o proces-
samento ou anlise de imagens necessita de matrizes bidimensionais que representam os
31
pixels da imagem e que, por sua vez, so as principais informaes presentes nos arquivos
grcos mais comumente usados em laboratrio.
no momento de realar uma imagem, o que pode ser realizado em dois domnios bsi-
cos: O domnio espacial e o domnio da freqncia. No domnio espacial pode-se citar
os ltros ou mscaras de convoluo utilizados para amenizar o efeito do rudo em ima-
gens, realar detalhes em imagens borradas e outros. Ele dito espacial pois opera sob o
prprio plano da imagem, isto , diretamente sob seus pixels [GON 2000]. A gura 4.2
ilustra a aplicao de uma mscara. J o domnio da freqncia baseia-se na transformada
de Fourier da imagem, isto , na taxa de transio que o brilho apresenta em uma imagem
[GON 2000].
Figura 4.2: a) Mscara 3 x 3 hipottica. b)Imagem original tons de cinza.
A mscara da gura 4.2 tambm dita oito-conectada ou N
8
porque utiliza oito pixels
vizinhos em relao ao seu centro. O pixel central da mscara, que tambm pode ser
vista como uma imagem, computado para todos os pixels da imagem original mais a
sua vizinhana local. Por exemplo, para encontrarmos o valor dos pixels resultantes da
convoluo da mscara 3 x 3 sobre uma imagem hipottica representada na gura 4.2
deve-se multiplicar cada valor do pixel da mscara por cada valor do pixel da imagem
original e por m efetuar a soma. Como esses novos pixels podem exceder o intervalo
de intensidades que se est sendo representado eles podem sofrer uma normalizao de
acordo com o peso da mscara [SHA 2000]. Segundo Gonzalez e Woods [GON 2000], as
tcnica espaciais so muito mais freqentemente usadas do que as tcnicas baseadas no
domnio da freqncia pela sua fcil implementao e performance computacional.
nas operaes geomtricas da imagem como a rotao, translao, shear, escala e outros.
no processo de anlise de imagens atravs da deteco de arestas, gerao de histograma,
32
encontro do mximo e nmo valor de uma imagem.
no armazenamento de novas imagens em arquivos. Esse processo de extrema importn-
cia uma vez que atravs dele possvel ter uma sada para o processamento realizado
mantendo assim a imagem original inalterada. Para isso, o ncleo deve ser capaz de codi-
car os algoritmos usados pelos principais formatos grcos permitindo assim, anexar a
matriz de pixel resultante de alguma operao realizada em um novo e vlido arquivo de
imagens.
no acesso aos pixels de uma imagem o ncleo deve implementar formas para que isso
ocorra de forma simples e rpida. Para isso vrios tipos de iteradores
1
devem ser imple-
mentados permitindo que, a matriz de pixel seja percorrida de diferentes formas visando
assim, uma melhor performance de processamento. A gura 4.3 demonstra dois exemplos
desses iteradores e como eles funcionam.
Figura 4.3: a) Conhecido como RectIter e percorre os pixels no sentido de cima para baixo
obedecendo a ordem da esquerda para direita. b)Conhecido como RookIter e permite uma
navegao arbitrria no que diz respeito a ordem. Nesse exemplo seguido o sentido de cima
para baixo porm a ordem varia entre esquerda e direita e da direita para a esquerda.
Esse ncleo geralmente implementado atravs de bibliotecas de programao. Porm,
muitas delas so especialistas,isto , atendem apenas funcionalidades especcas [Sun 1999].
Um bom exemplo a biblioteca Mmorph
2
que contm o estado da arte no que se refere a ope-
radores morfolgicos [DOR 2001]. No entanto, essa biblioteca alm de apenas se preocupar
com os aspectos relativos morfologia das imagens seja ela cinza, binria ou colorida, ela s
funciona agregada em um outro software chamado MATLAB. Esse sistema que a abreviatura
para MATrix LABoratory manipula essa biblioteca para ns de interao como usurio alm de,
1
mecanismo que propicia o percorrimento dos pixels de uma imagem atravs de diferentes maneiras.
2
Essa biblioteca pode ser obtida em http://www.mmorph.com com licena para trinta dias.
33
agregar novas funes. O MATLAB
3
nada mais que um software que agrega vrias bibliote-
cas especializadas como a de processamento de imagens, de morfologia, de otimizao linear,
anlise nanceira, lgica fuzzy, equaes diferenciais parciais, estatstica, e outros.
Nessa dissertao foi utilizada a interface de programao para imagens denominada JAI
que, atualmente, est na verso 1.1.2. Essa API (Application Programming Interface), como
comumente chamada, a biblioteca central sobre a qual a maioria das operaes com ima-
gens foram desenvolvidas. Essa API foi desenvolvida pela Sun Microsystems
4
em conjunto
com outras grandes empresas como a Siemens Corporate Research, Eastman Kodak e Autome-
tric visando, principalmente, atender as necessidades da rea mdica, geoespacial, comercial,
governamental e da internet [Sun 2004]. A seguir so abordados alguns aspectos dessas neces-
sidades.
Na rea mdica essa biblioteca permite a construo de aplicativos capazes de auxiliar no
diagnstico mdico por imagens atravs de processamentos como: segmentao, deter-
minao de regies de interesse, equalizao, ltros anti-rudos ou/e de desborramento,
aumento escalar da imagem entre outros. Algumas dessas formas de processamento so
utilizadas para o processo de quanticao de imagens, ou seja, para conseguir extrair
determinadas informaes teis para o prossional da sade que depende da imagem para
uma avaliao mais criteriosa sobre determinada doena;
No mbito geoespacial como destaca [Sun 2004], essa API pode ser utilizada para ma-
nipular grandes imagens obtidas via satlite obtendo assim informaes pertinentes, por
exemplo, do estado climtico de determinadas regies, seu comportamento atual, sua pre-
viso, seus recursos naturais entre outras. Esses sistemas so conhecidos como SIGs, isto
, Sistemas de Informaes Geogrcas;
Quanto s necessidades governamentais poder-se-ia citar tambm, o uso de imagens obti-
das via satlite para analisar o prejuzo que um tornado ou um terremoto causou ou
causaria em algum lugar, para analisar se determinada lavoura foi cultivada ou no, entre
outros. Um exemplo atual a utilizao da API JAI em conjunto com outra API chamada
Java 3D pela Agncia Espacial Norte-Americana - NASA. Os cientistas da NASA usaram
essas bibliotecas Java para controlar as sondas Spirit e Opportunity na misso de explo-
rar o planeta Marte. O software construdo para isso foi chamado de MAESTRO
5
e seu
objetivo era criar um mundo tridimensional baseado nas imagens captadas por essas son-
das ao mesmo tempo que, permitia a manipulao mecnica desses robs exploradores
[GOS 2004].
No domnio comercial, atualmente com a existncia de dispositivos de aquisio de ima-
gens mais acessveis a populao em geral, como por exemplo, as cmeras digitais e scan-
3
Maiores informaes sobre esse sistema, que uma verdadeira linguagem para computao tcnica, podem
ser obtidas em http://www.mathworks.com.
4
c 2000 Sun Microsystems, Inc. (http://www.sun.com)
5
Esse sistema pode ser baixado livremente mediante cadastro em (http://mars.telascience.org/)
34
ners de mesa, a ateno dada para a criao de novos softwares que manipulam imagens
evidente. Dessa forma, para no reimplementar uma srie de funcionalidades bsicas
o uso dessa API pode ser visto como uma alternativa lgica para otimizar o processo de
desenvolvimento de software.
As demandas referentes Internet referem-se a capacidade que essa biblioteca, baseada na
linguagem Java, possu para manipular imagens remotamente atravs do modelo cliente-
servidor. Na realidade essa vantagem adicional conseqncia da linguagem Java que j
permitia a construo de aplicaes baseada em objetos remotos atravs de RMI
6
(Remote
Method Invocation) [DEI 2001].
Alm da vantagem de possibilitar a implementao de objetos distribudos de imagens, a
API JAI multiplataforma. Isso ocorre porque ela foi escrita em Java, e, conseqentemente a
idia de escrever uma vez e executar emqualquer lugar vlida [Sun 1999]. Claro que essa in-
dependncia de plataforma relativa, isto , ela funciona em qualquer sistema operacional desde
que haja uma mquina virtual apropriada instalada para que a mesma seja interpretada. Outra ca-
racterstica muito positiva que essa biblioteca herdou da linguagemJava diz respeito a metodolo-
gia utilizada para sua construo. Essa API foi escrita com o paradigma orientado por objetos,
apresentando-se dessa forma uma organizao baseada em classes e mtodos. Essa uma ca-
racterstica positiva, pois facilita o reuso, legibilidade e a modularidade do cdigo fonte. Em
nvel de implementao, por exemplo, se quisermos utilizar a JAI para manipular umhistograma
apenas importamos a classe Histogram pertencente ao pacote javax.media.jai. Dessa
forma tem-se acesso a todos os atributos e servios (mtodos) providos por essa classe relativo
ao histograma de uma imagem de entrada.
Como foi dito no incio desse captulo, a camada central oferece uma srie de operaes bsi-
cas para a implementao de software para processamento de imagens. Nesse contexto pode-se
identicar nove categorias de operadores implementados pela biblioteca JAI, so eles: Operado-
res pontuais, operadores de rea, operadores geomtricos, de cor, de arquivo, de freqncia, de
estatstica, de extrao de bordas e operadores gerais [AKR 2003]. E justamente essa gama de
funcionalidades que a difere das bibliotecas especialistas como a Mmorph anteriormente citada.
A seguir so apresentados os principais operadores segundo as categorias mais usuais dentre
as nove anteriormente citadas. Todos esses operadores sero mostrados, para melhor organiza-
o, em tabelas como a 3.1. A primeira coluna dessas tabelas especica o nome do operador
que, intuitivamente ser passado como parmetro posteriormente, isto , na hora de programar.
A segunda coluna d a funcionalidade desse operador, isto , o que ser feito a partir de uma
ou duas imagens de entrada. E, por m, se existir, a terceira coluna mostra como esse operador
deve ser utilizado durante o processo de codicao atravs de uma forma adequada, isto , sem
erros em tempo de compilao ou execuo.
6
O uso de objetos distribudos via RMI aplicado a imagens foi descrito em trabalho publicado no XXIII En-
contro Nacional de Engenharia de Produo e IX International Conference on Industrial Engineering Management.
[WEL 2003]
35
Os operadores pontuais atuam apenas sob os atributos de cada pixel da imagem, isto ,
os pixels da nova imagem dependem somente da intensidade isolada da cada pixel da
imagem de entrada. A JAI implementa quatro dezenas de operadores pontuais. A tabela
4.1 demonstra alguns desses operadores.
Operador Funo Estrutura Bsica
Add Realiza a operao de adio de duas
imagens.
dst = JAI.create("Add", pb,
null);.
And Realiza a operao de AND lgico en-
tre duas imagens .
dst = JAI.create("And", pb,
null);.
BandCombine Usado para manipular as bandas de
uma imagem.
dst =
JAI.create("BandCombine",
pb, null);.
Threshold Computa o limiar de uma imagem. dst = JAI.create("Threshold", pb,
null);.
Invert Inverte os valores dos pixels da ima-
gem.
dst = JAI.create("Invert", pb,
null);.
Subtract Subtrai os pixels de duas imagens. dst = JAI.create("Subtract", pb,
null);.
Tabela 4.1: Alguns operadores pontuais presentes na JAI.
Os operadores de rea podem ser utilizados para implementar as mscaras anteriormente
citadas, para localizar as coordenadas espaciais de uma sub-imagem, para adicionar borda
ao redor de uma imagem, para implementar ltros de medianas capazes de suavizar uma
imagem entre outros. A JAI implementa quatro desses operadores que podem ser conferi-
dos na tabela 4.2.
Operador Funo
Border Adiciona bordas ao redor da imagem.
BoxFilter Determina a intensidade de um pixel de acordo com a mdia dos pixels
pertencentes a uma determinada rea retangular da imagem fonte.
Convolve Implementa a operao espacial entre mscara e imagem. ele que
utilizado para implementar a operao representada pela gura 4.2
Crop Recorta uma rea retangular da imagem.
MedianFilter Filtro de mediana utilizado para remover linhas ou pixels isolados.
Tabela 4.2: Operadores de rea implementados pela JAI.
H tambm a categoria dos operadores geomtricos que modicam a orientao, forma
e tamanho de uma imagem. Na tabela 4.3 possvel ver alguns desses operadores exis-
tentes.
Outra importante categoria a de manipulao de arquivos grcos. Essa categoria
essencial porque permite o acesso a informao referente a matriz de pixel da imagem.
Essa manipulao pode ser de escrita ou apenas leitura conforme mostrado na tabela 4.4.
36
Operador Funo
Afne Altera a distncia e o ngulo entre as linhas de uma imagem.
Rotate Rotaciona a imagem
Scale Aumenta ou diminui o tamanho da imagem.
Translate Translada a imagem para um outro local do plano
Transpose Combina a operao de ip com a de rotao;
Tabela 4.3: Operadores Geomtricos: manipulam a forma, tamanho e orientao da imagem.
Operador Funo
BMP Codica e decodica arquivos com extenso .BMP
FileLoad L a imagem de um arquivo grco
FileStore Grava uma imagem em um determinado tipo de arquivo grco.
GIF L uma imagem de arquivo com extenso .GIF
JPEG Abre uma imagem que est dentro de um arquivo com extenso .JPEG
PNG Interpreta os arquivos com extenso .PNG
PNM L os arquivos do padro PNM e tambm seus similares PBM, PGM e
PPM
TIFF L os arquivos com extenso .TIFF
URL Interpreta uma imagem especicada por um endereo web
Tabela 4.4: Operadores de arquivo: essenciais para iniciar qualquer processamento e/ou ar-
mazenar os resultados do mesmo.
H outras categorias que contm muitos outros operadores como o de freqncia e quan-
tizao de cores. Assim, na tabela 4.5, ainda mostrado outros operadores que foram
muito utilizados nesse trabalho.
Operador Funo Categoria
GradientMagnitude Reala as bordas de uma imagem
baseado em duas direes ortogonais,
isto , com uma mscara vertical e de-
pois horizontal
Extrao de bordas
Histogram Computa o histograma de uma ima-
gem, isto , a distribuio das intensi-
dades dos pixels dessa imagem
Estatstico
Tabela 4.5: Outros operadores muito usuais.
No entanto, faz-se necessrio ainda entender como relacionar esses operadores com as ima-
gens de entrada e sada sob a tica da construo do cdigo-fonte. Para isso, deve-se saber
que:
1. Um objeto esttico PlanarImage da classe javax.media.jai.PlanarImage
carrega a matriz de pixel de determinada imagem previamente aberta ou processada. Esse
objeto pode ser encontrado, por exemplo, na tabela 3.1 sob o nome de dst, signicando
37
imagem de destino, isto , aquele objeto que ter a matriz de pixel resultante de determi-
nada operao;
2. Necessita-se de um objeto no esttico denominado ParameterBlock provido pela
classe java.awt.image.renderable.ParameterBlock. Esta uma classe que
no pertence ao pacote nativo da JAI, porm ela totalmente compatvel e conveniente
para manipular operadores da JAI. Ela vem do pacote awt e muito til porque permite
abrigar diferentes informaes que formam um nico bloco de dados e que, posterior-
mente, sero associadas com o operador utilizado. Essas informaes podem ser uma
matriz alusiva a uma mscara de convoluo e/ou a prpria imagem. Na tabela 4.1 esse
objeto representado pelo parmetro pb da terceira coluna do mtodo JAI.create().
3. E por m, faz-se necessrio um objeto esttico que representa o ncleo do processa-
mento com operadores chamado JAI e do seu mtodo create providos pela classe me
javax.media.jai.JAI. Ele o mais importante porque nele que sero passados os
parme-tros de operao e dados de entrada providos pela classe ParameterBlock. A
gura 3.4 ilustra a utilizao precisa dessas trs entidades de software, isto , a imagem,
a operao, e o bloco de informaes.
Figura 4.4: Esquema para o uso dos operadores JAI.
Atravs da descrio desses trs passos bsicos, mas, essenciais para a manipulao de ope-
radores com a biblioteca JAI pode-se concluir tambm que, a construo de software em trs
camadas necessita de outros pacotes Java. Como especicado no item dois anterior o objeto
ParameterBlock no pertence ao JAI mas sim, ao pacote awt (Abstract Window Toolkit).
Isso tambm ocorre na implementao da ltima camada ou camada de interface grca onde
utiliza-se pacotes como o javax.swing para ns de reuso de componentes grcos como
janelas, caixas de dilogo, botes, barras de rolagem, menus, campos de entrada de dados entre
outros.
Entretanto, essa biblioteca no permite apenas utilizar essa ampla gama de operadores para
construir aplicaes completas, mas como tambm permite criar outros novos operadores. Isso
38
muito positivo em se tratando de codicao pois permite encapsular a complexidade presente
em um ou vrios componentes e que, por sua vez, podem apresentar-se sob inmeras classes
e arquivos. Dessa forma com uma chamada apenas do objeto esttico JAI.create(), que
utiliza apenas uma linha de cdigo, possvel resolver problemas de processamento de imagens
de forma muito simples e rpida. Por exemplo, para o problema da equalizao de imagens
mostrado pela gura 3.1 possvel criar um operador chamado "Equalize para resumir toda a
manipulao desse processamento. Esse procedimento foi criado com xito e sua chamada nal
cou na forma JAI.create("Equalize,pb ,null), onde o objeto pb representa o
bloco de informaes que carrega a matriz de pixels da imagem a ser equalizada.
4.2 A Camada de Aplicao
A camada de aplicao, representada pela camada intermediria da gura 4.1, consiste nos
componentes de software responsveis por resolver diversos problemas envolvendo imagens.
Porm, esses componentes se utilizam das funcionalidades implementadas pelo ncleo para
resolver algum problema mais amplo. Por exemplo, para binarizar uma imagem, utiliza-se
operadores do ncleo para decodicar o formato do arquivo grco que contm a imagem, para
transform-la em tons de cinza caso seja necessrio, para implementar o limiar propriamente
dito e, por m, salvar as mudanas em um novo arquivo grco. Os componentes de aplicao
podem ser interpretados como os objetos que compilam e agregam diversas operacionalidades
da camada bsica representada nesse trabalho pela JAI.
Essa camada, usualmente referenciada como a camada da lgica de negcio [VL 2002],
a responsvel por abrigar implementao de diversos algoritmos para imagens na forma de com-
ponentes de classes. Esses componentes interrelacionam-se entre si objetivando resolver sempre
um problema maior a partir de pequenos artefatos de software. Essa a fase de montagem e
seu processo assemelha-se a manipulao dos blocos do kit Lego porm de uma forma muito
mais difcil [CRN 2002]. Componentes de software so mais complexos que o Lego pois devem
se preocupar tambm em como interagir com outros componentes cuja nica operacionalidade
conhecida sua interface, isto , como montar componentes que foram desenvolvidos sob aspec-
tos distintos como uma linguagem diferente ou para um sistema ou problema especco. Com o
Lego isso no ocorre pois todos suas peas so rapidamente e perfeitamente compatveis entre
si. Segundo CrnKovic e Larsson [CRN 2002], programar baseado em componentes como ter
uma banheira com diferentes kits de brinquedos como Lego, Thinkertoy, Erector, Block City e
outros sendo que deve-se integrar todas as peas proveniente de cada um a m de montar um
nico brinquedo. Seguindo esse raciocnio baseado na necessidade de interoperabilidade entre
componentes obteve-se nesse trabalho um certo grau de facilidade uma vez que, todos os com-
ponentes foram criados utilizando a mesma linguagem, tcnica e metodologia de programao.
Alm disso, o framework que os suporta tambm foi concebido nos mesmos moldes, isto ,
foi arquiteturado utilizando a linguagem Java que exige um estilo de programao orientada por
objetos e, que por sua vez, foi racionalmente otimizada atravs do uso de padres de construo.
39
Isso garantiu desde o incio gerenciar a complexidade do software medida que ele ia crescendo
permitindo que os padres de desenvolvimento fossem rapidamente visualizados e incrementa-
dos a nvel de implementao de solues. Porm, se em algum estgio de desenvolvimento fu-
turo houver a necessidade de interoperar componentes de origens distintas pode-se executar essa
ao utilizando componentes de comunicao habitualmente denominados de middlewares
como CORBA (Common Object Request Broker Architecture), Microsoft OLE (Object Linking
and Embedding)e COM (Component Object Model)[BUS 1996] e [CAI 2000].
A gura 4.5 mostra o cdigo de um componente completo que transforma uma imagem
colorida para tons de cinza. Para isso utilizou-se de uma srie de primitivas proporcionadas pela
JAI para montar a lgica necessria para resolver esse problema especco.
Cdigo 1: Mtodo construtor do componente para converter a imagem em tons de cinza.
01. public RGBtoGRAY()
02. {
03. //Define o nome do arquivo a ser processado
04. String path="Angio.jpg";
05. //Guarda a matriz de pixel da imagem no objeto chamado src
06. PlanarImage src = JAI.create("fileload", path);
07. //Matriz que guarda a equao de luminncia
08. double[][] matrix = {
09. { 0.114, 0.587, 0.299, 0 }
10. };
12. //Bloco de informaes da imagem e da equao
13. ParameterBlock pb = new ParameterBlock();
14. pb.addSource(src);
15. pb.add(matrix);
16. //Realiza a operao de converso
17. PlanarImage dst = JAI.create("BandCombine", pb, null);
18. //Grava as informaes em novo arquivo grfico
19. JAI.create("filestore",dst,"AngioCinza.jpg");
20. }
Figura 4.5: Implementao da lgica central do componente de converso para tons de cinza.
Na gura 4.5 consegue-se visualizar na prtica
7
, o que foi demonstrado na gura 4.4 isto
, o esquema proposto para a utilizao de operadores da biblioteca JAI. Para isso foi utilizado
o mesmo esquema composto da imagem, do bloco de informaes e da operao. No caso da
gura 4.5 no lugar da mscara de convoluo, foi utilizada a equao de luminncia. Na linha
6 dessa gura obtm-se a imagem de entrada, na linha 8 construdo a equao de luminncia,
nas linhas 13 a 15 constri-se o bloco de informaes atravs do objeto ParameterBlok, na
7
Um bom recurso para programao com JAI a lista de discusso mantida ocialmente pela Sun em (http:
//archives.java.sun.com/cgi-bin/wa?A0=jai-interest).
40
linha 17 efetiva-se a operao de converso para tons de cinza e por m, na linha 19 um novo
arquivo grco gerado contendo a imagem recm processada. O resultado dessa operao
pode ser visto na gura 4.6. Nessa gura demonstrado o processo de angiognese em clulas
cancergenas. Esse processo caracterizado pela formao de novos vasos sangneos cuja
funo prover a nutrio para essas clulas que esto em proliferao.
Figura 4.6: a )Imagem original colorida. b )Imagem em tons de cinza.
Muitos outros componentes foram desenvolvidos para incrementar a operacionalidade dessa
camada. Por exemplo, o componente de equalizao automtica descrito no captulo 3 mais
especicadamente pela gura 3.2, o componente de visualizao de histograma e suas infor-
maes, componentes para morfologia
8
e segmentao por watersheds
9
e componentes de in-
terface grca
10
que fazem parte da camada a ser abordada na prxima seo. No entanto, cabe
ressaltar que, apesar de se ter construdos componentes para certos problemas de processamento
de imagens, o principal enfoque dado a esse trabalho o da construo de um mecanismo capaz
de gerenciar a complexidade provida pelo framework que ir agregar todos esses componentes.
nesse contexto que entraram os padres arquiteturais e de projeto que sero abordados no
prximo captulo.
A gura 4.7 demonstra, ainda, outro componente desenvolvido, que a biblioteca JAI no
disponibiliza e que de essencial importncia para a parte de anlise de imagens, isto , umcom-
ponente para a visualizao de histograma. Esse componente utiliza duas classes para resolver
esse problema. A primeira manipula a entrada da imagem e a segunda tem como responsabili-
dade mostrar na tela o histograma recebendo como parmetro apenas o objeto PlanarImage
(que carrega a matriz de pixel). Dessa forma, toda a complexidade exigida principalmente pelas
primitivas de exibio grcas do java, como o objeto Graphics2Dque ir exibir o histograma
na tela, encapsulada dentro de seu mtodo construtor. Porm, esse componente, no demons-
tra apenas o grco da distribuio dos pixels em relao as suas intensidades mas tambm
8
Construdo pela acadmica do curso de Cincia da Computao Mnica Marcuzzo.
9
Desenvolvido pela acadmica do curso de Cincia da Computao Grasiela Peccini.
10
A organizao dos componentes grcos do stoneAge foi desenvolvido pela tambm acadmica do curso de
Cincia da Computao Gabrielle Dias Freitas.
41
informa dados mais precisos para o usurios como a intensidade de maior ocorrncia, o ponto
de threshold, o total de pixels analizados e outros.
Figura 4.7: Visualizao do histograma da imagem da gura 4.6 b).
4.3 A camada de Interface com o Usurio
A camada de interface grca a parte mais importante de um sistema uma vez que, ela
que a maioria dos usurios utiliza para resolver seus problemas [GAL 2002]. Para isso, de
fundamental importncia que a mesma seja funcional, agradvel e acessvel. Segundo ainda
Wilbert Galitz [GAL 2002], um bom projeto de interface grca pode aumentar a produtividade
de 25 a 40%.
Devido a tal importncia, o projeto de interfaces est sendo atualmente visto como um
campo de estudo chamado HCI (Human-Computer Interaction) cujo principal objetivo pesqui-
sar e desenvolver mecanismos capazes de aperfeioar o desenvolvimento dessa importante fer-
ramenta. Foi o que aconteceu em 1970 quando pesquisadores da Xerox do Centro de Pesquisas
de Palo Alto apresentaram o mouse com rodas como uma ferramenta alternativa para as entradas
de dados provenientes do teclado. Graas a isso muita coisa mudou, uma vez que, os programas
puderam ser gerenciados de outra forma ,ou seja, com janelas , caixas de dilogo, botes e ou-
tros componentes grcos. Assim, 14 anos depois o mouse, j com uma bola, fez sucesso com o
Macintosh da Apple revolucionando a interao entre o homem e a mquina para computadores
domsticos [GAL 2002].
Entretanto, as pesquisas baseadas em HCI no se restringem apenas em inventar novas for-
mas que permitamo manipulao de software atravs de novas entidades de hardware mas como
tambm, de investigar como organizar a ampla gama de componentes grcos j existentes de
tal forma que o usurio aprove. Essa a tendncia atual no desenvolvimento de interfaces uma
vez que, hardwares de interao com o usurio, como o mouse por exemplo, j se tornaram um
padro e desde ento no sofreram enormes mudanas. Porm, encontrar um padro para o uso
de interfaces algo complexo uma vez que elas so dinmicas, isto , dependem da aplicao.
42
Um software cujo objetivo editar texto ter, intuitivamente, uma interface diferente de um
programa que implementa solues para o processamento de imagens digitais.
Nesse contexto, a montagem dos componentes grcos para resolver algum problema nor-
malmente ocorre com base na experincia que o desenvolvedor tem no que diz respeito a sa-
tisfao do usurio. Assim, para evitar demasiadas pesquisas de campo, o desenvolvimento da
camada de interface presente nesse trabalho, foi embasada nos inmeros programas j existentes
para imagens como o GIMP
11
, Photoshop
12
e CorelDraw
13
. Revendo a gura 4.1 pode-se visu-
alizar tambm que cada componente na camada de aplicao possui a sua interface pois cada
um desses componentes requer uma interao distinta do usurio e adequada sua lgica opera-
cional. Na gura 4.8 pode-se observar como a organizao dos componentes de uma interface
pode fazer a diferena no que diz respeito a funcionalidade que ela implementa. Nessa gura
apresentado, de maneira bem simples, os principais operadores da biblioteca JAI mencionados
anteriormente e como a sua utilizao pode ser confusa ou bem projetada para o usurio nal
em um exemplo hipottico de uso.
Figura 4.8: a ) Interface grca confusa e desorganizada. b ) Uma interface com a mesma
eccia porm organizada atravs do agrupamento de funcionalidades similares.
Assim, concluindo esse captulo, foi possvel perceber algumas caractersticas e requisitos
exigidos pelo desenvolvimento de software na rea de processamento de imagens. De posse
dessas informaes, o prximo passo o de conhecer mais detalhadamente os padres de cons-
truo. Essa etapa associada com a identicao e aplicao de alguns padres na rea de
imagens, ocorre no captulo seguinte.
11
c 2001-2004 -GNU Image Manipulation Program(http://www.gimp.org/)
12
c 2004 - Adobe Systems Incorporated (http://www.adobe.com/)
13
c 2004 - Corel Corporation (http://www.corel.com/)
43
5 PADRES DE CONSTRUO DE SOFTWARE PARA O
PROCESSAMENTO DE IMAGENS
Nesse captulo ser abordado os padres de projeto que, at o presente momento, apenas
foram citados supercialmente nos captulos e sees anteriores e que, por sua vez, representam
o mago dessa dissertao. Esses padres foram utilizados tanto para a criao do framework
que abrigar todos os componentes para processamento de imagens, quanto para os prprios
componentes a serem continuamente agregados. Porm, sob essa ptica de implementao,
os padres aplicados no desenvolvimento desses artefatos de software, atuam em diferentes
nveis de abstrao. Esses nveis so o de arquitetura (alto nvel), de projeto (mdio nvel) e
idiomticos (baixo nvel).
5.1 Os padres Arquiteturais
Como foi mencionado no captulo 2, o padro arquitetural proposto por Buschmann et al.
[BUS 1996], cataloga formas para organizar a estrutura fundamental de um sistema, isto ,
aquela parte que ir dar suporte a vrias operaes bsicas do sistema para imagens chamado de
StoneAge.
A literatura apresenta oito padres arquiteturais: Pipes and Filters, Broker, Model-View-
Controller, MicroKernel, Reection, Blackboard, Presentation-Abstraction-Control e Layers.
O primeiro deles, isto , Pipes and Filters que pode ser traduzido para Tubos e Filtros
apresenta uma soluo para desenvolver sistemas baseados em uxo de dados. O prximo
padro denominado de Broker (intermedirio) muito usado na implementao de sistemas
distribudos pois propicia a interoperabilidade entre diferentes componentes de software sejam
eles remotos ou locais. Exemplos do uso dessa soluo so o CORBA descrito na seo de
aplicao do captulo 4, a tecnologia Microsoft Ole 2.x e navegadores internet como HotJava
1
,
Mosaic
2
e Netscape
3
que agem como intermedirios entre os clientes e os provedores de servio
WWW [BUS 1996].
1
c Copyright 1994-2004 Sun Microsystems, Inc. (http://java.sun.com/products/archive/
hotjava/)
2
c 2003 Board of Trustees of the University of Illinois (http://archive.ncsa.uiuc.edu/SDG/
Software/Mosaic/NCSAMosaicHome.html)
3
c 2004 Netscape. All Rights Reserved. (http://www.netscape.com/)
44
O padro Model-View-Controller (Modelo/Vista/Controlador) utilizado para construir in-
terfaces para o usurio atravs da aplicao de trs componentes: O Modelo contm a lgica
bsica utilizada na resoluo do problema. A Vista exibe as informaes para o usurio e o
controlador manipula a entrada de dados pelo usurio. Segundo Gamma et al. [GAM 2000]
e Buschmann et al. [BUS 1996] os usos conhecidos desse padro so a construo de inter-
faces para a linguagem VisualWorks Smalltalk-80, e a Microsoft Fundation Class (MFC) para
desenvolver aplicaes para a plataforma Windows.
O prximo padro apontado pela literatura o Microkernel e que, de forma muito intuitiva,
serve para desenvolver software que precisa estender vrias aplicaes a partir de um ncleo
central. Essa abordagem tpica de sistemas operacionais e, dessa forma, ele tem seu uso prtico
na implementao do sistema operacional Mach
4
, Amoeba
5
, Windows NT
6
, para sistemas em
tempo real como o Chorus
7
e para sistemas de busca de dados como o MKDE.
O Padro arquitetural Reection (Reexo) serve para sistemas que precisam mudar sua
estrutura e comportamento dinamicamente. Pode tambm ser visto como um sistema adap-
tvel como o MicroKernel anteriormente descrito. Buschmann cita o exemplo de uma apli-
cao que precisa guardar de forma persistente seus dados sendo que, para isso, necessrio
armazenar e ler arbitrariamente objetos da memria principal. Para isso, faz-se necessrio ter
acesso dinmico aos dados por esses objetos implementados[BUS 1996].
J o padro BlackBoard implementa uma soluo em um contexto em que determinado
problema precisa de vrios programas independentes e que trabalham cooperativamente sob
a mesma estrutura. Nesse caso Buschmann descreve o problema de um software que precisa
realizar o reconhecimento de voz. A entrada de dados desse sistema pode ser uma simples
palavra ou uma sentena inteira e a sada de dados a representao desses sinais na forma
de frases completas exibidas na tela. Para isso, deve haver um programa que segmenta a onda
sonora de forma a ter sentido, outro programa ou procedimento deve checar a sintaxe da frase e
outras operacionalidades. So exemplos de sistemas que usam esse padro o HEARSAY-II que
um reconhecedor de voz de 1970, o HASP/SIAP utilizado para detectar submarinos inimigos
e o TRICERO de 1984 cuja funo era monitorar o trfego de aeronaves.
O padro Presentation-Abstraction-Control (Apresentao/Abstrao/Controle) tambm
destinado a implementao de software interativo. Com ele pode-se implementar interfaces com
o usurio (no necessariamente apenas interfaces grcas) baseando-se no conceito de agentes
colaborativos. O exemplo dado para esse padro um sistema para visualizar os resultados de
uma eleio. O sistema oferece vrias formas de visualizao como grco de setores, grco
de barras, tabelas e outros. Assim, a pedido do usurio, o sistema pode retornar diferentes
abstraes dos resultados, isto , uma verso do sistema pode estar mostrando apenas a tabela
4
c Desenvolvido pela Carnegie Mellon University (http://www-2.cs.cmu.edu/afs/cs/project/
mach/public/www/mach.html)
5
c 1996 Vrije Universiteit te Amsterdam, The Netherlands. All Rights Reserved.(http://www.cs.vu.
nl/pub/amoeba/)
6
c 2004 Microsoft Corporation. All rights reserved.(http://www.microsoft.com/)
7
Desenvolvido pelo Instituto Nacional de pesquisa em Informtica e em Automao da Frana(http://www.
inria.fr/)
45
precisa dos resultados da eleio enquanto outra pode estar exibindo informaes mais deta-
lhadas sobre o nmero de cadeiras que determinado partido alcanou no parlamento ao nal da
eleio [BUS 1996].
O ltimo padro arquitetural o Layers (camadas). Com ele pode-se modelar uma apli-
cao, intuitivamente, sob camadas onde, cada uma delas representa um domnio na aplicao.
Esse padro arquitetural foi utilizado para projetar o StoneAge. dele que surgiu o modelo
de camadas descrito no captulo 4, isto , a camada central que dominada pela biblioteca
para imagens JAI, a camada de aplicao que corresponde aos componentes desenvolvidos at
o presente momento e a camada de interface grca com o usurio que permite a entrada e
visualizao das imagens.
5.1.1 Da Lama Estrutura
A Big Ball of Mud
8
o nome que caracteriza os sistemas que so estruturados por convenin-
cia, isto , de acordo com a experincia do programador. No so levados em considerao as
noes de projeto pois no h preocupao em uma construo capaz de permitir que outras
pessoas possam facilmente entender e manter sua implementao.
Nesse contexto de desenvolvimento pode-se dizer que utilizar uma abordagem emprica no
desenvolvimento de uma ferramenta que estar em contnuo crescimento invivel. A idia cen-
tral do StoneAge que ele se torne uma verdadeira Caixa de ferramentas no que diz respeito
a processamento de imagens. Assim, ele sofrer modicaes constantes seja pelos alunos de
cincia da computao, da fsica ou at mesmo pelos professores do grupo de pesquisa.
Dessa forma, para assegurar que esse sistema cresa medida que novas necessidades de
aplicao vo surgindo no grupo de pesquisa
9
sua concepo bsica no pode ser proveniente
das idias baseadas na observao que o programador tem. Para isso, a melhor forma de im-
plementao a baseada em padres. Tomando como base o sentido da palavra, intuitivamente
pode-se pensar que essa uma boa idia pois, se um padro a especicao de algum problema
que se repete a sua utilizao e conseqente entendimento pode ser facilmente visualizado com
a vantagem de possuir j uma vasta documentao para o seu uso. Assim conseguido atribuir
suporte ao processo de desenvolvimento tornando-se muito til para os novos programadores
e/ou projetistas que iro agregar novas funes de acordo com as necessidades do grupo de
pesquisa.
De forma mais especca, entre os oito padres descritos anteriormente, o padro que mais
se encaixa no contexto de desenvolvimento do grupo o Layer. Atravs desse padro o StoneAge
foi dividido, como j descrito anteriormente, em trs camadas que correspondem a diferentes
graus de abstrao. Por exemplo a primeira camada ou camada do ncleo representa o mais
8
Ttulo da Palestra de Joseph Yoder (University of Illinois/The Refactory, Inc., US) na Terceira Con-
ferncia Latino Americana em Linguagens de Padres para Programao (http://www.cin.ufpe.br/
~sugarloafplop/main_pt.htm).
9
Com a aprovao do Edital CT-Info/MCT/CNPq 031/2004 pela coordenao do grupo PIGS o StoneAge ser
utilizado para dar suporte implementao da proposta intitulada: Ferramentas de Processamento e Anlise
de Imagens para Microscopia Quantitativa Aplicada a Anatomopatologia e Caracterizao Microestrutural de
Materiais. (http://www.cnpq.br/resultadosjulgamento/edital_312004_ctinfo.htm).
46
baixo nvel, enquanto que a interface grca com o usurio apresentada sob o nvel mais alto
no que se refere a aplicao com imagens.
Buschmann et al. [BUS 1996], ilustra a utilizao desse componente atravs da arquitetura
do modelo OSI. Omodelo OSI (Open Systems Interconnection) foi especicado para padronizar
o desenvolvimento de produtos de software voltados para redes de comunicao de dados. Ele
foi muito importante pois facilitou a interconexo de sistemas uma vez que, todos os protocolos
desenvolvidos pelos mais diversos fabricantes deveriam seguir esse modelo na sua concepo
[TOR 2001]. Graas a esse padro de desenvolvimento, possvel construir uma rede de com-
putadores utilizando produtos de diversos fabricantes. Esse modelo composto por sete ca-
madas a saber: A camada fsica, a camada de link de dados, a camada de rede, a de transporte,
a de seo, a de apresentao e a de aplicao. A gura 5.1 demonstra essas camadas.
Figura 5.1: Um exemplo de aplicao do padro arquitetural Layer: o modelo OSI.
Na transmisso de um dado, por exemplo um pacote IP (Internet Protocol), a utilizao da
camada OSI para tal objetivo ocorre de cima para baixo, isto , da camada sete que a de
aplicao, at a camada fsica que ir codicar esse pacote em sinais compatveis com o meio
onde os dados sero transmitidos (que o que as placas de rede fazem). Na recepo dos dados
o processo inverso, isto , primeiro a camada fsica recebe o sinal e os converte para zeros e
uns passando-os para a prxima camada denominada de link de dados.
Porm essa no a nica aplicao onde esse padro utilizado. Ele utilizado tambm
na implementao da JVM
10
(Java Virtual Machine). O cdigo construdo em Java quando
compilado traduzido para bytecodes que por sua vez so enviados para a JVM para serem
interpretados. Esse ltimo passo equivale a execuo do programa e as fases de traduo e
interpretao so realizadas sob a arquitetura de camadas. Outro exemplo muito intuitivo citado
10
1994-2004 Sun Microsystems, Inc. (http://java.sun.com/).
47
por Frank Buschman et al. so as APIs. As APIs so conjuntos de entidades de software que
podem tambm possuir diferentes nveis de abstrao. Como dito anteriormente a biblioteca JAI
uma API e como o StoneAge pode ainda de subdividir emcamadas. Ela apresenta vrios nveis
de abstrao pois prov mtodos de baixo nvel como os iteradores que realizam a navegao
entre os pixels assim como prov tambm um componente grco que exibe a imagem na tela
11
Outro uso conhecido so os Sistemas de Informao (SI) destinados ao comrcio e indstria. A
camada mais baixa geralmente representada pelo banco de dados e a mais alta pela interface
grca e a lgica operacional do sistema. Esses dois ltimos normalmente so implementados
juntos caracterizando um sistema com duas camadas. Atualmente o modelo mais utilizado
o de trs camadas cuja nica diferena consiste na separao entre lgica e interface. Por m
outro bom exemplo o sistema operacional voltado para redes corporativas Microsof Windows
NT. Esse sistema foi implementado basicamente sob quatro camadas:
Servios: Camada existente entre seu microkernel (denominado de NT Executive) e os
demais subsistemas;
Gerenciamento de Recursos: nessa camada esto implementados os mdulos de segu-
rana, de escalonamento do processador, de entrada e sada (mais conhecido como I/O),
gerenciamento de memria virtual entre outros;
Ncleo: que implementa operaes de baixo nvel como interrupes, tratamento de ex-
cees e outros;
HAL: Abreviatura de Hardware Abstraction Layer, cuja funo mascarar as diferenas
de hardware entre mquinas que possuem diferentes caractersticas fsicas;
Assim, mediante esses casos de uso que ocorrem nas mais diferentes reas onde os sis-
temas de computao esto presentes, justica-se o uso desse padro para o desenvolvimento
do StoneAge. Ele utilizado porque o StoneAge um sistema grande e dessa forma, decomp-
lo em camadas o tornar mais gerencivel no que diz respeito a sua complexidade. Deste modo,
as vantagens da aplicao desse padro sobre o sistema desenvolvido pode ser resumida em dois
itens: o reuso de camadas e a mudana acessvel de cdigo pertencente a cada camada. A ca-
mada de aplicao, por exemplo, pode ter seus componentes reutizados para outra aplicao uma
vez que cada um encontra-se sicamente separado para ns organizacionais, de manuteno e
de legibilidade. No StoneAge cada componente encapsulado em uma estrutura chamada pa-
cote, isto , eles no esto espalhados como mostra a gura 2.2. Essa gura foi assim construda
apenas para simplicar a idia central do funcionamento de um framework. Nesses pacotes,
que na verdade apenas uma hierarquia de diretrios reconhecida pela linguagem Java, so
compostos, usualmente, por inmeras classes que podem ser instanciadas por outras aplicaes.
Instanciadas signica que as classes podem ser utilizadas em outro ambiente que no o frame-
work chamado de StoneAge. No entanto, para ns de agilidade e simplicidade, o novo ambiente
11
Esse componente existe mas depreciado, isto , teve sua manuteno extinta e possui alguns bugs.
48
que ir receber esses componentes precisa ser construdo na mesma linguagem de origem dos
componentes que, no caso, Java. O StoneAge tem como vantagem tambm a fcil permutao
de cdigo porque cada layer ou camada possui seus prprios componentes, o que signica dizer
que na necessidade de mudana de algum componente apenas atua-se nesse local e mais especi-
cadamente sob o pacote que guarda esse componente. Assim, se mantidas sempre a mesma
interface dessa entidade de software pode-se troc-la por outra que implementa uma lgica mais
eciente ou que corrige bugs que durante a fase de testes passaram desapercebidos. Outro fato
prtico que surgiu no processo de desenvolvimento e que, pode ser encaixado nessa vantagem
de fcil troca de camadas, diz respeito a nova verso da JAI
12
lanada aps, a fase nal de im-
plementao do framework e que foi atualizada com xito. Framework refere-se ao StoneAge
e pode ser interpretado como um arcabouo de classes que iro dar suporte a um projeto re-
utilizvel de software [GAM 2000]. Na gura 5.2 mostrado o processo de componentizao
associado com a aplicao do padro arquitetural Layer.
Figura 5.2: viso das Camadas de um sistema com seus componentes internos e como eles se
relacionam. Adaptado de Buschmann et al. [BUS 1996].
Essa gura representa uma evoluo da idia inicial proposta pela gura 2.2 e uma viso de
mais baixo nvel se tomado como parmetro a gura 4.1. Esse baixo nvel refere-se a uma viso
j de implementao, ou seja, nesse estgio o StoneAge no era mais considerado uma bola
de lama, mas sim o projeto inicial do framework que oferece suporte as atividades do grupo
de pesquisa no que diz respeito ao processamento de imagens. Nela possvel enxergar que
o ncleo e a prpria interface tambm so baseadas no processo de componentizao. Esses
12
A nova verso a 1.1.2_01 de setembro de 2004. Pode ser efetuado o download livremente em (http:
//java.sun.com/products/java-media/jai/).
49
componentes internos j no so considerados de arquitetura, mas sim baseados na viso de
projeto e idioma.
5.2 Padres Gamma
Os padres Gamma como so chamados de maneira mais corriqueira os padres de projeto
especicados por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. A gangue dos
quatro, como so mais conhecidos, escreveram um livro onde apresentam vinte e trs padres
de construo para software orientado a objetos [GAM 2000].
A diferena entre esses padres e os arquiteturais descritos na seo anterior, que eles no
especicam maneiras de construir a estrutura fundamental de um sistema. Sublinha-se que, os
padres arquiteturais como o Layer, Microkernel, Pipes and Filters e outros intencionam justa-
mente isso, ou seja, fornecer um modelo bsico para o sistema a ser implementado. Entretanto
esses padres no especicam como fazer essa implementao a nvel de construo orientada
a objetos ou atravs de outro estilo qualquer de programao. justamente por isso que eles
so denominados padres de alto nvel, isto , no so utilizados conceitos de linguagem de
programao. Porm, cabe ressaltar, que essa fase deve ser realizada antes da utilizao dos de-
mais padres por motivos bvios uma vez que, eles que iro fornecer o bsico para sustentar a
maior parte do sistema.
Nesse contexto, os padres de projeto possuem uma caracterstica mais implementvel, ou
seja, apresentam estruturas prticas para o desenvolvimento de software orientado a objetos.
Tais estruturas correspondem a especicao de classes, instncias de classes, pacotes de soft-
ware e principalmente o relacionamento que as diversas estruturas apresentam como a herana
e agregao. Essas entidades de software geralmente so mostradas sob a forma de diagramas
UML principalmente os diagramas de classe e de pacotes. E justamente nesse nvel que a
UML surge como uma ferramenta que faz a ligao entre a modelagem do programa em alguma
ferramenta visual com a parte de cdigo.
Existem muitas ferramentas para essa fase de modelagem como o Rational Rose
13
e o UML-
Studio
14
que so verses pagas. Uma boa alternativa para isso a ferramenta UML chamada
ArgoUML
15
. Porm essas ferramentas no so meramente visuais. No UMLStudio por exem-
plo, possvel, atravs do diagrama de classes, gerar cdigo em ADA 95, C++, IDL e Java.
Obviamente essa gerao de cdigo-fonte parcial, isto , restringe-se ao escopo das classes,
mtodos e atributos especicados previamente. Ele no oferece a implementao lgica de
determinado componente de forma automatizada. Nesse contexto de operacionalidade essas
ferramentas servem apenas para ttulo de modelagem e conseqente documentao visual do
artefatos de software produzidos. A gura 5.3 mostra a interface do software de modelagem
UMLStudio sendo utilizado para modelar/documentar o componente de visualizao de his-
13
c IBM Corporation (http://www.ibm.com/).
14
c 1996-2001 PragSoft Corp. (http://www.pragsoft.com/).
15
Esse software Open Source e pode ser baixado livremente em (http://argouml.tigris.org/).
50
tograma representado pela gura 4.7 apresentado no captulo 4.
Figura 5.3: Uma ferramenta de construo de diagramas UML para a modelagem de software
orientado por objetos.
A gura 5.3 demonstra a implementao de duas classes para resolver o problema da visu-
alizao de histograma que so a HistogramAnalysis e a DisplayHistogram. A primeira
apenas passa o objeto de pixels para a segunda. Nesse componente utilizado a API Java 2D
para dar suporte a criao de grcos de alta qualidade. Com ela possvel manipular at ima-
gens porm de uma forma mais complicada e com pouco suporte no que diz respeito operaes
bsicas [KNU 1999].
Voltando aos padres de projeto propriamente dito, pode-se dividi-los em trs categorias
conforme descrito no captulo 2. Essa separao no um padro propriamente dito, isto ,
ela utilizada por Gamma et al. em [GAM 2000] porm Buschmann et al. em [BUS 1996]
descreve apenas oito padres e os coloca tambmem um contexto similar. Mas como os padres
Gamma so emmaior nmero utilizou-se a primeira referncia para ns de implementao desse
trabalho.
Os 23 padres descritos por Gamma so: Abstract Factory, Builder, Factory Method, Pro-
totype, Singleton, Adapter, Bridge, Composite, Decorator, Faade, Flyweight, Proxy, Chain of
Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy,
Template Method e Visitor. Eles so agrupados conforme o seu propsito e isso pode ser obser-
vado na tabela 5.1.
51
Padres de Criao Padres Estruturais Padres Comportamentais
Factory Method Adapter Interpreter
Abstract Factory Bridge Template Method
Builder Composite Chain of Responsability
Prototype Decorator Command
Singleton Faade Iterator
FlyWeight Mediator
Proxy Memento
Observer
State
Strategy
Visitor
Tabela 5.1: Os padres de projeto de Gamma agrupados em categorias ans.
Diferente do que ocorreu com a utilizao dos padres arquiteturais onde apenas um foi
identicado e utilizado para fundamentar o sistema, no desenvolvimento de umcomponente seja
na camada que for, pode-se utilizar vrios padres de projeto. Foi o que ocorreu no processo
de criao de um componente para segmentao de imagens baseado em contornos que ser
apresentado no captulo 7.
Para utilizar esses padres no processo de criao de componentes em Java primeiro deve-se
entender o que cada um representa, isto , o propsito de cada um deles. Cada um deles possui
uma nalidade distinta e, dessa forma, no necessariamente so utilizados em sua plenitude para
os problemas que envolvem processamento de imagens.
5.2.1 Padres de Criao
O Padro Factory Method (Fbrica de Mtodos) serve para retornar um objeto em um
contexto de diversas outras classes. Segundo [COO 1998] isso pode ser facilmente reali-
zado atravs da implementao de classes abstratas, onde cada classe lha dessa, isto ,
as concretas, possuem mtodos comuns porm com diferentes implementaes. Assim,
esses mtodos podem ser chamados de fbricas porque so os responsveis pela manu-
fatura dos objetos [GAM 2000]. Uma aplicao desse padro foi identicada durante no
uso dos iteradores descritos no captulo 4 mais precisamente quando era abordado a ca-
mada central do StoneAge, isto , o ncleo representado pela JAI. Nesse caso, o mtodo
que concretiza a manufatura do objeto que ir permitir a navegao nos pixels da ima-
gem o mtodo create() e sua construo na integra ocorre pelo seguinte cdigo:
RectIter readIterator = RectIterFactory.create(input, null);. Para
utilizar o outro iterador (o RookIter) mostrado na gura 4.3 b), basta importar o pacote
apropriado e trocar o cdigo anterior por RookIter readIterator = RookIterFac-
tory.create(input, null); onde input o objeto PlanarImage que carrega a
matriz de pixel. Ele um exemplo de fbrica de mtodos pois consegue instanciar apenas
um objeto concreto por vez [Sun 1999]. Outra aplicao desse padro foi identicada na
52
criao dos operadores mostrados na tabela 4.1 tambm atravs do mtodo create()
implementado pelo objeto JAI .
O Padro Abstract Factory
16
funciona de forma equivalente ao anterior, porm nele,
conseguido um nvel maior de abstrao. Em vez de retornar um objeto apenas, pode-se
retornar fbricas inteiras de objetos.
Um exemplo muito bom da utilizao desse padro pode ser visto no Look and Feel
utilizado pelos componentes swing do Java para mudar o estilo de apresentao dos
componentes grcos. H trs estilos de interfaces implementadas no JDK por default
: o estilo Windows, Motif(Unix) e Metal(padro Java). Eles so suportados pelo pacote
com.sun.java.swing.plaf[ECK 1998]. PLAF signica Pluggable Look-and-Feel
e sua utilizao pode ser vista na gura 5.4. Essa fbrica de objetos pode tornar-se muito
importante pois permite deixar a aplicao conforme os padres visuais existentes o que,
agrada o usurio leigo. Am disso, ela tambm permite misturar esses vrios estilos em
uma mesma aplicao e em tempo de execuo. Na gura
17
5.4 foi utilizado na barra de
rolagem o padro Java. No componente JTabbedPane(que d acesso a outros painis
dentro da mesma janela) foi utilizado o padro Unix e nas janelas de interao utilizadas
para abrir o arquivo grco foi utilizado o padro Windows.
Figura 5.4: Iterface grca construda com a mescla dos trs Look and Feel nativos do Java.
Sublinha-se que esse padro uma fbrica abstrata pois toda vez que um determinado
Look and Feel
18
utilizado todos os componentes grcos presentes na aplicao auto-
16
Tambm referenciado pela literatura como Kit.
17
Usa a imagem da lenna, que a mais utilizada em testes de imagens.(http://www.lenna.org).
18
Um tutorial on-line pode ser encontrado em http://java.sun.com/products/jlf/ed1/dg/.
53
maticamente so atualizados para esse perl. E, sendo que, todos esses componentes gr-
cos possuem sua implementao em diferentes objetos h a necessidade de reetir esse
efeito para todos eles. Ele dito abstrato porque para a sua utilizao no necessrio
especicar suas classes concretas. No que se refere a implementao ele foi construdo
de forma a permitir a fcil troca entre diferentes estilos visuais atravs de uma pequena
mudana no cdigo. Essa operao exibida na implementao da gura 5.5. Observe
nessa gura que a utilizao desses estilos visuais requer um bloco de tratamento de ex-
ceo. Nas linhas 3 e 11 pode-se comprovar que para o uso de determinado estilo basta
concatenar as strings Motif, Windows ou Metal com a palavra LookAndFeel() que ir
formar o objeto invocador.
Cdigo 2: Alternando entre diferentes estilos visuais.
01. //Configurando um componente para o estilo Unix
02. try {
03. UIManager.setLookAndFeel(new MotifLookAndFeel());
04. } catch (UnsupportedLookAndFeelException e) {
05. System.out.println("Problemas com o tema Unix Like");
06. }
07. //jtp o componente que implementa o painel de abas
08. SwingUtilities.updateComponentTreeUI(jtp);
09. //Configurando um componente para o estilo Windows
10. try {
11. UIManager.setLookAndFeel(new WindowsLookAndFeel());
12. } catch (UnsupportedLookAndFeelException e) {
13. System.out.println("Problemas com o tema Windows Like");
14. }
15. //bar o componente que implementa a barra de menus
16. SwingUtilities.updateComponentTreeUI(bar);
Figura 5.5: Um exemplo clssico do uso do padro Abstract Factory: mudando o estilo visual
dos componentes grcos do JDK.
J o padro Builder tem a nalidade de separar um objeto de todas as partes responsveis
por sua formao. Ele usado quando o objeto possui um grau de complexidade muito
grande e para isso sua construo ocorre em etapas, da o nome bastante intuitivo desse
padro, isto , construo. O objeto complexo vai sendo construdo por partes, sendo
que cada uma dessas partes representam um algoritmo distinto mas que, por sua vez,
complementam o objeto nal que chamado pela literatura de produto. A vantagem
direta desse padro a modularidade que apresenta, pois cada uma dessas separaes
entre etapas e produtos nais pode ser implementado atravs de classes distintas. Outra
vantagem citada por Erich Gamma et al. [GAM 2000], diz respeito ao controle que o
54
processo de criao possui, o que j no acontece com o padro Abstract Factory por
exemplo. Isso bem intuitivo de ser entendido pois os padres de criao anteriores
criam os produtos de uma s vez, enquanto que o Builder implementa uma lgica mais
precisa e incremental.
O prximo padro de criao o Singleton. Esse padro tem a nalidade de gerenciar
o processo de criao dos objetos. Ele pode ser utilizado, por exemplo, para garan-
tir que haja apenas uma instncia de uma determinada classe. Isso pode garantir ope-
racionalidades essenciais como a existncia de apenas uma determinada aplicao na
memria, um nico ponto de acesso a um banco de dados ou apenas um gerenciador de
impresso habilitado para uma rede de computadores locais como uma intranet por exem-
plo [COO 1998]. Alm dessas vantagens esse padro possibilita gerenciar as excees
que podem ocorrer durante o processo de instanciao.
O ltimo padro de criao o Prototype. Esse padro instancia objetos clonando ob-
jetos pr-existente. Esses objetos pr-existentes que foram copiados recebem o nome de
prottipos. Esse padro usado a todo momento, pois dicilmente algum constri uma
aplicao do zero, isto , sem reaproveitar uma srie de classes anteriormente codicadas.
Esse processo de reuso no ocorre apenas no que se refere a implementao de classes
elaboradas pelo desenvolvedor em questo, mas como tambm, nas vrias fbricas de ob-
jetos disponveis pelos kits de desenvolvimento como o JDK (Java Development Kit). A
utilidade desse padro evitar a proliferao desnecessria de cdigo.
5.2.2 Padres Estruturais
Os padres estruturais se preocupam com a forma com que os objetos so compostos. H
sete desses padres no catlogo Gamma (que el a tabela 5.1) sendo que, sua maior nalidade,
prover modelos de estruturas de objetos capazes de suportar a interoperabilidade entre si a
medida que o sistema cresce.
O primeiro padro o Adapter. Esse padro tem a nalidade de tornar a interface de
uma classe compatvel com outra. Isso acarreta na cooperao entre ambas, isto , per-
mite dois objetos trabalharem em conjunto. Segundo Cooper [COO 1998], existem duas
maneiras de fazer isso: atravs do mecanismo de herana e de composio. No primeiro
caso deriva-se uma nova classe a partir da incompatvel de forma a ajustar os mtodos
com a mesma, isto , que tenha uma mesma assinatura. A segunda instanciar a classe
original na nova (que precisa ser adaptada ao que j existe) e criar mtodos que possam
se comunicar com a classe original.
O padro Bridge separa a abstrao da implementao de determinado objeto. Em outras
palavras, ele esconde os detalhes de implementao da interface para ns de interope-
rabilidade entre dois objetos. Buschmann et al. [BUS 1996], cita como exemplo um
componente distribudo que precisa funcionar em uma rede de computadores e sistemas
55
operacionais heterogneos. Esse componente pode ser requisitado sob esses sistemas di-
ferentes mas precisa garantir a comunicao independente dessa peculiaridade. Assim
o padro Bridge implementa em seu interior uma hierarquia de camadas capaz de tratar
esses detalhes essenciais de funcionalidade.
O padro Composite utilizado em componentes que precisam representar uma coleo
de objetos. Esses objetos geralmente apresentam-se como uma estrutura de rvore para
representar hierarquias do tipo todo-parte [GAM 2000]. Um bom exemplo para isso a
API de interface grca do JDK, que se utiliza de uma hierarquia para representar seus
componentes grcos. A gura 5.6 demonstra um exemplo de hierarquias de pacotes na
qual o componente de interface grca JTextField foi implementado.
Figura 5.6: Componente grco construdo a partir de uma hierarquia de pacotes Java. (Imagem
obtida da documentao HTML do j2sdk1.4.1_02)
O padro Decorator tem a inteno de modicar o comportamento de um objeto sem que
haja a necessidade de derivar uma nova classe a partir dessa. Para que essa extenso
de funcionalidade ocorra a maneira que a literatura recomenda anexar ou empacotar
esse objeto em outro componente que implemente essas funcionalidades. devido a esse
processo que esse componente tambm chamado de Wrapper (empacotador).
Opadro Flyweight(peso-mosca) so usados emaplicaes que exigemumgrande nmero
de pequenas instncias de classes para resolver algum problema. Segundo James W.
Cooper [COO 1998], ele pode ser utilizado em um editor de texto que trata cada caracter
ou cada cone utilizados em uma tela como um objeto. Porm isso pode gerar dezenas
ou at centenas de milhares de objetos acarretando em um uso exagerado de memria.
Para resolver isso, basta reconhecer as instncias que so similares e transform-las em
mtodos (operaes) reduzindo assim o nmero de objetos na memria.
O Proxy um padro que implementa o controle de acesso a um objeto para ns de
us-lo sob demanda, isto apenas quando for necessrio. Gamma et al. [GAM 2000],
56
descreve um editor que precisa carregar uma grande imagem e exibir na tela. Para evitar
que isso ocorra quando h outras tarefas sendo executadas e que exigem um certo grau de
processamento, essa imagem pode ser ocultada, mantendo-se apenas uma referncia para
a mesma.
O ltimo padro o Faade. Esse padro prov um objeto que unica todas as interfaces
dos objetos pertencentes a um componente. Ele funciona como uma fachada que esconde
as particularidades das assinaturas dos objetos de um componente tornando-o mais fcil
de ser utilizado. Na gura 5.7 pode-se ver facilmente como esse processo atua no que diz
respeito as classes que pertencem a um pacote pr-existente e as classes novas situadas
acima desse componente.
Figura 5.7: O padro de projeto Faade atuando para tornar um componente mais exvel. a)
mostra a maneira confusa com que as novas classes E e F se comunicam com as classes do
componente. b) a aplicao do padro Faade para fazer o meio campo entre as interfaces dos
componentes e das classes novas E e F.
5.2.3 Padres Comportamentais
A preocupao principal desses padres so os algoritmos e a atribuio de responsabilida-
des entre objetos [GAM 2000]. Entretanto, para implementar essa idia ele tambm especica
estruturas de construo para os objetos. Essa categoria representada por onze padres. A
seguir apresentado uma breve descrio de cada um.
O padro Chain of Responsibility resolve determinado problema atravs da atribuio
de responsabilidades a uma cadeia de objetos. Nessa cadeia um objeto no est apto a
conhecer o comportamento do outro sendo que entre eles apenas h uma comunicao do
tipo requisio. Segundo Cooper [COO 1998], esse padro utilizado para implementar
sistemas de Help onde cada problema a ser pesquisado pelo usurio (que a requisio)
passa por diferentes objetos nessa cadeia at que o usurio consiga ou no a informao
desejada.
57
O padro Command similar ao anterior, isto , ele atende a um determinado pedido. A
diferena que ele no realiza essa requisio para uma cadeia mas sim, para um objeto
especco. Esse padro foi utilizado na construo do StoneAge e sua descrio mais
detalhada ser feita no captulo 6.
O padro Interpreter tem a nalidade de interpretar a gramtica de uma determinada lin-
guagem (como um projeto de compilador) ou para analisar, por exemplo, palavras de
dados referentes a nomes de pessoas em um sistema. Um bom exemplo descrito por
Cooper, [COO 1998] atravs do software Mathematica
19
onde atravs de uma equao
pode-se visualizar o seu grco como uma curva por exemplo. Para isso deve-se criar
uma hierarquia de classes capaz de atender as expresses regulares proposta por esse sis-
tema.
OIterator tema inteno de proporcionar o acesso seqencial aos elementos de umobjeto.
o que ocorre com os iteradores implementados pelo JAI. O objeto que implementa o
iterador na JAI acessa na ordem anteriormente descrita os pixels de uma imagem que
esto encapsulados no objeto PlanarImage . A principal caracterstica dele que ele
realiza essa operao de forma alto nvel, isto , no preciso reconhecer os detalhes
internos de sua implementao.
O Mediator utilizado para prover um fraco acoplamento entre objetos que precisam
mutuamente conhecer seus mtodos ou atributos. Quando h muitos objetos envolvidos
essa referncia entre objetos pode deixar o sistema muito confuso e, portanto, de difcil
manuteno. Para resolver isso, cria-se uma classe que ir gerenciar todas essas refern-
cias, isto , um objeto que conhecer os detalhes de implementao de todos os outros
[COO 1998]. Assim quando um objeto precisa se comunicar com outro ele o faz via
objeto mediador.
O padro Memento (recordao) guarda o estado de um objeto a m de recuper-lo pos-
teriormente. muito utilizado para prover a operao Undo [MET 2002]. Essa operao
muito til em qualquer sistema pois permite recuperar o objeto original de entrada sem
que haja a necessidade de executar sua abertura novamente e realizar determinado proces-
samento redundante. Para isso cria-se um nova classe que ir quardar o ltimo estado de
determinado objeto.
O padro Observer usado para separar um problema em dois objetos: um objeto que
cuida dos dados que sero utilizados e outro que mostra esses dados de alguma forma,
isto , seja por interface ou modo terminal mesmo. Assim esse objeto de exibio precisa
sempre observar qualquer mudana nos atributos do objeto de dados para ns de atu-
alizao dos dados que podem ter sofrido mudanas. Ele utilizado na implementao
do padro arquitetura MVC (Model-View-Controller) para gerenciar qualquer atualizao
19
c 2004 Wolfram Research, Inc. (http://www.wolfram.com/).
58
sofrida pelo objeto Model(que representa o ncleo dos dados utilizados) e que ir reetir
no objeto View (que mostra na tela). Dessa forma sua utilizao garante a delidade de
visualizao da informao.
O padro State utilizada para implementar objetos que dependem de uma determinada
situao para manifestar seu comportamento. Por exemplo, um objeto que representa uma
conexo de rede pode apresentar os estados estabelecido, fechado ou escutando.
Assim, um pedido de comunicao solicitado por algum outro objeto vai ser atendido
dependendo do status do objeto que implementa a conexo com a rede [GAM 2000].
O Strategy um padro que encapsula os detalhes de escolha de determinado algoritmo
em um contexto onde podem existir famlias inteiras de algoritmos.
O padro Template Method tambm foi utilizado nesse trabalho e sua nalidade prover
uma lgica comum para todas as subclasses de um componente. Para isso, a classe me
implementa um mtodo (que por sua vez encapsula um algoritmo) que utilizado por
todas as sub-classes evitando assim sua replicao em cada uma delas.
O ltimo padro o Visitor. Oferece uma estrutura para ser utilizada quando uma classe
concreta invoca um mtodo especco implementado por outra classe. Para isso deve ser
tratado as questes de visibilidade para permitir tal comunicao. Ele til pois permite
denir uma nova operao em outro objeto sem mudar as classes que j existem evitando
assim, a recompilao de cdigo.[GAM 2000]. Esse objeto separado o visitante da o
nome desse padro.
Dentre todos esses padres, que so os mais conhecidos da literatura, nem todos podem
se encaixar em problemas de processamento de imagens. Alguns deles foram usados para a
implementao desse trabalho, porm, isso no signica que a medida que o sistema cresce
outros padres sejam reconhecidos e utilizados.
5.3 Padres Idiomticos
Como dito no captulo 2, essa outra maneira de construir software orientado por objetos.
Porm nessa categoria no se cria classes e relacionamentos complexos como ocorre com os
anteriores. Mesmo assim, ela citada como baixo nvel porque est intimamente ligada a lin-
guagem de programao utilizada para desenvolver os componentes ou at mesmo o prprio
framework base.
A idia central desses padres utilizar recursos oferecidos pela linguagem usada na resolu-
o de algumproblema. Por exemplo, a linguagemC++ oferece a possibilidade de programar de
forma genrica atravs dos gabaritos STL. Java j implementa uma espcie de padro Singleton
atravs da palavra chave Static. Esse ltimo no tem exatamente a mesma nalidade do padro
propriamente dito, mas ajuda a sua implementao. Java apresenta mecanismos para guardar
59
objetos para sua utilizao em momentos futuros, substituindo assim a necessidade do padro
de projeto Memento. Esse ltimo diz respeito a implementao do objeto Vector, que permite
guardar objetos como se fossem dados primitivos em um vetor simples.
Porm, Buschmann et al. [BUS 1996], descreve que o simples ato de manter uma certa
caracterstica quando se desenvolve cdigo, est se utilizando um padro idiomtico tambm.
Isto , nesse caso no signica necessariamente utilizar vantagens oferecidas pelas linguagens
de programao, mas sim atravs da manipulao uniforme de cdigo simples. Por exemplo, se
um programador em C faz o possvel para utilizar apontadores de memria para implementar
alguma soluo, mesmo sabendo que existe a possibilidade de outras formas ele est progra-
mando com padres. A idia no misturar as formas e procurar propagar um padro para
todo o cdigo-fonte. No que se refere a esse trabalho, isso de certa forma foi utilizado pois,
mesmo que alguns componentes tenham sido manipulados ou codicados por pessoas diferen-
tes manteve-se um padro de codicao no que diz respeito as variveis, as classes entre outros.
A gura mostra essa idia a partir da codicao de duas funes em C que copiam um arranjo
de caracteres para outro.
Cdigo 3: Diferentes formas de uma mesma soluo.
01. //funo para replicar uma Strings usando ponteiro
02. void copyWithPointer(char *d, const char *s){
03. while (*d++=*s++);
04. }
05. //a mesma funo porm sem ponteiros
06. void copyWithoutPointer(char d[], const char s[]){
07. int i;
08. for(i=0;s[i]!=\0;i++)
09. {
10. d[i]=s[i];
11. }
12. d[i]=\0;
13. }
Figura 5.8: Duas funes na linguagem C que expressam a mesma inteno. Adaptao de
Buschmann et al. [BUS 1996].
A funo da linha dois utiliza ponteiros, enquanto que a da linha seis usa um arranjo propri-
amente dito. Para formar um padro idiomtico deve-se escolher uma dessas formas de imple-
mentao. Assim, pessoas de diferentes graus de entendimento em programao acostumam-se
mais rapidamente a um cdigo estranho.
O grande problema que pode vir a ocorrer quando da utilizao desses padres refere-se a
portabilidade de cdigo. fcil entender isso, pois se um componente escrito utilizando recur-
sos STL da linguagem C++ e h a necessidade de traduzi-lo para Java, possivelmente ele ter de
60
ser reescrito no que se refere aos seus detalhes internos uma vez que Java no tem a mesma abor-
dagem genrica que os gabaritos C++. A abordagem genrica
20
do Java a partir da verso J2SE
1.5 (The Java 2 Platform, Standard Edition) foi projetada apenas para eliminar a necessidade
de casts que so freqentemente utilizados no retorno de algum tipo de dado armazenado em
alguma coleo. J, C++ prov mecanismos mais sosticados para tratar diferentes tipos dados.
Esses mecanismos permitem denir um tipo sem especicar todos os outros tipos implemen-
tados pela linguagem. Essa abordagem foi descrita no captulo 2 e suas implicaes fogem do
contexto dessa dissertao.
Terminada a descrio dos padres de construo existentes e, das particularidades que en-
volvem o desenvolvimento de software no domnio de imagens, o prximo captulo mostra a
aplicao desses conceitos na construo do StoneAge propriamente dito.
20
Maiores informaes podem ser obtidas em: (http://java.sun.com/developer/
technicalArticles/J2SE/generics/)
61
6 STONEAGE: UMA FERRAMENTA JAVA BASEADA EM
COMPONENTES PARA O PROCESSAMENTO DE IMAGENS
Nesse captulo apresentado o framework desenvolvido para controlar os vrios compo-
nentes de software implementados. Esse framework a arquitetura base do sistema e foi con-
cebido atravs da aplicao de determinados padres especicados no captulo 5. Para tal
propsito, primeiramente ser abordado a linguagem de programao utilizada que, no caso,
Java. Posteriormente segue-se uma explicao mais detalhada dos padres utilizados no pro-
cesso de codicao. Paralelo a esse ltimo descrito a operacionalidade do sistema.
6.1 A Linguagem de Programao
Segundo Watt e Findlay [WAT 2004], vrios critrios devem ser utilizados para escolher
uma linguagem de programao. Entre eles: modularidade, reusabilidade, portabilidade, nvel
de abstrao, conabilidade, ecincia, legibilidade, disponibilidade de ferramentas e outros.
Sob essa perspectiva foi identicado no processo de desenvolvimento do StoneAge as seguintes
caractersticas da linguagem escolhida Java:
Java uma linguagem modular pois permite a construo de unidades de compilao o
que muito til para organizar grandes sistemas. Cita-se aqui, o uso dos pacotes Java que
permitem a organizao hierrquica das classes (veja gura 5.6) implementando assim
um link dinmico de compilao entre diferentes partes de um sistema. Esses pacotes so
estruturas de diretrios utilizados para organizar classes e interfaces [DEI 2001a]. Assim,
todos os componentes desenvolvidos nesse trabalho esto inseridos dentro de pacotes.
Dessa forma, h apenas duas classes principais que so as responsveis por gerenciar as
chamadas a esses pacotes. Nesse trabalho, elas receberam intuitivamente o nome de Main
(unidade principal do sistema base) e LitleWindow (unidade principal da interface com
o usurio). Isso muito agradvel para os futuros desenvolvedores pois no se deparam
com uma enxurrada de arquivos relativos as classes do sistema em um nico diretrio.
Java tambm permite o reuso no s de classes, mas como tambm de pacotes inteiros.
Esse aspecto muito explorado nesse trabalho. Todas as classes que j ofereciam uma
determinada soluo foram efetivamente utilizadas. Isso ocorreu na camada de aplicao
62
onde se reutilizava classes do ncleo para resolver um problema maior, quanto para cons-
truir a interface com o usurio onde foi utilizado os pacotes ofertados pelo kit de desen-
volvimento Java.
A linguagem Java tambm portvel. Inclusive essa umas das principais caracters-
ticas dela. Os programas escritos nessa linguagem podem ser movidos de plataforma
operacional sem que haja qualquer modicao em seu cdigo fonte. Isso ocorre porque
ela traduzida por uma mquina virtual que responsvel por abstrair as heterogenei-
dades implementadas pelas diferentes arquiteturas dos sistemas operacionais modernos.
Nesse trabalho foi utilizado como plataforma de trabalho o sistema operacional Windows
XP
1
porm, o sistema desenvolvido pode ser utilizado, a princpio, sob qualquer outra
plataforma cuja mquina virtual devidamente disponibilizada pelo fabricante que, no
caso, a Sun Microsystems.
No que se refere a nvel de abstrao Java apresenta-se sob a forma de alto nvel. Por
exemplo, em Java, o programador no utiliza apontadores de memria. Entretanto, todos
os objetos so acessados atravs de ponteiros, porm isso est escondido na semntica da
linguagem [WAT 2004].
Pelo fato do programador no manipular apontadores de memria explicitamente j pode
ser considerada uma linguagem com um certo grau maior de conabilidade. Ela tambm
possui checagem de erros em tempo de compilao e execuo. Isto , o compilador acusa
o erro que inviabilizou o sucesso na compilao e tambm acusa de forma bem alto nvel
possveis erros em tempo de execuo.
O Java, por ser interpretado, possui uma ecincia menor se comparado com C ou C++.
Dessa forma, para algumas aplicaes cientcas que requerem processamento intensivo
ele pode a no vir a ser adequado. Isso relativo, pois atualmente j esto utilizando Java
para programao paralela, isto , voltada para alto desempenho. Dessa forma, pode-
se utilizar Java para executar aplicaes em aglomerados de computadores atravs da
tecnologia como a de passagem de mensagens. Uma biblioteca Java que implementa
essa tecnologia a JOPI [MOH 2002]. normal muitos desenvolvedores utilizarem o
critrio ecincia para refutar a utilizao de Java. Porm esquecem de analisar as outras
vantagens que ela oferece como o desenvolvimento rpido de interfaces grcas(que pode
ser essencial para sistemas de imagens), suporte para programao web de alto nvel, sua
portabilidade operacional entre outros.
Legibilidade de cdigo algo que depende muito do programador. Porm, como Java
uma linguagem alto nvel o seu cdigo possui uma tendncia a se apresentar legvel e,
dessa forma, torna-se um dos pr-requisitos para a fcil manuteno de cdigo.
1
c 2004 Microsoft Corporation. All rights reserved.(http://www.microsoft.com/)
63
Esse ltimo item diz respeito as ferramentas de auxlio ao desenvolvimento Java atual-
mente existentes. uma vasta quantidade de ferramentas que possibilitam a construo
de cdigo. Entre todas cito as IDEs (Integrated Development Environment) e as ferramen-
tas de documentao de cdigo. As IDEs so ambientes de programao onde possvel
congurar um determinado kit de desenvolvimento Java objetivando receber uma srie
de auxlios como: obter informaes sobre os mtodos e atributos de determinada classe,
conhecer a hierarquia que um objeto possa ter am de integr-lo com outro, obter infor-
maes sobre erros de compilao ou execuo na forma de janelas grcas entre outros.
Nesse trabalho foram utilizados as IDEs Kawa
2
e IntelliJ
3
. J a ferramenta de documenta-
o
4
originria do prprio JDK e permite a documentao interna de um cdigo. Assim,
por exemplo, possvel descrever qual a inteno de um mtodo ou classe e como ele
foi implementado. A partir da, possvel gerar a documentao em formato HTML que
pode, por sua vez, ser automaticamente disponibilizado na internet. Esse processo pode
ser visualizado na gura 6.1.
Cdigo 4: Documentando o mtodo construtor da classe que efetua a equalizao de uma
imagem.
01. /**
02. * Mtodo construtor. Em seu interior executado toda a
03. * operao de equalizao.
04. * @param src O objeto PlanarImage da imagem a ser equalizada.
05. * @return O objeto representativo da imagem equalizada.
06. */
07. public static PlanarImage EqualizeImage(PlanarImage src)
08. {
09. ...
10. }
Figura 6.1: Usando os comentrios de documentao para explicar um componente.
Para a gerao dessa documentao devem ser utilizados comentrios especiais que sero
ignorados pelo compilador, mas utilizados pela ferramenta Javadoc. Eles recebem o nome
de comentrios de documentao e na gura 6.1 podem ser vistos da linha 1 at 6. Eles
iniciam com /** e terminam com */ . As tags Javadoc @param e @return descrevem
respectivamente um parmetro para o mtodo e seu retorno.
2
c 2000 Allaire Corporation. All rights reserved.(http://www.allaire.com/). Essa IDE foi descon-
tinuada, porm pela sua simplicidade e funcioalidade pode ser vista como uma boa opo.
3
c 2000 - 2002 JetBrains, Inc. All rights reserved.(http://www.intellij.com/).
4
c 1994-2004 Sun Microsystems, Inc.(http://java.sun.com/products/jdk/javadoc/index.
html).
64
Assim, mesmo conhecendo alguns dos critrios de avaliao de uma linguagem o contexto
em que ela ser aplicada pode pesar muito. Por exemplo, do que adianta chegar a concluso de
que Java a linguagem que mais se ajusta ao problema se no entanto, nenhum dos desenvolve-
dores possui a experincia necessria para explor-la ? O efeito disso pode ser muito negativo
porque o cdigo dicilmente ser legvel e provavelmente os programadores no conseguiro
seguir um estilo el no que diz respeito a orientao por objetos, pois muitos acabam utilizando
uma viso estruturada. Alm disso, se o fator tempo for importante, isto , no h muito tempo
para obter os conhecimentos necessrios sobre a linguagem pois faz-se necessrio uma resposta
rpida em nvel de programao, dicilmente ela ser utilizada. Assim, a escolha de uma lin-
guagem depende do contexto.
6.2 A Aplicao dos Padres no StoneAge
Na implementao do framework base foram utilizados quatro padres de projeto: o Com-
mand, um idiomtico, o Factory Method e o Strategy.
A idia do sistema base, como foi descrito anteriormente, a de suportar os inmeros com-
ponentes que nele sero agregados. Assim, a medida que o sistema vai crescendo, mais e mais
chamadas a esses componentes devero ser asseguradas por esse framework. Porm, o sistema
pode se tornar muito complexo pois cada uma dessas chamadas naturalmente sero executadas
via interface grca formando assim hierarquias de menus que iro fazer a interao entre o
usurio e os detalhes de implementao de alguma soluo. Dessa forma, para gerenciar essa
complexidade de requisies por parte do usurio foi utilizado o padro de projeto Command.
Esse padro pode ser melhor visualizado pelo modelo estrutural exibido na gura 6.2.
Figura 6.2: As trs classes bsicas do framework StoneAge.
65
Na gura 6.2 pode-se ver o esqueleto do funcionamento do padro Command. A classe
Main representa a classe me onde efetuado a abertura dos arquivos grcos, as informaes
de ajuda do sistema e outras. Toda vez que um arquivo grco aberto essa classe invoca um
objeto da classe LitleWindow que tem por nalidade exibir essa imagem na tela e propor-
cionar todos as operaes at ento desenvolvidas. Assim, a classe LitleWindow comporta-se
como um processo lho capaz de apresentar diferentes comportamentos. E justamente essa
exibilidade que levou a essa modelagem, isto , a partir de um objeto me possvel ter vrios
objetos lhos que representam as vrias imagens que foram carregadas e que, podem apresen-
tar diferentes formas de processamento. Por exemplo,em um objeto lho pode-se realizar o
histograma da imagem enquanto que em outro realizado a operao de binarizao.
Na gura 6.2 essa relao entre as duas classes realizada atravs do mecanismo de agrega-
o. Essa forma de relacionamento se d, segundo as normas da UML, por uma linha onde uma
das extremidades possui uma seta que aponta para a classe que est sendo instanciada, e na outra
por um diamante que representa a classe agregadora. Porm, essa ainda no a idia central
do padro Command. O seu ncleo de operao implementado pela interface chamada, nesse
trabalho, de CommandInterface .
Quando um sistema cresce muitas opes de funcionamento podem ser requisitadas via
interface grca. Em Java, normalmente esse processo inteiramente gerenciado pelo mtodo
actionPerformed e do objeto ActionEvent . Esse mtodo controla as requisies feitas
pelo usurio como, por exemplo, um click em um boto que ser seguido pela chamada de
algum outro mtodo. Veja na gura 6.3 como isso ocorre.
Cdigo 5: Controlando requisies do usurio via Interface Grca.
01. public void actionPerformed(ActionEvent w) {
02. String opcao = w.getActionCommand();
03. if (opcao.equals("open")){
04. open();
05. }
06. if (opcao.equals("close")){
07. close();
08. }
09. ...
10. }
Figura 6.3: Como feito o controle das chamadas dos mtodos por componentes grcos.
A palavra open e close da linha 3 e 6 representam o identicador de determinados compo-
nentes grcos especicados pelo programador. Entretanto, infelizmente, em um sistema que
apresenta muitas operaes esse mtodo caria sobrecarregado alm do que, a mesma classe
onde esse mtodo implementado possivelmente tambm abrigar todos os mtodos que im-
66
plementam as mais distintas operaes. Essa uma forma possvel e funcional, porm nada
legvel e portanto, de difcil manuteno.
Para resolver este problema, utilizado uma abordagem mais modular. Cada componente
grco, que requisita alguma operao, implementado como uma nova classe. Cada uma
dessas classes herda as caractersticas de uma interface publica chamada CommandInterFace
que o objeto Command propriamente dito. A gura 6.4 expe de maneira mais clara essa
soluo.
Cdigo 6: Manipulando requisies do usurio de forma mais elegante.
01. //especificao do objeto Command em um arquivo
02. public interface CommandInterFace {
03. public void ExecuteAction();
04. }
05. //invocando o objeto Command na Main
06. public void actionPerformed(ActionEvent e){
07. CommandInterFace obj = (CommandInterFace)e.getSource();
08. obj.ExecuteAction();
09. }
10. //Classe alusiva a um componente grfico interno a classe Main
11. class ListenOpenFile extends JMenuItem
12. implements CommandInterFace{
13. public void ExecuteAction(){
14. open();
15. }
16. }
17. ...
Figura 6.4: Uma alternativa de controle mais legvel.
Na linha 5 da gura 6.4 pode-se ver que o mtodo CommandInterFace cou reduzido
a quatro linhas. No s nesse caso ele sofreu essa reduo, isto , ele sempre manter essa
caracterstica constante. Atravs da especicao da interface Command todas as classes criadas
como a da linha 11 que tem a inteno de prover um item grco para abrir uma imagem de
arquivo, tero emseu interior o mesmo nome do mtodo presente emCommandInterFace, isto
, ExecuteAction() porm com diferentes implementaes. Com isso possvel desacoplar
o objeto que invoca a operao daquele que tem o conhecimento para execut-la [GAM 2000].
A principal desvantagem desse padro a proliferao de pequenas classes [COO 1998].
Porm, essa desvantagem no representa um risco para o sistema, pelo simples fato de que o as-
pecto organizacional alcanado pelo padro Command muito grande. Qualquer alterao em
algum componente grco pode ser facilmente realizada pois basta encontrar a sua classe e efe-
tuar as mudanas necessrias semmexer no resto do cdigo. Por exemplo, se a classe da linha 11
necessitar mudar sua nalidade bastaria entrar dentro do seu mtodo ExecuteAction() e al-
67
terar a chamada do mtodo open()para outro qualquer. Para ns de simplicao dentro dessas
pequenas classes foram invocados mtodos locais. Entretanto, na maioria dos casos, acontece o
instanciamento dos objetos principais dos componentes que esto alocados em unidades do tipo
pacote. Com a inteno de deixar essa idia clara, a gura 6.5 mostra como esse processo se
desenvolve.
Figura 6.5: Uma viso mais completa da estruturao do sistema base segundo o padro de
projeto de controle denominado de Command.
Na gura 6.5 todas as classes agregadas por LitleWindow so componentes grcos.
Nessa gura, para ns de simplicao, so mostrados alguns desses componentes como o
ListenImageSegmentation (que um item de menu que controla o processo de segmen-
tao), ListenImageAnalysis( um item de menu global que executa a anlise de imagem),
ListenEdit (item de menu global de edio) e , ListenUndo (item de menu que possibilita
voltar ao ltimo estado da imagem processada) . Esses componentes, por sua vez, agregam
os componentes que esto organizados em pacotes distintos como anteriormente descrito. Na
gura 6.5 isso ocorre com o componente de realce de bordas representado pela sua classe princi-
pal chamada de SegmentationGUIque instanciada quando o usurio invoca o item de menu
grco representado pela classe ListenImageSegmentation. Assim, cria-se uma espcie de
metodologia de desenvolvimento onde, os programadores habituam-se facilmente com o cdigo
do sistema possibilitando que o mesmo cresa a partir do desenvolvimento colaborativo. Isso
muito til em um grupo de pesquisa que, normalmente, possui como caracterstica o dinamismo
de desenvolvimento, isto , o quadro de programadores de tempos em tempos se renova.
68
Sublinha-se que a criao de ambas as classes Main e LitleWindow no uma especi-
cao do padro de projeto Command. Na verdade ambas se utilizam desse padro entretanto,
sua implementao foi assim construda para gerenciar melhor as imagens que so utilizadas.
Para isso a classe me apenas gerencia a entrada de dados e outras especicaes do sistema en-
quanto que a classe lha (LitleWindow) trata toda nova imagem como um objeto distinto. O
processamento realizado em uma imagem autnomo, no ocorrendo problemas quando vrias
imagens so abertas. A gura 6.6 mostra esse processo em ao atravs da primeira interface
construda para o StoneAge.
Figura 6.6: A primeira interface j funcional do StoneAge.
O outro padro utilizado nesse trabalho tem a inteno de guardar as imagens processadas
am de recuper-las posteriormente. o que as operaes usualmente conhecidas como Undo
(voltar) e Redo (avanar) implementam. Segundo Steven J. Metsker, [MET 2002], a dura-
bilidade desse armazenamento pode ser de momento, horas, dias ou anos. Dessa maneira, a
primeira forma de implementao pensada foi o padro memento(recordao) descrito no cap-
tulo 5. Ele pode ser muito til pois todos os detalhes de uma possvel manipulao de arquivo ou
at mesmo base de dados podem ser escondidos dentro de uma classe que ser posteriormente
agregada a classe LitleWindow . Entretanto, no h muito sentido prtico em armazenar o
estado parcial das imagens processadas em arquivo ou banco de dados. Usualmente essa ca-
racterstica momentnea, isto , existe apenas na memria voltil do computador enquanto o
69
sistema est sendo executado. Isso ocorre com os sistemas citados na seo 4.3.
Porm, sabendo que cada imagem vista como umobjeto do tipo PlanarImageconseguiu-
se facilmente armazen-la utilizando uma estrutura do tipo coleo. Essa estrutura provida
pela linguagem Java podendo ser considerada, portanto, um padro idiomtico. Essa coleo
o objeto Vector que tem a mesma idia de uma vetor unidimensional primitivo porm, em cada
um dos seus ndices ele capaz de armazenar objetos inteiros. Essa implementao resolve o
problema do armazenamento temporrio de imagens. A nvel de estruturas de dados ele opera
como uma lista. Cada imagem aberta adicionada nessa estrutura e quando o usurio precisa
de algum processamento anteriormente realizado, ele apenas vai navegando pelos ndices dessa
lista. No cdigo da gura 6.7 pode ser visto como simples a manipulao desse objeto.
Cdigo 7: A coleo Vector para armazenar imagens
01. //este vector guarda a imagem e suas variaes
02. Vector storeImageProcessed = new Vector();
03. //armazenando a imagem
04. storeImageProcessed.add((PlanarImage)src);
05. //retornando uma imagem da coleo
06. PlanarImage src =
07. (PlanarImage)storeImageProcessed.elementAt(posProcessed);
Figura 6.7: A coleo Vector utilizada para resolver o problema da operao undo.
Na linha 2 da gura 6.7 ocorre o instanciamento da classe Vector. Na linha 4 a imagem
adicionada na ltima posio desse vetor de objetos. A imagem representada pelo objeto
src . Nas linhas 6 e 7 ocorre a recuperao de um determinado objeto imagem de acordo com
seu ndice posProcessed . Toda vez que uma operao Undo requisitada pelo usurio esse
gerenciador de ndices (que uma varivel inteira) tem seu valor decrementado. O contrrio
acontece com a operao de Redo, isto , essa varivel sofre um incremento unitrio. Porm,
em ambas deve ser controlado o limite superior e inferior dessa coleo uma vez que, esse vetor
possui um incio e um m. Uma vantagem muito grande dessa coleo que ela possui um
crescimento incremental, isto , ela cresce conforme a necessidade. Ao contrrio de um objeto
do tipo array primitivo que obriga a alocao de um nmero especicado de ndices(tamanho)
no momento da sua criao, a classe Vector
5
aloca um novo espao apenas quando necessrio.
Signica dizer que, se uma imagem foi alterada trs vezes, h apenas trs ndices nessa coleo,
de zero a dois. Assim, toda vez que uma imagem previamente aberta sofre algumprocessamento
ela automaticamente armazenada na ltima posio dessa estrutura dinmica. A primeira
posio sempre guarda a imagem original. Segundo Deitel e Deitel [DEI 2001a], essas colees
oferecidas pelo Java permitem ao programador utilizar estruturas de dados como listas(como no
5
Pertencente ao pacote java.util a partir da verso dois do Java(1.2).
70
caso do Undo e Redo), pilhas, las e rvores sem reinventar a roda.
Para nalizar a utilizao desse padro idiomtico de recordao, sublinha-se que, poderia
ser utilizado o padro de projeto Iterator explicado no captulo 5 para ns de gerenciar o acesso
seqencial a essa coleo. Entretanto, isso apenas agregaria complexidade ao sistema pois a
criao de um objeto para esse m pode ser intuitivamente substitudo por um simples contador.
A gura 6.8 mostra a utilizao desse objeto dinmico de uma forma mais simples.
Figura 6.8: As operaes de Undo e Redo sob a perspectiva de um padro idiomtico.
Esse objeto Vector tambm existe em C++, sob a denominao mais usual de continer.
Assim como no Java ele tambm serve para guardar objetos e, tambm implementa operaes
que facilitam o seu uso como os mtodos de armazenamento e recuperao dos objetos nele
contidos.
O outro padro utilizado foi o Factory Method associado com o Strategy. Ambos foram uti-
lizados para implementar as operaes de Save e Save As . Essas operaes so fundamentais
pois atravs delas conseguido persistir a informao por algummecanismo de armazenamento.
No StoneAge essa informao guardada em arquivos grcos. Dentre esses h a possibilidade
de manipular arquivos com extenso JPEG/JPG
6
, TIFF
6
, BMP
6
PBM
6
e PNG
6
. No entanto,
mesmo a biblioteca JAI oferecendo os codecs para a abertura e construo desses arquivos
eles devem ser utilizados de forma a seguirem as normas da legibilidade. Essas duas operaes
6
JPEG/JPG: Joint Photographic Experts Group (http://www.jpeg.org/); TIFF: Tag Image
File Format (http://partners.adobe.com/public/developer/tiff/); BMP: Windows
Bitmap Format(http://www.microsoft.com/) ; PBM: Portable Bit Map; PNG: Portable Network
Graphics.(www.w3.org/Graphics/PNG/).
71
tem por nalidade salvar o arquivo aberto utilizando uma mesma extenso e salvar uma ima-
gem inserida em um arquivo grco em uma extenso diferente da original. Por exemplo, se a
imagem carregada possui a extenso PNG a operao Save As permite que ela seja salva, por
exemplo, com extenso JPEG.
Para solucionar esse problema foi projetado a soluo apresentada pela gura 6.9.
Figura 6.9: A modelagem UML das operaes Save e Save As .
Na gura 6.9, o padro Factory Method representado pela classe base Save e pelas classes
concretas SaveJPG, SaveBMP, SavePNG, SaveTIFF e SavePBM . Como descrito no captulo
5, esse padro Gamma utilizado quando h a necessidade de retornar algum objeto concreto
mediante determinada situao. No caso da operao de armazenamento o seu uso bastante
claro pois o sistema retorna apenas o objeto relativo ao arquivo grco ltrado pelo usurio. No
h lgica em retornar o objeto SaveTIFF e SavePNG se o usurio optou salvar em formato
TIFF. Obviamente isso ocorre porque no h lgica em salvar um arquivo grco com duas
extenses uma vez que os sistemas operacionais mais usuais no o reconheceriam. Assim, no
interior de cada classe concreta de Save est escondido a complexidade referente aos codecs
para ns de interpretao dos arquivos grcos. Dessa forma, qualquer necessidade de mudana,
seja por algum bug ou at mesmo a agregao de um novo formato basta reportar-se a essa
hierarquia de sub-classes. Essa uma grande vantagem dessa modelagem com classes abstratas,
pois cada uma das classes apresentadas na gura 6.9 est dentro de um arquivo prprio. Assim,
na necessidade de codicao de um novo codec basta copiar a estrutura de qualquer um
72
dos j existentes alterando apenas a sua lgica interna e seu escopo (nome da classe). No h
necessidade de mudar nada na classe me e nada nas classes irms.
No entanto, s a implementao do padro Factory Method no garante a funcionalidade
da operao em questo. Alm da necessidade de criar uma organizao de objetos falta es-
pecicar a fbrica propriamente dita, isto , quem vai executar a chamada para determinada
classe concreta. Para isso se deve ter em mente que cada classe lha implementa um algoritmo
distinto mediante um mesmo escopo de operao. Nesse contexto, para gerenciar qual algo-
ritmo deve ser invocado, foi utilizado o padro de projeto comportamental Strategy. A inteno
desse padro pode ser deduzida do seu prprio nome, isto , escolher qual estratgia(que o
algoritmo) deve-se utilizar. No entanto, essa estratgia deve ser exclusiva, isto , ou invoca
o algoritmo de SaveTIFF ou de SaveBMP. Para tal nalidade, o padro Strategy encapsula
em seu interior a denio de uma famlia de algoritmos de forma que sejam intercambiveis
[GAM 2000]. Segundo James W. Cooper, [COO 1998], esse padro tambm muito utilizado
para comprimir arquivos utilizando diferentes algoritmos, capturar video utilizando diferentes
esquemas de compresso e outros. Ele tambm muito til para abstrair a estrutura de classes
do padro Factory Method, isto , a classe LitleWindow(que controla a escolha do usurio por
salvar emdeterminado arquivo grco) se preocupa apenas empassar os argumentos necessrios
para o objeto Strategy que por sua vez se responsabiliza por invocar a implementao de deter-
minado algoritmo situado nas classes mais baixas. Esses dois padres esto armazenados em
um pacote chamado save, o que muito positivo pois as classes pertencentes a essa operao
de armazenamento fsico cam separadas das classes bsicas do sistema. Mais uma vez, a mo-
dularidade oferecida pelos padres acaba oferecendo uma certa organizao ao sistema como
um todo. Salienta-se tambm que, tanto a operao de Save quanto Save As implemen-
tada utilizando a mesma estrutura apresentada na gura 6.9. Tudo vai depender do argumento
passado para o objeto Strategy que gerencia os algoritmos. Se o usurio abrir uma imagem de
um arquivo JPG e invocar o mtodo Save As do menu de opes e aps isso decidir que deseja
salvar a imagem com outra extenso, o objeto Strategy em conjunto com a classe abstrata Save
gerenciar essa operao.
Assim, a aplicao dos padres na construo do StoneAge possibilita gerenciar melhor a
complexidade dos futuros componentes que sero agregados. No prximo captulo, apresen-
tado a construo de um componente de segmentao, que tambm se baseia em padres, e
como ele preparado para ser inserido no StoneAge.
73
7 APLICAO: UM COMPONENTE PARA SEGMENTAO
DE IMAGENS BASEADO EM FILTROS DE CONVOLUO
O objetivo desse captulo
1
demonstrar a aplicao dos padres de projeto na construo
de um componente para segmentao de imagens digitais baseado em contornos. Para isso
ser explicado primeiramente o processo de segmentao utilizado e depois a viso de projeto
estrutural do componente.
7.1 O processo de segmentao
Segmentao de imagens o processo pelo qual se particiona uma imagem em um con-
junto de regies uniformes colocando-as em primeiro ou segundo plano conforme o objeto de
interesse [RIT 2000], [RUS 1998]. Esse processo, tpico de sistemas de viso computacional,
baseia-se na propriedades dos pixels que formam a imagem, isto , a intensidade que cada um
apresenta em sua respectiva banda. Dessa forma, em uma imagem com valores de pixels no
intervalo entre 0 e 255 a borda detectada quando h mudanas bruscas nos nveis de cinza,
ou seja, em sua magnitude. Segundo Gonzalez e Woods, [GON 2000], essa uma abordagem
baseada na descontinuidade que, por sua vez, precisa ser complementada por um processo tam-
bm de segmentao conhecido como binarizao. Esse ltimo passo, tambm conhecido como
limiarizao ou thresholding, faz-se necessrio para identicar de forma mais consistente as
bordas aproximando-se ao mximo do contorno da imagem.
Nesse trabalho, a deteco de bordas foi aplicado s imagens de banda simples, necessitando
assim, que o aplicativo desenvolvido execute a converso da imagem captada, que por sua vez
possui um modelo de cores baseado em trs bandas, isto , RGB para o modelo monocromtico,
ou seja, cinza.
Segundo Ritter & Wilson [RIT 2000], uma grande variedade de tcnicas so usadas para
computar as bordas de uma imagem. Dentre elas, utilizou-se a tcnica da transformada que
aproxima o gradiente que, segundo Gonzalez e Woods, [GON 2000] o mtodo mais comum de
diferenciao emaplicaes de processamento de imagens. Para isso, so utilizados mscaras ou
kernels de convoluo que recebem essa denominao porque operam unicamente no domnio
1
Esse captulo baseia-se no trabalho publicado no XXIV Encontro Nacional de Engenharia de Produo,
[WEL 2004]
74
do espao. Para a deteco dessas bordas duas convolues so necessrias na imagem original.
A primeira operao de convoluo detecta as bordas na direo horizontal e a segunda na
direo vertical, formando assim, as bases do subespao de bordas. Dentre as mscaras que
existem foi implementado a de Frei e Chen pois foi a que apresentou melhor resultado. Na
gura 7.1, demonstrado essa mscara de convoluo na forma de arranjo bidimensional.
Figura 7.1: O kernel de convoluo utilizado: a ) ltro vertical e b ) ltro horizontal de Frei e
Chen.
Observe na gura 7.1 que todos os coecientes apresentam um somatrio nulo, o que sig-
nica dizer que em reas constantes a resposta ser nula ocorrendo assim a diferenciao entre
as regies [RIT 2000]. Aps a aplicao dessas mscaras, aplica-se um limiar ou thresholding
global sob a imagem segmentada para denir claramente o que borda do que plano de fundo.
Esse um passo bastante conveniente uma vez que o algoritmo de Frei e Chen no consegue
denir valores constantes e exclusivos para essas duas ocorrncias [RIT 2000]. Dessa forma,
com a limiarizao foi conseguido uma imagem binria cujo plano de fundo apresentava valor 0
e as bordas valor 1. Assim, para a imagem f(x,y), seu limiar T(x,y) foi encontrado como mostra
a equao da gura 7.2:
T(x,y) =

0 se f(x, y) < k
1 se f(x, y) k
Figura 7.2: Modelo Algbrico para encontrar o Thresholding, onde k o limite especicado
pelo usurio.
Esse processo de segmentao foi utilizado em imagens de componentes industriais. A idia
era detectar os contornos dessas peas e gerar um arquivo texto contendo as coordenadas espa-
ciais dessas bordas. Atravs desse arquivo a pea pode ser reconstruda em ambiente assistido
por computador Autocad
2
. A gura 7.3 demonstra a parte de processamento de imagens desse
trabalho. Sublinha-se que, a imagem original antes de ser convertida para tons de cinza sofreu o
2
c 2004 Autodesk, Inc. All rights reserved. (http://www.autodesk.com/).
75
processo de equalizao para ns de melhorar a distribuio da sua luminosidade e, conseqen-
temente tornar mais ntida suas bordas.
Figura 7.3: As vrias etapas necessrias para detectar a borda.
7.2 Os padres utilizados para projetar o componente
De conhecimento da tcnica no que diz respeito ao processamento de imagens necessrio
para esse tipo de segmentao, foi feito ento a modelagem de software para ns de codicao
posterior. Para isso, foram utilizados quatro padres de construo Gamma: Builder, Template
Method, Strategy e Command.
O padro Command mais uma vez foi utilizado para prover o controle necessrio para geren-
ciar o componente. Porm ele no teve que ser implementado, isto , o componente se utiliza
da estrutura de controle j implementada nas classes bases do sistema. Em outras palavras,
a mesma interface de comando CommandInterFace serviu para gerenciar as requisies dos
usurios desse componente via interface grca.
O padro Strategy foi utilizado de forma anloga ao problema do armazenamento de ima-
gens descrito no captulo anterior. Porm agora, em vez de gerenciar os algoritmos responsveis
por implementar determinado tipo de arquivo grco, ele implementa as vrias opes de ms-
caras de realce de bordas anteriormente citadas na seo anterior como Prewit, Frei and Chen,
Sobel e Roberts. Isso , esse padro est fazendo o papel da fbrica onde ocorre a manufatura
de determinado objeto e que, por sua vez, apresentam responsabilidades distintas. Porm, nesse
componente foi utilizado uma variante do padro Factory Method para manufaturar os objetos.
Esse padro o Builder.
O padro Builder, assim como o Factory Method, tambm retorna um objeto a partir de uma
dada requisio. Porm ele possui a vantagem de construir esse objeto a ser retornado de forma
mais modular, isto , passo-a-passo. Outra vantagem que, o objeto complexo que est sendo
construdo ca separado do seu processo de composio.
Antes de usar esse padro de projeto necessrio enfatizar trs aspectos essenciais no que
76
diz respeito a eccia desse componente:
1. H diferentes ltros de realce. Assim, o projeto do componente deve permitir que o
usurio possa escolher dinamicamente qual dessas mscaras ser utilizada;
2. S escolher qual o ltro utilizar no basta. O Componente tambm deve oferecer di-
ferentes tamanhos para essas mscaras. Normalmente, na literatura, elas so 3x3 ou 8
conectado (como a gura 7.1), mas tambm a literatura descreve como possibilidade de
uso mscaras de tamanho 5x5 e 7x7. Assim, possvel ter um mesmo algoritmo operando
sob diferentes tamanhos de mscaras.
3. Aps escolhida a mscara faz-se necessrio ainda executar a operao de convoluo
propriamente dita. Para isso j se deve ter decidido o nome do ltro e seu tamanho.
Nessa etapa de convoluo so utilizadas as mscaras horizontais e verticais escolhidas
anteriormente.
Nesse contexto, a principal vantagem do padro de criao Builder na implementao desse
componente , justamente gerenciar essas vrias partes necessrias para compor um objeto. Sua
congurao estrutural mostrada na gura 7.4.
Figura 7.4: O modelo estrutural do padro Builder. O objeto Image o produto que est sendo
construdo.
O padro Builder representado pela gura 7.4 possui um nvel a mais que o Factory Method.
A classe EdgeDetection uma classe abstrata que tem como funo abrigar diferentes
implementaes de ltros segundo um mesmo escopo de operao. Suas classes bases so
RobertsSegmentation(que implementa o ltro de Roberts), SobelSegmentation(que
implementa o ltro de Sobel), PrewittSegmentation e FreiAndChenSegmentation.
Cada uma dessas classes possui o mtodo makeMask() que tem como parmetro de entrada o
tamanho da mscara que o usurio optou em utilizar e o mtodo makeSegmentation() que
77
tem como parmetro de entrada o valor do limiar escolhido e como valor de retorno a imagem
j segmentada. Ambas operaes so abstratas e surgem nas sub-classes porm com valores
diferentes no que se refere a sua mscara. A primeira operao constri a mscara tomando
como base seu tamanho e a segunda realiza a operao de convoluo e depois de binarizao.
A classe Image representa o produto complexo que se est querendo produzir (que no caso
a imagem segmentada). A classe Director faz parte da especicao do padro Builder e
a responsvel por invocar todos os mtodos das classes lhas em um nico mtodo chamado
Constructor .
A classe Image recebe a imagem a ser segmentada do sistema base. essa imagem original
que se transformar no produto nal. Por isso que ela possui uma relao de dependncia
entre as classes lhas e com uma das classes base do StoneAge chamada LitleWindow . As
classes lhas dependem do produto nal pois, este, em seu estado inicial, carrega a imagem a
ser processada pela lgica algortmica contida no interior dessas classes concretas. J o produto
nal depende da classe base do sistema porque esse ltimo que prov a imagem propriamente
dita. A gura 7.5 mostra o projeto completo do componente e como ele se integra com a classe
base do sistema via interface grca provida pelo objeto SegmentationGUI e com a classe
que gerencia a chamada dos algoritmos denominada de Strategy .
Figura 7.5: A viso de projeto completa do componente de segmentao baseado em mscaras.
O ltimo padro utilizado no desenvolvimento desse componente foi o Template Method.
Como descrito no captulo 5 esse padro tem a inteno de prover um mtodo modelo para
vrios objetos. Para o processo de segmentao ocorrer no basta apenas aplicar ltros de con-
voluo. necessrio ainda tratar a imagem de entrada e tambm complementar o processo
de realce dos ltros pelo processo de binarizao. Se a imagem que se est intencionando seg-
mentar for RGB (usualmente conhecidas como multiespectral ou colorida) o componente de
78
segmentao deve convert-la para tons de cinza, uma vez que mais simples operar sob esse
tipo de imagem alm de ser pr-requisito para o processo de limiarizao futura. De outro lado,
aps a aplicao de determinada mscara utilizado o processo de binarizao (thresholding)
para garantir a excluso dos pixels que pertencem a borda daqueles que no pertencem, isto ,
o fundo da imagem. Assim, cada classe concreta de EdgeDetection deve implementar ambas
funcionalidades para garantir a eccia do componente. No entanto, como a lgica de ambas
operaes se mantm igual independente da classe concreta onde est implementada, possvel
trat-las de uma forma mais elegante. Para isso, basta implementar esses mtodos na prpria
classe abstrata (usualmente chamada de me) e apenas cham-los quando for conveniente nas
classes lhas. Assim, evita-se replicao de cdigo nas classes concretas (comumente chamada
de lhas). Assim, esses mtodos se tornam modelos justicando assim o seu nome pela litera-
tura.
A gura 7.6 mostra a interface grca desse componente. Essa interface corresponde a
classe SegmentationGUI da gura 7.5.
Figura 7.6: A interface grca do componente de segmentao baseado em contornos.
Muitas operaes em processamento de imagens se baseiam na aplicao de ltros. Dessa
forma, a utilizao desses quatro padres, especialmente pelo Builder que d o suporte central
ao componente, podem ser visto com muita utilidade no desenvolvimento de software para ima-
gens. Um bom exemplo a utilizao desses padres para construir um componente para mor-
fologia binria
3
, onde o elemento estruturante apresenta diferentes formatos e tamanhos. Assim
3
Compreende o estudo da estrutura geomtrica de imagens binrias, isto , aquelas compostas por pixels de
valores zeros e uns.
79
pode-se utilizar o padro Builder para construir passo-a-passo toda a representao necessria
para implementar um objeto que representa o elemento estruturante para, posteriormente utiliz-
lo em operaes de dilatao, eroso, abertura, fechamento e outras. Em nvel de aplicao esse
componente se segmentao baseado em contornos pode ser visto como um pr-requisito para
um componente de morfologia binria pois, o alvo de estudo dessa parte de morfologia so
imagens binrias que por sua vez so o resultado nal desse componente de segmentao. As-
sim, tambm a nvel de funcionalidade um componente acaba ajudando o outro na resoluo de
algum problema.
80
8 CONCLUSO
Os objetivos de construir um software independente de plataforma, de cdigo-livre e de
componentes adaptveis para o processamento e anlise de imagens foram cumpridos. Assim,
o StoneAge, no considerado uma bola de lama pois na sua construo foram aplicados
preceitos de engenharia de software avanada, ou seja, os padres de construo. No entanto,
apenas com o decorrer dos anos ser possvel avaliar se o ciclo de vida do StoneAge foi capaz de
dar suporte para as vrias aplicaes do grupo de pesquisa, isto , se ele realmente apresentou
caractersticas como fcil manuteno, legibilidade de cdigo e reuso.
Porm, na implementao do sistema e dos componentes desse trabalho a experincia mostrou
que os padres propiciaram formas comprovadamente timas de gerenciar a complexidade de
um componente am de torn-lo modular e exvel para ns de reuso. Por exemplo, a apli-
cao do padro Factory Method descrito no captulo 5 para gerenciar as vrias formas de ar-
mazenamento de imagens em arquivos grcos. Esse padro possibilita uma maneira modular
de codicao porque cada classe concreta da sua estrutura encapsula uma lgica diferente sob
um mesmo nome de operao. Assim, todas essas classes lhas possuem o escopo de mto-
dos comum o que assegura maior facilidade de interpretao pelos novos desenvolvedores, uma
vez que, mediante a necessidade de alguma alterao ou criao de nova classe concreta basta
basear-se elmente nas que j existem, isto , nas suas irms. O padro Strategy tambm apre-
senta bons resultados pois no apenas serviu para encapsular os detalhes da invocao de de-
terminado algoritmo, mas como tambm o responsvel pela gerncia de todo o componente.
Isso muito positivo porque para o sistema base invocar um determinado componente basta
instanciar o objeto que representa o padro Strategy. Toda a complexidade do componente ca
escondida. Esse processo pode ser visto na gura 7.5 e 6.9. Em outras palavras, a comunicao
entre um determinado componente e as classes bases do sistema realizada quase que total-
mente atravs do padro Strategy. Isso ocorre quando se utiliza o padro Builder onde tambm
necessrio o sistema base passar a imagem a ser construda para a classe que representa o
produto nal. Porm, no h necessidade de agregao pois essa passagem feita diretamente
para o atributo que representa a imagem dessa classe de forma esttica.
Outro resultado observado diz respeito a escalabilidade do sistema. Nas primeiras verses
do sistema no havia muitos componentes agregados e sua funcionalidade ainda era bastante
restrita. Mesmo assim, nesses estgios iniciais j eram utilizados padres de construo. No
81
entanto, eles s comearam a realmente demonstrar os seus benefcios a partir do momento em
que o sistema foi crescendo no que diz respeito as suas funcionalidades. Assim, a avaliao
dessa dissertao no se encerra aqui, mas se dar ao longo do desenvolvimento dos projetos
de pesquisa. O padro Command propiciou regras de controle para o gerenciamento de toda a
interface grca do sistema base e dos componentes. Qualquer modicao ou agregao de
novos componentes grcos basta seguir um modelo onde todos esses componentes so consi-
derados como classes isoladas que contm operaes comuns porm com diferentes implemen-
taes. Assim, quando o sistema foi se tornando grande e, conseqentemente a sua interface
grca tambm, a principal vantagem oferecida pelo padro Command foi a forma com que ele
gerenciou a complexidade resultante da associao entre componentes grcos e requisio de
componentes. Essa associao ocorre porque cada componente grco executa uma ao que
invoca determinada lgica que est presente em um componente e que, por sua vez, est alocado
em um pacote distinto.
O padro arquitetural Layer permitiu construir um cdigo bastante enxuto, porm funcional.
Isso foi muito visvel na implementao da camada de aplicao. Muitas operaes no precisa-
ram ser reimplementadas, isto , elas apenas foram usadas. Assim, no houve uma mistura entre
servios bsicos com a lgica de montagem de um componente. Por exemplo, para construir o
componente de segmentao no foi necessrio criar uma estrutura para realizar a convoluo
da mscara na imagem pois o ncleo j a implementa. Assimtambm possvel criar aplicaes
com um nmero reduzido de linhas de cdigo.
A utilizao dos padres idiomticos podem ser vistos como um mecanismo para resolver
um determinado problema utilizando exclusivamente caractersticas da linguagem de progra-
mao. No entanto, necessrio ter um certo grau de conhecimento sobre a linguagem utilizada
para conseguir explor-la melhor. O uso da coleo Vector do Java, garantiu de forma bas-
tante simples as operaes de Undo e Redo para o sistema base. Essas operaes so de extrema
importncia para o StoneAge pois na ocorrncia de alguma modicao no satisfatria na ima-
gem, o usurio pode retroceder ou avanar para uma determinada imagem sem a necessidade de
efetuar a abertura novamente de seu arquivo grco.
A modelagem do sistema e de seus componentes atravs da notao UML e suas ferramen-
tas, propicia ao desenvolvedor a viso necessria para trabalhar a parte mais difcil na concepo
de um sistema. Essa parte o processo de reconhecer, enxergar a aplicao de um determinado
padro para um problema de imagens. Esse problema no incio muito grande, principalmente
no momento de conjugar os vrios padres identicados que compem o componente. E para
esse processo de reconhecimento, necessrio ter conhecimento de todos os padres apontados
pela literatura e, tambm, conhecimento sobre o problema na rea de imagens. Se esses dois
aspectos esto dissociados no possvel efetuar uma boa implementao.
Por m, o trabalho de construir componentes para processamento de imagens requer tanto
conhecimentos sobre engenharia de software no que se refere aos padres, como o conhecimento
necessrio sobre o domnio da aplicao. De posse disso, o ltimo quesito necessrio optar
por uma linguagem de programao que d suporte s estruturas dos padres de construo.
82
REFERNCIAS
[AKR 2003] AKRE, A.; TABIRCA, S. Imaging technologies in java. Kilkenny City, Ireland:
Proceedings of the 2nd international conference on Principles and practice of pro-
gramming in Java, 2003. 159-161p.
[ALE 1977] ALEXANDER, C.; ISHIKAWA, S.; SILVERSTEIN, M. A pattern language.
New York: Oxford University, 1977.
[ALE 1979] ALEXANDER, C. The timeless way of building. [S.l.]: Oxford University Press,
1979.
[ARM 2003] ARMOUR, P. G. The laws of software process: a new model for the production
and management of software. [S.l.]: CRC Press LLC, 2003.
[BOO 1999] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The unied modeling language
user guide. [S.l.]: Addison Wesley, 1999.
[BUS 1996] BUSCHMANN, F. et al. Pattern - oriented software architecture: a system of
patterns. New York: John Wiley & Sons Ltd, 1996. v.1.
[CAI 2000] CAI, X. et al. Component-based software engineering: technologies, development
frameworks, and quality assurance schemes. 7th Asia-Pacic Software Engi-
neering Conference (APSEC 2000), p.372 , 2000.
[COA 1993] COAD, P.; NICOLA, J. Object-oriented programming. [S.l.]: Prentice Hall,
1993.
[COO 1998] COOPER, J. W. The design patterns - java companion. [S.l.]: Addison-Wesley,
1998.
[CRN 2002] CRNKOVIC, I.; LARSSON, M. Building reliable component-based software
systems. [S.l.]: Artech House, 2002.
[DEI 2001] DEITEL, H. M.; DEITEL, P. J. C++ como programar. Porto Alegre: Bookman,
2001.
83
[DEI 2001a] DEITEL, H. M.; DEITEL, P. J. Java
TM
como programar. Porto Alegre: Book-
man, 2001.
[DON 2001] DONALDSON, S. E.; SIEGEL, S. G. Successful software development. [S.l.]:
Prentice-Hall, Inc, 2001.
[DOR 2004] DORNELLAS, M. C.; WELFER, D. A generic programming approach for
automatic color image segmentation using cluster homogeneity. Florianpo-
lis, Santa Catarina - Brasil: X International Conference on Industrial Engineering
Management, 2004.
[DOR 2001] DORNELLAS, M. C. Algorithmic patterns for morphological image pro-
cessing. 2001. Tese (Doutorado em Cincia da Computao) University van
Amsterdam.
[DOR 2003] DORNELLAS, M. C. A Parallel Algorithmic Pattern. The Third Latin
American Conference on Patterns Languages of Programmig - SugarLoafPlop-
Porto de Galinhas, PE, 12-15 agosto: [s.n.], 2003. 119-134p. Disponvel em
<http://www.cin.ufpe.br/ sugarloaf/>. Acesso em maio de 2004.
[ECK 1998] ECKSTEIN, R.; LOY, M.; WOOD, D. Java swing. [S.l.]: OReilly, 1998.
[ENG 2000] ENGELS, G.; GROENEWEGEN, L. Object-oriented modeling: a roadmap.
Communications of the ACM, v.43, n.5, p.103116, May 2000.
[FAY 2003] FAYAD, M. E.; HAMZA, H.; RAJAGOPALAN, J. The recovery design pattern.
[S.l.]: The 2003 IEEE International Conference on Information Reuse and Inte-
gration, 2003. 594-600p. Disponvel em: <http://dblp.uni-trier.de>.
Acesso em: dez. 2004.
[FOW 1999] FOWLER, M. Refactoring: improving the design of existing code. [S.l.]:
Addison-Wesley, 1999.
[GAL 2002] GALITZ, W. O. The essential guide to user interface design: an in introduction
to GUI design principles and techniques. second.ed. [S.l.]: John Wiley & Sons,
2002.
[GAM 2000] GAMMA, E. et al. Padres de projeto: solues reutilizveis de software orien-
tado a objetos. Porto Alegre: Bookman, 2000.
[GON 2000] GONZALEZ, R. C.; WOODS, R. E. Processamento de imagens digitais. So
Paulo - Brasil: Edgard Blcher, 2000.
[GOS 2004] GOSLING, J. The mars mission continues. Sun Microsystems, Inc, Disponvel
em: <http://www.sun.com/mars>. Acesso em: abr. 2004.
84
[JOS 1999] JOSUTTIS, N. M. The c++ standard library: a tutorial and reference. [S.l.]:
Addison Wesley, 1999.
[KNU 1999] KNUDSEN, J. JAVA 2d graphics. [S.l.]: OReilly, 1999.
[KOB 1999] KOBRYN, K. UML 2001: a standardization odyssey. Communications of the
ACM, v.42, n.10, p.2937, October 1999.
[LAR 2000] LARMAN, C. Utilizando UML e padres: uma introduo anlise e ao projeto
orientados a objetos. [S.l.]: Bookman, 2000.
[LEA 1993] LEA, D. Christopher alexander: an introduction for object-oriented designers.
Disponvel em: <http://gee.cs.oswego.edu/dl/ca/ca/ca.html> .
Acesso em: abr. 2003.
[MAY 2003] MAY, D.; TAYLOR, P. Knowledge management with patterns. Communications
of the ACM, v.46, n.7, p.9499, 2003.
[MET 2002] METSKER, S. J. Design patterns java workbook. [S.l.]: Addison Wesley, 2002.
[MOH 2002] MOHAMED, N. et al. JOPI: a java object-passing interface. Communications
of the ACM, v.45, n.11, p.37 45, November 2002.
[PET 2001] PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prtica. Rio de
Janeiro: Campus, 2001.
[POP 2003] POPPENDIECK, M.; POPPENDIECK, T. Lean software development: an agile
toolkit. [S.l.]: Addison Wesley, 2003.
[RIT 2000] RITTER, G. X.; WILSON, J. N. Handbook of computer vision algorithms in
image algebra. New York.: CRC Press, 2000.
[RUS 1998] RUSS, J. C. The image processing handbook. [S.l.]: CRC Press, 1998.
[SAL 1997] SALVIANO, C. F. Introduo software patterns. XI SBES, Fortaleza, Cear -
Brasil, p.22, 1997.
[SAN 1995] SANTOS, L. P. P. D. Viso por computador. [S.l.]: Universidade do Minho -
Departamento de Informtica, 1995.
[SHA 2000] SHAPIRO, L.; STOCKMAN, G. TextBook: computer vision. Disponvel em:
< http://web.cps.msu.edu/~stockman/book/>. Acesso em: ago.
2004.
[Sun 1999] Sun Microsystems. Programming in java
TM
advanced imaging - release
1.0.1. [S.l.]: A Sun Microsystems, Inc. Business, 1999. Disponvel em:
<http://java.sun.com/products/java-media/jai/>. Acesso em: abr. 2004.
85
[Sun 2004] Sun Microsystems. Java
TM
APIs for imaging: enterprise-scale, dis-
tributed 2d applications. Disponvel em: <http://java.sun.com/products/java-
media/jai/collateral/datasheet.html>. Acesso em: mar. 2004.
[TOR 2001] TORRES, G. Redes de computadores: curso completo. [S.l.]: Axcel Books,
2001.
[VIT 2003] VITHARANA, P. Risks and challenges of component-based software develop-
ment. Communication of the ACM, v.8, p.6773, August 2003.
[VL 2002] VLTER, M.; SCHMID, A.; WOLFF, E. Server component patterns: compo-
nent infrastructures illustrated with EJB. [S.l.]: John Wiley & Sons, 2002.
[WAT 2004] WATT, D. A.; FINDLAY, W. Programming language design concepts. [S.l.]:
John Wiley & Sons, Ltd, 2004.
[WEI 1999] WEIHE, K. Asoftware engineering perspective on algorithmics. [S.l.]: Fakultt
fr Mathematik und Informatik of Konstanz, Germany, 1999. Research report.
(ISSN 1430-3558).
[WEL 2003] WELFER, D.; BASSO, F. P.; DORNELLAS, M. C. Framework colaborativo
para processamento de imagens utilizando a tecnologia jini. Ouro Preto, Minas
Gerais: ABEPRO - Associao Brasileira de Engenharia de Produo, 2003. 251p.
[WEL 2004] WELFER, D.; SILVA, A. D. D.; DORNELLAS, M. C. Programao de equipa-
mentos CNC atravs da anlise de imagens por segmentao. Florianpolis,
Santa Catarina: [s.n.], 2004. XXIV Encontro Nacional de Engenharia de Produo
e X International Conference on Industrial Engineering Management.