Desenvolvimento Progressivo de Programas Concorrentes Orientados a Objetos Aluno: Sérgio Soares Orientador: Paulo Borba

Conteúdo zMotivação zMétodo para tratamento de concorrência zAplicação prática do método zImpacto em eficiência zConclusões e Trabalhos Futuros

Motivação zAumento do uso de ambientes concorrentes yWWW (World Wide Web) yNecessidade de eficiência

Ambiente concorrente zComplexidade elevada yimplementação ytestes zTratamentos baseados na intuição yfalta de um padrão zImpacto negativo em ycorretude ymanutenção

Implementação Progressiva zPim ypadrões de projeto yorientação a objetos zAspectos ypersistência ydistribuição yconcorrência

Classes da arquitetura

Método para tratamento de Concorrência zDiretrizes ygerais yclasses básicas ycoleções de dados ymecanismo de persistência yfachada e coleções de negócio

Diretrizes gerais zEvitar a execução concorrente de métodos não atômicos public class ConjuntoPessoas { private Pessoa[] pessoas; private int indice; public void inserir(Pessoa p) { pessoas[indice] = p; indice = indice + 1; } //... }

Exemplo thread1thread2 conjunto.inserir(p1); ConjuntoPessoas conjunto = //... conjunto.inserir(p2); pessoas[indice] = p1; indice = indice + 1; pessoas[indice] = p2; indice = indice + 1; pessoas p1 indice p2 indice

Diretrizes específicas - classes básicas zImpedir a atualização concorrente de cópias de um objeto zMecanismo de timestamp yobjetos só podem ser atualizados se não houver uma atualização mais recente

zNas coleções de dados que utilizam SGBD ycertificar-se do uso correto de SQL (SGBDR) yutilizar transações quando necessário zNas que não utilizam SGBD ytratar o acesso a estrutura de dados yimplementar o serviço de transações Diretrizes específicas - coleções de dados

zEvitar acesso concorrente a estrutura de dados que mantém os canais de comunicação ysincronizar métodos Diretrizes específicas - mecanismo de persistência

zIdentificar regras de negócio que ocasionam situações de corrida ysincronizar métodos yusar o gerenciador de concorrência xsincroniza apenas os threads que podem interferir entre si Diretrizes específicas - coleções de negócio e fachada

O Método zUtiliza as diretrizes zTrata concorrência de baixo para cima na hierarquia da arquitetura zTarefas yT1 - Tratar classes básicas yT2 - Tratar coleções de dados yT3 - Tratar mecanismo de persistência yT4 - Tratar coleções de negócio e fachada

T1 - Tratando classes básicas zNas classes que os objetos sofrem acesso concorrente yaplicar diretrizes gerais zAplicar diretrizes específicas nas demais

Aplicação prática do método zAplicar o método a quatro sistemas ySistema 1 xdesenvolvido na universidade utilizando o Pim ySistemas 2, 3 e 4 xjá implementados xem funcionamento xutilizar o método para analisar os sistemas xdesenvolvidos por duas empresas empresa X - sistemas 2 e 3 empresa Y - sistema 4

Sistema 1 zImplementa parte da aplicação A zMostrou um pequeno impacto do método ymenos de 10% do tempo de desenvolvimento ymenos de 0,5% das linhas de código zNúmero do experimento y80 classes y9.562 linhas ycerca de 33 horas de desenvolvimento

Sistema 2 zImplementa toda a aplicação A zJá trata concorrência ytimestamp ytransações na fachada quando necessário zProblemas encontrados ymal uso do mecanismo de exceções ymecanismo de persistência com falhas no tratamento aplicado

zNúmeros da análise y107 classes y linhas y9 horas para analisar o sistema xsem realizar os tratamentos Sistema 2

Sistema 3 zImplementado pela mesma empresa do Sistema 2 yrealiza os mesmos tratamentos yutiliza o mesmo mecanismo de persistência zProblemas ydiferenças nos tratamentos aplicados em relação ao Sistema 2 yregras de negócio misturadas com os dados yprática de programação inocente

zProblemas (cont.) yduas coleções de dados sem SGBD precisam de tratamento xarray e socket zNúmeros da análise y66 classes y7.805 linhas y4,5 horas para analisar o sistema xsem realizar os tratamentos Sistema 3

Sistema 4 zTambém já trata concorrência zImplementado pela empresa que desenvolveu o mecanismo de persistência yutilizado pelos sistemas 2, 3 e 4 zProblemas yuso desnecessário de transações yuso desnecessário de sincronização xusar o timestamp

zNúmeros da análise y325 classes y linhas yQuase 8 horas para analisar o sistema xsem realizar as correções necessárias zTempo de análise menor devido ao conhecimento prévio do sistema Sistema 4

Impacto em eficiência zDiferentes tratamentos de concorrência yfachada com todos os método sincronizados yfachada com transações em todos os métodos ycoleção de negócio com métodos sincronizados ycoleção de negócio utilizando o gerenciador de concorrência yaplicando o timestamp yaplicando o método definido

zApenas dois destes tratamentos garantem a corretude se aplicados isoladamente yfachada sincronizada yaplicando o método Impacto em eficiência

Comparação

Comparação com métodos pesados

Conclusões zPadrão para tratamento de concorrência zGanho em qualidade de software zValidação das diretrizes definidas zAnalisar sistemas já tratados

zImpacto de diferentes tratamentos zImpacto pequeno da aplicação do método zProposta de padrões de projetos zFonte bibliográfica Conclusões

Trabalhos futuros zDefinir as regras utilizando métodos formais yprovas formais das regras zDesenvolver um método com suporte a especificação ysistemas críticos zModificar o método para ambiente EJB zDesenvolver ferramentas yprodutividade a curto prazo

zDocumentar os padrões de projeto definidos ytimestamp e gerenciador de concorrência zEstruturar melhor o método sem misturar aspectos de concorrência com outros aspectos yregras de negócio, dados yprogramação adaptativa Trabalhos futuros

Trabalhos relacionados zConcurrent Programming in Java ypadrões de projeto e regras de sincronização ytratamento de concorrência durante a implementação dos requisitos funcionais zRemoving Unnecessary Syncronization in Java yremove sincronizações em tempo de compilação ynão garante corretude do sistema original