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

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

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

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

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

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

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

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

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

Пермь 2011

Аннотация

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

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

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

Оглавление

• 1. Постановка задачи
• 2. Описание модели поведения системы, представленной на диаграммах активности
• 2.1 Диаграмма активности «Жизненный цикл проведения одного платежа»
• 2.2 Диаграмма активности для прецедента «Проверка данных»
• 2.3 Диаграмма активности для прецедентов «Проверка купюроприемника» и «Внесение наличных»
• 2.4 Диаграмма активности для прецедента «Печать чека»
• 2.5 Диаграмма активности для прецедента «Обработка платежа»
• 3. Описание модели взаимодействия, представленной на диаграммах последовательностей и кооперации
• 3.1 Диаграмма последовательностей
• 3.2 Диаграмма коопераций
• 4. Описание модели поведения, представленной на диаграммах состояний
• 5. Описание логической структуры системы, представленной на диаграммах классов
• 6. Описание физической структуры системы, представленной на диаграммах компонентов
• 7. Процесс генерации программного кода
• 8. Описание C# программы
• 9. Результаты тестирования
• Заключение
• Список использованной литературы
• Приложения

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 - переключает состояния терминала, отображение форм в зависимости от состояния;

Имеет поля: _manager(хранит экземпляр класса, создается при первом обращении к StateManager. Instance), _privKioskForm(хранит предыдущее состояние терминала для возврата);

Свойства: Instance - возвращает экземпляр класса StateManager;

Функции: ChangeState - переключение текущего состояния киоска,- текущая форма сохраняется в _privKioskForm и скрывается, новая форма выводится на экран.

Класс KioskFormInterface - интерфейс для состояний терминала (форм)

Функции: HideForm(скрыть форму), ShowForm (показать форму)

Класс Provider - интерфейс провайдеров, содержит данные провайдеров;

Функции:

GetCode - возвращает код провайдера

Length - возвращает длину маски (кол-во символов в реквизите)

Name - возвращаем имя провайдера

Title - возвращает заголовок маски (какой реквизит, например «номер телефона»)

Класс Payment - для хранения данных о платежах

Свойства: Amount, Property, Provider и ReceiptNumber - возвращают данные о платеже, такие как - сумма, реквизиты, провайдер и номер чека;

Функции:

AddAmount - добавляет сумму в платеж,

Payment - конструктор класса Payment, создает класс платежа,

Set ReceiptNumber - устанавливает номер чека

9. Результаты тестирования

При тестировании критичных ошибок не обнаружено.

Заключение

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

Для дальнейшего развития системы необходимо:

- расширить количество операторов

- доработать дизайн интерфейса для привлечения большего числа пользователей

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

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

Список использованной литературы

1. Гради Буч «Объектно-ориентированный анализ и проектирование с примерами приложений на С++»; второе издание, Rational Санта-Клара, Калифорния; перевод с английского под редакцией И. Романовского и Ф. Андреева; 2004.

2. Круглински Д., Уингоу С., Шеферд. Дж., «Программирование на Microsoft Visual C++ 6.0 для профессионалов»

3. Гусин А.Н., Хабибрахманов Р.Г., Лонский В.О. «Методическое пособие по работе в среде проектирования Rational Rose, на примере автоматизации работы склада». Пермь 2004. Электронное пособие.

4. Леоненков - UML. Электронное пособие.

5. А.М. Вендров “Объектно-ориентированный анализ и проектирование с использованием языка UML и Rational Rose”.

6. Уэнди Боггс (Wendy Boggs) Майкл Боггс (Michael Boggs) “UML и Rational Rose”.

Приложения

Приложение 1

Use case diagram

Рисунок 1. Use case diagram

Приложение 2

моделирование программный файл язык

Activity diagram

Рисунок 2. Activity diagram

Приложение 3

Sequence diagram

Рисунок 3. Sequence diagram

Приложение 4

Collaboration diagram

Рисунок 4.Collaboration diagram

Приложение 5

Statechart diagram

Рисунок 5. Statechart diagram

Приложение 6

Class diagram

Рисунок 6. Class diagram_1



Рисунок 7.Class diagram_2

Приложение 7

Component diagram

Приложение 8

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

По умолчанию программа находится в главном меню:

Рисунок 8. Главное меню

После выбора оператора попадаем в форму ввода реквизитов:

Рисунок 9. Форма ввода реквизитов

Вводим данные:

Рисунок 10. Форма ввода реквизитов с данными

И нажимаем кнопку вперед, происходит переход в форму проверки реквизитов:

Рисунок 11. Форма проверки реквизитов

Если номер был введен не правильно, то увидим сообщение:



Рисунок 12. Форма проверки реквизитов. Проверка не прошла

При нажатии кнопки назад происходит возврат в форму ввода реквизитов, где можно скорректировать введенные данные.

Если реквизиты были введены правильно, переходим по кнопке вперед в форму приема денег:

Рисунок 13. Форма приема денег

При нажатии на кнопку внести деньги имитируем работу купюроприемника:



Рисунок 14. Внесение денег с помощью эмулятора купюроприменика

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

Рисунок 15. Результирующая форма с выводом текста чека на экран

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



Рисунок 16. Результирующая форма

При переходе по кнопке вперед снова попадаем в главное меню.

Данные о платеже отправляются оператору, и вскоре пополняется счет пользователя.

Приложение 9

Руководство программиста

Компиляция и компоновка производится в среде Visual Studio 2008

Проект содержит следующие файлы:

BillValidator.cs - реализация класса купюроприемника

FiscalRegistrator.cs - реализация класса фискального регистратора

PC.cs - реализация класса ПЦ

Program .cs - основной класс, запуск

StateManager.cs - реализация класса состояний

States\BillAcceptForm.cs и т.д. - реализация класса форм

Providers.cs - класс наследованый от провайдера

Kiosk.exe - запускающий файл приложения

Приложение 10

Листинг программы

Класс: StateManager

public class StateManager

{

private static StateManager _manager;

private KioskFormInterfase _prevKioskForm;

public static StateManager Instance

{

get

{

if (_manager == null)

_manager = new StateManager();

return _manager;

}

}

public void ChangeState(KioskFormInterfase kioskForm)

{

if (_prevKioskForm != null)

_prevKioskForm.HideForm();

_prevKioskForm = kioskForm;

kioskForm.ShowForm();

}

}

Класс Payment

public class Payment

{

public Payment(Provider provider, string reqvezit)

{

Property = reqvezit;

Provider = provider;

}

public Provider Provider { get; private set; }

public int ReceiptNumber { get; private set; }

public string Property { get; private set; }

public int Amount { get; private set; }

public void AddAmount(int amount)

{

Amount += amount;

}

public void SetReceiptNumber(int receiptNumber)

{

ReceiptNumber = receiptNumber;

}

}

Интерфейс KioskFormInterfase

public interface KioskFormInterfase

{

void ShowForm();

void HideForm();

}

Интерфейс Provider

public interface Provider

{

int GetCode();

int Length();

string Name();

string Title();

Размещено на Allbest.ru