· «голый» WEB . Эта схема попадает под определение «тонкого» клиента. Интерфейс реализован на базе HTML , в качестве протокола HTTP поверх SSI . Клиент использует обычный WEB -браузер. В банке установлен WEB -сервер для исполнения WEB -приложения, который с одной стороны динамически формирует HTML -страницы для клиента, а с другой обращается с сервером базы данных.
· WEB + программное обеспечение. В данном решении клиенту предлагаются специальные программы или plugin -модули для конкретной версии WEB -браузера. Сложности: проведение установки и настройки специализированного ПО у клиента и необходимость периодического обновления этого ПО. Как следствие, необходимость создания в банке группы сотрудников для технической поддержки клиентов и дополнительные издержки банка. Так как ПО устанавливается у клиента – это система с «толстым» клиентом, а обработка на нашей машине.
· Применение JAVA -апплета. Функции клиентской программы выполняет JAVA -апплет, загружаемый в WEB -браузер клиента. В JAVA -апплете реализован весь интерфейс пользователя: экранные и печатные формы документов, проверки правильности заполнения, протокол защищенного взаимодействия с сервером БД, шифрование данных, генерация криптоключей, механизм ЭЦП клиента под финансовыми документами и обмен финансовыми документами с автоматизированными банковскими системами.
Независимо от используемой схемы, определяют состав Интернет-банкинга:
· Клиентская часть системы. Это интернет-сервер, устанавливаемый в банке, который посещают клиенты банка для выполнения операций в системе и где реализован прокол защищенного взаимодействия и шифрования данных.
· Сервер БД. Хранит все документы и открытые ключи ЭЦП клиентов, всю информацию о клиентах и 9справочники. В данной части системы происходит первичная регистрация клиентов, определение счетов и полномочий. Хранятся справочники, используемые клиентом в работе и полная информация о клиенте.
· Шлюз к АБС. Обеспечивает обмен данными между системами. Обычно поддерживается работа АБС в пакетном режиме, режиме реального времени, может быть комбинировано. Самым распространенным является обмен текстовыми файлами заранее определенного формата.
Для Российского рынка традиционыым решением является: на стороне клинета устанавливается спецмально ПО, дополнительно plugin -модули, а иногда и аппаратные средства. Для работы системы с клиентом используются WEB -браузеры.
1.4 Обслуживание клиентов банка через Интернет
Посетив специализированный сайт (такой сайт может быть разработан программистами какого-либо банка), клиент может получить полный набор услуг в течение нескольких минут: увидеть описание сайта, изучить категории операций, выбрать и оформить операцию, оплатить ёе (с помощью банковского перевода), получить подтверждение выполнения операции.
Глава 2. Проектирование АСУ
2.1 Цель работы.
Основной целью настоящей дипломной работы является создание системы обслуживания клиентов банка через Интернет.
Для достижения этой цели были решены следующие задачи:
1. Рассмотрены операции клиента и банка;
2. Проведен анализ;
3. Определены основные требования к разрабатываемой системе;
4. Спроектирована и разработана система обслуживания клиентов банка через ИНТЕРНЕТ;
5. Создан тестовый пример;
6. Произведено тестирование системы;
7. Проведена оценка экономической эффективности разработанной системы.
2.2 Функциональные требования к системе
2.2.1 Для реализации поставленных целей система должна отвечать следующим функциональным требованиям:
· оформление заказа на данную услугу(Клиент-Банк) – выполняется администратором по работе с клиентами, когда клиент определился;
· формирование Базы Данных клиентов;
· формирование отчетов;
· осуществление поиска по указанным параметрам – для администратора:
· по фамилии клиента;
· по номеру операции;
· по фамилии администратора
· возможность работы с операциями – поиск по описанию операций;
· возможность работы с операциями и клиентами(для администратора) – добавление, удаление, редактирование
2.2.2 Исходные данные:
· Анкетные данные;
· Желание клиента.
2.2.3 Выходные данные:
Результаты поиска;
· Договор с клиентом;
· Отчеты;
2.2.4 Требования к надёжности.
· Предусмотреть контроль вводимой информации.
· Предусмотреть блокировку некорректных действий пользователя при работе с системой.
· Обеспечить целостность хранимой информации.
· Обеспечить защиту от несанкционированного доступа к информации.
2.2.5 Требования к составу и параметрам технических средств.
Система должна работать на IBM совместимых компьютерах.
Минимальная конфигурация:
1. Тип процессора Pentium III или Athlon и выше;
2. Частота процессора 333 Mhz и выше;
3. Объём оперативного запоминающего устройства 64 Мб и более;
4. Объем свободного пространства на жестком диске 5 M б и выше.
Требования к информационной и программной совместимости.
Система должна работать под управлением семейства операционных систем Win 32 ( Windows 95, Windows 98, Windows Me , Windows 2000, Windows NT , Windows XP ). Выход в сеть Internet .
2.3 Выбор и обоснование технологии проектирования и инструментальных средств разработки
Разработка информационных систем включает в себя несколько этапов. Однако всегда начальным этапом создания системы является изучение, анализ и моделирование деятельности заказчика для возможного улучшения и оптимальных методов работы, которые и будут реализованы в создаваемом приложении.
Прежде чем решить эти проблемы и приступить к разработке системы необходимо иметь четкое описание методологии разработки, адаптированной к конкретному проекту. На основе выбранной методологии производится выбор конкретных проектных инструментов и программных средств.
В своем дипломном проекте я использую комбинированный подход к проектированию. Это наиболее популярный на сегодняшний день способ формализации требований к системе и построению ее архитектуры. Его популярность обусловлена сочетанием преимуществ функционального и объектного подходов к проектированию: функциональный подход хорош на этапе выдвижения требований и описания бизнес-процессов, а объектный – на этапе создания архитектуры системы, достаточно понятной для программиста, и дальнейшей реализации проекта в объектно-ориентированной среде программирования.
Под моделью ПО в общем случае понимается формализованное описание системы ПО на определенном уровне абстракции. Каждая модель определяет конкретный аспект системы, использует набор диаграмм и документов заданного формата, а также отражает точку зрения и является объектом деятельности различных людей с конкретными интересами, ролями или задачами. Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архитектуры системы.
Поскольку сложность систем повышается, важно располагать хорошими методами моделирования. Хотя имеется много других факторов, от которых зависит успех проекта, но наличие строгого стандарта языка моделирования является весьма существенным. Состав моделей, используемых в каждом конкретном проекте, и степень их детальности в общем случае зависят от следующих факторов:
· сложности проектируемой системы;
· необходимой полноты ее описания;
· знаний и навыков участников проекта;
· времени, отведенного на проектирование.
Визуальное моделирование оказало большое влияние на развитие ТС ПО вообще и CASEсредств в частности. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО. CASEтехнология представляет собой совокупность методов проектирования ПО, а так же набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE - средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
BPWin.
BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BPwin поддерживает три методологии: IDEF 0, DFD и IDEF 3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения:
С точки зрения функциональности системы. В рамках методологии IDEF 0( Integration Definition for Function Modeling ) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.
С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD ( Data Flow Diagramming ) могут дополнить то, что уже отражено в модели IDEF 3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF 3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF 3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.