И. А. Кудрявцев аучный (стр. 5 из 9)
При проектировании схемы базы данных был использован инструмент Rational Rose. Это популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа данного продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.
Данный программный продукт изначально создается для обработки и хранения данных. Поэтому актуальность создания общего хранилища данных вполне очевидна. Для этих целей используется СУБД MySQL, как наиболее распространенная при работе с фреймворком Django, и более простая, чем Postgres, которая больше нацелена на сложную серверную логику.
Для разработки дизайна системы был использован продукт Axure RP Pro 4, который позволяет создавать полноценный прототип системы. Этот прототип позволяет видеть не только непосредственно дизайн страниц, но и отслеживать динамику, все переходы между ними. Он позволяет видеть, как ведет себя система в зависимости от действий пользователя.
При разработке любого программного продукта большое значение имеет выбор фреймворка, с использованием которого будет разрабатываться система. В данном случае предпочтение было отдано фреймворку Django, как одному из самых удобных для создания подобных приложений. Django (Джанго) — это свободный программный каркас для создания веб-приложений, написанный на языке Python. Он обладает многими свойствами и принципами, которые помогают в быстрой разработке веб-приложений, особенно информационного характера. Этот фреймворк делает максимум усилий для того, чтобы из описанной один раз информации достать максимум возможного сервиса. Хотя им можно и не пользоваться (что тоже иногда важно).
Перечислим некоторые из основных его принципов:
· В Django модель данных разрабатываемого приложения описывается в Python классами, и по ней генерируется схема базы данных. А раз схема определяется в языке и от БД не зависит, это значит, что можно легко перейти на другую БД (например, если программист использовал для разработки Postgres, а у пользователя оказался только MySQL).
Пример описания класса модели представлен на рисунке 3.1.1.
Рис.3.1.1.
· Идеология MVC в Django реализована не совсем в классическом варианте. Например, то, что обычно называется Controller, там вырождено в файл соответствия URL’ов обрабатывающим функциям, которые лежат в уровне View. Поэтому часто говорят, что Django просто переназвали Controller во View, а View — в шаблоны.
Пример простой обрабатывающей функции из View представлен на рис. 3.1.2.
Рис.3.1.2.
· Разделение фреймворка на максимально независимые компоненты: так называемая “слабая связанность”. Шаблоны, обработчики и модель почти не завязаны друг на друга. Модель ничего не знает о такой вещи, как HTTP-запрос, а из шаблона нельзя даже случайно изменить данные.
· Отказ от завязывания шаблонов на язык программирования. Когда шаблон представляет собой смесь HTML’а и кода серверного языка, то очень быстро это приводит к тому, что в шаблон проникает довольно много логики, которая должна быть на уровне приложения. Это в свою очередь ведет к тому, что все это сложно поддерживать. В Django язык шаблона вообще не связан с Питоном, а шаблонная логика намеренно очень ограничена. Например, в операторе {% if %} можно проверить только логическую истинность объекта, а произвольное условие типа “равна ли длина списка десяти” — не допускается. Еще одно свойство шаблонной системы — безопасность. Можно обращаться не к любым методам, а только к тем, которые не меняют сами объекты. Поэтому шаблон спокойно можно отдать на редактирование кому-то другому, зная, что он ничего не сломает.
Пример шаблона представлен на рисунке 3.1.3.
Рис.3.1.3.
· URL’ы. В приложении есть файл, в котором просто пишется список всех видов URL’ов, которые привязываются к своим обрабатывающим функциям. Причем изменяемые части URL’ов передаются в обработчики в виде обычных параметров функций, а значит, их не надо доставать из какой-нибудь коллекции.
Пример такого файла приведен на рис. 3.1.4.
Рис. 3.1.4.
Центральная же идея Django — быстрая разработка с маленьким количеством кода. Все нацелено на то, чтобы большую часть времени программист занимался не настройкой фреймворка, а написанием кода своего приложения. Например, если рассмотреть административную часть веб-приложения, то можно увидеть, что в Django для этого писать код вообще не надо. Нужно только указать, какие объекты хотелось бы видеть в административном интерфейсе и все, Django автоматически сформирует интерфейс, который очень удобно использовать.
А теперь кратко опишем общую структуру проекта, созданного с помощью этого фреймворка. Проект – это коллекция конфигурационных файлов и приложений, каждое из которых содержит непосредственную реализацию логики создаваемого продукта. При создании нового проекта автоматически создаются 4 файла:
- __init__.py
- manage.py – утилита для взаимодействия с Django
- setting.py - файл с настройками проекта
- urls.py - файл URL’ов, о котором упоминалось выше
Приложение создается отдельно, и сразу после создания в его каталоге появляются файлы:
- __init__.py
- models.py – файл с описанием модели данных
- views.py – файл с обрабатывающими URL функциями
Все остальные необходимые модули, классы разработчик помещает внутрь своих приложений.
На рисунке 3.1.5. показана схема обработки запроса страницы, который делает пользователь.
- Прежде всего Django ищет переменную ROOT_URLCONF в файле настроек settings.py, которая содержит в себе полный путь к файлу с URL’ами.
- Затем Django загружает соответствующий модуль, находит там переменную urlpatterns, которая представляет собой список шаблонов. Пробегаясь по нему по порядку, останавливается на первом шаблоне, который совпадает с запрошенным URL.
- После этого Django импортирует и вызывает обрабатывающую функцию из view.py, которая соответствует найденному шаблону. Она получает объект REQUEST, достает из него все необходимые аргументы и каким-то образом их обрабатывает или передает управление другим функциям. (На диаграмме изображено обращение к брокеру Django, которые получает из базы необходимые данные). После своей работы она возвращает объект RESPONSE.
Рис.3.1.5.
Стоит также упомянуть еще об одном важном преимуществе Django – об его встроенном брокере для работы с базой данных. Он позволяет не писать sql-запросы в чистом виде, а пользоваться классами модели и их методами для создания, обновления, удаления и выборки нужных данных. Брокер позволяет делать выборки с различной фильтрацией и сортировкой и является очень полезным и удобным средством при разработке, ускоряя ее. Однако он не лишен недостатков: он не слишком мощный, и сложные запросы все-таки приходится писать вручную, а также он не позволяет работать с хранимыми процедурами.
Аутентификация и последующая авторизация пользователей происходит на основе ролей, которые они играют в системе, и в зависимости от этого им либо разрешено, либо запрещено выполнять определенные действия. Учитывая выбранную нами методологию разработки, можно выделить 4 основные роли:
- Разработчик
- Scrum мастер
- Владелец продукта
- Администратор системы
Однако было бы неправильно и скупо останавливаться только на этом наборе. Существует несколько моментов, которые стоило бы хорошенько обдумать.
Во-первых, функции Scrum мастера и владельца продукта достаточно нечеткие в технической части, и в разных компаниях, даже в разных проектах в одной компании, они могут распределяться по-разному. Где-то эти две роли будут уравнены в своих правах, а где-то вполне вероятно, что полномочия Scrum мастера в системе должны в точности совпадать с полномочиями разработчика. Плюс ко всему достаточно важную роль играет политика компании в части открытости. Иногда все люди могут свободно наблюдать за тем, как идут дела по всем проектам, чтобы оценивать продуктивность других команд, быть в курсе их успехов или неудач, но в других случаях им позволительно знать только о своих задачах, и ни о чем больше.