Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ

155

деленные в его предке (хотя некоторые из них он может переопре-

делить), и новые функции и значения. С точки зрения логики и

алгебры, это не конкретизация, а, в лучшем случае, обогащение

структуры. Старые методы вполне могут оказаться неадекватны-

ми для нового класса. В результате потребовалось разрабатывать

специальные способы борьбы с подобными затруднениями, кото-

рые описываются в курсе объектно-ориентированного програм-

мирования.

Очень важной стадией развития ООП является объектно-ориентирован-

ное проектирование (дизайн) (ООД). Здесь система описывается с несколь-

ких сторон, сначала со стороны пользователя (диаграммы использования),

потом со стороны данных (диаграммы классов) и с других сторон реализа-

ции (диаграммы состояний и т. п.) Поддерживать целостность системы опи-

саний и переходить от диаграмм к прототипам программ позволяет систе-

ма

UML

(Uniﬁed Modelling Language). Это уже не язык программирования, а

язык формализованных спецификаций программ.

§ 3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ

Рассмотренные в предыдущих разделах стили программирования отно-

сятся к уровню методик (см. сноску 1 на стр. 108). Для следования этим сти-

лям необходимы определенные условия, связанные со спецификой решае-

мой задачи, выбранного языка или что-либо иное, характеризующее методи-

ку данного стиля. Это необходимые, но, разумеется, недостаточные условия,

выполнение которых делает возможным адекватное применение стиля. На-

стоящий параграф посвящен несколько иным стилям, зависящим не столько

от языков и от задач, сколько от программного и технологического окруже-

ния программиста.

Эти стили рассчитаны не на составление единственной программы, а на

серийное их производство (в том или ином смысле).

В одном случае в качестве серии рассматривается набор программ, в ко-

торых повторяется применение одних и тех же фрагментов. Это стиль про-

граммирования от переиспользования.

В другом случае серия — это набор различных программ, которые в прин-

ципе могут быть построены автоматически (что в реальности означает либо

полуавтоматически, либо вручную, как правило, по жестко фиксированному

методу) из одной общей программы с учетом особенностей применения. Это

156

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

стиль специализирующего программирования.

Наконец, третий случай, для которого серийность вырождается. Она под-

меняется парой, один компонент которой — макет, образец, демонстраци-

онная разработка или же что-то отличное от программы, выполняющей ре-

шение задачи, но способное показать некоторые ее особенности либо в дру-

гом смысле приблизить разработку к цели. Это нечто называется образцом,

макетом, шаблоном либо прототипом, по которому может строиться про-

грамма. Второй компонент пары — производственный вариант программы,

изготавливаемый на основе информации о макетном образце, о его разра-

ботке или путем технологической процедуры работы с первым компонентом

пары (например, это могут быть правила заполнения шаблона). Это стиль

программирования от образца.

Три стиля программирования, обсуждаемые в данном параграфе, связы-

вает между собой общее качество. Идея каждого из них возникла в самый на-

чальный период развития информатики как отрасли человеческой деятельно-

сти. Однако форм представления идей, которые можно было бы предложить

в качестве практического руководства, пришлось ждать десятилетия. Но и се-

годня нельзя считать каждый из этих стилей окончательно оформившимся.

Почти все конкретные реализации этих идей ограничиваются использовани-

ем фон Неймановской модели вычислений, традиционных языков и техно-

логий, сложившихся в рамках этих традиций.

Внимание!

Иногда накопленный опыт может быть перенесен на другие

модели без потерь и даже с ощутимыми выгодами, ищите эти воз-

можности!

3.9.1. Программирование от переиспользования

Может показаться странным, что в обзоре стилей мы не выделили спе-

циально модульное программирование. В самом деле, в программистском

обиходе часто употребляется выражение «модульный стиль программирова-

ния». Однако если разобраться, то становится очевидным следующее.

Требование разрабатывать программы, в которых выделены

автономные и, соответственно, легко заменяемые другими, фраг-

менты, решающие логически замкнутые задачи, является обще-

логическим и общетехнологическимым, а не исключительным,

присущим какой-либо специальной методике.

3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ

157

Именно это требование обычно трактуется как модульность программно-

го изделия. Преимущества модульности, понимаемой в общем смысле, это:

возможности замены модуля без изменения всего остального, и осуществи-

мость повторного использования программных фрагментов. Вот последнее

уже можно рассматривать как особый стиль программирования, для которого

модульность является основным из средств.

Конкретные реализации модульности в системах программирования раз-

личны, но общий смысл понятия остается. Средства поддержки модульно-

сти характеризуют даже не стиль, а конкретный язык, поддерживающий этот

стиль. И поэтому правомерно говорить не о стиле, а о конкретном языке, в ка-

кой мере он поддерживает модульное построение программ в рамках своего

стиля. К вопросу о языковой поддержке модуляризации мы еще возвратимся

при обсуждении процедур как средства декомпозиции программ.

Стиль от переиспользования характеризуется тем, что при составлении

программы стремятся максимально использовать то, что уже сделано — са-

мим программистом, его коллегами или же вообще где-либо. В идеале на

смену программированию как кодированию алгоритмов должно прийти про-

граммирование как сборка из заранее заготовленных блоков — сборочное

программирование. Этот термин введен одним из соавторов в статьях [58,

59, 60]. Г. С. Цейтин отделил это понятие от теоретических рассмотрений

и представил его в работе [80] с чисто программистской стороны. Заметим,

что практика математики уже давно отказалась от построения новых теорем

(соответствующих в информатике программам) и новых понятий (соответ-

ствующих абстрактным типам данных) с самого начала. Она весьма профес-

сионально переиспользует ранее полученные результаты. Но в математике

из-за концептуального единства системы понятий и строгих критериев обо-

снованности не возникает проблемы совместимости новых версий, которая

зачастую губит попытки не просто переиспользования, но и просто исполь-

зования старых программ.

Понятно, что такое стремление далеко не всегда можно реализовать на

практике, что при использовании готовых строительных блоков возможны

потери. Тем не менее, потенциальная выгода за счет переиспользования все-

гда обращает на себя внимание.

Рассмотрим две реальные ситуации, которые демонстрируют разработку,

не ориентированную и ориентированную на переиспользование. В первой

ситуации действует программист, работающий с очень развитой системой, в

которой “есть все”. Тем не менее, он пишет свою процедуру лексикографиче-

ского упорядочивания строк, потому что «легче самому написать, чем найти,

158

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

а потом, ведь еще и подгонять придется». Вывод: во-первых, здесь начисто

отсутствует стремление к переиспользованию, а во-вторых, переиспользова-

нию могут препятствовать затруднения поиска того, что требуется включить

в составляемую программу и проблемы совместимости версий.

Вторая ситуация — другая крайность. Программисту на

Java

потребо-

валось построить синтаксический анализ. На вопрос о том, как он это де-

лает, получен ответ: «Зачем это знать? У меня есть пакет

JavaCC

, который

все делает, как надо!». Вместе с тем дальнейшие расспросы показали, что

этот программист не представляет себе даже того, какого типа метод анализа

поддерживает

JavaCC

, и, следовательно, ничего не может сказать о том, как

задание грамматики для данного пакета связано с эффективностью анализа.

Узнав возможные варианты, программист призадумался, но ничего менять

не стал. Почему? Ответ простой: «Так ведь все уже работает!». Короче го-

воря, качество использования готовых компонентов системы зависит от

знания о них. Ситуация опять-таки та же самая, что в математике, особенно

в прикладной. Квалифицированное использование теоретических результа-

тов требует знания соответствующей теории, а порою и идей доказательств

результатов (поскольку в реальной ситуации предположения теории никогда

не выполняются точно). Глубина требуемого знания различна: иногда доста-

точно общего представления, как, например, при использовании математи-

ческих функций, иногда нужны сведения о принципах реализации, но всегда

можно указать необходимый уровень знакомства с переиспользуемым.

Сравнение ситуаций показывает, что одних пожеланий и директивных

указаний, что надо что-то переиспользовать, мало. Нужны знания о том, что

можно воспользоваться переносимыми компонентами и как именно ими вос-

пользоваться, получение которых часто требует существенных трудозатрат.

Нужно, чтобы само переиспользуемое программное обеспечение было при-

способлено для этого, в частности, чтобы оно в гораздо большей степени,чем

сейчас, следовало накопленной в математике хорошей практике, не игнори-

руя ее как чистую теорию. Расшифровка предыдущего предложения позво-

лит вдумчивому читателю самому вывести все условия, необходимые для

обеспечения переиспользования в конкретной обстановке.

Конечно, переиспользованию способствует применение развитых и вы-

разительных языков. В частности, экранирование в них реализационных де-

талей позволяет легче переносить программы из одной операционной об-

становки в другую (перенос и переиспользование — различные задачи, но

в некоторых аспектах они пересекаются). Способствует переиспользованию

повышение уровня понятий языка, хотя бы до второго-третьего типа (объект-

3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ

159

ная ориентированность языка). Иногда ООП помогает также возможностя-

ми наследования свойств и методов объектов (но часто в самых критических

ситуациях плохо концептуально продуманная концепция наследования столь

же сильно и мешает). Все это — зародыши поддержки стиля программирова-

ния, нацеленного на переиспользование. Его можно придерживаться или нет

в зависимости от ситуации, от собственных склонностей, от уровня знаний о

среде программирования, уровня знаний и умений самого программиста (тот,

кто способен подняться до уровня метода, склонен к переиспользованию, а

тот, кто не может подняться выше тактического планирования, обычно избе-

гает его) и других обстоятельств. С другой стороны, сложившаяся практика

в значительной степени препятствует переиспользованию (обстоятельный

обзор препятствий, не потерявший актуальности до сих пор, выполнен Г. С.

Цейтиным в уже указанной работе [80]), а уровень систем поддержки еще

недостаточно высок и неадекватен общей задаче применения данного стиля.

Если же ограничиться деятельностью программиста и с этой точки зре-

ния, в противовес средствам поддержки, говорить о переиспользовании, то,

прежде всего, нужно указать на два аспекта данного стиля: применение су-

ществующих компонентов и разработка переиспользуемых компонентов.

Применение переиспользуемых компонентов характеризуется следующи-

ми особенностями стиля:

a) главная характеристика стиля от переиспользования: предпочтение по-

иска кандидатов на внедрение в программу самостоятельной разработке;

b) стремление к исследованию существующих кандидатов, к выявлению в

них особенностей, полезных или вредных для решаемой задачи;

c) попытки адаптации своего решения для осуществимости внедрения (здесь

могут появляться навязанное структурирование данных,конверторы и др.);

d) сопоставление и оценка вариантов внедрения и самостоятельной гипоте-

тической разработки;

e) адаптация внедряемого в программу, если она требуется (это сближает

обсуждаемый стиль с некоторыми аспектами другого технологического

стиля, который мы назвали программированием от образцов).

При разработке переиспользуемых компонентов необходимо учитывать, что

подобная разработка всегда требует дополнительных затрат,которые связаны

со следующими требованиями:

160

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

a) необходимо уделять особое внимание документированию (лучше всего,

самодокументированию) переиспользуемых компонентов;

b) необходим серьезный анализ того, что кандидаты на переиспользование

могут быть отнесены к типовым приемам программирования, т. е. имеют

достаточно широкую для использования в дальнейшем область примени-

мости;

c) нужно прорабатывать варианты не только варианты полного переисполь-

зования компонентов as is, но и частичного их переиспользования в виде

шаблонов, готовых фрагментов и т. п., когда требуется настройка компо-

нента (здесь опять прослеживаются связи с программированием от образ-

цов);

d) необходимы спецификации как области адекватного применения компо-

нента, так и границ применимости (вторая часть почти всегда отстутсвует

в нынешних спецификациях);

e) необходима оценка эффактивности применения компонента;

f) необходима специальная забота о предъявлении компонента потенциаль-

ным пользователям, в частности, определение круга пользователей, для

которых данный компонент может представлять интерес, и обеспечение

их соответствующей информацией.

В характеристиках обоих аспектов программирования от переиспользования

нет явного упоминания специфики традиционных моделей вычислений. По-

этому они не зависят от стиля, в котором написаны компоненты, и от осо-

бенностей вычислительных систем, на которых они реализуются. Но компо-

ненты и модель вычислений выполняют роль фундамента, на котором бази-

руется надстройка переиспользования. А устойчивость здания и даже его ар-

хитектура существенно зависит от качества фундамента. Рассмотрим ранее

представленные стили с точки зрения их приспособленности к сочетанию со

стилем переиспользования.

Программирование от состояний явно связано с глобальным для каждой

программы понятием набора состояний, и использовать фрагмент програм-

Анализ, проведенный специалистами фирмы IBM, показывает, что экономически оправ-

дано говорить о переиспользуемом компоненте, когда он будет применяться, по крайней ме-

ре, в трех разработках.

3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ

161

мы в отрыве от этого набора, вообще говоря, лишено смысла. Это указывает

на естественные рамки переиспользования для данного стиля.

Во-первых, если фрагмент может быть выделен как черный ящик, т. е.

нас интересует лишь соотношение между его входными и выходными дан-

ными, то он на уровне программы может рассматриваться как самостоятель-

ный узел переработки данных и тем самым получает независимость от со-

стояний программы. В свою очередь, именно это позволяет использовать та-

кой фрагмент как самостоятельный узел переработки другой программы, т. е.

переиспользовать его. На этом принципе строятся все библиотечные матема-

тические функции, реализацию которых достаточно часто не требуется даже

знать при использовании.

Обычными единицами переиспользования при любом стиле программи-

рования являются процедуры. Именно они автономно описываются и, если

оказываются независимыми от общего с другими компонентами контекста,

то по сути дела становятся теми самыми черными ящиками, о которых только

что шла речь.

Еще один возможный случай, когда часть, ясно осознанная программи-

стом, состояний внешней программы может быть интерпретирована как го-

моморфный образ части (опять же, явно выделенной) состояний компонен-

ты (серый ящик). Тогда компоненту можно даже модифицировать, т. е. воз-

можно переиспользование как фрагмента либо шаблона. Но приемы устано-

вления гомоморфизма между состояниями — та высокоуровневая надстрой-

ка над программированием от состояний, которая пока еще не создана, и по-

этому здесь программист в высшей степени зависит от качества содержатель-

ного концептуального анализа.

Как ни странно, немногим лучше приспособлено к сочетанию со стилем

переиспользования структурное программирование. Требования к структуре

информационного пространства задачи и к согласованию с ним других ком-

понентов программы обеспечивают регламентированные связи между под-

задачами, а значит, облегчается (но не исчезает) задача выделения самосто-

ятельных компонентов. В дополнение к полностью самостоятельным пере-

используемым компонентам здесь можно указать на переиспользование, при

котором в новом применении обеспечивается необходимая часть контекста

(т. е. переиспользуется компонент и эта часть контекста; смотри модули язы-

ков

Modula2

ObjectPascal

). Модули можно рассматривать как серые ящики

для структурного программирования. Возможности модуляризации доста-

точно хорошо исследованы и корректно реализованы в упомянутых выше

языках.

162

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

Следует отметить, что для рассмотренных случаев задача переисполь-

зования достаточно часто требует модификации того, что предоставляется.

Рассмотрим простейший пример, который не выходит за рамки переисполь-

зования черного ящика. Функция вычисления квадратного корня определена

только для неотрицательных аргументов. Вопрос: нужна ли в переиспользу-

емой подпрограмме вычисления этой функции проверка? С одной стороны,

она повышает надежность программирования,но с другой — оказывается из-

быточной, когда точно известно (можно доказать),что аргумент больше нуля.

В рамках традиционной техники простых механизмов отключения проверки

быть не может, поскольку все они нарушают принцип черного ящика. В им-

перативных языках подобные многовариантные подпрограммы традиционно

трактуются как нарушающие обозримость систем приказов.

Внимание!

На самом деле никакой крамолы в многовариантности нет.

Эта форма серых ящиков соответствует естественному расшире-

нию логики — исчислению предикатов с частично упорядочен-

ными кванторами — и может быть корректно добавлена к импе-

ративным структурным языкам, а к языкам программирования от

состояний она добавляется весьма естественно и стоит лишь по-

жалеть об отсутствии в них такой возможности.

Неимперативность по своей сути лучше приспособлена для переисполь-

зования и, в частности, для шаблонного переиспользования, поскольку соот-

ношения вместо приказов легче автоматически трансформировать или даже

просто переинтерпретировать в другой обстановке (отсутствие императив-

ности — еще один фактор, обусловливающий уже не раз упоминавшуюся

практически абсолютную переносимость математических результатов). По-

этому неудивительно, например, что базы данных-фактов в программах на

языке

Prolog

часто становятся их общими частями.

При использовании сентенциального и функционального стиля возмож-

ности перестройки переиспользуемого компонента под ситуацию гораздо вы-

ше за счет более высокоуровневых принципов вычислений. Однако точных

практических оценок этого пока что нет. Как правило, повторно используют-

ся крупные и содержательно полные фрагменты программ, чаще всего имен-

но те,которые являют собой базовые механизмы, развивающие модель вычи-

слений языка. Недостаточность опыта разработки больших производствен-

3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ

163

ных проектов с существенным использованием этих стилей вынуждают рас-

суждать о них лишь предположительно.

Следующие два стиля, рассмотренные выше, программирование от со-

бытий и приоритетов с точки зрения переиспользования интересны, пре-

жде всего, потому, что для них заранее предписана определенная декомпози-

ция программы: выделение в ней уровней генерации и обработки. Уже само

это наталкивает на мысль осуществимости общего генератора для однотип-

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

продуктивность использования данных стилей. Нельзя забывать и о том, что

событийный механизм или управление с помощью приоритетов неизбежно

повышают автономность обработчиков: например, они могут не обязатель-

но рассчитывать на определенную последовательность вызовов и, как след-

ствие, их гибкость повышается.

На сегодняшний день наиболее перспективными с точки зрения переис-

пользования являются программы в объектно-ориентированном стиле. Об-

щая причина тому — гибкие средства абстракции объектных языков и четкое

отделение интерфейсов классов от реализаций. Это повышает потенциаль-

ные и реальные возможности переиспользования.Вместе с тем данный стиль

эффективен лишь для достаточно больших систем и тем самым вдохновля-

ет программистов на построение больших систем классов и объектов, кото-

рые сильно взаимосвязаны. А это, в свою очередь, заставляет технологизи-

ровать разработки. Технология в настоящее время связывается с наработкой

типовых моделей фрагментов объектно-ориентированных систем. Создают-

ся шаблоны проектирования (так называемые паттерны), которые предпи-

сано использовать, чтобы минимизировать связи в системе, обеспечивать ее

развиваемость [22].

Проектирование с учетом повторного использования результатов в буду-

щем возможно осуществлять на трех уровнях:

1. Уровень приложений. В ходе ведения проекта заботятся о том, чтобы

при декомпозиции и разработке компонентов системы выявлялись ком-

поненты-кандидаты на переиспользование. Эти компоненты выделя-

ются в самостоятельные единицы и оформляются независимо от про-

екта;

2. Уровень инструментов.Разработка проекта практически всегда включа-

ет в себя создание инструментальных средств, поддерживающих уни-

фикацию:единые библиотеки общедоступных для проекта средств, об-

щий контекст и единообразные средства доступа к нему, средства под-

164

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

держки выполнения технологических соглашений и регламентов, ша-

блоны проектирования и др. Этот инструментарий или часть его во

многих случаях может быть оформлен независимо от проекта для воз-

можного переиспользования в виде библиотек;

3. Уровень решений. Ценность для переиспользования может представлять

архитектурный уровень проекта. Хорошие архитектурные решения,как

правило, допускают распространение за рамки конкретного проекта, в

котором они появились. Это могут быть фрагменты, которые пригод-

ны для использования в качестве образцов для других проектов, и то-

гда их переиспользование требует оформления соответствующего ша-

блона. Другой вариант независимого решения — каркас проекта, т. е.

набор взаимосвязанных компонентов,требующих доопределения, в ре-

зультате чего может быть построено приложение,подсистема,модуль и

др. Использование шаблонов или каркасов в другом проекте связывает

стиль переиспользования со стилем программирования от образцов.

Приведенный перечень упорядочен по степени значимости уровней для пе-

реиспользования. Наибольшая эффективность достигается,когда удается при

проектировании выйти на уровень решений, но одновременно этот уровень

является наиболее сложным и трудоемким для разработки.

В заключение отметим, что условия применения стиля переиспользова-

ния в реальном программировании должны включать в себя оценку и эко-

номических показателей, и уровня квалификации исполнителей. А это уже

функции менеджера проекта, который должен решать,ориентироваться ли на

переиспользование (в обоих аспектах) или нет, и, если да, то решить многие

финансовые и организационные проблемы, выходящие за рамки собственно

программирования.

Предупреждение!

Здесь необходима трезвая оценка уровня своих специалистов

и уровня организованности работ, поскольку на действительно

выгодное для переиспользования решение способны, как прави-

ло, лишь хорошие специалисты в хорошей инфраструктуре.

3.9.2. Программирование от образцов

Программирование от образцов — стиль, часто высокомерно игнорируе-

мый специалистами, но тем не менее он является весьма распространенным