Г л а в а  3

ПАКЕТ ПРОГРАММ

      С термином пакет программ или пакет прикладных программ связан широкий спектр проблем [Горбунов-Посадов, 1990], включающий, в частности, языки заданий пакетов, информационное обслуживание пользователей и др. Нас будет интересовать лишь один из компонентов этого спектра — особенности организации программного материала в пакете, делающие его важнейшим конфигурационным ориентиром при построении расширяемых программ.

3.1. Пакетная модуляризация

      Пусть требуется разработать программное обеспечение для проведения расчетов в некоторой предметной области. И пусть множество различных задач, возникающих в этой области, достаточно велико. Тогда построение одной «единичной» «универсальной» программы, решающей все множество задач, оказывается, как правило, нерациональным. Такая программа будет иметь гигантские размеры и труднообозримую структуру. Тем самым не только усложнится процесс ее создания, но и появится серьезное препятствие на пути последующего развития программы.
      Другой подход мог бы заключаться в реализации лозунга «каждой задаче — отдельную программу». Он представляется чрезвычайно расточительным, поскольку из-за общности задач предметной области в текстах программ, построенных таким образом, неизбежно будут присутствовать совпадающие или близкие по содержанию части. Это означает массовое дублирование программного материала, которое, как было показано в первой главе, крайне затруднит последующее сопровождение и развитие. Любые же поиски компромисса, «золотой середины» между первым и вторым подходами ведут всего лишь к перемешиванию их недостатков в различных пропорциях.
      Третий подход к решению рассматриваемой проблемы, которому посвящена настоящая глава, предлагает изменить направление модуляризации, сориентировав ее на новую общую конфигурацию программного фонда, называемую пакетом программ. При этом подходе целью становится не вычленение отдельных модулей единичной программы, а формирование набора модулей, охватывающего («покрывающего») данную предметную область. Покрытие области означает, что для любой ставящейся там задачи может быть построена решающая ее программа, представляющая собой надлежащим образом организованное подмножество модулей из сформированного набора.

      3.1.1. Пакет и библиотека. Чтобы четче определить специфику пакетного подхода, сопоставим его с другими конфигурационными решениями. Ближе всего к пакету стоит библиотека модулей (см. разд. 2.4.3), но между ними есть принципиальное отличие. При построении библиотеки не ставится цель покрытия предметной области, т. е. формирования конкретных приложений исключительно из хранящихся в библиотеке модулей. Как правило, в выполняемой программе библиотечные модули соседствуют с модулями, разрабатываемыми и хранимыми вне библиотеки. На такие модули, создаваемые специально для конкретной программы, помимо их основной, функциональной нагрузки ложатся обычно и все заботы по обеспечению межмодульного интерфейса.
      Постановка задачи реализации пакета программ существенно более жесткая. Любая выполняемая программа должна целиком составляться из модулей пакета (что позволяет, в частности, использовать пакет людям, не знакомым с программированием). Поэтому здесь основные проблемы интерфейса, т. е. межмодульных связей по данным и управлению, должны быть решены на стадии проектирования пакета и не могут быть перенесены на стадию формирования конкретных выполняемых программ.
      С библиотекой и пакетом связано небольшое терминологическое затруднение. В этой книге используется термин «библиотека модулей», несмотря на то что не менее широкое хождение в программистском обиходе имеет термин «библиотека программ». «Библиотека модулей» удобнее, поскольку она позволяет строго различать понятия: «программа» — законченный продукт, пригодный к выполнению, и «модуль» — компонент, используемый при формировании программы.
      Те же соображения применимы и к пакету, который, конечно же, следовало назвать «пакетом модулей». Однако в данном случае терминологическая традиция слишком сильна, словосочетание «пакет прикладных программ» повсеместно распространено, и от него нельзя было отказаться. И хотя «пакет программ» — единственное допущенное в книге отклонение от трактовки «программы» как пригодного к выполнению продукта, все же в тех местах, где возможна какая-либо неоднозначность, применяются термины «конкретная конфигурация программы» или «выполняемая программа».

      3.1.2. Пакет и универсальная программа. Наряду с сопоставлением «библиотека — пакет» заслуживает внимания и параллель между пакетом и «универсальной» программой. На первый взгляд, отличие между ними невелико. Скомпоновав вместе все составляющие пакет модули и снабдив их небольшой управляющей надстройкой, мы получим эквивалентную пакету «универсальную» программу. А высекая из «универсальной» программы (скажем, посредством техники смешанных вычислений [Ершов, 1984]) только составляющие, участвующие в конкретном расчете, мы получим, вообще говоря, такую же выполняемую программу, как и в случае сборки ее из выделенного подмножества модулей пакета.
      На самом деле главными аргументами в пользу пакетного подхода являются не непреодолимые сложности построения универсальной программы и не компактность программ, формируемых из модулей пакета. Основное преимущество пакета в том, что его архитектура делает его открытым для расширения и модификации, в то время как коррекция крупной «универсальной» программы — дело весьма деликатное (рис. 3.1).

 
Рис. 3.1.  Два подхода к построению крупных программ.
а — универсальная программа,  б — пакет

      Открытость пакета прикладных программ основана на возможности его безболезненного (см. разд. 1.2) развития. Расширение класса решаемых пакетом задач достигается в основном за счет подключения к пакету дополнительных вновь создаваемых модулей. При этом, вообще говоря, не требуются изменения существующих модулей, т. е. не может пострадать работоспособность отлаженных ранее версий программ.
      Разумеется, о безболезненности развития пакета надо говорить только с оговоркой «как правило». Реализация неожиданно появившейся революционной идеи может привести к кардинальной перетряске всего программного хозяйства, затрагивающей многие из накопленных модулей. Однако преобладающую часть возможных направлений развития пакета обычно удается предвосхитить еще на стадии первоначального проектирования. Если каждое из предугаданных направлений получит подобающее конфигурационное оформление, то основной объем работ по развитию пакета можно будет выполнить безболезненно.
      Безболезненность развития особенно актуальна при модификации заимствованной программы. Если исходный текст недоступен, то безболезненность здесь приходит автоматически: ранее отлаженные версии не затрагиваются. Однако даже если заимствованный текст разрешено редактировать, делать это все равно крайне нежелательно. Ведь когда появится новая, улучшенная версия заимствованной программы, придется вручную объединять свои изменения и изменения новой версии, а в программировании нет ничего более сложного и опасного.

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

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