Density

A utilização da técnica de padrões de projetos se iniciou com a clássica obra Design Pattern: elements of reusable object-oriented Software (Gamma et al., 1994), onde diversas boas práticas para solucionar problemas bem conhecidos de orientação a objetos foram catalogadas. Com o advento das plataformas corporativas de desenvolvimento, principalmente a Java 2 Enteprise Edition, diversos padrões de projeto específicos para implementação de arquitetura de sistemas corporativos foram propostos, tais como, os apresentados em Core J2EE Patterns (Malks et al., 2001) e, recentemente, em Patterns of Enterprise Applications (Fowler, 2012). Os padrões corporativos representam boas práticas na modelagem de problemas corporativos, tais como: escalabilidade de aplicações, padrões de integração, padrões arquiteturais, mecanismos de segurança, dentre outros.

Para a implementação de variabilidades em LPS, os padrões de projeto apresentados em (Gamma et al, 1994) ainda continuam sendo uma das mais relevantes contribuições na área. Por isso, serão detalhadas a seguir, com alguns exemplos de sua utilização. Os principais padrões utilizados para modelagem de variabilidades das LPS SIGAA e SIPAC são:

Nome do Padrão Utilização

Factory Method Permite que objetos sejam criados a partir de valores passados para métodos, instanciando assim o objeto correto que implementa um determinado comportamento padrão. Chain of Responsibility Divide um conjunto de responsabilidades entre diferentes

objetos conectados, de forma que, se um objeto não souber responder a uma requisição, passa a função para o próximo objeto da cadeia.

Strategy Define uma família de algoritmos, os encapsula e permite que eles sejam intercambiáveis.

Template Method Define o esqueleto de um algoritmo e permite que alguns de seus passos sejam sobrescritos em classes filhas.

35 3.4.1.1 Factory Method

O padrão Factory Method é amplamente utilizado para a escolha de objetos apropriados de acordo com a configuração do produto da LPS. Para exemplificar seu uso, considere a variabilidade pat-01 (Tabela 3-3) sobre a geração de número de tombos. O sistema SIPAC define três variantes para esta característica: (i) Numeração Sequencial, (ii) Sequencial por ano e (iii) Sequencial por Unidade Gestora. A interface

EstrategiaGeracaoTombo contém métodos relacionados com a geração do número do

tombo. A classe EstrategiaTomboFactory contém o método getInstance(String parameter) que recupera o objeto correto a partir do parâmetro repassado.

Figura 3-4 Fábrica para geração da estratégia de geração de números de tombamentos

A classe ProcessadorTombamento utiliza a fábrica de objetos de geração de

tombos através do seguinte trecho de código:

EstrategiaGeracaoTombo geracaoTombo =

EstrategiaGeracaoTomboFactory.getInstance(ParametrosPatrimonio.ESTRATE GIA_UTILIZADA);

3.4.1.2 Chain Of Responsibility

O padrão Chain of Responsability é aplicado nas LPS para implementar algumas das variabilidades do tipo or-feature. Este tipo de feature é um caso particular de feature alternativa, que permite a seleção de não apenas uma das características

36 pertencentes ao grupo alternativo de características, mas também a seleção de mais de uma característica desse grupo, ou até mesmo nenhuma delas.

No contexto das LPS dos sistemas SIG, exemplos de or-feature são os processamentos dos vínculos e permissões dos usuários. Estes processamentos podem ser compostos por diversas etapas e essas etapas podem variar de uma instituição para outra, ou dentro da mesma instituição, dependendo das mudanças de negócio. Através da aplicação do padrão Chain of Responsability é possível executar uma cadeia de classes que implementam um determinado processamento. As classes são executadas em uma ordem pré-definida, e ao término da execução de uma, inicia-se o processamento da classe seguinte. A Figura 3-5 pode-se verificar a classe base de execução (AcessoMenu) que cria a cadeira de execução através do método createChain. A adição e retirada de processamento na cadeia pode ser realizado através da criação ou remoção de novas classes na cadeira de execução.

Figura 3-5 Criação da cadeira de processamento

3.4.1.3 Strategy

O padrão de projeto Strategy é um dos mais utilizados para implementação de variabilidades de granularidade alta em características alternativas. O padrão define uma família de algoritmos que varia independentemente do cliente que o usa.

Um exemplo de utilização do Strategy no contextos da LPS dos sistemas SIG é a autenticação de usuários. Para implementar este comportamento definiu-se uma interface padronizada com o algoritmo de autenticação (interface

37 com banco de dados; (ii) com LDAP (Lightweight Directory Access Protocol); e (iii) com banco de dados e LDAP. A escolha da variante é feita através do parâmetro

ESTRATEGIA_AUTENTICACAO.

Figura 3-6 Uso do padrão de projeto Strategy na autenticação de usuários

O uso do padrão Strategy em combinação com o Factory Method fornece uma poderosa ferramenta para implementação de variabilidades. O Strategy fornece o mecanismo para generalização de comportamentos variáveis e o Factory Method uma forma eficaz da escolha da variante escolhida na feature alternativa.

3.4.1.4 Template Method

O padrão de projeto Template Method define um esqueleto de algoritmo de uma determinada operação, delegando alguns dos passos para subclasses. Ele delega certos passos do algoritmo para processamento da subclasse sem mudar a estrutura do algoritmo e sem gerar conflitos de código.

Um exemplo do uso do Template Method é a importação de produções da plataforma Lattes através de arquivo XML. O algoritmo de processamento possui um esqueleto padrão com determinadas variações por cada tipo de produção (participação em bancas, capítulo de livros, apresentações de trabalhos, dentre outras), pois, cada um possui dados específicos para serem tratados. A Figura 3-7 ilustra este cenário: a classe ImportaProducaoLattesXML possui o método padrão de processamento (método processar) e um método abstrato denominado statElement, que é usado para processamento do elemento XML. Cada tipo de produção possui uma implementação

38 concreta do startElement para tratamento correto das informações do tipo da produção. Todo o fluxo do algoritmo é invocado através da classe ImportacaoProducaoLattesXML, invocando as subclasses corretas durante a execução do processo.

Figura 3-7 Template Method no processamento de produção do Lattes