Обычно веб-сайты представляют собой сложные и динамические структуры. На их разработку выделяют короткое время, чтобы сайт как можно быстрее заработал и давал эффект. Часто разработчики сразу же садятся за написание кода, даже не обдумав, что они собираются создавать, и как они это собираются сделать. Код для сервера часто пишется с листа, таблицы в базах данных создаются по мере надобности, и в итоге иногда архитектура системы начинает развиваться в совершенно непредсказуемом направлении. Однако с помощью простого моделирования и строгого подхода к программированию можно сделать процесс разработки гораздо более гладким и гарантировать, что созданную web-систему будет просто поддерживать в дальнейшем.
UML (Unified ModelingLanguage) - унифицированный язык моделирования - это язык, с помощью которого описываются системы. Следовательно этот язык может замечательно помочь вам описать и отобразить вашу будущую систему. Данная статья продемонстрирует некоторые способы, с помощью которых, используя язык UML, вы можете моделировать свои web-сайты. Язык UML может быть очень сложным в усвоении, но некоторыми частями UML пользоваться очень легко, а это поможет вам создавать лучшие системы в меньшие сроки. В качестве примера мы возьмем приложение, которое было описано в статье "Создание WML-приложения".
Поскольку в данной статье мы не будем вдаваться в специфику языка UML, я предлагаю вам ознакомиться с отдельной статьей под названием "Что нужно знать о UML", в которой как в справочнике описаны некоторые термины и знаки языка. В выноске к статье перечислены ссылки на ресурсы, из которых можно почерпнуть более глубокие знания как о UML, так и о достойных примерах его использования в дизайне.
Стадия планирования
Вне зависимости от того, строите ли вы систему с нуля, переносите ее на другую платформу или улучшаете ее функциональность, с самого начала требуется составить план, чтобы гарантировать принятие правильного решения. Когда вы работаете в группе, состоящей из нескольких человек, ясное понимание плана движения вперед и четкое распределение работы становятся просто неоценимыми. Постарайтесь основательно разобраться в следующих аспектах системы на стадии планирования:
· Кто будет пользователями системы, и каковы будут роли этих пользователей
· Требования приложения
· Взаиморасположение страниц и порядок перемещения между ними
· Инструменты и технологии, которые будут использоваться на сайте
Знайте своих пользователей
Важно знать, какие типы пользователей будут работать с вашей системой. И не только потому, что для анализа системы вам придется беседовать с представителями этих пользователей (анкеты, письма, личные беседыи т.д.), но и потому, что часто вам придется моделировать систему так, чтобы в ней работали пользователи с различными ролями и привилегиями. Классифицируя пользователей и изучая их требования, вы узнаете такие сведения, которые скажут вам, как надо строить базу данных, какие ограничения обеспечить, как сгруппировать страницы, как организовать обучение и помощь, какая специфическая информация должна быть на сайте, а кроме того - ваши знания о пользователях могут быть интересны и вашим рекламодателям.
Определите требования
Уточните, что именно вы собираетесь построить, прежде чем начнете работу. Хоть вас и будет мучить соблазн выяснять это по мере написания кода, гораздо более эффективно - провести "мозговой штурм", нарисовать пару схем и записать все на бумаге. Часто нерентабельно писать подробную спецификацию требований к сайту, но вы обязаны хотя бы приблизительно набросать пару диаграмм и написать пару строк о том, какие функции будет выполнять сайт. Вот именно здесь и приходят на помощь блочные диаграммы. Рассматривайте блоки-действия как пакет функций - как нечто, что обычно соответствует странице сайта, приложению или действию, осуществляемому на сайте (например: проверка пароля посетителя, изменение настроек пользователя или удаление устаревших пользователей).
Как правило все эти диаграммы и блоки-действия сопровождаются какими-то краткими описаниями. Есть несколько статей, где обсуждается то, как создаются диаграммы с блоками-действиями и как пишутся к ним объяснения (например, статья Алистер Кокбёрн - "Шаблон блоков-действий" - Alistair Cockburn's Use Case Template). Если вкратце, то вы обычно описываете, что должно произойти внутри блока-действия, кто этим действие будет пользоваться, как оно будет вызываться, как останавливаться, и какие варианты результатов действия могут получиться.
Спланируйте страницы
Во время работы над блоками-действиями у вас сформируются некоторые представления по поводу того, каких и сколько страниц понадобится создавать для сайта. Возможно еще до начала работы у вас будут хорошие идеи о некоторых из страниц, однако с помощью блочных диаграмм вы сможете взглянуть на проблему с другой точки зрения. Нужно ли посетителю сайта столько много страниц? Не слишком ли много функций возложено на эту страницу? Трудно ли перемещаться по сайту? Скажем, трудно ли попасть с первой страницы на одну из часто выполняемых функций? Найдите ответы на все эти вопросы в блочных диаграммах, т.е. до того, как вы начнете делать наброски своих страниц и создавать прототип сайта.
После того, как вырисуется в общих чертах диаграмма блоков-действий, можно приступать к грубой прикидке структуры сайта. Для этого опять-таки можно воспользоваться языком UML. Кто-то скажет, что страницы и файлы нужно моделировать с помощью инструмента, где используются компонентные диаграммы. Лично я нахожу, что с инструментами, где используются классовые диаграммы, работать проще.
Выберите инструменты
Для маленьких сайтов выбрать инструменты и технологии достаточно просто. В особенности в тех случаях, когда важную роль играет стоимость проекта, возможны лишь несколько комбинаций - Apache, MySQL или PostgreSQL, PHP или Perl или JSP/сервлеты. Самым популярным решением обычно оказывается комбинация Apache+ PHP + MySQL, а наличие дешевых хостингов с этой комбинацией только подталкивает к ее использованию. Более мощным web-сайтам требуется оценивать и проверять инструменты более тщательно, прежде чем вкладывать в них свои время и силы. Более подробное обсуждение по оценке и выбору сервера приложений можно найти в статье "Выберите правильный сервер приложений J2EE".
Steve Franklin and WebReview
перевод - Алекс Качанов (http://www.webmascon.com/)
