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

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

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

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

К примеру имеем пользовательское приложение, с набором кнопочек. Каждая запускает ту или иную задачу, которая может выполнятся длительное (относительно интерфейса) время. Также имеются зависимости задач друг от друга, т.е. какие то можно запустить параллельно, какие то зависят от завершения других.
В качестве вариант 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 секунду
В описанном тобою случае я бы выбрала поток.