Разработка модуля обработки информации о договорах в системе продаж АО "Петер-Сервис"

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

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

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление Информатика и вычислительная техника

Кафедра Программного обеспечения и управления в технических системах

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

Разработка модуля обработки информации о договорах в системе продаж АО «Петер-Сервис»

Разработал Г.А. Савинов

Самара 2017

Отзыв руководителя

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

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

Степень достижения цели и практическая значимость. Поставленные в бакалаврской работе задачи решены в полном объеме. Ценность работы для студента - изучение и применение на практике стека процедурного расширения языка SQL, работы с JavaScript и несколькими его фреймворками. Знания и навыки, полученные в результате выполнения работы могут быть использованы в дальнейшей профессиональной деятельности будущего специалиста. Практическая ценность работы заключается в разработке модуля обработки информации о договорах, для системы продаж АО «Петер-Сервис».

Заключения по представленной работе. Разделы рассматриваемой бакалаврской работы проработаны Савиновым Геннадием Андреевичем в полном объеме. В целом, бакалаврская работа соответствует требованиям, предъявляемым к ВКР, заслуживает оценки «отлично», а студенту Савинову Геннадию Андреевичу может быть присвоена степень бакалавра по направлению 09.03.01 «Информатика и вычислительная техника».

Реферат

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

Введение

В настоящее время общество зависит от информационных технологий. Они прочно вошли в нашу жизнь, и помогают нам в решении ряда задач. Каждый из нас имеет по одному, а иногда и по несколько мобильных телефонов. Они помогают нам всегда оставаться на связи, вести переговоры с людьми на другом краю света. Мы звоним, отправляем СМС, выходим в Интернет. Каждое наше действие фиксируется в биллинговых системах, располагающихся у операторов предоставляющих услуги связи. Одним из таких операторов является компания ОАО МегаФон, предоставляющая услуги связи по всей России. Используемая в компании МегаФон биллинговая система была разработана компанией Петер-Сервис и называется BIS(Billing Information System). Она предназначена для подсчёта и тарифицирования оказанных услуг по доступу в сеть.

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

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

В процессе работы с разработанной системой автоматизированных продаж операторы столкнулись с целым рядом проблем из-за неправильно разработанной архитектуры. Операторам, при создании новых лицевых счетов приходилось работать напрямую с сущностью Клиент. Из-за ошибок операторов, в системе появлялось несколько идентичных карточек клиентов, с одинаковыми лицевыми счетами. Настоящей головной болью стало определение необходимого клиента с нужным лицевым счётом, для продажи новых услуг. Договор являлся лишь атрибутом сущности «Лицевой счёт». Это приводило к тому, что информация о всех лицевых счетах, принадлежащих к одному договору была разрозненной. При заключении нового договора, необходимо было заводить новый лицевой счёт и уже к нему осуществлять привязку договора.

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

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

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

В рамках бакалаврской работы решён ряд задач:

1. Разработка и внедрение сущности «Договор» в систему SFA;

2. Разработка механизмов работы с новой сущностью;

3. Доработка действующего механизма синхронизации данных между SFA и BIS.

Бакалаврская работа состоит из введения, пяти глав, заключения, списка литературы и приложения. Во введении приводится обоснование актуальности рассматриваемой задачи, а также разработанные пути её решения. В ходе работы использовалась литература следующих авторов: Р. Иерузалимский, Д. Леффингуэлл, П. Козловский, П. Б. Дарвин, Т. Конноли.

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

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

Приложение содержит: Диаграмма разработанного алгоритма синхронизации данных (Приложение А), разработанное API для взаимодействия с БД (Приложение Б), тестовые наборы данных (Приложение В), исходный код пакета SFA_CONTACTS_PG (Приложение Г), презентационные материалы (Приложение Д).

1. Описание предметной области и действующей структуры

1.1 Описание предметной области

Для обслуживания клиентов в салонах связи и салонах дилерской сети была разработана BIS - расширяемая биллинговая система. Принцип работы системы BIS проиллюстрирован на рис. 1.1. Система позволяет принимать платежи, настраивать услуги, тарифы или предоставлять выписки по счету. Непосредственно в ней хранится информация о лицевых счетах. Проблема в том, что это биллинговая система, и она была акцентирована на сущность «Лицевой счет», к которой и привязаны все финансы. Сущности «Клиент» и «Договор» в BIS нет.

Рис.1.1 - Принцип работы системы BIS

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

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

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

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

В SFA используется следующий перечень сущностей[1]:

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

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



Рис.1.2 - Принцип работы SFA

1. Потенциальный клиент - это клиент, который ещё не имеет договора на получение услуг, но представляет интерес, как будущий потребитель услуг;

2. Действующий клиент - это клиент, имеющий договор на получение определённых услуг. В SFA клиент становится действующим при выполнении любого из следующих условий:

2.1) завершение первой успешной продажи;

2.2) клиент имеет хотя бы один лицевой счет, созданный по результатам синхронизации BIS->SFA, или перенесенный с другого клиента SFA.

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

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

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

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

На рис. 1.3 изображена действующая структура и связь лицевых счетов с клиентом:

Рис. 1.3 - Связь клиента с лицевыми счетам

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

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

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

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

Также компанией Петер-Сервис разрабатывается продукт CAM(Customer Account Management), он находится в активной стадии разработки, и впоследствии будет содержать всю информацию о клиентах.

1.2 Структура действующей системы

Действующая структура система SFA представлена на рис. 1.4. На ней изображена база данных SFA, где хранятся все данные, по клиентам, продажам, задачам, лицевым счетам, договорам и пр. SQL.net - это сетевой продукт Oracle, обеспечивающий прозрачное соединение между клиентом и базой данных или между двумя базами данных.SQL.net работает поверх многих сетевых протоколов и на многих операционных системах. Доступ к базе данных осуществляется с помощью сервера HAS, разработанного компанией Peter-Service. Запросы на сервер поступают по протоколам http/https с web-сервера Apache, который в свою очередь предоставляет доступ пользователям к визуальному интерфейсу во всех филиалах.

Рис. 1.4 - Структурная схема SFA

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

1. Создание потенциального клиента в SFA;

2. Создание на потенциальном клиенте первой продажи;

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

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

5. Продажа завершается путём создания лицевого счёта в филиальном BIS;

6. После успешного завершения продажи клиент SFA из потенциального становится действующим.

Рис. 1.5 - Основной бизнес-процесс SFA

Задача Подготовка и заключение договора предназначена для согласования и подписания с клиентом договора, создания или редактирования лицевых счетов клиента, постановки клиента на биллинг. Этапы и шаги работы с задачей:

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

2. Оператору SFA на шаге Создана доступны следующие действия:

a. Сохранение - используется для сохранения новых значений атрибутов задачи без перевода её на другой шаг

b. Новые договор и ЛС - используется для создания нового договора и ЛС на клиента

c. Допродажа на существующий ЛС - используется для продажи дополнительных услуг на существующий лицевой счёт

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

3. При выборе действия Новый договор и ЛС:

a. Шаг задачи принимает значение Согласование с клиентом типового договора

b. Доступен для заполнения атрибут задачи Документы для заключения договора

4. Оператору SFA на шаге Согласование с клиентом типового договора доступны следующие действия:

a. Сохранение - используется для сохранения новых атрибутов задачи без перевода её на другой шаг

b. Договор не согласован, согласовать протокол разногласий - используется при не успешном согласовании договора

c. Договор согласован, создать лицевые счета - используется при успешном согласовании договора

5. При выборе действия Договор согласован, создать лицевые счета:

a. Шаг задачи принимает значение Создание лицевого счета

b. Автоматически создаётся дочерняя задача Новые договор и ЛС

6. Оператор выполняет дочернюю задачу Новые договор и ЛС, при этом в родительской задаче Подготовка и заключение договора оператору доступны следующие действия:

a. Сохранение - используется для сохранения новых значений атрибутов задачи без перевода её на другой шаг

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

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

Дополнительная задача Новые договор и ЛС, предназначена для создания договора и лицевого счёта на клиенте. Задача автоматически создаётся на этапе Подготовка и заключение договора. Задачу можно отменить без завершения, если она не является единственной дополнительной задачей.

Процесс синхронизации лицевых счетов BIS - SFA:

· выполняется разово при создании лицевого счета в BIS;

· запуск синхронизации инициируется заданием(SQL Server Agent), который запускает процедуру синхронизации.

Синхронизируются все юридические и физические лица, у которых заполнен атрибут «ИНН связанного юридического лица». Не синхронизируются ИП. Синхронизацию можно разделить на два этапа: этап по обработке ЛС в BIS до передачи в SFA и этап разбора полученных от BIS ЛС и формирование клиентов в SFA.

Рассмотрим более подробно второй этап. Визуальное представление действующего алгоритма синхронизации BIS - SFA представлено на рис. 1.6.

Этап разбора полученных от BIS лицевых счетов и формирование клиентов в SFA начинается с определения, является ли лицевой счёт резидентом. Если лицевой счёт является резидентом, то для него проверяется наличие ИНН. В случае отсутствия ИНН, лицевой счёт синхронизирован не будет. Если лицевой счёт не является резидентом, выполняется поиск клиентов в SFA, с соответствующим ИНН. При отсутствии найденных клиентов с аналогичным ИНН, создаётся новый клиент с атрибутами лицевого счёта, а также создаётся синхронизируемый лицевой счёт в SFA и привязывается к вновь созданному клиенту. Если же клиенты с аналогичным ИНН были найдены в SFA, то выполняется проверка наличия КПП у синхронизируемого ЛС. При наличии КПП, выполняется поиск клиента с аналогичным КПП, и осуществляется привязка. При отсутствии КПП у синхронизируемого ЛС, привязка будет выполнена к первому попавшемуся клиенту.

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

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



Рис. 1.6 - Действующий алгоритм синхронизации BIS-SFA

1. При разработке продукта SFA первоначально была реализована бизнес-логика, которая обеспечивала уникальность карточки клиента ЮЛ/ИП в SFA. Использование продукта SFA в промышленной эксплуатации привело к следующему:

a. Совместная работа продавцов в системе приводила к возникновению многочисленных конфликтов из-за одного уникального клиента ЮЛ/ИП и как следствие, к блокировке выполнения продаж на клиенте до момента разрешения конфликта.

b. Для устранения блокировки выполнения продаж был пересмотрен бизнес-процесс работы с карточками клиента и отменена большая часть логики конфликтов. Как следствие, карточки по одному уникальному клиенту ЮЛ/ИП в SFA «размножились» и по факту стали представлять зону ответственности за один или несколько договоров клиента.

c. Для реализации интеграции SFA и CAM необходимо вернуться к логике работы, когда одна карточка клиента SFA отвечает за одно ЮЛ/ИП, при этом обязательно выполняется доработка механизмов уникальности клиентов в системе.

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

2. Формализация требований к разрабатываемому модулю

В SFA вводится сущность Договор для группировки лицевых счетов. Один договор связан только с одной карточкой клиента SFA. На одной карточке клиента может находиться несколько договоров. Договор обладает ключевыми атрибутами: рыночный сегмент, внутренний сегмент, направление продаж, ФАМ (Федеральный Аккаунт Менеджер), ФСМ (Федеральный Сервис Менеджер), номер договора.

Продукт SFA становится мастер системой по ведению договоров. Это значит, что дополнительные атрибуты лицевого счёта наследуются с договора. При редактировании договора значения этих атрибутов синхронизируются на лицевые счета, принадлежащие этому договору в продукт BIS [2].

Вводится процедура идентификации - обеспечение уникальности клиентских сущностей в SFA:

· в идентификации участвуют потенциальные и действующие клиенты;

· в идентификации не участвуют заблокированные клиенты;

· идентификация проводится по ключевым атрибутам клиента ИНН/ОГРН + КПП;

· создание двух клиентов с одинаковыми ИНН или ОГРН и КПП запрещается.

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

В задаче Подготовка и заключение договора дорабатываются все возможные действия задачи. Для дополнительной задачи Новый договор и ЛС реализуется механизм автоматической генерации номера договора, последующего его автоматического создания в SFA при возвращении с формы филиального BIS. Выполняется синхронизация созданного договора в BIS. После внедрения сущности Договор меняется действующая система. На одном клиенте планируется хранить множество договоров, а на каждом договоре в свою очередь, множество лицевых счетов. Обновлённая схема представлена на рис. 2.1.

Рис. 2.1 - Обновлённая схема связи Клиент-Договор-Лицевой счёт

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

идентификация счет модуль интерфейс

3. Выбор инструментов для разработки

В компании Петер-Сервис для работы с сервером приложений HAS используются модули, написанные на языке lua. Данный язык был выбран не случайно. Lua - облегченный скриптовый язык c расширяемой семантикой. У него нет официального стандарта, и стандартом считается описание в руководстве пользователя. В настоящее время Lua является самым популярным скриптовым языком в индустрии игр и используется в ряде приложений в других предметных областях. Основополагающим принципом Lua является расширяемость семантики, т.е. предоставление мета-механизмов для реализации переменного набора инструментов вместо предоставления фиксированного набора инструментов. Это позволяет языку быть небольшим и простым, в то же время сохраняя мощность. Таким образом, Lua можно считать мультипарадигменным языком, поскольку он позволяет вести разработку в различных стилях [3].

Lua поддерживает логические, числовые (по умолчанию -- числа с плавающей точкой двойной точности) и строковые атомарные типы данных. Единственным “родным” сложным типом данных является таблица -- гетерогенный ассоциативный массив, позволяющий использовать разные типы данных для разных пар ключей и значений. Функции являются объектами первого класса, т.е. ими можно манипулировать точно так же, как переменными, передавать и получать как аргументы и т.д.

Lua компилируется в байт-код, исполняемый на виртуальной машине Lua. Lua -- скриптовый язык, созданный для встраивания в другие языки, поэтому предоставляет СиAPI. И так как сам сервер приложений HAS был написан на языке Си, а язык lua позволяет легко и просто с ним взаимодействовать, был выбран именно lua.

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

1. СУБД Oracle Database 11g

Oracle Database 11g представляет собой единую и функционально полную платформу для построения хранилищ данных и бизнес-аналитических систем, в которой сочетаются лучшие в отрасли масштабируемость и производительность, тесно интегрированная аналитика и встроенная интеграция и качество данных. Единая платформа функционирует на основе надёжной, недорогой Grid инфраструктуры. Oracle Database 11g обеспечивает непревзойдённую функциональность для хранилищ данных и витрин данных с проверенной возможностью масштабируемости до сотен ТБ и лучшей на рынке производительностью. Oracle Database 11g также обеспечивает уникальную интегрированную платформу для аналитики, в результате встраивания OLAP, Data Mining и статистики непосредственно в базу данных корпорация Oracle объединяет всю функциональность автономных аналитических механизмов с масштабируемостью, безопасностью и надёжность Oracle Database. Интеграция данных - основное требование любого хранилища данных, поэтому в состав Oracle Database 11g входит лучший инструмент ETL, Oracle Warehouse Builder, в котором используются возможности Oracle по масштабируемому преобразованию данных и разнородному доступу к данным.

2. PL/SQL Developer 12 - IDE для работы с СУБД Oracle

PL/SQL Developer представляет собой интегрированную среду разработки для создания, тестирования, отладки и оптимизации хранимых процедурных модулей на языке Oracle PL/SQL, таких как пакеты, триггеры и других. Среда PL/SQL Developer ориентируется на принципы удобства в работе, повышения качества кода и продуктивности программиста, что является ключевым преимуществом при разработке приложений для платформы Oracle. В распоряжении пользователя находится контекстно-зависимая справочная система. Реализован удобный доступ к описаниям объектов БД, подсветка синтаксических конструкций, построение и редактирование запросов, графический браузер и многие другие инструменты, которые так облегчают жизнь разработчика

3. Sublime Text 3- текстовый редактор с подсветкой синтаксиса

Sublime text - это кроссплатформенный проприетарный текстовый редактор. Поддерживает плагины на языке программирования Python. Редактор поддерживает большое количество языков программирования и имеет возможность подсветки синтаксиса. Sublime Text может быть оснащён менеджером пакетов, который позволяет пользователю находить, устанавливать, обновлять и удалять пакеты без перезагрузки программы. Менеджер поддерживает установленные пакеты в актуальном состоянии, загружая новые версии из репозиториев. Кроме того, он предоставляет команды для активации и деактивации установленных пакетов.

4. HAS-Server - сервер для взаимодействия с СУБД Oracle

Высокопроизводительный сервер приложений HAS предназначен для решения комплекса задач по предоставлению единой точки доступа к функциональным интерфейсам ряда информационно-биллинговых систем. По своим свойствам HAS-server обладает широкими возможностями для построения приложений для Internet/Mobile Network/Intranet с доступом к СУБД биллинговой системы и ориентирован на обслуживание миллионов пользователей.

5. Apache HTTP Server - сервер для обработки HTTP запросов

Apache HTTP Server - это полнофункциональный расширяемый веб-сервер, полностью поддерживающий протокол HTTP/1.1 и распространяющийся с открытым исходным кодом. Сервер может работать практически на всех распространённых платформах. Существуют готовые исполняемые файлы сервера для некоторых операционных систем. При этом он очень прост в установке и конфигурации.

6. AngularJS

AngularJS - JavaScript-Фреймворк с открытым исходным кодом. Предназначен для разработки одностраничных приложений. Его цель - расширение браузерных приложений на основе MVC-шаблона, а также упрощение тестирования и разработки. Фреймворк работает с HTML, содержащим дополнительные пользовательские атрибуты, которые описываются директивами, и связывает ввод или вывод области страницы с моделью, представляющей собой обычные переменные JavaScript. Значения этих переменных задаются вручную или извлекаются из статических или динамических JSON-данных.

7. KarmaJS

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

8. RequireJS

RequireJS является реализацией AMD (Asynchronous Module Definition), API для объявления модулей асинхронной загрузки «на лету», когда они понадобятся. RequireJS помогает в организации кода с помощью модулей и берёт на себя управление асинхронной и параллельной загрузкой файлов. Так как скрипты загружаются только при необходимости и параллельно, это уменьшает время загрузки страницы.

9. Telerik Fiddler

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

10. Grunt.js

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

11. Node.js

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

4. Разработка модуля обработки информации о договорах

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

1. Разработка таблиц, для хранения сущности в базе данных;

2. Проектирование новой сущности;

3. Разработка алгоритма идентификации;

4. Разработка lua-модулей для работы с сущностью на уровне сервера;

5. Разработка пользовательского интерфейса.

4.1 Разработка таблиц, для хранения сущности в базе данных

На данном этапе необходимо спроектировать таблицы, а также разработать API для взаимодействия с этими таблицами [4].

Новая сущность Договор должна содержать следующий набор атрибутов:

· уникальный идентификатор договора

· номер договора;

· тип договора;

· статус договора;

· наименование договора;

· предмет договора;

· аккаунт-менеджер за договор;

· сервис-менеджер за договор;

· рыночный сегмент;

· внутренний сегмент;

· направление продаж;

· дата заключения договора;

· дата истечения договора;

· идентификатор клиента, которому принадлежит договор.

Спроектированная таблица для сущности Договор представлена на рис. 4.1.

Рис. 4.1 - Таблица, содержащая договора

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

Рис. 4.2 - Таблица, содержащая статусы договоров

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



Рис. 4.3 - Таблица, содержащая типы договоров

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

Рис. 4.4 - Таблица, содержащая исторические записи

Итого получается 4 таблицы, полученная структура отражена на рис. 4.5.

В состав справочника статусов договоров войдут две записи:

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

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

В состав справочника типов договоров войдут следующие записи:



Рис. 4.5 - Общая схема таблиц и их взаимосвязь

LG - Тип принадлежности договора legacy филиалам

GF - Тип принадлежности договора проекту Greenfield (все legacy филиалы, присоединившиеся к проекту Greenfield, ведут свои записи в единой системе)

GF_FIX - Тип принадлежности оговора проекту GreenfieldFix (Первая стадия проекта Greenfield)

PETERSTAR - Тип принадлежности договора к биллингу ПетерСтар

Для созданных таблиц необходимо создать sql-пакет, объект базы данных, который группирует логически связанные типы, программные объекты и подпрограммы PL/SQL [5]. Пакеты состоят из двух частей: спецификации и тела.

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

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

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

· создание договора;

· обновление договора;

· получение договора;

· получение списка договоров;

· получения списка статусов договоров;

· получения списка типов договоров;

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

· перенос лицевого счёта с одного договора на другой;

Рис. 4.6 - Алгоритм работы слияния договоров

· закрытие договора;

· объединение договоров;

· проверка возможности редактирование договора.

Разработанное и размещённое в пакете SFA_CONTRACTS_PG API приведено в «Приложение Б». Алгоритм работы процедуры слияния договоров приведён на рис. 4.6

4.2 Проектирование новой сущности

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

Рис. 4.7 - Диаграмма разработанных классов

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

Диаграмма последовательности взаимодействия этих сущностей, представлены ниже. На первой диаграмме (рис.4.8) изображён процесс создания оператором нового клиента и получение новых лицевых счетов в системе, в которые впоследствии можно будет внести изменения. Жирными линиями выделены те объекты, которые появились вследствие доработок, выполненных в рамках данной дипломной работы. Для получения созданных лицевых счетов оператору будет необходимо создать нового клиента, и завести новую продажу. Автоматически, у новой продажи создаётся новая задача на создание лицевых счетов. В процессе выполнения шагов задачи происходит создание нового договора, а также создание новых лицевых счетов, которые впоследствии будут привязаны к этому договору.

Рис. 4.8 - Диаграмма последовательности

4.3 Разработка алгоритма идентификации

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

Схема разработанного алгоритма идентификации приведена ниже (рис. 4.9).

Рис. 4.9 - Алгоритм идентификации

4.4 Разработка lua-модулей для работы с сущностью на уровне сервера

На языке lua выполнены утилитные модули, реализованы классы сущностей на уровне сервера. Для каждой функции, реализованной в БД создаётся lua обёртка, в виде операции, чтобы разместить в HAS-сервере, и выполнять их по запросу. Часть операций будут вызывать непосредственно sql-API, а часть будут содержать дополнительную логику. На фрагменте с кодом ниже изображена операция получения списка договоров с дополнительной информацией - SFA_GET_CONTRACTS_WITH_INFO. Алгоритм работы приведён на рис. 4.10.

Данная операция получает информацию по договорам, добавляя к выходным данным имена менеджеров, ответственных за договора. Операция начинается с получения параметров из URL, находящимся в http запросе. Приставка ps.sfa_common обозначает обращение к утилитному модулю sfa_common в котором располагаются публичные общие функции. Метод ps.sfa_common.getOpParam позволяет получить параметр с определённым названием из URL. Метод ps.script.exec выполняет операцию, название которой указано первым параметром, с массивом параметров, указанных во втором параметре функции. Метод ps.sfa_common.checkHASError - проверяет выполненную операцию на наличие ошибок исполнения, в случае ошибки выбрасывает исключение, которое будет отображено с помощью диалогового окна для пользователя. Операция SFA_GET_CONTRACT_LIST вызывает процедуру get_contract_list из пакета SFA_CONTRACT_PG. Содержимое тела пакета приведено в «Приложение Г».

На рисунке ниже, изображена операция обновления информации о договоре - SFA_UPDATE_CONTRACT_SYNC_BIS. В дополнение, операция инициирует отправку синхронизирующей информации в продукт BIS.

Также выполняется создание нового файла «contract.lua», где будет находится класс Договор и обращения к пакету с API для договоров. Впоследствии этот класс будет задействован в других lua-файлах и классах, находясь на уровне контроллера данных.

Рис. 4.10 - Алгоритм работы операции SFA_GET_CONTRACTS_WITH_INFO



Рис. 4.11 - Алгоритм работы операции SFA_UPDATE_CONTRACT

После того, как мы создали модель и контроллер данных, а также обеспечили успешный обмен данными между ними, необходимо перейти к этапу «Разработка пользовательского интерфейса» [6].

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

Уровень представления реализуется на языке JavaScript с использованием таких фреймворков, как AngularJS, RequireJS.

В современных веб-приложениях требуется разбивка всей структуры приложения на модули, так как их размеры достигают внушительных размеров. При разработке модульных приложений на JavaScript возникает ряд проблем [7]. Первая проблема возникает при попытке описания и подключении зависимостей из разных частей приложения. Она состоит в необходимости подключения зависимостей на серверной стороне. Второй проблемой является размещение переменных в глобальной области, их видимость и возможные коллизии в данных. Обе эти проблемы можно решить при использовании подхода Asynchronous Module Definition. Он сводится к тому, что все подключаемые в будущем модули будут описаны функцией define, а их подключение будет осуществляться функцией require.

Концепция AMD помогает избежать хаоса при использовании большого количества файлов проекта в разработке, помогает при написании кода, который, впоследствии, можно использовать повторно. А, также снимает ответственность за подключение файлов с серверной стороны. К текущему моменту в интернете имеется множество инструментов, реализующих данную концепцию. После анализа всевозможных инструментов был выбран requireJS, он поможет при расположении вновь созданных angular-форм [8].

Для реализации возможности работы с сущностью договор была разработана форма, на которой отображён список договоров, имеющихся у клиента. На созданной форме доступно редактирование договора, создание нового, а также закрытие действующего договора. Загрузка новых записей в список будет осуществляться по принципу live-scroll.

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

Вновь созданная angular-форма будет расположена внутри каталога contracts, и иметь в своём составе несколько файлов. Структура каталога и расположение файлов приведено на рис. 4.12.

Рис. 4.12 - Структура каталога

Здесь можно выделить несколько моментов. В каталоге i18 располагаются файлы локализации в формате json. В зависимости, от выбранного языка, для оператора, в форму будут подтягиваться названия кнопок, и полей на том языке, который он выбрал. Файл define.js позволяет подключать данную форму фреймворку requireJS. Сама форма состоит из html-файла, в котором находятся все элементы и компоненты формы, одноимённого js-файла контроллера для формы, где будут происходить перестроение html формы по указанию. Также в подкаталоге js, находится сервис для формы, содержащий в себе всю бизнес-логику для работы с контроллером, и отправляющий запросы на серверную сторону [9].

Итоговое пользовательское представление формы изображено на рис. 4.13. На нём показан выбранный в таблице договор с идентификатором 1511, а также панель с атрибутами доступными на редактирование.

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

Рис. 4.13 - Пользовательское представление формы

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

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

При клике по кнопке очистки фильтров, произойдёт очистка всех фильтров, заполненных в шапке таблицы, и обновление данных в таблице.

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

Рис. 4.14 - Добавление нового договора

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

Таблица с данными реализована при помощи директивы ps-grid. Для ps-grid имеется ряд настроек, для отображения данных. Атрибут rows позволяет задавать модель данных для таблицы, которые будут отображены пользователю. Атрибут selected заполняется автоматически представлением для выделенных записей в таблице, в случае с возможностью выделения множества записей, в данный атрибут может попасть массив. Атрибут on-scroll позволяет привязать событие, срабатывающее при прокрутке оператором записей. Атрибут on-sort позволяет добавить событие, срабатывающее, при нажатии пользователем на шапку одного из столбцов для сортировки [10].

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

Рис. 4.15 - Окно с настройками отображения

Информационная панель реализована при помощи директивы ps-property-grid и представлена рядом полей, которые оператору необходимо заполнить для успешного создания нового или редактирования уже действующего договора. Номер договора является простым текстовым полем, а вот такие поля, как Площадка, Рыночный сегмент, Внутренний сегмент, Направление продаж, ФАМ, ФСМ представлены справочниками. Для реализации поля-справочника была использована директива ps-text-dictionary. При нажатии на крестик произойдёт очистка поля, от заполненных данных. При нажатии на многоточие, откроется окно со справочными данными, из которых необходимо отметить нужное справочное значение и нажать на кнопку «Выбрать». Выбранное справочное значение отобразится в поле, после чего можно перейти к заполнению следующих полей.

Рис. 4.16 - Справочник рыночных сегментов

Ещё одними необычными полями являются «Дата создания» и «Дата расторжения» договора. Они представлены на форме в виде директивы ps-date-time. При щелчке на иконку календаря, откроется небольшой календарь, с возможность установки конкретной даты, а также ползунок под ним с возможностью установки конкретного времени.

Рис. 4.17 - Установка даты для поля «Дата заключения»

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

Рис. 4.18 - Всплывающая подсказка

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

При нажатии кнопки Сохранить, произойдёт проверка заполнения всех полей, а также на корректность введённых значений, так для поля номер договора имеется ограничение на максимальное количество возможных символов - 150.

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

Рис. 4.19 - Ошибка создания нового договора

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

5. Тестирование разработанного модуля

Тестирование разработанной функциональности необходимо разделить на несколько частей:

1. Тестирование модели данных и методов работы с новым классом;

2. Тестирование контроллера работы с данными;

3. Тестирование части представления.

Начать необходимо с тестирования модели данных и методов работы с новым классом Договор.

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

Таблица 5.1 Тестовые наборы данных для тестирования API

№ тестового набора	Исполняемая процедура	Результат
1	Create_contract	Ошибка выполнения процедуры! Переданный идентификатор типа договора не был найден в системе!
2	Create_contract	Ошибка выполнения процедуры! Переданный идентификатор оператора не был найден в системе!
3	Create_contract	Договор с идентификатором 1 успешно был создан в системе!
4	Update_contract	Ошибка выполнения процедуры! Договор с идентификатором 2 не был найден в системе!
5	Update_contract	Договор был успешно обновлён!
6	Get_contract_ty pe_by_kn	Процедура вернёт NULL, так как типа договора с переданным кейнеймом не существует в системе
7	Get_contract_ty pe_by_kn	Процедура вернёт идентификатор 2.
8	Close_contract	Ошибка выполнения процедуры! Договор с идентификатором 2 не был найден в системе!
9	Close_contract	Договор успешно был закрыт

Для дальнейшего тестирования нам потребуется создать три дополнительных договора. Первый и второй, с идентификаторами 2 и 3 соответственно будут предназначаться для тестирования слияния двух договоров в один, а третий созданный договор с идентификатором 4 потребуется для тестирования переноса лицевого счёта. Заведём новый лицевой счёт, его сгенерированный идентификатор равен 13364. Привяжем его к договору с идентификатором 3.

Таблица 5.2 Тестовые наборы данных для тестирования слияния и переноса договоров

№ тестового набора	Исполняемая процедура	Результат
10	Merge_contract_into	Ошибка выполнения процедуры! Договор-донор с идентификатором 5 не был найден в системе!
11	Merge_contract_into	Ошибка выполнения процедуры! Договор-реципиент с идентификатором 6 не был найден в системе! ...

Подобные документы

• Автоматизация процесса обработки информации для сотрудников приёмной комиссии техникума

  Разработка сайта для хранения и обработки информации об абитуриентах в среде программирования Delphi 7. Архитектура базы данных. Функциональная схема программы. Даталогическая модель данных. Сущности БД и архива. Элементы пользовательского интерфейса.
  
  дипломная работа [4,2 M], добавлен 30.03.2015
  

• Разработка базы данных для хранения и обработки информации исследований плоских моделей взрывных размыкателей

  Процесс разработки базы данных для хранения и обработки информации. Ключи, индексы, триггеры, хранимые процедуры. Разработка пользовательского интерфейса и базы данных. Основные инструментальные средства для разработки клиентской и серверной частей.
  
  дипломная работа [225,0 K], добавлен 18.05.2013
  

• Разработка модуля внешней обработки для "1С Предприятие 8.2. Управление торговлей 10.3"

  Выбор методологии проектирования информационной системы, сбор требований, их моделирование. Архитектурное проектирование, разработка пользовательского интерфейса и модулей. Реализация и аттестация информационной системы. Методика работы с приложением.
  
  дипломная работа [2,9 M], добавлен 25.05.2014
  

• Создание баз данных

  Создание автоматизированной системы – "Агентство по трудоустройству". Проектирование таблиц для хранения данных. Разработка запросов и отчетов, предназначенных для просмотра, редактирования и вывода информации. Разработка пользовательского интерфейса.
  
  курсовая работа [4,9 M], добавлен 29.01.2011
  

• База данных спортивного инвентаря

  Разработка программы "База данных спортивного инвентаря". Описание алгоритма работы модулей и блоков. Структурная схема представления проекта. Процесс поиска нужной информации. Автоматическая сортировка данных. Добавление и редактирование записей.
  
  курсовая работа [3,0 M], добавлен 15.08.2013
  

• Разработка и внедрение модулей защиты информации от несанкционированного копирования в информационную систему

  Характеристика потенциальных угроз информации в информационной системе фирмы. Принцип функционирования программного обеспечения, разработка модулей и проект таблиц баз данных. Требования безопасности при работе на ПЭВМ, оценка эффективности проекта.
  
  дипломная работа [3,6 M], добавлен 28.06.2011
  

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

  Разработка проекта приложения, содержащего локальную базу данных для хранения и обработки ведомости работы расчетно-кассового узла универсама. Процесс разработки интерфейса и проекта интерактивной системы. Запуск и отладка, инструкция по эксплуатации.
  
  курсовая работа [34,2 K], добавлен 29.03.2011
  

• Автоматизированная информационная система

  Реализация программной системы "Магазин" для автоматизации деятельности и обеспечения хранения, накопления и предоставления информации. Логическая и физическая структуры базы данных. Разработка пользовательского интерфейса. Создание таблиц, представлений.
  
  контрольная работа [3,9 M], добавлен 31.03.2014
  

• Разработка программного модуля

  Структурная диаграмма программного модуля. Разработка схемы программного модуля и пользовательского интерфейса. Реализация программного модуля: код программы; описание использованных операторов и функций. Вид пользовательской формы с заполненной матрицей.
  
  курсовая работа [215,3 K], добавлен 01.09.2010
  

• Создание базы данных для ФК "Зенит"

  База данных для ЗАО "ФК "Зенит", предназначенная для хранения и обработки данных о работниках клуба, его бюджете и результатах участия в соревнованиях. Разработка предварительных отношений и пользовательского интерфейса. Структура таблиц базы данных.
  
  курсовая работа [4,4 M], добавлен 10.12.2011
  

• Проектирование модуля продаж и запросов "Plex Online"

  Разработка приложения "Plex Online" для контроля online-мониторинга производственного процесса, продаж, остатков товара и прочим функционалом. Разработка и тестирование программных модулей. Оптимизация работы базы данных путем кэширования данных.
  
  дипломная работа [1,8 M], добавлен 06.06.2016
  

• Реализация многопользовательской модели игрового приложения

  Разработка игрового проекта на игровом движке Unity 3D в среде программирования MS Visual Studio 2017. Блок-схема алгоритма работы приема сообщений с сервера на клиенте с упрощенным описанием выполняемых команд. Реализация пользовательского интерфейса.
  
  курсовая работа [1,5 M], добавлен 10.07.2017
  

• Знакомство с компьютером

  Структурная схема компьютера. Основные характеристики процессора - устройства, предназначенного для обработки информации и управления процессом обработки. Способы хранения информации. Описание, назначение и принципы работы устройств ввода и вывода данных.
  
  презентация [862,1 K], добавлен 20.07.2011
  

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

  Выбор технологии, языка и среды программирования. Анализ процесса обработки информации и выбор структур данных для ее хранения, разработка основных алгоритмов. Проектирование интерфейса пользователя. Выбор стратегии тестирования и разработка тестов.
  
  курсовая работа [332,3 K], добавлен 09.12.2014
  

• Автоматизированное получение данных в администрации Ленинского района г. Барнаула

  Создание таблиц базы данных и связей между ними. Разработка предварительного пользовательского интерфейса. Создание модуля "запросы". Разработка кнопочной формы и запросов. Проект по автоматизации планирования распределения ресурсов предприятия.
  
  отчет по практике [1,9 M], добавлен 17.03.2015
  

• Разработка программы "Расписание учебных занятий"

  Назначение программного модуля (базы данных). Разработка информационной базы данных для колледжа. Поиск пользователями информации о преподавателях и дисциплинах. Анализ входной и выходной информации. Разработка алгоритма работы программы-приложения.
  
  реферат [513,1 K], добавлен 22.10.2012
  

• Создание программного модуля на тему: "Организация работы автосервиса"

  Описание разрабатываемой программы с точки зрения пользователя и программиста. Поэтапная разработка программной системы. Создание базы данных в Access. Разработка структуры классов. Создание структуры для хранения данных. Проектирование интерфейса.
  
  курсовая работа [1,4 M], добавлен 07.08.2013
  

• Разработка системы сохранения результатов анкетирования в базе данных MS SQL Server

  Разработка программного продукта - приложения, позволяющего заносить данные анкетирования в базу данных MS SQL. Описание логики работы приложения, особенности пользовательского интерфейса. Формы просмотра анкет, описание процедур и функций программы.
  
  курсовая работа [1,2 M], добавлен 16.08.2012
  

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

  Разработка модуля для вычисления значения функции, который впоследствии подключается к программе ввода исходных данных с контролем допусимого значения в таблицу. Проектирование модуля для работы со строками и для обработки массивов текстовой информации.
  
  курсовая работа [17,8 K], добавлен 24.09.2010
  

• Автоматизация системы обработки экономической информации в малом торговом предприятии "Манго" (оптовая торговля)

  Требования и структура систем обработки экономической информации. Технология обработки информации и обслуживание системы, защита информации. Процесс создания запросов, форм, отчетов, макросов и модулей. Средства организации баз данных и работы с ними.
  
  курсовая работа [2,7 M], добавлен 25.04.2012
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам