68
Исходя из построенных выше диаграмм и их описания, можно составить
схему информационной модели, которая представлена на рисунке Ошибка!
Источник ссылки не найден..
Рис. 28 - Информационная модель.
При детальном рассмотрении данной схемы, можно отметить, что в каждой
сцене происходит обращение к базе данных. Также в этих сценах производится
запись в базу данных в те же таблицы при внесении каких-либо изменений.
Однако, исключением являются сцены «Просмотр значений/Запуск
мониторинга» и «Просмотр истории», - запись в базу данных производится
только в первой сцене, причём в обе таблицы. Вторая же сцена осуществляет лишь
чтение.
69
На выходе аналитик получает таблицу с результатами, а также историю
результатов.
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации
Входной информацией в разрабатываемой системе являются следующие
объекты:
Магазины;
Номенклатура;
Группы.
В свою очередь данные объекты несут в себе типы.
Магазины:
Название;
Ссылка;
Шаблон выборки информации.
Номенклатура:
Название;
Ссылка.
Группы:
Название.
На основании этих входных данных, так же входными данными являются
исходные коды страниц в интернет-магазинах и прочих электронных ресурсах.
На рисунке 29 изображена схема ввода информации в информационную
систему.
70
Рис. 29 - Входная информация.
2.2.3. Характеристика результатной информации
В рамках данного проекта результатная информация информационной
системы представляет из себя таблицу, заполненную ценами по каждому
элементу номенклатуры, сопоставленному с магазином.
Кроме того, существует возможность просмотра истории цен по заданному
временному ограничению.
В таблице 5 представлен примерный вывод результатной информации.
Таблица 5
Результатная информация
Магазин
№1
Магазин
№2
Магазин
№3
Магазин
№4
Позиция
№1
1
2
3
4
Позиция
№2
5
6
7
8
Позиция
№3
9
10
11
12
Позиция
№4
13
14
15
16
Позиция
№5
17
18
19
20
71
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
В данном дипломном проекте автоматизируется рутинная работа аналитика
организации по сбору цен конкурентов.
Порядок действий со стороны аналитика в данной информационной
системе:
1. Заполнение номенклатуры;
2. Заполнение магазинов;
3. Группировка номенклатуры (если требуется);
4. Заполнение ссылок на интернет-магазины;
5. Запуск сканирования;
6. Получение результата.
В дальнейшем требуется только лишь запускать сценарий сканирования.
Если требуется завести новую номенклатуру, либо изменить старую, то
функционал информационной системы позволяет это сделать.
Таким образом, лишь первоначальное заполнение займёт максимальное
время. В дальнейшем вся работа автоматизирована.
Схематически сценарий работы в информационной системе изображён на
рисунке 30.
Рис. 30 - Сценарий диалога в ИС.
72
Логика работы информационной системы следующая:
Заполняется номенклатура;
Заполняются магазины;
Для каждого магазина создаётся шаблон из исходного кода страницы
с товаром в этом магазине;
Объект «товар» содержит количество ссылок, сопоставимое с
каждым магазином;
При сканировании загружается исходный код страницы каждого
товара в каждом магазине;
В соответствии с заданными шаблонами производится выборка
цены;
Цена заносится в результирующую таблицу.
2.3.2. Характеристика базы данных
В рамках данного проекта приложение будет выполнять следующий набор
функций:
добавление/изменение/удаление магазина;
добавление/изменение/удаление товара;
добавление/изменение/удаление категории товаров;
добавление/изменение товара в категории;
добавление/изменение ссылок на товар;
парсинг страниц товара;
хранение предыдущих результатов парсинга.
На основании данного функционала можно выделить следующие хранимые
объекты:
магазин;
товар;
категория;
ссылка;
значение.
73
Каждый магазин, товар и категория должны иметь свои уникальные
идентификаторы, поскольку между ними и остальными объектами должна
существовать связь. Эта связь будет реализована благодаря данным
идентификаторам.
Каждая ссылка имеет отношение к конкретному товару в конкретном
магазине. Каждое значение, полученное при парсинге страницы по ссылке, имеет
отношение также к конкретному товару в конкретном магазине. Категория же при
необходимости может быть связана с конкретным товаром.
Основываясь на вышесказанном можно перечислить следующие таблицы:
items – таблица, содержащая в себе номенклатуру товара;
shops – таблица, содержащая в себе магазины;
categories – таблица, содержащая в себе категории для группировки
товара;
links – таблица, содержащая в себе ссылки на определённый товар в
том или ином магазине;
values – таблица, содержащая в себе результаты последнего
сканирования;
history – таблица, содержащая в себе все результаты сканирований.
В таблице «items» должны содержаться следующие поля:
id – уникальный идентификатор товара;
name – наименование товара;
cat_id – идентификатор категории, к которой относится данный
товар.
В таблице «shops» должны содержаться следующие поля:
id – уникальный идентификатор магазина;
name – наименование магазина;
link – общая ссылка на магазин. В рамках данного проекта служит
только для информации;
text_from – поле выборки текста «от»;
74
text_to – поле выборки текста «до».
Поля «text_from» и «text_to» созданы для дальнейшего парсинга страниц
данного магазина. Поскольку весь магазин в каталоге для каждого товара имеет
абсолютно одинаковую вёрстку страниц, то парсеру страниц при проходе по
ссылкам будет «видно» где именно брать значение с ценой на странице.
В таблице «categories» должны содержаться следующие поля:
id – уникальный идентификатор категории;
name – наименование категории.
В таблице «links» должны содержаться следующие поля:
iid – уникальный идентификатор товара, к которому относится
данная ссылка;
sid – уникальный идентификатор магазина, к которому относится
данная ссылка;
link – непосредственно ссылка на конкретный товар в конкретном
магазине.
Стоит обратить внимание на то, что в определённом магазине может не
быть какого-либо определённого товара, поэтому ссылки может просто не
существовать. Однако, запись в таблице содержаться может без ссылки. Стоит это
учесть на следующих этапах разработки приложения.
В таблице «values» должны содержаться следующие поля:
iid – уникальный идентификатор товара;
sid – уникальный идентификатор магазина;
value - значение, полученное при сканировании.
Таблица «history» по сути является аналогичной «values» за исключением
дополнительного поля – date. Данная таблица будет заполняться параллельно
«values», но в момент сканирования в поле «date» будет указано время на момент
сканирования. Таким образом в дальнейшем появляется возможность удобного
просмотра истории цен.
75
На этом планирование структуры базы данных можно считать оконченным.
В рамках данного проекта программа не будет разделена на клиентскую и
серверную части, поэтому будет использоваться встраиваемая СУБД SQLite.
Встраиваемые СУБД, как правило, не являются самостоятельными
системами, а являются подключаемыми библиотеками. В данном проекте для
работы с SQLite будет использоваться подключаемая библиотека «sqlite-jdbc».
JDBC (JavaDataBaseConnectivity) – кросс-платформенный промышленный
стандарт взаимодействия Java-приложений с различными СУБД, реализованный
в виде пакета java.sql, входящего в состав Java SE.[23]
SQL (Structured Query Language) – структурированный язык запросов. Он
позволяет СУБД с помощью запросов создавать реляционные базы данных,
представляющие собой набор связанных данных, хранящихся в таблицах, и
оперировать ими.[24]
Таким образом, посредством JDBC мы может выполнять команды SQLite,
которые, в свою очередь, обращаются непосредственно к базе данных.[25]
В основном синтаксис SQL-запросов SQLite не отличается от любых
других СУБД. Но бывают исключения.
В рамках данного проекта для создания таблиц, озвученных в предыдущем
параграфе, будут использоваться следующие SQL-запросы:
CREATE TABLE if not exists 'shops' (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name VARCHAR(50) NOT NULL,
"ink TEXT NOT NULL,
text_from TEXT NOT NULL,
text_to TEXT NOT NULL);
CREATE TABLE if not exists 'items' (
id INTEGER PRIMARY KEY AUTOINCREMENT,
76
name VARCHAR(50) NOT NULL,
cat_id INTEGER);
CREATE TABLE if not exists 'links' (
iid INTEGER,
sid INTEGER,
link TEXT NOT NULL);
CREATE TABLE if not exists 'categories' (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name VARCHAR(50) NOT NULL);
CREATE TABLE if not exists 'values' (
iid INTEGER,
sid INTEGER,
value VARCHAR(10) NOT NULL);
CREATE TABLE if not exists 'history' (
date DATETIME,
iid INTEGER,
sid INTEGER,
valueVARCHAR(10) NOTNULL);
Информация о записях из «Items» содержится в записях из таблиц «Links»,
«Values», «History», «Categories». Информация о записях таблицы «Shops»
содержатся в записях таблиц «Links», «Values», «History». Таким образом,
структуру базы данных ИС можно представить в виде следующей модели.
(рисунок 31):
77
Рис. 31 - Структура БД.
На данном этапе проектирование базы данных для информационной
системы можно считать оконченным.
2.3.3. Структурная схема пакета (дерево вызова программных
модулей)
Как и любой современный язык программирования Java (в частности и
JavaFX) позволяет использовать схему разделения данных приложения MVC.
Model-View-Controller (MVC, «Модель-Представление-Контроллер»,
«Модель-Вид-Контроллер») – схема разделения данных приложения,
пользовательского интерфейса и управляющей логики на три отдельных
компонента: модель, представление и контроллер – таким образом, что
модификация каждого компонента может осуществляться независимо[26]:
модель (Model) предоставляет данные и реагирует на команды
контроллера, изменяя своё состояние;
представление (View) отвечает за отображение данных модели
пользователю, реагируя на изменения модели;
контроллер (Controller) интерпретирует действия пользователя,
оповещая модель о необходимости изменений.