Требуется изобразить алгоритм, исполняемый совместно экземплярами нескольких разных классов. Один объект (назовём его b) вызывает операции стека и очереди, семантика этих операций заключается в добавлении и извлечении данных. Если данные добавляются, то объект b должен их передать в параметрах соответствующих операций. Если же данные извлекаются, то очередь и стек передают их объекту b в возвращаемых значениях операций. Причём, передаются значения типов sring и float. Как отразить на диаграмме передачу этих данных? Объект b также должен выполнять некоторые вычисления, а в конце должен присвоить значение типа string имеющему этот тип атрибуту ещё одного объекта, после чего происходит переход в конечное состояние. Как это отразить на диаграмме? Если моделируется поведение организации, то распределение работы по отделам и сотрудникам изображается дорожками. А правильно ли применять дорожки для отражения распределения работы по объектам-частям программы, или технического устройства?

Тарас, по правилам игры, Вы предлагаете свой вариант диаграммы, участники форума помогают его исправить.

По поводу вопроса: да , безусловно, правильно. На самом деле диаграммы деятельности могут быть трансформированы в диаграммы взаимодействия или конечных автоматов. Но - не старайтесь все изобразить на одной диаграмме - попробуйте использовать их в комплексе. Сюда по тому, что Вы написали -это очень подходит под диаграммы взаимодействия (uml-diagrams.org)

А правильно ли применять дорожки для отражения распределения работы по объектам-частям программы, или технического устройства?

Можно, конечно. Почему нельзя? (Тогда дорожки - устройства (классы), а действия - операции.)
Только нужно ли?
В такой ситуации гораздо лучше диаграммы последовательности.

А диаграммы взаимодействия - разве не собирательное название, включающее диаграммы деятельностей, последовательностей и коопераций? Мне надо показать не структуру, а именно порядок операций. Задача, решаемая проектируемой системой: есть очередь стек, табло и кнопка, в очереди валяется постфиксное математическое выражение, кнопка должна его посчитать и выдать на табло. При этом саму очередь надо очистить, данные можно сохранять в стек и в закрытые атрибуты кнопки. По поводу своей диаграммы: ну нарисую я. А если на столько не правильно, что будет вообще не понятно, что я имел ввиду? Потому и спрашиваю, как правильно обозначить передачу параметров и возврат значений.

Собирательное, и, тем не менее, они разные и используются для разного.
Именно поэтому в данном случае я стал бы рисовать последовательность.
Уважаемый Галоген дал Вам правильный совет: нарисуйте сами так, чтобы Вам самому было понятно. Обсудим.
А рисовать за Вас "поди туда, не знаю куда; принеси то, не знаю что ...", скорее всего, никто не станет.

А диаграммы взаимодействия - разве не собирательное название, включающее диаграммы деятельностей, последовательностей и коопераций?

UML2 - действующий стандарт UML (ссылку я вам давал в моем первом ответе). Диаграмма деятельности не входит в диаграммы взаимодействия (и никогда не входила). Диаграмма кооперации получила наименование диаграмма коммуникации. Все эти диаграммы, дополнительно диаграмма автомата, демонстрируют поведение системы или ее частей, хотя содержат и структурные элементы.

То, что вы пытаетесь до нас донести, нами понято сразу. Это типичный протокол взаимодействия. Чаще всего изображается диаграммой последовательности.

Объекты обмениваются сообщениями. Типы этих сообщений не слишком широки (http://umlmanual.ru/?page_id=32). На определенном уровне моделирования на линиях сообщений изображают операции классификатора объекта (при реализации это будут методы). Сигнатура операции стандартизована и описано в руководствах по UML, При этом они мало отличаются от того, как это делается в типичных программных языках

И как это изобразить на диаграмме последовательностей? Я нарисовал свой вариант. Проверьте, пожалуйста.

То есть так.

Выделение не сбросилось. На самом деле так.

Исправил ещё одну стрелку.

Богато ты нарисовал. На ДП это изобразить просто. Рисуешь 4 объекта: кнопка, очередь, стек и табло. Для примера.
Судя по алгоритму извне приходит событие Кнопка.OnClick, и далее разворачивается реализация этого клика, т.е. последовательный вызов методов объектов очередь, стек, табло. Смотрим самый первый метод запросить состояние очереди, может выглядеть так: getQueueState.
В программном коде это может выглядеть
proc onclick(sender, aQueue);
begin
if aQueue.State then
 begin
   блабла
 end
else
 begin
  aStek.getStek
 end;

end

и т.д. имхо, только тут ООП не пахнет, налицо антипаттерн MagicButton

Там последовательным вызовом не пахнет, а не ООПом. У меня цикл, а не линейный алгоритм. И я немного передумал: char вместо одного стринга.
proc onclick(sender, aQueue);
var t:string;
begin
       while aQueue.State do
       begin
              t:=aQueue.Type;
              if t='float' then begin
                                          x:=aQueue.GetFloat;
                                         aSteck.Add(x);
                                   end
                            else  begin                                         
                                          c:=aQueue.GetChar;
                                          x:=aStack.Get;
                                          y:=aStack.Get;
                                          aSteck.Add(x);
                                          case c of
                                          '+':begin r:=y+x;
                                                      aStack;
                                              end;
                                          '-':begin r:=y-x;
                                                      aStack.Add(r);
                                              end;
                                          '*':begin r:=y*x;
                                                      aStack.Add(r);
                                              end;
                                          '/':begin r:=y/x;
                                                      aStack.Add(r);
                                              end;
                                          end;
                                   end;
       end;
       r:=aStack.Get;
       tablo.caption:=FloatToStr(r);
end;
Где не ООП? Добавление/извлечение в стеке и очереди. Где последовательный вызов?

Точнее так:
proc onclick(sender, aQueue);
var t:string;
begin
       while aQueue.State do
       begin
              t:=aQueue.Type;
              if t='float' then begin
                                          x:=aQueue.GetFloat;
                                         aSteck.Add(x);
                                   end
                            else  begin                                         
                                          c:=aQueue.GetChar;
                                          x:=aStack.Get;
                                          y:=aStack.Get;
                                          case c of
                                          '+':begin r:=y+x;
                                                      aSteck.Add(r);
                                              end;
                                          '-':begin r:=y-x;
                                                      aStack.Add(r);
                                              end;
                                          '*':begin r:=y*x;
                                                      aStack.Add(r);
                                              end;
                                          '/':begin r:=y/x;
                                                      aStack.Add(r);
                                              end;
                                          end;
                                   end;
       end;
       r:=aStack.Get;
       tablo.caption:=FloatToStr(r);
end;

Galogen, не обижаешься, что я не согласился? Я ведь лучше знаю, чего хотел, а если на диаграмме совсем не то, значит она не правильно нарисована. Ну так за тем и тема, чтоб спросить, как правильно. И эта кнопка - только одна функция. Кроме неё там ещё 16 штук, 10 одного класса, 4 второго и две - каждая своего.

То есть это о кнопках. Их всего 17. 10 кнопок одного класса, 4 другого и три каждая своего.