И они реально разные. Каждый класс решает свою подзадачу. Один класс - набор цифр, второй - набор запятой, третий - ввод символа операции, четвёртый - запись операнда в очередь, пятый - вычисление всего выражения, сколько бы операций в нём не было. Такой вот постфиксный калькулятор, запоминающий много операций.

Я не обижаюсь. Ты меня не оскорблял, а то, что не согласен с чем-то, так это даже прекрасно.
Говоря про нарушение стиля ООП я имел в виду один из основных принципов: отделение представления от модели.

Кнопка - интерфейсный элемент, Табло тоже. Цель кнопки - получить команду извне(среагировать на событие) и передать его дальше. Кому? ну некому обработчику, который знает куда ее передать. Он - этот обработчик -подумает и вызовет или очередь или стек  и т.п.

Вопрос зачем? Ответ повторность использования, модифицируемость. Опять же реализуется принцип ООП: открытость для расширения, закрытость для модификации....

И решает каждый класс свою подзадачу: набор цифры, набор запятой, помещение операнда в очередь, помещение символа операции в очередь и рассчёт. Это калькулятор такой для длинных постфиксных выражений.

Кнопка - интерфейсный элемент, Табло тоже. Цель кнопки - получить команду извне(среагировать на событие) и передать его дальше. Кому? ну некому обработчику, который знает куда ее передать.

Согласен, но у меня обработчик зашит в метод. Или это тоже ошибка? Например, в метод "+ void Нажать()" класса "цифровая кнопка" зашит вызов "Табло::+ void Добавить(n:char)", причём, этот вызов - действие внутри метода, а "-char n" - атрибут класса "цифровая кнопка". Это зашито в метод. У запятой в методе уже два действия, второе - вызов операции блокирования самой кнопки, а та операция уже пишет атрибут "- bool Заблокировано", если он true, то в следующий раз операция "Нажать" уже не вызывается. Ну и так далее. Так что скорей уж пору поинтересоваться, не переборщил ли я с ООПом. Не будет ошибкой зашивание обработиков в методы? Мелкософтовый c++ позволяет из оконной процедуры (а именно она контролирует допустимость операций и централизует диспетчеризацию сообщений, предназначенных классу) вызвать что угодно, включая члены классов, лишь бы оно было доступно в глобальной области видимости + можно ключевым словом friend отменить все спецификаторы видимости одного класса в отношении конкретной функции, в том числе, оконной процедуры, а если и этого мало - friend ещё в одном классе и его спецификаторы тоже перестают распространяться на данную функцию. А так как пишу я именно на мелкософтовом c++, то реализовать такую модель могу, но сама оконная процедура формально не может быть членом класса.

Вопрос зачем? Ответ повторность использования, модифицируемость. Опять же реализуется принцип ООП: открытость для расширения, закрытость для модификации....

Так ведь именно на классах основано повторное использование. Наследуем от класса и метод-обработчки тоже наследуется. А для не связанных классов он не имеет смысла. Да и доступ из него нужен к атрибутам объекта, а они могут быть закрыты. Одну оконную процедуру френдануть - не велико отступление, а все обработчики френдить=прощай инкапусляция. Да и обработчики по смыслу все общедоступные, их не проблема вызывать и без френда, только завернуть исходники блокируемых обработчиков в альтернативы, проверяющие допустимость операции, но уже на уровне реализации, а не модели.

Говоря про нарушение стиля ООП я имел в виду один из основных принципов: отделение представления от модели.

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

Для того, чтоб постфиксное выражение посчитать без стека и очереди, придётся его транслировать в другую форму. Для того, чтоб инфиксное выражение посчитать без рекурсии и без даже неявного древовидного представления, его надо транслировать в другую форму.

Тарас, объединяй посты. Чего флудишь

Вопрос о диаграмме деятельности выродился в детали реализации. Исходная ошибка  - модель идет после реализации, нужно постараться научиться делать наоборот. Иначе диаграмма просто малополезна - код информативнее.

Я и делаю наоборот. Нотация математического выражения - это не реализация, а часть постановки. Задача: разработать калькулятор, поддерживающий длинные выражения с бинарными операторами: +, -, *, / (разделить), в постфиксной нотации, в которой операторы не имеют приоритетов, указываются после своих операндов, а порядок их исполнения определяется порядком их следования в выражении, при вычислении значения такого выражения возвращаться по выражению назад нельзя, но одним, или обоими операндами могут быть результаты предшествующих операций, выражение просматривается вперёд, пока не встретится оператор, при этом каждый встреченный операнд помещается в стек, а как только встретился оператор, из стека извлекаются последние элементы в количестве операндов данного оператора, после чего он выполняется над извлечённыи данными и его результат помещается в стек. Это постановка задачи. Разумеется, все её особенности оказались в модели. Реализацией же я пока не занимался вообще. И на чём будут реализованы очередь и стек - пока ни закорючки. Скорее всего это будут динамические массивы, а не списки, но в модели этого пока нет.

В любом случае необходимо отделить детали интерфейса от алгоритма.

Для начала можно нарисовать две диаграммы деятельности, не используя плавательные дорожки:
- 'Формирование постфиксного выражения'
(Ввод символа - их, видимо, три типа - цифра, запятая, знак. Вероятно, еще разделитель. Комбинация цифр и запятой составляет операнд. Операнды и знаки добавляются в очередь)
- 'Вычисление постфиксного выражения'
Примерно то, что на Вашей диаграмме, но без дорожек. Или, по крайней мере, без кнопки и табло. А то из диаграммы можно сделать вывод, что пользователь для получения результата выражения должен сорок раз на кнопку 'Расчет' нажать.

Можно еще отдельно - 'Проверка постфиксного выражения' - пригодится.

А действия пользователя с калькулятором изображать на отдельных диаграммах - если это потребуется.

Вот, рыбка приплыла, хвостиком махнула. и все сделала ясным и понятным:)

Или, по крайней мере, без кнопки и табло.
А то из диаграммы можно сделать вывод, что пользователь для получения результата выражения должен сорок раз на кнопку 'Расчет' нажать.

Зачем 40 раз запускать цикл? Но если нужны значения сорока выражений, то именно так. За один раз ровно одно выражение. Пусть длинное, но одно. А если не понятно, что это цикл, так и без табло будет тоже самое и надо исправлять именно изображение цикла. И без кнопки как она вообще получится, если алгоритм зашивается в кнопку? Причём, пользовательский интерфейс от алгоритма вроде отделён. Я пока не указал, будет ли калькулятор даже десятичным, или шестнадцатеричным. А может вообще вавилонская система будет. Это пока ни где не указано. Знак числа - это унарный -, а у меня предусмотрен только бинарный. Хотя, в принципе можно сделать и унарный на том же классе, что и запятая. А можно так: -4+68+2*4 записывать как
0
4
-
68
2
4
*
+
2*(-3+4) как
2
0
3
-
+
*
или как
2
4
3
-
*
. То есть знака числа нет, он может быть не введён и это не помешает использовать отрицательные числа.

Вероятно, еще разделитель.

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

Я нарисовал новый вариант. Теперь вопросы:
1. Надо ли указать типы данных?
2. Надо ли указать их начальные значения?
3. Я не переврал нотацию обращения через объект к его атрибуту, или операции?
4. Можно ветвление делать сразу с одной ветви на 4, а слияние с 4-х в одну? Как это изображается?

Я нарисовал новый вариант. Теперь вопросы:
1. Надо ли указать типы данных?
2. Надо ли указать их начальные значения?
3. Я не переврал нотацию обращение через объект к его атрибуту, или операции?

ДД - по сути блок-схема. Блок-схема  - суть визуализация алгоритма. Тебе судить самому правильно ли или не правильно, ты записал свой алгоритм. К синтаксису особых претензий нет