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

Есть ли у кого в арсенале более продвинутые способы построения логики приложения кроме цикла со свичами?

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

Поконкретнее задай вопрос.

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

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

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

В двух словах: между автоматом и средой должен быть удобный интерфейс который скрывает для второго реализацию первого.

Добавлено через 51 секунду
P.S.естественно первый о втором вобще не догадывается 

Использовать boost.statechart или другую библиотеку для КА?
Раз уж нравится использовать КА, почему бы не использовать более мощные средства их реализации, нежели простой switch

Abyx, а вот здесь уже интересно, счас почитаю отгуглю..

Чем multithreading (aka многопоточность) не устраивает? Для набора взаимодействующих задач - модель MVC (Model-View-Controller)

xvr, в принципе устраивает многопоточность, хотя и тянет за собой сложности с синхронизацией, и для некоторых проектов не применима (для однозадачных сред). Также возникают проблемы с сохранением/восстановлением состояния задачи (для конечного автомата можно скинуть на диск стейт, потом восстановить). Хотя наглядность кода, выше по моему мнению, особенно для реализации протоколов с каким нибудь железом и их отладки.

semibug, так ты же не общую теорию всего изобретаешь. Определись, можно ли использовать на твоем железе многозадачность. И используй, если можно. Это гораздо удобнее, чем закат солнца вручную с помощью переключений. И нет с синхронизацией сложностей - все давно придумано.
А если проекты разные (для разных сред), так и используй разные методы. Ты же розетки не молотком чинишь.

Earnest, Согласен.
Возьмем конкретный пример.
Имеем окошко программы с кнопкой "Do It!" и прогресс баром, каркас приложения создан с помощью мастера, выбран MFC.
По нажатию кнопки должна стартовать долгая задача, прогресс которой надо отобразить на прогресс баре. После старта задачи кнопка запуска становится неактивной до завершения задачи.
Варианты связи гуи с задачей:
  1. Выполнение задачи реализовать в виде последовательности кратковременых операций,  по нажатии кнопочки запускать цикл, в котором обновляется гуи и вызывается кусочек от операции, обновить прогресс бар
  2. Выполнение задачи вынести в отдельный поток. По нажатию кнопочки поток начинает выполнение необходимых действий, по таймеру в основном потоке проверяет завершение выполнение задачи, опрашивать (через критическую секцию) состояние прогресса и выводить на форму.
Есть ещё какие-то комбинации наверное.
Собственно какой вариант предпочтительнее(проще, правильней, красивей, более распространенный).

3й вариант -
Необходимые действия выносятся в поток, в нем в необходимых местах ставится отправка сообщений в основное окно, в параметрах сообщений закодированы необходимые действия, которое это основное окно и производит (например обновление прогресс индикатора, активация и деактивация кнопок и пр).

Есть еще 4й вариант, уже упоминаемая мною технология MVC, но ее лучше применять там, где уже есть ее поддержка (в Qt например), или где сложность системы перевешивает затраты на реализацию MVC самому
 

Вынести работу в отдельный _компонент_,  а ГУИ чтоб подавала ему команды, а также брало информацию и отображало себя.

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

Добавлено через 2 минуты и 1 секунду
В описанном тобою случае я бы выбрала поток.

Не совсем. У semibug 2й вариант включает не только поток, но и 
А вот это как раз и не совсем правильно - логику взаимодействия задает основной поток, а реализует эту логику - 2й поток. Более логично было бы отдать и то и другое одному и тому же потоку

Можно и с отдельным потоком сделать полную ж... (*)   
Так что 2й вариант распадается на несколько меньших подвариантов, и их тоже надо тщательно выбирать   

Так никто и не спорит. И в первом случае тоже есть разные варианты обеспечения нормальной работы интерфейса.

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

Про отображение речь не шла, речь шла об оповещении, что состояние изменилось.
UI - да, дело основного потока, а вот извлечение информации для отображения нет. Это должен предоставить рабочий поток. UI может вообще не знать, где и как эта информация представлена
Может быть существенно. Данные для отображения генерятся во 2м потоке, и доставлять их проще от источника (и именно в момент генерации) приемнику. Такая система доставки легко и непринужденно ложится на очередь сообщений Windows, и практически ничего за собой не тянет (в смысле объема кода). 
Доставка в противоположном направлении требует синхронизации, защиты разделяемых переменных, и возможно организации callback'ов из основного потока в 2й поток (для запросов) - это явно сложнее, чем один SendMessage
Это совершенно не нужная полумера - или отправлять сообщения 'по течению' (с помощью очереди сообщений Windows), или делать полноразмерную систему MVC. Тут же предлагается подход, удачно сочетающий недостатки обоих систем
Это уже MVC. Чрезвычайно гибкая и мощная система, но требует кода (как минимум того самого 'специальный управляющий элемент')

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

Ну да, конечно, только кода там кот наплакал - идея-то простая. 

В таком случае основной поток должен знать что то о рабочем потоке, в частности где у него лежит этот самый прогресс и как его достать. А это лишние логические связи в программе
Основной поток может выгрести поступающие сообщения, пока они есть в очереди, и только потом обновится
Абсолютно - конечно нет. Но если нет явных предпочтений и UI синхронизируемое обновление не является ПОЛНОСТЬЮ тривиальным, то лучше все же отправлять сообщения от рабочего потока. Ну или полный MVC
Кода не очень много, но он есть. И если нужно засинхронизировать отрисовку ТОЛЬКО прогресс бара и кнопок, то любой дополнительный код вполне может быть излишним