CC BY
15
дифицировать данные текущего информационного массива. Автоматически сформированная иерархия форм сразу может быть использована для доступа к данным, редактирование позволяет оптимизировать ее для большего соответствия решаемым задачам. В случае применения автоматически сгенерированных форм (как для собственных, так и для присоединенных данных) обеспечивается унификация внешнего вида подсистем. При необходимости изменения интерфейса производится изменение вида элементов управления (модификация библиотеки типов) или замена подсистемы КИ.
Имеется возможность совместить два описанных способа доступа к данным. Для этого в состав системы может быть включен комплект ActiveX-компонентов, включение которых в формы приложения на этапе разработки обеспечит (после присоединения готового приложения к системе СОФИ по первому методу) доступ к дополнительным данным соответствующего информационного массива средствами подсистемы КИ.
Подсистема мастер пополнений (МП) предоставляет средства для регулярного обновления информационного и программного обеспечения системы СОФИ. Корректно выполняются пополнение информационных массивов системы, расширение иерархии имеющихся ИПЯ, обновление ряда подсистем и служебных библиотек.
Система ориентирована на работу под управлением операционных систем WINDOWS-95/NT. В зависимости от варианта установки требует от 15 до 90 Мб дискового пространства. Рекомендуемый объем оперативной памяти 32 Мб.
Существует сетевая версия системы, реализованная на основе Internet (Ыгапе^-технологий [10]. Версия предназначена для обеспечения совместного доступа к физической информации в локальных и глобальных сетях. Доступ к данным предоставляется средствами WWW-браузера.
Рассмотренная система разрабатывалась как универсальное и удобное средство поддержки процесса проектирования. Обладая большими возможностями по настройке и модульным строением, СОФИ может быть адаптирована к конкретной предметной области и оптимизирована для решения конкретных задач; продуманный механизм модернизации, средства поддержки гибкой структуры данных позволяют накапливать информацию, предоставляемую группами пользователей и разработчиками системы, контролировать изменения в составе функций и в интерфейсе СОФИ. Подсистема ИППП формирует дружественную среду проектирования, позволяя сосредоточить внимание на формализации решаемой
задачи; содержит множество рекомендаций и известных решений. Реализованные процедуры принятия решений позволяют получить первичную оценку (по совокупности формальных критериев) перспективности рассматриваемого направления проектирования. Эти и ряд других наукоемких процедур поддержки процесса проектирования, позволяют значительно повысить качество и производительность работ изобретателей, инженеров-конструкторов, проектировщиков новой техники.
Авторы приглашают к сотрудничеству всех интересующихся проблемами автоматизации проектирования технических объектов и технологий. Вопросы и предложения просьба направлять по адресу [email protected] (E-mail).
Список литературы
1.Фоменков С.А., Гришин В.А., Камаев В.А. Представление и использование физических знаний при поисковом конструировании изделий машиностроения: Учебное посо-бие/ВолгГТУ, Волгоград, 1994. - 121 с.
2. Карачунова Г.А., Колесников С.Г., Фоменков С.А. Структура описания физических знаний для автоматизированных банков данных //Электродинамика и техника СВЧ и КВЧ. - 1995. -№ 1.-С. 49-56.
3. Карачунова Г.А., Колесников С.Г., Костерин В.В., Фоменков С.А. Автоматизированная информационно-поисковая система по физическим эффектам //Электродинамика и техника.-1995,-№ 1. - С.49-56.
4. Камаев В.А., Фоменков С.А., Карачунова Г.А. Автоматизированная информационно-поисковая система по физическим эффектам. //Сб. науч. тр.: Инновационное образование и инженерное творчество. - М.: Российская ассоциация науч,-техн. творч. «Эвристика», 1994. - С. 87-90.
5. Фоменков С.А., Петрухин A.B., Камаев В.А., Давыдов Д.А. Представление физических знаний для автоматизированных систем обработки информации. - Волгоград: ТОО «Принт», 1998. - 152 с.
6. Фоменков С.А., Колесников С.Г. Представление физических знаний в автоматизированном банке физических эффектов //Изв. вузов. Машиностроение. - 1998. - №1-3. -С. 55-61.
7. Половинкин А.И. Основы инженерного творчества. -М.: Машиностроение, 1988. - 368 с.
8. Техническое творчество: теория, методология, практика. Энциклопедический словарь-справочник./Под ред. А.И. Половинкина, В.В. Попова. - М.: НПО «Информ-система», 1995. - 408 с.
9. Петрухин A.B., Фоменков С.А., Камаев В.А. Использование физических знаний при решении задач концептуального проектирования технических объектов //Изв. вузов. Машиностроение. - 1997. - №1-3. - С. 29-32.
10. Петрухин A.B., Фоменков С.А., Колесников С.Г. Архитектура автоматизированной системы концептуального проектирования технических объектов и технологий с использованием структурированного описания физической информации (СОФИ) для сетевых приложений //Изв. вузов. Машиностроение. - 1998. - № 4-6. - С. 52-56.
ОСОБЕННОСТИ ТЕХНОЛОГИИ ОБРАБОТКИ ИНФОРМАЦИИ НА МАГНИТНЫХ НОСИТЕЛЯХ В СОВРЕМЕННЫХ СРЕДСТВАХ RAD
М.А. Колтыпин, H.A. Семенов
Современный этап развития общества характерен использованием машинной обработки информации. Подразумевается переход от использования бу-
мажных носителей и их обработки вручную к машинным и к соответствующей автоматизации процесса. В данной статье приводятся некоторые аспекты обработки информации на машинных носителях, которые могут быть в дальнейшем использованы в разработке собственных АРМов или информационных систем.
В настоящее время осуществляется планомерная информатизация Государственной налоговой службы России в соответствии с [1-3]; в документах регламентируются принципы формирования и порядок предоставления данных о доходах физических лиц. Используемое в настоящий момент программное обеспечение разрабатывается ГНИВЦ РФ на СУБД FoxPro 2.6.
Основную проблему представляет формирование файла с информацией, причем не сам процесс формирования, но корректность полученных результатов. Описанные ниже предложения могут быть использованы в равной степени как для анализа (приема) информации, так и для формирования данных в необходимом формате.
Налоговые инспекции осуществляют прием информации о доходах физических лиц на магнитных носителях от предприятий и организаций, а существующие системы обработки информации развиваются и находятся в стадии разработки. Авторами статьи предлагаются некоторые подходы к обработке информации с использованием средств RAD (Rapid Application
Development), а именно Borland Delphi® версия 4.0 с установленным Update Pack 2, рабо-
тающая под Microsoft Windows-98®.
Формат файла передачи данных детально описан в [3]. Основную сложность при обработке информации составляет контроль правильности входной информации, а также различия в использованной кодировке информации DOS и кодовой страницы 1251 Microsoft Windows-98®. Что касается контроля входной информации, то одной из проблем также является применение различных алгоритмов разбора входящей информации.
Структуру входного файла можно представить в виде схемы (рис. 1).
В состав сведений входят реквизиты, составляющие адресные данные налогоплательщика, а также сведения о полученных им доходах, произведенных начислениях и удержаниях подоходного налога.
Практика показывает, что при подготовке сведений даже с использованием сертифицированных программных продуктов возможны ошибки, особенно в адресе плательщика, при том, что многие предприятия не используют вышеназванные программные продукты, а, руководствуясь инстр. № 35, собственноручно формируют файл, увеличивая вероятность ошибки.
Рассмотрим принцип контроля адреса плательщика, обычно используемый в существующем ПО (в частности, рассматривался ПК 2.0, написанный с применением СУБД FoxPro 2.6.):
- осуществляется предварительный семантический и синтаксический контроль корректности реквизита содержащего адрес плательщика;
- осуществляется "смысловой" контроль реквизита, для чего его содержимое сопоставляется с классификатором адресов;
- в случае обнаружения расхождений с классификатором при прохождении семантического и синтаксического контроля пользователю предлагается вручную исправить не прошедший контроль адрес.
В данной ситуации существует несколько так называемых узких мест:
SHOW PROCEDURE RequireRekvizit; Procedure text:
/* Объявление временной переменной */ DECLARE VARIABLE REKVTMP INTEGER; BEGIN RESULT = 0;
SELECT DESKR_NUM FROM REKVIZITS WHERE REKV_NAME = :REKVPAR INTO :REKVTMP; /* Проверка существования реквизита*/ IF (REKVTMP IS NOT NULL) THEN BEGIN RESULT=1;
/*Выбор дескриптора функции обработки реквизита из таблицы дескрипторов*/ REKVDESC=REKVTMP; SUSPEND; END
END
/* Выходные параметры*/ Parameters:
REKVPAR INPUT CHAR(3) REKVDESC OUTPUT INTEGER RESULT OUTPUT NUMERIC(l)
Рис. 2. Пример процедуры анализа валидности реквизита
• при формировании данных вручную возможно возникновение как семантических, так и синтаксических ошибок;
• при использовании сертифицированного ПО основным узким местом является отсутствие абсолютного большинства адресов РФ в классификаторе или использование более старой версии классификатора подателями сведений;
• наименование реквизитов может изменяться в дальнейшем, однако в большинстве ПО данная ситуация также не учитывается;
• в существующем ПО используется жесткая программная привязка к стандарту передаваемой информации и к доступу к различным функциям.
В этом случае предлагается использовать подход с учетом возможностей средств Delphi, а также технологии клиент-сервер (в нашем примере рассматривается вариант с использованием Interbase).
1. Применительно к анализу файла с информацией о доходах физических лиц, учитывая возможность изменения в будущем его структуры (формы представления информации), а также формы и представления реквизитов, предлагается хранить вместе как формат, так и дескрипторы функций обработки, причем применительно к функциям можно использовать и процедуры Delphi (здесь узкое место - необходимость перекомпиляции DLL) и хранимые Interbase процедуры (здесь основная проблема - жесткая привязка к единственной СУБД, непереносимость программ).
2. Учет возможности формирования данных вручную и возможность различной степени детализации протокола приема.
Размещение списка реквизитов на СУБД
Обычно в анализируемом файле содержится достаточно большое количество реквизитов, которые могут меняться с течением времени в зависимости от изменений стандартов передаваемой информации. Поэтому как вариант можно выбрать размещение списка реквизитов на СУБД и использование хранимой процедуры для анализа соответствия соответствующего реквизита, анализируемого при чтении очередной записи из файла с информацией. Процесс получения информации можно представить в виде процедуры (рис. 2).
Эта процедура осуществляет поиск очередного анализируемого реквизита в СУБД и в случае присутствия возвращает единицу, что соответствует логическому значению True (Истина) или (в обратном случае) ноль - False (Ложь).
Достоинством ее является возможность обращения к ней из любой версии программы. Даже в случае изменения содержимого программный интерфейс останется неизменным (причем обращаться к данной процедуре можно из любой программной среды с возможностью взаимодействия с ODBC либо BDE драйвером Interbase). К недостаткам следует отнести
большие затраты по времени, чем при работе, например, с Paradox или dBase файлом, используя не SQL, а методы класса TTable Borland Delphi.
Совместное хранение реквизитов и дескрипторов их обработчиков
На образце реквизита АдрФизЛица, содержащего адрес физического лица, рассмотрим примеры хранимой процедуры, ее вызова и организации интерфейса программиста.
Реквизит имеет следующую структуру: «код страны», «код региона», «город», «район», «населенный пункт», «улица», «дом», «корпус», «квартира». Отсутствующие реквизиты пропускаются, каждый реквизит анализируется по содержимому классификатора адресов.
Предлагается разделить синтаксический и семантический контроль, часть процедуры, осуществляющей проверку валидности реквизита, разместить как хранимую процедуру (в конкретной реализации на сервере), а вторую часть, осуществляющую семантический контроль, выполнять в процедуре Borland Delphi.
Вариант совместного хранения данных и дескрипторов процедур в СУБД представлен в таблице.
Таким образом, функции будут находиться вместе с реквизитами, которые они обрабатывают; при подобном подходе обработка реквизитов может производиться следующим образом:
Select from TstFizAdr(:P RekvAdr, :P RekvDesc, :P Result)
Мы задаем P_RekvAdr как входной параметр, в котором передаем обрабатываемый реквизит, P_RekvDesc - дескриптор процедуры обработчика, а P_Result возвращает True (Истину), либо False (Ложь) в зависимости от существования данного реквизита.
Преимуществом данного подхода является возможность практически бесконечно совершенствовать, расширять возможности процедуры, осуществляющей контроль наличия реквизита, без ущерба для программы. К недостаткам мы опять же относим потери времени.
Очевидно, что использование хранимых процедур обусловливает простоту интерфейса программиста (разработчика).
Пример вызова хранимых процедур из Delphi
Использование хранимых процедур в Delphi удобно и просто. Для того, чтобы обратиться к процедуре, достаточно сформировать только запрос.
Таблица
Дескриптор DESKR NUM Функция FUNKY NAME Реквизит REKV NAME Примечание COMMENT
1 TstFizAdr АдрФизЛица Функция, осуществляющая анализ правильности адреса физического лица
Анализ результатов выполнения запроса может выглядеть следующим образом.
Как видим, не раскрывая деталей анализа кон-
// В этой части программы считываем из файла в переменную // REKVIZIT наименование реквизита // REKVTEXT его содержимое
// Инициализируем запрос ADRQuery. Close;
ADRQuery.ParamByName('REKV_NAME').AsString :=
REKVIZIT;
ADRQuery. Open;
// Выбор обрабатывающей процедуры по дескриптору Case ADRQuery.ParamByName('REKV_NAME').AsInteger of
// Функция анализа правильности адреса физ. лица 1: CheckAdr(REKVTEXT):Boolean; // Возвращаемый результат True (Истина) в случае корректности содержимого реквизита
end; // Case
Рис. 3. Пример Object Pascal процедуры выбора функции обработки содержимого реквизита
кретного реквизита, мы имеем простой и достаточно мощный механизм анализа информации, поступающей на магнитных носителях.
Применение подобного подхода позволяет гибко анализировать поступающую информацию, а в случае изменения формата файла обеспечивается коррекция функций обработки реквизитов с минимальными затратами времени. Важно упомянуть простоту конфигурирования системы с использованием данного подхода. Более того, данный подход и некоторые процедуры могут быть скомпонованы в отдельную библиотеку (DLL - Dynamic Link Library) и использованы в разных приложения (АРМах), взаимодействующих с файлами подобной структуры.
Список литературы
1. Федеральный закон от 20.02.95 № 24-ФЗ: Об информации, информатизации и защите информации // Российская газета,- 1995. -№ 39.
2. Приказ Госналогслужбы РФ от 03.02.95 № ВП-3-12/4: Об упорядочении разработки и внедрения программно-технических средств автоматизированной информационной системы в налоговых органах // Электронная справочная правовая система «Консультант Плюс».
3. Инструкция Госналогслужбы РФ от 29.06.95 N 35 (ред. от 15.06.98): По применению закона Российской Федерации: О подоходном налоге с физических лиц. // Российские вести. - 1995,- № 179.
4. Миллер, Тодд, Пауэл, Дэвид и др. Использование Delphi 3: Спец. изд. /Пер. с англ. - К.: Диалектика, 1997. - 768 с.
МНОГОУРОВНЕВАЯ СИСТЕМА КОНТРОЛЯ И УПРАВЛЕНИЯ ПРОИЗВОДСТВОМ СТЕКЛОИЗДЕЛИЙ
Г. А. Дмитриев, Б. И. Марголис, Фади Шараф
Система производства стеклотары состоит из ряда укрупненных технологических агрегатов: дозаторов и смесителей для приготовления шихты, стекловаренной печи, формующей машины, печи отжига, устройств упаковки. Характерными особенностями системы являются наличие большого количества параметров, подлежащих контролю и управлению, значительные расстояния между агрегатами. Все это, с одной стороны, определяет актуальность автоматизации контроля и управления производством стеклотары, а с другой - требует системного подхода к разработке и реализации алгоритма такого контроля [1].
Важнейшими принципами системного подхода к построению системы автоматизированного контроля и управления (СКУ) являются: иерархический принцип построения структуры, систематизация и централизация контролируемых параметров, универсальность математических моделей и программ, модульный принцип построения алгоритмов и программ. Структура СКУ производством стеклотары приведена на рисунке 1.
Нулевой уровень СКУ составляют локальные системы контроля и регулирования, включающие датчики, регуляторы и исполнительные механизмы. Следующий уровень (первый) образует управляющая вычислительная машина (УВМ). В машину поступает
стандартный сигнал от аналоговых преобразователей. УВМ 1-го уровня осуществляет опрос датчиков, проверку достоверности данных, контроль выхода
параметра за допустимые пределы, интерполяцию, экстраполяцию и прогноз изменения параметров, вычисление расчетных показателей. Периферийные устройства УВМ 1-го уровня с помощью сервисных и диспетчерских программ сигнализируют об отклонении параметров, накапливают информацию и распечатывают протоколы, передают данные для решения задач управления.
УВМ, с помощью которой реализуется СКУ, связана с управляющей машиной более высокого иерархического уровня (2-й уровень),
Рис.1. Структура СКУ производством стеклотары
