2011-01-25 2 views
1

Должен ли я сделать два отдельных варианта использования, если член веб-сайта может просматривать свой личный профиль и профиль других пользователей? Должен ли он быть членом - Просмотр собственного профиля и профиля Member-View Others? Или просто Member - Просмотр профиля достаточно?Случаи использования: отдельный или нет?

ответ

2

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

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

С другой стороны, в этом также есть несколько случаев - вы должны иметь такие случаи, как член, который может редактировать свой профиль, редактировать другие профили, и это также может идти и на отдельные поля. Участник может редактировать все свои данные, но в состоянии редактировать несколько деталей других конкретных членов ниже его в иерархии и не должен редактировать какие-либо сведения о других членах выше его в иерархии и т. Д.

+0

Случаи использования не являются функциями, проверьте литературу (например, Bittner). –

+0

@Gabriel - Ну, не уверен, что это заслужило ниспровержение. Во всяком случае, я отредактировал, чтобы изменить «функции» на «сценарии». Надеюсь, это кажется прекрасным? –

+1

@ Sachin Shanbhag проблема не в словах (хотя примеры использования представляют собой набор сценариев, а не определенный), а в содержании. Используйте случаи в качестве помощи для достижения определенной цели для актера. Это означает, что каждый отдельный случай использования должен иметь ценность для актера. Представьте, что единственной целью (и поведением) веб-приложения было бы показать члену свою информацию. Может ли такое приложение вам помочь? Вы заплатили бы за это? Для проверки подлинности и авторизации может потребоваться экран входа в систему, но это функция, а не вариант использования, ни один из них не будет платить за приложение, которое позволяет войти. –

0

Я бы сказал, что три например: Use cases

+0

Варианты использования не предназначены для структурирования функциональности. Варианты использования предназначены для анализа, а не для проектирования системы. –

+0

Разве вы не используете сценарии внутри случаев использования для определения классов, атрибутов и действий? Я знал, что разрешено факторизовать прецедент, когда он был частью более чем одного случая использования, поэтому у вас нет для повторения сценариев. – Dario

+0

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

0

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