1. Урок первый
2. Урок второй
3. Урок третий
Clarion на персональном компьютере
Давайте начнем с одной несложной задачи из реальной жизни и попробуем понять, как она решается средствами системы Clarion.
Итак, требуется создать приложение, которое позволило бы обеспечить контроль
за успеваемостью студентов в некоем воображаемом университете.
В соответствии с американской системой (а задача эта позаимствована из примера TopSpeed University, входящего в комплект поставки CW 2.0) успеваемость характеризуется оценками, которые получает студент на промежуточном экзамене, на итоговом экзамене и по результатам курсовой работы. Все они заносятся в ведомость и суммируются (оценка итогового экзамена удваивается), а окончательная оценка получается путем деления всей суммы на 4. Каждый студент вправе выбрать для получения знаний разные учебные курсы (курс отражает конкретную дисциплину). При этом студент является выпускником вполне определенного факультета (его название и составляет предмет специализации). Преподаватели курсов не могут работать сразу на нескольких факультетах, при этом за каждым из них закрепляется самостоятельное ведение одного или более курсов.
Построение информационной модели
Создание приложения начнем с построения информационной
модели (схемы базы данных). В принципе процесс построения модели не столь уж и
сложен, но факт остается фактом: для тех, кто впервые с этим сталкивается, он
вызывает наибольшие трудности в понимании. Поэтому давайте наберемся немного
терпения и постараемся аккуратно в нем разобраться.
Итак, в проектируемой нами информационной модели несложно выделить следующие
категории объектов (сущности): студенты (Students), преподаватели (Teachers),
предмет специализации (Majors), дисциплины (Courses), учебные курсы (Classes).
Кроме этого, каким-то образом необходимо учитывать саму успеваемость студента по
каждой из выбранных им учебных дисципин, да еще с учетом года обучения.
Система Clarion ориентируется на наиболее распространенную реляционную схему
(модель) представления данных, а отсюда следует, что наша информационная модель
должна в конечном итоге состоять из набора взаимосвязанных реляционных таблиц, в
которых хранится описание объекта реального мира и его связь с другими
объектами. Каждая такая таблица, в свою очередь, состоит из строк и столбцов.
Она отражает конкретный тип (класс) объекта и обладает уникальным именем. В
нашем случае на роль имен подобных таблиц претендуют Students, Teachers, Majors
и т.д.
Каждая строка таблицы отражает вполне конкретный объект данного типа, а
пересечение ее с тем или иным столбцом (полем данных) определяет значение
конкретного атрибута (свойства) этого объекта.
В нашем примере самой простой по своей структуре является таблица Majors.В
ней всего два атрибута ≈ номер (индентификатор) предмета (Number) и его название
(Description). Уже при построении таблицы часто можно сразу же оценить
потребности в физическом представлении этих атрибутов.
Итак, если общее число предметов специализации (факультетов) у нас составляет
один-два десятка, то для атрибута разумнее всего выбрать целочисленный тип в
однобайтовом представлении (BYTE), ведь он способен представлять числа в
диапазоне от 0 до 255. Название ≈ это уже текстовая строка (STRING), длина
которой должна подбираться с учетом наиболее длинного из возможных названий
предметов. Представителями (объектами) этого типа могут служить, скажем,
компьютерная наука (Computer Science), английский язык (English),
математика (Mathematics) и т.д.
Аналогичным образом мы строим таблицу Courses, в которой
будут храниться названия учебных дисциплин, таких как
микрокомпьютеры
(Microcomputers), программирование (Programming), алгебра (Algebra) и т.д.
Но в ней добавим еще одно поле для расширенного пояснения сути данной
дисциплины. Поскольку это пояснение может состоять не из одной строки, а из
нескольких, то самым удачным решением для хранения подобного комментария объекта
может служить характерный для Clarion специальный встроенный тип
MEMO.
При формировании информационной модели не следует
забывать и о ключах (индексах). Каждый ключ определяет порядок доступа к
объектам (записям) данной таблицы в соответствии со значениями конкретных полей.
Например, если в качестве ключа выбирается поле Number, то при работе с ним
доступ к записям будет осуществляться строго в порядке возрастания (или
убывания) значений этого поля, причем вне зависимости от хронологии занесения
записей в данную таблицу. Ключ может строиться сразу по нескольким полям одной
таблицы. В этом случае порядок доступа определяется как значениями полей, так и
последовательностью их имен внутри данного ключа.
Обратите внимание, что в обоих таблицах идентификатор
записи служит для компактного (числового) обозначения уникальности конкретного
объекта. И практически каждая подобная таблица должна обладать ключом,
построенным по этому полю. Такой ключ называют первичным (primary key),
поскольку он однозначно определяет каждую строку (запись) реляционной
таблицы.
Следующей по сложности таблицей является Teachers
(преподаватели). Какие атрибуты можно выделить у этого типа объектов? Помимо
традиционного для большинства реляционных таблиц числового идентификатора
объекта каждый преподаватель имеет вполне конкретное имя (FirstName) и фамилию
(LastName). Кроме того, часто может потребоваться знать точный домашний адрес и
номер телефона (рис.1). В нашей информационной модели каждый преподаватель может
относиться только к одному вполне конкретному факультету. А если принять во
внимание, что факультет (его название) однозначно определяет предмет
специализации (таблица Majors) каждого студента, то возникает вполне
справедливый вопрос: как организовать связь (построить отношение) между нашими
таблицами Majors и Teachers ?
Достигается это следующим образом. В таблице Teachers
заводим специальный атрибут (поле) принадлежности факультету (Department). Тип
этого поля выберем таким образом, чтобы оно в точности соответствовало типу
идентификатора объектов из таблицы Majors. Если там выбран тип BYTE, то и мы для
поля Department должны выбрать тип BYTE (8-разрядное целое). Если там выбран тип
LONG, то и мы должны выбрать тип LONG (32-разрядное целое). Поскольку связь
между таблицами устанавливается через ключи, то нам осталось для таблицы
Teachers построить специальный ключ (KeyDepartment), в котором задействовано
поле Department. Подобный ключ является как бы отражением (представительством)
первичного ключа таблицы Majors (KeyNumber). А потому его называют внешним
ключом (foreign key) таблицы Teachers. Это не что иное, как интерфейс таблицы с
внешним миром (с другими таблицами).
Теперь для формирования связи все готово и осталось сделать лишь небольшой
штрих ≈ со стороны таблицы Teachers задать тип отношения MANY:1
(многие-к-одному), связав поле Department из таблицы Teachers (TEA:Department) с
полем Number из таблицы Majors (MAJ:Number). Другими словами, тем самым, мы
подчеркнули в своей информационной модели тот факт, что РАЗНЫЕ преподаватели
могут относиться к одному и тому же факультету. Обратное утверждение неверно.
Задав такое отношение, мы автоматически получили и обратное отношение со стороны
таблицы Majors, которое уже имеет тип 1:MANY (один-ко-многим).
Давайте теперь ненадолго отвлечемся от нашей задачи и
поговорим о понятии отношения (relation). Зачем нужно задавать структуру таблицы
(имена и типы полей, ключи доступа), наверное, понятно. Без этого не обойтись. А
вот для чего требуется формировать еще и какие-то отношения? Неужели при
разработке приложения для данной информационной модели нельзя просто в
программном коде учесть тот факт, что поле TEA:Department (в Clarion так
обозначают его полное имя с учетом префикса таблицы) ≈ это практически то же
самое, что и MAJ:Number? Что ж, эт о не возбраняется. Но тогда вместо
автоматического построения кода всю логику поддержки отношений вам придется
программировать вручную. Чтобы оценить всю трудоемкость подобных операций,
давайте призадумаемся, какие проблемы могут у нас возникнуть при ручном
программировании. Во-первых, если в поле EA:Department будет занесено значение,
которого нет в поле MAJ:Number ни у одной из записей таблицы Majors, то налицо
грубейшее нарушение нашей модели.
Получается, что преподаватель работает на каком-то факультете,
которого в данном университете попросту нет. Образовалась
висячая ссылка. Кто
же будет это контролировать и отвечать за нарушение данного правила?
Пойдем дальше. Если связь с факультетом была корректной (программист вручную
постарался это обеспечить), то она легко может порваться при удалении из таблицы
Majors соответствующей записи о факультете. Ведь факультет вполне могут
реорганизовать, укрупнив за его счет другие факультеты. Опять та же
проблема. А теперь на секунду представьте, что начнет происходить, когда ваша
модель в силу реальной сложности исходной задачи начнет напоминать известный по
Маршаку дом, который построил Джек, где связи между таблицами будут столь
многоступенчатыми и замысловатыми, что вы с трудом сможете обеспечивать
корректность работы вашей информационной модели.
Здесь мы столкнулись с крайне важным понятием целостности
данных, точнее говоря, с одной из ее разновидностей, которая носит название
ссылочной целостности (referential integrity). В системе Clarion используется
четыре разных вида ссылочной целостности (No Action, Restrict, Cascade, Clear).
Но подробнее о них мы поговорим на следующем занятии. А сейчас, осознав всю
важность автоматического контроля отношений, давайте вновь вернемся к нашей
задаче.
Мы расстались с ней тогда, когда построили три таблицы
(Majors, Courses и Teachers). Пойдем дальше. Аналогично таблице Teachers строим
таблицу с описанием студентов (Students). Здесь нам понадобится добавить поле,
где указывается год окончания университета (GradYear). Кроме того, хотелось бы
знать в лицо хотя бы некоторых из студентов, для чего нам потребуется ввести
поле Photograph. Тип этого поля будет BLOB (binary large object ≈ большой
двоичный объект). Еще один небольшой нюанс ≈ связь с таблицей Majors мы будем
организовывать через поле STU:Major, поскольку в нашей модели мы отождествили
два понятия ≈ факультет и предмет специализации.
Для определения понятия учебный курс построим таблицу
Classes. В ней нам понадобится завести поле для хранения составного номера курса
(своеобразного идентификатора), которое мы назовем ClassNumber. Затем нам
понадобится хранить номер аудитории (мы создаем не систему расписаний занятий,
поэтому для простоты будем исходить из того, что за каждым курсом закреплена
конкретная аудитория). Дадим ему имя RoomNumber. Теперь нам надо не забыть о
поле, отвечающем за день и время проведения занятий (пусть для разнообразия оно
будет обычной строкой, в которую мы в сокращенном виде будем заносить день
недели и время начала занятия). Назовем его ScheduledTime. Для полноты нашей
модели нам необходимо завести два ссылочных поля: CourseNumber (для связи с
таблицей Courses) и TeacherNumber (для связи с Teachers). Реализуем это все
через тот же механизм первичных и внешних ключей.
Осталось сделать самую малость ≈ с помощью таблицы
построить понятие успеваемости. Эта таблица (Enrollment) несколько будет
отличаться от всех, которые мы уже построили. По сути ≈ это экзаменационная
ведомость, в которой должны присутствовать идентификатор студента
(StudentNumber) и идентификатор курса (ClassNumber), а также все три вида оценок
≈ MidtermExam (промежуточный экзамен), FinalExam (итоговый экзамен), TermPaper
(курсовая работа). Хранить в базе данных окончательную оценку (являющуюся
функцией этих трех оценок) не нужно. Ведь ее можно вычислять по мере
необходимости (например, при отображении на экране соответствующей
колонки).
Внимательный читатель, похоже, уже догадался, что
StudentNumber и ClassNumber ≈ это ссылочные поля, обеспечивающие связь между
таблицей Enrollment и соответственно таблицами Students и Classes. Но здесь
можно легко проглядеть другой важный момент: таблица Enrollment с помощью
слияния в одной записи двух отношений типа MANY:1 обеспечивает отношение
MANY:MANY (многие-ко-многим). Другими словами, один и тот же студент может
проходить обучение по РАЗНЫМ курсам, и на одном и том же курсе могут проходить
обучение РАЗНЫЕ студенты (рис.2). Таким образом, ведомость (Enrollment) здесь
является той информационной прослойкой, которая позволяет за счет промежуточной
таблицы преобразовать сложное отношение MANY:MANY в два простых. Теперь
информационная модель для нашей задачи построена, так что можно перевести дух и
подвести некоторые результаты.
Обратите внимание, что все поля в каждой таблице условно
можно разбить на три группы ≈ идентификатор, тело и ссылки. Различные комбинации
этих групп определяют разные по своему назначению виды таблиц. Так, таблицы
Majors и Courses не имеют ссылок, а потому (напрямую) не зависят от других
таблиц. Если проводить аналогию с пожарным делом и такими известными терминами,
как резервуар, рукав и муфта, то подобным таблицам больше всего подходит
название резервуара. Таблицы Teachers, Students и Classes имеют подобные ссылки;
соответственно им ближе понятие пожарного рукава. Наконец, таблица
Enr0000ollment не имеет идентификатора, состоит только из ссылок и тела и служит
для организации отношения многие-ко-многим, вот почему такому виду таблиц
лучше всего подойдет понятие соединительной муфты.
Во избежание неверного толкования следует помнить, что в технологии Clarion
существует одна неприятная терминологическая особенность: реляционная таблица в
ней называется просто файлом (File). Об этом не надо забывать, когда вы начнете
работать с системой Clarion или знакомиться с ее документацией. Подобная
путаница ≈ дань традиции, когда на заре своего развития понятие таблица (Table)
в Clarion было зарезервировано под определение визуальной формы табличного
отображения данных. Интересно, а чем же
принципиально отличается подход к построению информационной модели в системе
Clarion от того, что принято в большинстве известных СУБД (Oracle, Informix, DB2
и т.п.) ? Да по сути ничем. Разница лишь в форме хранения схемы БД и в
механизмах ее построения и ведения. В системе Clarion для этих целей
служит специальный файл-контейнер (файл с расширением .DCT), который называется
словарем данных (Data Dictionary). Наряду с таблицами, ключами, индексами и
отношениями в нем содержится информация о формате хранения таблицы (TopSpeed,
Clarion, Btrieve, ASCII, BASIC, DOS, Clipper, dBase, FoxPro, Paradox, ODBC).
Кроме того, здесь хранится формат полей ввода данных для соответствующих полей
таблиц, пароль доступа к таблице, полное имя файла для данной таблицы, признаки
методов контроля ссылочной целостности, условия входного контроля заносимых
данных (валидаторы), признак автоматической утилизации удаленных записей и
многое другое. Так что в случае необходимости вы всегда можете задействовать эти
ручки тонкой настройки вашей информационной системы. Интересно и то, что сам
словарь, в свою очередь, является базой данных, при этом Clarion предоставляет
возможность отображения ее в текстовый формат (выгрузка служебных данных, формат
.TXD) для последующего ручного редактирования и обратной загрузки в формат
.DCT.
Автоматическое построение модели
приложения Теперь, когда построен словарь данных, мы можем
автоматически сгенерировать на его основе типичное информационное приложение.
Для этого достаточно в системе Clarion при создании приложения указать признак
использования эксперт-программы (Application Wizard), предназначенной для
автоматического пост0роения логической модели приложения (.APP). Если в вашем
распоряжении имеется любая редакция Clarion for Windows или пробная (trial)
версия этого продукта, то разыщите среди стандартных примеров приложение
TopSpeed University (CW20EXAMPLESSCHOOL), создайте себе рабочий каталог и
скопируйте в него файл SCHOOL.DCT и все файлы с расширением .TPS (это файлы БД,
в которые уже занесена некоторая информация). А теперь при создании нового
приложения воспользуйтесь услугами Application Wizard. В результате в вашем
рабочем каталоге автоматически будет создан файл с расширением .APP (модель
приложения), который тотчас же будет загружен в среду Clarion. Перед вашими
глазами предстанет дерево логики вызовов Clarion-процедур. Вы можете внести в
него изменения (а можете ничего и не трогать) и после этого через поле меню
Project ≈> Make можете запустить процесс получения исполняемого файла
(SCHOOL.EXE). По этой команде на основе скелета приложения и специальных
программных Clarion-шаблонов система управления проектом (Make) начнет
генерирование исходных текстов на языке Clarion (эти файлы имеют расширение
.CLW).Затем начнется трансляция этих текстов в привычные программистам объектные
файлы для процессоров Intel семейства x86 и Pentium (к сожалению или к счастью ≈
для кого как ≈ компилятор Clarion пока не позволяет генерировать код для
процессоров Intel MMX). Как только закончится сборка EXE-файла, вы можете, не
выходя из Clarion-среды, с помощью кнопки Run запустить построенное приложение
(рис.3). На этих простых манипуляциях со средой разработки вы смогли увидеть в
действии почти все основные элементы кухни
Clarion.
Попробуйте сравнить теперь интерфейс, функциональность и
логическую модель вашего приложения с первоначальным решением той же задачи,
которое получил автор TopSpeed University ≈ Ричард Тейлор (Richard Taylor), член
Совета директоров фирмы TopSpeed, являющейся преемником Clarion Software и
нынешним владельцем всего Clarion-инструментария. Вы сразу заметите, насколько
более удобной и органичной выглядит версия TopSpeed University в исполнении
Ричарда Тейлора. Причем доводка приложения осуществлялась им не с помощью
ручного кодирования, а с использованием компонентного программирования на основе
программных Clarion-шаблонов.
Здесь можно подметить еще одну интересную особенность
Clarion. Понятие макетирования (prototyping), которое ныне приобретает все
больший вес в традиционном жизненном цикле программного продукта, развивается и
совершенствуется в технологии Clarion с первых дней ее рождения. Именно макет
является отправной точкой быстрого построения и удобного сопровождения
достаточно сложных информационных систем.Если инструментальная среда позволяет
создавать действующие макеты, которые с трудом можно отличить от готовой
прикладной системы, то это всегда говорит об огромном потенциале и высоком
качестве подобной среды.При работе с технологией Clarion между макетом и готовой
системой подчас очень трудно провести грань. Все здесь зависит от того, какие
требования вы или ваш заказчик предъявляете к конечной системе (исходя,
разумеется, из реальных ограничений на время разработки). В качестве
самостоятельного упражнения попробуйте, отталкиваясь от автоматически
построенного макета приложения для нашего примера, постепенно довести его до
эталона Ричарда Тейлора (а заодно и русифицировать). Через некоторое время вы
поймете, что эталон наш весьма далек от совершенства, так что (при наличии
времени и желания) доводить до нужной кондиции его можно еще довольно
долго.
Так все же, каким образом при работе со средой Clarion
удается быстро, почти на автомате, строить работоспособный макет и, фактически
не прибегая к ручному кодированию, без потери логических связей и структуры
данных доводить его до нормальной системы? Секрет здесь кроется в двух моментах
≈ в архитектуре самой системы Clarion и в специальном механизме программных
шаблонов (templates), о которых подробнее мы поговорим на следующем
уроке.
Этапы жизненного цикла приложения
Перед тем, как подвести итоги нашей работы, оглянемся
немного назад. Итак, от постановки задачи и формулировки требований мы сразу
перешли к проектированию, причем, что весьма важно, не конечного приложения, а
информационной модели, с которой этому приложению предстоит в дальнейшем
работать. Словарь данных, в котором хранится информационная модель, явился
отправной точкой для автоматического создания исполняемого файла нашего
конечного приложения. При этом мы избежали явного участия в этапах кодирования,
отладки и тестирования. За счет эксперт-программ и механизма шаблонов все они
прошли на автомате. Таким образом, после этапа проектирования мы перешли к
макетированию и в результате получили действующий макет нашего приложения. Если
теперь нам потребуется доведение макета до товарного вида, то это можно будет
сделать за счет корректировки в генераторе приложений (Application Generator)
структуры и параметров программы, быть может, даже не прибегая к ручному
кодированию отдельных участков на языке Clarion. Замечательное свойство
технологии Clarion состоит в том, что если расхождения между автоматически
полученным макетом и требуемым приложением достаточно значительны, то, изучив
язык шаблонов и накопив немного опыта, вы сможете самостоятельно готовить для
себя нужные эксперт-программы, настроенные на специфику решаемых вами задач, а
затем просто штамповать готовые приложения.
Итоги
Подведем некоторые итоги нашего первого урока. В нем мы
познакомились с основными принципами технологии Clarion и с ключевыми элементами
соответствующей инструментальной среды. На примере TopSpeed University мы
разобрали сложности формирования информационной модели и организации ее хранения
в словаре данных Clarion. Затем мы воспользовались услугами эксперт-программы
автоматической генерации Clarion-приложений и на основе словаря данных создали
свое, альтернативное приложение для того же примера TopSpeed
University.
На следующем занятии мы уделим внимание основному виду работы в среде Clarion
≈ компонентному программированию приложений, а также разберем особенности работы
с программными шаблонами и более подробно познакомимся с архитектурой системы
Clarion.
На этом же уроке вы узнаете и об отличиях стандартной и
профессиональной редакции Clarion for Windows. В заключение мы рассмотрим с вами
организацию работы приложений в архитектуре клиент/сервер и узнаем о способах
организации взаимодействия Clarion с промышленными
SQL-серверами.
Clarion в архитектуре «клиент-сервер»
На прошлом занятии мы познакомились с примером TopSpeed
University. При этом нам пришлось разобраться с информационной моделью для этой
задачи и на основе словаря данных автоматически построить работающее
Clarion-приложение.
Перед началом второго урока хотелось бы сделать небольшое
замечание. В шестом номере журнала «Компьютер Пресс» за этот год вышла статья
Евгения Галочкина «Clarion и серверы IBM AS/400: новая мелодия для
профессионалов», в которой были довольно подробно изложены технические нюансы
работы в архитектуре «клиент-сервер» с помощью Clarion. Так что во избежание
ненужного дублирования первоначальный план второго урока пришлось заметно
перекроить, перенеся акцент на другие аспекты разработки.
В этом уроке мы более подробно остановимся на принципах быстрой
разработки обычных приложений, тем более, что в соответствии с философией
Clarion они остаются неизменными для последующего масштабирования как для
архитектуры «клиент-сервер», так и для среды
Internet/intranet.
Как создаются приложения с помощью
Clarion
Теперь мы продвинемся немного дальше и постараемся понять, как
же создаются приложения. Как известно, практически в любой программной системе
можно выделить три составляющих: данные (содержание), программный код (логику) и
пользовательский интерфейс (форму). В информационных приложениях данные играют
главенствующую роль. Именно они определяют фундамент множества оперирующих ими
приложений. И все же почти наверняка автоматическое генерирование логики и
внешнего облика приложения на основе этого фундамента вряд ли удовлетворит как
заказчика, так и разработчика. (Если конечно ваша система не будет
разновидностью одного из уже построенных архитектурных решений.)
Значит, нам предстоит немного поработать головой и руками. С
чего же начать? Самое простое — попробовать разобраться в том, что уже сделано
до нас другими. Вернемся к примеру TopSpeed University, но не в нашей неуклюжей
«автоматической» редакции, а в «облагороженной» исходной версии Ричарда Тейлора.
Запустите среду Clarion и загрузите файл SCHOOL.APP. Именно в нем хранится
описание логики и внешнего облика приложения. Выберите теперь закладку с
названием «Template» и взгляните на структуру процедур, отсортированных по
положенным в их основу программным шаблонам («каркасам»). Вы увидите на экране
нечто вроде того, что изображено на рис.1. Процедурные шаблоны Browse,
Form, Frame, Report, Splash и Window определяют те крупные строительные блоки,
которые Тейлор использовал для своего приложения.
Рисунок 1
Шаблон Browse требуется для просмотра списка записей из одной или нескольких
реляционных таблиц, которые отфильтрованы по определенному условию. Шаблон Form
предназначен для работы с полями конкретной записи таблицы в контексте одной из
трех допустимых операций (добавления, модификации и удаления). В принципе этих
двух шаблонов было бы вполне достаточно для создания чисто «навигационных»
приложений, обеспечивающих простейший доступ к
реляционным таблицам. Но Тейлор чуть-чуть усложнил
требования к приложению и потому использовал еще четыре вида шаблона. Шаблон
Frame он использовал для головной процедуры Main с целью формирования рабочей
области, на которой будут располагаться общие элементы управления, а также окна
других процедур (MDI-интерфейс). Шаблон Window — для отображения иерархической
взаимосвязи элементов некоторых таблиц, напоминающей древовидную структуру
каталогов в навигаторе файлов Windows 95. Шаблон Report потребовался для
генерирования различных отчетов (выходных форм) в режиме WISYWIG с последующей
распечаткой на принтере. Ну а шаблон Splash был задействован в качестве
простейшего диалогового окна для отображения текста и графических изображений
логотипа продукта и «визитной карточки» автора. Помимо процедурных бывают и иные
типы шаблонов, но о них чуть позже. А сейчас если вы хотите быстро узнать, какие
еще процедурные шаблоны имеются в стандартной модели Clarion, через меню среды
выполните команду «Procedure —> Change Template Type».
Программные шаблоны
Clarion
Шаблоны подогнаны друг к другу и к общему каркасу всего
приложения таким образом, чтобы дать возможность разработчику использовать их
почти столь же легко, как и детали известного детского конструктора LEGO.
Давайте теперь попробуем разобраться в том, что же на самом деле представляет
собой программный шаблон для среды Clarion.
Шаблон — это параметризованный фрагмент исходного текста,
написанный на специальном языке — языке шаблонов (Template Language). Средства
языка от целевого исходного текста отделены за счет простых синтаксических
соглашений (перед операторами языка ставится префикс #, а перед переменными —
префикс %). Язык шаблонов выполняет следующие функции:
предоставляет средства (#PROMPT, #VALIDATE, #BUTTON, #IMAGE,
#FIELD и др.) для организации внешнего интерфейса с разработчиком
(инженером-конструктором) приложения; результаты заполнения визуальных форм
запоминаются в переменных языка шаблонов;
через встроенные переменные (%FieldName, %RelationKey,
%Target32, %DriverSQL, %LocalData, %ProgramTimeCreated и др.) обеспечивает
своеобразный мост со словарем данных, а также с самой инструментальной средой
Clarion;
на основе заданных и встроенных переменных обеспечивает
управление процессом генерации исходного текста с использованием операторов
ветвления и цикла (#IF, #CASE, #FOR, #LOOP);
обладает богатыми средствами работы с файлами, которые
участвуют в процессе генерации исходных текстов (#INCLUDE, #CREATE, #OPEN,
#READ, #REPLACE, #REDIRECT, #APPEND, #EXPORT, #IMPORT и др.);
управляет генерацией комментария;
имеет большой набор разных типов шаблонов, начиная от
процедурного (#PROCEDURE), кодового (#CODE), диалогового (#CONTROL) и
распределенного (#EXTENSION) и заканчивая утилитами
(#UTILITY);
позволяет создавать эксперт-программы (wizard), формирующие
различные технологические цепочки для синтеза и анализа программной
системы.
Язык шаблонов обладает такой выразительностью, что его вполне
можно использовать в качестве обычного языка программирования (например, при
написании вспомогательных утилит инструментальной среды). Другое дело, что
эффективность его работы может заметно уступать обычным языкам.
Итак, шаблон — это особым образом оформленный полуфабрикат
(каркас) исходного текста на некоем целевом языке программирования(в нашем
случае — на языке Clarion). Одно из самых замечательных свойств языка шаблонов
состоит в том, что он позволяет управлять логикой генерации текстов для любых
языков (C/C++, Java, Object Pascal, Modula-2, Fortran, Prolog, Lisp и др.) и
даже генерацией простых текстовых файлов произвольной структуры (например, HTML,
XML). Чтобы составить хоть какое-то представление о языке шаблонов, взгляните на
простой шаблон (рис.2), используемый для генерации
текстового файла, в котором содержится вся необходимая информация о составе
библиотечных и исполняемых файлов созданного вами приложения
(CW20TEMPLATEBUILDSHP.TPW).
Рисунок 2
#GROUP(%ConstructShipList)
#CREATE(%BuildFile)
#DECLARE(%ShipFile)
#SET(%ShipFile,%Application & '.shp')
#MESSAGE('Generating Module: ' & %ShipFile, 1) #! Post generation message
#MESSAGE('Generating Ship List', 2) #! Post generation message
#MESSAGE('',3)
Clarion for Windows
-------------------
Ship List
The following files must be shipped with your application.
NOTE: This list only includes those files that are VISIBLE
to the Clarion for Windows templates. Any DLLs loaded
in EMBEDs or INCLUDE files may not be visible to the
templates, and may not be in this list.
NOTE: In the case of External Library modules, the .LIB file
will be listed below. Some of these .LIBs (WINDOWS.LIB
for example) do not have DLLs associated with them. In
most cases you will need to ship an associated DLL.
NOTE: In the case of an External Library module generated by
AppGen, you must insure that all files on the shipping
list for that LIB/DLL are also included.
___ Executable Program: %Application.EXE
DLLs associated with the following libraries. (If Any)
#FOR(%Module),WHERE(%ModuleExternal)
___ %Module
#ENDFOR
#IF (~%ApplicationLocalLibrary)
The following CW DLLs
--------------------------
#IF(%Target32)
___ CW2RUN32.DLL - Clarion for Windows Library
#ELSE
___ CW2RUN16.DLL - Clarion for Windows Library
#ENDIF
#FOR(%UsedDriverDLLs)
#FIND(%DriverDLL,%UsedDriverDLLs)
#SET (%ValueConstruct,INSTRING('16',%DriverDLL,1))
#IF(%Target32 AND %ValueConstruct)
___ %(SUB(%DriverDLL,1,%ValueConstruct-1))32%(SUB(%DriverDLL,%ValueConstruct+2))
-%DriverDescription
#ELSE
___ %UsedDriverDLLs - %DriverDescription
#ENDIF
#ENDFOR
#ENDIF
#IF(ITEMS(%VBXList))
___ CWVBX.DLL - Clarion for Windows VBX Support Library
The following VBXs
-----------------------
#FOR(%VBXList)
___ %VBXList
#ENDFOR
#ENDIF
#IF(%OLENeeded)
#IF (~%ApplicationLocalLibrary)
#IF(%Target32)
___ CW2OLE32.DLL - Clarion for Windows OLE Support Library
#ELSE
___ CW2OLE16.DLL - Clarion for Windows OLE Support Library
#ENDIF
#ENDIF
#IF(ITEMS(%OCXList))
These files associated with OLE and OCX controls
-------------------------------------------------
#FOR(%OCXList)
___ %OCXList
#ENDFOR
#ENDIF
NOTE: It is possible that OLE and OCX files might not be in this list. Please
take care to include all files used.
#ENDIF
#EMBED(%ShipList,'Inside the Shipping List')
#CLOSE(%BuildFile)
#REPLACE(%ShipFile,%BuildFile)
Шаблоны задают первый уровень (каркасный) компонентного
программирования в технологии Clarion. Второй уровень (кодовый) определяют
компоненты в традиционном понимании (VBX, OCX, ActiveX-компоненты). При работе с
шаблонами нужно четко представлять себе и то, каковы их недостатки. Первый
состоит в том, что шаблон подразумевает работу внутри вполне определенного,
подчас весьма замысловатого, контекста («крепежных соединений»). Без знания всех
его нюансов вносить какие-либо изменения в шаблон нежелательно. Второй
недостаток состоит в сложности самого текста, написанного на языке шаблонов.
Ведь при необходимости поддерживать вариативность решений он может оказаться
чересчур сложным для человеческого восприятия, а потому и чреват серьезными
ошибками. Наконец, третий недостаток связан с тем, что при генерации исходного
текста на основе шаблона объем кода в силу копирования программных фрагментов
может значительно возрастать. Отсюда вытекает замедление компиляции приложения,
некоторая избыточность объектных файлов и увеличение размеров исполняемого кода.
Один из способов устранения этих недостатков кроется в активном использовании
решений объектно-ориентированного программирования в качестве основы исходного
текста, что позволяет заменить программные копии на ссылки и еще больше
сократить объем генерируемого объектного кода. Фирма TopSpeed заметно
продвинулась в этом направлении, переведя в новой среде Clarion 4 часть своих
базовых шаблонов на рельсы ООП и предоставив разработчику на выбор две
функционально идентичные архитектуры на основе шаблонов — классическую и
объектно-ориентированную.
Как известно, новое — это хорошо забытое старое. И в этом
смысле шаблоны по своей сути очень близки развитым средствам макропроцессоров,
весьма популярным еще в 70-х годах. Но в отличие от тех средств шаблоны Clarion
не просто параметризуют текст, а имеют средства организации пользовательского
интерфейса для инженера-конструктора, четкую структуризацию элементов
специального языка шаблонов и программный интерфейс (встроенные и заданные
переменные) с контекстом макрообработки.
Язык программирования
Clarion
Если шаблоны столь всемогущи, то возникает вполне законный
вопрос: зачем понадобилось изобретать специальный язык программирования, когда
все можно сделать на том же C++ ? Дело в том, что при подобном акценте на
программные шаблоны универсальный язык программирования, не обладающий
специальными высокоуровневыми языковыми средствами, ничем не лучше обычного
ассемблера (тем более, что фирма TopSpeed откровенно подчеркивает свою
ориентацию именно на платформу Wintel). Вот почему язык Clarion в дополнение к
традиционным средствам обычных языков добавляет некие новые возможности,
обеспечивает компактность представления и надежность статического контроля
ошибок еще на этапе компиляции. Наиболее важными среди них являются средства
обработки событий, ненаследуемые классы (WINDOW, FILE, VIEW, QUEUE, REPORT и
др.), которые как бы являются дальнейшим уточнением процедурных шаблонов, а
также средства для процедурной работы с файлами баз данных, являющиеся
надстройкой над ODBC/SQL-уровнем коммерческих СУБД. Еще один немаловажный момент
состоит в том, что какими бы изощренными не были сделаны шаблоны, в любой момент
может появиться потребность слегка их подправить. Вот почему в шаблонах Clarion
активно используются для этой цели программные вставки (embeds). Так что чем
компактнее и понятнее запись кода, тем проще будет сопровождать весь
проект.
Давайте вновь вернемся к нашей задаче TopSpeed University и
посмотрим, как выглядит ее решение с изнанки. С помощью курсора выберем
какую-нибудь процедуру, скажем, StudentTree (в самом низу списка,
рис.1) и выполним для
нее команду среды «Edit —> Source». Произойдет загрузка исходного текста
процедуры StudentTree. Найдем теперь в нем подпрограмму REL1::Load:Students
(ключевое слово ROUTINE) и внимательно посмотрим на ее текст (рис.3). В этом
небольшом фрагменте, отвечающем за подготовку информации о студентах для
отображения ее в древовидном представлении, затронуты многие средства языка
Clarion. Надеюсь, комментарии позволят вам разобраться в специфике программной
реализации. Внешний вид (лицевая сторона) результатов этой реализации
представлена на рис.4.
Рисунок 3
queue:reltree queue,pre() ! список для навигации по записям
REL1::Display STRING(200)
REL1::NormalFG LONG
REL1::NormalBG LONG
REL1::SelectedFG LONG
REL1::SelectedBG LONG
REL1::Icon SHORT
REL1::Level LONG
REL1::Loaded SHORT
REL1::Position STRING(512)
end
rel1::loadedqueue queue,pre() ! список состояния уровней дерева
REL1::LoadedLevel LONG
REL1::LoadedPosition STRING(512)
end
rel1::load:students routine ! подпрограмма загрузки в дерево таблицы students
REL1::Display = 'Students and Enrollment'
REL1::Loaded = 0 ! инициализируем все поля текущей записи
REL1::Position = '' ! служебного списка Queue:RelTree
REL1::Level = 0
REL1::Icon = 0
REL1::NormalFG = -1
REL1::NormalBG = -1
REL1::SelectedFG = -1
REL1::SelectedBG = -1
ADD(Queue:RelTree) ! добавляем текущую запись в список
SET(Students) ! позиционируемся на начало таблицы Students
LOOP
NEXT(Students) ! извлекаем очередную запись
IF ERRORCODE() ! если ошибка, то выясняем, какая
IF ERRORCODE() = BadRecErr ! достигли конца таблицы
BREAK ! выходим из цикла LOOP
ELSE
StandardWarning(Warn:RecordFetchError,'Students')
POST(Event:CloseWindow) ! посылаем сообщение о закрытии окна
EXIT ! выходим из подпрограммы
END
END
REL1::Loaded = 0 ! пока не загрузили
REL1::Position = POSITION(Students) ! запоминаем текущую позицию
REL1::Level = 1 ! уровень в дереве равен 1
REL1::LoadedLevel = ABS(REL1::Level)
REL1::LoadedPosition = REL1::Position
GET(REL1::LoadedQueue,REL1::LoadedLevel,REL1::LoadedPosition)
! извлекаем запись из списка REL1::LoadedQueue
IF ERRORCODE() AND REL1::LoadAll = False
ENR:StudentNumber = STU:Number ! формируем значения ключевых полей
CLEAR(ENR:ClassNumber,0) ! для последующего позиционирования
SET(ENR:StuSeq,ENR:StuSeq) ! позиционируемся в таблице Enrollment
! по значению ключевых полей ENR:StudentNumber и ENR:ClassNumber
! с последующим доступом по ключу ENR:StuSeq
LOOP
NEXT(Enrollment) ! извлекаем очередную запись
IF ERRORCODE() ! если ошибка, то выясняем, какая
IF ERRORCODE() = BadRecErr ! достигли конца таблицы
BREAK ! выходим из цикла LOOP
ELSE
StandardWarning(Warn:RecordFetchError,'Enrollment')
POST(Event:CloseWindow) ! посылаем сообщение о закрытии окна
EXIT ! выходим из подпрограммы
END
END
IF UPPER(ENR:StudentNumber)
UPPER(STU:Number) THEN BREAK.
! выходим: все, что нужно по данному студенту, уже извлекли
REL1::Level = -1 ! сбрасываем уровень
BREAK ! выходим из цикла LOOP
END ! конец малого цикла по таблице успеваемости Enrollment
DO REL1::Format:Students ! вызываем подпрограмму
ADD(Queue:RelTree,POINTER(Queue:RelTree)+1) ! добавляем текущую
! запись в список Queue:RelTree
IF REL1::LoadAll
ADD(REL1::LoadedQueue,REL1::LoadedLevel,REL1::LoadedPosition)
END
REL1::Level = 1
REL1::Loaded = True
! вызываем подпрограмму форматирования записи
DO REL1::Format:Students
ADD(Queue:RelTree,POINTER(Queue:RelTree)+1) ! добавляем запись
! вызываем подпрограмму загрузки успеваемости
DO REL1::Load:Enrollment
END
END ! конец большого цикла по записям таблицы Students
Рисунок 4
Теперь несколько слов об организации пользовательского
интерфейса. Для современных информационных систем характерно не только
разнообразие визуальных форм (как экранных, так и выходных), но и просто их
количество. Эта рутинная и монотонная задача в значительной степени поддается
автоматизации. И инструментальная система Clarion неплохо с ней справляется
(кстати, гордостью фирмы является TopSpeed-реализация элементов управления
Windows 95 для среды Windows 3.x, что позволяет устранить даже визуальное
различие между 16-разрядными и 32-разрядными приложениями). Как известно, на
вкус и цвет товарища нет, но без знания элементарных принципов дизайна качество
внешнего облика вашего приложения может оказаться весьма посредственным. Для
любознательных читателей могу порекомендовать в этой связи книгу Марка Минаси
«Графический интерфейс пользователя. Секреты проектирования», вышедшей в прошлом
году в издательстве «Мир».
Интерактивное управление визуальными языковыми структурами
WINDOW (ранее она называлась SCREEN) и REPORT, позволяющее обеспечивать работу
на основе взаимно однозначного соответствия между внешним видом и исходным
текстом, была одной из основных причин большой популярности среды Clarion еще в
середине 80-х годов. Нынешняя среда Clarion эти достоинства приумножила, и
теперь за счет механизма шаблонов формирование экранных и выходных форм вышло на
уровень «штамповочной» технологии. Давайте посмотрим, как выглядит работа по
форматированию окон (Window Formatter) на примере все той же процедуры
StudentTree. Есть два способа перехода в этот режим работы: один — через кнопку
Window в окне свойств данной процедуры (то есть со стороны модели приложения), а
второй — через экспресс-клавишу Ctrl/F при нахождении текстового курсора на
описании данного окна в исходном тексте (то есть со стороны языка). В результате
мы можем увидеть на нашем экране нечто вроде того, что изображено на
рис.5.
Рисунок 5
Работа с файлами БД
Работа с реляционными
таблицами, хранящимися в файлах БД, является одним из самых
сильных мест системы Clarion. Как мы уже узнали на нашем первом уроке, схема БД
(структура и взаимосвязь таблиц) хранится в специальном словаре данных. Вполне
возможно, что построенная информационная модель далека от оптимальной, обладает
неприятными коллизиями или даже является противоречивой. На третьем уроке мы
узнаем, какие средства предоставляет Clarion для статического анализа
информационной модели. А сейчас будем исходить из оптимальности разработанной
схемы БД и познакомимся с теми уровнями абстракции, которые необходимы для
полноценной работы с технологиями баз данных.
Итак, словарь данных определяет первый уровень абстракции.
Вторым уровнем является язык шаблонов (и прежде всего встроенные переменные,
обеспечивающие интерфейс со словарем). На этом уровне в соответствии со словарем
формируется логика связей с учетом отношений, ограничений ссылочной целостности,
диапазонов представления значений и т.п. (все то, что ныне называется модным
термином «бизнес-правила»).
Третий уровень абстракции, на который производится отображение
первых двух, — это язык определения данных, являющийся неотъемлемой частью
языка Clarion. Помимо реляционных таблиц (FILE) на нем описываются и
вспомогательные структуры QUEUE (список записей, хранящийся в оперативной
памяти) и VIEW (виртуальная таблица). Взгляните, как на языке определения данных
выглядит описание таблицы Enrollment из нашего примера TopSpeed University
(рис.6).
Рисунок 6
Enrollment FILE,DRIVER('TOPSPEED'),PRE(ENR),CREATE,BINDABLE,THREAD
StuSeq KEY(ENR:StudentNumber,ENR:ClassNumber),NOCASE,OPT
SeqStu KEY(ENR:ClassNumber,ENR:StudentNumber),NOCASE,OPT
Record RECORD,PRE()
StudentNumber LONG
ClassNumber LONG
MidtermExam SHORT
FinalExam SHORT
TermPaper SHORT
END
END
Четвертый уровень абстракции — это язык манипулирования
данными, также неразрывно связанный с языком Clarion. Для него характерны
операторы файлового доступа (OPEN, CREATE, PACK, STREAM, FLUSH, REMOVE, RENAME),
операторы модификации данных (ADD, APPEND, DELETE, PUT), операторы блокировки
доступа (LOCK, UNLOCK, HOLD, RELEASE), операторы позиционирования (SET, NEXT,
PREVIOUS, SKIP, GET), операторы поддержки транзакций (COMMIT, LOGOUT, ROLLBACK),
а также вспомогательные операторы (POSITION, POINTER, RECORDS, EOF, SEND).
Работу с языком манипулирования данными вы уже могли видеть на
рис.3.
Пятый уровень абстракции — это уровень внутренней унификации
работы с таблицами разных СУБД (механизм замещаемых драйверов БД). О нем стоит
поговорить чуть подробнее, тем более, что именно здесь проходит водораздел между
стандартной и профессиональной редакцией среды Clarion (в поставке стандартной
версии обеспечивается работа только с драйверами форматов CLARION и TOPSPEED).
Форма физического представления реляционных таблиц (и специфика работы с ними)
должна оказывать минимальное воздействие на разработку информационных
приложений. Вот почему разработчики Clarion реализовали этот механизм еще в
версии Clarion Database Developer 3.0 (для DOS), созданной около 5 лет назад.
Суть его состоит в том, что вся работа ведется через абстрактное понятие таблицы
(файла). Конкретизация же физического представления осуществляется в атрибуте
DRIVER структуры FILE (см.рис.6). Для перехода на работу с
другим представлением часто достаточно просто сменить символьную строку в
атрибуте DRIVER, отвечающую за подключение соответствующей
DLL-библиотеки.
Понятно, что простого переключения может оказаться недостаточно,
поэтому специфика работы с различным физическим представлением таблиц в
технологии Clarion осуществляется за счет поддержания многообразия типов данных
(в системе типов языка Clarion представлены практически все возможные типы,
которые могут встретиться в таблицах других СУБД), и за счет оптимизации доступа
(настройки параметров конкретного драйвера). При переносе Clarion в среду
Windows к драйверам Btrieve, FoxPro, Clipper, dBase3, dBase4, DOS, ASCII и BASIC
добавились драйвер ODBC и прямые SQL-драйвера для промышленных СУБД.
Тут мы непосредственно подходим к шестому уровню абстракции. Это
уровень внешней унификации работы с таблицами разных СУБД, который опирается на
ставшую стандартом де-факто для платформы Wintel спецификацию ODBC (Open
DataBase Connectivity). Работа в рамках ODBC строится по трехзвенной цепочке:
первичный (front-end) ODBC-драйвер со стороны языка Clarion, стандартный
менеджер ODBC (как связующий элемент) и вторичный (back-end) ODBC-драйвер,
обеспечивающий доступ к источнику данных в формате конкретной СУБД. Кстати
говоря, в дополнение к первичному ODBC-драйверу фирма TopSpeed недавно выпустила
и вторичный для своего основного рабочего формата TOPSPEED. Понятно, что такое
количество промежуточных слоев, да еще реализованных разными фирмами может
сказаться на функциональности интерфейса (типы данных, возврат результатов
запросов, нюансы совместимости) и, что особенно важно, на производительности.
Что касается последних сомнений, то быстродействие нынешнего поколения многих
ODBC-средств таково, что для той же системы Clarion падение производительности
по сравнению с прямыми SQL-драйверами составляет всего лишь около
15-20%.
Таким образом, мы вплотную подошли к седьмому уровню абстракции
работы с базами данных в технологии Clarion, а именно, к уровню SQL-драйверов.
Именно он и позволяет обеспечить достаточно полноценную работу в архитектуре
клиент/сервер, вне зависимости от того, какой моделью доступа к удаленным данным
вы пользуетесь (RDA, DBS или AS). В случае RDA-модели (Remote Data Access)
логика обработки практически целиком исполняется на клиентской части. И именно
эта модель достаточно легко может быть реализована при интеграции
Clarion-приложения (как клиентской части) с сервером баз данных. Однако этому
уровню в наибольшей степени подходит использование ODBC, а не SQL. В случае
DBS-модели (DataBase Server) большая часть логики обработки перекочевывает с
клиента на сервер. Здесь уже требуется активно задействовать механизмы хранимых
процедур и триггеров БД. Для этого случая больше подходит использование прямых
SQL-драйверов. Здесь уже можно задействовать специфику того или иного
SQL-сервера (SQL-хинты, script-файлы и т.п.). Эффективность взаимодействия с
SQL-сервером из Clarion-приложения можно повысить за счет использования
механизма свойств (property), встроенного в язык Clarion для доступа к методам
ненаследуемых классов. В случае же AS-модели (Application Server) между клиентом
и сервером данных появляется третье, промежуточное звено, задача которого
разгрузить сервер данных, почти полностью убрав с него логику. Реализация
AS-модели взаимодействия с помощью Clarion также возможна, но является наименее
проработанной. Как известно, центральную роль в этой модели играют мониторы
обработки транзакций, а штатных решений стыковки с ними ни на уровне шаблонов,
ни на уровне API-интерфейсов система Clarion пока не предоставляет.
Необходимость учета специфики работы с SQL-серверами позволяет в
полную силу задействовать возможности механизма шаблонов. Ведь именно
вариативное программирование, которое в Clarion может быть реализовано на более
высоком уровне абстракции, нежели простая и привычная условная компиляция,
позволяет эффективно решить задачу объединения общего с частным. Чисто
технологически это открывает и путь для более четкого разделения труда в
командах разработчиков: теперь результаты работы специалистов по организации
интерфейса с SQL-серверами могут быть представлены в формальном виде, пригодном
для непосредственного использования разработчиками другой специализации.
SQL-шаблоны Энди Степлтона в этом смысле — хороший опыт, который стоит взять на
вооружение.
Что касается самих прямых SQL-драйверов для Clarion, то на
сегодняшний момент имеются драйвера для Oracle (с поддержкой PL/SQL), IBM
DB2/400 и Informix. Практически завершены работы по Microsoft SQL Server; в
стадии тестирования находится Sybase Server (в котором сейчас производится
замена API-интерфейса).
Итоги
Подведем итоги второго урока. Мы познакомились со спецификой
программных шаблонов Clarion — основных строительных блоков, обеспечивающих
фундамент как вариативного, так и компонентного программирования. Продолжив
разбор примера TopSpeed University, мы изучили некоторые особенности языка
программирования Clarion. Наконец, вкратце разобрали семиуровневую архитектуру
работы с файлами БД в системе Clarion.
На следующем занятии мы изучим второй уровень компонентного
программирования в рамках VBX/OCX/ActiveX, выясним особенности Enterprise
Edition(версии Clarion для корпоративной коллективной разработки), познакомимся
со средствами Internet/intranet-программирования,предоставляемыми системой
Clarion, а также узнаем новости о готовящейся версии Clarion, получившей
название «Clarion 4».
Clarion в среде Internet/Intranet
На прошедших двух уроках мы вкратце познакомились с некоторыми
особенностями работы в рамках технологии Clarion. Заключительное занятие в этом
смысле будет несколько необычным. Во-первых, помимо основной темы, вынесенной в
его заголовок, мы затронем и такой важный аспект разработки, как компонентное
программирование. Во-вторых, более подробно разберем архитектуру системы Clarion
с учетом коллективной работы над единым проектом. В-третьих, на основе
бета-версии Clarion 4 выясним, что нового предлагает нам очередное поколение
инструментальной системы Clarion. Наконец, напоследок, в качестве небольшой
шпаргалки я приведу важную навигационную информацию,
которая может помочь
разработчику сориентироваться в различных информационных источниках, так или
иначе связанных с Clarion.
Виртуальные
машины
Бурное развитие Internet и активное паразитирование
intranet-сетей на широко распространенной программной начинке Internet (TCP/IP,
HTTP и др.) привело к большой востребованности соответствующих сетевых
приложений. В то же время разработка их сопряжена с серьезными проблемами: это и
крайне примитивные сетевые протоколы, и требование
вписаться в прокрустово
ложе браузеров, и немалые трудности с созданием надежной и гибкой серверной
части. Так или иначе, сегодня в этой области предлагается множество разных
подходов (Lotus Domino, IBM Net.Data, Microsoft ASP, динамический HTML в
трактовке Netscape и Microsoft и др.). Подавляющее большинство решаемых в
Internet/intranet задач носит подчеркнуто информационный характер с акцентом на
удаленные базы данных. Вот почему не остались здесь в стороне и такие гиганты
индустрии БД, как Oracle и Informix.
На их фоне фирма TopSpeed выглядит довольно
скромно и по своим размерам, и по возможностям. Тем не менее, взвесив все
за и против, она решилась тоже поучаствовать в этом
тотализаторе. Перевод
технологии Clarion на рельсы Internet оказался достаточно остроумным, так что
познакомившись с Clarion Internet Connect (CWIC) и с Clarion Application Broker,
вы поймете, что фирма TopSpeed нашла свою тропку в нехоженых зарослях
Internet.
Итак, в основу подхода TopSpeed положен,
если так можно выразиться, принцип виртуального операционного контекста (ВОК).
Другими словами, за счет специально предпринимаемых со стороны TopSpeed мер
нивелируются (демпфируются) как внутренние (программные), так и внешние
(интерфейсные и функциональные) различия, которые почти неизбежны при быстром
переносе прикладной системы в совершенно иную операционную среду.
Что такое ВОК и чем он примечателен? Наши предки говаривали:
Хочешь посмотреть в будущее ≈ загляни в прошлое. Давайте последуем их мудрому
совету и ненадолго приоткроем страницы истории. С появлением богато
разрекламированной технологии Java многие программисты вновь открыли для себя
механизм виртуальных машин (ВМ) ≈ старый, забытый
дедовский метод обеспечения
независимости ПО от разных компьютерных платформ. Паскаль, LISP, PROLOG,
Smalltalk, да и другие языки, будучи перенесенными на платформу ВМ, получили
тогда новую степень свободы (пусть и за счет заметного падения
производительности). Главная проблема, с которой несмотря на JIT-компиляцию не
особенно-то успешно борется нынешняя Java (на порядок уступая в быстродействии
коммерческим компиляторам C++) состоит в том, что на новой платформе
отрабатываются (интерпретируются) даже не операторы языка, а низкоуровневые
инструкции абстрактного процессора. Реализовав втеперь уже далеком 1986 г. свою
первую инструментальную систему Clarion [4,5], фирма TopSpeed (тогда
называвшаяся Clarion Software), сполна отведала все
прелести платформы ВМ.
Дело в том, что язык Clarion был реализован в виде не реального компилятора, а
как раз таки виртуальной машины, настроенной на работу в среде DOS.
До поры до времени мириться с неудобством
отладчика и заторможенностью ВМ еще как-то было можно, но зачем? Ведь
потребителя абсолютно не интересует изнанка прикладной системы. И пусть там нет
ни лишних узелков, ни складочек, оценить по достоинству он это не сможет. Долгое
время (почти пять лет) после выпуска первой версии Clarion разработчиков системы
еще как-то сдерживало желание обеспечить мифическую переносимость. Но потом они
махнули на нее рукой и, закупив лицензию у JPI, получили в свои руки нормальный
компилятор языка Clarion с кодогенерацией для процессоров Intel x86. Однако
печальный опыт использования ВМ не прошел даром ≈ даже заполучив настоящий
компилятор Clarion, разработчики инструментальной системы не стали намертво
привязывать ее к DOS и PC. Абстрактным слоем стала реализованная в виде
библиотек ядра исполняющая система языка Clarion (она служит верой и правдой и
по сей день), а также представленные в виде служебных БД словарь данных (.DCT) и
логическая модель приложения (.APP). Так что абстрактную оболочку вокруг себя
создал сам язык Clarion, который включил в свои конструкции немало элементов,
отсутствующих у всех универсальных языков (так называемых языков третьего
поколения, или 3GL).
Помимо введенного 7 лет назад механизма
подключаемых драйверов БД, выгодно отличающего Clarion от других
инструментальных систем, в ходе эволюции технологии принцип абстрактного
контекста ВОК заметно выручал разработчиков Clarion, как минимум, еще три
раза. Сначала им воспользовались при введении в DOS-реализацию графического
интерфейса. GUI Kit за счет специальной точки входа обеспечивал переключение с
текстовой среды на графическую. Причем это было сделано по сути без изменения
программного кода приложения. Второй раз ≈ при желании обеспечить полнокровную
поддержку возможностей среды при создании как 16-разрядных, так и 32-разрядных
приложений для Windows. Проблема совместимости здесь в том, что Windows 95 (и
Windows NT) обладает рядом элементов пользовательского интерфейса, которых
попросту нет в Windows 3.x. Разработчики Clarion за счет все того же принципа
ВОК успешно и без особого напряжения справились и с этой задачей. Так что
приложение, подготовленное для работы в Windows 95, может быть мгновенно
перенастроено для Windows 3.x. Ныне при переходе на рельсы Internet мы наблюдаем
третий случай использования ВОК в Clarion.
Подход TopSpeed к
Internet-реализации Clarion
Решение для Internet состоит в простейшей идее перенаправить
экранный ввод/вывод. Если исходить из того, что один из основных строительных
блоков Clarion ≈ тип WINDOW (также как FILE, VIEW и др.) ≈ после компиляции уже
хранится в памяти в виде компактной статической структуры данных, то несложно
догадаться, что по сути требуется решить задачу, во многом схожую с реализацией
механизма подключаемых драйверов БД. Напомню, что она сводится к тому, чтобы на
основе известной структуры реляционной таблицы (FILE) и на основе встроенных в
язык Clarion операций манипулирования данными добиться либо настройки на
инородное физическое представление, либо динамического преобразования операций в
команды целевой СУБД (в случае ODBC или же удаленного SQL-сервера). При этом
драйвер скрывает в себе не только нюансы преобразования, но и специальный
коммуникационный протокол. Однако если в случае подключаемых драйверов Clarion с
точки зрения разработчика выступал в роли клиента, то в случае с Internet все
наоборот ≈ теперь Clarion выступает в роли сервера.
Итак, ваше приложение как бы разрезается на
две части ≈ серверная работает под управлением специального исполняющего ядра
(Application Broker) в среде Windows 95 или Windows NT, а клиентская (CWIC,
Clarion Internet Connect, пользовательский интерфейс) работает под управлением
специально разработанной библиотеки Java-классов, выполняемой в среде любого
браузера, поддерживающего HTTP-протокол и обладающего виртуальной машиной языка
Java (напр., Netscape Navigator, Microsoft Internet Explorer, HotJava и др.).
Низкоуровневые графические и коммуникационные операции возложены на Java-слой, а
более высокоуровневые ≈ выполненные в виде шаблонов программные компоненты ≈
перепрограммированы на языке шаблонов. Таким образом, следует всего лишь
подменить исполняющую систему (CW2RUN32.DLL), и добавить/заменить несколько
шаблонов: головные (WIZARD.TPL, ICONNECT.TPL) и рабочие (WINDOW.TPW, WAPP.TPW,
RELTREE.TPW, STANDARD.TPW, STDFUNC.TPW, CTLBROW.TPW, ICGROUP.TPW). Шаблоны эти
опираются на представленную в виде исходных текстов небольшую вспомогательную
библиотеку поддержки Internet, реализованную на языке Clarion. Выбор языка Java
в качестве основы поддержки клиентской части обусловлен желанием обеспечить
исполнение распределенных Clarion-приложений на браузерах разных компьютерных
платформ (т.е. свести задачу к уже решенной другими).
Если вы не планируете проводить хитроумных экспериментов по
самостоятельному изменению тех штатных шаблонов Clarion, которые отвечают за
экранный ввод/вывод, то безболезненная перенастройка на Internet вам практически
гарантируется. Полученный в результате этого исполняемый модуль вместе с
необходимыми DLL-библиотеками размещается на HTTP-сервере и активизируется через
обычный URL-запрос, встроенный в вашу HTML-страницу или же набранный вручную в
браузере. Для отладки и тестирования клиентской и серверной части в рамках
одного локального компьютера разработчика предусмотрен специальный тестовый
полигон ≈ ⌠игрушечный■ HTTP-сервер, моделирующий работу в реальной сети.
Internet-решение поддерживает не только стандартный оконный интерфейс Clarion,
но также вывод печатных форм (REPORT), обеспечение шифрованных SSL-транзакций
(через ISAPI), работу специфичного для Internet cookie-механизма.
Один из относительных недостатков подхода
TopSpeed состоит в том, что все вспомогательные Java-классы клиенту нужно
все-таки явным образом подкачать по сети и распаковать. Более серьезные
недостатки связаны со всеми теми прелестями, которыми в визуальном плане
отличается поддержка Java в нынешних браузерах, а также с использованием
довольно медленного HTTP-протокола (который даже для специальных задач почему-то
упорно эксплуатирует большинство фирм, предлагающих решения в среде
Internet/intranet). Простота подхода TopSpeed стимулировала третьи фирмы на
разработку схожих решений, но с другими вариантами Application Broker. Не
удивлюсь, если фирме TopSpeed в ближайшем будущем захочется попользовать
ActiveX-компоненты на стороне клиента. Правда, в этом случае переносимость и
безопасность Java-слоя окажется иллюзорной.
Компонентное
программирование
Раз уж речь зашла об ActiveX [11], давайте
немного времени посвятим компонентному программированию в рамках технологии
Clarion. Тем более, что это непосредственно входит в программу нашего урока. На
сегодняшний день существует немало разных компонентных архитектур, отвечающих за
согласованное взаимодействие разнородных программных объектов, реализованных на
разных языках (CORBA, IBM SOM, JavaBeans и др.). Но доминирующую роль на
платформе Wintel (а Clarion, как мы помним, делает ставку именно на нее) играет
все же Microsoft COM (Component Object Model). Опирающийся на нее OCX
поддерживается в Clarion достаточно давно. Не буду вдаваться в технические
детали этой поддержки (в документации об этом сказано довольно подробно).
Остановлюсь лишь на двух моментах. Во-первых, использование этого механизма
гораздо важнее, чем просто адаптация своей системы к оформленным в виде VBX, OCX
и ActiveX сторонним компонентам. ActiveX ≈ достаточно удобный способ унификации
разнородных строительных блоков. Проблема лишь в том, что оформление
Clarion-компонент в виде ActiveX до недавнего времени было довольно трудоемким
делом. С появлением специального инструментария под названием JazzAge ActiveX
Factory ситуация может измениться кардинально (кстати, этот продукт поддерживает
как COM, так и DCOM, да к тому же обладает 16/32-реализациями не только для
Clarion, но и для Delphi, VisualBasic, Visual C++, PowerBuilder и др.). Второй
важный момент ≈ компонентное программирование в Clarion может осуществляться на
двух уровнях ≈ каркасном (шаблоны) и кодовом (COM-компоненты). И в этом смысле у
него довольно интересные перспективы.
Clarion и дисциплина
производства
При переходе от одиночного (кустарного) производства ПО к
промышленному встает одна из серьезных проблем ≈ коллективной согласованной
работы нескольких специалистов над единым проектом. На прошлых занятиях мы
познакомились с начальными редакциями Clarion (Standard и Professional
Editions). Теперь поговорим об Enterprise Edition. Важной ее особенностью наряду
с Data Modeller, графическим анализатором схемы БД (словаря данных), и с
TopSpeed Deployment Kit, инструментом для подготовки дистрибутива ваших
приложений, в этой редакции имеется Team Developer, обеспечивающий согласованную
работу с единым словарем данных и с логической моделью приложения (на уровне
блокировки и синхронизации доступа). В основе своей он опирается на известную
систему поддержки коллективной работы PVCS (со всеми ее плюсами и минусами).
Однако Clarion в организации работы не ограничивается аморфными рамками контроля
версий, а определяет неплохо продуманную дисциплину производства.
Я постарался немного облегчить читателю
задачу и пояснить эту дисциплину с помощью набора разных таблиц и диаграмм.
Пространство статьи ограничено, поэтому я прибегну к изложению идей в виде все
тех же реляционных таблиц и закодированных диаграмм. Сначала взгляните на
архитектуру системы Clarion (рис.1). По ней можно проследить трассу движения
служебных файлов (табл.5), а также состав, назначение и взаимосвязь разных
инструментальных компонент системы Clarion (табл.1,2,3,4). Все инструментальные
компоненты условно делятся на четыре группы:
1. Standard Edition
2. Professional
Edition
3. Enterprise Edition
4. Additional
Tools
Соответствие группе неявно обозначается
количеством букв в аббревиатуре. Третья группа включает в себя полностью вторую,
а та, в свою очередь, всю первую. Иными словами, Dictionary Editor (D) относится
к первой группе, а Clarion Data Modeller (CDM) ≈ к третьей.
Теперь давайте посмотрим на этапы
жизненного цикла программного продукта в рамках Clarion (рис.2a, 2b). Я здесь
намеренно отобразил не только основную магистраль разработки, отвечающую за
формирование прикладного слоя, но и не менее важную для коллективной работы
сопутствующую магистраль, связанную с формированием и поддержанием в боевой
готовности собственных инструментов. Естественно, что промышленное производство
подразумевает какое-то разделение труда. В табл.6 приведен один из возможных
вариантов деления по специализации. Понятно, что в небольших коллективах один и
тот же человек может совмещать несколько разных специальностей, что непросто. Но
ведь при кустарном производстве все эти задачи в той или иной мере возлагались
на одного человека! Более подробно с организацией промышленной разработки в
рамках Clarion вы можете познакомиться в статьях [3,6].
Новации Clarion
4
Теперь, как и обещал, несколько слов о новой версии Clarion for
Windows, которая получила название Clarion 4 и на момент написания статьи
существовала в виде бета-версии. Фирма TopSpeed намеренно задержала выход
очередного релиза CW 2.1, в котором был подготовлен ряд новаций. С выходом
Clarion 4 фирма меняет свой довольно замысловатый принцип нумерации версий (CW
2.003) и как бы подводит черту под новым продуктом своего семейства. Ранее
этапами большого пути в среде Windows были CW 1.0, CW 1.5, CW 2.0. Несмотря на
небольшое расхождение в нумерации, по сути это были разные (хоть и совместимые)
реализации технологии Clarion. Теперь TopSpeed отказалась от словосочетания
for Windows. Это связано не с появлением адекватной поддержки DOS (что потребовало
бы вряд ли обоснованных и немалых вложений). На мой взгляд, причина в расширении
за счет Internet/intranet того семейства клиентских платформ, на которых
способен работать Clarion.
Итак, первое важное отличие Clarion 4 от
своего предшественника CW 2.0 ≈ поддержка Internet/intranet. В ходе решения этой
задачи попутно была реализована и такая мелочь, как возможность задания
графической подложки окна (wallpaper), добавлена поддержка прозрачных и
анимационных GIF-картинок, в том числе и на кнопках, задействован настраиваемый
механизм непосредственного редактирования в browse-структурах (edit-in-place).
Ряд важных усовершенствований внесен в поддержку OCX и 32-разрядного механизма
ODBC, появился новый редактор программных вставок
(Embed Editor).
Второе серьезное отличие Clarion 4 (фирма
ставит его на первое место) ≈ перевод шаблонов на рельсы
объектно-ориентированного программирования (ООП) [10]. Теперь у разработчика
появляются на выбор два совместимых каркаса шаблонов ≈ классический (на основе
процедурного программирования) и объектный (на основе ООП). При этом TopSpeed
обещает обеспечивать подобную дуальность достаточно продолжительное
время.
В чем же выгода нового объектного каркаса
шаблонов? Во-первых, почти в два раза сокращается объем генерируемого кода на
языке Clarion. Во-вторых, возрастает наглядность программного кода в самих
шаблонах, а для метапрограммиста ≈ программирующего шаблоны ≈ это очень важно
(здесь цена ошибки весьма высока). В третьих, появляется гибкость: в шаблонах
наряду с обычным кодом на языке Clarion начинают интенсивно использоваться
обращения к вспомогательным библиотекам процедур и методов. Правда, в этом
смысле фирма TopSpeed вряд ли открыла что-то новое для разработчиков ≈ в отличие
от нее многие пользовались этим приемом давно, в том числе и для
интеллектуальной защиты собственных шаблонов (ведь их использование допустимо
только в исходном виде, и без насильственной привязки к сторонней библиотеке они
беззащитны). Серьезность намерений TopSpeed в отношении особой роли ООП отражает
факт значительной задержки ожидавшегося появления ООП-каркаса в рамках CW 2.1.
Как теперь выясняется, это было связано с разработкой специальной ООП-среды, на
которую опираются объектные шаблоны и которой дано имя ABC (Application Builder
Classes).
Теперь в ООП-шаблонах Clarion объединились плюсы (и минусы)
двух разных подходов к комбинированию программных решений. Удивляет лишь то, что
фирма TopSpeed пока активно не использует в шаблонах различные
ActiveX-компоненты. В своей лекции при получении престижной премии Тьюринга в
1977 г. Джон Бэкус, автор небезызвестного Фортрана и формализма описания
синтаксиса языков (БНФ, формализм Бэкуса-Наура), сказал:
Возможно, самым важным
аспектом обеспечения мощи изменяемой части языка является доступность
комбинационных форм, которые могут служить для построения новых процедур из
старых. А в этом смысле шаблоны ≈ весьма удачный каркас для комбинирования
различных программных решений и компонент.
Заключение
Итак, уважаемый читатель, вот и закончился наш небольшой курс.
К сожалению, он был чересчур сжатым. Нельзя объять необъятное: многое осталось
за бортом, в частности, мы упустили такие важные вопросы, как мультиязыковое и
мультипотоковое программирование. И все же я надеюсь, этот курс помог Вам лучше
узнать технологию Clarion и открыть для себя что-то новое и познавательное.
При этом, правда, автор упустил главное ≈
он так и не ответил на вопрос, в чем же все-таки состоит загадка
притягательности Clarion. Ведь если придирчиво взглянуть на эту технологию, то
несложно заметить, что у ее воплощения немало недостатков. Это и довольно
замысловатый язык шаблонов, и несколько перегруженный язык Clarion, во многом
павший жертвой изначального подражания Коболу и весьма неудачным языковым
решениям C и C++.
Чем же так притягивает к себе Clarion?
Разные люди ответят на этот вопрос по-разному. И дело здесь не столько в спектре
решаемых ими задач, характере работы, времени применения технологии. Выбор
базового инструмента во многом опирается на субъективную оценку самого
разработчика (или руководителя коллектива), которая складывается из простого
случая и подчас необъяснимых подсознательных (интуитивных) симпатий.
Свой ответ я бы сформулировал так: Clarion
(по крайней мере, пока) в силу своей наглядности, практичности и кажущейся
простоты почти идеально подходит и для преподавания в вузах, и для реальных
серьезных проектов, и для исследовательских работ по новым программным
инструментам и технологиям. Более того, сделав ставку на платформу шаблонов,
разработчики Clarion не прогадали. Как показала практика, дополнительная степень
свободы (макетирование на основе шаблонов) ≈ своеобразная палочка-выручалочка.
Именно она позволяет разработчику быть уверенным в том, что при определенных
усилиях он вполне сможет с ее помощью обеспечить столь важную сегодня
технологическую безопасность своего инструментария.
К великому сожалению, несмотря на
декларируемую открытость многих инструментальных систем в действительности они
превращают разработчиков в заложников выбранного инструментария. Если команда
разработчиков не в состоянии создавать и развивать свой собственный абстрактный
мир, связанный минимальными узами с операционным контекстом и с реальными
инструментальными системами, то она вряд ли сможет рассчитывать на серьезную
отдачу от своей работы. Ведь при резкой смене политики законодателей моды в
области формальных и фактических стандартов, соответствующих API-интерфейсов,
при новой рыночной стратегии фирмы-разработчика инструментария (а она редко
опирается на чисто техническое совершенство своего детища) перестраиваться на
ходу придется практически всем специалистам. В случае же обеспечения прослойки
технологической безопасности (своего рода рессор) этим будет заниматься крайне
ограниченный круг лиц довольно высокой квалификации. И если они удачно
сформировали внутреннюю архитектуру своего инструментария (что ярко видно на
примере фирмы TopSpeed), то это поможет снивелировать потери от тех потрясений и
сенсаций, которыми столь богат нынешний мир программных систем.
ЛИТЕРАТУРА
[1] Брюс Баррингтон “Как создавался Кларион“ // Мир ПК, 1993, No.2.
[2] Брюс Баррингтон “Истоки языка Clarion“ // Технология программирования, 1995, с.187-194.
[3] Bruce Barrington “Software Manufacturing“ // TopSpeed Developer Newsletter, 1995, February.
[4] Евгений Галочкин “История Clarion Software Corp. и ее программных продуктов“ // Clarion Magazine, 1995, No.1, с.19-21.
[5] Алексей Федоров “Clarion: прошлое, настоящее и будущее. Интервью с Брюсом Баррингтоном“ // Компьютер Пресс, 1997, No.6, с.134-138.
[6] Руслан Богатырев “От рожка до флейты Пана“ // Компьютерра, 1996, No.10, с.36-42.
[7] Дмитрий Рамодин “Призывный звук рожка“ // Компьютер Пресс, 1996, No.4.
[8] Алексей Орлов “Два звучных слова “ Clarion и Delphi“ // Мир ПК, 1996, No.6.
[9] Евгений Галочкин “Clarion и серверы AS/400: новая мелодия для профессионалов“ // Компьютер Пресс, 1997, No.6, с.142-147.
[10] Руслан Богатырев “Кларион и Объектный Паскаль“ // Мир ПК, 1997, No.5, с.60-68.
[11] Дэвид Чеппел “Технологии ActiveX и OLE“ // М.: “Русская редакция“, 1997.