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

Продолжение таблица 2.3

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

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

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

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

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

физическая модель была построена для СУБД PostgreSQL.

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

газораспределительной компании.

22

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

СОБСТВЕННИКАМИ ЖИЛЬЯ РЕГИОНАЛЬНОЙ ГАЗООБЕСПЕЧИВАЮЩЕЙ КОМПАНИИ

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

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

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

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

23

Таблица 3.1 – Таблица Жилищный фонд

Таблица 3.2 – Таблица Жильцы

Таблица 3.3 – Таблица Тарифы

24

Таблица 3.4 – Таблица Показания

Таблица 3.5– Таблица Квитанция

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

25

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

Рисунок 3.2 – Результат создания справочника «Жилищный фонд»

Таблица «Жильцы» содержит информацию о жильцах, проживающих в жилищном фонде, а именно, их персональные данные, лицевой счет и тд.

Результат создания справочника представлен на рисунке .

Рисунок 3.3 – Результат создания справочника «Жильцы»

Таблица «Тарифы» содержит данные о тарифах за природный газ, а также о датах, на которые данные тарифы актуальны. Результат создания справочника представлен на рисунке 3.4.

Рисунок 3.4 – Результат создания справочника «Тарифы»

26

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

Рисунок 3.5 – Результат создания справочника «Показания» Таблица «Квитанция» содержит информацию об оплате каждым из

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

Рисунок 3.6 – Результат создания справочника «Квитанция»

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

27

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

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

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

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

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

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

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

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

Представление обеспечивает различные способы представления данных,

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

28

Рисунок 3.7 – Схема взаимодействия в архитектуре MVC

Самое очевидное преимущество, которое получается при использовании концепции MVC — это чёткое разделение логики представления (интерфейса пользователя) и логики приложения.

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

Помимо изолирования видов от логики приложения, концепция MVC

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

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

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

Webориентированная среда Ruby on rails относится к среде MVC. Для разработки элементов автоматизированной информационной системы были созданы 12 контроллеров, 7 моделей и 12 представлений. Схема взаимодействия этих компонентов представлена на рисунке 3.8.

29

Controllers

Views

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

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

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

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

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

30

Рисунок 3.9 – осуществление поиска жильцов по введенному адресу

На рисунке представлена блок-схема алгоритма проведения поиска по критерию.

Начало

Выбор критериев поиска

Конец

Рисунок 3.10 – Блок-схема осуществления поиска

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

31