Projeto por contrato

Um projeto por esquema de contrato

Design por contrato ( DbC ), também conhecido como programação de contrato , programação por contrato e programação de design por contrato , é uma abordagem para projetar software .

Ela prescreve que os designers de software devem definir especificações de interface formais , precisas e verificáveis ​​para componentes de software , que estendem a definição comum de tipos de dados abstratos com pré -condições , pós -condições e invariantes . Essas especificações são chamadas de "contratos", segundo uma metáfora conceitual com as condições e obrigações dos contratos comerciais.

A abordagem DbC pressupõe que todos os componentes do cliente que invocam uma operação em um componente do servidor atenderão às pré-condições especificadas conforme necessário para essa operação.

Onde essa suposição é considerada muito arriscada (como na computação multicanal ou distribuída ), a abordagem inversa é adotada, o que significa que o componente do servidor testa se todas as pré-condições relevantes são verdadeiras (antes ou durante o processamento da solicitação do componente cliente ) e responde com uma mensagem de erro adequada se não.

História

O termo foi cunhado por Bertrand Meyer em conexão com seu projeto da linguagem de programação Eiffel e descrito pela primeira vez em vários artigos começando em 1986 ^{[1] [2] [3]} e as duas edições sucessivas (1988, 1997) de seu livro Object- Construção Orientada de Software . A Eiffel Software solicitou o registro de marca para Design by Contract em dezembro de 2003, e foi concedido em dezembro de 2004. ^{[4] [5]} O atual proprietário desta marca registrada é Eiffel Software. ^{[6] [7]}

O projeto por contrato tem suas raízes no trabalho de verificação formal , especificação formal e lógica Hoare . As contribuições originais incluem:

• Uma metáfora clara para guiar o processo de design
• A aplicação à herança , em particular um formalismo para redefinição e vinculação dinâmica
• A aplicação para tratamento de exceções
• A conexão com a documentação automática do software

Descrição

A idéia central do DbC é uma metáfora sobre como os elementos de um sistema de software colaboram entre si com base em obrigações e benefícios mútuos . A metáfora vem da vida empresarial, onde um "cliente" e um "fornecedor" acertam um "contrato" que define, por exemplo, que:

• O fornecedor deve fornecer um determinado produto (obrigação) e tem o direito de esperar que o cliente tenha pago sua taxa (benefício).
• O cliente deve pagar a taxa (obrigação) e tem direito a receber o produto (benefício).
• Ambas as partes devem cumprir certas obrigações, como leis e regulamentos, aplicáveis ​​a todos os contratos.

Da mesma forma, se o método de uma classe na programação orientada a objetos fornece uma certa funcionalidade, ele pode:

• Espere que uma certa condição seja garantida na entrada por qualquer módulo cliente que o chame: a pré- condição do método — uma obrigação para o cliente e um benefício para o fornecedor (o próprio método), pois o libera de ter que lidar com casos fora do a pré-condição.
• Garantir uma certa propriedade na saída: a pós -condição do método — uma obrigação para o fornecedor e, obviamente, um benefício (o principal benefício de chamar o método) para o cliente.
• Manter uma certa propriedade, assumida na entrada e garantida na saída: a classe invariante .

O contrato é semanticamente equivalente a um triplo Hoare que formaliza as obrigações. Isso pode ser resumido pelas "três perguntas" que o designer deve responder repetidamente no contrato:

• O que o contrato espera?
• O que o contrato garante?
• O que o contrato mantém?

Muitas linguagens de programação têm facilidades para fazer afirmações como essas. No entanto, a DbC considera esses contratos tão cruciais para a correção do software que devem fazer parte do processo de design. Com efeito, a DbC defende que as afirmações sejam escritas primeiro . ^{[ citação necessária ]} Os contratos podem ser escritos por comentários de código , aplicados por um conjunto de testes , ou ambos, mesmo se não houver suporte de linguagem especial para contratos.

A noção de contrato estende-se ao nível do método/procedimento; o contrato para cada método normalmente conterá as seguintes informações: ^{[ citação necessária ]}

• Valores ou tipos de entrada aceitáveis ​​e inaceitáveis ​​e seus significados
• Valores ou tipos de retorno e seus significados
• Valores ou tipos de condição de erro e exceção que podem ocorrer e seus significados
• Efeitos colaterais
• Pré-condições
• Pós-condições
• Invariantes
• (mais raramente) Garantias de desempenho, por exemplo, para tempo ou espaço usado

Subclasses em uma hierarquia de herança podem enfraquecer pré-condições (mas não fortalecê-las) e fortalecer pós-condições e invariantes (mas não enfraquecê-las). Essas regras se aproximam da subtipagem comportamental .

Todos os relacionamentos de classe são entre classes de clientes e classes de fornecedores. Uma classe de cliente é obrigada a fazer chamadas para recursos do fornecedor onde o estado resultante do fornecedor não é violado pela chamada do cliente. Posteriormente, o fornecedor é obrigado a fornecer um estado de retorno e dados que não violem os requisitos estaduais do cliente.

Por exemplo, um buffer de dados do fornecedor pode exigir que os dados estejam presentes no buffer quando um recurso de exclusão é chamado. Posteriormente, o fornecedor garante ao cliente que quando um recurso de exclusão terminar seu trabalho, o item de dados será, de fato, excluído do buffer. Outros contratos de design são conceitos de invariante de classe . A invariante de classe garante (para a classe local) que o estado da classe será mantido dentro das tolerâncias especificadas ao final de cada execução de recurso.

Ao usar contratos, um fornecedor não deve tentar verificar se as condições do contrato estão satisfeitas - uma prática conhecida como programação ofensiva - a ideia geral é que o código deve "falhe com força", com a verificação do contrato sendo a rede de segurança.

A propriedade "fail hard" do DbC simplifica a depuração do comportamento do contrato, pois o comportamento pretendido de cada método é claramente especificado.

Essa abordagem difere substancialmente da programação defensiva , onde o fornecedor é responsável por descobrir o que fazer quando uma pré-condição é quebrada. Na maioria das vezes, o fornecedor lança uma exceção para informar ao cliente que a pré-condição foi quebrada e, em ambos os casos – DbC e programação defensiva – o cliente deve descobrir como responder a isso. Nesses casos, o DbC facilita o trabalho do fornecedor.

Design por contrato também define critérios de correção para um módulo de software:

• Se a pré-condição AND invariante de classe for verdadeira antes de um fornecedor ser chamado por um cliente, então a condição AND invariante será verdadeira depois que o serviço for concluído.
• Ao fazer chamadas para um fornecedor, um módulo de software não deve violar as pré-condições do fornecedor.

O design por contrato também pode facilitar a reutilização de código, pois o contrato de cada parte do código é totalmente documentado. Os contratos para um módulo podem ser considerados como uma forma de documentação de software para o comportamento desse módulo.

Implicações de desempenho

As condições do contrato nunca devem ser violadas durante a execução de um programa livre de bugs. Os contratos são, portanto, normalmente verificados apenas no modo de depuração durante o desenvolvimento do software. Mais tarde, no lançamento, as verificações de contrato são desativadas para maximizar o desempenho.

Em muitas linguagens de programação, os contratos são implementados com assert . Asserts são, por padrão, compiladas no modo de lançamento em C/C++, e desativadas da mesma forma em C# ^[8] e Java.

Iniciar o interpretador Python com "-O" (para "otimizar") como argumento também fará com que o gerador de código Python não emita nenhum bytecode para asserções. ^[9]

Isso elimina efetivamente os custos de tempo de execução das assertivas no código de produção – independentemente do número e do gasto computacional de asserts usadas no desenvolvimento – pois nenhuma dessas instruções será incluída na produção pelo compilador.

Relação com teste de software

O design por contrato não substitui as estratégias de teste regulares, como teste de unidade, teste de integração e teste de sistema . Em vez disso, complementa os testes externos com autotestes internos que podem ser ativados tanto para testes isolados quanto em código de produção durante uma fase de teste.

A vantagem dos autotestes internos é que eles podem detectar erros antes que eles se manifestem como resultados inválidos observados pelo cliente. Isso leva a uma detecção de erros mais precoce e específica.

O uso de assertivas pode ser considerado uma forma de oráculo de teste , uma forma de testar o design pela implementação do contrato.

Suporte a idiomas

Idiomas com suporte nativo

As linguagens que implementam a maioria dos recursos DbC nativamente incluem:

• Ada 2012
• tchau
• Clojure
• Cobra
• D ^[10]
• Dafny
• Eiffel
• Fortaleza
• Kotlin
• Mercúrio
• Oxygene (anteriormente Chrome e Delphi Prism ^[11] )
• Racket (incluindo contratos de ordem superior e enfatizando que as violações de contrato devem culpar a parte culpada e devem fazê-lo com uma explicação precisa ^[12] )
• Sather
• Escala ^{[13] [14]}
• SPARK (via análise estática de programas Ada )
• Vala
• VDM

Idiomas com suporte de terceiros

Várias bibliotecas, pré-processadores e outras ferramentas foram desenvolvidas para linguagens de programação existentes sem design nativo por suporte de contrato:

• Ada , via pragmas GNAT para pré-condições e pós-condições.
• C e C++ :
  • Impulsionar.Contrato
  • DBC para pré- processador C
  • GNU Nana
  • Ferramentas de verificação formal eCv e eCv++
  • Compilador Digital Mars C++ via extensão CTESK de C
  • A Biblioteca Loki fornece um mecanismo chamado ContractChecker que verifica se uma classe segue o design por contrato.
  • DBC C++ Design por contrato para C++
• C# (e outras linguagens .NET), via Code Contracts ^[15] (um projeto da Microsoft Research integrado ao .NET Framework 4.0)
• Groovy via GContracts
• Vá via dbc ou gocontracts
• Java :
  • Ativo:
    • OVal com AspectJ
    • Contratos para Java (Cofoja)
    • Linguagem de modelagem Java (JML)
    • Validação de Bean (somente pré e pós-condições) ^[16]
    • valid4j
  • Inativo/desconhecido:
    • Jtest (ativo, mas DbC parece não ser mais suportado) ^[17]
    • iContract2/JContracts
    • Contrato 4J
    • jContratado
    • C4J
    • Google CodePro Analytix
    • SpringContracts para o Spring Framework
    • Jass
    • Modern Jass (sucessor é Cofoja) ^{[18] [19]}
    • JavaDbC usando AspectJ
    • JavaTESK usando extensão de Java
    • chex4j usando javassist
    • java-on-contratos altamente personalizáveis
• JavaScript , via AspectJS (especificamente, AJS_Validator), Cerny.js, ecmaDebug, jsContract, dbc -code-contracts ou jscategory.
• Common Lisp , por meio do recurso de macro ou do protocolo de metaobjeto CLOS .
• Nemerle , via macros.
• Nim , via macros .
• Perl , através dos módulos CPAN Class::Contract (por Damian Conway ) ou Carp::Datum (por Raphael Manfredi).
• PHP , via PhpDeal , Praspel ou Stuart Herbert's ContractLib.
• Python , usando pacotes como deal , icontract, PyContracts, Decontractors, dpcontracts, zope.interface, PyDBC ou Contracts for Python. Uma mudança permanente no Python para suportar o design por contratos foi proposta no PEP-316, mas adiada.
• Ruby , via DesignByContract de Brian McCallister, Ruby DBC ruby-contract ou Contracts.ruby.
• Ferrugem através da caixa de contratos .
• Tcl , por meio da extensão orientada a objetos XOTcl .

Veja também

• Engenharia de software baseada em componentes
• Correção (ciência da computação)
• Programação defensiva
• Fail-fast
• Métodos formais
• lógica Hoare
• Programação modular
• Derivação do programa
• Refinamento do programa
• Digitação forte
• Desenvolvimento orientado a testes
• Análise Typestate

Notas

Bibliografia

Links externos

• The Power of Design by Contract(TM) Uma descrição de alto nível do DbC, com links para recursos adicionais.
• Construindo software OO livre de bugs: Uma introdução ao Design by Contract(TM) Material antigo em DbC.
• Benefícios e desvantagens; Implementação em RPS-Obix
• Bertrand Meyer, Aplicando "Design by Contract" , IEEE Computer, outubro de 1992.
• Usando contratos de código para um código mais seguro