хотелось бы узнать Ваше мнение (особенно bas и Galogen) по поводу моей диаграмы Коммуникации для моего дипломного проекта.
Суть задачи (если не ясно пожалуйста спрашивайте):
на перекрёстке (транспортный узел) есть несколько полос движения в разные стороны для разного типа транспорта, для каждой полосы есть отдельный детектор движения и фонарь (светофор).
Полосы движения могут быть толерантны или нетолерантны друг с другом, толерантным разрешен одновременно сигнал "Зелёный", нетолерантным только по очереди.
Переключение сигналов происходит в определённой последовательности (например: Красный, Желтый, Зеленый) и между переключением полос должен выдерживаться определённый интервал чтоб дать возможность транспорту освободить перекрёсток.
Зелёный сигнал одной полосы имеет определённое макс и мин ВремяПропуска.
Разрешение на пропуск (Зелёный) даётся в зависимости от наличия требования на пропуск, статической приоритетности полосы и прошедшего время ожидания на пропуск.
В следствии изменения сигналов фонарей перекрёсток переходит из одного состояния в другое, эти состояния называются здесь фазами. В фазе фонари показывают либо зелёный либо красный сигнал, т.е. длительное состояние. Фаза это состояние всего перекрёстка, т.е. сигналы всех полос узла.

Перед включением системы инженер передаёт необходимые статические данные через некий графический фейс - конфигурирует управление. После чего управление может быть включёным неким Управляющим. При необходимости он же может её выключить.

Цель описать обмен сообщениями составных этой системы. Вот как я намалевал, обсудите пожалуйста, а то диаграмы коммуникации как-то редко встречаются.

А почему бы не разбить на 3 Д? А то как-то смешались в кучу Объекты и Люди.
Не понятно где управляющий класс, а где объекты данных
ИМХО одной ДКом не получится описать столь сложное поведение.

Т.е. то что пронумерировано 1+2 в отдельную ДК, 3 в отдельную и 4? Над этим я тоже думал.. просто картинок у меня тогда будет больше чем текста  
(это я спозаранку бредил)

Не понятно где управляющий класс, а где объекты данных

да, согласен, а как сделать понятно? Или может для понятности просто не хватает самого описания диаграммы?

одной ДКом не получится

думаю дальше... конечно же у меня не только ДКом для описания, есть ещё диаграмма компонент, деятельности (почти готова) и описывающая проблемную область диаграмма классов. Выкладу вскоре.

Выкладываю ещё компоненты и деятельность (вид сверху)

Осторожно мысли в слух:

По поводу диаграммы деятельности возник вопрос: а могу ли я в одной активности отправлять сигнал (конкретно полностью сконфигурировано) который будет принят лиш в следующей деятельности - моментально не активной. Т.е. будет ли он принят-то? И как тогда вообще с сигналами в дДеятельности работать?
А если сигнал работает отправляется деятельностью Включить, тогда то он дойдёт, но есть ли смысл моделировать это через сигналы, а не напрямую через control flow?


Почитал ещё немножко и опять взглянул на дКоммуникаций, наверно в пункт 3 не хватает повторения в цикле, буду добавлять звёздочки. А что вообще понимают под boundary в дКоммуникации? По-моему это просто некая граница, других свойств нету или я совсем ошибаюсь?

В диаграмме компонент (раз уже у меня там актёры) то и фонари тоже актёрами нада.