Любая программа может содержать

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

1. Считывается очередная команда из файла технологических команд.
2. Анализируется код команды, в соответствии с параметрами команды заполняется предопределённый массив CLD и предопределённые переменные .
3. Если активизирована программа обработки технологической команды, то вызывается программа обработки этой команды. В ней обычно содержится программный код, который формирует кадры управляющей программы (УП), соответствующие данной команде CLData.
4. Если активизирован шаблон для этой команды, то формируется выходная строка УП по шаблону.

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

Разбор 8 задания на Python | ЕГЭ по информатике 2021

Каждая программа обработки технологической команды начинается с заголовка, состоящего из слова < PROGRAM > и имени программы, а заканчивается словом < END >. Имя программы совпадает с именем команды, которую она обрабатывает. При вызове программы обработки параметры команды передаются через предопределенный массив < CLD > и оператор < Cmd >. Значения параметров для различных команд CLData описаны в главе < Описание технологических команд >.

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

Комментарием является любой текст, расположенный после символа < ! >до конца строки. Перенос комментариев недопустим. Закомментировать сразу несколько строк можно, выделив соответствующий блок кода, и, нажав комбинацию клавиш или .

Первой выполняемой программой является программа < COMMON >. Затем выполняется команда < PARTNO >, последней – программа обработки команды < FINI >.

Особенностью программы < COMMON >является определение в ней глобальных переменных, значения которых доступны во всех программах. Для собственных нужд любая программа может использовать переменные, не объявленные в < COMMON >и, поэтому, не являющиеся общедоступными. Такие переменные являются локальными.

Источник: kb.sprutcam.com

Подпрограммы в паскале

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

Разбор 8 задания на Python | ЕГЭ-2023 по информатике

В языке Паскаль выделяют два вида ПП:

1. Процедура PROCEDURE.

2. Функция FUNCTION.

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

Процедуры и функции объявляются в разделе описания вслед за разделом переменных.

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

ПП оформляются подобно основной программе, т.е. состоят из заголовка и тела (блока).

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

Все имена, представленные в разделе описаний основной программы, называют глобальными. Они действуют как в разделе операторов основной программы, так и в любой ПП.

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

ПП-ПРОЦЕДУРЫ

PROCEDURE имя процедуры (список формальных параметров);

PROCEDURE имя процедуры;

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

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

имя процедуры (список фактических параметров);

В Паскале различают четыре вида формальных параметров:

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

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

В качестве начального значения для формального параметра пересылается текущее значение соответствующего фактического параметра. Значение формального параметра может меняться при выполнении процедуры, однако влияние на значение фактического параметра не оказывает. Следовательно, параметр-значение не может быть результатом выполнения процедуры. Параметр-значение можно передавать только в одном направлении: из программы в процедуру.

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

Если в списке формальных параметров списку идентификаторов предшествует VAR, то параметры этого списка называются параметрами-переменными.

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

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

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

Фактическим параметром в этом случае должен быть идентификатор процедуры.

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

Фактическим параметром в этом случае должен быть идентификатор функции.

Между формальными и фактическими параметрами должно быть полное соответствие, т.е.

— формальных и фактических параметров должно быть одинаковое количество;

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

— тип каждого фактического параметра должен совпадать с типом соответствующего ему формального параметра.

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

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

FUNCTION имя функции (список формальных параметров): тип функции;

FUNCTION имя функции: тип функции;

За заголовком функции следует тело функции, оформленное в виде блока (раздел описаний и раздел операторов).

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

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

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

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

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

1. Параметры-значения.
2. Параметры-процедуры.
3. Параметры-функции.

Источник: studfile.net

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

Тестирование может показать лишь наличие ошибок, но не их отсутствие.

Эдсгер Дейкстра

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

Для выявления ошибок в программах ЖЦ разработки ПО предусматривает процесс тестирования, который является достаточно трудоемким и занимает больше времени, чем кодирование . (Г. Майерс дает оценку 1/3 для тестирования, при том, что кодирование занимает примерно 1/6 [6].) Тестируемое ПО обычно называют SUT — Software Under Test. Цель тестирования — не убедиться в безошибочной работоспособности программы, а наоборот — найти ошибки. Поэтому в первую очередь возникает вопрос: а что есть ошибка в программе?

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

Рис. 7.1. V-образная модель жизненного цикла разработки ПО

При рассмотрении вопросов анализа программного кода порой удобнее применять ранее рассмотренную в разделе 1 модель жизненного цикла . Ее часто называют V-образной из-за расположения блоков на рисунке (рис. 7.1).

Нисходящая левая ветвь модели отражает поэтапную последовательность преобразования одних программных документов в другие: SYS — системных требований в SRD — требования к программному обеспечению, проектированию и формированию DDD — описания архитектуры системы и, наконец, разработке CODE — кода программ. Восходящая правая ветвь отражает процесс верификации разработанного программного обеспечения.

На первом этапе путем тестирования производится модульная верификация (MV), при которой поведение исполняемого программного кода проверяется на соответствие его DDD -описанию. Это наиболее трудоемкая и скрупулезная часть исследования. Она часто требует написания драйверов — моделей модулей, вызывающих процедуры тестируемого модуля, и заглушек — моделей процедур других модулей, вызываемых из тестируемого. Часто в MV отдельно выделяют процесс тестирования межмодульных связей, описанных в DDD .

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

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

7.1. Тестовый план

Тестирование обычно проводится снизу вверх, т.е. сначала тести-руются отдельные функции, затем целые модули и далее проводится комплексное тестирование всей программы или комплекса программ. Для проведения тестирования разрабатывается тест-план (test-plan) — совокупность тестовых наборов (test-case). В каждом тестовом примере производится выполнение тестируемого программного элемента SUT при заданных Input — условиях и входных данных и проверяются все Output — выходные данные на соответствия заданным значениям.

Тестовый пример (набор) должен включать в себя как минимум:

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

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

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

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

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

7.2. Проблема полноты тестирования

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

Например, если рассмотреть функцию умножения двух рациональных чисел, варьируемых от -1000 до +1000, то в интервале от минимального возможного числа до максимального содержится бесконечное количество чисел. Т.е. все возможные значения входов проверить нельзя. Если же учесть, что машина оперирует невсеми этими числами, а различает только 10 знаков после запятой (т.е. множество чисел в интервале дискретно, минимальное отличие двух чисел 0,0000000001), то для проверки всех комбинаций из заданного диапазона понадобится степени тестовых примера, что является достаточно большим числом для такой простой функции. Если проверяются не все возможные комбинации входных условий, то тестирование является неполным.

В основном для сложных программ тестирование является неполным, но даже неполное тестирование может выявить большинство ошибок, если выработать грамотную стратегию их поиска. Часто используют метод деления входных значений на области эквивалентности, так чтобы внутри каждой области для всех значений программа «вела себя» похоже. Тогда при написании тестовых примеров рассматриваются все значения на границах областей и по одному произвольному значению из каждой области (области определяются для каждого входного параметра).

Этот подход называют методом трех точек. В нашем примере для функции умножения двух чисел можно рассмотреть области [-1000; 0] и [0; +1000]. Деление образовано путем выявления трех особых точек (-1000, 0 и +1000). Такие точки называют критическими точками, в них тестируемая функция может менять свое поведение или потенциально вести себя особо.

Т.е. для тестирования функции методом трех точек достаточно проверить случаев (для каждого входа это точки -1000; 0; 1000 и, например, -500 и 500), что значительно меньше полного перебора. Конечно, при таком подходе возможно, что какие-то ошибки останутся, но вероятность этого будет невелика и зависит от выбора критических точек.

Функции, выполняющие различные сравнения, могут неверно их проводить, поэтому имеет смысл проверять их работу в непосредственной близости к критическим точкам. Для этого берутся значения, отстоящие от критических точек на величину дискретизации значений. Т.е. для примера функции умножения двух чисел, кроме значений метода трех точек, стоит рассмотреть значения -999,9999999999; -0,0000000001; 0,0000000001 и 999,9999999999. Этот подход называют методом пяти точек.

Иная сторона тестирования связана с типизацией переменных, при помощи которых задаются входные данные. Если для входных значений функции используются переменные типа float, а максимальное значение входа ограничено как +1000, то теоретически можно передать на вход и число +1001. Зачастую реакция функции на такое число не будет даже описана.

Однако существуют приложения, чье поведение критично даже при передаче им входных значений, выходящих за пределы допустимых (например, авиационные программы, программы управления ядерными реакторами). В этом случае подразумевается, что программа должна вести себя корректно, т.е. не «зависнуть», не «повесить» систему, хотя выходное значение предсказать нельзя. Тестовые примеры, проверяющие поведение программы, в таких случаях, называются тестами на устойчивость (robustness). Если при тестировании методом пяти точек проверять еще и значения, выходящие за пределы допустимых диапазонов, то такой метод будет называться методом семи точек. В примере функции умножения двух чисел кроме значений -1000; -500; -999,9999999999; -0,0000000001; 0,0; 0,0000000001; 500,0; 999,9999999999; 1000 для каждого входа следует взять, например, еще значения -1001 и 100,0000000001.

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

Источник: intuit.ru