CC BY
92
Доклады ТУСУРа. 2004 г. Автоматизированные системы обработки информации, управления и проектирования УДК 681.3
ОСОБЕННОСТИ И ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ ЭЛЕКТРОННОГО КОШЕЛЬКА
В.А. Щербанов, П.В. Кориков
Предложена архитектура клиентского программного обеспечения электронного кошелька. Рассмотрены принципы проектирования.
Введение
Глобальная компьютеризация нашего общества диктует свои требования к средствам совершения финансовых сделок - от простейших покупок до крупных операций. Современный мобильный человек не желает тратить свое время на возню с платежными бумагами или в очереди в кассу или к банкомату. Увидев интересующий его товар в Интернете за домашним компьютером или в супермаркете, он хочет быть уверенным, что то средство оплаты, которое он может предложить, будет принято продавцом.
Задачей разработчика платежной системы является создание надежной, быстрой, удобной и легко масштабируемой системы. Потратив на начальном этапе разработки некоторые дополнительные ресурсы (временные и материальные), можно добиться высокой стабильности и надежности работы системы, а также возможности переноса некоторых ее компонентов на различные платформы. К примеру, возможность быстрого переноса клиентской части может увеличить число клиентов в несколько раз.
В результате изучения и анализа различных платежных систем была предложена новая модель для построения электронной платежной системы - модель виртуального электронного кошелька (ВЭК).
В данной модели при совершении сделки сумма денег одновременно дебетуется в электронном кошельке покупателя и кредитуется в электронном кошельке продавца [1]. Во время операции генерируются транзакции, содержащие сумму и тип сделки, дату, банковские атрибуты участников, а также их электронные подписи. Эти транзакции хранятся в виртуальных электронных кошельках участников и инкассируются по мере истечения определенного времени в банки-эмитенты. Здесь транзакции в зависимости от типа интерпретируются либо как платежное поручение, либо как акцептованное платежное требование-поручение. На основе информации, содержащейся в транзакции, подсчитываются обороты по дебету и по кредиту по каждому банку- участнику и полученные результаты отправляются в процессинговый центр.
На основе полученных данных процессинговый центр определяет итоговые обороты по дебету и кредиту системы и информирует банки о согласованности взаимных требований по платежам в случае их равенства. В противном случае процессинговый центр, определив, между какими банками данное равенство не выполняется, информирует их о необходимости обмена транзакциями. Восстановив утерянные или отвергнув неверные, банки вновь отправляют эту информацию в процессинговый центр. Получив информацию о согласованности требований, банки осуществляют платежи.
Как видно из описанной модели, в системе существуют три участника:
- процессинговый центр;
- банк;
- электронный кошелек.
В отличие от серверной части системы (процессинговый центр и банк), где для повышения надежности и стабильности системы могут применяться практически неограниченные технические и программные средства, клиентская часть является более примитивной и имеет ограниченную функциональность. В связи с этим было решено начать разработку системы именно с нее. Таким образом, в данной статье речь пойдет о принципах проектирования электронного кошелька.
Определение устройств и программных средств
На начальном этапе разработки системы одним из важных был вопрос об устройствах, способных функционировать в качестве электронного кошелька.
Такие устройства были условно разделены на два класса.
Специализированные - предназначены исключительно для проведения электронных расчетов. Обычно это комбинация программных и аппаратных средств, например пластиковые карты, смарт-карты, банкоматы и РОЭ-терминалы.
Универсальные - позволяют выполнять различные функции в зависимости от управляющей программы, например ЭВМ, карманные компьютеры, программируемые сотовые телефоны и смартфоны, устройства ТоисИРа^
В случае специализированных устройств стоимость их внедрения необходимо будет возложить на банки, продавцов или покупателей. К тому же организация обмена уже выпущенных и действующих устройств на новые чрезвычайно сложна и является дорогостоящим мероприятием. Универсальные устройства лишены таких недостатков. Хорошо спроектированная и реализованная программа способна работать на любом устройстве, имеющемся у пользователя, начиная от персонального компьютера и заканчивая сотовым телефоном с ограниченной функциональностью. Сумма, необходимая для подключения банком своего клиента к системе электронных платежей, будет равняться стоимости установки программного обеспечения на его устройство и при правильной организации будет стремиться к нулю. И хотя надежность специализированных устройств легче спроектировать, плюсы программной модели значительно превышают плюсы системы, основанной на специализированных устройствах.
После анализа различных устройств и их степени распространения было принято решение о необходимости создания системы, одинаково хорошо функционирующей на любых устройствах, способных соединяться в сети передачи данных. В качестве основной была принята сеть Интернет.
Следующие устройства были выбраны в качестве основных:
- персональные компьютеры как самые приспособленные к компьютерным сетям (в частности к Интернет);
- сотовые телефоны как самые широко распространенные устройства;
- карманные компьютеры как средства мобильного использования.
После выбора устройств была определена платформа программирования. Единственным языком, который позволяет писать одну программу под все системы, оказался язык Java. Требования, которым удовлетворяет данный язык:
- широкий спектр поддерживаемого оборудования и операционных систем. Программы, написанные на этом языке, способны работать в различных операционных системах (Windows™, Unix- и Linux-системы, Solaris и многие другие), а также на различных мобильных устройствах (сотовые телефоны с поддержкой Java, карманные компьютеры);
- большой выбор программных средств. Платформой Java поддерживаются средства сетевого взаимодействия, элементы пользовательского интерфейса и пр.;
- простота проектирования и разработки, что приводит к уменьшению числа ошибок;
- быстродействие полученного кода. В операциях с целочисленной арифметикой про-грам-мы, написанные на Java, показывают быстродействие, сопоставимое с быстродействием программ, написанных на C/C++;
- возможность изменять структуру приложения специальными программными средствами. Создать хорошую структуру больших программных систем удается не сразу - она должна развиваться по мере накопления опыта. Таким образом, необходимы автоматизированные средства для изменения (рефакторинга [2]) существующего кода без изменения функциональности.
Общая архитектура системы
Электронный кошелек клиента должен позволять делать следующие операции.
1. Предоставлять возможность ввода параметров сделки (сумму, тип, атрибуты другого участника), паролей к системе, а также других вспомогательных данных. Показывать пользователю сведения об операциях, состоянии счета и другую информацию.
2. Хранить на устройстве данные пользователя, его счета и информацию о совершенных операциях и корреспондентах.
3. Отправлять запросы, операции и данные другим участникам по любым доступным каналам связи, а также принимать их.
4. Обеспечивать надежное шифрование всей информации в системе, ее аутентичность, а также защиту от преднамеренного и случайного изменения.
5. Управлять логикой системы.
Таким образом, были выделены пять блоков системы, которые показаны на рисунке.
И хотя программы, написанные на Java, одинаково хорошо работают на всех системах, некоторые части являются платформенно-зависимыми. Например, пользовательский интерфейс программы выглядит по-разному на разных устройствах. На сотовых телефонах - это набор текстовых полей ввода, информационных сообщений и команд в меню вашего аппарата. На карманных компьютерах интерфейс может содержать дополнительные элементы, повышающие удобство. На персональных компьютерах интерфейс можно сделать максимально удобным и функциональным. То же можно сказать и про подсистему постоянного хранилища
(разный подход к управлению данными в памяти сотового аппарата и управлению данными на жестком диске пользователя), а также про подсистему сетевого интерфейса (разные способы пересылки данных по компьютерным сетям TCP/IP и сетям GSM).
Таким образом, пришлось вынести все платформенно-зависимые части в отдельные модули. Такое разделение позволяет максимально абстрагировать взаимодействие с ними остальных модулей.
Общая архитектура системы
Сетевой интерфейс
Сети передачи данных являются обязательными для нашей системы. И хотя в качестве основной принята сеть Интернет, электронные кошельки не должны ею ограничиваться. Например, сотовым телефонам естественна сеть GSM и осуществлять платежи можно посредством SMS. В связи с таким разнообразием сетей было решено отказаться от удобной и надежной модели постоянного соединения, когда клиент и сервер после установки соединения смогут организовать протокол связи без прерывания связи. Вместо этого принята модель дейтаграмм. Каждый участник системы формирует пакеты (например пакет платежа) и посылает их адресату без установки соединения с ним. Когда участник получит этот пакет, он волен принять платеж или отказаться. Это решение формируется как пакет и пересылается инициКтюруыйлртешазующий конкретный тип соединения класс должен реализовать интерфейс Connection.
public interface Connection {
public void close ();
public void send (byte[] data);
public void addRecieveDataListener (RecieveDataListener listener);
}
Метод close закрывает соединение, метод send отвечает за пересылку сообщения, а метод addRecieveDataListener добавляет «слушателя» получения данных. Это пользовательский класс, реализующий интерфейс RecieveDataListener:
public interface RecieveDataListener {
public void recieveData (byte[] data);
}
Один-единственный метод recieveData вызывается, когда приходят данные по выбранному сетевому интерфейсу.
Логическому блоку ничего неизвестно о реализующих данный интерфейс классах, вместо этого он вызывает фабричный метод open-класса Connector.
public class Connector {
public static Connection open (String uri);
}
Этот класс представляет собой паттерн1 «фабричный метод». Его метод open создает класс Connection по заданному URI (universal resource identifier).
Общая форма URI следующая: <схема>://<адрес>;<параметры>
Частью URI является его поле схемы, которое представляет собой протокол, используемый для соединения. RFC 2369 поддерживает множество действующих схем, таких как datagram, socket, serversocket, http, ftp, gopher и так далее.
Блок логики может предоставить выбор соединения пользователю и на основе этих данных создать экземпляр класса Connection и взаимодействовать уже через него.
byte[] data = new byte[1024]; // Заполнить массив данными // ...
Connection forVasya = Connector.open ("http://www.vasya.ru/purse.asp"); forVasya.send (data); forVasya.addRecieveDataListener (
new RecieveDataListener () {
public void recieveData (byte[] data) {
// Обработать пришедшие данные // ...
// Закрыть соединение forVasya.close ();
}
} ;
);
Такая реализация позволяет логическому блоку ничего не знать о подсистеме сетевого интерфейса и в случае необходимости менять его даже во время исполнения.
Постоянное хранилище
Вся информация, необходимая для нормального функционирования системы, должна иметь постоянное место хранения. Это может быть жесткий диск компьютера, память сотового аппарата или флэш-память другого мобильного устройства. Любой класс, реализующий конкретное устройство хранения, должен реализовать интерфейс DataStore:
public interface DataStore {
1
Здесь и далее паттерны проектирования имеют такой же смысл, что и в [3]. Паттерн - это описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. Паттерны можно рассматривать как строительные блоки приложения, хорошо отлаженные мировым сообществом разработчиков, которыми можно постоянно пользоваться, ничего не изобретая заново.
// Открыть хранилище по его имени void open (String path); // Закрыть хранилище void close ();
// Считать информацию из хранилища в буфер
int read (byte[] buffer, int fromlndex, int toIndex);
// Записать информацию из буфера в хранилище
int write (byte[] data, int fromlndex, int toIndex);
// Установить файловый указатель на позицию pos
long seek (long pos);
// Удалить хранилище
boolean remove();
}
Криптографический модуль
Хранимую информацию необходимо надежно шифровать на ключе пользователя. Для передаваемой информации необходимо обеспечить ее аутентичность. Таким образом, криптографическая система должна выполнять функции шифрования, подписи и нахождения хэш-значения. Алгоритмы должны быть надежными и качественно реализованными. Ввиду того что криптографические алгоритмы целочисленные и не меняются в зависимости от устройств, данный модуль является неотъемлемой частью логического блока. Интерфейсы, которые реализуют классы алгоритмов:
// Алгоритмы нахождения хэш-значения
public interface Hash {
public byte[] digest (byte[] input);
}
// Алгоритмы шифрования
public interface Cipher {
public byte[] setKey (byte[] newKey); public byte[] encrypt (byte[] m); public byte[] decrypt (byte[] c);
}
// Алгоритмы цифровой подписи
public interface Signature {
public byte[] setKey (byte[] newKey); public byte[] sign (byte[] data);
public boolean verify (byte[] data, byte[] signature);
}
Пользовательский интерфейс
Если с хранением и передачей информации все понятно и относительно просто, то в случае ее отображения ситуация усложняется. Существует множество устройств и операционных систем, на которых работает Java, и почти все они имеют свой неповторимый внешний вид. И хотя разработчики языка пытались обобщить системы пользовательских интерфейсов в группы, все же почти всегда они являются несовместимыми.
Для архитектуры взаимодействия логического блока и интерфейса мы применим паттерн Команда [3]. Логический блок посылает команды-запросы блоку пользовательского интерфей-
са, который в свою очередь исполняет их. Действия пользователя приводят к тому, что подсистема интерфейса посылает команды блоку логики.
Два интерфейса необходимы для нормальной работы:
public interface UlCommand {
public void execute (String command, String param);
public void addUICommandListener (UICommandListener listener);
}
public interface UICommandListener {
public void recieveCommand (String command, String param);
}
Теперь, чтобы послать команду о вводе пароля, достаточно следующего кода:
UICommand command = new PhoneUICommand (); command.execute ("ENTER_PASSWORD", null);
«Прослушать» ответ пользователя на приглашение ввести пароль можно последовательностью:
command.addUICommandListener (
new UICommandListener () {
public void recieveCommand (String command, String param) {
if (command.equals ("PASSWORD_ENTERED")) {
setCurrentPassword (param);
}
}
} ;
);
Сам модуль пользовательского интерфейса создается непосредственно для конкретного устройства и слабо зависит от всех остальных частей.
Заключение
Были рассмотрены основные особенности и принципы проектирования электронного кошелька. Конечно, это всего лишь рекомендации для разработчиков, которым желательно следовать. Структура системы может меняться в процессе разработки или изменения требований, однако архитектор должен предвидеть такие риски и минимизировать их еще на этапе проектирования.
ЛИТЕРАТУРА
1. Брянцева Л.В. Система безналичных взаиморасчетов на основе виртуального электронного кошелька / Л.В. Брянцева, С.Б. Козлов, В.А. Щербанов // Тез. докл. Российской науч.-техн. конф. «Автоматизированные коммерческо-технологические системы безналичных расчетов». - Томск: НИИ автоматики и электромеханики при ТУСУРе, 1997.
2. Фаулер М. Рефакторинг. Улучшение существующего кода. - СПб: Символ, 2003.
3. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. - СПб: Питер, 2001.
