Enterprise Architect & UML: тонкости при выборе интерфейса или абстрактного класса

В настоящее время я создаю модель из существующего кода C++. Существует (динамически загружаемая) библиотека, которая должна поэтому реализовывать/предоставлять определенный интерфейс (класс). Используемый класс имеет некоторые чистые виртуальные функции, но, по общему признанию, это не чистый интерфейс (в смысле Java), поскольку он также является базовым классом, содержащим состояние (члены) и несколько реализаций методов.

Так что это своего рода гибрид — базовый класс в C++ на самом деле, но интерфейс по своему основному назначению.

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

При рисовании примера в советнике (12) возникают некоторые вопросы:

а) есть ли какие-либо важные причины предпочесть класс и сделать его «абстрактным» (серое поле «Base») или мне следует напрямую использовать интерфейс из панели инструментов (фиолетовое поле «Base2»)? Пока я не смог заметить никакой разницы в поведении советника, кроме цвета.

б) Как я могу подавить стереотип {abstract}, написанный за методами? Когда я не устанавливаю для них значение "абстрактный", они не выделяются курсивом. Но я хочу, чтобы они были выделены курсивом, без "{abstract}".

c) Аналогичный вопрос относительно блоков классов/интерфейсов: не являются ли интерфейсы абстрактными по определению? Так почему же EA добавляет сюда текст {abstract}? Достаточно было выделить название класса курсивом.

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