Читайте также:
|
Функциональное моделирование является важнейшим элементом концептуального анализа, который выполняется на начальном этапе проектирования любой автоматизированной информационной системы, в том числе и системы управления предприятием. Разработка и анализ функциональной модели деятельности предприятия позволяет достаточно глубоко погрузиться в предметную область, выявить бизнес-процессы, используемые на предприятии, определить информационные потоки, выявить узкие места в деятельности предприятия и т.д. Для функционального анализа на концептуальном этапе удобно использовать простые, доступные для широкого понимания использования, хорошо проработанные методологии. Несмотря на солидный возраст стандартной методологии IDEF0, она по-прежнему весьма популярна среди аналитиков и широко используется, особенно на этапе концептуального анализа. Детальный анализ функциональной IDEF0-модели является основой для изучения существующих на предприятии бизнес-процессов и для разработки новых бизнес-процессов, которые в дальнейшем будут являться основой для разработки алгоритмов системы управления. Для моделирования бизнес-процессов удобно воспользоваться специально разработанной для этих целей методологией IDEF3. Модель IDEF3 содержит 2 типа диаграмм: диаграммы процессов и диаграммы состояний объектов, которые позволяют выполнить анализ бизнес-процессов с разных сторон в рамках одной модели. Разработка функциональной модели может быть произведена как AS IS - "функциональная модель как есть", или как TO BE - "функциональная модель как должно быть". Первая из них описывает функционирование существующей системы, вторая является проектным описанием работы создаваемой системы, или проектным описанием существующей системы, подвергающейся модернизации. Функциональная модель "как есть" является объектом и отчасти инструментом анализа, и позволяет выявить причины нерационального функционирования исследуемой моделируемой системы. Функциональная модель "как должно быть" является, обычно, основой технического задания на создание или модернизацию системы (рис.2).
Рис.2. Контекстная диаграмма «Продажа товаров»
Процесс продажи товаров происходит при участии продавца и покупателя, на взаимодействие которых оказывают влияние закон «О защите прав потребителей» и внутренние документы торгового предприятия, регламентирующие его деятельность. На входе этого процесса информация по товарам (наименование, цена, характеристики), запросы покупателей (товар, количество), данные о клиентах (ФИО, адрес, телефон) и информация о наличии товаров. На выходе, соответственно, товарный чек, кассовый чек, документы на гарантию, отгруженный товар, либо отказ в покупке в связи с отсутствием товара на складе. Рассмотрим теперь детализацию этого процесса (рис.3).
При детализации общего процесса продажи товаров получаем следующие этапы: запрос покупателя, поиск товара на складе, оформление продажи, выдача товара. Входной информацией для запроса покупателя является информация по товарам (наименование, цена, количество) и запросы покупателей (товар, количество), механизмом этого подпроцесса является и продавец, и покупатель. Выходной информацией здесь будет информация о выбранном товаре и его количестве, эта информация будет входной для следующего этапа – поиска товара на складе. Здесь на входе также информация о наличии товара, механизм – продавец. На выходе – либо отказ в связи с отсутствием товара на складе, либо информация о наличии данного товара. Переходим на этап оформления продажи. На входе кроме информации о наличии данного товара также данные о клиенте. Механизм – продавец и покупатель, на выходе – счет на оплату, который является входной информацией для подпроцесса выдачи товара. И наконец, после выдачи товара получаем: отгруженный товар, товарный чек, кассовый чек, документы на гарантию.
При детализации подпроцесса запроса покупателя (рис.4) можно отметить, что он разбит еще на три блока (формулирование требований к будущей покупке, анализ имеющихся товаров, выбор желаемого товара). При наличии общих сведений по товарам (наименовании, цене, характеристикам) покупатель формулирует требования к будущей покупке, на выходе этого этапа мы получаем список требований, они будут входным параметром для этапа анализа имеющихся товаров. Запросы покупателя о товаре и его количестве также на входе этого этапа. Механизмом для этого этапа является и покупатель, и продавец. На выходе – информация о товарах, удовлетворяющих требованиям, эта информация входная для последнего этапа. Последний этап – выбор желаемого товара (из нескольких, которые могут удовлетворять требованиям), механизм здесь также и продавец, и покупатель. На выходе – информация о выбранном товаре и его количестве.
Рис.3. Диаграмма декомпозиции «Продажа товаров»
Рис.4. Диаграмма декомпозиции «Запрос покупателя»
Поиск товара на складе (рис.5) представляет собой подпроцесс, состоящий из трех этапов: задание критериев поиска, поиск товаров, удовлетворяющих критериям, формирование списка результатов поиска. На входе первого этапа информация о выбранном товаре и его количестве, механизм здесь – продавец. На выходе получаем список критериев, которые являются входной информацией для поиска товаров, удовлетворяющих критериям. На этом этапе входной информацией также является информация о наличии товаров. Механизм также – продавец, на выходе получаем результаты поиска. Они будут входными данными для формирования списка результатов поиска, механизмом для которого также является продавец. В итоге на выходе этого подпроцесса получаем либо отказ в связи с отсутствием на складе, либо информацию о наличии данного товара.
Подпроцесс оформления продажи состоит из двух этапов (рис.6): получения личных данных клиента и выписки счета. На входе первого данные о клиенте (ФИО, адрес, телефон), механизм здесь и покупатель, и продавец, на выходе – личные данные клиента, которые вместе с информацией о наличии данного товара являются входными параметрами для этапа выписки счета. Здесь механизм и продавец, и покупатель, а на выходе в итоге – счет на оплату.
Подпроцесс выдачи товаров состоит из трех этапов (рис. 7): оплата товара, выдача гарантийных документов на товар, отгрузка товара. На входе первого этапа – счет на оплату, на выходе – кассовый чек, товарный чек, информация об оплаченном товаре. Входной информацией для этапа выдачи гарантийных документов на товар является информация об оплаченном товаре, на выходе здесь – документы на гарантию. Для этапа отгрузки товара входной информацией является кассовый и товарный чеки, полученные на первом этапе. На выходе здесь – отгруженный товар. Все рассмотренные три этапа имеют механизм покупатель и продавец.
Рис.5. Диаграмма декомпозиции «Поиск товара на складе»
Рис.6. Диаграмма декомпозиции «Оформление продажи»
Рис.7. Диаграмма декомпозиции «Выдача товара»
Перейдем к рассмотрению модели “TO-BE”. Процесс автоматизации учета заказов продажи представляет собой сложную систему, на входе которой информация по товарам (наименование, цена, характеристики, производитель), данные о клиенте (ФИО, адрес, телефон), запросы покупателей (товар, количество), параметры отчета по продажам (рис. 8). Механизм процесса: пользователь-клиент, оператор, веб-приложение клиента и СУБД, windows-приложение оператора и СУБД. Управление – внутренние документы торгового предприятия, закон «О защите прав потребителей». На выходе: сведения по товарам в базе данных, сведения о покупателях в базе данных, сведения по заказанным товарам в базе данных, сведения о состоянии заказа в базе данных, электронная корзина, счет на оплату и отчет по продажам.
Общий процесс при детализации представляет собой 6 подпроцессов (рис. 9): формирование справочника по товарам, просмотр списка товаров и составление корзины (предварительный заказ), формирование и оформление заказа, регистрация пользователя-клиента, учет оплаты товара, формирование отчета по продажам. На входе на этап формирования справочника по товарам – информация по товарам (наименование, цена, характеристики, цена, производитель), механизм – windows-приложение оператора и СУБД, оператор, а на выходе – сведения по товарам в базу данных, которые также являются входной информацией для следующего этапа. Просмотр списка товаров и составление корзины (предварительный заказ товаров) на входе также получает еще и запросы покупателей (товар, количество), механизм здесь – веб-приложение клиента и СУБД и пользователь-клиент. На выходе – электронная корзина и информация о выбранных товарах, которая является и входной для следующего этапа – формирование и оформление заказа. Здесь также на входе данные о клиенте и код зарегистрированного пользователя. В случае, если клиент не является зарегистрированным, то он перенаправляется на этап регистрации. То есть на выходе формирования и оформление заказа есть отрицательный результат проверки регистрации (перенаправление на регистрацию), счет на оплату, сведения по заказанным товарам в базу данных и сведения о состоянии заказа в базу данных. Механизм здесь windows-приложение оператора и СУБД, пользователь-клиент. На этапе регистрации (куда направляется пользователь в случае отрицательного результата проверки регистрации) входными данными являются данные о клиенте и отрицательный результат регистрации с этапа формирования и оформления заказа. На выходе – код зарегистрированного пользователя-клиента и сведения о покупателя в базу данных. Механизм - windows-приложение оператора и СУБД, web-приложение клиента и СУБД, пользователь-клиент. После двух логически связанных блоков: формирование и оформление заказа и регистрации клиента следует блок учета оплаты товара. Здесь на входе сведения по заказанным товарам в базе данных, сведения о состоянии заказа в базе данных, счет на оплату. На выходе – обновленные сведения о состоянии заказа в баз данных. Механизм - windows-приложение оператора и СУБД и оператор. Заключительный этап – формирование отчета по продажам. На входе – сведения о состоянии заказа в базе данных, сведения по заказанным товарам в базе данных и параметры отчета. На выходе – отчет по продажам. Механизм – оператор, windows-приложение оператора и СУБД, оператор.
Подпроцесс формирования справочников по товарам состоит из трех этапов (рис. 10): ввод сведений по товарам, генерация кода записи, выполнение SQL-запроса на вставку. На входе на первый этап – информация по товарам (наименование, цена, характеристики, производитель), механизм – оператор и windows-приложение оператора и СУБД, на выходе – сведения по товарам. Они являются входной информацией для этапа генерации кода записи. На выходе этого второго этапа – код записи, а механизм - windows-приложение оператора и СУБД. Наконец, третий этап – выполнении SQL-запроса на вставку. Входной параметр – код записи, на выходе – сведения по товарам в базе данных, механизм - windows-приложение оператора и СУБД.
Подпроцесс регистрации пользователя-клиента предполагает два этапа (рис. 11): ввод личных сведений и выполнение SQL-запроса на регистрацию клиента. На входе на этап «Ввод личных сведений» - данные о клиенте и отрицательный результат проверки регистрации. На выходе – личные сведения. Механизм – пользователь-клиент и веб-приложение клиента и СУБД. Второй этап – выполнение SQL-запроса на регистрацию пользователя-клиента – входным параметром имеет личные сведения, входной информацией – сведения о покупателях в базу данных и код зарегистрированного пользователя-клиента. Механизм – веб-приложение клиента и СУБД и windows-приложение оператора и СУБД.
Рис. 8. Контекстная диаграмма «Автоматизация учета заказов»
Рис. 9. Диаграмма декомпозиции «Автоматизация учета заказов»
Рис. 10. Диаграмма декомпозиции «Формирование справочника по товарам»
Рис. 11. Диаграмма декомпозиции «Регистрация пользователя-клиента»
Подпроцесс «Просмотр списка товаров и составление корзины (предварительный заказ)» (рис. 12) состоит из двух этапов: просмотр списка, отметка необходимых товаров. На входе первого – сведения по товарам в базе данных и запросы покупателей. На выходе – результат просмотра. Механизм – веб-приложение клиента и СУБД и пользователь-клиент. Входными параметрами для этапа отметки необходимых товаров является результат просмотра (выход предыдущего этапа) и запросы покупателей. На выходе здесь имеем электронную корзину и информацию о выбранных товарах. Механизм – пользователь-клиент.
Подпроцесс «Формирование и оформление заказа» (рис. 13) состоит из двух этапов: проверка регистрации и сохранение списка выбранных товаров. На входе первого данные о клиента, код зарегистрированного пользователя-клиента, информация о выбранных товарах. Механизм – веб-приложение клиента и пользователь-клиент. На выходе либо отрицательный результат проверки регистрации, либо положительный результат проверки. При положительном результате проверки переходим на этап сохранения списка выбранных товаров, на выходе которого получаем: сведения по заказанным товарам в базе данных, счет на оплату, сведения о состоянии заказа в базу данных. Механизм здесь – веб-приложение клиента и СУБД.
Подпроцесс «Учет оплаты товара» (рис. 14) состоит из трех этапов: просмотр счетов о продаже, отметка о продаже товаров в электронных заказах, выполнение SQL-запроса на изменение состояния заказа. На входе первого – сведения о состоянии заказа в базе данных, счет на оплату, сведения по заказанным товарам в базе данных. На выходе – информация о проданных товарах. Механизм – windows-приложение оператора и СУБД и оператор. На входе второго этапа (отметка о продаже товаров в электронных заказах) как раз и находится информация о проданных товарах. На выходе – коды проданных товаров и номера заказов. Механизм – windows-приложение оператора и СУБД, оператор. На третий этап (выполнение SQL-запроса на изменение состояния заказа) поступают коды проданных товаров и номера заказов. На выходе – сведения о состоянии заказа в базу данных (обновленная информация). Механизм – windows-приложение оператора и СУБД.
Подпроцесс «Формирование отчета по продажам» (рис. 15) состоит всего из двух этапов: SQL-запрос на выбор сведений из БД по указанной дате и вывод отчета (электронный документ, доступный для печати). Входные параметры для первого этапа – сведения по заказанным товарам в базе данных, сведения о состоянии заказа в базе данных, параметры отчета. Механизм - windows-приложение оператора и СУБД и оператор. Выходной параметр – результат запроса. Он же является входными данными для вывода отчета. Механизм здесь также windows-приложение оператора и СУБД и оператор. Выходные данные – отчет по продажам.
Рис. 12. Диаграмма декомпозиции «Просмотр списка товаров и составление корзины (предварительный заказ)»
Рис. 13. Диаграмма декомпозиции «Формирование и оформление заказа»
Рис. 14. Диаграмма декомпозиции «Учет оплаты товара»
Рис. 15. Диаграмма декомпозиции «Формирование отчета по продажам»
Дата добавления: 2015-12-07; просмотров: 580 | Нарушение авторских прав