Дипломная (вкр): Программный комплекс моделирования релейно-контактных схем

Рисунок 6.2 - Общая блок-схема редактора схем РЗА

7. ОТЛАДКА И ЭКСПЕРИМЕНТАЛЬНОЕ ТЕСТИРОВАНИЕ

7.1 Отладка

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

Существуют две взаимодополняющие технологии отладки: использование отладчиков и журналирование.

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

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

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

.        Программирование - внесение в программу новой функциональности, исправление ошибок в имеющейся.

.        Тестирование (ручное или автоматизированное; программистом, тестером или пользователем; «дымовое», в режиме черного ящика или модульное) - обнаружение факта ошибки.

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

.        Отладка - обнаружение причины ошибки.

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

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

Другое направление - сделать, чтобы отладка нужна была как можно реже. Для этого применяются:

.        Контрактное программирование - чтобы программист подтверждал другим путём, что ему на выходе нужно именно такое поведение программы. В языках, в которых контрактного программирования нет, используется самопроверка программы в ключевых точках.

.        Модульное тестирование - проверка поведения программы по частям.

.        Статический анализ кода - проверка кода на стандартные ошибки «по недосмотру».

В программном коде может быть так называемое недокументированное поведение - серьёзные ошибки, которые не проявляются при нормальном ходе выполнения программы, однако весьма опасны для безопасности всей системы в случае целенаправленной атаки. Чаще всего это результат ошибок программиста. Наиболее известные примеры - это SQL-инъекция и переполнение буфера.

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

7.2 Ручное тестирование

Ручное тестирование (manual testing) - часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно проводится тестировщиками или обычными пользователи путем моделирования возможных сценариев действия пользователя.

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

Ручное тестирование заключается в выполнении задокументированной процедуры, где описана методика выполнения тестов. Методика задает порядок тестов и для каждого теста - список значений параметров, который подается на вход со списком результатов на выходе. Так как процедура предназначена для выполнения человеком, в ее описании для краткости могут использоваться некоторые значения по умолчанию, ориентированные на здравый смысл, или ссылки на информацию, хранящуюся в другом документе.

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

Данные методы способствуют существенному увеличению производительности и повышению надежности программы. Во-первых, они обычно позволяют раньше обнаружить ошибки, уменьшить стоимость исправления последних и увеличить вероятность того, что корректировка произведена правильно. Во-вторых, психология программистов, по-видимому, изменяется, когда начинается тестирование перед релизом. Возрастает внутреннее напряжение и появляется тенденция «исправлять ошибки так быстро, как только это возможно». В итоге программисты допускают больше промахов при корректировке ошибок, уже найденных во время тестирования, чем при корректировке ошибок, найденных на более ранних этапах. Кроме того, скептицизм связан с тем, что это «первобытный метод». Сейчас стоимость машинного времени очень низка, а стоимость труда тестировщиков высока и ряд руководителей пойдут на все, чтобы сократить расходы. Однако, есть другая сторона ручного тестирования - при тестировании за компьютером причины ошибок выявляются только в программе, а самая глубокая их причина - мышление программиста, как правило, не претерпевает изменений, при ручном же тестировании, программист глубоко анализирует свой код, попутно выявляя возможные пути его оптимизации, и изменяет собственный стиль мышления, повышая квалификацию [12].

7.3 Модульное тестирование

Модульное тестирование, или юнит-тестирование - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Цель модульного тестирования - изолировать отдельные части программы и показать, что по отдельности эти части работоспособны.

Этот тип тестирования обычно выполняется программистами.

Модульное тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль по-прежнему работает корректно. Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений.

Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируя отдельные части программы, а затем программу в целом.

Модульные тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.

Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе [13].

8. РАЗРАБОТКА ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ

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

Любая схема создается в программе-редакторе схем. Необходимо запустить файл с названием editor.lua. В открывшемся окне будет показана рабочая область, меню и панель инструментов. Рисунок 8.1.

Рисунок 8.1 - Изначальное состояние программы-имитатора

Необходимо выбрать один из инструментов, находящихся на панели. Тогда справа на рабочей области будет показано, какой инструмент сейчас выбран, как на рисунке 8.2.

Рисунок 8.2 - Отображение выбранного инструмента

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

Рисунок 8.3 - Рабочая область окна программы

При использовании одного инструмента «Открытый контакт» на рабочей области, при левом клике мыши, отобразится данный элемент. Он будет иметь название “contact” и находиться по координатам, на которых в этот момент находился указатель мыши. Рисунок 8.4.

Рисунок 8.4 - Демонстрация работы инструмента «ОТКР»

Точно так же работают: «Закрытый контакт», «Реле» и некоторые другие. Инструмент «Провод» работает только в том случае, если на схеме есть хотя бы один контакт и одно реле. Это заставляет задуматься и избежать лишних ошибок при построении схемы и «Провод» работает по правому клику мыши на двух соединяемых элементах или на соединяемых элементе и питающей шине, как на рисунке 8.5.

Рисунок 8.5 - Работа инструмента «ПРОВОД»

Инструмент «Редактировать» необходим для того, чтобы редактировать информацию элемента - изменить его название и цепь, в которой он находится. Для этого нужно выбрать этот инструмент и два раза кликнуть на редактируемом элементе. Появится окно диалога, в котором нужно ввести данные и нажать кнопку «Подтвердить», как показано на рисунке 8.6.

Рисунок 8.6 - Диалоговое окно инструмента редактирования

После редактирования схема станет, например, такой, как на рисунке 8.7.

Рисунок 8.7 - Отредактированные элементы схемы

Значение параметра «Линия» в окне редактирования должно быть одинаковым для элементов, находящихся в одной цепи. В данном случае это значение равняется 1, для элементов с названием «РТО» и «РПЗ» и 2 - для элементов «РПЗ1» и «ПМО».

Идентификатор реле (id) назначается автоматически, идентификатор реле - от его названия и id реле, на котором он находится, только контакт обязательно должен содержать в своем названии название реле, на котором он находится.

Два инструмента «Элемент» и «Очистить» нужны для того, чтобы стирать элементы со схемы: первый - для удаления одиночного элемента, второй - для полного стирания схемы и возвращения рабочей области в исходное состояние.

Чтобы сохранить полученную схему нужно в меню “File” выбрать пункт меню “Save File”, как на рисунке 8.8.

Рисунок 8.8 - Меню сохранения схемы в файл

Тогда откроется диалог сохранения схемы в файл своего формата, как показано на рисунке 8.9. Формат можно выбрать только заданный, то есть .sch, если же сохранить схему в любом другом формате, то программа-имитатор не сможет ее корректно открыть.

Рисунок 8.9 - Диалоговое окно сохранения схемы в файл

Этот файл можно открыть в программе-имитаторе работы схемы, либо в программе-редакторе, чтобы отредактировать при необходимости. Для этого нужно в меню “File” выбрать пункт меню “Open File”. Откроется такое же окно выбора файла и выбрать можно будет только файлы формата .sch.

Для того, чтобы продемонстрировать работу схемы РЗА необходимо запустить программу schema.wlua. Откроется такое окно, как на рисунке 8.10.

Чтобы открыть схему нужно в меню «Файл» выбрать пункт «Открыть», как показано на рисунке 8.11.

В этом случае откроется диалоговое окно, аналогичное окну загрузки в программе-редакторе. Рисунок 8.12.

Файлы в формате .sch являются файлами-сохранениями схем для данной программы. При открытии такого файла в программе-имитаторе отобразится схема, которая в этом файле сохранена. Рисунок 8.13.

Рисунок 8.10 - Изначальное состояние программы-имитатора

Рисунок 8.11 - Меню «Файл» программы-имитатора

Рисунок 8.12 - Диалоговое окно открытия файла с сохраненной схемой

Рисунок 8.13 - Схема, открытая в программе-имитаторе

При нажатии на контакт правой кнопкой мыши данный контакт замкнется, на реле будет подано напряжение, то есть оно станет активно и его контакты инвертируют свое нормальное состояние. Также будет выведено сообщение о сработавшей защите, как на рисунке 8.14. Если отпустить правую кнопку мыши, тогда контакты вернутся в исходное состояние.

Рисунок 8.14 - Демонстрация срабатывания схемы

Если же контакт будет нажат левой кнопкой мыши, тогда сработает только этот контакт и его состояние будет зафиксировано до следующего нажатия левой кнопкой мыши на этот же контакт.

При нажатии правой кнопкой мыши на реле подтянутся его контакты и схема сработает дальше. Рисунок 8.15.

Рисунок 8.15 - Срабатывание реле «РПЗ»

Здесь правой кнопкой мыши нажата реле «РПЗ» и сработал ее контакт «РПЗ1». Если бы было больше контактов, то сработали бы все контакты, которые на ней находились бы и так с каждым реле.

ЗАКЛЮЧЕНИЕ

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