Процесс разработки приложений
для Web
Процесс разработки
приложения для работы в Internet/Intranet
мало отличается от процесса
создания обычной программы. Если
брать такие процессы разработки как
RUP, то
необходимо подходить к созданию любой
программы, будь то настольное
приложение или распределенные Web
сервисы – одинаково. Этапы процесса
практически не отличаются, лишь в
зависимости от объема реализуемых
функций они могут незначительно
сокращаться, пропуская создание
отдельных артефактов проекта.
Определение требований,
анализ, проектирование и реализация,
тестирование и развертывание – эти
стадии должен пройти любой
программный продукт, независимо для
какой платформы он создается, и в
какой программной среде он будет
функционировать.
При работе Web
приложения точно также как и в
обычной системе, пользователь
вводит и получает информацию,
работает с окнами и меню, сохраняет
данные на сервере и получает отчеты.
Единственное отличие заключается в
том, что само программное
обеспечение работает не на
компьютере пользователя, а на
удаленном сервере сети, а доступ
данным можно получить из любой
точки мира, где кабельные
сети или телефонная связь. С одной
стороны это удобно, а с другой
предъявляет дополнительные
требования к надежности
создаваемого программного
обеспечения.
Надежность Web
приложений
Любая программа должна
работать. И не просто работать, а
желательно без сбоев. Вы не можете
перезапускать систему несколько
раз в день из-за внутренних ошибок.
Вы не можете сказать, «выйдите все
из программы, сейчас я перезагружу
сервер», поскольку ваши
пользователи работают удаленно, в
разных городах или даже на разных
континентах.
Вы не можете остаться
после работы, чтобы «поколдовать» с
настройками, и установить новую
версию базы данных, пока никого нет
в системе. Для Web
приложений – это непозволительная
роскошь. У программы, работа с
которой осуществляется независимо
от часовых поясов, нет окончания
рабочего дня, в лучшем случает есть
только перерыв на профилактику.
Если ваша система
работает через сеть Internet,
то она должна быть доступна
двадцать четыре часа в сутки, семь
дней в неделю, триста шестьдесят
пять дней в году. Если нужна
профилактика, то нужно запускать
дублирующий сервер, но работа не
должна останавиться. Для ныне
модных программ электронной
коммерции (e-commerce)
любая остановка, будь то
профилактика или банальное «зависание»
системы, может принести миллионные
убытки, вот почему надежности
программного обеспечения для Web
уделяется так много внимания.
Однако не нужно и
перегибать палку. Создавать
программы при помощи ASP.NET
для управления через Internet
ядерным реактором, скорее всего
никто не будет, поэтому досконально
перепроверять каждую строчку кода
нет необходимости, хотя некоторым
программистам это будет весьма
полезно.
Многопользовательская работа
Для работы приложения,
ориентированного на Web, не важно кто
создает представление, с которым
работает пользователь. Какой
процессор, установленный на
домашнем компьютере или же где-то во
всемирной паутине рассчитывает
координаты для вывода кнопки на
экранной форме.
И при этом
многопользовательский режим работы
Internet
приложения – это не исключение, а
нормальный порядок работы. Если
программа для небольшого
предприятия может себе позволить
надолго заблокировать данные и
максимальным наказанием за это
будет ворчание трех-пяти
недовольных пользователей,
то Internet приложение не этого не может
сделать вовсе. Сама технология
доступа по протоколу TCP/IP
не позволяет долго поддерживать
канал связи с сервером.
А возможность в любой
момент закрыть окно своего броузера,
после банального обрыва модемной
связи не позволяет приложению точно
отследить текущую активность и
корректно завершить сеанс связи.
Поэтому, большинство приложений,
работающих в Web, используют максимально короткое,
насколько это возможно
блокирование данных.
Проблемы быстродействия
Для небольших
приложений, с которыми работают
несколько десятков пользователей в
локальной сети проблемы
быстродействия решаются просто.
Устанавливается высокоскоростная
сеть, если недостаточно пропускной
способности линии в 10 Mbit,
их заменяют на 100 Mbit,
прокладывают оптоволоконные
кабели, устанавливают
высококачественные
распределительные устройства. И
разработчики приложений этим
пользуются. Их не особенно заботит,
сколько мегабайт данных принимает и
передает их программа при просмотре
одного окна.
Порочная практика
использования запросов к базе
данных без ограничения полей и
записей, например: SELECT
* FROM BASE, приводит к передаче по
сети колоссальных массивов
ненужной информации. Экономия
времени разработчика на задании
ограничений и выборе только нужных
для конкретного случая полей базы
данных, приводит к перегрузке сети.
Особенно это ощущается в начале
рабочего дня, когда все
пользователи одновременно начинают
работать с программной системой.
Однако если в локальной
сети с этим еще можно как-то
мириться, поскольку объемы
передаваемых данных скрадываются
все увеличивающимся
быстродействием сети, то созданным
по такому же принципу Web
приложению работать будет
невозможно. Хотя скорости модемов
постоянно растут, и многие
пользователи работают с выделенной
линией Internet, но тут возникает вопрос оплаты
трафика, при котором каждый лишний
мегабайт данных, переданный по сети,
будет оплачиваться из кармана
пользователя.
Помня о том, как
замечательно выглядит собственная
домашняя страничка, написанная с
большим объемом графики и анимации,
разработчики иногда забывают, что
профессиональное приложение для Web
должно не только и не столько
красиво выглядеть, сколько
выполнять свои прямые функции и
быстро загружаться на любых линиях.
Ожидание пользователя
более 10 секунд при переключении со
страницы на страницу приложения
может привести как минимум к
раздражению, и в конечном итоге к
возможному отказу от работы с такой
системой вовсе.
Итоги
Сам процесс разработки приложений
для Web мало чем отличается от
процесса, используемого при
создании настольных приложений,
однако технические средства, а
также удаленность пользователей
накладывают на разработчика
определенные ограничения, которые
нужно учитывать чтобы исключить,
или хотя бы уменьшить проблемы при
эксплуатации готовой системы.
Список статей:
Еще статьи
>>>
Статьи