ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Взгляд в будущее СУБД: Dataflex 3.0

Статья опубликована в выпуске журнала № 3 за 1992 год.[ 21.09.1992 ]
Аннотация:
Abstract:
Авторы: Мельников А.В. () - , , , Батюков А.Г. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 5728
Версия для печати

Размер шрифта:       Шрифт:

ОБЩИЕ ПОНЯТИЯ О СОБЫТИЙНО-УПРАВЛЯЕМОЙ СИСТЕМЕ

 

Одним из наиболее трудоемких этапов проектирования программных систем для работы с базами данных является разработка модулей интерфейса с пользователем. Это во многом связано с отсутствием в имеющихся пакетах СУБД достаточно мощных средств для разработки гибкого интерфейса, что объясняется ориентацией этих пакетов на достижение максимальных показателей при работе с файлами базы данных и некоторым скептическим отношением к пользовательскому интерфейсу, как к второстепенному вопросу.

С нашей точки зрения эффективный интерфейс с пользователем во многом позволяет достичь максимального эффекта при работе с базой данных. В связи с этим наличие такого интерфейса в системах управления базами данных является актуальным.

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

переход от одного окна экрана к другому;

перемещение курсора от элемента к элементу внутри окна;

выполнение выбора элемента;

ввод информации в окна ввода;

использование "горячих" клавиш;

получение на экране информации по сигналу таймера.

Большая часть элементов интерфейса должна иметь непосредственную связь с соответствующими элементами базы данных. В этом случае манипуляция элементами интерфейса превращается по сути в манипуляцию элементами базы данных.

Эти действия выполняются по запросам, источниками которых могут быть различные программные и аппаратные средства (клавиатура, манипулятор мышь, средства телекоммуникации, таймер и т.д.). С точки зрения системы, такие запросы могут быть расценены как события, требующие адекватной реакции вне зависимости от источника их возникновения.

Упрощенная структура такой системы представляет собой циклический процесс, в котором происходит постоянный опрос источников программных событий. В соответствии с контекстом события выполняется та или иная функция. Это основной признак событийно-управляемой программы (Event-Driven Program).

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

Событийно-управляемая программа имеет достаточную гибкость и адаптивность к изменению внешней ситуации. Это достигается за счет того, что программист имеет возможность добавлять новые обработчики событий и новым способом решать задачи интерфейса. Обработчики событий могут служить основой модульного построения программы и быть "кирпичиками" для создания библиотек.

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

ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ СУБД

DATAFLEX КАК СОБЫТИЙНО-

УПРАВЛЯЕМАЯ СИСТЕМА

Первой попыткой реализации событийно-управляемой программы на основе объектно-ориентированного подхода для систем управления базами данных явилось создание в 1993 году пакета Data Flex 3.0, что стало долгожданным событием для программистов СУБД. Пакет DataFlex 3.0 представляет собой исполняющую систему со своей языковой средой, предназначенной для разработки как процедурно-ориентированных, так и полностью объектно-ориентированных программ.

Пакет DataFlex 3.0, реализуя принципы ООП, позволяет конструировать и интерфейс пользователя, и управление базой данных. Основной структурой языка, которой можно манипулировать как именованным целым, является объект. Он имеет имя и состоит из внутренних данных, свойств объекта, определяющих его состояние, методов, в качестве которых используются процедуры или функции объекта, команд назначения "горячих" клавиш и образа, используемого для отображения объекта на экране.

Программы, написанные в объектно-ориентированном стиле, строятся с помощью комбинирования объектов различных классов. Связь с внешней средой и между объектами реализуется посредством сообщений.

Что же такое сообщение в ООП и чем оно отличается от команды в процедурном программировании? Предположим, что необходимо отобразить на экране какую-либо информацию. В процедурном программировании команда, выполняющая эту функцию, должна содержать указание что, где и как размещать на экране. При этом необходимо, вероятно, позаботиться О сохранении предыдущего образа экрана. Этот подход довольно утомителен при программировании достаточно больших программ, особенно применительно к задачам СУБД. В DataFlex для выполнения этой функции достаточно одной команды активизации данного образа посредством передачи объекту, содержащему этот образ, сообщения. Например, использование команды

send activate to screenl

вызовет передачу объекту screenl сообщения activate, что приведет к выполнению этим объектом метода activate, который активизирует данный объект и вызовет отображение его образа на экране.

Первое различие между командой в процедурном программировании и сообщением состоит в том, что объекты, принадлежащие разным классам, могут интерпретировать одно и то же сообщение совершенно по-разному. Это достигается тем, что объекты могут иметь одноименные методы, но с различным внутренним контекстом. Эта особенность ООП называется полиморфизмом.

Второе различие заключается в том, что методы, свойства и внутренние данные "спрятаны" от других частей программы внутри объ-* екта. Так, метод может быть выполнен только тогда, когда вместе с соответствующим сообщением передается и имя объекта - получателя этого сообщения. То же самое относится и к свойствам объекта. Это понятие называется инкапсуляцией. В DataFlex используется правило: только методы и свойства объекта доступны из других объектов. Что касается внутренних данных объекта, не являющихся свойствами, то доступ к ним может быть осуществлен только из методов этого объекта. Инкапсуляция позволяет выбирать имена методов и свойств свободно, что достигается за счет использования сложного имени, состоящего из имени объекта и имени свойства или метода, к которому выполнялось обращение.

ДИСПЕТЧЕРИЗАЦИЯ СОБЫТИЙ

События, возникающие вне ядра DataFlex, обрабатываются диспетчером программных событий, который формирует сообщения с уникальным именем и адресует его некоторому объекту или группе объектов. Используя утилиту пакета DECONFIG, можно назначить предопределенным сообщениям некоторую комбинацию клавиш. Например, сообщению "Сохранить запись" можно назначить клавишу F2, тогда во время выполнения программы нажатие этой клавиши вызовет генерацию данного сообщения. DataFlex поддерживает 54 предопределенных сообщения. Кроме предопределенных сообщений, генерируемых при нажатии установленных в DECONFIG клавиш или кнопок "мыши", в программе можно определить и сообщения, которые заранее не были определены в пакете. Назначения производятся специальной командой определения "горячих" клавиш.

МЕТОДЫ ОБЪЕКТА - ОБРАБОТЧИКИ СОБЫТИЙ

Для обработки полученного сообщения в теле объекта должен быть определен метод (процедура или функция) с таким же именем, как и у сообщения. Внутри этого метода могут

быть команды посылки сообщений другим объектам с помощью команды send.

ОБРАЗ ОБЪЕКТА - ЕГО ВИДИМЫЙ АТРИБУТ

Объект DataFlex может иметь образ, который отображается на экране при активизации объекта. В DataFlex при определении образа используется принцип "look and feel", т.е. как образ представлен в тексте программы (размер, содержимое, взаимное расположение элементов), так он будет отображаться на экране при выполнении программы. Образ имеет имя, которое указывается при определении объекта. Подход, использующий элементы образа, может применяться как для организации меню, так н для организации окон ввода информации.

ОБЪЕКТЫ И КЛАССЫ

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

Класс определяет назначение объекта и обеспечивает обработку любых сообщений, реакция на которые заложена в этом классе. Например, если класс будет использоваться для создания объекта ввода данных, то он должен иметь образ для вывода на экран, процедуры и функции для управления перемещением по элементам и для ввода данных. Кроме того, должны быть назначены "горячие" клавиши для реализации навигации, поиска, сохранения и удаления записей в файле базы данных.

На основе уже имеющихся может быть определен новый класс. Класс, базирующийся на другом определении, является подклассом, а тот, на котором он базируется - суперклассом. Подкласс наследует структуру внутренних данных, свойства и методы этого суперкласса. Все атрибуты суперкласса становятся доступными в подклассе. В процессе наследования исходный код и память предка сохраняются и используются его потомками. В пакете DataFlex подкласс может иметь только один суперкласс. В некоторых языках (например в C++) подкласс может наследовать атрибуты из более чем одного суперкласса.

В подклассе обычно имеется возможность для переопределения методов из суперкласса. Каким образом специфицировать методы, которые могут быть переопределены? Существует два способа. Суть первого состоит в том,

что программист должен указать на последовательность методов, которая может быть переопределена; например, в С+ + это объявление метода виртуальной функцией. Метод, который нельзя переопределить - это конструктор суперкласса. Второй способ (он поддерживается DataFlex) заключается в том, что любой из методов суперкласса может быть переопределен в подклассе и вставлен как единое целое между операторами методов подкласса. Можно говорить в этом случае, что метод суперкласса расширен в под классе. Этот способ обеспечивает большую гибкость^за счет того, что метод в объекте, базирующемся на подклассе, может отправить сообщение суперклассу.

В DataFlex различают в соответствии с источником их получения четыре типа классов: абстрактные, базовые, предопределенные и пакетные.

Абстрактными являются классы, сущест-вующие до выполнения программы и предназначенные для определения на их базе других классов. Они отличаются специфичным функциональным назначением. Объект не может быть объявлен как объект абстрактного класса.

Базовые классы DataFlex (а их 6) предназначены, для создания на своей основе классов, экземпляры которых выполняют следующие функции:

ARRAY - хранение информации; EDIT - редактирование текста; LIST - выбор элемента из динамического списка;

MENU - выбор элемента из статического списка;

MESSAGE - отображение информации без права выбора;

SCROLLB - создание динамической линии прокрутки для классов EDIT и LIST.

Предопределенные классы - это классы, которые строятся во время выполнения. Классы этого типа автоматически становятся доступными для использования при наличии в программе команды use имя-класса. Они вместе с базовыми классами являются наиболее эффективными. Некоторые из них могут быть использованы для создания только объектов, а некоторые — как суперклассы.

Создаваемые классы (пакеты). Определения этих классов представлены на языке DataFlex и помещены в файлы, называемые пакетами. Программист может расширять иерархию классов путем создания собственных пакетных классов и размещения их в пакетных файлах.

ДЕЛЕГИРОВАНИЕ СООБЩЕНИЙ

Большинство объектно-ориентированных языков поддерживает только простое множество классов, когда метод определяется локально в определении класса, а определение объекта внутри определения класса и определение объекта внутри другого объекта не поддерживается. В пакете DataFlex эта возможность предоставляется. Подобно структуре процедур Паскаль-программы, язык DataFlex имеет

блочную структуру. Это означает, что возможно опредйление одного объекта внутри другого. Внутренний объект будет являться потомком. Каждый объект имеет одного предка и может иметь одного или более потомков. Это нисколько не означает, что потомок наследует свойства предка. Единственное, что наследует потомок от предка, это координаты расположения, цвет образа объекта на экране и назначенные для предка "горячие" клавиши. Употребление в этом смысле терминов потомок, предок, наследование противоречит терминологии ООП и может быть использовано только применительно к программам DataFJex. Подобная структура программы позволяет выполнить такую очень важную функцию событийно-управ-ляемой программы, как делегирование сообщений. Помимо этого, размещение объекта внутри другого позволяет потомкам различных объектов иметь одинаковые имена. Таким образом, структура программы DataFlex представляет собой дерево с одним общим предком и потомками, расположенными на ветвях этого дерева.

Делегирование сообщений от объекта к объекту принадлежит исключительно DataFlex 3.0. Данная особенность отличает механизм обработки сообщений DataFlex от классического ООП.

Существуют специальные команды, оказывающие влияние на механизм делегирования сообщений. Так, программист может предусмотреть внутри метода, который обрабатывается в ответ на сообщение, посылку сообщения с тем же именем классу этого объекта. Это вызывает стандартную реакцию, заложенную в классе.

ОБЪЯВЛЕНИЕ ОБЪЕКТОВ В ПРОГРАММЕ

Объявление объектов в программе DataFlex должно включать в себя следующие компоненты (символом "*" помечены компоненты, присутствие которых в определении объекта обязательно): - определение образа объекта (отсутствует,

когда объект не имеет образа); * определение имени объекта и класса, к которому он принадлежит;

 

определение внутренних переменных и свойств объекта;

инициализация свойств и внутренних пере менных объекта;

назначение элементов образа;

определение объектов-потомков;

определение методов (если отсутствуют, то все сообщения делегируются классу объекта и выше по цепочке объектов и классов);

назначение "горячих" клавиш (если отсутст вует, все назначения наследуются из класса или из старших предков);

* конец объявления объекта.

Р-абота данной программы начинается с назначения "горячих" клавиш, определяющих сообщения, которые посылаются текущему объекту при их нажатии. Далее посылается сообщение активизации объекта example, образ которого отображается на экране, к этот объект становится текущим. После запуска диспетчера программных событий методы текущего объекта выполняются в ответ на предопределенные сообщения и сообщения, заданные для него командами on_key. Так, ме'год left будет выполняться при посылке сообщения left, которое генерируется при нажатии комбинации клавиш Ctrl-Fl. Внутри этого метода в переменную coordinates помещаются текущие координаты образа объекта, которые содержатся в свойстве объекта location. Далее они изменяются с помощью команды set. Поскольку в DataFlex для представления данных типа integer используется длинное целое (32 бита), и координаты образа помещаются в одну переменную, то осуществить доступ отдельно к координатам X и Y, хранящимся соответственно в первых двух и следующих двух байтах переменкой coordinates, позволяют функции hi() и low(). Прекращение выполнения программы осуществляется посылкой сообщения cancel текущему объекту при нажатии клавиши "Esc". Метод с таким именем определен только в объекте DeskTop, приняв который, он посылает сообщение deactivate всем своим потомкам и заканчивает выполнение программы. Приняв такое сообщение, объект example убирает свое изображение с экрана и освобождает память.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1456
Версия для печати
Статья опубликована в выпуске журнала № 3 за 1992 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: