Курсовая работа: Особенности программирования для Windows
Иерархическая структура программ и реализованная в них схема взаимосвязи программных компонентов вполне удовлетворяет пользователей, работающих в DOS, но не способна удовлетворить пользователей Windows. Один из важнейших принципов Windows состоит в том, что пользователь должен всегда быть хозяином положения и в любой момент иметь самый широкий спектр полномочий по управлению вычислительным процессом. Например, пользователь, а не программа должен определять последовательность заполнения полей при вводе/корректировке данных. Более того, он должен иметь возможность вообще прервать на время процесс ввода/корректировки данных и обратиться к любой другой возможности из числа тех, которые предоставляются текущей или даже другой программой! Ведь Windows, в отличие от DOS, - многозадачная операционная среда.
Для реализации этого принципа программы, работающие под управлением Windows, не должны сами ожидать тех или иных действий от пользователя и заниматься их первичной обработкой, т.е. не должны быть модальными. Выполнение этой задачи берет на себя среда Windows, которая предоставляет такого рода “сервис" централизованно для всех программ.
В Windows все, что происходит во время работы программ и так или иначе может повлиять на дальнейший алгоритм их работы, называется событием . Нажатие или отпускание клавиши на клавиатуре, перемещение мышки или нажатие на ней кнопки, выбор варианта из меню - все это и многое другое представляет собой для Windows события. С учетом этого термина, говорят, что программы, работающие под управлением Windows, должны быть событийно-управляемыми . Такие программы, в противоположность “досовским”, управляются внешними событиями, а не управляют ими.
Событийно-управляемая программа должна быть представлена каким-то набором небольших программных единиц, работающих совершенно независимо друг от друга. Назначение каждой такой единицы заключается в функциональной (т.е. вторичной по отношению к Windows) обработке одного конкретного события , которое когда-то в силу каких-то причин может произойти. Программа, получив от Windows сообщение о происшедшем событии, должна быстро “отыскать" в своем наборе ту конкретную программную единицу, которая отвечает за его обработку, и отдать ей управление. Последняя, в свою очередь, должна максимально быстро выполнить необходимые действия и вернуть управление Windows. Требование максимальной быстроты обусловлено тем фактом, что в процессе работы каждой такой программной единицы Windows оказывается как бы “глухой" и невосприимчивой к любым новым событиям, которые могут произойти как в данной программе, так и в любой другой, работающей с ней параллельно[2] .
Таким образом, работающая под управлением Windows программа с момента своего запуска и до момента завершения не имеет непрерывного времени жизни : она периодически активизируется сигналом от Windows, вызывает соответствующий обработчик события и снова “засыпает".
Новая схема функционирования программы требует от ее создателей ярко выраженного модульного подхода к программированию. Каждый обработчик событий должен быть строго изолирован от любого другого. В противном случае чрезвычайно трудно предсказать реакцию программы в целом на одну из возможных комбинаций событий и гарантировать отсутствие нежелательных побочных эффектов.
При такой схеме работы программы с точки зрения разработчика появляется довольно неприятный побочный эффект: программа как бы утрачивает свою динамическую целостность. Действительно, если в DOS одним из важнейших программных компонентов для разработчика является стек вызовов, по которому всегда можно отследить историю вызовов или траекторию потока управлений в программе, то в Windows такой стек в подавляющем большинстве случаев оказывается практически непригодным, ибо не содержит в себе полезной информации.
1.2.1 Особенности работы с базами данных
Другой аспект, представляющийся весьма важным для разработчика при переходе от DOS к Windows, состоит в том, что программировать в новых условиях приходится с учетом возможности множественного одновременного доступа к файлам даже в том случае, когда программа задумана как однопользовательская.
При программировании в среде DOS сложилась весьма четкая классификация программ на однопользовательские и многопользовательские. Однопользовательская программа рассчитана на одного пользователя и может работать с файлами в простейшем монопольном режиме доступа. Многопользовательская программа пишется для локальной сети и обязана учитывать возможность одновременного доступа к файлам со стороны нескольких пользователей. Естественно, вторую категорию программ разрабатывать значительно труднее, особенно для случаев сложных транзакций. Выбрав однопользовательский вариант для своей программы, разработчик с самого начала руководствуется двумя соображениями:
“DOS работает в монозадачном режиме, следовательно никакая другая программа во время работы моей не будет иметь возможности обращаться к обрабатываемым файлам”;
“Структура моей программы мною же и определяется, поэтому я всегда могу построить ее таким образом, что никогда один и тот же файл не будет открыт дважды".
В среде Windows про однопользовательский режим работы приходится забыть хотя бы потому, что одну и ту же программу пользователь может запустить одновременно в двух “экземплярах”. Кроме того, имеются и другие факторы, побуждающие всегда разрабатывать только многопользовательские приложения. Для примера рассмотрим следующую, достаточно типовую для Windows-приложений, ситуацию. Допустим, в какой-то момент времени пользователь выбирает из меню вариант работы с файлом документов и в открывшемся окне приступает к выписке новой накладной на отпуск товара. Выше уже отмечалось, что по принятым в Windows стандартам хорошая программа должна в любых ситуациях предоставлять ему максимум своих функциональных возможностей, общий перечень которых заложен в меню. Поскольку меню в Windows не модально и доступно пользователю всегда, он может в силу соображений срочности приостановить ввод текущей накладной и приступить к вводу следующей, повторно выбрав из меню тот же вариант. Ясно, что в обеспечение этого разработчик не только должен предусмотреть возможность множественного доступа к файлам программы, но и позаботиться о том, чтобы эти файлы открывались в различных рабочих областях.
Данный пример приводит к следующим размышлениям. Оба окна и обслуживающие их программные коды должны быть вполне самостоятельными и самодостаточными компонентами общей программы, полностью реализующими принцип реентерабельности (т.е. допускающими свое существование во многих независимых копиях). Кроме того, необходимо позаботиться о том, чтобы при каждом новом открытии окна соответствующий файл открывался в новой рабочей области с уникальным алиасом (псевдонимом). И, наконец, окна должны иметь средства коммуникации друг с другом, поскольку каждое из них должно отражать реальную на данный момент времени информацию.
Таким образом, немодальный, многозадачный и многооконный режимы работы Windows добавляют разработчикам новые хлопоты. Каким образом создать приложение, способное устойчиво работать в столь сложной операционной среде? Ответ на этот вопрос следующий: успех ждет только на пути объектно-ориентированного программирования (ООП). И система CA-Visual Objects такое программирование обеспечивает в полной мере!
1.3 Структура программ в CA-Visual Objects
1.3.1 Объекты. Связи типа “владение "
Подробно реализация принципов ООП в CA-Visual Objects рассматривается в главе 3. Сейчас же мы коснемся этих вопросов лишь в той мере, в какой это необходимо для уяснения структуры приложений, создаваемых с помощью CA-Visual Objects, и их основных особенностей.
Программа в CA-Visual Objects - это совокупность объектов, способных взаимодействовать друг с другом посредством сигналов (сообщений).
Объект - некоторый функционально-полный компонент программы, обладающий вполне определенным набором свойств. Объект способен принимать сигналы (сообщения) от других объектов, реагировать на них и генерировать собственные сигналы (сообщения).
Нормально, объект пребывает в пассивном состоянии, ожидая получения предназначенных ему сообщений.
Получив сообщение X (см. рис.2.1), объект может изменить одно или несколько своих свойств (например, размеры, цвет) и сгенерировать одно или несколько сообщений Y для других объектов.
Характер реакции объекта определяется содержанием входного сообщения X. Отреагировав на очередное сообщение, объект снова переходит в пассивное состояние до тех пор, пока не получит извне новый сигнал.
Рис 1.14. Схематическое представление объекта
Объекты, имеющие общие “родовые” характеристики (т.е. сходные свойства и реакции на входные сообщения), объединяются в классы .
В ООП все возможные сообщения принято делить на две большие группы:
простые сообщения - те, которые имеют отношение к одному конкретному свойству объекта;
сложные сообщения - те, которые затрагивают одновременно несколько свойств объекта и/или побуждают его генерировать свои собственные сообщения.