CC BY
26
Cloud of Science. 2020. T. 7. № 3 http:/ / cloudofscience.ru
Опыт создания программы автоматической генерации веб-приложений по формальным
требованиям
П. В. Корытов, С. А. Беляев
Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» 197376, Санкт-Петербург, ул. Профессора Попова, 5
e-mail: thexcloud@gmail.com, bserge@bk.ru
Аннотация. В статье рассматривается проблема автоматизированного создания веб-приложений по формальным требованиям. Рассмотренные существующие решения, такие как средства проектирования баз данных и коммерческие конструкторы приложений, либо не предоставляют достаточную функциональность для создания работающего приложения, либо не работают с формальными моделями и малорасширяемы. Разработанное авторами решение предоставляет возможность создания клиент-серверного веб-приложения по модели «сущность-связь». Статья описывает алгоритм генерации кода по этой модели и некоторые детали создания системы, независимой от предметной области. Решение позволяет автоматизировать создание простых учетных систем и упростить создание более сложных.
Ключевые слова: модель сущность-связь, веб-разработка, генерация кода.
1. Введение
Учетные системы — приложения, хранящие, обрабатывающие информацию и отвечающие на запросы пользователя относительно этой информации. Разработка такой системы — трудоемкая задача, включающая в себя разработку архитектуры базы данных, интерфейса пользователя, программирование системы, кода клиента и сервера.
Поскольку перечисленные шаги повторяются вне зависимости от требований к системе, процесс разработки можно автоматизировать.
Рассмотрим автоматизацию разработки такой системы на основе формальной модели предметной области — модели «сущность-связь» (ER-модель, Entity-Relationship Model).
2. Обзор существующих решений
К поиску существующих продуктов для решения этой задачи можно подойти со стороны работы с формальными моделями или создания работающей системы.
2.1. Автоматизация создания структуры БД по формальным моделям
Существует множество решений для автоматизации создания базы данных (далее — БД). При этом используются различные варианты модели «сущность-связь».
Примеры простых сервисов для создания структуры БД — веб-приложения ERDPlus (https://erdplus.com) и SqlDBM (https://sqldbm.com). Первый сервис дает возможности конвертации логической ER-модели (соответствующей структуре предметной области) в физическую (соответствующую структуре БД, в данном случае — реляционную). Второй сервис работает только с реляционной моделью. Итоговую реляционную модель оба сервиса «переводят» в код различных диалектов SQL, который можно использовать для задания структуры БД. SqlDBM может решить обратную задачу — восстановление модели по SQL-коду.
Приложение MySQL Workbench является аналогичным решением, оно может использоваться для тех же целей [1]. Эта программа ограничена работой с одноименной системой управления базами данных (СУБД) MySQL, но, помимо создания структуры БД, предоставляет возможности для администрирования.
Все перечисленные решения работают с формальными моделями, но не могут использоваться для создания готового приложения, поскольку структура базы данных — не единственная часть системы.
2.2. Генерация кода
CASE-средство Visual Paradigm можно рассматривать как логичное развитие систем автоматизированного создания структур БД по формальным моделям [2].
Помимо работы с физическими и логическими ERD (Entity Relationship Diagrams) (один вид свободно конвертируется в другой), заслуживает внимание возможность генерации кода ORM (Object-Relational Mapping, объектно-реляционное отображение) по физической модели. Таким образом, макетируется не только структура базы данных, но и элементы программного кода — помимо классов ORM, возможно создание классов приложения по диаграмме классов и т. п.
Ограничивает применение то, что ORM-код генерируется только для одного фреймворка Hibernate (Java). И даже без учета этого ограничения, работающее приложение с помощью этого средства получить невозможно.
2.3. Создание приложений
2.3.1. ZoHo Creator
Существуют коммерческие системы, направленные непосредственно на создание приложений; например, ZoHo Creator — конструктор веб-приложений для автоматизации потоков данных.
Создание приложения производится в основном с помощью WYSIWIG-интерфейса, причем на каждом этапе создания приложение работоспособно. Сервис рассчитан на пользователей, незнакомых с программированием, но поддерживает добавление пользовательских скриптов и страниц [3].
Однако, работа с формальными моделями (в контексте создания структуры БД) в приложении отсутствует. Кроме того, сервис распространяется на коммерческой основе Software-As-Service (SaaS, программное обеспечение как услуга), то есть созданное приложение со всеми данными находится только на серверах компании ZoHo [4].
Затем, пользовательские скрипты создаются на собственном языке системы, и потому ограничены, произвольный код в программе выполнить невозможно.
2.3.2. Microsoft Access
Как и ZoHo Creator, Microsoft Access позволяет создать работающее приложение с помощью WYSIWIG-интерфейса [5].
Созданное приложение со всеми данными располагается локально, но работает тоже локально. Ранее, сервис Access Web Apps позволял организовать взаимодействие с приложением по схеме, аналогичной ZoHo, но эта возможность более не предоставляется.
Теоретически, в приложении можно выполнить произвольный код; практически, осложняет ситуацию редкое использование встроенного языка программирования Visual Basic For Applications (0.77%, 18-е место в индексе TIOBE [6]). По полученной формальной модели приложение создать нельзя.
Дополнительный недостаток Access и ZoHo Creator — коммерческая лицензия.
2.4. Краткие выводы
Из рассмотренных решений, те, которые работают с высокоуровневыми (близкими к предметной области) формальными моделями, не предоставляют достаточную функциональность для создания работающего приложения. Программисту остается значительная часть работы, в том числе — создание интерфейса пользователя.
С другой стороны, решения, которые направлены на создание приложений, с формальными моделями практически не работают, распространяются на коммерческой основе и предоставляют ограниченные возможности для расширения.
3. Описание разработанного решения
3.1. Требования и задачи
С учетом вышесказанного, разрабатываемое решение должно решать следующие задачи.
- Контролируемое создание структуры БД по ER-моделям.
- При разработке структуры БД по ER-модели требуется меньшее количество действий, в частности, при работе с внешними ключами и многосторонними зависимостями.
- Предоставление интерфейса для взаимодействия с БД.
- Предоставление готового расширяемого интерфейса позволит подготовить систему к использованию за меньшее время.
- Реализация в системе произвольной бизнес-логики.
- Если функциональности созданной системы недостаточно, должна быть возможность расширения, то есть исполнения произвольного кода на стороне сервера.
Решение должно разворачиваться на собственном сервере и использовать реляционную СУБД с целью автоматизации создания простых учетных систем и упрощения создания более сложных.
3.2. Общая архитектура решения
Архитектура разработанного решения приведена на рис. 1, она описана с использованием архитектурного шаблона «Слои», как это принято при описании «больших» систем [7]. Решение условно делится на две части: программу-генератор и учетную систему.
В качестве СУБД используется PostgreSQL [8], которая широко используется на практике и показывает производительность, сравнимую с нереляционными аналогами, в случае строгих структур данных [9]. Именно такие структуры и будут получаться в результате работы основного алгоритма.
В качестве языка серверной части используется Python 3 по причине простоты и компактности [10], а также легкости динамического подключения модулей.
Рисунок 1. Архитектура решения
Серверная часть учетной системы использует веб-фреймворк Flask (pallets/flask) и ORM-фреймворк SQLAlchemy (sqlalchemy/sqlalchemy) [11]. Код классов SQLAlchemy генерируется по ER-модели.
Основные технологии клиентской части учетной системы — Vue.js (vuejs/vue) и TypeScript (microsoft/TypeScript). Как и для серверной части, выбор обусловлен легкостью расширения полученного модуля.
Поскольку клиентское приложение «не привязано» ни к какой предметной области, используются универсальные компоненты, например, Vue Form Generator (vue-generators/vue-form-generator). Используемое средство отображения таблиц — Ag Grid (ag-grid/ag-grid).
Развертывание системы планируется осуществлять на сервере nginx [12]. Чтобы компенсировать проблемы с многопоточностью, свойственные Python, используется WSGI-сервер Gunicorn (benoitc/gunicorn) [13].
4. Работа с ER-моделями
В модулях программы-генератора выполняется основной процесс настройки приложения под конкретную предметную область. Основные шаги:
- создание реляционной модели по ER-модели;
- генерация кода ORM по реляционой модели;
- формирование настроек системы по реляционной модели.
4.1. ER-модель
Создание учетной системы начинается с построения логической ER-модели для предметной области. Для отображения ER-моделей используется нотация Мартина (Crow's Foot, «куриная лапка»), описанная в [14].
Хотя при использовании ER-модели для проектирования базы данных «вручную» можно сделать ряд упрощений, например, опустить неключевые атрибуты сущностей на диаграмме [15], для автоматического создания системы по ER-модели такое упрощение провести невозможно; напротив, модель должна содержать всю информацию, необходимую для создания структуры БД.
В системе ER-модель записывается в формате XML. Итоговая структура ER-модели и соответствующие теги XML приведены ниже: Сущность (entity) — id, имя (name)
Атрибут (attribute) — название (name), является ли ключом (isPk), тип (type). Связь (relation) — имя (name)
Сторона связи — сущность (idRef), кратность (isMultiple), обязательность (isMandatory).
Связь содержит хотя бы две стороны.
На рис. 2 приведен пример простого отношения.
Задача
Список
Название Дата окончания
Название
Описание
Рисунок 2. Пример отношения
Это отношение в XML описанного формата будет задано следующим образом: <?xml version="1.0" ?> <erModel>
<entity id="1">
<name>Task</name> <attribute>
<name>Name</name> <isPk>true</isPk> <type>varchar(2 00)</type> </attribute> <attribute>
<name>Due date</name> <type>date</type> </attribute> <attribute>
<name>Description</name> <type>text</type> </attribute> </entity> <entity id="2">
<name>List</name> <attribute>
<name>Name</name> <isPk>true</isPk> <type>varchar(2 00)</type> </attribute> </entity> <relation>
<name>belongs to</name> <side>
<idRef>1</idRef>
<isMandatory>false</isMandatory> <isMultiple>true</isMultiple> </side> <side>
<idRef>2</idRef>
<isMandatory>true</isMandatory> <isMultiple>false</isMultiple> </side> </relation> </erModel>
4.2. Модель хранения данных
Следующий шаг после разработки ER-модели — создание модели хранения данных. Основной алгоритм создания реляционной модели по ER подробно описан в [16]. Идея алгоритма — перевод сущностей логической модели в физическую; некоторые сущности объединяются в зависимости от отношений, некоторые отношения возводятся в ранг сущностей. Блок-схема алгоритма приведена на рис. 3.
Используемые в системе технологии диктуют свои требования: полученная из ER-модели структура должна содержать всю необходимую информацию для создания таблиц БД (PostgreSQL) и соответствующих классов ORM (SQLAlchemy).
Первый шаг алгоритма — создание таблиц для всех сущностей модели. Затем, каждое отношение обрабатывается по схеме, приведенной на рис. 3. При этом сначала обрабатываются отношения 1-1.
Необходимо выполнить следующие настройки алгоритма (на схеме — OPT и номер):
Добавление уникального индекса (UNIQUE INDEX) в связную таблицу (в терминологии SQLAlchemy — "secondary table").
Добавление недостающих проверок обязательности отношений (описано далее).
Разрешение отношения 0..1 — 1..* через две таблицы с обнуляемым (NULL) внешним ключом.
Проблема «недостающих проверок» заслуживает более подробного рассмотрения. Пусть отношение из примера на рис. 2 обязательное с обоих сторон — т. е. «список» обязательно включает в себя хотя бы одну «задачу».
Со стороны «задачи» достаточно установить обязательный внешний ключ, но со стороны «списка» такого простого средства для проверки обязательности нет. Вариант решения проблемы — установка триггера (в БД или в коде) на удаление «задачи» и на создание «списка», проверяющего корректность отношения.
В системе выбран вариант установки кода проверки в коде классов ORM, как рекомендуется в документации. Поскольку это приводит к снижению производительности и усложнению модели, добавление таких проверок можно отключить.
Последний шаг — разрешение ключевых атрибутов. В тех сущностях, где ключевой атрибут не был задан, в этом качестве будет использован уникальный внешний ключ (если такой есть) или автоматическое поле id.
Рисунок 3. Основной алгоритм
4.3. Генерация кода
Следующий этап — создание кода ORM. Для этой цели использованы 2 средства — шаблонизатор Jinja2 (pallets/jinja) и автоматический форматировщик кода YAPF (google/yapf).
Ниже приведен пример сгенерированного кода для «списка» для модели, представленной на рис. 2, дополненный комментариями для облегчения восприятия.
class Ex1List(Base):
# Имя таблицы tablename = 'list'
# Схема, здесь же может быть уникальный индекс по внешним ключам table args = ({'schema': 'er1'})
# Ключевой атрибут name = sa.Column(
sa.String(2 00), primary key=True, nullable=False, unique=True,
)
# Логическое отношение, соответствующее существованию внешнего
# ключа в другой сущности
task belongs to = sa.orm.relationship(
'Ex1Task', back populates='belongs to list'
)
Все созданные таблицы находятся в уникальной схеме (SCHEMA). Это позволяет поддерживать несколько моделей в одной базе данных и облегчает обслуживание.
Уникальный индекс по внешним ключам добавляется, когда отношение логической модели в физической становится сущностью (правая ветвь на схеме алгоритма).
Пример кода для «задачи» приведен ниже.
class Ex1Task(Base):
tablename = 'task'
table args = ({'schema': 'er1'})
name = sa.Column(
sa.String(2 00), primary key=True, nullable=False, unique=True,
)
# Неключевой атрибут
due date = sa.Column( sa.Date(), nullable=False,
)
# Неключевой атрибут description = sa.Column(
sa.Text(), nullable=False,
)
# Внешний ключ
list name = sa.Column( sa.String(200),
sa.ForeignKey('ex1.list.name', ondelete='cascade', onupdat e='cascade'),
nullable=False,
)
# Логическое отношение, соответствующее внешнему ключу таблицы belongs to list = sa.orm.relationship(
'ExlList', back populates='task belongs to', foreign keys= [list name]
Г
Здесь внешний ключ — физическое отношение между таблицами, использующееся СУБД. Логическое отношение устанавливается между классами ORM, и может (но не обязано) соответствовать атрибуту внешнего ключа в данном классе [11].
В приведенном примере показана связь «один-ко-многим». Для связи «многие-ко-многим», где будет создана дополнительная таблица ("secondary table", вторичная таблица), логическое отношение может выглядеть так:
is assigned to task = sa.orm.relationship( _ 'ErlTask',"
secondary='er1.user is assigned to task', back populates='is assigned to user'
)
То есть, цель (target) такого отношения — класс ORM, но атрибут дополнительной таблицы (secondary) указывает в базу данных.
4.4. Завершение создания
Завершающий этап автоматической генерации — настройка системы. В файл с настройками (также в формате XML) добавляются записи о созданных таблицах; для каждой таблицы создается форма ввода по умолчанию.
В дальнейшем эти настройки могут редактироваться в графическом интерфейсе программы-генератора.
5. Создание независимого от предметной области REST API
После завершения основной работы программы-генератора имеются созданные классы ORM и файл с настройками. Эти артефакты используются в созданной учетной системе.
5.1. Обработка запросов
Часто при составлении REST API сервера для каждого вида доступа к данным (например, запроса к таблице) пишутся отдельные обработчики. В них же может включаться вызов модулей бизнес-логики [13].
В создаваемой системе обработчик запросов должен быть универсальным. В основе обработчика лежит модуль SQLAlchemy JSON Querybuilder (suyash248/sqlalchemy-json-querybuilder), который дает средства для перевода запросов в формате JSON в SQLAlchemy Queryset.
Запрос вида: "filter_by": {
"and": [criterion_1, ... criteron_n], "or": [criterion_o1, ... criteron_on]
} ,
"order": ["Model.field_1", "-Model.field_2"]
Приводится к следующему виду на SQL: SELECT field_1, field_2, ..., field_n FROM table WHERE
(criterion 1 AND ... AND criteron n) OR (criterion o1 OR ... OR criteron on) ORDER BY field_1 ASC, field_2 DESC; _
Здесь criteron может быть как единичным условием (вида field_1 = value), так и
вложенным, что дает доступ к широкому спектру возможных запросов. Результат использования этого механизма в клиентском приложении представлен на рис. 4.
5.2. Сериализация
После того, как данные получены из БД, нужно вернуть их клиентской части веб-приложения. Следует отметить, что в SQLAlchemy отсутствуют встроенные возможности для сериализации объектов.
Для решения задачи сериализации используется библиотека marshmallow (marshmallow-code/marshmallow), которая она позволяет задавать «схемы» для объ-
ектов с возможностью сериализации (переводить в типы вроде JSON) и десериали-зации (переводить обратно в объекты Python).
Библиотека интегрируется со SQLAlchemy с помощью модуля marshmallow-sqlalchemy (marshmallow-code/marshmallow-sqlalchemy). Для корректной работы для каждой модели ORM следует указать класс-схему библиотеки сериализации.
Чтобы избежать генерации кода еще одного класса для каждой сущности, в модуль динамического подключения моделей при запуске добавлено автоматическое создание схем. Это трудоемкая операция, но она должна быть выполнена только один раз — при запуске сервера.
Пример сериализации «задачи» из примера на рис. 2:
{
"name": "task_1",
"due_date": "2010-10-15 15:12:54:00", "description": "description", "belongs to list": 2
}
ffl + New h' Export « Manual fi Access rights
f Id Name X Due dale T
50 Chris Figueroa 18-09-2011 15:43:41
20 David Potter 27-09-2000 11:51:39
147 Donald Walsh 06-06-1994 22:09:20
5 Kerry Rogers 28-04-19B9 11:13:49
129 Luke Wood MD 28-11-2017 06:26:33
68 Susan Roberts 07-05-2019 16:56:24
46 Veronica Nguyen 16-06-1993 02:07:36
T x
k
О AND @ .
.a(JO BVBI |>| .y fjoar
Class year public strategy pair
Ij []
Q []
г 1 of 1 > >l
Рисунок 4. Использование фильтров
5.3. Транзакции
Следует обратить внимание и на необходимость обработки строгих моделей, для примера рассмотрим вариацию отношения на рис. 2, в которой список включает в себя хотя бы одну задачу. Если установлены нужные настройки алгоритма, для пустой БД получится следующая ситуация:
нельзя создать «список», потому что нет задач, которые можно в него вклю-
чить;
- нельзя создать «задачу», потому что нет списка, в который можно включить задачу.
То есть, «список» и «задача» могут быть созданы только вместе. Со стороны сервера для разрешения проблем этого рода используются транзакции; нужно реализовать такую же функциональность на стороне клиентского приложения (см. рис. 5).
Н Run check О Revert В Commit
You have uricommited changes: 2 changed records, 1 created records and 1 deleted records.
Table Type fi Record key Status Actions
Task Updated 2 ✓ ■э
Task Updated 4 S ■э
Task Deleted 7 i Warnings В
Task New record + New •У В
1 to 4 of 4 К < Page 1 of 1 > >l
Рисунок 5. Работа с транзакциями на стороне клиентского приложения
Поэтому в разработанной системе один запрос на изменение, добавление или удаление записей в БД — одна транзакция, состоящая из нескольких таких действий.
На рис. 6 представлена работа со связанными таблицами.
6. Тестирование производительности системы
Созданная система развернута на компьютере с ЦП AMD Ryzen 5 1400 (8 ядер) @ 3.2 ГГц, 8 ГБ RAM.
Запрос с фильтрацией и сортировкой к таблице с 100 000 записями выполняется в среднем (здесь и далее n = 5):
- за 244 мс через ORM;
- за 610 мс через REST API.
Запрос к первой записи — 14 мс. Запрос к 100 000-й записи — 69 мс.
Рисунок 6. Работа со связанными таблицами
7. Заключение
Разработанное решение не позволяет генерировать произвольные программы, например, программу [17], но оно позволяет автоматизировать создание простых учетных систем и упростить создание более сложных.
В отличие от рассмотренных аналогов, это решение может быть развернуто на собственном сервере и поддерживает выполнение произвольного кода бизнес-логики. Выбранные технологии позволяют расширить систему без внесения модификаций в исходный код.
Вмешательство программиста может потребоваться для более сложных предметных областей, например, с цепными связями между таблицами. В этом случае возникают сложные отображения, когда не вся интересующая пользователя информация будет показываться по умолчанию. Обработка запросов к сложносвязан-ным таблицам может занять непропорционально (относительно количества записей) много времени. Эта проблема показывает ограничения модели «сущность-связь», т. к. в модели нет информации о структуре будущих запросов или о формате отображения данных. Решение этих вопросов составляет важную часть дальнейшей работы.
Литература
[1] Yang L., Cao L. The Effect of MySQL Workbench in Teaching Entity-Relationship Diagram (ERD) to Relational Schema Mapping // International Journal of Modern Education and Computer Science. 2016. Vol. 8. № 7. P. 1-17.
[2] Tsang C., Lau C., Leung Y. Object-Oriented Technology: From Diagram to Code with Visual Paradigm for UML. 2nd ed. — N. Y. : McGraw-Hill Education, 2010.
[3] Shabdar A. Mastering Zoho Creator: Build Cloud-Based Business Applications from the Ground Up. — N. Y. : Apress, 2017.
[4] Gonidis F. et al. Cloud application portability: an initial view // Proceedings of the 6th Balkan Conference in Informatics. — Thessaloniki, Greece, 2013. P. 275-282.
[5] Conrad J. Microsoft Access 2013 Inside Out. — London : Microsoft Press, 2013.
[6] TIOBE Software BV. TIOBE Index for March 2020 [Электронный ресурс]. URL: https://www.tiobe.com/tiobe-index/.
[7] Беляев С.А., Васильев А.В., Кудряков С.А. Архитектура системы мониторинга информационных трендов на основе свободного программного обеспечения // Программные продукты и системы. 2016. Т. 29. № 4. С. 85-88.
[8] Riggs S. et al. PostgreSQL 9 administration cookbook. — Birmingham : Packt Publishing Ltd., 2015.
[9] Jung M. G. et al. A study on data input and output performance comparison of mongodb and postgresql in the big data environment // 2015 8th International Conference on Database Theory and Application (DTA). — 2015. P. 14-17.
[10] Nanz S., Furia C. A. A comparative study of programming languages in rosetta code // IEEE/ACM 37th IEEE International Conference on Software Engineering. — IEEE Publ., 2015. Vol. 1. P. 778-788.
[11] Bayer M. The Architecture of Open Source Applications. Vol. II: Structure, Scale, and a Few More Fearless Hacks. — 2012.
[12] Беляев С. А. Веб-технологии: лабораторный практикум. — СПб. : Изд-во СПбГЭТУ «ЛЭТИ», 2019.
[13] Gareth D., Aggarwal S., Stouffer J. Flask: Building Python Web Services. — Birmingham : Packt Publishing Ltd., 2017.
[14] Hitchman S. The details of conceptual modelling notations are important — a comparison of relationship normative language // Communications of the Association for Information Systems, 2002. Vol. 10. P. 166-179.
[15] Chen P. P.-S. The entity-relationship model-toward a unified view of data // ACM Transactions on Database Systems. 1976. Vol. 1. P. 9-36.
[16] Teorey T. J., Dongoing Y., Fry J. P. A logical design methodology for relational databases using the extended entity-relationship model // ACM Computing Surveys. 1986. Vol. 18. № 2. P. 197-222.
[17] Osipov V., Vodyaho A., Zhukova N. About one approach to multilevel behavioral program synthesis for television devices // International Journal of Computers and Communications. 2017. Vol 11. P. 17-25.
Авторы:
Павел Валерьевич Корытов — студент, факультет компьютерных технологий и информатики, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ»
Сергей Алексеевич Беляев — кандидат технических наук, доцент, факультет компьютерных технологий и информатики, Санкт-Петербургский государственный электротехнический университет «ЛЭТИ»
Experiences of Developing a Program for Automated Generation of Web Applications by the Formal Requirements
P. V. Korytov, S. A. Belyaev
Saint-Petersburg State Electrotechnical University "LETI", 5 Prof. Popova st., 197376, Saint-Petersburg e-mail: thexcloud@gmail.com, bserge@bk.ru
Abstract. The article considers the problem of automated generation of web applications by the formal requirements. Reviewed existing solutions, such as database design tools and commercial application constructors either do not have enough functionality to create a working application or do not work with formal models and poorly extensible. The solution, developed by the authors, has capacity of creating a client-server web application by the entity-relationship model. The article describes the code generation algorithm and certain details of creating of an independent from the domain area system. The solution can automate the creation of simple data accounting systems and simplify development of more complex ones. Keywords: entity-relationship model, web development, code generation.
References
[1] Yang L., Cao L. (2016) International Journal of Modern Education and Computer Science, 8(7):1-17.
[2] Tsang C., Lau C., Leung Y. (2010) Object-Oriented Technology: From Diagram to Code with Visual Paradigm for UML (2nd ed., McGraw-Hill Education).
[3] Shabdar A. (2017) Mastering Zoho Creator: Build Cloud-Based Business Applications from the Ground Up (Apress).
[4] Gonidis F. et al. (2013) Cloud application portability: an initial view. In Proceedings of the 6th Balkan Conference in Informatics (Thessaloniki, Greece), pp. 275-282.
[5] Conrad J. (2013) Microsoft Access 2013 Inside Out (Microsoft Press).
[6] https://www.tiobe.com/tiobe-index/
[7] Belyaev S. A., Vasiliev A. V., Kudryakov S. A (2016) Programmnye produkty i sistemy, 29(4):85-88 [Rus]
[8] Riggs S., et al. (2015) PostgreSQL 9 administration cookbook (Packt Publishing Ltd.).
[9] Jung M. G. et al. (2015) A study on data input and output performance comparison of mongodb and postgresql in the big data environment. In 2015 8th International Conference on Database Theory and Application (DTA), pp. 14-17.
[10] Nanz S., Furia C. A. (2015) A comparative study of programming languages in rosetta code. In IEEE/ACM 37th IEEE International Conference on Software Engineering, Vol. 1, pp. 778-788.
[11] Bayer M. (2015) The Architecture of Open Source Applications Vol. II: Structure, Scale, and a Few More Fearless Hacks.
[12] Belyaev S. A. (2019) Be6-tekhnologii: laboratornyjpraktikum (SPbGETU "LETI"). [In Rus]
[13] Gareth D., Aggarwal S., Stouffer J. (2017) Flask: Building Python Web Services. (Birmingham, Packt Publishing Ltd).
[14] Hitchman S. (2002) Communications of the Association for Information Systems. 9(1): 166-179.
[15] Chen P. (1976) ACM transactions on database systems (TODS), 1:9-36.
[16] Teorey T. J, Dongoing Y, Fry J. P. (1986) ACM Computing Surveys (CSUR), 18(2):197-222.
[17] Osipov V., Vodyaho A., Zhukova N. (2017) Intern'l J of computers and communications, 11:17-25.
