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

 

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

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

 

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

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

 

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

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

 

 

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

Описание

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

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

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

 

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

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

 

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