Гдз. Документ Microsoft Word (3). Событийноуправляемое программирование

• Название: Событийноуправляемое программирование
• Дата: 18.11.2021
• Размер: 150.26 Kb.
• Имя файла: Документ Microsoft Word (3).docx
• Тип: Документы; #275588

Событийно-управляемое программирование

В Delphi программный код хранится в виде модулей. При этом структура модуля достаточно близка к аналогичной структуре в Турбо Паскале, хотя имеются и некоторые отличия:



Здесь Unit - зарезервированное слово (единица), начинающее

заголовок модуля; <имя> - имя модуля (правильный идентификатор);
Interface - зарезервированное слово (интерфейс), начинающее

интерфейсную часть модуля;

Implementation - зарезервированное

слово (выполнение), начинающее исполняемую часть;
Initialization - зарезервированное слово (инициализация), начинающее

инициа лизирую1цую частh модуля;
Finalization - зарезервированное

с:л.ово (завершение), начинающее завершающую

часть модуля; End - зарезервированное слово, являющееся признаком

конца модуля.

Таким образом, модуль состоит из заголовка и четырех составных

частей, любая из которых может быть пустой.




Технология создания приложений в DELPHI

В DELPHI

Объектно-ориентированный подход, так же как любая парадиг­ма программирования, подразум:евает прохоЖj\ение ряда этапов

при разработке программного продукта. Ранее уже описывались

этапы разработки программы при использовании структурного подхода к программированию, а также методика объектно­ориентированного проектирования. Безусловно, использование

объектов определяет некоторую специфику в последовательности

действий при создании приложения, хотя многое из того, что об­суждалось и использовалось ранее, остается в силе. Заметим, что

написание учебного приложения - это моделирование действий по разработке «взрослых}) программных продуктов, подразумева­ющее некоторое упрощение процесса с сохранением его основ­ных черт. С этих позиций и будем рассматривать далее этапы раз­работки приложений в Delphi. Отметим также, что процесс созда­ния программы чаще всего носит итерационный характер, т.е. сначала выполняются анализ, проектирование и реализация ин­терфейса или его части, а затем программа наращивается до по­лучения окончательного варианта.

Этапы разработки

■ постановка задачи, изучение предметной области, построе­ние модели (математической, информационной), проециро­вание построенной модели на разрабатываемое ООП­приложение;

■ проектирование ООП-приложения;

■ разработка интерфейса пользователя;

■ программирование приложения, тестирование и отладка программного кода;

■ разработка документации.

Проектирование ООП-приложения. Результатом первого этапа разработки является информационная модель исследуемого про­цесса, явления {в наше.:w. случае решаемой содержательной зада­чи). По сути, эта модель уже включает в себя, как минимум, набор объектов и связей между ними (т. е. для исходной системы выпол­нена декомпозиция}. На этапе проектирования ООП-приложения каждому объекту необходимо дать уникальное имя (задать иден­тификатор). Здесь же принимается решение, какие из объектов требуют визуализации, т.е. в терминах Delphi, какие компоненты будут отображены на форме.

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

Разработка интерфейса пользователя. При разработке интер­фейса пользователя необходимо отталкиваться от функциональ­ного назначения приложения. В Delphi особенность разработки интерфейса заключается в том, что многие его элементы (форма, компоненты и т.д.) уже присутствуют в среде программирования. Таким образом, интерфейс создается на базе имеющихся «:кирпи­чиков» и адаптируется под запросы потенциального конечного пользователя.

При разработке интерфейса пользователя необходимо соблюдать ряд правил

При проектировании окон (форм) ввода данных:

для команд всегда следует создавать клавишные эквивален­ты (при этом необходимо там, где это уместно, сохранять привычные эквиваленты), не заставляя пользователя приме­нять исключительно мышь;

расположение элементов на главной форме должно быть со­гласовано с задачами пользователяi

■ при вводе данных должна присутствовать заметная, но нена­вязчивая связь с пользователем (например, синтаксический контроль и, если возможно, исправление ошибок и опеча­ток);

■ для нескольких разных форм ввода не следует использовать существенно отличающиеся интерфейсы.

2. При создании меню:

■ следовать стандартным соглашениям о расположении пунк­тов меню, принятым в Windows;

■ группировать пункты меню в логическом порядке и по со­держанию;

■ для группировки пунктов в раскрывающихся меню исполь­зовать разделительные линии;

■ избегать избыточных меню;

■ использовать клавиатурные эквиваленты команд и «горя­чие» клавиши;

■ помещать на панель инструм:ентов часто используемые ко­манды меню.

З. При работе приложения в процессе ожидания следует ин­формировать пользователя о ходе работы {например, с 11омощью индикатора состояния выполнения задания).

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

Программирование, тестирование, отладка. Как уже отмеча­лось, на этапе проектирования приложения выделяется функцио­нальное назначение всех его элементов и возможные реакции на внешние и внутренние события.

Часть програм:много кода, которая касается ИIПерфейса приложе­ния, генерируется автоматически при помещении и настройке свойств соответствующих элементов. Часrь кода, касающуюся обра­ботки событий, создает программист. Кроме того, программный код может содержать вспомогательные подпрограммы, необходимые для функционирования отдельных частей или приложения в целом. Раз­мещение кода таких подпрограмм будет рассмотрено далее.