Объектно-ориентированный анализ и проектирование. Словарь языка uml. Правила языка uml. Механизмы и расширения языка uml.

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

Язык - система знаков, служащая:

средством человеческого общения и мыслительной деятельности;

способом выражения самосознания личности;

средством хранения и передачи информации.

Язык включает в себя набор знаков (словарь) и правила их употребления и интерпретации (грамматику).

При описании формального искусственного языка, как правило, описываются такие его элементы, как:

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

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

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

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

Спецификация - подробное описание системы, которое полностью определяет ее цель и функциональные возможности. Различают:

словесные спецификации на естественном языке;

модельные спецификации;

формальные спецификации.

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

Сущности UML

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

Существует семь разновидностей структурных сущностей, естественно, что все они нашли свое отражение в UML:

Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором записаны его имя, атрибуты и операции,

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

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

Прецедент (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Графически прецедент тоже изображается в виде эллипса, только ограниченного непрерывной линией, обычно содержащего только его имя.

Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Графически активный класс изображается также как и простой класс, но ограничивается прямоугольником, который рисуется жирной линией, и включает имя, атрибуты и операции.

Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя.

Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. Графически для изображения узла используется куб, обычно содержащий только имя узла.

Поведенческие сущности (behavioral things) - динамические составляющие модели UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве. Существует всего два основных типа поведенческих сущностей:

Взаимодействие (interaction) - это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщениями) и связи (между объектами). Графически сообщение изображается в виде стрелки, над которой почти всегда пишется имя соответствующей операции.

Автомат (state machine) - алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автоматов описываются поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы из одного состояния в другое, события - сущности инициирующие переходы и виды действий - реакция на переходы. Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, промежуточные состояния.

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. Примечание (note) - это просто символ для изображения комментариев или ограничений, присоединенный к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий.

Отношения UML

Отношения являются основными связующими конструкциями в UML и применяются для построения корректных моделей. В языке UML определены четыре типа отношений:

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически для изображения зависимости используют пунктирную линию, обычно со стрелкой, которая может содержать метку.

Ассоциация (association) - структурное отношение, описывающее совокупность связей, где под связью понимается некоторая смысловая связь между объектами. Графически ассоциация изображается в виде линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей.

Агрегация (aggregation) —специальная форма ассоциации, которая служит для представления отношения типа «часть-целое» между агрегатом (целое) и его составной частью. Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой сущность, которая включает в себя в качестве составных частей другие сущности. Отличие от обобщения заключается в том, что части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются самостоятельными сущностями. Более того, части целого обладают собственными атрибутами и операциями, которые существенно отличаются от атрибутов и операций целого.

Композиция (composition) - разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое. Эти части уничтожаются вместе с уничтожением целого. Отношение композиции - частный случай отношения агрегации. Это отношение служит для спецификации более сильной формы отношения «часть-целое», при которой составляющие части тесно взаимосвязаны с целым. Особенность этой взаимосвязи заключается в том, что части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части.

Обобщение (generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (проще говоря, потомок) может быть подставлен вместо объекта обобщенного элемента (родителя, предка). Как и положено в объектно-ориентированном программировании, потомок (child) наследует структуру и поведение своего предка (parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на предка.

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

Диаграммы UML

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

классов (class);

объектов (object);

прецедентов (вариантов использования) (use-case);

взаимодействия (interaction):

последовательности (sequence);

кооперативных (collaboration);

состояний (statechart);

деятельностей (activity);

компонентов (component);

развертывания (размещения) (deployment).

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

1. Цель создания диаграмм на языке UML –не рисование красивых картинок, а визуализация, специфицирование, конструирование и документирование. Диаграммы –это только одно из средств, но не все диаграммы необходимо сохранять. Иногда стоит создавать их на лету путем опроса элементов модели использовать для анализа системы по мере ее построения.

2. Следует избегать избыточных диаграмм, они только загромождают модель.

3. Каждая диаграмма должна содержать только необходимые детали.

4. Диаграммы не должны быть слишком краткими, если только уровень абстракции не очень высокий. Чрезмерное упрощение может скрыть детали.

5. Не следует делать диаграммы очень большими или очень маленькими.

6. У каждой диаграммы (и у любой сущности) должно быть осмысленное имя, ясно отражающее ее назначение.

Расширения языка UML

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

Механизмы расширения UML включают:

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

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

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

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