Диаграмма классов как for-loop

Question

Мне было интересно, как представить цикл for как диаграмму классов. Итак, в основном for-loop состоит из Set, (по крайней мере) одной связанной переменной/итератора и тела (cf. picture).

Так что, очевидно, правила сдерживания легки, но как выразить это соединение между переменной i и множеством и возможной связью между переменной i и телом?

т.е.

for(int i = 0; i< set.length; i++){ 
// some statements referencing the iterator 
// i.e. set[i] = i; 
} 

for-loop class diagram

Кроме того, я знаю, что есть лучшие диаграммы в UML для описания для цикла (например, диаграмма деятельности, например), но им интересуется, как зависимость между итерированным set и итератор может быть выражен как диаграмма классов.

Answer 1

Следует ли использовать эту схему?

A class diagram представляет структурные отношения между классами/типами. Он также может представлять собой ограничения.

Но диаграмма классов не может представлять поток управления (например, условные обозначения, циклы и т. Д.). Для этого вы должны рассмотреть диаграммы activity или sequence с combined fragments.

Тем не менее, ваш вопрос освещает интересный вопрос: как представить зависимость между итератором и итерированным контейнером?

итераторов в диаграммах классов

Одним из способов представления соотношения, конечно, смотреть на iterator design pattern, который использует navigable association в контейнер.

Однако не вся реализация итератора может вернуться обратно в контейнер (например, итератор в связанный список может не знать связанный список в целом, а только текущий элемент). В этом случае вы должны использовать simple dependency (пунктирная линия со стрелкой) от итератора к контейнеру. Вы можете сделать значение явным с помощью стереотипа <<use>>: итератор каким-то образом зависит от структуры итерационного контейнера.

При необходимости вы также можете использовать UML template для контейнера и итератора, чтобы показать тип объектов в контейнере/внутри.

Подчеркивание петли для петли в заготовки? Ваша попытка диаграммы предполагает, что у вас может возникнуть соблазн использовать command design pattern для абстрактного выполнения некоторых операций на контейнере (контейнер будет приемником). В этом случае тело не будет другим классом само по себе, но будет методом, который будет переопределен в конкретной производной команде.

Однако ваши намерения не полностью ясны для меня, и могут быть более подходящие шаблоны проектирования, чтобы их рассмотреть.