Лабораторная работа № 26. Разработка сетевых приложений

Цель работы:

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

Порядок выполнения работы

Задачу можно выполнять вдвоем

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

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

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

 

Задания:

1) Реализовать программу "talk" (клиент и сервер), позволяющую организовать диалог двух пользователей. Текстовая строка посылается партнеру по нажатию "Enter". Соединение разрывается при наборе строки, содержащей один-единственный символ "." (точка) (2).

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

3) Сетевой "Морской бой" (4).

4) Сетевые "Крестики-нолики" на бесконечном поле (3).

5) Сетевая игра "Быки и коровы" (3). (Каждый играющий задумывает четырехзначное число. Задача -- угадать число соперника. На очередном ходе игрок предлагает число и получает в ответ число быков и коров, бык соответствует правильной цифре на своем месте, корова -- цифре, которая содержится в записи числа, но названа не на своем месте.)

6) Сетевая игра "Го" (5) http://ournetlife.ru/category/games/ho_-_kitaiskaya_logicheskaya_igra.html

7) Реализовать сервер и клиент так, чтобы сервер мог работать с несколькими клиентами одновременно (с помощью потоков на сервере). Каждый клиент посылает на сервер приветствие, после чего сервер ждёт случайное число секунд от 1 до 10 и посылает ответ клиенту.

8) Реализовать клиент, который запрашивает у пользователя пароль, вычисляет его хеш-сумму (CRC-32), передаёт хеш-сумму на сервер, после чего сервер сравнивает её со своей хеш-суммой (которую он вычисляет по паролю так же, как клиент) и посылает клиенту подтверждение - пароль верен или нет.

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

10) Реализовать сервер, который может передавать команды системе на исполнение (с помощью функции system()). Пользователь вводит команды интерактивно в клиенте, клиент передаёт их на сервер, сервер печатает команду и исполняет её.

Проект "Файловый сервер": Filesrv.zip

Варианты

11) Проект "Файловый сервер". Реализовать команду "get" для клиента, которая получает файл от сервера.

12) Проект "Файловый сервер". Реализовать команду "put" для клиента, которая пересылает файл на сервер.

13) Проект "Файловый сервер". Реализовать команду "ls" для клиента, которая получает от сервера список файлов в текущей директории и распечатывает его на экране терминала.

14) Проект "Файловый сервер". Реализовать команду "mget" для клиента, которая получает несколько файлов от сервера. Список файлов задается с использованием звездочки "*" в имени файла.

15) Проект "Файловый сервер". Реализовать команду "mput" для клиента, которая передает серверу несколько файлов. Список файлов задается с использованием звездочки "*" в имени файла.

Содержание отчета

1) Титульный лист.

2) Наименование и цель работы.

3) Краткое теоретическое описание.

4) Задание на лабораторную работу.

5) Листинг программы.

6) Результаты выполнения программы.

 

Жизненный цикл программы

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

Во-вторых, после того как исправлены ошибки, выявленные во время ком­пиляции, и программа, наконец, заработала, часто обнаруживается, что она делает не то, что предполагалось. Скажем, программа вычисляет вес челове­ка, а он будет равен тонне или, напротив, сотне граммов. Расстояние до Луны окажется равным паре метров, а расстояние до ближайшего магази­на — сотне километров. В таких ошибках виноват неправильный алгоритм решения задачи. Для устранения дефекта приходится возвращаться к тексту программы и изменять заложенный в нее алгоритм.

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

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

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

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

21.1. Программный продукт и определение требований к продукту

Программный продукт

Каждый программист хочет, чтобы его программу использовали как можно больше людей на самых разных машинах. Для этого он должен сделать про­грамму удобной для использования. Конечно, программу надо тщательно протестировать и отладить. Она обязательно должна давать верные результа­ты. Необходимо предусмотреть и обработать все исключительные ситуации, чтобы программа не давала неожиданные сообщения об ошибках. Пользо­вателю надо дать удобный и привычный интерфейс, чтобы он мог сразу же начать работу с программой, а не ломать голову, думая как сделать то или иное действие. В программе следует предусмотреть как можно более широ­кие возможности: взаимодействие с большим количеством устройств ввода-вывода, способность работать в разной операционной среде. Программу на­до снабдить оперативной справкой (Help) и документацией, объясняющей ее особенности и условия эксплуатации. По крайней мере, к программе на­до приложить файл README с краткими пояснениями по ее установке и использованию. Наконец, программу надо сделать легко устанавливаемой (install) на компьютер и так же легко и полностью удаляемой из него.

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

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

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

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

Определение требований к продукту

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

Дело осложняется тем, что заказчик программного продукта часто не может полностью сформулировать то, что он хочет получить. Его требования огра­ничиваются общими фразами вроде: "Сделайте мне систему, такую же, как CoolProduct, но рассчитанную на наши правила товарооборота и отчетно­сти". Получив же такую систему, заказчик чаще всего восклицает: "Но я со­всем не это имел в виду!" Поэтому требования к программному продукту вырабатываются в результате долгих обсуждений и уточнений. Зачастую они изменяются уже в ходе разработки, хотя этого надо всячески избегать.

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

Требования к функционированию продукта

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

Современные программные продукты взаимодействуют с пользователем с помощью графического интерфейса. Обычный сеанс работы с продуктом выглядит следующим образом. При запуске продукта на экране дисплея от­крывается окно, содержащее различные графические компоненты (controls, widgets): поля ввода исходных и промежуточных данных, кнопки выбора, раскрывающиеся списки, из которых можно выбрать нужные пункты, ко­мандные кнопки подтверждения или отмены действий и другие элементы управления программой. Пользователь вводит исходные данные или выби­рает их из предложенного списка и запускает механизм решения задачи.

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

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

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

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

Плодотворный метод определения функциональных требований разработал Айвар Якобсон (Ivar Jacobson). Этот метод входит в так называемый унифи­цированный процесс разработки (RUP, Rational Unified Process), предлагае­мый фирмой Rational Software Corporation. Якобсон предложил начинать определение требований с составления всех возможных действий (actions) некоторого действующего лица (actor) с программным продуктом, с начала сеанса его работы до окончания сеанса. Действующим лицом может быть не только пользователь, но и какой-то алгоритм, выполняющийся в программ­ном продукте, и какая-то внешняя программа.

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

Набор всех сценариев, приводящих к одному результату, называется use case. На русский язык этот термин переводят по-разному: прецедент, сцена­рий использования, вариант использования. Сценарии, образующие преце­дент, называются экземплярами (instances) прецедента. Вначале в прецеден­ты вносятся все сценарии, в том числе и неудачные. Затем сценарии каждого прецедента анализируются, обобщаются и собираются в один-два наилучших сценария.

Например, пользователь Интернета может создать экземпляр прецедента "Загрузить файл с сайта", набирая адрес этого сайта в строке адреса браузе­ра. Другой экземпляр прецедента будет создан щелчком кнопки мыши по ссылке в окне браузера. Как видите, в браузере реализовано несколько сце­нариев прецедента "Загрузить файл с сайта". Набор другого адреса — это другой сценарий того же прецедента. Если адрес верен и загрузка файла до­пустима, то сценарий завершится успешно, в противном случае сценарий завершится неудачей.

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

Требования к надежности продукта

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

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

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

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