Java — наследование и агрегация UML

Я прочитаю вашу диаграмму как есть, то есть — я ее интерпретирую. Если моя интерпретация верна, то ваша модель, вероятно, будет правильной. В этом вся суть UML — однозначно передавать информацию при моделировании.

Так…

• Чтение диаграммы: в газете есть статьи, как хорошие статьи, так и плохие статьи. Статьи существуют независимо в газете, и если вы, например, удалите экземпляр газеты, его статьи останутся «плавающими» вокруг. Ты говоришь:

Я на самом деле использую GoodArticle для общения с газетой, а не
Родительский класс Article в актуальной кодировке. Но с точки зрения
представляющий UML, мне все равно следует подключить родительский класс (Article) к
Газета, хотя это на самом деле GoodArticle?

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

• Чтение диаграммы: GoodArticle содержит BadArticles. Это ограничение является исключительным, что означает, что если GoodArticle будет удалено, все содержащиеся в нем плохие статьи будут автоматически удалены.

Здесь вы говорите:

Стоит ли BadArticle подключаться к родительскому классу Article? Однако я
Я на самом деле использую GoodArticle для соединения с BadArticle в кодировании.

На этот раз диаграмма отражает код, так что все в порядке, BadArticle не должен быть связан с Article. Если вы сделаете это, это будет означать, что также BadArticle может содержать другие BadArticles.

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