Человеческий фактор в программировании

Константин Ларри Л.

Из журнала Software Development, том 1, № 4, апрель 1993 г.

IV

Инструменты, модели и методы

18

CASE и познание

Автоматизированное проектирование и создание программ (CASE, Computer-Aided Software Engineering) больше не является актуальной темой в области разработки программного обеспечения и приложений. Даже производители CASE-инструментов стараются переименовывать свои продукты, называя их «средами комплексной разработки» или просто «наборами инструментов». Как бы они ни назывались, средства разработки, которые мы применяем (успешно или неуспешно), в значительной степени связаны с тем, к чему мы стремимся как разработчики.

Иногда я бываю ярым сторонником инструментов.

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

Неудивительно, что зачастую можно услышать что-нибудь этакое: «У нас нет времени на использование CASE-инструментов, нас поджимают сроки». Это могут произносить те программисты (теперь уже полысевшие или поседевшие), которые когда-то возражали против языков высокого уровня. Наверное, они никогда не составляют блок-схем или схем потоков данных и настаивают на том, что в отличие от нас, простых смертных, они могут все удерживать в своей голове. С другой стороны, многие критики CASE-инструментов действительно пытаются применять определенные методы разумного проектирования и разработки. К сожале-нию, многие CASE-инструменты вместо того, чтобы способствовать процессу методичного решения задач и творческого проектирования, на самом деле препятствуют ему.

Что неправильно в этой картине? Вы видите высокооплачиваемого разработчика программного обеспечения, сидящего в офисе за рабочей станцией стоимостью шесть тысяч долларов и пользующегося CASE-инструмен-том стоимостью двенадцать тысяч долларов, который чертит в своем блокноте и делает заметки на желтых клочках бумаги. В конце концов, после множества исправлений, зачеркиваний и перерисовок он берет мышь и начинает вводить то, что разработал. Таким образом, сложный набор инструментов, установленный на его рабочей станции, превращается в замысловатую электронную доску для черчения.

Вот что здесь неправильно: вместо того чтобы взаимодействовать с разработчиком согласно его представлениям, инструмент работает против него. Вместо того чтобы поддерживать врожденные способности и привычки, укоренившиеся при обучении, CASE-инструмент становится помехой. Для глубокого понимания таких трудностей нам следует рассмотреть, как люди, и в особенности люди инженерного склада ума, решают задачи.

Создание эскизов

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

Что можно сказать о типичных CASE-инструментах? Во многих из них с помощью мыши вы выбираете из набора пиктограмм нужный символ, устанавливаете курсор (опять же с помощью мыши) в том месте внутри создаваемой диаграммы, где вы хотите расположить этот символ, и затем выполняете щелчок мышью, чтобы поместить символ на это место. В этот момент появляется диалоговое окно, в котором запрашивается имя для нового элемента. Это имя должно быть назначено в соответствии с общими и корпоративными стандартами, которые установлены для таких символов. Потом вы должны описать его, назначить для него интерфейсы и, возможно, задать другие параметры. И только после того, как все это выполнено в соответствии с принятыми правилами синтаксиса, вы сможете продолжить составление диаграммы. Однако к этому времени вы, наверное, уже забыли, что собирались делать дальше. Более того, общее представление о содержании и структуре задачи, которое казалось таким ясным, когда вы только протянули руку к мыши, теперь стерлось из вашей ментальной карты благодаря отвлекающим деталям CASE-инструмента.

Альтернативы и альтернативные точки зрения

Все проектирование

основано на компромиссах. Исследование, проведенное более тридцати лет назад, показало, что эффективные инженеры-про-ектировщики обычно сравнивают два или более альтернативных подхода к каждой существенной задаче. В разработке программного обеспечения эта стратегия может применяться так же успешно, как и в сферах деятельности с более богатой историей. (Моя диссертация в Массачусетском технологическом институте была как раз посвящена этому вопросу.) Сравнение альтернативных подходов может происходить быстро и главным образом в уме, или же оно может включать в себя составление сложных описаний и моделирование каждого варианта с тщательным анализом и оценкой всех результатов. В итоге может появиться ясная выигрышная стратегия, но иногда предпочтение отдается творческому синтезу на основе более чем одной альтернативы или компромиссу. Важнейшей частью процесса является взвешивание альтернативных вариантов с помощью прямого сопоставления двух схем или интерпретаций. Большинство современных CASE-инструментов не позволяют оставлять активными и доступными две версии одной системы, диаграммы или модели и уж точно не дают возможности их непосредственного сравнения.

Я видел несколько довольно хитрых способов, предназначенных для преодоления этого ограничения. В одной фирме у системного аналитика были в распоряжении две рабочие станции. На одной из них он вносил изменения и таким образом мог анализировать преимущества и недостатки сразу двух полных версий одной системы. Однако чаще всего альтернативный вариант содержится на бумаге, а другой — в хранилище CASE-инструмента.

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

Даже так называемые «интегрированные» наборы CASE-инструментов обычно не дают возможности просто и быстро переходить от одной модели системы к другой. Такие переходы должны осуществляться одним нажатием клавиши. Еще лучше, если будет предусмотрена возможность наглядного сопоставления. Окна не очень подходят для этого. К тому времени, как вы откроете два окна в CASE-инструменте, работающем в оконном режиме или среде, на экране уже не останется места, чтобы хорошо рассмотреть что-либо. Или будет виден только небольшой кусочек каждой схемы, или на экране будут отображены маленькие, нечитаемые символы и текст. Вряд ли компьютер может помочь [24] в разработке программного обеспечения!

24

Автор с юмором намекает на аббревиатуру CASE (Computer-Aided Software Engineering). «Aid» (англ.) — помощь, поддержка.

Создание и оценивание

Среди самых отъявленных преступников, нарушающих мыслительный процесс разработчиков программного обеспечения, есть некоторые из современных инструментов. К их числу относятся контекстно-зависимые программные редакторы, выполняющие синтаксическую проверку при вводе, или CASE-инструменты, которые поддерживают и навязывают определенную «методологию» разработки. Такая «методология» принуждает пользователя вводить только правильные схемы и описания, причем именно в том порядке, который был определен в «авторитетной» инструкции, написанной гуру в области методологии.

Когда компьютеры только начали применять для обработки текстов, системы проверки орфографии были отдельными программами — настолько медленными и неэффективными, что вы проверяли документ только в случаях крайней необходимости. Зачастую вы просто «забывали» это делать. Однако и компьютеры, и методы поиска стали быстрее. Системы проверки орфографии были интегрированы в текстовые редакторы. Довольно скоро один программист, у которого было свободное время, придумал орфографическую проверку «на лету», выполняемую непосредственно при вводе слов. Как-никак, во время ввода текста процессор большую часть времени все равно ничем не занят, а просмотр слов может вестись побуквенно между нажатиями клавиш. Хорошая идея, правда? Нет, неправда!