Проектирование электронной картотеки
Диаграмма вариантов использования – отражает отношения между пользователями системы и возможными вариантами её использования.
Диаграмма вариантов использования новой системы включает в себя следующие группы актеров:
1. Пользователь;
2. Оператор;
3. Администратор системы;
Актеры системы могут выполнять определенные действия. Ниже перечислены основные из них:
– поиск, просмотр и печать карточек;
– создание и редактирование, удаление карточек;
– экспорт и импорт данных в базу данных картотеки;
– управление пользователями.
Актеры на диаграмме вариантов использования обозначаются значком человечка. Действия обозначаются овалом, внутри которого описан вариант использования системы.
Рис.1. UML диаграмма вариантов использования.
В системе предусмотрены три роли: пользователь, оператор и администратор. Пользователь имеет возможность просмотра некоторого определённого контента, поиску по данному контенту. Оператор выполняет основные функции по ведению картотеки: вносит новые записи, редактирует в случае необходимости или изменений существующие, также доступна функция удаления. Администратор системы обладает правами супер-пользователя, помимо уже перечисленных функций ему доступны глобальный экспорт и импорт данных в базу, а также создание и удаление новых пользователей.
Диаграмма классов – диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи с ними. Ниже показана структура базы данных с моделями.
|
|
|
Рис.2. ER -диаграмма базы данных.
Модели
На данной диаграмме изображены модели и взаимосвязи между ними.
Рассмотрим каждую модель:
– ProcessTechnology – Технологический процесс;
– CurrentProcessTechnology – Технологический процесс (обработка);
– WrittenOffProcessTechnology – Технологический процесс (списанный);
– Specification – Спецификация;
– CurrentSpecification – Спецификация (обработка);
– WrittenOffSpecification – Спецификация (списанная);
– User – Пользователь.
3.1.1.1 Технологический процесс
Модель «Технологический процесс» - реализует логику работы и управление данными по технологическим процессам.
3.1.1.2 Технологический процесс (обработка)
Модель «Технологический процесс (обработка)» - реализует логику работы и управление данными по технологическим процессам находящемся в обработке.
3.1.1.3 Технологический процесс (списанный)
Модель «Технологический процесс (списанный)» - реализует логику работы и управление данными по списанным технологическим процессам.
3.1.1.4 Спецификация
Модель «Спецификация» - реализует логику работы и управление данными по спецификациям.
|
|
|
3.1.1.5 Спецификация (обработка)
Модель «Спецификация (обработка)» - реализует логику работы и управление данными по спецификациям находящимся в обработке.
3.1.1.6 Спецификация (списанная)
Модель «Спецификация (списанная)» - реализует логику работы и управление данными по списанным спецификациям.
3.1.1.7 Пользователь
«Пользователь» - модель, отвечающая за логику и хранение данных, касающихся работника архива, и выполняющего ввод и коррекцию. Реализует ролевую систему прав доступа к управлению информацией внутри разрабатываемой ИС.
Особенность реализации вспомогательных моделей для «Технологического процесса» и «Спецификации» заключается в целесообразности избежать выделения колонки в основной таблице ТП, так как значение «в обработке» не является постоянным свойством. Тем самым нет необходимости хранить эти данные на протяжении всего жизненного цикла записи. Тоже самое и со списанием, не каждая запись списана или будет токовой, превалирующие большинство записей никогда не будет списано. Как следствие, если добавить колонки с информацией по списанию в «Технологический процесс», они почти все будут пустовать. Одновременно мы получаем раздельную логику работы с записями, описанную отдельными моделями, что способствует упрощению разработки, прозрачности понимания функционирования приложения.
|
|
|
Ниже приведён пример метода «search»контроллера ArchiveController.
def search
if params[:trigger_category] == 'sp'
@specifications = Specification.includes(:written_off_specification).references(:written_off_specification)
@specifications = @specifications.where("replace(specification, ' ', '') LIKE replace(?, ' ', '')", "%#{params[:search]}%" ) if params[:search] && !params[:search].empty?
@specifications = @specifications.where('cipher LIKE ?', "%#{params[:cipher]}%" ) if params[:cipher] && !params[:cipher].empty?
@specifications = @specifications.where('name LIKE ?', "%#{params[:name]}%" ) if params[:name] && !params[:name].empty?
@specifications = @specifications.where("replace(replace(replace(written_off_specifications.notification, ' ', ''), '-', ''), '.', '') LIKE replace(replace(replace(?, ' ', ''), '-', ''), '.', '') ", "%#{params[:notification]}%" ) if params[:notification] && !params[:notification].empty?
@specifications = @specifications.date_search('receipts_date', params[:min_receipts_date], params[:max_receipts_date]) if params[:min_receipts_date] =~ /\d\d\/\d\d\/\d\d\d\d/
@specifications = @specifications.date_search('correction_date', params[:min_correction_date], params[:max_correction_date]) if params[:min_correction_date] =~ /\d\d\/\d\d\/\d\d\d\d/
@specifications = @specifications.date_search('write_off_date', params[:min_write_off_date], params[:max_write_off_date]) if params[:min_write_off_date] =~ /\d\d\/\d\d\/\d\d\d\d/
respond_to do |format|
format.html{
@specifications = @specifications.order(:specification).page(params[:page]).per(20) #unless (params[:search] && params[:cipher] && params[:name])
}
format.pdf {
@specifications = @specifications.order(:specification).all
|
|
|
render "archive/search_list" if action_name == 'search_list'
}
end
else
# Иначе, по аналогии с СП, для ТП - @process_technologies
end
end
Рис. 3. Пример кода метода« search » контроллера ArchiveController .
Данный метод отвечает за фильтрацию и поиск спецификаций и технологических процессов, а так же вызов генерации отчётов в формате «pdf». Используется объектно-реляционный преобразователь ActiveRecord, параметры поиска хранящиеся в массиве «params» передаются в генератор запросов ActiveRecord, который преобразует их в SQL запрос к базе данных.
Соответственно форма поиска, которая управляется данным контроллером представленная на Рис 4. Форма карточек генерируемых в формате «pdf», для дальнейшей печати в картотеку представлена на Рис. 5.
Рис. 4. Пример формы поиска спецификаций и технологических процессов .
Рис. 5. Пример генерации карточек на печать в картотеку .
Проектирование сервера
Одна из наиболее эффективных связок технологий для развёртывания веб приложения на Ruby on Rails, это использование веб сервера Unicorn – для приложения, веб сервера nginx для внешних соединений.
Сервер приложений Unicorn
Unicorn – это производительный сервер приложений для Ruby. Принцип работы Unicorn таков: веб-сервер выполняет не все задачи, а только те, за которые отвечает непосредственно он, остальные задачи он передаёт другим программам, которые лучше справляются с их выполнением.
Главный процесс Unicorn порождает рабочие процессы для обработки запросов согласно заданным параметрам. Также этот процесс отслеживает рабочие процессы, чтобы предотвратить проблемы с ресурсами. То есть, если процесс требует много времени или ресурсов, сервер остановит его Unicorn.
Как говорилось раньше, Unicorn использует операционную систему для балансировки нагрузки; для этого он может передавать задачи другим сервисам. Благодаря этому запросы не скапливаются.
Обратный прокси-сервер Nginx
Nginx – это высокопроизводительный веб-сервер и обратный прокси-сервер. Nginx легковесный, простой в работе, его функции можно расширить с помощью плагинов. Благодаря своей архитектуре Nginx может обрабатывать огромное количество запросов.
Рис. 6. Схема организации работы сервера.
Список литературы
1. Интернет ресурс: www.rusrails.ru
2. Хел Фултон «Программирование на языке Ruby», М.: ДМК Пресс, 2013. – 688 с.
3. Хартл Майкл «Ruby on Rails для начинающих», М.: ДМК Пресс, 2017. – 572 с.
Дата добавления: 2019-07-15; просмотров: 173; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!