ИНТЕРПРЕТАТОР ДИАГРАММ ГРАФИЧЕСКИХ ЗАПРОСОВ К RDF-ХРАНИЛИЩАМ ДАННЫХ
|
Реферат 2
Перечень сокращений и обозначений 4
Введение 9
1 Интерпретатор диаграмм графических запросов к RDF-хранилищам данных 13
1.1 Обзор и анализ интерпретируемых графических языков программирования и моделирования 13
1.1.1. Графические языки программирования и моделирования и методы
их интерпретации 13
1.1.2. Языки запросов к RDF-хранилищам данных 18
1.1.3. Аналоги разрабатываемого программного средства 21
1.1.4. Постановка задачи 26
1.2. Теоретические основы интерпретатора функционально-блочных диаграмм 26
1.2.1. Концепция базовых блоков 26
1.2.2. Концепция композитных блоков 27
1.2.3 Концепция SPARQL-блоков 28
1.2.4 Модель выполнения функционально-блочных диаграмм 29
1.2.5 Метод объяснения решений 32
1.3 Разработка программного интерпретатора функционально-блочных диаграмм 34
1.3.1 Цели создания программы, её назначение и функциональные
возможности 34
1.3.2 Выбор программно-аппаратной платформы 34
1.3.3 Архитектура программы 35
1.3.4 Основные структуры данных 38
1.3.5 Алгоритм работы интерпретатора и метода объяснения решений 40
1.3.6 Руководство пользователя 42
1.3.7 Отладка и тестирование 51
2 Безопасность жизнедеятельности 60
2.1 Введение 60
2.2 Требования к освещению на рабочих местах, оборудованных ПЭВМ 62
2.3Выводы 67
Заключение 69
Список использованных источников 70
Приложение А - UML-диаграммы 72
Приложение A.1 - Диаграмма классов 73
Приложение A.2 - UUMTL-диаграмма прецедентов 74
Приложение A.3 - UML-диаграмма развертывания 75
Приложение A.4 - Диаграмма последовательности 76
Приложение Б - Листинг программы 77
Приложение В - Презентация 97
Перечень сокращений и обозначений 4
Введение 9
1 Интерпретатор диаграмм графических запросов к RDF-хранилищам данных 13
1.1 Обзор и анализ интерпретируемых графических языков программирования и моделирования 13
1.1.1. Графические языки программирования и моделирования и методы
их интерпретации 13
1.1.2. Языки запросов к RDF-хранилищам данных 18
1.1.3. Аналоги разрабатываемого программного средства 21
1.1.4. Постановка задачи 26
1.2. Теоретические основы интерпретатора функционально-блочных диаграмм 26
1.2.1. Концепция базовых блоков 26
1.2.2. Концепция композитных блоков 27
1.2.3 Концепция SPARQL-блоков 28
1.2.4 Модель выполнения функционально-блочных диаграмм 29
1.2.5 Метод объяснения решений 32
1.3 Разработка программного интерпретатора функционально-блочных диаграмм 34
1.3.1 Цели создания программы, её назначение и функциональные
возможности 34
1.3.2 Выбор программно-аппаратной платформы 34
1.3.3 Архитектура программы 35
1.3.4 Основные структуры данных 38
1.3.5 Алгоритм работы интерпретатора и метода объяснения решений 40
1.3.6 Руководство пользователя 42
1.3.7 Отладка и тестирование 51
2 Безопасность жизнедеятельности 60
2.1 Введение 60
2.2 Требования к освещению на рабочих местах, оборудованных ПЭВМ 62
2.3Выводы 67
Заключение 69
Список использованных источников 70
Приложение А - UML-диаграммы 72
Приложение A.1 - Диаграмма классов 73
Приложение A.2 - UUMTL-диаграмма прецедентов 74
Приложение A.3 - UML-диаграмма развертывания 75
Приложение A.4 - Диаграмма последовательности 76
Приложение Б - Листинг программы 77
Приложение В - Презентация 97
Диаграммы графических запросов представляют собой графические инструменты, используемые для визуализации и проектирования запросов к базам данных. Они предоставляют удобный способ графического представления сложных запросов и их взаимосвязей, что делает их более понятными и доступными для широкого круга пользователей.
Вместо традиционного текстового подхода, где запросы формулируются с использованием специализированных языков запросов (например, SQL), диаграммы графических запросов позволяют разработчикам и аналитикам визуально создавать и оптимизировать запросы к данным. Они представляют собой набор графических элементов, таких как блоки, стрелки, символы и связи, которые отражают различные аспекты запроса и его структуру.
Диаграммы графических запросов упрощают процесс разработки, анализа и коммуникации запросов между различными заинтересованными сторонами, включая разработчиков, аналитиков и конечных пользователей. Они помогают визуализировать логику запросов, отображая связи между таблицами, условиями фильтрации, агрегацией данных и другими операциями.
Одним из преимуществ диаграмм графических запросов является их интуитивный и понятный интерфейс. Даже люди, не имеющие глубокого знания языков программирования или баз данных, могут легко разобраться в создании и понимании запросов, представленных в виде диаграммы. Это способствует эффективной коммуникации и сотрудничеству между различными участниками проекта.
Кроме того, диаграммы графических запросов могут быть автоматически интерпретированы и преобразованы в соответствующий текстовый код (например, SQL). Это позволяет легко преобразовывать визуальные запросы в исполняемый код и использовать их в реальных приложениях и системах. В целом, диаграммы графических запросов представляют собой мощный инструмент для проектирования, визуализации и оптимизации запросов к данным. Они облегчают процесс работы с базами данных, делая его более понятным, эффективным и доступным для различных пользователей.
Актуальность темы "Интерпретатор диаграмм графических запросов" заключается в следующем:
• визуальное представление запросов. Диаграммы графических запросов предоставляют визуальное представление сложных запросов к данным. Это может быть особенно полезно для пользователей, которые не имеют глубокого знания языков программирования или запросов баз данных. Представление запросов в виде диаграмм делает их более понятными и доступными;
• удобство и эффективность разработки. Использование графических диаграмм для создания запросов упрощает и ускоряет процесс разработки. Разработчики могут визуально проектировать и оптимизировать запросы, избегая необходимости написания сложного кода. Это снижает вероятность ошибок и позволяет сосредоточиться на более высокоуровневых аспектах разработки;
• улучшение коммуникации и сотрудничества. Диаграммы графических запросов являются языком, понятным как для разработчиков, так и для обычных пользователей. Они могут служить средством коммуникации между разработчиками, аналитиками и заказчиками, позволяя лучше понять требования и ожидания в отношении запросов к данным.
Автоматизация и оптимизация запросов: Интерпретатор диаграмм графических запросов может предоставлять возможности автоматической генерации кода на основе диаграммы. Это упрощает и автоматизирует процесс создания запросов, ускоряет разработку и снижает вероятность ошибок. Кроме того, такие инструменты могут предлагать оптимизацию запросов, что повышает производительность и эффективность выполнения запросов к данным.
В целом, использование интерпретатора диаграмм графических запросов имеет потенциал упростить и улучшить процесс разработки и выполнения запросов к данным.Эта тема актуальна, поскольку визуальное представление запросов и автоматизация их создания могут повысить эффективность работы разработчиков и обеспечить более понятное взаимодействие с данными для пользователей.
Безопасное проектирование критической киберфизической системы предполагает как правильную логику работы, так и соответствие рабочих компонентов их нефункциональным требованиям. В критически важных для безопасности технологических областях последнее также означает выполнение принципа Defense-in-Depth (DiD).
Для решения этой проблемы предлагается метод разработки сложных систем требований (или принципов проектирования) с использованием функциональных блок-схем (FBD) для описания общей архитектуры, хранящейся в базе знаний. Имея принцип проектирования, реализованный в виде FBD, мы можем не только освободить аналитика от ручного труда, но и предоставить механизмы рассуждений о результате оценки, которые проливают свет на полученное число.
Существует два подхода к реализации такого метода с использованием двух различных технологий. Первая - логическое программирование с использованием Prolog с его встроенными возможностями рассуждений и высокой выразительной силой. Здесь информация о нашей архитектуре I&C хранится в базе знаний Prolog, а отдельные запросы технологии и классы безопасности. Этот уровень хранит информацию о структуре архитектуры и физических интерфейсах между ее компонентами вместе с их физическим расположением. Функциональный уровень определяет информационные потоки, то есть функции, которые реализует оборудование, необходимые действия и измерения. В настоящее время такое разнообразие знаний об архитектуре и тот факт, что они часто разбросаны по разным источникам, создают препятствия для ручной оценки соответствия принципу DiD.Работа положила начало формальной проверке нефункциональных требований общей архитектуры ядерных систем КИПиА. Здесь она представлена с помощью онтологии OWL, а проверки выполняются с помощью запросов SPARQL. Онтология объединяет оба уровня информации, поэтому можно проверить свойства, относящиеся к физическим и функциональным компонентам. Хотя можно легко найти объекты, удовлетворяющие определенному запросу, недостаток этого подхода заключается в рассуждениях о более сложных свойствах вместе с зависимостями между ними формулируются в виде предложений Хорна.
Вторая реализация представляет собой графический инструмент, созданный с использованием объектно-ориентированного языка программирования. Этот инструмент позволяет визуально строить FBD требования, выполнять их и объяснять результаты. В этом инструменте архитектура I&C представлена с помощью онтологии, а отдельные запросы формулируются с помощью графического языка SPARQL. Такие формулировки заключены в специальный вид функциональных блоков (ФБ) - SPARQL FB, которые могут быть добавлены в FBD принцип проектирования.
Таким образом, в данной работе был создан интерпретатор графических запросов, предназначенный для обработки и выполнения запросов, связанных с графическими данными. Интерпретатор был реализован с использованием современных технологий и алгоритмов, что позволило достичь высокой производительности и эффективности в обработке запросов.
В процессе разработки интерпретатора была проведена анализ и исследование существующих методов работы с графическими данными, что позволило определить оптимальные подходы к обработке запросов.
Вместо традиционного текстового подхода, где запросы формулируются с использованием специализированных языков запросов (например, SQL), диаграммы графических запросов позволяют разработчикам и аналитикам визуально создавать и оптимизировать запросы к данным. Они представляют собой набор графических элементов, таких как блоки, стрелки, символы и связи, которые отражают различные аспекты запроса и его структуру.
Диаграммы графических запросов упрощают процесс разработки, анализа и коммуникации запросов между различными заинтересованными сторонами, включая разработчиков, аналитиков и конечных пользователей. Они помогают визуализировать логику запросов, отображая связи между таблицами, условиями фильтрации, агрегацией данных и другими операциями.
Одним из преимуществ диаграмм графических запросов является их интуитивный и понятный интерфейс. Даже люди, не имеющие глубокого знания языков программирования или баз данных, могут легко разобраться в создании и понимании запросов, представленных в виде диаграммы. Это способствует эффективной коммуникации и сотрудничеству между различными участниками проекта.
Кроме того, диаграммы графических запросов могут быть автоматически интерпретированы и преобразованы в соответствующий текстовый код (например, SQL). Это позволяет легко преобразовывать визуальные запросы в исполняемый код и использовать их в реальных приложениях и системах. В целом, диаграммы графических запросов представляют собой мощный инструмент для проектирования, визуализации и оптимизации запросов к данным. Они облегчают процесс работы с базами данных, делая его более понятным, эффективным и доступным для различных пользователей.
Актуальность темы "Интерпретатор диаграмм графических запросов" заключается в следующем:
• визуальное представление запросов. Диаграммы графических запросов предоставляют визуальное представление сложных запросов к данным. Это может быть особенно полезно для пользователей, которые не имеют глубокого знания языков программирования или запросов баз данных. Представление запросов в виде диаграмм делает их более понятными и доступными;
• удобство и эффективность разработки. Использование графических диаграмм для создания запросов упрощает и ускоряет процесс разработки. Разработчики могут визуально проектировать и оптимизировать запросы, избегая необходимости написания сложного кода. Это снижает вероятность ошибок и позволяет сосредоточиться на более высокоуровневых аспектах разработки;
• улучшение коммуникации и сотрудничества. Диаграммы графических запросов являются языком, понятным как для разработчиков, так и для обычных пользователей. Они могут служить средством коммуникации между разработчиками, аналитиками и заказчиками, позволяя лучше понять требования и ожидания в отношении запросов к данным.
Автоматизация и оптимизация запросов: Интерпретатор диаграмм графических запросов может предоставлять возможности автоматической генерации кода на основе диаграммы. Это упрощает и автоматизирует процесс создания запросов, ускоряет разработку и снижает вероятность ошибок. Кроме того, такие инструменты могут предлагать оптимизацию запросов, что повышает производительность и эффективность выполнения запросов к данным.
В целом, использование интерпретатора диаграмм графических запросов имеет потенциал упростить и улучшить процесс разработки и выполнения запросов к данным.Эта тема актуальна, поскольку визуальное представление запросов и автоматизация их создания могут повысить эффективность работы разработчиков и обеспечить более понятное взаимодействие с данными для пользователей.
Безопасное проектирование критической киберфизической системы предполагает как правильную логику работы, так и соответствие рабочих компонентов их нефункциональным требованиям. В критически важных для безопасности технологических областях последнее также означает выполнение принципа Defense-in-Depth (DiD).
Для решения этой проблемы предлагается метод разработки сложных систем требований (или принципов проектирования) с использованием функциональных блок-схем (FBD) для описания общей архитектуры, хранящейся в базе знаний. Имея принцип проектирования, реализованный в виде FBD, мы можем не только освободить аналитика от ручного труда, но и предоставить механизмы рассуждений о результате оценки, которые проливают свет на полученное число.
Существует два подхода к реализации такого метода с использованием двух различных технологий. Первая - логическое программирование с использованием Prolog с его встроенными возможностями рассуждений и высокой выразительной силой. Здесь информация о нашей архитектуре I&C хранится в базе знаний Prolog, а отдельные запросы технологии и классы безопасности. Этот уровень хранит информацию о структуре архитектуры и физических интерфейсах между ее компонентами вместе с их физическим расположением. Функциональный уровень определяет информационные потоки, то есть функции, которые реализует оборудование, необходимые действия и измерения. В настоящее время такое разнообразие знаний об архитектуре и тот факт, что они часто разбросаны по разным источникам, создают препятствия для ручной оценки соответствия принципу DiD.Работа положила начало формальной проверке нефункциональных требований общей архитектуры ядерных систем КИПиА. Здесь она представлена с помощью онтологии OWL, а проверки выполняются с помощью запросов SPARQL. Онтология объединяет оба уровня информации, поэтому можно проверить свойства, относящиеся к физическим и функциональным компонентам. Хотя можно легко найти объекты, удовлетворяющие определенному запросу, недостаток этого подхода заключается в рассуждениях о более сложных свойствах вместе с зависимостями между ними формулируются в виде предложений Хорна.
Вторая реализация представляет собой графический инструмент, созданный с использованием объектно-ориентированного языка программирования. Этот инструмент позволяет визуально строить FBD требования, выполнять их и объяснять результаты. В этом инструменте архитектура I&C представлена с помощью онтологии, а отдельные запросы формулируются с помощью графического языка SPARQL. Такие формулировки заключены в специальный вид функциональных блоков (ФБ) - SPARQL FB, которые могут быть добавлены в FBD принцип проектирования.
Таким образом, в данной работе был создан интерпретатор графических запросов, предназначенный для обработки и выполнения запросов, связанных с графическими данными. Интерпретатор был реализован с использованием современных технологий и алгоритмов, что позволило достичь высокой производительности и эффективности в обработке запросов.
В процессе разработки интерпретатора была проведена анализ и исследование существующих методов работы с графическими данными, что позволило определить оптимальные подходы к обработке запросов.
В ходе выполнения выпускной квалификационной работы была разработана программа, включающая в себя интерпретатор диаграмм графических запросов, реализация метода объяснения решений, а также методику выполнения и обработки результатов обращения к хранилищам данных RDF. Данная программа используется для оценки свойств систем, представленных в виде онтологии на основе RDF, она также обладает функционалом для работы с сервером Apache Jena Fuseki, который обрабатывает запросы к хранилищам данных.
В рамках создания программы были разработаны:
• семантика выполнения функционально-блочных диаграмм;
• концепция метода графического объяснения решений;
• графический редактор для работы с блоками;
• возможность настройки работы с Jena Fuseki Server;
• блок исполнения схемы c выводом промежуточных и итоговых результатов.
При создании программы также возникли некоторые затруднения:
• не удалось реализовать все возможности SPARQL, например выстраивание чёткой последовательности блоков «MINUS» и «UNION»;
• неполная работа с библиотекой Graphviz на ОС Windows;
• недостаточная оптимизация использованных методов.
В дальнейшем исследовании данной темы есть идеи по улучшению функционала программы, а также исправлению некоторых недоработок. Например, реализовать надстройку над языком SPARQL, а именно - реализацию условных операций и циклов.
В рамках создания программы были разработаны:
• семантика выполнения функционально-блочных диаграмм;
• концепция метода графического объяснения решений;
• графический редактор для работы с блоками;
• возможность настройки работы с Jena Fuseki Server;
• блок исполнения схемы c выводом промежуточных и итоговых результатов.
При создании программы также возникли некоторые затруднения:
• не удалось реализовать все возможности SPARQL, например выстраивание чёткой последовательности блоков «MINUS» и «UNION»;
• неполная работа с библиотекой Graphviz на ОС Windows;
• недостаточная оптимизация использованных методов.
В дальнейшем исследовании данной темы есть идеи по улучшению функционала программы, а также исправлению некоторых недоработок. Например, реализовать надстройку над языком SPARQL, а именно - реализацию условных операций и циклов.
