Автономная и комплексная отладка ПО. Моделирование работы систем с целью проведения комплексной отладки ПО

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

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

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

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

Мы установили, что в реальной работе системы имеются три типа входных данных в ПО:

1) данные, сообщения приходящие от системы более высокого уровня иерархии (СБВУИ),

2) данные, приходящие от аппаратуры (датчиков) системы,

3) данные межпрограммных сообщений.

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

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

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

Рис. 8.3 – Входные данные при отладке

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

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

Это моделирование может быть проведено в соответствии с 2 методами:

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

2) Автоматизировано с использованием инструментальной универсальной ЦВМ, на которой реализуются имитационная математическая модель внешней среды - аппаратуры СТС, связанной с математической моделью объекта управления, и реальной системной ЦВМ, в которой размещено отлаживаемое ПО.

Хорошая инструментальная среда для отладки ПО должна обладать четыремя свойствами.

1. У разработчиков и тестировщиков ПО есть необходимые инструменты.

2. Программное обеспечение отлаживается на ЦВМ той же архитектуры и конфигурации что и в реальной системе.

3. Использование системы, ПО которой отлаживается, пользователям понятно и хорошо моделируется в отладочной среде, что позволяет убедиться в работоспособности ПО.

4. Отладочная среда обладает повторяемостью результатов при повторяемости входных в ПО данных

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

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

2. Во вторых, имеющиеся в не отлаженном ПО ошибки могут привести к повреждению аппаратуры системы.

3. В третьих существенная часть отладки – проверка работы ПО в нештатных ситуациях работы системы. На реальной аппаратуре трудно имитируются нештатные ситуации в аппаратуре. Не ломать же её?! Отработка нештатных ситуаций ~ половина работ при отладке ПО СТС.

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

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