Разработка модуля организации электронного документооборота для ЗАО "Флант"

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

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

Правительство Российской Федерации

Федеральное государственное автономное образовательное учреждение

высшего профессионального образования

«Национальный исследовательский университет
«Высшая школа экономики»

Факультет Информационных технологий и вычислительной техники

Специализация «Компьютерные мультисреды»

Кафедра ИКТ

ДИПЛОМНЫЙ ПРОЕКТ

«Разработка модуля организации электронного документооборота для ЗАО «Флант»

Выполнил Студент группы № С-105

Ненароков Серафим Дмитриевич

Научный руководитель

Кондрашов Сергей Владимирович

Консультант

Столяров Дмитрий Олегович

Москва, 2013



Аннотация

В данной дипломной работе спроектирована и реализована система электронного документооборота, впоследствии используемая в двух проектах ЗАО «Флант». Проведен анализ требований, описаны используемые технологии и процесс реализации, собраны данные о результатах внедрения разработанного продукта.

электронный документ фреймворк маршрутизация



Оглавление

Введение

1. Обзорно-аналитическая часть

1.1 Анализ требований к модулю электронных документов

1.1.1 Сущность документа

1.1.2 Зависимости и конфликты

1.1.3 Состояния документов

1.1.4 Прикрепленные файлы и генерирование печатных версий

1.1.5 Нумерация документов

1.2 Обзор альтернативных решений

1.2.1 Flagship Docs

1.2.2 Microsoft SharePoint

2. Технологическая часть

2.1 Обзор паттерна MVC

2.2 Обзор фреймворка Ruby on Rails

2.2.1 MVC в Ruby on Rails

2.2.2 Модель: объектно-реляционное отображение (ORM) и ActiveRecord

2.2.3 Ruby on Rails и базы данных

2.2.4 Миграции

2.2.5 Вид

2.2.6 Контроллер

2.2.7 Маршрутизация

2.2.8 Тестирование

2.2.9 Структура исходных файлов приложения на Ruby on Rails

2.2.10 Работа Rails приложения в общем виде

2.3 Обзор системы управления версиями файлов Git

2.3.1 Общие сведения о системах контроля версий

2.3.2 Subversion

2.3.3 Git

2.3.4 Сравнение Git и SVN

2.3.5 Репозиторий GitHub

3. Разработка

3.1 Разработка модели модуля с учетом архитектурных решений

3.1.1 Полиморфные связи

3.1.2 Наследование с единой таблицей (Single Table Inheritance)

3.1.3 Сериализация полей

3.1.4 Вложения к документам

3.1.5 Генерация pdf

3.1.6 Дополнительная логика: нумерация, состояния, зависимости, конфликты

3.1.7 Диаграмма классов

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

3.3 Тестирование модуля

3.4 Создание gem-пакета модуля для распространения

3.5 Расширение функциональности модуля внутри конкретного приложения

3.6 Перспективы разработки

4. Экспериментальная часть

4.1 Оценка соответствия системы техническому заданию

4.2 Публикация исходного кода модуля в открытый репозиторий (github)

4.3 Сбор отзывов и статистики по использованию модуля

5. Охрана труда

5.1 Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей

5.2 Визуальные эргономические параметры. Средства измерения

5.2.1 Параметры полей, средства их измерения

5.2.2 Проведение измерений, соблюдение требований безопасности

5.2.3 Измерения. Методы

Заключение



Введение

Актуальность

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

Цель

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

Модуль должен быть универсальным и интегрироваться в приложения, основанные на среде Ruby on Rails.

Задачи

В данной работе были решены следующие задачи:

1) Исследование существующих решений на предмет возможности их внедрения;

2) Выбор инструментария для разработки и сопровождения модуля;

3) Разработка модуля для управления документами;

4) Внедрение модуля в веб-приложение;

5) Апробация.

Практическая значимость

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

Апробация

На данный момент разработанный модуль внедрен и функционирует в системе управления колл-центром ООО «СВ-КАРТ» в г. Обнинске Калужской области РФ и находится на стадии внедрения в систему управления таксомоторной компании ООО «Сити-Мобил».



1. Обзорно-аналитическая часть

1.1 Анализ требований к модулю электронных документов

1.1.1 Сущность документа

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

Документ представляет собой объект, содержащий следующий данные:

1) ссылка на объект, к которому он относится;

2) значения полей;

3) один или несколько присоединенных файлов.

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

1.1.2 Зависимости и конфликты

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

Каждому объекту, содержащему документы, необходима возможность задать типы возможных документов, характер их конфликтов и зависимостей.

Пример. Объект «Сотрудник» может содержать документы типа «Паспорт», «ИНН» и «Трудовой договор», либо «Гражданско-правовой договор». Ни один из договоров не может быть добавлен, пока не добавлены документы типа «Паспорт» и «ИНН». В то же время если активизирован «Трудовой договор», то «Гражданско-правовой договор» уже не может быть добавлен и наоборот. Первый случай представляет собой зависимости документов, второй -- конфликты.

1.1.3 Состояния документов

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

• Черновик (документ, созданный пользователем, но не активный):

1) можно редактировать;

2) можно безвозвратно удалить;

3) можно активизировать.

• Активный (активизированный черновик):

1) нельзя редактировать;

2) можно клонировать (создать копию со статусом «черновик»);

3) можно деактивировать;

4) нельзя безвозвратно удалить.

• Деактивированный:

1) можно клонировать;

2) нельзя безвозвратно удалить;

3) нельзя активировать.

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



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

1.1.4 Прикрепленные файлы и генерирование печатных версий

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

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

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

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

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

1.1.5 Нумерация документов

Многие документы должны поддерживать нумерацию внутри организации. Примером могут послужить трудовые договоры.

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



1.2 Обзор альтернативных решений

В настоящее время существует множество систем управления информационными ресурсами предприятия (ECM - Enterprise content management ), предназначенных для решения широкого спектра задач, связанных с управлением информационными ресурсами на предприятии. Частью такого комплекса является система управления документами (DMS -- Document management system). Основное ее назначение: хранение и отслеживание электронных документов и/или их образов. Такие системы часто предоставляют следующие сервисы:

1) метаданные -- дополнительная информация, хранимая вместе с файлами документов;

2) интеграция -- инструменты для организации взаимодействия DMS с другим ПО;

3) захват -- автоматическое сканирование документов. При этом есть возможность перевода изображения в текст с помощью систем OCR и сохранения текстовых данных сканированного документа в метаданные;

4) индексация -- создание индекса, основанного на метаданных документов, для облегчения процесса поиска и классификации;

5) хранение -- создание хранилища электронных документов и управление ими;

6) распространение -- организация удобного доступа к документам определенному кругу лиц, публикация документа в нужном формате;

7) безопасность -- определение прав доступа к документам, защита закрытых документов от несанкционированного использования;

8) документооборот -- организация жизненного цикла документа;

9) контроль версий документа.

Многие системы управления документами не имеют полного спектра приведенных выше сервисов.

В процессе исследования не было найдено модулей для Ruby on Rails, полностью удовлетворяющих требованиям. Были рассмотрены решения, частично подходящие для решения задачи.

1.2.1 Flagship Docs

Flagship Docs представляет собой популярную систему управления документами, разработанную компанией RPI Web Tech Group. Данная система решает широкий спектр задач, таких как хранение, управление, поиск по большому количеству документов, а также управление правами пользователей на документы. Система открыта и распространяется под лицензией MIT.

Главный недостаток системы Flagship Docs в контексте поставленной задачи -- отсутствие требуемой функциональности. Система эффективно управляет, структурирует и индексирует загруженные на сервер документы в разных форматах. Гибкое управление метаданными, организация логики документооборота выходит за рамки возможностей программы. Данная система также не подходит для решения задачи из-за ее распространения в виде отдельного Ruby on Rails приложения, что затруднит интеграцию в систему.

1.2.2 Microsoft SharePoint

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

1) инструменты для гибкой настройки логики обращения документов;

2) средства поиска документов;

3) средства классификации документов;

4) архивацию устаревших документов;

5) шифрование данных;

6) гибкую систему прав.

Компоненты документооборота, входящие в состав SharePoint, обладают рядом недостатков. Продукты являются платными: в условиях ограниченного бюджета использование этих продуктов неприемлемо. Помимо этого, они ограничивают выбор программных платформ: SharePoint зависим от других продуктов Microsoft. Разрабатывать интерфейс для взаимодействия Ruby on Rails и SharePoint дороже и сложнее, чем разработать модуль, удовлетворяющий требованиям.

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

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



2. Технологическая часть

2.1 Обзор паттерна MVC

Впервые описал схему Model-view-controller (Модель-вид-контроллер) Трюгве Реенскауг, норвежский ученый из университета в Осло, работавший в 1979 году над объектно-ориентированным языком программирования Smalltalk. Строго говоря, MVC является не паттерном, а схемой использования нескольких паттернов проектирования приложений.

Схема MVC состоит из объектов трех типов: модели, вида и контроллера.



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

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

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

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

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

Наблюдатель - поведенческий шаблон проектирования, предназначенный для создания зависимости между одним и несколькими объектами таким образом, что при изменении состояния основного меняется состояние зависимых. В MVC это реализуется в представлении и модели: при изменении модели меняются все её виды.

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

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

Подход MVC нашел широкое применение в веб-программировании на различных современных языках. Схема MVC породила семейство веб-фреймворков, использующих её в качестве основной архитектуры. Среди них можно выделить Ruby on Rails, Yii, Symfony, Zend Framework, Django и многие другие.

2.2 Обзор фреймворка Ruby on Rails

Сайт: http://www.rubyonrails.ru/

Веб-фреймворк Ruby on Rails разработан на языке Ruby и является вторым по популярности по версии http://hotframeworks.com.

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

2.2.1 MVC в Ruby on Rails

Как было сказано выше, Ruby on Rails является MVC-фреймворком и навязывает разработчику структуру приложения. Написание программы в общем случае сводится к созданию модели данных, реализации в ней бизнес-логики, разработке шаблонов (видов) для моделей и написанию контроллеров, определяющих логику взаимодействия модели, шаблонов и пользователя. Рассмотрим эти процессы подробнее.

2.2.2 Модель: объектно-реляционное отображение (ORM) и ActiveRecord

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

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

Для разных языков существуют различные библиотеки для реализации технологии ORM, такие как Propel, Doctrine (для PHP), Hibernate (Java), SQLAlchemy (Python) и Sequel (Ruby).

Ruby on Rails предоставляет разработчику модуль ActiveRecord -- реализацию одноименного шаблона проектирования для создания объектно-реляционного отображения. ActiveRecord тесно интегрируется со средой Rails и выполняет ряд дополнительных функций, таких как проверка приемлемости данных, извлечение данных из веб-форм.

Class Employee < ActiveRecord::Base

end

employee = Employee.find(1)

employee.name = 'Ivan'

employee.save

В приведенном примере создается класс, наследуемый от базового класса ActiveRecord. Подразумевается, что в базе данных создана таблица employees, с такими полями как id и name. Ниже создается экземпляр класса, получаемый методом find класса Employee, при этом создается неявный запрос к базе:

SELECT `employees`.* FROM `employees` WHERE `employees`.`id` = 1 LIMIT 1

2.2.3 Ruby on Rails и базы данных

Среда Rails поддерживает работу с большинством современных баз данных, таких как MySQL, SQLite, PostgreSQL. Для этого используются различные адаптеры, встроенные в среду Rails и определяемые в конфигурационном файле config/database.yml. Адаптеры позволяют ActiveRecord формировать различные запросы в зависимости от используемой БД, но формируемые одним и тем же объектно-ориентированным кодом.



2.2.4 Миграции

Для удобной манипуляции со структурой базы данных без использования SQL, а также для хранения истории изменения струкруты БД в процессе разработки (и особенно последующей доработки) приложения модуль ActiveRecord фреймворка Ruby on Rails предоставляет систему миграций.

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

Пример консольной команды для создания миграции:

>ralils generate migration create_employees

При этом в каталоге db/migrate будет создан файл с именем

20130315000001_create_employees.rb

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

Миграция представляет собой файл с кодом на языке Ruby, имплементирующий подкласс класса ActiveRecord::Migration. В классе могут быть переопределены следующие методы:

1) up() -- выполняется при запуске миграции;

2) down() -- выполняется при отмене (rollback) миграции;

3) change() -- выполняется при запуске миграции, не нуждается в классе down(), последовательность действий для отмены миграции определяется ActiveRecord автоматически, исходя из действий, описанных в change().

Основные команды для запуска созданной миграции:

1) > rake db:migrate -- запускает очередь миграций на выполнение;

2) > rake db:rollback -- отменяет последнюю выполненную миграцию.

Исходный код миграции, созданной выше, может быть таким:

class CreateEmployees < ActiveRecord::Migration

 def change

 create_table :employees do |t|

 t.integer :age

 t.string :first_name

 t.string :last_name

 end

 end

end

В коде переопределяется метод change базового класса. В нем вызывается метод create_table(), которому передается название таблицы и блок, в котором вызываются методы, определяющие типы данных полей. Этим методам передаются соответствующие названия создаваемых полей. Метод create_table создает в таблицу и вызывает блок, в котором происходит создание полей таблицы. В результате генерируется SQL запрос следующего вида:

CREATE TABLE `employees` (`id` int(11) DEFAULT NULL auto_increment PRIMARY KEY, `age` int(11), `first_name` varchar(255), `last_name` varchar(255)) ENGINE=InnoDB

Как видно из запроса, фреймворк по соглашению автоматически создает поле id, т. к. оно необходимо в большинстве случаев. Чтобы переопределить данное поведение, необходимо добавить опцию «:id => false» в вызов метода create_table().

2.2.5 Вид

Представления в Ruby on Rails реализованы в виде erb-шаблонов -- html-файлов со вставками кода на языке Ruby. Дополнительная логика, внедряемая в шаблон, позволяет сделать его динамичным, однако злоупотреблять внесением кода в виды не рекомендуется, т. к. основная задача представления -- отображение состояния модели и вывод интерфейса для взаимодействия с пользователем.

Перед отправкой ответа на запрос пользователя erb-шаблоны проходят процесс рендеринга с помощью встроенного шаблонизатора ERB (Extended Ruby): выполняется код, внедренный в шаблон, и формируется статичный html-файл, возвращаемый пользователю. Стоит отметить, что помимо встроенного шаблонизатора, можно использовать большое количество альтернативных сторонних продуктов, таких как eRuby, Tenjin и другие.

Как было сказано выше, код шаблона не должен содержать слишком много логики. Но в то же время бывают ситуации, когда большой объем кода необходим. Ruby on Rails представляет эффективный механизм сокращения кода: «помощники» (helpers). Хелпер представляет собой метод, реализуемый программистом в отдельном rb-файле, к которому получают доступ все шаблоны. В общем случае хелпер принимает объект модели и возвращает представлению html-код в виде строки. Это позволяет заменить несколько строк кода, формирующие корректное отображение модели, на вызов одного метода. Помимо повышения удобочитаемости кода реализуется принцип DRY (don't repeat yourself), призывающий избегать повторения кода: один и тот же хелпер зачастую вызывается в разных представлениях.

2.2.6 Контроллер

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

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

2.2.7 Маршрутизация

Rails предоставляет гибкий механизм маршрутизации. Он предназначен для задания соответствия URL и типа запроса контроллерам и действиям. В общем случае структура URL действия контроллера имеет следующий вид:

http://адрес_сайта/имя_контроллера/имя_действия

Например, запрос http://localhost/users/show вызовет действие show контроллера UsersController.

В файле routes.rb можно назначить определенным структурам запроса вызовы нужных действий контроллеров.

2.2.8 Тестирование

С запуска нового проекта на Rails среда создает для него всю необходимую тестовую инфраструктуру. Фреймворк поддерживает следующие виды тестов:

1) блочные тесты -- исследуют отдельные модели проекта в изоляции. Заготовки создаются автоматически при добавлении новой модели в приложение;

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

3) интеграционные тесты -- используются для исследования взаимодействия любого количества контроллеров приложения. Создаются вручную специальным запросом (rails generate integration_test имя_теста);

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

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

2.2.9 Структура исходных файлов приложения на Ruby on Rails

На рис. 4 представлена типичная структура каталогов приложения Ruby on Rails. Ниже описывается предназначение каждого из каталогов.

1) app/ -- содержит исходные коды основных частей приложения: моделей, видов и контроллеров;

1. assets/ -- содержит изображения, файлы JavaScript и таблицы стилей CSS, используемые видами приложения;

2. controllers/ -- содержит исходные коды контроллеров;

3. helpers/ -- в этой папке хранятся т. н. «помощники»;

4. models/ -- каталог для хранения исходников, описывающих модели приложения;

5. views/ -- виды приложения;

2) config/ -- хранит параметры конфигурации приложения, в т.ч. настройки подключения к базе данных (в файле database.yml), маршрутизации (routes.rb);

3) db/ -- содержит схему моделей, хранящихся в базе данных (файл schema.rb) и файлы миграций;

4) doc/ -- файлы автоматически сгенерируемой документации приложения;

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

6) public/ -- каталог, доступный извне при запуске приложения, содержит статичные файлы. Чаще всего содержит изображения, шаблоны страниц 404 ошибки и прочее;

7) script/ -- различные вспомогательные сценарии приложения (например, сценарий «разворачивания» приложения, запуска сервера и прочее);

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

9) tmp/ -- временные файлы, создаваемые в процессе работы приложения;

10) vendor/ -- любой сторонний импортированный код.

2.2.10 Работа Rails приложения в общем виде

На рис. 4 представлена схема работы Rails-приложения. Рассмотрим её подробнее:

1) клиент из браузера посылает запрос на сервер;

2) запрос обрабатывается механизмом маршрутизации, который определяет его тип (GET, PUT, POST, DELETE и т. д.) и структуру URL;

3) маршрутизатор вызывает действие контроллера, соответствующее запросу;

4) экшн (действие) контроллера взаимодействует с моделью, выполняя над ней определенные операции, меняя её состояние, либо получая её параметры;

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

6) действие возвращает пользователю сформированный html-файл.

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

2.3 Обзор системы управления версиями файлов Git

2.3.1 Общие сведения о системах контроля версий

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

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

Системы контроля версий условно можно разделить на два типа: централизованные и распределенные (DRCS - Distributed revision control systems). В централизованной системе документы управляются единым сервером-хранилищем, предоставляющим пользователям интерфейс для работы с файлами и их версиями. В распределенной же системе вся история изменений хранится в локальных хранилищах на каждом из компьютеров пользователей.

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

На данный момент наиболее популярными системами контроля версий являются централизованная Subversion (SVN) и распределенная Git. Ниже рассмотрены основные особенности каждой из систем.

2.3.2 Subversion

Сайт: http://subversion.apache.org/

Subversion -- централизованная система контроля версий, распространяемая под свободной лицензией (Apache License). Система приобрела широкую известность в кругу разработчиков свободного ПО. Ниже приведен краткий список известных проектов, использующих SVN:

1) Python;

2) Ruby;

3) Apache;

4) FreeBSD;

5) GCC;

6) Blender;

7) Boost;

8) Tor.

Систему SVN поддерживают такие известные хостинги проектов, как Google Code (https://code.google.com), SourceForge (http://sourceforge.net/) и многие другие.

Основные возможности системы контроля версий Subversion:

1) хранение полной истории изменения файлов в централизованном хранилище;

2) поддержка разветвления истории файла при его копировании: история скопированного файла может иметь общую часть с оригиналом;

3) поддержка ветвления: создание и слияние ветвей (branches);

4) наличие библиотек для работы с SVN для популярных языков программирования (Java, Python, PHP);

5) возможность зеркалирования хранилища.

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

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



2.3.3 Git

Git -- распределенная система контроля версий, разработанная создателем ядра Linux Линусом Торвальдсом в 2005 году. Система быстро набрала популярность и сейчас используется в таких проектах, как:

1) ядро Linux;

2) Ubuntu;

3) Android;

4) Chromium;

5) PHP;

6) Symfony;

7) jQuery.

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

Ниже перечислены основные особенности Git:

1) быстрое и удобное разделение и слияние версий;

2) каждому разработчику предоставляется локальная копия всей истории разработки;

3) эффективная поддержка больших проектов, хорошая масштабируемость;

4) безопасность: идентификатор ревизии зависит от всей предыдущей истории. После публикации коммита (новой ревизии) нельзя изменить старые версии;

5) поддержка гибкого управления историей изменений. Поддержка нескольких стратегий объединений конфликтных файлов;

6) система сбора мусора: автоматическая очистка неактуальных файлов после отмены изменений.

Ядро Git представляет собой лишь набор утилит командной строки для манипуляции с ревизиями файлов. Все параметры хранятся в конфигурационных файлах, это облегчает разработку и портирование инструментов для работы с Git. Утилиты Git спроектированы таким образом, чтобы обеспечить максимальное удобство при использовании в скриптах, что позволяет создавать производные системы контроля версий на основе Git.

Ниже приведен краткий набор базовых команд для работы с Git:

1) git clone адрес_репозитория -- создает локальную копию репозитория;

2) git add имя_объекта -- добавляет файл/папку в контроль версий;

3) git rm имя_объекта -- удаляет файл/папку из контроля;

4) git commit -- создает локальный коммит (ревизию);

5) git pull -- получает файлы, измененные в результате коммитов в удаленном репозитории;

6) git push -- отправляет созданный коммит в репозиторий;

7) git checkout имя_ветви -- переключается между ветвями репозитория;

8) git log -- отображает историю ревизий с комментариями разработчиков;

9) git status -- отображает информацию о состоянии локальной копии репозитория.

2.3.4 Сравнение Git и SVN

Аргументы в пользу Subversion:

1) централизованность системы позволяет не хранить на компьютере весь репозиторий, а лишь срез репозитория -- конкретную версию;

2) наличие удобного и хорошо развитого инструмента TortoiseSVN, предоставляющим графический интерфейс в Windows;

3) разработчики отмечают лучшую интеграцию SVN в графические IDE.

Аргументы в пользу Git:

1) для доступа к истории версий нет необходимости иметь сетевое подключение;

2) репозиторий не зависит от сбоев в работе сервера. На компьютере каждого из клиентов содержится полностью независимая копия репозитория;

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

4) производительность: наблюдается значительный прирост в скорости работы по сравнению с SVN.

Как видно из сравнения, Git опережает SVN по быстродействию и гибкости. А проблема нехватки дискового пространства не столь критична на современном компьютере. Помимо прочего, критичным для разработки больших приложений на Ruby on Rails является сохранение приемлемых параметров быстродействия при значительном увеличении объема исходного кода.

2.3.5 Репозиторий GitHub

Еще одна причина выбрать git в качестве системы контроля версий -- сильное и профессиональное сообщество, возникшее на сайте GitHub (https://github.com/) -- веб-сервисе для хостинга проектов и их совместной разработке. Данный ресурс может служит местом для привлечения новых разработчиков к проекту.



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

GitHub стал негласным стандартом для большинства Ruby on Rails разработчиков. Сам фреймворк разрабатывается также на GitHub. На этом хостинге размещают официальные репозитории следующие проекты:

1) Facebook;

2) Twitter;

3) Yahoo;

4) Perl;

5) jQuery;

6) Prototype.

Как следует из слогана хостинга («Social Coding» или «Пишем код вместе»), основной упор сделан именно на социализацию процесса разработки, краудфайндинг для открытых продуктов.

У каждого пользователя может быть несколько проектов. Другие пользователи могут копировать проекты в свой аккаунт (fork), дорабатывать и предлагать автору проекта внести их изменения в официальный репозиторий (pull request).

GitHub имеет удобный веб-интерфейс для работы с git-репозиторием, поддержку чтения исходного кода, сравнения ревизий, поиска по репозиторию напрямую в браузере. После регистрации и создания/форка первого проекта пользователь может скопировать новый репозиторий в локальное хранилище на ПК, занимаясь разработкой локально. После внесения изменений в код, программист может создать новую ревизию (git commit) и отправить изменения на сервер GitHub (git push).

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

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

GitHub поощряет разработку open source проектов. Это выражается в невозможности создать закрытый репозиторий при бесплатном аккаунте пользователя.

Git был выбран в качестве системы контроля версий не только ввиду того, что он является гибкой распределенной альтернативой SVN, но и благодаря Ruby-сообществу, возникшему вокруг сайта GitHub. Проект SimpleDocuments изначально планировался как открытый модуль. Размещение репозитория на GitHub, во-первых, решит проблему организации хостинга (не будет нужды в дополнительном корпоративном репозитории), во-вторых, будет способствовать развитию: есть вероятность того, что проект будет интересен другим разработчикам, которые помогут улучшить код, дополнить его новым функционалом.



3. Разработка

3.1 Разработка модели модуля с учетом архитектурных решений

3.1.1 Полиморфные связи

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

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

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

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

Как видно из диаграммы, для идентификации записи в произвольной таблице сущности documents достаточно иметь внешний ключ (documentable_id) и имя этой таблицы (documentable_type).

В разрабатываемом приложении полиморфная связь использована для реализации моделей документа (document) и вложения (attachment).

3.1.2 Наследование с единой таблицей (Single Table Inheritance)

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

Для решения это проблемы обычно используется паттерн проектирования STI (Single Table Inheritance). Основной смысл заключается в добавлении к таблице БД строкового поля type, в котором хранится название класса. При получении записи будет создаваться объект класса, указанного в поле type. Ruby on Rails поддерживает данную технологию.

Реализация STI в разрабатываемом приложении сводится к внесению в миграцию создания таблицы documents строкового поля «type» и наследованию конкретных классов документов (например, Passport) от суперкласса Document (который и связан с таблицей documents).

Ниже проиллюстрирован пример работы STI.

1) Создается подкласс: class Passport < Document # помещается любая специфичная логика end

2) Создается объект конкретного класса passport = Passport.new Объект сохраняется passport.save

3) В базе данных в таблице documents при этом создается запись следующего вида:

id	type
1	Passport

4) Если требуется получить документ с id = 1, выполняется команда doc = Document.find(1)

5) Rails анализирует поле type таблицы и помещает в переменную doc объект типа Passport.

3.1.3 Сериализация полей

Документ может содержать произвольное количество полей различных типов (номер, имя, фамилия, отчество и т. д.). Программист, реализующий наследников класса Document, сам определяет набор, названия и логику заполнения полей. Очевидным становится невозможность хранения каждого поля в отдельном столбце таблицы documents. Разумное решение проблемы -- использование механизма сериализации, который также поддерживается средой Ruby on Rails.

Сериализация позволяет сохранять произвольную структуру языка Ruby (в частности, хеш) в строковое поле таблицы БД для последующего её извлечения.

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

Каждому полю добавлены методы доступа (getter и setter) для удобной работы с экземпляром класса. Методы реализованы таким образом, что с точки зрения конечного программиста работа ведется с отдельными атрибутами объекта, а с точки зрения класса -- с одним и тем же полем data.

Пример.

1) Создается класс-наследник с единственным полем number: class Inn < Document document_field :number #добавление поля end

2) Создается объект класса, инициализируется единственное поле, и из него извлекается значение: doc = Inn.new doc.number = 12345678 #сеттер для инициализации print doc.number #геттер для получения значения >> 12345678

Пример показывает, что программист работает с полями документа, как с обычными атрибутами. Однако методы доступа сохраняют и извлекают значения из хеша, хранимого в атрибуте data, сериализуемом и проецируемом на одноименное поле в таблице documents базы данных.

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

{:number => 12345678}

3.1.4 Вложения к документам

Для реализации вложенных файлов было принято решение использовать сторонний гем paperclip (https://github.com/thoughtbot/paperclip). Он позволяет организовать хранение загруженных файлов, управление размерами изображений, а также связь изображений и объектов.

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

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

3.1.5 Генерация pdf

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

Было решено использовать дополнительный абстрактный класс Agreement, наследник класса Document. В данном классе была реализована логика генерации pdf-файлов при сохранении документа.

Конкретные классы договоров наследуются от класса Agreement и должны переопределить метод fields_to_replace, в котором формируется хеш вида {:имя_поля => значение}. Т. к. документ имеет доступ как к объекту, к которому относится, так и к любым другим документам, то в хеш могут быть собраны практически любые необходимые данные (в трудовом договоре это могут быть паспортные данные владельца, номер ИНН и пр.)

После сохранения документа вызывается метод generate_attachment, унаследованный от класса Agreement. Метод проводит поиск odt-шаблона документа в папке app/agreement_templates/ и, в случае успеха, создает временную копию найденного шаблона. В ней производится следующая обработка:

1) вызов метода fields_to_replace с целью получения хеша значений для замены;

2) поиск лексем вида «[ИМЯ_ПОЛЯ]» в шаблоне и замена вхождений значениями из хеша;

3) вызов консольной команды libreoffice для конвертации полученного odt-файла в pdf;

4) приложение pdf в виде вложенного файла к документу;

5) удаление временного odt-файла.

Для обработки odt был использован сторонний гем ODFReport.

Каждому классу, наследующемуся от Agreement, необходимо создать одноименный odt-файл в каталоге app/agreement_templates/.

3.1.6 Дополнительная логика: нумерация, состояния, зависимости, конфликты

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

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

1) находит документ типа своего класса с максимальным номером;

2) инкрементирует это значение;

3) присваивает полученное значение атрибуту number, если он еще не инициализирован.

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

Для реализации механизма состояний в модель документа введен атрибут state и были определены его возможные значения ('DRAFT' -- черновик, 'ACTIVE' -- активный, 'DELETED' -- удаленный). При создании документа вызывается метод set_default_state, устанавливающий статус 'DRAFT'. Также реализованы методы для активации (activate!) и деактивации (deactivate!) документа. В них заложена логика переходов одного состояния документа в другое.

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

1) dependencies -- имена классов, от которых зависит текущий класс;

2) conflicts -- имена классов, которые конфликтуют с текущим классом.

У каждого документа есть метод savable?, определяющий, может ли он быть сохранён. Метод является ключевым в логике работы документа, в нем проверяются зависимости, конфликты, состояние документа. Документ может быть признан сохраняемым только после успешного прохождения всех проверок.



Описанную выше логику иллюстрирует UML-диаграмма активации документа, представленная на рисунке.

3.1.7 Диаграмма классов

Ниже представлена диаграмма классов в разработанном модуле.

Конкретные классы названы в диаграмме именами конкретных документов (паспорт, ИНН, трудовой договор).

Сущность, содержащая документы, названа Employee (Сотрудник).

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

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

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

Контроллер, однако, универсален для всех документов и предоставляется модулем.

Ниже приведены предоставляемые действия контроллера:

1) show -- отображение содержимого документа на странице;

2) new -- страница создания нового документа;

3) create -- создание документа. Документ сохраняется в БД в случае возможности создания, выводится сообщение об ошибке в противном случае. При успешном создании происходит перенаправление на страницу просмотра документа, в противном случае -- на действие new;

4) edit -- открывает форму редактирования документа, в случае, если это возможно. Иначе происходит перенаправление на страницу списка документов;

5) update -- аналогичен методу create, применяется для обновления документа из действия edit;

6) clone -- клонирует указанный документ, перенаправляет на страницу создания нового документа с полями, заполненными значениями старого документа;

7) deactivate -- деактивирует документ, если это возможно. Перенаправление на страницу списка документов с сообщением об ошибке в противном случае;

8) destroy -- безвозвратное удаление документа в случае, если это возможно.

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

3.3 Тестирование модуля

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

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

3.4 Создание gem-пакета модуля для распространения

Существует несколько способов расширения функциональности приложений на Ruby on Rails.