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

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

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

175

Что изменилось бы в этих построениях, если бы они исходили из неимпе-

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

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

граммой. К примеру, в исходной программе на языке

Prolog

мы бы увидели

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

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

функции от двух переменных

в качестве запрашиваемого утверждения.

Анализ истории подстановок при n = 5 покажет, что некоторые из утвер-

ждений становятся лишними, раньше распознаются тупики. Это дает осно-

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

без объединения утверждений и их эквивалентных преобразований.

В функциональном языке история вычислений —это последовательность

подстановок аргументов функций и применения функций к аргументам. Не-

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

жения процесса в зависимости от перерабатываемых данных, иногда они мо-

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

историю, как и в операционном случае, можно определить, как нужно пре-

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

построить остаточную программу. Программа функции

F(x,n)

, реализующая

тот же алгоритм, что был представлен выше, при n = 5 за счет ликвидации

разветвлений и раскрытия рекурсии приобретет примерно такой вид:

(

) =

(

) = (

)

∗

На Лиспе, например, этот вид превращается в

(LAMBDA (x)(LAMBDA (t)(t*t*x)*(x*x)))

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

нию функций с частично определенными параметрами.

Для функционального программирования этот метод достаточно перспек-

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

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

ма алгебраических и логических преобразований.

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

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

функции Y = X

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

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

версального специализатора из нее получится остаточная программа с мини-

176

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

мальным числом умножений. Скорее всего, при n = 5 у вас получится что-то

вроде

((((x*x)*x)*x)*x)

Для операционных языков задача специализации оказывается еще труд-

нее, чем при следовании неимперативным стилям. Проблема прежде всего

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

граммы и в отсутствии даже элементов хорошей теории, которые уже суще-

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

ния. Поэтому уместно говорить об автоматизированных системах поддержки

специализации, которые либо показывают пользователю варианты преобра-

зований, требуя подсказок, либо ориентируются на частные ‘хорошие’ слу-

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

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

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

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

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

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

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

вариант.

И смешанное вычисление, и опциональная специализация — примеры

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

другие возможности. Рассмотрим их от простого к сложному.

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

С/С++

, ис-

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

констант, тем самым при переходе от одного варианта программы к друго-

му требуется лишь в одном месте выставить нужные значения. Немногим

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

ными вычислениями. По существу это просто задание соотношений между

константами.

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

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

шения и др. Наглядный пример — использование в универсальной програм-

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

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

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

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

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

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

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

3.10. ОБЩИЕ ВЫВОДЫ

177

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

мой и ее специализированной версии или по иным причинам нет смысла

явно составлять универсальный алгоритм. В этом случае можно говорить о

ручном способе специализации “идеальной” (несуществующей) программы,

которую можно рассматривать как призрак. Рассмотрение такого метода ра-

боты в связи с событийным программированием и сопрограммным механиз-

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

ручной специализации появляется возможность лучше узнать сущность про-

цессов, реализуемых в программе. Здесь в полной мере применим принцип

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

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

задачи (в другом подобном случае программист, знающий об общем реше-

нии, вполне может пойти другим путем). В данном случае, как и всегда, когда

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

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

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

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

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

ся к определенному моменту. Наглядно ситуацию иллюстрирует следующий

пример

, связанный с параллельными вычислениями. Пусть универсальная

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

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

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

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

преимущества одного из них.

§ 3.10. ОБЩИЕ ВЫВОДЫ

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

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

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

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

кого к аппаратуре. Здесь традиционно и оправдано применяются програм-

мирование от состояний, событий и приоритетов. Однако требования учета

временных характеристик ввода/съема данных, соотношений между ними, а

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

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

178

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

этим стилям накапливаются собственные типовые решения.

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

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

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

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

рые формируются как уточнения существующих стилей.

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

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

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

ние которых просто запрещено. Все подобные дополнения вводятся с целью

способствовать взаимопониманию и облегчить взаимодействия

. Продол-

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

глашения и регламенты становятся стилевыми элементами технологии про-

граммирования для данного коллектива.

Наконец,каждый профессиональный программист имеет собственные при-

вычки, предпочтения и сложившиеся стереотипы. Они определяют его ин-

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

узнавать ее автора

Большая часть таких стилей с трудом может быть систематизирована. Да

это и не требуется! Нужно только хорошо осознавать, что особенности сти-

лей не только неизбежны, но и желательны.

Мы рассмотрели основные существующие на практике стили программи-

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

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

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

Прежде всего, стили делятся на два уровня. В стилях первого уровня мы

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

ня — с абстрактными сущностями.

На первом уровне все стили укладываются в следующий морфологиче-

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

являющий назначение каждого стиля.

Другой вопрос, насколько они этой цели достигают.

Но авторам программ стоило бы помнить о том. что в Ватиканской канцелярии высшей

похвалой документу является: «Он так хорошо написан, что невозможно понять, кто его

автор.»

3.10. ОБЩИЕ ВЫВОДЫ

179

Действия Условия Стиль

Локальные Локальные Структурный

Глоба

льные Локальные От состояний

Лока

льные Глобальные Сентенциальный

Глоба

льные Глобальные От событий

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

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

в стилях первого уровня.

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

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

щиъх структуру многооконного интерфейса (прежде всего, таковыми стали

системы

ThinkPascal

ThinkC++

для

Macintosh

,а затем их эстафкету подхва-

тили

Visual C++

Delphi

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

плекс средств объектно-ориентированной системы программирования. Как

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

Рассмотрим теперь, каким классам практических задач лучше всего со-

ответствуют различные стили программирования.

Счету по физическим либо математическим формулам (если брать это

в наиболее общей форме методов вычислений) великолепно соответствует

структурное программирование. Более того, методам вычислений соответ-

стуют чаще всего циклы, а не рекурсия.

Чистая лексика — автоматы и, соотвественно, программирование от со-

стояний.

Статика синтаксиса — примитивная рекурсия или сводящиеся к ней сен-

тенциальные средства. Здесь часто также целесообразны табличные сред-

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

за эту область.

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

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

граммированию.

Распознавание образов — автоматы.

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

состояний на языке

FORTRAN

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

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

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

власть, то и других заставлять делать то же. Оглянитесь вокруг, и Вы увидите целую кучу

таких примеров.

180

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

Статика графики — рекурсия в объектно-ориентированной форме. Дина-

мика графики — автоматы в объектно-ориентированной форме либо собы-

тийное программирование.

***

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

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

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

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

Вопросы для самопроверки

1. Что представляет собой первый цикл в программе 3.3.1? Какую схему

программ он моделирует?

2. В программе 3.9.1 есть ошибка (по традиции появляющаяся с момента

ее разбора А. П. Ершовым). Где ошибка и почему ее не обязательно

исправлять для иллюстрации смешанных вычислений?

В свзязи с этим можно заметить, что популярная в настоящее время технология RUP явля-

ется средством автоматного представления динамики графики и следующей из нее динамики

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

Глава 4

Понятие жизненного цикла

программного обеспечения и его

модели

§ 4.1. ВВЕДЕНИЕ

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

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

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

му мануфактурному, а в перспективе и к промышленному, их производству.

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

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

цированному рабочему, должен иметь квалификацию и работать на уровне

как минимум техника, а квалифицированный рабочий — уже на том уровне,

который в технике соответстует инженеру.

Как обычно происходит в подобных ситуациях, программисты прежде

всего попытались перенести опыт других индустриальных производств в свою

сферу. В частности, было заимствовано и модифицировано под реальный

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

Аналогия жизненного цикла программного обеспечения с техническими

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

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

Программы, в отличие от чаще всего встречающихся в нашем обиходе

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

181

182

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

альными объектами, и на самом деле единственными чисто искусственны-

ми объектами, кроме математических конструкций, с которыми имеет дело

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

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

лами одной лишь мысли. А математический объект и программа сосотоят из

информационных сущностей. В принципе они могут быть порождены чисто

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

на реальные либо конвенциональные ограничения. Математический объект

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

ся в систему существующих математических объектов. Программа же созда-

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

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

но, да оно вдобавок и меняется все время. Так что программное окружение

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

и окружающая среда — для технических. И, конечно же, неустраним фак-

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

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

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

что он может сотворить с программой. Но, тем не менее, программа наибо-

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

настоящего искусственного объекта.

Программы не подвержены физическому износу, но в ходе их эксплуа-

тации обнаруживаются ошибки (неисправности), требующие исправления.

Ошибки возникают также от изменения условий использования программы.

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

ния, иначе оно теряет свой смысл. Поэтому правомерно говорить о старении

программ, правда, не о физическом, а о моральном.

Необходимость внесения изменений в действующие программы (как из-

за обнаруживаемых ошибок, так и по причине развития требований) приво-

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

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

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

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

ния программного обеспечения (см. рис. 4.1).

Исторически развитие концепций жизненного цикла связано с поиском

для него адекватных моделей. Как и всякая другая, модель жизненного цикла

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

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

4.1. ВВЕДЕНИЕ

183

Использование

Разработка

Продолжающаяся разработка

(сопровождение)

Рис. 4.1. Разработка, использование и сопровождение программ

нения моделей определяет их разнообразие.

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

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

следующим образом.

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

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

граммного обеспечения и что нереально требовать от него. В частности, не-

удобные моменты работы с программой, ее ошибки и недоработки обычно

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

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

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

будет во всех отношениях лучше данной системы.

Во-вторых, модели жизненного цикла — основа знания технологий про-

граммирования и инструментария, поддерживающего их. Программист все-

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

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

моделирования жизненного цикла: любая технология базируется на опреде-

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

струменты вокруг фаз и этапов жизненного цикла.

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

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

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

Все это относится к сфере профессиональных обязанностей руководителя

программного проекта.

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

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

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

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

рования.

184

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

§ 4.2. МОДЕЛИ ТРАДИЦИОННОГО ПРЕДСТАВЛЕНИЯ

О ЖИЗНЕННОМ ЦИКЛЕ

4.2.1. Общепринятая модель

Вероятно,самым распространенным мотивом обращения к понятию жиз-

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

с технологическим процессом. Этому назначению хорошо соответствует так

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

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

две фазы:

• разработка и

• сопровождение.

Фазы разбиваются на ряд этапов (см. рис. 4.2).

Разработка начинается с идентификации потребности в новом приложе-

нии, а заканчивается передачей продукта разработки в эксплуатацию.

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

ление требований. Определение требований включает описание общего кон-

текста задачи, ожидаемых функций системы и ее ограничений. На этом этапе

заказчик совместно с разработчиками принимают решение, о создании си-

стемы. Особенно существенен этот этап для нетрадиционных приложений.

В случае положительного решения начинается этап спецификации систе-

мы в соответствии с требованиями. Разработчики программного обеспече-

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

вать их в виде спецификаций системы. Важно подчеркнуть, что назначение

этих спецификаций — описывать внешнее поведение разрабатываемой си-

стемы, а не ее внутреннюю организацию, т. е. отвечать на вопрос, что она

должна делать, а не как это будет реализовано. Здесь говорится о назначении,

а не о форме спецификаций, поскольку на практике при отсутствии подхо-

дящего языка спецификаций, к сожалению, нередко приходится прибегать к

описанию «что» посредством «как»

. Прежде чем приступать к созданию

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

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

поддерживать соответствие описания «что» нечетким, неточным и часто противоречивым

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

что эти люди будут знакомы с «самым хорошим языком спецификаций», что они будут забо-

титься о корректности своих требований. Задача этапа спецификаций в том и состоит, чтобы