Здравствуйте Коллеги.

Первый раз взялся анализировать ПО на UML и появился первый вопрос. Правильно ли я использую стереотипы "include" и "extend" (см. рисунок):

Напрягает два момента:
1) Если взять UseCase OpenDocument, то действительно у него есть два варианта либо открыть документ DeviceDatabase, либо документ IPadressDatabase. При этом возможен только один из этих вариантов, т.е. это больше похоже на ветвление, и не понятно на сколько оправдано использовать стереотип "include" в данном случае;
2) Если же рассмотреть UseCase CloseDeviceDatabaseDocument, то понятно что перед закрытием программа должна спроси пользователя не сохранить ли текущий документ и если пользователь ответит "Да" выполнить UseCase SaveDeviceDatabaseDocument. Ну опять же на сколько оправдано использовать стереотип "extend" в этом случае?

Здравствуйте.

Мое мнение таково: Вы пытаетесь построить нечто вроде функциональной диаграммы декомпозиции.
При построении диаграммы вариантов использования (ДВИ) нужно придерживаться ряда правил:
1. простота и наглядность
2. глубина инклюдов и экстендов не более одного уровня
3. включаемый или расширяющий вариант использования обычно является абстрактным, собственно так и получается у вас.
4. но включаемый или расширяющий ВИ - это ведь повторно используемое поведение (а у вас это отсутствует)
5. а самое главное - отсутствует цель пользователя

Совет почитать что-то серьезно и переделать диаграмму

Здравствуйте,

Не согласен, пользователь очень заинтересован в сохранении своего документа чтобы труды его не пропали даром. По этой же причине он заинтересован и в его открытии. Может быть это конечно прелюдия к основной цели выполняемой программой, но без нее не куда.
По поводу почитать - уже читал дважды разные книги. В обоих случаях всё что там написано слишком расплывчато. Даже если взять пресловутую "цель пользователя", то в это понятие можно уместить что угодно, всё зависит от точки зрения. Я уверен, что проектирование с использованием UML это одна из тех задач, где опыт имеет большее значение чем знание теории. Это собственно одна из причин почему я решил перестать читать и начать чё то делать.
Я думаю из диаграммы понятна какая у неё цель, не могли бы вы описать как должен выглядеть правильный вариант.

Согласны вы со мной или нет, это ваше право. Читать ли вам книги или не читать - это ваше право.

Ваше диаграмма - это функциональная декомпозиция, такую диаграмму вполне можно было получить используя например IDEF0 нотацию. Почему я уже объяснил.

Открыть, сохранить или закрыть документ - в чем тут цель? Можно ли сохранить не открытый документ, а что будет происходить с закрытием, можно ли закрыть не открытый документ?

Как я могу нарисовать вашу диаграмму, не зная вашей предметной области?

Ну хорошо. Программа чисто учебная, просто я выбрал предметную область которая мне ближе. Цель программы опрашивать некоторый список сетевых устройств, собирать информацию о сетевых интерфейсах которым назначены IP-адреса и потом формировать базу IP-адресов. Я предположил, что список устройств нужно сохранять в каком то внутреннем представлении программы, которое я назвал базой данный устройств, поскольку нужно поддерживать всякие сервисные функции типа - добавить новое устройств, удалить старое, изменить атрибут устройсва и т.п. Также нужно поддерживать базу данных IP-адресов, чтобы опять же возможно было ее редактировать, сохранять, загружать и т.п.
Зная всё это, какие именно практические с точник зрения пользователя UseCase'ы можно выделить?
Я например считаю, что можно выделить как минимум следующие:
- Опрость список устройств (для этого его нужно как то предварительно сформировать)
- Создать новый список устройств
- Загрузить сохраненный список устройcтв
- Сохранить список устройств
- Редактировать список устройств
- Сформировать базу данных IP-адресов из списка опрошенных(!) устройств
- Редактировать базу данных устройств
- Сохранить базу данных IP-адресов
- Создать новую базу данных IP-адресов
- Открыть сохраненную базу данных IP-адресов

Ну хорошо. Программа чисто учебная, просто я выбрал предметную область которая мне ближе. Цель программы опрашивать некоторый список сетевых устройств, собирать информацию о сетевых интерфейсах которым назначены IP-адреса и потом формировать базу IP-адресов. Я предположил, что список устройств нужно сохранять в каком то внутреннем представлении программы, которое я назвал базой данный устройств, поскольку нужно поддерживать всякие сервисные функции типа - добавить новое устройств, удалить старое, изменить атрибут устройсва и т.п. Также нужно поддерживать базу данных IP-адресов, чтобы опять же возможно было ее редактировать, сохранять, загружать и т.п.
Зная всё это, какие именно практические с точник зрения пользователя UseCase'ы можно выделить?
Я например считаю, что можно выделить как минимум следующие:
- Опрость список устройств (для этого его нужно как то предварительно сформировать)
- Создать новый список устройств
- Загрузить сохраненный список устройcтв
- Сохранить список устройств
- Редактировать список устройств
- Сформировать базу данных IP-адресов из списка опрошенных(!) устройств
- Редактировать базу данных устройств
- Сохранить базу данных IP-адресов
- Создать новую базу данных IP-адресов
- Открыть сохраненную базу данных IP-адресов

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

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

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

1) "Include" и "extend" не стереотипы.
2) Авторы большинства подобных тем не предоставляют достаточных сведений, чтобы была возможность ответить на их вопрос.
3) Беглого знакомства с книжкой Коберна обычно достаточно, чтобы самому себе дать адекватный ответ на подобный вопрос.

Здравствуйте Коллеги.

Первый раз взялся анализировать ПО на UML и появился первый вопрос. Правильно ли я использую стереотипы "include" и "extend" (см. рисунок):

Напрягает два момента:
1) Если взять UseCase OpenDocument, то действительно у него есть два варианта либо открыть документ DeviceDatabase, либо документ IPadressDatabase. При этом возможен только один из этих вариантов, т.е. это больше похоже на ветвление, и не понятно на сколько оправдано использовать стереотип "include" в данном случае;
2) Если же рассмотреть UseCase CloseDeviceDatabaseDocument, то понятно что перед закрытием программа должна спроси пользователя не сохранить ли текущий документ и если пользователь ответит "Да" выполнить UseCase SaveDeviceDatabaseDocument. Ну опять же на сколько оправдано использовать стереотип "extend" в этом случае?

Зачем такое дикое количество вариантов использования на одной диаграмме?)))

Достаточно одного варианта использования - ManageDocument. От него Extend OSC (Open Save Close).