Проектирование клиент-серверного приложения для учёта, контроля и поддержки бизнес-процессов по реализации товаров и услуг

Е.В. Петренко

Национальный исследовательский Иркутский государственный технический университет

Представлена модель реализации базы данных и приложения для учета, контроля и поддержки бизнес-процессов по реализации товаров и услуг. Описана контекстная диаграмма процесса деятельности ИП «Акбулатов М.И.», проведен процесс декомпозиции в нотации IDEF0 при помощи CASE-средства BPWin. Изображены диаграммы прецедентов, классов (разбитые на два пакета: «Сущности базы данных» и «Интерфейс приложения»), диаграммы последовательности, выполненные в CASE-средств Rational Rose.

Постановка задачи

Создание простого, удобного программного средства для учёта, контроля и поддержки бизнес-процессов по реализации товаров и услуг для ИП «Акбулатов М.И.».

Перечислим выполненные этапы:

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

постановка задачи;

описание бизнес-процессов (функциональное описание системы);

проектирование базы данных;

проектирование приложения;

реализация;

тестирование.

Функции приложения

сбор и накопление данных о клиентах

сбор и накопление данных о поставщиках

сбор и накопление данных о сотрудниках

сбор и учёт данных о заказах клиентов

сбор и учёт данных о заявках клиентов

сбор и учёт данных о заказах поставщикам

формирование финансовых документов

формирование отчётов по продажам, услугам и закупкам

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

Функциональное Описание начинается с контекстной схемы (система, отделенная от окружающей среды с указанием связей с этой средой) и представлено на рис. 1.

Рис. 1. Контекст системы

На этой схеме:

стрелки слева отображают необходимые для исполнения процессы, они являются входами;

стрелки справа отображают результаты исполнения этих процессов, это стрелки выхода;

стрелки снизу отображают, механизмы, т.е. те объекты, которые собственно и исполняют процессы (в моём случае это ПО и сотрудники);

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

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

производительные (бизнес-процессы);

организационные;

процессы управления.

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

Рис. 2. Декомпозиция функционального блока

«Продажа компьютеров, компьютерной техники и их обслуживание»

На этом декомпозиция не заканчивается. Её результатом являются функциональные блоки:

«Планирование» (рис. 3);

«Поддержка бизнес-процессов» (рис. 4);

«Управление закупок, продаж, ремонтных работ» (рис. 9).

Декомпозиция функционального блока «Планирование»

Всё планирование состоит из составления общего плана и составления плана каждому сотруднику.

Рис. 3. Декомпозиция функционального блока «Планирование»

Декомпозиция функционального блока «Поддержка бизнес-процессов»

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

Рис. 4. Декомпозиция функционального блока «Поддержка бизнес-процессов»

На декомпозиции блока «Поддержка бизнес-процессов» не видно полных процессов на этапах: заказ товара, консультирование, продажи и ремонт. Поэтому мы производим ещё декомпозиции функциональных блоков:

«Заказ товара» (рис. 5);

«Консультирование» (рис. 6);

«Продажи» (рис. 7);

«Ремонт» (рис. 8).

Декомпозиция функционального блока «Управление закупок, продаж, ремонтных работ»

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

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

И всё это опять начнёт повторяться по циклу.

Рис. 9. Декомпозиция функционального блока

«Управление закупок, продаж, ремонтных работ»

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

Рис. 10. Архитектура клиент-серверной технологии

По рис. 10 можно понять, что обработка запроса пользователя происходит при обращении через сервер к БД (SQL-запросу). Передачей ответа будет результат обработки.

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

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

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

Моделирование будет представлено в виде объектной модели на языке UML в пакете Ration Rose.

Это моделирование позволяет решить следующие задачи:

визуализировать систему;

определить структуру;

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

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

диаграмма прецедентов (рис. 11);

диаграмма классов (пакет «интерфейс приложения», рис. 12);

диаграмма классов (пакет «сущности базы данных», рис. 13);

диаграмма последовательностей «Ведение списка клиентов» (рис. 14);

диаграмма последовательностей «Ведение списка заказов на товар» (рис.15);

диаграмма последовательностей «получение отчётов по продажам» (рис. 16).

Диаграмма прецедентов

На этой диаграмме представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов особенно важны при организации и моделировании поведения системы.

Рис. 11. Диаграмма прецедентов

Далее показаны диаграммы классов. Для их представления создано два пакета: пакет «интерфейс приложения» и пакет «сущности базы данных». На диаграмме классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения.

Диаграмма классов (пакет «интерфейс приложения»)

Диаграмма (пакет «интерфейс приложения») содержит классы интерфейса проектируемого приложения.

Рис. 12. Диаграмма классов (пакет «интерфейс приложения»)

Диаграмма классов (пакет «сущности базы данных»)

Диаграмма классов (пакет «сущности базы данных») содержит сущности базы данных. Собственно название пакета говорит само за себя.

Рис. 13. Диаграмма классов (пакет «сущности базы данных»)

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

Диаграммы последовательностей «Ведение списка …»

Перечисленные диаграммы: «Ведение списка клиентов»; «Ведение списка сотрудников»; «Ведение списка поставщиков»; «Ведение списка услуг» являются аналогичными, поэтому представлю одну из них, например «Ведение списка клиентов» (рис. 14).

Рис. 14. Диаграммы последовательностей «Ведение списка клиентов»

Диаграммы последовательностей «Ведение списков заказов …»

Перечисленные диаграммы: «Ведение списка заказов на товар»; «Ведение списка заказов на услуги»; «Ведение списка заказов поставщикам» являются аналогичными, поэтому представлю одну из них, например «Ведение списка заказов на товар» (рис. 15).

Рис. 15. Диаграмма последовательности «Ведение списка заказов на товар»

Диаграммы последовательностей «Получение отчётов …»

Перечисленные диаграммы: «Получение отчётов по продажам»; «Получение отчётов по закупкам»; «Получение отчётов по услугам» являются аналогичными, поэтому представлю одну из них, например «Получение отчётов по продажам» (рис. 16).

Рис. 16. Диаграмма последовательности «Получение отчётов по продажам»

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

Список литературы

1. Дорофеев А.С. Базы данных: учеб. пособие. Иркутск: Изд-во ИрГТУ, 2008. 100 с.

2. КватраниТ. Rational Rose 2000 иUML. Визуальное моделирование. М.: ДМК Пресс, 2001. 176 с.

3. Маклаков С.В. BPWin и ERWin. CASE-средства разработки информационных систем. М.: Диалог-МИФИ , 1999. 256 с.