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

Question

Для школьного задания мы должны составить диаграмму Usecase. Но документация, которую мы имеем, не сильно расширена. Он просто описывает, из каких компонентов состоит код использования, и один пример.
Мы должны сделать пример использования библиотечной системы. Мы нашли 11 вариантов использования, но я не буду вас беспокоить.

IIRC, сценарий использования описывает типичное использование системы, верно? Но что относится к диаграмме прецедентов и как они соединяются вместе?

Теперь у нас есть четыре актера (участник, сотрудник, менеджер и бухгалтер). Те, с которыми у нас больше всего проблем, - это члены и сотрудники.
Сотрудник - это тот, кто использует систему. Член по-прежнему принадлежит здесь как актер?

Некоторые примеры использования, которые у нас есть:

• Член присоединяется к библиотеке.
• Участник изменяет свои записи.
• Участник одалживает книгу.
• Член разделяет библиотеку (отписывается).
• Член книги заказывает статью.
• Пользователь возвращает книгу.
• Участник оплачивает (часть) сборы и штрафы.

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

Может кто-нибудь пролить (?) Свет на это?

Edit: Как описываются последовательности действий? Мне сказали, что вы можете видеть ассоциацию использования, например, вызов метода для некоторой подпрограммы, которая повторяется? Это правильно? А как продлен б?

Answer 1

IIRC, случай использования описывает типичный использование системы, верно? Но что тонкие [g] s принадлежат диаграмме вариантов использования, и как они соединяются вместе?

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

Вот пример, который я получил от Google:

Пример схемы использования http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png

Обратите внимание на простоту. Один актер, одна система, 5 вариантов использования. Ничего другого.

Кроме того, как предложил @ Eric P и из моего примера изображения, вы должны озаглавить ваши варианты использования структурой "[Verb] [Object]"; то есть "участник заимствует книгу" становится "Заемной книгой". Недостающий предмет вашего предложения варианта использования («участник») закодирован в вашей диаграмме вариантов использования как актер, связанный с вариантом использования.

Работник - это тот, кто использует система. Член еще принадлежит здесь как актер?

Боюсь, ответ на этот вопрос субъективен. Кто-то скажет «нет», потому что система используется только сотрудником, тогда сотрудник является единственным действующим лицом. Я лично не согласен.

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

Что если ваша возможная система автоматизирована, то есть Member отправляется в терминал, чтобы самостоятельно проверить книгу? Если вы сделали предположение во время сбора требований, вы можете упустить важную функциональность.

Редактировать: Как последовательность действий описал? Мне сказали, что вы можете видеть использование использует как вызов метода к какой-то рутине, которая повторяется? Это правильно? И как продлен используется

Диаграммы вариантов использования высокого уровня . Они должны показывать вашу высокоуровневую функциональность (в форме каждого варианта использования) и актеров, которые их используют, и ничего больше. Не засоряйте свои Диаграммы вариантов использования расширениями и включениями; они должны быть редкими и особенными. Самая большая ошибка новичка, которую вы можете сделать (и поверьте мне, я сделал это!), Состоит в том, чтобы попытаться модулировать ваш код в диаграмме вариантов использования. Да, я знаю, что это первое, что пытается сделать любой программист, но диаграммы Use Case не место для этого.

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

В любом случае, надеюсь, это поможет. Если у вас есть другие вопросы, не стесняйтесь спрашивать!

Answer 2

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

• Варианты использования - Введение
• Диаграммы вариантов использования UML

Answer 3

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

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

Answer 4

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

Таким образом, вы можете перефразировать ваши варианты использования в нечто вроде «Добавить нового участника», «Изменить учетную запись участника» и т. Д.

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