1 / 12

Conexões de Saberes

Conexões de Saberes. Amirton Chagas – abc@cin.ufpe.br Paola Accioly – prga@cin.ufpe.br http://www.cin.ufpe.br/~abc/TAES. O Programa Conexões de Saberes.

konala
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 – abc@cin.ufpe.br Paola Accioly – prga@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.

  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. Variaçõesescolhidas • 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.

  5. Variação 1 – Interface Gráfica: CadastrarAtividade • 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: CadastrarAtividade • 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: CadastrarAtividade • 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: CadastrarAtividade • 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: CadastrarAtividade • Técnicas não usadas: • Componentes • O projeto não possui implementação de containersOSGi 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”

  10. Variação 2 – Classes queenvolvemAtividade • 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 queenvolvemAtividade • 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?

More Related