В общем, было бы здорово, если бы кто-то мне помог в создании use case diagram

Operator X needs to implement self provisioning functionality via operator’s business portal. Business portal is maintained as part of the operator’s CRM solution. Login procedure should be simple but include all the security constraints.  During user login the data from identity management system is retrieved. When user identity is confirmed the information on user current product and services is shown to him as well as campaigning info, current customer orders status and details, product upgrades suggestions and interface to product backlog catalog maintained within CRM solution as well.

 

Subscriber could perform upgrade of his current offerings, subscribe to new product or unsubscribe to some of his products. Respective service order is decomposed and requests are sent to

-          Logistics system (if equipment delivery is required)

-         Work force management  (if field staff should be involved)

-         Provisioning gateway on order to perform necessary activations and deactivations and billing notifications.

 

All these system reports to Order Management on status and completion of their tasks. If task could not be completed that exception handling procedure starts.
Потом идет уведомление клиента, что все тип топ

Я застряла в самом начале.  Получается, здесь имеется лишь 1 актер (Operator X), который после входа в систему в задании переименован в subscriber и уже отсюда идут use cases по измению или добавлению услуг /продуктов. Так?

Operator X — это компания-оператор связи. Она не входит ни в какой портал, входят её клиенты-подписчики.

Спасибо, в принципе так и думала с subscriber  разбираться. Только вашу ДВИ немного расширю

Зачем?

Просто думаю сделать немного более подробней

Вопрос  - будет ли корректно сделать так?

А зачем подробней?

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

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

Название «обновить текущие предложения» мне не кажется удачным, потому что предложения формирует Оператор и публикует автоматически или посредством какого-то Администратора сервисов. Подписчик управляет не предложениями, а своими подписками на них, так же, как Контент-менеджер интернет-магазина управляет набором доступных товаров, а Покупатель — списком отобранных товаров.

Ну и связь «extend» хоть и технически верна, на практике ничего существенно важного не добавляет, а чтение затрудняет.
Например, как человеку, не знакомому с техникой extend понять, позволяет система обновлять список подписок на предложения?

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

Если вам по условиям задания нужно продемонстрировать знание наворотов стандарта UML, оставляйте, но на производстве подобные изощрения не нужны.

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

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

Я все -таки решила уточнить по поводу  агентов-систем.. ведь их тоже актерами следует изобразить?

Ага

Благодарю