Разработка программного продукта для составления расписания репетитора

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

В настоящее время достаточно большой процент школьников пользуется услугами репетиторов, по данным Мониторинга экономики образования НИУ ВШЭ - около 25%. Большинство учеников хотят улучшить свои шансы на успешную сдачу ЕГЭ и ОГЭ, другие - подтянуть знания текущего материала в школе или подготовиться к поступлению в вузы.

Каждый репетитор сам определяет, сколько занятий в неделю он готов проводить, в зависимости от нагрузки, желания и т.д. В обсуждениях на сайтах репетиторов и различных форумах мнения о том, какая нагрузка оптимальна, могут сильно отличаться: для кого-то иметь в расписании одновременно 10 учеников - уже много, а кто-то считает, что 27 учеников - «в самый раз».

Большинство репетиторов проводят индивидуальные занятия в свободное от работы или учебы время. К тому же, большая часть учеников в первой половине дня занята в школе, и на дополнительные занятия у них остается дневное или вечернее время.

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

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

Для достижения цели были сформулированы следующие задачи:

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

· спроектировать архитектуру приложения, схему базы данных и выбрать подходящие инструменты;

· разработать отдельные уровни приложения (работа с базой данных, бизнес-логика, интерфейс пользователя) и реализовать их взаимодействие друг с другом;

· протестировать программный продукт и разработать документацию.

1. ПОСТАНОВКА ЗАДАЧИ

Создание программного продукта для составления расписания репетитора. Основные части приложения: визуальное представление событий и занятий в календаре, работа с журналом успеваемости, отображение дерева тем занятий, списка учеников, с возможностью добавления, редактирования и удаления информации.

1.1 Анализ существующих решений

Приложение «Расписание для репетитора» можно отнести к приложениям-органайзерам, другими словами - планировщикам задач или ежедневникам. Органайзеры имеют непосредственное отношение к тайм-менеджменту и призваны облегчить задачу управления своим временем, помочь составить план своей деятельности.

Среди органайзеров в целом можно отметить и обычные блокноты или ежедневники, но в рамках данного проекта имеет смысл рассмотреть только электронные варианты.

Если говорить об органайзерах, начиная с появления персональной техники, то первыми устройствами-планировщиками стали персональные «карманные» органайзеры. Они имели, например, собственную клавиатуру и монохромный дисплей, 512 кБ памяти и выполняли свои основные функции. Некоторые устройства могли подключаться к принтеру или модему, или персональному компьютеру. Также известны органайзеры, совмещенные с наручными часами.

С развитием персональных компьютеров стали также появляться отдельные программы, выполняющие функции органайзеров. Помимо этого, были разработаны органайзеры, работающие через web или облачные хранилища [1].

В настоящее время существует множество онлайн-органайзеров (программы-планировщики в сети Интернет) под самые разные задачи [2]. Преимущества перед другими органайзерами довольно очевидны: возможен доступ к своему расписанию с различных устройств, нет необходимости носить с собой специальные устройства вроде «карманных органайзеров».

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

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

2. Наличие определенных функциональных возможностей. К ним можно отнести:

· визуальное отображение списка задач, в виде календаря или иным образом;

· возможность добавления участников события/задачи и их информации;

· возможность создания периодически повторяющихся задач;

· другое, исходя из сравнения органайзеров друг с другом.

3. Связь с другими ресурсами или приложениями.

4. Возможность использования для задач репетитора и составления расписания занятий.

Рассмотрим следующие онлайн-органайзеры.

1. TimeMaster.

Проект стартовал в 2011 году и продолжает развиваться.

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

В качестве достоинств сервиса разработчики выделяют следующее:

· календарь;

· возможность разбивать задачи на подзадачи;

· организация контактов;

· напоминания о событиях по e-mail и sms;

· учет потраченного времени;

· безопасность хранения данных, шифрование;

· методики тайм-менеджмента;

· техподдержка.

В приложении существует возможность добавления задач (событий) прямо в календарь или в дерево задач. События выделяются разным цветом, в зависимости от приоритета (всего три возможных приоритета). Есть возможность добавления периодических задач, с одним из следующих параметров: повторять событие определенное количество раз, либо повторять до определенной даты; для обоих вариантов можно выбрать период.

В параметры задачи входят: название, время начала, конец («дедлайн»), дата, последовательное/параллельное выполнение подзадач, учет времени, затраченного на задачу. К задаче также можно добавить заметку, выбрать контекст (учеба, работа и т.п.), контакты, напоминания и файлы.

При просмотре событий в календаре из всей информации есть только название события и отметка о выполнении. При добавлении «галочки»-отметки о выполнении событие пропадает из календаря. Для периодических задач такую отметку поставить нельзя.

Получить дополнительную информацию о событии можно в отдельном окне. Календарь выводится на определенное количество дней (выбирается пользователем), либо на неделю или месяц; также можно выбрать время начала и окончания рабочего дня.

В приложении также имеется дневник, в который предлагается записывать действия, которые пользователь проделал в выбранный промежуток времени.

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

Для работы приложения требуется любой из современных браузеров. Также возможен импорт задач из приложений Microsoft Outlook, Google Calendar, Яндекс.Календарь или из текстового файла. Для последнего существует особая инструкция.

С точки зрения удобства приложения для репетитора, можно отметить:

Плюсы:

· неплохая визуализация задач на выбранном диапазоне времени;

· возможность добавления периодически повторяющихся событий;

· связь события с контактами;

· возможность фильтрации задач в зависимости от контекста или контактов;

· возможность добавления заметок по событию.

Минусы:

· из всей информации о событии в календаре отображается только название;

· выбор цвета события в календаре только из трех вариантов, связанных с приоритетом;

· при отметке «выполнено» событие сразу пропадает из календаря;

· нет возможности группировать контакты;

· много «лишнего» функционала.

2. Миниплан.

Миниплан - бесплатный онлайн-органайзер для личного использования. Регистрация занимает заявленные разработчиками 10 секунд.

В приложении есть возможность добавлять события сразу в календарь, на специальные часы на отдельной странице или в список нераспределенных дел. События включают: название, время выполнения (начало и конец события), отметку о повторении события (каждый день, неделю, месяц или год), категорию (работа, встречи и т.п.), напоминания.

События, добавленные разными способами, не синхронизируются друг с другом. Другими словами, при добавлении события в календарь, оно не отображается на часах и наоборот.

Категории событий можно добавлять в настройках. В календаре разные категории отображаются разными цветами, которые также можно изменить в настройках. Также в календаре можно передвигать уже созданные задачи. При этом для повторяющихся событий изменения затронут только одно из них. Список дел можно увидеть за один день или одну неделю. Посмотреть все события за месяц или выбранный промежуток дней не удастся.

Часы, на которых можно отмечать события в течение дня, также имеют свои ограничения: с 9.00 до 20.45. Добавить события в другое время невозможно. На странице с часами можно добавлять заметки, рисовать, перетаскивать дела из нераспределенного списка на часы (для автоматического добавления), а также посмотреть короткий обучающий ролик.

Напоминания о событиях можно получать на электронную почту, по SMS или в Джаббер.

Имеется встроенная функция «поделиться приложением» со ссылками на популярные (и не очень) социальные сети. Можно синхронизировать дела с Google календарем или iCal.

Подведем итог:

Плюсы:

· возможность быстро разобраться в приложении, удобный интерфейс, быстрая регистрация;

· добавление повторяющихся событий и изменение времени одного из них, не затрагивая другие;

· хорошее визуальное отображение на специальных часах;

· выделение задач разным цветом с возможностью выбора цвета;

· список нераспределенных дел, которые можно назначить на определенное время уже после формирования списка;

· в календаре есть отметка с текущим временем.

Минусы:

· нет синхронизации между календарем и часами;

· нет групп событий для списка;

· нет возможности посмотреть все задачи на месяц;

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

· очевидные недоработки, например, обучающий ролик нельзя посмотреть на сайте (возникает ошибка), требуется переходить на сторонний ресурс и т.п.

3. Google Календарь.

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

События добавляются прямо в календарь, с возможностью редактирования в отдельном окне. Сами события включают множество характеристик: название, описание, время (включая часовой пояс), место проведения, повторяемость, гости, уровень доступа при просмотре другими участниками, цвет события в календаре, видеовстречи и др.

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

Задачи в календаре можно видеть за день, неделю, месяц или 4 дня. Также все события дублируются в «расписании», которое представляет список всех дел на ближайший месяц.

Помимо этого, можно создать несколько календарей. Например, с начала работы уже есть отдельный календарь для дней рождения - для этого случая есть особое описание событий: рассчитанные на весь день. Таким образом, можно разделить события на несколько календарей и просматривать их в отдельности.

В целом, Google Календарь подходит для планирования практически любых дел, доступен на любом устройстве с доступом в Интернет. Обилие функциональных возможностей может вызвать небольшие трудности в начале использования, но освоение главных функций (добавление и редактирование событий) не займет много времени.

4. Яндекс.Календарь.

Своеобразный аналог Google Календаря от российских разработчиков. Функционально очень похожи, сложно найти отличия (помимо визуальных особенностей). Тем не менее, можно обратить внимание, что в Яндекс.Календаре:

· нет возможности добавлять события, «растягивая» их на календаре, из-за чего требуется вручную указать время окончания события;

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

· удобное выделение цветом в отображении задач на месяц;

· так же, как и календарь от Google, позволяет: добавить участников события, напоминание, место проведения, запланировать событие на весь день, определить права участников события.

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

1.2 Разработка функциональных требований

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

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

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

· название;

· время начала и окончания;

· опции повторения события;

· временная отмена одного занятия, не влияющая на повторение этого события в будущем,

· информация об ученике или группе учеников;

· дисциплина, по которой проводится занятие;

· место проведения;

· информация о транспорте, если это занятие вне дома;

· стоимость занятия.

Также событие может включать дополнительные характеристики:

· более подробное описание одного события или всей серии повторяющихся событий;

· тема занятия;

· домашнее задание ученика;

· отметка за занятие и/или домашнее задание.

Помимо этого, необходимо предусмотреть возможность вносить в расписание задачи, не связанные напрямую с занятиями. Такие задачи могут иметь описание, время начала и окончания, место и информацию о повторении.

Часть информации о событии включает данные учеников, которые можно вынести отдельно. В связи с этим, требуется создание и редактирование карточек учеников, где будет содержаться их личная информация.

Также необходимо создать журнал успеваемости учеников и списки тем для изучения, которые формируются репетитором. Журнал успеваемости может включать ссылки на темы из списков, отметки о полном или частичном прохождении темы, домашние задания, дополнительную информацию о проведенном занятии.

Каждый из элементов приложения необходимо отображать на отдельной странице или в отдельном окне. К таким элементам можно отнести: календарь-расписание на неделю, месяц или один день, карточка ученика, подробная информация о событии из календаря, журнал успеваемости, подробная информация о записи в журнале, списки тем по дисциплине в целом или отдельному ученику. Элементы должны содержать ссылки друг на друга для быстрой навигации по разделам.

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

Помимо этого, необходимо реализовать регистрацию пользователей в приложении и сохранение нескольких расписаний для одного пользователя.

Все данные, которые необходимо хранить и отображать, можно выделить в несколько сущностей, логически связанных друг с другом:

1. Событие. Событие происходит в определенную дату, может иметь время начала и окончания, должно содержать в себе описание, наименование. Также события могу быть повторяющимися: каждый день, каждую неделю и т.д. Событие может быть занятием, но это необязательно, поэтому все параметры, необходимые для описания занятия стоит выделить в отдельную сущность.

2. Занятие. К описанию занятия можно отнести: дисциплина, по которой проводится занятие, студент, стоимость занятия.

3. Студент. В описании студента понадобится его имя, фамилия, адрес и контакты.

4. Контакт. Все контакты студентов в виде: телефон - номер телефона.

5. Тема занятия. Для одной дисциплины предполагается наличие некоторого числа тем занятий, которые можно выстроить в виде дерева каталогов. В каждой теме занятия необходимо название и, возможно, комментарий.

6. Запись журнала. В журнал заносится дополнительная информация к занятию: домашнее задание, тема занятия, оценка ученика.

база данные тестирование интерфейс



2. ПРОЕКТИРОВАНИЕ

В последнее время с развитием Интернета большую популярность получили веб приложения. Они представляют собой клиент-серверное приложение, в котором в качестве сервера выступает веб_сервер, а клиент взаимодействует с ним через браузер. Такие приложения обладают определенными преимуществами: пользователю не требуется установка специальных программ на свой компьютер (кроме браузера), приложения поддерживаются различными операционными системами без дополнительных настроек, данные хранятся на сервере и достаточно надежно защищены. Современный уровень развития веб_технологий позволяет создавать не просто статичные страницы, а динамически наполнять их данными, даже создавать игры в окне браузера.

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

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

2.1 Разработка архитектуры приложения

Архитектура программного продукта представляет собой совокупность важнейших решений об устройстве программной системы. Для разработки архитектуры необходимо:

· выбрать подходящий архитектурный стиль, определяющий общую организацию элементов и их взаимосвязи друг с другом;

· описать основные логические составляющие системы - сущности, интерфейсы и их поведение;

· декомпозировать основные сущности и интерфейсы для создания отдельных классов и вынесения общей логики;

· учесть возможность дальнейшего расширения системы.

В качестве основного архитектурного стиля программного продукта была выбрана трехуровневая архитектура.

В такой системе первый уровень представляет собой приложение для конечного пользователя, которое может содержать базовую логику для отображения данных в веб_интерфейсе, не имеет прямого доступа к базе данных. На втором уровне располагается сервер приложений (или веб_сервер), где сосредоточена вся основная часть бизнес_логики. Третий уровень занимает сервер базы данных, который обеспечивает хранение данных.

У данного архитектурного решения есть ряд преимуществ:

· приложение не требует поддержки на стороне клиента;

· хорошая масштабируемость системы;

· высокая безопасность и надежность;

· возможность вносить изменения в одну из частей приложения, не затрагивая остальные.

Помимо этого, было принято решение разделить приложение на две логические составляющие: серверная часть приложения, которая взаимодействует с базой данных (бэкенд), - и клиентская часть, отвечающая за представление пользовательского интерфейса (фронтенд), которая также может быть запущена на веб_сервере. Взаимодействие между бэкендом и фронтендом удобно осуществлять в соответствии с принципами архитектуры REST. Такой подход позволит в дальнейшем (при желании) полностью изменить одну из частей, не меняя другой, или реализовать несколько вариантов представления данных при обращении к одной и той же серверной части.

REST (Representational state transfer) - это популярное в настоящий момент архитектурное решение для взаимодействия клиентских и серверных приложений [5]. REST не является протоколом и не имеет определенного стандарта. Тем не менее, для реализации REST архитектуры существуют определенные соглашения, которые поддерживаются библиотеками и фреймворками, упрощающими создание RESTful приложений.

В основе такой архитектуры заложены следующие принципы:

1. Модель взаимодействия «клиент-сервер». Хорошей практикой считается отделение данных от логики их представления: такой подход позволяет создать различные представления для одних и тех же данных через создание самых разных клиентских приложений.

2. Отсутствие состояние (stateless). Серверная часть приложения не хранит состояние клиентской части. Запросы к «серверу» отправляются тогда, когда «клиент» готов изменить свое состояние. Результаты запросов «клиента» не хранятся на стороне «сервера».

3. Кэширование. Клиентская часть приложения может хранить ответы сервера в течение некоторого времени.

4. Многослойная архитектура. «Клиент», как правило, не может знать, подключается ли он напрямую к «серверу» или к промежуточному узлу, что позволяет распределить нагрузку на несколько серверов, повышает масштабируемость системы.

5. Код по требованию (необязательное ограничение). Код может быть передан клиентской части приложения в виде апплетов или сценариев. На практике такой подход используется очень редко.

6. Единообразие интерфейса. Основное требование к дизайну REST_сервисов. Подразумевается, что каждый блок данных, отдаваемых в ответ на REST запрос, может быть получен по определенному идентификатору, уникальному в пределах приложения. Для передачи данных используются форматы, отличные от тех, в которых данные хранятся на «сервере» (например, JSON или XML). Для взаимодействия используются HTTP запросы. В ответе «сервера» также могут содержаться идентификаторы для других действий с теми же данными.

REST архитектура за счет приведенных принципов представляет собой удобный вариант описания взаимодействия различных модулей приложения (в нашем случае - серверной и клиентской частей).

2.2 Выбор инструментальных средств

При разработке приложения очень важно использовать систему контроля версий (СКВ). Такая система позволяет хранить различные версии продукта на разных стадиях разработки в локальном и удаленном репозиториях, видеть все изменения в коде (и когда они были сделаны), сравнивать несколько вариантов реализации одного и того же функционала. Стоит отметить, что в случае работы над проектом нескольких разработчиков, системы контроля версий незаменимы, и этот подход практически всегда применяется в разработке коммерческих приложений. В качестве системы контроля версий использовался Git.

В сравнении с другими системами контроля версий, Git обладает высокой производительностью, может обеспечить интеграцию с другими СКВ, изначально ориентирован на работу с изменениями, а не с файлами. В Git есть подробная документация, к которой можно обратиться напрямую из консоли. Многие среды разработки позволяют работать с Git из собственного интерфейса, но внутри используют те же консольные команды.

Основным языком разработки серверной части приложения был выбран Java. Java - объектно-ориентированный язык программирования, один из самых популярных на данный момент. В качестве преимуществ языка Java можно отметить независимость от операционной системы, отсутствие необходимости отслеживать выделение и освобождение памяти, отсутствие указателей и множественного наследования (которые могут привести к ряду неприятных ошибок при неправильном использовании).

Выбор среды разработки для Java, как правило, слабо связан с возможностями самой среды разработки: в сети Интернет можно встретить много споров, касательно того, какая из них лучше, и много сторонников самых разных вариантов, включая любителей вести разработку на бумаге. Тем не менее, можно предположить, что хорошая и удобная среда ускоряет разработку приложения, позволяет избежать элементарных ошибок, вроде опечаток, за счет подсветки синтаксиса. Также немаловажно, чтобы среда предоставляла возможности рефакторинга и отладки приложения. Была выбрана одна из таких сред разработки - IntelliJ IDEA. Среда предоставляется компанией JetBrains в двух версиях: Community (бесплатно для всех) и Ultimate (для обладателей лицензионного ключа). Тем не менее, возможности «продвинутой» среды разработки можно опробовать в пробной (trial) версии, в тестовом режиме (программа «раннего» доступа), по студенческой лицензии или, например, получив временный ключ за решение задач на образовательной платформе Stepik.ru. В расширенной версии, в частности, можно тестировать REST-запросы непосредственно из среды разработки.

Помимо возможностей IntelliJ IDEA, для тестирования REST-приложения хорошо подходит Postman. Есть версии в виде расширения Google Chrome или отдельного приложения. Удобство в тестировании заключается в возможности сохранения сделанных запросов, редактировании тела запроса, заголовков, выборе формата передачи данных (например, JSON или XML). Инструмент хорошо подходит для того, чтобы увидеть, в каком виде фронтенд получает сообщения от бэкенда, и при необходимости скорректировать ответ серверной части.

В части использования фреймворков в разработке особое внимание стоит обратить на Spring. Фреймворк обладает колоссальными возможностями, в частности, помогает избавиться от шаблонного кода для работы с базой данных и создания REST, упрощает использование приемов внедрения зависимостей. Spring Boot (фактически - плагин для системы автоматизации сборки) еще больше упрощает разработку, потому что минимизирует настройки Spring, поддерживает встроенный контейнер, что позволяет избежать разворачивания приложения на веб_сервер при каждом запуске. Также в Spring Boot можно обойтись без задания конфигураций через XML файлы, а используя аннотации «в Java-стиле». Это отличное решение для старта разработки с использованием Spring при отсутствии необходимости погружения целиком в настройки фреймворка.

В случае использования сторонних библиотек или фреймворков для разработки на языке Java сложно обойтись без автоматизации сборки проекта. Сборка проекта может включать в себя компиляцию, компоновку, запуск тестов, развертывание («деплой») на сервер. В настоящее время чаще всего для сборки проекта используется Maven - фреймворк для автоматизации сборки, компиляции, создания jar, создания дистрибутива программы, документации. Из положительных моментов использования Maven можно отметить следующие:

· можно использовать в любой операционной системе;

· возможность решения конфликтов в подключенных библиотеках (зависимостях);

· управление из командной строки или из среды разработки;

· декларативное описание продукта.

Для разработки клиентской части было принято решение использовать наиболее базовые технологии - HTML, CSS, JavaScript. Помимо этого, для улучшения визуального отображения элементов на странице использовался Bootstrap, а для обращения к REST серверному приложению через Ajax запросы - JQuery. Последний также позволяет несколько упростить JavaScript код и имеет огромное количество библиотек с готовыми решениями в сети Интернет.

IntelliJ IDEA имеет ограниченный функционал в части работы с интернет-технологиями, поэтому для фронтенд-разработки использовался WebStorm - еще один продукт компании JetBrains. Данная среда разработки обеспечивает подсветку синтаксиса, автодополнение кода и предоставляет много возможностей для рефакторинга при работе с HTML, CSS, JavaScript, Jquery и др. Также есть возможность работать с системами контроля версий через интерфейс, иметь доступ к командной строке непосредственно из среды разработки.

Для проверки визуального отображения интерфейса программного продукта в основном использовался браузер Google Chrome. Тем не менее, среда разработки WebStorm позволяет быстро перейти к просмотру приложения через любой из пяти самых часто используемых браузеров.

В качестве системы управления базами данных была выбрана MySQL - реляционная СУБД с открытым исходным кодом, достаточно простая в освоении и использовании. Для относительно небольшого некоммерческого проекта возможностей MySQL вполне достаточно. MySQL Workbench, который входит в состав дистрибутива, позволяет проектировать модель базы данных с помощью схем, хранить сделанные ранее SQL-запросы к базе данных, осуществлять обратную разработку (reverse engineering), например, в случае создания базы данных средствами фреймворка Hibernate, для проверки корректности полученной схемы и соответствия ее классам-сущностям, описанным на Java.

2.3 Проектирование схемы базы данных

База данных (БД) позволяет сохранять и получать большие объемы данных, связанных друг с другом [3]. В реляционной БД данные хранятся в виде таблиц, каждая из которых, как правило, описывает одну сущность. Для проектирования базы данных, в первую очередь, создается модель, на основании которой в дальнейшем пишутся SQL скрипты. MySQL Workbench позволяет создавать модель базы данных в виде схемы таблиц и связей между ними - диаграммы «сущность-связь» (рис. 1).



Рисунок 1 - Диаграмма "сущность-связь" проекта

При проектировании БД также следует придерживаться определенных правил, чтобы в дальнейшем избежать дублирования данных. В частности, в каждой таблице должен присутствовать первичный ключ (ПК) для однозначной идентификации строки таблицы и связи таблиц друг с другом. Также стоит избегать дублирования данных, например, с помощью декомпозиции.

Для каждого атрибута необходимо задать тип данных и размер - длину строки или количество цифр. Типы данных (в соответствии с MySQL), используемые в проектировании:

1. BIGINT. Целые числа большой разрядности. Подходит для уникального идентификатора.

2. VARCHAR. Строка изменяющейся длины от 1 до 255 символов. Лишние пробелы в начале и конце обрезаются при сохранении. Сравнение и сортировка - независимо от регистра.

3. DATE. Дата. Отображается в виде YYYY-MM-DD.

4. TIME. Время. Отображается в виде HH:MM:SS.

5. ENUM. Перечисление. Строковое значение из ограниченного списка.

6. DECIMAL. Число с плавающей запятой. Хранится в виде строки, по одному символу для каждой цифры.

В соответствии с описанными сущностями в главе 1 определим следующий набор основных таблиц.

Для сущности «Событие» необходимо задать уникальный идентификатор (ID), даты начала и окончания (необходимо для повторяющихся событий), время начала и окончания, код повторяемости, название и комментарий (табл. 1).

Таблица 1 - Атрибуты таблицы EVENT

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
NAME	VARCHAR	255	+
COMMENT	VARCHAR	255	-
DATE_START	DATE	YYYY-MM-DD	+
DATE_END	DATE	YYYY-MM-DD	-
TIME_START	TIME	HH:MM:SS	-
TIME_END	TIME	HH:MM:SS	-
CODE	ENUM	DAILY, WEEKLY, MONTHLY, YERLY, NEVER	+
ID_TUTOR	BIGINT	20	+

Уникальный идентификатор всегда является обязательным полем для заполнения, является первичным ключом и заполняется автоматически при добавлении новой записи в таблицу (инкрементируется). Поле NAME также является обязательным, т.к. необходимо для идентификации события в интерфейсе пользователя. Код повторяемости события включает значение NEVER для не повторяющихся событий, поэтому также обязателен для заполнения, при этом дата начала события будет являться датой самого этого события, а не серии событий.

При этом следует понимать, что дата начала и окончания не характеризует одно длительное событие, а относится к серии повторяющихся событий. Например, событие «зарядка по утрам» может быть ежедневным на протяжении месяца, но не будет занимать весь месяц в календаре. С другой стороны, у события может не быть конкретной даты окончания, и пользователь должен иметь возможность добавить событие такого типа, поэтому поле DATE_END не обязательно для заполнения.

Также событие может относиться к целому дню, например, День рождения. Таким образом, время начала и окончания события может быть не указано.

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

Уникальных полей в данной таблице не предусматривается. Также в таблицу могут быть добавлены поля, необходимые для связи с другими сущностями.

Сущность «Студент» включает в себя информацию об имени, фамилии и адресе учащегося (табл. 2).

Таблица 2 - Атрибуты таблицы STUDENT

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
FIRST_NAME	VARCHAR	45	+
LAST_NAME	VARCHAR	45	-
ADDRESS	VARCHAR	255	-
ID_TUTOR	BIGINT	20	+

Предполагается, что размер имени и фамилии не может превышать 45 символов. Также фамилия и адрес являются не обязательными полями для заполнения.

Сущность «Контакт» была разделена на две таблицы, в связи с тем, что наименование контакта может повторяться. Например, у нескольких учеников будет контакт «мобильный телефон», при этом для каждого ученика он будет свой. Таким образом, названия контактов можно вынести в отдельную таблицу-справочник CONTACT_NAME, состоящую всего из двух атрибутов: ID и NAME. Идентификатор имеет тот же тип данных BIGINT(20), NAME является строкой и может состоять из 100 символов - VARCHAR(100). Также важно, чтобы названия контактов не дублировались в таблице, поэтому необходимо добавить ограничение уникальности (unique constraint) для поля NAME. Таким образом, при попытке добавить в таблицу дублирующую запись, база данных выдаст ошибку.

В таблице CONTACT (табл.3) хранится значение контакта - непосредственно номер телефона, адрес электронной почты, тогда как в таблице CONTACT_NAME - строки «мобильный телефон», «e_mail» и т.п. Все поля обязательны для заполнения.

Таблица 3 - Атрибуты таблицы CONTACT

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
ID_CONTACT_NAME	BIGINT	20	+
VALUE	VARCHAR	100	+
ID_STUDENT	BIGINT	20	+

Таблицы CONTACT_NAME (табл. 4) и CONTACT связаны соотношением «один ко многим», что означает, что одно и то же название контакта может быть использовано для нескольких контактов. Для обеспечения такой связи в таблицу CONTACT добавлено поле ID_CONTACT_NAME. Также необходимо обозначить и саму связь - добавить внешний ключ (ВК, foreign key), который обеспечит целостность данных и не позволит добавить контакт со ссылкой (ID) на несуществующее название контакта.

Таблица 4 - Атрибуты таблицы CONTACT_NAME

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
NAME	VARCHAR	100	+

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

Сущность «Тема занятия» должна представлять собой иерархическую структуру, поэтому в таблице, описывающей эту сущность (табл. 5), добавляется специальное поле ID_PARENT_THEME - идентификатор родительской записи. Дополнительное поле позволит определить связи в дереве тем занятий между родительскими и дочерними элементами. Для корневого элемента в поле PID будет значение NULL - родительский элемент отсутствует.

Таблица 5 - Атрибуты таблицы THEME

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
ID_PARENT_THEME	BIGINT	20	-
NAME	VARCHAR	255	+
COMMENT	VARCHAR	255	-
ID_SUBJECT	BIGINT	20	+

Сущность «Занятие» связана с некоторыми уже описанными сущностями. С таблицей EVENT связь «один к одному», т.к. каждое событие может быть занятием, и это распространяется на серию событий тоже. При этом событие будет существовать независимо от того, существует ли связанное с ним занятие, поэтому ID, связывающий сущности, следует добавить в таблицу LESSON.

Также каждое занятие проводится в рамках некоторой дисциплины (табл. 6), связь с сущностью «Дисциплина» - «многие к одному», поскольку для каждой дисциплины может быть проведено много занятий. С другой стороны, каждая тема занятия связана с дисциплиной как «многие к одному», поэтому в таблицу THEME добавляется поле ID_SUBJECT.

Таблица с дисциплинами должна содержать в себе идентификатор и наименование дисциплины. Изначально это таблица-справочник, на которую ссылаются сущности «Занятие» и «Тема занятия».

Таблица 6 - Атрибуты таблицы SUBJECT

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
NAME	VARCHAR	100	+
ID_TUTOR	BIGINT	20	+

Помимо этого, каждое занятие связано с одним студентом, соответственно, должна существовать связь «один к одному» между таблицами LESSON и STUDENT. Для поддержания целостности данных в таблицу LESSON (табл. 7) нужно добавить поле ID_SUBJECT. Также, как правило, занятие имеет определенную стоимость (price). Тип данных для стоимости - десятичное число с двумя знаками после запятой. Для соответствия типам данных в языке Java (класс BigDecimal) размер такого десятичного числа довольно большой: 19 символов.

Таблица 7 - Атрибуты таблицы LESSON

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
ID_EVENT	BIGINT	20	+
ID_STUDENT	BIGINT	20	+
ID_SUBJECT	BIGINT	20	+
PRICE	DECIMAL	(19,2)	+

Для описания сущности «Запись журнала» потребуются следующие данные: ссылка на занятие, дата конкретного занятия, ссылка на тему занятия, домашнее задание, оценки за занятие и домашнее задание, комментарий преподавателя (табл. 8). Следует учесть, что для одного занятия (особенно, если это серия повторяющихся занятий) может существовать несколько записей в журнале: по одной для каждой конкретной даты. Для обеспечения связи «один ко многим» добавим в таблицу JOURNAL атрибут ID_LESSON и соответствующий внешний ключ. Аналогичная связь существует и с таблицей THEME.

Таблица 8 - Атрибуты таблицы JOURNAL

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
ID_LESSON	BIGINT	20	+
ID_THEME	BIGINT	20	-
DATE	DATE	YYYY-MM-DD	+
HOMETASK	VARCHAR	255	-
LESSON_MARK	VARCHAR	255	-
HOMETASK_MARK	VARCHAR	255	-
COMMENT	VARCHAR	255	-

Поля с оценками могут заполняться репетитором произвольно, это не обязательно одна оценка, поэтому допускается максимальный возможный размер - 255 символов.

Данные по теме занятия, домашнему заданию и оценкам могут быть заполнены в любое время, а не только при создании новой записи в журнал, поэтому соответствующие поля не являются обязательными.

Для работы в системе нескольких пользователей необходимо разграничить данные, связав их с идентификатором пользователя. Другими словами, например, список студентов одного репетитора может быть показан только этому репетитору, и у другого пользователя системы не должно быть доступа к этим данным. Простое решение данной проблемы заключается в создании таблицы с сущностью «Репетитор». Данные в этой таблице могут быть представлены логином пользователя, паролем (в зашифрованном виде), личной информацией о репетиторе и т.п. Для самого минимального варианта достаточно одного идентификатора. Помимо этого, добавим имя и адрес (табл. 9).



Таблица 9 - Атрибуты таблицы TUTOR

Атрибут	Тип данных	Размер/возможные значения	Обязательное поле
ID	BIGINT	20	+
NAME	VARCHAR	255	-
ADDRESS	VARCHAR	255	-

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

Таким образом, описаны все необходимые сущности в виде таблиц, справочников и связей между ними. Создание самой базы данных и таблиц выполняется с помощью соответствующих SQL_запросов (приложение 1).

Помимо этого, в ходе разработки приложения необходимо определить порядок добавления и удаления записей в таблицах с учетом внешних ключей. Если в какой-то момент произойдет нарушение необходимого порядка, СУБД сгенерирует ошибку, и данные не будут добавлены или удалены. Несоответствие типов данных или отсутствие части данных для обязательных полей также могут привести к сообщениям об ошибках.



3. РАЗРАБОТКА ПРИЛОЖЕНИЯ

Разработку приложения можно разделить на несколько частей:

1) разработка серверной части приложения на языке Java:

а) классы/интерфейсы для взаимодействия с базой данных,

б) классы, объединяющие функционал в сервисы, утилитные классы (реализация бизнес-логики),

в) классы точек доступа REST;

2) разработка интерфейса пользователя:

а) создание статичных составляющих (HTML),

б) настройка стилей (CSS, Bootstrap),

в) управление содержимым, в том числе через Ajax_запросы, обработчики событий для кнопок (JavaScript, JQuery).

При этом разработка возможна по уровням: сначала полностью реализовывается взаимодействие с БД, затем описывается слой бизнес-логики, потом - точки доступа для HTTP_запросов и т.д. С другой стороны, возможна разработка функционала по частям: реализация доступа только к нескольким таблицам из базы, создание сервиса для работы с этими данными, вывод их в интерфейс (на отдельной странице или части страницы).

На практике разработка частичного функционала позволяет избежать повторения ошибок за счет больших возможностей для тестирования, а также упрощает внесение изменений в логику программы. Тем не менее, в готовом (или частично готовом) приложении проще разобраться по уровням: начиная с получения данных из базы или, наоборот, из интерфейса пользователя.

Плагин Spring Boot создает каркас серверной части приложения без использования xml файлов настроек [4], кроме одного - pom.xml - необходимого для сборки приложения через Maven. В файле pom.xml прописываются название проекта, вариант упаковки проекта в результате сборки, версия jdk, необходимые для работы приложения зависимости и плагины.

Еще одной важной отличительной особенностью Spring является создание и поддержание контекста приложения. Контекст - это интерфейс, который представляет собой окружение для компонент приложения. Одной из важных задач контекста является инициализация бинов - объектов, таких как сервисы или контроллеры. В настройках контекста можно явно указать, какое количество объектов каждого класса необходимо: один на все приложение, один на сессию и т.д.

На основании аннотаций, пришедших на замену конфигурационным файлам xml, формируется набор компонентов следующих уровней:

· Repository. Интерфейс, обеспечивающий непосредственный доступ к базе данных.

· Service. Компонент, в котором можно объединить несколько репозиториев для совместного использования.

· RestController. Компонент, внутри которого создаются точки доступа к приложению через REST. Использует сервисы для получения данных.

Помимо этого, описываются классы-сущности с аннотацией @Entity, соответствующие таблицам в БД, и классы для передачи данных - Data Transfer Object (DTO).

3.1 Реализация взаимодействия с базой данных

Помимо всего прочего, Spring Boot позволяет использовать возможности фреймворка Hibernate для доступа к БД. Hibernate - это библиотека Java, позволяющая решать задачи объектно-реляционного отображения (ORM), то есть отображения традиционных реляционных баз данных в объектно-ориентированную модель и наоборот. Hibernate является реализацией спецификации JPA (Java Persistence API).

Для настройки Spring Boot необходим файл application.properties, в котором можно переопределить нужные параметры, в том числе URL для доступа к БД, стратегию создания/обновления БД при старте приложения и т.п. Также, при сборке приложения возможно добавление записей, записанных в файле data.sql через SQL команду INSERT. На этапе разработки базы данных эта функция особенно актуальна, т.к. во время сборки проекта в автоматическом режиме база данных может быть создана заново, после чего заполнена тестовыми данными из data.sql.

URL для доступа к БД - это строка, описывающая стандарт взаимодействия с базой данных, СУБД, сервер и порт для подключения, название используемой базы данных. В приложении использовался URL: jdbc:mysql://localhost:3306/testing_db.

Для работы с данными, полученными из БД, были созданы классы-сущности (Entity). Поля таких классов соответствуют атрибутам в таблицах базы данных. Поскольку в каждой сущности используется идентификатор, был создан общий базовый класс BaseEntity с полем id, от которого наследуются все классы Entity. Благодаря этому все изменения, касающиеся идентификаторов, можно применять к одному участку кода.

Связи между сущностями определяются аннотациями @OneToOne, @OneToMany, @ManyToOne и @ManyToMany. Аннотации пишутся над полями класса, при этом в отличие от состава таблицы, для таких связей полями являются на идентификаторы других сущностей, а сами эти сущности. То есть, если в таблице CONTACT есть ID связанной таблицы CONTACT_NAME, то в сущности Contact есть поле с типом данных ContactName. Для связи «один ко многим» аналогичным образом можно задать списковое поле (Set или List).

Spring (и Hibernate в его составе) позволяет избежать ряда рутинных операций при разработке доступа к БД:

1. при изменении в структуре базы данных эти же изменения должны дублироваться в классах-сущностях; с использованием фреймворка появляется возможность пересоздать базу данных на основе только классов при запуске приложения;

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

3. нет необходимости в написании большого количества шаблонного кода для стандартных операций поиска, добавления, редактирования и удаления записей в таблицах (CRUD операции).

Модуль Spring Data JPA позволяет описать непосредственное взаимодействие с БД через интерфейсы без реализации. Данный модуль по умолчанию реализует CRUD операции, а также создает реализацию на основе имени метода. Например, метод findByName сгенерирует запрос по полю с названием «name» (его необходимо передать в метод в качестве параметра). Аналогично можно делать запросы в базу по вложенным объектам и их полям. Для более сложных запросов можно использовать аннотацию @Query с прямым указанием текста запроса на языке SQL или JPQL.

На уровне репозиториев реализованы следующие операции с данными (табл.10).

Таблица 10 - Методы интерфейсов Repository

Репозиторий	Метод	Описание
Для всех репозиториев по умолчанию	findOne	поиск записи по идентификатору
	findAll	выбор всех записей
	exists	проверка существования записи в таблице, по идентификатору или объекту целиком
	save, flush, saveAndFlush	сохранение записи в таблицу
	delete	удаление записи по идентификатору или переданному объекту
	deleteAll	удаление всех записей в таблице
	count	подсчет записей в таблице, всех или по критериям
ContactNameRepository	findByName	поиск по полю name
ContactRepository	findByIdStudent	поиск всех контактов по идентификатору студента
EventRepository	findAllByIdTutor	поиск по идентификатору репетитора
	findAllEventsBetweenDates	поиск событий между датой начала и окончания, с учетом идентификатора репетитора
SubjectRepository	findByIdTutor	поиск по идентификатору репетитора
StudentRepository	findByIdTutor	поиск по идентификатору репетитора
JournalRepository	findByTutor	постраничный поиск записей журнала по идентификатору репетитора
	findByLessonAndDate	поиск по занятию и дате
ThemeRepository	findBySubjectId	поиск по идентификатору дисциплины
	findByIdParentTheme	поиск всех тем занятий по идентификатору родительской записи
TutorRepository	findByNameAndAddress	поиск по имени и адресу

3.2 Реализация бизнес-логики приложения

Репозитории с помощью «инъекции зависимости» (Dependency Injection) включаются внутрь классов_сервисов. Со стороны контекста Spring в первую очередь создаются объекты классов репозиториев, затем сервисов. Каждый сервис может работать с одним репозиторием или объединять их в небольшой логический модуль. В частности, были созданы StudentContactService, для работы с сущностями Student, Contact и ContactName, и SubjectThemeService для Subject и Theme.

Чтобы записать нового студента в базу, необходимо сначала записать экземпляр класса Student, а затем все его контакты, поскольку в каждом контакте есть ссылка на студента. При этом для записи контакта нужно также записать все названия контактов. Если этого не сделать в необходимой последовательности, БД сгенерирует ошибку, т.к. мы попытаемся записать данные частично, что может привести к нарушению целостности. К тому же, следует позаботиться об откате внесенных изменений, если часть данных уже записана. Для удобного управления записью данных в несколько таблиц существует аннотация @Transactional, которая добавляется над методом и говорит о том, что работа с БД внутри этого метода соответствует одной транзакции. В случае ошибок в процессе выполнения метода, все изменения, которые уже были внесены, откатятся до состояния, соответствующего началу выполнения метода.

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

Помимо связи между разными сущностями, в модели данных также существует связь сущности с самой собой - это касается тем занятий (Theme). Каждая тема занятия может иметь ссылку на родительскую тему. Чтобы составить все дерево тем, необходимо по id корневого элемента произвести несколько запросов в базу данных: для каждого узла дерева получить список дочерних элементов, либо убедиться, что таковых не существует. Метод для получения всех тем занятий по id родительской записи описан в сервисе SubjectThemeService - это рекурсивный вызов метода репозитория по получению всех дочерних элементов одного уровня.

Для передачи информации в ответе на REST запросы были использованы объекты DTO. Для каждой сущности (Entity_класса) создан соответствующий ему класс объекта передачи данных, с помощью которого можно избежать излишней вложенности в JSON данных и передавать только необходимую информацию. В каждом классе DTO есть статический метод of, позволяющий преобразовать Entity в DTO и заполнить все необходимые поля. Также возможно преобразование списка объектов_сущностей в список объектов DTO через перегруженный метод of.