Тема дипломной работы: Разработка системы поддержки продаж на платформе VDOM

Дипломная работа 58 с., 13 рис., 9 табл., 10 источников, 4 прил.

Ключевые слова: ИНФОРМАЦИОННАЯ СИСТЕМА, СИСТЕМА ПОДДЕРЖКИ ПРОДАЖ, РЕЛЯЦИОННАЯ БАЗА ДАННЫХ, ER-МОДЕЛЬ ДАННЫХ, SQL, БИЗНЕС-ЛОГИКА, ORM, UML, API, XML, WEB, VDOM, E2VDOM, PYTHON

Цель: разработка системы поддержки продаж на платформе VDOM.

Результаты работы: разработана реляционная БД, слой бизнес-логики, web-интерфейс, а также внешний API, для интеграции со сторонними приложениями. Система внедрена.

Область применения: разработанная система используется в качестве системы поддержки продаж подразделениями и партнерами компании VDOM Box International.

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

* Содержание *



Введение

1 Анализ

1.1 Концепция

1.2 Основные требования

1.3 Предметная область

2 Проектирование

2.1 Схема базы данных

2.1.1 ER-схема

2.1.2 Реляционная схема

2.2 Архитектура

2.2.1 Слой бизнес-логики

2.2.2 Внешний API

2.3 Пользовательский интерфейс

3 Реализация

3.1 Платформа VDOM

3.1.1 Технология VDOM

3.1.2 Технология E2VDOM

3.1.3 Аппаратная и программная части

3.1.4 Объектная модель

3.1.5 Web-сервисы

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

3.3 Архитектура

3.3.1 Слой бизнес-логики

3.3.2 Внешний API

3.4 Пользовательский интерфейс

3.4.1 Web-интерфейс

3.4.2 Пример реализации одной из web-страниц

Заключение

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

Приложение А. ER-диаграмма

Приложение Б. Реляционная диаграмма

Приложение В. Диаграмма классов слоя бизнес-логики

Приложение Г. Руководство пользователя



* Выдержки из текста *



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

Основным товаром, распространяемым компанией VDOM Box International, является web-сервер приложений VDOM Box, который объединяет в себе аппаратную и программную части. Стоит отметить, что, как правило, продается не сам сервер, а некое «готовое решение», в комплект поставки которого входит также некий набор устройств (например, флэш-карта), приложений и услуг (например, гарантийное обслуживание).

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

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

Разрабатываемая система поддержки продаж под названием VBI Partners в первую очередь должна решать именно приведенные выше задачи. Непосредственными пользователями данной системы, работающими с ней через web-интерфейс, станут первичные поставщики товаров и дистрибьюторы.



***



Для начала рассмотрим технические возможности VDOM по разработке БД. Как уже было сказано ранее, в системе VDOM в качестве СУБД используется вариация SQLite – embedded SQLite 3. Данная СУБД является «встраиваемой», то есть разработанная с ее помощью база данных интегрируется непосредственно в само приложение.

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

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

• Отсутствие поддержки составных первичных ключей.

• Отсутствие поддержки внешних ключей.

• Отсутствие поддержки каскадных операций.

• Отсутствие поддержки триггеров.

• Ограниченный набор типов данных.



***



Поговорим теперь о самом процессе проектирования.

Первым шагом проектирования был выбор способа организации бизнес-логики. После анализа существующих подходов, описанных в [3], был сделан выбор в пользу «модели предметной области» (Domain Model), так как наша предметная область является относительно сложной и, возможно, будет усложняться в будущем. Выбранный подход предполагает, что классы бизнес-логики и их ассоциации в определенном смысле соответствуют сущностям предметной области и отношениям между ними.

Вторым шагом проектирование был выбор способа выполнения преобразований ORM (Object-Relational Mapping) [4], то есть преобразования данных из реляционного представления в объектное и наоборот. Из описанных в [3] вариантов был выбран способ, известный под названием Active Record, так как он является относительно простым в реализации и хорошо сочетается с организацией бизнес-логики по принципу модели предметной области. Паттерн Active Record подразумевает, что каждый класс содержит в себе как бизнес-логику, так и методы доступа к базе данных (выборка, создание, обновление, удаление).

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



***



В данном пункте рассмотрена реализация API на платформе VDOM. Рассмотрим для начала средства, предоставляемые используемой платформой для решения поставленной задачи. Платформа VDOM предоставляет возможность удаленного вызова процедур посредством библиотеки, работающей по протоколу SOAP. Каждая процедура оформляется в виде отдельного файла исходного кода на языке Python и помещается в приложение, из которого может быть в последствие вызвана. Ввод и вывод данных осуществляется в формате XML. Вызываемая процедура получает данные через сессию, через переменную с фиксированным именем (xml_data). Выходные данные отправляются аналогично – сохраняются в переменную с фиксированным именем (response).

Теперь поговорим непосредственно о реализации внешнего API. Разработка каждой отдельной API-операции подразумевает последовательное решение трех задач, а именно:

• Анализ входных XML-данных.

• Реализация логики операции.

• Формирование выходных XML-данных.



***



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

Визуальная часть разрабатывалась за счет размещения на каждой странице объектов и задания значений их атрибутам. В некоторых местах для задания изощренного оформления, использовались стили CSS [10]. Различные, чисто декоративные элементы оформления, такие, как например, логотип, иконки, рисунки, шапка сайта, использованные при оформлении пользовательского интерфейса, были разработаны дизайнером компании VDOM Box Research. Для задания визуальной составляющей страниц, использовалась интегрированная среда разработки VDOM IDE.

Поведенческая часть разрабатывалась за счет использования технологии event->action. Для построения схемы взаимодействия размещенных на страницах объектов также использовалась VDOM IDE. Для написания логики обработчиков событий (action-ов) использовалась VDOM Script IDE, так как функциональность редактора скриптов VDOM IDE оказалась довольно-таки ограниченной.