Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: Кротяка от 04 Января 2014, 20:12:03
-
В UML новичок, владею начальными знаниями в этой области, сроки горят...необходимо спроектировать диаграмму классов на тему "Карточная игра Дурак". Помогите, если не сложно...
-
Нужны начальные требования, описание игры.
Какие требования:
сколько возможно игроков (до 6?), кто будут являться игроки - компьютер или люди? игра сетевая?
набор правил - кто начинает ход, сколько карт можно набирать, первый отбой сколько карт и так далее.
Например: http://www.gambiter.ru/durak/item/69-igra-durak-pravila.html
Следуя правилам можно начать выделять потенциальные классы.
Колода
Карта (Масть, Номинал, Козырь?)
Игрок (Нападающий, Отбивающийся, Число карт)
Раздача
Ход
т.п.
все это связать, предложить для обсуждения.
Однако я вижу вы уже активно работаете :) http://www.cyberforum.ru/uml/thread1059174.html
-
Ну нужно же что то придумать :)
В самом начале игры должен производиться выбор: простой дурак, подкидной, переводной
Правила игры:
В колоде 36 карт
Количество игроков - до шести
количество набираемых карт - до 36
Первый отбой - 5 карт
Первый ход - у игрока с наименьшим козырем
Существует 1 реальный игрок - человек, остальные - компьютер
-
Ну, молодец.
Действуем дальше. Правила игры - это поведенческие аспекты. Нам пока нужно определить структурные: про диаграмму классов говорится.
Вопрос выбора типа игры - это вопрос взаимодействия с системой, который скорее всего может быть описан вариантом использования "Играть в игру", мы его рассматривать не буду.
Структурные элементы игры известны. Начинаем придавать им форму - рисуй диаграмму, тут бесплатных пироженых не бывает.
-
количество набираемых карт - до 36
Это что за правило? Если одни наберет все 36 карт наверное он того, проигравший:)
-
Ну нужно же что то придумать :)
В самом начале игры должен производиться выбор: простой дурак, подкидной, переводной
Правила игры:
В колоде 36 карт
Количество игроков - до шести
количество набираемых карт - до 36
Первый отбой - 5 карт
Первый ход - у игрока с наименьшим козырем
Существует 1 реальный игрок - человек, остальные - компьютер
Добрый вечер!
1. Сформулируйте назначение системы с точки зрения игрока.
2. Определите какими классами событий/действий будет оперировать система, выполняя своё назначение.
3. Определите с какими классами объектов/субъектов/сущностей будут связаны вышеуказанные события.
4. Нарисуйте диаграмму классов, расставив связи между ними и множественности.
-
собственно диаграмма то у меня есть
имеются сомнения относительно правильности и уровня её выполнения
-
собственно диаграмма то у меня есть
имеются сомнения относительно правильности и уровня её выполнения
Судя по диаграмме, у тебя имеется довольно зрелое представление об UML. Мне правда, не совсем ясно назначение некоторых классов, а алгоритмы методов скрыты от меня. Также я вижу некоторые проблемы с кратностями связей, но в чем все-таки проблема?
-
собственно диаграмма то у меня есть
имеются сомнения относительно правильности и уровня её выполнения
1. Обычно сначала рисуется диаграмма классов анализа. На ней не должно быть главного меню и других проектных классов.
2. Название каждого класса должно быть в единственном числе.
3. Откуда крупье в игре "Дурак"?
4. Предлагаю идти поэтапно, сначала правильно выделить классы, а уже потом атрибуты и операции.
5. Предыдущее моё сообщение остаётся в силе.
-
в чем все-таки проблема?
как мне кажется для курсового проекта эта диаграмма слишком проста
-
Откуда крупье в игре "Дурак"?
предлагаете убрать крупье? кто то же должен сдавать карты
Обычно сначала рисуется диаграмма классов анализа
с такими диаграммами не сталкивался
-
предлагаете убрать крупье? кто то же должен сдавать картыс такими диаграммами не сталкивался
Когда я играл в дурака, то всегда сдавал кто-то из игроков и они никогда не назывались "крупье". Диаграмма классов такая же, просто на ней отсутствуют проектные классы типа "главное меню"
-
как мне кажется для курсового проекта эта диаграмма слишком проста
Что является целью курсового проекта? Готовое приложение для игры в дурака? Или сама записка со всеми проектными решениями?
Вообще приложение можно сделать по-разному. Если задача выполнить именно объектно-ориентированную разработку в соответствии с тем подходом, которому вас учат, то хотелось бы понимать, а чему вас учат:).
В любом случае нужно понять, что должна делать твоя программа, а затем понять какие классы какие обязанности будут исполнять. Это как раз и будет задачей ОО программирования, определить кто за что ответственен.
Ты нарисовал имеющуюся диаграмму классов, которая включает уже все программные классы приложения, так ведь? Почему ты полагаешь, что она слишком простая для курсовой?
-
Замечания по диаграмме
1. Композиция - Main_Menu - Game - в чем ее смысл?, кратность 1 ко 1, как планируется это обеспечивать, зачем? Почему Игра композируется в понятие Главное меню? Не означает ли это, что есть главное окно приложения, которое включает в себя: Главное меню, Окно текущей игры и т.п.
2. Почему Крупье агрегируется в игру, а Игроки композируются? Крупье по сути осуществляет раздачу колоды, но как заметил Сергей, роль Раздатчика переходит к проигравшему, а в начале случайна.
3. Card_Deck - это карточная колода. Цвет рубашки и тип - это конечно очень важно, но что значит Игрок имеет атрибут Карты типа Карточная колода? Карточная колода - это коллекция, а игрок имеет некоторый набор этих карт в течение игры, а не просто так - никак это момент не отражен, хотя показана связь многие ко многим. Связь Колода и Крупье - не совсем понятна.
Я бы для начала убрал все лишние методы, оставил только классы и атрибуты, при этом рекомендую следовать советам Дениса Бескова (http://www.uml2.ru/forum/index.php?topic=6101.msg36727#msg36727)
-
Что является целью курсового проекта? Готовое приложение для игры в дурака? Или сама записка со всеми проектными решениями?
Вообще приложение можно сделать по-разному. Если задача выполнить именно объектно-ориентированную разработку в соответствии с тем подходом, которому вас учат, то хотелось бы понимать, а чему вас учат:).
В любом случае нужно понять, что должна делать твоя программа, а затем понять какие классы какие обязанности будут исполнять. Это как раз и будет задачей ОО программирования, определить кто за что ответственен.
Ты нарисовал имеющуюся диаграмму классов, которая включает уже все программные классы приложения, так ведь? Почему ты полагаешь, что она слишком простая для курсовой?
целью курсового является проектирование системы, после чего выполняется ОО разработка приложения
Вот собственно задание для разработки диаграммы классов:
Найти сущности, для которых можно выделить базовый и производный классы. Привести описание базовой (абстрактной) сущности и производных сущностей, указать отличительные черты производных сущностей между собой. Создать иерархию классов, определить базовый и производный классы.
При выполнении работы учесть следующие требования:
•выделить общие методы производных классов, описать их в отдельной таблице;
•предусмотреть хранение объектов иерархии;
•показать на диаграмме классов иерархию классов и связи между классами;
•сгенерировать код по разработанной диаграмме.
-
Я бы для начала убрал все лишние методы, оставил только классы и атрибуты
сделал как вы рекомендовали
-
Хм. Задание довольно однозначно говорит, что делать. Правда, не совсем ясно как, это должно быть отражено в методических указаниях. Ну весьма странно требовать что-то не давая примеров.
Мне, правда, не совсем понятно требование выстраивания иерархии классов. Почему иерархии, а зачем она вообще тут нужна, из чего это следует? Видимо, это следует из понимания задачи преподавателем. Посмотрите на примеры, которые дает вам преподаватель и примеры других курсовых проектов.
Я бы начал с описания процесса игры, а дальше постарался распределить функции (действия) по классам. Получится ли при этом иерархия классов, пока мне не совсем ясно. Это будет ясно после проведения анализа и построения первичной модели классов.
При этом классы так или иначе разделятся на те, которые представляют суть предметной области (т.е. игры в дурака) и те, которые будут являться программными классами: формы, контроллеры, диспетчеры и т.п.
-
Хм. Задание довольно однозначно говорит, что делать. Правда, не совсем ясно как, это должно быть отражено в методических указаниях. Ну весьма странно требовать что-то не давая примеров.
Мне, правда, не совсем понятно требование выстраивания иерархии классов. Почему иерархии, а зачем она вообще тут нужна, из чего это следует? Видимо, это следует из понимания задачи преподавателем. Посмотрите на примеры, которые дает вам преподаватель и примеры других курсовых проектов.
Я бы начал с описания процесса игры, а дальше постарался распределить функции (действия) по классам. Получится ли при этом иерархия классов, пока мне не совсем ясно. Это будет ясно после проведения анализа и построения первичной модели классов.
При этом классы так или иначе разделятся на те, которые представляют суть предметной области (т.е. игры в дурака) и те, которые будут являться программными классами: формы, контроллеры, диспетчеры и т.п.
собственно всё и дело в том, что какие либо методические указания отсутствуют, ровно так же, как и примеры. Я процитировал вам всё, что было в инструкции
Оцените пожалуйста мой предыдущий пост. Хочется знать, в нужном ли направлении я двигаюсь
-
сделал как вы рекомендовали
Не, то что сделано - в топку.
Давай начнем пока с классов предметной области.
1. Нужен ли нам класс Колода? Какую функцию он будет выполнять? Выступать хранилищем карт и следить за тем чтобы все карты были разные, чтобы раздавались уникальные карты, будет отвечать за козыря, за порядок карт в колоде перед раздачей и в ходе игры, будет отвечать за цвет и дизайн рубашки - годится?
2. Колода состоит из карт (т.е. если ты рисуешь композицию, то она ромбом направлена на колоду). Нужно указать что колода состоит из Карт от 36 до 52, при этом рядом с Карта нужно поставить модификатор {set}, т.е. все карты уникальны.
3. Связи обобщения у тебя использованы некорректно. Т.е. неправильно. Полый треугольник говорит - "это".
Т.е. Игра - это Параметры, Игрок - это Игра, Карта - это Игрок. Звучит явно странно. Я бы пока не трогал обобщение, обобщать начнешь позже. Пока только ассоциации.
4. Игра - включает от 2 до 6 игроков (если колода 52 карты до 8). Чем могут отличаться игроки? Ты говори, что одни реальный, другие компьютерные. Это уже сигнал для некоторого выделения общих понятий в абстрактный класс Игрок. Но не спешим.
Игра включает колоду карт (одна кстати не измена), и распределение этих карт по игрокам. Т.е. Игрок имеет на руках карты. Сколько и какие карты - эту информацию следует хранить. При этом часть карт будут на руках, часть карт в колоде, часть карт в отбое, часть карт в ходе. Всю эту информацию нужно хранить и отображать на экране в процессе игры. Игра будет иметь также тип (определяя набор правил)
5. Каждая карта должна характеризоваться: Мастью, Номиналом. В ходе Игры карта - козырь или не козырь, на руках у игрока, в колоде или в отбое.
Пока у нас есть класс Игра, Игрок, Колода, Карта. Вполне допускаю, что они трансформируются в какие-то визуальные классы, ты же ведь игру будет визуализировать.
Но пока диаграмма новая гораздо хуже исходной.
-
целью курсового является проектирование системы, после чего выполняется ОО разработка приложения
Вот собственно задание для разработки диаграммы классов:
Найти сущности, для которых можно выделить базовый и производный классы. Привести описание базовой (абстрактной) сущности и производных сущностей, указать отличительные черты производных сущностей между собой. Создать иерархию классов, определить базовый и производный классы.
При выполнении работы учесть следующие требования:
•выделить общие методы производных классов, описать их в отдельной таблице;
•предусмотреть хранение объектов иерархии;
•показать на диаграмме классов иерархию классов и связи между классами;
•сгенерировать код по разработанной диаграмме.
Есть ощущение что преподаватель не постарался подобрать задачу таким образом, чтобы выстраивание иерархий и прочие "прелести" естественным образом ложились в решение без притягивания "за уши".
И еще... Генерировать код по одной диаграмме классов это занятие с сомнительной полезностью. Нужно как проработать поведенческую часть системы (варианты использования и диаграммы последовательности)
-
Есть ощущение что преподаватель не постарался подобрать задачу таким образом, чтобы выстраивание иерархий и прочие "прелести" естественным образом ложились в решение без притягивания "за уши".
И еще... Генерировать код по одной диаграмме классов это занятие с сомнительной полезностью. Нужно как проработать поведенческую часть системы (варианты использования и диаграммы последовательности)
Ну собственно я ничего не могу исправить. Никаких объяснений либо указаний от преподавателя по этому поводу не следовало. Есть задача и её необходимо выполнить. И преподавателя не волнует как я это буду делать.
-
Ну собственно я ничего не могу исправить. Никаких объяснений либо указаний от преподавателя по этому поводу не следовало. Есть задача и её необходимо выполнить. И преподавателя не волнует как я это буду делать.
Тогда делай как понимаешь. Ну или как учили. Как-то ведь учили? Вариантов реализации-то ведь много, одну ты уже предоставлял примерно.
Правда, у меня есть вопрос: ты предлагаешь до 5 компьютерных игроков и 1 реальный. Интересно, а каков будет алгоритм выбора карт для хода или отбоя - там же много разных моментов может возникнуть.
-
С диаграммой классов немножко подождём. Оцените сделанную мной ДВИ на эту же тему
-
С диаграммой классов немножко подождём. Оцените сделанную мной ДВИ на эту же тему
Я думаю у тебя должен быть один ВИ - играть в игру, можно сделать уточнение через Играть в простого дурака и т.д.
Все остальные шаги сами по себе не имеют значения.
Просто ты взял и представил некоторую декомпозицию в виде диаграммы ВИ. А это не хорошо. В твоем случае (возможно) отдельными ВИ были бы: регистрация игроков, настройка поведения игроков, загрузка рубашек карт, редакция правил игры, сохранить промежуточные результаты игры (чтобы например вернуться и доиграть)
Т.к. ВИ - это некоторый процесс, проводящий к определенному результату, то при игре в дурака - результат - ничья, проигрыш или выигрыш. Ведь ты же не будет использовать систему, чтобы просто сделать ход, или просто выбрать тип игры. Все эти шаги ты выполняешь в ходе ВЫПОЛНЕНИЯ игры.
Вот описание процесса игры (по самым ключевым позициям) куда как более важно для реализации. А описание процесса можно выполнить в виде сценария ВИ, с помощью диаграммы деятельности, с помощью диаграмма состояния, с помощью диаграммы последовательности.
Но нужны ли они тебе для курсовой? В смысле чтобы они были в курсовой записке? Если нет, то сосредоточься на результате. Но диаграммы помогут общаться с аудиторией.
-
Я думаю у тебя должен быть один ВИ - играть в игру, можно сделать уточнение через Играть в простого дурака и т.д.
Все остальные шаги сами по себе не имеют значения.
Просто ты взял и представил некоторую декомпозицию в виде диаграммы ВИ. А это не хорошо. В твоем случае (возможно) отдельными ВИ были бы: регистрация игроков, настройка поведения игроков, загрузка рубашек карт, редакция правил игры, сохранить промежуточные результаты игры (чтобы например вернуться и доиграть)
Т.к. ВИ - это некоторый процесс, проводящий к определенному результату, то при игре в дурака - результат - ничья, проигрыш или выигрыш. Ведь ты же не будет использовать систему, чтобы просто сделать ход, или просто выбрать тип игры. Все эти шаги ты выполняешь в ходе ВЫПОЛНЕНИЯ игры.
Вот описание процесса игры (по самым ключевым позициям) куда как более важно для реализации. А описание процесса можно выполнить в виде сценария ВИ, с помощью диаграммы деятельности, с помощью диаграмма состояния, с помощью диаграммы последовательности.
Но нужны ли они тебе для курсовой? В смысле чтобы они были в курсовой записке? Если нет, то сосредоточься на результате. Но диаграммы помогут общаться с аудиторией.
все эти диаграммы нужны мне для курсового проекта.
Т.е. даже следующий результат будет неправильным?
-
Ход мыслей твоих понятный. Ты реализуешь функциональную декомпозицию в стиле такой диаграммы. Судя по тому как ты ее активно используешь, может так вас и учат?
Окей.
1. Начать игру в принципе нормально. Что будет результатом начала игры?
- определим тип дурака
- определим число игроков
- раздадим карты
- определим козырь
- определим кто будет ходить первым
Ты все это выделили в отдельные ВИ, правильно ли? Например мы используем твое приложение для того, чтобы определить тип игры? Вроде нет, это часть ВИ Начать игру, ты не случайно все части приинклюдил. Потому вывод:
Оставляем только ВИ Начать игру, а все инклюды убираем (они внутри как шаги ВИ будут описываться).
2. Сделать очередной ход, при этом тут один нападает, другой отбивается, третий подбрасывает. Ход закончится добором карт или определением вышедшего из игры.
Никаких эксендов и инклюдов. Возможно в ходе реализации появится еще что-то. Я бы начал с этого.
Далее можно или описать каждый ВИ (его сценарии), или изобразить их в виде диаграммы деятельности, или диаграммы последовательности. Да запиши последовательность действий в стиле Пользователь делает Система отвечает, будет понятен процесс и необходимые сущности.
Может у тебя есть идея как будет выглядеть программа - нарисуй, полезно. Такую иллюстрацию кадров игры.
Дополнительно можно описать диаграмму автомата игрока и игры в целом. А можно не делать.
Уточни что конкретно сказано по заданию курсовой.
-
Полностью задание на курсовую выглядит следующим образом:
- На основании описания предметной области выделить основные функции рассматриваемой подсистемы. Разработать в среде Enterprise Architect диаграмму Вариантов Использования (Use Case Diagram).
- Детально проанализировать выполнение каждой функции системы, описать для каждой функции основной поток событий. Выделить основные сущности, взаимодействующие между собой, выделить события и ответственности сущностей проектируемой системы. Построить Диаграмму Последовательности.
- Разработать иерархию классов рассатриваемой задачи. Проанализировать сущности системы, построить иерархию наследования и агрегации классов на диаграмме классов (Class Diagram).
- Разбить классы на три группы (Граничные, Управляющие и Сущности).
- Выделить из множества классов системы два класса, которые имеют сложную логику поведения. Для двух выделенных классов описать события, которые влияют на состояния этого класса, определить правила переходов из одного состояния в другое. Построить диаграмму состояний (State Diagram) для этих классов.
- Согласовать 2-3 деятельности (предусловия для варианта использования, операция класса), которые требуют детальной проработки. Разработать для них диаграммы деятельности (Activity Diagram).
Упростил свою диаграмму до следующей:
-
А задание-то множится ;)
Не скажу, что так стало круче и понятнее. Почему, потому что реально не хватает требований, а следовательно, или ты в праве их додумывать, или недостаточно корректно работаешь с исходным описанием задачи.
Предположим - это первое. Видимо предметную область вы выбираете сами.
Что в этой диаграмме несколько не понятно.
1. Зарегистрироваться. Куда, кому, зачем? Компьютеру тоже нужно регистрироваться? Вообще как происходит определение игроков в игре? А зачем регистрироваться игроку-человеку? Игра ведь только с компьютером. Пусть перед началом игры происходит запрос имени игрока-человека, вот ничего и регистрировать не надо.
2. Установить параметры. Где? Для чего, зачем? Компьютер тоже устанавливает параметры? Или это делает Игрок-человек, а если я установил параметры но не играю, я кто? Я могу быть этим установщиком параметров? У меня жена вот блондинка, играть любит в дурака, а вот устанавливать параметры так и не научилась :)
3. Играть в игру. Ну мы к этому вновь пришли, только Играть в игру - будет абстрактным ВИ, а остальные в простого, подкидного переводного - уточнения. Т.е. отношение не экстенд, а расширение generalization
4. Сохранить промежуточные результаты кто может? Видимо только Игрок-человек?
5. Игрок-компьютер разве это не часть разрабатываемой тобой программы? Или это будет реально отдельная программа? Если нет, то может не стоит его выделать как сущность - он только по-моему путается.
Как предложение. Все-таки исходный вариант: Начать игру и Выполнить очередной ход мне нравился больше.
Начать игру - это собственно выполнить все подготовительные действия, в том числе и число конов, если нужно. При этом все делает Игрок (ну или некий установщик): определяет тип игры, сколько игроков от компьютера будет, может выберет их из банка персонажей например или задаст случайный выбор (мало ли может ты на раздевание любишь играть)
Выполнить очередной ход. Тут можно добавить роли: Игрок-нападающий, Игрок-отбивающийся, впрочем можно и не парится. Главное понять человечек - это не реальный пользователь, это абстрактная роль, которую возможный пользователь играет в процессе ВИ (инициирует и является главным получателем двигателем результата)
Сохранить промежуточные результаты или лучше незавершенную игру, тогда появится Загрузить сохраненную неоконченную партию (к примеру)
А вот регистрацию я бы убрал, Не ясны мне параметры и просто Играть в игру в таком контексте.
Далее у тебя будет 2, 3 или 4 варианта использования, думаю пока достаточно. Теперь бери самые ценные и пиши для них основные потоки, как предложено в задании. Вытащим Сущности и построим Диаграмму последовательности.
Вариантов много конечно, но давай попробуй тот, который тебе ближе к сердцу.
-
Вариантов много конечно, но давай попробуй тот, который тебе ближе к сердцу.
пробую
-
Тебе, конечно, кажется, что так диаграмма выглядит солидно. Столько овальчиков. Не то, что просто 4. Но все расширения я бы убрал, потому как уточнения читаются: Установить параметры - это Начать игру, Простой дурак - это Начать игру, но ведь куда как проще записать это прямо в сценарии Начать игру.
Но не буду переубеждать. Советую лишь сделать немного иначе. Установить параметры - убери вообще. Начать игру - сделать абстрактным, а там где у тебя типы игр, все-таки напиши Начать играть в простого дурака, Начать играть в подкидного дурака и т.д.
Просто ВИ именуются отглагольной фразой или глагольной фразой, а не существительным.
-
Тебе, конечно, кажется, что так диаграмма выглядит солидно. Столько овальчиков. Не то, что просто 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 - это класс, который отвечает за параметры игры (количество игроков, тип игры, уровень сложности), добавляет игроков в игру. По сути он не должен выполнять то, что реализовано в методах интерфейса. Он всего лишь должен задавать параметры для его реализации
но дело даже не в этом. Я не могу понять, как строить диаграмму последовательности. Все остальные диаграммы уже построил, правильно/неправильно - но я хотя бы понимал, что я делаю, как, для чего и зачем(ниже примеры). С диаграммой последовательности - полный ноль. Вроде бы всё просто, берёшь поток событий и строишь, но когда доходит до дела - дело не движется. Не могли бы вы объяснить мне, с чего вообще стоит начать?
-
класс Game - это класс, который отвечает за параметры игры (количество игроков, тип игры, уровень сложности), добавляет игроков в игру. По сути он не должен выполнять то, что реализовано в методах интерфейса. Он всего лишь должен задавать параметры для его реализации
Если честно, мне твой ответ не понятен. Понимаешь - интерфейс, как и абстрактный класс только декларирует сигнатуру методов, их реализацию берет на себя конкретный класс. Как может класс реализовывать интерфейс по модели и не делать его по факту? Зачем тогда рисовать диаграмму? Странно.
но дело даже не в этом. Я не могу понять, как строить диаграмму последовательности. Все остальные диаграммы уже построил, правильно/неправильно - но я хотя бы понимал, что я делаю, как, для чего и зачем(ниже примеры). С диаграммой последовательности - полный ноль. Вроде бы всё просто, берёшь поток событий и строишь, но когда доходит до дела - дело не движется. Не могли бы вы объяснить мне, с чего вообще стоит начать?
Диаграммы последовательностей строят для изображения сценария решения какой-то задачи. ДП строят для потоков вариантов использования и они описывают протокол взаимодействия объектов, участвующих в реализации определенного поведения классов.
Например, ты описываешь сценарий Разыграть раздачу (ну первый ход от захода игрока до отбоя или завала другого игрока)
1. В сценарии участвуют Игроки как действующие лица -actor
2. В сценарии участвуют Игроки - как объекты хранящие определенное состояние игры и обладающие каким-то внутренним поведением
3. В сценарии участвуют классы: карты, Игра что-то еще, что также сохраняет некоторое состояние игры и обладает каким то поведением
4. в Сценарии участвуют (должны) классы которые отвечают за управление (но не имеют состояния и ничего не хранят - транзиентные классы) и за взаимодействие с внешними по отношению к программе сущностями - т.е. например GUI - формы, контролы и т.п. - граничные классы
Все это хозяйство и используется для построение диаграмм последовательности и показывают ПОСЛЕДОВАТЕЛЬНОСТЬ обмена сообщениями(вызовами методов) между объектами (инстансами классов) - ghbvths http://www.uml-diagrams.org/sequence-diagrams-examples.html
-
Однако что там в продолжении? Каникулы заканчиваются, времени будет куда как меньше.
Огромное спасибо за помощь. Курсовую сдал, во всём разобрался(в т.ч. и с ДП)
-
Огромное спасибо за помощь. Курсовую сдал, во всём разобрался(в т.ч. и с ДП)
Молодец