1
Задачи студентов / Re: Игра "Дурак"
« : 18 Января 2014, 02:14:31 »Однако что там в продолжении? Каникулы заканчиваются, времени будет куда как меньше.Огромное спасибо за помощь. Курсовую сдал, во всём разобрался(в т.ч. и с ДП)
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Однако что там в продолжении? Каникулы заканчиваются, времени будет куда как меньше.Огромное спасибо за помощь. Курсовую сдал, во всём разобрался(в т.ч. и с ДП)
Ну думаю, преподаватель увидел основные моменты в реализации твоей диаграммы классов. Видимо впечатлился:)класс Game - это класс, который отвечает за параметры игры (количество игроков, тип игры, уровень сложности), добавляет игроков в игру. По сути он не должен выполнять то, что реализовано в методах интерфейса. Он всего лишь должен задавать параметры для его реализации
Мне только не понятен момент реализации интерфейса Play - почему класс Игрок содержит все методы этого интерфейса, а класс Game, который тоже реализует интерфейс Play нет?
Понимаешь, ты тут все в кучу и кислое, и мягкое. От того полное фондю ...
У тебя тут и смысловые классы (предметной области) и классы приложения - все в кучу. Тут же уже распределены ответственности.
Ну не по феншую это...
1. Main_Menu -это вообще группа контролов главного окна приложения например. Да главное окно можно рассматривать как наследника класса Форма, на чем бы ты не делал задача на xaml, wf, в сибилдере борлановском или еще в какой-то swinge - если ты используешь фреймворк или просто библиотеку ты берешь какой-то базовый класс типа window. При этом меню ясный перец - часть этого главного окна приложения, где есть панель меню, есть панель вывода (где все собственно и рендерится) canvas какой-то и т.п. И все это образует богатую собственную структуру со своими атрибутами, событиями и методами. Зачем это указывать здесь - мне не понятно
2. Что такое PLay? по сути это интерфейс, который реализует класс Game - причем тут композиция???
3. Связь между Колодой и Игрой - как минимум в обратном направлении. Это игра включает колоду а не колода включает игру
Правда если рассуждать, что колода может участвовать в разных играх, а вот в игре только одна колода? Но это тоже плохо, так как колода участвует физически только в одной игре/
4. Связь агрегации между Игроком и Картами весьма странная - мало того что она многие ко многим, так и семантически не понятна. Каким образом Игрок выступает агрегатором карт? - Да у игрока на руках в течение Игры может быть от нуля до 36 карт скажем, Понятно что одна и та же карта в течение Игры может переходить в руки разных Игроков, быть в Колоде или в Отбое
На твоей диаграмме я смысла не улавливаю
5. Что это за класс Компьютер чем один компьютер игрок будет отличаться от другого? Может дать более понятное название классу - типа Робот?
6. У Игрока - если уж пишешь методы, почему кроме методов получения нет ничего, а как же метод сделать ход - т.е. положить в игру карту? Ну и т.п. Или мне пока на методы не смотреть?
Если мы пока говорим о смысле, а не о реализации, то тут много недочетов.Оцените пожалуйста смысловое проектирование. Реализацию буду делать, когда со смыслом будет всё в порядке
Если мы пока говорим о смысле, а не о реализации, то тут много недочетов.1. Т.е. вы хотите сказать, что класс Parametrs здесь не нужен?
1. параметры - почему во множественном числе? Одна Игра имеет несколько Параметр, иначе зачем выделять отдельный класс, добавь соответствующие атрибуты к классу Game
2. Game включает от 2 до n(зависит от числа карта) Players. Какой смысл в Players_Count? Во-первых, это характеристика Игры, во-вторых, если и нужен этот атрибут. то он вычисляемый.
3. Что это за атрибуты в Game, каков их смысл?
4. Game ассоциация к Card - вернее композиция. 1- почему композиция, 2- зачем эта связь нужна, 3- почему бы не сделать тогда связь между Game и Card_Deck
5. Не понятно, где будет отражаться ход игры. В ДВИ есть что-то типа сохранения текущей игры?
Однако что там в продолжении? Каникулы заканчиваются, времени будет куда как меньше.С ДВИ вроде бы как справился. Теперь вернёмся к диаграмме классов. Оцените пожалуйста мою следующую попытку. Правильна/неправильна реализация? Чего не хватает/есть ли что то лишнее?
Нет ты не понял. Абстрактный - это то который не имеет собственной реализации. Нет просто начать игру, есть начать одну из возможных.значение понятия "абстрактный" я понимаю достаточно хорошо. Просто хотелось узнать, как в этой диаграмме описать параметры
В начать игру описывается некоторая общая часть, в детализированных особенности. Что-то типа http://www.uml2.ru/faq/use-cases/421-
Тебе, конечно, кажется, что так диаграмма выглядит солидно. Столько овальчиков. Не то, что просто 4. Но все расширения я бы убрал, потому как уточнения читаются: Установить параметры - это Начать игру, Простой дурак - это Начать игру, но ведь куда как проще записать это прямо в сценарии Начать игру.Хорошо. В каком ВИ правильнее будет установить параметры игры(количество игроков например), если ВИ Начать игру будет абстрактным?
Но не буду переубеждать. Советую лишь сделать немного иначе. Установить параметры - убери вообще. Начать игру - сделать абстрактным, а там где у тебя типы игр, все-таки напиши Начать играть в простого дурака, Начать играть в подкидного дурака и т.д.
Просто ВИ именуются отглагольной фразой или глагольной фразой, а не существительным.
Вариантов много конечно, но давай попробуй тот, который тебе ближе к сердцу.пробую
Я думаю у тебя должен быть один ВИ - играть в игру, можно сделать уточнение через Играть в простого дурака и т.д.все эти диаграммы нужны мне для курсового проекта.
Все остальные шаги сами по себе не имеют значения.
Просто ты взял и представил некоторую декомпозицию в виде диаграммы ВИ. А это не хорошо. В твоем случае (возможно) отдельными ВИ были бы: регистрация игроков, настройка поведения игроков, загрузка рубашек карт, редакция правил игры, сохранить промежуточные результаты игры (чтобы например вернуться и доиграть)
Т.к. ВИ - это некоторый процесс, проводящий к определенному результату, то при игре в дурака - результат - ничья, проигрыш или выигрыш. Ведь ты же не будет использовать систему, чтобы просто сделать ход, или просто выбрать тип игры. Все эти шаги ты выполняешь в ходе ВЫПОЛНЕНИЯ игры.
Вот описание процесса игры (по самым ключевым позициям) куда как более важно для реализации. А описание процесса можно выполнить в виде сценария ВИ, с помощью диаграммы деятельности, с помощью диаграмма состояния, с помощью диаграммы последовательности.
Но нужны ли они тебе для курсовой? В смысле чтобы они были в курсовой записке? Если нет, то сосредоточься на результате. Но диаграммы помогут общаться с аудиторией.
Есть ощущение что преподаватель не постарался подобрать задачу таким образом, чтобы выстраивание иерархий и прочие "прелести" естественным образом ложились в решение без притягивания "за уши".Ну собственно я ничего не могу исправить. Никаких объяснений либо указаний от преподавателя по этому поводу не следовало. Есть задача и её необходимо выполнить. И преподавателя не волнует как я это буду делать.
И еще... Генерировать код по одной диаграмме классов это занятие с сомнительной полезностью. Нужно как проработать поведенческую часть системы (варианты использования и диаграммы последовательности)
Хм. Задание довольно однозначно говорит, что делать. Правда, не совсем ясно как, это должно быть отражено в методических указаниях. Ну весьма странно требовать что-то не давая примеров.собственно всё и дело в том, что какие либо методические указания отсутствуют, ровно так же, как и примеры. Я процитировал вам всё, что было в инструкции
Мне, правда, не совсем понятно требование выстраивания иерархии классов. Почему иерархии, а зачем она вообще тут нужна, из чего это следует? Видимо, это следует из понимания задачи преподавателем. Посмотрите на примеры, которые дает вам преподаватель и примеры других курсовых проектов.
Я бы начал с описания процесса игры, а дальше постарался распределить функции (действия) по классам. Получится ли при этом иерархия классов, пока мне не совсем ясно. Это будет ясно после проведения анализа и построения первичной модели классов.
При этом классы так или иначе разделятся на те, которые представляют суть предметной области (т.е. игры в дурака) и те, которые будут являться программными классами: формы, контроллеры, диспетчеры и т.п.