Файл: Моделирование предметной области «учет продаж» с помощью UML (Анализ функциональной модели).pdf

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

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

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

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

Рисунок 3 – Диаграмма декомпозиции «Закупка товаров»

Далее продолжим декомпозицию диаграммы «Организовать работу интернет-магазина», произведем дальнейшее разбиение на подсистемы процесса «Хранение» и построим соответствующую функциональную диаграмму (рис. 4)

Рисунок 4 – Диаграмма декомпозиции «Хранение»

Опишем процессы, представленные на данной диаграмме декомпозиции.

Получить товар – кладовщик получает закупленные у поставщиков товары.

Отсортировать товар – сотрудник склада сортирует товар и передает список товаров, которые есть на складе, системному администратору.

Обеспечить хранение – сотрудники склада осуществляют контроль над хранением товара.

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

Теперь произведем разбиение на подсистемы процесса «Продажа» и рассмотрим диаграмму декомпозиции этого процесса.

Опишем процессы, представленные на диаграмме декомпозиции процесса «Продажа» (рис. 5).

Рисунок 5 – Диаграмма декомпозиции «Продажа»

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

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

---

Отследить получение посылки – часто случается, что товар может затеряться во время доставки, поэтому нужно отслеживать состояние посылки до момента ее вручения адресату.

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

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

1.2.2. Анализ функциональной модели

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

Оформление заказа клиентом – чтобы оформить заказ клиент должен будет зарегистрировать аккаунт на веб-сайте, в процессе регистрации он вводит свои данные, такие как: адрес доставки, контактный e-mail адрес, фамилию, имя и другое. Просматривая каталог товаров на веб-сайте, клиент начинает оформлять заказ. Выбрав товары, которые клиент хочет приобрести, он кликает на кнопку “Добавить в корзину”, после выбора всех необходимых товаров клиент нажимает кнопку “Оформить заказ”, выбирает на следующей диалоговой странице способ доставки и способ оплаты. Когда заказ оформлен, система автоматически посылает данные о сделанном заказе по электронной почте в почтовый отдел, сотрудники которого после получения письма должны сформировать посылку по данным заказа и сделать почтовое отправление.

Отслеживание посылки – когда сотрудник почтового отдела отправляет заказ, он заносит номер для отслеживания посылки в данные оформленного заказа. Клиент сможет отслеживать местоположение отправленного ему товара по уникальному почтовому идентификатору посылки (распространенно сокращение трек-номер посылки).

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

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

---

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

Отмечу, что эта концептуальная диаграмма будет существенно отличаться от окончательной диаграммы программных классов системы, так как в данном разделе построение диаграмм классов мною рассматривается с точки зрения концептуального аспекта. Концептуальный аспект – диаграммы классов отображают понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как не зависимую от средств реализации (языка программирования). Концептуальную модель программных классов в следующем разделе будет рассматриваться в аспектах спецификаций и реализаций. Аспект спецификации – модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне). Аспект реализации – модель действительно определяет реализацию классов программного продукта. Этот аспект наиболее важен для программистов.

Опишем, как происходит обработка платежа через платежную систему. Типичный вариант использования: пользователь, после оформления заказа, кликает на кнопку оплаты и перенаправляется на сайт платежной системы (при этом, в ссылке передается маркер безопасности будущей транзакции и идентификатор получателя платежа), где он непосредственно осуществляет платеж. Если платежная транзакция завершается успешно, то, как правило, система возвращает ответ в виде специально сформированного xml файла, который содержит результат транзакции и другие сведения, необходимые для идентификации состояния платежа виртуальным магазином. Подключение систем оплаты сводится к созданию модуля осуществляющего синтаксический анализ структуры xml файла возвращенного платежной системой после проведения транзакции.

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

Моделирование предметной области

Диаграмма вариантов использования

---

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

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

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

Сценарии прецедента выделяют в отдельные прецеденты, связанные отношением включает (include), при выполнении следующих условий:

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

Взаимосвязь расширяет (extend) предоставляет дополнительную возможность в том случае, когда основной прецедент нельзя модифицировать. Основная идея заключается в создании расширяющего или дополнительного прецедента, в котором описывается, где и при каких условиях он расширяет некоторый основной прецедент.

Рассмотрим диаграмму прецедентов “Интернет-магазин”, которая приведена на рис.5.

Рисунок 5 – Диаграмма прецедентов “Интернет-магазин”

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

Основные прецеденты включают в себя:

• Управление аккаунтом. Он расширяется прецедентами “Авторизация” – процесс прохождения авторизации на сайте, “Регистрация” – регистрация клиента на сайте, ”Управление аккаунтом” – редактирование профиля пользователя, это может быть изменение личных данных, пароля доступа, адреса доставки и другое.
• Просмотр каталога – просмотр клиентом магазина товаров доступных в продаже. Прецедент связан отношением расширения с прецедентами “Получить консультацию” – связаться с менеджером и узнать дополнительную информацию о продукте, “Оценить продукт” – возможность поставить оценку просматриваемому продукту, “Оставить отзыв” – возможность оставить комментарий к продукту и “Искать продукт” – возможность поиска продукта по ассортименту магазина.
• Оформление заказа. Этот прецедент включает в себя прецеденты “Добавление товара в корзину” (тип связи “include”), “Оплатить” – непосредственно проведение транзакции через платежную систему и “Управлять корзиной” – возможность просмотра товаров находящихся в корзине и управление ими (изменение количества, удаление конкретного товара из корзины).
• Консультировать клиента. Клиент может получать консультации как на веб-сайте, так и с помощью систем обратной связи, например форма обратной связи, консультации через системы мгновенного обмена сообщениями и т.д. Консультацию осуществляет менеджер.
• Управление каталогом. Менеджер может управлять каталогом, добавлять новые категории товаров, новые товары, управлять информацией о товарах, редактировать их описание и другое.
• Обработать заказ. Менеджер управляет статусом заказа и указывает номер почтового отправления. В случае если клиент хочет что-либо изменить в заказе, менеджер может это сделать в интерфейсе управления заказами.
• Администрирование сайта. Веб-сайт нуждается в постоянном администрировании, так как малейший простой в случае сбоя может негативно сказаться на рейтинге магазина. Прецедент включает в себя добавление новостей на сайт, управление аккаунтами пользователей и сотрудников магазина.

---

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

Реальный прецедент описывает конкретное проектное решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов.

Таблица 1

Описание прецедента регистрации пользователя

Название прецедента	Зарегистрироваться
Исполнитель	Клиент
Цель	Пройти процедуру регистрации на сайте
Основной успешный сценарий	Клиент переходит на веб-сайт магазина. Кликает кнопку зарегистрироваться. Вводит данные в регистрационную форму и нажимает кнопку отправить данные. На указанный адрес электронной почты поступает письмо содержащее информацию о регистрационных данных
Тип	Идеальный
Ссылки	Добавление нового пользователя, Авторизация, Отправка письма

Таблица 2

Описание прецедента регистрации пользователя

Название прецедента	Управление аккаунтом
Исполнитель	Клиент
Цель	Изменить данные профиля
Основной успешный сценарий	Клиент переходит на веб-сайт магазина, регистрируется. Осуществляет процедуру авторизации на сайте. Управляет данными в своем профиле. Система, взаимодействуя с БД, осуществляет изменение данных пользователя
Тип	Идеальный
Ссылки	Отправить на email уведомление о успешном изменении пароля, изменение данных пользователя в БД

Таблица 3

Описание прецедента Оформление заказа

Название прецедента	Оформление заказа
Исполнитель	Клиент
Цель	Оформить заказ
Основной успешный сценарий	Выбрать товары, которые нужно приобрести, нажать напротив товаров кнопку “добавить в корзину”. Повторять действия до тех пор, пока не будет укомплектован заказ. Затем нажать кнопку “Оформить заказ”. Пройти процедуру оплаты.
Тип	Идеальный
Ссылки	Обновить корзину, Авторизация платежа, Отправка данных о оплаченном заказе на email клиента и в почтовый отдел

---