close

Вход

Забыли?

вход по аккаунту

Гришин Александр Игоревич. Сервис построения маршрутов в крупных торговых центрах: подсистема торгового центра

код для вставки
АННОТАЦИЯ
ВКР 65 с., 29 рис., 2 табл., 17 источников, 1 прил.
WEB-ПРИЛОЖЕНИЕ, НАВИГАЦИЯ, ТОРГОВЫЙ ЦЕНТР, ПОСТРОЕНИЕ
МАРШРУТОВ, ТЕХНОЛОГИЯ КЛИЕНТ-СЕРВЕР, МЕТОДОЛОГИЯ MVC.
Выпускная квалификационная работа посвящена разработке сервиса
построения маршрутов в крупных торговых центрах: подсистема торгового центра.
В первой главе выпускной квалификационной работы проведен анализ
методов позиционирования
и
навигации
в крупных
торговых
центрах.
Рассмотрены методы позиционирования в закрытых помещениях. Выполнен обзор
систем-аналогов и прототипов сервисов построения маршрутов в крупных
торговых центрах. Выявлены основные функциональные и нефункциональные
требования к подсистеме торгового центра.
Во второй главе разработаны спецификации программного обеспечения
подсистемы торгового центра. Определена архитектура сервиса построения
маршрутов в крупных торговых центрах. Спроектированы функциональная,
информационная и поведенческая модели программного обеспечения подсистемы
торгового центра.
В третьей главе осуществлено проектирование программного обеспечения
подсистемы торгового центра. Определена структура, логическая модель базы
данных и создан прототип интерфейса программного обеспечения подсистемы
торгового центра. Осуществлено проектирование алгоритма дополнения карт
сервиса.
В четвертой
главе описана реализация
программного
обеспечения
подсистемы покупателя, представлены физическая модель базы данных.
Приведены особенности реализации алгоритма создания и заполнения карт
сервиса. Разработан интерфейс программного обеспечения подсистемы торгового
центра.
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
7
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ
9
1.1 Анализ задачи сервиса для построения маршрутов в крупных
торговых центрах
9
1.2 Методы локального позиционирования в закрытом помещении
11
1.2.1 Метод распознавания шаблона
12
1.2.2. Метод позиционирования по точке доступа, к которой
присоединен клиент
12
1.2.3. Триангуляция
13
1.2.4. Ангуляция или позиционирование с определением угла
входящего сигнала
14
1.2.5. Метод дифференциации пространственных образцов
14
1.2.6. Технология инфракрасного и ультразвукового излучения
15
1.2.7. Технология Bluetooth Low Energy
16
1.2.8. Технология UWB
16
1.2.9. Технология координатных меток
17
1.3 Обзор и сравнительный анализ систем-аналогов и прототипов
мобильного приложения
18
1.4 Построение функциональной модели сервиса для построения
маршрутов в крупных торговых центров
21
1.5 Функциональные требования подсистемы торгового центра
24
1.6 Нефункциональные требования подсистемы торгового центра
25
5
2 ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ СЕРВИСА ДЛЯ
ПОСТРОЕНИЯ МАРШРУТОВ В КРУПНЫХ ТОРГОВЫХ
ЦЕНТРАХ. ПОДСИСТЕМА ТОРГОВОГО ЦЕНТРА
27
2.1 Архитектура программного обеспечения подсистемы торгового
центра
27
2.2 Функциональная модель программного обеспечения подсистемы
торгового центра
29
2.3 Информационная модель подсистемы торгового центра
34
2.4 Поведенческая модель подсистемы торгового центра
35
3 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
СЕРВИСА ДЛЯ ПОСТРОЕНИЯ МАРШРУТОВ В КРУПНЫХ
ТОРГОВЫХ ЦЕНТРАХ. ПОДСИСТЕМЫ ТОРГОВОГО ЦЕНТРА
42
3.1 Структура подсистемы торгового центра
42
3.2 Проектирование классов подсистемы торгового центра
45
3.2.1 Класс MarketController
45
3.2.2 Класс ShopController
47
3.2.3 Класс MapModel
48
3.2.4 Класс JsonController
48
3.3 Проектирование базы данных подсистемы торгового центра
49
3.4 Проектирование интерфейса подсистемы торгового центра
55
3.5 Проектирование алгоритма дополнения карты сервиса для
построения маршрутов в крупных торговых центрах
57
4 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
СЕРВИСА ДЛЯ ПОСТРОЕНИЯ МАРШРУТОВ В КРУПНЫХ
ТОРГОВЫХ ЦЕНТРАХ. ПОДСИСТЕМЫ ТОРГОВОГО ЦЕНТРА
60
6
4.1 Разработка физической модели базы данных подсистемы
торгового центра
60
4.2 Особенности реализации алгоритма создания и заполнения карт
сервиса для построения маршрутов в крупных торговых центрах
62
4.3 Разработка интерфейса подсистемы торгового центра
65
ЗАКЛЮЧЕНИЕ
68
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
69
ПРИЛОЖЕНИЕ А – ЛИСТИНГ ПРОГРАММЫ
71
УДОСТОВЕРЯЮЩИЙ ЛИСТ НА ДЕМОНСТРАЦИОННЫЙ
МАТЕРИАЛ
93
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
94
7
ВВЕДЕНИЕ
Повседневно идет строительство больших торговых центров по всей
России. Их количество растет с каждым днём. Розничным магазинам выгодно
арендовать помещения внутри них, в связи с большой посещаемостью таких
заведений. Для того что бы сдать больше площади современные ТЦ становятся
все больше и больше. Вместе с этим и растет количество объектов внутри.
Разно плановость зданий затрудняет поиск необходимого магазина конечному
покупателю. Каждый не раз сталкивался с ситуацией, когда зайдя в большой
торговый центр, точно не знаешь где искать нужный магазин. И в большинстве
своем поиск информации происходит с помощью стендов с картой торгового
центра. К сожалению, многие не смогут запомнить точное месторасположение
нужного магазина и поиск продолжится в импровизационном порядке.
Для избежание такой ситуации на помощь приходят смартфоны.
Современный человек, в большинстве своем, каждый день использует свой
мобильный для поиска нужной информации, общения и развлечения. Если во
времена появления они предназначались исключительно для связи с людьми, то
в наше время мобильные устройства берут на себя часть необходимых функций
для человека. Тем самым, облегчают ему жизнь.
Для решения вышеприведенных проблем предлагается использование
сервиса для построения маршрутов, которое поможет людям ориентироваться в
крупных торговых центрах и давать нужную, конкретную информацию о
интересующих его магазинах. Тем самым повысить лояльность и расположить
его к посещению конкретного торгового центра. Возможность использования
карт плана зданий в мобильном приложении имеет большое значение для
каждого человека. При правильной организации информации на картах,
пользователь может получить всю доступную информацию о магазинах,
включая его описание, акции, виды предоставляемого товара и точное
местоположение внутри торгового центра.
8
Целью разработки мобильного приложения является предоставление
информации о магазинах торгового центра, построение карт и удобной
навигации по ней.
Основными задачами работы являются:
-
анализ предметной области и формирование требований к
подсистемы торгового центра сервиса для построения маршрутов в крупных
торговых центрах
-
анализ приложений-аналогов;
-
проектирование серверной части приложения для построения
маршрутов в крупных торговых центрах, включая описание структур данных и
структурную схему приложения;
-
разработка серверной части приложения для построения маршрутов
в крупных торговых центрах;
-
разработка
проектирование
логики
и
описание
диалога
с
алгоритмов
клиентской
работы
частью
приложения,
и
разработку
графического интерфейса веб-приложения для удобной работы с базой данных.
9
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ
1.1 Анализ задачи сервиса для построения маршрутов в крупных торговых
центрах
В последнее время на просторах интернета появилось множество
различных сервисов, взаимодействующих с торговыми центрами. Несмотря на
их огромное разнообразие, очень мало сервисов завоевали большую
популярность у пользователей.
Развитие магазинов, строительство крупных торговых центров и
стремительный рост посетителей, повышает необходимость разработки
мобильных приложений, связанных с тематикой шопинга. Для того чтобы
получить необходимую информацию о магазинах торгового центра, приходится
скачать большое количество приложений, или посетить огромное количество
интернет сервисов, что отнимает много времени у пользователя, а так же
занимает большое количество памяти в смартфонах или планшетах.
Так же стоит обратить внимание, что большинство магазинов не имеют
собственного сервиса или сайта, в котором бы находилась информация об
акциях, скидках или проводимых мероприятиях. Это усложняет жизнь как
магазинам, так и покупателям. На отечественном рынке совсем недавно
разработчики стали выпускать подобные приложения. Используя данные в
виде: справочной информации о магазинах, акциях, мероприятиях и его
расположении
в
торговом
центре,
относительно
легко
повышается
результативность посещения пользователем.
Появление
дополнительных
способов
взаимодействия
между
посетителями и магазинами, а также создания дополнительных услуг для них
должно находиться на пике популярности в разрабатываемых мобильных
приложений с точки зрения возможностей их применения в сфере шопинга.
Подобные, дополнительные способы взаимодействия с посетителями и
оказания им дополнительных услуг могут предложить сервисы путеводители в
торговом центре, активно развивающиеся в последние годы.
10
Основной задачей разрабатываемого сервиса является предоставление
максимально возможной информации о торговых центрах, возможность
просмотра всех магазинов отдельного торгового центра(ТЦ) и построение
маршрута внутри них. Сервис построения маршрутов в крупных торговых
центрах состоит из веб-интерфейса, где осуществляется добавление, удаление и
редактирования
предоставляющая
всей
информации
возможность
сервиса
и
пользователям
мобильное
находить
приложение
полезную
информацию о торговых центрах конкретного города, позволяет просматривать
текущие акции, скидки, новые коллекции магазинов, мероприятия ТЦ, также
хранит описание и информацию о конечном магазине (телефон, ссылка на сайт,
социальные сети). У каждого ТЦ существует собственная карта помещения с
нанесенными на ней магазинами. Распределение плана здания осуществляется
по этажам. Основной задачей сервиса является информирование пользователя
о предстоящих акциях и упрощение ориентирования в большом ТЦ.
Пользователь в начале работы с приложением осуществляет знакомство с
методами работы и функциями приложения по средством небольшой
презентации, далее может выбрать конкретный ТЦ, и перейти на карту данного
здания. Все элементы карты динамичны и обрабатывают нажатие, путем
подсветки нажатой области (конкретного магазина). После чего, выбирается
объект ТЦ рядом с которым находится пользователь и определяется конечная
точка маршрута. Приложение с помощью вычислений определяет оптимальный
маршрут и для большей наглядности отображает его на экране смартфона.
Следующей полезной опцией приложения является определение магазинов по
критериям. Пользователь сможет исходя из списка критериев выбрать
необходимые и приложение подсветит только те магазины, которые подходят
по данному критерию, что весьма удобно при поиске определенного вида
товара. Таким образом в рамках дипломной работы представлен сервис,
предоставляющий возможность:
1) через мобильное приложение:
11
а)
просматривать и выбирать торговый центр, подключенный к
данному сервису;
б)
получать информацию о торговом центре и розничных
магазинах конкретного торгового центра;
в)
просматривать схемы зданий торговых центров;
г)
строить маршрут в выбранном торговом центре;
д)
просматривать акций и скидки розничных магазинов.
2) через веб-интерфейс:
а)
производить регистрацию новых пользователей в системе;
б)
осуществлять добавление и удаление торговых центров из
системы;
в)
разграничивать права доступа сотрудников торговых центров;
г)
производить заполнения информации о торговых центрах и
розничных магазинах;
д)
отслеживать корректность информации о скидках и акциях;
е)
добавлять
планы
зданий
торговых
центров
и
ориентировочных меток.
1.2 Методы локального позиционирования в закрытом помещении
В настоящее время замечается рост интереса к решению проблемы
определения местоположения различных объектов. Местоположение может
быть вычислено как в глобальных, так и в локальных координатах. Системы
глобального позиционирования, такие как GPS и ГЛОНАСС, получили
огромное распространение благодаря широкому охвату и достаточно высокой
точности вне помещений. Однако такие системы оказываются невозможными
внутри зданий из-за помех от аппаратуры в помещениях, а также поглощения
сигнала корпусом самого здания.
Решить
данные
задачи
предстоит
системам
локального
позиционирования. Одним из предназначением данных систем является
определение
местоположения
объектов
внутри
помещений.
Основным
12
преимуществом систем локального позиционирования является возможность
развернуть эту услугу на основе уже построенной сети [2].
Для решения задачи позиционирования необходимо иметь набор
измерений показателя уровня принимаемого сигнала как минимум, от 3 точек
доступа. Точки доступа, измерения с которых формируют набор, в общем
случае работают на трех разных каналах: первый, шестой и одиннадцатый, это
связано с работой стандартов IEEE 802.11. Если точка доступа не передаёт и не
принимает, она находится в режиме мониторинга своего канала [2].
Позиционирование в локальных беспроводных сетях можно реализовать
несколькими способами:
1.2.1 Метод распознавания шаблона
Данный метод исходит из того, что в каждой точке устройство видит
уникальную радио картину. Устройство сканирует радио обстановку – точки
доступа и уровень их сигналов, сверяет полученную схему радиосигналов со
списком шаблонов и находит координату устройства. Для настройки всей сети
необходимо
провести
длительный
процесс
сканирования
эфира
всего
помещения, а также проводить регулярную калибровку данных, так как в
реальности в помещениях постоянно происходят изменения.
Метод обладает преимуществом низких затрат на оборудование, но при
этом стоимость владения таким решением будет высокой, а точность
позиционирования низкой.
1.2.2. Метод позиционирования по точке доступа, к которой присоединен
клиент
Данный способ имеет преимущество простоты, но его точность низка.
Зона действия беспроводной сети может быть довольно большой, диаметр сети
может быть 50 метров и более [2]. Этот метод позволяет определить только
присутствие клиента. Определить точное местоположение невозможно.
13
1.2.3. Триангуляция
Алгоритм триангуляции – это геометрический подход, позволяющий по
трем или более точками доступа позиционировать клиента. Он основан на
вычислении расстояний между клиентом и, как минимум, тремя точками
доступа [1].
Этот метод заключается в том, чтобы определить силу сигнала от клиента
на точках доступа Wi-Fi и в зоне пересечения возможного расположения
клиента относительно каждой точки с позиционировать устройство. Данный
метод является довольно информативным. Для его эффективной работы
необходимо точки доступа расположить по периметру помещения и в центре
таким образом, чтобы каждая точка в пространстве находилась в зоне трехчетырех точек доступа Wi-Fi [1]. При правильном развесе точек доступа он
позволяет с высокой вероятностью определить координату клиента с точностью
до пяти метров [1]. Препятствия на пути радиосигнала будут мешать точности
определения координаты. Статичные препятствия необходимо смоделировать,
а движущиеся неминуемо будут оказывать негативное влияние на точность.
Схема работы алгоритма (рисунок 1).
Рисунок 1 – Принцип работы алгоритма триангуляции
14
К основным достоинствам алгоритма можно отнести высокую точность и
независимость от предварительных вычислений. Основными недостатками
являются необходимость тщательного построения модели распространения
сигнала и необходимость постоянной калибровки параметров среды, в которой
распространяется Wi-Fi сигнал.
1.2.4. Ангуляция или позиционирование с определением угла входящего
сигнала
Данный метод является революционной разработкой Cisco, позволяющей
добиться метровой точности позиционирования Wi-Fi клиента. Внешний
модуль точного позиционирования, подключенный к модульной точке доступа
Cisco Aironet, со специальной антенной позволяет дополнительно определить
угол, под которым пришел сигнал и сузить сегмент возможного нахождения
Wi-Fi клиента до луча. Применяя метод триангуляции к такой информации от
трех-четырех точек доступа, можно получить координату, с высокой
вероятностью дающую точность до одного метра [1].
1.2.5. Метод дифференциации пространственных образцов
Этот метод основан на измерении мощности сигнала от всех точек
доступа и сравнение полученных значений с образцами измерения мощности
сигнала в заранее определенных координатах помещения [3]. Выделяют два
этапа в процессе работы алгоритма:
− предварительные измерения векторов, состоящих из значений
мощности сигнала от всех точек доступа. На данном этапе происходит
измерение образцов в различных координатах и сохранение их в базе данных
[3];
− определение местоположения клиента. На данном этапе происходит
измерение вектора сигналов от клиента и последующее сравнение его с
образцами, хранящимися в базе данных [3]. Этапы работы алгоритма
(рисунок 2).
15
Рисунок 2 – Этапы в процессе работы алгоритма дифференциации
пространственных образцов
К преимуществам алгоритма относят высокую точность. При достаточно
большой плотности предварительных измерений погрешность можно свести
практически до нуля. Однако из преимуществ данного метода вытекают и его
недостатки: необходимость большого объема предварительных измерений и
обновление их с учетом изменений в среде [3].
1.2.6. Технология инфракрасного и ультразвукового излучения
В системах локального позиционирования при помощи инфракрасного
излучения
координаты
рассчитываются
по
времени
прохождения
периодического импульса, испускаемого объектом, от источника до приемника.
Недостатками данного метода являются помехи от солнечного света и
невысокая относительная точность. Используя инфракрасный лазер, можно
повысить точность измерений до 10 сантиметров, однако это дорогостоящие
системы.
Система позиционирования в режиме реального времени на базе
ультразвуковых датчиков работают по аналогичному принципу источникприемник. На объекте устанавливается источник ультразвуковых волн, а
приемники размещаются в помещении в определенном порядке. Для
вычисления координат на плоскости достаточно получать данные с трех
16
приемников. Для определения положения в пространстве, включая высоту,
необходимо иметь не менее четырех приемников волн. Точность измерения в
идеальных условиях достигает порядка трех-пяти сантиметров. Недостатком
данного способа является необходимость строго планирования размещения
датчиков-приемников ультразвуковых волн.
1.2.7. Технология Bluetooth Low Energy
На базе беспроводной технологии Bluetooth LE реализован один из
методов
измерения
расстояния
по
уровню
радиосигнала.
Основными
достоинствами данной технологии является компактный размер устройства и
сверхмалое энергопотребление. В качестве сенсоров служат карманные
Bluetooth-передатчики,
координаты
которых
постоянны
и
известны.
Передатчики с заданной периодичностью производят широковещательную
рассылку, содержащую их собственную идентифицирующую информацию.
Объект получает эти данные и на основе силы сигнала, следовательно,
удаленности от каждого из сенсоров, определяет свое местоположение. Пример
работы алгоритма представлен на рисунке 3.
Рисунок 3 – Варианты архитектуры систем позиционирования а)
беспроводная архитектура; б) проводная архитектура
1.2.8. Технология UWB
UWB - одна из радиочастотных технологий, позволяющая создать
систему позиционирования в режиме реального времени в помещении. В
17
России сигналы UWB называются сверхширокополосными сигналами. Такие
сигналы распространяются с частотой 3-10 ГГц и маленькой мощностью. Сверх
широкая полоса пропускания обеспечивает более точное измерение расстояния
по
сравнению
с
другими
радиочастотными
технологиями.
Точность
определения координат может достигать нескольких сантиметров, что и
необходимо для робототехнических систем. Сверхширокополосные сигналы не
зависят от многолучевого распространения благодаря очень коротким
импульсам, не более одной нано секунды, то есть отраженный сигнал приходит
уже после того как был передан основной. Практическая реализация
представляет собой устройство – передатчик, закрепленный на объекте, три и
более стационарных точек – приемников сигнала. По известным координатам
точек – приемников и временем получения сигнала от передатчика вычисляется
местоположение объекта.
Каждый из методов позиционирования обладает как плюсами, так и
минусами. Алгоритмы, в которых отсутствует стадия предварительных
вычислений, показывают более низкую точность по сравнению с методами, у
которых
она
вычисления,
есть.
Однако
являются
методы,
сложными
в
использующие
конфигурации
предварительные
базы
данных
и
подразумевают статичную среду, либо требуют регулярную калибровку
измерений, хранящихся в базе данных. Комбинирование различных методов
позволит значительно повысить точность результата и меньше зависеть от
изменений в среде распространения сигнала.
1.2.9. Технология координатных меток
Данный
метод
определяет
местонахождения
пользователя
путем
предоставления пользователю перечень меток на карте. Далее происходит
выбор ближайшей метки по отношению к реальному местоположению
пользователя. Каждая метка отвечает за отдельный объект торгового центра.
После выбора метки определяется приближенное положения человека в здании,
этого
будет
достаточно
для
формирования
маршрута
следования
до
18
необходимого объекта торгового центра. Одним из преимуществ данного
метода является полное отстранение от аппаратной части – все методы
представленные выше требовали необходимой аппаратуры для вычисления
местонахождения пользователя в здании. Данная технология осуществляется
путем добавления к плану зданий торгового центра координаты будущих
меток. Каждой метки дается название соответствующее объекту торгового
центра, к которой она прикреплена. Технология позволяет в кротчайшие сроки
добавлять в приложение новые торговые центры.
Таким образом данная технология полностью обеспечивает необходимую
функциональность программного обеспечения, которая позволит решить
поставленные задачи по реализации сервиса построения маршрутов в крупных
торговых центров.
1.3 Обзор и сравнительный анализ систем-аналогов и прототипов
мобильного приложения
Что
бы
выделить
преимущества
разрабатываемой
подсистемы
необходимо рассмотреть аналоги, в качестве которых выступают приложения
являющиеся
лидерами
рынка
подобных
сервисов,
направленных
на
информирование посетителей торговых центров: Аэоробонус, InfoShopping,
Едадил. Естественно, это не единственные приложения с необходимым
функционалом, но они представляют особенный интерес для анализа
прототипов и аналогов, так как содержат в себе некоторую часть функций
разрабатываемого мобильного приложения. Все они основаны на одном
принципе - упростить взаимодействие пользователя с торговым центром.
Некоторые из подобных сервисов предоставляют возможность, построения
маршрута от текущего местоположения в торговом центре, до конкретного
магазина.
Как
правило,
такие
приложения
повышают
уровень
заинтересованности пользователей.
В основном мобильные приложения располагаются в магазинах
приложений. На данный момент существует два крупных магазина: Google Play
19
– для мобильных приложений под операционной системой (далее - ОС) Android
и App Store – для приложений под ОС iOS. Так как в данной дипломной работе
проектируется и разрабатывается мобильное приложение под ОС Android, то
приложения-аналоги будут рассматриваться из магазина Google Play.
Рассмотрим несколько крупных систем, предоставляющие пользователям
информацию как о торговом центре в целом, так и о магазинах расположенных
в нем. Представленные приложения информирует огромное число посетителей,
помогает выбрать нужный магазин и сэкономить драгоценное время. Ниже
приведено краткое описание каждого из приведенных аналогов.
1)
аэоробонус
-
бесплатное
приложение
для
потенциальных
покупателей торгового центра «АЭРО ПАРК», направленное на увеличение
покупательской активности в магазинах арендаторов, расположенных в
торгово-развлекательном центре в городе Брянск. Приложение имеет удобный
и простой интерфейс, у него есть возможность накапливания бонусов за
покупки, которые в дальнейшем можно обменять на подарки. Весь каталог
ресторанов и магазинов торгового центра можно увидеть на интерактивной
карте, а так же есть возможность построения маршрута от конкретных точек, до
нужного
магазина.
Недостатками
приложения
является
невозможность
функционирования его в режиме, независимым от интернета.
2)
infoShopping - это проработанное приложение с приятным дизайном
и стабильной функциональностью. Оно работает практически со всеми
торговыми центрами города Москвы. Посетитель используя приложение
"infoShopping" на схеме торгового центра видит сразу все интересующие его
скидки, акции и прочие специальные предложения. Приложение содержит
полную и актуальную информацию о торговых центрах, перечне их магазинов,
времени работы и наличии парковки, а так же содержит удобные карты
торговых центров, которые помогут легко найти нужный магазин, банкомат,
ресторан или машину на парковке.
3)
eдадил - простое приложение для вашего смартфона. Приложение
автоматически определяет город пользователя и показывает все магазины по
20
каталогам, которые ему доступны. Есть возможность зайти внутрь нужного
каталога и посмотреть все акции. Все товары также разбиты по категориям.
Приложение также показывает адреса всех магазинов-партнеров в городе на
карте. Чтобы не забыть все заинтересовавшие скидки приложение позволяет
сформировать корзину для похода в каждый магазин. По истечении срока
действия акции корзина показывает, что время для выгодных покупок прошло.
В приложении «Едадил» нет возможности просматривать карту торгового
центра, это можно отнести к его существенным недостаткам.
В таблице 1 представлена сравнительная характеристика основных
функций приложений-аналогов и разрабатываемого мобильного приложения.
Таблица 1 – Сравнительная характеристика разрабатываемого мобильного
приложения с аналогами
Функции /
Аэоробонус InfoShopping Едадил Разрабатываемое
Приложение
Наличие карт
помещений
Построение
маршрута
Перечень акций,
мероприятий
Поиск по
категориям
Многообразность
выбора ТЦ
приложение
Да
Да
Нет
Да
Да
Нет
Нет
Да
Да
Да
Да
Да
Да
Нет
Да
Да
Нет
Да
Нет
Да
21
1.4 Построение функциональной модели сервиса для построения
маршрутов в крупных торговых центров
Сервису предназначенному для построение маршрутов в крупных
торговых центрах и предоставления необходимой информации о розничных
магазинах была построена функциональная модель, представленная в виде
диаграммы вариантов использования для выделенных актеров. В системе
присутствуют 3 актера:
1)
пользователь – любой человек, использующий сервис в качестве
средства для получения необходимой информации и построения маршрутов в
крупных торговых центрах.
2)
сотрудник ТЦ – зарегистрированный пользователь, производящий
взаимодействие с магазинами и планом здания определенного торгового
центра.
3)
администратор – пользователь, производящий все манипуляции с
базой данных, в их числе добавление, редактирование, удаление информации.
Также выполняющий проверку на актуальность предоставляемых данных в
приложении, своевременную замену устаревших сведений и обновление
существующих.
У пользователя (рисунок 4) есть возможность просматривать все
добавленные торговые центры в систему, знакомится с интересующей
информацией в описании торгового центра, переходить в социальные сети и
официальный сайт. Для каждого центра пользователь может посмотреть план
этажей,
представляющих
собой
интерактивную
карту
с
динамичным,
отзывчивым интерфейсом, где есть возможность искать интересующий магазин
на карте с помощью строки поиска с дальнейшей подсветкой найденного
магазина. В разделе с картами пользователь может выбрать категорию товаров
из предложенного списка и система определит наиболее подходящие магазины,
специализирующиеся на данном виде товара. Здесь же люди, использующие
приложения, смогут ознакомится с действующими акциями и скидками
конкретных розничных точек. И основной функциональной частью данного
22
раздела приложения является построение маршрутов. Пользователь для
построения пути должен выбрать магазин или иной объект, рядом с которым он
находится и далее определить конечную точку движения, это также может быть
любой объект торгового центра, далее система на серверной стороне
высчитывает маршрут и отправляет в мобильное приложение, где поверх
открытой карты будет производится анимационное отображение маршрута.
В основном разделе приложения пользователь может осуществлять поиск
всех розничных магазинов включенных в приложение. Просматривать
информацию о них, переходить в социальные сети или сайт, выяснять в каких
торговых центрах расположен данный магазин. С точки зрения системы
обычный пользователь через приложение формирует запросы к серверу, а
приложение в свою очередь обрабатывает ответ и отображает на экране
смартфона.
Рисунок 4 – Диаграмма вариантов использования для пользователя
Вторым актером является сотрудник торгового центра (рисунок 5). Его
учетную
запись
создает
администратор
сервиса,
после
добавления
определенного торгового центра в систему. Актер добавляет магазины в базу
данных, которые находятся на территории торгового центра, где он является
ответственным лицом по заполнению информации.
Также отвечает за
наполнения информации о магазина и сопровождения корректной, актуальной
информации о нём. У него есть возможность удалять, редактировать и
23
добавлять акции и скидки конкретного магазина. Исходя из того, что акции и
скидки это временные записи, необходимо будет отслеживать корректность
информации о них, путем осуществления выборки из базы данных акций и
скидок конкретного магазина. Существенной задачей сотрудника торгового
центра является добавления плана этажей торгового центра. Заполнение
данного изображения метками, которые в дальнейшем будут служить
ориентиром конечному пользователю приложения, то есть каждая метка будет
характеризовать определенный магазин в торговом центре. При смене
планировки здания, сотруднику будет доступна возможность изменять
хранимые метки и планы зданий на новые.
Рисунок 5 – Диаграмма вариантов использования для сотрудника ТЦ
Третьим актером является администратор (рисунок 6). Он является супер
пользователем системы - в его распоряжения все манипуляции с базой данных.
Соответственно, администратор добавляет все данные через веб-интерфейс, а
именно - информацию по торговому центру и учетным данным сотрудников
торгового центра.
Также веб – интерфейс позволяет производить редактирование записей,
для этого необходимо сделать выборку по определенному критерию и
дополнительной форме изменить существующие данные. В любой момент
времени администратор может производить поиск и осуществлять просмотр
24
всех добавленных записей, для удобного отслеживания состояния базы данных.
В возможности администратора входит добавление новых торговых центров с
будущим добавлением ответственного сотрудника по заполнению информации
о магазинах в конкретном торговом центре.
Рисунок 6 – Диаграмма вариантов использования для администратора
Администратор является лицом сервиса и все сотрудники торговых
центров при возникновении ошибок или некорректной работы сервиса
обращаются за помощью к данному актеру.
1.5 Функциональные требования подсистемы торгового центра
Подсистема торгового центра сервиса построения маршрутов в крупных
торговых центров должна включать в себя:
1)
загрузка информации о торговых центрах, розничных магазинах,
акциях и скидках с помощью JSON файла и загрузка единичных записей в вебинтерфейсе администратора и сотрудника торгового центра;
2)
просмотр всей добавленной информации. Так же необходима
возможность удаления и редактирования записей о торговых центрах,
розничных магазинах, акциях, скидках, мероприятиях;
3)
обнаружение и вывод ошибок при загрузки информации;
25
4)
обработка запросов с веб- интерфейса и мобильного приложения,
формирование JSON ответа.
1.6 Нефункциональные требования подсистемы торгового центра
Для разрабатываемой подсистемы торгового центра сервиса построения
маршрутов в крупных торговых центрах можно выделить следующие
нефункциональные требования:
-
реализация веб – интерфейса для администратора и сотрудника
торгового центра (требования к эксплуатации);
-
использование
архитектуры
REST
API
(требования
к
эксплуатации);
-
обеспечение максимальной производительности загрузки данных
(требования к производительности);
-
обеспечение разумного времени отклика для работы с запросами
клиентской части приложения (требования к эффективности);
-
обеспечение
надежности
передачи
данных
(требования
к
надежности);
-
поддержка целостности и безопасности данных, обусловленные
нарушениями в работе web-сервера (требования к надежности);
-
использование технологии AJAX, языков PHP, фраймворка Yii2[4],
JavaScript, система управления базами данных (СУБД) MySQL, формата
передачи данных JSON (требования к реализации);
-
обеспечение удобочитаемого представления ошибок (требования к
этичности);
-
ориентированность на конечных пользователей (требования к
удобству использования);
-
подсистема должна иметь возможность расширяться за счет
добавления нового функционала поиска, либо внедрения возможности загрузки
данных, используя формат передачи, отличный от установленного (требования
к расширяемости);
26
-
подсистема должна выявлять попытки нарушения целостности и
безопасности данных путем выявления угроз, связанных с внедрением
вредоносного кода, несанкционированным доступом, либо иным действиями,
способными нарушить работоспособность всей информационной системы или
внести
какие-либо
изменения
в
хранимую
информацию
уполномоченного лица (требования к безопасности).
без
ведома
27
2 ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ СЕРВИСА ДЛЯ ПОСТРОЕНИЯ
МАРШРУТОВ В КРУПНЫХ ТОРГОВЫХ ЦЕНТРАХ. ПОДСИСТЕМА
ТОРГОВОГО ЦЕНТРА
2.1
Архитектура программного обеспечения подсистемы торгового
центра
Сервис для построения маршрутов в крупных торговых центрах строится
на основе архитектуры REST API и способа проектирования веб-приложений
по методологии MVC [11] (рисунок 7). Данная архитектура обеспечивает
взаимодействие клиентских частей программного обеспечения и серверной
части.
Рисунок 7 – Архитектура сервиса для построения маршрутов в крупных
торговых центрах
REST API - это общие принципы организации взаимодействия
приложения или сайта с сервером посредством протокола HTTP[12].
Особенность REST в том, что сервер не запоминает состояние пользователя
28
между
запросами
идентифицирующая
-
в
каждом
пользователя
и
запросе
все
передаётся
параметры,
информация,
необходимые
для
выполнения операции.
Всё взаимодействие с сервером сводится к 4 операциям:
1)
получение данных с сервера (обычно в формате JSON, или XML);
2)
добавление новых данных на сервер;
3)
модификация существующих данных на сервере;
4)
удаление данных на сервере.
Для каждого типа операции используется свой метод HTTP-запроса:
1)
получение – GET;
2)
добавление – POST;
3)
модификация – PUT;
4)
удаление – DELETE.
Принцип работы данной архитектуры следующий:
На сервере реализовано взаимодействие с базой данных и также варианты
сформированных URL запросов, при вызове которых происходит отправка
JSON[9] файла на запрашиваемый объект. Следовательно, клиентские части,
для получения данных отправляют запрос на конкретный адрес и ответом
получают
JSON
объект,
который
в
дальнейшем
раскодируется
и
обрабатывается в связи с нуждами системы. Таким образом, это позволяет
реализовать общую часть один раз для разных клиентских подсистем(веб –сайт
/ android – приложение). Например, необходимо получить список всех торговых
центров. На сервере реализован запрос на языке SQL к базе данных, который
результатов выдает список всех торговых центров. Далее с помощью
встроенных функций фрэймворка YII2[5] генерируется адрес, по которому
любое клиентское приложение может получить результат этого SQL запроса в
виде JSON[10]. Соответственно, веб-сайт и android-приложение по данному
адресу будут получать список всех торговых центров с будущей обработкой
полученной информацией.
29
2.2 Функциональная модель программного обеспечения подсистемы
торгового центра
В качестве средства для предоставления функциональной модели
подсистемы торгового центра была использована диаграмма вариантов
использования (рисунок 8). В качестве основных актеров данной подсистемы
выделяются:
1)
сотрудник ТЦ – зарегистрированный пользователь, производящий
взаимодействие с магазинами и планом здания определенного торгового
центра;
2)
администратор – пользователь, производящий все манипуляции с
базой данных, в их числе добавление, редактирование, удаление информации.
Также, выполняющий проверку на актуальность предоставляемых данных в
приложении, своевременную замену устаревших сведений и обновление
существующих.
У каждого актера выделяются его основные функции в системе, на
диаграмме функции выписываются в отдельный круг. Далее каждое общее
действие может быть расширенно более детализированным действием, либо
включено в большую функцию актера. На диаграмме стрелки показывают
взаимосвязь каждой функции с другими, так же проведена линия от
конкретного актера к тем функциям, которые являются основополагающими у
него. Далее эти функции конкретизируются до того момента, пока их
реализация не состоит конечного метода или перечня некоторых методов в
объектном
функциями
подходе.
Динамика
наглядно
действий
представляется
осуществляемых
основными
с
диаграммы
помощью
последовательности или диаграммы деятельности.
Диаграммой
последовательности
описаны
функции
«Просмотр
и
редактирование информации о торговых центрах» (рисунок 9), а также
«Редактирование и удаление розничного магазина» (рисунок 10).
30
Рисунок 8 – Физическая модель подсистемы торгового центра
31
Рисунок 9 – Модель процесса «Просмотр и редактирование информации
о торговых центрах»
На рисунке 9 определенны конкретные действия, в ходе которых будет
выполнен
просмотр
информации
о
торговом центре. Для просмотра
информации о торговом центре сотруднику достаточно найти и нажать кнопку
«Торговый центр», после чего, будет выведена вся необходимая информация.
Для ее редактирования справа каждого поля будет находится кнопка
«Редактировать», с помощью которой, сотрудник переключается в режим
редактирования – конкретное поле становится полем для ввода, то есть
сотрудник сможет добавлять, удалять или изменять существующий текст.
Данное решение полностью реализуется на стороне клиента с помощью
Javascript, только после нажатия кнопки «Сохранить» вся измененная
информация отправляется на сервер и записывается в базу данных.
Диаграмма последовательности (рисунок 10), отражающая работу с
розничными
магазинами,
точнее
описывает
конкретные
действия
для
осуществления просмотра всех розничных магазинов конкретного торгового
центра, процесс редактирования и удаления, как частичной информации о
розничном магазине, так и полное удаление розничного магазина, например,
если данный магазин больше не арендует помещение в этом торговом центре.
32
Рисунок 10 – Модель процесса «Редактирование и удаление розничного
магазина»
Для
осуществления
предложенных
действий
сотруднику
будет
достаточно, путем нажатия кнопки «Розничные магазины», вывести весь
список магазинов, обслуживающего торгового центра, после чего, у каждого
розничного магазина будет кнопка «Редактировать» и «Удалить», которые
будет выполнять соответствующие действия.
На диаграмме вариантов использования одним из основных действий
является загрузка данных на сервер и сохранения их в базу данных. Для
детализации данного действия представлена диаграмма деятельности (рисунок
11). На данной схеме видно алгоритм, с помощью которого, производится
загрузка данных на сервер с сохранением в базу данных.
33
Рисунок 11 – Модель процесса «Загрузка данных»
В начале загрузки данных с помощью HTML5 и встроенного атрибута
«required» можно определить поля, которые будут являться обязательными при
отправки формы на обработку. Без заполнения этих форм данные не отправятся
и страница оповестит пользователя подсказкой, какие поля необходимо
заполнить. Далее, после того, как обязательные поля заполнены, скрипт
обработки
формы,
написанный
на
Javascript,
проверяет
правильность
34
введенных данных, например, в поле номера телефона должны быть только
цифры, без знаков латиницы. Если же первоначальная валидация не проходит,
то пользователь увидит сообщение, в котором будет подробно описано его
ошибка. В случае корректного заполнения формы, данные отправляются на
сервер, где проходят вторую валидацию. Это необходимо для того случая,
когда в браузере пользователя отключен Javascript и, следовательно, первая
валидация не будет осуществлена. При успешном прохождении, данные
записываются в базу данных, и пользователь видит сообщение об успешной
загрузке.
2.3 Информационная модель подсистемы торгового центра
Информационная модель [13] подсистемы торгового центра показывает
взаимосвязь и отношение выделенных сущностей на примере контекстной
диаграммы классов (рисунок 12).
Рисунок 12 – Информационная модель подсистемы торгового центра
Данная диаграмма показывает необходимые классы для реализации
поставленной задачи. Основным классом является «Торговый центр» и вся
остальная логика основывается на нём. В одном торговом центре существует
35
конечное множество розничных магазинов - связь на диаграмме один ко
многим.
Каждый магазин устанавливает свои, определенные скидки и акции на
конкретный период. Здесь связь один ко многим из-за того, что у магазина
может быть много акций и скидок, а вот одна акция не может распространяться
на несколько магазинов. В ином случае, каждая акция будет дублироваться для
конкретного магазина.
Класс «Мероприятия» относится как к торговому центру в целом, так и к
розничным магазинам. По данным классом понимается любая организационная
деятельность в рамках конкретного объекта.
Главным классом, взаимодействующим с маршрутами, будет являться
класс «Карта». В нём будет реализовано добавление плана зданий, добавление
контрольных точек, обозначающих объекты торгового центра.
Под классом «Объект ТЦ» будет пониматься все объекты торгового
центра, не относящиеся к розничным магазинам. Например, стенды,
банкоматы, туалеты, лавки, эскалаторы и многое другое. При чём, в одном
торговом центре, может быть большое множество таких объектов. И за
добавление, удаление, изменение информации об этих объектах будет отвечать
класс «Объект ТЦ».
2.4 Поведенческая модель подсистемы торгового центра
Поведенческая модель сервиса, с помощью диаграммы переходов
интерфейса пользователя «Сотрудник ТЦ» подсистемы торгового центра
(рисунок 13), отчетливо показывает все возможные переходы внутри
подсистемы, указывает возможные события между этими переходами и
основные механизмы работы.
36
Рисунок 13 – Диаграмма переходов интерфейса пользователя
«Сотрудник ТЦ» подсистемы торгового центра
37
Данная диаграмма описывает все переходы интерфейса подсистемы,
необходимые для реализации работы сотрудника торгового центра. Для более
детального рассмотрения всех состояний и переходов между ними, ниже
приведена таблица 2.
Таблица 2 – Таблица состояний
Состояние
интерфейса
Описание
Переход
Следующее
состояние
1
2
3
4
Вход в систему
Главное меню
Торговый центр
Отображение
Аутентификация
формы С вводом
пройдена
Логина/Пароля
2.
Аутентификац Аутентификация не
ия пользователя
пройдена
3.
Осуществление
входа
1.
1.
Приветственны
й экран
2.
Краткое
руководство
3.
Ожидание
действий
пользователя
Просмотр
информации о
торговом центре карточка торгового
центра
Главное меню
Вход в систему
Нажатие на кнопку
«Торговый центр»
Торговый центр
Нажатие на кнопку
«Розничные
магазины»
Розничные
магазины
Нажатие на кнопку
«Вторичные
объекты»
Вторичные
объекты
Нажатие на кнопку
«Выход»
Выход
Нажатие на кнопку
«Редактировать»
Редактирование
Нажатие на кнопку
«Добавить карту»
Редактор карт
Нажатие на кнопку
«Мероприятия»
Мероприятия
38
Продолжение таблицы 2
1
2
3
4
Розничные
магазины
Список всех
магазинов данного
торгового центра
Нажатие на
конкретный
экземпляр
Розничный магазин
Нажатие на кнопку
«Добавить
магазин»
Добавление
магазина
Нажатие на кнопку
«Удалить магазин»
Удаление магазина
Нажатие на
конкретный
экземпляр
Вторичный объект
Нажатие на кнопку
«Добавить объект»
Добавление
вторичного объекта
Нажатие на кнопку
«Удалить объект»
Удаление
вторичного объекта
Изменение
информации об
объекте
редактирования
Нажатие на кнопку
«Сохранить»
Сохранить
изменения
Нажатие на кнопку
«Отменить»
Отменить
изменения
Список всех
мероприятий данного
торгового центра
Нажатие на
конкретный
экземпляр
Карточка
мероприятия
Нажатие на кнопку
«Добавить
мероприятие»
Добавление
мероприятия
Нажатие на кнопку
«Удалить
мероприятие»
Удаление
мероприятия
Нажатие на кнопку
«Акции и скидки»
Акции и скидки
Вторичные
объекты
Редактирование
Мероприятия
Розничный магазин
Список всех
вторичных объектов
данного торгового
центра
Просмотр
информации о
розничном магазине –
карточка магазина
39
Продолжение таблицы 2
1
2
3
4
Добавление
магазина
1. Заполнение формы
ввода необходимой
информацией
Нажатие на кнопку
«Добавить»
Розничные
магазины
Нажатие на кнопку
«Отменить»
Розничные
магазины
Нажатие кнопки
«Удалить»
Розничные
магазины
Нажатие кнопки
«Отменить»
Розничные
магазины
Нажатие на кнопку
«Назад»
Вторичные
объекты
2. Отправка данных на
сервер
Удаление магазина
Удаление магазина из
базы данных.
Вторичный объект
Просмотр
информации о
вторичном объекте –
карточка объекта
Сохранить
изменения
1. Изменения
сохранены
Торговый центр
/Розничные
магазины
2. Отправление
данных на сервер
Отменить
изменения
Изменения отменены
Торговый центр
/Розничные
магазины
Карточка
мероприятия
Просмотр
информации о
мероприятии –
карточка мероприятия
Нажатие на кнопку
«Назад»
Мероприятия
Редактор карт
Форма для отправки
плана здания
Нажатие на кнопку
«Отправить»
Торговый центр
Нажатие на кнопку
«Отменить»
Торговый центр
40
Продолжение таблицы 2
1
2
3
4
Добавление
мероприятия
1. Заполнение формы
ввода необходимой
информацией
Нажатие на кнопку
«Добавить»
Мероприятия
2. Отправка данных на
сервер
Нажатие на кнопку
«Отменить»
Удаление
мероприятия
Удаление
мероприятия из базы
данных
Акции и скидки
Список всех акций и
скидок данного
розничного магазина
Добавление акций
и скидок
1. Заполнение формы
ввода необходимой
информацией
2. Отправка данных на
сервер
Удаление акций и
скидок
Удаление акции или
скидок из базы
данных
Мероприятия
Нажатие на кнопку
«Добавить акцию
или скидку»
Добавление акций
и скидок
Нажатие на кнопку
«Назад»
Розничный магазин
Нажатие на кнопку
«Добавить»
Акции и скидки
Нажатие на кнопку
«Отменить»
Нажатие на кнопку
«Удалить»
Акции и скидки
Нажатие на кнопку
«Отменить»
Добавление
вторичного объекта
1. Заполнение формы
ввода необходимой
информацией
2. Отправка данных на
сервер
Нажатие на кнопку
«Добавить»
Нажатие на кнопку
«Отменить»
Вторичные
объекты
41
Продолжение таблицы 2
1
2
3
4
Удаление
вторичного объекта
Удаление вторичного
объекта из базы
данных
Нажатие на кнопку
«Удалить»
Вторичные
объекты
1. Завершение сеанса
Нажатие на кнопку
«Выход»
Выход из системы
Нажатие на кнопку
«Отмена»
Главное меню
Выход
2. Выход из учетной
записи
3. Выход из системы
Нажатие на кнопку
«Отменить»
42
3 ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СЕРВИСА
ДЛЯ ПОСТРОЕНИЯ МАРШРУТОВ В КРУПНЫХ ТОРГОВЫХ
ЦЕНТРАХ. ПОДСИСТЕМЫ ТОРГОВОГО ЦЕНТРА
3.1 Структура подсистемы торгового центра
В основе физической структуры подсистемы торгового центра лежит
архитектура MVC (Model – View – Controller) [14]. Выбор данной архитектуры
обосновывается понятной структурой приложения, обособленной разработкой
отдельных частей и легкой возможностью масштабирования системы.
Для детального понимания будущего сервиса, было использована
физическая модель классов (рисунок 14). На данной схеме изображены
физические классы, которые будут реализованы по архитектуре MVC. Здесь
отчетливо видно каким образом будет происходить взаимосвязь между
Контроллером и Моделью. Каждый класс унаследованный от родительского
класса Controller будет иметь возможность обращаться ко всем классам
контроллерам [7]. Такими же свойствами обладает классы Моделей. Также
каждый Контроллер может создать экземпляр класса Модели и работать внутри
своих методов с полученным объектом. Это облегчает хранение информации в
момент выполнения конкретного скрипта.
По
схеме
видно,
как
происходит
выполнения
любого
запроса
пользователя. В момент перехода по конкретной ссылке отправляется запрос на
сервер, который обрабатывает конкретно вызванный контроллер. В каждом
контроллере предусмотрены «действия» - методы отвечающие за выполнения
определенных
алгоритмов
на
соответствующей
странице.
В
случае
необходимости получить, добавить или изменить данные записанные в базе
данных, в Действии есть возможность создать экземпляр той Модели, которая в
данный момент нужна и начать взаимодействовать с ней, путем вызова
определенных методов класса Модели для конкретных запросов.
43
Рисунок 14 – Физическая модель классов
44
Далее, метод посылает запрос, в виде Sql кода, в базу данных и получает
ответ, преобразовывает его в понятный для языка программирования формат
(ассоциативный массив), который возвращает на Контроллер. После чего
Контроллер
обрабатывает
полученные
данные
и
отправляет
их
на
Представление, где они, исходя из дизайна страницы и желаний программиста,
выводятся в веб-интерфейсе. Таким образом осуществляется полный цикл от
запроса конкретного адреса в строке запроса браузера, до демонстрации
страницы с запрашиваемыми данными[7].
К дополнительным классам относятся все классы, которые осуществляют
формирования форм ввода информации, обработку и генерацию json, обработку
и получение запросов от клиентских подсистем. А также вспомогательные
классы, осуществляющее работы всей подсистемы.
В качестве уточнения взаимосвязи классов внутри Модели на рисунке 15
представлена физическая модель классов конкретно для Модели. Данная
структура взаимодействует таким образом, что любой класс внутри себя может
создавать экземпляры других классов. В конкретном сервисе необходимо
только в некоторых случаях прибегать к выше упомянутой возможности. На
диаграмме ниже видно, что при выполнении определенных запросов, в классе
«MarketModel» будет задействованы экземпляры классов «ShopModel» для
хранения информации о магазине, «EventModel» где будет информация о
текущем мероприятии, «MapModel» для добавления информации о плане
здания торгового центра и «ObjectModel» который будет осуществлять
хранение информации
о
объектах торгового
центра, не являющихся
магазинами, именно эскалаторы, туалеты, стойки, лавки и многое другое.
45
Рисунок 15 – Физическая модель компонента Model
Также по схеме можно определить в каком классе, какие экземпляры
будут создаваться для упрощения работы с полученной информацией через
формы ввода. Таким образом, при добавлении розничного магазина, внутри
метода addStock() желательно создать экземпляр класса «StockModel» и с
помощью него взаимодействовать с атрибутами данного класса. Таким же
образом строится взаимодействие всех классов при вызове метода, который
отвечает за создание или удаление стороннего класса. Это необходимо для
упрощения восприятия кода, и улучшения структуры приложения.
3.2 Проектирование классов подсистемы торгового центра
3.2.1 Класс MarketController
Данный класс осуществляет полную обработку страницы с торговым
центром. При переходе на эту страницу выполняется метод indexAction данный
46
метод должен быть реализован во всех классах контроллерах, он является
основным[8].
«MarketController» обладает свойствами:
1)
идентификатор торгового центра;
2)
порядковый номер мероприятия.
В число методов класса «MarketController» входят:
1)
addTrcAction() – администратор с помощью данного метода может
создавать новые торговые центры. Внутри него осуществляется прием
необходимых данных с формы ввода добавления торгового центра, проверка
данных на валидность, передачи этих данных методу addTrc() класса
«MarketModel», для занесения их в базу данных, отправка результата на
Представление.
2)
showAction – данный метод срабатывает в момент выбора одного
торгового центра из списка торговых центров. Для администратора список
торговых центров выводится весь, для сотрудников только закрепленный за
ними. После нажатия на торговый центр, можно увидеть всю информацию о
нем. Данную информацию можно редактировать, после сохранения измененной
информации, данный метод обрабатывает её и, с помощью Модели, обновляет
информацию в базе данных. Также метод создает экземпляр класса «FormTrc»
что бы отправить эту форму на Представление. И пользователь имел
возможность редактировать записи.
3)
mapAction – при работе с торговым центров нам необходимо
загружать план зданий и устанавливать метки на карте. Каждая метка будет
относится либо к розничному магазину, либо к объекту торгового центра. Для
осуществления данных манипуляции служит метод mapAction(). Он ожидает
загрузки изображения с указанным этажом и добавляет путь в базу данных.
Далее принимает значения координат меток, и записывает их, для дальнейшего
воспроизводства на мобильном приложении.
4)
addEventAction – метод добавления мероприятий торгового центра.
На странице, обрабатываемой данным методом, находится форма, в которой
47
сотрудник торгового центра может добавить информацию о мероприятии,
изображение, контактную информацию. После отправления формы, все эти
данные обрабатываются этим методов, после чего добавляются в базу данных;
5)
deleteAction – метод для удаления торгового центра. Данный метод
отправляет
идентификатор
торгового
центра
с
запросом
удаления
в
MarketModel.
3.2.2 Класс ShopController
Класс ShopController обрабатывает все запросы связанные с розничными
магазинами. В случае перехода на страницу с списком магазинов, срабатывает
метод indexAction, который оправляет запрос в базу данных на получение
существующих розничных магазинов конкретного торгового центра и
полученный результат выводит пользователю в качестве таблицы.
«ShopController» обладает свойством «Идентификатор торгового центра»
В число методов класса «ShopController» входят:
1)
addShopAction() – осуществляет добавление розничного магазина в
базу данных;
2)
showAction – отображает всю информацию конкретного магазина,
после выбора его в списке;
3)
addEventAction – метод для добавления мероприятий в розничном
магазине;
4)
deleteAction – метод для удаления розничного магазина. Данный
метод отправляет идентификатор розничного магазина с запросом удаления в
ShopModel, в метод deleteShop();
5)
addStockAction – метод добавления акции и скидок данного
розничного магазина. Сотрудник в форме ввода может выбрать добавлять
акцию, либо скидку.
48
3.2.3 Класс MapModel
Класс «MapModel» реализован для обслуживания взаимодействия с
планами зданий торговых центров. Он осуществляет добавление, удаление и
редактирование информации относящейся к картам и меткам торгового центра
в базе данных.
Свойства данного класса:
1)
идентификатор торгового центра;
2)
идентификатор карты;
3)
описание;
4)
координаты метки.
Методы класса «MapModel»:
1)
getAllMap – метод для получения всех карт конкретного торгового
центра из базы данных. Данный метод отображает фотографии плана зданий
ассоциируя их по этажам;
2)
getMap – метод получения плана здания конкретного этажа;
3)
addMap – осуществляет добавление изображений, меток и путей в
базу данных;
4)
deleteMap – удаляет карту из базы данных по идентификатору
торгового центра и номера этажа.
3.2.4 Класс JsonController
Класс «JsonController» осуществляет основную работу с операциями по
передаче, приему и формированию Json[10] объектов. Для каждого действия
предусмотрен свой метод.
Методы класса «JsonGeneration»:
1)
actionMarket – метод для получения всех торговых магазинов из
базы данных;
2)
actionShop – метод получения розничных магазинов;
3)
actionEvent – метод получения всех мероприятий;
4)
actionStock – метод получения всех акций и скидок;
49
5)
actionOneShop
–
метод
получения
одного
магазина
по
определенному идентификатору передаваемому в функцию, путем GET
запроса.
3.3 Проектирование базы данных подсистемы торгового центра
Для хранения и обработки данных в разрабатываемой подсистеме
необходимо использовать базу данных. Процесс проектирования базы данных
начинается с выбора модели хранения данных. Затем на основе выбранной
модели хранения в виде схемы необходимо разработать ее логическое
представление. Следующим этапом является выбор конкретной СУБД, с учетом
специфики которой на основе логической схемы базы данных реализуется ее
физическое представление.
Для проектирования логической схемы базы данных была выбрана
модель хранения данных «сущность-связь» (ER-модель) в нотации IDEF1X
[15].
В данной нотации была разработана концептуальная схема базы данных
на логическом уровне, которая представлена на рисунке 16.
В базе данных сервиса для построения маршрутов в крупных торговых
центрах, подсистемы торгового центра выделены следующие сущности:
1)
торговый центр;
2)
розничный магазин;
3)
карта;
4)
мероприятия;
5)
акции и скидки;
6)
пользователь;
7)
метка;
8)
связь.
Сущность «Торговый центр» хранит информацию о торговом центре,
включая, полную информацию о нем, краткую информацию (для превью
торгового центра в мобильном приложении), ссылку на фото, часы работы.
50
Среди набора атрибутов выделяются необязательные и обязательные поля. В
базе данных это соответствует возможности атрибута иметь NULL-значение.
Выделяются следующие атрибуты:
1)
уникальный идентификатор;
2)
наименование торгового центра;
3)
описание;
4)
адрес;
5)
ссылка на фото;
6)
ссылка на логотип;
7)
количество этажей в торговом центре;
8)
ссылка на официальный сайт;
9)
ссылки на социальные сети;
10)
дополнительная информация;
11)
номер телефона.
Сущность «Розничный магазин» содержит информацию о магазине в
определенном торговом центре. При случае одноименных магазинов в разных
торговых центрах, система будет хранить два экземпляра данного магазина.
Это сделано для того, чтобы работа двух сотрудников разных торговых центров
не пересекалось. Дополнительным аспектом является разное территориальное
расположение торговых центрах, разная площадь и разный этаж. Для сущности
«Розничный магазин» выделяются атрибуты:
1)
уникальный идентификатор;
2)
идентификатор ТЦ;
3)
идентификатор метки;
4)
название магазина;
5)
описание;
6)
ссылка на фотографию;
7)
этаж;
8)
ссылка на официальный сайт;
9)
ссылки на социальные сети;
51
10)
номер телефона.
Сущность «Объекты ТЦ» содержит информацию об объектах торгового
центра, не относящиеся к магазинам. Например, эскалаторы, стойки с
информацией, лестницы, туалеты. Данная сущность показывает наличие
определенных объектов в торговом центре.
Атрибутами сущности «Объекты ТЦ» являются:
1)
идентификатор объекта;
2)
идентификатор ТЦ;
3)
идентификатор метки;
4)
название;
5)
описание;
6)
этаж.
Сущность «Карта» необходима для хранения информации о планах
здания торгового центра. У одного торгового центра может быть несколько
карт, в зависимости от количество этажей здания. В данной таблице будет
ссылка на фотографию плана здания торгового центра.
Атрибуты сущности «Карта»:
1)
идентификатор карты;
2)
идентификатор ТЦ;
3)
ссылка на фотографию;
4)
этаж.
По атрибуту «Идентификатор ТЦ» и «Этаж» будет происходить связь с
сущностями «Розничный магазин» и «Объекты ТЦ». Это даст возможность
отображать метки магазинов на карте, при клике на которых, будет
отображаться полная информация магазина, также позволит скрыть метки
отвечающие за пути и упростит поиск магазинов при выборе конкретного
этажа.
Сущность
«Мероприятие»
осуществляет
хранение
информации
о
мероприятиях, проводимых в торговых центрах и розничных магазинах. Для
показательности связи выделен атрибут «Идентификатор типа» и «Тип
52
мероприятия», в которых и указывается к какой сущности относится данное
мероприятие.
Атрибуты сущности «Мероприятие»:
1)
идентификатор мероприятия;
2)
идентификатор типа;
3)
тип мероприятия;
4)
название;
5)
описание;
6)
ссылка на фотографию;
7)
дата начала;
8)
дата окончания;
9)
дополнительная информация;
10)
номер телефона.
Сущность «Акции и скидки» хранит информацию о акциях и скидках
розничного магазина. У одного магазина может быть несколько скидок и акций,
соответственно связь между сущностям один ко многим.
Атрибуты сущности «Акции и скидки»:
1)
идентификатор;
2)
идентификатор магазина;
3)
название;
4)
описание;
5)
ссылка на изображение;
6)
дата начала;
7)
дата окончания;
8)
дополнительная информация.
Сущность «Метка» хранит информацию о всех добавленных метках на
конкретной карте. Сотрудник при расставлении меток на карте торгового
центра, будет осуществлять добавление их в таблицу «Метка». То есть для
того, что бы получить список всех меток и их координаты любой карты,
необходимо обратиться к данной сущности.
53
Атрибуты данной сущности:
1)
идентификатор;
2)
идентификатор карты;
3)
координаты по оси Х;
4)
координаты по оси Y.
Сущность «Связь» - данная сущность необходима для хранения
возможных путей между метками. После добавления всех меток, сотрудник
входит в режим добавления путей, где после нажатия правой кнопкой мыши на
одну
метку
потом
на
другую,
между
ними
изображается
линия,
символизирующая путь. Данные этого пути будут хранится в данной сущности.
С помощью данной сущности, можно будет узнать, все связи конкретной
метки.
Атрибуты сущности «Связь»:
1)
идентификатор связи;
2)
идентификатор метки начала;
3)
идентификатор метки окончания;
4)
вес связи.
Сущность «Метка» хранит информацию о точках пути. Сотрудник
торгового центра, во время добавления меток, будет иметь возможность
выбрать какую метку он добавляет, данных меток будет три типа, данная
сущность отвечает за сохранение информации о метках пути.
54
Рисунок 16 – Логическая схема базы данных
55
3.4 Проектирование интерфейса подсистемы торгового центра
Сотрудник торгового центра и администратор осуществляет работу с
помощью веб-интерфейса. Исходя из этого, проектирование интерфейса
является важным аспектом разработки программного обеспечения.
В начале проектирования стоит определить страничную структуру
будущего сервиса (рисунок 17) [16]. Основными страницами будут являться:
1)
страница входа / выхода и аутентификации;
2)
главная страница;
3)
страница с информацией о торговых центрах / торговом центре;
4)
страница с розничными магазинами;
5)
страница с мероприятиями;
6)
страница с акциями и скидками;
7)
карты торговых центров.
Также будут внутренние страницы которые будут отвечать за добавление,
удаление или редактирование информации о выбранном объекте. Будет
страница работы с картами, на которой сотрудник торгового центра будет
добавлять метки на карту.
Внутри каждого раздела будет находиться список объектов по
соответствию названия раздела. Можно будет осуществить редактирование
отдельных пунктов и удаление объектов. Также зайти на карточку объекта
(торгового центра, розничного магазина) и узнать полную информацию о нем.
В качестве примера были выполнены прототипы части основных страниц
для формирования понимания будущего интерфейса. На рисунке 18 изображен
прототип страницы входа / выхода и аутентификации сервиса. Основным
элементом данной страницы является форма ввода информации, где
сотруднику дается возможность войти в систему под выданным логином и
паролем.
56
Рисунок 17 – Страничная структура сайта
Следующим прототипом является страница с информацией о розничном
магазине – карточка магазина со всей информацией. Она будет изображена в
виде таблицы, где слева наименования нужного элемента, с права его значение.
Рисунок 18 – Прототип интерфейса страницы «Вход/выход»
57
Рисунок 19 - Прототип интерфейса страницы «Карточка магазина»
В
прототипе
«Карточка
товара»
указаны
первоначальные
поля
информации, при непосредственной разработки интерфейса будут добавлены
все поля из базы данных.
Исходя из прототипов в качестве темы для интерфейса будет
использована стандартный шаблон Yii2 Framework’a[6], так как он отвечает
всем требованиям и выполнен исходя из пользовательского опыта.
3.5 Проектирование алгоритма дополнения карты сервиса для построения
маршрутов в крупных торговых центрах
Основным алгоритмом сервиса является алгоритм, отвечающий за
добавление, удаление карты торгового центра, установку меток магазинов,
меток движения и второстепенных объектов.
58
Для реализации данного функционала будет выделена отдельная
страница, на которой, будут отображаться все карты данного торгового центра
по этажам. Это означает, что одна карта – один этаж. После выбора этажа,
карта подгружается в выделенную область с определенным размером. Где и
будут инициализироваться координаты меток исходя и холста. Далее
сотруднику необходимо выбрать тип метки, которую он хочет добавлять. Если
выбрана метка магазина или объекта, то в списке определяется наименование
магазина или объекта соответственно. Различие в добавлении меток пути и
меток магазина, объектов – это возможность добавлять сразу несколько меток
пути. Более подробный алгоритм изображен на рисунке 20.
После оформления всех запланированных меток, сотрудник торгового
центра активирует режим построения маршрута по кнопке «Режим маршрута».
В нём необходимо ответственно провести пути следования будущего
пользователя, то есть связать все метки так, как будет осуществлять
передвижения человека в торговом центре. При выборе метки правой кнопкой
мыши, необходимо выбрать метку, с которой она будет связанна, после чего
между ними образуется линия. Она характеризует возможность строить
маршрут по данному пути. Таким образом формируется проход, по которому, в
результате,
будет
двигаться
человек.
Каждая
возможная
комбинация
записывается в таблицу «Связь» в базу данных, как наименования первой
метки, наименование второй метки и веса между ними, который определяется
как расстояние в пикселях.
59
Рисунок 20 – Алгоритм добавления меток
60
4 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СЕРВИСА ДЛЯ
ПОСТРОЕНИЯ МАРШРУТОВ В КРУПНЫХ ТОРГОВЫХ ЦЕНТРАХ.
ПОДСИСТЕМЫ ТОРГОВОГО ЦЕНТРА
4.1
Разработка физической модели базы данных подсистемы торгового
центра
Разработка базы данных опирается на ранее созданную логическую
модель. Физическая модель представляет собой более детализированную, на
более низком уровне абстракции логическую модель [17]. Здесь определяются
названия полей, они должны точно характеризовать атрибут, что бы не
нарушалось восприятие для программиста, который будет работать с данной
базой данных. Также определяются типы данных для каждого атрибута,
первичные ключи, внешние ключи. Уточняется стратегия обеспечения
целостности данных.
Физическая модель базы данных сервиса для построения маршрутов в
крупных торговых центрах представлена на рисунке 21. Логическая модель
являлась основой разработки физической модели. Все спроектированные
сущности детализировались и были приведены к конечному виду, который
можно воссоздать для обеспечения работы сервиса. Между сущностями
определены не идентифицирующие связи – не один первичный ключ не
является первичным ключом для другой сущности. Также, на схеме видно, что
придуманы имена, по которым можно определить для чего существует данный
атрибут. Уточнены типы полей, чаще всего использовался строковый тип
VARCHAR. Также рядом с началом и окончанием связи располагается
обозначение стратегии обеспечения целостности базы данных. Она показывает
действия, которые будут применены к таблицам «родителям» или таблицам
«потомкам» при определенных функциях, а именно «удаления», «добавления»
и «редактирования». Как видно, что, если удалить объект таблицы «market», то
будет удалены все потомки данной таблицы по каскаду. При том, что при
добавлении, ничего не будет происходить.
61
Рисунок 21 – Физическая модель базы данных
62
4.2 Особенности реализации алгоритма создания и заполнения карт
сервиса для построения маршрутов в крупных торговых центрах
На основе ранее спроектированного алгоритма добавления, удаления и
взаимодействия меток, был реализован алгоритм создания и заполнения карт.
Основным
классом
реализации
является
«MapController».
Он
осуществляет взаимодействия с классом «MapModel», который в свою очередь
взаимодействует с базой данных.
Алгоритм работы с картой и метками заключается в следующем.
Сотрудник торгового центра, после добавления карт для каждого этажа
(рисунок 22), переходит в раздел «Добавление меток».
Рисунок 22 – Интерфейс страницы «Добавление карт»
В данном разделе находится главная область – куда подгружаются карты.
Она реализована с помощью компонента canvas и имеет конкретный размер
1024х768. Данная размерность играет большую роль, так как с левого верхнего
угла происходит отсчет координат, которые потом записываются в качестве
координат метки. Слева от основного раздела находятся превью изображений с
этажами. Сотрудник при выборе одной из них, подгружает ее в основной экран.
После загрузки карты, сотруднику необходимо добавить метки.
Для добавления меток, сотрудник торгового центра, должен определиться
с типом данной метки.
Существует три типа:
1)
объект;
63
2)
проход;
3)
магазин.
При выборе объекта или магазина, с помощью php скрипта, в раздел со
списком подгружаются наименование выбранного раздела. Сотрудник выбрав
его, может кликнуть левой кнопкой мыши на карту, после чего на карте
появится
изображение метки
(рисунок 23). После этого, сотруднику
необходимо нажать кнопку «Добавить». Далее в классе «MapController», в
методе «actionAdd» осуществляется приём данных, а именно, какой магазин /
объект был выбран, координаты клика относительно размера холста canvas.
Далее данные отправляются в класс модели «MapModel», где в методе addMark,
производится добавление полученных данных в таблицу «Mark», которая
хранит все метки этажей. После чего, происходит поиск магазина в таблице
«Shop», к которому добавили метку. В поле «id_mark» таблицы «Shop» заносим
последний добавленный идентификатор из таблицы «Mark».
Рисунок 23 – Добавление меток «Магазин»
В случае добавления меток «Проход» (рисунок 24) сотрудник может
добавить левой кнопкой мыши все желаемые метки, и после этого нажать
кнопку «Добавить». В методе «actionAdd» при приеме данных с формы,
64
определяется тип метки. Метки «Проход» обрабатываются в цикле, так как они
не привязаны к объектам и сразу добавляются в таблицу «Mark».
Рисунок 24 – Добавление меток «Проход»
После того, как сотрудник добавил все желаемые метки, ему необходимо
обозначить возможные пути – нажав кнопку «Режим маршрута». В данном
режиме правой кнопкой мыши происходит выбор метки, далее определение,
куда может двигаться пользователь и выбор следующей метки по пути. Между
выбранными метками изображается линия, характеризующая возможный путь
будущего маршрута. В момент клика на вторую метку, когда первая уже
выбрана, с помощью Ajax механизма формируется запрос на «MapController» в
метод «actionRelations», который принимает идентификатор первой метки,
идентификатор второй метки и рассчитанный вес связи на основе координат
данных меток. И эта информация, через метод «addRelations», добавляется в
базу данных, в таблицу «Relations». В случае, если сотрудник нажмет на линию
два раза, она исчезнет, тем самым отправит запрос на удаление данной связи из
базы данных.
После добавления всех возможных путей из разных меток, клиентская
часть сервиса для построения маршрутов в курпных торговых центрах, может
65
получить список в виде json[10] объекта. Данный json формируется с помощью
нескольких запросов к базе данных. Json объект имеет вид:
{id_mark:1,relation:{1: { id_mark, weight},2: {…},…}}
На данной
схеме объекта
json видно, что
в начале пишется
идентификатор метки, связи которой нужно узнать. Далее, исходя из
количество связанных меток формируется массив объектов с атрибутами
идентификатор метки и рассчитанный вес.
4.3 Разработка интерфейса подсистемы торгового центра
Планом для разработки интерфейса всех экранов являются структура и
схематичный прототип интерфейса. Учитывая структуру сайта, необходимо
внести в интерфейс компоненты позволяющие удобно осуществлять переходы
между страницами, добавить навигационную цепочку - это элемент навигации
по сайту, который представляет собой путь от корня сайта, до текущей
страницы, на которой в настоящий момент находится пользователь (рисунок
25). Конечный пользователь сервиса должен максимально быстро переходить
между необходимыми ему страницами.
Рисунок 25 – Навигационная цепочка
Прототип осуществляет роль каркаса – он определяет примерный вид и
расположение будущих компонентов страницы. И все же, конечный результат
может разниться с прототипом. На основе прототипа был разработан
интерфейс, на рисунке 26 изображена страница «Входа/выхода».
66
Рисунок 26 – Интерфейс страницы «Входа/выхода»
Страница «Входа/выхода» является начальной при запуске приложения,
без аутентификации не будет возможности перейти на другую страницу. В
скрипте прописана проверка логина и пароля, и в Cookie[isUser] записывается –
есть ли возможность просматривать данную страницу или нет.
Рисунок 27 – Интерфейс страницы «Карточка торгового центра»
Исходя из прототипа был разработан и сверстан интерфейс карточки
торгового центра (рисунок 27). Здесь располагается таблица выгрузки всей
информации о торговом центре, который редактирует конкретный
пользователь. Вверху страницы указывается наименование выбранного
67
торгового центра, и кнопка «Редактирование», при нажатии на которую,
произойдет переход в режим редактирования.
Рисунок 28 – Интерфейс страницы «Магазины»
Страница «Магазины» (рисунок 28) содержит список всех магазинов
редактируемого торгового центра, вывод осуществляется с помощью таблицы.
Вверху страницы можно видеть наименования раздела, и кнопку «Добавить
магазин» - сотрудник переходит в режим добавления магазина (рисунок 29).
На странице «Добавления магазина» отображается форма добавления,
состоящая из атрибутов таблицы «shop». Для добавления магазина, необходимо
заполнить минимальное количество полей, это наименование и этаж,
идентификатор торгового центра, подгружается самостоятельно.
Рисунок 29 – Интерфейс страницы «Добавление магазина»
68
ЗАКЛЮЧЕНИЕ
Задача позиционирования и построения маршрута в крупных торговых
центрах является актуальной, так как повсеместно строят большие здания под
торговые центры, где покупателю становится трудно ориентироваться и
находить нужный магазин. В рамках данной выпускной квалификационной
работы подсистема торгового центра реализует серверную часть приложения,
отвечающая за хранение информации в базе данных, веб-интерфейс для
сотрудников торгового центра и администратора, где осуществляется работа с
данными сервиса.
В ходе выполнения работы были решены все поставленные задачи.
Проведен анализ и описаны процессы предметной области, рассмотрены
приложения-аналоги,
проанализированы
средства
реализации
позиционирования в закрытых помещениях.
На основании выявленных требований были описаны спецификации,
определена архитектура подсистемы, рассмотрены особенности организации
взаимодействия подсистемы и внешних ПО.
На этапе проектирования была построена структура подсистемы
торгового центра, включающая в себя, серверную часть и веб - приложение.
Проведена разработка серверной части, обеспечивающей работу с базой
данных,
графического
интерфейса
веб-приложения
для
удобного
взаимодействия с базой данных и администрирования подсистемы торгового
центра.
Таким образом, можно сделать вывод о том, что поставленная цель была
достигнута.
69
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1.
Игнатенко П.А. Разработка системы позиционирования в закрытых
помещениях с использованием метода ангуляции источников Wi-Fi-сигнала
[Текст] / Ухтинский гос. техн. ун-т. – Ухта, 2016.
2.
Системы локального позиционирования [Электронный ресурс] //
Мир беспроводных решений. – URL: http://www.wless.ru/technology/ ?tech=11
(дата обращения: 25.04.2018).
3.
Wi-Fi-позиционирование «дешево и сердито». О частоте замеров
или возможно ли Wi-Fi-позиционирование в реальном времени [Электронный
ресурс]. – URL: https://habrahabr.ru/post/309308/ (дата обращения: 27.04.2018).
4.
Документация API Yii 2.0 [Электронный ресурс]. – URL:
https://www.yiiframework.com/doc/api/2.0/ (дата обращения: 02.05.2018).
5.
Магия RESTful API в Yii2 [Электронный ресурс]. – URL:
http://developer.uz/blog/restful-api-in-yii2/ (дата обращения: 05.04.2018).
6.
Создание
сайта
на
Yii2
[Электронный
ресурс].
–
URL:
http://rgblog.ru/page/sozdanie-sajta-na-yii-framework-20-chast-1/ (дата обращения:
05.04.2018).
7.
Полное руководство по Yii2 [Электронный ресурс]. – URL:
https://yiiframework.com.ua/ru/doc/guide/2/start-workflow/
(дата
обращения:
09.04.2018).
8.
Приложение
Yii2
с
нуля
[Электронный
ресурс].
–
URL:
https://webformyself.com/prilozhenie-yii2-s-nulya/ (дата обращения: 15.04.2018).
9.
Документация
по
Json
[Электронный
ресурс].
–
URL:
https://clickhouse.yandex/docs/ru/formats/json/ (дата обращения: 20.04.2018).
10.
Руководство по PHP – работа с Json [Электронный ресурс]. – URL:
http://php.net/manual/ru/book.json.php/ (дата обращения: 21.04.2018).
11.
MVC в вебе. MVC (Model, View, Controller) в применении к веб-
разработке. [Электронный ресурс]. – URL: https://habr.com/post/181772/ (дата
обращения: 25.04.2018).
70
12.
RESTful API для сервера – делаем правильно [Электронный
ресурс]. – URL: https://m.habr.com/post/144011/ (дата обращения: 27.04.2018).
13.
Информационная модель подсистем [Электронный ресурс]. – URL
http://www.ngpedia.ru/id159853p1.html (дата обращения: 2.05.2018).
14.
Архитектура
MVC
[Электронный
ресурс].
https://github.com/codedokode/pasta/blob/master/arch/mvc.md
–
URL:
(дата обращения:
12.05.2018).
15.
Основы методологии IDEF1X [Электронный ресурс]. – URL:
http://citforum.ru/cfin/idef/idef1x.shtml (дата обращения: 15.05.2018).
16.
Разработка
пользовательских
интерфейсов,
прототипирование
[Электронный ресурс]. – URL: https://blog.sibirix.ru/2012/05/23/prototyping-insibirix/ (дата обращения: 18.05.2018).
17.
Создание физической модели хранилища данных [Электронный
ресурс]. – URL: https://www.intuit.ru/studies/courses/599/455/lecture/10170 (дата
обращения: 22.05.2018).
71
ПРИЛОЖЕНИЕ А
(обязательное)
Листинг программы
<?php
namespace app\controllers;
use Yii;
use app\models\Market;
use app\models\MarketSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
/**
* MarketController implements the CRUD actions for Market model.
*/
class MarketController extends Controller
{
/**
* {@inheritdoc}
*/
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
$searchModel = new MarketSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
'dataProvider' => $dataProvider,
]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
72
public function actionCreate()
{
$model = new Market();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('create', [
'model' => $model,
]);
}
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Market::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
}
}
<?php
namespace app\controllers;
use Yii;
use app\models\Shop;
use app\models\ShopSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
73
/**
* ShopController implements the CRUD actions for Shop model.
*/
class ShopController extends Controller
{
/**
* {@inheritdoc}
*/
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
$searchModel = new ShopSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
'dataProvider' => $dataProvider,
]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
public function actionCreate()
{
$model = new Shop();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('create', [
'model' => $model,
]);
}
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
74
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Shop::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
}
} <?php
namespace app\controllers;
use Yii;
use app\models\Map;
use app\models\MapSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
/**
* MapController implements the CRUD actions for Map model.
*/
class MapController extends Controller
{
/**
* {@inheritdoc}
*/
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
75
$searchModel = new MapSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
'dataProvider' => $dataProvider,
]);
}
public function actionUpload()
{
$model = new UploadForm();
if (Yii::$app->request->isPost) {
$model->photo_link = UploadedFile::getInstance($model, 'photo_link');
if ($model->upload()) {
// file is uploaded successfully
return;
}
}
return $this->render('upload', ['model' => $model]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
public function actionCreate()
{
$model = new Map();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('create', [
'model' => $model,
]);
}
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
76
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Map::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
}
} <?php
namespace app\controllers;
use Yii;
use app\models\Mark;
use app\models\MarkSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
/**
* MarkController implements the CRUD actions for Mark model.
*/
class MarkController extends Controller
{
/**
* {@inheritdoc}
*/
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
$searchModel = new MarkSearch();
77
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
'dataProvider' => $dataProvider,
]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
public function actionCreate()
{
$model = new Mark();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('create', [
'model' => $model,
]);
}
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Mark::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
78
}
} <?php
namespace app\controllers;
use Yii;
use app\models\Object;
use app\models\ObjectSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
class ObjectController extends Controller
{
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
$searchModel = new ObjectSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
'dataProvider' => $dataProvider,
]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
public function actionCreate()
{
$model = new Object();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('create', [
'model' => $model,
]);
}
79
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Object::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
}
} <?php
namespace app\controllers;
use Yii;
use yii\filters\AccessControl;
use yii\web\Controller;
use yii\web\Response;
use yii\filters\VerbFilter;
use app\models\LoginForm;
use app\models\ContactForm;
class SiteController extends Controller
{
public function behaviors()
{
return [
'access' => [
'class' => AccessControl::className(),
'only' => ['logout'],
'rules' => [
[
'actions' => ['logout'],
'allow' => true,
'roles' => ['@'],
80
],
],
],
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'logout' => ['post'],
],
],
];
}
public function actions()
{
return [
'error' => [
'class' => 'yii\web\ErrorAction',
],
'captcha' => [
'class' => 'yii\captcha\CaptchaAction',
'fixedVerifyCode' => YII_ENV_TEST ? 'testme' : null,
],
];
}
public function actionIndex()
{
return $this->render('index');
}
public function actionLogin()
{
if (!Yii::$app->user->isGuest) {
return $this->goHome();
}
$model = new LoginForm();
if ($model->load(Yii::$app->request->post()) && $model->login()) {
return $this->goBack();
}
$model->password = '';
return $this->render('login', [
'model' => $model,
]);
}
public function actionLogout()
{
Yii::$app->user->logout();
return $this->goHome();
}
81
public function actionContact()
{
$model = new ContactForm();
if ($model->load(Yii::$app->request->post()) && $model->contact(Yii::$app>params['adminEmail'])) {
Yii::$app->session->setFlash('contactFormSubmitted');
return $this->refresh();
}
return $this->render('contact', [
'model' => $model,
]);
}
public function actionAbout()
{
return $this->render('about');
}
} <?php
namespace app\controllers;
use Yii;
use app\models\Stock;
use app\models\StockSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
class StockController extends Controller
{
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
$searchModel = new StockSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
82
'dataProvider' => $dataProvider,
]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
public function actionCreate()
{
$model = new Stock();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('create', [
'model' => $model,
]);
}
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Stock::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
}
} <?php
83
namespace app\controllers;
use Yii;
use app\models\Event;
use app\models\EventSearch;
use yii\web\Controller;
use yii\web\NotFoundHttpException;
use yii\filters\VerbFilter;
/**
* EventController implements the CRUD actions for Event model.
*/
class EventController extends Controller
{
/**
* {@inheritdoc}
*/
public function behaviors()
{
return [
'verbs' => [
'class' => VerbFilter::className(),
'actions' => [
'delete' => ['POST'],
],
],
];
}
public function actionIndex()
{
$searchModel = new EventSearch();
$dataProvider = $searchModel->search(Yii::$app->request->queryParams);
return $this->render('index', [
'searchModel' => $searchModel,
'dataProvider' => $dataProvider,
]);
}
public function actionView($id)
{
return $this->render('view', [
'model' => $this->findModel($id),
]);
}
public function actionCreate()
{
$model = new Event();
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
84
return $this->render('create', [
'model' => $model,
]);
}
public function actionUpdate($id)
{
$model = $this->findModel($id);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
return $this->render('update', [
'model' => $model,
]);
}
public function actionDelete($id)
{
$this->findModel($id)->delete();
return $this->redirect(['index']);
}
protected function findModel($id)
{
if (($model = Event::findOne($id)) !== null) {
return $model;
}
throw new NotFoundHttpException('The requested page does not exist.');
}
} <?php
namespace app\models;
use Yii;
class Market extends \yii\db\ActiveRecord
{
/**
* {@inheritdoc}
*/
public static function tableName()
{
return 'market';
}
public function rules()
{
return [
[['title', 'adress', 'floor_amount'], 'required'],
[['description'], 'string'],
85
[['floor_amount'], 'integer'],
[['title', 'adress', 'photo_link', 'logo_link', 'work_time', 'site_link', 'fb_link', 'vk_link',
'insta_link', 'phone'], 'string', 'max' => 255],
[['extra_info'], 'string', 'max' => 1000],
];
}
/**
* {@inheritdoc}
*/
public function attributeLabels()
{
return [
'id' => 'Идентификатор',
'title' => 'Название',
'description' => 'Описание',
'adress' => 'Адресс',
'photo_link' => 'Сслыка на изображение',
'logo_link' => 'Ссылка на логотип',
'floor_amount' => 'Количество этажей',
'work_time' => 'Рабочее время',
'site_link' => 'Сслыка на офф.сайт',
'fb_link' => 'Фейсбук',
'vk_link' => 'Вконтакте',
'insta_link' => 'Инстаграмм',
'extra_info' => 'Дополнительно',
'phone' => 'Номер телефона',
];
}
public function getEvents()
{
return $this->hasMany(Event::className(), ['id_type' => 'id']);
}
public function getMaps()
{
return $this->hasMany(Map::className(), ['id_market' => 'id']);
}
public function getObjects()
{
return $this->hasMany(Object::className(), ['id_market' => 'id']);
}
public function getShops()
{
return $this->hasMany(Shop::className(), ['id_market' => 'id']);
}
public function getUsers()
{
return $this->hasMany(User::className(), ['id_market' => 'id']);
}
} <?php
namespace app\models;
86
use Yii;
class Shop extends \yii\db\ActiveRecord
{
/**
* {@inheritdoc}
*/
public static function tableName()
{
return 'shop';
}
/**
* {@inheritdoc}
*/
public function rules()
{
return [
[['id_market', 'title', 'floor_num'], 'required'],
[['id_market', 'id_map', 'floor_num', 'crd_x', 'crd_y'], 'integer'],
[['description'], 'string'],
[['title', 'photo_link', 'site_link', 'fb_link', 'vk_link', 'inst_link', 'phone', 'work_time'],
'string', 'max' => 255],
[['id_market'], 'exist', 'skipOnError' => true, 'targetClass' => Market::className(),
'targetAttribute' => ['id_market' => 'id']],
[['id_map'], 'exist', 'skipOnError' => true, 'targetClass' => Map::className(),
'targetAttribute' => ['id_map' => 'id']],
];
}
/**
* {@inheritdoc}
*/
public function attributeLabels()
{
return [
'id' => 'ID',
'id_market' => 'Id Market',
'id_map' => 'Id Map',
'title' => 'Title',
'description' => 'Description',
'photo_link' => 'Photo Link',
'floor_num' => 'Floor Num',
'site_link' => 'Site Link',
'fb_link' => 'Fb Link',
'vk_link' => 'Vk Link',
'inst_link' => 'Inst Link',
'phone' => 'Phone',
'work_time' => 'Work Time',
'crd_x' => 'Crd X',
'crd_y' => 'Crd Y',
];
87
}
public function getEvents()
{
return $this->hasMany(Event::className(), ['id_type' => 'id']);
}
public function getMarket()
{
return $this->hasOne(Market::className(), ['id' => 'id_market']);
}
public function getMap()
{
return $this->hasOne(Map::className(), ['id' => 'id_map']);
}
public function getStocks()
{
return $this->hasMany(Stock::className(), ['id_shop' => 'id']);
}
} <?php
namespace app\models;
use Yii;
class Mark extends \yii\db\ActiveRecord
{
/**
* {@inheritdoc}
*/
public static function tableName()
{
return 'mark';
}
/**
* {@inheritdoc}
*/
public function rules()
{
return [
[['id_map', 'crd_x', 'crd_y'], 'required'],
[['id_map', 'crd_x', 'crd_y'], 'integer'],
[['id_map'], 'exist', 'skipOnError' => true, 'targetClass' => Map::className(),
'targetAttribute' => ['id_map' => 'id']],
];
}
/**
* {@inheritdoc}
*/
public function attributeLabels()
{
88
return [
'id' => 'ID',
'id_map' => 'Id Map',
'crd_x' => 'Crd X',
'crd_y' => 'Crd Y',
];
}
/**
* @return \yii\db\ActiveQuery
*/
public function getMap()
{
return $this->hasOne(Map::className(), ['id' => 'id_map']);
}
} <?php
namespace app\models;
use Yii;
class Stock extends \yii\db\ActiveRecord
{
/**
* {@inheritdoc}
*/
public static function tableName()
{
return 'stock';
}
/**
* {@inheritdoc}
*/
public function rules()
{
return [
[['id_shop', 'title'], 'required'],
[['id_shop'], 'integer'],
[['description'], 'string'],
[['title', 'photo_link', 'time_end', 'phone'], 'string', 'max' => 255],
[['extra_info'], 'string', 'max' => 1000],
[['id_shop'], 'exist', 'skipOnError' => true, 'targetClass' => Shop::className(),
'targetAttribute' => ['id_shop' => 'id']],
];
}
/**
* {@inheritdoc}
*/
public function attributeLabels()
{
return [
89
'id' => 'ID',
'id_shop' => 'Id Shop',
'title' => 'Title',
'description' => 'Description',
'photo_link' => 'Photo Link',
'time_end' => 'Time End',
'extra_info' => 'Extra Info',
'phone' => 'Phone',
];
}
/**
* @return \yii\db\ActiveQuery
*/
public function getShop()
{
return $this->hasOne(Shop::className(), ['id' => 'id_shop']);
}
} <?php
namespace app\models;
use Yii;
class Map extends \yii\db\ActiveRecord
{
public $imageFile;
/**
* {@inheritdoc}
*/
public static function tableName()
{
return 'map';
}
/**
* {@inheritdoc}
*/
public function rules()
{
return [
[['id_market', 'photo_link', 'floor_num'], 'required'],
[['id_market', 'floor_num'], 'integer'],
[['photo_link'], 'file', 'skipOnEmpty' => false, 'extensions' => 'png, jpg'],
[['id_market'], 'exist', 'skipOnError' => true, 'targetClass' => Market::className(),
'targetAttribute' => ['id_market' => 'id']],
];
}
/**
* {@inheritdoc}
*/
90
public function attributeLabels()
{
return [
'id' => 'ID',
'id_market' => 'Id Market',
'photo_link' => 'Photo Link',
'floor_num' => 'Floor Num',
];
}
public function getMarket()
{
return $this->hasOne(Market::className(), ['id' => 'id_market']);
}
public function getMarks()
{
return $this->hasMany(Mark::className(), ['id_map' => 'id']);
}
/**
* @return \yii\db\ActiveQuery
*/
public function getObjects()
{
return $this->hasMany(Object::className(), ['id_map' => 'id']);
}
/**
* @return \yii\db\ActiveQuery
*/
public function getShops()
{
return $this->hasMany(Shop::className(), ['id_map' => 'id']);
}
public function upload()
{
if ($this->validate()) {
$this->photo_link->saveAs('uploads/' . $this->photo_link->baseName . '.' . $this>photo_link->extension);
return true;
} else {
return false;
}
}
} <?php
namespace app\models;
use Yii;
class Event extends \yii\db\ActiveRecord
{
91
/**
* {@inheritdoc}
*/
public static function tableName()
{
return 'event';
}
/**
* {@inheritdoc}
*/
public function rules()
{
return [
[['id_type', 'isMarket', 'title'], 'required'],
[['id_type', 'isMarket'], 'integer'],
[['description'], 'string'],
[['title', 'photo_link', 'time_start', 'phone'], 'string', 'max' => 255],
[['extra_info'], 'string', 'max' => 1000],
[['id_type'], 'exist', 'skipOnError' => true, 'targetClass' => Market::className(),
'targetAttribute' => ['id_type' => 'id']],
[['id_type'], 'exist', 'skipOnError' => true, 'targetClass' => Shop::className(),
'targetAttribute' => ['id_type' => 'id']],
];
}
/**
* {@inheritdoc}
*/
public function attributeLabels()
{
return [
'id' => 'ID',
'id_type' => 'Id Type',
'isMarket' => 'Is Market',
'title' => 'Title',
'description' => 'Description',
'photo_link' => 'Photo Link',
'time_start' => 'Time Start',
'extra_info' => 'Extra Info',
'phone' => 'Phone',
];
}
/**
* @return \yii\db\ActiveQuery
*/
public function getType()
{
return $this->hasOne(Market::className(), ['id' => 'id_type']);
}
92
/**
* @return \yii\db\ActiveQuery
*/
public function getType0()
{
return $this->hasOne(Shop::className(), ['id' => 'id_type']);
94
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
2. Даты и время
3. Создатели
4. Внешние
ссылки
5. Защита
6. Характеристики
содержания
Характеристики документа
на электронном носителе
Vkr_presentation.pptx
Демонстрационные плакаты
к выпускной
квалификационной работе
Класс документа
ЕСКД
Вид документа
Оригинал документа на
электронном носителе
Аннотация
Демонстрационный
материал, отображающий
основные этапы выполнения
выпускной
квалификационной работы
Использование документа Операционная система
Windows 7, Microsoft
PowerPoint 2013
Дата и время
17.06.2018
копирования документа
Дата создания документа 29.05.2018
Дата утверждения
20.06.2018
документа
Автор
Гришин А.И
Изготовитель
Гришин А.И.
Ссылки на другие
Удостоверяющий лист
документы
№ 140235/п
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
Объем информации
1 216 018 Б
документа
95
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Титульный лист
Основные методы поиска
объектов в торговых центрах
Требования к программному
обеспечению подсистемы
торгового центра
Функциональная модель
сервиса построения
маршрутов в крупных
торговых центрах
Функциональная модель
подсистемы торгового центра
Структура программного
обеспечения подсистемы
торгового центра
Алгоритм дополнения карт
сервиса
Логическая модель базы
данных
Диаграмма переходов
интерфейса пользователя
«Сотрудник ТЦ» подсистемы
торгового центра
Экранные формы
подсистемы торгового центра
1/--страниц
Пожаловаться на содержимое документа