Представьте, у вас онлайн-магазин и вы поняли что надо в сжатые сроки внести серьёзные изменения. Программисты говорят, правки займут несколько месяцев, но они ещё посмотрят. Назначается встреча, туда зовут всех, не только разработчиков с аналитиками, но также рабочий персонал и пользователей. Структура программы отображается на стене, и дизайнеры системы, собравшись в группу, начинают её исследовать. Внезапно выясняется, что нужно всего-то набросать пару новых компонентов, да переподключить чуть иначе парочку старых. Новый прогноз на выполнение задачи - неделя!
FBP не было популярно, вероятно, из-за сдвига парадигмы, что требует от мышления, но сейчас для него самое время. Оно даёт последовательный взгляд на приложение от орлиного взора, вглубь, до реализации низкоуровневых модулей. Но требует писать приложение как переиспользуемые "чёрные ящики". Это заставляет программистов фокусироваться на данных и их трансформациях. Это быстрое прототипирование и надёжный результат. Это совместимость с распределёнными системами и пересечение с ООП.
Слишком хорошо, чтобы быть правдой? Судите сами! Что будет описано далее, я считаю настоящей революцией в создании программ и в поддержке требований к обработке данных от компаний по всему миру.
Большинство приложений написано на т.н. "языках уровнем повыше" (Higher level languages). Есть также языки "пятого поколения", ещё более высокоуровневые, чем HHL, но более специализированные. Несмотря на богатство инструментария, программист сегодня должен преобразовать свои элегантные идеи в строки команд на конкретном языке. Генераторы имели определённый успех, но не решили проблему - большинство программ до сих пор пишутся вручную. Программисты до сих пор будто мастера-мебельщики, вручную выстругивающие стулья из красного дерева.
И пару слов о т.н. "процедурных" или "организационных" подходы к улучшению процесса разработки вроде "structured walk-throughs", "the buddy system", "chief programmer teams", "third-party testing". Они все хороши и будут давать результат независимо от парадигмы.
Без разработчиков приложений бизнес во всём мире встанет. Эти люди практикуют ремесло, которого большинство не понимает. Архитипичный программист это одарённый, но непрактичный индивид который лучше сходится с машинами, чем с людьми. На самом деле, конечно, программист это интерфейс между его клиентами, говорящими на языке бизнеса, и их системами, говорящими на языке электронов. И чем эффективнее программист может заполнить пропасть между этими мирами, тем лучше будет приложение, что он пишет. Однако, всё это требует от него множества навыков.
Проблемы современного инструментария программирования рождаются чуть ли не полностью от несоответствия между областью проблемы, в которой программист работает и тулчейном, которым он или она вынужден пользоваться. Лишь сократив пропасть между миром пользователей и разработчиков, мы сможем поставлять приложения удовлетворяющие всем нуждам и делать это эффективно с точки зрения финансов время-затрат.
Важная вещь о разработке приложений, что я понял за последние 20 лет - сам процесс толком не изменился. Дело тут, конечно, не в недостатке адептов какого-то нового блестящего инструмента. Тем не менее, очень немногие из этих инструментов дали то, что обещали. Когда я начал свою карьеру в 1959 году, у нас уже были высокоуровневые языки, интерпретаторы и вызовы подпрограмм - это все еще основные инструменты современных профессионалов в области программирования. Тип программирования, которым занимается большинство из нас, уходит корнями в процедурное программирование, возникшее в 40-50-х годах. Тогда новое изобретение, называемое компьютером, удовлетворило растущую потребность в повторяющихся математических вычислениях, таких как таблицы приливов и отливов, баллистические расчеты и расчеты переписи. В этих областях компьютеры пользовались огромным успехом.
Однако даже тогда некоторые эксперты в этом новом мире вычислений начали сомневаться, действительно ли процедурное программирование приложений подходит для создания бизнес-приложений. Комбинация все более и более сложных систем, явная сложность работы программистов среднего уровня и необходимость сокращения накладных расходов предприятиями приводит к все большему давлению на сегодняшних профессионалов в области программирования.
Кроме того, по мере того, как программисты создают новые системы, растёт количество ресурсов, расходуемых на их поддержку, до такой степени, что на способность многих компаний разрабатывать новые приложения серьезно влияет бремя поддержки старых. Это, в свою очередь, отрицательно сказывается на их способности конкурировать на новом конкурентном глобальном рынке.
Часто упоминается технический долг - невыполненные задачи по программированию, которые планируется выполнить, но которые нельзя взять в работу из-за нехватки ресурсов. Я также слышал, как люди используют фразу "скрытый техдолг" - это работа, которую пользователи хотели бы видеть, но всем ясно, что нет смысла даже говорить о ней, поэтому она, как правило, не отображается в статистике! Я думаю, это, по крайней мере, частично, причина, почему отделы, не связанные с вычислениями, в последние годы скупают ПК - они думают, что наличие собственных компьютеров сделает их независимыми, но, конечно, они просто столкнутся с теми же старыми проблемами. На собственных машинах!
Когда-то предсказывалось, что потребуется больше операторов телефонных коммутаторов, чем доступных молодых дамочек. Эта проблема была решена разработкой систем автоматической телефонной коммутации. Точно так же многие теперь думают, что нынешнюю ситуацию в вычислительной технике можно решить только с помощью квантового скачка в технологиях, и, конечно же, каждая новая программная технология претендует на то, чтобы стать долгожданным решением. Я и ряд других людей полагаем, что концепции, описанные ниже, и есть решение, и я надеюсь, что, читая эту книгу, вы согласитесь с нами. Однако они представляют собой настоящую смену парадигмы, которая коренным образом меняет то, как мы смотрим на процесс программирования. Как и многие важные открытия, эта новая парадигма в основном довольно проста, но имеет далеко идущие последствия.
Упоминание о новой парадигме заставляет сразу же подумать о другой новой парадигме, популярность которой неуклонно растет, а именно об объектно-ориентированном программировании (обычно сокращенно ООП). То, что я собираюсь описать, не является ООП, но имеет определенное сходство с ним, и особенно с более продвинутыми концепциями ООП, в частности с концепцией "активных объектов". В конечном итоге эти две парадигмы, похоже, находятся на сходящемся пути, и, как я опишу в более поздней главе, я считаю, что вполне возможно объединить два набора концепций для достижения лучшего из обоих миров. Однако, в большей части этой книги я буду представлять наши концепции и опыт по мере их исторической эволюции, используя нашу собственную терминологию.
Проработав несколько лет в компьютерном бизнесе, я обнаружил, что не понимаю, почему программирование приложений должно быть таким сложным. Его сложность, конечно же, не является сложностью самих алгоритмов или логики. С арифметической точки зрения в бизнес-программировании редко можно встретить умножение или деление, не говоря уже о чем-то столь же загадочном, как квадратный корень.
Я и ряд других специалистов в этой области пришли к выводу, что основная причина проблемы - это, на самом деле, то же самое, что привело к самой компьютерной революции, а именно компьютерная модель фон Неймана.
Эта традиционная модель, которая была очень продуктивной в течение последних нескольких десятилетий, разработана на основе единого счетчика инструкций, который последовательно проходит через строки кодов, решая, что делать на каждом этапе. Эти коды могут обрабатываться как данные (например, компиляторами), так и как команды. Эта конструкция обычно, но не обязательно, сочетается с однородным массивом ячеек памяти, из которых инструкции берут данные и в которые они их возвращают. Как описано в недавней статье Valiant (1990), сила этой модели проистекает из того факта, что она действует как мост между двумя "разнообразными и хаотическими" мирами (как их называет Valiant) аппаратного и программного обеспечения, позволяя они должны развиваться отдельно. Но, по той же причине, успех этой модели убедил практиков, что сложности, с которыми мы сталкиваемся, не могут быть вызваны какими-либо фундаментальными проблемами с этим набором концепций.
Программисты недостаточно умны, у них недостаточно хороших инструментов, у них недостаточно математического образования или они недостаточно много работают - уверен, и вы столкнулись со всем этим. Я не верю, что хоть что-то из этого правда - существует гораздо более фундаментальная проблема, а именно, что на базовом уровне среда просто не подходит для поставленной задачи. Представьте на секунду, как построить из глины автомобиль! Он очень пластичен во влажном состоянии, вы сможете сделать что угодно, но после обжига он очень твердый, но очень хрупкий! Именно так "ощущается" большинство наших приложений сегодня!
Настало время для новой парадигмы, что заменит модель фон Неймана в качестве моста между аппаратным и программным обеспечением. Та, что мы будем описывать, похожа предлагаемую Valiant (я расскажу о нем подробно в главе 27), и на самом деле кажется одной из семейства связанных концепций, появившихся за последние несколько лет. Общая концепция, лежащая в основе большей части этой работы, состоит в том, что для решения этих проблем мы должны перестать беспокоится о порядке исполнения инструкций, как мы делаем это при Фон-Неймановском программировании и начать и структурировать программы как совокупности взаимодействующих асинхронных процессов. Если вы посмотрите на приложения, большие, чем одна программа, или загляните внутрь машины, вы обнаружите, что многие процессы идут параллельно. Только в рамках одной программы (шага задачи или транзакции) вы по-прежнему обнаруживаете строгую традиционную последовательную логику. Мы думали, жесткий контроль последовательности выполнения - единственный способ получить предсказуемый код и, следовательно, он необходим для надежных систем. Оказывается, машины (и люди) работают эффективнее, если оставить лишь те ограничения, которые имеют значение, и убрать остальные, и вы можете сделать это без потери надежности. Цель этой книги - попытаться описать совокупность опыта, накопленного с использованием определенного набора реализаций этой концепции на протяжении многих лет, поэтому я не буду вдаваться в подробности на данном этапе. В этой главе мы будем больше говорить об истории этой концепции, чем о конкретных реализациях или опыте, полученном при их использовании.
Еще один фактор, который заставляет меня думать, что об этой технологии пора обнародовать, - мы сталкиваемся с растущим кризисом в разработке приложений.
Одновременно с появлением новых требований технологии меняется все быстрее. Набор концепций, что я буду описывать, кажется, хорошо согласуется с текущими направлениями как для программного, так и для аппаратного обеспечения. Он не только может естественным образом поддерживать требования распределенных, гетерогенных приложений, но также кажется подходящей технологией для новых многопроцессорных машин, над которыми работают университеты и ведущие производители компьютеров по всему миру. Как покойный Уэйн Стивенс, известный писатель о методологиях разработки приложений, отмечал в нескольких своих статьях (например, Stevens 1985), парадигма, которую мы будем описывать, обеспечивает последовательный, естественный взгляд на приложения с точки зрения их работы. Поскольку вы можете описывать ручные приложения с помощью диаграмм потоков данных, связь между ручными и системными процедурами может быть легко показана.
В дальнейшем я буду использовать термин "Flow-Based programming" (или сокращенно FBP) для описания этого нового набора концепций и программного обеспечения, необходимого для его поддержки. В прошлом мы использовали термин "data-flow", поскольку он передает ряд наиболее важных аспектов этой технологии, но существует значительный объем опубликованных работ по так называемым data-flow архитектурам в компьютерном дизайне и связанном с ними программном обеспечении. (Например, очень интересная работа из MIT), поэтому термин "data-flow" может вызвать путаницу в некоторых академических кругах. Несколько лет назад мне также указали, что, когда поток управления требуется явно, FBP может предоставить его с триггеров, поэтому термин "Потоко-Ориентированное программирование" избегает коннотации, что мы не можем управлять потоком исполнения. Это не значит, что у FBP и data-flow мало общего - компьютерные архитектуры потоков данных возникают из того же понимания, что конструкция машины фон Неймана, столь успешная в прошлом, должна быть обобщена, если мы хотим двигаться дальше.
Одно существенное различие между двумя школами, по крайней мере, сейчас, заключается в том, что большая часть других работ с потоками данных была математически ориентирована, поэтому она имеет тенденцию работать с числами и массивами чисел. Хотя моя ранняя работа с потоками данных в конце 60-х годов также включала простые числовые значения, текущих через сеть функциональных блоков, мой опыт работы с системами моделирования привел меня к осознанию того, что в бизнес-приложениях было бы более продуктивно иметь структурированные потоки данных. Объекты, которые я назвал "сущностями". Это название отражало, что эти структурированные объекты имеют тенденцию представлять сущности во внешнем мире. (В нашей более поздней работе мы поняли, что имя "сущность" (entity) может вызвать путаницу с сущностями в моделировании данных, хотя есть точки сходства, поэтому мы решили использовать другое слово. Такая система - естественный способ для моделирования приложений и различие между моделированием и реализацией становится гораздо менее значительным, чем в традиционном программировании. Вы можете думать о "сущности" как о записи в хранилище, но как записи активной (в том смысле, что она запускает события), а не как о пассивной (просто читается или записывается). Сущности проходят через сеть процессов, например автомобили в городе или лодки в речной системе. Они отличаются от математических токенов компьютеров с потоком данных или моих ранних работ главным образом тем, что они имеют структуру: каждая сущность представляет собой объект с атрибутами, например, у сотрудника будут такие атрибуты, как зарплата, дата найма, менеджер и т.д. Как вы читаете В этой книге должно стать ясно, почему должен быть хотя бы один уровень приложения, на котором объекты перемещаются как отдельные единицы, хотя вполне может быть возможно интегрировать различные подходы к потокам данных на более низких уровнях.
На данном этапе я собираюсь кратко описать FBP, чтобы дать читателю какую-то картину, но сперва сделаю оговорку: краткого описания, которое следует ниже, вероятно, будет недостаточно, чтобы вы могли представить себе, что такое FBP и как оно это делает. Однако, если мы не сделаем этого сейчас, опыт показывает, вам трудно будет соотнести, что я описываю здесь, со своими собственными знаниями. Иначе вы можете поспешить с выводами, которые могут помешать вам увидеть, что действительно нового в концепциях, которые я буду описывать позже. Я называю это синдромом "А, да это же всего лишь...".
При общепринятом программировании, когда вы садитесь писать программу, вы пишете код на странице - операции строчка за строчкой, серию действий, чтобы компьютер их выполнял. Поскольку сейчас мы, конечно, все пишем структурированный код, мы начинаем с основной строки, содержащей в основном вызовы подпрограмм, которым впоследствии можно придать "значение", реализовав их. Некоторые люди размышляли о возможности вместо этого построить программу, просто соединяя вместе заранее написанные части логики. Иногда это называют программированием "Legoland". Несмотря на то, что, по сути, это то, что мы делаем, когда используем утилиты, всегда были некоторые сомнения в том, может ли этот подход создавать крупномасштабные приложения, и, если да, то будут ли такие приложения работать. Теперь я с удовольствием объявляю, что на оба эти вопроса ответ утвердительный!
"Клей", который FBP использует для соединения частей, это пример того, что Йельский Гелернтер и Карриеро (1992) назвали "координационным языком". Я считаю, что различие между языками координации и процедурными языками полезно и помогает прояснить, чем отличается FBP. Привычные языки программирования указывают машине, какую логику выполнять; языки координации сообщают машине, как координировать несколько модулей, написанных на одном или нескольких языках программирования. Существует довольно много опубликованных материалов о различных подходах к координации, но большая часть этой работы связана с использованием языков специального назначения, что снижает применимость этих концепций к традиционным языкам и средам. Наряду с Гелернтером и Карриеро я считаю, что лучший подход - иметь независимую от языка нотацию координации, которая может координировать модули, написанные на множестве различных языков. Отдельные модули должны иметь общий интерфейс, чтоб могли взаимодействовать с программным обеспечением для координации, но это не слишком сложно.
Координация и модульность - две стороны одной медали, и несколько лет назад Нейт Эдвардс из IBM ввел термин "настраиваемая модульность" для обозначения способности повторно использовать независимые компоненты, просто изменяя их взаимосвязь, что, по его мнению, характеризует все успешные системы. И хоть я не уверен, когда именно Нейт впервые объединил эти два слова - "конфигурируемый" и "модульность", в отчете о планировании в Пало-Альто в 1976 году используется этот термин, а также статье Нейта 1977 года (Эдвардс, 1977). Работа Нейта Эдвардса довольно нетехническая и прагматичная, а его опыт в, основном, связан с железом, а не софтом, что может быть причиной, почему его работа не получила внимания, которого она заслужила. Одна из важных характеристик настраиваемой модульности - вы можете создавать системы из многоразовых "черных ящиков", подобно микрочипам. Вы также, конечно, должны иметь что-то, чтобы связать их вместе, но их не нужно каким-либо образом изменять, чтобы это произошло. Конечно, это характерно почти для всех вещей, которые мы привязываем друг к другу в реальной жизни - фактически, почти везде, кроме привычного программирования. В FBP эти черные ящики - основные строительные блоки и разработчик использует их для создания приложения. Новые черные ящики могут быть написаны по мере необходимости, разработчик пытается сначала использовать то, что доступно. В FBP акцент смещается с создания всего нового на соединение уже существующего, а новое создаётся только если это экономически оправданно. Нейт Эдвардс сыграл ключевую роль в том, чтобы люди, занимающиеся аппаратным обеспечением, следовали этому принципу - и теперь, конечно, как и все великие открытия, кажется, что мы всегда это знали! Мы должны помочь разработчикам софта пройти через ту же смену парадигмы. Если вы посмотрите на литературу по программированию с этой точки зрения, то удивитесь, как мало авторов пишут об основах повторного использования - на самом деле, сам термин, кажется, предполагает элемент неожиданности, как если бы повторное использование было случайным явлением!
Мы будем описывать сходство между FBP и другими подобными системами в следующих главах, но, возможно, на этом этапе было бы полезно использовать каналы DOS для проведения простой аналогии. Если вы использовали DOS, вы знаете, что можете брать отдельные программы и объединять их с помощью вертикальной черты |, например: A | B (прим. пер. - аналогично UNIX pipe).
Это очень простая форма того, что я назвал координацией отдельных программ. Она сообщает системе, что мы хотитим передать выход A на вход B, но ни A, ни B не должны быть изменены, чтобы это произошло. A и B должны иметь точки подключения ("вилки" и "розетки"), которые система может использовать, и, конечно же, должно быть какое-то программное обеспечение, которое понимает обозначение вертикальной черты и знает, что с ней делать. FBP расширяет эту концепцию по ряду направлений, что значительно увеличивает ее силу. Оказывается, это обобщение приводит к совершенно иному подходу к созданию приложений, в результате чего системы становятся более надежными и удобными в обслуживании. На следующих страницах я надеюсь, что смогу доказать это!
Все FBP-системы, созданные за последние 20 лет, в основном состояли из следующих компонентов:
- Ряд предварительно закодированных, предварительно протестированных функций, представленных в форме объектного кода, а не в форме исходного кода ("черные ящики") - этот набор является открытым и (будем надеяться) постоянно пополняется
- "Драйвер" - ПО, координирующее различные независимые модули и реализующее API, который используется компонентами для связи друг с другом и с драйвером.
- Нотация того, как компоненты соединяются вместе в одну или несколько сетей (разработчик приложения FBP начинает с изображений, а затем преобразует их в спецификации, которые будут выполняться драйвером)
- Это обозначение может быть помещено в файл для выполнения программным обеспечением драйвера. В наиболее успешной до сих пор реализации FBP (DFDM - описывается в следующем разделе этой главы) сеть может быть либо скомпилирована и отредактирована ссылка для создания исполняемой программы, либо ее можно интерпретировать напрямую (с, конечно, большими накладными расходами на инициализацию). В режиме интерпретации компоненты загружаются динамически, поэтому вы можете вносить изменения и просматривать результаты много раз за несколько минут. Люди находят этот режим чрезвычайно продуктивным. Позже, когда отладка будет завершена, вы можете преобразовать интерпретируемую форму в компилируемую форму, чтобы обеспечить лучшую производительность.
- Процедуры, позволяющие конвертировать, компилировать и упаковывать отдельные модули и сети
- Документация (справочная и учебная) по всему вышеперечисленному
В приведенный выше список я не включил образование - но, это, конечно, самый важный пункт из всех. Чтобы начать работу, необходимо формальное образование - оно может занять всего несколько дней или недель, и я надеюсь, эта книга поможет понять многие из основных концепций. Однако образование также включает в себя практику в течение нескольких месяцев или лет. И в этом смысле FBP сильно отличается от привычного программирования. В отличие от большинства других профессий, в программировании мы склонны недооценивать опыт, что на самом деле может быть связано с природой современной среды программирования. В других профессиях мы не рекомендуем давать новичку стопку книг, затем сделать операцию на головном мозге, построить мост, добыть золото и переплыть Атлантику. Вместо этого ожидается, что будет ряд последовательных шагов от ученика до мастера. Разработка приложений с использованием FBP больше похожа на инженерную дисциплину: мы собираем структуры из уже существующих компонентов с четко определенными спецификациями, а не строим вещи с нуля, используя базовое сырье. В такой среде ключевым моментом является опыт: требуется время, чтобы узнать, какие компоненты доступны, как они сочетаются друг с другом и какие компромиссы могут быть достигнуты. Однако, в отличие от строителей мостов, FBP-программисты могут очень быстро видеть плоды своей работы и получить видя, как простые программы делают нетривиальные вещи. Обучение FBP - это практика, и очень приятно видеть реакцию людей, когда они добиваются, чтоб что-то работало, не написав ни строчки кода!
Теперь, когда графическое оборудование и софт стали доступны по разумной цене, очень хочется иметь GUI для наших FBP-систем. FBP - очень наглядное по своей природе и графический интерфейс сделает его еще более удобным. Некоторые прототипы уже были выполнены в этом направлении и, кажется, подтверждают эту идею. Многие потенциальные пользователи FBP уже будут иметь один или несколько инструментов графического дизайна, и, как мы увидим, существует сильная связь между структурным анализом и FBP, так что представляется возможным и желательным использовать графические интерфейсы FBP для проведения структурного анализа.
Немного истории: первая реализация FBP была создана мной в 1969-1970 годах в Монреале, Квебек. Вышло неплохо - настолько, что её взяли в крупную канадскую компанию, где использовали для крупной онлайн-системы. Система получила название "Advanced Modular Processing System "(AMPS). Она сама и опыт, полученный с ее помощью, довольно подробно описаны в статье, которую я написал несколько лет спустя для IBM Systems Journal (Morrison 1978). Это была первая статья, опубликованная в "Системном журнале" автором из региона, который тогда назывался "Дальним Востоком IBM" (включая Канаду, Южную Америку и Дальний Восток).
Хотя эти концепции малоизвестны, на самом деле они уже много лет являются общественным достоянием. Произошло это следующим образом: в конце 1970-х или начале 71-го я обратился в отдел интеллектуальной собственности IBM Canada, чтобы узнать, можем ли мы получить патент на основную идею. Их рекомендация, которая, как мне кажется, была пророческой, заключалась в том, что эта концепция больше похожа на закон природы и не подлежит патентованию. Однако, они рекомендовали мне написать Бюллетень технического раскрытия информации (TDB), который был должным образом опубликован и распространен среди патентных ведомств по всему миру (Morrison, 1971). TDB - это своего рода обратный патент: в то время как патент защищает владельца, но требует, чтобы он или она попытались предсказать все возможные варианты концепции, TDB помещает концепцию в общественное достояние.
К концу 80-х мы с Уэйном Стивенсом совместно разработали новую версию этого программного обеспечения, получившую название "Data Flow Development Manager" (DFDM). Это описано в Приложении А к последней книге Уэйна Стивенса (Stevens 1991) (которое, кстати, содержит много хороших материалов по методам разработки приложений в целом). То, что я обычно называю "процессами", в DFDM называли "сопрограммами" после Конвея (1963), который описал раннюю форму этой концепции в статье 60-х годов и даже тогда предвидел некоторые из ее потенциальных возможностей. "Сопрограмма" образована от слова "подпрограмма" вместе с латинским префиксом, означающим "с", в противовес с "подпрограмма", которая образована с префиксом, означающим "под". (Это разница "кооперативного" с "подчинённым").
DFDM использовался для ряда проектов (от 40 до 50) различного масштаба в IBM Canada. Несколько лет спустя Кенджи Терао начал проект в IBM Japan, чтобы поддержать нас в разработке улучшенной версии для японского рынка. Эта версия на момент написания является единственным диалектом FBP, который был доступен на рынке, и я считаю, что огромная заслуга принадлежит Кенджи и всем преданным и дальновидным людям в IBM Japan, которые помогли сделать это возможным. Хотя эта версия DFDM была во многих отношениях более надежной или "промышленной", чем та, которую мы использовали в IBM Canada, большая часть опыта, который я буду описывать на следующих страницах, основана на том, что мы узнали, используя внутреннюю версия DFDM в IBM-Канада или с ещё более ранней системой AMPS. Кто знает, возможно, однажды напишут сиквел этой книги, описывающий опыт Японии с DFDM.
Последнее, но важное - существует система для ПК, написанная на C, которая пытается воплотить многие из лучших идей своих предков. Она доступна с лета 1993 и работает на машинах на базе Intel. Она был протестирована на машинах на базе 268, 386 и 486. Поскольку она написана на C, мы надеемся, что позже её можно будет перенести на другие версии C, хотя есть небольшой объем кода, зависящего от среды, который придется изменять вручную. Это программное обеспечение называется THREADS - система разработки приложений на основе THREads (люблю рекурсивные акронимы!). Как и DFDM, она тоже имеет интерпретируемые и скомпилированные версии, поэтому приложения можно разрабатывать итеративно, а затем компилировать для создания одного файла ".exe".
Терминология, используемая в этой книге, отличается от терминологии, используемой в AMPS и DFDM, поскольку некоторые из этих терминов, как оказалось, вызывают путаницу. Например, чанки данных, что перемещаются между асинхронными процессами, назывались "сущностями" в AMPS и DFDM, но, как я уже сказал, это вызывало путаницу у людей с опытом моделирования данных. "Объекты" создавали бы другие проблемы, и нам не нравилась идея создания совершенно новых слов (хотя некоторые авторы использовали их эффективно). "Кортежи" из "Линды" Каррьеро и Гелернтера (1989) очень близки, но это название также представляет собой несколько иной образ. Поэтому мы решили использовать довольно нейтральный термин "информационный пакет" (или для краткости "IP") для этой концепции (прим. пер. - что вызывает путаницу с IP). Этот термин был придуман во время работы над DFDM, в которой мы также связали концепции FBP с другими работами, появляющимися в литературе или разрабатываемыми в других частях IBM. Некоторые из расширений базовой подструктуры AMPS и DFDM, о которых я расскажу позже, также были сформулированы в этот период. Когда мне нужно сослаться на идеи, почерпнутые из этой работы, я буду использовать имя FPE (от Flow-Based Programming Environment), хотя это не аббревиатура, используемая в этом проекте. THREADS следует этой пересмотренной терминологии и включает ряд идей FPE.
Как я сказал в прологе, большую часть из 33 лет моей работы в IT я почти исключительно занимался бизнес-приложениями. Хотя бизнес-приложения часто бывают более сложными, чем научные, академическое сообщество до сих пор не проявляло особого интереса к этой области. Это "уловка 22", поскольку бизнес выиграет от работы, проделанной в академических кругах, однако академические круги (за некоторыми примечательными исключениями) склонны не рассматривать бизнес-программирование как интересную область для работы. Я надеюсь, что FBP сможет действовать как мост между этими двумя мирами, и в следующих главах попытаюсь связать FBP с другой связанной теоретической работой, с которой работающие программисты, вероятно, обычно не сталкиваются. Мои чтения в этой области предполагают, что FBP имеет прочную теоретическую основу. Оно доступно стажёрам (иногда проще, чем опытным!). AMPS используется в течение 20 лет, поддерживая одну из крупнейших компаний в Северной Америке, и совсем недавно, в этом году (1992), один из их старших сотрудников сказал мне: "AMPS сослужила нам хорошую службу, и мы ожидаем, что она будет продолжать". Бизнес-системы должны развиваться с течением времени по мере изменения требований рынка, поэтому очевидно, что их система могла расти и адаптироваться с годами по мере возникновения необходимости - это живая система, а не какое-то устаревшее любопытство, которое устарело с развитием технология.
А теперь я хотел бы завершить эту главу добровольным отзывом от пользователя DFDM, что мы получили несколько лет назад:
"Мне надо было объединить 23 отчета в один. Поскольку все отчеты разной длины и размера, это сложнее в обычной среде PLI (прим.пер. - ЯП разработанный в 1964 в IBM). Для написания программы потребовался бы 1 день работы и 1 день для тестирования. Такая программа будет содержала бы повторяющийся код. Однажды утром, когда я пил кофе, я написал для этого DFDM-сеть. Она была завершена до того, как кофе остыл. Во время тестирования была обнаружена небольшая ошибка, исправление которой заняло 10 минут. Поскольку использовались 3 стандартные сопрограммы, PLI не требовался. 2 сопрограммы были использованы единожды, и ещё 1 - 23 раза. Если бы не DFDM, я бы сказал пользователю, что его требование не оправдано с точки зрения затрат. Написание этого примечания заняло больше времени, чем сеть DFDM".
Обратите внимание, что в своей заметке Редж (сокращенно от Réjean), который, кстати, является разработчиком с нарушением зрения, с многолетним опытом работы с бизнес-приложениями, упомянул все моменты, которые были важны для него как разработчика - он указал на повторное использование, что он получил, потому что функции, которые он брал прямо с полки, были теми, которые ему не нужно было писать, тестировать и, в конечном итоге, поддерживать! В DFDM "сопрограммы" являются основными строительными блоками, которые программисты могут соединять вместе для создания приложений. Они либо уже доступны ("на полке"), либо программист может написать новые, и в этом случае он или она, естественно, попытается повторно использовать их как можно чаще - чтобы получить максимальную отдачу от вложенных денег. Хотя писать новые сопрограммы PL/I не так уж сложно, большинство разработчиков приложений не хотят писать новый код - они просто хотят, чтобы их приложения работали на клиента, желательно с минимальными усилиями, достаточными чтоб качественно выполнить работу. Конечно, всегда есть программисты, которым нравится процесс программирования, и, как мы увидим на следующих страницах, они также играют важную роль в этом новом развивающемся мире.
Нам особенно понравилась записка Реджа, ибо он использует специальное оборудование, которое преобразует все, что отображается на его экране, в произносимые слова. Поскольку FBP всегда казался мне очень визуальной техникой, я беспокоился, будут ли у программистов с ослабленным зрением какие-либо проблемы с ним, и было очень обнадеживающим обнаруженить, что Редж смог столь продуктивно использовать эту технологию. В более поздних обсуждениях с ним он подчеркнул необходимость сохранения простой структуры приложений. В FBP вы можете использовать иерархическую декомпозицию для создания нескольких слоев, каждый из которых содержит простую структуру, вместо того, чтобы создавать единую плоскую очень сложную структуру. На самом деле, конструкции, которые настолько сложны, что у него были бы проблемы с ними, трудны для всех. Он также указывает, что инструменты, которые он сочтет полезными, например, что-то, что может превращать сетевые диаграммы в списки соединений, также значительно помогут и людям с нормальным зрением в работе с этими структурами.
Пойнт Реджа о преимуществах простых структур также подтверждается другим кейсом, когда использование DFDM привело к структуре из примерно 200 процессов. Задействованный там программист (еще один очень умный парень) не нарисовал ни единой картины! Он постепенно создавал свою программу, используя иерархическую декомпозицию, и тем не менее, с тех пор у него один из самых низких показателей ошибок среди всех приложений в магазине. Я надеюсь, что по мере того, как вы будете читать дальше, вы поймёте причины столь высокого уровня надежности.
Далее я опишу основные особенности FBP и что мы узнали при разработке и использовании его различных реализаций. Информация о некоторых из них появилась во многих местах, и я чувствую, что пора попытаться собрать воедино 20-летний опыт работы с этим всем в одном месте. За прошедшие годы появилось много статей, написанных разными авторами в разных областях, которые, как я считаю, представляют собой различные грани одного алмаза, но я надеюсь, что, объединив множество связанных идей в одном месте, читатель начнет видеть общую картину. Возможно, есть кто-то, кто ждет этих идей и будет вдохновлен развивать!