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

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

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.

FEATURE MODEL

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.

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.

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.

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

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

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.

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

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.

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.

CLONES ANTES DA REESTRUTURAÇÃO

CLONES APÓS A REESTRUTURAÇÃO

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

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

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

ATIVIDADES – TEMPO Atividade Técnica Tempo

Identificação de features Clones e Manualmente

05 horas

Desenho do modelo de features

CaptainFeature 02 horas

Outras atividades iniciais 01 horas

Extração das features* FLiP e Manualmente 04 horas

Inclusão dos ponto de variação

Manualmente 03 horas

Adição das variações* 08 horas

Reestruturação do código* Clones / OO 04 horas

Montagem do configuration knowledge

05 horas

Overhead de instalação de FLiP / Problemas com o CIn

06 horas

* Exigiu a programação de novas classes do zero

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.

Dúvidas?