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

Александр Крестин

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

Объектом исследования является процесс автоматизации отображения расписания ВУЗа с использованием интеграционного сервиса для получения, накопления и обмена информацией, а также приложения дополненной реальности. Цель работы – разработать автоматизированную систему, позволяющую решать следующие задачи: создание общей базы данных расписания; автоматизация изменения информации в базе данных расписания при изменении официального расписания; выдача расписания в унифицированном формате для интеграции с различным типом систем; возможность фильтра расписания по заданному критерию. В результате выполнения выпускной квалификационной работы были исследованы основные направления деятельности диспетчерской службы высшего учебного заведения. Описана концепция подсистемы интеграции и разработано программное обеспечение для интеграции расписания с различными потребителями, а также приложение-клиент для отображения расписания с использованием технологии дополненной реальности. При написании программы использовались следующие технологии: JavaScript, PhantomJS, Python, Django, MS Visual Studio 2017, C#, Unity3D, СУБД SQLite.

Информатика

Дипломы

Вуз: Пензенский государственный технологический университет (ПензГТУ)

ID: 5f46352acd3d3e0001729564

UUID: 57a70aa0-c9b2-0138-2143-0242ac180006

Язык: Русский

Опубликовано: больше 3 лет назад

Просмотры: 369

-21.72

Александр Крестин

-1

Комментировать 13

Рецензировать 0

Скачать - 3,1 МБ

Поделиться работой

МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «Пензенский государственный технологический университет» (ПензГТУ) ПОЯСНИТЕЛЬНАЯ ЗАПИСКА ПензГТУ 1.09.03.03.09.ПЗ к выпускной квалификационной работе на тему: Разработка автоматизированной информационной системы отображения расписания занятий ВУЗа с использованием технологии дополненной реальности Выпускную квалификационную работу выполнил студент группы 16ИЭ1б Крестин Александр Юрьевич _________ (группа, фамилия, имя, отчество) (подпись, дата) Руководитель ВКР к.т.н., доцент кафедры «Прикладная информатика» (должность, место работы) Чигирева Ирина Валерьевна (фамилия, имя, отчество) Оценка руководителя ________________________________________________________ (подпись, дата) Оценка консультанта по (при наличии)____________________________________________ (раздел, оценка, подпись, дата) ВКР допустить к защите в ГЭК Зав. кафедрой «Прикладная информатика» (название кафедры) ___________________Ремонтов А.П.__ (подпись, Ф.И.О.) Защиту назначить на _______________2020 г. Декан факультета _______________________________ (название факультета) ____________________________________ (подпись, Ф.И.О.) ВКР защищена с оценкой : «__________________» протокол № ________ от «_____» ________ 2020 г. Секретарь ГЭК________________________Лазарева О.И._ (подпись, Ф.И.О.) г. Пенза, 2020 1

МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего образования "Пензенский государственный технологический университет" (ПензГТУ) «Утверждаю» заведующий кафедрой «Прикладная информатика» ____________ А.П. Ремонтов ___________________ 2020 г. ЗАДАНИЕ на выпускную квалификационную работу 1. Студент группы 16ИЭ1б факультета АИТ направления подготовки 09.03.03 – «Прикладная информатика», профиль «Прикладная информатика в экономике» Крестин Александр Юрьевич 2. Руководитель ВКР: Чигирева Ирина Валерьевна, к.т.н., доцент кафедры «Прикладная информатика» ПензГТУ. 3. Период выполнения ВКР: с 11.05.2020 г. по 06.07.2020 г. 4. Место преддипломной практики: кафедра «Прикладная информатика» 5. Тема ВКР: Разработка автоматизированной информационной системы отображения расписания занятий ВУЗа с использованием технологии дополненной реальности Тема утверждена приказом проректора по учебной работе ПензГТУ от ___13.04.2020_________№ ___33/07-10-08______________ 6. Техническое задание на выполнение ВКР. Система предназначена для интеграции существующего расписания ПензГТУ с новыми внешними потребителями, такими как: web-сервис расписания аудитории и мобильное приложения дополненной реальности. Функции системы:  формирование базы данных расписания занятий;  преобразование гипертекстового представления официального расписания занятий ПензГТУ для записи в БД в формате SQLite;  вывод данных и расписании с помощью web-сервиса;  фильтр расписания по аудитории и преподавателю; 2

 просмотр расписания аудитории по QR-коду;  просмотр расписания аудитории с помощью мобильного приложения и технологии дополненной реальности. Требования к аппаратному обеспечению: мобильное устройство с характеристиками не хуже: частота процессора 2.0 ГГц, объём ОЗУ 512 Мбайт, объём внутренней памяти устройства 8 Гбайт, поддержка передачи мобильных данных 3G/4G Wi-Fi. ПЭВМ с характеристиками не хуже: частота процессора 2000 МГц, объем ОЗУ 1 Гбайт, объем НЖМД 80 Гбайт. Требования к программному обеспечению: ОС Windows 10; средства реализации – JavaScript, PhantomJS, Python, Django, MS Visual Studio 2017, C#, Unity3D, СУБД SQLite; 7. Объем и содержание основной части проекта. 7.1. Содержание пояснительной записки (перечень вопросов, подлежащих разработке, расчетов, обоснований, описаний). Введение. 1. Предпроектный анализ вопросов создания системы:  краткая характеристика процессов создания и накопления информации о расписании;  анализ информационных потоков;  анализ средств создания системы;  разработка концепции создания системы;  разработка требований к АС. 2. Проектирование системы:  2.1 Общая концепция серверной части приложения  2.2 Общая концепция клиентской части приложения  2.3 Структура информационной системы приложения  2.3.1 Интерфейс пользователя.  2.4 Разработка дизайна приложения  2.4.1 Разработка макета приложения  2.5 Разработка функциональной части 7.2. Графическая часть (перечень и содержание чертежей, плакатов). 1. Диаграммы потоков данных(плакат, 2 лист формата А1); 2. Модель данных предметной области (плакат, 1 лист формата А1); 3. Схема работы системы (чертёж,1 лист формата А1); 4. Структура пользовательского интерфейса (плакат, 1 лист формата А1). 5. Схема ресурсов системы (плакат, 1 лист формата А1); 8. Консультанты и содержание дополнительных разделов. 8.1. Раздел: «_______________________________________» 3

Консультант _______________________________________________________ (должность, место работы, фамилия, имя, отчество) 9. Календарный график работ по выполнению ВКР. Наименование этапов работ Объем работы, % Анализ предметной области и разработка моделей 20 17.05.2020 Проектирование АИС 45 28.05.2020 Оформление пояснительной записки 20 05.06.2020 Оформление графической части 10 10.06.2020 Подготовка презентации 5 15.06.2020 Подпись Срок выполнения руководителя Дата выдачи задания 24.05. 2020 г. Руководитель ВКР: __________________ И.В. Чигирева (подпись) (ФИО) _11.05.2020г. (дата) Задание к исполнению принял: (подпись) А.Ю. Крестин (ФИО) _11.05.2020г. (дата) 4

Реферат Пояснительная записка 80 листов, 19 рисунков, 5 таблиц, 15 источников, 8 приложений. СИСТЕМА ИНТЕГРАЦИИ, АВТОМАТИЗИРОВАННАЯ СИСТЕМА, БАЗА ДАННЫХ, ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ СИСТЕМЫ, JSON, WEB-ПРИЛОЖЕНИЕ, МОБИЛЬНОЕ ПРИЛОЖЕНИЕ, ДОПОЛНЕННАЯ РЕАЛЬНОСТЬ. Объектом исследования является процесс автоматизации отображения расписания ВУЗа с использованием интеграционного сервиса для получения, накопления и обмена информацией, а также приложения дополненной реальности. Цель работы – разработать автоматизированную систему, позволяющую решать следующие задачи:  создание общей базы данных расписания;  автоматизация изменения информации в базе данных расписания при Инв. № подп. Подп. и дата Взам. инв. № Инв. № дубл. Подп. и дата изменении официального расписания;  выдача расписания в унифицированном формате для интеграции с различным типом систем;  возможность фильтра расписания по заданному критерию. В результате выполнения выпускной квалификационной работы были исследованы основные направления деятельности диспетчерской службы ПензГТУ. Описана программное концепция обеспечение для подсистемы интеграции и разработано интеграции расписания с различными потребителями, а также приложение-клиент для отображения расписания с использованием технологии дополненной реальности. При написании программы использовались следующие технологии: JavaScript, PhantomJS, Python, Django, MS Visual Studio 2017, C#, Unity3D, СУБД SQLite. При проектировании системы использовался пакет Visio 2007. Из Лист № докум. Подп. Дата м. Разраб. Крестин А.Ю. И.В. Пров. Чигирева Н. контр. Утв. ВКР-09.03.03-09-20 81 01 Разработка… (см. титульный лист) Пояснительная записка ________ Литера Лист 5 Листов 80 5 ПензГТУ , гр. 16И Э 1б

Содержание Введение .................................................................................................................. 8 1 Предпроектный анализ вопросов создания системы расписания ВУЗа....... 10 1.1 Краткая характеристика предметной области ......................................... 10 1.2 Анализ информационных потоков ............................................................ 11 1.3 Анализ средств создания системы ............................................................ 11 1.3.1 Средства для парсинга сайта .............................................................. 11 1.3.2 Средства для создания интеграционного cервиса ............................ 13 1.3.3 Средства обмена данными .................................................................. 14 1.3.3 Сравнительный анализ современных технологий создания дополненной реальности ...................................................................................... 18 1.4 Разработка концепции построения системы ............................................ 22 1.4.1 Состав системы и ее функции ............................................................ 22 1.4.2 Состав баз данных ............................................................................... 23 1.4.3 Состав информационных потоков и носителей данных .................. 23 1.4.4 Разработка диаграммы вариантов использования ............................ 23 1.4.4 Ожидаемые результаты автоматизации ............................................ 24 1.5 Разработка требований к АС ..................................................................... 25 1.5.1 Основание для разработки .................................................................. 25 1.5.2 Назначение разработки ....................................................................... 25 1.5.3 Требования к системе в целом............................................................ 25 1.5.4 Требования к видам обеспечения....................................................... 27 2 Проектирование системы .................................................................................. 29 2.1 Разработка информационного обеспечения системы отображения расписания ПензГТУ ............................................................................................ 29 2.2 Разработка программного обеспечения .................................................... 31 2.2.1 Разработка серверной части системы отображения расписания .... 31 2.2.2 Разработка подсистемы автоматического разбора существующего расписания 38 2.2.3 Разработка web-интерфейса просмотра расписания ........................ 45 6

2.2.4 Разработка мобильного приложения для просмотра расписания с использованием технологии дополненной реальности .................................... 48 2.3 Руководство пользователя ......................................................................... 57 2.3.1 Назначение и условия применения системы .................................... 57 2.3.2 Подготовка к работе ............................................................................ 57 2.3.3 Описание операций ............................................................................. 59 Заключение ............................................................................................................ 63 Перечень принятых сокращений ......................................................................... 64 Список литературы ............................................................................................... 65 ПРИЛОЖЕНИЕ А. Спецификация ..................................................................... 67 ПРИЛОЖЕНИЕ Б. Диаграммы потоков данных ............................................... 69 ПРИЛОЖЕНИЕ В. Модели данных предметной области ................................ 72 ПРИЛОЖЕНИЕ Г. Схема работы системы ........................................................ 74 ПРИЛОЖЕНИЕ Д. Схема программы мобильного приложения..................... 76 ПРИЛОЖЕНИЕ Е. Схема ресурсов системы ..................................................... 78 ПРИЛОЖЕНИЕ Ж. Структура пользовательского интерфейса ...................... 79 ПРИЛОЖЕНИЕ И. Исходный код системы ....................................................... 79 7

Введение Зачастую на предприятиях используется какая-либо автоматизированная система, позволяющая решать бизнес-задачи при помощи информационных технологий. Так в Пензенском государственном технологическом университете используется своя система для отображения расписания на сайте ВУЗа, при этом ее информационной составляющей является таблица в формате Exel, что влечет ряд проблем, например, отсутствие удобного поиска расписания по преподавателю или аудитории. Так же проблема такого подхода состоит в невозможности использовать эти данные каким-либо сторонним системам. Решением данной проблемы может стать разработка системы-посредника, которая будет осуществлять процесс интеграции данных из одной системы в другую. Интеграция данных включает объединение данных, находящихся в различных источниках, и предоставление данных пользователям в унифицированном виде. Этот процесс становится существенным как в коммерческих задачах (когда двум похожим компаниям необходимо объединить их базы данных), так и в научных (комбинирование результатов исследования из различных биоинформационных репозиториев, для примера). Роль интеграции данных возрастает, когда увеличивается объём и необходимость совместного использования данных. При создании подсистемы интеграции возникает ряд задач, состав которых зависит от требований к ней и используемого подхода. К ним, в частности, относятся:  разработка архитектуры системы интеграции данных;  создание интегрирующей модели данных, являющейся основой единого пользовательского интерфейса в системе интеграции;  разработка методов отображения моделей данных и построение отображений в интегрирующую модель для конкретных моделей, поддерживаемых отдельными источниками данных;  интеграция метаданных, используемых в системе источников данных; 8

 преодоление неоднородности источников данных;  разработка механизмов семантической интеграции источников данных. В данной работе рассматривается процесс создания автоматизированной системы для отображения расписания занятий ВУЗа, включающую подсистему интеграции для получения и накопления информации, а также разработка мобильного приложения, которое использует данные из подсистемы интеграции и отображает расписание аудитории при помощи технологии дополненной реальности. Для достижения поставленной цели разрабатываемая система должна решать следующие задачи:  создание общей базы данных расписания;  автоматизацию изменения информации в базе данных расписания при изменении официального расписания;  выдачу расписания в унифицированном формате для интеграции с различным типом систем;  возможность фильтра расписания по заданному критерию. В данный момент работа расписания занятий ПензГТУ не имеет единой БД и все данные хранятся, добавляются и изменяются сотрудниками диспетчерской службы с помощью Excel файлов, затем сервис, разработанный на языке программирования php, транслирует данные из этих файлов в формат html страниц. При этом отсутствует унифицированный формат предоставления данных о расписании для различных систем-потребителей (мобильное приложение, web-приложение), а также отсутствует возможность отфильтровать данные о расписании по заданному критерию, например, по номеру аудитории, преподавателю, предмету и т.д. Поэтому разработку автоматизированной системы, с подсистемой интеграции расписания между различными сервисами можно считать актуальной. 9

1 Предпроектный анализ вопросов создания системы расписания ВУЗа 1.1 Краткая характеристика предметной области Составление расписания – одна из наиболее распространённых задач в планировании и оптимизации учебного процесса в учебных заведениях. От того, насколько хорошо составлено расписание, зависит эффективность работы преподавателей, усвоение учебного материала студентами, рациональное использование материальных ресурсов. Автоматизация составления расписания – классическая задача в системах управления учебным заведением, но на данный момент нет единого, общепринятого способа её решения. Для составления расписания занятий в Пензенском государственном технологическом университете существует диспетчерская служба. В ее задачи входит планирование, организация и контроль учебной, консультационной и информационной деятельности подразделений ВУЗа ВО, СПО. При этом она выполняет следующие функции:  разработка расписания учебных занятий по направлениям и специальностям ВО для каждой формы обучения, контроль его соблюдение;  координация работы кафедр по составлению расписания зачетов и экзаменов на осенний и весенний семестры;  анализ семестровых планов на предмет их соответствия рабочим учебным планам;  разработка графика использования аудиторного фонда для занятий с обучающимися;  координация индивидуальных планов работы преподавателей ВУЗа;  разработка мероприятий по совершенствованию организации образовательного процесса в подразделениях ВО, СПО. 10

1.2 Анализ информационных потоков Рассмотрим характеристики информационных потоков и процессов обработки данных проектируемой системы. Характеристика информационных потоков представлена в таблице 1.1. Таблица 1.1- Сведения об обмене документами Информационный поток Учебные планы Список дисциплин Список преподавателей Расписание занятий Источник Учебное управление Кафедры Кафедры Диспетчерская Приемник Диспетчерская Диспетчерская Диспетчерская Управление информатизации На основе данных о назначении и составе информационной системы разработана иерархическая информационно-функциональная модель (взаимосвязанные диаграммы потоков данных) существующей ИС, в которой отражены подразделения предприятия, и выделены объекты, внешние по отношению к проектируемой системе (см. приложение Б). 1.3 Анализ средств создания системы 1.3.1 Средства для парсинга сайта На данный момент все расписание хранится в excel файлах, размеченных специальным образом. На сайт эти данные транслируются специальной программой на php, доступ к которой ограничен. Поэтому встает вопрос получения данных расписания и добавления их в БД по раздельным таблицам (аудитории, преподаватели, дисциплины). Так как получить доступ к данным возможно только через сайт http://tt.penzgtu.ru/, то имеет место применение технологии парсинга сайта. В общем смысле, парсинг – это линейное сопоставление последовательности слов с правилами языка. Понятие «язык» рассматривается в самом широком контексте. Это может быть человеческий язык (например, 11

русский), используемый для коммуникации людей. А может и формализированный язык, в частности, любой язык программирования. Парсинг сайтов – последовательный синтаксический анализ информации, размещённой на интернет-страницах. Что представляет из себя текст интернетстраниц? Иерархичный набор данных, структурированный с помощью человеческих и компьютерных языков. На человеческом языке предоставлена информация, знания, ради которых, собственно, люди и пользуются Интернетом. Компьютерные языки (html, JavaScript, css) определяют как информация выглядит на мониторе. Разделим парсинг сайтов на две подзадачи.  собственно сам парсинг – поиск данных, которые нам интересны на страницах;  осмысливание полученных данных. Из методов парсинга можно выделить регулярные выражения и поиск подстроки. Регулярные выражения (англ. regular expressions) — формальный язык поиска и осуществления манипуляций с подстроками в тексте, основанный на использовании метасимволов (символов-джокеров, англ. wildcard characters). Для поиска используется строка-образец (англ. pattern, по-русски её часто называют «шаблоном», «маской»), состоящая из символов и метасимволов и задающая правило поиска. Для манипуляций с текстом дополнительно задаётся строка замены, которая также может содержать в себе специальные символы. Поддержка регулярных выражений есть во многий языках программирования, а также в некоторых текстовых редакторах, поэтому в качестве метода для поиска информации было принято решение использовать именно их. Следующим шагом является выбор инструмента для обращения к конкретной странице и выполнения регулярных выражений для поиска необходимой информации на сайте. 12

Для этих целей лучше подходит такой инструмент как PhantomJS, являющийся полнофункциональным браузером без графической оболочки, управлять которым можно с помощью скриптов написанных на JavaScript. 1.3.2 Средства для создания автоматизированного интеграционного сервиса В качестве средств для создания серверной части системы необходимо использовать программный комплекс с СУБД, поддерживающий обмен информацией по протоколу http, позволяющий выдавать ответ на запрос информации в виде html-файла, и поддерживающий клиент-серверную архитектуру. На данный момент на рынке для построения клиент-серверных приложений существует целый ряд средств. Django — свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC. Проект поддерживается организацией Django Software Foundation. Сайт на Django строится из одного или нескольких приложений, которые рекомендуется делать отчуждаемыми и подключаемыми. Это одно из существенных архитектурных отличий этого фреймворка от некоторых других. Также, в отличие от других фреймворков, обработчики URL в Django конфигурируются явно при помощи регулярных выражений, а не выводятся автоматически из структуры моделей контроллеров. Для работы с базой данных Django использует собственный ORM, в котором модель данных описывается классами Python, и по ней генерируется схема базы данных. Yii — это фреймворк для веб-программирования общего назначения, который может быть использован для разработки практически любых вебприложений. Благодаря своей легковесности и наличию продвинутых средств кэширования, Yii особенно подходит для разработки приложений с большим потоком трафика, таких как порталы, форумы, системы управления контентом (CMS), системы электронной коммерции и др. 13

Подобно большинству других PHP-фреймворков, Yii — это MVCфреймворк. Превосходство Yii над другими фреймворками заключается в эффективности, широких возможностях и качественной документации. Yii изначально спроектирован очень тщательно для соответствия всем требованиям при разработке серьёзных веб-приложений. Yii не является ни побочным продуктом какого-либо проекта, ни сборкой сторонних решений. Он является результатом большого опыта авторов в разработке веб-приложений, а также их исследований наиболее популярных веб-фреймворков и приложений. Ruby on Rails программирования — (RoR) Ruby, реализует фреймворк, написанный архитектурный шаблон на языке Model-View- Controller для веб-приложений, а также обеспечивает их интеграцию с вебсервером и сервером баз данных. Является открытым программным обеспечением. Laravel — бесплатный веб-фреймворк с открытым кодом, предназначенный для разработки с использованием архитектурной модели MVC В результате опроса sitepoint.com в декабре 2013 года о самых популярных PHPфреймворках Laravel занял место самого многообещающего проекта на 2014 год. В качестве основы для построения серверной части системы было принято решение использовать фреймворк Django, т.к. он является бесплатным, модульным, поддерживает СУБД Sqlite, и позволяет обеспечить клиент серверной взаимодействие со всеми частями системы. 1.3.3 Средства обмена данными В процессе разработки приложений с клиент-серверной архитектурой неизбежно возникает проблема выбора формата обмена данными между клиентскими и серверным модулями. Решение этой проблемы может оказать значительное влияние как на работу приложения, так и на трудоемкость дальнейшей модернизации. Время отклика, объем передаваемой информации по каналу связи, расширяемость и портируемость, требуемые ресурсы и другие параметры могут зависеть от формата обмена данными. 14

В настоящее время существует значительное количество различных форматов, рекомендуемых в литературе для использования в распределенных информационных системах. Чаще всего в сообществе разработчиков, предпочтение отдают одному из трёх наиболее используемых форматов обмена данными: XML, JSON, YAML. XML (Extensible Markup Language) – простой, очень гибкий текстовый формат, являющийся подмножеством SGML (ISO 8879) [3], который позволяет определять собственные теги и атрибуты. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать ее в соответствии с особенностями конкретной предметной области, будучи ограниченным лишь синтаксическими правилами языка [4]. Возможность создания собственных тегов делает XML универсальным. JSON (Java Script Object Notation) – представляет собой облегченный формат обмена данными между компьютерами [5]. В соответствии с определением стандарта (Европейской ассоциации сценарного языка производителей программирования компьютеров), он ECMA является производным от литералов Java Script. JSON более компактен, чем XML, его конструкции легче анализируются средствами Java Script, для которого JSON является внутренним используемым типом данных. Основная сфера применения JSON – программирование web-приложений, где он служит альтернативой XML. YAML – человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. В настоящее время акроним YAML интерпретируется как «YAML Ain’t Markup Language» («YAML – не язык разметки»). В названии отражена история развития: на ранних этапах акроним представлял собой аббревиатуру выражения «Yet Another Markup Language» («Ещё один язык разметки») и даже рассматривался как конкурент XML, но позже был переименован, чтобв акцентировать внимание на данных, а не на разметке документов. 15

В настоящее время не существует сформулированных критериев, благодаря которым можно было бы сравнить форматы обмена данными в приложениях с клиент-серверной архитектурой. Однако на различных ресурсах, посвященных IT-тематике, профессиональными разработчиками и архитекторами информационных систем не раз делались попытки такие критерии рекомендовать. Стоит отметить, что, несмотря на значительное число характерных черт, рекомендованных в качестве критериев сравнения, не все они представляют теоретическую или практическую пользу. Ниже представлены те критерии сравнительного анализа, которые в настоящее время представляются наиболее важными при принятии решения в процессе разработки клиентсерверного приложения.  человекочитаемость – предполагает простую и удобную разметку передаваемых данных. При этом язык должен иметь незначительное количество символов-разделителей (скобки, кавычки и т.д.).  простота сериализации – преобразования объекта (данных) в поток байтов для дальнейшего хранения или передачи по каналу связи, в память или файл.  простота десериализации – преобразования потока байтов в объект данных.  возможность проверки формата входных данных – наличие в формате обмена данными внутреннего языка описания структуры документа (JSON-Schema, XML-Schema), необходимого для осуществления предварительной проверки на соответствие приходящих данных, например, со стороны клиента.  эффективность сжатия данных – включает скорость выполнения алгоритма компрессии и коэффициент сжатия.  распространенность – наличие большого количества разработчиков, использующих тот или иной формат обмена данными.  динамика развития, которая характеризуется скоростью популяризации и развития. 16

Сравнение трех рассматриваемых форматов обмена информацией будет выполнено по вышеперечисленным критериям в соответствии с данными, опубликованными не ранее 2013 года. Для количественной оценки соответствия тому или иному критерию используется пятибалльная шкала как одна из самых простых и распространенных в системах оценивания. Затем подсчитывается средний балл оценки каждого формата. Следует отметить, что используемый метод сравнительного анализа является субъективным, так как проставленные оценки являются количественной характеристикой выводов и опыта авторов настоящей статьи. Удобство чтения формата для обмена данными вызывает споры среди разработчиков программного обеспечения, т.к., по мнению многих, является слишком субъективным. Некоторые специалисты утверждают, что это один из самых важных критериев, и приводят доказательства того, что один формат удобнее для чтения, нежели другой. Так, в результате даже беглого просмотра интернет-ресурсов, можно сделать вывод о неудобстве (более трудном восприятии) XML. Для рассмотрения второй характеристики необходимо привести примеры преобразования объекта данных (XML, JSON и YAML) в серверном модуле информационной системы. В качестве языка программирования для иллюстрации выбран С# как один из самых популярных языков с большим количеством дополнительных библиотек и поддержкой миллионов разработчиков программного обеспечения. Пример сериализации объекта XML: Пример сериализации объекта JSON: Пример сериализации объекта YAML: 17

По приведенным примерам можно заключить, что в целом все три формата достаточно удобны и просты для сериализации объектов данных. Заметим, что JSON и YAML имеют одинаковую структуру программного кода сериализации объекта, отличаясь лишь наименованием собственных типов. Два указанных формата похожи друг на друга и отличаются лишь синтаксическими разделителями. Исходя из приведенного выше анализа было принято решение использовать формат JSON для обмена данными между различными частями системы. 1.3.3 Сравнительный анализ современных технологий создания дополненной реальности Среди существующих технологий в области построения приложений дополненной реальности существуют решения, демонстрирующими различные подходы к разработке ПДР, они подразделяются на маркерные и безмаркерные. Приложения дополненной реальности, основанные на маркерах, позволяются решать задачи в областях, в которых возможно явно указания места сцены, где должно быть размещено дополнение. Безусловными преимуществами таких систем является меньшая по сравнению с безмаркерными системами трудоёмкость и наукоёмкость разработок, а также большая надежность определения точных координат расположения дополнительного контента. Рассмотрим библиотеки для создания дополненной реальности на основе маркерной технологии. ARTAG и ARTOOLKIT являются одними из первых систем дополненной реальности, основанными на маркерах (рисунок 1.1). 18

Рисунок 1.1 – Система ARTOOLKIT Эти системы поддерживают различные подходы к формированию маркеров и имеют соответствующий набор библиотек, включающий различные алгоритмы для выделения и распознавания маркеров. Однако уровень средств ARTAG и ARTOOLKIT остается довольно низким: многие задачи, связанные с работой дополненной реальности, остаются на плечах программиста. Вопросы общей архитектуры приложения, разработки пользовательского интерфейса, учета положения пользователя в пространстве не решены средствами этих библиотек. Более того, обе эти системы не предлагают каких-либо решений с точки зрения технологии разработки приложений дополненной реальности, учета особенностей программной оболочки и возможных изменений в ней[3]. Qualcomm Vuforia является логичным развитием систем типа ARTOOLKIT и ARTAG, предоставляя более богатые возможности для работы с видеопотоком, для распознавания объектов различных типов (рисунок 1.2). 19

Рисунок 1.2 – Система Qualcomm Vuforia В рамках данной платформы предоставлены также средства для организации взаимодействия с пользователем на основе дополненной реальности. Однако вопросы разработки приложения, учета особенностей программной оболочки, вопросы учёта позиции человека в пространстве остаются на плечах программиста. Не смотря на это, данная платформа является наиболее гибкой и быстроразвивающейся на данный момент. К тому же лицензия на ее использование не предполагает какой-либо денежной компенсации разработчику, что делает возможным ее использование в любых коммерческих проектах. Также Vuforia обладает возможностью интегрирования с мультиплатформенным инструментом для разработки интерактивных графических приложений Unity3D, с помощью которого можно создавать любые интерактивные графические приложения - будь то игра, симулятор, или интерактивная 3D презентация[3]. Одним из наиболее распространенных продуктов, построенных на безмаркерных технологиях дополненной реальности, является Layar Browser (рисунок 1.3). 20

Рисунок 1.3 – Система Layar Browser Данное приложение позволяет отображать дополнительный контент, представленный в виде слоев, а в качестве основы для расположения дополнительного контента используют данные о позиции пользователя в пространстве, которые, как правило, получены с помощью GPS. Особенностями технологии Layar при построении приложений дополненной реальности являются: 1. Ориентация на использование геопозиционирования. 2. Богатая «экосистема», содержащая подробную документацию и примеры по созданию слоев. 3. Доступность для внесения изменения только API уровня слоя, то есть разработчик не может вносить изменения в работу приложения, выходящие за рамки редактирования слоев. Все остальные решения зашиты в платформу Layar. Как следствие, важным преимущество технологии Layar является то, что практически все вопросы создания приложения, за исключением уровня слоя, переносятся с плеч прикладного разработчика на саму систему Layar. Однако у данного подхода есть ряд недостатков: 21

1. Трудность использования для решения тех задач дополненной реальности, где геопозиционирование не является основным или единственным источником данных о местоположении пользователя. 2. Сложность настройки приложения под конкретного пользователя. 3. Сложность явного учета специфики конкретной программной оболочки при разработке слоев. 1.4 Разработка концепции построения системы Целью выполнения данного раздела является разработка концепции создания автоматизированной системы с подготовкой описания концепции и схемы функциональной структуры системы (диаграммы потоков данных). 1.4.1 Состав системы и ее функции Участниками бизнес-процессов являются:  диспетчерская;  Управление информатизации;  подсистема интеграции;  внешние потребители. На данный момент работа и взаимодействие диспетчерской и управления информатизации налажена и ее результатом является расписание учебного процесса доступное по адресу http://tt.penzgtu.ru/. Но данная схема не предусматривает обмен данными о расписании со сторонними потребителями, например, мобильное приложение, а также не предусматривает поиск расписания по заданному критерию, например, по аудитории, преподавателю. Поэтому было принято решение о интеграции имеющейся системы расписания с новыми потребителями через дополнительный сервис, функции которого включают:  парсинг сайта расписания при изменении;  хранение и обновление данных о расписании в БД;  вывод расписания по заданному критерию(аудитории); 22

 выдача расписания в текстовом формате обмена данными; 1.4.2 Состав баз данных Перечень данных представлен в таблице 1.2. Таблица 1.2 – Перечень данных Оперативные Расписание аудитории Расписание преподавателя Справочные Аудитории Преподаватели Время Дисциплины Неделя 1.4.3 Состав информационных потоков и носителей данных Состав информационных потоков и носители данных представлены в таблице 1.3. Таблица 1.3 – Перечень данных информационных потоков. Информационные потоки в АЭИС Идентификатор Источник Информация о расписании Обновленные расписании данные Данные для обновления Запрос расписания Данные о расписании Диспетчерска я о Управление информатиза ции подсистема интеграции. Подсистема парсинга Внешние потребители подсистема интеграции Приемник Управление информатиз ации подсистема интеграции Носитель данных (ЛВС, НМД, бумага) ЛВС ЛВС подсистема интеграции ЛВС подсистема интеграции Внешние потребители ЛВС ЛВС Диаграмма потоков данных после автоматизации представлена в приложении Б. 1.4.4 Разработка диаграммы вариантов использования Для описания взаимоотношений и зависимостей между группами вариантов использования и действующими лицами, участвующих в процессе, была спроектирована диаграмма вариантов использования разрабатываемой системы, которая наглядно продемонстрирует распределение функций системы 23

между ее пользователями. Диаграмма вариантов использования системы изображена на рисунке 1.4. Рисунок 1.4 – Диаграмма вариантов использования 1.4.4 Ожидаемые результаты автоматизации По сравнению с неавтоматизированной обработкой данных должны произойти следующие изменения:  будет обеспечен однократный ввод в систему справочных данных («Аудитории», «Преподаватели», «Дисциплины», «Время», «Неделя»), которые используются при вводе оперативных данных и формировании расписания по заданному критерию;  формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») в формате JSON.  формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») и вывод в окно браузера. Таким образом, за счет использования ЛВС для обмена данными и сокращения времени на оформление документов, автоматического 24

формирования расписания, сокращения затрат времени на ввод оперативных данных должно произойти повышение качества получения информации о расписании учебного процесса ПензГТУ. 1.5 Разработка требований к АС 1.5.1 Основание для разработки Основанием для разработки автоматизированной системы отображения расписания расписания ПензГТУ послужила необходимость в обеспечении информацией о расписании различных потребителей данной информации. 1.5.2 Назначение разработки Автоматизированная система отображения расписания ПензГТУ предназначена для обеспечения информацией о расписании различных внешних сервисов, а также для удобного вывода расписания по критериям пользователя. Цели создания автоматизированной системы отображения:  накопление, хранение, обработка и выдача достоверной и оперативной информации;  сокращение времени на обработку информации;  уменьшение затрат времени на обработку информации (ввод, обработка информации);  улучшение качества контроля и учета обрабатываемой информации. 1.5.3 Требования к системе в целом Требования к структуре и функционированию системы. В разрабатываемой системе необходимо разработать подсистему разбора текста сайта расписания для составления БД, подсистему вывода результатов запроса пользователя информации о расписании и мобильное приложение выводящее расписание аудитории с использованием технологии дополненной реальности. Исходя из этого, система должна выполнять следующие функции:  парсинг сайта расписания ПензГТУ при обновлении информации;  добавление данных о аудиториях, дисциплинах, преподавателях в БД; 25

 формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») в формате JSON.  формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») и вывод в окно браузера.  интеграция с мобильным приложением дополненной реальности; Требования к персоналу. Персонал АС должен иметь профессиональную подготовку по основной деятельности, подготовку на уровне оператора ПЭВМ и подготовку по эксплуатации АИС, которую он должен получить в период подготовки АС к внедрению на предприятии. Контроль подготовки персонала должен быть выполнен на стадии внедрения. Требования к надежности. При функционировании данной информационной системы должен осуществляться контроль входной и выходной информации, в том числе данных вводимых пользователем и данных, содержащихся в таблицах базы данных. Должна быть предусмотрена защита от неправильного ввода данных. Данные системы должны храниться в единой базе данных. Целостность и сохранность данных должны обеспечиваться выбранной СУБД. Доступ к информации пользователей должен быть защищен паролями и происходить при помощи процедуры аутентификации. АИС должна иметь время восстановления не более 1 часа в случае отказа или сбоя в процессе работы. Должна быть предусмотрена возможность восстановления системы из резервной копии. Требования к сохранности информации при авариях. Во избежание утраты данных в случае аварий, отказов система должна быть снабжена накопителем, чтобы иметь возможность в конце рабочего дня копировать на него нужную информацию. 26

Требования к эксплуатации и обслуживанию компонентов системы. Электропитание технических средств ПензГТУ должно осуществляться от сети переменного тока напряжением 220В. Система заземления для технического обеспечения (ТО) должна быть автономной. Регламент обслуживания: в соответствии с графиком профилактических работ, по мере необходимости в случае отказов или появлении неисправностей. Должно быть оборудовано место для хранения дискет, компакт-дисков с архивом базы данных, картриджей принтеров, компакт-дисков с системным и прикладным программным обеспечением. 1.5.4 Требования к видам обеспечения Требования к информационному обеспечению. Состав, структура и способы организации данных в системе должны соответствовать п. 1.4.2-1.4.3 «Разработка концепции создания». Должна использоваться СУБД, основанная на реляционной модели БД. Полномочия пользователей по работе с данными должны определяться в зависимости от выполняемых ими функций. Для работы с постоянной и условно-постоянной информацией должны использоваться данные типа «Справочники». При внезапном отключении электропитания должна быть обеспечена возможность сохранения данных с помощью использования бесперебойного питания. При вводе должен производиться контроль вводимых данных путем проверки установленных ограничений. Требования к программному обеспечению. Необходимо разработать прикладное ПО подсистемы парсинга сайта, подсистемы вывода информации о расписании по запросу в форматах html страницы и JSON строки, мобильное приложение показывающее расписание аудитории с использованием технологии дополненной реальности. 27

Для реализации АИС необходима ОС Windows 7 и выше; средства реализации – JavaScript, PhantomJS, Python, Django, MS Visual Studio 2017, C#, Unity3D, СУБД SQLite. Требования к аппаратному обеспечению. ПЭВМ с характеристиками не хуже: частота процессора 3,2 ГГц, объем ОЗУ 1024 Мбайт, объем НЖМД 500 Гбайт, ЛВС Fast Ethernet. Мобильное устройство с характеристиками не хуже: частота процессора 2.0 ГГц, объём ОЗУ 512 Мбайт, объём внутренней памяти устройства 8 Гбайт, поддержка передачи мобильных данных 3G/4G Wi-Fi. Требования к методическому обеспечению. Должно быть разработано руководство пользователя АРМ с указанием возможностей АИС, инструкций по выполнению всех операций, а также правил эксплуатации. 28

2 Проектирование системы 2.1 Разработка информационного обеспечения системы отображения расписания ПензГТУ Данные с которыми работает системы должны храниться в базе данных. Для разработки схемы базы данных можно воспользоваться разными видами моделей: модель “Сущность – связь”, фреймовая модель, семантическая сеть. Эти средства должны удовлетворять следующим требованиям:  язык спецификаций должен быть понятным и не содержать параметры реализации инфологической системы;  инфологическая модель предметной области должна легко преобразовываться в модели БД для распространенных СУБД. Исходя из выше указанных требований, подходит модель, называемая “Сущность – связь” или ER-модель. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Общий порядок построения ER-модели состоит в следующем: 1. свойства. В каждом внешнем представлении нужно выделить понятия и их При этом используются результаты анализа экономических документов и разработки концепции построения АРМ. 2. Обозначить понятие именами, которые должны быть понятными, краткими и привычными для пользователя. 3. Выбрать ключевое свойство для каждого понятия. 4. Выявить связи между разными понятиями и определить их степень. 5. Объединить модели, построенные для разных внешних представлений. Особенности разработанной модели:  соответствие третьей нормальной форме; 29

 отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов;  минимальная длина первичных ключей. В данном проекте используется СУБД, основанная на реляционной модели БД. Описание физической модель БД представлено в таблице 2.1. Таблица 2.1 – Описание физической модели БД Имя id Number id Name id Name id Name id room_id date time week day group_id subject_id instructor_id Поле таблицы БД Тип Длина, Ограничения байт Назначение УСЛОВНО – ПОСТОЯННЫЕ ДАННЫЕ Справочник «Аудитории» Первичный ключ Счетчик 2 Номер аудитории Строка(10) 10 Справочник «Преподаватели» Первичный ключ Счетчик 2 Имя преподавателя Строка(75) 75 Справочник «Дисциплины» Первичный ключ Счетчик 2 Название дисциплины Строка(50) 50 Справочник «Группы» Первичный ключ Счетчик 2 Название группы Строка(30) 30 Оперативные данные Документ «Расписание» Первичный ключ Счетчик 2 Ссылка Число 2 Дата занятия Дата 8 Время занятия Время 8 Неделя Число 2 День недели Число 2 Ссылка Число 2 Ссылка Число 2 Ссылка Число 2 Отношения между сущностями приведены в таблице 2.2. Таблица 2.2 – Отношения таблиц Название таблицы Аудитории Преподаватели Дисциплины Группы Ключевое поле id id id id Связанные таблицы Расписание Расписание Расписание Расписание Отношения 1:N 1:N 1:N 1:N 30

ER-модель базы данных представлена в приложении В. 2.2 Разработка программного обеспечения 2.2.1 Разработка серверной части системы отображения расписания Программная реализация подсистемы интеграции расписания со сторонними сервисами выполнена с использованием фреймворка Django и языка программирования Python 2.7. Проект в django это структура директорий и настройки общие для всех приложений внутри. В свою очередь приложение — это код, который выполняется интерпретатором Python. Все управление проектом Django происходит из командной строки. Для создания проекта была использована команда: python django-admin.py startproject timeTable При этом создаётся структура папок вида: timeTable |-- __init__.py |-- manage.py |-- settings.py `-- urls.py Приложение для интерфейса межпрограммного взаимодействия (API) создавалось с помощью команды: python manage.py startapp timeTableApi При этом создаётся структура папок вида: timeTable |-- ... |-- ... `-- timeTableApi |-- __init__.py |-- models.py `-- views.py Разработка моделей. В Django большинство взаимодействий с базой данных осуществляется посредством механизма объектно-ориентированного отображения (Object-Relational Mapper или ORM). Django использует собственный ORM, в котором модель данных описывается классами Python, и по ней генерируется схема базы данных. 31

Модели отображают информацию о данных, с которыми работает приложение. Они содержат поля и поведение данных. Обычно одна модель представляет одну таблицу в базе данных. После создания модели, Django автоматически создает API для работы с базой данных, который позволяет создавать, получать, изменять и удалять объекты. Перечень созданных моделей приведен в таблице 2.3. Таблица 2.3 – Модели таблиц БД Название модели Назанчение TimeTable Программное представление таблицы «Расписание» Программное представление таблицы Room «Аудитория» Программное представление таблицы Subject «Дисциплина» Программное представление таблицы Group «Группа» Программное представление таблицы Instructor «Преподаватель» Django использует механизм миграций для переноса изменений в моделях (добавление поля, удаление модели и т.д.) на структуру базы данных. Для работы с миграциями и структурой базы данных используются две команды:  migrate, которая отвечает за применение миграций, за откат миграций и за вывод статуса миграций.  makemigrations, которая отвечает за создание новых миграций на основе изменений в моделях. Стоит отметить, что миграции создаются и работают в контексте отдельного приложения. Следует рассматривать миграции, как систему контроля версий для базы данных. makemigrations отвечает за сохранение 32

состояния моделей в файле миграции, а migrate отвечает за их применение к базе данных. Поэтому перед использованием приложения были последовательно вызваны команды: python manage.py makemigrations python manage.py migrate В результате выполнения данных команд была создана база данных SQLite3 со структурой соответствующей описанию моделей. Разработка представлений. В Django страницы и остальной контент отдается представлениями. Представление - это функция Python(или метод представления-класса). Django выбирает представление, анализируя запрошенный URL и после обработки запроса использует шаблон для генерации страницы. Например, блог может состоять из следующих представлений:  Главная страница – показывает несколько последних записей блога.  Страница записи – страница отображения одной записи блога.  Страница-архив записей по годам – показывает все месяца года и записи блога, сгруппированные по этим месяцам.  Страница-архив записей по месяцам – показывает все дни месяца и записи блога, сгруппированные по этим дням.  Страница-архив записей по дням – показывает все записи за указанный день.  Форма комментариев – предоставляет возможность добавить комментарий к записи блога. В разрабатываемой системе представления используются для отображения информации о расписании в формате JSON ответа для внешних потребителей, а также для отображения html-страницы расписания аудитории. На рисунках 2.1 и 2.2 изображены примеры страниц, сгенерированных Django для вывода расписания в виде html-страницы и JSON Ответа соответственно. 33

Рисунок 2.1 – Вывод расписания в виде html-страницы Рисунок 2.2 – Вывод JSON-ответа Разработка RESTful-сервиса. Для обеспечения интеграции между различными компонентами в разрабатываемой системе применялась концепция REST. 34

REST (сокр. англ. Representational State Transfer, «передача состояния представления») — стиль построения архитектуры распределенного приложения. Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например HTML, XML, JSON). Сетевой протокол (как и HTTP) должен поддерживать кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость системы и позволяет ей эволюционировать с новыми требованиями. В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса В общем случае REST является очень простым интерфейсом управления информацией без использования каких-то дополнительных внутренних прослоек. Каждая единица информации однозначно определяется глобальным идентификатором, таким как URL. Каждая URL в свою очередь имеет строго заданный формат. Каждая единица информации однозначно определяется URL – это значит, что URL по сути является первичным ключом для единицы данных. Например, расписание аудитории 1-336 /room/1_336, а расписание аудитории на понедельник — /room/1_336/day/0. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /room/1_336/day/0 – это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word. Управление информацией REST-сервиса – целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол HTTP. Для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) 35

могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST. При этом следует отметить использование модуля django-rest-framework инструмент для работы с rest основанный на идеологии фреймворка Django. Django REST Framework — это лёгкий фреймворк для Django, поддерживающий идеологию REST. Использование этого фреймворка позволяет легко стандартизировать запросы к базе данных и одновременно создавать RESTful WEB API сайта. Особенности Django REST Framework:  отображение ресурсов с использованием новой функции Django — Class Based Views.  поддержка ModelResources и проверка входных данных.  наличие подключаемых парсеров, отображений, авторизации и прав доступа - все легко настраивается.  указание типа материала с использованием Access в заголовках HTTP-запросов.  поддержка форм с возможностью проверки. Для подсистемы интеграции был разработан следующий REST протокол: POST /api/timetable/ — добавить данные о расписании переданные в формате key-value GET /api/timetable/room/— получить расписание аудитории room в формате JSON GET /api/timetable/room/day/— получить расписание аудитории room на день day в формате JSON GET /timetable/room/— получить расписание аудитории room в формате html Разработка маршрутизатора web-запросов. Для обработки web-запросов в Django используется специальный внутренний механизм, основанный на регулярных выражениях. При запросе к 36

странице Django-сайта, используется следующий алгоритм для определения какой код необходимо выполнить: 1. Django определяет какой корневой модуль URLconf использовать. Обычно, это значение настройки ROOT_URLCONF, но, если объект запроса HttpRequest содержит атрибут urlconf (установленный request middleware), его значение будет использоваться вместо ROOT_URLCONF. 2. Django загружает модуль конфигурации URL и ищет переменную urlpatterns. Это должен быть список экземпляров django.conf.urls.url(). 3. Django перебирает каждый URL-шаблон по порядку, и останавливается при первом совпадении с запрошенным URL-ом. 4. Если одно из регулярных выражений соответствует URL-у, Django импортирует и вызывает соответствующее представление, которое является просто функцией Python(или представление-класс). При вызове передаются следующие аргументы:  объект HttpRequest.  если в результате применения регулярного выражения получили именованные совпадения, они будут переданы как позиционные аргументы.  именованные аргументы создаются из именованных совпадений. Они могут быть перезаписаны значениями из аргумента kwargs, переданного в django.conf.urls.url(). 5. Если ни одно регулярное выражение не соответствует, или возникла ошибка на любом из этапов, Django вызывает соответствующий обработчик ошибок. На рисунке 2.3 приведен пример разработанного URLConf. 37

Рисунок 2.3 - Пример файла конфигурации URL-обработчика 2.2.2 Разработка подсистемы автоматического разбора существующего расписания Программная реализация подсистемы автоматического разбора существующего расписания (парсера сайта http://tt.penzgtu.ru/) осуществлялась с использованием технологий JavaScript и PhantomJS. PhantomJS является полнофункциональным браузером без графической оболочки, управлять которым можно с помощью скриптов написанных на JavaScript. С применением данных технологий для решения задачи формирования базы данных расписания был разработан следующий алгоритм: 1. Подключиться к адресу http://tt.penzgtu.ru/ 2. Определить тип страницы по заголовку, используя регулярные выражения. 3. Сформировать список ссылок на последующие страницы для рекурсивного обхода. 4. Исследовать код страницы на предмет наличия в ней информации о расписании. 5. При наличии расписания вычленить с помощью регулярных выражений информацию о группе, аудитории, преподавателе, времени, предмете, сформировать запись и выполнить запрос к системе интеграции (REST-сервису) для занесения данных о расписании в БД. Вернуться на страницу назад и перейти к следующей ссылке. 38

На рисунке 2.4 приведен пример страницы со ссылками расписания занятий очной формы обучения и ее исходный код: Рисунок 2.4 – Исходный код страницы расписания Анализ исходного кода страницы показал, что все ссылки представлены тегами <li> с атрибутом class=button, следовательно, javascript-код для сбора информации по всем ссылкам на странице представлен на рисунке 2.5. Рисунок 2.5 – Код для поиска ссылок на странице Результат выполнения данного кода в консоли браузера представлен на рисунке 2.6. 39

Рисунок 2.6 – Результат выполнения кода поиска ссылок На рисунке 2.7 приведен пример страницы расписания занятий очной формы обучения и ее исходный код: Рисунок 2.7 – Исходный код страницы расписания Анализ исходного кода страницы показал, что вся необходимая информация по расписанию находится в соответствующих html-тегах. Перечень тегов и соответствующей информации представлен в таблице 2.4. 40

Таблица 2.4 – Анализ кода html-страницы расписания. Html-тег Хранимая информация <p class="day-title"> </p> День недели <td class="day-time"></td> Время занятия <td class="day-subject"></td> Предмет, аудитория, преподаватель, номер недели Таким образом основной задачей разбора расписания является вычленение информации из строки внутри тега <td class="day-subject"></td>. Для этого был применен механизм регулярных выражений, которые позволяют осуществлять поиск информации в строке основываясь на определенном шаблоне. Разработка регулярных выражений для поиска информации в строке. Регулярные выражения - это широко используемый способ описания шаблонов для поиска текста и проверки соответствия текста шаблону. Специальные метасимволы позволяют определять, например, что необходимо найти подстроку в начале входной строки или определенное число повторений подстроки. Модификатор — предназначен для "инструктирования" регулярного выражения. Метасимволы — специальные символы, которые служат командами языка регулярных выражений. Регулярное выражение задаётся как обычная переменная, только вместо кавычек используется слэш, например: var reg=/рег_выражение/ Под простейшими шаблонами будем понимать такие шаблоны, которые не нуждаются в каких-либо специальных символах. Допустим, нашей задачей является замена всех букв "р" (малых и заглавных) на латинскую большую букву "R" в словосочетании Регулярные выражения. Создаём шаблон var reg=/р/ и используя метод replace осуществляем замену: 41

Метасимволы задают тип символов искомой строки, способ окружения искомой строки в тексте, а так же количество символов отдельного типа в просматриваемом тексте. Поэтому метасимволы можно разделить на три группы:  метасимволы поиска совпадений;  количественные метасимволы;  метасимволы позиционирования; В таблице 2.5 приведены метасимволы поиска совпадений. Таблица 2.5 - Метасимволы поиска совпадений Символ Значение \b граница слова Описание задаёт условие, при котором шаблон должен выполняться в начале или конце слова Пример /\ber/ совпадает с error, не совпадает с hero или с player /er/ совпдает с player, не совпадает с hero или с error /\ber\b/ не совпадает с hero или с player или с error, может совпасть только с er \B задаёт условие, при котором шаблон не выполняется в начале или не граница слова конце слова /\Ber/ совпадает с hero или с player, не совпадает с error /er\B/ совпадает с error или с player, не совпадает с hero /\Ber\B/ совпадает с hero, не совпадает с player или с error \d цифра от 0 до 9 - /\d\d\d\d/ совпадает с любым четырёх значным числом \D не цифра - /\D\D\D\D/ не совпадёт с 2005 или 05.г или №126 и т.д. \s одиночный пустой символ соответствует символу пробела \over\sbyte\ совпадает только с over byte любой один символ за исключением пробела \over\Sbyte\ совпадает с over-byte или с over_byte, не совпадает с over byte или over--byte - /A\w/ совпадает с A1 или с AB, не совпадает с A+ - /A\W/ не совпадает с A1 или с AB, совпадает с A+ \S \w \W одиночный непустой символ буква, цифра или символ подчёркивания не буква, цифра или символ подчёркивания 43

Символ Значение . любой символ [] набор символов [^ ] набор не входящих символов Список Описание Пример любые знаки, буквы, цифры и т.д. задаёт условие, при котором шаблон должен выполняться при любом совпадении символов заключенных в квадратные скобки задаёт условие, при котором шаблон не должен выполняться при любом совпадении символов заключенных в квадратные скобки /.../ совпадает с любыми тремя символами ABC или !@4 или 1 q разработанных регулярных /[QA]WERTY/ совпадает с QWERTY, с AWERTY /[^QA]WERTY/ не совпадает с QWERTY, с AWERTY выражений и их назначение представлен в таблице 2.6. Таблица 2.6 – Список регулярных выражений Регулярное выражение Получаемая информация /\d{1}\-\d+/g Номер аудитории /.*\s/ Название предмета /.*\s.{1}\..{1}\.|[А-Яа-яЁё]+-[А-Яа-яЁё- Имя преподавателя ]+$/ /(.*по)\s+(.*)\s+неделе\s.*\n.*\n.*/g Номер недели /\лекция|\лаб.|\пр./ Тип занятия Javascript-код для сбора информации по всем ссылкам на странице представлен в приложении Д. Результат выполнения данного кода в консоли браузера представлен на рисунке 2.8. 44

Рисунок 2.8 – Результат выполнения кода поиска информации о расписании Разработка процесса автоматизации парсинга сайта расписания Для записи полученных данных в базу данных, сформированные данные последовательно посылаются в виде POST-параметров AJAX-запроса на адрес ранее разработанного REST сервиса (POST /api/timetable/). Таким образом происходит отделение способа получения данных о расписании и способа занесения их в БД. Для решения задачи автоматизации процесса запуска скриптов на языке javascript на страницах с расписанием была применена технология PhantomJS. PhantomJS представляет собой web-браузер без графической оболочки, которым можно управлять с помощью скриптов на языке JavaScript. Исходный код разработанных модулей для управления процессом поиска информации на страницах расписания представлен в приложении Ж. 2.2.3 Разработка web-интерфейса просмотра расписания Для разработки графического интерфейса расписания аудитории использовались такие технологии как Django, html, css. В начале был разработан Html-шаблон (рисунок 2.9). 45

Рисунок 2.9 – Html-шаблон расписания С помощью фреймворка Django данный шаблон заполняется данными о расписании. Будучи веб-фреймворком, Django позволяет динамически генерировать HTML. Самый распространенный подход - использование шаблонов. Шаблоны содержат статический HTML и динамические данные, рендеринг которых описан специальным синтаксисом. Django предоставляет бэкенд для собственной системы шаблонов, которая называется - язык шаблонов Django (Django template language, DTL), а также стандартный API для загрузки и рендеринга шаблонов, независимо от используемого бэкенда. Загрузка включает в себя поиск шаблона по названию и предварительную обработку, обычно выполняется загрузка шаблона в память. Рендеринг означает передачу данных контекста в шаблон и возвращение строки с результатом. 46

При обращении клиента по адресу /timetable/room/ (где вместо room указывается номер аудитории в формате номеркорпуса_номераудитории (напр. 1_336)) Django выполняет запрос к БД и формирует список занятий аудитории и отдает его Html-шаблону, в котором наряду в html-разметкой присутствует специальный код на языке DTL, обрабатываемые процессором шаблонов Django. С помощью данного кода происходит динамическая генерация html из полученных данных. Пример полученного таким образом расписания представлен на рисунке 2.10. Рисунок 2.10 – Пример динамически заполненного шаблона 47

2.2.4 Разработка мобильного приложения для просмотра расписания с использованием технологии дополненной реальности При разработке мобильного приложения использовались такие технологии как система проектирования графических приложений Unity3D и библиотека дополненной реальности Vuforia. Структура проекта Unity3D представляет собой дерево папок. На рисунке 2.11 приведена структура папок проекта Рисунок 2.11- Структура папок проекта Двумя основными папками являются: Assets и ProjectSettings. Другие папки генерируются на основе этих двух папок. Краткий обзор всех файлов и папок.  Assembly - CSharp-vs.csproj и Assembly-CSharp.csproj – Visual Studio (с окончанием — vs на конце файлов) и MonoDevelop файлы проекта созданные для C# скриптов.  Assembly-UnityScript-vs.unityproj и Assembly-UnityScript.unityproj – файлы проекта, но для скриптов JavaScript.  MobileUI.sln и MobileUI-csharp.sln - файлы проектов для интегрированных средств разработки (IDE), первая включает в себя проект с 48

языками — C #, JavaScript и Boo, в то время как второй файл — только для проекта с языком C # и предназначен для открытия в Visual Studio, потому что VS «не знает» скрипты JavaScript и Boo проекта.  MobileUI.userprefs и MobileUI -csharp.userprefs — конфигурационные файлы, где MonoDevelop сохраняет текущие файлы, точки восстановления, время и т.д.  Assets — папка, в которой хранятся все медиа ресурсы, в том числе скрипты, текстуры, звуки, анимации и т.д.  ProjectSettings — в этой папке хранятся все настройки проекта Unity, такие как физика, теги, настройки и т.д.  Library – локальный кэш для импортируемых файлов из папки Assets, при использовании внешней системы контроля версий (VCS) эта папка должна быть исключена из списка VCS.  QCAR – библиотека для распознавания изображений, входящая в состав системы дополненной реальности. На рисунке 2.12. изображено главное окно программы Unity3D Рисунок 2.12 - Главное окно программы Unity3D 49

Основной концепцией Unity3d является использование в сцене легко управляемых объектов, которые, в свою очередь, состоят из множества компонентов. расширение Создание их отдельных функциональности игровых с объектов помощью и последующее добавления различных компонентов позволяет бесконечно совершенствовать и усложнять проект. Влияние компонента на поведение или положение того или иного объекта в сцене (свойства компонента) определяется с помощью переменных компонента. Ресурсы (Assets) проекта – это строительные/составные блоки всех проектов Unity, в качестве которых могут быть использованы файлы изображений (текстур), 3D-моделей, звуковые файлы, которые будут использоваться при создании в качестве ресурсов. Поэтому в любой папке проекта Unity всегда существует подкаталог с именем Assets, где хранятся все файлы ресурсов. Когда какой-либо ресурс (например, геометрическая 3D-модель) используется в сцене игры, он становится в терминологии Unity игровым объектом (Game Object). Все эти объекты изначально имеют хотя бы один компонент, задающий его положение в сцене и возможные преобразования (компонент Transform). Переменные компонента Transform определяет положение (position), поворот (rotation) и масштаб (scale) объекта в его локальной декартовой прямоугольной системе координат X, Y, Z. Наличие переменных у каждого компонента обусловливает возможность обращения к ним из соответствующей программы (скрипта). Компоненты (components) в Unity3d имеют различное назначение – они могут влиять на поведение, внешний вид и многие другие функции объектов, к которым прикрепляются (attaching). Unity предоставляет множество компонентов различного назначения. Для обеспечения интерактивности различных 3D-приложений в Unity3d используются скрипты, которые также рассматриваются средой как компоненты. 50

Помимо JavaScript, Unity3d также предоставляет возможность использовать для написания скриптов языки C# и Boo (производный от языка Python). Для написания скриптов можно воспользоваться встроенным редактором Unity3d MonoDevelop. Готовая программа на Unity3D — это набор сцен, соединенных между собой. При разработке программы использовались 1 сцена - для отображения расписания с помощью технологии дополненной реальности. Разработка функциональной части. Функциональная часть приложения базируется на программах, написанных на языке программирования C#. К любому объекту в Unity3D может быть прикреплен компонент-скрипт, который будет выполнять заданную программу. Скрипт взаимодействует с внутренними механизмами Unity за счет создания класса, наследованного от встроенного класса, называемого MonoBehaviour. Класс представляет собой своего рода план для создания нового типа компонента, который может быть прикреплен к объекту. Каждый раз, когда скриптовый компонент присоединяется к объекту, создается новый экземпляр объекта, определенный планом. Имя класса берется из имени, которое было указано при создании файла. Имя класса и имя файла должны быть одинаковыми, для того, чтобы скриптовый компонент мог быть присоединен к объекту. Две функции, определенные внутри класса-наследника MonoBehaviour, являются основными.  функция Update - это место для размещения кода, который будет обрабатывать обновление кадра для игрового объекта. Это может быть движение, срабатывание действий и ответная реакция на ввод пользователя, в основном всё, что должно быть обработано с течением времени в игровом процессе. Чтобы позволить функции Update выполнять свою работу, необходимо инициализировать переменные, считать свойства и осуществить связь с другими игровыми объектами до того, как будут совершены какие-либо действия. 51

 функция Start будет вызвана Unity до начала игрового процесса (т.е. до первого вызова функции Update), и это идеальное место для выполнения инициализации.  В разработанном приложении были созданы следующие скрипты:  DataLoader.cs - отвечает за отправку запроса по сети Интернет на получения расписания аудитории.  MarkerTracker.cs – отвечает за отслеживание маркера дополненной реальности.  InputManager.cs - обработчик нажатия кнопки выхода. Разработка информационной части мобильного приложения. В разработанном приложении вся информация о расписании поступает подсистемы интеграции посредством обращения по сети Интернет из к соответствующим функциям REST-сервиса. При этом ответ приходит в виде JSON -строки, например: [ { "id": null, "room": "", "date": null, "time": "08:00", "end_time": "08:45", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "08:55", "end_time": "09:40", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "09:50", "end_time": "10:35", "week": null, "day": null, "group": "", "subject": "Свободно", 52

"instructor": "" }, { "id": null, "room": "", "date": null, "time": "10:45", "end_time": "11:30", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": 1652, "room": "1_336", "date": null, "time": "11:40", "end_time": "12:25", "week": null, "day": 1, "group": "18ИЭ1бп", "subject": "Интеллект.инф.системы", "instructor": "Усачев Ю.Е." }, { "id": 1630, "room": "1_336", "date": null, "time": "12:35", "end_time": "13:20", "week": null, "day": 1, "group": "18ИЭ1бп", "subject": "Интеллект.инф.системы", "instructor": "Усачев Ю.Е." }, { "id": 1317, "room": "1_336", "date": null, "time": "13:30", "end_time": "14:15", "week": null, "day": 1, "group": "18УК1бп", "subject": "Методы и средства измер.", "instructor": "Чекайкин С.В." }, { "id": 1326, "room": "1_336", "date": null, "time": "14:25", "end_time": "15:10", "week": null, "day": 1, "group": "18УК1бп", "subject": "Методы и средства измер.", "instructor": "Чекайкин С.В." }, { "id": null, "room": "", 53

"date": null, "time": "15:20", "end_time": "16:05", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "16:15", "end_time": "17:00", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "17:10", "end_time": "17:55", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "18:05", "end_time": "18:50", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "19:00", "end_time": "19:45", "week": null, "day": null, "group": "", "subject": "Свободно", "instructor": "" }, { "id": null, "room": "", "date": null, "time": "19:55", "end_time": "20:40", "week": null, "day": null, 54

"group": "", "subject": "Свободно", "instructor": "" } ] В свою очередь библиотека Vuforia имеет свою базу данных маркеров, используемых для определения местоположения для дополненной реальности. В качестве маркеров могут выступать QR-коды либо обычные изображения. При этом для того чтобы создать базу данных маркеров используется специальных web-интерфейс приведенный на рисунке 2.13. Рисунок 2.13 – Web-интерфейс для создания БД маркеров дополненной реальности С помощью данного интерфейса создаётся база данных маркеров дополненной реальности, которую впоследствии можно использовать в разрабатываемом мобильном приложении. Разработка префабов для приложения. Префаб (Prefabs) в терминологии Unity3D – это конструкция подготовленных объектов и компонентов, предназначенная для их многократного использования в проекте. Экземпляр префаба может быть добавлен в любое количество сцен, а также многократно в одну сцену. Все экземпляры являются ссылками на оригинальный префаб и, 55

фактически, его «клонами»; имеют те же свойства и компоненты, что и оригинальный объект. Префабы полезны, когда нужно создать несколько экземпляров сложного объекта. Альтернативным способом реализации многократного использования объектов и компонентов в проекте является создание новых объектов с помощью скрипта. Для разрабатываемого приложения был создан префаб для отображения расписания аудитории (Рисунок 2.14) Рисунок 2.14 – Префаб для отображения расписания аудитории При работе приложения данный префаб будет заполняться данными о расписании конкретной аудитории. Разработка алгоритма работы приложения. После объединения всех рассмотренных технологий вместе был разработан алгоритм работы приложения. Он сводится к следующим шагам: 1. Запустить приложение. 56

2. Запустить функцию сканирования маркера дополненной реальности через камеру мобильного устройства. 3. При обнаружении маркера определить его имя. 4. Выполнить GET запрос к системе интеграции по адресу /api/timetable/room/, где вместо room подставить название маркера. 5. Получить JSON ответ, заполнить соответствующие поля префаба для просмотра расписания и отобразить данный префаб на месте маркера дополненной реальности. 2.3 Руководство пользователя 2.3.1 Назначение и условия применения системы Система интеграции расписания ПензГТУ предназначена для обеспечения информацией о расписании различных внешних сервисов, а также для удобного вывода расписания по критериям пользователя. Функции автоматизированной системы отображения:  парсинг сайта расписания ПензГТУ при обновлении информации;  хранение и обновление данных о расписании в БД;  вывод расписания по заданному критерию(аудитории);  выдача расписания в текстовом формате обмена данными; 2.3.2 Подготовка к работе При подготовке к работе с системой отображения расписания необходимо локально установить Python 2.7, а также скопировать каталог с программным обеспечением на жесткий диск ПК. Для запуска системы необходимо вызвать терминал командной строки Windows, перейти в каталог системы, содержащим файл manage.py и выполнить команду python manage.py runserver (рисунок 2.15) 57

Рисунок 2.15 – Запуск подсистемы интеграции Затем необходимо проверить работу системы, набрав в адресной строке браузера http://127.0.0.1:8000/api/timetable/ (рисунок 2.16) Рисунок 2.16 – Проверка работоспособности системы 58

Следующим шагом необходимо запустить скрипт парсинга расписания сайта ПензГТУ для заполнения БД системы. Для этого необходимо перейти в каталог TimeTableParserScripts, расположенный в корневом каталоге системы и выполнить в терминале команду: phantomjs.exe tt_parser.js. Данная команда запускает процесс парсинга сайта расписания с помощью браузера PhantomJS (рисунок 2.17). Рисунок 2.17 – Процесс парсинга сайта расписания После завершения процесса парсинга, БД подсистемы интеграции будет заполнена данными о расписании. Для подготовки к работе мобильного приложения необходимо скопировать установочный пакет test.apk на мобильное устройство и открыть его через программу проводник, тем самым запустив процесс установки. 2.3.3 Описание операций Для проверки работоспособности подсистемы выдачи расписания в формате html необходимо перейти по ссылке расписания аудитории в формате 59

http://127.0.0.1:8000/timetable/room/ (где вместо room указывается номер аудитории в формате номеркорпуса_номераудитории (напр. 1_336) (рисунок 2.18). Рисунок 2.18 – Подсистема выдачи расписания в формате html Для проверки работоспособности подсистемы выдачи расписания в формате JSON необходимо перейти по ссылке расписания аудитории в формате http://127.0.0.1:8000/api/timetable/room/ (где вместо room указывается номер аудитории в формате номеркорпуса_номераудитории (напр. 1_336) (рисунок 2.19) 60

Рисунок 2.19 – Подсистема выдачи расписания в формате JSON Для проверки работоспособности мобильного приложения необходимо запустить его на выполнение на мобильном устройстве и навести на маркер указанный на рисунке 2.20. Рисунок 2.20 – Маркер дополненной реальности 61

При этом должно произойти соединение с сервером и при ответе сервера на экране должно быть выведено расписание аудитории 1-328 (рисунок 2.21) Рисунок 2.21 – Работа мобильного приложения 62

Заключение В результате выполнения выпускной квалификационной работы были исследованы основные направления деятельности диспетчерской службы ПензГТУ. Были проанализированы потоки данных и взаимодействие между внешними объектами относительно проектируемой системы и произведен анализ вариантов использования проектируемой автоматизированной системы. Затем была разработана концепция построения автоматизированной системы и определены ее основные функции. Таким образом, в результате разработки автоматизированной системы отображения расписания занятий ПензГТУ:  обеспечен однократный ввод в систему справочных данных («Аудитории», «Преподаватели», «Дисциплины», «Время», «Неделя»), которые используются при вводе оперативных данных и формировании расписания по заданному критерию;  реализовано формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») в формате JSON.  реализовано формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») и вывод в окно браузера.  разработано мобильное приложение для вывода расписания аудитории с помощью технологии дополненной реальности 63

Перечень принятых сокращений АС – автоматизированная система БД – база данных ДПД – диаграмма потоков данных ИО – информационное обеспечение ИП – информационный поток ЛВС – локальная вычислительная сеть НЖМД – накопитель на жестком диске ОЗУ – оперативно запоминающее устройство ПК – персональный компьютер ПО – программное обеспечение СУБД – система управления базами данных ЭВМ – электронная вычислительная машина 64

Список литературы 1. Интеграция информационных систем [Электронный документ] - Режим доступа: https://habrahabr.ru/post/117468/ (дата обращения 05.06.2020)– Загл. с экрана. 2. Регулярные выражения, пособие для новичков [Электронный документ] - Режим доступа: https://habrahabr.ru/post/115825/ (дата обращения 05.06.2020)– Загл. с экрана. 3. Regular expression [Электронный документ] - Режим доступа: https://en.wikipedia.org/wiki/Regular_expression/ (дата обращения 05.06.2020)– Загл. с экрана. 4. Парсинг сайта при помощи PhantomJS [Электронный документ] - Режим доступа: http://learndata.ru/phantomjs-casperjs-parsing/ (дата обращения 05.06.2020)– Загл. с экрана. 5. Парсинг сайта при помощи PhantomJS [Электронный документ] - Режим доступа: http://learndata.ru/phantomjs-casperjs-parsing/ (дата обращения 05.06.2020)– Загл. с экрана. 6. Сравнительный анализ форматов обмена данными, используемых в приложениях с клиент-серверной архитектурой [Электронный документ] Режим доступа: https://www.fundamental-research.ru/ru/article/view?id=38464 (дата обращения 05.06.2020)– Загл. с экрана. 7. Формат JSON [Электронный документ] - Режим доступа: https://ru.wikipedia.org/wiki/JSON (дата обращения 05.06.2020)– Загл. с экрана. 8. JSON и XML. Что лучше? [Электронный документ] - Режим доступа: https://habrahabr.ru/post/31225/ (дата обращения 05.06.2020)– Загл. с экрана. 9. Ногербек Н.Д. ОБЗОР MVC ВЕБ-ФРЕЙМВОРКОВ. – Томский политехнический университет. – 2 с. 10. ГОСТ 2.109-73 ЕСКД. Основные требования к чертежам. 11. ГОСТ 2.104-68 ЕСПД. Основные надписи. 12. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам. 65

13. ГОСТ 19.404-78 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению. 14. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. 15. ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. 66

ПРИЛОЖЕНИЕ А (обязательное) Спецификация 67

Обозначение Наименование ВКР-09.03.03-09-20 81 01 Разработка… (cм. титульный лист) Пояснительная записка ВКР-09.03.03-09-20 91 01 Схема программы Чертеж, 1 лист A1, файл СхемаПрог.vsd ВКР-09.03.03-09-20 92 01 Разработка… (cм. титульный лист) Схема работы системы Чертеж, 1 лист A1, файл СхемаРаботыС истемы.vsd ВКР-09.03.03-09-20 94 01 Схема ресурсов системы Чертеж, 1 лист A1, файл СхемаРес.vsd Диаграмма вариантов использования Плакат 1 лист фор. А1, файл DVI.vsd Модель БД Плакат 1 лист фор. А1, файл DB.vsd Структура пользовательского интерфейса Плакат 1 лист фор. А1, файл DB.vsd Инв. № подп. Подп. и да та Взам. инв. № Инв. № дубл. Подп. и дата Примечан 100 стр. ие Из Лист № докум. Подп. Дата м. Разраб. Крестин А.Ю. И.В. Пров. Чигирева Н. контр. Утв. ВКР-09.03.03-09-20 Разработка… (см. титульный лист) Спецификация Литера Лист 1 Листов 1 ПензГТУ , 68 гр. 16 ИЭ 1б