3.5.1. Диаграмма внутренней структуры

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

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

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

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

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

На диаграммах внутренней структуры применяются следующие основные сущности.

• структурированный классификатор (structured classifier);
• часть (part);
• порт (port);
• соединитель (connector).

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

Часть имеет имя 1, тип 2 и кратность 3. Отношение между структурированным классификатором и его частями — это чаще всего отношение композиции. В этом случае часть изображается как классификатор — прямоугольником 4, который должен быть расположен внутри прямоугольника структурированного классификатора. Если часть не связаны со структурированным классификатором отношением композиции^∇, то тогда нотация меняется, и рамочка прямоугольника рисуется пунктирной линией 5.

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

Для портов может быть задано два свойства.

Первое свойство связано с теми сервисами, которые предоставляют интерфейсы, доступные через данный порт. Это свойство имеет имя isService, и, соответственно, определяет, является порт сервисным или нет.

Значение свойства isService по умолчанию true, т.е. порт сервисный, в противном случае порт называют скрытым портом.

В процессе разработки скрытый порт может быть изменен или даже удален. Нотация скрытого порта — квадратик, присоединенный к границе классификатора с внутренней стороны 6 на предыдущем рисунке.

Второе свойство с именем isBehavior определяет, является ли данный порт портом поведения всего классификатора или классификатор делегирует поведение своим частям.

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

Значение данного свойства по умолчанию —false, т.е. порт не является портом поведения.

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

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

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

Соединители бывают двух видов: делегирующие и сборочные.

На следующем рисунке показаны оба вида соединителей: делегирующие 1 и сборочные 2. Для делегирующих соединителей существует возможность использования альтернативной нотации с использование стереотипа «delegate» 3.

Рассмотрим пример диаграммы внутренней структуры из модели информационной системы отдела кадров (см. следующий рисунок). На этой диаграмме, мы выделяем в подразделении (класс Department) простую внутреннюю структуру, которая состоит из единственного начальника и некоторого множества подчиненных. Подчиненные (subordinates) и начальник (chief) взаимодействуют, причем предусмотрены различные интерфейсы взаимодействия в зависимости от направления передачи информации (IChief и ISubordinate). Кроме того, указанные части взаимодействуют с внешним миром через свои порты (Inbox и Resource).

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

3.5.2. Кооперация

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

Есть еще одно отличие, хорошо проявляющееся в нотации кооперации. Кооперация идентифицируется по имени, исходя из задачи, которую решает, в то время как структурированные классификаторы носят имена реальных классов или компонентов.

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

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

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

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

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

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

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

Кооперация изображается в виде пунктирного эллипса, содержащего имя кооперации.

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

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

Например, заместитель начальника подразделения, кроме обычных свойств подчиненного, может обладать правом подписи за начальника. Это можно оформить в виде интерфейса IDeputy, который является специализацией интерфейса ISubordinate.

Заместитель с правом подписи может выступать в роли подчиненного (subordinate)  на описанной выше диаграмме Кооперации начальника с подчиненным.

Однако тип этой роли ‒ ISubordinate ‒ не позволяет начальнику поручить заместителю заключение договора или каким-либо другим образом воспользоваться правом подписи своего подчиненного. Специализация кооперации, показанная ниже, позволяет решить эту проблему. В ней роль subordinate имеет специализированный тип IDeputy, предоставляющий необходимую операцию.

Нотация использования кооперации предназначена для описания конкретного случая использования кооперации, т.е. является экземпляром кооперации.

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

Экземпляры кооперации изображаются пунктирным эллипсом. Внутрь эллипса помещаются имя использования 1 и имя кооперации 2, разделенные двоеточием.

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

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

Различие между этими диаграммами состоит в том, что в первом случае заместители (их трое!) не обладают правом подписи за начальника, так как используется экземпляр кооперации Subordination (3 на первом рисунке), а во втором — обладают, так как используется экземпляр кооперации Subordination with power to sign (1 на втором рисунке). Заметим, что заместители начальника на обеих диаграммах описывается одним и тем же классом (4 на первом рисунке и 2 на втором рисунке).

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

3.5.3. Образцы проектирования

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

Для углубленного изучения данного аспекта вернемся к моделированию информационной системы отдела кадров и еще раз посмотрим на реализацию варианта использования Hire Person, представленного на диаграмме Типовой сценарий приема сотрудника.

И хотя внешне все выглядит удовлетворительно, на самом деле в данной реализации полно недочетов (о существовании которых мы упоминали в параграфе 2.3.4), которые опытные читатели наверняка заметили. Например, из данной реализации следует, что класс Hire Form может создать экземпляр класса Person и обладает информацией об экземплярах класса Position, что противоречит одному из принципов, которым желательно следовать, проектируя приложения с графическим интерфейсом пользователя. Данный принцип проектирования носит название ‒ Model-View Separation и говорит о том, что сущность, ответственная за общение с пользователем (графический интерфейс), не должна напрямую манипулировать данными, а сущность, ответственная за хранение и обработку данных, не должен содержать элементов пользовательского интерфейса.

На самом деле данный принцип был использован при моделировании на уровне компонент и представлен на диаграмме компонентов ИС OK, где мы выделили компоненты, отвечающие за взаимодействие с пользователем (эти компоненты имеют добавление GUI к своему имени, например, StaffManagerGUI), и компоненты, реализующие непосредственно логику приложения (эти компоненты имеют добавление Management к своему имени, например, StaffManagement).

Сделано это было как раз для того, чтобы не смешивать элементы пользовательского интерфейса с элементами бизнес-логики, что полностью соответствует принципу Model-View Separation.

Все что нам остается сделать ‒ это предложить новую диаграмму последовательности для реализации типового сценария приема сотрудника, удовлетворяющую принципу Model-View Separation.

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

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

Зато для описания образцов проектирования прекрасно подходит сущность кооперация, а точнее ее параметризованный вариант, который носит название шаблон кооперации (collaboration template).

В качестве примера рассмотрим описание образца проектирования Publisher-Subscriber (см. следующий рисунок), который применяется в случае, когда некоторое множество объектов должно следить за изменением состояния другого объекта. Объект, изменение состояния которого требуется отслеживать, называется издателем (publisher), а объекты, которые следят за его состоянием, называются подписчиками (subscriber). Отсюда и название образца проектирования.

Каждый подписчик ‒ экземпляр классификатора с типом параметра шаблона кооперации SType 1, а издатель ‒ экземпляр классификатора с типом параметра шаблона кооперации PType 2.

Издатель (роль Publisher 3) должен определить две операции subscribe() и unsubscribe(), которые служат для того, чтобы подписать, и соответственно, отписать подписчика (роль Subscriber 4) от нотификации. Нотификация осуществляется путем вызова метода update(), который определен в интерфейсе ISubscriber. Этот интерфейс должен быть реализован 5 каждый подписчиком.

Пример использования образца проектирования Publisher-Subscriber в контексте информационной системы отдела кадров приведен в параграфе 4.4.2.

3.5.4. Экземпляры классификаторов

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

Для того чтобы указать, что элемент на диаграмме является именно экземпляром классификатора, а не самим классификатором, применяется следующая нотация  ‒ его имя подчеркивают^∇.

Не могут иметь конкретных экземпляров абстрактные классификаторы^∇, к которым относятся, например, интерфейс (стереотип «interface») и любые другие классификаторы с ограничением {abstract}.

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

Экземпляры классификатора "тип данных" (стереотип «dataType») и его специализации "примитивный тип" (стереотип «primitive») на диаграммах в большинстве случаев представляются в виде начальных или константных значений для атрибутов других классификаторов. Для возможных экземпляров классификатора "перечисление" (стереотип «enumeration») предусмотрена специальная нотация.

Пример использования экземпляров действующего лица для информационной системы отдела кадров приведен на следующем рисунке. Пользуясь случаем, мы продемонстрируем на этом примере альтернативную нотацию для представления действующего лица  ‒ класс со стереотипом «actor» 1.

Глядя на этот рисунок, у читателя может возникнуть законный вопрос: почему на диаграмме нарисованы экземпляры действующих лиц, хотя в разделе 2.3 о такой возможности ничего не сказано?

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

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

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

Заметим, что в случае коопераций, ее экземпляры не подчеркиваются. Не подчеркиваются также и названия внутренних частей кооперации^∇.

Большую помощь при моделировании системы оказывают экземпляры узлов (стереотипы «device», «executionEnvironment») и размещаемые на них экземпляры артефактов (стереотипы «artifact», «artifact», «file», «document», «executable», «library», «script», «source»), которые изображаются на диаграмме размещения.

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

В этом случае имена экземпляров узлов и размещенных на них артефактов подчеркиваются.

В отношении артефактов осталось сделать небольшое, но важное замечание, которое связано с понятием индивидуальности, определенном в параграфе 3.2.4.

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

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

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

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

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

В рамках данного раздела нам осталось рассмотреть еще два классификатора: класс и класс ассоциации. Однако поскольку для экземпляров классов в UML используется специальная сущность  ‒ объект, то мы отвели для ее описания отдельный параграф.

3.5.5. Объекты и диаграмма объектов

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

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

Если есть возможность указать конкретный метод класса, ответственный за данную операцию, то рядом с именем метода можно указать стереотип «create», а отношение зависимости позволяет показать, экземпляры какого именно класса создаются в данном методе.

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

Логично предположить, что ответственность за создание экземпляров класса Department ложится на экземпляр класса Company. Проиллюстрируем сказанное. На следующем рисунке метод createDpt() 1 класса Company отвечает за создание экземпляров классов Department, а метод createPrs() 2 за создание экземпляров класса Person. В то же время класс Department, согласно тому же принципу, создает экземпляры класса Position 3. Кроме этого на диаграмме классов дополнительно показано, что объект с именем Someone является экземпляром класса Person 4.

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

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

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

Поскольку диаграмма объектов ‒ это не более чем пример, ее описательная сила невелика. Все, что можно показать на диаграмме объектов, можно показать и на диаграмме взаимодействия в форме коммуникации (см. параграф 4.4.5), причем гораздо более информативно. Поэтому диаграммы объектов используются сравнительно редко. Так, например, большинство инструментов не поддерживает отдельного режима для рисования диаграмм объектов: на диаграмме классов можно разместить только объекты (без классов) и тем самым она станет диаграммой объектов. Мы полагаем, что авторы UML сохранили диаграммы объектов как отдельный вид канонических диаграмм "на всякий случай" и "для полноты картины" ‒ в наших примерах данный вид диаграмм редко используется, однако без примера мы читателя не оставим. Достаточно информативный пример использования диаграммы объектов для информационной системы отдела кадров приведен в параграфе 4.5.1, а сейчас мы хотим поговорить о малоизвестном, но очень полезном способе использования диаграммы объектов.

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

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

Соответствующая ей диаграмма объектов, построенная из экземпляров метаклассов метамодели, приведена на ниже.

Некоторые авторы, например, Конрад Бок [Conrad Bock. UML 2 Activity and Action Model. // Journal of Object Technology, vol. 2, No 4–6, vol. 3, No 1, No 7, 2003–2004] используют модель хранения (repository model) как одно из полезнейших средств задания семантики моделей.

Выводы

• Структура сложной системы описывается на уровне дескрипторов.
• Диаграммы классов моделируют структуру классов и отношений между ними.
• Классы выбираются на основе анализа предметной области, взаимного согласования элементов модели и общих теоретических соображений.
• Взаимосвязь между классами описывается, прежде всего, с помощью отношений обобщения и ассоциации. Реже с помощью отношений зависимости и реализации.
• Отношение ассоциации имеет большой набор различных дополнений, с помощью которых можно указать особенности отношений между классами.
• Множества классов могут объединяться в логическую структуру – компонент.
• Каждый компонент описывается набором требуемых и обеспеченных интерфейсов.
• Компонент и классы как элементы модели связываются с физическими сущностями — артефактами — с помощью манифестации.
• Диаграммы компонентов моделируют структуру компонентов (артефактов) и взаимосвязей между ними.
• Диаграммы размещения моделируют структуру вычислительных ресурсов и размещенных на них артефактов.
• Диаграммы внутренней структуры показывают контекст взаимодействия частей сложных классификаторов, причем части, в свою очередь, могут иметь внутреннюю структуру.
• Кооперация – это способ показать контекста взаимодействия нескольких классификаторов
• Диаграмма объектов — это пример связей программных объектов в отдельный момент выполнения системы.