Курсовые работы / ПРИС КП_10

Данная модель представлена диаграммой классов – нотацией UML-диаграмм

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

Выводы по второму разделу

В результате выполнения второго раздела курсового проекта был проведен анализ основных бизнес-процессов предметной области, формы входных и выходных документов, выявлены основные категории пользователей для которых разрабатывается система. На основе проведенного анализа было определено основное назначение системы и ее возможности. Также была определена цель и задачи разрабатываемой системы. После чего была определена структура и необходимый функционал информационной системы. Функциональная модель для автоматизируемого бизнес-процесса была построена по стандарту IDEF0. Для построения логической модели использовался стандарт IDEF1.X, а физическая модель была построена в нотации UML и представлена диаграммой классов.

Таким образом, в разделе был проведен анализ предметной области и бизнес-

процессов, на основе которого было проведено проектирование информационной системы.

22

3 РАЗРАБОТКА И ТЕСТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ АВТОМАТИЗАЦИИ УЧЕТА РАБОТЫ СОТРУДНИКОВ РЕГИОНАЛЬНОЙ

ТЕПЛОГЕНЕРИРУЮЩЕЙ КОМПАНИИ

3.1 Описание таблиц предметной области

Была поставлена задача разработать ИС для автоматизации учета работы сотрудников региональной теплогенерирующей компании по архитектуре клиент-

сервер [14]. При этом, в качестве СУБД была выбрана PostgreSQL, а в качестве инструментального средства проектирования используется фреймворк Ruby On Rails и язык программирования Ruby [15]. В ходе проектирования БД были созданы

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

Рисунок 3.1 – Схема данных

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

23

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

VidNarushenia содержит перечень нарушений. Описание полей таблиц представлено в таблицах 3.1 – 3.7.

Таблица 3.1 – Таблица Вид нарушения

Таблица 3.2 – Таблица Сотрудники

24

Таблица 3.3 – Таблица Графики

Таблица 3.4 – Таблица Нарушения сотрудников

Таблица 3.5 – Таблица Аварии

25

Таблица 3.6 – Таблица Пароль

Таблица 3.7 – Таблица Бригада

Каждая таблица содержит поля status и s_delete, эти поля необходимы для реализации многопользовательского режима работы системы [16]. Поля идентификатор, created_at и updated_as генерируются Ruby on Rails

самостоятельно. Наполнение информацией базы данных происходило с помощью миграций [17].

3.2 Дерево программных модулей

Фреймворк Ruby on Rails поддерживает структуру MVC приложений: Model

(модель) - View(представление) - Controller(контроллер). Приложения разбиваются на компоненты трех типов: модели, представления и контроллеры. Концепция

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

26

Модель отвечает за поддержку состояния приложения. Иногда это состояние является кратковременным, продолжающимся только на время нескольких взаимодействий с пользователем. А иногда состояние является постоянным и сохраняется вне приложения, чаще всего в базе данных. Модель — это не просто данные; в ней прописаны все правила, применяемые к этим данным (ограничения на значения и т.п).

Представление отвечает за формирование пользовательского интерфейса,

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

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

Взаимодействие этих трех элементов концепции представлено на рисунке

3.2, они же представляют собой модули программы.

Рисунок 3.2 – Архитектура MVC

В Rails-приложении входящий запрос сначала посылается маршрутизатору,

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

(называемый в Rails действием). Действие может искать запрошенные данные,

27

может взаимодействовать с моделью и может вызвать другое действие. В

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

которое создает изображение для пользователя.

3.3 Схемы взаимосвязей модулей и массивов данных

Как уже говорилось ранее Ruby on Rails относится к среде MVC.

Разрабатываемое приложение состоит из 16 контроллеров (1 системный, 4 для отчетов, остальные для справочников), 8 моделей и 16 представлений. Схема взаимосвязей этих компонентов представлена на рисунке 3.3 и 3.4 для отчетов.

Controllers

Sessions_controller.

admin_controller.rb

rb

home_page_control ler.rb

Models

Views

Рисунок 3.3. – Схема взаимосвязей модулей данных программы

28

Отчеты

Controllers

sdacha_exzamena_contr

all_avarii_controller.rb max_controller.rb sotrs_controller.rb oller.rb

Views

Рисунок 3.4. – Схема взаимосвязей модулей данных отчетов

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

Стоит отметить, что для всех отчетов отсутствует модуль Model, все ограничения прописаны в модуле View.

3.4 Алгоритм работы модуля информационной системы

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

представленный в листинге 3.1 переводит переменную в формат даты (Date.civil).

Где каждый параметр селектора даты переводится в числовой тип

(params[:start]["written_on(1i)"].to_i). written_on(1i) – означает, что из селектора даты берется компонент года, written_on(2i) – компонент месяца, written_on(3i) –

29

компонент дня. После чего извлекается нужный компонент (месяц или день) –

командой .month или .day.

Листинг 3.1 – Текст контроллера отчета

class AllAvariiController < ApplicationController def index

end

def search

@month_s = Date.civil(params[:start]["written_on(1i)"].to_i,params[:start]["written_on(2i)"].to_i, params[:start]["written_on(3i)"].to_i).month

@day_s = Date.civil(params[:start]["written_on(1i)"].to_i,params[:start]["written_on(2i)"].to_i, params[:start]["written_on(3i)"].to_i).day

@month_f = Date.civil(params[:finish]["written_on(1i)"].to_i,params[:finish]["written_on(2i)"].to_i, params[:finish]["written_on(3i)"].to_i).month

@day_f = Date.civil(params[:finish]["written_on(1i)"].to_i,params[:finish]["written_on(2i)"].to_i, params[:finish]["written_on(3i)"].to_i).day

end end

Код представления, который отображен в листинге 3.2, отвечает за страницу,

в которой пользователь вводит промежуток времени за который он хочет вывести отчет. Тег date_select имеет конструкцию date_select(object_name, method, options =

{}, html_options = {}), который возвращает набор выбранных тегов (один за год,

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

(идентифицированного объектом) [19].

В данном случае выбран метод written_on. Также прописана опция discard_year, которая имеет значение true, означающая, что в селекторе не будет отображаться тег для года. Для передачи переменных :start, :finish в запрос необходимо преобразовать их тип и извлечь выбранные месяц и число, что было сделано в контроллере.

Листинг 3.2 – Текст представления (index) отчета

<h1>Отчет об авариях</h1>

<%= link_to 'Главная страница', controller: 'home_page' %>

<%= form_tag("search", method: "get") do %>

<%= label_tag(:start, "Введите начальную дату:") %>

<%= date_select(:start, "written_on", discard_year: true) %> <br><br>

30

<%= label_tag(:finish, "Введите конечную дату:") %>

<%= date_select(:finish, "written_on", discard_year: true) %> <%= submit_tag("Искать") %>

<% end %>

После того, как пользователь введет необходимую дату, он нажимает на кнопку «Искать», которая вызывает форму поиска. Код формы для поиска представлен в листинге 3.3. Данная форма является основной для отчета. В ней содержится SQL-запрос к базе данных с помощью команды find_by_sql, а команда date_part извлекает необходимую часть даты (год, месяц или день) и является командой postgresql. Данный код представляет собой цикл, который возвращает массив объектов модели из результирующего множества.

Листинг 3.3 – Текст представления (search) отчета

<h1>Отчет об авариях</h1>

<%= link_to 'Главная страница', controller: 'home_page' %><br><br> <table border="1">

<th>Бригада</th> <th>Вид ремонта</th> <th>Результат </th> <th>Дата</th>

<%= Avarii.find_by_sql(["select avariis.brigada_id, avariis.vidremonta, avariis.result, avariis.data from avariis where date_part('month', avariis.data) >= ? and date_part('day', avariis.data) >= ? and date_part('month', avariis.data) <= ? and date_part('day', avariis.data) <= ?", @month_s, @day_s, @month_f, @day_f]).each do |avarii| %>

<tr>

<td><%= avarii.brigada_id %></td> <td><%= avarii.vidremonta %></td> <td><%= avarii.result %></td> <td><%= avarii.data %></td>

</tr> <% end %>

Таким образом, блок-схема алгоритма работы отчета обо всех авариях

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

31