Обычно веб-сайты представляют собой сложные и динамические структуры. На их разработку выделяют короткое время, чтобы сайт как можно быстрее заработал и давал эффект. Часто разработчики сразу же садятся за написание кода, даже не обдумав, что они собираются создавать, и как они это собираются сделать. Код для сервера часто пишется с листа, таблицы в базах данных создаются по мере надобности, и в итоге иногда архитектура системы начинает развиваться в совершенно непредсказуемом направлении. Однако с помощью простого моделирования и строгого подхода к программированию можно сделать процесс разработки в гораздо более гладким и гарантировать, что созданную web-систему будет просто поддерживать в дальнейшем.
UML (Unified Modeling Language) - унифицированный язык моделирования - это язык, с помощью которого описываются системы. Следовательно этот язык может замечательно помочь вам описать и отобразить вашу будущую систему. Данная статья продемонстрирует некоторые способы, с помощью которых, используя язык UML, вы можете моделировать свои web-сайты. Язык UML может быть очень сложным в усвоении, но некоторыми частями UML пользоваться очень легко, а это поможет вам создавать лучшие системы в меньшие сроки. В качестве примера мы возьмем приложение, которое было описано в статье "Создание WML-приложения".
Поскольку в данной статье мы не будем вдаваться в специфику языка UML, я предлагаю вам ознакомиться с отдельной статьей под названием "Что нужно знать о UML", в которой как в справочнике описаны некоторые термины и знаки языка. В выноске к статье перечислены ссылки на ресурсы, из которых можно почерпнуть более глубокие знания как о UML, так и о достойных примерах его использования в дизайне.
Стадия планирования
Вне зависимости от того, строите ли вы систему с нуля, переносите ее на другую платформу или улучшаете ее функциональность, с самого начала требуется составить план, чтобы гарантировать принятие правильного решения. Когда вы работаете в группе, состоящей из нескольких человек, ясное понимание плана движения вперед и четкое распределение работы становятся просто неоценимыми. Постарайтесь основательно разобраться в следующих аспектах системы на стадии планирования:
- Кто будет пользователями системы, и каковы будут роли этих пользователей
- Требования приложения
- Взаиморасположение страниц и порядок перемещения между ними
- Инструменты и технологии, которые будут использоваться на сайте
Знайте своих пользователей
Важно знать, какие типы пользователей будут работать с вашей системой. И не только потому, что для анализа системы вам придется беседовать с представителями этих пользователей (анкеты, письма, личные беседы и т.д.), но и потому, что часто вам придется моделировать систему так, чтобы в ней работали пользователи с различными ролями и привилегиями. Классифицируя пользователей и изучая их требования, вы узнаете такие сведения, которые скажут вам, как надо строить базу данных, какие ограничения обеспечить, как сгруппировать страницы, как организовать обучение и помощь, какая специфическая информация должна быть на сайте, а кроме того - ваши знания о пользователях могут быть интересны и вашим рекламодателям.
Рис. 1: Иерархия исполнитель-роль
На представленном выше рисунке изображены несколько групп пользователей (называемые на языке UML "исполнителями" (actors), которые будут работать с web-сайтом. В данном случае самый общий тип пользователя ("Пользователь сайта" - Site user) расположен вверху диаграммы. Сплошная стрелка обозначает отношение обобщения, то есть у нас имеются две более специфические категории пользователей: посетители-гости и зарегистрированные пользователи. Характеристики, которые будут общими у обеих групп пользователей, будут приписаны исполнителю "пользователь сайта", а привилегии, специфичные для посетителей-гостей и зарегистрированных пользователей, будут приписаны более мелкой соответствующей роли. В зависимости от используемой программы, вы можете прямо в диаграмме создавать описания и прикреплять их к определенному исполнителю, т.е. вам нет необходимости создавать отдельно диаграмму и отдельно документы, ее описывающие. В данном приложении помимо прочего пользователи делятся на посетителей, подключившихся к сайту по беспроводной связи, и администраторов. Обе эти группы - дальнейшая подразделение группы зарегистрированных пользователей, в системе у них будут различные функции.
Определите требования
Уточните, что именно вы собираетесь построить, прежде чем начнете работу. Хоть вас и будет мучить соблазн выяснять это по мере написания кода, гораздо более эффективно - провести "мозговой штурм", нарисовать пару схем и записать все на бумаге. Часто нерентабельно писать подробную спецификацию требований к сайту, но вы обязаны хотя бы приблизительно набросать пару диаграмм и написать пару строк о том, какие функции будет выполнять сайт. Вот именно здесь и приходят на помощь блочные диаграммы. Рассматривайте блоки-действия как пакет функций - как нечто, что обычно соответствует странице сайта, приложению или действию, осуществляемому на сайте (например: проверка пароля посетителя, изменение настроек пользователя или удаление устаревших пользователей). Следующий рисунок представляет собой краткую диаграмму блоков-действий, с помощью которой планируется web-сайт. Обратите внимание, что на данной диаграмме не показаны все действия, предусмотренные в нашем приложении - обычно для описания всей функциональности будущего сайта создается несколько диаграмм.
Рис.2: Диаграмма блоков-действий
Даже с помощью такой простой диаграммы как эта, можно запросто описать огромный объем информации. Например, отношение включения ("include"), показывает, что два определенных действия включают в себя одну и туже функцию аутентификации пользователя. Отношение расширения ("extend") указывает, что страница с информацией о погоде может выдаваться как в HTML так и в WML-формате. Отношение обобщения ("generalization") показывает, что для выдачи конкретных страниц будет использовать более общая процедура, под называнием "выдача HTML-страницы" или "выдача WML-страницы" с целью обеспечить единство внешнего вида и поведения всех страниц на web-сайте.
Также диаграмма показывает, что посетители подключенные к сайту по беспроводной связи, будут иметь доступ к тем его разделам, которые не будут видны для других посетителей. В данной диаграмме только эта группа пользователей может посмотреть отчеты о дорожной обстановке. Мы посчитали, что отчеты о дорожной обстановке понадобятся лишь людям, находящимся в пути, и потому нам нет нужды прилагать усилия по генерации страниц в каких-то иных форматах, кроме формата WML. Следовательно, действие "Выдать отчет о дорожной обстановке" не нужно расширять (extend) вариантами WML или HTML страниц, оно может напрямую включить (include) действие "Создать WML-страницу".
Как правило все эти диаграммы и блоки-действия сопровождаются какими-то краткими описаниями. Есть несколько статей, где обсуждается то, как создаются диаграммы с блоками-действиями и как пишутся к ним объяснения (например, статья Алистер Кокбёрн - "Шаблон блоков-действий" - Alistair Cockburn's Use Case Template). Если вкратце, то вы обычно описываете, что должно произойти внутри блока-действия, кто этим действие будет пользоваться, как оно будет вызываться, как останавливаться, и какие варианты результатов действия могут получиться.
Спланируйте страницы
Во время работы над блоками-действиями у вас сформируются некоторые представления по поводу того, каких и сколько страниц понадобится создавать для сайта. Возможно еще до начала работу у вас будут хорошие идеи о некоторых из страниц, однако с помощью блочных диаграмм вы сможете взглянуть на проблему с другой точки зрения. Нужно ли посетителю сайта столько много страниц? Не слишком ли много функций возложено на эту страницу? Трудно ли перемещаться по сайту? Скажем, трудно ли попасть с первой страницы на одну из часто выполняемых функций? Найдите ответы на все эти вопросы в блочных диаграммах, т.е. до того, как вы начнете делать наброски своих страниц и создавать прототип сайта.
После того, как вырисуется в общих чертах диаграмма блоков-действий, можно приступать к грубой прикидке структуры сайта. Для этого опять-таки можно воспользоваться языком UML. Кто-то скажет, что страницы и файлы нужно моделировать с помощью инструмента, где используются компонентные диаграммы. Лично я нахожу, что с инструментами, где используются классовые диаграммы, работать проще (см. следующий рисунок).
Рис. 3: Диаграмма страниц
На данной диаграмме все функции сайта были распределены на несколько областей:
- / - корень сайта
- /common/ - общие функции, изображения, скрипты, таблицы стилей и так далее
- /maps/ - изображения карт и направлений
- /traffic/ - отчеты о дорожной обстановке
- /weather/ - отчеты о погоде
Данный рисунок также показывает, какие параметры передаются между страницами. Переменная regionId - самая главная, так как она обозначает район, в котором заинтересован пользователь (будь то код округа, города или провинции). С помощью переменной regionId вы передаете информацию о регионе между страницами, таким образом пользователь сможет перейти от отчета о погоде к отчету о дорожной обстановке в том же самом регионе. Что касается каталога common, то здесь вы видите, что область состоит из целого пакета (package), а не из отдельных файлов. Это просто прием укрощения хаоса в диаграмме, так как пакеты будут взаимно использовать большинство, если не все, файлы, расположенные в каталоге /common/.
Данная диаграмма очень полезна для планирования сайта, так как она помогает избежать путаницы. Кроме того она служит вам шаблоном, которым вы будете пользоваться при создании других web-сайтов с такой же структурой.
Выберите инструменты
Для маленьких сайтов выбрать инструменты и технологии достаточно просто. В особенности в тех случаях, когда важную роль играет стоимость проекта, возможны лишь несколько комбинаций - Apache, MySQL или PostgreSQL, PHP или Perl или JSP/сервлеты. Самым популярным решением обычно оказывается комбинация Apache + PHP + MySQL, а наличие дешевых хостингов с этой комбинацией только подталкивает к ее использованию. Более мощным web-сайтам требуется оценивать и проверять инструменты более тщательно, прежде чем вкладывать в них свои время и силы. Более подробное обсуждение по оценке и выбору сервера приложений можно найти в статье "Выберите правильный сервер приложений J2EE". На следующем рисунке показана примерная компонентная диаграмма, с помощью которой описывается архитектура сайта. Данная простая диаграмма пожалуй подойдет для описания многих web-сайтов, работающих сейчас в Сети. Следовательно ее не придется каждый раз воссоздавать заново, так как в ней нет какой-либо интересной, специфической или уникальной информации.
Рис. 4: Диаграмма архитектуры
Мы не будем описывать весь цикл разработки программного продукта в данной статье, но важно отметить, что именно теперь можно начинать создавать макет сайта и прототипы страниц. Запишите на будущее пару идей по структуре сайта и организации его страниц, так как в конечном счете вам захочется создать какой-то общий код, генерирующий меню, боковые панели и общую компоновку страниц, чтобы использовать его в других сайтах. Кроме того, если вы переносите проект на новые инструменты и технологии, прототипы помогут выяснить вам, насколько дизайн осуществим при данных условиях, и насколько ваша команда подготовлена к использованию новых инструментов.
Этап дизайна
Этап дизайна должен накладываться на этап анализа - уже в то время, когда вы узнаете все больше и больше подробностей о будущей системы, вы начинаете делать наброски того, как она будет построена. Невозможно сначала на 100% проанализировать систему, а затем прямо перейти к ее дизайну. Часто требования к системе развиваются, а иногда и ваша идея построения системы может послужить толчком к развитию требований к ней (и наоборот). Все разработчики занимаются дизайном - но некоторые занимаются им прямо во время написания кода. Вообще-то это работает, но при таком методе труднее становится управлять сложным кодом и совместно работать на ним в команде. Несколько минут потраченные на моделирование системы с помощью диаграмм в конце окупят с лихвой.
Дизайн на будущее
Большинство разработчиков проводит большую часть времени за отлаживанием и переделкой кода чем, за его написанием. В особенности это справедливо, когда вам приходится работать над несколькими web-сайтами сразу. Хорошие дизайнерские находки можно переносить с одного сайта на другой в части структуры, организации и построения кода. Однако если вы наворотите код без предварительного планирования, преимущества его использования в перспективе сойдут на нет. Очень эффективным способом визуального изображения сайта является построение нескольких диаграмм классов. Приведенные рисунки показывают несколько ключевых отношений, используемых в диаграммах классов.
Рис. 5: Диаграмма классов
Диаграммы, подобные приведенной выше, можно построить очень быстро. Эта диаграмма, например, изображает мой сайт, о котором я говорил в предыдущей статье - Введение в WML. На ее создание ушло примерно 15 минут. Однако она сослужила хорошую службу при создании и поддержке демо-версии сайта, и позволила избежать переделки кода, которая была бы неизбежной в другом случае. Мне бы хотелось обратить ваше внимание в диаграмме на несколько ключевых моментов (пожалуй, вам предварительно стоит ознакомиться с описанием приложения в предыдущей статье о WML).
- Класс Renderer является абстрактным классом - его имя выделено курсивом. Это значит, что он не будет использоваться напрямую, лишь его потомки-подклассы будут инициализированы (например Region()). Все страницы, выводящие информацию на экран, должны быть подклассами этого класса, чтобы обеспечить задачу вывода информации для любого типа броузера.
- Класс WeatherReport отвечает за создание и владение всех объектов Region. На схеме это отношение изображено с помощью черного ромба, обозначающего сильное отношение группировки (aggregation). Это значит, что один объект владеет другими объектами и создает их.
- Знак "+" перед названиями методов обозначает, что эти методы имеют тип public, и они могут быть вызваны из других объектов или функций. Знак "-" обозначает, что переменная или метод имеют тип private, и они видимы только функциям, принадлежащим данному объекту. В PHP все методы и переменны имеют тип public, но мы должны всегда рассматривать эти переменные как private-переменные, и не должны к ним обращаться напрямую.
- Класс HTMLWeatherReport зависит от класса HTMLUtils. Отношение зависимости (dependency) обозначает, что один класс инициализирует и/или вызывает функции другого класса.
- В каждом классе диаграммы классов должны быть указаны все методы (и переменные. Если таковые имеются), их видимость (тип public, private или protected), тип значения, возвращаемого каждой функцией, аргументы-параметры этих функций, и также типы данных переменных. Функции указываются первыми, а за ними в отдельном блоке перечисляются переменные.
Если система, которую вы строите, не является объектно-ориентированной, диаграммы классов все равно могут помочь вам создать модель приложения. Классы вместо объектов просто будут обозначать различные включаемые файлы и функции. В этом случае на вашей диаграмме будут отсутствовать отношения наследования, слияния (composition), группировки (aggregation) и прочие отношения из ООП. НО тем не менее ваша диаграмма должна показывать с помощью стрелок-зависимостей, какие файлы какими файлами вызываются.
Моделирование работы системы
Иногда необходимо показать, как куски все составные части системы будут работать вместе в процессе. Диаграмма классов показывает все отношения между классами, но не показывает порядок в котором делаются вызовы и то, как результат выполнения одной функции определяет какая функция будет вызываться следующей. Для того, чтобы показать более динамические аспекты системы, язык UML предлагает ряд диаграмм различного типа. Диаграммы сценариев (Scenario diagrams) особенно полезны, если вы разрабатываете модель веб-сайта. Диаграммы сценариев делятся на два вида: диаграммы взаимодействия (collaboration diagrams) и диаграммы последовательностей (sequence diagrams). Как правило не приходится моделировать все действия, происходящие в системе. Обычно, диаграммы сценариев служат для отображения самых сложных частей системы, либо для общего схематического изображения работы кода. Например, с помощью этой диаграммы можно показать, как код проверки пользователя вставляется в определенную страницу, либо показать, как набор утилит служит в различных страницах для создания единого интерфейса сайта. Два типа диаграмм сценариев приведены ниже на рисунках.
Рис. 6. Диаграмма взаимодействия
Данная диаграмма взаимодействия показывает дизайн того, как на веб-сайте будет создаваться отчет о погоде. Реальный код, стоящий за диаграммой, можно найти в предыдущей статье - введении в WML (исключая механизм проверки пользователя). Некоторые незначительные методы на диаграмме не присутствуют потому, что я был заинтересован в моделировании ключевых шагов процесса. Вы сами можете проследить выполнение методов от "1" до "1.3.3.4". в некоторых командах принято нумеровать диаграммы как 1, 2, 3, 4, но вообще-то лучше показывать глубину вызовов используя следующую нотацию: 1, 1.1, 1.2, 2, 2.1 и так далее. эта схема нумерации показывает систему передачи вызовов более наглядно. Например, диаграмма показывает, что метод report() вызывает несколько функций в объектах WMLUtil и Region. Функция buildHeader(...) в WMLUtil вызывается до того, как мы начали создавать отчет с помощью других функций. Наконец, мы вызываем метод buildFooter(...) в модуле WMLUtil до того, как возвращаемся к методу report() и из него - к методу getPage(). В диаграммы взаимодействия можно добавлять более подробную информацию, например, тип возвращаемых данных, ограничения на данные и прочие условия.
Рис. 7. Диаграмма последовательностей
Диаграмма последовательностей очень похожа на диаграмму взаимодействий по тому, какую информацию они показывают. Вообще-то, многие программы UML способны создавать диаграммы последовательностей из диаграмм взаимодействий и обратно. Главное отличие диаграммы последовательностей в том, что на этой диаграмме легче проследить последовательность действий. Кроме того, на этой диаграмме можно указать подробную информацию о времени существования того или иного объекта или о его поведении (например, время ожидания, взаимодействие параллельных нитей процесса, момент создания и уничтожения объектов).
Когда возникает вопрос, какую диаграмму строить, я использую несколько критериев, которые помогают мне выбрать наиболее подходящий вариант:
- Используйте диаграмму последовательностей, если вы хотите показать детали кода, относящиеся к временным и межпроцессорным взаимодействиям
- Используйте диаграмму взаимодействий, если вы пытаетесь показать цепь взаимодействий между объектами
- Используйте диаграмму последовательностей, если вы хотите показать одновременные взаимодействия между несколькими объектами
- Используйте диаграмму взаимодействий, если вы хотите показать большое количество взаимодействий или передачи сообщений между малым количеством объектов.
План развертывания приложения
Как было сказано в первой части данной статьи, большинство веб-сайтов не отличаются сложной архитектурой. Однако диаграммы развертывания системы все равно могут представлять для вас интерес по двум причинам: они показывают архитектуру и организацию файлов. Что касается организации файлов, то я предпочитаю работать с инструментами моделирования классов так, как описано в первой части в разделе " Спланируйте страницы ". Здесь же, я упомяну для справки диаграмму компонентов, но в зависимости от сложности сайта вы можете сами решать, нужна она или нет. Следующий ниже пример намеренно использует больше машин (узлов), чем наш простой реальный пример, который вполне уместился бы на одной машине, ну разве что в будущем его понадобилось бы промасштабировать для обслуживания более массовой аудитории.
Рис.8: Диаграмма компонентов
Принципы хорошего дизайна
UML - это всего лишь инструмент. Если им правильно пользоваться, он облегчит вам работу по созданию хороших сайтов. Но ключом к созданию хорошего сайта являются принципы хорошего дизайна, и никакая нотация не обучит вас им. На эту тем есть множество книг, но я попытаюсь осветить лишь несколько самых главных вопросов.
Пишите цельный и несплетенный код
Эту фразу постоянно повторяют при описании принципов объектно-ориентированного программирования. Цельный класс объединяет в себе все поведения и всю информацию, которые имеют общее назначение или задачу. Это значит, что вам не следует будет наполнять код пользовательского интерфейса математическими алгоритмами, или например вам следует поместить все операции и информацию о пользователе в один класс UserAccount. Цельный дизайн важен по ряду причин. Он помогает сократить число зависимостей классов друг от друга, позволяет создать более интуитивный и понятный дизайн, упрощает процесс разъяснения дизайна для других разработчиков, и сокращает количество классов, с которыми разработчику приходится одновременно работать. Например, если вам придется делать изменения в механизм проверки пользователя на вашем сайте, удобнее было бы изменить только один файл, чем несколько.
Несплетенный (decoupled) дизайн означает уменьшение числа взаимодействий между классами или файлами. Такой дизайн не только проще понять и объяснить своим коллегам по команде, но его и проще поддерживать. Посмотрите на следующий пример:
Рис. 9: Пример дизайна №1
Не зная ничего о назначении каждого из изображенных классов, не разумно давать оценку их целостности. Тем не менее, диаграмма показывает, что отношения между классами изящно сведены к минимуму. Из-за этого легче понять поведение кода. Что более важно, изменения в любом из классов минимально влияют на другие классы (например, изменения в классе D непосредственно затронут лишь класс B). Более того, что получения доступа к классу D разработчику не нужно что-то знать о классах E, F или G. А теперь посмотрите на другой пример и сравните.
Рис.10: Пример дизайна №2
В этом пример дизайна объекты явно слишком сильно сплетены. Изменения в классе D1 потребуют длительных тестов других классов, чтобы проверить, насколько изменения сказались на них. Более того, если вы хотите выполнить какую-то функцию, вам придется гадать, где она спрятана - в самом классе D1 или в его соседях C1, E1 и/или F1.
Чтобы избежать подобного слишком сложного дизайна требуются навыки, но вот советы, которые могут вам в этом помочь:
- Ставьте себе задачу создавать цельные классы. Не распыляйте функциональность по нескольким файлам или классам.
- Называйте свои объекты ясно и понятно. Если кто-то другой не знает, что ваш класс или файл делает, или что означает ваша переменная, это значит, что вам дизайн не будет интуитивно понятным в не зависимости от того, насколько хороша его структура. Сокращения только затруднят понимание вашего дизайна.
- Не бойтесь жонглировать (refactor) кодом. Очень часто перемещение функциональности в другой файл или класс может существенно упростить код.
- Старайтесь делать классы компактными. Водопад кода лишь свидетельствует, что класс теряет целостность. Огромные классы, модули или файлы как правило свидетельствуют об отсутствии у них четкого назначения.
- Проведите обзор вашего дизайна с кем-нибудь. Может статься, что вам подкинут новую идею, или укажут на моменты, которые были ясны для вас, но не ясны для других.
- Не позволяйте фактору эффективности кода слишком сильно давить на ваш дизайн на ранних стадиях. Чистый и хорошо проработанный код гораздо проще оптимизировать и отточить, чем запутанный код, оптимизирующий проблемы, которые уже пересмотрены и сняты.
Найдите инструменты, которые поддерживают процесс дизайна
Если вы пользуетесь UML для создания и поддержки ПО вашего веб-сайта, вот несколько инструментов, которые вам могут пригодиться. Подробное их обсуждение выходит за рамки данной статьи, но вы можете отправить мне письмо, если у вас возникнут какие-либо вопросы.
- Ручка и бумага - эти инструменты не так уж и сложны. Пару быстрых набросков в понятной форме будут гораздо более полезными, чем диаграммы, смысл которых непонятен. С помощью этих инструментов конечно не так просто описывать интерфейсы классов и создавать диаграммы сценариев, но общие планы системы вы в любом случае сможете набросать. Microsoft Visio - Visio Professional 2000 теперь поддерживает UML. Вполне неплохой инструмент, по сравнению с другими. Если вы пользуетесь версией ниже 2000, можно скачать набор UML объектов, созданных работниками компании Navision. Rational Rose - лично мне нравится этот инструмент, но для мелких разработчиков веб-сайтов он слишком дорого. Инструменты Rational Rose позволяют с легкостью управлять разрастающимся дизайном проекта, создавать отчеты по моделям, совместно (поочередно или параллельно) работать над моделью с другими пользователями.
Вот другие варианты, которыми я пользовался очень мало или вообще не пользовался, но которые могут быть отличным вариантом для вас:
- MagicDraw - дешевая Java-система моделирования на UML
- Together - очень хорошо привязывается к C/C++ и Java, и поддерживает UML. Начать рисовать диаграммы классов можно и в бесплатном варианте программы Together WhiteBoard.
- Objecteering UML - распространяет UML-програмум для личного пользования бесплатно
- System Architect - популярная дорогая система UML-моделирования со службой поддержки на местах
Заключение
Данная статья представила некоторые основные понятия, связанные с UML. Надеюсь, мне удалось рассказать достаточно про нотацию и ее применение, чтобы вызвать у вас интерес. Небольшая доля формального планирования может значительно повысить эффективность вашего следующего веб-сайта. Кроме того, вам легче будет поддерживать имеющиеся сайты, и вы сможете запросто переносить наработки в следующие проекты. Теперь, лучше всего продолжить изучение нотации с просмотра справочных ссылок, данных в заключение статьи, либо приобрести хорошую книгу и начать пользоваться этими инструментами. Вам будет еще проще, если вы найдете коллегу, знакомого с UML и ООП, который поможет вам советами.
Чтобы обсудить это в форуме, нажмите здесь. |
