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

АКАДЕМИЯ МАРКЕТИНГА И СОЦИАЛЬНО-ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ — ИМСИТ (г. Краснодар) Факультет информатики и вычислительной техники Кафедра математики и вычислительной техники ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА на тему: «Разработка программного обеспечения для терминалов приема платежей за услуги связи» (по материалам ООО Фирмы «Теплостройсервис», г. Краснодар) Краснодар

Реферат

ТЕРМИНАЛЫ ПРИЕМА ПЛАТЕЖЕЙ, 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 составляет 29 470 рублей. В данную поставку входят интеграция нового поставщика, редактирование формата и вида реестра, генерация доступа к личному кабинету, программирование интерфейса, программирование чека и сценария платежа, настройку простого меню до 8 позиций и простого чека. Таким образом, программирование интерфейса, программирование чека и сценария платежа, настройку простого меню до 8 позиций и простого чека составляют половину пакета услуг по программированию терминалов приема платежей, что составляет около15 000 рублей на каждый терминал. Было принято решение о разработке собственного программного продукта, входящего в программно-аппаратный комплекс, возможности которого позволяют организовать прием платежей в пользу операторов сотовой связи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— регулярным выполнением требований ГОСТ 51 188–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). С помощью нового класса организована навигация по основным операциям приложения:

casei of

1: begin

caption:='Далее'; top:=650; left:=1100;

end;

2: begin

caption:='Назад'; top:=650; left:=16;

end;

3: begin

caption:='НаГлавную'; top:=650; left:=565;

color:=rgb (236,159,45);

end;

4: begin

font.Size:=22;

caption:='Погашениекредитов';

width:=300;

top:=250; left:=10;

visible:=true;

end;

end;

stat — номер действия (главная страница = 0, ввод номера = 1, проверка данных = 2, внесение наличных = 3). В зависимости от номера действия организовано динамическое изменение вида формы (Рисунок 2−5):

a:=tnavigator (self);

casea.index of

1: begin

case stat of

1: begin

stat:=2; form1. reg2(true);

form1.Label3.Caption:='Проверкавведенныхданных';

end;

2: begin

stat:=3; form1. reg3(true);

form1.Label3.Caption:='Внеситеналичные';

end;

3: begin

form1.Label4.Visible:=false;

form1.Label3.Caption:='Возьмитечек';

form1.chek;

end;

end;

end;

2: begin

case stat of

1: begin

stat:=0; form1. reg1(false);

form1.Label3.Caption:='Выберитеоператора';

form1.ButtonsNastr (true);

navigat[4]. Visible:=true;

end;

2: begin

stat:=1; form1. reg2(false);

form1.Label3.Caption:='Введитеномер';

end;

3: begin

stat:=2; form1. reg3(false);

form1.reg2(true);

form1.Label3.Caption:='Проверкавведенныхданных';

end;

end;

end;

3: begin

stat:=0; form1. reg1(false);

form1.Label3.Caption:='Выберитеоператора';

form1.label4.Visible:=false;

navigat[1]. Caption:='Далее';

form1.Panel1.Visible:=false;

navigat[4].Visible:=true;

form1.buttonsnastr (true);

end;

4: begin

form1.ButtonsNastr (false);

navigat[4]. Visible:=false;

navigat[3].Visible:=true;

end;

end;

money, komis — внесенная сумма и комиссия от нее;

labels — массив полей для формирования чека;

nam — имя получателя;

number — строка с введенным номером из поля Edit1.

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

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

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

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

В программе созданы несколько новых классов с использованием переопределения методов при наследовании (Рисунки 9 и 10).В классе-потомке при этом используется специальный модификатор override.

Класс Tnavigator. Кнопки навигации: Назад, На Главную, Далее:

Tnavigator=class (Tpanel)

procedure click; override;

private

index:integer;

end;

КлассTkeyboard. Клавиатура (от 1 до 0 и кнопка Удалить):

Tkeyboard=class (Tpanel)

procedureclick;override;

private

number:string;

end;

Рисунок 9- Класс Tnavigator и класс Tkeyboard

Класс Tmybutton. Кнопки на главной странице.

Tmybutton=class (Tpanel)

procedureclick;override;

private

Index:integer;

icon:timage;

end;

Рисунок 10- Класс Tmybutton. Кнопки на главной странице При создании нового экземпляра класса вначале вызываются конструкторы всех родительских классов (начиная с самого высшего уровня иерархии), наследником которых является данный класс, и только затем выполняется конструктор самого класса. Объявить и создать новый объект можно следующим образом: В разделе var объявляется переменная, имеющая тип требуемогокласса:

var

Form1: Tform1;

buttons:array[1.n] of Tmybutton;

keybrd:array[1.m] of tkeyboard;

navigat:array[1.4] oftnavigator;

Затем в тексте программы с помощью вызова конструктора Create создается новый экземпляр указанного класса, ссылка на который присваивается описанной переменной, например:

for i:=1 to n do

begin

buttons[i]: =tmybutton.Create (self);

withbuttons[i] do

В программе организованы режимы проверки введенных данных и визуальный контроль действий операций пользователя (Рисунки 11 и 12).

Рисунок 11 - Проверка данных

Рисунок 12 - Внесение наличных

Первоначально формирование чека было организовано в пользовательской процедуреForm1. Сhek при этом надписи в чеке печатались друг на друге (Рисунок 13).

Рисунок - 13 Некорректная печать чека

Эта ошибка была исправлена путем переноса процедуры создания полей чека из пользовательской процедуры в событийную процедуру FormCreate (Рисунок 14).

Рисунок 14 — Корректная печать чека

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

7.1 Руководство пользователя При входе на главную страницу пользователь (плательщик) видит основное меню, которое содержит:

— меню выбора оператора;

— меню погашения кредита.

Интерфейс представлен ранее на рис.15

После выбора оператора пользователь переходит на страницу «введите номер», представленную на рисунке 15.

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

Осуществляется переход на страницу проверки номера. Страница представлена ранее на рисунке 11.

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

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

Рисунок 17 — Страница выбора банка После выбора банка пользователь перенаправляется на страницу ввода номера счета, организованную аналогично странице ввода номера телефона. После ввода номера счета пользователь перенаправляется на страницу проверки правильности данных, представленную на рисунке 18.

Рисунок 18 — Страница проверки правильности ввода номера счета После нажатия на функциональную клавишу «далее» происходит перенаправление на страницу печати чека, аналогичную странице печати чека оплаты сотового оператора, представленную ранее на рисунке 14. Происходит печать чека. На данной странице есть функциональная клавиша «на главную», при нажатии на которую пользователь может перейти на страницу входа и осуществить новые операции.

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

В состав проекта входит несколько файлов и каталогов.

После того как приложение Win32 было спроектировано и сохранено, в каталог проекта помещаются следующие основные файлы:

— Projectl. dproj — файл группы проектов;

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

— Projectl. Res — файл ресурсов приложения. Двоичный файл, содержащий все необходимые для проекта ресурсы (пиктограммы, указатели мыши, графические изображения или строки). Название у него такое же, как и у файла проекта.

— Projectl. exeфайл приложения;

— Unitl. dfm — файл, определяющий внешний вид формы;

Unitl.pas — файл исходного кода модуля.

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

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

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

(1)

где С — стоимость;

Т — трудозатраты (например, в человеко-часах или человеко-месяцах);

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

Трудозатраты вычисляют по следующей формуле:

(2)

Здесь Р — размер кода программы;

П — временная производительность.

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

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

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

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

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

— внешние запросы;

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

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

Далее полученные значения умножаются на коэффициенты сложности для каждого фактора (по данным IFPUG) и суммируются для получения полного размера программного продукта. Значения этих коэффициентов приведены в таблице 1.

Таблица 1 — Значения коэффициентов сложности

Для рассматриваемого нами примера возьмем значения, приведенные в таблице 2.

Размер нашей функции составит:

Это число является предварительной оценкой и нуждается в уточнении.

Таблица 2 — Пример коэффициентов сложности

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

1.Требуется ли резервное копирование данных?

2.Требуется обмен данными?

3.Используются распределенные вычисления?

4.Важна ли производительность?

5.Программа выполняется на сильно загруженном оборудовании?

6.Требуется ли оперативный ввод данных?

7.Используется много форм для ввода данных?

8.Поля базы данных обновляются оперативно?

9.Ввод, вывод, запросы являются сложными?

10.Внутренние вычисления сложны?

11.Код предназначен для повторного использования?

12.Требуется преобразование данных и установка программы?

13.Требуется много установок в различных организациях?

14.Требуется поддерживать возможность настройки и простоту использования?

Значения для данных характеристик определяются следующим образом: 0 — никогда; 1 — иногда; 2 — редко; 3 — средне, 4 — часто; 5 — всегда. Эти характеристики для примера функции сведены в таблице 3.

Таблица 3 — Пример характеристик проектов

Определяется S — сумма всех весов.

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

(3)

[Уточненный функциональный размер] =[Приближенный функциональный размер] * [0,65+0,01 * (Сумма общих характеристик)]. Суть этой формулы состоит в том, что неуточненный функциональный размер нужно уменьшить на 35%. И если к приложению предъявляется специальные требования (не все общие характеристики — нули), то каждая единица этих общих характеристик увеличивает результат на 1%. Уточненный функциональный размер функции выбор метода будет следующим:

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

Количество строк кода по функциональному размеру можно вычислить с помощью стандартных таблиц. В свою очередь, количество строк кода позволяет определить общую трудоемкость в человеко-месяцах и сроки проекта. Например, в известна следующая величина: 23 строки исходного кода на Delphi на одну единицу функционального размера. Используя этот коэффициент, имеем 39×53 = 0,9 тыс. строк на Delphi.

Переведем теперь эти цифры в человеко-месяцы согласно формуле COCOMO (Конструктивная модель стоимости — Constructive Cost Model)

y = 0,9x^1.05, (4)

где x — тысячи строк кода. Получим оценку 0,9*2,7^1.05 = 2,5 человеко-месяцев.

Далее человеко-месяцы умножаются на оклад сотрудника разработчика в соответствии с формулой (1). При окладе 15 000 рублей стоимость разработки будет приблизительно равна 37 500 рублей. Учитывая тот факт, что осуществляется переход ООО «Теплостройсервис» от дилерской схемы работы к самостоятельному обслуживанию терминалов оплаты за услуги связи, данная стоимость проекта является оправданной.

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

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

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

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

Работа с компьютером входит в состав вредных для здоровья человека работ. Так оператор подвержен таким заболеваниям, как воспаление кожи и дерматиты, так как пыль, накапливающаяся на экране из-за электростатического поля, летит на оператора. Человек, сидящий за дисплеем, может подвергаться воздействию низкоэнергетического рентгеновского и ультрафиолетового излучения, электромагнитного излучения (экраны наиболее интенсивно излучают на частотах 10.4 — 15 КГц — частоте строчной развертки), статического электричества; возникающего в результате облучения экрана потоком заряженных частиц электронной трубки, а также воздействию шума, неудовлетворительного освещения и микроклимата. Помимо всего сказанного, работа за компьютером относится к психическим формам труда, так как необходимо воспринимать изображение на экране, постоянно следить за его динамикой, различать тексты рукописных или печатных материалов и т. П. Также сидячая поза во время работы может приводить к таким симптомам, как боли в спине и области шеи, ухудшение зрения, боли в кистевых и плечевых суставах, нарушение сна, вызванного перенапряжением, хронические головные боли, тошнота, слабость.

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

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

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

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

Измерения рентгеновского излучения перед экраном цветного дисплея показали, что на расстоянии 5 см от экрана мощность дозы составляет 100 мкГр/ч, а на расстоянии 250 см от экрана — 0.0025 мкГр/ч. Конструкция видеомониторов должна обеспечивать величину эквивалентной дозы рентгеновского излучения в любой точке на расстоянии 0.05 м от экрана и корпуса монитора не более 0.1 мбэр/час (100 мкР/час).

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

Особое внимание следует обратить на статическое электричество. Измерения показывают, что напряженность электростатического поля в рабочей зоне, как отечественных, так и импортных дисплеев достигает 85−62 кВ/м, при норме 20 кВ/м в течение часа (ГОСТ 12.1.045.84).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с требованиями ГОСТ 12.1.004−91 пожарная безопасность объекта обеспечивается: системой предотвращения пожара; системой противопожарной защиты; организационно-техническими мероприятиями. Для этого применяется огнезащита материалов и конструкций, используются противопожарные преграды (внутренние и наружные противопожарные стены, перегородки, перекрытия, противопожарные зоны), применяются противопожарную защиту зданий. В производственных помещениях необходимо также иметь первичные средства пожаротушения, которыми можно производить тушение пожаров на начальной стадии (огнетушители). Для тушения пожара в помещении с ПЭВМ необходимо применять газовые составы — хладоны, инертные разбавители, порошки.

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

Для успешной эвакуации персонала необходимо предусмотреть следующие требования к зданиям, где располагается помещения с ПЭВМ: количество эвакуационных выходов из помещений и зданий в целом определяется с учетом безопасности (не менее двух); минимальная ширина дверей на путях эвакуации — 0,8 м, а проходов — не менее 1 м; коридоры и проходы, предназначенные для эвакуации, имеют возможно меньшую длину и минимальное количество поворотов; двери на путях эвакуации открываются по направлению выхода из здания; лестницы имеют удобную для эвакуации связь с этажами и в то же время надежную изоляцию от них, исключающую воздействие на них факторов пожара.

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

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

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

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

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

Заключение

В результате работы над выпускной квалификационной работой решена задача, создания прикладного программного продукта для реализации пользовательского интерфейса терминалов по приему платежей от населения. Данная задача ставилась ООО Фирмой «Теплостройсервис» при переходе с дилерского обслуживания терминалами оплаты населения к созданию собственной сети на основе своего программного обеспечения. Данное пользовательское приложение интегрируется с единую систему проведения платежей от населения в банки и операторам сотовой связи. Приложение реализовано в среде Delpfi 2007, которое является клиентской частью архитектуры клиент-сервер. В работе представлена модель классов системы перевода платежей с с клиентской и серверной частью в виде базы данных. Реализация клиент серверной технологии через Интернет осуществляется по технологии CORBA, встроенной в систему разработки Delpfi 2007.

Разработанное приложение на основе технологии объектно-ориентированного программирования обеспечивает удобный пользовательский интерфейс, реализующий заданный функционал ввода данных о платежах: выбор услуги (оплата сотовой связи или погашение кредитов), выбор получателя платежа в рамках услуги, ввод номера счета или телефона сотового оператора, возможность проверки веденных данных, передачу данных на сервер и запись в таблицу базы данных, вывод чека, печать чека. Данное приложение является легко расширяемым и при необходимости может быть дополнено банками — получателями платежа или операторами связи, например, с которыми будет заключен договор у ООО Фирмы «Теплостройсервис» .

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

и литературы

1. Голицина, О. Л. Программирование на языках высокого уровня [Текст] / О. Л. Голицина, И. И. Попов.- М.: ФОРУМ, 2011. 496 с.

2. Джексон, Г. Проектирование реляционных баз данных [Текст] / Г. Джексон. — М.: Мир, 2011. — 298 с.

3. Долгоруков, А. Метод case как современная технология профессионально-ориентированного проектирования [Электронный ресурс] / А. Долгоруков. — // КОРНИ. — Режим доступа: http://www.evolkov.net/case/case.develop.html.

4. Емельянова, Н. З. Основы построения автоматизированных информационных систем: Учеб. Пособие [Текст] / Н. З. Емельянова, Т. Л. Партыка, И. И. Попов — М.: Форум: Инфра-М, 2011. — 412с.

5. Зиндер, Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие [Текст]/ Е. З. Зиндер — М.: Центр Информационных Технологий. — 2010. — 135 с.

6. Интернет-Университет Информационных Технологий. Элементы графической нотации диаграммы классов [Электронный ресурс]. — Режим доступа: http://www.intuit.ru/department/pl/umlbasics/5/

7. Интернет-Университет Информационных Технологий.

Введение

в Delphi 2007 [Электронный ресурс]. — Режим доступа: http://www.intuit.ru/department/pl/ Delphi /1/

8. Информационные системы: Диаграмма вариантов использования [Электронный ресурс]. — Режим доступа: http://www.business-process.ru/designing/methodology/uml/theory/use_case_diagram_theory.html

9. Карпова, Т. А. Базы данных. Модели, разработка, реализация [Текст]/Т.А. Карпова. — СПб: Питер. — 2012. — 304 с.

10. Карпова, Т. С. Базы данных. Модели, разработка, реализация [Текст] / Т. С. Карпова. — СПб.: Питер, 2012. — 236 с.

11. Крёнке, Д.А., Теория и практика построения баз данных. З-е изд. [Текст] / Д. А. Крёнке — СПб.: Питер, 2010 — 859 с.: ил.

12. Макаровских, Т. А. Документирование программного обеспечения. В помощь техническому писателю [Текст] / Т. А. Макаровских. — СПб.: Ленанд. — 2015. — 356 с.

13. Маклаков, С. В. UML 2.0. Руководство по применению [Текст]/ Маклаков С. В. — М.: ДИАЛОГ-МИФИ. — 2011. — 256 с.

14. Маленко, Д.Ю., Новые возможности для разработчиков SQL Server [Текст] / Д. Ю. Маленко — М.: СОЛОН-Пресс, 2011. — 208с.: ил.

15. Саммерфилд, М. Программирование на Delphi. Подробное руководство. — Пер. с англ. [Текст] / М. Саммерфилд. — СПб.: Символ-Плюс, 2012. — 608с.

16. Синтес, А. Объектно-ориентированное программирование [Текст] / А. СинтесМ.: Вильямс, 2012. — 672 с.

17. Сухомлин, В.А. Объектно-ориентированные CASE-технологии. Учебное пособие [Текст]/ проф. В. А. Сухомлин. — М.: МГУ. — 2011. — 134 с.

18. Фаронов, В. В. Delphi. Программирование на языке высокого уровня: Учебник для вузов[Текст]/ В. В. Фаронов. — Спб.: Питер, 2012. — 348с.

19. Черемных, С. В. Моделирование и анализ систем. UML 2.0: практикум [Текст] / С. В. Черемных, И. О. Семенов, B.C. Ручкин — М.: Финансы и статистика, 2010. 192 с.

20. Эванс, Э. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем [Текст] / Э. Эванс — М.: Вильямс — 2012. — 562с.

21. Эренковский, В. А. Безопасность работы за компьютером: Учебное пособие [Текст] /В.А. Эренковский.- Спб.: Питер, 2012. — 348с.

Приложение, А Листинг программы главной формы

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, ExtCtrls, Buttons, GIFImg;

const

day:array[1.7] of string=('Воскресенье','Понедельник','Вторник','Среда','Четверг','Пятница','Суббота');

n=4; m=11; z=6;

type

TForm1 = class (TForm)

Label1: TLabel;

Label2: TLabel;

Timer1: TTimer;

Label3: TLabel;

Edit1: TEdit;

Image1: TImage;

Label4: TLabel;

Panel1: TPanel;

procedure FormCreate (Sender: TObject);

procedure StartTime;

procedure reg1(show:boolean);

procedure reg2(show:boolean);

procedure reg3(show:boolean);

procedure chek;

procedure labnastr (lab:tlabel; t, l: integer; cap: string);

procedure ButtonsAndKeybrdCreate;

procedure ButtonsNastr (reg:boolean);

procedure Timer1Timer (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

Tnavigator=class (Tpanel)

procedure click; override;

private

index:integer;

end;

Tkeyboard=class (Tpanel)

procedure click;override;

private

number:string;

end;

Tmybutton=class (Tpanel)

procedure click;override;

private

Index:integer;

icon:timage;

end;

var

Form1: TForm1;

buttons:array[1.n] of TMybutton;

keybrd:array[1.m] of tkeyboard;

navigat:array[1.4] of tnavigator;

c:tcolor;

curs:integer;

phone:string;

stat:integer;

money, komis: integer;

labels:array[1.z] of tlabel;

nam, number: string;

implementation

{$R *.dfm}

procedure tform1. ButtonsNastr (reg: Boolean);

var

a:string;

i:integer;

begin

if reg then

begin

a:='.bmp';

buttons[1]. Caption:='МТС';

buttons[2].Caption:='Билайн';

buttons[3].Caption:='Мегафон';

buttons[4].Caption:='TELE2';

buttons[1].icon.top:=20;

label3.Caption:='Выберите оператора';

end

else

begin

a:='_1.bmp';

buttons[1]. Caption:='Сбербанк России';

buttons[2]. Caption:='УралСиб';

buttons[3].Caption:='Альфа-банк';

buttons[4].Caption:='Россельхозбанк';

buttons[1].icon.top:=5;

label3.Caption:='Выберите банк';

end;

for i:=1 to n do

begin

try

if reg then buttons[i]. Index:=i

else buttons[i]. Index:=i+4;

image1.Picture.LoadFromFile (inttostr (buttons[i].Index)+'.gif');

buttons[i].icon.Picture.Assign (image1.Picture);

except

showmessage ('Файл '+inttostr (buttons[i]. Index)+'.gif'+' не найден в папке с программой.');

end;

end;

end;

procedure tform1. labnastr (lab: TLabel; t: Integer; l: Integer; cap: string);

begin

lab.Top:=t; lab. Left:=l; lab. Caption:=cap;

end;

procedure tform1. chek;

var

i:integer;

number1:string;

p:integer;

a:integer;

begin

number1:='';

if number[1]='+' then a:=5

else a:=1;

for i:=a to 23 do

begin

try

p:=strtoint (number[i]);

if ((p>=0)and (p<=9)) then number1:=number1+number[i];

except

continue;

end;

end;

labnastr (labels[1], 30,5,'Получатель: '+nam);

labnastr (labels[2], 55,5,'Принято: '+inttostr (money)+' руб.');

labnastr (labels[3], 80,5,'Зачислено: '+inttostr (money-komis)+' руб.');

labnastr (labels[4], 105,5,'Комиссия: '+inttostr (komis)+' руб.');

labnastr (labels[5], 130,5,'Номер телефона/счета: '+number1);

labnastr (labels[6], 155,5,'Дата: '+datetostr (now)+' '+timetostr (now));

panel1.Width:=250; panel1. Height:=200;

panel1.left:=550; panel1. Top:=200;

panel1.Visible:=true;

panel1.Caption:='';

navigat[1]. Visible:=false;

navigat[2].Visible:=false;

end;

procedure tform1. reg1(show:boolean);

var

i:integer;

begin

for i:=1 to 3 do

begin

if (show and (i=1)) then continue;

navigat[i]. Visible:=show;

end;

for i:=1 to m do keybrd[i]. Visible:=show;

for i:=1 to n do buttons[i]. Visible:=not show;

Edit1.Visible:=show;

Image1.Visible:=show;

end;

procedure tform1. reg2(show:Boolean);

var

I:integer;

begin

for i:=1 to m do keybrd[i]. Visible:=not show;

label4.Caption:='Проверьте правильность введенныхо Вами данных.';

label4.Caption:=label4.Caption+#13+'Если Вы допустили ошибку — вернитесь назад,';

label4.Caption:=label4.Caption+' иначе — '+#13+'нажмите Далее';

label4.Visible:=show;

label4.Font.Size:=16;

navigat[1]. Caption:='Далее';

end;

procedure tform1. reg3(show: Boolean);

var

i:integer;

begin

number:=edit1.Text;

image1.Visible:=not show;

edit1.Visible:=not show;

label4.Font.Size:=26;

label4.Caption:='Внесено '+inttostr (money)+' руб.'+#13;

komis:=money-(money div 10);

label4.Caption:=label4.Caption+#13+'К зачислению '+inttostr (money-komis)+' руб.'+#13;

label4.Caption:=label4.Caption+#13+'Комиссия '+inttostr (komis)+' руб.';

navigat[1]. Caption:='Оплатить';

end;

procedure tform1. ButtonsAndKeybrdCreate;

var

i, t, l:integer;

begin

t:=150;

for i:=1 to n do

begin

buttons[i]: =tmybutton.Create (self);

with buttons[i] do

begin

parent:=form1;

width:=600; height:=110;

top:=t; left:=400;

font.Size:=26; font. Color:=clWhite;

parentbackground:=false;

color:=c;

borderstyle:=bssingle;

index:=i;

icon:=timage.Create (self);

with icon do

begin

parent:=buttons[i];

width:=200; height:=98;

if i=1 then top:=20

else top:=5;

left:=10;

proportional:=true;

transparent:=true;

end;

end;

t:=t+buttons[i]. Height+15;

end;

buttonsnastr (true);

t:=215; l:=525;

for i:=1 to m do

begin

keybrd[i]: =tkeyboard.Create (self);

with keybrd[i] do

begin

parent:=form1;

width:=100; height:=100;

top:=t; left:=l;

parentbackground:=false;

color:=c;

font.Size:=26; font. Color:=clwhite;

caption:=inttostr (i);

number:=inttostr (i);

visible:=false;

borderstyle:=bssingle;

end;

l:=l+keybrd[i]. width+15;

if i mod 3=0 then begin t:=t+keybrd[i]. Height+5; l:=525; end;

end;

keybrd[10]. Width:=(keybrd[10].Width*3)+30;

keybrd[10].Caption:='0';

keybrd[10].number:='0';

keybrd[11].Top:=edit1.Top-45;

keybrd[11].Left:=1015;

keybrd[11].Height:=edit1.Height+40;

keybrd[11].Width:=175;

keybrd[11].Caption:='Удалить';

for i:=1 to 4 do

begin

navigat[i]: =tnavigator.Create (self);

with navigat[i] do

begin

parent:=form1; visible:=false;

width:=250; height:=100;

index:=i;

font.Size:=30; font. Color:=clwhite;

borderstyle:=bssingle;

parentbackground:=false;

color:=c;

case i of

1: begin

caption:='Далее'; top:=650; left:=1100;

end;

2: begin

caption:='Назад'; top:=650; left:=16;

end;

3: begin

caption:='На Главную'; top:=650; left:=565;

color:=rgb (236,159,45);

end;

4: begin

font.Size:=22;

caption:='Погашение кредитов';

width:=300;

top:=250; left:=10;

visible:=true;

end;

end;

end;

end;

end;

procedure tnavigator. Click;

var

a:tnavigator;

i:integer;

begin

a:=tnavigator (self);

case a. index of

1: begin

case stat of

1: begin

stat:=2; form1. reg2(true);

form1.Label3.Caption:='Проверка введенных данных';

end;

2: begin

stat:=3; form1. reg3(true);

form1.Label3.Caption:='Внесите наличные';

end;

3: begin

form1.Label4.Visible:=false;

form1.Label3.Caption:='Возьмите чек';

form1.chek;

end;

end;

end;

2: begin

case stat of

1: begin

stat:=0; form1. reg1(false);

form1.Label3.Caption:='Выберите оператора';

form1.ButtonsNastr (true);

navigat[4]. Visible:=true;

end;

2: begin

stat:=1; form1. reg2(false);

form1.Label3.Caption:='Введите номер';

end;

3: begin

stat:=2; form1. reg3(false);

form1.reg2(true);

form1.Label3.Caption:='Проверка введенных данных';

end;

end;

end;

3: begin

stat:=0; form1. reg1(false);

form1.Label3.Caption:='Выберите оператора';

form1.label4.Visible:=false;

navigat[1]. Caption:='Далее';

form1.Panel1.Visible:=false;

navigat[4].Visible:=true;

form1.buttonsnastr (true);

end;

4: begin

form1.ButtonsNastr (false);

navigat[4]. Visible:=false;

navigat[3].Visible:=true;

end;

end;

end;

procedure tkeyboard. Click;

var

a:tkeyboard;

p:string;

begin

a:=tkeyboard (self);

if form1. Label3.Caption='Введите номер телефона' then

begin

if a. number='11' then

begin

if curs=0 then curs:=24;

case curs of

22: curs:=19;

18: curs:=14;

12:curs:=7;

5: ;

else curs:=curs-1;

end;

p:=form1.Edit1.Text;

form1.Edit1.Text:=copy (p, 1,(curs-1))+' '+copy (p, curs+1,(25-curs+1));

navigat[1]. Visible:=false;

end

else

if curs<>0 then

begin

p:=form1.Edit1.Text;

form1.Edit1.Text:=copy (p, 1,(curs-1))+a.number+copy (p, curs+1,(25-curs+1));

case curs of

7: curs:=12;

14: curs:=18;

19: curs:=22;

23: begin curs:=0; navigat[1]. Visible:=true; end;

else inc (curs);

end;

end;

end;

if form1. Label3.Caption='Введите номер счета' then

begin

if a. number='11' then

begin

curs:=curs-1;

p:=form1.Edit1.Text;

form1.Edit1.Text:=copy (p, 1,(curs-1))+copy (p,(curs+1),(25-(curs+1)));

navigat[1]. Visible:=false;

end;

if a. number<>'11' then

begin

if curs<13 then

begin

form1.Edit1.Text:=form1.Edit1.Text+a.number;

curs:=curs+1;

if curs=13 then navigat[1]. Visible:=true;

end;

end;

end;

end;

procedure tmybutton. Click;

var

a:tmybutton;

i:integer;

begin

a:=tmybutton (self);

nam:=a.Caption;

form1.Image1.Picture.LoadFromFile (inttostr (a.Index)+'.gif');

if a. Index<=4 then

begin

form1.Label3.Caption:='Введите номер телефона';

form1.Edit1.Text:=phone;

curs:=5;

end

else

begin

form1.Label3.Caption:='Введите номер счета';

form1.Edit1.Text:='';

curs:=1;

end;

stat:=1;

form1.reg1(true);

navigat[4]. Visible:=false;

end;

procedure tform1. StartTime;

begin

label1.Caption:=day[dayofweek (now)]+', '+datetostr (now);

label2.Caption:=timetostr (now);

end;

procedure TForm1. Timer1Timer (Sender: TObject);

begin

label2.Caption:=timetostr (now);

end;

procedure TForm1. FormCreate (Sender: TObject);

var

i:integer;

begin

c:=rgb (81,182,207); stat:=0; money:=0;

form1.BorderStyle:=bsnone;

form1.WindowState:=wsmaximized;

StartTime;

ButtonsAndKeybrdCreate;

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

edit1.Font.Size:=40;

edit1.Width:=600; edit1. Height:=100;

edit1.Top:=120; edit1. Left:=400;

edit1.Text:=phone;

edit1.Font.Color:=clblue;

edit1.Visible:=false;

image1.Visible:=false;

Image1.Top:=250;

for i:=1 to z do

begin

labels[i]: =tlabel.Create (self);

with labels[i] do

begin

width:=1;

parent:=panel1;

autosize:=true;

font.Size:=8;

font.Style:=[fsbold];

end;

end;

end;

end.