Desenvolvimento Progressivo de Programas Concorrentes Orientados a Objetos

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

Conteúdo z. Motivação z. Método para tratamento de concorrência z. Aplicação prática do método z. Impacto em eficiência z. Conclusões e Trabalhos Futuros

Motivação z. Aumento do uso de ambientes concorrentes y. WWW (World Wide Web) y. Necessidade de eficiência

Ambiente concorrente z. Complexidade elevada yimplementação ytestes z. Tratamentos baseados na intuição yfalta de um padrão z. Impacto negativo em ycorretude ymanutenção

Implementação Progressiva z. Pim ypadrões de projeto yorientação a objetos z. Aspectos ypersistência ydistribuição yconcorrência

Classes da arquitetura

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

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

Exemplo Conjunto. Pessoas conjunto = thread 1 thread 2 1 conjunto. inserir(p 1); pessoas[indice] = p 1; 2 indice = indice + 1; 3 indice pessoas //. . . p 2 p 1 conjunto. inserir(p 2); pessoas[indice] = p 2; indice = indice + 1;

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

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

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

Diretrizes específicas coleções de negócio e fachada z. Identificar 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

O Método z. Utiliza as diretrizes z. Trata concorrência de baixo para cima na hierarquia da arquitetura z. Tarefas y. T 1 y. T 2 y. T 3 y. T 4 - Tratar classes básicas coleções de dados mecanismo de persistência coleções de negócio e fachada

T 1 - Tratando classes básicas z. Nas classes que os objetos sofrem acesso concorrente yaplicar diretrizes gerais z. Aplicar diretrizes específicas nas demais

Aplicação prática do método z. Aplicar o método a quatro sistemas y. Sistema 1 xdesenvolvido na universidade utilizando o Pim y. Sistemas 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 z. Implementa parte da aplicação A z. Mostrou um pequeno impacto do método ymenos de 10% do tempo de desenvolvimento ymenos de 0, 5% das linhas de código z. Número do experimento y 80 classes y 9. 562 linhas ycerca de 33 horas de desenvolvimento

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

Sistema 2 z. Números da análise y 107 classes y 21. 204 linhas y 9 horas para analisar o sistema xsem realizar os tratamentos

Sistema 3 z. Implementado pela mesma empresa do Sistema 2 yrealiza os mesmos tratamentos yutiliza o mesmo mecanismo de persistência z. Problemas 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

Sistema 3 z. Problemas (cont. ) yduas coleções de dados sem SGBD precisam de tratamento xarray e socket z. Números da análise y 66 classes y 7. 805 linhas y 4, 5 horas para analisar o sistema xsem realizar os tratamentos

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

Sistema 4 z. Números da análise y 325 classes y 83. 865 linhas y. Quase 8 horas para analisar o sistema xsem realizar as correções necessárias z. Tempo de análise menor devido ao conhecimento prévio do sistema

Impacto em eficiência z. Diferentes 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

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

Comparação

Comparação

Comparação

Comparação com métodos pesados

Comparação com métodos pesados

Comparação com métodos pesados

Conclusões z. Padrão para tratamento de concorrência z. Ganho em qualidade de software z. Validação das diretrizes definidas z. Analisar sistemas já tratados

Conclusões z. Impacto de diferentes tratamentos z. Impacto pequeno da aplicação do método z. Proposta de padrões de projetos z. Fonte bibliográfica

Trabalhos futuros z. Definir as regras utilizando métodos formais yprovas formais das regras z. Desenvolver um método com suporte a especificação ysistemas críticos z. Modificar o método para ambiente EJB z. Desenvolver ferramentas yprodutividade a curto prazo

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

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