26. Правила языка uml

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

имена, которые можно давать сущностям, отношениям и диаграммам;

области действия - контексты, в которых имя имеет некоторое значение;

видимость, когда имена видимы и могут использоваться другими элементами;

целостность, как элементы должны правильно и согласованно соотноситься друг с другом;

выполнение, что означает выполнить или имитировать некоторую динамическую модель.

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

содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);

неполные (отдельные элементы пропущены);

несогласованные (целостность модели не гарантируется).

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

27. Общие механизмы языка uml

Моделирование упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Работу с UML существенно облегчает последовательное использование общих механизмов, которые мы сейчас перечислим:

спецификации (specifications);

дополнения (adornments);

принятые деления (common divisions);

механизмы расширения (extensibility mechanisms).

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

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

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

При моделировании объектно-ориентированных систем реальность делится с учетом, по крайней мере, двух методов.

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

Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обязуется точно следовать объявленной семантике интерфейса. А в связи с этим, почти все конструкции UML характеризуются дихотомией "интерфейс/реализация". Например, прецеденты реализуются кооперациями, а операции - методами.

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

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

помеченные значения (tagged value), которые расширяют свойства основных конструкций UML, позволяя включать новую информацию в спецификацию элемента;

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

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