Обобщение на диаграмме классов UML

трудно представить себе ситуацию, когда между объектами в одной системе

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

поскольку унаследованные составляющие можно переопределить в подклассе, если нужно. При

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

мы выделили классы Position, Department и Person.
Резонно предположить, что все

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

должностям находится в пределах ответственности информационной системы отдела кадров, но

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

нескольких суперклассов (множественное наследование), не требуется, чтобы у базовых классов

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

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

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

классов применяются два отношения:
классификатор (в частности, класс) использует интерфейс —

это показывается с помощью зависимости со стереотипом «call»;
классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.

классов применяются два отношения:
классификатор (в частности, класс) использует интерфейс —

это показывается с помощью зависимости со стереотипом «call»;
классификатор (в частности, класс) реализует интерфейс — это показывается с помощью отношения реализации.

очень большого или даже потенциально бесконечного) и конечного множества операций,

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

в качестве указания типа?

могут быть:
атрибуты классов, в том числе классов ассоциаций;
параметры операций, в

том числе тип возвращаемого значения;
роли полюсов ассоциаций;
параметры шаблонов (см. ниже).

типы, которые считаются предопределенными в UML
Типы данных, которые определены в

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

как минимум, три: строка, целое число и значение даты/времени. Инструменты

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

это класс с параметрами. Параметром может быть любой элемент описания

класса — тип составляющей, кратность атрибута и т. д. На диаграмме шаблон изображается с помощью прямоугольника класса, к которому в правом верхнем углу присоединен пунктирный прямоугольник с параметрами шаблона.
Описания параметров перечисляются в этом прямоугольнике через запятую. Описание каждого параметра имеет вид:
ИМЯ : тип

Для того, чтобы на основе шаблона получить конкретный класс, который

может использоваться в модели, нужно указать явные значения аргументов. Такое указание называется связыванием. В UML применяются два способа связывания:
явное связывание — зависимость со стереотипом «bind», в которой указаны значения аргументов;
неявное связывание — определение класса, имя которого имеет формат имя_шаблона < аргументы >

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

использовать ее многократно, подставляя конкретные значения аргументов.
Явное связывание более наглядно, неявное связывание менее наглядно, зато записывается короче.

и T, тип которого не указан. Этот шаблон применяется для

создания массивов определенной длины, содержащих элементы определенного типа. В данном случае с помощью явного связывания определен класс Triangle как массив из трех элементов типа Point. С помощью неявного связывания определен аналогичный по смыслу класс с именем Array<3,Point>.

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

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

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

включать в модель все классы сразу. На первых итерациях достаточно идентифицировать очень небольшую (10%) долю всех классов системы.
Не обязательно определять все свойства класса сразу. Начните с имени — операции и атрибуты постепенно выявятся в процессе моделирования поведения.
Не обязательно показывать на диаграмме все свойства класса. В процессе работы диаграмма должна легко охватываться одним взглядом.
Не обязательно определять все отношения между классами сразу. Пусть класс на диаграмме "висит в воздухе" — ничего с ним не случится.

и диаграмм размещения. Название объясняется тем, что данные диаграммы приобретают

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

поскольку предназначены для моделирования двух теснейшим образом связанных структур:
• структуры

компонентов в приложении;
• структуры используемых вычислительных ресурсов.

моделируемой системы.
На диаграмме компонентов применяются следующие основные типы сущностей:
компоненты;
интерфейсы;
классы;
объекты.
На диаграмме

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

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

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

более сложное и объемное, чем фрагмент кода или одиночный класс.
Компонент

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

нужна — она оказывается тривиальной и никакой полезной информации не

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

компонентов) из которого при установке собирается конкретный уникальный экземпляр приложения,

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

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

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

гипертекста Home .html и файл помощи Search .hlp, а исходный

текст этого исполнимого компонентa хранится в файле Control .cpp.

очередь, реализуется компонентом с именем DataBase.

При этом для второго компонентa этот

интерфейс является экспортируемым. 

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

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

только один дополнительный тип сущности — узел и два дополнительных

отношения: ассоциация между узлами и размещение компонента на узле.
В остальном диаграммы размещения наследуют возможности диаграмм компонентов.

системы.
Компоненты системы во время ее работы размещаются на узлах. В

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

(а) - имя типа узла, (б) – имя экземпляра узла

.

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

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

компонента внутрь фигуры узла.

можно передать отношением зависимости от узла к компоненту.

на основе анализа предметной области, взаимного согласования элементов модели и

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

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