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

Введение 3

Глава 1. Техническое задание 5

1.Общие сведения 5

2.Назначения и цели создания системы 6

3.Характеристика объектов автоматизации 7

4.Требования к системе 7

Глава 2. Разработка диаграмм 9

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

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

Диаграмма последовательности 21

Глава 3. Реализация методов 23

Выводы 26

Список литературы 27

Приложения 28

Введение

Вычислительная система – это совокупность программных и аппаратных средств, направленных на решение задач обработки информации. Термин «вычислительная система» появился в конце 1950-х – начале 1960-х после того как в ЭВМ того времени начали использовать больше одного процессора, тем самым увеличивая производительность и надежность системы.
В рамках данной курсовой работы было рассмотрено объектно-ориентированной проектирование. Так как объектно-ориентированный подход, также распространен в программировании, рассмотрим сначала отличия этих двух дисциплин. Целью программирования является решение прикладных задач с помощью механизмов определённого языка и сторонних вспомогательных программ. Проектирование основное внимание уделяет правильному описанию сложных систем и ее отдельных частей с различных сторон.
Объектно-ориентированное проектирование основывается на объектно-ориентированной декомпозиции. Она представляет собой разбиение системны на какие-либо объекты, действующие в той ситуации, которая моделируется в данный момент. Именно декомпозиция отличает этот метод проектирования от структурного.
На этапе проектирование осуществляется преобразование требований, изложенных в ТЗ в детальные спецификации информационной системы, разрабатываются подробные схемы, описывающие её с разных сторон.

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

Диаграмма вариантов использования (use case diagram)
Диаграмма классов (class diagram)
Диаграммы поведения (behavior diagrams)

Диаграмма состояний (statechart diagram)
Диаграмма деятельности (activity diagram)
Диаграммы взаимодействия (interaction diagrams)

Диаграмма последовательности (sequenceьdiagram)
Диаграмма кооперации (collaboration diagram)

Диаграммы реализации (implementation diagrams)

Диаграмма компонентов (component diagram)
Диаграмма развертывания (deployment diagram)

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

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

Темой этой курсовой работы является поддержание реализации индустрии компьютерных игр, теперь нужно подробней рассмотреть специфику компьютерных игр их направление и обобщить что они из себя представляют.
Компьютерная игра - это специальная программа с помощью которой пользователь может «убивать время» играя в различные игры по типу пасьянса или дурака, как пример карточных игр из реальной жизни но уже реализованных на компьютере и не только.
В данное время все сильнее распространяется индустрия киберспорта, а именно это компьютерные игры. То есть собираются профессиональные игроки в игры. Пример считается турнир, проведенный 19 октября 1972 года в лаборатории искусственного интеллекта Стэнфордского университета. Предметом соревнований стал созданный десятилетием ранее Spacewar!, где два игрока брали на себя роль космических пилотов, воюющих друг с другом, ограниченным запасом топлива и гравитацией планеты, вокруг которой происходили цифровые баталии.

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

Глава 1. Техническое задание

Общие сведения

Полное наименование системы и ее условное обозначение.

Прототип информационной системы для поддержании реализации компьютерных игр.

Условное обозначение: Прототип ИС для ПРКИ.

Наименование разработчика и заказчика системы.

Заказчик – кафедра Информатики и вычислительной техники Воронежского института высоких технологий.

Разработчик – студент группы ИВТ-193 Самбулов Максим Александрович

Основания для разработки прототипа ИС.

Задание на курсовую работу

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

Начало работы – 22.09.2022 года.

Окончание работы –25.11.2022 года.

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

По окончанию работ заказчику будут предъявлены:

- пояснительная записка;

- исходные файлы веб-сервиса;

Назначения и цели создания системы

Назначение системы.

Прототип ИС для ПРКИ нужен для того чтобы обычный человек смог разобраться в посещении компьютерного клуба.

Цели создания системы.

Целью создания системы является:

- улучшение качества работы компьютерного клуба;

- оптимизация распределения сотрудников;

- улучшение работы сайта и самого компьютерного клуба путем обновления комплектующих.

Характеристика объектов автоматизации

Краткие сведения об объекте автоматизации

Объектом автоматизации является компьютерный клуб.

Сведения об условиях эксплуатации объекта автоматизации

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

Требования к системе

Требования к системе в целом

Прототип ИС ПРКИ требуется для сотрудников и клиентов в зависимости от предпочтений.

Требования к функциям, выполняемым системой.

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

Требования к видам обеспечения.

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

В качестве входной информации выступает:

БД клиентов и сотрудников
Оформление игрового места

В качестве выходной информации выступает:

Изменения в БД
Отображение информации в личном кабинете

Глава 2. Разработка диаграмм

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

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

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

Суть этой диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актёром или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
Также диаграмма вариантов использования включает в себя отношения между компонентами диаграммы, которые описывают взаимодействие между одними актерами и вариантами использования, и другими актерами, и вариантами использования.
В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

Отношение ассоциации;
Отношение расширения;
Отношение обобщения;
Отношение включения.

Для данной курсовой работы была составлена диаграмма, состоящая из 5-ти актеров и 18-ти вариантов использования, представленная на рисунке 1.

Рисунок 1 – Диаграмма вариантов использования

Диаграмма имеет 5 актеров и 16 вариантов использования, рассмотрим их поподробней. Актеры: Владелец, администратор, клиент, модератор, инженер.
Варианты использования или прецеденты, связанные с конкретным актером:

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

Диаграмма классов

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

Ассоциация;
Агрегация;
Композиция;
Наследование.

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

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

Рисунок 3 – Отношение агрегации на диаграмме классов
Композиция – это разновидность агрегации, в которой объекты-часть зависят от класса, который их используют и не могут существовать без него. В примере, представленном на рисунке 4 Покупатель на может существовать в отрыве от Авторизированный покупатель. Если эти данные будут удалены, то Покупатель потеряет доступ к системе.
Наследование – это отношение типа общее-частное. Определяет связи классов, где класс-наследник обладает поведением и структурой класса-родителя. На схеме обозначется как линии идущие от наследников к родителю. На конце с классом-родителем изображают незакрашенный треугольник, направленный острым концом в даный класс. У данного типа отношений на схеме не указывается кратность.

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

Public «+» - максимальная видимость. Данный параметр или метод доступен из любой части программы;
Package «

» - пакетный квантор видимости дает доступ к параметру всем классам внутри одно пакета;

Protected «#» - данный квантор ограничивает область видимость наследниками класса в котором был применен;

Private «-» - приватный квантор скрывает параметр от всех других классов, включая наследников, а также от экземпляров самого класса.

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

Рисунок 5 – Диаграмма классов
На диаграмме представлены 9 классов: Постоянный покупатель, Покупатель, авторизованный покупатель, Оплата, Оплата картой, Оплата наличными, Компьютерные игры, Разработчик, Инвестор.

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

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

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

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

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

Диаграмма деятельности может включать в себя следующие элементы:

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

Рисунок 6 – Начальный узел деятельности

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

Рисунок 7 – Конечный узел деятельности

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

Рисунок 8 – Конечный узел потока

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

Рисунок 9 – Объект

Узел решения представляет из себя элемент определяющий ветвление. В точку ветвления входит ровно один переход, а выходит - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов эти сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Желательно чтобы условия покрывали все возможные варианты, иначе поток остановится. Визуально узел решения выглядит как ромб с выходящими из него стрелками, представлен на рисунке 10.

Рисунок 10 – Узел решения

Далее следует обратить внимание на такой элемент, как узел объединение. Узел объединения бывает двух подтипов: вилка и слияние. В первом случае на вход подается один поток, который разветвляется на 2 и более, во втором случае на входе имеется 2 и более потоков, который объединяются в один выходной. Смотрите рисунок 11.

Рисунок 11 – Узел объединения
В ходе проектирования поддержки и реализации индустрии компьютерных игр была создана диаграмма деятельности, представленная на рисунке 12.
На данной диаграмме деятельности рассматривается алгоритм посещения компьютерного клуба. Клиент узнает все что ему нужно о данном заведении, и вообще подходит ли оно ему. После чего выбирает девайс на котором он проведет время, далее он узнает есть ли свободные места. Если есть то он может сразу оплатить часы и пойти за своё место, либо если он делает это через сайт то он может забронировать место и по приезду оплатить его. Если же места нет, он может либо дождаться его и оплатить, либо забронировать его после того кто сейчас за ним сидит и прийти позже.

Рисунок 12 – Диаграмма деятельности
В данной диаграмме были использованы такие элементы как: узел начала, узел окончания деятельности, действие, узел решения.

Диаграмма последовательности

Диаграмма последовательности является своеобразным расширение диаграмма вариантов использования. В ней рассматривается взаимодействие определенных объектов, и информация которой они обмениваются в ходе выполнения прецедента.
Основными элементами диаграммы последовательности являются: актер (см. рисунок 6); обозначения объектов (см. рисунок 7); вертикальные «линии жизни», отображающие течение времени; прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (см. рисунок 8); стрелки, показывающие обмен сигналами или сообщениями между объектами (см. рисунок 9).

Рисунок 13 – Актер с «линией жизни»

Рисунок 14 – Объект с «линией жизни»

Рисунок 15 - Прямоугольник, отражающий деятельность объекта или исполнение им определенной функции

Рисунок 16 - Стрелка, показывающая обмен сигналами или сообщениями между объектами
Рассмотрим основные виды сообщений:

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

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

Рисунок 17 – Диаграмма последовательности для прецедентов «Авторизировать клиента» и «Оплатить заказ»
В системе рассмотрен алгоритм авторизации клиента на сайте.

На диаграмме рассматриваются актер «Покупатель», объекты «Авторизация», «Проверка данных», «База данных» и «Авторизованный покупатель».

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