Проектирование по контракту ( DbC ), также известное как контрактное программирование , программирование по контракту и программирование по контракту , — это подход к проектированию программного обеспечения .
Он предписывает разработчикам программного обеспечения определять формальные , точные и проверяемые спецификации интерфейса для программных компонентов , которые расширяют обычное определение абстрактных типов данных предусловиями , постусловиями и инвариантами . Эти спецификации называются «контрактами» в соответствии с концептуальной метафорой условий и обязательств деловых контрактов.
Подход DbC предполагает, что все клиентские компоненты , которые вызывают операцию на серверном компоненте , будут соответствовать предварительным условиям, указанным как необходимые для этой операции.
Если это предположение считается слишком рискованным (например, в многоканальных или распределенных вычислениях ), используется обратный подход , означающий, что серверный компонент проверяет, выполняются ли все соответствующие предварительные условия (до или во время обработки запроса клиентского компонента ). и в противном случае отвечает соответствующим сообщением об ошибке.
Этот термин был придуман Бертраном Мейером в связи с его разработкой языка программирования Eiffel и впервые описан в различных статьях, начиная с 1986 года [1] [2] [3] и в двух последовательных изданиях (1988, 1997) его книги «Объект- Ориентированное построение программного обеспечения . Eiffel Software подала заявку на регистрацию товарного знака Design by Contract в декабре 2003 года и получила разрешение в декабре 2004 года. [4] [5] Нынешним владельцем этого товарного знака является Eiffel Software. [6] [7]
Проектирование по контракту уходит корнями в работу над формальной верификацией , формальной спецификацией и логикой Хоара . Оригинальные вклады включают в себя:
Центральная идея DbC — это метафора того, как элементы программной системы взаимодействуют друг с другом на основе взаимных обязательств и выгод . Эта метафора пришла из деловой жизни, где «клиент» и «поставщик» договариваются о «контракте», который определяет, например, что:
Аналогично, если метод класса в объектно-ориентированном программировании предоставляет определенную функциональность, он может :
Контракт семантически эквивалентен тройке Хоара , которая формализует обязательства. Это можно резюмировать «тремя вопросами», на которые проектировщик должен неоднократно ответить в договоре:
Многие языки программирования имеют средства для создания подобных утверждений . Однако DbC считает, что эти контракты настолько важны для корректности программного обеспечения , что они должны быть частью процесса проектирования. По сути, DbC рекомендует сначала писать утверждения . [ нужна цитация ] Контракты могут быть написаны с помощью комментариев к коду , реализованы с помощью набора тестов или и то, и другое, даже если для контрактов не существует специальной языковой поддержки.
Понятие контракта распространяется на уровень метода/процедуры; контракт для каждого метода обычно содержит следующую информацию: [ нужна ссылка ]
Подклассам в иерархии наследования разрешено ослаблять предусловия (но не усиливать их) и усиливать постусловия и инварианты (но не ослаблять их). Эти правила приблизительно соответствуют поведенческим подтипам .
Все отношения классов существуют между классами клиентов и классами поставщиков. Клиентский класс обязан выполнять вызовы функций поставщика, если результирующее состояние поставщика не нарушается клиентским вызовом. В дальнейшем поставщик обязан предоставить состояние возврата и данные, не нарушающие государственные требования клиента.
Например, буфер данных поставщика может требовать, чтобы данные присутствовали в буфере при вызове функции удаления. Впоследствии поставщик гарантирует клиенту, что, когда функция удаления завершит свою работу, элемент данных действительно будет удален из буфера. Другие контракты на проектирование представляют собой концепции инварианта класса . Инвариант класса гарантирует (для локального класса), что состояние класса будет поддерживаться в пределах заданных допусков в конце выполнения каждой функции.
При использовании контрактов поставщик не должен пытаться проверить выполнение условий контракта (практика, известная как наступательное программирование ). Общая идея заключается в том, что код должен «сильно давать сбои», а проверка контракта является защитой.
Свойство DbC «жесткий отказ» упрощает отладку поведения контракта, поскольку предполагаемое поведение каждого метода четко указано.
Этот подход существенно отличается от подхода защитного программирования , где поставщик несет ответственность за выяснение того, что делать, если предварительное условие нарушено. Чаще всего поставщик генерирует исключение, чтобы сообщить клиенту, что предварительное условие нарушено, и в обоих случаях — как DbC, так и защитного программирования — клиент должен придумать, как на это реагировать. В таких случаях DbC облегчает работу поставщика.
Проектирование по контракту также определяет критерии правильности программного модуля:
Проектирование по контракту также может облегчить повторное использование кода, поскольку контракт для каждого фрагмента кода полностью документирован. Контракты на модуль можно рассматривать как форму программной документации , определяющей поведение этого модуля.
Условия контракта никогда не должны нарушаться во время выполнения безошибочной программы. Поэтому контракты обычно проверяются только в режиме отладки во время разработки программного обеспечения. Позже в выпуске проверки контрактов отключаются для максимизации производительности.
Во многих языках программирования контракты реализуются с помощью Assert . Утверждения по умолчанию компилируются в режиме выпуска в C/C++ и аналогичным образом деактивируются в C# [8] и Java.
Запуск интерпретатора Python с «-O» (для «оптимизировать») в качестве аргумента также приведет к тому, что генератор кода Python не будет выдавать какой-либо байт-код для утверждений. [9]
Это эффективно устраняет затраты времени выполнения утверждений в рабочем коде — независимо от количества и вычислительных затрат утверждений, используемых при разработке, — поскольку такие инструкции не будут включены в производство компилятором.
Проектирование по контракту не заменяет обычные стратегии тестирования, такие как модульное тестирование , интеграционное тестирование и тестирование системы . Скорее, оно дополняет внешнее тестирование внутренними самотестами, которые можно активировать как для изолированных тестов, так и в рабочем коде на этапе тестирования.
Преимущество внутренних самотестирований заключается в том, что они могут обнаруживать ошибки до того, как они проявятся в виде неверных результатов, наблюдаемых клиентом. Это приводит к более раннему и более конкретному обнаружению ошибок.
Использование утверждений можно рассматривать как форму тестового оракула , способ тестирования проекта путем реализации контракта.
Языки, которые изначально реализуют большинство функций DbC, включают:
Кроме того, стандартная комбинация методов в Common Lisp Object System имеет квалификаторы методов :before, :afterкоторые :aroundпозволяют, помимо прочего, писать контракты в качестве вспомогательных методов.
Для существующих языков программирования без собственного дизайна были разработаны различные библиотеки, препроцессоры и другие инструменты по контрактной поддержке:
{{cite web}}: CS1 maint: archived copy as title (link)п. 2