(e várias outras coisas importantes para a sua formação)
Professor: Paulo Borba
Nome oficial: Tópicos Avançados em Linguagens Computacionais (graduação), Tópicos Avançados em Linguagem de Programação 3 (pós-graduação)
Cronograma
3/3 (8hs, na sala D003): Discutir problemas de modularidade com orientação a objetos, e conceitos básicos de orientação a aspectos
6/3 (10hs, na sala D003): Discutir identificação e atribuição de concerns, e métricas para identificação de crosscutting concerns. Definir equipe e estudo de caso a ser usado no projeto.
antes estudar em detalhe Identifying, Assigning, and Quantifying Crosscutting Concerns, de Marc Eaddy, Alfred Aho, and Gail C. Murphy; ICSE Workshop on Assessment of Contemporary Modularization Techniques (ACoM 2007), Minneapolis, MN, May 22, 2007.
13/3: Analisar em detalhe o estudo de caso escolhido pela sua equipe, e usar o ConcernTagger para marcar concerns e calcular métricas do estudo de caso (primeira parte do projeto)
17/3: Continuar a atividade anterior (primeira parte do projeto)
20/3: Semana Santa
24/3: Continuar a atividade anterior (primeira parte do projeto)
27/3 (10hs, na sala D003): Apresentar resultados do seu projeto
planejar a sua apresentação para 15 minutos, com slides sobre
o sistema considerado (funcionalidades principais, número de classes e linhas de código, tanto do sistema como um todo quanto, se for o caso, do subsistema analisado pela sua equipe)
concerns identificados no sistema (lista dos concerns, justificativa da escolha do que foi considerado concern, outras escolhas cogitadas mas não seguidas por vocês, hierarquia de concerns)
resumo da atividade de atribuição de concerns (número de linhas de código marcadas, tempo total levado para marcar, 3 exemplos não triviais de concerns e código associado marcado, exemplo de código relacionado a mais de um concern, dúvidas e problemas surgidos durante a atribuição)
métricas geradas pela ferramenta com base na atribuição feita pela sua equipe
conclusões (que concerns vocês acham que são crosscutting, em relação a que outro concern? as métricas foram úteis? estão corretas? por que?)
enviar a sua apresentação (arquivo ppt ou pdf, com nome no seguinte formato loginsDosMembrosEmOrdemAlfábetica-parte1.ppt) para phmb antes da aula
31/3 (8hs, no laboratório Grad4): Discutir identificação de concerns através da detecção de código duplicado
seguir roteiro de instalação da ferramenta de detecção de códigos duplicados
3/4: Usar a ferramenta de detecção de clones de código para identificar concerns no estudo de caso (segunda parte do projeto)
7/4 (8hs, na sala D003): Apresentar resultados do seu projeto
planejar a sua apresentação para 5 minutos, com slides sobre
gráfico de clones de código, gerado pela ferramenta
exemplos de clones encontrados
parâmetros usados para configuração da ferramenta, quantidade de clones encontrados, lista de concerns associados a estes clones, quantidade de clones por concern
enviar a sua apresentação (arquivo ppt ou pdf, com nome no seguinte formato loginsDosMembrosEmOrdemAlfábetica-parte2.ppt) para phmb antes da aula
10/4 (10hs, na sala D003): Discutir construções básicas de AspectJ
estudar em detalhe Getting started with AspectJ, de Gregor Kiczales et al, Communications of the ACM, 44(10), pp. 59-65, October 2001.
estudar em detalhe Distribution and Persistence as Aspects, de Sérgio Soares, Paulo Borba, e Eduardo Laureano, Software: Practice & Experience, 36(7):711-759, 2006. John Wiley & Sons.
estudar em detalhe o artigo I want my AOP!, de Ramnivas Laddad, JavaWorld.com, 2002, partes 1 e 2
caso interessado em saber mais sobre tratamento de concorrência, olhar Concurrency Manager, de Sérgio Soares e Paulo Borba, First Latin American Conference on Pattern Languages of Programming - SugarLoafPLoP'01, pages 221-231, Rio de Janeiro, Brazil, October 2001.
14/4 (8hs, na sala D003): Discutir construções avançadas de AspectJ
estudar em detalhe Modularizing design patterns with aspects: a quantitative study, de Alessandro Garcia, Cláudio Sant'Anna, Eduardo Figueiredo, Uirá Kulesza, Carlos Lucena, e Arndt von Staa. In Proceedings of the 4th international conference on Aspect-oriented software development, March 2005.
estudar em detalhe Deriving refactorings for AspectJ, de Leonardo Cole e Paulo Borba. In Proceedings of the 4th international conference on Aspect-oriented software development, March 2005.
28/4: Reestruturar o estudo de caso escolhido pela sua equipe para evitar duplicação de código e implementar crosscutting concerns com aspectos (terceira parte do projeto)
sempre que adequado, usar os refactorings do Eclipse, mas verificar as pré-condições extras necessárias quando aspectos são usados
sempre que adequado, usar refactorings orientados a aspectos referenciados na aula anterior
sempre que adequado, usar padrões de projeto orientados a aspectos e idiomas AspectJ referenciados na aula anterior
registrar que refactorings, padrões e idiomas foram usados, e quantidade de vezes que cada um foi utilizado
registrar que modificações no código não correspondem aos refactorings, padrões e idiomas referenciados na aula anterior
usar a ferramenta de detecção de códigos duplicados para verificar a qualidade da versão resultante do estudo de caso
identificar que mudanças feitas foram derivadas de sugestões de resultados de partes anteriores do projeto, e quais resultaram da execução desta parte do projeto; contrastar resultados anteriores do projeto com os resultados atuais (tipo os crosscutting concerns identificados na primeira parte foram todos modularizados? por que? os clones detectados na segunda parte foram todos modularizados? por que?)
colocar resultados (versões atualizadas das apresentações, código analizado e marcado com o ConcernTagger, código reestruturado, documentos analizados, etc.) de todas as partes do seu projeto na seção Projetos realizados mais abaixo
1/5: Dia do Trabalho
5/5: Continuar a atividade anterior (terceira parte do projeto)
8/5: Continuar a atividade anterior (terceira parte do projeto)
12/5: Continuar a atividade anterior (terceira parte do projeto)
15/5: Continuar a atividade anterior (terceira parte do projeto)
19/5 (8hs, no laboratório Grad4): Apresentar resultados do seu projeto
cada membro da equipe deve ser capaz de falar sobre qualquer parte do código original e resultante
preparar apresentação resumindo os resultados, com indicadores, percentuais e gráficos ilustrando os principais pontos solicitados na descrição da terceira parte do projeto
22/5: Corpus Christi
26/5 (8hs, no laboratório Grad4): Apresentar resultados do seu projeto
29/5 (10hs, na sala D003): Discutir reconciliação de modularidade OO com modularidade OA
estudar em detalhe Specifying design rules in aspect-oriented systems, de Marcos Dósea, Alberto Costa Neto, Paulo Borba, e Sérgio Soares. In I Latin American Workshop on Aspect-Oriented Software Development - LA-WASP'2007, affiliated with SBES'07, pages 67-78, João Pessoa-PB, Brazil, October 2007.
2/6: Descrever design rules para estudo de caso escolhido pela sua equipe
atualizar resultados na seção Projetos realizados mais abaixo
5/6: Continuar a atividade anterior (quarta parte do projeto)
9/6 (8hs, no laboratório Grad4): Apresentar resultados do seu projeto
mostrar código das design rules identificadas
12/6 (10hs, na sala D003): Discutir tendências da construção de software e suas linguagens