Концептуальная модель информационной системы

Оглавление

 

Введение 3

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

2. Концептуальная модель информационной системы 7

      2.1 Глоссарий проекта………………………………………………………..7

      2.2 Описание нефункциональных требований……………………………..8

      2.3 Функциональные требования……………………………………………8

3. Логическая модель информационной системы 21

Заключение 31

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

 

 

 

Введение

Объектом исследования данного  курсового проекта является склад  оптовой торговли.

Что такое оптовая торговля? Мы с вами считаем оптовиками торгово-распределительные  фирмы, но ведь с этой точки зрения оптовой торговлей занимается и мелкая розничная пекарня, продающая свои булочки, пирожные и торты местному отелю.

Оптовая торговля включает в  себя любую деятельность по продаже  товаров или услуг тем, кто  приобретает их с целью перепродажи  или профессионального использования.

Задачи проектирования информационной системы оптовой торговли включают:

1. описание предметной области;
2. разработку концептуальной и логической модели информационной системы;
3. реализацию моделей в среде CASE-средства StarUML.

В результате разработки должна быть построена информационная система, позволяющая организации выполнять бизнес-процессы. Внедрение системы позволит:

1. оперативно учитывать местонахождение товара;
2. автоматически формировать отчетные документы;
3. решить проблемы ежедневного ручного подсчета реальных продаж, такие как: необходимость обработки большого количества данных о продажах, большие временные затраты;
4. минимизировать ошибки «человеческого фактора».

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

Глава «Концептуальная модель информационной системы» включает глоссарий проекта, нефункциональные требования и функциональные требования к системе в виде диаграмм вариантов использования. Также описаны сценарии вариантов использования и построены диаграммы последовательности.

Глава «Логическая модель информационной системы» содержит иерархию классов системы. Также в данной главе осуществляется отображение элементов полученных моделей классов в элементы моделей базы данных.

Завершается глава разработкой  диаграммы размещения, на которой  отображается расположение компонентов  в распределенном приложении.

 

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

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

Процесс обработки заказа включает следующие этапы:

1. прием заказа;
2. подтверждение заказа;
3. комплектация заказа;
4. доставка заказа;
5. учет продажи.

При доставке товара покупателю предоставляется экземпляр накладной  и чек по оплате заказа. Также  печатается счет-фактура и счет в  случае оплаты безналичным платежом.

Заказы доставляются курьерами, транспортными компаниями и почтой России в случае доставки в регионы России.

Заказ может находиться в  нескольких состояниях (возможно в нескольких состояниях одновременно):

1. принят к обработке;
2. укомплектован (на складе есть весь товар по заказу);
3. ожидает комплектации (на складе нет всех товаров по заказу);
4. готов к отправке;
5. в пути (у курьера, в транспортной компании);
6. оплачен;
7. доставлен.

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

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

 

2. Концептуальная модель информационной системы

2.1 Глоссарий проекта

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

Склад — помещение, комплекс помещений, предназначенный для  хранения материальных ценностей.

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

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

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

Отчет – документ, отражающий информацию по продажам и закупкам за период времени, информацию о работе курьеров, о текущем местонахождении товаров.

Служба доставки – служба доставки заказа. Покупатель может  выбрать курьерскую службу доставки, доставку транспортными компаниями либо доставку почтой России.

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

Статус заказа – состояние, в котором находится заказ.

2.2 Описание нефункциональных требований

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

Разрабатываемая система должна обеспечивать многопользовательский режим работы. Пользовательский интерфейс должен быть Windows–coвместимым, а также должен быть простым и не требующим дополнительного обучения для пользователей, обладающих компьютерной грамотностью.

Только группа пользователей  «Администраторы» должна иметь доступ к административной панели управления. Пользователи системы должны проходить авторизацию в системе перед началом работы.

Система должна взаимодействовать  с существующей банковской системой и с системой электронных платежей.

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

2.3 Функциональные требования

Пользователи системы должны делиться на ролевые группы:

1. главный механик;
2. комендант;
3. покупатель.

Главный механик должен обрабатывать поступающие заказы (добавлять заказы в БД, формировать документы, укомплектовать заказы), отслеживать доставку заказов, отслеживать оплату заказов покупателями.

Комендант должен заключать договора с поставщиками, добавлять поставщиков в БД, добавлять товар в БД, планировать закупки.

Функциональные требования в проекте описаны в виде диаграмм прецедентов.

Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования  динамических аспектов системы.

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

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

Диаграммы прецедентов имеют  большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают  понимание систем, подсистем или  классов, представляя взгляд извне  на то, как данные элементы могут  быть использованы в соответствующем  контексте.

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

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

1. Клиент (супертип) – интересуется наличием товаров.
2. Покупатель (подтип) – покупатель склада. Проходит проверку документов, делает, получает и оплачивает заказ.
3. Комендант (подтип) – планирует закупки, заключает договора с поставщиками, принимает товар.
4. Главный механик (подтип) – принимает заказы, комплектует заказы, формирует документы, отправляет заказы.
5. Система электронных платежей – система безналичных расчетов, через которую можно оплатить заказ.

Общую модель деятельности системы  можно представить в виде следующих диаграмм прецедентов:

1. Общая диаграмма прецедентов работы склада (Рис. 1);
2. Диаграмма прецедентов для действующего лица «Покупатель» (Рис. 2);
3. Диаграмма прецедентов для варианта использования «Обработать заказ» (Рис. 3)

              

Рис. 1

Рис. 2

Рис. 3

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

Дальнейшее проектирование системы заключается в разработке сценариев вариантов использования.

Сценарии вариантов использования – в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы.

Вариант использования “Сформировать  отчет”

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

 

Вариант использования «Принять заказ»

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

Вариант использования «Укомплектовать  заказ»

Описание	Данный вариант использования  описывает процесс комплектации заказа менеджером по продажам.
Основной сценарий	Вариант использования начинает выполняться, когда менеджер по продажам комплектует  заказ. Главный механик выделяет заказ и выбирает пункт меню «Укомплектовать». Система отмечает товар как укомплектованный. Система изменяет статус заказа на «Укомплектован». Система отправляет письмо покупателю об изменении статуса заказа.
Постусловие	Отправить заказ.