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

351

-расход пара на подогреватели высокого давления, кг/с(D4, D5, D6, D7); -расход пара в конденсатор, кг/с (Gк);

- возврат конденсата с производства, кг/с(Dвк);

-количество химически очищенной воды, подаваемой в деаэратор (Dхов); -потери конденсата в деаэраторе (Dут);

-расходы выпара из сепараторов непрерывной продувки (Dс1, Dс2). Возникает система из 17 линейныхуравнений – балансовые уравнения

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

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

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

Часть неизвестных находятся из системы однозначно, а часть зависят от указанных двух параметров.

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

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

О.К. Левкина

АНАЛИЗ БИБЛИОТЕК СОЗДАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ПРИЛОЖЕНИЙ WINDOWS

Объект исследования: библиотеки создания пользовательского интерфейса Microsoft Foundation Class, Qt, Windows Forms, Windows Presentation Foundation и wxWidgets.

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

Microsoft Foundation Class (MFC) – это графический инструментарий для Windows. Имеет смешанный C/C++ интерфейс.

Qt – кросс-платформенная библиотека, графический С++ инструментарий.

Windows Forms является частью Microsoft .NET Framework. Создает обёртку для существующего Win32 API в управляемом коде.

Windows Presentation Foundation (WPF) — графическая подсистема в составе .NET Framework, использующая язык XAML.

wxWidgets — это кроссплатформенная библиотека инструментов с открытым исходным кодом.

Архитектура. Библиотека MFC требует от программиста использования архитектуры «документ-представление» и шаблонов. Шаблоны имеют фиксированную структуру, и поэтому сложно расширить их возможности. Шаблоны также создают вид, но не имеют к нему доступа.

352

В wxWidgets также реализована модель «документ-представление». Qt не ограничивает программиста какой-либо моделью дизайна.

Windows Forms рассматривается как замена MFC, но не предлагает парадигму, сравнимую с архитектурой «документ-представление».

WPF включает новую модель построения приложений, основанную на

DirectX.

Модель дизайна. MFC – это библиотека, имеющая псевдообъектный дизайн.

Qt построена на объектно-ориентированной архитектуре. Её инструментарий имеет согласованное наследование, организацию классов и методов.

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

XAML.

wxWidgets активно использует концепции ООП.

Обработка сообщений. Работа MFC основана на механизме сообщений. Windows посылает программе тысячи сообщений. Непросто узнать, как их использовать.

Работа Qt базируется на механизме, основанном на передаче сигналов и их приёме слотами. Сигнал вырабатывается, когда происходит определенное событие. В ответ на сигнал вызывается слот. Число сигналов обычно невелико, и все они хорошо документированы.

Windows Forms, как и MFS, основан на механизме сообщений.

WPF предоставляет класс ComponentDispatcher, который определяет простой протокол для выполнения цикла обработки сообщений.

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

Компоновка элементов. MFC не обеспечивает компоновку элементов управления внутри окна: это создает проблемы при желании сделать окно изменяемого размера.

Qt предлагает инструмент Qt Designer. С помощью него можно корректировать свойства элементов управления и подключать сигналы к слотам.

Основная система компоновки Windows Forms использует фиксированные координаты.

ВWPF компоновка разделяется разными контейнерами.

Приложение в wxWidgets состоит из различных виджетов. Компоновка осуществляется абсолютным позиционированием и классификаторами.

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

Строки в Qt являются объектами класса QString, который изначально поддерживает Юникод.

Windows Forms, WPF и wxWidgets полностью поддерживают Юникод.

353

Язык XAML, использующийся в WPF, поддерживает Юникод UTF-16. Вывод. Анализируя все вышеперечисленные возможности и недостатки

библиотек, можно сделать вывод, что наиболее гибкими библиотеками являются Qt и WPF.

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

А.В. Ломаченков

ЭВОЛЮЦИЯ ИНТЕРФЕЙСА ПРОГРАММИРОВАНИЯ WINAPI

Объект исследования: интерфейс программирования WinAPI. Результаты, полученные лично автором: выявлены принципы развития

интерфейса программирования Windows API, сделаны выводы на основе этих принципов.

Само по себе понятие API (application programming interface) означает набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах.

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

Если говорить о Windows API, то получилось так, что изначально интерфейс был спроектирован для использования в программах, написанных на языке C (или C++). Работа через Windows API — это наиболее близкий к системе способ взаимодействия с ней из прикладных программ. Функциональность, предоставляемая Windows API, может быть разделена на восемь категорий: Base Services, Advanced Services, Graphics Device Interface, User Interface, Common Dialog Box Library, Common Control Library, Windows Shell, Network Services.

Первая версия Windows API называется Win16 и представляет собой 16разрядную версию, используемую в Windows 3.1. Изначально назывался просто Windows API, затем стал называться Win16 для отличия от Win32. Функционал Win16 API расположен в корне операционной системы, в

файлах: kernel.exe (or krnl286.exe or krnl386.exe), user.exe and gdi.exe.

Несмотря на расширение .exe, на самом деле они являются dll-библиотеками (dynamically linked library - динамически подключаемая библиотека).

Вторая, 32-разрядная версия, называется Win32 и используется в

Windows 95 и Windows NT. Win32 является надмножеством для Win16 (т.е.

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

354

принципе похожими, оба интерфейса все же отличаются друг от друга. Win32 поддерживает 32-разрядную линейную адресацию, тогда как Win16 работает только с 16-разрядной сегментированной моделью памяти. Это привело к тому, что некоторые функции были модифицированы таким образом, чтобы принимать 32-разрядные аргументы и возвращать 32разрядные значения. Часть из них пришлось изменить с учетом 32-разрядной архитектуры. Была реализована поддержка потоковой многозадачности, новых элементов интерфейса и прочих нововведений Windows.

Так как Win32 поддерживает полностью 32-разрядную адресацию, то логично, что целые типы данных (intergers) также объявлены 32-разрядными. Это означает, что переменные типа int и unsigned будут иметь длину 32 бита, а не 16, как в Windows 3.1. Если же необходимо использовать переменную или константу длиной 16 бит, они должны быть объявлены как short. Следовательно, при переносе программного кода из 16-разрядной среды необходимо убедиться в правильности использования целочисленных элементов, которые автоматически будут расширены до 32 битов, что целочисленных элементов, которые автоматически будут расширены до 32 битов, что может привести к появлению побочных эффектов.

Другим следствием 32-разрядной адресации является то, что указатели больше не нужно объявлять как near и far. Любой указатель может получить доступ к любому участку памяти. В Windows 95 и Windows NT константы near и far объявлены (с помощью директивы #define) пустыми version of Win32 shipped with Windows 95 сперва называлась as Win32c, with the "c" standing for "compatibility (совместимость)", but this term Microsoft отказались в пользу of Win32.

Win32 — самая популярная ныне версия. Базовые функции этого API

реализованы в DLL kernel32.dll и advapi32.dll; базовые модули GUI — в user32.dll и gdi32.dll. Win32 появился вместе с Windows NT и затем был перенесён (в несколько ограниченном виде) в системы серии Windows 9x. В современных версиях Windows, происходящих от Windows NT, работу Win32 GUI обеспечивают два модуля: csrss.exe (Client/Server Runtime Subsystem),

работающий в пользовательском режиме, и win32k.sys в режиме ядра. Работу же системных Win32 API обеспечивает ядро - ntoskrnl.exe

Win32s — подмножество Win32, устанавливаемое на семейство 16разрядных систем Windows 3.x и реализующее ограниченный набор функций Win32 API для этих систем. Буква "s" означает "subset" (подмножество).

Win64 — 64-разрядная версия Win32, содержащая дополнительные функции для использования на 64-разрядных компьютерах. Win64 API можно найти только в 64-разрядных версиях Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows Server 2008 R2 и Windows 7.

Любопытно отметить, что архитектура, заложенная 20 лет назад, работает до сих пор. И, как показывают факты, должна просуществовать еще долгое время. Примерно 90% программного обеспечения, написанного под Windows — написано на WinAPI, так что отказаться от этой архитектуры

355

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

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

А.В. Ломаченков

АНАЛИЗ ЗАВИСИМОСТИ ПРОИЗВОДИТЕЛЬНОСТИ СПИРАЛЬНОГО ХЕШИРОВАНИЯ ОТ ХАРАКТЕРА РАСПРЕДЕЛЕНИЯ ДАННЫХ

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

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

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

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

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

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

При линейном распределении данных на каждое расщепление будет затрачиваться одинаковое количество времени, при этом в новый блок переносится половина записей из расщепляемого блока, т.е. на каждое расщепление требуется t*m времени, где t –время, затраченное на перенос записи из расщепляемого блока в новый, m – количество записей в расщепляемом блоке. При линейном распределении каждый блок будет занят наполовину, и на каждом расщеплении будет добавляться только один новый блок.

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

356

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

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

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

Практические результаты исследования представлены ниже в виде графиков (рис.1).

Рис. 7. Производительность спирального хеширования

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

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

358

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

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

В рамках своей выпускной курсовой работы я представлю мобильное приложение, которое попытается улучшить способ информирования студентов. Один из разделов приложения, является раздел «Новости», в котором находится персональная лента новостей. Т.е. все новости университета не будут идти одним потоком. Благодаря сформированным тегам студент сам решает, на какую категорию новостей подписываться и что читать. И это возможно благодаря представленному анализу текста новостей и автоматическому тегированию.

Работа выполнена под руководством асс. «Информатика и программное обеспечение» Д.Н. Пануса

К.В. Лукьянова АВТОМАТИЗИРОВАННАЯ СИСТЕМА ОБМЕНА СООБЩЕНИЯМИ

С ВОЗМОЖНОСТЬЮ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ НА ОСНОВЕ АСИММЕТРИЧНЫХ КРИПТОГРАФИЧЕСКИХ МЕТОДОВ

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

Результаты, полученные лично автором: спроектирована и разработана автоматизированная система обмена сообщениями с возможностью обеспечения безопасности на основе асимметричных криптографических методов. В рамках данной системы реализованы три алгоритма электронной цифровой подписи: RSA, ElGamal и DSA, а также хеш-функция SHA-256.

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

359

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

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

Разработанная система получила название «СоКрипто». В качестве архитектуры была выбрана клиент-серверная архитектура, так как разработанная система является веб-приложением.

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

Криптографическая подсистема включает в себя следующие модули:

модуль ЭЦП содержит реализацию алгоритмов RSA, ElGamal и DSA для добавления к сообщению ЭЦП и ее проверки;

модуль хеширования содержит реализацию алгоритма хэширования SHA-256 для контроля целостности данных.

Основными функциями системы являются: регистрация нового пользователя, авторизация уже зарегистрированных пользователей, оправка

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

Интерфейс системы и механизм обмена сообщениями реализован на языке PHP. В качестве web-сервера для разработки системы используется пакет Denwer. В его состав входит web-сервер Apache с настроенным интерпретатором PHP и СУБД MySQL, которая использовалась при реализации данной системы.

Работа с алгоритмами ЭЦП выполнена с помощью web-сервисов, реализованных на объектно-ориентированном языке программирования Java

исервера приложений GlassFish. В качестве среды разработки использовались IntelliJ IDEA 14 и Eclipse.

Система поддерживает две разновидности интерфейса: администратора

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

Интерфейс пользователя, содержит вкладки: сотрудники, сообщения, задачи и объявления.

При отправке сообщения пользователь имеет возможность отправить сообщение без подписи или подписать его при помощи одного из трех алгоритмов ЭЦП: RSA, ElGamal и DSA. Выбрав алгоритм, отправитель должен загрузить секретный ключ. После чего пользователь может отправить подписанное сообщение адресату. Подпись проверяется автоматически при открытии сообщения получателем посредством ключа, выбранного из БД.

360

Закрытый и открытый ключи генерируются системой при запросе администратора.

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

работа с сообщениями, а не с файлами;

обмен сообщениями осуществляется внутри системы и не требует сторонних программ, подобных электронной почте;

обеспечивает целостность информации и подтверждение авторства;

имеет удобный и понятный интерфейс;

является наиболее экономически выгодным вариантом.

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

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

Е.А. Лупачев

СРЕДСТВА ОТЛАДКИ ПРИЛОЖЕНИЙ WINDOWS

Объект исследования: средства отладки приложений Windows. Результаты, полученные лично автором: проанализированы некоторые способы отладки приложений Windows и разобраны более подробно классы

Debug и Trace.

В данной работе приводится описание общих проблем отладки и способов их решения для управляемых приложений или приложений, написанных на языках, предназначенных для общеязыковой среды выполнения, например Visual Basic, C#, и C++). Описанные здесь методики — методики высшего уровня.

Диагностические сообщения в окне вывода

Во время выполнения сообщения в окне вывода можно написать с помощью класса Debug или Trace; оба класса входят в библиотеку классов System.Diagnostics.Класс Debug используется, если необходимо выводить сообщение только в отладочной версии программы. Класс Trace используется в том случае, если необходимо выводить сообщение и в отладочной версии программы, и в выпускаемой.

Методы вывода

Классы Trace и Debug предоставляют следующие методы вывода:

1.Различные методы Write, которые выводят сведения без прерывания выполнения программы.

2.Методы Debug.Assert и Trace.Assert, которые прерывают выполнение программы и выводят сведения, если заданное условие не выполняется.