Базовая модель Web-процесса

MIME

HTTP

Сетевые и сопутствующие протоколы

В числе протоколов, составляющих основу Internet, присутствует стек сете­вых протоколов TCP/IP. Не единственный протокол, но целая группа тако­вых, именно TCP/IP делает возможным все службы, существующие в Inter­net. В отдельности, IP (Internet Protocol, протокол Internet) предоставляет базовую информацию, связанную с адресацией и маршрутизацией, необхо­димую для доставки данных по сети Internet. С другой стороны, TCP (Transport Control Protocol, протокол управления передачей) обеспечивает средства, делающие коммуникации надежными, такие, как коррекция и по­вторная передача. Объединив их вместе, в сочетании со службой доменных имен (Domain Name Service, DNS), представляющей собой процесс преобра­зования полностью определенных доменных имен вроде www.webdesignref.com, в соответствующие им IP-адреса (66.45.42.235), мы получаем возможность создавать в сети Internet службы высокого уровня, такие как электронная почта или Web-сайты. Знание протоколов низкого уровня многим Web-дизайнерам может показаться бессмысленным, однако при разработке в высшей степени масштабируемых Web-сайтов понимание подробностей организации сетей оказывается особенно полезным. Как бы то ни было, не­зависимо от задач сайта, в следующем протоколе, который мы будем обсуж­дать, должен разбираться каждый Web-дизайнер.

HTTP (Hypertext Transport Protocol, протокол передачи ^гипертекста) — это протокол прикладного уровня, отвечающий за взаимодействие между аген­том пользователя (которым обычно является Web-браузер) и Web-сервером. Этот простой протокол определяет восемь основных команд (GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE и CONNECT), которыми агент пользователя может воспользоваться- для запроса или управления данными. В ответах могут содержаться как числовые, так и текстовые коды (к приме­ру, 404 Not Found) и сопутствующие данные.

Простота протокола HTTP — это одновременно и счастье, и напасть. Его несложно реализовать, однако недостаток управления состоянием и пробле­мы с производительностью приносят Web-разработчикам неприятности. Спецификация HTTP 1.1, определенная в документе RFC 2616, была обра­щена ко многим проблемам, связанным с производительностью, однако управление состоянием до сих пор приходится осуществлять с помощью cookies, скрытых переменных данных или расширенных адресов. Обзор HTTP дается в главе 17, в то время как в приложении 7 приводятся подроб­ности, касающиеся его форматов запроса и ответа.

MIME (Multipurpose Internet Mail Extensions, многоцелевые расширения электронной почты в Internet), невоспетый герой Web-протоколов, исполь­зуется браузерами для определения типа данных, получаемых ими с сервера. В частности, HTTP-заголовок под названием content-type содержит значе­ние MIME, которое браузер отыскивает для того, чтобы понять, данные ка­кого типа он получает и что с ними делать. Серверы присоединяют MIME-типы к HTTP-заголовкам, генерируя их из программы или привязывая рас­ширение файла (к примеру, html) к соответствующему MIME-типу (к при­меру, text/html). MIME позволяет Web-сайтам представлять данные любого типа, а не только распространенные в Web форматы вроде HTML.

8.4.3. Адресация: URL/URI/URN/URC

Для запроса Web-страницы и связывания с ней необходимо использовать схему адресации. Пользователи Internet знакомы с унифицированным указа­телем ресурса (Uniform Resource Locator, URL), таким как http:// www.webdesignref.com/, определяющим протокол и местонахождение. В спе­цификациях более широко принятым термином, обозначающим короткие имена или строку адреса, ссылающуюся на ресурс в Internet, является уни­фицированный идентификатор ресурса (Uniform Resource Identifier, URI). Тем не менее, каково бы ни было название, URI и URL не предоставляют всей информации, которая может потребоваться в Internet в будущем, т. к. они указывают лишь на местонахождение.

ЛЕКЦИЯ 9. Процесс web-дизайна. Планирование сайта. Размещение и продвижение сайта. (2 часа)

Основная или базовая модель процесса, предполагаемая для использования при разработке Web-сайтов, должна быть, прежде всего, близка большинст­ву людей, по крайней мере, по смыслу, т. к. она является дедуктивной Ба­зовая модель начинается с общей картины, а затем сужается до конкретных шагов, необходимых для завершения сайта. В сфере производства про­граммного обеспечения подобная модель носит название "водопад" (waterfall model) или, иногда, "модель жизненного цикла программного обеспечения" (software lifecycle model), т. к. она описывает именно фазы жизненного цик­ла прикладной программы.

Рисунок 9.1.Модель водопада

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

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

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

Дата добавления: 2015-05-26