Институт управления, бизнеса и права учебно-методический комплекс (стр. 2 )

Тематику Web-приложения студенты формируют самостоятельно.

1.6  Учебно-методическое обеспечение дисциплины

1.6.1. Основная литература

№ п/п	Перечень литературы
1.	Мацяшек требований и проектирование систем (Разработка информационных систем с использованием UML) : учебно-методическое пособие / Л. Мацяшек - Москва : Вильямс, 20c.
2.	Информационная архитектура: чертежи для сайта – М.: КУДИЦ-ОБРАЗ, 2004. – 320 с.
3.	Торрес руководство по проектированию и разработке пользовательского интерфейса : руководство / - Москва : Вильямс, 20c.
4.	Применение UML и шаблонов проектирования : книга / К. Ларман - Москва : Вильямс, 20c.

1.6.2. Дополнительная литература

№ п/п	Перечень литературы
1.	PHP 4: разработка Web-приложений. Библиотека программиста. - СПб.: Питер, 20с.
2.	PHP 4. Учебный курс. – СПб.: Питер, 20с.
3.	MySQL 5.0 : книга / В. Гольцман - Санкт-Петербург : Питер, 20c.
4.	Браун веб-сайта. Взаимодействие с заказчиком, дизайнером и программистом : книга / - Санкт-Петербург : Питер, 20c.
5.	и др. Защита от хакеров Web-приложений – М.: АйТи, ДМК Пресс, 2004 – 496 с.
6.	Разработка Web - приложений с помощью PHP и MySQL : пособие / Л. Веллинг, Л. Томсон - Москва : Питер, 20c.

1.7  Информационно-методическое обеспечение

Информационно методическое обеспечение дисциплины включает УМК, компьютерные программы, электронные учебники, Интернет-ресурсы приведенные в таблице 1.1.

Таблица 1.1 – Обеспечение дисциплины

№ п/п	Перечень
1.	IE
2.	PHP 5
3.	My SQL
4.	MS-Visio
5.  BP	BP-Win, ER-Win
6.	Rational Rose
7.	Материалы сервера ИУБиП

2  Лекции

Лекция 1.Определение архитектуры Web-приложений

План

1. Архитектура приложений

2. Архитектурные шаблоны Web-приложений

3. Шаблон Thin Web Client

4. Шаблон Thick Web Client

5. Шаблон Web Delivery

Содержание

1. Архитектура приложений

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

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

2. Архитектурные шаблоны Web-приложений

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

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

Основными шаблонами являются:

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

2. Thich Web Client предполагает, что значительная часть бизнес-логики выполняется на клиентской машине. Обычно для выполнения бизнес-логики используется динамический HTML, аплеты Java или управляющие элементы ActiveX. Взаимодействие с сервером по-прежнему происходит через протокол HTTP.

3. Web Delivery. При взаимодействии клиента и сервера, кроме протокола HTTP, используются и другие протоколы, такие как IIОР, DCOM, которые могут применяться для поддержки системы распределенных объектов. В данном случае браузер функционирует как контейнерный модуль системы распределенных объектов.

3. Шаблон Thin Web Client

Шаблон на основе «тонкого» клиента полезно использовать в тех приложениях, в которых можно гарантировать наличие только минимальной конфигурации клиента. Этот шаблон больше всего подходит для Web-приложений, когда клиент обладает минимальными вычислительными возможностями или не может управлять своей конфигурацией.

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

Структура шаблона. Основные компоненты архитектуры размещаются на сервере. В большинстве случаев – это минимальная структура Web-приложения. Основные компоненты:

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

■  Web-сервер – главная точка доступа для всех клиентских браузеров. В архитектуре тонкий клиент браузеры получают доступ к системе только через Web-сервер, который принимает запросы на получение Web-страниц – либо статических, либо динамических (формируемых на сервере). В зависимости от запроса Web-сервер может инициировать некоторые серверные процессы. Если запрос сгенерирован на получение серверной страницы со сценариями, модулями CGI, ISAPI, то Web-сервер передает эту страницу для обработки соответствующему интерпретатору сценариев или исполняемому модулю. Результатом обработки является отформатированная HTML-страница, которую можно отобразить в браузере.

■  Соединение HTTP – стандартный протокол взаимодействия клиентских браузеров и серверов. Каждый раз, когда клиент и сервер обмениваются информацией, устанавливается новое независимое соединение.

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

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

■  Сервер приложения – основное средство для выполнения бизнес-логики в серверной части приложения. В обязанности сервера приложений входит выполнение кода серверных страниц.

■  Дополнительный элемент – база данных. Во многих Web-приложениях база данных используется для хранения коммерческой информации. В некоторых случаях база данных используется для хранения самих страниц (однако такое ее применение относится к другому архитектурному шаблону).

Простейший способ соединения системы с базой данных заключается в обеспечении для сценариев серверных страниц возможности прямого доступа к компоненты хранения данных. Существуют стандартные библиотеки доступа к данным, такие как RDO(Remote Data Object), ADO (ActiveX Data Object), ODBC (Open Database Connectivity), JDBC (Java Database Connectivity).

На рис. 1.1 представлено логическое представление архитектурного шаблона "тонкого" Web-клиента.

Рис. 1.1. Архитектура на основе "тонкого" Web-клиента

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

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

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

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

4. Шаблон Thick Web Client

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

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

Структура шаблона. Поскольку архитектурный шаблон Thick Web Client является расширением архи­тектуры на основе "тонкого" Web-клиента, в обоих шаблонах имеются одни и те же базовые элементы, к которым добавляются некоторые дополнительные компоненты.

■  Клиентский сценарий (Client script) — сценарий JavaScript или VBScript, внедренный в отформатированные страницы HTML. Броузер интерпретирует сценарии. Консорциум W3C определил стандарт HTML и интерфейс объектной
модели документа DOM (Document Object Model), которые позволяют броузеру
обрабатывать клиентские сценарии.

■  Документ XML (XML document) —- документ на языке XML (Extensible Markup
Language). В документах XML представляется содержимое (данные) без элемен­
тов форматирования.

■  Управляющий элемент ActiveX (ActiveX control) — загружаемый при необходимо­сти СОМ-объект, на который может ссылаться клиентский сценарий. Как и
любой другой СОМ-объект, он имеет полный доступ к клиентским ресурсам.
Основной механизм обеспечения безопасности клиентских компьютеров за­
ключается в применении алгоритмов аутентификации и цифровых подписей.
Броузеры можно настроить таким образом, чтобы при загрузке управляющих
элементов ActiveX на клиентский компьютер пользователю выдавалось предупреждающее сообщение. Механизмы аутентификации позволяют идентифици­
ровать автора управляющего элемента посредством анализа подписи, выданной
одним из пользующихся доверием агентств по выдаче сертификатов.

■  Аплет Java (Java applet) — платформно-независимый откомпилированный компонент, запускаемый в контексте броузера. Для обеспечения требуемого уровня
безопасности аплет имеет ограниченный доступ к клиентским ресурсам. Java-аплеты могут использоваться как для создания сложных элементов пользова­тельского интерфейса, так и для анализа документов XML или инкапсуляции
сложных правил бизнес-логики.

■  Компонент JavaBean — небольшой Java-компонент, предназначенный для выполнения определенной задачи и поддерживающий некоторый набор интерфейсов, позволяющих встраивать его в более сложные системы. Управляющие
элементы ActiveX являются аналогом компонентов JavaBean в архитектурах,
разработанных компанией Microsoft.

На рис. 1.2 представлена архитектура на основе "толстого" Web-клиента.

Рис. 1.2. Архитектура на основе "толстого" Web-клиента

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

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

При использовании этого шаблона очень важно обеспечить переносимость прило­жения между различными реализациями броузеров. Не все HTML-броузеры поддер­живают сценарии JavaSCript и VBScript. Кроме того, управляющие элементы ActiveX могут применяться лишь на клиентских компьютерах под управлением операционной системы Windows компании Microsoft. Даже если используются броузеры известных производителей, всегда присутствуют, пусть незначительные, но все же отличия в реализации модели DOM.

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

5. Шаблон Web Delivery

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

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

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

Структура. Наиболее существенное отличие шаблона Web Delivery от других архитектурных шаблонов Web-приложений заключается в методе, используемом при взаимодействии клиента и сервера. В других шаблонах в качестве основного механизма применяется не поддерживающий соединения протокол HTTP, который ограничивает возможности раз­работчика, если необходимо обеспечить интерактивное взаимодействие клиента с серве­ром. К важным элементам шаблона Web Delivery относятся все элементы шаблона Thin Web Client, к которым добавляются следующие дополнительные компоненты.

■  DCOM — распределенная объектная модель компонентов, разработанная компанией Microsoft. Модель DCOM обеспечивает возможность объектам, разме­щенным на одном компьютере, взаимодействовать и использовать методы объектов другой машины.

■  IIОР— протокол, входящий в состав технологии CORBA группы OMG. Этот
протокол обеспечивает возможность взаимодействия с распределенными объектами через Internet или любую сеть TCP/IP.

■  RMI (JRMP) — механизм Java, позволяющий взаимодействовать с объектами,
содержащимися на других машинах. JRMP (Java Remote Method Protocol) — естественный протокол для RMI, но его использовать не обязательно. Механизм
RMI можно реализовать на базе протокола ПОР спецификации CORBA.

На рис. 1.3 представлено логическое представление архитектурного шаблона Web Delivery.

Рис.1.3 Архитектура на основе шаблона Web Delivery

Основные принципы поведения. Наиболее важный аспект шаблона Web Delivery заключается в использовании броузера для доставки объектов распределенных систем. Броузер используется для предоставления пользовательского интерфейса и хранения некоторых объектов, кото­рые независимо от него взаимодействуют с объектами серверного уровня. Взаимодей­ствие между клиентскими и серверными объектами осуществляется с использованием протоколов ПОР, RMI и DCOM.

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

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

Лекция 2. Требования и прецеденты при разработке Web-приложений

План

1. Понятие и классификация требований к приложениям

2. Основы инженерии требований

3. Документирование требований

Содержание

1.  Понятие и классификация требований к приложениям

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

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

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

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

Различие между пользовательскими и системными требованиями показаны в примере 2.1.

Пример 2.1.

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

Спецификация системных требований.

  Пользователь должен иметь возможность определять тип внешних файлов.

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

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

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

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

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

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

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

Пример 2.2. Функциональные требования.

1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству каталожных баз данных или по определенному их подмножеству.

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

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

Пример 2.3. Нефункциональные требования

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

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

2.  Основы инженерии требований

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

Рисунок 2.1 – Процесс разработки требований

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

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

1. Отвечает ли система целям организации заказчика и разработчика?

2. Можно ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости?

3. Можно ли объединить систему с другими системами, которые уже эксплуатируются?

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

1.  Что произойдет с организацией, если система не будет введена в эксплуатацию?

2.  Какие текущие проблемы существуют в организации и как новая система поможет их решить?

3.  Требует ли разработка системы технологии, которая до этого не использовалась в организации?

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

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

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

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

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

Методами определения требований могут быть интервью, “мозговой штурм” (brainstorming), схемы мышления (mind mapping), метод упрощенной спецификации приложения, совместная разработка приложений (JAD), определение пользовательских сценариев, метод VORD.

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