О. В. Бартеньев. Современный ФОРТРАН

end if

end function

y = x * sin(x)

print '(1x, a, f5.2, a, f6.4)', 'x = ', x, ' y = ', y x = x + dx

end do end if

end program txy

2.4. Этапы проектирования программ

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

1.Разработка спецификации.

2.Проектирование программы.

3.Запись программы на языке программирования (кодирование).

4.Отладка и тестирование программы.

5.Доработка программы.

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

7.Документирование.

8.Поддержка программы в процессе эксплуатации.

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

Вспецификации отражаются:

•состав входных, выходных и промежуточных данных;

•какие входные данные являются корректными и какие ошибочными;

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

•какие ошибки должны выявляться и какие сообщения должны выдаваться пользователю;

•какие ограничения имеет программа (например, программа размещения элементов печатной платы может иметь ограничение по числу размещаемых элементов);

42

2. Элементы программирования

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

•какая документация должна быть подготовлена;

•перспективы развития программы.

На этапе проектирования создается структура программы и для каждого фрагмента выбираются известные или разрабатываются новые алгоритмы. Последние должны быть подвергнуты тщательным исследованиям на предмет их результативности, т. е. способности алгоритма получать требуемые результаты, и эффективности - способности алгоритма получать нужные результаты за приемлемое время.

Параллельно с разработкой алгоритмов решаются вопросы организации данных, т. е. выделяются данные стандартных типов и способы их представления (скаляр или массив), а также разрабатываются новые структуры данных и определяется круг используемых с этими структурами операций. Подходы к решению этих задач во многом зависят от используемого языка программирования, который может быть, например, объектно-ориентированным или модульным. Современный Фортран поддерживает концепции как процедурного, так и модульного программирования (разд. 8.1).

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

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

Тестирование - это запуск программы или отдельного фрагмента с целью выявления в них ошибок. Отладка - процесс локализации и исправления ошибок. В результате тестирования устанавливается, соответствуют или нет разработанные фрагменты и состоящая из них программа сформулированным в спецификациях требованиям. Методы тестирования и отладки рассмотрены, например, в [10].

Для тестирования фрагмента (программы) создаются специальные тестовые наборы входных данных, для которых до запуска фрагмента (программы) вычисляются ожидаемые результаты. Запуск фрагмента выполняется из специально созданной вспомогательной программы, называемой драйвером. Если фрагмент, в свою очередь, вызывает другие фрагменты, работоспособность которых пока еще не проверена, то эти фрагменты заменяются специальными простыми программами, которые имеют тот же интерфейс, что и заменяемые фрагменты, и имитируют их деятельность. Такие программы называются заглушками.

43

О. В. Бартеньев. Современный ФОРТРАН

Тестирование может начинаться с фрагментов низшего уровня. Тогда нам понадобятся только драйверы, поскольку фрагменты более высокого уровня будут вызывать уже проверенные фрагменты. Такая стратегия тестирования называется восходящей. При нисходящей стратегии тестирование начинается с фрагментов высшего уровня. В этом случае понадобятся только заглушки. Обычно при тестировании восходящая и нисходящая стратегии используются совместно.

Проделанная на предшествующих этапах работа, как правило, предоставляет разработчикам достаточный материал, позволяющий сделать выводы о рабочих характеристиках программы и сформулировать предложения по улучшению программы и ее отдельных показателей. Однако не всегда все эти предложения сразу же реализуются и программа с определенными изъянами выходит в свет в качестве программного продукта. Впрочем, если некоторые характеристики серьезно ухудшают качество программы, то придется выполнить ее доработку.

Поддержка программы в процессе эксплуатации имеет целью устранение выявленных пользователями ошибок и адаптацию программного продукта к условиям его эксплуатации. Помимо этого, накапливается материал, необходимый для последующего развития и создания новой версии программы.

2.5. Правила записи исходного кода

Программисты, как правило, со временем вырабатывают свой стиль записи исходного кода, позволяющий им при повторном обращении к программе быстро вспоминать, что она делает и как работает, и при необходимости быстро вносить изменения в программу. Иными словами, программист умеет писать хорошо читаемый и легко изменяемый код. В ряде случаев необходимо, чтобы этот код легко могли бы прочесть и изменить другие программисты, например сопровождающие программу. Итак, за счет каких приемов удается записать хорошо читаемый и легко изменяемый код? Вот некоторые из них:

•программная единица должна содержать достаточный комментарий, позволяющий определить ее назначение, состав входных и выходных данных и выполняемые ей действия. Комментарий, однако, не должен мешать чтению операторов Фортрана;

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

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

программную единицу оператор IMPLICIT NONE;

•операторы объявления следует группировать по типам;

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

44

2. Элементы программирования

g может быть использовано для обозначения ускорения свободного падения, имя iVectorSize подойдет для указания длины вектора. Понятен смысл и имени pi;

•атрибуты объектов данных следует объявлять в операторах объявления типа, например так:

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

integer, parameter :: m = 10, n = 20 real a(m, n)

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

character(*), parameter :: date = '01.01.2000'

•при записи управляющих конструкций следует использовать правило рельефа, состоящее в том, что расположенные внутри конструкции операторы записываются правее образующих эту конструкцию операторов, например операторов IF-THEN-ELSE. Это же правило распространяется на запись определений производных типов и процедур;

•при записи операторов и выражений следует использовать пробелы, например до и после оператора присваивания или логической операции. Не забывайте ставить пробелы и после запятых, например в конструкторе массива. Однако в длинных выражениях пробелы между знаками операций могут быть опущены;

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

•операторы FORMAT группируются в одном месте, как правило вверху или внизу программной единицы;

•размещенные в одном файле программные единицы должны разделяться пустыми строками;

•программные единицы следует располагать в файле в алфавитном порядке их имен;

•однократно используемые в программе процедуры лучше оформлять как внутренние, следующие после оператора CONTAINS;

•внутренняя функция лучше операторной;

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

45

О. В. Бартеньев. Современный ФОРТРАН

•внутренние массивы и строки процедур следует оформлять как автоматические объекты;

•не использовать оператор GOTO;

•не применять ассоциирования памяти;

•отказаться от использования нерекомендуемых и устаревших средств Фортрана (прил. 2).

Большинство из приведенных правил рассмотрены в пособии и проиллюстрированы примерами.

46