Файл: Моделирование предметной области «Учет продаж» с помощью UML (Основные понятия объектно-ориентированного подхода).pdf

2. ПОСТРОЕНИЕ ОБЪЕКТНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ «УЧЕТ ПРОДАЖ» С ПРИМЕНЕНИЕМ ЯЗЫКА МОДЕЛИРОВАНИЯ UML

2.1. Описание функционирования предметной области «Учет продаж»

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

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

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

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

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

2.2. Построение диаграммы модели информационной системы оптовой базы

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

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

Поставщик (предприятие) – человек, который занимается доставкой товаров и продуктов.

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

Теперь необходимо создать в ModelMaker главную диаграмму модели и диаграммы действующих лиц (рис. 1).

Рисунок 1 – Перечень действующих лиц в главной диаграмме модели

Следующий этап – составление списка вариантов использования.

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

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

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

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

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

– Принять заказа покупателя. Администратор утверждает принятие заказа поставщика, система рассылает прайсы покупателям.

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

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

– Сформировать отчет за определенные периоды времени о работе.

– Сформировать отчет по списку оптовых покупателей.

– Сформировать отчет по заявкам на товары.

– Сформировать отчет по анализам продаж.

Все варианты использования нужно добавить в главную диаграмму модели. Результат представлен на рисунке 2.

Рисунок 2 – Список вариантов использования информационной системы оптовой базы

2.3. Диаграмма вариантов использования информационной системы оптовой базы

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

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

Рисунок 3 – Диаграмма вариантов использования информационной системы оптовой базы

Далее следует детальное описание вариантов использования, которые в большей степени раскрывают работу данной информационной системы оптовой базы:

– Заполнить форму заявки на покупку.

– Внести данные о продавце и товара.

– Сформировать отчет по заявкам на товары.

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

Краткое описание. Данный вариант использования описывает заполнение покупателем формы заявки на покупку товаров.

Основной поток событий

1. Открыть форму заявки на заполнение списка товаров.
2. Внести количество, наименование оптового продукта.
3. Выбрать предполагаемое срок доставки.
4. Сохранить изменения в системе.
5. Оповестить администратора о поступившей заявке (выполняется системой).

Предусловия

Перед заполнением формы покупатель должен войти в систему.

Постусловия

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

2.4. Архитектурный анализ информационной системы оптовой базы

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

Как правило, в потоках событий каждого варианта использования выявляются классы трех типов (Category):

Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой.

Классы-сущности (Entity) – представляют собой ключевые абстракции (понятия) создаваемой системы.

Управляющие классы (Control) – обеспечивают координацию объектов в системе.

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

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

Для реализации второго события «Внести количество и наименования продуктов» необходимо добавить в модель управляющий класс «ControllerRecord» (Контролер записей), который будет координировать запись данных в электронную базу. Поскольку система сохраняет данные о покупателе, содержащие список товаров, наименование товаров, контакты, выбранные категорию, можно выделить класс сущности «ListStudents» (Список покупателей) – таблица с данными о покупателях. Анализируя остальные события и рассуждая аналогичным образом, можно выявить остальные классы, которые необходимы для реализации основного потока событий рассматриваемого варианта использования. Результатом работы данного варианта использования будет созданная системой заявка, поскольку сами заявки не хранятся в системе, а только отправляются администратору для последующего анализа, нужно создать граничный класс: «Request» (Заявка). Далее приведен их полный перечень:

1. Граничный класс RequestForm – электронная форма заявки на продукт.
2. Граничный класс Request – заявка на продукт.
3. Управляющий класс ControllerRecordRequest – контролер записей персональных данных о покупателе в электронную базу.

Ниже приведены перечни классов для данных вариантов использования.

Перечень классов для варианта использования «Сформировать отчет по заявкам на товары»:

1. Граничный класс EAReportForm – электронная форма для формирования отчета: внесение данных о продуктах.
2. Управляющий класс ControllerEAReport – контролер событий.
3. Класс-сущность InternalExamResults – таблица с результатами заявок.

Далее нужно создать список классов в ModelMaker. Он представлен на рисунке 5.

Рисунок 5 – Перечень классов модели информационной системы оптовой базы

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни объекта. Она представляет собой фрагмент жизненного цикла объекта. Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов, оно помечается, как минимум, именем сообщения; можно показать самоделегирование.

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

Диаграмма последовательности «Заполнить форму заявки на товар»

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

TRequestForm – электронная форма заявки на товар, граничный класс (Boundary).

TRequest – заявка на товар, граничный класс (Boundary).

TControllerRecordRequest – контролер записей персональных данных о покупателе в электронную базу, управляющий класс (Control).

Действующее лицо – Покупатель.

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

От действующего лица «Покупатель» к граничному классу «TRequestForm» передается сообщение: 1. Запрос формы «Заявка».

От граничного класса «TRequestForm» к действующему лицу «Покупатель» передается сообщение: 2. Предоставление формы «Заявка».

От действующего лица «Покупатель» посылается сообщение самоделегирования: 3. Ввод персональных данных.

От действующего лица «Покупатель» к управляющему классу «TControllerRecordRequest» передается сообщение: 4. Сохранить изменения.

От управляющего класса «TControllerRecordRequest» посылается сообщение самоделегирования: 5. Сформировать заявку.

От управляющего класса «TControllerRecordRequest» к граничному классу TRequest посылается сообщение: 6.Отправить заявку.

От действующего лица «Покупатель» к граничному классу «TRequestForm» передается сообщение: 7.Закрытие формы «Заявка»

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 6.

Рисунок 6 – Диаграмма последовательности для варианта использования «Заполнить форму заявки на товар»

Диаграмма последовательности «Внести данные о назначенном поставщике»

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