3.5. Ошибка в модуле
Поскольку поведение однозначно определяется конструкцией, возникновение ошибочного поведения означает в конечном итоге ошибку конструкции (отдельные испытания при этом могут проходить штатно).
Для выявления таких ошибок у относительно несложных систем вполне достаточно средств обычного тестирования, в пределе - со 100% покрытием.
Но главный вопрос здесь - почему нельзя просто "откинуть" те испытания, которые приводят к ошибкам?
Можно - для подобных относительно несложных систем, когда все такие испытания с ошибками просто выявляются и диагностируются как выходящие за пределы применимости, что требует обращения к неким внешним "спецификациям", неважно - формальным или нет.
Здесь уместно описать, как при таком подходе выглядит модуль, которому противостоит окружение. Так, если с модулем ещё можно связать интерфейс, играющий роль его спецификации, то для окружения эти требования всегда означают набор лишь возможных(!), но не обязательных водействий. То есть, содержательная сторона модуля ничего не говорит о поведении окружения, к которому невозможно в общем виде задать даже структуру требований.
Другое дело - действительно сложные системы, чьё полное поведение можно рассматривать как композицию, как усложнение поведения собственных модулей, которые можно рассматривать как своеобразные "спецификации":
- не только на собственное поведение - как автономное, так и в комплексе (в составе другой системы)
- но и на поведение сопряжённых модулей, поскольку они не должны своим поведением "провоцировать" (вызывать ошибки) в рассматриваемом модуле
Главное отличие от предыдущего случая - в том, что такая система не "маленькая", не "однородная", а скорее образована как композиция модулей, где своё место в ряду усложнений занимает и рассматриваемый модуль.
И вот для произвольного модуля рождается структура - ряд его усложнений, каждое из которых должно содержать в себе далее определяемые характерные черты поведения такого модуля.
Стадии такого
усложнения в реальности обычно относятся к физически разным
моментам.
Но их можно рассматривать и как происходящие совместно, то есть, каждое
испытание производится над всеми версиями разрабатываемого
автомата, включая его
автономное испытание.
И вот теперь можно соотнести указанные характерные черты поведения некоторого модуля с его смыслом, который в более общем случае является инвариантом его древовидного описания.
Для рассматриваемых здесь динамических систем общее понятие семантического треугольника конкретизируется следующим образом:
Примером здесь может служить одна из простейших
программ,
в которой имеется единственный
оператор присвоения
значения
1
переменной
x:
x:=1;
Если принять, что это "обычная", "правильная" программа, то следует ожидать, что после выполнения такого действия переменная x будет содержать значение 1 независимо от всевозможных различий в условиях и времени проведения любого испытания из состава всего эксперимента.
Здесь везде будут подразумеваться только такие "правильные"
программы и
автоматы,
чьё пока нестрогое и неполное определение может быть получено обратной переформулировкой:
при каждом
запуске соответствующего
испытания:
- переменная x будет содержать значение 1
- ...
В более общем случае под
смыслом
(характерными чертами согласованной системы) некоторого
модуля будут пониматься его
элементы и
отношения между ними:
- элементы - это собственные состояния модуля, а потому служащие фрагментами испытаний над ним как автономно, так и в комплексе с другими
- отношения И и ЛИБО образованы собственными состояниями модуля, а потому должны наблюдаться не только для его автономных испытаний, но и для комплексных
То есть, ошибка конструкции - это оценочная характеристика, даваемая автомату либо в процессе тестирования (испытания), либо в результате анализа описания такого автомата и означающаяя разрушение смысла работы некоторых его модулей.
Автомат без ошибок конструкции называется корректным.