Материал: Создание демонстрационного прототипа системы поддержки принятия решений в области проектирования радиоустройств

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

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

Генерируют возможные варианты конструкторских решений.

Осуществляют оценку этих вариантов и выбирают лучший.

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

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

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

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

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

Теоретические исследования в области разработки первых систем поддержки принятия решений проводились в технологическом институте Карнеги в конце 50-х начале 60-х годов XX века. Объединить теорию с практикой удалось специалистам из Массачусетского технологического института в 60-х годах. В середине и конце 80-х годов XX столетия стали появляться такие системы, как EIS, GDSS, ODSS. В 1987 годукомпания Texas Instruments разработала Gate Assignment Display System для United Airlines. Это позволило значительно снизить убытки от полетов и отрегулировать управление различными аэропортами, начиная от Международного аэропорта O’Hare в Чикаго и заканчивая Stapleton в Денвере, штат Колорадо. В 90-х годах сфера возможностей систем поддержки принятия решений расширялась благодаря внедрению хранилищ данных и инструментов OLAP (аналитическая обработка в реальном времени). Появление новых технологий отчетности сделало систему поддержки принятия решений незаменимой в менеджменте.

1.4 Постановка задачи на проектирование системы поддержки принятия решений

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

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

Рис. 3 - Схема программы

Использование системы поддержки принятия решений при проектировании систем радиосвязи позволит:

сократить время на их разработку на стадии эскизного проектирования,

выбрать оптимальное решение из множества возможных,

снизить риск ошибок, возникающих из-за недостаточной подготовки конструктора,

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

2. Проектирование системы поддержки принятия решений

.1 Этапы создания экспертных систем

Стадии существования (этапы развития) системы поддержки принятия решений схожи со стадиями (этапами) экспертных систем, и представляют собой[6]:

Демонстрационный (для представления возможностей, выбранных архитектурных и программных решений). Разработка занимает 2-4 месяца, количество исполняемых утверждений 15-30.

Исследовательский (совершенствование архитектуры системы поддержки принятия решений и базы знаний). Разработка занимает 2-3 месяца, при наличии демонстрационного прототипа, количество исполняемых утверждений 40-60.

Действующий. Разработка системы от начала до стадии действующей системы занимает 6-9 месяцев, количество исполняемых утверждений около 100.

Промышленный (реальное применение в пределах организации, как правило для которой велась разработка системы поддержки принятия решений). Разработка системы от начала до стадии промышленного прототипа требует 12-18 месяцев, 150-200 исполняемых утверждений.

Коммерческий (широкое применение во многих организациях). Разработка занимает 1,5-2 года.

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

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

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

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

Реализация. Создание прототипа системы поддержки принятия решений.

Тестирование. Выявление ошибок.

Опытная эксплуатация.

.2 Идентификация проблемы

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

Генерация возможных вариантов конструкторских решений (снижение вероятности ошибки ввиду недостаточной подготовки конструктора).

Оценка вариантов решений и выбор оптимального (снижение вероятности ошибки ввиду субъективности выбираемого конструктором решения).

Результатами работы разрабатываемой системы поддержки принятия решений должны быть следующие показатели:

Сокращение времени проектирования систем радиосвязи на этапе эскизного проекта.

Снижение вероятности ошибок конструктора на этапе эскизного проекта.

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

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

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

. Символьные языки программирования (например, Lisp, Prolog и их разновидности). Эти инструментальные средства в последнее время, как правило, не используются в реальных приложениях в связи с тем, что они плохо приспособлены к объединению с программами, написанными на языках традиционного программирования.

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

. Оболочки экспертных систем общего назначения, содержащие все программные компоненты, но не имеющие знаний о конкретных предметных средах. Средства этого и последующего типов не требуют от разработчика приложения знания программирования. Примерамиявляются Expert Developer Pro,ЭКО, Leonardo, Nexpert Object, Kappa идр. Стоит отметить, что в последнее время термин «оболочка» заменяют на более широкий термин «среда разработки». Если хотят подчеркнуть, что средство используется не только на стадии разработки приложения, но и на стадиях использования и сопровождения, то употребляют термин «полная среда». Примерами таких средств для создания статических экспертных систем являются: Nexpert Object, ProKappa, ART*Enterprise, Level 5 Object идр.

В результате анализа инструментальных средств была выбрана среда разработки ExpertDeveloperPro. Система позволяет создавать базу знаний, структурированную как направленный ациклический граф.Направленный ациклический граф - ориентированный граф, в котором отсутствуют пути кончающиеся и начинающиеся в одной и той же вершине, является обобщением дерева, а точнее их объединения - леса. Данное инструментальное средство можно отнести к полным средам разработки, так как оно используется на всех этапах жизни системы поддержки принятия решений (создание базы знаний, использование и отладка системы). Система имеет открытый исходный код, и написана на языке C++ с использованием пакета Microsoft Foundation Classes.

Пакет Microsoft Foundation Classes - библиотека на языке С++, созданная Microsoft с целью облегчить разработку GUI-приложений для Microsoft Windows путем создания каркаса приложения,автоматически создаваемого по типовому макету интерфейса. Что позволяет избавить программиста от рутинных действий, таких как отработка оконных событий, пересылка данных между внутренними буферами и тому подобное. Разработчику после получения каркаса остается только вписать код в места, где будут требоваться специальные действия.

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

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

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

Рис. 4 - Экран работы с системой

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

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

Недостатками системы является отсутствие отображения пройденных вопросов, и двоичный характер ответов.

Извлечение знаний

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

.2.1 Структура радиоприемных устройств

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