Терминал приема платежей

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

Пермский государственный  технический университет

Кафедра Информационных технологий и автоматизированных систем

 

 

 

 

 

 

 

 

 

 

 

Курсовая работа по дисциплине

«Технология программирования»

«Терминал приема платежей»

 

 

Выполнил: студент группы АСУз-07

Кузнецова (Турова) П. В.

Проверил: доцент кафедры ИТАС Ноткин А. М.

 

 

 

 

 

 

Пермь 2011

 

 

Аннотация

 

Целью курсовой работы является приобретение навыков моделирования  программных продуктов в среде Rational Rose.

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

Задачей работы является разработка программной системы от начала (анализ требований) до конца (тестирование и сопровождение-документация). В процессе выполнения курсовой работы была создана модель системы на языке UML, подготовленная в Rational Software Architect и программный продукт в виде исполняемого файла и исходных файлов.

 

 

Оглавление

 

 

 

1. Постановка задачи

 

В качестве инструментальной среды проектирования используется Rational Software Architect. Для описания модели используется язык UML.

Процесс проектирования – Rational Unified Process(RUP). Язык программирования используется C++. Среда разработки программы Microsoft Visual Studio.NET.

Терминал приема платежей

Программное обеспечение  встроенного процессора терминала.

Терминал – это автомат для оплаты сотовой связи, интернета и других услуг. В его состав входят следующие устройства: дисплей, пинпад (панель управления с кнопками), купюроприемник, фискальный регистратор, GPRS модем, сторожевой таймер.

Купюроприемник – состоит из: укладчика купюр, валидатор купюр (определяет номинал купюры и ее подлинность) и кассета (хранилище принятых купюр).

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

GPRS модем – осуществляет связь между терминалом и процессинговым центром (ПЦ).

Прием платежа  осуществляется по следующему алгоритму:

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

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

Данные отправляются на ПЦ для проверки. Результат проверки возвращается на терминал. Если проверка данных закончилась не удачно, то терминал возвращается в режим ввода данных и пользователю выдается сообщение о необходимости скорректировать реквизиты. Если проверка прошла успешно, то производим проверку состояния купюроприемника и ФРа. Если были обнаружены ошибки, то переходим в режим обслуживания (терминал не принимает платежи, до устранения ошибок). После успешной проверки переходим в режим приема денег.

По завершении приема денег терминал переходит в режим печати чека. Данные отправляются в ФР, где платеж регистрируется и производится печать чека. При этом платеж отправляется на ПЦ, где производится зачисление средств на счет пользователя. Далее терминал переходит в режим ожидания пользователя.

Переход из режима обслуживания в режим ожидания пользователя происходит автоматически после исправления  ошибок.

Цель: Разработать такое ПО оплаты услуг, которое обладало бы следующими свойствами:

1. Интуитивно-понятный интерфейс.
2. Быстрая и гарантированная возможность оплаты большого количества услуг.

Т.е. ПО, которое привлекло  бы максимальное количество клиентов.

Бизнес - требования:

1. Клиент должен иметь возможность выбрать необходимую услугу.
2. Клиент должен иметь возможность ввести свои данные для проведения платежа.
3. Клиент должен иметь возможность внести нужную сумму на счет.
4. Клиент должен иметь возможность получить квитанцию с информацией о внесении средств на счет.
5. Клиент должен иметь возможность гарантированного и своевременного поступления средств на оплаченный счет.

Функциональные  требования:

1. Система должна иметь возможность оправлять данные клиента на ПЦ для проверки.
2. Система должна проверять функционирование купюроприемника перед приемом денег.
3. Система должна иметь возможность отправлять данные в фискальный регистратор для дальнейшей печати им квитанции.
4. Система должна отправлять данные о проведенном платеже на ПЦ для зачисления средств на счет клиента.
5. Система должна постоянно функционировать.

Описание прецедентов  диаграммы Use Сase:

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

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

«Проверка данных» - после ввода реквизитов, переходим в форму «Проверки реквизитов». Данные введенные клиентом отсылаются на ПЦ посредством GPRS модема для проверки. После получения ответа, если данные верны, то переходим в форму «Ввода купюр», если данные не прошли проверку, то возвращаемся в форму «Ввода реквизитов» для корректировки.

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

«Проверка купюроприемника» - перед появлением формы «Ввода купюр» проверяем функционирование купюроприемника, если купюроприемник отвечает, то начинаем прием денег. Если купюроприемник не отвечает, то переходим в «Сервисную форму» до устранения ошибок.

«Прием денег» - купюроприемник принимает купюры, определяет номинал, складывает в кассету.

«Получение  квитанции» - клиент находится в форме «Печати чека»

«Печать чека» - в фискальный регистратор посылаются данные и команда на печать чека.

«Получение денег на счет» - после печати чека, отображается сообщение «Спасибо, что воспользовались нашей системой. Удачного дня», после чего система возвращается в форму «Выбора оператора».

«Обработка  платежа» - после окончания приема денег и печати чека на ПЦ отсылаются данные с реквизитам и суммой платежа для дальнейшего зачисления средств на счет.

 

 

2. Описание модели поведения системы, представленной на диаграммах активности

 

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

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

 

2.1 Диаграмма активности «Жизненный цикл проведения одного платежа»

 

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

 

 

2.2 Диаграмма активности для прецедента «Проверка данных»

 

На диаграмме активности для  прецедента «Проверка данных» отображен  алгоритм отправки и проверки данных на ПЦ. При верности данных возвращается положительный ответ, если данные не верны, то возвращается отрицательный ответ.

 

2.3 Диаграмма активности для прецедентов «Проверка купюроприемника» и «Внесение наличных»

 

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

 

2.4 Диаграмма активности для прецедента «Печать чека»

 

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

 

2.5 Диаграмма активности для прецедента «Обработка платежа»

 

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

 

3. Описание модели взаимодействия, представленной на диаграммах последовательностей и кооперации

 

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

 

3.1 Диаграмма последовательностей

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

3.2 Диаграмма коопераций

 

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

 

 

4. Описание модели поведения, представленной на диаграммах состояний

 

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

На диаграмме состояний  отображены все состояния на протяжении процесса приема платежа, такие как: Главное меню, Форма ввода реквизитов, Форма проверки данных, Форма внесения наличных, Форма печати чека.

 

 

5. Описание логической структуры системы, представленной на диаграммах классов

 

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

На диаграмме присутствуют классы:

- классы, реализующие интерфейс Provider , - класс-сущность (entity), т.к. не зависят от своего окружения, хранят только данные;

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

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

- класс Payment также является классом-сущностью (entity), т.к. только хранит данные о платеже.

- классы FiscalRegistrator и PC являются граничными классами (boundary), т.к. взаимодействуют в системой, посылая и принимая сообщения.

 

 

6. Описание физической структуры системы, представленной на диаграммах компонентов

 

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

На диаграмме представлены компоненты, представляющие из себя классы, описание которых хранится в виде *.h и *.cpp файлов. Стрелочками указано, какой компонент, от какого компонента зависит. Так компонент Kiosk.exe связан зависимостью с StateManager, а тот в свою очередь имеет зависимости с компонентами разных форм, таких как MainForm, PropertyEditForm, PropertyValidate, BillAcceptForm и ResultForm, почти каждая из которых имеет зависимость с одним из компонентов, - PC, BillValidator(имеет зависимость с компонентом Payment), FiscalRegistrator. Зависимость выявляется на этапе компиляции или выполнения программы.

 

 

7. Процесс генерации программного кода

 

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

Основным классом приложения является класс StateManager. Объект этого класса управляет состояниями киоска.

Окна программы наследованы  от интерфейса KioskFormInterface.

 

 

8. Описание C# программы

 

Класс StateManager – переключает состояния терминала, отображение форм в зависимости от состояния;