A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

CONEXÕES DE SABERES Amirton Chagas – Paola Accioly –

Apresentações semelhantes


Apresentação em tema: "CONEXÕES DE SABERES Amirton Chagas – Paola Accioly –"— Transcrição da apresentação:

1 CONEXÕES DE SABERES Amirton Chagas – abc@cin.ufpe.brabc@cin.ufpe.br Paola Accioly – prga@cin.ufpe.brprga@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. 2

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 3

4 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

5 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

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

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

8 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

9 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

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

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

12 Dúvidas?


Carregar ppt "CONEXÕES DE SABERES Amirton Chagas – Paola Accioly –"

Apresentações semelhantes


Anúncios Google