Приемы модульного программирования

Разработка сложной программы, состоящей из десятков тысяч, а то и сотен тысяч операторов – очень непростая задача. Для решения сложной задачи ее обычно разделяют на ряд более простых задач. Разделение сложной задачи на ряд подзадач, решение которых может выполняться отдельными подпрограммами, имеет много достоинств:

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

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

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

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

Свойства подпрограмм:

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

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

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

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

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

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

Процедура - функция – это процедура, имеющая следующие ограничения:

- имя ее должно иметь спецификатор, определяющий тип данных функции (является ли она текстовой, целой, одинарной точности и т.д.);

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

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

Процедуры

Начало и конец процедуры в языке BASIC определяет оператор SUB…END SUB.

Синтаксис:

SUB < имя> [< список> ] [STATIC]

[операторы]

[EXIT SUB]

[операторы]

END SUB

где

< имя> – уникальное во всей программе имя процедуры,

< список> – список переменных, передаваемых процедуре при ее вызове; список переменных разделяется запятыми,

EXIT SUB – альтернативный выход из процедуры.

Если в описании процедуры присутствует ключевое слово STATIC, то переменные процедуры – локальные, т.е. сохраняют свои значения между вызовами и при очередном вызове программы не инициализируются.

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

Вызов процедуры может осуществляться оператором CALL или указанием только имени процедуры. Синтаксис передачи управления процедуре:

1. CALL < имя процедуры> [< список аргументов >]

2. <имя процедуры> [< список аргументов >]

Во втором случае, когда не используется оператор CALL, в начале программы должно быть сделано объявление процедуры при помощи оператора DECLARE.

Синтаксис:

DECLARE <FUNCTION | SUB> < имя> [ параметры ],

Где

<имя> - имя процедуры SUB,

< параметры> – переменные, указывающие параметры, которые передаются в процедуру.

Если среди переменных – массив, то его имя указывается с пустыми скобками справа, например, А().

Пример.

REM “Нахождение максимального значения в массиве”

DECLARE SUB MAX (MASSIV())

RANDOMIZE TIMER

INPUT “Введите размерность массива ”; N

DIM M(1 TO N)

FOR I=1 TO N

M(I) = 198*RND – 99

NEXT I

CALL MAX (M(), N)

PRINT MMAX

END

SUB MAX (MASSIV(), K)

SHARED MMAX

MMAX = MASSIV(1)

FOR I = 2 TO K

IF MASSIV(I) > MMAX THEN MMAX = MASSIV(I)

NEXT I

END SUB

Процедуры-функции

Синтаксис:

FUNCTION < имя> [< список> ] [STATIC]

[операторы]

<имя> = < выражение>

[операторы]

END FUNCTION,

где

<имя> - объявленное имя функции,

<список > – параметры, которым из основной программы передаются и присваиваются значения.

< имя> = < выражение> означает, что через имя возвращается значение функции.

Пример:

REM Среднее арифметическое суммы элементов массивов

DECLARE FUNCTION SUMM (X(), Y)

RANDOMIZE TIMER

INPUT “Введите размерности двух массивов ”; N1, N2

DIM A(N1), B(N2)

FOR I = 1 TO N1: A(I) = RND*10: PRINT A(I);: NEXT I: PRINT

FOR I = 1 TO N2: B(I) = RND*10: PRINT B(I);: NEXT I: PRINT

SR = (SUMM (A(), N1) + SUMM (B(), N2))/2

PRINT “Среднее S=”; SR

END

FUNCTION SUMM (X(), Y)

S = 0

FOR I = 1 TO Y: S = S + X(I): NEXT I

SUMM = S

END FUNCTION

Процедуры-функции могут быть рекурсивными. Пример.

REM Сумма натурального ряда чисел

DECLARE FUNCTION primer (n)

INPUT “Введите натуральное число “; x

PRINT “Сумма ряда=”; primer (x)

END

FUNCTION primer (n)

IF n = 0 THEN EXIT FUNCTION

primer = primer (n - 1) + n

END FUNCTION

Языки программирования

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

Самым «низкоуровневым» языком является совокупность команд процессора. Близким к командам процессора является язык Ассемблер. Применение ассемблера позволяет учесть при написании программы все аппаратные возможности компьютера. Когда-то первые программы писали именно так. Чем ближе язык программирования к машинному коду, тем удобнее он для процессора, - программа выполняется быстрее, места в памяти требуется меньше. Составление программ на Ассемблере отличается исключительно большой трудоемкостью и поэтому сейчас применяется редко, однако по-прежнему широко распространен среди профессиональных программистов.

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

Языки высокого уровня начали использоваться для создания программ в 60-х годах. К настоящему времени создано и используется множество языков программирования. Их можно классифицировать по четырём основным группам: процедурные, объектно-ориентированные, функциональные и логические.

Процедурные языки (С, BASIC, FORTRAN, PASCAL и др.)

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

Объектно-ориентированные языки (С++, Java,Visual Basic)

Переменные и функции в такой программе группируются в так называемые классы. Благодаря этому достигается более высокий уровень структуризации программы. Работа программы рассматривается как последовательность событий и соответствующих реакций объектов на эти события. В принципе объектно-ориентированный язык базируется на процедурной модели программирования.

Функциональные языки

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

Логические языки (ЛИСП, ПРОЛОГ)

Основываются на формальной логике и Булевой алгебре, иногда и средствах нечёткой логики. Программа, записанная на логическом языке программирования, не содержит в себе конкретных алгоритмов (заданной последовательности действий). Задаётся описание условий задачи и логических отношений, по которым программа сама рассчитывает возможные следствия и взаимосвязи введённых данных и формул.

Большинство используемых сегодня языков программирования, были созданы на рубеже 60-х и 70-х годов. При этом новые языки не переставали регулярно появляться, однако ни один из них (кроме Java ) не задержался в практике программирования.

По существу прекращены попытки создания “универсального” языка программирования, призванного объединить в себе все последние достижения в области разработки языков (из попыток 60-х – 70-х годов можно вспомнить Алгол, PL/1, Аду). Крупные "языковые” проекты безвозвратно ушли в прошлое вместе с порожденными ими языками.

Наконец, появление персонального компьютера и ОС с графическим интерфейсом (прежде всего Mac OS и Windows) переместило внимание разработчиков программного обеспечения из сферы языков программирования в другие области средств разработки ПО, такие, как визуальное или объектно-ориентированное программирование или модели баз данных. Программист все чаще использует в качестве инструмента не столько язык, сколько конкретную систему программирования (например, Delphi), а какой язык является для нее базовым, не так уж важно.

Трансляторы

Программу на языке программирования записывают в обычном текстовом редакторе. В таком виде программу называют исходным модулем (кодом, текстом).

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

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

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

Существуют два вида трансляторов: компиляторы и интерпретаторы.

Компилятор – программа-транслятор, преобразующая исходный программный модуль в объектный модуль.

Объектный модуль – преобразованный в машинный код исходный программный модуль.

Объектный модуль хоть и записан в виде машинных кодов, но он работать не может, так как в нем содержатся вызовы стандартных процедур и программ, которые программист предусмотрел использовать из специальных библиотек программ. Эти библиотеки прилагаются к языку программирования. Операцию выбора программ из библиотек и подключения их к объектному модулю выполняет специальная программа – редактор связей. Только после работы редактора связей получают работающую программу – исполняемый модуль (рабочий код).

Исполняемый модуль – это объектный модуль с подключенными библиотечными программами.

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

Кроме того, обычно используют оптимизирующие компиляторы. Такой компилятор найдет все повторяющиеся места программы и сделает длину объектного модуля минимальной. В результате дополнительно сокращается время исполнения программы, уменьшается потребность в оперативной памяти.

Все языки программирования можно условно разделить на компилируемые и интерпретируемые. Поскольку откомпилированные программы выполняются в 20-50 раз быстрее, практически все прикладные и служебные программы поставляются в откомпилированном виде. Файлы таких программ имеют расширение.EXE или.COM.

Некоторые интерпретируемые языки программирования могут иметь также и компиляторы.

Интерпретируемые языки проще в изучении.

Лекция 15

Разработка сложных программ

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

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

Структура ЖЦ ПО по ISO/IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

К настоящему времени наибольшее распространение получили следующие две модели ЖЦ:

• каскадная модель (70-85 г.г.);
• спиральная модель (86-90 г.г.).

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

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

Рис. 18 Каскадная схема разработки ПО

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

Рис. 19 Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 20), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате, выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис.20 Спиральная модель ЖЦ