Лекция

Пакеты в языке UML

Канонические диаграммы языка UML

Особенности графического изображения диаграмм языка UML

Практическая работа № 4

Лабораторная работа № 4

Лекция

Средства языка UML для моделирования систем

Пакеты в языке UML

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

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

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

Подпакет (subpackage) — пакет, который является составной частью другого пакета.

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

Для графического изображения пакетов на диаграммах применяется специальный графический символ – большой прямоугольник с небольшим прямоугольником, присоединенным к левой части верхней стороны первого . Можно сказать, что визуально символ пакета напоминает пиктограмму папки в популярном графическом интерфейсе. Внутри большого прямоугольника может записываться информация, относящаяся к данному пакету. Если такой информации нет, то внутри большого прямоугольника записывается имя пакета, которое должно быть уникальным в пределах рассматриваемой модели.

Перед именем пакета может помещаться строка текста, содержащая ключевое слово, заранее определенное в языке UML, и называемое стереотипом, например facade, framework, stub и topLevel. В качестве содержимого пакета могут выступать имена его отдельных элементов и их свойства, такие как видимость элементов за пределами пакета.

Одним из типов отношений между пакетами является отношение вложенности или включения пакетов друг в друга. В языке UML это отношение может быть изображено без использования линий простым размещением одного пакета-прямоугольника внутри другого пакета-прямоугольника. Так, в данном случае пакет с именем Пакет_1 содержит в себе два подпакета: Пакет_2 и Пакет_3.

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

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

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

Подсистема есть просто группировка элементов модели, которые специфицируют простейшее поведение физической системы. При этом элементы подсистемы делятся на две части – спецификацию поведения и его реализацию. Для графического представления подсистемы применяется специальное обозначение – прямоугольник, как в случае пакета, но дополнительно разделенный на три секции. При этом в верхнем маленьком прямоугольнике изображается символ, по своей форме напоминающий “вилку” и указывающий на подсистему. Имя подсистемы вместе с необязательным ключевым словом или стереотипом записывается внутри большого прямоугольника. Однако при наличии строк текста внутри большого прямоугольника имя подсистемы может быть записано рядом с обозначением “вилки”.

Операции подсистемы записываются в левой верхней секции, ниже указываются элементы спецификации, а справа от вертикальной линии – элементы реализации. При этом два последних раздела помечаются соответствующими метками: “Элементы спецификации” и “Элементы реализации”. Секция операций никак не помечается. Если в подсистеме отсутствуют те или иные секции, то они не отображаются на схеме.

Канонические диаграммы языка UML

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

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

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

· вариантов использования (use case diagram)

· классов (class diagram)

· кооперации (collaboration diagram)

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

· состояний (statechart diagram)

· деятельности (activity diagram)

· компонентов (component diagram)

· развертывания (deployment diagram)

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

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

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

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

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

Стереотип (stereotype) — новый тип элемента модели, который расширяет семантику метамодели. Стереотипы должны основываться на уже существующих и описанных в метамодели языка UML типах или классах.

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

Помеченное значение (tagged value) — явное определение свойства как пары "имя – значение". В помеченном значении само имя называют тегом (tag).

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

Ограничение (constraint) — некоторое логическое условие, ограничивающее семантику выбранного элемента модели.

Как правило, все ограничения специфицируются разработчиком. Ограничения на диаграммах изображаются в форме строки текста, заключенного в фигурные скобки. Для формальной записи ограничений предназначен специальный язык объектных ограничений (Object Constraint Language, OCL), который является составной частью языка UML.

В последующих лекциях канонические диаграммы рассматриваются более подробно.

Особенности графического изображения диаграмм языка UML

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

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

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

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

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

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

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

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

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

Рекомендации по графическому изображению диаграмм языка UML

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

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

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

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

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

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

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

· Любая модель системы должна содержать только те элементы, которые определены в нотации языка UML. Имеется в виду требование начинать разработку проекта, используя только те конструкции, которые уже определены в метамодели UML. Как показывает практика, этих конструкций вполне достаточно для представления большинства типовых проектов программных систем. И только при отсутствии необходимых базовых элементов языка UML следует использовать механизмы их расширения для адекватного представления конкретной модели системы. Не допускается переопределение семантики тех элементов, которые отнесены к базовой нотации метамодели языка UML.

Практическая работа 4

Диаграмма объектов (object diagram)

И снова, прежде чем говорить о новом виде диаграмм, введем определения нужных нам понятий. Итак, мы уже знаем, что такое класс. А что такое объект?

Объект (object) - экземпляр класса.

Zicom Mentor "говорит" об объектах более обстоятельно:

Объект (object) -

· конкретная материализация абстракции;

· сущность с хорошо определенными границами, в которой инкапсулированы состояние и поведение;

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

"Второе" определение, по сути, просто расширяет "Бучевское". Да, действительно, объект - это экземпляр класса. Скажем, объектом класса "Микроволновая печь" из примера, приведенного выше, может быть и простейший прибор фирмы "Saturn" небольшой емкости и с механическим управлением, и навороченный агрегат с грилем, сенсорным управлением и системой трехмерного распределения энергии от Samsung или LG.

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

Как же обозначается объект в UML? А очень просто - объект, как и класс, обозначается прямоугольником, но его имя подчеркивается. Под словом имя здесь мы понимаем название объекта и наименование его класса, разделенные двоеточием. Для указания значений атрибутов объекта в его обозначении может быть предусмотрена специальная секция. Еще один нюанс состоит в том, что объект может быть анонимным: это нужно в том случае, если в данный момент не важно, какой именно объект данного класса принимает участие во взаимодействии. Примеры - на рисунке 4

Рисунок 4 - Примеры 4

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

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

Приведем простейший пример такой диаграммы (рисунок 5).

Рисунок 5 - Пример 5

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

Другой пример (рисунок 6).

Рисунок 6 - Пример 6

Эта диаграмма тоже понятна в общих чертах даже без дополнительных объяснений. Здесь мы видим взаимосвязь объектов - организационных единиц в некоторой компании.

И наконец, последний пример (рисунок 7): диаграмма объектов учебной среды "Робот" для Turbo Pascal, в которой наше поколение школьников училось основам алгоритмизации.

Рисунок 7 - Пример 7

Задание:

1. Придумайте свой пример и опишите его, используя диаграмму объектов (object diagram).

Лабораторная работа №4

Добавление актера на диаграмму вариантов использования и редактирование его свойств

Для добавления актера на диаграмму варианта использования нужно с помощью левой кнопки мыши нажать кнопку с изображением пиктограммы актера на специальной панели инструментов, отпустить левую кнопку мыши и щелкнуть левой кнопкой мыши на свободном месте рабочего листа диаграммы. На диаграмме появится изображение актера с маркерами изменения его геометрических размеров и предложенным программой именем по умолчанию NewClass. Для разрабатываемой модели банкомата предложенное программой имя актера следует изменить на Клиент Банкомата (рис. 1).

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

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

Рис. 1. Диаграмма вариантов использования после добавления на нее актера

Рис. 2. Диаграмма вариантов использования при изменении графических размеров актера

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

Рис. 3. Диалоговое окно спецификации свойств актера Клиент Банкомата

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

Для актера Клиент Банкомата можно уточнить его назначение в модели. С этой целью следует изменить его стереотип и добавить текст документации. Для изменения стереотипа во вложенном списке Stereotype нужно выбрать строку Business Actor (бизнес-актер). Для добавления текста документации в секцию Documentation следует ввести текст: «Любое физическое лицо, пользующееся услугами банкомата» и нажать кнопку Apply (Применить) или OK. После изменения данных свойств актера Клиент Банкомата окно спецификации свойств будет выглядеть следующим образом (рис. 4).

Рис. 4. Диалоговое окно спецификации свойств после изменения стереотипа и добавления текста документации для актера Клиент Банкомата