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

Оглавление

 

Введение 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

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

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

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

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

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

 

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

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

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

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

 

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

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

 

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

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

 

Вариант использования «Добавить  поставщика в БД»

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

 

 

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

Описание

Вариант использования описывает  процесс заказа товара менеджером по закупкам.

Основной сценарий

Вариант использования начинает выполняться, когда менеджер по закупкам хочет  заказать товар. Комендант выбирает в меню пункт «Сделать заказ». Система отображает экранную форму «Сделать заказ». Система проверяет обновления прайс-листов поставщиков. Если есть обновление, то прайс-лист обновляется. Система отображает сводный прайс-лист. Система отмечает в сводном прайс-листе товары, которые заказали покупатели, но которых нет в наличии. Комендант отмечает товары, которые хочет заказать. Комендант выбирает в меню пункт «Отправить заказ». Система отправляет заказ поставщикам по электронной почте.

 

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

Описание	Вариант использования описывает  процесс принятия товара менеджером по закупкам.
Основной сценарий	Основной поток: вариант использования  начинает выполняться, когда менеджер хочет принять товар. Комендант загружает накладную в систему; Система сохраняет товар в БД. Менеджер устанавливает наценку. Система сохраняет изменения.

 

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

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

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

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

Диаграммы последовательности для вариантов использования действующего лица «Заведующий складом»:

«Сформировать отчет» (Рис. 4).

Рис. 4

Диаграммы последовательности для вариантов использования действующего лица «Главный механик»:

1. «Принять заказ» (Рис. 5);
2. «Укомплектовать заказ» (Рис. 6);
3. «Принять оплату» (Рис. 7);
4. «Отправить заказ» (Рис. 8);

Рис.5

Рис.6

Рис.7

Рис.8

Диаграммы последовательности для вариантов использования действующего лица «Комендант»:

1. «Добавить поставщика в БД» (Рис. 9);
2. «Заказать товар» (Рис. 10);
3. «Принять товар» (Рис. 11).

                                                        Рис.9

                Рис.10

                 Рис.11

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

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

Логическое представление  содержит:

1. классы, являющиеся основными элементами архитектуры системы;
2. диаграммы классов, используемые для представления классов, их атрибутов, операций и связей. Как правило, для описания системы применяется несколько диаграмм классов, каждая из которых отображает некоторое подмножество всех классов системы;
3. диаграммы взаимодействия, применяемые для отображения объектов, участвующих в сценарии варианта использования или в реализации некоторой системной операции;
4. диаграммы состояний, описывающие динамику поведения объектов некоторого класса;
5. пакеты, содержащие группы взаимосвязанных классов. Типичная система может содержать сотню классов или больше, и объединение их в пакеты снижает сложность модели.

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

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

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

Классы-сущности (Entity):

1. Заведующий складом;
2. Главный механик;
3. Комендант.

Граничные классы (Boundary):

1. Принтер;
2. Административная панель;
3. Система электронных платежей.

Управляющие классы (Control):

1. Менеджер БД;
2. Менеджер закупок;
3. Менеджер обработки заказов;
4. Менеджер отчетов;
5. Клиент.

Класс «Заведующий складом» является супер-классом и объединяет два подкласса: «Главный механик» и «Комендант». Следовательно, подклассы «Главный механик» и «Комендант» наследуют атрибуты класса «Заведующий складом» (Рис. 12).

Рис.12

 

У класса «Заведующий складом» есть следующие атрибуты:

1. ФИО – фамилия, имя и отчество заведующего складом;
2. Табельный номер – уникальный идентификационный номер;
3. Домашний адрес;
4. Контактный телефон.

Граничные классы:

1. «Административная панель» (Рис. 13);

Рис. 13

2. «Принтер» (Рис. 14);

Рис. 14

3. «Система электронных платежей» (Рис. 15):

Рис. 15

         Управляющие классы:

1. «Менеджер БД» (Рис. 16):

Рис. 16

2. «Менеджер закупок» (Рис. 17):

Рис. 17

3. «Менеджер обработки заказа» (Рис. 18):

Рис. 18

4. «Клиент» (Рис. 19);

Рис. 19

5. «Менеджер отчетов» (Рис. 20):

Рис. 20

 

 

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

Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. При этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т. е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.

 

 

 

 

 

 

 

 

«Сформировать отчет»

Рис. 21

«Принять заказ»

                 Рис. 22

 

«Укомплектовать заказ»

Рис. 23

«Отправить заказ»

Рис. 24

 

«Принять оплату»

Рис. 25

«Добавить поставщика в БД»

 Рис. 26

 

«Заказать товар»

Рис. 27

«Принять товар»

Рис. 28

 

На основе построенных  классов–сущностей создан прототип модели БД, которая используется в  системе.

Для создания модели БД используется технология прототипного проектирования (RAD-технология), реализованная в СУБД Microsoft Access.

С помощью конструктора таблиц созданы таблицы базы данных и  определены их взаимосвязи (Рис. 29).

Рис. 29

       Физическое распределение готового приложения, включая размещение и топологию сети, а также локализацию в ней компонентов системы, отражает диаграмма размещения (Рис. 30).

Рис. 30

Заключение

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

Также были разработаны концептуальная и логическая модели информационной системы.

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

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

Для каждого варианта использования  построены диаграммы классов.

Все диаграммы выполнены  в среде CASE-средства StarUML.

Также была построена модель БД, которая отражает схему хранения информации в БД и связи между объектами. Модель построена с помощью средства Microsoft Access пакета Microsoft Office.

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

Результаты проектирования могут являться основой для создания информационной системы складов.

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

 

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

1. Вендров, А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб.пособ. / А.М.Вендров. – М.:Финансы и стат., 2004.-192с.

2. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем: Учеб. / А.М. Вендров. – М.: Финансы и стат., 2003.- 352с.