UML и анализ

Question

Я понимаю UML, но мне кажется, у меня проблемы с проведением базового анализаВот пример проекта:

Цель состоит в том, чтобы спроектировать страницу или приложение на Facebook, где зарегистрированные пользователи могут купить другого пользователя, чтобы стать его владельцем, и изменить свое сообщение о статусе.

Каждыйпользователь начинает с 1000 очков и может купить другого пользователя за 500 очков.Это мешает другим пользователям покупать пользователя в течение получаса.После завершения транзакции покупатель получает 200 баллов, а купленный пользователь - 200 баллов.Каждый раз, когда израсходовано 100 баллов, зарабатывается 20 баллов.Каждый раз, когда пользователь покупает, его стоимость увеличивается на 200. Каждый день дается 300 очков.

Участник может найти других участников с помощью функции поиска или списка.

Администратор может просматривать информацию о пользователе., получить информацию об игре и дать бонусные баллы.

Я могу определить Актеров сценариев использования User и Administrator.Варианты использования: Search, Buy, Modify (для пользователя) и View user information, View game information, Give bonus points (для администратора).Я застрял, когда дело доходит до диаграмм последовательности, определяющих, какие классы нужны и какие операции.

Какой совет или какой подход вы можете дать, чтобы начать работу с этим примером?Я попытался прочитать несколько книг на эту тему, но я в замешательстве.

Answer 1

Нет смысла делать диаграмму последовательности, пока у вас не появятся какие-то классы.

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

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

Да, похоже, что у вас есть Пользователь и Администратор как два актера.Я вижу такие операции, как «поиск пользователей» и «добавление игровых очков».(Где-то там прячется «игра»)

Answer 2

Если это вариант, вы можете использовать SysML вместо UML.SysML был разработан для системного анализа / проектирования и, как следствие, не имеет всех элементов моделирования для представления мелких деталей, которые есть в UML.Но у него есть Требования (которых нет в UML) и, конечно, Варианты использования, Действия и т. Д.

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

Это потому, что дизайн - это не уточнение анализа, это качественно иная вещь: анализ является входом в дизайн (то есть, что должночто делает система?), но ни одна модель использования не скажет вам, какую стратегию сообщения об ошибках должен использовать ваш код.Или в вашем случае драйвер дизайна номер один на самом деле вовсе не случай использования, а тот факт, что вы будете реализовывать его с помощью API Facebook.

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