Cтраница 3
В большинстве случаев модуль, обнаруживающий ошибку, не должен ее исправлять. Модуль, определяющий стратегию коррекции, может потребовать частичного участия в корректирующем действии ряда других модулей системы. При проектировании большинства реальных систем рассмотрение проблем межмодульного интерфейса производится, как правило, на более поздних стадиях процесса проектирования вплоть до начала эксплуатации. В результате такого подхода возникает необходимость нарушения разработанного интерфейса для получения желаемых результатов по локализации ошибок. [31]
Если критерием оптимизации разрабатываемой модульной СОД является максимизация достоверности обрабатываемой информации, в качестве модели отображения логического взаимодействия событий ошибки различных элементов СОД ( процедур и информационных элементов), приводящих к появлению недостоверной информации при обработке, удобно использовать понятие графа ошибок. Анализ графа ошибок дает возможность оценки вероятностей появления главного события ошибки в зависимости от структуры и технологической схемы модульной СОД, а также сложности межмодульного интерфейса. Большое число и сложный характер информационных связей между программными модулями повышает число ошибок при проектировании программного и информационного обеспечения и при функционировании системы. Степень влияния ошибок в отдельной программе на работу других программ затрудняет их обнаружение и исправление. Поэтому одной из основных причин снижения достоверности при обработке данных является межмодульный интерфейс, определяемый составом программных модулей и информационных массивов и их размещением во внешней памяти, а также наличием в системе программных модулей точек разрыва, которые вызывают необходимость передачи управления другим модулям и обращения к внешней памяти ЭВМ. Эти причины приводят к увеличению вероятностей базисных событий и главного события ошибки. [32]
При нисходящем тестировании проверки начинаются с программ управления и организации вычислительного процесса. Первоначально тестируются управляющие программы и программы решения функциональных задач, размещенные на высших иерархических уровнях. К ним постепенно подключаются для тестирования программы последующих более низких иерархических уровней. Если программы нижних уровней не разработаны или не протестированы, то вместо них включаются программные имитаторы - заглушки. Преимуществом такого метода является возможность сохранения и развития наборов тестовых исходных данных по мере подключения программ нижних уровней. С самого начала тестирования могут использоваться исходные данные, соответствующие реальному функционированию КП, с последовательно уменьшающимися ограничениями. При этом наиболее полно и на ранних этапах проверяется межмодульный интерфейс. Однако такое тестирование может требовать больших затрат на обнаружение простейших ошибок в модулях нижних иерархических уровней по мере их подключения, если они до этого тестировались недостаточно полно. [33]
При разработке больших, сложно организованных программ приходится иметь дело с разнообразием форм представления данных. Рабочими объектами могут быть: оттранслированные модули; тексты программ, подлежащие редактированию; документирующий ( полный) текст программы. При расчетах, кроме того, могут требоваться схемы счета, текстовые вставки, данные. Все эти различные по-существу компоненты отличаются еще и по чисто технологическим признакам, таким, как время жизни, активность, характерный размер, стоимость обработки. Их разнородность приводит к необходимости иметь в ИС средства доступа к внешней памяти различного назначения, от стационарных пакетов МД, входящих в состав той или иной системы коллективного пользования, до индивидуальных носителей, закрепленных за конкретным пакетом. Важно, что значительная часть перечисленных объектов хранится и используется в текстовом виде. Зачастую в такой же форме осуществляется в пакете и межмодульный интерфейс, особенно на верхних уровнях иерархии. Поэтому операции над текстом являются весьма существенными функциями ИС и должны включать развитые средства работы с файлами, диалогового редактирования и макропроцессирования. [34]
При нисходящем тестировании проверка начинается с главного модуля. К нему постепенно подключаются модули более низких иерархических уровней. Если модули нижних уровней не разработаны или не протестированы, то вместо них подключаются программы-заглушки. Таким образом тестируется некоторая модель группы программ с имитаторами-заглушками. При использовании этого метода появляется возможность сохранения и развития исходных тестовых данных по мере подключения модулей нижних иерархических уровней. С самого начала тестирования могут использоваться реальные исходные данные, которые постепенно уточняются по мере подключения модулей. При этом наиболее полно и на ранних стадиях проверяется межмодульный интерфейс. [35]