Лекция 1. Веб-приложения: назначение, развитие и жизненный цикл

Продолжительность: 45 минут. Тема программы: введение в основные понятия и историю веб-приложений.

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

0-4 минуты. От привычного действия к устройству сервиса

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

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

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

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

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

4-11 минут. Основные понятия и участники работы

Веб-страница представляет собой документ, который браузер показывает пользователю. На странице могут находиться текст, изображения, ссылки, таблицы и поля ввода. Несколько связанных страниц и ресурсов образуют веб-сайт. Браузером называют программу для работы с веб-ресурсами. Например, Firefox или Safari. [2]

Веб-приложением в рамках нашего курса будем называть программу, с которой пользователь взаимодействует через веб-интерфейс и выполняет определённые задачи. У сайта перевозчика есть информационная сторона: контакты, правила провоза багажа, описание маршрутов. Есть прикладная сторона: поиск рейса, выбор места, управление бронированием. Один сервис может объединять обе стороны.

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

Интерфейсом называют средства взаимодействия человека с программой. Надпись «Куда», поле ввода, кнопка «Найти рейсы» и сообщение о результате относятся к интерфейсу. Удобный интерфейс помогает человеку понять, что требуется ввести, какое действие произойдёт и чем оно завершилось.

Клиентом называют программу, которая обращается за ресурсом или услугой. В нашем примере роль клиента выполняет браузер. Серверная программа принимает обращения и формирует ответы. Слово «сервер» также используют для компьютера, на котором работает такая программа. Поэтому полезно уточнять, о чём идёт речь: о программе или об оборудовании. [2, 26]

Представим разговор. Браузер сообщает: «Покажи рейсы в Тверь». Серверная часть подбирает сведения и отвечает: «Подходят рейсы в 09:00 и 12:30». Браузер представляет результат пассажиру в виде понятной страницы.

Для длительного хранения сведений часто используется база данных. Это организованное хранилище, в котором приложение может искать, добавлять и изменять записи. В нашем учебном проекте такими записями будут рейсы, автобусы, места и бронирования. Серверная программа обращается к хранилищу и применяет правила работы сервиса. [3]

Теперь введём ещё два распространённых слова. Frontend, произносится «фронтенд», обозначает клиентскую часть веб-приложения. Backend, «бэкенд», обозначает серверную часть, которая обрабатывает обращения и выполняет основные правила сервиса.

Предположим, пассажир выбрал место 12. Браузер передаёт его выбор. Сервер проверяет текущее состояние места и сохраняет бронирование. Затем браузер показывает подтверждение. У каждой части есть своя ответственность, и именно их согласованная работа даёт результат.

11-18 минут. Предпосылки появления и основные вехи

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

В 1989 году в CERN Тим Бернерс-Ли предложил проект связанной информационной системы. К 1991 году идея стала работающей Всемирной паутиной. Важным шагом стало решение CERN от 30 апреля 1993 года сделать программное обеспечение веба общественным достоянием. Это помогло другим организациям использовать и развивать технологию. [1]

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

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

Следующий важный шаг связан с формированием страниц из данных. Допустим, перевозчик хранит сто рейсов в базе. Пассажир выбирает направление, и сервер собирает ответ именно для этого выбора. Такой результат зависит от обращения пользователя и текущего содержимого хранилища. Статический ресурс обычно отдаётся в подготовленном виде; динамический ответ формируется программой при обработке обращения. [3]

В середине 1990-х получили развитие технологии поведения и оформления страниц. Язык JavaScript позволил программировать действия в браузере, а CSS дал средства описания внешнего вида. Первый стандарт ECMAScript, лежащий в основе JavaScript, опубликован в 1997 году. Первая рекомендация CSS появилась в 1996 году. [4, 5]

На примере расписания разделение выглядит так. HTML задаёт структуру: заголовок, таблицу и кнопку. CSS определяет расположение, цвета и размеры. JavaScript может реагировать на выбор дня и обновлять показанные данные.

В 2000-е годы распространился подход Ajax: страница могла запрашивать данные в фоне и обновлять отдельную область. При выборе нового направления пользователь оставался в том же интерфейсе, а список рейсов менялся. Название исторически связано с XML, при этом на практике для таких обменов широко используется и JSON. [39]

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

Отдельное направление представляют прогрессивные веб-приложения, PWA. В зависимости от реализации и поддержки браузера они могут устанавливаться на устройство и предоставлять часть возможностей при временной потере связи. Объём автономной работы определяется тем, что разработчики заранее предусмотрели и сохранили на устройстве. [6]

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

18-25 минут. Состав приложения и современная практика

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

HTML описывает, какие элементы находятся в документе и что они означают. Например, название направления можно обозначить как заголовок, список остановок как список, расписание как таблицу. CSS определяет визуальное представление. JavaScript выполняет программные действия в браузере. Такое разделение помогает изменять оформление, сохраняя смысл и структуру документа. [28]

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

Важный термин для взаимодействия программ: API, произносится «эй-пи-ай». Это согласованный интерфейс обращения к возможностям другой программы. В учебном проекте API может определять: какие данные передать для поиска рейса, по какому адресу обратиться и в каком виде придёт результат.

Сравним два возможных решения. В первом сервер сразу формирует готовый HTML со списком рейсов. Во втором сервер отдаёт данные, а браузерная программа собирает из них карточки. Выбор зависит от задач проекта. Оба решения опираются на понятные правила обмена между клиентом и сервером. [3, 18]

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

Теперь представим два одновременных обращения. У пассажиров Анны и Бориса открыта одна страница, и оба видят свободное место 12. Каждый нажимает кнопку бронирования. Серверная часть должна последовательно или иным согласованным способом разрешить конфликт: закрепить место за одним бронированием и сообщить второму пассажиру об изменении доступности.

Этот пример показывает границу ответственности интерфейса. Браузер помогает выбрать место и отправить намерение. Решение о закреплении места опирается на общее состояние сервиса. Для нашего проекта за это отвечает серверная программа совместно с хранилищем.

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

25-32 минуты. Жизненный цикл разработки

Жизненный цикл описывает путь программного продукта от первоначальной потребности до сопровождения, развития и завершения использования. Этапы могут повторяться: после обратной связи команда уточняет требования и выпускает следующую версию. Распространённые этапы включают планирование, анализ, проектирование, реализацию, тестирование, внедрение и сопровождение. [7]

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

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

Затем формулируют требования. Требование должно помогать понять ожидаемое поведение. Фраза «поиск должен быть удобным» оставляет много вариантов толкования. Более конкретная формулировка: «Пассажир выбирает город назначения и получает рейсы этого направления с временем отправления и доступным количеством мест».

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

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

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

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

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

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

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

32-40 минут. Качество и цифровые транспортные системы

Теперь представим, что приложение уже работает. Его ценность зависит от того, насколько надёжно пассажир получает нужный результат. Рассмотрим несколько требований к качеству на нашем учебном примере.

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

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

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

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

Пятое: безопасность. В нашем сервисе пассажир должен видеть собственные бронирования, а диспетчер только доступные ему рабочие данные. Шифрование соединения защищает передаваемые сведения. Проверка прав и обработка пользовательского ввода требуют отдельных правил в приложении. [16, 36]

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

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

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

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

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

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

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

40-45 минут. Закрепление и завершение

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

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

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