Диаграмма прецедентов игры человек против человека. Компьютерные игры и виртуальная реальность. Современная интернет зависимость. ? доступен режим конструктора, где можно проверить взаимодействие различных свойств

Диаграммы прецедентов.

Среда выполнения

Теория Введение

Для того чтобы более точно понять, как должна работать система, все чаще используется описание функциональности системы через варианты использования (Use Caseили прецеденты). Это самый первый этап в разработке системы – он предваряет этап анализа.

Варианты использования это – описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем.

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

Зачем нужны варианты использования?

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

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

В процессе тестирования, описанные ранее варианты использования, позволяют проще оценить точность реализации требований пользователей и позволяют провести пошаговую проверку этих требований.

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

Нотация uml

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

Любой прецедент должен иметь имя, отличающее его от других прецедентов. Оно должно быть уникально внутри объемлющего пакета. Имя прецедента представляет собой текстовую строку. Взятое само по себе, оно называется простым именем. К составному имени спереди добавлено имя пакета, в котором он находится. Обычно при изображении прецедента указывают только его имя. Имя может занимать несколько строк. На практике для именования прецедентов используют короткие глагольные фразы в активной форме, обозначающие некоторое поведение и взятые из словаря моделируемой системы.

На рис. 1 показано, как на диаграммах изображаются актеры и прецеденты.

рис. 1. Изображение на диаграмме актера и прецедента

Актер. Актер представляет роль, которую играет в данной системе человек, аппаратное устройство или другая система. Как показано на рисунке выше, актеры изображаются в виде человеческой фигуры. Можно определить общие типы актеров, а затем специализировать их отношением обобщения (см. Отношение обобщения), как показано на рис. 2.

рис. 2. Отношение обобщения между актерами

Прецедент .Прецедентом (Usecase) называется описание множества последовательностей действий (включая варианты), выполняемых системой для того, чтобы актер мог получить ценный результат. Графически прецедент изображается в виде эллипса.

Прецеденты организовывают, определив между ними отношения обобщения, включения и расширения. Эти отношения применяют, чтобы выделить некоторое общее поведение (извлекая его из других прецедентов, которые его включают) или, наоборот, вариации (поместив такое поведение в другие прецеденты, которые его расширяют).

Актеров можно связывать с прецедентами только отношениями ассоциации (см. Отношение ассоциации). Ассоциация между актером и прецедентом показывает, что они общаются друг с другом, возможно, посылая или принимая сообщения (рис. 3).

рис. 3. Отношение ассоциации между актером и прецедентом

Отношение обобщения (см. Отношение обобщения) между прецедентами аналогично отношениям обобщения между классами. Это означает, что прецедент-потомок наследует поведение и семантику своего родителя, может замещать его или дополнять его поведение, и, кроме того, может быть подставлен всюду, где появляется его родитель (как родитель, так и потомок могут иметь конкретные экземпляры).

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

Как показано на рис. 4, обобщения между прецедентами изображаются точно так же, как и обобщения между классами - в виде линии с незакрашенной стрелкой.

рис. 4. Обобщения, включения и расширения

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

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

Отношения включения изображаются в виде зависимостей (см. Отношение зависимости) со стереотипом (см. Отношение ассоциации) include. Чтобы специфицировать место в потоке событий, где базовый прецедент включает поведение другого, вы просто пишете словоinclude, за которым следует имя включаемого прецедента (см. ниже).

Направление отношения включения следует от прецедента, который используется, к прецеденту, который его использует. Направление стрелки указывает, что в точке расширения используется включаемый прецедент.

Например, при описании сценария прецедента «Следить за выполнением заказа», который использует другой прецедент «Проверить клиента»:

Основной поток событий. Получить и проверить номер заказа, include (Проверить клиента). Запросить статус каждой части заказа и доложить клиенту.

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

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

Отношение расширения изображают в виде зависимости (см. Отношение зависимости) со стереотипом extend. Точки расширения базового сценария перечисляются в дополнительном разделе. Они являются просто метками, которые могут появляться в потоке базового прецедента.

Например, поток для прецедента «Разместить заказ» можно было бы описать нижеследующим образом.

Основной поток событий . include(Проверить Клиента). Собрать все пункты сделанного клиентом заказа. (Установить приоритет). Отправить заказ на обработку.

В данном примере фраза «Установить приоритет» - это точка расширения. Прецедент может содержать несколько точек расширения (причем каждую по несколько раз), идентифицируемых по именам. При обычных обстоятельствах базовый прецедент в этом примере выполняется без учета приоритетности заказа. Если же поступает приоритетный заказ, то поток будет выполняться, как обычно, до точки расширения (Установить приоритет), а в ней будет выполнен расширяющий прецедент («Разместить срочный заказ»), после чего возобновится работа главного потока. Если определено несколько точек расширения, то расширяющие прецеденты будут последовательно выполняться в собственных потоках.

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

Контекст системы. Любая система содержит внутри себя какие-либо сущности, в то время как другие сущности остаются за ее пределами. Например, в системе проверки кредитных карточек имеются счета, транзакции и механизмы проверки подлинности. В то же время обладатели кредитных карточек и торговые предприятия находятся вне системы. Сущности внутри системы отвечают за реализацию поведения, которого ожидают сущности, находящиеся снаружи. Сущности, находящиеся вне системы и взаимодействующие с ней, составляют ее контекст. Таким образом, контекстом называется окружение системы.

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

Моделирование контекста системы состоит из следующих шагов:

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

Организуйте похожих актеров с помощью отношений обобщения/специализации.

Введите стереотипы для каждого актера, если это облегчает понимание.

Поместите актеров на диаграмму прецедентов и определите способы их связи с прецедентами системы.

Например, на показан контекст системы, работающей с кредитными карточками, где основное внимание уделяется окружающим ее актерам. В первую очередь это Клиенты двух типов («Индивидуальный клиент» и «Корпоративный клиент»), соответствующие ролям, которые играют люди при взаимодействии с системой. В этом контексте показаны и актеры, представляющие другие организации, такие как «Торговые предприятия» (с ними покупатели совершают карточные транзакции, приобретая вещи или услуги) и «Субсидирующие финансовые институты». В реальном мире последние два актера, скорее всего, сами будут программными системами.

рис. 5.Моделирование контекста системы

Тот же метод позволяет моделировать и контекст подсистемы. В прямоугольник на рисунке заключены прецеденты, которые описывают саму систему (которую мы разрабатываем), а актеры являются внешними по отношению к системе сущностями.

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

Рис. 1.1.

Данная схема включает в себя следующие подпроцессы:

1. Инициализация. Содержит алгоритмы определения права первого хода и выдачи начального числа карт всем игрокам.

2. Фаза развития. Содержит алгоритм размещения карт на столе, в виде животных и их свойств.

3. Фаза определения кормовой базы. Содержит алгоритм определения количества фишек еды, которое будет доступно игрокам в «фазу питания».

4. Фаза питания. Содержит алгоритмы кормления и применения свойств животных.

5. Фаза вымирания и получения новых карт. Содержит алгоритмы перемещения ненакормленных животных в сброс, определения количества и выдачи новых карт.

6. Завершение игры. Данная схема содержит алгоритм подсчета очков и определения победителя.

Подробные схемы подпроцессов находятся в приложении Б. Алгоритмическое описание правил игры.

Спецификация требований

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

Бизнес требования:

Игра против компьютера;

Выбор количества игроков.

Функциональные требования:

Требования, предъявляемые к системе, с точки зрения правил игры:

Выдавать карты;

Хранить актуальную информацию о текущих картах на руках игроков и их животных со всеми свойствами, лежащими на игровом поле;

Рассчитывать очередность хода;

Определять и передавать право на первый ход;

Рассчитывать взаимодействие между различными свойствами;

Определять кормовую базу в расчете на количество игроков;

Помещать карты в сброс;

Хранить информацию о картах находящихся в сбросе игрока;

Требования, предъявляемые к системе, с точки зрения игрока:

Начать новую игру;

Положить карту в виде животного;

Положить карту, как свойство;

Пропустить ход;

Взять фишку еды из кормовой базы;

Положить фишку еды на своё животное;

Активировать применить свойство;

Закончить игру.

Модель вариантов использования

Построение диаграммы прецедентов

Визуализация требований реализована с помощью use-case диаграммы (см. рисунок 1.2.).

Рис. 1.2.

Документирование прецедентов

Документирование прецедентов представлено ниже в таблицах (см . таблицы 1.1. - 1.15).

Таблица 1.1. Прецедент «Создать новую игру».

Таблица 1.2. Прецедент «Задать параметры».

Краткое описание	Прецедент позволяет пользователю задать параметры создаваемой игры и начать игровой процесс.
Исполнители
Предусловия	Пользователь нажал кнопку «Новая игра»
Основной поток	1. Игрок выбирает используемый набор карт: Стандартный набор (84 карты) - по умолчанию. Дополнение «Время летать» (+42 карты). 2. Игрок выбирает количество игроков: 2 игрока - по умолчанию. 3 игрока. 4 игрока. 3. Игрок нажимает кнопку «Создать игру». 4. К созданной игре добавляются боты (игроки управляемые компьютером) в количестве, указанном в настройках.
Альтернативные потоки
Постусловия	Параметры настроены.

Краткое описание
Исполнитель
Предусловия
Основной поток	2. Система выводит окно, в котором игроку предоставляется возможность выбрать место, куда сохранить файл в формате txt. 3. Игрок выбирает путь, название файла и подтверждает сохранение. 4. Система сохраняет игру на диск и выдает игроку сообщение. 5. Система предлагает продолжить игру.
Альтернативные потоки	А1. Недостаточно места на диске. a. Система выводит сообщение, что недостаточно места на диске для записи.
Постусловия	Конфигурация и текущее состояние игры сохранены в файл на жестком диске

Таблица 1.4.Прецедент «Продолжить игру».

Краткое описание	Прецедент позволяет продолжить ранее сохраненную игру.
Исполнитель
Предусловия	Наличие на диске файла с сохраненной конфигурацией игры.
Основной поток	1. Игрок запускает систему. 2. Игрок нажимает на кнопку «Продолжить игру». 3. Система выводит окно, в котором игроку предоставляется возможность выбрать файл сохраненной игры. 4. Игрок выбирает файл и подтверждает открытие. А1. Файл неверной структуры. 5. Система восстанавливает конфигурацию, состояние и количество игроков из файла и загружает игровое поле.
Альтернативные потоки	А1. Файл неверной структуры. a. Система выводит сообщение о том, что файл поврежден. b. Система возвращается к 3-ому пункту.
Постусловия	Конфигурация игры восстановлена.

Таблица 1.5.Прецедент «Закончить игру».

Таблица 1.6.Прецедент «Играть».

Краткое описание	Прецедент представляет собой игровой процесс.
Исполнитель
Предусловия	Выполнен прецедент «Создать новую игру».
Основной поток	Начало игры: 1. Система определяет очередность хода (Выполняет жеребьевку на основе ДСЧ). 2. Система передает право первого хода игроку, выбранному в результате жеребьевки. 3. Выполняется прецедент «Получить карты» для новой игры. Фаза развития: А2. Игрок уже пропустил ход. 5. Игрок делает ход. А3. Игрок решает сходить. А4. У игрока нет карт на руках. 6. Система переводит очередь на другого игрока. Фаза определения кормовой базы: 7. Система при помощи ДСЧ определяет количество фишек еды, которое будет доступно на фазе питания. 8. Фишки еды появляются на игровом поле. Фаза питания: А7. Игрок уже пропустил ход. 9. Игрок делает ход. А9. Игрок решает сходить. А5. Игрок нажимает на кнопку «Пропустить ход». 10. Система переводит очередь на следующего игрока. Фаза вымирания: 11. Выполняется прецедент «Получить карты» в фазу вымирания. Завершение игры: 12. Система подсчитывает очки, набранные игроками. 13. Система выводит общий результат всех игроков. 14. Появляются кнопки «Создать новую игру» «Выйти в меню».
Альтернативные потоки	А1. Все игроки получили карты. a. Игра переходит на шаг 3. А2. Игрок уже пропустил ход. А3. У игрока нет карт на руках. А4. Игрок решает сходить. a. Выполняется прецедент «Сделать ход» в фазу развития. А5. Игрок нажимает на кнопку «Пропустить ход». a. Выполняется прецедент «Пропустить ход». А6. Все игроки пропустили ход в фазе развития. a. Игра переходит на шаг 5. А7. Игрок уже пропустил ход. a. Прецедент переходит к шагу 8. А8. У игрока нет карт на столе. a. Выполняется прецедент «Пропустить ход». А9. Игрок решает сходить. a. Выполняется прецедент «Сделать ход» в фазу питания. А10. Все игроки пропустили ход в фазу питания. a. Игра переходит на шаг 9. А11. Прецедент «Получить карты» в фазу вымирания завершен. А11.1. Ни один из игроков не получил новых карт. a. Право первого хода переходит следующему игроку. b. Игра возвращается на шаг 3. А11.1. Ни один из игроков не получил новых карт в фазу вымирания. a. Игра переходит на шаг 10. А12. Игрок набрал больше всех очков. a. Выполняется прецедент «Выиграть». А13. Игрок, вместе с другим игроком, набрал одинаковое количество очков, но больше, чем у остальных игроков. a. Система дополнительно подсчитывает очки по животным находящимся в сбросе игроков. b. Если игрок набрал больше очков, чем соперник - выполняется прецедент «Выиграть». c. Если игрок набрал меньше очков, чем соперник - выполняется прецедент «Проиграть». А14. Игрок набрал меньше очков, чем другой игрок. А15. Игрок нажал кнопку «Создать новую игру». a. Выполняется прецедент «Создать игру». А16. Игрок нажал кнопку «Выйти в меню». a. Выполняется прецедент «Завершить игру».
Точка расширения	· Прецедент «Выиграть». · Прецедент «Проиграть».
Постусловия	Сыграна партия игры.

Таблица 1.7. Прецедент «Получить карты».

Краткое описание	Прецедент позволяет игроку получить новые карты из колоды.
Предусловия	Выполнен прецедент «Создать новую игру».
Основной поток	Для новой игры: 1. Система выдает игроку 6 карт из общей колоды. В фазу вымирания: А1. Все игроки получили необходимое число карт, либо закончились карты в колоде. А2. Ненакормленные животные игрока помещены в сброс и определено количество необходимых для выдачи карт. 1. Система помещает ненакормленных животных в сброс игрока. 2. Система определяет количество необходимых для выдачи карт, равное числу выживших животных игрока + 1. 3. Система выдает игроку одну карту из необходимого количества. 4. Система переводит очередь на следующего игрока. 5. Выполняется прецедент «Получить карты» в фазу вымирания.
Альтернативные потоки	А1. Все игроки получили нужное число карт, либо закончились карты в колоде. a. Прецедент завершается. А2. Ненакормленные животные игрока помещены в сброс и определено количество выживших животных. a. Прецедент переходит к шагу 3. А3. У игрока нет выживших животных и нет карт на руках. А3.1. В колоде нет карт. a. Система определяет количество необходимых для выдачи карт, равное 6. А3.1. В колоде нет карт. a. Выполняется прецедент «Проиграть». b. Прецедент переходит к шагу 4. А4. Игроку выдано всё необходимое количество карт. a. Прецедент переходит к шагу 4.
Постусловия	Игрок получил новые карты.

Таблица 1.8.Прецедент «Выиграть».

Таблица 1.9.Прецедент «Проиграть».

Таблица 1.10.Прецедент «Пропустить ход».

Краткое описание	Прецедент пропускает ход игрока.
Предусловия	Игрок обладает правом хода.
Основной поток	1. Система завершает ход игрока. В текущей фазе игрок больше не будет получать право хода.
Альтернативные потоки	А1. Игра находится на фазе питания, есть фишки в кормовой базе и у игрока есть ненакормленные животные или животные с незаполненным жировым запасом. a. Система выводит сообщение о том, что игрок не может пропустить ход, т.к. обязан взять фишку еды. b. Прецедент завершается.
Постусловия	Игрок пропускает ход и больше не может ходить в текущую фазу.

Таблица 1.11.Прецедент «Сделать ход».

Краткое описание	Прецедент позволяет игроку сделать ход.
Предусловия	Игрок обладает правом хода.
Основной поток	Фаза развития: Фаза питания: А5. Игрок применяет свойство.
Альтернативные потоки	А1. Игрок кладет карту в виде животного. a. Выполняется прецедент «Положить карту в виде животного». А2. Игрок кладет карту, как свойство. a. Выполняется прецедент «Положить карту, как свойство». b. Прецедент «Сделать ход» завершается. А3. В кормовой базе не осталось фишек еды. У игрока нет свойств, которые можно применить. a. Выполняется прецедент «Пропустить ход». А4. Игрок берет фишку еды из кормовой базы. a. Выполняется прецедент «Взять фишку еды». А5. Игрок применяет свойство. a. Выполняется прецедент «Применить свойство». А5.1. У игрока нет свойств, которые можно применить. a. Прецедент «Сделать ход» завершается.
Постусловия	Игрок делает ход в текущую фазу.

Таблица 1.12.Прецедент «Положить карту в виде животного».

Краткое описание	Прецедент позволяет игроку создать новое животное.
Предусловия	Игрок имеет право хода.
Основной поток	А1. Игрок отпустил карту. 2. Игрок перетаскивает карту на свободное место своего игрового поля. 3. Система выделяет место и информирует игрока о том, что карта будет положена в виде животного игрока. А2. Карта находится над другой картой своего игрового поля или поля противника. 4. Игрок отпускает карту. 5. Карта располагается на игровом поле игрока изображением животного вверх.
Альтернативные потоки	А1. Игрок отпустил карту. А2. Игрок отпустил карту над другой картой своего игрового поля или поля противника. a. Выполняется прецедент «Положить карту как свойство» с шага 3. А3. Игрок отпустил карту над игровым полем противника.
Постусловия	На игровом поле текущего игрока появилась карта животного.

Таблица 1.13.Прецедент «Положить карту как свойство».

Краткое описание	Прецедент позволяет игроку наделить выбранное животное свойством.
Предусловия	Игрок имеет право хода.
Основной поток	1. Игрок нажимает на выбранную карту и удерживает её. А1. Игрок отпустил карту. 2. Игрок перетаскивает карту на животное на своем игровом поле. 3. Система выделяет карту животного и информирует игрока о том, что карта будет расположена, как свойство этого животного. 4. Игрок отпускает карту. 5. Над выбранным животным появляется название и признаки свойства.
Альтернативные потоки	А1. Игрок отпустил карту. a. Карта не меняет положения и остается на «руках» у игрока. А2. Игрок отпустил карту на пустое место своего игрового поля. a. Выполняется прецедент «Положить карту в виде животного» с шага 3. А3. Игрок отпустил карту на пустое место игрового поля противника. a. Карта возвращается обратно в «руки» игрока. А4. Игрок отпустил карту над животным противника. a. Если свойство может применяться на животных других игроков, то прецедент переходит к шагу 5. b. Если свойство не может применяться на животных других игроков, то система информирует игрока о том, что данное свойство может быть применено только на своих животных, карта возвращается обратно в «руки» игрока. А5. Свойство на карте относится к парным. a. Система применяет свойство к выбранному животному и запрашивает указать второе животное игрока. b. Игрок указывает 2е животное. c. Система располагает указанные карты рядом друг с другом. d. Над выбранными животными появляется название свойства и соединительная линия между этими свойствами. А5.1. У игрока только 1 животное. a. Система информирует игрока о том, что парное свойство не может быть размещено, т.к. у игрока не достаточно карт животных. b. Карта возвращается обратно в «руки» игрока. А6. На карте имеется 2 свойства на выбор. a. Система выводит модальное окно с вариантами свойств. b. Игрок нажимает на выбранное свойство. c. Прецедент переходит к шагу 5. A7. Свойство не может быть применено дважды на одну карту животного. a. Система информирует игрока о том, что свойство не может быть размещено дважды на одно и то же животное.
Постусловия	На игровом поле игрока к карте животного добавляется название и признаки свойства, которыми оно обладает.

Таблица 1.14.Прецедент «Взять фишку еды».

Краткое описание	Прецедент позволяет игроку накормить одно из его животных.
Предусловия	Игрок имеет право хода.
Основной поток	1. Игрок нажимает на фишку еды в кормовой базе и удерживает её. А1. Игрок отпустил фишку. 2. Игрок перетаскивает фишку еды на животное на своем игровом поле. 3. Система выделяет карту животного и информирует игрока о том, что данное животное получит +1 к запасу пищи. 4. Игрок отпускает фишку еды. 5. У выбранного животного устанавливается отметка о получении фишки еды, запас пищи пополняется на +1 единицу.
Альтернативные потоки	А1. Игрок отпустил фишку. a. Фишка не меняет положения и остается в кормовой базе. А2. Животное игрока уже накормлено. a. Система выделяет карту животного и информирует игрока о том, что данное животное не может получить новую фишку еды, т.к. является полностью накормленным. b. Если игрок отпускает фишку еды, то фишка возвращается в кормовую базу. А3. Игрок отпустил фишку еды вне своего игрового поля. А4. Игрок отпустил фишку вне карты животного на своем игровом поле. a. Фишка возвращается в кормовую базу.
Постусловия	Текущее животное игрока пополняет запас пищи на 1 единицу.

Таблица 1.15.Прецедент «Применить свойство».

Краткое описание	Прецедент позволяет игроку активировать свойство своего животного.
Предусловия	Игрок имеет право хода.
Основной поток	1. Система подсвечивает свойства животного, которые могут быть активированы. 2. Игрок нажимает на доступное свойство. 3. Система обрабатывает выбранное свойство и отображает результат применения на игровом поле, либо сообщает его игроку.
Альтернативные потоки	А1. Использовано свойство «Хищник». a. Система подсвечивает животных, которые могут быть атакованы. b. Игрок выбирает животное, которое собирается атаковать. c. Система проверяет защитные свойства этого животного. d. Если есть защитное свойство - то система переводит ход на игрока, чье животное атаковано, после выбора свойства ход возвращается обратно атаковавшему игроку и прецедент переходит на шаг 3. e. Если свойств нет или оно не сработало - животное считается съеденным и пропадает с поля. Животное атаковавшего игрока получает 2 единицы еды. А2. Свойство может применяться один раз за раунд. a. Система помечает свойство, как использованное, такое свойство больше не может применяться в этом раунде.
Постусловия	Активируется свойство животного, принадлежащего игроку.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Введение

1. Анализ предметной области

1.1 Постановка задачи

1.2 Алгоритмическое представление правил игры

1.3 Спецификация требований

1.4 Модель вариантов использования

1.4.1 Построение диаграммы прецедентов

1.5 Обзор инструментов разработки

1.6 Анализ аналогов

1.7 Выводы по главе

2. Проектирование игры

2.1 Модель проектирования

2.1.1 Архитектура игры

2.2 Разработка графического интерфейса пользователя.

2.2.1 Структура интерфейса

2.2.2 Главное меню

2.2.3 Экран игры

2.3 Реализация интерфейса в среде Unity

2.3.1 Главное меню

2.3.2 Экран игры

2.6 Выводы по главе

3. Разработка

3.1 Перемещение карт

3.2 Игровое поле игрока

3.3 Реализация алгоритма поведения компьютера.

3.4 Выводы по главе

Заключение

Библиографический список

ПРИЛОЖЕНИЕ A. Свойства базовой версии игры «Эволюция».

ПРИЛОЖЕНИЕ Б. Алгоритмическое описание правил игры.

ПРИЛОЖЕНИЕ В. Исходный код алгоритма поведения компьютера.

Введение

За последние 20 лет наблюдаются стремительные тенденции в развитии рынка видеоигр. Начиная свой путь от игровых автоматов, данная сфера постепенно охватила почти все цифровые устройства, которыми ежедневно пользуется каждый из нас: компьютеры, планшеты и мобильные телефоны. Помимо этого, существует также рынок настольных игр, который имеет значительное количество фанатов и интересных проектов. Исследования данной области показали, что около 62% людей, увлекающихся играми, предпочитают играть на компьютере, мобильном телефоне или планшете, около 14% любят играть в настольные игры в компании друзей, остальные 24%, предпочитают и то и другое . Данная разница в показателях говорит о потере интереса к настольным играм, что в свою очередь обусловлено следующими факторами:

· большинство людей не могут поиграть в настольную игру из-за отсутствия времени, места или необходимой компании, так как почти все настольные игры предназначены для игры от 2х до 4х человек;

· нет возможности попрактиковаться в одиночку и найти для себя новые выигрышные стратегии;

· коробка с настольной игрой может занимать много места, а некоторые карточки или фишки могут испортиться или потеряться.

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

В рамках выпускной квалификационной работы рассматривается настольная игра «Эволюция» - это симулятор развития жизни на Земле, основанный на дарвиновском принципе естественного отбора. Каждый игрок развивает собственную популяцию живых существ, наделяя их разнообразными свойствами -- приспособлениями к условиям окружающей среды.

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

В настоящее время существует большое количество различных инструментов для разработки компьютерных или мобильных игр. У каждого из них есть свои особенности, свои плюсы и минусы. Наиболее предпочтительным для реализации игры «Эволюция» оказался движок Unity, по причине его бесплатного распространения, огромного сообщества и возможности создавать кроссплатформенные игры на высокоуровневом языке программирования C#.

Объектом данного исследования является настольная игра «Эволюция», предметом исследования - разработка компьютерной версии данной игры с использованием игрового движка Unity.

Целью работы является разработка компьютерной версии настольной игры «Эволюция» на игровом движке Unity.

Для достижения данной цели необходимо выполнить следующие задачи:

1. Изучить правила настольной игры «Эволюция» и на их основе определить функциональные требования и описать сценарий использования.

2. Спроектировать архитектуру разрабатываемой игры.

3. Разработать дизайн игровых объектов и графический интерфейс пользователя.

4. Реализовать компьютерную версию игры на основе спроектированных моделей используя среду Unity.

На этапе анализа используются такие методы исследования, как абстракция и декомпозиция для представления объекта в виде системы. Для описания взаимодействия всех элементов системы используются объектно-ориентированный анализ и проектирование.

1. Анализ предметной области

1.1 Постановка задачи

«Эволюция» -- это настольная игра, для компании от 2х до 4х человек, где каждый игрок развивает собственную популяцию живых существ, наделяя их разнообразными свойствами необходимыми для выживания. Свойства помогают животным в борьбе за пищевые ресурсы, запасы которых ограничены. Существа, которым не досталось пищи, погибают, а выжившие позволяют ввести в игру ещё больше животных и свойств. Победителем становится тот из соперников, чья популяция будет к концу игры самой развитой и многочисленной .

Животные и их свойства представлены в игре в виде карточек. Где с одной стороны изображен символ животного - ящерица, а с другой различные свойства, такие как: «Хищник», «Водоплавающее», «Симбиоз», «Норное» и т.д. Всего в базовой версии игры существует 19 различных свойств (см. Приложение 1). Каждая карта, лежащая на поле игрока символом животного вверх, является одним из его существ. Свойства подкладываются под животное, таким образом, что бы другим игрокам было видно какими свойствами оно обладает. На некоторых картах указано сразу два свойства: в таком случае игрок должен выбрать, каким из них он хочет наделить своё существо. Когда животное погибает от голода или становится съеденным другим животным со свойством «Хищник», оно вместе со всеми свойствами отправляется в сброс игрока.

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

? фаза развития;

? фаза определения кормовой базы;

? фаза питания;

? фаза вымирания и получения новых карт.

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

Фаза питания. Во время этого этапа игроки по очереди берут из кормовой базы одну фишку еды и используют на любое своё существо, которое ещё не накормлено. Для обычных животных необходима одна фишка еды красного цвета, чтобы оно считалось накормленными, но некоторые свойства увеличивают эту потребность. Также фишки еды можно получить, путем применения таких свойств, как «Хищник» или «Пиратство» в данном случае фишка дополнительной еды будет синего цвета. Накормленное животное не может получить новые фишки еды, кроме случая, когда на нем применяется свойство «Жирового запас», при действии данного свойства фишка еды красного цвета преобразуется в желтую фишку. Если все животные игрока накормлены и их «Жировой запас» заполнен, игрок больше не может брать фишки еды из кормовой базы или получать их в результате применения свойств. Однако если в кормовой базе остались фишки еды и у игрока еще есть ненакормленные животные или животные с незаполненным «Жировым запасом», он обязан брать фишки из кормовой базы. Когда все животные накормлены и их «Жировой запас» заполнен, либо закончилась кормовая база и игроки сыграли все свойства, которые хотели использовать в эту фазу хода - фаза питания завершается.

Рис. 1.1. Алгоритм игрового процесса.

Данная схема включает в себя следующие подпроцессы:

1. Инициализация. Содержит алгоритмы определения права первого хода и выдачи начального числа карт всем игрокам.

2. Фаза развития. Содержит алгоритм размещения карт на столе, в виде животных и их свойств.

3. Фаза определения кормовой базы. Содержит алгоритм определения количества фишек еды, которое будет доступно игрокам в «фазу питания».

4. Фаза питания. Содержит алгоритмы кормления и применения свойств животных.

5. Фаза вымирания и получения новых карт. Содержит алгоритмы перемещения ненакормленных животных в сброс, определения количества и выдачи новых карт.

6. Завершение игры. Данная схема содержит алгоритм подсчета очков и определения победителя.

Подробные схемы подпроцессов находятся в приложении Б. Алгоритмическое описание правил игры.

1.3 Спецификация требований

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

Бизнес требования:

? игра против компьютера;

? выбор количества игроков.

Функциональные требования:

Требования, предъявляемые к системе, с точки зрения правил игры:

? выдавать карты;

? хранить актуальную информацию о текущих картах на руках игроков и их животных со всеми свойствами, лежащими на игровом поле;

? рассчитывать очередность хода;

? определять и передавать право на первый ход;

? рассчитывать взаимодействие между различными свойствами;

? определять кормовую базу в расчете на количество игроков;

? помещать карты в сброс;

? хранить информацию о картах находящихся в сбросе игрока;

? считать итоговые очки и определять победителя;

Требования, предъявляемые к системе, с точки зрения игрока:

? начать новую игру;

? положить карту в виде животного;

? положить карту, как свойство;

? пропустить ход;

? взять фишку еды из кормовой базы;

? положить фишку еды на своё животное;

? активировать\ применить свойство;

? закончить игру.

1.4 Модель вариантов использования

1.4.1 Построение диаграммы прецедентов

Визуализация требований реализована с помощью use-case диаграммы (см. рисунок 1.2.).

Рис. 1.2. Диаграмма прецедентов.

1.4.2 Документирование прецедентов

Документирование прецедентов представлено ниже в таблицах (см . таблицы 1.1. - 1.15).

Таблица 1.1. Прецедент «Создать новую игру».

Таблица 1.2. Прецедент «Задать параметры».

Краткое описание	Прецедент позволяет пользователю задать параметры создаваемой игры и начать игровой процесс.
Исполнители
Предусловия	Пользователь нажал кнопку «Новая игра»
Основной поток	1. Игрок выбирает используемый набор карт: Стандартный набор (84 карты) - по умолчанию. Дополнение «Время летать» (+42 карты). 2. Игрок выбирает количество игроков: 2 игрока - по умолчанию. 3 игрока. 4 игрока. 3. Игрок нажимает кнопку «Создать игру». 4. К созданной игре добавляются боты (игроки управляемые компьютером) в количестве, указанном в настройках.
Альтернативные потоки
Постусловия	Параметры настроены.

Таблица 1.3.Прецедент «Сохранить игру».

Краткое описание
Исполнитель
Предусловия
Основной поток	2. Система выводит окно, в котором игроку предоставляется возможность выбрать место, куда сохранить файл в формате txt. 3. Игрок выбирает путь, название файла и подтверждает сохранение. 4. Система сохраняет игру на диск и выдает игроку сообщение. 5. Система предлагает продолжить игру.
Альтернативные потоки	А1. Недостаточно места на диске. a. Система выводит сообщение, что недостаточно места на диске для записи.
Постусловия	Конфигурация и текущее состояние игры сохранены в файл на жестком диске

Таблица 1.4.Прецедент «Продолжить игру».

Краткое описание	Прецедент позволяет продолжить ранее сохраненную игру.
Исполнитель
Предусловия	Наличие на диске файла с сохраненной конфигурацией игры.
Основной поток	1. Игрок запускает систему. 2. Игрок нажимает на кнопку «Продолжить игру». 3. Система выводит окно, в котором игроку предоставляется возможность выбрать файл сохраненной игры. 4. Игрок выбирает файл и подтверждает открытие. А1. Файл неверной структуры. 5. Система восстанавливает конфигурацию, состояние и количество игроков из файла и загружает игровое поле.
Альтернативные потоки	А1. Файл неверной структуры. a. Система выводит сообщение о том, что файл поврежден. b. Система возвращается к 3-ому пункту.
Постусловия	Конфигурация игры восстановлена.

Таблица 1.5.Прецедент «Закончить игру».

Краткое описание	Прецедент позволяет выйти из системы, либо закончить партию игры.
Исполнитель
Предусловия
Основной поток	Находясь в главном меню: 1. Игрок нажимает кнопку «Выйти». 2. Система запрашивает подтверждение выхода «Да\Нет» 3. Система завершает свое выполнение и выходит на рабочий стол. При нахождении в игре: 1. Игрок нажимает кнопку «Выйти в меню». 2. Система запрашивает подтверждение выхода «Да\Нет». 3. Система выходит в главное меню.
Альтернативные потоки
Постусловия	Игра завершилась.

Таблица 1.6.Прецедент «Играть».

Краткое описание	Прецедент представляет собой игровой процесс.
Исполнитель
Предусловия	Выполнен прецедент «Создать новую игру».
Основной поток	Начало игры: 1. Система определяет очередность хода (Выполняет жеребьевку на основе ДСЧ). 2. Система передает право первого хода игроку, выбранному в результате жеребьевки. 3. Выполняется прецедент «Получить карты» для новой игры. Фаза развития: А2. Игрок уже пропустил ход. 5. Игрок делает ход. А3. Игрок решает сходить. А4. У игрока нет карт на руках. 6. Система переводит очередь на другого игрока. Фаза определения кормовой базы: 7. Система при помощи ДСЧ определяет количество фишек еды, которое будет доступно на фазе питания. 8. Фишки еды появляются на игровом поле. Фаза питания: А7. Игрок уже пропустил ход. 9. Игрок делает ход. А9. Игрок решает сходить. А5. Игрок нажимает на кнопку «Пропустить ход». 10. Система переводит очередь на следующего игрока. Фаза вымирания: 11. Выполняется прецедент «Получить карты» в фазу вымирания. Завершение игры: 12. Система подсчитывает очки, набранные игроками. 13. Система выводит общий результат всех игроков. 14. Появляются кнопки «Создать новую игру» \ «Выйти в меню».
Альтернативные потоки	А1. Все игроки получили карты. a. Игра переходит на шаг 3. А2. Игрок уже пропустил ход. А3. У игрока нет карт на руках. А4. Игрок решает сходить. a. Выполняется прецедент «Сделать ход» в фазу развития. А5. Игрок нажимает на кнопку «Пропустить ход». a. Выполняется прецедент «Пропустить ход». А6. Все игроки пропустили ход в фазе развития. a. Игра переходит на шаг 5. А7. Игрок уже пропустил ход. a. Прецедент переходит к шагу 8. А8. У игрока нет карт на столе. a. Выполняется прецедент «Пропустить ход». А9. Игрок решает сходить. a. Выполняется прецедент «Сделать ход» в фазу питания. А10. Все игроки пропустили ход в фазу питания. a. Игра переходит на шаг 9. А11. Прецедент «Получить карты» в фазу вымирания завершен. А11.1. Ни один из игроков не получил новых карт. a. Право первого хода переходит следующему игроку. b. Игра возвращается на шаг 3. А11.1. Ни один из игроков не получил новых карт в фазу вымирания. a. Игра переходит на шаг 10. А12. Игрок набрал больше всех очков. a. Выполняется прецедент «Выиграть». А13. Игрок, вместе с другим игроком, набрал одинаковое количество очков, но больше, чем у остальных игроков. a. Система дополнительно подсчитывает очки по животным находящимся в сбросе игроков. b. Если игрок набрал больше очков, чем соперник - выполняется прецедент «Выиграть». c. Если игрок набрал меньше очков, чем соперник - выполняется прецедент «Проиграть». А14. Игрок набрал меньше очков, чем другой игрок. А15. Игрок нажал кнопку «Создать новую игру». a. Выполняется прецедент «Создать игру». А16. Игрок нажал кнопку «Выйти в меню». a. Выполняется прецедент «Завершить игру».
Точка расширения	· Прецедент «Выиграть». · Прецедент «Проиграть».
Постусловия	Сыграна партия игры.

Таблица 1.7. Прецедент «Получить карты».

Краткое описание	Прецедент позволяет игроку получить новые карты из колоды.
Предусловия	Выполнен прецедент «Создать новую игру».
Основной поток	Для новой игры: 1. Система выдает игроку 6 карт из общей колоды. В фазу вымирания: А1. Все игроки получили необходимое число карт, либо закончились карты в колоде. А2. Ненакормленные животные игрока помещены в сброс и определено количество необходимых для выдачи карт. 1. Система помещает ненакормленных животных в сброс игрока. 2. Система определяет количество необходимых для выдачи карт, равное числу выживших животных игрока + 1. 3. Система выдает игроку одну карту из необходимого количества. 4. Система переводит очередь на следующего игрока. 5. Выполняется прецедент «Получить карты» в фазу вымирания.
Альтернативные потоки	А1. Все игроки получили нужное число карт, либо закончились карты в колоде. a. Прецедент завершается. А2. Ненакормленные животные игрока помещены в сброс и определено количество выживших животных. a. Прецедент переходит к шагу 3. А3. У игрока нет выживших животных и нет карт на руках. А3.1. В колоде нет карт. a. Система определяет количество необходимых для выдачи карт, равное 6. А3.1. В колоде нет карт. a. Выполняется прецедент «Проиграть». b. Прецедент переходит к шагу 4. А4. Игроку выдано всё необходимое количество карт. a. Прецедент переходит к шагу 4.
Постусловия	Игрок получил новые карты.

Таблица 1.8.Прецедент «Выиграть».

Таблица 1.9.Прецедент «Проиграть».

Таблица 1.10.Прецедент «Пропустить ход».

Краткое описание	Прецедент пропускает ход игрока.
Предусловия	Игрок обладает правом хода.
Основной поток	1. Система завершает ход игрока. В текущей фазе игрок больше не будет получать право хода.
Альтернативные потоки	А1. Игра находится на фазе питания, есть фишки в кормовой базе и у игрока есть ненакормленные животные или животные с незаполненным жировым запасом. a. Система выводит сообщение о том, что игрок не может пропустить ход, т.к. обязан взять фишку еды. b. Прецедент завершается.
Постусловия	Игрок пропускает ход и больше не может ходить в текущую фазу.

Таблица 1.11.Прецедент «Сделать ход».

Краткое описание	Прецедент позволяет игроку сделать ход.
Предусловия	Игрок обладает правом хода.
Основной поток	Фаза развития: Фаза питания: А5. Игрок применяет свойство.
Альтернативные потоки	А1. Игрок кладет карту в виде животного. a. Выполняется прецедент «Положить карту в виде животного». А2. Игрок кладет карту, как свойство. a. Выполняется прецедент «Положить карту, как свойство». b. Прецедент «Сделать ход» завершается. А3. В кормовой базе не осталось фишек еды. У игрока нет свойств, которые можно применить. a. Выполняется прецедент «Пропустить ход». А4. Игрок берет фишку еды из кормовой базы. a. Выполняется прецедент «Взять фишку еды». А5. Игрок применяет свойство. a. Выполняется прецедент «Применить свойство». А5.1. У игрока нет свойств, которые можно применить. a. Прецедент «Сделать ход» завершается.
Постусловия	Игрок делает ход в текущую фазу.

Таблица 1.12.Прецедент «Положить карту в виде животного».

Краткое описание	Прецедент позволяет игроку создать новое животное.
Предусловия	Игрок имеет право хода.
Основной поток	А1. Игрок отпустил карту. 2. Игрок перетаскивает карту на свободное место своего игрового поля. 3. Система выделяет место и информирует игрока о том, что карта будет положена в виде животного игрока. А2. Карта находится над другой картой своего игрового поля или поля противника. 4. Игрок отпускает карту. 5. Карта располагается на игровом поле игрока изображением животного вверх.
Альтернативные потоки	А1. Игрок отпустил карту. А2. Игрок отпустил карту над другой картой своего игрового поля или поля противника. a. Выполняется прецедент «Положить карту как свойство» с шага 3. А3. Игрок отпустил карту над игровым полем противника.
Постусловия	На игровом поле текущего игрока появилась карта животного.

Таблица 1.13.Прецедент «Положить карту как свойство».

Краткое описание	Прецедент позволяет игроку наделить выбранное животное свойством.
Предусловия	Игрок имеет право хода.
Основной поток	1. Игрок нажимает на выбранную карту и удерживает её. А1. Игрок отпустил карту. 2. Игрок перетаскивает карту на животное на своем игровом поле. 3. Система выделяет карту животного и информирует игрока о том, что карта будет расположена, как свойство этого животного. 4. Игрок отпускает карту. 5. Над выбранным животным появляется название и признаки свойства.
Альтернативные потоки	А1. Игрок отпустил карту. a. Карта не меняет положения и остается на «руках» у игрока. А2. Игрок отпустил карту на пустое место своего игрового поля. a. Выполняется прецедент «Положить карту в виде животного» с шага 3. А3. Игрок отпустил карту на пустое место игрового поля противника. a. Карта возвращается обратно в «руки» игрока. А4. Игрок отпустил карту над животным противника. a. Если свойство может применяться на животных других игроков, то прецедент переходит к шагу 5. b. Если свойство не может применяться на животных других игроков, то система информирует игрока о том, что данное свойство может быть применено только на своих животных, карта возвращается обратно в «руки» игрока. А5. Свойство на карте относится к парным. a. Система применяет свойство к выбранному животному и запрашивает указать второе животное игрока. b. Игрок указывает 2е животное. c. Система располагает указанные карты рядом друг с другом. d. Над выбранными животными появляется название свойства и соединительная линия между этими свойствами. А5.1. У игрока только 1 животное. a. Система информирует игрока о том, что парное свойство не может быть размещено, т.к. у игрока не достаточно карт животных. b. Карта возвращается обратно в «руки» игрока. А6. На карте имеется 2 свойства на выбор. a. Система выводит модальное окно с вариантами свойств. b. Игрок нажимает на выбранное свойство. c. Прецедент переходит к шагу 5. A7. Свойство не может быть применено дважды на одну карту животного. a. Система информирует игрока о том, что свойство не может быть размещено дважды на одно и то же животное.
Постусловия	На игровом поле игрока к карте животного добавляется название и признаки свойства, которыми оно обладает.

Таблица 1.14.Прецедент «Взять фишку еды».

Краткое описание	Прецедент позволяет игроку накормить одно из его животных.
Предусловия	Игрок имеет право хода.
Основной поток	1. Игрок нажимает на фишку еды в кормовой базе и удерживает её. А1. Игрок отпустил фишку. 2. Игрок перетаскивает фишку еды на животное на своем игровом поле. 3. Система выделяет карту животного и информирует игрока о том, что данное животное получит +1 к запасу пищи. 4. Игрок отпускает фишку еды. 5. У выбранного животного устанавливается отметка о получении фишки еды, запас пищи пополняется на +1 единицу.
Альтернативные потоки	А1. Игрок отпустил фишку. a. Фишка не меняет положения и остается в кормовой базе. А2. Животное игрока уже накормлено. a. Система выделяет карту животного и информирует игрока о том, что данное животное не может получить новую фишку еды, т.к. является полностью накормленным. b. Если игрок отпускает фишку еды, то фишка возвращается в кормовую базу. А3. Игрок отпустил фишку еды вне своего игрового поля. А4. Игрок отпустил фишку вне карты животного на своем игровом поле. a. Фишка возвращается в кормовую базу.
Постусловия	Текущее животное игрока пополняет запас пищи на 1 единицу.

Таблица 1.15.Прецедент «Применить свойство».

Краткое описание	Прецедент позволяет игроку активировать свойство своего животного.
Предусловия	Игрок имеет право хода.
Основной поток	1. Система подсвечивает свойства животного, которые могут быть активированы. 2. Игрок нажимает на доступное свойство. 3. Система обрабатывает выбранное свойство и отображает результат применения на игровом поле, либо сообщает его игроку.
Альтернативные потоки	А1. Использовано свойство «Хищник». a. Система подсвечивает животных, которые могут быть атакованы. b. Игрок выбирает животное, которое собирается атаковать. c. Система проверяет защитные свойства этого животного. d. Если есть защитное свойство - то система переводит ход на игрока, чье животное атаковано, после выбора свойства ход возвращается обратно атаковавшему игроку и прецедент переходит на шаг 3. e. Если свойств нет или оно не сработало - животное считается съеденным и пропадает с поля. Животное атаковавшего игрока получает 2 единицы еды. А2. Свойство может применяться один раз за раунд. a. Система помечает свойство, как использованное, такое свойство больше не может применяться в этом раунде.
Постусловия	Активируется свойство животного, принадлежащего игроку.

1.5 Обзор инструментов разработки

В качестве среды для разработки компьютерной игры «Эволюция» был выбран игровой движок Unity. Unity - это мультиплатформенный инструмент для разработки 2D/3D игр и интерактивного контента. На сегодняшний день доступна 5 версия движка, в которой реализованы все самые последние 3D и 2D технологии. Одной из таких технологий является UI System, которая содержит классы, значительно упрощающие работу с 2D элементами. . Данная технология наиболее подходит для создания игрового пространства и интерактивного интерфейса компьютерной игры «Эволюция». Базовый набор UI элементов и их назначение представлены в таблице 1.16.

Таблица 1.16. Базовый набор UI элементов в Unity.

Название UI элемента	Назначение	Отображение
	Представляет собой абстрактное пространство в котором производится настройка и отрисовка UI. Все элементы UI должны быть дочерними для Сanvas.
	Область для группировки элементов. Может содержать фоновое изображение или цвет.
	Представляет собой графический объект загруженный на сцену, который может использоваться для декорации уровня, в качестве, 2D объекта игры, иконки и т.д.
	Компонент Text, также известный как Label, имеет область для ввода текста, который будет отображен. Есть возможность задать шрифт, его стиль и размер. Присутствуют опции для установки параметров выравнивания; настройки горизонтального и вертикального переполнения, которые управляют поведением текста, когда он не влезает по ширине или высоте в отведенный ему прямоугольник.
	Кнопка состоит из картинки и текста, а так же специального скрипта кнопки. Текст расположен, как отдельный элемент внутри кнопки. Можно настроить отображение кнопки в различных состояниях: обычное состояние, состояние при наведении, состояние при нажатии и состояние при блоке кнопки. Содержит событие нажатия кнопки.
	Данный объект позволяет пользователю выбрать одну опцию из списка опций.
	Данный объект позволяет пользователю прокручивать изображение или другую область которая слишком велика и не входит в указанные рамки.
	Использует для выбора числовых значений из указанного диапазона.
	Комплексный компонент, включающий в себя область для отображения контента, вертикальный и горизонтальный scrollbar для прокрутки контента внутри этой области.
	Представляет собой переключатель, который позволяет пользователю включить, либо выключить опцию. Кроме того можно объединить несколько переключателей в группу, в тех случаях, когда только один из вариантов должен быть выбран.
	Предоставляет возможность пользователю вводить текст. Содержит 2 события: изменение текста и конец изменения текста.

Одной из главных особенностей игрового движка Unity является удобный и полностью настраиваемый интерфейс, который сочетает в себе редактор сцен, игровых объектов, скриптов, анимации, а также предоставляет возможность мгновенного запуска и отладки разрабатываемого приложения или игры . На рисунке 1.3. изображен скриншот окна редактора. Все ресурсы и объекты могут перемещаться при помощи Drag-and-Drop методов.

Рис. 1.3. Окно редактора Unity.

Ниже подробней описаны используемые вкладки окна редактора:

1. Scene View. В данном окне можно перемещаться по игровому миру, передвигать и вращать объекты сцены, а также изменять их масштаб.

2. Game View. Представляет собой изображение игрового мира, отрисованное из установленной камеры. Здесь можно посмотреть, как будет выглядеть игра для игрока. Также можно запустить и проверить игру.

3. Project Window. В данном окне можно работать со всеми ресурсами проекта: изображениями, шрифтами, скриптами, сохраненными объектами, сценами и т.д. Unity поддерживает огромное количество различных форматов мультимедии.

4. Hierarchy Window. Представляет собой иерархию игровых объектов расположенных на текущей сцене.

5. Inspector Window. Позволяет просмотреть, изменить и удалить свойства\скрипты текущего выбранного объекта. А также добавить объекту новые свойства\скрипты.

6. Toolbar. Содержит инструменты для трансформации игровых объектов в окне Scene View, Кнопки запуска и остановки приложения в окне Game View, выпадающее меню Layout которое отвечает за расположение окон в редакторе.

7. Console Window. Обеспечивает вывод в лог сообщений, предупреждений и ошибок.

Unity также обладает следующими преимуществами:

1. Открытость документации. Unity поставляется с полной документацией и примерами по каждой функции движка, к которой можно обратиться в любой момент.

2. Сообщество разработчиков. Unity обладает активным онлайн сообществом, готовым помочь новым пользователям. Также разработчики Unity Technology часто прислушиваются к пользователям и добавляют по их запросам новые функции в игровой движок. Кроме этого существует множество официальных и неофициальных видео-курсов помогающих разобраться с аспектами разработки игр на данном игровом движке .

3. Кроссплатформенность. Один и тот же код, написанный на движке Unity, с минимальными изменениями может быть перенесен на различные платформы (PC, Mac, Android, iOS, Web, игровые консоли). Это огромный плюс, который сокращает время на разработку игры в несколько раз.

4. Asset Store. Unity имеет собственный магазин, где можно найти огромное количество различных плагинов и ресурсов для создания игры. Разумеется, какие-то из них бесплатные, какие-то платные, но все они собраны в одном месте с удобным поиском и возможностью загрузить, интегрировать и получить сразу рабочий функционал .

В качестве инструмента для написания программного кода была выбрана среда Visual Studio 2015. В данной работе Visual Studio используется как лучшая альтернатива MonoDevelop, которая в игровом движке Unity представлена по умолчанию.

В качестве языка программирования был выбран высокоуровневый язык программирования C# .

1.6 Анализ аналогов

В ходе исследования предметной области был найден единственный на данный момент рабочий аналог компьютерной реализации настольной игры «Эволюция». Интерфейс данного аналога изображен на рисунке 1.4.

Рис. 1.4. Интерфейс пользователя игры-аналога.

Данный аналог обладает следующими преимуществами:

? доступен режим игры против 1го компьютера на 3х уровнях сложности. В данном варианте сложность проявляется в предоставлении «форы» компьютеру (компьютер отыгрывает один раунд без участия игрока, после этого присоединяется игрок);

? доступен режим по сети 1 против 1;

? доступен режим конструктора, где можно проверить взаимодействие различных свойств;

? понятный и интуитивный интерфейс пользователя, основанный на point-and-click;

? существует запись в журнал игрового процесса, всех ходов игрока и его соперника;

? возможность просмотреть код (массив содержащий параметры текущей игры: количество карт в колоде, очередность хода и список карт находящихся на руках у игроков);

? существует возможность посмотреть карты находящиеся в сбросе игрока.

Данный аналог обладает следующими недостатками:

? игра расположена в социальной сети «вконтакте» из-за чего отсутствует возможность играть без подключения к интернету;

? представленная игра помимо обычного набора карт содержит карты из дополнения «время летать», что вызывает недовольство среди игроков, так как отсутствует выбор набора карт.

Выделим основные критерии для сравнения аналога и разрабатываемой нами игры (см. таблица 1.17.):

1. Существует ли возможность запускать игру в оффлайн режиме против компьютера?

2. Присутствует ли возможность играть онлайн через интернет?

3. Правила игры соответствуют оригиналу игры?

4. Присутствует возможность выбора количества игроков?

5. Есть возможность изменить уровень сложности компьютера?

Таблица 1. 17. Сравнение критериев игры аналога и разрабатываемой игры.

По сложившимся результатам можно сделать вывод, что разрабатываемая игра будет улучшена в том плане, что она позволит играть без подключения к интернету. И будет присутствовать возможность выбора количества игроков, от 2 до 4х. Таким образом, данный анализ помогает выявить достоинства и недостатки игры аналога и оценить конкурентное преимущество разрабатываемой игры.

1.7 Выводы по главе

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

2. Проектирование игры

2.1 Модель проектирования

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

алгоритм интерфейс файл пользователь

Таблица 2.1. Соответствие прецедентов и классов игры.

Прецедент	Название класса	Описание класса
Создать новую игру		Отвечает за отображение UI элементов на экране и взаимодействие пользователя с ними.
		Отвечает за загрузку экранов.
Задать параметры		Статический класс для хранения настроек игры.
		Основной класс игры, реализует игровую логику и управляет всеми процессами и элементами в игре, а также позволяет сохранить и загрузить игру.
Продолжить игру
Закончить игру
	PlayerController	Отвечает за инициализацию игроков. Управляет очередностью хода.
		Отвечает за переход между фазами игры.
Получить карты		Хранит информацию о типе игрока, его картах на руках, на столе и в сбросе.
		Отвечает за хранение и отображение карт находящихся «на руках» у игрока.
		Представляет собой колоду карт.
		Отвечает за хранение и отображение карт находящихся в сбросе у игрока.
		Представляет собой карту с изображением на ней двух свойств.
		Хранит информацию о свойстве, изображенном на карте. Название, описание и изображение этого свойства.
Выиграть
Проиграть
Пропустить ход
Сделать ход
Положить карту в виде животного
		Представляет собой карту на столе игрока, положенную в виде животного.
Положить карту, как свойство
		Отвечает за хранение и отображение карт находящихся «на столе» игрока.
		Представляет собой свойство карты расположенное на столе игрока, как признак конкретного животного.
Взять фишку еды
		Отвечает за генерацию, хранение и отображение фишек еды в фазу питания.
		Представляет собой фишку еды определенного цвета (Красную, Синею, Желтую), которая используется при кормлении животного игрока.
Применить свойство
		Отвечает за обработку выбранного свойства и отображение результата на игровом поле.

2.1.1 Архитектура игры

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

Рис. 2.1. Диаграмма классов. Часть 1.

Рис. 2.2. Диаграмма классов. Часть 2.

Рис. 2.3. Диаграмма классов. Часть 3.

2.2 Разработка графического интерфейса пользователя

2.2.1 Структура интерфейса

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

Рис. 2.4. Структура интерфейса.

2.2.2 Главное меню

Главное меню (см. рис. 2.5.) игры состоит из названия игры, фонового изображения и 3х кнопок: «Новая игра», «Продолжить игру» и «Выход». При нажатии на кнопку «Новая игра» открывается модальное окно настройки параметров игры (см. рис. 2.6.), которое содержит переключатели для выбора набора карт (базовый набор установлен по умолчанию и не доступен для выбора), выбор количества игроков, а также кнопку «Начать игру», при нажатии на которую загрузится игровое поле.

Рис. 2.5. Главное меню

Рис. 2.6. Окно задания параметров игры.

2.2.3 Экран игры

Экран игры состоит из 2х областей: фронтальной области и игрового поля. Фронтальная область (см. рис. 2.7.) содержит верхнее меню с кнопками: «Показать\скрыть игровой лог», «Сохранить игру», «Выйти в меню». Также в верхней части фронтальной области располагается окно с игровым логом, текстом уведомлений и информацией о текущей фазе в которой находится игра. Внизу фронтальной области располагается панель с картами, находящимися “на руках” у игрока. Данная панель может быть свернута и развернута по щелчку мыши. При двойном нажатии на любую карту животного оно масштабируется по центру экрана (см. рис. 2.8.).

Рис. 2.7. Фронтальная область.

Рис. 2.8. Подробный просмотр карты.

Игровой стол (см. рис. 2.9.) находится в 3D пространстве и содержит 2 области: игрока и соперника. Данные области служат для расположения карт животных и их свойств. Между данными областями находится кормовая база с фишками еды. Также на игровом столе располагаются кнопки выбора игроков, колода с указанием оставшегося количества карт, и кнопка «Сброс», при нажатии на которую открывается модальное окно содержащее карты животных, которые погибли в результате фазы вымирания.

Рис. 2.9. Экран игры. Игровой стол.

2.3 Реализация интерфейса в среде Unity

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

На основе спроектированного графического интерфейса в Unity было создано 2 сцены:

· «Menu» - представляет собой главное меню игры.

· «Game» - представляет собой игровое пространство, на котором непосредственно происходит весь игровой процесс.

Все сцены, так же как и любой другой ресурс сохраняются в папку Assets проекта и могут быть открыты в окне редактора. На рисунке 2.10. показаны сохраненные сцены проекта.

Рис. 2.10. Ресурсы проекта - игровые сцены.

Для захвата и отображения объектов в игровом пространстве используются камеры. Камера может быть установлена в двух режимах: ортографический и перспективный. При использовании ортографической камеры изображение объектов не уменьшается при увеличении дистанции. Данный режим используется для создания двухмерных и изометрических миров, во всех остальных случаях используется перспективная камера (см. рис. 2.11.).

Рис. 2.11. Настройки камеры в редакторе Unity.

Для создания игры было принято использовать систему UI игрового движка Unity. Все элементы UI располагаются на полотне (Canvas), которое определяет размещение 2D объектов в игровом пространстве. За это отвечает свойство Render Mode, которое содержит следующие значения:

Screen Space - Overlay. В данном режиме полотно масштабируется по размерам экрана и отрисовывается без связи со сценой или камерой (UI будет отрисован даже в том случае, когда на сцене нету камеры). В случае изменения размера окна, полотно будет растянуто под размеры экрана. Полотно будет рисоваться поверх всех остальных графических элементов.

Screen Space - Camera. В данном режиме полотно рисуется на плоскости перпендикулярной взгляду камеры, на некотором расстоянии от точки взгляда. Размер полотна не меняется с изменением расстояния, оно всегда масштабирется, чтобы заполнять разрез пирамиды видимости у камеры (camera frustrum view). Интерфейс будет заслоняться любыми 3D элементами, которые находятся перед плоскостью интерфейса.

World Space. В данном режиме полотно располагается в мировых координатах и является плоским 3D объектом.

2.3.1 Главное меню

На рисунке 2.12. показана сцена главного меню и иерархия объектов, расположенных на данной сцене. Полотно на котором располагаются UI элементы имеет свойство RenderMode с установленным значением Screen Space - Overlay. Такие элементы, как: ParamsWindow, ExitConfirm, ContinueGame - являются модальными окнами и по умолчанию находятся в неактивном состоянии.

Рис. 2.12. Сцена «Главное меню» и иерархия игровых объектов

MenuManager - пустой GameObject содержащий класс для управления меню.

Settings - пустой GameObject содержащий класс с настройками игры. Данный объект передается при загрузке сцены игры, чтобы иметь информацию о выбранных настройках.

2.3.2 Экран игры

На рисунке 2.13. показана сцена «Игровое поле» и иерархия объектов данной сцены. Элементы фронтальной области располагаются на полотне со свойством Render Mode равном Screen Space - Overlay, это означает, что отображение данных элементов не зависит от камеры. Игровое поле представляет собой полотно, расположенное в 3D пространстве и повернутое под углом 30 градусов относительно камеры. Для отображения данной сцены используется перспективная камера.

Рис. 2.13. Сцена «Игровое поле» и иерархия объектов сцены.

Общее представление сцены игры, то, как она выглядит для игрока показано на рисунке 2.14.

Рис. 2.14. Отладка сцены «Игровое поле».

2.4 Структура файла сохранения игры

Файл сохранения должен быть представлен в удобном для чтения программы формате и содержать информацию о всех текущих состояниях игры:

· текущие настройки игры;

· текущая фаза игры;

· текущее право хода;

· карты, находящиеся на руках у игроков;

· карты животных, находящиеся на столе у игроков;

· карты животных, находящиеся в сбросе у игроков;

· свойства и связи между животными;

· информация об использованных свойствах;

· информация о накормленных животных;

· количество фишек еды в кормовой базе;

· карты находящиеся в колоде.

Для описания данной информации наиболее подходящим является формат JSON. JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером . Примерное содержание файла изображено на рисунке 2.15.

Рис. 2.15. Структура файла сохранения игры.

2.5 Проектирование поведения компьютера

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

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

Подобные документы

Разработка компьютерной игры "Эволюция" с помощью игрового движка Unit. Сравнение критериев игры-аналога и разрабатываемой игры. Разработка графического интерфейса пользователя. Настройки камеры в редакторе Unity. Структура файла сохранения игры.

дипломная работа , добавлен 11.02.2017


Исследование базовых концепций программирования приложений под операционную систему Windows. Изучение истории создания универсального языка программирования Си. Разработка графического пользовательского интерфейса. Обзор правил игры и алгоритма работы.

курсовая работа , добавлен 09.11.2012


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

дипломная работа , добавлен 27.10.2017


История развития языка программирования Java. История тетриса - культовой компьютерной игры, изобретённой в СССР. Правила проведения игры, особенности начисления очков. Создание интерфейса программы, ее реализация в среде Java, кодирование, тестирование.

курсовая работа , добавлен 27.09.2013


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

методичка , добавлен 24.10.2012


Описание алгоритма хода ЭВМ в режиме "пользователь-компьютер" в игре "Морской бой". Описание совокупности классов, их полей и методов. Разработка интерфейса и руководства пользователя по проведению игры. Листинг программы, написанной на языке Java.

курсовая работа , добавлен 26.03.2014


Обоснование необходимости разработки программы для игры "Тетрис". Математическая и графическая части алгоритма. Выбор языка и среды программирования. Отладка текста программы, разработка интерфейса пользователя. Тестирование, руководство пользователя.

курсовая работа , добавлен 17.01.2011


Исследование общих правил игры в шашки, инструкции пользователя и программиста. Характеристика основных алгоритмов, исполняющих задачи класса Life Widget. Оценка ходов компьютера и человека. Построение дерева поиска лучшего хода исходя из оценки функций.

контрольная работа , добавлен 20.12.2012


Особенности программирования аркадных игр в среде Python. Краткая характеристика языка программирования Python, его особенности и синтаксис. Описание компьютерной игры "Танчики" - правила игры, пояснение ключевых строк кода. Демонстрация работы программы.

курсовая работа , добавлен 03.12.2014


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

Диаграммы прецедентов частично описывает use case – прецедент использования проектируемой системы, давая частичное описание частичного применения системы с точки зрения условного внешнего обозревателя (за которым – в идеале - стоит согласованная точка зрения участников работ). При этом описание фокусируется на том, что должна делать система по отношению к своему внешнему окружению (периферии), а не то на том, как она эта делает.

Иначе говоря, диаграмма есть частичная спецификация.

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

Заметим, в случае достаточно крупных программных систем мы не используем термин «алгоритм», например – неуместно говорить об «алгоритме текстового редактора (редактирования текста)» и т.п. Причина ясна – в сложных случаях мы можем надежно описать (проанализировать, проверить и т.п.) некоторые ветки алгоритма верхнего уровня, но не сам законченный алгоритм, предполагающий законченное описание всех возможных веток.

Иначе говоря, сценарий – это и частичная алгоритмизация.

Пример. Запись пациента на прием в поликлинику.

Данный простейший пример предполагает примерно следующий скрытый за ним сценарий прецедента (естественно сделать его комментарием к имени прецедента):

"Пациент звонит в поликлинику для записи к врачу в целях профилактики. Регистратор поликлиники находит в журнале регистрации ближайший свободный период, согласует время с пациентом и фиксирует его в журнале»

Make Appointment (согласовать назначение [у врача]) – имя прецедента. Patient (пациент) – роль человека. Связь между актором и прецедентом – ассоциация коммуникации (для краткости коммуникация – в виде обмена сообщениями)

Пример 2. Уточнение предыдущей диаграммы (посредством ее расширения).

Вторая диаграмма отражает больше деталей ситуации. Здесь появляются новые акторы: Scheduler – регистратор, Doctor – врач, Clerk – служащий, и новые прецеденты CancelAppointment – отменить прием, RequestMedication – запросить лечение и PayBill – оплатить счет.

Крупные программные среды UML-моделирования имеют средства поддержки версий. В таком случае мы можем считать представлением (view) группу диаграмм, относящихся либо к последней версии, либо ко всем. Второе, очевидно, предпочтительно.

Уже самый первый пример ставит перед нами «главный вопрос всех времен и народов»: «Ну и зачем мне эти диаграммы прецедентов?» Еще более популярный вариант: «Да вообще кому они нужны - все эти диаграммы!». В процессе обучения его лучше не скрывать в себе, но переадресовать себе самому, перефразируя и конкретизируя. Кому именно и когда именно и зачем именно они полезны?

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

Мораль стара – полезно встать на место другого, посмотреть на мир его глазами.

Но обратимся снова к конкретному примеру. Зачем нужно такое уточнение? Для человека, хорошо знакомого с предметной областью (доменом) – в данном случае, системой здравоохранения – в этой диаграмме нет новой информации. Для него она неявно содержится уже в первом прецеденте, выводиться из него. Однако, во-первых - не все люди одинаково хорошо знакомы с данным доменом. Во-вторых – они могут иметь разные мнения как на сам домен, так и на то, какие его черты должны быть отражены в разрабатываемой системе. Наконец, мы можем в дальнейшем попросту забыть то, на чем договорились.

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

Описание коммуникаций. Диаграммы последовательностей [системы]- sequence diagrams

Диаграммы последовательностей некоторой системы объектов - артефакт модели (часть документированного описания) прецедентов, используемый для частичного описания поведения некоторой системы объектов в виде возможных, основных (успешных) и альтернативных сценариев.

Главное назначение таких диаграмм - отображение событий, пере­даваемых исполнителями системе через ее границы. Каждая из них дает схематическое описание сценария прецедента в виде последовательности событий, генерируе­мых внешними акторами - и компактное, обозримое (для анализа, контроля и т.п.) описание событий, генери­руемые внутри самой системы. Иначе говоря – диаграмма пытается ответить скорее на вопрос: «какие главные события инициируются извне», чем как именно система реагирует на внешние сигналы. Не точно и полно - лишь по мере возможности.

Отметим здесь новую трактовку старого поведенческого подхода (бихевиоризм, от behavior - поведение), базового для кибернетики. Строение системы важно – но не само по себе, а лишь постольку, поскольку оно обеспечивает нужное поведение, верную реакцию на внешние сигналы. Не так важно, как устроена система – важнее, чтобы она имитировала нужное поведение. Устройство разнообразных т.н. «умных» машин «виртуально» - это касается машин как реальных, так и виртуальных. Проще говоря – оно не должно и не может походить на настоящее. А поведение – реально.

В кибернетических терминах, все внутренние подсистемы (связанные с описанием объектов данной системы) рассматриваются как "черный ящик", а сама система – как полупрозрачный, или «серый ящик». Как и ранее, то, что находиться вне ящика считается относящимся к логике , внутри ящика – к реализации системы (скрытой в устройстве ящика – касается ли она определения структуры связанных с ним данных или методов). В «полупрозрачном» случае, имеется в виду реализация самого верхнего уровня.

Вспомним, что классы и объекты в ООП описывают – соответственно, на более и менее абстрактном уровне – статическое представление модели. Они содержат указание на методы – именованную ссылку на определение правил (алгоритмов) потенциального поведения объектов, при этом скрывая фактическое поведение объектов, по отношению друг к другу. Проще говоря, они отвечают скорее на вопрос «как может вести себя [один] данный объект», а не на вопрос о том, как ведут себя объекты – вместе, в целом.

Поведение системы объектов рассматривается здесь как скоординированное взаимодействие объектов, фиксируемое в виде временнóй шкалы исполнения методов посылки сообщений - трассы сообщений. Течение времени отображается координатой «сверху вниз», посылающие сообщения объекты (источники) левее, получающие сообщения – правее (приемники сообщений). По возможности.

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

В данном случае речь снова идет о трассе вызовов – точнее, о трассе инициирующих такие вызовы сообщений. Но уже в более сложном случае системы объектов, изменяющих (через вызов метода объекта-источника) состояний объекта-приемника (а также, возможно, в качестве побочного эффекта – и состояний других объектов). Изменение состояния и трактуется теперь как «событие в жизни объекта».

Здесь по-прежнему есть внешние объекты, инициирующие внутренние процессы обмена сообщениями, но в более сложных для описания случаях нет единого главного «командира» и иерархии подчиненности.

Пример. Бронирование места в гостинице.

сообщение

Внешний объект, инициирующий поток сообщений – окно регистрации Reservation window. Объект Reservation window посылает сообщение makeReservation() {забронировать } соответствующей службе сети отелей HotelChain. Та, в свою очередь пересылает сообщение makeReservation() отелю Hotel. Если в гостинице есть свободные номера, объекта Hotel вызывает методы Reservation {забронировать номер) и Confirmation {подтвердить заказ}.

Каждая из пунктирных вертикальных «линий жизни» (lifeline), представляет заполненное событиями время потенциального существования некоторого объекта – в виде изменения состояний других объектов и изменения его собственных состояний. Каждая стрелка описывает вызов метода посылки сообщения. Стрелка идет от отправителя к приемнику сообщения, выделяя полосу активности (период обработки сообщения - activation bar) на временной координате.

На диаграмме объект Hotel вызывает самого себя (self call) для определения доступности номера. Если условие IsRoom выполняется, Hotel создает объекты Reservation и Confirmation. Звездочка на вызове available означает итерацию – циклический вызов (для того, чтобы выяснить, доступен ли номер для всех дней предполагаемого пребывания гостя). Выражение в квадратных скобках означает условие (предикат).

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

Диаграммы кооперации (взаимодействий) –

collaboration diagrams

Диаграммы кооперации, как и диаграммы последовательностей, относятся к диаграммам описания взаимодействия. Они содержат ту же информацию, что и диаграммы последовательностей – но в ином ракурсе, фокусируясь не на описании процессов коммуникации между объектами (в виде последовательности вызовов), но на определении роли объектов в качестве источника и приемника сообщений. Словом, здесь мы пытаемся ответить не на вопрос «как» происходит коммуникация фактически, но кто и кому может пересылать сообщения.

Пример. Тот же - бронирование места в гостинице.

объект

сообщение

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

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

Описание строения. Диаграммы состояний. Statechart diagrams.

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

Вспомним общие положения. Конечный автомат – модель возможного реагирования (в виде прямой и обратной реакции) объекта моделирования на внешние события - изменения во внешней среде (окружении, периферии, ситуации, контексте и т.п.)

Понятие автомата - центральное в понимании логической схемы функционирования компьютера как устройства, выполняющего пошагово одну-единственную операцию (как и любое иное), имитирующую операцию аппликации (применения функции к аргументу). Неявно, понятие автомата лежит в начале основных программистских концепций – например, трактовке программ как преобразователя потоков и/или последовательных файлов. Но в данном случае, нам стоит вспомнить концепции более ранние. Не о компьютерах или программах, но о не менее знаменитой собаке академика Павлова…

В общем случае, автомат реагирует на такие изменения среды

• явно определяемым изменением состояния своего внутреннего, невидимого извне и скрытого внутри него устройства; такие внутренние состояния в теории автоматов именуются, но не описываются.
• изменением состояния среды – неявным, поскольку наличие таких состояний среды подразумевается, но не сами состояния не определяются.

Обратной связью называется изменение поведения (внутреннего состояния) автомата, возникающее (косвенно) в результате его собственных действий по изменению среды.

В явном виде, определяется коммуникация автомата со средой, в виде

• множества возможных входных и выходных сообщений. Их роль в теории автоматов выполняют элементарные сигналы, буквы (в ООП, естественно – объекты).
• двух функций (или одного оператора), определяющих по текущим входному сообщению и внутреннему состоянию выходное сообщение и следующее внутреннее состояние. Соответственно называемых функцией выхода и функцией перехода (transition).

Если (и когда ) входные сообщения отсутствуют, автомат описывает источник (или отправитель, sender)подготовленных им ранее выходных сообщений. Если (и когда ) отсутствуют выходные сообщения, автомат описывает приемник (адресат, получатель) и обработчик выходных сообщений.

• ввод – набор на клавиатуре - [предположительно] действующего (активного, верного) общего идентификатора пользователя - вроде номера паспорта; в данном случае – это номер клиента системы социального страхования SSN (social security number),
• ввод [предположительно] действующего персонального идентификатора пользователя как клиента данного банка PIN (personal id number)
• отсылку данной информации на проверку (validation).

Описание возможных [внутренних] состояний авторизации начинается с именования. Getting SSN – получить SSN, Getting PIN – получить PIN, Validating – проверка и Rejecting – отказ, в случае неудачи сценария «по умолчанию». Далее определяются переходы из состояния в состояние, для каждой пары состояний и всевозможных комбинаций сообщений.

Что описывается в теории множеств в терминах фундаментального понятия декартового произведения множеств.

Существенным отличием диаграмм состояний в UML (по сравнению с классической теорией автоматов) является возможность описания структурных состояний , т.е. состояний, которые сами являются системами. Тонким моментом является здесь переход сообщений через границы системы. Контуры принятого здесь UML подхода намечены нами при обсуждении понятия прецедента.

Но возможности языков всегда обусловлены необходимостью решения некоторой проблемы и прежде чем «влезать внутрь ящика (черного или серого)» стоит задуматься – какой именно? Классическая теория сложности вычислений определяет «информационный взрыв» - обилие информации, с которой человек не может справиться (manage) в терминах экспонент (например 2 n). Что не подлежит сомнению, но… В практике программирования уже полиномы (в данном случае, минимально n 2) – уже в общем случае не управляемы – не контролируемы, анализируемы, проверяемы и т.п. Для того, чтобы взглянуть в лицо хаосу, достаточно вообразить себе автомат со 50 состояниями. Кажется, немного… если бы не 2500 возможных переходов.

Это касается любых диаграмм – бинарных и иных графов, вне зависимости от интерпретации, типа задачи описания и способа ее решения. Надеюсь, сейчас для нас становиться куда более предметным не только понимание происхождения UML, но и всех иных структурных методов в программировании и в целом – назначение математических формализмов. А ты говорил - «пустая абстракция, оторванная от жизни»… Чьей жизни? - Только не от жизни описателя моделей.

Обратим внимание на интересную особенность примера. Авторизация – не вещь (физический объект), не система таких объектов, но процесс . И вместе с тем, конечно – объект нашего текущего внимания и описания.

Диаграммы деятельности –

activity diagrams.

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

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

Наиболее заметные отличия видны на следующем примере.

Пример. Схема работы банкомата (ATM Machine) по обслуживанию клиента (Customer) банка (Bank).

По-прежнему условия (предикаты) изображаются ромбами, методы ([пользовательские] операторы) – прямоугольниками с закругленными концами.

Сторожевое условие (guard condition) трактуется здесь как проверка необходимости выполнения неправильного хода событий – т.е. неудачного сценария. По сути – необходимости обработки логического исключения (exception) (вызванного сбоем «времени логики», а не «времени исполнения»).

Плавательные дорожки (swimlines) разделяют «пловцов» - объекты, чьи методы исполняются. Как видно из примера, фактически они трактуются здесь как субъекты деятельности , исполняющие некоторую общую работу.

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

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

· Банкомат и банк вместе составляют систему-сервер, выполняющую работу для инициирующего ее клиента (актора) – имеющего приоритет, отраженный в порядке следования субъектов.

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

Конечно, для данной предметной области больше подходит первая, характерная для современных «клиент-серверных» подходов интерпретация.

Мы привыкли рассматривать подобные диаграммы как законченные описания. Но в контексте рассматриваемого подхода, существует еще одна важная трактовка диаграмм, исходящая из возможностей описателя. Можно предположить, что мы находимся на той стадии разработки, когда взаимоотношение субъектов еще не определены или нам неизвестны. Как-то (пока) надо описать.

Немедленным следствием возникающего здесь «разделения труда» между несколькими акторами, является необходимость согласования возникающего параллелизма выполнения действий. На диаграмме такое согласование обозначается новым типом ветвления – вилка (fork) и соединения (join) процессов.

Параллелизм – крайне сложная тема, допускающая много толкований. В контексте необходимости описания предметной области, естественно продолжить тему разделения труда между субъектами исходя из необходимости достижения общего результата. В этом «многопроцессорном» варианте порядок действий неважен.

Исходя из возможностей описателя, возможна иная трактовка. Мы знаем, что данный процесс когда-то должен начаться и когда-то завершиться. Но [пока] не знаем точно порядка действий.

Задача описания предметной области.

Модель предметной области отображает концептуальные классы – основные, с точки зрения моделирую­щего, классы понятий, относящиеся к предметной области (не к программной реализации).

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

Формально говоря, в рассматриваемом подходе построение диаграмм классов в основных своих принципах мало отличается от принятого в «обычном ООП». Самую существенную разницу привносят рассмотренные нами выше мотивы разделения труда. По мере возможности, программист соучаствует в предыдущих этапах, но отвечает за этап программной реализации. Внутри него, он волен выделять классы, исходя из необходимости решения внутренних проблем программной реализации – в рамках своей роли, он этого делать не может. Классы предметной области заданы реалиями предметной области.

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

Напомним (в качестве пищи для размышлений), что исторически понятие [петли] обратной связи (feedback loop) появилось в кибернетике (точнее, в теории автоматов) именно в связи с необходимостью формального описания сложного поведения, характерного для живых существ. А не реальных автоматов , наиболее частых (в силу простоты) примеров в сегодняшней литературе по программированию.

Модель пред­метной области отображает:

· объекты предметной области или концептуальные классы;

· ассоциации между концептуальными классами;

· атрибуты и операции концептуальных классов (имена свойств и методов).

Пример диаграммы классов. Схема оплаты заказов.

Пример подразумевает примерно следующий (успешный) сценарий оплаты (payment) заказа (order) клиентом (customer) некоторой торгово-транспортной компании: «Клиент, заказавший список товаров (см. item – характеризацию свойств товара в отдельном пункте заказа) может оплатить заказ кредитной карточкой (credit), наличными (cash) или банковским чеком (check)»

Обратим внимание, что диаграммы классов, помимо самих классов, описывают в виде графа и разнообразные реальные связи (association) между классами.

Иначе говоря – при описании структуры классов мы применяем идущий от теории множеств и отношений (relation) реляционный подход, рассмотренный нами ранее при освоении реляционных баз данных. Отметим здесь возможность указания кратности связей, описывающих точнее (по сравнению с «один» и «много»), сколько объектов (экземпляров, instance) одного класса может находиться в данном отношении с другим классом. 0..1 - не более одного, 1 - ровно 1, 1* - не менее одного и т.п.

Некоторую путаницу здесь обычно вносит разнообразие типов связей. Здесь связь (association) – любая возможная связь между классами, вне зависимости от того, какое дальнейшее отношение между объектами оно подразумевает.

Одни из них – как и ранее - относятся к описанию структуры данных. Таковы, например, связь Customer-Order и связь «часть-целое» (aggregation, отношение агрегирования) между классами Order и OrderDetail.

Другие (generalization – обобщение) – к описанию взаимосвязи классов по наследованию. См. в примере связь класса Payment с подклассами Cash, Check и Credit. Это статическая (фиксированная) связь между классами , подразумевающая возможность динамической (изменяемой) связи между объектом и классом . В каждый момент времени объект относим к некоторому конкретному классу – но затем эта принадлежность объекта может измениться. Что собственно и отличает понятие класса в ООП от типа в процедурном программировании.

Закладки на будущее. Помимо «просто связей», своеобразной особенностью UML является возможность определения иных, пользовательских типов связей, а также группировки классов в пакеты – по иным, отличным от рассмотренных нами ранее соображениям. В том числе, будущим, пока нам неизвестным.

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

Диаграммы объектов. *

Диаграммы объектов используются значительно реже диаграмм классов. Фактически, мы спускаемся здесь до уровня программной реализации. Применять их полезно, когда графическое представление помогает обратить внимание участников разработки на те особенности реализации, которые тяжело распознать по тексту программы.

В качестве неформальной мотивации, легко представить температуру в коллективе при возвращении из отпуска программиста, не посвятившего коллег в особенности реализации. Как известно, по закону Паркинсона (он же закон падения бутерброда) необходимость коррекции программного кода происходят как раз во время отсутствия написавшего его программиста! Во всяком случае, такие примеры надолго запоминаются…

Пример 1. Рекурсивные связи

Здесь предполагается иерархия классов, описывающих подразделения (departments) университета.

Пример 2. Унаследованные статические связи.

mathStat, math, statistics, appliedMath, mathEd – объекты, ссылки на класс Department

Вероятно, более сложным и важным примером является описание далеко не всегда очевидных возможностей изменения в программе принадлежности одного объекта к различным классам – относительно иерархии наследования.

Диаграммы компонент и диаграммы развертывания –

Component and deployment diagrams

Компонента [архитектуры программной системы] – модуль, часть [текста] программы, традиционно связываемый с автоматизацией, алгоритмической обработкой программного кода (программы как данные). При использовании UML они трактуются как физические аналоги диаграмм классов и описываются аналогичным образом. Иначе говоря, диаграммы компонентов - формальный аналог диаграмм классов, предназначенный для описания программной архитектуры, строения программной системы.

И в этом качестве – не столь важны для прикладного программиста. Но еще раз обратим здесь внимание на один важный момент. Мы привыкли, что задачи программирования ставятся заказчиком - задаются извне программирования. Но, несомненно, весьма большая часть задач рождается внутри самого программирования – касается ли они software или hardware, программной или аппаратной его части. Так, изначально модули трактовались скорее как единицы компиляции (compilation, сборки) – но проложили путь объектному программированию в качестве универсального способа моделирования. То, что в модульном программировании трактуется как именованная константа (имя модуля обозначает фиксированный интерфейс и его реализацию), в объектном становиться именем переменной (имя объекта обозначает переменный интерфейс и реализацию).

В компонентном программировании понятие компоненты идет еще дальше и имеет более четкое определение. Просто – именованный, но [пока] никак не реализованный интерфейс. Родившись в среде чисто системных задач (особенно важно здесь вспомнить задачу поддержки версий), она становиться здесь инструментом решения любых задач (повышенной сложности).

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

Пример. Физическая среда поддержки продажи недвижимости.

Здесь Real Estate Server и Bank Server – сервера агентства по продаже недвижимости и ипотечного банка, предоставляющего ссуду своему клиенту (customer) в ответ на его заявление (application). PC – клиентский компьютер, позволяющий пользователю разрабатываемой нами программной системы делать запросы как в банк, так и агентство, в соответствии с имеющейся в его базе данных списком (listing) предложений.

Аппаратные устройства представляются узлами (nodes). Каждая программная компонента связана с некоторым узлом и представляется на диаграмме в виде прямоугольника с двойной петлей в верхнем левом углу. Отдельным значком (кружок) выделен интерфейс – набор сервисных функций (возможностей поддержки) предоставляемых соотвествующимим системами клиенту.

Концептуальное понимание термина прозрачно. Клиент не может знать сложное внутренное устройство систем (хотя и должен знать, что оно сложно и потому ценить труд разработчиков). Больше того. Не будучи высоквалифицированным специалистом, он не должен вмешиваться в их функционирование – причем даже тогда, когда для этого есть физическая возможность . Это дает косвенное определение моральных ограничений, честного клиента и попросту – культурного человека . Не хакера.

Однако, для нормального функционирования всей системы он вправе получить доступ к интерфейсу – описание которого ему, скорее всего, известно лишь в форме инструкции пользователя в неформальном текстовом или графическом виде, т.е. на обычном человеческом языке. Проще говоря, кто-то все-таки должен ему обяснить азы - «что, как и почему».

По сути единственным существенным нововедением здесь является специальное обозначение символа для интерфейса , рассматриваемого отдельно от его программной или физической реализации (см. обсуждение выше). По всей видимости, Unified Modelling Language еще нуждается в дальнейшей унификации. Что ж, все люди – люди, в том числе и создатели языков моделирования.

Но закончить наш обзор UML я хотел бы не этим – но обращением к читателю.

1. Концептуализация системы: идея приложения – игра на развитие памяти.

2. Аналитическая модель – это точное, четкое представление задачи, позволяющее отвечать на вопросы и строить решения.

3. Проектная модель – это реализация решений задач, понятых на этапе анализа.

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

Сложность. Игра должна поддерживать стандартные варианты сложности (например, легкий, средний, трудный). Пользователь должен иметь возможность настроить свою сложность игры.

Уровни. Вне зависимости от типа сложности игра должна поддерживать уровни. Уровень определяет максимальное количество фигур на экране. Т.е. количество фигур – это функция от уровня.

Подсказки. В случае затруднения выбора фигуры игрок может выбрать подсказку.

База данных. По возможности в системе должна храниться информация об игроках.

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

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

Модель вариантов использования, прецедентов

Рассмотрим прецеденты Игра и Настройка сложности.

Основными артефактами при моделировании прецедентов являются диаграммы прецедентов, прецеденты, диаграммы последовательностей прецедентов. Многие новички в области ООА/П при моделировании прецедентов делают акцент лишь на диаграммах прецедентов, что по своей сути не приносит существенной пользы. Необходимо понимать, что диаграммы отображают лишь имена , названия прецедентов , а не сами прецеденты.

Рисунок 1. Диаграмма прецедентов

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

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

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

Идентификация конечных событий. Также следует определить конечные события. Для прецедента Настройка сложности таковым будет установка параметров сложности игры, здесь все понятно. Для прецедента Игра ситуация иная: вариант использования Игра может продолжаться до тех пор, пока игра не будет выиграна или проиграна. Конечным событием прецедента Игра выберем событие, когда игроку надоест данный сервис, т.е. выход из игры.

Предварительные рекомендации : в качестве прецедентов следует выбирать только полные транзакции, несущие смысл для пользователя системы. Хотя ведущие методологи уже определили стиль написания прецедентов, это вовсе не означает, что мы должны строго следовать ему (или не следовать лишь по причине несогласия). Не забудем, что прецеденты отвечают на вопрос “что”, а не на вопрос “как”, т.е. не надо в прецеденте описывать каким образом достигается тот или иной результат.

Прецедент Игра.

Прецедент Настройка сложности.

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

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

Рисунок 2. Диаграмма последовательностей прецедента Игра

Рисунок 3. Диаграмма последовательностей прецедента Настройка сложности

Анализ приложения

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

Модель классов приложения.

Одним из артефактов анализа приложения являются диаграммы классов приложения. Это означает, что в моделях нежелательно отображать классы, относящиеся к уровню реализации (списки, деревья и т.п. абстрактные типы данных).

Классы. В качестве источника потенциальных классов выделим прецеденты, но это не единственный источник. Обычно классы соответствуют существительным. Например, из предложения – система (экран) отображает фигуру, можно отобрать потенциальные классы Система (экран), Фигура.

Проблема: одна часть речи может плавно перетекать в другую. Не стоит долго мучиться над вопросом соотношения ключевых слов со списком потенциальных классов. Модели классов будут уточняться со временем, и абсолютно корректную модель построить сразу, чаще всего, невозможно. Хотя это и не означает, что это бесполезное занятие.

Выбираем потенциальные классы для нашего примера: игрок, игра, фигура, сложность, уровень, эллипс, прямоугольник.

Замечание: вообще говоря, для каждого прецедента обычно приходится строить свою модель классов. Но так как приложение небольшое, то построим единую модель классов для обоих прецедентов.

Свойства. Определим свойства классов. Свойства – это такие концепции, которые не обладают собственной индивидуальностью. В данном случае, например, цвет фигуры (но если бы мы строили графический редактор, то цвет, скорее всего, обладал бы такой индивидуальностью). Такие свойства можно найти в списке потенциальных классов.

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

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

Ассоциации. Далее между выбранными классами установим связи – ассоциации. Связи можно извлечь из тех же прецедентов, глаголы – это потенциальные связи. Иначе говоря – как и ранее - проблема понимания слов естественного языка в том или ином качестве остается.

Например, игра определяется сложностью.

Рисунок 4. Диаграмма классов приложения

На диаграмме присутствуют две ассоциации - игра определяется сложностью , фигура определяется сложностью .

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

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

Рекомендация: вообще говоря, диаграмма классов строится параллельно с диаграммой взаимодействия, на диаграмме взаимодействия отображаются сообщения, посылаемые между объектами. Сообщение – это вызов функции класса. Так что операции классов лучше брать из диаграмм взаимодействия.

Обобщения. Далее организуем структуру иерархии классов по наследованию путем выявления общей структуры. Общую структуру можно выделить у классов Эллипс, Прямоугольник и т.д. в класс Фигура . К такому обобщению можно прийти из двух соображений. Обобщение снизу вверх: в суперклассе Фигура должны быть определены общие черты для классов Эллипс, Прямоугольник (координаты, цвет, время жизни). Конкретизация сверху вниз: выделим из описания игры именные группы, состоящие из различных обстоятельств с указанным существительным. Например, «фигура прямоугольник» или «фигура эллипс».

Рисунок 5. Диаграмма классов приложения с обобщением

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

Резюме: модели классов полезны не только для определения структур данных. Прослеживание моделей классов позволяет выразить некоторые виды поведения, т.е. прецеденты.

Модель состояний приложения

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

Выделим классы, обладающие разными состояниями. Таковым, например, является класс Игра . Этот класс может находиться в состояниях Игры, Победы и т.д.

Выделим состояния класса Игры . Для этого мысленно представим себе объект класса Игра, пытаясь понять различия этого объекта в состояниях Игра, Победа, Проигрыш . В состоянии Игра объект прорисовывает фигуру, а в остальных состояниях – нет. Иначе говоря, ассоциация между классами Игра и Фигура присутствует в состоянии Игра , а в состояниях Победа и Проигрыш эта ассоциация отсутствует (тем самым состояния Победа и Проигрыш для меня неотличимы).

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

Выделение событий. После выделения состояний необходимо выделить события, которые вызывают переход между состояниями.

· Событие сигнала – это событие получения или отправки сигнала.

· Событие изменения – это событие, вызванное выполнением логического выражения.

· Событие времени – это событие, вызванное достижения момента абсолютного времени или истечением временного интервала.

Событие изменения Выполнение условий игры переводит объект класса Игра из состояния Игры в состояние Победа . Событие изменения Невыполнение условий игры переводит объект класса Игра из состояния Игры в состояние Проигрыш . Тем самым разные события приводят объект в разные состояния.

Событие – это точки на линии времени, а состояния – это интервалы.

Рисунок 6. Диаграмма состояний для класса Игра

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

Диаграмма состояний объекта – это автомат (граф), вершинами которого являются состояния, а ребрами – события.

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

Проектирование приложения

Проектирование системы – это выбор высокоуровневой стратегии решения задач.

Модель взаимодействий приложения

Вернемся к прецедентам, потому как модели взаимодействий строятся на модели прецедентов. Артефакт диаграммы последовательностей прецедентов отвечали на вопрос “что”, в данном разделе построим диаграммы последовательностей, отвечающие на вопрос “как” при решении задач варианта использования Игра.

Обратимся к сценарию прецедента Игра, инициализация которого происходит после события запуска этого сервиса Игроком.

Инициализация игры. Согласно шаблонам проектирования необходим класс-контроллер, который будет принимать на себя “огонь” событий от пользователя. Пусть класс Игра отвечает за запуск игры.

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

Определение значений атрибутов будущей фигуры. Так как фигура определяется атрибутами (тип, цвет, положение), а значения атрибутов должны быть случайны, то необходим класс, который будет отвечать за случайное образование значений атрибутов – класс Алгоритм . Значения атрибутов зависят от сложности игры. Иначе говоря, здесь мы замечаем связывание классов Алгоритм и Сложность - т.е. значения атрибутов есть функция от Сложности. Тем самым Сложность передается классу Алгоритм в качестве параметра. Значит, Сложность надо передать в качестве параметра при запуске игры.

Создание фигуры. Параметры будущей фигуры определены, но какой класс будет отвечать за создание фигуры? Здесь применим шаблон проектирования Creator, согласно которому создавать будет тот класс, который обладает большей информацией об объекте, таковым является класс Алгоритм. Класс Алгоритм возвратит классу Игра положение новой фигуры. После создания фигуры класс переходит в режим ожидания выбора пользователем фигуры.

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

Рисунок 7. Диаграмма последовательностей прецедента Игра

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

ПОСЛЕСЛОВИЕ ДЛЯ ХАКЕРОВ. ОСНОВНОЙ РЕСУРС.

Конечно, не все из сказанного выше было для тебя на 100% ясно и на 100% полезно - в смысле 100% готовности завтра же приступить к разработке сложных программных систем 100% надежности. Вроде так актуальных сегодня систем задач 100% защиты информации «от где-то спрятавшихся злобных хакеров». Я не верю, что стопроцентные гарантии здесь возможны - и нужны вообще. Во всяком случае, эта скромная методичка не ставила перед собой недостижимых целей. Это всего лишь инструкция для еще не квалифицированного пользователя (клиента) языка UML . Написанная, по мере возможности, «по-человечески».

Никто не совершенен – ни ты, «клиент образования», ни я, твой «сервер». Ты недоучился или я недоучил, теперь уже поздно искать виноватых. Здесь мы сделали лишь первую итерацию в процессе подготовки. Конечно, для достаточно надежного программирования сложных систем нужно еще углубляться, специализироваться, еще многое знать и уметь. Это ясно. Но данное пособие – о другом. Здесь я хотел сделать не шаг вперед, но шаг назад – показать тебе, что сначала нужно суметь заново понять уже пройденное . Зачастую – недопонятое, пройденное мимо.

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

Но все мы поначалу беремся сделать 1) все 2) сразу 3) идеально. И это нормально – пока не сильно касается других, близких и дальних. Момент истины наступает, когда наш идеальный сценарий заканчивается неудачей. Тогда одни начинают учиться работать всерьез, а те, что покруче - искать виноватых. «Недоучили, не так и не тому учили» – в общем, недодали ресурсов. Милый, а ты сам – сильно вкладывался? Не скрыты ли за твоей непоколебимой верой в безграничную мощь собственной интуиции надежда на авось и… обычная лень, нежелание трудиться?

Hack-work – это поденщина, рутинная и халтурная работа, а «крутой хакер» – человек крайне ненадежный. Бесплатно или за хорошие деньги, но если такой возьмется за разработку уже не игрушечных систем – реального вреда будет не меньше, чем от любого «злобного хакера» (как правило – виртуального). Расплачиваться же тогда будут все. Реально. И интересно тогда уже точно никому не будет.

Дело тут не в самих деньгах, договорах и иных артефактах. Это лишь обозначения общественного договора, знаки доверия и договоренностей между людьми. Просто на будущее вещи приходиться фиксировать – чтобы не забыть прошлого. Основной ресурс – ресурс человеческих взаимоотношений. Если не приумножать его, тогда действительно – кому нужна вся эта математика? It’s a deal -договорились?

Я надеюсь, теперь ты лучше понимаешь то, на что и кого именно я делал свой расчет. Вот такая математика…

СПИСОК ЛИТЕРАТУРЫ

1. Гради Буч, Джеймс Рамбо, Ивар Джекобсон – Язык UML. Руководство пользователя. Издательство ДМК Пресс, 2007 г., 496 с. Классика от создателей UML.

2. Крэг Ларман – Применение UML 2.0 и шаблонов проектирования. Издательство Вильямс, 2008 г., 736 с. Отражает доминирующий сегодня инженерный подход к ОО АП.

3. Дж. Рамбо, М. Блаха - UML 2.O. Объектно-ориентированное моделирование и разработка. 2-е изд. - СПб.: Питер, 2007. - 544 с. То же, с чуть более практическим уклоном.

4. Rational University – материалы академической программы корпорации IBM (см. http://www.ibm.com/ru/software/info/students/): Essentials of visual modeling, Fundamentals of Rational Rose. Сокровищница примеров, тестов и лабораторных работ.

Дополнительная литература.

1. Мартин Фаулер. UML. Основы. Издательство Символ-Плюс, 2006 г., 192 с. Краткий справочник.

2. Rational University – материалы академической программы корпорации IBM (см. http://www.ibm.com/ru/software/info/students/): Mastering Object-Oriented Analysis and Design, Managing the Management of Iterative Development и другие.

3. Бертран Мейер. Объектно-ориентирование конструирование программных систем . Издательство Русская редакция 2005 г., 1204 с. Отражает более классический взгляд на современную ситуацию. Требует хорошей математической подготовки.

Дополнительная литература - для преподавателей.

Ф.А. Новиков. Описание практической работы студентов (ЛП) по дисциплине «Анализ и проектирование на UML» - кафедра «Технологии программирования», Санкт‐Петербургский государственный университет информационных технологий, механики и оптики, Санкт‐Петербург, 2007

Выше автор ориентировался на индивидуальную подготовку. Но единственный надежный способ практической проверки понимания изложенных выше концепций ОО АП – особенно, «критерия 36.6» - коллективная, командная разработка . Методическая разработка Ф. Новикова дает здесь хороший старт - в виде схемы проведения соответствующих лабораторных работ. Хотя автор лично рекомендовал бы для их выполнения задания игрового характера, не претендующие на серьезность. Например - шахматы, шашки, иные настольные игры.

Впрочем, стоит перечитать Ромео и Джульетту , чтобы понять, что истинный смысл цитаты относиться не к собственно розам. Даже - рациональным или виртуальным. Главная тема трагедии обозначается в самом ее начале: Две равно уважаемых семьи в Вероне, где встречают нас события…

Слушателям данного курса доступны лицензионные программные продукты компаний IBM и Microsoft – для этого достаточно обратиться к преподавателю курса (автору данного пособия)

В рамках, определяемых популярной шуткой. Преподаватель – преподавателю: «Ну и глупые же студенты попались. Объяснял, объяснял – уже сам все понял, а они все никак не поймут!»

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

Согласно учебной программе:(- но смотри послесловие J

Русскоязычная терминология, относящая к рассматриваемым проблемам, еще не вполне устоялась. В случае затруднений с переводом автор – во избежание неоднозначного понимания - использует «кальку». Неточный перевод чужих реалий в свои собственные порождает крайне тяжелые проблемы.

Collaboration – сотрудничество. В русском языке слово коллаборационист имеет негативный смысл, потому чаще говорят о диаграммах коопераций.

Автор главы – Анастасия Сабирзянова. Я внес лишь несущественные стилистические правки – поскольку мне нравиться ее живой и честный стиль изложения процесса разработки. Понятно, при желании она могла бы слукавить… Ведь Анастасия отлично закончила факультет ВМК КГУ и имеет уже достаточно большой опыт практического разработки коммерческих приложений. Впрочем - наверное, именно поэтому и не смогла… Н.Б.

Что верно – при учете необходимости трактовать в таких случаях иные части речи как существительные. Вспомним пример «Авторизация», где мы трактуем операцию авторизовать как процесс. Н.Б.

Ключевые слова : имеется в виду глоссарий – компактный список основных терминов, описывающих предметную область. В остальном - мнение Анастасии хорошо ложиться в концепцию ОО АП. Модель – не только и не столько конечный результат разработки. Это текущий результат понимания проблем, с ней связанных. Отсюда – необходимость и полезность проб. Н.Б.

Не всегда, не абсолютно. Описание предметной области имеет приоритет – по умолчанию , при прочих равных условиях. Но напомним, главной задачей итеративного метода является (более-менее) равномерное продвижение всех видов работ. Внутренний идентификатор – например, первичный ключ таблицы БД - также может быть выбран далеко не случайно, но исходя из задач программной реализации. Можно представить себе крайнюю исключительную ситуацию, когда из-за проблем реализации приходиться ограничивать описание предметной области. Разница – в том, что обоснования требуют единичные исключения, а не общие правила. Н.Б.

Мы не затрагивали в данном пособии крайне полезное понятие шаблона проектирования (к тому же, если честно - я не помню такого шаблона). Пока – до знакомства с ним по литературе (см. например ) читатель здесь и далее может читать его так: «ведущие разработчики с большим опытом рекомендуют создать в данной ситуации следующий класс». Н.Б.

В простых случаях. В общем случае, сообщение ссылается на вызов, и соотношение сообщений и операций приходиться задавать особо. Н.Б.

Равно как и желание предупредить возможные ошибки на более ранней стадии. Н.Б.

Я не случайно выделил выше субъекты действий. В главном, я солидарен с Анастасией в ее понимания сути подхода, выраженном ранее и во введении к примеру. Все разработчики – субъекты, или попросту – люди. Не боги, но и не роботы. А каждый человек имеет свой личный подход к решению проблем, зависящий от теоретической квалификации, практического опыта и многих иных вещей – крайне полезных для понимания проблем, но не предопределяющих однозначно решения. Жизнь сложна – языки просты.

Болезни современного программирования, которую и пытается лечить UML – идут от обратного. Не разобравшись в проблемах, мы часто заранее уверены в однозначности решения. Каждый – своего собственного. Оттого-то зачастую температура «в среднем по больнице» поднимается выше нормальной 36.6 - Н.Б.

Реми Кулом (слева) с компьютерной программой Crazy Stone против гроссмейстера Норимото Ёды

В 1994 году компьютер обыграл чемпиона мира по шашкам, в 1997 году - по шахматам. Сегодня компьютеры превосходят людей абсолютно во всех популярных играх с полной информацией , кроме одной - го.

У классической игры с 2500-летней историей очень простые правила, но компьютерные программы даже близко не могут подобраться к победе над лучшими гроссмейстерами, пишет Wired.

Древнюю игру можно считать «восточной версией шахмат». Как и шахматы, это игра с полной информацией, то есть в любой момент игры все игроки имеют полную информацию о состоянии игры и воздействуют на игру дискретными действиями. Здесь успех не зависит от удачи или скорости реакции.

Несмотря на рост вычислительной мощи компьютеров (чемпион мира по шахматам сегодня, вероятно, проиграет даже вашему домашнему ПК), алгоритмы игры в го на экспертном уровне остаются нерешённой и одной из самых интересных задач ИИ. Проблема ещё и в том, что очень немногие способны подняться до девятого дана в игре. Для этого нужно несколько лет обучаться в Японии или Корее. Там талантливых детей забирают из дома для обучения в академии го примерно с 9 лет.

Продвинутые любители почти всегда застревают на определённом уровне игры и не могут улучшить результат: «Требуется некий ментальный прыжок, чтобы снять эту блокировку, и в разработке программ та же проблема, - объясняет Дэвид Фотлэнд (David Fotland), главный разработчик процессора PA-RISC в компании Hewlett Packard в 70-е годы. Он тестировал программу го на процессоре своей разработки. - Вопрос в том, как оценивать всю доску, а не отдельные фрагменты».

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

Компьютерные программы для го разрабатывают уже 45 лет, этой проблеме уделяли почти столько же внимания, сколько и шахматным программам. Первую написал гений теории игр Альфред Зобрист в 1968 году. Она могла обыграть абсолютного новичка, который только что познакомился с правилами (запись первой игры человек-компьютер). Начало казалось оптимистичным. В следующие четыре десятилетия было потрачено огромное количество времени и интеллектуальных усилий, но даже с учётом прогресса в вычислительной мощности программы так и не смогли одолеть даже продвинутого любителя.

Причину можно понять, если сравнить го с шахматами. В начале шахматной партии у белых есть 20 возможных ходов, а у чёрных - 20 возможных вариантов ответа. После первого хода на доске может быть 400 различных позиций. А теперь сравните цифры в го: на доске 19х19 у чёрных есть 361 возможных начальных ходов, а у белых 360 вариантов ответа. Это означает 129 960 возможных комбинаций только после первого раунда.

Так называемый «фактор ветвления» - среднее количество ходов, доступных в каждом раунде - в шахматах составляет 35, в го - 250. Игры с сильным ветвлением затрудняют работу стандартных алгоритмов, использующих правило минимакса для создания дерева возможных комбинаций. Даже с учётом анализа не всех, а только перспективных ветвлений для более глубокого анализа. То, что работает в шашках и шахматах, не работает в го. Выбор перспективных ветвлений в дереве возможных комбинаций го - часто совершенно таинственный процесс. Даже игроки не понимают, как они это делают: «Просто смотришь на доску и знаешь», говорят они.

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

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

Талантливый французский программист Реми Кулом (Rémi Coulom) добился первого успеха с программой Crazy Stone в 2006 году, когда догадался совместить минимакс и метод Монте-Карло. Новый алгоритм расчёта дерева ветвлений он назвал Monte Carlo Tree Search или MCTS. Француз выиграл чемпионат среди компьютерных программ UEC Cup в 2007 и 2008 годах, но это так и не принесло ему известности, и Реми забросил разработку. Но в 2010 году он получил предложение от японского игрового разработчика Unbalance - и в 2011 году вышла первая коммерческая версия Crazy Stone. В 2013 году Реми победно вернулся на чемпионат.

Однако, в 2014 году случилась неудача. В финальном противостоянии против программы Zen зрители поняли, что творится нечто странное уже после третьего хода. Программа Zen, после стандартной постановки двух камней по углам вдруг поставила третий камень около центра. Так никто не играл, это было явно «нечеловеческое» решение. Вскоре уровень победных ожиданий у Crazy Stone вырос до неприлично высоких значений, более 60%. Судя по всему, программа считала безопасной группу камней в правом верхнем углу, хотя она не была безопасной. Поскольку успешная стратегия напрямую зависит от правильной оценки доски, зрители начали шептаться о возможном поражении Crazy Stone. Так оно и вышло: на 186 ходу Crazy Stone признала поражение, а Zen стал новым чемпионом UEC Cup.

Впрочем, у Кулома осталась возможность реванша. Как финалист, он получил право играть против настоящего гроссмейстера-человека с форой в четыре камня. В этом году на турнир приехал Норимото Ёда. Японский гроссмейстер сел за стол в традиционном зелёном кимоно. Реми Кулом - в очках без оправы и синем свитере, в которых был и на прошлом чемпионате.