Диаграмма прецедентов игры человек против человека. Компьютерные игры и виртуальная реальность

Реми Кулом (слева) с компьютерной программой 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.

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

В программной и системной инженерии USE CASE-диаграмма представляет собой список действий или шагов мероприятия, которые обычно определяют взаимодействие между ролью (известной на языке унифицированного моделирования как «актер») и системой для достижения цели. "Актер" может быть человеческой или другой внешней системой.

Определение

USE CASE-диаграммы языка UML — это важный и ценный метод анализа требований, который широко используется в современной разработке программного обеспечения со времени его официального введения Иваром Джекобсоном в 1992 году. Разработка с использованием приложений зависит от многих моделей процессов и структур, таких как ICONIX, Unified Process (UP), IBM Rational Unified Process (RUP) и Oracle Unified Method (OUM).

История

В 1986 году Ивар Джекобсон сначала сформулировал текстовые, структурные и визуальные методы моделирования для определения вариантов использования. В 1992 году его соавтор книги «Объектно-ориентированная разработка программного обеспечения — подход, основанный на USE CASE», помог популяризовать технику сбора функциональных требований, особенно в разработке ПО.

Другие эксперты также внесли большой вклад, в частности Алистер Кокберн, Ларри Константин, Дин Леффингвелл, Курт Биттнер и Гуннар Овергаард.

Характер взаимодействия элементов

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

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

USE CASE-диаграммы: состав, виды связей

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

Существует три основных элемента процесса:

"Актеры" — это тип пользователей, которые взаимодействуют с системой.

Система — функциональные требования, которые определяют предполагаемое поведение элементов.

Цели — USE CASE обычно инициируются пользователем для выполнения целей, описывающих действия и варианты, участвующие в их достижении.

Характеристики методики:

Шаги при разработке диаграмм:

Определите пользователей системы.

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

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

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

Терминология

USE CASE-диаграмма в Rational Rose — это диаграмма динамического поведения в UML, которая моделирует функциональность системы с использованием участников, прецедентов и других важнейших объектов. Случаи использования — это набор действий, служб и функций, которые должна выполнять система. В этом контексте система — это то, что разрабатывается или эксплуатируется, например веб-сайт. «Актеры» (условный термин) — это люди или организации, которые работают под определенными ролями внутри системы.

Для чего применяются USE CASE-диаграммы?

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

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

Что такое диаграмма UML?

USE CASE-диаграмма UML — это способ визуализации программного обеспечения с использованием набора диаграмм. Основоположники технологии — Грэди Буч, Джеймс Румбо, Ивар Джекобсон и компания Rational Software Corporation. Их работы легли в основу объектно-ориентированного дизайна, затем спецификации были расширены, чтобы охватить более широкий спектр проектов разработки программного обеспечения. Сегодня UML принимается группой управления объектами (OMG) в качестве стандарта для разработки программного обеспечения для моделирования.

Чтобы ответить на вопрос о том, использования в UML, необходимо сначала понять ее строительные блоки. Общие компоненты включают:

пользователей, которые взаимодействуют с системой;

определенную последовательность действий и взаимодействия между участниками и сценарием системы;

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

В профессиональном сообществе программистов для объяснения структуры часто применяют диаграммы USE CASE «по курочке Рябе» — визуальное изображение сюжета популярной сказки в виде схемы.

Что такое UML?

UML означает Unified Modeling Language. UML 2.0 помог расширить исходную спецификацию, чтобы охватить более широкую часть усилий по разработке программного обеспечения, включая гибкие методы. Также были реализованы следующие разработки:

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

Типы диаграмм

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

Эти диаграммы организованы в две различные группы: структурные и диаграммы поведения (или взаимодействия).

Структурные, в свою очередь, делятся на следующие виды диаграмм:

Классов — являются основой почти каждого объектно-ориентированного метода, включая UML. Они описывают статическую структуру системы.

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

Объекта — описывают статическую структуру системы в определенное время. Они могут использоваться для проверки диаграмм классов для точности.
Композитные структурные диаграммы показывают внутреннюю часть класса. Моделируют функциональность системы с использованием участников и прецедентов.

Компонентов — описывают организацию физических программных компонентов, включая исходный код, исполняемый файл (двоичный код).

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

Поведенческие имеют в своем составе диаграммы:

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

Символы и обозначения

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

Зависимости отмечены пунктирной линией со стрелкой. Использование << >> позволяет указать свойства этой зависимости. Множественность обычно отображается с номером на одном конце стрелки и * с другой.

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

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

Почему мы используем UML?

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

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

Пример USE CASE-диаграммы — графическое изображение взаимодействий между методология, используемая в системном анализе для выявления, уточнения и организации системных требований. В этом контексте термин «система» относится к тому, что разрабатывается или эксплуатируется, например к веб-сайту по продаже и обслуживанию товаров по почте. USE CASE-диаграмма в UML (Unified Modeling Language) — стандартная нотация для моделирования объектов и систем реального мира.

Расшифровка понятий

Цели системы могут включать в себя планирование общих требований, проверку аппаратного проектирования, тестирование и отладку разрабатываемого программного продукта, создание справки по оперативной помощи или выполнение задачи, ориентированной на потребителя. Например, использование диаграммы вариантов USE CASE diagram в среде продаж включает в себя упорядочивание товаров, обновление каталога, обработку платежей и отношения с клиентами. Диаграмма использования выглядит как блок-схема. Интуитивные символы представляют собой элементы системы. Сценарии прецедентов диаграмм USE CASE-банкомата содержат четыре компонента:

Граница, которая определяет систему интереса к окружающему миру.

"Актеры", обычно люди, связанные с системой, определяемые в соответствии с их ролями.

Варианты использования, которые являются конкретными ролями, которые играют "актеры" внутри и вокруг системы.

Взаимоотношения между субъектами.

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

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

цели и методы их достижения;

объем системы.

Практическое применение

USE CASE-диаграмма не имеет большого значения при отсутствии четкого понимания процесса — она не будет моделировать порядок выполнения шагов, если не заложен четкий алгоритм. Эксперты рекомендуют использовать данные диаграммы для дополнения текстового варианта. В диаграмме на высоком уровне демонстрируется взаимосвязь между вариантами использования, субъектами и системами. По этой причине часто используются USE CASE uml-диаграммы для политической партии при моделировании структуры.

Диаграмма идеальна в таких ситуациях:

представление целей системно-пользовательских взаимодействий;

определение и организация функциональных требований в системе;

выявление контекста и требований системы;

моделирование основного потока событий в прецеденте.

Благодаря оптимальной визуализации при моделировании программного обеспечения стиральных машин USE CASE-диаграммы применяются очень широко.

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

Назначение

Цель диаграммы — захватить динамический аспект системы. Однако это определение является слишком общим для описания цели. Так как другие четыре диаграммы (активность, последовательность, совместное использование и Statechart) также имеют одинаковую цель. USE CASE-диаграммы используются для сбора требований к системе, включая внутренние и внешние воздействия (как правило, это требования к дизайну). Следовательно, когда система анализируется для сбора ее функциональных возможностей, разрабатываются примеры использования и идентифицируются участники.

Когда начальная задача завершена, диаграммы случайных ситуаций моделируются для представления внешнего вида. Целями при создании USE CASE-диаграмм можно назвать следующее:

сбор требований;

получение внешнего вида системы;

влияние внешних и внутренних факторов;

визуализация взаимодействия между требованиями и субъектами.

Процесс создания

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

Можно сказать, что варианты использования - это не что иное, как системные функции, написанные организованным образом.

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

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

Дайте подходящее имя для актеров.

Покажите на диаграмме отношения и зависимости.

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

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

Сферы применения

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

Чтобы понять динамику, нужно использовать разные типы диаграмм. USE CASE-диаграммы, состав, виды связей — наилучший пример. Ее конкретная цель - собирать системные требования участников.

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

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

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

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило - пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

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

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

Кому и в каких случаях нужны сценарии

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

- Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

- Тестировщику. Почти готовый тест-кейс:-)

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

А также другим участникам процесса.

В каких случаях они нужны:

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

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

Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие - отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Важные моменты

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

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

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

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

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

Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а - это общее расширение к сценарию, не к конкретному.

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

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Диаграммы прецедентов (Use case diagrams) - применяются для моделирования поведения системы, подсистемы или класса с точки зрения прецедентов (или вариантов использования).

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

Прецеденты;

Участников (актеров);

Отношения зависимости, обобщения и ассоциации.

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

Рис. 3.5.6.1. Графическое отображение примера прецедентов в UML.

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

Рис. 3.5.6.2. Графическое отображение примера участников в UML

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

Моделирование контекста системы, подразумевающего иденти­фикацию участников, взаимодействующих с системой, а также их ролей;

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

Сущности, находящиеся вне моделируемой системы и взаимодей­ствующие с ней, составляют ее контекст. Важной задачей при модели­ровании контекста является идентификация сущностей, взаимодейст­вующих с системой, и их описание.

Моделирование системы необходимо проводить, следуя следую­щим этапам:

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

Рассмотреть и описать потоки событий для прецедентов отраженных на главной диаграмме прецедентов, а именно: предусловия, главный поток, подпотоки, альтернативные потоки, постусловия;

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

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

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

Моделирование требований к системе необходимо проводить, сле­дуя следующим этапам:

Установление контекста системы, идентификация окружающих систему участников;

Для каждого участника - рассмотрение поведения, которое он ожидает и требует от системы;

Именование выделенных вариантов поведения как прецедентов;

Выделение общего поведения в новые прецеденты, которые бу­дут использоваться другими;

Выделение вариации поведения в новые прецеденты, расширяющие основные потоки событий;

Моделирование выделенных прецедентов, участников, отноше­ний между ними на диаграмме прецедентов;

Дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования к системе.

Моделирования диаграмм прецедентов на конкретных примерах приведены на рис. 3.5.6.3. и рис. 3.5.6.4.

Рис. 3.5.6.3. Графическое отображение прецедентов на примере обслуживания

абонентов сотовой телефонной связи.

Следует отметить дополнение прецедентов примечаниями, описывающими не­функциональные специфические требования, т.е.комментариями, которыми могут сопровождаться некоторые отношения между вариантами использования. Так, смысл отношения "include" состоит в том, что в данном примере «Подключение» включает в себя «Выбор оператора связи». Смысл же связи <> в том, что прецедент, например, «Рассмотрение анкеты» "расширяется" вариантом использования «Заключение договора». Это можно в данном случае объяснить тем, что «Заключить договор» можно только после проверки оператором анкеты. «Рассмотрение заявления» "расширяет" прецедент «Блокировка номера», «Замена sim-карты», «Детализация счета», «Замена абонентского номера». Таким образом, связь <> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

Рис. 3.5.6.4. Графическое отображение прецедентов

на примере производственного участка.

Данные диаграммы прецедентов описывают участников при их взаи­модействии с системой на предприятиях.

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

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

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

Для более подробного анализа, правила настольной игры были представлены в виде блок схем, описывающих основные этапы игрового процесса. Общая схема изображена на рисунке 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.4.Прецедент «Продолжить игру».

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

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

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

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

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

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

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

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

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

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

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