Обсуждение:Предпосылка
 | Эта статья имеет рейтинг Stub-class по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects : | ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
Чем предварительные условия отличаются от предпосылок?
Проблемы безопасности могут возникнуть из-за неверных предварительных условий — например, раздел кода, в котором есть предварительное условие, что ввод верный, когда это может быть не так.
Это не совсем пример; он не проясняет для меня, какие проблемы безопасности могут возникнуть. Кроме того, «предварительное условие, что ввод верный» является своего рода избыточным. Galaxiaad 01:10, 14 дек. 2004 (UTC)
Объединить?
Имеет ли смысл объединить постусловие и предусловие ? -- Абдулл 13:01, 2 августа 2006 (UTC)
Предпосылки: Необходимость и Достаточность
Нехарактерно для математика строгости Мейера, что рассмотрение предварительных условий в Главе 11 « Конструирования объектно-ориентированного программного обеспечения» упускает существенный элемент анализа и проектирования: достаточность. В настоящей статье утверждается,
Если предварительное условие нарушено, эффект раздела кода становится неопределенным и, таким образом, он может выполнить или не выполнить свою предполагаемую работу.
Хотя это и правда, утверждение отвлекает внимание от более тонкого случая. Хотя очевидно, что нарушение любого предварительного условия в данном списке достаточно, чтобы гарантировать (не «может» или «не может»), что код, защищенный предварительными условиями, не будет работать (в конце концов, они являются «необходимыми» условиями), что произойдет, когда спецификация предварительных условий недостаточна из-за отсутствия других необходимых условий? Если эти неуказанные условия будут выполнены для данного потока выполнения, все будет хорошо, и пользователь «вознаградится» постусловиями, контракт будет выполнен. Однако, если одно или несколько неуказанных предварительных условий будут нарушены, постусловия не будут достигнуты. Хуже того, отладка будет усложнена необходимостью обнаружения этих неуказанных предположений путем возможной идентификации какой-то внутренней несогласованности в значениях переменных кода.
Неудачный выбор слова require для разграничения предварительных условий в Eiffel предполагает, что неполного набора необходимых условий будет достаточно для обеспечения успеха желаемого результата. Но, как утверждает автор, предварительные условия — это часть контракта вызывающей стороны , которая, если она удовлетворена, вознаграждается постусловиями. Это явно подразумевает, что предварительные условия должны быть полными , то есть достаточными для обеспечения успешного завершения кода.
Недостаточность — распространенное заблуждение, особенно пагубное в повседневном применении метода вариантов использования Якобсона. Предварительные и последующие условия являются стандартными частями шаблонов вариантов использования, но оба чаще соблюдаются при нарушении, чем при соблюдении. Я никогда не слышал о курсе обучения вариантам использования, который бы прямо указывал на это и давал студентам упражнения для практики. Тем не менее, должно быть совершенно ясно, что все необходимые условия должны быть найдены и указаны для достижения желаемого состояния счастья. Все это означает «все необходимое, но ничего лишнего: ничего ненужного»; только тогда можно ожидать гарантии контракта.
Не отмахивайтесь от этого как от пустого мелочного педантизма, потому что это внезапно налагает гораздо более высокую степень формальности на спецификацию требований и последующее применение дополнительной осмотрительности для полной идентификации требований. Теперь аналитик требований не должен просто «правильно» составить спецификацию, но он также должен сделать ее «полной», и доказуемо. С практикой проектировщики привыкают к такой осмотрительности, но для тех, кто не привык к формальным методам анализа и проектирования, это поначалу становится проблемой. Заинтересованный читатель, возможно, захочет поразмыслить над тем, как этот стандартный шаблон в составлении контракта: «За хорошее и ценное вознаграждение, получение и достаточность которого настоящим подтверждаются...» относится к проектированию по контракту при разработке программного обеспечения.
Я также хотел бы отметить, что это обсуждение достаточности предусловия не вносит ничего нового в проектирование и разработку объектно-ориентированного ПО. Достаточность предполагается в большинстве обсуждений проектирования по контракту, например, в Проектировании по контракту. Там эта идея глубоко укоренилась в обсуждении DbC, но она всегда неявная. Если первоначальный автор все еще поддерживает статью DbC или эту, я бы рекомендовал добавить краткое упоминание достаточности предусловия в одну или обе статьи.
--Edgeorge99 ( обсуждение ) 17:34, 4 апреля 2018 (UTC)Дункан Джордж, Уитчерч-Стауффвилл, Канада
