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

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

Автор: Пушкин, Алексей Юрьевич

Шифр специальности: 05.13.01

Научная степень: Кандидатская

Год защиты: 2007

Место защиты: Москва

Количество страниц: 216 с. ил.

Артикул: 3361113

Автор: Пушкин, Алексей Юрьевич

Стоимость: 250 руб.

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

Содержание
ВВЕДЕНИЕ
ГЛАВА 1. ЗАДАЧА СОЗДАНИЯ И ИСПОЛЬЗОВАНИЯ В МАШИНОСТРОИТЕЛЬНЫХ САПР ПОДСИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
1.1. СОВРЕМЕННЫЙ ПОДХОД К АВТОМАТИЗАЦИИ ПРИНЯТИЯ РЕШЕНИЙ
1.2. Инструментальные и программные средства разработки программного обеспечения.
1.3. Выводы
ГЛАВА 2 МАТЕМАТИЧЕСКИЕ И ПРОГРАММНЫЕ СРЕДСТВА ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
2.1. Теория принятия решений.
2.2. Рассуждения в условиях неопределенности.
2.3. Интеллектуализированные системы.
2.4. искусственный интеллект и экспертные системы
2.5. Классификация экспертных систем.
2.6. Базы знаний.
2.7. Математические основы продукционных систем
2.8. МЕТОДЫ устранения неопределенностей и пополнения знаний.
2.8. языки программирования задач искусственного интеллекта и языки представления знаний
2.9. обзор современных разработок в области систем основанных на знаниях
2. ю. Полученные результаты исследований и внедрения программ искусственного интеллекта и
0КСППРТЫХ СИСТЕМ.
2. П. ВЫВОДЫ
ГЛАВА 3. ТЕОРЕТИЧЕСКАЯ РАЗРАБОТКА ПРОДУКЦИОННОЙ ПОДСИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИИ М111ММН1МИН1МН1ММ1МН1ММШММНН1ММ1И1МММ11М1ММ11И1Н11ИННМИШ1НМ11ММ
3.1. Состав информации и юй системы предприятия и место продукционной подсистемы в ней
3.2. Общие принципы функционирования подсистемы поддержи принятия решений.
3.3. алгоритмы работы продукционных систем
3.4. Структура подсистемы поддержки принятия решений
3.5. РЕЖИМ работы.
3.6. ВЫВОДЫ.
ГЛАВА 4. РЕАЛИЗАЦИЯ ПОДСИСТЕМЫ ПРИНЯТИЯ РЕШЕНИЙ
4.1. обоснование и выбор программнотехнических средств реализации системы
4.2. краткое описание разработанных программных средств.
4.3. применение разработанной подсистемы
4.4. Оценка возможности использования подсистемы в информационных системах общего назначения
4.5. ОСНОВНЫЕ ВЫВОДЫ И РЕЗУЛЬТАТЫ РАБОТЫ
СПИСОК ЛИТЕРАТУРЫ


Определяющее свойство подсистем заключается в том, что они могут функционировать самостоятельно, независимо от тех систем, в состав которых входят. Сложность взаимодействия между системными компонентами означает, что система не сводится просто к сумме ее составных частей. Она имеет определенные свойства, которые присущи ей именно как целостной системе. Такие интеграционные свойства не могут быть свойствами какой-либо отдельной системы. Более того, они проявляются тогда, когда система рассматривается как единое целое. Некоторые из этих свойств можно вывести из аналогичных свойств отдельных подсистем, но чаще они являются комплексным результатом взаимодействия всех подсистем и их невозможно оценить, исходя из анализа отдельных системных компонентов. В процессе формализации требований к системе и на этапе проектирования система рассматривается как совокупность компонентов и взаимосвязей между ними. Для этого используются модели системной архитектуры, которые в графическом виде представляют всю организацию системы, то есть ее компоненты и взаимосвязи между ними. Архитектура системы обычно представляется в виде блочной диаграммы (блок-схемы), где блоки соответствуют основным подсистемам, а существующие связи между подсистемами обозначаются линиями со стрелками, соединяющими отдельные блоки диаграммы. Связи могут соответствовать потокам данных, последовательности включения подсистем в работу или каким-либо другим типам зависимости. На уровне детализации система разбивается на отдельные подсистемы. Это такие компоненты, которые, исходя из предназначения подсистемы, выполняют какую-либо одну функцию. Конечно, декомпозицию подсистем можно проводить по другим признакам, например конструктивным или технологическим. Большинство аппаратных подсистем и многие программные подсистемы такие как, системы управления базами данных не разрабатываются специально для включения в состав больших систем. Часто в них встраиваются уже готовые системы. Очень немногие организации имеют возможности для проектирования производства и тестирования всех компонентов сложных больших систем. Организация-разработчик системы, которую обычно называют ведущим или генеральным подрядчиком может заключать контракты на разработку отдельных подсистем с другими субподрядчиками. Для создания больших систем группа организаций-разработчиков может создать консорциум, в который входят разработчики и поставщики всех компонентов. Модель «подрядчик-субподрядчик» минимизирует количество организаций, участвующих в реализации контракта. Субподрядчики разрабатывают и производят части системы в соответствии со спецификацией, предоставляемой ведущим подрядчиком. После завершения работ субподрядчиками система собирается из отдельных частей ведущим подрядчиком, и готовая система поставляется заказчику. В быстроразвивающсйся сфере разработки объектно-ориентированных приложений становится все труднее и труднее создавать и поддерживать приложения, обладающие высоким качеством, укладываясь при этом в разумные временные рамки. Унифицированный язык моделирования появился как ответ на потребность в универсальном языке объектного моделирования, который могла бы использовать любая компания. UML - это своего рода вариант чертежа, принятый в индустрии информационных технологий. Это метод детального описания архитектуры системы. Все разработчики сталкиваются с ситуацией, когда приходится проектировать большие классы. При ручном вводе и объявлении имеется ряд подводных камней: во-первых, постановщик задач, как правило, описывает то, что необходимо, на словах, или в редких случаях, с минимальным бумажным сопровождением; во-вторых, разработчик, создающий систему, опять-таки в большинстве случаев игнорирует все комментарии, которыми необходимо сопровождать программный код. В итоге постановщик задач путается в программе, разработчик не помнит, что к чему, а если на его место взят новый сотрудник, то зачастую новый разработчик переписывает модули заново с нуля. Такая ситуация приводит к тому, что производство программного продукта задерживается.

Рекомендуемые диссертации данного раздела

28.06.2016

+ 100 бесплатных диссертаций

Дорогие друзья, в раздел "Бесплатные диссертации" добавлено 100 новых диссертаций. Желаем новых научных ...

15.02.2015

Добавлено 41611 диссертаций РГБ

В каталог сайта http://new-disser.ru добавлено новые диссертации РГБ 2013-2014 года. Желаем новых научных ...


Все новости

Время генерации: 0.297, запросов: 244