Унифицированный язык моделирования UML

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

Тем не менее, призываю использовать UML. Очень важно понимать, зачем это нужно, как это может помочь при разработке программного обеспечения и написании программного кода. Нет доказательств того, что эти методы хороши или плохи, что они обеспечили успешную реализацию или полный провал какого-либо проекта, однако есть ряд причин, по которым всё-таки следует ими пользоваться. Не просто послушать и забыть, понадеявшись на то, что если вы попадете в группу разработчиков, использующих UML, то быстро разберетесь вы этих простых значках (а это действительно так, разобраться не сложно). Не просто послушать, а действительно использовать их самостоятельно, даже при выполнении индивидуальных заданий.

Причины

1) Задачи, мысли, идеи, решения должны материализоваться. Далеко не каждый может придумать и держать в голове несколько тысяч строк кода. Так или иначе, все используют для промежуточной материализации идей и решений визуализацию (на бумаге, на экране, на всём что окажется под рукой в минуты озарения). Каждый использует привычные для него (а может быть им и придуманные) значки, обозначения, представления. Мысль выражается в слове или другом графическом обозначении. Почему бы не использовать для этого одни и те же стандартные, простые, проверенные на опыте и ошибках других обозначения. Таким образом, первую причину можно сформулировать просто: графические обозначения помогают увидеть многое в малом, помогают мыслить и находить решения. А почему бы не воспользоваться UML?

2) Программы разрабатываются группами разработчиков, в которые входят не только программисты, но и специалисты прикладной области, дизайнеры пользовательского интерфейса, технические писатели и, возможно, заказчики. Естественный язык неоднозначен, неточен и может приводить к недопониманию, когда приходится иметь дело со сложными понятиями. Даже если вы попытаетесь привлечь графические средства, многие не захотят разбираться в ваших каракулях. Программный код точен, но слишком насыщен деталями реализации. К тому же некоторые из них не знают языков программирования. Нужна простая и ёмкая форма выражения проектных решений для обсуждения с другими разработчиками. Эта форма должна быть стандартна и понятна всем. Такой формой стал UML. Таким образом, вторая причина – необходимость общения.

3) Чем больше разрабатываемый программный продукт, тем ценнее ёмкая и точная документация о нем. Если задуман большой проект, который будет развиваться в течении нескольких лет, то без документирования просто не обойтись. Более полное и точное представление о системе у всех разработчиков, обнаружение и исправление ошибок, оптимизация скорости и расходования системных ресурсов, текучесть кадров, всё это требует хорошей и полной документации о системе. Третья причина, UML диаграммы упрощают документирование проекта.

4) UML позволяет в ёмкой и точной форме выразить сложные вещи, дать представление о системе в целом и описать не её до мельчайших деталей. Большой набор предусмотренных графических обозначений не позволит потерять контроль над разрабатываемой системой, в какой бы ситуации вы не оказались. С другой стороны UML не обязывает использовать все его средства, а позволяет использовать только то, что необходимо в данном проекте. Ещё одна причина, при очевидных плюсах UML не способствует бюрократии и оставляет свободу выбора уровня конкретизации документации.

UML (Unified Modeling Language) – это язык (графическая система обозначений) для моделирования, то есть описания предметов и явлений с использованием системы обозначений. Язык предлагает обозначения для построения следующих видов диаграмм:

Диаграмма классов

Диаграммы классов (объектов), безусловно, занимают центральное место в объектно-ориентированном моделировании. Они концентрируют в себе широкий диапазон понятий моделирования (объекты, атрибуты, поведение). Диаграммы классов, в различных (часто упрощенных видах) используются на других диаграммах UML.

Наиболее часто используемый вид диаграмм. Диаграмма объектов представляет мгновенный снимок объектов системы с точки зрения времени. Позволяет представлять диаграммы с трёх точек зрения:

Концептуальная точка зрения, когда она служит для представления понятий предметной области и взаимоотношений между ними;

Точка зрения спецификации, когда она служит для представления понятий программной системы, рассматривает только интерфейсы (спецификацию), но не реализацию.

Точка зрения реализации, когда она точно описывает классы, их атрибуты, методы и их аргументы, видимость членов и т.п.

Перед именем атрибута или операции указывается их видимость:

+ public,
# protected,
– private.

В списке параметров указывается направление (характер использования параметра):

in – вход;
out – выход;
inout – вход/выход.

Диаграммы классов описывают не только объекты системы, но и отношения различного рода, существующие между ними. В UML выделяют два вида статических отношений:

- ассоциации;
- подтипы.

Основные типы ассоциаций отображаются следующим образом:

Обобщение (супертип, подтип):

Диаграмма последовательности

На диаграмме последовательности объекты изображаются прямоугольниками на вершине вертикальной пунктирной линии.

Эта вертикальная линия называется линией жизни объекта. Она представляет собой жизненный цикл объекта в процессе взаимодействия. Каждое сообщение представляется стрелкой между линиями жизни двух объектов. Порядок следования сообщений устанавливается сверху вниз, то есть так, как они показаны на диаграмме. Каждое сообщение помечается именем сообщения. На диаграмме присутствовать рекурсивные вызовы – сообщения, которые объекты посылают сами себе. Чтобы показать период времени, в течение которого объект является активным, изображается прямоугольник активности. Управляющая информация может быть представлена на диаграмме в квадратных скобках перед именем сообщения. На диаграмме последовательности пунктирной линией может отображаться возврат (но не обязательно). Также можно отобразить удаление объекта значком X в нижней части линии жизни.

Диаграмма деятельности

Диаграммы деятельности позволяют графически отобразить поведение объекта при выполнении определенных действий.

Параллельное поведение изображается с помощью слияний и разделений.

Диаграмма вариантов использования

На диаграммах вариантов использования применяется следующие обозначения.

Актер представляет собой некоторую роль, которую играет пользователь системы. Актеры связаны с вариантами использования.

Диаграмма пакетов

Идея пакета может быть применена к любому элементу моделей. Пакет обозначается значком:

С помощью стрелок ассоциация можно показать взаимосвязи между пакетами.