UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA CURSO DE CINCIA DA COMPUTAO

PAROLA: UM FRAMEWORK PARA CONSTRUO DE APLICAES J2SE BASEADAS EM PLUG-INS.

TRABALHO DE GRADUAO

Daniel Michelon De Carli

Santa Maria, RS, Brasil 2009

PAROLA: UM FRAMEWORK PARA CONSTRUO DE APLICAES J2SE BASEADAS EM PLUG-INS.

por

Daniel Michelon De Carli

Trabalho de Graduao apresentado ao Curso de Cincia da Computao da Universidade Federal de Santa Maria (UFSM, RS), como requisito parcial para a obteno do grau de Bacharel em Cincia da Computao

Orientador: Prof. Dr. Marcos Cordeiro dOrnellas (UFSM)

Trabalho de Graduao No 282 Santa Maria, RS, Brasil 2009

Universidade Federal de Santa Maria Centro de Tecnologia Curso de Cincia da Computao

A Comisso Examinadora, abaixo assinada, aprova o Trabalho de Graduao

PAROLA: UM FRAMEWORK PARA CONSTRUO DE APLICAES J2SE BASEADAS EM PLUG-INS. elaborado por Daniel Michelon De Carli como requisito parcial para obteno do grau de Bacharel em Cincia da Computao

COMISSO EXAMINADORA:

Prof. Dr. Marcos Cordeiro dOrnellas (UFSM) (Presidente/Orientador)

Profa . Dra . Lisandra Manzoni Fontoura (UFSM)

Ma . Gabriela Carla Bauermann

Santa Maria, 16 de julho de 2009.

AGRADECIMENTOS

Agradeo acima de tudo a Deus - inteligncia suprema, causa primria de todas as coisas pela vida. Agradeo minha famlia por ser a minha fortaleza nas horas de diculdade, pela educao moral e por buscar me proporcionar uma educao acadmica de excelncia que, com muito esforo, conseguiram. Agradeo minha noiva, Graziele Camargo Kemmerich, pelo carinho, amor e dedicao. Alm disso, por ser incansvel - aprendendo computao - para me auxiliar na reviso deste trabalho. Agradeo a meus colegas da Animati, em especial ao Jean Carlo Berni, pela leitura do presente trabalho e pelas diversas sugestes de melhorias no texto. Agradeo ao meu orientador, por acreditar no meu potencial, bem como pelos momentos de conselho e crticas, que me foram bastante teis na busca de ser melhor prossional. Agradeo aos bons espritos pelo auxlio fraternal, pela induo de boas idias e pela intuio que muito me auxilia. Agradeo aos meus professores, pelo conhecimento e experincia compartilhada, por todo o suporte concedido. Agradeo a todos aqueles que estiveram presentes na minha vida e que de uma forma ou de outra contriburam para a consolidao dessa etapa.

A pessoa , acima de tudo, a sua mente. O que elabora, torna-se; quanto cultiva, experimenta. J OANNA DE NGELIS

RESUMO

Trabalho de Graduao Curso de Cincia da Computao Universidade Federal de Santa Maria PAROLA: UM FRAMEWORK PARA CONSTRUO DE APLICAES J2SE BASEADAS EM PLUG-INS. Autor: Daniel Michelon De Carli Orientador: Prof. Dr. Marcos Cordeiro dOrnellas (UFSM) Local e data da defesa: Santa Maria, 16 de julho de 2009. O Parola um framework para construo de aplicaes de processamento de imagens que atua na construo da interface grca do usurio, controlando os mtodos matemticos e gerenciando as imagens. Os sistemas, que fazem uso da abordagem proposta pelo Parola, recebem novas funcionalidades atravs do desenvolvimento e insero de plug-ins. Os plug-ins so desenvolvidos com maior independncia estrutural que os componentes de software convencionais pois, necessitam conhecer apenas as interfaces dos objetos de fronteira para se comunicarem com o sistema. Dessa forma, o desenvolvedor do plug-ins no precisa conhecer em profundidade a arquitetura do sistema, mas sim as regras bsicas de comunicao entre a plataforma de software e o plug-in. Esse trabalho busca demonstrar o uso de tcnicas de engenharia de software e padres de projeto para a construo de um framework, que implementa o gerenciamento de plug-ins, usando a tecnologia J2SE (Java 2 Platform, Standard Edition).

Palavras-chave: Frameworks, plug-ins, padres de projeto, processamento de imagens.

ABSTRACT

Graduation Work Graduate Program in Computer Science Federal University of Santa Maria PAROLA: A FRAMEWORK FOR CONSTRUCTING J2SE APPLICATIONS BASED ON PLUG-INS. Author: Daniel Michelon De Carli Advisor: Prof. Dr. Marcos Cordeiro dOrnellas (UFSM) Parola is a framework for image processing applications that works by constructing graphical user interfaces, controlling the mathematical methods and managing images. Systems built by the Parola approach receive new features by developing and installing plug-ins. Plug-ins are created with more structural independence than traditional software components, because they just need to know the border objects to communicate with the system. Thus, the plug-ins developers dont need profound knowledge regarding the systems architecture, but they do need to know the basic rules for communication between the software platform and the plug-in. This work demonstrates the use of some software engineering techniques and design patterns to construct a framework for managing plugins using the J2SE (Java 2 Platform, Standard Edition) technology.

Keywords: Frameworks, plug-ins, design patterns, image processing.

LISTA DE FIGURAS

Figura 2.1 Os trs personagens do processo de componentizao segundo Padmal Vitharana (VITHARANA, 2003) apud (WELFER, 2004).(Fonte WELFER, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.2 Diagrama de classes do padro Observer. . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 2.3 Diagrama de Classes do Padro DAO.(Fonte SUN, 2002) . . . . . . . . . . . . Figura 2.4 Tecnologias Java.(Fonte SUN, 2009b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 3.1 Plug-ins habilitados ou desabilitados conforme o tipo da imagem em foco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 3.2 Diagrama De Classes do Parola - Simplicado. . . . . . . . . . . . . . . . . . . . . . Figura 3.3 Diagrama de Classe de Domnio (Pacote Model). . . . . . . . . . . . . . . . . . . . . Figura 3.4 Diagrama de Classe - Classes que se comunicam diretamente com os plug-ins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figura 3.5 Camadas de comunicao - objetos de fronteira e plug-ins. . . . . . . . . . . . Figura 3.6 Diagrama de sequncia: Inicializao do Parola. . . . . . . . . . . . . . . . . . . . . . Figura 3.7 Mquina de estados do Parola - Eventos internos do Parola. . . . . . . . . . .

17 19 19 20 25 27 28 31 32 34 38

Figura 4.1 Anima - Aplicao de Processamento de Imagens (Animati, LaCA/UFSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

LISTA DE ABREVIATURAS E SIGLAS

API BCE CUDA DAO GPU HTML IDE ISO JVM JAI JNI J2SE JSE SGML SOAP W3C XML

Application Programming Interface Boundary, Control and Entity Compute Unied Device Architecture Data Access Object Graphics Processing Unit HyperText Markup Language Integrated Development Environment International Organization for Standardization Java Virtual Machine Java Advanced Imaging Java Native Interface Java 2 Platform Standard Edition Java Platform Standard Edition Standard Generalized Markup Language Simple Object Access Protocol. The World Wide Web Consortium Extensible Markup Language

SUMRIO

INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 14 14 15 17 18 19 20 22 22 24 25 27 29 30 32 33 34 35 40 41 42 43

2 REVISO BIBLIOGRFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Sistemas Baseados em Componentes e Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Padres de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Data Acess Object (DAO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 JAVA e J2SE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 O FRAMEWORK PAROLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Consideraes de Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Descrio funcional do Parola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Arquitetura e implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Objetos de Entidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Objetos de Criao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Objetos de Fronteira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Objetos de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Inicializao do Parola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Internacionalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Criao e instalao de plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 RESULTADOS OBTIDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Instalao de novas funcionalidades (Arthemis X Anima) . . . . . . . . . . . . . . . 4.2 Controlando as funcionalidades (Arthemis X Anima) . . . . . . . . . . . . . . . . . . . . 4.3 Anima: Lista de plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

CONCLUSO E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

11

INTRODUO

A elaborao de sistemas computacionais vem aumentando seu grau de complexidade na medida que novos componentes passam a ser inter-relacionados para gerao de aplicaes. Percebe-se que a reutilizao de cdigo uma questo fundamental para a criao de sistemas de forma mais rpida e eciente. Tanto na indstria, como em laboratrios de pesquisa em universidades, o fator tempo (ou time-to-market) se caracteriza como diferencial e indicador de produtividade. Concernente a isso, entregar sistemas com alto valor agregado e com diferenciais competitivos o objetivo almejado por qualquer organizao. Produzir software com rapidez e eccia uma atividade complexa, que exige um grande esforo para o seu projeto e sua implementao. Entretanto, o que geralmente ocorre a redescoberta e reinveno dos aspectos centrais da aplicao, tornando o desenvolvimento do software custoso e de baixa qualidade. Quando esse processo ocorre o mesmo chamado de reescrever o cdigo (SCHMIDT; GOKHALE; NATARAJAN, 2004). Somando-se a isso, conforme Freitas (FREITAS, 2006), podem ocorrer situaes onde a falta de planejamento conduza implementao de sistemas monolticos, os quais apresentam uma grande quantidade de compartilhamento de dados, de variveis globais e de um uxo de controle catico. Sistemas monolticos grandes costumam ser de difcil compreenso e, consequentemente, as atividades de manuteno transforma-se em atividades desaadoras e normalmente so onerosas. Para minimizar os efeitos dessa complexidade, comum a utilizao de tcnicas para permitir a escalabilidade no desenvolvimento dos sistemas. Uma forma de se facilitar o crescimento do software estrutur-lo para que este aceite a insero de novas funcionalidades conforme a demanda. Para tanto, organizar o sistema como framework torna-se uma opo racional. Para Fayad (FAYAD, 2001), um framework uma coleo de componentes implementados completamente ou parcialmente com padres predenidos de

12

cooperao entre eles. A arquitetura de um framework corresponde denio de seus mdulos e de como a interao entre estes realizada. Frameworks orientados a componentes (ou objetos) tornaram-se populares na indstria de software durante os anos noventa. Numerosos frameworks foram desenvolvidos por empresas e universidades para diversos domnios de aplicao, incluindo interfaces grcas de usurio (por exemplo Java Swing e outras bibliotecas Java, Microsoft MFC), editores grcos (HotDraw, Stingrays Objective Views), aplicaes de negcios (IBM San Francisco), servidores network (Java Jeeves), dentre outros. Quando combinados entre si, os frameworks fornecem uma poderosa soluo para reuso de software em larga escala (FAYAD; HAMU, 1999; HAMU, 1999) apud (FAYAD, 2001). Pode-se rmar que os frameworks so ferramentas que auxiliam a construo de aplicaes atravs do reuso de estruturas comuns a vrios domnios de problemas. Alm disso, a questo de foco e objetivo, aliada a ambientes com alta rotatividade de pessoas se tornam um problema para a construo de sistemas de forma contnua. Nas universidades, grandes projetos de software so uma tarefa desaadora, tendo em vista que a mo-de-obra normalmente empregada composta por alunos de graduao e mestrado, que costumam passar um perodo relativamente curto na instituio. Alunos de graduao atuam de forma mais substancial em projetos de software quando estes representam seu trabalho de concluso de curso. No entanto, os cdigos fonte produzidos geralmente so mal documentados, o que torna o processo de reutilizao de componentes complexo ou impraticvel. Mestrandos, por sua vez, possuem em mdia dois anos para o desenvolvimento das suas atividades acadmicas e pesquisas cientcas, e so detentores de diversas responsabilidades como docncia orientada e a publicao de seus estudos. Laboratrios de pesquisa que buscam ter um desenvolvimento de software continuado normalmente enfrentam o panorama citado. Com o objetivo de minimizar o prejuzo causado pelo cenrio, prope-se uma abordagem baseada em plug-ins. Plug-ins so componentes de software que apresentam sua arquitetura independente da aplicao principal, pois se interrelacionam com o sistema atravs dos objetos de fronteira. Pode-se destacar os principais pontos positivos dessa abordagem: Primeiramente, plug-ins mal projetados no comprometem todo o sistema. Em segundo lugar, mais fcil reescrever um plug-in do que uma aplicao inteira. O Parola busca ser um framework que auxilia no gerenciamento de mtodos de pro-

13

cessamento e anlise de imagens digitais que so desenvolvidos por demanda. Para isso, baseia-se em padres de projeto, utilizando tcnicas de engenharia de software para implementar uma arquitetura baseada em plug-ins de maneira consistente. O presente trabalho de graduao segue a seguinte organizao: o captulo 2 apresenta uma reviso bibliogrca a respeito de frameworks, sistemas baseados em componentes e plug-ins, padres de projeto e Java. O captulo 3 descreve o processo de desenvolvimento da ferramenta, abordando consideraes de design, arquitetura e implementao, como tambm a forma de construir plug-ins para o Parola. O captulo 4 expe os resultados obtidos. Por m, o captulo 5 apresenta as concluses.

14

REVISO BIBLIOGRFICA

Neste captulo apresenta-se uma reviso bibliogrca sobre os tpicos relacionados a este trabalho. Primeiramente sero mostradas questes referentes frameworks. Ser tratado, tambm, o desenvolvimento baseado em componentes e plug-ins. A seguir, apresentada a temtica de Padres de Projeto, sendo explicado os principais padres que foram utilizados para o desenvolvimento do framework Parola. Alm disso, apresentamse questes referentes linguagem de programao Java, bem como sobre a plataforma J2SE (Java 2 Platform, Standard Edition).

2.1 Frameworks
Parnas (PARNAS; CLEMENTS; WEISS, 1985) arma que um framework implementa a arquitetura de software para uma famlia de aplicaes com caractersticas similares. Pode-se, tambm, denir framework como sendo um conjunto de classes que cooperam entre si e constroem um projeto reutilizvel de software. Alm disso, um framework captura as decises e projetos que so comuns ao seu domnio de aplicao (GAMMA et al., 2005). Nesse caso, Frameworks so mais aplicveis aos domnios de problemas onde exista uma grande uniformidade em termos de funcionalidade e requisitos (SCHMIDT; GOKHALE; NATARAJAN, 2004). Um framework tem como uma das funes principais permitir que mdulos ou funcionalidades sejam adicionados por demanda, aumentando seu escopo de utilizao. A padronizao da estrutura da aplicao permite uma reduo signicativa do tamanho e complexidade do cdigo fonte que deve ser escrito por desenvolvedores, os quais customizam o framework (FAYAD, 2001). Os esforos de desenvolvimento do framework devem ser direcionados no sentido de uma modelagem que tente prever sua escalabilidade, uma vez que sua meta abranger o maior nmero de funcionalidades para determinado

15

domnio de aplicao. Em um framework, componentes ou mdulos so chamados de pontos de variao ou hotspots (PREE, 1999, 1995). Uma aplicao criada a partir do framework pode ser customizada atravs dos hotspots, que representam pontos de adaptao de cdigo que podem ser redenidos (FAYAD; SCHMIDT; JOHNSON, 1999). As partes xas do framework so chamadas frozenspots e representam as estruturas imutveis do sistemas. Dessa forma, temos: Frozenspots Partes xas de um framework; Servios j implementados pelo framework; Geralmente realizam chamadas indiretas ou genricas aos hotspots. Hotspots Partes exveis de um framework; Pontos extensveis, para criao de novos servios/funcionalidades; Partes nos quais os programadores que usam o framework adicionam o seu cdigo para especicar uma funcionalidade de sua aplicao; Hotspots so geralmente implementados atravs de herana e de mtodos abstratos. Neste trabalho busca-se desenvolver um framework direcionado para o processamento e anlise de imagens. Dentro desse propsito a arquitetura do sistema foi elaborada para permitir com que novos mtodos de processamento ou anlise sejam adicionados ao framework de forma simplicada, correspondendo aos hotspots. A parte xa do sistema equivale a arquitetura e a forma como os seus componentes se inter-relacionam. Tambm existem componentes que so aplicveis maioria dos mtodos, como por exemplo, mdulos para abrir, salvar e visualizar de imagens, considerados como frozenspots.

2.2 Sistemas Baseados em Componentes e Plug-ins

Sistemas baseados em componentes, so facilmente personalizados ou adaptados para domnios de aplicaes especcos. Aplicaes de processamento e anlise de imagens

16

so utilizadas nos mais diversos ramos de pesquisas cientcas, onde cada rea tem suas caractersticas e particularidades. Um sistema de propsito geral necessita, dessa forma, de adequaes para ser utilizado de maneira mais ecaz e eciente. Da mesma forma que os paradigmas de desenvolvimento estruturado e orientado a objetos inuenciaram programadores e projetistas de todo o globo, o modelo de desenvolvimento de software baseado em componentes emerge como a atual revoluo na concepo de sistemas computacionais (VITHARANA, 2003) apud (WELFER, 2004). Essa tendncia consequncia natural de uma srie de vantagens como fcil manuteno, maior qualidade e tempo e custos reduzidos de desenvolvimento. Conforme destaca Welfer (WELFER, 2004), o desenvolvimento baseado em componentes possui trs personagens principais: o desenvolvedor do componente, o montador e o cliente ou usurio nal. De maneira simplicada, o desenvolvedor aquele que cria o componente, isto , o programador; o montador necessita conhecer apenas as interfaces do componente, utilizando-o e combinando com outros componentes para resoluo de algum problema computacional; e, por m, o cliente, ou usurio nal, aquele que recebe uma aplicao a qual foi construda com o advento de componentes previamente selecionados e que, dessa forma, atendem sua lista de requisitos. A Figura 2.1 demonstra a atuao desses trs elementos no processo de desenvolvimento de software desde a sua concepo at o seu uso pelo cliente nal (WELFER, 2004). Primeiramente, os componentes so fabricados pelo desenvolvedor para vrios ns, sendo que no h uma relao explcita entre eles, isto , so concebidos para serem independentes. Em um segundo momento, o montador precisa encontrar e inter-relacionar os componentes a m de resolver o problema do cliente. E, por m, tem-se o produto de software pronto para ser utilizado pelo cliente. 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 (BOOCH; JACOBSON; RUMBAUGH, 1999). Para tanto, devem-se administrar artifcios para permitir a personalizao do sistema garantindo a elaborao de aplicaes direcionadas. Um framework facilmente adaptvel dever garantir a elaborao de sistemas cujas demandas sejam individualizadas. Entretanto, Wolnger (WOLFINGER, 2008) defende que o desenvolvimento baseado

17

Figura 2.1: Os trs personagens do processo de componentizao segundo Padmal Vitharana (VITHARANA, 2003) apud (WELFER, 2004).(Fonte WELFER, 2004) em componentes cria sistemas monolticos onde as funcionalidades so habilitadas ou no para execuo, e que modicaes implicam na reposio de grandes partes do software. Para resolver esse problema Wolnger sugere que sistemas baseados em plug-ins carregados em tempo de execuo e mais independentes da arquitetura do sistema resolvem melhor o problema da complexidade no desenvolvimento de aplicaes customizveis. O framework Parola engloba ambas as solues. Existem componentes desenvolvidos como objetos, que so comuns a vrias funcionalidades do sistemas, como por exemplo, abrir, salvar e visualizar imagens. Esses mtodos foram denidos como componentes por questes de padronizao e controle da aplicao. Tambm possvel incluir novos mdulos na forma de plug-ins que so carregados para a aplicao em tempo de execuo. Os plug-ins facilitam a customizao do sistema dependendo do seu contexto de aplicao e permitem que terceiros possam desenvolver mdulos de forma mais independente (WOLFINGER, 2008).

2.3 Padres de Projeto

A utilizao de padres em projetos de desenvolvimento de software com programao orientada a objetos ganhou fora com a publicao dos 23 padres de projeto pela Gangue dos Quatro "GoF"(GAMMA et al., 2005). Esses padres so divididos em trs categorias: os padres de criao, padres estruturais e os padres comportamentais. A primeira categoria representa formas para o processo de criao ou instanciamento de objetos. A segunda identica os padres que compem as classes ou grupos de classes e os padres comportamentais caracterizam a interao e responsabilidades entre os objetos,

18

isto , a comunicao entre eles (COOPER, 1998). Conforme Deitel (DEITEL; DEITEL, 2004) os padres de projeto beneciam os desenvolvedores do sistema das seguintes formas: 1. Ajudando a construir software convel com arquiteturas comprovadas e a experincia acumulada das empresas; 2. Promover a reutilizao de projetos em tempos futuros; 3. Ajudar a identicar erros e armadilhas comuns que ocorrem quando se constroem sistemas; 4. Ajudar a projetar sistemas de forma independente da linguagem na qual estes sero implementados; 5. Estabelecer um vocbulo de projeto comum entre desenvolvedores; 6. Encurtar a fase de projeto em um processo de desenvolvimento de software. Na elaborao do framework de que trata esse trabalho foram empregados alguns padres de projetos. Podemos destacar o Observer descrito por Gamma (GAMMA et al., 2005) e o Data Access Object(DAO), explicado pela Sun(SUN, 2002). 2.3.1 Observer Conforme Gamma (GAMMA et al., 2005), o pado Observer tem o objetivo de ser usado quando um objeto muda de estado e necessrio noticar todos os seus dependentes atualizando-os automaticamente. Pode-se vericar uma representao do padro Observer na Figura 2.2. Se observa que o Subject representa uma classe abstrata ou uma interface que oferece mecanismos para adicionar e remover observadores. A implementao da lgica ser feita na classe ConcrecteSubjec que envia uma noticao para os observadores quando seu estado muda. O Observer dene uma interface de atualizao para objetos que devem ser noticados sobre mudanas em um Subject. J o ConcrecteObserver implementa a lgica necessria para executar uma ao quando noticado.

19

Figura 2.2: Diagrama de classes do padro Observer. 2.3.2 Data Acess Object (DAO) Conforme a Sun (SUN, 2002), o uso de um Data Access Object abstrai e encapsula todo acesso aos dados, sendo que o DAO responsvel por gerenciar a conexo com a fonte de dados para obter e armazenar as informaes. Pode-se visualizar na Figura 2.3 o diagrama de classes do padro DAO. O BusinessObject o objeto que requer o acesso base de dados tanto para obter quanto para armazenar informaes. O DataAccessObject abstrai o acesso fonte de dados (DataSource) tanto para gravao, quanto para acesso as informaes. O TransferObject usado para carregar os dados.

Figura 2.3: Diagrama de Classes do Padro DAO.(Fonte SUN, 2002)

20

2.4 JAVA e J2SE

Java uma linguagem de programao orientada a objetos de alto nvel criada pela Sun Microsystems em 1991. Uma das caractersticas que mais se destaca nessa linguagem a capacidade do cdigo fonte ser compilado uma nica vez e poder ser executado em qualquer arquitetura de hardware e software compatvel com essa tecnologia. A Sun (SUN, 2008a) denomina essa caracterstica como sendo "Write Once Run Anywhere". Para atingir essa independncia de plataformas, um programa Java necessita de uma mquina virtual instalada, que chamada de JVM (Java Virtual Machine) . O cdigo fonte traduzido em bytecodes que a JVM consegue ler e interpretar. Breves (BREVES; P., 2007) dene bytecode como: Toda interface, classe, anotao e enumerao, alm do respectivo cdigo dentro deles, est em um arquivo .class, que tem um formato binrio muito bem especicado, batizado de bytecode. Java uma tecnologia muito ampla, possvel programar desde dispositivos mveis a aplicaes Web. Dentre as tecnologias desta linguagem, pode-se destacar Java EE (Enterprise Edition), SE (Standard Edition) e ME (Micro Edition). A Figura 2.4 apresenta um diagrama que mostra a abrangencia das diversas tecnologias Java.

Figura 2.4: Tecnologias Java.(Fonte SUN, 2009b) Tanto a plataforma J2SE (Java 2 Platform, Standard Edition) quanto a JSE (Java Stan-

21

dard Edition) tem o foco em sistemas desktop. A primeira refere-se s tecnologias Java da verso 1.2 at a verso 5. J a nomenclatura JSE foi adotada a partir da verso 6 da linguagem Java. Sabe-se que atualmente a verso 5 suportada pela maioria das plataformas computacionais. o caso do sistema operacional MacOSX Tiger, que s tem suporte verso 5 dessa linguagem.

22

3 O FRAMEWORK PAROLA

O Parola um framework que encapsula uma srie de decises de projeto para a criao de aplicaes de processamento e anlise de imagens baseadas em Plug-ins. Ele implementa uma arquitetura plugvel, facilmente extensvel que controla os plug-ins e gerencia as imagens. Para isso, necessrio um sistema bem organizado, que se fundamenta em conceitos de engenharia de software e padres de projeto para apresentar um design consistente. Do ponto de vista dos plug-ins, pode-se destacar que eles apresentam uma grande independncia do restante do sistema, sendo limitados somente pelas interfaces dos objetos de fronteira. Esse captulo tem como objetivo mostrar os principais aspectos da arquitetura e da tecnologia empregadas na construo do Parola, alm de apresentar a metodologia de construo de um plug-in. Evita-se entrar em aspectos mais especcos da linguagem de programao, contudo algumas excees se fazem necessrias para um melhor entendimento do trabalho.

3.1 Consideraes de Tecnologia

Java uma linguagem de programao de alto nvel bastante conceituada na indstria de software. Diversas caractersticas a tornam a escolha preferida por arquitetos de software para os mais diversos projetos. Ao tratar, em especco, do framework Parola, podem-se destacar as seguintes caractersticas: 1. Orientao a objetos; 2. Invocao de objetos e mtodos em tempo de execuo (desconhecidos durante a compilao); 3. Existncia de uma grande comunidade de desenvolvedores;

23

4. Existncia da API (Application Programming Interface) de processamento de imagens JAI (Java Advanced Imaging); 5. Invocao de cdigo desenvolvido em outras linguagens atravs do framework JNI (Java Native Interface); 6. Existncia de bons frameworks para a construo de interfaces grcas, em especco o framework Swing que faz parte da API padro da plataforma J2SE/JSE; 7. Bom suporte a manipulao de arquivos XML (Extensible Markup Language). A orientao a objetos j se consagrou como uma abordagem de desenvolvimento de sucesso. J a invocao de mtodos e objetos em tempo de execuo no uma caracterstica que todas as linguagens orientadas a objetos possuem. Em Java, isso possvel por meio da API Reection. A Sun (SUN, 2008b) arma que a tecnologia Reection possibilita que programadores construam programas que modiquem o seu comportamento em tempo de execuo, o que necessrio para a invocao dos plug-ins. A API JAI outro ponto importante, pois oferece um conjunto de interfaces orientadas a objetos que do suporte a um modelo de programao de alto nvel, para a manipulao de imagens digitais (SUN, 2009c). A JAI ainda permite que qualquer algoritmo de processamento de imagens possa ser adicionado sua API e ser usado como se fosse uma parte nativa da biblioteca. Sendo assim, conforme a conceituao de framework, pode-se inferir que a tecnologia JAI um framework que atua no domnio matemtico de processamento e anlise de imagens. JNI, por usa vez, uma tecnologia que se destaca, possibilita ao desenvolvedor tirar proveito da plataforma Java e, ainda, utilizar cdigo escrito em outras linguagens (LIANG, 1999). Apesar do framework Parola no se beneciar diretamente da tecnologia JNI, essa caracterstica considerada importante, pois permite que plug-ins se utilizem de tecnologias de processamento de alto desempenho em GPU (Graphics Processing Unit), como a tecnologia CUDA (Compute Unied Device Architecture) da Nvidia (CUDA uma arquitetura para processamento paralelo de propsito geral disponvel para a linguagem C (NVIDIA, 2008)). Segundo a W3C (W3C, 2009) XML um formato de arquivo texto simples e exvel que organiza as informaes de maneira estruturada e clara atravs do uso de tags, de maneira similar ao formato HTML (HyperText Markup Language). XML importante

24

por ser um padro utilizado pela indstria de software. Diversas aplicaes fazem uso desse formato de arquivo, utilizam-no, em especial, para guardar conguraes e servindo de base para diversos arquivos dados. Alm disso, ele utilizado em diversos protocolos de comunicao, como, por exemplo, o protocolo SOAP (Simple Object Access Protocol). Suas caractersticas de simplicidade e exibilidade permite a criao de arquivos de fcil entendimento. O grande grau de importncia do XML, aliado ao timo suporte para linguagem Java, foi fundamental para a denio desse formato para os arquivos de congurao do framework Parola.

3.2 Descrio funcional do Parola

Abaixo, segue a lista das principais funcionalidades que o Parola implementa: 1. Gerenciamento de plug-ins: Cada plug-in possui um controlador que gerencia o estado habilitado ou desabilitado; 2. Plug-in sempre habilitado (caso congurado); 3. Personalizao da interface grca atravs de pacotes de estilo (conhecidos em ingls como look and feel); 4. Separadores entre os plug-ins; 5. Construo de menus e submenus (ordenados conforme o arquivo de congurao); 6. Construo da barra de tarefas; 7. Componente de visualizao de imagens; 8. Componente de abertura de imagens; 9. Componente para salvar imagens; 10. Congurao da funcionalidade "sobre"(tag about, que gera um pop-up, utilizado normalmente para crditos); 11. Comando para organizar as janelas internas (cascata ou lado a lado). Em relao ao objetivo de gerenciamento de plug-ins a Figura 3.1 apresenta duas imagens de uma aplicao construda com o Parola, colocadas lado a lado. No caso

25

A, evidencia-se um plug-in que s trabalha com imagens em tons de cinza, que o CalcPhase. J no caso B, visualiza-se um outro plug-in que s trabalha com imagens coloridas, o ColorSpace3D. Contudo, ambas imagens apresentam um terceiro e quarto plug-ins, que esto disponveis tanto para imagens coloridas, quanto para imagens em tons de cinza, que so o de correo de iluminao e o de histograma. Essa funcionalidade, de gerenciar os estados habilitado e desabilitado dos plug-ins, de extrema importncia para o Parola, pois evita que os usurios nais do sistema executem um plug-in que receba uma imagem que no tenha sido projetado para trabalhar. Nesse caso, o problema se d pois um plug-in pode gerar dados inconsistentes ou apresentar funcionamento anmalo apartir de uma imagem errada, gerando instabilidade para todo o sistema.

Figura 3.1: Plug-ins habilitados ou desabilitados conforme o tipo da imagem em foco.

3.3 Arquitetura e implementao

Bezerra (BEZERRA, 2007) arma que em Sistemas de Software Orientados a Objetos "os objetos encapsulam tanto dados quanto comportamento. O comportamento de um objeto denido de tal forma que ele possa cumprir com suas responsabilidades. Uma responsabilidade de um objeto uma obrigao que este tem no sistema no qual ele est inserido. Graas s suas responsabilidades, um objeto colabora com outros objetos para que os objetivos do sistema sejam alcanados.

26

Tendo por base que um objeto encapsula tanto dado quanto comportamento dentro da categorizao de objetos BCE (Boundary, Control e Entity), podem-se distinguir trs categorias: os objetos de fronteira, de controle e de entidade. Bezerra (BEZERRA, 2007) os dene da seguinte maneira: 1. Objetos de entidade normalmente servem como um repositrio para alguma informao manipulada pelo sistema; 2. Os objetos de controle, chamados tambm controladores, so responsveis por coordenar a execuo de alguma funcionalidade especca do sistema. Esses objetos decidem o que o sistema deve fazer quando ocorre um evento relevante, ou seja, servem como gerentes de outros objetos para a realizao de um ou mais casos de uso; 3. Os objetos de fronteira permitem o sistema interagir com o ambiente externo, tanto na comunicao com atores, quanto na interface com sistemas externos. Alm desses mencionados, pode-se armar, ainda, que existem objetos que so responsveis pela criao de outros objetos, tratam-se de objetos de criao. A terminologia objetos de criao baseada a partir da diviso que Gamma (GAMMA et al., 2005) propem aos padres de projeto e que deni trs categorias: os padres de criao, os padres estruturais e os padres comportamentais. Objetos de criao, normalmente, so classicados pela BCE com objetos de controle, devido as suas responsabilidades. Contudo, com o objetivo de facilitar o entendimento da arquitetura do Parola e pelo grau de especicidade desses objetos na construo deste framework tratar-se-o separadamente. Somando-se a isso, possvel armar que um objeto pode ser enquadrado em mais de uma categoria, mediante a suas responsabilidades. Um objeto, ento, pode assumir a caracterstica de controlador e de fronteira, como no caso do objeto de nome Parola (mesmo nome de sua classe). Esses tipos de objetos so tratados, logo abaixo, levando em conta a forma que o Parola foi implementado. A Figura 3.2 apresenta uma verso simplicada do diagrama de classes do framework Parola. As classes do pacote model foram subtradas desse diagrama para garantir uma melhor compreenso, contudo, possvel ver em detalhes as classes pertencentes ao pacote model na Figura 3.3.

27

Figura 3.2: Diagrama De Classes do Parola - Simplicado. 3.3.1 Objetos de Entidade O Parola, por tratar-se de uma ferramenta voltada para a construo de outras aplicaes, apresenta um domnio de negcio - entidades - peculiar. Para projetistas de software, ver a relao entre as entidades e as tabelas de um banco de dados em um sistema de informao convencional, uma tarefa bastante corriqueira. Mapeiam-se os relacionamentos entre as tabelas, assim, gerando as entidades. O diagrama de classes do domnio relativamente de fcil entendimento tanto pelos desenvolvedores, quanto pelos usurios nais. A mesma coisa acontece com o Parola. Seus usurios, os desenvolvedores de plug-ins, conseguem facilmente identicar elementos de interfaces grcas com o usurio. Componentes comumente vistos em interfaces grcas so representados e armazenados em instncias das classes do diagrama da Figura 3.3. Pode-se destacar, nessa gura, que so representados menus, barra de tarefas (ToolBars), Items (forma pela qual so

28

inseridos plug-ins no Parola), entre outros.

Figura 3.3: Diagrama de Classe de Domnio (Pacote Model). Aprofundando a anlise em relao a classe Item, possvel identic-la como sendo de fundamental importncia para o Parola. Isso se deve ao fato dela armazenar informaes de congurao para plug-ins, como a classe a ser invocada (o plug-in propriamente dito) e a classe responsvel pelo controle do plug-in (habilitando ou no), alm de denir se o plug-in ser habilitado por padro (defaultEnable), entre outras conguraes. Alm da congurao dos plug-ins, essa classe assume outras responsabilidades que so herdadas da interface ParolaModel, destacando-se as listadas abaixo:

29

1. Denio de separadores entre os plug-ins; 2. Denio da funo about; 3. Comandos do sistema: (a) cmd_exit: Dispara evento para fechar o programa; (b) cmd_organize_cascade: Dispe as janelas internas em forma de cascata; (c) cmd_organize_side_by_side: Dispe as janelas internas lado a lado; A Figura 3.3 apresenta trs tipos de classes do modelo. As classes que esto em tons de amarelo so responsveis pelas informaes de interface grca; as classes em tons de verde representam os dados de linguagem; e, por m, a classe em tom de roxo armazena as preferncias do usurio. Os objetos de entidade so carregados a partir de trs arquivos XML: 1. cong.xml: Entidades de interface grca; 2. main_<lingua>_<pas>.xml: Entidades de linguagem. Nesse caso, existe um arquivo para cada idioma. Por exemplo: main_pt_BR.xml (arquivo para portugus brasileiro) ou main_en_US.xml (ingls americano); 3. userPreferences.xml: Entidade de preferncia do usurio. (Guarda as informaes como lngua, pas e aparncia). 3.3.2 Objetos de Criao No Parola, as classes que apresentam o suxo DAO e o prexo Factory (fbricas) so responsveis pela criao de objetos. O primeiro caso, corresponde ao uso do padro de projeto Data Access Object, padro que auxilia na interao com uma base de dados, para o acesso aos arquivos XML, gerando os objetos de entidade. No segundo caso, temos classes com o prexo Factory, que so responsveis pela criao dos componentes visuais. A partir dos objetos de entidade, as fbricas criam objetos de interface grca com as caractersticas necessrias a cada funo. A Figura 3.2 apresenta tanto classes DAO, quanto Factory.

30

3.3.3 Objetos de Fronteira A comunicao entre Plug-ins e o ambiente da aplicao fundamental, e se d atravs de duas classes principais, que so instanciadas gerando os objetos de fronteira. O primeiro caso, refere-se ao objeto Parola, que a nica instncia da classe principal do framework e disponibiliza as interfaces bsicas de acesso ao ambiente da aplicao. Podese destacar que esse objeto mais til para gerenciar informaes de propsito geral, como: 1. Lngua e o pas que o ambiente est usando, sendo til para que os plug-ins apresentem as suas interfaces grcas na lngua correta; 2. Informaes para posicionar o plug-in em relao janela da aplicao; 3. Interfaces de acesso de baixo nvel, usadas quando so necessrias interaes mais especcas. Outro objeto responsvel pela comunicao com os plug-ins o ParolaImageMiddleware. Esse implementa uma camada de abstrao para interagir com as imagens do sistema, adicionando novas e gerenciando imagens abertas. Implementa mecanismos que buscam imagens por tipos. Por exemplo, possvel ter acesso a todas as imagens em escala de cinza atravs do mtodo getAllGrayScaleImagesFrames(). A Figura 3.4 mostra o diagrama de classes dos objetos de fronteira. Observa-se nesse diagrama os mtodos que servem de interface de comunicao com os plug-ins. Questes mais aprofundadas sobre esse diagrama entrariam no domnio especco da linguagem, o que foge ao escopo desse trabalho. Com o objetivo de facilitar o entendimento das comunicaes dos objetos de fronteira com os plug-ins, v-se na Figura 3.5 as possveis combinaes. Dessa forma, os plugins podem se comunicar diretamente com o Parola, usando o ParolaImageMiddleware ou atravs das duas classes. Aprofundando a anlise sobre essa gura pode-se observar as seguintes caractersticas: O plug-in 1 comunica-se diretamente com o objeto Parola esse caso acontece quando existe alguma funcionalidade que no manipula imagens, por exemplo, um plug-in para visualizao de dados gerados por outro plug-in;

31

Figura 3.4: Diagrama de Classe - Classes que se comunicam diretamente com os plug-ins. O plug-in 2 faz uso da comunicao com os objetos Parola e ParolaImageMiddleware esse caso concentra-se na grande maioria dos plug-ins. Certas funcionalidades que interagem com o usurio necessitam saber, no mnimo, dados da lngua e a informaes para posicionar a janela do plug-in, alm de ter que interagir com o sistema para buscar, atualizar ou criar novas de imagens; O plug-in 3 comunica-se somente com o ParolaImageMiddleware essa situao acontece quando uma funcionalidade no precisa de interface grca. Por exemplo, quando se converte uma uma imagem RGB para escala de cinza ou quando se separam as suas bandas.

32

Figura 3.5: Camadas de comunicao - objetos de fronteira e plug-ins. 3.3.4 Objetos de Controle Desenvolver plug-ins, gerenciar imagens, ler arquivos de congurao e construir interface grca com o usurio so tarefas inerentes ao propsito do Parola. Mas faz-se necessrio invocar a classe certa na hora certa, habilitar ou no plug-ins e mesmo garantir a construo correta da interface grca. Essas aes, referem-se aos objetos de controle. No Parola dividem-se em dois grupos: Os controladores dos plug-ins e os controladores do Parola. Os controladores dos plug-ins reagem a eventos gerados pelo Parola, respondendo, habilitando ou desabilitando os plug-ins, dependendo do estado da aplicao. Cada plugin pode ter somente um controlador associado ou no possuir nenhum. No caso de no se ter nenhum controlador associado o plug-in se manter habilitado ou no, mediante a sua congurao defaultEnabled. Pode-se vericar os diversos estados que a aplicao pode assumir no diagrama de estados da Figura 3.7. Assim sendo, os controladores dos plug-ins representam um caso de uso tpico do padro observer, visto que esses controladores cam observando o estado da aplicao. Em Java utiliza-se do termo listner para se referir ao observador. Esse termo, por sua vez, bastante usado pelo framework Swing. Dessa forma, os controladores so denidos no arquivo de congurao pela tag classListener. Outro ponto importante que seu funcionamento bastante simples, para isso o controlador possui apenas um mtodo que retorna true, no caso habilitado, ou false, no caso desabilitado. Os controles de estados do Parola so os mecanismos responsveis por informar o novo estado para os controladores dos plug-ins, alm de invocar a classe certa na hora em que a aplicao ser nalizada. A Figura 3.2, que mostra o diagrama de classes do Parola,

33

possibilita a observao do pacote controler, que apresenta, por usa vez, trs classes: PerformAction Trata os eventos gerados pela troca, perda ou ganho do foco sobre as imagens no sistema. A cada evento o Parola avisa seu estado aos observadores e cada observador, de posse do novo estado da aplicao, retorna um valor booleano para o framework o avisando se o plug-in de sua responsabilidade est ou no habilitado; ActionItems A partir do momento em que o plugin encontra-se habilitado, essa classe responsvel pela sua execuo. Em outras palavas, ela cria uma instncia do plug-in; ActionWindow Invoca a classe responsvel pela ao de fechamento da aplicao. 3.3.5 Inicializao do Parola Esta seo trata dos passos que so necessrios para o Parola ser inicializado. O sistema l os arquivos de congurao e inicializa todos os objetos na memria, assim, a aplicao est pronta para uso. Objetos de entidade, criao, fronteira e controle so inicializados e comeam a atuar juntos para criar um ambiente completo. Em especial sero tratado os pontos que envolvem a criao dos objetos de entidade at a construo da interface grca com o usurio. A Figura 3.6 apresenta o diagrama de sequncia dos objetos de criao. Primeiramente, o objeto Parola - objeto principal - faz a requisio dos elementos de congurao ao CongDAO, e recebe, como resposta, os objetos de entidade, carregados a partir do aquivo cong.xml. Esse arquivo de congurao contem dados sobre os plug-ins, alm de diversas outras informaes como, por exemplo, a ordem dos plug-ins e de mais elementos na interface grca. Em um segundo momento, o objeto principal do framework recebe os dados de preferncia de usurio. A partir dessas informaes, noticado o objeto LanguageDAO a lngua e o pas, dados necessrios para a traduo correta do sistema. De posse dos objetos de entidade, o Parola repassa as informaes necessrias para os objetos com o prexo Factory, a m de que sejam criados os objetos de interface grca (janela da aplicao, menus, submenus, barra de tarefas, entre outros). E por m, para cada elemento da interface grca existe um ParolaModel associado, que permite ao DAO de linguagem buscar os dados para o Parola fazer a traduo do sistema. A partir desse momento, o sistema encontra-se inicializado, esperando a interao com o usurio.

34

Figura 3.6: Diagrama de sequncia: Inicializao do Parola.

3.4 Internacionalizao
A internacionalizao um aspecto importante para todas as aplicaes que buscam ter uma comunidade global de usurios. O Parola apresenta seu idioma baseado em arquivos XML, uma vez que ele necessita conhecer uma srie de informaes para a criao da interface grca como, por exemplo, mnemonicos (atalhos de teclado) e descries (usadas quando se repousa o mouse sobre algum item). O framework necessita de objetos que encapsulem esses dados de linguagem para que se possa ter uma implementao clara e simples, destacam-se os objetos de entidade responsveis pela lngua, que assumem essa funo. Abaixo, apresentado o exemplo do cdigo de um arquivo simplicado de idioma: <language> <item> <id>meu_plugin_id</id> <value>Isso vai aparecer no boto do plugin</value> <mnemonic>I</mnemonic> <shortDescription> Quando o mouse ficar parado sobre o plugin,

35

essa a mensagem que vai aparecer em uma caixinha amarela. </shortDescription> </item> </language> Contudo, a forma de internacionalizao baseada em XML pode no ser a melhor sada para todos os casos. Os plug-ins de posse de informaes de localidade (pas e lngua), que facilmente conseguem obter a partir do objeto de fronteira Parola, podem implementar a sua traduo da maneira que lhe for mais conveniente. Entretanto, importante destacar a importncia de usar formas padronizadas para implementar a internacionalizao de sistemas de software. A padronizao facilita a traduo do sistema para um determinado idioma, pois torna mais simples o trabalho dos responsveis pela traduo, os tradutores, que tendo que se preocupar com diversas formas de internacionalizao gastam mais tempo e, consequentemente, elevam os custos do processo. Dessa forma, encorajado o uso de arquivos .properties, padronizao denida pela Sun Microsystem. De uma maneira resumida, existe um arquivo de texto com a terminao .properties para cada pas e lngua a ser traduzida, para cada plug-in. Todos os arquivos de linguagem apresentam uma coluna que representa a chave e uma segunda que representar a sua traduo, separadas pelo caractere = (igual). Atravs de mecanismos que a API padro Java implementa facilmente se tem acesso as frases que sero usadas para a traduo do plug-in. Segue-se o exemplo de um arquivo .properties em portugus brasileiro. Esse arquivo possuir o nome: plug-in_pt_BR.properties. PalavraChave1 = Essa a traduo da PalavarChave1. Abaixo, o cdigo de um arquivo .properties em ingls americano, e seu nome plug-in_en_US.properties. PalavraChave1 = This is the PalavarChave1s translation.

3.5 Criao e instalao de plug-ins

A insero de novas funcionalidades ao framework se d atravs de sua parte exvel ou hotspots, conhecidas como plug-ins. Para a elaborao de um novo plug-in deve-se

36

criar uma classe que possua um construtor que no receba argumentos. Isso, necessrio para a instanciao do plug-in em tempo de execuo. As regras bsicas de codicao para a criao de um plug-in so: 1. Criao de um construtor que no recebe argumentos, buscando seguir o padro JavaBeans (SUN, 2009a); 2. Denir se o plug-in ser ou no modal, ou seja, se deve bloquear as demais janelas do programa at o m de sua execuo ou no; 3. Denir posio em relao janela principal; 4. E, nalmente, tornar o plug-in visvel. Abaixo, apresentado o exemplo do cdigo do construtor de um plug-in: public SamplePlugin() { super(); // inicializa os componentes do plug-in initComponents(); // bloquear as demais janelas this.setModal(true); /*posiciona o plug-in centralizado em * relao a janela princial */ this.setLocationRelativeTo(Parola.getMainFrame()); //torna o plug-in visvel this.setVisible(true); } Aps a criao do construtor, necessrio congurar o Parola para execut-lo. Observase no prximo cdigo a congurao de um plug-in (no arquivo "cong.xml"). A estrutura que representa um plug-in denida pela tag "item", a tag id, por usa vez, refere-se ao identicador do plug-in, que ser posteriormente utilizada para a traduo. O tipo "plugin" , na tag type, informa ao Parola que esse item se refere a um plug-in, e portanto, este dever identicar as demais tags que o seguem. J a tag className faz referncia ao

37

endereo do plug-in. Por sua vez, o classListner a classe que ser invocada pelo Parola a m de observar os eventos que possam habilitar ou no o plug-in, como, por exemplo, uma imagem ganhar o foco. No caso de no existir imagem em foco, o plug-in assume o estado padro que foi denido pela tag defaultEnable (habilitado ou no). Pode-se visualizar a mquina de estados do Parola na Figura 3.7 e ter uma compreenso de como o Parola interage com os plug-ins e com os estados internos da aplicao. <item> <id>meu_plugin_id</id> <type>plugin</type> <className> br.com.animati.anima.SamplePlugin </className> <classListener> br.com.animati.anima.SamplePluginListener </classListener> <defaultEnable>false</defaultEnable> </item> Para o Parola poder ter acesso a esse novo plug-in pode-se proceder das seguintes maneiras: 1. De posse do novo plug-in e com os arquivos de congurao devidamente editados, faz-se necessrio colocar o plug-in em um lugar visvel ao classpath, que dene os locais onde a JVM consegue ter acesso as classes Java. Isso se faz das seguintes maneiras: (a) Congurando o classpath atravs de um argumento de linha de comando, assim a JVM consegue encontrar as classes do plug-in. Isso se d atravs do comando "java -classpath <meu_diretrio_com_o_plugin> -jar

<nome_do_projeto_feito_com_o_Parola>". No caso de um projeto chamado Parola far-se-ia da seguinte maneira: "java -classpath /diretrio_com_o_plugin -jar Parola". Essa maneira de adicionar um plug-in bastante til pois permite ao programador que crie scripts os quais contenham esse comando, podendo

38

Figura 3.7: Mquina de estados do Parola - Eventos internos do Parola. ser feito, por exemplo, atravs de arquivos ".bat"(em sistemas windows) ou ".sh"(em sistemas do tipo Unix). (b) possvel, tambm, congurar a varivel de ambiente do sistema operacional relativa ao classpath. Isso, contudo, varia dentre os sistemas operacionais. Quando congurada a varivel de ambiente, para buscar as classes do plug-in, basta invocar a aplicao para ela pode executar o plug-in. Detalhes sobre essa congurao no sero abordados nesse trabalho por considerar a primeira alternativa a forma mais simples e fcil. (c) A ltima maneira se faz por colocar as classes do plug-in em um diretrio j mapeado pelo classpath. Considera-se essa alternativa til quando o plug-in possa vir a ser til a aplicaes de terceiros. Contudo, no ser abordada essa congurao por considerar a primeira alternativa a que se adapta melhor a maioria dos casos. 2. Outra forma de se adicionar funcionalidades, se faz a partir do cdigo fonte do framework. Nesse caso, cria-se um projeto em uma IDE (Integrated Development Environment) como, por exemplo, o NetBeans. IDEs so ambientes de desenvol-

39

vimento de software que combinam editor, compilador, ferramenta para depurao de cdigo entre outras funcionalidades. Cria-se ento um projeto, adiciona-se os cdigos do Parola e cria-se o pacote do plug-in.Quando compilado o projeto, normalmente, o plug-in ser empacotado junto do pacote da aplicao. Dessa forma no se faz necessrio explicitar o caminho do plug-in ao classpath da JVM. Outro pronto importante saber como se consegue ter acesso imagem desejada e como se pode devolver uma imagem ao sistema. Nesse caso observa-se no cdigo abaixo um exemplo de como o desenvolvedor faz para adquirir um objeto da classe PlanarImage, usada pela JAI para os mtodos de processamento de imagens. ParolaInternalFrame animaInternalFrame = ParolaImageMiddleware.getCurrentParolaImageFrame(); PlanarImage planarImage = animaInternalFrame.getImage().getPlanarImage(); Quando do termino do processamento, deve-se enviar a nova imagem ao Parola atravs do ParolaImageMiddleware conforme o cdigo abaixo: Image image = new Image(); image.setPlanarImage(newImage); ParolaImageMiddleware.createParolaInternalFrame(image); Essa seo apresentou os conceitos bsicos para o desenvolvimento e instalao de novas funcionalidades em sistemas baseados no framework Parola.

40

RESULTADOS OBTIDOS

O framework descrito nas sees anteriores foi utilizado com sucesso por vrios alunos de iniciao cientca do Laboratrio de Computao Aplicada da Universidade Federal de Santa Maria (LaCA/UFM). Alm de alunos do LaCA/UFSM a empresa Animati Computao Aplicada teve alguns de seus desenvolvedores trabalhando no sistema Anima (Figura 4.1). O Anima um sistema de processamento e anlise de imagens desenvolvido atravs de uma parceria entre a Animati e o laboratrio LaCA. Esse capitulo apresenta um comparativo da abordagem proposta pelo sistema Arthemis, antigo projeto do LaCA, em comparao ao Anima, desenvolvido com o Parola.

Figura 4.1: Anima - Aplicao de Processamento de Imagens (Animati, LaCA/UFSM) . O Arthemis uma aplicao de processamento e anlise de imagem que apresenta a

41

mesma proposta do Anima, isto , busca ser uma plataforma computacional extensvel e personalizvel para processar imagens digitais. Os dois softwares apresentam arquiteturas bem diferentes. O Arthemis segue a proposta de arquitetura trs camadas, baseada em componentes, divididas da seguinte maneira: A primeira camada, representa a APJ JAI. A segunda, se refere aos mtodos de processamento de imagens desenvolvidos no LaCA, esse mtodos fazem acesso primeira camada. E a terceira camada, a camada de interface grca, que faz acesso aos mtodos da segunda camada. O Anima, por outro lado, uma coleo de plug-ins inseridos no Parola, tirando vantagem da proposta arquitetural disponibiliza pelo framework. Sendo assim, as caractersticas estruturais e arquiteturais atribudas ao Anima na verdade se referem ao Parola, contudo ser usado o nome Anima em alguns casos por representar uma aplicao voltada ao usurio nal.

4.1 Instalao de novas funcionalidades (Arthemis X Anima)

O Arthemis congura a interface grca atravs de arquivos XML, de maneira similar aos recursos do Parola. Entretanto, sua congurao bastate trabalhosa , visto que necessrio editar o cdigo fonte de algumas classes Java alm de ter que alterar o arquivo XML de congurao. Em outras palavras, para adicionar uma nova funcionalidade necessrio fazer o mapeamento da classe a ser invocado em pelo menos trs classes Java, para da usar as conguraes dos arquivos XML. Desse modo, seus arquivos XML apenas se responsabilizam pela organizao das funcionalidades na interface grca da aplicao. J o Anima, por ser baseado no Parola, necessita apenas a congurao do arquivo cong.xml e dos arquivos de linguagens (para a internacionalizao). Dispensa, assim, a necessidade de alterao do cdigo fonte da aplicao. O que evidencia a primeira grande mudana de paradigma entre o Anima e o Arthemis. O Anima tem suas funcionalidades adicionadas na forma de plug-ins e o arquivo cong.xml guarda as informaes relevantes para a instanciao das funcionalidades, evita-se a prtica do hard coding (prtica que altera diretamente o cdigo fonte da aplicao para fazer mudanas em sua congurao). O Parola utiliza-se da API Reection de forma mais eciente que o Arthemis.

42

4.2 Controlando as funcionalidades (Arthemis X Anima)

Fazendo-se uma anlise da arquitetura trs camadas implementada pelo Arthemis possvel fazer as seguintes observaes: 1. A segunda camada, responsvel pelos mtodos de processamento de imagens, apresenta um boa independncia em relao camada de interface grca; 2. A terceira camada, a de interface grca, apresenta uma grande importncia no sistema, pois possui as seguintes responsabilidades: (a) Criar a interface grca de toda a aplicao; (b) Implementar a interface grca de cada mtodo de processamento de imagens; (c) Tratar todos os possveis erros do programa; (d) Gerenciar as imagens abertas no sistema. A arquitetura do Arthemis foi capaz de criar uma segunda camada com forte independncia da interface grca. Suas caractersticas de implementao e padronizao de interfaces de acesso deixavam aberta a possibilidade de se criar uma linguagem de macros. Entretanto, a terceira camada, fortemente baseada em componentes, apresentava decincias bastante srias. No existia um mecanismo que garantisse que uma determinada funcionalidade casse disponvel somente quando o estado interno do sistema fosse favorvel. Quando muito, a interface grca capturava as excees geradas pelo uso de uma imagem incompatvel a um mtodo matemtico e noticava o usurio do sistema com alguma mensagem de erro. Resultando que o sistema, em muitos casos, gerasse resultados inconsistentes. Outras vezes, o sistema disparava excees, das classes da primeira ou segunda camada, que quando no tratadas geravam funcionamento anmalo a aplicao. A camada de interface grca do Arthemis representa um verdadeiro desao. Era altamente complexa e apresentava um uxo de controle de difcil entendimento. Um ponto chave do Anima o controle que se tem sobre cada funcionalidade. Como explicado no captulo anterior, o Parola disponibiliza formas de gerenciar as funcionalidades, que so inseridas na forma de plug-ins. Existe um controlador associado a cada plug-in, esse responsvel por observar o status interno do sistema, habilitando ou desabilitando o plug-in conforme a necessidade. Esse controle consegue resolver o principal problema de interface grca do Arthemis, pois ele evita que o problema acontea.

43

Quando se tinha um erro em um determinado mtodo de processamento de imagens, e se necessitava descobrir se o problema de interface grca ou de implementao matemtica a arquitetura do Arthemis se mostrava bastante complexa. Pois, o Arthemis apresentava uma estrutura distribuda. Os mtodos matemticos cavam em um pacote especco e as interfaces grcas cavam em outro. Isso gerava uma estrutura bastante grande, e que necessitava muito tempo de anlise para o seu entendimento. Soma-se a isso, o fato de que a camada responsvel pela interface grca era fortemente baseada em componentes, isso acarretou uma estrutura monoltica, o que, nesse caso, dicultava a compreenso do sistema. Dessa forma o processo de depurao cava prejudicado. Por outro lado, o Anima apresenta a sua estrutura encapsulada em plug-ins. Isso signica que, cada plug-in carrega em seu pacote a interface grca e a implementao do mtodo matemtico. Assim, o processo de depurao ca restrito ao pacote do plug-in, o que simplica ao processo de deteco de erros.

4.3 Anima: Lista de plug-ins

O Anima apresenta os seguintes plug-ins implementados: 1. CalcPhase : uma ferramenta para determinar as fraes de rea dos componentes homogneos de uma imagem usando o mtodo da anlise linear de histogramas(FRIEDRICH, 2007); 2. Correo de Iluminao: Responsvel por implementar mtodos de processamento de imagens para correo do vignetting, problema bastante comum em laboratrios que trabalham com microscopia ptica (BERNI, 2007); 3. ColorSpace3D: Ferramenta que permite a visualizao 3D de diferentes espaos de cores (DARONCO, 2006; MAZZANTI, 2008); 4. Histogramas: Plug-in que permite a visualizao dos histogramas de imagens digitais.

44

5 CONCLUSO E TRABALHOS FUTUROS

Este trabalho apresentou uma arquitetura exvel baseada em plug-ins e padres de projetos, visando a construo de um framework para processamento e anlise de imagens, denominado Parola. O Parola torna a insero de novas funcionalidades a um sistema uma tarefa simples, pois trabalha com o conceito de plug-ins. O uso de tecnologias baseadas em plug-ins proporciona maior liberdade ao programador na elaborao de novos mdulos, em razo do plug-in no possuir uma dependncia rgida em relao a arquitetura do sistema a que pertence. Isso se deve ao fato da interao com a aplicao ser feita atravs dos objetos de fronteira. Essa abordagem permite que os sistemas possam dispor de uma grande quantidade de funcionalidades, sendo que somente as necessrias na execuo de um determinado procedimento so carregadas em tempo de execuo. A invocao de plug-ins por demanda aumenta a ecincia de utilizao de recursos computacionais, pois torna o software mais leve e direcionado. Outro ponto signicativo que a arquitetura que o Parola oferece garante um alto grau de independncia entre os plug-ins. Isso representa uma boa opo para locais onde exista uma grande rotatividade de pessoas como em laboratrios de pesquisa de universidades. importante destacar que no se faz necessrio, por parte do desenvolvedor do plugin, ter um conhecimento aprofundado sobre a arquitetura do sistema, pois a insero de um plug-in se d atravs de regras simples. Dessa forma, o desenvolvedor otimiza seu tempo, utilizando-o no desenvolvimento dos mtodos matemticos, enquanto as questes estruturais cam a cargo do Parola. Supondo-se, ainda, que um plug-in foi mal implementado ou que esteja gerando resultados errneos, esse no compromete toda a aplicao, pois caso seja necessrio, o plug-in pode ser facilmente desabilitado ou substitudo por outro mais atualizado. Somando-se

45

a isso, uma aplicao de processamento de imagens possui diversos pontos de controle, alm de ser responsvel por gerenciar diversas imagens. Dessa forma, mais econmico reescrever um plug-in do que toda a aplicao. Com a utilizao de padres de projeto aplicam-se um conjunto de melhores prticas para a soluo de problemas comuns em projetos de software, favorecendo a busca por reusabilidade de cdigos. medida que o sistema cresce, os padres auxiliam no seu entendimento e extensibilidade, que so caractersticas necessrias a um framework, que busca encapsular uma srie de descries importantes do projeto de software. Em relao aos aspectos estruturais internos ao Parola, pode-se destacar que a implementao dos controladores dos plug-ins seria mais complexa se no fosse a utilizao do padro observer. O padro DAO, por usa vez, permitiu uma implementao do acesso aos dados dos arquivos XML de maneira simples e objetiva. Como trabalhos futuros, pretende-se implementar interfaces para o desenvolvimento dos plug-ins, visando a criao de uma forma padronizada que permita aos plug-ins se comunicarem. Diversas funcionalidades podero tirar proveito dessa caracterstica, como, por exemplo, a implementao de uma linguagem de macro. Outros trabalhos futuros referem-se a comparao da arquitetura que o Parola oferece em relao a outros frameworks para processamento de imagens, alm de buscar comparativos com outras arquiteturas baseadas em plug-ins.

46

REFERNCIAS

BERNI, J. C. A. Desenvolvimento e Implementao de Mtodos de Correo de Iluminao para Imagens Digitais. Santa Maria: Curso de Cincia da Computao. Universidade Federal de Santa Maria., 2007. BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML. 2.ed..ed. [S.l.]: Elservier, 2007. BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. The Unied Modeling Language User Guide. [S.l.]: Addison-Wesley, 1999. BREVES, A.; P., S. Desvendando o Bytecode. Revista Mundojava (ISSN 1679-3978) , Curitiba, [S.l.], n.23, maio 2007. COOPER, J. W. The Design Patterns - Java Companion. [S.l.]: Addison-Wesley, 1998. DARONCO, L. C. Interface 3D para representao da distribuio de cores de imagens digitais em diferentes espaos de cores. Santa Maria: Curso de Cincia da Computao. Universidade Federal de Santa Maria., 2006. DEITEL, H.; DEITEL, P. Java Como programar. Proto Alegre: Bookman, 2004. FAYAD, M. E-Frame: a process-based object-oriented framework for e-commerce. International Conference on Computing, Las Vegas, Junho 2001. FAYAD, M. E.; SCHMIDT, D. C.; JOHNSON, E. R. Building application frameworks object-oriented foundations of framework design. [S.l.]: John Wiley Sons, 1999. FAYAD, M.; HAMU, D. Object-Oriented Enterprise Frameworks,. New York: Wiley & Sons, 1999.

47

FREITAS, D. G. Athena: um framework para a construo de interfaces humanocomputador no domnio da segmentao de imagens. 2006. Dissertao (Mestrado) PPGEP-UFSM, Santa Maria. FRIEDRICH, A. R. Implementao de um Mtodo para Clculo das Fraes de rea de Componentes Homogneos de uma Imagem usando Anlise Linear de Histogramas. Santa Maria: Curso de Cincia da Computao. Universidade Federal de Santa Maria., 2007. GAMMA, E.; HELM, R.; R., J.; VLISSIDES, J. Padres de Projeto. Solues Reutilizveis de software orientado a objetos. Porto Alegre: Bookman, 2005. HAMU, D. Enterprise Frameworks. In: BUILDING APPLICATION FRAMEWORKS: OBJECT-ORIENTED FOUNDATIONS OF FRAMEWORK DESIGN, 1999, New York. Anais. . . John Wiley & Sons, 1999. p.8387. LIANG, S. The JavaTM Native Interface - Programmers Guide and Specication. [S.l.]: Addison-Wesley, 1999. MAZZANTI, E. S. Tcnicas de Reengenharia de Software aplicadas em uma ferramenta de representao 3D da distribuio de cores de imagens digitais. Santa Maria: Curso de Cincia da Computao. Universidade Federal de Santa Maria., 2008. NVIDIA. NVIDIA CUDA Programming Guide. Version 2.1.ed. [S.l.: s.n.], 2008. PARNAS, D.; CLEMENTS, P.; WEISS, D. The Modular Structure of Complex Systems. IEEE Transactions on Software Engineering, [S.l.], n.SE-11, p.259266, 1985. PREE, W. Design Patterns for Object-Oriented Software Development. [S.l.]: Addison-Wesley, 1995. (ACM Press). PREE, W. Hot-Spot-Driven Development. In: Building Application Frameworks: object-oriented foundations of framework design. New York: John Wiley & Sons, 1999. SCHMIDT, D. C.; GOKHALE, A.; NATARAJAN, B. Leveraging application framework. ACM Press, [S.l.], v.Vol. 2 Issue 5, p.6675, 2004.

48

SUN,

M.

Core

J2EE

Patterns

Data

Access

Object.

Disponvel em

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ DataAccessObject.html, Acesso em: Junho de 2009. SUN, M. Independent Tests Demonstrate Write Once Run Anywhere Abilities of Java. Disponvel em http://www.sun.com/smi/Press/sunflash/ 1997-09/sunflash.970918.2.xml, Acesso em: Maro 2008. SUN, M. Trail: the reection api. Disponvel em http://java.sun.com/docs/ books/tutorial/reflect/index.html, Acesso em: Abril de 2009. SUN, M. JavaBeans Concepts. Disponvel em http://java.sun.com/docs/ books/tutorial/javabeans/whatis/index.htm, Acesso em: 2009. SUN, M. Java ME Platform Overview. Disponvel em http://java.sun.com/ javame/technology/index.jsp, Acesso em: Junho de 2009. SUN, M. Java Advanced Imaging (JAI) API. Disponvel em http://java.sun. com/javase/technologies/desktop/media/jai/, Acesso em: Maio de 2009. VITHARANA, P. Risks and challenges of component-based software development. Communication of the ACM, [S.l.], 2003. W3C. Extensible Markup Language (XML). Disponvel em http://www.w3.org/ XML/, Acesso em: Maio de 2009. WELFER, D. Padres de projeto no desenvolvimento de sistemas de processamento de imagens. 2004. Dissertao (Mestrado) Dissertao de Mestrado do PPGEPUFSM, Santa Maria. WOLFINGER, R. Plug-in Architecture and Desing Guidelines for Customizable Enterprise Applications. OOPSLA08, [S.l.], 2008. Abril de