Большинство приложений, написанных под DOS, имеют в принципе одинаковую иерархическую структуру. На самом верху этой структуры находится некая головная процедура или функция. Она отображает на экране меню и в зависимости от выбора пользователя, вызывает одну из функций второго уровня или завершает работу программы. В функциях второго уровня пользователю также могут быть предложены для выбора новые меню, в соответствии с которыми он может “спуститься" на один уровень ниже, еще более конкретизируя и детализируя вычислительный процесс, и т.д. На любом из уровней пользователю могут предлагаться окна для просмотра, ввода или корректировки информации, обрабатываемой данной программой. Во всех случаях, требующих вмешательства пользователя в вычислительный процесс (выбор из меню, ввод/корректировка данных и т.д.), программа переходит в режим ожидания.
В Clipper’е основные средства диалога с пользователем реализуются такими командами и функциями, как MENU TO, ACHOICE (),READ. Для всех них общим является модальный режим работы, т.е. такой режим, при котором программа своими средствами анализирует любую реакцию пользователя и не продолжает вычислительный процесс до тех пор, пока пользователь не предпримет заранее обусловленного программой действия (например, нажмет клавишу Esс). Модальный режим диалогов в DOS ограничивает возможности пользователя по управлению вычислительным процессом. Например, пользователь не может прервать на время ввод одного документа в базу данных и выбрать из меню вариант ввода или печати нового документа.
Иными словами, в DOS программа в большей степени руководит пользователем, нежели пользователь - программой. Программа как бы ведет пользователя за руку по своим “лабиринтам", предоставляя ему весьма ограниченный спектр возможностей по дальнейшим действиям на каждом “перекрестке”. В более общем плане можно сказать следующим образом: в DOS программа управляет событиями, а не события программой.
Иерархическая структура программ и реализованная в них схема взаимосвязи программных компонентов вполне удовлетворяет пользователей, работающих в DOS, но не способна удовлетворить пользователей Windows. Один из важнейших принципов Windows состоит в том, что пользователь должен всегда быть хозяином положения и в любой момент иметь самый широкий спектр полномочий по управлению вычислительным процессом. Например, пользователь, а не программа должен определять последовательность заполнения полей при вводе/корректировке данных. Более того, он должен иметь возможность вообще прервать на время процесс ввода/корректировки данных и обратиться к любой другой возможности из числа тех, которые предоставляются текущей или даже другой программой! Ведь Windows, в отличие от DOS, - многозадачная операционная среда.
Для реализации этого принципа программы, работающие под управлением Windows, не должны сами ожидать тех или иных действий от пользователя и заниматься их первичной обработкой, т.е. не должны быть модальными. Выполнение этой задачи берет на себя среда Windows, которая предоставляет такого рода “сервис" централизованно для всех программ.
В Windows все, что происходит во время работы программ и так или иначе может повлиять на дальнейший алгоритм их работы, называется событием. Нажатие или отпускание клавиши на клавиатуре, перемещение мышки или нажатие на ней кнопки, выбор варианта из меню - все это и многое другое представляет собой для Windows события. С учетом этого термина, говорят, что программы, работающие под управлением Windows, должны быть событийно-управляемыми. Такие программы, в противоположность “досовским”, управляются внешними событиями, а не управляют ими.
Событийно-управляемая программа должна быть представлена каким-то набором небольших программных единиц, работающих совершенно независимо друг от друга. Назначение каждой такой единицы заключается в функциональной (т.е. вторичной по отношению к Windows) обработке одного конкретного события, которое когда-то в силу каких-то причин может произойти. Программа, получив от Windows сообщение о происшедшем событии, должна быстро “отыскать" в своем наборе ту конкретную программную единицу, которая отвечает за его обработку, и отдать ей управление. Последняя, в свою очередь, должна максимально быстро выполнить необходимые действия и вернуть управление Windows. Требование максимальной быстроты обусловлено тем фактом, что в процессе работы каждой такой программной единицы Windows оказывается как бы “глухой" и невосприимчивой к любым новым событиям, которые могут произойти как в данной программе, так и в любой другой, работающей с ней параллельно[2].
Таким образом, работающая под управлением Windows программа с момента своего запуска и до момента завершения не имеет непрерывного времени жизни: она периодически активизируется сигналом от Windows, вызывает соответствующий обработчик события и снова “засыпает".
Новая схема функционирования программы требует от ее создателей ярко выраженного модульного подхода к программированию. Каждый обработчик событий должен быть строго изолирован от любого другого. В противном случае чрезвычайно трудно предсказать реакцию программы в целом на одну из возможных комбинаций событий и гарантировать отсутствие нежелательных побочных эффектов.
При такой схеме работы программы с точки зрения разработчика появляется довольно неприятный побочный эффект: программа как бы утрачивает свою динамическую целостность. Действительно, если в DOS одним из важнейших программных компонентов для разработчика является стек вызовов, по которому всегда можно отследить историю вызовов или траекторию потока управлений в программе, то в Windows такой стек в подавляющем большинстве случаев оказывается практически непригодным, ибо не содержит в себе полезной информации.
Другой аспект, представляющийся весьма важным для разработчика при переходе от DOS к Windows, состоит в том, что программировать в новых условиях приходится с учетом возможности множественного одновременного доступа к файлам даже в том случае, когда программа задумана как однопользовательская.
При программировании в среде DOS сложилась весьма четкая классификация программ на однопользовательские и многопользовательские. Однопользовательская программа рассчитана на одного пользователя и может работать с файлами в простейшем монопольном режиме доступа. Многопользовательская программа пишется для локальной сети и обязана учитывать возможность одновременного доступа к файлам со стороны нескольких пользователей. Естественно, вторую категорию программ разрабатывать значительно труднее, особенно для случаев сложных транзакций. Выбрав однопользовательский вариант для своей программы, разработчик с самого начала руководствуется двумя соображениями:
“DOS работает в монозадачном режиме, следовательно никакая другая программа во время работы моей не будет иметь возможности обращаться к обрабатываемым файлам”;
“Структура моей программы мною же и определяется, поэтому я всегда могу построить ее таким образом, что никогда один и тот же файл не будет открыт дважды".
В среде Windows про однопользовательский режим работы приходится забыть хотя бы потому, что одну и ту же программу пользователь может запустить одновременно в двух “экземплярах”. Кроме того, имеются и другие факторы, побуждающие всегда разрабатывать только многопользовательские приложения. Для примера рассмотрим следующую, достаточно типовую для Windows-приложений, ситуацию. Допустим, в какой-то момент времени пользователь выбирает из меню вариант работы с файлом документов и в открывшемся окне приступает к выписке новой накладной на отпуск товара. Выше уже отмечалось, что по принятым в Windows стандартам хорошая программа должна в любых ситуациях предоставлять ему максимум своих функциональных возможностей, общий перечень которых заложен в меню. Поскольку меню в Windows не модально и доступно пользователю всегда, он может в силу соображений срочности приостановить ввод текущей накладной и приступить к вводу следующей, повторно выбрав из меню тот же вариант. Ясно, что в обеспечение этого разработчик не только должен предусмотреть возможность множественного доступа к файлам программы, но и позаботиться о том, чтобы эти файлы открывались в различных рабочих областях.
Данный пример приводит к следующим размышлениям. Оба окна и обслуживающие их программные коды должны быть вполне самостоятельными и самодостаточными компонентами общей программы, полностью реализующими принцип реентерабельности (т.е. допускающими свое существование во многих независимых копиях). Кроме того, необходимо позаботиться о том, чтобы при каждом новом открытии окна соответствующий файл открывался в новой рабочей области с уникальным алиасом (псевдонимом). И, наконец, окна должны иметь средства коммуникации друг с другом, поскольку каждое из них должно отражать реальную на данный момент времени информацию.
Таким образом, немодальный, многозадачный и многооконный режимы работы Windows добавляют разработчикам новые хлопоты. Каким образом создать приложение, способное устойчиво работать в столь сложной операционной среде? Ответ на этот вопрос следующий: успех ждет только на пути объектно-ориентированного программирования (ООП). И система CA-Visual Objects такое программирование обеспечивает в полной мере!