2016-01-16 3 views
2

У меня есть короткий вопрос:
Должен ли я указывать атрибуты типов, таких как List, Arrays, Vectors или Pointers, для объектов (не примитивного типа) в диаграмме UML или достаточно только стрелок объединения/агрегации/композиции?Указатели атрибутов, списки и векторы, необходимые в диаграмме UML?

Пример: какая из этих диаграмм верна?

enter image description here

или

enter image description here

ответ

2

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

На первой диаграмме показаны два свойства каждого типа. Один назван, а другой (в конце каждой ассоциации) не указан. Это неверно.

+0

Спасибо. Что вы подразумеваете, говоря «в конце каждой ассоциации»? Не могли бы вы показать правильный пример? Как первая, так и вторая диаграммы показывают агрегацию и состав (Class4 имеет указатели на Class5 и Class6, но Class6 и Class5 не знают Class4) –

+0

Примеры примеров объединения приведены в http://stackoverflow.com/questions/34252780/what-is -это-общее-представление-это-диаграмма/34256880 # 34256880. Для объяснения состава и агрегации см .: http://stackoverflow.com/questions/1644273/what-is-the-difference-between-aggregation-composition-and-dependency/1644321#1644321 –

+0

Imho, неназванное свойство на диаграмма классов означает, что имя будет таким же, как имя его класса. Как правило, я не читал, но он широко используется как недопустимое правило. – Gangnus

0

Это действительно зависит от того, что вы пытаетесь передать в этом архитектурном чертеже. Цель чертежа - помочь понять структуру программного обеспечения. Он не должен использоваться для представления всех деталей реализации. Если вы вкладываете в него слишком много деталей, он становится загроможденным, и трудно сохранить его в соответствии с исходным кодом, когда происходят изменения.

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

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

+0

Он не помещает много информации. Он помещает ту же информацию дважды. Первый - это плохой стиль, секрет - такой плохой стиль, который можно рассматривать как ошибку. – Gangnus

Смежные вопросы