Дизайн по контракту - Design by contract

Дизайн по договорной схеме

Дизайн по контракту (DbC), также известный как контрактное программирование, программирование по контракту и программирование по контракту, это подход для разработка программного обеспечения.

Он предписывает разработчикам программного обеспечения определять формальный, точные и проверяемые спецификации интерфейса для программные компоненты, которые расширяют обычное определение абстрактные типы данных с предварительные условия, постусловия и инварианты. Эти спецификации называются «контрактами» в соответствии с концептуальная метафора с условиями и обязательствами хозяйственных договоров.

Подход DbC предполагает все клиентские компоненты которые вызывают операцию над серверный компонент будет соответствовать предварительным условиям, указанным как требуемые для этой операции.

Если это предположение считается слишком рискованным (например, в многоканальном или распределенных вычислений ) обратный подход берется, что означает, что серверный компонент проверяет, что все соответствующие предварительные условия выполняются (до или во время обработки клиентский компонент 's запрос) и отвечает подходящим сообщением об ошибке, если нет.

История

Термин был придуман Бертран Мейер в связи с его дизайном Язык программирования Eiffel и впервые описаны в различных статьях, начиная с 1986 г.[1][2][3] и два последовательных издания (1988, 1997) его книги Построение объектно-ориентированного программного обеспечения. Eiffel Software подала заявку на регистрацию товарного знака для Дизайн по контракту в декабре 2003 г., а предоставлена ​​в декабре 2004 г.[4][5] Текущий владелец этого товарного знака - Eiffel Software.[6][7]

Дизайн по контракту берет свое начало в работе над формальная проверка, формальная спецификация и Логика Хоара. Оригинальные материалы включают:

Описание

Центральная идея DbC - это метафора того, как элементы программной системы взаимодействуют друг с другом на основе взаимного взаимодействия. обязательства и преимущества. Метафора пришла из деловой жизни, где «клиент» и «поставщик» договариваются о «контракте», который определяет, например, следующее:

  • Поставщик должен предоставить определенный товар (обязательство) и вправе ожидать, что клиент уплатил его гонорар (выгоду).
  • Клиент должен оплатить комиссию (обязательство) и имеет право на получение продукта (выгоду).
  • Обе стороны должны соблюдать определенные обязательства, такие как законы и правила, применимые ко всем контрактам.

Аналогично, если метод из учебный класс в объектно-ориентированного программирования предоставляет определенную функциональность, может:

  • Ожидайте, что определенное условие будет гарантировано при входе любым клиентским модулем, который его вызывает: метод предварительное условие - обязательство для клиента и выгода для поставщика (сам метод), так как он освобождает его от необходимости заниматься делами вне предварительного условия.
  • Гарантировать определенную собственность на выходе: метод постусловие - обязанность поставщика и, очевидно, выгода (основное преимущество вызова метода) для клиента.
  • Сохранение определенного свойства, предполагаемого при входе и гарантированного при выходе: инвариант класса.

Контракт семантически эквивалентен Хоар тройной который формализует обязательства. Это можно резюмировать «тремя вопросами», на которые проектировщик должен неоднократно отвечать в контракте:

  • Чего требует контракт?
  • Что гарантирует договор?
  • Что содержится в контракте?

Много языки программирования иметь возможности сделать утверждения как это. Однако DbC считает эти контракты очень важными для правильность программного обеспечения что они должны быть частью процесса проектирования. Фактически, DbC защищает сначала напишите утверждения.[нужна цитата ] Контракты могут быть написаны комментарии к коду, принудительно тестирование или и то, и другое, даже если для контрактов нет специальной языковой поддержки.

Понятие контракта простирается до уровня метода / процедуры; контракт для каждого метода обычно будет содержать следующую информацию:[нужна цитата ]

Подклассы в иерархия наследования разрешено ослаблять предусловия (но не усиливать их) и усиливать постусловия и инварианты (но не ослаблять их). Эти правила приблизительно поведенческий подтип.

Все отношения классов существуют между классами клиентов и классами поставщиков. Класс клиента обязан выполнять вызовы функций поставщика, в которых конечное состояние поставщика не нарушается вызовом клиента. Впоследствии поставщик обязан предоставить возвращаемое состояние и данные, не нарушающие государственных требований клиента.

Например, буфер данных поставщика может потребовать, чтобы данные присутствовали в буфере при вызове функции удаления. Впоследствии поставщик гарантирует клиенту, что, когда функция удаления завершит свою работу, элемент данных действительно будет удален из буфера. Другие контракты на проектирование представляют собой концепции инвариант класса. Инвариант класса гарантирует (для локального класса), что состояние класса будет поддерживаться в пределах указанных допусков в конце выполнения каждой функции.

При использовании контрактов поставщик не должен пытаться проверить выполнение условий контракта - практика, известная как наступательное программирование - общая идея состоит в том, что код должен «терпеть неудачу», а проверка контракта является страховочной сеткой.

Свойство DbC «жесткий сбой» упрощает отладку поведения контракта, поскольку предполагаемое поведение каждого метода четко указано.

Этот подход существенно отличается от подхода защитное программирование, где поставщик отвечает за выяснение, что делать, если предварительное условие нарушено. Чаще всего поставщик генерирует исключение, чтобы сообщить клиенту, что предварительное условие было нарушено, и в обоих случаях - как в DbC, так и в защитном программировании - клиент должен выяснить, как на это отреагировать. В таких случаях DbC облегчает работу поставщика.

Дизайн по контракту также определяет критерии корректности программного модуля:

  • Если инвариант класса И предусловие истинны до вызова поставщика клиентом, то инвариант И постусловие будет истинным после того, как услуга будет завершена.
  • При обращении к поставщику программный модуль не должен нарушать предварительные условия поставщика.

Дизайн по контракту также может облегчить повторное использование кода, поскольку контракт для каждой части кода полностью документирован. Контракты на модуль можно рассматривать как форму документация по программному обеспечению для поведения этого модуля.

Последствия для производительности

Условия контракта никогда не должны нарушаться во время выполнения программы без ошибок. Поэтому контракты обычно проверяются только в режиме отладки во время разработки программного обеспечения. Позже при выпуске проверки контрактов отключаются, чтобы максимизировать производительность.

Во многих языках программирования контракты реализуются с помощью утверждать. Утверждения по умолчанию компилируются в режиме выпуска в C / C ++ и аналогичным образом деактивируются в C #.[8] и Java.

Запуск интерпретатора Python с аргументом «-O» (от «optimize») в качестве аргумента также приведет к тому, что генератор кода Python не будет выдавать байт-код для утверждений.[9]

Это эффективно исключает затраты времени выполнения на утверждения в производственном коде - независимо от количества и вычислительных затрат на утверждения, используемые при разработке, - поскольку никакие такие инструкции не будут включены в производство компилятором.

Отношение к тестированию программного обеспечения

Дизайн по контракту не заменяет обычные стратегии тестирования, такие как модульное тестирование, интеграционное тестирование и системное тестирование. Скорее, он дополняет внешнее тестирование внутренними самотестированием, которые можно активировать как для изолированных тестов, так и в производственном коде на этапе тестирования.

Преимущество внутренних самотестирования заключается в том, что они могут обнаруживать ошибки до того, как они проявят себя как недействительные результаты, наблюдаемые клиентом. Это приводит к более раннему и более конкретному обнаружению ошибок.

Использование утверждений можно рассматривать как форму тестовый оракул, способ тестирования проекта при выполнении контракта.

Языковая поддержка

Языки с собственной поддержкой

Языки, которые изначально реализуют большинство функций DbC, включают:

Языки со сторонней поддержкой

Различные библиотеки, препроцессоры и другие инструменты были разработаны для существующих языков программирования без нативной разработки посредством контрактной поддержки:

Смотрите также

Примечания

  1. ^ Мейер, Бертран: Дизайн по контракту, Технический отчет TR-EI-12 / CO, Interactive Software Engineering Inc., 1986
  2. ^ Мейер, Бертран: Дизайн по контракту, в Достижения в объектно-ориентированной разработке программного обеспечения, ред. Д. Мандриоли и Б. Мейер, Prentice Hall, 1991, стр. 1–50.
  3. ^ Мейер, Бертран: Применение «Дизайн по контракту», in Computer (IEEE), 25, 10, October 1992, pp. 40–51, также доступно. онлайн
  4. ^ «Регистрация в Ведомстве США по патентам и товарным знакам» ПРОЕКТИРОВАНИЕ ПО КОНТРАКТУ"".
  5. ^ «Регистрация в Ведомстве США по патентам и товарным знакам для графического дизайна со словами« Дизайн по контракту »"".
  6. ^ «Статус товарного знака и поиск документов». tarr.uspto.gov.
  7. ^ «Статус товарного знака и поиск документов». tarr.uspto.gov.
  8. ^ «Утверждения в управляемом коде». msdn.microsoft.com.
  9. ^ Официальные документы Python, утверждение утверждения
  10. ^ Брайт, Уолтер (2014-11-01). "Язык программирования D, контрактное программирование". Цифровой Марс. Получено 2014-11-10.
  11. ^ Ходжес, Ник. «Пишите более чистый и качественный код с контрактами классов в Delphi Prism». Embarcadero Technologies. Получено 20 января 2016.
  12. ^ Финдлер, Фелляйзен Контракты на функции высшего порядка
  13. ^ «Документы стандартной библиотеки Scala - утверждения». EPFL. Получено 2019-05-24.
  14. ^ Сильная типизация как еще одно «исполнение контракта» в Scala, см. обсуждение на scala-lang.org/.
  15. ^ «Кодовые контракты». msdn.microsoft.com.
  16. ^ "Спецификация проверки компонентов". beanvalidation.org.
  17. ^ https://www.parasoft.com/wp-content/uploads/pdf/JtestDataSheet.pdf
  18. ^ «Архивная копия» (PDF). Архивировано из оригинал (PDF) на 2016-03-28. Получено 2016-03-25.CS1 maint: заархивированная копия как заголовок (связь) п. 2
  19. ^ «Нет шансов на выпуск под лицензией Apache / Eclipse / MIT / BSD? · Проблема №5 · nhatminhle / cofoja». GitHub.

Библиография

  • Митчелл, Ричард, и МакКим, Джим: Дизайн по контракту: на примере, Аддисон-Уэсли, 2002 г.
  • А викибук описание DBC близко к исходной модели.
  • Макнейл, Эшли: Основа семантики поведенческих контрактов. Труды второго международного семинара по моделированию поведения: основы и приложения (BM-FA '10). ACM, Нью-Йорк, Нью-Йорк, США, 2010. В этой статье обсуждаются обобщенные понятия Договор и Заменяемость.

внешняя ссылка