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

АКАДЕМИЯ МАРКЕТИНГА И СОЦИАЛЬНО-ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ - ИМСИТ (г. Краснодар)

Факультет информатики и вычислительной техники

Кафедра математики и вычислительной техники

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

на тему: "Разработка программного обеспечения для терминалов приема платежей за услуги связи" (по материалам ООО Фирмы "Теплостройсервис", г. Краснодар)

Краснодар

2015



Реферат

ТЕРМИНАЛЫ ПРИЕМА ПЛАТЕЖЕЙ, UML, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС, ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ, СРЕДА DELPFI 2007

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

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

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

К полученным результатам относятся приложение для реализации интерфейса терминала по приему платежей за услуги связи. Приложение написано на языке программирования высокого уровня Delpfi.

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

Внедрение результатов предусматривается в терминальном оборудовании для оплаты платежей населением за услуги связи, используемом ООО Фирмой "Теплостройсервис".

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



Перечень сокращений, символов и специальных терминов с их определением

API - интерфейс программирования приложений (Application Programming Interface);

GUI - графический интерфейс пользователя (Graphical User Interface);

ORM - объектно-реляционное отображение (Object-Relational Mapping);

RAD - быстрая разработка приложений (Rapid Application Development);

UML - унифицированный язык моделирования (Unified Modeling Language);

CORBA - технологический стандарт написания распределённых приложений (Common Object Request Broker Architecture);

БД - база данных;

ООП - объектно-ориентированное программирование;

ОС - операционная система;

ПО - программное обеспечение.



Содержание

Введение

1. Исследование предметной области

1.1 Концептуальная модель

1.2 Диаграмма вариантов использования

1.3 Диаграмма классов

2. Анализ требований к программному обеспечению

3. Техническое задание на разработку

3.1 Введение

3.2 Требования к программе

3.3 Условия эксплуатации

4. Выбор метода разработки программного обеспечения

4.1 Выбор языка программирования

5. Основная часть

6. Реализация разработки

6.1 Разработка программных модулей

6.2 Разработка интерфейса пользователя

7. Разработка проектной документации

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

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

8. Оценка эффективности программного продукта

9. Мероприятия по охране труда и безопасности жизнедеятельности

9.1 Вредные воздействия производственных факторов

9.2 Методы повышения безопасности

9.3 Пожарная безопасность

9.4 Защита окружающей природной среды

Заключение

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

Приложение

Введение

программный обеспечение интерфейс терминал

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

– выбор сотового оператора;

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

– ввод номера счёта для оплаты кредита с возможностью проверки его корректности и исправления;

– возможность контроля суммы внесённого платежа;

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

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

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

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

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

- сокращением времени на внесение в базу поступивших платежей;

- безопасном хранении данных.



1. Исследование предметной области

1.1 Концептуальная модель

Концептуальной моделью является отражение предметной области, в данном случае - сфера деятельности ООО "Теплостройсервис".

В ООО Фирма "Теплостройсервис" одним из направлений деятельности является работа по оказанию услуг населению по оплате услуг связи через терминалы.

Терминальное обслуживание осущетвляется по дилерскому договору с фирмой Кампэй (Comepay). Кампэй образована в 2006 году, работает на рынке под зарегистрированным брендом "Comepay", и является одной из ведущих компаний Российской Федерации по приему моментальных платежей. Основными направлениями бизнеса являются: развитие сервиса по приему платежей, который позволяет осуществлять оплату всех повседневных услуг от мобильной связи до погашения банковских кредитов, и производство платежных терминалов.

На первом этапе развития данного направления по предоставлению услуг терминальной оплаты ООО Фирма "Теплостройсервис" являлась региональным провайдером ООО "Кампей". В настоящее время ООО Фирма "Теплостройсервис" имеет подключения свыше 200 точек оплаты и более 600 платежных терминалов в г. Краснодаре и Краснодарском крае.

Для обеспечения надежной и бесперебойной работы по приему платежей, Фирма использует высококачественное оборудование фирмы IBM и CISCO, резервное копирование программного обеспечения и информации находящейся на сервере ООО "Теплостройсервис", а также дублирование серверного оборудования.

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

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

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

Для перехода на самостоятельное предоставление услуг ООО "Теплостройсервис" необходимо покупать техническое оборудование в виде терминала и программное обеспечение к данному оборудованию. Стоимость лицензии на программное обеспечение "Электронный кассир" и базовая настройка на один терминал на 30.03.2015 составляет 29470 рублей. В данную поставку входят интеграция нового поставщика, редактирование формата и вида реестра, генерация доступа к личному кабинету, программирование интерфейса, программирование чека и сценария платежа, настройку простого меню до 8 позиций и простого чека. Таким образом, программирование интерфейса, программирование чека и сценария платежа, настройку простого меню до 8 позиций и простого чека составляют половину пакета услуг по программированию терминалов приема платежей, что составляет около15000 рублей на каждый терминал. Было принято решение о разработке собственного программного продукта, входящего в программно-аппаратный комплекс, возможности которого позволяют организовать прием платежей в пользу операторов сотовой связи.

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

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

1.2 Диаграмма вариантов использования

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой [2]. Диаграмма вариантов использования показана на рисунке 1.

Рисунок 1 - Диаграмма вариантов использования

1.3 Диаграмма классов

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

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

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

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

Рисунок 2 - Диаграмма классов

2. Анализ требований к программному обеспечению

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

- выбор сотового оператора;

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

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

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

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

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

Основные требования, предъявляемые к качеству ПО:

1.Надежность.

- Устойчивость к отказам.

- Способность к восстановлению работоспособности при отказах.

2.Практичность, удобство использования.

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

- Удобство обучения.

- Простота и удобство использования программы. (Это требование относится прежде всего к интерфейсу пользователя).

3.Эффективность.

- Временные характеристики.

- Использование ресурсов (Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач).

4.Сопровождаемость.

- Изменяемость, удобство внесения изменений.

5.Переносимость, мобильность.

- Адаптируемость (Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии).

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

7.Возможность отката на предыдущую версию (roll-back). 8.Возможность интеграции с автоматическими тестерами (типа Rational Robot и т.д.).

9.Простота конфигурации системы.



3. Техническое задание на разработку

3.1 Введение

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

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

Финансирование не предусмотрено.

3.2 Требования к программе

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

- выбор сотового оператора;

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

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

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

- печать чека, подтверждающего выполнение операции.

Требования к обеспечению надежного функционирования программы

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

- организацией бесперебойного питания технических средств;

- использованием лицензионного программного обеспечения;

- регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств";

- регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.

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

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

Отказы из-за некорректных действий пользователей системы. Отказы программы возможны вследствие некорректных действий оператора (пользователя) при взаимодействии с операционной системой.

3.3 Условия эксплуатации

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

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

- задача поддержания работоспособности технических средств;

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

- задача установки (инсталляции) программы;

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

Требования к составу и параметрам технических средств

В состав технических средств должны входить:

- стандартный терминал для приема платежей;

- серверная станция.

Серверная станция должна иметь следующие характеристики:

- универсальный 2-процессорный 4U сервер для монтажа в стойку STSS Flagman RX247.3-036LH;

- до 2-х процессоров Intel Xeon серий E5-2600 v2 (до 12 ядер, до 30MB L3 cache, до 8.0GT/s QPI) или E5-2600 (до 8 ядер, до 20MB L3 cache, до 8.0GT/s QPI);

- до 1536 ГБ оперативной памяти DDR3-1866 ECC Registered или Unbuffered;

- дисковая подсистема до 36-ти 3.5" SATA/SAS HDD/SSD с горячей заменой + до 2-х фиксированных 2.5" SATA/SAS HDD/SSD;

- 4-канальный интегрированный сетевой адаптер 1 Гбит/с;

- система удалённого управления сервером IPMI 2.0 Server Management with KVM-over-LAN & Virtual-media-over-LAN;

- отказоустойчивая 1+1 система электропитания с поддержкой горячей замены блоков питания

Сервер с установленным программным обеспечением:

- ОС: MS Windows Server, Linux, Solaris, FreeBSD;

- от Delphi 2007 до Delphi XE8;

- SQL-сервер MySQL 5.1 выше.

Клиентский компьютер (на терминальной станции) с ОС: MS Windows Server, Linux, Solaris, FreeBSD, прикладное ПО - Delphi 2007, Delphi XE8.

Клиентский компьютер с одним из установленных браузеров: Microsoft Internet Explorer v6 и выше, Mozilla Firefox 3.0 и выше, Google Chrome 3.0 и выше, Safari 3.0 и выше, Opera 9.0 и выше.



4. Выбор метода разработки программного обеспечения

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

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

Достоинства модульных программ следующие:

– легко составляются и отлаживаются. Функциональные компоненты такой программы могут быть написаны и отлажены порознь.

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

Недостатки модульности:

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

– может потребоваться несколько больший объем памяти, если каждой подпрограмме отводится отдельная часть рабочей памяти.

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

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

Преимущества ООП:

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

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

– объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;

– объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

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

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

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

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

Параллельное программирование включает в себя все черты более традиционного, последовательного программирования, но в нем есть три дополнительных, четко определенных этапа:

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

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

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

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

В ООП используется важное понятие "класс", т.е. абстрактное представление чего-либо, тогда как объект является используемым экземпляром того, что представляет класс.

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

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

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

Методами называют действия, которые объект может выполнить. Это процедуры или функции, которые выполняются в ответ на какой-либо запрос (нарисовать, изменить размер, переместить и т. П.). При этом метод, который должен вызываться в ответ на запрос, определяется классом, экземпляром которого является данный объект. И наоборот, если объекты принадлежат к одному и тому же классу, то они должны вызывать одинаковые методы в ответ на один и тот же запрос.

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

4.1 Выбор языка программирования

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

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

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

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

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

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

– создавать оболочки для баз данных, как и сами базы данных;

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

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

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

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

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

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

Выше перечисленными свойствами обладают языки программирования:

– Visual C++;

– Java;

– Delphi.

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

C++ (Си++). Объектно-ориентированное расширение языка Си, созданное Бьярном Страуструпом в 1980 году.Множество новых мощных возможностей, позволивших резко повысить производительность программистов, наложилось на унаследованную от языка Си определенную низкоуровневость. В результате чего создание сложных и надежных программ требует от разработчиков высокого профессионального уровня. В основе языка C - требования системного программиста: полный и эффективный доступ ко всем ресурсам компьютера, средства программирования высокого уровня, переносимость программ между различными платформами и операционными системами. С++, сохраняя совместимость с C, вносит возможности объектно-ориентированного программирования, выражая идею класса (объекта) как определяемого пользователем типа. Благодаря перечисленным качествам, C/C++ занял позицию универсального языка для любых задач.

Java (Джава, Ява). Этот язык был создан компанией Sun в начале 90-х годов на основе Си++. Он призван упростить разработку приложений на основе Си++ путем исключения из него всех низкоуровневых возможностей. Но главная особенность этого языка - компиляция не в машинный код, а в платформно-независимый байт-код (каждая команда занимает один байт). Этот байт-код может выполняться с помощью интерпретатора - виртуальной Java-Maшины JVM(JavaVirtualMachine), версии которой созданы для любых платформ. Благодаря наличию множества Java-машин программы на Java можно переносить не только на уровне исходных текстов, но и на уровне двоичного байт-кода, поэтому язык Ява стал очень популярным. Особое внимание в развитии этого языка уделяется двум направлениям: поддержке всевозможных мобильных устройств и микрокомпьютеров, встраиваемых в бытовую технику (технология Jini) и созданию платформно-независимых программных модулей, способных работать на серверах в глобальных и локальных сетях с различными операционными системами (технология JavaBeans). Пока основной недостаток этого языка - невысокое быстродействие, так как язык Ява интерпретируемый.

Delphi 2007 for Win32 компании CodeGear , подразделения компании Borland . Назначение - быстрое создание приложений (RapidApplicationDeveloping, RAD). Язык программирования Delphi - язык программирования, который используется в одноимённой среде разработки и является комбинацией нескольких важнейших технологий:

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

– объектно-ориентированнаямоделькомпонент;

– визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов;

– масштабируемые средства для построения баз данных.

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

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

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

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

Преимущества Delphi по сравнению с аналогичными программными продуктами.

– быстрота разработки приложения;

– высокая производительность разработанного приложения;

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

– наращиваемость за счет встраивания новых компонентов и инструментов в среду Delphi;

– возможность разработки новых компонентов и инструментов собственными средствами Delphi (существующие компоненты и инструменты доступны в исходных кодах);

– удачная проработка иерархии объектов.

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

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



5. Основная часть

Для разрабатываемой системы приема платежей с терминальных станций используется архитектура Интранет в реализации клиент - сервер.

Архитектура Интранет в среде Delphi реализована следующим образом.

1. Каждый клиент имеет доступ к данным Web-сервера посредством своего броузера.

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

3. Связь с БД и создание приложений работы с БД реализуется через следующие задачи:

- отображение данных пользователю;

- механизм организации передачи данных "приложение - БД";

- Генерация отчетов и диаграмм

Первая задача решается компонентами Delphi с закладки DataControls, что позволяет отображать данные пользователю.

Реализация задачи механизма организации передачи данных в Delphi 2007 "приложение - БД" обеспечивается с помощью двух технологий взаимодействия приложений DCOM и CORBA. Они представлены компонентами Provider и ClientDataSet.

В качестве движка работы с серверами БД используется новая технология dbExperss (многоплатформенная). Компоненты размещены на закладке ADO в Delphi 7. Набор компонентов включает:

- SQLConnection - соединение с БД. Данный компонент по функции аналогичен ADOConnetion, т.е позволяет настроить параметры связи с сервером БД;

- SQLQuery, SQLTable, SQLDataSet, SQLStoredProc - компоненты работы с объектами БД. В документации эти компоненты названы unidirectional datasets;

- SQLMonitor - компонент регистрации событий работы с БД;

- SQLClientDataSet - компонент доступа к данным (client dataset).

Все компоненты типа DataSet делятся на два типа

- Unidirectional

- Client dataset

Unidirectional - данный вид набора данных предназначен для извлечения данных через SQL запросы. Он позволяет двигаться по данным только вперед (согласно сортировке заданной order by) и не кэширует изменения, что делает его более быстрым и менее требовательным к ресурсам. Однако, он не позволяет пользователю редактировать данные, накладывать фильтры и Lookup.

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

На основе всего вышесказанного, в системе Delpfi 2007 можно использовать несколько архитектур взаимодействия с БД: файл- сервер, двухзвенную архитектуру клиент- сервер, трехзвенную архитектуру.

Выбрана двухзвенная архитектуру клиент- сервер, представленная на рисунке 3.

Рисунок 3- Двухзвенная архитектура клиент- сервер



Для создания классического двухуровневого клиент-сервера в системе Delpfi 2007 существует архитектура доступа к серверам БД. В качестве SQL client dataset используется компонент SQLClientDataSet, объединяющий (Table, Query, StoredProc). Он может отображать данные в элементах управления, вставлять и редактировать их.

Разработка приложений для Internet реализуется с помощью набора компонентов для работы с Internet, обеспечивающих работу с многими сервисами интернета (сокеты TCP и UDP, DNS, FTP итд). Причем для многих протоколов реализованы не только клиенты, но и серверы.

Разделение приложений и серверной части БД представлено на рисунке 2 - Диаграмма классов.



6. Реализация разработки

6.1 Характеристика комплекса задач

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

– возможность выбора сотового оператора;

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

– ввод номера счёта для оплаты кредита с возможностью проверки его корректности и исправления;

– возможность контроля суммы внесённого платежа;

– возможность печати чека, подтверждающего выполнение операции;

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

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

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

6.2 Разработка интерфейса пользователя

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

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

Рисунок 4 - Главное окно программы

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

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

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

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

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

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

Принцип простоты. Наиболее распространенные операции должны выполняться максимально просто. При этом должны быть видимые ссылки на более сложные процедуры.

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

Рисунок 5 - Пример выполнения операции



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

Рисунок 6 Режим перехода к следующему этапу операции

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

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

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

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

2. Непосредственное манипулирование. Таким образом, имеется ряд способов, которыми пользователь мог бы связываться с компьютером:

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

– вопрос и ответ -- диалог, где компьютер задает вопросы, а пользователь отвечает ему (или наоборот);

– формы -- пользователь заполняет формы или поля диалога, вводя данные в соответствующие поля;

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

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

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

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

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

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

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

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

Рисунок 7-Цветовое решение интерфейса

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

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

Рисунок 8 - Непротиворечивость и стандартизация интерфейса

Формы. Формы -- основной элемент интерфейса. Назначение форм -- удобный ввод и просмотр данных, состояния, сообщений автоматизированной системы.

Основные принципы проектирования форм:

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

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

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

– логические группы элементов необходимо отделять пробелами, строками, цветовыми или другими визуальными средствами;

– взаимозависимые или связанные элементы должны отображаться в одной форме.

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

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

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

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

Организация системы навигации и системы отображения состояний.

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

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

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

– выбрать из предложенных альтернатив опцию или набор опций;

– ввести информацию;

– выбрать опцию из набора опций, которые могут изменяться в зависимости от текущего контекста;

– подтвердить фрагмент введенной информации перед продолжением ввода.

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

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

– принудительные действия в системе, которые предотвращают или затрудняют появление ошибок;

– обеспечение хороших и информативных сообщений об ошибках;

– использование обратимых действий, позволяющих пользователям исправлять их собственные ошибки;

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

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

6.3 Разработка программного продукта

В приложении, согласно разработанному интерфейсу, автоматически описывается новый класс Tforml, являющийся наследником класса (Tform). Объявляется новая переменная Forml типа Tforml, через которую можно получитьдоступ к свойствам, методам и событиям формы. Описание класса Tform1: Label1 - дата;

Label2 - время;

Label3 - подсказка;

Label4 - подсказка и отображение внесенных средств;

Edit1 - номер счета/телефона;

procedurestarttime - определяется дата;

procedure reg1 (reg2, reg3) - отвечают за скрытие/отображение элементов;

procedurechek и labnastr - формирование чека;

procedurebuttonsAndKeybrdCreate - создание элементов управления;

procedurebuttonsnastr = настройка надписей и изображений на кнопках buttons;

procedure Timer1Timer - обновление времени в Label2.

Переменные Var:

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

phone - маскаполя Edit:.

ButtonsAndKeybrdCreate;

phone:='+7 ( ) - - - `;

buttons - массив кнопок на главной странице (Tmybutton);

keybrd - массив кнопок клавиатуры + кнопка удалить (Tkeyboard);

navigat - массив кнопок навигации (Tnavigator). С помощью нового класса организована навигация по основным операциям приложения: