«Моделирование предметной области «Учет продаж» с помощью UML»

Содержание:

Введение

Электронная торговля в виртуальном магазине основывается на той же структуре, что и традиционная торговля. Преимущества виртуального магазина перед реальным очевидны. Уменьшается численность персонала за счет сокращения объема взаимодействия с клиентами, аренда оборудования или услуг виртуального-хостинга у хостинг провайдеров и размещение списка продаваемых товаров в виде каталога на сайте дешевле и проще аренды торговых помещений и размещения товаров на полках, нет нужды в кассовом обслуживании и так далее. Оплата товаров и услуг по доставке в виртуальных магазинах осуществляется с помощью различных платежных систем работающих в сети интернет. Их подключение к процессинговой системе проведения платежей осуществляется программистом при помощи интерфейсов программирования приложений (API – application programming interface) предоставляемых этими сервисами, примеры таких систем: «Paypal», «QIWI», «Merchant WebMoney Transfer», «Яндекс.Деньги» (перечисленные системы имеют возможность привязки кредитных карт к счету в системе), и другие системы.

Интернет-магазин называют также виртуальным магазином. К нему полностью подходит определение виртуального предприятия. Иначе говоря, виртуальный магазин – это сообщество территориально разобщенных сотрудников магазина (продавцов, кассиров, менеджеров-консультантов) и покупателей, которые могут общаться и обмениваться информацией через электронные средства связи при полном (или минимальном) отсутствии личного прямого контакта. Покупки через интернет – это процесс, при котором потребители непосредственно покупают товары или различного рода услуги через интернет, осуществляя оплату при помощи платежных систем или напрямую с банковской карточки. Консультирование может осуществляться с помощью систем: мгновенного обмена сообщениями, таких как ICQ, Skype и др., электронной почты, а также по телефону используя IP-телефонию и другие доступные средства связи.

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

Цель данной работы – проектирование информационной системы интернет-магазина.

Для достижения поставленной цели нужно выполнить ряд задач:

• провести детальный анализ предметной области;
• построить диаграмму вариантов использования;
• построить диаграммы последовательности;
• построить диаграмму состояний;
• построить диаграммы деятельности;
• построить диаграмму классов.

Глава 1  Описание предметной области

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

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

Оплата заказов клиентами осуществляется при помощи платежных систем, поддерживающих привязку к банковской карте, а именно: “PayPal” и “Яндекс.Деньги”. Все вырученные средства поступают на счет компании и затем обрабатываются сотрудниками бухгалтерского отдела. Данные обо всех финансовых операциях будут экспортироваться в корпоративную информационную систему 1С: Предприятие или другую систему, выбранную для эксплуатации. Но это отдельная задача, в этой работе будет рассматриваться только проектирование и разработка непосредственно веб-сайта виртуального магазина и его установка (развертывание) на производственном сервере.

Почтовые отправления осуществляются с помощью различных компаний по отправке почты, таких как EMS, DHL, “Почта России” и других на выбор клиента. Клиент должен оплатить стоимость доставки самостоятельно, если ее стоимость не включена в стоимость товара. Выбор способа доставки осуществляется клиентом во время оформления заказа на веб-сайте. После отправки товара клиенту выдается номер почтового отправления (почтовый идентификатор), по которому можно отслеживать текущий статус и местоположение посылки. Денежные средства за оплаченный товар резервируются до тех пор, пока системой отслеживания почтовых отправлений не будут получены данные о том, что клиент получил свою посылку.

На предприятии, осуществляющем торговлю через интернет, обычно присутствуют следующие отделы:

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

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

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

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

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

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

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

Глава 2. Функциональная модель бизнес-процессов

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

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

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

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся: BPwin (изготовитель программного продукта компания PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. В данной работе для создания диаграмм IDEF0 был использован программный продукт BPwin.

2.1. Функциональные диаграммы

Функциональное моделирование IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов.

Построение модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

Рассмотрим контекстную диаграмму «Работа интернет-магазина» (рис. 1).

Рисунок 1 – Контекстная диаграмма «Работа интернет-магазина»

Взаимодействие системы с окружающей средой описывается с помощью входов – «Товары» и «Заказы» совершаемые клиентами, выходов – «Обслуженный клиент», «Не обслуженный клиент» и «Доходы», управления – «Документы», и ресурсов необходимых для решения поставленной задачи – «Сотрудники», «ПО» и «ЭВМ».

Товары – закупленные для продажи товары.

Заказы – заказы совершаемые покупателями.

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

Сотрудники – персонал магазина, распределенный по отделам.

Обслуженный клиент – клиент получивший товар или предоставленную услугу.

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

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

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

Далее рассмотрим диаграмму декомпозиции «Организовать работу интернет-магазина» (рис.2)

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

1. Закупка товаров – закупка товаров, которые будут в дальнейшем продаваться в магазине, у поставщиков;
2. Хранение – обеспечение хранения закупленных товаров на продовольственном складе, отправка товаров по почте при поступлении заказов;
3. Продажа – непосредственно продажа товаров. Так как система оформления заказа будет полностью автоматизирована, в основные обязанности сотрудников отдела продаж будут входить консультирование клиентов, изменение статусов заказов и разрешение возникающих спорных ситуаций.

Рисунок 2 – Контекстная диаграмма «Организовать работу интернет-магазина»

Произведем дальнейшее разбиение на подсистемы процесса «Закупка товаров».

Рассмотрим диаграмму декомпозиции процесса «Закупка товаров» (рис.3). Опишем процессы, представленные на данной диаграмме декомпозиции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

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

Таблица 2

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

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

Таблица 3

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

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

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

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