Создание системы управления взаимоотношениями с клиентами

Создание системы управления взаимоотношениями с клиентами

РЕФЕРАТ

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

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

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

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

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. Анализ решаемой задачи

1.1 Стратегия системы управления

1.2 Требования к системе управления

2. Разработка

2.1 Разработка схемы базы данных

2.2 Разработка логической структуры базы данных

3. Разработка триггеров и настройка репликации

3.1 Хранимые процедуры и триггеры. Особенности использования

3.1.1 Разработанные триггеры

3.2 Репликация базы данных

3.2.1 Настройка репликации в СУБД Postgres

4. настройка сервера ldap

4.1 Настройка сервера LDAP

ВЫВОДЫ

ПЕРЕЧЕНЬ ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

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

Преимущества, которыми обладает система:

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

.Постоянная связь с заказчиками и покупателями.

.Система не имеет ограничений на виртуальную площадь. Можно разместить сколь угодно сделок и проектов.

.Система обладает удобным интерфейсом для отображения различных данных.

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

1. Анализ решаемой задачи

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

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

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

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

Создание корпоративных приложений имеет ряд особенностей, а именно:

·   «расслоение» приложения по уровням;

·   структурирование логики предметной области;

·   связывание модулей, размещаемых в памяти с реляционной базой данных.

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

1.1 Стратегия системы управления

Выделим основные сущности системы и их функции на самом высоком уровне абстракции.

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

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

С каждым бизнес-процессом также связан определённый набор данных. В рамках любого бизнес-процесса «на входе» используется один или несколько видов ресурсов, и в результате этой деятельности на «выходе» создаётся продукт (бизнес-цель), представляющий ценность для конечного потребителя. Ресурсы и конечный продукт можно представить в виде данных процесса. Следовательно, с любым бизнес-процессом связан его набор данных - следующая сущность системы.

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

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

1.2 Требования к системе управления

клиент база триггер репликация

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

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

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

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

·   Менеджер - это пользователь, который взаимодействует с клиентами, создает проекты, сделки и поддерживает актуальность данных клиента.

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

2. Разработка

2.1 Разработка схемы базы данных

Была разработана структура БД, описанная на формальном языке, поддерживаемом системой управления базами данных (СУБД).

2.2 Разработка логической структуры базы данных

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

Рисунок 2.1 − Схема базы данных

3. Разработка триггеров и настройка репликации

3.1 Хранимые процедуры и триггеры. Особенности использования

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

·   разбалансирование бизнес-логики системы;

·   создание анти паттерна “велосипед” (свое плохое решение, при существовании лучшего).

Триггер - это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено наступлением определенного события (действием) - по сути добавлением INSERT или удалением DELETE строки в заданной таблице, или модификации UPDATE данных в определенном столбце заданной таблицы реляционной базы данных.

3.1.1 Разработанные триггеры

"old"."contacts_name"!="new"."contacts_name" then"contacts" set "id" = "old"."id""contacts.id" = "old"."id";if;old;;

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

varchar(30);varchar(30);varchar(30);varchar(100);varchar(100);varchar(100);varchar(364);TG_OP = 'INSERT' THEN= NEW.tasks_name;= NEW.responsible;:= 'Add new tasks: ';:= ' to contacts: ';:= mstr || nstr || msstr || ostr;INTO "events"(id,events_text,tasks_id) values ((select count(*) from "events")+1,retstr,NEW.id);NEW;TG_OP = 'UPDATE' THEN= NEW.tasks_name;:= 'Update task: ';:= mstr || nstr;(OLD.tasks_name != NEW.tasks_name) then= NEW.tasks_name;= OLD.tasks_name;:= 'Update task name: ';:= ' to name: ';:= mstr || ostr || msstr || nstr;if;INTO "events"(id,events_text,tasks_id) values ((select count(*) from "events")+1,retstr,NEW.id);NEW;TG_OP = 'DELETE' THEN= OLD.tasks_name;:= 'Remove task: ';:= mstr || ostr;INTO "events"(id,events_text) values ((select count(*) from "events")+1,retstr);OLD;IF;;

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

varchar(30);varchar(30);varchar(100);varchar(100);varchar(254);TG_OP = 'INSERT' THEN= NEW.company_name;:= 'Add new company: ';:= mstr || nstr;INTO "events"(id,events_text) values ((select count(*) from "events")+1,retstr);NEW;TG_OP = 'UPDATE' THEN= NEW.company_name;= OLD.company_name;:= 'Update company: ';:= ' To company: ';(OLD.company_name != NEW.company_name) then:= mstr || ostr || msstr || nstr;:= mstr || nstr;if;INTO "events"(id,events_text) values ((select count(*) from "events")+1,retstr);NEW;TG_OP = 'DELETE' THEN= OLD.company_name;:= 'Remove company: ';:= mstr || ostr;INTO "events"(id,events_text) values ((select count(*) from "events")+1,retstr);OLD;IF;;

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

varchar(30);varchar(30);varchar(100);varchar(100);varchar(254);TG_OP = 'INSERT' THEN= NEW.contacts_name;:= 'Add new contact: ';:= mstr || nstr;INTO "events"(id,events_text,contakts_id) values ((select count(*) from "events")+1,retstr,NEW.id);NEW;TG_OP = 'UPDATE' THEN= NEW.contacts_name;= OLD.contacts_name;:= ' To contact name: ';(OLD.contacts_name != NEW.contacts_name) then:= 'Update contact name: ';:= mstr || ostr || msstr || nstr;:= 'Update contact: ';:= mstr || nstr;if;INTO "events"(id,events_text,contakts_id) values ((select count(*) from "events")+1,retstr,NEW.id);NEW;TG_OP = 'DELETE' THEN= OLD.contacts_name;:= 'Remove contact: ';:= mstr || ostr;INTO "events"(id,events_text) values ((select count(*) from "events")+1,retstr);OLD;IF;;

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

varchar(30);varchar(30);varchar(100);varchar(100);varchar(254);TG_OP = 'INSERT' THEN= NEW.deals_name;:= 'Add new deal: ';:= mstr || nstr;INTO "events"(id,events_text,deals_id) values ((select count(*) from "events")+1,retstr,NEW.id);NEW;TG_OP = 'UPDATE' THEN= NEW.deals_name;= OLD.deals_name;:= ' To deal name: ';(OLD.deals_name != NEW.deals_name) then:= 'Update deal name: ';:= mstr || ostr || msstr || nstr;:= 'Update deal: ';:= mstr || nstr;if;INTO "events"(id,events_text,deals_id) values ((select count(*) from "events")+1,retstr,NEW.id);NEW;TG_OP = 'DELETE' THEN= OLD.deals_name;:= 'Remove deal: ';:= mstr || ostr;INTO "events"(id,events_text) values ((select count(*) from "events")+1,retstr);OLD;IF;;

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

"new"."money"<1 then"deals" set "money" = 1;if;new;;

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

"new"."money">100000 then"deals" set "money" = 1;if;new;;

Триггер, который заносит данные в таблицу событий при изменении адреса контакта:

varchar(30);varchar(100);varchar(30);varchar(100);varchar(254);OLD.contacts_address != NEW.contacts_address then= NEW.contacts_name;= NEW.contacts_address;:= 'Update address to contacts: ';:= ' to address: ';:= mstr || nstr || astr || ostr;into "events"("id","contakts_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заносит данные в таблицу событий при изменении e-mail контакта:

varchar(30);varchar(100);varchar(30);varchar(100);varchar(254);OLD.contacts_email != NEW.contacts_email then= NEW.contacts_name;= NEW.contacts_email;:= 'Update mail to contacts: ';:= ' to mail: ';:= mstr || nstr || astr || ostr;into "events"("id","contakts_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заносит данные в таблицу событий при изменении телефона контакта:

varchar(30);varchar(100);varchar(30);varchar(100);varchar(254);OLD.contacts_telephon != NEW.contacts_telephon then= NEW.contacts_name;= NEW.contacts_telephon;:= 'Update phone to contacts: ';:= ' to phone: ';:= mstr || nstr || astr || ostr;into "events"("id","contakts_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заносит данные в таблицу событий при изменении статуса сделки:

varchar(30);varchar(100);varchar(30);varchar(100);varchar(254);OLD.deals_type != NEW.deals_type then= NEW.deals_name;= NEW.deals_type;:= 'Update deals type in dial: ';:= ' to type: ';:= mstr || nstr || astr || ostr;into "events"("id","deals_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заносит данные в таблицу событий при изменении ответственного за задачу:

varchar(350);varchar(100);varchar(50);varchar(100);varchar(254);OLD.responsible != NEW.responsible then= NEW.tasks_name;= NEW.responsible;:= 'Update tasks responsible in task: ';:= ' to contacts: ';:= mstr || nstr || astr || ostr;into "events"("id","tasks_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заносит данные в таблицу событий при изменении статуса задачи:

varchar(30);varchar(100);varchar(30);varchar(100);varchar(254);OLD.status != NEW.status then= NEW.tasks_name;= NEW.status;:= 'Update task status in task: ';:= ' to status: ';:= mstr || nstr || astr || ostr;into "events"("id","tasks_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заносит данные в таблицу событий при изменении ответственного за сделку:

varchar(350);varchar(100);varchar(50);varchar(100);varchar(254);OLD.responsible != NEW.responsible then= NEW.deals_name;= NEW.responsible;:= 'Update deals responsible in dial: ';:= ' to contacts: ';:= mstr || nstr || astr || ostr;into "events"("id","deals_id","events_text")((select count(*) from "events")+1,.id,retstr);if;new;;

Триггер, который заполняет автоматически поля, в которых хранится дата и время, при добавлении новой сделки:

"tasks" set "tasks_date" = ('now'::text)::date where "tasks"."id" = NEW.id;"tasks" set "tasks_time" = ('now'::text)::time with time zone where "tasks"."id" = NEW.id;new;;

3.2 Репликация базы данных

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

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

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

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

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

3.2.1 Настройка репликации в СУБД Postgres

Для начала на обеих серверах в /etc/hosts были добавлены две строчки:

.1.1.1 db_0

.1.1.2 db_1

Далее был настроен файл pg_hba.conf:

# nano /usr/home/pgsql/data/pg_hba.conf

Для мастера:

#IP мастера_addresses = ‘1.1.1.1’

#На слейвreplication postgres 1.1.1.2/32 trustall postgres 1.1.1.2/32 trust

#Тут мы говорим, что доступ имеют все и со всех адресов, с использованием пароля

Далее производится настройка файла postgresql.conf:

# nano /usr/local/pgsql/data/postgresql.conf

В этом файле:

#Ведение журнала с правами чтения для слейва_level = hot_standby

#Максимальное количество слейвов_wal_senders = 2

#Устанавливаем общее хранимое количество кусков лога_keep_segments = 32

#Дублируем журнал в отдельное место_mode = on_command = 'cp %p /usr/lib/postgresql/9.1/main/archive/%f'

#Максимальное количество подключений_connections = 150

#Размер буфера_buffers = 2400MB

Теперь нужно перезапустить мастер. Необходимо передать базу на слейв. Для этого используем rsync:

# psql -c "SELECT pg_start_backup('label', true)"

# rsync -a /usr/lib/postgresql/9.1/main/ posgres@1.1.1.2:/usr/lib/postgresql/9.1/main/ <mailto:posgres@1.1.1.2:/usr/lib/postgresql/9.1/main/> --exclude postmaster.pid

# psql -c "SELECT pg_stop_backup()"

Теперь нужно настроить слейв. В postgresql.conf:_standby = on_mode = off

Необходимо создать recovery.conf:_mode = 'on'_conninfo = 'host=1.1.1.1 port=5432 user=postgres'

#триггер нужен для бэкапа, чтобы в случае бэкапа могли остановить процесс репликации и сделать слейв доступным на запись_file = '/usr/lib/postgresql/9.1/main/trigger'_command = 'cp /usr/lib/postgresql/9.1/main/archive/%f "%p"'

Теперь можно запустить процесс репликации.

Проверка на слейве:

# ps6878 6872 1 10:31 ? 00:00:01 postgres: wal receiver process streaming 0/2000000

Это значит, что репликация настроена правильно.

3.3    Мониторинг системы с помощью утилиты Nagios

- система с открытым кодом, предназначенная для мониторинга компьютерных систем и сетей. Она следит за указанными в настройках узлами и службами, и оповещает администратора в случае, если какие-то из служб прекращают (или возобновляют) свою работу. Nagios, первоначально созданная под именем Netsaint, разработана Этаном Галстадом (Ethan Galstad). Он же поддерживает и развивает систему сегодня, совместно с командой разработчиков, которые занимаются как официальными, так и неофициальными плагинами.

Первоначально Nagios была разработана для работы под GNU/Linux, но она также хорошо работает и под другими Unix- подобными ОС.

3.3.1 Настройка мониторинга

Листинг файла localhost.cfg:

# This can serve as an example for configuring other servers;

# Custom services specific to this host are added here, but services

# defined in nagios2-common_services.cfg may also apply.

#host

{generic-host ; Name of host template to use_name slave1.1.1.21.1.1.2

}

#Apachecommand

{_name check_apache_line /home/sereban/apache2.sh

}service

{generic-service_name localhost_description Apache_command check_apache_enabled 1

}

#Postgrescommand

{_name check_postgres_line /home/sereban/pg.sh

}service

{generic-service_name localhost_description Postgres_command check_postgres_enabled 1

}service

{generic-service_name localhost_description Postgres_command check_postgres_enabled 1

}service

{generic-service_name slave_description Postgres_command check_postgres_enabled 1

}

Рисунок 3.1 - Мониторинг сервисов систем

4. настройка сервера ldap

4.1 Настройка сервера LDAP

В качестве сервера желательно выбрать открытое решение, поддерживающее общий стандарт протокола LDAP. Пожалуй, самым интересным и доступным в таком случае есть сервер sldap.

Для начала необходимо установить несколько пакетов:

# apt-get install slapd ldap-utils migrationtools

Теперь нужно переконфигурировать sldap, чтобы расширить количество изменяемых настроек:

#dpkg-reconfigure slapd

#пропустить настройку сервера LDAP? ... Нет

#Доменное имя DNS: ... debuntu.local

#Название организации: ... Всечтоугодно debuntu.local

#Пароль для admin: 1

#Подтвердите пароль: 1

#Настраивается пакет slapd (информация о формате базы ldap)

#Выбор формата базы ldap

#Удалять базу данных при вычистке slapd? ... Нет

#Переместить старую базу данных? ... Да

#Включить протокол LDAPv2? ... Нет

Теперь в системе установлен демон и административная учетная запись. Можно проверить есть ли доступ к ldap-серверу:

$ ldapsearch -x -b dc=debuntu,dc=local

# extended LDIF

#

# LDAPv3

# base <dc=debuntu,dc=local> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# debuntu.local: dc=debuntu,dc=local: top: dcObject: organization: nodomain: debuntu

# admin, debuntu.local: cn=admin,dc=debuntu,dc=local: simpleSecurityObject: organizationalRole: admin: LDAP administrator

# People, debuntu.local: ou=People,dc=debuntu,dc=local: People: organizationalUnit

# search result: 2: 0 Success

# numResponses: 4

# numEntries: 3

Теперь нужно добавить пользователей. Используя migrationtools можно быстро импортировать всех существующих пользователей и групп с локальной системы в LDAP. Нужно отредактировать конфигурационный файл migrate_common.ph и заменить следующие параметры:

$DEFAULT_MAIL_DOMAIN = "debuntu.local";

$DEFAULT_BASE = "dc=debuntu,dc=local";

Теперь необходимо экспортировать данные:

# ./migrate_group.pl /etc/group ~/group.ldif

# ./migrate_passwd.pl /etc/passwd ~/passwd.ldif

В домашнем каталоге нужно создать файл people_group.ldif и заполнить его строками:

dn: ou=People, dc=debuntu, dc=local

ou: People: organizationalUnit

dn: ou=Group, dc=debuntu, dc=local

ou: Group: organizationalUnit

Теперь списки пользователей и групп, сконвертированные в LDAP формат ldif, нужно импортировать в LDAP базу:

# ldapadd -x -W -D "cn=admin,dc=debuntu,dc=local" -f ~/people_group.ldif

# ldapadd -x -W -D "cn=admin,dc=debuntu,dc=local" -f ~/group.ldif

# ldapadd -x -W -D "cn=admin,dc=debuntu,dc=local" -f ~/passwd.ldif

где:

W что будет запрошен пароль администратора LDAP;

D что используется для идентификации администратора;

f что указывает файл, где ldapadd будет брать данные для добавления.

ВЫВОДЫ

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

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

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

ПЕРЕЧЕНЬ ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1. Documentation information [Електроний ресурс] : The JavaEE 6 Tuturial. - Електрон дан. - [USA], 2010. -

LDAP and JNDI [Електроний ресурс]: Toglther forever. - Електрон. дан. - [USA] 2008-2010. - Режим доступу : http:// <http://www.javaworld.com/>www<http://www.javaworld.com/>javaworld <http://www.javaworld.com/><http://www.javaworld.com/>com <http://www.javaworld.com/> /javaworld/jw-03-2000/jw-0324-ldap.html .Web Service [Електроний ресурс] : Spring Source. - Електрон. дан. [EU], 2005-2010. - Режим доступу : <http://static.springsource/>. org/spring-ws/sites/1.5/8. Testing [Електроний ресурс] : Spring Source. - Електрон. дан. [EU], 2005-2010. - Режим доступу : http://static.springsource.org/ spring/docs/2.5.x/reference/testing.html.3. Beans, BeanFactory and the ApplicationContext [Електроний ресурс] : Spring Source. - Електрон. дан. [EU], 2005-2010. - Режим доступу : <http://static/>:// <http://static/>static <http://static/>.springsource.org/spring/docs/1.2.9/reference/beans .html.

Часть 19 - Spring. Бизнес-уровень в действие [Електроний ресурс] : Студенчиский отдел кадров. Пособие по JAVA-технологиям/Anton Saburov - Електрон. дан. [Россия], 2009. - Режим доступу : <http://www.java-course.ru/students/part19.html>:// <http://www.java-course.ru/students/part19.html>www<http://www.java-course.ru/students/part19.html>java <http://www.java-course.ru/students/part19.html><http://www.java-course.ru/students/part19.html>course <http://www.java-course.ru/students/part19.html><http://www.java-course.ru/students/part19.html>ru <http://www.java-course.ru/students/part19.html><http://www.java-course.ru/students/part19.html>students <http://www.java-course.ru/students/part19.html><http://www.java-course.ru/students/part19.html>part <http://www.java-course.ru/students/part19.html>19. <http://www.java-course.ru/students/part19.html>html <http://www.java-course.ru/students/part19.html>.

Часть 10 - Spring. Бизнес- Тестирование с точки зрения разработчика [Електроний ресурс] : Студенчиский отдел кадров. Пособие по JAVA-технологиям/Anton Saburov - Електрон. дан. [Россия], 2009. - Режим доступу : <http://www.java-course.ru/ students/ part10.html>:// <http://www.java-course.ru/ students/ part10.html>www <http://www.java-course.ru/ students/ part10.html><http://www.java-course.ru/ students/ part10.html>java <http://www.java-course.ru/ students/ part10.html><http://www.java-course.ru/ students/ part10.html>course <http://www.java-course.ru/ students/ part10.html><http://www.java-course.ru/ students/ part10.html>ru <http://www.java-course.ru/ students/ part10.html>/  <http://www.java-course.ru/ students/ part10.html>students <http://www.java-course.ru/ students/ part10.html>/  <http://www.java-course.ru/ students/ part10.html>part <http://www.java-course.ru/ students/ part10.html>10. <http://www.java-course.ru/ students/ part10.html>html <http://www.java-course.ru/ students/ part10.html>.