Файл: Методика защиты информации в системах электронного документооборота (Выбор программных средств разработки).pdf

Выбор программных средств разработки является основным этапом при разработке. Каждое программное средство предназначено для решения определенных задач. В данном случае необходимо выполнить следующее:

1. Выбор языка программирования и фреймворка;
2. Выбор веб-сервера;
3. Выбор СУБД.

Выбор языка программирования и фреймворка

Для разработки веб-приложения можно использовать различные языки программирования и фреймворки.

Обычно реализация веб-приложения состоит из двух частей – серверной и клиентской. Клиентская часть обычно реализуется с помощью средств HTML, CSS, JavaScript. Серверная часть реализуется с помощью различных языков программирования – Java, C#, PHP, Python, Ruby и т.д.

Наиболее популярными являются:

• • PHP – скриптовый язык общего назначения, интенсивно применяемый для разработки веб-приложений;
  • Python – высокоуровневый язык программирования общего назначения, ориентированный на повышение производительности разработчика и читаемости кода;
  • Ruby – динамический, рефлективный, интерпретируемый высокоуровневый язык программирования. [8]

Для каждого из описанных языков существуют фреймворки для построения веб-приложений: Laravel/Symphony/Yii2 для PHP, Django/Flask для Python, Ruby on Rails для Ruby. Данные фреймворки предоставляют набор готовых функций и API для взаимодействия с ними, а также диктуют правила построения архитектуры приложения.

С помощью Django и Python можно создать веб приложение, работающее как с файлами, так и с HTTP-запросами. Язык является интерпретируемым и свободно распространяемым. При этом данный язык поддерживает компилирование в byte-код, что позволяет увеличить скорость выполнения.

Достоинства:

• • простота разработки – исходный код имеет наглядную структуру, а благодаря отсутствию необходимости описывать переменные перед их инициализацией сохраняется семантика;
  • кроссплатформенность интерпретатора – данная возможность позволяет разрабатывать и разворачивать веб-приложения на рабочей станции или сервере с любой операционной системой;
  • большое количество готовых библиотек от сторонних разработчиков, позволяющих ускорить процесс разработки приложений;
  • поскольку каждый Python-проект желательно запускать в виртуальном окружении (создаваемым приложением virtualenv), отсутствует конфликт версий библиотек и приложений, а код является изолированным на уровне операционной системы.

Фреймворк Django реализует шаблон MVT (Model, View, Template – интерпретацию шаблона MVC, где в роли контроллера выступает View, а в роли представления - Template) и предоставляет богатый API для реализации как компонентов, необходимых для работы (моделей, представлений и шаблонов), так и собственных библиотек функций и классов.

В состав данного фреймворка входит большое количество разнообразных модулей, позволяющих создавать современные веб- приложения.

Достоинства решения на Python/Django:

• • бесплатное распространение;
  • кроссплатформенность;
  • расширяемость;
  • высокая производительность по сравнению с другими интерпретируемыми языками программирования;
  • абстрагирование от конкретной СУБД;
  • высокая скорость разработки. Недостатки данного решения:
  • непривычный синтаксис;
  • необходимость конфигурации каждого узла системы.

Выбор веб-сервера

Для работы с Python/Django могут быть использованы следующие веб- серверы:

• • Apache с модулем mod_python;
  • Nginx с через приложение uWSGI;
  • Gunicorn с Nginx в качестве reverse-Proxy;
  • Microsoft IIS.

Был выбран Microsoft IIS, так как это является одним из требований к системе.

Выбор СУБД

Django поддерживает четыре системы управления базами данных:

• • PostgreSQL;
  • SQLite 3;
  • MySQL;
  • Oracle.

Используемая СУБД должна отвечать таким требованиям, как быстрота, простота, эффективность и надежность. По умолчанию в настройках Django указано использование SQLite. Django изначально проектировалась и разрабатывалась для работы с СУБД PostgreSQL.

В таблице 2.2.1 приведен сравнительный анализ данных СУБД. [10] Таблица 2.2.1 – Сводная таблица характеристик СУБД

PostgreSQL – свободная объектно-реляционная система управления базами данных, основанная на языке SQL – языке структурированных запросов, являющемся стандартом для разработки реляционных БД. Отличительной особенностью реляционных баз данных являются отношения. Внутренние механизмы оптимизации отношений позволяют добиться высокой скорости обработки. Также отношения позволяют связывать данные из нескольких таблиц при выполнении запросов.

К преимуществам данной СУБД относятся:

• • высокопроизводительные и надежные механизмы транзакций и репликации;
  • расширяемая система встроенных языков программирования;
  • наследование;
  • легкая расширяемость;
  • многоверсионность – одновременная модификация базы данных несколькими пользователями с помощью механизма Multiversion Concurrency Control, благодаря чему отпадает нужда в блокировании чтения [12];
  • возможность создания пользовательских типов данных.

PostgreSQL – наиболее подходящее решение для создания вебприложений и веб-сервисов любой сложности с помощью фреймворка Django, которые ориентированы на получение, хранение и обработку информации. Данное решение позволяет создавать динамически генерируемые HTML представления, то есть включающими информацию, изменяемую в реальном времени.

Так же в состав Django входит библиотека Django ORM, предоставляющая интерфейс для работы с СУБД. С помощью данной библиотеки, реализующей шаблон проектирования «Active Record», возможно создание запросов к БД в виде использования методов классов, унаследованных от класса Model. Также данная библиотека оптимизирует текст запроса и выполняет его только в момент обращения к данным, что позволяет не производить промежуточных запросов и тем самым снизить нагрузку на СУБД.

Глава 3. ПРОЕКТИРОВАНИЕ

3.1 Проектирование базы данных

Проектирование структуры БД является одной из основных и очень трудозатратных задач при разработке ПО, работающего с данными.

Для работы с базой данных Django использует собственный ORM, в котором модель данных описывается классами Python, называемыми моделями, и по ней генерируется схема базы данных. ORM позволяет работать с базой данных, без непосредственного использования SQL. [14]

А с помощью миграций происходит преобразование базы данных в соответствии с моделями.

Было создано 14 моделей:

UserInfo – для отображения дополнительной информации о пользователе (телефон, примечание);

Access – для отображения списка уровней доступа; AccessHistory – для отображения истории доступа; SignIn – для хранения ключей доступа;

UserBan – для блокировки пользователей по логину; IPBan – для блокировки пользователей по ip-адресу; SessionBan – для блокировки пользователей по сессии;

Action – для отображения списка действий над категориями и карточками документов;

Categories – для отображения списка категорий; CategoriesHistory – для отображения истории категорий;

CategoriesUserGroups – для отображения связывания категорий и групп пользователей;

DocumentCards – для отображения списка карточек документов; DocumentsHistory – для отображения истории карточек документов; Posts – для отображения сообщений.

Каждая модель представлена классом, унаследованным от django.db.models.Model. Каждая модель содержит несколько атрибутов, каждый из которых отображает поле в таблице базы данных.

Каждое поле представлено экземпляром класса Field, например, CharField для текстовых полей и DateTimeField для полей даты и времени. Это указывает Django какие типы данных хранят эти поля.

Через класс Meta определяются дополнительные настройки для модели. Например, название таблицы в базе данных для этой модели (db_table), читабельное название модели (verbose_name), права доступа для этой модели (permissions).

Модель также может иметь методы. Минимально в каждой модели определяется стандартный метод класса для Python str (), чтобы вернуть удобочитаемую строку для каждого объекта. Эта строка используется для представления отдельных записей на сайте администрирования. Часто это возвращает поле названия или имени из модели.

Для примера, модель DocumentCards выглядит следующим образом:

def directory_path(instance, filename):

category = Categories.objects.get(category_id=instance.category_id) parent_id = category.parent_id

while parent_id is not None:

category = Categories.objects.get(category_id=parent_id) parent_id = category.parent_id

return '{0}/{1}'.format(category.name, filename)

class DocumentCards(models.Model):

document_card_id = models.BigAutoField(primary_key=True, verbose_name='Id') name = models.TextField()

comment = models.TextField(blank=True, null=True) file = models.FileField(upload_to=directory_path)

category = models.ForeignKey(Categories, models.DO_NOTHING, related_name='docs') user = models.ForeignKey(User, models.DO_NOTHING)

delete = models.BooleanField("Статус удаления", default=False)

class Meta: managed = False

db_table = 'document_cards' verbose_name = 'Карта документов'

verbose_name_plural = "Карты документов"

default_permissions = () permissions = (

("view_document_card", "Просмотр карт документов"), ("add_document", "Добавление карт документов"), ("change_own_document", "Редактирование своих карт документов"), ("change_all_document", "Редактирование всех карт документов"), ("download_own_document", "Скачивание своих документов"), ("download_all_document", "Скачивание всех документов"), ("delete_document", "Удаление своих карт документов"),

def str (self): return self.name

Модель содержит два текстовых поля, это название и комментарий для карточки документа, так же используется поле document_card_id для задания первичного ключа. Поля category и user являютсе внешними ключами на таблицы Categories и User, для отображения категории, в которой создана данная карточка, а также пользователя, который ее создал. Поле delete используется для пометки удалена ли карточка. Поле file используется для загрузки файла.

Атрибут upload_to позволяет указать каталог и название файла при его сохранении. В данном случае используется функция directory_path, которая будет вызвана для получения пути к загруженному файлу, включая имя файла. Вызываемый объект должен принимать два обязательных аргумента, и возвращать путь в стиле Unix (с прямыми слэшами), который будет передан в систему хранения файлов. Два аргумента это instance – объект, для которого сохраняется текущий файл, и filename – оригинальное имя файла.

После создания моделей используются миграции и для сохранения изменений моделей (и структуры базы данных) – это просто файлы на диске.

В приложении Б приведена полученная схема базы данных. Таблицы auth_user, auth_group, auth_user_groups, auth_group_permissions, auth_permission, auth_user_user_permissions, django_content_type, django_admin_log, admin_tools_menu_bookmark и admin_tools_dashboard_preferences созданы автоматически Django и отвечают за аутентификацию пользователей и за работу панели администратора.

3.2 Проектирование архитектуры системы

Один из основных принципов фреймворка Django – DRY (don't repeat yourself). Веб-системы на Django строятся из одного или нескольких приложений, которые рекомендуется делать отчуждаемыми и подключаемыми. Это одно из заметных архитектурных отличий этого фреймворка от некоторых других. Также, в отличие от многих других фреймворков, обработчики URL в Django конфигурируются явно (при помощи регулярных выражений), а не автоматически задаются из структуры контроллеров.

Архитектура Django похожа на «Модель-Представление-Контроллер» (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Представление (View), а презентационная логика Представления реализуется в Django уровнем Шаблонов (Templates). Из-за этого уровневую архитектуру Django часто называют «Модель-Шаблон-Представление» (MTV).

Рисунок 3.2.1 – Взаимодействие MTV

Первоначально разработка Django велась для обеспечения более удобной работы с новостными ресурсами, что достаточно сильно отразилось на архитектуре: фреймворк предоставляет ряд средств, которые помогают в быстрой разработке веб-сайтов информационного характера. Например, разработчику не требуется создавать контроллеры и страницы для административной части сайта, в Django есть встроенное приложение для управления содержимым, которое можно включить в любой сайт, сделанный на Django, и которое может управлять сразу несколькими сайтами на одном сервере. [16]