Проектирование

При разработке модели вы можете широко применять диаграммы. Можно использовать больше нотаций и при этом быть более точным. Вот некоторые полезные приемы:

• Диаграммы классов с точки зрения программного обеспечения.Они показывают классы программы и их взаимосвязи.

• Диаграммы последовательности для общих сценариев. Правиль­ный подход состоит в извлечении наиболее важных и интересных сценариев из прецедента, а также в использовании CRC-карточек и диаграмм последовательности с целью понять, что происходит в программе.

• Диаграммы пакетов, показывающие высокоуровневую организа­цию программного продукта.

• Диаграммы состояний для классов со сложным жизненным циклом.

• Диаграммы развертывания, показывающие физическую конфигу­рацию программного обеспечения.

Многие из этих приемов позволяют документировать программное обеспечение после его создания. Кроме того, это может помочь людям сориентироваться в программе, если они ее не создавали и не знакомы с кодом.

В рамках жизненного цикла метода водопада необходимо создавать эти диаграммы и выполнять различного рода действия (активности) как часть конкретных фаз. Документы, создаваемые по окончании ка­кой-либо фазы, обычно включают диаграммы для проведенных дейст­вий. Стиль водопада подразумевает применение UML в качестве инст­румента проектирования.

При итеративном подходе диаграммы UML могут выступать или как модели, или как эскизы. В режиме проектирования аналитические диаграммы обычно создаются в рамках итерации, предшествующей итерации построения функциональности. Каждая итерация не начи­нается с самого начала. Напротив, она модифицирует существующую документацию, подчеркивая изменения, произошедшие в новой ите­рации.

Создание моделей обычно происходит на ранней стадии итерации и может быть сделано по частям для различных разделов функциональ­ности, назначенной для данной итерации. Кроме того, итерация под­разумевает изменение существующей модели, а не построение каж­дый раз новой модели.

Применение UML в режиме эскизирования - более подвижный про­цесс. Один из подходов заключается в выделении пары дней в начале итерации на создание эскизного дизайна для данной итерации. Можно также проводить короткие сессии проектирования в любой момент в ходе итерации, устраивая короткие получасовые совещания всякий раз, когда разработчики начинают спорить по поводу нетривиальной функции.

В режиме проектирования вы ожидаете, что программная реализация будет строиться в соответствии с диаграммами. Изменение модели сле­дует считать отклонением, которое требует, чтобы проектировщики, создавшие эту модель, ее пересмотрели. Эскиз обычно трактуется как первый срез дизайна. Если в ходе кодирования обнаруживается, что эскиз не совсем точен, то разработчики должны иметь возможность изменить дизайн. Разработчики, внедряющие дизайн, должны сами решать, стоит ли устраивать широкую дискуссию, чтобы понять все возможные варианты.

Относительно моделей у меня есть свое собственное мнение, которое заключается в том, что даже хорошему проектировщику очень трудно составить правильную модель. Я часто обнаруживаю, что моя собст­венная модель не остается нетронутой по завершении кодирования. И все же я считаю эскизы UML полезными, хотя не думаю, что их сле­дует возводить в абсолют.

В обоих режимах имеет смысл исследовать несколько вариантов ди­зайна. Как правило, лучше просматривать варианты в режиме эскиз­ного моделирования, чтобы иметь возможность быстро создавать и из­менять варианты. Выбрав дизайн, вы можете либо использовать эс­киз, либо детально проработать его до уровня модели.