Conexões de Saberes

1. Conexões de Saberes Amirton Chagas Paola Accioly abc@cin.ufpe.br prga@cin.ufpe.br

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. Escopo do estudo • Para tornar possível a realização do estudo de caso por uma equipe reduzida, limitamos o escopo de nosso estudo em Features às áreas relacionadas à Atividades • Os refactorings de OO sugeridos ao realizar a análise de clones foram implementados independente da restrição de escopo acima.

5. Feature model

6. Features – Cadastro • A Feature obrigatóra de Cadastro é composta por outras 4 features, das quais uma é obrigatória e as outras 3 são opcionais • Tem como objetivo fornecer uma tela de cadastro que se adéqüe às necessidades do produto, disponibilizando os campos requeridos para cada versão.

7. Features – Cadastro • Mecanismo usado: AOP • Permite que posteriormente qualquer um dos outros campos atualmente obrigatórios se torne opcional sem maiores mudanças; • Mantém a legibilidade do código base, fato que não ocorreria caso usássemos Compilação Condicional por exemplo. • Possibilidade de adaptação à ferramenta FLiP • Alternativas possíveis: • CGT – Mecanismo muito pesado para uma variação simples. “Matar mosquito com um canhão” • Polimorfismo de Subtipo – Exigiria a criação de diversas classes muito semelhantes entre si.

8. Features - Cadastro • Alternativas possíveis: • Compilação Condicional – Grande impacto na leitura do código • Parametrização por Arquivos de Propriedade – Foi considerada a segunda melhor opção para esta feature, “perdendo” para aspectos apenas no fato de não ser suportada por FLiP.

9. Features – Relatório • A Feature opcional de Relatório é composta por mais duas features, opcionais com a possibilidade de ocorrência simultânea. • A possibilidade de existência das subfeatures de Relatório está restringida pela escolha dos itens da primeira parte • Uso de constraints no modelo • Sua função é gerar relatórios operacionais do programa, auxiliando os gestores a tomar decisões de quais novas atividades devem ser criadas, e quais das atuais merecem maior atenção

10. Features - Relatório • Mecanismo usado: AOP + Polimorfismo de Subtipo • Motivos semelhantes aos da escolha por AOP em cadastro; • O uso de um RelatorioGenerico facilitou a implementação dos Relatórios como um todo • Permite que a adição de novos relatórios seja feita de forma transparente, apenas adicionando novos aspectos; • Mantém a legibilidade do código base, fato que não ocorreria caso usássemos Compilação Condicional por exemplo. • Possibilidade de adaptação à ferramenta FLiP

11. Features - Relatório • Alternativas possíveis: • Compilação Condicional –Impacto na leitura do código, técnica ficaria muito espalhada • Componentes – Seria possível, porém, assim como CGT para a feature de Cadastro, seria um grande esforço que pode ser resolvido com técnicas mais simples de mesmo grau de eficiência.

12. Reestruturação do estudo de caso • Foi necessária a criação de packages para manter os aspectos • Facilitar a implementação, usando within para evitar loops infinitos • br.ufpe.cin.conexao.gui.aspectos • Parte do código que já existia migrou para os aspectos • Todo o código existente que era relacionado com qualquer uma das features passou a ser parte do aspecto desta feature • Exemplo: • br.ufpe.cin.conexao.gui.CadastroAtividade

13. Novas Variações introduzidas • Foram incluídas as variações relativas às features de Relatório por Carga Horária e por Faixa Etária.

14. Novos Pontos de Variação • Foram incluídos novos pontos de variação para as features relativas a Relatórios, anteriormente não consideradas. • Estes pontos de variação são: • Tela principal da GUI (br.ufpe.cin.conexao.gui.FramePrincipal), para adicionar itens de menu que possibilitem a navegação até as telas dos Relatórios • O pacote br.ufpe.cin.conexao.gui, que dependendo da inclusão ou não da feature terá classes adicionadas ou removidas.

15. Clones antes da reestruturação

16. Clones após a reestruturação

17. Clones • Análise dos clones levou à detecção de algumas más escolhas de projeto utilizadas na implementação • Resolvidas com • Refatorações simples com OO • Remoção de classes sem sentido, stubs • Substituição de objetos de classes ineficientes próprias por outras mais eficientes de Java. • Apesar disto, na média, o código era bom e precisou de poucas alterações • Análise dos clones não levou a descoberta de novas features / variações / variation points • O tamanho reduzido do sistema talvez deva ser levado em conta neste fato

18. Dificuldades • Ambiente... Foi muito complicado conseguir máquinas no CIn para trabalhar durante os horários reservados à realização do estudo • Grads reservados, e nos que sobram, poucas máquinas que funcionam • Curva de aprendizado do Captain Feature • No início é complicado de usar. Após se acostumar, é aceitável • Instalação e uso de FLiP • A ferramenta se mostrou complicada desde o início. “Resistia” a ser instalada em certas máquinas, e em algumas, após a instalação, simplesmente não funcionava

19. Dificuldades • Técnicas disponíveis em FLiP • A disponibilização de apenas Compilação Condicional e Aspectos em FLiP nos fez voltar nosso estudo basicamente às possibildades de usar estas duas abordagens. • Algumas das extrações de FLiP para AOP não funcionaram, o que nos levou a usar a ferramenta não para realizar o estudo como um todo, mas apenas por teste/aprendizado

20. Atividades – Tempo * Exigiu a programação de novas classes do zero

21. Conclusões • Enquanto na primeira parte do projeto, utilizamos os mecanismos de forma arbitrária, a título de conhecimento para verificar seu funcionamento, nesta parte usamos conscientemente alguns mecanismos, analisando vantagens e desvantagens em relação aos outros disponíveis • A análise dos clones fez com que o código ficasse mais limpo, e apesar de não termos encontrado novas features ou variações, foi muito útil.

22. ? Dúvidas?