Описание в UML веб-сайта оплаты услуг

Рассматривается ООАП автоматизированной онлайн-системы создания веб-сайтов. Для краткости назовем ее автоматизированный вебпостроитель (ЛВП).

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

Диаграмма вариантов использования (Use Case Diagram). В качестве актора выступает пользователь этой системы. Пользователь может производить две операции — менять свойства веб-сайта и производить финансовые расчеты. Эти операции выражены на диаграмме двумя вариантами использования: «ИзменитьСвойстваВебСайта» и «ОплатитьУслуги». У одного пользователя может быть от одного до нескольких веб-сайтов, что отображено на отношениях ассоциации кратностью «1…П».

Вариант использования «ИзменитьСвойстваВебСайта» состоит из трех вариантов использования: «ИзменитьТему», «ИзменитьДизайн», «ИзменитьРегистрацИнформ». Они связаны с «ИзменитьСвойстваВебСайта» отношениями включения. Это отношение передает поведение ПрО. Процессы изменения свойств веб-сайта или создания веб-сайта состоят из этих трех этапов. Варианты использования «СоздатьВебСайт» и «ИзменитьСвойстваВебСайта» связаны отношением расширения. Следующий вариант использования «ОплатитьУслуги» состоит из составляющих его трех вариантов использования: «СообщитьОбОплате», «ПровестиТранзакцию», «АнализироватьРезультатТранзакции». Они связаны с «ОплатитьУслуги» отношениями включения.

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

Инициализацию варианта использования «ИзменитьСвойстваВебСайта» производит актор — «Пользователь». Этот вариант использования и составляющие его варианты пассивны.

Процесс взаимодействия диктуется пользователем. Варианты использования «ИзменитьТему», «ИзменитьДизайн», «Изменить РегистрацИнформ» последовательны по отношению друг к другу и могут взаимодействовать с «Пользователем» в прямом или обратном направлении относительно порядка, представленного на рис. 4.11.

Рис. 4.11. Диаграммы использования на сайте.

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

В диаграмме вариантов использования определены следующие основные классы (рис. 4.12).

BillingSystem. Класс отвечает за финансовые расчеты. Имеет атрибуты периода оплаты (billing Period) и баланс {balance). Посылает управляющие сообщения классам Customer, TariffPlan, ControlSystem. Получает сообщения от тех же классов.

TariffPlan. Класс управляет информацией по тарифным планам. Атрибутами является информация о ценах. Посылает сообщения классам Customer и BillingSystem. Получает сообщения от этих же классов.

Site. Представляет собой объект веб-сайта пользователя. Имеет операции по созданию и по управлению веб-сайтом. Получает управляющие сообщения от классов Customer и ControlSystem. Классы Template, PageSet, Ecommerce, PictureGallery связаны с классом WebSite отношением агрегации, так как эти классы являются его составными элементами.

Customer. Представляет собой класс пользователя. Имеет атрибуты имени (customerName) и контактной информации (contactlnfo). Посылает управляющие сообщения классам WebSite и BillingSystem, получает сообщения от класса BillingSystem.

ControlSystem. Класс-демон, объект которого существует на протяжении работы системы. Управляет процессами запуска управляющих функций (расчет стоимости услуг, включение/отключение веб-сайтов). Посылает управляющие сообщения классам WebSite и BillingSystem. Получает сообщения от класса BillingSystem.

Для моделирования процесса редактирования содержимого страницы используется вариант «РедактироватьСтраницу».

Для процесса оплаты услуг (Use case «ОплатигьУслуги») используется диаграмма кооперации. Процесс оплаты услуг инициируется классом ControlSystem путем посылки сообщения вызова операции calculateDebt () (рассчитать долг) класса BillingSystem. Сообщение представляет собой асинхронный поток управления.

Класс BillingSystem, в свою очередь, посылает сообщение вызова операции getTariffPlan () (получить тарифный план) класса TariffPlan. Поток управления синхронный. Классу TariffPlan для выполнения операции getTariffPlan () требуется вызов операции getCustomerInfo () (получить информацию о пользователе) класса Customer. Возвращаемые результаты этих сообщений представлены сообщениями в виде стрелок, обращенных в обратную сторону с кружком в начале. После получения ответной информации от класса TariffPlan класс BillingSystem вызывает операцию sendBillingMessage () (уведомить пользователя об оплате) класса Customer путем посылки сообщения. В ответ класс Customer вызывает операцию acccptPaymcnt () (принять оплату) класса BillingSystem путем посылки сообщения. После этого класс BillingSystem возвращает ответ классу ControlSystem на сообщение. Этот ответ обрабатывается в классе ControlSystem и как результат генерируется сообщение вызова операции changeStatusQ (изменить состояние) класса WebSite.

Рис. 4.12. Диаграмма классов расчета оплаты за услуги:

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

Процесс оплаты услуг (Use ease «ОплатитьУслуги») инициируется классом controlSystem путем посылки сообщения вызова операции calculateDebt () (рассчитать долг) класса BillingSystem. Сообщение представляет собой асинхронный поток управления.

BillingSystem, в свою очередь, посылает сообщение вызова операции getTariffPlan () (получить тарифный план) класса TariffPlan. Поток управления синхронный. Классу TariffPlan для выполнения операции getTariffPlan () требуется вызов операции getCustomerInfo () (получить информацию о пользователе) класса Customer. Возвращаемые результаты этих сообщений представлены сообщениями в виде стрелок, обращенных в обратную сторону с кружком в начале. После получения ответной информации от класса TariffPlan, класс BillingSystem вызывает операцию sendBillingMessage () (уведомить пользователя об оплате) класса Customer путем посылки сообщения. В ответ класс Customer вызывает операцию acceptPayment () (принять оплату) класса BillingSystem путем посылки сообщения. После этого класс BillingSystem возвращает ответ классу ControlSystem на сообщение. Этот ответ обрабатывается в классе ControlSystem, и, как результат генерируется сообщение вызова операции changeStatus () (изменить состояние) класса WebSite.

Диаграмма кооперации для процесса создания веб-сайта (Use case «СоздатьВебСайт», рис. 4.13).

Процесс создания веб-сайта инициируется классом Customer путем посылки сообщения № 1 вызова операции createWebSite () (создать веб-сайт) класса WebSite. WebSite, свою очередь, посылает сообщение № 2 вызова операции chooseTariffPlan () (выбрать тарифный план) класса TariffPlan — запись о финансовом состоянии пользователя.

После получения ответа класс WebSite посылает сообщение № 3 вызова операции chooseTemplate () (выбрать графический шаблон) класса Template. Затем класс WebSite посылает сообщение № 4 вызова операции editPageSet () (редактировать набор страниц) класса PagcSet. Регистрационная информация о пользователе вносится в систему посредством сообщения № 5 — вызов операции acceptCustomerInfo () класса Customer. Последняя операция № 6 — createNewBillingRecord () класса BillingSystem создает новую учетную запись.

Для процесса редактирования содержимого страницы (Use case «РедактироватьСтраницу»). Процесс редактирования инициируется классом Customer путем посылки сообщения № 1 вызова операции showPageSet () (показать набор страниц) класса PageSet. Затем идут сообщения № 2 и № 3, вызывающие операции showProperties () и editBlock () класса Page соответственно. После завершения редактирования изменения публикуются на веб-сайте путем вызова операции updateWebSite () класса WebSite (сообщение № 4).

Рис. 4.13. Диаграмма «Создать веб-сайт».

Процесс создания веб-сайта (диаграмма кооперации Use case «СоздатьВебСайт») инициируется классом Customer путем посылки сообщения № 1 вызова операции createWebSite () (создать веб-сайт) класса WebSite. WebSite, свою очередь, посылает сообщение № 2 вызова операции chooseTariffPlan () (выбрать тарифный план) класса TariffPlan. Далее, после получения ответа класс WebSite посылает сообщение № 3 вызова операции chooseTemplate () (выбрать графический шаблон) класса Template. Затем класс WebSite посылает сообщение № 4 вызова операции editPageSet () (редактировать набор страниц) класса PageSet. Регистрационная информация о пользователе вносится в систему посредством сообщения № 5 — вызов операции acceptCustomerInfo () класса Customer. Последняя операция № 6 — createNewBillingRecord () класса BillingSystem — создает новую учетную запись о финансовом состоянии пользователя. Диаграмма состояний описывает класс BillingSystem (). Этот класс периодически производит процедуру расчета, что отображается переходом в себя наверху диаграммы (рис. 4.14).

Диаграмма деятельности показывает процесс расчета и оплаты услуг (Use case «ОплатитьУслуги»). Сначала происходят последовательные действия с целью расчета стоимости оказанных услуг. Далее происходит ветвление по альтернативным ветвям в зависимости от значения сторожевого условия. Если выполняется условие «[долга нет]», то происходит переход в конечное состояние. В противном случае происходит разделение потоков на два параллельных (рис. 4.15).

Рис. 4.14. Диаграмма оплаты услуг.

В левой ветви происходят действия «Послать уведомление об оплате» и «Получить оплату», а в правой — «Получить оплату». Распараллеливание вызвано тем, что в общем случае пользователь может оплатить услуги, не дожидаясь уведомления. Далее параллельные потоки сливаются в один, и происходит ветвление в зависимости от сторожевого условия. При условии «[оплата не получена]» выполняется деятельность «Отключить услугу». Далее — выход в конечное состояние.

Диаграмма деятельности показывает структуру создания веб-сайта (Use case «СоздатьВебСайт») (рис. 4.16).

Моделирование структуры систем диаграммами UML представляет собой сложную проблему. Трансформация диаграмм к ЯП вызывает определенные трудности анализа и проверки правильности полученной системы.

Рис. 4.15. Диаграмма сайта «Оплата услуг» с потоками.

Рис. 4.16. Диаграмма «Создать сайт оплаты услуг».