Разработка автоматизированного средства генерации отчетов Сетелем Банк ООО

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

Федеральное агенство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

“Поволжский государственный университет телекоммуникаций и информатики”

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

Направление Информатика и вычислительная техника

Кафедра Программного обеспечения и управления в технических системах

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(БАКАЛАВРСКАЯ РАБОТА)

Разработка автоматизированного средства генерации отчетов Сетелем Банк ООО

Утверждаю	зав.кафедрой д.т.н., проф.	В.Н. Тарасов
Руководитель	ст. преп.	К.С. Павлов
Н. контролер	ст. преп.	С.В. Чернова
Разработал	ПО-31	К.К. Исайчева

Самара 2017





Введение

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

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

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

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

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

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

Целью работы является повышение эффективности деятельности представительства банка за счет создания автоматизированного средства генерации отчетов.

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

Основная задача данной бакалаварской работы - создание автоматизированного средства генерации отчетов Сетелем Банк ООО. Эту задачу можно разбить на несколько подзадач:

- изучить алгоритм выполнения расчетов для формирования общих отчетов;

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

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

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

- изучить технологию разработки бизнес приложений;

- разработать систему, удовлетворяющую техническим требованиям;

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

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

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

Для разработки системы за методологическую основу были взяты труды Гудвина Г.К. “Проектирование программного обеспечения” [10], в которых описываются технологии и методы проектирования программных продуктов, и “JAVA: Справочное руководство”, автор Нотон П. [12].

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

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

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

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

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

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

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

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

база данные автоматизация гендерация отчет

1. Теоретическая часть

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

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

Анализ предметной области является первым шагом этапа системного анализа. С этого шага начинается разработка программной системы. Разработчики должны:

- понимать язык, на котором говорят заказчики;

- выявить цели их деятельности;

- определить набор решаемых ими задач;

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

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

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

Анализ предметной области разбивается на три фазы:

- анализ концептуальных требований и информационных потребностей;

- выявление информационных объектов и связей между ними;

- построение концептуальной модели предметной области и проектирование концептуальной схемы БД.

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

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

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

1.2 Автоматизация банковской деятельности

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

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

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

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

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

1.3 Техническое задание

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

1.4 Требования к системе

Система для автоматизированного сбора отчетов должна отвечать следующим требованиям:

- возможность вносить и хранить данные со стороны кредитных экспертов о:

?) количестве кредитных заявок;

?) количестве одобренных кредитных заявок;

?) количестве выданных кредитных заявок;

?) информация по каждой выданной заявке (чеку): сумма, тип страхования, если применимо, наличие или отсутствие услуг смс-информирования и lkp;

?) паритетной доле торговой точки;

?) дневной, недельной и месячной доле банка на данной торговой точке;

?) количестве выданных ДТС-карт;

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

?) информация о количестве оформленных дополнительных продуктах банка;

?) поле для комментарий кредитного эксперта;

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

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

2. Описание и выбор средств разработки

2.1 Стек технологий. Кроссплатформенные приложения

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

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

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

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

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

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

В технологии "клиент-сервер" функции приложений подразделяются на три группы:

- ввод и отображение данных (взаимодействие с пользователем);

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

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

Поэтому, в любом приложении выделяются следующие компоненты:

- компонент представления данных;

- прикладной компонент;

- компонент управления ресурсом.

Определенные правила, по которым осуществляется связь между компонентами, называются "протоколом взаимодействия".

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

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

- портируемость кода между аппаратными и программными платформами;

- возможность поддержки средств клиент/сервер;

- степень "осведомленности" продукта о базе данных. Она отражает объем работы, необходимый для того, чтобы программы могли взаимодействовать с базой данных. У инструментальных средств, имеющих высокий уровень "осведомленности" о базе данных, стандартные возможности работы с БД уже встроены во все приложения;

- совокупность навыков разработчиков либо наличие консультантов, знающих эти инструментальные средства;

- степень "современности" продукта и вероятность того, что он будет поддерживаться многие годы;

- сложность инструментального средства и возможная скорость написания и отладки программ;

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

2.2 Выбор инструментальных средств

В процессе выбора среды для реализации проекта автоматизированного средства генерации отчетов Сетелем Банк ООО было принято решение об использовании CUBA Platform [2], так как данная платформа уже ранее использовалась при разработке системы учета рабочего времени сотрудников банка. Рациональное использование возможностей средств разработки приложений позволяет автоматизировать процесс создания проекта, для чего идеально подходит CUBA Platform.

Инструментальные средства позволяют:

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

- передавать управление процессам в зависимости от состояния системы;

- создавать как сами базы данных, так и обертки для баз данных;

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

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

- поддержка объектно-ориентированного стиля программирования;

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

- использование визуальных компонентов для наглядного проектирования интерфейса;

- поддержка БД.

2.3 Обзор платформы быстрой разработки приложений

CUBA Platform, используемая для разработки системы автоматизированного сбора отчетов, - это высокоуровневая платформа для создания бизнес-приложений на Java, объединяющая ведущие open-source технологии в эффективную среду разработки. Готовые компоненты платформы, такие как универсальный фильтр данных, отчеты, графики, управление бизнес-процессами, контроль доступа, аудит, полнотекстовый поиск и модуль работы с кредитными картами позволяют быстро решать типовые задачи при разработке корпоративных приложений.

Платформа включает CUBA Studio - дополнительный инструмент, который используется совместно с Java IDE. CUBA Studio обеспечивает генерацию экранов CRUD, скриптов сборки и обновления БД, а также визуальное проектирование интерфейса. Вместе с автоматическим применением изменений без остановки сервера (hot deploy), Studio существенно экономит время разработчика.

Приложения, созданные на CUBA, легко интегрируются в ИТ-инфраструктуру предприятия благодаря веб-интерфейсу, универсальному REST API, а также поддержке наиболее популярных баз данных и серверов приложений. Возможность работы в кластере гарантирует масштабируемость приложений.

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

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

2.4 Основные возможности CUBA Platform

К основным возможностям CUBA Platform относятся:

- декларативное создание UI: компоновка экранов в XML, инициализация и обработка событий в классах Java;

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

- экраны работают в веб (AJAX) и в десктоп (Swing) клиентах, исходники общие;

- метаданные -- расширенная информация о модели данных. Проектирование модели данных “от сущностей к таблицам”;

- мягкое удаление записей в БД;

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

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

- “из коробки” поддерживаются PostgreSQL, MS SQL Server, Oracle, HSQL;

2.4.1 Преимущества CUBA Platform

К преимуществам CUBA Platform можно отнести:

- быстрое создание приложений;

- готовые компоненты;

- широкий набор визуальных компонентов, универсальный фильтр данных, отчеты, графики, BPM, контроль доступа, аудит, полнотекстовый поиск, работа с кредитными картами и т.д.;

- автоматизация разработки;

- генерация экранов CRUD, скриптов сборки и обновления БД, визуальное проектирование интерфейса, применение изменений без остановки сервера;

- быстрый старт;

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

- гибкость и удобство разработки;

- вся разработка ведется на Java Standard Edition, интерфейс описывается декларативно в XML. Не требуется использование HTML, CSS или JavaScript;

- ваша IDE + инструменты CUBA;

- CUBA Studio выполняет рутинные операции, позволяя сконцентрироваться на программировании логики в удобной для вас IDE;

- открытая архитектура;

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

Платформа CUBA состоит из свободно распространяемых компонентов:

- J2EE (Java 2 Enterprise Edition) - наиболее распространённая в мире и стабильная платформа построения корпоративных приложений;

- AJAX web framework (Google Web Toolkit) - технология, предоставляющая широкий набор компонентов для создания web-интерфейса;

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

- EclipseLink ORM - современная технология объектно-реляционного отображения данных.

2.4.2 Технологии, включенные в Cuba

Перечень технологий, входящих в CUBA:

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

- Spring - используется в качестве основной инфраструктуры среднего слоя и клиентских блоков приложения;

- Eclipse link - применяется для реализации ORM. Позволяет моделировать предметную область в соответствии со стандартом JPA и выполнять сложные объектно-ориентированные запросы;

- Gradle - применяется для сборки проектов;

- Activiti - является основой модуля BPM и предоставляет средства для создания, исполнения и управления процессами с поддержкой стандарта BPMN 2.0;

- Apache Lucene - фреймворк реализации полнотекстового поиска.

2.4.3 PostgreSQL

В ходе разработки системы автоматизированной генерации отчетов использовалась СУБД PostgreSQL. Выбор данной системы управления БД обусловлен рядом ее преимуществ перед другими СУБД и удобством в использовании.

PostgreSQL [1] - это система управления базами данных, причем не просто реляционная, а свободная объектно-реляционная СУБД. Данное обстоятельство дает PostgreSQL множество преимуществ над другими SQL базами данных с открытым кодом, такими как MySQL, MariaDB и Firebird.

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

Кроме того, PostgreSQL отличается от других реляционных баз данных рядом возможностей, которые отсутствуют у других [3]:

- массивы значений в PostgreSQL могут храниться для большинства существующих типов данных. MySQL, MariaDB, и Firebird это невозможно. Чтобы хранить такие массивы значений в традиционных реляционных базах данных, придется создавать отдельную таблицу со строками для каждого из значений массива;

- в PostgreSQL реализована возможность создания нового типа на случай, если обширного списка типов данных PostgreSQL окажется недостаточно. С помощью команды CREATE TYPE, можно создать новые типы данных, такие как составной, перечисляемый, диапазон и базовый. MySQL, MariaDB и Firebird в силу того, что не являются объектно-реляционными, такой функциональности предоставить не могут;

- PostgreSQL может обрабатывать гораздо больший объем данных, нежели другие БД:

?) максимальный размер базы данных - неограничен;

?) максимальный размер таблицы - 32 TB;

?) максимальный размер строки - 1.6 TB;

?) максимальный размер поля - 1 GB;

?) максимальное количество строк в таблице - неограничено;

?) максимальное количество столбцов в таблице - 250-1600 в зависимости от типа столбца;

?) Максимальное количество индексов в таблице - неограничено;

В то время, как у MySQL и MariaDB присутствует ограничение размера строк в 65 535 байт, Firebird также предлагает всего лишь 64Кб в качестве максимального размера строки и т.д.;

- в PostgreSQL реализована поддержка JSON, что позволяет перейти к хранению schema-less данных в SQL базе данных. Это может быть полезно, когда структура данных требует определённой гибкости: например, если в процессе разработки структура всё ещё меняется или неизвестно, какие поля будет содержать объект данных. Тип данных JSON обеспечивает проверку корректности JSON, который позволяет использовать специализированные JSON операторы и функции, встроенные в PostgreSQL для выполнения запросов и манипулирования данными. Также доступен тип JSONB -- двоичная разновидность формата JSON, у которой пробелы удаляются, сортировка объектов не сохраняется, вместо этого они хранятся наиболее оптимальным образом, и сохраняется только последнее значение для ключей-дубликатов;

- большое внимание уделяется целостности данных. PostgreSQL стремится соответствовать стандарту ANSI-SQL:2008, отвечает требованиям ACID (атомарность, согласованность, изолированность и надежность) и известен своей ссылочной и транзакционной целостностью. Первичные ключи, ограничивающие и каскадные внешние ключи, уникальные ограничения, ограничения NOT NULL, проверочные ограничения и другие функции обеспечения целостности данных дают уверенность, что только корректные данные будут сохранены.

3. Проектирование и разработка системы управления

3.1 Разработка базы данных

Основные задачи, которые решаются в процессе разработки модели базы данных:

- обеспечение хранения в БД всей необходимой информации;

- обеспечение возможности получения данных по всем необходимым запросам;

- сокращение избыточности и дублирования данных;

- обеспечение целостности базы данных.

В моем приложении используются следующие сущности:

- AdditionalService - описывает дополнительный продукт. Имеет поле имя;

- AdditionalServiceLink - описывает связь отчетов и дополнительных продуктов. Имеет ссылки на отчет и дополнительный продукт, а также количество дополнительных продуктов;

- Bank - описывает абстрактный банк. Имеет поле имя;

- CompetitorBank - хранит данные о выручке банка конкурента. Имеет ссылку на сущность Bank и поле amount, хранящее сумму банка конкурента;

- Bill - описывает чек в отчете. Имеет такие поля как сумма, тип страхования, использовать смс, использовать lkp;

- TradePoint - описывает торговую точку. Имеет поле имя;

- TradePointShare - описывает долю торговой точки в итоговом отчете. Имеет такие поля как паритетна доля, дневная доля, недельная доля, месячная доля;

- StoreChain - описывает торговую сеть. Имеет имя и коллекцию торговых точек;

- StoreChainShare - описывает долю торговой сети в итоговом отчете. Имеет такие поля как кредитный оборот сети, итоговый кредитный оборот, дневная доля, месячный кредитный оборот сети, итоговый месячный кредитный оборот, месячная доля;

- Report - базовый класс для отчетов кредитных экспертов. Имеет такие поля как ссылка на торговую точку, количество заявок, количество одобренных заявок, количество выданных заявок, сумма, дневная доля, недельная доля, месячная доля, коллекция чеков (выданных), коллекция банков конкурентов, коллекция дополнительных продуктов, количество карт cetelem, комментарий;

- EndDayReport - описывает вечерний отчет кредитных экспертов. Наследник Report. В дополнение к полям Report имеет поля сумма со страховкой, количество смс, количество lkp, кредитный объем торговой точки, суммарный кредитный объем;

- ForecastReport - описывает прогнозный отчет кредитных экспертов. Наследник Report. В дополнение к полям Report имеет поле паритетная доля;

- SummaryReport - базовый класс для итоговых отчетов. Имеет поля сумма факт, чеки факт, сумма cpu факт, сумма cpu ui факт, чеки с смс, процент чеков с смс, чеки с lkp, процент чеков с lkp, количество карт cetelem, дополнительная информация и коллекция дополнительных продуктов;

- EndDaySummaryReport - описывает вечерний итоговый отчет. Наследник SummaryReport. В дополнение к полям SummaryReport имеет поля количество заявок, количество одобренных заявок, процент кредитов, конвертация, коллекция долей торговых точек, коллекция долей торговых сетей;

- ForecastSummaryReport - описывает прогнозный итоговый отчет. Наследник SummaryReport. В дополнение к полям SummaryReport имеет поля прогнозируеммая сумма, сумма cpu прогноз, сумма cpu ui прогноз, прогнозируемые чеки, чеки с cpu факт, чеки с cpu проноз, чеки с cpu ui факт, чеки с cpu ui проноз.

Для удобства был добавлен класс-перечисление InsuranceType - описывает тип страхования: CPU или CPU_UI.

Схема базы данных (картинка) была выполнена с использованием возможностей сайта Vertabelo [6]. По факту уже после того как приложение было создано. Перед разработкой на листе бумаги был сделан набросок схемы базы данных моего проекта (см. Приложение Б).

3.2 Разработка программного обеспечения

3.2.1 Создание проекта

Для создания проекта в CUBA Studio, необходимо проделать следующие действия:

1. запустите CUBA Studio и откройте ее веб-интерфейс;

2. в стартовом окне нажмите на кнопку Create New;

3. в окне New project в поле Project name введите имя проекта - cetelem. Имя должно содержать только латинские буквы, цифры и знак подчеркивания;

4. в полях ниже автоматически сгенерируются:

?) Project path ? путь к каталогу нового проекта. Каталог можно выбрать вручную, нажав на кнопку “…” рядом с полем; Отобразится окно Folder select со списком папок на жестком диске. Вы можете выбрать одну из них или создать новый каталог, нажав на кнопку “+”;

?) Project namespace - пространство имен, которое будет использоваться как префикс имен сущностей и таблиц базы данных. Пространство имен может состоять только из латинских букв, и должно быть как можно короче. Например, если имя проекта - cetelem, то пространство имен может быть cetelem;

?) Root package ? корневой пакет Java-классов. Может быть скорректирован позже, однако сгенерированные на этапе создания классы перемещены не будут;

?) Platform version - используемая в проекте версия платформы. Артефакты платформы будут автоматически загружены из репозитория при сборке проекта;

5. оставим все предложенные значения без изменений;

6. нажмите на кнопку “ОК”. В указанном каталоге cetelem будет создан пустой проект, и откроется главное окно Studio.

3.2.2 Создание сущностей

Рассмотрим пример создания сущностей в CUBA Studio на примере сущности Bank.

- перейдите на вкладку Data Model на панели навигатора и нажмите на кнопку New entity. Появится диалоговое окно New > entity (рис. 3.1);

Рис 3.1 - Окно “New entity”

- в поле Class name введите название класса сущности - Bank;

- нажмите “ОК”. В рабочей области откроется страница дизайнера сущности (Рис 3.2);

Рис 3.2 - Окно “Дизайнер сущности”

- в полях Name и Table автоматически сгенерируются имя сущности и имя таблицы в базе данных;

- в поле Parent class оставьте установленное значение - StandardEntity;

- поле Inheritance strategy оставьте пустым;

- нажмите на кнопку рядом с полем Name. На экране отобразится окно Localized message, в нем следует задать локализацию имени сущности на доступных языках.

Далее создадим атрибуты сущности. Для этого нажмите на кнопку “New”, находящуюся под таблицей Attributes.

- в отобразившемся окне Create attribute (рис. 3.3) в поле Name введите название атрибута сущности ? name, в списке Attribute type выберите значение DATATYPE, в поле Type укажите тип атрибута String и далее укажите длину текстового атрибута в поле Length, равной 255 символам. Установите флажок Mandatory. В поле Column автоматически сгенерируется имя колонки таблицы в базе данных;

-

Рис 3.3 - Окно “Create attribute”

- далее нажмите на кнопку рядом с названием атрибута. На экране отобразится окно Localized message, в нем следует задать локализацию названия атрибута на доступных языках;

- для добавления атрибута нажмите на кнопку “Add”.

После создания атрибутов перейдите на вкладку Instance name дизайнера сущности для задания Name pattern. В списке Available attributes выделите атрибут name и перенесите его в список Name pattern attributes, нажав на кнопку с изображением стрелки вправо.

На этом создание сущности Bank завершено. Нажмите на кнопку “Ок” в верхнем левом углу дизайнера сущности для сохранения изменений.

3.2.3 Создание таблиц базы данных

Для создания таблиц базы данных достаточно на вкладке Data Model панели навигатора нажать на кнопку “Generate DB scripts” (рис. 3.4). После этого откроется страница Database scripts. На вкладке будут сгенерированы скрипты обновления базы данных от ее текущего состояния (Update scripts) и скрипты создания базы данных с нуля (Init tables, Init constraints, Init data). Также на вкладке будут доступны уже выполненные скрипты обновления базы данных, если они есть.

Рис 3.4 - Окно “Database scripts”

Чтобы сохранить сгенерированные скрипты, нажмите на кнопку “Save and close”. Для запуска скриптов обновления выполните Run > Update database.

3.2.4 Создание экранов просмотра и редактирования сущностей

Рассмотрим процесс создания стандартных экранов на примере сущности Bank.

Для создания стандартных экранов просмотра и редактирования необходимо выделить сущность Bank на вкладке Data Model панели навигатора и нажать на кнопку “New > Generic UI screen”. После этого на экране отобразится окно “Generic UI Templates” (рис. 3.5). Выполните следующие действия:

Рис 3.5 - Окно “Generic UI Templates”

- выберите Entity Browser, нажмите Create;

- Выберите Entity Browser, нажмите Create;

- Нажмите Close.

Во вкладке Generic UI панели навигатора в модуле Web появятся элементы bank-edit.xml и bank-browse.xml.

Для сущностей Торговая точка, Банк-конкурент, Чек и Сеть магазинов подходят экраны, сгенерированные CUBA Studio. Небольшое косметическое изменение включают настройку для отображения экранов редактирования в режиме диалога, чтобы не было лишнего пустого пространства.

<dialogMode width="AUTO"/>

В остальные экраны просмотра и редактирования сущностей были внесены изменения.

3.2.5 Экран просмотра Дополнительных продуктов и Банков

Для данных экранов (рис. 3.6) стандартный фильтр был заменен на упрощенный в виде текстового поля и обработкой изменения значения в нем. nameFilterField.addValueChangeListener(e ->

additionalServicesDs.refresh(ParamsMap.of("name",

nameFilterField.getValue() != null

? "(?i)%" + nameFilterField.getValue() + "%"

: null)));

Рис.3.6 - Экран просмотра Банков

3.2.6 Экран редактирования отчета КЭ по ТТ

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

Для новой сущности проставляются значения по умолчанию:

@Override

protected void initNewItem(Report item) {

item.setApplicationsNumber(0);

item.setApprovedNumber(0);

item.setGivenOutNumber(0);

item.setAmount(BigDecimal.ZERO);

item.setDayShare(0);

item.setWeekShare(0);

item.setMonthShare(0);

item.setCetelifeCardNumber(0);

}

Рис. 3.7 - Экран редактирования отчета КЭ по ТТ

При попытке сохранить отчет происходит проверка на соответствие общего количества заявок, утвержденных заявок и выданных заявок (рис. 3.8).

@Override

protected void postValidate(ValidationErrors errors) {

int applicationsNumber = getValueOrDefault(getItem().getApplicationsNumber(), 0);

int approvedNumber = getValueOrDefault(getItem().getApprovedNumber(), 0);

int givenOutNumber = getValueOrDefault(getItem().getGivenOutNumber(), 0);

if (approvedNumber > applicationsNumber) {

errors.add(approvedNumberField, getMessage("approvedNumber.validationError"));

}

if (givenOutNumber > approvedNumber) {

errors.add(givenOutNumberField, getMessage("givenOutNumber.validationError"));

}

}

Рис. 3.8 - Сообщение об ошибке в количестве заявок

Общая сумма всех выданных заявок, а также их количество рассчитывается автоматически при добавлении новых заявок:

@Override

public void ready() {

billsDs.addCollectionChangeListener(e -> {

getItem().setGivenOutNumber(billsDs.size());

getItem().setAmount(reportService.calculateTotalAmount(getItem()));

});

}

3.2.7 Экран редактирования Вечернего Отчета КЭ по ТТ

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

3.2.8 Экран просмотра отчетов КЭ по ТТ

В экран был добавлен фильтр по дате (рис. 3.9), представляющий собой компонент DateField.

Рис. 3.9 - Экран просмотра отчетов КЭ по ТТ, фильтр по дате

При изменении значения поля даты, происходит загрузка данных из БД.

Экран просмотра отчётов позволяет сгенерировать итоговый отчет, для этого на панель кнопок таблицы была добавлена еще одна (рис. 3.10).



Рис. 3.10 - Экран просмотра отчетов КЭ по ТТ, генерация итогового отчета

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

Рис. 3.11 - Экран выбора даты

После генерации отчета происходит проверка наличия отсутствующих в итоговом отчете торговых точках. Если такие ТТ есть, то выводится предупреждение (рис. 3.12).



Рис. 3.12 - Список отсутствующих в итоговом отчете торговых точек

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

protected void handleSelectedDate(Date date) {

}

3.2.9 Экран редактирования Итогового Вечернего Отчета

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

storeChainsShareDs.addItemPropertyChangeListener(e -> {

if ("chainMonthCreditTurnover".equals(e.getProperty())

|| "totalMonthCreditTurnover".equals(e.getProperty())) {

BigDecimal chainCT = e.getItem().getChainMonthCreditTurnover();

BigDecimal totalCT = e.getItem().getTotalMonthCreditTurnover();

if (chainCT != null && totalCT != null) {

e.getItem().setMonthShare(reportService.calculatePercentage(chainCT, totalCT));

} else {

e.getItem().setMonthShare(BigDecimal.ZERO);

}

}});

3.2.10 Экран просмотра Итоговых Отчетов

В дополнение к стандартным CRUD действиям, добавлена возможность отправить отчет по почте (рис.3.13).

public void sendEmail() {

try {

reportService.sendReport(summaryReportsTable.getSingleSelected());

showNotification(getMessage("message.emailSent"));

} catch (EmailException e) {

showNotification(getMessage("message.emailSendingFailed"));

}

}

Рис. 3.13 - Экран просмотра Итоговых Отчетов, отправка отчета на почту

3.3 Генерирование итоговых отчетов

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

3.4 Настройка ролей

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

Рис. 3.14 - Настройка роли кредитного эксперта

Рис. 3.15 - Настройка роли кредитного эксперта

3.5 Настройка групп

Чтобы кредитные эксперты видели только отчеты, созданные ими самими, была добавлена группа “Кредитные эксперты” (рис. 3.16).

Рис. 3.16 - Группы доступа

3.6 Сборка и запуск проекта

1. сборка проекта. Выберите пункт главного меню Studio Build > Assemble project. На этом этапе будут загружены все необходимые библиотеки и в подкаталогах build модулей будут собраны артефакты проекта;

2. выберите пункт меню Run > Deploy. В подкаталоге build проекта будет установлен сервер Tomcat с собранным приложением;

3. выберите пункт меню Run > Start application server. Через несколько секунд в панели статуса ссылка рядом с надписью Web application станет доступной, и по ней можно осуществить переход к приложению непосредственно из Studio.

4. Руководство пользователя

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

4.1 Руководство пользователя для кредитных экспертов

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

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

Рис. 4.1 - Окно авторизации пользователя

После входа в систему кредитному эксперту будут доступны следующие пункты меню:

- Отчеты (рис. 4.2)

?) Прогнозные отчеты КЭ по ТТ

?) Вечерние отчеты КЭ по ТТ (рис. 4.3),

- Помощь (рис. 4.3)

?) Параметры



Рис. 4.2 - Отчеты

Рис. 4.3 - Помощь

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

Рассмотрим создание отчетов на примере экрана Прогнозных отчетов. Он позволяет создавать новые отчеты, изменять и удалять уже созданные, выполнять поиск ранее созданных отчетов по дате и с использованием фильтров (рис. 4.4).



Рис. 4.4 - Экран Прогнозные отчеты КЭ по ТТ

Создание или редактирование отчета происходит в специальном окне создания прогнозных отчетов КЭ по ТТ, открываемом в текущей вкладке (рис. 4.5).

Рис. 4.5 - Экран формы для создания прогнозных отчетов

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

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

Рис. 4.6 - Экран создания чека

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

Рис. 4.7 - Экран Конкуренты

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



Рис. 4.8 - Экран для внесения информации, о суммах, оформленных в банках-конкурентах

Вкладка Дополнительные продукты предназначена для учета дополнительных банковских продуктов, оформленных за текущий день (рис. 4.9).

Рис. 4.9 - Экран Дополнительные продукты банка

Заполнение информации в данной вкладке происходит аналогично вкладке Конкуренты (рис. 4.10).

Рис. 4.10 - Экран для внесения информации об оформленных дополнитльных продуктах банка

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

Рис. 4.11 - Экран Параметры

Изменение пароля происходит в специальном экране, открываемом в режиме диалога (рис. 4.12).

Рис. 4.12 - Экран смены пароля

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

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

- Отчеты (рис. 4.13)

?) Прогнозные отчеты КЭ по ТТ

?) Вечерние отчеты КЭ по ТТ

?) Прогнозные отчеты

?) Вечерние отчеты

- Реестр (рис. 4.14)

?) Банки

?) Дополнительные продуты

?) Сети магазинов

?) Торговые точки

- Настройки (рис. 4.15)

?) Основные

- Администрирование (рис. 4.16)

?) Пользователи

?) Группы доступа

?) Роли

?) Помощь

Рис. 4.13 - Отчеты



Рис. 4.14 - Реестр

Рис. 4.15 - Настройки

Рис. 4.16 - Администрирование

Экраны просмотра Прогнозных отчетов КЭ по ТТ (рис. 4.17) и Вечерних отчетов КЭ по ТТ в большинстве своем схожи

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

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

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

Так же в данных экранах реализована возможность поиска по дате и с помощью фильтров.

Рис. 4.17 - Экран Прогнозные отчеты КЭ по ТТ

Рис. 4.18 - Экран, выводящий сообщение об отсутствии отчетов с соответствующих торговых точек

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



Рис. 4.19 - Экран Прогнозные отчеты

Реестр, экран Банки (рис. 4.20) предназначен для создания списка банков-конкурентов, присутствующих на торговых точках одновременно с Сетелем Банк. Данный экран позволяет добавлять в систему новые банки-конкуренты, редактировать и удалять уже добавленные. Изменение и добавление банка происходит в специальном окне редактирования, открываемом в диалоговом режиме (рис. 4.21).

Рис. 4.20 - Экран Банки



Рис. 4.21 - Экран редактирования информации о банке-конкуренте

Реестр, экран Дополнительные продукты (рис. 4.22) предназначен для создания списка дополнительных продуктов банка. Данный экран позволяет добавлять в систему новые продукты банка, редактировать и удалять уже существующие. Изменение и добавление продуктов происходит в специальном окне редактирования, открываемом в диалоговом режиме (рис. 4.23).

Рис. 4.22 - Экран Дополнительные продукты



Рис. 4.23 - Экран редактирования информации о дополнительных продуктах банка

Реестр, экран Торговые сети (рис. 4.24) предназначен для объединения магазинов, принадлежащих одной торговой сети. Необходимость создания данного экрана обусловлена тем, что для торговых точек, входящих в объединение, отличаются параметры расчета итоговых отчетов - в отличие от остальных магазинов, в торговых сетях присутствует расчет доли присутствия банка в торговой сети, исходя из результатов отчетного дня и месяца. Данный экран позволяет добавлять в систему новые торговые сети магазинов, редактировать и удалять уже существующие.

...