Сборник 70 студ конференции БГТУ

361

3.Методы Debug.Fail и Trace.Fail, которые всегда прерывают выполнение программы и выводят сведения.

В дополнение к программному выводу приложения в окне Вывод могут отображаться сведения о следующих объектах:

1.Загруженные или выгруженные модули отладчика.

2.Вызванные исключения.

3.Завершившиеся процессы.

4.Завершившиеся потоки.

Утверждения в управляемом коде

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

C++ не поддерживает методы класса Debug. В случае C++ такого же результата можно добиться с помощью класса Trace в сочетании с условной компиляцией, например: #ifdef DEBUG... #endif.

Метод Debug.Assert

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

int IntegerDivide ( int dividend , int divisor )

{Debug.Assert ( divisor != 0 ); return ( dividend / divisor ); }

Листинг 1. Пример использования Debug.Assert

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

Побочные эффекты метода Debug.Assert

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

Debug.Assert (meas(i) != 0 );

Листинг 2. Неверное использование Debug.Assert

Такое использование метода Debug.Assert на первый взгляд может показаться безопасным, но предположим, например, что функция meas обновляет счетчик при каждом вызове. При сборке версии для выпуска вызов функции meas исчезнет, а значит, счетчик обновляться не будет. Это и есть пример функции, имеющей побочный эффект. Удаление вызова функции, имеющей побочные эффекты, может создать ошибку, которая проявится только в

362

версии программы для выпуска.Чтобы избежать подобных проблем, не следует помещать вызовы функций в оператор метода Debug.Assert. Вместо этого следует использовать временную переменную:

temp = meas( i ); Debug.Assert ( temp != 0 );

Листинг 3. Верное использование Debug.Assert

Методы Trace.Assert и Debug.Assert принимают до трех аргументов. Первый аргумент является обязательным и задает условие, которое требуется проверить. Если вызвать метод Trace.Assert(Boolean) или Debug.Assert(Boolean) только с одним аргументом, то метод Assert проверит условие и, если оно ложно, выведет содержимое стека вызовов в окно Вывод. В следующем примере показаны методы Trace.Assert(Boolean) и Debug.Assert(Boolean).

Второй и третий аргументы, если они присутствуют, должны иметь строковый формат. Если метод Trace.Assert или Debug.Assert вызывается с двумя или тремя аргументами, первым аргументом является условие. Метод проверяет условие и, если результат ложен, выводит вторую и третью строки.

Работа выполнена под руководством доц. каф. «Информатика и программное обеспечение» Е.А. Белова

Е.А. Лупачев

ИССЛЕДОВАНИЕ ЭФФЕКТИВНОСТИ МЕТОДОВ ВНЕШНЕГО ХЕШИРОВАНИЯ

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

Результаты, полученные лично автором: сравнены производительности линейного и спирального хеширования при линейном распределении данных.

Целью моего исследования является анализ производительности линейного и спирального хеширования и их сравнение при линейном распределении данных.

Вначале работы предполагалось, что спиральное хеширование при добавлении большого массива данных будет работать быстрее, чем линейное.

Тесты проводились для каждого вида хеширования при начальном объёме таблиц в 2 блока по 2 записи в каждом с различным количеством информации (5, 10, 50, 100, 150 записей) по 3 раза при линейном распределении данных. Время выполнения программы в каждом случае вычислялось как среднее арифметическое из трех полученных значений.

Врезультате было выявлено, что на добавление каждого элемента в любом случае тратится равное количество времени. Математическая сложность добавления: 2*m+3, где m – длина записи.

364

работоспособности программы на больших объёмах данных при линейном распределении данных.

Работа выполнена под руководством доц. каф. «Информатика и программное обеспечение» А.О. Трубакова

Р.М. Маркелов

ИНТЕЛЛЕКТУАЛЬНЫЙ СОВЕТУЮЩИЙ МОДУЛЬ ДЛЯ РЕГИОНАЛЬНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ

СИСТЕМЫ

Объект исследования: интеллектуальный советующий модуль, осуществляющий помощь пациенту при выборе специальности врача.

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

Врамках Федерального проекта «Электронная медицина» в 2010 г. в Брянской области начал свою работу Портал государственных медицинских услуг napriem.info. В настоящий момент данный портал поддерживает работу

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

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

Общий принцип работы модуля следующий: пациенту предлагается в интерактивном режиме ответить на ряд вопросов относительно беспокоящих его симптомов. Вопросы могут быть связаны с типом симптома и его локализацией (например, местом возникновения боли), частотой и характером проявления, степенью выраженности и др. На основе полученных ответов, а также анамнеза жизни пациента (содержащего информацию об условиях его проживания и характере трудовой деятельности) и данных его электронной медицинской карты (хранящейся на выделенном сервере Территориального фонда обязательного медицинского страхования Брянской области и доступной порталу napriem.info по защищенному каналу), подсистема, используя механизм вероятностного вывода, определяет наиболее вероятные причины заявляемых пациентом симптомов, и в соответствии с этим выдает рекомендации о том, к врачу какой специальности следует обратиться.

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

365

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

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

Поскольку требуется определение широкого спектра специалистов, то было принято решение использовать БС иерархической структуры (рис. 1). На верхнем уровне расположена родительская сеть, в задачи которой входит определение группы заболеваний (заболевания сердца, легких, печени и т.д.). По результатам определения группы заболеваний осуществляется выбор конкретной специальности врача. Для этого используется одна из дочерних сетей.

Рис. 1. Иерархическая структура Байесовой сети

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

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

366

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

Работа выполнена под руководством зав. каф. «Информатика

ипрограммное обеспечение» доц. А.Г. Подвесовского

идоц. каф. «Информатика и программное обеспечение» Д.Г. Лагерева

А.С. Марочкин

ОСНОВЫ МОДЕЛИ ПРОГРАММИРОВАНИЯ WINRT

Объект исследования: компонентное API WinRT.

Результаты, полученные лично автором: проанализированы некоторые особенности программирования с использованием WinRT, сделаны соответствующие выводы.

Вследствие появления новых типов устройств, технологий и концепций взаимодействия с пользователем, компания Microsoft разработала, абсолютно отличающуюся от других версий, Windows 8, с качественно новыми требованиями. Специально для этой версии Windows было разработано компонентное API WinRT.

Основным требованием к Windows 8 при его создании была скорость. Поэтому, при разработке WinRT, Microsoft следовал концепции, что любая операция длительностью более 50мс должна быть асинхронной. Это объясняет повсеместное использование асинхронности в WinRT.

Использование асинхронности предполагает усложнение программного кода и логики программы. (Листинг 1.)

367

}

Листинг 1. Иcпользование асинхронности в WinRT.

В данном примере показан обработчик события нажатия клавиши, при котором происходит асинхронная обработка данных. Можно заметить, что в метод ThreadPool.RunAsync передается наша процедура Compute, которая асинхронно обработает необходимые данные. Далее заполняется делегат Completed. В нем содержится тот код, который будет выполнен после завершения работы асинхронной процедуры. Эти кодом может быть либо функция обратного вызова, либо лямбда выражение. Следует отметить, что в примере, в описанной лямбда функции, используется объект ядра CoreDispatcher для корректной обработки возврата в поток пользовательского интерфейса. Как можно заметить данный код выглядит громоздко и далеко не с первого раза понятно, какие действия он производит.

Именно поэтому Microsoft, специально для языков C# и Visual Basic, ввели ключевое слово await.(Листинг 2.)

368

}

catch (Exception exc) { btnDoWork.Content = exc.Message; }

}

Листинг 2. Использование ключевого слова await.

Данное слово говорит о том, что все операции, написанные ниже слова await, будут выполнены после завершения выполнения асинхронной операции обработки данных. Поэтому в сигнатуре метода btnDoWork_Click мы видим ключевое слово async. Данное слово сообщает компилятору о том, что данный метод следует компилировать с использованием конечного автомата. Это позволяет методу останавливать и продолжать свою работу в нужные моменты исполнения кода. Использование данных ключевых слов сделало возможным создание такого кода, который мы написали, если бы не использования асинхронность. Также данное слово освобождает нас от работы с объектами ядра типа СoreDispatcher.

Из всего вышеперечисленного можно сделать следующие выводы:

•Новый интерфейс – Метро;

•Более высокая эффективность за счет асинхронности;

•Возможность использования различных языков программирования;

•Создание универсальных приложений для Windows и Windows Phone; К минусам можно отнести лишь одно:

•Усложнение программного кода, как следствие повсеместного использования асинхронности.

Работа выполнена под руководством доц. каф. «Информатика и программное обеспечение» Е.А. Белов

А.С. Марочкин

ИССЛЕДОВАНИЕ ЗАВИСИМОСТИ ЭФФЕКТИВНОСТИ ИНДЕКСИРОВАНИЯ ИНФОРМАЦИИ ДВИЖУЩИХСЯ ОБЪЕКТОВ ОТ РАЗЛИЧНЫХ ФАКТОРОВ

Объект исследования: STR-Дерево.

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

Проблема индексирования данных движущихся объектов является одной из важнейших задач. В данной работе были проведены исследования по анализу, программированию и замерам такого метода как STR-Дерево. Были проведены замеры времени индексирования различного количества входных данных (участков траекторий) и построен график зависимости (Рис 1).

369

Рис.1. Зависимость времени индексирования от объема входных данных

Из полученных данных можно сделать вывод, что с увеличением количества входных данных скорость работы данного алгоритма заметно падает. Производились замеры времени обработки пространственного запроса при различном количестве проиндексированных объектов (Рис.2).

Рис.2. Зависимость времени обработки запроса от количества проиндексированных данных.

Для построения данного графика использовался запрос одинакового объема (в данном случае 1000х1000 единиц координат) для всех объемов входных данных. В тестовом примере данный запрос содержал 1000 отрезков траектории заданного объекта. Из полученных результатов видно, что график стремиться к константной сложности т.к. колеблется вокруг точки со значением 0,0025. На основании этого можно утверждать, что количество входных данных практически не влияет на время обработки запроса.

Далее были проведены замеры объемов памяти необходимых для индексирования и хранения различных объемов входных данных (Рис.3.). Как можно заметить, данный метод достаточно требователен к памяти.

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

370

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

Рис.3. Зависимость объемов памяти от объема входных данных.

Работа выполнена под руководством доц. каф. «Информатика и программное обеспечение» А.О. Трубакова

Д.С. Морозов СРАВНИТЕЛЬНЫЙ АНАЛИЗ ЛИНЕЙНОГО ХЕШИРОВАНИЯ И

ЛИНЕЙНОГО ХЕШИРОВАНИЯ С ЧАСТИЧНЫМ РАСШИРЕНИЕМ

Объект исследования: линейное хеширование и линейное хеширование с частичным расширением.

Результаты, полученные лично автором: сравнительные характеристики эффективности алгоритмов линейного хеширования и линейного хеширования с частичным расширением.

Цель данной работы изучить алгоритмы линейного хеширования и линейного хеширования с частичным расширением; реализовать их и исследовать эффективность.

Первый критерий сравнения – среднее количество перестановок. Задачей этого теста являлось сравнение быстродействия алгоритмов на произвольных данных. Было сгенерировано 50000 случайных натуральных чисел, через каждую 1000 элементов для каждого алгоритма было выявлено число перестановок. В результате выяснилось, что число перестановок у линейного хеширования с частичным расширением немного меньше чем у линейного хеширования, в среднем на (68,56) перестановок.

Второй критерий сравнения – среднее количество блоков в цепочке. Протестированы одинаковые для обоих алгоритмов наборы данных из 10, 50 и 100 тысяч случайных наборов натуральных чисел. В ходе теста выяснилось, что среднее количество блоков в цепочке одинаковое и равно 3.