Назначение UML

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

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

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

Необходимо принимать во внимание три толкования спецификаций.

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

• То, которое имеет в виду действующее лицо, являющееся потребителем спецификации (например, разработчик).

• То, которое объективно обусловлено природой специфицируемого объекта.

Эти три трактовки спецификаций могут не совпадать. Заказчик может не осознавать своих объективных потребностей, или неверно их интерпретировать. Разработчик может не разбираться в предметной области заказчика и интерпретировать формулировки спецификаций совершенно превратным образом. Если же в формулировке спецификаций участвует разработчик, то злоупотребление технической терминологией может совершенно дезориентировать заказчика.

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

Особенности человеческого восприятия таковы, что текст с рисунками воспринимается легче, чем просто текст. А рисунки с текстом (комиксы) — еще легче. Модели UML допускают представление в форме рисунков, причем эти рисунки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются. Приведем пример без всяких объяснений (Рисунок 1.3).

Рисунок 1.3 - Жизненный цикл работника на предприятии

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

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

Модели UML являются артефактами, которые можно хранить и использовать как в форме электронных документов, и в виде твердой копии. В последних версиях UML с целью достижения более полного соответствия этому назначению сделано довольно много. В частности, специфицировано представление моделей UML в форме документов в формате XMI^[1], что обеспечивает практическую интероперабельность при работе с моделями. Другими словами, модели UML — это документы, которые можно использовать самыми разными способами, начиная с печати изображений и заканчивая автоматической генерацией человекочитаемых текстовых описаний.

Не следует думать, что UML — это панацея от всех проблем программирования.

Во-первых, UML не является языком программирования. Дело не в том, что UML язык графический, а подавляющее большинство практических языков программирования являются линейными текстовыми языками. Гораздо важнее то, что для моделей UML не определена операционная семантика, то есть не определен способ выполнения моделей на компьютере. Это сделано вполне сознательно, в противном случае UML оказался бы зависимым от некоторой модели вычислимости, уровень абстрактности его концепций пришлось бы существенно снизить и он не отвечал бы своему основному назначению: служить средством спецификации приложений и других систем на любом уровне абстракции и в различных предметных областях. Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Together, Rational Rose, Visual Paradigm, Microsoft Visio и др.). В последние годы в компьютерной индустрии широкое распространение получили комплексные системы разработки приложений, которые обычно называют CASE средствами. В таких системах разработки предпринимаются попытки согласованным образом поддержать и обеспечить все фазы процесса разработки приложений, а не только фазы кодирования и отладки, традиционно поддерживаемые обычными системами программирования. Поскольку управление спецификациями и проектирование являются важнейшими составляющими процесса разработки приложений, понятно, что в CASE средствах должно быть предусмотрено нечто, эквивалентное основному назначению UML.

В третьих, UML не является моделью процесса разработки приложений (хотя модель процесса необходима и имеется множество различных). Конечно, у авторов UML есть собственная модель процесса — Rational Unified Process (RUP), но, тем не менее, ими сделано все для того, чтобы устранить прямое влияние RUP на UML и сделать UML пригодным для использования в любой модели процесса или даже без нее.

Перечислим различные способы использования UML в порядке убывания важности.

• Рисование диаграмм. Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе.

• Обмен информацией. Сообщество людей, применяющих и понимающих UML стремительно растет. Если вы будете использовать UML, то вас будут понимать другие и вы будете понимать других с полувзгляда.

• Спецификация систем. Это важнейший способ использования UML.

• Повторное использование архитектурных решений. Повторное использование ранее разработанных решений — ключ к повышению эффективности.

• Генерация кода. Генерировать код нужно и можно, но возможности имеющихся инструментов не стоит переоценивать.

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

Рассмотрим, как соотносится сегодняшняя практика использования UML с декларированным выше назначением языка. Можно выделить три основных варианта использования UML (Рисунок 1.4).

Рисунок 1.4 - Инструментальная поддержка.

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

Вариант использования "Составление моделей" подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели.

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

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

1.3 Модель UML и ее элементы

Модель UML — это конечное множество сущностей и отношений между ними. Сущности и отношения модели — это экземпляры метаклассов метамодели.

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

Для удобства обзора сущности в UML можно подразделить на четыре группы:

• структурные;

• поведенческие;

• группирующие;

• аннотационные.

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

Структурные сущности предназначены для описания структуры. Обычно к структурным сущностям относят следующие.

• Класс — описание множества объектов с общими атрибутами и операциями.

• Интерфейс — множество операций, которое определяет набор услуг (службу), предоставляемых классом или компонентом.

• Действующее лицо — сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

• Вариант использования — описание последовательности производимых системой действий, доставляющей значимый для некоторого действующего лица результат.

• Компонент — физически заменяемый артефакт, реализующий некоторый набор интерфейсов.

• Узел — физический вычислительный ресурс.

Приведенная классификация не является исчерпывающей. У каждой из этих сущностей есть различные частные случаи и вариации.

Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие (точнее, две с половиной, потому что иногда употребляется еще и деятельность, которая является частным случаем состояния).

Состояние — период в жизненном цикле объекта, в котором объект удовлетворяет некоторому условию, выполняет деятельность или ожидает события.

Деятельность — состояние, в котором выполняется работа, а не просто пассивно ожидается наступление события.

Действие — атомарный неделимый элемент работы.

Группирующая сущность в UML одна — пакет — зато универсальная.

Пакет — группа элементов модели (в том числе пакетов).

Аннотационная сущность тоже одна — примечание — зато в нее можно поместить все что угодно, так как содержание примечания UML не ограничивает.

В таблице 1 приведена стандартная нотация в минимальном варианте для упомянутых сущностей.

Таблица 1 Нотация основных сущностей

В UML используются четыре основных типа отношений:

• зависимость;

• ассоциация;

• обобщение;

• реализация.

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

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

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

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

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