Пакетная обработка
В эпоху пакетных вычислений (то есть во времена, предшествовавшие появлению диалогового программного обеспечения) безраздельно царствовали алгоритмы. Тогда было возможно, и это имело действительно существенное значение, указать как входные, так и ожидаемые выходные данные системы еще до написания кода. В силу того, что модель применения программных продуктов описывалась схемой ввод→обработка→вывод, много времени тратилось на разработку центрального алгоритма, а главной задача проектирования заключалась в максимальной экономии дискового пространства и памяти. У этой модели есть свои достоинства, и сегодня она по-прежнему является идеалом, к которому следует стремиться при разработке отдельных процедур, предназначенных для обработки информации в пакетном режиме (например, при проектировании алгоритмов сортировки). Такой подход целесообразно применять при проектировании отдельных функций, но не сложных систем, обеспечивающих интерактивное взаимодействие с пользователем. Этот период можно назвать эрой "блок-схем".
Серверная обработка без сохранения состояний
При построении надежных серверных приложений, отвечающих на запросы, роль Святого Грааля играет "отсутствие состояния". Ваш код получает запрос, обрабатывает его, а затем возвращает результат, не нуждаясь в сохранении состояния на протяжении периода времени между двумя последовательными запросами. Все это очень напоминает пакетную обработку, поскольку в данном случае также используется модель, описываемая схемой ввод→обработка→вывод. Разумеется, современные сложные Web- приложения (например, система покупательских тележек на Web-сайте Amazon) должны сохранять свое состояние в течение промежутков времени между двумя последовательными запросами, а этого легче всего достигнуть осуществляя управление состояниями на основе существенно централизованного механизма инкапсуляции, обеспечивающего выполнение как можно большего объема кода без сохранения состояния
Интерактивные вычисления, управляемые событиями
Управляемые событиями вычисления (event-driven computing) представляют вычислительную модель, в которой приложение находится в состоянии долговременного обмена информацией с конечным пользователем. Выполнение кода осуществляется в ответ на действия и запросы конечного пользователя; задача приложения заключается в обеспечении соответствующей реакции на то, что делает пользователь. В отличие от пакетных приложений интерактивные (диалоговые) приложения не имеют определенного фиксированного периода завершения и продолжают обрабатывать новые события, запускаемые пользователем, до тех пор, пока пользователь не решит прервать рабочий сеанс. Эту модель программирования обычно называют "управляемой событиями", поскольку в результате действий пользователя вырабатываются дискретные события (например, события щелчка мыши, выбора элемента списка или закрытия окна), на которые должно реагировать разрабатываемое приложение. При построении удачного интерактивного приложения, управляемого событиями, очень многое зависит от того, насколько тщательно продумана модель управления состояниями.
Разработка программ является итеративным процессом, который, тем не менее, также должен подчиняться определенным правилам
В наши дни лишь немногие специалисты рекомендуют использовать блок-схемы для представления функционального поведения приложений. Начнем с того, что в этом случае приходится работать с блок-схемами огромных размеров. Современная модель программ, управляемых событиями, богатые пользовательские интерфейсы и широкодоступные инструментальные средства, обеспечивающие быструю разработку приложений, привели к тому, что идея отображения всех алгоритмов приложения и вариантов пользовательского взаимодействия с помощью блок-схем в настоящее время кажется уже старомодной. Детализация на таком уровне может быть использована для отображения отдельных ключевых алгоритмов, если это необходимо, но в целом требуется более высокоуровневый подход.
Существует и противоположный подход, ориентированный на конкретную специфику ситуаций, суть которого состоит в том, что необходимо "просто взяться за работу и составлять код, пока не будет получено завершенное приложение". При всей своей соблазнительности такой бездумный подход к программированию чреват возможными просчетами и обычно приводит к созданию беспорядочного клубка плохо функционирующего кода с массой "ляпов", который трудно сопровождать и от которого, в конце концов, вы откажетесь и будете переписывать заново. Приложения этого типа часто выглядят так, будто их "склепали" или "слепили лишь потому, что под рукой оказались их составные части. В этом случае все проектные решения принимаются в результате ответов на то и дело возникающие частные вопросы о том, каким образом можно решить ту или иную текущую проблему, и при этом мало внимания уделяется анализу того, каково будет общее влияние данного решения на систему в целом как в отношении ее поведения, так и в отношении сложности кода.