1 / 22

Conexões de Saberes

Conexões de Saberes. Amirton Chagas Paola Accioly abc@cin.ufpe.br prga@cin.ufpe.br. 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

aaron
Télécharger la présentation

Conexões de Saberes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related