Етап дизайну

Етап дизайну повинен накладатися на етап аналізу - вже в той час, коли ви дізнаєтеся все більше і більше подробиць про майбутню системи, ви починаєте робити начерки того, як вона буде побудована. Неможливо спочатку на 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 і ООП, який допоможе вам порадами.

Детальніше »