Unified Modeling Language (версия 2, как правило) представляет собой набор полуофициальных обозначений , которые могут быть использованы для выражения аспектов разработки программного обеспечения в графическом виде. Например, шаблоны проектирования обычно объясняются в текстовой форме с помощью классов Uml и диаграмм последовательности .
Польза модели более высокого уровня над простым исходным кодом не вызывает сомнений: просто помните, что шаблоны проектирования сами по себе представляют собой более высокий уровень абстракции по сравнению с ключевыми словами простого класса, функции и интерфейса. Диаграммы UML располагаются между ними: более удобными диаграммами, которые я нашел, являются класс, последовательность и объектная диаграмма, которые имитируют структуру кода (классы, методы, вызовы, возвращаемые значения), одновременно обрезая большинство детали реализации.
Благодаря таким моделям, как диаграммы и шаблоны, мы можем общаться с другими разработчиками и сообщать основные принципы нашего дизайна в кратчайшие сроки; способность итераций к одному и тому же программному компоненту расширяется благодаря нашей способности предлагать различные конструкции на основе быстро написанных диаграмм вместо прототипов кода. UML-диаграммы не обязательно являются частью документации, хотя, если вы будете их обновлять, они будут эффективным способом подведения итогов выборов, которые вы сделали при кодировании.
Вероятно, прототипы и диаграммы могут быть созданы с той же эффективностью, но диаграммы и шаблоны, как правило, гораздо более кратки и могут передавать весь набор отношений между классами одним взглядом.
Большое предварительное проектирование почти всегда приводит к сбою, поскольку заранее определенные методы, поля и классы не удовлетворяют сценарию, который мы постепенно раскрываем при написании тестов и интеграции классов друг с другом. Но никто не сказал, что шаблоны и диаграммы должны диктовать каждую отдельную строку кода, которую мы напишем: в инженерных моделях они полезны в основном для того, что они пропускают , а не для того, что они представляют, поскольку выражения, выделенные жирным шрифтом в этой статье, читаемы просто потому что остальная часть статьи не выделена жирным шрифтом.
Поскольку я пишу UML-диаграммы для своих университетских курсов, и я обнаружил, что снова и снова использую их, чтобы донести до своей рабочей группы свои идеи для веб-приложений, мне пришлось выбирать инструмент для их написания. Если вы все еще не спите после этой теоретической дискуссии, вот варианты, которые лучше всего подходят для меня.
Салфетка
Back-of-the-салфетка UML — это классика . Вы на обеденном перерыве (это как под душем), и очень умная идея приходит вам в голову благодаря вашему мозгу, который постоянно работает над вашими повторяющимися проблемами, даже когда вы расслабляетесь. Вы хотите быстро рассказать другим, что вы подумали, поэтому вы берете салфетку и начинаете писать на ней, прежде чем идея ускользнет.
Это аварийный инструмент, не очень хороший для написания (по крайней мере, для итальянских салфеток, которые имеют несколько слоев, каждый очень тонкий) и не пригодный для удаления чего-либо.
Лист бумаги
Я не говорю о печатной бумаге: чистый лист бумаги, карандаш с точилкой и резина, чтобы вы могли переписать части диаграмм. Эта комбинация очень удобна, и ни один программный инструмент никогда не даст вам гибкости бумаги, если у вас нет устройства с сенсорным экраном, похожего на StarTrek.
Более того, бумага не позволяет вам пытаться поддерживать диаграмму более нескольких дней, так как архивирование листов будет проблематичным: вы не можете добавить их. Если вам действительно нужно, вы можете отсканировать лист.
В Agile-движении наблюдается тенденция отдавать предпочтение низкотехнологичным инструментам, таким как бумага, а не программному обеспечению для отслеживания технологий, например, в случае пользовательских историй. Этот выбор отражает и это влияние.
Доска или доска
Листы рассчитаны не более чем на 2 или 3 человека: вместо этого доска может визуализировать диаграмму, чтобы каждый мог помнить ее в течение дня. Для архитектурных схем это манна с неба.
Доска также предлагает больше места для манипулирования вещами, но общее пространство доски ограничено : это нужно другим людям, и надпись на стенах не будет работать долго.
Электронная доска с несколькими страницами, которые вы можете сохранять и извлекать, и писать на каком-то устройстве, была бы очень крутой; мы еще не там технологически или экономически. Чтобы сохранить диаграммы такого рода, я использовал протографы с высоким разрешением , которые сегодня можно сделать с помощью дешевой камеры типа «укажи и щелкни» за несколько секунд. Излишне говорить, что редактирование этих диаграмм было бы невозможно.
У всех трех физических инструментов есть большой недостаток: они требуют, чтобы команда находилась в одном месте , и не разрешают удаленную работу.
yUML
Вместо того, чтобы утомлять себя, притягивая и толкая вещи, напишите простое формальное описание с помощью yUML своей диаграммы и дайте онлайн-инструменту yUML сгенерировать его. Описание очень простое; 
этот код будет генерировать диаграмму справа:
[Wages]^-[Salaried], [Wages]^-[Contractor]
Не беспокойтесь о том, что вы можете сделать с помощью этого инструмента, yUML поддерживает только те виды диаграмм, которые полезны, такие как классы и действия. Я скучаю по диаграмме последовательности, однако.
Обратите внимание, что если ваша диаграмма слишком сложна для того, чтобы эффективно ее визуализировать (перепутать или пересекать стрелки), она будет слишком сложной для понимания человеком. Ю, наверное, лучше разбить его на несколько диаграмм или вырезать ненужные элементы. Я использую yUML для всех диаграмм UML в моих статьях.