• Большинство формальных методов фиксируют требования, используя сочетание диаграмм и нескольких пояснительных фраз. На этих рисунках показано, как проектировщик понимает требования. Однако в многих случаях для конечных пользователей эти диаграммы бессмысленны, поэтому они нуждаются в их интерпретации проектировщиками. Следовательно, в реальности формальная проверка требований со стороны фактического пользователя отсутствует – все основывается на объяснениях проектировщика, как и в старомодных письменных требованиях. В этом способе фиксирования требований есть определенная польза, но мы предпочитаем, если это возможно, предоставить в распоряжение пользователя некий прототип и дать ему с ним поиграться.
• Похоже, что формальные методы поощряют специализацию. Одна группа людей работает над моделью данных, другие занимаются архитектурой, в то время как сборщики требований коллекционируют сценарии использования (или их эквивалент). Мы видели, как это приводило к плохому взаимодействию и трате усилий впустую. Кроме того, существует тенденция впадать в умонастроение типа «мы против них» – проектировщики против программистов. Мы же предпочитаем воспринимать систему, над которой работаем, целиком. Скорее всего, невозможно будет глубоко проникнуть в суть каждого аспекта системы, но вы обязаны знать, как взаимодействуют между собой компоненты, куда помещены данные и каковы требования.
• Мы предпочитаем создавать настраиваемые динамичные системы, используя метаданные, позволяющие изменять характер приложений в ходе их выполнения. Большинство современных формальных методов сочетают модель статического объекта или данных с некоторой разновидностью механизма построения диаграммы событий или процесса. Мы пока не встречали механизма, позволяющего отображать динамизм, ожидаемый от систем. На самом деле большинство формальных методов уводят в сторону, поощряя стремление к заданию статических отношений между объектами, которые на самом деле должны быть связаны между собой динамически.
Какова отдача от методов?
В своей статье в журнале САСМ [Gla99b], написанной в 1999 г., Роберт Гласе сделал обзор исследований улучшений в производительности и качестве, достигнутых благодаря семи различным технологиям разработки программ (технология 4GL, структурные методики, CASE-средства, формальные методы, методология «чистой комнаты», модели процессов и ООТ). Он сообщает, что первоначальное оживление, связанное со всеми этими методами, было преувеличено. Хотя существуют указания на то, что у некоторых методов есть преимущества, эти преимущества начинают проявляться только после существенного снижения производительности и качества, в период принятия технологии на вооружение и обучения пользователей.
Не стоит недооценивать стоимость принятия новых инструментальных средств и методов. Подготовьтесь к тому, что первые проекты с применением этих технологий будут предназначены для учебных целей.
Нужно ли использовать формальные методы?
Безусловно. Но не забывайте, что формальные методы разработки – это лишь один инструмент из вашего арсенала. Если после тщательного анализа вы почувствуете, что вам необходим формальный метод, берите его на вооружение, но помните, что несете ответственность. Никогда не становитесь рабом методологии, ведь кружки и стрелки обедняют своих хозяев. Прагматики смотрят на методологии критическим взглядом, затем берут лучшее из каждой и преобразуют их в набор практических технологий, который улучшается каждый месяц. Это является решающим моментом. Вы должны постоянно работать над усовершенствованием процессов. Никогда не делайте жесткие рамки методологии границами вашего собственного мира.
Не подавайтесь ложному авторитету метода. Люди могут ходить на собрания, принося с собой гектары бумаги с изображением диаграмм классов и сто пятьдесят сценариев использования, но вся эта макулатура – лишь их ошибочная интерпретация требований и конструкции. Старайтесь не думать о том, сколько стоит тот или иной инструмент, глядя на результаты его работы.
Подсказка 59: Дорогие инструменты не всегда создают лучшие решения
Конечно, в разработке программ есть место формальным методам. Однако, столкнувшись с проектом, философия которого заключается в изречении «диаграмма класса и есть приложение, все остальное – лишь механическое составление текста программы», знайте, что имеете дело с проектной командой, которая уцепилась за плавучее бревно и медленно гребет к берегу.