
- •Министерство образования и науки Российской Федерации Московский государственный институт электронной техники (технический университет) Факультет мп и тк
- •«Программный комплекс многокритериальной оптимизации систем на основе мультихромосомных моделей и генетических алгоритмов»
- •Содержание
- •Перечень сокращений
- •Введение
- •1. Специальный раздел
- •1.1. Исследовательская часть
- •1.1.1. Обзор существующих программ для оптимизации
- •1.1.3. Информационные потребности пользователя
- •1.2. Конструкторская часть
- •1.2.1. Требования, предъявляемые к системе
- •1.2.2. Структура входных и выходных данных
- •1.2.3. Конфигурация технических средств
- •1.2.4. Модули комплекса
- •1.2.5. Общий алгоритм работы программы
- •1.2.6. Иерархия классов
- •1.2.7. Переменные в выражениях и их использование в программе
- •1.2.8. Основные алгоритмы и особенности программной реализации
- •1.2.9. Проверка отказоустойчивости программы
- •1.2.10. Проверка работы комплекса на контрольных примерах
- •1.3. Выводы
- •2. Технологический раздел
- •2.1. Использование стандартных библиотек
- •2.1.1. Библиотека stl
- •2.1.2. Библиотека mfc
- •2.1.3. Применение библиотек stl и mfc в программе
- •2.1.4. Средство ClassWizard
- •2.2.2. Встроенные средства языка для отладки программ
- •2.2.3. Отладка программного кода, содержащего stl и mfc
- •2.4. Приёмы объектно-ориентированного проектирования
- •2.4.1. Применение паттернов проектирования в программе
- •2.5. Выводы
- •3. Организационно-экономический раздел
- •3.1. Метод анализа иерархий
- •3.2. Метод парных сравнений.
- •3.2.1. Определение собственных векторов
- •3.3. Применение метода для выбора среды программировани
- •3.3.1. Характеристики сред программирования
- •3.3.2. Таблица сравнений важности критериев
- •3.3.3. Таблицы попарного сравнения сред разработки по каждому критерию
- •3.4. Результаты применения метода
- •3.5. Выводы
- •4. Производственная и экологическая безопасность
- •4.1. Опасные и вредные факторы, воздействующие на программиста
- •4.1.1. Микроклимат рабочей зоны программиста
- •4.1.2. Воздействие шума на программиста. Защита от шума
- •4.1.3. Уровень напряжённости электромагнитного поля
- •4.1.4. Электробезопасность. Статическое электричество
- •4.1.5. Освещенность рабочего места
- •4.2. Заключение
- •Заключение
- •Список литературы
- •Исходный текст программы
- •Результаты испытаний
- •Руководство оператора
- •Аннотация
- •2. Условия выполнения программы
- •2.1. Климатические условия эксплуатации
- •2.2. Состав аппаратных и программных средств
- •3. Требования к персоналу (пользователю)
- •4.2.2. Выполнение функции сохранения модели в файл
- •4.2.3. Выполнение функции ввода информации о системе
- •4.2.4. Выполнение функции задания различных параметров системы
- •4.2.5. Правила записи выражений
- •4.2.6. Выполнение функции задания параметров генетических алгоритмов
- •4.2.7. Выполнение функции поиска решения
- •5.3. Ошибки при проверке модели
- •5.4. Ошибки во время поиска решения
2.2.2. Встроенные средства языка для отладки программ
Язык программирования Visual C++ 6.0 содержит специальные средства отладки [8]. дополняющие собой инструментальные средства отладки среды. Остановлюсь на некоторых из них, которые применялись при отладке разработанного программного комплекса.
Отладочные макросы
ASSERT – используется для проверки логических условий, которые должны выполняться в данной точке программы. Например, в функцию передаётся указатель и предполагается, что он всегда будет иметь ненулевое значение. Однако для предотвращения возможных ошибок это следует проверить. С этой целью перед использованием данного указателя следует вызвать макрос ASSERT: ASSERT (pObject) Всякий раз, когда логическое выражение, переданное в качестве аргумента макросу ASSERT, будет принимать значение FALSE, выполнение приложения будет останавливаться и на экран будет выводиться окно с сообщением об ошибке. После этого можно перейти в текст программы для отладки.
TRACE – служит для вывода диагностических сообщений. Обычно заранее известны потенциальные места возникновения ошибок. Например, многие функции возвращают своим значением коды ошибок (в том числе и код такой специфической «ошибки», как успешное завершение). Эти коды возврата можно игнорировать, а можно и вывести их значения, чтобы была возможность проанлизировать выполнение программы. Именно для этих целей и применяется макрос TRACE.
Эти макросы выполняются только в отладочной версии программы. В окончательной версии (т.н. release), в которой не определена константа _DEBUG, данные макросы не выполняют никаких действий. Это позволяет оставлять их в тексте программы без опасения, что они замедлят выполнение окончательной версии приложения или будут выдавать непонятные сообщения конечному пользователю.
OutputDebugString() и отладочная консоль
В некоторых случаях для того, чтобы посмотреть значения переменных, не желательно или невозможно прерывать выполнение программы. Например, для многонитевого приложения или для участков кода, критичных ко времени выполнения. Более того, зачастую отладочная и окончательная версия программы ведут себя по-разному. И даже если отладочная версия работает без ошибок, то в окончательной версии они могут появиться. И здесь уже не воспользуешься отладчиком.
Для вывода какой-либо информации из приложения в этих случаях используется функцию OutputDebugString(), которая пишет в отладочную консоль – специальную консольную утилиту, содержащуюся в Visual Studio C++ 6.0 SDK (dbmon.exe). Эта функция принимает в качестве аргумента строку, которую и выводит в отладочную консоль. Применяя эту функцию в окончательной версии программы, можно локализовать местоположение ошибки последовательным приближением. На рис.2.7 показано использование отладочной консоли при отладке графического редактора в окончательной версии программы.
Рис 2.7 Пример отладки с использованием отладочной консоли
2.2.3. Отладка программного кода, содержащего stl и mfc
Так как библиотеки STL и MFC уже давно разработаны и отлажены, число ошибок в этих библиотеках минимально. Поэтому все ошибки в программах, использующих эти библиотеки, заключаются в неправильном использовании классов из этих библиотек.
Серьёзная проблема, с которой постоянно сталкиваются программисты – утечка памяти. Эта проблема может возникнуть в любом приложении. не обязательно в том. которое использует библиотеки STL или MFC. Однако использование специальных классов MFC даёт возможность локализовать место, в котором происходит неконтролируемая утечка памяти. Речь идёт о классе CMemoryState. Это класс обладает рядом методов, которые позволяют зафиксировать количество занятой памяти в любой момент времени, вычислить разницу в занимаемой памяти между двумя контрольными точками и вывести дамп памяти в окно отладки.
С отладкой кода с использованием библиотеки STL дела в Visual Studio C++ обстоят не так хорошо. Эта среда не имеет специальных средств для отладки такого кода. Например, окно Quick Watch не поможет, если необходимо просмотреть все элементы какого-нибудь контейнера, скажем, list. Для этого придётся вставлять в код отладочный цикл, в котором последовательно выбираются элементы из контейнера с помощью итератора. Код ниже иллюстрирует этот подход:
std::list<int> myList; std::list<int>::iterator it; for (it = myList.begin(); it != myList.end(); it++) { // теперь можно посмотреть значение текущего элемента с помощью *it } |
Тонким моментом при использовании библиотеки STL является применение контейнеров указателей. Дело в том, что при удалении указателя из контейнера, память, динамически выделенная для этого указателя, автоматически не освобождается. Поэтому следует быть особенно внимательным при работе с такими контейнерами, особенно если они создаются на стеке. Для обнаружения утечек памяти как раз подойдёт класс библиотеки MFC CMemoryState, описанный выше.
Типичной ошибкой при использовании классов STL является выход за границы. Следующий фрагмент кода иллюстрирует подобную ситуацию:
std::vector<double> myVector; myVector.push_back(rand() / RAND_MAX); int iPos; cin >> iPos; cout << myVector[iPos]; |
В случае, если значение переменной iPos будет отличным от 0, myVector[iPos] вернёт совершённо неожиданное значение. Найти такую ошибку не очень-то и просто. Для уменьшения вероятности появления ошибок подобного рода можно воспользоваться следующими рекомендациями. Во-первых, переменную iPos следует объявлять, как беззнаковое целое. А во-вторых, перед обращением к какому-либо элементу контейнера сравнить значение индекса и количество элементов в контейнере. Для получения количества элементов нужно вызвать функцию size(), которая присутствует в интерфейсе всех контейнеров библиотеки STL.