Построение тестов для ИЭТР и приёмо-сдаточных испытаний

А. Г. Котов,

К. В. Кухарева, канд. техн. наук,

П. А. Правильщиков,

канд. техн. наук,

г. Москва

«Цель CALS формулируется достаточно просто: производитель обязан поставлять, предположим, ВМС США, боевой корабль в комплекте не с эшелоном бумажной эксплуатационно-конструкторской документации (и вагонами томов изменений к ней), а с актуальной трёхмерной электронной моделью».

Колчин А.Ф., Овсянников М.В., Стрекалов А.Ф., Сумароков С.В. Управление жизненным циклом продукции. М.: Анахарсис, 2002. - 304 с.

Мысль о необходимости автоматизировать процесс тестирования огромной эксплуатационно-конструкторской документации для сложных наукоёмких изделий – не нова. Пожалуй, впервые она была высказана более четверти века назад по отношению к системам программного обеспечения (ПО) [1, 2]. Так, Г. Майерс утверждал, что «Проверка точности всей документации для пользователя является важной частью комплексного тестирования систем ПО. Все комплексные тесты следует строить только на основе документации для пользователя. В частности, должна быть проверена правильность всех приводимых в этих публикациях примеров» [2, стр. 237]. Однако в то время ни одной сколько-нибудь формализованной процедуры или алгоритма, позволяющей хотя бы концептуально подойти к решению проблемы автоматизации построения тестов для проверки документации, предложено не было. Да и сама документация в то время рассматривалась, прежде всего, в виде «энциклопедических» томов. Идеи «безбумажной информатики» на основе электронного обмена данными, выдвинутые в конце 70-х годов – начале 80-х годов XX века академиком В.М. Глушковым [3], реализуются только в наше время. В наши дни, когда реализуется парадигма компьютерно-ин-тегрированных производств, идеи академика Глушкова дополняют интерактивные электронные технические руководства (ИЭТР), придавая им новое содержание. При этом следует учитывать, что сами по себе ИЭТР иногда являются довольно сложными программными комплексами, особенно тогда, когда в качестве ИЭТР выступают анимационные или управляемые аудио- и видеоролики. Использование аудио- и видеоданных позволяет наглядно продемонстрировать поэтапное выполнение любой операции по обслуживанию и ремонту изделия. Подчеркнём, что при помощи анимации можно увидеть такую работу систем и механизмов, которая недоступна визуально. Однако их трудоёмкость, их сложность а, следовательно, и стоимость подобной документации, подобных технических руководств возрастает. Затраты на создание и поддержку эксплуатационной технической документации с учётом различных модификаций и модернизации изделия могут составлять значительную часть от общих затрат на эксплуатацию самого изделия (поэтому совсем не случайно выбран эпиграф к данному докладу). От полноты и достоверности ИЭТР зависит качество выполнения процессов и процедур обслуживания изделия, а также производительность труда эксплуатационного и ремонтного персонала [4]. Поэтому возникает и проблема тестового диагностирования сложных ИЭТР. Суть этой проблемы состоит в проверке правильности отображения, правильности поэтапного выполнения реализуемых ими функций (алгоритмов). Можно ли для решения этой проблемы использовать тесты, уже построенные для тестового диагностирования программно-технического комплекса, в документацию которого входят ИЭТР? Как при этом должен быть задан (записан, представлен) программно-технический комплекс?
Любое сложное изделие (в том числе и программно-технический комплекс или просто програм-мный продукт) представляет собой иерархию подсистем (компонент), узлов (модулей, блоков или функций), а также отдельных деталей (макрокоманд, мелких программ или подпрограмм). В ИЭТР с каждым из перечисленных элементов ассоциируется следующая информация: 1) техническое описание; 2) технология эксплуатации, обслуживания и ремонта; 3) обнаружение и определение места и типа ошибок или неисправностей. Наиболее приспособленным, с нашей точки зрения, для описания различных иерархических систем является структурный анализ (SA) и методология проектирования на его основе [5-7], которые используются для создания функциональной архитектуры системы. Ещё в конце 70-х структурный анализ и методология проектирования получили достаточно известную аббревиатуру – SADT (Structured Analysis and Design Technique). В начале 90-х годов в США на основе SADT был принят стандарт моделирования деловых и производственных процессов – стандарт IDEF0. Он получил широкое распространение, так как принят в качестве стандарта в нескольких международных организациях, с том числе в НАТО и МВФ. Стандарт IDEF0 тесно связан с международным стандартом ISO 10303. Последний часто именуют STEP (Standard for the Exchange of Product data) По сути, стандарт IDEF0 становится частью STEP, так как в методологии STEP для разработки протоколов применения используется структурный анализ, определяемый IDEF0. При описании функциональной архитектуры сложного наукоёмкого изделия универсальной единицей структурного анализа [7] является SA-блок – см. рис.1.

Управление

На рис. 1 вход при наличии управления преобразуется в выход с помощью некоторого «механизма». В нашем случае в качестве субъекта выступает некоторая функция, выполняемая программно или с помощью технических средств – см. рис. 2. Поэтому в качестве механизма («исполнителя») здесь выступает либо программа, либо аппаратура ЭВМ (чаще всего ПК), либо некоторое специализированное программно-техническое средство. Так как выполнение всякой функции, реализуемой программно или аппаратно, протекает во времени, то на самом деле реализуемая SA-блоком
функция является некоторым процессом, осуществляющим во времени управляемое отображение пространства X_k входов SA-блока в пространство Y_k его выходов.
Подчеркнём, что чаще всего в качестве обозначения k-го SA-блока выступает вербальное (лексическое) описание реализуемой функции (рис. 2). Но так как язык SA вполне допускает использование математических формул [7], то в целях формализации и более строгой постановки задачи мы будем дополнять вербальное описание обозначением некоторого математического отображения, стандартное обозначение которого приведено на рис. 3. Часто с записью функциональной архитектуры выписывается и функциональный тест – тест T_k. Тест T_k проверяет выполнение функции k-го SA-блока. С математической точки зрения функциональный тест T_k, не зависимо от выбранного критерия качества тестового диагностирования, можно рассматривать в качестве некоторого ограничения (сужения) исходного отображения. Напомним, что сужением отображения на подмножество T_k (T_k Ì X) называется отображение , заданное для t_i Î T_k равенством = . Здесь Z_k = Im - образ (область значений) отображения : Z_k Ì Y. Тогда SA-блок можно представить так, как он представлен на
рис. 4.
Заметим, что иметь готовый тест T_k ещё не достаточно для проверки некоторого пункта эксплуатационно-конструкторской документации особенно тогда, когда этот тест находится внутри иерархии функциональной архитектуры. Для того чтобы проверить некоторый заданный пункт документации необходимо вызвать этот тест (заставить отработать вполне определённый механизм управления) и создать условия для его выполнения T_k. Необходимо также получить результаты выполнения данного теста. В терминах технической диагностики это соответствует созданию (обеспечению) условий управляемости и наблюдаемости. Для обеспечения условий управляемости и наблюдаемости на этапе проектирования существуют два подхода: методы тестопригодного проектирования (например, использование методов введения дополнительных контрольных точек [8] или написание древовидных программ с циклами) или же специфические методы моделирования (в данном случае методы символического моделирования - см., например, [9]). Реализация методов символического моделирования позволяет формализовать, а затем и определить те условия, при которых тесты, построенные для «внутренних» модулей системы, могут быть поданы из управляющей программы. На практике, однако, обычно используется некоторая комбинация методов тестопригодного проектирования и методов символического моделирования. Это объясняется большой размерностью реальных систем. В данной работе рассматриваются достоинства и недостатки подобных методов, а также их сочетаний в целях выбора оптимального (с точки зрения авторов) подхода к решению задачи автоматизированного построения тестов, как для приёмо-сдаточных испытаний, так и для ИЭТР. Подобные тесты дополняют друг друга. Учитывая трудоёмкость построения тестов и трудоёмкость моделирования, большие надежды авторы возлагают на появление новых вычислительных средств с механизмами массового и гипермассового параллелизма [10].
Литература

1. Пархоменко П.П., Правильщиков П.А. Диагностирование программного обеспечения.
// Автоматика и телемеханика, 1980, № 1, стр. 103-124.
2. Майерс Г. Надёжность программного обеспечения. М.: Мир, 1980.

3. Глушков В.М. Основы безбумажной информатики. Киев: Наукова Думка, 1982.

4. Колчин А.Ф., Овсянников М.В., Стрекалов А.Ф., Сумароков С.В. Управление жизненным циклом продукции. М.: Анахарсис, 2002. - 304 с.

5. Ross D.T. Structured analysis (SA): a language for communicating ideas.
// IEEE Trans. Software Engineering, 1977, v. SE-3, № 1. P. 16-34.
6. Ross D.T., Schoman K.E. Structured analysis and requirements definition.
// IEEE Trans. Software Engineering, 1977, v. SE-3, № 1. P. 6-15.
7. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования.
М.: МетаТехнология, 1993. 240 с.
8. Правильщиков П.А. Определение минимального множества дополнительных контрольных точек для проверки исправности и поиска неисправностей в комбинационных устройствах. // Автоматика и телемеханика, 1974, № 1. Стр. 144-151.
9. Правильщиков П.А. Построение тестов для программ. // Автоматика и телемеханика, 1977, № 5. Стр. 147-160.
10. Правильщиков П.А. Закон сохранения перебора и естественный параллелизм D-алгоритмов для построения тестов и моделирования в технической диагностике. // Автоматика и телемеханика, 2004, № 7. Стр. 151-191.