Тебе, конечно, кажется, что так диаграмма выглядит солидно. Столько овальчиков. Не то, что просто 4. Но все расширения я бы убрал, потому как уточнения читаются: Установить параметры - это Начать игру, Простой дурак - это Начать игру, но ведь куда как проще записать это прямо в сценарии Начать игру.

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

Хорошо. В каком ВИ правильнее будет установить параметры игры(количество игроков например), если ВИ Начать игру будет абстрактным?

Хорошо. В каком ВИ правильнее будет установить параметры игры(количество игроков например), если ВИ Начать игру будет абстрактным?

Нет ты не понял. Абстрактный - это то который не имеет собственной реализации. Нет просто начать игру, есть начать одну из возможных.
В начать игру описывается некоторая общая часть, в детализированных особенности. Что-то типа http://www.uml2.ru/faq/use-cases/421-

Нет ты не понял. Абстрактный - это то который не имеет собственной реализации. Нет просто начать игру, есть начать одну из возможных.
В начать игру описывается некоторая общая часть, в детализированных особенности. Что-то типа http://www.uml2.ru/faq/use-cases/421-

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

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

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

Например, ты можешь написать:
Игрок начинает игру
Система предлагает Игроку выбрать тип игры
Игрок выбирает одну из возможных типов
Система предлагает указать количество игроков, число игровых конов
Игрок указывает число игроков и конов игры.
Система предлагает раздать карты
Игрок инициирует раздачу карт и определяет козыря
Система определяет игрока, который начинает ходить (имеет наименьший козырь)

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

Однако что там в продолжении? Каникулы заканчиваются, времени будет куда как меньше.

Однако что там в продолжении? Каникулы заканчиваются, времени будет куда как меньше.

С ДВИ вроде бы как справился. Теперь вернёмся к диаграмме классов. Оцените пожалуйста мою следующую попытку. Правильна/неправильна реализация? Чего не хватает/есть ли что то лишнее?

Если мы пока говорим о смысле, а не о реализации, то тут много недочетов.

1. параметры - почему во множественном числе? Одна Игра имеет несколько Параметр, иначе зачем выделять отдельный класс, добавь соответствующие атрибуты к классу Game

2. Game включает от 2 до n(зависит от числа карта) Players. Какой смысл в Players_Count? Во-первых, это характеристика Игры, во-вторых, если и нужен этот атрибут. то он вычисляемый.

3. Что это за атрибуты в Game, каков их смысл?

4. Game ассоциация к Card - вернее композиция. 1- почему композиция, 2- зачем эта связь нужна, 3- почему бы не сделать тогда связь между Game и Card_Deck

5. Не понятно, где будет отражаться ход игры. В ДВИ есть что-то типа сохранения текущей игры?

Если мы пока говорим о смысле, а не о реализации, то тут много недочетов.

1. параметры - почему во множественном числе? Одна Игра имеет несколько Параметр, иначе зачем выделять отдельный класс, добавь соответствующие атрибуты к классу Game

2. Game включает от 2 до n(зависит от числа карта) Players. Какой смысл в Players_Count? Во-первых, это характеристика Игры, во-вторых, если и нужен этот атрибут. то он вычисляемый.

3. Что это за атрибуты в Game, каков их смысл?

4. Game ассоциация к Card - вернее композиция. 1- почему композиция, 2- зачем эта связь нужна, 3- почему бы не сделать тогда связь между Game и Card_Deck

5. Не понятно, где будет отражаться ход игры. В ДВИ есть что-то типа сохранения текущей игры?

1. Т.е. вы хотите сказать, что класс Parametrs здесь не нужен?
2. Players_Count - это параметр, который задаёт пользователь до начала иры
3. First_player - имя игрока, который первым будет делать ход. User и Computer - игроки, принимающие участие в игре
4. Композиция потому, что игра не может существовать без карт(иначе как играть?). Связь нужна для использования Card классом Game. Cвязь между Game и Card_Deck не нужна, т.к. игре будет достаточно знать всю информацию о картах, информация о колоде не особо то и нужна
5. В ДВИ есть что-то типа сохранения текущей игры. Ход игры будет отображаться в классе Game.

1. Т.е. вы хотите сказать, что класс Parametrs здесь не нужен?

Если мы играем сейчас в игру здравого смысла, то я не понимаю назначения данного класса. Параметры чего? без понятия ИГРЫ они бессмысленны. Зачем выделять в отдельный класс - пока мне причина не понятна, а она должна быть и существенной. Что означает связь между Игра и Параметры? Правильно ли, что набор одних и тех же параметров, встречается в разных Играх или все-таки одна и также Игра имеет разные Параметры?

2. Players_Count - это параметр, который задаёт пользователь до начала иры

Ну вот разве это не характеристика конкретной игры? Почему это нужно хранить в отрыве от сущности и понятия Игра, к какой-то иной сущности параметры?

3. First_player - имя игрока, который первым будет делать ход. User и Computer - игроки, принимающие участие в игре

Зачем? Разве это не следует из правил игры и из самого факта связи конкретной ИГры с набором конкретных Игроков. Первый игрок - это вообще тот, кто имеет на руках наименьший козырь. Это результат начала игры. А признак первости - характеристика Игрока, а не игры, также как и является ли он Юзерем или Компьютером.

4. Композиция потому, что игра не может существовать без карт(иначе как играть?). Связь нужна для использования Card классом Game. Cвязь между Game и Card_Deck не нужна, т.к. игре будет достаточно знать всю информацию о картах, информация о колоде не особо то и нужна

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

5. В ДВИ есть что-то типа сохранения текущей игры. Ход игры будет отображаться в классе Game.

Предположим, но на диаграмме я этого не увидал.

Если мы пока говорим о смысле, а не о реализации, то тут много недочетов.

Оцените пожалуйста смысловое проектирование. Реализацию буду делать, когда со смыслом будет всё в порядке

Оцените пожалуйста смысловое проектирование. Реализацию буду делать, когда со смыслом будет всё в порядке

Понимаешь, ты тут все в кучу и кислое, и мягкое. От того полное фондю ...
У тебя тут и смысловые классы (предметной области) и классы приложения - все в кучу. Тут же уже распределены ответственности.
Ну не по феншую это...

1. Main_Menu -это вообще группа контролов главного окна приложения например. Да главное окно можно рассматривать как наследника класса Форма, на чем бы ты не делал задача на xaml, wf, в сибилдере борлановском или еще в какой-то swinge - если ты используешь фреймворк или просто библиотеку ты берешь какой-то базовый класс типа window. При этом меню ясный перец - часть этого главного окна приложения, где есть панель меню, есть панель вывода (где все собственно и рендерится) canvas какой-то и т.п. И все это образует богатую собственную структуру со своими атрибутами, событиями и методами. Зачем это указывать здесь - мне не понятно

2. Что такое PLay? по сути это интерфейс, который реализует класс Game - причем тут композиция???

3. Связь между Колодой и Игрой - как минимум в обратном направлении. Это игра включает колоду а не колода включает игру
Правда если рассуждать, что колода может участвовать в разных играх, а вот в игре только одна колода? Но это тоже плохо, так как колода участвует физически только в одной игре/

4. Связь агрегации между Игроком и Картами весьма странная - мало того что она многие ко многим, так и семантически не понятна. Каким образом Игрок выступает агрегатором карт? - Да у игрока на руках в течение Игры может быть от нуля до 36 карт скажем, Понятно что одна и та же карта в течение Игры может переходить в руки разных Игроков, быть в Колоде или в Отбое

На твоей диаграмме я смысла не улавливаю

5. Что это за класс Компьютер чем один компьютер игрок будет отличаться от другого? Может дать более понятное название классу - типа Робот?

6. У Игрока - если уж пишешь методы, почему кроме методов получения нет ничего, а как же метод сделать ход - т.е. положить в игру карту? Ну и т.п. Или мне пока на методы не смотреть?

Понимаешь, ты тут все в кучу и кислое, и мягкое. От того полное фондю ...
У тебя тут и смысловые классы (предметной области) и классы приложения - все в кучу. Тут же уже распределены ответственности.
Ну не по феншую это...

1. Main_Menu -это вообще группа контролов главного окна приложения например. Да главное окно можно рассматривать как наследника класса Форма, на чем бы ты не делал задача на xaml, wf, в сибилдере борлановском или еще в какой-то swinge - если ты используешь фреймворк или просто библиотеку ты берешь какой-то базовый класс типа window. При этом меню ясный перец - часть этого главного окна приложения, где есть панель меню, есть панель вывода (где все собственно и рендерится) canvas какой-то и т.п. И все это образует богатую собственную структуру со своими атрибутами, событиями и методами. Зачем это указывать здесь - мне не понятно

2. Что такое PLay? по сути это интерфейс, который реализует класс Game - причем тут композиция???

3. Связь между Колодой и Игрой - как минимум в обратном направлении. Это игра включает колоду а не колода включает игру
Правда если рассуждать, что колода может участвовать в разных играх, а вот в игре только одна колода? Но это тоже плохо, так как колода участвует физически только в одной игре/

4. Связь агрегации между Игроком и Картами весьма странная - мало того что она многие ко многим, так и семантически не понятна. Каким образом Игрок выступает агрегатором карт? - Да у игрока на руках в течение Игры может быть от нуля до 36 карт скажем, Понятно что одна и та же карта в течение Игры может переходить в руки разных Игроков, быть в Колоде или в Отбое

На твоей диаграмме я смысла не улавливаю

5. Что это за класс Компьютер чем один компьютер игрок будет отличаться от другого? Может дать более понятное название классу - типа Робот?

6. У Игрока - если уж пишешь методы, почему кроме методов получения нет ничего, а как же метод сделать ход - т.е. положить в игру карту? Ну и т.п. Или мне пока на методы не смотреть?

1. Т.е. хотите сказать, что класс Main_Menu здесь не нужен?

2. Т.е. Play должен быть интерфейсом? Связь реализации от Game к Play?

3. Действительно. Спасибо.

4. Ассоциация 1 ко многим?

5. Компьютер - это игрок-компьютер. Отличаться они будут как минимум "именем" и уровнем игры. А ещё наличием карт, приоритетом ходьбы и т.д.

6. Эти методы реализованы в Play. Или они должны быть в Player, а в Play просто реализован класс Game?

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

1. Т.е. хотите сказать, что класс Main_Menu здесь не нужен?

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

2. Т.е. Play должен быть интерфейсом? Связь реализации от Game к Play?

Ну, а что еще есть в классе Play - только поведение, какой смысл это поведение отображать в отдельном классе? Только если мы предполагаем будущую модификацию с одной стороны, а  с другой стороны это точно определяет поведение. И опять же все это так же как Menu - есть классы приложения. Мы же пока строим модель предметной области.

4. Ассоциация 1 ко многим?

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

6. Эти методы реализованы в Play. Или они должны быть в Player, а в Play просто реализован класс Game?

А чем в твоем случае отличается Play Game и Player?

Следующую диаграмму классов преподаватель оценил как нормальную (правда в подробности особо не вникал)

Следующую диаграмму классов преподаватель оценил как нормальную (правда в подробности особо не вникал)

Ну думаю, преподаватель увидел основные моменты в реализации твоей диаграммы классов. Видимо впечатлился:)
Мне только не понятен момент реализации интерфейса Play - почему класс Игрок содержит все методы этого интерфейса, а класс Game, который тоже реализует интерфейс Play нет?

Ну думаю, преподаватель увидел основные моменты в реализации твоей диаграммы классов. Видимо впечатлился:)
Мне только не понятен момент реализации интерфейса Play - почему класс Игрок содержит все методы этого интерфейса, а класс Game, который тоже реализует интерфейс Play нет?

класс Game - это класс, который отвечает за параметры игры (количество игроков, тип игры, уровень сложности), добавляет игроков в игру. По сути он не должен выполнять то, что реализовано в методах интерфейса. Он всего лишь должен задавать параметры для его реализации
но дело даже не в этом. Я не могу понять, как строить диаграмму последовательности. Все остальные диаграммы уже построил, правильно/неправильно - но я хотя бы понимал, что я делаю, как, для чего и зачем(ниже примеры). С диаграммой последовательности - полный ноль. Вроде бы всё просто, берёшь поток событий и строишь, но когда доходит до дела - дело не движется. Не могли бы вы объяснить мне, с чего вообще стоит начать?