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

Зачем 40 раз запускать цикл? Но если нужны значения сорока выражений, то именно так.

Конечно, но на прежней диаграмме это выглядело так, словно это надо в процессе вычисления одного выражения. В последней версии все гораздо лучше.

без кнопки как она вообще получится, если алгоритм зашивается в кнопку?

Это не алгоритм зашивается в кнопку. Это вызов алгоритма зашивается в кнопку.
Примерно...

Код: [Выделить]

class CPostfixExpression
{
public:
//вычисление выражения
float calculate();
//проверка валидности выражения
bool validate();
//добавить символ
void addSymbol(char _c)

//другие методы...

private:

//очередь
string m_Queue[1000];
//стек
float m_Stack[1000];
}

//Очередь и стек, вероятно, будут реализованы как-то по-другому. Но работаем с ними только в методах CPostfixExpression.

CPostfixExpression myExp; //ну скажем, глобальная переменная

На кнопках
void CCalcButton::onClick()
{
myExp.calculate();
}
Как-то так...

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

class CPostfixExpression
{
public:
//вычисление выражения
float calculate();
//проверка валидности выражения
bool validate();
//добавить символ
void addSymbol(char _c)

//другие методы...

private:

//очередь
string m_Queue[1000];
//стек
float m_Stack[1000];
}

//Очередь и стек, вероятно, будут реализованы как-то по-другому. Но работаем с ними только в методах CPostfixExpression.

CPostfixExpression myExp; //ну скажем, глобальная переменная

На кнопках
void CCalcButton::onClick()
{
 myExp.calculate();
}

Не так. Класса CPostfixExpression вообще нет. В принципе, задача системы понята как вычисление единственного выражения, но с остановками для чтения пользователем части промежуточных результатов, а после чтения каждого промежуточного результата продолжается ввод выражения и расчёт его следующей части. Если же надо вдруг начать не связанный расчёт, то резет системы к начальному состоянию, в предыдущем сеансе её функционирование завершается и начинается новый. Соответственно и myExp превращается в само приложение, а его атрибуты - в самостоятельные объекты. И приходим к тому, что кнопка - элемент самого выражения. Я не настаиваю на том, что это всегда так. Это в данном конкретном проекте так по-нерусски. Или так нельзя? И очередь не строк, а смешанная. И с дополнительной возможностью получить тип элемента без извлечения самого элемента.

И на диаграмме у меня не классы, а именно объекты. Вопрос: правильно ли писать "объект::атрибут" и "объект::Операция(параметры)"? И сколько всего может быть ветвей с одного ромба?

И на диаграмме у меня не классы, а именно объекты. Вопрос: правильно ли писать "объект::атрибут" и "объект::Операция(параметры)"? И сколько всего может быть ветвей с одного ромба?

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

Что касается второго вопроса
http://www.uml-diagrams.org/activity-diagrams-controls.html#decision-node - ссылка была дадена, что еще ты хочешь услышать?
Сколько хочешь столько и может. Просто следует понимать: не нарушай читабельность, карсоту и гармонию диаграммы.

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

Код: [Выделить]

class A
{
 public:
  class B
  {
   ...
  };
 ...
}, не атрибута класса, а именно атрибута конкретного объекта.

Трансформатор - электрический девайс на подстанции, а это называется транслятор.

И к чему этот ликбез?

Итак, какова точно нотация элемента объекта... не атрибута класса, а именно атрибута конкретного объекта.

Я так понимаю это вопрос?
Я перефразирую ее примерно так:
Итак, какова точно нотация элемента строки...не столбца таблицы, а именно столбца конкретной строки.
1. для меня эта фраза звучит как абракадабра
2. что означает нотация элемента строки объекта? У каждого элемента свою нотация?
3. что такое нотация атрибута конкретного объекта?

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

Так что "нотация" атрибута конкретного объекта, можно допустить, = "нотации" атрибута класса, к которому относится объект.

Может я что-то не понял в вопросе? Или это был не вопрос? Повтори, пожалуйста.

Для изображения ветвления рисуются две или более стрелки, выходящие из одной точки фокуса управления объекта. При этом соответствующие условия должны быть явно указаны рядом с каждой из стрелок в форме сторожевого условия. Как нетрудно представить, если условие записано в форме булевского выражения, то ветвление будет содержать только две ветви. В любом случае условия должны взаимно исключать одновременную передачу альтернативных сообщений.

taras_aa а не получается ли у Вас , что Вы сначала написали код, а теперь пытаетесь логику изложить?

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

А читающий проверяет Вашу диаграмму на предмет нотации и он знает UML? Или задача понять Ваш код, схематично?

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

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

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

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

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

И к чему это ликбез?Я так понимаю это вопрос?
Я перефразирую ее примерно так:
Итак, какова точно нотация элемента строки...не столбца таблицы, а именно столбца конкретной строки.
1. для меня эта фраза звучит как абракадабра
2. что означает нотация элемента строки объекта? У каждого элемента свою нотация?
3. что такое нотация атрибута конкретного объекта?

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

Так что "нотация" атрибута конкретного объекта, можно допустить, = "нотации" атрибута класса, к которому относится объект. Может я что-то не понял в вопросе? Или это был не вопрос? Повтори, пожалуйста.

Элемент строки - ячейка, перепутать её с целым столбцом не возможно. При чём здесь схематичность - не понятно. Конечно, задача - понять. И надо исходить из знания языка, но если в UML принято одно, а у меня то же самое изображено совсем не так, то ни какой это не UML, такой нотации он не знает и должен будет листать всю модель в надежде понять сначала нотацию, а это сбивает с толку. Трансляторы всегда смотрели, где декларировано само имя, а уже там высняли, как. Прямоугольник же объекта имеет свой собственный код, отличный от кода прямоугольника класса. То есть для машины эти сущности абсолютно различны, как не перевирай нотацию при последующем использовании. А человеку надо, видя непосредственно данную конкретную диаграмму, опираться на свои знания, чтоб по памяти безо всякого листания определить, что именно изображено определённым символом, а не тратить время на поиск. Знания - информация в памяти, закреплённая многократным использованием, можешь считать их хранилище гигантским кешем. Аспекты же конкретной модели хранятся в обычной долговременной памяти, к тому же глючной. Поэтому и вспоминать, где видел такую же закорючку в данной модели долго, а знания извлечь в оперативу - быстро, и ошибиться в обозначениях на другом листе данной модели можно элементарно, а в знаниях можно быть хоть в какой то мере уверенным. И начинается не нужное листание и поиск. На те листы надо смотреть, когда нужны другие аспекты модели, изображённые там, иначе теряется наглядность, а с ней и смысл изображать что либо именно в виде диаграмм. Про стрелки из одной точки я знаю, но вопрос не в них, а в цикле. Вверх же стрелки не идут? Но и не одно отдельное итеративное сообщение. Жирные горизонтальные тоже известны, но у меня именно выбор ветви, а не разделение на параллельные нити. Нити исполняются одновременно и соответствуют потокам, но только истинно параллельным, а из ветвей исполняется только одна и не в момент времени, а вообще. Здесь два напитка. А если чай, кофе, квас и морс? Можно в один ромб сделать? Объекты надо подчеркнуть? Допустим. А после объекта как сослаться на его атрибут? Через двойное двоеточие? Через простое? Через точку? Через "->"? Как? И код я пока не писал.

Подчеркнуть пока не смог. Не подскажите, как это сделать?

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

И все-таки давайте по порядку, а то с утра как то не очень "переваривается".
Вам нужно в ветвлении нарисовать много стрелок?
Так нарисуйте

В точку ветвления может входить ровно один переход, а выходить - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов эти сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Но эти условия должны покрывать все возможные варианты, иначе поток остановится.

много букафф, не осилил...

Я все-таки никак не пойму цель топикстартера.
Есть язык UML, его стандрат доступен для изучения. Он имеет механизмы расширения. Это визуальный язык моделирования. Вопросы исполняемого кода UML изучаются в рамках инициативы MDA, например.

При чём здесь схематичность - не понятно.

А где я про схематичность написал?

Вам нужно в ветвлении нарисовать много стрелок?

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

Так нарисуйте

А можно? Как?

Есть язык UML, его стандрат доступен для изучения.

Ссылку можно?

Вообще, поисковые машины работаю релевантно

http://www.omg.org/spec/UML/

Documents Associated With UML Version 2.3

А можно? Как?

Вы в Visio рисуете ? Там нотация не проверяется.
И сами Visio Stencil and Template for UML 2.2