Разработка автоматизированной экспертной системы помощи в диагностике и устранении неисправностей в автомобиле

Изучение способов проектирования автоматизированных систем. Разработка структуры тезауруса (для хранения данных). Разработка модуля распознавания ключевых слов (запрос и текст), модуля автоматического дополнения базы знаний. Создание UI-макета системы.

Рубрика История и исторические личности
Вид дипломная работа
Язык русский
Дата добавления 23.08.2017
Размер файла 733,8 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

  • Введение
  • 1. Анализ особенностей разработки экспертных систем
  • 1.1 Изучение способов проектирования автоматизированных систем
  • 1.2 Проектирование системы
  • 2. Формулирование требований к системе
  • 3. Разработка структуры тезауруса (для хранения данных)
  • 3.1 Ознакомление с существующими способами организации баз данных
  • 3.2 Разработать базу данных
  • 4. Разработка модуля распознавания ключевых слов (запрос и текст)
  • 5. Разработка модуля автоматического дополнения базы знаний
  • 6. Разработка модуля визуализации
  • 7. Разработка API и интерфейса
  • 7.1 Создание UI-макета системы
  • 7.2 Написание модуля взаимодействия (API)
  • 8. Тестирование системы
  • Заключение
  • Список используемых понятий и сокращений
  • Список используемых источников
  • Приложения

Введение

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

Последнее время становится все больше автоматизированных экспертных систем, которые помогают принимать различные решения. Однако нельзя забывать о тех ученых, в трудах которых заложены фундаментальные знания исследуемой области. Несмотря на то, что прошло пару десятков лет с момента выпуска основополагающих работ по экспертным системам, их актуальность не иссякла. Ученых в данной области достаточно много, поэтому перечислим лишь некоторых из них: Попов Э. В.[19], Нейлор К.[9], Джексон П.[10], Брукинг А.[18], Нильсон Н.[16], Хейес-Рот[17] и т.д. Р. Левин, Д. Дранг, Б. Эделсон в своей книге[15] изложили ключевые концепции искусственного интеллекта и экспертных систем. Важной особенностью их работы является описание перехода от теории к практике на примитивном языке программирования. Кук Н. М. и Макдональд Дж. в своей книге[20] раскрывают такое понятие, как формальная методология приобретения и представления экспертных знаний.

Следующий объект исследования, на котором стоит остановиться, является теория принятия решений. Учеными, которые заложили фундаментальные знания в данной области, являются: Кини Р.[21], Райфа Х.[21], Айзерман М.А.[22], Алескеров Ф.Т.[22], Орловский С. А.[23] и т.д. Также стоит упомянуть ученых, занимавшихся внедрением теории принятия решений в информационные системы: Трахтенгерц Э. А.[24] и т.д.

Немаловажное значение имеет место хранения данных. От этого зависит структура всего проекта, его функциональность, область распространения, а также быстродействие. База данных является отличным хранилищем данных, которое отвечает на ряд важных требований при разработке (хранение большого объема данных, поиск по запросу, скорость обработки запроса и т.д.). Одними из ученых, занимавшихся вопросом изучения базы данных и которые были основоположниками данной области, являются: Дейт К. Дж.[25], Крёнке Д.[26] и т.д.

Данная работа посвящена разработке автоматизированной экспертной системы помощи в диагностике и устранении неисправностей в автомобиле. О необходимости создания такой системы писал еще в 1997 году Дворянкин А. М. [1]. Также Эри Рикардо Нурсаль написал научную статью [13] по этой же проблеме. И предложил свою структуру экспертной системы, включающую в себя несколько модулей (машина вывода, база знаний, база данных, система взаимодействия с пользователем, адаптивная система). Данная система могла бы увеличить производительность станций технического обслуживания автомобилей за счет уменьшения количества клиентов, которые были вынуждены уехать из-за недостатка знаний механика данного предприятия. Схожей проблемой занимался Ахмад Т. Аль-Таани и подробно описал весь этап создания экспертной системы для диагностики автомобильных неисправностей в своей научной статье[14]. Здесь приводится анализ данной области и методы проектирования таких систем. Немаловажным является тот факт, что в статье приведены примеры работы системы с определенными неисправностями, которые могут возникнуть в процессе эксплуатации автомобиля.

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

Первая экспертная система, которую мы рассмотрим далее, будет из области управления персоналом.

Компьютерный комплекс «Служба персонала + Консалтинг персонала» произведенный отечественной компанией НПО «Эталон»[2] представляет собой двухуровневую экспертную систему шестого поколения с искусственным интеллектом.

Для понимания всего комплекса в целом, рассмотрим подробнее отдельные позиции системы.

Структура программы:

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

Интерфейс:

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

Сетевые возможности:

Как и многие продукты НПО «Эталон» данная разработка имеет полнофункциональный доступ к сети, а также есть возможность передачи информации с одной станции на другую в закодированном формате на переносном носителе.

Вывод:

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

Причины, которыми был вызван интерес к данной теме:

- недостаточный уровень развития науки;

- низкая степень оснащенности лечебных учреждений;

- большой объем практической нагрузки врача;

- атипичное течение или редкость заболевания;

- низкий уровень подготовки врачебных кадров;

- ошибки лабораторно-инструментальных исследований.

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

Одним из примеров экспертных систем реального времени является экспертная система G2 [3].

Основные компоненты данной системы:

- База знаний

- Лексический анализатор

- Подсистема моделирования

- Планировщик

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

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

При создании G2 использовались такие универсальные технологии разработки современных информационных систем как:

- Стандарты открытых систем

- Архитектура клиент/сервер

- Объектно-ориентированное программирование

- ОС, позволяющие выполнять несколько процессов параллельно в реальном времени

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

- С пакетами программ

- С СУБД

- С контроллерами и концентраторами данных

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

MYCIN - пример одной из ранних экспертных систем. Она была разработана в 70-х годах прошлого века в Стэнфордском университете в качестве диссертации Эдварда Ханса Шортлифа. При создании данной системы использовались знания, полученные во время написания другой экспертной системы - Dendral, но с акцентом на использования правил в условиях наличия элементов неопределённости. MYCIN был спроектирован для диагностирования бактерий, вызывающих тяжелые инфекции, и для рекомендации необходимого количества антибиотиков в зависимости от массы тела.Система работала по принципу множественных вопросов, на основании которых она выдавала список вероятных бактерий и диагнозов с возможным курсом лечения. Программа запускалась на сервере с разделением времени, доступному по раннему Интернету (ARPANet), когда еще не было персональных компьютеров.

Теперь рассмотрим другую систему - TMYCIN. Она основана на MYCIN [5].

TMYCIN («Tiny EMYCIN») является простой экспертной системой, разработанной на базе EMYCIN. TMYCIN не выполняет все задачи EMYCIN, она предназначена для реализации наиболее часто используемых функций в виде малого и простого модуля. Внутренняя реализация TMYCIN было написано с нуля и поэтому отличается от аналога в EMYCIN.

Принцип работы TMYCIN прост. Функция верхнего уровня doconsult создает новый символ из context-name для использования его в качестве context-name консультации. После этого, система просит у пользователя ввести параметры, которые определены как исходные данные. Далее вызывается bc-goal для каждого из целевых параметров и в завершении выводит результаты.

Аналогом экспертной системы в области медицины является компьютерная программа CaDet [6]. На основе анализа эпидемиологических и клинических признаков отдельных пациентов CaDet предоставляет врачам информацию, показывающую необходимость особого внимания относительно ранней диагностики рака соответствующим пациентам. Исследования показали, что рабочие возможности данного инструмента позволяют использовать его для помощи врачам. Работа программы заключается в том, что по каждому пациенту вводятся данные о состоянии его здоровья и после обработки данных предоставляется отчет. Он состоит из нескольких секций:

- Данные, которые были выявлены в процессе диагностирования пациента;

- Предупреждения рака, которые формируются после обработки введенных данных.

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

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

- Формализованный фактор рака (FCF)--обозначает степень внимания, которое должно получить к соответствующему раку врачом. Этот счет эвристическим образом вычисляется путем взвешивания результатов диагностирования пациента. Его величины могут находиться в диапазоне от 1 до 6.

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

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

Описанная ниже система - MovieRecommendationSystem [7] - представляет собой написанную на языке CLIPS систему, которая помогает пользователю в выборе фильма. Данная система достаточно простоя в реализации. Для разработки интерфейса используется Java. MovieRecommendationSystem позволяет подобрать фильм по заданным пользователем критериям, таким как жанр, возрастное ограничение, страна происхождения и другим.

Вторая открытая система - Menu-Classification [8] - используется в ресторанном деле.

Данная система была разработана для облегчения классификации меню ресторанов по типам, использую базу знаний и наивный байесовский классификатор (основанный на применении Теоремы Байеса со строгими (наивными) предположениями о независимости) с 95%-й точностью Идея для этого проекта была позаимствована из музыкальной рекомендации Pandora, в которой каждая музыка классифицирована в различные общие категории, а в них более мелкие подкатегории. Классификация идет в два этапа. В начале идет классификация по наивному байесовскому классификатору. Далее используя экспертную систему и фиксированные правила классификации для определенного меню, которое позволяет пользователям делать свои подкатегории по набору ключевых слов.

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

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

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

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

Инструментальные и программные средства. Для сервера используется система: ubuntu 16.04. Технические характеристики:

- ОЗУ: 4 ГБ

- Ядер: 4

- HDD: 20 Гб

На сервере стоит Apache версии 2.4.25 (Win32), OpenSSL 1.0.2j, PHP 5.6.30 и phpMyAdmin 4.6.5.2.

Кодировка сервера: UTF-8 Unicode (utf8)

Для разработки используется Node js: 6.10.2 с средством подгрузки дополнительных модулей npm 10.10.2. О причинах выбора см. раздел 8.2.

1.5 Планируемые результаты

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

1. Анализ особенностей разработки экспертных систем

1.1 Изучение способов проектирования автоматизированных систем

Экспертная система -- это программа для компьютера, которая оперирует со знаниями в определенной предметной области с целью выработки рекомендаций или решения проблем. Данный раздел написан опираясь на информацию из книг К. Нейлора[9] и П. Джексона [10].

Основные задачи, которые решает экспертная система:

- извлечение информации из первичных данных

- диагностика неисправностей;

- структурный анализ сложных;

- выбор конфигурации сложных многокомпонентных систем;

- планирование последовательности выполнения операций, приводящих к заданной цели.

Отличительные особенности экспертной системы:

- Моделирует механизм человеческого мышления для решения задачи;

- Система формирует определенные выводы, основываясь на своих знаниях;

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

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

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

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

Базовые функции экспертных систем:

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

- Представление знаний. Ассоциативное представление знаний на логическом уровне.

- Управление процессом поиска решения. Умение правильно соотнести знания друг с другом.

- Разъяснение принятого решения.

- Текущее состояние проблемы. Умение правильно трактовать запрос пользователя и дать корректный результат.

Стадии приобретения знаний:

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

- Концептуализация. Формирование основных отношений, таких как причинно-следственная связь терминов, анализ потоков информации и т.д.

- Формализация. Происходит работа со структурой данных. Проводится оценка полноты и достоверности данных, ограничений, которые накладываются на данные;

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

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

Метод проектирования включает совокупность трёх составляющих:

1. пошаговой процедуры, определяющей последовательность операций проектирования;

2. критериев и правил, используемых для оценки результатов выполнения операций;

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

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

Наиболее часто при проектировании ИС используют технологии и методы системного проектирования.

Системное (предварительное, концептуальное) проектирование включает в себя следующие стадии:

1. определение общих целей проектирования с формированием отдельных целей разработки;

2. формирование концепции системы и подготовки данных для создания модели объекта;

3. разработки описания системы в виде структур объекта, проектирования и построения функциональных подсистем объекта;

4. формализация задач проектирования, в том числе формирование области поиска решений, систем предпочтений и ограничений, требований к объекту.

Концептуальное проектирование порой называют техническим. Его основными этапами являются:

1. предварительное проектирование,

2. эскизное (рабочее или техно-рабочее) проектирование,

3. изготовление, испытания и доводка опытного образца системы.

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

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

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

1.2 Проектирование системы

Рис. 1. Обобщенная структура ЭС

Экспертные системы должны иметь 4 обязательных элемента[11]:

- База знаний - хранит в себе весь набор знаний, необходимый системе для корректной работы;

- Лексический анализатор - основной блок анализа и обработки знаний, позволяющей системе принимать решения;

- Редактор базы знаний - служит для добавления новых знаний и дополнения или изменения текущего набора знаний;

- Интерфейс пользователя - служит для возможности взаимодействия пользователя и системы.

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

Рис. 2. ER-диаграмма

Главной особенностью данной базы данных является древовидная структура хранения данных - все элементы-данные разбиты на структурные уровни и блоки в соответствии с рисунком 3. Такой подход позволит в дальнейшем облегчить работу с данными - их редактирование, занесение и выгрузку.

Рис. 3. Структура данных

Лексический анализатор написан с использованием Node.JS. Фактически, представляет из сея обработчик входного запроса, который обрабатывается по определенному набору правил, в соответствии с которыми собирается ключевая фраза-запрос к базе данных. Полученные таким способом данные хранят в себе набор вероятных проблем и способы их устранения.

Редактор базы знаний будет представлять из себя web-форму со списком полей, необходимых для поиска, редактирования и добавления данных.

Внешний вид интерфейса пользователя описан ниже в разделе «Создание UI-макета системы».

Процесс разработки ЭС разделяется на три основных этапа:

- Предварительный этап

- Этап прототипирования

- Этап доработки

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

На данный момент разработана база данных и проходит ее отладка. Так же были написаны модули машины вывода, интерфейса и редактора базы знаний.

2. Формулирование требований к системе

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

- Система должна быть эффективной, она должна давать достоверные рекомендации по устранению неисправностей;

- Интерфейс данной системы должен быть понятен для пользователей с различным уровнем способностей;

- База знаний системы должна периодически обновляться для повышения эффективности работы.

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

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

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

Третье - база данных должна быть заполнена экспертом корректно и им же проверена.

3. Разработка структуры тезауруса (для хранения данных)

3.1 Ознакомление с существующими способами организации баз данных

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

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

Классификация по степени распределённости:

- Централизованная. БД, полностью находится на одном устройстве (сервер или компьютер).

- Распределённая. БД, части которой находятся в различных местах сети в соответствии с каким-либо критерием.

- Неоднородная. Фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД.

- Однородная. Фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.

- Фрагментированная. Методом распределения данных является фрагментирование, вертикальное или горизонтальное.

- Тиражированная. Методом распределения данных является тиражирование (репликация).

Классификация по модели данных:

- Иерархическая

- Объектная и объектно-ориентированная

- Объектно-реляционная

- Реляционная

- Сетевая

Иерархическая модель данных -- это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов данных различных уровней. Между объектами существует связь предок-потомок. У предка может быть неограниченное число потомков (или не быть ни одного), у потомка может быть только один предок. Потомки с одним предком называются близнецами.

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

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

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

Реляционная модель данных включает следующие компоненты:

- Структурный аспект (составляющая) -- данные в базе данных представляют собой набор отношений.

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

- Аспект (составляющая) обработки (манипулирования) -- РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

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

Основными плюсами которой являются:

- Удобная и статичная структура

- Быстрый поиск

- Удобный и отработанный доступ к данным

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

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

3.2 Разработать базу данных

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

Для корректного функционирования системы необходимо использовать две основные таблицы: понятия и проблемы. В таблице «понятия» будет хранится информация о физическом объекте и его описание. В таблице «проблема» будет хранится проблема, ее описание и способы ее устранения. Примеры структур представлены на рисунке 4.

Рис. 4. «Структура БД»

Рис. 5. «Вид графа»

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

create table element(

id numeric(3) primary key not null,

name varchar(100) not null,

description varchar(255) not null,

id_up numeric(3) not null,

lvl numeric(3) not null.

);

Выше представлен код создания таблицы с терминами. Она состоит из описательных полей имени и описания, а так же информационных полей, которые указывают на элемент-родитель (id_up) и структурный уровень (lvl).

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

create table problem(

id numeric(3) primary key not null,

name varchar(100) not null,

description varchar(255) not null,

decision varchar(255) not null,

tag varchar(255) not null,

KPI numeric(3) not null

);

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

create table link(

id numeric(3) primary key not null,

id_problem numeric(3) reference problem,

id_trouble numeric(3) reference element

);

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

тезаурус хранение данные макет

4. Разработка модуля распознавания ключевых слов (запрос и текст)

Для любых действий с объектами базы знаний необходимы два основных элемента - модуль взаимодействия с базой знаний и модуль распознавания исходных данных. Разработка модуля взаимодействия будет подробнее рассмотрена в последующих разделах. В данном разделе будет более подробно описана работа модуля распознавания.

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

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

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

var substringArray_find = element.split(" ");

var substringArray = myString.split("*");

Выше показан пример кода, который позволит нам разбить запрос пользователя на массив слов, использованных в запросе. Помимо этого, данный набор команд разделяет и список ключевых слов, полученный в строковом формате из базы данных. Ключевые слова разделены символом «*», что отражено во второй строке. Сам код находится в приложении 6.

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

5. Разработка модуля автоматического дополнения базы знаний

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

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

6. Разработка модуля визуализации

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

Граф рисуется в блоке типа «canvas».

<canvas id="viewport" width="800" height="600"></canvas>

Для визуализации используется JavaScript с библиотеками AJAX, для выгрузки информации из базы данных, и arbor, которая помогает рисовать сам граф.

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

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

"nodes": [

{"name":"Автомобиль"},

{"name":"Двигатель"},

{"name":"Система питания"},

{"name":"Воздух"},

{"name":"Топливо"},

{"name":"Бензин"},

{"name":"Дизель"},

{"name":"Карбюраторный двигатель"},

{"name":"Инжекторный двигатель"},

{"name":"Топливная рампа"},

{"name":"Топливная форсунка"},

{"name":"Топливный насос"}]

Второй по порядку блок описывает связи между вершинами. В поле src указывается вершина-начало, в поле dest обозначена вершина-конец линии графа. Все вершины в этом блоке должны быть предварительно описаны в первом блоке nodes.

"edges": [

{"src":"Автомобиль","dest":"Двигатель"},

{"src":"Двигатель","dest":"Система питания*"},

{"src":"Двигатель","dest":"Кривошипно-шатунный механизм"},

{"src":"Система питания","dest":"Воздух"},

{"src":"Система питания","dest":"Топливо"},

{"src":"Топливо","dest":"Бензин"},

{"src":"Топливо","dest":"Дизель"},

{"src":"Бензин","dest":"Карбюраторный двигатель"},

{"src":"Бензин","dest":"Инжекторный двигатель"},

{"src":"Инжекторный двигатель","dest":"Топливная рампа"},

{"src":"Инжекторный двигатель","dest":"Топливная форсунка"},

{"src":"Инжекторный двигатель","dest":"Топливный насос"},

{"src":"Инжекторный двигатель","dest":"Топливный фильтр тонкой очистки"}

]

7. Разработка API и интерфейса

7.1 Создание UI-макета системы

Основными требованиями к интерфейсу являются:

- Удобство навигации;

- Легкость восприятия;

- Информативность;

- Отсутствие избыточности информации.

Исходя из этих требований в Adobe Photoshop был нарисован примерный макет размещения основных информационных блоков. Основными элементами интерфейса являются:

- Поле ввода запроса;

- Окно визуализации графа, в виде которого представлена связь понятий и решений проблем;

- Окно списка неисправностей, где видны все возможные найденные неисправности;

- Окно пояснения - расшифровывает понятие или дает инструкцию к действию.

Рис. 6. «Макет интерфейса»

Рис. 7. «Интерфейс»

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

Рис. 8. «Интерфейс»

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

Рис. 9 «Добавление неисправности»

Рис. 10. «Добавление структурного элемента»

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

7.2 Написание модуля взаимодействия (API)

Для разработки серверной части web-приложения и для его взаимодействия с базой данных был разработан API. Изначально имеется база данных состоящая из трех таблиц. Код создания находится в приложении. Изначально код серверной части был написан на языке программирования PHP, однако, после возникновения некоторых проблем с установлением связи сервера с базой данных, было решено перейти на более современный и производительный Node.js. Он позволяет использовать единый язык программирования во всех элементах web-приложения. Другим плюсом Node.js перед PHP является более простая обработка текстовой информации и работы и передачей данных через web-запросы (AJAX) в формате JSON, который признан наиболее удобным для этих целей. Такой подход дает возможность более качественной оптимизации приложения и позволяет реализовать лучшее взаимодействие между front-end и back-end частями приложения. В приложении 6 находится код, который реализует связь с базой данных и помогает получить из нее необходимые данные.

Так для выборки всех элементов из тестовой таблицы используется

'SELECT * FROM table'

Для выполнений обновления данных и добавления необходимо выполнить соответственно один из двух запросов:

UPDATE [top(x)] <объект> SET <присваивание1 [, присваивание2, ...]> [WHERE <условие>];

insert into <название таблицы> values (<Значение>,...)

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

Рассмотрим работу сервера в общем виде. Во-первых, необходимо постоянно проверять (слушать) определенный порт нашего сервера на наличие обращения на него. При условии наличия некого обращения к нашему серверу, идет проверка на наличие запроса, если таковой имеется, то мы его считываем и обрабатываем. В случае если в модуле перенаправления имеется функция, которая вызывается при определенном запросе на сервер, то обработка должна проходить таким образом, что выполняется проверка на соответствие ожидаемого функцией запроса и запросом, который получил сервер. Модуль обработки запроса, полученный сервером, хранится в файле router.js. Его функционал в данном проекте заключается в том, чтобы разбивать запрос, пришедший на сервер на несколько частей и отправлять для дальнейшей обработки только нужные. Это сделано для того, чтобы облегчить работу последующих модулей, а также помогает разработчику брать из запроса только ту информацию, которая будет необходима для работоспособности всего модуля взаимодействия. Модуль прослушивания определенного порта сервера, про который мы упоминали выше, находится в файле server.js и он является начальным звеном в работе всего сервера. Затем идет модуль перенаправления (router.js) и только после них идет основной обработчик запроса, в котором содержаться основные функции, которые выполняет сервер, и хранится он в файле requestHandlers.js. Запуск сервера происходит с помощью файла index.js, в котором вызываются в определенном порядке все необходимые модули обработки запроса.

Ниже представлен список основных функций API, необходимых для работы системы:

1. Получение объекта поиска из базы знаний

2. Вывод списка проблем по заданному элементу запроса

3. Вывод структурных объектов

4. Вывод неисправностей

5. Изменение объекта знаний из таблицы возможных неисправностей

6. Изменение объекта знаний структуры

7. Добавление новых неисправностей

8. Добавление структурных элементов

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

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

Функция вывода структурных элементов базы данных выполняется в несколько этапов. Первым этапом является запрос к базе данных, которая в свою очередь предоставляет нам все данные для дальнейшей обработки. Так как речь идет о структурных элементах система, то нам необходимо знать два поля, это “name” и “upper_name”. Первое представляет собой название текущего элемента, а второе - это название элемента, который расположен на один уровень выше. В нашем случае, если взять «Двигатель»(“name”), то элементом выше будет «Автомобиль» (“upper_name”).Таким образом необходимо перебрать все структурные элементы базы данных и сформировать ответ на запрос, представляющий из себя перечень названий структурных элементов и связей между ними, если таковые имеются. На стороне клиента этот запрос будет принят и записан в файл input.json, который в свою очередь отвечает за построение графа. Описание визуализации графа и его построение можно почитать в разделе «Визуализация графа».

8. Тестирование системы

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

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

Далее будет демонстрация тестирования приложения.

Тест интерфейса заполнения базы данных.

Рис. 11. «Тестирование добавления структурного элемента»

Рис. 12. «База данных «Тестирование добавления элемента»

Как видно из приведенный рисунков 11 и 12, серверная часть приняла запрос пользователя, обработала его и заполнила базу данных должным образом. Название стурктурного элемента помещено в “name”, описание в “description”, родительский структурный уровень в “upper_name”. Внесение информации в базу данных работает корректно.

Тест поиска проблем, по указанному запросу.

Рис. 13. «Запрос пользователя»

Рис. 14. «Вывод списка проблем и их решений»

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

...

Подобные документы

  • Изучение биографии Антонова, который создание научных основ и новых решений, положенных в основу разработки Единой системы ЭВМ, организацию промышленной базы по выпуску и внедрению в народное хозяйство современных ЭВМ был награжден Ленинской премией.

    презентация [454,7 K], добавлен 22.11.2010

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

    курсовая работа [24,7 K], добавлен 13.06.2006

  • Прабатьківщина слов’ян. Розселення слов’ян на землях сучасної Європи. Життя східних слов’ян: утворення поселень, розвиток ремесел, виникнення вірувань і традицій. Слов’янські племена: поляни, сіверяни, деревляни, уличі і тиверці, дуліби, хорвати.

    реферат [28,0 K], добавлен 05.11.2007

  • Історія двох великих етнополітичних об'єднань: східних слов'ян і Хозарського каганату. Аналіз особливостей початкового етапу слов’яно-кочівницьких стосунків. Взаємини східних слов’ян і Хозарського каганату (сер. VIII-IX ст.). Слов’яно-хозарські стосунки.

    курсовая работа [1,9 M], добавлен 07.05.2011

  • Основные этапы формирования социально-политической системы Российской Федерации в 1990-1993 гг. Разработка и принятие Конституции государства. Вертикаль власти: реформы российской политической системы 2000-х гг. Социально-экономическое развитие страны.

    курсовая работа [51,1 K], добавлен 17.10.2014

  • Слов’яни в історичному контексті. Концепції щодо території формування та походження слов’ян. Склавини та анти – предки українського народу. Економічний розвиток, суспільний устрій та культура східних слов’ян напередодні об’єднання їх у феодальну державу.

    реферат [27,5 K], добавлен 28.12.2008

  • Ялтинская и Потсдамская конференции глав правительств СССР, США и Великобритании, создание мирной системы: обеспечение режима ядерного сдерживания как залога стабильности. Крушение Ялтинско-Потсдамской системы международных отношений: причины, итоги.

    курсовая работа [52,2 K], добавлен 15.12.2011

  • Контакти східних слов'ян і балтських племен. Спільні риси в поховальному обряді слов'ян і ятвягів в I і II періодах Раннього Середньовіччя, слов'ян II періоду Раннього Середньовіччя і східнобалтських племен. Вплив балтських племен на етногенез слов'ян.

    статья [20,4 K], добавлен 11.08.2017

  • Слов'яни як одна з найчисленніших груп давньоєвропейського населення, історичні пам'ятки та джерела, що засвідчують їх походження та етапи становлення. Свідчення про територію розселення слов'ян-венедів. Роль мовознавчої науки в вирішенні даної проблеми.

    реферат [19,7 K], добавлен 22.10.2010

  • Історія та існуючі теорії походження слов'ян, етапи формування окремих груп слов'янських мов. Створення та перші правителі Київської Русі, становлення та завоювання нової держави. Процвітання металургійної промисловості та основні ремесла пращурів.

    реферат [19,5 K], добавлен 25.03.2010

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

    реферат [33,9 K], добавлен 18.05.2012

  • Формування давньої системи вірувань східних слов’ян від І тис. до н.е. до запровадження християнства на Русі. Іранські божества київського пантеону. Поняття "генотеїзму" у віруваннях східних слов’ян. Демонологія та жертвопринесення у язичницьких культах.

    реферат [32,6 K], добавлен 18.05.2012

  • Воєнна організація слов’ян. Галицько-володимирські князі. Історія нашого війська у княжу добу. Слов’янські городи та їх укріплення. Варяги та варязьке військо. Значіння варягів для України. Походи Олега й Ігоря на Чорне море, бої на Каспію й Закавказзі.

    реферат [37,1 K], добавлен 28.11.2010

  • Визначення історичного часового проміжку, коли відбувається розселення слов’ян. Автор "Повісті минулих літ", час й обставини її створення, цінність джерела. Відношення Нестора Літописця до процесу розселення слов’ян. Зміст уривку "про розселення слов’ян".

    реферат [48,9 K], добавлен 22.03.2015

  • Життя та діяльність Костянтина (Кирила) та Мефодія, місце їх місіонерської діяльності в культурному процесі та вплив на подальший розвиток історії слов'янського народу. Походження слов'янського письма та абетки. Боротьба за богослужіння живою мовою.

    реферат [56,2 K], добавлен 29.09.2009

  • Дослов'янські народи на території сучасної України. Продуктивні форми господарства слов'янських племен - землеробство і скотарство. Походження, розселення та устрій. Культури східних слов'ян. Християнізація слов'янських князів. Становлення державності.

    контрольная работа [43,6 K], добавлен 27.03.2011

  • История развития технических средств обучения авиационного персонала. Методологический аспект разработки автоматизированной обучающей системы. Борьба за превосходство. "Тренажерный бум" времен холодной войны. Подготовка персонала в настоящее время.

    реферат [38,4 K], добавлен 04.09.2013

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

    контрольная работа [42,0 K], добавлен 28.10.2010

  • Ознайомлення із історією походження східних слов'ян; опис їх родинного побуту, фольклору та міфології у "Велесовій книзі". Дохристиянські вірування як прояв розуміння довкілля. Дослідження антропологічного складу середньовічної людності Русі-України.

    реферат [34,3 K], добавлен 11.03.2012

  • Характеристика оценок Версальско-Вашингтонской системы и политики "умиротворения" отечественными современными историками. Сущность и особенности советской внешней политики в отечественной историографии. Разработка и внеклассного урока по данной теме.

    дипломная работа [69,9 K], добавлен 24.06.2017

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.