Файл: Разработка проекта информационной системы для книжного магазина.pdf

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

2. Анализ предметной области и создание моделей

2.1. Функциональная модель книжного магазина

В целях осуществления функционального проектирования информационной системы задействуется CASE–средство AllFusion Process Modeller, которое поддерживает сразу несколько методологий: IDEF0, DFD и IDEF3.

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

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

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

Контекстная диаграмма и детализация процессов

Контекстная диаграмма "A-0" в иерархии диаграмм IDEF0 отражает наиболее высокий уровень абстракции. Контекст предполагает:

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

В рамках данной курсовой работы, контекстная диаграмма представляет собой схему управления книжным магазином (Рис. 2).

Управляющих потоков два – это «Законодательство» и «Регламенты и должностные инструкции». «Законодательство» подразумевает действующее законодательство РФ, которое влияет на деятельность книжного магазина. «Регламенты и должностные инструкции» - это правила корпоративной этики, полномочия и обязанности сотрудников, разработанные руководителями подразделений для своих непосредственных подчинённых.

Входные данные – «Финансовые ресурсы» (для оплаты закупаемого у поставщиков товара), «Продукция поставщика», «Запросы покупателей» (информация по потребностям от клиентов, включая жалобы с целью обмена/возврата).

Выходные потоки – это «Чеки о покупках» (как подтверждение результата осуществления продажи), «Проданная продукция» (полученные клиентами товары) и «Прибыль» (как реализация цели бизнеса).

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

Диаграммы бизнес-процессов:

Рассмотрим более подробно модель деятельности книжного магазина на диаграмме «A0» (Рис. 3). Здесь представлена её декомпозиция до четырёх ключевых процессов:

«Администрирование магазина» (процесс, являющийся источником частных управляющих воздействий для других процессов);
«Закупки» (взаимодействие с поставщиками);
«Хранение на складе» (управление запасами);
«Реализация» (взаимодействие с покупателями).

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

Также очевидна реализованность принципа ветвления, поскольку управляющие воздействия «Законодательство» и «Регламенты и должностные инструкции», а также механизмы «Персонал» и «ПО и оборудование» задействуются во всех указанных ранее процессах. В то же время, входные потоки «Запросы покупателей» и «Данные о покупателях» допустимы лишь в рамках процесса «Реализация». «Финансовые ресурсы» задействуются как в процессе «Закупки», так и в процессе «Администрирование магазина» (в частности, перечисление заработной платы сотрудникам книжного магазина).

Следуя бизнес-логике, разумно провести дальнейшую декомпозицию процессов «Хранение на складе» (Рис. 4) и «Реализации» (Рис. 5).

Так, «Хранение на складе» декомпозируется до следующих процессов:

«Приём товара»;
«Проверка качества»;
«Заведение в базу».

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

В свою очередь, процесс «Реализация» является более комплексным, и требует более детальной декомпозиции, учитывая способ покупки товаров через интернет-магазин. Так, декомпозиция процесса «Реализация» предполагает следующие процессы в рамках цели проекта:

«Продажа через интернет-магазин»,
«Консультация продавца»,
«Оплата на кассе».

Здесь также можно увидеть детализацию ветвления, но уже и на уровне управляющего воздействия «Регламенты и должностные инструкции» по отношению к процессу «Консультация продавца», предполагающую, с одной стороны, «План продаж», а с другой - «Стандарты продаж».

На уровне механизмов, детализация «Персонала» предполагает задействовать средства «Курьерская служба» и «Продавец-консультант» в процессе «Продажа через интернет-магазин», в то время как процессе «Консультация продавца» задействуется только «Продавец-консультант», а в процессе «Оплата на кассе» задействуется один лишь кассир. При этом детализация механизма «ПО и оборудование» предполагает задействовать средства «Касса и 1С» в процессе «Оплата на кассе», в процессе «Консультация продавца» — «Терминал для поиска продукции в базе данных», и «Веб-приложение интернет-магазина» в процессе «Продажа через интернет-магазин».

Теперь перейдем к более детальному анализу процесса «Продажа через интернет-магазин», предполагающему три вложенных процесса (Рис. 6):

«Добавление товаров в корзину»,
«Подтверждение заказа, регистрация, оплата» (для зарегистрированных клиентов — авторизация),
«Передача товаров покупателю».

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

Наконец, чтобы окончательно определиться с деталями передачи или доставки товаров клиенту при продаже товаров через интернет-магазин, проведём последнюю декомпозицию процесса «Передача товаров покупателю» (Рис. 7). Так, можно выделить три процесса:

«Самовывоз с пункта выдачи»,
«Почтовое отправление»,
«Курьерская доставка».

Соответственно, механизм «Курьерская доставка» задействуется только в процессе «Курьерская доставка». В остальном же, соблюдены всё те же правила, и каждый процесс соответствует методологии SADT.

2.2 ER-диаграмма потоков данных "сущность-связь"

Для ER-диаграммы необходимо составить подробное описание типов данных, в ней указаны таблицы, атрибуты таблиц, типы и размеры данных и описание атрибутов. Однако, данное описание с комментариями в форме таблицы было бы не доступным для восприятия, вследствие чего описание будет предложено списком. Во избежании ошибок при обращении к базе данных, всем сущностям ER-диаграммы потоков данных «сущность-связь» будут присвоены названия на латинице (Рис. 8). Значения количества допустимых символов будет указано выше среднего и далее может быть ограничено уже администратором информационной системы.

Для удобства же спецификации данных, они будут описаны далее в следующем формате:

%Entity1%

%Attribute1%: %Type%(%Format%), %Key%,

%Attribute2%: %Type%(%Format%), %Key%,

…

%AttributeN%: %Type%(%Format%), %Key%,

Где %Entity% - это сущность, %Attribute% - название поля атрибута, %Type% - тип данных, %Format% - формат/размер поля, %Key% - ключевое поля (первичный/вторичный ключ, или поле без ключа).

Формат и значения атрибутов:

Number – числовое поле,

String – текстовое поле,

Integer – целое число,

First key – первый ключ,

Second key – второй ключ.

“<N” - означает ограничение количества символов поля конкретным значением:

“=N” - означает соответствие количества символов поля конкретному значению.

Спецификация

Staff (персонал)

Для управления правами доступа сотрудников, а также для учёта личных продаж продавцов-консультантов, нельзя обойтись без сущности персонала. Здесь используются минимально необходимые атрибуты “Employee_ID” (идентификатор сотрудника), “Surname” (фамилия), “Name” (имя), “Patronomic” (отчество), “Position” (должность), “Department” (отдел).

Employee_ID: Number(Integer), first key

Surname: String(<86);

Name: String(<86);

Patronomic: String(<86);

Position: String(<20);

Department: String(<20).

Customers (покупатели)

Поскольку задействуются ресурсы интернет-магазина, то регистрация пользователей предполагает также минимально необходимый набор атрибутов. Здесь используются “Customer_ID” (идентификатор покупателя), “Surname” (фамилия), “Name” (имя), “Patronomic” (отчество), “Address” (адрес), “Phone” (телефон), “E-mail”.

Customer_ID: Number(Integer), first key;

Surname: String(<86);

Name: String(<86);

Patronomic: String(<86);

Address: String(<100);

Phone: String(<16);

E-mail: String(<255).

Publishing_outfit

В рамках поисковых запросов по наличию книг в магазине, крайне удобно обращаться к издательствам. Здесь используются “Publishing_outfit_ID” (идентификатор издательства), “Name” (название), “Address” (адрес), “Phone” (телефон).

Publishing_outfit_ID: Number(Integer), first key;

Name: String(<86);

Address: String(<256);

Phone: String(<17).

Suppliers (поставщики)

Является обязательной сущностью при ведении учёта закупок. Здесь используются “Supplier_ID” (идентификатор поставщика), “Organisation” (Наименование), “TIN” (ИНН), “IEC” (КПП), “BIC” (БИК), “Checking_account” (расчётный счёт), “Corresponding_account” (корреспондентский счёт), “Representative_full_name” (ФИО представителя), “Legal_address” (юридический адрес), “Phone” (телефон).

Supplier_ID: Number(Integer), first key;

Organisation: String(<20);

TIN: Number(Integer,=10/12);

IEC: Number(Integer,=12);

BIC: Number(Integer,=9);

Checking_account: Number(Integer,=20);

Corresponding_account: Number(Integer,=20);

Representative_full_name: String(<256);

Legal_address: String(<256);

Phone: String(<17).

Products (книги)

Поскольку в рамках работы, мы исходим из того, что вся продукция представляет собой книжные издания, то описание структуры базы данных сильно упрощается. В частности, появляется возможность использовать в качестве идентификатора товара (“Product_ID”) ISDN книги, и выделить общие атрибуты товаров, такие как “Title” (наименование) “Genre” (жанр), “Author” (автор), “Year_of_publication” (год публикации), и остальные: “Price” (цена), “Amount” (количество), и ключевые “Supplier_ID” (идентификатор поставщика) и “Publishing_outfit_ID” (идентификатор издательства).

Product_ID: String(Integer), first key;

Supplier_ID: Number(Integer), second key;

Publishing_outfit_ID: Number(Integer), second key

Title: String(<30);

Author: String(<256);

Genre: String(<20);