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

Question

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

Так что это своего рода гибрид - базового класса в C++ реальности, но интерфейс в своей основной целью .

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

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

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

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

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

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

Answer 1

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

б) Похоже, вы заполнили Context/Advanced/Кратность со значением abstract

с) Да. Интерфейсы являются абстрактными, и если вы посмотрите на вкладку «Сведения», вы увидите, что поле Abstract отмечено и не может быть изменено. Я понятия не имею, откуда взялся этот фигурный текст в квадратных скобках. Это не стереотип. Единственный способ показать это - изменить тип с int на int {abstract}.

d) Вы можете реализовать более одного интерфейса в классе, поэтому теоретически все разъемы в порядке. Таким образом, Derived реализует два интерфейса.

Редактировать Как @minastros выяснил сам (и Pmed меня) преступник был один из огромного количества флагов в параметрах EA:

Answer 2

Как отмечает Томас, интерфейс является абстрактный класс технически , хотя абстрактный класс не всегда является интерфейсом. Если у вас есть хотя бы одна операция (метод), которая не реализована, класс является абстрактным, поэтому следует, что если ни одна из операций не реализована, класс также является абстрактным.«Абстрактный класс» часто рассматривается только как класс с частичной реализацией, поскольку такой абстрактный класс отличается от интерфейса. Тем не менее, класс без реализации - интерфейс - технически также является абстрактным классом.

Вероятно, поэтому EA ставит атрибут {abstract} на интерфейс (это не стереотип на диаграмме, это атрибут - стереотипы используют <>). Я бы этого не сделал сам, потому что это само собой разумеется.