Как реализовать в Kotlin связь Composition UML?

У меня UML 2.5 диаграмма классов с большим количеством отношения композиции.

Я пытаюсь реализовать их в Котлине (извините, я новичок в Котлине):

class RuleScenarioState (val description : String){

    var action: RuleStateAction? = null

    var stateType : ScenarioStateType? = null

    var completeCriteria : StateCompleteCriteria? = null

    private class ComplexCompleteCriteria private constructor(val customCriteriaImplementation : String): StateCompleteCriteria()  {
    }

    private class ExpressionCompleteCriteria private constructor(val expression : RegulationExpression): StateCompleteCriteria() {
    }

    private class RegulationNodeCompleteCriteria   private constructor(val regulationNodeTreeId : UUID):  StateCompleteCriteria() {
    }

    private class CustomCompleteCriteria  private constructor(val customCriteriaImplementation : String): StateCompleteCriteria() {
    }

    private class CustomRuleStateAction private constructor(val customActionImplementationName : String): RuleStateAction() {
    }

    private class ClassificationRuleActionState  private constructor(val classificationExpression : RegulationExpression):  RuleStateAction() {
    }
}

К сожалению, я понятия не имею, как будут использоваться эти классы, у меня есть только схема, которую нужно реализовать. Я думаю, что создавать экземпляры с интенсивными манипуляциями с состоянием, как показано выше, — плохая идея, но как обеспечить взаимосвязь экземпляров один к одному? Как правильно реализовать связь композиции UML в Котлине?

Это ваша схема? Интересно, стрелы наследования идут в правильном направлении: абстрактные классы редко наследуют несколько конкретных классов. Не могли бы вы проверить? Кроме того, что означает пунктирная ссылка «ссылка»? И последнее, но не менее важное: есть ли причина делать составные классы приватными для состояния сценария? (на схеме об этом не сказано)

Christophe 23.04.2022 16:51

@Кристоф нет! Это не моя схема. И это не UML 2.5 на мой выбор, а все же легальный синтаксис инструмента plantuml.com

Catherine Ivanova 24.04.2022 11:55
3 метода стилизации элементов HTML
3 метода стилизации элементов HTML
Когда дело доходит до применения какого-либо стиля к нашему HTML, существует три подхода: встроенный, внутренний и внешний. Предпочтительным обычно...
Формы c голосовым вводом в React с помощью Speechly
Формы c голосовым вводом в React с помощью Speechly
Пытались ли вы когда-нибудь заполнить веб-форму в области электронной коммерции, которая требует много кликов и выбора? Вас попросят заполнить дату,...
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно...
Flatpickr: простой модуль календаря для вашего приложения на React
Flatpickr: простой модуль календаря для вашего приложения на React
Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей....
В чем разница между Promise и Observable?
В чем разница между Promise и Observable?
Разберитесь в этом вопросе, и вы значительно повысите уровень своей компетенции.
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
2
2
134
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Что требует модель UML?

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

Составная агрегация UML — это своего рода ассоциация, которая обеспечивает две вещи:

  • что экземпляр компонента (например, RuleStateAction) принадлежит исключительно одному составному элементу (например, RuleScenarioState);
  • что композит (например, RuleScenarioState) несет ответственность за существование и хранение своих компонентов (например, RuleStateAction), и, в частности, его компоненты уничтожаются, если композит прекращает свое существование.

Как это реализовать в Котлине?

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

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

Несколько несвязанных замечаний:

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

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

Я прочитал ваш пост. Сначала я предполагаю, что эта gist.github.com/iva-nova-e-katerina/… является лучшей реализацией диаграммы. Но я не уверен, потому что: 1) вы единственный парень в Интернете, который считает, что диаграмма классов определяет состав объектов. Даже baeldung.com/java-состав-агрегация-ассоциация не заботится о жизненном цикле и доступности объектов. 2) возможно, некоторые из моих внутренних классов и внутренних перечислений также должны быть как-то приватными

Catherine Ivanova 24.04.2022 12:25

PS: я не уверен, что «экземпляр компонента (например, RuleStateAction) принадлежит исключительно одному составному элементу», пожалуйста, взгляните на код baeldung. Экземпляр компонента github.com/eugenp/tutorials/blob/master/core-java-modules/… может быть извлечен и использован вне составного класса — BuildingWithDefinitionRoomInMethod

Catherine Ivanova 24.04.2022 12:33

@CatherineIvanova Возможно, Баелдунг неправильно понял состав UML: мои утверждения почти полностью относятся к спецификациям UML 2.5.1, связанным с используемым черным бриллиантом. Если предмет может быть упомянут одновременно в нескольких местах, композицию использовать не следует: точнее будет простая ассоциация. Также возможно, что утечка объектов не воспринимается так буквально в сообществах, использующих эталонную семантику для объектов (например, Java, Kotlin, Swift, …) и не предлагающих простых функций клонирования.

Christophe 24.04.2022 13:01

Эта тема вызвала оживленные дебаты, не могли бы вы дать ссылку на раздел и параграф спецификации UML 2.5.1? Если вы правы, мне остается сделать все классы и перечисления внутренними и приватными, за исключением класса RoleScenario, поэтому таким образом я ограничу инстанцирование и ссылки на экземпляры классов компонентов.

Catherine Ivanova 24.04.2022 13:18

@CatherineIvanova Кристоф не прав, настаивая на том, что композиция UML подразумевает зависимость жизненного цикла (владение). На самом деле, как поясняется, например, в stackoverflow.com/questions/885937/…, спецификация UML утверждает, что композиция часто имеет такую ​​зависимость от жизненного цикла, но также объясняет, что есть случаи композиции, когда компонент может пережить разрушение композита.

Gerd Wagner 24.04.2022 13:50

@CatherineIvanova Точные абзацы можно найти на стр. 112 свободно загружаемых спецификаций на веб-сайт ОМГ. В середине страницы вы можете найти точное определение составной агрегации, а первое предложение под таблицей завершает определение.

Christophe 24.04.2022 13:57

@GerdWagner текущие спецификации говорят: «Композитный: указывает, что свойство агрегировано составно, т. е. составной объект несет ответственность за существование и хранение составных объектов» и «Композитное агрегирование — это сильная форма агрегирования, для которой требуется часть объекта включаться одновременно не более чем в один составной объект. Если составной объект удаляется, все экземпляры его частей, которые являются объектами, удаляются вместе с ним». - Это кажется мне сильным объяснением.

Christophe 24.04.2022 14:00

Это, конечно, не предотвращает переназначение компонента, если он принадлежит одному композиту в любой момент времени.

Christophe 24.04.2022 14:00

@Кристоф, очень жаль, но не могли бы вы дать мне номера страниц как P.112, так и ""Композитный: указывает, что свойство ..." ?? Я потерялся :(

Catherine Ivanova 24.04.2022 14:16

@CatherineIvanova P.112 должен был означать страницу 112. Предложения в двойных кавычках копируются

Christophe 24.04.2022 14:29

@CatherineIvanova На странице 112 они также говорят: «Частичный объект может (где разрешено иное) быть удален из составного объекта до того, как составной объект будет удален, и, следовательно, не может быть удален как часть составного объекта». В заключение: часть объекта может быть удалена, а может и не быть удалена при удалении составного объекта. Я не знаю, почему Кристоф (и другие) игнорируют это заявление.

Gerd Wagner 24.04.2022 15:03

@ Герд Вагнер, это утверждение ничего не значит, оно касается внутреннего жизненного цикла частичного объекта. Для меня важнее всего то, что Class Diagram заботится о жизненном цикле и доступности объектов. Я могу управлять доступностью типов при разработке классов.

Catherine Ivanova 24.04.2022 15:09

@ Кристоф, кажется, ты прав. Многие примеры реализации составных отношений, которые я нашел в Интернете, не ограничивают объекты в соответствии со спецификацией UML 2.5.1. Мне нужно обсудить с автором диаграммы. Благодарю вас!

Catherine Ivanova 24.04.2022 15:11

@GerdWagner Я думаю, вы неправильно понимаете мою точку зрения. Моя точка зрения заключается в том, что часть не может принадлежать двум композитам ОДНОВРЕМЕННО. Утечка объекта подвергает вас риску возникновения этой ситуации; отсутствие утечки явно предотвращает проблему. Конечно, если право собственности передается другому объекту, конфликта нет (т.е. компонент может пережить создавший его композит), но только при условии, что он "ранее удален из композита". Таким образом, утечка объекта и его удаление - это нормально, утечка, но сохранение, потребует дополнительной осторожности, чтобы избежать множественного владения

Christophe 24.04.2022 19:34

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

Gerd Wagner 25.04.2022 00:03

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

Christophe 25.04.2022 08:43

Другие вопросы по теме