Суть диаграмм использования
https://stackoverflow.com/questions/627871
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Для школьного задания мы должны составить схему использования.Но документация, которая у нас есть, не очень расширена.В нем просто описывается, из каких компонентов состоит usecase, и один пример.
Мы должны создать базу данных о библиотечной системе.Мы нашли 11 вариантов использования, но я не буду беспокоить вас всеми из них.
IIRC, usecase описывает типичное использование системы, верно?Но какие вещи должны быть на схеме использования и как они соединяются вместе?
Сейчас у нас есть четыре действующих лица (участник, служащий, менеджер и бухгалтер).Больше всего проблем у нас возникает с членами клуба и сотрудниками.
Сотрудник - это тот, кто использует систему.Принадлежит ли участник по-прежнему этому месту как актер?
Некоторые варианты использования, которые у нас есть:
- Участник присоединяется к библиотеке.
- Участник изменяет свои записи.
- Участник берет книгу напрокат.
- Участник разделяет библиотеку (отписывается).
- Участник заказывает статью.
- Участник возвращает книгу.
- Участник оплачивает (часть) сборов и штрафов.
Они становятся вариантами использования на диаграмме.Но должно ли быть больше вариантов использования, например, employee вводит membernumber, employee вводит booknumber и так далее (использует?).
Кто-нибудь может пролить (?) свет на это?
Редактировать: Как описываются последовательности действий?Мне сказали, что вы можете видеть ассоциацию uses, подобную вызову метода к какой-то процедуре, которая повторяется?Правильно ли это?И как используется extended?
Решение
IIRC, usecase описывает типичный использование системы, верно?Но что тонкие [g] s относятся к схеме использования, и как они соединяются вместе?
Ваши диаграммы вариантов использования (да, в типичном проекте их будет несколько), вероятно, должны быть самыми простыми диаграммами в вашем наборе UML.Они должны сопоставлять Актеров / Роли, которые вы определили, непосредственно с вариантами использования вашей системы.Фактически, они должны быть сосредоточены в первую очередь на одном Действующем лице и включать других действующих лиц только в том случае, если они должны участвовать в конкретном варианте использования.
Вот пример, который я нашел в Google:
Примерная Схема использования http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png
Обратите внимание на простоту.Один актер, одна Система, 5 Вариантов использования.Больше ничего.
Кроме того, поскольку @Эрик П предложено, и мой пример изображения подразумевает, что вы должны озаглавить свои варианты использования структурой "[Глагол] [Объект]";т. е."участник берет книгу взаймы" становится "Книгой взаймы".Отсутствующий субъект предложения вашего варианта использования ("участник") закодирован на вашей диаграмме вариантов использования как Субъект, связанный с вариантом использования.
Сотрудник - это тот, кто использует систему.Является ли участник по-прежнему принадлежащим здесь как актер?
Боюсь, ответ на этот вопрос субъективен.Некоторые скажут "нет", что поскольку системой пользуется только сотрудник, то сотрудник является единственным действующим лицом.Лично я с этим не согласен.
Почему?Во-первых, варианты использования являются частью этапа сбора требований.Они предназначены для того, чтобы помочь вам организовать конечную функциональность системы.Но отрицать тот Member Актер просто потому, что ваше нынешнее убеждение заключается в том, что технология не будет использоваться Member заключается в том, чтобы ограничить себя на этом этапе.
Что, если ваша конечная система является автоматизированный, означающий, что Member сама подходит к терминалу, чтобы проверить книгу?Если вы сделали предположение во время сбора требований, вы можете упустить важную функциональность.
Редактировать: Как описываются последовательности действий ?Мне сказали, что вы можете видеть a использует ассоциацию, подобную вызову метода к какой-то процедуре, которая повторяется?Правильно ли это?И как используется extended ?
Диаграммы вариантов использования находятся на высоком уровне.Они должны показывать вашу высокоуровневую функциональность (в виде каждого варианта использования) и Участников, которые их используют, и ничего больше.Не засоряйте свои диаграммы вариантов использования расширениями и включениями;они должны быть редкими и только для особых случаев.Самая большая ошибка новичка, которую вы можете совершить (и поверьте мне, я ее совершил!), - это попытаться модулировать ваш код внутри вашей диаграммы вариантов использования.Да, я знаю, это первое, что пытается сделать любой стоящий программист, но диаграммы вариантов использования - не место для этого.
Что касается последовательности действий:в типичном наборе диаграмм UML каждый вариант использования связан с ним одним или несколькими Диаграммы деятельности.Они примерно аналогичны блок-схеме и служат графическим представлением типичной структуры описания вариантов использования, которую поощряет большинство учебников по программной инженерии.
В любом случае, я надеюсь, что это поможет.Если у вас есть другие вопросы, не стесняйтесь задавать!
Другие советы
Меня учили, что у всех немного разный подход к диаграммам вариантов использования, поэтому я не знаю, применимо ли это к вам, но действующие лица - это, как правило, те, кто имеет прямой контакт с системой.Таким образом, участник не был бы актером, если бы он не отсканировал свой собственный читательский билет или что-то в этом роде, потому что ему пришлось бы проходить через сотрудника.
Варианты использования должны охватывать все, но не быть слишком подробными.Таким образом, сотрудник проверил бы наличие членства, если оно не существует, перейдите к созданию варианта использования членства, иначе проверьте наличие непогашенных сборов.Если членство на хорошем счету, отсканируйте книгу и т.д.
Похоже, у вас смутное представление о том, что такое варианты использования.Вот несколько ресурсов, которые помогут вам двигаться в правильном направлении:
Действующее лицо - это человек, использующий систему, поэтому, если Сотрудник - единственный, кто использует систему, то он должен быть действующим лицом.У вас также может быть несколько возможных участников, если, например, функция доступна как сотрудникам, так и менеджерам.
Итак, вы можете перефразировать свои варианты использования на что-то вроде "Добавить нового участника", "Изменить учетную запись участника" и т.д.
Что касается уровня детализации, я бы включил как можно больше деталей, не вдаваясь в "технические" подробности.Предложения Брэндона там довольно хороши.
