4.4 Implementação
4.5.9 Operação condicional
As escolhas (externa e interna) não são as únicas formas de escolhas suportadas pelo AJCSP. Como na maioria das linguagens de programação, a estrutura de condição ifThe- nElse também é suportada. Portanto, através da avaliação de um valor boleano, fluxos diferentes podem ser tomados.
4.5. TRADUÇÃO Estrutura condicional. i f (π) t h e n ( P ( ) ) e l s e (Q ( ) ) Tradução. i f (π) { ( new P ( ) ) . r u n ( ) ; } e l s e { ( new Q ( ) ) . r u n ( ) ; }
A estrutura condicional avalia π, que é uma variável do tipo boleano, que pode ser lida de um canal ou retornada de um método. Apenas as variáveis declaradas no escopo AJCSP, utilizadas para receber valores dos canais, e métodos declarados na classes são avaliados como expressões condicionais.
Se π for verdadeiro, o processo que estiver no escopo do then é executado. Caso contrário, o processo que estiver no escopo do else é executado.
4.5.10
Paralelismo
O operador de paralelismo permite que dois processos distintos possam executar seus comportamentos concorrentemente, onde o operador [||] separa os processos.
Paralelismo
P1 [||] P2
Tradução
C S P r o c e s s [ ] p r o c e s s o s = new C S P r o c e s s [ ] { new P1 ( ) , new P2 ( ) } ; P a r a l l e l p a r a l l e l = new P a r a l l e l ( p r o c e s s o s ) ;
p a r a l l e l . r u n ( ) ;
Apesar de existir uma diferença na semântica entre interleaving e paralelismo, o AJCSP pode tratar as duas formas no operador paralelo. Isso quer dizer que, se existir algo comoα -> P [||] α -> Q, o paralelismo acontecerá, já que o eventoα está sendo sincronizado. Consequentemente os processos P e Q executarão normalmente em paralelo. No caso do paralelismo sem a sincronização dos eventos P [||] Q, os processos P e Q formam um interleaving, pois não existem eventos para sincronização.
4.6. SUMÁRIO
4.6
Sumário
Este capítulo traz detalhes sobre a abordagem AJCSP. Um compilador é proposto para reconhecer uma especificação concorrente, introduzida em classes Java através de ano- tações. Essas anotações seguem uma estrutura sintática baseada em CSP. Consequente- mente, tornando a programação mais abstrata.
O objetivo do compilador é traduzir toda especificação concorrente das anotações em código JCSP, que posteriormente são injetadas nas classes originais utilizando pro- gramação orientada a aspectos.
A sintaxe utilizada no AJCSP sofre algumas modificações, quando comparado com CSP. Por exemplo, a possibilidade de usar chamada de métodos no operador de pre- fixo, criando uma interação entre a especificação concorrente com o código de regra de negócio, separando totalmente as responsabilidades.
Conclui-se que a abordagem AJCSP provê uma abordagem de especificação com- portamental em alto nível quando comparado com outras abordagens como java thread, facilitando a introdução e/ou modificação de um comportamento específico, como tam- bém maior modularização entre a camada de negócio e a programação comportamental do sistema.
O próximo capítulo conduz um experimento que avalia os benefícios e restrições do AJCSP diante de outras abordagens como Java Thread e JCSP.
5
Estudo de Caso
5.1
Introdução
Nesta seção apresentaremos um estudo de cado para avaliar o desempenho da abordagem AJCSP, quando comparados ao JCSP, bem como ao Java threads. O objetivo principal do estudo consiste em aferir a contribuição da abordagem AJCSP na produção de um código concorrente mais simples, comparando-a com outras abordagens. A avaliação será baseada na modularidade, onde se analisará a concorrência do sistema criado.
Para tanto, o presente estudo considerará as seguintes métricas de qualidade: (i) es- palhamento da concorrência; (ii) entrelaçamento da concorrência e (iii) código sequen- cial.
Portanto, formulamos alguns questionamentos a fim de que sejam respondidos, com o objetivo de verificar a consistência do estudo de caso proposto.
Qual abordagem contribui para:
P1. diminuição do espalhamento da concorrência?
P2. diminuição do entrelaçamento entre concorrência o e código sequencial (regra de negócio)?
P3. diminuição do número de componentes?
P4. diminuição do acoplamento entre o componente de concorrência com os demais componentes da classe?
P5. diminuição de linhas de código em componentes?
5.2. SUITE DE MÉTRICAS P7. diminuição do número de atributos e operações?
P8. o desenvolvimento de sistema concorrente em alto nível?
Nas próximas seções, serão discutidos os grupos de métricas empregadas assim como os procedimentos de avaliação
5.2
Suite de métricas
Uma suite de métricas (Sant’anna et al., 2003; Garcia et al., 2005; Eaddy et al., 2007,
2008) será utilizada para avaliar a separação da concorrência do código sequencial, acoplamento dos componentes e tamanho de código. Estas métricas foram adaptadas a partir das métricas da orientação a objetos (Chidamber and Kemerer, 1994) para ser aplicado para a orientação a aspectos. Elas têm sido utilizadas em vários trabalhos expe- rimentais (Garcia et al., 2005, 2006; Eaddy et al., 2007, 2008; Figueiredo et al., 2008;
Bonifácio and Borba, 2009). A Tabela5.1sumariza cada métrica utilizada neste estudo de caso.
As métricas de separação CDC (Garcia et al., 2005), CDO (Garcia et al., 2005) e LOCC (Eaddy et al.,2008) contribuem na verificação da existência da concorrência nas classes do sistema. Uma vez que elas podem aferir quantos componentes e/ou operações no sistema implementam concorrência. Para quantificar a concorrência entre os com- ponentes, são utilizadas métricas DOS (Eaddy et al., 2007) e DOT (Eaddy and Eaddy,
2008), com objetivo de saber como a concorrência está espalhada e/ou embaralhada entre os componentes.
Para algumas métricas, valores baixos implicam melhores resultados. Por exemplo, a métrica de espalhamento (DOS) varia de 0 (completamente concentrado em um só local) até 1 (completamente espalhado, presente em todos os componentes) (Eaddy et al.,
2008).
Embora, Eaddy (Eaddy et al.,2008) tente demonstrar que a métrica DOS quantifica mais precisamente a modularidade que as métricas CDC e CDO (Sant’anna et al.,2003;
Garcia et al., 2005), ambas fora utilizadas, porque algumas aplicações têm apresentado elevados valores da métrica DOS na implementação AJCSP. A causa disso é devido ao deslocamento das linhas de código relacionadas a concorrência dos métodos para anotações nas classes. A anotação que define o comportamento concorrente deve ser tratada como uma contribuição para concorrência mesmo não sendo uma linha de código, localizado dentro de um bloco de comentários.
5.2. SUITE DE MÉTRICAS
Tabela 5.1 A suite de métricas.
Atributos Métricas Definições
Concern Diffusion Número de componentes que contribuem
over Components (CDC) para a implementação da preocupação.
(Garcia et al.,2005)
Concern Diffusion Número de métodos que contribuem
over Operations (CDO) para a implementação da preocupação.
(Garcia et al.,2005)
Separação de Lines of Concern Número de linhas de código que contribuem
preocupações Code (LOCC) para a implementação da preocupação.
(Eaddy et al.,2008)
(Separation Degree of Scattering Mede o espalhamento da preocupação
of Concern across Classes (DOSC) pelas classes do sistema.
- SoC) (Eaddy et al.,2008)
Degree of Scattering Mede o espalhamento da preocupação
across Methods (DOSM) pelos métodos do sistema.
(Eaddy et al.,2008)
Degree of Tangling Mede o quanto dedicado a classe é para
within classes (DOTC) uma preocupação.
(Eaddy and Eaddy,2008)
Acoplamento Coupling Between Número de métodos e atributos de um componente
Components (CBC) que podem ser chamado ou acessado por outro
componente. (Chidamber and Kemerer,1994)
Lines of Code (LOC) Número de linhas de código.
(Chidamber and Kemerer,1994).
Tamanho Number of Attributes (NOA) Número de atributos de cada classe. (Chidamber and Kemerer,1994).
Number of Operations (NOO) Número de métodos de cada classe.
(Chidamber and Kemerer,1994).
Vocabulary Size (VS) Número de componentes do sistema.
(Chidamber and Kemerer,1994).
Por este motivo, optou-se por utilizar a métrica DOS para classes (DOSC) (Eaddy et al.,
2008) e para métodos (DOSM) (Eaddy et al., 2008) com o objetivo de refinar a medida de espalhamento. Para calcular a métrica DOS, utiliza-se as equações abaixo:
CONC(s,t) = número de linhas relacionadas à concorrência no componente t
número total de linhas relacionadas à concorrência s
5.1 onde CONC calcula a concentração da concorrência s no componente t
DOS(s) = 1− |T|
∑
T t ( CONC(s,t)− 1 |T| )2 |T| − 1 5.25.3. PROCEDIMENTOS DE AVALIAÇÃO
e T é o número total de componentes, que pode ser classes para a métrica DOSC ou métodos para DOSM.
A medida DOS considera o pior caso, ou seja, quando a preocupação está presente em todos os componentes do sistema. (Eaddy et al., 2008) Enquanto a métrica DOTC considera o embaralhamento de uma preocupação específica, a métrica DOTC será de- talhada mais adiante.
O uso das métricas (DOSC e DOSM) ajuda a saber exatamente os locais a serem modificados (componentes ou operações) em uma atividade de manutenção. As métricas CDC e DOSC são comparáveis, pois as duas medem propriedades de preocupações a nível de classe (Eaddy et al.,2008), assim como DOSM e CDO também são compatíveis por tratarem operações. Portanto, as métricas (DOSC e DOSM) e (CDC e CDO) se complementam. As métricas de tamanho VS e NOO (Tabela 5.1, que quantificam o número de componentes e operações, respectivamente, são utilizadas a fim de comparar medidas relacionadas à concorrência com o resto do sistema. Métricas de tamanho são importantes para avaliar a complexidade do sistema final.
A dependência entre componentes é avaliada pela métrica CBC. Informações sobre SoC, CBC e métricas de tamanho podem ser encontradas em (Chidamber and Kemerer,
1994;Sant’anna et al.,2003;Garcia,2004).
5.3
Procedimentos de avaliação
Um estudo foi conduzido utilizando cinco sistemas diferentes, implementados em três versões (AJCSP, JCSP, and Java threads).
Producer and Consumer (ProdCons) - Programa clássico produtor-consumidor, onde é implementado a comunicação síncrona entre duas classes, uma que produz uma informação e outra que consume o valor produzido (Khurshid et al.,2010). AlarmClock - Programa que implementa um alarme que avisa a classe cliente quando
atingir um determinado horário. Os clientes se registram na classe alarme principal informando o tempo que deseja ser acordado (Khurshid et al.,2010).
CruiseControl - Implementação de um controle automático de velocidade de um carro. A classe principal contém métodos que simulam aceleração, freio e parada de um carro. Durante a execução é mostrado a variação da velocidade e a distância percorrida a medida que o controle de velocidade é executado (Khurshid et al.,
5.3. PROCEDIMENTOS DE AVALIAÇÃO
Catch - Framework para automação de testes funcionais. Desenvolvido e utilizado in- ternamente pelo C.E.S.A.R.1, fornece uma plataforma para criação de testes au- tomáticos utilizando a linguagem Java.
Health Watcher - Sistema de reclamações para instituições de saúde. (Soares and Borba,
2002)
Todos os sistemas tiveram suas funcionalidades reconstruídas em JCSP e AJCSP, mantendo a versão original.
Os sistemas apresentam diferentes complexidades, propositalmente a fim de anali- sar a abordagem AJCSP em diferentes aspectos. Os sistemas utilizados Producer and Consumer (Khurshid et al., 2010), AlarmClock (Khurshid et al., 2010) e CruiseCon- trol (Khurshid et al.,2010;Wellings,2004) são muito simples, com poucas linhas de có- digo. Porém utilizam concorrência para construir suas principais funcionalidades. Eles ajudam a entender melhor as métricas de separação de preocupações (SoC). Outro sis- tema escolhido foi o Catch, que é um framework para automação de testes funcionais em ambientes web e desktop, que usa concorrência em uma funcionalidade específica. Por- tanto, apenas um pedaço do código do framework precisou ser alterado, sendo útil para avaliar a redução do tamanho dos componentes e operações como métricas de tamanho. Por último, foi utilizado o sistema Health Watcher (Soares and Borba, 2002), que fornece um sistema de reclamações para o serviço público de saúde. O Health Watcher é o maior de todos, com 6 mil linhas de código, que tem como característica a arquitetura web, utilizando o padrão de arquitetura de software MVC (Kayal,2008). Apesar de ser um sistema complexo, a concorrência está presente apenas no seu gerenciador interno de conexões. Neste caso, o health watcher foi totalmente reconstruído utilizando a abor- dagem AJCSP que ajudará a interpretar os resultados das métricas de acoplamento, além de mostrar que um sistema totalmente sequencial pode se tornar um sistema concorrente utilizando as anotações AJCSP. Por conta desta reconstrução a versão original não foi considerada nos cálculos das métricas de separação de concorrência (Tabela5.2), pois a comparação das métricas é entre a versão original, a versão JCSP e AJCSP, no entanto a versão original do sistema não utiliza API Java threads.
No processo de avaliação, os dados foram parcialmente colhidos pela ferramenta de medição JMetrics 2, a qual suporta algumas métricas: VS, NOA e NOO. Foi utilizada também uma ferramenta de métricas AOP 3 para coletar CBC e LOC. Finalmente, as
1Ferramenta interna do C.E.S.A.R. http://www.cesar.org.br/ 2http://sourceforge.net/projects/jmetrics/
5.4. RESULTADOS DO ESTUDO
Tabela 5.2 Resultados das métricas da separação da concorrência.
System Version CDC CDO LOCC DOSC DOSM DOTC
Threads 4 5 41 0.78 0.88 0.75 ProdCons JCSP 3 3 40 0.95 0.74 0.96 AJCSP 3 0 6 1 0 0.42 Threads 4 5 47 0.80 0.82 0.63 AlarmClock JCSP 4 7 78 0.89 0.96 0.65 AJCSP 4 0 8 0.93 0 0.41 Threads 3 25 71 0,76 0,72 0,60 Cruisecontrol JCSP 4 6 156 0,96 0,65 0,91 AJCSP 5 0 8 0,93 0 0,29 Threads 4 6 54 0,70 0,79 0,02 Catch Framework JCSP 6 11 103 0,81 0 ,84 0,04 AJCSP 4 2 10 0,58 0,50 0,02 Threads - - - - Health Watcher JCSP 23 55 1074 0,95 0,93 0,17 AJCSP 23 16 127 0,91 0,93 0,11
métricas SoC (CDC, CDO, LOCC, DOSC, DOSM, e DOTC) (Sant’anna et al., 2003;
Eaddy et al., 2007) foram coletadas manualmente. O Eclipse TPTP4 foi utilizado para observar as classes do sistema Health Watcher executando suas funcionalidades de forma concorrente.
5.4
Resultados do estudo
Esta seção apresenta os resultados do processo de medição. Os dados foram coletados baseados em um conjunto de métricas conhecidas (Tabela 5.1). O detalhamento é or- ganizado em duas partes: 1) resultados para as métricas de separação da concorrência (Tabela5.2); 2) resultados para as métricas de acoplamento e tamanho (Tabela5.3).