В технической диагностике [1] традиционно рассматривается следующая цепочка понятий: дефект - логическая неисправность – ошибка. Логическая неисправность есть обобщение разнообразных дефектов, имеющих различную физическую
природу, и она проявляется на выходе устройства в виде ошибки преобразования
информации.
При проектировании программного продукта под дефектом будем понимать
любое искажение кода команды, изменяющее логику ее работы. Это изменение порождает логическую неисправность, которая и приводит к искажению результатов,
то есть к ошибкам вычислений тех или иных переменных в программе.
Устранение логических неисправностей и, соответственно, дефектов программ
и является целью и задачей бездефектного проектирования. В силу этого, верификация и тестирование как средство объективного вычислительных процессов должны
входить в любую технологию проектирования программ.
Логические неисправности условий-предикатов (УП) в программных продуктах можно разделить на простые и сложные. Простые неисправности могут только
удалять некоторые дуги и, соответственно, вершины на графе вычислительного процесса. Сложные неисправности могут не только удалять, но и вносить новые дуги и
вершины.
Основные затруднения при сравнении систем алгебро-логических уравнений
ВП программ на предмет установления их эквивалентности преобразования одной и
той же информации состоят в компенсациях и эквивалентности УП и появлении их
невычислимых конъюнкций. Поиск невычислимых конъюнкций в предметной и логической областях представляет наибольший интерес при проектировании вычислительных процессов и программ на их основе. В логических схемах это понятие определяется как don’t care – не заботит (безразлично) и является следствием частичного
определения булевых функций [2]. В программах это явление правильнее трактовать
как don’t exist – не существует, которое является следствием реализаций конъюнкций УП методами функциональной декомпозиции условий-предикатов при их алгоритмизации и программировании.
Понятие don’t exist тесно связано с понятием импликации (влечет), которое в
технической логике [3] трактуется несколько иначе, чем в формальной или математической логике, так как в ней событие рассматривается как факт, то есть вычислено
условие-предикат в значении true или false или оно не вычислено и, следовательно,
осталось неопределенным. Далее, условия-предикаты рассматриваются просто как
логические булевы переменные и объединение их конъюнкций, описывающие сложные предикаты, как булевы функции, в общем случае частично определенные.
Импликация является инструментом поиска несуществующих конъюнкций, а
именно, если вычисление некоторого условия a в значении pa=0 \/ 1 влечет (имплицирует) однозначное доопределение условия b в значении pb=0 \/ 1, то значение pb в
конъюнкции a /\ b не существует – это и есть don’t exist.
Несуществующие значения конъюнкций УП при сравнении покрытий для переменных необходимо удалить, так как при алгоритмизации и программировании в
области don’t exist происходит произвольное доопределение условий вычисления
значений переменных по различным формулам или алгоритмам. Данное положение
легко проиллюстрировать, например, при вычислении значений переменных по интервальным формулам. Использование булевых функций и логических переменных
позволяет строить адекватные и формальные модели вычислительных процессов, базирующихся на понятии алгоритма [4], как основу бездефектного проектирования
программных продуктов методами технической диагностики [5].
|