Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [ 21 ] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Проектирование по контракту

Проектирование по контракту (Design by Contract) - это метод проектирования, разработанный Бертраном Мей ером. Этот метод является центральным свойством языка Eiffel, который он разработал. Однако проектирование по контракту не является специфичным только для языка Eiffel; этот метод может быть использован и с любым другим языком программирования.

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

Метод проектирования по контракту использует три вида утверждений: предусловия, постусловия и инварианты.

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

Предусловие - это высказывание относительно того, как должен выглядеть окружающий мир до выполнения операции. Для операции извлечь квадратный корень можно определить предусловие вход >= 0. Такое предусловие утверждает, что применение операции извлечь квадратный корень для отрицательного числа является ошибочным и последствия такого применения будут неопределенными.

На первый взгляд эта идея кажется неудачной, поскольку нам придется выполнить некоторые дополнительные проверки, что-

чтобы их было проще понимать. Язык UML также предоставляет для этой цели формальный язык объектных ограничений (ОСЬ, Object Constraint Language), с которым можно познакомиться по книге Уор-мера (Warmer) и Клеппе (Kleppe), 1998 [45].

В идеальном случае правила ограничения следует реализовывать в виде утверждений на языке программирования. Это согласуется с понятием инварианта при проектировании по контракту (см. врезку).

бы убедиться в корректности выполнения операции извлечь квадратный корень . При этом возникает важный вопрос: кто должен быть ответственным за выполнение этой проверки.

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

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

Инвариант представляет собой утверждение относительно класса. Например, класс Счет может иметь инвариант вида обаланс = сумма(позиция.количество())*. Инвариант должен быть всегда истинным для всех экземпляров класса. Всегда в данном случае означает всякий раз, когда объект инициирует выполнение какой бы то ни было операции .

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

Утверждения могут играть уникальную роль в задании подклассов.

Одна из опасностей полиморфизма заключается в том, что вы можете переопределить операции подкласса таким образом, что они станут несовместимыми с операциями суперкласса. Утверждения не позволят вам выполнить подобные действия. Инварианты и постусловия класса должны применяться ко всем подклассам. Подклассы могут усилить эти утверждения, но не могут ослабить их. С другой стороны, предусловие нельзя усилить, но можно ослабить.

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

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

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

Когда следует использовать проектирование по контракту

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

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

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

Где найти дополнительную информацию

Книга Мейера (Meyer), 1997 [33] является классической работой в области объектно-ориентированного проектирования, в ней много внимания уделяется утверждениям. Ким Уолден и Жан-Марк Нирсон, 1995 [44], а также Стив Кук и Джон Дэниеле, 1994 [13] в своих книгах часто прибегают к использованию метода контрактного проектирования.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [ 21 ] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.