2010-12-10 2 views
2

Я создаю диаграмму UseCase для системы управления библиотекой. У меня есть «Login» usecase, который должен делать каждый актер, чтобы перейти к другим обычаям. другими словами, я хочу показать, что «Login» usecase является обязательным условием для других пользователей. Кто-нибудь знает, как это показать? благодарякак сделать мой «вход» прецедентом для использования в других случаях в UML

ответ

7

Есть несколько способов сделать это:

  1. Используйте <<include>> отношения, где каждый UC <<includes>> Войти как первый шаг
  2. Установите предварительное условие на каждом UC, который должен иметь пользователь зарегистрированный в
  3. Создайте актера с именем «Записанный пользователь» (или аналогичный) и покажите все связанные с ним связанные с ним дела.

Что вы выбираете, зависит от ряда факторов. (1) прост и интуитивен, но на самом деле не очень хорошо масштабируется на диаграмме, если у вас много случаев использования. (2) работает хорошо, если вы документируете «Использовать случаи» в текстовом виде, но не отображаются на диаграммах. (3), возможно, не является обычным, но может обеспечить более масштабируемость, чем (1), хотя его можно просматривать на диаграмме. Однако он ломается, если у вас есть несколько Актеров, каждый из которых должен быть зарегистрирован для выполнения своих UC.

Я лично стараюсь использовать (2). Если мне нужна диаграмма UC, я включу UC «Login», но не покажут отношение от нее к другим UC.

Один вариант, который я бы не рекомендовал, является отношением <<extend>>, где каждый UC <<extends>> Вход UC. Это действительно не работает семантически и имеет такие же проблемы масштабируемости, как (1) выше.

hth.

+0

благодаря sfinnie. Я искал в Интернете предварительные условия для использования. было много ответов, но ни один из них не показал диаграмму с предварительными условиями. Интересно, это комментарий или что-то в этом роде. если вы можете показать мне, что это такое на диаграмме, я буду признателен. – m0j1 2010-12-10 19:43:16

1

Альтернативой отношения <<includes>> в этом случае является зависимость <<precedes>>. Это делает более ясным, что логин должен быть предшествующим, а не просто происходит в какой-то момент во время использования.

Enterprise Architect включает такую ​​стереотипную зависимость в панели инструментов Case Case, но в противном случае вы могли бы создать свою собственную стереотипную зависимость. Документация EA на этом говорится:

Запускает и Precedes отношения определяются Open Modeling Language (OML). Они представляют собой стереотипные отношения зависимости; Вызов указывает, что в случае использования варианта «Случай A» в какой-то момент происходит случай использования B, а Precedes указывает, что Use Case C должен завершиться до начала использования Case D.

Возможно, вы не хотите вводить идиомы OML в свой UML, но функция делает именно то, что вы хотите и видимо на уровне диаграммы.

0

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

Самое главное, что UC не предназначены для полной спецификации системы.Так просто положить его где-нибудь еще, например:

  • , как правило, в общем списке правил системы

  • в виде таблицы в «права доступа пользователей» спецификации раздела