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?