Учебное пособие 1295

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

2.4.Проверка успешности выполнения команды и вывод сообщения для пользователя, если в обрабатывающем модуле возникла ошибка или особая ситуация. При отсутствии ошибок устанавливается новое состояние МПО.

2.5.Конец цикла по п.2.

3.Вывод итогового сообщения о завершении работы

проекта.

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

Обобщённый алгоритм ведущего модуля ППП с ВЯ командного типа, работающего в режиме компиляции, может быть построен следующим образом:

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

2.Запрос у пользователя режима работы: компиляция новой программы или выполнение уже готовой программы.

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

3.1.Цикл до окончания ввода программы на ВЯ или до отказа пользователя от работы в этом режиме.

3.1.1.Ввод и проверка очередной команды.

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

3.1.3.Команда синтаксически верна и выполнима. Формирование очередного элемента управляющего вектора

ирегистрация изменений состояния МПО.

3.1.4.Конец цикла 3.1.

3.2.Сохранение управляющего вектора во внешней памяти (в файле).

121

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

то

4.1. Запрос имени файла, содержащего управляющий

вектор.

4.2.Чтение управляющего вектора из файла.

4.3.Цикл до конца управляющего вектора.

4.3.1.Вызов обрабатывающего модуля, указанного в очередном элементе управляющего вектора.

4.3.2.Проверка успешности выполнения обрабатывающего модуля. Если возникла ошибка или особая ситуация – вывод сообщения для пользователя и установка кода серьёзности ошибки.

4.3.3.Если код серьёзности ошибки не допускает дальнейшего выполнения программы, то переход к п.4.4.

4.3.4.Конец цикла по п.4.3.

4.4.Итоговое сообщение о завершении программы на входном языке.

5.Запрос о продолжении работы с пакетом. При положительном ответе – переход к п.2.

6.Завершение сеанса работы с пакетом.

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

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

122

обрабатывающих модулей или обслуживающих модулей для ввода-вывода данных.

4.4. Проектирование обслуживающих модулей ППП

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

Справочный интерфейс пользователя

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

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

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

Интерфейс управления

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

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

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

123

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

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

Информационный интерфейс

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

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

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

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

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

124

Интерфейс ввода-вывода

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

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

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

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

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

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

Внешний интерфейс

Внешний интерфейс должен обеспечит ввод данных из файлов или базы данных и вывод данных в файл (базу данных). Конкретные требования к внешнему интерфейсу определяются на основе анализа предполагаемых условий применения пакета и объёмов обрабатываемых данных.

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

125

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

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

126

5.ОПРЕДЕЛЕНИЕ НАДЁЖНОСТИ. ТЕСТИРОВАНИЕ

ИОТЛАДКА ПРОГРАММ

5.1. Надёжность программы. Модели надёжности

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

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

Работоспособным называется такое состояние программы, при котором оно способно выполнять заданные функции с параметрами, установленными требованиями технического задания (ТЗ). С переходом программы в неработоспособное состояние связано событие отказа [7].

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

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

Для оценки надежности используются 3 группы показателей: качественные, порядковые и количественные.

Рассмотрим основные количественные показатели надежности ПИ.

127

1. Вероятность безотказной работы Р - это вероят-

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

где t — случайное время работы программы до отказа; t3

—заданная наработка.

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

Это показатель, обратный предыдущему.

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

Существует следующая связь между (t) и P(t): В частном случае при = const

P(t) exp( t).

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

4. Средняя наработка до отказа Тj - математическое ожидание времени работы ПИ до очередного отказа

где t - время работы программы от (К — 1) до К-го отка-

за.

128

Иначе среднюю наработку на отказ Тj можно предста-

вить

где tj — время работы программы между отказами; n - количество отказов.

5. Среднее время восстановления ТВ - математическое ожидание времени восстановления tвi - времени, затраченного на обнаружение и локализацию отказа – tо.л.i, времени устранения отказа - ty.o.i, времени пропускной проверки работоспособности – tп.п.i:

где n — количество отказов.

Для этого показателя термин "время" означает время, затраченное специалистом по тестированию на перечисленные виды работ.

6. Коэффициент готовности К2 - вероятность того, что ПИ ожидается в работоспособном состоянии в произвольный момент времени его использования по назначению

К2 = Тi/(Гi+ ТB). (13)

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

129

Естественно, мы можем и должны стремиться повышать уровень надежности программы, но достижение 100 %-ной надежности лежит за пределами возможного.

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

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

Классификация программных ошибок по категориям

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

Под категорией ошибок понимается видовое описание ошибок конкретных типов. В полной классификации выделено более 160 категорий, объединенных в 20 классов.

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

1.Создать список ошибок (по примеру приведенной классификации).

2.Определить перечень категорий, имеющих причинный характер.

3.Обеспечить получение необходимой информации о происхождении каждой ошибки.

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

130