Дипломная работа: Исполняемое Win32 приложение

Адаптивные нечеткие системы. Классические нечеткие системы обладают тем недостатком, что для формулирования правил и функций принадлежности необходимо привлекать экспертов той или иной предметной области, что не всегда удается обеспечить. Адаптивные нечеткие системы (adaptive fuzzy systems) решают эту проблему. В таких системах подбор параметров нечеткой системы производится в процессе обучения на экспериментальных данных. Алгоритмы обучения адаптивных нечетких систем относительно трудоемки и сложны по сравнению с алгоритмами обучения нейронных сетей, и, как правило, состоят из двух стадий:

- генерация лингвистических правил;

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

Значительная часть методов обучения нечетких систем использует генетические алгоритмы. В англоязычной литературе этому соответствует специальный термин – Genetic Fuzzy Systems.

Значительный вклад в развитие теории и практики нечетких систем с эволюционной адаптацией внесла группа испанских исследователей во главе с Ф. Херрера (F. Herrera).

Нечеткие запросы. Нечеткие запросы к базам данных (fuzzy queries) – перспективное направление в современных системах обработки информации. Данный инструмент дает возможность формулировать запросы на естественном языке, например: 'Вывести список недорогих предложений о съеме жилья близко к центру города', что невозможно при использовании стандартного механизма запросов. Для этой цели разработана нечеткая реляционная алгебра и специальные расширения языков SQL для нечетких запросов. Большая часть исследований в этой области принадлежит западноевропейским ученым Д. Дюбуа и Г. Праде.

Нечеткие ассоциативные правила. Нечеткие ассоциативные правила (fuzzy associative rules) – инструмент для извлечения из баз данных закономерностей, которые формулируются в виде лингвистических высказываний. Здесь введены специальные понятия нечеткой транзакции, поддержки и достоверности нечеткого ассоциативного правила.

Нечеткие когнитивные карты. Нечеткие когнитивные карты (fuzzy cognitive maps) были предложены Б. Коско в 1986 г. и используются для моделирования причинных взаимосвязей, выявленных между концептами некоторой области. В отличие от простых когнитивных карт, нечеткие когнитивные карты представляют собой нечеткий ориентированный граф, узлы которого являются нечеткими множествами. Направленные ребра графа не только отражают причинно-следственные связи между концептами, но и определяют степень влияния (вес) связываемых концептов. Активное использование нечетких когнитивных карт в качестве средства моделирования систем обусловлено возможностью наглядного представления анализируемой системы и легкостью интерпретации причинно-следственных связей между концептами. Основные проблемы связаны с процессом построения когнитивной карты, который не поддается формализации. Кроме того, необходимо доказать, что построенная когнитивная карта адекватна реальной моделируемой системе. Для решения данных проблем разработаны алгоритмы автоматического построения когнитивных карт на основе выборки данных.

Нечеткая кластеризация. Нечеткие методы кластеризации, в отличие от четких методов (например, нейронные сети Кохонена), позволяют одному и тому же объекту принадлежать одновременно нескольким кластерам, но с различной степенью. Нечеткая кластеризация во многих ситуациях более 'естественна', чем четкая, например, для объектов, расположенных на границе кластеров. Наиболее распространены: алгоритм нечеткой самоорганизации c-means и его обобщение в виде алгоритма Густафсона-Кесселя.

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

3. ПРОЕКТИРОВАНИЕ ФУНКЦИОНАЛЬНОЙ СТРУКТУРЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

- класс CFuzzyApp, обеспечивающий функциональность динамического исполнения приложения в целом, порожденный от базового MFC-классаCWinApp;

- класс CFuzzyDlg, обеспечивающий работу с визуальными компонентами операционной среды MicrosoftWindows, порожденный от базового MFC-классаCDialog;

Класс CFuzzyApp наследуется от класса приложения CWinApp. Основной перегружаемым виртуальным методом данного класса является метод CFuzzyApp::InitInstance(). Перегрузка метода необходима для инициализации вспомогательных компонент приложения, а также для реализации связи визуального окна компонентов MSWindows с исполняемым приложением. В целом, метод CFuzzyApp::InitInstance() готовит приложение к работе.

Как известно [3], программы, работающие в среде MSWindows, имеют графический интерфейс пользователя (GUI – GraphicalUserInterface). Исходные данные поступают в программу через диалоговое окно. Например, пользователь может сообщить приложению о выборе функции, включив один из переключателей (класс CButton(BS_RADIOBUTTON, …)) или выполнив некоторое действие с другими элементами управления. Для каждого диалогового окна в приложении есть две вещи, которые необходимо разработать, – ресурсы окна и класс окна.

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

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

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

Далее в редакторе ресурсов в диалоговое окно должны быть добавлены необходимые элементы управления – кнопки, радиокнопки, поля ввода, текстовые метки, декоративные элементы (GroupBox) и элемент Picture.

Проектируемый интерфейс изображен на рисунке 3.1.

Рисунок 3.1 – Проектируемый интерфейс

Когда сформированы ресурсы окна и подготовлен класс CFuzzyDlg для окна приложения, можно создавать объект этого класса в самой программе и выводить на экран связанное с ним диалоговое окно. В рассматриваемом случае, достаточно в методе CFuzzyApp::InitInstance() вывести диалоговое окно на экран сразу после запуска приложения, используя базовый метод CDialog::DoModal() класса диалогового окна CDialog.

Отображение результатов построения функции производится в элемент Picture. Для вывода графики в Windows и в Visual C++ используется понятие контекста устройства (device context). Контекст устройства ‑ это объект класса CDC, содержащий все методы для построения изображения в окне.

Таким образом спроектированная структура программного обеспечения является адекватной решению поставленной в техническом задании задачи.

4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ

Программная реализация разработанной выше структуры приложения состоит в разработке исполняемого Win32-приложения в среде визуального программирования MSVisualStudio. Проект программного обеспечения состоит из трех классов – CFuzzyApp, CFuzzyDlg, CFuzzy_.

В классе CFuzzy_ выполняются непосредственные расчеты значений функций неопределенности. Расчеты выполняются функциями-членами[6] этого класса:

- CFuzzy_::fisTriangleMf (double x, double *params) – вычисление значений треугольной функции принадлежности;

- CFuzzy_::fisTrapezoidMf(doublex, double *params) – вычисление значений трапециидальной функции принадлежности;