𝖂𝖎ƙ𝖎𝖊

Programação por contrato

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:

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":

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:

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:

Ferramentas em Geral

Consulte Também

Bibliografia

  1. ↑ Meyer, Bertrand: Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986
  2. ↑ Meyer, Bertrand: Design by Contract, em Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1-50
  3. ↑ Meyer, Bertrand: Applying "Design by Contract", in Computer (IEEE), 25, 10, October 1992, pages 40-51, também disponível em online
  4. ↑ United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"
  5. ↑ United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"
  6. ↑ Current status of United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"
  7. ↑ Current status of United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"
  8. ↑ Bright, Walter (20 de agosto de 2006). «D Programming Language, Contract Programming». Digital Mars. Consultado em 6 de outubro de 2006 

Predefinição:Refbegin

  • Mitchell, Richard, and McKim, Jim: Design by Contract: by example, Addison-Wesley, 2002
  • A wikibook describing DBC closely to the original model.

Predefinição:Refend

Ligações externas

talvez você goste

Permaneça conectado

Parceiros

Dieta Cetogenica | NutriPro Saúde