Мифический человеко-месяц или как создаются программные системы
Шрифт:
В нише обычных коммерческих приложений значительный вклад сделан языками четвертого поколения (4GL). Бём пишет, что «наиболее удачные из 4GL явились результатом написания какой-либо части области приложений на языке опций и параметров». Наиболее широко распространенными из этих 4GL являются генераторы приложений и комбинированные пакеты баз данных и связи с языками запросов.
Миры операционных систем объединились. В 1975 году было изобили операционных систем — у каждого производителя компьютеров была, по крайней мере, одна патентованная операционная система для каждой производственной серии, а часто и две. Насколько изменилось положение сегодня! Лозунгом дня стали открытые системы, и осталось лишь пять главных операционных сред, для которых создаются пакеты приложений (в хронологическом порядке):
• IBM MVS и VM
• DEC VMS
• Unix в том или ином варианте
• IBM PC,
• Apple Macintosh.
Индустрия коробочных продуктов. Экономические законы для разработчиков в этой отрасли совершенно отличны от тех, которые действуют в классической индустрии: стоимость разработки нужно делить на большое количество экземпляров, расходы на упаковку и маркетинг высоки. В классической индустрии при внутрифирменной разработке график работ и набор функций могли быть изменены, в отличие от стоимости разработки. На открытом рынке жесткой конкуренции сроки и функциональность полностью доминируют над затратами на разработку.
Как и следовало ожидать, столь различные экономические требования породили весьма различающиеся культуры программирования. В классической индустрии лидирующее положение заняли крупные фирмы с установившимися стилями управления и культурой работы. В коробочной индустрии, напротив, возникли сотни начинающих фирм, ничем не связанных и сосредоточенных на конечной цели, а не на процессе. В такой атмосфере талант отдельного программиста всегда ценится значительно выше, и существует подспудное ощущение, что выдающиеся проекты создаются выдающимися архитекторами. Во вновь возникшей культуре есть возможность вознаграждать «звезд» соответственно их вкладу. В классической индустрии социальная политика фирм и их принципы оплаты труда всегда это затрудняли. Неудивительно поэтому, что многие звезды нового поколения были втянуты в орбиту пакетной индустрии.
Покупай и создавай: коробочные продукты в качестве компонентов
Радикально улучшить устойчивость программных продуктов и производительность труда при их создании можно, лишь поднявшись на один уровень и изготавливая программы из модулей или объектов. Особенно многообещающей тенденцией становится использование рыночных пакетов в качестве платформ, на которых создаются более богатые и специализированные продукты. Система управления движением грузовиков создается с помощью коробочной базы данных и коммуникационного пакета, также как и информационная система для студентов. Объявления в журналах предлагают сотни стеков для Hypercard, специализированных шаблонов для Excel, десятки специальных функций на Pascal для MiniCad или функций на AutoLisp для AutoCad.
Метапрограммирование. Стеки для Hypercard, специализированные шаблоны для Excel, функции для MiniCad часто называют метапрограммированием, созданием нового слоя, приспосабливающего функции к нуждам определенной группы пользователей пакета. Идея метапрограммирования не нова, она вернулась и получила свое название. В начале 60-х многие производители компьютеров и вычислительные центры больших информационно-управляющих систем образовывали небольшие группы специалистов, создававших целые языки прикладного программирования с помощью макросов, написанных на ассемблере. В вычислительном центре Eastman Kodak был создан язык прикладного программирования на базе макроассемблера для IBM 7080. Аналогично, в телекоммуникационной программе Queued Telecommunications Access Method для IBM OS/360 можно было на многих страницах кода, написанного предположительно на языке макроассемблера, не найти ни одной команды машинного уровня. Сейчас блоки, создаваемые метапрограммистом, значительно больше, чем тогдашние макроопределения. Такое развитие вторичного рынка очень обнадеживает: пока мы ждали возникновения активного рынка классов C++, незаметно возник рынок метапрограмм многократного использования.
Это действительно наступление на сущность. Поскольку на среднего программиста информационно-управляющих систем феномен разработки на основе пакетов еще не оказал воздействия, он пока не очень замечаем программной инженерией. Тем не менее, это направление будет быстро развиваться, поскольку затрагивает сущность моделирования концептуальных конструкций. Коробочный пакет предоставляет большой функциональный модуль со сложным, но точным интерфейсом, а его внутреннюю концептуальную структуру вовсе не требуется проектировать. Программные продукты с функциями высокого уровня, такие как Excel и 4th dimension, действительно являются большими модулями, но служат понятными, документированными, отлаженными модулями, с помощью которых можно создавать заказные системы. Разработчики приложений следующего
уровня получают богатство функций, сокращение времени разработки, отлаженные компоненты, улучшенную документацию и резко сниженную цену.Сложность, конечно, в том, что коробочные пакеты разработаны как самостоятельные объекты, функции и интерфейсы которых метапрограммисты не могут изменить. Кроме того, более существенно то, что разработчики коробочных пакетов, кажется, не слишком стремятся сделать свои продукты пригодными в качестве модулей более крупных систем. Думаю, что такое понимание неверно, и существует неудовлетворенный рынок для пакетов, способствующих использованию метапрограммирования.
Так что же требуется? Можно выделить четыре уровня пользователей коробочных продуктов:
• Пользователь как таковой, просто использующий приложение и удовлетворенный функциями и интерфейсом, предоставленными разработчиками.
• Метапрограммист, строящий шаблоны и функции поверх отдельного приложения с использованием имеющихся интерфейсов, главным образом, для обеспечения труда конечного пользователя.
• Разработчик внешних функций, вводящий в приложение дополнительные функции. Это, по сути, новые примитивы языка прикладного программирования, обращающиеся к отдельным модулям, написанным на языке общего назначения. Необходима возможность интерфейса этих новых функций с приложением через перехватываемые команды, обратные вызовы или перегружаемые функции.
• Метапрограммист, использующий одно и, в особенности, несколько приложений в качестве компонентов более крупной системы. Это пользователь, чьи нужды сегодня слабо удовлетворяются. Это тот вид использования, который обещает наибольший рост производительности при создании новых приложений.
Для этого последнего типа пользователей коробочный продукт должен иметь дополнительный документированный интерфейс — интерфейс
метапрограммирования. Он должен предоставлять несколько возможностей. Прежде всего, метапрограмма должна управлять ансамблем приложений, несмотря на то, что каждое приложение, как правило, считает, что управляет самим собой. Этот ансамбль должен управлять интерфейсом пользователя, хотя обычно само приложение считает, что делает это. Ансамбль должен быть в состоянии вызвать любую функцию приложения, как если бы его командная строка исходила от пользователя. Выходные данных приложения должны передаваться ему, а не на экран, причем в виде логических блоков подходящих типов данных, а не текстовой строки, которую нужно отобразить. В некоторых приложениях, например, FoxPro, есть дырочки, позволяющие передать командную строку, но возвращаются скудные и неразобранные данные. Такая дырочка — заплатка на скорую руку, в то время как требуется общее проработанное решение.
Большие возможности дало бы наличие языка сценариев для управления взаимодействием приложений, входящих в ансамбль. Такого рода функции впервые предоставила Unix с помощью каналов и стандарта файлов в формате ASCII-строк. Сегодня неплохим решением является AppleScript.
Состояние и будущее программной инженерии
Однажды я попросил Джима Феррелла (Jim Ferrell), председателя химико-технологического факультета университета штата Северная Каролина поведать о
развитии химических технологий вне связи с химией, на что он экспромтом выдал мне замечательный рассказ, продолжавшийся час, начиная с существовавших с античных времен различных производственных процессов для многих продуктов — от стали до хлеба и парфюмерных изделий. Он рассказал, как профессор Артур Д. Литтл (Arthur D. Little) в 1918 году основал в МТИ факультет прикладной химии для исследования, разработки и обучения общим фундаментальным технологиям всех процессов. Сначала были практические правила, затем эмпирические номограммы, затем рецепты проектирования отдельных компонентов, затем математические модели распространения тепла, масс, количества движения в отдельных емкостях.
По ходу рассказа Феррелла я поразился обилию параллелей между разработкой химических технологий и развитием программных технологий, происходившим почти полвека спустя. Парнас утверждает, что я вообще пишу о «программной инженерии». Он противопоставляет программотехнику как науку электротехнику и считает, что называть наше занятие инженерией самонадеянно. Возможно, он прав в том, что эта область никогда не станет инженерной дисциплиной с такой точной и всеохватывающей основой, какая есть у электротехники. В конце концов, программная инженерия, подобно химической технологии, занята нелинейными задачами увеличения масштабов до промышленных процессов и, подобно организации промышленного производства, постоянно ставится в тупик сложностями человеческого поведения.