Os alunos realizaram uma análise do gap de qualidade alcançada pelo sistema atual e a expectativa de qualidade desejada para atender os requisitos de negócio. As medidas coletadas, a árvore de utilidade e as demandas de negócio orientaram essa análise. Exemplificando essa análise com o tema “Pool de acesso sem fila (com
timeout)”: após uma análise estática do código-fonte mais aprofundada, verificou-se que na arquitetura inicial, várias classes referenciavam uma determinada classe do sistema, denominada CatalogFacade, a qual, por sua vez, provia o acesso aos dados. Em testes comportamentais, simulados com o apoio do JMeter em tempo de execução, quando havia vários usuários requisitando dados simultaneamente, o Pet
Store tentava atender a todos até que, em um determinado ponto, não mais respondia
a tantas requisições, situação em que o usuário recebia uma tela de erro.
Do ponto de vista pedagógico, o processo de ensino/aprendizagem de qualidade de arquitetura tornou-se muito mais rico quando, em casos como esse, os alunos, por meio de medições descobriam os limites do sistema e constatavam, por intermédio de evidências que a arquitetura de software não mais atendia os requisitos do negócio.
Etapa 6 - Criação da Especificação Técnica do sistema desejado
Nesta etapa, iniciou-se a elaboração da Especificação Técnica do sistema, na qual, de acordo com o ponto de vista da Engenharia do RM-ODP, já se definem as possíveis táticas arquiteturais que podem ser implementadas. Apoiando-se no princípio do roteiro de “Documentação essencial”, a Especificação Técnica produzida pelos alunos foi sucinta, e continha apenas as informações que serviram como base para a implementação da prova de conceito.
Etapa 7 - Projeto e implementação da Prova de Conceito baseado na Especificação Técnica
Neste ponto do roteiro, apoiados pelo ponto de vista da Tecnologia do RM- ODP, os alunos implementaram a prova de conceito baseando-se na Especificação Técnica. Essa prova de conceito podia ser Construtiva ou Destrutiva, de acordo com a necessidade de cada grupo. Como exemplo, para atender o objetivo de negócio do grupo “Pool de acesso sem fila (com timeout)”, que, no caso do Pet Store, significava responder a muitos usuários simultaneamente sem que o sistema retorne uma mensagem de erro, os alunos acabaram por decidir que seria aceitável, ao se ultrapassar a quantidade de usuários que o sistema é capaz de atender, uma mensagem de indisponibilidade temporária, exibida ao usuário através do uso adequado do mecanismo de timeout, conceito esse desconhecido por muitos alunos. Em uma das aplicações do roteiro, após a primeira implementação da prova de conceito, após alteração dos mecanismos de acesso aos dados, os alunos constataram que a solução não era viável, pois mensagens de erros técnicas continuavam a ser exibidas quando o sistema era submetido a alta carga de acesso. Ainda na mesma aplicação do roteiro, os alunos decidiram considerar uma segunda alternativa de solução. A Figura 18 destaca o ponto avaliado na arquitetura inicial e a modificação proposta. Na solução inicial, não havia controle da quantidade de acessos simultâneos. Na segunda solução, o controle era feito através da criação de uma classe auxiliar, denominada AccessController, que implementava o controle do pool de acessos por meio da implementação de um método chamado testAccess().
Figura 18 - Exemplo de solução proposta por alunos do Grupo “Pool sem filas” (com timeout)
Fonte: adaptado de Guimarães (2008)
Quando uma requisição de acesso aos dados era feita à classe CatalogFacade pelas diversas classes que a referenciam, o método testAccess() da classe
AccessController era invocado. Esse método verificava se o contador interno de
acessos chegou ao limite, ou seja, à capacidade de atendimento do pool. Se não chegou, o contador era incrementado e retornava-se VERDADEIRO para a classe
CatalogFacade, permitindo a liberação da requisição de acesso. Quando a requisição
terminava de ser atendida, o contador era decrementado. Se o contador chegasse ao limite especificado pelo tamanho do pool, o método testAccess() retornava FALSO, impedindo a liberação da requisição e uma mensagem adequada ao usuário era exibida.
O aprendizado de avaliação de diversas alternativas foi rico, do ponto de vista pedagógico, para a formação do arquiteto de software, pois, com essa experiência, os alunos aprenderam a avaliar e testar alternativas arquiteturais, constatando, por meio de evidências coletadas nas medições, que a abordagem utilizada inicialmente não foi a mais adequada. Infelizmente, muitos profissionais de mercado só descobrem que a arquitetura de software implementada não atende aos requisitos quando recebem reclamações do usuário de um sistema em produção.
Etapa 8 - Revisão da Especificação Técnica de acordo com os resultados da Prova de Conceito
Nesta fase, os alunos atualizaram a Especificação Técnica, inserindo os resultados e as alterações necessárias derivadas da implementação das provas de conceito. Nesta etapa, o Questionário 2 (intermediário) foi aplicado com o objetivo de avaliar se os conceitos ministrados até a metade do curso foram assimilados pelos alunos. A Especificação Técnica também foi avaliada pelo professor e pelos monitores do curso, buscando-se evidencias da aplicação dos conceitos lecionados.
Etapa 9 - Implementação das melhorias definidas na Especificação Técnica
Uma vez atualizada a Especificação Técnica, iniciava-se para a implementação das melhorias arquiteturais. Os alunos eram estimulados a utilizarem técnicas de engenharia simultânea, visando paralelizar, entre os integrantes de cada grupo, a implementação dos componentes da nova arquitetura de software.
Etapa 10 - Plano de medição dos requisitos não funcionais do novo sistema
Finalizada a implementação, o plano de medição elaborado na Etapa 3 era atualizado, considerando os requisitos de qualidade esperados pelo processo de negócio. Nesse novo plano, os alunos consideraram os requisitos funcionais e não funcionais, tendo como referência as melhorias arquiteturais implementadas na Etapa 9.
Etapa 11 - Coleta de medidas de qualidade do novo sistema
O plano de medição criado na Etapa 10 era executado pelos alunos. Após a execução do plano, já era possível saber quais requisitos foram atendidos pela nova arquitetura. Do ponto de vista pedagógico, essa era uma etapa importante, pois os alunos aprenderam a coletar medidas da implementação que eles mesmos fizeram e, dessa forma, podem avaliar como os requisitos de qualidade foram atendidos pela arquitetura de software escolhida por eles, o que está relacionado com o objetivo secundário deste trabalho, conforme descrito no Capítulo 1.