«Хороший инструмент для разработки — это тот инструмент, который не замедляет мою работу». Программист осторожно посмотрел на коробку весом почти 40 кг, в которой находилась новейшая и лучшая среда разработки на С++. «Мне нужен такой инструмент, который даст мне возможность программировать так, как я хочу. После этого на основе кода такой инструмент должен составить эти дурацкие схемы, которые требует от меня начальник». Думаю, что сейчас, наверное, самое время поговорить об этих дурацких схемах.

Многие разработчики — особенно те, которые ломают головы над созданием микрокомпьютеров и рабочих станций, — имеют очень смутное представление о структурных схемах, диаграммах объектных коммуникаций, схемах информационных потоков и блок-схемах. Довольно многие из них никогда не рисовали функциональных иерархий и растерялись бы, обнаружив такие схемы на своем столе. Увидев Booch-грамму, они подумали бы, что это какая-нибудь плохая новость, доставленная на желтой бумаге курьером из компании Booch Telecommunications.

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

коренной объектно-ориентированной разработке программ на основе создания прототипов. Схемы и диаграммы не находят своего места в быстро меняющемся мире скороспелых микроприложений, разрабатываемых с помощью методов визуального программирования и быстрого создания приложений. «У нас нет времени на рисование картинок. Нас поджимают жесткие сроки выпуска новой версии!» «Зачем вообще рисовать схемы, если можно просто писать код?» Это хороший вопрос. Для чего нужны эти рисунки?

Конечно, структурные схемы и другие классические модели проектирования и анализа были разработаны не для того, чтобы замедлить процесс программирования, так же, как они не были созданы для того, чтобы удовлетворить нужды суетливых потребителей или осчастливить во все вмешивающихся руководителей. Большинство этих методов разработчики придумали для собственных нужд — чтобы упростить и ускорить свою работу. Время, затраченное на обдумывание программ с помощью моделей, — это время, которое экономится при программировании и отладке. Модели проектирования и анализа сокращают время разработки, так как позволяют моделировать программы без необходимости их кодирования и облегчают принятие замысловатых решений для сложных задач. Все это хорошо известно. Хороший план сокращает время разработки; хорошие модели проектирования упрощают планирование.

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

Разработчики программного обеспечения рисуют картинки перед созданием самих программ по тем же причинам, что и архитекторы, рисующие поэтажные планы и вертикальные профили перед тем, как приступить к строительству дома. Тем не менее здания не всегда строились с помощью планов и рисунков. Если схема здания достаточно проста и знакома, строители могут работать без помощи моделей, ведя проектирование в процессе строительства. Сельским общинам на рубеже веков не требовались чертежи, чтобы построить сарай. В те времена сараи имели простую конструкцию, а в их строительстве применялись несложные методы. Каждый знал, как выглядит сарай, как он строится и что для этого требуется. Большинство членов общины уже занималось этим, а новички могли научиться, внимательно наблюдая за тем, что делают другие, и делая то же самое. Но если перейти от хижин и сараев к домам в колониальном стиле с четырьмя спальнями или высотным квартирным комплексам, то все становится сложнее.

То же самое можно сказать и о компьютерных программах. В те времена, когда 64 Кбайт оперативной памяти было пределом, а в качестве операционной среды использовалась СР/М, было вполне возможно и разумно удерживать всю программу в своей голове. Но тот, кто говорит, будто сможет запомнить все детали в сотнях тысяч строк программы на С, говорит неправду — если не вам, то себе. Именно здесь возникает необходимость в моделях проектирования.

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

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

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

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

Хорошие инструменты моделирования также позволяют делать своего рода эскизы, которые трудно выполнить в коде. Языки программирования точны и детальны, а компиляторы упрямо требуют наличия точного синтаксиса и законченных конструкций. Чистая доска не имеет таких ограничений. Разработчик или вся группа могут подойти к ней и «поиграть» с картинками. Они могут передвигать элементы по схеме, отслеживая сложные взаимосвязи между распределенными областями системы. Словом, модели проектирования позволяют разработчикам программного обеспечения действовать подобно настоящим инженерам, проверяя и сравнивая альтернативные варианты организации программ без необходимости переложения идей в код.

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

Как же отличить хорошую модель от плохой, а плохую от безобразной? Оставайтесь с нами.

Из журнала Software Development, том 2, № 2, февраль 1994 г.