Sosnin.spb.ru / Материалы, статьи / Планирование сайта с помощью UML (часть 2)
Диаграммы, подобные приведенной выше, можно построить очень быстро. Эта диаграмма, например, изображает мой сайт, о котором я говорил в предыдущей статье - Введение в WML. На ее создание ушло примерно 15 минут. Однако она сослужила хорошую службу при создании и поддержке демо-версии сайта, и позволила избежать переделки кода, которая была бы неизбежной в другом случае. Мне бы хотелось обратить ваше внимание в диаграмме на несколько ключевых моментов (пожалуй, вам предварительно стоит ознакомиться описанием приложения в предыдущей статье о WML).
Данная диаграмма взаимодействия показывает дизайн того, как на веб-сайте будет создаваться отчет о погоде. Реальный код, стоящий за диаграммой, можно найти в предыдущей статье - введении в 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(). В диаграммы взаимодействия можно добавлять более подробную информацию, например, тип возвращаемых данных, ограничения на данные и прочие условия.
Диаграмма последовательностей очень похожа на диаграмму взаимодействий по тому, какую информацию они показывают. Вообще-то, многие программы UML способны создавать диаграммы последовательностей из диаграмм взаимодействий и обратно. Главное отличие диаграммы последовательностей в том, что на этой диаграмме легче проследить последовательность действий. Кроме того, на этой диаграмме можно указать подробную информацию о времени существования того или иного объекта или о его поведении (например, время ожидания, взаимодействие параллельных нитей процесса, момент создания и уничтожения объектов).
Когда возникает вопрос, какую диаграмму строить, я использую несколько критериев, которые помогают мне выбрать наиболее подходящий вариант:
Несплетенный (decoupled) дизайн означает уменьшение числа взаимодействий между классами или файлами. Такой дизайн не только проще понять и объяснить своим коллегам по команде, но его и проще поддерживать. Посмотрите на следующий пример:
Не зная ничего о назначении каждого из изображенных классов, не разумно давать оценку их целостности. Тем не менее, диаграмма показывает, что отношения между классами изящно сведены к минимуму. Из-за этого легче понять поведение кода. Что более важно, изменения в любом из классов минимально влияют на другие классы (например, изменения в классе D непосредственно затронут лишь класс B). Более того, что получения доступа к классу D разработчику не нужно что-то знать о классах E, F или G. А теперь посмотрите на другой пример и сравните.
В этом пример дизайна объекты явно слишком сильно сплетены. Изменения в классе D1 потребуют длительных тестов других классов, чтобы проверить, насколько изменения сказались на них. Более того, если вы хотите выполнить какую-то функцию, вам придется гадать, где она спрятана - в самом классе D1 или в его соседях C1, E1 и/или F1.
Чтобы избежать подобного слишком сложного дизайна требуются навыки, но вот советы, которые могут вам в этом помочь:
Версия для печати
