Сетевая игра "Крестики-Нолики" между произвольными пользователями локальной сети

 

Оглавление


ВВЕДЕНИЕ

1. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ

.1 Обзор существующих решений

.2 Достоинства и недостатки существующих решений

.3 Реализуемые функциональные возможности

.4 Выводы

. КОНСТРУКТОРСКАЯ ЧАСТЬ

.1 Архитектура программного комплекса

.2 Описание реализованного протокола данных

.3 Функционирование сервера

.3.1 Обработка входящих подключений

.3.2 Работа пользовательского потока

.3.3 Работа потока отправки

.4 Функционирование клиента

.4.1 Поиск сервера

.4.2 Подключение клиента к серверу

.4.3 Обмен пакетами

.4.4 Потеря соединения с сервером

.5 Выводы

. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

.1 Выбор языка программирования

.2 Структура серверного приложения

.3 Структура клиентского приложения

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

.5 Работа с клиентским приложением

.6 Тестирование программного комплекса

.7 Выводы

ЗАКЛЮЧЕНИЕ

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


Введение


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

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

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

.Разработка структуры программного комплекса;

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

.Реализация частей программного комплекса («клиент» и «сервер») и обмена данными между ними посредством созданного протокола;

.Тестирование разработанного программного комплекса.

1. Исследовательская часть


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


1.1Обзор существующих решений


Как уже было сказано, существует большое количество сетевых игр типа «Крестики-Нолики». У всех этих игр можно выделить некоторые общие черты:

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

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

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

.После завершения игры пользователь может вновь начать новую игру.

Рисунок 1.1. Игра.


1.2Достоинства и недостатки существующих решений


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

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

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

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

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


1.3Реализуемые функциональные возможности


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

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

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

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


1.4 Выводы


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

2. Конструкторская часть


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


2.1Архитектура программного комплекса


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

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

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


Рисунок. 2.1. Модель взаимодействия «клиент» - «сервер».

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


2.2Описание разработанного протокола передачи данных


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

Пакет запроса соединения с сервером. Этот пакет является прототипом для двух следующих пакетов, используется для одного из видов подключения к серверу - регистрация или авторизация. Формат пакета следующий:

req_con;login;password;

где req_con - заголовок пакета запроса соединения, login и password - информация об учетной записи.

Пакет запроса регистрации на сервере. Этот пакет используется тогда, когда пользователь ещё не зарегистрирован на сервере, и для входа на сервер требуется наличие его собственной учетной записи. Формат пакета следующий:

req_reg;login;password;

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

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

req_auth;login;password;

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

Пакет ответа соединения с сервером. Этот пакет используется, когда пользователь удачно соединился с сервером, и тот принял его регистрационные/авторизационные данные. Формат пакета следующий:

resp_con;successfully;message;

где resp_con - заголовок пакета ответа, successfully - результат подключения (удачно/неудачно), message - сообщение от сервера.

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

chat_mes;login;message;

где chat_mes - заголовок пакета сообщения, login - логин пользователя, отправившего сообщение, message - текст сообщения.

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

req_game;login;

где req_game - заголовок пакета поиска игры, login - логин пользователя, желающего начать играть.

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

cncl_req;login;

где cncl_req - заголовок пакета прекращения поиска игры, login - логин пользователя, желающего прекратить поиск.

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

resp_game;enemy_login;turn;

где resp_game - заголовок пакета результата поиска, enemy_login - логин оппонента, turn - право первого хода.

Пакет хода игрока. Этот пакет используется, когда игрок делает ход. Формат пакета следующий:

game_move;enemy_login;x;y;

где game_move - заголовок пакета хода игрока, enemy_login - логин оппонента, x и y - координаты хода.

Пакет победы игрока. Этот пакет используется при завершении игры в пользу одного из игроков. Формат пакета следующий:

win_game;enemy_login;x;y;

где win_move - заголовок пакета победы игрока, enemy_login - логин оппонента, x и y - координаты хода.

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

no_mooves!;enemy_login;x;y;

где no_mooves! - заголовок пакета отсутствия ходов, enemy_login - логин оппонента, x и y - координаты хода.

Пакет пинга. Этот пакет используется для определения активности клиентов и сервера. Если пакет не возвращается, значит клиент/сервер отключены. Формат пакета следующий:

ping;

где ping - заголовок пакета пинга.

Пакет подключения пользователя. Этот пакет используется для оповещения пользователей в сети о подключении нового пользователя. Формат пакета следующий:

online;login;

где online - заголовок пакета подключения пользователя, login - логин подключившегося пользователя.

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

offline;login;

где offline - заголовок пакета отключения пользователя, login - логин отключившегося пользователя.


2.3Функционирование сервера


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

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

.Широковещательная рассылка пакетов всем подключенным пользователям локальной сети - BroadcastManager;

.Обработка подключений новых пользователей - ConnectManager;

.Обработка данных, получаемых от пользователей и отправляемых пользователям - ClientsManager;

.Обработка данных, связанных с одним конкретным пользователем (получение и отправление) - ClientManager;

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

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

.Очередь пакетов для отправки конкретному клиенту. В эту очередь будут добавляться пакеты, которые необходимо отправить конкретному клиенту. Очередь будет одновременно использоваться частями BroadcastManager и ClientManager.

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

Общий жизненный цикл программы состоит из следующих этапов:

.Запуск сервера, при этом запускаются отдельные потоки для ConnectManager и BroadcastManager;

.При получении корректного входящего подключения ConnectManager запускает для подключившегося пользователя новый поток ClientManager;

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

.При остановке сервера завершаются все потоки.

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


2.3.1 Обработка входящих подключений

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

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

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

Рисунок 2.2. UML-диаграмма действий потока обработки входящих подключений.


2.3.2Работа пользовательского потока

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

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


2.3.3Работа потока отправки

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


2.4Функционирование клиента


В данной главе рассматриваются основные алгоритмы работы клиента и их особенности.


2.4.1Поиск сервера

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

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


.4.2Подключение клиента к серверу

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

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

Алгоритм действий клиента при входе на сервер изображен на рисунке 2.3.

Рисунок 2.3. UML-диаграмма действий клиента при входе на сервер.


2.4.3Обмен пакетами

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

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

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

Алгоритм работы клиентской части приложения при получении пакетов изображен на рисунке 2.4.

Рисунок 2.4. UML-диаграмма действий клиента при приеме пакетов.


2.4.4Потеря соединения с сервером

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

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


2.5 Выводы


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

3. Технологическая часть


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


3.1 Выбор языка программирования


Для создания программного комплекса был выбран язык программирования C#. Этот выбор был сделан на основании нескольких причин.

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

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

В-третьих, для данного языка существует многофункциональная среда разработки Microsoft Visual Studio, благодаря которой можно быстро и удобно разрабатывать приложения на языке C#.

В качестве средства разработки приложения-сервера использовалась Microsoft Visual Studio 2010 по нескольким причинам. Во-первых, данная IDE содержит подсветку кода, что упрощает процесс написания программы. Во-вторых, она содержит инструмент для автозавершения кода. В-третьих, эта среда разработки содержит огромное множество настраиваемых параметров, благодаря чему программист может настроить её наилучшим для себя образом.


3.2Структура серверного приложения

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

В серверном приложении можно выделить следующие классы:

.Классы диспетчеров, управляющих рабочими потоками

·MainManager: инкапсулирует в себе все главные части приложения;

·BroadcastManager: управляет широковещательной рассылкой пакетов по протоколу UDP;

·ConnectManager: управляет входящими соединениями;

·ClientsManager: управляет подключенными клиентами;

·ClientManager: управляет одним конкретным подключенным клиентом.

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

·BroadcastWorker: функции рабочего потока широковещательной рассылки;

·ConnectWorker: функции потока работы с входящими соединениями (прослушивание, установление связи);

·ClientWorker: функции рабочего потока, которым управляет ClientManager;

.Классы пакетов

·Packet - абстрактный класс, от которого наследуются все остальные классы пакетов;

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

·RequestLoginPacket - класс пакета запроса авторизации на сервере;

·RequestRegistrationPacket - класс пакета запроса регистрации на сервере;

·ResponceConnectionPacket - класс пакета ответа соединения с сервером;

·RequestGamePacket - класс пакета поиска игры;

·ResponseGamePacket - класс пакета результата поиска игры;

·MoveGamePacket - класс пакета хода пользователя;

·WinGamePacket - класс пакета победы пользователя;

·CancelRequestGamePacket - класс пакета прекращения поиска игры;

·NoMovesPacket - класс пакета отсутствия ходов;

·ChatMessagePacket - класс пакета сообщений чата;

·PingPacket - класс пакета опроса доступности;

·OfflinePacket - класс пакета отключения пользователя;

·OnlinePacket - класс пакета подключения пользователя.

Также серверная программа создает два файла - log.txt и chat_log.txt для записи системных сообщений журнала и сообщений из чата соответственно.


3.3Структура клиентского приложения


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

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


·Установленный пакет .NET Framework 4.0, 4.5;

·Наличие локальной сети;

·Операционная система семейства Windows NT (2000, XP, Vista, Windows 7);

·100 мегабайт оперативной памяти;

·Должны быть доступны для передачи и приема данных порты: 15000 и 16000.


3.5 Работа с клиентским приложением


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


Рисунок 3.1. Окно авторизации.


Если у пользователя еще нет учетной записи, при нажатии на кнопку «Регистрация» откроется окно регистрации, с помощью которого можно будет создать новую учетную запись.

Рисунок 3.2 Окно регистрации.


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


Рисунок 3.3. Подключение к серверу выполнено.


При нажатии на кнопку «Начать игру» будет начат поиск соперника.

Рисунок 3.4. Поиск соперника


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


Рисунок 3.5. Игровой процесс.


При завершении игры приложение сообщает о результате партии.

Рисунок 3.6. Окончание игры.


3.6 Тестирование программного комплекса


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

.Регистрация с логином, который уже зарегистрирован.


Рисунок 3.7. Регистрация с логином, который уже зарегистрирован.


.Авторизация с логином, который не зарегистрирован.

Рисунок 3.8. Авторизация с логином, который не зарегистрирован.


.Авторизация с неверно указанным паролем.


Рисунок 3.9. Авторизация с неверно указанным паролем.


.Разрыв соединения.

Рисунок 3.10. Разрыв соединения.


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


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


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

3.7 Выводы


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

Заключение


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

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

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

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


1) Алешин В. Требования к выполнению курсовой работы по ВК и С:

Методическое указание. - Москва, 2008.

) Таненбаум Э. Компьютерные сети. - СПб.: Питер, 2003.

) Палмер М. Проектирование и внедрение компьютерных сетей. - БХВ-Петербург, 2004.

4) Troelsen A. Pro C# 5.0 and the .NET 4.5 Framework. - APress, 2012.


Оглавление ВВЕДЕНИЕ 1. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ .1 Обзор существующих решений .2 Достоинства и недостатки существующих решений .3 Реализуемые

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ