Файл: Проектирование подсистемы подготовки и оформления заказов в составе ERP-системы для ИП «Континент».pdf
Добавлен: 13.05.2023
Просмотров: 296
Скачиваний: 5
СОДЕРЖАНИЕ
1.1. Выбор комплекса задач автоматизации
1.2. Характеристика существующих бизнес – процессов
2.1. Информационная модель и её описание
2.2. Характеристика нормативно-справочной, входной и оперативной информации
2.3. Характеристика результатной информации
2.4. Общие положения (дерево функций и сценарий диалога)
2.5. Характеристика базы данных
2.6. Структурная схема пакета (дерево вызова программных модулей)
Таблица 2.6. – Характеристика входной информация бизнес процессов
|
Вход |
Процесс |
|
Накладные |
Деятельность отдела продаж →Прием товаров |
|
Клиентские запросы |
Деятельность клиентской службы Деятельность отдела продаж Деятельность сервисного центра |
|
Данные о клиентах |
Деятельность клиентской службы Деятельность отдела продаж Деятельность сервисного центра |
Оперативные процессы или в рамках функционального моделирования называются работы (или алгоритмы). В ходе исследования предметной области были выделены следующие оперативные процессы
Таблица 2.7. – Характеристика оперативных процессов
|
Оперативный процесс |
Старший Процесс |
|
Деятельность клиентской службы |
Деятельность салона магазина |
|
Деятельность отдела продаж |
Деятельность салона магазина |
|
Деятельность сервисного центра |
Деятельность салона магазина |
|
Отчетность |
Деятельность салона магазина |
|
Обработка заявки |
Деятельность клиентской службы |
|
Занесение информации в базу данных |
Деятельность клиентской службы |
|
Прием товара |
Деятельность отдела продаж |
|
Консультации клиентов |
Деятельность отдела продаж |
|
Продажа товара |
Деятельность отдела продаж |
|
Составление отчета по продажам |
Деятельность отдела продаж |
|
Прием заявок |
Деятельность сервисного центра |
|
Исполнение заявки |
Деятельность сервисного центра |
|
Составление отчета по клиентским заявкам |
Деятельность сервисного центра |
При этом глобальный процесс «Отчетность» будет являться общим хранилищем данных об отчетах, реализуемых подпроцессами контекста «Деятельность салона-магазина «Континент»»
2.3. Характеристика результатной информации
Результативной информацией будут выходы бизнес процессов которые определенны в модельной части.
Таблица 2.8. – Характеристика выходной информации бизнес-процессов
|
Выход |
Процесс |
|
Информация о ценах |
Деятельность отдела продаж |
|
Информация о тарифах и скидках |
Деятельность отдела продаж Деятельность сервисного центра |
|
Товарные чеки |
Деятельность клиентской службы Деятельность отдела продаж Деятельность сервисного центра |
|
Отчеты |
Отчетность |
2.4. Общие положения (дерево функций и сценарий диалога)
Поскольку сутью темы настоящей работы является учет пользовательских заказов, определим функции, которые будет выполнять проектируемая информационная система:
Таблица 2.9. – Функции проектируемой АИС
|
Основные |
Служебные функции |
|
Ввод информации по заказам Ведение журналов Ввод справочной информации Формирование сводной информации |
Связь с базой данных (БД) Авторизация |
Представим перечисленные функции деревом функций:
Рисунок 2.2. Дерево функций АИС
Теперь построим сценарий диалога пользователя. Обычно диалоги пользователя основаны на заполнении полей стандартных, например журнальных форм. Таким образом, входные и выходные данные помещаются хранилища (базы) данных. Для проектируемой АИС предлагается такой сценарий диалога пользователя:
Рисунок 2.3. Сценарий диалога пользователя
2.5. Характеристика базы данных
Прежде чем строить структуру базы данных, необходимо определиться с выбором СУБД. Здесь используются следующие критерии:
- максимальное количество пользователей;
- поддерживаемый объем базы данных;
- поддержка наличия в базе данных таких объектов, как хранимые процедуры, представления и т.п.;
- требовательность к ресурсам;
- технологии, поддерживаемые данной СУБД, для доступа к данным.
Системы управления базами данных (СУБД) – это программные средства, предназначенные для создания, наполнения, обновления и удаления баз данных. СУБД дают возможность пользователям осуществлять непосредственное управление данными, а программистам быстро разрабатывать более совершенные программные средства их обработки. Характеристики готовых прикладных пакетов определяются, прежде всего, принятой в СУБД организацией данных и типом используемого транслятора.
В настоящее время разработчики программного обеспечения ориентируются, прежде всего, на сетевые решения, основанные на платформе «клиент-сервер», ввиду их явных преимуществ по сравнению с локальными решениями.
Локальные СУБД обладают, как правило, следующими недостатками:
- снижение производительности в многопользовательском режиме работы при одновременном редактировании данных;
- большой сетевой трафик;
- отсутствие эффективных средств проведения согласованных изменений данных;
- слабый уровень защиты информации.
Из коммерческих продуктов, основанных на «клиент-серверной» платформе наиболее распространенными и эффективными являются Oracle и Microsoft SQL Server, отличающиеся высокой производительностью и масштабируемостью. Однако данные продукты имеют достаточно высокую цену, и их применение не оправдано для потребностей компании «Континент».
Сложилось такое мнение: «чтобы ощутить всю мощь Oracle база данных должна иметь более 10 тысяч записей».
Microsoft Access – это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Система управления базами данных предоставляет возможность контролировать задание структуры и описание своих данных, работу с ними и организацию коллективного пользования этой информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение данных, обработка данных и управление данными. Все эти функциональные возможности в полной мере реализованы в Microsoft Access.
Так как Microsoft Access является современным приложением Windows, можно использовать все возможности DDE и ОLЕ. DDE позволяет динамично осуществлять обмен данными между Access и любым другим поддерживающим DDE приложениями. В Access можно при помощи макросов осуществлять динамический обмен данными с другими приложениями. OLE является более изощренным средством Windows, которое позволяет установить связь с объектами другого приложения или внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть картинки, диаграммы, электронные таблицы или документы из других поддерживающих ОLЕ приложений Windows.
Microsoft Access, обладая всеми чертами классической СУБД, предоставляет и дополнительные возможности. Access – это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки работающих с базами данных приложений. С помощью Access можно создать приложение, работающее в среде Windows и полностью соответствующее вашим потребностям по управлению данными. Используя запросы, есть возможность выбирать и обрабатывать хранящуюся в таблицах информацию. Можно создавать формы для ввода, просмотра и обновления данных, а также использовать Access для создания как простых, так и сложных отчетов.
Мной принято решение использовать именно СУБД Microsoft Access. Во первых, исследуемое предприятие сравнительно небольшое, а если руководство сочтет необходимым дальнейшее развитие этой темы, то можно будет распространить разработку на клиент серверное приложение. Однако, поскольку, на мой взгляд рамок Microsoft Access не достаточно для создания полноценно и гибкого интерфейса для приложений. Я решила программную оболочку создать в среде разработки Delphi 7 с использованием технологии ADO. Это своего рода комбинированный подход, позволяющий разделить СУБД и интерфейсное приложение. Для баз данных сравнительно небольшого объема такой подход оказывается достаточно эффективным. Тем более, что приложения разработанные с использованием среды Delphi имеют меньший по сравнению с другими средами объем исполняемых файлов, а сама среда имеет быстрый компилятор. Это два основных достоинства среды разработки Delphi.
2.6. Структурная схема пакета (дерево вызова программных модулей)
Рисунок 2.4. Дерево вызова программных модулей
2.7 Описание программных модулей
Модуль сеанса предназначен для реализации функций сеансового уровня базовой эталонной модели взаимодействия открытых систем OSI. В модуле внешнего соединения реализованы функции транспортного, сетевого и канального уровней OSI. Далее, поскольку разработка приложения предполагается в среде разработки Delphi, как уже отмечалось, следует учесть, что среда имеет так называемую блочно-модульную структуру разработки, а это означает, что каждый фрагмент кода реализуется либо в виде отдельного модуля, либо в составе другого модуля. У нас глобальный модуль также будет реализован в виде модуля главной формы приложения, которую традиционно называют MainForm и из нее осуществляется вызов всех функциональных модулей. Такой подход не обязателен, но является общепринятым и модным, поэтому также будем его придерживаться при разработке. Остальные модули, которые представлены в дереве также будут реализованы в виде отдельных форм, то есть файлов типа *.pas. В модулях справочников будет реализовано обращение к сущностям, ранее объявленных, как справочные. Это справочники, должностей, улиц и т. п. Назначение остальных модулей понятно из названия.