Окно программы

1

Полоса прокрутки

Заголовок

Рабочая область

1

1

1

2

Главное меню

Рисунок 10 – Отношение композиции

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

Единственное ограничение, которое вносит агрегация в ассоциацию – отсутствие цикличности связи, так как класс не может содержаться сам в себе.

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

Подклассы

Рисунок 11 - Пример обозначения обобщения

В UMLможет применяться и другой стиль оформления обобщения –бинарный, в котором для пар потомок-предок используется отдельная наклонная линия (рисунок 12 ).

Геометрическая фигура

Суперкласс

overlapping

Подклассы

Прямоугольник

Эллипс

Окружность

…

Рисунок 12 – Бинарный стиль обозначения обобщения с перекрытием

Многоточие означает, что все возможные потомки пока не перечислены и могут появиться другие потомки (свойство «неполный»,incomplete). Отсутствие многоточия говорит о полном перечислении потомков (свойство «полный»,complete). Если эллипс может иметь потомком окружность (например, при равенстве полуосей), то говорят о свойстве «перекрытие», overlapping– оно обязательно обозначается, как показано на рисунке. По умолчанию считается, что перекрытие отсутствует (свойство «раздельный»,disjoint).

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

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

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

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

На рисунке 13 изображены два варианта программной реализации спецификации блока выбора решения на экране: выпадающее меню с опциями выбора в виде строки и набор радиокнопок альтернативного выбора, помечаемых курсором. Спецификация выбора задаётся классом интерфейсного типа ChoiceBlockбез раздела атрибутов. В этом классе определены две видимые операции:setDefault– Установить значение опции выбора по умолчанию иgetChoice– Получить значение опции выбора. Классы реализации спецификацииPopUpMenuиRadioButtonArrayобъявляют эти же операции, но с более конкретными аргументами выбора и возвращаемыми значениямиString(Строка) иButton(Кнопка) соответственно. Блоки выбора решения связаны бинарной ассоциацией с соответствующими классами единичного выбораChoice,StringиButton.

.

Рисунок 13 - Отношение реализации

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

Важным частным случаем отношения реализации является реализация варианта использования или отдельной операции в виде кооперации (collaboration) объектов (рис. 14 ).

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

Рисунок 14 - Реализация варианта использования при помощи кооперации

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

1. граничные(boundary) классы: объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов, упоминавшихся ранее);

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

3. классы управления(control): объекты этих классов являютсяактивными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.;

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

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

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

Рекомендуется для избежания конфликта имён в модели системы использовать только один вид группировки.

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

Система(стереотип «system») – это корневая подсистема в иерархии пакетов. Она является единственной сущностью, которая не может содержаться в других пакетах. В пакетесистема содержатся все остальные подсистемы и модели.

Подсистема(стереотип «subsystem») – это часть системы, которая может быть выделена разработчиком по тому или иному признаку (обычно функциональному или территориальному). Представляется отдельным пакетом. У подсистемы есть собственная спецификация и программная реализация. Разбиение на подсистемы производится для сложных систем, реализация которых основана на использовании большого количества классов. Практически все подсистемы любого уровня детализации взаимозависимы. Количество уровней иерархии в декомпозиции подсистем на подсистемы языкомUMLне ограничивается.

Модель (стереотип «model») – некоторое абстрактное представление системы, использующее ту или иную точку зрения разработчика (определённые свойства системы). Моделей может быть множество, они могут быть взаимозависимы, а также вкладываться друг в друга. Каждая модель представляется отдельным пакетом. Все они содержатся в пакетесистема, могут также содержаться в пакетахподсистема имодель более высокого уровня.

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

Перед именем элемента, например, класса может ставиться имя пакета. Оно отделяется двойным двоеточием. Пример: displayWindow:WindowingSystem::GraphicWindows::Window(указаны два пакета перед именем классаWindow, причем пакетGraphicWindowsвходит в состав пакета ). Так отображается иерархия пакетов.

Пакет изображается в виде большого прямоугольника, к левому углу которого прикреплён другой прямоугольник вида «закладки» (подобно изображению папки в операционной системеWindows). Если содержимое пакета не раскрывается, то внутри большого прямоугольника ставится имя пакета. Иначе имя пакета помещается в закладку. Над именем пакета может располагаться строка стереотипа в угловых кавычках. Пример диаграммы пакетов представлен на рисунке 15.

Рисунок 15 – Пример диаграммы пакетов

На рисунке изображена в виде пакета со стереотипом «подсистема» часть системы, формирующая отчёты по продажам по запросам пользователей. Этот пакет содержит несколько пакетов, связанных отношением зависимости (пунктирная стрелка) с внешними пакетами. Пакет Интерфейс пользователя использует стандартные компоненты внешнего по отношению к подсистеме пакетаОконный интерфейс (формы, элементы управления и методы работы с ними, определённые выбранной системой программирования и операционной системой). Кроме того, для формирования отчётов о продажах требуется расчёт показателей, реализуемый двумя способами (вариантами) : с помощью электронных таблицMSExcelи с помощью СУБДMSAccess. На диаграмме пакетов это отображено абстрактным пакетомРасчёт показателей, являющегося обобщением двух конкретных пакетовРасчёт по электронным таблицам иРасчёт по таблицам БД. Все эти пакеты связаны отношением зависимости с соответствующими внешними пакетами. Имена абстрактных пакетов выделены курсивом.