The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Перевод документации Eiffel по технологии проектирования по контракту

10.03.2013 23:30

Выполнен перевод на русский язык документации Eiffel по технологии проектирования по контракту (Design by Contract).

В мире бизнеса договор между заказчиком и исполнителем определяет, что каждая из сторон выполняет и что получает взамен. Аналогично и разработчики программного обеспечения постоянно полагаются на сторонние библиотеки, которые устанавливают определённые правила их использования. Формализация этих правил привела к созданию метода Проектирования по контракту (Design by Contract™), основанного на формальной верификации, формальной спецификации и логике Хоара. Его новшествами стали:

  • чёткое распределение ответственности между компонентами;
  • применение к наследованию, в частности формализм переопределения методов и динамического связывания;
  • применение к исключительным ситуациям;
  • связь с автоматическим документированием.

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



  1. Главная ссылка к новости (http://www.opennet.me/base/dev...)
  2. OpenNews: Релиз EiffelStudio 7.1, IDE для языка Eiffel
  3. OpenNews: Перевод документации Eiffel по технологии безопасности void safety
  4. Русскоязычный перевод документации Eiffel по технологии SCOOP
Автор новости: croster
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/36353-eiffel
Ключевые слова: eiffel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (12) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Crazy Alex (ok), 02:23, 11/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я так понимаю, аннотация не с английского переводилась? Потому что в ней, простите, чушь написана.

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

     
     
  • 2.2, Аноним (-), 02:51, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > юниттесты позволяют прогнать (в идеале) каждый code path

    Юнит-тесты позволяют протестировать валидность поведения кусочков программы ("юнитов"). Протестировать все возможные code paths в мало-мальски крупной программе становится невозможно из-за совершенно дикого количества их всевозможных сочетаний.

     
     
  • 3.3, Аноним (-), 09:38, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Протестировать все возможные code paths в мало-мальски крупной программе становится невозможно из-за совершенно дикого количества их всевозможных сочетаний.

    Протестировав все возможные входа юнитов, а это вполне реально, автоматом покрываются все code path, нэ?

     
     
  • 4.4, Александр (??), 12:41, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы разрешима. Возможный подход к полному покрытию - model checking, тем не менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному программированию" говорить не приходится.
    Другой вариант - статический анализ, верификация. Там от контрактов деваться практически некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то выводить без подсказок.
     
     
  • 5.5, Аноним (-), 12:49, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы
    > разрешима. Возможный подход к полному покрытию - model checking, тем не
    > менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному
    > программированию" говорить не приходится.
    > Другой вариант - статический анализ, верификация. Там от контрактов деваться практически
    > некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то
    > выводить без подсказок.

    code coverage и задача об остановке никак не связаны.

     
     
  • 6.6, Александр (??), 13:29, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Так ведь code coverage ничего и не гарантирует. Мы можем лишь убедиться, что определённые (все) участки программы достижимы, и на определённых данных вычисляют определённые результаты.
    Контракты никак не отменяют юнит-тесты. Но они позволяют реализовывать дополнительные модели тестирования. То, что сейчас поддерживается в EiffelStudio - возможность автоматически генерировать тесты на основе а) выполнения программы, приводящей к нештатной ситуации; б) вызову отдельных компонентов с сгенерированными входными данными, приводящему к нештатной ситуации. В обоих случаях под нештатной ситуацией понимается нарушение контракта или исключение.
     
     
  • 7.7, Аноним (-), 15:57, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Внезапно, я не противопоставляю контракты и юниттесты. Хотя, ассерты на стероидах, как и сам эйфель просто не нужны.
     
     
  • 8.8, croster (ok), 16:42, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Они и не противопоставляются, применение контрактов не означает полного отказа о... текст свёрнут, показать
     
  • 8.9, Александр (??), 17:17, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Безусловно, существует много ненужных вещей Вопрос лишь в контексте, о котором ... текст свёрнут, показать
     

  • 1.10, northbear (??), 21:20, 11/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Несчастные юнит-тесты. В последнее время про них всё время норовят всякую чушь написать.

    Что значит поддерживать юнит-тесты в актуальном состоянии? И почему их вдруг стало трудно писать?
    Если три-четыре строчки юнит-теста вызывают проблемы, то может вообще не стоит браться разрабатывать приложения? Тем более на Eiffel...

     
     
  • 2.11, Crazy Alex (ok), 21:43, 11/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да там просто идиотскую аннотацию написали. Сама дока вполне достойная, как и контракты в целом.
     
     
  • 3.12, croster (ok), 08:13, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Аннотация обновлена.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру