CONEXÕES DE SABERES Amirton Chagas – [email protected]@cin.ufpe.br Paola Accioly –...
-
Upload
barbara-rodrigues-aquino -
Category
Documents
-
view
221 -
download
5
Transcript of CONEXÕES DE SABERES Amirton Chagas – [email protected]@cin.ufpe.br Paola Accioly –...
CONEXÕES DE SABERESAmirton Chagas – [email protected] 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 não a necessidade de armazenar dados relativos 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
5
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
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 O projeto não possui implementação de containers OSGi
para podermos usar as ferramentas fornecidas 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 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?