Código Legado: como mantê-lo com qualidade

Código Legado: como mantê-lo com qualidade Cleber Ferreira Gomes, Anita Maria da Rocha Fernandes Curso de Pós Graduação Universidade do Vale do Itajaí (UNIVALI) 88.032-005 Florianópolis SC Brasil fclebinho@gmail.com, anita.fernandes@univali.br Abstract. The difficulty faced by organizations maintain functional and reusable legacy code is a scenario that encompasses several discussions, however, not always the result is expected. Even companies adopting methodologies, processes and tools, this issue is much more complex and delicate. This article describes some scenarios executed by Softplan company in pursuit of quality of legacy code, listing resources and difficulties faced by the organization. The final idea is to present some points, which when exploited, will help the organization better achieve its objectives. Resumo. A dificuldade enfrentada pelas organizações em manter o código legado funcional e reutilizável é um cenário que engloba várias discussões, no entanto, nem sempre o resultado é o esperado. Mesmo as empresas adotando metodologias, processos e ferramentas, essa questão é muito mais complexa e delicada. Este artigo descreve alguns cenários executados pela empresa Softplan, em busca da qualidade do código legado, listando recursos e dificuldades enfrentadas pela organização. A ideia final é apresentar alguns pontos, que ao serem explorados, vão ajudar a organização a atingir melhor os seus objetivos. 1. Introdução A Softplan, fundada em 1990, é uma empresa genuinamente catarinense especializada no desenvolvimento e implantação de softwares. Visa atender um nicho de mercado voltado especialmente para gestão profissional de empresas da indústria da construção. Com o passar dos anos, a Softplan se especializou no desenvolvimento e na implantação de softwares voltados para a gestão para os segmentos de Justiça, Infraestrutura e Obras, Gestão Pública, Projetos Cofinanciados por Organismos Internacionais e Indústria da Construção. Atualmente, a empresa atua com o objetivo de tornar a gestão pública e privada no Brasil mais transparente, eficiente e ágil, com o uso de tecnologias modernas e inovadoras. Dentro deste cenário, a Unidade de Justiça é a responsável pelas soluções que atendem as instituições da justiça brasileira, tais como, Tribunais de Justiça Estadual, Ministérios Públicos Estaduais e Procuradorias de Justiça Estaduais e Municipais. Compõem essa unidade cinco softwares mantidos e em constante evolução desde 1993. Um dos principais objetivos, e ao mesmo tempo um desafio da Softplan e das demais empresas de software, é desenvolver software de qualidade. Mesmo com as ferramentas disponibilizadas hoje no mercado, que automatizam maior parte do ciclo de vida de um software, as empresas de software ainda encontram muitas dificuldades na hora de entregar algo de valor para o cliente final. As tendências tecnológicas avançam em constante evolução e muito rápida, e as empresas de software não conseguem acompanhá-las por diversos motivos, seja pelo

alto custo de aquisição e manutenção dessas ferramentas, ou pela complexidade do código legado existente, o que impossibilita a migração. Ao falar em projetos que possuem vários anos de vida, é praticamente impossível prevê a cobertura de testes automatizados em todas as funcionalidades. Quando a cobertura de testes não faz parte da cultura da empresa, há um aumento do código legado de baixa qualidade, acarretando no alto índice de erros inseridos, aumentando assim o custo para se manter o código legado. Com base nisso, este artigo apresenta alguns cenários utilizados pela empresa Softplan em busca da qualidade de seu código legado. Tais cenários podem servir de guia para outras empresas que pretendem manter a qualidade de seu código legado. Este artigo está organizado em cinco seções, sendo que na segunda serão abordados temas referentes a testes e padrões de projeto, na terceira seção será apresentado um breve histórico até a atualidade do cenário exercido pela empresa Softplan, na quarta seção será apresentada uma proposta com base na fundamentação teórica considerando o cenário atual. Na quinta seção serão apresentados os benefícios das abordagens que este artigo oferece. 2. Fundamentação Teórica A seguir tem-se a fundamentação teórica que embasou este trabalho. Esta fundamentação refere-se aos Testes Automatizados de Software e aos Padrões de Projeto. 2.1 Testes Automatizados Segundo Kaner (2001), o propósito da automação de testes pode ser resumidamente descrito como a aplicação de estratégias e ferramentas tendo em vista a redução do envolvimento humano em atividades manuais repetitivas. A automação possibilita a execução de testes regressivos com maior amplitude e profundidade. O grande problema ocorre quando em um estágio avançado do desenvolvimento, gasta-se mais tempo executando testes regressivos do que testando as novas funcionalidades. Uma abordagem de testes baseada puramente em testes manuais, normalmente não consegue acompanhar as demandas e o volume de testes ao longo do ciclo de vida de desenvolvimento de um software [Caetano 2011]. Frequentemente o produto é liberado sem que tenha sido completamente testado em virtude de restrições de tempo. A automação de testes quando utilizada corretamente permite a execução ininterrupta de testes regressivos a qualquer hora do dia ou da noite. Dessa forma para conseguir testar o sistema todo constantemente de forma contínua a um preço justo, são automatizando os testes. Ou seja, escrevendo um programa que testa o programa. Esse programa invocaria os comportamentos do sistema e garantiria que a saída é sempre a esperada [Caetano 2011]. Hoje várias abordagens sobre testes são encontradas, algumas delas são: testes de caixa branca, caixa preta, caixa cinza, regressão, técnicas não funcionais, unidade, TDD (Test-Driven Development), integração, sistema, aceitação, operação, alfa e beta e candidato a lançamento. Neste artigo serão abordados os testes de unidade e TDD. 2.1.1 Testes de Unidade

Testes de unidade são testes que testam apenas uma classe ou método, verificando se seu comportamento está de acordo com o desejado. Em testes de unidade, verificandose a funcionalidade da classe e/ou método em questão passando o mínimo possível por outras classes ou dependências do sistema [Caelum 2016]. Considerando que a unidade é a menor parte testável de uma aplicação. Em uma linguagem de programação orientada a objetos usando como exemplo a linguagem Java, a menor unidade é um método [Caelum 2016]. Em testes de unidade, o foco não está no comportamento real das dependências da classe, mas em como a classe em questão se comporta diante das possíveis respostas das dependências, ou então se a classe modificou as dependências da maneira esperada [Caelum 2016]. Já Feathers (2013) fala que, testar isoladamente é uma parte importante da definição de um teste de unidade, pois muitos erros podem ocorrer quando as porções de softwares são integradas. Ainda, segundo Feathers (2013) testes grandes abrangendo amplas áreas de códigos funcionais, também são considerados importantes, porém podem apresentar grandes problemas tais como: Localização de erros Quando os testes vão além do que devem testar, fica mais difícil determinar o que significa a falha de teste. Geralmente dá bastante trabalho detectar a causa de falha de teste. Examinar as entradas de teste, examinar a falha e determinar em que local do trajeto entre a entrada e saídas ela ocorreu. Isso também ocorre nos testes de unidade, mas frequentemente é trivial porque os testes são muito pequenos. Tempo de execução Testes maiores tendem a demorar mais para serem executados. Isso tende a tornar a execução um pouco frustrante. Testes que tem execução muito demorada acabam não sendo executados. Cobertura Pode ser difícil visualizar a conexão entre um trecho de código e os valores que o exercitam. Pode-se descobrir se um trecho de código é exercitado por um teste usando ferramentas de cobertura, mas quando adicionamos código novo, talvez se faça necessário ter algum trabalho para criar testes de alto nível que exercitam o novo código. As qualidades encontradas quando são empregados bons testes de unidade são: testes sendo executados rapidamente e a ajuda na localização dos problemas mais facilmente. 2.1.2 Test-Driven Development (TDD) TDD é uma das práticas de desenvolvimento de software sugeridas por diversas metodologias ágeis, como XP (Extreme Programming). A ideia é fazer com que o desenvolvedor escreva testes automatizados de maneira constante ao longo do desenvolvimento. Mas, diferentemente da prática comum que é empregada atualmente, o TDD sugere que o desenvolvedor escreva o teste antes mesmo da implementação [Aniche 2013].

Aniche (2013) cita que desenvolvedores de TDD (ou qualquer outro papel que é executado dentro de uma equipe de software) estão muito acostumados com o processo tradicional de desenvolvimento: primeiro a implementação e depois o teste. Ainda para Aniche (2013) a ideia é simples: o desenvolvedor deve começar a implementação pelo teste e, deve o tempo todo, fazer de tudo para que seu código fique simples e com qualidade. Conforme mostra a Figura 1. Figura 1: Fluxo aplicado ao TDD Fonte: Aniche (2013) Essa modalidade traz benefícios como mencionado por Aniche (2013), garantindo qualidade no código desenvolvido: Foco no teste e não na implementação Ao começar pelo teste, o programador consegue pensar somente no que a classe deve fazer, e esquece por um momento da implementação. Isso o ajuda a pensar em melhores cenários de teste para a classe sob desenvolvimento. Código nasce testado Se o programador pratica o ciclo corretamente, isso então implica em que todo o código de produção escrito possui ao menos um teste de unidade verificando que ele funciona corretamente. Simplicidade Ao buscar pelo código mais simples constantemente, o desenvolvedor acaba por fugir de soluções complexas, comuns em todos os sistemas. O praticante de TDD escreve código que apenas resolve os problemas que estão representados por um teste de unidade. Melhor reflexão sobre o design da classe No cenário tradicional, muitas vezes a falta de coesão ou o excesso de acoplamento é causado muitas vezes pelo desenvolvedor que só pensa na implementação e acaba esquecendo como a

classe vai funcionar perante o todo. Ao começar pelo teste, o desenvolvedor pensa sobre como sua classe deverá se comportar perante as outras classes do sistema. O teste atua como o primeiro cliente da classe que está sendo escrita. Nele, o desenvolvedor toma decisões como o nome da classe, os seus métodos, parâmetros, tipos de retorno, e etc. No fim, todas elas são decisões de design e, quando o desenvolvedor consegue observar com atenção o código do teste, seu design de classes pode crescer muito em qualidade. Aniche (2013) ainda afirma, que o praticante de TDD escreve um pouco de testes, um pouco de implementação e recebe feedback. Isso acontece ao longo do desenvolvimento de maneira frequente. Já um programador que não pratica TDD espera um tempo maior para obter o mesmo feedback. Conforme mostra a Figura 2. 2.2 Padrões de Projeto Figura 2: Feedback proposto pelo conceito TDD. Fonte: Aniche (2013). A origem dos Design Patterns (Padrões de Desenho ou ainda Padrão de Projeto) vem do trabalho de um arquiteto chamado Christopher Alexander, no final da década de 70. Ele escreveu dois livros, inicialmente, A Pattern Language [Alexander 1977] e A Timeless Way of Building [Alexander 1979], nos quais ele exemplificava o uso e descrevia seu raciocínio para documentar os padrões. Em 1995, um grupo de quatro profissionais escreveu e lançou o livro Design Patterns: Elements of Reusable Object-Oriented Software [Gamma etal 1995], um catálogo com 23 padrões de desenho (design patterns). Os autores ficaram mais conhecidos como A Gangue dos Quatro (Gang Of Four ou GoF), considerados os maiores entusiastas dos Design Patterns. Um padrão descreve um conjunto composto por um contexto, um problema e uma solução. Em outras palavras, pode-se descrever um padrão como uma solução para um determinado problema em um contexto. Porém, um padrão não descreve qualquer solução, mas sim uma solução que já tenha sido utilizada com sucesso em mais de um

contexto [Guerra 2012]. Ainda segundo Guerra (2012), exatamente por esse motivo que a descrição dos padrões normalmente sempre indica alguns de seus usos conhecidos. Um padrão não descreve soluções novas, mas soluções consolidadas. A ideia dos padrões vem do trabalho de Christopher Alexander na área de arquitetura de cidades e construções [Benioff, Adler 2009]. Neste livro, cada padrão trazia uma solução adequada a um problema, que poderia ser reutilizada e adaptada para diversas situações. Padrões de projeto não são projetos, como listas encadeadas e tabelas de acesso aleatório, que podem ser codificadas em classes e ser reutilizadas tais como estão. Tampouco são projetos complexos, de domínio específico, para uma aplicação inteira ou subsistema [Gamma et al 1995]. Padrões de projeto, aqui apresentado, são descrições de objetos e classes comunicantes que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular [Gamma et al 1995]. A modelagem de um software é uma questão dinâmica que evolui a medida que o desenvolvimento do software vai seguindo seu curso. Apesar de ainda ser comum a modelagem das classes da aplicação a partir de diagramas antes do início das implementações, muitas vezes os problemas aparecem somente depois. Sendo assim, muito importante que saber como utilizar os padrões na modelagem inicial, é saber como refatorar um código existente para uma solução que utilize um determinado padrão. A refatoração constante do código é hoje uma das bases para a manutenção de sua qualidade ao longo do projeto. [Guerra 2012] Cohn (2009) ainda fala que, refatorar é alterar a estrutura do código sem alterar o seu comportamento. É uma prática que permite que o desenvolvedor melhore o design do código, tornando o mais limpo e fácil de se compreender. É uma técnica essencial para prevenir que o código se deteriore. À medida que novos comportamentos são incluídos no software, por consequência aumentando a complexidade, existe uma grande tendência de se escrever código duplicado e torná-lo mais difícil de compreender e de dar manutenção. Por outro lado, é preciso tomar cuidado para não cair em um perfeccionismo extremo e gastar tempo tentando aperfeiçoar detalhes sem importância. Para facilitar a identificação do momento correto para realizar a refatoração, Poppendieck (2003) cita cinco características de um sistema íntegro. Simplicidade Na maioria das vezes um design simples é o melhor design. Design Patterns, quando bem aplicados, são uma ótima ferramenta para aplicar soluções simples a problemas complexos; Clareza O código fonte deve ser facilmente compreendido por todos os membros da equipe. Todos os elementos do código devem ser devidamente nomeados para que sejam facilmente compreendidos por todos; Eficácia Um bom design deve produzir o resultado correto, isto é, deve atingir o objetivo pelo qual foi criado; Sem repetição O mesmo código não deve existir em dois lugares diferentes. Quando uma mudança precisa ser feita em muitos lugares o risco de defeitos cresce exponencialmente;

Utilidade Toda funcionalidade de um sistema precisa ser útil para seus usuários. Quando uma funcionalidade deixa de ser necessária, cria-se desperdício em mantê-la; em muitos casos é melhor eliminá-la. Poppendick (2003), destaca que se qualquer uma destas estiver faltando, é sinal de que é hora de refatorar. Gamma et al (1995) cita 23 padrões de projeto, apresentado em forma de catálogo conforme mostra a Tabela 1. Tabela 1. Catálogo de padrões de projeto Há várias maneiras de organizar os padrões. Alguns padrões são frequentemente usados em conjunto. Por exemplo, o Composite é frequentemente usado com o Iterator ou o Visitor. Alguns padrões são alternativos: o Prototype é frequentemente uma alternativa para o Abstract Factory. Alguns padrões resultam em projetos semelhantes, embora tenham intenções diferentes [Gamma et al 1995]. Uma outra maneira, ainda, de organizar padrões de projeto é de acordo com a forma com que eles se relacionam. Porém o artigo irá abordar somente as formas de organizações por relacionamento e catálogo. 2.2.1 Organização de Padrões A seguir serão apresentadas referem-se aos Padrões Relacionados e a Organização por Catálogo.. 2.2.1.1 Padrões Relacionados A Figura 3 ilustra os padrões de relacionamentos graficamente.

Figura 3: Relacionamentos entre padrões de projeto. 2.2.1.2 Organização por Católogo Nessa seção serão apresentados os padrões com um breve resumo de sua aplicação e agrupados por propósitos: de criação, estrutural e comportamental. 2.2.1.2.1 Padrões de Criação Abstract Factory: Fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas. Builder: Separa a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações.

Factory Method: Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe a ser instanciada. O Factory Method permite a uma classe postergar a instanciação às subclasses. Prototype: Especifica os tipos de objetos a serem criados usando uma instância prototípica e criar novos objetos copiando esse protótipo. Singleton: Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela. 2.2.1.2.2 Padrões Estruturais Adapter: Converte a interface de uma classe em outra interface esperada pelos clientes. O Adapter permite que certas classes trabalhem em conjunto, pois de outra forma seria impossível por causa de suas interfaces incompatíveis. Bridge: Separa uma abstração da sua implementação, de modo que as duas possam variar independentemente. Composite: Compõe objetos em estrutura de árvore para representar hierarquias do tipo partes-todo. O Composite permite que os clientes tratem objetos individuais e composições de objetos de maneira uniforme. Decorator: Atribui responsabilidades adicionais a um objeto dinamicamente. Os decorators fornecem uma alternativa flexível a subclasses para extensão da funcionalidade. Façade: Fornece uma interface unificada para um conjunto de interfaces em um subsistema. O Façade define uma interface de nível mais alto que torna o subsistema mais fácil de usar. Flyweight: Usa compartilhamento para suportar grandes quantidades de objetos, de granularidade fina, de maneira eficiente. Proxy: Fornece um objeto representante, ou um marcador de outro objeto, para controlar o acesso ao mesmo. 2.2.1.2.3 Padrões Comportamentais Interpreter: Dada uma linguagem, define uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças nessa linguagem. Template Method: Define o esqueleto de um algoritmo em uma operação, postergando a definição de alguns passos para subclasses. O Template Method permite que as subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura.

Chain of Responsibility: Evita o acoplamento do remetente de uma solicitação ao seu destinatário, dando a mais de um objeto a chance de tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um objeto a trate. Command: Encapsula uma solicitação como um objeto, desta forma permitindo que você parametrize clientes com diferentes solicitações, enfileire ou registre (log) solicitações e suporte operações que podem ser desfeitas. Iterator: Fornece uma maneira de acessar sequencialmente os elementos de uma agregação de objetos sem expor sua representação subjacente. Mediator: Define um objeto que encapsula a forma como um conjunto de objetos interage. O Mediator promove o acoplamento fraco ao evitar que os objetos se refiram explicitamente uns aos outros, permitindo que você varie suas interações independentemente. Memento: Sem violar o encapsulamento, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa posteriormente ser restaurado para este estado. Observer: Define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são automaticamente notificados e atualizados. State: Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado de classe. Strategy: Define uma família de algoritmos, encapsula cada um deles e os torna intercambiáveis. O Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam. Visitor: Representa uma operação a ser executada sobre os elementos da estrutura de um objeto. O Visitor permite que você defina uma nova operação sem mudar as classes dos elementos sobre os quais opera. 3. Cenário atual Hoje, a empresa conta com aproximadamente 1.500 colaboradores em diversos cargos, tais como, analistas de negócio, testadores, desenvolvedores, suporte, consultores de produtos, gestores e outros perfis de colaboradores que dão suporte as atividades da empresa. A Softplan é uma das maiores empresas do Brasil no desenvolvimento de softwares de gestão. Em 2013, a empresa empregava o conceito de testes guiado por roteiro, onde descreviam o passo a passo detalhadamente, chegando assim a gerar documentos com várias páginas, a complexidade aumentava quando se faziam ainda menções a outros roteiros como pré-requisitos. Esses roteiros seriam de apoio para os desenvolvedores executarem antes de tomar a demanda como pronto, porém não era isso que acontecia. Devido à alta complexidade dos documentos e pelo tempo escasso, devido alto fluxo de erros a serem analisados e resolvidos em tempo hábil. Esses roteiros consumiam muito tempo para ser

confeccionados, a ponto de que determinadas demandas estarem em estágio de análise ou mesmo de implementação, sem mesmo terem iniciado a confecção do roteiro de teste da demanda em questão. Nesse período já se buscava alternativas para melhorar a qualidade das entregas, e por isso iniciaram-se estudos sobre as melhores práticas, padrões de projeto, porém houve algumas resistências, como ainda há nos dias hoje, em tornar isso uma cultura dentro da organização, sejam elas por falta de capacitação e preparo ou pela arquitetura de software adotada pela empresa, o que dificulta o emprego dessas boas práticas. Dois anos mais tarde, já em 2015, a empresa optou em escalar o processo ágil com base no framework SAFe, que trouxe diversos benefícios, um deles é que para cada demanda se definem critérios de aceite listado pelo analista de produto. Em cima desses critérios de aceito são elaborados os roteiros de testes, enxutos, coesos e objetivos. Nessa nova fase os testes são aplicados por equipes especializadas em testes e exclusivos para esse fim. Para chegar nesse formato, a empresa Softplan teve o auxílio de consultorias externas, para alavancar na eficiência no que se refere a testes. Atualmente, a empresa segue a busca pela melhoria contínua, analisando e revendo seus processos que possam garantir melhores resultados. 4. Proposta A ideia do código nascer testado como cita a literatura quando se fala de TDD seria o ideal, mais na prática isso não é tão simples assim, devido algumas questões como: tempo, disponibilidade, conhecimento, custo, arquitetura, ferramentas, linguagem de programação e o próprio código legado já existente. O ideal e essencial para ter bons resultados é aplicá-lo de maneira gradativa. É importante que a empresa encare esse processo, fazendo com que ele se torne natural no andamento diário das atividades. Hoje em dia as empresas até veem os testes automatizados como necessários, mas na corrida contra o tempo e na busca por resultados rápidos, colocam essa questão em segundo plano, pois o resultado dessa ação impactará na qualidade do código legado. Outros pontos críticos são a complexidade, duplicidade e até mesmo a qualidade do código alterado ou incluído em cada ciclo proposto nas metodologias ágeis, o código legado é submetido à manutenção constantemente seja ela corretiva ou evolutiva. Nesse aspecto a proposta é de se aplicar padrões de projetos que tornem o código legado acessíveis, legíveis e reaproveitais. Para esse caso se faz um necessário que haja um planejamento que considere refatorações de melhoria do código legado. Hoje qualquer ação abordando as situações mencionadas acima vão incidir em custo. No entanto, vale avaliar se esses custos vão evitar que o custo de manutenção corretiva aumente, assim como acontece sobre o código legado hoje. Por isso é importante que empresa esteja ciente dessa implementação, mesmo de maneira gradual, pois só assim será possível ter uma resposta real sobre a importância e controle dos custos. Isso evitaria erros, correções pelos analistas, visando assim uma melhora significativamente do código legado. 5. Conclusões Ao longo do artigo foi apresentado que código legado e uma peça fundamental para as empresas porem mantê-lo é uma tarefa difícil, Kaner (2001) e Aniche (2003) defendem

que a cobertura de testes unitário e automatizados garatem a integridade funcional do software, Gamma et al (1995), alega que ao utilizar padrões de projeto elevam a qualidade do código ao torna-lo organizado, legível, coerente e de fácil entendimento. Testes automatizados são fundamentais para um desenvolvimento de qualidade, sua existência traz diversos benefícios para o software, como o aumento da qualidade e a diminuição de erros em produção. Uma empresa que possui muitos desenvolvedores modificando o código simultaneamente pode perder o controle sobre as alterações, por esse motivo a melhor forma é atacar no conhecimento, costumes, boas práticas. No caso da Softplan, considerar as abordagens proposta pelo artigo irá trazer benefícios ao facilitar a interação dos desenvolvedores perante ao código, pois código de qualidade e coberto por testes automatizados irão evitar o aumento do código legado de baixa qualidade. Referências Aniche, Mauricio (2013) Test-Driven Development - Teste e Design no Mundo Real com.net. Editora Casa do Código. Guerra, Eduardo (2012). Design Patterns com Java Projeto orientado a objeto guiado por padrões. Editora Casa do Código. Kaner, Cem; Bach, James; Pettichord, Bret (2001) Lessons Learned in Software Testing: A Context-Driven Approach. Feathers, Michael C. (2013) Working Effectively with Legacy Code. Editora Printice Hall, ISBN 0-13-117705-2 Benioff, Marc; Adler, Carlye (2009). Behind the Cloud: the untold story of how salesforce.com went from idea to billion-dollar company and revolutionized an industry. Jossey-Bass. Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995) Design patterns - elements of reusable object-oriented software. Alexander, Christopher (1977) A Pattern Language. http://library.uniteddiversity.coop/ecological_building/a_pattern_language.pdf, acessado em 06/2016. Alexander, Christopher (1979) The Timeless Way Of Building. http://library.uniteddiversity.coop/ecological_building/the_timeless_way_of_buil ding_complete.pdf, acessado em 06/2016. Cohn, Mike (2009). Succeeding with Agile: Software Development Using Scrum. Poppendieck, Mary; Poppendieck, Tom (2003). Lean Software Development: An Agile Toolkit. Caelum. http://www.caelum.com.br/apostila-java-testes-xml-design-patterns/testesautomatizados/#3-5-junit, acessado em 06/2016 Caetano, Cristiano. (2011) http://www.qualister.com.br/blog/introducao-a-automacaode-testes, acessado em 06/2016