Многопользовательский проектно-ориентированный планировщик задач

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

Оглавление

Введение

1. Анализ предметной области

1.1 Обзор существующих решений

1.2 Заключение

2. Технические характеристики приложения

2.1 Используемые решения и технологии

2.2 Архитектура приложения

3. Реализация приложения

3.1 Алгоритм работы приложения

3.2 Основные классы приложения

3.3 База данных приложения

3.4 Модели данных приложения

3.5 Классы приложения для работы с СУБД

3.6 Возможности расширения приложения. Модули

4. Использование приложения

4.1 Регистрация и авторизация

4.2 Создание и выбор рабочего пространства

4.3 Работа с проектами и задачами

4.4 Работа с метками и статусами задач

4.5 Приглашение пользователей

4.6 Установка и удаление модулей

Заключение

Библиография

Введение

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

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

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

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

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

Для реализации проекта «Многопользовательский проектно-ориентированный планировщик задач» необходимо выполнить ряд шагов:

Определить и объяснить тему проекта.

Провести подробное исследование существующих решений, определить их основные характеристики, достоинства и недостатки.

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

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

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

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

Разработать приложение.

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

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

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

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

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

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

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

регистрация авторизация пространство проект



1. Анализ предметной области

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

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

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

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

Producteev;

Asana;

Redmine;

Teamer.

Выбор был сделан исходя из популярности продуктов, уникальности представленного приложением набора функций, дизайна и возможности использования без оплаты лицензии из более чем 200 аналогов [1, 2].

Сравнение решений было произведено с использованием следующего набора характеристик:

функциональность;

удобность работы с интерфейсом;

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

организация данных;

наличие разных статусов завершенности задач;

платность/бесплатность.



1.1 Обзор существующих решений

Producteev

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

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

Так же в Producteev задачи могут обладать только двумя статусами завершенности: сделана или не сделана.

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

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

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

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

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

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

Интерфейс. В Producteev интерфейс представляет из себя несколько колонок, у каждой свое функциональное назначение. Такой вид интерфейса типичен для многих решений данного класса.

Загрузка данных без перезагрузки страницы. При работе с интерфейсом загрузка любых данных происходит без перезагрузки страницы.

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

Статусы завершенности задач. В Producteev задача может быть либо завершенной, либо незавершенной.

Платность. Producteev предоставляет возможность бесплатного пользования для проектов с количеством пользователей до 2-х. Если участников больше, то необходимо оплатить продукт.

Asana

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

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

Как и Producteev, Asana предоставляет только 2 статуса завершенности задач -- завершено или не завершено.

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

Redmine

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

В планировщике Redmine представлен список всех проектов и задач по ним, доступ на чтение к которым имеет пользователь. Так же каждый проект может обладать подпроектами с собственными настройками доступа. Одна установка системы предоставляет одно рабочее пространство.

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

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

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

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

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

Подводя итоги, можно сказать о Redmine следующее по каждой рассматриваемой характеристике:

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

Интерфейс. В Redmine интерфейс был разработан достаточно давно, что имеет свои последствия: Redmine имеет неудобный и несовременный интерфейс.

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

Организация данных. Все данные хранятся в рамках одного проекта или подпроекта.

Статусы завершенности задач. В Redmine предусмотрено 7 статусов задач.

Платность. Redmine полностью бесплатен для использования.

Teamer

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

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

В Teamer простая система авторизации, регистрации и приглашений пользователей в проект. После того как был создан проект, появляется возможность приглашения людей в него. Эта возможность реализована как текстовое поле для ввода e-mail адреса человека, которого нужно пригласить. Если по такому адресу человек уже регистрировался в системе раньше, то он автоматически добавляется в проект. В противном случае на e-mail высылается письмо с подтверждением регистрации в системе, после чего пользователь так же вступает в проект.

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

Каждая задача может быть завершенной или незавершенной, аналогично системам Asana и Producteev.

Teamer бесплатен при пользовании им как веб-сервисом. Доступна платная версия с возможностью установки на собственный сервер.

1.2 Заключение

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

объединение проектов и людей в рабочем пространстве;

наличие большого количества статусов задач;

гибкие фильтры по всем свойствам задач;

использование частичной загрузки контента на странице;

простой в использовании интерфейс.

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

2. Технические характеристики приложения

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

2.1 Используемые решения и технологии

Так как реализуемое решение является веб-приложением, в основе его работы лежит взаимодействие сервера и клиента. В качестве клиента выступает браузер, в качестве сервера -- HTTP-сервер с возможностью выполнения кода на PHP и доступом к СУБД MySQL из этого кода.

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

HTML в качестве языка разметки, на котором строится интерфейс приложения.

CSS используется для стилизации интерфейса приложения.

JavaScript - язык программирования, код на котором может выполняться в браузере. Используется в системе для создания интерактивных элементов интерфейса, а так же для взаимодействия с сервером.

AJAX - частичная загрузка данных с сервера без перезагрузки страницы с помощью JavaScript.

JSON - формат данных, используемый для получения информации с сервера.

Mustache - шаблонизатор, используемый для сопоставления данных с разметкой. Существует его реализация и для JavaScript, и для PHP

jQuery - библиотека для JavaScript, используемая для удобного доступа к дереву DOM документа.

Для серверной части были использованы:

PHP как основной язык программирования для серверной логики приложения.

Mustache - шаблонизатор.

MySQL - используемая в работе SQL СУБД.

2.2 Архитектура приложения

В основе архитектуры дипломного проекта лежит подход, называемый MVC. Аббревиатура MVC раскрывается как Model-View-Controller и показывает 3 основных компонента приложения:

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

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

Контроллер (Controller). Контроллер выполняет функцию объединения представлений и моделей, необходимых для работы в данный момент. В зависимости от того, что запрашивает или с чем взаимодействует пользователь, приложение должно быть выбран контроллер, адекватно реагирующий на действия пользователя. В случае веб-приложений обычно контроллер выбирается исходя из содержимого строки запроса и его параметров. Если вернуться к примеру с проектами, приведенном в описании модели, то можно сказать, что контроллер, отвечающий на запрос вида "<домен_приложения>/workspace/1" должен запросить у модели проектов список проектов, лежащих в рабочем пространстве с идентификатором 1 и передать этот список соответствующему представлению. Очевидно, что могут быть случаи, когда на одном экране приложения должны быть отображены данные из нескольких источников (моделей). Тогда контроллер может вызвать несколько моделей и объединить их данные, но встает проблема выбора представления: выбирать ли представление для каждой модели или для страницы в целом. В дипломном проекте проблема решена вложениями представлений друг в друга.

3. Реализация приложения

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

3.1 Алгоритм работы приложения

При получении серверной частью приложения запроса со стороны клиента выполняются следующие действия:

Обработка запроса. Этот процесс включает в себя преобразования ссылки вида "<домен_приложения>/параметр1/параметр2..." на список подстрок вида "параметр1, параметр2 ...". Так же в запросе возможно задание формата данных (JSON или HTML; если формат не задан явно, то выбирается формат по умолчанию, то есть HTML), о котором указывает расширение, добавляемое к последнему параметру запроса. Пример обработки запроса "<домен_приложения>/workspace/1.json": запрос будет разбит на параметры "workspace" и "1", формат вывода данных будет выбран как JSON.

Так же при обработке запроса могут быть выделены дополнительные параметры, переданные как GET или POST. GET запрос имеет в строке запроса дополнительные параметры вида "<путь_запроса>?param1=value1&param2=value2..." с парами ключ-значение (для первого параметра ключом будет param1, значение - value1). В случае с POST аналогичные пары могут быть переданы в теле запроса.

Инициализация данных о системной схеме базы данных. На основе схемы происходит автоматическое соединение таблиц базы данных, а так же создание таблиц при новой установке системы. Системная структура таблиц хранится в специальном файле на сервере. При расширении модулями она может быть дополнена.

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

Создание автозагрузчика файлов классов, используемых приложением. Язык программирования PHP не предусматривает единых правил для структуры файлов исходного кода и папок. Как следствие, за включением нужных на данный момент файлов должен следить сам программист либо с помощью непосредственного включения файлов по их пути в файловой системе, либо с использованием так называемого автозагрузчика, который используется в проекте. Алгоритм работы автозагрузчика следующий: если при выполнении кода программы было обнаружено обращение к классу, который еще не был подключен, его имя передается автозагрузчику. Автозагрузчик исходя из переданного имени находит необходимый файл и подключает его. Если файл не был найден, генерируется исключение. В планировщике задач для корректной работы приложения все файлы с исходными кодами классов должны лежать в определенных папках и иметь имя, соответствующее имени типа с расширением "php". Файлы, не содержащие классов, должны быть подключены путем непосредственного вызова операций включения файлов.

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

Задание списков необходимых для работы приложения клиентских файлов (стилей CSS и файлов JavaScript кода). Интерфейс приложения может содержать не только разметку, но и файлы других типов, которые необходимо подключить на стороне клиента для корректной работы приложения. Без этих файлов отображаемая пользователю информация может выглядеть непонятной, а так же может быть нарушена логика приложения, так как часть ее реализована для выполнения на стороне клиента (исходные коды на JavaScript).

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

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

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

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

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

Определение контроллера, который необходимо запустить исходя из списка соответствий, составленного на шаге № 7, и запускает его. На этом шаге происходит инициализация контроллера и задание его параметров. Контроллер выбирается либо по полному соответствию запроса пользователя и запросу из списка соответствия контроллеров и параметров запроса, либо если второй является подстрокой первого. Например, один и тот же контроллер, которому соответствует запрос "<домен_приложения>/workspace" может быть применен к следующим путям: "<домен_приложения>/workspace/1", "<домен_приложения>/workspace/1/one_more_parameter", "<домен_приложения>/workspace". Стоит так же упомянуть, что в качестве параметров контроллеру передается только та часть строки запроса, которая идет после соответствующей строки в списке контроллеров. То есть в случае "<домен_приложения>/workspace/1" контроллеру будет переданы не "workspace", "1", а только "1". За обработку неверных строк запроса в таких случаях отвечает не система, которая может определить запрос как неверный только в случае отсутствия контроллера для такого запроса, а сам контроллер.

3.2 Основные классы приложения

Ниже приведена UML диаграмма классов, показывающая отношения классов приложения, а так же раскрывающая его архитектуру.



На диаграмме видно 3 класса: App, Controller и Model. Блок View не является классом, он иллюстрирует наличие представлений, выбираемых контроллером. Так как представления в приложении являются файлами с разметкой и вставками кода, то они не выделены на диаграмме как класс. Однако, представления являются неотъемлемой частью системы, поэтому исключать их из диаграммы тоже неверно. Далее приведено подробное описание каждого класса на диаграмме.

App

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

Класс App содержит только статические поля и методы, за исключением метода loadClass(), который используется для автозагрузки классов. В связи с ограничениями PHP в качестве функции автозагрузки нельзя использовать статические методы, поэтому было решено сделать loadClass() не статическим. Единственным объектом класса App в приложении является объект автозагрузки классов. Во всех остальных случаях испольуются исключительно статические члены класса App.

Пояснения к полям класса App:

+ path : string - открытое поле, инициализируемое значением строки запроса без домена приложения, параметров GET, расширения и крайних символов "/";

+ args : string[] - открытое поле, являющееся массивом значений, являющихся результатом разбиения значения поля path на подстроки с использованием разделителя "/" (например, если поле path равно "workspace/1/delete", то значением args будет массив из элементов "workspace", "1", "delete");

+ user : User - открытое поле, объект класса User, содержащий информацию об аккаунте пользователя в системе;

+ modules : array[] - открытое поле, словарь модулей системы, ключом которого является уникальный код модуля, значением - массив, содержащий информацию о модуле, такую как название и описание;

+ mode : string - открытое поле, запрошенный формат данных, определяемый отделением расширения из строки запроса (часть строки после точки и перед параметрами GET, если такие есть в запросе);

+ controllers : Controller[] - открытое поле, словарь соответствия строки запроса в формате, аналогичном значению переменной path, экземпляру контроллера;

+ scripts : string[] - открытое поле, список JavaScript файлов, подключаемых на странице на стороне клиента;

+ styles : string[] - открытое поле, список файлов CSS стилей, подключаемых на странице на стороне клиента;

+ mainNav : string[] - открытое поле, словарь соответствия ссылки и ее имени в главном меню приложения;

+ tmpl : Mustache_Engine - открытое поле, экземпляр шаблонизатора.

Пояснения к методам класса App:

+ init() - открытый статический метод, инициализирует приложение; вызывается единожды при обращении к серверу;

+ requireModule(name : string) - открытый статический метод, загружает модуль с указанным системным названием (кодом), определяемым именем папки с файлами модуля;

+ loadModules() - открытый статический метод, загружает все включенные модули;

+ registerController(path : string, controller : Controller) - открытый статический метод, регистрирует контроллер controller по пути path в словаре контроллеров;

+ show404() - открытый метод, вызывается в случае, если нужно клиенту вернуть 404 ошибку сервера (ресурс не найден);

+ loadClass(name : string) - открытый метод, автоподгрузчик классов;

- initArgs() - закрытый статический метод, производит обработку запроса;

- initControllers() - закрытый статический метод, производит задание всех контроллеров, необходимых для работы системы;

- initMustache()- закрытый статический метод, инициализирует экземпляр шаблонизатора;

- initMainNav()- закрытый статический метод, задает пункты главного меню;

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

Controller

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

Пояснения к полям класса Controller:

# args : string[] - защищенное поле, список аргументов, передаваемых контроллеру;

# view : string - защищенное поле, имя шаблона, используемого как шаблон страницы;

# output : mixed - защищенное поле, хранит данные, сформированные на основе моделей.

Пояснения к методам класса Controller:

+ Controller(args : string[]) - открытый конструктор, инициализирует аргументы контроллера;

+ setOutput(output : mixed) - открытый метод, задает данные для вывода;

+ getOutput() - открытый метод, возвращает данные для вывода;

+ setView(view : string) - открытый метод, задает имя шаблона страницы;

+ getView() - открытый метод, возвращает имя шаблона страницы;

+ setArgs(args : string[]) - открытый метод, задает аргументы контроллера;

+ getArgs() - открытый метод, возвращает аргументы контроллера;

+ render() - открытый метод, выводит на страницу представление или возвращает output в определенном формате (зависит от переменной mode в классе приложения);

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

Model

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

Пояснения к полям класса Model:

# params : string[] - защищенное поле, массив параметров, необходимых для выдачи отображаемых в представлении данных;

# view : string - защищенное поле, содержит имя представления модели;

# output : mixed - защищенное поле, содержит отображаемые данные.

Пояснения к методам класса Model:

+ Model(view : string, params : string[]) - открытый конструктор, задает имя представления для модели, а так же ее параметры;

+ setOutput(output : mixed) - открытый метод, задает отображаемые данные;

+ getOutput() - открытый метод, возвращает отображаемые данные;

+ setView(view : string) - открытый метод, задает имя представления модели;

+ getView() - открытый метод, возвращает имя представления модели;

+ output() - открытый абстрактный метод, должен задавать отображаемые данные;

+ insert(params : mixed) - открытый абстрактный метод, должен реализовывать логику добавления данных;

+ update(params : mixed) - открытый абстрактный метод, должен реализовывать логику изменения данных;

+ delete(params : mixed) - открытый абстрактный метод, должен реализовывать логику удаления данных;

+ formScheme() - открытый абстрактный метод, возвращает структуру параметров, необходимых для создания или изменения данных (используется для формирования форм добавления/изменения данных в представлениях).

View

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

В работе был использован шаблонизатор Mustache. Из многих существующих решений в этой области был выбран именно Mustache, так как только он имеет реализацию и на PHP, и на JavaScript, что позволило избежать дублирование кода шаблонов, предназначенных для обработки на стороне клиента и сервера. Любой шаблон, написанный с использованием специального синтаксиса Mustache, может быть обработан в частности на PHP и на JavaScript.

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

Классы Model и Controller являются абстрактными. В системе используются классы, унаследованные от данных, для реализации конкретной логики. Например, для работы с задачами используется класс TasksModel, унаследованный от Model, для вывода задач и проектов в данном рабочем пространстве используется класс TasksController, наследник Controller.

3.3 База данных приложения

В приложении для постоянного хранилища данных используется SQL база данных, управляемая СУБД MySQL. В базе хранятся данные о рабочих пространствах, проектах, задачах, комментариях к задачам, прикрепленных файлах, статусах задач, метках, а так же могут храниться любые произвольные данные, хранимые модулями.

Ниже приведена ER-диаграмма таблиц, входящих в состав приложения без установленных модулей.



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

workspace

Таблица workspace хранит данные о созданных в системе рабочих пространствах. Описание атрибутов:

wid - первичный ключ, идентификатор рабочего пространства;

name - имя рабочего пространства.

project

Таблица project содержит данные о проектах, созданных в системе. Каждый проект может быть создан строго внутри одного рабочего пространства. Описание атрибутов:

pid - первичный ключ, идентификатор проекта;

wid - внешний ключ, указывает на рабочее пространство, в котором был создан проект;

name - имя проекта.

task

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

tid - первичный ключ, идентификатор задачи;

name - имя задачи;

pid - внешний ключ, указывает на проект, в котором была создана задача;

sid - внешний ключ, указывает на статус задачи;

tag_id - внешний ключ, указывает на метку задачи.

status

Таблица status содержит доступные статусы задач. Описание атрибутов:

sid - первичный ключ, идентификатор статуса;

name - имя статуса.

tag

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

tag_id - первичный ключ, идентификатор метки;

name - имя метки;

r, g, b - компоненты кода цвета в формате RGB, где r, g, b, соответственно, коды красного, зеленого и синего цветов.

comment

Таблица comment хранит комментарии к задачам. Описание атрибутов:

cid - первичный ключ, идентификатор комментария;

body - текст комментария;

time - время написания комментария;

tid - внешний ключ, ссылается на задачу, к которой был написан комментарий;

uid - внешний ключ, ссылается на аккаунт пользователя, который оставил комментарий.

file

Таблица file хранит данные о прикрепленных к задачам файлах. Описание атрибутов:

fid - первичный ключ, идентификатор файла;

filename - имя файла при загрузке;

tid - внешний ключ, ссылается на задачу, к которой был прикреплен файл.

user

Таблица user хранит данные об аккаунтах пользователей системы. Описание атрибутов:

uid - первичный ключ, идентификатор аккаунта пользователя;

name - уникальное имя аккаунта пользователя;

password - хеш-код, вычисленный из пароля пользователя;

email - адрес электронной почты пользователя.

workspace_user

Таблица workspace_user реализует связь многие-ко-многим между таблицами user и workspace. Каждый пользователь может быть добавлен к нескольким рабочим пространствам, каждое рабочее пространство может быть использовано несколькими пользователями. Описание атрибутов:

wid - первичный ключ, внешний ключ, ссылается на рабочее пространство, в котором заведен аккаунт пользователя;

uid - первичный ключ, внешний ключ, ссылается на аккаунт пользователя рабочего пространства.



3.4 Модели данных приложения

Без установленных модулей приложение предоставляет следующие модели для работы с данными из базы данных:

WorkspacesModel. Предоставляет данные о рабочих пространствах системы, доступных пользователю.

ProjectsModel. Предоставляет данные о проектах в определенном рабочем пространстве.

TasksModel. Предоставляет данные о задачах в определенном проекте.

TagsModel. Предоставляет данные о метках.

StatusesModel. Предоставляет данные о статусах задач.

CommentsModel. Предоставляет данные о комментариях к определенной задаче.

FilesModel. Предоставляет данные о прикрепленных к определенной задаче файлах.

UsersModel. Предоставляет данные об аккаунтах пользователей в рамках заданного рабочего пространства.

3.5 Классы приложения для работы с СУБД

Для работы с СУБД в дипломном проекте был предусмотрен специальный набор классов, реализующий логику, связанную с отправкой запросов и получением результатов из базы данных. Это было необходимо для того, чтобы предоставить механизм автоматического обнаружения и устранения ошибок ввода, защиты от взлома, а так же чтобы предоставить удобный интерфейс для работы с СУБД. В классах реализован так называемый принцип "цепочки вызовов" (chaining), то есть при каждом вызове методов объекта возвращается сам объект (если не нужно вернуть какой-то результат работы метода), что позволяет создавать цепочку вызовов, как в приведенном примере. Ниже приведена таблица сравнения кода с использованием прямого обращения к базе и использованием специального класса.

Прямой запрос к базе данных	Интерфейс взаимодействия с базой данных
mysql_connect('local', 'user', 'pswd'); mysql_select_db('task_manager'); $res = mysql_query(' SELECT user.name, comment.body, task.name FROM comment INNER JOIN user ON user.uid = comment.uid INNER JOIN task ON task.tid = comment.tid WHERE task.name = \'Новая задача\' '); $comments = array(); while ($row = mysql_fetch_assoc($res)) { $comments[] = $row; }	$s = new Selector(); $comments = $s -> addEntity('comment') -> addRelation(new Relation('comment', 'user', true)) -> addRelation(new Relation('comment', 'task', true)) -> addFields(array('user.name', 'comment.body', 'task.name')) -> addFilter(new Filter('task.name', 'Новая задача')) -> execute();

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

Всего а приложении предусмотрено 6 классов для работы с СУБД: Selector, Inserter, Updater, Deleter, Filter, Relation используемые для выборки, вставки, изменения и удаления строк в таблицах, для фильтрации, установки отношений между таблицами, соответственно. Ниже приведена UML диаграмма этих классов.



Как видно из диаграммы, объект класса Relation может быть частью объекта класса Selector, объект класса Filter может быть частью объекта любого из классов Selector, Updater, Deleter. Далее приведено более подробное описание каждого класса.

Selector

Класс Selector содержит логику, необходимую для выборки данных.

Поля класса Selector:

- tables : string[] - закрытое поле, массив имен таблиц, из которых необходимо произвести выборку (FROM);

- relations : Relation[] - закрытое поле, массив объектов отношений, задающих правила для соединения таблиц (JOIN);

- filters : Filter[] - закрытое поле, массив объектов условий выборки, задающих ограничения выборки (WHERE);

- fields : string[] - закрытое поле, массив имен полей, которые необходимо вывести (SELECT);

- limit : int[2] - закрытое поле, массив параметров ограничения количества выбираемых элементов (LIMIT);

- order : string[] - закрытое поле, массив параметров сортировки выборке (ORDER BY).

Методы класса Selector:

+ Selector() - открытый конструктор, инициализирует объект класса;

+ addEntity(e : string) : this - открытый метод, добавляет имя таблицы в массив таблиц, из которых будет производиться выборка;

+ addFields(f : string[]) : this - открытый метод, задает набор атрибутов, которые необходимо вывести;

+ addRelation(r : Relation) : this - открытый метод, добавляет объект отношения к выборке;

+ addFilter(f : Filter) : this - открытый метод, добавляет объект условия выборки;

+ setLimit(from : int, length: int) : this - открытый метод, задает ограничения количества выбираемых строк;

+ addOrderBy(field : string, asc : bool) : this - открытый метод, добавляет критерий сортировки выборки;

+ __toString() : string - метод преобразования объекта в строку, возвращает строку SQL-запроса, выполняемую в СУБД;

+ execute() - открытый метод, выполняет запрос и возвращает результат.

Inserter

Класс Inserter отвечает за создания новых строк в таблицах базы данных.

Поля класса Inserter:

- values : string[] - закрытое поле, словарь вставляемых значений, где ключом является название поля, значением - задаваемое этому полю значение;

- table : string - закрытое поле, имя таблицы, в которую осуществляется добавление.

Методы класса Inserter:

+ Inserter(table : string) - открытый конструктор, инициализирует объект класса;

+ addValue(field : string, value : string) - открытый метод, добавляет новое значение поля

+ __toString() : string - метод преобразования объекта в строку, возвращает строку SQL-запроса, выполняемую в СУБД;

+ execute() - открытый метод, выполняет запрос и возвращает результат.

Updater

Класс Updater отвечает за выполнение запросов, изменяющих значения полей в строках таблиц базы данных.

Поля класса Updater:

- values : string[] - закрытое поле, словарь задаваемых значений, где ключом является название поля, значением - задаваемое этому полю значение;

- table : string - закрытое поле, имя таблицы, в которой изменяются данные.

- filters : Filter[] - закрытое поле, массив объектов условий выборки, задающих ограничения для изменяемых строк таблицы;

Методы класса Updater:

+ Updater(table : string, values : string[], filter : Filter) - открытый конструктор, создает новый объект с заданными таблицей, словарем изменяемых значений и одним объектом условий выборки;

+ addValue(field : string, value : string) - открытый метод, добавляет новое значение поля;

+ addFilter(filter : Filter) - открытый метод, добавляет объект условия выборки;

+ __toString() : string - метод преобразования объекта в строку, возвращает строку SQL-запроса, выполняемую в СУБД;

+ execute() - открытый метод, выполняет запрос и возвращает результат.

Deleter

Класс Deleter выполняет удаление строк из таблиц базы данных.

Поля класса Deleter:

- table : string

- filters : Filter[]

Методы класса Deleter:

+ Deleter(table : string, filter : Filter)

+ addFilter(filter : Filter)

+ __toString() : string

+ execute()

Relation

Класс Relation содержит логику, связанную с соединением таблиц между собой.

Поля класса Relation:

- source : string - закрытое поле, содержит имя таблицы, к которой происходит соединение;

- entity : string - закрытое поле, содержит имя присоединяемой таблицы;

- type : string - закрытое поле, содержит тип соединения таблиц (внешнее, внутреннее, левое, правое);

- scheme : array - закрытое поле, содержит схему таблиц для автоматического определения полей, по которым будет происходить соединение;

- reverse : bool - закрытое поле, указывает, соединять ли таблицы по идентификатору исходной или присоединяемой таблицы (в зависимости от направления связи один-ко-многим), направление соединения.

Методы класса Relation:

+ Relation(s : string, e : string, reverse : bool, t : int) - открытый конструктор, задает исходную таблицу, присоединяемую таблицу, направление соединения и тип соединения;

+ source() : string - открытый метод, возвращает имя исходной таблицы;

+ entity() : string - открытый метод, возвращает имя присоединяемой таблицы

+ applyScheme(scheme : array) - открытый метод, задает схему таблиц базы данных;

+ __toString() : string - метод преобразования объекта в строку, возвращает строку с частью запроса, отвечающую за соединение таблиц.

Filter

Класс Filter отвечает за задание условий выборки в запросах.

Поля класса Filter:

- fields : string[] - закрытое поле, словарь, ключом которого является имя поля, значением - массив, содержащий тип сравнения (точное совпадение, подстрока, вхождение в множество, строгие/нестрогие неравенства).

Методы класса Filter:

+ Filter(field : string, value : string, method : int) - открытый конструктор, задает один элемент в словаре значений - имя поля, значение, тип сравнения;

+ addField(params : array) - добавляет новое значение в словарь значений;

+ __toString() : string - метод преобразования объекта в строку, возвращает строку с частью запроса, отвечающую за задание условий выборки.

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

3.6 Возможности расширения приложения. Модули

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

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

Создание необходимых таблиц в базе данных.

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

На стадии загрузки модулей подмена существующих объектов контроллеров на созданные модулем.

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

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

Пример содержимого файла init.php:

<?

// Указание модулей, необходимых для работы

require_module('dependency1');

require_module('dependency2');

require_module('dependency3');

// Информация о модуле

$module = array(

'name' => 'Имя модуля',

'description' => 'Описание модуля'

);

// Подключение классов модуля

require('ThisModuleController.php');