Aprofundando os conceitos de Design by Contract

No último post sobre DbC, descrevi seus conceitos básicos e algumas considerações necessárias para sua aplicação. Farei agora um pequeno aprofundamento, descrevendo alguns aspectos importantes para sua aplicação prática.

 

Resumo rápido

• Um contrato aplicado à escrita de código compreende na verificação de certas condições que devem ser verdadeiras durante a execução do programa. Se não forem, significa que o programa violou o contrato definido e conseqüentemente possui bugs.

• Geralmente as linguagens de programação possuem uma rotina (uma função, um método ou mesmo uma macro) chamada Assert, que podemos utilizar para verificar se os contratos estão sendo cumpridos.

Contratos geralmente possuem:

• Pré-condições: Condições esperadas; Valores ou estados previstos de serem recebidos;
• Pós-condições: Resultados esperados; Valores ou estados previstos de serem resultantes;
• Invariáveis: Condições que permeiam (estão presentes em) todos os contratos e que são imutáveis.

Sob os aspectos de implementação, da escrita de código, podemos dizer que as pré-condições tipicamente validam os parâmetros de entrada de uma rotina; as pós-condições validam os estados e valores resultantes da rotina; e as invariáveis, validam estados que devem permanecer verdadeiros, imutáveis, antes das pré-condições e após as pós-condições.

As invariáveis geralmente são utilizadas em classes, de forma a garantir que todas as suas instâncias sempre possuam determinados estados.

 

Mais sobre Assert

Por Assert interromper a execução do programa, gerando uma descrição da falha no cumprimento da condição, a utilizamos somente em modo de depuração (debug mode). No modo de depuração efetuamos todos os testes no programa em busca de falhas, até que o software seja considerado suficientemente estável para ser liberado. Neste ponto, compilamos o software em modo de liberação (release node) fazendo com que os Asserts sejam desabilitados. Desta forma, o programa não termina ao entrar num estado inválido, apesar de poder funcionar de maneira imprevisível.

Logo, a qualidade dos testes efetuados em modo de depuração será a garantia de que o software não está operando fora do esperado em modo de liberação.

Exemplo (C++):

void Funcionario::DefinirDiaDoPagamento(
  const int dia)
{
        // Contrato: O dia do pagamento deve ser
        // sempre igual, independente do mes em
        // que e' pago.
        
        // Logo, considerando que ha' um mes que
        // possui 28 dias (fevereiro) de quatro em
        // quatro anos, o dia do pagamento deve
        // variar entre 1 e 28, para poder ser
        // SEMPRE igual.
 
        #ifdef _DEBUG
        assert( ( dia >= 1 ) && ( dia <= 28 ) );
        #endif
 
        _diaDoPagamento = dia;
}

Com a ajuda do exemplo, podemos notar alguns aspectos:

• O método não trata o valor do dia fornecido. Pelo contrário, ele estabelece um contrato (com uma pré-condição) de que o valor do dia já esteja tratado (validado) e dentro de limites esperados.
• O contrato só será validado em modo de depuração.
• Ao retirar a pré-condição, o funcionamento do método continua o mesmo.

(Observação: No exemplo, a classe Funcionario poderia ter uma invariável que substituiria sua pré-condição. Assim, seria garantido que _diaDoPagamento sempre estaria na a faixa de valores desejada, independente do método que operasse sobre ele.)

 

Removabilidade de Contratos

Os contratos devem sempre poder ser removidos sem que o funcionamento do programa mude. Isso porque se o contrato fosse parte da lógica do programa, ele deveria estar sujeito a garantia de qualidade. Então teríamos de ter outros contratos para validar esses contratos, e assim por diante, o que é notadamente inviável e incorreto. Também porque devemos poder alterar a forma como eles são implementados ou removê-los por eficiência, sem que tenhamos que alterar outras partes do programa.

 

Herança, Polimorfismo e Contratos

Ao implementarmos herança em uma classe, trazemos os contratos da classe pai para a classe filha. A classe filha então pode fortalecer ou enfraquecer os contratos:

• Fortalecer um contrato significa manter as cláusulas do contrato antigo e ainda adicionar novas cláusulas ao mesmo;
• Enfraquecer um contrato significa não cumprir as cláusulas do contrato antigo sob certas condições;

Em termos de implementação, veremos que:

• Podemos usar AND para fortalecer um contrato; e
• Podemos usar OR para enfraquecer um contrato;

Exemplo (C++):

      Contrato original:

   // Pressao deve ser menor que 120
   assert( pressao <= 120 );

      Contrato fortalecido:

   // Pressao deve ser menor que 120 e
   // Temperatura deve ser menor que 400
   assert( ( pressao <= 120 )
     && ( temperatura <= 400 ) );

      Contrato enfraquecido:

   // Pressao deve ser menor que 120 ou
   // Temperatura deve ser menor que 400
   assert( ( pressao <= 120 )
     || ( temperatura <= 400 ) );

 

Fica evidenciado, então, como podemos fortalecer ou enfraquecer contratos. Mas quando devemos fortalecer ou enfraquecer um contrato ?

Para responder a esta questão, vamos refletir sobre seu impacto sobre o comportamento da classe filha.

Suponha que uma classe A possua um método X. Sua classe filha, B, precisa reimplementar X para que X se comporte conforme suas necessidades (polimorfismo). Se o método X de B fortalece as pré-condições de X de A, o risco de uma chamada correta para X de B não ser correta para X de A aumenta. Em outras palavras, como o X de B adiciona cláusulas ao contrato que existe em X de A, pode ser que uma destas cláusulas não seja cumprida ao chamar X de A. Ou mais resumido, o que é válido para B pode não ser para A.

Ainda, se o método X de B enfraquece uma pós-condição do método X de A, um resultado esperado para X de A pode não ser esperado para X de B, levando ao risco de haver problemas no entendimento do valor resultante de X de B.

Logo, concluímos que fortalecer uma pré-condição de um método em uma classe filha pode acarretar em um aumento do risco para o mesmo método da classe pai. E se enfraquecermos uma pós-condição de um método na classe filha, aumentamos o risco do método da classe filha.

Com isso, respondemos nossa pergunta e formamos duas regras:

• Pré-condições não devem ser fortalecidas;
• Pós-condições não devem ser enfraquecidas;

E quanto às invariáveis ?

Como uma instância de uma classe filha pode ser considerada uma instância de suas classes pai, podemos dizer que as regras (invariáveis) aplicadas para a classe filha devem servir também para as classes pai. Logo, só é permitido fortalecer as invariáveis das classes pai, o que nos leva a uma terceira regra:

• Invariáveis não podem ser enfraquecidas;

Essas regras levam a um melhor entendimento dos contratos e das suas relações. Com elas podemos aplicar os contratos com mais segurança e garantir que a aplicação de herança e polimorfismo não resultará numa violação de algum contrato estabelecido.

 

Confiar no código escrito ?

O uso de Assert como garantia de contrato implica que o programa termine caso se encontrado uma violação no contrato (uma falha). Isso é bom, pois obriga-nos a consertar o software e não ignorar a falha, para que seja corrigida imediatamente e que a versão de liberação não contenha a mesma. Como vimos, na versão de liberação a falha não é mais tratada, já que confiamos nos testes efetuados na versão de depuração.

Como podemos então garantir ou ao menos melhorar as chances de não haver uma violação de contrato, ou mesmo outras falhas no software ?

Podemos introduzir algumas ações:

• Enfatizar os Testes de Caixa Branca (aqueles que focam o correto funcionamento de uma rotina, sem somente avaliar suas entradas e saídas - o chamado Teste de Caixa Preta);
• Fazer Revisões Formais no código;
• Usar uma ferramenta de Cobertura de Código, que auxilia a verificar condições não tratadas pelo software escrito;
• Usar Desenvolvimento Dirigido a Testes;
• Testar, testar e testar denovo;

A aplicação destas ações maximiza (e muito) a chance de nunca ocorrer uma violação de contrato no software e ele funcionar conforme o previsto, mesmo que os contratos não cubram todas as falhas. Sim, o estabelecimento contrato ajuda na identificação de falhas. Mas não, ele sozinho não cobre todas as possíveis falhas.

Isso que acabei de citar leva a uma implicação:

A ausência de evidência de um erro não é a evidência da ausência de um erro.

Em outras palavras, só porque você não achou um erro não que dizer que ele não exista.

 

Conclusão

Vimos contratos mais a fundo e estabelecemos algumas regras importantes para a sua aplicação. Observamos que o uso de contratos auxilia a escrever código com menos falhas, mas que sozinho não pode oferecer a garantia de que falhas não ocorrerão.

 

Em um próximo post estarei mostrando exemplos de DbC na prática, em linguagens que suportam e que não o suportam nativamente. Até breve.

 

Technorati tags: Design by Contract, Contracting for Software. Assertions, Software Development, Contract Programming

Aplicativo: Songbird

Anote aí esse nome: Songbird. Daqui um tempo ele provavelmente estará concorrendo com iTunes, Windows Media Player, WinAmp e companhia na preferência do melhor "digital jukebox". Seu nome soa com algo parecido, e não lhe causa estranheza ? Sim, o nome é parecido com o Thunderbird, primo-irmão do Firefox. E não é à toa. O Songbird é construído na mesma base destes dois aplicativos, usando a Mozilla Cross-Plataform (que possui a XUL - eXtensible User-interface Language) , o que faz com que haja versões pra Windows, GNU/Linux e Mac OS. Isso quer dizer, entre outras coisas, que este player opensource também suporta skins, é todo integrado a web, oferece suporte a línguas de diversos países e, o principal, oferece suporte à extensões (plug-ins) - o ponto forte do seu primo Firefox.

O Songbird aindá está chocando, se apresentando no momento em que escrevo na versão 0.2.1, mas ele nascerá (versão 1.0) em meados de 2007. Apesar disso, ele já tem diversas funções que deixam os concorrentes com inveja.

Com certeza, você ainda vai ouvir falar muito bem dele. Talvez, escutando em audio nele mesmo... ;)

 

 

 

 

 

 

 

Confira mais no site do Songbird.

Design by Contract (DbC)

João deseja um guarda-roupa sob-medida para o seu quarto, mas teme que um marceneiro inábil não consiga fazê-lo como ele anseia. Então ele resolve deixar tudo anotado no papel para que não haja equívocos e o marceneiro entregue o guarda-roupa como planejado. Assim, ele diminui o risco de problemas e não precisa confiar tanto nas habilidades de improviso do marceneiro.

João então anota tudo e faz uma espécie de contrato onde ele - o cliente - descreve tudo que deseja obter. O marceneiro - seu fornecedor - irá acordar em entregar o pedido sob o preço e tempo determinados.

Assim, foi estabelecido um contrato, uma forma de tentar assegurar que ambas as partes se beneficiem.

Geralmente, vemos nos contratos as seguintes características:

• Cada parte se beneficiará de alguma forma;
• Para ter tais benefícios, terão de cumprir certas obrigações;
• Esses benefícios e obrigações estarão documentados num Documento de Contrato;

O Documento de Contrato protegerá ambos os lados:

• Ele protege o cliente especificando o quanto deve ser feito: o cliente espera um determinado resultado.
• Ele protege o fornecedor especificando um mínimo aceitável: o fornecedor está ciente do escopo requisitado.

Aquilo que não está no contrato obviamente não pode ser cobrado ou imposto. Na verdade, nem sempre. Podem haver problemas neste ponto. Sempre há coisas que estão implícitas e que são esperadas por ambos os lados. Por exemplo, João obviamente espera que a porta de seu guarda-roupa feche sem problemas e que a tranca idem, mas isso não foi colocado em seu contrato pois acredita estar implícito na fabricação de qualquer guarda-roupa. Seu marceneiro, por sua vez, espera que o cheque não volte... :)

Como visto, há certas questões que são sempre esperadas de estar contidas num contrato. Seja por práticas comuns do mercado, regras, leis ou quaisquer outras que sejam largamente conhecidas. A questão é que estas regras implícitas são esperadas em todos os contratos e portanto não necessitam ser repetidas em todos eles.

Contratos e escrita de código

A primeira vista pode parecer um pouco estranho, mas toda esta bagagem de contrato é aplicável a escrita de código. Cliente, fornecedor, contrato, benefícios, obrigações e regras implícitas estão permeados em nosso código fonte de uma forma ou outra e é facilmente possível identificá-los, formalizá-los e verificá-los. O melhor de tudo é que esta formalização da escrita de código em espécies de contratos pode nos auxiliar a garantir um ótimo nível de qualidade do código. Ela ajuda a assegurar que o código fará aquilo que desejamos, que poderemos verificá-lo e atestar que cumpre suas obrigações.

Aplicando contratos à escrita de código

Ao escrever código, espressamos a lógica do software em linhas e agrupamos estas linhas em rotinas para ficarem mais fáceis de gerenciar, memorizar (diminuir a carga mental), evitar duplicações, etc. Estas rotinas muitas vezes fazem referências à outras que por sua vez à outras mais, indo de um alto nível de abstração para um baixo nível de abstração, em relação aos detalhes de implementação.

Quando uma rotina chama outra, ela espera um determinado comportamento e resultado desta - e falando em termos de contrato, um determinado benefício. Por sua vez ela tem uma obrigação com a outra rotina, que seria a de passar informações corretas para a mesma.

Então uma rotina A que chama outra, B, espera um benefício ao custo de uma obrigação. Podemos dizer que A, a rotina chamadora, seria o cliente e B, a rotina chamada, seria o fornecedor. Agora, podemos tentar estabelecer o contrato entre as partes criando suas cláusulas.

Como fazemos isso no código ?

Através de afirmações do tipo "assegure que", os asserts. Praticamente toda a linguagem de programação tem uma biblioteca que possui um método capaz de verificar se uma condição está sendo cumprida e caso ela não esteja, interromper a execução do programa informando o ocorrido.

Em C++, por exemplo, há uma biblioteca padrão chamada assert.h onde está definida a função assert. Caso a condição passada para a função assert não seja verdadeira, a execução do programa é interrompida e é informado o local (arquivo) e a linha onde a condição foi testada. Geralmente outras linguagens também possuem uma função assert em uma de suas bibliotecas padrão, ou é facilmente conseguida com terceiros ou mesmo implementada.

O exemplo que irei mostrar estará implementado em C++, mas acredito poder ser facilmente aplicado à qualquer linguagem de programação.

Considere a seguinte rotina:

 

 

A rotina cliente (que irá chamá-la) deve ter por obrigação passar um objeto válido (no caso, um objeto não-nulo). Ela se beneficiará de, passado um objeto válido, ter ele adicionado à uma lista para posterior uso.

A rotina fornecedora (a exemplificada) deve ter por obrigação adicionar um objeto à lista. Ela se beneficiará de não precisar fazer nada quando um objeto for nulo.

Fica então estabelecido um contrato entre as rotinas.

Geralmente, focaremos atenção na rotina fornecedora. Isto porque por ela sabemos também se a rotina cliente cumpriu com suas obrigações.

No caso exemplificado a rotina cliente tem uma pré-condição (obrigação) "objeto deve ser válido" e uma pós-condição (benefício/resultado) "ter o objeto adicionado à lista".

Veja a implementação:

 

Repare que a rotina com contrato tem a seguinte estrutura:

<pré-condições>  // Obrigações da rotina chamadora

<implementação>

<pós-condições> // Garantia dos benefícios para a rotina chamadora

 

Nas pré-condições temos os requerimentos que qualquer rotina que for chamá-la deve satisfazer para estar correta. E nas pós-condições as propriedades que devem ser garantidas para quando houver o retorno (da execução) de volta à rotina chamadora.

Invariáveis

Acabamos de ver como aplicamos um contrato à uma rotina. Pudemos identificar facilmente cliente, fornecedor, obrigações e benefícios de cada uma. No entanto, na introdução sob os contratos, informei que há determinadas regras que estão implícitas e que, apesar de não declaradas no contrato são esperadas de estarem contidas. A estas regras implícitas e imutáveis, damos o nome de invariáveis. Uma invariável, como o próprio nome diz é uma regra que não varia no decorrer do contexto (do programa, ou da classe, enfim). Ela teria de estar presente em todos os contratos, de forma a assegurar que todos eles a tenham cumprido.

Por isso, o desejável é que uma invariável seja declarada somente uma vez e que seja implicitamente presente em todos os contratos (rotinas).

No entanto, somente algumas poucas linguagens atualmente suportam a notação de contratos, como Eiffel e a linguagem D. Essas possuem palavras reservadas (como invariant) que possibilitam a implementação correta de DbC.

Em outras, por sua vez, é necessário um certo trabalho para simular alguns desses conceitos.

Contratos ou tratamento de entradas inválidas

Uma diferença clara que se deve ter em mente ao decidir quando usar um contrato - usando uma cláusula de verificação (assert) - ou quando tratar uma entrada inválida - usando uma expressão condicional (if) - é: determinado valor é esperado ou é um caso especial ?

Por exemplo, suponha que uma rotina espere que um determinado objeto que será usado não seja nulo. Como é esperado que ele não seja nulo, não é aceitável que ele seja. Logo, deve-se usar uma cláusula de verificação para garantir que a rotina receberá o objeto no estado esperado.

Se ao invés disso a rotina fosse projetada para tolerar objetos nulos e tomasse determinada ação de acordo com esta condição, então deveria-se usar uma expressão condicional no lugar.

A decisão vai de encontro com o comportamento desejado em seu código e como ele irá se comportar caso haja condições que vão contra aquilo que é esperado. 

Não se deve misturar as duas coisas. A presença de verificações redundantes aumenta as chances de inconsistência. Se o contrato é preciso e explícito não há necessidade de checagens redundantes.

Conclusão

O uso de contratos no desenvolvimento de software pode levar a:

• um melhor entendimento das relações entre as rotinas de um programa e do comportamento das rotinas em si;
• assegurar um mínimo de confiabilidade no código;
• diminuição de bugs por análise das obrigações e verificações de cada rotina;
• facilidade de verificação de bugs (os asserts acusam falhas nas condições esperadas);
• significante aumento da estabilidade (com a previsão e reflexão dos comportamentos do programa, o código é escrito para ser menos suscetível a imprevisibilidades);

Em próximos posts estarei exemplificando a notação de contratos em linguagens que a suportam e que não a suportam. Até breve.

 

Technorati tags: Design by Contract, Contracting for Software, Assertions, Software Development

Best-Pratices - Let's begin

Aos poucos, irei escrevendo mais sobre algumas metodologias, processos e best-pratices do desenvolvimento de software. Como um assunto puxa outro e muitas coisas estão interligadas, tentarei ir devagar e colocando as coisas em pequenas porções, para serem absorvidas e digeridas facilmente. Até breve.

Utilitário: Programmer's Notepad

Um notepad opensource com uma grande gama de recursos e suporte a diversas linguagens. E melhor, leve e prático.

 

 

 

 

 

 

 

 

Site do PNotepad