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

Диаграмма последовательности

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

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (линии жизни), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места, так как при большом количестве объектов значительно растянута по горизонтали.

На рис. 6. изображена диаграмма последовательностей для прецедента просмотра продукта (расширение прецедента просмотра каталога).

Опишем, что на ней изображено. Пользователь с помощью клиента, в качестве которого выступает веб-браузер, переходит по ссылке на продукт, его браузер выполняет HTTP запрос типа GET. Обработчик URL адресов Django проверяет, что ссылка соответствует регулярному выражению, указанному в конфигурационном файле (urls.py). Если ссылка удовлетворяет заданному шаблону, обработчик URL вызывает функцию представления, передавая в качестве параметров имя представления и словарь GET запроса. В функции представления совершается запрос к классу модели на выборку продукта с id указанным в URL. На выходе генерируется словарь (тип данных языка python) содержащий данные о запрашиваемом продукте. Далее в функции представления осуществляется операция визуализации (render) шаблона и пользователь получает ответ от сайта в виде страницы с продуктом.

На рис. 7. изображена диаграмма последовательностей для прецедента «Оформление заказа».

Рисунок 6 – Диаграмма последовательностей для прецедента “Просмотр продукта”

Покупатель после того как он сформировал виртуальную корзину нажимает на кнопку оформить заказ, веб-браузер отправляет HTTP запрос типа POST, содержащий данные о том какие товары находятся в корзине и их количество. После обработки запроса контроллером и обработчиком URL функция представления вызывает метод makeCheckout экземпляра класса Checkout (обработчик платежей). Экземпляр класса обработчика платежей вызывает метод createOrder класса Order (заказ). Затем этот класс вызывает метод класса OrderItem (отдельный экземпляр содержащийся в заказе) в который добавляются данные для каждого продукта содержащегося в виртуальной корзине (id продукта, количество, цена и id экземпляра класса Order), после того как все экземпляры класса созданы, класс Order вычисляет сумму заказа. Затем класс Order возвращает пользователю страницу предварительного просмотра заказа, после того как пользователь нажимает кнопку подтвердить вызывается метод makeCheckoutPayment, класс Checkout еще раз запрашивает данные заказа у класса Order, затем вызывается метод makePayment который создает класс Payment System API взаимодействующий с платежной системой. Далее этот класс возвращает результат оплаты классу обработчику платежей. Если платежная транзакция завершена успешно, то статус заказа меняется на “оплачен” (с этого момента в отделе доставки начинают формировать посылку для отправления). Пользователю возвращается страница с информацией об успешной оплате заказа.

---

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

Диаграмма состояний

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

Также зачастую диаграмма состояний используется аналитиками для описания последовательности переходов объекта из одного состояния в другое. 

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

Рисунок 8 – Проверка заказа

Рисунок 9 – Диаграмма состояний заказа

Рисунок 10 – Ожидание проверки заказа

Рисунок 11 – Подтверждение заказа

Диаграмма деятельности

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

Если варианты использования ставят перед Системой цель, то диаграмма  деятельности показывает последовательность действий, необходимых для ее достижения.  Действия (action) это элементарные шаги, которые не предполагают дальнейшую декомпозицию.    

Рисунок 12 – Диаграмма деятельности для оформления заказа

Рисунок 13 – Диаграмма деятельности для оформления доставки

Диаграмма классов

На рис. 14 приведена концептуальная диаграмма классов, основанная на анализе предметной области. Она описывает структуру системы, показывая её классы, их атрибуты и методы, а также отношения между классами (их тип и кратность).

Основные типы связи:

• Обобщение – показывает, что один класс является частной формой другого, то есть отношение часть-целое. Обычно такой связью показывают наследование классов. Графически обобщение представляется линией с пустым треугольником у родительского класса.
• Ассоциация – указывает на то, что объекты одного класса связаны с объектами другого класса. Графически представляется как линия связывающая классы, для именованной ассоциации указывается кратность отношения и её имя. Также помимо кратности иногда указывают роли каждого из взаимодействующих объектов.
• Агрегация – отношение целого и его части. Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём по умолчанию, агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое – нет. Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу.
• Композиция – отношение целого и неотъемлемой его части. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется как агрегация, но с закрашенным ромбиком.

---

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

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

Рисунок 14 – Концептуальная диаграмма классов

Экземпляры класса отзыв не могут существовать без продукта, к которому отзыв был оставлен, поэтому тип связи композиция.

Классы “Типы характеристик” и “Статусы заказа” словарные, в программном продукте будут использоваться в соответствии с шаблоном проектирования “Одиночка”, то есть во время работы приложения будет существовать единственный экземпляр каждого из этих классов. Класс “типы характеристик” будет хранить только названия характеристик, например: ширина, тип, размер, вес, цвет и т.д. Класс “Статусы заказа” хранит возможные статусы заказа, например: отправлен, обрабатывается, получен и т.д. На диаграмме представлены как перечисления.

Заключение

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

Работа состоит из введения, аналитической и практической части, заключения.

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

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

Для интернет-магазина приводятся диаграммы последовательности, деятельности, состояний, классов. При проектировании было использовано следующее программное обеспечение: средства построения UML диаграмм Enterprise Architect и AllFusion Process Modeler BPWin .

Список использованной литературы

1. Маклаков С.В. Создание информационных систем с ALLFusionModelingSuite 2003 / С.В. Маклаков – Москва.: ДИАЛОГ МИФИ – Москва, 2003. – 432 с.
2. Ларман К. Применение UML 2.0 и шаблонов проектирования / К. Ларман: пер. с англ. – Москва.: ООО «И. Д. Вильямс», 2007. – 736 с.
3. Буч Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, А. Джекобсон: пер. с англ. – Москва.: ДМК, 2000. – 432 с.
4. Вендоров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: учеб. Пособие / А.М. Вендоров – Москва.:Финансы и статистика, 2002. – 192 с.
5. Проскурин Д.К. Проектирование информационных систем: учеб. Пособие / Д.К. Проскурин, М.В. Шитикова – Воронеж.: Государственный архитектурно- строительный университет – Воронеж, 2003. – 198 с.
6. Django. Разработка веб-приложений на Python / Д. Форсье [и др.].; пер. с англ.– СПб. : Символ-Плюс, 2010. – 456 с.
7. Django. Подробное руководство. 2-е издание / А. Головатый, Д. Каплан-Мосс.; пер. с англ.– СПб. : Символ-Плюс, 2010. – 560 с.
8. Dive into Python / Mark Pilgrim.; United States, New York.: Apress, 2010. – 495 с.
9. Beginning Django E-Commerce / Jim McGaw.; United States, New York.: Apress, 2009. – 409 с.
10. Django 1.2 E-Commerce / Jesse Legg.; England, Birmingham.: PACKT Publishing, 2010. – 244 с.
11. Django 1.1 Testing and Debugging / Karen M. Tracey.; England, Birmingham.: PACKT Publishing, 2010. – 436 с.
12. Лутс М. Изучаем Python. 4-е издание / М. Лутс.; пер. с англ.– СПб. : Символ-Плюс, 2011. – 1280 с.
13. Фаулер. М. Архитектура корпоративных программных приложений / М. Фаулер.; пер. с англ.– М. : Издательский дом Вильямс, 2006. – 544 с.
14. Флэнаган Д. JavaScript. Подробное руководство, 5-е издание / Д. Флэнаган.; пер. с англ.– СПб. : Символ-Плюс, 2008. – 992 с.
15. Мартин Р. Чистый код. Создание, анализ и рефакторинг / Р. Мартин.; пер. с англ. Библиотека программиста – СПб. : Питер, 2010. – 464 с.
16. Макконелл С. Совершенный код. Мастер класс / С. Макконелл.; пер. с англ. Издательско-торговый дом «Русская Редакция» – СПб. : Питер, 2005. – 896 с.

---