PROFILPELAJAR.COM

Programação por contrato do inglês Design by contract (DbC) é um abordagem de desenvolvimento de software que prescreve que os desenvolvedores devem definir métodos formais, especificações de interface precisas e verificáveis dos componentes de desenvolvimento de software, que acarreta na definição de Tipo Abstrato de Dados com pre-condições, pos-condições e constantes. Estas especificações são definidas como um "contrato", de acordo com os próprios conceitos de condições e obrigações dos contratos de negócio.

Devido o termo Design by Contract ser marca registrada da Eiffel Software nos EUA, muitos desenvolvedores se referem à abordagem como Programação por Contrato (Programming by contract).

História

O termo foi registrado por Bertrand Meyer em união com a linguagem de programação Eiffel e descreveu inicialmente em vários artigos em 1986^[1]^[2]^[3] e 2 edições sucessivas (1988, 1997) de seu livro Object-Oriented Software Construction. Eiffel Software atribuiu o registro da marca Design by Contract em Dezembro de 2003, e a obteve em Dezembro de 2004.^[4]^[5] O atual detentor destes termos é a Eiffel Software.^[6]^[7]

Programação por Contrato tem suas raízes em Verificação Formal, Especificação Formal e Lógica Hoare. As contribuições originais incluem:

Uma metáfora nítida para auxílio no processo de elaboração.
A aplicação da Herança, em uma formalização para redefinição e Ligação dinâmica.
O uso de Tratamento de exceção.
A conexão com automatização de Documentação de software.

Descrição

A ideia Central do DbC é a metáfora onde como os elementos de um software colaboram entre si, baseando-se em obrigações e benefícios mútuos. A metáfora vem do mundo dos negócios, onde um "cliente" e um "Fornecedor" acordam sobre um "contrato" que define por exemplo:

O fornecedor deve prover um determinado produto(obrigação) e fica entendido que o cliente tenha pago por isto (benefício).
O cliente deve pagar o valor (obrigação) e é garantido a obter o produto (benefício).
Ambas partes satisfazem suas obrigações, através de leis e regulamentações, aplicadas a todos os contratos.

Similarmente, se a rotina de uma Classe em Programação Orientada a objetos provê uma certa funcionalidade, isto deve :

Aguardar uma certa condição para garantir que uma informação no módulo de clientes o chame: a pré-condição da rotina — uma obrigação para o cliente, e o benefício do fornecedor (a rotina em si), eliminando casos de executar por outros meios.
Garantir uma certa condição de saída: A pós-condição da rotina — uma obrigação do fornecedor, e obviamente um benefício (o maior benefício de chamar a rotina) para o cliente.
Manter uma determinada propriedade, assumida na entrada e garantida na saída: uma Classe Constante.

O contrato é a formalização destas obrigações e benefícios. É possível resumir Programação por contrato através de "3 perguntas" que um designer deve-se fazer constantemente:

O que isto prevê?
O que isto garante?
O que isto mantém?

Muitas linguagens de programação possuem facilidades em fazer asserções como estas. Contudo, o DbC considera estes contratos cruciais para as correções do software, que deve ser parte do processo de design. De fato, DbC defende a escrita de asserções inicialmente.

A noção de contrato se estende aos níveis de métodos e procedimentos; o contrato de cada método irá normalmente conter as seguintes "clausulas":

Valores e tipos aceitáveis e rejeitáveis, e seus motivos
Tipos e valores de retorno, e seus motivos
Condições de Erro e Tratamento de exceção que podem ocorrer, e suas justificativas
Efeitos colaterais
Pre-condições
Pós-condições
Constantes
(eventualmente) Garantias de Performance, ex: tempo e espaço consumidos

Subclasses em uma hierarquia de herança são permitidas para facilitar pre-condições (e não reforçá-las) e reforçar portanto pós-condições e constantes (porém, não ignorá-las). Estas regras facilitam a utilização de subclasses.

Todos os relacionamentos entre Cliente e Fornecedor estão entre as classes. A classe Cliente é obrigada a fazer chamadas às funcionalidades dos Fornecedores de forma que o estado do Fornecedor não seja violado. Consequentemente, o Fornecedor é obrigado a fornecer um estado de retorno e dados que garantam que nada foi violado. Instanciando-se, pode ser necessário que os dados do Fornecedor estejam em buffer no momento da solicitação de deleção. Desta forma, o Fornecedor garante ao Cliente que a exclusão conclua este trabalho, a informação vai, de fato, ser apagada do registro. Outros conceitos de DbC são "Classe constante". A classe constante garante (para a classe local) que o estado da classe será mantido dentro de tolerâncias especificadas no fim de cada execução de funcionalidade.

Quando se utiliza contrato, para um Fornecedor que esquecer de verificar se as condições de um contrato são satisfeitas; a ideia em geral é que o código "falhe bruscamente", mantendo o contrato em uma rede segura. A propriedade de "Falhar bruscamente" dos DbC's simplifica a depuração do comportamento do contrato como a intenção de cada rotina deve ser claramente especificada. Isto é conhecido como uma prática relacionada conhecida como programação defensiva, onde o Fornecedor é responsável por identificar quando uma pré-condição foi quebrada. Mais normal do que se imagina, O fornecedor controla uma exceção para informar o cliente que uma precondição foi quebrada, e nos 2 casos - DbC e programação defensiva - o cliente deve identificar como lidar com a situação. O DbC torna o trabalho do fornecedor mais simples.

DbC define também critérios de correção para um módulo do software:

Se a classe constante E a precondição são verdadeiras antes do fornecedor ser chamado pelo cliente, então a constante e a pós-condição serão verdadeiras após o serviço ser concluído.
Fazendo uma chamada para um fornecedor, o módulo do software não pode violar as pré-condições da classe em questão (Fornecedor).

Devido as condições do contrato não poderem ser violadas durante a execução do programa, eles podem tanto serem deixados num código de depuração ou removidos na versão de produção por questão de performance.

O reúso também é facilitado pela aplicação do DbC, desde que o contrato de cada parte do código for completamente documentado. O contrato de um módulo pode ser definido através de uma documentação de software conforme o comportamento de cada módulo.

Relação com o teste de Software

Teste unitário testa um módulo isoladamente, para certificar que está se assumindo as cláusulas do contrato e subcontratos usados no caso de uso. Teste de integração avalia se os módulos estão operando normalmente quando em conjunto.

Suporte de linguagem

Linguagens com suporte nativo

Dentre as linguagens que implementam a maioria das funcionalidades do DbC estão:

Cobra
D^[8]
Eiffel
Fortress
en:Lisaac
Nice
Oxygene (formerly Chrome)
Sather
SPARK, via static analysis dos programas em Ada .
Spec#

Linguagens com suporte de terceiros

Várias bibliotecas, pre-processos e outras ferramentas estão sendo desenvolvidas para as linguagens de programação sem o suporte nativo à DbC:

Ada, via definições de GNAT para pré e pós condições. O grupo Ada Rapporteur está preparando a inclusão de programas de subcontratos (AI05-0145) e tipos de constantes (AI05-0146) em uma versão futura do Ada, Ada 201X.
C and C++, via 'DBC para C preprocessor, GNU Nana, ou Digital Mars compilador C++, via extensão CTESK do C. Loki Library provê um mecanismo chamado ContractChecker que verifica se uma classe segue o contrato definido no DbC.
C# (e outras linguagens .NET), via Code Contracts (uma Pesquisa da Microsoft pretende integrar no .NET Framework 4.0)
Java, via AspectJML, OVal, iContract2, Contract4J, jContractor, Jcontract, C4J, CodePro Analytix, STclass, Jass preprocessor, OVal with AspectJ, Java Modeling Language (JML), SpringContracts for the Spring framework, or Modern Jass, Custos^{[ligação inativa]} using AspectJ,JavaDbC usando AspectJ, JavaTESK através da extensão do Java.
JavaScript, via Cerny.js ou ecmaDebug.
Lisp
- Common Lisp, via as facilidades de macroCLOS protocolo de meta objeto.
- Scheme, através da extensão o esquema PLT, enfatizando que cada violação de contrado deve exigir uma justificativa do culpado.[1]
Nemerle, via macros.
Perl, via modulos CPAN Class::Contract (by Damian Conway) ou Carp::Datum (by Raphael Manfredi).
Python, usando pacotes como zope.interface, PyDBC ou Contracts for Python.
Ruby, via Brian McCallister's DesignByContract, Ruby DBC ou ruby-contract.

Ferramentas em Geral

Perfect Developer, através da especificação da linguagem Perfect, pode-se verificar contratos com análise de código estático e gerar programas em linguagems como C++ e Java.