Курсовая работа (т): Автоматизированная система построения лабиринта и поиска выхода из него

Диаграмма объектов представляет статическую составляющую взаимодействующих между собой объектов, она должна включить в себя только те объекты предметной области, которые потом преобразуются в диаграмму классов. Связи между объектами показывают отношения между ними, при необходимости в диаграмме можно привести и атрибуты(свойства) объектов [2]. На рисунке 13 приведена диаграмма объектов для рассматриваемой системы.

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

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

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

Рисунок 13 - Диаграмма объектов предметной области

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

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

Автоматическая генерация лабиринта. В системе будет использоваться два алгоритма генерации лабиринта: прореживания и «основного пути».

Работа с файлами. Пользователь должен иметь возможность сохранить лабиринт в файл и загрузить его из файла.

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

Визуализация процессов работы с лабиринтом. Пользователь должен выбрать вид визуализации: статическая (с задержкой по времени) или динамическая (с оставлением следов).

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

Таким образом, система должна выполнять следующие функции:

Настройка параметров лабиринта:

задание размеров;

выбор темы;

расставление входа/выхода;

Автоматическое построение (генерация) лабиринта:

алгоритм прореживания;

алгоритм «основного пути»;

Поиск пути:

алгоритм «правой руки»;

волновой алгоритм;

Сохранение лабиринта в файл;

Загрузка лабиринта из файла;

Визуализация процессов работы с лабиринтом:

динамическая;

статическая;

Выдача справочной информации о системе.

. Проектирование системы

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

.1      Разработка структурной схемы

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

−       наличием множества элементов;

−       наличием связей между ними;

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

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

На рисунке 14 приведена структурная схема системы.

В состав системы входят следующие подсистемы:

)        Подсистема управления, которая отвечает за взаимодействие подсистем между собой и представлена в виде иерархического меню;

)        Подсистема составления лабиринта, в состав которой входят:) подсистема настройки параметров, которая отвечает за ввод (выбор) значений параметров лабиринта и проверку корректности этих значений;)       подсистема генерирования, которая отвечает за автоматическое составление лабиринта;

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

)        Файловая подсистема, которая отвечает за хранение лабиринта в файле заранее определенного типа;

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

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

.2 Спецификация системы

Требования - это свойства, которыми должно обладать ПО для адекватного определения функций, условий и ограничений выполнения ПО, а также объемов данных, технического обеспечения и среды функционирования [2].

Программные требования (Software Requirements) - свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач [11]. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований к разрабатываемой ПС.

Спецификация требований к ПО (SRS) - процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут отрабатываться на этапах жизненного цикла ПО. В спецификации требований отражается:

− структура ПО;

− требования к функциям, качеству и документации;

− задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структуры данных.

.2.1   Функциональная спецификация

Функциональные требования задают то, что система должна делать; нефункциональные - с соблюдением «каких условий» (например, скорость отклика при выполнении заданной операции). При разработке этих требований в первую очередь необходимо учитывать потребности пользователя (заказчика). Пользовательские требования (User Requirements) - описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Часто пользовательские требования представляют в виде сценариев (вариантов использования) [2].

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

.2.2   Перечень исключительных ситуаций

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

.2.3   Спецификация качества

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

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

В спецификации качества перечисляются основные требования по показателям качества:

описывается уровень надежности ПС;

формулируются требования по быстродействию;

требования к разработке интерфейса и т.п.

Таблица 1 - Перечень функций, выполняемых системой

Таблица 2 - Перечень исключительных ситуаций

.3 Проектирование интерфейса пользователя

Интерфейс (от англ. interface - поверхность раздела, перегородка) - совокупность средств и методов взаимодействия между элементами системы.

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

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

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

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

Сначала пользователь выбирает тему оформления лабиринта по своему желанию (по умолчанию выбрана тема «Лето»). В полях «Высота» и «Ширина» пользователь должен будет задать соответствующие значения будущего лабиринта. При нажатии кнопки «Создать шаблон» на поле справа появляется сетка для будущего лабиринта заданных размеров.

Рисунок 14 - Интерфейс (главное окно программы)

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

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

.4      Информационно-логический проект системы

Одной из широко используемых методик документирования требований является построение ряда моделей системы. Эти модели используют графические представления, показывающие решения как исходной задачи, так и разрабатываемой системы [2]. Как правило, графическое представление более понятно, чем описание требований на естественном языке.

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

Визуализировать систему в ее текущем или желательном для нас состоянии;

Описать структуру или поведение системы;

Получить шаблон, позволяющий сконструировать систему;

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

.4.1   Язык UML

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

Язык UML не является языком программирования (он инвариантен к языкам программирования).

В нотации языка UML определены следующие виды канонических диаграмм:

вариантов использования (use case diagram);

классов (class diagram);

кооперации (collaboration diagram);

последовательности (sequence diagram);

состояний (statechart diagram);

деятельности (activity diagram);

компонентов (component diagram);

развертывания (deployment diagram).

2.4.2 Диаграмма вариантов использования

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

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

−       Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.