Зазвичай веб-сайти представляють собою складні й динамічні структури. На їх розробку виділяють короткий час, щоб сайт якнайшвидше запрацював і давав ефект. Часто розробники відразу ж сідають за написання коду, навіть не обдумавши, що вони збираються створювати, і як вони це збираються зробити. Код для сервера часто пишеться з аркуша, таблиці в базах даних створюються в міру потреби, і в підсумку іноді архітектура системи починає розвиватися в абсолютно непередбачуваному напрямі. Однак за допомогою простого моделювання і строгого підходу до програмування можна зробити процес розробки в набагато більш гладким і гарантувати, що створену 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: Діаграма архітектури

Ми не будемо описувати весь цикл розробки програмного продукту в даній статті, але важливо відзначити, що саме тепер можна починати створювати макет сайту і прототипи сторінок. Запишіть на майбутнє пару ідей по структурі сайту і організації його сторінок, так як у кінцевому рахунку вам захочеться створити якийсь загальний код, який генерує меню, бічні панелі і загальне компонування сторінок, щоб використовувати його в інших сайтах. Крім того, якщо ви переносите проект на нові інструменти та технології, прототипи допоможуть з'ясувати вам, наскільки дизайн здійснимо за даних умов, і наскільки ваша команда підготовлена ??до використання нових інструментів.

Детальніше »