CONEXÕES DE SABERES
Amirton Chagas – [email protected]
Paola Accioly – [email protected]
http://www.cin.ufpe.br/~abc/TAES
O PROGRAMA CONEXÕES DE SABERES

O Conexões de Saberes oferece a jovens
universitários
de
origem
popular
a
possibilidade de desenvolver a capacidade de
produzir conhecimentos científicos



Criar capacidade de intervir em seu território de
origem.
Possibilita a avaliação dos estudantes sobre o
impacto das políticas públicas desenvolvidas em
espaços populares.
Os participantes do programa recebem apoio
financeiro e metodológico.
2
O PROGRAMA CONEXÕES DE SABERES



Está implementado em diversas universidades do
país, se adequando à realidade e as necessidades
locais de cada instituição.
Necessita de um sistema para gerenciar o seu
funcionamento
Não é necessário um sistema completamente
diferente para cada universidade. Apesar das
diferenças em cada local, existe uma vasta base
comum a todas as instituições

Possibilidade de criar uma Linha de Produtos de
software para atender as necessidades específicas de
cada instituição
3
VARIAÇÕES ESCOLHIDAS


Os pontos de variação mais adequados ao estudo que
nos propomos são a Interface Gráfica e as classes que
envolvem Atividades
De acordo com a instituição, existe ou
necessidade de armazenar dados relativos a:



não
a
Carga Horária da atividade
Faixa etária dos participantes
Código do projeto ao qual a atividade está vinculada

A necessidade das instituições em torno dos dados
acima variam desde “nenhum deles” até “todos eles”.

Algumas instituições possuem Atividades de Formação e
de Lazer, outras, apenas Atividades de Formação.
4
VARIAÇÃO 1 – INTERFACE GRÁFICA:
CADASTRAR ATIVIDADE

Técnicas:
 Compilação Condicional
A própria classe contém o
código de geração dos
campos e é injetado nela
também todo o código
para mostrá-los ou não.
 Refactor: Agrupou-se o
código de criação dos
campos para cada variação


Parametrização por
Arquivos de Propriedade
Semelhante à CC, no
entanto, pode ser mudado
em runtime e não necessita
em Java de ferramentas ou
plug-ins não-nativos
 Mesmo refactor de CC

5
VARIAÇÃO 1 – INTERFACE GRÁFICA:
CADASTRAR ATIVIDADE

Orientação a Aspectos
A definição de que se deve adicionar ou não os campos
fica em arquivos separados, um para cada variação.
 Código da classe fica muito mais limpo e legível.
 Refactor: O código de criação dos componentes foi
migrado da classe para os respectivos aspectos.

VARIAÇÃO 1 – INTERFACE GRÁFICA:
CADASTRAR ATIVIDADE

Mixins
Cria-se classes com cada variação menor herdando da
classe já existente
 Para os casos de necessidade de usar mais de uma das
variações menores, cria-se uma classe com herança
múltipla das classes previamente criadas.
 Refactor: O código de criação dos componentes foi
migrado da superclasse para as respectivas subclasses.

VARIAÇÃO 1 – INTERFACE GRÁFICA:
CADASTRAR ATIVIDADE

Polimorfismo de Subtipo
Cria-se uma subclasse da superclasse para cada
variação, com todo o código necessário nela
 Duplicação de código 
 Para a escolha de qual classe usar, pode-se usar PFP,
CC, makefiles... Nossa escolha: CC

VARIAÇÃO 1 – INTERFACE GRÁFICA:
CADASTRAR ATIVIDADE

Técnicas não usadas:

Componentes


PPP


Não faria sentido usar PPP (Generics) no nosso caso, para a
escolha de qual modelo de tela seria usado, apesar de ser
possível implementar usando esta técnica
CGT


O projeto não possui implementação de containers OSGi para
podermos usar as ferramentas fornecidas
Seria uma técnica interessante para ser usada na variação
escolhida
 Não tivemos sucesso ao utilizar a ferramenta velocity.
AOM

“Canhão para matar uma mosca”
9
VARIAÇÃO 2 – CLASSES QUE ENVOLVEM
ATIVIDADE
A Variação 2 se mostrou muito semelhante à
variação 1.
 A principal diferença foi a possibilidade de
usar PPP razoavelmente


Para as outras técnicas, os comentários da
variação 1 são os mesmos, inclusive de
implementação.

Apesar de, claro, os refactors terem sido diferentes, a
essência deles foi a mesma.
VARIAÇÃO 2 – CLASSES QUE ENVOLVEM
ATIVIDADE

Parametrização por Polimorfismo Paramétrico
Temos mais de um tipo de atividade. Criamos duas
classes básicas filhas de Atividade.
 Algumas classes que usavam Atividade, passaram a
receber o parâmetro do tipo de Atividade ao qual ela
estaria associada


Depois, usamos o objeto pelo tipo polimorficamente
parametrizado anteriormente.
Dúvidas?