Conexões de Saberes

1. Conexões de Saberes Amirton Chagas – abc@cin.ufpe.br Paola Accioly – prga@cin.ufpe.br http://www.cin.ufpe.br/~abc/TAES

2. 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.

3. 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

4. Variaçõesescolhidas • 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.

5. Variação 1 – Interface Gráfica: CadastrarAtividade • 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

6. Variação 1 – Interface Gráfica: CadastrarAtividade • 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.

7. Variação 1 – Interface Gráfica: CadastrarAtividade • 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.

8. Variação 1 – Interface Gráfica: CadastrarAtividade • 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

9. Variação 1 – Interface Gráfica: CadastrarAtividade • Técnicas não usadas: • Componentes • O projeto não possui implementação de containersOSGi 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”

10. Variação 2 – Classes queenvolvemAtividade • 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.

11. Variação 2 – Classes queenvolvemAtividade • 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.

12. ? Dúvidas?